Return-path: Received: from mail-la0-f43.google.com ([209.85.215.43]:38346 "EHLO mail-la0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756751Ab3KIVYE (ORCPT ); Sat, 9 Nov 2013 16:24:04 -0500 Received: by mail-la0-f43.google.com with SMTP id n7so1912464lam.30 for ; Sat, 09 Nov 2013 13:24:02 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <526E20EA.9090203@rempel-privat.de> Date: Sat, 9 Nov 2013 15:24:02 -0600 Message-ID: (sfid-20131109_222410_591284_9909F15A) Subject: Re: I always need a miracle to connect with iwlwifi From: Felipe Contreras To: Krishna Chaitanya Cc: Oleksij Rempel , ilw@linux.intel.com, "hostap@lists.shmoo.com" , linux-wireless Mailing List Content-Type: text/plain; charset=UTF-8 Sender: linux-wireless-owner@vger.kernel.org List-ID: On Sat, Nov 9, 2013 at 1:10 PM, Krishna Chaitanya wrote: > On Sat, Nov 9, 2013 at 10:22 PM, Felipe Contreras > wrote: >> On Sat, Nov 9, 2013 at 7:10 AM, Krishna Chaitanya >> wrote: >>> On Sat, Nov 9, 2013 at 2:22 AM, Felipe Contreras >>> wrote: >>>> On Fri, Nov 8, 2013 at 2:30 PM, Krishna Chaitanya >>>> 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