I just wanted to ping the list just in case my last message had been caught in a spam filter or otherwise missed. I'm not trying to be pushy, just don't want to get into a situation where everyone is waiting on a response from everyone else. Just want to make sure I'm the only one waiting. :-) I have no expectation that anybody "owes" me a response. If I need to look deeper into the problem on my own, I will be happy to do so. If I have, once again, picked on a piece of the code that has no bearing in my issue, please don't be afraid to tell me I am being stupid. If I need to switch this to the -devel list, I can subscribe and repost it there. This may have gone a bit off charter for the -users list. On Tue, Sep 18, 2007 at 05:17:27PM -0500, Scott Lambert wrote:
On Tue, Sep 18, 2007 at 09:54:33AM +0200, Alan DeKok wrote:
Scott Lambert wrote:
lrad_packet_list_socket_add() is called with a pointer to the radius request packet list structure and the socket file descriptor of the socket which has been created with the call to socket() and bound to an IP and port by bind() during the prior call to lrad_socket(). Is that correct?
Yes. In the jail, it asks to bind to 0.0.0.0, but the socket *actually* binds to the jail IP. This is why the "inaddr_any" check doesn't match.
So, should we be looking for != in the above if() from lrad_packet_list_socket_add()?
... no. The issue is that when udpfromto is used, we have:
a) socket binds to 0.0.0.0 (really, outside of the jail) b) the server doesn't know which IP is used to send a packet c) the server DOES know which IP the response is sent to
Since the "received" IP doesn't match the "source" IP, there's a little bit of tweaking that has to be done to match the response to an outstanding request. That's what that check is for.
I am sorry for being so dense. I think I can see that I was wrong before.
However, what I see, though experimentation and lots of printfs, is that sockfd is bind()ing with a specified IP of 0.0.0.0. bind() takes care of fixing that up for processes in the jail and when bind returns, the socket is *actually* bound to the jail's IP address. Without the jail the socket would have remainded bound to 0.0.0.0.
Then lrad_packet_list_socket_add() determines what IP we bound to from the *actual* information in the sockaddr_in structure to which sockfd points. That is the &ps->ipaddr.ipaddr.ip4addr.s_addr inside lrad_packet_list_socket_add(). In the jail that is actually the jail's IP address.
That's all well and good. However, perhaps the problem comes when we get to recv_one_packet() in radclient.c and unconditionally set reply->dst_ipaddr = client_ipaddr which is apparantly due to "udpfromto issues."
/* * udpfromto issues. We may have bound to "*", * and we want to find the replies that are sent to * (say) 127.0.0.1. */ reply->dst_ipaddr = client_ipaddr;
Commenting that line out makes my jail work.
On my systems, reply->dst_ipaddr == client_ipaddr except when Packet-Src-IP-Address is NOT specified within the jail.
When Packet-Src-IP-Address is NOT specified within the jail:
radclient: recv_one_packet: client_ipaddr.ipaddr.ip4addr = 0 radclient: recv_one_packet: reply->dst_ipaddr.ipaddr.ip4addr = 460364101
By leaving reply->dst_ipaddr alone, lrad_packet_list_find_byreply is able to match the ps->ipaddr with the reply->dst_ipaddr even though ps->inaddr_any = 0.
I don't know the circumstances in which reply->dst_ipaddr != client_ipaddr in such a way that it would be necessary to force them ==.
Are those circumstances mutually exclusive of the jail circumstances?
Could this be the correct location for a fix?
-- Scott Lambert KC5MLE Unix SysAdmin lambert@lambertfam.org