On Fri, Nov 8, 2013 at 2:30 PM, Krishna Chaitanya <chaitanya.mgit@xxxxxxxxx> wrote: > On Fri, Nov 8, 2013 at 7:48 PM, Felipe Contreras > <felipe.contreras@xxxxxxxxx> wrote: >> On Fri, Nov 8, 2013 at 8:06 AM, Krishna Chaitanya >> <chaitanya.mgit@xxxxxxxxx> wrote: >>> On Fri, Nov 8, 2013 at 6:44 PM, Felipe Contreras >>> <felipe.contreras@xxxxxxxxx> wrote: >>>> On Fri, Nov 8, 2013 at 2:35 AM, Felipe Contreras >>>> <felipe.contreras@xxxxxxxxx> wrote: >>>>> On Sat, Nov 2, 2013 at 2:05 PM, Krishna Chaitanya >>>>> <chaitanya.mgit@xxxxxxxxx> wrote: >>>>> >>>>>> Also one more thing you said N900 uses mac80211 and it has no issues, but as >>>>>> its a embedded device it might running an older kernel where the >>>>>> handling might be >>>>>> different, so we need to try with the same kernel you are facing an >>>>>> issue with the >>>>>> a driver which advertises IEEE80211_HW_NEED_DTIM_BEFORE_ASSOC. >>>>> >>>>> Yes it was running an older kernel, but I just compiled v3.12 and ran >>>>> it on the N900, and still everything works fine. >>>>> >>>>>> (or) if you a have a compilation environment try commenting the advertisement of >>>>>> IEEE80211_HW_NEED_DTIM_BEFORE_ASSOC in the iwlwifi DVM driver and >>>>>> try to reproduce the issue. >>>>> >>>>> After commenting that flag everything works fine :) >>> >>> Oh, great. That was just to corner the problem, that means we are not getting >>> the required beacon before the association, but we only wait for 1 beacon here >>> may be we to wait for some number of beacons before giving up the association?? >>> >>> Johannes?? >> >> But we are receiving 0 beacons, waiting for more than 1 won't help. >> BTW, why NEED_DTIM_BEFORE_ASSOC if the device doesn't *need* the DTIM >> before the association? >> >>>>> What are the next steps? >>>> >>>> I tried to add some debugging to see what's going on, and indeed the >>>> beacon packets are lost, I added debugging as low in the chain as I >>>> could (iwlagn_rx_reply_rx()), and I don't see them there. However, >>>> when I enable the monitor mode, I see them. What's going on? >>> >>> In the captures you shared all the beacons are malformed, so >>> probably they failed the CRC check. iwlwifi drops all the CRC failed >>> packets. (doth MVM and DVM) >> >> Before iwlagn_rx_reply_rx()? >> >>> Not sure how you are receiving the beacons in the monitor mode. >> >> I don't know what kismet does, but I can see my debugging is printing them. >> >>> BTW did you tried capturing the beacons in other devices and see if they >>> are really malformed, or is it just iwlwifi interpreting them wrongly.? >> >> I haven't managed to do that yet. >> >> This is what I'm doing: >> >> --- a/drivers/net/wireless/iwlwifi/dvm/rx.c >> +++ b/drivers/net/wireless/iwlwifi/dvm/rx.c >> @@ -919,6 +919,11 @@ static int iwlagn_rx_reply_rx(struct iwl_priv *priv, >> ampdu_status = iwlagn_translate_rx_status(priv, >> le32_to_cpu(rx_pkt_status)); >> >> + if (ieee80211_is_beacon(header->frame_control)) { >> + print_hex_dump(KERN_INFO, "iwlwifi: dump: ", DUMP_PREFIX_OFFSET, >> + 16, 1, header, len, true); >> + } >> + >> if ((unlikely(phy_res->cfg_phy_cnt > 20))) { >> IWL_DEBUG_DROP(priv, "dsp size out of range [0,20]: %d\n", >> phy_res->cfg_phy_cnt); >> > Oops...you just missed, Right after your print there is a check to > drop frames with BAD CRC :-). That's why I put the print before that check. Since I don't see the print, that means the check was never executed. iwlagn_rx_reply_rx() was never called for the beacon frame. -- Felipe Contreras -- 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