20
Mikrotik DHCP bekommt keine Anfrage von älteren Clients
Nochmals hallo zusammen,
nachdem ich mit der Hilfe aus dem Forum hier fast mein gesamtes Netz auf einen MT RB5009 migriert habe, stehe ich vor einem seltsamen Phänomen.
Schließe ich einen Laptop an einen Port an, der auf ein bestimmtes VLAN gebunden ist (VLAN 30), bekomme ich eine DHCP-Anfrage auf dem passenden DCHP-Server (dhcp30) und es wird eine Lease vergeben, alles prima.
Schließe ich jedoch ältere Hardware an denselben Port an, die ebenfalls DHCP Clients sind, bekomme ich keine Anfragen. Schließe ich dieselbe Hardware jedoch an meine FritzBox an, bekommen die Geräte eine IP.
Es handelt sich um einen D-Link DP-301 Printserver (für Parallelport, für die älteren unter uns ;) und eine älteres IP-Übertragungsgerät einer Einbruchmeldeanlage).
Hat jemand eine Idee, wo ich weitersuchen könnte? Debugging auf dem dhcp des MT liefert wie gesagt keine Anfragen.
nachdem ich mit der Hilfe aus dem Forum hier fast mein gesamtes Netz auf einen MT RB5009 migriert habe, stehe ich vor einem seltsamen Phänomen.
Schließe ich einen Laptop an einen Port an, der auf ein bestimmtes VLAN gebunden ist (VLAN 30), bekomme ich eine DHCP-Anfrage auf dem passenden DCHP-Server (dhcp30) und es wird eine Lease vergeben, alles prima.
Schließe ich jedoch ältere Hardware an denselben Port an, die ebenfalls DHCP Clients sind, bekomme ich keine Anfragen. Schließe ich dieselbe Hardware jedoch an meine FritzBox an, bekommen die Geräte eine IP.
Es handelt sich um einen D-Link DP-301 Printserver (für Parallelport, für die älteren unter uns ;) und eine älteres IP-Übertragungsgerät einer Einbruchmeldeanlage).
Hat jemand eine Idee, wo ich weitersuchen könnte? Debugging auf dem dhcp des MT liefert wie gesagt keine Anfragen.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 13335136647
Url: https://administrator.de/forum/mikrotik-dhcp-bekommt-keine-anfrage-von-aelteren-clients-13335136647.html
Ausgedruckt am: 22.12.2024 um 17:12 Uhr
20 Kommentare
Neuester Kommentar
Was meinst du mit Debugging genau?? Hast du mit dem Torch Tool auf dem MT geprüft ob du die DHCP Requests sehen kannst?
Wenn dort gar keine DHCP Requests kommen, dann hat das 2 Gründe:
Ideal wäre auch gewesen du hättest beide DHCP Requests einmal mit dem Wireshark mitgeschnitten und nach Unterschieden gesucht. So kann man leider nur mit dir mitraten...
Wenn dort gar keine DHCP Requests kommen, dann hat das 2 Gründe:
- Das Gerät sendet gar keine DHCP Requests
- Du hast einen Fehler in deinem VLAN bzw. PVID Setup gemacht
Ideal wäre auch gewesen du hättest beide DHCP Requests einmal mit dem Wireshark mitgeschnitten und nach Unterschieden gesucht. So kann man leider nur mit dir mitraten...
Moin,
vielleicht haben die älteren Geräte auch ein Autonegotiation-Problem mit dem Mikrotik, der D-Link Printserver kann max. Fast-Ethernet (10/100 Mbit) das Meldegerät vielleicht sogar nur 10 Mbit?
Vielleicht kommt gar kein richtiger Link zustande. Entweder mal testweise einen Fast-Ethernet Switch dazwischenschalten oder den Port des Mikrotik mal fest einstellen.
Gruß
cykes
vielleicht haben die älteren Geräte auch ein Autonegotiation-Problem mit dem Mikrotik, der D-Link Printserver kann max. Fast-Ethernet (10/100 Mbit) das Meldegerät vielleicht sogar nur 10 Mbit?
Vielleicht kommt gar kein richtiger Link zustande. Entweder mal testweise einen Fast-Ethernet Switch dazwischenschalten oder den Port des Mikrotik mal fest einstellen.
Gruß
cykes
1ein Autonegotiation-Problem mit dem Mikrotik
Dafür spräche was der TO sagt, das z.B. Torch usw. keinen eingehenden DHCP Request zeigt!Wenn dem so ist macht es Sinn den Anschlussport dieses Printservers im Interface Setting des MT einmal statisch (Haken bei Autonegotiation entfernen) fest auf 10 oder 100 Mbit zu setzen je nachdem was der max. kann.
So, vielen Dank für die vielen Tipps.
Mit Debugging auf dem MT meinte ich System/Logging/Topics/dhcp. Dort sind keine passenden Anfragen auf dem passenden VLAN-DHCP-Server zu sehen.
Mit Wireshark konnte ich mittels Sniffer Pakete loggen, sowohl mit Auto-Negotiate, als auch mit fix eingestellter Geschwindigkeit.
Folgende Anfragen konnte ich sehen (STP, IPX ist weggefiltert)
Sagt mir als Laien nicht viel, aber das NAK in #25 scheint mir seltsam zu sein. Kann das ein Kenner interpretieren?
Mit Debugging auf dem MT meinte ich System/Logging/Topics/dhcp. Dort sind keine passenden Anfragen auf dem passenden VLAN-DHCP-Server zu sehen.
Mit Wireshark konnte ich mittels Sniffer Pakete loggen, sowohl mit Auto-Negotiate, als auch mit fix eingestellter Geschwindigkeit.
Folgende Anfragen konnte ich sehen (STP, IPX ist weggefiltert)
No. Time Source Destination Protocol Length Info
16 13.875554997 D-LinkAl_d2:98:51 NETBIOS- NetBIOS 109 Add Name Query - PRINTER<20>
17 13.880088982 0.0.0.0 255.255.255.255 DHCP 637 DHCP Discover - Transaction ID 0x1000000
18 13.914414993 0.0.0.0 255.255.255.255 DHCP 645 DHCP Discover - Transaction ID 0x1000000
19 14.179653834 78:9a:18:39:3f:0e Broadcast ARP 93 Who has 192.168.20.7? Tell 192.168.20.1
20 14.180490633 78:9a:18:39:3f:0e Broadcast ARP 93 Who has 192.168.20.7? Tell 192.168.20.1
22 14.464289048 D-LinkAl_d2:98:51 NETBIOS- NetBIOS 109 Add Name Query - PRINTER<20>
23 14.683043449 192.168.20.1 255.255.255.255 DHCP 393 DHCP Offer - Transaction ID 0x1000000
24 15.075646145 192.168.20.7 255.255.255.255 DHCP 637 DHCP Request - Transaction ID 0x3000000
25 15.076780559 192.168.20.1 255.255.255.255 DHCP 393 DHCP NAK - Transaction ID 0x3000000
26 15.077193828 D-LinkAl_d2:98:51 NETBIOS- NetBIOS 109 Add Name Query - PRINTER<03>
27 15.080417566 192.168.20.7 255.255.255.255 DHCP 645 DHCP Request - Transaction ID 0x3000000
28 15.241950826 78:9a:18:39:3f:0e Broadcast ARP 93 Who has 192.168.20.7? Tell 192.168.20.1
29 15.243786663 D-LinkAl_d2:98:51 78:9a:18:39:3f:0e ARP 107 192.168.20.7 is at 00:80:c8:d2:98:51
30 15.243865530 192.168.20.1 192.168.20.7 ICMP 121 Echo (ping) request id=0x9e18, seq=256/1, ttl=255 (reply in 31)
31 15.246373853 192.168.20.7 192.168.20.1 ICMP 117 Echo (ping) reply id=0x9e18, seq=256/1, ttl=255 (request in 30)
32 15.674534927 D-LinkAl_d2:98:51 NETBIOS- NetBIOS 109 Add Name Query - PRINTER<03>
33 16.280658558 D-LinkAl_d2:98:51 NETBIOS- NetBIOS 109 Add Name Query - PRINTER<00>
35 16.884365469 D-LinkAl_d2:98:51 NETBIOS- NetBIOS 109 Add Name Query - PRINTER<00>
36 17.494335478 D-LinkAl_d2:98:51 NETBIOS- BROWSER 227 Host Announcement PRINTER, Workstation, Server, Domain Member Server, Print Queue Server
37 17.495824486 D-LinkAl_d2:98:51 NETBIOS- BROWSER 227 Host Announcement PRINTER, Workstation, Server, Domain Member Server, Print Queue Server
38 17.497517410 D-LinkAl_d2:98:51 NETBIOS- BROWSER 227 Host Announcement PRINTER, Workstation, Server, Domain Member Server, Print Queue Server
39 17.500384470 D-LinkAl_d2:98:51 AppleTalk-broadcast-address AARP 107 Is there a 61184.19
40 17.709685370 D-LinkAl_d2:98:51 AppleTalk-broadcast-address AARP 107 Is there a 61184.19
41 17.929629448 D-LinkAl_d2:98:51 AppleTalk-broadcast-address AARP 107 Is there a 61184.19
42 18.149618444 D-LinkAl_d2:98:51 AppleTalk-broadcast-address AARP 107 Is there a 61184.19
43 18.369752183 D-LinkAl_d2:98:51 AppleTalk-broadcast-address AARP 107 Is there a 61184.19
45 18.589451972 D-LinkAl_d2:98:51 AppleTalk-broadcast-address AARP 107 Is there a 61184.19
46 18.809594818 D-LinkAl_d2:98:51 AppleTalk-broadcast-address AARP 107 Is there a 61184.19
47 19.029640161 D-LinkAl_d2:98:51 AppleTalk-broadcast-address AARP 107 Is there a 61184.19
48 19.249605045 D-LinkAl_d2:98:51 AppleTalk-broadcast-address AARP 107 Is there a 61184.19
49 19.469468546 D-LinkAl_d2:98:51 AppleTalk-broadcast-address AARP 107 Is there a 61184.19
50 19.689991682 ef00.13 0000.ff ZIP 107 GetNetInfo request
51 20.239572200 ef00.13 0000.ff ZIP 107 GetNetInfo request
53 20.789540816 ef00.13 0000.ff ZIP 107 GetNetInfo request
54 21.344116376 ef00.13 0000.ff NBP 189 Op: lookup Count: 1
55 21.889942401 ef00.13 0000.ff NBP 189 Op: lookup Count: 1
56 22.439660802 ef00.13 0000.ff NBP 189 Op: lookup Count: 1
73 28.823678359 192.168.20.7 255.255.255.255 DHCP 637 DHCP Discover - Transaction ID 0x1000000
74 28.824664185 192.168.20.7 255.255.255.255 DHCP 645 DHCP Discover - Transaction ID 0x1000000
75 28.826809445 78:9a:18:39:3f:0e Broadcast ARP 93 Who has 192.168.20.7? Tell 192.168.20.1
76 28.826876797 192.168.20.1 192.168.20.7 ICMP 121 Echo (ping) request id=0x9e18, seq=768/3, ttl=255 (reply in 78)
77 28.828876107 D-LinkAl_d2:98:51 78:9a:18:39:3f:0e ARP 107 192.168.20.7 is at 00:80:c8:d2:98:51
78 28.830792428 192.168.20.7 192.168.20.1 ICMP 117 Echo (ping) reply id=0x9e18, seq=768/3, ttl=255 (request in 76)
94 36.051822722 0.0.0.0 255.255.255.255 MNDP 251 5678 → 5678 Len=162
95 36.051922293 78:9a:18:39:3f:0e CDP/VTP/DTP/PAgP/UDLD CDP 167 Device ID: MikroTik Port ID: vlan-bridge/ether2
96 36.051992226 78:9a:18:39:3f:0e LLDP_Multicast LLDP 208 MA/f2:44:89:2c:32:47 IN/vlan-bridge/ether2 120 SysN=MikroTik SysD=MikroTik RouterOS 7.11.2 (stable) Aug/31/2023 13:55:47 RB5009UPr+S+
97 36.057317099 fe80::7a9a:18ff:fe39:3f0e ff02::1 MNDP 271 5678 → 5678 Len=158
98 36.057381484 192.168.20.1 255.255.255.255 MNDP 251 5678 → 5678 Len=158
99 36.057430568 78:9a:18:39:3f:0e CDP/VTP/DTP/PAgP/UDLD CDP 176 Device ID: MikroTik Port ID: vlan20
100 36.057511380 78:9a:18:39:3f:0e LLDP_Multicast LLDP 214 MA/f2:44:89:2c:32:47 IN/vlan20 120 SysN=MikroTik SysD=MikroTik RouterOS 7.11.2 (stable) Aug/31/2023 13:55:47 RB5009UPr+S+
113 43.674805508 192.168.20.7 255.255.255.255 DHCP 637 DHCP Discover - Transaction ID 0x1000000
114 43.675802339 192.168.20.7 255.255.255.255 DHCP 645 DHCP Discover - Transaction ID 0x1000000
115 43.863114951 78:9a:18:39:3f:0e Broadcast ARP 93 Who has 192.168.20.26? Tell 192.168.20.1
116 43.863653648 78:9a:18:39:3f:0e Broadcast ARP 93 Who has 192.168.20.26? Tell 192.168.20.1
117 44.365317478 192.168.20.1 255.255.255.255 DHCP 393 DHCP Offer - Transaction ID 0x1000000
118 44.374693322 192.168.20.26 255.255.255.255 DHCP 637 DHCP Request - Transaction ID 0x3000000
119 44.376113432 192.168.20.1 255.255.255.255 DHCP 393 DHCP NAK - Transaction ID 0x3000000
120 44.376166930 192.168.20.26 255.255.255.255 DHCP 645 DHCP Request - Transaction ID 0x3000000
122 44.921799845 78:9a:18:39:3f:0e Broadcast ARP 93 Who has 192.168.20.26? Tell 192.168.20.1
123 44.923651452 D-LinkAl_d2:98:51 78:9a:18:39:3f:0e ARP 107 192.168.20.26 is at 00:80:c8:d2:98:51
124 44.923651670 192.168.20.1 192.168.20.26 ICMP 121 Echo (ping) request id=0xa218, seq=256/1, ttl=255 (reply in 125)
125 44.926227536 192.168.20.26 192.168.20.1 ICMP 117 Echo (ping) reply id=0xa218, seq=256/1, ttl=255 (request in 124)Sagt mir als Laien nicht viel, aber das NAK in #25 scheint mir seltsam zu sein. Kann das ein Kenner interpretieren?
(STP, IPX ist weggefiltert)
Was soll denn IPX sein?? Novell ist schon seit Jahrzehnten mausetot. Sinnvoll wäre gewesen einen Capture Filter auf UDP 67 und 68 zu setzen um nur DHCP Frames zu bekommen.Die .20.7 ist das der Printserver??
Leider hast du keinerlei Angaben zur Mac Adresse gemacht so das man nicht sicher sagen kann von wem der Request kommt.
Sicher ist aber das der DHCP Server dem Anfragenden die .20.7 zuteilt und die auch mit einem Ping Check überprüft.
Leider aber alles wild geraten weil...
- Der Request mit einer 0.0.0.0 IP kommt und daraus die Mac Adresse des Printservers nicht ersichtlich ist
- Mit den dann folgenden Offer wird nur die IP Adresse gezeigt und du hast es versäumt im Layer 2 die Mac Adresse sichtbar zu machen.
Unter diesen Umständen können auch wir nur im Trüben stochern und wild Kristallkugeln.
Gleiches gilt für das Endgerät unten was die .20.26 bekommt.
Siehst du irgendwas in den DHCP Leases im Mikrotik?
Was sagt ein Torch Sniffern auf UDP 67 und 68?
Ok, nochmal das Ganze mit Screenshot und MAC Adresse. 00:80:c8:d2:98:51 ist der Printserver.
Torch auf ether2 mit den Ports 67 + 68
Auf dem MT ist in den DHCP Leases nichts zu sehen, einmal war ganz kurz eine Zeile mit dem Interface ether2, MAC des Printservers, der .20.7 IP und Status conflict zu sehen, aber sehr schnell wieder weg und auch nicht durch Neustart des Printservers reproduzierbar.
Torch auf ether2 mit den Ports 67 + 68
Auf dem MT ist in den DHCP Leases nichts zu sehen, einmal war ganz kurz eine Zeile mit dem Interface ether2, MAC des Printservers, der .20.7 IP und Status conflict zu sehen, aber sehr schnell wieder weg und auch nicht durch Neustart des Printservers reproduzierbar.
Moin,
auch nur wild geraten, aber Du hattest in Deiner Eingangsfrage geschrieben, dass der Port des MT (ether2?), an dem Du den Printserver bzw. das Meldegerät anschliesst, an VLAN 30 gebunden ist, die Anfragen/Antworten scheinen aber laut Trace aus/an VLAN 20 zu kommen - kann das vielleicht das Problem sein?
Gruß
cykes
auch nur wild geraten, aber Du hattest in Deiner Eingangsfrage geschrieben, dass der Port des MT (ether2?), an dem Du den Printserver bzw. das Meldegerät anschliesst, an VLAN 30 gebunden ist, die Anfragen/Antworten scheinen aber laut Trace aus/an VLAN 20 zu kommen - kann das vielleicht das Problem sein?
Gruß
cykes
Ah, mein Fehler. Ich hatte ether2 danach ins VLAN20 gehängt, da es eingangs der einzige Client in VLAN30 war und ich ausschließen wollte, dass VLAN30 an sich fehlkonfiguriert ist.
In Vlan20 hängen mehrere funktionierende Clients, die auch an ether2 per Dhcp eine IP bekommen.
In Vlan20 hängen mehrere funktionierende Clients, die auch an ether2 per Dhcp eine IP bekommen.
Torch auf ether2 mit den Ports 67 + 68
Das ist leider fehlerhaft, denn du snifferst, wie man am Screeshot sieht leider immer getrennt nur nach Port 67 oder nur 68. Du hättest am Port Fenster einfach auf den "Pfeil nach unten" klicken sollen und zusätzlich noch 68 eintragen müssen um beides Request und Reply in einem Torch zu sehen!!
Man kann aber sehen das zum Request auch ein Reply kommt und der Printserver die .20.26 erhält, denn die Layer 2 Mac Adresse korrespondiert zu dieser IP!!
Damit pingt der Printserver ja sogar den Mikrotik. Er bekommt also eine gültige IP vom Server und nutzt diese auch. Die .20.26 müsste auch in den DHCP Leases im MT auftauchen und von allen anderen Geräten pingbar sein. Die Bindung seiner Mac Adresse an die .20.26 ist da eindeutig.
Nebenbei:
Hast du einmal gecheckt ob es beim Hersteller des Printservers ggf. eine neuere, aktuellere Firmware Version gibt als die die du derzeit verwendest?
Falls ja solltest du den PS in jedem Falle updaten.
Du hättest am Port Fenster einfach auf den "Pfeil nach unten" klicken sollen
Geht leider beim Torch nicht in der Winbox, bei anderen Fenstern schon.
Folgendes Verhalten scheint reproduzierbar zu sein
- Der Printserver stellt tatsächlich eine DHCP Anfrage (DISCOVER)
- Es wird auch ein Angebot vom DHCP Server gemacht (OFFER)
- Der Printserver macht von der angebotenen Adresse ein REQUEST
- Der DHCP Server antwortet NAK
Das Ganze passiert nur 2x. In der ARP Liste sehe ich
aber unter DHCP steht ein Konflikt
Entferne ich den Lease mit dem Konflikt manuell, kann ich dem Printserver unter der 2. angebotenen Adresse (hier.20.30) erreichen.
Der Printserver stellt allerdings nach dem 2. Versuch auf manuelles IP Assignment zurück und stellt keine weiteren DHCP Anfragen, daher war das schwierig zu reproduzieren.
Stelle ich den Printserver auf DHCP zurück, kann man das Spielchen von vorne betrachten.
Könnte es evtl. für die erfolgreiche Vergabe der Leases problematisch sein, dass die Systemzeiten vom DHCP Server und dem Printserver abweichen?
Da stimmt ggf. etwas mit dem Pool bzw. den Ranges in dem Pool nicht das den Server zwingt mit einem NAK zu antworten?
Kann es sein das du da für das VLAN 20 einen Tippfehler begangen hast was die Maske oder die Ranges anbetrifft?
Sie dazu auch HIER.
Checke zu den Masken des Pools auch nochmal die Maske des VLAN 20 IP Interfaces. Da darf es keinerlei Unterschiede geben!
An den zeiten kann es nicht liegen denn DHCP kennt keine Uhrzeiten. Lediglich die Lease Time die aber einzig nur für den Server relevant ist.
Kann es sein das du da für das VLAN 20 einen Tippfehler begangen hast was die Maske oder die Ranges anbetrifft?
Sie dazu auch HIER.
Checke zu den Masken des Pools auch nochmal die Maske des VLAN 20 IP Interfaces. Da darf es keinerlei Unterschiede geben!
An den zeiten kann es nicht liegen denn DHCP kennt keine Uhrzeiten. Lediglich die Lease Time die aber einzig nur für den Server relevant ist.
Ich habe das anhand des Links oben nochmal kontrolliert, kann aber keine Abweichung feststellen. Ich setze zwar zusätzlich 2 DHCP Options, aber es geht auch ohne nicht.
Just for Info aus der MS Knowledgebase:
"Both Windows and MacOS does not use DHCP option 15 for domain search when DHCP option 119 is provided. "
Macht also wenig Sinn das zusammen zu setzen....
Hast du testweise die Options mal deaktiviert oder den PS mal in ein Segment gehängt wo der DHCP Server diese Options NICHT verwendet??
Da die Fritzbox ja auch keinerlei Options im DHCP Server supportet wäre das ggf. Wert einmal auszutesten ob diese Options den PS ggf. ins Straucheln bringen.
"Both Windows and MacOS does not use DHCP option 15 for domain search when DHCP option 119 is provided. "
Macht also wenig Sinn das zusammen zu setzen....
Hast du testweise die Options mal deaktiviert oder den PS mal in ein Segment gehängt wo der DHCP Server diese Options NICHT verwendet??
Da die Fritzbox ja auch keinerlei Options im DHCP Server supportet wäre das ggf. Wert einmal auszutesten ob diese Options den PS ggf. ins Straucheln bringen.
Moin.
Die aktuellen Mikrotik-Firmwares haben ein Problem das sie alte ARP-Einträge nicht korrekt nach der Ablaufzeit von 30 Sekunden (Default) "flushen" wenn das Gerät nicht mehr antwortet und so Konflikte entstehen können. Es bleiben also alte Einträge darin hängen. Das kannst du momentan entweder durch ein Mikrotik-Skript beheben das man regelmäßig durchlaufen lässt und verwaiste Einträge aus der ARP-Tabelle entfernt, oder du setzt im DHCP-Server die folgende Option:
Dann werden die ARP-Entries durch den DHCP-Server selbst angelegt und auch wieder zuverlässig entfernt sobald die DHCP-Lease für die MAC abgelaufen ist.
Vorher bitte sämtliche alten Einträge zur MAC aus der ARP Tabelle löschen.
Wenn du in dem VLAN keine statisch konfigurierten Clients hast kannst du auf dem Interface auch ARP deaktivieren und wenn du o.g. Option setzt. Dann können nur noch DHCP-Clients miteinander kommunizieren, oder wenn man statisch konfigurierte Clients manuell in die ARP Tabelle einträgt.
Gruß sid
Die aktuellen Mikrotik-Firmwares haben ein Problem das sie alte ARP-Einträge nicht korrekt nach der Ablaufzeit von 30 Sekunden (Default) "flushen" wenn das Gerät nicht mehr antwortet und so Konflikte entstehen können. Es bleiben also alte Einträge darin hängen. Das kannst du momentan entweder durch ein Mikrotik-Skript beheben das man regelmäßig durchlaufen lässt und verwaiste Einträge aus der ARP-Tabelle entfernt, oder du setzt im DHCP-Server die folgende Option:
Dann werden die ARP-Entries durch den DHCP-Server selbst angelegt und auch wieder zuverlässig entfernt sobald die DHCP-Lease für die MAC abgelaufen ist.
Vorher bitte sämtliche alten Einträge zur MAC aus der ARP Tabelle löschen.
Wenn du in dem VLAN keine statisch konfigurierten Clients hast kannst du auf dem Interface auch ARP deaktivieren und wenn du o.g. Option setzt. Dann können nur noch DHCP-Clients miteinander kommunizieren, oder wenn man statisch konfigurierte Clients manuell in die ARP Tabelle einträgt.
Gruß sid
1"Both Windows and MacOS does not use DHCP option 15 for domain search when DHCP option 119 is provided. "
Hatte ich auch gesehen, aber Linux ist nicht direkt erwähnt (Ubuntu & Fedora Clients im Netz), daher erstmal beides drin.Hast du testweise die Options mal deaktiviert oder den PS mal in ein Segment gehängt wo der DHCP Server diese Options NICHT verwendet??
Ja, im Nebensatz oben erwähnt. Sowohl auf VLAN20 mal abgeschaltet als auch ein neues VLAN kreiert ohne die Options.@7907292512
Habe ich gerade erfolglos versucht, es werden ARP-Einträge für die 2 DHCP-Versuche erzeugt (wurden ohne Haken auch), aber die Lease bleibt auf conflict stehen.
Das ist nicht definitiv nicht normal. Vermutlich die Mikrotik-Config nicht mehr konsistent. Würde das Teil erst mal komplett zurücksetzen und neu clean starten.
Gerät mit doppelter MAC im Netz die dir da einen Streich spielt?
Und nimm mal testweise die Conflict-Detection raus.
Welche RouterOS Firmware geflasht?
Gerät mit doppelter MAC im Netz die dir da einen Streich spielt?
Und nimm mal testweise die Conflict-Detection raus.
Welche RouterOS Firmware geflasht?
RouterOS ist 7.11.2 (stable)
Geräte mit doppelter MAC sind nicht im Netz
Ohne Conflict Detection bleibt die Lease ein paar Sekunden im Status offered und verschwindet dann wieder.
Komplett-Reset wäre nur die allerletzte Lösung und geht nur, wenn ich alleine zu Hause bin. Da das bereits in Betrieb ist der WAF ohne Internet eher gering. ;)
Im Notfall bekommt der Printserver eben eine statische IP oder wandert auf den Müll.
Wie sind eure Regeln hier: Für ein (vermutlich) anderes DHCP-Problem mit einem anderen Endgerät (sendet DISCOVER ohne end-option) eröffne ich einen neuen Thread? Oder derselbe?
Geräte mit doppelter MAC sind nicht im Netz
Ohne Conflict Detection bleibt die Lease ein paar Sekunden im Status offered und verschwindet dann wieder.
Komplett-Reset wäre nur die allerletzte Lösung und geht nur, wenn ich alleine zu Hause bin. Da das bereits in Betrieb ist der WAF ohne Internet eher gering. ;)
Im Notfall bekommt der Printserver eben eine statische IP oder wandert auf den Müll.
Wie sind eure Regeln hier: Für ein (vermutlich) anderes DHCP-Problem mit einem anderen Endgerät (sendet DISCOVER ohne end-option) eröffne ich einen neuen Thread? Oder derselbe?
Zitat von @maximalz:
Wie sind eure Regeln hier: Für ein (vermutlich) anderes DHCP-Problem mit einem anderen Endgerät (sendet DISCOVER ohne end-of-options) eröffne ich einen neuen Thread? Oder derselbe?
Anderes Thema bitte neuer Thread.Wie sind eure Regeln hier: Für ein (vermutlich) anderes DHCP-Problem mit einem anderen Endgerät (sendet DISCOVER ohne end-of-options) eröffne ich einen neuen Thread? Oder derselbe?
Ggf. hilft es zusätzlich auch mal das DHCP Logging im MT zu aktivieren (/system logging add topics=dhcp)
