Re: Problem in proxying with multiple servers in the realms file

Hi Sergey,

> > The manual states that the server specification is a comma separated
> > list of servers. These will be tried in turn, until the list is
> > exhausted (somewhat in conjunction with the retries parameter).
> > But if I test out this setup, the radiusserver does not seem to
> > retransmit the proxy request to the second server in case the first
> > server does not work.
> 
> In order to toggle the retransmission the client must resend its
> request (usually clients are configured to send 2-3 of them within
> a predefined interval of time). This should change in the future
> versions when I enable the use of timeout parameter.

Okay, so the way things work in practice differs from the way they work 
in my head. I thought my client could send out one request to the server
and that the server would autonomically try all proxyservers on the list
in raddb/realms. 

But in that case: here's is another little problem for you to tackle ;-)

I thought that my client was already retransmitting, but it doesn't seem 
to do so. I had "retry 1" in my configuration. Using this, the output of
the client would show: 

radtest: debug: client.c:246:rad_clt_send0: sending RT_ACCESS_REQUEST
radtest: debug: server ***.***.***.***:1812
radtest: debug: send: User-Name = (STRING) *********@testrealm
radtest: debug: send: User-Password = (STRING) **************
radtest: debug: client.c:348:rad_clt_send0: no response. retrying.
radtest: debug: client.c:356:rad_clt_send0: no reply from ***.***.***.***:1812
expect 2
got    0
FAIL

But in my debug logging there was only one line of output, regarding
the sending of a proxied auth request:

Jul 20 15:15:44 proxy.c:171:proxy_send_pdu: Proxying id 96 to 1020304

If I update my client.conf to state "retry 2", then things are much
better. The client will actually retransmit and my proxy setup will work:

Jul 20 15:27:51 proxy.c:171:proxy_send_pdu: Proxying id 102 to 1020304
Jul 20 15:27:53 proxy.c:171:proxy_send_pdu: Proxying id 102 to 2030405

I would say that the retry parameter should state how many retries to do.
So using "retry 0", it should be possible to authenticate in case the
radiusserver is doing it's jobs like it should be. But if I use "retry 0",
the client will abort immediately and return FAIL, saying that there was
no reply from the radiusserver that was queried. The same problem goes for
"retry 1". The client will do a request, wait a little, say that it has had
no response en try again (but aborting immediately). This is the situation
that I had (see above). If I use snoop, I can also see that there is only
one packet transmitted, so the retrying bit seems fake.

If I use "retry 3", then 1 normal request and 1 retransmitted request will
be sent out. The clients will say it will do the last request, but it isn't
seen using snoop.

A little counting error somewhere in the code?


> > I have skimmed through the sources, but I ran into the function 
> > "radius_req_xmit", which I can't really place. I do not have the feeling
> > this function is ever actually called
> 
> Yes, it is called. The full reverse call graph is:

Ah... silly it me. It really must have been the sleep. I confused the
struct member name with the struct value :-( So STRUCT.xmit = radius_req_xmit
and STRUCT.xmit is called (instead of STRUCT.radius_req_xmit). Grmmbbl...
Thanks for waking me up ;-)

> PS: I owe you an answer to your previous letter :)

I won't hold it against you if it isn't in Dutch :-)

Regards,

Maurice Makaay
InterNLnet BV