Ath79 builds with all kmod packages through opkg [flow offloading]

Hehe, oh well. :slight_smile:

Will do a rebuild of latest image with fixed luci switch page...
Luci switch page is fixed... builds are uploading
Everyone who have this issue could also wait for the next package snapshot builds and update luci with opkg instead of installing the fixed images...

do these builds already have mtd installed, so i can install the bootloader..

Mtd is installed... To make read-only partition temporary writeable, do a:

opkg update 
opkg install kmod-mtd-rw 
insmod mtd-rw i_want_a_brick=1
1 Like

Hi @juppin, if I come from factory firmware on archer C7 is it enough to install your version just from webinterface? console with -F parameter is not needed, or shoul it be used with sysupgrade.bin after putting the factory.bin ? also, what is the difference between eu, us and plain factory.bin firmwares? thanks

Forgot that to mention... Install from stock fw should work with the factory images directly. No need to do a sysupgrade after first install... Don´t know which version you have to use, i would first test the factory image without US/EU and if this get not accepted by stock webinterface try US and/or EU factory images.
As i know the US/EU version does differ in the tp link header only...

Installed latest version of Archer C7 v2 and so far no problems at all, just installed all the packages I require.

I have also installed your buil on both an archer c7 and a wdr4300, both are running well since yesterday, no problems on 5ghz band which I use...although I haven't observed any performance change using this new kernel and software offload compared to the "optimized lede" build I was using before; anyway, thanks for your efforts of making this possible even on old hardware like 3600 and 4300

Hmm, if I change the default interface from 192.168.1.1 to whatever I'm using in my network, then the device becomes unreachable. This is on a 1043ND v2. No DHCP assigned IP given to the PC, and it's not reachable if I try to connect to 192.168.1.1 nor my new IP having manually set an IP in either of these ranges...

Weird. Recovery+TFTP'd back to stock then flashed a factory AR71xx image and restored a backup.

I'll wait until it's more polished.

I use on all my ath79 devices (wdr3600, wdr4300, wr1043v2, wr1043v3 and wr1043v4) non default ip addresses and i do not have any problems... Probably you have missed something...

I had the same problem, if I change device IP address from UI and apply the change it timeouts waiting for the changes to be applied and it kind of reverts to old config but PC does not get IP anymore, had to reboot and it boots with old IP.

Only way I find out it works is to edit network config file via SSH and then rebooting the device.

2 Likes

Sounds like the next issue with luci... Doesn't changed the ip with LUCI for a long time.
Would you mind to create an issue at luci´s issue tracker?

I´ve created a issue on luci´s github repo.

2 Likes

Does anyone know if the next stable release will include this for the Archer c7 v2? I see there's a release candidate build now.

Will be not included in 18.06.
If you take a look into the 18.06 source, there is no ath79 target. It is completely dropped on this branch.

Currently the ath79 target is a source-only target. This means there is also no image build by buildbot on trunk/master.

How do we fix that for trunk/master? I assume some hoops need to be jumped through and it's too risky for 18.06 but it would be nice to get the trunk going to encourage further testing.

Unfortunately I am unable to reproduce the problem. When I change the LAN IP from 192.168.1.1 to 192.168.2.1 in LuCI, I lose access (as expected) and the failure screen appears stating that the config has been rolled back because the device cannot be reached anymore. I then chose to perform an "unchecked apply" and reconfigure my PC network adapter to use 192.168.2.2 instead of 192.168.1.2. Afterwards I am able to reach LuCI just fine at http://192.168.2.1/ instead of http://192.168.1.1/.

1 Like

I flashed the latest 4.14.51 based kernel version build available here for the 1043ND v2.

After flashing, I changed LAN IP from 192.168.1.1 to 192.168.10.2, then got the "30s to apply" message, then a message that states settings will be rolled back. It wouldn't go away. Waited a few minutes.

This is when the device becomes unresponsive and unreachable. It won't provide a DHCP IP, and won't be reachable if manually configuring the network adapter to 192.168.1.2 or 192.168.10.3.

Same behavior as reported by @dacarrs. A reset done through the reset button then makes the device reachable over at 192.168.1.1 as expected. Doing the exact same steps after this reset results in the same behavior.

I wanted to go back to an AR71xx snapshot I was using until then. Luci wouldn't accept a stripped stock firmware in this test ath79 build, so I recovery+TFTP'd back to stock.


No, @juppin I don't think I missed something, I've been using openwrt/LEDE for years since DDWRT stopped satisfying my needs and never had an issue changing the LAN IP through luci. I've had to use snapshots for a while since I also have an Archer C7 v4 as my main router and WDS AP, and there wasn't any issues installing luci through opkg and then configuring the LAN IP to 192.168.10.1. My 1043ND V2 is a WDS client and provides wired+wireless connectivity to the rest of the house.

If this is isn't a luci issue since it's going through some changes lately, I don't really know what could it be. I just reported my experience so that you and the more experienced people here would know about it.

I didn't try changing the LAN IP through ssh and then rebooting, though.

This sounds like a platform specific bug to me then. LuCI relies on netifd/procd to revert the effective network config to its previous defaults. If that does not work it might be something ath79 specific. Due to a lack of ath79 compatible hardware I cannot really test that though.

Whats your client operating system? Windows? OS X? Linux? Can you watch the status of your local network interface while apply/rollback is running? Is it renegotiating DHCP? Is a manual disabling and reenabling of the network interface helping or did it keep its old 192.168.1.x IP all the time?

W10 Pro 1803 (17134.137, latest patch applied), same behavior on both Chrome 67.0.3396.99 and Firefox 61.0, both 64 bit builds

I remember the network interface disabling itself as if losing connectivity and then reenabling itself as usual when you do a LAN IP change, but then would remain with the dreaded yellow exclamation sign. Checking the network interface status I would then get one of those generic 169.254.xxx.xxx/16 addresses you get when there is no DHCP server running to hand out a proper address.

Disabled then enabled the network interface, no difference. Manually set it to 192.168.10.3/24, web interface unreachable. Tried to SSH in, no response. Trying 192.168.1.2 resulted in the same behavior, no web interface nor SSH response.

ipconfig /release, ipconfig /renew in an admin cmd wouldn't do anything. No DHCP renegotiation. Dead.

This is when I reset and tried these steps again, resulting in the same behavior.


Just to be clear, I didn't do any weird ar71xx -> ath79 upgrade that would screw things up (went back to stock and flashed the provided ath79 factory image), and after resetting on the ath79 build, I had the same behavior.

Thanks for the details, this indeed sounds like some underlying issue with ath79 to me then. This is something that most likely requires a serial console to debug...

... what I mean is that eventually the device should be reachable with either the old or the new ip, a state where the network interface on the router side is misconfigured or not up, should not happen.