Re: Re-transmits arriving via a different proxy / EAP duplicate detection
On 09/10/12 19:17, alan buxey wrote: Hi, As I iterate through our logging config, I'm gaining increasing visibility of all kinds of peculiar stuff. This one I spotted today - we are seeing remote RADIUS servers (eduroam visited sites) sending retransmits via different intermediate proxies. I've seen this a couple of times int he past - and recently too. the recent one was fixed by ensuring that the RADIUS server was listening only The pattern we see is quite odd. I suspect the core issue is being exacerbated by misbehaving clients or visited-site radius servers. The reason I suspect this is that, if it were genuine packet loss, you'd expect to see retransmits at all stages of the EAP session. But we almost exclusive see retransmits in response to a reject (very common) or an accept (rarely). In particular, there seem to be some sites where retransmits come in if we send a reject. I don't know if this is a particular supplicant or a particular radius server. Or maybe I'm mis-reading the evidence. But it does seem odd... I'm wondering whether to open a JRS support ticket or not (any suggestions ;o) - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Re-transmits arriving via a different proxy / EAP duplicate detection
Phil Mayers wrote: First, the FreeRADIUS duplicate detect / retransmit logic doesn't apply because the source IP, shared secret, Proxy-State and Message-Authenticator are all different, even though all other attributes are identical. This is correct behaviour AFAICT from the RFCs. Second, because the retransmits aren't eaten by the duplicate detection, they arrive as real packets in the server core, but are rejected because the State attribute is no longer valid - this is because FR mutates State on every round-trip, mixing in the EAP type/id/exchange number. There is a solution. But it involves new code. Does anyone have any thoughts on the matter? Absent RADIUS-over-TCP, this seems like a really tricky one... Nah. Create a new state tracking module. a) runs before sending reply, and caches State - request/reply b) runs on receiving packet, and looks for duplicate state if found, and request looks similar, send duplicate reply That would bypass all of the EAP code, and add another layer of duplicate detection after the packets are duplicate code. There should really also be a state tracking API in the server core. Certain modules (i.e. securid) roll their own, and it's not overly efficient. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Re-transmits arriving via a different proxy / EAP duplicate detection
Hi, As I iterate through our logging config, I'm gaining increasing visibility of all kinds of peculiar stuff. This one I spotted today - we are seeing remote RADIUS servers (eduroam visited sites) sending retransmits via different intermediate proxies. I've seen this a couple of times int he past - and recently too. the recent one was fixed by ensuring that the RADIUS server was listening only on a particular IPv6 address - by default it was binding to all available interfaces...and having 2 NICs, it has 2 IPv4 addresses and 2 IPv6 addresses... the IPv4 had been bound to just eth1 as reuqired...but the IPv6 hadnt thus, whilst the request was arriving at eth1, responses were going out via eth0 First, the FreeRADIUS duplicate detect / retransmit logic doesn't apply because the source IP, shared secret, Proxy-State and Message-Authenticator are all different, even though all other attributes are identical. This is correct behaviour AFAICT from the RFCs. correct.and the EAP session gets really broken We're also generating a lot of logging and noise, though that's an internal problem. thats a side effect of more 802.!x action - and one we too are dealing with locally (locally, a campus site deals with far more traffic than other systems that I deal withthe difference is that you have direct control over your NAS kit and local infrastructure and can fix things..). we've already gone through several iterations of optimising PGSQL, indexing, clearing and having 1st-line access what they need etc. doing dot1x/mab/webauth on switches just adds to the noise/mix. ...and the hundreds of misconfigured devices... certificate errors...TLS issues, wifi causing problems with failed EAP etc. alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
