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

Hi, I am looking for a good OpenWrt build for the WNDR3700v3 ...

Is anyone creating a distribution for this unfortunate beast?

Any guidance/pointers/ideas on how to get a good OpenWrt build for WNDR3700v3?

Thanks!

Luis

luisd wrote:

@hnyman
Hi, I am looking for a good OpenWrt build for the WNDR3700v3 ...
Is anyone creating a distribution for this unfortunate beast?
Any guidance/pointers/ideas on how to get a good OpenWrt build for WNDR3700v3?

I have no advice for you.
3700v3 is a completely different device than 3700v1/v2/3800, as you have already found out (based on your message on Arokh's thread).

I guess the trunk snapshot is the best thing you can find for the v3. I have not seen much discussion about it in the forum.

Hi Hnyman,

I am having trouble with WDS.  New WDS clients cannot connect.  I have to reboot the wds server to connect.  This is a hassle because if any client disconnects for any reason, it stays disconnected until I reboot the server.  Any suggestions?

By the way, I am using a build based on your build, but not your build.  Thanks for providing the base to make it easy for me to make slight customizations (nfs client and usb printer support).

I have not used WDS for some time, so I have no recent experience on that. But I might test it.

Two questions for clarification:
You have WDS master server (ap), WDS slave server (sta) and then the client devices. And it is the clients that lose connectivity?

How have you configured the 2.4 / 5 GHz connectivity? Are both radios in WDS mode?

(When I used WDS, I used only the 5GHz radio1 for WDS traffic between the routers )

(Last edited by hnyman on 16 Apr 2016, 17:22)

hnyman wrote:

You have WDS master server (ap), WDS slave server (sta) and then the client devices. And it is the clients that lose connectivity?

I have a few WNDR3800's.  One "ap" and a few "sta".  It is the "sta" slaves that lose connectivity, so I have to reboot the "ap" and then all "sta" are immediately able to reconnect.

hnyman wrote:

How have you configured the 2.4 / 5 GHz connectivity?
(When I used WDS, I dedicated the 5GHz radio1 for WDS traffic between the routers and allowed the clients to connect to either router only with the 2.4 GHz radio0)

Mine is the same, except I also allow clients to connect on 5 GHz.  Those clients can only connect to the "sta".

(Last edited by johnthomas00 on 16 Apr 2016, 17:25)

if I remember correctly, there was something regarding dual radios and WDS, which led me to use just one of them for WDS.
dd-wrt forum has this advice: https://www.dd-wrt.com/wiki/index.php/W … eneral_FAQ

EDIT: Sorry, I had the sta/ap wrong first. You might check your message again.
ap is the WDS master
sta is the slave server

(Last edited by hnyman on 16 Apr 2016, 17:23)

hnyman wrote:

if I remember correctly, there was something regarding dual radios and WDS, which led me to use just one of them for WDS.
dd-wrt forum has this advice: https://www.dd-wrt.com/wiki/index.php/W … eneral_FAQ

I will try, thanks

hnyman wrote:

EDIT: Sorry, I had the sta/ap wrong first. You might check your message again.
ap is the WDS master
sta is the slave server

Fixed, thanks again.

I'm experiencing a similar (probably the same) issue with a TP-Link TL-WDR4300 as AP (only the 2.4 GHz radio configured for WDS) and an old TP-Link TL-WR941NDv1 as STA (with a wired client behind it), both running self built trunk snapshots (r49065). It varies quite a bit how long the connection survives, sometimes just a few minutes, sometimes several days, but once it goes down, it won't recover. Rebooting the STA rarely helps, rebooting the WDS AP always helps - even when the STA is definately dead, the connection is still listed as active on the AP, while both the STA (TL-WR941NDv1) and the client behind it remain inaccessible from the AP side of the network.

Trunk snapshots from late last year were reliable (I think, the STA isn't in use every day, so it took a while to notice and the time to failure varies a lot), snapshots since (around~) early this year trigger the problem for me (not just with r49065, but also several before that one). My current suspicion is the hostapd/ wpa_supplicant/ wpad update from v2.3 (2015-03-25 plus security fixes) to 2016-01-15, as I've been running r48185 for quite a while, without remembering any related issues. I did replace package/network/services/hostapd/ with the version from r48345 (transplanted into r49166) on the STA (TL-WR941NDv1) for testing (no improvement), my next approach will be doing the same on the AP side (TL-WDR4300).

(Last edited by slh on 16 Apr 2016, 22:50)

slh wrote:

I'm experiencing a similar (probably the same) issue . . .

Sounds the same to me.  I don't monitor as closely as you do so was not confident enough to make some claims (e.g. still listed as active on the AP).  I also agree with prior stability.  I may try to find an old stable version.

Hnyman, the dual radio solution did not work.  I no longer allow clients (except WDS clients) to connect on the 5 Ghz channel and I still experience the issue.  My temporary solution is a python script which reboots the WDS server if a WDS client is down for a few times in a row.

I filed a bug report here (let's continue the conversation there until there is a solution): 
https://dev.openwrt.org/ticket/22228

johnthomas00 wrote:

I filed a bug report here (let's continue the conversation there until there is a solution): 
https://dev.openwrt.org/ticket/22228

That is good. My build has just the standard radio components, so there should be nothing build-specific. Better to have a generic bug about it.

Just a very first impression, as it's too early to confirm it for sure, I have reverted to wpad v2.3 on the WDS AP (TL-WDR4300, trunk r49065, wpad 2015-03-25-2) about 20h ago and the WDS connection to the TL-WR941NDv1 (trunk r49166, wpad-mini 2015-03-25-2) is still working so far (normal STAs and this single WDS STA are connecting to the WDS AP).

(Last edited by slh on 17 Apr 2016, 22:07)

slh wrote:

Just a very first impression, as it's too early to confirm it for sure, I have reverted to wpad v2.3 on the WDS AP (TL-WDR4300, trunk r49065, wpad 2015-03-25-2) about 20h ago and the WDS connection to the TL-WR941NDv1 (trunk r49065, wpad-mini 2015-03-25-2) is still working so far (normal STAs and this single WDS STA are connecting to the WDS AP).

If possible, could you report this on the ticket?
https://dev.openwrt.org/ticket/22228
You sound much more credible and specific than I do and that would likely help the developers fix this in trunk.

johnthomas00, did you have a chance to test or confirm this by reverting to wpad/ wpad-mini 2015-03-25-2 on your systems?

With wpad reverted to 2015-03-25-2 on the WDS-AP, my WDS link has now been reliable for a full week.

slh wrote:

johnthomas00, did you have a chance to test or confirm this by reverting to wpad/ wpad-mini 2015-03-25-2 on your systems? With wpad reverted to 2015-03-25-2 on the WDS-AP, my WDS link has now been reliable for a full week.

Thanks, I have not.  How do I revert wpad like that?  Do I change a setting in .config?  Do I run a git command?

By the way, I am having some success with pinging each STA and the AP every two minutes.  I am still testing.  I built a python script to reboot the AP if one was down for 15 minutes.  The script tests every two minutes.  Funny thing is, now the STAs are not going down.  It is still too soon for me to be confident.  I'll report back if I can get them all to stay up for 5 or more days.

I'll revert wpad if this does not work and I would like to learn, so if easy, please do share how to revert please.

Thanks slh!!

Following buildroot.exigence, the following should happen after step 3 and before 4 of the afforementioned howto.

Just make a copy of your git clone (cp -a openwrt openwrt-old), change into that directory (cd openwrt-old) and reset it to r48345 (git checkout f8f3907e6f5174ce651a835687ffdee99f0e46a1); "head -n12 package/network/services/hostapd/Makefile" should now confirm "PKG_VERSION:=2015-03-25" and "PKG_REV:=8278138e679174b1ec8af7f169c2810a8888e202".

Now you have your current trunk checkout under openwrt, and an older one (the last one with hostapd 2015-03-25, well, technically not the very last one, but the last change affecting hostapd 2015-03-25, before it got bumped to 2016-01-15) under openwrt-old.

Delete hostapd from your current trunk/ HEAD (rm -r openwrt/package/network/services/hostapd/) and copy the older hostapd version (the whole hostapd directory) into your trunk/ HEAD checkout (cp -a openwrt-old/package/network/services/hostapd openwrt/package/network/services/).

Assuming you're running a relatively recent (~this year) of hnyman's builds for the WNDR3700/WNDR3800, it's probably best to borrow his build config from https://www.dropbox.com/sh/t52c02rm20y8x9p/khFGAJu3gc (if you apply his device specific patches would be a matter of preference, they're not relevant to this particular problem). Copy trunk-r49218-20160423/WNDR3700-trunk-r49218-20160423-1259.diffconfig to openwrt/.config (the top-level directory of your modified OpenWrt trunk, thereby renaming the file to ".config" (leading dot)). For the very purpose of this test, his WNDR3700/WNDR3800 specific patches aren't particularly relevant (especially as you don't even need to actually flash your self-built firmware, but only need the built wpad ipk package). Follow a slightly different procedure for step 4 of buildroot.exigence, by just running "make defconfig" and "make oldconfig" before going straight to "make prereq" and "make" (or "make -j$(($(getconf _NPROCESSORS_ONLN) * 2))" to get leverage of all your CPU cores).

While you could install the freshly built firmware snapshot, you could also just replace the wpad package of your currently running firmware (wpad is a relatively standalone binary, so this has a rather high chance of success - if your snapshot isn't too old; technically wpad from more or less any relatively current ar71xx build should do) as this would be safer (but this needs roughly 650-700 KB free space on your flash). For this, you'd just copy (scp) the freshly built bin/ar71xx/packages/base/wpad_2015-03-25-2_ar71xx.ipk to /tmp/ of your router and use opkg to install it - this has the advantage that there is a lower risk of bricking your router (at worst wlan wouldn't work) and that you can get rid of this patched wpad package via firstboot (factory reset).

While this short guide should cover all relevant steps, it does assume you being roughly familiar with building OpenWrt.
<insert $disclaimer about $no_warranties>, not tested on a Netgear WNDR3700/WNDR3800 or this particular firmware build, but unpatched OpenWrt trunk (r49199) on a TP-Link TL-WDR4300v1, TL-WDR3600v1, TL-WR1043NDv1 and TL-WR941NDv1 with my own, targetted to my needs, config instead.
Yes, there are more elegant ways to use git - but I'm describing it in an easy and (hopefully) fail-safe way here (openwrt-old is only used as source for the older hostapd directory, it can be deleted after you copied it).

(Last edited by slh on 25 Apr 2016, 03:52)

Heads up in advance: r49252 breaks things in a nasty way for anybody who does trunk sysupgrade with settings preserved.

Bug report: https://dev.openwrt.org/ticket/22271

r49252 breaks things in a major way in a sysupgrade with settings preserved, as dnsmasq does not start and thus DNS and DHCP do not work.

If a router is flashed with a new firmware with revision >= 49252, it will expect to find user "dnsmasq" in /etc/password and /etc/shadow as well as group "dnsmasq" in /etc/group. If those are not found, dnsmasq does not start and all connectivity breaks down.

root@OpenWrt:~# logread | grep dnsm
Wed Apr 27 11:27:52 2016 daemon.crit dnsmasq[2753]: unknown user or group: dnsmasq
Wed Apr 27 11:27:52 2016 daemon.crit dnsmasq[2753]: FAILED to start up
...
Wed Apr 27 11:28:11 2016 daemon.info procd: Instance dnsmasq::instance1 s in a crash loop 6 crashes, 0 seconds since last crash

I fixed my own router by manually copying /rom/etc/passwd, /rom/etc/shadow and /rom/etc/group to /etc

(Last edited by hnyman on 27 Apr 2016, 12:15)

slh wrote:

Following buildroot.exigence, the following should happen after step 3 and before 4 of the afforementioned howto.
<snip>

SLH, thank you kindly for the detail guidance.  I may do this.

I am having good success with pinging each STA and the AP every two minutes.  I built a python script to reboot the AP if any was down for 15 minutes.  The script tests every two minutes.  Funny thing is, now the STAs are not going down.  The AP has been up for almost 6 days and everything is connecting fine.

This is obviously a hack, not a solution.  Hopefully the developers will have some time to look at this at some point.  I am happy to test. 

I believe hnyman's instructions show how to build Chaos Calmer.  I may do that.  Calmer sounds good at the moment.

Thanks again!

hnyman wrote:

Heads up in advance: r49252 breaks things in a nasty way for anybody who does trunk sysupgrade with settings preserved.

Bug report: https://dev.openwrt.org/ticket/22271

r49252 breaks things in a major way in a sysupgrade with settings preserved, as dnsmasq does not start and thus DNS and DHCP do not work.

If a router is flashed with a new firmware with revision >= 49252, it will expect to find user "dnsmasq" in /etc/password and /etc/shadow as well as group "dnsmasq" in /etc/group. If those are not found, dnsmasq does not start and all connectivity breaks down.

root@OpenWrt:~# logread | grep dnsm
Wed Apr 27 11:27:52 2016 daemon.crit dnsmasq[2753]: unknown user or group: dnsmasq
Wed Apr 27 11:27:52 2016 daemon.crit dnsmasq[2753]: FAILED to start up
...
Wed Apr 27 11:28:11 2016 daemon.info procd: Instance dnsmasq::instance1 s in a crash loop 6 crashes, 0 seconds since last crash

I fixed my own router by manually copying /rom/etc/passwd, /rom/etc/shadow and /rom/etc/group to /etc

I added the following to /etc/rc.local :

# fix for r >= 49252 breakage (dnsmasq gets own group)
cp /rom/etc/passwd /etc/passwd
cp /rom/etc/shadow /etc/shadow
cp /rom/etc/group /etc/group

just before issuing "sysupdate -v ./MY_IMAGE_FILE" and deleted them after the reboot, which seems to have worked (as LUCI complaint about the root password not being set yet). This might be a bit easier on newbies like me...

Best Regards & many thanks
        M.

hnyman wrote:

Heads up in advance: r49252 breaks things in a nasty way for anybody who does trunk sysupgrade with settings preserved.

Bug report: https://dev.openwrt.org/ticket/22271

The bug has been fixed by r49276.
Sysupgrade should again work normally.

(Last edited by hnyman on 1 May 2016, 12:50)

FYI, I am unable to duplicate the WDS bug in Chaos Calmer.  Also, I was able to "upgrade" to Chaos Calmer from Trunk with the same settings files without issue (note: I use access point features only, not router functions).

Also, Hnyman, please let us know if you start an https://www.lede-project.org/ based setup similar to this.

CC and trunk are practically identical for settings. Switching between them is easy.

johnthomas00 wrote:

Also, Hnyman, please let us know if you start an https://www.lede-project.org/ based setup similar to this.

Most likely I will start publishing LEDE builds soon, as I already have the build. My own router is already running a LEDE build, but there were problems with package source repos, so I did not upload the build. Those problems should be fixed already by Jow. I will likely upload the build next week.

As far as I see, a large part of the active Openwrt core developers splitted off to be LEDE, so I guess that it will get more development activity than the traditional Openwrt.

EDIT: LEDE build r98 uploaded.

(Last edited by hnyman on 8 May 2016, 21:45)

hi hnyman, does one simply perform a sysupgrade from openwrt to lede?  is it safe to keep openwrt setting sysupgrade?  or start fresh?  thanks for confirming.

Currently the LEDE spin-off is practically identical to DD trunk. Same settings etc. You can use normally sysupgrade to switch between builds.

Hello hnymn:
Thank you for the rock steady build!!!
I'm having a bit of trouble with the adblock script, and receive the following error:

Wed May 11 04:18:45 2016 user.notice adblock[3719] info : adblock service started due to 'ifup' of 'wan' interface
Wed May 11 04:18:46 2016 user.notice adblock[4359] error: outdated adblock configuration found, please use latest version from '/etc/adblock/adblock.conf.default', rc: 125
Wed May 11 04:18:46 2016 user.notice adblock[4359] info : domain adblock processing failed (1.1.2, , 11.05.2016 04:18:46)

I have a WNDR 3800 with LEDE Designated Driver r98. I was also experiencing this with WNDR3800-trunk-r49295 build.
Also, I could not find any discussion in this topic area about DNSSEC, have you considered adding this to the build?
Thank you,
GethroC