Re: [Dnsmasq-discuss] [RESEND PATCH] Only bind IPv6 wildcard when it is enabled
On Thursday 21 January 2021 14:52:22 Matthias May wrote:
> On 21/01/2021 14:20, Pali Rohár wrote:
> > Hello!
> >
> > On Thursday 21 January 2021 14:00:10 Matthias May wrote:
> >> On Linux when IPv6 is disabled, one would not expect Dnsmasq to bind
> >> the IPv6 wildcard.
> >
> > And it is a problem? I would expect that if IPv6 is disabled then
> > applications (including dnsmasq) cannot bind to the IPv6 address for
> > listening... Or can applications bind to IPv6 address also when IPv6 is
> > disabled? I just have not caught what is the problem (from description).
> >
>
> Well not a problem per se, but i was quite surprised to see dnsmasq binding
> :: with IPv6 disabled.
> Yes it seems to be possible to bind :: while IPv6 is disabled.
Hello!
Now I see where is the issue. And seems that you misunderstood meaning
of the all/disable_ipv6 sysctl value.
Value of /proc/sys/net/ipv6/conf/all/disable_ipv6 can be 1 also in the
case when you have assigned IPv6 addresses and you have IPv6 sockets in
use.
You try it yourself. Call following commands:
# echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6
# echo 0 > /proc/sys/net/ipv6/conf/eth0/disable_ipv6
First command disable IPv6 on all interfaces and then second command
enable IPv6 just for eth0. Also in this state you can verify that
all/disable_ipv6 is still 1, but explicitly enabled eth0 is 0:
# cat /proc/sys/net/ipv6/conf/all/disable_ipv6
1
# cat /proc/sys/net/ipv6/conf/eth0/disable_ipv6
0
And IPv6 is working fine in this state on eth0.
So checking for /proc/sys/net/ipv6/conf/all/disable_ipv6 whether IPv6 is
enabled or disabled is incorrect.
Correct check should be really trying to opening AF_INET6 socket and
checking if bind() success on wildcard :: IPv6 address.
So your proposed patch breaks IPv6 support for machines where IPv6 is
disabled by default and enabled only for explicitly whitelisted
interfaces.
You should look at other sysfs files about IPv6 state. Probably some of
them are:
/sys/module/ipv6/parameters/disable
/sys/module/ipv6/parameters/disable_ipv6
> See the previous discussion on this list at:
> https://www.mail-archive.com/dnsmasq-discuss@lists.thekelleys.org.uk/msg14032.html
>
> >> This patch adds a condition to the wildcard bind function, which checks
> >> on Linux if IPv6 is disabled.
> >>
> >> Signed-off-by: Matthias May
> >> Signed-off-by: Zefir Kurtisi
> >> ---
> >> src/dnsmasq.h | 1 +
> >> src/network.c | 24 +---
> >> src/util.c| 22 ++
> >> 3 files changed, 36 insertions(+), 11 deletions(-)
> >>
> >> diff --git a/src/dnsmasq.h b/src/dnsmasq.h
> >> index 4220798..2cfb1cb 100644
> >> --- a/src/dnsmasq.h
> >> +++ b/src/dnsmasq.h
> >> @@ -1292,6 +1292,7 @@ int read_write(int fd, unsigned char *packet, int
> >> size, int rw);
> >> void close_fds(long max_fd, int spare1, int spare2, int spare3);
> >> int wildcard_match(const char* wildcard, const char* match);
> >> int wildcard_matchn(const char* wildcard, const char* match, int num);
> >> +int is_ipv6_disabled(void);
> >> #ifdef HAVE_LINUX_NETWORK
> >> int kernel_version(void);
> >> #endif
> >> diff --git a/src/network.c b/src/network.c
> >> index c7d002b..0d35fb7 100644
> >> --- a/src/network.c
> >> +++ b/src/network.c
> >> @@ -990,19 +990,21 @@ void create_wildcard_listeners(void)
> >>
> >>l = create_listeners(, !!option_bool(OPT_TFTP), 1);
> >>
> >> - memset(, 0, sizeof(addr));
> >> + if (!is_ipv6_disabled()) {
> >> +memset(, 0, sizeof(addr));
> >> #ifdef HAVE_SOCKADDR_SA_LEN
> >> - addr.in6.sin6_len = sizeof(addr.in6);
> >> +addr.in6.sin6_len = sizeof(addr.in6);
> >> #endif
> >> - addr.in6.sin6_family = AF_INET6;
> >> - addr.in6.sin6_addr = in6addr_any;
> >> - addr.in6.sin6_port = htons(daemon->port);
> >> -
> >> - l6 = create_listeners(, !!option_bool(OPT_TFTP), 1);
> >> - if (l)
> >> -l->next = l6;
> >> - else
> >> -l = l6;
> >> +addr.in6.sin6_family = AF_INET6;
> >> +addr.in6.sin6_addr = in6addr_any;
> >> +addr.in6.sin6_port = htons(daemon->port);
> >> +
> >> +l6 = create_listeners(, !!option_bool(OPT_TFTP), 1);
> >> +if (l)
> >> + l->next = l6;
> >> +else
> >> + l = l6;
> >> + }
> >>
> >>daemon->listeners = l;
> >> }
> >> diff --git a/src/util.c b/src/uti
Re: [Dnsmasq-discuss] [RESEND PATCH] Only bind IPv6 wildcard when it is enabled
Hello!
On Thursday 21 January 2021 14:00:10 Matthias May wrote:
> On Linux when IPv6 is disabled, one would not expect Dnsmasq to bind
> the IPv6 wildcard.
And it is a problem? I would expect that if IPv6 is disabled then
applications (including dnsmasq) cannot bind to the IPv6 address for
listening... Or can applications bind to IPv6 address also when IPv6 is
disabled? I just have not caught what is the problem (from description).
> This patch adds a condition to the wildcard bind function, which checks
> on Linux if IPv6 is disabled.
>
> Signed-off-by: Matthias May
> Signed-off-by: Zefir Kurtisi
> ---
> src/dnsmasq.h | 1 +
> src/network.c | 24 +---
> src/util.c| 22 ++
> 3 files changed, 36 insertions(+), 11 deletions(-)
>
> diff --git a/src/dnsmasq.h b/src/dnsmasq.h
> index 4220798..2cfb1cb 100644
> --- a/src/dnsmasq.h
> +++ b/src/dnsmasq.h
> @@ -1292,6 +1292,7 @@ int read_write(int fd, unsigned char *packet, int size,
> int rw);
> void close_fds(long max_fd, int spare1, int spare2, int spare3);
> int wildcard_match(const char* wildcard, const char* match);
> int wildcard_matchn(const char* wildcard, const char* match, int num);
> +int is_ipv6_disabled(void);
> #ifdef HAVE_LINUX_NETWORK
> int kernel_version(void);
> #endif
> diff --git a/src/network.c b/src/network.c
> index c7d002b..0d35fb7 100644
> --- a/src/network.c
> +++ b/src/network.c
> @@ -990,19 +990,21 @@ void create_wildcard_listeners(void)
>
>l = create_listeners(, !!option_bool(OPT_TFTP), 1);
>
> - memset(, 0, sizeof(addr));
> + if (!is_ipv6_disabled()) {
> +memset(, 0, sizeof(addr));
> #ifdef HAVE_SOCKADDR_SA_LEN
> - addr.in6.sin6_len = sizeof(addr.in6);
> +addr.in6.sin6_len = sizeof(addr.in6);
> #endif
> - addr.in6.sin6_family = AF_INET6;
> - addr.in6.sin6_addr = in6addr_any;
> - addr.in6.sin6_port = htons(daemon->port);
> -
> - l6 = create_listeners(, !!option_bool(OPT_TFTP), 1);
> - if (l)
> -l->next = l6;
> - else
> -l = l6;
> +addr.in6.sin6_family = AF_INET6;
> +addr.in6.sin6_addr = in6addr_any;
> +addr.in6.sin6_port = htons(daemon->port);
> +
> +l6 = create_listeners(, !!option_bool(OPT_TFTP), 1);
> +if (l)
> + l->next = l6;
> +else
> + l = l6;
> + }
>
>daemon->listeners = l;
> }
> diff --git a/src/util.c b/src/util.c
> index 5f13027..5cd461f 100644
> --- a/src/util.c
> +++ b/src/util.c
> @@ -787,6 +787,28 @@ int wildcard_matchn(const char* wildcard, const char*
> match, int num)
>return (!num) || (*wildcard == *match);
> }
>
> +#ifndef HAVE_LINUX_NETWORK
> +/* implement for other platforms */
> +int is_ipv6_disabled(void)
> +{
> + return 0;
> +}
> +#else /* HAVE_LINUX_NETWORK */
> +int is_ipv6_disabled(void)
> +{
> + FILE *f;
> + char *fname = "/proc/sys/net/ipv6/conf/all/disable_ipv6";
> + char buf[4];
> + int ipv6_disabled = 0;
> + if ((f = fopen(fname, "r"))) {
> + if (fgets(buf, 4, f))
> + ipv6_disabled = atoi(buf) == 1;
> + fclose(f);
> + }
> + return ipv6_disabled;
This check is incorrect. If IPv6 support is disabled at kernel compile
time then fopen() fails and this function returns 0, meaning IPv6 is
enabled.
> +}
> +#endif /* HAVE_LINUX_NETWORK */
> +
> #ifdef HAVE_LINUX_NETWORK
> int kernel_version(void)
> {
> --
> 2.27.0
>
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
--
Pali Rohár
pali.ro...@gmail.com
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] How to contact Simon Kelley
On Monday 28 September 2020 13:59:04 Riccardo Schirone wrote: > Hello, > > I'm trying to reach out to Simon Kelley about dnsmasq, however he is not > answering direct emails and he has not been active on this list for few months > now. > > Does anybody have a way to contact him or know anything about him? Could you > ping him if you have other means to reach him apart from public email? > > Thank you, Well, I have tried to contact Simon for two years via this mailing list and also via private email about one patch and he has not responded yet. So I suspect that some emails are going into his spambox or that he does not want to discuss... -- Pali Rohár pali.ro...@gmail.com ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [PATCH v2] DHCPv6: Honor assigning IPv6 address based on MAC address
On Thursday 23 July 2020 13:11:36 Move On wrote: > On Thu, Jul 23, 2020 at 10:35:45AM +0200, Pali Rohár wrote: > > So finally something relevant to this patch... > > Cheer \o/ > > > On Wednesday 22 July 2020 23:48:19 Petr Menšík wrote: > > > On 7/22/20 3:44 PM, Pali Rohár wrote: > > > > I do not see any benefit why to complicate things just because "IPv6 > > > > addresses are many". I do not see nothing wrong on simple setup where > > > > device has one IPv6 address assigned by DHCPv6 server. > > > I think you are requesting breaking of DHCP definition RFCs. I see > > > nothing wrong with IPv6 assigned to MAC address. I think it is wrong, if > > > there are existing leases for the same address with different IAID. > > > > The whole point of this patch is to make MAC --> IPv6 address assigning > > working. It means that IPv6 address must be leased to MAC address if > > assigning is based on MAC address and not on DUID/IAID. > > > > If user set in configure file that for MAC address AB:CD:EF:AB:CD:EF > > must be assigned IPv6 address FD::1 then user would expect that host > > with address AB:CD:EF:AB:CD:EF would get IPv6 address FD::1. > > > > Why host get different address, then why such option is even provided? > > > > User already express by this configuration that he is interested in such > > setup even if it does not have to be compliant with standards. > > > > Some people are saying that assigning IPv6 address based on MAC address > > is already violation of DHCPv6 RFC. > > > > Also dnsmasq provides support for leasing one IPv4 address to more MAC > > addresses. This is often used when computer has both ethernet and wifi > > interfaces and only one is used at the same time. dnsmasq then lease > > IPv4 address to the last MAC address which asked for it. This feature > > also violates DHCPv4 standard, but it is there as it is useful for lot > > of people. > > > > So why should be similar useful feature problematic for IPv6 when it is > > already provided for IPv4 in dnsmasq? > > > > > > Anyway, if violation of DHCPv6 RFC standard with this setup of leasing > > IPv6 address to MAC address statically is problematic, what about adding > > a new option which enables this behavior? > > > > Provide PATCH v3 and see what happens So, this is the only thing which needs to be fixed and after patch would be merged? -- Pali Rohár pali.ro...@gmail.com ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [PATCH v2] DHCPv6: Honor assigning IPv6 address based on MAC address
On Thursday 23 July 2020 19:03:41 Kevin 'ldir' Darbyshire-Bryant wrote: > > On 23 Jul 2020, at 14:11, Pali Rohár wrote: > > > > > > > Hello Kevin! So you basically have similar/same feature request. > > > > Could you test this dnsmasq patch if it helps with your setup? > > > > -- > > Pali Rohár > > pali.ro...@gmail.com > > I have successfully used prior incarnations of your patch. Great! So patch was already tested that is working and it is useful. > Recently I haven’t required it but I am not sure if this is because qnap have > improved something OR simply because I don’t reboot the boxes anywhere near > as often. I’ll see if I can provoke the problem over the next few days but I > am quite busy at the moment. Fixing the issue when the problem arises is a > real pain in the arse involving qnap shutdown, dnsmasq shutdown, edit > leasefile & remove the rogue leases, restart dnsmasq, restart qnap. I understand it, assigning IPv6 address based on MAC address is in dnsmasq currently unusable and removing lease file with dnsmasq restart is the only workaround which I know. I think that patch in current form is enough. -- Pali Rohár pali.ro...@gmail.com ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Tag requests for a DHCP address from devices using a Locally Administered MAC address
On Sunday 26 July 2020 15:35:24 Geert Stappers wrote: > On Sun, Jul 26, 2020 at 06:07:52AM -0700, d...@lutean.com wrote: > > > > iOS 14 > > > > > > CISCO provides an IOS, https://en.wikipedia.org/wiki/Cisco_IOS > > > My second guess on IOS is an Apple Computer Inc product. > > > > > > > > > > will by default use randomized, private MAC addresses. > > > > > > Yeah right, let's sell a depleted MAC address pool > > > as a privacy improvement ... > > > > > > > It is an upcoming feature of Apple products that will be on > > by default: https://support.apple.com/en-ca/HT211227 Ah :-( So Apple devices would be broken on lot of networks. Another reason why to not buy them. I heard from lot of people that they are not supporting Apple devices on networks anymore and I now I'm seeing reasons for such decisions. Maintaining such crap must be really pain. > > It is already available through the public beta. > > > > So Apple devices as of October or sooner will be > > changing their MAC addresses by default > > > > > > > > > In my testing these devices use a MAC address with the LAA bit set > > > > (2nd least significant bit of the first byte of the MAC). It restricts > > > > this to host addresses (least significant bit is set to 0). > > > > > > Speaks about two bits > > > > > > > > > > This patch detects MAC addresses with this bit set and tags the request > > > > with > > > > the tag "laa-address". This would allow other rules to decide what to do > > > > with these requests (such as ignoring them). > > > > > > Speaks about one bit > > > > > > > > > > > > Speaking about bits, see > > https://en.wikipedia.org/wiki/MAC_address#/media/File:MAC-48_Address.svg > > > for the "exploded view" > > > > > > > https://en.wikipedia.org/wiki/MAC_address#Unicast_vs._multicast > > > > The reason two bits are tested is because: > > - one bit is the UAA / LAA bit > > - one bit is the unicast / multicast bit > > > > so this patch wouldn't tag LAA multicast MAC addresses should > > those happen to be in use somewhere. > > > > So specifically a device with an LAA unicast MAC address > > would get a tag. This requires testing two bits. > > > > OK, thanks for elaborating I think that big misunderstanding comes from commit message which says that one bit (LAA) is tested, but in patch itself are tested two bits. I guess that fixing commit message to properly describe that testing both bits (and which) are needed should be enough. Anyway, I'm not sure if 'laa-address' is correct name if it is not set for every laa-address, but only for unicast laa-address. -- Pali Rohár pali.ro...@gmail.com ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [PATCH v2] DHCPv6: Honor assigning IPv6 address based on MAC address
On Thursday 23 July 2020 12:43:03 Kevin 'ldir' Darbyshire-Bryant wrote: > > On 23 Jul 2020, at 09:35, Pali Rohár wrote: > > > > So finally something relevant to this patch... > > > > On Wednesday 22 July 2020 23:48:19 Petr Menšík wrote: > >> On 7/22/20 3:44 PM, Pali Rohár wrote: > >>> I do not see any benefit why to complicate things just because "IPv6 > >>> addresses are many". I do not see nothing wrong on simple setup where > >>> device has one IPv6 address assigned by DHCPv6 server. > >> I think you are requesting breaking of DHCP definition RFCs. I see > >> nothing wrong with IPv6 assigned to MAC address. I think it is wrong, if > >> there are existing leases for the same address with different IAID. > > > > The whole point of this patch is to make MAC --> IPv6 address assigning > > working. It means that IPv6 address must be leased to MAC address if > > assigning is based on MAC address and not on DUID/IAID. > > > > If user set in configure file that for MAC address AB:CD:EF:AB:CD:EF > > must be assigned IPv6 address FD::1 then user would expect that host > > with address AB:CD:EF:AB:CD:EF would get IPv6 address FD::1. > > > If I may proffer this real life use case/scenario as found in my very own > home: > > I have a couple of Qnap NAS boxes. They speak legacy IP and IPv6. These > boxes sometimes offer services such as bittorrent to the Internet. They live > behind an Openwrt router/firewall, the very device that runs dnsmasq offering > DHCPv4/v6 leases. For purposes of my own sanity I lock the IPv4 address to > the qnap devices MAC addresses, thus I can enter unchanging and consistent > entries in the firewall for relevant hosts/ports. I have an identical > requirement for IPv6. I need to be sure that these Qnap devices will land at > a known, consistent, effectively static IPv4/v6 address. > > The IPv4 case is easily solved and supported. The IPv6 case (until > recently..qnap changed something..and I don’t reboot as much) was more > challenging in that dnsmasq ignores the MAC address. The DUID/IAID would > change at different stages of the boot, leading to dnsmasq thinking the > address requested was being requested for a new client as opposed to the same > client simply rebooting. > > There is a use case for locking/mapping IPv6 to MAC address whether it > violates RFCs or not. For reasons of firewall pinholes I need certain > machines to land at certain addresses. For ‘fun’ we can discuss if this is a > problem with/for upnp/natpnp Hello Kevin! So you basically have similar/same feature request. Could you test this dnsmasq patch if it helps with your setup? -- Pali Rohár pali.ro...@gmail.com ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [PATCH v2] DHCPv6: Honor assigning IPv6 address based on MAC address
So finally something relevant to this patch... On Wednesday 22 July 2020 23:48:19 Petr Menšík wrote: > On 7/22/20 3:44 PM, Pali Rohár wrote: > > I do not see any benefit why to complicate things just because "IPv6 > > addresses are many". I do not see nothing wrong on simple setup where > > device has one IPv6 address assigned by DHCPv6 server. > I think you are requesting breaking of DHCP definition RFCs. I see > nothing wrong with IPv6 assigned to MAC address. I think it is wrong, if > there are existing leases for the same address with different IAID. The whole point of this patch is to make MAC --> IPv6 address assigning working. It means that IPv6 address must be leased to MAC address if assigning is based on MAC address and not on DUID/IAID. If user set in configure file that for MAC address AB:CD:EF:AB:CD:EF must be assigned IPv6 address FD::1 then user would expect that host with address AB:CD:EF:AB:CD:EF would get IPv6 address FD::1. Why host get different address, then why such option is even provided? User already express by this configuration that he is interested in such setup even if it does not have to be compliant with standards. Some people are saying that assigning IPv6 address based on MAC address is already violation of DHCPv6 RFC. Also dnsmasq provides support for leasing one IPv4 address to more MAC addresses. This is often used when computer has both ethernet and wifi interfaces and only one is used at the same time. dnsmasq then lease IPv4 address to the last MAC address which asked for it. This feature also violates DHCPv4 standard, but it is there as it is useful for lot of people. So why should be similar useful feature problematic for IPv6 when it is already provided for IPv4 in dnsmasq? Anyway, if violation of DHCPv6 RFC standard with this setup of leasing IPv6 address to MAC address statically is problematic, what about adding a new option which enables this behavior? -- Pali Rohár pali.ro...@gmail.com ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] DHCPv6 without DNS (Was: Re: [PATCH v2] DHCPv6: Honor assigning IPv6 address based on MAC address)
On Wednesday 22 July 2020 23:48:19 Petr Menšík wrote: > On 7/22/20 3:44 PM, Pali Rohár wrote: > > Hello Petr! > > > > On Wednesday 22 July 2020 14:42:16 Petr Menšík wrote: > >> More below... > >> > >> On 7/22/20 9:40 AM, Pali Rohár wrote: > >>> Hello Petr! > >>> > >>> On Tuesday 21 July 2020 14:23:51 Petr Menšík wrote: > >>>> I think more correct would be using the same DUID on both systems. > >>> > >>> Problem is that DUID generation is under control of operating system and > >>> during installation of operating system, every one generates its own. It > >>> is not under user control (at this stage of setup) or under "hw" control > >>> (like for MAC address in IPv4 where operating system read MAC address > >>> from HW). > >>> > >>> Also this is unsuitable in environment where MAC address should be > >>> assigned to network card "by law". Or in environment where must be 1:1 > >>> mapping between assigned IPv4 and IPv6 address. > >> > >> Could you explain a situation, why 1:1 mapping is required? Why 1:4 > >> mapping would not work? > > > > What do you mean by 1:4 mapping? And why 4? That device would always > > have one IPv4 address and randomly chosen IPv6 address from 4 member > > set? > Because it would be likely enough for normal host, even if it uses PXE > on boot. Yes, it would have always one from those 4. This is again fragile. It expects that there would not be more then 4 installation of OS on same host. > > This looks like complication. The point of DHCPv6 is that I could assign > > one address, not random address from 4 member IPv6 set. > One from predefined set is not random address. So in the end, in the worst case I need to set N addresses. So result is same as random. > > I really do not want to try 4 addresses until I figure out which one is > > working. This is insane. > Are you typing IPv6 addresses? How? What commands use them? Try DNS. Thank you, but this is about DHCPv6. I'm started feeling like in market place where I'm getting tons of products for which I did not asked. > It > has support for multiple addresses on single name. Sane software would > try all of them until it succeeds. We are not in ideal world where all software is sane, free of bugs and works like charm. > >> They are different protocols. IPv6 supports > >> multiple addresses from the start. Because they make several maintenance > >> actions a lot simpler. Why do you insist there must be only one address? > > > > And why I have to use multiple IPv6 addresses? I want to have service on > > specific/chosen IPv6 address. Not random. > How often do your machines change running operating system, with IAID > change? Excluding changes during netboot. Randomly. If I take e.g. home local network then every reboot with Windows machine disconnected from network can generate new IAID. No, I do not want to debug Windows bugs. > >> You can use SLAAC for MAC generated addresses and they would be the same > >> regardless running OS. > > > > SLAAC cannot be used anymore for this purpose as operating systems do > > not use MAC address for generating SLAAC address. Both Windows systems > > and NetworkManager systems generates randomized SLAAC address by > > default. IIRC Android is doing it too. > Good. Maybe there is a reason behind it. Reason is privacy, to not expose MAC address to world. If MAC address is directly included in IPv6 address then servers can track computers if they connect from different networks. But if IPv6 address does not contain MAC address then it is OK. And reason why to use DHCPv6 where admin should have control how to assign IPv6 address. > If you used hardware address to > identify them instead of manually reserved IP address, it would work > also with them. > > > >>> > >>> If I have to configure every one machine on network and every one > >>> operating system on that machine, then I do not have to use DHCPv6 and I > >>> would assign all addresses statically. > >>> > >>> The point of usage DHCPv6 here is ability to configure network > >>> automatically without need to re-configure network stack on operating > >>> system. > >> It is possible to configure them on network. > > > > Well, as I said, if I had to configure network stack on every IPv6 > > connected computer and on every operating system on that computer then I > > can set static IPv6 address. And do not see to deal with DUIDs and IADs. > > >
[Dnsmasq-discuss] MSFT: DHCPRELEASE on shutdown (Was: Re: [PATCH v2] DHCPv6: Honor assigning IPv6 address based on MAC address)
On Wednesday 22 July 2020 15:35:33 Petr Menšík wrote: > Btw, found windows allows releasing of leases to be configured from DHCP > server. I doubt similar option is accepted on ISC DHCP client. > NetworkManager probably does not implement such thing. > > This should help you avoiding conflicts between multiple instances in a > different way. Never used it, not sure whether it does work. > > Some customization might be necessary on Linux distribution. > > 1. > https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-dhcpe/4cde5ceb-4fc1-4f9a-82e9-13f6b38d930c I know about this option and I'm already using it in dsnmasq: --dhcp-option=vendor:MSFT,2,1i Problem is that this option is for DHCPv4 MS clients. Does not work for MS DHCPv6 clients. Also it is not reliable, e.g. when network is disconnected. And dnsmasq has working MAC <--> IPv4 address assignment so it is not needed at all. -- Pali Rohár pali.ro...@gmail.com ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [PATCH v2] DHCPv6: Honor assigning IPv6 address based on MAC address
Hello Petr! On Wednesday 22 July 2020 14:42:16 Petr Menšík wrote: > More below... > > On 7/22/20 9:40 AM, Pali Rohár wrote: > > Hello Petr! > > > > On Tuesday 21 July 2020 14:23:51 Petr Menšík wrote: > >> I think more correct would be using the same DUID on both systems. > > > > Problem is that DUID generation is under control of operating system and > > during installation of operating system, every one generates its own. It > > is not under user control (at this stage of setup) or under "hw" control > > (like for MAC address in IPv4 where operating system read MAC address > > from HW). > > > > Also this is unsuitable in environment where MAC address should be > > assigned to network card "by law". Or in environment where must be 1:1 > > mapping between assigned IPv4 and IPv6 address. > > Could you explain a situation, why 1:1 mapping is required? Why 1:4 > mapping would not work? What do you mean by 1:4 mapping? And why 4? That device would always have one IPv4 address and randomly chosen IPv6 address from 4 member set? This looks like complication. The point of DHCPv6 is that I could assign one address, not random address from 4 member IPv6 set. I really do not want to try 4 addresses until I figure out which one is working. This is insane. > They are different protocols. IPv6 supports > multiple addresses from the start. Because they make several maintenance > actions a lot simpler. Why do you insist there must be only one address? And why I have to use multiple IPv6 addresses? I want to have service on specific/chosen IPv6 address. Not random. > You can use SLAAC for MAC generated addresses and they would be the same > regardless running OS. SLAAC cannot be used anymore for this purpose as operating systems do not use MAC address for generating SLAAC address. Both Windows systems and NetworkManager systems generates randomized SLAAC address by default. IIRC Android is doing it too. > > > > If I have to configure every one machine on network and every one > > operating system on that machine, then I do not have to use DHCPv6 and I > > would assign all addresses statically. > > > > The point of usage DHCPv6 here is ability to configure network > > automatically without need to re-configure network stack on operating > > system. > It is possible to configure them on network. Well, as I said, if I had to configure network stack on every IPv6 connected computer and on every operating system on that computer then I can set static IPv6 address. And do not see to deal with DUIDs and IADs. The point of usage DHCPv6 is to automatize assignment of IPv6 addresses without need to do configuration of target systems. Like in IPv4 setup. Moreover, it is not possible to configure DUIDs on every system. E.g. Intel's PXE implementation burned into PC ROM does not allow to set DUID or IAID in firmware/setup screen. > It is not possible to > ignore conflicting IDs. It would work well if host OS releases assigned > leases before shutdown. Some OSes do not do it. Different closed source / burned systems (including PXE) even cannot be workarounded / fixed. And still this does not work if you disconnected ethernet cable before doing OS shutdown and connecting if after new bootup. > If they are still leased, they should not be > assigned to conflicting ids. Is it possible to make sure they release > the lease on shutdown/reboot? In case of network disconnect such thing is not obviously possible. And expecting that there is no network disconnect during leased IPv6 address is wrong. Moreover, in static MAC <--> IPv6 setup I expect that IPv6 address is assigned (leased) to MAC address. Otherwise, what other use case could be for static MAC <--> IPv6 configuration setup? > > > >> There is already another option to make this working. It is possible > >> assigning IPv6 prefix or multiple addresses. dhcp-host can provide > >> multiple addresses to single mac > > > > Assigning IPv6 address based on mac address is broken as I pointed in > > this patch. So such setup would not work. > > > > Anyway, my point is not to assign multiple addresses to single MAC > > address, but rather to ensure that for one MAC address would be assigned > > always only one specific MAC address. And not more. > But you need dnsmasq to ignore conflicts between addresses. While > existing solution allows to predefine addresses to static host entry. It > would always gen one of those addresses in case of conflict. It seems > more elegant and more correct fix to me. You haven't stated why do you > need just a single address for conflicting DUID. Just to note that dnsmasq assign address to IAID, not to DUID. Same problem ha
Re: [Dnsmasq-discuss] [PATCH v2] DHCPv6: Honor assigning IPv6 address based on MAC address
Hello Petr! On Tuesday 21 July 2020 14:23:51 Petr Menšík wrote: > I think more correct would be using the same DUID on both systems. Problem is that DUID generation is under control of operating system and during installation of operating system, every one generates its own. It is not under user control (at this stage of setup) or under "hw" control (like for MAC address in IPv4 where operating system read MAC address from HW). Also this is unsuitable in environment where MAC address should be assigned to network card "by law". Or in environment where must be 1:1 mapping between assigned IPv4 and IPv6 address. If I have to configure every one machine on network and every one operating system on that machine, then I do not have to use DHCPv6 and I would assign all addresses statically. The point of usage DHCPv6 here is ability to configure network automatically without need to re-configure network stack on operating system. > There is already another option to make this working. It is possible > assigning IPv6 prefix or multiple addresses. dhcp-host can provide > multiple addresses to single mac Assigning IPv6 address based on mac address is broken as I pointed in this patch. So such setup would not work. Anyway, my point is not to assign multiple addresses to single MAC address, but rather to ensure that for one MAC address would be assigned always only one specific MAC address. And not more. > which works with different DUID quite > well. It still has different addresses, but with the same base. > > taken from manual page: > --dhcp-host=laptop,[1234:50/126] > > Why isn't this sufficient? > > On 5/26/20 10:52 AM, Pali Rohár wrote: > > On Thursday 21 May 2020 16:22:03 Geert Stappers wrote: > >> On Sun, May 03, 2020 at 01:23:15PM +0200, 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 > >> > >> How to reproduce that semi-brokenness? > > > > Take computer with Windows/Linux dual boot systems. > > > > Configure MAC-based static IPv6 entry for that computer in dnsmasq and > > set big enough lease time (e.g. day or more). > > > > Boot computer into Windows and wait until dnsmasq assign it IPv6 > > address. It should match MAC-based entry in dnsmasq. Then reboot > > computer into Linux system and again wait until it got assigned IPv6 > > address. > > > > Normally it should get again same IPv6 address as it was assigned on > > Windows, due to MAC-based static IPv6 entry in dnsmasq. > > > > But in reality that static entry is ignored by dnsmasq and rather some > > "random" address is assigned. > > > > So assigning IPv6 addresses based on static MAC address in dnsmasq is > > broken. > > > > You can reproduce it not only with Windows/Linux, but with any two > > DHCPv6 clients which use different IAID/DUID. E.g. PXE DHCPv6 client > > (for network booting) and Linux DHCPv6 client. > > > > dnsmasq without this patch refuse to assign MAC-based IPv6 static > > address to computer with that MAC address, if that IPv6 address is still > > leased to DHCPv6 client with different IAID. > > > > In my above example/reproducer, IPv6 address was leased to Windows > > DHCPv6 client and therefore dnsmasq refused to assign it to Linux DHCPv6 > > client, which in most cases have different IAID. Even both clients > > (Windows and Linux) are on the same computer with same MAC address, > > which matches MAC address in dnsmasq configuration file. > > > > That is why I called IPv6 address assignment according to MAC address as > > "semi-brokenness". > > > >> > >>> 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 f
Re: [Dnsmasq-discuss] Fwd: [PATCH] Makefile: make variables overridable
On Sunday 12 July 2020 17:40:56 John Ericson wrote: > On Sun, Jul 12, 2020, at 5:22 PM, Pali Rohár wrote: > > > > But why is this change needed at all? Are there some bugs in GNU make so > > that macros/variables initialized by '=' cannot be overridden and > > initialization with '?=' is fixing those bugs? > > Definitions with = can still be overridden on the command line, but won't be > overridden by environment variables alone. The PKG_CONFIG change would just > be to avoid extra make flags. Ok, so you wanted to automatically override all those variables without specifying them as arguments to make process. Yes, this not working in classic make as for make it is expected that caller explicitly supply what wants to override. I asked about GNU make bugs because I already hit 3 different bugs in this make software which caused that variables were not correctly set or propagated. So I though that you found another related to = and ?=. -- Pali Rohár pali.ro...@gmail.com ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Fwd: [PATCH] Makefile: make variables overridable
On Sunday 12 July 2020 22:19:42 Geert Stappers wrote: > On Sun, Jul 12, 2020 at 09:05:17PM +0200, Pali Rohár wrote: > > On Sunday 12 July 2020 13:53:11 John Ericson wrote: > > > Hi, I am another NixOS maintainer. > > > > > > Yes, it is true that ?= in makefiles is somewhat rare, and that we > > > can work around this other ways. But it was I who proposed the ?= > > > change on our side, so let say why I think it's the right choice: > > > > > > Most C packages don't use "?=" and do > > > FOO ?= foo > > > but instead do have a configure script, so they do > > > FOO = @FOO@ > > > with regular "=". However that configure script *does* silently > > > consume environment variables, so the effect is the same. > > > > "FOO ?= foo" syntax is not supported by POSIX make: > > https://pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html > > > > And requires some GNU Make extension. > > > > I guess because dnsmasq is supported also on non-GNU Make systems, it > > cannot take some patch which adds dependency on Linux or GNU specific > > feature. > > I rather hope that dnsmasq is considered usefull in worlds outside > the Linux and GNU world. > > > > > I wouldn't request upstream add a configure script is nothing > > > is needed, and I don't even like the implicitness of environment > > > variables myself. But the fact is it is the standard for distros > > > to communicate information to all the myriad build systems, > > > so I advocate this change so distros can remove extra packaging hacks. > > > > > > The variable we need to override is PKG_CONFIG. > > > > Basically I do not understand whole point of this patch. If you for > > compilation need to override some Makefile variable, why do you not > > set correct value of that variable? > > > > It is lot of easier to set correct value during compilation as patching > > sources or sending patch to upstream and waiting if it would be released > > in new version. > > I have prepared a patch which only changes the PKG_CONFIG > and does have explaination[1] in the commit message. But why is this change needed at all? Are there some bugs in GNU make so that macros/variables initialized by '=' cannot be overridden and initialization with '?=' is fixing those bugs? -- Pali Rohár pali.ro...@gmail.com ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Fwd: [PATCH] Makefile: make variables overridable
On Sunday 12 July 2020 13:53:11 John Ericson wrote: > Hi, I am another NixOS maintainer. > > Yes, it is true that ?= in makefiles is somewhat rare, and that we can work > around this other ways. But it was I who proposed the ?= change on our > side[1], so let say why I think it's the right choice: > > Most C packages don't use "?=" and do > FOO ?= foo > but instead do have a configure script, so they do > FOO = @FOO@ > with regular "=". However that configure script *does* silently consume > environment variables, so the effect is the same. "FOO ?= foo" syntax is not supported by POSIX make: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html And requires some GNU Make extension. I guess because dnsmasq is supported also on non-GNU Make systems, it cannot take some patch which adds dependency on Linux or GNU specific feature. > I wouldn't request upstream add a configure script is nothing is needed, and > I don't even like the implicitness of environment variables myself. But the > fact is it is the standard for distros to communicate information to all the > myriad build systems[2], so I advocate this change so distros can remove > extra packaging hacks. > > The variable we need to override is PKG_CONFIG. Basically I do not understand whole point of this patch. If you for compilation need to override some Makefile variable, why do you not set correct value of that variable? It is lot of easier to set correct value during compilation as patching sources or sending patch to upstream and waiting if it would be released in new version. > P.S. Sorry I am missing the right "in-reply-to"; I turned on message delivery > after the original emails were sent, and do not know how to get the > message-id from the pipermail archive. You can find Message-Id of every email in GZIP archive available at: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/ -- Pali Rohár pali.ro...@gmail.com ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [PATCH v2] DHCPv6: Honor assigning IPv6 address based on MAC address
On Tuesday 26 May 2020 10:52:05 Pali Rohár wrote: > On Thursday 21 May 2020 16:22:03 Geert Stappers wrote: > > On Sun, May 03, 2020 at 01:23:15PM +0200, 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. > > > > How to reproduce that semi-brokenness? > > Take computer with Windows/Linux dual boot systems. > > Configure MAC-based static IPv6 entry for that computer in dnsmasq and > set big enough lease time (e.g. day or more). > > Boot computer into Windows and wait until dnsmasq assign it IPv6 > address. It should match MAC-based entry in dnsmasq. Then reboot > computer into Linux system and again wait until it got assigned IPv6 > address. > > Normally it should get again same IPv6 address as it was assigned on > Windows, due to MAC-based static IPv6 entry in dnsmasq. > > But in reality that static entry is ignored by dnsmasq and rather some > "random" address is assigned. > > So assigning IPv6 addresses based on static MAC address in dnsmasq is > broken. > > You can reproduce it not only with Windows/Linux, but with any two > DHCPv6 clients which use different IAID/DUID. E.g. PXE DHCPv6 client > (for network booting) and Linux DHCPv6 client. > > dnsmasq without this patch refuse to assign MAC-based IPv6 static > address to computer with that MAC address, if that IPv6 address is still > leased to DHCPv6 client with different IAID. > > In my above example/reproducer, IPv6 address was leased to Windows > DHCPv6 client and therefore dnsmasq refused to assign it to Linux DHCPv6 > client, which in most cases have different IAID. Even both clients > (Windows and Linux) are on the same computer with same MAC address, > which matches MAC address in dnsmasq configuration file. > > That is why I called IPv6 address assignment according to MAC address as > "semi-brokenness". > > > > > > 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. > > > --- > > > > > > This is my original patch rebased on top of current git master branch. > > > > Acknowledge > > > > > > > Previous email with this patch probably dropped into spambox > > > and was not processed. > > > > (unspoken words + > > > > http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2020q2/014018.html > > ) I'm not sure if this is that case... because Simon reacted to other patch emails. This really looks like that patch email was dropped into spambox. Simon, if you are reading this email / patch could you react if you have received this email? Or if it was dropped into spambox? > > > > > So please let me know if now this email was correctly received. > > > > Recieved the patch and was able to `git am` it. > > It did compile and passed the unittests. > > > > No further check was done. Mostly because not facing the problem that > > patch submitter has. Probably some day I will, hence the above 'How to > > reproduce that semi-brokenness?' > > > > > > > src/rfc3315.c | 55 +++ > > > 1 file changed, 47 insertions(+), 8 deletions(-) > > > > > > diff --git a/src/rfc3315.c b/src/rfc3315.c > > > index b3f0a0a..e588b13 100644 > > > --- a/src/rfc3315.c > > > +++ b/src/rfc3315.c > > ... 142 lines of actual patch ... > > > > > > Groeten > > Geert Stappers > > -- > > Silence is hard to parse > > > > ___ > > Dnsmasq-discuss mailing list > > Dnsmasq-discuss@lists.thekelleys.org.uk > > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > > -- > Pali Rohár > pali.ro...@gmail.com -- Pali Rohár pali.ro...@gmail.com ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [PATCH v2] DHCPv6: Honor assigning IPv6 address based on MAC address
On Thursday 21 May 2020 16:22:03 Geert Stappers wrote: > On Sun, May 03, 2020 at 01:23:15PM +0200, 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. > > How to reproduce that semi-brokenness? Take computer with Windows/Linux dual boot systems. Configure MAC-based static IPv6 entry for that computer in dnsmasq and set big enough lease time (e.g. day or more). Boot computer into Windows and wait until dnsmasq assign it IPv6 address. It should match MAC-based entry in dnsmasq. Then reboot computer into Linux system and again wait until it got assigned IPv6 address. Normally it should get again same IPv6 address as it was assigned on Windows, due to MAC-based static IPv6 entry in dnsmasq. But in reality that static entry is ignored by dnsmasq and rather some "random" address is assigned. So assigning IPv6 addresses based on static MAC address in dnsmasq is broken. You can reproduce it not only with Windows/Linux, but with any two DHCPv6 clients which use different IAID/DUID. E.g. PXE DHCPv6 client (for network booting) and Linux DHCPv6 client. dnsmasq without this patch refuse to assign MAC-based IPv6 static address to computer with that MAC address, if that IPv6 address is still leased to DHCPv6 client with different IAID. In my above example/reproducer, IPv6 address was leased to Windows DHCPv6 client and therefore dnsmasq refused to assign it to Linux DHCPv6 client, which in most cases have different IAID. Even both clients (Windows and Linux) are on the same computer with same MAC address, which matches MAC address in dnsmasq configuration file. That is why I called IPv6 address assignment according to MAC address as "semi-brokenness". > > > 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. > > --- > > > > This is my original patch rebased on top of current git master branch. > > Acknowledge > > > > Previous email with this patch probably dropped into spambox > > and was not processed. > > (unspoken words + > http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2020q2/014018.html > ) > > > > So please let me know if now this email was correctly received. > > Recieved the patch and was able to `git am` it. > It did compile and passed the unittests. > > No further check was done. Mostly because not facing the problem that > patch submitter has. Probably some day I will, hence the above 'How to > reproduce that semi-brokenness?' > > > > src/rfc3315.c | 55 +++ > > 1 file changed, 47 insertions(+), 8 deletions(-) > > > > diff --git a/src/rfc3315.c b/src/rfc3315.c > > index b3f0a0a..e588b13 100644 > > --- a/src/rfc3315.c > > +++ b/src/rfc3315.c > ... 142 lines of actual patch ... > > > Groeten > Geert Stappers > -- > Silence is hard to parse > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss -- Pali Rohár pali.ro...@gmail.com ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] [PATCH v2] DHCPv6: Honor assigning IPv6 address based on MAC address
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.
---
This is my original patch rebased on top of current git master branch.
Previous email with this patch probably dropped into spambox and was not
processed. So please let me know if now this email was correctly received.
---
src/rfc3315.c | 55 +++
1 file changed, 47 insertions(+), 8 deletions(-)
diff --git a/src/rfc3315.c b/src/rfc3315.c
index b3f0a0a..e588b13 100644
--- a/src/rfc3315.c
+++ b/src/rfc3315.c
@@ -48,7 +48,7 @@ static int build_ia(struct state *state, int *t1cntr);
static void end_ia(int t1cntr, unsigned int min_time, int do_fuzz);
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 int config_valid(struct dhcp_config *config, struct dhcp_context
*context, struct in6_addr *addr, struct state *state, time_t now);
static struct addrlist *config_implies(struct dhcp_config *config, struct
dhcp_context *context, struct in6_addr *addr);
static void add_address(struct state *state, struct dhcp_context *context,
unsigned int lease_time, void *ia_option,
@@ -688,8 +688,13 @@ 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 &&
+config_has_mac(config, state->mac, state->mac_len,
state->mac_type) &&
+match_netid(c->filter, solicit_tags, plain_range)
&&
+!config_implies(config, c, _addr))
+ continue; /* another static address is configured */
/* add address to output packet */
add_address(state, c, lease_time, ia_option, _time,
_addr, now);
@@ -701,7 +706,10 @@ static int dhcp6_no_relay(struct state *state, int
msg_type, void *inbuff, size_
/* Suggest configured address(es) */
for (c = state->context; c; c = c->current)
- if (!(c->flags & CONTEXT_CONF_USED) &&
+ if ((!(c->flags & CONTEXT_CONF_USED) ||
+ (state->mac_len && config &&
+ config_has_mac(config, state->mac, state->mac_len,
state->mac_type)
+ )) &&
match_netid(c->filter, solicit_tags, plain_range) &&
config_valid(config, c, , state, now))
{
@@ -725,6 +733,11 @@ static int dhcp6_no_relay(struct state *state, int
msg_type, void *inbuff, size_
req_addr = ltmp->addr6;
if ((c = address6_available(state->context, _addr,
solicit_tags, plain_range)))
{
+ if (state->mac_len && config &&
+ config_has_mac(config, state->mac, state->mac_len,
state->mac_type) &&
+ match_netid(c->filter, solicit_tags, plain_range) &&
+ !config_implies(config, c, _addr))
+ continue; /* skip this lease because another static
address is configured */
add_address(state, c, c->lease_time, NULL, _time,
_addr, now);
mark_context_used(state, _addr);
get_context_tag(state, c);
@@ -859,7 +872,7 @@ static int dhcp6_no_relay(struct state *state, int
msg_type, void
Re: [Dnsmasq-discuss] [PATCH] DHCPv6: Honor assigning IPv6 address based on MAC address
Hello! I have not got any reply about this patch for years. So I would like to know, is some spam filter eating my emails and therefore patch was not delivered? Can somebody confirm if Simon got my patch or should I probably resent it from different email address, to prevent spam filter problems? On Friday 07 February 2020 23:08:32 Pali Rohár wrote: > Hello Simon! > > Could you please review / comment this patch? > > I would like to know what is needed to be fixed or changed, so patch > could be finally merged. > > 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 > > n
Re: [Dnsmasq-discuss] IPv6 host-id
On Tuesday 21 April 2020 08:27:49 Geert Stappers wrote: > On Mon, Apr 20, 2020 at 10:27:11PM -0400, Jiawen Chen wrote: > > # Assign 192.168.0.150 and [::0:1000] to my living room pc > > dhcp-host=,192.168.0.150,[::0:1000],livingroom.internal,12h > > > > # Assign 192.168.0.151 and [::0:1001] to my file server > > dhcp-host=,192.168.0.151,[::0:1001],fileserver.internal,12h > > ``` > > > > Sadly, the host-id-only notation ([::0:1000]) does not appear permitted > > when dnsmasq parses /etc/hosts. > > > > Any suggestions would be greatly appreciated! > > FWIW I suggest configuration syntax that allows > > > dhcp-host=,192.168.0.150,[interface(br0)::0:1000],livingroom.internal,12h Hello Jiawen! Beware that IPv6 address does not have to be assigned based on MAC address settings in config file. MAC to IPv6 assignment is not enforced by dnsmasq and if your DHCPv6 client changes DUID or IAID (e.g. dualbooting to different OS or PXE or reinstalling OS) then some another free IPv6 address would be assigned for your PC identified by . There is my pending patch which should fix this problem and when user want then IPv6 address would be enforced for particular MAC address. -- Pali Rohár pali.ro...@gmail.com ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Sending user-specified default gateway with RAs
On Sunday 23 February 2020 11:41:47 William Edwards wrote: > Question: how do I configure dnsmasq to supply a user-specified default > gateway address in RAs? Hello William! This is not possible as IPv6 gateway (router) address is not present in RA packet structure. If client receives RA packet it expects that sender of RA packet is gateway (router). So if you do not have dnsmasq on your router, you must disable RA in dnsmasq. And enable RA on your real IPv6 router. In IPv6 network it is expected that RA is sent only by IPv6 router. RA means Router Advertisement and only real router should advertise that is router. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ 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
Hello Simon!
Could you please review / comment this patch?
I would like to know what is needed to be fixed or changed, so patch
could be finally merged.
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 add
Re: [Dnsmasq-discuss] [PATCH] DHCPv6 - Multiple reservations for single host
On Friday 10 January 2020 21:25:22 Simon Kelley wrote: > On 08/01/2020 09:32, Harald Jensås wrote: > > On Tue, 2020-01-07 at 21:51 +, Simon Kelley wrote: > >> On 23/12/2019 11:24, Harald Jensas wrote: > >>> Hi, > >>> > >>> The patch below is a slight alteration to a possible solution > >>> discussed in > >>> http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2017q1/011289.html > >>> . > >>> > >>> My approach here does not require making dhcp-host conditional on a > >>> tag. However, making dhcp-host conditional on a tag would be a nice > >>> addition that could be introduced as a follow up to this to have a > >>> match on the tag of the final OS to keep the provisioned system > >>> consistently configured with a specific address can be very handy. > >>> For > >>> the Openstack use-case I am working in, this however is'nt > >>> necessary. > >>> > >>> I have confirmed that the patch below together with a small change > >>> in > >>> Openstack Ironic (see: https://review.opendev.org/72) solved > >>> the > >>> long standing issue when doing network booting and node > >>> provisioning > >>> in combination with static only dhcp configuration. > >>> > >>> We are looking forward to comments and feedback regarding this > >>> approach. > >>> > >>> Thank you! > >>> > >> > >> If I've understood correctly, this looks like it might be a viable > >> solution. Question: how many addresses do you configure for each > >> host, > >> and is this fragile if the boot process changes, for instance to add > >> new > >> steps? > > > > Thank you for reviewing this! > > > > I have tested using 4 addresses in total, I should be able to do with 2 > > addresses with the workflow I tested with which is OVMF-UEFI->iPXE- > >> LinuxDeployRamdisk->Final OS. OVMF-UEFI uses two addresses just to do > > PXE, but it is kind enough to release both addresses before executing > > the network boot program. Then iPXE uses one, and the deploy ramdisk > > one. Depending on wheater the deploy ramdisk does a release or not > > before rebooting a third address would be used by the final OS. (This > > is where dhcp-host conditional on a tag would be handy to control the > > address of the final OS.) > > > > In the openstack use case the dhcp-config is changed to have just a > > single dhcp-host entry prior to booting into the final os, openstack's > > networking service takes care of issuing a release during this step > > making sure the leased addresses are released. (This is why the dhcp- > > host conditional on a tag is'nt required in the openstack use case. > > > > The number of addresses is indeed fragile, adding another bootstep > > could increase the number of addresses needed. Also an unexpected reset > > of the booting system would lock up addresses that where not released, > > mainly problem with UEFI firmware that likes to generate new IAID's > > every time it boots ... > > > > As digression, Pali Rohár `honor assignment based on MAC address` > > patch is less fragile for this use case. I recognize it breaks other > > parts of the DHCPv6 RFC, see my comments on a previous post in this > > thread. Should we consider his approach if the patch can be re-worked > > to be an opt-in via configuration and a note in docs that the behaviour > > is not following RFC? > > Pali has done good work on this and I appreciate it. The objection to > that approach is both the RFC non-compliance, and also the fact that it > absolutely depends on dnsmasq being able to determine the MAC address > of a client. Hi Simon! You are right. We can write into documentation that such setup is non-RFC-compliant. But even that is is non-compliant it is useful in such environment. Openstack is one. Another example is small home network with dual-boot computers. Every reinstallation of OS or rebooting computer to other OS would lead to changing of IAID and DUID. DHCP server can identify computer only by MAC address. There is nothing more which can be used generally. And static DHCPv6 leases is the only way how to configure firewall for particular service on specific host. And in the end, if dnsmasq provides a way for specifying in configuration file assigning IPv6 address based on MAC address, it should implement it the best possible way. Even if it is fragile or not-RFC-compliant. All these information could be put into doc
Re: [Dnsmasq-discuss] [PATCH] Add new extensible D-Bus signal
On Thursday 09 January 2020 12:17:52 Florent Fourcot wrote: > Hello, > > On 09/01/2020 12:10, Pali Rohár wrote: > > Hello! I looked at this API, but is has same problems as old one. It is > > not possible to extend it in future (if it would be needed). Could you > > please design API in way that can be extended in future? (See my > > previous email with details how to achieve it) > > Thanks for our time. Additional data are now in lease_info, a dictionary (as > you suggested in patch V1). Previous values already in old signals are > hardcoded, to simplify migration of users from previous to this new one. Ah, right. So you put there also all previous parameters from old signal (which are fixed and cannot be changed). And then new parameters are put into dictionary which is part of those old parameters. Well, this can work. > So, I'm not sure to understand your point. Could you be more specific? -- Pali Rohár pali.ro...@gmail.com ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [PATCH] Add new extensible D-Bus signal
On Thursday 09 January 2020 11:15:09 Florent Fourcot wrote: > Hello Simon, > > On 06/12/2019 10:53, Victorien Molle wrote: > > For our usage, we need to have more informations sent over D-Bus such as > > the interface > > name, the vendor class identifier and the lease expiration time. > > > > To achieve this, we add a new D-Bus signal "DhcpLeaseNotification" which > > exports the > > requested informations as a dictionnary. > > It also has the advantage to be flexible if someone wants to add a new > > entry in the > > future. > > > > Could you have a look on this patch? It's a new notification feature, with > more DHCP details inside. We are available to improve it if needed. Hello! I looked at this API, but is has same problems as old one. It is not possible to extend it in future (if it would be needed). Could you please design API in way that can be extended in future? (See my previous email with details how to achieve it) -- Pali Rohár pali.ro...@gmail.com ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [PATCH] DHCPv6 - Multiple reservations for single host
On Tuesday 07 January 2020 13:57:02 Harald Jensås wrote: > On Tue, 2020-01-07 at 10:51 +0100, Pali Rohár wrote: > > Hi Harald! What are differences between your patch and mine which > > adds > > support for it too (plus honor assignment based on MAC address)? > > http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2019q4/013545.html > > > > My patch allow creating multiple IPv6 address reservations for the same > host (MAC address), your patch allow a single IPv6 address to be > reserved for multiple MAC addresses? Yes! Now I see difference :-) I misread your description. > Also, Your patch allow dnsmasq to abandon a lease if a new request > using the same MAC address but a different IAID comes. My patch instead > makes it possible to configure multiple IPv6 addresses for a single MAC > address. The first request matching MAC will get leased to that > CLID/IAID combo. Another request from the same MAC using a different > CLID/IAID combo get's a lease using the second reservation, and so on. > No lease is abandoned before either the client does a release or the > lease_time is reached without the client renewing. > > I came up with this approach after realizing Simon already expressed > that the approach of allowing the server to abandon a lease is a bad > idea. Quoting Simon from [1]: > > """ Allowing the IDs to change is a bad idea, > since in DHCPv6 they are the only thing > that identifies a client. If you lease an > address to a CLID/IAID combo, then you > can't lease it to another CLID/IAID until > that lease has expired. """ > > > As I understand the RFC's your approach of allowing a lease to be > abandoned is not allowed. Theoretically it is not according to RFC, but also whole assignment based on MAC address is not according to RFC. And there are usecases for assignment based on MAC address even it is against RFC. One example is multi OS laptop or another example is PXE booting which will always would use different IAID in PXE and in then booted system. > Personally and practically I like the `honor > assignment based on MAC address` patch, but it would also break > compatibility with a client that intentionally ask for multiple leases. > A client is allowed to do so according to RFC. Maby the `honor > assignment based on MAC address` patch need's an iteration that adds a > configuration flag enabling the behaviour + doc update that clarifies > the behaviour is breaking RFC complience? Assignment based on MAC address is useless and does not work without my patch which honors this option. Basically currently whole option for assigning IPv6 based on MAC address is broken and dnsmasq does not respect this option. I have no problem with updating documentation or patch itself, but I have not got any comment for whole year that something is wrong in that patch or that documentation needs to be updated. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [PATCH] DHCPv6 - Multiple reservations for single host
, NULL)) &&
> - have_config(config, CONFIG_NAME))
> +
> + if (state->clid)
> + {
> + /* Loop to find config that is not already used*/
> + int skip_entries = 0;
> + do {
> +config = find_config(daemon->dhcp_conf, state->context, state->clid,
> + state->clid_len, state->mac, state->mac_len,
> + state->mac_type, NULL, skip_entries);
> +/* Always use config with no address */
> +if (config && !>addr6)
> + break;
> +/* Check if address not leased to another CLID/IAID */
> +if (config && check_address(state, >addr6))
> + break;
> +/* Skip one more entry in the next find_config pass */
> +skip_entries++;
> + } while (config != NULL);
> + }
> +
> + if (state->clid && config && have_config(config, CONFIG_NAME))
> {
>state->hostname = config->hostname;
>state->domain = config->domain;
> @@ -557,7 +574,7 @@ static int dhcp6_no_relay(struct state *state, int
> msg_type, void *inbuff, size_
> /* Search again now we have a hostname.
>Only accept configs without CLID here, (it won't match)
>to avoid impersonation by name. */
> - struct dhcp_config *new = find_config(daemon->dhcp_conf,
> state->context, NULL, 0, NULL, 0, 0, state->hostname);
> + struct dhcp_config *new = find_config(daemon->dhcp_conf,
> state->context, NULL, 0, NULL, 0, 0, state->hostname, 0);
> if (new && !have_config(new, CONFIG_CLID) && !new->hwaddr)
> config = new;
> }
> @@ -583,7 +600,7 @@ static int dhcp6_no_relay(struct state *state, int
> msg_type, void *inbuff, size_
> ignore = 1;
> }
>else if (state->clid &&
> -find_config(daemon->dhcp_conf, NULL, state->clid, state->clid_len,
> state->mac, state->mac_len, state->mac_type, NULL))
> +find_config(daemon->dhcp_conf, NULL, state->clid, state->clid_len,
> state->mac, state->mac_len, state->mac_type, NULL, 0))
> {
>known_id.net = "known-othernet";
>known_id.next = state->tags;
--
Pali Rohár
pali.ro...@gmail.com
___
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
Hello!
Today this patch celebrates one year anniversary.
Based on the fact that there was no reported problem for this patch for
one year and also more people tested it and use it in production systems,
could be this patch included it into dnsmasq project?
Or is something else needed?
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
Re: [Dnsmasq-discuss] [PATCH] Add interface name, vendor class if present and lease expiration time to dbus signals
On Wednesday 04 December 2019 20:18:56 Nicolas Cavallari wrote: > On 04/12/2019 13:24, Victorien Molle wrote: > > For our usage, we need to have more informations sent over D-Bus such as > > the interface > > name, the vendor class identifier and the lease expiration time. > > > > Note: in order to get leases extradata be populated, we enabled this > > feature if D-Bus > > is enabled in configuration file (this was enabled in the past only if a > > script was > > ran on leases updates). > > D-Bus has this disadvantage that the change you are proposing completely > breaks the existing D-Bus API that one may be relying on, and many D-Bus > handling libraries would be incapable of understanding both API at the time. Victorien, just for explanation: You cannot change order, number or types of DBus method / signal arguments. It is like function call in any C-like language. It is part of public API which is used by many applications. Number and types of DBus methods / signals is encoded in signature which is passed between DBus clients. > One solution would be to keep the old signal and also send a new signal > with the original info plus the extra, possibly in a way that allows to > add more over time (a dict ?). If you want to create a backward compatible DBus API, you should use array or dictionary (ordered hash map) argument and then pass new values into this array/dictionary. > (Also, this API should be documented in the file dbus/DBus-interface...) -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [PATCH] Add dhcp-ignore-clid configuration option
On Monday 28 October 2019 22:00:21 Oliver Freyermuth wrote: > Hi together, > > Am 12.10.19 um 23:20 schrieb Simon Kelley: > > On 10/10/2019 16:54, Florent Fourcot wrote: > >> Hello Simon, > >> > >> > >>> Of course, it involves enumerating the broken machines, rather than a > >>> blanket setting covering everything, but that's probably a good thing. > >>> It's what I wanted to provide with the tag extension I suggested, and > >>> rather renders that redundant. > >>> > >>> What do you thin Florent? Is this enough, or would you like the new > >>> blanket option as well? > >> > >> Thank you for the point on this option, I missed it before. However, > >> iIterating on hosts is not really a solution for us, since it's customer > >> devices (they appear/disappear out of our control, on a lot of sites). > >> > >> Moreover, in our context, MAC addresses are more relevant than clients > >> identifiers, even for hosts with a valid identifier. Our networks have > >> some checks on couple IP/MAC addresses consistency, and distributing an > >> IP address previously in use with another MAC is probably a bad idea for > >> this kind of tools. > >> > >> So, I'm still in favor of the blanket options. > >> > > > > OK, I'm convinced. The patch is in. > > > > Many thanks. > > > > Simon. > > is this also applicable to IPv6, which suffers from similar issues? No, patch in this email thread affects only IPv4. > This could chime in well withe the patch posted earlier by Pali Rohár on this > list. Yea, it would be year since last time I sent this patch to mailing list... and is still not processed / reviewed yet. > Cheers, > Oliver > > > > > > > ___ > > Dnsmasq-discuss mailing list > > Dnsmasq-discuss@lists.thekelleys.org.uk > > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > > > -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] (PATCH) catch up
On Monday 30 September 2019 22:40:20 Geert Stappers wrote: > On Mon, Sep 30, 2019 at 03:51:43PM +0100, Simon Kelley wrote: > > On 24/09/2019 06:54, Geert Stappers wrote: > > > On Thu, Jan 03, 2019 at 08:12:43PM +, Simon Kelley wrote: > > >> In general, I'm way behind my inbox, and struggling to catch up. Moving > > >> house is not helping :( > > >> I will try and get to everything in the end, but I won't be offended is > > >> people remind me. > > > > > > What would be a reasonable interval time? > > > > > > > Now would be a good time to tell me > > all the stuff I should be dealing with. > > DHCPv6: Honor assigning IPv6 address based on MAC address > http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2018q4/012707.html > > Two "works for me" are > in http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2019q2/013098.html > > Pali Roh�r was early september still on this mailinglist > ( http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2019q3/013289.html > ) I'm still subscribed to dnsmasq mailing list. I'm reading it and so I'm still there! (Btw, seems there is broken encoding in previous email, in my name is letter A with acute accent = á) -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Welcome back, Honor assigning IPv6 address based on MAC address
On Thursday 27 June 2019 07:29:53 Geert Stappers wrote: > On Thu, Jun 27, 2019 at 12:06:31AM +0100, Roy Marples wrote: > > On 26/06/2019 21:16, Oliver Freyermuth wrote: > > > Am 26.06.19 um 21:49 schrieb Pali Rohár: > > > > So, could somebody review and comment my patch? > > > > > > Just to add on this: > > > I'm also using this patch in production since over a month now and it > > > works very well for me (with dnsmasq 2.80). > > > Would really love to see this upstream. > > > > Based on mailing list activity, Simon isn't involved much for reasons > > unknown. I suggest we pester him when he returns :) > > Seen the transmitted smiley, hopefully is indeed a smiley recieved. > > When Simon returns we just should say Welcome back > And we already can start with expressing > >Welcome back > > > Simply because there is life outside this mailinglist. > > > > Just to chime in, I'm using this in production as well with good success as > > well, even though it does go against some DHCP6 designs. > > Thanks for reporting that Hello, just gentle reminder about this patch. I think it still has not been processed yet. -- Pali Rohár pali.ro...@gmail.com ___ 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
On Saturday 11 May 2019 17:42:54 Kevin Darbyshire-Bryant wrote: > > On 6 Apr 2019, at 12:01, Geert Stappers wrote: > > > > On Mon, Apr 01, 2019 at 01:02:20AM +0200, Pali Rohár wrote: > >> On Tuesday 12 February 2019 13:41:43 Geert Stappers wrote: > >>> On 06-02-2019 21:29, Pali Rohár wrote: > >>>> On Friday 11 January 2019 17:52:43 Pali Rohár wrote: > >>>>> 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). > > > > ... > > > >>>>> 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. > >>>>> > >>>> PING > >>>> > >>> Another request for > >>> > >>> Hey, could this patch get reviewed? > >>> > >>> > >> Hello, can somebody review this patch? > >> > > > > FWIW > > > > * The (four months old) patch does get applied cleanly. > > * My compiler is happy with it > > * Executable remains running upon start ( no early crash ) > > * I'm unable to test the (new) IPv6 functionality > > > > > > Where in the "patch pipeline" is Pali's patch? > > > > > > Regards > > Geert Stappers > > I’ve been using this patch to tame qnap’s frustrating dhcpv6 assignment > limitations for many months. It’s immensely useful. > > > Cheers, > > Kevin D-B So, could somebody review and comment my patch? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ 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
Hello, can somebody review this patch? On Tuesday 12 February 2019 13:41:43 Geert Stappers wrote: > Another request for > > Hey, could this patch get reviewed? > > > On 06-02-2019 21:29, Pali Rohár wrote: > > PING > > > > On Friday 11 January 2019 17:52:43 Pali Rohár wrote: > >> 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 le
Re: [Dnsmasq-discuss] Is wrapping close() in retry_send() required ?
On Wednesday 27 February 2019 17:07:21 Simon Kelley wrote:
> On 27/02/2019 15:06, Bogdan Harjoc wrote:
> > There are 50 calls to close() in dnsmasq-2.80, and 10 of them are
> > wrapped in retry_send().
> >
> > "man close" has this paragraph in the section "Dealing with error
> > returns from close":
> >
> > "Retrying the close() after a failure return is the wrong thing to do,
> > since this may cause a reused file descriptor from another thread to
> > be closed. This can occur because the Linux kernel always releases the
> > file descriptor early in the close operation, freeing it for reuse;
> > the steps that may return an error, such as flushing data to the
> > filesystem or device, occur only later in the close operation".
> >
> > Dnsmasq is single-threaded so the retry_send() call is probably
> > harmless. Are there other OSes that may return an error before the fd
> > is released, in other words is there an OS where wrapping close in
> > retry_send is required ?
>
>
> Good questions.
>
> Note that retry_send() only deals with EINTR return codes, ie
> interrupted system calls. (Ok there are other return codes in there, but
> nothing which might be returned by close())
>
> So the use of retry_send(close(...)) is simply to restart the close()
> syscall if a signal arrives during the syscall.
>
>
> HOWEVER, whilst the man page for close() on my Linux machine states that
> EINTR is a possible error return, man (7) signal does NOT include
> close() in the set of syscalls which can be interrupted.
>
> Clearly I was reading the close() man page when I used the wrapper, and
> signal man page when I didn't :)
>
>
> You're probably right that it doesn't matter, but it would be nice to
> make this at least consistent.
>
> Anyone know the answer?
See manpage: http://man7.org/linux/man-pages/man2/close.2.html
The EINTR error is a somewhat special case. Regarding the EINTR
error, POSIX.1-2013 says:
If close() is interrupted by a signal that is to be caught, it
shall return -1 with errno set to EINTR and the state of
fildes is unspecified.
This permits the behavior that occurs on Linux and many other
implementations, where, as with other errors that may be reported by
close(), the file descriptor is guaranteed to be closed. However, it
also permits another possibility: that the implementation returns an
EINTR error and keeps the file descriptor open. (According to its
documentation, HP-UX's close() does this.) The caller must then once
more use close() to close the file descriptor, to avoid file
descriptor leaks. This divergence in implementation behaviors
provides a difficult hurdle for portable applications, since on many
implementations, close() must not be called again after an EINTR
error, and on at least one, close() must be called again. There are
plans to address this conundrum for the next major release of the
POSIX.1 standard.
So retrying close() on EINTR on Linux is an application bug. On the
other hand it is required on HP-UX.
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: PGP signature
___
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
PING On Friday 11 January 2019 17:52:43 Pali Rohár wrote: > 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) &am
Re: [Dnsmasq-discuss] [PATCH] DHCPv6: Honor assigning IPv6 address based on MAC address
On Sunday 13 January 2019 09:11:27 Roy Marples wrote: > On 11/01/2019 16:52, Pali Rohár wrote: > > 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. > > ... > > > > 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. > > Can we get this by itself first? Hehe, no :-) Support for above feature is just side effect of assigning IPv6 address for MAC address if MAC address was specified in config file. Basically after this patch, assigning based on MAC address started working and therefore code which already handles assigning IP(v4) address for MAC address handles it for IPv6 too. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ 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
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, pl
[Dnsmasq-discuss] [PATCH] DHCPv6: Honor assigning IPv6 address based on MAC address
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 &&
+config_has_mac(config, state->mac, state->mac_len,
state->mac_type) &&
+match_netid(c->filter, solicit_tags, plain_range)
&&
+config_valid(config, c, ) &&
+!IN6_ARE_ADDR_EQUAL(_addr, ))
+ continue; /* another static address is configured */
/* add
Re: [Dnsmasq-discuss] [PATCH] DHCPv6: Add support for more than one hardware address per IPv6 address
On Saturday 02 June 2018 16:25:51 Pali Rohár wrote: > On Saturday 02 June 2018 15:48:58 Pali Rohár wrote: > > On Tuesday 23 May 2017 09:39:11 Pali Rohár wrote: > > > On Monday 22 May 2017 23:11:02 Simon Kelley wrote: > > > > On 12/05/17 16:32, Pali Rohár wrote: > > > > > 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? > > > > > > > > The whole point of DHCP is to avoid an IP address being used by more > > > > than one network card. The current two-MAC addresses for one IP facility > > > > in DHCPv4 doesn't contradict this. It's specified to be used only when > > > > there's a guarantee that both MAC address are never simultaneously in > > > > use. > > > > > > I know. But as I wrote, lot of people misuse this feature to assign one > > > IPv4 address to more network cards. As there is use case for such state > > > and dnsmasq can do it. > > > > > > So instead of misusing that feature I'm asking how to implement it > > > properly. > > > > Hi Simon! > > > > Do you have any opinion about this? Or do you fully disagree and such > > feature should not be in dnsmasq? > > > > > > Cheers, > > > > > > > > Simon. > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > In IPv6 it is a more complicated, e.g. when network administrator wants > > to assign one IPv6 address for specific computer. > > > > Imagine that you have one computer with more OS (dua-boot) and each OS > > has its own DUID and IAID (MAC address is stable). > > > > Problem: dnsmasq assign IPv6 address to that computer when OS1 is > > running. Computer is then rebooted to OS2 which has different DUID and > > IAID. Therefore dnsmasq assigns a new (different) IPv6, because old one > > is still "used" in server lease file. > > > > To "solve" this problem it is either needed to extend dnsmasq to allow > > assigning one IPv6 address to more DUIDs/IAIDs. > > > > Or to assign IPv6 addresses based on MAC address and then dnsmasq leases > > file needs to be extended to included also MAC address for IPv6 > > addresses. > > Currently in lease file for DHCPv6 records there is line: > > e
Re: [Dnsmasq-discuss] 128 bit prefix length on static ipv6 lease
On Wednesday 22 August 2018 13:19:23 Roger James wrote: > My static ipv6 leases get delivered with a 128 bit prefix length. > > eth0: flags=4163 mtu 1500 >inet 192.168.10.9 netmask 255.255.255.0 broadcast 192.168.10.255 >inet6 fe80::681:fbbe:cf42:4bf prefixlen 64 scopeid 0x20 >inet6 fda0:4d7f:afbb::9 prefixlen 128 scopeid 0x0 >inet6 2001:8b0:1418:4c2f2::9 prefixlen 64 scopeid 0x0 > > > The prefix on the 2001:8b0:1418:4c2f address is 64 because I have overidden > it with a locally defined static address. The prefix on the fda0:4d7f:afbb > address is as delivered by dnsmasq. I cannot see an obvious way to override > this in the routers dnsmasq config. The hostid is correct so it would appear > that my DUID is also correct. What am I missing? Hi! DHCPv6 assign just one IPv6 address which means address with /128 prefix. Routing in IPv6 is done via Router Advertisement (which dnsmasq supports too). What is the output of route -n? Is there route for that your fda0:4d7f:afbb:: prefix? -- Pali Rohár pali.ro...@gmail.com ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DHCPv6 with dnsmasq for automated deployments
> Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 > >>>> DHCPSOLICIT(br-lan) 00:01:00:01:22:9a:b7:2b:24:5e:be:0c:bc:ba > >>> it seems the QNAP NAS box is using a fresh client DUID each reboot... > >> > >> > >> Patches Welcome > > > > At the moment, there's sadly too much in my queue to start on another > > OpenSource project - but I'll look into it once this changes, > > which sadly won't be in the very near future. > > If anybody else has time at hand, of course I can offer to test a patch > > (the setup is here). > > > > Cheers, > > Oliver > > > >> > >> ___ > >> 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 > > > > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ 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
On Tuesday 23 May 2017 09:39:11 Pali Rohár wrote: > On Monday 22 May 2017 23:11:02 Simon Kelley wrote: > > On 12/05/17 16:32, Pali Rohár wrote: > > > 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? > > > > The whole point of DHCP is to avoid an IP address being used by more > > than one network card. The current two-MAC addresses for one IP facility > > in DHCPv4 doesn't contradict this. It's specified to be used only when > > there's a guarantee that both MAC address are never simultaneously in use. > > I know. But as I wrote, lot of people misuse this feature to assign one > IPv4 address to more network cards. As there is use case for such state > and dnsmasq can do it. > > So instead of misusing that feature I'm asking how to implement it > properly. Hi Simon! Do you have any opinion about this? Or do you fully disagree and such feature should not be in dnsmasq? > > Cheers, > > > > Simon. > > > > > > > > > > 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. > > > > In IPv6 it is a more complicated, e.g. when network administrator wants to assign one IPv6 address for specific computer. Imagine that you have one computer with more OS (dua-boot) and each OS has its own DUID and IAID (MAC address is stable). Problem: dnsmasq assign IPv6 address to that computer when OS1 is running. Computer is then rebooted to OS2 which has different DUID and IAID. Therefore dnsmasq assigns a new (different) IPv6, because old one is still "used" in server lease file. To "solve" this problem it is either needed to extend dnsmasq to allow assigning one IPv6 address to more DUIDs/IAIDs. Or to assign IPv6 addresses based on MAC address and then dnsmasq leases file needs to be extended to included also MAC address for IPv6 addresses. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ 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
On Saturday 02 June 2018 15:48:58 Pali Rohár wrote: > On Tuesday 23 May 2017 09:39:11 Pali Rohár wrote: > > On Monday 22 May 2017 23:11:02 Simon Kelley wrote: > > > On 12/05/17 16:32, Pali Rohár wrote: > > > > 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? > > > > > > The whole point of DHCP is to avoid an IP address being used by more > > > than one network card. The current two-MAC addresses for one IP facility > > > in DHCPv4 doesn't contradict this. It's specified to be used only when > > > there's a guarantee that both MAC address are never simultaneously in use. > > > > I know. But as I wrote, lot of people misuse this feature to assign one > > IPv4 address to more network cards. As there is use case for such state > > and dnsmasq can do it. > > > > So instead of misusing that feature I'm asking how to implement it > > properly. > > Hi Simon! > > Do you have any opinion about this? Or do you fully disagree and such > feature should not be in dnsmasq? > > > > Cheers, > > > > > > Simon. > > > > > > > > > > > > > > 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. > > > > > > > > In IPv6 it is a more complicated, e.g. when network administrator wants > to assign one IPv6 address for specific computer. > > Imagine that you have one computer with more OS (dua-boot) and each OS > has its own DUID and IAID (MAC address is stable). > > Problem: dnsmasq assign IPv6 address to that computer when OS1 is > running. Computer is then rebooted to OS2 which has different DUID and > IAID. Therefore dnsmasq assigns a new (different) IPv6, because old one > is still "used" in server lease file. > > To "solve" this problem it is either needed to extend dnsmasq to allow > assigning one IPv6 address to more DUIDs/IAIDs. > > Or to assign IPv6 addresses based on MAC address and then dnsmasq leases > file needs to be extended to included also MAC address for IPv6 > addresses. Currently in lease file for DHCPv6 records there is line: expire_time iaid ipv6_addr hostname duid and for DHCPv4 is: expire_time mac ipv4_addr hostname clid To have similar format DHCPv6 records as DHCPv4 could be changed and extended for mac address to: expire_time mac ipv6_addr hostname duid iaid Or to have iaid on same position, to: expire_time iaid ipv6_addr hostname duid mac And then allow assigning IPv6 address for IAID and correctly from lease file for IPv6 address takes value relevant for configuration. E.g. when IPv6 address is assigned based on MAC address, took mac. When is assigned for DUID, then duid. And when iaid, then IAID. So when configured this would allow "stealing" IPv6 address when there is one computer which uses two different DHPv6 clients with different DUIDs or IAIDs. (E.g. dual-boot Linux-Windows setup). Also this extended information in lease file could allow to implement that assigning one IPv6 address to more MAC addresses properly as in lease file would be all relevant information about dhcp client. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DHCPv6 with dnsmasq for automated deployments
On Friday 25 May 2018 14:07:34 Oliver Freyermuth wrote: > Dear dnsmasqers, > > I fear the following is a design issue of DHCPv6, but I wonder if there's a > way to overcome it with dnsmasq... > > When automatically deploying machines via PXE / network installer, there's > usually first a DHCPv6 client running in the installer, > and afterwards (when the machine is installed) the "real" DHCPv6 client > running on the machine. > Naturally, both will usually have different client DUIDs... > > Using dnsmasq's functionality to perform DHCPv6 address assignment based on > MAC address, > this works fine for the first client, but the second DHCPv6 client will not > get an address until the old lease is expired. > > In general, I feel this is the correct behaviour, but it's of course rather > inconvenient when deploying machines automatically - > they will retrieve an IPv6 address with the network installer, and then not > get one after the first reboot. > Also, when reinstalling them, they will not get an address in the installer > if the lease from their "old life" is still valid. > > Does somebody have a good solution for this? > Is there something like "id:*" for IPv4 implemented for the IPv6 world (i.e. > something like "duid:*")? > > Cheers and all the best, > Oliver Hi Oliver! dnsmasq for DHCPv6 stores in lease file IAID, not DUID. But assignment of address is done either by DUID or MAC address. I think you hit some problem affected by the way how is IPv6 address assigned according to DUID, IAID, MAC address and status of lease file. 2 years ago I tried to discuss with Simon about possibility to assign one address to more DHCP requests identified by MAC address and one of needed thing was probably extension of lease file (to include also MAC address and DUID) and handling of requests which already have address assigned in lease file. Apparently until now Simon has not response about it and I gave up trying to ping him again... http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2016q1/010404.html -- Pali Rohár pali.ro...@gmail.com ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnsmasq config: avoid using this network for gateway and DNS
On Wednesday 14 February 2018 16:03:44 Libor Peltan wrote: > Good morning, Hi! > i would like to ask how to configure dnsmasq (DHCP options) to tell the > client not to use this network for accessing Internet. > > My server is listening on bluetooth interface; mobile phone connects to the > server and establishes networking over bluetooth. Server is serving DHCP to > assign the mobile phone address for communicating with the server. This > networking-over-bluetooth connection shall be only used for communication > between those two. The server is offline anyway. > > My problem is, that once the mobile phone connects to my server, it sometimes > attempts to use the bluetooth connection to access Internet, instead of using > mobile networks (4G). Often web browsers fail to show webpages (DNS probe no > internet). > > I tried to fix this issue with following parameters to dnsmasq: > > --dhcp-option=3 --dhcp-option=6 --dhcp-option=33,, > --dhcp-option-force=121, /24, > > However it does not really help. For a very similar setup I'm using following dnsmasq options: -C /dev/null -F , -K -p 0 -O 3 -O 6 and it works fine for me. DHCP client does not set any gateway nor recursive dns server, but sets an ip address. If it does work, does it mean that your phone assigns some (random?) gateway address? Or how that phone attempts to use bluetooth connection if it does not have default gateway? > The problem is complicated, because it must work for "all" types of mobile > phones (Android and iPhone) and they are difficult to debug. > > Thanks much for any advices! > > Libor -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [PATCH] cname no longer accepts trailing dot
On Monday 26 February 2018 19:59:53 Petr Menšík wrote: > - for (arg += strlen(arg)+1; *arg == ' '; arg++); > + for (arg += arglen+1; *arg && isspace(*arg); arg++); Hi! Just one note about this change. Function isspace() is implemented according to current locale and basically every locale can have different set of characters marked as "space". E.g. in C locale isspace() function is truth not only for ASCII space (0x20), but also e.g. for ASCII tab (0x09). Some people improperly use function isspace() just because they think it matches only ASCII spaces (0x20). Due to dependent on locale I would suggest to use explicit set of characters... but that is just suggestion. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [PATCH] Fix some errors and warnings from clang-analyzer
On Wednesday 04 October 2017 19:22:11 Rosen Penev wrote: > diff --git a/src/cache.c b/src/cache.c > index 4f43246..88851e7 100644 > --- a/src/cache.c > +++ b/src/cache.c > @@ -572,7 +572,7 @@ struct crec *cache_insert(char *name, struct all_addr > *addr, > } > >if (name) > -strcpy(cache_get_name(new), name); > +strncpy(cache_get_name(new), name, strlen(cache_get_name(new))); Hi! This line looks suspicious. Should not be length argument sizeof of destination buffer, instead of current length of null term string? Also strncpy in some circumstances fill string which is not null terminated. -- Pali Rohár pali.ro...@gmail.com ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [PATCH] Fix some errors and warnings from clang-analyzer
On Thursday 05 October 2017 01:41:02 ros...@gmail.com wrote: > On Thu, 2017-10-05 at 09:48 +0200, Pali Rohár wrote: > > On Wednesday 04 October 2017 19:22:11 Rosen Penev wrote: > > > diff --git a/src/cache.c b/src/cache.c > > > index 4f43246..88851e7 100644 > > > --- a/src/cache.c > > > +++ b/src/cache.c > > > @@ -572,7 +572,7 @@ struct crec *cache_insert(char *name, struct > > > all_addr *addr, > > > } > > > > > >if (name) > > > -strcpy(cache_get_name(new), name); > > > +strncpy(cache_get_name(new), name, > > > strlen(cache_get_name(new))); > > > > Hi! This line looks suspicious. Should not be length argument sizeof > > of > > destination buffer, instead of current length of null term string? > > > > Doesn't sizeof on a pointer return the size of the pointer instead of > the string? Yes! Therefore I wrote word construction "size of destination buffer" and not code "sizeof(buf)". You need to take size of that destination buffer manually. > > Also strncpy in some circumstances fill string which is not null > > terminated. > > strlen apparently does not include \0. needs a + 1 looks like. That is another problem. But still my above sentence about strncpy applies. strncpy does not ensure that destination string would be always null terminated, even source one was. -- Pali Rohár pali.ro...@gmail.com ___ 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
On Monday 22 May 2017 23:11:02 Simon Kelley wrote: > On 12/05/17 16:32, Pali Rohár wrote: > > 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? > > The whole point of DHCP is to avoid an IP address being used by more > than one network card. The current two-MAC addresses for one IP facility > in DHCPv4 doesn't contradict this. It's specified to be used only when > there's a guarantee that both MAC address are never simultaneously in use. I know. But as I wrote, lot of people misuse this feature to assign one IPv4 address to more network cards. As there is use case for such state and dnsmasq can do it. So instead of misusing that feature I'm asking how to implement it properly. > Cheers, > > Simon. > > > > > > 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 ___ 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
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
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. -- Pali Rohár pali.ro...@gmail.com ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [PATCH] Delay DHCP replies for Raspberry Pi clients
On Wednesday 29 March 2017 23:22:39 Eric Luehrsen wrote: > On 03/29/2017 04:35 PM, Dan Sneddon wrote: > > On 03/29/2017 10:43 AM, Chris Novakovic wrote: > >> On 29/03/2017 18:13, Kurt H Maier wrote: > >>> On Wed, Mar 29, 2017 at 02:48:48PM +0200, Floris Bos wrote: > >>>> The PXE boot firmware implementation of the Raspberry Pi 3 > >>>> has a bug causing it to fail if it receives replies > >>>> instantly. > >>> > >>> Why not have a configurable dhcp-delay setting instead of putting > >>> device-specific quirks into the source code of dnsmasq forever? > >> > >> +1 for a dhcp-delay setting, ideally per-MAC: the Ethernet adapters on > >> older RPi models (as well as the built-in wifi adapter on the RPi 3) > >> also use the b8:27:eb OUI, and this artificial delay oughtn't be applied > >> to them. > > > > Another +1 for adding a dhcp-delay setting on a per-MAC basis. > > PXE devices are limited. I guess in a way of thinking that is > intentionally so. A server side robustness action is a valid use case > consideration. I would suggest the "tag" option method. You can tag a > network if say a whole subnet was only to serve PXE security cameras. > You can tag a partial MAC (wildcard) to ID a manufacturer. Assign the > delay option to the tag. This is just like DHCP "need broadcast" and > other client-server quirks. +1 for tag method. -- Pali Rohár pali.ro...@gmail.com ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Debugging dnsmasq on Ubuntu
On Wednesday 29 March 2017 09:43:33 Joel Whitehouse wrote: > Both the file /var/run/NetworkManager/dnsmasq.conf and the directory > /etc/NetworkManager/dnsmasq.d/ are empty, so it's likely that dnsmasq is > receiving its resovlers from Network Manager over the dbus interface. Right. > Is there any way to get dnsmasq to log when it issues a new query to a > resolver? I have all information in syslog. dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 21 dhclient: DHCPREQUEST of X.X.X.X on wlan0 to 255.255.255.255 port 67 dhclient: DHCPOFFER of X.X.X.X from X.X.X.X dhclient: DHCPACK of X.X.X.X from X.X.X.X dhclient: bound to X.X.X.X -- renewal in X seconds. NetworkManager[1977]: (wlan0): DHCPv4 state changed preinit -> bound NetworkManager[1977]:address X.X.X.X NetworkManager[1977]:prefix X (X.X.X.X) NetworkManager[1977]:gateway X.X.X.X NetworkManager[1977]:nameserver 'X.X.X.X' NetworkManager[1977]:domain name 'X' NetworkManager[1977]: Activation (wlan0) Stage 5 of 5 (IPv4 Configure Commit) scheduled... NetworkManager[1977]: Activation (wlan0) Stage 5 of 5 (IPv4 Commit) started... NetworkManager[1977]: (wlan0): writing resolv.conf to /sbin/resolvconf dnsmasq[4160]: setting upstream servers from DBus dnsmasq[4160]: using nameserver X.X.X.X#53 So when NetworkManager via dbus reconfigure list of nameservers then dnsmasq logs them into syslog. -- Pali Rohár pali.ro...@gmail.com ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Windows ipv6 hostname
On Monday 26 December 2016 14:50:41 Markus Hartung wrote: > >For dhcpv6 I have own dnsmasq patches which assign ipv6 address > >bases on > >mac address... > > That could be interesting with such patch. Is there any reason it > haven't been accepted? See discussion: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2016q1/010135.html http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2016q1/thread.html#10135 Simon did not response about it for 11 months... so I do not know. http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2016q4/010885.html > What I need is just a way for a given mac-address dnsmasq should be > informed of the hostname. Anyway, dnsmasq has already some support for mac-address in DHCPv6... -- 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] Windows ipv6 hostname
On Friday 23 December 2016 10:39:20 Markus Hartung wrote: > Is there a way to flush the lease database in dnsmasq? I have tried > removing the line in /var/lib/misc/dnsmasq.leases and restart dnsmasq > but my laptop still gets the same IP-address. Or is it that dnsmasq > uses the mac-address to generate same IP-address every time? Removing lease database file when dnsmasq is not running should be enough. But dhcp client can try to "renew" already assigned IP address and dhcp client (dnsmasq) can extend this lease if nobody is using requested ip address. So you should remove both *client* and *server* databases to prevent such situation. I think it is possible to configure dnsmasq to assign only configured ipv4 address for mac address. For dhcpv6 I have own dnsmasq patches which assign ipv6 address bases on mac address... -- 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] Windows ipv6 hostname
Hi Uwe! On Thu Dec 22 17:35:16 2016 Uwe Schindler <u...@thetaphi.de> wrote: > Hi, > > Windows hosts generally have 2 problems, so assigning a DNS name with > IPv6 address using "ra-names" only works under the following > circumstances: > > - The Windows firewall must allow ICMP Echo (PING) requests to go > through (IPv6). And here comes the problem: By default the Windows > firewall blocks pings on IPv4 and IPv6. Dnsmasq pings the possible SLAAC > defined IPv6 address to see if it is valid. And that does not work by > default. Ah, so firewall settings. Anyway for correct IPv6 setup you should not disable ICMPv6. As ICMPv6 messages are critical part of whole network. ECHO is probably not needed, but PACKET-TOO-BIG is *required*. > - Windows has to assign the IPv6 address using the official > SLAAC algorithm! Unfortunately with randomized-ideftifiers enabled (also > the default), the auto-assigned IPv6 addresses are not created form the > MAC address using the SLAAC algorithm. You have to disable > randomized-identifiers to make this work. SLAAC is not used when A(utonomous) bit is not announced in RA prefix and in case M(anaged) bit is present DHCPv6 should be used. And I think this setup is used, so SLAAC algorithm does not matter here. > With above default, Windows hides its IPv6 address completely and you > cannot guess it. > > Important: Randomized-Identifiers has nothing to do with privacy > extensions (with privacy extensions, the IPv6 address is still SLAAC > conform, but IPv6 hosts use a second address for *outgoing* connections > only. The SLAAC address is still there and can be pinged). > > On my windows machines I have disabled randomized-identifiers, but they > still use privacy extensions. In additions pinging is enabled in the > firewall. Then everything works. This is not the fault of dnsmasq, there > is nothing it can do better - maybe instead of pinging it can use some > different approach to "verify" the IP address (something like a IPv6 > like ARP request only). Hm, I think this is not an optimal implementation in dnsmasq. ICMPv6 ND packet should be used instead ICMPv6 ECHO. As ECHO is (as you wrote) by default blocked on Windowses and ND is "equivalent" for ARP I suggest to change implementation to ND. > Uwe > > - > Uwe Schindler > Achterdiek 19, D-28357 Bremen > http://www.thetaphi.de > eMail: u...@thetaphi.de > > > -Original Message- > > From: Dnsmasq-discuss [mailto:dnsmasq-discuss- > > boun...@lists.thekelleys.org.uk] On Behalf Of Pali Rohár > > Sent: Thursday, December 22, 2016 1:49 PM > > To: Markus Hartung <m...@hartmark.se> > > Cc: dnsmasq-discuss@lists.thekelleys.org.uk > > Subject: Re: [Dnsmasq-discuss] Windows ipv6 hostname > > > > On Thursday 22 December 2016 11:24:53 Markus Hartung wrote: > > > On 2016-12-21 14:08, Michael Stilkerich wrote: > > > > Well, dnsmasq needs to get the hostname to assign to a machine from > > > > someplace. I don't know > > > > all the possible places (search the manual page for that), but I > > > > can > > > > > > > > think of: > > > > 1) Dnsmasq configuration (dhcp-host options) > > > > 2) /etc/ethers if enabled > > > > 3) suggested with the DHCPv4 request by the client > > > > > > > > I think Windows 10 should suggest a hostname (3), at least it seems > > > > to do for me. I have manually assigned > > > > a hostname on the Windows computer, and dnsmasq knows and assigns > > > > it. > > > > > > On 2016-12-20 12:53, Pali Rohár wrote: > > > > Another option is to stop using SLAAC and start using DHCPv6 where > > > > you have full control of assigned IPv6 addresses. > > > > > > > > Such feature like host will "randomly" chose address is unsuitable > > > > for setup when you need to have control of which address is > > > > assigned to which device (e.g in this setup when you want to > > > > assign record). > > > > > > I have managed to get DHCPv6 working now, I thought that windows 10 > > > didn't have any support for it. > > > > Windows Vista has (good quality) support for DHCPv6 and IIRC new > > versions of Windowses uses same/similar implementation. So I think > > Windows 10 should work (no idea if some advanced configuration is > > needed)... Also at that time Windows Vista had correct implementation > > of using RA prefix together with assigned DHCPv6 address. (In contrast > > common linux ISC DHCPv6 client is still broken and hardcode
Re: [Dnsmasq-discuss] Windows ipv6 hostname
On Wednesday 21 December 2016 01:26:15 Markus Hartung wrote: > On 2016-12-20 12:53, Pali Rohár wrote: > > Another option is to stop using SLAAC and start using DHCPv6 where > > you have full control of assigned IPv6 addresses. > > > > Such feature like host will "randomly" chose address is unsuitable > > for setup when you need to have control of which address is > > assigned to which device (e.g in this setup when you want to > > assign record). > > That would of cource be the optimal solution, is there a way to get > dnsmasq to do DHCPv6 and also add -records or any third-party > programs/tools to acheive that? IIRC dnsmasq supports it. -- 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] Windows ipv6 hostname
On Thursday 22 December 2016 11:24:53 Markus Hartung wrote: > On 2016-12-21 14:08, Michael Stilkerich wrote: > > Well, dnsmasq needs to get the hostname to assign to a machine from > > someplace. I don't know > > all the possible places (search the manual page for that), but I > > can > > > > think of: > > 1) Dnsmasq configuration (dhcp-host options) > > 2) /etc/ethers if enabled > > 3) suggested with the DHCPv4 request by the client > > > > I think Windows 10 should suggest a hostname (3), at least it seems > > to do for me. I have manually assigned > > a hostname on the Windows computer, and dnsmasq knows and assigns > > it. > > On 2016-12-20 12:53, Pali Rohár wrote: > > Another option is to stop using SLAAC and start using DHCPv6 where > > you have full control of assigned IPv6 addresses. > > > > Such feature like host will "randomly" chose address is unsuitable > > for setup when you need to have control of which address is > > assigned to which device (e.g in this setup when you want to > > assign record). > > I have managed to get DHCPv6 working now, I thought that windows 10 > didn't have any support for it. Windows Vista has (good quality) support for DHCPv6 and IIRC new versions of Windowses uses same/similar implementation. So I think Windows 10 should work (no idea if some advanced configuration is needed)... Also at that time Windows Vista had correct implementation of using RA prefix together with assigned DHCPv6 address. (In contrast common linux ISC DHCPv6 client is still broken and hardcode /64 prefix even if RA announce different). > It turned out that my ufw on my > ubuntu server were blocking the DHCPv6. I was in my simple mind just > assuming that DHCP and DHCPv6 used same ports It is common behaviour that all firewalls block everything except some exceptions. It is also good for security reasons. DHCP is using IPv4 and DHCPv6 is obviously using IPv6. And IPv6 network stack is independent of IPv4, so you need to configure your firewall differently for IPv4 and IPv6 (e.g. iptables vs. ip6tables). And because DHCP and DHCPv6 are *different* protocols, they should not be used on same ports. If you look at DNS there is no DNSv6 or so. DNS is same over IPv4 and IPv6. You cannot ask for IPv6 address via DHCP or IPv4 via DHCPv6. But you can resolve record (IPv6) via IPv4 connection to DNS, so hence DNS is only one. If you cannot memorize number of tcp or udp ports for some services, just look into /etc/services file. $ grep -E -i 'dhcp|bootp' /etc/services bootps 67/tcp # BOOTP server bootps 67/udp bootpc 68/tcp # BOOTP client bootpc 68/udp dhcpv6-client 546/tcp dhcpv6-client 546/udp dhcpv6-server 547/tcp dhcpv6-server 547/udp > Still no hostname in the lease-file. However, I tried creating a > virtual win10 host and it seems to correctly set the hostname. > > $ cat /var/lib/misc/dnsmasq.leases > 1482450696 3e:fa:72:5b:c7:02 192.168.1.184 * 01:3e:fa:72:5b:c7:02 > 1482454218 08:00:27:60:fb:f2 192.168.1.108 budweiser > 01:08:00:27:60:fb:f2 1482454219 34078759 2001:470:28:6ac::b8c2 > budweiser > 00:01:00:01:1f:6b:f9:80:08:00:27:60:fb:f2 > 1482454045 171899506 2001:470:28:6ac::e82c * > 00:03:00:01:3e:fa:72:5b:c7:02 > > Note that the host budweiser correcly gets a host entry in the file. > And ping:ing the hostname on ipv4 and ipv6 yields the correct > ip-address. So if some Windows 10 host is working fine and another not, then some configuration is really needed... You have one working configuration of Windows 10 so you will need to (somehow) reuse it for non-working one. > Been doing some wireshark-ing and found this request on the working > host: > > Frame 1998: 210 bytes on wire (1680 bits), 210 bytes captured (1680 > bits) on interface 0 > Ethernet II, Src: PcsSyste_60:fb:f2 (08:00:27:60:fb:f2), Dst: > IPv6mcast_01:00:02 (33:33:00:01:00:02) > Internet Protocol Version 6, Src: fe80::a00:27ff:fe60:fbf2, Dst: > ff02::1:2 User Datagram Protocol, Src Port: 546, Dst Port: 547 > DHCPv6 > Message type: Request (3) > Transaction ID: 0xe6d3a2 > Elapsed time > Client Identifier > Server Identifier > Identity Association for Non-temporary Address > Fully Qualified Domain Name > Option: Fully Qualified Domain Name (39) > Length: 24 > Value: 000962756477656973657208686172746d61726b02736500 > 0... = Reserved: 0x00 > .0.. = N bit: Server should perform DNS updates > ..0. = O bit: Server has not overridden client's S bit > preference > ...0 = S bit: Server should not perfo
Re: [Dnsmasq-discuss] Windows ipv6 hostname
On Tuesday 20 December 2016 12:14:19 Toke Høiland-Jørgensen wrote: > Markus Hartung <m...@hartmark.se> writes: > > On 2016-12-19 06:18, Toke Høiland-Jørgensen wrote: > >> Markus Hartung <m...@hartmark.se> writes: > >> > >> ... > >> My guess is that Windows 10 implements RFC7217: > >> https://tools.ietf.org/html/rfc7217 > >> > >> If this is the case, there is no way for dnsmasq to predict the > >> IPv6 address of a new client (which is what ra-names relies on), > >> and so you can't get the record. > > > > It's a shame the windows 10 IPv6 implementation lacks those stuff. > > Well, arguably the Windows 10 behaviour is a feature - RFC7217 was > written because the EUI-64 based approach has privacy issues (the > client will use the same address on every network). So I would > expect more and more clients to adopt the privacy-preserving > approach. I believe NetworkManager has support for it on Linux, but > am not sure if it's enabled by default. Another option is to stop using SLAAC and start using DHCPv6 where you have full control of assigned IPv6 addresses. Such feature like host will "randomly" chose address is unsuitable for setup when you need to have control of which address is assigned to which device (e.g in this setup when you want to assign record). > >> A way to get naming is to use ohybridproxy: > >> https://github.com/sbyx/ohybridproxy - this will query mdns on the > >> network for records when asked. However, I am not sure if > >> there is a way to integrate this with the authoritative server in > >> dnsmasq (but if there is, I would love to know about it). > > > > Thanks for the information, but I have managed to compile > > ohybridproxy and have no idea on how to use it. > > Haven't had time to play with it myself yet, so can't be of much help > there; but as I understand it, the idea is that you configure the > proxy to use a particular domain, and then point dnsmasq at it with > --server. Don't think this will integrate with the auth server > mechanism in dnsmasq, though; not sure if there's a way to achieve > that. > > The alternative is to turn off the private addresses in Windows 10, -- Pali Rohár pali.ro...@gmail.com > of course (as Michael suggested). 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] RADV: Send same RDNSS address as in DHCPv6
On Wednesday 20 January 2016 21:03:50 Simon Kelley wrote: > On 16/01/16 15:10, Pali Rohár wrote: > > On Friday 15 January 2016 22:37:46 you wrote: > >> On 01/01/16 21:07, Pali Rohár wrote: > >>> On Friday 01 January 2016 20:58:42 Simon Kelley wrote: > >>>> Does the existing behaviour cause you problems? The rationale > >>>> for why it behaves the way it does is that link-local > >>>> addresses are good IF client and server are on the same link, > >>>> since there's no possibility of addresses changing or > >>>> renumbering. A client getting DNS server addresses from RADV > >>>> is by definition on the same link as the server. One getting > >>>> DNS addresses by DHCP is not (there may be a DHCP relay > >>>> involved) but has DHCP to handle renumbering. > >>> > >>> Hi! Reason is to provide same data over DHCPv6 and over RA. > >>> This is > >>> > >>> really useful to have consistency of connection data in whole > >>> > >>> network. > >>> > >>> When different addresses are sent over DHCPv6 and RA, correct > >>> client behaviour is to use both (different) addresses in DNS > >>> configuration. > >>> > >>> But when I'm running one SW which doing everything needed for > >>> IPv6 > >>> > >>> client subnetwork configuration I would expect that this SW > >>> > >>> provide same data over all channels. Currently redundant > >>> information over DHCPv6 and RA is only DNS (for now). > >> > >> You can certainly configure it to do that, the default does > >> different things for RA and DHCPv6 for the reasons I gave. Have > >> you seen problems with those values when using RA and DHCP? > > > > Problems? Not something which break functionality. Just that OS > > adds two addresses (one l-l from RA and one from DHCPv6) to > > /etc/resolv.conf and both addresses represent just one recursive > > DNS (that where is running dnsmasq). Which I basically do not like > > as there is only one recursive/forwarder DNS server. > > > > Plus also that inconsistency on network that one configuration part > > of IPv6 addresses (RA) send different information as another > > configuration part (DHCPv6). > > > >> If so, that's a bug, that needs to be fixed, but otherwise, the > >> best solution for you may be to configure dnsmasq rather than > >> patching it. > > > > Ok, configuration option for behaviour which I want is also OK. But > > I dot want to hardcode full IPv6 address of machine where is > > running dnsmasq as this address can be changed in time (because it > > comes from DHCPv6 prefix delegation). Option --dhcp-range has > > already fix for it, it accept address suffix with > > constructor:. > > > > But for specifying RDNSS option in dnsmasq it is not possible to > > set global IPv6 address which comes from interface... > > If you set the RDNSS address to be [::] then dnsmasq should > substitute a global address of the interface, for both DHCPv6 and > RA. Great, it is working! dhcp-option=option6:dns-server,[::] -- 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
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? -- 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] Compile Error.
On Wednesday 24 August 2016 17:31:19 Tony White wrote: > inotify.c:92: warning: implicit declaration of function > ‘inotify_init1’ Hi! You do not have header files with definition for system call inotify_init1. That was added to Linux kernel 2.6.27. > CentOS 5.11 Looks like that you have only kernel 2.6.18, so I guess dnsmasq cannot be compiled for such old distribution... -- 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] systemd service improvements
On Tuesday 05 July 2016 22:54:33 Kurt H Maier wrote: > I'm not sure "me, too" is a very good reason to make this change. I > would instead start by convincing the distros you mention above to > use the unit file dnsmasq already has in /contrib, and getting them > all on the same page. dnsmasq is a very flexible tool whose > deployment needs to be crafted to the situation in which it is > used. Aside from some tuning tweaks, most of the applications you > list are classical monoliths, where dnsmasq is very commonly used as > part of a larger package of tools. I fully agree, /contrib is the best place where to have it. -- 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] systemd service improvements
On Thursday 30 June 2016 16:58:56 Craig Andrews wrote: > I'd like to propose a couple changes in terms of systemd in dnsmaq. > First, dnsmasq should always install a systemd unit so all > distributions/users can use it I'm against such change. Why on the Earth install useless files into system which do nothing? I really do not want to see that programs starts installing systemd files just because it is "no harm". If such thing happen, dnsmasq then should install also config file for upstart, also for openrc, and also install shortcut for Windows start menu for *all* systems as that is too by that definition "no harm". -- 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
(after two months) PING! 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... > -- Pali Rohár pali.ro...@gmail.com ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [PATCH] RADV: Send same RDNSS address as in DHCPv6
On Friday 15 January 2016 22:37:46 you wrote: > On 01/01/16 21:07, Pali Rohár wrote: > > On Friday 01 January 2016 20:58:42 Simon Kelley wrote: > >> Does the existing behaviour cause you problems? The rationale for > >> why it behaves the way it does is that link-local addresses are > >> good IF client and server are on the same link, since there's no > >> possibility of addresses changing or renumbering. A client > >> getting DNS server addresses from RADV is by definition on the > >> same link as the server. One getting DNS addresses by DHCP is not > >> (there may be a DHCP relay involved) but has DHCP to handle > >> renumbering. > > > > Hi! Reason is to provide same data over DHCPv6 and over RA. This is > > > > really useful to have consistency of connection data in whole > > > > network. > > > > When different addresses are sent over DHCPv6 and RA, correct > > client behaviour is to use both (different) addresses in DNS > > configuration. > > > > But when I'm running one SW which doing everything needed for IPv6 > > > > client subnetwork configuration I would expect that this SW > > > > provide same data over all channels. Currently redundant > > information over DHCPv6 and RA is only DNS (for now). > > You can certainly configure it to do that, the default does different > things for RA and DHCPv6 for the reasons I gave. Have you seen > problems with those values when using RA and DHCP? Problems? Not something which break functionality. Just that OS adds two addresses (one l-l from RA and one from DHCPv6) to /etc/resolv.conf and both addresses represent just one recursive DNS (that where is running dnsmasq). Which I basically do not like as there is only one recursive/forwarder DNS server. Plus also that inconsistency on network that one configuration part of IPv6 addresses (RA) send different information as another configuration part (DHCPv6). > If so, that's a > bug, that needs to be fixed, but otherwise, the best solution for > you may be to configure dnsmasq rather than patching it. Ok, configuration option for behaviour which I want is also OK. But I dot want to hardcode full IPv6 address of machine where is running dnsmasq as this address can be changed in time (because it comes from DHCPv6 prefix delegation). Option --dhcp-range has already fix for it, it accept address suffix with constructor:. But for specifying RDNSS option in dnsmasq it is not possible to set global IPv6 address which comes from interface... -- 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
On Friday 01 January 2016 21:23:36 Simon Kelley wrote: > On 23/12/15 21:10, Pali Rohár wrote: > > This patch allows to assign one IPv6 address for more config > > entries specified by MAC address. This is similar function as for > > IPv4 addresses in DHCPv4 server code part. > > This needs some thinking about: DHCPv6 is different from DHCPv4 in > that clients are not, at all, identified by MAC address, rather by > client-id and IAID. I know and this is absolutely uncomfortable for me. One client has different DUID across different operating systems. Also different across OS reinstalling... Also if I want to connect new device I need to instruct people how to set stable DUID across all OS... Just not usable for normal usage of "any" device. For identifying computer/device I need some stable identifier and DHCPv6 DUID is *not* stable in current implementation of major usage OS. MAC address of network card is stable. And so this identifier is what I prefer to use. dnsmasq has for it support and I'm happy for it! And when I configure both DHCPv4 and DHCPv6 one configuration line MAC,ipv4,ipv6 is really nice for having "clean" configuration. > In addition, DHCPv6 handles multiple addresses > and leases per client. When using just DUID I have problem here. My laptop has both Wifi and wired ethernet and with DUID information I'm not able to configure dnsmasq for stable ipv6 addresses. > What's important? To be able to specify more than on MAC address, any > one of which can be matched, or to have a single IPv6 address which > is removed from one IAID to another if the MAC addresses are paired? For specified laptops, I have special configuration. All network interfaces (one wifi, one wired ethernet) on those laptops is assigned same IP address. Operating system is configured in special way that when both interfaces are active it send packets *only* via ethernet. So it allows me to have active TCP connections and allows me to switch between wifi/ethernet without dropping it. DHCPv4 in dnsmasq has already support for assigning one ip address to more MAC addresses (more clients) and this my patch add support for it too. -- 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] Fix compilation without HAVE_DNSSEC
On Friday 01 January 2016 20:54:53 Simon Kelley wrote: > On 23/12/15 21:10, Pali Rohár wrote: > > Do not call add_do_bit which is only for dnssec code. > > --- > > > > src/forward.c |2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/src/forward.c b/src/forward.c > > index 041353c..bffea78 100644 > > --- a/src/forward.c > > +++ b/src/forward.c > > @@ -793,8 +793,10 @@ void reply_query(int fd, int family, time_t > > now) > > > > header->hb4 |= HB4_CD; > > > > if (forward->flags |= FREC_AD_QUESTION) > > > > header->hb4 |= HB4_AD; > > > > +#ifdef HAVE_DNSSEC > > > > if (forward->flags & FREC_DO_QUESTION) > > > > add_do_bit(header, nn, (char *)pheader + plen); > > > > +#endif > > > > forward_query(-1, NULL, NULL, 0, header, nn, now, forward, > > forward->flags & FREC_AD_QUESTION, forward->flags & > > FREC_DO_QUESTION); return; > > > > } > > Is this against 2.75? All the EDNS0 header code has had a major > overhaul in the development code, and I think that this is probably > no longer relevant. If not please shout and I'll look again. Current code in git: ce5732e84fc46d7f99c152f736cfb4ef5ec98a01 -- 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] RADV: Send same RDNSS address as in DHCPv6
On Friday 01 January 2016 20:58:42 Simon Kelley wrote: > Does the existing behaviour cause you problems? The rationale for why > it behaves the way it does is that link-local addresses are good IF > client and server are on the same link, since there's no possibility > of addresses changing or renumbering. A client getting DNS server > addresses from RADV is by definition on the same link as the server. > One getting DNS addresses by DHCP is not (there may be a DHCP relay > involved) but has DHCP to handle renumbering. Hi! Reason is to provide same data over DHCPv6 and over RA. This is really useful to have consistency of connection data in whole network. When different addresses are sent over DHCPv6 and RA, correct client behaviour is to use both (different) addresses in DNS configuration. But when I'm running one SW which doing everything needed for IPv6 client subnetwork configuration I would expect that this SW provide same data over all channels. Currently redundant information over DHCPv6 and RA is only DNS (for now). -- 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
[Dnsmasq-discuss] [PATCH] RADV: Send same RDNSS address as in DHCPv6
Before this patch when both RADV and DHCPv6 is running and DNS server
address was not configured then RADV were sending link-local address and
DHCPv6 global address.
This patch change behaviour of RADV and when both RADV and DHCPv6 is
running without configured DNS server then in RADV RDNSS will be same
global address as in DHCPv6 instead link-local address.
---
man/dnsmasq.8 |4 ++--
src/radv.c| 22 ++
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/man/dnsmasq.8 b/man/dnsmasq.8
index 6a121fe..bb588d3 100644
--- a/man/dnsmasq.8
+++ b/man/dnsmasq.8
@@ -1695,8 +1695,8 @@ the machine running dnsmasq. By default, the "managed
address" bits are set, and
the "use SLAAC" bit is reset. This can be changed for individual
subnets with the mode keywords described in
.B --dhcp-range.
-RFC6106 DNS parameters are included in the advertisements. By default,
-the relevant link-local address of the machine running dnsmasq is sent
+RFC6106 DNS parameters are included in the advertisements. By default
+the relevant DHCPv6 address (or link-local when using SLAAC) of the machine
running dnsmasq is sent
as recursive DNS server. If provided, the DHCPv6 options dns-server and
domain-search are used for the DNS server (RDNSS) and the domain serach list
(DNSSL).
.TP
diff --git a/src/radv.c b/src/radv.c
index 39f1e92..15e116c 100644
--- a/src/radv.c
+++ b/src/radv.c
@@ -482,6 +482,28 @@ static void send_ra_alias(time_t now, int iface, char
*iface_name, struct in6_ad
}
}
+ if (daemon->port == NAMESERVER_PORT && !done_dns && parm.link_pref_time != 0
&& parm.other)
+for (context = daemon->dhcp6; context; context = context->next)
+ if (context->if_index == iface &&
!IN6_IS_ADDR_UNSPECIFIED(>local6))
+ {
+ /* squash duplicates */
+ struct dhcp_context *c;
+ for (c = context->current; c; c = c->current)
+ if ((c->flags & CONTEXT_USED) &&
+ IN6_ARE_ADDR_EQUAL(>local6, >local6))
+ break;
+
+ if (!c)
+ {
+ done_dns = 1;
+ put_opt6_char(ICMP6_OPT_RDNSS);
+ put_opt6_char(3);
+ put_opt6_short(0);
+ put_opt6_long(min_pref_time);
+ put_opt6(>local6, IN6ADDRSZ);
+ }
+ }
+
if (daemon->port == NAMESERVER_PORT && !done_dns && parm.link_pref_time != 0)
{
/* default == us, as long as we are supplying DNS service. */
--
1.7.9.5
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] [PATCH] DHCPv6: Add support for more than one hardware address per IPv6 address
This patch allows to assign one IPv6 address for more config entries
specified by MAC address. This is similar function as for IPv4 addresses
in DHCPv4 server code part.
---
man/dnsmasq.8 |9 ++---
src/rfc3315.c | 63 -
2 files changed, 60 insertions(+), 12 deletions(-)
diff --git a/man/dnsmasq.8 b/man/dnsmasq.8
index d51b10f..6a121fe 100644
--- a/man/dnsmasq.8
+++ b/man/dnsmasq.8
@@ -978,10 +978,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 3ed8623..19738b4 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);
@@ -704,7 +704,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 =
mark_config_used(c, );
@@ -713,8 +713,14 @@ static int dhcp6_no_relay(struct state *state, int
msg_type, void *inbuff, size_
}
else if (!(c = address6_available(state->context, req_addr,
solicit_tags, plain_range)))
continue; /* not an address we're allowed */
- else if (!check_address(state, req_addr))
+ else if (!check_address(state, config, req_addr))
continue; /* address leased elsewhere */
+ else if (state->mac_len && config &&
+config_has_mac(config, state->mac, state->mac_len,
state->mac_type) &&
+match_netid(c->filter, solicit_tags, plain_range)
&&
+config_valid(config, c, ) &&
+!IN6_ARE_ADDR_EQUAL(req_addr, ))
+ continue; /* another static address is configured */
/* add address to output packet */
#ifdef OPTION6_PREFIX_CLASS
@@ -730,10 +736,13 @@ static int dhcp6_no_relay(struct state *state, int
msg_type, void *inbuff, size_
/* Suggest configured address(es) */
for (c = state->context; c; c = c->current)
- if (!(c->flags & CONTEXT_CONF_USED) &&
+ if ((!(c->flags & CONTEXT_CONF_USED) ||
+ (state->mac_len && config &&
+ config_has_mac(config, state->mac, state->mac_len,
state->mac_type)
+ )) &&
match_netid(c->filter, solicit_tags, plain_range) &&
config_valid(config, c, ) &&
- check_address(state, ))
+ check_address(state, config, ))
{
mark_config_used(state->context, );
if (have_config(config, CONFIG_TIME))
@@ -758,6 +767,12 @@ static int dhcp6_no_relay(struct state *state, int
msg_type, void *inbuff, size_
req_addr = >addr6;
if ((c = address6_available(state->context, req_addr,
solicit_tags, plain_range)))
[Dnsmasq-discuss] [PATCH] Fix compilation without HAVE_DNSSEC
Do not call add_do_bit which is only for dnssec code. --- src/forward.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/src/forward.c b/src/forward.c index 041353c..bffea78 100644 --- a/src/forward.c +++ b/src/forward.c @@ -793,8 +793,10 @@ void reply_query(int fd, int family, time_t now) header->hb4 |= HB4_CD; if (forward->flags |= FREC_AD_QUESTION) header->hb4 |= HB4_AD; +#ifdef HAVE_DNSSEC if (forward->flags & FREC_DO_QUESTION) add_do_bit(header, nn, (char *)pheader + plen); +#endif forward_query(-1, NULL, NULL, 0, header, nn, now, forward, forward->flags & FREC_AD_QUESTION, forward->flags & FREC_DO_QUESTION); return; } -- 1.7.9.5 ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
