Hallo,
vor einer Weile hatte ich ja schonmal ein paar Fragen zum Thema Sockets gestellt. Die liessen sich alle auf wundersame Weise lösen, doch nun stehe ich vorm nächsten Problem. Das Tool dient (zur Erinnerung) dem Steuern des Routers der TK Eumex 620 Lan unter Linux.
Vorgeschichte:
Man kann den Router der Anlage mit bestimmten Packeten Starten und Stoppen und somit verhindern das sich die Anlage ungewollt einwählt. Dies geht aber nur wenn kein anderer Rechner, z.B. der Win Rechner meines Vaters hochgefahren ist. Denn die Software "Home Capi Control" die zur Anlage gehört, meldet sich bei der Anlage an und ich habe erst vor kurzem herausgefunden wie die Authentifizierung funktioniert. Nun möchte ich natürlich das die Authentifizierung auch von meinem Tool simuliert wird.
Problem: Normalerweise antwortet die Anlage in einem Broadcast wenn KEIN anderer Rechner sich an der Anlage angemeldet hat. Das sieht dann z.B. so aus: Ich (192.168.69.7) sende ein Packet mit einer Routerstatusabfrage und bekomme als Antwort von der Anlage (192.168.69.254) einen Broadcast (192.168.69.255) mit der nötigen Routerinformation (..ist gestartet/..ist gestoppt..).
WENN sich ein Rechner an der Anlage angemeldet hat antwortet die Anlage DIREKT auf die IP des anmeldenten Rechners. Also kein Broadcast an 192.168.69.255 sondern eine direkte Antwort an 192.168.69.7.
Das Empfangen von Daten als Broadcast klappt ohne Probleme ( recvfrom() ). Die Anlage sendet die Antworten an alle Anfragen an Port 9997. Zum Empfangen der Broadcasts an Port 9997 muss ich nichteinmal den Socket auf listen setzen. Alle anderen Packete, also die direkt beantworteten kommen bei mir aber nicht an. Stattdessen antwortet der Kernel mit einem ICMP (Destination unrechable) an die Anlage. Das wiederum liegt ja mit hoher Wahrscheinlichkeit daran das ja der Port 9997 nicht offen im Sinne von listen ist. Wenn ich ihn aber auf listen setzen will erhalten ich ein "Operation not supported!". Was mache ich falsch? Wie kann ich die Daten die für meine IP bestimmt sind denn dann empfangen?
Freunlich grüßend, Martin
PS: Entschuldigt bitte den Traffic und den Spaghetticode... :)
Am 16. Juli 2003 schrieb Martin Weissbach:
vor einer Weile hatte ich ja schonmal ein paar Fragen zum Thema Sockets gestellt.
Mal eine Frage: wieso nimmst du SOCK_RAW anstelle SOCK_DGRAM? Es sind doch UDP-Pakete, oder?
Torsten
Torsten Werner email@twerner42.de wrote:
Am 16. Juli 2003 schrieb Martin Weissbach:
vor einer Weile hatte ich ja schonmal ein paar Fragen zum Thema Sockets gestellt.
Mal eine Frage: wieso nimmst du SOCK_RAW anstelle SOCK_DGRAM? Es sind doch UDP-Pakete, oder?
Um den IP Header manipulieren zu können. Dies ist bei SOCK_DGRAM nicht möglich.
Am 16. Juli 2003 schrieb Martin Weissbach:
Um den IP Header manipulieren zu können. Dies ist bei SOCK_DGRAM nicht möglich.
Ach so, klar. Aber dafür muss man root sein und als root klappt es bei mir. Bei dir nicht?
Torsten
Torsten Werner email@twerner42.de wrote:
Am 16. Juli 2003 schrieb Martin Weissbach:
Um den IP Header manipulieren zu können. Dies ist bei SOCK_DGRAM nicht möglich.
Ach so, klar. Aber dafür muss man root sein und als root klappt es bei mir. Bei dir nicht?
Ja dafür muss man root sein, weil normalerweise der Kernel die Packete zusammenbaut. Sobald statt SOCK_RAW, SOCK_DGRAM verwendet wird sollte setsockopt() meckern und es sollte sowas wie: "setsockopt() failed: Protocol not available" dastehen.
Was meinst du aber mit
als root klappt es bei mir. Bei dir nicht?
Die Headermanipulation klappt. Das Programm funktioniert ohne Probleme, nur erhalte ich keine Antworten die direkt für meine IP Addresse bestimmt sind.
MfG, Martin
Am 16. Juli 2003 schrieb Martin Weissbach:
Die Headermanipulation klappt. Das Programm funktioniert ohne Probleme, nur erhalte ich keine Antworten die direkt für meine IP Addresse bestimmt sind.
Hmm, ich hab es noch nicht verstanden. Wenn du mit raw sockets arbeitest, um die Absenderadresse zu fälschen, wirst du nie Antwortpakete außer Broadcasts bekommen. Unicasts bekommst du höchstens, wenn die Netzkarte im promiscous mode ist. Für beides brauchst du root-Rechte. Willst du dagegen an deine IP-Adresse gerichtete Pakete empfangen, solltest du mit UDP sockets arbeiten. Dann brauchst du bei den hohen Portnummern auch keine root-Rechte mehr.
Torsten
Torsten Werner email@twerner42.de wrote:
Am 16. Juli 2003 schrieb Martin Weissbach:
Die Headermanipulation klappt. Das Programm funktioniert ohne Probleme, nur erhalte ich keine Antworten die direkt für meine IP Addresse bestimmt sind.
Hmm, ich hab es noch nicht verstanden. Wenn du mit raw sockets arbeitest, um die Absenderadresse zu fälschen, wirst du nie Antwortpakete außer Broadcasts bekommen. Unicasts bekommst du höchstens, wenn die Netzkarte im promiscous mode ist.
Wenn ich eine falsche Absenderaddresse angebe --> logisch. Aber wieso werde ich keine Antwortpakete erhalten wenn ich die korrekte IP angebe? Die Anlage antwortet mir (per ethereal überprüft) korrekt, der Kernel schickt dann ein Destination unreachable Typ 3 ICMP (also Port unreachable) los. Denkst du nicht das es eher daran liegt? Wenn du willst kann ich dir ja mal nen Trace schicken...
Für beides brauchst du root-Rechte. Willst du dagegen an deine IP-Adresse gerichtete Pakete empfangen, solltest du mit UDP sockets arbeiten. Dann brauchst du bei den hohen Portnummern auch keine root-Rechte mehr.
Das ist klar. Aber brauche die Raw Sockets um einen bestimmten Source Port zu erzeugen. Sonst funktioniert das ganze nicht. An Raw Sockets komm ich hier nicht vorbei. Ich könnte natürlich zum empfangen einen nicht Raw Socket nehmen. Ok ich denke ich werds so mal probieren. Danke für den Tipp.
MfG, Martin
lug-dd@mailman.schlittermann.de
-
Martin Weissbach -
Torsten Werner