I always need a miracle to connect with iwlwifi

Krishna Chaitanya chaitanya.mgit
Sat Nov 9 05:10:30 PST 2013

On Sat, Nov 9, 2013 at 2:22 AM, Felipe Contreras
<felipe.contreras at gmail.com> wrote:
> On Fri, Nov 8, 2013 at 2:30 PM, Krishna Chaitanya
> <chaitanya.mgit at gmail.com> wrote:
>> On Fri, Nov 8, 2013 at 7:48 PM, Felipe Contreras
>> <felipe.contreras at gmail.com> wrote:
>>> On Fri, Nov 8, 2013 at 8:06 AM, Krishna Chaitanya
>>> <chaitanya.mgit at gmail.com> wrote:
>>>> On Fri, Nov 8, 2013 at 6:44 PM, Felipe Contreras
>>>> <felipe.contreras at gmail.com> wrote:
>>>>> On Fri, Nov 8, 2013 at 2:35 AM, Felipe Contreras
>>>>> <felipe.contreras at gmail.com> wrote:
>>>>>> On Sat, Nov 2, 2013 at 2:05 PM, Krishna Chaitanya
>>>>>> <chaitanya.mgit at gmail.com> 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?
This is not just for your case but rather on a generic note. Regarding
the flag even i am not
too sure but i guess some hardware need to know the DTIM to set the
wakeup schedule
after 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.
Ok. So when we disable advertising of that flag in the driver you said things
are working fine. So in that scenario after the connection are you
seeing the beacons?

Just want to understand the problem is throughout or just before association.
If the driver itself it not getting the beacons then our debugging ends there,
some one from intel should guide you through the FW debugging.

More information about the Hostap mailing list