What should i do with serial console to get more information on this issue?
If i change a ip address of a network interface other than the interface from that the current luci session is served it will work without problems. Seems it only occurs on the interface which serves the luci session.
Should there be two ip´s on the interface until the new one is verified to work?
In the latter case, everything works as expected (you could force changing the LAN ip with "Apply unchecked" and reconnect/relogin manually afterwards).
In the former case, something went wrong with the network reconfiguration after rolling back the uci configuration.
If that last dialog is never appearing, this means that for some reason, the br-lan interface is not reverting back to its old IP address, or if it did, some lower level issue is preventing it from communicating with the outside.
If it is stuck in such a state, I'd further try via serial if things like ifup lan, ifup -a, echo f > /proc/net/nf_conntrack are fixing it. It would also be interesting to observer both logread -f and the output of dmesg while such an apply/roolback session is running to see if there are any carrier events, protocol handlers executed and the like.
After revert i could not ping the device on 192.168.1.1 and luci never showed dialog to revert or apply unchecked.
I´ve tried ifup lan, ifup -a and echo f > /proc/net/nf_conntrack but device doesn´t resond to pings afterwards anyway.
Then i´ve tried if down lan && ifup lan and does also not work...
If i do ifdown lan && sleep 1 && ifup lan the device does respond to pings and the dialog to revert or apply unchecked on luci shows up.
Don´t have a clue why it needs a delay between ipdown and ifup
If i change the ip in /etc/config/network and do a /etc/init.d/network restart it will work normally, but with /etc/init.d/network reload it will not work
I see. Thats not entirely unexpected. A restart will completely tear down network, stop netifd, start netifd again and reinitialize everything from scratch. A reload, however is supposed to incrementally apply only changed settings.
Can you check if flushing the neighbour cache (ip neigh flush dev br-lan) makes any difference after reload? Can you also try to ping6 the link-local IPv6 address? (ping6 fe80::...%eth0 from a connect client)
root@OpenWrt:/# brctl show
bridge name bridge id STP enabled interfaces
br-lan 7fff.ec086b8ac472 no eth1.1
root@OpenWrt:/# nano /etc/config/network # change ip of lan to 192.168.2.1
root@OpenWrt:/# /etc/init.d/network reload
root@OpenWrt:/# brctl show
bridge name bridge id STP enabled interfaces
br-lan 7fff.ec086b8ac472 no eth1.1
root@OpenWrt:/# /etc/init.d/network restart
root@OpenWrt:/# brctl show
bridge name bridge id STP enabled interfaces
br-lan 7fff.ec086b8ac472 no eth1.1
Changing lan to non bridged and only to eth1.1 does work with a relaod... But if i change ip on the non bridged interface same behavior as with a bridged lan.
@blogic has a specific idea on what might be wrong and plans to look into it tomorrow. Could be that some required patches to adjust_link() didn't get ported over to ath79.
When the devs deem the target mature the buildbots will pick it up. Support for lots of devices is being brought up just now, and those devices need to be tested. Kinks are being worked out. You don't want people flashing that stuff only to find out they need serial to recover their device (or, worse, need to buy a new router).
I'm not at all familiar with DTS, but I wonder how much different Archer C7 v4 is from C7 v2? Any chance you can create (and send a PR for) the DTS for C7 v4 and include it in your builds?
PS. I've also sent an e-mail to the contributor of the DTS for the C7 v2.
Hi, I'm trying to flash through sysupgrade your firmware to an Archer C7 V2 and I get a message that archer-c7 device is not supported, only tplink and tl-archer-c7-v2.
I tried it in a C7 V2 and had to go back to ar71xx because I was running into many problems while changing the interface IP and creating VLANs.
Thanks!