Hallo! Ich möchte ich einen kurzen String vom Controller per UDP über das GSM- Modem an einen Port meiner IP-Adresse daheim senden und irgendwie, am besten(?) per HyperTerminal, diesen zu empfangen. µC: ATMEGA2560 GSM-Modem: Sim340Z HeimRouter: Fritzbox 7170 IP-Adressen heim/GSM: bekannt Die Einwahl des Modems per UDP und das senden eines Strings an einen bestimmten Port einer bestimmten IP klappt (denke ich) bereits. Dies ist in einer AppNote gut beschrieben: Verbindung aufbauen: (AT+CIPSTART=”UDP”, “IP address of the server”, “port number of the server”) String senden: AT+CIPSEND command, then type the data when response “>”, ctrl+z (0x1a) is used to start the sending. Das Reply des Modems spricht dafür, das die Daten tatsächlich gesendet werden. Nun weiss ich nicht, wie ich an den String daheim rankomme: muss ich im Router eine Portfreigabe einstellen? Falls: von wo nach wo? Und welche Einstellugen muss ich bei HyperT treffen? Welche IP eintragen? Die von GSM? oder von daheim? Bin total heiß drauf, diesen kleinen Scheissstring am Terminal zu empfangen aber die vielen verschiedenen Einstellungen zermürben mich. Schönen Gruß Stephan
Na dein GSM-Modem verbindet sich mit dem Internet und schickt die Daten an eine IP, die “IP address of the server” also die Öffentliche adresse deines Routers. Jetzt musst du deinem Router sagen das er allen UDP traffic auf dem Port aus dem Internet in dein Heimnetzwerk an eine Locale IP weiterleiten soll. Wie du das jetzt machst ist Sache von dir und deinem Handbuch des Routers. Das Problem bei UDP ist du machst einen "fire and forget". Daher ist die response eigentlich immer positiv. Das ist wie einen frankierten Brief mit Adresse aus dem Fenster zu werfen. Wenn der Briefträger diesen findet und freundlich ist nimmt er ihn mit. Wenn er im Blumenbeet verottet kannst du auch sagen das du den Brief erfolgreich versendet hast. Bau zum anfangen lieber mal eine TCP Verbindung auf, dann weist du auch ob der Server antwortet. Allerdings basieren meine Aussagen alle auf reinen Vermutungen da nur unzureichende angaben gemacht wurden
Übrigens könnte es äußerst hilfreich sein auf Seiten des Routers bzw. deines lokalen Rechners mit Paketsniffern à la Wireshark bzw. tcpdump zu arbeiten, um mögliche Fehlerquellen minimieren zu können. Mit dem "HyperTerminal" wirst du übrigens nicht besonders weit kommen. Du wirst nicht drum herum kommen einen kleinen "Server" zu schreiben, der auf dem von dir festgelegten Port "lauscht". Wie genau das geht hängt natürlich von Programmiersprache und Betriebssystem ab, ist aber im Falle einer einfachen UDP Verbindung mit wenigen Zeilen machbar.
Hab mir nu einen UDP-Client-Server downgeloadet und tataaa! das "Hallo" kommt an! Ich bin noch ein bissel skeptisch, weil es ein wenig zu einfach ist! Nächste Mission: UPD zwischen zwei GSMModems. Danke erstmal, kommmen sicher noch Fragen!
Stephan schrieb:-. > Nächste Mission: UPD zwischen zwei GSMModems. Das wird so nix. Es sei denn du hast spezielle verträge bei denen du öffentliche IPs bekommst... bei allen anderen kommst du hinter ein NAT.
-.- schrieb: > Das wird so nix. Es sei denn du hast spezielle verträge bei denen du > öffentliche IPs bekommst... bei allen anderen kommst du hinter ein NAT. Könnte vielleicht schon funktionieren - wenn beide hinter dem gleichen Provider-NAT im gleichen Netz hängen.
Es kann schwer errden zwischen zwei Geräten UDP Pakete zu übertragen. Vor ein paar Jahren sind schon einmal menschen auf die Idee gekommen Daten direkt zwischen GSM Geräten zu übertragen. Die Netzbetreiber haben das lange nicht gemerkt da die Abrechnung darauf beruht fas der Datenverkehr an den Routern auf die APN bezogen gezählt wird. Der Traffic über die alten "Walled-Gardens" war aber kostenlos, weil man da sowieso nur die Angebote der Netzbereiber nutzen konnte. Darum war die Idee einfach den APN des Walled-Gardens einzutragen und dann Datentraffik von Gertät zu gerät zu machen. Das hat gut funktioniert. Die Netzbetreiber konnten das nicht abrechnen und haben es lange zeit auch gar nicht gemerkt. Inzwischen sind diese "Lücken" bei allen Netzbetreibern gestopft. Es kann sein das dafür in den Routern der direkte Traffik zwischen Geräte-IP Adressen blockiert wurde. Das zweite Problem ist das die verwendeten IP-Adressräume schon lange nicht mehr ausreichen. Darum teilen die Netzbetreiber Deuthscland in Regionen auf. IP-Adressen werden dann mehrfach vergeben. Wenn man also z.B. ein Gerät in Hambur hat und ein zweites in München, dann werden die trotzdem nicht direkt miteinander kommunizieren können, auch wenn die Adressen bekannt sind. Der einzig sichere Weg ist es einen TCP/Tunnel zu einem Server im Internet auf zu bauen und disen als Relaisstation zu nutzen. Da Handys heute ja oft schon VPN an Bord haben sollte das relativ leicht möcglich sein. Das sollte Dich aber nicht daran hindern weiter zu experimentieren. Vorausstezungen; gleicher Netzbetreiber, gleiche Region
dulle schrieb: > Das zweite Problem ist das die verwendeten IP-Adressräume schon lange > nicht mehr ausreichen. Darum teilen die Netzbetreiber Deuthscland in > Regionen auf. IP-Adressen werden dann mehrfach vergeben. Dürfte man dazu denn Details bzw. Stichwörter erfahren? Meines Wissens setzen die Betreiber schlichtweg auf NAT. Ich jedenfalls bekomme bei jedem mir bekannten Anbieter eine private IP aus dem 10/8 Netz. -.- schrieb: > Das wird so nix. Es sei denn du hast spezielle verträge bei denen du > öffentliche IPs bekommst... bei allen anderen kommst du hinter ein NAT. Gerade bei UDP ist das noch machbar. Stichwort: NAT-Traversal, siehe [1]. Das bedarf halt schon ein bisschen mehr Wissen im Bereich der Netzwerktechnik und ist nicht unbedingt ein Thema für einen Netzwerkanfänger. Mit freundlichen Grüßen, Karol Babioch [1]: https://de.wikipedia.org/wiki/Network_Address_Translation#NAT-Traversal
Es sind mehr telefone eingewählt als es ip adressen im 10er netz gibt. Darum werden die selben Adressen mehrfach vergeben, aufgeteilt in Regionen. Für M2M businesskunden gibt es spezielle Verträge mit gesonderten IP-Adressbereichen. Eigentlich müssten die Netzbetreiber auf IPV6 umstellen, aber das kostet nunmal Geld und muss langfristig umgesetzt werden, das geht nocht von Heute auf Morgen. Also versucht man aus IPV4 herfaus zu holen was geht. Die regionale Unterteilung ist ja auch erst mal ok, was allerdings passiert wenn man sich mit dem handy über eine "Regionengrenze" bewegt, weis ich nicht. Verbindungsabbrüche sind allerdings auch nichts ungewöhnliches beim mobiltelefon.
dulle schrieb: > Es sind mehr telefone eingewählt als es ip adressen im 10er netz gibt. Ja, und? Das ist Sinn und Zweck von privaten IP-Adressen. Die meisten, die hinter einem Router hängen, sind ja auch mit einer 192.168/16 Adresse unterwegs. Ich bekomme bei meinem Provider sowieso eine IP aus einem /30 Netz. Das kommt im Endeffekt einer Point-to-Point Verbindung gleich, d.h. sämtlicher Traffic fließt über den Router des Providers. dulle schrieb: > was allerdings passiert wenn man sich mit dem handy > über eine "Regionengrenze" bewegt, weis ich nicht. Nichts. Die Geräte, sofern sie überhaupt miteinander kommunizieren, tun dies ja über ihre öffentlichen IP-Adressen, und dabei würde die gleiche private IP-Adresse auf beiden Seiten nicht stören bzw. keine der beiden würde davon etwas mitbekommen. dulle schrieb: > was allerdings passiert wenn man sich mit dem handy > über eine "Regionengrenze" bewegt, weis ich nicht. Verbindungsabbrüche > sind allerdings auch nichts ungewöhnliches beim mobiltelefon. Verbindungsabbrüche haben hiermit aber rein gar nichts zu tun und rühren von ganz anderen Faktoren. Wir reden hier über die IP bzw. UDP Schicht. Die Funktionsweise von IP (und darüber liegenden Schichten) ist gleich - egal, ob unterwegs am Handy, oder daheim am Rechner. Adresskollisionen im Bereich der privaten IPs sind nur beim Einsatz von VPNs problematisch, da die involvierten Rechner dann mit dem Routing durcheinander kommen können. Wobei das hier mit o.g. /30 Netz auch eher eine theoretische Gefahr sein dürfte. Mit freundlichen Grüßen, Karol Babioch
Nach meinen versuchen sind die clients jeweils isoliert... somit nix von a nach b so ohne weiteres.
... schrieb: > Nach meinen versuchen sind die clients jeweils isoliert... somit nix von > a nach b so ohne weiteres. Was heißt "isoliert"? Wie ich oben ausgeführt habt, findet die Kommunikation aufgrund des /30 Netzes sowieso über die dazwischenliegenden Router statt. Oder meinst du, dass sich beide Teilnehmer hinter einem NAT befinden? Mit freundlichen Grüßen, Karol Babioch
Hallo. Ich richte mich darauf ein, eine Art Relaisstation zu verwenden, sprich, "irgendetwas" mit dem sich beide Module verbinden, und wenn "es" an Port x etwas empfängt soll es das an y weitersenden. Ungern würd ich dafür einen Rechner ständig laufen lassen. Ließe so etwas sich nicht mit Diensten a´la DynDNS realisieren? Ich stelle mir vor: beide Module stellen eine Verbindung mit einem jeweiligen Port der Domain "meiner" DynDNS- Seite her. Dort hin gesendete Daten würden ja an die IP meines Heimrouters weitergeleitet. Dort könnte eine Portfreigaberegel bestimmen, dass alle bei x eigehenden Daten nach y geleitet werden, sprich, an den Port de anderen Modems. Realistisch?
Stephan schrieb: > dass alle bei x eigehenden > Daten nach y geleitet werden, sprich, an den Port de anderen Modems. In dieser Form wird das nicht funktionieren. "y" müsste sich zuvor auch mit deinem Dienst verbinden. Der wesentliche Punkt ist, dass die Verbindung von "y" initiiert wird, sonst stehst du vor dem selben Problem wie auch zuvor schon ohne dritte Partei. Stephan schrieb: > Ungern würd ich dafür einen Rechner ständig laufen lassen. Ließe so > etwas sich nicht mit Diensten a´la DynDNS realisieren? Inwiefern schließt denn die Nutzung von dynamischen DNS aus, dass ein Rechner ständig laufen muss? DynDNS ermöglicht es nur, dass du den entsprechenden Rechner immer findest, auch bei sich ändernder IP. Je nachdem welchen Router du verwendest, würde sich so etwas aber direkt auf dem Router implementieren lassen. Da dieser sowieso läuft, "verschwendest" du nicht unnötig Energie. Eine Alternative wäre etwas wie ein Raspberry Pi (oder ähnliches). Allerdings sollte man man vielleicht dazu sagen, dass du auch über Authentifizierungsmechanismen und Verschlüsselung nachdenken solltest ;). Sonst kann ein jeder Nachrichten an deine Geräte verschicken. Je nach Implementierung ist das ein mögliches Einfallstor, um größeren Schaden anzurichten. Mit freundlichen Grüßen, Karol Babioch
Ich komme (gehirnmäßig) nicht weiter. Wenn Modem 1 sich mit der IP meines Routers verbindet und an Port 100 etwas sendet: empfängt es denn Modem 2, wenn es sich ebenda hin verbunden hat und an Port 100 lauscht?
Stephan schrieb: > Wenn Modem 1 sich mit der IP meines Routers verbindet und an Port 100 > etwas sendet: empfängt es denn Modem 2, wenn es sich ebenda hin > verbunden hat und an Port 100 lauscht? Ich glaube du solltest dich nochmal mit den Netzwerkgrundlagen auseinander setzen. Auch wenn das jetzt vielleicht böse klingt, ist es nicht so gemeint. Ich möchte dir nur unnötige Arbeit und Frust im weiteren Verlauf des Projekts ersparen. Das Konzept "verbinden" gibt es im Falle von UDP nämlich in dieser Form gar nicht. Da habe ich mich oben auch etwas unglücklich ausgedrückt. Der Client verschickt einfach seine Pakete, der Server empfängt diese - sofern alles "gut" läuft. Nochmal zum eigentlichen Problem: Beide Parteien befinden sich hinter einem NAT-Router. Dadurch ist der direkte Kontakt ausgeschlossen. Sobald der jeweils dazwischenliegende NAT-Router ein "unerwartetes" Paket empfängt, verwirft er dieses schlichtweg. Du könntest jetzt natürlich einen Dienst auf deinem Router laufen lassen (bzw. einem Rechner in deinem Netzwerk und mit entsprechenden Portweiterleitungen arbeiten). Beide Endgeräte würden dann diesen kontaktieren, wodurch es diesem Dienst ermöglicht wird zu antworten, da die dazwischenliegenden NAT-Router entsprechende Einträge in ihren intern verwalteten Tabellen vornehmen. Dieser Dienst müsste nun, nachdem er die IP-Adressen beider Parteien kennt, und diese (für eine beschränkte Zeit) kontaktieren kann, die von einer Partei eingehenden Pakete an die jeweils andere Partei weiterleiten. Keine Ahnung, ob du echten Duplexbetrieb benötigst, aber das würde eine Unterscheidung zwischen Sender und Empfänger unnötig machen und das Ganze vereinfachen. Das ist durchaus machbar und sollte in seiner Grundform nicht allzu aufwendig sein. Die aus Sicht der Netzwerktechnik bessere Alternative wäre aber ein "echtes" NAT-Traversal, wie oben bereits angedeutet. Dafür brauchst du auch die dritte Partei - allerdings nur zu Beginn des Prozedere. Damit wäre eine mögliche Fehlerquelle bzw. ein Flaschenhals aus dem Weg geschafft. Viel komplizierter ist es eigentlich auch nicht, und ein praktikabler Algorithmus wird hier [1] beschrieben. Eine aus sicherheitstechnisch brauchbare Alternative wäre die Verwendung eines VPN, wobei sich beide Parteien beim VPN-Server, der auf dem Router läuft, einwählen würden. Durch eine entsprechende Konfiguration wären damit auch beiden Parteien untereinander verbunden - und zwar verschlüsselt. Das wird bei der von dir verwendeten Hardware aber nicht möglich sein :(. Auf gut Deutsch: Um die dritte Partei kommst du nicht herum, also kannst du es gleich richtig machen ;). Mit freundlichen Grüßen, Karol Babioch [1]: https://en.wikipedia.org/wiki/UDP_hole_punching
Na gut, plane ich halt eine "dritte Partei" ein. Unglücklich ist, dass mein Rechner (der, der mal mit dem Modem kommunizieren soll) selbst über Simkarte online ist. Aber dafür ist heute zu spät! Danke erstmal, ich werde nochmal drauf zurückkommen!
Stephan schrieb: > Unglücklich ist, dass mein Rechner (der, der mal mit dem Modem > kommunizieren soll) selbst über Simkarte online ist. Du hast oben von Router gesprochen? Die "dritte Partei" muss natürlich für die anderen beiden Parteien erreichbar sein. Ansonsten kommst du nicht wirklich weiter. Mit freundlichen Grüßen, Karol Babioch
Karol Babioch schrieb: > Du hast oben von Router gesprochen? Japp. Zurzeit kommunizert mein GSM-Modem mit der IP-Adresse meines Heimrouters. Das klappt ja auch wunderbar. (Wie groß ist eigentlich die tatsächliche "Gefahr" durch die Portfreigabe, die ich dazu eingerichtet habe? Ich möchte nun aber versuchen, zwischen mobilem Laptop und dem GSM-Modem zu kmmunizieren. Sprich: Auf dem (per GSM mobilen) Laptop läuft ein kleines Bedienprogramm, welches irgendwie Strings mit dem weit entfernten GSM-Modem austauscht.
Stephan schrieb: > Sprich: Auf dem (per GSM mobilen) Laptop läuft ein kleines > Bedienprogramm, welches irgendwie Strings mit dem weit entfernten > GSM-Modem austauscht. Dann ist die o.g. "dritte Partei" aber nach wie vor dein "Heimrouter", der von "außen" für jeden erreichbar ist. Stephan schrieb: > Wie groß ist eigentlich die tatsächliche "Gefahr" durch die > Portfreigabe, die ich dazu eingerichtet habe? Die "typische" Gefahr, der man sich aussetzt, sobald man etwas ans Netzwerk hängt. Fehler bzw. Unaufmerksamkeiten innerhalb deines Programms lassen sich ggf. ausnutzen, um den Programmfluss zu verändern und dadurch Kontrolle über den Dienst bzw. sogar deinen Rechner zu erhalten. Sowohl deine IP als auch den konfigurierten Port solltest du als "öffentlich" einsehbar betrachten. Deine IP hinterlässt du höchstwahrscheinlich auf jeder Seite, die du besuchst und ist von dortigen Adminstratoren einsehbar. Auch wenn Portscans über UDP nicht so einfach wie im Falle von TCP sind, ist es je nach Konfiguration durchaus möglich auf offene Ports zu schließen. Außerdem gibt es ja höchstens nur etwa 65k Möglichkeiten ;). Mit freundlichen Grüßen, Karol Babioch
Ich würde gern mehr Zeit in das, WAS zu senden ist und wie es zustande kommt investieren als in die Frage danach, WIE es ankommt. Frage zum UDP hole punching: da steht, es wären öffentlich zugängliche IP Adressen benötigt- die hat GSM doch aber nicht oder?
Stephan schrieb: > die hat GSM doch aber nicht oder? Doch klar. Die öffentlich zugängliche IP Adresse ist diejenige Adresse, die eine neutrale Partei zu sehen bekommt, wenn du ein Paket nach "außen" verschickst. Die im dahinter liegenden NAT befindlichen Hosts sind im o.g. Beispiel als "A" und "B" bezeichnet: > Let A and B be the two hosts, each in its own private network; N1 and N2 > are the two NAT devices with globally reachable IP addresses P1 and P2 > respectively; S is a public server with a well-known globally reachable > IP address. Mit freundlichen Grüßen, Karol Babioch
Lässt sich das mit VisualBasic für den danndauerhaftlaufenden Heimrechner programmieren?
Ich sag erstmal gut Nacht und hoffe, Du findest den Threat nochmal wieder und ich kann auf dich zurückgreifen, hört sich gut an was Du schreibst- nur mir wirds bissel spät. Bis hoffentlich später, Stephan, Kiel
Stephan schrieb: > Lässt sich das mit VisualBasic für den danndauerhaftlaufenden > Heimrechner programmieren? Das wäre halt ein klassisches Beispiel von "mit Kanonen auf Spatzen geschossen". Letztendlich ist der benötigte Dämon so einfach, dass man das mit ein paar Zeilen C hin bekommen sollte. Das lässt sich dann nämlich auch für den Router bzw. andere "energieeffiziente" Geräte kompilieren. Dafür extra einen Heimrechner laufen zu lassen, würde mein (Umwelt-)Gewissen belasten ;). Mit freundlichen Grüßen, Karol Babioch
Was -ausser Raspberry pi- wäre denn eine geeignete, stromsparende Hardware? Ich denke nicht, dass im Router ein Programm änder kann /sollte.
Stephan schrieb: > Was -ausser Raspberry pi- wäre denn eine geeignete, stromsparende > Hardware? Ich persönlich bin großer Advokat von Linuxsystemen, wenn es um das Lösen von Problemen bzgl. Netzwerken geht. Das bringt einen ausgereiften Netzwerkstack mit, und ist i.d.R. relativ einfach zu programmieren. Mittlerweile gibt es da mehr Möglichkeiten als man aufzählen könnte. Eine von vielen z.B. wäre GNUBLIN, siehe [1]. Ansonsten einfach mal nach embedded Linux Systemen suchen. Stephan schrieb: > Ich denke nicht, dass im Router ein Programm änder kann > /sollte. Warum nicht? Ich kenne die FRITZ!Box nicht wirklich, aber das setzt meines Wissens auch alles auf Linux auf. Insofern sollte es prinzipiell schon möglich sein ;). Mit freundlichen Grüßen, Karol Babioch [1]: http://shop.embedded-projects.net/
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.