Hello,
I'm using iwlwifi for a Centrino Ultimate-N 6300 on 3.14.4 and 3.17.1.
Connect to my wireless network works, but I get disconnected every 60
seconds or so. The dmesg output looks like
https://bpaste.net/show/1623a8ae5dc6 .
I had the same issue on the three latest firmware versions:
iwlwifi-6000-ucode-9.176.4.1
iwlwifi-6000-ucode-9.193.4.1
iwlwifi-6000-ucode-9.221.4.1
The dmesg log actually shows the driver loading the different versions
above.
It's the first time I try to use wireless on Linux, so I might have made
a dumb mistake.
Thanks for any tips,
Laurentiu Nicola
On Thu, Oct 16, 2014 at 3:48 PM, Laurențiu Nicola <[email protected]> wrote:
> Hello,
>
> I'm using iwlwifi for a Centrino Ultimate-N 6300 on 3.14.4 and 3.17.1.
> Connect to my wireless network works, but I get disconnected every 60
> seconds or so. The dmesg output looks like
> https://bpaste.net/show/1623a8ae5dc6 .
>
> I had the same issue on the three latest firmware versions:
> iwlwifi-6000-ucode-9.176.4.1
> iwlwifi-6000-ucode-9.193.4.1
> iwlwifi-6000-ucode-9.221.4.1
>
> The dmesg log actually shows the driver loading the different versions
> above.
>
> It's the first time I try to use wireless on Linux, so I might have made
> a dumb mistake.
>
I'd try to use a different network manager.
This is the the place to get support for this though.
Okay. I'm running 3.17.1, so the line numbers might not be the ones
you're expecting:
patching file net/mac80211/mlme.c
Hunk #1 succeeded at 128 (offset -1 lines).
Hunk #2 succeeded at 137 (offset -1 lines).
Hunk #3 succeeded at 1875 (offset -209 lines).
Hunk #4 succeeded at 1886 (offset -207 lines).
Hunk #5 succeeded at 1908 (offset -207 lines).
Hunk #6 succeeded at 1924 (offset -244 lines).
dmesg output is at https://bpaste.net/show/649277aaada8 .
Laurentiu
On Thu, Oct 23, 2014, at 19:46, Emmanuel Grumbach wrote:
> On Thu, Oct 23, 2014 at 7:02 PM, Laurențiu Nicola <[email protected]>
> wrote:
> > Sorry, but I only saw a two-line change [1] to
> > `ieee80211_rx_mgmt_beacon` (which already had a log message). Am I
> > missing something?
> >
> > [1] http://www.spinics.net/lists/linux-wireless/msg128340.html
> >
>
> No - you are not. I did miss something...I forgot to attach the patch.
> Here you go.
>
> > Laurentiu
> >
> > On Thu, Oct 23, 2014, at 11:07, Emmanuel Grumbach wrote:
> >> On Thu, Oct 23, 2014 at 10:30 AM, Laurențiu Nicola <[email protected]>
> >> wrote:
> >> > I did; the card still gets disconnected and the message doesn't show up
> >> > in dmesg.
> >> >
> >>
> >> You had *none* of the many prints I added in the log?
> >>
> >> That seems really weird...
> >>
> >> > Laurentiu
> >> >
> >> > On Thu, Oct 23, 2014, at 08:21, Emmanuel Grumbach wrote:
> >> >> On Thu, Oct 23, 2014 at 12:53 AM, Laurențiu Nicola <[email protected]>
> >> >> wrote:
> >> >> > Nope. It seems that code doesn't get executed when my issue occurs (or
> >> >> > in my five or ten minutes of uptime). I've seen
> >> >> > `ieee80211_reset_ap_probe` get called by `ieee80211_rx_mgmt_probe_resp`,
> >> >> > but (if I'm not wrong) not on every disconnect.
> >> >> >
> >> >> > And as far as I can tell, force_cam is set to true.
> >> >>
> >> >> Can you please try with the patch attached and send the logs?
> >> >> I again need MAC80211_MLME_DEBUG.
> >> >>
> >> >> Thanks.
> >> >>
> >> >> >
> >> >> > Laurentiu
> >> >> >
> >> >> > On Wed, Oct 22, 2014, at 12:10, Emmanuel Grumbach wrote:
> >> >> >> On Tue, Oct 21, 2014 at 10:56 PM, Laurențiu Nicola <[email protected]>
> >> >> >> wrote:
> >> >> >> > Yep! `scb_timeout` is 60 on my router.
> >> >> >> >
> >> >> >> > On Tue, Oct 21, 2014, at 14:00, poma wrote:
> >> >> >> >> On 21.10.2014 10:35, Felix Fietkau wrote:
> >> >> >> >> > On 2014-10-21 10:23, Laurențiu Nicola wrote:
> >> >> >> >> >> It's an ASUS RT-N66U running NEWD-2/K3X from r24160.
> >> >> >> >> > This is a Broadcom based device, so it should behave in the same way as
> >> >> >> >> > other APs/Routers running the Broadcom drivers.
> >> >> >> >> > The driver should only send Reason 7 when receiving a PS-Poll, BlockAck,
> >> >> >> >> > BlockAckReq or Action frame from a station that's not associated, so
> >> >> >> >> > probably it has already kicked out your iwlwifi client earlier. Not sure
> >> >> >> >> > why that doesn't show up in the log though.
> >> >> >> >> >
> >> >> >> >>
> >> >> >> >> Whether this might refer to the Station Control Block Timeout value
> >> >> >> >>
> >> >> >> >> http://www.dd-wrt.com/wiki/index.php/Wl#scb_timeout
> >> >> >> >> ...
> >> >> >> >> scb_timeout
> >> >> >> >>
> >> >> >> >> AP only: inactivity timeout value for authenticated stas
> >> >> >> >>
> >> >> >>
> >> >> >> Actually, mac80211 should be probing the AP every 30 seconds but a
> >> >> >> beacon might abort the probe...
> >> >> >> Can you try something like this:
> >> >> >>
> >> >> >> diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
> >> >> >> index 75df184..c9db7cf 100644
> >> >> >> --- a/net/mac80211/mlme.c
> >> >> >> +++ b/net/mac80211/mlme.c
> >> >> >> @@ -3295,7 +3295,8 @@ static void ieee80211_rx_mgmt_beacon(struct
> >> >> >> ieee80211_sub_if_data *sdata,
> >> >> >> if (ifmgd->flags & IEEE80211_STA_CONNECTION_POLL) {
> >> >> >> mlme_dbg_ratelimited(sdata,
> >> >> >> "cancelling AP probe due to a
> >> >> >> received beacon\n");
> >> >> >> - ieee80211_reset_ap_probe(sdata);
> >> >> >> + pr_err("Not cancelling the probe to make sure the AP
> >> >> >> hears us from time to time\n");
> >> >> >> + //ieee80211_reset_ap_probe(sdata);
> >> >> >> }
> >> >> >>
> >> >> >> /*
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> >>
> >> >> >> >> poma
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> --
> >> >> >> >> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
> >> >> >> >> in
> >> >> >> >> the body of a message to [email protected]
> >> >> >> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >> >> >> --
> >> >> >> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
> >> >> >> in
> >> >> >> the body of a message to [email protected]
> >> >> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >> >> --
> >> >> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
> >> >> in
> >> >> the body of a message to [email protected]
> >> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
> >> in
> >> the body of a message to [email protected]
> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Email had 1 attachment:
> + PROBE.patch
> 3k (application/octet-stream)
On Tue, Oct 21, 2014 at 12:06 PM, Krishna Chaitanya
<[email protected]> wrote:
> On Tue, Oct 21, 2014 at 11:01 AM, Emmanuel Grumbach <[email protected]> wrote:
>> On Tue, Oct 21, 2014 at 8:02 AM, Emmanuel Grumbach <[email protected]> wrote:
>>> On Mon, Oct 20, 2014 at 10:29 PM, Laurențiu Nicola <[email protected]> wrote:
>>>> No, nothing in the DD-WRT syslog. The IP seems to be the one cached by
>>>> my DHCP client. I also tried various suggestions found on the internet,
>>>> but nothing helped.
>>>>
>>>
>>> Can you please try to have another device in monitor mode to sniff the
>>> traffic going on?
>>> Felix, can you please tell me when DD-WRT can send a deauth with reason code 7?
>>>
>>> thanks.
>>
>> Can you please disable power save?
>> For this, please make sure you have
>> https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/iwlwifi-fixes.git/commit/?id=f8dfc607b2b460e8e8adfdfb3c5f5bba3a4ad01b
>> or at least have the module parameter.
>> I am wondering if the firmware is not sending frames because of power
>> save toggling.
>>
>> I you could get more extensive logs from the AP it'd be great.
>> Running tracing on the AP would let us know why it thinks we are not associated.
>>
> I have faced the same issue before it happens when DUT is in powersave
> and for some reason AP authenticates (in this case probably due to
*typo: deuauthenticates.
> inactivity) but as DUT is in power save we don't Rx the deauth (some
> AP's don't wait
> for STA to wakeup and retrieve the deauth frame).
>
> So after that if DUT tries to sent any data frame, as it still thinks
> that it is connected
> (network lost also will not trigger because it still Rx beacon) and in
> that case AP deauthenticates
> us by Reason:7.
>
> May be if we enable tx status report ACK we can pass the inactivity
> check as some AP's
> wont reset inactivity timer for probe's.
On Fri, Oct 24, 2014 at 11:34 AM, Laurențiu Nicola <[email protected]> wrote:
> Okay, I've filed a bug [1].
>
> At some point you mentioned about using another device to monitor
> traffic. I don't have another laptop running Linux (would Android
> count?), but DD-WRT has a "wl monitor" command [2] that sounds useful.
> Should I try to install tcpdump on my router?
You can try - but I think that tracing might help and is easier to get.
I put the instructions in the bug.
>
> Laurentiu
>
> [1] https://bugzilla.kernel.org/show_bug.cgi?id=86801
> [2] http://www.dd-wrt.com/wiki/index.php/Wl#monitor
>
> On Fri, Oct 24, 2014, at 08:32, Emmanuel Grumbach wrote:
>> On Thu, Oct 23, 2014 at 11:33 PM, Emmanuel Grumbach <[email protected]>
>> wrote:
>> > On Thu, Oct 23, 2014 at 11:27 PM, Laurențiu Nicola <[email protected]> wrote:
>> >> https://bpaste.net/show/8a0e5c68762f
>> >>
>> >> On Thu, Oct 23, 2014, at 23:16, Emmanuel Grumbach wrote:
>> >>> > https://bpaste.net/show/5cc48256d952
>> >>> >
>> >>> > On Thu, Oct 23, 2014, at 22:55, Emmanuel Grumbach wrote:
>> >>> >> On Thu, Oct 23, 2014 at 10:42 PM, Laurențiu Nicola <[email protected]>
>> >>> >> wrote:
>> >>> >>> Doesn't seem to help https://bpaste.net/show/68e1a6b33689.
>> >>> >>
>> >>> >> ok - let me re-add the logs...
>> >>> >>
>> >>> >>
>> >>>
>> >>> This makes no sense to me.
>> >>> We do talk to the AP since we get frames Acked...
>> >
>> > This again makes no sense to me.
>> > Time to go to bed I guess.
>>
>> Can you please open a bug on bugzilla.kernel.org?
>> Make sure to CC [email protected]
>>
>> This will make it more trackable.
>> Thanks.
>>
>> >
>> >>>
>> >>> Can you please apply this on top of what you have?
>> >>>
>> >>> diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
>> >>> index 2de8870..f3b1e62 100644
>> >>> --- a/net/mac80211/mlme.c
>> >>> +++ b/net/mac80211/mlme.c
>> >>> @@ -1991,15 +1991,16 @@ void ieee80211_sta_tx_notify(struct
>> >>> ieee80211_sub_if_data *sdata,
>> >>> if (ieee80211_is_nullfunc(hdr->frame_control) &&
>> >>> sdata->u.mgd.probe_send_count > 0) {
>> >>> if (ack)
>> >>> - ieee80211_sta_reset_conn_monitor(sdata);
>> >>> + // ieee80211_sta_reset_conn_monitor(sdata);
>> >>> + ;
>> >>> else
>> >>> sdata->u.mgd.nullfunc_failed = true;
>> >>> ieee80211_queue_work(&sdata->local->hw, &sdata->work);
>> >>> return;
>> >>> }
>> >>>
>> >>> - if (ack)
>> >>> - ieee80211_sta_reset_conn_monitor(sdata);
>> >>> +// if (ack)
>> >>> +// ieee80211_sta_reset_conn_monitor(sdata);
>> >>> }
>> >>>
>> >>> static void ieee80211_mgd_probe_ap_send(struct ieee80211_sub_if_data
>> >>> *sdata)
>> >>>
>> >>>
>> >>> Thanks.
>> >>> --
>> >>> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
>> >>> in
>> >>> the body of a message to [email protected]
>> >>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
>> in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Oct 19, 2014 at 11:48 PM, Laurențiu Nicola <[email protected]> wrote:
> Hello,
>
> Sorry for the late reply. I was using just wpa_supplicant. I also tried
> wicd, but it seems to hang when connecting to a network, but my
> understanding is that it's just a wpa_supplicant manager. I got this
> while installing Gentoo, but I also reproduced it on the Fedora 20 Live
> CD. See https://bpaste.net/show/7d5ad99260a7 for logs, but it doesn't
> seem to say much more than my original extract.
>
> What I found out in the meanwhile, however, is that active traffic will
> prevent the issue from occurring. This happened with the Fedora Live CD,
> but pinging the AP is also sufficient. I noticed iwconfig reports that
> the power saving mode is off.
>
> For what it's worth, I compiled my kernel and iwlwifi module with
> tracing on, so tell me if I should try that.
Please recompile with MAC80211_MLME_DEBUG, MAC80211_STA_DEBUG and
reproduce - thanks.
>
> Laurentiu
>
>
> On Fri, Oct 17, 2014, at 04:53, Dan Williams wrote:
>> On Thu, 2014-10-16 at 15:48 +0300, Laurențiu Nicola wrote:
>> > Hello,
>> >
>> > I'm using iwlwifi for a Centrino Ultimate-N 6300 on 3.14.4 and 3.17.1.
>> > Connect to my wireless network works, but I get disconnected every 60
>> > seconds or so. The dmesg output looks like
>> > https://bpaste.net/show/1623a8ae5dc6 .
>> >
>> > I had the same issue on the three latest firmware versions:
>> > iwlwifi-6000-ucode-9.176.4.1
>> > iwlwifi-6000-ucode-9.193.4.1
>> > iwlwifi-6000-ucode-9.221.4.1
>> >
>> > The dmesg log actually shows the driver loading the different versions
>> > above.
>> >
>> > It's the first time I try to use wireless on Linux, so I might have made
>> > a dumb mistake.
>>
>> Can you try to get debug output from wpa_supplicant, which is the
>> process that controls WiFi on Linux? What distro and version do you
>> use, and do you know what WiFi management service is being used?
>> (NetworkManager, conman, plain wpa_supplicant, wicd, something else?)
>>
>> Dan
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Oct 21, 2014 at 2:46 PM, Emmanuel Grumbach <[email protected]> wrote:
> On Tue, Oct 21, 2014 at 12:05 PM, Krishna Chaitanya
> <[email protected]> wrote:
>> On Tue, Oct 21, 2014 at 2:05 PM, Felix Fietkau <[email protected]> wrote:
>>> On 2014-10-21 10:23, Laurențiu Nicola wrote:
>>>> It's an ASUS RT-N66U running NEWD-2/K3X from r24160.
>>> This is a Broadcom based device, so it should behave in the same way as
>>> other APs/Routers running the Broadcom drivers.
>>> The driver should only send Reason 7 when receiving a PS-Poll, BlockAck,
>>> BlockAckReq or Action frame from a station that's not associated, so
>>> probably it has already kicked out your iwlwifi client earlier. Not sure
>>> why that doesn't show up in the log though.
>>>
>> May be iwlwifi is dozing and did not Rx that frame?
>
> yep - this is most probably what happens. iwlwifi goes to sleep and it
> get a deauth that it doesn't hear. Then it wakes up with an NDP and
> gets kicked out.
> But shouldn't the deauth be buffered and indicated through the TIM IE?
Yes, but not all AP's do that, at least the one i faced the issue was
not doing that.
--
Thanks,
Regards,
Chaitanya T K.
On Thu, Oct 23, 2014 at 7:02 PM, Laurențiu Nicola <[email protected]> wrote:
> Sorry, but I only saw a two-line change [1] to
> `ieee80211_rx_mgmt_beacon` (which already had a log message). Am I
> missing something?
>
> [1] http://www.spinics.net/lists/linux-wireless/msg128340.html
>
No - you are not. I did miss something...I forgot to attach the patch.
Here you go.
> Laurentiu
>
> On Thu, Oct 23, 2014, at 11:07, Emmanuel Grumbach wrote:
>> On Thu, Oct 23, 2014 at 10:30 AM, Laurențiu Nicola <[email protected]>
>> wrote:
>> > I did; the card still gets disconnected and the message doesn't show up
>> > in dmesg.
>> >
>>
>> You had *none* of the many prints I added in the log?
>>
>> That seems really weird...
>>
>> > Laurentiu
>> >
>> > On Thu, Oct 23, 2014, at 08:21, Emmanuel Grumbach wrote:
>> >> On Thu, Oct 23, 2014 at 12:53 AM, Laurențiu Nicola <[email protected]>
>> >> wrote:
>> >> > Nope. It seems that code doesn't get executed when my issue occurs (or
>> >> > in my five or ten minutes of uptime). I've seen
>> >> > `ieee80211_reset_ap_probe` get called by `ieee80211_rx_mgmt_probe_resp`,
>> >> > but (if I'm not wrong) not on every disconnect.
>> >> >
>> >> > And as far as I can tell, force_cam is set to true.
>> >>
>> >> Can you please try with the patch attached and send the logs?
>> >> I again need MAC80211_MLME_DEBUG.
>> >>
>> >> Thanks.
>> >>
>> >> >
>> >> > Laurentiu
>> >> >
>> >> > On Wed, Oct 22, 2014, at 12:10, Emmanuel Grumbach wrote:
>> >> >> On Tue, Oct 21, 2014 at 10:56 PM, Laurențiu Nicola <[email protected]>
>> >> >> wrote:
>> >> >> > Yep! `scb_timeout` is 60 on my router.
>> >> >> >
>> >> >> > On Tue, Oct 21, 2014, at 14:00, poma wrote:
>> >> >> >> On 21.10.2014 10:35, Felix Fietkau wrote:
>> >> >> >> > On 2014-10-21 10:23, Laurențiu Nicola wrote:
>> >> >> >> >> It's an ASUS RT-N66U running NEWD-2/K3X from r24160.
>> >> >> >> > This is a Broadcom based device, so it should behave in the same way as
>> >> >> >> > other APs/Routers running the Broadcom drivers.
>> >> >> >> > The driver should only send Reason 7 when receiving a PS-Poll, BlockAck,
>> >> >> >> > BlockAckReq or Action frame from a station that's not associated, so
>> >> >> >> > probably it has already kicked out your iwlwifi client earlier. Not sure
>> >> >> >> > why that doesn't show up in the log though.
>> >> >> >> >
>> >> >> >>
>> >> >> >> Whether this might refer to the Station Control Block Timeout value
>> >> >> >>
>> >> >> >> http://www.dd-wrt.com/wiki/index.php/Wl#scb_timeout
>> >> >> >> ...
>> >> >> >> scb_timeout
>> >> >> >>
>> >> >> >> AP only: inactivity timeout value for authenticated stas
>> >> >> >>
>> >> >>
>> >> >> Actually, mac80211 should be probing the AP every 30 seconds but a
>> >> >> beacon might abort the probe...
>> >> >> Can you try something like this:
>> >> >>
>> >> >> diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
>> >> >> index 75df184..c9db7cf 100644
>> >> >> --- a/net/mac80211/mlme.c
>> >> >> +++ b/net/mac80211/mlme.c
>> >> >> @@ -3295,7 +3295,8 @@ static void ieee80211_rx_mgmt_beacon(struct
>> >> >> ieee80211_sub_if_data *sdata,
>> >> >> if (ifmgd->flags & IEEE80211_STA_CONNECTION_POLL) {
>> >> >> mlme_dbg_ratelimited(sdata,
>> >> >> "cancelling AP probe due to a
>> >> >> received beacon\n");
>> >> >> - ieee80211_reset_ap_probe(sdata);
>> >> >> + pr_err("Not cancelling the probe to make sure the AP
>> >> >> hears us from time to time\n");
>> >> >> + //ieee80211_reset_ap_probe(sdata);
>> >> >> }
>> >> >>
>> >> >> /*
>> >> >>
>> >> >>
>> >> >>
>> >> >> >>
>> >> >> >> poma
>> >> >> >>
>> >> >> >>
>> >> >> >> --
>> >> >> >> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
>> >> >> >> in
>> >> >> >> the body of a message to [email protected]
>> >> >> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> >> >> --
>> >> >> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
>> >> >> in
>> >> >> the body of a message to [email protected]
>> >> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> >> --
>> >> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
>> >> in
>> >> the body of a message to [email protected]
>> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
>> in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Oct 20, 2014 at 8:30 AM, Laurențiu Nicola <[email protected]> wrote:
> Here: https://bpaste.net/show/bf6dc1847ce3
>
Are you sure you had MAC80211_MLME_DEBUG?
>
> Laurentiu
> On Mon, Oct 20, 2014, at 07:52, Emmanuel Grumbach wrote:
>> On Sun, Oct 19, 2014 at 11:48 PM, Laurențiu Nicola <[email protected]>
>> wrote:
>> > Hello,
>> >
>> > Sorry for the late reply. I was using just wpa_supplicant. I also tried
>> > wicd, but it seems to hang when connecting to a network, but my
>> > understanding is that it's just a wpa_supplicant manager. I got this
>> > while installing Gentoo, but I also reproduced it on the Fedora 20 Live
>> > CD. See https://bpaste.net/show/7d5ad99260a7 for logs, but it doesn't
>> > seem to say much more than my original extract.
>> >
>> > What I found out in the meanwhile, however, is that active traffic will
>> > prevent the issue from occurring. This happened with the Fedora Live CD,
>> > but pinging the AP is also sufficient. I noticed iwconfig reports that
>> > the power saving mode is off.
>> >
>> > For what it's worth, I compiled my kernel and iwlwifi module with
>> > tracing on, so tell me if I should try that.
>>
>> Please recompile with MAC80211_MLME_DEBUG, MAC80211_STA_DEBUG and
>> reproduce - thanks.
>>
>> >
>> > Laurentiu
>> >
>> >
>> > On Fri, Oct 17, 2014, at 04:53, Dan Williams wrote:
>> >> On Thu, 2014-10-16 at 15:48 +0300, Laurențiu Nicola wrote:
>> >> > Hello,
>> >> >
>> >> > I'm using iwlwifi for a Centrino Ultimate-N 6300 on 3.14.4 and 3.17.1.
>> >> > Connect to my wireless network works, but I get disconnected every 60
>> >> > seconds or so. The dmesg output looks like
>> >> > https://bpaste.net/show/1623a8ae5dc6 .
>> >> >
>> >> > I had the same issue on the three latest firmware versions:
>> >> > iwlwifi-6000-ucode-9.176.4.1
>> >> > iwlwifi-6000-ucode-9.193.4.1
>> >> > iwlwifi-6000-ucode-9.221.4.1
>> >> >
>> >> > The dmesg log actually shows the driver loading the different versions
>> >> > above.
>> >> >
>> >> > It's the first time I try to use wireless on Linux, so I might have made
>> >> > a dumb mistake.
>> >>
>> >> Can you try to get debug output from wpa_supplicant, which is the
>> >> process that controls WiFi on Linux? What distro and version do you
>> >> use, and do you know what WiFi management service is being used?
>> >> (NetworkManager, conman, plain wpa_supplicant, wicd, something else?)
>> >>
>> >> Dan
>> >>
>> > --
>> > To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
>> > the body of a message to [email protected]
>> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
>> in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Oct 23, 2014 at 12:53 AM, Laurențiu Nicola <[email protected]> wrote:
> Nope. It seems that code doesn't get executed when my issue occurs (or
> in my five or ten minutes of uptime). I've seen
> `ieee80211_reset_ap_probe` get called by `ieee80211_rx_mgmt_probe_resp`,
> but (if I'm not wrong) not on every disconnect.
>
> And as far as I can tell, force_cam is set to true.
Can you please try with the patch attached and send the logs?
I again need MAC80211_MLME_DEBUG.
Thanks.
>
> Laurentiu
>
> On Wed, Oct 22, 2014, at 12:10, Emmanuel Grumbach wrote:
>> On Tue, Oct 21, 2014 at 10:56 PM, Laurențiu Nicola <[email protected]>
>> wrote:
>> > Yep! `scb_timeout` is 60 on my router.
>> >
>> > On Tue, Oct 21, 2014, at 14:00, poma wrote:
>> >> On 21.10.2014 10:35, Felix Fietkau wrote:
>> >> > On 2014-10-21 10:23, Laurențiu Nicola wrote:
>> >> >> It's an ASUS RT-N66U running NEWD-2/K3X from r24160.
>> >> > This is a Broadcom based device, so it should behave in the same way as
>> >> > other APs/Routers running the Broadcom drivers.
>> >> > The driver should only send Reason 7 when receiving a PS-Poll, BlockAck,
>> >> > BlockAckReq or Action frame from a station that's not associated, so
>> >> > probably it has already kicked out your iwlwifi client earlier. Not sure
>> >> > why that doesn't show up in the log though.
>> >> >
>> >>
>> >> Whether this might refer to the Station Control Block Timeout value
>> >>
>> >> http://www.dd-wrt.com/wiki/index.php/Wl#scb_timeout
>> >> ...
>> >> scb_timeout
>> >>
>> >> AP only: inactivity timeout value for authenticated stas
>> >>
>>
>> Actually, mac80211 should be probing the AP every 30 seconds but a
>> beacon might abort the probe...
>> Can you try something like this:
>>
>> diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
>> index 75df184..c9db7cf 100644
>> --- a/net/mac80211/mlme.c
>> +++ b/net/mac80211/mlme.c
>> @@ -3295,7 +3295,8 @@ static void ieee80211_rx_mgmt_beacon(struct
>> ieee80211_sub_if_data *sdata,
>> if (ifmgd->flags & IEEE80211_STA_CONNECTION_POLL) {
>> mlme_dbg_ratelimited(sdata,
>> "cancelling AP probe due to a
>> received beacon\n");
>> - ieee80211_reset_ap_probe(sdata);
>> + pr_err("Not cancelling the probe to make sure the AP
>> hears us from time to time\n");
>> + //ieee80211_reset_ap_probe(sdata);
>> }
>>
>> /*
>>
>>
>>
>> >>
>> >> poma
>> >>
>> >>
>> >> --
>> >> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
>> >> in
>> >> the body of a message to [email protected]
>> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
>> in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Oct 20, 2014 at 10:06 AM, Emmanuel Grumbach <[email protected]> wrote:
> On Mon, Oct 20, 2014 at 8:30 AM, Laurențiu Nicola <[email protected]> wrote:
>> Here: https://bpaste.net/show/bf6dc1847ce3
>>
>
> Are you sure you had MAC80211_MLME_DEBUG?
>
>>
Ok - You probably had it - sorry. But apparently the AP is really kicking us...
What AP do you have?
On Thu, Oct 23, 2014 at 10:30 AM, Laurențiu Nicola <[email protected]> wrote:
> I did; the card still gets disconnected and the message doesn't show up
> in dmesg.
>
You had *none* of the many prints I added in the log?
That seems really weird...
> Laurentiu
>
> On Thu, Oct 23, 2014, at 08:21, Emmanuel Grumbach wrote:
>> On Thu, Oct 23, 2014 at 12:53 AM, Laurențiu Nicola <[email protected]>
>> wrote:
>> > Nope. It seems that code doesn't get executed when my issue occurs (or
>> > in my five or ten minutes of uptime). I've seen
>> > `ieee80211_reset_ap_probe` get called by `ieee80211_rx_mgmt_probe_resp`,
>> > but (if I'm not wrong) not on every disconnect.
>> >
>> > And as far as I can tell, force_cam is set to true.
>>
>> Can you please try with the patch attached and send the logs?
>> I again need MAC80211_MLME_DEBUG.
>>
>> Thanks.
>>
>> >
>> > Laurentiu
>> >
>> > On Wed, Oct 22, 2014, at 12:10, Emmanuel Grumbach wrote:
>> >> On Tue, Oct 21, 2014 at 10:56 PM, Laurențiu Nicola <[email protected]>
>> >> wrote:
>> >> > Yep! `scb_timeout` is 60 on my router.
>> >> >
>> >> > On Tue, Oct 21, 2014, at 14:00, poma wrote:
>> >> >> On 21.10.2014 10:35, Felix Fietkau wrote:
>> >> >> > On 2014-10-21 10:23, Laurențiu Nicola wrote:
>> >> >> >> It's an ASUS RT-N66U running NEWD-2/K3X from r24160.
>> >> >> > This is a Broadcom based device, so it should behave in the same way as
>> >> >> > other APs/Routers running the Broadcom drivers.
>> >> >> > The driver should only send Reason 7 when receiving a PS-Poll, BlockAck,
>> >> >> > BlockAckReq or Action frame from a station that's not associated, so
>> >> >> > probably it has already kicked out your iwlwifi client earlier. Not sure
>> >> >> > why that doesn't show up in the log though.
>> >> >> >
>> >> >>
>> >> >> Whether this might refer to the Station Control Block Timeout value
>> >> >>
>> >> >> http://www.dd-wrt.com/wiki/index.php/Wl#scb_timeout
>> >> >> ...
>> >> >> scb_timeout
>> >> >>
>> >> >> AP only: inactivity timeout value for authenticated stas
>> >> >>
>> >>
>> >> Actually, mac80211 should be probing the AP every 30 seconds but a
>> >> beacon might abort the probe...
>> >> Can you try something like this:
>> >>
>> >> diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
>> >> index 75df184..c9db7cf 100644
>> >> --- a/net/mac80211/mlme.c
>> >> +++ b/net/mac80211/mlme.c
>> >> @@ -3295,7 +3295,8 @@ static void ieee80211_rx_mgmt_beacon(struct
>> >> ieee80211_sub_if_data *sdata,
>> >> if (ifmgd->flags & IEEE80211_STA_CONNECTION_POLL) {
>> >> mlme_dbg_ratelimited(sdata,
>> >> "cancelling AP probe due to a
>> >> received beacon\n");
>> >> - ieee80211_reset_ap_probe(sdata);
>> >> + pr_err("Not cancelling the probe to make sure the AP
>> >> hears us from time to time\n");
>> >> + //ieee80211_reset_ap_probe(sdata);
>> >> }
>> >>
>> >> /*
>> >>
>> >>
>> >>
>> >> >>
>> >> >> poma
>> >> >>
>> >> >>
>> >> >> --
>> >> >> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
>> >> >> in
>> >> >> the body of a message to [email protected]
>> >> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> >> --
>> >> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
>> >> in
>> >> the body of a message to [email protected]
>> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
>> in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Oct 23, 2014 at 10:42 PM, Laurențiu Nicola <[email protected]> wrote:
> Doesn't seem to help https://bpaste.net/show/68e1a6b33689.
ok - let me re-add the logs...
>
> Laurentiu
>
> On Thu, Oct 23, 2014, at 22:28, Emmanuel Grumbach wrote:
>> On Thu, Oct 23, 2014 at 8:38 PM, Laurențiu Nicola <[email protected]>
>> wrote:
>> > Okay. I'm running 3.17.1, so the line numbers might not be the ones
>> > you're expecting:
>> >
>> > patching file net/mac80211/mlme.c
>> > Hunk #1 succeeded at 128 (offset -1 lines).
>> > Hunk #2 succeeded at 137 (offset -1 lines).
>> > Hunk #3 succeeded at 1875 (offset -209 lines).
>> > Hunk #4 succeeded at 1886 (offset -207 lines).
>> > Hunk #5 succeeded at 1908 (offset -207 lines).
>> > Hunk #6 succeeded at 1924 (offset -244 lines).
>> >
>> > dmesg output is at https://bpaste.net/show/649277aaada8 .
>>
>> can you please test the patch attached?
>>
>> (remove the previous one first please)
>>
>> >
>> > Laurentiu
>> >
>> > On Thu, Oct 23, 2014, at 19:46, Emmanuel Grumbach wrote:
>> >> On Thu, Oct 23, 2014 at 7:02 PM, Laurențiu Nicola <[email protected]>
>> >> wrote:
>> >> > Sorry, but I only saw a two-line change [1] to
>> >> > `ieee80211_rx_mgmt_beacon` (which already had a log message). Am I
>> >> > missing something?
>> >> >
>> >> > [1] http://www.spinics.net/lists/linux-wireless/msg128340.html
>> >> >
>> >>
>> >> No - you are not. I did miss something...I forgot to attach the patch.
>> >> Here you go.
>> >>
>> >> > Laurentiu
>> >> >
>> >> > On Thu, Oct 23, 2014, at 11:07, Emmanuel Grumbach wrote:
>> >> >> On Thu, Oct 23, 2014 at 10:30 AM, Laurențiu Nicola <[email protected]>
>> >> >> wrote:
>> >> >> > I did; the card still gets disconnected and the message doesn't show up
>> >> >> > in dmesg.
>> >> >> >
>> >> >>
>> >> >> You had *none* of the many prints I added in the log?
>> >> >>
>> >> >> That seems really weird...
>> >> >>
>> >> >> > Laurentiu
>> >> >> >
>> >> >> > On Thu, Oct 23, 2014, at 08:21, Emmanuel Grumbach wrote:
>> >> >> >> On Thu, Oct 23, 2014 at 12:53 AM, Laurențiu Nicola <[email protected]>
>> >> >> >> wrote:
>> >> >> >> > Nope. It seems that code doesn't get executed when my issue occurs (or
>> >> >> >> > in my five or ten minutes of uptime). I've seen
>> >> >> >> > `ieee80211_reset_ap_probe` get called by `ieee80211_rx_mgmt_probe_resp`,
>> >> >> >> > but (if I'm not wrong) not on every disconnect.
>> >> >> >> >
>> >> >> >> > And as far as I can tell, force_cam is set to true.
>> >> >> >>
>> >> >> >> Can you please try with the patch attached and send the logs?
>> >> >> >> I again need MAC80211_MLME_DEBUG.
>> >> >> >>
>> >> >> >> Thanks.
>> >> >> >>
>> >> >> >> >
>> >> >> >> > Laurentiu
>> >> >> >> >
>> >> >> >> > On Wed, Oct 22, 2014, at 12:10, Emmanuel Grumbach wrote:
>> >> >> >> >> On Tue, Oct 21, 2014 at 10:56 PM, Laurențiu Nicola <[email protected]>
>> >> >> >> >> wrote:
>> >> >> >> >> > Yep! `scb_timeout` is 60 on my router.
>> >> >> >> >> >
>> >> >> >> >> > On Tue, Oct 21, 2014, at 14:00, poma wrote:
>> >> >> >> >> >> On 21.10.2014 10:35, Felix Fietkau wrote:
>> >> >> >> >> >> > On 2014-10-21 10:23, Laurențiu Nicola wrote:
>> >> >> >> >> >> >> It's an ASUS RT-N66U running NEWD-2/K3X from r24160.
>> >> >> >> >> >> > This is a Broadcom based device, so it should behave in the same way as
>> >> >> >> >> >> > other APs/Routers running the Broadcom drivers.
>> >> >> >> >> >> > The driver should only send Reason 7 when receiving a PS-Poll, BlockAck,
>> >> >> >> >> >> > BlockAckReq or Action frame from a station that's not associated, so
>> >> >> >> >> >> > probably it has already kicked out your iwlwifi client earlier. Not sure
>> >> >> >> >> >> > why that doesn't show up in the log though.
>> >> >> >> >> >> >
>> >> >> >> >> >>
>> >> >> >> >> >> Whether this might refer to the Station Control Block Timeout value
>> >> >> >> >> >>
>> >> >> >> >> >> http://www.dd-wrt.com/wiki/index.php/Wl#scb_timeout
>> >> >> >> >> >> ...
>> >> >> >> >> >> scb_timeout
>> >> >> >> >> >>
>> >> >> >> >> >> AP only: inactivity timeout value for authenticated stas
>> >> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> Actually, mac80211 should be probing the AP every 30 seconds but a
>> >> >> >> >> beacon might abort the probe...
>> >> >> >> >> Can you try something like this:
>> >> >> >> >>
>> >> >> >> >> diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
>> >> >> >> >> index 75df184..c9db7cf 100644
>> >> >> >> >> --- a/net/mac80211/mlme.c
>> >> >> >> >> +++ b/net/mac80211/mlme.c
>> >> >> >> >> @@ -3295,7 +3295,8 @@ static void ieee80211_rx_mgmt_beacon(struct
>> >> >> >> >> ieee80211_sub_if_data *sdata,
>> >> >> >> >> if (ifmgd->flags & IEEE80211_STA_CONNECTION_POLL) {
>> >> >> >> >> mlme_dbg_ratelimited(sdata,
>> >> >> >> >> "cancelling AP probe due to a
>> >> >> >> >> received beacon\n");
>> >> >> >> >> - ieee80211_reset_ap_probe(sdata);
>> >> >> >> >> + pr_err("Not cancelling the probe to make sure the AP
>> >> >> >> >> hears us from time to time\n");
>> >> >> >> >> + //ieee80211_reset_ap_probe(sdata);
>> >> >> >> >> }
>> >> >> >> >>
>> >> >> >> >> /*
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >> >> >> poma
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >> >> >> --
>> >> >> >> >> >> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
>> >> >> >> >> >> in
>> >> >> >> >> >> the body of a message to [email protected]
>> >> >> >> >> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> >> >> >> >> --
>> >> >> >> >> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
>> >> >> >> >> in
>> >> >> >> >> the body of a message to [email protected]
>> >> >> >> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> >> >> >> --
>> >> >> >> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
>> >> >> >> in
>> >> >> >> the body of a message to [email protected]
>> >> >> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> >> >> --
>> >> >> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
>> >> >> in
>> >> >> the body of a message to [email protected]
>> >> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> >> Email had 1 attachment:
>> >> + PROBE.patch
>> >> 3k (application/octet-stream)
>> Email had 1 attachment:
>> + a.patch
>> 3k (application/octet-stream)
On Tue, Oct 21, 2014 at 12:34 PM, Emmanuel Grumbach <[email protected]> wrote:
> On Tue, Oct 21, 2014 at 9:37 AM, Krishna Chaitanya
> <[email protected]> wrote:
>> On Tue, Oct 21, 2014 at 12:06 PM, Krishna Chaitanya
>> <[email protected]> wrote:
>>> On Tue, Oct 21, 2014 at 11:01 AM, Emmanuel Grumbach <[email protected]> wrote:
>>>> On Tue, Oct 21, 2014 at 8:02 AM, Emmanuel Grumbach <[email protected]> wrote:
>>>>> On Mon, Oct 20, 2014 at 10:29 PM, Laurențiu Nicola <[email protected]> wrote:
>>>>>> No, nothing in the DD-WRT syslog. The IP seems to be the one cached by
>>>>>> my DHCP client. I also tried various suggestions found on the internet,
>>>>>> but nothing helped.
>>>>>>
>>>>>
>>>>> Can you please try to have another device in monitor mode to sniff the
>>>>> traffic going on?
>>>>> Felix, can you please tell me when DD-WRT can send a deauth with reason code 7?
>>>>>
>>>>> thanks.
>>>>
>>>> Can you please disable power save?
>>>> For this, please make sure you have
>>>> https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/iwlwifi-fixes.git/commit/?id=f8dfc607b2b460e8e8adfdfb3c5f5bba3a4ad01b
>>>> or at least have the module parameter.
>>>> I am wondering if the firmware is not sending frames because of power
>>>> save toggling.
>>>>
>>>> I you could get more extensive logs from the AP it'd be great.
>>>> Running tracing on the AP would let us know why it thinks we are not associated.
>>>>
>>> I have faced the same issue before it happens when DUT is in powersave
>>> and for some reason AP authenticates (in this case probably due to
>> *typo: deuauthenticates.
>>
>>> inactivity) but as DUT is in power save we don't Rx the deauth (some
>>> AP's don't wait
>>> for STA to wakeup and retrieve the deauth frame).
>>>
>>> So after that if DUT tries to sent any data frame, as it still thinks
>>> that it is connected
>>> (network lost also will not trigger because it still Rx beacon) and in
>>> that case AP deauthenticates
>>> us by Reason:7.
>>>
>>> May be if we enable tx status report ACK we can pass the inactivity
>>> check as some AP's
>>> wont reset inactivity timer for probe's.
>
> That seems unlikely - we are kicked out after 1 minute?
> Let's check, Laurentiu - can you please ping in the background and see
> what happens?
Yeah, but some Ap's do that :-)
Quote from Laurentiu:
"What I found out in the meanwhile, however, is that active traffic will
prevent the issue from occurring. This happened with the Fedora Live CD,
but pinging the AP is also sufficient. I noticed iwconfig reports that
the power saving mode is off."
So when traffic is there the issue doesn't happen, so it points to inactivity.
On Thu, Oct 23, 2014 at 11:27 PM, Laurențiu Nicola <[email protected]> wrote:
> https://bpaste.net/show/8a0e5c68762f
>
> On Thu, Oct 23, 2014, at 23:16, Emmanuel Grumbach wrote:
>> > https://bpaste.net/show/5cc48256d952
>> >
>> > On Thu, Oct 23, 2014, at 22:55, Emmanuel Grumbach wrote:
>> >> On Thu, Oct 23, 2014 at 10:42 PM, Laurențiu Nicola <[email protected]>
>> >> wrote:
>> >>> Doesn't seem to help https://bpaste.net/show/68e1a6b33689.
>> >>
>> >> ok - let me re-add the logs...
>> >>
>> >>
>>
>> This makes no sense to me.
>> We do talk to the AP since we get frames Acked...
This again makes no sense to me.
Time to go to bed I guess.
>>
>> Can you please apply this on top of what you have?
>>
>> diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
>> index 2de8870..f3b1e62 100644
>> --- a/net/mac80211/mlme.c
>> +++ b/net/mac80211/mlme.c
>> @@ -1991,15 +1991,16 @@ void ieee80211_sta_tx_notify(struct
>> ieee80211_sub_if_data *sdata,
>> if (ieee80211_is_nullfunc(hdr->frame_control) &&
>> sdata->u.mgd.probe_send_count > 0) {
>> if (ack)
>> - ieee80211_sta_reset_conn_monitor(sdata);
>> + // ieee80211_sta_reset_conn_monitor(sdata);
>> + ;
>> else
>> sdata->u.mgd.nullfunc_failed = true;
>> ieee80211_queue_work(&sdata->local->hw, &sdata->work);
>> return;
>> }
>>
>> - if (ack)
>> - ieee80211_sta_reset_conn_monitor(sdata);
>> +// if (ack)
>> +// ieee80211_sta_reset_conn_monitor(sdata);
>> }
>>
>> static void ieee80211_mgd_probe_ap_send(struct ieee80211_sub_if_data
>> *sdata)
>>
>>
>> Thanks.
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
>> in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
No, nothing in the DD-WRT syslog. The IP seems to be the one cached by
my DHCP client. I also tried various suggestions found on the internet,
but nothing helped.
Laurentiu
On Mon, Oct 20, 2014, at 11:23, Emmanuel Grumbach wrote:
> On Mon, Oct 20, 2014 at 10:22 AM, Laurențiu Nicola <[email protected]>
> wrote:
> > One thing that might be relevant is that, although there is a static
> > DHCP lease configured (which works on Windows), the router/AP is giving
> > the laptop a different IP address. The reported MACs are the same, of
> > course. I don't know whether wpa_supplicant remembers and requests the
> > last IP it had, but the lease was already present when I configured it.
> >
> > The router runs DD-WRT and I don't have problems on Windows or Android.
> >
>
> I guess you can try to get some logs from the DD-WRT - but if the AP
> doesn't
> give the same address to Linux as in Windows - there is something
> fishy...
>
> > Laurentiu
> >
> > On Mon, Oct 20, 2014, at 10:12, Emmanuel Grumbach wrote:
> >> On Mon, Oct 20, 2014 at 10:06 AM, Emmanuel Grumbach <[email protected]>
> >> wrote:
> >> > On Mon, Oct 20, 2014 at 8:30 AM, Laurențiu Nicola <[email protected]> wrote:
> >> >> Here: https://bpaste.net/show/bf6dc1847ce3
> >> >>
> >> >
> >> > Are you sure you had MAC80211_MLME_DEBUG?
> >> >
> >> >>
> >> Ok - You probably had it - sorry. But apparently the AP is really kicking
> >> us...
> >> What AP do you have?
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
> >> in
> >> the body of a message to [email protected]
> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
> in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Oct 20, 2014 at 10:29 PM, Laurențiu Nicola <[email protected]> wrote:
> No, nothing in the DD-WRT syslog. The IP seems to be the one cached by
> my DHCP client. I also tried various suggestions found on the internet,
> but nothing helped.
>
Can you please try to have another device in monitor mode to sniff the
traffic going on?
Felix, can you please tell me when DD-WRT can send a deauth with reason code 7?
thanks.
> Laurentiu
>
> On Mon, Oct 20, 2014, at 11:23, Emmanuel Grumbach wrote:
>> On Mon, Oct 20, 2014 at 10:22 AM, Laurențiu Nicola <[email protected]>
>> wrote:
>> > One thing that might be relevant is that, although there is a static
>> > DHCP lease configured (which works on Windows), the router/AP is giving
>> > the laptop a different IP address. The reported MACs are the same, of
>> > course. I don't know whether wpa_supplicant remembers and requests the
>> > last IP it had, but the lease was already present when I configured it.
>> >
>> > The router runs DD-WRT and I don't have problems on Windows or Android.
>> >
>>
>> I guess you can try to get some logs from the DD-WRT - but if the AP
>> doesn't
>> give the same address to Linux as in Windows - there is something
>> fishy...
>>
>> > Laurentiu
>> >
>> > On Mon, Oct 20, 2014, at 10:12, Emmanuel Grumbach wrote:
>> >> On Mon, Oct 20, 2014 at 10:06 AM, Emmanuel Grumbach <[email protected]>
>> >> wrote:
>> >> > On Mon, Oct 20, 2014 at 8:30 AM, Laurențiu Nicola <[email protected]> wrote:
>> >> >> Here: https://bpaste.net/show/bf6dc1847ce3
>> >> >>
>> >> >
>> >> > Are you sure you had MAC80211_MLME_DEBUG?
>> >> >
>> >> >>
>> >> Ok - You probably had it - sorry. But apparently the AP is really kicking
>> >> us...
>> >> What AP do you have?
>> >> --
>> >> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
>> >> in
>> >> the body of a message to [email protected]
>> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
>> in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Oct 21, 2014 at 12:05 PM, Krishna Chaitanya
<[email protected]> wrote:
> On Tue, Oct 21, 2014 at 2:05 PM, Felix Fietkau <[email protected]> wrote:
>> On 2014-10-21 10:23, Laurențiu Nicola wrote:
>>> It's an ASUS RT-N66U running NEWD-2/K3X from r24160.
>> This is a Broadcom based device, so it should behave in the same way as
>> other APs/Routers running the Broadcom drivers.
>> The driver should only send Reason 7 when receiving a PS-Poll, BlockAck,
>> BlockAckReq or Action frame from a station that's not associated, so
>> probably it has already kicked out your iwlwifi client earlier. Not sure
>> why that doesn't show up in the log though.
>>
> May be iwlwifi is dozing and did not Rx that frame?
yep - this is most probably what happens. iwlwifi goes to sleep and it
get a deauth that it doesn't hear. Then it wakes up with an NDP and
gets kicked out.
But shouldn't the deauth be buffered and indicated through the TIM IE?
On Thu, 2014-10-16 at 15:48 +0300, Laurențiu Nicola wrote:
> Hello,
>
> I'm using iwlwifi for a Centrino Ultimate-N 6300 on 3.14.4 and 3.17.1.
> Connect to my wireless network works, but I get disconnected every 60
> seconds or so. The dmesg output looks like
> https://bpaste.net/show/1623a8ae5dc6 .
>
> I had the same issue on the three latest firmware versions:
> iwlwifi-6000-ucode-9.176.4.1
> iwlwifi-6000-ucode-9.193.4.1
> iwlwifi-6000-ucode-9.221.4.1
>
> The dmesg log actually shows the driver loading the different versions
> above.
>
> It's the first time I try to use wireless on Linux, so I might have made
> a dumb mistake.
Can you try to get debug output from wpa_supplicant, which is the
process that controls WiFi on Linux? What distro and version do you
use, and do you know what WiFi management service is being used?
(NetworkManager, conman, plain wpa_supplicant, wicd, something else?)
Dan
On Tue, Oct 21, 2014 at 11:37 AM, Laurențiu Nicola <[email protected]> wrote:
> Perhaps I'm not looking at the right log :). Do you mean enabling syslog
> and /tmp/var/log/messages?
>
> Laurentiu
>
> On Tue, Oct 21, 2014, at 11:35, Felix Fietkau wrote:
>> On 2014-10-21 10:23, Laurențiu Nicola wrote:
>> > It's an ASUS RT-N66U running NEWD-2/K3X from r24160.
>> This is a Broadcom based device, so it should behave in the same way as
>> other APs/Routers running the Broadcom drivers.
>> The driver should only send Reason 7 when receiving a PS-Poll, BlockAck,
>> BlockAckReq or Action frame from a station that's not associated, so
>> probably it has already kicked out your iwlwifi client earlier. Not sure
>> why that doesn't show up in the log though.
>>
Note that it kicks iwlwifi after 1 minute - this seems short?
>> - Felix
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
>> in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
https://bpaste.net/show/8a0e5c68762f
On Thu, Oct 23, 2014, at 23:16, Emmanuel Grumbach wrote:
> > https://bpaste.net/show/5cc48256d952
> >
> > On Thu, Oct 23, 2014, at 22:55, Emmanuel Grumbach wrote:
> >> On Thu, Oct 23, 2014 at 10:42 PM, Laurențiu Nicola <[email protected]>
> >> wrote:
> >>> Doesn't seem to help https://bpaste.net/show/68e1a6b33689.
> >>
> >> ok - let me re-add the logs...
> >>
> >>
>
> This makes no sense to me.
> We do talk to the AP since we get frames Acked...
>
> Can you please apply this on top of what you have?
>
> diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
> index 2de8870..f3b1e62 100644
> --- a/net/mac80211/mlme.c
> +++ b/net/mac80211/mlme.c
> @@ -1991,15 +1991,16 @@ void ieee80211_sta_tx_notify(struct
> ieee80211_sub_if_data *sdata,
> if (ieee80211_is_nullfunc(hdr->frame_control) &&
> sdata->u.mgd.probe_send_count > 0) {
> if (ack)
> - ieee80211_sta_reset_conn_monitor(sdata);
> + // ieee80211_sta_reset_conn_monitor(sdata);
> + ;
> else
> sdata->u.mgd.nullfunc_failed = true;
> ieee80211_queue_work(&sdata->local->hw, &sdata->work);
> return;
> }
>
> - if (ack)
> - ieee80211_sta_reset_conn_monitor(sdata);
> +// if (ack)
> +// ieee80211_sta_reset_conn_monitor(sdata);
> }
>
> static void ieee80211_mgd_probe_ap_send(struct ieee80211_sub_if_data
> *sdata)
>
>
> Thanks.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
> in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Could this still happen if power saving is disabled?
Laurentiu
On Tue, Oct 21, 2014, at 10:22, Krishna Chaitanya wrote:
> On Tue, Oct 21, 2014 at 12:34 PM, Emmanuel Grumbach <[email protected]>
> wrote:
> > On Tue, Oct 21, 2014 at 9:37 AM, Krishna Chaitanya
> > <[email protected]> wrote:
> >> On Tue, Oct 21, 2014 at 12:06 PM, Krishna Chaitanya
> >> <[email protected]> wrote:
> >>> On Tue, Oct 21, 2014 at 11:01 AM, Emmanuel Grumbach <[email protected]> wrote:
> >>>> On Tue, Oct 21, 2014 at 8:02 AM, Emmanuel Grumbach <[email protected]> wrote:
> >>>>> On Mon, Oct 20, 2014 at 10:29 PM, Laurențiu Nicola <[email protected]> wrote:
> >>>>>> No, nothing in the DD-WRT syslog. The IP seems to be the one cached by
> >>>>>> my DHCP client. I also tried various suggestions found on the internet,
> >>>>>> but nothing helped.
> >>>>>>
> >>>>>
> >>>>> Can you please try to have another device in monitor mode to sniff the
> >>>>> traffic going on?
> >>>>> Felix, can you please tell me when DD-WRT can send a deauth with reason code 7?
> >>>>>
> >>>>> thanks.
> >>>>
> >>>> Can you please disable power save?
> >>>> For this, please make sure you have
> >>>> https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/iwlwifi-fixes.git/commit/?id=f8dfc607b2b460e8e8adfdfb3c5f5bba3a4ad01b
> >>>> or at least have the module parameter.
> >>>> I am wondering if the firmware is not sending frames because of power
> >>>> save toggling.
> >>>>
> >>>> I you could get more extensive logs from the AP it'd be great.
> >>>> Running tracing on the AP would let us know why it thinks we are not associated.
> >>>>
> >>> I have faced the same issue before it happens when DUT is in powersave
> >>> and for some reason AP authenticates (in this case probably due to
> >> *typo: deuauthenticates.
> >>
> >>> inactivity) but as DUT is in power save we don't Rx the deauth (some
> >>> AP's don't wait
> >>> for STA to wakeup and retrieve the deauth frame).
> >>>
> >>> So after that if DUT tries to sent any data frame, as it still thinks
> >>> that it is connected
> >>> (network lost also will not trigger because it still Rx beacon) and in
> >>> that case AP deauthenticates
> >>> us by Reason:7.
> >>>
> >>> May be if we enable tx status report ACK we can pass the inactivity
> >>> check as some AP's
> >>> wont reset inactivity timer for probe's.
> >
> > That seems unlikely - we are kicked out after 1 minute?
> > Let's check, Laurentiu - can you please ping in the background and see
> > what happens?
>
> Yeah, but some Ap's do that :-)
> Quote from Laurentiu:
>
> "What I found out in the meanwhile, however, is that active traffic will
> prevent the issue from occurring. This happened with the Fedora Live CD,
> but pinging the AP is also sufficient. I noticed iwconfig reports that
> the power saving mode is off."
>
> So when traffic is there the issue doesn't happen, so it points to
> inactivity.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
> in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Oct 21, 2014 at 8:02 AM, Emmanuel Grumbach <[email protected]> wrote:
> On Mon, Oct 20, 2014 at 10:29 PM, Laurențiu Nicola <[email protected]> wrote:
>> No, nothing in the DD-WRT syslog. The IP seems to be the one cached by
>> my DHCP client. I also tried various suggestions found on the internet,
>> but nothing helped.
>>
>
> Can you please try to have another device in monitor mode to sniff the
> traffic going on?
> Felix, can you please tell me when DD-WRT can send a deauth with reason code 7?
>
> thanks.
Can you please disable power save?
For this, please make sure you have
https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/iwlwifi-fixes.git/commit/?id=f8dfc607b2b460e8e8adfdfb3c5f5bba3a4ad01b
or at least have the module parameter.
I am wondering if the firmware is not sending frames because of power
save toggling.
I you could get more extensive logs from the AP it'd be great.
Running tracing on the AP would let us know why it thinks we are not associated.
>
>> Laurentiu
>>
>> On Mon, Oct 20, 2014, at 11:23, Emmanuel Grumbach wrote:
>>> On Mon, Oct 20, 2014 at 10:22 AM, Laurențiu Nicola <[email protected]>
>>> wrote:
>>> > One thing that might be relevant is that, although there is a static
>>> > DHCP lease configured (which works on Windows), the router/AP is giving
>>> > the laptop a different IP address. The reported MACs are the same, of
>>> > course. I don't know whether wpa_supplicant remembers and requests the
>>> > last IP it had, but the lease was already present when I configured it.
>>> >
>>> > The router runs DD-WRT and I don't have problems on Windows or Android.
>>> >
>>>
>>> I guess you can try to get some logs from the DD-WRT - but if the AP
>>> doesn't
>>> give the same address to Linux as in Windows - there is something
>>> fishy...
>>>
>>> > Laurentiu
>>> >
>>> > On Mon, Oct 20, 2014, at 10:12, Emmanuel Grumbach wrote:
>>> >> On Mon, Oct 20, 2014 at 10:06 AM, Emmanuel Grumbach <[email protected]>
>>> >> wrote:
>>> >> > On Mon, Oct 20, 2014 at 8:30 AM, Laurențiu Nicola <[email protected]> wrote:
>>> >> >> Here: https://bpaste.net/show/bf6dc1847ce3
>>> >> >>
>>> >> >
>>> >> > Are you sure you had MAC80211_MLME_DEBUG?
>>> >> >
>>> >> >>
>>> >> Ok - You probably had it - sorry. But apparently the AP is really kicking
>>> >> us...
>>> >> What AP do you have?
>>> >> --
>>> >> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
>>> >> in
>>> >> the body of a message to [email protected]
>>> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
>>> in
>>> the body of a message to [email protected]
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Oct 20, 2014 at 10:22 AM, Laurențiu Nicola <[email protected]> wrote:
> One thing that might be relevant is that, although there is a static
> DHCP lease configured (which works on Windows), the router/AP is giving
> the laptop a different IP address. The reported MACs are the same, of
> course. I don't know whether wpa_supplicant remembers and requests the
> last IP it had, but the lease was already present when I configured it.
>
> The router runs DD-WRT and I don't have problems on Windows or Android.
>
I guess you can try to get some logs from the DD-WRT - but if the AP doesn't
give the same address to Linux as in Windows - there is something fishy...
> Laurentiu
>
> On Mon, Oct 20, 2014, at 10:12, Emmanuel Grumbach wrote:
>> On Mon, Oct 20, 2014 at 10:06 AM, Emmanuel Grumbach <[email protected]>
>> wrote:
>> > On Mon, Oct 20, 2014 at 8:30 AM, Laurențiu Nicola <[email protected]> wrote:
>> >> Here: https://bpaste.net/show/bf6dc1847ce3
>> >>
>> >
>> > Are you sure you had MAC80211_MLME_DEBUG?
>> >
>> >>
>> Ok - You probably had it - sorry. But apparently the AP is really kicking
>> us...
>> What AP do you have?
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
>> in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Oct 23, 2014 at 8:38 PM, Laurențiu Nicola <[email protected]> wrote:
> Okay. I'm running 3.17.1, so the line numbers might not be the ones
> you're expecting:
>
> patching file net/mac80211/mlme.c
> Hunk #1 succeeded at 128 (offset -1 lines).
> Hunk #2 succeeded at 137 (offset -1 lines).
> Hunk #3 succeeded at 1875 (offset -209 lines).
> Hunk #4 succeeded at 1886 (offset -207 lines).
> Hunk #5 succeeded at 1908 (offset -207 lines).
> Hunk #6 succeeded at 1924 (offset -244 lines).
>
> dmesg output is at https://bpaste.net/show/649277aaada8 .
can you please test the patch attached?
(remove the previous one first please)
>
> Laurentiu
>
> On Thu, Oct 23, 2014, at 19:46, Emmanuel Grumbach wrote:
>> On Thu, Oct 23, 2014 at 7:02 PM, Laurențiu Nicola <[email protected]>
>> wrote:
>> > Sorry, but I only saw a two-line change [1] to
>> > `ieee80211_rx_mgmt_beacon` (which already had a log message). Am I
>> > missing something?
>> >
>> > [1] http://www.spinics.net/lists/linux-wireless/msg128340.html
>> >
>>
>> No - you are not. I did miss something...I forgot to attach the patch.
>> Here you go.
>>
>> > Laurentiu
>> >
>> > On Thu, Oct 23, 2014, at 11:07, Emmanuel Grumbach wrote:
>> >> On Thu, Oct 23, 2014 at 10:30 AM, Laurențiu Nicola <[email protected]>
>> >> wrote:
>> >> > I did; the card still gets disconnected and the message doesn't show up
>> >> > in dmesg.
>> >> >
>> >>
>> >> You had *none* of the many prints I added in the log?
>> >>
>> >> That seems really weird...
>> >>
>> >> > Laurentiu
>> >> >
>> >> > On Thu, Oct 23, 2014, at 08:21, Emmanuel Grumbach wrote:
>> >> >> On Thu, Oct 23, 2014 at 12:53 AM, Laurențiu Nicola <[email protected]>
>> >> >> wrote:
>> >> >> > Nope. It seems that code doesn't get executed when my issue occurs (or
>> >> >> > in my five or ten minutes of uptime). I've seen
>> >> >> > `ieee80211_reset_ap_probe` get called by `ieee80211_rx_mgmt_probe_resp`,
>> >> >> > but (if I'm not wrong) not on every disconnect.
>> >> >> >
>> >> >> > And as far as I can tell, force_cam is set to true.
>> >> >>
>> >> >> Can you please try with the patch attached and send the logs?
>> >> >> I again need MAC80211_MLME_DEBUG.
>> >> >>
>> >> >> Thanks.
>> >> >>
>> >> >> >
>> >> >> > Laurentiu
>> >> >> >
>> >> >> > On Wed, Oct 22, 2014, at 12:10, Emmanuel Grumbach wrote:
>> >> >> >> On Tue, Oct 21, 2014 at 10:56 PM, Laurențiu Nicola <[email protected]>
>> >> >> >> wrote:
>> >> >> >> > Yep! `scb_timeout` is 60 on my router.
>> >> >> >> >
>> >> >> >> > On Tue, Oct 21, 2014, at 14:00, poma wrote:
>> >> >> >> >> On 21.10.2014 10:35, Felix Fietkau wrote:
>> >> >> >> >> > On 2014-10-21 10:23, Laurențiu Nicola wrote:
>> >> >> >> >> >> It's an ASUS RT-N66U running NEWD-2/K3X from r24160.
>> >> >> >> >> > This is a Broadcom based device, so it should behave in the same way as
>> >> >> >> >> > other APs/Routers running the Broadcom drivers.
>> >> >> >> >> > The driver should only send Reason 7 when receiving a PS-Poll, BlockAck,
>> >> >> >> >> > BlockAckReq or Action frame from a station that's not associated, so
>> >> >> >> >> > probably it has already kicked out your iwlwifi client earlier. Not sure
>> >> >> >> >> > why that doesn't show up in the log though.
>> >> >> >> >> >
>> >> >> >> >>
>> >> >> >> >> Whether this might refer to the Station Control Block Timeout value
>> >> >> >> >>
>> >> >> >> >> http://www.dd-wrt.com/wiki/index.php/Wl#scb_timeout
>> >> >> >> >> ...
>> >> >> >> >> scb_timeout
>> >> >> >> >>
>> >> >> >> >> AP only: inactivity timeout value for authenticated stas
>> >> >> >> >>
>> >> >> >>
>> >> >> >> Actually, mac80211 should be probing the AP every 30 seconds but a
>> >> >> >> beacon might abort the probe...
>> >> >> >> Can you try something like this:
>> >> >> >>
>> >> >> >> diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
>> >> >> >> index 75df184..c9db7cf 100644
>> >> >> >> --- a/net/mac80211/mlme.c
>> >> >> >> +++ b/net/mac80211/mlme.c
>> >> >> >> @@ -3295,7 +3295,8 @@ static void ieee80211_rx_mgmt_beacon(struct
>> >> >> >> ieee80211_sub_if_data *sdata,
>> >> >> >> if (ifmgd->flags & IEEE80211_STA_CONNECTION_POLL) {
>> >> >> >> mlme_dbg_ratelimited(sdata,
>> >> >> >> "cancelling AP probe due to a
>> >> >> >> received beacon\n");
>> >> >> >> - ieee80211_reset_ap_probe(sdata);
>> >> >> >> + pr_err("Not cancelling the probe to make sure the AP
>> >> >> >> hears us from time to time\n");
>> >> >> >> + //ieee80211_reset_ap_probe(sdata);
>> >> >> >> }
>> >> >> >>
>> >> >> >> /*
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> >>
>> >> >> >> >> poma
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> --
>> >> >> >> >> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
>> >> >> >> >> in
>> >> >> >> >> the body of a message to [email protected]
>> >> >> >> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> >> >> >> --
>> >> >> >> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
>> >> >> >> in
>> >> >> >> the body of a message to [email protected]
>> >> >> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> >> >> --
>> >> >> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
>> >> >> in
>> >> >> the body of a message to [email protected]
>> >> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> >> --
>> >> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
>> >> in
>> >> the body of a message to [email protected]
>> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Email had 1 attachment:
>> + PROBE.patch
>> 3k (application/octet-stream)
On Tue, Oct 21, 2014 at 9:37 AM, Krishna Chaitanya
<[email protected]> wrote:
> On Tue, Oct 21, 2014 at 12:06 PM, Krishna Chaitanya
> <[email protected]> wrote:
>> On Tue, Oct 21, 2014 at 11:01 AM, Emmanuel Grumbach <[email protected]> wrote:
>>> On Tue, Oct 21, 2014 at 8:02 AM, Emmanuel Grumbach <[email protected]> wrote:
>>>> On Mon, Oct 20, 2014 at 10:29 PM, Laurențiu Nicola <[email protected]> wrote:
>>>>> No, nothing in the DD-WRT syslog. The IP seems to be the one cached by
>>>>> my DHCP client. I also tried various suggestions found on the internet,
>>>>> but nothing helped.
>>>>>
>>>>
>>>> Can you please try to have another device in monitor mode to sniff the
>>>> traffic going on?
>>>> Felix, can you please tell me when DD-WRT can send a deauth with reason code 7?
>>>>
>>>> thanks.
>>>
>>> Can you please disable power save?
>>> For this, please make sure you have
>>> https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/iwlwifi-fixes.git/commit/?id=f8dfc607b2b460e8e8adfdfb3c5f5bba3a4ad01b
>>> or at least have the module parameter.
>>> I am wondering if the firmware is not sending frames because of power
>>> save toggling.
>>>
>>> I you could get more extensive logs from the AP it'd be great.
>>> Running tracing on the AP would let us know why it thinks we are not associated.
>>>
>> I have faced the same issue before it happens when DUT is in powersave
>> and for some reason AP authenticates (in this case probably due to
> *typo: deuauthenticates.
>
>> inactivity) but as DUT is in power save we don't Rx the deauth (some
>> AP's don't wait
>> for STA to wakeup and retrieve the deauth frame).
>>
>> So after that if DUT tries to sent any data frame, as it still thinks
>> that it is connected
>> (network lost also will not trigger because it still Rx beacon) and in
>> that case AP deauthenticates
>> us by Reason:7.
>>
>> May be if we enable tx status report ACK we can pass the inactivity
>> check as some AP's
>> wont reset inactivity timer for probe's.
That seems unlikely - we are kicked out after 1 minute?
Let's check, Laurentiu - can you please ping in the background and see
what happens?
Sorry, but I only saw a two-line change [1] to
`ieee80211_rx_mgmt_beacon` (which already had a log message). Am I
missing something?
[1] http://www.spinics.net/lists/linux-wireless/msg128340.html
Laurentiu
On Thu, Oct 23, 2014, at 11:07, Emmanuel Grumbach wrote:
> On Thu, Oct 23, 2014 at 10:30 AM, Laurențiu Nicola <[email protected]>
> wrote:
> > I did; the card still gets disconnected and the message doesn't show up
> > in dmesg.
> >
>
> You had *none* of the many prints I added in the log?
>
> That seems really weird...
>
> > Laurentiu
> >
> > On Thu, Oct 23, 2014, at 08:21, Emmanuel Grumbach wrote:
> >> On Thu, Oct 23, 2014 at 12:53 AM, Laurențiu Nicola <[email protected]>
> >> wrote:
> >> > Nope. It seems that code doesn't get executed when my issue occurs (or
> >> > in my five or ten minutes of uptime). I've seen
> >> > `ieee80211_reset_ap_probe` get called by `ieee80211_rx_mgmt_probe_resp`,
> >> > but (if I'm not wrong) not on every disconnect.
> >> >
> >> > And as far as I can tell, force_cam is set to true.
> >>
> >> Can you please try with the patch attached and send the logs?
> >> I again need MAC80211_MLME_DEBUG.
> >>
> >> Thanks.
> >>
> >> >
> >> > Laurentiu
> >> >
> >> > On Wed, Oct 22, 2014, at 12:10, Emmanuel Grumbach wrote:
> >> >> On Tue, Oct 21, 2014 at 10:56 PM, Laurențiu Nicola <[email protected]>
> >> >> wrote:
> >> >> > Yep! `scb_timeout` is 60 on my router.
> >> >> >
> >> >> > On Tue, Oct 21, 2014, at 14:00, poma wrote:
> >> >> >> On 21.10.2014 10:35, Felix Fietkau wrote:
> >> >> >> > On 2014-10-21 10:23, Laurențiu Nicola wrote:
> >> >> >> >> It's an ASUS RT-N66U running NEWD-2/K3X from r24160.
> >> >> >> > This is a Broadcom based device, so it should behave in the same way as
> >> >> >> > other APs/Routers running the Broadcom drivers.
> >> >> >> > The driver should only send Reason 7 when receiving a PS-Poll, BlockAck,
> >> >> >> > BlockAckReq or Action frame from a station that's not associated, so
> >> >> >> > probably it has already kicked out your iwlwifi client earlier. Not sure
> >> >> >> > why that doesn't show up in the log though.
> >> >> >> >
> >> >> >>
> >> >> >> Whether this might refer to the Station Control Block Timeout value
> >> >> >>
> >> >> >> http://www.dd-wrt.com/wiki/index.php/Wl#scb_timeout
> >> >> >> ...
> >> >> >> scb_timeout
> >> >> >>
> >> >> >> AP only: inactivity timeout value for authenticated stas
> >> >> >>
> >> >>
> >> >> Actually, mac80211 should be probing the AP every 30 seconds but a
> >> >> beacon might abort the probe...
> >> >> Can you try something like this:
> >> >>
> >> >> diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
> >> >> index 75df184..c9db7cf 100644
> >> >> --- a/net/mac80211/mlme.c
> >> >> +++ b/net/mac80211/mlme.c
> >> >> @@ -3295,7 +3295,8 @@ static void ieee80211_rx_mgmt_beacon(struct
> >> >> ieee80211_sub_if_data *sdata,
> >> >> if (ifmgd->flags & IEEE80211_STA_CONNECTION_POLL) {
> >> >> mlme_dbg_ratelimited(sdata,
> >> >> "cancelling AP probe due to a
> >> >> received beacon\n");
> >> >> - ieee80211_reset_ap_probe(sdata);
> >> >> + pr_err("Not cancelling the probe to make sure the AP
> >> >> hears us from time to time\n");
> >> >> + //ieee80211_reset_ap_probe(sdata);
> >> >> }
> >> >>
> >> >> /*
> >> >>
> >> >>
> >> >>
> >> >> >>
> >> >> >> poma
> >> >> >>
> >> >> >>
> >> >> >> --
> >> >> >> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
> >> >> >> in
> >> >> >> the body of a message to [email protected]
> >> >> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >> >> --
> >> >> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
> >> >> in
> >> >> the body of a message to [email protected]
> >> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
> >> in
> >> the body of a message to [email protected]
> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
> in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
I did; the card still gets disconnected and the message doesn't show up
in dmesg.
Laurentiu
On Thu, Oct 23, 2014, at 08:21, Emmanuel Grumbach wrote:
> On Thu, Oct 23, 2014 at 12:53 AM, Laurențiu Nicola <[email protected]>
> wrote:
> > Nope. It seems that code doesn't get executed when my issue occurs (or
> > in my five or ten minutes of uptime). I've seen
> > `ieee80211_reset_ap_probe` get called by `ieee80211_rx_mgmt_probe_resp`,
> > but (if I'm not wrong) not on every disconnect.
> >
> > And as far as I can tell, force_cam is set to true.
>
> Can you please try with the patch attached and send the logs?
> I again need MAC80211_MLME_DEBUG.
>
> Thanks.
>
> >
> > Laurentiu
> >
> > On Wed, Oct 22, 2014, at 12:10, Emmanuel Grumbach wrote:
> >> On Tue, Oct 21, 2014 at 10:56 PM, Laurențiu Nicola <[email protected]>
> >> wrote:
> >> > Yep! `scb_timeout` is 60 on my router.
> >> >
> >> > On Tue, Oct 21, 2014, at 14:00, poma wrote:
> >> >> On 21.10.2014 10:35, Felix Fietkau wrote:
> >> >> > On 2014-10-21 10:23, Laurențiu Nicola wrote:
> >> >> >> It's an ASUS RT-N66U running NEWD-2/K3X from r24160.
> >> >> > This is a Broadcom based device, so it should behave in the same way as
> >> >> > other APs/Routers running the Broadcom drivers.
> >> >> > The driver should only send Reason 7 when receiving a PS-Poll, BlockAck,
> >> >> > BlockAckReq or Action frame from a station that's not associated, so
> >> >> > probably it has already kicked out your iwlwifi client earlier. Not sure
> >> >> > why that doesn't show up in the log though.
> >> >> >
> >> >>
> >> >> Whether this might refer to the Station Control Block Timeout value
> >> >>
> >> >> http://www.dd-wrt.com/wiki/index.php/Wl#scb_timeout
> >> >> ...
> >> >> scb_timeout
> >> >>
> >> >> AP only: inactivity timeout value for authenticated stas
> >> >>
> >>
> >> Actually, mac80211 should be probing the AP every 30 seconds but a
> >> beacon might abort the probe...
> >> Can you try something like this:
> >>
> >> diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
> >> index 75df184..c9db7cf 100644
> >> --- a/net/mac80211/mlme.c
> >> +++ b/net/mac80211/mlme.c
> >> @@ -3295,7 +3295,8 @@ static void ieee80211_rx_mgmt_beacon(struct
> >> ieee80211_sub_if_data *sdata,
> >> if (ifmgd->flags & IEEE80211_STA_CONNECTION_POLL) {
> >> mlme_dbg_ratelimited(sdata,
> >> "cancelling AP probe due to a
> >> received beacon\n");
> >> - ieee80211_reset_ap_probe(sdata);
> >> + pr_err("Not cancelling the probe to make sure the AP
> >> hears us from time to time\n");
> >> + //ieee80211_reset_ap_probe(sdata);
> >> }
> >>
> >> /*
> >>
> >>
> >>
> >> >>
> >> >> poma
> >> >>
> >> >>
> >> >> --
> >> >> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
> >> >> in
> >> >> the body of a message to [email protected]
> >> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
> >> in
> >> the body of a message to [email protected]
> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
> in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Oct 21, 2014 at 11:01 AM, Emmanuel Grumbach <[email protected]> wrote:
> On Tue, Oct 21, 2014 at 8:02 AM, Emmanuel Grumbach <[email protected]> wrote:
>> On Mon, Oct 20, 2014 at 10:29 PM, Laurențiu Nicola <[email protected]> wrote:
>>> No, nothing in the DD-WRT syslog. The IP seems to be the one cached by
>>> my DHCP client. I also tried various suggestions found on the internet,
>>> but nothing helped.
>>>
>>
>> Can you please try to have another device in monitor mode to sniff the
>> traffic going on?
>> Felix, can you please tell me when DD-WRT can send a deauth with reason code 7?
>>
>> thanks.
>
> Can you please disable power save?
> For this, please make sure you have
> https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/iwlwifi-fixes.git/commit/?id=f8dfc607b2b460e8e8adfdfb3c5f5bba3a4ad01b
> or at least have the module parameter.
> I am wondering if the firmware is not sending frames because of power
> save toggling.
>
> I you could get more extensive logs from the AP it'd be great.
> Running tracing on the AP would let us know why it thinks we are not associated.
>
I have faced the same issue before it happens when DUT is in powersave
and for some reason AP authenticates (in this case probably due to
inactivity) but as DUT is in power save we don't Rx the deauth (some
AP's don't wait
for STA to wakeup and retrieve the deauth frame).
So after that if DUT tries to sent any data frame, as it still thinks
that it is connected
(network lost also will not trigger because it still Rx beacon) and in
that case AP deauthenticates
us by Reason:7.
May be if we enable tx status report ACK we can pass the inactivity
check as some AP's
wont reset inactivity timer for probe's.
Yep! `scb_timeout` is 60 on my router.
On Tue, Oct 21, 2014, at 14:00, poma wrote:
> On 21.10.2014 10:35, Felix Fietkau wrote:
> > On 2014-10-21 10:23, Laurențiu Nicola wrote:
> >> It's an ASUS RT-N66U running NEWD-2/K3X from r24160.
> > This is a Broadcom based device, so it should behave in the same way as
> > other APs/Routers running the Broadcom drivers.
> > The driver should only send Reason 7 when receiving a PS-Poll, BlockAck,
> > BlockAckReq or Action frame from a station that's not associated, so
> > probably it has already kicked out your iwlwifi client earlier. Not sure
> > why that doesn't show up in the log though.
> >
>
> Whether this might refer to the Station Control Block Timeout value
>
> http://www.dd-wrt.com/wiki/index.php/Wl#scb_timeout
> ...
> scb_timeout
>
> AP only: inactivity timeout value for authenticated stas
>
>
> poma
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
> in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> https://bpaste.net/show/5cc48256d952
>
> On Thu, Oct 23, 2014, at 22:55, Emmanuel Grumbach wrote:
>> On Thu, Oct 23, 2014 at 10:42 PM, Laurențiu Nicola <[email protected]>
>> wrote:
>>> Doesn't seem to help https://bpaste.net/show/68e1a6b33689.
>>
>> ok - let me re-add the logs...
>>
>>
This makes no sense to me.
We do talk to the AP since we get frames Acked...
Can you please apply this on top of what you have?
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 2de8870..f3b1e62 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -1991,15 +1991,16 @@ void ieee80211_sta_tx_notify(struct ieee80211_sub_if_data *sdata,
if (ieee80211_is_nullfunc(hdr->frame_control) &&
sdata->u.mgd.probe_send_count > 0) {
if (ack)
- ieee80211_sta_reset_conn_monitor(sdata);
+ // ieee80211_sta_reset_conn_monitor(sdata);
+ ;
else
sdata->u.mgd.nullfunc_failed = true;
ieee80211_queue_work(&sdata->local->hw, &sdata->work);
return;
}
- if (ack)
- ieee80211_sta_reset_conn_monitor(sdata);
+// if (ack)
+// ieee80211_sta_reset_conn_monitor(sdata);
}
static void ieee80211_mgd_probe_ap_send(struct ieee80211_sub_if_data *sdata)
Thanks.
Nope. It seems that code doesn't get executed when my issue occurs (or
in my five or ten minutes of uptime). I've seen
`ieee80211_reset_ap_probe` get called by `ieee80211_rx_mgmt_probe_resp`,
but (if I'm not wrong) not on every disconnect.
And as far as I can tell, force_cam is set to true.
Laurentiu
On Wed, Oct 22, 2014, at 12:10, Emmanuel Grumbach wrote:
> On Tue, Oct 21, 2014 at 10:56 PM, Laurențiu Nicola <[email protected]>
> wrote:
> > Yep! `scb_timeout` is 60 on my router.
> >
> > On Tue, Oct 21, 2014, at 14:00, poma wrote:
> >> On 21.10.2014 10:35, Felix Fietkau wrote:
> >> > On 2014-10-21 10:23, Laurențiu Nicola wrote:
> >> >> It's an ASUS RT-N66U running NEWD-2/K3X from r24160.
> >> > This is a Broadcom based device, so it should behave in the same way as
> >> > other APs/Routers running the Broadcom drivers.
> >> > The driver should only send Reason 7 when receiving a PS-Poll, BlockAck,
> >> > BlockAckReq or Action frame from a station that's not associated, so
> >> > probably it has already kicked out your iwlwifi client earlier. Not sure
> >> > why that doesn't show up in the log though.
> >> >
> >>
> >> Whether this might refer to the Station Control Block Timeout value
> >>
> >> http://www.dd-wrt.com/wiki/index.php/Wl#scb_timeout
> >> ...
> >> scb_timeout
> >>
> >> AP only: inactivity timeout value for authenticated stas
> >>
>
> Actually, mac80211 should be probing the AP every 30 seconds but a
> beacon might abort the probe...
> Can you try something like this:
>
> diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
> index 75df184..c9db7cf 100644
> --- a/net/mac80211/mlme.c
> +++ b/net/mac80211/mlme.c
> @@ -3295,7 +3295,8 @@ static void ieee80211_rx_mgmt_beacon(struct
> ieee80211_sub_if_data *sdata,
> if (ifmgd->flags & IEEE80211_STA_CONNECTION_POLL) {
> mlme_dbg_ratelimited(sdata,
> "cancelling AP probe due to a
> received beacon\n");
> - ieee80211_reset_ap_probe(sdata);
> + pr_err("Not cancelling the probe to make sure the AP
> hears us from time to time\n");
> + //ieee80211_reset_ap_probe(sdata);
> }
>
> /*
>
>
>
> >>
> >> poma
> >>
> >>
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
> >> in
> >> the body of a message to [email protected]
> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
> in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Oct 23, 2014 at 11:33 PM, Emmanuel Grumbach <[email protected]> wrote:
> On Thu, Oct 23, 2014 at 11:27 PM, Laurențiu Nicola <[email protected]> wrote:
>> https://bpaste.net/show/8a0e5c68762f
>>
>> On Thu, Oct 23, 2014, at 23:16, Emmanuel Grumbach wrote:
>>> > https://bpaste.net/show/5cc48256d952
>>> >
>>> > On Thu, Oct 23, 2014, at 22:55, Emmanuel Grumbach wrote:
>>> >> On Thu, Oct 23, 2014 at 10:42 PM, Laurențiu Nicola <[email protected]>
>>> >> wrote:
>>> >>> Doesn't seem to help https://bpaste.net/show/68e1a6b33689.
>>> >>
>>> >> ok - let me re-add the logs...
>>> >>
>>> >>
>>>
>>> This makes no sense to me.
>>> We do talk to the AP since we get frames Acked...
>
> This again makes no sense to me.
> Time to go to bed I guess.
Can you please open a bug on bugzilla.kernel.org?
Make sure to CC [email protected]
This will make it more trackable.
Thanks.
>
>>>
>>> Can you please apply this on top of what you have?
>>>
>>> diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
>>> index 2de8870..f3b1e62 100644
>>> --- a/net/mac80211/mlme.c
>>> +++ b/net/mac80211/mlme.c
>>> @@ -1991,15 +1991,16 @@ void ieee80211_sta_tx_notify(struct
>>> ieee80211_sub_if_data *sdata,
>>> if (ieee80211_is_nullfunc(hdr->frame_control) &&
>>> sdata->u.mgd.probe_send_count > 0) {
>>> if (ack)
>>> - ieee80211_sta_reset_conn_monitor(sdata);
>>> + // ieee80211_sta_reset_conn_monitor(sdata);
>>> + ;
>>> else
>>> sdata->u.mgd.nullfunc_failed = true;
>>> ieee80211_queue_work(&sdata->local->hw, &sdata->work);
>>> return;
>>> }
>>>
>>> - if (ack)
>>> - ieee80211_sta_reset_conn_monitor(sdata);
>>> +// if (ack)
>>> +// ieee80211_sta_reset_conn_monitor(sdata);
>>> }
>>>
>>> static void ieee80211_mgd_probe_ap_send(struct ieee80211_sub_if_data
>>> *sdata)
>>>
>>>
>>> Thanks.
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
>>> in
>>> the body of a message to [email protected]
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello,
Sorry for the late reply. I was using just wpa_supplicant. I also tried
wicd, but it seems to hang when connecting to a network, but my
understanding is that it's just a wpa_supplicant manager. I got this
while installing Gentoo, but I also reproduced it on the Fedora 20 Live
CD. See https://bpaste.net/show/7d5ad99260a7 for logs, but it doesn't
seem to say much more than my original extract.
What I found out in the meanwhile, however, is that active traffic will
prevent the issue from occurring. This happened with the Fedora Live CD,
but pinging the AP is also sufficient. I noticed iwconfig reports that
the power saving mode is off.
For what it's worth, I compiled my kernel and iwlwifi module with
tracing on, so tell me if I should try that.
Laurentiu
On Fri, Oct 17, 2014, at 04:53, Dan Williams wrote:
> On Thu, 2014-10-16 at 15:48 +0300, Laurențiu Nicola wrote:
> > Hello,
> >
> > I'm using iwlwifi for a Centrino Ultimate-N 6300 on 3.14.4 and 3.17.1.
> > Connect to my wireless network works, but I get disconnected every 60
> > seconds or so. The dmesg output looks like
> > https://bpaste.net/show/1623a8ae5dc6 .
> >
> > I had the same issue on the three latest firmware versions:
> > iwlwifi-6000-ucode-9.176.4.1
> > iwlwifi-6000-ucode-9.193.4.1
> > iwlwifi-6000-ucode-9.221.4.1
> >
> > The dmesg log actually shows the driver loading the different versions
> > above.
> >
> > It's the first time I try to use wireless on Linux, so I might have made
> > a dumb mistake.
>
> Can you try to get debug output from wpa_supplicant, which is the
> process that controls WiFi on Linux? What distro and version do you
> use, and do you know what WiFi management service is being used?
> (NetworkManager, conman, plain wpa_supplicant, wicd, something else?)
>
> Dan
>
Doesn't seem to help https://bpaste.net/show/68e1a6b33689.
Laurentiu
On Thu, Oct 23, 2014, at 22:28, Emmanuel Grumbach wrote:
> On Thu, Oct 23, 2014 at 8:38 PM, Laurențiu Nicola <[email protected]>
> wrote:
> > Okay. I'm running 3.17.1, so the line numbers might not be the ones
> > you're expecting:
> >
> > patching file net/mac80211/mlme.c
> > Hunk #1 succeeded at 128 (offset -1 lines).
> > Hunk #2 succeeded at 137 (offset -1 lines).
> > Hunk #3 succeeded at 1875 (offset -209 lines).
> > Hunk #4 succeeded at 1886 (offset -207 lines).
> > Hunk #5 succeeded at 1908 (offset -207 lines).
> > Hunk #6 succeeded at 1924 (offset -244 lines).
> >
> > dmesg output is at https://bpaste.net/show/649277aaada8 .
>
> can you please test the patch attached?
>
> (remove the previous one first please)
>
> >
> > Laurentiu
> >
> > On Thu, Oct 23, 2014, at 19:46, Emmanuel Grumbach wrote:
> >> On Thu, Oct 23, 2014 at 7:02 PM, Laurențiu Nicola <[email protected]>
> >> wrote:
> >> > Sorry, but I only saw a two-line change [1] to
> >> > `ieee80211_rx_mgmt_beacon` (which already had a log message). Am I
> >> > missing something?
> >> >
> >> > [1] http://www.spinics.net/lists/linux-wireless/msg128340.html
> >> >
> >>
> >> No - you are not. I did miss something...I forgot to attach the patch.
> >> Here you go.
> >>
> >> > Laurentiu
> >> >
> >> > On Thu, Oct 23, 2014, at 11:07, Emmanuel Grumbach wrote:
> >> >> On Thu, Oct 23, 2014 at 10:30 AM, Laurențiu Nicola <[email protected]>
> >> >> wrote:
> >> >> > I did; the card still gets disconnected and the message doesn't show up
> >> >> > in dmesg.
> >> >> >
> >> >>
> >> >> You had *none* of the many prints I added in the log?
> >> >>
> >> >> That seems really weird...
> >> >>
> >> >> > Laurentiu
> >> >> >
> >> >> > On Thu, Oct 23, 2014, at 08:21, Emmanuel Grumbach wrote:
> >> >> >> On Thu, Oct 23, 2014 at 12:53 AM, Laurențiu Nicola <[email protected]>
> >> >> >> wrote:
> >> >> >> > Nope. It seems that code doesn't get executed when my issue occurs (or
> >> >> >> > in my five or ten minutes of uptime). I've seen
> >> >> >> > `ieee80211_reset_ap_probe` get called by `ieee80211_rx_mgmt_probe_resp`,
> >> >> >> > but (if I'm not wrong) not on every disconnect.
> >> >> >> >
> >> >> >> > And as far as I can tell, force_cam is set to true.
> >> >> >>
> >> >> >> Can you please try with the patch attached and send the logs?
> >> >> >> I again need MAC80211_MLME_DEBUG.
> >> >> >>
> >> >> >> Thanks.
> >> >> >>
> >> >> >> >
> >> >> >> > Laurentiu
> >> >> >> >
> >> >> >> > On Wed, Oct 22, 2014, at 12:10, Emmanuel Grumbach wrote:
> >> >> >> >> On Tue, Oct 21, 2014 at 10:56 PM, Laurențiu Nicola <[email protected]>
> >> >> >> >> wrote:
> >> >> >> >> > Yep! `scb_timeout` is 60 on my router.
> >> >> >> >> >
> >> >> >> >> > On Tue, Oct 21, 2014, at 14:00, poma wrote:
> >> >> >> >> >> On 21.10.2014 10:35, Felix Fietkau wrote:
> >> >> >> >> >> > On 2014-10-21 10:23, Laurențiu Nicola wrote:
> >> >> >> >> >> >> It's an ASUS RT-N66U running NEWD-2/K3X from r24160.
> >> >> >> >> >> > This is a Broadcom based device, so it should behave in the same way as
> >> >> >> >> >> > other APs/Routers running the Broadcom drivers.
> >> >> >> >> >> > The driver should only send Reason 7 when receiving a PS-Poll, BlockAck,
> >> >> >> >> >> > BlockAckReq or Action frame from a station that's not associated, so
> >> >> >> >> >> > probably it has already kicked out your iwlwifi client earlier. Not sure
> >> >> >> >> >> > why that doesn't show up in the log though.
> >> >> >> >> >> >
> >> >> >> >> >>
> >> >> >> >> >> Whether this might refer to the Station Control Block Timeout value
> >> >> >> >> >>
> >> >> >> >> >> http://www.dd-wrt.com/wiki/index.php/Wl#scb_timeout
> >> >> >> >> >> ...
> >> >> >> >> >> scb_timeout
> >> >> >> >> >>
> >> >> >> >> >> AP only: inactivity timeout value for authenticated stas
> >> >> >> >> >>
> >> >> >> >>
> >> >> >> >> Actually, mac80211 should be probing the AP every 30 seconds but a
> >> >> >> >> beacon might abort the probe...
> >> >> >> >> Can you try something like this:
> >> >> >> >>
> >> >> >> >> diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
> >> >> >> >> index 75df184..c9db7cf 100644
> >> >> >> >> --- a/net/mac80211/mlme.c
> >> >> >> >> +++ b/net/mac80211/mlme.c
> >> >> >> >> @@ -3295,7 +3295,8 @@ static void ieee80211_rx_mgmt_beacon(struct
> >> >> >> >> ieee80211_sub_if_data *sdata,
> >> >> >> >> if (ifmgd->flags & IEEE80211_STA_CONNECTION_POLL) {
> >> >> >> >> mlme_dbg_ratelimited(sdata,
> >> >> >> >> "cancelling AP probe due to a
> >> >> >> >> received beacon\n");
> >> >> >> >> - ieee80211_reset_ap_probe(sdata);
> >> >> >> >> + pr_err("Not cancelling the probe to make sure the AP
> >> >> >> >> hears us from time to time\n");
> >> >> >> >> + //ieee80211_reset_ap_probe(sdata);
> >> >> >> >> }
> >> >> >> >>
> >> >> >> >> /*
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >> poma
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >> --
> >> >> >> >> >> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
> >> >> >> >> >> in
> >> >> >> >> >> the body of a message to [email protected]
> >> >> >> >> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >> >> >> >> --
> >> >> >> >> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
> >> >> >> >> in
> >> >> >> >> the body of a message to [email protected]
> >> >> >> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >> >> >> --
> >> >> >> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
> >> >> >> in
> >> >> >> the body of a message to [email protected]
> >> >> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >> >> --
> >> >> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
> >> >> in
> >> >> the body of a message to [email protected]
> >> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >> Email had 1 attachment:
> >> + PROBE.patch
> >> 3k (application/octet-stream)
> Email had 1 attachment:
> + a.patch
> 3k (application/octet-stream)
On Tue, Oct 21, 2014 at 10:28 AM, Laurențiu Nicola <[email protected]> wrote:
> I have 3.17.1, which includes the patch you mention. I also verified
> that iwconfig reports that power management is disabled.
>
> I don't know how easy it is to recompile the DD-WRT kernel. One thing I
> could do is try another firmware instead of DD-WRT to see if the issue
> still occurs.
>
I guess you can try to use the vendor's firmware and see what happens.
Another option is try to tweak DD-WRT not to kick client out after 1 minute :)
> Laurentiu
>
> On Tue, Oct 21, 2014, at 08:31, Emmanuel Grumbach wrote:
>> On Tue, Oct 21, 2014 at 8:02 AM, Emmanuel Grumbach <[email protected]>
>> wrote:
>> > On Mon, Oct 20, 2014 at 10:29 PM, Laurențiu Nicola <[email protected]> wrote:
>> >> No, nothing in the DD-WRT syslog. The IP seems to be the one cached by
>> >> my DHCP client. I also tried various suggestions found on the internet,
>> >> but nothing helped.
>> >>
>> >
>> > Can you please try to have another device in monitor mode to sniff the
>> > traffic going on?
>> > Felix, can you please tell me when DD-WRT can send a deauth with reason code 7?
>> >
>> > thanks.
>>
>> Can you please disable power save?
>> For this, please make sure you have
>> https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/iwlwifi-fixes.git/commit/?id=f8dfc607b2b460e8e8adfdfb3c5f5bba3a4ad01b
>> or at least have the module parameter.
>> I am wondering if the firmware is not sending frames because of power
>> save toggling.
>>
>> I you could get more extensive logs from the AP it'd be great.
>> Running tracing on the AP would let us know why it thinks we are not
>> associated.
>>
>>
>> >
>> >> Laurentiu
>> >>
>> >> On Mon, Oct 20, 2014, at 11:23, Emmanuel Grumbach wrote:
>> >>> On Mon, Oct 20, 2014 at 10:22 AM, Laurențiu Nicola <[email protected]>
>> >>> wrote:
>> >>> > One thing that might be relevant is that, although there is a static
>> >>> > DHCP lease configured (which works on Windows), the router/AP is giving
>> >>> > the laptop a different IP address. The reported MACs are the same, of
>> >>> > course. I don't know whether wpa_supplicant remembers and requests the
>> >>> > last IP it had, but the lease was already present when I configured it.
>> >>> >
>> >>> > The router runs DD-WRT and I don't have problems on Windows or Android.
>> >>> >
>> >>>
>> >>> I guess you can try to get some logs from the DD-WRT - but if the AP
>> >>> doesn't
>> >>> give the same address to Linux as in Windows - there is something
>> >>> fishy...
>> >>>
>> >>> > Laurentiu
>> >>> >
>> >>> > On Mon, Oct 20, 2014, at 10:12, Emmanuel Grumbach wrote:
>> >>> >> On Mon, Oct 20, 2014 at 10:06 AM, Emmanuel Grumbach <[email protected]>
>> >>> >> wrote:
>> >>> >> > On Mon, Oct 20, 2014 at 8:30 AM, Laurențiu Nicola <[email protected]> wrote:
>> >>> >> >> Here: https://bpaste.net/show/bf6dc1847ce3
>> >>> >> >>
>> >>> >> >
>> >>> >> > Are you sure you had MAC80211_MLME_DEBUG?
>> >>> >> >
>> >>> >> >>
>> >>> >> Ok - You probably had it - sorry. But apparently the AP is really kicking
>> >>> >> us...
>> >>> >> What AP do you have?
>> >>> >> --
>> >>> >> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
>> >>> >> in
>> >>> >> the body of a message to [email protected]
>> >>> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> >>> --
>> >>> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
>> >>> in
>> >>> the body of a message to [email protected]
>> >>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
>> in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
On 21.10.2014 10:35, Felix Fietkau wrote:
> On 2014-10-21 10:23, Laurențiu Nicola wrote:
>> It's an ASUS RT-N66U running NEWD-2/K3X from r24160.
> This is a Broadcom based device, so it should behave in the same way as
> other APs/Routers running the Broadcom drivers.
> The driver should only send Reason 7 when receiving a PS-Poll, BlockAck,
> BlockAckReq or Action frame from a station that's not associated, so
> probably it has already kicked out your iwlwifi client earlier. Not sure
> why that doesn't show up in the log though.
>
Whether this might refer to the Station Control Block Timeout value
http://www.dd-wrt.com/wiki/index.php/Wl#scb_timeout
...
scb_timeout
AP only: inactivity timeout value for authenticated stas
poma
On Tue, Oct 21, 2014 at 10:56 PM, Laurențiu Nicola <[email protected]> wrote:
> Yep! `scb_timeout` is 60 on my router.
>
> On Tue, Oct 21, 2014, at 14:00, poma wrote:
>> On 21.10.2014 10:35, Felix Fietkau wrote:
>> > On 2014-10-21 10:23, Laurențiu Nicola wrote:
>> >> It's an ASUS RT-N66U running NEWD-2/K3X from r24160.
>> > This is a Broadcom based device, so it should behave in the same way as
>> > other APs/Routers running the Broadcom drivers.
>> > The driver should only send Reason 7 when receiving a PS-Poll, BlockAck,
>> > BlockAckReq or Action frame from a station that's not associated, so
>> > probably it has already kicked out your iwlwifi client earlier. Not sure
>> > why that doesn't show up in the log though.
>> >
>>
>> Whether this might refer to the Station Control Block Timeout value
>>
>> http://www.dd-wrt.com/wiki/index.php/Wl#scb_timeout
>> ...
>> scb_timeout
>>
>> AP only: inactivity timeout value for authenticated stas
>>
Actually, mac80211 should be probing the AP every 30 seconds but a
beacon might abort the probe...
Can you try something like this:
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 75df184..c9db7cf 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -3295,7 +3295,8 @@ static void ieee80211_rx_mgmt_beacon(struct
ieee80211_sub_if_data *sdata,
if (ifmgd->flags & IEEE80211_STA_CONNECTION_POLL) {
mlme_dbg_ratelimited(sdata,
"cancelling AP probe due to a
received beacon\n");
- ieee80211_reset_ap_probe(sdata);
+ pr_err("Not cancelling the probe to make sure the AP
hears us from time to time\n");
+ //ieee80211_reset_ap_probe(sdata);
}
/*
>>
>> poma
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
>> in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
One thing that might be relevant is that, although there is a static
DHCP lease configured (which works on Windows), the router/AP is giving
the laptop a different IP address. The reported MACs are the same, of
course. I don't know whether wpa_supplicant remembers and requests the
last IP it had, but the lease was already present when I configured it.
The router runs DD-WRT and I don't have problems on Windows or Android.
Laurentiu
On Mon, Oct 20, 2014, at 10:12, Emmanuel Grumbach wrote:
> On Mon, Oct 20, 2014 at 10:06 AM, Emmanuel Grumbach <[email protected]>
> wrote:
> > On Mon, Oct 20, 2014 at 8:30 AM, Laurențiu Nicola <[email protected]> wrote:
> >> Here: https://bpaste.net/show/bf6dc1847ce3
> >>
> >
> > Are you sure you had MAC80211_MLME_DEBUG?
> >
> >>
> Ok - You probably had it - sorry. But apparently the AP is really kicking
> us...
> What AP do you have?
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
> in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Here: https://bpaste.net/show/bf6dc1847ce3
Laurentiu
On Mon, Oct 20, 2014, at 07:52, Emmanuel Grumbach wrote:
> On Sun, Oct 19, 2014 at 11:48 PM, Laurențiu Nicola <[email protected]>
> wrote:
> > Hello,
> >
> > Sorry for the late reply. I was using just wpa_supplicant. I also tried
> > wicd, but it seems to hang when connecting to a network, but my
> > understanding is that it's just a wpa_supplicant manager. I got this
> > while installing Gentoo, but I also reproduced it on the Fedora 20 Live
> > CD. See https://bpaste.net/show/7d5ad99260a7 for logs, but it doesn't
> > seem to say much more than my original extract.
> >
> > What I found out in the meanwhile, however, is that active traffic will
> > prevent the issue from occurring. This happened with the Fedora Live CD,
> > but pinging the AP is also sufficient. I noticed iwconfig reports that
> > the power saving mode is off.
> >
> > For what it's worth, I compiled my kernel and iwlwifi module with
> > tracing on, so tell me if I should try that.
>
> Please recompile with MAC80211_MLME_DEBUG, MAC80211_STA_DEBUG and
> reproduce - thanks.
>
> >
> > Laurentiu
> >
> >
> > On Fri, Oct 17, 2014, at 04:53, Dan Williams wrote:
> >> On Thu, 2014-10-16 at 15:48 +0300, Laurențiu Nicola wrote:
> >> > Hello,
> >> >
> >> > I'm using iwlwifi for a Centrino Ultimate-N 6300 on 3.14.4 and 3.17.1.
> >> > Connect to my wireless network works, but I get disconnected every 60
> >> > seconds or so. The dmesg output looks like
> >> > https://bpaste.net/show/1623a8ae5dc6 .
> >> >
> >> > I had the same issue on the three latest firmware versions:
> >> > iwlwifi-6000-ucode-9.176.4.1
> >> > iwlwifi-6000-ucode-9.193.4.1
> >> > iwlwifi-6000-ucode-9.221.4.1
> >> >
> >> > The dmesg log actually shows the driver loading the different versions
> >> > above.
> >> >
> >> > It's the first time I try to use wireless on Linux, so I might have made
> >> > a dumb mistake.
> >>
> >> Can you try to get debug output from wpa_supplicant, which is the
> >> process that controls WiFi on Linux? What distro and version do you
> >> use, and do you know what WiFi management service is being used?
> >> (NetworkManager, conman, plain wpa_supplicant, wicd, something else?)
> >>
> >> Dan
> >>
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> > the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
> in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On 2014-10-21 07:02, Emmanuel Grumbach wrote:
> On Mon, Oct 20, 2014 at 10:29 PM, Laurențiu Nicola <[email protected]> wrote:
>> No, nothing in the DD-WRT syslog. The IP seems to be the one cached by
>> my DHCP client. I also tried various suggestions found on the internet,
>> but nothing helped.
>>
>
> Can you please try to have another device in monitor mode to sniff the
> traffic going on?
> Felix, can you please tell me when DD-WRT can send a deauth with reason code 7?
What kind of device is it, and what software version?
- Felix
I have 3.17.1, which includes the patch you mention. I also verified
that iwconfig reports that power management is disabled.
I don't know how easy it is to recompile the DD-WRT kernel. One thing I
could do is try another firmware instead of DD-WRT to see if the issue
still occurs.
Laurentiu
On Tue, Oct 21, 2014, at 08:31, Emmanuel Grumbach wrote:
> On Tue, Oct 21, 2014 at 8:02 AM, Emmanuel Grumbach <[email protected]>
> wrote:
> > On Mon, Oct 20, 2014 at 10:29 PM, Laurențiu Nicola <[email protected]> wrote:
> >> No, nothing in the DD-WRT syslog. The IP seems to be the one cached by
> >> my DHCP client. I also tried various suggestions found on the internet,
> >> but nothing helped.
> >>
> >
> > Can you please try to have another device in monitor mode to sniff the
> > traffic going on?
> > Felix, can you please tell me when DD-WRT can send a deauth with reason code 7?
> >
> > thanks.
>
> Can you please disable power save?
> For this, please make sure you have
> https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/iwlwifi-fixes.git/commit/?id=f8dfc607b2b460e8e8adfdfb3c5f5bba3a4ad01b
> or at least have the module parameter.
> I am wondering if the firmware is not sending frames because of power
> save toggling.
>
> I you could get more extensive logs from the AP it'd be great.
> Running tracing on the AP would let us know why it thinks we are not
> associated.
>
>
> >
> >> Laurentiu
> >>
> >> On Mon, Oct 20, 2014, at 11:23, Emmanuel Grumbach wrote:
> >>> On Mon, Oct 20, 2014 at 10:22 AM, Laurențiu Nicola <[email protected]>
> >>> wrote:
> >>> > One thing that might be relevant is that, although there is a static
> >>> > DHCP lease configured (which works on Windows), the router/AP is giving
> >>> > the laptop a different IP address. The reported MACs are the same, of
> >>> > course. I don't know whether wpa_supplicant remembers and requests the
> >>> > last IP it had, but the lease was already present when I configured it.
> >>> >
> >>> > The router runs DD-WRT and I don't have problems on Windows or Android.
> >>> >
> >>>
> >>> I guess you can try to get some logs from the DD-WRT - but if the AP
> >>> doesn't
> >>> give the same address to Linux as in Windows - there is something
> >>> fishy...
> >>>
> >>> > Laurentiu
> >>> >
> >>> > On Mon, Oct 20, 2014, at 10:12, Emmanuel Grumbach wrote:
> >>> >> On Mon, Oct 20, 2014 at 10:06 AM, Emmanuel Grumbach <[email protected]>
> >>> >> wrote:
> >>> >> > On Mon, Oct 20, 2014 at 8:30 AM, Laurențiu Nicola <[email protected]> wrote:
> >>> >> >> Here: https://bpaste.net/show/bf6dc1847ce3
> >>> >> >>
> >>> >> >
> >>> >> > Are you sure you had MAC80211_MLME_DEBUG?
> >>> >> >
> >>> >> >>
> >>> >> Ok - You probably had it - sorry. But apparently the AP is really kicking
> >>> >> us...
> >>> >> What AP do you have?
> >>> >> --
> >>> >> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
> >>> >> in
> >>> >> the body of a message to [email protected]
> >>> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >>> --
> >>> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
> >>> in
> >>> the body of a message to [email protected]
> >>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
> in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
It's an ASUS RT-N66U running NEWD-2/K3X from r24160.
Laurentiu
On Tue, Oct 21, 2014, at 11:20, Felix Fietkau wrote:
> On 2014-10-21 07:02, Emmanuel Grumbach wrote:
> > On Mon, Oct 20, 2014 at 10:29 PM, Laurențiu Nicola <[email protected]> wrote:
> >> No, nothing in the DD-WRT syslog. The IP seems to be the one cached by
> >> my DHCP client. I also tried various suggestions found on the internet,
> >> but nothing helped.
> >>
> >
> > Can you please try to have another device in monitor mode to sniff the
> > traffic going on?
> > Felix, can you please tell me when DD-WRT can send a deauth with reason code 7?
> What kind of device is it, and what software version?
>
> - Felix
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
> in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Okay, I've filed a bug [1].
At some point you mentioned about using another device to monitor
traffic. I don't have another laptop running Linux (would Android
count?), but DD-WRT has a "wl monitor" command [2] that sounds useful.
Should I try to install tcpdump on my router?
Laurentiu
[1] https://bugzilla.kernel.org/show_bug.cgi?id=86801
[2] http://www.dd-wrt.com/wiki/index.php/Wl#monitor
On Fri, Oct 24, 2014, at 08:32, Emmanuel Grumbach wrote:
> On Thu, Oct 23, 2014 at 11:33 PM, Emmanuel Grumbach <[email protected]>
> wrote:
> > On Thu, Oct 23, 2014 at 11:27 PM, Laurențiu Nicola <[email protected]> wrote:
> >> https://bpaste.net/show/8a0e5c68762f
> >>
> >> On Thu, Oct 23, 2014, at 23:16, Emmanuel Grumbach wrote:
> >>> > https://bpaste.net/show/5cc48256d952
> >>> >
> >>> > On Thu, Oct 23, 2014, at 22:55, Emmanuel Grumbach wrote:
> >>> >> On Thu, Oct 23, 2014 at 10:42 PM, Laurențiu Nicola <[email protected]>
> >>> >> wrote:
> >>> >>> Doesn't seem to help https://bpaste.net/show/68e1a6b33689.
> >>> >>
> >>> >> ok - let me re-add the logs...
> >>> >>
> >>> >>
> >>>
> >>> This makes no sense to me.
> >>> We do talk to the AP since we get frames Acked...
> >
> > This again makes no sense to me.
> > Time to go to bed I guess.
>
> Can you please open a bug on bugzilla.kernel.org?
> Make sure to CC [email protected]
>
> This will make it more trackable.
> Thanks.
>
> >
> >>>
> >>> Can you please apply this on top of what you have?
> >>>
> >>> diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
> >>> index 2de8870..f3b1e62 100644
> >>> --- a/net/mac80211/mlme.c
> >>> +++ b/net/mac80211/mlme.c
> >>> @@ -1991,15 +1991,16 @@ void ieee80211_sta_tx_notify(struct
> >>> ieee80211_sub_if_data *sdata,
> >>> if (ieee80211_is_nullfunc(hdr->frame_control) &&
> >>> sdata->u.mgd.probe_send_count > 0) {
> >>> if (ack)
> >>> - ieee80211_sta_reset_conn_monitor(sdata);
> >>> + // ieee80211_sta_reset_conn_monitor(sdata);
> >>> + ;
> >>> else
> >>> sdata->u.mgd.nullfunc_failed = true;
> >>> ieee80211_queue_work(&sdata->local->hw, &sdata->work);
> >>> return;
> >>> }
> >>>
> >>> - if (ack)
> >>> - ieee80211_sta_reset_conn_monitor(sdata);
> >>> +// if (ack)
> >>> +// ieee80211_sta_reset_conn_monitor(sdata);
> >>> }
> >>>
> >>> static void ieee80211_mgd_probe_ap_send(struct ieee80211_sub_if_data
> >>> *sdata)
> >>>
> >>>
> >>> Thanks.
> >>> --
> >>> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
> >>> in
> >>> the body of a message to [email protected]
> >>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
> in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Oct 21, 2014 at 2:05 PM, Felix Fietkau <[email protected]> wrote:
> On 2014-10-21 10:23, Laurențiu Nicola wrote:
>> It's an ASUS RT-N66U running NEWD-2/K3X from r24160.
> This is a Broadcom based device, so it should behave in the same way as
> other APs/Routers running the Broadcom drivers.
> The driver should only send Reason 7 when receiving a PS-Poll, BlockAck,
> BlockAckReq or Action frame from a station that's not associated, so
> probably it has already kicked out your iwlwifi client earlier. Not sure
> why that doesn't show up in the log though.
>
May be iwlwifi is dozing and did not Rx that frame?
https://bpaste.net/show/5cc48256d952
On Thu, Oct 23, 2014, at 22:55, Emmanuel Grumbach wrote:
> On Thu, Oct 23, 2014 at 10:42 PM, Laurențiu Nicola <[email protected]>
> wrote:
> > Doesn't seem to help https://bpaste.net/show/68e1a6b33689.
>
> ok - let me re-add the logs...
>
>
> >
> > Laurentiu
> >
> > On Thu, Oct 23, 2014, at 22:28, Emmanuel Grumbach wrote:
> >> On Thu, Oct 23, 2014 at 8:38 PM, Laurențiu Nicola <[email protected]>
> >> wrote:
> >> > Okay. I'm running 3.17.1, so the line numbers might not be the ones
> >> > you're expecting:
> >> >
> >> > patching file net/mac80211/mlme.c
> >> > Hunk #1 succeeded at 128 (offset -1 lines).
> >> > Hunk #2 succeeded at 137 (offset -1 lines).
> >> > Hunk #3 succeeded at 1875 (offset -209 lines).
> >> > Hunk #4 succeeded at 1886 (offset -207 lines).
> >> > Hunk #5 succeeded at 1908 (offset -207 lines).
> >> > Hunk #6 succeeded at 1924 (offset -244 lines).
> >> >
> >> > dmesg output is at https://bpaste.net/show/649277aaada8 .
> >>
> >> can you please test the patch attached?
> >>
> >> (remove the previous one first please)
> >>
> >> >
> >> > Laurentiu
> >> >
> >> > On Thu, Oct 23, 2014, at 19:46, Emmanuel Grumbach wrote:
> >> >> On Thu, Oct 23, 2014 at 7:02 PM, Laurențiu Nicola <[email protected]>
> >> >> wrote:
> >> >> > Sorry, but I only saw a two-line change [1] to
> >> >> > `ieee80211_rx_mgmt_beacon` (which already had a log message). Am I
> >> >> > missing something?
> >> >> >
> >> >> > [1] http://www.spinics.net/lists/linux-wireless/msg128340.html
> >> >> >
> >> >>
> >> >> No - you are not. I did miss something...I forgot to attach the patch.
> >> >> Here you go.
> >> >>
> >> >> > Laurentiu
> >> >> >
> >> >> > On Thu, Oct 23, 2014, at 11:07, Emmanuel Grumbach wrote:
> >> >> >> On Thu, Oct 23, 2014 at 10:30 AM, Laurențiu Nicola <[email protected]>
> >> >> >> wrote:
> >> >> >> > I did; the card still gets disconnected and the message doesn't show up
> >> >> >> > in dmesg.
> >> >> >> >
> >> >> >>
> >> >> >> You had *none* of the many prints I added in the log?
> >> >> >>
> >> >> >> That seems really weird...
> >> >> >>
> >> >> >> > Laurentiu
> >> >> >> >
> >> >> >> > On Thu, Oct 23, 2014, at 08:21, Emmanuel Grumbach wrote:
> >> >> >> >> On Thu, Oct 23, 2014 at 12:53 AM, Laurențiu Nicola <[email protected]>
> >> >> >> >> wrote:
> >> >> >> >> > Nope. It seems that code doesn't get executed when my issue occurs (or
> >> >> >> >> > in my five or ten minutes of uptime). I've seen
> >> >> >> >> > `ieee80211_reset_ap_probe` get called by `ieee80211_rx_mgmt_probe_resp`,
> >> >> >> >> > but (if I'm not wrong) not on every disconnect.
> >> >> >> >> >
> >> >> >> >> > And as far as I can tell, force_cam is set to true.
> >> >> >> >>
> >> >> >> >> Can you please try with the patch attached and send the logs?
> >> >> >> >> I again need MAC80211_MLME_DEBUG.
> >> >> >> >>
> >> >> >> >> Thanks.
> >> >> >> >>
> >> >> >> >> >
> >> >> >> >> > Laurentiu
> >> >> >> >> >
> >> >> >> >> > On Wed, Oct 22, 2014, at 12:10, Emmanuel Grumbach wrote:
> >> >> >> >> >> On Tue, Oct 21, 2014 at 10:56 PM, Laurențiu Nicola <[email protected]>
> >> >> >> >> >> wrote:
> >> >> >> >> >> > Yep! `scb_timeout` is 60 on my router.
> >> >> >> >> >> >
> >> >> >> >> >> > On Tue, Oct 21, 2014, at 14:00, poma wrote:
> >> >> >> >> >> >> On 21.10.2014 10:35, Felix Fietkau wrote:
> >> >> >> >> >> >> > On 2014-10-21 10:23, Laurențiu Nicola wrote:
> >> >> >> >> >> >> >> It's an ASUS RT-N66U running NEWD-2/K3X from r24160.
> >> >> >> >> >> >> > This is a Broadcom based device, so it should behave in the same way as
> >> >> >> >> >> >> > other APs/Routers running the Broadcom drivers.
> >> >> >> >> >> >> > The driver should only send Reason 7 when receiving a PS-Poll, BlockAck,
> >> >> >> >> >> >> > BlockAckReq or Action frame from a station that's not associated, so
> >> >> >> >> >> >> > probably it has already kicked out your iwlwifi client earlier. Not sure
> >> >> >> >> >> >> > why that doesn't show up in the log though.
> >> >> >> >> >> >> >
> >> >> >> >> >> >>
> >> >> >> >> >> >> Whether this might refer to the Station Control Block Timeout value
> >> >> >> >> >> >>
> >> >> >> >> >> >> http://www.dd-wrt.com/wiki/index.php/Wl#scb_timeout
> >> >> >> >> >> >> ...
> >> >> >> >> >> >> scb_timeout
> >> >> >> >> >> >>
> >> >> >> >> >> >> AP only: inactivity timeout value for authenticated stas
> >> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >> Actually, mac80211 should be probing the AP every 30 seconds but a
> >> >> >> >> >> beacon might abort the probe...
> >> >> >> >> >> Can you try something like this:
> >> >> >> >> >>
> >> >> >> >> >> diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
> >> >> >> >> >> index 75df184..c9db7cf 100644
> >> >> >> >> >> --- a/net/mac80211/mlme.c
> >> >> >> >> >> +++ b/net/mac80211/mlme.c
> >> >> >> >> >> @@ -3295,7 +3295,8 @@ static void ieee80211_rx_mgmt_beacon(struct
> >> >> >> >> >> ieee80211_sub_if_data *sdata,
> >> >> >> >> >> if (ifmgd->flags & IEEE80211_STA_CONNECTION_POLL) {
> >> >> >> >> >> mlme_dbg_ratelimited(sdata,
> >> >> >> >> >> "cancelling AP probe due to a
> >> >> >> >> >> received beacon\n");
> >> >> >> >> >> - ieee80211_reset_ap_probe(sdata);
> >> >> >> >> >> + pr_err("Not cancelling the probe to make sure the AP
> >> >> >> >> >> hears us from time to time\n");
> >> >> >> >> >> + //ieee80211_reset_ap_probe(sdata);
> >> >> >> >> >> }
> >> >> >> >> >>
> >> >> >> >> >> /*
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >> >>
> >> >> >> >> >> >> poma
> >> >> >> >> >> >>
> >> >> >> >> >> >>
> >> >> >> >> >> >> --
> >> >> >> >> >> >> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
> >> >> >> >> >> >> in
> >> >> >> >> >> >> the body of a message to [email protected]
> >> >> >> >> >> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >> >> >> >> >> --
> >> >> >> >> >> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
> >> >> >> >> >> in
> >> >> >> >> >> the body of a message to [email protected]
> >> >> >> >> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >> >> >> >> --
> >> >> >> >> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
> >> >> >> >> in
> >> >> >> >> the body of a message to [email protected]
> >> >> >> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >> >> >> --
> >> >> >> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
> >> >> >> in
> >> >> >> the body of a message to [email protected]
> >> >> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >> >> Email had 1 attachment:
> >> >> + PROBE.patch
> >> >> 3k (application/octet-stream)
> >> Email had 1 attachment:
> >> + a.patch
> >> 3k (application/octet-stream)
> Email had 1 attachment:
> + a.patch
> 6k (application/octet-stream)
On 2014-10-21 10:23, Laurențiu Nicola wrote:
> It's an ASUS RT-N66U running NEWD-2/K3X from r24160.
This is a Broadcom based device, so it should behave in the same way as
other APs/Routers running the Broadcom drivers.
The driver should only send Reason 7 when receiving a PS-Poll, BlockAck,
BlockAckReq or Action frame from a station that's not associated, so
probably it has already kicked out your iwlwifi client earlier. Not sure
why that doesn't show up in the log though.
- Felix
Perhaps I'm not looking at the right log :). Do you mean enabling syslog
and /tmp/var/log/messages?
Laurentiu
On Tue, Oct 21, 2014, at 11:35, Felix Fietkau wrote:
> On 2014-10-21 10:23, Laurențiu Nicola wrote:
> > It's an ASUS RT-N66U running NEWD-2/K3X from r24160.
> This is a Broadcom based device, so it should behave in the same way as
> other APs/Routers running the Broadcom drivers.
> The driver should only send Reason 7 when receiving a PS-Poll, BlockAck,
> BlockAckReq or Action frame from a station that's not associated, so
> probably it has already kicked out your iwlwifi client earlier. Not sure
> why that doesn't show up in the log though.
>
> - Felix
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
> in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html