Hello,
After a bisection on the kernel, it seems that a patch is causing a
problem with NetworkManager:
commit 0172bb75073e11a5aa9d8a953bdaefb8709f00c8 ("cfg80211:
use DS or HT operation IEs to determine BSS channel")
The Wifi access points are not listed in the KDE plasma widget and it
won't even connect to the saved ones even if they are in range.
There is a fix though: running "iwlist wlan0 scan" twice as root (which
properly lists APs in reach) and the second time must be run about two
seconds after the first time.
Then NetworkManager lists the access points and connects to the
prefered one if possible (normal behavior).
This also happens with nm-applet in Gnome.
The hardware is: 14e4:4315 (Network controller: Broadcom Corporation
BCM4312 802.11b/g LP-PHY (rev 01)) on an Intel Core i3 M370 CPU (64
bits) computer.
The abnormal behaviour is not random, it happens every time.
Detlev Casanova
On Wed, 2013-09-18 at 22:47 +0200, Detlev Casanova wrote:
> Hello,
>
> After a bisection on the kernel, it seems that a patch is causing a
> problem with NetworkManager:
>
> commit 0172bb75073e11a5aa9d8a953bdaefb8709f00c8 ("cfg80211:
> use DS or HT operation IEs to determine BSS channel")
>
> The Wifi access points are not listed in the KDE plasma widget and it
> won't even connect to the saved ones even if they are in range.
>
> There is a fix though: running "iwlist wlan0 scan" twice as root (which
> properly lists APs in reach) and the second time must be run about two
> seconds after the first time.
>
> Then NetworkManager lists the access points and connects to the
> prefered one if possible (normal behavior).
>
> This also happens with nm-applet in Gnome.
>
> The hardware is: 14e4:4315 (Network controller: Broadcom Corporation
> BCM4312 802.11b/g LP-PHY (rev 01)) on an Intel Core i3 M370 CPU (64
> bits) computer.
>
> The abnormal behaviour is not random, it happens every time.
Can you run wpa_supplicant with debugging output? The quick and dirty
way is to:
mv /usr/sbin/wpa_supplicant /
killall -TERM wpa_supplicant
/wpa_supplicant -dddtu
and then wait for the problem to happen, and grab the log output for us
to analyze.
Dan
On Thu, 2013-09-19 at 07:58 +0200, Detlev Casanova wrote:
> Here is the output (attached file for formatting)
Was that from the good case? The bad case would have been more
interesting.
johannes
Le lundi 23 septembre 2013 11:13:49 Dan Williams a ?crit :
> On Sun, 2013-09-22 at 16:20 +0200, Detlev Casanova wrote:
> > Le samedi 21 septembre 2013 22:51:59 Johannes Berg a ?crit :
> > > On Thu, 2013-09-19 at 07:58 +0200, Detlev Casanova wrote:
> > > > Here is the output (attached file for formatting)
> > >
> > > Was that from the good case? The bad case would have been
> >
> > more
> >
> > > interesting.
> >
> > This is both cases. I made another one and here, I can give more
> > details:
> >
> > Network manager is trying to list APs and fails until time
> > 1379858724.386569
>
> Ok, the logs indicate that the driver simply doesn't see any scan
> results:
>
> 1379858724.381522: Received scan results (0 BSSes)
>
> Then 20 seconds later (after the explicit iwlist), it finds some scan
> results:
>
> 1379858746.953924: Received scan results (3 BSSes)
>
> So I'm not sure what's going on here, but I don't think NetworkManager
> is the issue; it's likely in the supplicant's scanning code or in the
> driver itself. NetworkManager asks the supplicant to scan with both the
> wildcard SSID and any hidden-tagged SSID, and the wildcard SSID should
> ensure that all available APs are found.
Yes and the problem is most likely to be in the driver because it doesn't
occur before commit 0172bb75073e11a5aa9d8a953bdaefb8709f00c8 ("cfg80211: use
DS or HT operation IEs to determine BSS channel")
> Johannes, does anything else jump out at you in the logs?
>
> Dan
>
> > The The first "iwlist wlan0 scan" is done juste after the log line
> > (1379858738.682054). It lists the APs in range in the console but
> > not in the Network Manager ui.
> >
> > The second "iwlist wlan0 scan" is done at time 1379858739.802067
> > and APs are being listed in the console and in the Network Manager
> > UI.
> >
> > After that, NM will connect to the acces point with SSID "Maison".
> >
> > It also looks like the listing in Network Manager comes between the
> > moment "iwlist wlan0 scan" is run for the second time and the
> > moment is shows its output on the console.
> >
> > Detlev.
2013/9/18 Detlev Casanova <[email protected]>:
> After a bisection on the kernel, it seems that a patch is causing a
> problem with NetworkManager:
>
> commit 0172bb75073e11a5aa9d8a953bdaefb8709f00c8 ("cfg80211:
> use DS or HT operation IEs to determine BSS channel")
>
> (...)
>
> The hardware is: 14e4:4315 (Network controller: Broadcom Corporation
> BCM4312 802.11b/g LP-PHY (rev 01)) on an Intel Core i3 M370 CPU (64
> bits) computer.
See:
http://www.spinics.net/lists/linux-wireless/msg105359.html
("Scanning regression since "cfg80211: use DS or HT operation IEs to
determine BSS channel"")
It seems that starting with the mentioned commit, b43 doesn't report
any results on the 1st scanning. No idea how this patch affected b43.
Scanning on channel b43 is failing even worse starting with that
commit.
--
Rafał
On Sun, 2013-09-22 at 16:20 +0200, Detlev Casanova wrote:
> Le samedi 21 septembre 2013 22:51:59 Johannes Berg a écrit :
> > On Thu, 2013-09-19 at 07:58 +0200, Detlev Casanova wrote:
> > > Here is the output (attached file for formatting)
> >
> > Was that from the good case? The bad case would have been
> more
> > interesting.
>
> This is both cases. I made another one and here, I can give more
> details:
>
> Network manager is trying to list APs and fails until time
> 1379858724.386569
Ok, the logs indicate that the driver simply doesn't see any scan
results:
1379858724.381522: Received scan results (0 BSSes)
Then 20 seconds later (after the explicit iwlist), it finds some scan
results:
1379858746.953924: Received scan results (3 BSSes)
So I'm not sure what's going on here, but I don't think NetworkManager
is the issue; it's likely in the supplicant's scanning code or in the
driver itself. NetworkManager asks the supplicant to scan with both the
wildcard SSID and any hidden-tagged SSID, and the wildcard SSID should
ensure that all available APs are found.
Johannes, does anything else jump out at you in the logs?
Dan
> The The first "iwlist wlan0 scan" is done juste after the log line
> (1379858738.682054). It lists the APs in range in the console but
> not in the Network Manager ui.
>
> The second "iwlist wlan0 scan" is done at time 1379858739.802067
> and APs are being listed in the console and in the Network Manager
> UI.
>
> After that, NM will connect to the acces point with SSID "Maison".
>
> It also looks like the listing in Network Manager comes between the
> moment "iwlist wlan0 scan" is run for the second time and the
> moment is shows its output on the console.
>
> Detlev.
2013/9/29 Rafał Miłecki <[email protected]>:
> Scanning on channel b43 is failing even worse starting with that
> commit.
s/b43/13/
--
Rafał
Le mercredi 18 septembre 2013 23:16:08 Dan Williams a ?crit :
> On Wed, 2013-09-18 at 22:47 +0200, Detlev Casanova wrote:
> > Hello,
> >
> > After a bisection on the kernel, it seems that a patch is causing
a
> > problem with NetworkManager:
> >
> > commit 0172bb75073e11a5aa9d8a953bdaefb8709f00c8
("cfg80211:
> > use DS or HT operation IEs to determine BSS channel")
> >
> > The Wifi access points are not listed in the KDE plasma widget
and it
> > won't even connect to the saved ones even if they are in range.
> >
> > There is a fix though: running "iwlist wlan0 scan" twice as root
(which
> > properly lists APs in reach) and the second time must be run
about two
> > seconds after the first time.
> >
> > Then NetworkManager lists the access points and connects to
the
> > prefered one if possible (normal behavior).
> >
> > This also happens with nm-applet in Gnome.
> >
> > The hardware is: 14e4:4315 (Network controller: Broadcom
Corporation
> > BCM4312 802.11b/g LP-PHY (rev 01)) on an Intel Core i3 M370
CPU (64
> > bits) computer.
> >
> > The abnormal behaviour is not random, it happens every time.
>
> Can you run wpa_supplicant with debugging output? The quick
and dirty
> way is to:
>
> mv /usr/sbin/wpa_supplicant /
> killall -TERM wpa_supplicant
> /wpa_supplicant -dddtu
>
> and then wait for the problem to happen, and grab the log output
for us
> to analyze.
>
> Dan
Here is the output (attached file for formatting)
Le samedi 21 septembre 2013 22:51:59 Johannes Berg a ?crit :
> On Thu, 2013-09-19 at 07:58 +0200, Detlev Casanova wrote:
> > Here is the output (attached file for formatting)
>
> Was that from the good case? The bad case would have been
more
> interesting.
This is both cases. I made another one and here, I can give more
details:
Network manager is trying to list APs and fails until time
1379858724.386569
The The first "iwlist wlan0 scan" is done juste after the log line
(1379858738.682054). It lists the APs in range in the console but
not in the Network Manager ui.
The second "iwlist wlan0 scan" is done at time 1379858739.802067
and APs are being listed in the console and in the Network Manager
UI.
After that, NM will connect to the acces point with SSID "Maison".
It also looks like the listing in Network Manager comes between the
moment "iwlist wlan0 scan" is run for the second time and the
moment is shows its output on the console.
Detlev.
On Fri, 2013-10-11 at 17:43 +0200, Detlev Casanova wrote:
> > > > > occur before commit 0172bb75073e11a5aa9d8a953bdaefb8709f00c8
> > >
> > > ("cfg80211:
> > > > > use DS or HT operation IEs to determine BSS channel")
> >
> > [...]
> >
> > > I looked into wpa_supplicant and after an upgrade from 0.7.3 to 2.0,
> > > the problem seems to be fixed.
> >
> > Huh, that's odd. Did 0.7.3 use wext driver?
>
> Yes it did.
Hmm. Even taking that into account though I don't really see any
difference.
Maybe you could check if there's any difference in iwlist scan output
before/after the patch (for the affected AP)?
johannes
On Mon, 2013-10-07 at 08:48 +0200, Detlev Casanova wrote:
> > > Yes and the problem is most likely to be in the driver because it
> doesn't
> > > occur before commit 0172bb75073e11a5aa9d8a953bdaefb8709f00c8
> ("cfg80211:
> > > use DS or HT operation IEs to determine BSS channel")
[...]
> I looked into wpa_supplicant and after an upgrade from 0.7.3 to 2.0,
> the problem seems to be fixed.
Huh, that's odd. Did 0.7.3 use wext driver?
johannes
On 10/17/2013 10:38 AM, Johannes Berg wrote:
> On Fri, 2013-10-11 at 17:43 +0200, Detlev Casanova wrote:
>
>>>>>> occur before commit 0172bb75073e11a5aa9d8a953bdaefb8709f00c8
>>>>
>>>> ("cfg80211:
>>>>>> use DS or HT operation IEs to determine BSS channel")
>>>
>>> [...]
>>>
>>>> I looked into wpa_supplicant and after an upgrade from 0.7.3 to 2.0,
>>>> the problem seems to be fixed.
>>>
>>> Huh, that's odd. Did 0.7.3 use wext driver?
>>
>> Yes it did.
>
> Hmm. Even taking that into account though I don't really see any
> difference.
>
> Maybe you could check if there's any difference in iwlist scan output
> before/after the patch (for the affected AP)?
>
> johannes
Not to clog up the channel, but I was running into exactly the same
problem. I expected to see the problem somewhere in the kernel, etc. I
turned on debugging and kernel tracing and saw nothing. The fix for me
is almost identical to the fix that Detlev first described.
However, the problem for me was somewhere else entirely. The access
point was sending out malformed beacon messages that kept it from
showing up.
I *hope* that this helps. However, I hope, at least, this was not a
waste of bits. :-)
Will
>
>
> --
> 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
>
Le lundi 7 octobre 2013 09:40:58 Johannes Berg a ?crit :
> On Mon, 2013-10-07 at 08:48 +0200, Detlev Casanova wrote:
> > > > Yes and the problem is most likely to be in the driver because it
> >
> > doesn't
> >
> > > > occur before commit 0172bb75073e11a5aa9d8a953bdaefb8709f00c8
> >
> > ("cfg80211:
> > > > use DS or HT operation IEs to determine BSS channel")
>
> [...]
>
> > I looked into wpa_supplicant and after an upgrade from 0.7.3 to 2.0,
> > the problem seems to be fixed.
>
> Huh, that's odd. Did 0.7.3 use wext driver?
Yes it did.
On Thu, 2013-10-17 at 12:19 -0400, Will Hawkins wrote:
> Not to clog up the channel, but I was running into exactly the same
> problem. I expected to see the problem somewhere in the kernel, etc. I
> turned on debugging and kernel tracing and saw nothing. The fix for me
> is almost identical to the fix that Detlev first described.
>
> However, the problem for me was somewhere else entirely. The access
> point was sending out malformed beacon messages that kept it from
> showing up.
Any idea how they were malformed? Was there a bad DS IE or so?
johannes
On 10/21/2013 09:06 AM, Johannes Berg wrote:
> On Thu, 2013-10-17 at 12:19 -0400, Will Hawkins wrote:
>
>> Not to clog up the channel, but I was running into exactly the same
>> problem. I expected to see the problem somewhere in the kernel, etc. I
>> turned on debugging and kernel tracing and saw nothing. The fix for me
>> is almost identical to the fix that Detlev first described.
>>
>> However, the problem for me was somewhere else entirely. The access
>> point was sending out malformed beacon messages that kept it from
>> showing up.
>
> Any idea how they were malformed? Was there a bad DS IE or so?
I'm not enough of an expert to answer your question definitively.
However, I've included the malformed packet as an attachment. I've
stripped identifying information (hopefully), but think that this will
still give you information to answer the question.
If this is not sufficient, please let me know! I'm glad to help however
I can.
Will
>
> johannes
>
>
On Sun, 2013-09-29 at 21:29 +0200, Detlev Casanova wrote:
> > So I'm not sure what's going on here, but I don't think NetworkManager
> > is the issue; it's likely in the supplicant's scanning code or in the
> > driver itself. NetworkManager asks the supplicant to scan with both the
> > wildcard SSID and any hidden-tagged SSID, and the wildcard SSID should
> > ensure that all available APs are found.
>
> Yes and the problem is most likely to be in the driver because it doesn't
> occur before commit 0172bb75073e11a5aa9d8a953bdaefb8709f00c8 ("cfg80211: use
> DS or HT operation IEs to determine BSS channel")
Does it work on a newer kernel if you revert that commit? I really see
nothing wrong with that commit ...
Failing all else, since I can't reproduce the issue, can you please
compare the output of "iw list" before and after the failure (on the
failing kernel)? Maybe all channels are marked disabled or something?
But that really should've been the same behaviour before the patch too.
Also, tracing would be good (trace-cmd record -e cfg80211 -e mac80211,
compress trace.dat and send it to me)
johannes