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 [EMAIL PROTECTED] - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html