Re: [Dnsmasq-discuss] dnsmasq 2.78 is failing to respond to dhcpv6 requests forwarded via relay agent

2019-01-10 Thread Simon Kelley
Thanks for the offer. I think there may be a simpler answer, worth
trying first.

Looking back through the git history, this looks like a bug introduced
into 2.78 by the patches for security problems found by Google, in 2017.

It was fixed for 2.79, by  patch


http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=499d8dde2b1a216eab9252ee500cc31b8c2b2974

So, first either move to 2.79 (or preferably 2.80) or apply that patch.

If that doesn't fix it, we'll go for debugging.


Cheers,

Simon.



On 10/01/2019 12:18, Sandeep K M wrote:
> Hi Simon,
> 
> Thanks again for the response.
> 
> I will be happy to be your tester :)
> 
> Its fairly a simple setup with two hosts and a switch. I can create this
> any time you want.
> 
> Please provide me the instructions. I am using dnsmasq version 2.78.
> 
> Thanks
> -Sandeep
> 
> On Wed, Jan 9, 2019 at 10:33 PM Simon Kelley  > wrote:
> 
> On 04/01/2019 06:25, Sandeep K M wrote:
> > Hi Simon,
> >
> > Thanks a lot for your prompt reply.
> >
> > Attached are the packet captures:
> >
> > 1. Packets exchanged between client and relay (client-relay.pcap)
> > 2.  Packets exchanged between relay and server (relay-server.pcap)
> > 3. strace of dnsmasq (dnsmasq.trace)
> >
> > Please let me know if any other information is required.  
> >
> > I am not an expert in reading pcap's or strace but I do see in the
> > attached strace i.e. dnsmasq.trace file that ""DHCPADVERTISE"
> message is
> > being written to the same interface from which it received the
> > "DHCPSOLICIT" packet. But still it is fails to go out of that
> interface.
> >
> > 06:04:09.371741 write(2, "DHCPADVERTISE(m1s1p7) 2020::14
> > 00:01:00:01:23:c1:b0:e2:00:50:56:bd:09:fb ", 73) = 73
> >
> > Any help on this would be greatly appreciated. Also is there any
> example
> > configuration of dnsmasq dhcpv6 working with relay ? Any reference
> would
> > be of great help.
> >
> 
> I'm sure this was tested with a relay, but the current test harnesses
> here would take some work to get into a position to test this code, so
> I'm going to try and use you as a tester, if that's OK?
> 
> 
> Looking at the strace output, dnsmasq logs that it's sending a
> DHCPADVERTISE reply, but it never calls sendto() to actually send the
> packet. This is definitely a dnsmasq bug, and not something in your
> network that's causing the packet to get lost: it never gets sent.
> 
> 
> What's confusing me is that manually tracing the code paths from what's
> known to be working (log the DHCPADVERTISE) to the sendto() call that
> should send that packet, I can't see any reason why the code should
> fail.
> 
> Are you in a position to run dnsmasq under gdb and step through the
> relevant code? I can give you detailed instructions on where to set
> breakpoints and where the reply packet could be getting lost. The path
> is maybe 50 lines.
> 
> Staring at the code has found me one bug, but it's not relevant in this
> case. (The code to avoid copying an RFC6939 link address option in a
> relay request to the reply to the relay actually sends a zero-length
> option, instead of eliding it entirely.)
> 
> Cheers,
> 
> Simon.
> 
> 
> 
> 

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


Re: [Dnsmasq-discuss] DHCP, how to ignore the client MAC address?

2019-01-10 Thread wkitty42

On 1/10/19 3:26 PM, Michael Schleicher wrote:

As I said, for Linux VM's, I can set a uniq Client-ID that helps, but on
Windows you can not set define a Client-ID (as far as I know).


isn't this the machine name? when i was supporting winwhatever, the install 
generated a machine name... that is the name i saw used in DHCP requests... it 
is the name that was added to the DNS so queries on it would return its current 
IP...



--
 NOTE: No off-list assistance is given without prior approval.
   *Please keep mailing list traffic on the list unless*
   *a signed and pre-paid contract is in effect with us.*

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


Re: [Dnsmasq-discuss] DHCP, how to ignore the client MAC address?

2019-01-10 Thread Michael Schleicher
Hi John,

many thanks for your reply and help.

On 1/10/19 9:28 AM, john doe wrote:
> On 1/9/2019 11:38 AM, MIchael Schleicher wrote:
>>
>> On 09.01.19 08:14, john doe wrote:
>>> On 1/8/2019 11:31 AM, smicha wrote:
 Hi John,

 thanks for your reply.

 I did some tests with your hints.

 On 7.1.2019 17:41, john doe wrote:
>
> Some hints from dnsmasq.conf:
>
> # Give the machine which says its name is "bert" IP address
> # 192.168.0.70 and an infinite lease
> #dhcp-host=bert,192.168.0.70,infinite

 Do not work with my setup, because when we re-deploy a VM, the MAC
 address will be autom. changed.
 The re-delpoyed VM will than get a different IP as the old vm had
 before.

>>>
>>> I just tested this option  and the behavior described is correct with
>>> dnsmasq 2.76, from the man page:
>>
>> I have running the version 2.78.
>>
>>> "--dhcp-host=lap,192.168.0.199 tells dnsmasq to always allocate the
>>> machine lap the IP address 192.168.0.199.
>>> Addresses allocated like this are not constrained to be in the range
>>> given by the --dhcp-range option, but they must be in the same subnet as
>>> some valid dhcp-range. For subnets which don't need"
>>
>> Yes, the config "--dhcp-host=lap,192.168.0.199" is working. The VM with
>> the hostname "lap" will get the IP 192.168.0.199.
>>
>> But, I have the problem, when I have a new VM, a new version of the VM
>> "lap" which have a different MAC address.
>> Than, that new version of VM "lap" get not the 192.168.0.199. They get
>> an other IP from the pool.
>>
>>> As long as a client use the hostname ("lap") the same IP will always be
>>> given to that client, the MAC address is not used.
>>>
>>
>> As far as I see, for the "first" IP provisioning that is true -> the
>> Hostname is enough.
>> But, than the "dnsmasq.leases" file have also the MAC address and
>> Client-ID values stored, which will be compared an the next DHCP Requests.
>> If than one of the values are different (MAC, CLIENT-ID) the DHCP-Client
>> will get an other IP.
>>
>> Please see below, a example...
>>
>>
>
> See also (1) for more info on 'dhcp-host'.
>
>
> 1)  http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html


 Maybe is it possible to "patch" the code of dnsmasq, where dnsmasq can
 ignore the MAC address in the DHCP task?

>>>
>>> Possibly, more nolageable dnsmasqer would need to chime in to do that
>>> though! :)
>>> If '--dhcp-host=hostname,IP' is not working for you more info would need
>>> to be provided.
>>>
>>
>>
>> BTW: the VM "lap" does not have set a special "DHCP-Client-Identifier",
>> so it use for DHCP-Client-ID the MAC address.
>>
>>
>> Here some outputs of the dnsmasq.leases file:
>>
>> # inital DHCP-Request:
>>
>> 1547107342 00:50:56:85:02:fa 192.168.0.199 lap 01:00:50:56:85:02:fa
>>
>> As you can see, the VM "lap" (MAC 00:50:56:85:02:fa) get the expected IP
>> -> so far so good.
>>
>>
>> Next, I power off the VM "lap" without a DHCP-Release and deploy a copy
>> of the VM "lap" which have than an other MAC (00:50:56:85:02:ff) ! ->
>> the MAC will always set by the deployment of a new VM version.
>>
>>
>> Now, I start the new version of the VM "lap" (the old version of the VM
>> "lap" is no longer available.
>>
>> The dnsmasq.leases looks now, like this:
>> 1547116110 00:50:56:85:02:ff 192.168.0.200 lap 01:00:50:56:85:02:ff
>> 1547107342 00:50:56:85:02:fa 192.168.0.199 * 01:00:50:56:85:02:fa
>>
>>
>> As you see, the VM "lap" have now the IP "192.168.0.200" and not the
>> expected IP "192.168.0.199.
>>
>> Do you have an idea how I can fix that?
>> I tested different options with "--dhcp-host", but with no luck.
>>
>> I hope you can help my.
>>
> 
> Beside looking at the VM software to always assign the same MAC address
> to the same guest and the fact that I'm able to reproduce what you are
> seeing, that is all I can offer.
> 

I have already checked the VM deployment software, when a new version of
a VM will be cloned/deployed, the VM-deployment-layer give that new
clone/deployed VM a different MAC.

As I said, for Linux VM's, I can set a uniq Client-ID that helps, but on
Windows you can not set define a Client-ID (as far as I know).

I have already try to find in the dnsmasq code the part, where the
incoming DHCP-Request will be received and maybe I can change or set the
Client-ID (fake) for the upcoming processing, but i did not found the
correct part of the code and also have no good knowhow in C.

I will try to find the part and do than some changes and tests.

If maybe someone can give me some hints, that's very welcome.

Many thanks
Michael

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


Re: [Dnsmasq-discuss] debugging dhcpv6 requests forwarded via relay agent

2019-01-10 Thread Geert Stappers
On Thu, Jan 10, 2019 at 05:48:26PM +0530, Sandeep K M wrote:
> On Wed, Jan 9, 2019 at 10:33 PM Simon Kelley wrote:
> > On 04/01/2019 06:25, Sandeep K M wrote:
> > >
> > > Attached are the packet captures:
> > >
> > > 1. Packets exchanged between client and relay (client-relay.pcap)
> > > 2.  Packets exchanged between relay and server (relay-server.pcap)
> > > 3. strace of dnsmasq (dnsmasq.trace)
> > >
   ...
> >
> > I'm sure this was tested with a relay, but the current test harnesses
> > here would take some work to get into a position to test this code, so
> > I'm going to try and use you as a tester, if that's OK?
> >
> >
> > Looking at the strace output, dnsmasq logs that it's sending a
> > DHCPADVERTISE reply, but it never calls sendto() to actually send the
> > packet. This is definitely a dnsmasq bug, and not something in your
> > network that's causing the packet to get lost: it never gets sent.
> >
> >
> > What's confusing me is that manually tracing the code paths from what's
> > known to be working (log the DHCPADVERTISE) to the sendto() call that
> > should send that packet, I can't see any reason why the code should fail.
> >
> > Are you in a position to run dnsmasq under gdb and step through the
> > relevant code? I can give you detailed instructions on where to set
> > breakpoints and where the reply packet could be getting lost. The path
> > is maybe 50 lines.
> >
> > Staring at the code has found me one bug, but it's not relevant in this
> > case. (The code to avoid copying an RFC6939 link address option in a
> > relay request to the reply to the relay actually sends a zero-length
> > option, instead of eliding it entirely.)
> >
> 
> I will be happy to be your tester :)
> 
> Its fairly a simple setup with two hosts and a switch. I can create this
> any time you want.
> 
> Please provide me the instructions. I am using dnsmasq version 2.78.


Keeping the ML in loop would be good.
At least for the sake of the mailinglist archive.


Regards
Geert Stappers


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


Re: [Dnsmasq-discuss] dnsmasq 2.78 is failing to respond to dhcpv6 requests forwarded via relay agent

2019-01-10 Thread Sandeep K M
Hi Simon,

Thanks again for the response.

I will be happy to be your tester :)

Its fairly a simple setup with two hosts and a switch. I can create this
any time you want.

Please provide me the instructions. I am using dnsmasq version 2.78.

Thanks
-Sandeep

On Wed, Jan 9, 2019 at 10:33 PM Simon Kelley 
wrote:

> On 04/01/2019 06:25, Sandeep K M wrote:
> > Hi Simon,
> >
> > Thanks a lot for your prompt reply.
> >
> > Attached are the packet captures:
> >
> > 1. Packets exchanged between client and relay (client-relay.pcap)
> > 2.  Packets exchanged between relay and server (relay-server.pcap)
> > 3. strace of dnsmasq (dnsmasq.trace)
> >
> > Please let me know if any other information is required.
> >
> > I am not an expert in reading pcap's or strace but I do see in the
> > attached strace i.e. dnsmasq.trace file that ""DHCPADVERTISE" message is
> > being written to the same interface from which it received the
> > "DHCPSOLICIT" packet. But still it is fails to go out of that interface.
> >
> > 06:04:09.371741 write(2, "DHCPADVERTISE(m1s1p7) 2020::14
> > 00:01:00:01:23:c1:b0:e2:00:50:56:bd:09:fb ", 73) = 73
> >
> > Any help on this would be greatly appreciated. Also is there any example
> > configuration of dnsmasq dhcpv6 working with relay ? Any reference would
> > be of great help.
> >
>
> I'm sure this was tested with a relay, but the current test harnesses
> here would take some work to get into a position to test this code, so
> I'm going to try and use you as a tester, if that's OK?
>
>
> Looking at the strace output, dnsmasq logs that it's sending a
> DHCPADVERTISE reply, but it never calls sendto() to actually send the
> packet. This is definitely a dnsmasq bug, and not something in your
> network that's causing the packet to get lost: it never gets sent.
>
>
> What's confusing me is that manually tracing the code paths from what's
> known to be working (log the DHCPADVERTISE) to the sendto() call that
> should send that packet, I can't see any reason why the code should fail.
>
> Are you in a position to run dnsmasq under gdb and step through the
> relevant code? I can give you detailed instructions on where to set
> breakpoints and where the reply packet could be getting lost. The path
> is maybe 50 lines.
>
> Staring at the code has found me one bug, but it's not relevant in this
> case. (The code to avoid copying an RFC6939 link address option in a
> relay request to the reply to the relay actually sends a zero-length
> option, instead of eliding it entirely.)
>
> Cheers,
>
> Simon.
>
>
>
>
>
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] DHCP, how to ignore the client MAC address?

2019-01-10 Thread john doe
On 1/9/2019 11:38 AM, MIchael Schleicher wrote:
> 
> On 09.01.19 08:14, john doe wrote:
>> On 1/8/2019 11:31 AM, smicha wrote:
>>> Hi John,
>>>
>>> thanks for your reply.
>>>
>>> I did some tests with your hints.
>>>
>>> On 7.1.2019 17:41, john doe wrote:

 Some hints from dnsmasq.conf:

 # Give the machine which says its name is "bert" IP address
 # 192.168.0.70 and an infinite lease
 #dhcp-host=bert,192.168.0.70,infinite
>>>
>>> Do not work with my setup, because when we re-deploy a VM, the MAC
>>> address will be autom. changed.
>>> The re-delpoyed VM will than get a different IP as the old vm had
>>> before.
>>>
>>
>> I just tested this option  and the behavior described is correct with
>> dnsmasq 2.76, from the man page:
> 
> I have running the version 2.78.
> 
>> "--dhcp-host=lap,192.168.0.199 tells dnsmasq to always allocate the
>> machine lap the IP address 192.168.0.199.
>> Addresses allocated like this are not constrained to be in the range
>> given by the --dhcp-range option, but they must be in the same subnet as
>> some valid dhcp-range. For subnets which don't need"
> 
> Yes, the config "--dhcp-host=lap,192.168.0.199" is working. The VM with
> the hostname "lap" will get the IP 192.168.0.199.
> 
> But, I have the problem, when I have a new VM, a new version of the VM
> "lap" which have a different MAC address.
> Than, that new version of VM "lap" get not the 192.168.0.199. They get
> an other IP from the pool.
> 
>> As long as a client use the hostname ("lap") the same IP will always be
>> given to that client, the MAC address is not used.
>>
> 
> As far as I see, for the "first" IP provisioning that is true -> the
> Hostname is enough.
> But, than the "dnsmasq.leases" file have also the MAC address and
> Client-ID values stored, which will be compared an the next DHCP Requests.
> If than one of the values are different (MAC, CLIENT-ID) the DHCP-Client
> will get an other IP.
> 
> Please see below, a example...
> 
> 

 See also (1) for more info on 'dhcp-host'.


 1)  http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html
>>>
>>>
>>> Maybe is it possible to "patch" the code of dnsmasq, where dnsmasq can
>>> ignore the MAC address in the DHCP task?
>>>
>>
>> Possibly, more nolageable dnsmasqer would need to chime in to do that
>> though! :)
>> If '--dhcp-host=hostname,IP' is not working for you more info would need
>> to be provided.
>>
> 
> 
> BTW: the VM "lap" does not have set a special "DHCP-Client-Identifier",
> so it use for DHCP-Client-ID the MAC address.
> 
> 
> Here some outputs of the dnsmasq.leases file:
> 
> # inital DHCP-Request:
> 
> 1547107342 00:50:56:85:02:fa 192.168.0.199 lap 01:00:50:56:85:02:fa
> 
> As you can see, the VM "lap" (MAC 00:50:56:85:02:fa) get the expected IP
> -> so far so good.
> 
> 
> Next, I power off the VM "lap" without a DHCP-Release and deploy a copy
> of the VM "lap" which have than an other MAC (00:50:56:85:02:ff) ! ->
> the MAC will always set by the deployment of a new VM version.
> 
> 
> Now, I start the new version of the VM "lap" (the old version of the VM
> "lap" is no longer available.
> 
> The dnsmasq.leases looks now, like this:
> 1547116110 00:50:56:85:02:ff 192.168.0.200 lap 01:00:50:56:85:02:ff
> 1547107342 00:50:56:85:02:fa 192.168.0.199 * 01:00:50:56:85:02:fa
> 
> 
> As you see, the VM "lap" have now the IP "192.168.0.200" and not the
> expected IP "192.168.0.199.
> 
> Do you have an idea how I can fix that?
> I tested different options with "--dhcp-host", but with no luck.
> 
> I hope you can help my.
> 

Beside looking at the VM software to always assign the same MAC address
to the same guest and the fact that I'm able to reproduce what you are
seeing, that is all I can offer.

-- 
John Doe

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