Moin, ich betreibe einen Server (derzeit ein Raspberry Pi 4; später vielleicht eine andere Plattform) in einem Netzwerk, das nach außen eine dynamische IP-Adresse hat. Auf den Server greift per Portforwarding (irgendein Dyn-DNS-Anbieter) ein Gerät mit ublox-LTE-Modem zu. Die Verbindung soll ständig verfügbar sein. Im Normalbetrieb funktioniert das auch, nur die nächtliche Zwangstrennung führt zu Problemen. An der lokalen Netzwerk-Geschichte kann und darf ich nichts drehen. Derzeit lasse ich alle x-Minuten ein DNS-Resolve durchführen, was bei der Zwangstrennung aber leider nicht den gewünschten Erfolg bringt (, sondern sorgt dafür, dass sich "mein" System aufhängt). Hat jemand einen Tipp für mich, wie ich das hinbekommen kann? Viele Dank im Voraus.
:
Verschoben durch Admin
Rahul D. schrieb: > nächtliche Zwangstrennung Wo gibt es denn sowas noch? Ansonsten lautet deine Beschreibung im Prinzip "funzt nicht". Was funzt nicht? Wie äussert sich das? Wenn du einen funktionierenden Dyn-DNS-Dienst hast, und dein Server und der Client richtig funktionieren, funzt das. Dafür ist Dyn-DNS schließlich gedacht. Wenn es nicht funzt, machst ist was verkehrt. Oliver
Rahul D. schrieb: > ständig verfügbar Rahul D. schrieb: > Zwangstrennung Eine Zwangstrennung trennt, wie der Name schon sagt, die Internetverbindung. Was verstehst du also unter "ständig verfügbar"? Rahul D. schrieb: > Derzeit lasse ich alle x-Minuten ein DNS-Resolve durchführen, was bei > der Zwangstrennung aber leider nicht den gewünschten Erfolg bringt (, > sondern sorgt dafür, dass sich "mein" System aufhängt). Wer führt den DNS-Resolve aus? Dein Server (warum sollte er das tun?) oder das andere System (warum hängt sich dann dein System auf?)?
Rahul D. schrieb: > irgendein Dyn-DNS-Anbieter Er will anscheinend bei obigen Anbieter, seine neue IP-Adrtesse schnellstmöglich bekanntgeben, mit seinem DNS-Resolve... Bei mir hatte das damals die Fritzbox erledigt und direkt mit dem Dyn-DNS-Anbieter geschnackt!?
Jan H. schrieb: > Was verstehst du also unter "ständig verfügbar"? Dass die Verbindung zwischen Client und Server eine Standleitung ist, und der Kunde jederzeit auf System mit dem ublox-Modem zugreifen kann (Fernwartung). Jan H. schrieb: > Wer führt den DNS-Resolve aus? Dein Server (warum sollte er das tun?) Genau. Warum sollte ein Server seine IP-Adresse erfragen? Der soll keine Selbstgespräche führen. > oder das andere System Ja, die Remote-Stelle fragt die IP des Servers an. > (warum hängt sich dann dein System auf?)? Andere Baustelle... Oliver S. schrieb: > Wo gibt es denn sowas noch? Bei uns scheinbar. Wir haben zwar Glasfaser, aber es scheint (manchmal) zu einer Verbindungstrennung zu kommen. Meine Frage zielte darauf ab, ob jemand einen besseren Vorschlag hat, wie man als Client erkennt, dass der Server ab jetzt über eine andere IP-Adresse zu erreichen ist.
Teo D. schrieb: > Er will anscheinend bei obigen Anbieter, seine neue IP-Adrtesse > schnellstmöglich bekanntgeben, mit seinem DNS-Resolve... Bei mir hatte > das damals die Fritzbox erledigt und direkt mit dem Dyn-DNS-Anbieter > geschnackt!? Es muss nicht schnellstmöglich sein. Bei uns erledigt das auch die Fritzbox.
Rahul D. schrieb: > Teo D. schrieb: >> Er will anscheinend bei obigen Anbieter, seine neue IP-Adrtesse >> schnellstmöglich bekanntgeben, mit seinem DNS-Resolve... Bei mir hatte >> das damals die Fritzbox erledigt und direkt mit dem Dyn-DNS-Anbieter >> geschnackt!? > > Es muss nicht schnellstmöglich sein. > Bei uns erledigt das auch die Fritzbox. Danke für die Info und BB PS: Was soll das, willst du nicht mal versuchen die Missverständnisse aufzuklären?-O
Teo D. schrieb: > Was soll das, willst du nicht mal versuchen die Missverständnisse > aufzuklären?-O Welche? Das System sieht so aus: hier vorort hinter einer Fritzbox mit Portwarding und einer dynamischen IP-Adresse, die von einem ensprechenden DynDNS-Provider veröffentlicht wird, befindet sich ein Server. Der Client befindet sich irgendwo, wo er per LTE mit dem Internet kommuniziert, und sammelt Daten. Die Daten werden auf den Server übertragen. Das funktioniert soweit. Wenn die Verbindung ordendtlich beendet wird (Socket schließen), erkennen das auch beide Seiten problemlos; egal auf welcher Seite der Socket geschlossen wird. Wenn die Verbindung aber aufgrund des IP-Wechsels unterbrochen, funktioniert es nicht. Der Client bzw. die Remote-Stelle soll auch mit dem Server verbunden sein, wenn gerade keine Daten zum Server übertragen werden. Prinzip einer Standleitung... Was ist jetzt noch missverständlich?
Rahul D. schrieb: > Der Client bzw. die Remote-Stelle soll auch mit dem Server verbunden > sein, wenn gerade keine Daten zum Server übertragen werden. > Prinzip einer Standleitung... Hm. Was genau versteht derjenige, der das fordert, unter "verbunden sein"? Standleitung und TCP/IP sind konzeptionell irgendwie wenig kompatibel. Oliver
Ich habe einen HP Microserver an einer VDSL Leitung hängen, da buchen sich unter anderem mehrere OpenVPN Verbindungen drauf. Habe DynDNS konfiguriert, direkt im Router. Läuft einwandfrei. Wichtig war nur: DNS Eintrag wirklich als dynamisch anlegen, damit der nicht in irgendeinem Cache landet. Und im VPN Client konfigurieren, dass vor dem neuen Verbringungsversuch ein nslookup erfolgt. Genau dafür ist DNS gemacht, wenn dein Anbieter dir was anderes erzählt solltest du wechseln. (Selber schon erlebt "sie dürfen hier nur 1x täglich ein NS Update senden was machen sie da?!")
Rahul D. schrieb: > Das System sieht so aus: > hier vorort hinter einer Fritzbox mit Portwarding und einer dynamischen > IP-Adresse, die von einem ensprechenden DynDNS-Provider veröffentlicht > wird, befindet sich ein Server. > Der Client befindet sich irgendwo, wo er per LTE mit dem Internet > kommuniziert, und sammelt Daten. > Die Daten werden auf den Server übertragen. > > Wenn die Verbindung ordendtlich beendet wird (Socket schließen), > erkennen das auch beide Seiten problemlos; egal auf welcher Seite der > Socket geschlossen wird. Das wirst du nicht bekommen. Dann die Zwangstrennung macht eine ansonsten "stille" Instanz. Die müßte schon ankündigen, daß eine Zwangstrennung ansteht. AFAIK kann man die FritzBox aber so konfigurieren, daß sie die Trennung von sich aus und zu einer festen Zeit vornimmt. > Wenn die Verbindung aber aufgrund des IP-Wechsels unterbrochen, > funktioniert es nicht. Dann ist das Protokoll ungeeignet. Abgerissene Verbindungen kann man erkennen (TCP keepalive) und neu verbinden. Rahul D. schrieb: >> (warum hängt sich dann dein System auf?)? > Andere Baustelle... Aber die einzig relevante Baustelle. Unter der Annahme, daß der Server hinter einer DSL-Einwahlverbindung hängt, können 3 Dinge passieren: - Servername löst korrekt auf, Server antwortet - Servername löst auf, aber Server antwortet nicht - Servername löst nicht auf beide Fehlerfälle können mit Zeitdauer wenige Sekunden bis Stunden auftreten. Deine Software muß damit klarkommen. Oder du nimmst Geld in die Hand und spendierst dem "Server" eine richtige Netzanbindung.
Leute, so ne Soketverbindung sollte wegen einer IP-Adressenderung nicht verlorengehen! Liegt also sicher am Client, der damit nicht umgehen kann.
Axel S. schrieb: > Rahul D. schrieb: >>> (warum hängt sich dann dein System auf?)? >> Andere Baustelle... > > Aber die einzig relevante Baustelle. Unter der Annahme, daß der Server > hinter einer DSL-Einwahlverbindung hängt, können 3 Dinge passieren: > > - Servername löst korrekt auf, Server antwortet > - Servername löst auf, aber Server antwortet nicht > - Servername löst nicht auf > > beide Fehlerfälle können mit Zeitdauer wenige Sekunden bis Stunden > auftreten. Deine Software muß damit klarkommen. Oder du nimmst Geld in > die Hand und spendierst dem "Server" eine richtige Netzanbindung. Danke für die Antwort. Das Thema ist in Arbeit. Ich kann leider hier nicht einfach mal die Verbindung zum Provider kappen - da gibt's Mecker von den Kollegen. Der Server soll am Ende vom Kunden betrieben werden. Und ich habe von dem ganzen Zeug wenig bis keine Ahnung (deswegen teilweise auch eine etwas einfache Nomenklatur meinerseits).
Teo D. schrieb: > Leute, so ne Soketverbindung sollte wegen einer IP-Adressenderung > nicht > verlorengehen! Liegt also sicher am Client, der damit nicht umgehen > kann. Danke, das meinte ich. Manchmal braucht man einen Dolmetscher ;)
Oliver S. schrieb: > Rahul D. schrieb: >> nächtliche Zwangstrennung > > Wo gibt es denn sowas noch? Mindestens bei o2.
Eine Socketverbindung verbindet 2 IP-Adressen. Wenn sich davon eine aendert, wars das mit der Socketverbindung. Da hilft auch kein DNS-Service.foobaz
Fakt ist, manche Geräte kommen damit klar, andere nicht. Also geht es technisch und die die es nicht können, haben defekten Code.
Teo D. schrieb: > Leute, so ne Soketverbindung sollte wegen einer IP-Adressenderung nicht > verlorengehen! Liegt also sicher am Client, der damit nicht umgehen > kann. Die Socketverbindung wird mit Sicherheit verlorengehen wenn eine der Seiten ihre IP ändert. Aber der Client sollte diesen Zustand von sich aus erkennen können und dann zuverlässig eine neue Verbindung zum Server aufbauen. Die Logik dafür muss im Client liegen. Denn der Server hat von sich aus keinerlei Möglichkeit den Client zu erreichen, denn der Client ist über Mobilfunk angebunden und daher hinter dem CG-NAT/Firewall des Mobilfunkanbieters und kann daher nur ausgehende Verbindungen aufbauen.
> Die Logik dafür muss im Client liegen.
Man koennte den Traffic auch tunneln. Dann koennte auch die
Serverseite die Verbindung in Richtung Tunnel neu aufbauen.
Ist natuerlich nicht unsonst und braucht ein Tunnelgateway
im Internet.
Gerd E. schrieb: > Die Socketverbindung wird mit Sicherheit verlorengehen wenn eine der > Seiten ihre IP ändert. Tut sie. Gerd E. schrieb: > Aber der Client sollte diesen Zustand von sich aus erkennen können und > dann zuverlässig eine neue Verbindung zum Server aufbauen. Ich frage regelmäßig die IP-Adresse per DNS-Resolve ab. Meine Frage war, ob man das noch besser machen kann. > Die Logik dafür muss im Client liegen. Denn der Server hat von sich aus > keinerlei Möglichkeit den Client zu erreichen, denn der Client ist über > Mobilfunk angebunden und daher hinter dem CG-NAT/Firewall des > Mobilfunkanbieters und kann daher nur ausgehende Verbindungen aufbauen. Genau. Und das ist das Problem. Irgendwelche Tunnels und VPNs lassen sich auf dem Controller nur schwer umsetzen, da er mit seiner Hauptaufgabe, Messdaten zu sammeln, schon gut ausgelastet ist. Kunden- (bzw. Chef-) Vorgaben waren, dass nicht noch mehr Hardware dazukommen soll. Axel S. schrieb: > Aber die einzig relevante Baustelle. Die Baustelle war ein "__breakpoint();" ... sowas sollte man VOR einem Test auskommentieren. (Oder Tests nicht am Freitag Nachmittag zwischen Tür und Angel starten). PS: Es gab heute Nacht eine Zwangstrennung. Ob die von der Fritzbox oder dem Provider kam, interessiert (mich) aber nicht weiter, da nur ihr (mögliches) Auftreten relevant ist.
:
Bearbeitet durch User
> Ich frage regelmäßig die IP-Adresse per DNS-Resolve ab. > Meine Frage war, ob man das noch besser machen kann. Ja, der Client muss fuer seine Socketverbindung die TCP-Option "keepalive" nutzen. Nur dann bekommt der Client zuverlaessig mit, das die Verbindung irgendwo getrennt wurde und der Client die Verbindung neu aufbauen muss. Die DNS-Anfragen erkennen das wesentlich spaeter und nur unzuverlaessig. Mein Mobilfunkprovider weist nach der 24 Stundentrennung z.B. wieder die selbe Adresse zu. Da wuerde deine Erkennung dann vollstaendig fehlschlagen. Natuerlich muss er bei einem Neuaufbau u.U. mehrfach eine DNS-Aufloesung anstossen. Solange naemlich bis beim DynDNS die neue Adresse propagiert wird.
Rahul D. schrieb: > Irgendwelche Tunnels und VPNs lassen sich auf dem Controller nur schwer > umsetzen, da er mit seiner Hauptaufgabe, Messdaten zu sammeln, schon gut > ausgelastet ist. Kunden- (bzw. Chef-) Vorgaben waren, dass nicht noch > mehr Hardware dazukommen soll. Was kannst bzw. darfst du denn überhaupt beeinflussen? Du hast gesagt: 1. am lokalen Netzwerk darfst du nichts machen. 2. extra Hardware darfst du nicht dazubauen. 3. der Internetanschluss bleibt mit Zwangstrennung Darfst oder kannst du wenigstens den Code des Clients ändern? Wie sieht's mit einem Man in the Middle Server aus der im Internet dauerhaft steht? Also das ganze einfach rumdrehen und beide Rechner zu Clients machen und den Server im Internet dann zum Server?
foobaz schrieb: > Solange naemlich bis beim > DynDNS die neue Adresse propagiert wird. Und das wird schon mal mehrere Minuten dauern. Rahul D. schrieb: > Der Client befindet sich irgendwo, wo er per LTE mit dem Internet > kommuniziert, und sammelt Daten. > Die Daten werden auf den Server übertragen. > Das funktioniert soweit. Jetzt dann nochmal die Frage: Was genau bezweckt dann die Forderung nach einer "Standleitung"? Wenn der Server nichts ungefragt an den Client schickt, kann der Client jedesmal, wenns mal wieder Daten zu übertragen gibt, eine Verbindung öffnen (auf die dann aktuellen IP-Adresse des Servers), die Daten übertragen, und danach wieder zu machen. Dann knallt es nur noch, wenn die Verbindung während der Übertragung unterbrochen wird. Das kann immer vorkommen, nicht nur durch die Provider-Zwangstrennung, und das muß der Client erkennen können, und damit klar kommen. Oliver
:
Bearbeitet durch User
Rahul D. schrieb: >> Aber der Client sollte diesen Zustand von sich aus erkennen können und >> dann zuverlässig eine neue Verbindung zum Server aufbauen. > > Ich frage regelmäßig die IP-Adresse per DNS-Resolve ab. > Meine Frage war, ob man das noch besser machen kann. Ja. Du kannst entweder das TCP-Keepalive nehmen. Wie gut das funktioniert, hängt von Deinem IP-Stack ab. Was Du auf jeden Fall machen kannst, ist in Deiner Applikation regelmäßig eine Anfrage an den Server stellen und dann mit einem Timeout auf Antwort warten. Wenn keine Antwort bis Ablauf des Timeouts kommt, dann die Verbindung neu aufbauen. Sagen wir mal Du verwendest HTTPS als Protokoll. Dann könntest Du für den Verbindungstest eine statische Seite vom Server abrufen. Bei anderen Protokollen musst Du halt dafür was entsprechendes vorsehen. Wenn die Verbindung als unterbrochen erkannt wurde, dann erst eine DNS-Anfrage starten. Wenn Du die ganze Zeit und ohne erkannte Unterbrechung schon DNS-Anfragen machst, dann dauert es bis zum Ablauf der TTL bis Du die neue IP bekommst. Daher die DNS-Anfrage erst bei erkannter Verbindungsunterbrechung machen. Und wenn keine Verbindung zu stande kommt, dann natürlich DNS-Anfrage und Verbindungsaufbauversuch wiederholen.
Quatsch das ganze. Der Server stellt eine Verbindung zu einen Server im Internet her. Entweder er ist "eingewählt" ODER er wählt sich in den Moment ein. Also muss er der Beere sagen, sie soll alle X-Minuten irgend ein Ping senden oder was auch immer. Ich würde das damit es kein Ärger gibt an meine eigenen Domain machen. Die Verbindung wird hergestellt wenn nicht unterbrochen. Danach fragt die Beere nach ihre IP im Internet. Vergleicht beide IP's und wenn sie nicht identisch ist, teilt die Beere das den DYN-DNS-Anbieter mit. Oder wie hier sehr oft erwähnt eine Fritzbox. Notfalls irgendeine alte aus der Bucht. Den Job macht fast jede so nebenbei wenn eingetragen. Sind fleißig die Teilchen ;)
foobaz schrieb: > Mein Mobilfunkprovider weist nach der > 24 Stundentrennung z.B. wieder die selbe Adresse zu. Der Server bekommt eine neue Adresse. Darum geht es hier. Nano schrieb: > Darfst oder kannst du wenigstens den Code des Clients ändern? Der kommt von mir. > Wie sieht's mit einem Man in the Middle Server aus der im Internet > dauerhaft steht? > Also das ganze einfach rumdrehen und beide Rechner zu > Clients machen und den Server im Internet dann zum Server? Das ist nicht gewünscht. Oliver S. schrieb: > Wenn der Server nichts ungefragt an den Client > schickt, kann der Client jedesmal, wenns mal wieder Daten zu übertragen > gibt, eine Verbindung öffnen (auf die dann aktuellen IP-Adresse des > Servers), die Daten übertragen, und danach wieder zu machen. Das ist aber genau das, was nicht der Fall ist: Vom Server können auch Steuerbefehle übertragen werden (Der Server ist nicht unbedingt das, was man sich vorstellt, sondern ein PC an dem auch mal ein Mensch sitzen kann, der dann auch mal den Status des Messsystems (am anderen Ende) überprüfen oder ändern will. Gerd E. schrieb: > Was Du auf jeden Fall machen kannst, ist in Deiner Applikation > regelmäßig eine Anfrage an den Server stellen und dann mit einem Timeout > auf Antwort warten. Wenn keine Antwort bis Ablauf des Timeouts kommt, > dann die Verbindung neu aufbauen. Das hatten wir uns auch schon überlegt. Dabei fällt Traffic an, der dann auch bezahlt werden will... Nur so am Rande: Die Idee mit dem DNS-Resolve scheint zu funktionieren - die geänderte IP-Adresse wird erkannt. Nur die Reaktion meines Clients hakt noch (Mein ADHS stört einfach). Es handelt sich nur auf der Serverseite um einen PC. Auf der Messsystemseite steckt ein STM32F4 und ein ublox-LTE-Modem als Telemetriemdul. Das Protokoll haben wir uns selber ausgedacht, um möglichst wenig Overhead und Kompatiblität zu den Prtokollen, die wir auf anderen Schnittstellen verwenden, zu haben. Für mich ist dieses Thema vorerst erledigt. Danke für die Vorschläge.
Gibt es bei der Zwangstrennung auch jedesmal einen anderen IPv6-Prefix?
Schlaumaier schrieb: > Quatsch das ganze. > > Der Server stellt eine Verbindung zu einen Server im Internet her. > Entweder er ist "eingewählt" ODER er wählt sich in den Moment ein. > > Also muss er der Beere sagen, sie soll alle X-Minuten irgend ein Ping > senden oder was auch immer. Ich würde das damit es kein Ärger gibt an > meine eigenen Domain machen. Die Verbindung wird hergestellt wenn nicht > unterbrochen. Die Beere IST (momentan) der Server. > Danach fragt die Beere nach ihre IP im Internet. Vergleicht beide IP's > und wenn sie nicht identisch ist, teilt die Beere das den > DYN-DNS-Anbieter mit. Das erledigt die Fritzbox (oder ein anderer Router mit Portforwaring). > Oder wie hier sehr oft erwähnt eine Fritzbox. > Notfalls irgendeine alte aus der Bucht. Den Job macht fast jede so > nebenbei wenn eingetragen. > > Sind fleißig die Teilchen ;) Nur so am Rande: Das soll eine kommerzielle Lösung für einen Kunden werden. Wir verwenden nicht "irgendeine alte aus der Bucht". Der ganze Hardware-Aufbau ist seit diversen Monaten fertig. Einzig zur Netzproblematik hatte ich eine Frage.
Rahul D. schrieb: > Das soll eine kommerzielle Lösung für einen Kunden werden. Eine kommerzielle Lösung über DynDNS mit wechselnden IP-Adressen ist einfach sch...lecht und immer Bastelei. Ich würde das so umsetzen:
1 | Himbeere ---> Server |
2 | ^ |
3 | | |
4 | +--------- Client |
Der PI schickt aktiv die Daten an einen Server mit fester IP-Adresse (gibts als VM für ca. 4 EUR im Monat, z.B Hetzner), der Client holt sie von dort wieder ab. Vorteil: Der Server ist immer erreichbar. Die 4 EUR sollten für ein kommerzielles Projekt immer drin sein. Man kann übrigens den Server auch noch "nebenbei" mit anderen Aufgaben beschäftigen, so dass das Geld gut angelegt ist.
:
Bearbeitet durch Moderator
Frank M. schrieb: > (gibts als VM für ca. 4 EUR im Monat, z.B Hetzner), Und für schier unbezahlbare 1€/Monat bei IONOS ;-)
(prx) A. K. schrieb: > Und für schier unbezahlbare 1€/Monat bei IONOS ;-) Danke für den Tipp, schaue ich mir an :-)
> > Mein Mobilfunkprovider weist nach der > > 24 Stundentrennung z.B. wieder die selbe Adresse zu. > Der Server bekommt eine neue Adresse. Darum geht es hier. Das war nur ein Beispiel um zu zeigen, dass dein DNS-Geroedel Murks ist. Das koennte bei einem leitungsgebundenen Einwahlanschluss genauso passieren.
> Der Server bekommt eine neue Adresse. Darum geht es hier. Bei mir bekommt jede Kiste von der Fritzbox immer die selbe IP zugewiesen. Einfach das Teil anklicken und dann bearbeiten. "immer die selbe IP zuweisen". Basierend auf diese Aussage. Rahul D. schrieb: > Die Beere IST (momentan) der Server. bedeutet das die Beere bekommt immer die 192.168.30.10 z.b. von der Fritzbox trotz automatischer IP-Vergabe. ;)
Rahul D. schrieb: >> Was Du auf jeden Fall machen kannst, ist in Deiner Applikation >> regelmäßig eine Anfrage an den Server stellen und dann mit einem Timeout >> auf Antwort warten. Wenn keine Antwort bis Ablauf des Timeouts kommt, >> dann die Verbindung neu aufbauen. > > Das hatten wir uns auch schon überlegt. Wenn Du ein eigenes Protokoll verwendest und jederzeit vom Server aus Befehle senden können willst, halte ich das aus meiner Erfahrung heraus für die zuverlässigste Variante. > Dabei fällt Traffic an, der dann auch bezahlt werden will... Sagen wir mal Du überträgst da kleine Pakete mit vielleicht 60 Bytes hin und zurück. Das dann 1x pro Minute sind insg. nur etwas mehr als 5 MByte pro Monat. Das halte ich daher für kein Problem, selbst die günstigsten Mobilfunkverträge bieten heute Traffic im Gigabytebereich pro Monat.
die Fritzbox hat nur ein Problem wenn man einen HTTPS Server freigeben möchte, dann leitet das eingebaute DynDNS immer auf auf die FB Oberfläche um. In dem Fall nicht das FB DynDNS eintragen, sondern auf dem Serverrechner aktivieren. Hatte ich lange nach gesucht.
Schlaumaier schrieb: >> Der Server bekommt eine neue Adresse. Darum geht es hier. > > Bei mir bekommt jede Kiste von der Fritzbox immer die selbe IP > zugewiesen. Wenn die FritzBox durch Zwangstrennung eine neue IP-Adresse bekommt, ist auch der Server dahinter (d.h. die Himbere) danach nur über die abweichende IP-Adresse von außen erreichbar. Für den Client sieht es also so aus, als ob sich die Adresse des Servers geändert hat. Das ist einfach dem Portforwarding geschuldet. Das ist vollkommen unabhängig von der Tatsache, dass die lokale Adresse der Himbeere sich gar nicht ändert.
foobaz schrieb: > Das war nur ein Beispiel um zu zeigen, dass dein DNS-Geroedel > Murks ist. Das koennte bei einem leitungsgebundenen Einwahlanschluss > genauso passieren. Der Client baut die Verbindung zum Server auf. Wenn der für den Server nicht erreichbar ist, dann ist das so (z.B. mobile Plattform temporär ohne Netz). Der Bediener ist dann zwar angeschmiert, aber irgendwann ist das Ding entweder wieder erreichbar, oder jemand mus da hinfahren und es wieder einschalten. Gerd E. schrieb: > Das dann 1x pro Minute sind insg. nur etwas mehr als 5 MByte > pro Monat. Das halte ich daher für kein Problem, selbst die günstigsten > Mobilfunkverträge bieten heute Traffic im Gigabytebereich pro Monat. Und diese Mobilfunkverträge sind für solche (einen Daten-) Anwendungen vorgesehen? Warum haben wir dann nach entsprechenden IOT-Verträgen geguckt? Die Karte von Vodafone kostet einmalig ca. 12 Euro und hat standardmaäßig 75 MB Traffic inklusive. Irgendwelche Prepaid- und Vertragskarten haben mit dem Modem nicht funktioniert. Schlaumaier schrieb: > Bei mir bekommt jede Kiste von der Fritzbox immer die selbe IP > zugewiesen. Bei mir zuhause auch - hinter der FritzBox. Wenn ich einen Port freigebe, ändert sich die der Fritzbox im Netzt gelegentlich, wesewegen man solche Einrichtungen wie "dyndns.com" verwendet. Johannes S. schrieb: > die Fritzbox hat nur ein Problem wenn man einen HTTPS Server freigeben > möchte, dann leitet das eingebaute DynDNS immer auf auf die FB > Oberfläche um. In dem Fall nicht das FB DynDNS eintragen, sondern auf > dem Serverrechner aktivieren. Hatte ich lange nach gesucht. Danke, die nicht wirklich relevante Information. Das Thema ist inzwischen meinerseits abgehakt.
Rahul D. schrieb: > Gerd E. schrieb: >> Das dann 1x pro Minute sind insg. nur etwas mehr als 5 MByte >> pro Monat. Das halte ich daher für kein Problem, selbst die günstigsten >> Mobilfunkverträge bieten heute Traffic im Gigabytebereich pro Monat. > > Und diese Mobilfunkverträge sind für solche (einen Daten-) Anwendungen > vorgesehen? Das sind ganz normale Mobilfunkverträge mit Datenvolumen. Kannst Du als Prepaid und Postpaid bei allen 3 Mobilfunkanbietern so bekommen. > Warum haben wir dann nach entsprechenden IOT-Verträgen geguckt? > Die Karte von Vodafone kostet einmalig ca. 12 Euro und hat > standardmaäßig 75 MB Traffic inklusive. > Irgendwelche Prepaid- und Vertragskarten haben mit dem Modem nicht > funktioniert. Hast Du vielleicht kein normales Mobilfunkmodem, sondern eines für NB-IoT oder LTE-M? Da brauchst Du dann tatsächlich einen speziellen Vertrag dafür.
Gerd E. schrieb: >> Warum haben wir dann nach entsprechenden IOT-Verträgen geguckt? >> Die Karte von Vodafone kostet einmalig ca. 12 Euro und hat >> standardmaäßig 750 MB Traffic inklusive. >> Irgendwelche Prepaid- und Vertragskarten haben mit dem Modem nicht >> funktioniert. > > Hast Du vielleicht kein normales Mobilfunkmodem, sondern eines für > NB-IoT oder LTE-M? Da brauchst Du dann tatsächlich einen speziellen > Vertrag dafür. Was ist denn ein "normales Mobilfunkmodem"? Hast du da irgendwelche Beispieltypen? Ich habe hier ein ublox SARA-R410M-02B (https://www.sparkfun.com/products/14997). Dafür braucht man offensichtlich einen IOT-/LTE-NB-Vertrag.
Rahul D. schrieb: > Was ist denn ein "normales Mobilfunkmodem"? Na eines, was mit normalem LTE / 4G Mobilfunk umgehen kann und nicht nur NB-IoT oder LTE-M kann. > Hast du da irgendwelche Beispieltypen? > Ich habe hier ein ublox SARA-R410M-02B Das passende u-blox Modell wäre z.B. TOBY-R2: https://www.u-blox.com/en/product/toby-r2-series Gibt es einen speziellen Grund warum Du die IoT-Variante gewählt hast? Z.B. langer Batteriebetrieb wäre ein valider Grund. Diesem Vorteil musst Du halt die massiv höheren Preise für Datenvolumen gegenrechnen.
Es gibt auch ublox Modems die LTE (ohne -M) sprechen. Die laufen mit Standard-Prepaid und haben ne viel höhere Datenrate. LTE-M hatte ich mir für meine Wildkammeras auch zunächst angeschaut. War mir bei dem lächerlichen Datenvolumen und dem damaligen Preis viel zu teuer. Vorteil von LTE-M ist der geringere Stromverbrauch, höhere Reichweite und theoretisch günstigere Hardwarepreis. Wobei letzteres damals (noch?) nicht zutreffend war.
Gerd E. schrieb: > Gibt es einen speziellen Grund warum Du die IoT-Variante gewählt hast? Ich habe es nicht gewählt. Das wurde von jemand anders wohl auch aufgrund des verfügbaren Sparkfun-Moduls beschafft (müsste ich jetzt nachfragen...). Gerd E. schrieb: > Das passende u-blox Modell wäre z.B. TOBY-R2: > https://www.u-blox.com/en/product/toby-r2-series Danke für den Tip. Andreas M. schrieb: > Vorteil von LTE-M ist der geringere Stromverbrauch, höhere Reichweite. Das waren auch Gründe. Vielleicht bauen wir den ganzen Kram noch auf ein "consumer"-Gerät um.
Bei mir ist es ein ublox LARA-R2. Muss man halt die passende Region aussuchen, das Toby geht weltweit.
Andreas M. schrieb: > Bei mir ist es ein ublox LARA-R2. Muss man halt die passende Region > aussuchen, das Toby geht weltweit. Das TOBY sieht auf den ersten Blick sehr interessant aus. Leider gab es noch einen weiteren Grund für die Auswahl: Verfügbarkeit. Das Sparkfun-SARA-Modul ist/war verfügbar. Die anderen haben Liefertermine in 2022... (erste Kurzrecherche bzgl. Preis). Der Preis von ca. 70 Euro für das SARA war auch akzeptabel (und wir mussten nicht erst eine Platine designen).
Wie viel mA/mW genehmigt sich denn die SARA im empfangsbereiten Zustand? Die 6mA aus dem Datenblatt sind ja nicht besser als bei einem 0815 GSM Modul..
Ich benutze auch ein Fertigmodul mit dem LARA-2: https://www.seeedstudio.com/LTE-Cat-1-Pi-HAT-Europ-p-3060.html Damals über mouser bestellt. Im Moment allerdings auch nicht auf Lager. Ich benutze das mit dem RaspB-Pi aber eigentlich wird nur die UART verwendet.
Falls es jemanden interessiert: Der Test übers Wochenende war erfolgreich. Inklusive IP-Adressüberprüfung per DNS-Abfrage.
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.