Hi,
Am 08.03.21 um 00:42 schrieb Christoph Loesch:
Hi,
with dnsmasq (version 2.80 on current OpenWRT 19.07.7) I noticed following (in
my opinion wrong) behaviour:
when using the setting "dhcp-boot=/pxelinux.0,servername,192.168.1.123" the DHCP Offer/ACK packets
sent do not contain the "Boot
Hi,
Am 12.04.20 um 20:12 schrieb Uwe Schindler:
> Hi,
>
>> thanks for the elaborate reply!
>
> No problem!
and thanks again :-).
>
>> There's a slightly more special case for us: We have one central firewall
>> (which
>> gets the full /56 net on the upstream interface routed to it) and most
Oliver
>
> Simon.
>
>
> On 12/04/2020 18:20, Oliver Freyermuth wrote:
>> Am 12.04.20 um 19:01 schrieb Simon Kelley:
>>> The first question is, how static are your global addresses? Making a
>>> network which can survive renumbering is a lot more difficul
Hi,
thanks for the elaborate reply!
Am 12.04.20 um 19:33 schrieb Uwe Schindler:
> Hi
>
>> I have a setup in mind and wonder whether dnsmasq is the correct tool (since
>> I
>> have not found the necessary functionality in the documentation yet).
>>
>> We have a /56 IPv6 network, and plan to us
Oliver
>
>
> Simon.
>
>
>
> On 12/04/2020 17:20, Oliver Freyermuth wrote:
>> Dear DNSmasqers,
>>
>> I have a setup in mind and wonder whether dnsmasq is the correct tool (since
>> I have not found the necessary functionality in the documentation yet).
Dear DNSmasqers,
I have a setup in mind and wonder whether dnsmasq is the correct tool (since I
have not found the necessary functionality in the documentation yet).
We have a /56 IPv6 network, and plan to use pure DHCPv6 (no stateless
autoconfiguration) in several /64 networks.
There are sev
Dear Harald,
Am 27.01.20 um 10:05 schrieb Harald Jensås:
> On Sun, 2020-01-26 at 20:01 +0100, Oliver Freyermuth wrote:
>> I also like this new approach. "Wasting" 4 addresses for one host
>> seems to be the only way
>> to solve this while conforming to RFCs.
>
Am 07.01.20 um 22:51 schrieb Simon Kelley:
> 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
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
Am 26.06.19 um 21:49 schrieb Pali Rohár:
> 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
Am 14.05.19 um 17:52 schrieb Roy Marples:
> 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
Am 11.05.19 um 19:42 schrieb Kevin Darbyshire-Bryant:
>
>
>> 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
Am 06.06.2018 um 10:36 schrieb Roy Marples:
> 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* t
Dear Roy,
Am 05.06.2018 um 13:34 schrieb Roy Marples:
> 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
Am 04.06.2018 um 23:27 schrieb Roy Marples:
> 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
Am 04.06.2018 um 18:46 schrieb wkitt...@gmail.com:
> On 06/04/2018 07:36 AM, Oliver Freyermuth wrote:
>> Right now, I only know one could:
>> - Stop dnsmasq.
>> - Purge the lease from the leases-file.
>> - Restart dnsmasq.
>
>
> i think the process is:
>
Am 04.06.2018 um 12:49 schrieb Roy Marples:
> 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, dns
ys.
TL;DR: The RFCs did not think about automated machine deployment :-(.
One needs to violate the RFCs to allow for that in a DHCPv6 environment.
Cheers,
Oliver
>
> TLDR; these clients are violating the RFCs. The only feasible way to
> make them behave is for dnsmasq to violate the
Am 25.05.2018 um 17:23 schrieb P W:
> On Fri, May 25, 2018 at 03:34:08PM +0200, Oliver Freyermuth wrote:
>> Am 25.05.2018 um 15:30 schrieb Kevin Darbyshire-Bryant:
>>>> On 25 May 2018, at 13:07, Oliver Freyermuth wrote:
>>>>
>>>> Dear dnsmasqers,
>&g
Am 25.05.2018 um 15:30 schrieb Kevin Darbyshire-Bryant:
>
>
>> On 25 May 2018, at 13:07, Oliver Freyermuth
>> wrote:
>>
>> Dear dnsmasqers,
>>
>> I fear the following is a design issue of DHCPv6, but I wonder if there's a
>> way to overc
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
21 matches
Mail list logo
