[Dnsmasq-discuss] relay packets black hole

Tue Dec 3 21:00:39 UTC 2024

On 12/3/24 09:26, oss.group at omnilan.de wrote:
> On 2024-12-03 10:07, oss.group at 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 at lists.thekelleys.org.uk
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss