On Fri, Jul 29, 2011 at 3:50 PM, Mohammed Shafi <shafi.wireless@xxxxxxxxx> wrote: > On Fri, Jul 29, 2011 at 2:44 PM, Helmut Schaa > <helmut.schaa@xxxxxxxxxxxxxx> wrote: >> Hi, >> > Hi Helmut, > >> I just noticed that EAPOL frames generated by hostapd during the 4-way >> handshake are sent out by mac80211 using a rate as selected by the rc >> algorithm for data frames. In my case minstrel_ht selects a MCS rate for >> 11n clients which sometimes results in a 4-way handshake timeout under >> low signal conditions. > > I am occasionally seeing this issue in ath9k Station under heavy > traffic conditions > and low signal(only when I the distance between STA and AP is very > much significant), > some times I could no recreate the issue. I use ath9k-rate control and > I still found that the > EAPOL frames are being sent at lower rate. > with the sniffer capture there are lot of retries for 2nd message. > the timeout comes after 2nd message I might have missed out. looking back at one of the sniffer capture it seems the AP(very reliable one) is sending EAPOL to my STA at 1Mbps while the STA does not seems to be sending at legacy rate. > >> >> I haven't found anything in 802.11-2007 if EAPOL frames have to be sent >> at a low rate but I'd argue that it makes sense to send them at a basic >> rate just like it's done for management frames. let me try I can send it in lower rate and fixes the issue. >> >> We've got a nice little helper in mac80211 (rate_control_send_low) that >> allows the rc algorithm to check if a frame should be sent at a low rate. >> I thought I'd hook in there and just check skb->protocol to force EAPOL >> frames to the lowest rate. However, this didn't work out because in AP >> mode the EAPOL frames are injected through a monitor interface and as >> such skb->protocol is never initialized (ieee80211_monitor_start_xmit). >> >> The injected frames however already have an 802.11 header and therefore >> figuring out the ethertype of the injected frame is not as straightforward as >> I liked it to be :( >> >> Can I always be sure that an injected data frame (!=nullfunc) has a rfc1042 >> header following after the 802.11 header? >> >> Another option would be to let hostapd specify a fixed tx rate in the radiotap >> header (and extend mac80211 to understand it). However, since some drivers >> also make use of skb->protocol (to forbid aggregation for example) it sounds >> more sane to initialize it also for injected frames. > > in ath9k Raj pointed out that we are not doing aggregation if the > frame is of EAPOL, I can > check if I am missing something. > > >> >> Any other ideas? >> >> Thanks, >> Helmut >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > > > > -- > shafi > -- shafi -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
