[Bug 258527] wpa_supplicant(8) from the base is not able to bring up wlan(4) interface correctly due to SIGSEGV after EAP/PEAP MSCHAPv2 authentication

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258527

--- Comment #17 from Cy Schubert <cy@FreeBSD.org> ---
(In reply to Marek Zarychta from comment #16)

> We should all take it easy, it is a minor breakage and probably no other setups except mine are affected. On the other hand, the security/wpa_supplicant from ports still works as intended.

The problem is similar to the one fixed in -CURRENT during testing of the
import of WPA that supported WiFi 6. It was fixed there during testing however
this PR clearly shows that the problem wasn't the WiFi 6 wpa but instead the
restructuring. The fix is the same.

The fix will be MFCed into stable/12 and stable/13 in about two months anyway.
It's the same fix that I posted here that I should have bisected and committed
before committing WiFi 6 but I understood at the time that this was a WiFi 6
wpa problem but in fact it was with how I structured the Makefiles. The fix is
an MFC of a tiny part of what will be MFCed.

> The QA process takes some time, the same for debugging and writing patches, but also taking dumps and testing patches requires some time and effort including either driving tens of miles or recreating EAP/PEAP secured network in the home lab.

This is appreciated. I had access to EAP/PEAP at $JOB but now we are #WFH. The
office is permanently closed and I work from home now. The commute is great but
access to EAP/PEAP not so great.

> I have no insight into @freebsd.org e-mail server setup, but believe it does some false positives marking messages as SPAM what makes writing direct email messages a bit hopeless.

FreeBSD mail servers don't block spam. I have a .forward at freebsd.org which
forwards to my cschubert.com, which runs spamassassin on my mail gateway. It
add SPAM headers which are read by procmail on my laptop which files emails
into a SPAM folder. This is totally my fault. I should have checked my spam
folder. I'm sorry.

As to why spamassassin believes your emails are SPAM,

Content analysis details:   (5.5 points, 5.0 required)

 pts rule name              description
---- ---------------------- --------------------------------------------------
 0.2 BAYES_999              BODY: Bayes spam probability is 99.9 to 100%
                            [score: 1.0000]
 3.5 BAYES_99               BODY: Bayes spam probability is 99 to 100%
                            [score: 1.0000]
 0.0 SPF_NONE               SPF: sender does not publish an SPF Record
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 2.0 DEAR_SOMETHING         BODY: Contains 'Dear (something)'
-0.1 DKIM_VALID_AU          Message has a valid DKIM or DK signature from
author's
                            domain
-0.1 DKIM_VALID_EF          Message has a valid DKIM or DK signature from
                            envelope-from domain
-0.1 DKIM_VALID             Message has at least one valid DKIM or DK signature
 0.1 DKIM_SIGNED            Message has a DKIM or DK signature, not necessarily
valid
-0.0 NICE_REPLY_A           Looks like a legit reply (A)

> The first conclusion: "no other setups are probably affected" is pretty sad and means that FreeBSD's user base became FreeBSD's consumer base. I have reported this breakage a week or two ago on the net@ mailing list and there was no feedback at all. The FreeBSD consumer base utilizes probably only RELEASEs and cares neither for the development process nor for the quality of the upcoming product.

Sadly many people run -RELEASE.

> The final question which comes here is: Do we really need wpa_supplicant in the base? I was against ftpd(8) removal which IMHO is an imminent part of the FreeBSD OS, but wpa_supplicant can be easily installed from ports. Consumers who have only WiFi access can have the package on the USB stick.

Yes, IMO client utilities should be in base. Server daemons such as hostapd,
krb5kdc, and the like probably should not be. Though, pkgbase would solve a lot
of this.

Developer maintenance time is another factor.

Mozilla and Google have deprecated FTP from their browsers. Soon the only FTP
clients will be the command line clients and those in utilities like filezilla.

Lastly, at $JOB, our F5 does not support FTP. F5 has removed the FTP protocol
from their Internet Gateway product line. I think that eventually FTP won't be
supported anywhere.

It's fine if we wait until the new WPA is MFCed. EAP/PEAP is probably not as
used now that people (like me and others) work from home, permanently.

I'll have to set up EAP/PEAP here. I can use either one of my computers
downstairs as I use hostapd on it to test or I have a AP that can be configured
to use radius. I'll need to set up a radius server with Kerberos authentication
to test. Probably a good idea anyway.

-- 
You are receiving this mail because:
You are on the CC list for the bug.