On 10/12/12 20:00, PENZ Robert wrote:
@PhilMayers: Did you get the Mail with the full logfile? do you need more?
Ok, your NAS is buggy I'm afraid. In some small percentage of cases, it is not handling the wrapping of EAP id values from 255 to 0. The following sequence of (redacted) packets shows the problem (see line ~2389268 in your debug for this example, but there are lots of others in there): Access-Request packet from host NAS port 54217, id=183, length=151 User-Name = "host/blah" EAP-Message = 0x02ff... NAS-IP-Address = NAS Service-Type = Login-User Calling-Station-Id = "MAC" NAS-Port-Id = "x:y" NAS-Port = x00y NAS-Port-Type = Ethernet Message-Authenticator = 0x26710066ee2e161ba4979519e82cde59 ... [eap] EAP packet type response id 255 length 33 ... +- entering group EAP {...} [eap] EAP Identity [eap] processing type tls [tls] Requiring client certificate [tls] Initiate [tls] Start returned 1 ... Sending Access-Challenge of id 183 to 10.15.132.5 port 54217 EAP-Message = 0x010000060d20 Message-Authenticator = 0x00000000000000000000000000000000 State = 0xe043a0c1e043ad9227375e26b2f8cb62 Note that the access-request contains an EAP response with id=255, and we return an EAP request with id=0, having wrapped around. The NAS follows up with: Access-Request packet from host 10.15.132.5 port 54217, id=184, length=241 User-Name = "host/blah" EAP-Message = 0x02ff... NAS-IP-Address = NAS Service-Type = Login-User Calling-Station-Id = "MAC" NAS-Port-Id = "x:y" NAS-Port = x00y NAS-Port-Type = Ethernet State = 0xe043a0c1e043ad9227375e26b2f8cb62 Message-Authenticator = 0x03a814fd68371689281f1e66a4728614 ... [eap] EAP packet type response id 255 length 105 ... rlm_eap: No EAP session matching the State variable. That is - we send an Access-Challenge containing an EAP request id=0, the client responds with an Access-Request containing EAP response id=255. This is obviously wrong. FreeRADIUS mixes certain data into the "State" value with a "xor" including the EAP id - that's why you're getting that particular error message, but the underlying problem is that the NAS is not always handling EAP id value wrap correctly. I'm curious as to why the EAP id values are so large - I don't think most NASes do this, they start from id=1 on every conversation, but I don't know if it's legal. The ID wrapping seems to work in other cases; I'm not certain, but it *may* be that it only fails if the sequence is: C: access-request EAP-response id=255 EAP-Identity S: access-challenge EAP-request id=0 PEAP-start C: access-request EAP-response id=255 PEAP-data i.e. if the initial EAP-identity is the one with id=255. But anyway - I think your NAS is buggy. There's no way you can solve this in FreeRADIUS - you obviously can't rewrite the EAP id, so I think you'll need to open a bug report with the vendor. There is one thing you *might* be able to do which *might* work, but it's dependent on what the NAS does - if I'm right and it's only Identity packets that don't wrap properly, you might be able to detect EAP identity packets and modify the ID and *maybe* the Extreme switch will reply in-sequence. Like so: authorize { if ("%{EAP-Message[0]}" =~ /^0x02ff(....)01(.+)/) { # we have an EAP-identity packet id=255, see if we can force a wrap update request { EAP-Message := "0x0201%{1}01%{2}" } } .... } However - I have no idea if this syntax will even work, and to be honest I'm extremely dubious that, if it does, the Extreme would respond properly. Cheers, Phil