I used lsmod and the module is not loaded so I installed it with:
opkg install kmod-ath9k

Now I can see wlan0 and wlan1 in ifconfig but the file wireless has remained empty. If I try to configure it myself, the output of wifi is:

root@OpenWrt:/etc/config# wifi
/sbin/wifi: eval: line 1: hostapd_set_bss_options: not found
/sbin/wifi: eval: line 1: hostapd: not found
Failed to start hostapd for phy0
/sbin/wifi: eval: line 1: hostapd_set_bss_options: not found
/sbin/wifi: eval: line 1: hostapd: not found
Failed to start hostapd for phy1

I think is a good idea to build openwrt myself!

Thank you very much.
Daniele

Building OpenWRT yourself may be a good idea for other reasons, but perhaps not necessary here. I think the snapshot images are mostly OK, except that they include all components as modules rather than as built-in commands.

You can probably fix the above errors by using opkg to install hostapd-mini. On a side note, once the mac80211 and the ath9k kernel modules are installed, I think the system will auto-create an appropriate /etc/config/wireless template for your system the next time you run "wifi" (or maybe you have to reboot?). I believe it only does that if /etc/config/wireless does not exist, though.

I had a similar, possibly related problem with the first trunk build I tried 2 weeks ago. Make sure that the kmod-ath9k package is installed; it was missing from the build I tried, resulting in this problem. (You can check by: running "lsmod | grep ath9k", or running "opkg list-installed | grep ath9k").

Ah, I see essdz already pointed out that's the problem. Sorry; I was looking at page 6 of the thread and didn't realize there was already a page 7.

Anyway, comments 100, 107 and 109 from me in this thread list a bunch of packages I had to install to get the trunk build to work (including luci). Yeah, building yourself is a good idea (I didn't have these problems with kmod-ath9k and hostapd in the build I made, though luci was still mostly absent and required a lot of playing with opkg after install).

So is there any news on the signal levels? I saw a ticket had been opened.

Simple and easy: No.

On a related note, does anyone have a copy of (or a pointer to) the corresponding AR9xxx data sheet? I wasn't able to find one with some cursory searching. It would be very helpful to look at configuration info for the radios so we can see if we're missing something!

When I opened the router, I could see that one of the two wifi modules is AR9223 (the other one was not possible to discern, the message above is completely faded. Is it the AR9220 ??).
I have found this datasheet for a pci adapter which uses the same chip.
http://www.senao-me.ae/uploads/1237268820436.doc
I hope this can help in development.

Daniele.

(Last edited by enodiesop on 5 Feb 2010, 17:49)

Thanks--but unfortunately, this seems to be simply a datasheet for the module that *uses* the chip, so it doesn't include any information about the AR9223 itself. I think it would help the community if we could find the actual interface used by the chip! The datasheet I'm hoping to find is likely to be a hundred pages or more...but maybe it's only available under NDA?

Any new information about new builds which might work?

AFAIK the latest trunk is working fine on WNDR3700.  My main "production" home router is running a build I did maybe a week or so ago (not sure exactly when but at least after the switch to default to kernel 2.6.32, so pretty recent).  I have not seen any changes go by that look like they would affect WNDR3700, so I haven't updated, but conversely a build of current trunk should be just as good as mine.

It depends on what you mean by "might work". Excluding the signal strength issues, all of the recent builds have worked for me. (My most recent checkout was trunk r19503, for reference, and it worked fine.) If you plan to work in the same room as your router, the current builds should be all you need.

On the flip side, I have been watching checkins and I have not seen anything in OpenWRT that appears to impact the signal strength issue since my last checkout. Although compat-wireless was updated from 02-02 to 02-07 since then, I don't believe the ath9k developers have noticed the issue.

I did some playing with the stock NETGEAR firmware in the meantime, and it turns out that the four "power saving modes" mentioned in the product literature are apparently not doing anything fancy after all: when you adjust the power saving mode in the range of 25% to 100% through the web interface, they simply run scripts to adjust the radio txpower (in /etc/rc.d/rc.wlan). I verified through iwconfig that the four different power-saving modes simply result in reduced transmit power settings after they have been applied--so I think the culprit is something else.

I noticed that the NETGEAR factory GPL source releases come with a set of detailed release notes in docs/release_notes.tex, and these notes appear to have been kept up to date even in the most recent releases. I haven't looked through much of it, but there seems to be at least some marginally-interesting stuff in there.

For example, if you want to rebuild and upgrade a new copy of the U-Boot bootloader, the release notes provides specific instructions for manipulating the flash memory to do so, as follows:

Please burn u-boot-wndr3700-dni6-V1.7.bin
Set up a tftp server on your PC, its ip address is 192.168.1.12.
Entering into boot loader
ag7100> set serverip 192.168.1.12
ag7100> tftp 0x80010000 u-boot-wndr3700-dni6-V1.7.bin
ag7100> erase 0xbf000000 +0x70000
ag7100> cp.b 0x80010000 0xbf000000 0x50000
ag7100> reset
Entering into boot loader again
ag7100>bootm
Then the device should be in tftp recovery mode. Please run the command
"tftp -i 192.168.1.1 put WNDR3700U-V1.0.4.49.img" on MS-DOS of your PC.

I agree -- I haven't seen any activity around wireless signal strength for WNDR3700.  With that said, with the current trunk, the signal strength is sufficient that I get usable coverage over my whole house, so in my case at least, it's not *that* bad.

Are you using 2,4GHz or 5GHz?
Only asking since my 2,4GHz performance is only few meters line of sight. 5GHz is far better.

@essdz,

How about enable u-boot bootloader to boot from USB?

Both work fine in my (small) house.  Signal strength could be better but coverage is very usable on both 2.4GHz and 5GHz.  I have seen issues when I enable 802.11n on the AP -- but I think those are actually bugs in the iwlagn driver I'm running on my laptop.

Now that would be an * Excellent!! * idea!

I note theres been an update in the trunk by juhosg claiming to work around the bad signal strength, anyone tested yet?

Yep, just saw that go by too.  I just finished building it.

It seems to be a huge improvement for me -- on my 2.4 GHz network, in the worst spot in my house, I saw signal strength go from -86 dBm to -61 dBm, and my laptop went from struggling to hold a 12 Mb/sec data rate to having a solid 54 Mb/sec connection.  I didn't do before and after numbers for 5 GHz, but in the same bad spot I see a -71 dBm signal, which seems pretty good.

I think it's definitely worth building the latest trunk if you've been having signal strength problems with WNDR3700.

YES! I just built r19658 and I am seeing significant improvements in signal strength. The signal is not quite as good as the stock NETGEAR firmware for me, but it's definitely a lot more useable.

Compared to the previous OpenWRT release, I see a 16 dB (!) improvement in 2.4 GHz signal strength and a 6 dB improvement in 5 GHz signal strength.

RSSI at 2.4 GHz is still 6 dB lower than the default NETGEAR firmware, and 11 dB lower for 5 GHz, but as I wrote before, it's now useable.

Juhosg's patch from earlier today indicates that it is selecting a fixed antenna group, so perhaps there is a little more tweaking to be done...but we're looking in pretty good shape overall, and now we know where to look.

Now that we've got some useful signal strength, here are some patches to get a nice default LED configuration for both the wired and wireless parts of the device.

This patch adjusts the default /etc/config/network setup to set up your bicolor switch LEDs at boot. If you already have a customized network configuration, just copy and paste the relevant pieces. (The config is loaded automatically via UCI, so this means you don't have to run a special swconfig script to set up the LEDs.)

http://pastebin.com/f6dff0914  (click "download")

The following patch is a clean version of ase's earlier posting to enable the correct GPIO for the WLAN LEDs. This also leverages juhosg's recent checkin to determine whether or not the driver is running on the WNDR3700 in order to create a clean patch.

http://pastebin.com/m76ad5c6f (click "download")

These changes work great for me, except that the WLAN LEDs are on solid and do not blink. I could have sworn that we had nice blinky LEDs in a previous trunk revision, so this warrants further investigation...although I don't think it's related to my patch.

If these work for other people, I will submit them for inclusion in the trunk.

Thanks juhosg (Gabor Juhos) for fixing signal levels!

Works ok here, not perfect but a lot better than before.

(Last edited by ole.h on 11 Feb 2010, 22:00)

I've tested these patches and they seem to work fine. Good job!

Could you include an example of configuring the wan led via the switch as well in the config file?

Also this is just a matter of opinion but I'd personally change the green led default mode from 2 (always on and blinking) to 9 (on only when 10/100 mb/s connection and blinking). This way when using 1000 mb/s connection you wouldn't get both green and orange led on at the same time.

Please submit your patches for inclusion. Could you also submit my patch (or something similar) for toggling the wan led color from post #135 at the same time?

OK--submitted. We'll see what happens. Thanks for all of your work on the switch driver and finding the WLAN LEDs!

I noticed that juhosg's antenna patch is toggling some GPIOs to select a fixed antenna group. I thought it might be interesting to play with some of the other settings on those GPIOs to see if any other antenna group(s) might work better and/or differently.

If you add the following code as package/mac80211/patches/590-wndr3700-antenna.patch, you can then adjust the value of those four GPIOs using module parameters:

--- a/drivers/net/wireless/ath/ath9k/init.c    2010-01-18 14:11:59.943782130 -0200
+++ b/drivers/net/wireless/ath/ath9k/init.c    2010-01-18 14:12:59.015805947 -0200
@@ -32,6 +32,22 @@
 module_param_named(nohwcrypt, modparam_nohwcrypt, int, 0444);
 MODULE_PARM_DESC(nohwcrypt, "Disable hardware encryption");
 
+static int modparam_as1 = 0;
+module_param_named(as1, modparam_as1, int, 0664);
+MODULE_PARM_DESC(as1, "WNDR3700 antenna select 1");
+
+static int modparam_as2 = 1;
+module_param_named(as2, modparam_as2, int, 0664);
+MODULE_PARM_DESC(as2, "WNDR3700 antenna select 2");
+
+static int modparam_as3 = 0;
+module_param_named(as3, modparam_as3, int, 0664);
+MODULE_PARM_DESC(as3, "WNDR3700 antenna select 3");
+
+static int modparam_as4 = 1;
+module_param_named(as4, modparam_as4, int, 0664);
+MODULE_PARM_DESC(as4, "WNDR3700 antenna select 4");
+
 /* We use the hw_value as an index into our private channel structure */
 
 #define CHAN2G(_freq, _idx)  { \
@@ -682,10 +698,14 @@
     ath9k_hw_cfg_output(ah, 9, AR_GPIO_OUTPUT_MUX_AS_OUTPUT);
 
     /* select the first antenna group */
-    ath9k_hw_set_gpio(ah, 6, 0);
-    ath9k_hw_set_gpio(ah, 7, 1);
-    ath9k_hw_set_gpio(ah, 8, 0);
-    ath9k_hw_set_gpio(ah, 9, 1);
+    ath9k_hw_set_gpio(ah, 6, modparam_as1);
+    ath9k_hw_set_gpio(ah, 7, modparam_as2);
+    ath9k_hw_set_gpio(ah, 8, modparam_as3);
+    ath9k_hw_set_gpio(ah, 9, modparam_as4);
+
+    ath_print(ath9k_hw_common(ah), ATH_DBG_FATAL,
+            "WNDR3700 antenna configuration: %d %d %d %d\n",
+            modparam_as1, modparam_as2, modparam_as3, modparam_as4);
 }
 #else
 static inline void wndr3700_init_antenna(struct ath_hw *ah) {}

After doing this, assuming that you built ath9k as a module, you can then edit /etc/modules.d/27-ath9k and adjust the file to look like this:

ath9k_hw
ath9k_common
ath9k as1=0 as2=1 as3=0 as4=1

You can then try varying the values of as1 through as4 to see what happens (with the above being the current default config). I was rebooting between changes--it should be testable, at least in theory, by doing rmmod followed by modprobe, but that seemed to confuse something in the wireless code--and you can confirm by looking for "WNDR3700" in dmesg to verify that your specified GPIOs were correctly configured.

I haven't had a lot of time to play with it yet, but if these settings turn out to do something useful that needs to be accessed from userspace, we could think about a /proc filesystem interface for it.