On 11/10/2013 06:26 PM, Felipe Contreras wrote: > On Sun, Nov 10, 2013 at 12:31 AM, Emmanuel Grumbach <egrumbach@xxxxxxxxx> 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? >>>>>> >> >> Right - we need the send the beacon interval to the device *before* we >> configure the device to be associated. > > But what do you mean "need"? If I remove the flag the association works fine. > >>>>>> 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. >>>>>>>> >> >> That won't help since the firmware will drop frames with bad CRC, >> unless you are in monitor mode. > > And apparently ad-hoc mode too. > > Either way that's not helping, ideally those corrupted beacons should > be parsed by the driver, it will see they are corrupted, but still do > something sensible. > >>>>>>> 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. >> >> No wonder. If we can't receive any beacons you can expect issues.... >> PS will be completely broken and that is only the first on the list... > > That's OK, it's better to connect with issues rather than not connect at all. > >>> Its probably the beacons loss that triggering the disconnects, so >>> both the problem have the same cause. Its the beacon reception >>> we need to figure it out. >>> >>> Adding some intel guys explicitly. >>> >>>>> 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. >>>> >>> >>> Hmm...dead end this side too. >>> >>>>>> 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? >>>>>> >> >> As I explained, the firmware needs to. This is for configuring the PS >> state machine. But since you AP is completely broken, PS is likely not >> to work at all anyway.... > > I don't use powersave anyway. > >> And my small experience in WiFi leads me to the conclusion that if a >> driver cannot rely on the AP sending beacon, it is really in trouble. > > Somehow every device in this house doesn't seem to have a problem. > Even this device in Windows works fine. > >> We can cope with buggy AP, but not associate to microwaves. >> Other devices will work, granted. But they can't go to sleep then, and >> need to poke the AP from time to time to make sure it hasn't >> disappeared. > > That's better than not associating at all, ever. No because it would break the driver against all the working APs which are fortunately enough more common. Maybe you can rewrite mac80211 / iwlwifi to make things work differently so that PS would still work with good APs and association would work with yours. Fair enough. Go ahead. > >> Note that this is true regardless of the design / HW wahtever. Ok, the >> Windows driver on the same device works with this "AP". Fine. But it >> can't theoretically can't work well. Nor can any other WiFi device >> that can't hear the beacon. Now - maybe we have an issue in the Linux >> driver that mangles the beacons (PHY stuff) - that's possible. But >> since you haven't sent a sniffer capture of the AP with another >> device, we can't know. > > That's right, I tried to do that with an N900 but the monitor mode > doesn't work. I'll keep trying. > >>>>>> 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. >>>> >>> Yeah, so far so good. But there should be a reason why they are >>> specifically advertising this flag? Also DTIM is Multicast+Powersave >>> so a rare thing, we might no hit that too often. >> >> Hmm... well... N/M. > > Wouldn't it make sense to timeout if there's no DTIM, and still > associate? It's better than not associating ever. Plus, if you already > know that power saving wouldn't work in this case, merely disable > powersave. > I can't wait for your patch. -- 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
