eduroam wifi doesn't work

Hello.
So i recently switch from Arch to FreeBSD so i might be a noob sorry.

debug info:
FreeBSD freebsd 14.1-RELEASE FreeBSD 14.1-RELEASE releng/14.1-n267679-10e31f0946d8 GENERIC amd64
my rc.conf : https://pastebin.com/ii05znEE

my wpa_supplicant conf
Code:
 ctrl_interface=DIR=/var/run/wpa_supplicant
eapol_version=2
fast_reauth=1

network={
   ssid="IONIS"
    key_mgmt=WPA-EAP
    eap=PEAP
    identity="mo*****me@epitech.eu"
    password="***"
    phase2="auth=MSCHAPV2"
 }

I already tried mostly every single other eduroam config that i could find on internet
but the people on linux (Ubntu / Arch) have the exact same config and are able to connect. so i really don't know.
And i can connect to my phone hotspot / home network.

Code:
<3>Trying to associate with d8:54:a2:36:1e:e5 (SSID='IONIS' freq=5180 MHz)
<3>Authentication with d8:54:a2:36:1e:e5 timed out.
<3>CTRL-EVENT-DISCONNECTED bssid=d8:54:a2:36:1e:e5 reason=3 locally_generated=1
<3>CTRL-EVENT-DSCP-POLICY clear_all
<3>CTRL-EVENT-SCAN-RESULTS
<3>WPS-AP-AVAILABLE
<3>Trying to associate with d8:54:a2:37:56:25 (SSID='IONIS' freq=5200 MHz)
<3>Authentication with d8:54:a2:37:56:25 timed out.
<3>CTRL-EVENT-DISCONNECTED bssid=d8:54:a2:37:56:25 reason=3 locally_generated=1
<3>CTRL-EVENT-DSCP-POLICY clear_all
<3>CTRL-EVENT-SCAN-RESULTS
<3>WPS-AP-AVAILABLE
I am sure of my credentials
 
Thread 66528 discusses seeing error messages specific to EAP when the problem is with EAP, which you don't seem to have. That's probably not the problem.

These events look like a good clue:

<3>CTRL-EVENT-DISCONNECTED bssid=d8:54:a2:36:1e:e5 reason=3 locally_generated=1

One of the header files for wpa_supplicant describes the meaning of CTRL-EVENT-DISCONNECTED in a comment:

C:
/** Disconnected, data connection is not available */
#define WPA_EVENT_DISCONNECTED "CTRL-EVENT-DISCONNECTED "

I couldn't find a definition for "reason" in wpa's documentation, so /google turned up this:


There, the author says he mapped your "reason=3" to:

reason=3 "Deauthenticated because sending STA is leaving (or has left) the BSS"

Googling that error message found a possible explanation on the FortiNet forum:

the message "Disassociated because sending STA is leaving (or has left) BSS" means that the client is moving to another access point using non-aggressive load balancing.

Have you tried connecting from less crowded parts of your campus?

After all of that, I found that the FreeBSD Handbook has an example network configuration for EAP-PEAP authenticated SSIDs, here:


I noticed your network configuration block doesn't have the "proto", "ca_cert", and "phase1" parameters. Perhaps one of them has a default value that's causing this problem? My read on wpa_supplicant.conf(5) is that, without specifying a path to a trust anchor with "ca_cert", wpa won't authenticate the server you're authenticating to.

Also, while it is an old thread, Thread 43651 discusses some things you could try.
 
I tended to use:

Code:
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=wheel

network={
    ssid="eduroam"
    key_mgmt=WPA-EAP
    eap=PEAP
    identity="<username>@<institute>"
    password="<password>"
}

Admittedly that was on OpenBSD and there are some differences in the wifi stack. But it might still work. I based mine on the old article here.
 
There's even an example EduRoam configuration in the Examples section of wpa_supplicant.conf(5), it turns out:

Code:
     ctrl_interface=/var/run/wpa_supplicant
     ctrl_interface_group=wheel
     network={
             ssid="eduroam"
             scan_ssid=1
             key_mgmt=WPA-EAP
             eap=TTLS
             identity="user@example.org"
             password="foobar"
             phase2="auth=MSCHAPV2"
     }
 
Well, wow. It's 2025, and the FreeBSD wifi stack still shows no sign of getting buttoned down like it is on Android/iphone/Win/Linux... Even with a working hardware driver, the procedure to connect/disconnect reliably is still an issue.

How come people in older threads are so dismissive of a legitimate usability issue, I'll never know.

I'm grateful that somebody's making the noise, maybe that will motivate the FreeBSD devs to get their act together. I know they are prioritizing enabling N-speeds in FreeBSD (after supporting only G-speeds), but reliably connecting/disconnecting from wifi shouldn't involve having enough knowledge to spend hours on research to figure out what goes into weird .conf files.
 
but reliably connecting/disconnecting from wifi shouldn't involve having enough knowledge to spend hours on research to figure out what goes into weird .conf files.
It is the same process as on Linux. wpa_supplicant(8) is generally the standard and has been for years.

If you mean FreeBSD doesn't have a GUI WiFi program to make this process easier for non-technical users, well that is because FreeBSD doesn't have a desktop environment. It kind of steals them from Linux, so of course things are going to be missing.

This is one of my main arguments against FreeBSD not just grabbing Gnome/KDE in its default install, it will make a mess *and* still be absolutely unsuitable as a desktop-centric OS.

I think there is wifimgr(8) but people tend not to use it because GUI tools do tend to be less powerful (and tend to rot). There are a few different wifi GUI tools in ports, though WPA2-enterprise is by its nature a little more complex so they likely don't support it.

(I even remember RHEL8's GUI NetworkManager failing to connect to a corporate wifi once. It didn't allow TTLS *and* PEAP to be specified so roaming was broken and 50% of the connects would fail. If sodding Red Hat can't get this stuff right....)
 
It is the same process as on Linux. wpa_supplicant(8) is generally the standard and has been for years.

If you mean FreeBSD doesn't have a GUI WiFi program to make this process easier for non-technical users, well that is because FreeBSD doesn't have a desktop environment. It kind of steals them from Linux, so of course things are going to be missing.

This is one of my main arguments against FreeBSD not just grabbing Gnome/KDE in its default install, it will make a mess *and* still be absolutely unsuitable as a desktop-centric OS.

I think there is wifimgr(8) but people tend not to use it because GUI tools do tend to be less powerful (and tend to rot). There are a few different wifi GUI tools in ports, though WPA2-enterprise is by its nature a little more complex so they likely don't support it.

(I even remember RHEL8's GUI NetworkManager failing to connect to a corporate wifi once. It didn't allow TTLS *and* PEAP to be specified so roaming was broken and 50% of the connects would fail. If sodding Red Hat can't get this stuff right....)
Y'know, there's also bsdconfig wireless, but even that lags behind Android/iphone/Windows when it comes to reliably connecting.

Enterprise wifi is a very different beast from public or consumer/private wifi. I'd know, I have wrangled with it at $JOB, learned the correct settings (of just one workplace) cold.

Sometimes, you don't need the power of options, you need the power of reliability. After all, isn't it the UNIX principle of Keep It Simple, Stupid? it's plenty applicable to wifi, as well. Just like nobody wants to be required to know how to use brainfuck or assembler to simply get the correct output of /bin/ls, nobody should be required to spend hours of researching what different details mean in /etc/wpa_supplicant.conf just to be able to reliably connect to a random public wifi hotspot.
 
Enterprise wifi is a very different beast from public or consumer/private wifi. I'd know, I have wrangled with it at $JOB, learned the correct settings (of just one workplace) cold.
Then as you know, setting *up* a RADIUS backed WPA2 Enterprise system is so much easier on FreeBSD and Linux than on Windows or macOS.

So no, I disagree. Sometimes a config file and standalone daemon *is* the easier choice.

Sometimes, you don't need the power of options, you need the power of reliability. After all, isn't it the UNIX principle of Keep It Simple, Stupid? it's plenty applicable to wifi, as well.
KISS almost always translates to "using a config file". KISS means the exact opposite of big heavy GUIs for non-technical users. I am indeed a big follower of the principle myself.

Just like nobody wants to be required to know how to use brainfuck or assembler to simply get the correct output of /bin/ls,
Thats fine then. You don't need to know assembler to use wpa_supplicant.

They are different use-cases that won't ever change. The world will rarely use FreeBSD directly as a consumer/user-friendly desktop OS. Likewise the world will rarely use Windows for WPA2 Enterprise wifi appliances. And thats fine; both roles are mutually exclusive and merging them will make them both suck at their corresponding tasks.
 
Then as you know, setting *up* a RADIUS backed WPA2 Enterprise system is so much easier on FreeBSD and Linux than on Windows or macOS.
It's not about servers or routers. Don't mix those with client devices like phones and laptops.

If I were setting up a server or an AP, then sure, I do need to know about handing out certs and the rest. If a phone can connect reliably without user even knowing much about what's happening (i.e. wpa_supplcant details configured on the phone), why not a laptop running FreeBSD?

Having a clear idea of what a server/hotspot is supposed to do vs what a client/phone/laptop is supposed to do is essential. It's a divide-and-conquer approach, with reliabiity as goal.
 
It's not about servers or routers. Don't mix those with client devices like phones and laptops.
It is. FreeBSD is about servers and routers.

FreeBSD doesn't run on phones and is always going to be unsuitable for the use-case as a non-technical laptop OS compared to other, tailored operating systems.

This is because a decent server OS is mutually exclusive to being a decent consumer OS.
 
It is. FreeBSD is about servers and routers.

FreeBSD doesn't run on phones and is always going to be unsuitable for the use-case as a non-technical laptop OS compared to other, tailored operating systems.

This is because a decent server OS is mutually exclusive to being a decent consumer OS.
Then how come the Foundation is sponsoring a Working Group to focus on laptops?

How come the Foundation is making noise about enabling N-speeds (which are triple the G-speeds that FreeBSD supported so far) ?

It is very much in line with UNIX principles to do one thing and do it well. Just like we don't expect /bin/ls to sort the output (/bin/sort takes care of it), connecting a client device (like a laptop running FreeBSD) shouldn't require a degree in Computer Science and patience to spend hours researching what the details in wpa_supplicant mean, and what values are correct for which hotspot. That stuff really needs to be automated and more importantly, reliable.

So yes, it is about servers/routers vs client devices. Mental distinction between the two (and realizing that we need specifically the client devices to be reliable in connecting) is going to be the difference maker. Base installation of FreeBSD frankly has what it takes to connect, I think it's just a matter of making the connection process behave reliably.
 
Then how come the Foundation is sponsoring a Working Group to focus on laptops?
Exactly because as I said, FreeBSD focuses on servers. It needs intervention if laptops are going to have any chance as a viable target. More specifically, people who are interested in this will have to write the tools.
It is very much in line with UNIX principles to do one thing and do it well. Just like we don't expect /bin/ls to sort the output (/bin/sort takes care of it),
Just like wpa_supplicant only deals with the raw WPA packet injection rather than DHCP or "user-friendlyness". Use the right tool for the job.
connecting a client device (like a laptop running FreeBSD) shouldn't require a degree in Computer Science and patience to spend hours researching what the details in wpa_supplicant mean, and what values are correct for which hotspot. That stuff really needs to be automated and more importantly, reliable.
It is expected to be raw and clean if running FreeBSD. It should be more user-friendly if running a desktop-centirc fork. Otherwise why does GhostBSD, NomadBSD, etc exist?

Reliability is generally best guaranteed by keeping things simple. Unless there is a hardware / driver issue, it *is* very reliable when configured correctly is it not? Arguably I would say FreeBSD's wifi is one of the most reliable out there, which is amazing considering a fairly large lack of upstream hardware vendor support. FreeBSD must be doing something right.

In short, people don't run Windows Server Core and then complain that there is only a command prompt and no easy-to-configure GUI wifi tool. This is pretty much comparable to a minimal FreeBSD base.

In principle, I don't disagree with you that a simple port to install which will suddenly "make FreeBSD easy" would be great but how many decades has it been? Arguably since the loss of Gnome 2 and KDE 3.x, plus the weirdness with the out of tree drm/kms drivers, FreeBSD is now *less* user-friendly than it has ever been. Do you think FreeBSD is going to seriously change and become suitable for the general public any time soon? It is clearly Darwin vs macOS and IMO FreeBSD will be most useful focusing on being a great Darwin because it will never be a great macOS compared to the competition.
 
My take is that wpa_supplicant merely needs to be told to do its work (of connecting to a hotspot) correctly and reliably. When that job is made more complicated by the lack of distinction between client device and server/router/hotspot, that's when you have a mess that nobody wants to touch, and of course, it follows that wifi is unreliable and complex.

After all, UNIX's basic principles are simplicity and reliability. Just string that together, keep applying that, and yes, wifi is a pretty deserving recipient of those ideals.

FWIW, DHCP is in base, as is SSH server. Even the bootonly image would include those.
 
astyle , kpedersen I think you both have been members of this forum long enough to know that the OP is new to the community, and that this kind of grousing about the project's deficiencies can't make a good impression. I agree with most of the points you both make, but you know there are better places to make them than a thread requesting help.

iwantwifiplease, Mateusz Piotrowski posted a script he wrote to the FreeBSD wiki to configure his machines to attach to EduRoam:


In it, he seems to indicate that he sets fast_reauth to 0 when troubleshooting, which you might consider trying.
 
astyle , kpedersen I think you both have been members of this forum long enough to know that the OP is new to the community,
New to the Forums, yes. N00b, no, not by a long shot. I could kind of tell that OP has a decent handle on networking, and would be willing to look at documentation if pointed to it. I actually have respect for that.

Thing is, in these Forums, we do have a crowd who tend to be very blunt in their assessment of reality. Sometimes, reality is unflattering. My take is, if one is upfront about their own unflattering realities, that merits more respect than trying to hide it. For example, I suck at Git. Being upfront about it actually really helps, I either look for a solution that still gets the job done using a different tool, or I bite the bullet and study the git command that SHOULD do the job.

And same with wifi. Yeah, FreeBSD's wifi support could use improvement. Knowing the realities (of how wifi works on FreeBSD) is very helpful when looking for a solution.

I'd say that there's kind of a difference between personal attacks and merely pointing out unflattering realities. And, the point of talking about unflattering realities in this thread was, IMHO, more about stirring the pot and making noise. When there's recent noise about an issue, it's got better chances of getting noticed by devs and resolved. That's how Open Source works.
 
To all the people discussing FreeBSD and WiFi: I love FreeBSD but I have no problem with admitting that setting up WiFi isn't as easy as it is on any other platform. It can't be the best in everything *shrug*

iwantwifiplease: have you tried actually using "eduroam" as your SSID?
"IONIS" definitely doesn't look right in your config.
 
Back
Top