Hi,

I have been using L2TP VPN protocol and I have noticed that when a user closes the connection I am getting a log record like this: "myVPNuser logged out, 14400 262941154 2621688857 1168198 2971793 from ipAddress"

What do these numbers 14400 262941154 2621688857 1168198 2971793 represent? I asked chatGPT and it responded that

In Mikrotik logs, the numbers in the record provide specific details about the session metrics and activities. Here's a breakdown of the numbers in the log entry:

• 14400: This likely represents the duration of the session in seconds. In this case, it translates to 4 hours (14400 seconds / 3600 seconds per hour).

• 262941154: This could represent the number of bytes sent by the user during the session. Mikrotik typically logs data usage in bytes.

• 2621688857: This might represent the number of bytes received by the user during the session. Like the previous number, it's also likely in bytes.

• 1168198: This number could represent the number of packets sent by the user during the session.

• 2971793: This number could represent the number of packets received by the user during the session.

In summary, the log entry appears to provide the following information:

• User: myVPNuser

• Action: logged out

• Session duration: 14400 seconds (4 hours)

• Bytes sent: 262941154 bytes

• Bytes received: 2621688857 bytes

• Packets sent: 1168198 packets

• Packets received: 2971793 packets

• IP address: ipAddress

These metrics are helpful for network administrators to monitor user activity and network usage.

Is the response correct?

It was true at least in early Ros, this (very old) documentation mentions that:
https://mikrotik.com/testdocs/ros/2.8/s ... ogging.php

Description

Some log entries, like those containing information about user logout event, contain additional information about connection. These entries have the following format: <time> <user> logged out, <connection-time-in-seconds> <bytes-in> <bytes-out> <packets-in> <packets-out>

Though, unless you made up the numbers, it seems to me that the packet size look strange:
262941154/1168198=225,0826949
2621688857/2971793=882,1909389

Though, unless you made up the numbers, it seems to me that the packet size look strange:
262941154/1168198=225,0826949
2621688857/2971793=882,1909389

hm..I think I copied the log message as it is (except the user and the ip)... e.g. another log that I had today is:

myVPNuser logged out, 356 9363801 332580302 151358 249297 from ipAddress

Yep, I may well be wrong, but the bytes/packets should be a "whole" number, or - even if there are different sized packets - the ratio should be near to an average of some kind.
Your new log entry gives:
9363801/151358=61,86
332580302/249297=1334,07
as said "strange".

I just noticed that the numbers that you were looking at are not the packets size but the bytes size. In the first log: 14400 262941154 2621688857 1168198 2971793:

• Session duration: 14400 seconds (4 hours)

• Bytes sent: 262941154 bytes ~ 250.75 MB

• Bytes received: 2621688857 bytes ~ 2.44 GB

• Packets sent: 1168198 packets

• Packets received: 2971793 packets

The byte numbers seem valid to me. About the packet size, I have not a clue...

Yes, the first three (time. bytes sent, bytes received) are fine, the forth and fifth (packet sent, packet received) are what seem "off", or at least they are logged/calculated in a different way from what I would have expected.

Yep, I may well be wrong, but the bytes/packets should be a "whole" number, or - even if there are different sized packets - the ratio should be near to an average of some kind.
Your new log entry gives:
9363801/151358=61,86
332580302/249297=1334,07
as said "strange".

It's not strange, it's normal. When the traffic is download-heavy and uses TCP, most of the packets being received will be large packets (size close to the MTU). Packets being sent will mostly be ACK packets, which are tiny. And because of something called the TCP window, it's perfectly normal to only send one ACK packet per multiple payload packets received.

Thanks, it makes sense.

The 61 sent and 1334 received seem compatible with small as mainly ACK and large, near to MTU size, averages.

The earlier values of 225 and 882 not so much, maybe those were related to a different use of the connection.