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

2019-01-11 Thread john doe
On 1/11/2019 8:48 PM, Michael Schleicher wrote:
> Hi Geert,
> 
> thanks for you mail.
> 
> On 1/11/19 6:50 PM, Geert Stappers wrote:
>> On Fri, Jan 11, 2019 at 11:29:13AM +0100, MIchael Schleicher (smicha) wrote:
>>> On 11.01.19 10:53, john doe wrote:
 On 1/11/2019 9:49 AM, MIchael Schleicher (smicha) wrote:
>
> I have just checked on my environment what's in the dnsmasq.leases file:
>
> 1547246444 00:50:56:85:23:ea 10.198.10.223 win-vm 01:00:50:56:85:23:ea
> 1547276503 00:50:56:85:f1:86 10.198.10.37 linux-vm 01:00:50:56:85:f1:86
>
> As you see the Client-ID (5th field) is the MAC + "01:" as prefix.
>

 You previously said that the hostname is always the same, as ilustrated
 by the above they are not (win-vm vs linux-vm)?

>>>
>>> That are 2 different systems. (1 Windows and 1 Linux VM). It's just a
>>> example
>>>
>>
>> Thing I would like to known is the name of the virtualisation platform.
>> Mostly because all those I seen did allow me to define MAC address.
>>
> 
> The virtual landscapes (VM's) are running on VMware ESX Cluster.
> The ESX Hosts are "controlled" by a software which called
> "eCloud-Manager". That are deploying the different clones of landscapes.
> 
> We have a bunch of master VM's and the software deploy that VM's in
> different isolated landscapes. (each landscape is isolated with vlans
> and includes a copy of the Masters (but with different MAC as the Master
> VM's have!).
> 
> So, when a cloned VM in one of the virtual landscapes are crash or have
> some other problems, the software destorys the VM and deploy a copy of
> the Master-VM, with a different MAC to that landscapes.
> 
> And that is exactly the problem, during the deployment of that cloned VM
> from the Master, the MAC will changed from the eCloud-Manager during the
> VMWare deployment.
> 
> I hope I gave you a understandable description.
> 

If the maintaner of dnsmasq has not chimed in that leav us with to options:
- To much on his plate, something could be done to answer this question.
- The issue lies elsewhere (predicting way for MAC addressing).

-- 
John Doe

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


Re: [Dnsmasq-discuss] Config Parcing Bug

2019-01-11 Thread wkitty42

On 1/11/19 7:22 PM, Tasnad Kernetzky wrote:

Hi all,

I wanted to report a bug (at least we belieave it is one). We had a
short discussion over at the archlinux bugtracker
(https://bugs.archlinux.org/task/60366).

In short:


echo 'address=/ab--c.example.com/#' | dnsmasq --test -C -



dnsmasq: error at line 1 of stdin


Althoug the URL is "forbidden":


host 'ab--c.example.com'
host: 'ab--c.example.com' is not a legal IDNA2008 name (string

contains forbidden two hyphens pattern), use +noidnin



is that a punycode domain name? all the one's i've seen are written as

  xn--codehere.invalid

firefox has a specific option we set so we don't get taken in by look-alike 
homographs... specifically the links with unicode characters in them are 
displayed in their punycode form, xn--blahblah... these links explain more if 
some folks don't know about this aspect of the DNS system...


https://en.wikipedia.org/wiki/Internationalized_domain_name#ASCII_spoofing_concerns
https://en.wikipedia.org/wiki/IDN_homograph_attack
https://en.wikipedia.org/wiki/Punycode#Internationalized_domain_names


--
 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


[Dnsmasq-discuss] Config Parcing Bug

2019-01-11 Thread Tasnad Kernetzky
Hi all,

I wanted to report a bug (at least we belieave it is one). We had a
short discussion over at the archlinux bugtracker
(https://bugs.archlinux.org/task/60366).

In short:

> echo 'address=/ab--c.example.com/#' | dnsmasq --test -C -

> dnsmasq: error at line 1 of stdin

Althoug the URL is "forbidden":

> host 'ab--c.example.com'
> host: 'ab--c.example.com' is not a legal IDNA2008 name (string
contains forbidden two hyphens pattern), use +noidnin

it would be nice to be able to block it. We ended up there, since the
filter list from
https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts started
to include these kinds of URLs.


My feeling is, that parsing the two dashes somehow fails. Interestingly,
adding one more character before the dashes does not trigger the bug:

> echo 'address=/abb--c.example.com/#' | dnsmasq --test -C -

> dnsmasq: syntax check OK.


Escaping (ab\-\-c.example.com) allows dnsmasq to start, but renders the
line ineffective.


Do you know about this and is it intended behaviour?


Regards,

Tasnad




signature.asc
Description: OpenPGP digital signature
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


[Dnsmasq-discuss] Determine wireless SSID

2019-01-11 Thread Donald Muller
This is probably not possible but I thought I would ask.

Is it possible for DNSMASQ to determine the SSID for a DHCP request? I would 
like to be able to assign different values for devices using the guest network. 
DNSMASQ is running on my QNAP NAS while I have a Netgear wireless router 
providing the wireless connectivity.

Thanks

-
"Everyone is entitled to his own opinion, but not to his own facts." - Daniel 
Patrick Moynihan

___
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-11 Thread Michael Schleicher
Hi Geert,

thanks for you mail.

On 1/11/19 6:50 PM, Geert Stappers wrote:
> On Fri, Jan 11, 2019 at 11:29:13AM +0100, MIchael Schleicher (smicha) wrote:
>> On 11.01.19 10:53, john doe wrote:
>>> On 1/11/2019 9:49 AM, MIchael Schleicher (smicha) wrote:

 I have just checked on my environment what's in the dnsmasq.leases file:

 1547246444 00:50:56:85:23:ea 10.198.10.223 win-vm 01:00:50:56:85:23:ea
 1547276503 00:50:56:85:f1:86 10.198.10.37 linux-vm 01:00:50:56:85:f1:86

 As you see the Client-ID (5th field) is the MAC + "01:" as prefix.

>>>
>>> You previously said that the hostname is always the same, as ilustrated
>>> by the above they are not (win-vm vs linux-vm)?
>>>
>>
>> That are 2 different systems. (1 Windows and 1 Linux VM). It's just a
>> example
>>
> 
> Thing I would like to known is the name of the virtualisation platform.
> Mostly because all those I seen did allow me to define MAC address.
> 

The virtual landscapes (VM's) are running on VMware ESX Cluster.
The ESX Hosts are "controlled" by a software which called
"eCloud-Manager". That are deploying the different clones of landscapes.

We have a bunch of master VM's and the software deploy that VM's in
different isolated landscapes. (each landscape is isolated with vlans
and includes a copy of the Masters (but with different MAC as the Master
VM's have!).

So, when a cloned VM in one of the virtual landscapes are crash or have
some other problems, the software destorys the VM and deploy a copy of
the Master-VM, with a different MAC to that landscapes.

And that is exactly the problem, during the deployment of that cloned VM
from the Master, the MAC will changed from the eCloud-Manager during the
VMWare deployment.

I hope I gave you a understandable description.

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] DHCP, how to ignore the client MAC address?

2019-01-11 Thread Geert Stappers
On Fri, Jan 11, 2019 at 11:29:13AM +0100, MIchael Schleicher (smicha) wrote:
> On 11.01.19 10:53, john doe wrote:
> > On 1/11/2019 9:49 AM, MIchael Schleicher (smicha) wrote:
> > > 
> > > I have just checked on my environment what's in the dnsmasq.leases file:
> > > 
> > > 1547246444 00:50:56:85:23:ea 10.198.10.223 win-vm 01:00:50:56:85:23:ea
> > > 1547276503 00:50:56:85:f1:86 10.198.10.37 linux-vm 01:00:50:56:85:f1:86
> > > 
> > > As you see the Client-ID (5th field) is the MAC + "01:" as prefix.
> > > 
> > 
> > You previously said that the hostname is always the same, as ilustrated
> > by the above they are not (win-vm vs linux-vm)?
> > 
> 
> That are 2 different systems. (1 Windows and 1 Linux VM). It's just a
> example
> 

Thing I would like to known is the name of the virtualisation platform.
Mostly because all those I seen did allow me to define MAC address.


Cheers
Geert Stappers
DevOps Engineer

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


Re: [Dnsmasq-discuss] [PATCH] DHCPv6: Honor assigning IPv6 address based on MAC address

2019-01-11 Thread Pali Rohár
Hello, can somebody look at this patch?

I remember that more people asked for ability to assign IPv6 address
based on MAC address specified in config file, rather then IAID/DUID.

On Monday 17 December 2018 18:41:09 Pali Rohár wrote:
> Currently IPv6 addresses are assigned to tuple (IAID, DUID). When system
> changes IAID/DUID then old assigned IPv6 address cannot be reused, even
> when in config file was DHCPv6 assignment based on MAC address (and not on
> DUID).
> 
> IAID/DUID is changed when rebooting from one operating system to another;
> or after reinstalling system. In reality it is normal that DUID of some
> machine is changed, so people rather assign also IPv6 addresses based on
> MAC address.
> 
> So assigning IPv6 based on MAC address in dnsmasq is currently semi-broken.
> 
> This patch tries to fix it and honors IPv6 config rules with MAC address,
> to always assign particular IPv6 address to specific MAC address (when
> configured). And ignores the fact if IAID/DUID was changed.
> 
> Normally IPv6 address should be assigned by IAID/DUID (which also state
> DHCPv6 RFCs), but dnsmasq has already some support for assigning IPv6
> address based on MAC address, when users configured in config file.
> 
> So this patch just tries to fix above problem for user configuration with
> MAC addresses. It does not change assignment based on DUID.
> 
> Also this patch adds support for allowing IPv6 address to be associated
> with multiple hardware addresses, and gives dnsmasq permission to abandon a
> lease. This is similar functionality as already supported for IPv4 address.
> ---
>  man/dnsmasq.8 |  9 ++---
>  src/rfc3315.c | 62 
> ++-
>  2 files changed, 59 insertions(+), 12 deletions(-)
> 
> diff --git a/man/dnsmasq.8 b/man/dnsmasq.8
> index f01a5ba..8614f08 100644
> --- a/man/dnsmasq.8
> +++ b/man/dnsmasq.8
> @@ -1068,10 +1068,13 @@ will only match a
>  Token-Ring hardware address, since the ARP-address type for token ring
>  is 6. 
>  
> -As a special case, in DHCPv4, it is possible to include more than one
> -hardware address. eg:
> +It is possible to include more than one hardware address. eg for IPv4:
>  .B --dhcp-host=11:22:33:44:55:66,12:34:56:78:90:12,192.168.0.2
> -This allows an IP address to be associated with
> +or for IPv6:
> +.B --dhcp-host=11:22:33:44:55:66,12:34:56:78:90:12,[::2]
> +or for both:
> +.B --dhcp-host=11:22:33:44:55:66,12:34:56:78:90:12,192.168.0.2,[::2]
> +This allows an IPv4 and/or IPv6 address to be associated with
>  multiple hardware addresses, and gives dnsmasq permission to abandon a
>  DHCP lease to one of the hardware addresses when another one asks for
>  a lease. Beware that this is a dangerous thing to do, it will only
> diff --git a/src/rfc3315.c b/src/rfc3315.c
> index a20776d..c83cf2d 100644
> --- a/src/rfc3315.c
> +++ b/src/rfc3315.c
> @@ -54,7 +54,7 @@ static struct prefix_class 
> *prefix_class_from_context(struct dhcp_context *conte
>  #endif
>  static void mark_context_used(struct state *state, struct in6_addr *addr);
>  static void mark_config_used(struct dhcp_context *context, struct in6_addr 
> *addr);
> -static int check_address(struct state *state, struct in6_addr *addr);
> +static int check_address(struct state *state, struct dhcp_config *config, 
> struct in6_addr *addr);
>  static void add_address(struct state *state, struct dhcp_context *context, 
> unsigned int lease_time, void *ia_option, 
>   unsigned int *min_time, struct in6_addr *addr, time_t 
> now);
>  static void update_leases(struct state *state, struct dhcp_context *context, 
> struct in6_addr *addr, unsigned int lease_time, time_t now);
> @@ -746,7 +746,7 @@ static int dhcp6_no_relay(struct state *state, int 
> msg_type, void *inbuff, size_
>   /* If the client asks for an address on the same network as 
> a configured address, 
>  offer the configured address instead, to make moving to 
> newly-configured
>  addresses automatic. */
> - if (!(c->flags & CONTEXT_CONF_USED) && config_valid(config, 
> c, ) && check_address(state, ))
> + if (!(c->flags & CONTEXT_CONF_USED) && config_valid(config, 
> c, ) && check_address(state, config, ))
> {
>   req_addr = addr;
>   mark_config_used(c, );
> @@ -755,8 +755,14 @@ static int dhcp6_no_relay(struct state *state, int 
> msg_type, void *inbuff, size_
> }
>   else if (!(c = address6_available(state->context, 
> _addr, solicit_tags, plain_range)))
> continue; /* not an address we're allowed */
> - else if (!check_address(state, _addr))
> + else if (!check_address(state, config, _addr))
> continue; /* address leased elsewhere */
> + else if (state->mac_len && config &&
> +  

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

2019-01-11 Thread MIchael Schleicher (smicha)

Hi John,

On 11.01.19 10:53, john doe wrote:

On 1/11/2019 9:49 AM, MIchael Schleicher (smicha) wrote:

Hi,

thanks for your reply.

On 10.01.19 22:25, wkitt...@gmail.com wrote:

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...




I have just checked on my environment what's in the dnsmasq.leases file:

1547246444 00:50:56:85:23:ea 10.198.10.223 win-vm 01:00:50:56:85:23:ea
1547276503 00:50:56:85:f1:86 10.198.10.37 linux-vm 01:00:50:56:85:f1:86

As you see the Client-ID (5th field) is the MAC + "01:" as prefix.



You previously said that the hostname is always the same, as ilustrated
by the above they are not (win-vm vs linux-vm)?



That are 2 different systems. (1 Windows and 1 Linux VM). It's just a 
example



Thanks
Michael

___
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-11 Thread john doe
On 1/11/2019 9:49 AM, MIchael Schleicher (smicha) wrote:
> Hi,
> 
> thanks for your reply.
> 
> On 10.01.19 22:25, wkitt...@gmail.com wrote:
>> 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...
>>
>>
> 
> I have just checked on my environment what's in the dnsmasq.leases file:
> 
> 1547246444 00:50:56:85:23:ea 10.198.10.223 win-vm 01:00:50:56:85:23:ea
> 1547276503 00:50:56:85:f1:86 10.198.10.37 linux-vm 01:00:50:56:85:f1:86
> 
> As you see the Client-ID (5th field) is the MAC + "01:" as prefix.
> 

You previously said that the hostname is always the same, as ilustrated
by the above they are not (win-vm vs linux-vm)?

-- 
John Doe

___
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-11 Thread Simon Kelley
Great. I'm distressed I didn't remember the issue until I ran "git
blame" over the code when putting together debugging instructions.

Cheers,

Simon.


On 11/01/2019 08:47, Sandeep K M wrote:
> Thanks a lot Simon, that did the trick.
> 
> The patch fixed the issue. I am able to see the reply messages being
> sent by server and the same being received by the client:
> 
> Jan 11 06:46:52 dnsmasq[4131]: started, version 2.78 DNS disabled
> Jan 11 06:46:52 dnsmasq[4131]: compile time options: IPv6 GNU-getopt
> no-DBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth
> no-DNSSEC loop-detect inotify
> Jan 11 06:46:52 dnsmasq-dhcp[4131]: DHCPv6, IP range 2020::10 --
> 2020::20, lease time 1h
> Jan 11 06:47:47 dnsmasq-dhcp[4131]: DHCPSOLICIT(m1s1p1)
> 00:01:00:01:23:ca:f8:95:00:50:56:96:32:20
> Jan 11 06:47:47 dnsmasq-dhcp[4131]: DHCPADVERTISE(m1s1p1) 2020::12
> 00:01:00:01:23:ca:f8:95:00:50:56:96:32:20
> Jan 11 06:47:48 dnsmasq-dhcp[4131]: DHCPREQUEST(m1s1p1)
> 00:01:00:01:23:ca:f8:95:00:50:56:96:32:20
> Jan 11 06:47:48 dnsmasq-dhcp[4131]: DHCPREPLY(m1s1p1) 2020::12
> 00:01:00:01:23:ca:f8:95:00:50:56:96:32:20
> Jan 11 07:17:48 dnsmasq-dhcp[4131]: DHCPRENEW(m1s1p1)
> 00:01:00:01:23:ca:f8:95:00:50:56:96:32:20
> Jan 11 07:17:48 dnsmasq-dhcp[4131]: DHCPREPLY(m1s1p1) 2020::12
> 00:01:00:01:23:ca:f8:95:00:50:56:96:32:20
> 
> Everything is working fine even the renew. Thanks again.
> 
> Thanks
> -Sandeep
> 
> On Fri, Jan 11, 2019 at 3:21 AM Simon Kelley  > wrote:
> 
> 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
> mailto:si...@thekelleys.org.uk>
> > >>
> 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 

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

2019-01-11 Thread Sandeep K M
Thanks a lot Simon, that did the trick.

The patch fixed the issue. I am able to see the reply messages being sent
by server and the same being received by the client:

Jan 11 06:46:52 dnsmasq[4131]: started, version 2.78 DNS disabled
Jan 11 06:46:52 dnsmasq[4131]: compile time options: IPv6 GNU-getopt
no-DBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth
no-DNSSEC loop-detect inotify
Jan 11 06:46:52 dnsmasq-dhcp[4131]: DHCPv6, IP range 2020::10 -- 2020::20,
lease time 1h
Jan 11 06:47:47 dnsmasq-dhcp[4131]: DHCPSOLICIT(m1s1p1)
00:01:00:01:23:ca:f8:95:00:50:56:96:32:20
Jan 11 06:47:47 dnsmasq-dhcp[4131]: DHCPADVERTISE(m1s1p1) 2020::12
00:01:00:01:23:ca:f8:95:00:50:56:96:32:20
Jan 11 06:47:48 dnsmasq-dhcp[4131]: DHCPREQUEST(m1s1p1)
00:01:00:01:23:ca:f8:95:00:50:56:96:32:20
Jan 11 06:47:48 dnsmasq-dhcp[4131]: DHCPREPLY(m1s1p1) 2020::12
00:01:00:01:23:ca:f8:95:00:50:56:96:32:20
Jan 11 07:17:48 dnsmasq-dhcp[4131]: DHCPRENEW(m1s1p1)
00:01:00:01:23:ca:f8:95:00:50:56:96:32:20
Jan 11 07:17:48 dnsmasq-dhcp[4131]: DHCPREPLY(m1s1p1) 2020::12
00:01:00:01:23:ca:f8:95:00:50:56:96:32:20

Everything is working fine even the renew. Thanks again.

Thanks
-Sandeep

On Fri, Jan 11, 2019 at 3:21 AM Simon Kelley 
wrote:

> 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-11 Thread MIchael Schleicher (smicha)

Hi,

thanks for your reply.

On 10.01.19 22:25, wkitt...@gmail.com wrote:

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...





I have just checked on my environment what's in the dnsmasq.leases file:

1547246444 00:50:56:85:23:ea 10.198.10.223 win-vm 01:00:50:56:85:23:ea
1547276503 00:50:56:85:f1:86 10.198.10.37 linux-vm 01:00:50:56:85:f1:86

As you see the Client-ID (5th field) is the MAC + "01:" as prefix.

Many Thanks
Michael


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