Keine Antwort auf DHCP Discover (ENC28J60)

[M. G. (sirmel)]

Hallo zusammen,

Bin grade dabei einen ENC28J60 zu programmieren, sodass ich diesen in 
ein DHCP Netzwerk integrieren kann. Wenn ich nun ein DHCP-Discover sende 
kommt das auch am Router an (ich habe den ENC28J60 und einen Laptop mit 
Wireshark an einen Router angeschlossen), der Router scheint aber kein 
DHCP-Offer loszuschicken. Das sehe ich dadran dass der ENC28J60 kein 
Paket empfaengt welches nur fuer seine MAC bestimmt ist (bei einem 
DHCP-Offer wird das Paket doch nur an die entsprechende MAC gesendet und 
nicht als Broadcast richtig?). Ansonsten werden aber alle 
Broadcastpakete empfangen. Ich habe meinen Code schon mit diversen 
anderen Codes verglichen, da sollte soweit alles stimmen. Im Anhang der 
Report von Wireshark, kann es sein dass mein DHCP-Paket falsch ist oder 
da noch was fehlt (Wireshark erkennt es aber als DHCP-Discover und ich 
habe es so aufgebaut wie das DHCP-Discover Paket, welches mein Computer 
raussendet - MAC, IP etc natuerlich angepasst)?

No.     Time        Source                Destination           Protocol Length Hw src addr           Hw dest addr          Info                                                            New Column
   2195 1695.087315 0.0.0.0               255.255.255.255       DHCP     323    PollinEl_01:b9:13     Broadcast             DHCP Discover - Transaction ID 0xbadccdab                       2195

Frame 2195: 323 bytes on wire (2584 bits), 323 bytes captured (2584 bits)
    Arrival Time: Jul 26, 2013 14:17:30.805484000 CST
    Epoch Time: 1374819450.805484000 seconds
    [Time delta from previous captured frame: 0.355258000 seconds]
    [Time delta from previous displayed frame: 0.355258000 seconds]
    [Time since reference or first frame: 1695.087315000 seconds]
    Frame Number: 2195
    Frame Length: 323 bytes (2584 bits)
    Capture Length: 323 bytes (2584 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ip:udp:bootp]
    [Coloring Rule Name: UDP]
    [Coloring Rule String: udp]
Ethernet II, Src: PollinEl_01:b9:13 (00:22:f9:01:b9:13), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
    Destination: Broadcast (ff:ff:ff:ff:ff:ff)
        Address: Broadcast (ff:ff:ff:ff:ff:ff)
        .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
        .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
    Source: PollinEl_01:b9:13 (00:22:f9:01:b9:13)
        Address: PollinEl_01:b9:13 (00:22:f9:01:b9:13)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
    Type: IP (0x0800)
Internet Protocol Version 4, Src: 0.0.0.0 (0.0.0.0), Dst: 255.255.255.255 (255.255.255.255)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)
    Total Length: 323
    Identification: 0x0000 (0)
    Flags: 0x00
        0... .... = Reserved bit: Not set
        .0.. .... = Don't fragment: Not set
        ..0. .... = More fragments: Not set
    Fragment offset: 0
    Time to live: 128
    Protocol: UDP (17)
    Header checksum: 0x39ab [correct]
        [Good: True]
        [Bad: False]
    Source: 0.0.0.0 (0.0.0.0)
    Destination: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: bootpc (68), Dst Port: bootps (67)
    Source port: bootpc (68)
    Destination port: bootps (67)
    Length: 289
    Checksum: 0x0000 (none)
        [Good Checksum: False]
        [Bad Checksum: False]
Bootstrap Protocol
    Message type: Boot Request (1)
    Hardware type: Ethernet
    Hardware address length: 6
    Hops: 0
    Transaction ID: 0xbadccdab
    Seconds elapsed: 0
    Bootp flags: 0x0000 (Unicast)
        0... .... .... .... = Broadcast flag: Unicast
        .000 0000 0000 0000 = Reserved flags: 0x0000
    Client IP address: 0.0.0.0 (0.0.0.0)
    Your (client) IP address: 0.0.0.0 (0.0.0.0)
    Next server IP address: 0.0.0.0 (0.0.0.0)
    Relay agent IP address: 0.0.0.0 (0.0.0.0)
    Client MAC address: PollinEl_01:b9:13 (00:22:f9:01:b9:13)
    Client hardware address padding: 00000000000000000000
    Server host name not given
    Boot file name not given
    Magic cookie: DHCP
    Option: (t=12,l=16) Host Name = "AVR NET-IO BOARD"
        Option: (12) Host Name
        Length: 16
        Value: 415652204e45542d494f20424f415244
    Option: (t=53,l=1) DHCP Message Type = DHCP Discover
        Option: (53) DHCP Message Type
        Length: 1
        Value: 01
    Option: (t=55,l=17) Parameter Request List
        Option: (55) Parameter Request List
        Length: 17
        Value: 011c02030f06770c2c2f1a792a79f9fc2a
        1 = Subnet Mask
        28 = Broadcast Address
        2 = Time Offset
        3 = Router
        15 = Domain Name
        6 = Domain Name Server
        119 = Domain Search [TODO:RFC3397]
        12 = Host Name
        44 = NetBIOS over TCP/IP Name Server
        47 = NetBIOS over TCP/IP Scope
        26 = Interface MTU
        121 = Classless Static Route
        42 = Network Time Protocol Servers
        121 = Classless Static Route
        249 = Private/Classless Static Route (Microsoft)
        252 = Private/Proxy autodiscovery
        42 = Network Time Protocol Servers
    End Option

0000  ff ff ff ff ff ff 00 22 f9 01 b9 13 08 00 45 00   ......."......E.
0010  01 43 00 00 00 00 80 11 39 ab 00 00 00 00 ff ff   .C......9.......
0020  ff ff 00 44 00 43 01 21 00 00 01 01 06 00 ba dc   ...D.C.!........
0030  cd ab 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0040  00 00 00 00 00 00 00 22 f9 01 b9 13 00 00 00 00   ......."........
0050  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0060  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0070  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0080  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0090  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
00a0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
00b0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
00c0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
00d0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
00e0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
00f0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0100  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0110  00 00 00 00 00 00 63 82 53 63 0c 10 41 56 52 20   ......c.Sc..AVR 
0120  4e 45 54 2d 49 4f 20 42 4f 41 52 44 35 01 01 37   NET-IO BOARD5..7
0130  11 01 1c 02 03 0f 06 77 0c 2c 2f 1a 79 2a 79 f9   .......w.,/.y*y.
0140  fc 2a ff

[andi6510 (Gast)]

DHCP hat auch einen broadcast mode bei dem alle Pakete per broadcast 
verschickt werden, auch wenn die empfangende MAC-Addresse bereits 
bekannt ist. Wird am Server bzw Client konfiguriert ist aber eher 
unüblich.

Wenn du direkt am Router mit wireshark und separatem Laptop die Pakete 
anschaust, wirst du nur broadcast pakete sehen und die Pakete die direkt 
an den Laptop gehen. Der Ethernetswitch am Routerausgang wird dir aber 
alle Pakete, welche für eine andere MAC Adresse bestimmt sind, 
vorenthalten. So auch die DHCP-Offer Message (es sei denn sie geht per 
broadcast raus - siehe oben). Die Lösung für dieses Problem ist einen 
konfigurierbaren Switch mit Monitorport zu verwenden oder einen guten 
alten Ethernet HUB (wird seit gefühlten 50 Jahren nicht mehr verkauft).

Wenn diese Hürde genommen ist könnte es in deinem Fall sehr hilfreich 
sein den DHCP-traffic eines anderen Gerätes komplett mitzuschneiden und 
als Referenz für die eigene Implementierung zu verwenden.

[Hans Ulli K. (Gast)]

Also entweder einen Rechner mit DHCP Server aufsetzen und darauf 
Wireshark laufen lassen.
Oder einen OpenWRT kompatiblen Router benutzen und dann tcpdump 
verwenden.

Mit Wireshark am Switchport vom Router zu hängen ist Blödsinn.

[M.G (Gast)]

Ok super, danke für die Hilfe:). Die Idee mit dem Switch hatte ich auch, 
hab mir schon gedacht dass der Router mir die Pakete die ich eigentlich 
sehen will blockt. Dann werd ich mal in der Technikkiste wühlen müssen, 
nen alter Hub sollte noch irgendwo rumfliegen:D.

Komischerweise zeigt mit der Router im Log aber an dass er nen 
DHCP-Discover empfängt, leider kann ich nicht sehen ob er auch drauf 
antwortet. Kennt ihr nen Programm mit dem ich empfangene Pakete 
editieren und zurücksenden kann? Das würde die ganze Sache zum testen 
ziemlich vereinfachen.

[c-hater (Gast)]

andi6510 schrieb:

> Wenn du direkt am Router mit wireshark und separatem Laptop die Pakete
> anschaust, wirst du nur broadcast pakete sehen und die Pakete die direkt
> an den Laptop gehen.

Kommt drauf an. Bei vielen Consumer-Routern mit weniger als 4 LAN-Ports 
sind sämtliche vorhandenen LAN-Ports auf Layer 2 gebridged, das sind 
also praktisch Hubs, keine Switches.

[M. G. (sirmel)]

Also ich habe jetzt zwei verschiedene Router ausprobiert, der eine 
sendet ein DHCP-OFFER zurück, der andere anscheinend nicht. Hab leider 
noch keinen Hub um über Wireshark wirklich zu sehen was gesendet wird 
aber der ENC28j60 empfängt von dem einen Router auf jeden Fall ein 
DHCP-OFFER, welches auch an die richtige MAC gerichtet ist.

Aber mehr als "DHCP-Enable" und den IP-Bereich kann ich bei dem Router 
ja nicht konfigurieren oder muss ich da noch auf irgendwelche 
Einstellungen achten?

[M. G. (sirmel)]

Ok jetzt funktioniert es, ich hatte am Ende vom Paket nochmal manuel ein 
Padding-Field angehängt, jetzt wo ich dieses entfernt habe antworten mir 
beide Router auf den DHCP-Discover:).

Vielen Dank für eure Hilfe

[Rainer S. (rsonline)]

Bootp flags: 0x0000 (Unicast)

        0... .... .... .... = Broadcast flag: Unicast

        .000 0000 0000 0000 = Reserved flags: 0x0000

Das erste Bit sollte eigentlich auf 1 sein bei der ersten Anfrage, 
später dann auf 0.

[Kalender Kalender (Gast)]

Rainer S. schrieb:
> Das erste Bit sollte eigentlich auf 1 sein bei der ersten Anfrage,
> später dann auf 0.

Kaum acht Jahre später kommt schon diese Information. Wie nützlich.