Customer is making an update on their radius server and a behaviour of BNG creates a problem for it. Customer calculates session duration according to accounting stop packet.
They use two attribute on accounting stop packet: Event-Timestamp and Accounting-Session-Time. They make a basic math calculation to find session start time: "Event-Timestamp minus Accounting-Session-Time". They expect to find same value on Accounting Start packet (Event-Timestamp value on Accounting start packet). But there are minor difference between them (1 second).
As per the pcap, Event-Stamp on Accounting start is (packet number 5): - Aug 16, 2024 10:29:28. When we make manual maths calculation on Accounting Stop packet (packet number is 7): Aug 16, 2024 10:36:59 - 452 = Aug 16, 2024 10:29:27
So there is 1 second difference.
After calculating the time manually, we are getting a difference of 1 second.
I went through the packet capture and checked the difference of arrival time between packets 5 and 7.
Let us first look at the frame arrival time:
Packet 5:
Arrival Time: Aug 16, 2024 12:59:27.888044000 IST
Packet 7:
Arrival Time: Aug 16, 2024 13:07:00.125716000 IST
Note that as per the frame arrival time, I could see the time difference to be exactly:
The exact time difference between 13:07:00.125716 and 12:59:27.888044 is *452.237672 seconds*.
5 3.562255 46.196.222.1 172.16.6.124 RADIUS 555 Accounting-Request id=21
7 455.799927 46.196.222.1 172.16.6.124 RADIUS 658 Accounting-Request id=22
455.799927 - 3.562255 = 452.237672 seconds
----------------------------
Coming to the Event Timestamps of Packets 5 and 7 from the 'Attribute Value Pairs' in the Pcap file:
AVP: t=Acct-Status-Type(40) l=6 val=Start(1)
Event-Timestamp: Aug 16, 2024 12:59:28.000000000 IST
AVP: t=Acct-Status-Type(40) l=6 val=Stop(2)
Event-Timestamp: Aug 16, 2024 13:06:59.000000000 IST
13:06:59 minus 12:59:28 gives us 453 seconds.
Whereas, as per the actual timestamp of the issue, we have a difference of 452.237672 seconds.
While subtracting manually, you have rounded off the above value to 452 which leaves us with 0.23 of a second.
Next, the event time stamp of both the packets has been rounded off as we can see from the timestamp. We can see 000000000 after the seconds for both the packets.
Considering the 0.23 seconds offset when you rounded off 452.23 to 452, and the milliseconds left out after rounding off the 2 event timestamps, the exact value could be close to 452.23 seconds, hence not having the 1 second delay.
------------------------------------------------
The issue is only on the mathematics side.
Due to the missing decimals, the difference of 1 second is being seen, if you include the decimals as well, the timing could be correct.
Check if there are any other setups where customer is having a delay of 2 seconds or more, which might indicate an actual issue.