Hi, Being part of the 'eduroam' clan we have a lot of EAP traffic proxying about the place, even more so being part of the 'University Triangle' in London so those peskey students and staff mooch where ever they can. My setup is generally: ---- home_server_pool eduroam { #type = fail-over <-- works #type = client-balance <-- grumbles #type = client-port-balance <-- grumbles type = keyed-balance <-- grumbles home_server = jrs.0 home_server = jrs.1 home_server = jrs.2 } ---- The proxy topology in eduroam (incase you do not know) is: [us x 2] ---------- [ .ja.net proxies x 3 ] ---------- [them x 2] <ramble> I used 'keyed-balance' as 'client-balance'/'client-port-balance' load balance terribly when your NAS's use the same source port and most of our traffic comes from the same IP (the single infernal WLC 4400 we have). This however is not important, as I only started to use 'keyed-balance' about an hour ago. I noticed after the summer FreeRADIUS overhaul I am finishing off that a number of proxied requests to particular realms failed for no reason. Speaking to my counterparts at the other universities they could see nothing wrong in their *FreeRADIUS* installations. Because I have a general knowledge of whats going on in the nearby universities I know there are some filthy MS IAS installations about and pretty quickly noticed queries to these places were working fine whilst request to my FreeRADIUS buddies did not. </ramble> Looking closer at the detail logs I saw that mid-EAP conversation the packets started to get proxied to different national proxies which resulted (expectedly) with a Access-Reject; also explaining why my counterparts never saw an inner authentication. Looks like MS IAS does not really care where the proxied packets come from, it only key's on Proxy-State (I'm guessing here); FreeRADIUS being a lot more picky...which is just what I like :) With this in mind I moved to 'fail-over' and everything started working. Alas I cannot leave it on 'fail-over' otherwise Alan Buxey gets grumbly. <ramble> I figured out how to enable super verbosity to get at those RDEBUG3's in realms.c:home_server_ldb() and saw (when using anything other than 'fail-over'): ---- [first packet] PROXY jrs 2.0 jrs 0.0 PROXY jrs 2.0 jrs 1.0 [a latter EAP packet had something like] PROXY jrs 2.0 jrs 0.0 PROXY jrs 1.0 jrs 0.0 ---- I think this was a red herring for me, but it got me to look more closer at the realms.c code. </ramble> 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? Cheers -- Alexander Clouter .sigmonster says: There is no grief which time does not lessen and soften. diff --git a/src/main/realms.c b/src/main/realms.c index a0cb796..71640d0 100644 --- a/src/main/realms.c +++ b/src/main/realms.c @@ -1938,8 +1938,12 @@ home_server *home_server_ldb(const char *realmname, /* * We've found the first "live" one. Use that. + * The !HOME_POOL_LOAD_BALANCE clause is for the EAP + * case when we want to do CLIENT/KEY based balancing + * and avoid inconsistent proxying */ - if (pool->type == HOME_POOL_FAIL_OVER) { + if (pool->type == HOME_POOL_FAIL_OVER + || pool->type != HOME_POOL_LOAD_BALANCE) { found = home; break; }