Netcup DHCP Server antwortet nicht auf Discovery Requests von ipconfig.

  • Moin zusammen,


    ich habe die letzten Tage ein etwas eigenartiges Problem debugged, welches aufgetreten ist, nachdem ich meinen Debian Stretch server auf Buster upgraded habe. Dabei schlägt die Netzwerkkonfiguration während der initramfs phase des Bootprozesses fehl, da der Netcup server nicht auf Discovery Requests des verwendeten dhcp clients ipconfig antwortet.

    Hier ein paar nähere Details: Wie die meisten Linux Admins ja wissen dürften, wird im Boot Prozess ein minimalistisches filesystem, das initramfs in den Speicher geladen, um einige Schritte, wie z.B. das entschlüsseln einer LUKS Partition vorzunehmen. Netzwerkzugang wird während der Phase eher selten benötigt, aber z.B. bei PXE boots (afaik) und z.B. wenn man das initramfs mit einem dropbear ssh Server ausstattet, um per SSH den Disk Key für LUKS eingeben zu können (anstatt immer per SCP VNC verbinden zu müssen).

    Im diesem Falle wird in der Regel die Shell Funktion configure_networking im /scripts/functions Shell Script ausgeführt, welches die Kernel Options (speziell die IP option) checkt und das Netzwerkinterface entsprechend konfiguriert. Standardmäßig ist dafür DHCP eingestellt.

    Dafür verwendet die Funktion das klibc-utils tool ipconfig, welches einen minimalistischen DHCP client implementiert. Wie man den angehängten network traces entnehmen kann, antwortet zuständige Netcup DHCP Server nicht auf den Request von ipconfig. Ein anderes, minimalistisches DHCP Tool, udhcpc aus der Busybox, welches ebenfalls im initramfs zur Verfügung steht hat einen minimal anderen Request und darauf antwortet der Server.

    Es sind bei Debian und Ubuntu ein Bug bekannt gewesen, (im PXE usecase) bei dem festgestellt wurde, dass die DHCP Implementierung von ipconfig minimal falsch ist, sodass gewisse pingelige DHCP server die Antwort verweigern. der Bug wurde jedoch eigentlich längst gefixt und ich kann beim angucken des Request Packets auch nichts ungewöhnliches entdecken.



    Ein workaround ist die statische Konfiguration mittels Kernel Option IP, aber ich würde mich riesig freuen, wenn die Netcup Admins der Sache mal nachgehen könnten. In einer lokalen VM konnte antwortet der VMware DHCP Server nämlich problemlos auf das selbe Paket.


    Wer es selber mach testen möchte, kann dies auch nach dem Boot machen, das ipconfig binary liegt in /usr/lib/kblic-utils/bin (oder so).


    PS: Vielleicht kann ein Mod ja auch mal ein Sticky im Forum anlegen, dass man sein Konto im CCP verknüpfen muss, habe einen Tag auf eine Freischaltung durch einen Mod gewartet ^^..

  • Schöner Beitrag, habe wieder was neue gelernt!

    Das Forum hier wird als Nutzerforum betrieben und (leider) nicht als Supportforum. Obwohl einige Netcupmitarbeiter hier mitlesen, hast du keine Garantie darauf, dass dein Beitrag von diesen gelesen wird. Etwas bessere Chancen hat man, wenn man einen Mitarbeiter hier verlinkt, so z.B.: [netcup] Felix P.

    Wenn du eine schnellere Antwort willst, solltest du den Support direkt anschreiben. Es kann dann allerdings sein, dass du erst mal eine Standardantwort bekommst..

  • Steini danke für den Tipp! und schön, dass du aus meinem Post was lernen konntest :) Da ich mit meinem workaround aktuell ganz gut leben kann, hats mit der Aufklärung des Problems auch keine große Eile, deswegen dachte ich mache ich das mal in einem öffentlichen Forum, wo vielleicht der eine oder andere noch was Beitragen oder mitnehmen kann.


    H6G vielleicht wird sogar Broadcast traffic aktiv für die Kunden IPs gefiltert? Mich würde es dann doch noch mal jucken rauszubekommen was in Stretch anders war, dass es damals funktioniert hat oder ob die Netzwerkregeln wohl genau in dem Zeitraum umgestellt worden sind?..

  • Mal eine blöde Frage, wieso überhaupt DHCP? Sowohl IPv4 als auch IPv6 Addressen/Netze sind doch statisch den VMs zugewiesen, also sollte auch die Konfiguration entsprechender Adressen statisch sein.


    Ich habe noch nie DHCP in diesem Anwendungsfall verwendet und es wäre mir auch neu, dass Netcup oder andere Server Hoster DHCP Server betreiben. Wozu auch?



    Und wenn Debian/Ubuntu das von sich aus macht, dann ist das entweder ein Konfigurationsfehler des Administrators oder ein grober Bug.

  • Weiters sehe ich ipconfig schon seit vielen Jahren als deprecated an. Da wundert es mich auch nicht, wenn das eine defekte DHCP Client Implementierung hat.


    Zu den Unterschieden aus deinen Mitschnitten:

    ipconfig setzt scheinbar keine UDP checksum.

    ipconfig setzt auch nicht DHCP Option 61 oder Option 57 (maximum dhcp message size) fordert aber 5 zusätzliche Parameter gegenüber udhcpc an.

  • Ich habe noch nie DHCP in diesem Anwendungsfall verwendet und es wäre mir auch neu, dass Netcup oder andere Server Hoster DHCP Server betreiben. Wozu auch?


    • Installation: egal welche ISO du bootest, du kommst ohne großartige Konfiguration ins Internet, bis du ganz bequem die Konfig ändern kannst. Nicht jeder möchte im Installer gleich seine feste IP eingeben. Ist über das VNC auch manchmal nervig.
    • TFTP Server (Netboot / PXE-Boot / Rettungssystem) werden über den DHCP Server announciert. Das ist mit die einfachste Variante ein Image über das Netzwerk zu booten oder solche Geschichten wie Ubuntu MAAS zu fahren.
    • Eine Internetverbindung im initramfs oder einem frühen Kernelstadium, um z.B. Konfigurationen oder Schlüssel zu laden.

    Es gibt genügend Anwendungsfälle für DHCP.

    Und ja, Netcup betreibt einen DHCP Server, der Hoster mit H aus Falkenstein hat auch DHCP Server im Einsatz.

  • Weiters sehe ich ipconfig schon seit vielen Jahren als deprecated an. Da wundert es mich auch nicht, wenn das eine defekte DHCP Client Implementierung hat.

    ipconfig (1) hat absolut gar nichts mit ifconfig zu tun, solltest du das gerade verwechseln.


    1: https://github.com/yashdsaraf/…libc-utils/ipconfig.c.txt


    ipconfig setzt scheinbar keine UDP checksum.

    Meines Wissens nach, werden Datagramm Prüfsummen immer von Kernel angebracht, sofern dieser mit AF_INET angesprochen wird.

  • [...]nachdem ich meinen Debian Stretch server auf Buster upgraded habe. Dabei schlägt die Netzwerkkonfiguration während der initramfs phase des Bootprozesses fehl, da der Netcup server nicht auf Discovery Requests des verwendeten dhcp clients ipconfig antwortet.[...]

    Exakt dasselbe wie OrangeLynx kann ich für sämtliche von mir administrierten Server bei netcup bestätigen:

    Nach dem auf mehreren VPS- und Root-Servern über mehrere Wochen verteilten dist-upgrade von stretch auf buster (inkl. grub und initramfs) versandeten die DHCP-Requests von dropbear konsequent in Timeouts, wodurch beim Reboot dann zunächst mal nur die VNC-Konsole als Ausweg blieb.


    Heißt: Das Problem ist leider kein Einzelfall, sondern mit einem aktuellen Debian (stable) sowohl im VPS- als auch im Root-Server-Segment zuverlässig reproduzierbar.


    Daher schonmal einen Dank an die Admins, von denen vielleicht jemand etwas Zeit findet, um nachzuforschen, ob es diesbezüglich bereits Erkenntnisse oder vielleicht sogar auch eine einigermaßen leicht behebbare Ursache am DHCP-Server gibt.

    Bezüglich der von mir administrierten Server sehe ich die zuständigen DHCP-Server unter den IPv4-Adressen 46.38.225.134 und 46.38.225.234.


    Zitat

    [...]Ein workaround ist die statische Konfiguration mittels Kernel Option IP,[...]


    Das "DEVICE/IP"-Setting in "/etc/initramfs-tools/initramfs.conf" klappt bei mir merkwürdigerweise nicht, sondern initramfs fragt trotz vorhandener "DEVICE"- und "IP"-Option (und erfolgtem update-initramfs) noch per DHCP ins Netz (siehe folgende zwei Zeilen). Falls sich jemand erklären kann, wieso die nicht greifen... Danke :)

    DEVICE=ens3   # netmask: /22 (status 2019-09-25)

    IP=XXX.XXX.XXX.XXX::YYY.YYY.YYY.YYY:255.255.252.0::ens3:off::

    XXX.XXX.XXX.XXX ist hierbei die IPv4-Adresse des ens3-Interfaces am lokalen Server.

    YYY.YYY.YYY.YYY ist hierbei die IPv4-Adresse des Gateway-Hosts.


    (Bei einem anderen Provider habe ich dieses Problem merkwürdigerweise nicht, allerdings gibt es dort gar kein DHCP und die dortigen (Redundanz-)Server waren auch unter stretch schon immer fix konfiguriert.)


    p.s.

    Auch ich habe mich nach vielen Jahren nun erstmalig hier im Forum mit registriert und möchte das nutzen, um rückwirkend einfach mal "Danke!" zu sagen, dass es dieses Forum gibt und dass die netcup-Mitarbeiter hier auch hin und wieder aktiv mit antworten.

  • Hi ENOLINK,


    danke für die Bestätigung, dass es nicht nur bei mir auftritt. Ein geistesabwesender reboot meines VPS hat mich auch schlagartig daran erinnert, dass ich das Problem noch habe und bislang keine zufriedenstellende Lösung gefunden habe.


    Würde mich sehr freuen, wenn jetzt auch von offizieller Seite mal eine Stellungnahme kommen würde (Problem (an)erkannt, Lösungsvorschläge, etc.).


    Grüße,

  • Ich antworte mal eben auf meine eigene Frage, zu der ich nun (endlich) durch etwas Zufall die Ursache gefunden habe.

    Falls also noch jemand das Problem hatte, dass der Server nach dem Upgrade auf Debian 10 trotz vorhandenem DEVICE/IP-Setting im initramfs immer noch DHCP versucht (und dabei fehlschlägt), ist hier nochmal das entsprechend fragende Zitat von mir und direkt darunter die Lösung:

    Das "DEVICE/IP"-Setting in "/etc/initramfs-tools/initramfs.conf" klappt bei mir merkwürdigerweise nicht, sondern initramfs fragt trotz vorhandener "DEVICE"- und "IP"-Option (und erfolgtem update-initramfs) noch per DHCP ins Netz (siehe folgende zwei Zeilen).

    DEVICE=ens3   # netmask: /22 (status 2019-09-25)

    IP=XXX.XXX.XXX.XXX::YYY.YYY.YYY.YYY:255.255.252.0::ens3:off::

    XXX.XXX.XXX.XXX ist hierbei die IPv4-Adresse des ens3-Interfaces am lokalen Server.

    YYY.YYY.YYY.YYY ist hierbei die IPv4-Adresse des Gateway-Hosts.

    Tja, die Lösung dazu ist fast schon peinlich simpel:

    Die letzten beiden Parameter in der Zeile "IP=..." sind oben als leere Werte angegeben. Genau deshalb schlägt das ganze seit dem Buster-Upgrade fehl.
    Das ganze funktioniert sofort (wieder) problemlos, nachdem man diese beiden (leeren) Einträge mitsamt ihrer parametertrennenden Doppelpunkte komplett rausschmeißt, also statt wie oben nun so:

    IP=XXX.XXX.XXX.XXX::YYY.YYY.YYY.YYY:255.255.252.0::ens3:off


    <verbose>

    Hier noch ein paar Anmerkungen und meine eigenen Notizen zu den gesamten Parametern, vielleicht hilft das ja einem verzweifelten Suchenden als Überblick:


    Alle möglichen Parameter der "IP"-Option in "/etc/initramfs-tools/initramfs.conf" mit den jeweiligen Kommentaren darunter:

    IP=IPADDRESS:SERVERIPADDRESS:GATEWAY:NETMASK:HOSTNAME:INTERFACE:AUTOCONF:DNS1:DNS2

    Anmerkungen zu den Einzelparametern der "IP"-Option:

    IPADDRESS=IPv4-Adresse, z.B 10.10.10.10

    SERVERIPADDRESS=IPv4-Adresse des Servers, nur benötigt für NFS-Root, anderenfalls leer

    GATEWAY=IPv4-Adresse des Gateways, z.B. 10.10.10.1

    NETMASK=IPv4-Subnetzmaske, z.B. 255.255.252.0 für ein "/22"-Subnetz

    HOSTNAME=Hostname für namensbasiertes DHCP, anderenfalls leer

    INTERFACE=Name des Netzwerkinterfaces, z.B. eth0, ens1 o.ä.

    AUTOCONF=Autokonfigurations-Flag, z.B. off

    DNS1=IPv4-Adresse des ersten DNS-Servers, nur bei namensbasierte Verbindung benötigt, anderenfalls leer (bzw. komplett weglassen)

    DNS2=IPv4-Adresse des zweiten DNS-Servers, nur bei namensbasierte Verbindung benötigt, anderenfalls leer (bzw. komplett weglassen)


    Optionale Parameter am Ende kann man komplett weglassen und die meisten tun das vermutlich auch, weshalb das wohl sonst niemandem aufgefallen war.

    Ich hatte die Parameterzeile auf meinen Servern stets komplett, damit beim ersten Draufblicken schon klar ist, dass und wieviel da noch zusätzliche stehen könnte. Genau solche leeren Platzhalterparameter am Ende mag die unter Buster aktuelle Paketversion jedoch offenbar nicht mehr.

    </verbose>