OpenWrt Forum Archive

Topic: Build for WNDR3700/WNDR3800

The content of this topic has been archived between 9 Jul 2013 and 6 May 2018. Unfortunately there are posts – most likely complete pages – missing.

hnyman wrote:
nieroster wrote:

I use "Access Point (WDS)". What is station mode?

Oh, you are using WDS. The name might then also be caused by the WDS mode selection. With WDS you likely have one router as the AP and the other(s) router(s) as STA, right?
https://wiki.openwrt.org/doc/uci/wirele … ce_options
https://wireless.wiki.kernel.org/en/use … tion/modes

It is quite possible that the difficulties arise just in one of the various wifi modes, so when reporting that wifi fails, please mention the operational mode with details. It quite possible that there would be a problem with WDS that does not materialise for normal (non-WDS) users, although I don't remember seeing anything WDS-related lately.


Ah, all good points. I was running the router in non-WDS non-STA mode, at least this is what I believe. Will look more closely once I reflash to >= r1512.

Best Regards
        M.

I am having the same problem of the 2.4GHz network disappearing on lede-r1512-20160905-tcpdump. I am not using WDS or anything else, just a common home wireless router configuration.
5GHz works without a problem.

The problem appeared when I upgraded my router to r1512, build r1444 works fine. Sadly there was nothing different on the kernel or on the system log.

(Last edited by lagonauta on 6 Sep 2016, 22:38)

lagonauta wrote:

I am having the same problem of the 2.4GHz network disappearing on lede-r1512-20160905-tcpdump. I am not using WDS or anything else, just a common home wireless router configuration.
5GHz works without a problem.

Does the network disappear from the clients' visibility? Or do they not just get any connectivity?  Does the problem affect just one device or do all devices lose the 2.4 GHz wifi?

There is nothing build-specific in my build's wifi components (except a config option to reduce WPA error message verbosity), so the problems are likely related to mac80211 & kernel changes, either for all devices or for ar71xx platform. You might file a bug at the LEDE bug tracker: https://bugs.lede-project.org/

Yeah, I will probably file a bug at LEDE.
Yes, the network disappear from all clients, only 5GHz is visible and connectable (obviously only on those devices that support 5GHz networks)
For some reason the web interface showed that the interface was not only active, but had some clients connected (smartphones). Sadly I did not check all smartphones if they still had connectivity, but mine didn't.

hnyman wrote:

But it makes sense to rebuild all settings every now and then. I do a firstboot (or sysupgrade -n) maybe once per month.

How exactly does one do a "firstboot" and where exactly would I run the sysupgrade -n command?

Thanks!

(Last edited by ZzBloopzZ on 8 Sep 2016, 16:13)

ZzBloopzZ wrote:
hnyman wrote:

But it makes sense to rebuild all settings every now and then. I do a firstboot (or sysupgrade -n) maybe once per month.

How exactly does one do a "firstboot" and where exactly would I run the sysupgrade -n command?

Thanks!

Hi ZzBloopzZ,

I believe firstboot is a command you can issue at your routers command prompt (after logging into it via ssh). It basically wipes the one partition openwrt/lede use for persistent variable storage. If this partition is empty you will only see the default files from the read-only /rom part of the firmware, any changes you make (for non tmpfs backed directories) will typically create overlay files to appear in that partition.

About sysupgrade -n
If you use the command line to upgrade your router the procedure you would follow is something like:
1) copy the new firmware image to the /tmp folder on your router:
scp WNDR3700v2-lede-r1512-20160905-1601-sqfs-sysupgrade.bin root@192.168.1.1:/tmp

2) log into the router:
ssh root@192.168.1.1

3) change into the folder containing the new firmware image:
cd /tmp

4) actually initiate the firmware upgrade (the router will reboot after it is done):
sysupgrade ./WNDR3700v2-lede-r1512-20160905-1601-sqfs-sysupgrade.bin

If called in that fashion the firmware upgrade will try to keep all your configuration files intact over the re-flash and reboot, so that your router's name, BSIDs passwords and what not will just stay as you configured it (what unfortunately is not conserved over the re-flash are additional packages you might have installed manually, you need to re-install these manually after each re-flash).
If you use "sysupgrade -n ./WNDR3700v2-lede-r1512-20160905-1601-sqfs-sysupgrade.bin" instead the router will not keep your existing configuration files (but wipe the persistent variable data partition) and hence will need to be reconfigured from scratch. But see https://wiki.openwrt.org/doc/howto/generic.sysupgrade and https://wiki.openwrt.org/doc/techref/sysupgrade for further reference...

Best Regards

Dear moeller,

Thank you for the useful and detailed post. I really appreciate you writing all that out for me. I had searched the wiki before asking but it was not clear to me, but now I got it 100%.

One last question, does firstboot and sysupgrade -n basically do the same thing? Like since I want to update my firmware I would just flash via sysupgrade -n... or do I need to run the firstboot command after it is finished flashing via sysupgrade -n command?

Thank You!

(Last edited by ZzBloopzZ on 8 Sep 2016, 17:09)

Yes, firstboot wipes the r/w partition with all changes, settings etc., so it reverts the router to the situation like the previous firmware upgrade would have been done without preserving settings. So, doing sysupgrade without preserving settings leads to the same situation as firstboot.

The background is that firmware gets written into a read-only partition /rom and all your settings & later changes are written to a read/write partition ( /overlay ) , which is shown as an overlay on top of the rom-part in a live router. Just wiping the overlay part (e.g. with firstboot) reverts the router into pristine condition as it would have been just flashed.

In practice, Luci runs "firstboot" for Reset menu selection, and for sysupgrade Luci runs "sysupgrade" with/without "-n" depending on your selection of keeping settings when upgrading.

If you use Luci for sysupgrade , just deselect the "Keep settings" tickbox to start from a clean slate.

Just successfully upgraded to lede-r1535. The GUI/Luci appears to be working MUCH smoother and more responsive. Granted I came from a build that was from September 2015.

Last question, how can I disable the DHCP of IPv6 addresses on my LAN? I tried changing few settings related to IPv6 to disabled and then restarted router but no luck.

Thanks!

Also, special thank you to hnyman for all your continuous effort for maintaining these old routers. I gave up on the wireless on these over a year ago and use a Ubiquity AP. Everything is dandy. :c)

(Last edited by ZzBloopzZ on 9 Sep 2016, 04:43)

Is it possible to flash the WNDR3800 build to my WNDR3800CH? Normally I don't with other builds but i'm trying to move to LEDE now.

(Last edited by SgtFeces on 9 Sep 2016, 08:16)

SgtFeces wrote:

Is it possible to flash the WNDR3800 build to my WNDR3800CH? Normally I don't with other builds but i'm trying to move to LEDE now.

I don't think so but I am not sure. CH has different board ID so I think that the OEM flash logic will not accept the regular file. A separate firmware version is created for CH, but my build scripts remove that and the -NA version before uploading the binaries. You should probably take the LEDE snapshot for CH from https://downloads.lede-project.org/snap … x/generic/

ZzBloopzZ wrote:

Last question, how can I disable the DHCP of IPv6 addresses on my LAN? I tried changing few settings related to IPv6 to disabled and then restarted router but no luck.

Well, that has nothing to do with my build by itself, so you might find better answers if you ask that in a separate thread. Docs in https://wiki.openwrt.org/doc/uci/network6

But my guess is: in /etc/config/network remove the "ip6assign" option for lan, in /etc/config/dhcp set dhcpv6 and ra to 'disabled' for lan. (Not sure if you meant just DHCP or also RA, but the advice disables both. See https://wiki.openwrt.org/doc/uci/networ … ent_dhcpv6 ) Optionally also disable the odhcpd service.

hnyman wrote:

I don't think so but I am not sure. CH has different board ID so I think that the OEM flash logic will not accept the regular file. A separate firmware version is created for CH, but my build scripts remove that and the -NA version before uploading the binaries. You should probably take the LEDE snapshot for CH from

Thank you for the swift reply. I'll move on over there and try to replicate the builds here in my VM later. smile

SgtFeces wrote:

Thank you for the swift reply. I'll move on over there and try to replicate the builds here in my VM later. smile

If you compile your own version, then you could just use my scripts (read advice in post #2 of this thread) and just remove the one line at the end of updateNmake.sh where the CH, NA and Mac versions are removed. As they are rather rare and I personally have no device, I remove those versions. Comment or remove that line and you are set:
"rm -f $BinDir/*-NA.img $BinDir/*3800ch* $BinDir/*wndrmac*"

(Last edited by hnyman on 9 Sep 2016, 08:55)

Now it happened again, WiFi became non operational.  I noticed because the music stopped playing:

Sat Sep 10 12:22:48 2016 kern.info kernel: [233254.312267] device wlan1.sta1 left promiscuous mode
Sat Sep 10 12:22:48 2016 kern.info kernel: [233254.317453] br-lan: port 4(wlan1.sta1) entered disabled state
Sat Sep 10 12:22:53 2016 kern.info kernel: [233259.797124] device wlan1.sta1 entered promiscuous mode
Sat Sep 10 12:22:53 2016 kern.info kernel: [233259.815349] br-lan: port 4(wlan1.sta1) entered forwarding state
Sat Sep 10 12:22:53 2016 kern.info kernel: [233259.821415] br-lan: port 4(wlan1.sta1) entered forwarding state
Sat Sep 10 12:22:55 2016 kern.info kernel: [233261.814579] br-lan: port 4(wlan1.sta1) entered forwarding state

Although the LEDs showed the WiFi as active it could not bee seen by any client. I pressed the WiFi button to disable WiFi and again to reenable it. Now it is working like usual.

I am using LEDE Reboot r1519

cheers,
nieroster

moeller0 wrote:
hnyman wrote:
nieroster wrote:

I use "Access Point (WDS)". What is station mode?

Oh, you are using WDS. The name might then also be caused by the WDS mode selection. With WDS you likely have one router as the AP and the other(s) router(s) as STA, right?
https://wiki.openwrt.org/doc/uci/wirele … ce_options
https://wireless.wiki.kernel.org/en/use … tion/modes

It is quite possible that the difficulties arise just in one of the various wifi modes, so when reporting that wifi fails, please mention the operational mode with details. It quite possible that there would be a problem with WDS that does not materialise for normal (non-WDS) users, although I don't remember seeing anything WDS-related lately.


Ah, all good points. I was running the router in non-WDS non-STA mode, at least this is what I believe. Will look more closely once I reflash to >= r1512.

Best Regards
        M.

Okay, so I flashed your otherwise excellent "Reboot (HEAD, r1535)+ build on my wndr3700v2 first with sysupgrade and had the same issue, both the 2.4 and the 5.0 GHz radio seem to auto-disable after some time (clients are a nexus 4, 2 nexus 5X, one amazon fire) and it will not come back by itself, executing "wifi" on the router will enable the radios again (for some time). Interestingly, running firstboot and manually re-creating my configuration (minus a few firewall items that seem to be not required anymore (or ever)) also results in disappearing radios...

I also still get weird resets:

root@nacktmulle:~# cat /sys/kernel/debug/ieee80211/phy0/ath9k/reset ; cat /sys/kernel/debug/ieee80211/phy1/ath9k/reset
    Baseband Hang:  0
Baseband Watchdog:  0
   Fatal HW Error:  1
      TX HW error:  0
 Transmit timeout:  0
     TX Path Hang:  0
      PLL RX Hang:  0
         MAC Hang: 85
     Stuck Beacon: 2881
        MCI Reset:  0
Calibration error:  0
Tx DMA stop error: 116
Rx DMA stop error:  0


    Baseband Hang:  0
Baseband Watchdog:  0
   Fatal HW Error:  0
      TX HW error:  0
 Transmit timeout:  0
     TX Path Hang:  0
      PLL RX Hang:  0
         MAC Hang:  1
     Stuck Beacon: 3252
        MCI Reset:  0
Calibration error:  0
Tx DMA stop error: 89
Rx DMA stop error:  1

Unfortunately no "smoking gun" in the log or the kernel message buffer.

Best Regards
        M.

Hi Hannu,

it seems the issue is already supported (see https://bugs.lede-project.org/index.php … task_id=34 and https://bugs.lede-project.org/index.php … ;sort=desc and ) Since I did not encounter the issue with r1398_20160822, but with 1497_20160904, r1512_20160905, and r1535, my totally unscientific gut feeling points to the ath9k powersave related commits around https://github.com/lede-project/source/ … 61402da3aa ... (but this is really just because a failure to wake up from a normal powersave mode might lead to the quiet disappearing of the radios without any error messages, again this is total conjecture, all I know between August 22nd and September 4th something changed)
        Now all I need is my build machine being replaced (motherboard failure) so I can go test this hypothesis (by either git bisecting or by selectively reverting the power save commits)... @hnyman do you still have ready made intermediate wndr3700v2 sysupgrade images from the period between AUgust22nd and September 4th, you could post somewhere (which would be faster than waiting for my replacement machine to arrive...)?

Best Regards
        M.

LEDE bug report #166 sounds similar as the recent wifi troubles that some have experienced.
https://bugs.lede-project.org/index.php … ask_id=166

I had the 2016-08-01, 2016-08-29 and 2016-08-31 builds handily available and they are now in Dropbox. But I do not have builds from mid-August.

EDIT:
I re-compiled and uploaded lede-r1442-20160825-8859102. That is after the kernel bump to 4.4.19 but before the powersave fixes. Note that the timestamps of the build reflect today instead of 25 August.

(Last edited by hnyman on 11 Sep 2016, 19:21)

Hi Hnyman,

hnyman wrote:

LEDE bug report #166 sounds similar as the recent wifi troubles that some have experienced.
https://bugs.lede-project.org/index.php … ask_id=166

I had the 2016-08-01, 2016-08-29 and 2016-08-31 builds handily available and they are now in Dropbox. But I do not have builds from mid-August.

EDIT:
I re-compiled and uploaded lede-r1442-20160825-8859102. That is after the kernel bump to 4.4.19 but before the powersave fixes. Note that the timestamps of the build reflect today instead of 25 August.

Than you very much, or kiitos? I just flashed r1442 and will report how that works. Typically the radios disappear quite quickly, so by tomorrow I should know (well work might get in the way, so I might have to see until tomorrow evening). I do expect failures to show up in the next hour or so in any case, so if it takes until tomorrow that would already be great wink. Assuming r1442 works reliably I will then move to the next build in time (2016-08-29), but let's first see how 1442 actually holds up...
        Once I actually know a bit more about when the issue was introduced I plan to report this to the LEDE tracker, they do know about similar issues (#166) so just posting a me too without additional information seems useless...


Best Regards
        M.

moeller0 wrote:

I just flashed r1442 and will report how that works.
...
        Once I actually know a bit more about when the issue was introduced I plan to report this to the LEDE tracker, they do know about similar issues (#166) so just posting a me too without additional information seems useless...

Actually, when there is just the initial report that has not been confirmed by anybody else, even the "me too" has value, as it tells that somebody else sees the same problem. #166 sounds pretty much like your issue and the router mentioned is rather similar. So, please report your findings there, even if they are a bit vague. Narrowing the regression range would naturally be great.

(Last edited by hnyman on 12 Sep 2016, 09:14)

hnyman wrote:
moeller0 wrote:

I just flashed r1442 and will report how that works.
...
        Once I actually know a bit more about when the issue was introduced I plan to report this to the LEDE tracker, they do know about similar issues (#166) so just posting a me too without additional information seems useless...

Actually, when there is just the initial report that has not been confirmed by anybody else, even the "me too" has value, as it tells that somebody else sees the same problem. #166 sounds pretty much like your issue and the router mentioned is rather similar. So, please report your findings there, even if they are a bit vague. Narrowing the regression range would naturally be great.

Hi Hnyman,

okay I added a comment to #166 giving all the detail I have available ATM. It seems that r1442 is not affected, at least it survived 12 hours testing so far without loosing the radios, I will continue testing until this evening before switching to r1462...

Best Regards
        M.

@moeller0:
Some details for debugging:
(Assuming that the reason is in the mac80211/ath9k wifi driver itself)
https://git.lede-project.org/?p=source. … 11;hb=HEAD

r1442-20160825 / 8859102 contains the early changes upto "ath9k: Set ATH9K_STATION_STATISTICS..."
r1462-20160829 / e9c5177 contains one new wifi change:     "ath9k: revert temperature compensation support..."
r1476-20160831 / f29774b build contains no wifi changes but is the last build before the powersave changes starting at r1481, but 1477-1480 have no impact on my build, so r1476 serves ok.)
r1497-20160904 contains most of the powersave changes.

The earliest mentioned problematic build (by nieroster) was r1497-20160904

You might try r1476 next. r1462 has just one change that removes new functionality, so I doubt if that could be the culprit.

(Last edited by hnyman on 12 Sep 2016, 13:16)

hnyman wrote:

@moeller0:
Some details for debugging:
(Assuming that the reason is in the mac80211/ath9k wifi driver itself)
https://git.lede-project.org/?p=source. … 11;hb=HEAD

r1442-20160825 / 8859102 contains the early changes upto "ath9k: Set ATH9K_STATION_STATISTICS..."
r1462-20160829 / e9c5177 contains one new wifi change:     "ath9k: revert temperature compensation support..."
r1476-20160831 / f29774b build contains no wifi changes but is the last build before the powersave changes starting at r1481, but 1477-1480 have no impact on my build, so r1476 serves ok.)
r1497-20160904 contains most of the powersave changes.

The earliest mentioned problematic build (by nieroster) was r1497-20160904

You might try r1476 next. r1462 has just one change that removes new functionality, so I doubt if that could be the culprit.

Hi hnyman,

excellent, so I will try r1476 next, assuming that r1442 survives my ~24 hour test...

Best Regards
        M.

@moeller0:

I went back to r1442, no problems until now (almost 24h)!

cheers,
nieroster

moeller0 wrote:
hnyman wrote:

@moeller0:
Some details for debugging:
(Assuming that the reason is in the mac80211/ath9k wifi driver itself)
https://git.lede-project.org/?p=source. … 11;hb=HEAD

r1442-20160825 / 8859102 contains the early changes upto "ath9k: Set ATH9K_STATION_STATISTICS..."
r1462-20160829 / e9c5177 contains one new wifi change:     "ath9k: revert temperature compensation support..."
r1476-20160831 / f29774b build contains no wifi changes but is the last build before the powersave changes starting at r1481, but 1477-1480 have no impact on my build, so r1476 serves ok.)
r1497-20160904 contains most of the powersave changes.

The earliest mentioned problematic build (by nieroster) was r1497-20160904

You might try r1476 next. r1462 has just one change that removes new functionality, so I doubt if that could be the culprit.

Hi hnyman,

excellent, so I will try r1476 next, assuming that r1442 survives my ~24 hour test...

Best Regards
        M.

Okay so it looks like r1442 survived for almost 24 hours, when I stopped the experiment by flashing r1476. Let's see how long that survives...

Best Regards
       M.