hi
(Raghu: please read at the very end!)
> Is there any way of sending a Reply-Message is the current scenario?
> I'm using a Cisco 350 series access point and FreeRadius version 0.7.
> I'm using a custom 802.1x supplicant for Windows 2000, but the
> behaviour seems to be the same. I'm using the Reply-Mesasge attribute
> to send a EAP-Notification. Just a simple plain text message, that
> pops ups as a EAP-Notification window on the client side. The problem
> I'm having is that, client gets authenticated and then the
> notification window pops up. Till here its ok, but then I get a
Are you sure about the latter? I would suppose that your supplicant pops
up a display box or a baloon or whatever on receiving the
EAP-Notification message from the AP and *not* after being
authenticated. And _then_ it gets rejected. So it's not ok.
> access-reject message from the server and the client gets
> de-authenticated. This happens almost immediatelty after the
> notification message pops up. Any ideas why this is so. What are the
With the correction above this is the same behaviour which I described
in the howto. The supplicant is not de-authenticated though, the message
pops up during the authentication exchange, then the EAP-Failure comes
in and Windows displays you a "Not able to connect to wireless network"
message.
> sequence of messages that are exchanged for the 'reply-message'
> attribute?
I don't know the exact message flow but it seems to be kind of
following. I will place (*) where I'm not sure about the real flow. In
fact, the doubts are always on the air interface, since I can't sniff
it. However, I can easily see what happens between the AP and the
server. So, at least one side should be precise. If anyone explains me
how to sniff on the air interface under XP, i'm willing to see what
exactly happens there.
Supplicant AP RADIUS server
RAD REQ/
EAP/Resp Id "EAP-Message" = EAP/Resp ID
BEGIN -----------> ------------------>
RAD RSP/
"Reply Message" = "text"
EAP Notification "EAP-Message" = EAP/MD5 Challenge
<----------- <------------------
EAP/MD5 Challenge (*)
<-----------
RAD REQ/
EAP-Notification "EAP-Message" = EAP-Notification
-------------> ------------------->
EAP/MD5 Chal Resp (*)
-------------->
EAP FAILURE RAD REJECT
<------------- <------------------ (notification results in reject)
RAD REQ/
"EAP-Message" = EAP MD5 Chale Resp
-------------------> (ignored at server - no State)
I'm not sure about this second MD5 Challenge message after the EAP
notification: on one hand i can't imagine that the challenge itself can
be trasported by an EAP message of type "notification". on the other
hand, Raghu figured out that the server receives the answer with the
notification and the expected State attributes in it and that the
request incoming at the server after this notification is in fact a
re-request and not the answer to the challenge.
Perhaps, it's AP whose behaviour is buggy: perhaps it should ignore the
notification response coming upstream instead of forwaring it to the
server. Later it could put the response to the challenge in the RADIUS
message with the expected State etc. But i simply don't know.
There are two things to add:
- issuing the notification message downstream to the client is ok imho,
it corresponds to the EAP RFC (2284), grep it for "notification".
- answering to the notification with a notification is kind of weird,
because notifications shouldn't be sent upstream to the server (that's
why freeradius currently immediately reacts with a RADIUS REJECT).
otherwise i couldn't find anything on this topic in the rfcs (i didn't
look very hard though).
If I understood correctly, Raghu currently plans to filter the
Reply-Message out of Challenges. It would perhaps resolve the problem,
since the Reply-Message would only be added to the final Accept message.
But it could still be a problem: Reply-Message would be in the Accept
message, it will pass the AP, the supplicant will display a message and
answer with a notification, just like it does now. This notification
would be sent by the AP to the server, just like now, the server would
Reject, the AP will close the port... On the other hand, I proposed to
silently discard the incoming EAP-Notification. Raghu noticed that in
this case the supplicant doesn't receive the Accept, since the State
attribute is missing in the incoming Request (whether it is a re-request
or the answer to the challenge).
Perhaps we should do both: filtering the reply message would assure that
it will only arrive one time, after the accept. Then, it would be
silently discarded :-)
But, for the moment, there is only one solution, as described in the
HOWTO: delete the Reply-Message attribute from the concerned user's
configuration.
Regards,
artur
--
Artur Hecker
artur[at]hecker.info
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
