Camaleón wrote[1]:
> vermagic: 3.9.0-rc2 SMP mod_unload modversions 686
>
> As soon as I load the brcmsmac module, N-M pop-ups and asks for the
> secrets... constantly until it quits, that is, I cannot even connect
> to the wifi AP with the Broadcom card, it's a bit frustrating :-(
>
> (attaching full dmesg and syslog files)
Thanks.
> I also downloaded Debian experimental kernel sources (3.8.2), do you
> want me to compile and test this?
I see no reason to do that.
Hm.
Jonathan
[1] http://bugs.debian.org/664767
El 2013-03-19 a las 13:16 -0500, Dan Williams escribió:
> On Tue, 2013-03-19 at 19:11 +0100, Camaleón wrote:
(...)
> > > NM minimally verifies the PSK, which by 802.11 standards is between 8
> > > and 63 ASCII characters inclusive. So you should be able to type
> > > anything you want within those constraints, but clearly only one is your
> > > real PSK.
> >
> > Oops! Okay, so what user inputs is not "bullet-proof".
> >
> > Anyway, this does not seem to be a problem of bad password. I was
> > finally able to get connected to the AP as soon as I carry the nebook
> > and put it next to the AP which is the problem I've always have had
> > with this driver (brcmsmac).
>
> Yeah, that's a symptom of bad power control or bad gain or who knows
> what in the driver. But also, make sure your antennas are connected
> correctly :)
I'm starting to think the embedded wireless adapter could have been
damaged somehow. The fact is that the card worked fine until kernel 2.6.38
(IIRC), but afterwards... well, I had to connect an additional USB card.
> > As soon as I back to another room, N-M asks me again for the pass-key
> > and disconnects.
>
> NM 0.9.8 shouldn't do that; I bet you're not even getting to the point
> where the 4-way handshake and password verification are done. NM 0.9.8
> will retry a few times, notify you and fail, then wait a couple minutes
> and try again. It shouldn't ask for a password anymore in situations
> like this.
Debian Wheezy still has 0.9.4 but well, that's a minor issue ;-(
Greetings,
--
Camaleón
El 2013-03-19 a las 11:53 -0500, Dan Williams escribió:
> On Tue, 2013-03-19 at 17:21 +0100, Camaleón wrote:
> > 2013/3/19 Camaleón <[email protected]>:
> > > 2013/3/18 Jonathan Nieder <[email protected]>:
> > >> Camaleón wrote:
> > >>> El 2013-03-18 a las 20:38 +0100, Arend van Spriel escribió:
> > >>
> > >>>> Sorry to hear. Reading back the bug report I noticed you are having a
> > >>>> bcm4313 and we recently had a regression on it. Could you provide
> > >>>> debugfs information from <debugfs_mount>/brcmsmac/bcma0:0/hardware
> > >>>
> > >>> I see. My "/sys/kernel/debug/*" directory is empty
> > >>
> > >> mount -t debugfs debugfs /sys/kernel/debug
> > >
> > > Perfect, thanks.
> > >
> > > root@stt300:~# cat /sys/kernel/debug/brcmsmac/bcma0\:0/hardware
> > > board vendor: 103c
> > > board type: 145c
> > > board revision: 2209
> > > board flags: 8002a00
> > > board flags2: 800
> > > firmware revision: 262032b
> > >
> > > Now let's see how reverting the patch makes any difference as soon as
> > > I can compile the module. I will keep you updated
> >
> > Update: applied the patch to revert the "other" patch but I still
> > cannot get the driver to work (see attached syslog). N-M still asks
> > for password until desists :-(
>
> Note that NM 0.9.8 won't ask for a password when just anything fails,
> but will ask for a password if the 4-way handshake fails, because if
> that fails, it's probably your password. We're contemplating getting
> rid of that too, and just notifying the user that their password may be
> wrong and that they should go update it in the network configuration
> panel so we don't interrupt. But if you're 100% sure your PSK is
> correct, then it is, most likely, a driver bug.
Password is correct. I have a second wireless card (external, using
rt2800usb driver) that connects without a glitch to the same AP.
Moreover, unless I type the right password, N-M dialog does not allow
me to click on the "Connect" button.
Greetings,
--
Camaleón
On Tue, 2013-03-19 at 19:11 +0100, Camaleón wrote:
> El 2013-03-19 a las 12:59 -0500, Dan Williams escribió:
>
> > On Tue, 2013-03-19 at 18:30 +0100, Camaleón wrote:
> > > El 2013-03-19 a las 11:53 -0500, Dan Williams escribió:
> > > >
> > > > Note that NM 0.9.8 won't ask for a password when just anything fails,
> > > > but will ask for a password if the 4-way handshake fails, because if
> > > > that fails, it's probably your password. We're contemplating getting
> > > > rid of that too, and just notifying the user that their password may be
> > > > wrong and that they should go update it in the network configuration
> > > > panel so we don't interrupt. But if you're 100% sure your PSK is
> > > > correct, then it is, most likely, a driver bug.
> > >
> > > Password is correct. I have a second wireless card (external, using
> > > rt2800usb driver) that connects without a glitch to the same AP.
> > >
> > > Moreover, unless I type the right password, N-M dialog does not allow
> > > me to click on the "Connect" button.
> >
> > NM minimally verifies the PSK, which by 802.11 standards is between 8
> > and 63 ASCII characters inclusive. So you should be able to type
> > anything you want within those constraints, but clearly only one is your
> > real PSK.
>
> Oops! Okay, so what user inputs is not "bullet-proof".
>
> Anyway, this does not seem to be a problem of bad password. I was
> finally able to get connected to the AP as soon as I carry the nebook
> and put it next to the AP which is the problem I've always have had
> with this driver (brcmsmac).
Yeah, that's a symptom of bad power control or bad gain or who knows
what in the driver. But also, make sure your antennas are connected
correctly :)
> As soon as I back to another room, N-M asks me again for the pass-key
> and disconnects.
NM 0.9.8 shouldn't do that; I bet you're not even getting to the point
where the 4-way handshake and password verification are done. NM 0.9.8
will retry a few times, notify you and fail, then wait a couple minutes
and try again. It shouldn't ask for a password anymore in situations
like this.
Dan
On Tue, 2013-03-19 at 18:30 +0100, Camaleón wrote:
> El 2013-03-19 a las 11:53 -0500, Dan Williams escribió:
>
> > On Tue, 2013-03-19 at 17:21 +0100, Camaleón wrote:
> > > 2013/3/19 Camaleón <[email protected]>:
> > > > 2013/3/18 Jonathan Nieder <[email protected]>:
> > > >> Camaleón wrote:
> > > >>> El 2013-03-18 a las 20:38 +0100, Arend van Spriel escribió:
> > > >>
> > > >>>> Sorry to hear. Reading back the bug report I noticed you are having a
> > > >>>> bcm4313 and we recently had a regression on it. Could you provide
> > > >>>> debugfs information from <debugfs_mount>/brcmsmac/bcma0:0/hardware
> > > >>>
> > > >>> I see. My "/sys/kernel/debug/*" directory is empty
> > > >>
> > > >> mount -t debugfs debugfs /sys/kernel/debug
> > > >
> > > > Perfect, thanks.
> > > >
> > > > root@stt300:~# cat /sys/kernel/debug/brcmsmac/bcma0\:0/hardware
> > > > board vendor: 103c
> > > > board type: 145c
> > > > board revision: 2209
> > > > board flags: 8002a00
> > > > board flags2: 800
> > > > firmware revision: 262032b
> > > >
> > > > Now let's see how reverting the patch makes any difference as soon as
> > > > I can compile the module. I will keep you updated
> > >
> > > Update: applied the patch to revert the "other" patch but I still
> > > cannot get the driver to work (see attached syslog). N-M still asks
> > > for password until desists :-(
> >
> > Note that NM 0.9.8 won't ask for a password when just anything fails,
> > but will ask for a password if the 4-way handshake fails, because if
> > that fails, it's probably your password. We're contemplating getting
> > rid of that too, and just notifying the user that their password may be
> > wrong and that they should go update it in the network configuration
> > panel so we don't interrupt. But if you're 100% sure your PSK is
> > correct, then it is, most likely, a driver bug.
>
> Password is correct. I have a second wireless card (external, using
> rt2800usb driver) that connects without a glitch to the same AP.
>
> Moreover, unless I type the right password, N-M dialog does not allow
> me to click on the "Connect" button.
NM minimally verifies the PSK, which by 802.11 standards is between 8
and 63 ASCII characters inclusive. So you should be able to type
anything you want within those constraints, but clearly only one is your
real PSK.
Dan
On Tue, 2013-03-19 at 22:55 +0100, Arend van Spriel wrote:
> On 03/19/2013 05:21 PM, Camaleón wrote:
> > Mar 19 17:05:28 stt300 kernel: [26034.188562] wlan0: authenticated
> > Mar 19 17:05:28 stt300 kernel: [26034.192108] wlan0: associate with 00:1a:2b:97:7a:97 (try 1/3)
> > Mar 19 17:05:28 stt300 NetworkManager[30971]: <info> (wlan0): supplicant interface state: authenticating -> associating
> > Mar 19 17:05:30 stt300 kernel: [26036.586947] wlan0: RX AssocResp from 00:1a:2b:97:7a:97 (capab=0x411 status=0 aid=1)
> > Mar 19 17:05:30 stt300 kernel: [26036.587560] brcmsmac bcma0:0: brcmsmac: brcms_ops_bss_info_changed: associated
> > Mar 19 17:05:30 stt300 kernel: [26036.587576] brcmsmac bcma0:0: brcms_ops_bss_info_changed: qos enabled: true (implement)
> > Mar 19 17:05:30 stt300 kernel: [26036.587603] wlan0: associated
> > Mar 19 17:05:30 stt300 kernel: [26036.587698] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
> > Mar 19 17:05:30 stt300 wpa_supplicant[2855]: wlan0: Associated with 00:1a:2b:97:7a:97
>
> Seems to be heading in the right direction, but....
>
> > Mar 19 17:05:30 stt300 NetworkManager[30971]: <info> (wlan0): supplicant interface state: associating -> associated
> > Mar 19 17:05:30 stt300 NetworkManager[30971]: <info> (wlan0): supplicant interface state: associated -> 4-way handshake
> > Mar 19 17:05:32 stt300 avahi-daemon[2630]: Joining mDNS multicast group on interface wlan0.IPv6 with address fe80::ae81:12ff:fe34:6963.
> > Mar 19 17:05:32 stt300 avahi-daemon[2630]: New relevant interface wlan0.IPv6 for mDNS.
> > Mar 19 17:05:32 stt300 avahi-daemon[2630]: Registering new address record for fe80::ae81:12ff:fe34:6963 on wlan0.*.
> > Mar 19 17:05:32 stt300 NetworkManager[30971]: <warn> Activation (wlan0/wireless): association took too long.
>
> Here it seem to go bad again...
>
> > Mar 19 17:05:32 stt300 NetworkManager[30971]: <info> (wlan0): device state change: config -> need-auth (reason 'none') [50 60 0]
> > Mar 19 17:05:32 stt300 NetworkManager[30971]: <warn> Activation (wlan0/wireless): asking for new secrets
> > Mar 19 17:05:32 stt300 kernel: [26039.005158] wlan0: deauthenticating from 00:1a:2b:97:7a:97 by local choice (reason=3)
>
> And we get a deauth request with WLAN_REASON_DEAUTH_LEAVING.
That local choice (reason=3) is NetworkManager terminating the
association attempt because it already took 25 seconds, which is way too
long for a simple association. The cause is long before that.
NM tells the supplicant to start associating here:
Mar 19 17:05:07 stt300 NetworkManager[30971]: <info> Config: set
interface ap_scan to 1
and finally kills the attempt here:
Mar 19 17:05:32 stt300 NetworkManager[30971]: <warn> Activation
(wlan0/wireless): association took too long.
So the supplicant gets a total of 25 seconds to associate to the AP,
which, if you're not associated within that time, you're definitely not
going to get associated if you're given more time. But between 17:05:07
and 17:05:32, NM is just waiting for the association to succeed.
It really does look like the supplicant or driver tries to associate but
then fails, eg:
Mar 19 17:05:08 stt300 kernel: [26014.833011] wlan0: send auth to
00:1a:2b:97:7a:97 (try 1/3)
Mar 19 17:05:13 stt300 kernel: [26019.834259] wlan0: deauthenticating
from 00:1a:2b:97:7a:97 by local choice (reason=3)
There's a whole lot of authentication/association failures in that log,
which do appear to indicate that the STA can see the AP, but the AP
can't hear the STA.
Then we also have stuff like:
Mar 19 17:05:24 stt300 wpa_supplicant[2855]: wlan0: SME: Authentication
request to the driver failed
where it would be nice to know why the request failed.
Dan
> > Mar 19 17:05:33 stt300 kernel: [26040.004150] brcmsmac bcma0:0: brcmsmac: brcms_ops_bss_info_changed: disassociated
> > Mar 19 17:05:33 stt300 kernel: [26040.004172] brcmsmac bcma0:0: brcms_ops_bss_info_changed: qos enabled: false (implement)
> > Mar 19 17:05:34 stt300 kernel: [26040.504402] cfg80211: Calling CRDA to update world regulatory domain
> > Mar 19 17:05:34 stt300 ntpd[2611]: Listen normally on 16 wlan0 fe80::ae81:12ff:fe34:6963 UDP 123
> > Mar 19 17:05:34 stt300 ntpd[2611]: peers refreshed
> > Mar 19 17:05:34 stt300 wpa_supplicant[2855]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:00:00:00:00:00 reason=3
> > Mar 19 17:05:34 stt300 NetworkManager[30971]: <info> (wlan0): supplicant interface state: 4-way handshake -> disconnected
> > Mar 19 17:05:34 stt300 NetworkManager[30971]: <warn> Couldn't disconnect supplicant interface: This interface is not connected.
>
> I am trying to make sense of it, but it is getting late over here. Have
> a fresh look tomorrow.
>
> Regards,
> Arend
>
> --
> 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 03/19/2013 05:21 PM, Camaleón wrote:
> Mar 19 17:05:28 stt300 kernel: [26034.188562] wlan0: authenticated
> Mar 19 17:05:28 stt300 kernel: [26034.192108] wlan0: associate with 00:1a:2b:97:7a:97 (try 1/3)
> Mar 19 17:05:28 stt300 NetworkManager[30971]: <info> (wlan0): supplicant interface state: authenticating -> associating
> Mar 19 17:05:30 stt300 kernel: [26036.586947] wlan0: RX AssocResp from 00:1a:2b:97:7a:97 (capab=0x411 status=0 aid=1)
> Mar 19 17:05:30 stt300 kernel: [26036.587560] brcmsmac bcma0:0: brcmsmac: brcms_ops_bss_info_changed: associated
> Mar 19 17:05:30 stt300 kernel: [26036.587576] brcmsmac bcma0:0: brcms_ops_bss_info_changed: qos enabled: true (implement)
> Mar 19 17:05:30 stt300 kernel: [26036.587603] wlan0: associated
> Mar 19 17:05:30 stt300 kernel: [26036.587698] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
> Mar 19 17:05:30 stt300 wpa_supplicant[2855]: wlan0: Associated with 00:1a:2b:97:7a:97
Seems to be heading in the right direction, but....
> Mar 19 17:05:30 stt300 NetworkManager[30971]: <info> (wlan0): supplicant interface state: associating -> associated
> Mar 19 17:05:30 stt300 NetworkManager[30971]: <info> (wlan0): supplicant interface state: associated -> 4-way handshake
> Mar 19 17:05:32 stt300 avahi-daemon[2630]: Joining mDNS multicast group on interface wlan0.IPv6 with address fe80::ae81:12ff:fe34:6963.
> Mar 19 17:05:32 stt300 avahi-daemon[2630]: New relevant interface wlan0.IPv6 for mDNS.
> Mar 19 17:05:32 stt300 avahi-daemon[2630]: Registering new address record for fe80::ae81:12ff:fe34:6963 on wlan0.*.
> Mar 19 17:05:32 stt300 NetworkManager[30971]: <warn> Activation (wlan0/wireless): association took too long.
Here it seem to go bad again...
> Mar 19 17:05:32 stt300 NetworkManager[30971]: <info> (wlan0): device state change: config -> need-auth (reason 'none') [50 60 0]
> Mar 19 17:05:32 stt300 NetworkManager[30971]: <warn> Activation (wlan0/wireless): asking for new secrets
> Mar 19 17:05:32 stt300 kernel: [26039.005158] wlan0: deauthenticating from 00:1a:2b:97:7a:97 by local choice (reason=3)
And we get a deauth request with WLAN_REASON_DEAUTH_LEAVING.
> Mar 19 17:05:33 stt300 kernel: [26040.004150] brcmsmac bcma0:0: brcmsmac: brcms_ops_bss_info_changed: disassociated
> Mar 19 17:05:33 stt300 kernel: [26040.004172] brcmsmac bcma0:0: brcms_ops_bss_info_changed: qos enabled: false (implement)
> Mar 19 17:05:34 stt300 kernel: [26040.504402] cfg80211: Calling CRDA to update world regulatory domain
> Mar 19 17:05:34 stt300 ntpd[2611]: Listen normally on 16 wlan0 fe80::ae81:12ff:fe34:6963 UDP 123
> Mar 19 17:05:34 stt300 ntpd[2611]: peers refreshed
> Mar 19 17:05:34 stt300 wpa_supplicant[2855]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:00:00:00:00:00 reason=3
> Mar 19 17:05:34 stt300 NetworkManager[30971]: <info> (wlan0): supplicant interface state: 4-way handshake -> disconnected
> Mar 19 17:05:34 stt300 NetworkManager[30971]: <warn> Couldn't disconnect supplicant interface: This interface is not connected.
I am trying to make sense of it, but it is getting late over here. Have
a fresh look tomorrow.
Regards,
Arend
El 2013-03-18 a las 20:38 +0100, Arend van Spriel escribió:
> On 03/18/2013 09:37 AM, Jonathan Nieder wrote:
>> Camaleón wrote[1]:
>>
>>> vermagic: 3.9.0-rc2 SMP mod_unload modversions 686
>>>
>>> As soon as I load the brcmsmac module, N-M pop-ups and asks for the
>>> secrets... constantly until it quits, that is, I cannot even connect
>>> to the wifi AP with the Broadcom card, it's a bit frustrating :-(
>
> Sorry to hear. Reading back the bug report I noticed you are having a
> bcm4313 and we recently had a regression on it. Could you provide
> debugfs information from <debugfs_mount>/brcmsmac/bcma0:0/hardware
I see. My "/sys/kernel/debug/*" directory is empty so now that I'm going
to recompile the whole kernel again to revert the patch, is there any
flag I need to turn on at the ".config" file to enable the debug for
brcmsmac or any additional flag it could be interesting for this?
> The regression was caused by following commit:
>
> "brcmsmac: support 4313iPA" b6fc28a158076ca2764edc9a6d1e1402f56e1c0c
>
> If possible you can revert that and see how that goes.
It will cost me a bunch of dislikes ;-) but sure, I'll try and report
back.
Greetings,
--
Camaleón
2013/3/19 Camale?n <[email protected]>:
> 2013/3/18 Jonathan Nieder <[email protected]>:
>> Camale?n wrote:
>>> El 2013-03-18 a las 20:38 +0100, Arend van Spriel escribi?:
>>
>>>> Sorry to hear. Reading back the bug report I noticed you are having a
>>>> bcm4313 and we recently had a regression on it. Could you provide
>>>> debugfs information from <debugfs_mount>/brcmsmac/bcma0:0/hardware
>>>
>>> I see. My "/sys/kernel/debug/*" directory is empty
>>
>> mount -t debugfs debugfs /sys/kernel/debug
>
> Perfect, thanks.
>
> root@stt300:~# cat /sys/kernel/debug/brcmsmac/bcma0\:0/hardware
> board vendor: 103c
> board type: 145c
> board revision: 2209
> board flags: 8002a00
> board flags2: 800
> firmware revision: 262032b
>
> Now let's see how reverting the patch makes any difference as soon as
> I can compile the module. I will keep you updated
Update: applied the patch to revert the "other" patch but I still
cannot get the driver to work (see attached syslog). N-M still asks
for password until desists :-(
Greetings,
--
Camale?n
2013/3/24 Arend van Spriel <[email protected]>:
> On 03/23/2013 04:28 PM, Camale?n wrote:
(...)
>> More verbose logs, just in case someone finds something of interest.
>>
>
> What I see in this log is that your AP keeps sending EAPOL message 1 and
> you keep sending EAPOL message 2 until one gives up the attempts. This
> behaviour would suggest the psk is wrong as indicated in the log, but
> you said you could connect using another card, right? So using the same
> configured N-M connection?
Yes, a second card works perfect.
Even more... look at these news logs (attached and compressed because
this one is a bit big, ~1.5 MiB), wlan0 is binded to brcmsmac and
wlan2 is the external card (rt2800usb). Okay, as soon as I boot the
system wlan2 loads and runs fine. The I remove the this second card
(unplug the usb cord) and load the re-pacthed brcmsmac kernel module.
It cannot connect and asks me for the passkey. I carry the computer
next to the AP and voil?, I get magically associated to the AP and N-M
asks no more for the passkey. As soon as I return to my room, problems
start over... so, it does not look like a bad passkey problem, I'm
afraid :-)
Greetings,
--
Camale?n
On 03/23/2013 04:28 PM, Camale?n wrote:
> 2013/3/19 Camale?n <[email protected]>:
>
>>> Now let's see how reverting the patch makes any difference as soon as
>>> I can compile the module. I will keep you updated
>>
>> Update: applied the patch to revert the "other" patch but I still
>> cannot get the driver to work (see attached syslog). N-M still asks
>> for password until desists :-(
>
> More verbose logs, just in case someone finds something of interest.
>
> Greetings,
>
What I see in this log is that your AP keeps sending EAPOL message 1 and
you keep sending EAPOL message 2 until one gives up the attempts. This
behaviour would suggest the psk is wrong as indicated in the log, but
you said you could connect using another card, right? So using the same
configured N-M connection?
Regards,
Arend
Camaleón wrote:
> El 2013-03-18 a las 20:38 +0100, Arend van Spriel escribió:
>> Sorry to hear. Reading back the bug report I noticed you are having a
>> bcm4313 and we recently had a regression on it. Could you provide
>> debugfs information from <debugfs_mount>/brcmsmac/bcma0:0/hardware
>
> I see. My "/sys/kernel/debug/*" directory is empty
mount -t debugfs debugfs /sys/kernel/debug
On Tue, 2013-03-19 at 17:21 +0100, Camaleón wrote:
> 2013/3/19 Camaleón <[email protected]>:
> > 2013/3/18 Jonathan Nieder <[email protected]>:
> >> Camaleón wrote:
> >>> El 2013-03-18 a las 20:38 +0100, Arend van Spriel escribió:
> >>
> >>>> Sorry to hear. Reading back the bug report I noticed you are having a
> >>>> bcm4313 and we recently had a regression on it. Could you provide
> >>>> debugfs information from <debugfs_mount>/brcmsmac/bcma0:0/hardware
> >>>
> >>> I see. My "/sys/kernel/debug/*" directory is empty
> >>
> >> mount -t debugfs debugfs /sys/kernel/debug
> >
> > Perfect, thanks.
> >
> > root@stt300:~# cat /sys/kernel/debug/brcmsmac/bcma0\:0/hardware
> > board vendor: 103c
> > board type: 145c
> > board revision: 2209
> > board flags: 8002a00
> > board flags2: 800
> > firmware revision: 262032b
> >
> > Now let's see how reverting the patch makes any difference as soon as
> > I can compile the module. I will keep you updated
>
> Update: applied the patch to revert the "other" patch but I still
> cannot get the driver to work (see attached syslog). N-M still asks
> for password until desists :-(
Note that NM 0.9.8 won't ask for a password when just anything fails,
but will ask for a password if the 4-way handshake fails, because if
that fails, it's probably your password. We're contemplating getting
rid of that too, and just notifying the user that their password may be
wrong and that they should go update it in the network configuration
panel so we don't interrupt. But if you're 100% sure your PSK is
correct, then it is, most likely, a driver bug.
Dan
2013/3/18 Jonathan Nieder <[email protected]>:
> Camale?n wrote:
>> El 2013-03-18 a las 20:38 +0100, Arend van Spriel escribi?:
>
>>> Sorry to hear. Reading back the bug report I noticed you are having a
>>> bcm4313 and we recently had a regression on it. Could you provide
>>> debugfs information from <debugfs_mount>/brcmsmac/bcma0:0/hardware
>>
>> I see. My "/sys/kernel/debug/*" directory is empty
>
> mount -t debugfs debugfs /sys/kernel/debug
Perfect, thanks.
root@stt300:~# cat /sys/kernel/debug/brcmsmac/bcma0\:0/hardware
board vendor: 103c
board type: 145c
board revision: 2209
board flags: 8002a00
board flags2: 800
firmware revision: 262032b
Now let's see how reverting the patch makes any difference as soon as
I can compile the module. I will keep you updated
Greetings,
--
Camale?n
El 2013-03-19 a las 12:59 -0500, Dan Williams escribió:
> On Tue, 2013-03-19 at 18:30 +0100, Camaleón wrote:
> > El 2013-03-19 a las 11:53 -0500, Dan Williams escribió:
> > >
> > > Note that NM 0.9.8 won't ask for a password when just anything fails,
> > > but will ask for a password if the 4-way handshake fails, because if
> > > that fails, it's probably your password. We're contemplating getting
> > > rid of that too, and just notifying the user that their password may be
> > > wrong and that they should go update it in the network configuration
> > > panel so we don't interrupt. But if you're 100% sure your PSK is
> > > correct, then it is, most likely, a driver bug.
> >
> > Password is correct. I have a second wireless card (external, using
> > rt2800usb driver) that connects without a glitch to the same AP.
> >
> > Moreover, unless I type the right password, N-M dialog does not allow
> > me to click on the "Connect" button.
>
> NM minimally verifies the PSK, which by 802.11 standards is between 8
> and 63 ASCII characters inclusive. So you should be able to type
> anything you want within those constraints, but clearly only one is your
> real PSK.
Oops! Okay, so what user inputs is not "bullet-proof".
Anyway, this does not seem to be a problem of bad password. I was
finally able to get connected to the AP as soon as I carry the nebook
and put it next to the AP which is the problem I've always have had
with this driver (brcmsmac).
As soon as I back to another room, N-M asks me again for the pass-key
and disconnects.
Greetings,
--
Camaleón
2013/3/19 Camale?n <[email protected]>:
>> Now let's see how reverting the patch makes any difference as soon as
>> I can compile the module. I will keep you updated
>
> Update: applied the patch to revert the "other" patch but I still
> cannot get the driver to work (see attached syslog). N-M still asks
> for password until desists :-(
More verbose logs, just in case someone finds something of interest.
Greetings,
--
Camale?n
On 03/18/2013 09:37 AM, Jonathan Nieder wrote:
> Camale?n wrote[1]:
>
>> vermagic: 3.9.0-rc2 SMP mod_unload modversions 686
>>
>> As soon as I load the brcmsmac module, N-M pop-ups and asks for the
>> secrets... constantly until it quits, that is, I cannot even connect
>> to the wifi AP with the Broadcom card, it's a bit frustrating :-(
Sorry to hear. Reading back the bug report I noticed you are having a
bcm4313 and we recently had a regression on it. Could you provide
debugfs information from <debugfs_mount>/brcmsmac/bcma0:0/hardware
The regression was caused by following commit:
"brcmsmac: support 4313iPA" b6fc28a158076ca2764edc9a6d1e1402f56e1c0c
If possible you can revert that and see how that goes.
Regards,
Arend
>
> Thanks.
>
>> I also downloaded Debian experimental kernel sources (3.8.2), do you
>> want me to compile and test this?
>
> I see no reason to do that.
>
> Hm.
> Jonathan
>
> [1] http://bugs.debian.org/664767
>