Cool. Thnks all contributors for this incredible work!
Anyone else running into issues with hardware flow offloading on a mt7621 device? I was getting the full 500/500 mbit from my WAN connection on dslreports with minimal router load during tests on 18.06.x series. I am now seeing 500/400 bottlenecked speeds, with multiple cores hitting 100% load.
Has anyone been able to update their Xiaomi Mi Router 3G (mir3g) with the latest OpenWrt 19.07.0? There is no .tar file in the releases folder and the router will not accept the .bin file.
Another question related to this is, if you have updated your Xiaomi Mi Router 3G (mir3g) to the latest OpenWrt 19.07.0, do you have ipv6 working?
There is a mt7621 related bug FS#1763 in the 18.06 and ipv6 does not work with this router, and I can't update my router to test, for above mentioned reason.
I'm missing the 'Force connection tracking' checkbox in the firewall's dialogs. It now has a tab for conntrack settings, but it does not seem to have the same effect. It does not write an option conntrack to the firewall file.
Minor disagreement. Factory can be used anytime (including from OEM firmware). My personal best practice is, for major version number changes I use the factory file and for minor version updates I use sysupgrade. I would also use factory instead of sysupgrade if I was changing from AR71 (which is what I have on 18.06) to ATH79.
Wrong for most routers. Totally depends on the router...
For most routers the factory image contains a header that makes it compatible with the OEM flashing routine: like "Factory = header + sysupgrade image + possibly padding". But flashing that factory image via sysupgrade would brick the router. (no idea about that 3700v4 specifically, maybe that is an exception, if you are sure about that)
Makes no sense for most routers. The sysupgrade and factory have identical functional contents except that packaging (for OEM flashing routine).
5 Likes
Interesting. I had no idea that other routers could have issues. I can attest that the Archer C7 v2 has never had a problem flashing the factory image from within luci which I have done multiple times in the 17.x series and once to the 18.x series. Thanks for making me aware it could be an issue on other devices.
Factory on the Archer is probably still a better recommendation for people switching from AR71xxx to ATH79, because most people (in my opinion) will be using the luci web interface and won't see it documented anywhere that they need to drop to a commandline and sysupgrade -F etc.
Thanks, that'll do. Out of curiosity does that mean LUCI can't be used even when unchecking "keep settings" since it has no "force" equivalent?
Using sysupgrade over SSH gives you more flexibility. I never upgrade through LuCI myself, frankly, but that's mostly just force of habit.
@Sunspark Please stop recommending bad practices. Like @hnyman said, there's a valid reason why OpenWrt differentiates between factory and sysupgrade images. If you want to persevere, that's fine, just don't drag other people along.
1 Like
Is it normal that my router got a slightly modified MAC address after upgrading? Shouldn't be a biggy, but it prompts all the windows machines on my network to see it as a "new network", reverting their settings to "public network".
I've tried to upgrade my r6220 via LuCi from 18.06.5 to 19.07.0 (image openwrt-19.07.0-ramips-mt7621-r6220-squashfs-sysupgrade.bin, sha256 checked), but it don't come up again.
From led behavior it seem to reboot continuously, but I'm trying to understand better what is going on.
In the meantime, be careful with this device.
1 Like
THANKS MATE!
I was becoming crazy, 5GHz wasn't working (even on WPA2)
I wasn't able to connect to device, netither to boot in failsafe mode.
So I can't be more helpful in diagnosis this problem, if you have some checks that I can redo, I'll can try.
In the meantime, I have debricked my device with nmrpflash and installed from USB rootfs.bin and kernel.bin. Now I'm running 19.07.0 without problems.
I've upgraded another netgear r6220 via cli (sysupgrade) with the same file (openwrt-19.07.0-ramips-mt7621-r6220-squashfs-sysupgrade.bin) and all went good.
1 Like
what device do you use?
Some devices were initially using a "wrong" MAC, i.e. not the primary one printed on the device, which is sometimes corrected later and could affect you now.
I installed yesterday and runs good. I want to point out that, for Netgear R6220 the image file is named differently between snapshot and stable release, so you have to "force" the upgrade because is seen as a different file.
snapshot -> netgear_r6220-squashfs-sysupgrade.bin
stable -> r6220-squashfs-sysupgrade.bin
I upgraded my Archer C7 v2 from 18.06 to 19.07, and from ar71xx to ath79 using the sysupgrade image through the luci web interface.
The only thing is that I didn't check the option to preserve settings.
1 Like
I upgraded to this release on a GL-B1300 have noticed I receive every 3 seconds a "daemon.err hostapd: Failed to set beacon parameters" whilst this doesn't cause any noticeable issues was wondering if I should log this somewhere?
Patrick helped me on IRC - apparently it was a correction made specifically for my device (TP-Link WDR 4300 v1).
I've also switched from ar71 to ath79, as per his recommendation.
Uploaded the sysupgrade binary, upgraded without keeping config files. I've redone my config, since re-uploading the config I'm lugging around for years didn't seem like a great idea when switching architecture - ymmv. All I can say is that functionality and performance seems to be the same for me, after the switch.
I apologize for sidetracking the thread here, I just wanted to give a quick update to the feedback from @hnyman and @Borromini regarding factory vs sysupgrade.
I went reading to see if I could learn what is the difference. From what I was able to gather, the factory.bin file contains magic bits in the header for the benefit of the OEM firmware, and the rest of it fills up the entire flash memory space with the partitions that are supposed to exist, and does not overwrite the uboot partition (interestingly, I was able to find a rare edge-case openwrt device that does overwrite uboot). Today, both factory and sysupgrade files contain the same packages, etc. Sysupgrade copies the data to the /tmp partition in RAM, and then as part of the process clears out the previous system partition and copies the data over from /tmp to flash.
I don't believe I damaged my specific router by the previous usage of the factory file more than once, but I am comfortable enough now that for 19.x I will use the sysupgrade file to perform the change to ATH79, just not ticking keep previous config files for this upgrade.
I do have a recommendation to make. I think the easiest path to enforce correct user behaviour, as I suspect I may not be the only one who has done this, would be to have a line of code in the LuCI "Flash new firmware image" section to reject firmware .bin files that contain the characters "factory" in the filename. Command line would be unaffected and if someone really needed to they could just delete those characters from the filename since it would just be a generic filename string check. It isn't stated clearly in the existing documentation that bad things will happen if you use the factory file again and I figure this tweak to LuCI is easier than updating the internet.
Looking forward to seeing people's LAN & WiFi benchmarks with 19.07 for AR71xxx vs ATH79. My connection isn't fast enough to give the device a workout.
3 Likes