UDP Socket - Missing UDP Port

Sockets, TCP/IP, (XML-)RPC und ähnliche Themen gehören in dieses Forum
Antworten
Stefan_Kunz
User
Beiträge: 5
Registriert: Montag 17. August 2020, 14:06

Hallo zusammen,

es handelt sich evtl. um eine banale Frage, aber vielleicht kann mir dennoch jemand beim folgendem Thema helfen:

Test-Setup:
Mein Rechner und zwei Steuergeräte hängen beide an einem Gateway. Es handelt sich um zwei verschiedene Netzwerk. Zwischen Rechner und Gateway IP = 169.254.... und zwischen Gateway und den Steuergeräten IP = 150.45.199....
Beide Steuergeräte kommunizieren miteinander und das Gateway routet die Pakete an den Rechner.

Ich möchte nun Daten von den Steuergeräten empfangen und auch an die Steuergeräte senden. Es handelt sich dabei um UDP Pakete.
Das Problem ist, dass ich nicht auf welchen Port ich mich binden muss.

s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.bind(("",30510))
data, address = s.recvfrom(1024)

Das Steuergerät sollte die Pakete immer an den Port 30510 senden. Ich weiß aber nicht ob das Gateway beim Routing ebenfalls die Pakete an den Port 30510 (an Rechner) sendet oder irgendeinen anderen verwendet.


In Wireshark sind die Pakete jedoch zu sehen. D.h. das Gateway routet die Pakete an den Rechner und Wireshark kann diese auch empfangen.
Aber wenn ich das über Python versuche erhalte ich keine Pakete.


Wenn ich einen Server und einen Client selbst baue, dann bekomme ich das mit den Sockets hin (also Grundkenntnisse sind vorhanden).
Wie mache ich das aber, wenn der zweite Teilnehmer nicht von mir ist. Es halt ein Gateway, am Rechner über LAN angeschlossen. Was setzte ich beim socket.bind(()) ein, wenn ich nicht weiß wohin die Pakete vom Gateway gesendet werden?

Oder anders gefragt:
Kann ich ganz allgemein Pakete über den LAN Anschluss empfangen, unabhängig vom Port? Ich meine, Wireshark bekommt das ja auch irgendwie hin.

Vielen Dank und schöne Grüße
Stefan Kunz
Sirius3
User
Beiträge: 17711
Registriert: Sonntag 21. Oktober 2012, 17:20

Ein Gateway sollte Pakete nur weiterleiten aber nichts am Port ändern. Von daher sollte alles passen. Ferndiagnosen, warum es dennoch nicht tut, sind aber schwierig.
Stefan_Kunz
User
Beiträge: 5
Registriert: Montag 17. August 2020, 14:06

Ja genau, das ist das, was ich erwarten würde. Sprich: Wenn das Steuergerät eine UDP Nachricht an die IP-Adresse XXX und an Port YYY sendet und das Gateway die Nachricht zu meinen Router über LAN weiterleitet, dann sollte ich die Nachricht auch so empfangen, d.h. selbe IP-Adresse und selber Port (IP XXX und Port YYY).

Dass mein Rechner und das Steuergerät in verschiedenen Netzwerken sind, sollte daran auch nichts ändern, oder?
__deets__
User
Beiträge: 14494
Registriert: Mittwoch 14. Oktober 2015, 14:29

Wenn die Routen stimmen, also Pakete ankommen, dann sollte das passen. Und allgemein werden Zielports niemals umgeschrieben. Denn per Port werden ja die Services identifiziert.
Stefan_Kunz
User
Beiträge: 5
Registriert: Montag 17. August 2020, 14:06

Danke schon Mal für den Support.

Irgendwie glaube ich, dass der Fehler bei mir im Python-Skript liegt - aber was könnte ich denn da falsch gemacht haben? Sollte eigentlich ziemlich Simple sein, wenn man erstmal einfach irgendetwas empfangen möchte.


Wireshark:
Hier kommen die Pakete an. Steuergerät sendet an das Gateway die UDP Nachricht mit IPv4 (Bsp.) 111.222.160.333 und Port (Bsp.) 29900. Das Gateway routet diese Nachricht an meinen Rechner (IPv4 (Bsp.) 333.444.192.80). In Wireshark sehe ich die UDP Nachricht mit der IPv4 und dem Port, welche das Steuergerät verwendet hat. Das passt soweit.


Python (sehr einfach gehalten):
import socket
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.bind((" ",29900)) #hier habe ich den Port verwendet, welches auch das Steuergerät für die UDP Nachricht verwendet hat - siehe auch weiter oben im Text.
data, address = s.recvfrom(1024)
print(data)

In Python empfange ich aber leider nichts.
Benutzeravatar
sparrow
User
Beiträge: 4164
Registriert: Freitag 17. April 2009, 10:28

Schreib Code bitte zwische Code-Tags. Die erscheinen automatisch, wenn du im "Vollständiger Editor & Vorschau" den </> Button drückst. Dazwischen gehört dein Code.

Ich würde als erstes den Port an die gewünschte IP-Adresse binden, statt eines Leerzeichens als Adresse. Oder an "0.0.0.0". Ich weiß, dass eine leere Zeichenkette wie "0.0.0.0" behandelt wird - aber ob das auch für eine Zeichenkette mit einem Leerzeichen gilt, weiß ich nicht.
__deets__
User
Beiträge: 14494
Registriert: Mittwoch 14. Oktober 2015, 14:29

Hast du wirklich ein Leerzeichen im Hostnamen? Das muss denke ich "" sein, wenn du auf alle Schnittstellen binden willst.
Stefan_Kunz
User
Beiträge: 5
Registriert: Montag 17. August 2020, 14:06

Nee, ich habe kein Leerzeichen verwendet. Das war wahrscheinlich ein Tippfehler in meinen letzten Kommentar.

Das Socket an "0.0.0.0" zu binden habe ich ebenfalls versucht. Auch das bringt nicht das gewünschte Resultat.

Wenn ich ein zweites Python Skript starte, in dem ein weiterer Socket erstellt wird und dann an den Port 29900 eine UDP Nachricht sende, dann kann ich diese im Socket vom ersten Skript (also das Socket, was weiter oben dargestellt habe) auch empfangen.

Aber halt nicht die UDP Nachrichten, die über den LAN Anschluss zum Rechner transportiert werden.
Stefan_Kunz
User
Beiträge: 5
Registriert: Montag 17. August 2020, 14:06

Ok. Problem verstanden, Problem gelöst.

Ursache:
In Python werden anscheinend Pakete, die ursprünglich nicht für den Rechner (auf dem das Python Skript ausgeführt wird) bestimmt sind, bereits in einer der unteren Schichten des OSI Modells rausgefiltert.
Diese kommen gar nicht bis zur Applikation an. Daher sehe ich diese auch nicht.

Lösung:
Promiskuitiv aktivieren. Dann werden alle Pakete, die am LAN Port ankommen, zur Applikation transportiert. Kleiner Seitenhieb ist, dass Admin Rechte dafür benötigt werden.
__deets__
User
Beiträge: 14494
Registriert: Mittwoch 14. Oktober 2015, 14:29

Aeh, nein. Ich weiss nicht, was da jetzt die Ursache ist, aber "in Python" wird da ueberhaupt nichts. Das exponiert hier lediglich die System-Socket-Schnittstelle, und alles, was da an Filtern oder aehnlichem greift, ist auch im System verankert, und hat mit Python nichts zu tun. Da ist also Antivirus oder persoenliche Firewall oder was auch immer am Werk.
Antworten