#dhcp — Public Fediverse posts

Fortigate is not able to get an IP address from the local DHCP on PnetLab #networking #server #2204 #vmware #dhcp

https://askubuntu.com/q/1566733/612

Fortigate is not able to get an IP address from the local DHCP on PnetLab #networking #server #2204 #vmware #dhcp

https://askubuntu.com/q/1566733/612

Fortigate is not able to get an IP address from the local DHCP on PnetLab #networking #server #2204 #vmware #dhcp

https://askubuntu.com/q/1566733/612

Fortigate is not able to get an IP address from the local DHCP on PnetLab #networking #server #2204 #vmware #dhcp

https://askubuntu.com/q/1566733/612

Fortigate is not able to get an IP address from the local DHCP on PnetLab #networking #server #2204 #vmware #dhcp

https://askubuntu.com/q/1566733/612

When two Hetzner servers died at the same time

On May 12, 2026, two of my Arch Linux + LUKS servers at Hetzner became unreachable at the same moment. Both had been running for 4+ months without issue. Both had received the same pacman -Syyu the day before, but had stayed on the old kernel until the morning the websites stopped responding. I rebooted — SSH never came back. nmap -Pn -p 22 showed filtered from anywhere. No ping. No banner. The Hetzner Robot panel insisted the hardware was fine.

Several hours went into hypotheses that turned out to be wrong:

• The encryptssh initcpio hook referencing a /usr/lib/initcpio/udev/11-dm-initramfs.rules file that no longer exists. Real bug, no boot impact — the initramfs rebuilds anyway.
• PermitRootLogin no in sshd_config. Real misconfiguration, fixed it, didn’t help. A refusing sshd shows closed, not filtered.
• Predictable interface-naming drift after the systemd 260 upgrade. Patched the .network config to match by MAC. Useful hardening; not the cause.
• Stale GRUB stage1 + core.img in the MBR. Arch never re-runs grub-install after a grub package upgrade. Refreshed it. Still filtered.
• Kernel 7.0.5 regression. Downgraded to 6.18.3, the kernel that had run for 4 months. Still filtered. So the kernel itself wasn’t it either.

The clue was in the persistent journal: a single recorded boot from December 31 to May 12 10:13 UTC, and absolutely nothing after. Every reboot since the upgrade was failing before systemd-journald could flush to disk — so the failure had to be in the initramfs, before the root filesystem was even mounted.

What it almost certainly was

Hetzner Dedicated servers configure the initramfs network with ip=dhcp on the kernel command line. That depends on Hetzner’s DHCP server replying to whatever request format the current kernel sends. Somewhere between kernel 6.18 / iproute2 6.18 and kernel 7.0 / iproute2 7.0, the request format changed enough that Hetzner’s DHCP stopped responding. Effects:

• Old kernel at runtime kept the interface already configured (Phase A — 32 hours of healthy operation after the package upgrade).
• New kernel cold-boots, hits DHCP, never gets an IP, dropbear cannot listen, port 22 stays filtered.

Hetzner’s own documentation has been quietly moving away from ip=dhcp toward static IPv4 in the kernel command line. The fix is exactly that:

GRUB_CMDLINE_LINUX="cryptdevice=/dev/md1:cryptroot ip=A.B.C.D::GATEWAY:255.255.255.255:hostname:eth0:none"

One line in /etc/default/grub, grub-mkconfig, reboot. No more dependency on Hetzner’s DHCP responding to whatever your current kernel sends.

Why it matters for anyone running this stack

If you run Arch on Hetzner Dedicated with full-disk encryption and remote unlock via dropbear, the ip=dhcp shipped by installimage is a latent bug. It can keep working for years and then break overnight, on every machine you have, after a routine pacman -Syyu. The static-IP version is what Hetzner now recommends and removes the entire dependency.

Tooling

While debugging, I turned the whole rescue / chroot / diagnose / fix workflow into a Python CLI (hal) — including hal fix static-ip, which derives the static cmdline directly from your existing systemd-networkd .network file:

→ github.com/kevinveenbirkenbach/hetzner-arch-luks

Single command, idempotent, reversible (the original /etc/default/grub is backed up to .hal-backup). If you’re on this stack, switch to static IP before the next kernel upgrade catches you.

When two Hetzner servers died at the same time

On May 12, 2026, two of my Arch Linux + LUKS servers at Hetzner became unreachable at the same moment. Both had been running for 4+ months without issue. Both had received the same pacman -Syyu the day before, but had stayed on the old kernel until the morning the websites stopped responding. I rebooted — SSH never came back. nmap -Pn -p 22 showed filtered from anywhere. No ping. No banner. The Hetzner Robot panel insisted the hardware was fine.

Several hours went into hypotheses that turned out to be wrong:

• The encryptssh initcpio hook referencing a /usr/lib/initcpio/udev/11-dm-initramfs.rules file that no longer exists. Real bug, no boot impact — the initramfs rebuilds anyway.
• PermitRootLogin no in sshd_config. Real misconfiguration, fixed it, didn’t help. A refusing sshd shows closed, not filtered.
• Predictable interface-naming drift after the systemd 260 upgrade. Patched the .network config to match by MAC. Useful hardening; not the cause.
• Stale GRUB stage1 + core.img in the MBR. Arch never re-runs grub-install after a grub package upgrade. Refreshed it. Still filtered.
• Kernel 7.0.5 regression. Downgraded to 6.18.3, the kernel that had run for 4 months. Still filtered. So the kernel itself wasn’t it either.

The clue was in the persistent journal: a single recorded boot from December 31 to May 12 10:13 UTC, and absolutely nothing after. Every reboot since the upgrade was failing before systemd-journald could flush to disk — so the failure had to be in the initramfs, before the root filesystem was even mounted.

What it almost certainly was

Hetzner Dedicated servers configure the initramfs network with ip=dhcp on the kernel command line. That depends on Hetzner’s DHCP server replying to whatever request format the current kernel sends. Somewhere between kernel 6.18 / iproute2 6.18 and kernel 7.0 / iproute2 7.0, the request format changed enough that Hetzner’s DHCP stopped responding. Effects:

• Old kernel at runtime kept the interface already configured (Phase A — 32 hours of healthy operation after the package upgrade).
• New kernel cold-boots, hits DHCP, never gets an IP, dropbear cannot listen, port 22 stays filtered.

Hetzner’s own documentation has been quietly moving away from ip=dhcp toward static IPv4 in the kernel command line. The fix is exactly that:

GRUB_CMDLINE_LINUX="cryptdevice=/dev/md1:cryptroot ip=A.B.C.D::GATEWAY:255.255.255.255:hostname:eth0:none"

One line in /etc/default/grub, grub-mkconfig, reboot. No more dependency on Hetzner’s DHCP responding to whatever your current kernel sends.

Why it matters for anyone running this stack

If you run Arch on Hetzner Dedicated with full-disk encryption and remote unlock via dropbear, the ip=dhcp shipped by installimage is a latent bug. It can keep working for years and then break overnight, on every machine you have, after a routine pacman -Syyu. The static-IP version is what Hetzner now recommends and removes the entire dependency.

Tooling

While debugging, I turned the whole rescue / chroot / diagnose / fix workflow into a Python CLI (hal) — including hal fix static-ip, which derives the static cmdline directly from your existing systemd-networkd .network file:

→ github.com/kevinveenbirkenbach/hetzner-arch-luks

Single command, idempotent, reversible (the original /etc/default/grub is backed up to .hal-backup). If you’re on this stack, switch to static IP before the next kernel upgrade catches you.

When two Hetzner servers died at the same time

On May 12, 2026, two of my Arch Linux + LUKS servers at Hetzner became unreachable at the same moment. Both had been running for 4+ months without issue. Both had received the same pacman -Syyu the day before, but had stayed on the old kernel until the morning the websites stopped responding. I rebooted — SSH never came back. nmap -Pn -p 22 showed filtered from anywhere. No ping. No banner. The Hetzner Robot panel insisted the hardware was fine.

Several hours went into hypotheses that turned out to be wrong:

• The encryptssh initcpio hook referencing a /usr/lib/initcpio/udev/11-dm-initramfs.rules file that no longer exists. Real bug, no boot impact — the initramfs rebuilds anyway.
• PermitRootLogin no in sshd_config. Real misconfiguration, fixed it, didn’t help. A refusing sshd shows closed, not filtered.
• Predictable interface-naming drift after the systemd 260 upgrade. Patched the .network config to match by MAC. Useful hardening; not the cause.
• Stale GRUB stage1 + core.img in the MBR. Arch never re-runs grub-install after a grub package upgrade. Refreshed it. Still filtered.
• Kernel 7.0.5 regression. Downgraded to 6.18.3, the kernel that had run for 4 months. Still filtered. So the kernel itself wasn’t it either.

The clue was in the persistent journal: a single recorded boot from December 31 to May 12 10:13 UTC, and absolutely nothing after. Every reboot since the upgrade was failing before systemd-journald could flush to disk — so the failure had to be in the initramfs, before the root filesystem was even mounted.

What it almost certainly was

Hetzner Dedicated servers configure the initramfs network with ip=dhcp on the kernel command line. That depends on Hetzner’s DHCP server replying to whatever request format the current kernel sends. Somewhere between kernel 6.18 / iproute2 6.18 and kernel 7.0 / iproute2 7.0, the request format changed enough that Hetzner’s DHCP stopped responding. Effects:

• Old kernel at runtime kept the interface already configured (Phase A — 32 hours of healthy operation after the package upgrade).
• New kernel cold-boots, hits DHCP, never gets an IP, dropbear cannot listen, port 22 stays filtered.

Hetzner’s own documentation has been quietly moving away from ip=dhcp toward static IPv4 in the kernel command line. The fix is exactly that:

GRUB_CMDLINE_LINUX="cryptdevice=/dev/md1:cryptroot ip=A.B.C.D::GATEWAY:255.255.255.255:hostname:eth0:none"

One line in /etc/default/grub, grub-mkconfig, reboot. No more dependency on Hetzner’s DHCP responding to whatever your current kernel sends.

Why it matters for anyone running this stack

If you run Arch on Hetzner Dedicated with full-disk encryption and remote unlock via dropbear, the ip=dhcp shipped by installimage is a latent bug. It can keep working for years and then break overnight, on every machine you have, after a routine pacman -Syyu. The static-IP version is what Hetzner now recommends and removes the entire dependency.

Tooling

While debugging, I turned the whole rescue / chroot / diagnose / fix workflow into a Python CLI (hal) — including hal fix static-ip, which derives the static cmdline directly from your existing systemd-networkd .network file:

→ github.com/kevinveenbirkenbach/hetzner-arch-luks

Single command, idempotent, reversible (the original /etc/default/grub is backed up to .hal-backup). If you’re on this stack, switch to static IP before the next kernel upgrade catches you.

When two Hetzner servers died at the same time

On May 12, 2026, two of my Arch Linux + LUKS servers at Hetzner became unreachable at the same moment. Both had been running for 4+ months without issue. Both had received the same pacman -Syyu the day before, but had stayed on the old kernel until the morning the websites stopped responding. I rebooted — SSH never came back. nmap -Pn -p 22 showed filtered from anywhere. No ping. No banner. The Hetzner Robot panel insisted the hardware was fine.

Several hours went into hypotheses that turned out to be wrong:

• The encryptssh initcpio hook referencing a /usr/lib/initcpio/udev/11-dm-initramfs.rules file that no longer exists. Real bug, no boot impact — the initramfs rebuilds anyway.
• PermitRootLogin no in sshd_config. Real misconfiguration, fixed it, didn’t help. A refusing sshd shows closed, not filtered.
• Predictable interface-naming drift after the systemd 260 upgrade. Patched the .network config to match by MAC. Useful hardening; not the cause.
• Stale GRUB stage1 + core.img in the MBR. Arch never re-runs grub-install after a grub package upgrade. Refreshed it. Still filtered.
• Kernel 7.0.5 regression. Downgraded to 6.18.3, the kernel that had run for 4 months. Still filtered. So the kernel itself wasn’t it either.

The clue was in the persistent journal: a single recorded boot from December 31 to May 12 10:13 UTC, and absolutely nothing after. Every reboot since the upgrade was failing before systemd-journald could flush to disk — so the failure had to be in the initramfs, before the root filesystem was even mounted.

What it almost certainly was

Hetzner Dedicated servers configure the initramfs network with ip=dhcp on the kernel command line. That depends on Hetzner’s DHCP server replying to whatever request format the current kernel sends. Somewhere between kernel 6.18 / iproute2 6.18 and kernel 7.0 / iproute2 7.0, the request format changed enough that Hetzner’s DHCP stopped responding. Effects:

• Old kernel at runtime kept the interface already configured (Phase A — 32 hours of healthy operation after the package upgrade).
• New kernel cold-boots, hits DHCP, never gets an IP, dropbear cannot listen, port 22 stays filtered.

Hetzner’s own documentation has been quietly moving away from ip=dhcp toward static IPv4 in the kernel command line. The fix is exactly that:

GRUB_CMDLINE_LINUX="cryptdevice=/dev/md1:cryptroot ip=A.B.C.D::GATEWAY:255.255.255.255:hostname:eth0:none"

One line in /etc/default/grub, grub-mkconfig, reboot. No more dependency on Hetzner’s DHCP responding to whatever your current kernel sends.

Why it matters for anyone running this stack

If you run Arch on Hetzner Dedicated with full-disk encryption and remote unlock via dropbear, the ip=dhcp shipped by installimage is a latent bug. It can keep working for years and then break overnight, on every machine you have, after a routine pacman -Syyu. The static-IP version is what Hetzner now recommends and removes the entire dependency.

Tooling

While debugging, I turned the whole rescue / chroot / diagnose / fix workflow into a Python CLI (hal) — including hal fix static-ip, which derives the static cmdline directly from your existing systemd-networkd .network file:

→ github.com/kevinveenbirkenbach/hetzner-arch-luks

Single command, idempotent, reversible (the original /etc/default/grub is backed up to .hal-backup). If you’re on this stack, switch to static IP before the next kernel upgrade catches you.

When two Hetzner servers died at the same time

On May 12, 2026, two of my Arch Linux + LUKS servers at Hetzner became unreachable at the same moment. Both had been running for 4+ months without issue. Both had received the same pacman -Syyu the day before, but had stayed on the old kernel until the morning the websites stopped responding. I rebooted — SSH never came back. nmap -Pn -p 22 showed filtered from anywhere. No ping. No banner. The Hetzner Robot panel insisted the hardware was fine.

Several hours went into hypotheses that turned out to be wrong:

• The encryptssh initcpio hook referencing a /usr/lib/initcpio/udev/11-dm-initramfs.rules file that no longer exists. Real bug, no boot impact — the initramfs rebuilds anyway.
• PermitRootLogin no in sshd_config. Real misconfiguration, fixed it, didn’t help. A refusing sshd shows closed, not filtered.
• Predictable interface-naming drift after the systemd 260 upgrade. Patched the .network config to match by MAC. Useful hardening; not the cause.
• Stale GRUB stage1 + core.img in the MBR. Arch never re-runs grub-install after a grub package upgrade. Refreshed it. Still filtered.
• Kernel 7.0.5 regression. Downgraded to 6.18.3, the kernel that had run for 4 months. Still filtered. So the kernel itself wasn’t it either.

The clue was in the persistent journal: a single recorded boot from December 31 to May 12 10:13 UTC, and absolutely nothing after. Every reboot since the upgrade was failing before systemd-journald could flush to disk — so the failure had to be in the initramfs, before the root filesystem was even mounted.

What it almost certainly was

Hetzner Dedicated servers configure the initramfs network with ip=dhcp on the kernel command line. That depends on Hetzner’s DHCP server replying to whatever request format the current kernel sends. Somewhere between kernel 6.18 / iproute2 6.18 and kernel 7.0 / iproute2 7.0, the request format changed enough that Hetzner’s DHCP stopped responding. Effects:

• Old kernel at runtime kept the interface already configured (Phase A — 32 hours of healthy operation after the package upgrade).
• New kernel cold-boots, hits DHCP, never gets an IP, dropbear cannot listen, port 22 stays filtered.

Hetzner’s own documentation has been quietly moving away from ip=dhcp toward static IPv4 in the kernel command line. The fix is exactly that:

GRUB_CMDLINE_LINUX="cryptdevice=/dev/md1:cryptroot ip=A.B.C.D::GATEWAY:255.255.255.255:hostname:eth0:none"

One line in /etc/default/grub, grub-mkconfig, reboot. No more dependency on Hetzner’s DHCP responding to whatever your current kernel sends.

Why it matters for anyone running this stack

If you run Arch on Hetzner Dedicated with full-disk encryption and remote unlock via dropbear, the ip=dhcp shipped by installimage is a latent bug. It can keep working for years and then break overnight, on every machine you have, after a routine pacman -Syyu. The static-IP version is what Hetzner now recommends and removes the entire dependency.

Tooling

While debugging, I turned the whole rescue / chroot / diagnose / fix workflow into a Python CLI (hal) — including hal fix static-ip, which derives the static cmdline directly from your existing systemd-networkd .network file:

→ github.com/kevinveenbirkenbach/hetzner-arch-luks

Single command, idempotent, reversible (the original /etc/default/grub is backed up to .hal-backup). If you’re on this stack, switch to static IP before the next kernel upgrade catches you.

So it turns out #FreeBSD via #PXE only uses #TFTP for the initial boot but expects `/boot/lua/loader.lua` to be loaded via #NFS, the root of which it expects to get via #DHCP but #dnsmasq won't supply this when in proxy mode.

Joy.

So it turns out #FreeBSD via #PXE only uses #TFTP for the initial boot but expects `/boot/lua/loader.lua` to be loaded via #NFS, the root of which it expects to get via #DHCP but #dnsmasq won't supply this when in proxy mode.

Joy.

So it turns out #FreeBSD via #PXE only uses #TFTP for the initial boot but expects `/boot/lua/loader.lua` to be loaded via #NFS, the root of which it expects to get via #DHCP but #dnsmasq won't supply this when in proxy mode.

Joy.

So it turns out #FreeBSD via #PXE only uses #TFTP for the initial boot but expects `/boot/lua/loader.lua` to be loaded via #NFS, the root of which it expects to get via #DHCP but #dnsmasq won't supply this when in proxy mode.

Joy.

At home, on most common network which are statefull #dhcp,

You usually get an #ipv4 based on your hardware MAC address, this ensures constancy across device reboot, dual boot (and distro hoping 🙈)

But #ipv6 do not care about the hardware, it will look for a DUID (small string) at /etc/dhcp/duid.

You can persist this file into your dots for your ipv6 address to survive across OS changes.

#linux #archlinux

Interrupted Upgrades #networking #dhcp #ip

https://askubuntu.com/q/1565749/612

You want the #dhcp to yield the same #ipv4 everytime -> ensure your MAC address is fixed.

For the #dhcp to yield the same #ipv6-> ensure /var/lib/dhcpcd/duid
contains a fixed user-defined duid-uuid.

https://www.europesays.com/britain/10074/ UK NCSC says APT28 exploits routers for DNS hijacking, enabling large-scale traffic interception #AdversaryInTheMiddle #AiTM #APT28 #AuthenticationToken #CredentialHarvesting #CyberOperations #DHCP #DNSHijacking #espionage #FancyBear #ForestBlizzard #MilitaryIntelligence #NCSC #NetworkCompromise #RouterConfigurations #routers #SednitGang #Sofacy #Strontium #TrafficInterception #UK #UnitedKingdom #vulnerabilities

Joah... was macht man so am Oster-Wochenende???

Na klar: Das eigene lokale Netzwerk komplett umbauen von Flat LAN mit Fritz!Box und Pihole, auf ein ausgewachsenes Business Netzwerk mit:

Fritz!Box nur noch als Modem, OPNsense (als Firewall, Kea DHCP, Unbound DNS), vier TP-Link EAP225 als Access Points mit drei WLANs, ein TP-Link TL-SG1016DE Smart Switch mit nun insgesamt 5 VLANs, Omada Software Controller zur Verwaltung der EAP225.

Alle IoT Geräte die den Homeassistant bedienen in einem eigenen VLAN, Gäste WLAN, IoT WLAN, etc... pp... 😛

Man hat ja sonst nix zu tun.......

#opnsense #netzwerk #network #vlan #homeassistant #iot #pihole #keadhcp #dhcp #omada #tplink

Joah... was macht man so am Oster-Wochenende???

Na klar: Das eigene lokale Netzwerk komplett umbauen von Flat LAN mit Fritz!Box und Pihole, auf ein ausgewachsenes Business Netzwerk mit:

Fritz!Box nur noch als Modem, OPNsense (als Firewall, Kea DHCP, Unbound DNS), vier TP-Link EAP225 als Access Points mit drei WLANs, ein TP-Link TL-SG1016DE Smart Switch mit nun insgesamt 5 VLANs, Omada Software Controller zur Verwaltung der EAP225.

Alle IoT Geräte die den Homeassistant bedienen in einem eigenen VLAN, Gäste WLAN, IoT WLAN, etc... pp... 😛

Man hat ja sonst nix zu tun.......

#opnsense #netzwerk #network #vlan #homeassistant #iot #pihole #keadhcp #dhcp #omada #tplink

Joah... was macht man so am Oster-Wochenende???

Na klar: Das eigene lokale Netzwerk komplett umbauen von Flat LAN mit Fritz!Box und Pihole, auf ein ausgewachsenes Business Netzwerk mit:

Fritz!Box nur noch als Modem, OPNsense (als Firewall, Kea DHCP, Unbound DNS), vier TP-Link EAP225 als Access Points mit drei WLANs, ein TP-Link TL-SG1016DE Smart Switch mit nun insgesamt 5 VLANs, Omada Software Controller zur Verwaltung der EAP225.

Alle IoT Geräte die den Homeassistant bedienen in einem eigenen VLAN, Gäste WLAN, IoT WLAN, etc... pp... 😛

Man hat ja sonst nix zu tun.......

#opnsense #netzwerk #network #vlan #homeassistant #iot #pihole #keadhcp #dhcp #omada #tplink

Joah... was macht man so am Oster-Wochenende???

Na klar: Das eigene lokale Netzwerk komplett umbauen von Flat LAN mit Fritz!Box und Pihole, auf ein ausgewachsenes Business Netzwerk mit:

Fritz!Box nur noch als Modem, OPNsense (als Firewall, Kea DHCP, Unbound DNS), vier TP-Link EAP225 als Access Points mit drei WLANs, ein TP-Link TL-SG1016DE Smart Switch mit nun insgesamt 5 VLANs, Omada Software Controller zur Verwaltung der EAP225.

Alle IoT Geräte die den Homeassistant bedienen in einem eigenen VLAN, Gäste WLAN, IoT WLAN, etc... pp... 😛

Man hat ja sonst nix zu tun.......

#opnsense #netzwerk #network #vlan #homeassistant #iot #pihole #keadhcp #dhcp #omada #tplink

Joah... was macht man so am Oster-Wochenende???

Na klar: Das eigene lokale Netzwerk komplett umbauen von Flat LAN mit Fritz!Box und Pihole, auf ein ausgewachsenes Business Netzwerk mit:

Fritz!Box nur noch als Modem, OPNsense (als Firewall, Kea DHCP, Unbound DNS), vier TP-Link EAP225 als Access Points mit drei WLANs, ein TP-Link TL-SG1016DE Smart Switch mit nun insgesamt 5 VLANs, Omada Software Controller zur Verwaltung der EAP225.

Alle IoT Geräte die den Homeassistant bedienen in einem eigenen VLAN, Gäste WLAN, IoT WLAN, etc... pp... 😛

Man hat ja sonst nix zu tun.......

#opnsense #netzwerk #network #vlan #homeassistant #iot #pihole #keadhcp #dhcp #omada #tplink

Contabo Support & Culture - The technical failure itself is secondary to the organizational failure handling it. Contabo’s support culture demonstrates a fundamental misalignment of incentives.

Optimizing for Metrics Over Solutions: The primary objective of the support tier appears to be closing tickets as quickly as possible, using any available justification, rather than genuinely resolving the customer’s problem.

Blame Shifting: There is a clear tendency to attribute faults to the customer or incorrect settings rather than investigating potential anomalies in the underlying virtualization or infrastructure layer.

Absence of Root Cause Analysis: Because the support team applied a static configuration workaround and immediately closed the ticket, the actual root cause of the disappearing DHCP configuration was never identified.

Perpetual Vulnerability: When root causes are ignored in favor of quick patches, the underlying infrastructure bugs remain. This guarantees that the exact same issue will occur again, leading to an endless cycle of new tickets.

#Contabo #VPS #hosting #support #networking #DHCP

Along the way my ISP's router #DNS cache and #DHCP server helped to frustrate me at every turn 😅 it's why I tacked on the side-project of installing #PiHole, though not quite ready to cut over to that as DHCP server yet.

At the very least my three main network machines now have easy to remember static IPs so when all else fails I don't have to open the awful router web interface to find my stuff.

Overall though I'd call this experience a success. No data was lost and I learned a lot 😁

RFC 9915: #DHCPv6

#IPv6 dispose de 3 mécanismes principaux pour l'allocation d'une adresse IP à une machine. L'allocation statique, « à la main », le système d'« autoconfiguration » SLAAC et #DHCP. DHCP pour IPv6 était normalisé dans le RFC 8415, que notre #RFC met à jour. Le protocole n'a guère changé, le principal changement est la suppression de certaines fonctions peu utilisées.

https://www.bortzmeyer.org/9915.html

Was eine kleine Aktivierung alles bewirken kann. Ums verrecken wollte der DHCP Dienst unter Kea DHCP nicht funktionieren und ich kam auch nicht darauf in den Logs zuschauen, was ich letztendlich dann doch getan habe. Ein zweiter DHCP Dienst war aktiviert. Naja wieder was gelernt. In des Logs schauen und verstehen was da los ist.

#OPNsense #Logs #DHCP

I have a Dell Wyse 3040 thin client I'm trying to PXE boot with a iSCSI root volume.

I can see the DHCP request at power up, but I never see it make the tftp request for the file using the options in the response.

Anybody else had any luck?

#homelab #dhcp #pxe

En début d’année, Free a sorti une mise à jour du firmware des Freebox Server qui apportent deux fonctionnalités majeures Sur le blog Tuto #Freebox #TFTP et Options #DHCP https://blog.genma.fr/?Tuto-Freebox-TFTP-et-Options-DHCP

@whitequark it’s not that involved

## netboot.xyz
enable-tftp
tftp-root=/opt/tftp
#dhcp-boot=netboot.xyz.kpxe
#dhcp-boot=boot/grub/i386-pc/core.0,,192.168.250.1

#pxe-service=x86PC,"PXELINUX (BIOS)",pxelinux.0
#pxe-service=X86-64_EFI,"PXELINUX (EFI)",netboot.xyz.efi
#dhcp-boot=meow
#dhcp-boot=openwrt
dhcp-boot=netboot.xyz.efi
#enable-tftp
#tftp-root=/opt/tftp/

here’s a raw snippet from my config. can’t be bothered to make more sense of it so you get the whole 5 years of evolution

port=0 to disable the DNS resolver

CVE Alert: CVE-2021-47829 - Weird-Solutions - DHCP Broadband - https://www.redpacketsecurity.com/cve-alert-cve-2021-47829-weird-solutions-dhcp-broadband/

#OSINT #ThreatIntel #CyberSecurity #cve-2021-47829 #weird-solutions #dhcp-broadband

Сеть вместо SD-карты: как собрать минимальный Linux для Raspberry Pi с возможностью загрузки по сети

Когда собираешь и тестируешь свой Linux для одноплатника достаточно долго, начинаешь замечать, что деплой Linux на SD-карту — монотонная повторяющаяся последовательность действий, занимающая ценное время, в которой легко совершить ошибку. К тому же больно видеть, как исчерпывает свой ресурс SD-карта и слот для неё. Часто при embedded-разработке эти проблемы решают при помощи сетевой загрузки Linux. В этой статье я расскажу, как организовать сетевую загрузку для Raspberry Pi и собрать минимальное ядро Linux, поддерживающее сетевую загрузку. Сетевая загрузка рассматривается для Raspberry Pi 3 Model В и Raspberry Pi 4 Model B, которые я далее называю общим термином Raspberry Pi или более ласково — малинка. Основное назначение окружения для сетевой загрузки — ускорение отладки и тестирование пользовательских приложений и программ разрабатываемого дистрибутива Linux. Тема сетевой загрузки довольно многогранна и затрагивает несколько уровней стека — от протоколов локальной сети до особенностей загрузчика Raspberry Pi. Я старался изложить материал максимально просто и последовательно, но если у вас нет базовых знаний о работе локальных сетей (DHCP, TFTP), протоколах TCP/IP или процессе загрузки Linux, некоторые моменты могут показаться сложными. Статья является продолжением моей предыдущей статьи , где я рассказывал, как создать минимальный Linux для Raspberry Pi, который грузится с SD-карты. В свой репозиторий я поместил исходный код Docker-образов, упрощающий сборку минимального Linux и настройку окружения для сетевой загрузки. Надеюсь, что статья сэкономит вам время, которое вы сможете потратить на свой увлекательный проект.

https://habr.com/ru/companies/ruvds/articles/976846/

#сетевая_загрузка #минимальный_linux #raspberrypi #tftp #dhcp #nfs #embeded_linux #rpi3 #rpi4 #статьи_ruvds

Finally (2), I have some good enough DHCP server! :drgn_aww:

Tried kea from ISC — it works but requires some additional actions to be launched under #NetBSD. It has very strange default paths for file with leases, PIDs and logs:
- /usr/pkg/var/lib/kea/
- /usr/pkg/var/lib/run/kea
- /usr/pkg/var/log/kea

BTW, it could be changed via playing with some environment variables.

Also, the default startup script uses keactrl to launch DHCP server and keactrl requires some configuration for it. So, to use "service kea start" there are two configuration files are necessary:
- /usr/pkg/etc/keactrl.conf — the main configuration file for server.
- /usr/pkg/etc/kea/keactrl.conf — the configuration file for keactrl.

Then, I tried the dhcpsd — the new promising successor of ISC dhcpd, which could be configured with configuration file in Lua and conforms Unix FHS — all necessary files lies in the right places: /var/run, /var/log, etc. Sadly, it doesn't work: server starts but there are no leases for clients and no any errors in the log :-(

Then, I found cmu-dhcpd in the repos — there is a dhcpd from Carnegie Mellon University with some patches from Princeton. And, finally it works! And it also conforms Unix FHS: main configuration in the /etc/dhcpd.conf, PID-file in the /var/run/dhcpd.pid and logs in the /var/log/messages :drgn_aww:

#selfhosting #dhcp #DHCPv4 #dhcpd

Finally, I have some good enough DHCP server.

It is a kea from ISC – the successor of EOLed dhcpd.

The moment, when I switched re0 interface configuration from DHCP to static IP and rebooted the server — was the most touching. The second one — when I disabled DHCP server in the D-Link router, started kea and restarted the router :drgn_hide:

Fortunately, the lines from connecting phone appeared in the kea log after some lenghty seconds :drgn_happy_blep:

#SelfHosting #dhcp #kea #DHCPv4

Kea DHCP: Modern, open source DHCPv4 and DHCPv6 server

https://www.isc.org/kea/

#HackerNews #Kea #DHCP #open #source #DHCPv4 #DHCPv6 #server #ISC

Foreman в изоляции: как мы построили отказоустойчивую и безопасную систему для массового деплоя ОС

Делимся опытом трансформации нашей инфраструктуры: от децентрализованных экземпляров Foreman с публичными IP до защищённой, изолированной архитектуры с централизованным управлением через GitLab, повышенной безопасностью и легкой масштабируемостью.

https://habr.com/ru/companies/hostkey/articles/941722/

#foreman #PXEдеплой #системное_администрирование #автоматизация #hostkey #gitlab #изоляция_сети #bare_metal #dhcp #devops

New blog post: High Availability DNS and DHCP in the homelab

Apologies in advance, this one is quite lengthy....

https://www.beyondwatts.com/posts/high-availability-dns-and-dhcp/

#homelab #dns #dhcp #powerdns #kea

This guide walks you through every method for changing the IP address on Debian 12, providing clear, step-by-step instructions.

Keep reading:👇
https://greenwebpage.com/community/how-to-change-an-ip-address-on-debian-12/

#ipaddress #nmcli #nmtui #networkmanager #dhcp #manaulipaddress #debian #linuxadministration #greenwebpage

@robpumphrey

I cannot say positively that there exists someone who can *recommend* some. I can point to some, but this does not constitute a recommendation, and you'll have to do some investigation. (-:

https://packages.debian.org/sid/dibbler-server

https://packages.debian.org/sid/dhcpy6d

https://packages.debian.org/sid/kea-dhcp4-server

https://packages.debian.org/sid/kea-dhcp6-server

https://packages.debian.org/sid/udhcpd

https://packages.debian.org/sid/wide-dhcpv6-server

#DHCP #Dibbler #Kea #BusyBox

Microsoft's June Patches Unleash a Cascade of Critical Failures

#CyberSecurity #Microsoft #PatchTuesday #WindowsServer #DHCP #SysAdmin #TechNews #InfoSec #ZeroDay #Vulnerability #ITPro

https://winbuzzer.com/2025/06/18/microsofts-june-patches-unleash-a-cascade-of-critical-failures-xcxwbn/

第865回　UbuntuでDHCPサーバーを構築する（Ubuntu 24.04 LTS対応版）
https://gihyo.jp/admin/serial/01/ubuntu-recipe/0865?utm_source=feed

#gihyo #技術評論社 #gihyo_jp #技術動向 #OS #ネットワーク技術 #Ubuntu #DHCP #Kea_DHCP #Unbound #DNS

Причесываем VSCode до неприличной Yocto IDE или история одной кнопки

Идея написания этой статьи вдруг возникла у меня в начале 2025 года, когда я проснулся 2 января с тяжелой головой и вдруг понял что нужно сделать что хорошее, что то хорошее для вас, как говорит моя дочь Маргарита «для тех кто в Интернете». Как минимум мне нужен компьютерный класс на Raspberry Pi4, ну или хотя бы ферма docker(ов). Я обожаю Visual Studio Code, но мне всегда не хватает времени чтобы более детально разобраться в его огромной функциональности, в различных конфигурациях, тасках и launch(ах) описанных в формате json и я решил это обойти. Статья из серии DockerFace. Краткое содержание статьи: Выбор и настройка плагина для VSCode Запись Yocto образа на SD карту памяти Сборка Yocto образа в Docker(е) Прием Барона Мюнхгаузена для документирования bash Запуск Yocto образа RPi под виртуальной машиной Qemu Развертывание DemoMinimal образа из Yocto коробки Выписываем Buster Slim(а) для крутой разборке в Докере Настройка DHCP, TFTP и NFS сервера Загрузка core-image-minimal (wic) образа на rpi4 по сети Сетевая загрузка Raspbian для платы Raspberry Pi4 Побочный эффект сборки, загрузка ISO дистрибутива Ubuntu по сети Автоматический анализ Yocto логов с помощью Deepseek самая красивая кнопка для друзей Элвиса встраиваем кнопки в VSCode паровозиком

https://habr.com/ru/articles/899796/

#yocto_project #vscode #pxeboot #dhcp #tftp #nfs #uboot #raspberry #deepseek #openembedded

#Dnsmasq 2.91 has been released (#DNS / #AAAA / #CNAME / #PTR / #DNSSEC / #DHCP / #DHCPv4 / #DHCPv6 / #BOOTP / #TFTP / #PXE) https://thekelleys.org.uk/dnsmasq/doc.html

🆕#blog🆕

ZeroTier – domowy VPN bez publicznego adresu IP

👇👇👇👇👇
https://blog.tomaszdunia.pl/zerotier/
#️⃣#️⃣#️⃣#️⃣#️⃣
#Android #DHCP #DuckDNS #DynamicDNS #HomeAssistant #iOS #IoT #NabuCasa #NoIP #OpenVPN #SelfHosted #VPN #Wireguard #ZeroTier

… So, this happened.
Created a new Razor WebApp, and migrated all of my previous codebase into it.
Have to figure out what I want now …

#AspNetCore #DotNet #CSharp #WebDev #Proxmox #DNS #DHCP #IPAM #DDI #Kea #PowerDNS

As I was writing that last post, I might actually write code to load a table with IP records and then layer data on top of that. That table will be populated when a network is created and, if the gateway is included, that IP will be reserved right away. I'm going to need that data anyways, so I might as well have a way to manage it.

For a given IP and subnet mask, I'll be able to know all the usable IPs thanks to functions from the ip_network python library I'm using. It will be easy to add/remove the IP data when the network is created, destroyed, or the gateway is changed. Oh look, I just wrote some code for that - making this change easier.

Devices in the inventory will be able to claim 0..n IP addresses and I could even have it claim a static IP (outside any DHCP range) or association with a given DHCP range.

This has an additional benefit of being able to calculate DHCP range utilization. If a DHCP range has 10 IPs and 5 devices associated with it, it's 50% used.

#rackroot #programming #applicationdesign #backend #ipam #fastapi #webdev #homelab #dhcp

ICYMI: Ali Imran Nagori looks at the automatic installation method rolled out with Ubuntu 22.04, which borrows some tools from the cloud configuration toolbox
https://www.linux-magazine.com/Issues/2024/288/Ubuntu-autoinstall-with-cloud-init
#Ubuntu #cloud #YAML #TFTP #OpenSource #dnsmasq #DNS #DHCP #FOSS

Time for a #PowerWashing and #Chat. Today we discuss #DNS, #Resignations and #Reservations of #DHCP kind.

Join us for PowerWash and Chat with Jae and James.

#Twitch https://cwir.es/twitch

Чиним GRUB без флешки

Кажется, у каждого есть старенький ноутбук, который давно служит лишь для просмотра фильмов. У меня такой тоже есть — подключён по HDMI к телевизору и почти забыт. Однажды ради эксперимента я установил на него Linux, а через пару месяцев, когда понадобилось место, решил просто удалить линуксовый раздел. Затем я перезагрузил ноутбук и винда, конечно же, не загрузилась. После установки линукса, загрузчик GRUB переписал MBR, и теперь система не знала, откуда грузиться. Что делать? Казалось бы, всё просто: берём флешку, загружаемся с Live CD, восстанавливаем MBR. Но флешки у меня не было. Можно было бы флешку одолжить, но хотелось решить проблему здесь и сейчас. Размышляя об этом, я залез в биос и обнаружил, что ноутбук поддерживает загрузку по сети через PXE…

https://habr.com/ru/articles/857804/

#grub #linux #PXE #DHCP #tftp