#dhcp — Public Fediverse posts

DHCP is the network receptionist 🏷️💻

New device joins?
DHCP hands out the IP address, gateway, DNS settings, and lease time.

The new Networking for Humans post explains automatic network configuration without acronym pain.

#Networking #DHCP #ELI5 #ITTraining #DevOps

https://webdad.eu/2026/07/16/%f0%9f%8f%b7%ef%b8%8f-dhcp-is-the-receptionist-who-hands-out-name-tags/

@rabautz ich habe erst mit #dnsmasq angefangen, wurde aber nicht warm damit. Bei weiterer Recherche kam ich auf #KeaDHCP und ich weis nicht wo ich es gelesen habe aber es wurde als neuer #DHCP Server gefeiert. Und mit Kea bin ich sehr gut klar gekommen und dabei geblieben.

#OPNsense

@rabautz ich habe erst mit #dnsmasq angefangen, wurde aber nicht warm damit. Bei weiterer Recherche kam ich auf #KeaDHCP und ich weis nicht wo ich es gelesen habe aber es wurde als neuer #DHCP Server gefeiert. Und mit Kea bin ich sehr gut klar gekommen und dabei geblieben.

#OPNsense

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.

ECI N3: Exploiting and securing communication on the Internet

Pabellón Cero + Infinito, Ciudad Universitaria, Buenos Aires, Argentina, lunes, 27 de julio, 18:00 GMT-3

Profesor

Vladimír Veselý

@[email protected]

Turno

Noche (18:00 a 21:00)

Idioma

Inglés

Descripción

During the course, participants will learn about the basic principles of computer communication security. We will explain how authentication, confidentiality and integrity are achieved using various cryptographic techniques (e.g. MD5, SHA, AES and RSA). Next, participants will learn how to communicate securely on the web, send emails and connect to WiFi networks. Furthermore, we will demonstrate the security vulnerabilities in these scenarios using freely available hacking tools.

Programa del curso

* Monday: Computer Networking and Security 101
* Tuesday: TLS/SSL and exploiting HTTP
* Wednesday: Exploiting DNS and SMTP
* Thursday: Exploiting DHCP and Wi-Fi
* Friday: Exploiting Wi-Fi and conducting MitM

https://cartelera.inexactas.ar/event/eci-n3-exploiting-and-securing-communication-on-the-internet

ECI N3: Exploiting and securing communication on the Internet

Pabellón Cero + Infinito, Ciudad Universitaria, Buenos Aires, Argentina, lunes, 27 de julio, 18:00 GMT-3

Profesor

Vladimír Veselý

@[email protected]

Turno

Noche (18:00 a 21:00)

Idioma

Inglés

Descripción

During the course, participants will learn about the basic principles of computer communication security. We will explain how authentication, confidentiality and integrity are achieved using various cryptographic techniques (e.g. MD5, SHA, AES and RSA). Next, participants will learn how to communicate securely on the web, send emails and connect to WiFi networks. Furthermore, we will demonstrate the security vulnerabilities in these scenarios using freely available hacking tools.

Programa del curso

* Monday: Computer Networking and Security 101
* Tuesday: TLS/SSL and exploiting HTTP
* Wednesday: Exploiting DNS and SMTP
* Thursday: Exploiting DHCP and Wi-Fi
* Friday: Exploiting Wi-Fi and conducting MitM

https://cartelera.inexactas.ar/event/eci-n3-exploiting-and-securing-communication-on-the-internet

ECI N3: Exploiting and securing communication on the Internet

Pabellón Cero + Infinito, Ciudad Universitaria, Buenos Aires, Argentina, lunes, 27 de julio, 18:00 GMT-3

Profesor

Vladimír Veselý

@[email protected]

Turno

Noche (18:00 a 21:00)

Idioma

Inglés

Descripción

During the course, participants will learn about the basic principles of computer communication security. We will explain how authentication, confidentiality and integrity are achieved using various cryptographic techniques (e.g. MD5, SHA, AES and RSA). Next, participants will learn how to communicate securely on the web, send emails and connect to WiFi networks. Furthermore, we will demonstrate the security vulnerabilities in these scenarios using freely available hacking tools.

Programa del curso

* Monday: Computer Networking and Security 101
* Tuesday: TLS/SSL and exploiting HTTP
* Wednesday: Exploiting DNS and SMTP
* Thursday: Exploiting DHCP and Wi-Fi
* Friday: Exploiting Wi-Fi and conducting MitM

https://cartelera.inexactas.ar/event/eci-n3-exploiting-and-securing-communication-on-the-internet

ECI N3: Exploiting and securing communication on the Internet

Pabellón Cero + Infinito, Ciudad Universitaria, Buenos Aires, Argentina, lunes, 27 de julio, 18:00 GMT-3

Profesor

Vladimír Veselý

@[email protected]

Turno

Noche (18:00 a 21:00)

Idioma

Inglés

Descripción

During the course, participants will learn about the basic principles of computer communication security. We will explain how authentication, confidentiality and integrity are achieved using various cryptographic techniques (e.g. MD5, SHA, AES and RSA). Next, participants will learn how to communicate securely on the web, send emails and connect to WiFi networks. Furthermore, we will demonstrate the security vulnerabilities in these scenarios using freely available hacking tools.

Programa del curso

* Monday: Computer Networking and Security 101
* Tuesday: TLS/SSL and exploiting HTTP
* Wednesday: Exploiting DNS and SMTP
* Thursday: Exploiting DHCP and Wi-Fi
* Friday: Exploiting Wi-Fi and conducting MitM

https://cartelera.inexactas.ar/event/eci-n3-exploiting-and-securing-communication-on-the-internet

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

Сеть вместо 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

Сеть вместо 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

Сеть вместо 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

DHCP: настройка серверов, Relay и анализ трафика в Wireshark

Приветствую! В любой сети устройства должны получать IP-адреса, шлюзы и DNS-серверы, чтобы корректно обмениваться данными и иметь доступ в Интернет. Конечно, можно настраивать всё вручную, но в реальной жизни это неудобно и часто приводит к ошибкам. На помощь приходит протокол DHCP (Dynamic Host Configuration Protocol) . Его задача проста - автоматически раздавать клиентам все необходимые сетевые параметры, включая IP, маску подсети, шлюз и DNS. В этой работе мы подробно разберём, как работает DHCP, от процесса обмена сообщениями DORA (Discover, Offer, Request, Acknowledge), через анализ сетевого трафика в Wireshark, до настройки DHCP-сервера на MikroTik и Ubuntu-Server . Мы также рассмотрим дополнительные возможности протокола, такие как DHCP Relay, который позволяет обслуживать клиентов в других подсетях.

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

#dhcp #dhcprelay #dhcpd #iscdhcpserver #mikrotik #gns3 #dhcp_server #dora #windows #ubuntuserver

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

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

So I recently used a #sledgehammer where a #scalpel was needed.

I've got an #HP DL80 Gen9 with the iLO license, but without the #FlexibleLOM card... so to access the iLO I have to have an ethernet cable plugged into the first ethernet port.

Problem is, no matter what I tried in #Webmin or #NetworkManager, every reboot would re-enable that port... which would then get a IP via DHCP (even when I'd disabled it in nm...), which would mean #Zabbix would pick it up as a client and add it.. meaning every time a disk got a little "backed up", I'd get two alerts, and this machine has 12 very old SATA drives in it.

Tired of messing with the damned thing, I finally got out the sledgehammer....
....and blacklisted HP's #OUI from the #DHCP server.

No IP, no extra client created in Zabbix, and only the normally-annoying amount of alerts.

I'll #fsck with it for real, later...

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

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

We are (again) modernizing obsolete #ISCDHCP installations. Apart from the direct successor #KeaDHCP, there are unfortunately not too many reasonably trustworthy #OSS alternatives.

A fairly unknown product in this area is the #FreeRADIUS #DHCP server.

For my part, I really like config files that are easy for humans to read as well, especially for troubleshooting purposes.

And if you compare the config files of the 3 alternatives, one can see once again how bloated #JSON is ...

We are (again) modernizing obsolete #ISCDHCP installations. Apart from the direct successor #KeaDHCP, there are unfortunately not too many reasonably trustworthy #OSS alternatives.

A fairly unknown product in this area is the #FreeRADIUS #DHCP server.

For my part, I really like config files that are easy for humans to read as well, especially for troubleshooting purposes.

And if you compare the config files of the 3 alternatives, one can see once again how bloated #JSON is ...

TunnelVision - Ny (gammal?) sårbarhet som medger avidentifiering av VPN-trafik. Läs mer på bloggen här:

https://kryptera.se/tunnelvision-ny-sarbarhet-som-medger-avidentifiering-av-vpn-trafik/

#VPN #tunnel #sårbarhet #cybersäkerhet #itsäkerhet #OpenVPN #wireguard #android #dhcp #nätverk #säkerhet

TunnelVision - Ny (gammal?) sårbarhet som medger avidentifiering av VPN-trafik. Läs mer på bloggen här:

https://kryptera.se/tunnelvision-ny-sarbarhet-som-medger-avidentifiering-av-vpn-trafik/

#VPN #tunnel #sårbarhet #cybersäkerhet #itsäkerhet #OpenVPN #wireguard #android #dhcp #nätverk #säkerhet

TunnelVision - Ny (gammal?) sårbarhet som medger avidentifiering av VPN-trafik. Läs mer på bloggen här:

https://kryptera.se/tunnelvision-ny-sarbarhet-som-medger-avidentifiering-av-vpn-trafik/

#VPN #tunnel #sårbarhet #cybersäkerhet #itsäkerhet #OpenVPN #wireguard #android #dhcp #nätverk #säkerhet

TunnelVision - Ny (gammal?) sårbarhet som medger avidentifiering av VPN-trafik. Läs mer på bloggen här:

https://kryptera.se/tunnelvision-ny-sarbarhet-som-medger-avidentifiering-av-vpn-trafik/

#VPN #tunnel #sårbarhet #cybersäkerhet #itsäkerhet #OpenVPN #wireguard #android #dhcp #nätverk #säkerhet

TunnelVision - Ny (gammal?) sårbarhet som medger avidentifiering av VPN-trafik. Läs mer på bloggen här:

https://kryptera.se/tunnelvision-ny-sarbarhet-som-medger-avidentifiering-av-vpn-trafik/

#VPN #tunnel #sårbarhet #cybersäkerhet #itsäkerhet #OpenVPN #wireguard #android #dhcp #nätverk #säkerhet

Does anyone know if it is possible to set the WORKGROUP on Windows systems using ISC-DHCPD on a Linux server? Windows network sharing sucks when everyone is on a different WORKGROUP and I'm having a hard time finding anything.

#Linux #Windows #DHCP #WORKGROUP