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...
Sent: Thursday, September 27, 2018 at 7:43 PM
From: "Simon Kelley" <>
Subject: Re: [Dnsmasq-discuss] No Broadcast Dhcp Offers
On 27/09/18 20:24, wrote:
> 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.



> After that I promise I wont bother anymore ;)
> Thanks
> *Sent:* Wednesday, September 26, 2018 at 4:36 PM
> *From:* "Simon Kelley" <>
> *To:*
> *Subject:* Re: [Dnsmasq-discuss] No Broadcast Dhcp Offers
> On 26/09/18 17:33, Simon Kelley wrote:
>> On 24/09/18 11:45, wrote:
>>> Amof, 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
Dnsmasq-discuss mailing list

Reply via email to