Alan DeKok <aland@deployingradius.com> writes:
On Sep 19, 2024, at 4:21 AM, Bjørn Mork via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
Then it turned out that vendor C also must have been working on their BlastRADIUS implementation. Unfortunately, it seems that they only got as far as to make the authentication process crash if the Access-Accept includes M-A. Nice work!
:(
Apologies. I didn't have my facts right. The software running on these routers is older than BlastRADIUS. The bug is actually a couple of years old. It was only recently discovered after RADIUS servers implemented the BlastRADIUS fixes. And we were not the first ones to notice (which would have been a surprise). For those looking, the bug is identified as CSCwk90054 by vendor C, titled "SSH process crashes during log in process using Radius" The description says "This issue has been reported after upgrading Microsoft Server 2022 (acting as Radius Server) to OS Build 20348.2582 - KB5040437. This upgrade was released on July 9, 2024" And with the risk of assuming to much again - I don't think that release date is a coincidence.
Will of course also work with the vendor, but that takes time. And we have a number of routers to upgrade before it's done. Testing is a bit of a hassle when we have to switch FR versions to enable/disable M-A (unless we cheat with a proxy filter).
Arg.
I _really_ don't want to add more configuration flags to work around broken vendor equipment. That kind of nonsense tends to hang around for decades, because vendors go "well, there's a flag to work around it, so we don't have to fix our products!"
I'll see if there's a good solution, but I suspect not. If vendors could ship products which aren't garbage, that would be great...
Yes, thinking more about this I realise that you are right. We are much better off without such knobs. It was a bad idea. Please don't waste any time on it. Bjørn