The OpenWrt Community is proud to announce the sixth service release of
the stable OpenWrt 18.06 series. OpenWrt 18.06.6 incorporates security
updates for base packages, new versions of the Linux kernel, a bug fix
related to signature verification, and fixes for various devices.
Some selected highlights of this service release are:
Linux kernel updated from 4.9.198 to 4.9.208 and from 4.14.151 to 4.14.162
Security fixes for the following base packages: e2fsprogs, openssl, uhttpd
LXC and netns fixes for an issue that could cause kernel panics
PCIe reset crash fix on brcmfmac
Device detection fix for all Mikrotik devices, fixing sysupgrade for newer devices
Device support fixes for several devices: lantiq, Archer C20i, Mikrotik RBM33G, TL-WDR3320 v2, TL-WDR3600, TL-WDR4300, TL-WDR4310, TL-WDR4900 v2, Archer C5, Archer C7, MW4530R, WeVO 11AC NAS, WeVO W2914NS v2, ASUS WL-330N, Asus WL-330N3G, Samsung CY-SWR1100, Ravpower WD03
Note that updates to the package feeds are available immediately to all
minor releases of OpenWrt: there is no need to upgrade to a new OpenWrt
image to install newer versions of a package. This applies to core
OpenWrt packages as well as community-maintained packages.
As always, a big thank you goes to all our active package maintainers,
testers, documenters, and supporters.
I think there may be a possible regression in the 18.06.6 release which did not exist in the previous point releases. Twice now since installation I have woken up in the morning with no internet access. It appears to be DNS resolution at first glance because the browser etc says cannot resolve name, etc. I can connect to the Archer C7 v2 router using IP only. Resolution requires rebooting at which time it is fine for a couple of days.
In the log it has a warning from dnsmasq warning that the maximum number of concurrent DNS connections has been reached.
It's possible pppoe-wan is involved in some way. I will have to check when I get home if I am able to ping the IP I wasn't able to ping earlier using the router diagnostics, unless that is also trying to use DNS. Will check. If I can, then the problem isn't with dnsmasq and is actually the internet connection itself despite the system overview showing as connected to the isp gateway, DNS servers, etc. I will update this post, but in either case, there is still an issue and if reproducible, this release should be pulled.
I will revert back to the previous 18.06.5 and will monitor for a few days to see if the same thing happens again when it didn't previously.
Update: The ping command is working from within the router. I haven't tested with all DNS disabled to see if it still works. So I'm leaning toward an interface issue as an interface not passing data but appearing to be active would certainly mess with DNS. Reverting down now and will monitor till the weekend.
Update 2: No loss of internet with 18.06.5 4-5 days later, I suspect the issue will come back if I go back to 6.
I am not sure, if I understand this correctly, so please excuse this dumb question: does this mean, if my device is running 18.06.5, I will get all the new program versions from 18.06.6 just by doing normal "opkg upgade"?
My FB4040 is running on 18.06.5, kernel 4.14.151, and "opkg list-upgradable" doesn't show any package that could be upgraded. If I am not misinterpreting your statement, kernel 4.14.162 and some other packages should be offered as upgradable.
Are you relying on the ISP DNS servers? If so, you might be able to resolve by ignoring the ISP DNS, and configuring your own pair of custom DNS servers (e.g. 4.4.4.4).
My guess is the PPPoE stack had to renew the handshake at some point, and dnsmasq failed to obtain the IP of the DHCP sever handed via the PPPoE auth.
You could confirm this by restarting the dnsmasq instance next time DNS lookups fail.