orm@doc-tcpip.org

Erstellt: Oktober 2000 - Letzte Modifikation: Mai 2001

[ Main | Local ]


Ein DHCP-Trace aus dem wahren Leben


Wie sieht ein DHCP Vorgang aus?

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.

Das ganze im Trace

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

Der Server hat 2 Adapter im selben physikalischen Netz. Es muss nicht dasselbe logische Netz sein, denn einen Broadcast sehen natürlich alle Adapter gleich. Das muß kein Fehler sein, kann aber unter Umständen Probleme machen. Also merken...


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

Und ein drittes Interface. Jetzt sollte man sich die Interfaces mal näher anschauen (mit ifconfig und netstat).


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.
Das ist der erste Eindruck. Sieht man genau hin, dann sieht man, das dieses Paket transmitted wird - das heißt, die lokale Maschine sendet das Paket. Das ist aber gerade mein DHCP Server! Auch die Hops sind 0, und die giaddr ist nicht gesetzt - das Paket kommt von diesem Rechner!! Das ist ganze eigenartig.


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  ]


[ Main | Local ]

[ Allgemein | UNIX | AIX | TCP-IP | TCP | ROUTING | DNS | NTP | NFS | FreeBSD | Linux | SMTP | Tracing | GPS ]

Copyright 2001-2014 by Orm Hager - Es gilt die GPL
Feedback bitte an: Orm Hager (orm@doc-tcpip.org )