I always need a miracle to connect with iwlwifi

[Felipe Contreras]

On Sat, Nov 9, 2013 at 1:10 PM, Krishna Chaitanya
<chaitanya.mgit at gmail.com> wrote:
> On Sat, Nov 9, 2013 at 10:22 PM, Felipe Contreras
> <felipe.contreras at gmail.com> wrote:
>> On Sat, Nov 9, 2013 at 7:10 AM, Krishna Chaitanya
>> <chaitanya.mgit at gmail.com> wrote:
>>> 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:
>>
>>>>>> 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?
>>
>> But not this hardware? Because everything works fine.
>>
>>>>> 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.
>>
>> Yes, everything works perfectly.
>>
>>> So in that scenario after the connection are you
>>> seeing the beacons?
>>
>> No, there are no beacons ever, at least from this AP

> Oh ok, thats interesting. Are you not seeing any disconnects due
> to beacon loss triggers?

I see some disconnects now and then, but I don't know why. Before
trying to tackle those problems I would like to be able to connect
reliably.

> Also can you add some debugging to the iwlagn_rx_beacon_notif
> (the beacon RX handler)?

All right, I've added debugging there, but so far I see nothing.

>> It seems to me all the beacon frames are dropped by the firmware
>> before passing them to the driver, so the driver cannot parse them and
>> do something sensible even though they are corrupted, the driver never
>> gets them.
>>
>>> 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.
>>
>> Not really, part of the debugging ends there, but we can still do something.
>>
>> What is the meaning of NEED_DTIM_BEFORE_ASSOC, if the driver doesn't
>> *need* this? Why fail the association completely, if we don't need to?
>>
>> Also, I realized that after rebooting the router, the beacon frames
>> are not corrupted any more, so it's a compound problem, yet even in
>> the corrupted case, the driver can work just fine, if only it didn't
>> *require* the DTIM unnecessarily,
>
> Yeah, that's more of design query with the problem being not able to
> Rx the beacons? We need to understand the reason for this flag being
> set by the iwlwifi driver.

Indeed.

>>as apparently all hardware and even
>> other OS'es on this hardware do.
>
> Thats the reason this flag is a _HW_ not all hardwares requrie this
> but intel does.

But it doesn't, my hardware is Intel, and it works fine without it.

-- 
Felipe Contreras