Weitergeleitete Broadcasts an andere als das eigene IP-Subnetz werden bis zum Herunterfahren der Socket empfangen - warum?

500
Konstantin Shemyak

Meine beiden Hosts befinden sich im selben Ethernet-Segment. Host A ist 10.1.0.1/16, Host B ist 10.1.0.2/16. A sendet gerichtete UDP-Broadcasts an 10.1.255.255einen UDP-Listen-Socket, der INADDR_ANYan B gebunden ist .

Nachdem ich wechselnde IP - Konfiguration auf A zu, 10.0.0.1/16so dass sie gehört zu einem anderen IP - Subnetz und beginnt Rundfunk 10.0.255.255, dass gleicher Buchse auf B noch empfängt diese Sendung.

Wenn ich die Höranwendung auf B neu starte, werden diese Broadcasts in einem "falschen" Subnetz nicht mehr vom Socket empfangen .

Frage: Warum lässt der Netzwerkstapel von B das Paket nicht fallen, was weder ein Unicast zu B noch ein Broadcast zu einem Subnetz von B ist, bis das Socket heruntergefahren wird?

Ich weiß, dass RFC1122 sagt :

Hosts SHOULD use the Limited Broadcast address to broadcast to a connected network.

Ich verstehe, dass die Anwendung von A, die gerichtete Broadcasts mit der Absicht sendet, an das eigene Subnetz zu senden, nicht der "Sollte" -Klausel folgt. Aber meine Frage ist, warum B sie nicht fallen lässt, solange UDP-Socket lebt.

Ich habe dieses Verhalten auf den Linux-Kerneln 4.4 und 3.13 beobachtet.

2
Wenn Sie sagen "B empfängt diese Rundsendung", zeigt das Programm das tatsächlich an - Packet Capture (tcpdump) oder einen regulären UDP-Socket? grawity vor 6 Jahren 2
@Grawity UDP-Socket. (Natürlich auch tcpdump, auch wenn sich das Interface nicht im Promiscuous-Modus befindet.) Konstantin Shemyak vor 6 Jahren 0
Nur weil Host B den Verkehr sieht, was normal ist, bedeutet das nicht, dass er darauf einwirkt. Abhängig von Ihrer Überwachungsmethode können Sie Ihre Daten falsch interpretieren. Wenn Sie ein Netzwerk-Sniffing-Tool verwenden, befindet sich der Ethernet-Adapter wahrscheinlich im Promiscuous-Modus. Daher wird der gesamte Datenverkehr im Netzwerk angezeigt, stattdessen wird er an ihn adressiert oder nicht. Appleoddity vor 6 Jahren 0
Es ist auch wichtig, wenn diese Geräte über einen Switch oder Hub angeschlossen sind. Appleoddity vor 6 Jahren 0
@Appleoddity im obigen Kommentar Ich habe den Empfang des Pakets durch den * UDP-Socket * explizit erwähnt (und auch den * nicht * Promiscuous-Modus, wenn Sniffer ausgeführt wird). Konstantin Shemyak vor 6 Jahren 0
@Appleoddity: Auf der Ethernet-Ebene ist dies völlig normal (da alle Broadcast-Typen dieselbe MAC-Adresse haben); Ich nehme an, das OP fragt, warum es nicht fallen gelassen wird, sobald es die IP-Schicht erreicht. grawity vor 6 Jahren 2
@ user3608247 Ich sehe in deiner Frage keines der beiden Dinge, die du gerade erwähnt hast, aber das ist weder hier noch dort, denke ich. Haben Sie die IP-Weiterleitung auf Ihrem Host b aktiviert? Dies würde dazu führen, dass der IP-Stack auf jedes Paket reagiert, würde ich auch denken. Appleoddity vor 6 Jahren 0
Warten Sie, es tut mir leid, dass Sie dies für eine Konversation abgeben, aber Sie verwenden einen Sniffer, um festzustellen, ob der Host das Paket empfängt. Natürlich sieht der Schnüffler es. Genau wie @ grawity erwähnt, verwenden sie alle dieselbe Broadcast-MAC-Adresse, so dass die Netzwerkkarte das Paket empfängt und in einem Sniffer angezeigt wird, aber die Schicht 3 des OSI-Stacks nicht passiert. Appleoddity vor 6 Jahren 0
@ grawity Ich habe die Frage bearbeitet. Der unerwartete Empfang von Broadcasts in ein "falsches" Subnetz wird nur fortgesetzt, bis der UDP-Socket heruntergefahren wird. Konstantin Shemyak vor 6 Jahren 0
Anscheinend wurde das gleiche Problem vor 6 Monaten auf serverfault gemeldet: https://serverfault.com/questions/830364/application-receiving-boradcast-fromddifferent-subnet Konstantin Shemyak vor 6 Jahren 0

0 Antworten auf die Frage

Verwandte Probleme