Ich haben eben ein Update von Stretch auf Buster gemacht und habe nun das Problem, dass es sich scheinbar keine IP mehr via DHCP zieht.
Das einzige was instant hilft, ist, wenn ich folgendes eingebe. Danach habe ich sofort eine IP, ohne auch nur eine Sekunde warten zu müssen:
Code: Alles auswählen
dhclient ens32
Code: Alles auswählen
cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
source /etc/network/interfaces.d/*
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
allow-hotplug ens32
iface ens32 inet dhcp
Code: Alles auswählen
ifconfig
ens32: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::211:22ff:fe33:4455 prefixlen 64 scopeid 0x20<link>
ether 00:11:22:33:44:55 txqueuelen 1000 (Ethernet)
RX packets 53 bytes 3180 (3.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 11 bytes 1682 (1.6 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Code: Alles auswählen
# /var/log/syslog
Jul 9 09:01:24 SomeHost dhclient[482]: DHCPDISCOVER on ens32 to 255.255.255.255 port 67 interval 20
Jul 9 09:01:24 SomeHost sh[459]: DHCPDISCOVER on ens32 to 255.255.255.255 port 67 interval 20
Jul 9 09:01:44 SomeHost dhclient[482]: DHCPDISCOVER on ens32 to 255.255.255.255 port 67 interval 11
Jul 9 09:01:44 SomeHost sh[459]: DHCPDISCOVER on ens32 to 255.255.255.255 port 67 interval 11
Jul 9 09:01:55 SomeHost dhclient[482]: DHCPDISCOVER on ens32 to 255.255.255.255 port 67 interval 11
Jul 9 09:01:55 SomeHost sh[459]: DHCPDISCOVER on ens32 to 255.255.255.255 port 67 interval 11
Jul 9 09:02:06 SomeHost dhclient[482]: No DHCPOFFERS received.
Jul 9 09:02:06 SomeHost sh[459]: No DHCPOFFERS received.
Jul 9 09:02:06 SomeHost sh[459]: No working leases in persistent database - sleeping.
Jul 9 09:02:06 SomeHost dhclient[482]: No working leases in persistent database - sleeping.
Jul 9 09:02:06 SomeHost sh[459]: ens32=ens32
Code: Alles auswählen
ifdown ens32 && ifup ens32
Killed old client process
Internet Systems Consortium DHCP Client 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/ens32/00:11:22:33:44:55
Sending on LPF/ens32/00:11:22:33:44:55
Sending on Socket/fallback
DHCPRELEASE of 192.168.1.60 on ens32 to 192.168.1.1 port 67
send_packet: Network is unreachable
send_packet: please consult README file regarding broadcast address.
dhclient.c:2878: Failed to send 300 byte long packet over fallback interface.
Internet Systems Consortium DHCP Client 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/ens32/00:11:22:33:44:55
Sending on LPF/ens32/00:11:22:33:44:55
Sending on Socket/fallback
DHCPDISCOVER on ens32 to 255.255.255.255 port 67 interval 6
DHCPDISCOVER on ens32 to 255.255.255.255 port 67 interval 10
DHCPDISCOVER on ens32 to 255.255.255.255 port 67 interval 15
DHCPDISCOVER on ens32 to 255.255.255.255 port 67 interval 17
DHCPDISCOVER on ens32 to 255.255.255.255 port 67 interval 12
No DHCPOFFERS received.
No working leases in persistent database - sleeping.
Ich könnte natürlich einfach versuchen in der "/etc/network/interfaces" ein "post-up dhclient ens32" hinzufügen. Das hilft vielleicht, aber das wäre ja nur ein Workaround.
EDIT:
McBane87 hat geschrieben:09.07.2019 13:25:00Nur mal noch so als Info nebenbei.
Ich habe jetzt ein komplett frisches Debian Buster mithilfe der Netinst-ISO installiert.
Das installieren hat wunderbar funktioniert. Es gab eine Adresse via DHCP und alles lief.
Sobald die Installation fertig war und das System durchgebootet hatte, habe ich nun aber das gleiche Problem wie oben beschrieben. Irghendwas ist an Buster kaputt....
Ich möchte der Vollständigkeithalber noch erwähnen dass wir uns in deiner VSphere VM-Umgebung befinden. Das erschien mir Anfangs noch nicht wichtig. Aber vielleicht ist die Info ja doch relevant.
McBane87 hat geschrieben:10.07.2019 09:59:00Weitere Erkenntnisse:
Wenn ich mir die Binary /sbin/ifup vom alten Debian Stretch zum neuen Debian Buster kopiere bzw. die vorhandene ersetze und dann noch ein "auto ens32" ins /etc/network/interfaces schreibe. Dann klappt auch wieder alles problemlos mit DHCP. (Ohne das "auto ens32" würde die alte ifup Version das interface nicht starten im Gegensatz zur neueren Version.)
Ich konnte die Kollegen vom DHCP befragen. In den Logs ist zu sehen, dass das ifup von Buster eine andere CID zum DHCP übermittelt. Erwarten würde der DHCP soetwas:
"01:00:11:22:33:44:55:" als CID. Bekommen tut er aber das hier mit der neueren Version von ifup: "ff:22:33:44:55:00:01:00:01:24:b7:2f:8e:00:11:22:33:44:55:". Und aus diesem Grund bekommt der Client dann auch keine IP. Er wird nicht als authorisiertes System erkannt! => "could not offer an address: no permitted ranges available"
(Da ich die MAC Adressen abgeändert habe und die Logik hinter der langen CID nicht ganz verstehe, kann es sein, dass sie für Wissende jetzt keinen Sinn mehr ergibt nachdem ich sie abgeändert habe, aber das Prinzip sollte trotzdem klar sein. Es wird eine viel längere CID übermittelt)
Fragt sich natürlich, wie kann ich Buster abgewöhnen die CID so zu "verschlimmbessern" ?
McBane87 hat geschrieben:10.07.2019 13:14:29Das Ursache des Problems habe ich mittlerweile gefunden. Das ifupdown Paket setzt seit Version 0.8.35 auf DUID beim dhclient. Es ruft den dhclient also mit der Option "-i" auf. Damit kann unser Netzwerk bzw. DHCP Umgebung aber nicht umgehen. Und wenn ich die Source richtig deute, dann ist die Option "-i" auch noch hardcoded, sodass man keine Wahl mehr hat. Außer man deinstalliert den dhclient und nutz einen anderen Client wie zum Beispiel pump.
McBane87 hat geschrieben:10.07.2019 15:55:33Mein aktueller Workaround bleibt einfach das Paket in dem dhclient vorkommt zu deinstallieren und dafür einen anderen DHCP-Client zu installieren. Denn ifupdown prüft nach einer festen Reihenfolge verschiedenen DHCP-Clients auf existenz und nutzt den erstbesten. Wenn dhclient also nciht da ist, dann wird ein anderer, der vorhande ist, genommen. Somit sollte ich auch bei zukünftigen Updates der Pakete relativ sicher fahren.