> > It's not a dupe because it is different, that's the point. It is not > > the same set of a/v pairs that was originally sent. I don't see anything > > violating the RFC here. > > Hmm... Maybe I'm wrong here, assuming that NAS should re-send > packet with the same id. But then what the "duplicate" requests for? > And in which case should we expect 'em?
RFC 2865 says: "The Identifier field MUST be changed whenever the content of the Attributes field changes, and whenever a valid reply has been received for a previous request. For retransmissions, the Identifier MUST remain unchanged." In Access Requests usually all attributes remain the same when retransmitting. In that case the NAS would use the same identifier and you might see 'duplicate' request on the Radius server. Accounting Requests are slightly different if your NAS includes the attribute Acct-Delay-Time. This needs to be updated in each retransmit, and since now the contents of the packet change, a new Identifier is needed. Here is the relevant section from RFC 2866: " Note that if Acct-Delay-Time is included in the attributes of an Accounting-Request then the Acct-Delay-Time value will be updated when the packet is retransmitted, changing the content of the Attributes field and requiring a new Identifier and Request Authenticator." Without this attribute the NAS can use the same identifier and you might still see 'duplicate' requests on the server. So the Cisco NAS seems to be RFC-compliant (atleast in this respect)! Puneet _______________________________________________ No banners. No pop-ups. No kidding. Introducing My Way - http://www.myway.com - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
