| orm@doc-tcpip.org | Erstellt: Oktober 2000 - Letzte Modifikation: Mai 2001 |
Der Client sendet einen Broadcast ins Netz, auf dem er einen DHCP-Server
vermutet. Das ist das DHCPDISCOVER-Paket. Ein auf dem Netz befindlicher
Server bekommt das Paket und kann eine Adresse aus dem von ihm verwalteten
Bereich vergeben. Er sendet ein DHCPOFFER an den Client. Dieses
Paket ist kein Broadcast, sondern geht direkt an die Adresse des Clients,
dessen MAC-Adresse der Server ja nun kennt. Der Server bietet eine Adresse
an und die Optionen/Informationen über die er verfügt. Der Client empfängt
das Angebot. Er kann Angebote von mehreren Servern abwarten, wenn er
möchte. Jedenfalls entscheidet sich der Client für ein Angebot und sendet
einen Broadcast, in dem er die Server-ID und die ausgewählte Adresse
wiederholt. Das ist das DHCPREQUEST. Es ist ein Broadcast, um so
die Entscheidung des Clients auch den anderen Servern bekannt zu machen -
diese können dann die Bearbeitung von diesem Vorgang einstellen. Wenn
von Server-Seite sich am Angebot nichts geändert hat, dann antwortet der
Server mit einem DHCPACK. Das ist direkt an den Client gerichtet
und wiederholt nocheinmal die Einstellungen und die Adresse. Der Client
kann sich dann konfigurieren. Der Vorgang ist damit abgeschloßen.
Adressen können sowohl von Server wie auch von Client-seite geprüft
werden. Daraus resultieren die Messages DHCPNACK und DHCPDECLINE.
Ein Client kann und sollte beim Runterfahren seine Adresse zurückgeben.
Dazu dient das DHCPRELEASE.
In diesem Trace sind nicht alle Messages zu sehen.
Der Trace ist auf dem DHCP-Server unter AIX mit dem iptrace-Kommando
aufgenommen worden.
Auf diesem Netz gab es ein Problem: die Clients haben nie eine Adresse
erhalten (Es waren X-Stations, also grafikfähige Terminals, die nichts
besseres aus der Situation machen konnten als ewig zu versuchen, eine
Adresse, also einen "Lease" zu bekommen). Am Ende des Traces sieht man
dann warum das so war.
Packet Number 2278 TOK: ====( 356 bytes received on interface tr2 )==== 12:55:24.563523993 TOK: 802.5 packet TOK: 802.5 MAC header: TOK: access control field = 10, frame control field = 40 TOK: [ src = c0:01:a4:00:37:ef, dst = ff:ff:ff:ff:ff:ff] TOK: routing control field = 8630, 2 routing segments TOK: routing segments [ fb1 810 ] TOK: 802.2 LLC header: TOK: dsap aa, ssap aa, ctrl 3, proto 0:0:0, type 800 (IP) IP: < SRC = 0.0.0.0 > IP: < DST = 255.255.255.255 > IP: ip_v=4, ip_hl=20, ip_tos=0, ip_len=328, ip_id=2048, ip_off=0 IP: ip_ttl=128, ip_sum=31a6, ip_p = 17 (UDP) UDP: < source port=68(dhcpc), < destination port=67(dhcps) > UDP: [ udp length = 308 | udp checksum = a66a ] UDP: DHCPv4 header breakdown: UDP: Request: UDP: htype:6, hlen:6, hops:0 UDP: xid:0x58522148, secs:0, flags:0x0 UDP: ciaddr:0.0.0.0, yiaddr:0.0.0.0 UDP: siaddr:0.0.0.0, giaddr:0.0.0.0 UDP: DHCPDISCOVER UDP: Client-id(7 bytes)UDP: 00000000 064001a4 0037ef |.@...7. | UDP: request IP: 10.1.20.137 UDP: hostname: dumpy UDP: param. req. list.: 1, 3, 44, 46, 47, 6, 255 UDP:
Das ist das erste Paket. Wir haben es hier mit dem Rechner Dumpy zu tun. Er
hatte als letzte Adresse die 10.1.20.137, die er jetzt auch wieder haben
möchte - wenn möglich. Am Hardware-Type 6 sehe ich, das es sich um ein
Token-Ring Interface handelt, das eine IP-Adresse anfordert. Am Parameter
"hops" kann ich festmachen, das DHCP-Client und Server auf demselben Netz
liegen (ich weiss, das der Trace auf dem Server gemacht ist). Wäre noch eine
Maschine als Relay-Host dazwischen, würde ich hier eine 1 sehen.
Die Transaction ID (xid, 0x58522148) merke ich mir, denn daran
erkenne ich alle Pakete, die zu diesem Vorgang gehören. Um ehrlich zu sein - ich
habe diese Pakete mit "grep" über die xid aus dem original Trace gefischt.
Dann sehe ich, daß das Paket ein DHCPDISCOVER ist, der Client sich
mit dem Hardware-Type und der MAC-Adresse identifiziert. Er gibt seine
alte IP nocheinmal an und nennt unverbindlich seinen Namen.
Zum Schluß fordert er noch einige Parameter an, die im Angebot unbedingt
enthalten sein müssen. Es handelt sich hier um die DHCP Optionen, wie sie im
RFC 2132 spezifiert sind: Die Subnetmaske (1), Routeradressen (3), Netbios Name
Server Adresse (44), Netbios Node Type (46), Netbios Scope Option (47),
Name Server Adresse (6) und die "Ende der Optionsliste" Option (255).
Packet Number 2279 TOK: ====( 356 bytes received on interface tr0 )==== 12:55:24.563535446 TOK: 802.5 packet TOK: 802.5 MAC header: TOK: access control field = 18, frame control field = 40 TOK: [ src = c0:01:a4:00:37:ef, dst = ff:ff:ff:ff:ff:ff] TOK: routing control field = 8630, 2 routing segments TOK: routing segments [ fb1 810 ] TOK: 802.2 LLC header: TOK: dsap aa, ssap aa, ctrl 3, proto 0:0:0, type 800 (IP) IP: < SRC = 0.0.0.0 > IP: < DST = 255.255.255.255 > IP: ip_v=4, ip_hl=20, ip_tos=0, ip_len=328, ip_id=2048, ip_off=0 IP: ip_ttl=128, ip_sum=31a6, ip_p = 17 (UDP) UDP: < source port=68(dhcpc), < destination port=67(dhcps) > UDP: [ udp length = 308 | udp checksum = a66a ] UDP: DHCPv4 header breakdown: UDP: Request: UDP: htype:6, hlen:6, hops:0 UDP: xid:0x58522148, secs:0, flags:0x0 UDP: ciaddr:0.0.0.0, yiaddr:0.0.0.0 UDP: siaddr:0.0.0.0, giaddr:0.0.0.0 UDP: DHCPDISCOVER UDP: Client-id(7 bytes)UDP: 00000000 064001a4 0037ef |.@...7. | UDP: request IP: 10.1.20.137 UDP: hostname: dumpy UDP: param. req. list.: 1, 3, 44, 46, 47, 6, 255 UDP:
Hier hat man dasselbe Paket nochmal - oder?
Bei genauerer Betrachtung stolpern wir über das erste Problemchen:
TOK: ====( 356 bytes received on interface tr2 )==== 12:55:24.563523993 TOK: ====( 356 bytes received on interface tr0 )==== 12:55:24.563535446
Packet Number 2280 TOK: ====( 356 bytes received on interface tr1 )==== 12:55:24.563588235 TOK: 802.5 packet TOK: 802.5 MAC header: TOK: access control field = 10, frame control field = 40 TOK: [ src = c0:01:a4:00:37:ef, dst = ff:ff:ff:ff:ff:ff] TOK: routing control field = 8630, 2 routing segments TOK: routing segments [ fb1 810 ] TOK: 802.2 LLC header: TOK: dsap aa, ssap aa, ctrl 3, proto 0:0:0, type 800 (IP) IP: < SRC = 0.0.0.0 > IP: < DST = 255.255.255.255 > IP: ip_v=4, ip_hl=20, ip_tos=0, ip_len=328, ip_id=2048, ip_off=0 IP: ip_ttl=128, ip_sum=31a6, ip_p = 17 (UDP) UDP: < source port=68(dhcpc), < destination port=67(dhcps) > UDP: [ udp length = 308 | udp checksum = a66a ] UDP: DHCPv4 header breakdown: UDP: Request: UDP: htype:6, hlen:6, hops:0 UDP: xid:0x58522148, secs:0, flags:0x0 UDP: ciaddr:0.0.0.0, yiaddr:0.0.0.0 UDP: siaddr:0.0.0.0, giaddr:0.0.0.0 UDP: DHCPDISCOVER UDP: Client-id(7 bytes)UDP: 00000000 064001a4 0037ef |.@...7. | UDP: request IP: 10.1.20.137 UDP: hostname: dumpy UDP: param. req. list.: 1, 3, 44, 46, 47, 6, 255 UDP:
TOK: ====( 356 bytes received on interface tr2 )==== 12:55:24.563523993 TOK: ====( 356 bytes received on interface tr0 )==== 12:55:24.563535446 TOK: ====( 356 bytes received on interface tr1 )==== 12:55:24.563588235
Packet Number 2284 TOK: ====( 394 bytes transmitted on interface tr0 )==== 12:55:25.518171484 TOK: 802.5 packet TOK: 802.5 MAC header: TOK: access control field = 0, frame control field = 40 TOK: [ src = 80:20:35:7c:72:1b, dst = 40:01:a4:00:37:ef] TOK: routing control field = 06b0, 2 routing segments TOK: routing segments [ fb1 810 ] TOK: 802.2 LLC header: TOK: dsap aa, ssap aa, ctrl 3, proto 0:0:0, type 800 (IP) IP: < SRC = 10.1.27.137 > IP: < DST = 10.1.20.137 > IP: ip_v=4, ip_hl=20, ip_tos=0, ip_len=366, ip_id=5252, ip_off=0 IP: ip_ttl=30, ip_sum=42e8, ip_p = 17 (UDP) UDP: < source port=67(dhcps), < destination port=68(dhcpc) > UDP: [ udp length = 346 | udp checksum = cc1c ] UDP: DHCPv4 header breakdown: UDP: Reply: UDP: htype:6, hlen:6, hops:0 UDP: xid:0x58522148, secs:0, flags:0x0 UDP: ciaddr:0.0.0.0, yiaddr:10.1.20.137 UDP: siaddr:0.0.0.0, giaddr:0.0.0.0 UDP: DHCPOFFER UDP: server-id: 10.1.27.137 UDP: subnet mask: 255.255.240.0 UDP: domain name: orm.org UDP: router: 10.1.19.253 UDP: NetBIOS over TCP/IP name server: 10.1.16.247, 10.1.16.248 UDP: NetBIOS over TCP/IP node type: 0x8 UDP: domain name server: 192.168.124.81, 192.168.124.80 UDP: time server: 10.1.19.254 UDP: hostname: dumpy UDP: broadcast address: 10.1.31.255 UDP: Xwindow system font server: 10.1.19.211 UDP: lease time: 345600 UDP:
Hier die erste Antwort (DHCPOFFER). Der Server hat jetzt das Feld
yiaddr gesetzt. Das ist die Adresse, die er dem Client anbietet
(Your IP Address). Der Server identifiziert sich auch selbst.
Der Client hatte angekündigt, das
er es nur unter bestimmten Bedingungen annimmt:
Der Subnetmaske (1), Routeradressen (3), Netbios Name
Server Adresse (44), Netbios Node Type (46), Netbios Scope Option und der
Name Server Adresse (6). Das ist alles erfüllt und zusätzlich gibt es noch ein
paar Goodies. Halt - Es fehlt die Netbios Scope Option (47)!
Das ganze geht über das Interface tr0. Ohne netstats kann
man nicht wissen, wie die Umgebung aussieht. Vermutlich ist aber tr0 das
einzige Interface, was zu der angeforderten Adresse passt.
Packet Number 2285 TOK: ====( 356 bytes received on interface tr2 )==== 12:55:25.526058808 TOK: 802.5 packet TOK: 802.5 MAC header: TOK: access control field = 10, frame control field = 40 TOK: [ src = c0:01:a4:00:37:ef, dst = ff:ff:ff:ff:ff:ff] TOK: routing control field = 8630, 2 routing segments TOK: routing segments [ fb1 810 ] TOK: 802.2 LLC header: TOK: dsap aa, ssap aa, ctrl 3, proto 0:0:0, type 800 (IP) IP: < SRC = 0.0.0.0 > IP: < DST = 255.255.255.255 > IP: ip_v=4, ip_hl=20, ip_tos=0, ip_len=328, ip_id=2304, ip_off=0 IP: ip_ttl=128, ip_sum=30a6, ip_p = 17 (UDP) UDP: < source port=68(dhcpc), < destination port=67(dhcps) > UDP: [ udp length = 308 | udp checksum = 48dc ] UDP: DHCPv4 header breakdown: UDP: Request: UDP: htype:6, hlen:6, hops:0 UDP: xid:0x58522148, secs:0, flags:0x0 UDP: ciaddr:0.0.0.0, yiaddr:0.0.0.0 UDP: siaddr:0.0.0.0, giaddr:0.0.0.0 UDP: DHCPREQUEST UDP: Client-id(7 bytes)UDP: 00000000 064001a4 0037ef |.@...7. | UDP: request IP: 10.1.20.137 UDP: server-id: 10.1.27.137 UDP: hostname: dumpy UDP: param. req. list.: 1, 3, 44, 46, 47, 6, 255 UDP:
Den Client scheint es nicht zu stören, daß die Scope Option fehlt.
Er bittet den Server um die angebotene Adresse, wobei er nochmal seine
Optionsliste mitschickt. Das ist das DHCPREQUEST.
Ein DHCPREQUEST ist auch immer ein Broadcast, einmal, weil der
Client die Adresse noch nicht sicher hat, und weil er so den anderen
Servern, die sich vielleicht immer noch um ihn bemühen, so gleich
mitteilt, das er sich entschieden hat. Und die Sache somit für nicht
ausgewählte Server (die Server-ID!) erledigt ist.
Packet Number 2286 TOK: ====( 356 bytes received on interface tr0 )==== 12:55:25.526076096 TOK: 802.5 packet TOK: 802.5 MAC header: TOK: access control field = 18, frame control field = 40 TOK: [ src = c0:01:a4:00:37:ef, dst = ff:ff:ff:ff:ff:ff] TOK: routing control field = 8630, 2 routing segments TOK: routing segments [ fb1 810 ] TOK: 802.2 LLC header: TOK: dsap aa, ssap aa, ctrl 3, proto 0:0:0, type 800 (IP) IP: < SRC = 0.0.0.0 > IP: < DST = 255.255.255.255 > IP: ip_v=4, ip_hl=20, ip_tos=0, ip_len=328, ip_id=2304, ip_off=0 IP: ip_ttl=128, ip_sum=30a6, ip_p = 17 (UDP) UDP: < source port=68(dhcpc), < destination port=67(dhcps) > UDP: [ udp length = 308 | udp checksum = 48dc ] UDP: DHCPv4 header breakdown: UDP: Request: UDP: htype:6, hlen:6, hops:0 UDP: xid:0x58522148, secs:0, flags:0x0 UDP: ciaddr:0.0.0.0, yiaddr:0.0.0.0 UDP: siaddr:0.0.0.0, giaddr:0.0.0.0 UDP: DHCPREQUEST UDP: Client-id(7 bytes)UDP: 00000000 064001a4 0037ef |.@...7. | UDP: request IP: 10.1.20.137 UDP: server-id: 10.1.27.137 UDP: hostname: dumpy UDP: param. req. list.: 1, 3, 44, 46, 47, 6, 255 UDP:
Dasselbe nochmal. Wegen der verschiedenen Interfaces...
Packet Number 2287 TOK: ====( 356 bytes received on interface tr1 )==== 12:55:25.526082860 TOK: 802.5 packet TOK: 802.5 MAC header: TOK: access control field = 10, frame control field = 40 TOK: [ src = c0:01:a4:00:37:ef, dst = ff:ff:ff:ff:ff:ff] TOK: routing control field = 8630, 2 routing segments TOK: routing segments [ fb1 810 ] TOK: 802.2 LLC header: TOK: dsap aa, ssap aa, ctrl 3, proto 0:0:0, type 800 (IP) IP: < SRC = 0.0.0.0 > IP: < DST = 255.255.255.255 > IP: ip_v=4, ip_hl=20, ip_tos=0, ip_len=328, ip_id=2304, ip_off=0 IP: ip_ttl=128, ip_sum=30a6, ip_p = 17 (UDP) UDP: < source port=68(dhcpc), < destination port=67(dhcps) > UDP: [ udp length = 308 | udp checksum = 48dc ] UDP: DHCPv4 header breakdown: UDP: Request: UDP: htype:6, hlen:6, hops:0 UDP: xid:0x58522148, secs:0, flags:0x0 UDP: ciaddr:0.0.0.0, yiaddr:0.0.0.0 UDP: siaddr:0.0.0.0, giaddr:0.0.0.0 UDP: DHCPREQUEST UDP: Client-id(7 bytes)UDP: 00000000 064001a4 0037ef |.@...7. | UDP: request IP: 10.1.20.137 UDP: server-id: 10.1.27.137 UDP: hostname: dumpy UDP: param. req. list.: 1, 3, 44, 46, 47, 6, 255 UDP:
Packet Number 2288 TOK: ====( 352 bytes transmitted on interface tr2 )==== 12:55:25.551603398 TOK: 802.5 packet TOK: 802.5 MAC header: TOK: access control field = 0, frame control field = 40 TOK: [ src = 80:20:35:7c:15:42, dst = ff:ff:ff:ff:ff:ff] TOK: routing control field = 8220, 0 routing segments TOK: 802.2 LLC header: TOK: dsap aa, ssap aa, ctrl 3, proto 0:0:0, type 800 (IP) IP: < SRC = 10.0.144.148 > IP: < DST = 255.255.255.255 > IP: ip_v=4, ip_hl=20, ip_tos=0, ip_len=328, ip_id=5254, ip_off=0 IP: ip_ttl=30, ip_sum=ec8b, ip_p = 17 (UDP) UDP: < source port=67(dhcps), < destination port=68(dhcpc) > UDP: [ udp length = 308 | udp checksum = 3923 ] UDP: DHCPv4 header breakdown: UDP: Reply: UDP: htype:6, hlen:6, hops:0 UDP: xid:0x58522148, secs:0, flags:0x0 UDP: ciaddr:0.0.0.0, yiaddr:0.0.0.0 UDP: siaddr:0.0.0.0, giaddr:0.0.0.0 UDP: DHCPNAKUDP: server-id: 10.0.144.148 UDP:
Was ich hier nicht verstehe: Hier antwortet ein Server, der mit der ganzen Sache eigentlich nichts zu tun hat. Und er schickt ein DHCKNAK, dabei hat ihn garniemand gefragt. Da soetwas öfter auch ein Problem des Tools ist, lohnt es sich, den Hex-dump des Paketes anzusehen:
TOK: 00000120 63825363 35010636 040a0090 94ff0000 |c.Sc5..6........| . Magic Cookie . Option 53 (0x35, DHCP Message Type . Länge (1 Byte) . Wert ist 6, also DHCPNAK . Option 53 (0x36, Server Identifier) . Länge (4 Byte) . Und eine IP... . ff=255, Option List End..Das ist alles richtig übertragen, auch wenn es ein "DHCPNAKUDP" nicht gibt, aber das ist geschenkt.
Packet Number 2289 TOK: ====( 352 bytes received on interface tr0 )==== 12:55:25.552730343 TOK: 802.5 packet TOK: 802.5 MAC header: TOK: access control field = 18, frame control field = 40 TOK: [ src = 80:20:35:7c:15:42, dst = ff:ff:ff:ff:ff:ff] TOK: routing control field = 8220, 0 routing segments TOK: 802.2 LLC header: TOK: dsap aa, ssap aa, ctrl 3, proto 0:0:0, type 800 (IP) IP: < SRC = 10.0.144.148 > IP: < DST = 255.255.255.255 > IP: ip_v=4, ip_hl=20, ip_tos=0, ip_len=328, ip_id=5254, ip_off=0 IP: ip_ttl=30, ip_sum=ec8b, ip_p = 17 (UDP) UDP: < source port=67(dhcps), < destination port=68(dhcpc) > UDP: [ udp length = 308 | udp checksum = 3923 ] UDP: DHCPv4 header breakdown: UDP: Reply: UDP: htype:6, hlen:6, hops:0 UDP: xid:0x58522148, secs:0, flags:0x0 UDP: ciaddr:0.0.0.0, yiaddr:0.0.0.0 UDP: siaddr:0.0.0.0, giaddr:0.0.0.0 UDP: DHCPNAKUDP: server-id: 10.0.144.148 UDP:
Auf jedem Interface diese seltsame Meldung. Mittlerweile hat es auch der Client gehört, ganz klar. Und wenn ein Client mit einer bestimmten xid ein daruaf gerichtetes DHCPNAK empfängt, dann setzt er sich zurück und fängt nach einer Pause neu an...
Packet Number 2290 TOK: ====( 352 bytes received on interface tr2 )==== 12:55:25.552740156 TOK: 802.5 packet TOK: 802.5 MAC header: TOK: access control field = 1c, frame control field = 40 TOK: [ src = 80:20:35:7c:15:42, dst = ff:ff:ff:ff:ff:ff] TOK: routing control field = 8220, 0 routing segments TOK: 802.2 LLC header: TOK: dsap aa, ssap aa, ctrl 3, proto 0:0:0, type 800 (IP) IP: < SRC = 10.0.144.148 > IP: < DST = 255.255.255.255 > IP: ip_v=4, ip_hl=20, ip_tos=0, ip_len=328, ip_id=5254, ip_off=0 IP: ip_ttl=30, ip_sum=ec8b, ip_p = 17 (UDP) UDP: < source port=67(dhcps), < destination port=68(dhcpc) > UDP: [ udp length = 308 | udp checksum = 3923 ] UDP: DHCPv4 header breakdown: UDP: Reply: UDP: htype:6, hlen:6, hops:0 UDP: xid:0x58522148, secs:0, flags:0x0 UDP: ciaddr:0.0.0.0, yiaddr:0.0.0.0 UDP: siaddr:0.0.0.0, giaddr:0.0.0.0 UDP: DHCPNAKUDP: server-id: 10.0.144.148 UDP:
Auf jedem Interface diese seltsame Meldung.
Packet Number 2291 TOK: ====( 352 bytes received on interface tr1 )==== 12:55:25.553873826 TOK: 802.5 packet TOK: 802.5 MAC header: TOK: access control field = 10, frame control field = 40 TOK: [ src = 80:20:35:7c:15:42, dst = ff:ff:ff:ff:ff:ff] TOK: routing control field = 8220, 0 routing segments TOK: 802.2 LLC header: TOK: dsap aa, ssap aa, ctrl 3, proto 0:0:0, type 800 (IP) IP: < SRC = 10.0.144.148 > IP: < DST = 255.255.255.255 > IP: ip_v=4, ip_hl=20, ip_tos=0, ip_len=328, ip_id=5254, ip_off=0 IP: ip_ttl=30, ip_sum=ec8b, ip_p = 17 (UDP) UDP: < source port=67(dhcps), < destination port=68(dhcpc) > UDP: [ udp length = 308 | udp checksum = 3923 ] UDP: DHCPv4 header breakdown: UDP: Reply: UDP: htype:6, hlen:6, hops:0 UDP: xid:0x58522148, secs:0, flags:0x0 UDP: ciaddr:0.0.0.0, yiaddr:0.0.0.0 UDP: siaddr:0.0.0.0, giaddr:0.0.0.0 UDP: DHCPNAKUDP: server-id: 10.0.144.148 UDP:
Auf jedem Interface diese seltsame Meldung.
Packet Number 2292 TOK: ====( 394 bytes transmitted on interface tr0 )==== 12:55:26.460727340 TOK: 802.5 packet TOK: 802.5 MAC header: TOK: access control field = 0, frame control field = 40 TOK: [ src = 80:20:35:7c:72:1b, dst = 40:01:a4:00:37:ef] TOK: routing control field = 06b0, 2 routing segments TOK: routing segments [ fb1 810 ] TOK: 802.2 LLC header: TOK: dsap aa, ssap aa, ctrl 3, proto 0:0:0, type 800 (IP) IP: < SRC = 10.1.27.137 > IP: < DST = 10.1.20.137 > IP: ip_v=4, ip_hl=20, ip_tos=0, ip_len=366, ip_id=5449, ip_off=0 IP: ip_ttl=30, ip_sum=4223, ip_p = 17 (UDP) UDP: < source port=67(dhcps), < destination port=68(dhcpc) > UDP: [ udp length = 346 | udp checksum = c91c ] UDP: DHCPv4 header breakdown: UDP: Reply: UDP: htype:6, hlen:6, hops:0 UDP: xid:0x58522148, secs:0, flags:0x0 UDP: ciaddr:0.0.0.0, yiaddr:10.1.20.137 UDP: siaddr:0.0.0.0, giaddr:0.0.0.0 UDP: DHCPACK UDP: server-id: 10.1.27.137 UDP: subnet mask: 255.255.240.0 UDP: domain name: orm.org UDP: router: 10.1.19.253 UDP: NetBIOS over TCP/IP name server: 10.1.16.247, 10.1.16.248 UDP: NetBIOS over TCP/IP node type: 0x8 UDP: domain name server: 192.168.124.81, 192.168.124.80 UDP: time server: 10.1.19.254 UDP: hostname: dumpy UDP: broadcast address: 10.1.31.255 UDP: Xwindow system font server: 10.1.19.211 UDP: lease time: 345600
So hätte es sein sollen: der Server Antwortet auf den Request mit einem
abschliessenden Acknowledge, der Client kann sich jetzt mit diesen Informationen
konfigurieren. In diesem Fall zu spät, der Client ist schon dabei, sich auf
einen neuen Versuch vorzubereiten. Das ist dauernd so gegangen - deshalb ist
der Trace so lange.
Ich habe aus dem Trace geschloßen, das auf dem Server 2 DHCP-Server Instanzen
liefen - was an und für sich nicht unmöglich ist, wenn sich die IP-Bereiche
nicht überschneiden. Es hat sich dann bei näherer Analyse herausgestellt, das
das Ganze etwas unorthodox aufgesetzt war und sich daher entsprechend verhielt.
Dem einen oder anderen wird eine Eigenartigkeit der MAC-Adresse des Clients
aufgefallen sein: Sie ist unterschiedlich, je nach dem, ob es die Quelle
oder das Ziel ist:
UDP: Client-id(7 bytes)UDP: 00000000 064001a4 0037ef TOK: [ src = c0:01:a4:00:37:ef, dst = ff:ff:ff:ff:ff:ff] TOK: [ src = 80:20:35:7c:72:1b, dst = 40:01:a4:00:37:ef]Das hängt damit zusammen, das es sich um Token Ring handelt. Die "richtige" MAC Adresse ist 40:01:a4..., ein IBM Adapter. Ist für diese Adresse ein ein Routing Feld vorhanden, so ändert sich das Bitmuster, um diesen Umstand mitzuteilen. Naja, Token Ring halt...
TOK: 802.5 MAC header: TOK: access control field = 10, frame control field = 40 TOK: [ src = c0:01:a4:00:37:ef, dst = ff:ff:ff:ff:ff:ff] TOK: routing control field = 8630, 2 routing segments TOK: routing segments [ fb1 810 ]
[ Allgemein | UNIX | AIX | TCP-IP | TCP | ROUTING | DNS | NTP | NFS | FreeBSD | Linux | RPi | SMTP | Tracing | GPS | LW ]
Copyright 2001-2021 by Orm Hager - Es gilt die GPL