I always need a miracle to connect with iwlwifi

[Felipe Contreras]

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?
>>
>>>>> 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