Date: Mon, 20 Sep 2021 22:08:30 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [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 Message-ID: <bug-258527-7501-ovPZoReZtf@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-258527-7501@https.bugs.freebsd.org/bugzilla/> References: <bug-258527-7501@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D258527 --- 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_suppli= cant 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 howe= ver 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 anyw= ay. It's the same fix that I posted here that I should have bisected and commit= ted 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 patche= s, but also taking dumps and testing patches requires some time and effort = including either driving tens of miles or recreating EAP/PEAP secured netwo= rk 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 d= oes 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 whi= ch 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 signa= ture 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessa= rily valid -0.0 NICE_REPLY_A Looks like a legit reply (A) > The first conclusion: "no other setups are probably affected" is pretty s= ad and means that FreeBSD's user base became FreeBSD's consumer base. I hav= e reported this breakage a week or two ago on the net@ mailing list and the= re 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 o= f the FreeBSD OS, but wpa_supplicant can be easily installed from ports. Co= nsumers 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 F= TP clients will be the command line clients and those in utilities like filezi= lla. Lastly, at $JOB, our F5 does not support FTP. F5 has removed the FTP protoc= ol 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 config= ured to use radius. I'll need to set up a radius server with Kerberos authentica= tion to test. Probably a good idea anyway. --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-258527-7501-ovPZoReZtf>