On Mon, Feb 24, 2025 at 12:15 PM 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.
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.
I'm currently testing with a Huawei B535-932 router but the experience is the same for probably all of our customers' IoT devices.
From what I've seen, if I force the router to only connect on 3G, I get one Session - Start to Finish and with a single Acct-Session-Id - Everything seems to work perfectly. If I force the router to use 4G only, then I see multiple connections. Almost like it's establishing connections on top of connections.
When the router boots up and latches to the network, I get an authentication request. Once the auth request is accepted, I get the accounting start packet and subsequent interim updates. All of the updates are with 0 Acct-Input-Octets and Acct-Ouput-Octets. At this stage the router has not made any data connection to the network, it has only latched onto the network. As soon as I enable the mobile data connection, that's where things get interesting.
New Authentication Request < Access Accept sent back
Accounting Stop packet for the initial auth request "to latch onto the network" < Sent Accounting response
Receive Accounting Start Packet - B9033604530D06A0 < Sent Accounting Response
Receive Account Stop Packet - B9033604530D06A0 - Acct-Terminate-Cause = NAS-Request ** < Sent Accounting Response
Receive Access Request - NSAPI 5 < Access Accept sent back
Receive Accounting Start Packet - B9033604530D00CE - NSAPI 5 < Sent Accounting Response
Receive Access Request - NSAPI 6 < Access Accept sent back
Receive Accounting Request - Stop Packet - B9033604530D00CE - NSAPI 5 < Sent Accounting Response
Receive Accounting Request - Start Packet - B903360453110451 - NSAPI 6 < Sent Accounting Response
Receive Auth Request - NSAPI 5 < Sent Access Accept
Receive Accounting Request - Start - B903360453050473 - NSAPI 5 < Sent Accounting Response
Receive Accounting Request - Stop - B903360453110451 - NSAPI 6 < Sent Accounting Response
Receive Access Request - NSAPI 6 < Sent Access Accept
Receive Accounting Request - Start - B90336045315039C - NSAPI 6 < Sent Accounting Response
Receive Accounting Request - Interim Update - B903360453050473 - NSAPI 5 | Acct-Input-Octets = 1742 | Acct-Output-Octets = 0 < Sent Accounting Response Received Accounting Request - Interim Update - B90336045315039C - NSAPI 6 | Acct-Input-Octets = 0 | Acct-Output-Octets = 5279 < Sent Accounting Response Received Accounting Request - Interim Update - B903360453050473 - NSAPI 5 | Acct-Input-Octets = 1742 | Acct-Output-Octets = 0 < Sent Accounting Response
Disabling the Data Session :
Received Accounting Request - Stop - B90336045315039C - NSAPI 6 | Acct-Input-Octets = 0 | Acct-Output-Octets = 9936 < Sent Accounting Response
Received Accounting Request - Stop - B903360453050473 - NSAPI 5 | Acct-Input-Octets = 3197 | Acct-Output-Octets = 0 < Sent Accounting Response
To me, it looks like on 4G, there are two sessions being established, one for "up" traffic and one for "down" traffic as I have noticed that those interim accounting packets only ever contain either Acct-Input-Octets = 0 **or** Acct-Output-Octets = 0 and the NSAPI values are 5 and 6. In which case, the Acct-MultiSession-Id would have been great to track usage on sessions within the same "session", although I'm not sure if this would be seen as a MultiSession?
The connectivity is too slow, and it is being dropped, more specifically to Ericsson APN systems. We had to ensure that the APN was enforcing "Simultaneous-Use = 1" and that the Session Timeout did not exceed 1 day.
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.
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.
Most of these devices had modems made in China, but not all.
Hi Guys
This might be off topic but I was wondering if someone with more knowledge than me, would be able to confirm the following :-
In a mobile network scenario with thousands of IoT devices
On our radius servers, we've been noticing a lot of 0-byte sessions on our databases and upon investigation, we've seen the following behaviour :-
Authentication Request Received < Access Accept sent back Accounting Start Packet Received with a Acct-Session-Id < Acknowledgement sent back Interim Accounting Packet Received - This time with a different Acct-Session-Id for the same connection ** At this point, things start going bad as we are not able to update the original DB entry created with the Acct Start Packet, since the Acct-Session-Id differs between the packet received in the Accounting Start Packet and the Interim Accounting Packet.
This results in a 0-session entry in the DB for the Accounting Start Packet entry as a new entry is written into the DB based on the new Acct-Session-Id received in the Interim Accounting packet.
Any subsequent packets received with a different Acct-Session-Id, results in writing a new DB entry when the Interim Accounting Packet is received.
We queried this with the upstream provider, and they advised that the 3GPP-NSAPI number changes when packets are received and they claim that the Acct-Session-Id on their side would change based on the 3GPP-NSAPI value that could (and in most cases) changes.
< Acknowledgement Sent back
From what I've been reading, The Acct-Session-Id should remain constant for the entire PDP context/session, even when the NSAPI changes because the Acct-Session-Id is meant to uniquely identify the entire user session. NSAPI changes are considered sub-sessions within the main PDP context and keeping the same Acct-Session-Id helps maintain session continuity for billing and tracking purposes, which is exactly our use case for accounting which is not working as expected.
Any thoughts and insights would be appreciated if someone faced a similar situation.
Many thanks, Gabriel - List info/subscribe/unsubscribe? Seehttp://www.freeradius.org/list/users.html
On 2025/02/24 09:05, Gabriel Marais wrote: - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html