On Sat, Nov 9, 2013 at 1:10 PM, Krishna Chaitanya <chaitanya.mgit@xxxxxxxxx> wrote: > On Sat, Nov 9, 2013 at 10:22 PM, Felipe Contreras > <felipe.contreras@xxxxxxxxx> wrote: >> On Sat, Nov 9, 2013 at 7:10 AM, Krishna Chaitanya >> <chaitanya.mgit@xxxxxxxxx> wrote: >>> On Sat, Nov 9, 2013 at 2:22 AM, Felipe Contreras >>> <felipe.contreras@xxxxxxxxx> wrote: >>>> On Fri, Nov 8, 2013 at 2:30 PM, Krishna Chaitanya >>>> <chaitanya.mgit@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? >> >> 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 -- 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
