________________________________________ From: freeradius-devel-bounces+vladimir.grujic=oriontelekom.rs@lists.freeradius.org [freeradius-devel-bounces+vladimir.grujic=oriontelekom.rs@lists.freeradius.org] on behalf of Arran Cudbard-Bell [a.cudbardb@freeradius.org] Sent: Wednesday, October 17, 2012 12:15 PM To: FreeRadius developers mailing list Subject: Re: problem with radclient On 17 Oct 2012, at 10:48, Vladimir Grujić <Vladimir.Grujic@oriontelekom.rs> wrote:
I am just pointing out that this is not occurring when packet is sent directly over wire without PACKET-Src-IP-Address mangling over originating ip on another setup (same binaries) to the same nas.
... so the NAS probably doesn't have the correct shared secret associated with the src IP address in the packet. Check your traces to see that it's set to what you expect. if packet is created to come from PACKET-Src-Ip-Address then i have the correct secret. In your attribute list include the AVP: Message-Authenticator = 0x00 your NAS will probably stop responding to disconnect requests (if it actually validates the Message-Authenticator). It responded with an Disconnect-ACK again Read through the code in radclient.c https://github.com/FreeRADIUS/freeradius-server/blob/master/src/main/radclie... The call to rad_verify is just using the secret specified on the command line, it is not dependent on src IP address. UDP packet headers are *NOT* used when calculating the Message-Authenticator as shown by the RFC snippet I posted previously. I will need to go trough the code again... -Arran - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html