maximalz
Goto Top

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.

Content-ID: 13335136647

Url: https://administrator.de/contentid/13335136647

Ausgedruckt am: 22.11.2024 um 07:11 Uhr

aqui
aqui 16.10.2023 aktualisiert um 21:37:57 Uhr
Goto Top
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:
  • Das Gerät sendet gar keine DHCP Requests
  • Du hast einen Fehler in deinem VLAN bzw. PVID Setup gemacht
Letzteres kann sein wenn noch ein IP Interface auf der Bridge ist oder die PVID Settings an dem Port nicht stimmen. Leider hast du hier keinerlei hilfreiche Angaben gemacht und zwingst zum Kristallkugeln.
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...
cykes
cykes 17.10.2023 um 06:31:10 Uhr
Goto Top
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
aqui
aqui 17.10.2023 um 11:44:44 Uhr
Goto Top
ein 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.
maximalz
maximalz 17.10.2023 um 18:50:34 Uhr
Goto Top
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)

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?
aqui
aqui 17.10.2023 aktualisiert um 19:39:00 Uhr
Goto Top
(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.
Wireshark ist ein grafisches Programm warum du dann keinen Screenshot schickst aus dem die Layer 2 Adressen ersichtlich sind erschliesst sich einem nicht.
Unter diesen Umständen können auch wir nur im Trüben stochern und wild Kristallkugeln. face-sad

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?
maximalz
maximalz 17.10.2023 um 21:08:23 Uhr
Goto Top
Ok, nochmal das Ganze mit Screenshot und MAC Adresse. 00:80:c8:d2:98:51 ist der Printserver.

bildschirmfoto vom 2023-10-17 20-48-23


Torch auf ether2 mit den Ports 67 + 68

bildschirmfoto vom 2023-10-17 20-56-41
bildschirmfoto vom 2023-10-17 20-56-04

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.
cykes
cykes 18.10.2023 um 06:39:37 Uhr
Goto Top
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
maximalz
maximalz 18.10.2023 um 06:52:10 Uhr
Goto Top
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.
aqui
aqui 18.10.2023 aktualisiert um 12:43:17 Uhr
Goto Top
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. face-sad
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.
maximalz
maximalz 18.10.2023 um 14:47:06 Uhr
Goto Top
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

bildschirmfoto vom 2023-10-18 14-35-49

Das Ganze passiert nur 2x. In der ARP Liste sehe ich

bildschirmfoto vom 2023-10-18 14-38-26

aber unter DHCP steht ein Konflikt

bildschirmfoto vom 2023-10-18 14-30-36

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.

bildschirmfoto vom 2023-10-18 14-43-59

Stelle ich den Printserver auf DHCP zurück, kann man das Spielchen von vorne betrachten.
maximalz
maximalz 18.10.2023 um 15:42:45 Uhr
Goto Top
Könnte es evtl. für die erfolgreiche Vergabe der Leases problematisch sein, dass die Systemzeiten vom DHCP Server und dem Printserver abweichen?
aqui
aqui 19.10.2023 um 13:56:04 Uhr
Goto Top
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.
maximalz
maximalz 19.10.2023 um 14:19:52 Uhr
Goto Top
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.

bildschirmfoto vom 2023-10-19 14-19-19
aqui
aqui 19.10.2023 aktualisiert um 14:30:47 Uhr
Goto Top
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.
7907292512
7907292512 19.10.2023 aktualisiert um 14:39:20 Uhr
Goto Top
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:

screenshot

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
maximalz
maximalz 19.10.2023 um 14:51:46 Uhr
Goto Top
"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.
7907292512
7907292512 19.10.2023 aktualisiert um 15:01:05 Uhr
Goto Top
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?
maximalz
maximalz 19.10.2023 aktualisiert um 16:12:48 Uhr
Goto Top
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?
7907292512
7907292512 19.10.2023 um 16:13:32 Uhr
Goto Top
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.
aqui
aqui 19.10.2023 um 17:29:06 Uhr
Goto Top
Ggf. hilft es zusätzlich auch mal das DHCP Logging im MT zu aktivieren (/system logging add topics=dhcp)