HotSpot accounting underreports hotspot=auth traffic by ~15% on RouterOS 7.23.3

RouterOS Wireless Networking
1

Hello,

We are investigating a persistent HotSpot accounting discrepancy on RouterOS 7.23.3.

Setup:

  • RB5009 as HotSpot/CAPsMAN controller
  • 9 CAPs / 18 radios
  • one SSID on 2.4/5 GHz
  • WPA2/WPA3
  • ft=yes, ft-over-ds=yes
  • all WiFi interfaces show traffic processing on CAP
  • clients roam frequently between CAPs

We normally see about 15–18% more WAN traffic than in aggregated HotSpot user counters.

To isolate the issue, we added passthrough mangle counters for:

  • all WAN forwarded traffic
  • hotspot=auth
  • hotspot=!auth

Example synchronized test:

WAN forwarded traffic:        26,926,465 bytes

hotspot=auth traffic: 26,926,415 bytes

hotspot=!auth traffic: 50 bytes

HotSpot aggregated counters: 22,606,761 bytes

So virtually all WAN forwarded traffic is recognized as authenticated HotSpot traffic, but HotSpot accounting records about 16% less.

FastTrack normally excludes HotSpot traffic:

connection-state=established,related

hotspot=!from-client,!to-client

We also completely disabled the FastTrack rule and repeated the test:

WAN forwarded traffic:        9,643,285 bytes

hotspot=auth traffic: 9,643,285 bytes

HotSpot aggregated counters: 8,154,479 bytes

Undercount was still ~15.4%, so FastTrack does not appear to be the cause.

In a simple lab setup with one AP and one HotSpot client, HotSpot counters match firewall counters almost exactly.

We also occasionally see much larger daily discrepancies, up to roughly 40%. A 15-minute monitoring script has detected cases where the aggregate:

/ip hotspot user bytes-in/out

/ip hotspot active bytes-in/out

actually decreased between samples.

Normal transfer from /ip hotspot active to /ip hotspot user after session removal was tested separately and worked correctly.

Could this be related to frequent roaming / FT / traffic-processing=on-cap while HotSpot accounting runs on the central controller?

Has anyone seen similar behavior, or is there any known HotSpot accounting limitation/bug in this scenario?

I can provide config exports and per-client test results if needed.

2

Isn't it somehow connected to packet fragmentation? More packets mean more traffic on WAN side to transfer LAN traffic.

3

Update: the likely culprit seems to be User Manager rate limiting / dynamic HotSpot queues.

With all UM speed limits removed, provider vs HotSpot accounting stayed within ~3–4% for several days, and:

WAN FWD = HS AUTH + HS NONAUTH

I then added a separate 5M/5M rate-limit to user profiles. After re-authentication, dynamic HotSpot queues appeared again.

The next day, the User Manager based daily stats were short by about 10 GB, while mangle counters still matched WAN traffic almost exactly.

So it looks like traffic is forwarded correctly, but UM session accounting under-counts when dynamic HotSpot queues created by UM rate-limit are active.

I’ll remove the rate-limit again and check if the gap returns to ~3–4%.