Build for WNDR3700v1/v2 / WNDR3800 (discontinued)

Great! Thanks a lot, that looks much better :wink:

Best Regards

Hi @hnyman regarding your WNDR3700/3800 and R7800 build I want to ask which queueing dicipline and script you use for SQM?

On my WNDR4300 I use cake and a piece of cake but what I’m interested in is if you use the same or something different and what your experience is with the setup you have and the other options

Thanks in advance.

I use the SQM default = simple.qos. I don't usually burden my network connection to the extreme, so that is good enough.

Cake is also ok and performs well.

(Additionally, the dual-core processor in R7800 does not quite like all the qdics used by simple.qos. e.g. HTB. See https://github.com/tohojo/sqm-scripts/issues/48 )

But the "best qdisc" highly depends on your use case. ISP line speed, your CPU (single/multi-core, calculation power), wired/wireless clients, single/multiple heavy user client(s), preference of latency/throughput etc.

I strongly urge you to test various SQM strategies e.g. with flent. During active cake development phase two years ago I made a comparison of several SQM qdiscs with WNDR3800 and noted that depending on the use case and preferences, the best SQM script/qdisc could either be simple, cake or hfsc). See https://github.com/tohojo/sqm-scripts/pull/26#issuecomment-185833432 for my results in early 2016. The situation has surely change since then, as we are now at kernel 4.9/4.14 and cake has seen lots of development. But still the same holds: test with your own normal use.

But cake is no magic bullet and always the best. (If it would be, it would surely have been upstreamed into Linux kernel by now.)

Thank you for your quick response.

I have to say I also don’t burden my connection a lot and there are no heavy users on the network.

The connection is a coaxial cable connection 40/4 Mbit so it’s also not that big.

Before I used cake on both the download and the upload the bufferbloat was huge like F rating on dslreports, now its A/A+.

I will to try as suggested the other qdisks and see if I see a difference or not.

The build LEDE build I use is the 17.01 stable branch so I’m using a 4.4 kernel. Which also makes a difference compared to the Master branch as you said with the 4.9/4.14 kernel.

owrt1806-r6910-323285ac00-20180516

First 18.06 build.

I will stop compiling "stable" for 17.01 unless there are major fixes, and will be testing 18.06 stable branch instead.

1 Like

For what it's worth, there's a problem with /etc/opkg/distfeeds.conf in that first build. Opkg tries to download from a path that doesn't exist on openwrt's server.

I replaced the http://downloads.openwrt.org/releases/18.06-SNAPSHOT/ part with http://downloads.lede-project.org/snapshots/ as a temporary fix.
Aside from that, it's been running great for a whole 10 minutes :wink:

Sure. the 18.06 phase1 buildbot is crunching the images and SDKs, and packages will start to get compiled next. Packages will appear maybe in 1-2 days for opkg. (Packages should have actually materialised by now, but the phase2 packages 18.06 buildbot has been configured wrongly. It looks for "lede-" SDKs based on old lede-17.01 config, while 18.06 is branded "openwrt-". I reported that to jow a few hours ago, so hopefully the config gets fixed and packages start getting compiled.)

Well, it is currently rather equal to master, so it should run just fine.

In that case, care to help me with my ZBT-1326 build? :smiley:

owrt1806-r6917-8948a78862-20180520

18.06 buildbot signing keys have been added to the keyring today, so the build is able to normally download 18.06 packages with opkg.

As far as I can tell, collectd or rrdtool is broken in both r6910 and r6917. I can't find any error in syslog but when I go to statistics -> graphs, there's no graph there although several modules are enabled and corresponding collectd-mod-xxx packages seem installed. It used to work with LEDE builds and the same configuration. Can you have a look whenever you have some spare time.

Thanks

works for me.
something wrong inyour own router?

image

It was indeed on my side. I deleted my old config file that I carried from openwrt -> LEDE -> openwrt and that's all fixed. No big deal, thanks again.

Hi, I've been using this build for at least a couple of years and twice a year I update it. Worked well so far.

On another thread I read that 4/32 devices show issues with 18.06 because the firmware size and the memory use increased.
Is it also your experience? Some people cannot even make the firmware for the 4 MB flash...

In my case I ask because I noticed that in some cases I already experience a sort of black out of the internet connection when the number of connections gets to about 600, even if the CPU and the memory use are not near the max (40% used CPU, 20-30% free memory, basically the usual value, and 1.5 system load). QoS is already "cake/piece of cake" set to 39500/3900 Kbps for my 40000/4000 cable connection.
Mostly (but not always, and not only) it happens when I start my Windows 10 or an OS X laptop: there is a spike in connections and internet stops working for a couple of minutes.

Now that I think about it, I experienced it also with the original Netgear firmware, so maybe it's something else and I have to investigate further, but the question stands: will these routers (3700v2, 3800) hold well with the 18.06 installed?

As always, thanks hnyman for the build and everyone else for the help you gave hnyman to improve it!

I have no 4/32 devices. They are mostly antique stuff. They started to get troublesome with 17.01 and likely even more with 18.06. (The 32 MB RAM is the crucial limitation there, as kernel memory requirement steadily creeps up.)

WNDR3700 is 8/64, WNDR3700v2 is 16/64 and WNDR3800 is 16/128 device, so they are still well suited for 17.01, 18.06 and the current master.

You have left much too small extra bandwidth margins, especially on the upload side, I think. WNDR3700v2 shapes some 85000/10000 Kbps with my own connection, so your problems are not about its basic performance. Of course, if you use router-based VPN, then its encryption will cause additional load.

In general WNDR3700v2 and the whole family is still ok with 18.06.

You are right, I remembered wrongly: I set the limits to 39000/3800. Now I set 38000/3800 that is 95% of the max bandwidth.
Let's see if it improves.

Hi @hnyman I got a quick question about the firmware you build for 18.06.

I know you build on Ubuntu as well when I try to compile I get the following warnings, did you also got these? If so could you put me in the right direction how to solve the warnings?

WARNING: Makefile 'package/utils/busybox/Makefile' has a build dependency on 'libpam', which does not exist
WARNING: Makefile 'package/network/utils/curl/Makefile' has a dependency on 'libgnutls', which does not exist
WARNING: Makefile 'package/network/utils/curl/Makefile' has a dependency on 'libopenldap', which does not exist
WARNING: Makefile 'package/network/utils/curl/Makefile' has a dependency on 'libidn', which does not exist
WARNING: Makefile 'package/network/utils/curl/Makefile' has a dependency on 'libssh2', which does not exist
WARNING: Makefile 'package/boot/kexec-tools/Makefile' has a dependency on 'liblzma', which does not exist
WARNING: Makefile 'package/network/services/lldpd/Makefile' has a dependency on 'libnetsnmp', which does not exist

Thanks in advance.

Normally there are no warnings.
I got those warnings once, when respective packages were introduced in feeds.

It sound like you have not run the feeds "install" script lately. There are two steps and you need both feeds update and feeds install.

(The install command registers new packages into config database)

Found the issue. The cable modem from the provider had "IP flood protection" enabled and apparently starting Chrome with 20 tabs was enough to trigger the protection.

master-r7161-c8677ca-20180609

Fixed factory image.

I noticed that the TFTP recovery flashing routine in WNDR3800 did not accept my factory images any more. After small testing I have noticed that the reason is a too long version string in the factory image header of master or 18.06 builds. Modern git version 2.17.1 creates 10-digit short hash by default and that causes a too long version string for the image header. (17.01 is branded LEDE, so the string remains apparently short enough)

Longer story in
https://bugs.openwrt.org/index.php?do=details&task_id=1583

Does not work:
master
device:WNDR3800 version:VOpenWrt.r7161-c8677ca89e region: hd_id:29763654+16+128
18.06
device:WNDR3800 version:VOpenWrt.r6995-ba204d941c region: hd_id:29763654+16+128

Works:
master my build (short hash)
device:WNDR3800 version:VOpenWrt.r7161-c8677ca region: hd_id:29763654+16+128                 
17.01 my build
device:WNDR3800 version:VLEDE.r3898-4a38c0cad5 region: hd_id:29763654+16+128
master buildbot:
device:WNDR3800 version:VOpenWrt.r7161-c8677ca region: hd_id:29763654+16+128
18.06 buildbot:
device:WNDR3800 version:VOpenWrt.r7009-48c5d6a region: hd_id:29763654+16+128
17.01 buildbot:
device:WNDR3800 version:VLEDE.r3909-b6a1f43 region: hd_id:29763654+16+128

I can fix my own build by forcing a shorter git hash in getver.sh

--- a/scripts/getver.sh
+++ b/scripts/getver.sh
@@ -40,7 +40,7 @@ try_git() {
                        REV="${UPSTREAM_REV}+$((REV - UPSTREAM_REV))"
                fi
 
-               REV="${REV:+r$REV-$(git log -n 1 --format="%h" $UPSTREAM_BASE)}"
+               REV="${REV:+r$REV-$(git log -n 1 --format="%h" --abbrev=7 $UPSTREAM_BASE)}"
 
                ;;
        esac

I have only tested with WNDR3800, but I guess that this hits also other Netgear routers with the same kind of TFTP flashing recovery mode.

2 Likes

@hnyman I tried install all the feeds but the same warnings occur, normally I only install the feeds that I need for my build.

I think you are right that it has something to do with the feeds, when updating the feeds it already starts with the warnings.