RE: [OpenWrt-Devel] ATH10K VLAN firmware issue
Thanks for your answer, How I can know when this issue will be fixed in ath10k firmware mainline? Do you know if Qualcomm publish a release note for this firmware? > -Message d'origine- > De : linux-wireless-ow...@vger.kernel.org [mailto:linux-wireless- > ow...@vger.kernel.org] De la part de Valo, Kalle > Envoyé : mardi 21 février 2017 14:19 > À : voncken > Cc : 'OpenWrt Development List'; 'linux-wireless'; > ath...@lists.infradead.org > Objet : Re: [OpenWrt-Devel] ATH10K VLAN firmware issue > > voncken <cedric.vonc...@acksys.fr> writes: > > > Do you know if the firmware team planned to fix the VLAN issue on > > ath10k firmware? > > I reported it forward only this week. > > -- > Kalle Valo
RE: [OpenWrt-Devel] ATH10K VLAN firmware issue
Kalle, Do you know if the firmware team planned to fix the VLAN issue on ath10k firmware? Thanks for your help. Cedric. > -Message d'origine- > De : linux-wireless-ow...@vger.kernel.org [mailto:linux-wireless- > ow...@vger.kernel.org] De la part de Valo, Kalle > Envoyé : mardi 15 novembre 2016 14:44 > À : Bruno Antunes > Cc : OpenWrt Development List; linux-wireless; voncken; > ath...@lists.infradead.org > Objet : Re: [OpenWrt-Devel] ATH10K VLAN firmware issue > > Bruno Antunes <baantu...@gmail.com> writes: > > > On 7 November 2016 at 18:06, Valo, Kalle <kv...@qca.qualcomm.com> > wrote: > >> Bruno Antunes <baantu...@gmail.com> writes: > >> > >>> On 4 November 2016 at 21:17, Valo, Kalle <kv...@qca.qualcomm.com> > wrote: > >>> > >>>> Can someone file a bug to bugzilla about this so that all the info > >>>> is properly stored? The more comprehensive the report is the > better. > >>>> > >>>> https://bugzilla.kernel.org/ > >>> > >>> I will file a bug report. > >> > >> Thanks, it's good to store all in one place so that it's easier to > >> find the relevant info. > > > > Just file the bug with the ID 187241 - VLAN support in ATH10k Feel > > free to ask for adicional info. I did not mention any names in the > bug > > report fell free to take credit if wanted. > > Thanks. I'll report it to the firmware team, let's see what happens. If > there's more information which might help to fix this feel free to > update that to the bug report. > > https://bugzilla.kernel.org/show_bug.cgi?id=187241 > > -- > Kalle Valo
Atheros ETSI DFS pattern
In the file drivers/net/wireless/ath/dfs_pattern_detector.c we can found the ETSI pattern definition. In this definition we can found 7 patterns (0 to 6). The ETSI standard EN 301893 Annex D only specifies 6 patterns. Only the pattern 1 to 6 defined in the ath dfs pattern match with the ETSI standard. Why the pattern 0 is defined? Is it possible to remove this pattern and keep compliant with the ETSI standard? Thanks for your help. Cedric.
RE: [OpenWrt-Devel] ATH10K VLAN firmware issue
Hi Ben, Do you plan to release a candelatech firmware with this fix? Regards. Cedric Voncken. > -Message d'origine- > De : linux-wireless-ow...@vger.kernel.org [mailto:linux-wireless- > ow...@vger.kernel.org] De la part de Ben Greear > Envoyé : samedi 5 novembre 2016 15:35 > À : Sebastian Gottschall; yu-chieh kung; Bruno Antunes > Cc : Mauro Mozzarelli; linux-wireless@vger.kernel.org; OpenWrt > Development List; ath...@lists.infradead.org > Objet : Re: [OpenWrt-Devel] ATH10K VLAN firmware issue > > Looks to me like 10.4 defaults to the right value, but possibly there > are other issues with it. I tested my CT 10.4 and it worked OK with > vlans for me. > > Thanks, > Ben > > On 11/05/2016 01:05 AM, Sebastian Gottschall wrote: > > would be good if qca can fix this bug finally in all available > > firmwares. its a very annoying issue since a long time > > > > Sebastian > > > > > > Am 04.11.2016 um 23:23 schrieb Ben Greear: > >> The bug appears that vlan-tx-stripping is unconditionally enabled in > >> at least my firmware. I have re-compiled w/out that flag set, and > it > >> appears to work for me. > >> > >> Please download this firmware, rename it firmware-2.bin, make sure > >> you remove/rename any firmware-5.bin (etc) so mine will load, and > see if that fixes your problem. > >> > >> Please note that it is very likely you will have to use same MAC > >> address for the VLAN devices that the underlying station uses in > order for this to work. > >> > >> https://www.candelatech.com/downloads/tmp/firmware-2-full- > community.b > >> in > >> > >> > >> Thanks, > >> Ben > >> > >> > >> On 11/04/2016 02:50 PM, Ben Greear wrote: > >>> I can reproduce this in my CT firmware. I'll see if I can fix it, > >>> but for stock firmware, it might be that changing the driver to use > >>> Ethernet packet type of native-wifi would make .1q vlans work. > >>> > >>> Thanks, > >>> Ben > >>> > >>> On 11/04/2016 10:28 AM, yu-chieh kung wrote: > >>>> I met the same problem before, > >>>> if i modify the 1q header to other value (0xaa00) before go into > firmware. > >>>> I can capture the packet in the air I think the vlan packet is > >>>> dropped in firmware. > >>>> > >>>> 2016-11-04 22:41 GMT+08:00 Bruno Antunes <baantu...@gmail.com>: > >>>>> On 4 November 2016 at 14:18, Mauro Mozzarelli > <open...@ezplanet.net> wrote: > >>>>>> Since the capability is implemented in software you might be > >>>>>> testing the limit of your router's CPU i/o speed. > >>>>> > >>>>> By loading the module in rawmode? > >>>>> > >>>>> The AP is an APU and Sta is an APU2. > >>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> On 04/11/16 14:13, Bruno Antunes wrote: > >>>>>>> > >>>>>>> Hi all, > >>>>>>> > >>>>>>> Old thread but I think the issue is still present. > >>>>>>> > >>>>>>> I'm running a setup with VLANs with WDS and ath10k cards. > >>>>>>> > >>>>>>> To make it work both cards must be loaded in rawmode, AP and > >>>>>>> Sta, and with no security. > >>>>>>> > >>>>>>> I'm using a OpenWrt trunk r49941 and the most recent firmware, > >>>>>>> 10.2.4.70.58, from Kalle ath10k firmware tree. > >>>>>>> > >>>>>>> Although it works the throughput is very bad. > >>>>>>> Are there any alternatives to improve the throughput. > >>>>>>> > >>>>>>> Best Regards, > >>>>>>> Bruno > >>>>>>> > >>>>>>> On 9 December 2015 at 17:24, voncken <cedric.vonc...@acksys.fr> > wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>>> -Message d'origine- > >>>>>>>>> De : Ben Greear [mailto:gree...@candelatech.com] Envoyé : > >>>>>>>>> mercredi 9 décembre 2015 16:34 À : Cedric VONCKEN;
RE: Mac80211 : Wpa rekeying issue
Hi, I'm not a WPA expert and security expert, Could you explain why the patch sent by Alexander Wetzel break the security properties of this code? The Alexander's patch is in attachment. Thanks for your help. > -Message d'origine- > De : linux-wireless-ow...@vger.kernel.org [mailto:linux-wireless- > ow...@vger.kernel.org] De la part de voncken > Envoyé : mardi 29 décembre 2015 16:24 > À : 'Emmanuel Grumbach' > Cc : 'linux-wireless'; 'Johannes Berg' > Objet : RE: Mac80211 : Wpa rekeying issue > > > -Message d'origine- > > De : Emmanuel Grumbach [mailto:egrumb...@gmail.com] Envoyé : mardi 29 > > décembre 2015 15:20 À : Cedric VONCKEN Cc : linux-wireless Objet : Re: > > Mac80211 : Wpa rekeying issue > > > > On Tue, Dec 29, 2015 at 3:01 PM, Cedric VONCKEN > > <cedric.vonc...@acksys.fr> > > wrote: > > > Hi, > > > > > > My test plateform is: > > > 2 equipements > > > Both equipment used compat version 2015-07-21 from openwrt. > > > Both equipment used security WPA2 > > > > > > The equipment #1 is an AP. > > > The Group rekey interval is set to 3601s > > > The Pair rekey interval set to 50s (I reduced this value to > > > show the issue often) > > > The Master rekey interval is set to 86400 s. > > > > > > The equipment #2 is a sta+wds > > > > > > I used a 5GHz channel to have a free channel (without other AP) I > > > connected a computer on each equipment. > > > > > > To reproduce the issue: > > > I ran iperf udp@50Mbps from computer connected to the AP to > > > the computer connected to the sta. After several WPA2 rekeying, > > > iperf server side didn't received any frame. > > > > > > I investigated in the driver. All packets are dropped in sta side, > > > because the function ieee80211_crypto_ccmp_decrypt return > > > Rx_DROP_UNUSABLE. This function return this code because the test > > > if(memcmp(pn,key->u.ccmp.rx_pn[queue],IEEE8021_CCMP_PN_LEN) <=0) > > > return true. > > > > > > Have you any idea to fix this issue? > > > > > > > I don't remember exactly what we had, but you may look at > > http://permalink.gmane.org/gmane.linux.kernel.wireless.general/137742 > > Thanks for the link, I think I'm in the same situation. > > How can I fix this issue? > > Because the patch sent by Alexander Wetzel was rejected by Johannes (for > security reason), and if I disable the hw crypto I will have performance > issue. > > > -- > 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 fix1.patch Description: Binary data
RE: Mac80211 : Wpa rekeying issue
> > > > Hi, > > > > I'm not a WPA expert and security expert, > > > > Could you explain why the patch sent by Alexander Wetzel break the > security properties of this code? > > > > The Alexander's patch is in attachment. > > > > Thanks for your help. > > It simply disables the replay attack detection :) You could receive the > same (encrypted) packet twice and not throw away the second one. > The author of the patch never said that this patch is a "fix", it is rather > a debug step to understand what happens. > > PTK rekeying is a problem from the spec point of view. In Intel, we did > inquiries and in the end we understood that what we should really do > whenever we get to a situation where we need to rekey the PTK is to > disconnect and reconnect. Only weird configuration allow to change the PTK > more frequently than after X packet (don't remember what X is bu something > like 2^32 which is big enough to hold the connection for days...). > > IIRC, Intel devices don't have problems in Tx while we rekey because we > give the key material along with the packet itself, so that we can't get to > a situation where we have old PN and new key. The Atheros devices separate > the key material and the Tx packet (which is a perfectly valid design > decision), but this introduce the possibility to use the old PN with a new > key meaning that the recipient could decrypt the packet after the new key > has been installed, but it would also update the PN to be high and discard > all the next packets that will come with a new (low) PN. > So essentially, this is a bug in the TX'ing side. Fixing it requires to hit > the performance which is not something people are willing to do, when the > bug is really in the spec. > That's what I remember, but I may be wrong. > Thanks for your answer. Do you know if we can have the same issue with ATH10K chipset? -- 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
RE: Mac80211 : Wpa rekeying issue
> -Message d'origine- > De : Emmanuel Grumbach [mailto:egrumb...@gmail.com] > Envoyé : mardi 29 décembre 2015 15:20 > À : Cedric VONCKEN > Cc : linux-wireless > Objet : Re: Mac80211 : Wpa rekeying issue > > On Tue, Dec 29, 2015 at 3:01 PM, Cedric VONCKEN <cedric.vonc...@acksys.fr> > wrote: > > Hi, > > > > My test plateform is: > > 2 equipements > > Both equipment used compat version 2015-07-21 from openwrt. > > Both equipment used security WPA2 > > > > The equipment #1 is an AP. > > The Group rekey interval is set to 3601s > > The Pair rekey interval set to 50s (I reduced this value to > > show the issue often) > > The Master rekey interval is set to 86400 s. > > > > The equipment #2 is a sta+wds > > > > I used a 5GHz channel to have a free channel (without other AP) I > > connected a computer on each equipment. > > > > To reproduce the issue: > > I ran iperf udp@50Mbps from computer connected to the AP to > > the computer connected to the sta. After several WPA2 rekeying, iperf > > server side didn't received any frame. > > > > I investigated in the driver. All packets are dropped in sta side, > > because the function ieee80211_crypto_ccmp_decrypt return > > Rx_DROP_UNUSABLE. This function return this code because the test > > if(memcmp(pn,key->u.ccmp.rx_pn[queue],IEEE8021_CCMP_PN_LEN) <=0) > > return true. > > > > Have you any idea to fix this issue? > > > > I don't remember exactly what we had, but you may look at > http://permalink.gmane.org/gmane.linux.kernel.wireless.general/137742 Thanks for the link, I think I'm in the same situation. How can I fix this issue? Because the patch sent by Alexander Wetzel was rejected by Johannes (for security reason), and if I disable the hw crypto I will have performance issue. -- 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
Mac80211 driver crash in monitor mode
Hi,
I'm using mac80211/ATH9K driver in monitor mode to inject some packets.
With the latest driver version my packet injector software generated a
kernel panic.
The reason of this crash is:
In mac80211/tx.c, function __ieee80211_tx:
case NL80211_IFTYPE_MONITOR:
if (sdata->u.mntr_flags & MONITOR_FLAG_ACTIVE) {
vif = >vif;
break;
}
sdata = rcu_dereference(local->monitor_sdata);
if (sdata) {
vif = >vif;
info->hw_queue =
vif->hw_queue[skb_get_queue_mapping(skb)];
} else if (ieee80211_hw_check(>hw,
QUEUE_CONTROL)) {
ieee80211_purge_tx_queue(>hw, skbs);
return true;
} else
vif = NULL;
break;
If I don't enable the MONITOR_FLAG_ACTIVE I'm going to the line vif =
null, this function will continue and will call ieee80211_tx_frags and
this function will call ieee80211_drv_tx.
In ieee80211_drv_tx function:
if (pubsta) {
u8 tid = skb->priority & IEEE80211_QOS_CTL_TID_MASK;
txq = pubsta->txq[tid];
} else if (vif) {
txq = vif->txq;
}
In my case pubsta == null so I'm going to else statement. The line
vif->txq generate kernel pannic because the VIF pointer have been
initialized to null in __ieee80211_tx function.
Do you have any suggestion to fix this crash?
Cedric Voncken.
--
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
RE: ATH10K VLAN firmware issue
> -Message d'origine- > De : Ben Greear [mailto:gree...@candelatech.com] > Envoyé : mercredi 9 décembre 2015 16:34 > À : Cedric VONCKEN; ath...@lists.infradead.org; linux-wireless > Objet : Re: ATH10K VLAN firmware issue > > This only happens when you use STA + WDS, or is .1q broken for you in > other cases as well? No, this issue occurs in all modes (STA, STA + WDS, AP). Thanks Cedric. > > Thanks, > Ben > > On 12/08/2015 06:29 AM, Cedric VONCKEN wrote: > > I'm testing to transmit frame with 802.1q tag (VLAN). > > > > My client is set in STA + WDS and the netdev is bridged with eth0. > > I have a computer with vlan configuration set connected to the STA > > eth0. > > > > If I try to transmit frames with 802.1q tag, the frames are not sent. > > I checked with wireless sniffer, and I don't see the frame with VLAN > > tag (the frames without VLAN tag are sent). > > > > I tested with firmware 10.2.4.70.14-2 from kale github, > > 10.1.467-ct-com-full-015 from candelatech and 10.2.4.70-2 from > > openwrt, and in all cases I have the same issue. > > > > Thanks for your help. > > > > > > -- > > 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 > > > > -- > Ben Greear <gree...@candelatech.com> > Candela Technologies Inc http://www.candelatech.com -- 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
ATH10K VLAN firmware issue
I'm testing to transmit frame with 802.1q tag (VLAN). My client is set in STA + WDS and the netdev is bridged with eth0. I have a computer with vlan configuration set connected to the STA eth0. If I try to transmit frames with 802.1q tag, the frames are not sent. I checked with wireless sniffer, and I don't see the frame with VLAN tag (the frames without VLAN tag are sent). I tested with firmware 10.2.4.70.14-2 from kale github, 10.1.467-ct-com-full-015 from candelatech and 10.2.4.70-2 from openwrt, and in all cases I have the same issue. Thanks for your help. -- 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
RE: ATH10 firmware question
Hi, Thanks for your answer. > >>> > >>> Hi, > >>> > >>> I have a simple test platform. > >>> One PC connected to an equipment. This equipment is set in > >>> AP mode. > >>> Another PC connected to another equipment. This equipment > >>> is set in STA + WDS mode. > >>> > >>> Both equipment use the same openwrt Firmware (compat > >>> 2015-07-21), I only changed the ath10k firmware (in > >>> /lib/firmware/ath10k/...). > >>> Both equipment has the same hardware. > >>> I used a clear channel, and VHT80. > >>> The radio was connected with a coaxial cable and I placed > >>> 40 dBm attenuation per Rf chain. > >>> I used the WLN350NX radio card from compex. > >>> > >>> First test : ATH10K firmware 10.2.4.70-2 on both equipment > >>> An iperf from PC connected to the AP to the PC > >>> connected to the STA give 919 Mbps. > >>> An iperf from PC connected to the STA to the PC > >>> connected to the AP give 500 Mbps. > >>> > >>> Second test : ATHK firmware 10.2.4.70.10-2 on both equipment > >>> An iperf from PC connected to the AP to the PC > >>> connected to the STA give 921 Mbps. > >>> An iperf from PC connected to the STA to the PC > >>> connected to the AP give 441 Mbps. > >>> > >>> If I cross the computer I have the same result. I did > >>> several time these test and I always have the same result. > >> > >> > >> We see similar. One thing we notice is that if you actually try to > >> send less throughput, then you get better overall throughput. > >> > >> In other words, trying to send 1Gbps UDP frames will give you more > >> poor throughput than trying to send 650Mbps (in the upload direction). > >> > >> I thought it might be a poor interaction regarding backoff in the > >> ath10k driver/firmware (see the congestion bins in firmware for why > >> this is the case), but even fixing that in firmware didn't improve > >> the situation in my testing. > > > > If CPU is the bottleneck on DUT than overcommiting the UDP traffic at > > the source may lead the ethernet driver to waste CPU cycles on the > > DUT. > > You are correct about the overcommit in general, but our systems are quite > overpowered. > > We are testing with 3.5Ghz E5 quad-core systems...it is not just a CPU > usage issue. And, exact same hardware runs great (close to 900Mbps) in AP > download mode. > In my case I'm testing with mips 64 dual core at 1.2 GHz. The CPU load is around 50% during my test. I'm agree with Ben, the issue is not in CPU. I tried this morning with different firmware version. I only change the ath10K firmware in client side and I only test the client Tx performance. Test with firmware 999.999.0.636 Unfortunately this firmware does not support the WDS mode, I need to update my setting. With this firmware I have a better performance, I can reach 700 Mbps. Test with firmware 10.1.467-ct-15 from candelatech (full community version) I tested in WDS setting and the same setting of previous firmware to be sure the setting have no impact on the performance. In both case I can reach around 650 Mbps. I tested with beta-16 firmware from candelatech, but I have a similar performance. Thanks Cedric. -- 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
ATH10 firmware question
Hi, I have a simple test platform. One PC connected to an equipment. This equipment is set in AP mode. Another PC connected to another equipment. This equipment is set in STA + WDS mode. Both equipment use the same openwrt Firmware (compat 2015-07-21), I only changed the ath10k firmware (in /lib/firmware/ath10k/...). Both equipment has the same hardware. I used a clear channel, and VHT80. The radio was connected with a coaxial cable and I placed 40 dBm attenuation per Rf chain. I used the WLN350NX radio card from compex. First test : ATH10K firmware 10.2.4.70-2 on both equipment An iperf from PC connected to the AP to the PC connected to the STA give 919 Mbps. An iperf from PC connected to the STA to the PC connected to the AP give 500 Mbps. Second test : ATHK firmware 10.2.4.70.10-2 on both equipment An iperf from PC connected to the AP to the PC connected to the STA give 921 Mbps. An iperf from PC connected to the STA to the PC connected to the AP give 441 Mbps. If I cross the computer I have the same result. I did several time these test and I always have the same result. Is it the expected result? What is the recommanded firmware version for each mode? Thanks for your help. Cedric Voncken. -- 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
Ath10K issue
I'm using compat-wireless 2015-03-09 from openwrt. At the power up, these equipments worked in AP mode and several sta can do an association. Randomly it is not possible to make association to several AP. If I look the log file I see cyclically these error messages. Wed Sep 9 10:29:49 2015 kern.warn kernel: [17654.116104] ath10k_warn: 186 callbacks suppressed Wed Sep 9 10:29:49 2015 kern.warn kernel: [17654.133185] ath10k_pci 0001:02:00.0: SWBA overrun on vdev 3, skipped old beacon Wed Sep 9 10:29:49 2015 kern.warn kernel: [17654.153058] ath10k_pci 0001:02:00.0: SWBA overrun on vdev 0, skipped old beacon Wed Sep 9 10:29:49 2015 kern.warn kernel: [17654.157255] ath10k_pci 0001:02:00.0: reached WMI management transmit queue limit Wed Sep 9 10:29:49 2015 kern.warn kernel: [17654.157260] ath10k_pci 0001:02:00.0: failed to transmit packet, dropping: -16 Wed Sep 9 10:29:49 2015 kern.warn kernel: [17654.212297] ath10k_pci 0001:02:00.0: SWBA overrun on vdev 2, skipped old beacon Wed Sep 9 10:29:49 2015 kern.warn kernel: [17654.232087] ath10k_pci 0001:02:00.0: SWBA overrun on vdev 3, skipped old beacon Wed Sep 9 10:29:49 2015 kern.warn kernel: [17654.252874] ath10k_pci 0001:02:00.0: SWBA overrun on vdev 0, skipped old beacon Wed Sep 9 10:29:49 2015 kern.warn kernel: [17654.286774] ath10k_pci 0001:02:00.0: SWBA overrun on vdev 2, skipped old beacon Wed Sep 9 10:29:49 2015 kern.warn kernel: [17654.320914] ath10k_pci 0001:02:00.0: SWBA overrun on vdev 3, skipped old beacon Wed Sep 9 10:29:49 2015 kern.warn kernel: [17654.355043] ath10k_pci 0001:02:00.0: SWBA overrun on vdev 0, skipped old beacon Wed Sep 9 10:29:54 2015 kern.warn kernel: [17659.167694] ath10k_warn: 193 callbacks suppressed Wed Sep 9 10:29:54 2015 kern.warn kernel: [17659.184778] ath10k_pci 0001:02:00.0: SWBA overrun on vdev 0, skipped old beacon Wed Sep 9 10:29:54 2015 kern.warn kernel: [17659.204514] ath10k_pci 0001:02:00.0: SWBA overrun on vdev 2, skipped old beacon Wed Sep 9 10:29:54 2015 kern.warn kernel: [17659.225098] ath10k_pci 0001:02:00.0: reached WMI management transmit queue limit Wed Sep 9 10:29:54 2015 kern.warn kernel: [17659.235968] ath10k_pci 0001:02:00.0: SWBA overrun on vdev 3, skipped old beacon Wed Sep 9 10:29:54 2015 kern.warn kernel: [17659.264524] ath10k_pci 0001:02:00.0: failed to transmit packet, dropping: -16 Wed Sep 9 10:29:54 2015 kern.warn kernel: [17659.270094] ath10k_pci 0001:02:00.0: SWBA overrun on vdev 0, skipped old beacon Wed Sep 9 10:29:54 2015 kern.warn kernel: [17659.303945] ath10k_pci 0001:02:00.0: failed to transmit management frame via WMI: -11 Wed Sep 9 10:29:54 2015 kern.warn kernel: [17659.304408] ath10k_pci 0001:02:00.0: reached WMI management transmit queue limit Wed Sep 9 10:29:54 2015 kern.warn kernel: [17659.304414] ath10k_pci 0001:02:00.0: failed to transmit packet, dropping: -16 Wed Sep 9 10:29:54 2015 kern.warn kernel: [17659.363876] ath10k_pci 0001:02:00.0: SWBA overrun on vdev 2, skipped old beacon Wed Sep 9 10:29:59 2015 kern.warn kernel: [17664.219316] ath10k_warn: 208 callbacks suppressed To reestablish my access point I need to restart the Wifi (wifi up in openwrt). Have you any idea of this issue? Regards. Cédric Voncken. -- 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
RE: ATH10K and VLAN : Frame with VLAN tag are not sent
The WDS client mode seems to work with ATH10k, and I have the same problem without it. My problem is not in the AP-VLAN feature. I didn't use the encryption in my test. The frames with vlan tag are not sent by ath10k wireless card, in Sta mode, AP mode, Sta + wds mode. My PC1 sends a frame to PC2 with or without VLAN tag. If the tag is present the frame is not sent. If the tag is not present the frame is sent. In my test, the frame with VLAN tag should be sent through ATH10K. I enable the debug in ATH10k driver. The frame with the vlan tag is sent to the wireless radio card. I check the frame dump from ath10k_htt_tx function but I didn't see any error in frame format. I paste the dump below (the frame it is an arp frame in the vlan 6). ath10k_pci :01:00.0: htt tx flags0 37 flags1 3072 len 70 id 0 frags_paddr 06a54000, msdu_paddr 0c158c66 vdev 0 tid 16 freq 0 ath10k_pci :01:00.0: htt tx msdu: : 88 03 00 00 04 f0 21 0e 38 e1 04 f0 21 18 03 a0 ath10k_pci :01:00.0: htt tx msdu: 0010: ff ff ff ff ff ff a 00 09 90 00 4a 97 aa aa ath10k_pci :01:00.0: htt tx msdu: 0020: 03 00 00 00 81 00 00 06 08 06 00 01 08 00 06 04 ath10k_pci :01:00.0: htt tx msdu: 0030: 00 01 00 09 90 00 4a 97 c0 a8 06 fd 00 00 00 00 ath10k_pci :01:00.0: htt tx msdu: 0040: 00 00 c0 a8 06 01 Oh. So you actually refer to the dot1q VLAN tagging. I haven't tested this but I would expect this to work. I'm agree with you it should work, but not :-( Moreover, for each frame sent the Tx status from the cards will increment the failed_count counter, but I didn't know what went wrong. Perhaps htt tx msdu was completed with failure status code. You didn't provide enough logs so I'm just guessing. I didn't have more log on this point, I'm trying the ath10k debug, the ath10 ftrace. If you know how I can have more log on the failure, I will send these logs. Any idea ? I see no reason why this should fail. The dot1q encapsulation shouldn't influence how firmware behaves.. but maybe I'm wrong. It's still unclear to me what your topology looks like. Perhaps you're having problem with environmental configuration itself? Did you try other Wi-Fi device (e.g. ath9k) instead of ath10k? Yes I tested with ath9k wireless card, the same configuration works. I did an interesting test. With ostinato software I generate an ICMP frame without vlan tag. I changed the ethertype in the frame. I tried with the ethertype 0x800 (IP), 0x801, 0x8892 (PROFINET), 0x8100 (dot1q), 0x0600. All frames are sent except when the ethertype is set to 0x8100. It seems the firmware do not accept the ethertype 0x8100. Michał -- 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
RE: ATH10K and VLAN : Frame with VLAN tag are not sent
The WDS client mode seems to work with ATH10k, and I have the same problem without it. My problem is not in the AP-VLAN feature. I didn't use the encryption in my test. The frames with vlan tag are not sent by ath10k wireless card, in Sta mode, AP mode, Sta + wds mode. My PC1 sends a frame to PC2 with or without VLAN tag. If the tag is present the frame is not sent. If the tag is not present the frame is sent. In my test, the frame with VLAN tag should be sent through ATH10K. I enable the debug in ATH10k driver. The frame with the vlan tag is sent to the wireless radio card. I check the frame dump from ath10k_htt_tx function but I didn't see any error in frame format. I paste the dump below (the frame it is an arp frame in the vlan 6). ath10k_pci :01:00.0: htt tx flags0 37 flags1 3072 len 70 id 0 frags_paddr 06a54000, msdu_paddr 0c158c66 vdev 0 tid 16 freq 0 ath10k_pci :01:00.0: htt tx msdu: : 88 03 00 00 04 f0 21 0e 38 e1 04 f0 21 18 03 a0 ath10k_pci :01:00.0: htt tx msdu: 0010: ff ff ff ff ff ff a 00 09 90 00 4a 97 aa aa ath10k_pci :01:00.0: htt tx msdu: 0020: 03 00 00 00 81 00 00 06 08 06 00 01 08 00 06 04 ath10k_pci :01:00.0: htt tx msdu: 0030: 00 01 00 09 90 00 4a 97 c0 a8 06 fd 00 00 00 00 ath10k_pci :01:00.0: htt tx msdu: 0040: 00 00 c0 a8 06 01 Moreover, for each frame sent the Tx status from the cards will increment the failed_count counter, but I didn't know what went wrong. Any idea ? Regards. Cedric. -Message d'origine- De : Michal Kazior [mailto:michal.kaz...@tieto.com] Envoyé : vendredi 5 juin 2015 07:42 À : Cedric VONCKEN Cc : linux-wireless Objet : Re: ATH10K and VLAN On 3 June 2015 at 16:46, Cedric VONCKEN cedric.vonc...@acksys.fr wrote: I'm testing to send a VLAN frame through ATH10K device. I'm using compat wireless 2015-03-09 from openWRT. The ATH10K firmware used is 10.2.4.45 My test platform is: Pc1 : IP 10.101.4.3 (without VLAN) VLAN 1 : IP 192.168.5.1 Equipment in AP mode. The netdev is bridged with eth0 Equipment in client mode with WDS mode enables. The client is connected to the AP. The netdev is bridged with eth0. AP and client use ATH10K wireless card. PC2: IP 10.101.4.4 (without VLAN) VLAN 1 : IP 192.168.5.2 The PC1 is connected to the equipment in AP mode and the PC2 is connected to the equipment in client mode. I can ping from PC1 to PC2 without vlan (ping 10.101.4.4). I cannot ping from PC1 to PC2 with VLAN. With tcpdump I checked the vlan frame is sent to the netdev but this frame is not send to the air. Is it possible to send a VLAN frame through ATH10K? If no, is it a driver limitation or firmware limitation? I'm not sure if IFTYPE_WDS works with ath10k but IFTYPE_AP_VLAN works fine for me on latest github.com/kvalo/ath master branch. Can you test if it works with no encryption, please? Michał -- 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
RE: ATH10K and VLAN : Frame with VLAN tag are not sent
De : linux-wireless-ow...@vger.kernel.org [mailto:linux-wireless- ow...@vger.kernel.org] De la part de Michal Kazior Envoyé : vendredi 5 juin 2015 11:46 À : voncken Cc : linux-wireless; ath...@lists.infradead.org Objet : Re: ATH10K and VLAN : Frame with VLAN tag are not sent [...] I see no reason why this should fail. The dot1q encapsulation shouldn't influence how firmware behaves.. but maybe I'm wrong. It's still unclear to me what your topology looks like. Perhaps you're having problem with environmental configuration itself? Did you try other Wi-Fi device (e.g. ath9k) instead of ath10k? Yes I tested with ath9k wireless card, the same configuration works. I did an interesting test. With ostinato software I generate an ICMP frame without vlan tag. I changed the ethertype in the frame. I tried with the ethertype 0x800 (IP), 0x801, 0x8892 (PROFINET), 0x8100 (dot1q), 0x0600. All frames are sent except when the ethertype is set to 0x8100. It seems the firmware do not accept the ethertype 0x8100. Interesting. This may suggest firmware actually doesn't handle dot1q VLAN tagging properly in NWifi Tx encap mode. Can you try changing it to 802.3 encap and re-test, please? --- a/drivers/net/wireless/ath/ath10k/mac.c +++ b/drivers/net/wireless/ath/ath10k/mac.c @@ -3172,7 +3172,7 @@ ath10k_tx_h_get_txmode(struct ath10k *ar, struct ieee80211_vif *vif, if (ieee80211_is_data_present(fc) sta sta-tdls) return ATH10K_HW_TXRX_ETHERNET; - return ATH10K_HW_TXRX_NATIVE_WIFI; + return ATH10K_HW_TXRX_ETHERNET; } Note: Your backports may not have the necessary code.. In which case it'll be difficult to do this the easy way. If that's the case I suggest you get latest backports or generate them yourself from the latest kvalo/ath master. I will try to change my backport. But it is not easy, because I need to use a cross-compiler. From openwrt website I can download a backport 2015-05-08. I will try to integrate it. Do you know how I can generate a tar file for openwrt from kale git hub? Cedric Michał -- 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 -- 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
RE: ATH10K and VLAN : Frame with VLAN tag are not sent
I did an interesting test. With ostinato software I generate an ICMP frame without vlan tag. I changed the ethertype in the frame. I tried with the ethertype 0x800 (IP), 0x801, 0x8892 (PROFINET), 0x8100 (dot1q), 0x0600. All frames are sent except when the ethertype is set to 0x8100. It seems the firmware do not accept the ethertype 0x8100. Interesting. This may suggest firmware actually doesn't handle dot1q VLAN tagging properly in NWifi Tx encap mode. Can you try changing it to 802.3 encap and re-test, please? --- a/drivers/net/wireless/ath/ath10k/mac.c +++ b/drivers/net/wireless/ath/ath10k/mac.c @@ -3172,7 +3172,7 @@ ath10k_tx_h_get_txmode(struct ath10k *ar, struct ieee80211_vif *vif, if (ieee80211_is_data_present(fc) sta sta-tdls) return ATH10K_HW_TXRX_ETHERNET; - return ATH10K_HW_TXRX_NATIVE_WIFI; + return ATH10K_HW_TXRX_ETHERNET; } Note: Your backports may not have the necessary code.. In which case it'll be difficult to do this the easy way. If that's the case I suggest you get latest backports or generate them yourself from the latest kvalo/ath master. I will try to change my backport. But it is not easy, because I need to use a cross-compiler. From openwrt website I can download a backport 2015-05-08. I will try to integrate it. Do you know how I can generate a tar file for openwrt from kale git hub? That's non-trivial as far as I understand. You could try generating a quilt patch in openwrt to update ath10k. Either some sort of manual cherry-picking of the txmode patch for ath10k or create a partial diff (e.g. only drivers/net/wireless/ath/ath10k) between openwrt backports and kvalo/ath generated backports. I've managed to reproduce your problem in my setup. With NWifi Txed frames with dot1Q VLAN tagging aren't even sent OTA and are reported as not acked by firmware. When I changed the Tx encap mode to 802.3 (ethernet) I can see frames OTA but they are corrupted 3addr frames with invalid SA/DA addresses. I'm guessing this is because firmware expects explicit WMI_PEER_ADD_WDS_ENTRY_CMDID to be issued when trying too use 802.3 Tx encap with 4addr frames. Thanks for these informations, but where I need to set the flag WMI_PEER_ADD_WDS_ENTRY_CMDID? The backport 2015-05-08 should support your modification. I'm trying du compile it. Michał -- 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
RE: ATH10K and VLAN : Frame with VLAN tag are not sent
[...] I see no reason why this should fail. The dot1q encapsulation shouldn't influence how firmware behaves.. but maybe I'm wrong. It's still unclear to me what your topology looks like. Perhaps you're having problem with environmental configuration itself? Did you try other Wi-Fi device (e.g. ath9k) instead of ath10k? Yes I tested with ath9k wireless card, the same configuration works. I did an interesting test. With ostinato software I generate an ICMP frame without vlan tag. I changed the ethertype in the frame. I tried with the ethertype 0x800 (IP), 0x801, 0x8892 (PROFINET), 0x8100 (dot1q), 0x0600. All frames are sent except when the ethertype is set to 0x8100. It seems the firmware do not accept the ethertype 0x8100. Interesting. This may suggest firmware actually doesn't handle dot1q VLAN tagging properly in NWifi Tx encap mode. Can you try changing it to 802.3 encap and re-test, please? --- a/drivers/net/wireless/ath/ath10k/mac.c +++ b/drivers/net/wireless/ath/ath10k/mac.c @@ -3172,7 +3172,7 @@ ath10k_tx_h_get_txmode(struct ath10k *ar, struct ieee80211_vif *vif, if (ieee80211_is_data_present(fc) sta sta-tdls) return ATH10K_HW_TXRX_ETHERNET; - return ATH10K_HW_TXRX_NATIVE_WIFI; + return ATH10K_HW_TXRX_ETHERNET; } Note: Your backports may not have the necessary code.. In which case it'll be difficult to do this the easy way. If that's the case I suggest you get latest backports or generate them yourself from the latest kvalo/ath master. I will try to change my backport. But it is not easy, because I need to use a cross-compiler. From openwrt website I can download a backport 2015-05-08. I will try to integrate it. Do you know how I can generate a tar file for openwrt from kale git hub? That's non-trivial as far as I understand. You could try generating a quilt patch in openwrt to update ath10k. Either some sort of manual cherry-picking of the txmode patch for ath10k or create a partial diff (e.g. only drivers/net/wireless/ath/ath10k) between openwrt backports and kvalo/ath generated backports. I've managed to reproduce your problem in my setup. With NWifi Txed frames with dot1Q VLAN tagging aren't even sent OTA and are reported as not acked by firmware. When I changed the Tx encap mode to 802.3 (ethernet) I can see frames OTA but they are corrupted 3addr frames with invalid SA/DA addresses. I'm guessing this is because firmware expects explicit WMI_PEER_ADD_WDS_ENTRY_CMDID to be issued when trying too use 802.3 Tx encap with 4addr frames. In my compat, I intagrated the function ath10k_tx_h_get_txmode (I don't not if it is sufficient). The frame seems be formwarded (in wireshark I can see an encapsuled Ethernet frame). I will work to find where I need to add the flag WMI_PEER_ADD_WDS_ENTRY_CMDID. Cedric. -- 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
ATH10K and VLAN
I'm testing to send a VLAN frame through ATH10K device. I'm using compat wireless 2015-03-09 from openWRT. The ATH10K firmware used is 10.2.4.45 My test platform is: Pc1 : IP 10.101.4.3 (without VLAN) VLAN 1 : IP 192.168.5.1 Equipment in AP mode. The netdev is bridged with eth0 Equipment in client mode with WDS mode enables. The client is connected to the AP. The netdev is bridged with eth0. AP and client use ATH10K wireless card. PC2: IP 10.101.4.4 (without VLAN) VLAN 1 : IP 192.168.5.2 The PC1 is connected to the equipment in AP mode and the PC2 is connected to the equipment in client mode. I can ping from PC1 to PC2 without vlan (ping 10.101.4.4). I cannot ping from PC1 to PC2 with VLAN. With tcpdump I checked the vlan frame is sent to the netdev but this frame is not send to the air. Is it possible to send a VLAN frame through ATH10K? If no, is it a driver limitation or firmware limitation? Thanks for your help. Cédric. -- 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
[mac80211]synchronize_net call in ieee_tx_ba_session_handle_start
The synchronize_net called in function ieee_tx_ba_session_handle_start generate a jiter after the association. I can observe a long period (100ms or more) where no data are sent because mac80211 is blocked in synchronize_net. My product has several network interface and processor with 4 cores. If I understood correctly, in case we use the ath9k driver, the function drv_ampdu_action will call the ath_tx_aggr_start and this function will flush the tx pending packet and return the next sequence number. So in this case it is not necessary to call this function. Is it possible to remove this function, or I need to consider another case? Thanks for your help. Cedric Voncken. -- 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
RE: ath10k: What will happens when radar is detected ?
-Message d'origine- De : Michal Kazior [mailto:michal.kaz...@tieto.com] Envoyé : mardi 24 mars 2015 07:56 À : Cedric VONCKEN Cc : linux-wireless Objet : Re: ath10k: What will happens when radar is detected ? On 23 March 2015 at 16:16, Cedric VONCKEN cedric.vonc...@acksys.fr wrote: In 802.11ac standard, it is possible to dynamically reduce the channel width used. My question is: If I use a channel with 80 or 40 MHz width, what will happen if I detect radar? The ath10k card/driver reduces automatically the channel width. Currently entire chandef occupied will be marked as unavailable and AP will stop/switch to a different non-overlapping chandef via CSA. Thanks for your answer. I guess it should be possible to implement what you suggest, i.e. change only chandef width when radar is narrow and located at a suitable part of the chandef. This would require hw to be capable of detecting radar center freq and width accurately. I'm not sure if QCA988X is capable of that although firmware interface seems to be able to carry this kind of information already. I wonder why would you want this behaviour in the first place? Wouldn't this actually end up with having less bandwidth and lower throughput (which is already penalized when radar detection is active)? In an industrial environment we prefer to reduce the throughput but keep the link without gap. I think it can be a parameter in AP software for example. Cédric -- 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
ath10k: What will happens when radar is detected ?
In 802.11ac standard, it is possible to dynamically reduce the channel width used. My question is: If I use a channel with 80 or 40 MHz width, what will happen if I detect radar? The ath10k card/driver reduces automatically the channel width. Cedric Voncken. -- 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
RE: ARP dropped during WPA handshake
During the initial WPA handshake the connection is not fully set up, and so no general traffic can (nor should) pass between the STA and AP. That includes ARP and any L2/L3+ protocols, except for EAP and wifi management packets. The interface itself must be IFF_UP before it can pass traffic, including the WPA handshake traffic. IFF_UP only means that the interface can be configured at the L2 level and the hardware is active, it does *not* mean the interface can pass traffic. Whatever is causing the ARPs shouldn't be doing that yet, and should be fixed to use the interface's operstate or IFF_LOWER_UP instead of IFF_UP. Only when the supplicant changes the interface's operstate to IF_OPER_UP is the interface *actually* ready to pass traffic. IFF_UP is not sufficient. Thanks for your reply. It seems wpa_supplicant set the operstate to IF_OPER_DORMANT when he received the ASSOCIATED Event from the driver (through netlink). And set the operstate to IF_OPER_UP in case of wpa handshake success. Is it normal the local ip stack send arp when netdev it is on IF_OPER_DORMANT state? I'm not sure the kernel stack cares much as long as the device is up. It is requesting the ARP because some application is attempting to communicate with that IP address. That application should probably be waiting until the interface is actually ready to communicate, which means IF_OPER_UP. But if this is the first WPA handshake with the AP during the initial connection, the wifi device shouldn't even have an IP address yet, so nothing should be doing ARP on the interface yet. Perhaps whatever is assigning the IP address to the interface is doing it too early, before the interface is IF_OPER_UP? It is not the initial connection. My sta is connected on AP1 and the communication is established (in my test the communication it is iperf from STA to computer behind the APs). I looking for a solution to enable the communication for wpa_supplicant, but block the L3 communication while the WPA handshake is not finished. Have you any idea? Cedric. -- 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
RE: ARP dropped during WPA handshake
On 03/13/2015 12:36 PM, Cedric VONCKEN wrote: My test plateforme is very simple, One sta (with openwrt), one AP and a computer connected to the AP. I launch iperf on the sta and power up the AP. With wireshark I can observe 1 s delay between the frame EAPOL 4/4 and the arp request sent by the sta. I can observe the delay only if my sta uses architecture with more 1 cpu. When the sta received the Authentication response, mac80211 sets the iface on UP state. This state allows wpa_supplicant to send the EAPOL frame for WPA handshake but other frames are dropped. If an arp request is sent by the local ip stack during the WPA handshake this arp will be dropped and we need to wait the end of arp timeout (1 s). Have you any suggestion / pointer to fix this issue? I had a situation where ARP requests were sent and responses were replied, but the requester did not accept the responses and therefore was continuously sending request. However, this was in an IBSS and WPA encryption, which is not really supported if I understand well. RSN worked like a charm, though. The issue was related to the type of encryption. This could also be an issue in your case, however, AP is well supported, so hard to tell. I'm not really a security expert. My point being, you will get better and faster support if you could specify which encryption protocol you use, the specific parameters, etc. br, Wim. My platform is very simple. I use 2 equipment. Both equipment are based on mips64 processor, use ATH9K driver and openwrt. One equipment is configured in AP mode with WPA2-PSK, another equipment is configured in station mode. I can access to the sta through ssh. Below, a tcpdump capture from sta. 17:43:12.964096 EAPOL key (3) v2, len 95 17:43:12.998439 EAPOL key (3) v1, len 117 17:43:13.062409 ARP, Request who-has 10.32.61.100 tell 10.32.0.1, length 28 17:43:13.079989 EAPOL key (3) v2, len 151 17:43:13.082764 EAPOL key (3) v1, len 95 17:43:14.062381 ARP, Request who-has 10.32.61.100 tell 10.32.0.1, length 28 17:43:14.127101 ARP, Reply 10.32.61.100 is-at b8:88:e3:45:1d:c6 (oui Unknown), length 46 17:43:14.127123 IP 10.69.1.201.41690 10.32.61.100.5001: UDP, length 1470 17:43:14.127136 IP 10.69.1.201.41690 10.32.61.100.5001: UDP, length 1470 You can see the ARP request during the WPA Handshake. Any suggestion will be appreciate. Cedric. Thanks for your help. Cedric Voncken -- 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 -- 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
ARP dropped during WPA handshake
My test plateforme is very simple, One sta (with openwrt), one AP and a computer connected to the AP. I launch iperf on the sta and power up the AP. With wireshark I can observe 1 s delay between the frame EAPOL 4/4 and the arp request sent by the sta. I can observe the delay only if my sta uses architecture with more 1 cpu. When the sta received the Authentication response, mac80211 sets the iface on UP state. This state allows wpa_supplicant to send the EAPOL frame for WPA handshake but other frames are dropped. If an arp request is sent by the local ip stack during the WPA handshake this arp will be dropped and we need to wait the end of arp timeout (1 s). Have you any suggestion / pointer to fix this issue? Thanks for your help. Cedric Voncken -- 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
RE: ARP dropped during WPA handshake
Below, a tcpdump capture from sta. 17:43:12.964096 EAPOL key (3) v2, len 95 17:43:12.998439 EAPOL key (3) v1, len 117 17:43:13.062409 ARP, Request who-has 10.32.61.100 tell 10.32.0.1, length 28 17:43:13.079989 EAPOL key (3) v2, len 151 17:43:13.082764 EAPOL key (3) v1, len 95 17:43:14.062381 ARP, Request who-has 10.32.61.100 tell 10.32.0.1, length 28 17:43:14.127101 ARP, Reply 10.32.61.100 is-at b8:88:e3:45:1d:c6 (oui Unknown), length 46 17:43:14.127123 IP 10.69.1.201.41690 10.32.61.100.5001: UDP, length 1470 17:43:14.127136 IP 10.69.1.201.41690 10.32.61.100.5001: UDP, length 1470 You can see the ARP request during the WPA Handshake. During the initial WPA handshake the connection is not fully set up, and so no general traffic can (nor should) pass between the STA and AP. That includes ARP and any L2/L3+ protocols, except for EAP and wifi management packets. The interface itself must be IFF_UP before it can pass traffic, including the WPA handshake traffic. IFF_UP only means that the interface can be configured at the L2 level and the hardware is active, it does *not* mean the interface can pass traffic. Whatever is causing the ARPs shouldn't be doing that yet, and should be fixed to use the interface's operstate or IFF_LOWER_UP instead of IFF_UP. Only when the supplicant changes the interface's operstate to IF_OPER_UP is the interface *actually* ready to pass traffic. IFF_UP is not sufficient. Thanks for your reply. It seems wpa_supplicant set the operstate to IF_OPER_DORMANT when he received the ASSOCIATED Event from the driver (through netlink). And set the operstate to IF_OPER_UP in case of wpa handshake success. Is it normal the local ip stack send arp when netdev it is on IF_OPER_DORMANT state? Any suggestion will be appreciate. Cedric. Thanks for your help. Cedric Voncken -- 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 -- 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 -- 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
Question : WMM queue management in AP role
Hi all, The AP role can manage several sta. In case of WMM, each sta have a separate queue or all sta use the same queue? Where can I found any information on the WMM queue management in linux wireless? I'm using ath9k driver. Cedric Voncken -- 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
RE: ath10k firmware crash
I did some tests with a linksys WRT1900AC and I have ~950 mbps OTA easily. You mean ath10k (STA) VS WRT1900AC get up ~950mbps? If so, could you say what's the HW, FW version you use? My test platform is one WRT1900AC set in bridge mode with a computer. If I use the WRT1900AC in AP mode with another computer, I have 950 mbps If I use the cavium octon III dev plateform + ath10k driver in AP mode, I have around 700 mbps I'm using the latest compat wireless (2014-09-26) from openwrt. The wireless card is the WLE900VX from compex or DAXA-O1 from Unex. The WRT1900AC have mimo 4x4 with 3 streams, and my wireless card have mimo 3x3 with 3 streams. Maybe that explains the difference. Cedric Voncken. -- Bartosz -- 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 -- 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
RE: ath10k firmware crash
Are you perhaps trying to run STA with 4addr bridging? If so then make sure you use recent ath10k as this was known to be a problem. We tested without the 4addr bridging, that works fine but we can't add the interface in bridge :-( Have you a benchmark reference with ATH10K ? at this time we can send around 700 Mbit/s, is it the maximum or we can expected better ? Michał Thanks Cedric Voncken -- 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
RE: ath10k firmware crash
I'm using the compat wireless from Openwrt. Compat wireless version 2014-05-22, but we updated the firmware with the latest version provided by openwrt (commit number 38eeda3ae6f90fde5546bdd48ee4ff3090f238c0 from kernel.org/pub/scm/linux/kernel/git/firmare/linux-firmware) The fix for 4addr STA bridging is in the driver, not the firmware. The compat version you're using doesn't contain the required fix. I'm pretty sure openwrt compat 2014-09-26 contains it. Ok, I will test with this version. Thanks for your help. Michał -- 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
RE: ath10k firmware crash
Are you perhaps trying to run STA with 4addr bridging? If so then make sure you use recent ath10k as this was known to be a problem. Yes I'm testing with 4 addr bridging because I need to bridge this interface. I' ll try without this option. I'm testing with commit number 38eeda3ae6f90fde5546bdd48ee4ff3090f238c0 from kernel.org/pub/scm/linux/kernel/git/firmare/linux-firmware. It is the latest version in openwrt. Can you also provide ath10k traces or debug logs, please? I'll send a trace. I'm using the compat wireless from Openwrt. Compat wireless version 2014-05-22, but we updated the firmware with the latest version provided by openwrt (commit number 38eeda3ae6f90fde5546bdd48ee4ff3090f238c0 from kernel.org/pub/scm/linux/kernel/git/firmare/linux-firmware) The fix for 4addr STA bridging is in the driver, not the firmware. The compat version you're using doesn't contain the required fix. I'm pretty sure openwrt compat 2014-09-26 contains it. It fix my issue. Thanks for your help. Cedric Voncken Michał -- 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 -- 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
ath10k firmware crash
Hi all, I'm trying to use ath10k in client mode and AP mode with 2 wireless cards (Ap on one card and client on another card). The AP mode work, but the client mode always crash. Please find below the ath10k crash information [ 79.131301] ath10k: hardware name qca988x hw2.0 version 0x4100016c [ 79.149420] ath10k: firmware version: 999.999.0.636 [ 79.167248] ath10k: target register Dump Location: 0x0040AC14 [ 79.185939] ath10k: target Register Dump [ 79.201804] ath10k: [00]: 0x4100016C 0x 0x009C4521 0x [ 79.220184] ath10k: [04]: 0x009C4521 0x00060330 0x0019 0x00955A00 [ 79.238566] ath10k: [08]: 0xD0CE 0x 0x0040CC94 0x0020 [ 79.256945] ath10k: [12]: 0x 0x 0x00958360 0x0095836B [ 79.275327] ath10k: [16]: 0x809A0978 0x0040AD94 0x00439304 0x0040D074 [ 79.293706] ath10k: [20]: 0x 0x 0x0041EFB8 0x [ 79.312086] ath10k: [24]: 0x809A0978 0x0040AD94 0x00439304 0x0343389A [ 79.330466] ath10k: [28]: 0x809AD1A2 0x0040ADE4 0x00439304 0x0043F68C [ 79.348845] ath10k: [32]: 0x809B01DA 0x 0x00410110 0x0041937C [ 79.367224] ath10k: [36]: 0x 0x 0x 0x [ 79.385604] ath10k: [40]: 0x 0x 0x0071 0x00412700 [ 79.403984] ath10k: [44]: 0x00439BB8 0x 0x 0x0040 [ 79.422364] ath10k: [48]: 0x809AE0B4 0x0040AE04 0x0040 0x0043F68C [ 79.440744] ath10k: [52]: 0x0001 0x 0x004231F0 0x0040 [ 79.459124] ath10k: [56]: 0x809AE17E 0x0040AE44 0x0040FE6C 0x0040D310 I'm using openwrt, and I have the same problem with/without configuration option Firmware optimized for sta operation. Is it possible to use at the same time on 2 different cards the AP mode and client mode? Cedric Voncken -- 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: DFS pattern detector and ETSI EN 301 893 V1.7.1
Hi, I will test my equipment with the ETSI standard EN 301 893 1.7.1. I looked the DFS pattern detector set in ath9k driver and the comment specifies it compliant with the ETSI standard in V1.5.1. If I correctly understood the ath9k source code and the ETSI EN 301 893 standard, the table D.3 and D.4 in Annexes D of ETSI standard it uses to fill the ETSI_radar_ref_types_v15 structure. The difference between these tables in EN 301 893 v1.5.1 and EN 301 893 v1.7.1 is only the minimal pulse width (from 0.8 to 0.5). This value is set to 0 in many structure fields. Could you confirm the ETSI ath9k pattern detector is compatible with the ETSI EN 301 893 v1.7.1 standard? If it is right, I will send a patch to precise that in ath9k comment. Thanks for your help. Cedric Voncken -- 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
