Vinay Wagh wrote:
> On looking deeper in to the problem I saw that the reason the
> rbtree_insert in eaplist_add() fails is because there is already a node
> in the tree with the same state (PW_STATE), this node is for a different
> request altogether and so the insert in to the tree fails. Since I send
> multiple requests from the same gateway and the radius client on the
> gateway opens up 4 source ports to the radius server we have can send 4
> requests in the same second that have the same ID and source IP address.
Hmm... that may be allowed by the spec, but it seems broken to me.
The code in rlm_eap does NOT use the source port to distinguish
requests, because some NASes send EAP requests for one session via
multiple source ports. It just depends on how busy the NAS is.
> The eap_handler_cmp() function uses the STATE to distinguish requests if
> the id and source IP address are the same, but in my case the state is
> also the same. Here is the relevant debug log for it
If the state is the same, then something is going seriously wrong
inside of the server. The state that is generated SHOULD be random, and
unique per request.
> Wed Sep 19 22:36:37 2007 : Info: STATE: Added state 82 f1 8b 49 6f bf b9
> a4 ee 2a d3 d5 ef f8 ec 3b for {am= [EMAIL PROTECTED]
Can you instrument the code to see when the state is generated? My
suspicion is that a new State attribute is NOT being generated. i.e.
the server sees the "same" request, and re-uses the same State.
That shouldn't be happening, though. On a new EAP-Identity packet, a
new State is allocated, and added to the list. Since the State is
generated from random numbers, it SHOULD be unique every time.
> I am guessing this can cause other problems, not sure if this can result
> in sending Access-Accept to users who should not be authenticated but it
> definitely rejects users who should be authenticated. Another problem I
> see which seems related to this is that I receive Access-Accept on the
> gateway for a valid user but the reply has an invalid message
> authenticator. I think this is probably because it finds a different
> handler instead, but not sure about that.
The calculation of the Message-Authenticator has nothing to do with
EAP, or with the State. If the Message-Authenticator is invalid, then
something is seriously wrong.
> Is this a known bug ? If yes, is it fixed and in what release ? For now,
> I am changing the eap_handler_cmp() function to compare the identity if
> the state is the same, since in our lab setup we also have a unique
> identity for each user, do you see a problem with doing this.
No. I would suggest in your situation also adding a comparison on the
source port. That should work ard the problem.
I'm hesitant to add that comparison to the main code, though. It may
cause other peoples networks to break.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
