ubuntuusers.de

Hallo,

ich habe eine Frage zu ARP:

wenn ein Host eine ARP Anfrage startet, sucht er ja prinzipiell die Mac einer IP. Unter:

http://www.elektronik-kompendium.de/sites/net/0901061.htm

steht:

"Befindet sich eine IP-Adresse nicht im gleichen Subnetz, geht ARP über das Standard-Gateway. Findet ARP die Hardware-Adresse des Standard-Gateways im Cache nicht, wird eine lokale ARP-Adressauflösung ausgelöst."

Meine Frage dazu:

Wie findet ARP ganz zu Anfang, wenn noch keine Einträge da sind, und das NW noch nicht konfiguriert ist die MAC des Standart-gateways? (DHCP muss seine Daten ja auch erstmal adressieren können, was es ja nicht kann, solange keine ARP-table da ist)

Was bedeutet dann der Satz: "...wird eine lokale ARP-Adressauflösung ausgelöst." ?

Vielen Dank und Grüße,

...

Servus.

linzus schrieb:

Wie findet ARP ganz zu Anfang, wenn noch keine Einträge da sind, und das NW noch nicht konfiguriert ist die MAC des Standart-gateways? (DHCP muss seine Daten ja auch erstmal adressieren können, was es ja nicht kann, solange keine ARP-table da ist)

DHCP sendet den ersten Request (DHCP-Discover) als MAC-Broadcast. Der antwortende Server teilt im Offer auch seine IP mit, erst nach dem DHCP-ACK wird IP gesprochen, erst dann ist der IP-Stack konfiguriert. Siehe dazu auch http://www.elektronik-kompendium.de/sites/net/0812221.htm. Somit ist ARP vorher nicht nötig 😉

Was bedeutet dann der Satz: "...wird eine lokale ARP-Adressauflösung ausgelöst." ?

Na, bevor ein Paket an den Gateway geschickt werden kann, muss seine Adresse bekannt sein. Wenn die nicht in der ARp-Table steht, löst der Client bei sich eine ARP-Auflösung aus (lokal, also von sich ausgehend), denn aus dem IP-Stack kennt der Client ja die IP-Adresse des Gateways und kann die mittels ARP in eine MAC auflösen.

Ich hoffe, das half weiter.

Tante Edith sagt: Ohne Erweiterungen bzw Hacks ist ARP auf die Broadcastdomäne beschränkt. Deine Quelle ist hier nicht korrekt bzw nicht eindeutig formuliert. Wenn das Ziel eines Pakets in einem anderen Subnetz liegt, muss es über das Standardgateway geroutet werden. Das ist dann aber eine IP-Aufgabe und hat (bis auf die angesprochene Auflösung der MAC des Gateways) nicht mehr mit ARP zu tun. (Ich hoffe, auch Into the Pit ist hiermit zufrieden)

redknight schrieb:

(Ich hoffe, auch Into the Pit ist hiermit zufrieden)

Ja. 😀

linzus schrieb:

Wie findet ARP ganz zu Anfang, wenn noch keine Einträge da sind, und das NW noch nicht konfiguriert ist die MAC des Standart-gateways? (DHCP muss seine Daten ja auch erstmal adressieren können, was es ja nicht kann, solange keine ARP-table da ist)

Man kann die Netzwerkkommunikation sehr schön mit einem Sniffer (tcpdump oder Wireshark) nachverfolgen und z.B. auch nach Protokollen filtern. So sieht man dann den Broadcast. Witzig, wenn Windows-Clients im Netz sind, die sind da eher die Quasseltanten, brüllen alle in den Raum und wollen alles wissen. 😉

Hallo rednight & into_the_pit,

vielen Dank für eure Antwort(en)!

Ich denke jetzt habe ich es verstanden.

Ich werde es zuhause mal mit meinem raspberry und wireshark genauer untersuchen ☺

Viele Grüße,

...

DHCP sendet den ersten Request (DHCP-Discover) als MAC-Broadcast. Der antwortende Server teilt im Offer auch seine IP mit, erst nach dem DHCP-ACK wird IP gesprochen, erst dann ist der IP-Stack konfiguriert. Siehe dazu auch http://www.elektronik-kompendium.de/sites/net/0812221.htm. Somit ist ARP vorher nicht nötig

Jetzt muss ich doch noch mal nachfragen:

Auf der verlinkten Seite steht:

"DHCP-Discover: Der DHCP-Client verschickt ein UDP-Paket mit der Ziel-Adresse 255.255.255.255 und der Quell-Adresse 0.0.0.0. Dieser Broadcast dient als Adressanforderung an alle verfügbaren DHCP-Server. Im Optimalfall gibt es nur einen DHCP-Server. So vermeidet man Konflikte bei der Adressvergabe."

Dabei handelt es sich aber doch um ein IP-Packet. In meiner Routingtabelle ist status quo aber ja zum Zeitpunkt des Verbindungsaufbaus noch kein Eintrag vorhanden (also wohin das IP-BC adressieren). Oder werden IP-BCs immer automatisch als MAC-BCs gesendet?

Vielen Dank nochmal, und VG, ...

linzus schrieb:

... Oder werden IP-BCs immer automatisch als MAC-BCs gesendet?

Nein, nicht immer. Kannst aber alles auf deinem PI, mit z. B.:

sudo tcpdump -vvveni <Interface> udp portrange 67-68
sudo systemctl restart dhcpcd.service
sudo nmap -sU -p 67 --script=dhcp-discover <IP-Adresse-DHCP-Server>

anzeigen lassen bzw. anschauen.

Mhh, ja mit Wireshark habe ich es probiert, allerdings sehe ich im Monitor Mode nurnoch 802.11 Packete, aus denen nichts herauslesbar ist :-/ (hab alles per WIFI verbunden)

linzus schrieb:

..., aus denen nichts herauslesbar ist :-/ (hab alles per WIFI verbunden)

Dann versuch mal mit tcpdump (statt wireshark):

sudo tcpdump -vvveni wlan0 udp portrange 67-68

EDIT:

Z. B. die Anfrage (von der IP-Adresse 0.0.0.0) an einen Server (MAC-Adresse ff:ff:ff:ff:ff:ff und IP-Adresse 255.255.255.255):

:~ $ sudo tcpdump -vvveni wlan0 udp portrange 67-68
tcpdump: listening on wlan0, link-type EN10MB (Ethernet), capture size 262144 bytes

08:45:35.808899 b8:27:eb:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 383: (tos 0x0, ttl 64, id 13851, offset 0, flags [none], proto UDP (17), length 369)
    0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from b8:27:eb:xx:xx:xx, length 341, xid 0x6f31858c, Flags [none] (0x0000)

und die "gezielte" Antwort vom Server:

08:45:35.819030 c0:25:06:##:##:## > b8:27:eb:xx:xx:xx, ethertype IPv4 (0x0800), length 590: (tos 0x0, ttl 64, id 13851, offset 0, flags [none], proto UDP (17), length 576)
    192.168.178.1.67 > 192.168.178.43.68: [udp sum ok] BOOTP/DHCP, Reply, length 548, xid 0x6f31858c, Flags [none] (0x0000)

EDIT 2:

Es gibt aber auch Fälle (z. B. im Netz von Unitymedia) bei denen die reply-messages (DHCP-ack) als broadcast (an 255.255.255.255 / ff:ff:ff:ff:ff:ff) gesendet werden und deshalb im gesamten UM-Netz gesehen werden können. Z. B.:

21:08:05.960954 ##:##:##:79:72:## > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 328)
    10.217.252.1.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP, Reply, length 300, hops 1, xid 0x2be95d6b, Flags [Broadcast] (0x8000)
     Client-IP 95.##.##.##
     Server-IP 85.216.127.10
     Gateway-IP 10.217.252.1
     Client-Ethernet-Address c8:0a:a9:##:##:##
     Vendor-rfc1048 Extensions
       Magic Cookie 0x63825363
       DHCP-Message Option 53, length 1: ACK
       Server-ID Option 54, length 4: 10.217.252.1
       Subnet-Mask Option 1, length 4: 255.255.252.0
       Default-Gateway Option 3, length 4: 95.###.##.1
       Domain-Name-Server Option 6, length 8: 82.212.62.40,78.42.43.40
       Router-Discovery Option 31, length 1: Y
       END Option 255, length 0
       PAD Option 0, length 0, occurs 25

Hallo Lubux,

vielen Dank für deine ausführliche Erläuterung! Ich habe es jetzt dank tcpdump auch hinbekommen, die Schritte wie unten nachzuvollziehen. Demnach sendet er tatsächlich die Erste Anfrage auf Layer-2 und Layer-3 als BC.

Vielen Dank nochmals und ebensolche Grüße,

...