"[sql] stop packet with zero session length" problem

[Brian Candler]

> But these two are accounting packets. We start to see these after the
> authentication and authorization phases are completed, right? So I assume
> at this stage, the user has already been authenticated. Do I assume wrong?
>
> And why do we see exchange of data but no session time? I think this is another bug in the firmware.

I have seen NASes which send a Stop accounting record (with zero session time) for authentication failures.
But you're right that the Start record *does* imply authentication was OK.  So it might mean the client disconnected
immediately after authenticating.

Any session with duration less than one full second I would expect to see as zero.

> Yes, the user*was*  online after the exchange. The first packet*is*  entered into radacct table,
> but the second packet is not.

What I asked was whether you had any evidence that the user was in fact online after the Stop record was sent.  The accounting records say the user was *not* online, and in the absence of evidence to the contrary, I am inclined to believe them.

If you go through your radacct table and find a subsequent Start record for the same user a few seconds later, then that would be evidence that the user did in fact disconnect and then started a new session, i.e. the AP is telling the truth.

If the user is still online and sending/receiving packets after the Stop record was sent, but no further Start packet has been seen, then you have evidence that the Stop packet was incorrect.

> I believe it is FreeRADIUS that refuses to accept the second packet because my stored procedure
> a) does not care about what session length it receives as an argument,
> b) can not create entries is the system log.
>
> And I am afraid I can't send you the debug log, since I retrieve all my data from a live network.

What you seem to be saying is: "I think freeradius 2.2.9 is broken, but I can't provide any direct evidence to back up the assertion nor information to help the developers fix it, and by the way I'm not prepared to update to a current and supported version either"

I think you need to get into a position where you can collect more information. For example: a live network obviously should have more than one RADIUS server for redundancy. Can you perhaps run one in debug mode and the rest in normal mode?  Even if the debug instance can't keep up with a full load, the others should take up the slack.

Or stop the server, run in debug mode for 5 seconds and replicate the problem, then start the server in normal mode again.

The debug output will probably identify the issue for you.  If it's a config issue on your side, a database problem, or a NAS problem then you can proceed to fix.

But if it *did* happen to be a FreeRADIUS problem, remember that nobody is going to release a version 2.2.10 for you.  And even if they did, and you got 2.2.9 from an OS package, the OS vendor would need persuading to package 2.2.10.

So in that case, you'd have to make your own patch and build/deploy it yourself (this is open source, so help yourself). IBut it would probably be easier for you to deploy 3.0.13, which is what many people on this list are running and developing against.

Regards,

Brian.