Ok, I'm sure this is something people have seen before, but it has me stumped.
I'm on the road for a couple of days with my google ChromeBook pixel,
which worked perfectly fine in the previous location I was at, and
works fine at home. But in the current condo, the machine simply
*cannot* connect
bad firmware load on a crappy wireless AP probably, I just flashed the
latest firmware on a new Netgear, and had exactly the same issue
flashed back to the original firmware and the issue goes away, question is
whats the router and version? Ive seen it before also occasionally
using OpenWRT on some
Can you try disabling network manager from the init scripts (I am not
sure which distro you are using as a base but
/etc/init.d/network-manager stop ) tends to work for a percentage of
machines.
Then running wpa_supplicant manually.
i.e:
create a hashed passphrase config snippit with :
aenertia
On 24 March 2013 21:06, Linus Torvalds wrote:
> Ok, I'm sure this is something people have seen before, but it has me stumped.
> wlan0: authenticate with 50:46:5d:02:85:08
> wlan0: send auth to 50:46:5d:02:85:08 (try 1/3)
> wlan0: authenticated
> wlan0: associate with 50:46:5d:02:85:08 (t
On Sun, Mar 24, 2013 at 9:22 PM, Outback Dingo wrote:
> bad firmware load on a crappy wireless AP probably, I just flashed the
> latest firmware on a new Netgear, and had exactly the same issue
> flashed back to the original firmware and the issue goes away, question is
> whats the router and vers
On Sun, Mar 24, 2013 at 9:26 PM, Joel Wirāmu Pauling wrote:
> Can you try disabling network manager from the init scripts (I am not
> sure which distro you are using as a base but
> /etc/init.d/network-manager stop ) tends to work for a percentage of
> machines.
>
> Then running wpa_supplicant man
On Mon, Mar 25, 2013 at 2:23 AM, Linus Torvalds
wrote:
>
> Interestingly, the kernel messages from doing this were different:
>
> wlan0: RX AssocResp from 50:46:5d:02:85:08 (capab=0x411 status=0 aid=16)
>
> notice how now it says "aid=16" instead of "aid=10". WTF?
This seems to be irrelevant. R
On Mon, Mar 25, 2013 at 02:23:52AM -0700, Linus Torvalds wrote:
> Apparently this really is NetworkManager doing something wrong.
>
> I'm running F18, so doing
>
> systemctl stop NetworkManager.service
> ifconfig wlan0 up
> iwlist scan
> wpa_passphrase *essid* *pas
On Mon, Mar 25, 2013 at 3:12 AM, Jouni Malinen wrote:
>
> Did you happen to notice whether wpa_supplicant showed more than one
> attempt at associating with the AP?
According to the kernel messages, there seems to be just a single
quick association:
IOW, this is what happens with wpa_supplicant:
Am 25.03.2013 10:23, schrieb Linus Torvalds:
> On Sun, Mar 24, 2013 at 9:26 PM, Joel Wirāmu Pauling
> wrote:
>> Can you try disabling network manager from the init scripts (I am not
>> sure which distro you are using as a base but
>> /etc/init.d/network-manager stop ) tends to work for a percenta
On Mon, Mar 25, 2013 at 3:38 AM, Linus Torvalds
wrote:
>
> that web page
> tells me how to add them, so I'll do that (I obviously lose my network
> when I try this, so I'm not doing it while writing this email ;)
Ok, full wpasupplicant log added to the RH NetworkManager bugzilla,
let's hope that
On Mon, Mar 25, 2013 at 04:06:49AM -0700, Linus Torvalds wrote:
> Ok, full wpasupplicant log added to the RH NetworkManager bugzilla,
> let's hope that somebody sees the problem there. I see that there's a
> gnome bugzilla for NM too, but it appears that at least Dan Williams
> is on both the RH an
Likely due to some odd dhcp options or behaviours comming whatever odd
ball vendor implemented dhcp server that runs the wireless network dhcp
leases. Often in hotels or corporates they use an offloaded radius and
crypto upstream of the AP itself. These tend to be dark voodoo, Cisco and
Aruba/Alca
On Tue, Mar 26, 2013 at 01:17:10AM +1300, Joel Wirāmu Pauling wrote:
>Likely due to some odd dhcp options or behaviours comming whatever odd
>ball vendor implemented dhcp server that runs the wireless network dhcp
>leases. Often in hotels or corporates they use an offloaded radius and
On Mon, Mar 25, 2013 at 4:30 AM, Jouni Malinen wrote:
>
> This looks very basic case taken into account the AP configuration (just
> WPA2-Personal/CCMP) and passphrase that should not allow much of a
> chance for typos or encoding issues (non-ASCII..).
Hmm. I'm certain I didn't mistype it, and I
On Mon, Mar 25, 2013 at 09:04:14AM -0700, Linus Torvalds wrote:
> Ok, I've collected a successful trace with wpa_supplicant, and added
> it to the bugzilla entry.
Thanks. This log does actually show a retry of the EAPOL-Key message 1/4
about a second after the first attempt and that was the area I
On Mon, Mar 25, 2013 at 9:35 AM, Jouni Malinen wrote:
>
> I'm not really familiar with debugging with NM enabled, but it could be
> possible that the instructions for the older wpa_supplicant on
> https://live.gnome.org/NetworkManager/Debugging could be adopted for
> this. The key here would be to
Me and other ath9k users have experienced various similar problems
for years, across different ath9k hardware. NM was usually not part
of the picture, at least never in my case, my problems were always
with only wpa_supplicant, if that.
ath9k has improved, but I still have "soft" issues that nobod
On 25 March 2013 11:03, Peter Stuge wrote:
> Me and other ath9k users have experienced various similar problems
> for years, across different ath9k hardware. NM was usually not part
> of the picture, at least never in my case, my problems were always
> with only wpa_supplicant, if that.
>
> ath9k
On Mon, Mar 25, 2013 at 9:42 AM, Linus Torvalds
wrote:
> On Mon, Mar 25, 2013 at 9:35 AM, Jouni Malinen wrote:
>>
>> I'm not really familiar with debugging with NM enabled, but it could be
>> possible that the instructions for the older wpa_supplicant on
>> https://live.gnome.org/NetworkManager/D
On Mon, Mar 25, 2013 at 07:12:57PM -0700, Linus Torvalds wrote:
> Nothing sane worked, so I did a brute-force "let's just make
> wpa_supplicant a shell-script that adds the debug fields and then runs
> the real wpa_supplicant binary with the extra flags".
Ah, yes. I remember having done that at so
Jouni Malinen wrote:
> a clear difference in the driver interface (nl80211 vs. WEXT)
> that is being used here. This should not have really caused the
> issue since both cases used cfg80211 and same set of parameters for
> association. Anyway, that is the only clear difference..
I can confirm that
On Tue, 2013-03-26 at 11:58 +0200, Jouni Malinen wrote:
> On Mon, Mar 25, 2013 at 07:12:57PM -0700, Linus Torvalds wrote:
> > Nothing sane worked, so I did a brute-force "let's just make
> > wpa_supplicant a shell-script that adds the debug fields and then runs
> > the real wpa_supplicant binary wi
On Tue, Mar 26, 2013 at 2:58 AM, Jouni Malinen wrote:
>
> If you still happen to be at the location with this AP, it could be
> useful to confirm that this kernel interface difference is indeed the
> reason by running the manual configuration case with -Dnl80211 added to
> the wpa_supplicant comma
On Tue, Mar 26, 2013 at 08:25:20AM -0700, Linus Torvalds wrote:
> Ok, added to the bugzilla. I'm still in the condo, but I'm leaving
> soon and need to pack up, so this is likely the last thing I can do..
>
> It is indeed the nl80211 part that causes problems, so I guess we're
> back to an actual
Adding linux-wireless, not sure if many people read this list.
Luis
On Tue, Mar 26, 2013 at 8:40 AM, Jouni Malinen wrote:
> On Tue, Mar 26, 2013 at 08:25:20AM -0700, Linus Torvalds wrote:
>> Ok, added to the bugzilla. I'm still in the condo, but I'm leaving
>> soon and need to pack up, so this
26 matches
Mail list logo
