On 27/09/18 20:54, gravit...@gmx.com wrote:
> 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
> *From:* "Simon Kelley" <si...@thekelleys.org.uk>
> *To:* gravit...@gmx.com, dnsmasq-discuss@lists.thekelleys.org.uk
> *Subject:* Re: [Dnsmasq-discuss] No Broadcast Dhcp Offers
> On 27/09/18 20:24, gravit...@gmx.com 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.
> 
> 
> Cheers,
> 
> Simon.
> 
>> After that I promise I wont bother anymore ;)
>> Thanks
>>  
>> *Sent:* Wednesday, September 26, 2018 at 4:36 PM
>> *From:* "Simon Kelley" <si...@thekelleys.org.uk>
>> *To:* dnsmasq-discuss@lists.thekelleys.org.uk
>> *Subject:* Re: [Dnsmasq-discuss] No Broadcast Dhcp Offers
>> On 26/09/18 17:33, Simon Kelley wrote:
>>> On 24/09/18 11:45, gravit...@gmx.com 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@lists.thekelleys.org.uk
>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>  


_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Reply via email to