Re: [Dnsmasq-discuss] [solved] define IPv6 prefix for host-records

[Carsten Spieß]

Hello Simon,

> You're trying to invent yet another way of solving the "naming IPv6
> hosts" problem, 
yes ;)

> made more difficult by the fact that they change
> addresses as the delegated prefix changes.
 
> There are a couple of other possibilities.
> 
> 1) If you're using DHCP for IPv4, look at the dnsmasq "ra-names"
> facility, which can make creating DNS entries for RA-allocated
> addresses automatic.
i'll have a look, but:
 
> 2) Consider giving your hosts ULA addresses as well as addresses with
> the prefix you get from you ISP. If you just want a DNS name that's
> usable from the local net, then that gives you a stable address to
> associate with the DNS name.
That's _the_ good idea (why i didn't have it myself)!
It's like the NATed private IPv4 addresses i use locally.
The delegated prefix is only for outside connections.

That's it, thanks,
Carsten
-- 
Carsten Spieß
Lauterlech 39d
D-86152 Augsburg
Tel.: +49(821)51 78 65
mailto://fl...@carsten-spiess.de


pgpYa9f0YxHbM.pgp
Description: Digitale Signatur von OpenPGP
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] [PATCH] DHCPv6: Add support for more than one hardware address per IPv6 address

[Pali Rohár]

On Friday 12 May 2017 17:15:20 Simon Kelley wrote:
> There are so many layers of quotes here that I've completely lost
> track of what we were trying to achieve, and how to achieve it. My
> memory is that we'd failed to come up with any consensus on either
> of those.

Goal 1:

Ability to assign one IPv4 address to two different MAC addresses. 
Currently it is possible by misusing concept of "more mac addresses" 
(where IPv4 address can be "steal" by later DHCP client).

Goal 2:

Achieve Goal 1 also for DHCPv6.

> Using MAC addresses with DHCPv6 AT ALL is quite difficult - it's not
> a concept that the RFCs deal with.

I read DHCPv6 RFC and it does not refuse assigning IPv6 address based on 
link layer MAC address. Anyway, this is already supported by dnsmasq.

But what I want to achieve has ability to assign one IPv6 address to 
more MAC addresses at same time. This DHCPv6 RFC does not allow, but in 
some situations it is useful and I think such options could be provided 
by DHCPv6 server with explicit warning in documentation.

> Doing the sleight-of-hand trick
> that works with DHCPv4 doesn't seem feasible to me for DHCPv6.

Do you completely disagree with fact that dnsmasq could support this 
scenario for assigning one IP address to more network cards (identified 
by MAC address)? Or you just do not like my current implementation?

In previous email I wrote that Goal 2 can be achieved by storing tuple 
DUID, IAID, MAC address and IPv6 address into DHCPv6 leases file.

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] [PATCH] DHCPv6: Add support for more than one hardware address per IPv6 address

[Simon Kelley]

On 09/05/17 10:21, Pali Rohár wrote:
> On Sunday 02 October 2016 11:43:43 Pali Rohár wrote:
>> On Wednesday 27 January 2016 13:37:27 Pali Rohár wrote:
>>> On Wednesday 20 January 2016 20:15:23 Simon Kelley wrote:
 Dnsmasq identifies IPv6 clients via their MAC address for the
 purpose of selecting dhcp-host configuration to use, but it
 doesn't use the MAC address as a unique client identifier for the
 purpose of assigning DHCP leases in the same way the DHCPv4 does.
 That's the crucial difference.
>>>
>>> Yes, I know.
>>>
 The equivalent of the DHCPv4 share MAC address facility, should
 really be something  which shares IAIDs, maybe?
>>>
>>> Right, in lease file is stored pair (MAC address, IP address) for
>>> IPv4 and pair (IAID, IPv6 address) for IPv6.
>>>
 The crucial thing I'm trying to achieve here is turning your patch
 from something that works on your network, with your very odd
 configuration, into something that other people might want and use.
 Without that, it's fine as your patch, but it can't go into the
 dnsmasq mainline.
>>>
>>> Understood.
>>>
 Maybe the way to think about that is to think about
 how to document it. If we can describe what problem it solves, and
 how it should be used, then we'll be getting there.
>>>
>>> I was thinking about it for more days. It is really not easy to solve
>>> this problem... Here are my results:
>>>
>>> * There are people who misuse original concept of "more mac
>>> addresses" for one ipv4 address. Dnsmasq supports this configuration
>>> only if one mac address from that --dhcp-host line is used at same
>>> time.
>>>
>>> * DHCPv6 clients are identified by DUID string, which we can say is
>>>   totally random and are not persistent across multi-OS computers or
>>>   reinstalling...
>>>
>>> * Internally DHCPv6 leases are identified by IAID.
>>>
>>> So to make configuration clean for both IPv4 and IPv6 we need support
>>> for:
>>>
>>> * Assigning IPv4 lease to more MAC addresses at the same time
>>>   (This will help people to use "more mac addresses" functionality
>>> correctly)
>>>
>>> * Assigning IPv6 address to more DUIDs at the same time
>>>   (This is "correct" IPv6 equivalent for previous request)
>>>
>>> * Assigning IPv6 address to more MAC addresses at the same time
>>>   (This is what would fix DUID problem)
>>>
>>> And it means that pair (IAID, IPv6 address) for IPv6 leases it not
>>> enough to do it.
>>>
>>> So, what about extending lease line for IPv6 addresses to include
>>> DUID and MAC address?
>>>
 We need to bear in
 mind that the behaviour we're talking about violates the RFCs
 specifying DHCPv6, so it has to be especially carefull justified.
>>>
>>> Thats probably truth, but if something is useful users will try to
>>> use it. Either itself by patching dnsmasq or if possible by optional
>>> config options...
>>
>> Hi Simon! Replaying to my old email from January. Have you found some 
>> time to look at my suggestions? If yes, what do you think about it?
>>
> 
> PING again.
> 

There are so many layers of quotes here that I've completely lost track
of what we were trying to achieve, and how to achieve it. My memory is
that we'd failed to come up with any consensus on either of those.

Using MAC addresses with DHCPv6 AT ALL is quite difficult - it's not a
concept that the RFCs deal with. Doing the sleight-of-hand trick that
works with DHCPv4 doesn't seem feasible to me for DHCPv6.


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 vendor-option and grub net_pxe_extensionspath

[Simon Kelley]

On 11/05/17 23:22, Carl Karsten wrote:
> I am pondering something I am not sure I even want: I guess we can call
> it a default option 209
> 
> Is this valid, reliable, predictable?
> 
> dhcp-option-force=209,"partman-auto/disk=/dev/sda"
> 
> dhcp-host=00:26:9e:03:9d:e5,set:negk,negk
> dhcp-option-force=tag:negk,209,"partman-auto/disk=/dev/sdb"
> 
> 
> The hope is ...sda except for the tag:negk case.

Yeah, that's how it's defined to work: and option which is conditional
on a tag gets used in preference to one which is not conditional, of the
tag is set.


Cheers,

Simon.

> 
> personally I only touch 20 machines a year, so setting up the extra 19
> lines
> is easy.  I like to understand my tools, and maybe someone with 100''s
> will be interested in my setup.  probaly not ;)
> 
> 
> 
> 
> On Sun, Apr 30, 2017 at 11:58 PM, Carl Karsten  > wrote:
> 
> woked - yay.
> 
> dhcp-host=00:26:9e:03:9d:e5,set:negk,negk
> dhcp-option-force=tag:negk,209,"partman-auto/disk=/dev/sda"
> 
> # grub/grub.cfg
> net_get_dhcp_option appends ${net_default_interface} 209 string
> 
> menuentry "Install Ubuntu preseed" {
> set gfxpayload=keep
> linux /ubuntu-installer/amd64/linux gfxpayload=800x600x16,800x600
> --- auto=true url=dc10b DEBCONF_DEBUG=5 tasks="" hostname=
> interface=${net_default_mac} ${appends}
> initrd /ubuntu-installer/amd64/initrd.gz
> }
> 
> ~ # head /var/log/syslog
> May  1 04:30:40 kernel: [0.00] Command line:
> BOOT_IMAGE=/ubuntu-installer/amd64/linux
> gfxpayload=800x600x16,800x600 --- auto=true url=dc10b
> DEBCONF_DEBUG=5 tasks= hostname= interface=00:26:9e:03:9d:e5
> partman-auto/disk=/dev/sda
> 
> 
> 
> On Fri, Apr 28, 2017 at 5:53 PM, Simon Kelley
> > wrote:
> 
> On 27/04/17 17:42, Carl Karsten wrote:
> > I am looking for the syntax of dhcp vendor options, and then how to
> > access them in grub-net.  I think.  maybe there is a better way.
> >
> > I pxe boot grub, which boots di (Debian Installer) and pass a 
> preseed file.
> >
> > I am trying to work out a nice way to pass host specific info to di
> > example, most use:
> > partman-auto/disk="/dev/sda"
> > but one machine has an onboard ssd nvme which needs /dev/nvme0n1
> >
> > di will read values appended to the kernel boot line, so I can hard 
> code
> > it like this:
> >
> > menuentry "Install Ubuntu preseed" {
> > set gfxpayload=keep
> > linux /ubuntu-installer/amd64/linux gfxpayload=800x600x16,800x600 
> ---
> > auto=true url=dc10b hostname= partman-auto/disk="/dev/nvme0n1"
> > interface=${net_default_mac}
> > initrd /ubuntu-installer/amd64/initrd.gz
> > }
> >
> > interface=${net_default_mac} - use the nic that pxe booted.
> >
> > Now I get lost in conf options and syntax.  forgive me for making 
> stuff
> > up here, if it worked I wouldn't be asking for help.
> >
> > I am hoping for something like
> > partman-auto/disk=$(net_pxe_extensionspath/disk}
> >
> > in dnsmasq conf:
> > dhcp-host=40:8d:5c:7f:bb:90,,gator
> >
> > dhcp-option-force=host:gator,209,"disk=/dev/nvme0n1"
> >
> 
> Look for "tags" in the man page, in this case, set a tag in the
> dhcp-host line (it can be the same as the hostname)
> 
> dhcp-host=40:8d:5c:7f:bb:90,set:gator,gator
> 
> 
> and make the option conditional on that tag
> 
> dhcp-option-force=tag:gator,209,"disk=/dev/nvme0n1"
> 
> >
> > So yeah, how do I send random strings based on mac/hostname
> See above
> 
> 
> > and how do I read what was sent in grub?
> 
> Set the "log-dhcp" flag in the dnsmasq configuration to get lots of
> useful information.
> 
> Cheers,
> 
> Simon.
> 
> >
> 
> 
> 
> > --
> > Carl K
> >
> >
> >
> > ___
> > 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] specifying dhcp options in proxy mode

[Andriy Gapon]

On 11/05/2017 14:36, Simon Kelley wrote:
> The design is that dnsmasq sends the options expected by a PXE client if
> it's acting as a proxy (because the whole proxy thing is part of the PXE
> spec: a normal DHCP client doesn't know how to deal with it.) The
> replies to the PXE client are constructed using the information given in
> the pxe-service and pxe-prompt options. The inclusion of arbitrary
> vendor-specific options is an oversight, I think.
> 
> As the PXE-spec doesn't AFAIK, include root-path as an expected option,
> I'm not sure that sending it will have any effect.
> 
> As stated in the thread you link to, if you're netbooting an OS via PXE
> then one the OS starts, it will do DHCP again, and that's the time to
> send arbitrary options.
> 
> TL;DR I don't think implementing what you're asking for will achieve
> what you want, but if you can demonstrate that it will, then I'll
> certainly looking at adding the extra function.

Simon,

thank you very much for reply.

My reason for wanting that feature is to support a scenario where is a main DHCP
server that is tasked only with giving out network information and which I can
not modify at all.  In my opinion options like root-path, swap-server and
similar belong to the same league as, say, bootfile-name rather than, say,
dns-server or router.  In either case, my main DHCP server is not configured to
advertise root-path.

Also, in my case it is the OS that wants to get root-path not the first stage
PXE loader.

So, without dnsmasq allowing me to send root-path option there is no way I can
give it to the OS.
I thought that the purpose of the proxy mode was exactly to help with PXE / OS
booting in situations where the main DHCP server can not be altered to do that 
job.

Having said all of the above, I should admit that the OS in question could be
non-compliant with the PXE specification.  Maybe it should use a different
mechanism like vendor options or a configuration file (advertised via
bootfile-name) to get the information it needs.

-- 
Andriy Gapon

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

Re: [Dnsmasq-discuss] dnsmasq & fingerbank.org

[Ed W]

On 09/04/2017 19:22, Denton Gentry wrote:

https://fingerbank.org/about.html is a database of OS signatures based
on the DHCP options populated and the order in which they appear. So
for example, an Android device will typically send
'1,33,3,6,15,26,28,51,58,59' while iOS sends '1,3,6,15,119,252'.

We modified dnsmasq to export DHCP OS signatures to a
DNSMASQ_REQUESTED_OPTIONS environment variable when it forks the
dhcp-script. The environment variable is formatted to match
fingerbank. The dhcp-script we run writes the signature to a separate
file, though of course this behavior is outside of dnsmasq itself.

Is OS fingerprinting support something which could be more widely useful?
Should I rebase the patch to the current tree and start discussion?


Ooh!  I would love to see this implemented!

Ed

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