If your clock if off by a large amount, SSL connections cannot work. And since your DNS uses SSL, the domain name of the NTP server cannot be resolved. A possible solution would be to replace the domain name of the NTP server by its IP so it doesn't need to be resolved.
I understand and confirmed today that this is what causes the problems. So this is nothing specific to 19.07.
No I can't confirm this issue.
I have seen strange wifi issues on the BT HomeHub 5A on 19.07.0-rc2. I've made the recommended change to the interrupt steering to use both processors:
#set_hex_val "$q/rps_cpus" "$(($PROC_MASK & ~$irq_cpu_mask))" set_hex_val "$q/rps_cpus" "$PROC_MASK" #set_hex_val "$q/xps_cpus" "$((1 << $idx))" set_hex_val "$q/xps_cpus" "$PROC_MASK"
There are no particular issues with my laptop and my Huawei Mediapad - the WiFi speeds are up to 140Mbps WiFi-lan (test using iperf3 to a LAN server) however with my Samsung Galaxy S9, if I test the minute I restart the wifi I sometimes get 150Mbps but after half a minute or so it never gets above 25Mbps even though other devices will reach 120+Mbps. I reflashed 18.06.4 with the Maurer patch and I get up to 150Mbps consistently on all devices including the Galaxy S9.
Upgraded both a Netgear WNDR3800 and Archer C7 v2 via web interface without serious problem. I used the 18.06 "Keep Settings" to, well, keep the settings. I had to re-install packages manually, though...
The only confusion was that my browser couldn't log into the Archer C7 after the reboot. (The WNDR3800 worked fine.) With the Archer C7, I could get the main login page, but my password was not accepted. I tried reloading the browser, even force reloading the browser.
Fix: Quitting/exiting the browser (current version of Firefox on macOS) and then going back to the router login page worked fine, all settings saved, etc.
Does 19.07.0 rc2 support flow-offloading?
Yes it does.
When can we expect the first final 19.07.00 release ?
According to the mailing list, they're tagging the final on the 6th of this month, so ~10th maybe?
https://openwrt.org/releases/19.07/start#roadmap says preliminary date schedule is January 12th.
When trying to upgrade to 19.07.RC2 from 18.06. on a Mikrotik RB433UAH the device starts to loop and I see this error:
ubi: refuse attaching mtd6 - MLC NAND is not supported
Any idea what the problem might be?
[ 3.054043] NAND flash driver for RouterBoard 4xx series version 0.2.0 [ 3.060874] nand: device found, Manufacturer ID: 0xad, Chip ID: 0xdc [ 3.067234] nand: Hynix NAND 512MiB 3,3V 8-bit [ 3.071666] nand: 512 MiB, MLC, erase size: 256 KiB, page size: 2048, OOB size: 64 [ 3.079310] Scanning device for bad blocks [ 3.158919] Bad eraseblock 479 at 0x0000077ff800 [ 3.375876] Bad eraseblock 1844 at 0x00001cd3f800 [ 3.403720] Bad eraseblock 1993 at 0x00001f27f800 [ 3.417289] Creating 3 MTD partitions on "NAND 512MiB 3,3V 8-bit": [ 3.423477] 0x000000000000-0x000000040000 : "booter" [ 3.429995] 0x000000040000-0x000000400000 : "kernel" [ 3.436296] 0x000000400000-0x000020000000 : "ubi" [ 3.446603] libphy: Fixed MDIO Bus: probed [ 3.453884] IP17xx: Found IP175D at ag71xx-mdio.0:00 [ 3.461449] libphy: ag71xx_mdio: probed [ 3.806071] ag71xx ag71xx.1: connected to PHY at ag71xx-mdio.0:04 [uid=02430d80, driver=Generic PHY] [ 3.815743] eth0: Atheros AG71xx at 0xba000000, irq 5, mode: rmii [ 4.259683] ag71xx ag71xx.0: connected to PHY at ag71xx-mdio.0:00 [uid=02430d80, driver=IC+ IP17xx] [ 4.269293] eth1: Atheros AG71xx at 0xb9000000, irq 4, mode: mii [ 4.277204] NET: Registered protocol family 10 [ 4.285926] Segment Routing with IPv6 [ 4.289669] NET: Registered protocol family 17 [ 4.294140] bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfilter if you need this. [ 4.307126] 8021q: 802.1Q VLAN Support v1.8 [ 4.311423] rb: no calibration data found [ 4.318830] UBI: auto-attach mtd6 [ 4.322148] ubi: refuse attaching mtd6 - MLC NAND is not supported [ 4.328369] UBI error: cannot attach mtd6 [ 4.333000] VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6 [ 4.340534] Please append a correct "root=" boot option; here are the available partitions: [ 4.348877] 1f00 44 mtdblock0 [ 4.348881] (driver?) [ 4.355418] 1f01 4 mtdblock1 [ 4.355421] (driver?) [ 4.361943] 1f02 8 mtdblock2 [ 4.361946] (driver?) [ 4.368473] 1f03 4 mtdblock3 [ 4.368476] (driver?) [ 4.375002] 1f04 256 mtdblock4 [ 4.375005] (driver?) [ 4.381530] 1f05 3840 mtdblock5 [ 4.381532] (driver?) [ 4.388059] 1f06 520192 mtdblock6 [ 4.388062] (driver?) [ 4.394579] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) [ 4.403707] Rebooting in 1 seconds..
Yes, its normal.
MLC NAND flash was never supported officially in UBI.
It was still working in 18.06 and I fought to keep support throughout all point releases, but it was agreed to follow upstream on this matter and drop it after 18.06
see this for details
You can make your own 19.07 build and add the patch from that commit, but it's at your own risk with zero support.
Have seen a similar issue which I logged at FS#2563. Would be interested if there is any resolution to this. I had to revert to 18.06.04 to make 5 GHz useable.
sorry for the noobish question but what is with the new "openwrt-19.07.0-ath79-generic-tplink_tl-wr1043nd-v2-initramfs-kernel.bin" file ? what is it for?
Since 19.07 is available now, this topic is obsolete and will be closed.
Please open new topics for any remaining questions regarding 19.07.
Commonly initramfs image is loaded via tftp into RAM, so it is like LiveCD image. Specifically for TP-Link I don't know.
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.