Was Gi.net b1300 vlan problem fixed in this release
Ftrizbox 4040, from 19.07.3 to .4, first attempted with "keep settings".
After fixing the missing packages using opkgscript.sh, I still have one BIG issue: the wired ports do not work, the TX counter shows traffic but all RX counters stay at 0.
My switch was split in 3 segments and the ports in the old config were listed in descending order; the new version likes them better in ascending order, but I don't think that is the issue here: I removed the network config, let the boot process generate a platform default, saw the different ordering, fixed it in my older config and rebooted again. Still no RX traffic.
I'm going to try with the default switch configuration and then revert to .3, else my NAS and destkop won't be pleased.
EDIT: started from a clean network config on .4, added one VLAN (named 101) and GUI rolls back the config. If I do the config from serial console, I can see there is no RX traffic after restarting network config to apply switch config.
TLDR: do NOT update to 19.07.4 if you have a 4040 (and possibly any ipq40xx device) and you need to split the switch. I am writing this after going back to .3 which works just fine. I'll update this post if new info comes up.
Most likely this is the reason
to the mods: feel free to break this post out of the thread if it makes sense.
Thanks aboaboit! It is quite a pitty that OpenWRT was released without taking into account ipq40xx devices and fixing vlan tagging.
Now we need another service release.
Router is spontaneously rebooting after .4 update. I just noticed somewhere on openwrt.org that I wasn't supposed to do the update from the NetGear webui, but rather use a program Linux program to flash. I thought "aha!", and reflashed latest Netgear firmware and then Openwrt fw.
Still rebooting spontaneously.
FWIW, my affected device is a NetGear R6120.
Probably doesn't matter, but just in case, I'll mention that I am 1 of 4 renters living in this home. I have split the 4 Ethernet ports into 4 different segments. While there is no firewall between them, I have all 4 LAN ports split into 4 different IP address subnets, each with its own DHCP server settings, etc. WiFi is Bridged to the 1st LAN port, and the other 3 have a separate APs at the other end of their respective Ethernet runs. I have had to completely take down my Netgear router, and put back up my backup router.
No issues upgrading 5 routers (4 remotely):
2x Archer C7 v2
I'd like if the sysupgrade options "-u" and "-k" were added to LuCI as well.
Also, /etc/rc.d/* symlinks deletions are not preserved across upgrades. On some routers, I disabled dnsmasq and odhcpd. I have to do it again after each upgrade, and reinstall packages. If there was an automatic package re-installation feature, a minor upgrade like this would be transparent to me.
thanks for the good work
5 posts were split to a new topic: Automatic update script
Hi All, upgrading from a 19.07.3 I to 07.4 I'm getting this message:
The uploaded image file does not contain a supported format. Make sure that you choose the generic image format for your platform.
device is indeed a xiaomi mini, file is miwifi-mini-squashfs-sysupgrade.bin , checksums match.
Should I just cross my fingers and force (-F) the upgrade ?
Rock solid for 14 days on my Netgear R7800.
My issue was related to firewall hardware offloading, disabling it fixed the stability issue
Replying to my own question: yes, you can safely force update the 19.07.4 image.
AFAIK someone omitted 'xiaomi' somewhere, but otherwise 19.07.4 is running fine.
Flashed a snapshot update, and the device rebooted maybe 2 more times, but has now been up almost 7 days straight. For some reason, when I flashed the snapshot, LuCI stopped working, and I had to ssh in and install the packages. (I'm just glad I re-enabled dropbear before doing the update). Everything seems to be great now. Thank you to the devs at OpenWRT.
I have a question regarding the .4 update. If this is the wrong place to ask, well, mods don't really need my permission to move it...
Anywho, I noticed there is no update link for my Netgear R7900. Is this an oversight, or is there some reason why I can't or shouldn't update it directly from .3 to .4?
Update: I've been running on new .4 version for 16 days now and with constant 10 wifi clients and another 5 wired devices without any issues. We're constantly streaming, Zoom meetings, YouTube, and video chat all without any issues. This is a very stable build!!! Much thanks to all the Devs!!!
Snapshots do not include LuCI, never have. So this is entirely expected and you did the right thing.
Official stable release builds do include LuCI, of course.
From my experience with a R7800 I got more Wifi client drops of an android lineage note 3 smartphone than with 18.06.8. Despite the higher drop frequency there is surely a lineageOS problem (generally?) because it doesn't reconnect itself automatically.
I had the same issue with a ZBT-WG3526 (16M). It looks to me that somehow it has been broken.
With the previous release I was using:
iptables -A forwarding_rule -i br-lan -o pppoe-ONT -m conntrack --ctstate RELATED,ESTABLISHED -j FLOWOFFLOAD --hw ip6tables -A forwarding_rule -i br-lan -o 6in4-he -m conntrack --ctstate RELATED,ESTABLISHED -j FLOWOFFLOAD --hw
(pppoe-ONT and 6in4 are my WAN and IPv6 tunnel interfaces, respectively)
With this release, I needed to change it to:
iptables -A forwarding_rule -i br-lan -o pppoe-ONT -m conntrack --ctstate RELATED,ESTABLISHED -j FLOWOFFLOAD ip6tables -A forwarding_rule -i br-lan -o 6in4-he -m conntrack --ctstate RELATED,ESTABLISHED -j FLOWOFFLOAD
Sooo, where can I find the OpenWRT update firmware to move my .3 box to .4 on my R7900. The spot for it on the ToH is blank.
In order to make it easier for users which are expecting that there are two different OpenWrt images (one for installation, one for upgrading), I have copied the install link to the upgrade datafield.
Xiaomi R3P problems if we plug ethernet cable to LAN port no2, all LAN became unsable , connected but will not get dhcp ip(No RX packets), and wifi performace so poor ping spike very high.100 ms+