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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
