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?
First of all check if you end up in this stuck state:
... or if you eventually end up with that:
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.
While you see ...
ifconfig br-lan on the router should show the new, changed IP address.
Once the countdown is over and you see ...
ifconfig br-lan on the router should revert back to the previous, original IP address.
The eventually causes the browser to be able to "ping" http://[old-ip-address]/chi-bin/luci/... again which will then trigger this dialog:
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.
@jow Here are my test results.
I´m ending in stuck state with "failed to confirm apply withing..."
Periodical (every 5 sec) output of ifconfig br-lan and dmesg while changing default ip to 192.168.2.1: https://pastebin.com/xxDAwwGd
The output of logread -f for the same action: https://pastebin.com/gnXCtpMa
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 
Does it also work normally if you do an "/etc/init.d/network reload", "ubus call network reload" or "ifup -a" after changing the ip?
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)
With a non working interface:
root@OpenWrt:/# ip neigh flush dev br-lan
Nothing to flush
With a working iface:
root@OpenWrt:/# ip neigh flush dev br-lan
192.168.1.2 lladdr 28:d2:44:87:59:b1 ref 1 used 0/0/0 probes 4 REACHABLE
*** Round 1, deleting 1 entries ***
*** Flush is complete after 1 round(s) ***
ping6 does also not work after ip address change and a reload, after a restart it does work.
I guess its boils down to low level ag71xx ethernet driver things and/or interaction with the switch. Will try to gather some more opinion in irc.
Can you please also compare brctl show output before and after?
The same output before and after...
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.
show us a dmesg and if you are willing to test it, we will help you, but come to the dedicated thread or open a new one
I´ve added a new build!
Changelog:
Greets
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.
What can I do?
Thanks
In the first post i mentioned if you come from ar71xx you have to use the force option -F.
Please check the first post, you also have to create a new wifi config and adopt it to your old one...
Sorry, my bad. Thank you for your patience and for your work!
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!