On May 3, 2019, at 11:46 AM, Oscar <oscar@jofre.com> wrote:
I do not know whether to laugh or cry :)
That's because of bad vendors.
Can I share your answer to mikrotik ?
Sure. It's a public response.
About:
The only real solution here is to *remove* the entry from the accounting table when you get a stop. But you might *not* get a "stop" packet, so even that solution isn't perfect.
I think it would be the same, instead of remove the radacct row, as we have also a radacctid unique to update acctuniqueid with (acctuniqueid+radacctid) when acctstoptime (stop accounting) comes. And of course on stale sessions the same, if stop packet doesn't come.
Yup. All Mikrotik has to do to fix this is to update their Acct-Session-Id to include the 32-bit Unix time of when the session started. They *already* track this information in the user session. It's likely a 3-line patch. We can't do a similar work around in FreeRADIUS. If we did, it would look like this: * on every accounting packet, query the accounting table for existing / matching sessions * if an existing session is found, AND the current packet is MAYBE not matching (due to Acct-Session-Time), THEN close the old session and create a new one BUT we can't do this, because UDP packets can get lost. Accounting packets can also be delayed for hours. So we have no idea if the "new" packet is really new, or is just a delayed "old" packet. So this fix won't work. The general poor nature of the RADIUS protocol prevents us from working around stupid vendors. Since we can't change the RADIUS protocol, we're left with bitching at the vendors. The only way to fix this issue permanently is for the NAS vendor to update their equipment so that it isn't crap. Alan DeKok.