#12 l2tpns not closing tunnels correctly
l2tpns manages its tunnels in a way that is causing us some headaches. We are not receiving radius accounting-records for STOP events when each user disconnects, and we are seeing events in l2tpns's logs indicating not-so-graceful tunnel-disconnects, regardless of the users' disconnect-method.
It seems as if l2tpns does not acknowledge tunnels being terminated (either deliberately by the user, or due to a failure on the client-side), and as a result, is not sending a STOP-accounting Radius record to our logs when it should.
We ARE successfully receiving START and INTERIM-UPDATE records ..... but STOP records show up rarely (and sporadically).
Observe this variety of different 'disconnect events' in our logs:
2011-03-29 12:29:34 01/00 Shutting down tunnel 1 (Stopped)
2011-03-29 12:29:51 03/00 New tunnel from PUB.IP.PUB.IP:52984 ID 3
2011-03-29 12:30:07 03/00 Out of sequence tunnel 3, (5 is not the expected 4)
2011-03-29 12:30:20 02/00 Kill tunnel 2: Expired
2011-03-29 12:30:20 02/00 New tunnel from PUB.IP.PUB.IP:58116 ID 2
2011-03-29 12:30:31 02/00 Out of sequence tunnel 2, (5 is not the expected 4)
2011-03-29 12:30:37 04/00 New tunnel from PUB.IP.PUB.IP:59366 ID 4
2011-03-29 12:30:44 01/00 Kill tunnel 1: Expired
2011-03-29 12:31:00 04/00 Out of sequence tunnel 4, (5 is not the expected 4)
2011-03-29 12:31:12 01/00 New tunnel from PUB.IP.PUB.IP:60088 ID 1
2011-03-29 13:00:16 01/00 Kill tunnel 1: Timeout on control message
2011-03-29 13:01:45 02/00 Out of sequence tunnel 2, (5 is not the expected 4)
2011-03-29 13:03:49 02/00 Kill tunnel 2: Timeout on control message
However, as I said, we ARE seeing acknowledgments that the session STARTS and we receive very timely INTERIM-UPDATES for still-connected sessions.
We have tried a few releases (2.1.21-1.1, 2.1.21-1.5 and we also custom-compiled our own 2.1.21-1.5 build with which to test).
We are testing on Debian Lenny amd64.
Same probleme here even with CSV build 2.2.0