Gotcha! :)
Thank you very much Simon, it is clearly a donge driver bug, since
DHCPDISCOVER comes indeed with both bytes 2 and 3 =0
Please, last effort from you, tell me in what file.c did you put that if
which "falls back to broadcast".
I will try to patch it myself and bypass it with some kind of new
option, kind a "--dhcp-unicast", to always force the use of mac, no
matter what.
That solution will be *a lot* better than my dirty frames reinjection...
On src/dhcp.c, around line 400
if ((ntohs(mess->flags) & 0x8000) || mess->hlen == 0 ||
mess->hlen > sizeof(ifr.ifr_addr.sa_data) || mess->htype == 0)
{
/* broadcast to 255.255.255.255 (or mac address invalid) */
dest.sin_addr.s_addr = INADDR_BROADCAST;
dest.sin_port = htons(daemon->dhcp_client_port);
}
else
{
/* unicast to unconfigured client. Inject mac address direct
into ARP cache.
Have fun!
Cheers,
Simon.
*Sent:* Thursday, September 27, 2018 at 7:43 PM
*Subject:* Re: [Dnsmasq-discuss] No Broadcast Dhcp Offers
Hi Simon,
thank you for your answer.
I confirm no --dhcp-broadcast option.
I dont really want to bother too much... but if you could just give me a
couple of examples of that last thing.
I mean, could you just give me a simple example of "hardware address
length field is zero or greater than 16"?
And/or a simple example of "hardware address type field is zero."?
We talking about the <mac dongle>?
Or, how can I check on Linux the "hardware address length field" and
"hardware address type"?
In the DHCPDISCOVER packet, these are bytes 2 and 3. Byte 1 is 1
(BOOTREQUEST) and byte 2 is the "hardware address type", whilst byte
three is the "hardware address length", which is typically 6 for what
people normally think of as MAC addresses.
Cheers,
Simon.
After that I promise I wont bother anymore ;)
Thanks
*Sent:* Wednesday, September 26, 2018 at 4:36 PM
*Subject:* Re: [Dnsmasq-discuss] No Broadcast Dhcp Offers
Post by Simon KelleyAmof, the first and only frames my dongle sends on eth at start, are
some Dhcp DISCOVER, no arps at all.
Please note that such Dhcp DISCOVER frames come with the broadcast bit
NOT set.
Afaik, that meas my dongle is indeed asking the Dhcp server to send a
unicast response, directly to its mac.
Instead QNSMASQ sends those Dhcp OFFER frames to broadcast.
Why it happens so?
I can offer two reasons why it might be so. The first is that there's a
bug in dnsmasq, which is not unheard-of, but this is old code and a bug
has not been observed before. The second is that you're running dnsmasq
configured to always send broadcasts, using the --dhcp-broadcast option.
Check all the dnsmasq configuration files, that's the sort of thing that
gets slipped in because is solves someone's problem one time, and "it
can't do any harm".
Looking at the code, it also falls back to broadcast if the "hardware
address length field is zero or greater than 16, or if the "hardware
address type" field is zero.
Cheers,
Simon.
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss