Return-path: Received: from mail-wi0-f179.google.com ([209.85.212.179]:64310 "EHLO mail-wi0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756750Ab3KIVh4 (ORCPT ); Sat, 9 Nov 2013 16:37:56 -0500 Received: by mail-wi0-f179.google.com with SMTP id fb10so760945wid.12 for ; Sat, 09 Nov 2013 13:37:55 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <526E20EA.9090203@rempel-privat.de> From: Krishna Chaitanya Date: Sun, 10 Nov 2013 03:07:35 +0530 Message-ID: (sfid-20131109_223812_049376_622C1DCB) Subject: Re: I always need a miracle to connect with iwlwifi To: Felipe Contreras Cc: Oleksij Rempel , ilw@linux.intel.com, "hostap@lists.shmoo.com" , linux-wireless Mailing List , Johannes Berg , egrumbach@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-wireless-owner@vger.kernel.org List-ID: On Sun, Nov 10, 2013 at 2:54 AM, Felipe Contreras wrote: > 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. 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? >>> >>> 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.