Hi:

Just wondering if anyone has any experience using the SR71-A card with the ath9k driver under OpenWRT. Does it work? Any issues to report?

Thanks

hi cyrus_mc

yes, i have test it with two PC Engines ALIX 3D boards and one SR71-A on the boards.
openwrt trunk: Linux version 2.6.31.1

i have only load the driver ath9k , not madwifi, and i have speed on twenty meters distance udp > 130MBit/s and tcp 75MBit/s single.

at the moment, i test with MikroTik RouterBOARD R52n .... test are equal ... values are equal.

one problem that i have ... at a distance more as hundred meters ... no association available. i thing is it a timing problem. in madwifi i set the parameter distance, are in the setup ath9k and mac80211 i found not this parameter for seting the distance.

i have it testet at twenty meters : ok, test at over hundred meters ... only on moment have a association then fail, ath 2k meters ... no association.
the values of signal and quality are very good. i have antennas for long distance and dual polarity .... are i think the time of signal from one radio to the other radio is too long. i see the wpa on the ap and the ap on the wpa ... i search for setting the distance values on ath9k setup.

can you help?

can report results with R52n on a RouterStation (ar71xx) based board. It works and associates after tweaking the initialisation.
I make it come up first as an AP and than as a STA. Works fine over 8 km as far as the radio is concerned. With the standard procedure directly into
STA mode I cannot get it to work in a stable fashion. The automatic rate choice has been disabled. So one needs to set bitrate manually.
However, the wireless drivers in the compat-wireless package cause a memory leak and after about 500 MB of traffic the system reboots
due to memory shortage.; until that all works fine, no error messages, no problems.  Just did the test with exactly same firmware and the radio present but the data
going from wan to lan in routing mode. No memory leak whatsoever. So the ath9k hardware/driver combination has a serious problem ....
Have tried compilations into OpenWrt trunk of compat-wireless versions up to today Oct. 27. In this repect they all show the same problem.

(Last edited by doddel on 27 Oct 2009, 17:17)

Greetings doddel,

thanks for your reply.  How did you tweak the initialisation?  We've transfered over one 1 GB traffic so far, but still with very low bitrate at a distance of around 200 meters.

Thanks and take care...

the script i wrote to experiment and replace /sbin/wifi you can download here:
http://www.dorpstraat.com/OpenWrt/wifi
Rename the original /sbin/wifi and put this one chmod 755 in its place. You can from the command line do a 'wifi [up]' and 'wifi down' command and in the script choose whether to use wpa or no encryption and make adaptations where you like.
It bypasses all OpenWrt regular scripts to set up the wireless interface wlan0, ignores the config files, and focuses on just one card on the wlan0 interface that gets set as a station to listen on channel 48 in 802.11 a mode.
In my case a Mikrotik R52n card on a RouterStation Ubiquity motherboard. By no means intended to replace wifi; just a tool to get a finger behind all the problems that exist.

A few observations I have made in the mean time:
1) the memory leak is not caused by Authentication//Encryption and is also present when the system is open and neither hostapd nor wpa_supplicant are active.
2) the leak is not there in routed traffic between eth0 and eth1 ethernet interfaces.
So there must be a problem with the ath9k radio driver.
3) the timing problem is not related to the memory leak but seems an initialisation deficiency of the radio system. If you comment out the lines hostapd_on and hostapd_off in the add_wlan0 subroutine the connection will still be made by the station to the access point. But strangely enough while the pinging times from STA to AP appear to be normal, the pinging from AP to STA is erratic and shows times anywhere between 20 and 150 ms. Only with this intermediate activity by hostapd I get the timing rigt and normal throughput. In the erratic situation the AP bombards the STA with deassociations 'Reason: 3'.

I have tried to compile OpenWrt with debug tools embedded in Busybox but cannot get it to compile. If somebody reads this and could give some hints on how to check ath9k for its memory leaks I would be grateful.

(Last edited by doddel on 28 Oct 2009, 16:46)

can add to this that i enabled ath9k debug facilities that show interrupts and tx / rx activity in the debug file system.
ath9k thinks everything is fine; no error messages, no resends or anything.
Yet after about 350 M of traffic memory runs out :-(

i have switch to kernel 2.6.31-5 Kamikaze r18266.

the connection is mostly stable, the bandwidth is 40MBit/s - 60MBit/s.
no memory leaks ... with iperf 2 days and many GBytes transfer.

i have it used with a dual polarity antenna and if i connect only one kable, it works in MCS2x and if i put the second kabel on the antenna .... it works in MCS3x or MCS4x
the bandwidth is 40MBit/s - 60MBit/s. with or without the second kabel. in range from zero to 20 db tx power. on signal -7 to -60.

i have read that the HT40 makes over hundred MBit/s .... it is a legend?

congrats !
cannot confirm the same here; also did a compile with 2.6.31.5 and latest compat-wireless but it makes no difference.

My laptop with Ubuntu linux, that I use for the OpenWrt compilations, has a miniPCI slot and for the fun of it did put the R52n card
in there. Works very well, uses ath9k, and no memory leak. So in line with your result now.

Can you start the radio properly with the stock wifi routine ? Do you get same results in client and in ap mode ?
Here in sta mode the stock wifi gets the radio started but something is wrong then in the 80211 timing.

Given these results I can only conclude that there is a serious problem in the cross-compilation on a x86 platform to the ar71xx (mips) target. 
Checked with the snapshot of Nov.2 and that produces exactly same problems on my RouterStation motherboard.

Hello doddel,

I bought an Ubiquiti Routerstation based on ar71xx and have planned to ship it with Mikrotik R52n, but your posts make me hesitating. Is the problem with memory leaks only in STA mode or as an AP too?

have not tried it as AP but will. In mean time have found in another project that uses the ar7161 additional compilation patches for the RS platform and am looking into those.
There must be something that derails the cross-compilation of the kernel and/or drivers to the ar7161 mips and messes up proper memory use.

just completed the test as AP, this time in g mode using the R52n card on a RS board. Unfortunately also then the same leak is present from MemFree into SUnreclaim and Slab.
In AP mode I do not manage to get the 802.11 timing right. Very erratic ping times from ap to sta 50 ms and more while from sta to ap it looks reasonable 2.5 ms. It should be under 2 ms both ways though as for the experiment the units and antennas are just meters apart.
Have not found a way yet to start it as AP with at least a good wireless timing and performance. Sorry that I can not report better news for the moment.
Can exclude the other side as culprit of the timing problems because I have tried very different hardware on the other side like RT2501usb and Ubiquiti Wispstaton5. The timing problems are reproducible

(Last edited by doddel on 8 Nov 2009, 15:20)

doddel, did you try to turn off power savings feature on STA?
I also had problems with high and erratic RTT in one direction, but "iwconfig wlan0 power off" resolved them.

Hi Doddle,

I am using a Microtik R52n AR9220 802.11n wifi card on a Intel IXP4XX based wireless router board.
Currently, I can setup an AP mode using ath9k driver in 2.4GHz  "g" mode and seems working.

I wonder whether ath9k gives support to setup "WDS" mode ? iw list shows the following supported modes
on my system.
        max # scan SSIDs: 4
        Supported interface modes:
                 * IBSS
                 * managed
                 * AP
                 * AP/VLAN
                 * monitor
                 * mesh point

Does ath9k gives WDS support for 802.11n wifi card ?

thanks
Sara

@sara
would suggest to check out http://linuxwireless.org/en/users/Documentation/modes. WDS is listed there !
Saw in another older post that It can be enabled, in case it would not work, via setting NL80211_IFTYPE_WDS in ath_attach()
Thanks for reporting your result with the R52n. It confirms that problems are related to the compilation for the MIPS cpu ar71xx
or something peculiar of the RouterStation board and that it works well with x86 architecture. (in my Pentium4 laptop with Ubuntu it also works well)

@nopsenica
thanks !; Just tried 'iwconfig wlan0 power off' but it is not an allowed command for my OpenWrt iwconfig. Just saw on my linux PC that it does exist there
so probably must be enabled somewhere in the OpenWrt compile configuration. Will report results.

Hi doddle,

Yes, WDS is mentioned in the documentation but in driver section http://linuxwireless.org/en/users/Drivers it is not mentioned.

Is that WDS support depends on the 802.11n wifi card vendor? cos in the following reference link  http://www.mail-archive.com/bcm43xx-dev … 08607.html , iw list shows WDS support modes whereas it is not in my case.

       max # scan SSIDs: 4
        Supported interface modes:
                 * IBSS
                 * managed
                 * AP
                 * AP/VLAN
                 * WDS
                 * monitor
                 * mesh point

Is WDS mode support depends on the 802.11n wifi card vendors  ?

Sara

@doddel

I have forgotten ... somewhere in last commits openwrt trunk disabled all wireless options but essential ones. Apply following patch to enable all wireless options, after that "iwconfig ... power off" will work again.

diff --git a/package/wireless-tools/Makefile b/package/wireless-tools/Makefile
index 80766ad..7195f15 100644
--- a/package/wireless-tools/Makefile
+++ b/package/wireless-tools/Makefile
@@ -55,7 +55,6 @@ define Build/Compile
        $(MAKE) -C $(PKG_BUILD_DIR) \
                $(TARGET_CONFIGURE_OPTS) \
                CFLAGS="$(TARGET_CFLAGS) -I." \
-               BUILD_WE_ESSENTIAL=y \
                libiw.so.$(PKG_VERSION) iwmulticall
        $(MAKE) -C $(PKG_BUILD_DIR) \
                PREFIX="$(PKG_INSTALL_DIR)" \

WDS is a repeater function, i.e. an alternation between the roles of an AP to nearby clients and of a station that relays that traffic to another AP (that is why you loose bandwith as anything received will be transmitted again on the same channel by the same radio while preserving the original sender's mac address) . If the ath9k driver supports it, what the docs seem to suggest, it should work in principle because the radio operations are under direct control by the driver software. The meaning of it all is in the software and the radio just executes while in real time being controlled by the driver.
I do not use WDS myself because of the bandwidth sacrifice. Therefore cannot comment on current WDS ath9k status. Just check the ath9k repositories and bug reports. OpenWrt Trunk imports via the compat-wireless package a quite recent version of their work.

@nopsenica
thanks for your patch ! Will give it a try.

did the experiment and can 100% confirm your experience and fix for the timing problem.

Apparently the hostapd program also does something to the power setting. Found that also with the essentials_only version of iwconfig in wireless-tools
the AP can give stable timing. It is important though to go through the activation steps in the right order.
1.    iw phy phy0 interface add wlan0 type managed    , to bring up the wireless interface
2. <commands to start hostapd>
3.   ifconfig wlan0 <ip_address> netmask 255.255.255.0 broadcast +   , to bring up the network interface.

If 3) is done before 2) the ping timing is bad, unless one adds the power off command.

The case of sta/client mode is different. Hostapd is not needed there and in case of wpa the wpa_supplicant, unlike hostapd, apparently leaves power alone.
My _by accident_ find that starting and stopping hostapd before bringing up the interface as client can indeed be replaced by the 'iwconfig wlan0 power off' command
as suggested by you.    So that is one problem under control ! Thank you.
Left for me is the ar71xx specific but severe problem of memory leak as function of traffic. For the rest the board and OpenWrt work very nicely now.

(Last edited by doddel on 9 Nov 2009, 15:58)