<div dir="ltr">Hi there,<div><br>I'm not sure of a way of testing it with a real network device, but I'm happy to attempt to build a older UML kernel and test it from there. As I said in my original email, the last fully known working build was way back in kernel 3.2 and a lot has changed since then, so it could very well be a kernel issue and due to the edge use case, no one has ever really come across it. Is there a kernel version you'd like me to try out? Debian has a standard usermodelinux package which contains prebuilt UML images with kernel versions of 4.9, 4.19 or 5.5 if they'd be handy? <a href="https://tracker.debian.org/pkg/user-mode-linux">https://tracker.debian.org/pkg/user-mode-linux</a>.<br><br>Thanks for the support,<br>Josh<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 23 Apr 2020 at 20:30, Simon Kelley <<a href="mailto:simon@thekelleys.org.uk">simon@thekelleys.org.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Ok, so Josh ran the strace and sent me the results as requested.<br>
<br>
The interesting bit us here.<br>
<br>
recvmsg(4, {msg_name={sa_family=AF_INET, sin_port=htons(68),<br>
sin_addr=inet_addr("0.0.0.0")}, msg_namelen=16,<br>
msg_iov=[{iov_base="\1\1\6\0\310\261\311+\0\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\366\226}H"...,<br>
iov_len=548}], msg_iovlen=1, msg_control=[{cmsg_len=24,<br>
cmsg_level=SOL_IP, cmsg_type=IP_PKTINFO,<br>
cmsg_data={ipi_ifindex=if_nametoindex("eth0"),<br>
ipi_spec_dst=inet_addr("192.168.1.1"),<br>
ipi_addr=inet_addr("255.255.255.255")}}], msg_controllen=24,<br>
msg_flags=0}, MSG_PEEK|MSG_TRUNC) = 300<br>
recvmsg(4, {msg_namelen=16}, 0)         = -1 EAGAIN (Resource<br>
temporarily unavailable)<br>
<br>
<br>
<br>
The first call to recvmsg has the MSG_PEEK and MSG_TRUNC flags set.<br>
MSG_TRUNC causes the result to be the actual length of the received<br>
packet, even if it's longer than  supplied buffer (548) and MSG_PEEK is<br>
defined as:<br>
<br>
<br>
 MSG_PEEK<br>
       This  flag  causes the receive operation to return data from the<br>
       beginning of the receive queue without removing that  data  from<br>
       the queue.  Thus, a subsequent receive call will return the same<br>
       data.<br>
<br>
So this allows the buffer to be expanded if necessary and then recvmsg<br>
gets called again when the buffer is big enough, to actually get the<br>
data and remove it from the queue. In this case the packet is 300 bytes<br>
long and the buffer is already 548 bytes, so no expansion is needed, we<br>
just do the call again, without the MSG_PEEK|MSG_TRUNC flags. That's the<br>
second call to recvmsg, which returns EAGAIN - the socket is<br>
no-blocking, and this return says there's no packet queued. It looks<br>
like the kernel is ignoring the MSG_PEEK flag, and dequeueing the data<br>
on the first call.<br>
<br>
I think this is a kernel bug.<br>
<br>
Josh, does this work with an older kernel or with a real network device,<br>
rather than the UML virtual device? It would be good to work out where<br>
the regression happened.<br>
<br>
<br>
Simon.<br>
<br>
On 16/04/2020 15:40, Josh H wrote:<br>
> <br>
>     First, answer a simple question the answer to which I may have missed.<br>
>     Is dnsmasq logging the receipt of DHCPDISCOVER messages? Can we see the<br>
>     whole log showing that?<br>
> <br>
> <br>
> Based on the config I provided at the initial message, I have the log<br>
> file writing to /var/log/dnsmasq.log. This is the whole content of that<br>
> file:<br>
> <br>
> root@dns:~# cat /var/log/dnsmasq.log<br>
> Apr 16 15:36:50 dnsmasq[1695]: started, version 2.80 DNS disabled<br>
> Apr 16 15:36:50 dnsmasq[1695]: compile time options: IPv6 GNU-getopt<br>
> DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC<br>
> loop-detect inotify dumpfile<br>
> Apr 16 15:36:50 dnsmasq-dhcp[1695]: DHCP, IP range 192.168.1.3 --<br>
> 192.168.1.8, lease time 12h<br>
> <br>
> No mention of the DHCPDiscover being acknowledged.<br>
> <br>
>     The next stage is to run dnsmasq under strace (check back here if you<br>
>     need instructions on that) and see what system calls it's making.<br>
> <br>
> <br>
> What command would I need to run for this? And what service is best to<br>
> upload the strace result, pastebin?<br>
> <br>
> Thanks,<br>
> Josh <br>
> <br>
> On Thu, 16 Apr 2020 at 12:49, Simon Kelley <<a href="mailto:simon@thekelleys.org.uk" target="_blank">simon@thekelleys.org.uk</a><br>
> <mailto:<a href="mailto:simon@thekelleys.org.uk" target="_blank">simon@thekelleys.org.uk</a>>> wrote:<br>
> <br>
> <br>
> <br>
>     On 15/04/2020 19:27, Josh H wrote:<br>
> <br>
>     > It's difficult for me to share the config outright as I'm using a<br>
>     > modified version of netkit that I've updated to a much newer kernel<br>
>     > - <a href="http://netkit-ng.github.io/" rel="noreferrer" target="_blank">http://netkit-ng.github.io/</a>. The netkit version that is available on<br>
>     > that link is the one that worked with dnsmasq just fine, and that<br>
>     > version was 2.62 and kernel 3.2. However I've updated it and am<br>
>     running<br>
>     > 2.80 and kernel 5.6. <br>
>     ><br>
>     > Anything else I can provide you with that might help? It's a very<br>
>     unique<br>
>     > setup so I appreciate  it's probably not the easiest thing to try and<br>
>     > debug. <br>
>     ><br>
> <br>
>     First, answer a simple question the answer to which I may have missed.<br>
>     Is dnsmasq logging the receipt of DHCPDISCOVER messages? Can we see the<br>
>     whole log showing that?<br>
> <br>
>     The next stage is to run dnsmasq under strace (check back here if you<br>
>     need instructions on that) and see what system calls it's making.<br>
> <br>
> <br>
>     Simon.<br>
> <br>
> <br>
>     _______________________________________________<br>
>     Dnsmasq-discuss mailing list<br>
>     <a href="mailto:Dnsmasq-discuss@lists.thekelleys.org.uk" target="_blank">Dnsmasq-discuss@lists.thekelleys.org.uk</a><br>
>     <mailto:<a href="mailto:Dnsmasq-discuss@lists.thekelleys.org.uk" target="_blank">Dnsmasq-discuss@lists.thekelleys.org.uk</a>><br>
>     <a href="http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss" rel="noreferrer" target="_blank">http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss</a><br>
> <br>
</blockquote></div>