Connect Baby to WPA2-EAP

[inkasso]

Thank you for all your help ralphy!
I really appreciate that you are doing this just because of my request.

My test results:

I have downloaded and scp'd the files to my Sqeezebox after connecting it via LAN.
Afterwards I stopped the WiFi service, made a backup of the original files and replaced them with the ones from the download.
Then I started the WiFi service again, which worked without any error.
I disconnected LAN and tried to connect to my old WiFi which is WPA2-PSK, which worked without any problems.

Until this point I can say: At least, it hasn't become worse

Now I reconnected LAN, transferred again all files and the configuration for my WPA2-EAP connection and tried to do the WPA2-EAP connection.
It didn't work, but the error message gave clues now, why.

After various different configurations of wpa_supplicant I finally found a config that successfully authenticated against my RADIUS server.

I replaced /etc/wpa_supplicant.conf with my successfull test-config and replaced /etc/network/interfaces as described in the tutorial. After rebooting, the device did not connect automatically to WiFi and did not find any WiFIs to connect to. Even LAN connections did not work any more and I had to factory reset. I guess, there was a problem with my /etc/network/interfaces file, but I have not the time to debug this now.

I'll give it another try later, so stay tuned. After everything works, I'll provide a little howTo for other interested people here.

[mrw]

Despite @ralphy's post, wpa_supplicant has been built (I think) with an "internal" TLS library, which apparently supports TLS v1. That may be why the author of "Raptors blog" claimed to be able to get somewhere back in 2011.

Well, I tried this out on an RPi based access point running hostapd, which I set up to use its internal, (minimal ?), radius server.
At first it wouldn't work, but that's because the RPi system defaulted to minimum TLS v1.2. When hostapd was persuaded to use TLS v1.0 (tls_flags=[ENABLE-TLSv1.0]) then, well, it worked.

> wpa_cli status
<snip>
pairwise_cipher=CCMP
group_cipher=CCMP
key_mgmt=WPA2/IEEE 802.1X/EAP
<snip>
EAP state=SUCCESS
selectedMethod=13 (EAP-TLS)
eap_tls_version=TLSv1
EAP TLS cipher=DHE-RSA-AES-256-SHA
tls_session_reused=0
<snip>

I then tried it using @ralphy's modified wpa_supplicant build, configured for for TLS 1.1 & 1.2. That, too, worked:

> wpa_cli status
<snip>
pairwise_cipher=CCMP
group_cipher=CCMP
key_mgmt=WPA2/IEEE 802.1X/EAP
<snip>
EAP state=SUCCESS
selectedMethod=13 (EAP-TLS)
eap_tls_version=TLSv1.2
EAP TLS cipher=DHE-RSA-AES-256-SHA256
tls_session_reused=0
<snip>

I had a number of false starts with this, with things behaving in a somewhat peculiar manner. At one point I was finding myself seemingly needing to put phase1="tls_disable_tlsv1_0=1" into wpa_supplicant.conf's network configuration before it would work. But then, mysteriously, I didn't. So that's probably a red herring, and I remain a bit puzzled. But that's common with the Radio's wireless.

This change to hostapd/wpa_supplicant may be relevant:
https://w1.fi/cgit/hostap/commit/src...6729476556853e

My wireless configuration:

network={
	ssid="MY SSID"
	scan_ssid=1
	key_mgmt=WPA-EAP
	pairwise=CCMP
	group=CCMP
	eap=TLS
	identity="Anything"
	ca_cert="/root/ca.pem"
	client_cert="/root/clientcert.der"
	private_key="/root/clientkey.der"
}

The identity setting is necessary, even though the actual identity seems to be irrelevant. The private key is not encrypted, so no password needed.

So, in principal it seems to work, but I will say that, on restart, the Radio does not always seem to get any DHCP configuration, even though it does connect to the AP. Sometimes it does, sometimes it doesn't. That may be a difficulty with my test AP arrangements. But it all seems a bit delicate. I don't think I'll be pursuing it further.

[inkasso]

Sorry, I still didn't find the time for another test. So much is happening at the moment here...

Just a quick question to mrw: Does your SSID really contain a space in it's name or did you just put it in to make it easier to read?

I do have an SSID with space and guessed that my problems were coming exactly from there. My next test would have been to change the SSID to one without a space. The problems you describe seem common to me. It does associate with the AP but does not obtain an IP via DHCP. Would not be such a big issue for me, as I'd also be willing to assign one manually.

And before everyone starts to give me the hint, that I should enclose my SSID into double quotes in the wpa_supplicant.conf and the interfaces file as well... I did and sadly it did not work :-/

[mrw]

Just a quick question to mrw: Does your SSID really contain a space in it's name or did you just put it in to make it easier to read?

No space in my SSID ! As you guessed, it was just to make it easier to read.

I do have an SSID with space and guessed that my problems were coming exactly from there.

Just don't ! That will give almost certainly give you problems somewhere or other.

In principle an SSID can have up to 32 arbitrary bytes. In practice, restrict yourself to standard, displayable, ASCII characters. I don't think the Radio will be graceful (at present) with much else, and I don't think the Controller or Touch will ever really be. I may be wrong on those points, but you really don't need the complication.

The problems you describe seem common to me. It does associate with the AP but does not obtain an IP via DHCP.

My problems may well have been signal strength (lack of) related. It's been somewhat more reliable since I posted.

One problem you may encounter is that the Squeezeplay "Choose network" UI will remove the relevant entries from the network interfaces file, and perhaps wpa_supplicant.conf, if a connection fails.

I think that one could make a reasonably simple patch to Squeezeplay to allow a knowledgeable user to predefine settings for an EAP-TLS AP. I'll post further if I get something that looks viable.

I also ran across a problem with the Radio community firmware when switching from one wireless network to another, whereby it would not update the DHCP configuration properly, requiring a "Repair Network". But I doubt that that will be influencing your issues. I'll be making a proposal to @ralphy that corrects matters in due course.

And before everyone starts to give me the hint, that I should enclose my SSID into double quotes in the wpa_supplicant.conf and the interfaces file as well... I did and sadly it did not work :-/

SSIDs without quotes are understood to be a hexadecimal form of the SSID (which allows for arbitrary SSIDs - see above).
SSIDs with quotes are usual for normal people.

[mrw]

So, in principal it seems to work, but I will say that, on restart, the Radio does not always seem to get any DHCP configuration, even though it does connect to the AP. Sometimes it does, sometimes it doesn't. That may be a difficulty with my test AP arrangements. But it all seems a bit delicate. I don't think I'll be pursuing it further.

Problem located, an issue with "new" behaviours in wpa_supplicant v2.9.

I've opened a PR: https://github.com/ralph-irving/squeezeos/pull/10

[ralphy]

Problem located, an issue with "new" behaviours in wpa_supplicant v2.9.

I've opened a PR: https://github.com/ralph-irving/squeezeos/pull/10

A new community firmware build for the radio v8.01r16867 is available on sourceforge with the fixes from mrw, wpa2-eap support and wpa_cli command line history and edit enabled for wpa_supplicant v2.9.

If no issue are reported in the next couple weeks, I will release it.

[inkasso]

Darn. As initiator of this thread I'd love to test, but currently my RADIUS is down - so I could only test, what is already working in the current edition.
I don't know how long the hardware will be for repair, so I have to wait for this test.

I still appreciate all that has been done here and I will still participate here as far as I can.