[SOLVED!!!] Weird Wifi problem -- WPA-EAP TTLS fails
There's a bit of acronym-soup here, for context check out the list archives from May 2011. I had this weird WPA-EAP TTLS problem at that time, and have now finally gotten it resolved. The key was to finally run a packet sniffer on the wireless port and watch the authentication as it went by. It turns out that the access point is asking for PEAP, not TTLS, so the EAP method-negotiation process was just failing, since the instructions I had were very clear about setting up the EAP to be TTLS-only. It's now clear that the instructions were simply wrong. The reason for mentioning this on-list is that the symptoms of client misconfiguration included, in the verbose wpa_supplicant output, a bit about ...disconnected by local choice (reason=3)..., and googling that message gets you a lot of hits, which turned out to be completely irrelevant to my issue, and I spent a lot of time on irrelevant details. Lesson 1: The local choice message can arise from a trivially misconfigured client, it's not necessarily a symptom of all the scary stuff that's out there. Lesson 2: Wireshark is awesome. I should have used it much earlier. -- A. -- Andrew Reid / rei...@bellatlantic.net -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120011.52257.rei...@bellatlantic.net
Re: Weird Wifi problem -- WPA-EAP TTLS fails
On Fri, 20 May 2011 20:47:21 -0400 Andrew Reid rei...@bellatlantic.net wrote: So, apologies for the long-windedness, but what can cause EAP to fail? Do I need to add some libraries with more authentication schemes in them somehow? Obviously I have all the dependencies of wpa_supplicant, but is there something else? I don't know if I can be of much help, as I'm running EAP-TLS with FreeRADIUS, but you don't have any other takers yet. And all I can suggest is that you probably won't solve this without seeing the RADIUS logs, on what I assume is a Windows server, and I've no idea what they call RADIUS these days. It used to be IAS on Server 2003, and I've never had anything to do with that. Is the Macbook a domain member, and is your machine? Some Windows facilities are available only to domain members, and this may be one. At the very least, RADIUS requires both human and machine to be named in its server configuration. EAP-(T)TLS isn't just something a step up from WPA(2), it uses a separate authentication server, and a Windows one is tied into Active Directory. You clearly have an account, but does your computer? If so, then the RADIUS logs will tell you what authentication is missing. It's possible for a non-domain computer to connect to a Windows VPN or at least was with 2003. Do you do that? If so then you should have the necessary authentication measures installed, if not actually configured yet, though I believe everything necessary has been in the kernel for some years now. I'm afraid I use the Not-Work Manager on Ubuntu to make the connection, and I'm not logging in to Windows, and EAP-TLS is heavy on certificates, so my configurations will be of no use to you. EAP-TTLS also uses a certificate, but on the server only, the idea of TTLS being that you don't need to install anything on the client. -- Joe -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110521122011.1191e...@jresid.jretrading.com
Re: Weird Wifi problem -- WPA-EAP TTLS fails
On Fri, 20 May 2011 20:47:21 -0400 Andrew Reid rei...@bellatlantic.net wrote: So, apologies for the long-windedness, but what can cause EAP to fail? Do I need to add some libraries with more authentication schemes in them somehow? Obviously I have all the dependencies of wpa_supplicant, but is there something else? I don't know if I can be of much help, as I'm running EAP-TLS with FreeRADIUS, but you don't have any other takers yet. And all I can suggest is that you probably won't solve this without seeing the RADIUS logs, on what I assume is a Windows server, and I've no idea what they call RADIUS these days. It used to be IAS on Server 2003, and I've never had anything to do with that. The WAP itself is part of a Cisco Enterprise system. I'm not sure what the back-end authentication is, our workplace duplicates enterprise passwords across many authentication engines (to reduce password proliferation, a goal I heartily endorse). I do know that the Mac I used was not any kind of Windows domain member, and the Debian laptop also is not. I've put in a support query for the server-side logs, but the first-line support's response is it works on the Mac, our system is fine, Linux is not supported, and I have to admit that for a support team with scarce resources, that's not an absurd answer. I have asked them specifically for the authentication logs (and given them a precise time of the failed attempt and the originating MAC address), but haven't heard back on that yet. I've googled around a bit more since my initial post, and I'm starting to think I might actually be able to parse the wpa_supplicant logs, and maybe sharpen my question, possibly by figuring where in the EAP framework it's coming undone. What I suspect has happened is that the squeeze wpa_supplicant has some kind of new default that's breaking the process, and if I can just figure out what it is and set it to work like lenny did, I'll be fine. But, wpa_supplicant's option space is pretty big. I think I may be able to scare up another Linux laptop, and may even be able to get lenny on there, to try to close in on this. Anyways, thanks for your reply, mostly just thinking out loud here... -- A. -- Andrew Reid / rei...@bellatlantic.net -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201105211257.31395.rei...@bellatlantic.net
Weird Wifi problem -- WPA-EAP TTLS fails
Hi all --
I'm having a strange problem with my wireless connection, and I'm running
out of ideas.
I have a ThinkPad T510 laptop, running stock Debian squeeze. I use
the KDE desktop, but I think that's not an issue, because I've reproduced
the problem without any network managers or anything.
This machine has the Intel Centrino Wireless-N 1000 system
(PCI ID 8086:0084), which is supported by the stock iwlagn module.
It worked in lenny, with the backported kernel and drivers.
I can connect to my WPA-PSK access point at home, and to unencrypted
public Wifi systems, without any difficulties, but at work, we have a
WPA-EAP TTLS set-up, where it doesn't connect.
I can connect with my credentials on a colleague's Macbook, so my
account is evidently active, and the access point works, it looks like
the problem is on my system somewhere. Linux is unsupported at my
workplace, so I'm on my own.
The way I am connecting is in instructions all over the place:
ifconfig wlan0 up
wpa_supplicant -i wlan0 -c /etc/wpa_supplicant/work_wpa.conf
... which associates with the right SSID, then does this:
CTRL-EVENT-EAP-STARTED EAP authentication started
... then waits for maybe 30 seconds, then
CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
I have generated much more verbose logs with wpa_supplicant -dd etc,
but I really have no idea what I'm looking at. Some times it looks like it
times out, but I have some traces without timeout messages, which didn't
work. All of them have a line, EAP: Received EAP-Failure, which is the
thing that most looks like an actual solveable problem.
It seems that there can be a lot of variability in the log files,
for a while I was trying different options in the conf file, and seeing
if it looked like it was getting farther in the auth process. From that,
I did learn that it seems to do more with the right password than with
the wrong one, which suggests that *something* is working, but that's
about as much as I can get out of it.
My work_wpa.conf file is as recommended by my employer, and looks like:
ctrl_interface=/var/run/work_wpa
eapol_version=1
ap_scan=1
fast_reauth=1
network={
ssid=correct SSID, in quotes
key_mgmt=WPA-EAP
eap=TTLS
identity=correct username, in quotes
password=correct password, in quotes
anonymous_identity=anonym...@example.com
ca_cert=quoted/path/to/cert
priority=2
}
I have tried explicitly setting a phase2=autheap=MSCHAPV2, and
some others, and I've read about lots of other parameters.
I've found several related-looking posts by googling around,
which motivated me to try re-loading the iwlagn module with
swcrypto=1 and/or swcrypto50=1, but this does not change
the behavior.
So, apologies for the long-windedness, but what can cause EAP to
fail? Do I need to add some libraries with more authentication schemes
in them somehow? Obviously I have all the dependencies of wpa_supplicant,
but is there something else?
Thanks in advance.
-- A.
--
Andrew Reid / rei...@bellatlantic.net
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201105202047.21826.rei...@bellatlantic.net
