On 30/10/2020 15:30, Petr Menšík wrote:
It is year 2020, IPv6 is far too long with us to be optional.
Has it?
https://www.google.com/intl/en/ipv6/statistics.html#tab=per-country-ipv6-adoption
Looks to me like most of the world doesn't even have IPv6.
And thanks to Netflix blocking if you use
On 22/07/2020 13:42, Petr Menšík wrote:
You can use SLAAC for MAC generated addresses and they would be the same
regardless running OS.
This hasn't been true for a number of years because a few OS (and of course
dhcpcd) have grown support for RFC 7217.
Now if they all used the same
On 08/07/2020 10:24, Slawek Kaplonski wrote:
I found out that dhcp-option is only 8 bits so it can be only 255 chars long.
I also found old email
https://www.mail-archive.com/dnsmasq-discuss@lists.thekelleys.org.uk/msg06719.html
with advice to use multiple dhcp-option=… fields to workaround
On 19/03/2020 22:01, Simon Kelley wrote:
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=0506a5ed4e56863627c54aedad30ad61221292ef
should handle both old kernel header files and old kernels, in any
combination.
I really dislike this approach because it makes the assumption that no
On 02/12/2019 17:50, Geert Stappers wrote:
Please enlighten me or us, this mailinglist, why I / we see ' >
33:33:00:01:00:02 '
where I would expect to see ' > ff:ff:ff:ff:ff:ff ' (ethernet broadcast)
Observe the Destination and Source fields. The destination should be the
DHCPv6 multicast
On 22/10/2019 17:17, Normen Kowalewski wrote:
FAIW - i was curious to see if RFC 8415 of November 2018, the update of
the now officially obsoleted RFC 3315, uses some other wording, but it
also just speaks about 4 octets that jointly are an unsigned integer
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
On 14/05/2019 14:29, Oliver Freyermuth wrote:
Same here. In an automated deployment situation, client changes DUID in each
phase:
- PXE (if done via IPv6)
- Installation time (from ramdisk)
- Final OS after installation
This may improve if newer versions of dhcpcd get packaged in installer
On 14/05/2019 04:54, Steve Lloyd wrote:
I am running dnsmasq on the lastest stretch on a rpi. For some reason
dnsmasq dies after about 20 minutes, I can restart it and it will last
another 20 minutes. Any insight on how to fix this would be much
appreciated. Here is the status after it
On 13/05/2019 09:31, Kristoffel Pirard wrote:
The dnsmasq man page for the --user parameter says that "Dnsmasq must
_normally_ be started as root". We tested starting as non-root user,
but with capabilities cap_net_bind_service, cap_net_admin, cap_net_raw.
It currently seems to work, but I'm
On 21/01/2019 08:59, Harald Dunkel wrote:
But AFAICS strongswan's dhcp plugin doesn't, and
surely it is not alone.
Use another DHCP client that does then?
There's no reason why dhcpcd can't work with StrongSwan. You even get a
DHCPv6 client for free which StrongSwan doesn't support.
Will
On 17/01/2019 22:58, Simon Kelley wrote:
The delay is while dnsmasq tests the address it's about to allocate in
case some host is already using it. It sends a ICMP echo request
(essentially a ping) and if it gets a reply, the test fails. After a 3
second timeout the test succeeds and the address
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
On 29/12/2018 18:49, Geert Stappers wrote:
What is your favorite / good enough DHCP test client?
dhcpcd - if there's a relevant DHCP RFC it doesn't support, it's a bug.
https://roy.marples.name/projects/dhcpcd
# dhcpcd -dBT4 xennet0
dhcpcd-7.0.8 starting
DUID
On 12/11/2018 19:09, Jan Psota wrote:
On 12/11/2018 16:11, Donald Muller wrote:
You could put a reservation in dnsmasq for the wired and wireless
MAC addresses and give them the same IP address.
How?
In /etc/dnsmask.hosts I have:
On 12/11/2018 16:11, Donald Muller wrote:
You could put a reservation in dnsmasq for the wired and wireless MAC addresses
and give them the same IP address.
How?
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
Hi List
dnsmasq has this lovely piece of code
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob;f=src/option.c;h=462796996ef208bd013eece70fce51e7dc1a45ad;hb=HEAD#l3240
This effectively stops me using dnsmasq to give the same IP address to
wired and wireless interfaces (which are on the
On 19/07/2018 21:34, Simon Kelley wrote:
This generates multiple instance of the DHCP option 121 in the DHCP
reply packet, which isn't strictly legal.
What makes you think it's not legal?
RFC3442 makes no mention of it not being legal and RFC3396 describes how
multiple instances of options
On 06/06/2018 09:14, Oliver Freyermuth wrote:
I finally managed to test this in my testing setup - it works perfectly fine!
Awesome :D
Could you let me know once it's integrated upstream?
I *am* the upstream for dhcpcd :)
It will be in the next dhcpcd release for sure.
I plan to open
On 04/06/2018 11:49, Roy Marples wrote:
These problems are very nicely solved with RFC 6355 which adds DUID-UUID
where UUID is taken from the hosts firmware. The UUID can then be
displayed on the node alongside the MAC address for provisioning.
https://tools.ietf.org/html/rfc6355
The downside
On 25/05/2018 13:07, Oliver Freyermuth wrote:
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
On 03/06/2018 22:20, Simon Kelley wrote:
I agree that this is an annoying problem. In DHCPv6 even determining the
MAC address of a client is a slightly dodgy operation - there are
circumstances where it's not possible. That notwithstanding, dnsmasq
does it's best, and allows you to configure an
On 05/10/2017 03:23, Rosen Penev wrote:
@@ -1239,7 +1238,7 @@ static struct serverfd *allocate_sfd(union mysockaddr
*addr, char *intname)
#endif
}
- if (intname && strlen(intname) != 0)
+ if (!strlen(intname))
ifindex = if_nametoindex(intname); /* index == 0 when not binding
On 25/04/2017 08:08, Alin Năstac wrote:
> I'm talking about second case, the "static" one. The use case is this:
> 1) Client A using ISC DHCP client gets a lease from a different LAN called X
> 2) Client A gets disconnected from LAN X and connected to LAN Y where
> dnsmasq DHCP server runs in a
On 20/03/2015 12:49, Alfonso Ranieri wrote:
Il 20/03/2015 00:42, Simon Kelley ha scritto:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I want to start the release-process towards 2.73. There's a whole heap
of good stuff since 2.72, and good reasons to get it out there before
proceeding
On 2014-10-03 22:13, Roy Marples wrote:
On 2014-10-03 21:08, Simon Kelley wrote:
This looks fine, but I have a vague worry about breaking the build on
old C libraries that don't define the st_mtim field. Does anyone know
when this entered the standard?
It's not in *any* accepted standard
On 2014-09-29 20:17, Simon Kelley wrote:
On 27/09/14 11:01, Roy Marples wrote:
On Friday 26 Sep 2014 21:14:20 Simon Kelley wrote:
This is just a heads-up that if you're using the --dhcp-script option
in
dnsmasq, and the script you're calling is being interpreted by bash,
then you're affected
Hi Simon
On Monday 29 Sep 2014 20:17:56 Simon Kelley wrote:
There's no definition of what is allowed in those DHCP options, so it's
quite possible that a shell metacharacter would be encountered.
Sanitising the strings would therefore change what gets passed to the
script, ie it would be an
On 2014-09-30 13:33, Nicholas Weaver wrote:
Although, to be honest, although the DHCP vector is trivial to exploit
[1], if the attacker can give you a bogus DHCP reply you've lost
already.
At this point, the attacker already has a full man-in-the-middle of
all network traffic, and can easily
On 2014-09-22 19:48, glphvgacs wrote:
hello,
i posted a earlier version fo this on openwrt-users list with some
interesting responds. here is the tip of the thread just in case:
https://lists.openwrt.org/pipermail/openwrt-users/2014-September/003139.html
--/etc/dnsmasq.conf:
On 2014-07-19 15:53, Niels Penneman wrote:
... but it has a prefix length of 128. Hence, the VMs cannot see each
other.
My configuration explicitly specifies a prefix length of 64; what could
cause the prefix length to be set to 128 on the DHCPv6 client side?
DHCPv6 addresses have no prefix
On 08/03/2014 8:36, Simon Kelley wrote:
On 07/03/14 21:42, Tom Hendrikx wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
I'm using dnsmasq 2.66 to provide my local network with ipv4 dhcp, and
ipv6 information requests (ip addressing is handled by my router).
I'm able to to provide
@lists.thekelleys.org.uk
Subject: Re: [Dnsmasq-discuss] DHCPv6 same host different subnets
On 12/12/13 14:57, Roy Marples wrote:
Hi
According to this:
http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2013q3/007464.html
This should work
dhcp-host=id:00:01:00:01:XXX,[2a01:348:31:2::2],fred
dhcp-host=id
Hi
According to this:
http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2013q3/007464.html
This should work
dhcp-host=id:00:01:00:01:XXX,[2a01:348:31:2::2],fred
dhcp-host=id:00:01:00:01:XXX,[2a01:348:31:3::2],fred
But it fails. I get the last address assigned to the 2a01:348:31:2
Hi List
I've been adding RFC3925 Vendor-Identifying Vendor Options to dhcpcd(8)
and testing against dnsmasq-2.67
I added this to dnsmasq.conf:
dhcp-option=vi-encap:12345, 1, It is pitch black. You are likely to be
eaten by a grue.
dhcp-option=vi-encap:12345, 2, 100
I added this to
On 06/12/2013 21:37, Simon Kelley wrote:
It fails at startup? I can't reproduce that. What's the exact message?
Ahem. A buggy config. my bad!
Secondly, this works via DHCPv4, but doesn't work for DHCPv6. How can
I
debug this? Wireshark shows a correct trace with the same enterprise
number
On 23/11/2013 14:06, dnsmasq.bertra...@dfgh.net wrote:
Hello,
Alwas some problems with my /97 prefix ...
on the client side dhclient say the prefix is /64
the router advertissement is ok with ridsc6 i see that i have /97
prefix
in dhcp no option for prefixlen seems possible
Is a trick
Hi List
The majority of my IPv6 capable hardware doesn't grok DHCPv6.
This is fine and dandy, because it understands RS/RA just fine and some
even work with the RDNSS and DNSSL RA options.
The way that I see it is that the RA can set the O bit so that a well
formed client can then request
On 16/09/2013 11:44, Simon Kelley wrote:
That links seems to refer entirely to DHCPv6. Dnsmasq will allow
non-64 prefix lengths for DHCPv6. What we're talking about here is
rfc4861 router advertisements and I'm not sure how the discussion you
reference applies there.
It shows a case where a RA
On 07/09/2013 19:37, Simon Kelley wrote:
Best of luck. The DHCPv6 protocol allows this, in theory, but how it
should work in practice is not really settled, in my experience. Do
you have a DHCPv6 client that will do the work? All the clients I've
tested seem to only request or expect a single
On 24/07/2013 14:29, Simon Kelley wrote:
I think this should happen already: for IPv4 calls to do_options have
the domain argument which is set to the result of get_domain(address)
which will be domain-suffix unless there's a more specific example.
This is for INFOREQ where there is no
Hi
I've been working on some FQDN issues with dnsmasq. This patch addresses
the following:
* FQDN with just a hostname is NOT terminated (rfc4702 2.3)
* Allow a blank FQDN message to request the hostname (rfc4702 2.3)
(assuming no normal hostname option asked for)
* if expand_hosts is
42 matches
Mail list logo
