[gelöst] DHCP Problem in Win/Linux Dualboot Speedport W701v

[drivingsouth]

Hallo,

ich verwende ein Dualbootsystem mit Linux und Windows drauf. Leider vergibt der Speedport nur an ein Betriebsystem eine IP über dhcp. Der Name des Rechners ist unter beiden Betriebssystemen identisch, die MAC ja sowieso.

Wenn der Rechner einmal in Linux eine IP bekommen hat, bekommet er in Win dann keine mehr und umgekehrt.

Ich muß dann immer folgende Schritte durchführen, damit ich wieder eine IP bekomme:
1) multid stoppen
2) /var/flash/multid.leases löschen
3) multid starten

Meine multid.leases sieht folgendermaßen aus:
wlease 00:1B:77:41:92:26 192.168.178.41 864000 "thinkpad" ff65746831000100010e429597001b77419226

Ich habe mir mal mit wireshark unter Linux die dhcp-Anfragen angesehen, vom Speedport kommt da überhaupt keine Antwort zurück.

Wo werden denn eigentlich die vergebenen IP-Adressen verwaltet?

Kann es sein, daß sich die IP-Anforderungen von Win und Linux unterscheiden und ich daher von der Box keine IP bekomme, weil er die IP für das jeweils andere Betriebssystem schon vergeben hat?

Würde es mir weiterhelfen, wenn ich statt dem AVM-dhcp Server z.B. dnsmasq aus dem ds-mod verwenden würde?



Gruß,
drvsouth

 

[derheimi]

Die DHCP-Request von Linux und Windows unterscheiden sich ein wenig in den Optionen, die mitgesendet werden. Für Details kannst Du ja auhc mal unter Windows mit Wireshark die Requests mittracen. Das gar keine Antwort kommt ist allerdings seltsam - Du hast aber schon an die unterschiedlichen Ports für Hin- und Rückrichtung gedacht (UDP 67 und UDP 68 ) ?
Was passiert, wenn Du unter Linux testweise einen anderen Hostnamen einstellst?

Die Adressen werden in der multid.leases verwaltet, wie Du das schon herausgefunden hast.

WEnn Du dnsmasq verwendest, kannst Du im Fehlerfall wenigstens den Debuglevel hochdrehen und sehen, wie der Daemon zu dieser Sache steht, ob er die Request sieht oder ignoriert. Ob das beim mutlid geht, weiß ich nicht.

 

[kriegaex]

Multid hat zwei Debug-Optionen und einen Verbose-Schalter. Was die jeweils bewirken, habe ich nie getestet, aber als Einstieg sollte das genügen. Einfach mal multid -? aufrufen. Der Dämon kann auch im Vordergrund gestartet werden, dann kann man direkt mitlesen, was er ausgibt.

 

[drivingsouth]

An den Rechnernamen liegt es nicht, wenn ich unter jedem OS einen eigenen Rechnernamen vergebe, besteht das Problem weiterhin.
Die Einträge in mulitd.leases unterscheiden sich recht stark, je nachdem, welches OS die IP verlangt:

multid.leases mit Linux:
wlease 00:1B:77:41:92:26 192.168.178.41 844650 "thinkpad" ff65746831000100010e429597001b77419226

multid.leases mit Windows:
wlease 00:1B:77:41:92:26 192.168.178.41 864000 "thinkpad-vista" 01001b77419226

multid gibt mir folgendes aus, wenn ich multid.leases gelösch habe und dann einmal mit Linux und danach mit Windows eine IP angefordert habe:

multid: DHCPD: lan: ACK(192.168.178.41)
multid: DHCPD: lan: ACK(192.168.178.41)
multid: DHCPD: no lease found, for DHCPDISCOVER
multid: DHCPD: no lease found, for DHCPDISCOVER
multid: DHCPD: no lease found, for DHCPDISCOVER

Naja, das Problem besteht ja wohl schon länger:
http://www.ip-phone-forum.de/showthread.php?t=89939
Wobei ich aber den Eindruck habe, daß es früher (mit der Telekom Firmware) lief. In unserer alten WG waren zumindestens zwei Rechner mit Win/Linux unterwegs und es gab damals keine Probleme.

Ich werde dann mal eine Firmware mit dnsmasq bauen und probieren, ob das hilft.

gruß,
Christoph

 

[drivingsouth]

Ich habe jetzt dnsmasq installiert und den avm-eigenen dhcpserver abgeschaltet. Damit funktioniert es jetzt problemlos.

 

[hermann72pb]

Dann ändere doch bitte den Titel des Threads in "[gelöst]: SpeedportW701V ..."
Die Speedport-Bezeichnung im Titel schlage ich vor, weil das Problem bei "normalen" Fritz!Boxen kaum bekannt ist und damit dein Thema nachher besser gefunden (zugeordnet) werden kann.

Der AVM-eigener DHCP-Server ist für mich (und wahrscheinlich für die meisten hier) sowieso ein Rätsel, weil man nie sicher sein kann, wie er die leases vergibt. Es kann dir schon passieren, dass heute dein Rechner 192.168.178.21 bekommt und morgen (warum auch immer) 192.168.178.24. Und das mit dem gleichen Betriebssystem. In deinem Fall "verkomplizierst" du das Leben dem AVM-DHCP-Server mit deinen zwei Betriebssystemen weiter. Das Schlimme an der Geschichte ist, du kannst da im Normalfall nichts löschen und in keiner Weise Einfluß darauf nehmen. Deswegen nutze ich seit Ewigkeiten dnsmasq. Bei dnsmasq kannst du die IP-Adressen fest und eindeutig an die MAC-Adressen binden. Das Abschalten des AVM-internen DHCP-Servers ist übrigens nicht zwingend erforderlich, weil dnsmasq sich durch einen Hack vor dem AVM-DHCP-Server startet und ihm das Port UDP53 "klaut". Aber besser ist es ihn doch abzuschalten.

MfG

 

[kriegaex]

Ja, das ist schon seltsam. Ich verwende trotzdem kein dnsmasq, denn wenn ich schon feste Adressen an MACs binde, wozu dann überhaupt DHCP? Ich vergebe einfach feste IP-Adressen bei mir im Netz, auch für meine VMware-Maschinen. DHCP im multid lasse ich trotzdem weiter laufen, falls ich mal schnell zwischendurch eine VM anstöpseln will, die nicht ständig dieselbe Adresse braucht. Das stört gegenseitig nicht. Ich finde, man kann sich das Leben auch künstlich schwer machen.

Ergänzung: Die festen IPs haben auch den Vorteil, daß man sie direkt in die hosts und lmhosts im DS-Mod eintragen und somit eine gute Erreichbarkeit der Maschinen erzielen kann.

 

[hermann72pb]

wozu dann überhaupt DHCP?

Das ist irgendwie historisch gewachsen. Frag mich nicht, seit wann ich mir das angewöhnt hatte. Vielleicht seit LinkSys-Zeiten mit WLAN-MACs-Zuweisung. Es gibt aber -denke ich- genug leute, die das so machen.

MfG

 

[RalfFriedl]

Es gubt durchaus Gründe, DHCP mit festen Adressen zu verwenden. Unter anderem kann man über DHCP nicht nur die IP-Adresse vergeben, sondern auch etliche andere Einstellungen wie Gateway, DNS-Server, WINS-Server, NTP-Server und einiges mehr einstellen. Wenn die Clients auf DHCP eingestellt sind, kann man bei Bedarf diese Einstellungen zentral ändern.

Inwieweit man die für ein Heimnetzwerk auch so machen will, kann jeder selbst entscheiden.