First...most NASes, if they don't receive a reply during a certain window, they resend the packet. So perhaps the connectivity between you and the NAS is spotty at times, or many other factors that would inhibit a reply from FreeRADIUS.
I personally only rely on the Acct-Unique-Session-Id that FreeRADIUS generates (I'm assuming this is what you meant when you said AcctUniqueIDs, if not, enable acct_unique in the accounting group). However, from what I've seen, FreeRADIUS 0.8.1's acct_unique key's default setting is "User-Name, Acct-Session-Id, NAS-IP-Address, Client-IP-Address, NAS-Port-Id". I don't know about you, but the NASes I typically deal with (Cisco AS5300s, Ascend MAXes, and USR TotalControls) don't seem to send a NAS-Port-Id attribute, which would result in the same user having the same unique session ID, if they were to a) establish a second connection for the purpose of multilink PPP, or b) disconnect and reconnect to the same NAS. So long story short, if you have the default setting, that might be why you see the same unique session ID. Second, the 5 second delay probably is a clue. That's probably the setting on the NAS for trying to retransmit an accounting packet it never received a reply for. Another attribute you should look at is Acct-Delay-Time, that tells you how long this packet has been delayed before sending. If you take a closer look at the detail you included, the second packet has a delay time of 5, so if you see the exact same attributes in packets that arrive sequentially BUT the delay time is incrementing, it's safe to say that those packets are for one session only. The reason you only see one login in radius.log is due to the cleanup_delay setting. Looks like the default setting is helping you, read this snippet: # cleanup_delay: The time to wait (in seconds) before cleaning up # a reply which was sent to the NAS. # # The RADIUS request is normally cached internally for a short period # of time, after the reply is sent to the NAS. The reply packet may be # lost in the network, and the NAS will not see it. The NAS will then # re-send the request, and the server will respond quickly with the # cached reply. # # If this value is set too low, then duplicate requests from the NAS # MAY NOT be detected, and will instead be handled as seperate requests. Third, I wouldn't necessarily put the blame on the NAS itself, but the connectivity between the NAS and your RADIUS server, and possibly the load/CPU usage on your RADIUS server. Fourth, I think at this point, we've eliminated the possibility of dirty phone lines, but underlined why it could possibly be bad transit. One rule of thumb to use in the future is to start with a blank configuration file, and manually add settings and such by hand AFTER you've looked over the default/stock configuration, rather than putting the default configuration (which might not be any good for you) into production. -- Omachonu Ogali DialAssurance, Inc. [EMAIL PROTECTED] (888) 524-2551 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
