Build for WNDR3700v1/v2 / WNDR3800 (discontinued)

[quote="VSG, post:40, topic:64"]
LEDE master: lede-r3887-17f60b1cd2-20170328Which changes?
[/quote]compared to what?
My build is just the compilation of current LEDE with the package inclusions & source changes that I list/explain. Full source diff compared to the default are available at each build in its download directory. But I am not explaining the general LEDE (or Openwrt) changes that are available in git commit logs.

For build from commit 17f60b1cd2 the changelog is here....
https://git.lede-project.org/?p=source.git;a=shortlog;h=17f60b1cd260a24ef990d6622f9c5ed6951c0722

Funny. I never noticed that. I have 3700v1, 3700v2 and 3800. v1 and v2 have the sticker for WPS PIN while 3800 really does not have it. But Netgear still sets the random PIN in the firmware and I use that just like for v1 and v2 (although it is not visible :frowning: ) The firmware for all three is compiled at the same time, so I am not going to make exception for 3800.

Sure, if you compile your own personal version of the firmware. The information is readable from the "art" partition. (Just follow the example how I read WPS PIN and patch the wifi config generation accordingly)

But I am following the long Openwrt practice of leaving wifi off initially, so I am not going to change my own build.

EDIT:
My download directory even gives an explanation how the 3700v1/v2/3800 device data is structured:
https://www.dropbox.com/sh/t52c02rm20y8x9p/AACuQTlCP6p-0w9IBGYe0Fiea/art%20partition%20binary%20contents/art_header_explanation.txt?dl=0

1 Like

Actually, if you just have one router and you want a build to include your personal.settings, just include the config files as custom files in the build. See https://lede-project.org/docs/guide-developer/use-buildsystem#custom_files or http://wiki.openwrt.org/doc/howto/build#custom_files

This is purely for my own educational purposes- but is there any way to do a kermit/etc download onto a WNDR3800 that has had it's ART destroyed, and hence, unable to bring up the network due to invalid MAC addresses? The machine in question is already gone, but there has to be a way to write to it since your build with ART write support just sets it non-RW?

Thanks. Worked perfectly

Does anyone know how to enable CSA in DFS channel? I need to make a handover from a DFS channel for a non-DFS simulating a CSA

I have never needed to do serial transfer to u-boot, but it should be possible. Some advice can be found in https://wiki.openwrt.org/toh/netgear/wndr3700#flashing_over_serial

Using u-boot commands it should also be possible to get tftp functionality working from u-boot.

It should also be possible to override MAC in interface config, so that the network will come up despite missing MAC information in art. That would then enable using LEDE console to write a backup copy of art contents back to art via mtd.

1 Like

The problem I had was that the entire unit became corrupt thanks to a DD-WRT flash that didn't setup the partitioning correctly- I assume the previous owner flashed the wrong image.

I couldn't tftp into it because of the invalid MAC, and didn't know where the MAC address was stored, but I had the serial console just fine..

I'm afraid I'm not familiar enough with ath9k to know if it's even possible. I can tell you that DFS won't work unless you are using a 20Mhz width, it won't work at 40. I'd suggest grabbing @hnyman's config to see how he has it setup - the kernel docs on DFS are pretty lacking.. https://wireless.wiki.kernel.org/en/developers/DFS

No.
And my build uses the standard ath9k driver with default settings, so there is nothing build-specific.

You should ask that question in a new hardware / wireless config oriented thread to get answers from wifi driver/config gurus (who might not read a thread about a private build for a rather old device...)

I will remove aiccu in the next builds, as SixXS will stop operations in June.
https://www.sixxs.net/sunset/

[quote]Sunsetting SixXS

SixXS will be sunset in H1 2017. All services will be turned down on 2017-06-06, after which the SixXS project will be retired. Users will no longer be able to use their IPv6 tunnels or subnets after this date, and are required to obtain IPv6 connectivity elsewhere, primarily with their Internet service provider.[/quote]

If you are still using aiccu-based SixXS 6in4 tunnels, start looking for alternatives...

Tried both of these versions for WNDR3800 - after flashing and resetting to default values, the on / off button of the wifi does not work either. What need to do to ensure that the router understands the pressing of the WiFi button?

[quote="VSG, post:54, topic:64"]
WNDR3800 - after flashing and resetting to default values, the on / off button of the wifi does not work either. What need to do to ensure that the router understands the pressing of the WiFi button?
[/quote]You need to have a working wifi config first. The default config leaves wifi disabled (each radio has the option "disabled" as 1). You need to configure the channel, country, SSID, encryption etc. normal wifi config items.

After you have a working wifi, the button works and turns wifi on or off. (It issues the commands "wifi up" or "wifi down", but does not alter the actual wifi config.)

I just tested with WNDR3700 running 17.01-SNAPSHOT, r3293-1adc6db036 and the button works just as expected.

Let me start with praising you for supplying such a nice stream of ready-to-use builds for the venerable wndr3[7|8]000v[1|2] that makes keeping up to date with lede development a breeze that requires no actual firmware building from my side :wink:

I have a question regarding the IPv6/WAN6 default configuration in your builts (as I have been plagued by erratic IPv6 and DNS issues since winter); at least on my wndr3700v2 the interface name for the WAN6 interface defaults to eth1 (after a "sysupgrade -n", so I believe this to show the defaults of your builts/lede):
"config interface 'wan6'
option ifname 'eth1'
"
This seems to be sensible in that eth1 really is the ethernet interface that directs towards the internet.

But it does not work for setting up IPv6 on my "deutsche telekom vdsl50 link", resulting in a weird router state over-all where DNS (IPv6 and IPv4) is severely wonky (e.g. "nslookup www.heise.de" on the router will not work like 19 out of 20 attempts).
According to a Hans Dedecker (https://bugs.lede-project.org/index.php?do=details&task_id=668) the issue is that for links where IPv6 is negotiated over an IPv4 PPPoE link (like mine) the wan6 ifname should be "@wan" (or alternatively the wan6 interface should be nuked completely). And lo and behold with:
config interface 'wan6'
option proto 'dhcpv6'
option _orig_ifname 'eth1'
option _orig_bridge 'false'
option ifname '@wan'
option reqaddress 'try'
option reqprefix 'auto'

I get both working IPv6 and IPv4 DNS working again. So I wonder does @wan also work for users that do get IPv6 directly via DHCP, and if yes, would you consider switching the default? I have not looked into the defaults lede's stable version or snapshots, so for all I know this might be an issue with "upstream lede" as well.

Best Regards

Sorry. I use the LEDE default setting there. No personal modifications, as you can see from the diffs I provide with builds. It works for me, so I am not going to change it.

(I have native IPv6 from ISP and currently the connection is ethernet via fiber directly to the cellar, so I have no experience from PPPoX things.)

Ps. currently my old WNDR3700 is just a supporting router providing wifi coverage ;-(
I mainly use R7800.

Ah, then I will try to figure out what the rationale is for lede's default. The interesting thing is that as of last summer, things just worked, and then they stopped, but I was too busy otherwise to directly dig into this. My main puzzlement is not so much that out of the box my IPv6 did not work (I guess it is fair to having to configure it properly given the multitude of deployment schemes, it is more that IPv4 DNS stopped working reliably, which is quite an unexpected side-effect of a semi-broken IPv6 configuration). Anyway, thanks for you builds, I will try to figure out what to do upstream :wink:

BTW, I completely had forgotten about the nice diffs you supply, so sorry for not looking more diligently...

At some point the @wan default was changed into supplying the WAN netdev directly (e.g. eth1 or eth0.2). That change was done by Steven back then and I remember that I already asked for the motivation there too since it essentially turned a well working IPv6 autoconfiguration into something that failed for anyone using VLANs, PPPoE or anything else affecting the WAN layer 3 interface.

Maybe it makes sense to switch back to @wan, you could ask Hans Dedecker via mailing list or IRC as he's the one with the deepest insight into the current IPv6 userland.

Edit: I reviewed my old chat logs and the explanation given was that "it doesn't work with e.g. dslite setup".

We should maybe fix whatever is broken with dslite and switch back to the wan6 interface with @wan as this seemed to be the most reliable variant so far...

Maybe I have misunderstood something here, but I have a PPPoE connection to my ISP for IPv4 and my WAN6 interface (LEDE default) configured to get DHCP address from the ISP (I believe it goes by way of the PPPoE connection?).
I do NOT have the ipv6=1 option enabled under my WAN interface, yet my IPv6 works fine (Native with PD).
Isn't this the exact configuration you're talking about? Although, I am using a WNDR3700v1 if that has any bearing?

The only odd thing I do have, is that I have to change the ula_prefix from whatever is system generated after a factory reset or upgrade, or my IPv6 internet traffic won't work (but I do get assigned IPv6 routable addresses etc. to clients and to the interfaces in LEDE)... still haven't worked out why on that one.

1 Like

I made builds to test the FastPath - the Shortcut Forwarding Engine from Qualcomm, that is supposed to streamline NAT routing. WNDR3700/3800 family is CPU constrained with speedy internet connections, so I thought to test this myself.

Fastpath is not yet in LEDE master sources, but there is a pull request from @dissent1 , so it might get included at some point. Relevant discusion e.g. in Qualcomm Fast Path For LEDE

In any case, the download directory now contains two almost identical builds from today:

  • lede-r4668-b70a96285c-20170803-optional-fastpath has basic build but has the Fastpath packages as *.ipk files in the directory, so that they can be downloaded and installed with opkg
  • lede-r4668-b70a96285c-20170803-fastpath-built-in has Fastpath built into the firmware.