Re: [ath9k-devel] ath9k_htc: station unable to authenticate
On Thu, Jun 20, 2013 at 07:33:30AM +0200, thus spake Oleksij Rempel: Am 19.06.2013 21:33, schrieb Ignacy Gawedzki: 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? Original firmware, since OpenWRT doesn't support the ADSL chip. - 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. I'll manage to get the configuration as soon as possible. It seems the association problem went away since I patched the drivers on the AP too, so unpatching the drivers on the station is not enough to reproduce the problem. I'll unpatch the drivers on the AP and re-run the test. Do you have problems on all 3 configurations? On both Netgears for sure. For hostapd I'll confirm that in a little while. Can you please test it with some N (HT) capable AP. But please, not with N-draft certified AP. Is ath9k_htc N-capable? -- I used to have a sig, but I've stopped smoking now. ___ 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 20.06.2013 08:39, schrieb Ignacy Gawedzki: On Thu, Jun 20, 2013 at 07:33:30AM +0200, thus spake Oleksij Rempel: Am 19.06.2013 21:33, schrieb Ignacy Gawedzki: 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? Original firmware, since OpenWRT doesn't support the ADSL chip. - 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. I'll manage to get the configuration as soon as possible. It seems the association problem went away since I patched the drivers on the AP too, so unpatching the drivers on the station is not enough to reproduce the problem. I'll unpatch the drivers on the AP and re-run the test. Do you have problems on all 3 configurations? On both Netgears for sure. For hostapd I'll confirm that in a little while. Can you please test it with some N (HT) capable AP. But please, not with N-draft certified AP. Is ath9k_htc N-capable? Yes, if hostapd configured properly. Question to Corey, i assume your old AP was supporting only BG networks. And your new one, which is working fine, supports N? -- 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
Ignacy Gawedzki wrote: 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. Can you test if this patch helps (without reverting the mac80211 commit) ? diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c b/drivers/net/wireless/ath/ath9k/htc_drv_main.c index eaa94fe..fba6ea7 100644 --- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c +++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c @@ -1183,7 +1183,7 @@ static int ath9k_htc_config(struct ieee80211_hw *hw, u32 changed) mutex_lock(priv-htc_pm_lock); priv-ps_idle = !!(conf-flags IEEE80211_CONF_IDLE); - if (priv-ps_idle) + if (!priv-ps_idle) chip_reset = true; mutex_unlock(priv-htc_pm_lock); Sujith ___ 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 Thu, Jun 20, 2013 at 12:39:29PM +0530, thus spake Sujith Manoharan: Ignacy Gawedzki wrote: 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. Can you test if this patch helps (without reverting the mac80211 commit) ? It works indeed, at least with the DG834Gv4. diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c b/drivers/net/wireless/ath/ath9k/htc_drv_main.c index eaa94fe..fba6ea7 100644 --- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c +++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c @@ -1183,7 +1183,7 @@ static int ath9k_htc_config(struct ieee80211_hw *hw, u32 changed) mutex_lock(priv-htc_pm_lock); priv-ps_idle = !!(conf-flags IEEE80211_CONF_IDLE); - if (priv-ps_idle) + if (!priv-ps_idle) chip_reset = true; mutex_unlock(priv-htc_pm_lock); Sujith -- The whole problem with the world is that fools and fanatics are always so certain of themselves, and wiser people so full of doubts. - Bertrand Russell ___ 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
Ignacy Gawedzki wrote: Can you test if this patch helps (without reverting the mac80211 commit) ? It works indeed, at least with the DG834Gv4. Thanks for testing. I've posted the patch: https://patchwork.kernel.org/patch/2753741/ Sujith ___ 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
Oleksij Rempel wrote: here i need some help. Why it was not always reproducible? It depends on timing, protocol, moon position? The bug was consistently reproducible at my end. Sujith ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] Supported Wi-Fi direct of Android?
Hi list, I want to enable concurrently the wlan0 and p2p0 interface with the usb wifi dongle on PCs, It is similar to the Wi-Fi direct of Android-4.2.2(Samsung Galaxy Nexus). I found out Galaxy Nexus Wi-Fi chip is Broadcom BCM4330, but I can't buy a usb dongle used this chip, however I can buy TP-LINK TL-WN722N with using ar9271( ath9k_htc driver). Now I want to know if ath9k_htc driver support to enable concurrently the wlan0 and p2p0 interface, and how to support this functionality with coding. Please help! Some reference information: *http://readlist.com/lists/shmoo.com/hostap/3/15004.html* -- * To me it seem YanBo is working with a mac80211 driver and asking how to tell mac80211 it can support multiple (concurrent) interfaces. Same like for cfg80211, advertise interface combinations? And if you advertise a combination with P2P_DEVICE then wpa_s (with these patches) will pick it up and create one. johannes* --- Best Regards, Chengyi ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Supported Wi-Fi direct of Android?
On 06/20/2013 02:44 PM, Check Zhao wrote:
Hi list,
I want to enable concurrently the wlan0 and p2p0 interface with the usb
wifi dongle on PCs,
It is similar to the Wi-Fi direct of Android-4.2.2(Samsung Galaxy Nexus).
I found out Galaxy Nexus Wi-Fi chip is Broadcom BCM4330, but I can't buy
a usb dongle used this chip, however I can buy TP-LINK TL-WN722N with
using ar9271( ath9k_htc driver).
Now I want to know if ath9k_htc driver support to enable concurrently
the wlan0 and p2p0 interface, and how to support this functionality with
coding.
Please help!
From the code:
static const struct ieee80211_iface_limit if_limits[] = {
{ .max = 2, .types = BIT(NL80211_IFTYPE_STATION) |
BIT(NL80211_IFTYPE_P2P_CLIENT) },
{ .max = 2, .types = BIT(NL80211_IFTYPE_AP) |
BIT(NL80211_IFTYPE_P2P_GO) },
};
static const struct ieee80211_iface_combination if_comb = {
.limits = if_limits,
.n_limits = ARRAY_SIZE(if_limits),
.max_interfaces = 2,
.num_different_channels = 1,
};
It has P2P support, but it is a mac80211 driver and it may need
P2P_DEVICE support as well. Johannes?
Regards,
Arend
Some reference information:
/http://readlist.com/lists/shmoo.com/hostap/3/15004.html/
--
/ To me it seem YanBo is working with a mac80211 driver and asking how to
tell mac80211 it can support multiple (concurrent) interfaces.
Same like for cfg80211, advertise interface combinations? And if you
advertise a combination with P2P_DEVICE then wpa_s (with these patches)
will pick it up and create one.
johannes/
---
Best Regards,
Chengyi
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Supported Wi-Fi direct of Android?
static const struct ieee80211_iface_limit if_limits[] = {
{ .max = 2, .types = BIT(NL80211_IFTYPE_STATION) |
BIT(NL80211_IFTYPE_P2P_CLIENT) },
{ .max = 2, .types = BIT(NL80211_IFTYPE_AP) |
BIT(NL80211_IFTYPE_P2P_GO) },
};
static const struct ieee80211_iface_combination if_comb = {
.limits = if_limits,
.n_limits = ARRAY_SIZE(if_limits),
.max_interfaces = 2,
.num_different_channels = 1,
};
It has P2P support, but it is a mac80211 driver and it may need P2P_DEVICE
support as well. Johannes?
Not necessarily, no. It's an implementation choice.
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
[ath9k-devel] performance with ath9k, sparklan WPEA-127N, and Macbook pro
Hello, I am attempting to build an AP that can support airplay streaming between various mac devices. My current test bed is as follows: Macbook Pro 10,2 (13 Retina), with an Airport Extreme (0x14E4, 0x10F) card, which is using the BCM43xx driver (according to system report). Apple TV Gen 3 (no idea what the wireless hardware in it is) A Jetway Mini-top: http://www.newegg.com/Product/Product.aspx?Item=N82E16856107081 It's running fully patched debian stable (wheezy), amd64. I have replaced the stock PCI Express wireless card with a SparkLan WPEA-127N: http://www.sparklan.com/product.php?func=viewprod_id=181 and added two antennas to the top of the case utilizing these: http://www.embeddedworks.net/pdetail.php?mn=assyprod=assy085 http://www.embeddedworks.net/pdetail.php?mn=anteprod=ante542 The darn WPEA-127N came world-roaming burned in to the EEPROM, so I modified the ath9k driver from the stock debian wheezy driver using: https://patchwork.kernel.org/patch/2249511/ (thanks Ben) and for good measure, also updated regulatory.bin for crda to map regdomain 0 to the US (where I'm at). Finally, my modprobe settings for ath9k are: options ath9k override_eeprom_regdomain=0 options ath9k nohwcrypt=1 I have successfully connected to the AP over a 5GHz channel utilizing HT40, and have working network connectivity. My hostapd.conf is as follows: interface=wlan0 driver=nl80211 ssid=aero hw_mode=a channel=44 ieee80211n=1 wmm_enabled=1 wmm_ac_bk_cwmin=4 wmm_ac_bk_cwmax=10 wmm_ac_bk_aifs=7 wmm_ac_bk_txop_limit=0 wmm_ac_bk_acm=0 wmm_ac_be_aifs=3 wmm_ac_be_cwmin=4 wmm_ac_be_cwmax=10 wmm_ac_be_txop_limit=0 wmm_ac_be_acm=0 wmm_ac_vi_aifs=2 wmm_ac_vi_cwmin=3 wmm_ac_vi_cwmax=4 wmm_ac_vi_txop_limit=94 wmm_ac_vi_acm=0 wmm_ac_vo_aifs=2 wmm_ac_vo_cwmin=2 wmm_ac_vo_cwmax=3 wmm_ac_vo_txop_limit=47 wmm_ac_vo_acm=0 tx_queue_data3_aifs=7 tx_queue_data3_cwmin=15 tx_queue_data3_cwmax=1023 tx_queue_data3_burst=0 tx_queue_data2_aifs=3 tx_queue_data2_cwmin=15 tx_queue_data2_cwmax=63 tx_queue_data2_burst=0 tx_queue_data1_aifs=1 tx_queue_data1_cwmin=7 tx_queue_data1_cwmax=15 tx_queue_data1_burst=3.0 tx_queue_data0_aifs=1 tx_queue_data0_cwmin=3 tx_queue_data0_cwmax=7 tx_queue_data0_burst=1.5 ht_capab=[LDPC][HT40+][SHORT-GI-20][SHORT-GI-40][TX-STBC][RX-STBC1][DSSS_CCK-40] #ht_capab=[LDPC][SHORT-GI-20][TX-STBC][RX-STBC1] #ht_capab=[LDPC][TX-STBC][RX-STBC1] macaddr_acl=0 auth_algs=1 ignore_broadcast_ssid=0 wpa=3 wpa_passphrase=[REDACTED] wpa_key_mgmt=WPA-PSK wpa_pairwise=CCMP country_code=US the various wmm and tx_queue parts are mostly unknown to me, as I came across them trying to determine why my airplay stream would not start if the encryption scheme was CCMP. After setting the above, it would start when the scheme was set to CCMP. As of right now, I get about 11MB/s (88Mbit/s), and that seems low. I was hoping to see something closer 200-250Mbit, but I don't really know what to expect between a published maximum (which I currently believe to be 450Mbit for this card), and a practical maximum. So, my question is...am I doing it wrong? Also, since the wmm and tx settings are mostly unknown to me, I've been trying to figure out what they mean, but have not located any useful resources. If anyone could point me in that direction, I may find that these settings are completely wrong for my hardware. Finally, if this is the completely wrong forum to ask this question, I apologize. This is my first dive into a linux AP, and I'm mostly still stumbling around blindly. Thanks, Adam ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] performance with ath9k, sparklan WPEA-127N, and Macbook pro
On 2013-06-20 6:05 PM, Adam Allred wrote: Hello, I am attempting to build an AP that can support airplay streaming between various mac devices. My current test bed is as follows: Macbook Pro 10,2 (13 Retina), with an Airport Extreme (0x14E4, 0x10F) card, which is using the BCM43xx driver (according to system report). Apple TV Gen 3 (no idea what the wireless hardware in it is) A Jetway Mini-top: http://www.newegg.com/Product/Product.aspx?Item=N82E16856107081 It's running fully patched debian stable (wheezy), amd64. I have replaced the stock PCI Express wireless card with a SparkLan WPEA-127N: http://www.sparklan.com/product.php?func=viewprod_id=181 and added two antennas to the top of the case utilizing these: http://www.embeddedworks.net/pdetail.php?mn=assyprod=assy085 http://www.embeddedworks.net/pdetail.php?mn=anteprod=ante542 The darn WPEA-127N came world-roaming burned in to the EEPROM, so I modified the ath9k driver from the stock debian wheezy driver using: https://patchwork.kernel.org/patch/2249511/ (thanks Ben) and for good measure, also updated regulatory.bin for crda to map regdomain 0 to the US (where I'm at). Finally, my modprobe settings for ath9k are: options ath9k override_eeprom_regdomain=0 options ath9k nohwcrypt=1 Using nohwcrypt=1 is a bad idea and might explain your performance issues. Where did you get that from? - Felix ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] performance with ath9k, sparklan WPEA-127N, and Macbook pro
I picked it up off of http://ubuntuforums.org/showthread.php?t=1746326 and only tried it after I had a working connection, just to see if it would make a difference, since it's ubuntu and a AR92xx series card in that post. Performance is the same both with and without this option. Adam On Thu, Jun 20, 2013 at 12:44 PM, Felix Fietkau n...@openwrt.org wrote: On 2013-06-20 6:05 PM, Adam Allred wrote: Hello, I am attempting to build an AP that can support airplay streaming between various mac devices. My current test bed is as follows: Macbook Pro 10,2 (13 Retina), with an Airport Extreme (0x14E4, 0x10F) card, which is using the BCM43xx driver (according to system report). Apple TV Gen 3 (no idea what the wireless hardware in it is) A Jetway Mini-top: http://www.newegg.com/Product/Product.aspx?Item=N82E16856107081 It's running fully patched debian stable (wheezy), amd64. I have replaced the stock PCI Express wireless card with a SparkLan WPEA-127N: http://www.sparklan.com/product.php?func=viewprod_id=181 and added two antennas to the top of the case utilizing these: http://www.embeddedworks.net/pdetail.php?mn=assyprod=assy085 http://www.embeddedworks.net/pdetail.php?mn=anteprod=ante542 The darn WPEA-127N came world-roaming burned in to the EEPROM, so I modified the ath9k driver from the stock debian wheezy driver using: https://patchwork.kernel.org/patch/2249511/ (thanks Ben) and for good measure, also updated regulatory.bin for crda to map regdomain 0 to the US (where I'm at). Finally, my modprobe settings for ath9k are: options ath9k override_eeprom_regdomain=0 options ath9k nohwcrypt=1 Using nohwcrypt=1 is a bad idea and might explain your performance issues. Where did you get that from? - Felix ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] performance with ath9k, sparklan WPEA-127N, and Macbook pro
On 2013-06-20 6:49 PM, Adam Allred wrote: I picked it up off of http://ubuntuforums.org/showthread.php?t=1746326 and only tried it after I had a working connection, just to see if it would make a difference, since it's ubuntu and a AR92xx series card in that post. Performance is the same both with and without this option. OK. Better leave it out from now on, it's not a good idea to use random workarounds for old issues on a different wifi chip :) I think you should start by using more recent drivers, Linux 3.2 is a bit old. Pick up a recent compat-drivers release - https://backports.wiki.kernel.org/index.php/Releases Also, how exactly are you measuring performance? Once you have the new release installed and are running some performance tests, it would be helpful to post the contents of /sys/kernel/debug/ieee80211/phy0/netdev\:wlan0/stations/*/rc_stats It'll show how well the individual 802.11n rates are working. - Felix ___ 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 Thursday 20 Jun 2013, Felix Fietkau wrote: On 2013-06-20 12:26 PM, David Goodenough wrote: On Wednesday 19 Jun 2013, Ben Greear wrote: 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 The only place I have noticed that do this with wifi kit is Microtik who say they can do setups like this - but as usual with them there is no indication of how it is done under the covers. They're doing it with hacked up proprietary protocol modifications. So I get why you would want to do combine two links to get full-duplex. But why would you want to mess around with things like ACKs? - Felix Most of my links are quite long, so removing any turnaround had got to be a good thing (hasn't it?). I presume that every time the link turns around you have to turn off the receive path (or at least disconnect it) and then power up the transmitter, and allow time for the receiver at the other end to sync. Then at the receiving end if it was transmitting before (this is point to point) it has to shut down the transmit path in an orderly fashion so that it remains loaded while active. Surely that has to take a significant time? By quite long I am talking up to 7km. David ___ 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 2013-06-20 12:26 PM, David Goodenough wrote: On Wednesday 19 Jun 2013, Ben Greear wrote: 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 The only place I have noticed that do this with wifi kit is Microtik who say they can do setups like this - but as usual with them there is no indication of how it is done under the covers. They're doing it with hacked up proprietary protocol modifications. So I get why you would want to do combine two links to get full-duplex. But why would you want to mess around with things like ACKs? - Felix ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] phy0: Chip reset failed
On 19/06/2013, at 22.42, stof...@skulp.net wrote: 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 Now I enabled debufs and set the mask: echo 0xFEFF /sys/kernel/debug/ieee80211/phy0/ath9k_htc/debug kernel 3.9.4: Jun 20 19:38:46 pi4 kernel: [ 1483.808643] ath: phy0: Timeout waiting for WMI command: WMI_NODE_CREATE_CMDID Jun 20 19:38:46 pi4 kernel: [ 1483.808683] ath: phy0: Unable to add station entry for: 64:70:02:22:ea:71 Jun 20 19:38:46 pi4 kernel: [ 1483.808709] wlan0: failed to move IBSS STA 64:70:02:22:ea:71 to state 3 (-110) - keeping it anyway Jun 20 19:38:47 pi4 kernel: [ 1484.808694] ath: phy0: Timeout waiting for WMI command: WMI_REG_READ_CMDID Jun 20 19:38:47 pi4 kernel: [ 1484.808735] ath: phy0: REGISTER READ FAILED: (0x4048, -110) Jun 20 19:38:48 pi4 kernel: [ 1485.178685] ath: phy0: Dropping a packet due to TX timeout Jun 20 19:38:48 pi4 kernel: [ 1485.808740] ath: phy0: Timeout waiting for WMI command: WMI_REG_WRITE_CMDID Jun 20 19:38:48 pi4 kernel: [ 1485.808781] ath: phy0: REGISTER WRITE FAILED:(0x4048, -110) Jun 20 19:38:49 pi4 kernel: [ 1486.228742] ath: phy0: Dropping a packet due to TX timeout Jun 20 19:38:49 pi4 kernel: [ 1486.808790] ath: phy0: Timeout waiting for WMI command: WMI_REG_READ_CMDID and then the two last lines repeated infinitely... ___ 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 2013-06-20 8:13 PM, David Goodenough wrote: On Thursday 20 Jun 2013, Felix Fietkau wrote: On 2013-06-20 12:26 PM, David Goodenough wrote: On Wednesday 19 Jun 2013, Ben Greear wrote: 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 The only place I have noticed that do this with wifi kit is Microtik who say they can do setups like this - but as usual with them there is no indication of how it is done under the covers. They're doing it with hacked up proprietary protocol modifications. So I get why you would want to do combine two links to get full-duplex. But why would you want to mess around with things like ACKs? - Felix Most of my links are quite long, so removing any turnaround had got to be a good thing (hasn't it?). I presume that every time the link turns around you have to turn off the receive path (or at least disconnect it) and then power up the transmitter, and allow time for the receiver at the other end to sync. Then at the receiving end if it was transmitting before (this is point to point) it has to shut down the transmit path in an orderly fashion so that it remains loaded while active. Surely that has to take a significant time? The rx/tx switching time is very short, short enough to be insignificant. The inter-frame duration, slot time, etc. are significantly longer, but aggregation effectively cuts it down to a fraction relative to the number of packets. With a lot of changes to the software it would be possible to disable the on-chip ACK functionality, retransmission, etc. However, I think the disadvantages outweigh the advantages, mainly due to the extra latency of processing lots of things in software that are currently accelerated by the hardware. The increase in complexity is not particularly nice either. - Felix ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] phy0: Chip reset failed
kernel 3.9.4: Jun 20 19:38:46 pi4 kernel: [ 1483.808643] ath: phy0: Timeout waiting for WMI command: WMI_NODE_CREATE_CMDID Jun 20 19:38:46 pi4 kernel: [ 1483.808683] ath: phy0: Unable to add station entry for: 64:70:02:22:ea:71 Jun 20 19:38:46 pi4 kernel: [ 1483.808709] wlan0: failed to move IBSS STA 64:70:02:22:ea:71 to state 3 (-110) - keeping it anyway Jun 20 19:38:47 pi4 kernel: [ 1484.808694] ath: phy0: Timeout waiting for WMI command: WMI_REG_READ_CMDID Jun 20 19:38:47 pi4 kernel: [ 1484.808735] ath: phy0: REGISTER READ FAILED: (0x4048, -110) Jun 20 19:38:48 pi4 kernel: [ 1485.178685] ath: phy0: Dropping a packet due to TX timeout Jun 20 19:38:48 pi4 kernel: [ 1485.808740] ath: phy0: Timeout waiting for WMI command: WMI_REG_WRITE_CMDID Jun 20 19:38:48 pi4 kernel: [ 1485.808781] ath: phy0: REGISTER WRITE FAILED:(0x4048, -110) Jun 20 19:38:49 pi4 kernel: [ 1486.228742] ath: phy0: Dropping a packet due to TX timeout Jun 20 19:38:49 pi4 kernel: [ 1486.808790] ath: phy0: Timeout waiting for WMI command: WMI_REG_READ_CMDID downgraded to kernel 3.2.27 and now they have been running fine since (2 hours)... ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] phy0: Chip reset failed
Am 21.06.2013 02:44, schrieb stof...@skulp.net: kernel 3.9.4: Jun 20 19:38:46 pi4 kernel: [ 1483.808643] ath: phy0: Timeout waiting for WMI command: WMI_NODE_CREATE_CMDID Jun 20 19:38:46 pi4 kernel: [ 1483.808683] ath: phy0: Unable to add station entry for: 64:70:02:22:ea:71 Jun 20 19:38:46 pi4 kernel: [ 1483.808709] wlan0: failed to move IBSS STA 64:70:02:22:ea:71 to state 3 (-110) - keeping it anyway Jun 20 19:38:47 pi4 kernel: [ 1484.808694] ath: phy0: Timeout waiting for WMI command: WMI_REG_READ_CMDID Jun 20 19:38:47 pi4 kernel: [ 1484.808735] ath: phy0: REGISTER READ FAILED: (0x4048, -110) Jun 20 19:38:48 pi4 kernel: [ 1485.178685] ath: phy0: Dropping a packet due to TX timeout Jun 20 19:38:48 pi4 kernel: [ 1485.808740] ath: phy0: Timeout waiting for WMI command: WMI_REG_WRITE_CMDID Jun 20 19:38:48 pi4 kernel: [ 1485.808781] ath: phy0: REGISTER WRITE FAILED:(0x4048, -110) Jun 20 19:38:49 pi4 kernel: [ 1486.228742] ath: phy0: Dropping a packet due to TX timeout Jun 20 19:38:49 pi4 kernel: [ 1486.808790] ath: phy0: Timeout waiting for WMI command: WMI_REG_READ_CMDID downgraded to kernel 3.2.27 and now they have been running fine since (2 hours)... Hmm.. looks like firmware died. How long do you run to reproduce it? How many peers are in this mesh? Do you run in adhock mode? If it is regression, can you please run git bisect? -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
