Re: [Dnsmasq-discuss] No Broadcast Dhcp Offers
It worked at first shot! thank you Simon! :)
Sent: Thursday, September 27, 2018 at 8:09 PM
From: "Simon Kelley"
To: gravit...@gmx.com, dnsmasq-discuss@lists.thekelleys.org.uk
Subject: Re: [Dnsmasq-discuss] No Broadcast Dhcp Offers
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"
> *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 ?
>> 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"
>> *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
Re: [Dnsmasq-discuss] No Broadcast Dhcp Offers
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"
> *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 ?
>> 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"
>> *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
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 ? > 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" > *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
Re: [Dnsmasq-discuss] No Broadcast Dhcp Offers
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" 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 ? > 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" > *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
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 ? Or, how can I check on Linux the "hardware address length field" and "hardware address type"? After that I promise I wont bother anymore ;) Thanks Sent: Wednesday, September 26, 2018 at 4:36 PM From: "Simon Kelley" 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
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
Re: [Dnsmasq-discuss] No Broadcast Dhcp Offers
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". Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] No Broadcast Dhcp Offers
Hi Geert, thanks for the answer. >>I don't buy that. ARP also does ethernet broadcasts. >>Without Address Resolution Protocol no IPv4 networking on ethernet. Sorry dont understand what you dont buy, i'm not selling anything here ;-) 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? >>What I think is that no driver is loaded for the dongle during first DHCP Discover request. >>Then just write your own DHCP server. ;-) In fact I already did that, on server side I wrote few codes of C program which binds to eth. It listens to QNSMASQ Dhcp OFFER frames messages with eth.dst=ff:ff:ff:ff:ff:ff. When such frames arrive, it simply re-inject exactly the same frames in eth, but with eth.dst= . It works, dongle answers with REQUEST, then ACK, then all goes smoothly no problems. As you can understand, that is just a very dirty workaround, can use it only to test the correct connectivity and driver load, because unfortunately I cant do nothing on the dongle side. But can't use that thing in production... Any hint for a decent solution to suggest me? Thank you Sent: Sunday, September 23, 2018 at 9:33 AM From: "Geert Stappers" To: dnsmasq-discuss@lists.thekelleys.org.uk Subject: Re: [Dnsmasq-discuss] No Broadcast Dhcp Offers On Sat, Sep 22, 2018 at 07:06:53PM +0200, gravit...@gmx.com wrote: > Hi all, > I have a very simple question, but it seems difficult to find a solution... > > By default DNSMASQ sends Dhcp OFFER message with eth.dst=ff:ff:ff:ff:ff:ff , it > sends to broadcast mac. > I have a dongle which works a bit outside specs, and can't answer to broadcast > mac. I don't buy that. ARP also does ethernet broadcasts. Without Address Resolution Protocol no IPv4 networking on ethernet. What I think is that no driver is loaded for the dongle during first DHCP Discover request. > So, I need DNSMASQ to send the Dhcp OFFER messages (and better also ACK/NAK and > the whole Dhcp stack) to a specific mac I set. > Does it exist such option? I don't know. > I already was thinking to start crafting Dhcp frames myself... but I dont > really want to rewrite my own DNSMASQ... Then just write your own DHCP server. ;-) Groeten Geert Stappers -- Leven en laten leven ___ 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
Re: [Dnsmasq-discuss] No Broadcast Dhcp Offers
On Sat, Sep 22, 2018 at 07:06:53PM +0200, gravit...@gmx.com wrote: > Hi all, > I have a very simple question, but it seems difficult to find a solution... > > By default DNSMASQ sends Dhcp OFFER message with eth.dst=ff:ff:ff:ff:ff:ff , > it > sends to broadcast mac. > I have a dongle which works a bit outside specs, and can't answer to broadcast > mac. I don't buy that. ARP also does ethernet broadcasts. Without Address Resolution Protocol no IPv4 networking on ethernet. What I think is that no driver is loaded for the dongle during first DHCP Discover request. > So, I need DNSMASQ to send the Dhcp OFFER messages (and better also ACK/NAK > and > the whole Dhcp stack) to a specific mac I set. > Does it exist such option? I don't know. > I already was thinking to start crafting Dhcp frames myself... but I dont > really want to rewrite my own DNSMASQ... Then just write your own DHCP server. ;-) Groeten Geert Stappers -- Leven en laten leven ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] No Broadcast Dhcp Offers
Hi all, I have a very simple question, but it seems difficult to find a solution... By default DNSMASQ sends Dhcp OFFER message with eth.dst=ff:ff:ff:ff:ff:ff , it sends to broadcast mac. I have a dongle which works a bit outside specs, and can't answer to broadcast mac. So, I need DNSMASQ to send the Dhcp OFFER messages (and better also ACK/NAK and the whole Dhcp stack) to a specific mac I set. Does it exist such option? I already was thinking to start crafting Dhcp frames myself... but I dont really want to rewrite my own DNSMASQ... I know iptables doesnt have this option... So, if DNSMASQ doesn't have this option too, how can I do that alternatively? Thanks, SB ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
