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