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

    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.