On Feb 24, 2025, at 5:14 AM, Conrad Classen <conrad.classen@gmail.com> wrote:
We have seen similar cases, and were able to use the IMEISV field to identify the devices on our APN's.
Were other attributes for the session stable? i.e. NAS-IP-Address, NAS-Port, etc. If so, that could help too. Note that RFC 2866 doesn't say that the values of NAS-Identifier, etc. must be stable across all accounting packets for one session. So yes, there are vendors who send different values.
It seems that there are some newer devices that attempt to build connections on top of a connection, even if it has not accepted the Access-Accept Response even though it was Authenticated.
<sigh> I've updated the RADEXT Wiki with this information.
Further to this, we had to get the developers for the devices involved, because they were taking short-cuts to ensure connectivity as fast as possible instead of complying with the AAA standards.
For the future, please reach out to me via email. I am more than happy to join any conversions via email, or even calls, no matter what the time / time zone. These kind of issues cost me time and money. They cost FreeRADIUS users time and money. It's worth my time to join any conversation about broken NAS equipment, and then to pull rank on the vendor. I've generally
On some devices, the number of connectivity attempts was 19 before the Radius had even responded with the Access-Accept, each with their own Session-Id to the same device.
I can't even imagine the situation where this would ever be a good idea. The vendors are going out of their way to do extra work which is stupid, useless, and broken. At this point, it looks like it's becoming necessary to update the RADIUS RFCs. That is generally the only way to fight back against such vendor craziness. Alan DeKok.