NSAPI changes Acct-Session-Id from upstream provider

[Gabriel Marais]

On Mon, Feb 24, 2025 at 12:15 PM Conrad Classen
<conrad.classen at 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.
>
>
> On 2025/02/24 09:05, Gabriel Marais wrote:
> > 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
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html