Re: [Dnsmasq-discuss] relay packets black hole

Tue, 03 Dec 2024 13:21:44 -0800 


On 12/3/24 09:26, oss.gr...@omnilan.de wrote:

On 2024-12-03 10:07, oss.gr...@omnilan.de wrote:

...


As soon as I add/uncomment *my actual config, no client is able to 
acquire a lease*.

dhcp-relay=172.17.146.10,172.17.128.253
dhcp-proxy=172.17.146.10


    startuplog dnsmasq-dhcp[13148]: DHCP relay from 172.17.146.10 to 
172.17.128.253




On the interface with the <local address> (172.17.146.10), I can only 
see this initial broadcast frame:
09:45:08.646733 ee:8c:ea:aa:1b:31 > ff:ff:ff:ff:ff:ff, ethertype IPv4 
(0x0800), length 342: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, 
Request from ee:8c:ea:aa:1b:31, length 300



Absolutely no DHCP-related frames are traveling on the <server> 
(172.17.128.253) interface (ngeth14).
This doesn't change if I alter the dhcp-relay line to "dhcp- 
relay=172.17.146.10,ngeth14".

The log shows

runninglog dnsmasq-dhcp[13148]: DHCP relay 172.17.146.10 -> 
172.17.128.253

but no frames materialize.
...



poll({ 4/POLLIN 7/POLLIN 8/POLLIN 9/POLLIN 10/POLLIN 11/POLLIN 12/ 
POLLIN },7,-1) = 1 (0x1)
recvmsg(4,{{ AF_INET 0.0.0.0:68 },16,[{"\^A\^A\^F\0z)]\M- 
V\0\0\0\0\0\0\0"...,548}],1, 
{{level=IPPROTO_IP,type=IP_RECVIF,data={0x38,0x12,0x09,0x00,0x06,0x07,0x06,0x00,0x65,0x70,0x61,0x69,0x72,0x32,0x62,0xee,0x8c,0xea,0xaa,0x1b,0x41,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00}}},72,MSG_PEEK},MSG_PEEK|MSG_TRUNC) = 300 (0x12c)
recvmsg(4,{{ AF_INET 0.0.0.0:68 },16,[{"\^A\^A\^F\0z)]\M- 
V\0\0\0\0\0\0\0"...,548}],1, 
{{level=IPPROTO_IP,type=IP_RECVIF,data={0x38,0x12,0x09,0x00,0x06,0x07,0x06,0x00,0x65,0x70,0x61,0x69,0x72,0x32

,0x62,0xee,0x8c,0xea,0xaa,0x1b,0x41,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00}}},72,0},0)
 = 300 (0x12c)
__sysctl("net.routetable.0.0.5.0",6,0x0,0x820cb6ce8,0x0,0) = 0 (0x0)

__sysctl("net.routetable.0.0.5.0",6,0xc2b4a05e000,0x820cb6ce8,0x0,0) = 0 
(0x0)

ioctl(4,SIOCGIFFLAGS,0x820cb6e90)                = 0 (0x0)
ioctl(4,SIOCGIFADDR,0x820cb6e90)                 = 0 (0x0)
__sysctl("net.routetable.0.0.5.0",6,0x0,0x820cb6b98,0x0,0) = 0 (0x0)

__sysctl("net.routetable.0.0.5.0",6,0xc2b4a05e000,0x820cb6b98,0x0,0) = 0 
(0x0)

socket(PF_INET,SOCK_DGRAM|SOCK_CLOEXEC,0)        = 15 (0xf)
ioctl(15,SIOCGIFINDEX,0x820cb6ba0)               = 0 (0x0)
close(15)                                        = 0 (0x0)
socket(PF_INET,SOCK_DGRAM|SOCK_CLOEXEC,0)        = 15 (0xf)
ioctl(15,SIOCGIFINDEX,0x820cb6ba0)               = 0 (0x0)
close(15)                                        = 0 (0x0)
socket(PF_INET,SOCK_DGRAM|SOCK_CLOEXEC,0)        = 15 (0xf)
ioctl(15,SIOCGIFINDEX,0x820cb6ba0)               = 0 (0x0)
close(15)                                        = 0 (0x0)

sendmsg(4,{{ AF_INET 172.17.128.253:67 },43,[{"\^A\^A\^F\^Az)]\M- 
V\0\0\0\0\0\0"...,300}],1, 
{{level=IPPROTO_IP,type=IP_RECVDSTADDR,data={0xac,0x11,0x92,0x0a}}},20,0},0) ERR#22 'Invalid argument'





Well, there's your problem :)


Actually, I can't see the problem. The incoming packet is received OK, 
and it's arrival interface is determined and associated with the relay 
configuration. (That's all the  SIOCGIFINDEX, ioctls, looking at the 
addresses of the local interfaces.



Finally, the code tries to send the packet on to 172.17.128.253 port 67 
- tick, with a source address of 172.17.146.10 - tick.


Why that provokes EINVAL, I have very little idea.

Some pointers to help your debugging.


You're looking at relay_upstream4() in src/dhcp.c which calls 
send_from() in src/forward.c



As far as I can tell the sockopts IP_RECVDSTADDR and IP_SENDSRCADDR have 
the same numerical value in the headers, so the dtrace IP_RECVDSTADDR in 
a sendmsg() argument is not unexpected. It may be worth looking at 
/usr/include/netinet/in.h on the machine you're building on and the 
machine you're running on. Just in case that changed at some point and 
broke the ABI.




If you set the second argument of the send_from() call in 
relay_upstream4() to 1, that will suppress the attempt to set the source 
address of the transmitted packet. If the EINVAL error then goes away, 
that's a clue.



I have a very ancient, very faint, memory that some BSD flavours support 
IP_RECVDSTADDR but NOT IP_SENDSRCADDR but I'm pretty sure FreeBSD is OK 
in this respect. 
https://man.freebsd.org/cgi/man.cgi?query=ip&sektion=4&manpath=FreeBSD+9.0-RELEASE




The send_from() function is also used to send DNS packets, so a quick 
test/dtrace of dnsmasq forwarding DNS to the same place it's supposed to 
be relaying DHCP to might be informative.


Good luck!


I don't have a functional FreeBSD VM at the moment, but I can create a 
new one if needs be.


Cheers,

Simon.







P.S.: I initially observed the problem with version 2.90, but wanted to 
test 2.78 which was the release fixing a dhcp-relay bug according to the 
changelog.
Currently there's still 2.78 installed for debugging - which is kind of 
inconvenient, since it's a jail on a production-setup which entirely 
lacks compiler/debuggers...




_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss



_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss






















					Reply via email to