wlan0 keeps deauthenticating DEAUTH_LEAVING about every minute

wlan0 keeps deauthenticating DEAUTH_LEAVING about every minute

[Dennis New]

Ever since I upgraded to the 4.10 kernels (I don't think this behavior
existed in the 4.8 series), after I startup my laptop (either from cold
boot, or from standby), my wlan0 interface keeps deauthenticating

19:24:29 kernel: wlan0: deauthenticating from 00:11:22:33:44:55 by
local choice (Reason: 3=DEAUTH_LEAVING)

usually exactly 60 seconds after it authenticates/associates (to my
open wifi access point), but not always 60 seconds after -- sometimes
it happens in less than 60 seconds. Although, if it somehow manages to
pass the 60 second mark without deauthenticating, it remains stable --
unless I decide to /etc/init.d/net.wlan0 restart it :s. I'm not sure
what makes makes the deauthentications suddenly stop, but after various
incantations and module unloading/reloading and a fair amount of
cursing, or possibly just waiting some random amount of time, the
problem goes away for the day ... and returns the next day when I boot
up again, and I have to go through this torturous process all over
again, of praying and restarting my wlan0 interface.

Here's a snippet of my messages log, of the usual 60 second deauth:

...
19:23:29 kernel: wlan0: authenticate with 00:11:22:33:44:55
19:23:29 kernel: ------------[ cut here ]------------
19:23:29 kernel: WARNING: CPU: 0 PID: 18925 at net/mac80211/mlme.c:287 ieee80211_determine_chantype+0x12e/0x380
19:23:29 kernel: Modules linked in: b43 [last unloaded: b43]
19:23:29 kernel: Hardware name: Acer, inc. Ferrari 4000
19:23:29 kernel: Call Trace:
19:23:29 kernel:  ? __warn+0xdd/0x100
19:23:29 kernel:  ? ieee80211_determine_chantype+0x12e/0x380
19:23:29 kernel:  ? ieee80211_prep_connection+0x121/0x8a0
19:23:29 kernel:  ? printk+0x42/0x4a
19:23:29 kernel:  ? ieee80211_mgd_auth+0x247/0x3a0
19:23:29 kernel:  ? cfg80211_get_bss+0x1bb/0x230
19:23:29 kernel:  ? cfg80211_mlme_auth+0x11a/0x180
19:23:29 kernel:  ? nl80211_authenticate+0x2e2/0x340
19:23:29 kernel:  ? genl_family_rcv_msg+0x196/0x390
19:23:29 kernel:  ? genl_rcv_msg+0x3e/0x90
19:23:29 kernel:  ? genl_family_rcv_msg+0x390/0x390
19:23:29 kernel:  ? netlink_rcv_skb+0x8f/0xb0
19:23:29 kernel:  ? genl_rcv+0x1f/0x30
19:23:29 kernel:  ? netlink_unicast+0x12f/0x1d0
19:23:29 kernel:  ? netlink_sendmsg+0x2e1/0x380
19:23:29 kernel:  ? rw_copy_check_uvector+0x51/0x100
19:23:29 kernel:  ? sock_sendmsg+0xe/0x20
19:23:29 kernel:  ? ___sys_sendmsg+0x26b/0x280
19:23:29 kernel:  ? core_sys_select+0x232/0x320
19:23:29 kernel:  ? _copy_to_user+0x25/0x30
19:23:29 kernel:  ? sock_getsockopt+0x10d/0x720
19:23:29 kernel:  ? unix_ioctl+0x43/0x50
19:23:29 kernel:  ? sock_do_ioctl.constprop.17+0x19/0x60
19:23:29 kernel:  ? sock_ioctl+0x1dd/0x2b0
19:23:29 kernel:  ? __sys_sendmsg+0x47/0x80
19:23:29 kernel:  ? entry_SYSCALL_64_fastpath+0x13/0x93
19:23:29 kernel: ---[ end trace 17d46d9355f2a966 ]---
19:23:29 kernel: wlan0: send auth to 00:11:22:33:44:55 (try 1/3)
19:23:29 kernel: wlan0: authenticated
19:23:29 kernel: wlan0: associate with 00:11:22:33:44:55 (try 1/3)
19:23:29 kernel: wlan0: RX AssocResp from 00:11:22:33:44:55 (capab=0x401 status=0 aid=1)
19:23:29 kernel: wlan0: associated

19:24:29 kernel: wlan0: deauthenticating from 00:11:22:33:44:55 by local choice (Reason: 3=DEAUTH_LEAVING)
19:24:30 kernel: wlan0: authenticate with 00:11:22:33:44:55
19:24:30 kernel: ------------[ cut here ]------------
19:24:30 kernel: WARNING: CPU: 0 PID: 18925 at net/mac80211/mlme.c:287 ieee80211_determine_chantype+0x12e/0x380
19:24:30 kernel: Modules linked in: b43 [last unloaded: b43]
19:24:30 kernel: Hardware name: Acer, inc. Ferrari 4000
19:24:30 kernel: Call Trace:
19:24:30 kernel:  ? __warn+0xdd/0x100
19:24:30 kernel:  ? ieee80211_determine_chantype+0x12e/0x380
19:24:30 kernel:  ? ieee80211_prep_connection+0x121/0x8a0
19:24:30 kernel:  ? printk+0x42/0x4a
19:24:30 kernel:  ? ieee80211_mgd_auth+0x247/0x3a0
19:24:30 kernel:  ? cfg80211_get_bss+0x1bb/0x230
19:24:30 kernel:  ? cfg80211_mlme_auth+0x11a/0x180
19:24:30 kernel:  ? nl80211_authenticate+0x2e2/0x340
19:24:30 kernel:  ? genl_family_rcv_msg+0x196/0x390
19:24:30 kernel:  ? genl_rcv_msg+0x3e/0x90
19:24:30 kernel:  ? genl_family_rcv_msg+0x390/0x390
19:24:30 kernel:  ? netlink_rcv_skb+0x8f/0xb0
19:24:30 kernel:  ? genl_rcv+0x1f/0x30
19:24:30 kernel:  ? netlink_unicast+0x12f/0x1d0
19:24:30 kernel:  ? netlink_sendmsg+0x2e1/0x380
19:24:30 kernel:  ? rw_copy_check_uvector+0x51/0x100
19:24:30 kernel:  ? sock_sendmsg+0xe/0x20
19:24:30 kernel:  ? ___sys_sendmsg+0x26b/0x280
19:24:30 kernel:  ? core_sys_select+0x232/0x320
19:24:30 kernel:  ? _copy_to_user+0x25/0x30
19:24:30 kernel:  ? sock_getsockopt+0x10d/0x720
19:24:30 kernel:  ? unix_ioctl+0x43/0x50
19:24:30 kernel:  ? sock_do_ioctl.constprop.17+0x19/0x60
19:24:30 kernel:  ? sock_ioctl+0x1dd/0x2b0
19:24:30 kernel:  ? _copy_to_user+0x25/0x30
19:24:30 kernel:  ? __sys_sendmsg+0x47/0x80
19:24:30 kernel:  ? entry_SYSCALL_64_fastpath+0x13/0x93
19:24:30 kernel: ---[ end trace 17d46d9355f2a967 ]---
19:24:30 kernel: wlan0: send auth to 00:11:22:33:44:55 (try 1/3)
19:24:30 kernel: wlan0: authenticated
19:24:30 kernel: wlan0: associate with 00:11:22:33:44:55 (try 1/3)
19:24:30 kernel: wlan0: RX AssocResp from 00:11:22:33:44:55 (capab=0x401 status=0 aid=1)
19:24:30 kernel: wlan0: associated

19:25:30 kernel: wlan0: deauthenticating from 00:11:22:33:44:55 by local choice (Reason: 3=DEAUTH_LEAVING)
...

Re: wlan0 keeps deauthenticating DEAUTH_LEAVING about every minute

[Larry Finger]

On 03/24/2017 08:32 PM, Dennis New wrote:
> Ever since I upgraded to the 4.10 kernels (I don't think this behavior
> existed in the 4.8 series), after I startup my laptop (either from cold
> boot, or from standby), my wlan0 interface keeps deauthenticating
>
> 19:24:29 kernel: wlan0: deauthenticating from 00:11:22:33:44:55 by
> local choice (Reason: 3=DEAUTH_LEAVING)
>
> usually exactly 60 seconds after it authenticates/associates (to my
> open wifi access point), but not always 60 seconds after -- sometimes
> it happens in less than 60 seconds. Although, if it somehow manages to
> pass the 60 second mark without deauthenticating, it remains stable --
> unless I decide to /etc/init.d/net.wlan0 restart it :s. I'm not sure
> what makes makes the deauthentications suddenly stop, but after various
> incantations and module unloading/reloading and a fair amount of
> cursing, or possibly just waiting some random amount of time, the
> problem goes away for the day ... and returns the next day when I boot
> up again, and I have to go through this torturous process all over
> again, of praying and restarting my wlan0 interface.

When you file a bug report such as this, you need to provide information 
regarding what specific card you have. The appropriate stanza from "lspci -nn" 
has that information.

I do not normally run a b43 wireless NIC, but I did pull out an ancient laptop 
that uses the PCMCIA version of a BCM4318 with PCI ID of 14e4:4318. Running 
kernel 4.10.0, I do see periodic drops. My period is 120 sec and the drop is a 
reason 7, not reason 3 as you see. Another difference is that I see the drops 
with kernel 4.8.0 as well. With the earlier kernel, the drop period is closer to 
60 sec, but it is not as regular. I will be checking even earlier kernels to see 
if I can find a "good" value for bisection.

Larry

Re: wlan0 keeps deauthenticating DEAUTH_LEAVING about every minute

[Dennis New]

On Sun, 26 Mar 2017 11:00:12 -0500, Larry Finger wrote:
> ...  provide information regarding what specific card you have. The
> appropriate stanza from "lspci -nn" has that information.
> 
> I do not normally run a b43 wireless NIC, but I did pull out an
> ancient laptop that uses the PCMCIA version of a BCM4318 with PCI ID
> of 14e4:4318. Running kernel 4.10.0, I do see periodic drops. My
> period is 120 sec and the drop is a reason 7, not reason 3 as you
> see. Another difference is that I see the drops with kernel 4.8.0 as
> well. With the earlier kernel, the drop period is closer to 60 sec,
> but it is not as regular.

Huh. I also have that BCM4318 card, but not PCMCIA.

06:02.0 Network controller [0280]: Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller [14e4:4318] (rev 02)
        Subsystem: AMBIT Microsystem Corp. Aspire 3022WLMi, 5024WLMi, 5020 [1468:0311]
        Flags: bus master, fast devsel, latency 64, IRQ 9
        Memory at c0304000 (32-bit, non-prefetchable) [size=8K]
        Kernel driver in use: b43-pci-bridge

These past few days I seem to have had some "success" by simply
putting a 60 second sleep in my bootup scripts before bringing up
my wlan0 interface. (Ie. I haven't been getting any deauths after
doing this.)

Re: wlan0 keeps deauthenticating DEAUTH_LEAVING about every minute

[Arend Van Spriel]

On 26-3-2017 19:43, Dennis New wrote:
> On Sun, 26 Mar 2017 11:00:12 -0500, Larry Finger wrote:
>> ...  provide information regarding what specific card you have. The
>> appropriate stanza from "lspci -nn" has that information.
>>
>> I do not normally run a b43 wireless NIC, but I did pull out an
>> ancient laptop that uses the PCMCIA version of a BCM4318 with PCI ID
>> of 14e4:4318. Running kernel 4.10.0, I do see periodic drops. My
>> period is 120 sec and the drop is a reason 7, not reason 3 as you
>> see. Another difference is that I see the drops with kernel 4.8.0 as
>> well. With the earlier kernel, the drop period is closer to 60 sec,
>> but it is not as regular.
> 
> Huh. I also have that BCM4318 card, but not PCMCIA.
> 
> 06:02.0 Network controller [0280]: Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller [14e4:4318] (rev 02)
>         Subsystem: AMBIT Microsystem Corp. Aspire 3022WLMi, 5024WLMi, 5020 [1468:0311]
>         Flags: bus master, fast devsel, latency 64, IRQ 9
>         Memory at c0304000 (32-bit, non-prefetchable) [size=8K]
>         Kernel driver in use: b43-pci-bridge
> 
> These past few days I seem to have had some "success" by simply
> putting a 60 second sleep in my bootup scripts before bringing up
> my wlan0 interface. (Ie. I haven't been getting any deauths after
> doing this.)

Interesting. I assume you are using wpa_supplicant so can you make a
supplicant log of that with and without the 60 second sleep.

Regards,
Arend

Re: wlan0 keeps deauthenticating DEAUTH_LEAVING about every minute

[Dennis New]

On Sun, 26 Mar 2017 20:47:41 +0200, Arend Van Spriel wrote:
> 
> 
> On 26-3-2017 19:43, Dennis New wrote:
> > On Sun, 26 Mar 2017 11:00:12 -0500, Larry Finger wrote:
> >> ...  provide information regarding what specific card you have. The
> >> appropriate stanza from "lspci -nn" has that information.
> >>
> >> I do not normally run a b43 wireless NIC, but I did pull out an
> >> ancient laptop that uses the PCMCIA version of a BCM4318 with PCI
> >> ID of 14e4:4318. Running kernel 4.10.0, I do see periodic drops. My
> >> period is 120 sec and the drop is a reason 7, not reason 3 as you
> >> see. Another difference is that I see the drops with kernel 4.8.0
> >> as well. With the earlier kernel, the drop period is closer to 60
> >> sec, but it is not as regular.
> > 
> > Huh. I also have that BCM4318 card, but not PCMCIA.
> > 
> > 06:02.0 Network controller [0280]: Broadcom Corporation BCM4318
> > [AirForce One 54g] 802.11g Wireless LAN Controller [14e4:4318] (rev
> > 02) Subsystem: AMBIT Microsystem Corp. Aspire 3022WLMi, 5024WLMi,
> > 5020 [1468:0311] Flags: bus master, fast devsel, latency 64, IRQ 9
> > Memory at c0304000 (32-bit, non-prefetchable) [size=8K] Kernel
> > driver in use: b43-pci-bridge
> > 
> > These past few days I seem to have had some "success" by simply
> > putting a 60 second sleep in my bootup scripts before bringing up
> > my wlan0 interface. (Ie. I haven't been getting any deauths after
> > doing this.)
> 
> Interesting. I assume you are using wpa_supplicant so can you make a
> supplicant log of that with and without the 60 second sleep.

The same thing happens even without wpa_supplicant. Simply doing "iw
wlan0 connect BlablaAP" .... it will still mysteriously deauthenticate
after a minute (usually).

Re: wlan0 keeps deauthenticating DEAUTH_LEAVING about every minute

[Arend Van Spriel]

On 26-3-2017 20:51, Dennis New wrote:
> On Sun, 26 Mar 2017 20:47:41 +0200, Arend Van Spriel wrote:
>>
>>
>> On 26-3-2017 19:43, Dennis New wrote:
>>> On Sun, 26 Mar 2017 11:00:12 -0500, Larry Finger wrote:
>>>> ...  provide information regarding what specific card you have. The
>>>> appropriate stanza from "lspci -nn" has that information.
>>>>
>>>> I do not normally run a b43 wireless NIC, but I did pull out an
>>>> ancient laptop that uses the PCMCIA version of a BCM4318 with PCI
>>>> ID of 14e4:4318. Running kernel 4.10.0, I do see periodic drops. My
>>>> period is 120 sec and the drop is a reason 7, not reason 3 as you
>>>> see. Another difference is that I see the drops with kernel 4.8.0
>>>> as well. With the earlier kernel, the drop period is closer to 60
>>>> sec, but it is not as regular.
>>>
>>> Huh. I also have that BCM4318 card, but not PCMCIA.
>>>
>>> 06:02.0 Network controller [0280]: Broadcom Corporation BCM4318
>>> [AirForce One 54g] 802.11g Wireless LAN Controller [14e4:4318] (rev
>>> 02) Subsystem: AMBIT Microsystem Corp. Aspire 3022WLMi, 5024WLMi,
>>> 5020 [1468:0311] Flags: bus master, fast devsel, latency 64, IRQ 9
>>> Memory at c0304000 (32-bit, non-prefetchable) [size=8K] Kernel
>>> driver in use: b43-pci-bridge
>>>
>>> These past few days I seem to have had some "success" by simply
>>> putting a 60 second sleep in my bootup scripts before bringing up
>>> my wlan0 interface. (Ie. I haven't been getting any deauths after
>>> doing this.)
>>
>> Interesting. I assume you are using wpa_supplicant so can you make a
>> supplicant log of that with and without the 60 second sleep.
> 
> The same thing happens even without wpa_supplicant. Simply doing "iw
> wlan0 connect BlablaAP" .... it will still mysteriously deauthenticate
> after a minute (usually).

Ok. I stop my train of thoughts right there. The log you sent earlier
was partial, right? Do you have complete dmesg of the first couple of
minutes after booting.

Regards,
Arend

Re: wlan0 keeps deauthenticating DEAUTH_LEAVING about every minute

[Johannes Berg]

On Fri, 2017-03-24 at 21:32 -0400, Dennis New wrote:
> Ever since I upgraded to the 4.10 kernels (I don't think this
> behavior existed in the 4.8 series), after I startup my laptop
> (either from cold boot, or from standby), my wlan0 interface keeps
> deauthenticating

> ...
> 19:23:29 kernel: wlan0: authenticate with 00:11:22:33:44:55
> 19:23:29 kernel: ------------[ cut here ]------------
> 19:23:29 kernel: WARNING: CPU: 0 PID: 18925 at
> net/mac80211/mlme.c:287 ieee80211_determine_chantype+0x12e/0x380

This is already indicating a severe problem. I don't know how you end
up in this situation with b43, since that doesn't have any regulatory
magic afaict.

> 19:23:29 kernel: wlan0: associated
> 
> 19:24:29 kernel: wlan0: deauthenticating from 00:11:22:33:44:55 by
> local choice (Reason: 3=DEAUTH_LEAVING)
> 

I'm convinced that this comes from reg_check_channels().

The above WARN_ON() already told you that the channel was considered
invalid.

Do you know what channel your AP is on? Perhaps show the output of "iw
wlan0 scan dump" while it's connected (you have 60 seconds :P)

Can you please show the output of "iw list" and "iw phy0 channels"?

johannes

Re: wlan0 keeps deauthenticating DEAUTH_LEAVING about every minute

[Arend Van Spriel]

On 29-3-2017 9:34, Johannes Berg wrote:
> On Fri, 2017-03-24 at 21:32 -0400, Dennis New wrote:
>> Ever since I upgraded to the 4.10 kernels (I don't think this
>> behavior existed in the 4.8 series), after I startup my laptop
>> (either from cold boot, or from standby), my wlan0 interface keeps
>> deauthenticating
> 
>> ...
>> 19:23:29 kernel: wlan0: authenticate with 00:11:22:33:44:55
>> 19:23:29 kernel: ------------[ cut here ]------------
>> 19:23:29 kernel: WARNING: CPU: 0 PID: 18925 at
>> net/mac80211/mlme.c:287 ieee80211_determine_chantype+0x12e/0x380

284	while (!cfg80211_chandef_usable(sdata->local->hw.wiphy, chandef,
285					tracking ? 0 :
286					   IEEE80211_CHAN_DISABLED)) {
287		if (WARN_ON(chandef->width == NL80211_CHAN_WIDTH_20_NOHT)) {
288			ret = IEEE80211_STA_DISABLE_HT |
289			      IEEE80211_STA_DISABLE_VHT;
290			break;
291		}

> This is already indicating a severe problem. I don't know how you end
> up in this situation with b43, since that doesn't have any regulatory
> magic afaict.

The only way this WARN_ON can kick in is below so may be interesting to
log the three variables checked in 'if' statement.

161	chandef->chan = channel;
162	chandef->width = NL80211_CHAN_WIDTH_20_NOHT;
163	chandef->center_freq1 = channel->center_freq;
164	chandef->center_freq2 = 0;
165
166	if (!ht_cap || !ht_oper || !sta_ht_cap.ht_supported) {
167		ret = IEEE80211_STA_DISABLE_HT | IEEE80211_STA_DISABLE_VHT;
168		goto out;
169	}
170
171	chandef->width = NL80211_CHAN_WIDTH_20;

>> 19:23:29 kernel: wlan0: associated
>>
>> 19:24:29 kernel: wlan0: deauthenticating from 00:11:22:33:44:55 by
>> local choice (Reason: 3=DEAUTH_LEAVING)
>>
> 
> I'm convinced that this comes from reg_check_channels().
> 
> The above WARN_ON() already told you that the channel was considered
> invalid.
> 
> Do you know what channel your AP is on? Perhaps show the output of "iw
> wlan0 scan dump" while it's connected (you have 60 seconds :P)
> 
> Can you please show the output of "iw list" and "iw phy0 channels"?

Could it be a radar channel and it's waiting for CAC timeout or whatever
the term is ;-) ?

Regards,
Arend

Re: wlan0 keeps deauthenticating DEAUTH_LEAVING about every minute

[Johannes Berg]

> > > 19:23:29 kernel: wlan0: authenticate with 00:11:22:33:44:55
> > > 19:23:29 kernel: ------------[ cut here ]------------
> > > 19:23:29 kernel: WARNING: CPU: 0 PID: 18925 at
> > > net/mac80211/mlme.c:287 ieee80211_determine_chantype+0x12e/0x380
> 
> 284	while (!cfg80211_chandef_usable(sdata->local->hw.wiphy,
> chandef,
> 285					tracking ? 0 :
> 286					   IEEE80211_CHAN_DISABLED
> )) {
> 287		if (WARN_ON(chandef->width ==
> NL80211_CHAN_WIDTH_20_NOHT)) {
> 288			ret = IEEE80211_STA_DISABLE_HT |
> 289			      IEEE80211_STA_DISABLE_VHT;
> 290			break;
> 291		}
> 
> > This is already indicating a severe problem. I don't know how you
> > end
> > up in this situation with b43, since that doesn't have any
> > regulatory
> > magic afaict.
> 
> The only way this WARN_ON can kick in is below so may be interesting
> to log the three variables checked in 'if' statement.

Yeah we should probably extend the WARN_ON() to a WARN() with that
information.

> Could it be a radar channel and it's waiting for CAC timeout or
> whatever the term is ;-) ?

No. Not even tongue-in-cheek :-)
This code was designed for regulatory changes, but the WARN_ON()
indicates that we got connected on a channel that we think isn't
actually usable. We quite possibly should reject that connection there,
but it seems to me it should've been rejected elsewhere already...?

johannes

Re: wlan0 keeps deauthenticating DEAUTH_LEAVING about every minute

[Arend Van Spriel]

On 29-3-2017 9:46, Johannes Berg wrote:
> 
>>>> 19:23:29 kernel: wlan0: authenticate with 00:11:22:33:44:55
>>>> 19:23:29 kernel: ------------[ cut here ]------------
>>>> 19:23:29 kernel: WARNING: CPU: 0 PID: 18925 at
>>>> net/mac80211/mlme.c:287 ieee80211_determine_chantype+0x12e/0x380
>>
>> 284	while (!cfg80211_chandef_usable(sdata->local->hw.wiphy,
>> chandef,
>> 285					tracking ? 0 :
>> 286					   IEEE80211_CHAN_DISABLED
>> )) {
>> 287		if (WARN_ON(chandef->width ==
>> NL80211_CHAN_WIDTH_20_NOHT)) {
>> 288			ret = IEEE80211_STA_DISABLE_HT |
>> 289			      IEEE80211_STA_DISABLE_VHT;
>> 290			break;
>> 291		}
>>
>>> This is already indicating a severe problem. I don't know how you
>>> end
>>> up in this situation with b43, since that doesn't have any
>>> regulatory
>>> magic afaict.
>>
>> The only way this WARN_ON can kick in is below so may be interesting
>> to log the three variables checked in 'if' statement.
> 
> Yeah we should probably extend the WARN_ON() to a WARN() with that
> information.
> 
>> Could it be a radar channel and it's waiting for CAC timeout or
>> whatever the term is ;-) ?
> 
> No. Not even tongue-in-cheek :-)
> This code was designed for regulatory changes, but the WARN_ON()
> indicates that we got connected on a channel that we think isn't
> actually usable. We quite possibly should reject that connection there,
> but it seems to me it should've been rejected elsewhere already...?

But this is prior to connection, right? This warning happens upon
authenticate. So in nl80211_authenticate() we do:

chan = nl80211_get_valid_chan(&rdev->wiphy,
			      info->attrs[NL80211_ATTR_WIPHY_FREQ]);

and in cfg80211_mlme_auth():

req.bss = cfg80211_get_bss(&rdev->wiphy, chan, bssid, ssid, ssid_len,
			   IEEE80211_BSS_TYPE_ESS,
			   IEEE80211_PRIVACY_ANY);

After that the chain is:

ieee80211_mgd_auth() ->
	ieee80211_prep_connection() ->
		ieee80211_prep_channel() ->
			ieee80211_determine_chantype()

Regards,
Arend

Re: wlan0 keeps deauthenticating DEAUTH_LEAVING about every minute

[Johannes Berg]

> > This code was designed for regulatory changes, but the WARN_ON()
> > indicates that we got connected on a channel that we think isn't
> > actually usable. We quite possibly should reject that connection
> > there, but it seems to me it should've been rejected elsewhere
> > already...?
> 
> But this is prior to connection, right? This warning happens upon
> authenticate.

Yeah the warning happens in authentication.

> So in nl80211_authenticate() we do:
> 
> chan = nl80211_get_valid_chan(&rdev->wiphy,
> 			      info->attrs[NL80211_ATTR_WIPHY_FREQ]);
> 
> and in cfg80211_mlme_auth():
> 
> req.bss = cfg80211_get_bss(&rdev->wiphy, chan, bssid, ssid, ssid_len,
> 			   IEEE80211_BSS_TYPE_ESS,
> 			   IEEE80211_PRIVACY_ANY);

That might not be what's going on - the OP said he was getting this
with iw, which doesn't go through nl80211_authenticate() but
nl80211_connect().

> After that the chain is:
> 
> ieee80211_mgd_auth() ->
> 	ieee80211_prep_connection() ->
> 		ieee80211_prep_channel() ->
> 			ieee80211_determine_chantype()

And somehow that determines that even a 20MHz no-HT channel isn't
valid.

johannes

Re: wlan0 keeps deauthenticating DEAUTH_LEAVING about every minute

[Dennis New]

On Wed, 29 Mar 2017 09:34:50 +0200, Johannes Berg wrote:
> On Fri, 2017-03-24 at 21:32 -0400, Dennis New wrote:
> > Ever since I upgraded to the 4.10 kernels (I don't think this
> > behavior existed in the 4.8 series), after I startup my laptop
> > (either from cold boot, or from standby), my wlan0 interface keeps
> > deauthenticating
> 
> > ...
> > 19:23:29 kernel: wlan0: authenticate with 00:11:22:33:44:55
> > 19:23:29 kernel: ------------[ cut here ]------------
> > 19:23:29 kernel: WARNING: CPU: 0 PID: 18925 at
> > net/mac80211/mlme.c:287 ieee80211_determine_chantype+0x12e/0x380
> 
> This is already indicating a severe problem. I don't know how you end
> up in this situation with b43, since that doesn't have any regulatory
> magic afaict.
> 
> > 19:23:29 kernel: wlan0: associated
> > 
> > 19:24:29 kernel: wlan0: deauthenticating from 00:11:22:33:44:55 by
> > local choice (Reason: 3=DEAUTH_LEAVING)
> 
> I'm convinced that this comes from reg_check_channels().
> 
> The above WARN_ON() already told you that the channel was considered
> invalid.
> 
> Do you know what channel your AP is on?

6

> Perhaps show the output of "iw wlan0 scan dump" while it's
connected (you have 60 seconds :P)

I have been having stable connections for the past few days,
simply by putting a 60 second sleep before starting my wlan0. Although
if I /etc/init.d/net.wlan0 restart it (without the delay), it will
still do this deauth'ing.


> Can you please show the output of "iw list" and "iw phy0 channels"?

"iw phy7 channels":
Band 1:
	* 2412 MHz [1] 
	  Maximum TX power: 20.0 dBm
	  Channel widths:
	* 2417 MHz [2] 
	  Maximum TX power: 20.0 dBm
	  Channel widths:
	* 2422 MHz [3] 
	  Maximum TX power: 20.0 dBm
	  Channel widths:
	* 2427 MHz [4] 
	  Maximum TX power: 20.0 dBm
	  Channel widths:
	* 2432 MHz [5] 
	  Maximum TX power: 20.0 dBm
	  Channel widths:
	* 2437 MHz [6] 
	  Maximum TX power: 20.0 dBm
	  Channel widths:
	* 2442 MHz [7] 
	  Maximum TX power: 20.0 dBm
	  Channel widths:
	* 2447 MHz [8] 
	  Maximum TX power: 20.0 dBm
	  Channel widths:
	* 2452 MHz [9] 
	  Maximum TX power: 20.0 dBm
	  Channel widths:
	* 2457 MHz [10] 
	  Maximum TX power: 20.0 dBm
	  Channel widths:
	* 2462 MHz [11] 
	  Maximum TX power: 20.0 dBm
	  Channel widths:
	* 2467 MHz [12] 
	  Maximum TX power: 20.0 dBm
	  No IR
	  Channel widths:
	* 2472 MHz [13] 
	  Maximum TX power: 20.0 dBm
	  No IR
	  Channel widths:
	* 2484 MHz [14] 
	  Maximum TX power: 20.0 dBm
	  No IR
	  Channel widths: 20MHz


"iw list":
Wiphy phy7
	max # scan SSIDs: 4
	max scan IEs length: 2285 bytes
	max # sched scan SSIDs: 0
	max # match sets: 0
	max # scan plans: 1
	max scan plan interval: -1
	max scan plan iterations: 0
	Retry short limit: 7
	Retry long limit: 4
	Coverage class: 0 (up to 0m)
	Device supports RSN-IBSS.
	Supported Ciphers:
		* WEP40 (00-0f-ac:1)
		* WEP104 (00-0f-ac:5)
		* TKIP (00-0f-ac:2)
		* CCMP-128 (00-0f-ac:4)
		* CCMP-256 (00-0f-ac:10)
		* GCMP-128 (00-0f-ac:8)
		* GCMP-256 (00-0f-ac:9)
	Available Antennas: TX 0 RX 0
	Supported interface modes:
		 * IBSS
		 * managed
		 * AP
		 * AP/VLAN
		 * monitor
	Band 1:
		Bitrates (non-HT):
			* 1.0 Mbps
			* 2.0 Mbps (short preamble supported)
			* 5.5 Mbps (short preamble supported)
			* 11.0 Mbps (short preamble supported)
			* 6.0 Mbps
			* 9.0 Mbps
			* 12.0 Mbps
			* 18.0 Mbps
			* 24.0 Mbps
			* 36.0 Mbps
			* 48.0 Mbps
			* 54.0 Mbps
		Frequencies:
			* 2412 MHz [1] (20.0 dBm)
			* 2417 MHz [2] (20.0 dBm)
			* 2422 MHz [3] (20.0 dBm)
			* 2427 MHz [4] (20.0 dBm)
			* 2432 MHz [5] (20.0 dBm)
			* 2437 MHz [6] (20.0 dBm)
			* 2442 MHz [7] (20.0 dBm)
			* 2447 MHz [8] (20.0 dBm)
			* 2452 MHz [9] (20.0 dBm)
			* 2457 MHz [10] (20.0 dBm)
			* 2462 MHz [11] (20.0 dBm)
			* 2467 MHz [12] (20.0 dBm) (no IR)
			* 2472 MHz [13] (20.0 dBm) (no IR)
			* 2484 MHz [14] (20.0 dBm) (no IR)
	Supported commands:
		 * new_interface
		 * set_interface
		 * new_key
		 * start_ap
		 * new_station
		 * set_bss
		 * authenticate
		 * associate
		 * deauthenticate
		 * disassociate
		 * join_ibss
		 * set_tx_bitrate_mask
		 * frame
		 * frame_wait_cancel
		 * set_wiphy_netns
		 * set_channel
		 * set_wds_peer
		 * probe_client
		 * set_noack_map
		 * register_beacons
		 * start_p2p_device
		 * set_mcast_rate
		 * connect
		 * disconnect
		 * set_qos_map
	Supported TX frame types:
		 * IBSS: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
		 * managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
		 * AP: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
		 * AP/VLAN: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
		 * mesh point: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
		 * P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
		 * P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
		 * P2P-device: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
	Supported RX frame types:
		 * IBSS: 0x40 0xb0 0xc0 0xd0
		 * managed: 0x40 0xd0
		 * AP: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
		 * AP/VLAN: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
		 * mesh point: 0xb0 0xc0 0xd0
		 * P2P-client: 0x40 0xd0
		 * P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
		 * P2P-device: 0x40 0xd0
	software interface modes (can always be added):
		 * AP/VLAN
		 * monitor
	interface combinations are not supported
	HT Capability overrides:
		 * MCS: ff ff ff ff ff ff ff ff ff ff
		 * maximum A-MSDU length
		 * supported channel width
		 * short GI for 40 MHz
		 * max A-MPDU length exponent
		 * min MPDU start spacing
	Device supports TX status socket option.
	Device supports HT-IBSS.
	Device supports SAE with AUTHENTICATE command
	Device supports low priority scan.
	Device supports scan flush.
	Device supports AP scan.
	Device supports per-vif TX power setting
	Driver supports full state transitions for AP/GO clients
	Driver supports a userspace MPM
	Device supports configuring vdev MAC-addr on create.

Re: wlan0 keeps deauthenticating DEAUTH_LEAVING about every minute

[Johannes Berg]

On Wed, 2017-03-29 at 06:28 -0400, Dennis New wrote:
> On Wed, 29 Mar 2017 09:34:50 +0200, Johannes Berg wrote:
> > On Fri, 2017-03-24 at 21:32 -0400, Dennis New wrote:
> > > Ever since I upgraded to the 4.10 kernels (I don't think this
> > > behavior existed in the 4.8 series), after I startup my laptop
> > > (either from cold boot, or from standby), my wlan0 interface
> > > keeps
> > > deauthenticating
> > > ...
> > > 19:23:29 kernel: wlan0: authenticate with 00:11:22:33:44:55
> > > 19:23:29 kernel: ------------[ cut here ]------------
> > > 19:23:29 kernel: WARNING: CPU: 0 PID: 18925 at
> > > net/mac80211/mlme.c:287 ieee80211_determine_chantype+0x12e/0x380
> > 
> > This is already indicating a severe problem. I don't know how you
> > end
> > up in this situation with b43, since that doesn't have any
> > regulatory
> > magic afaict.
> > 
> > > 19:23:29 kernel: wlan0: associated
> > > 
> > > 19:24:29 kernel: wlan0: deauthenticating from 00:11:22:33:44:55
> > > by
> > > local choice (Reason: 3=DEAUTH_LEAVING)
> > 
> > I'm convinced that this comes from reg_check_channels().
> > 
> > The above WARN_ON() already told you that the channel was
> > considered
> > invalid.
> > 
> > Do you know what channel your AP is on?
> 
> 6
> 
> > Perhaps show the output of "iw wlan0 scan dump" while it's
> 
> connected (you have 60 seconds :P)
> 
> I have been having stable connections for the past few days,
> simply by putting a 60 second sleep before starting my wlan0.
> Although
> if I /etc/init.d/net.wlan0 restart it (without the delay), it will
> still do this deauth'ing.

Very strange.

> 	* 2437 MHz [6] 
> 	  Maximum TX power: 20.0 dBm
> 	  Channel widths:

That's quite odd, why isn't it listing any possible channel widths?!

I get:
	* 2437 MHz [6] 
	  Maximum TX power: 15.0 dBm
	  Channel widths: 20MHz HT40- HT40+

What's "iw reg get"?

johannes

Re: wlan0 keeps deauthenticating DEAUTH_LEAVING about every minute

[Arend Van Spriel]

Op 29 mrt. 2017 13:51 schreef "Johannes Berg" <johannes@sipsolutions.net
<mailto:johannes@sipsolutions.net>>:
>
> On Wed, 2017-03-29 at 06:28 -0400, Dennis New wrote:
> > On Wed, 29 Mar 2017 09:34:50 +0200, Johannes Berg wrote:
> > > On Fri, 2017-03-24 at 21:32 -0400, Dennis New wrote:
> > > > Ever since I upgraded to the 4.10 kernels (I don't think this
> > > > behavior existed in the 4.8 series), after I startup my laptop
> > > > (either from cold boot, or from standby), my wlan0 interface
> > > > keeps
> > > > deauthenticating
> > > > ...
> > > > 19:23:29 kernel: wlan0: authenticate with 00:11:22:33:44:55
> > > > 19:23:29 kernel: ------------[ cut here ]------------
> > > > 19:23:29 kernel: WARNING: CPU: 0 PID: 18925 at
> > > > net/mac80211/mlme.c:287 ieee80211_determine_chantype+0x12e/0x380
> > >
> > > This is already indicating a severe problem. I don't know how you
> > > end
> > > up in this situation with b43, since that doesn't have any
> > > regulatory
> > > magic afaict.
> > >
> > > > 19:23:29 kernel: wlan0: associated
> > > >
> > > > 19:24:29 kernel: wlan0: deauthenticating from 00:11:22:33:44:55
> > > > by
> > > > local choice (Reason: 3=DEAUTH_LEAVING)
> > >
> > > I'm convinced that this comes from reg_check_channels().
> > >
> > > The above WARN_ON() already told you that the channel was
> > > considered
> > > invalid.
> > >
> > > Do you know what channel your AP is on?
> >
> > 6
> >
> > > Perhaps show the output of "iw wlan0 scan dump" while it's
> >
> > connected (you have 60 seconds :P)
> >
> > I have been having stable connections for the past few days,
> > simply by putting a 60 second sleep before starting my wlan0.
> > Although
> > if I /etc/init.d/net.wlan0 restart it (without the delay), it will
> > still do this deauth'ing.
>
> Very strange.
>
> >       * 2437 MHz [6] 
> >         Maximum TX power: 20.0 dBm
> >         Channel widths:
>
> That's quite odd, why isn't it listing any possible channel widths?!

Is iw not handling 20MHZ_NOHT definition?

Regards,

Arend

Re: wlan0 keeps deauthenticating DEAUTH_LEAVING about every minute

[Johannes Berg]

On Wed, 2017-03-29 at 20:58 +0200, Arend Van Spriel wrote:
> 
> > >       * 2437 MHz [6] 
> > >         Maximum TX power: 20.0 dBm
> > >         Channel widths:
> > 
> > That's quite odd, why isn't it listing any possible channel
> > widths?!
> 
> Is iw not handling 20MHZ_NOHT definition?

But iw is printing "20MHz" when NL80211_FREQUENCY_ATTR_NO_20MHZ isn't
set.

johannes

Re: wlan0 keeps deauthenticating DEAUTH_LEAVING about every minute

[Dennis New]

On Wed, 29 Mar 2017 13:49:06 +0200, Johannes Berg wrote:
> On Wed, 2017-03-29 at 06:28 -0400, Dennis New wrote:
> > On Wed, 29 Mar 2017 09:34:50 +0200, Johannes Berg wrote:
> > > On Fri, 2017-03-24 at 21:32 -0400, Dennis New wrote:
> > > > Ever since I upgraded to the 4.10 kernels (I don't think this
> > > > behavior existed in the 4.8 series), after I startup my laptop
> > > > (either from cold boot, or from standby), my wlan0 interface
> > > > keeps
> > > > deauthenticating
> > > > ...
> > > > 19:23:29 kernel: wlan0: authenticate with 00:11:22:33:44:55
> > > > 19:23:29 kernel: ------------[ cut here ]------------
> > > > 19:23:29 kernel: WARNING: CPU: 0 PID: 18925 at
> > > > net/mac80211/mlme.c:287 ieee80211_determine_chantype+0x12e/0x380
> > > 
> > > This is already indicating a severe problem. I don't know how you
> > > end
> > > up in this situation with b43, since that doesn't have any
> > > regulatory
> > > magic afaict.
> > > 
> > > > 19:23:29 kernel: wlan0: associated
> > > > 
> > > > 19:24:29 kernel: wlan0: deauthenticating from 00:11:22:33:44:55
> > > > by
> > > > local choice (Reason: 3=DEAUTH_LEAVING)
> > > 
> > > I'm convinced that this comes from reg_check_channels().
> > > 
> > > The above WARN_ON() already told you that the channel was
> > > considered
> > > invalid.
> > > 
> > > Do you know what channel your AP is on?
> > 
> > 6
> > 
> > > Perhaps show the output of "iw wlan0 scan dump" while it's
> > 
> > connected (you have 60 seconds :P)
> > 
> > I have been having stable connections for the past few days,
> > simply by putting a 60 second sleep before starting my wlan0.
> > Although
> > if I /etc/init.d/net.wlan0 restart it (without the delay), it will
> > still do this deauth'ing.
> 
> Very strange.
> 
> > 	* 2437 MHz [6] 
> > 	  Maximum TX power: 20.0 dBm
> > 	  Channel widths:
> 
> That's quite odd, why isn't it listing any possible channel widths?!
> 
> I get:
> 	* 2437 MHz [6] 
> 	  Maximum TX power: 15.0 dBm
> 	  Channel widths: 20MHz HT40- HT40+
> 
> What's "iw reg get"?

global
country 00: DFS-UNSET
        (2402 - 2472 @ 92), (N/A, 20), (N/A)
        (2457 - 2482 @ 92), (N/A, 20), (N/A), PASSIVE-SCAN
        (2474 - 2494 @ 20), (N/A, 20), (N/A), NO-OFDM, PASSIVE-SCAN
        (5170 - 5250 @ 160), (N/A, 20), (N/A), PASSIVE-SCAN
        (5250 - 5330 @ 160), (N/A, 20), (0 ms), DFS, PASSIVE-SCAN
        (5490 - 5730 @ 160), (N/A, 20), (0 ms), DFS, PASSIVE-SCAN
        (5735 - 5835 @ 80), (N/A, 20), (N/A), PASSIVE-SCAN
        (57240 - 63720 @ 2160), (N/A, 0), (N/A)

Re: wlan0 keeps deauthenticating DEAUTH_LEAVING about every minute

[Larry Finger]

On 03/29/2017 02:36 PM, Dennis New wrote:
> global
> country 00: DFS-UNSET
>         (2402 - 2472 @ 92), (N/A, 20), (N/A)
>         (2457 - 2482 @ 92), (N/A, 20), (N/A), PASSIVE-SCAN
>         (2474 - 2494 @ 20), (N/A, 20), (N/A), NO-OFDM, PASSIVE-SCAN
>         (5170 - 5250 @ 160), (N/A, 20), (N/A), PASSIVE-SCAN
>         (5250 - 5330 @ 160), (N/A, 20), (0 ms), DFS, PASSIVE-SCAN
>         (5490 - 5730 @ 160), (N/A, 20), (0 ms), DFS, PASSIVE-SCAN
>         (5735 - 5835 @ 80), (N/A, 20), (N/A), PASSIVE-SCAN
>         (57240 - 63720 @ 2160), (N/A, 0), (N/A)

That "country 00" looks like commit 1d2a6a5e4bf2921531071fcff8538623dce74efa
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Wed Mar 22 16:08:33 2017 +0100

     genetlink: fix counting regression on ctrl_dumpfamily()

Larry

Re: wlan0 keeps deauthenticating DEAUTH_LEAVING about every minute

[Arend Van Spriel]

On 29-3-2017 22:15, Larry Finger wrote:
> On 03/29/2017 02:36 PM, Dennis New wrote:
>> global
>> country 00: DFS-UNSET
>>         (2402 - 2472 @ 92), (N/A, 20), (N/A)
>>         (2457 - 2482 @ 92), (N/A, 20), (N/A), PASSIVE-SCAN
>>         (2474 - 2494 @ 20), (N/A, 20), (N/A), NO-OFDM, PASSIVE-SCAN
>>         (5170 - 5250 @ 160), (N/A, 20), (N/A), PASSIVE-SCAN
>>         (5250 - 5330 @ 160), (N/A, 20), (0 ms), DFS, PASSIVE-SCAN
>>         (5490 - 5730 @ 160), (N/A, 20), (0 ms), DFS, PASSIVE-SCAN
>>         (5735 - 5835 @ 80), (N/A, 20), (N/A), PASSIVE-SCAN
>>         (57240 - 63720 @ 2160), (N/A, 0), (N/A)
> 
> That "country 00" looks like commit
> 1d2a6a5e4bf2921531071fcff8538623dce74efa
> Author: Stanislaw Gruszka <sgruszka@redhat.com>
> Date:   Wed Mar 22 16:08:33 2017 +0100
> 
>     genetlink: fix counting regression on ctrl_dumpfamily()

I am more confused about "(2402 - 2472 @ 92)". That is some seriously
strange bandwidth :-p

Regards,
Arend