Jump to content
MaM

IPV6 für den Mediaserver

Recommended Posts

MaM

Zumindest ein bißchen 😁

 

Wie wäre es, wenn das Setup gleich noch einen Eintrag a la "netsh interface portproxy add v6tov4 listenport=8089" hinzufügt?

Damit ist dann das Webinterface auch per V6 erreichbar und man spart sich das hässliche Timeout jedesmal, wenn man die Seite neu aufruft in einem LAN, das auch mit V6 arbeitet (sollten ja inzwischen recht viele sein, Tendenz steigend).

Es sind keine Änderungen am DVBViewer oder Media Server erforderlich, nur im Setup sollte die Option mit aufgenommen werden.

 

Erklärung: die Zeile weist den in Windows fest eingebauten Portproxy um, ankommende Verbindungen auf IPV6 Port 8089 umzuleiten an "localhost" Port 8089 (auf welchem sich normalerweise ja das Webinterface tummelt)

 

(besser wäre es natürlich, wenn die Programm WIRKLICH V6 fähig würden, aber das wage ich gar nicht zu erwähnen, erstmal warte ich auf zusätzliche 32Bit 🙂 )

 

(Update: fehlendes Gleichheitszeichen eingefügt)

Edited by MaM

Share this post


Link to post
Griga
8 hours ago, MaM said:

Wie wäre es, wenn das Setup gleich noch einen Eintrag a la "netsh interface portproxy add v6tov4 listenport 8089" hinzufügt?

 

Fehlt da nicht ein Gleichheitszeichen nach listenport?

 

Was ist, wenn der Anwender einen anderen Webserver-Port konfiguriert (hat)?

 

Share this post


Link to post
Griga

P.S. In dem im ersten Post angegebenen String "netsh interface..." versteckt sich ein unsichtbares Zeichen hinter listenport. In Notepad++ wird es zum UTF-8 BOM. Also besser so nicht in die Eingabeaufforderung kopieren. ;)

 

Share this post


Link to post
MaM
vor 52 Minuten schrieb Griga:

 

Fehlt da nicht ein Gleichheitszeichen nach listenport?

 

Was ist, wenn der Anwender einen anderen Webserver-Port konfiguriert (hat)?

 

a) hmm, er scheint mit und ohne zu fressen. Aber egal, dann machen wir eben eins hin... war ja eh nur als Beispielzeile gedacht und sollte programmtechnisch ja anders umgesetzt werden...

b) dann soll das Setup den Proxyeintrag natürlich auf den anderen Port konfigurieren. Ist ja wohl nicht so schwer, Variablen zu benutzen, oder? (man könnte natürlich auch noch ne Abfrage einbauen, wie bei den Firewallregeln)

 

Update a) Stimmt, fehlt ein Gleichheitszeichen! Er frißt es auch ohne, aber dann kommt eine ganz andere Einstellung raus 😞

Also besser schreiben "netsh interface portproxy add v6tov4 listenport=8089" (und auch hier ist wieder kein BOM oder son Mist drin, einfach von Hand so eingetippt!)

 

Edited by MaM

Share this post


Link to post
MaM
vor 4 Minuten schrieb Griga:

P.S. In dem im ersten Post angegebenen String "netsh interface..." versteckt sich ein unsichtbares Zeichen hinter listenport. In Notepad++ wird es zum UTF-8 BOM. Also besser so nicht in die Eingabeaufforderung kopieren. ;)

 

 

PPS: Das ist Quatsch. Cut&Paste funktioniert einwandfrei mit der Zeile. Das BOMt wohl nur bei Dir (schalt doch die Kodierung um auf UTF-8 (ohne BOM)

Die Zeile wurde einfach von Hand hier mit dem Editor des Forums eingetippt. Nix mystisches, nur Plain Text...

Edited by MaM

Share this post


Link to post
Griga
1 hour ago, MaM said:

a) hmm, er scheint mit und ohne zu fressen. Aber egal, dann machen wir eben eins hin...

 

Quellen im Web geben alle ein Gleichheitszeichen an. netsh frisst die Zeile zwar ohne, aber ein nachfolgendes "netsh interface portproxy delete v6tov4 listenport 8089" scheitert mit einer Fehlermeldung. Das ist mit Gleichheitszeichen nicht der Fall.

 

1 hour ago, MaM said:

b) dann soll das Setup den Proxyeintrag natürlich auf den anderen Port konfigurieren.

 

Typischerweise wird der DMS erst installiert, und danach konfiguriert der Anwender den Webserver Port. Andersherum ist schwierig :D Du hast wahrscheinlich nur an Update-Installationen gedacht.

 

Ich denke, es ist keine gute Idee, im Setup auf diese Weise an der Systemkonfiguration zu schrauben. Wenn schon, dann optional. Und nicht im Setup.

 

Insgesamt ein interessanter Hinweis, aber nicht gut präsentiert und zu Ende gedacht.

 

Frage: Ich habe hier ein IPv4-Netzwerk (nehme ich jedenfalls an). Wenn ich die Kommandozeile mit Adminrechten starte und "netsh interface portproxy add v6tov4 listenport=8089" eingebe, erwarte ich nun, dass der DMS via http://[::1]:8089 erreichbar ist. Chrome liefert mir nach Eingabe der Adresse aber nur einen ERR_CONNECTION_REFUSED. Im DMS Code kommt nichts davon an, wie der Debugger zeigt. Warum?

 

57 minutes ago, MaM said:

Das ist Quatsch. Cut&Paste funktioniert einwandfrei mit der Zeile.

 

Kodierung ist UTF-8. Das Zeichen steckte hinter v6tv4, nicht wie erst angegeben hinter listenport. Ich hatte die Zeile nach Notepad++ kopiert. Mir war aufgefallen, dass dort ein Punkt erschien, der sich nicht löschen bzw. durch ein Blank ersetzen ließ. Daraufhin habe ich es mir mit einem Hexviewer angeschaut und das BOM mitten im Text entdeckt. Bei einem weiteren Versuch befand sich das Zeichen hinter 8089. Nachdem du deinen Post editiert hat, kann ich es nicht mehr reproduzieren. Sehr merkwürdig...

 

Share this post


Link to post
MaM
vor 59 Minuten schrieb Griga:

Frage: Ich habe hier ein IPv4-Netzwerk (nehme ich jedenfalls an). Wenn ich die Kommandozeile mit Adminrechten starte und "netsh interface portproxy add v6tov4 listenport=8089" eingebe, erwarte ich nun, dass der DMS via http://[::1]:8089 erreichbar ist. Chrome liefert mir nach Eingabe der Adresse aber nur einen ERR_CONNECTION_REFUSED. Im DMS Code kommt nichts davon an, wie der Debugger zeigt. Warum?

der Teufel steckt im Detail, wie so oft 🙂

Die angegebene Zeile für den Portproxy leitet ja ALLE V6 Adressen um, ALLE, ausser "localhost" . Normalerweise will man den ja gar nicht umleiten, da dort ja sich die lokalen Serverprogramme tummeln. Man kann Windows aber nach der Methode "ich will das aber so! BASTA!" dazu zwingen...

 

Für Deinen Test müsstest Du dann zusätzlich eingeben:

 

"netsh interface portproxy add v6tov4 listenport=8089 listenaddress=::1 connectaddress=192.168.0.15"

 

(wobei connectaddress die Adresse des DMS ist, möglichst nicht 127.0.0.1)

 

(Ps: zum Aufräumen aller Fehlversuche empfehle ich "netsh interface portproxy reset", das löscht alle vorhandenen Einträge)

 

Share this post


Link to post
Griga
17 minutes ago, MaM said:

Für Deinen Test müsstest Du dann zusätzlich eingeben:

 

So klappt der Zugriff auf das Webinterface mit http://[::1]:8089. Aber nur mit Benutzername und Passwort.

 

Das liegt wohl daran, dass ich hier für Testzwecke per userdata.xml-Eintrag dem DMS vortäusche, dass  von seiner lokalen Adresse 192.168.xxx.xxx ausgehende Zugriffe aus einem anderen Netzwerk kommen. Eine Art simulierter Zugriff aus dem Internet. Und da will er dann halt ein Passwort sehen.

 

Andere Testmöglichkeiten für den v6tov4 portproxy gibt es in einem IPv4-Netzwerk nicht, oder?

 

Share this post


Link to post
MaM

Na ja, es hindert Dich ja niemand daran, ein "richtiges" IPV6 LAN aufzusetzen. Es gibt genügend kostenlose Angebote für Tunnel (MAMs empfehlen www.tunnelbroker.net, läuft hier absolut stabil seit Jahren und vergibt FESTE Adressen!). Die kannst Du direkt auf Deiner Fritzbox, irgendeinem Unix/Linux/BSD Server, oder zur Not auch auf irgendeiner Windows Kiste aufsetzen.

Wobei die letztere Variante ist nun wirklich die, die man tunlichst vermeiden sollte, ohne ein paar laufende Serverprozesse macht V6 wenig Freude...

 

(Hinweis zu Tunnelbroker: Anfänger kriegen da sofort einen Tunnel. Der kann auch alles, nur Port 25 (Mail) ist geblockt. Man muss ein paar Online Prüfungen ablegen und ein paar Wochen stabilen Betrieb machen, dann reicht eine Mehl an den Admin und auch die Post fluppt durch. Und wenn man genügend Prüfungen gemacht hat, gibts sogar ein T-Shirt umsonst 🙂

Die Seite liefert auch komplette Konfigurationsanweisungen für alle Betriebssysteme. Cut&Paste reicht, nur das Passwort muss man noch selber ergänzen.)

 

 

Share this post


Link to post
Griga
16 hours ago, MaM said:

Damit ist dann das Webinterface auch per V6 erreichbar und man spart sich das hässliche Timeout jedesmal, wenn man die Seite neu aufruft in einem LAN, das auch mit V6 arbeitet

 

Mir fehlt jegliche Vorstellung davon, wozu bzw. in welchem Fall die Erreichbarkeit per IPv6 zwingend gebraucht wird. Kann man "in einem LAN, das auch mit V6 arbeitet", den DMS-Webserver nicht mehr über eine IPv4-Adresse erreichen? Und was ist dann mit den anderen Serverinstanzen im DMS? RTSP? UPnP? Media & Live Stream?

 

2 hours ago, MaM said:

Na ja, es hindert Dich ja niemand daran, ein "richtiges" IPV6 LAN aufzusetzen.

 

Doch. Zeitmangel. Es gibt rund um den DMS & DVBViewer x Sachen zu erledigen, die wichtiger sind. Bislang sind IPv6 LANs hier nicht als Problem aufgetaucht. Es ist ja nicht so, dass ich hier untätig sitze und warte, bis mir irgendjemand erzählt, was man noch machen könnte.

 

Share this post


Link to post
MaM
vor 3 Stunden schrieb Griga:

Mir fehlt jegliche Vorstellung davon, wozu bzw. in welchem Fall die Erreichbarkeit per IPv6 zwingend gebraucht wird. Kann man "in einem LAN, das auch mit V6 arbeitet", den DMS-Webserver nicht mehr über eine IPv4-Adresse erreichen? Und was ist dann mit den anderen Serverinstanzen im DMS? RTSP? UPnP? Media & Live Stream?

na ja "zwingend" würde ich nicht sagen, es wäre nur "hübscher".

 

Der Effekt bei den Leuten mit V6 Netzen (z.B. wenn man mit DSLite von Unitymedia gestraft, äääh "beglückt",  ist) sind einfach gähnen langweilige Pausen beim Zugriff.

Es gilt nämlich die Regel "V6 hat Priorität" (steht so in der Norm, ist völlig korrekt so und nicht diskutabel). Das heißt, bei einem Verbindungsaufbau für den mehrere Adressen verfügbar sind, wird immer zuerst V6 probiert. Erst, wenn dort, nach Timeout, keine Verbindung zustande kommt, wird die nächste Adresse durchprobiert, bis irgendwann mal die V4 Adressen dran sind. Mit etwas Geduld kommst Du dann irgendwann mal zu Deiner gewünschten Webseite. ABER ES NERVT AUF DIE DAUER!

 

Wenn ich mir so meinen Media Server angucke, dann liefert mir Windows:

C:\Users\mam>nslookup vcr
Server:  Chef.Werries.Local
Address:  192.168.0.76

Name:    vcr.Werries.Local
Addresses:  2001:470:1f0b:244::15
          fdfd::15
          192.168.0.15

Also probiert der Browser erstmal 2001:470.... (die globale V6 Adresse) (30s Timeout), dann fdfd::15 (die lokale V6 Adresse) (30s Timeout) um dann nach nur knapp einer Minute endlich 192.168.0.15 zu probieren und erfolgreich zu sein.

Mit dem Portproxy Eintrag gibts keine Fehlversuche, also auch keine Wartezeit (die übrigens nach ein paar Minuten Inaktivität wieder von vorne beginnt!).

Und da der Eintrag nun wirklich kein Brot kostet, geschweige den Arbeit, noch dass er unangenehme Nebenwirkungen hat, fällt mir wenig ein, auf ihn verzichten zu wollen.

vor 3 Stunden schrieb Griga:

Doch. Zeitmangel.

Na ja, 5 Minuten solltest Du schon entbehren können.

 

vor 3 Stunden schrieb Griga:

Bislang sind IPv6 LANs hier nicht als Problem aufgetaucht

Da sie bei einigen ISPs inzwischen nicht mehr zu verhindern sind, werden sie Dich irgendwann überrollen.

 

vor 3 Stunden schrieb Griga:

Und was ist dann mit den anderen Serverinstanzen im DMS? RTSP? UPnP? Media & Live Stream?

Für den Verbindungsaufbau ist immer der Client zuständig. Solange Dein DVBViewer gar kein V6 kennt, wird er auch keinen Verbindungsversuch darauf starten (ganz andere Socket Typen, da muß man schon einiges an Programmcode ändern). Betroffen sind nur "universelle" Clients wie Browser & Co. Sollten allerdings irgendwann einmal Klienten für beide Protokolle existieren (VLC z.B. is so einer, da ist die "Denkpause" auch fühlbar), dann wird sich der negative Einfluß weiter verbreiten und mehr Leute ärgern.

 

 

 

Share this post


Link to post
HaraldL

Damit es bei dir persönlich schneller geht möchest du ggf. andere LANs vom Setup verhunzen lassen? Ich hab hier einen DSL-Anschluß der Telekom mit IPv4 und echtem IPv6 ohne Murks wie Teredo, 6to4, Isatap etc (was ich auch per Netsh alles drei deaktiviere) oder DSLite.

 

Wenn ich jetzt mit NSLOOKUP den PC meiner Frau suche bekomme ich auch erst eine IPv6-Adresse 2003:d6:... und trotzdem ist im Browser der Aufruf instant erfolgreich, keine 30s Wartezeit. Getestet in Firefox, Chrome, Internet Explorer, Opera.

 

Also wenn überhaupt, dann wäre das was Optionales für den Tweaker, aber bitte nicht als Default allen aufzwingen.

Share this post


Link to post
MaM

Und, es geht hierbei sicherlich nicht um mich. Ich mache den Eintrag schon seit Jahren, mir fiel nur auf, dass auch viele andere betroffen sein könnten (die meisten davon werden die Ursache nie finden können und es als gottgegeben hinnehmen da sie ja doch seeehr versteckt ist) und kam auf die offensichtlich dumme Idee, die Info mit anderen zu teilen. Bei solch Ignoranten wie Dir vergeht mir die Lust dazu aber recht schnell wieder.

Edited by MaM

Share this post


Link to post
Griga

Es ist hilfreich, die Möglichkeit der portproxy-Konfiguration zu kennen, aber ich bin aus verschiedenen Gründen nicht davon überzeugt, dass sie im Setup / DMS UI als Option auftauchen sollte:

  1. Wenn wir hier mehrere Reports pro Monat hätten, die lahme Zugriffszeiten in IPv6 LANs beklagen, gäbe es Handlungsbedarf. Bislang sind mir aber keine weiteren Beschwerden über lange Webserver-Zugriffszeiten in IPv6-Netzen bekannt.
  2. In der angegebenen Form bezieht sich die Maßnahme nur auf HTTP-Zugriffe auf den Webserver, lässt aber die Frage offen, wie andere Serverinstanzen im DMS in der Hinsicht zu behandeln sind - insbesondere auch, wenn UDP und Multicast ins Spiel kommen (bei UPnP und Sat>IP).
  3. Es handelt sich um eine Systemeinstellung, die man i.a. nur einmalig vornimmt, was auch außerhalb des DMS geschehen kann kann, wenn man die Kommandozeile kennt bzw. durch den Support erfährt. Eine Integration ins UI würde der Bequemlichkeit dienen, brächte aber auch die Gefahr mit sich, dass Anwender die Option auf Verdacht verwenden, ohne zu wissen, was sie damit bewirken.
  4. Risiken und Nebenwirkungen: Wenn alle IPv6-Zugriffe auf den Webserver-Port auf localhost gemapt werden, haben wir praktisch eine Art Reverse-Proxy-Betrieb, ohne dass der DMS dafür konfiguriert ist und ohne dass er die tatsächliche Client IP (z.B: durch x-forwarded-for) erfährt. Dies hebelt Schutzmechanismen aus, die für Zugriffe aus anderen Netzwerken zwingend ein Passwort vorsehen. Weiterhin sind Probleme beim transkodierten Streaming zu erwarten, bei dem Clients (auch) anhand ihrer IP unterschieden bzw. wiedererkannt werden.

Ich denke, es lohnt sich mehr, Zeit in die Untersuchung der Realisierbarkeit echter IPv6-Unterstützung mit den verwendeten Netzwerk-Bibliotheken zu investieren,  als in die portproxy-Krücke.

 

Share this post


Link to post
MaM

Na ja, war mir schon klar, was der Bauer nicht kennt, frißt er nicht. Also: VERGISSES!

 

Nur ein paar Deiner Denkfehler muß ich noch kurz korrigieren:

vor 21 Minuten schrieb Griga:

Risiken und Nebenwirkungen: Wenn alle IPv6-Zugriffe auf den Webserver-Port auf localhost gemapt werden, haben wir praktisch eine Art Reverse-Proxy-Betrieb, ohne dass der DMS dafür konfiguriert ist und ohne dass er die tatsächliche Client IP (z.B: durch x-forwarded-for) erfährt. Dies hebelt Schutzmechanismen aus, die für Zugriffe aus anderen Netzwerken zwingend ein Passwort vorsehen. Weiterhin sind Probleme beim transkodierten Streaming zu erwarten, bei dem Clients (auch) anhand ihrer IP unterschieden bzw. wiedererkannt werden.

Niemand hat vorgeschlagen, den Webserver umzuleiten. Der tummelt sich gemeinhin auf Port 80 und/oder 443. Wir reden hier vom Webzugang des Media Servers auf Port 8089. Nichts anderes wird tangiert und die Risiken und Nebenwirkungen sind nicht existent.

Streaming & Co sind in keinster Weise betroffen, sie laufen über eigene V4 Verbindungen.

 

vor 24 Minuten schrieb Griga:

In der angegebenen Form bezieht sich die Maßnahme nur auf HTTP-Zugriffe auf den Webserver, lässt aber die Frage offen, wie andere Serverinstanzen im DMS in der Hinsicht zu behandeln sind - insbesondere auch, wenn UDP und Multicast ins Spiel kommen (bei UPnP und Sat>IP). 

GAR NICHT! und auch NIEMALS!

Der Kram existiert nicht in der reinen V6 Welt und seit dem letzten abgelehnten Vorstoß des UPnP Konsortiums 2009 ist er auch wohl endgültig vom Tisch. V6 bietet eigene Multicast Adressbereiche mit definierten Scopes (Global, Sitelocal, Linklocal). Vor allen Dingen gibt es kein NAT mehr und Firewalls funktionieren nun ganz anders. Es gibt also viele neue Anforderungen, die die Anwenundungen zu erfüllen haben.

Solange es Dual Stack Implementierungen gibt, wird UPnP noch toleriert (nur auf V4), das wars aber dann auch.

Wollt Ihr die Programme irgendwann wirklich mal auf V6 umstellen, müsst ihr euch komplett was Neues ausdenken. Allerdings sollten durch die neuen V6 Möglichkeiten viele Dinge viel einfacher und sauberer werden. Nur trenne Dich gleich von der Idee des "Updates", das wird eine vorprogrammierte Sackgasse. Fangt von vorne an.

 

 

Share this post


Link to post
Griga
On 5/21/2018 at 10:38 PM, MaM said:

Erklärung: die Zeile weist den in Windows fest eingebauten Portproxy um, ankommende Verbindungen auf IPV6 Port 8089 umzuleiten an "localhost" Port 8089 (auf welchem sich normalerweise ja das Webinterface tummelt)

 

Wie passt das zu deinen letzten Ausführungen? Wenn der DMS Webserver bei IPv6-Zugriffen nur noch 127.0.0.1 als Client IP sieht, gibt es die genannten Probleme. Bei dem von dir vorgeschlagenen

 

"netsh interface portproxy add v6tov4 listenport=8089 listenaddress=::1 connectaddress=192.168.xxx.xxx"

 

war es jedenfalls so, dass der DMS 192.168.xxx.xxx als Client IP angesehen hat, sonst hätte er bei der hier konfigurierten Internet-Simulation nicht mit einer Passwortabfrage reagiert.

 

Das selbe Problem stellt sich bei Betrieb mit einem Reverse Proxy, weil der DMS dann nur noch dessen IP als Client IP sieht (also üblicherweise 127.0.0.1 bei einem lokalen Reverse Proxy). Aber in dem Fall lässt sich das durch eine Konfiguration des DMS für diese Betriebsart und mit x-forwarded-for & Co. regeln.

 

Share this post


Link to post
MaM
vor 4 Minuten schrieb Griga:

Wie passt das zu deinen letzten Ausführungen? Wenn der DMS Webserver bei IPv6-Zugriffen nur noch 127.0.0.1 als Client IP sieht, gibt es die genannten Probleme. Bei dem von dir vorgeschlagenen

da steht doch weiterhin "listenport=8089", also werden alle anderen Ports nicht betroffen.

Aus Faulheitsgründen hab ich "connectport=8089" weggelassen. Aber das ist Default.

 

Ich geb zu, als einzigen "Nachteil" sieht es für das Webinterface so aus, als wenn die Anfrage von 127.0.0.1 käme (oder von einer anderen Adresse, wenn man den Portproxy auf einem anderen Server im LAN einrichten würde). Die Passwortabfrage sehe ich als geringeres Problem an, die ist hier eh immer aktiviert, ich will nicht, dass meine Usah an den Timern rumfuckeln 🙂. Insofern war mir die Abfrage gar nicht aufgefallen, ich bin sie gewohnt.

 

Du solltest Dich vielleicht mal langsam von dem Grundgedanken trennen, dass eine IP Adresse irgendein Sicherheitsfeature darstellt und verlässlich ist. Dank NAT, VPNs, Portproxies & Co kann man heute so ziemlich alles faken. 

Auch wenn es wohl ein Klacks wäre, den internen Webserver zusätzlich an die V6 Ports zu binden, Ihr müsstet die komplette Adressverwaltung in der GUI / Webpages ändern. Den Aufwand würde ich nicht treiben wollen. Da bleib ich lieber beim Proxy.

Share this post


Link to post
Griga
57 minutes ago, MaM said:

Ich geb zu, als einzigen "Nachteil" sieht es für das Webinterface so aus, als wenn die Anfrage von 127.0.0.1 käme

 

Das gibt dann Probleme beim transkodierten Streaming, wenn Clients von verschiedenen IPV6-Adressen mit dem gleichen Parametersatz zugreifen, weil sie der DMS nicht mehr unterscheiden kann.

 

Hintergrund ist u.a., dass typischerweise zunächst der Browser eine Verbindung aufbaut, sich die Header anschaut und dann die URL an eine Player-Engine wie Stagefright (unter Android) delegiert, die eine weitere Verbindung aufbaut. Das ist kein Problem, wenn der Content bereits fertig transkodiert auf der Platte vorliegt. Aber bei On-The-Fly-Transkodierung startet es unnötigerweise zwei ressourcenhungrige FFmpeg-Instanzen, wenn der DMS sowas nicht erkennt und abfängt, indem er den selben Stream beiden Verbindungen zuordnet. In deinem Fall erkennt er es eventuell fälschlich, und die Clients schnappen sich den Stream-Output gegenseitig vor der Nase weg, es sei denn, du ergänzt clientseitig eine individuelle Stream ID als zusätzlichen Parameter.

 

Das ist nur ein Beispiel. Bei On-The-Fly-Transkodierung (insbesondere nach HLS) gibt es verschiedene Anforderungen, die über ein schlichtes File-Delivery--Modell hinausgehen. Zum Teil ist dafür die Unterscheidung von Clients anhand ihrer IP-Adresse notwendig.

 

Share this post


Link to post
MaM
vor 1 Stunde schrieb Griga:

Das gibt dann Probleme beim transkodierten Streaming, wenn Clients von verschiedenen IPV6-Adressen mit dem gleichen Parametersatz zugreifen, weil sie der DMS nicht mehr unterscheiden kann.

Nein, natürlich gibt es keine Probleme.

Eine TCP Verbindung ist durch VIER Parameter charakterisiert: Quelladresse,Quellport,Zieladresse,Zielport. Beim Weiterleiten durch den Proxy wird jedesmal eine neue Verbindung aufgebaut, dabei wird immer ein neues Quellport gewählt (da das alte ja noch belegt ist). So funktioniert TCP/IP seit den 70er Jahren. Mach ein paar Verbindungen auf, guck mit "netstat", Du wirst sehen, immer verschiedene Quellports...

(Anmerkung: wenn eure Anwendung immer nur die Adresse vergleichen sollte, so ist das ein PROGRAMMIERFEHLER!!!)

 

Edited by MaM

Share this post


Link to post
Griga

Ich glaube, so ganz hast du das Handling  transkodierter Streams noch nicht verstanden. Ich wollte dich nur wissen lassen, womit du bei deiner Methode rechnen musst.

 

Noch mal anders dargestellt: Beim transkodierten Streaming steht der DMS vor dem Problem dass er verschiedene Clients vom selben Gerät (also konkret wie oben geschildert Browser und beauftragte Player-Engine) als zusammengehörig erkennen und beide mit dem selben Stream bedienen muss, um einen übermäßigen Ressourcenverbrauch durch doppelte Transkodierung zu vermeiden. Die Zusammengehörigkeit erkennt er an der gleichen Client IP und dem identischen Satz Streaming-Parameter (im Query-Teil der URL).

 

Ein Vergleich der Client-Ports hilft nicht, weil Browser und Player, die den DMS mit zwei verschiedenen TCP-Verbindungen gleichzeitig belangen und die der DMS als zusammengehörig erkennen muss, natürlich clientseitig verschiedene Ports verwenden, wie du schon richtig angemerkt hast. Auch ein Vergleich der User Agents  führt nicht zum Ziel. Chrome und Stagefright verwenden z.B. unter Android verschiedene User Agent Strings. Das einzige, was Browser und Player in dem Fall gemeinsam haben, ist die Client IP und dass sie die gleiche URL verwenden.

 

Ein  typisches Szenario, in dem es in deinem Setup schiefgehen kann, wären zwei Clients auf verschiedenen Mobilgeräten, die zeitgleich beide den DMS via IPv6 belangen und beide das Erste HD mit identischen WebM-Presets transkodiert haben wollen. Der DMS erkennt wegen der vermeintlich gleichen Client-IPs nicht mehr, dass es verschiedene Geräte sind, die er mit zwei separat transkodierten Streams bedienen muss. Wenn es passiert, wirst du dich erinnern...

 

Das ist übrigens auch noch format- und quellenabhängig (für alle, die es interessiert): Bei TS als Zielformat können Clients an jeder beliebigen Stelle in einen Live-Stream einsteigen. Wenn eine Transkodierung nach TS läuft und später kommt ein Client hinzu, der exakt den gleichen Stream haben will, kriegt er einfach eine Kopie - kein Problem. Bei WebM muss der Player jedoch die Header am Anfang des Streams mitkriegen. Später einklinken geht nicht. Und bei einer Datei als Quelle geht es auch nicht mit TS, da es ja sein könnte, dass ein Client einen Sprung ausführt, bei dem der DMS die Transkodierung ab der gewünschten Stelle neu startet. Das müsste der andere Client, der den selben Stream erhält, dann mitmachen, ob er will oder nicht...

 

Schluss der Vorlesung, ich habe noch anderes zu tun :bye:

 

Share this post


Link to post
MaM

Na gut, ich sagte ja, LASSEN WIR DAS!

Dir fehlt offensichtlich das Basiswissen um die Auswirkungen verstehen und abschätzen zu können.

 

Share this post


Link to post
HaraldL

Du bist ja dann nicht derjenige der böse Anrufe und Mails bekommt wenn auch nur bei einem kleinen Teil der ggf. Tausenden (? keine Ahnung wie viele User vom DVBViewer/DMS es gibt) Anwendern danach Probleme mit dem Netzwerk auftreten. Das ist ja leider Christian. Nach 30 Jahren als selbständiger EDV-Dienstleister und Netzwerkadministrator (und ja dank erfolgreichem Studium der Technischen Informatik hab ich auch genug Basiswissen und brauchte deine obigen Infos dazu nicht) habe ich schon genügend haarsträubende und wacklige Netzwerkinstallationen bei Kunden gesehen wo so etwas oft ausreicht das Kartenhaus zum Einsturz zu bringen. Und schuld ist dann für den Anwender nicht der katastrophale Zustand vorher sondern genau das eine Programm nach dessen Installation dann irgendwas nicht mehr geht. Das ist halt die Realität.

 

Da kannst du mich als Ignoranten bezeichnen, aber schau doch mal in den Spiegel bitte.

Share this post


Link to post
Griga

Wie ein Versuch gezeigt hat, braucht es im wesentlichen ein Update der zugrundeliegenden Netzwerkbibliothek, um den DMS Webserver IPv6-fähig zu machen. Bislang wird eine ältere Version ohne IPv6-Unterstützung verwendet.

 

Bei Einsatz der neuen Version gibt es ein paar Inkompatibilitäten im DMS-Code, die sich jedoch behandeln lassen. Wenn ich dann der Liste der Interface bzw. Adapter-Adressen, über die der Webserver auf eingehende Verbindungen lauscht, ::1 hinzufüge (also localhost auf IPv6isch :)), kann ich ihn im Browser über die Adresse erreichen. In einem IPv6-Netzwerk müssten noch die IPv6-Adressen der weiteren Adapter hinzukommen, was im Prinzip kein großes Problem darstellt - die liefert Windows, wenn man höflich fragt.

 

Hinsichtlich der Behandlung von Client IP-Adressen ist der Webserver bereits IPv6-fähig - das musste für Reverse Proxy-Unterstützung implementiert werden, weil dieser ja eventuell im X-Forwarded-For Header IPv6 Client-Adressen angibt.

 

Allerdings entsteht aus der Umstellung auf die aktuelle Version der Netzwerkbibliothek ein hoher Testbedarf. Das Problem sind nicht die vom Compiler bemängelten offensichtlichen Code-Inkompatibilitäten, sondern versteckte Inkompatibilitäten/Fehler, die vielleicht nur in bestimmten Situationen zuschlagen. Außerdem fehlt mir die Testmöglichkeit in einem IPv6-Netzwerk. Eventuell ist eine öffentliche Beta für Leute fällig, die sich trauen... jedenfalls werden eine Zeitlang zwei DMS-Versionen parallel gepflegt werden müssen, bis die Sache auf soliden Füssen steht: Die Nur-IPv4-Variante mit der älteren Version der Netzwerkbibliothek und die neue IPv6-fähige.

 

Share this post


Link to post
MaM

Testen kann ich hier grundsätzlich. Allerdings sind hier viele Features wie Streaming usw. gar nicht im Einsatz. Ich benutze das Dingen nur als Videorekorder, gesteuert über das Webinterface. Theroretisch können die Leute hier Live TV darüber gucken, aber die Auslastungsstatistik weist 0% auf. Und mit Mobilgeräten oder sonstigem Hexenwerk ist hier schon gar nix los, dem Hörensagen soll es sowas geben, aber warum soll ich mir an einem Bonsai Bildschirm die Augen (noch mehr) kapputmachen?

 

Bin also wohl nicht der wirklich geeignete Testkandidat.

 

Aber, wie schon mal erwähnt, investier ne halbe Stunde Arbeit unter kundiger Anleitung (*), schon hast Du ein voll funktionsfähiges V6 LAN. Vorraussetzungen dafür wären nur eine recht moderne Fritzbox, oder ein Raspberry, der nix zu tun hat (letzterer ist dann zwar nicht die Performance Grille, aber solange Deine Internetleitung unter 100Mbit/s liegt, wirst Du nix davon merken).

 

So als Einsteigerübung kannst Du schon mal anfangen und "::1" aus dem Gedächtnis streichen. Es existiert zwar aus Kompatibilitätsgründen, sollte aber möglichst nicht benutzt werden, schon gar nicht von Applikationen. Es kommt eigentlich nur zum Einsatz beim Starten essentieller Basisdienste (Booten des Rechners), im normalen Betrieb laufen keine Verbindungen darüber.

Grundsätzlich gilt: "je globaler, desto besser, desto höhere Priorität". Also Adressen mit limitiertem Geltungsbereich werden weniger oder gar nicht mehr verwendet, sobald Adressen mit weiterer Reichweite verfügbar sind. Die Fritzbox z.B. stellt Adressen (ULA = unique local address) für lokalen Bereich (FC00:: ... FDFF::) zur Verfügung, solange sie KEINE Internetverbindung aufgebaut hat, löscht diese aber normalerweise (kann man abschalten) aber sofort, sobald eine Verbindung hergestellt wurde und ein globaler Präfix bezogen wurde.

Deshalb wird auch im LAN hinterher mit der "Internetadresse" gearbeitet, was bei vielen Programmen heute Sicherheitsprobleme hervorruft, da die Programmierer dank NAT gewohnt sind: "das HeimLAN ist "sicher"". Von dem Gedanken muss man sich schnell verabschieden, und andere Vorkehrungen einbauen. Und auch die "Bindungen an eine IP Adresse", wie sie jetzt zur Sicherung der Dienste des DMS benutzt werden, sind Makulatur. Adressen sind dynamisch, sie können jederzeit im Betrieb gelöscht werden, hinzukommen, sich ändern. Du musst also neue Callbacks vorsehen, die die Statusänderungen der Adressen abfangen und entsprechend reagieren. Selbst wenn man (in Deutschland leider unüblich) einen statischen Präfix erhält, die Voreinstellung der meisten Betriebssysteme enthält inzwischen die aktivierten "Privacy Extensions", damit wechselt der Klient selbstständig innerhalb einer Zeitspanne (meist 24h) seine Adresse (völlig zufällige Auswahl).

 

So einfach, wie Du Dir den Umbau vorstellst, wird es also nicht werden. Nicht umsonst bezog sich meine ursprüngliche Anfrage nur auf eine Weiterleitung des Webinterfaces...

 

(*) nimm nicht jeden Jungspund mit nur 30 Jahren Erfahrung. Vertrau besser auf wirkliche Veteranen 😎

 

Share this post


Link to post
Griga
10 hours ago, MaM said:

Vorraussetzungen dafür wären nur eine recht moderne Fritzbox, oder ein Raspberry, der nix zu tun hat

 

Weder noch vorhanden.

 

Hmm, auch ohne solche Hardware kommt bei der Abfrage der Adapter einiges zusammen - was habe ich davon zu halten? Mit allen IPv6-Adressen kann ich das Webinterface lokal im Browser aufrufen...

 

Zwischenablage01.png

 

Share this post


Link to post
nuts

Ich könnte für Entwicklerzwecke eine Fritz!Box 3370 zur Verfügung stellen.

Laut einer kurzen google Suche müsste die Kiste ipv6 tauglich sein, aber ich kenn mich da kein bisschen aus.

Sollte das weiterhelfen schick ich dir die Kiste Griga.

 

 

Share this post


Link to post
MaM

davon ist GAR NICHTS zu halten. "FE80..." sind sogenannte "link local addresses", sie gelten nur für das Kabelsegment, dass an jener Netzwerkkarte angeschlossen ist.

Link Local soll/darf für Anwendungen nicht verwendet werden. Es dient nur zur initialen Findung von Klienten und als lokale Adresse für das Standardgateway (da jede Karte ihre eigene Adresse hat, kommt automatisch die "richtige" Adresse des Gateways beim Klienten an).

 

"2001::3e8a..." hingegen, WÄRE eine global gültige Adresse, aber ist wohl eher ein Fake von Dir, denn der Bereich ist für die IETF reserviert. Allerdings könnte es auch noch eine nicht deaktivierte TEREDO Schnittstelle sein (kommt auf die Netzmaske an), nur, die Server bei Microsoft sind schon lange abgeschaltet... Also hilft sie Dir nicht wirklich weiter.

 

Ohne richtigen V6 Zugang solltest Du die Programmänderungen gar nicht erst versuchen, da würde wohl kaum was Sinnvolles bei rauskommen. Du kannst den Kram natürlich auch "auf dem eigenen Rechner" einrichten, aber, das ist nicht wirklich so dasselbe, da er dann zusätzliche Router und Gateway Funktionen aktiviert, die ein normaler V6 Rechner nicht hat. Dadurch könnten einige Dinge "verfälscht" werden, und die Programmiererei in einen Irrweg abgleiten (sprich: es passieren bei Dir dann automatisch Dinge, die bei anderen nicht passieren).

Deshalb lieber in anderer Hardware unterbringen.

 

 

Share this post


Link to post
MaM
vor 1 Minute schrieb nuts:

Ich könnte für Entwicklerzwecke eine Fritz!Box 3370 zur Verfügung stellen.

Laut einer kurzen google Suche müsste die Kiste ipv6 tauglich sein, aber ich kenn mich da kein bisschen aus.

Sollte das weiterhelfen schick ich dir die Kiste Griga.

 

 

Löblich, aber auch keine wirklich gute Idee.  Die FB muss dann als sein Hauptrouter (sprich: auch für die V4 Verbindung) benutzt werden, ich geh mal davon aus, er hat schon einen und auch keine Lust, das gesamte LAN umzufrickeln, damit die FB nun der Chef ist.

Die V6 Funktion der FB ist bei reinen V4 Anschlüssen nur ein Addon, es leitet den V6 Traffic durch die V4 Verbindung, dazu muss es sie allerdings selber besitzen (sonst klappen viele Dinge mit der FB nich).

 

Die Fritzbox habe ich eigentlich nur erwähnt, weil viele Leute sie eh schon in Betrieb haben und man dann eben nur ein paar Einstellungen hinzufügen muss. Aber "alter Router weg und dafür Fritzbox hin" ist zuviel Aufwand.

 

Share this post


Link to post
Griga
27 minutes ago, nuts said:

Ich könnte für Entwicklerzwecke eine Fritz!Box 3370 zur Verfügung stellen.

 

Danke für das Angebot. Ich nehme an, die Telekom wird mich in Bälde auf VoIP umstellen wollen, da ich noch einen betagten Telekom-Router und mein heißgeliebtes Analog-Telefon in Betrieb habe, das sogar bei Stromausfall funktioniert. Dann ist ohnehin ein neuer Router fällig, und ich komme eventuell auf das Angebot zurück.

 

Das wichtige Zwischenergebnis ist für mich erst mal, dass der DMS-Webserver sich mit der aktualisierten Netzwerk-Bibliothek über IPv6-Adressen ansprechen lässt. Weiteres wird sich mit der Zeit ergeben... beim DVBViewer & DMS muss man in kleinen Schritten denken, sonst wird man rappelig im Kopf.

 

Share this post


Link to post
MaM

also stressfreier ist ein fertig konfigurierter Raspi.

 

Den steckt man einfach mit ins LAN, gönnt ihm noch ein paar Milliampere Strom, und schon hat jeder Rechner V6. Und nimmt man ihn wieder weg, ist alles, wie vorher.

 

Da braucht man an keiner Kiste etwas umkonfigurieren.

 

Und wenn Du wirklich arbeiten willst, kann ich mal die Mottenkisten hier durchforsten, das findet sich bestimmt noch so ein Ding, das ich entsprechend vorkonfigurieren kann und in ein Paket packe. Allerdings wohl nicht mehr diese Woche, habe hier reichlich zu tun, da ich gerade einen neuen Fileserver aufsetze und so knappe 50Tb Videos und Benutzerdaten rüberschaufeln muss (und ein Backup dafür konfigurieren)

Share this post


Link to post
HaraldL

Tests mit IPv6 könnte ich hier durchführen, Zeit ist zwar immer etwas knapp aber insbesondere wenn ich eine Checkliste hätte was alles ausprobiert werden könnte, dann kann ich das machen. Hab hier natives IPv6 und IPv4 parallel. Was bei IPv6 ggf. noch zu beachten ist sind die "Privacy Extensions" die z.B. hier aktiv sind (das war standardmäßig aktiv, mußte ich nicht extra einschalten). Da bekommt der Client neben der festen IPv6-Adresse zusätzlich noch eine temporäre die nur für kurze Zeit gilt und sich dann jedesmal ändert. Damit er eben nicht über eine dauerhafte eindeutige IPv6-Adresse trackbar ist. Für Internetzugriffe wird dann immer die temporäre verwendet, nachdem diese wechselt sind Antworten auf der alten temporären aber noch längere Zeit möglich (er hat also ggf. dann mehrere temporäre IPv6 parallel damit bestehende Connections nicht abbrechen).

 

Der DMS müsste in so einem Umfeld also im laufenden Betrieb mitbekommen wenn die IPv6-Adresse wechselt. Und nicht nur der temporäre hintere Teil der IPv6 ändert sich, auch das vordere Prefix wird in gewissen Zeitabständen neu zugeteilt. In der Fritzbox sieht man den für lokale Geräte zugewiesenen Präfix und dessen "Lebensdauer" übrigens auch im Menüpunkt Internet - Onlinemonitor oben. Da steht dann sowas wie:

 

Internet, IPv6
 
verbunden seit **.**.2018, **:** Uhr, Telekom, Geschwindigkeit des Internetzugangs (verfügbare Bitrate): ↓ ** Mbit/s ↑ ** Mbit/s,
IPv6-Adresse: 2003:d6:c3bf:1d****, Gültigkeit: 14282/1682s,
IPv6-Präfix: 2003:d6:c3dd:b800::/56, Gültigkeit: 13820/1220s

 

Ein "ipconfig" schaut hier z.B. etwa so aus:


 

C:\>ipconfig

Windows-IP-Konfiguration

Ethernet-Adapter LAN-Verbindung:

   Verbindungsspezifisches DNS-Suffix: fritz.box
   IPv6-Adresse. . . . . . . . . . . : 2003:d6:c3dd:b800:c4****
   Temporäre IPv6-Adresse. . . . . . : 2003:d6:c3dd:b800:bd****
   Verbindungslokale IPv6-Adresse  . : fe80::c4c1:8a****
   IPv4-Adresse  . . . . . . . . . . : 192.168.***.***
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Standardgateway . . . . . . . . . : fe80::3a10:d5****
                                       192.168.***.***

 

 

 

Edited by HaraldL

Share this post


Link to post
Griga
14 hours ago, HaraldL said:

Was bei IPv6 ggf. noch zu beachten ist sind die "Privacy Extensions" die z.B. hier aktiv sind (das war standardmäßig aktiv, mußte ich nicht extra einschalten). Da bekommt der Client neben der festen IPv6-Adresse zusätzlich noch eine temporäre die nur für kurze Zeit gilt und sich dann jedesmal ändert. Damit er eben nicht über eine dauerhafte eindeutige IPv6-Adresse trackbar ist. Für Internetzugriffe wird dann immer die temporäre verwendet

 

Was zunächst interessiert und funktionieren sollte, ist IPv6 innerhalb eines privaten Netzwerkes. Dazu gehört:

  • Der DMS ist über eine IPv6-Adresse erreichbar. Dies muss eine feste Adresse sein, weil sonst z.B. die Verwendung von M3Us mit HTTP-Adressen erschwert wird oder gar die Kommunikation mit DVBViewer-Clients unmöglich, weil sie für eine bestimmte DMS-Adresse konfiguriert sind.
  • Der DMS kann anhand einer Client-IPv6-Adresse erkennen, ob sich ein Client auf dem selben PC oder im selben (Sub-)Netzwerk befindet. Das ist bei IPv4 möglich, indem er die Client-Adresse mit den Adapter-Adressen des Server-PCs (gegebenenfalls mit Anwendung der Subnetzmasken) vergleicht.

Inwiefern ist das mit IPv6 gegeben/umsetzbar? Zugriffe aus dem Internet kommen später an die Reihe...

 

Ich hänge mal ein Tool an, das die vom DMS durch Abfrage von Windows ermittelten IPv4 und IPv6 Adressen aufzählt. Verwendet wird dabei die Funktion WSAIoctl mit SIO_GET_INTERFACE_LIST für IPv4 und SIO_ADDRESS_LIST_QUERY für IPv6.

 

Im ersten Abschnitt "Adapter IPs" erscheinen die Adressen der lokalen Netzwerk-Adapter, bei IPv4 ergänzt durch die Subnetzmaske in hexadezimaler Form in Klammern. Bei IPv6 hängt Windows am Ende eventuell nach einem % eine Zone ID an (was immer das bedeuten mag...), die man vor der Verwendung der Adresse z.B. im Browser entfernen muss.

 

Im zweiten Abschnitt "Subnet IPs" erscheinen die Subnetz-Adressen in CIDR-Notation.

 

 

IPList.zip

Share this post


Link to post
Griga
15 hours ago, MaM said:

"FE80..." sind sogenannte "link local addresses", sie gelten nur für das Kabelsegment, dass an jener Netzwerkkarte angeschlossen ist.

 

Mit der ersten der beiden bei mir angezeigten "link-local" IPv6 Adressen kann ich den DMS in meinem Netzwerk sogar von einem anderen PC aus erreichen (Windows 7 PC mit DMS -> WLAN -> Router -> LAN -> Windows 10 PC mit Firefox als Client). Das hätte ich jetzt nicht gedacht :blink:

 

Als Client-Adresse zeigt mir das Webinterface -> Statusseite dann eine (andere) link-local Adresse an.

 

Die anderen IPv6-Adressen scheitern mit Zeitüberschreitung (Server antwortet nicht).

 

Share this post


Link to post
MaM
vor 2 Minuten schrieb Griga:

Das hätte ich jetzt nicht gedacht :blink:

Das muss so sein, FE80 dient NUR zum AUFFINDEN. Dein Router muss das durchleiten, sonst würden WLAN und LAN niemals miteinander kommunizieren können. Der Router arbeitet in diesem Falle als Proxy.

 

Aber, ich wiederhole mich: VERGISS ADRESSEN, besonders FE80!

Du wirst sonst schnell tief enttäuscht werden.

 

Share this post


Link to post
Griga

Das Thema "Namensauflösung" habe ich ausgelagert.

Share this post


Link to post
HaraldL
vor 10 Stunden schrieb Griga:

Ich hänge mal ein Tool an,  ...

 

Ich vermute du wolltest eine EXE in der Zip posten, keine DSK Datei ;)

Share this post


Link to post
Griga

Danke für den Hinweis. Ich hab's korrigiert.

Share this post


Link to post
MaM

also, ich hab dann mal heute in einer müssigen Stunde (das Umkopieren der Daten auf den neuen Server läuft schon 4 Tage lang, da hat man reichlich Zeit) so einen Raspi zusammengebaut und konfiguriert.

  • einfach Strom dran und ans LAN klemmen (wobei im LAN ein Router vorhanden sein muß, der über DHCP eine V4 Adresse und ein Standardgateway zuteilt)
  • bis zur nächsten vollen Viertelstunde warten (der Cronjob für DynDNS läuft nur alle 15Min, der Tunnel muss bei Adresswechsel umkonfiguriert werden, passiert automatisch, aber eben nur alle 15Min um Traffic zu sparen)
  • V6 geniessen

An den Klienten, ob Windows, Linux oder sonstwas, ist NICHTs zu tun (sofern man nicht dran rumgefuckelt hat).

 

Da die meisten V4-only Experten einen Realitätsschock erleiden, hat die Kiste einen Firewall und lässt von aussen nur PING & Co ins LAN. Das sollte ja wohl für den Anfang reichen. Später kann man dann immer noch Regeln hinzufügen, die DMS Traffic passieren lassen. Abgehend ist natürlich ALLES freigeschaltet. (Ist also so wie bei V4 hinter einem NAT Router ohne Portweiterleitungen) (auch kein Fernwartungszugang, die Kiste ist also nicht hackbar) Das ist keine Nickeligkeit, nur Vorsicht. (Wenn Du mit Linux vertraut bist, kannste auch Monitor und Tastatur anschliessen und das (Root)Passwort kriegen, ansonsten ist die Kiste wartungsfrei)

 

Schaltet man die Kiste ab (oder trennt sie vom Netz) deaktivieren die Klienten innerhalb von 30s wieder V6 (dh. die Adresse bleibt erhalten, aber das Gateway ist weg und es können keine Pakete mehr zugestellt werden. Nach ein paar Minuten verschwinden dann auch die Adressen.)

 

Im Gegensatz zu in Deutschland üblichen Anschlüssen, sind dies STATISCHE Adressen!, der Raspi hat also immer dieselbe (aufgedruckte) Adresse und die Klienten behalten ihre auch (wenn die Privacy Extensions deaktiviert sind). Das ist zum Programmieren erstmal deutlich angenehmer als alle paar Stunden ne neue raussuchen zu müssen. Es ist auch egal, an welchem Anschluß Du das Teil betreibst, die Adresse ist überall und immer dieselbe.

 

Für später können dann noch dynamische DNS Server verwendet werden, auch (R)DNS ist mit etwas Aufwand möglich. Aber tob Dich erstmal im LAN damit aus, bevor "die Welt zu Gast bei Griga" kommt.

 

Wenn Dauerleihgabe haben wollen, schick mir ne PM mit Adresse fürs Paket...

 

Share this post


Link to post
Griga

Danke für das Angebot, aber für solche Experimente fehlt mir die Zeit. IPv6 ist zur Zeit im Gegensatz zu anderen Themen kein wirklich dringendes Problem.

 

Nichtsdestotrotz werde ich das Thema im Auge behalten und sich bietende Gelegenheiten nutzen, insbesondere auch, wenn bei mir in absehbarer Zeit wie beschrieben ein neuer Router und damit eine Reorganisation meines Netzwerkes fällig wird.

Share this post


Link to post
craig_s

Hey darf ich mal kurz in die Kamera winken?

Hallo Mam, lange nix gehört, alles gute und Gesundheit und Grüße an Onkel Cypheros von - Tante testest! :bye:

Das wars schon..

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×