udpfromto works for the server but not from radclient
The server operates properly and returns responses from the correct ip addresses out of multiple on the server, but the radtest client refuses to run and returns radclient: socket: cannot initialize udpfromto: Function not implemented The server does not operate correctly when built without udpfromto. The system is a current testing debian and the package is a custom rebuild based on the current git source. Thanks, Joe
Joe Maimon wrote:
The server operates properly and returns responses from the correct ip addresses out of multiple on the server, but the radtest client refuses to run and returns
radclient: socket: cannot initialize udpfromto: Function not implemented
Weird...
The server does not operate correctly when built without udpfromto.
Huh? That shouldn't make any difference. What does it mean to say "not operate correctly"? Alan DeKok.
Alan DeKok wrote:
Joe Maimon wrote:
The server operates properly and returns responses from the correct ip addresses out of multiple on the server, but the radtest client refuses to run and returns
radclient: socket: cannot initialize udpfromto: Function not implemented
Weird...
I think its probably a misuse of library calls. It seems to work properly if I put in an ip address instead of "localhost".
The server does not operate correctly when built without udpfromto.
Huh? That shouldn't make any difference.
What does it mean to say "not operate correctly"?
Sorry -- It means it does not operate correctly when I have the server bind to multiple addresses, such as on loopback interfaces where I am using an anycast style setup, replies come back from the wrong address. In other words, the functionality is required.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Joe Maimon wrote:
I think its probably a misuse of library calls. It seems to work properly if I put in an ip address instead of "localhost".
That is very strange. It looks like the udpfromto code is being handed invalid IP addresses when the server does DNS lookups.
Sorry -- It means it does not operate correctly when I have the server bind to multiple addresses, such as on loopback interfaces where I am using an anycast style setup, replies come back from the wrong address.
If you put an IP address instead of "*" in the listen section, does it still do that? If so, I suspect that the issue is a socket initialization thing fixed in 2.1.0. Alan DeKok.
Alan DeKok wrote:
Joe Maimon wrote:
I think its probably a misuse of library calls. It seems to work properly if I put in an ip address instead of "localhost".
That is very strange. It looks like the udpfromto code is being handed invalid IP addresses when the server does DNS lookups.
Is there any compelling reason to have udpfromto in the radclient code path?
Sorry -- It means it does not operate correctly when I have the server bind to multiple addresses, such as on loopback interfaces where I am using an anycast style setup, replies come back from the wrong address.
If you put an IP address instead of "*" in the listen section, does it still do that?
If the server only sockets on a single address, I assume it will work fine, but only on that address. I need the server to have listening sockets on at least three addresses.
If so, I suspect that the issue is a socket initialization thing fixed in 2.1.0.
I am using fairly recent git.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Joe Maimon wrote:
Is there any compelling reason to have udpfromto in the radclient code path?
Not really. It's just easier to use a common API to create sockets
If the server only sockets on a single address, I assume it will work fine, but only on that address. I need the server to have listening sockets on at least three addresses.
That's not quite what I meant. If you have 3 "listen" sections, each using: ipaddr = 192.168.x.y What does it do? Does it send packets from the correct source IP?
I am using fairly recent git.
I find it a little hard to understand how it can choose the wrong source IP for responses. Why do you need udpfromto support? Alan DeKok.
Alan DeKok wrote:
Joe Maimon wrote:
Is there any compelling reason to have udpfromto in the radclient code path?
Not really. It's just easier to use a common API to create sockets
Thats what I thought.
If the server only sockets on a single address, I assume it will work fine, but only on that address. I need the server to have listening sockets on at least three addresses.
That's not quite what I meant.
If you have 3 "listen" sections, each using:
ipaddr = 192.168.x.y
What does it do? Does it send packets from the correct source IP?
I have not tried that. I can try that, but it is sub-optimal, since the server configuration is intended to be as identical as possible across multiple hosts. There is a third option, instead of only specific listen sockets or a single * socket, which if I recall correctly, bind9 uses. Periodically scan the system for all ip addresses and create a listening socket for each one in response to ipaddr = *, instead of creating a single socket for all system ip addresses.
I am using fairly recent git.
I find it a little hard to understand how it can choose the wrong source IP for responses.
It does, with ipaddr = * when built without udpfromto support.
Why do you need udpfromto support?
The default debian build includes it, and the system includes multiple ip addresses on loopback interfaces aside from interface addresses, all need to work correctly.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Joe Maimon wrote:
I have not tried that. I can try that, but it is sub-optimal, since the server configuration is intended to be as identical as possible across multiple hosts.
Of course.
There is a third option, instead of only specific listen sockets or a single * socket, which if I recall correctly, bind9 uses.
Periodically scan the system for all ip addresses and create a listening socket for each one in response to ipaddr = *, instead of creating a single socket for all system ip addresses.
Ugh. That's disgusting. If Bind or ISC DHCP does something, that's a good reason *not* to do it.
I find it a little hard to understand how it can choose the wrong source IP for responses.
It does, with ipaddr = * when built without udpfromto support.
Yes. Because the machine has a primary interface with an IP, and an alias with another IP. The *kernel* decides the source IP of the reply. It chooses the primary IP, even though the packet was sent to the secondary IP.
The default debian build includes it, and the system includes multiple ip addresses on loopback interfaces aside from interface addresses, all need to work correctly.
OK. So the issue is getting radclient to work with udpfromto. Alan DeKok.
participants (2)
-
Alan DeKok -
Joe Maimon