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 some
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 with the
On Tue, Mar 26, 2013 at 2:58 AM, Jouni Malinen jo...@qca.qualcomm.com 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
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 jo...@qca.qualcomm.com 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
On Sun, Mar 24, 2013 at 9:22 PM, Outback Dingo outbackdi...@gmail.com 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
On Sun, Mar 24, 2013 at 9:26 PM, Joel Wirāmu Pauling j...@aenertia.net 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
On Mon, Mar 25, 2013 at 2:23 AM, Linus Torvalds
torva...@linux-foundation.org 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
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* *password*
On Mon, Mar 25, 2013 at 3:12 AM, Jouni Malinen jo...@qca.qualcomm.com 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
Am 25.03.2013 10:23, schrieb Linus Torvalds:
On Sun, Mar 24, 2013 at 9:26 PM, Joel Wirāmu Pauling j...@aenertia.net
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
On Mon, Mar 25, 2013 at 3:38 AM, Linus Torvalds
torva...@linux-foundation.org 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
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 and
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
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 jo...@qca.qualcomm.com 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
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 jo...@qca.qualcomm.com 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
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 nobody
On 25 March 2013 11:03, Peter Stuge pe...@stuge.se 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.
On Mon, Mar 25, 2013 at 9:42 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Mon, Mar 25, 2013 at 9:35 AM, Jouni Malinen jo...@qca.qualcomm.com wrote:
I'm not really familiar with debugging with NM enabled, but it could be
possible that the instructions for the older wpa_supplicant
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
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 :
On 24 March 2013 21:06, Linus Torvalds torva...@linux-foundation.org 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
26 matches
Mail list logo
