Alan DeKok <aland@deployingradius.com> wrote:
The conclusion, we should not be paying any attention to 'currently_outstanding' or 'fr_rand()' when there is EAP traffic; I decided to add the clause !HOME_POOL_LOAD_BALANCE; things now work.
What do you think of the following patch, I think there is sound reasoning behind it, however of course I am just a network monkey?
Nope. The solution is to fix the EAP module. Edit src/modules/rlm_eap.c, function eap_handler_cmp(). Delete the comparison that checks src_ipaddr.
Does mean that client-balance, client-port-balance and keyed-balance do not do as advertised on the tin though which I would want to grumble about being a Bad Thing(tm).
The code already creates a unique State attribute for each EAP session. So it really doesn't need to check anything else.
If that solves the problem, we can put the fix into 2.1.8.
It is a receiver side only fix mind you that does not stop FreeRADIUS (or anything else) shifting packets to the wrong place. The fix is that you need to remove any uncertainty about where the traffic goes and having that load comparison[1] and an explicit call to a random shuffler royally breaks things by making things unpredictable. In the 'eduroam' case, if we removed the national RADIUS servers, and lets say I delivered the packets straight to the remote end, nothing stops FreeRADIUS delivering half an EAP session to the wrong box which would result in an Access-Reject. I would argue you actually want to keep the src_ipaddr check to pick up on upstream *broken* load balancers, unfortunately it's just currently FreeRADIUS does have a broken load balancer. For what it is worth, NAK? :) Cheers [1] obviously you still want the max outstanding check there, but you have to think of the case of (such as for us) where 'outstanding_sessions' is zero ~100% of the time -- Alexander Clouter .sigmonster says: <ahzz_> i figured 17G oughta be enough.