DHCP3 macht Zicken

[Six]

Ähnlich diesem Problem DHCP3 und andere Betriebsysteme habe ich seit kurzem ein ähnliches Problem, nur daß sowohl MS Windows XP als auch GNU/Linux Maschinen gelegentlich keine IP beziehen.

Also, ich habe hier eine Debian Lenny Kiste, die u. a. zwei Subnetze mit IP-Adressen bedient und ein paar Clients, die zwischen diesen Subnetzen häufiger am Tag hin- und herwechseln. Das hat bis Anfang der Woche auch für GNU/Linux Maschinen geklappt. Der Ablauf ist üblicherweise so, daß der Request problemlos reinkommt, ein Angebot erfolgt, das aber nicht mehr angenommen wird.

Code: Alles auswählen

Dec 21 17:40:15 atlas dhcpd: DHCPREQUEST for 192.168.82.5 from <MAC1> via eth3
Dec 21 17:40:15 atlas dhcpd: DHCPACK on 192.168.82.5 to <MAC1> (gorgias) via eth3
Dec 21 17:40:18 atlas dhcpd: DHCPDISCOVER from <MAC2> via eth2
Dec 21 17:40:19 atlas dhcpd: DHCPOFFER on 192.168.81.5 to <MAC2> via eth2

gorgias ist mein Laptop mit ArchLinux64 und die Anfrage von MAC2 ist von einem etwas älteren Mandriva 2008 Laptop. Die letzten zwei Zeilen wiederholen sich ein paar Dutzend mal.

So, jetzt wird's richtig lustig. Stoppe und starte ich den DHCP-Dämon per Hand, so ändert sich die Situation nicht. Starte ich aber den Router neu, so funktioniert die IP Vergabe wieder problemlos.

Code: Alles auswählen

Dec 21 17:46:34 atlas dhcpd: DHCPDISCOVER from <MAC1> (gorgias) via eth3
Dec 21 17:46:35 atlas dhcpd: DHCPOFFER on 192.168.82.5 to<MAC1> (gorgias) via eth3
Dec 21 17:46:39 atlas dhcpd: DHCPREQUEST for 192.168.82.5 (192.168.82.1) from <MAC1> (gorgias) via eth3
Dec 21 17:46:39 atlas dhcpd: DHCPACK on 192.168.82.5 to <MAC1> (gorgias) via eth3
Dec 21 17:47:34 atlas dhcpd: DHCPDISCOVER from <MAC2> via eth2
Dec 21 17:47:35 atlas dhcpd: DHCPOFFER on 192.168.81.5 to <MAC2> via eth2
Dec 21 17:47:35 atlas dhcpd: DHCPREQUEST for 192.168.81.5 (192.168.81.1) from <MAC2> via eth2
Dec 21 17:47:35 atlas dhcpd: DHCPACK on 192.168.81.5 to <MAC2> via eth2

Hier noch die dhcpd.conf.
EDIT: Die zweite Subnetz-Definition ist vollständig, habe ich nur beim C&P abgeschnitten.

Und noch mehr EDIT:
/etc/network/interfaces

Code: Alles auswählen

# LAN über eth2 und eth3
auto eth2
iface eth2 inet static
        address 192.168.81.1
        network 192.168.81.0
        netmask 255.255.255.0
        broadcast 192.168.81.255

auto eth3
iface eth3 inet static
        address 192.168.82.1
        network 192.168.82.0
        netmask 255.255.255.0
        broadcast 192.168.82.255

Und: /etc/udev/rules.d/10_nic.rules

Code: Alles auswählen

# Fixiere Devices
KERNEL=="eth*",SYSFS{address}=="__:__:__:__:__:3b",NAME="eth0"
KERNEL=="eth*",SYSFS{address}=="__:__:__:__:__:20",NAME="eth2"
KERNEL=="eth*",SYSFS{address}=="__:__:__:__:__:a0",NAME="eth3"

MACs habe ich mal gestrichen

Ich habe gerade erst begonnen, mich mit dem Problem in aller Ruhe auseinander zu setzen, so daß ich auch für einfachste Hinweise dankbar bin.

[123456]

Ich habe gerade erst begonnen, mich mit dem Problem in aller Ruhe auseinander zu setzen, so daß ich auch für einfachste Hinweise dankbar bin.

ich zitier dich mal:

Starte ich aber den Router neu, so funktioniert die IP Vergabe wieder problemlos.

...und...

nur daß sowohl MS Windows XP als auch GNU/Linux Maschinen gelegentlich keine IP beziehen

Schuss ins Blaue. Firmware Update? Uups, gerade gesehen das ist ja gar kein Hardware Router...

[Six]

So, ich bin jetzt durch die anscheinend üblichen Schritte durch: authoritative, Subnetzhopping (ich benutze nun eine Leasetime von 300 bzw 600 max.), aber es ändert sich nichts.

Ich werde nun mal die Namen der Devices ändern, vielleicht kommen die sich ins Gehege. Momentan benenne ich ja eth1 in eth2 und eth2 in eth3 um.

[Danielx]

Der Ablauf ist üblicherweise so, daß der Request problemlos reinkommt, ein Angebot erfolgt, das aber nicht mehr angenommen wird.

Mich würde mal interessieren, wie das auf der Client-Seite aussieht!
Kommt das DHCPOFFER des Servers beim Clienten an, wenn ja, schickt der Client daraufhin ein DHCPREQUEST ab?

Gruß,
Daniel

[herrchen]

keine hilfe - nur ein denkanstoss:

Stoppe und starte ich den DHCP-Dämon per Hand, so ändert sich die Situation nicht. Starte ich aber den Router neu, so funktioniert die IP Vergabe wieder problemlos

das macht mich sicher, das problem *nicht* beim DHCP zu suchen.

welche dienste werden denn noch beim booten gestartet?
hast du etwas das nach "avahi", "zeroconf" oder "mDNS" riecht?

herrchen

[Six]

Danke schon mal, daß ihr mir weitere Stoßrichtungen liefert. Ich komme gerade nicht an die anderen Laptops ran, die meisten haben schon Urlaub, aber heute abend sollte das gehen. Mein Laptop hat heute noch keine Probleme gehabt, daher steht nur das Üblich im Log.

Code: Alles auswählen

Dec 22 11:35:43 [dhcpcd] eth0: dhcpcd 4.0.7 starting
Dec 22 11:35:43 [dhcpcd] eth0: waiting for carrier
Dec 22 11:35:45 [dhcpcd] eth0: carrier acquired
Dec 22 11:35:45 [dhcpcd] eth0: broadcasting for a lease
Dec 22 11:35:45 [dhcpcd] eth0: offered 192.168.82.5 from 192.168.82.1
Dec 22 11:35:45 [dhcpcd] eth0: checking 192.168.82.5 is available on attached networks
Dec 22 11:35:50 [dhcpcd] eth0: acknowledged 192.168.82.5 from 192.168.82.1
Dec 22 11:35:51 [dhcpcd] eth0: leased 192.168.82.5 for 38400 seconds

Hier ist auch mal die Liste der Prozeße auf atlas (dem Server):

Code: Alles auswählen

atlas:~# pstree
init─┬─acpid
     ├─cron
     ├─cupsd
     ├─dhcpd3
     ├─getty
     ├─inetd
     ├─klogd
     ├─3*[net.agent───sleep]
     ├─nmbd───nmbd
     ├─pppd
     ├─smbd───smbd
     ├─sshd───sshd───bash───pstree
     ├─syslogd
     └─udevd

Da scheint mir kein Kandidat dabei zu sein. Ich habe auch noch mal die IPTables geprüft, but no dice, Port 67/68 sind auf den internen Interfaces frei

[herrchen]

Hier ist auch mal die Liste der Prozeße auf atlas (dem Server):

das sieht wirklich recht aufgeräumt aus.

da hilft nur wildes raten

├─3*[net.agent───sleep]

das kommt von "udevd", oder?
hast du in deiner "interfaces" *neuerdings* ein "hotplug" drin?

herrchen

[Six]

Guter Gedanke, vielen Dank, leider scheint das nicht das Problem zu sein. Ich habe kein "hotplug" in der Interface-Konfiguration, siehe oben. So weit ich weiß ist net.agent ja auch nur der Userspace-Helper von Hotplug. Dabei ruft Hotplug zunächst modprobe auf, lädt die passenden Module und startet anschließend net.agent (ein Prozeß pro NIC), um die Einstellungen aus /etc/network/interfaces anzuwenden, oder nicht? Udev habe ich ja, wie oben beschrieben, auf die genauen Devicenames festgenagelt -- da sollten eigentlich keine Verwechslungen vorkommen.

Das ist der letzte Output. Ich kann die Kiste heute abend mal neu starten, um ein frischeres Ergebnis zu bekommen.

Code: Alles auswählen

[   11.029308] udev: renamed network interface eth1_rename to eth2
[   11.054589] udev: renamed network interface eth2 to eth3

Dieses Round-Robin-Verfahren ist suboptimal, ich weiß, aber die Schnittstellen sind aus Legacy-Gründen so benannt -- der Server hatte mal vier Schnittstellen. Vor ca. 6 Monaten haben wir eth1 stillgelegt, weil der NIC hops gegangen ist und um die Dienste nicht alle neu konfigurieren zu müssen (z. B. CUPS und Samba), haben wir halt diese Umbenennung vorgenommen. Das war allerdings noch unter Etch, das Update auf Lenny habe ich laut Log am 23.11.2008 vorgenommen.

Code: Alles auswählen

atlas:~# ifconfig -a
eth0      Link encap:Ethernet  Hardware Adresse __:__:__:__:__:3b
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX packets:1645798 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1072632 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000
          RX bytes:2443935416 (2.2 GiB)  TX bytes:84144023 (80.2 MiB)
          Interrupt:11 Basisadresse:0xe400

eth2      Link encap:Ethernet  Hardware Adresse __:__:__:__:__:20
          inet Adresse:192.168.81.1  Bcast:192.168.81.255  Maske:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX packets:11501 errors:0 dropped:0 overruns:0 frame:0
          TX packets:14697 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:223 Sendewarteschlangenlänge:1000
          RX bytes:1831549 (1.7 MiB)  TX bytes:14953779 (14.2 MiB)
          Interrupt:12 Basisadresse:0xc000

eth3      Link encap:Ethernet  Hardware Adresse  __:__:__:__:__:a0
          inet Adresse:192.168.82.1  Bcast:192.168.82.255  Maske:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX packets:1061172 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1630953 errors:4 dropped:0 overruns:0 carrier:4
          Kollisionen:0 Sendewarteschlangenlänge:1000
          RX bytes:73949226 (70.5 MiB)  TX bytes:2416107024 (2.2 GiB)
          Interrupt:10 Basisadresse:0xc400

Wie man sieht, klappt das auch. Ich bin echt ratlos.

[123456]

Das war allerdings noch unter Etch, das Update auf Lenny habe ich laut Log am 23.11.2008 vorgenommen.

Zumindest scheint es da eine zeitliche Koinzidenz mit dem Problem zu geben, oder? Darf man fragen warum der Router mit Lenny laufen muss?

[cosmac]

hi,

hier hatten wir mal einen billigen Netgear-Router rein als Access Point laufen, also seinen DHCP-Server abgeschaltet. Irgendwann hat der seine Einstellungen vergessen und dem echten DHCP-Server Konkurrenz gemacht. Das Ergebnis war kein totales Chaos, nur gelegentlich hat ein Client eine Adresse aus dem falschen Subnetz erwischt.

[Six]

Weil Lenny neuer, toller und schöner ist Eigentlich gibt es keinen bestimmten Grund, außer aktuelleres Samba und CUPS, wobei Kiste sowieso zu viele Sachen gleichzeitig macht -- mit der Zeit gewachsen, wie das halt immer so ist. Jedenfalls ist die jetzt Lenny und es gibt keinen Weg zurück.

So weit ich weiß hängt auch kein weiterer DHCP-Server in unserem Netz, deswegen fällt das vermutl. auch aus. Ich habe aber immer noch kein anderes Laptop als meines in die Finger bekommen, somit kann ich das aber nicht 100% ausschließen. Mein Laptop findet jedenfalls nichts. Naja, jetzt ist erstmal Urlaub bis zum 2. Januar, danach mehr.

[123456]

Weil Lenny neuer, toller und schöner ist Eigentlich gibt es keinen bestimmten Grund, außer aktuelleres Samba und CUPS, wobei Kiste sowieso zu viele Sachen gleichzeitig macht -- mit der Zeit gewachsen, wie das halt immer so ist. Jedenfalls ist die jetzt Lenny und es gibt keinen Weg zurück.

Ein apt-downgrade würde manchen beglücken. Meine konservative Meinung zu zentraler Infrastruktur (Server, Proxies, Router) ist, das dort nur stable werkeln sollte - mit unausweichlichen und begründeten Ausnahmen.

Interessant wäre auch die Info, ob das Neubooten der Maschine im Vergleich zum dhcpd Neustarten ein einmaliges Erfolgserlebnis war oder dies reproduzierbar ist.

[Six]

Hallo und frohes Neues, da simmer wieder...

Möglich wäre ein Downgrade via apt-pinning ja schon, aber früher oder später muß das Upgrade sowieso erfolgen. Der Reboot funktioniert reproduzierbar, deswegen haben wir heute auch angefangen, die Hardware genauer zu begucken. Am Montag mehr.