On the note of wireless performance, aside from the HT40 issues: I should add that when I created the tracker build that is currently circulating, I accidentally built the ath9k/mac80211 drivers with debugging features turned on. (I forgot to cleanse my config from some previous development work...)

I don't know if these debug features have any noticeable impact on performance, or if they just cause driver bloat and/or eat CPU...but it's one more thing that we can look into.

essdz can you put the sysupgrade image into a torrent? I messed up my initial install and want to sysupgrade my device to get everything fixed.

Well, I tried using x-wrt interface and it doesn't have a fully functional ui for some areas like setting channels for wireless for instance. I switched back to luci, installed ntp client for time synchronization and changed firewall wan incoming traffic from reject to drop and everything appears to be working fine (including wireless channel bonding, using 157 right now...must just be certain channels that work either with openwrt or with my adapter but I don't care as it works fine at 157!). Thanks OpenWRT and essdz for making the image I am currently using. Lots of cool packages I can play with since I updated opkg.conf with the correct address for trunk.

Btw I don't really notice any substantial impact in network performance with the debug mode you mentioned essdz. Maybe I just don't notice it because I don't use enough traffic on the network to see an impact or whatever but everything works for my standards. Just FYI. The test image you posted will work fine for my purposes until another image is posted or i feel like compiling from trunk which I doubt I ever will feel like doing.

(Last edited by skarlson on 4 Mar 2010, 18:11)

How do you configure the vlans? With swconfig + command line or some other means of configuration? Could you provide an example what to do to lose the connectivity?

I'd like to install a server LAMP on the router. Is it possible?

I've gotten a few requests for the sysupgrade version of the earlier torrent release. My present connectivity is not good enough to seed another torrent, but the sysupgrade is now posted for public access at the address below.

This sysupgrade is from exactly the same build that was used to create the torrent. If you already downloaded the torrent and it's working for you, this sysupgrade won't give you anything new.

http://wndr3700.nfshost.com/openwrt-ar7 … pgrade.bin

IMPORTANT NOTE: this is the sysupgrade version of the torrent. This download will do you no good unless you are already running OpenWRT on your device. If you want to install OpenWRT from the stock NETGEAR firmware, instead download the torrent that is referenced here.

I've also been playing with some code to tweak the antenna settings on the wireless interfaces through the /proc filesystem, similar to how it's done with the manufacturer's firmware.

If you're building the code yourself and interested in experimenting, see my note and patch posted today to the related Trac ticket.

I had time to write the antenna patch to permit the GPIOs to be tweaked, but I haven't had time to systematically test all of the combinations to see their impact on performance...any takers?

Apparently busybox httpd cannot handle network settings. If you kill httpd and start lucid, the pages work. I have to figure out how to do this automatically...

/etc/init.d/httpd disable
/etc/init.d/lucid enable

(Last edited by gulikoza on 6 Mar 2010, 12:51)

Please would someone be so kind and confirm an observation:
I’m testing continuous ping form window 7 wireless client to the wndr3700 ip address. Client and router are in the same room with air distance within 5 meters (15 ft.).  Two different Intel abg clients behave exactly the same and see 3 % loss with an average latency of 5 ms. Testing the same configuration against an older kamikaze router with standard Atheros abg (ath_pci) I get just 2 ms average latency without any loss.

The sporadic packet loss badly affects various latency sensitive applications (example interactive ssh). While everything else has greatly improved this problem remains pretty much unchanged through trunk images since November. Does anyone else see the same result or even better knows a configuration tweak to improve the steadiness of wifi transmission?

I didn't have nonworking luci pages in either essdz's build that he posted online nor do I have nonworking luci pages in the fresh build (r20016) I am using now which was created today. Only problem I had was compiling it which I found out was likely a problem downloading certain luci files during compile because they did not exist on the mirrors listed.

I found the following fix for build which solved the issue and I was able to successfully build an image. I followed the wiki except after downloading from svn I did cd trunk and ran the following before make package/symlinks or make menuconfig.

./scripts/feeds update packages luci
./scripts/feeds install -a -p luci

Quite pleased with the build and I just plunked down a sysupgrade version on top of essdz's original image which I was using before that to avoid having to set everything up again. Not sure about latency issues since I haven't run anything. I only did an internet latency test and I am getting the same readings I got while using factory firmware.

Uppp!

Can't tell you exactly what went wrong (or should i say, what i did wrong), but after giving it another shot the problem was gone. I do however ran into a new problem. I think it's WNDR3700 related...

I have two "wan" connections to two isp's. Using iproute2, i loadbalance between those isp's. During a tcp session, for unknown reason, the packet sequence number get reset. When a tcp session is established all packets should traverse the same wan interface during this connection. But this is not always happening, as it rarely changes sequence number. After this hickup has happend the connection between the two hosts is gone. Below is a tcpdump output of my lan interface and wan interface of the same session.

LAN:

01:26:35.296622 IP (tos 0x0, ttl 128, id 7712, offset 0, flags [DF], proto TCP (6), length 45)
    Saturnus.louwes.local.49743 > by2msg4010818.phx.gbl.1863: Flags [P.], cksum 0x77cb (correct), ack 12580, win 251, length 5
01:26:35.478672 IP (tos 0x0, ttl 115, id 3236, offset 0, flags [DF], proto TCP (6), length 48)
    by2msg4010818.phx.gbl.1863 > Saturnus.louwes.local.49743: Flags [P.], cksum 0x40c2 (correct), ack 3952, win 65450, length 8
01:26:35.678567 IP (tos 0x0, ttl 128, id 7715, offset 0, flags [DF], proto TCP (6), length 40)
    Saturnus.louwes.local.49743 > by2msg4010818.phx.gbl.1863: Flags [.], cksum 0x1927 (correct), ack 12588, win 251, length 0
01:27:19.475426 IP (tos 0x0, ttl 128, id 10472, offset 0, flags [DF], proto TCP (6), length 45)
    Saturnus.louwes.local.49743 > by2msg4010818.phx.gbl.1863: Flags [P.], cksum 0x77be (correct), ack 12588, win 251, length 5
01:27:19.975402 IP (tos 0x0, ttl 128, id 10534, offset 0, flags [DF], proto TCP (6), length 45)
    Saturnus.louwes.local.49743 > by2msg4010818.phx.gbl.1863: Flags [P.], cksum 0x77be (correct), ack 12588, win 251, length 5
01:27:20.575450 IP (tos 0x0, ttl 128, id 10557, offset 0, flags [DF], proto TCP (6), length 45)
    Saturnus.louwes.local.49743 > by2msg4010818.phx.gbl.1863: Flags [P.], cksum 0x77be (correct), ack 12588, win 251, length 5
01:27:21.775521 IP (tos 0x0, ttl 128, id 11239, offset 0, flags [DF], proto TCP (6), length 45)
    Saturnus.louwes.local.49743 > by2msg4010818.phx.gbl.1863: Flags [P.], cksum 0x77be (correct), ack 12588, win 251, length 5
01:27:24.175681 IP (tos 0x0, ttl 128, id 11249, offset 0, flags [DF], proto TCP (6), length 45)
    Saturnus.louwes.local.49743 > by2msg4010818.phx.gbl.1863: Flags [P.], cksum 0x77be (correct), ack 12588, win 251, length 5
01:27:28.975999 IP (tos 0x0, ttl 128, id 12017, offset 0, flags [DF], proto TCP (6), length 45)
    Saturnus.louwes.local.49743 > by2msg4010818.phx.gbl.1863: Flags [P.], cksum 0x77be (correct), ack 12588, win 251, length 5
01:27:38.576587 IP (tos 0x0, ttl 128, id 16464, offset 0, flags [DF], proto TCP (6), length 40)
    Saturnus.louwes.local.49743 > by2msg4010818.phx.gbl.1863: Flags [R.], cksum 0x1a19 (correct), seq 3957, ack 12588, win 0, length 0

WAN:

01:26:35.296801 IP (tos 0x0, ttl 127, id 7712, offset 0, flags [DF], proto TCP (6), length 45)
    192.168.31.65.49743 > by2msg4010818.phx.gbl.1863: Flags [P.], cksum 0x79f2 (correct), ack 12580, win 251, length 5
01:26:35.478494 IP (tos 0x0, ttl 116, id 3236, offset 0, flags [DF], proto TCP (6), length 48)
    by2msg4010818.phx.gbl.1863 > 192.168.31.65.49743: Flags [P.], cksum 0x42e9 (correct), ack 3952, win 65450, length 8
01:26:35.678744 IP (tos 0x0, ttl 127, id 7715, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.31.65.49743 > by2msg4010818.phx.gbl.1863: Flags [.], cksum 0x1b4e (correct), ack 12588, win 251, length 0

#From here on it goes wrong (SEQ_number changed and wrong ACK). Looks like NATing goes bad.
#It even switched form outgoing interface...

01:27:19.475608 IP (tos 0x0, ttl 127, id 10472, offset 0, flags [DF], proto TCP (6), length 45)
    192.168.31.65.49743 > by2msg4010818.phx.gbl.1863: Flags [P.], cksum 0x79e5 (correct), ack 2501110533, win 251, length 5
01:27:19.975592 IP (tos 0x0, ttl 127, id 10534, offset 0, flags [DF], proto TCP (6), length 45)
    192.168.31.65.49743 > by2msg4010818.phx.gbl.1863: Flags [P.], cksum 0x79e5 (correct), ack 1, win 251, length 5
01:27:20.575633 IP (tos 0x0, ttl 127, id 10557, offset 0, flags [DF], proto TCP (6), length 45)
    192.168.31.65.49743 > by2msg4010818.phx.gbl.1863: Flags [P.], cksum 0x79e5 (correct), ack 1, win 251, length 5
01:27:21.775728 IP (tos 0x0, ttl 127, id 11239, offset 0, flags [DF], proto TCP (6), length 45)
    192.168.31.65.49743 > by2msg4010818.phx.gbl.1863: Flags [P.], cksum 0x79e5 (correct), ack 1, win 251, length 5
01:27:24.175878 IP (tos 0x0, ttl 127, id 11249, offset 0, flags [DF], proto TCP (6), length 45)
    192.168.31.65.49743 > by2msg4010818.phx.gbl.1863: Flags [P.], cksum 0x79e5 (correct), ack 1, win 251, length 5
01:27:28.976192 IP (tos 0x0, ttl 127, id 12017, offset 0, flags [DF], proto TCP (6), length 45)
    192.168.31.65.49743 > by2msg4010818.phx.gbl.1863: Flags [P.], cksum 0x79e5 (correct), ack 1, win 251, length 5
01:27:38.576749 IP (tos 0x0, ttl 127, id 16464, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.31.65.49743 > by2msg4010818.phx.gbl.1863: Flags [R.], cksum 0x1c40 (correct), seq 5, ack 1, win 0, length 0

Any ideas ?

(Last edited by Adze on 8 Mar 2010, 19:27)

Has anyone had any success in getting VLANs working on the WNDR3700?

I have tried creating a subint on the WAN interface for a guest network using VLAN 103, however I don't end up passing any traffic.

~Tyson

(Last edited by tysonedwards on 10 Mar 2010, 00:39)

It works but only *.bin firmware. Original firmware has *.img extension and it dosn't work. Have can I do? Must I do convert firmware's file from *.img to *.bin?

CoyoteDen's process should actually *only* work with .IMG (manufacturer-format) files, and not at all with the OpenWRT .bin files. Can you confirm exactly which file you were attempting to use?

The steps in the wiki have worked fine for me and others to restore the manufacturer-default firmware. Can you try it again? (Which firmware image are you trying to upload?)

I also struggled a bit to get things restored after getting bricked. The problem was that i copy/pasted al the tftp commands at once, which messed up the client, without any warnings (just didn't work). Entering the lines one by one helped for me...

By the way, i'm still wresteling with my above problem... What i tried so far is disable everything in iptables and only add MASQ rules, to no avail. Even with the default Backfire release the problem exists...

(Last edited by Adze on 10 Mar 2010, 19:30)

I was able to restore my router using the tracker image posted on page 8 and 9 using tftp which is *.img file. I actually built a custom image which I upgraded the tracker image to after restoration.

(Last edited by skarlson on 10 Mar 2010, 21:55)

I think I might have a clue why HT40 does not work with my clients.

root@OpenWrt:/sys/kernel/debug/ieee80211/phy1/stations/00:26:bb:XX:XX:XX# cat ht_capa
ht supported
cap: 0x004c
        HT20
        SM Power Save disabled
        RX HT40 SGI
        No RX STBC
        Max AMSDU length: 7935 bytes
        No DSSS/CCK HT40
ampdu factor/density: 3/6
MCS mask: ff ff 00 00 00 00 00 00 00 00
MCS tx params: 0

All of my three Mac clients announce HT20 only. Seems like ath9k misinterprets client capabilities or the OSX driver is announcing them wrong. Now I wonder if I could hardcode HT40 in the driver, because the windows driver is capable of HT40. Might be interesting to compare the outputs from other people to draw conclusions.

  --Markus

Has anyone gotten jumbo frame support to work?

It works for me. I didn't need to configure anything special on the WNDR3700.

eg.

17:50:14.679153 IP (tos 0x0, ttl 64, id 29181, offset 0, flags [DF], proto TCP (6), length 52)
    xx.xx.1.200.548 > xx.xx.1.100.55826: Flags [.], cksum 0x55f6 (correct), ack 57083053, win 14558, options [nop,nop,TS val 3738 ecr 900901209], length 0
17:50:14.679204 IP (tos 0x0, ttl 64, id 40642, offset 0, flags [DF], proto TCP (6), length 7936)
    xx.xx.1.100.55826 > xx.xx.1.200.548: Flags [.], seq 57090937:57098821, ack 5256, win 35478, options [nop,nop,TS val 900901209 ecr 3738], length 7884

So what's necessary to install on this device? Can someone create a wiki page with instructions as I'd like to try it out. I don't mind building an svn version if that's required.

There is already a Wiki page:

http://wiki.openwrt.org/inbox/netgear/wndr3700

What I would recommend is that you grab essdz's torrent build as it is a very good base that you can use to get started with, however once you get the hang of things, building from svn is not all that difficult.

I'm seemingly picking up HT40 capabilities properly here using a OS X 10.6.2 client (MBP early 2008):

root@openwrt:/sys/kernel/debug/ieee80211/phy1/stations/00:1e:c2:XX:XX:XX# cat ht_capa 
ht supported
cap: 0x000e
    HT20/HT40
    SM Power Save disabled
    No RX STBC
    Max AMSDU length: 7935 bytes
    No DSSS/CCK HT40
ampdu factor/density: 3/6
MCS mask: ff ff 00 00 00 00 00 00 00 00
MCS tx params: 0

@tysonedwards Wow, it's really nicely documented. I already ordered my unit. Looks like the first N-based OpenWRT. I hope that the mods get incorporated into the svn so all we'd have to do is compiles it instead of applying the patches first.

There are no required patches that I am aware of that need to be applied from the current SVN builds.