Re: [ath9k-devel] Disable BAW sliding
Hi all, Is there anybody who worked on BAW(Block Ack Window) sliding mechanism in ath9k? Is it possible to disable this mechanism? What would you want to do that for? It seems to me that all this would accomplish is to get the tx path stuck after a number of packets were sent. - Felix I want to transmit fixed size of aggregate frames all the time, i.e., despite channel errors, aggregate frames should always include 32 subframes. I'm working on that but I didn't get significant result yet. Is it feasible at all? If yes, what can be your suggestions? Thanks in advance - Shinnazar ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Tplink TL-WN822N drops out connections randomly on Arch Linux with Kernel 3.9.4 (Mark Lee)
Hello, I do also have similar device and am facing a strange problem with it. After booting up the machine I am unable to connect to certain wireless AP. That is an old Owislink WL5460 router set up in 2.4B+G mode with WPA encryption. After connecting to another AP e.g. non encrypted AP made up of my Android phone or even encrypted AP created on an iphone I can then connect to the problematic AP. I am on arch linux currently with kernel 3.9.6. The issue started happening as I have updated my kernel to 3.9.1. Previously everything has been working fine wor me. Here are some more details $ lsusb | grep Ather Bus 002 Device 005: ID 0cf3:9271 Atheros Communications, Inc. AR9271 802.11n $ iw dev wlp0s26u1u6 get power_save Power save: off $ dmesg | grep 00:4f:62:05:df:2d [ 23.237360] wlp0s26u1u6: authenticate with 00:4f:62:05:df:2d [ 23.331989] wlp0s26u1u6: send auth to 00:4f:62:05:df:2d (try 1/3) [ 26.376049] wlp0s26u1u6: send auth to 00:4f:62:05:df:2d (try 2/3) [ 28.335490] wlp0s26u1u6: deauthenticating from 00:4f:62:05:df:2d by local choice (reason=3) --- snip --- This is repeating over and over again until I connect to something else. And then the final successfull connection to this AP looks like... [ 252.381096] wlp0s26u1u6: authenticate with 00:4f:62:05:df:2d [ 252.520920] wlp0s26u1u6: send auth to 00:4f:62:05:df:2d (try 1/3) [ 252.524098] wlp0s26u1u6: associate with 00:4f:62:05:df:2d (try 1/3) [ 252.538293] wlp0s26u1u6: RX AssocResp from 00:4f:62:05:df:2d (capab=0x411 status=0 aid=3) $ dmesg | grep ath9k_htc [7.353707] usb 2-1.6: ath9k_htc: Firmware htc_9271.fw requested [7.353772] usbcore: registered new interface driver ath9k_htc [7.829552] usb 2-1.6: ath9k_htc: Transferred FW: htc_9271.fw, size: 51272 [8.064565] ath9k_htc 2-1.6:1.0: ath9k_htc: HTC initialized with 33 credits [8.255145] ath9k_htc 2-1.6:1.0: ath9k_htc: FW Version: 1.3 [ 252.522905] ath9k_htc 2-1.6:1.0 wlp0s26u1u6: disabling HT as WMM/QoS is not supported by the AP [ 252.522908] ath9k_htc 2-1.6:1.0 wlp0s26u1u6: disabling VHT as WMM/QoS is not supported by the AP $ sudo iw dev wlp0s26u1u6 scan dump BSS 00:4f:62:05:df:2d(on wlp0s26u1u6) -- associated TSF: 254735798022 usec (2d, 22:45:35) freq: 2412 beacon interval: 100 TUs capability: ESS Privacy ShortSlotTime (0x0411) signal: -61.00 dBm last seen: 103493 ms ago Information elements from Probe Response frame: SSID: predok Supported rates: 1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 DS Parameter set: channel 1 ERP: no flags Extended supported rates: 24.0 36.0 48.0 54.0 WPA: * Version: 1 * Group cipher: TKIP * Pairwise ciphers: TKIP * Authentication suites: PSK RSN: * Version: 1 * Group cipher: TKIP * Pairwise ciphers: CCMP * Authentication suites: PSK * Capabilities: (0x) $ sudo iw dev wlp0s26u1u6 scan dump [sudo] password for peto: BSS 00:4f:62:05:df:2d(on wlp0s26u1u6) TSF: 255417536590 usec (2d, 22:56:57) freq: 2412 beacon interval: 100 TUs capability: ESS Privacy ShortSlotTime (0x0411) signal: -59.00 dBm last seen: 386 ms ago Information elements from Probe Response frame: SSID: predok Supported rates: 1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 DS Parameter set: channel 1 ERP: no flags Extended supported rates: 24.0 36.0 48.0 54.0 WPA: * Version: 1 * Group cipher: TKIP * Pairwise ciphers: TKIP * Authentication suites: PSK RSN: * Version: 1 * Group cipher: TKIP * Pairwise ciphers: CCMP * Authentication suites: PSK * Capabilities: (0x) Thanks and greetings Peter On 02.06.2013 19:00, Oleksij Rempel wrote: Can you please do some test: - disable STBC on access point. You will probably need to edit hostapd.conf manually. - change or disable encryption type. Am 02.06.2013 18:39, schrieb Mark E. Lee: Access Point Firmware: DD-WRT v24-sp2 (03/19/12) std Access Point Hardware: netgear-wnr2000v3 Output of # iw dev wlan0 get power_save : Power save: off Output of $ iw dev wlan0 scan dump : Attached log file (unix ending) On Sun, 2013-06-02 at 12:00 +0200, ath9k-devel-request at lists.ath9k.org wrote: Send ath9k-devel mailing list submissions to ath9k-devel at lists.ath9k.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.ath9k.org/mailman/listinfo/ath9k-devel or, via email, send a message with subject or body 'help' to ath9k-devel-request at lists.ath9k.org You can reach the person managing the list at ath9k-devel-owner at lists.ath9k.org When replying, please edit your Subject line so it is more specific than Re: Contents of ath9k-devel digest... ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org
Re: [ath9k-devel] Tplink TL-WN822N drops out connections randomly on Arch Linux with Kernel 3.9.4 (Mark Lee)
Hello, I am afraid I don't know how to do this. Do I have to recompile the whole kernel testing each commit or should I just recompile the driver or even track firmware changes? Can you please point me to somewhere where I can read on how to proceed? Greetings Peter On 18.06.2013 21:41, Oleksij Rempel wrote: Hi Peter, if it is regression, can you please do git bisect to find commit affecting your connection. It can be outside of ath9k_htc source. Am 18.06.2013 20:20, schrieb Peter Vágner: Hello, I do also have similar device and am facing a strange problem with it. After booting up the machine I am unable to connect to certain wireless AP. That is an old Owislink WL5460 router set up in 2.4B+G mode with WPA encryption. After connecting to another AP e.g. non encrypted AP made up of my Android phone or even encrypted AP created on an iphone I can then connect to the problematic AP. I am on arch linux currently with kernel 3.9.6. The issue started happening as I have updated my kernel to 3.9.1. Previously everything has been working fine wor me. Here are some more details $ lsusb | grep Ather Bus 002 Device 005: ID 0cf3:9271 Atheros Communications, Inc. AR9271 802.11n $ iw dev wlp0s26u1u6 get power_save Power save: off $ dmesg | grep 00:4f:62:05:df:2d [ 23.237360] wlp0s26u1u6: authenticate with 00:4f:62:05:df:2d [ 23.331989] wlp0s26u1u6: send auth to 00:4f:62:05:df:2d (try 1/3) [ 26.376049] wlp0s26u1u6: send auth to 00:4f:62:05:df:2d (try 2/3) [ 28.335490] wlp0s26u1u6: deauthenticating from 00:4f:62:05:df:2d by local choice (reason=3) --- snip --- This is repeating over and over again until I connect to something else. And then the final successfull connection to this AP looks like... [ 252.381096] wlp0s26u1u6: authenticate with 00:4f:62:05:df:2d [ 252.520920] wlp0s26u1u6: send auth to 00:4f:62:05:df:2d (try 1/3) [ 252.524098] wlp0s26u1u6: associate with 00:4f:62:05:df:2d (try 1/3) [ 252.538293] wlp0s26u1u6: RX AssocResp from 00:4f:62:05:df:2d (capab=0x411 status=0 aid=3) $ dmesg | grep ath9k_htc [7.353707] usb 2-1.6: ath9k_htc: Firmware htc_9271.fw requested [7.353772] usbcore: registered new interface driver ath9k_htc [7.829552] usb 2-1.6: ath9k_htc: Transferred FW: htc_9271.fw, size: 51272 [8.064565] ath9k_htc 2-1.6:1.0: ath9k_htc: HTC initialized with 33 credits [8.255145] ath9k_htc 2-1.6:1.0: ath9k_htc: FW Version: 1.3 [ 252.522905] ath9k_htc 2-1.6:1.0 wlp0s26u1u6: disabling HT as WMM/QoS is not supported by the AP [ 252.522908] ath9k_htc 2-1.6:1.0 wlp0s26u1u6: disabling VHT as WMM/QoS is not supported by the AP $ sudo iw dev wlp0s26u1u6 scan dump BSS 00:4f:62:05:df:2d(on wlp0s26u1u6) -- associated TSF: 254735798022 usec (2d, 22:45:35) freq: 2412 beacon interval: 100 TUs capability: ESS Privacy ShortSlotTime (0x0411) signal: -61.00 dBm last seen: 103493 ms ago Information elements from Probe Response frame: SSID: predok Supported rates: 1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 DS Parameter set: channel 1 ERP: no flags Extended supported rates: 24.0 36.0 48.0 54.0 WPA: * Version: 1 * Group cipher: TKIP * Pairwise ciphers: TKIP * Authentication suites: PSK RSN: * Version: 1 * Group cipher: TKIP * Pairwise ciphers: CCMP * Authentication suites: PSK * Capabilities: (0x) $ sudo iw dev wlp0s26u1u6 scan dump [sudo] password for peto: BSS 00:4f:62:05:df:2d(on wlp0s26u1u6) TSF: 255417536590 usec (2d, 22:56:57) freq: 2412 beacon interval: 100 TUs capability: ESS Privacy ShortSlotTime (0x0411) signal: -59.00 dBm last seen: 386 ms ago Information elements from Probe Response frame: SSID: predok Supported rates: 1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 DS Parameter set: channel 1 ERP: no flags Extended supported rates: 24.0 36.0 48.0 54.0 WPA: * Version: 1 * Group cipher: TKIP * Pairwise ciphers: TKIP * Authentication suites: PSK RSN: * Version: 1 * Group cipher: TKIP * Pairwise ciphers: CCMP * Authentication suites: PSK * Capabilities: (0x) Thanks and greetings ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] ath9k AP Beacon vs AdHoc Beacon Style
Hi everybody, I am new to this forum. I am reading about beacon in ath9k and come across AP and AdHoc style beaconing. The question i have is what is the main difference that plays the key role in selecting which beacon style to be used when somebody creating new kind of communication. Is it because of chipset, reusability, or some other factors?. Need your kind help here. Rgds, Zaki. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] ath9k_htc: Firmware - htc_9271.fw download failed
Hi, I am porting ar9271 wifi module to an arm platform, after some days try, still can not solve the problem, please help. Environment: 1. lilnux kernel version 2.6.28. 2. compat-wireless-2011-12-31-p 3. without udev, but with mdev 4. firmware puts in lib/firmware/htc_9271.fw compile ok, but when install ath9k_htc.ko, get error message: == usb 1-1: new high speed USB device using FOTG2XX_DRV and address 4 port status 10009 2nd port status 10009 usb 1-1: configuration #1 chosen from 1 choice usb 1-1: ath9k_htc: Firmware - htc_9271.fw download failed ath9k_htc: probe of 1-1:1.0 failed with error -22 === ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] ath9k_htc: station unable to authenticate
Hi, After a lot of git-bisecting and other testing, it appears that commit 382a103b2b528a3085cde4ac56fc69d92a828b72 (linux-stable.git) is the culprit. To reproduce the problem, use backports-20130607, and the ath9k defconfig (with no change otherwise). The station is unable to authenticate with WPA2 to the AP. Interestingly enough, if a monitor vif is created and upped beforehand, the authentication succeeds. After reverting the commit, authentication succeeds very quickly (without the need to up a monitor vif), just as expected. Note that I have kernel 3.8.0 (as per Ubuntu 13.04) and that original ath9k_htc driver works as expected. This has been also tested on Debian with driver from original kernel 3.9 (i.e. without backports). For the moment I can live with the commit reverted, but I suppose it's been there to fix something else, so this should probably be looked into by someone more knowledgeable than me. Ignacy -- A person is shit's way of making more shit. -- S. Barnett, anthropologist. -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: station unable to authenticate
So, regression was introduced by this patch: Author: Johannes Berg johannes.b...@intel.com Date: Fri Mar 22 22:30:09 2013 +0100 mac80211: fix idle handling sequence Corey Richardson reported that my idle handling cleanup (commit fd0f979a1b, mac80211: simplify idle handling) broke ath9k_htc. The reason appears to be that it wants to go out of idle before switching channels. To fix it, reimplement that sequence. Reported-by: Corey Richardson co...@octayn.net Signed-off-by: Johannes Berg johannes.b...@intel.com Johannes, can you please take a look on it. Am 19.06.2013 13:58, schrieb Ignacy Gawedzki: Hi, After a lot of git-bisecting and other testing, it appears that commit 382a103b2b528a3085cde4ac56fc69d92a828b72 (linux-stable.git) is the culprit. To reproduce the problem, use backports-20130607, and the ath9k defconfig (with no change otherwise). The station is unable to authenticate with WPA2 to the AP. Interestingly enough, if a monitor vif is created and upped beforehand, the authentication succeeds. After reverting the commit, authentication succeeds very quickly (without the need to up a monitor vif), just as expected. Note that I have kernel 3.8.0 (as per Ubuntu 13.04) and that original ath9k_htc driver works as expected. This has been also tested on Debian with driver from original kernel 3.9 (i.e. without backports). For the moment I can live with the commit reverted, but I suppose it's been there to fix something else, so this should probably be looked into by someone more knowledgeable than me. Ignacy -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: Firmware - htc_9271.fw download failed
Am 19.06.2013 12:14, schrieb Bo Shi:
Hi,
I am porting ar9271 wifi module to an arm platform, after some days
try, still can not solve the problem, please help.
Environment:
1. lilnux kernel version 2.6.28.
2. compat-wireless-2011-12-31-p
3. without udev, but with mdev
4. firmware puts in lib/firmware/htc_9271.fw
compile ok, but when install ath9k_htc.ko, get error message:
==
usb 1-1: new high speed USB device using FOTG2XX_DRV and address 4
port status 10009
2nd port status 10009
usb 1-1: configuration #1 chosen from 1 choice
usb 1-1: ath9k_htc: Firmware - htc_9271.fw download failed
ath9k_htc: probe of 1-1:1.0 failed with error -22
===
Hmm...
Firmware - htc_9271.fw download failed comes because
ath9k_hif_usb_download_fw returned -ENOMEM or -EIO
but probe of 1-1:1.0 failed with error -22 is -EINVAL.
Try attached patch. may be we will find exact reason.
--
Regards,
Oleksij
diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c b/drivers/net/wireless/ath/ath9k/hif_usb.c
index f5dda84..2b00872 100644
--- a/drivers/net/wireless/ath/ath9k/hif_usb.c
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
@@ -1014,8 +1014,8 @@ static int ath9k_hif_usb_download_fw(struct hif_device_usb *hif_dev)
FIRMWARE_DOWNLOAD_COMP,
0x40 | USB_DIR_OUT,
firm_offset 8, 0, NULL, 0, HZ);
- if (err)
- return -EIO;
+ if (err)
+ return err;
dev_info(hif_dev-udev-dev, ath9k_htc: Transferred FW: %s, size: %ld\n,
hif_dev-fw_name, (unsigned long) hif_dev-fw_size);
@@ -1032,8 +1032,8 @@ static int ath9k_hif_usb_dev_init(struct hif_device_usb *hif_dev)
ret = ath9k_hif_usb_download_fw(hif_dev);
if (ret) {
dev_err(hif_dev-udev-dev,
- ath9k_htc: Firmware - %s download failed\n,
- hif_dev-fw_name);
+ ath9k_htc: Firmware - %s download failed (error %i)\n,
+ hif_dev-fw_name, ret);
return ret;
}
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: station unable to authenticate
mac80211: fix idle handling sequence Corey Richardson reported that my idle handling cleanup (commit fd0f979a1b, mac80211: simplify idle handling) broke ath9k_htc. The reason appears to be that it wants to go out of idle before switching channels. To fix it, reimplement that sequence. Reported-by: Corey Richardson co...@octayn.net Signed-off-by: Johannes Berg johannes.b...@intel.com Johannes, can you please take a look on it. Not very well, I don't know anything about ath9k. I'm willing to help out, but I can't really say what broke it. johannes Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052 ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: station unable to authenticate
Am 19.06.2013 15:08, schrieb Berg, Johannes: mac80211: fix idle handling sequence Corey Richardson reported that my idle handling cleanup (commit fd0f979a1b, mac80211: simplify idle handling) broke ath9k_htc. The reason appears to be that it wants to go out of idle before switching channels. To fix it, reimplement that sequence. Reported-by: Corey Richardson co...@octayn.net Signed-off-by: Johannes Berg johannes.b...@intel.com Johannes, can you please take a look on it. Not very well, I don't know anything about ath9k. I'm willing to help out, but I can't really say what broke it. hm.. looks like this code depends on power_save. is it correct? Ignacy, can you please take a look if power_save mode is enabled by you. iw dev wlan0 get power_save if yes. Try to disable it. I think last week power_save was set to disabled by default. There are too many bugs right now. -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: station unable to authenticate
On Wed, Jun 19, 2013 at 03:38:47PM +0200, thus spake Oleksij Rempel: hm.. looks like this code depends on power_save. is it correct? Ignacy, can you please take a look if power_save mode is enabled by you. iw dev wlan0 get power_save if yes. Try to disable it. Although I have been building with CFG80211_DEFAULT_PS=y, the iw get power_save command tells me it's off. I think last week power_save was set to disabled by default. There are too many bugs right now. I'll test without CFG80211_DEFAULT_PS, just to be sure. Thanks for the hint. -- NO CARRIER ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: station unable to authenticate
Btw, I'm a bit confused -- are you using ath9k_htc as per the subject, or ath9k? if it's ath9k_htc then I don't really understand why the patch that *fixed* it for Corey *broke* it for you? johannes ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: station unable to authenticate
On Wed, Jun 19, 2013 at 11:08 AM, Oleksij Rempel li...@rempel-privat.de wrote: Am 19.06.2013 16:11, schrieb Johannes Berg: Btw, I'm a bit confused -- are you using ath9k_htc as per the subject, or ath9k? if it's ath9k_htc then I don't really understand why the patch that *fixed* it for Corey *broke* it for you? johannes It will be interesting to get some more info from Corey, about his wireless setup. It seems many of my issues were related to a faulty WAP, once I replaced it with a different one 90% of my problems went away. What information do you want? ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: station unable to authenticate
Am 19.06.2013 16:11, schrieb Johannes Berg: Btw, I'm a bit confused -- are you using ath9k_htc as per the subject, or ath9k? if it's ath9k_htc then I don't really understand why the patch that *fixed* it for Corey *broke* it for you? johannes It will be interesting to get some more info from Corey, about his wireless setup. Ignacy wrote: The station is unable to authenticate with WPA2 to the AP. Interestingly enough, if a monitor vif is created and upped beforehand, the authentication succeeds. which looks more like power management issue. If monitore mode is enabled, no power sawing is done. But i use CFG80211_DEFAULT_PS=y on my system too and didn't had this issue. Even power_save=on is working. What else is different? Ignacy, Is it RPi + TL-WN722NC? -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] Is there a way to connect pairs of wifi cards to achieve full duplex
I would like to have a point to point full duplex link (outdoors). I realise that this can not be done with a single wifi card/antenna, I will need a pair. I only need a single point to point link, not a master/slave setup. I would want the low level protocol bits to work this way as well so that ACKS and management responses to work this way as well as data packets. Any ideas? David ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: station unable to authenticate
On Wed, Jun 19, 2013 at 05:08:12PM +0200, thus spake Oleksij Rempel: Ignacy wrote: The station is unable to authenticate with WPA2 to the AP. Interestingly enough, if a monitor vif is created and upped beforehand, the authentication succeeds. which looks more like power management issue. If monitore mode is enabled, no power sawing is done. But i use CFG80211_DEFAULT_PS=y on my system too and didn't had this issue. Even power_save=on is working. What else is different? Ignacy, Is it RPi + TL-WN722NC? Yes, absolutely, but it happens on a Dell XPS 13 as well (Ubuntu 13.04). -- P.S. All information contained in the above letter is false, for reasons of military security. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: station unable to authenticate
On Wed, Jun 19, 2013 at 07:59:39PM +0200, thus spake Ignacy Gawedzki: On Wed, Jun 19, 2013 at 05:08:12PM +0200, thus spake Oleksij Rempel: Ignacy, Is it RPi + TL-WN722NC? Yes, absolutely, but it happens on a Dell XPS 13 as well (Ubuntu 13.04). BTW, removing CFG80211_DEFAULT_PS doesn't make any difference. -- Everything is more fun naked except cooking with grease. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: Firmware - htc_9271.fw download failed
Hi Oleksij, I've patched your file, but it seems the code does not run to that part. plugin wifi module first time: = Compat-wireless backport release: compat-wireless-2011-12-28-p Backport based on linux-next.git next-20111228 cfg80211: Calling CRDA to update world regulatory domain usb 1-1: ath9k_htc: Firmware - htc_9271.fw download failed ath9k_htc: probe of 1-1:1.0 failed with error -22 usbcore: registered new interface driver ath9k_htc plugin wifi module second time: = usb 1-1: USB disconnect, address 2 usb 1-1: new high speed USB device using FOTG2XX_DRV and address 3 port status 10009 2nd port status 10009 usb 1-1: configuration #1 chosen from 1 choice usb 1-1: ath9k_htc: Firmware - htc_9271.fw download failed plugin wifi module thrid time: = ath9k_htc: probe of 1-1:1.0 failed with error -22 usb 1-1: USB disconnect, address 3 usb 1-1: new high speed USB device using FOTG2XX_DRV and address 4 port status 10009 2nd port status 10009 usb 1-1: configuration #1 chosen from 1 choice usb 1-1: ath9k_htc: Firmware - htc_9271.fw download failed ath9k_htc: probe of 1-1:1.0 failed with error -22 On Wed, Jun 19, 2013 at 9:21 PM, Oleksij Rempel li...@rempel-privat.dewrote: Am 19.06.2013 12:14, schrieb Bo Shi: Hi, I am porting ar9271 wifi module to an arm platform, after some days try, still can not solve the problem, please help. Environment: 1. lilnux kernel version 2.6.28. 2. compat-wireless-2011-12-31-p 3. without udev, but with mdev 4. firmware puts in lib/firmware/htc_9271.fw compile ok, but when install ath9k_htc.ko, get error message: ==**==**== usb 1-1: new high speed USB device using FOTG2XX_DRV and address 4 port status 10009 2nd port status 10009 usb 1-1: configuration #1 chosen from 1 choice usb 1-1: ath9k_htc: Firmware - htc_9271.fw download failed ath9k_htc: probe of 1-1:1.0 failed with error -22 ==**==**=== Hmm... Firmware - htc_9271.fw download failed comes because ath9k_hif_usb_download_fw returned -ENOMEM or -EIO but probe of 1-1:1.0 failed with error -22 is -EINVAL. Try attached patch. may be we will find exact reason. -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: Firmware - htc_9271.fw download failed
Am 19.06.2013 20:14, schrieb Bo Shi: Hi Oleksij, I've patched your file, but it seems the code does not run to that part. There is no other part in driver which will print this message ath9k_htc: Firmware - htc_9271.fw download failed. You probably trying unpatched kernel. plugin wifi module first time: = Compat-wireless backport release: compat-wireless-2011-12-28-p Backport based on linux-next.git next-20111228 cfg80211: Calling CRDA to update world regulator usb 1-1: ath9k_htc: Firmware - htc_9271.fw download failed ath9k_htc: probe of 1-1:1.0 failed with error -22 usbcore: registered new interface driver ath9k_htc plugin wifi module second time: = usb 1-1: USB disconnect, address 2 usb 1-1: new high speed USB device using FOTG2XX_DRV and address 3 port status 10009 2nd port status 10009 usb 1-1: configuration #1 chosen from 1 choice usb 1-1: ath9k_htc: Firmware - htc_9271.fw download failed plugin wifi module thrid time: = ath9k_htc: probe of 1-1:1.0 failed with error -22 usb 1-1: USB disconnect, address 3 usb 1-1: new high speed USB device using FOTG2XX_DRV and address 4 port status 10009 2nd port status 10009 usb 1-1: configuration #1 chosen from 1 choice usb 1-1: ath9k_htc: Firmware - htc_9271.fw download failed ath9k_htc: probe of 1-1:1.0 failed with error -22 On Wed, Jun 19, 2013 at 9:21 PM, Oleksij Rempel li...@rempel-privat.de mailto:li...@rempel-privat.de wrote: Am 19.06.2013 12:14, schrieb Bo Shi: Hi, I am porting ar9271 wifi module to an arm platform, after some days try, still can not solve the problem, please help. Environment: 1. lilnux kernel version 2.6.28. 2. compat-wireless-2011-12-31-p 3. without udev, but with mdev 4. firmware puts in lib/firmware/htc_9271.fw compile ok, but when install ath9k_htc.ko, get error message: ==__==__== usb 1-1: new high speed USB device using FOTG2XX_DRV and address 4 port status 10009 2nd port status 10009 usb 1-1: configuration #1 chosen from 1 choice usb 1-1: ath9k_htc: Firmware - htc_9271.fw download failed ath9k_htc: probe of 1-1:1.0 failed with error -22 ==__==__=== Hmm... Firmware - htc_9271.fw download failed comes because ath9k_hif_usb_download_fw returned -ENOMEM or -EIO but probe of 1-1:1.0 failed with error -22 is -EINVAL. Try attached patch. may be we will find exact reason. -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org mailto:ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: station unable to authenticate
Am 19.06.2013 17:11, schrieb Corey Richardson: On Wed, Jun 19, 2013 at 11:08 AM, Oleksij Rempel li...@rempel-privat.de wrote: Am 19.06.2013 16:11, schrieb Johannes Berg: Btw, I'm a bit confused -- are you using ath9k_htc as per the subject, or ath9k? if it's ath9k_htc then I don't really understand why the patch that *fixed* it for Corey *broke* it for you? johannes It will be interesting to get some more info from Corey, about his wireless setup. It seems many of my issues were related to a faulty WAP, once I replaced it with a different one 90% of my problems went away. What information do you want? Every thing about your old WAP and symptoms of problems you had. - hardware. also you ath9k_htc adapter too - firmware - configuration - iw dev wlan0 scan dump Currently we have diffetrent mystical bugs, which are impossible to reproduce some where else. So we will just collect every information we can find. -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: station unable to authenticate
Am 19.06.2013 20:03, schrieb Ignacy Gawedzki: On Wed, Jun 19, 2013 at 07:59:39PM +0200, thus spake Ignacy Gawedzki: On Wed, Jun 19, 2013 at 05:08:12PM +0200, thus spake Oleksij Rempel: Ignacy, Is it RPi + TL-WN722NC? Yes, absolutely, but it happens on a Dell XPS 13 as well (Ubuntu 13.04). BTW, removing CFG80211_DEFAULT_PS doesn't make any difference. Can you please tell more about your access point: - hardware - firmware - configuration - iw dev wlan0 scan dump -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: station unable to authenticate
On 06/19/2013 11:37 AM, Oleksij Rempel wrote: Am 19.06.2013 20:03, schrieb Ignacy Gawedzki: On Wed, Jun 19, 2013 at 07:59:39PM +0200, thus spake Ignacy Gawedzki: On Wed, Jun 19, 2013 at 05:08:12PM +0200, thus spake Oleksij Rempel: Ignacy, Is it RPi + TL-WN722NC? Yes, absolutely, but it happens on a Dell XPS 13 as well (Ubuntu 13.04). BTW, removing CFG80211_DEFAULT_PS doesn't make any difference. Can you please tell more about your access point: - hardware - firmware - configuration - iw dev wlan0 scan dump Does the ath9k_htc do it's own rate control, perhaps modelled on ath9k_rate_control algorithm? If so, that could be the problem...it has issues with associating when network conditions are poor... Thanks, Ben -- Ben Greear gree...@candelatech.com Candela Technologies Inc http://www.candelatech.com ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: station unable to authenticate
On Wed, Jun 19, 2013 at 2:36 PM, Oleksij Rempel li...@rempel-privat.de wrote: Every thing about your old WAP and symptoms of problems you had. - hardware. also you ath9k_htc adapter too The adapter is a netgear WNA1100. The WAP actually died, unfortunately, it will no longer boot up, and I no longer have it, but it was an HP ProCurve something-or-another. Sorry I can't be more useful :( ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: station unable to authenticate
On Wed, Jun 19, 2013 at 08:37:42PM +0200, thus spake Oleksij Rempel: Can you please tell more about your access point: - hardware - firmware - configuration - iw dev wlan0 scan dump I tested the thing with at least three different APs: - Netgear DG834Gv4 with latest firmware. - Netgear DG834Gv5 (don't know which firmware and can't check at this time). - hostapd (can't say which version at this time either) with the same ath9k_htc. All APs are configured for WPA2-PSK. The scan dump for the first AP: BSS 00:1e:2a:ed:35:70 (on wlan7) TSF: 163623606 usec (0d, 00:02:43) freq: 2412 beacon interval: 100 capability: ESS Privacy ShortSlotTime (0x0411) signal: -43.00 dBm last seen: 24 ms ago Information elements from Probe Response frame: SSID: Wolfnet Supported rates: 1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 DS Parameter set: channel 1 ERP: Barker_Preamble_Mode RSN: * Version: 1 * Group cipher: CCMP * Pairwise ciphers: CCMP * Authentication suites: PSK * Capabilities: 16-PTKSA-RC (0x000c) Extended supported rates: 6.0 9.0 12.0 48.0 WMM: * Parameter version 1 * u-APSD * BE: CW 15-1023, AIFSN 3 * BK: CW 15-1023, AIFSN 7 * VI: CW 7-15, AIFSN 2, TXOP 3008 usec * VO: CW 3-7, AIFSN 2, TXOP 1504 usec -- Save the whales. Feed the hungry. Free the mallocs. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: station unable to authenticate
On Wed, Jun 19, 2013 at 11:39:55AM -0700, thus spake Ben Greear: Does the ath9k_htc do it's own rate control, perhaps modelled on ath9k_rate_control algorithm? Do you mean ATH9K_LEGACY_RATE_CONTROL ? If so, that could be the problem...it has issues with associating when network conditions are poor... Frankly, I doubt this is the case. With so many different setups, and the AP is like one meter away from the station right now. -- The groove will take you through times without money much better than money will take you through times without groove. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] phy0: Chip reset failed
Hi, I have set up a mesh (batman-adv) with several TP-link TL-WN722 USB dongles (AR9271 chip). But at random times the wireless connection is dropped. After rebooting, I can read this in the log: Jun 19 11:56:24 ubuntumac kernel: [914836.592964] ath: phy3: Unable to remove station entry for: 64:70:02:22:ec:2e Jun 19 13:03:23 ubuntumac kernel: [918853.808862] ath: phy3: Chip reset failed Jun 19 13:03:23 ubuntumac kernel: [918853.808868] ath: phy3: Unable to reset channel (2412 Mhz) reset status -22 Jun 19 13:03:23 ubuntumac kernel: [918853.808869] ath: phy3: Unable to set channel kernel is: Linux ubuntumac 3.8.0-25-generic #37-Ubuntu SMP Thu Jun 6 20:47:07 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux kernel modules loaded for wireless: ath9k_htc 91536 0 ath9k_common 14055 1 ath9k_htc ath9k_hw 413680 2 ath9k_common,ath9k_htc ath23827 3 ath9k_common,ath9k_htc,ath9k_hw mac80211 606457 1 ath9k_htc cfg80211 510937 3 ath,mac80211,ath9k_htc I have tried patching the driver with https://dev.openwrt.org/browser/trunk/package/mac80211/patches/552-ath9k_rx_dma_stop_check.patch?rev=34910 but no luck. Any suggestions? ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH-WN 2/2] ath9k_htc: Add ethtool stats support.
From: Ben Greear gree...@candelatech.com
This provides some of the same info found in
the ath9k_htc debugfs through the standard ethtool stats API.
This logic is only supported when ath9k_htc debugfs kernel
feature is enabled, since that is the only time stats
are actually gathered.
Signed-off-by: Ben Greear gree...@candelatech.com
---
This patch is against wireless-next, and has been tested
against my 3.9 tree for quite a while.
drivers/net/wireless/ath/ath9k/hif_usb.c |8 ++-
drivers/net/wireless/ath/ath9k/htc.h | 14
drivers/net/wireless/ath/ath9k/htc_drv_debug.c | 81
drivers/net/wireless/ath/ath9k/htc_drv_main.c |6 ++
4 files changed, 108 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c
b/drivers/net/wireless/ath/ath9k/hif_usb.c
index f5dda84..9e582e1 100644
--- a/drivers/net/wireless/ath/ath9k/hif_usb.c
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
@@ -234,10 +234,15 @@ static inline void ath9k_skb_queue_complete(struct
hif_device_usb *hif_dev,
struct sk_buff *skb;
while ((skb = __skb_dequeue(queue)) != NULL) {
+#ifdef CONFIG_ATH9K_HTC_DEBUGFS
+ int ln = skb-len;
+#endif
ath9k_htc_txcompletion_cb(hif_dev-htc_handle,
skb, txok);
- if (txok)
+ if (txok) {
TX_STAT_INC(skb_success);
+ TX_STAT_ADD(skb_success_bytes, ln);
+ }
else
TX_STAT_INC(skb_failed);
}
@@ -620,6 +625,7 @@ static void ath9k_hif_usb_rx_stream(struct hif_device_usb
*hif_dev,
err:
for (i = 0; i pool_index; i++) {
+ RX_STAT_ADD(skb_completed_bytes, skb_pool[i]-len);
ath9k_htc_rx_msg(hif_dev-htc_handle, skb_pool[i],
skb_pool[i]-len, USB_WLAN_RX_PIPE);
RX_STAT_INC(skb_completed);
diff --git a/drivers/net/wireless/ath/ath9k/htc.h
b/drivers/net/wireless/ath/ath9k/htc.h
index 6bd556d..055d7c2 100644
--- a/drivers/net/wireless/ath/ath9k/htc.h
+++ b/drivers/net/wireless/ath/ath9k/htc.h
@@ -324,7 +324,9 @@ static inline struct ath9k_htc_tx_ctl *HTC_SKB_CB(struct
sk_buff *skb)
#ifdef CONFIG_ATH9K_HTC_DEBUGFS
#define TX_STAT_INC(c) (hif_dev-htc_handle-drv_priv-debug.tx_stats.c++)
+#define TX_STAT_ADD(c, a) (hif_dev-htc_handle-drv_priv-debug.tx_stats.c +=
a)
#define RX_STAT_INC(c) (hif_dev-htc_handle-drv_priv-debug.rx_stats.c++)
+#define RX_STAT_ADD(c, a) (hif_dev-htc_handle-drv_priv-debug.rx_stats.c +=
a)
#define CAB_STAT_INC priv-debug.tx_stats.cab_queued++
#define TX_QSTAT_INC(q) (priv-debug.tx_stats.queue_stats[q]++)
@@ -337,6 +339,7 @@ struct ath_tx_stats {
u32 buf_completed;
u32 skb_queued;
u32 skb_success;
+ u32 skb_success_bytes;
u32 skb_failed;
u32 cab_queued;
u32 queue_stats[IEEE80211_NUM_ACS];
@@ -345,6 +348,7 @@ struct ath_tx_stats {
struct ath_rx_stats {
u32 skb_allocated;
u32 skb_completed;
+ u32 skb_completed_bytes;
u32 skb_dropped;
u32 err_crc;
u32 err_decrypt_crc;
@@ -362,10 +366,20 @@ struct ath9k_debug {
struct ath_rx_stats rx_stats;
};
+void ath9k_htc_get_et_strings(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif,
+ u32 sset, u8 *data);
+int ath9k_htc_get_et_sset_count(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif, int sset);
+void ath9k_htc_get_et_stats(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif,
+ struct ethtool_stats *stats, u64 *data);
#else
#define TX_STAT_INC(c) do { } while (0)
+#define TX_STAT_ADD(c, a) do { } while (0)
#define RX_STAT_INC(c) do { } while (0)
+#define RX_STAT_ADD(c, a) do { } while (0)
#define CAB_STAT_INC do { } while (0)
#define TX_QSTAT_INC(c) do { } while (0)
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_debug.c
b/drivers/net/wireless/ath/ath9k/htc_drv_debug.c
index 632d13d..7416d58 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_debug.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_debug.c
@@ -902,6 +902,87 @@ static const struct file_operations fops_modal_eeprom = {
.llseek = default_llseek,
};
+
+/* Ethtool support for get-stats */
+#define AMKSTR(nm) #nm _BE, #nm _BK, #nm _VI, #nm _VO
+static const char ath9k_htc_gstrings_stats[][ETH_GSTRING_LEN] = {
+ tx_pkts_nic,
+ tx_bytes_nic,
+ rx_pkts_nic,
+ rx_bytes_nic,
+
+ AMKSTR(d_tx_pkts),
+
+ d_rx_crc_err,
+ d_rx_decrypt_crc_err,
+ d_rx_phy_err,
+ d_rx_mic_err,
+ d_rx_pre_delim_crc_err,
+ d_rx_post_delim_crc_err,
+ d_rx_decrypt_busy_err,
+
+ d_rx_phyerr_radar,
+ d_rx_phyerr_ofdm_timing,
+ d_rx_phyerr_cck_timing,
+
+};
+#define
[ath9k-devel] [PATCH-WN 1/2] ath9k_htc: Support reporting tx and rx chain mask.
From: Ben Greear gree...@candelatech.com
Signed-off-by: Ben Greear gree...@candelatech.com
---
This is against wireless-next, and has been in my 3.9 tree for
some time.
drivers/net/wireless/ath/ath9k/htc.h |2 +
drivers/net/wireless/ath/ath9k/htc_drv_debug.c | 16 +-
drivers/net/wireless/ath/ath9k/htc_drv_init.c |7
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 38
4 files changed, 48 insertions(+), 15 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/htc.h
b/drivers/net/wireless/ath/ath9k/htc.h
index 6958103..6bd556d 100644
--- a/drivers/net/wireless/ath/ath9k/htc.h
+++ b/drivers/net/wireless/ath/ath9k/htc.h
@@ -583,6 +583,8 @@ bool ath9k_htc_setpower(struct ath9k_htc_priv *priv,
void ath9k_start_rfkill_poll(struct ath9k_htc_priv *priv);
void ath9k_htc_rfkill_poll_state(struct ieee80211_hw *hw);
+struct base_eep_header *ath9k_htc_get_eeprom_base(struct ath9k_htc_priv *priv);
+
#ifdef CONFIG_MAC80211_LEDS
void ath9k_init_leds(struct ath9k_htc_priv *priv);
void ath9k_deinit_leds(struct ath9k_htc_priv *priv);
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_debug.c
b/drivers/net/wireless/ath/ath9k/htc_drv_debug.c
index 87110de5..632d13d 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_debug.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_debug.c
@@ -496,21 +496,7 @@ static ssize_t read_file_base_eeprom(struct file *file,
char __user *user_buf,
ssize_t retval = 0;
char *buf;
- /*
-* This can be done since all the 3 EEPROM families have the
-* same base header upto a certain point, and we are interested in
-* the data only upto that point.
-*/
-
- if (AR_SREV_9271(priv-ah))
- pBase = (struct base_eep_header *)
- priv-ah-eeprom.map4k.baseEepHeader;
- else if (priv-ah-hw_version.usbdev == AR9280_USB)
- pBase = (struct base_eep_header *)
- priv-ah-eeprom.def.baseEepHeader;
- else if (priv-ah-hw_version.usbdev == AR9287_USB)
- pBase = (struct base_eep_header *)
- priv-ah-eeprom.map9287.baseEepHeader;
+ pBase = ath9k_htc_get_eeprom_base(priv);
if (pBase == NULL) {
ath_err(common, Unknown EEPROM type\n);
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_init.c
b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
index bb0ba9e..925c5b0 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_init.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
@@ -716,6 +716,7 @@ static void ath9k_set_hw_capab(struct ath9k_htc_priv *priv,
struct ieee80211_hw *hw)
{
struct ath_common *common = ath9k_hw_common(priv-ah);
+ struct base_eep_header *pBase;
hw-flags = IEEE80211_HW_SIGNAL_DBM |
IEEE80211_HW_AMPDU_AGGREGATION |
@@ -771,6 +772,12 @@ static void ath9k_set_hw_capab(struct ath9k_htc_priv *priv,
priv-sbands[IEEE80211_BAND_5GHZ].ht_cap);
}
+ pBase = ath9k_htc_get_eeprom_base(priv);
+ if (pBase) {
+ hw-wiphy-available_antennas_rx = pBase-rxMask;
+ hw-wiphy-available_antennas_tx = pBase-txMask;
+ }
+
SET_IEEE80211_PERM_ADDR(hw, common-macaddr);
}
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index eaa94fe..ef68857 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -1774,6 +1774,43 @@ static int ath9k_htc_get_stats(struct ieee80211_hw *hw,
return 0;
}
+struct base_eep_header *ath9k_htc_get_eeprom_base(struct ath9k_htc_priv *priv)
+{
+ struct base_eep_header *pBase = NULL;
+ /*
+* This can be done since all the 3 EEPROM families have the
+* same base header upto a certain point, and we are interested in
+* the data only upto that point.
+*/
+
+ if (AR_SREV_9271(priv-ah))
+ pBase = (struct base_eep_header *)
+ priv-ah-eeprom.map4k.baseEepHeader;
+ else if (priv-ah-hw_version.usbdev == AR9280_USB)
+ pBase = (struct base_eep_header *)
+ priv-ah-eeprom.def.baseEepHeader;
+ else if (priv-ah-hw_version.usbdev == AR9287_USB)
+ pBase = (struct base_eep_header *)
+ priv-ah-eeprom.map9287.baseEepHeader;
+ return pBase;
+}
+
+
+static int ath9k_htc_get_antenna(struct ieee80211_hw *hw, u32 *tx_ant,
+u32 *rx_ant)
+{
+ struct ath9k_htc_priv *priv = hw-priv;
+ struct base_eep_header *pBase = ath9k_htc_get_eeprom_base(priv);
+ if (pBase) {
+ *tx_ant = pBase-txMask;
+ *rx_ant = pBase-rxMask;
+ } else {
+ *tx_ant = 0;
+ *rx_ant = 0;
+ }
+ return 0;
+}
+
Re: [ath9k-devel] Is there a way to connect pairs of wifi cards to achieve full duplex
On 06/19/2013 09:50 AM, David Goodenough wrote: I would like to have a point to point full duplex link (outdoors). I realise that this can not be done with a single wifi card/antenna, I will need a pair. I only need a single point to point link, not a master/slave setup. I would want the low level protocol bits to work this way as well so that ACKS and management responses to work this way as well as data packets. Any ideas? That sounds interesting. I wonder if some specialized type of bonding interface could do the trick. I'd guess you wouldn't need any specific driver support. The bond would just always TX on pair A (with peer TX pair B). I'd ask around on the bonding mailing list (assuming such thing exists) and see if they have any suggestions. Thanks, Ben David ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel -- Ben Greear gree...@candelatech.com Candela Technologies Inc http://www.candelatech.com ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Is there a way to connect pairs of wifi cards to achieve full duplex
On 06/19/2013 03:56 PM, Adrian Chadd wrote: .. just keep in mind that adjacent high power transmitters can actually leak enough RF to trigger ADC saturation and thus the device may actually not try to decode anything. Thus, whilst your TX is TXing, the RX side may be unhappy. :-) We've had decent multi-NIC throughput when there is a mostly-solid aluminium chassis plate between the NICs, and when one is on 2.4 and the other is on 5Ghz. Pretty much anything else is pushing your luck though :) Ben -- Ben Greear gree...@candelatech.com Candela Technologies Inc http://www.candelatech.com ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Is there a way to connect pairs of wifi cards to achieve full duplex
.. just keep in mind that adjacent high power transmitters can actually leak enough RF to trigger ADC saturation and thus the device may actually not try to decode anything. Thus, whilst your TX is TXing, the RX side may be unhappy. :-) Adrian (This is why TDMA is awesome.) On 19 June 2013 15:09, Ben Greear gree...@candelatech.com wrote: On 06/19/2013 09:50 AM, David Goodenough wrote: I would like to have a point to point full duplex link (outdoors). I realise that this can not be done with a single wifi card/antenna, I will need a pair. I only need a single point to point link, not a master/slave setup. I would want the low level protocol bits to work this way as well so that ACKS and management responses to work this way as well as data packets. Any ideas? That sounds interesting. I wonder if some specialized type of bonding interface could do the trick. I'd guess you wouldn't need any specific driver support. The bond would just always TX on pair A (with peer TX pair B). I'd ask around on the bonding mailing list (assuming such thing exists) and see if they have any suggestions. Thanks, Ben David ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel -- Ben Greear gree...@candelatech.com Candela Technologies Inc http://www.candelatech.com ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: Firmware - htc_9271.fw download failed
Hi Oleksij, I am new to ath9k, may be a stupid question, what do you mean unpached kernel, I need to patch something to linux kernel directly? my step to compile compat-wireless is: 1. decompress new instance of compat-wireless-2011-12-31-p 2. select driver: ./scripts/driver-select ath9k_htc, then patch the diff you provided me. 3. make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- KLIB=/usr/src/arm-linux-2.6.28/linux-2.6.28-fa KLIB_BUILD=/usr/src/arm-linux-2.6.28/linux-2.6.28-fa 4. copy all the ko files to embedded system's folder: /lib/modules/2.6.28/kernel 5. insmod all the ko, then depmod -s 6. plugin wireless card Am I missing something? thanks in advance. On Thu, Jun 20, 2013 at 2:18 AM, Oleksij Rempel li...@rempel-privat.dewrote: Am 19.06.2013 20:14, schrieb Bo Shi: Hi Oleksij, I've patched your file, but it seems the code does not run to that part. There is no other part in driver which will print this message ath9k_htc: Firmware - htc_9271.fw download failed. You probably trying unpatched kernel. plugin wifi module first time: = Compat-wireless backport release: compat-wireless-2011-12-28-p Backport based on linux-next.git next-20111228 cfg80211: Calling CRDA to update world regulator usb 1-1: ath9k_htc: Firmware - htc_9271.fw download failed ath9k_htc: probe of 1-1:1.0 failed with error -22 usbcore: registered new interface driver ath9k_htc plugin wifi module second time: = usb 1-1: USB disconnect, address 2 usb 1-1: new high speed USB device using FOTG2XX_DRV and address 3 port status 10009 2nd port status 10009 usb 1-1: configuration #1 chosen from 1 choice usb 1-1: ath9k_htc: Firmware - htc_9271.fw download failed plugin wifi module thrid time: = ath9k_htc: probe of 1-1:1.0 failed with error -22 usb 1-1: USB disconnect, address 3 usb 1-1: new high speed USB device using FOTG2XX_DRV and address 4 port status 10009 2nd port status 10009 usb 1-1: configuration #1 chosen from 1 choice usb 1-1: ath9k_htc: Firmware - htc_9271.fw download failed ath9k_htc: probe of 1-1:1.0 failed with error -22 On Wed, Jun 19, 2013 at 9:21 PM, Oleksij Rempel li...@rempel-privat.de mailto:li...@rempel-privat.de** wrote: Am 19.06.2013 12:14, schrieb Bo Shi: Hi, I am porting ar9271 wifi module to an arm platform, after some days try, still can not solve the problem, please help. Environment: 1. lilnux kernel version 2.6.28. 2. compat-wireless-2011-12-31-p 3. without udev, but with mdev 4. firmware puts in lib/firmware/htc_9271.fw compile ok, but when install ath9k_htc.ko, get error message: ==**__** ==__== usb 1-1: new high speed USB device using FOTG2XX_DRV and address 4 port status 10009 2nd port status 10009 usb 1-1: configuration #1 chosen from 1 choice usb 1-1: ath9k_htc: Firmware - htc_9271.fw download failed ath9k_htc: probe of 1-1:1.0 failed with error -22 ==**__** ==__=== Hmm... Firmware - htc_9271.fw download failed comes because ath9k_hif_usb_download_fw returned -ENOMEM or -EIO but probe of 1-1:1.0 failed with error -22 is -EINVAL. Try attached patch. may be we will find exact reason. -- Regards, Oleksij __**_ ath9k-devel mailing list ath9k-devel@lists.ath9k.org mailto:ath9k-devel@lists.**ath9k.orgath9k-devel@lists.ath9k.org https://lists.ath9k.org/**mailman/listinfo/ath9k-develhttps://lists.ath9k.org/mailman/listinfo/ath9k-devel -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: station unable to authenticate
Am 19.06.2013 21:33, schrieb Ignacy Gawedzki: On Wed, Jun 19, 2013 at 08:37:42PM +0200, thus spake Oleksij Rempel: Can you please tell more about your access point: - hardware - firmware - configuration - iw dev wlan0 scan dump I tested the thing with at least three different APs: - Netgear DG834Gv4 with latest firmware. this one is BG with Broadcom BCM4318. Is here original firmware or openwrt? - Netgear DG834Gv5 (don't know which firmware and can't check at this time). this is BG with Conexant CX94610 - hostapd (can't say which version at this time either) with the same ath9k_htc. this one is actually BGN, did you configured it for N? Can you please provide your hostapd.conf. Do you have problems on all 3 configurations? Can you please test it with some N (HT) capable AP. But please, not with N-draft certified AP. -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: Firmware - htc_9271.fw download failed
Hi Bo, i can imagine two variants: - patch was rejected. you will need to edit this file manually: drivers/net/wireless/ath/ath9k/hif_usb.c - kernel was patched and compiled correctly, but your system still uses old ath9k_htc module. Am 20.06.2013 03:58, schrieb Bo Shi: Hi Oleksij, I am new to ath9k, may be a stupid question, what do you mean unpached kernel, I need to patch something to linux kernel directly? my step to compile compat-wireless is: 1. decompress new instance of compat-wireless-2011-12-31-p 2. select driver: ./scripts/driver-select ath9k_htc, then patch the diff you provided me. 3. make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- KLIB=/usr/src/arm-linux-2.6.28/linux-2.6.28-fa KLIB_BUILD=/usr/src/arm-linux-2.6.28/linux-2.6.28-fa 4. copy all the ko files to embedded system's folder: /lib/modules/2.6.28/kernel 5. insmod all the ko, then depmod -s 6. plugin wireless card Am I missing something? thanks in advance. -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
