OpenWrt 18.06.0 release

Thanks for all the hard work!!! <3

1 Like

I'm using OpenWrt/LEDE 17.01.5 on 1 of my 1900ac(s) (vlan. openvpn, openssh, dnscrypt and my custom scrips)

+1 setup :slight_smile:

Can I use "sysupgrade -c linksys-wrt1900ac-squashfs-sysupgrade.bin" from 18.06.0?

I have the same hardware and used luci to upgrade from 17.01.3, everything seems fine, you still have to re-install all those packages though.

2 Likes

Excellent news, my sincere thanks to the team.

I loaded 18.06.00 on my TP-LINK TL-WR741ND v4 just an hour ago.

It works, 84KB remaining free after my additional 10k of startup and sched configurations are added.

1 Like

No kmod-fs-exfat package in repo. Is it possible to get it anywhere except self-compiling?

Currently no.
By current defaults, the buildbot system does not build patented stuff anymore, and exfat falls into that category.

As kmods are tightly tied to the kernel version and options, compatibility requires exactly same version.

In theory, somebody might compile a compatible kmod with the release SDK and place it available (like eduperez has done for new mwlwifi versions), but so far nodoby has done that.

Ps.
regarding exfat, detailed explanation can be found in Exfat package for 4.14? (build patented)

1 Like

thats a biggie and will hit a lot of people. should be in the know issuses (maybe in bold)

1 Like

That also affects multimedia stuff around ffmpeg

About the exfat driver, there's a new(er) driver that probably should replace the current one however I can't figure out how to get it to report exfat as exfat instead of sdfat.

If someone knows the solution feel free to reply in

1 Like

@jow
above is a wish for the release 18.06 docs: mention that patented stuff is not available anymore in the release download repo and needs to be built by the users themselves. Same goes also for master snapshots, of course.

Affected stuff is e.g. exfat file system, some ffmepg-related multimedia packages, etc.

kmod-sit don't worked!

Thu Aug  2 16:28:48 2018 kern.info kernel: [2363628.104336] sit: non-ECT from 64.6.8.24 with TOS=0xf
Thu Aug  2 16:28:48 2018 kern.info kernel: [2363628.115230] sit: non-ECT from 64.6.8.27 with TOS=0xa
Thu Aug  2 16:28:48 2018 kern.info kernel: [2363628.218472] sit: non-ECT from 64.16.12.14 with TOS=0x1
Thu Aug  2 16:28:48 2018 kern.info kernel: [2363628.226370] sit: non-ECT from 64.16.12.14 with TOS=0x5
Thu Aug  2 16:28:48 2018 kern.info kernel: [2363628.234014] sit: non-ECT from 64.16.12.14 with TOS=0xa
Thu Aug  2 16:28:48 2018 kern.info kernel: [2363628.245159] sit: non-ECT from 64.6.8.27 with TOS=0xa
Thu Aug  2 16:28:48 2018 kern.info kernel: [2363628.251850] sit: non-ECT from 64.6.8.27 with TOS=0xa
Thu Aug  2 16:28:48 2018 kern.info kernel: [2363628.359123] sit: non-ECT from 64.6.8.24 with TOS=0xe
Thu Aug  2 16:28:48 2018 kern.info kernel: [2363628.392724] sit: non-ECT from 64.6.8.27 with TOS=0xa
Thu Aug  2 16:28:48 2018 kern.info kernel: [2363628.404445] sit: non-ECT from 64.6.8.24 with TOS=0xb

Fix it!
I'll be waiting for 18.06.1

Can we have table which ar7xxx platforms migrated to ath79 kernel 4.14 thx!

In this release? None so far.

Thx sorry I thought it was done.

Are you sure it doesn't work? It works for me, but gives a lot of logging noise. First hit on Google: "Kernel update 4.4.132 enables log_ecn_error in sit module by default now, syslog spam". So a simple
echo N > /sys/module/sit/parameters/log_ecn_error
in /etc/rc.local solved the issue.

Do you mean: "Could you fix that, please?"

6 Likes

I'd like to think he didn't want to be offensive and he's English is just bad.

Do you mean: "his English"?

1 Like

I felt this is my lucky friday the third and I made a sysupgrade on a Netgear R7800 from 17.01.4 to 18.06 and checked 'keep settings'. The white LED is blinking slowly and that's it, not getting an IP.

Lucky me I got a second R7800 with 17.01.5 ;- )

That sounds bad!

Was just about to ask if upgrade from 17.01.4/5 to 18.06 was supported?

Can you please be more specific? Which bin have you used? I have a live TL-WR741ND v4 and I'm afraid to flash it since I tested 18.06.0 yesterday on a spare D-Link DIR-300 B1 (same 4MB Flash / 32MB RAM) and had 0 space left, couldn't even save the LuCI password.
This is what I used on the D-Link DIR-300 B1:
https://downloads.openwrt.org/releases/18.06.0/targets/ramips/rt305x/
dir-300-b1-squashfs-factory.bin 6bc9f1c3cc2ebcbc21a771be0285140001d229e04d7a02ba1f6d449e1aa93c86 3584.1 KB Tue Jul 31 17:25:04 2018
dir-300-b1-squashfs-sysupgrade.bin 63a64d80c75a8367cee474796a855a667c3bbfdc3d8629b5377f4c156e6af81a 3584.2 KB Tue Jul 31 17:25:04 2018

And what I found for the TL-WR741ND v4:
https://downloads.openwrt.org/releases/18.06.0/targets/ar71xx/tiny/
tl-wr741nd-v4-squashfs-factory.bin 36c2810487eb0a612a6495e4a5a40339bea3df518998ab49bc7768077391d059 3840.0 KB Tue Jul 31 04:42:06 2018
tl-wr741nd-v4-squashfs-sysupgrade.bin 04544705f136d4e49225767d2d640a0521fb700b7819c02c96564027356b4ccc 3584.0 KB Tue Jul 31 04:42:06 2018

Note the same size of the flash bin files.
With my D-Link DIR-300 B1 experience, 0 space left after flashing 18.06.0, i was about to suggest to ditch the IPV6 support for these old 4/32 routers if that will save some space and make the flash files usable.

my devices hung unless i unchecked 'keep setting'. after flashing new 18.06 version, i could restore settings. i havent dug in to figure out why. i'm sure some dev knows!