Nick Warr wrote:
We have a central radius server, and a few point to point connections where we have our point to multipoint connections (base stations) each base stations is a NAS, which for the most part works just fine. Our problem happens if something interrupts the point to point connectivity, the PPP sessions between the CPEs and the base stations remain up, but on the radius side, if the point to point connection remains down for longer than the idle timeout, the user (at least for freeradius) is disconnected.
I have no idea what that means. The RADIUS server doesn't "disconnect" users after an idle timeout. Did *you* configure the server to do this? If so, *SAY SO*. This is *not* in the default config. We do *not* have access to your configuration, and we *cannot* read minds.
The NAS however, remains unaware of this (as the UDP disconnect message didn't arrive.. link down and all that),
What's a "UDP disconnect message" ?
and the user remains up and functional, but we no longer have any accounting for that user. This of course, we can reset by hand, but if it happens during the night for example, we could lose several hours of accounting.
This really sounds like a routing problem. The network goes down, comes back up, and the NASes don't send packets to the RADIUS server. If the user session is up, the NAS should continue to send accounting packets. If it doesn't, it's broken.
What I'd like to know is if freeradius 2.x has some sort of functionality we can configure to make sure that if the radius server is receiving accounting packets for an account which should be disconnected, that it will re-send the PoD to get the NAS to actually disconnect it.
So you're sending PoD from the RADIUS server? Perhaps you could describe what you're doing, without making the assumption that we're familiar with your local configuration. Alan DeKok.