E2-Receiver mit IPv6 nutzen (Dual Stack und DS-lite) - incl. CS

[Schimmelreiter]

Da bezüglich des neuen Internet-Protokolls viel Verwirrung gestiftet wurde und kaum brauchbare Quellen mit Lösungen statt des völlig falschen "geht nicht" existieren, habe ich mich entschlossen, ein kleines How-To zu verfassen, wie man

IPv6 mit einem Enigma2-Receiver nutzen​

kann.

Das How-To richtet sich dabei nicht nur an diejenigen, die IPv6 nutzen müssen (Weil sie wegen DS-lite nicht mehr per IPv4 von außen an ihr Heimnetz kommen) oder deren Gegenstellen (z.B. CS-Clients an IPv6-Servern), sondern grundsätzlich an alle, die ein bißchen mit der Zeit gehen und sich an das neue Protokoll gewöhnen wollen.

Die meisten aktuellen Images bringen zumindest eine rudimentäre Unterstützung mit, in einigen kann sie auch als halbwegs ausreichend bezeichnet werden.
Ich hoffe, mit diesem Tutorial auch ein paar der deutlichen Vorzüge von IPv6 aufzeigen zu können und so Image-Ersteller und Benutzer dazu zu animieren, IPv6 insgesamt weniger stiefmütterlich zu behandeln. IPv6 ist kein Notnagel, der erst implementiert zu werden hat, wenn das Kind durch DS-lite bereits in den Brunnen gefallen ist, sondern es sollte so oder so darauf umgestellt werden, um mit einigen der Grundprobleme von IPv4 Schluß zu machen.
Es ist deutlich angenehmer, sich rechtzeitig - also noch mit einem "vollwertigen" IPv4-Zugang in der Hinterhand - mit IPv6 zu beschäftigen, als erst dann, wenn man es muß und alles einfach nur möglichst schnell funktionieren muß.

Ohne die den Benutzern durch die Entwickler zwischen die Beine geworfenen Knüppel würde niemand mehr freiwillig IPv4 nutzen, wenn er auch IPv6 haben kann!

Ich verzichte an dieser Stelle auf technisches Hintergrundwissen zu den Gemeinsamkeiten und Unterschieden von IPv4 und IPv6 und den Gründen, warum die Umstellung auf IPv6 notwendig wurde. Wer mag, kann dies z.B.

Sie müssen registriert sein, um Links zu sehen.

nachlesen.


Inhalt

• Schritt 0: Voraussetzungen
• Schritt 1a: Ermitteln des Standes für den IPv6-Support des E2-Images
• Schritt 1b: IPv6-Support der Box verbessern (oscam austauschen)
• Schritt 2: Box für IPv6 einrichten
  • oscam
  • Web-Interface
  • Datei-Übertragung (Samba, ftp, ...)
  • Virtuelles Privates Netzwerk (VPN)

Um das eigentliche Howto übersichtlich zu halten, bitte ich darum, Rückfragen in diesem Thread zu stellen.​

 

[Schimmelreiter]

AW: E2-Receiver mit IPv6 nutzen (Dual Stack und DS-lite) - incl. CS

Schritt 0: Voraussetzungen


Was wird nun benötigt, wenn wir einen E2-Receiver auf IPv6 bzw. Dual Stack (= IPv4 und IPv6) umstellen wollen?

1. IPv6-tauglicher Internet-Zugang
   Ein Internet-Zugang kann "nativ" (d.h. bereits providerseitig) IPv6-tauglich sein oder über einen 6in4-Tunnel dazu gemacht werden.
   • Nativ (Dual-Stack)
     Bislang haben leider die wenigsten Internet-Provider in Deutschland auf den "Dual Stack"-Betrieb, also IPv6 und IPv4 gleichzeitig, umgestellt.
     Hauptsächlich sind dies bisher die All-IP-Anschlüsse der Telekom, sowie auf Anfrage 1&1-Anschlüsse bei denen die Telekom der Vorleister ist.
     Ebenfalls auf Anfrage umgestellt werden kann der Anschluß bei NetCologne/NetAachen und KabelBW (Hier bitte darauf achten, "Dual Stack" und ggf. noch "Kein DS-lite" zu betonen, um nicht auf DS-lite (= kein eingehender IPv4-Traffic mehr möglich) statt Dual Stack umgestellt zu werden!).
   • Nativ (DS-lite)
     Einige Kunden von Unitymedia, KabelBW, Kabel Deutschland, M-Net, Glasfaser Deutschland und möglicherweise weiteren Providern haben bereits DS-lite-Anschlüsse.
     Dabei handelt es sich um "abgespeckte" Dual-Stack-Anschlüsse. Diese verfügen über vollwertiges IPv6, sind aber per IPv4 nicht mehr von außen erreichbar, da sie sich IPv4-mäßig hinter einem doppelten NAT befinden, welches nicht beeinflußt werden kann. Ausgehend können von solchen Anschlüssen aus aber auch IPv4-Verbindungen aufgebaut werden.
     Für dieses Tutorial ist der Unterschied zwischen "Dual Stack" und "DS-lite" irrelevant, da ich nur IPv6 bespreche, welches ja an einem DS-lite-Anschluß vorhanden ist.
   • Tunnel-Anbindung
     An allen anderen Anschlüssen, welche noch IPv4-only angebunden sind, kann man sich recht leicht einen 6in4-Tunnel einrichten.
     Bei den Fritz!Boxen ist auch dessen besonders einfach einzurichtende Variante eines 6in4-Tunnels von SixXS möglich.
     Bei der Benutzung einer Tunnel-Anbindung behält man das IPv4 seines Internet-Anbieters und nutzt zusätzlich für IPv6-Traffic eben diesen Tunnel, das Ergebnis ist also de facto ein "Dual Stack"-Anschluß.
     Wie man diese Tunnel in einer Fritz!Box einrichtet, habe ich bereits
     Sie müssen registriert sein, um Links zu sehen.
     beschrieben.
2. IPv6-tauglicher Router
   • Perfekt geeignet ist eine AVM Fritz!Box ab 7270v2 aufwärts, bezogen auf das Alter der Box, d.h. es gehen natürlich auch abgespeckte Modelle (Keine Telefonie, keine Festnetz-Telefonie, ...) derselben oder neueren Generationen!
   • Ebenfalls geeignet sind die meisten Profi-Router (Gemeint sind 19"-Geräte von Lancom, Cisco, Juniper, ...)
   • Gut geeignet sind Asus-Router mit aktueller Firmware (Mindestens von Februar/März 2014)
   • Die meisten anderen Router sind mit Werksfirmware nicht wirklich für den IPv6-Server-Betrieb geeignet, selbst wenn IPv6-Unterstützung beworben wird!
     Der Hintergrund ist der, daß nahezu allen davon das entscheidende Feature fehlt, nämlich eine konfigurierbare IPv6-Firewall.
     Eine Firewall die nur die Zustände "ganz dicht" oder "aus" kennt, eignet sich nicht dafür, einzelne Geräte im Heimnetz gezielt für einzelne Dienste freizugeben, alle anderen Geräte und Ports aber vor Zugriff von außen zu schützen. Die Firewall behelfsweise komplett zu öffnen stellt aber ein unkalkulierbares Risiko dar!
     
     Soll die E2-Box nur als IPv6-Client laufen, dann ist diese Einschränkung unerheblich, da die Firewall auf "komplett zu" bleiben kann. "Komplett zu" läßt immer noch Antwortpakete auf von innen herausgehende Anfragen zu.
   • Bedingt geeignet sind Router mit modifizierter Firmware (DD-WRT, Open-WRT)
     Bei diesen Routern lassen sich direkt über Linux' ip6tables Firewall-Regeln definieren. Dies erfordert aber - mangels Interface in der Web-GUI - praktisch dieselben Kenntnisse über ip6tables wie unter jeder normalen Linux-Kiste auch.
3. IPv6-taugliches Firmware-Image auf der Box
   Stand Mitte April 2015 gibt es praktisch kein aktuelles Image mehr, in dem nicht zumindest das Web-Interface per IPv6 erreichbar ist und ein IPv6-fähiger oscam zumindest manuell direkt installiert werden könnte.

Um das eigentliche Howto übersichtlich zu halten, bitte ich darum, Rückfragen in diesem Thread zu stellen.

 

[Schimmelreiter]

Schritt 1a: Ermitteln des vorhandenen IPv6-Supports des E2-Images

Der folgenden Tabelle könnt Ihr den Stand der IPv6-Unterstützung verschiedener Enigma2-Images entnehmen.
Die Farbgebung bei einem "Nein" zeigt dabei gleichzeitig den Schwierigkeitsgrad der Nachrüstung an (Grün = sehr einfach, Orange = einfach, Rot = schwierig/unmöglich).
Die Farbgebung beim Image ist eine gewichtete Zusammenfassung davon.

Tabelle 1: Aktuelle Images
[table="align: left"]
[tr]
[td] Firmware/Image [/td]
[td]Linux-Kernel[/td]
[td]Python/Twisted[/td]
[td]OpenWebif[/td]
[td]Dream-Webif[/td]
[td]Streaming[/td]
[td]Streaming
(transkodiert)[/td]
[td]oscam[/td]
[td]sshd[/td]
[td]ftpd[/td]
[td]telnetd[/td]
[td]OpenVPN[/td]
[/tr]
[tr]
[td]HDMU[/td]
[td]Ja[/td]
[td]Ja[/td]
[td]Ja[/td]
[td]entfällt[/td]
[td]Ja[/td]
[td]?[/td]
[td]Nein[/td]
[td]Ja[/td]
[td]Ja[/td]
[td]Ja[/td]
[td]Ja[/td]
[/tr]
[tr]
[td]Newnigma2 (>= 5.x.y ?)³[/td]
[td]?[/td]
[td]Ja[/td]
[td]entfällt[/td]
[td]Ja[/td]
[td]Ja[/td]
[td]?[/td]
[td]Nein[/td]
[td]Ja[/td]
[td]?[/td]
[td]?[/td]
[td]?[/td]
[/tr]
[tr]
[td]OpenATV / OpenViX / OpenHDF / sonstige oe-a¹[/td]
[td]Ja[/td]
[td]Ja[/td]
[td]Ja[/td]
[td]Ja[/td]
[td]Nein[/td]
[td]Ja²[/td]
[td]Nein[/td]
[td]Ja[/td]
[td]Ja[/td]
[td]Ja[/td]
[td]Ja[/td]
[/tr]
[tr]
[td]OpenPLi 4.0[/td]
[td]Ja[/td]
[td]Ja[/td]
[td]Ja[/td]
[td]entfällt[/td]
[td]Nein[/td]
[td]Ja²[/td]
[td]Nein[/td]
[td]Ja[/td]
[td]Ja[/td]
[td]Nein[/td]
[td]Ja[/td]
[/tr]
[tr]
[td]Vu+ original incl. VTI/Black Hole[/td]
[td]Ja[/td]
[td]Nein[/td]
[td]Nein[/td]
[td]Nein[/td]
[td]Nein[/td]
[td]Nein[/td]
[td]Nein[/td]
[td]Ja[/td]
[td]Nein[/td]
[td]Nein[/td]
[td]Nein[/td]
[/tr]
[tr]
[td]VTI 8.2.0[/td]
[td]Ja[/td]
[td]Ja[/td]
[td]Ja[/td]
[td]entfällt[/td]
[td]Nein[/td]
[td]Nein[/td]
[td]Nein[/td]
[td]Ja[/td]
[td]Nein[/td]
[td]Nein[/td]
[td]Nein[/td]
[/tr]
[/table]
Tabelle 2: Veraltete Images (Nur solche, die noch vielfach in Gebrauch sind, z.B. wegen DM800/DM800se/DM500HD/DM500HDv2-Clones)

Spoiler

[table="align: left"]
[tr]
[td] Firmware/Image [/td]
[td]Linux-Kernel[/td]
[td]Python/Twisted[/td]
[td]OpenWebif[/td]
[td]Dream-Webif[/td]
[td]Streaming[/td]
[td]Streaming
(transkodiert)[/td]
[td]oscam[/td]
[td]sshd[/td]
[td]ftpd[/td]
[td]telnetd[/td]
[td]OpenVPN[/td]
[/tr]
[tr]
[td]Newnigma2 (<= 4.x.y ?)³[/td]
[td]Optional[/td]
[td]Nein[/td]
[td]entfällt[/td]
[td]Nein[/td]
[td]Nein[/td]
[td]entfällt[/td]
[td]Nein[/td]
[td]Ja[/td]
[td]Nein[/td]
[td]Nein[/td]
[td]Nein[/td]
[/tr]
[tr]
[td]OpenPLi 2.1/3.0[/td]
[td]Ja[/td]
[td]Nein[/td]
[td]Nein[/td]
[td]Nein[/td]
[td]Nein[/td]
[td]Nein[/td]
[td]Nein[/td]
[td]Ja[/td]
[td]?[/td]
[td]Nein[/td]
[td]Nein[/td]
[/tr]
[tr]
[td]Vu+ original incl. VTI/Black Hole[/td]
[td]Ja[/td]
[td]Nein[/td]
[td]Nein[/td]
[td]Nein[/td]
[td]Nein[/td]
[td]Nein[/td]
[td]Nein[/td]
[td]Ja[/td]
[td]Nein[/td]
[td]Nein[/td]
[td]Nein[/td]
[/tr]
[/table]

1. oe-a = "OpenEmbedded Alliance" mit folgenden Members/Images: OpenViX, OpenATV, OpenMIPS, OpenHDF, u.v.m.
   Die Angaben beziehen sich auf jeweils aktuelle Versionen, z.B. OpenATV >=4.2, OpenViX >=165, usw.
   IPv6-Support für DM800/DM800se/DM500HD/DM500HDv2 seit 15.4.2015
2. ggf. modellabhängig
3. stellvertretend für alle Images, die direkt auf dem aktuellen "Dream Multimedia"-Code aufbauen, z.B. auch Merlin

Denjenigen die die Liste schon länger beobachten mag aufgefallen sein, daß ich einige Images in der Gesamtwertung herabgestuft habe.
Das resultiert daraus, daß man vor über einem Jahr als die Liste begonnen wurde noch dankbar sein mußte, wenn man die IPv6-Kernelmodule nicht selber nachladen mußte und man am Ende einen IPv6-fähigen oscam auf der Box betreiben konnte.

Seitdem aber selbst Dream und Vu+ in ihren Images passablen IPv6-Grundsupport bieten ist auch die Erwartungshaltung gestiegen:
Der Benutzer dürfte eigentlich gar nichts mehr reparieren müssen, deshalb kann in 2015 ein Image nur dann noch als "orange" bewertet werden, wenn zumindest das eingebaute Web-Interface ohne vorherigen Benutzereingriff IPv6-fähig ist (incl. der sich daraus ergebenden Voraussetzungen, daß Linux-Kernel und Python IPv6-fähig sein müssen).
Für eine grüne Bewertung darf der Benutzer jetzt auch bei der Nutzung des im Image enthaltenen/vom Feed verfügbaren OpenVPN und transkodierten Streaming keine unnötigen Knüppel mehr zwischen die Beine bekommen.


Sollte die von Euch verwendete Firmware/Image nicht in der obigen Liste enthalten sein, kann der IPv6-Support der Box wie folgt ermittelt werden:

Spoiler

Wenn ich im Folgenden von "auf der Box" spreche, dann meine ich damit auf einer Konsole, also innerhalb einer telnet- oder ssh-Sitzung zur Box.

1. Linux-Kernel
   IPv6-Support im Linux-Kernel ist zwingend erforderlich, alles weitere baut auf diesem auf. Ohne IPv6-Support im Kernel ist somit gar keine IPv6-Nutzung möglich.
   Zum Glück wird diese Voraussetzung inzwischen von den meisten Images erfüllt.
   
   Ob der Kernel mit IPv6-Support gebaut wurde, läßt sich ganz einfach ermitteln. Dazu auf der Box folgendes Befehlszeile eingeben:
   

   [ -e /proc/net/if_inet6 ] && echo "IPv6 vorhanden"

   
   Das Ergebnis sollte wie folgt aussehen:
   

   root@ultimo:~# [ -e /proc/net/if_inet6 ] && echo "IPv6 vorhanden"
   IPv6 vorhanden

   
   Kommt hingegen keine Antwort "IPv6 vorhanden", so wurde der Kernel entweder ohne IPv6 gebaut oder IPv6 wurde als Modul gebaut, welches separat installiert werden muß.
   
   
   Spoiler

   Sollte dies der Fall sein, kann man auf der Box wie folgt (opkg ggf. durch ipkg ersetzen) nach dem Modul suchen:
   

   opkg update
   opkg list *ipv6*

   
   Auf dem Bildschirm sollte nun in etwa Folgendes stehen:
   

   root@ultimo:~# opkg update
   Downloading http://...
   Inflating http://...
   ...
   root@ultimo:~# opkg list *ipv6*
   kernel-module-ipv6 - 3.1.1-r4.10.13 - ipv6 kernel module  ipv6 kernel module; IPv6 protocol stack for Linux
   packagegroup-base-ipv6 - 1.0-r76 - IPv6 support  Merge machine and distro options to create a basic machine
   root@ultimo:~#

   
   Wir wissen also nun, daß für unser Image die beiden Pakete "kernel-module-ipv6" und "packagegroup-base-ipv6" für den IPv6-Support erforderlich sind.
   
   Diese beiden Pakete können wir nun durch folgende Eingabe installieren:
   

   opkg install kernel-module-ipv6 packagegroup-base-ipv6

   Dabei sind natürlich die Paketnamen "kernel-module-ipv6" & "packagegroup-base-ipv6" durch die zu ersetzen, die Ihr bei "opkg list *ipv6*" genannt bekommen habt.
   
   Sollte die Ausgabe von "opkg list *ipv6*" hingegen am Ende so ausgesehen haben:
   

   root@ultimo:~# opkg list *ipv6*
   root@ultimo:~#

   dann gibt es keinen IPv6-Support für Euer Image, in diesem Fall bitte dringendst dem Entwickler-Team damit auf die Nüsse gehen! :emoticon-0178-rock:
   Bis dieses Problem gelöst ist (Image-Update/-Wechsel, eigener Kernel), könnt Ihr hier mit dem Lesen aufhören, da ist nichts zu machen.
2. oscam
   Ob oscam mit IPv6 gebaut wurde, könnt Ihr durch Eingabe von
   

   oscam -V

   auf der Box prüfen.
   
   Es werden alle "Build options", also Einstellungen vom Bau des oscam, angezeigt, wobei uns nur folgende Zeile interessiert:
   

   IPv6 support:                  yes

   bzw. eben
   

   IPv6 support:                  no

   
   
   Spoiler

   Sollte die Ausgabe "no" lauten, dann habt Ihr auf Eurer Box einen IPv6-untauglichen oscam.
   Ein Problem ist das aber nicht weiter, da der oscam einfach ersetzt werden kann.
   
   Solltet Ihr auf die Eingabe "oscam -V" folgende Fehlermeldung erhalten haben ...
   

   -sh: oscam: not found

   ... dann liegt oscam bei Euch nicht im Suchpfad, sondern wird in irgendwelchen Start-Scripts mit Pfadangabe aufgerufen.
   
   In diesem Fall könnte Ihr den Pfad wie folgt ermitteln, sofern oscam gerade läuft:
   

   ps -l | grep oscam

   
   Ihr erhaltet voraussichtlich in etwa folgende Ausgabe:
   

   Topf:~# ps -l | grep oscam
   S     0  1482     1  3700     4 0:0   17:00 00:00:00 /usr/emu/oscam8755 -b -c
   S     0  2691  1482 17588  1516 0:0   17:13 00:01:50 /usr/emu/oscam8755 -b -c
   S     0 28535 27906  2200   504 pts0  14:27 00:00:00 grep oscam
   Topf:~#

   
   Damit wissen wir, daß die oscam-Binary den Namen und Pfad "/usr/emu/oscam8755" hat und können sie nun entsprechend aufrufen:
   

   /usr/emu/oscam8755 -V

   
   Nun solltet Ihr ebenfalls die Ausgabe der "Build options" vor Euch sehen, darunter auch die Zeile "IPv6 support: yes" oder eben ""IPv6 support: no"
3. Python & Twisted (Nice to have, aber nicht zwingend nötig)
   Praktisch alles auf Eurer E2-Kiste ist in der Script-Sprache Python geschrieben. Erst diese Scripts machen aus Linux+tuxbox+tuxtxt Enigma2.
   Da z.B. auch das Web-Interface in Python und dem Python-Modul "Twisted" geschrieben ist, kann es nur dann direkt IPv6 unterstützen, wenn auch Python mit IPv6-Unterstützung gebaut wurde und Twisted halbwegs aktuell ist. Ersteres ist leider auf den wenigsten Images der Fall, letzteres schon eher.
   
   Aktuelle Images von OpenPLi 4.0 und HDMU erfüllen diesen Punkt auf jeden Fall.
   
   
   Spoiler

   Folgender Befehl auf der Box prüft den IPv6-Support von Python und die Version von Twisted:
   

   python -c 'import twisted,socket; print socket.has_ipv6; print twisted.version'

   
   Das Ergebnis sollte auf dem Terminal nun in etwa so aussehen:
   

   root@ultimo:~# python -c 'import twisted,socket; print socket.has_ipv6; print twisted.version'
   True
   [twisted, version 12.0.0]

   
   Dies wäre der Idealzustand, wie er m.W. "out-of-the-box" nur bei OpenPLi 4.0 gegeben ist:
   1. Python wurde mit IPv6-Support gebaut ("True")
   2. Twisted hat die Versionsnummer 12.0.0. (Mindestversion für IPv6: 12.0.0)
   
   Das Ergebnis könnte auch so aussehen (HDMU-Image):
   

   Topf:~# python -c 'import twisted,socket; print socket.has_ipv6; print twisted.version'
   False
   [twisted, version 13.0.0]

   
   In diesem Fall ist zwar Twisted ausreichend aktuell, aber Python hat keinen IPv6-Support. Beide Bedingungen müssen für das Web-Interface erfüllt sein.
   Bittet in diesem Fall die Entwickler Eures Images, Python demnächst mit IPv6-Support zu bauen. Es schaden denjenigen nicht, die es nicht nutzen wollen, aber ist Voraussetzung für diejenigen, die es brauchen oder nutzen möchten.

Um das eigentliche Howto übersichtlich zu halten, bitte ich darum, Rückfragen in diesem Thread zu stellen.

 

[Schimmelreiter]

AW: E2-Receiver mit IPv6 nutzen (Dual Stack und DS-lite) - incl. CS

Schritt 1b: IPv6-Support der Box verbessern

Hier beschreibe ich, wie man den IPv6-Support seiner E2-Box verbessert, wenn sich beim derzeitigen Stand laut Schritt 1a Lücken ergeben haben.

• Linux-Kernel
  forget it
• oscam
  oscam ist grundsätzlich vollständig IPv6-tauglich. Leider wird kaum jemand auf seinem Image bereits einen brauchbaren vorfinden.
  Daher müssen wir ihn noch ersetzen, bevor wir oscam per IPv6 nutzen können ...
  1. Box/Hardware-Plattform identifizieren
     
     Spoiler

     Auch wenn alle E2-Boxen Linux als Betriebssystem verwenden, so nutzen sie doch unterschiedliche Prozessortechnologien.
     Dadurch gibt es nicht "einen" oscam, sondern es muß ein zum Gerät passender verwendet werden.
     
     Um die Prozessorarchitektur zu ermitteln, gibt man auf der Box
     

     uname -m

     ein, was ungefähr folgende Ausgabe produzieren sollte:
     

     root@ultimo:~# uname -m
     mips
     root@ultimo:~#

     
     Diese Box nutzt also eine mips-Plattform.
     
     Den Namen der Box (Vu+ Ultimo, Dreambox 800SE, AZbox, usw.) solltet Ihr auch ohne meine Hilfe wissen
  2. oscam bauen/herunterladen
     • Für jeden, der wenigstens ein bißchen mit Linux klarkommt, empfehle ich, sich selber einen passenden oscam mittels
       Sie müssen registriert sein, um Links zu sehen.
       zu bauen. Das ist auch nicht schwieriger - eher leichter - als z.B. ein Freetz-Image für die Fritz!Box zu bauen.
     • Für alle anderen habe ich hier im Downloadbereich eine Sammlung von IPv6-tauglichen oscams für die meisten Boxen hochgeladen: Link Removed
       Alle oscams wurden mit SSL und IPv6 gebaut, ebenso mit Support für alle üblichen und unüblicheren Cardreader und die Sharing-Protokolle newcamd und cccam.
       
       Da ich natürlich selber nicht alle Boxen/CardReader/udgl. haben kann, kann ich die Builds auch nicht getestet haben ... verzeiht mir also bitte, wenn einzelne Build ggf. auf einzelnen Images nicht laufen.
       Solltet Ihr einen speziellen Build brauchen, dann könnt Ihr Euch gerne bei mir melden und ich werde sehen, was ich tun kann.
  3. Vorhandenen oscam finden
     
     Spoiler

     Dazu gebt Ihr auf der Box ein:
     

     which oscam

     
     Daraus folgt diese Ausgabe:
     

     root@ultimo:~# which oscam
     /usr/bin/oscam
     root@ultimo:~#

     
     Sie sagt uns, daß die zu ersetzende oscam "binary" die Datei /usr/bin/oscam ist.
     
     Sollte sie so aussehen:
     

     root@ultimo:~# which oscam
     root@ultimo:~#

     dann wurde der oscam auf diesem Wege nicht gefunden.
     
     Wenn er gerade läuft, dann kann er aber mittels
     

     ps -l | grep oscam

     gefunden werden:
     

     Topf:/# ps -l | grep oscam
     S     0  1482     1  3700     4 0:0   Mar06 00:00:00 /usr/emu/oscam8755 -b -c
     S     0  2691  1482 17588  1524 0:0   Mar06 00:02:02 /usr/emu/oscam8755 -b -c
     S     0  6227 27906  2196   416 pts0  17:46 00:00:00 grep oscam
     Topf:/#

     in diesem Fall wäre also /usr/emu/oscam8755 unsere zu ersetzende oscam "binary".
  4. Vorhandenen oscam sichern
     
     Spoiler

     Als allererstes machen wir von der zu ersetzenden Binary eine Sicherheitskopie. Dazu gebe man auf der Box
     

     cd /usr/bin

     ein, wobei "/usr/bin" durch "alles bis zum letzten /" der selber gefundenen oscam-Binary zu ersetzen ist.
     
     Dort gibt man dann
     

     cp oscam oscam.knowngood

     ein, um eine Kopie von oscam unter dem Namen "oscam.knowngood" anzulegen.
     Auch hier ist mindestens das erste "oscam" durch den tatsächlichen Namen der selber gefundenen Binary zu ersetzen, also den Teil nach dem letzten /, im Beispiel für die per "ps -l | grep" gefundene oscam-Binary wäre das also "oscam8755".
  5. Neuen oscam testen
     
     Spoiler

     Kopiert nun den neuen oscam (Selbst gebaut oder aus meinem Archiv) irgendwie (ftp, Netzwerk-Freigabe, ssh, ...) irgendwo auf die Box oder irgendwohin, wo ihr von der Box aus drankommt (z.B. ein in die Box eingebundenes NAS).
     
     Wechselt an den Speicherort der neuen oscam Binary, z.B. mittels
     

     cd /hdd/movie

     falls Ihr den oscam im Verzeichnis mit den Aufnahmen auf der boxeigenen Festplatte abgelegt habt.
     
     Dort gebt Ihr ein
     

     ./oscam -V

     
     Nun sollte, ähnlich wie beim Prüfen der Voraussetzungen, zu sehen sein, mit welchen Optionen oscam gebaut wurde.
     Wird hingegen ein "segmentation fault" oder sonst eine englische Fehlermeldung ausgegeben, dann habt Ihr entweder einen oscam für die falsche Plattform (Siehe Punkt 1) genommen oder Ihr (oder ich) den oscam mit für Eure Box ungeeigneten Einstellungen gebaut.
     In diesem Fall nicht weitermachen, sondern zuerst einen geeigneten oscam bauen/beschaffen, also diese Anleitung ab Punkt 1 wiederholen.
  6. oscam ersetzen
     
     Spoiler

     Linux zeigt ein sehr seltsames Verhalten beim Ersetzen von laufenden Programmen. Einerseits können laufenden Programme auch aus dem Speicher heraus immer wieder mit der alten Version neu gestartet werden, auch kann die vorhandene oscam-Binary meist gelöscht werden, aber sie kann selten direkt überschrieben werden.
     
     Also wechseln wir in das Verzeichnis, in dem sich unser zu ersetzender oscam befinden (Siehe Schritt 2)
     

     cd /usr/bin

     und löschen den vorhandenen oscam
     

     rm oscam

     
     Nun kann der bereits im vorherigen Schritt auf die Box/in Reichweite der Box kopierte oscam auf der Box an denselben Ort umkopiert werden, an dem sich auch der alte befand:
     

     cp /hdd/movie/oscam /usr/bin/oscam

     
     "cp" ist der Befehl zum Kopieren einer Datei unter Linux, "mv" verschiebt eine Datei und "rm" löscht sie.
     Für cp und mv lautet die Syntax:
     

     cp|mv Quelle Ziel

     
     Beispiele:
     

     cp /hdd/movie/oscam /usr/bin/oscam

     kopiert die Datei "oscam" aus dem Verzeichnis "/hdd/movie" (I.d.R. ist dies der Pfad zu den Aufnahmen auf Eurer Festplatte) ins Verzeichnis "/usr/bin", wo sie ebenfalls wieder "oscam" heißen wird.
     
     

     mv /hdd/movie/oscam /usr/emu/oscam8755

     verschiebt die Datei "oscam" aus dem Verzeichnis "/hdd/movie" ins Verzeichnis "/usr/emu" und benennt sie dabei in "oscam8755" um.
  7. Neuen oscam starten
     Um den neuen oscam zu starten, startet am besten die Box neu.
     
     Der neue oscam muß jetzt bereits zumindest so funktionieren, wie der alte.
• Python/Twisted
  Lieber nicht.

Um das eigentliche Howto übersichtlich zu halten, bitte ich darum, Rückfragen in diesem Thread zu stellen.

 

[Schimmelreiter]

AW: E2-Receiver mit IPv6 nutzen (Dual Stack und DS-lite) - incl. CS

Schritt 2: Box für IPv6 einrichten

Nachdem wir die eigentlich unnötigen Schritten 1a/1b abgeschlossen haben (Unnötig deshalb, weil sich die Schritte 1a/1b auf "Installiert ein aktuelles Image" reduzieren würden, wenn die Entwickler der Images einfach mal ihre ganzen "--disable-ipv6"-Switches aus der Build-Umgebung ihrer Images nehmen und nicht mit uralten Programmversionen rumhantieren würden ....), können wir uns nun dem eigentlichen Ziel dieses How-Tos widmen, dem Konfigurieren unserer Box für IPv6.

Teil 1: oscam

Da sich die grundsätzliche Arbeitsweise von IPv4 und IPv6 nicht unterscheidet, sind die Änderungen überschaubar. Es gibt eigentlich nur drei Stellen, an denen IPv6 berücksichtigt werden muß bzw. kann.

1. Oscam-Oberfläche/Monitor/Web-Interface (oscam.conf)
   Um die oscam selber auch per IPv6 erreichen zu können, müssen ggf. folgende Punkte in oscam.conf geändert werden:
   • nocrypt im Abschnitt [monitor]
     Hiermit wird eingestellt, von welchen IPs aus unverschlüsselte Verbindungen zum oscam-Monitor möglich sein sollen.
     Wird der oscam-Monitor nicht nach außen geöffnet (Dringend empfohlen!) ist dies die empfohlene Einstellung:
     

     nocrypt                  = 127.0.0.1,192.168.0.0-192.168.255.255,::1,fd00::-fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff,2000::-3fff:ffff:ffff:ffff:ffff:ffff:ffff:ffff

     Spoiler

     nocrypt                       = 127.0.0.1,192.168.0.0-192.168.255.255,::1,fd00::-fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff

     Ermöglicht unverschlüsselte Verbindungen zum Monitor nur aus dem IPv4- und IPv6-Heimnetz.
     (Die IPv6-Adresse ::1 entspricht dem localhost bzw. 127.0.0.1 bei IPv4 und der Bereich fd00::-fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff ist für ULAs (Unique Local Addresses) reserviert, die den bekannten privaten IPv4-Adressen - also z.B. 192.168.x.y - entsprechen)
     
     Aber Achtung:
     Da bei IPv6 genügend Adressen für alle zur Verfügung stehen, wird auch innerhalb des Heimnetzes mit den öffentlichen IPv6-Adressen gearbeitet, dafür entfällt z.B. in den Standardeinstellungen der Fritz!Boxen die ULA, sobald eine Außenanbindung besteht.
     Somit wäre der Monitor mit der vorgenannten Einstellung auch nicht mehr unverschlüsselt aus dem Heimnetz erreichbar.
     Sofern Ihr ein statisches Präfix habt (Das wird in der Regel nur bei einer Tunnel-Anbindung der Fall sein oder bei NetCologne/NetAachen, sofern auch die IPv4 als statische IP bestellt wurde, normal ist ansonsten aber leider ein dynamisches Präfix), könnt Ihr dieses daher auch noch aufnehmen:
     

     nocrypt                       = 127.0.0.1,192.168.0.0-192.168.255.255,::1,fd00::-fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff,2a02:908::-2a02:908:ffff:ffff:ffff:ffff:ffff:ffff

     (Dieses Beispiel erlaubt zusätzlich zu den diversen lokalen IPs noch den gesamten IPv6-Adressbereich von Unitymedia ... an dieser Stelle nicht sehr sinnvoll sondern nur Illustration)
     
     Ohne statisches Präfix ist eine sinnvolle Konfiguration bei nach außen geöffnetem Monitor-Port derzeit leider nicht möglich!
   • httpallowed im Abschnitt [webif]
     Dieser Parameter regelt, wer auf das Web-Interface des oscam zugreifen kann.
     Achtung: Ich empfehle, den Zugriff von außerhalb nur dann freizugeben, wenn man oscam für SSL/https konfiguriert hat, da sich ansonsten der gesamte Verkehr zwischen dem oscam-Webinterface und dem Client mitloggen läßt (Unabhängig ob IPv4 oder IPv6)!
     
     Solange der Port des Web-Interfaces nicht nach außen geöffnet wird oder aber das WebInterface von überall aus erreichbar sein soll, wäre dies die empfohlene (problemloseste) Einstellung:
     

     httpallowed                  = 127.0.0.1,0.0.0.0-255.255.255.255,::1,fd00::-fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff,2000::-3fff:ffff:ffff:ffff:ffff:ffff:ffff:ffff

     Weitere Beispiele:
     Spoiler

     httpallowed                  = 127.0.0.1,192.168.0.0-192.168.255.255,::1,fd00::-fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff,2a02:908::-2a02:908:ffff:ffff:ffff:ffff:ffff:ffff

     = Zugriff aus dem Heimnetz per IPv4 und IPv6 möglich, ebenso per IPv6 aus dem gesamte Unitymedia-Netz.
     
     

     httpallowed                  = 127.0.0.1,192.168.0.0-192.168.255.255,::1,fd00::-fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff,2000::-3fff:ffff:ffff:ffff:ffff:ffff:ffff:ffff

     = Zugriff aus dem Heimnetz per IPv4 und IPv6 möglich, ebenso per IPv6 aus dem gesamte Internet.
     
     

     httpallowed                  = 127.0.0.1,0.0.0.0-255.255.255.255,::1,fd00::-fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff,2000::-3fff:ffff:ffff:ffff:ffff:ffff:ffff:ffff

     = Zugriff aus dem Heimnetz per IPv4 und IPv6 möglich, ebenso per IPv4 und IPv6 aus dem gesamte Internet.
2. Readers/Proxies (oscam.server)
   • device
     An dieser Stelle kann bei einem oscam mit IPv6-Support auch eine IPv6-IP statt eines Hostnames oder einer IPv4 eingetragen werden.
     
     Beispiel:
     

     device                     = 2001:db8:affe:c0c0:face:b00c:1234:5678,10015

     verbindet mit dem Server mit der IPv6 2001:db8:affe:c0c0:face:b00c:1234:5678 auf Port 10015
     
     Ihr könnt natürlich auch einen DynDNS-Hostname, der sich auf eine IPv6 auflösen läßt verwenden, in dem Fall ändert sich optisch nichts.
     
     Achtung:
     Immer wieder falsch verstanden wird der Sinn eines Hostnames. Ein DynDNS-Hostname hat einzig und allein den Zweck, eine (sich ggf. ändernde) schlecht zu merkende IP-Adresse durch einen leichter zu merkenden Namen zu ersetzen.
     Das heißt aber nur, daß Euer Gerät dann selber "nachschlägt", welche IP-Adresse sich dahinter verbirgt und diese kontaktiert.
     Natürlich kann ein IPv4-only-Client einen IPv6-Server auch dann nicht erreichen, wenn der IPv6-Server einen hübschen DynDNS-Hostname für seine IPv6 hat.
     So (IP-Adresse) oder so (Hostname): Server und Client müssen beide das selbe Protokoll unterstützen.
     
     Wenn Euer Onkel Otto in Namibia wohnt und Ihr eine Sperre für Auslandstelefonate habt, dann könnt Ihr Onkel Otto ja auch nicht anrufen, nur weil Ihr ihn unter "Onkel Otto" im Telefonbuch des Telefons habt.
     Egal ob selber gewählt oder aus dem Telefonbuch, seine Nummer bleibt 00264 ... und das ist und bleibt eine Auslandsrufnummer.
3. Benutzerkonfiguration (oscam.user)
   • hostname
     Wenn Ihr einen Benutzer bezüglich der IP-Adressen von denen aus er auf den oscam zugreifen darf einschränken wollt, dann habt Ihr in dessen Konto bisher z.B. diese Zeile stehen:
     

     hostname = 137.54.27.93

     oder - wahrscheinlicher - für die Definition über einen DynDNS-Host:
     

     hostname = larifari.dyndns.org

     
     Bei diesem Parameter gibt es nun zwei Aspekte zu berücksichtigen:
     1. Jedes Gerät hat seine eigene IPv6-Adresse, bei IPv4 hat aber das gesamte Heimnetz nach außen nur eine einzige und teilt sich diese per NAT ...
        
        Hat nun ein User mehrere Receiver zuhause stehen und greift von jedem davon direkt per IPv6 statt per IPv4 auf Euren Server zu, dann wird er dies nun mit unterschiedlichen IP-Adressen tun, statt wie vorher mit nur einer.
        In diesem Szenario muß also entweder der Benutzer die Zugriffe auf Euren Server auf einen einzigen seiner Receiver beschränken und dann von dort aus selber in seinem Netz weiterverteilen (Wozu Ihr ggf. die erlaubten hops erhöhen müßt) oder Ihr müßt weitere Benutzer anlegen, nämlich für jeden zulässigen Receiver einzeln.
     2. Hat der User einen DynDNS-Dienst, der sich nur auf eine IPv4-Adresse auflösen läßt, dann kann er auch nur von dieser IP aus zu Eurem Server verbinden und das natürlich auch nur, wenn Eurer Server auch per IPv4 erreichbar ist (Also gar nicht mehr, wenn Ihr hinter einem DS-lite-Anschluß hängt). Wundert Euch also nicht, wenn ein so beschränkter User nicht per IPv6 auf Euren Server kommt.
        Umgekehrt gilt das natürlich genauso: Bei einem nur auf eine IPv6-Adresse auflösbaren DynDNS-Host kann der User sich auch nur noch per IPv6 mit Eurem Server verbinden.
        
        Nur wenn der DynDNS-Hostname auf beide Adressen auflösbar ist, kann der User auch über beide Protokolle auf Euren Server (Sofern dieser auch über beide Protokolle erreichbar ist).

Um das eigentliche Howto übersichtlich zu halten, bitte ich darum, Rückfragen in diesem Thread zu stellen.

 

[Schimmelreiter]

AW: E2-Receiver mit IPv6 nutzen (Dual Stack und DS-lite) - incl. CS

Schritt 2: Box für IPv6 einrichten

Teil 2: Web-Interface

• OpenWebif
  Das Web-Interface "OpenWebif", welches aus lizenzrechtlichen Gründen sowieso auf den meisten Boxen verwendet wird, ist bereits out-of-the-box IPv6-ready.
  Sobald alle Voraussetzungen vorliegen (Linux-Kernel und Python mit IPv6-Support gebaut und Twisted mit mindestens der Version 12.0.0 vorhanden) wird das OpenWebif automatisch im "Dual Stack"-Betrieb laufen, sich also sowohl über IPv6 als auch über IPv4 erreichen lassen.
• "Old Webinterface" / Dream Webinterface
  Der Stand des IPv6-Supports im Dream Webinterface oder dem daraus abgeleiteten "old webinterface" mancher Images ist mir nicht bekannt und - aufgrund der Lizenzprobleme - auch sch...egal. Dream Multimedia ist es übrigens noch egaler.
• Relativ sicher ist aber, daß das "old webinterface" auf non-DMM-Boxen i.d.R. keine IPv6-Unterstützung haben wird, da es einen alten Stand des Dream Webinterfaces immer weiter nutzt.
• Zugriff auf das Web-Interface über IPv6
  Der Zugriff auf das Web-Interface über IPv6 gestaltet sich prinzipiell völlig unproblematisch:
  Alle auch nur halbwegs aktuellen Browser beherrschen IPv6 und können das Web-Interface daher auch problemlos darüber erreichen.
  Auch die App "DreamDroid" unterstützt IPv6, kann also - IPv6-Unterstützung am Ort des Zugriffs vorausgesetzt - ebenfalls problemlos per IPv6 auf das Web-Interface zugreifen

Um das eigentliche Howto übersichtlich zu halten, bitte ich darum, Rückfragen in diesem Thread zu stellen.

 

[Schimmelreiter]

AW: E2-Receiver mit IPv6 nutzen (Dual Stack und DS-lite) - incl. CS

Schritt 2: Box für IPv6 einrichten

Teil 3: Datei-Übertragung (Samba, ftp, ...)

• Samba/CIFS/Windows-Freigaben
  
  Spoiler

  Samba unterstützt prinzipiell seit Version 3.2.x IPv6.
  
  Eine kleine Anmerkung hierzu:
  CIFS/SMB (Also das eigentliche Protokoll) ist unter IPv6 nur in Bezug auf Port 445 definiert. Die TCP/UDP-Ports 137-139 werden von der Definition des IPv6-Supports in CIFS nicht mehr erfaßt, sie sind aber auch unter IPv4 nur noch historisch.
  Siehe auch

  Sie müssen registriert sein, um Links zu sehen.

  , Zitat "Neuere Windows-Versionen nutzen SMB direkt auf dem TCP-Port 445 und lösen Namen per DNS und in kleinen Netzwerken per LLMNR auf.".
  
  Beim Samba wird Euch jedoch vermutlich das selbe Problem begegnen wie schon bei Python, nämlich eine Version, die ohne Not ohne IPv6-Support gebaut wurde.
  Ein weiteres häufiges Problem wird sein, daß auf E2-Boxen gerne aus Gründen des Speicherplatzes/RAM-Bedarfs ein deutlich älterer Samba, oft Version 3.0.37, verwendet wird, für den es keinen offiziellen IPv6-Support gibt.
  
  Auch hier kann ich nur empfehlen, bei den Entwicklern des Images anzufragen, ob diese Samba nicht in Zukunft IPv6-fähig bauen können, sofern sie einen entsprechend neuen Samba (3.2+) verwenden.
  
  Samba ist aber für unser "Projekt IPv6" das geringste Problem, da man es eh nur lokal oder durch ein VPN hindurch verwendet (bzw. verwenden sollte) und innerhalb des Heimnetzes hat man ja selbst bei einem DS-lite-Anschluß immer noch lokale IPv4-Adressen.
  Deshalb werde ich hier nicht weiter auf Samba über IPv6 eingehen.
• File Transfer Protocol - ftp
  Als FTP-Server auf den meisten E2-Boxen dient vsftpd, der "Very Secure File Transfer Protocol Daemon".
  
  vsftp kann von Haus aus den Dual-Stack-Betrieb unterstützen, d.h. IPv4 und IPv6 gleichzeitig. Hierzu ist nur eine klitzekleine Änderung an einer Konfigurationsdatei notwendig.
  
  
  Spoiler

  Je nach verwendetem Image wird vsftpd entweder beim Start als Daemon geladen und bleibt dann im Speicher, oder vsftpd wird über den inetd nur bei Bedarf (= Zugriff) geladen. Nach diesem Betriebsmodus richtet es sich, wo eine Änderung vorzunehmen ist.
  

  • Fall 1 - vsftpd wird über inetd gestartet (z.B. OpenPLi 4.0)
    
    In diesem Fall befindet sich in der Datei /etc/inetd.conf eine Zeile mit etwa folgendem Inhalt:
    

    ftp     stream  tcp    nowait  root    /usr/sbin/vsftpd    vsftpd

    
    Diese Zeile sagt dem inetd, daß er bei Zugriff auf Port 21 (ftp) tcp von außen das Programm /usr/sbin/vsftpd für die Bearbeitung dieses Zugriffs nutzen soll.
    
    Hier ist lediglich das "tcp" in "tcp6" zu ändern, so daß diese Zeile danach so aussieht:
    

    ftp     stream  tcp6    nowait  root    /usr/sbin/vsftpd    vsftpd

    
    Nach dieser Änderung kann man sich über ftp sowohl per IPv6 als auch per IPv4 verbinden, da ein IPv6-Socket standardmäßig auch abwärtskompatibel zu IPv4 ist.
  • Fall 2 - vsftpd läuft als eigener Daemon
    In diesem Fall befindet sich in der Datei /etc/vsftpd.conf folgende Zeile:
    

    listen=YES

    
    Diese sagt dem vsftpd, daß er nach dem Start als eigenständiger Daemon laufen und per IPv4 auf eingehende Verbindungen lauschen ("listen") soll.
    
    Ändert man diese Zeile um in
    

    listen_ipv6=YES

    dann läuft vsftpd ebenfalls als Daemon und lauscht auf einem IPv6-Socket auf eingehende Verbindungen. Da IPv6-Sockets unter Linux standardmäßig auch abwärtskompatibel zu IPv4 sind, kann man sich nun sowohl per IPv6 als auch per IPv4 mit dem ftp-Server der Box verbinden.
    
    Achtung: Die Groß-/Kleinschreibung des Parameters "listen_ipv6" ist wichtig. "listen_IPv6" funktioniert nicht!
  Für den FTP-Server gilt jedoch, wie schon für Samba, daß der IPv6-Support weitgehend irrelevant ist, denn das "secure" im Namen des Servers bezieht sich nicht auf ftp an sich, denn das ist grottenunsicher, sondern nur auf den vsftp-Daemon selber. Ins Internet freigegeben gehört ein FTP-Server nicht.
  
  Man kann vsftpd durchaus sicher konfigurieren, also so daß er SSL benutzt, man riskiert hierdurch jedoch die Möglichkeit des Receivers zur Zusammenarbeit mit bestimmten Tools für den PC, die über FTP mit dem Receiver Daten austauschen (z.B. Bouquet Editor Suite).
  
  Eine in jeder Hinsicht bessere Alternative stelle ich im nächsten Abschnitt vor.
• Secure FTP/Secure Copy/ssh
  Auf nahezu allen E2-Boxen ist bereits ein ssh-Server vorhanden oder es läßt sich einer über die Paketverwaltung nachinstallieren.
  
  Der ssh-Server "OpenSSH" kann nun aber nicht nur als sichere Alternative zu Telnet fungieren, sondern er kann noch weit mehr, nämlich das ältere "Secure Copy/scp" und das aktuelle "Secure FTP/sftp bzw. ftpes" anbieten.
  Wenn die Freigabe der Dateien auf dem Receivers über das öffentliche Netz erforderlich/gewünscht ist, dann ist ein OpenSSH-Server hierzu das Mittel der Wahl. Im Idealfall ergänzt man im Nachhinein auch noch die Konfiguration des ssh-Servers so, daß ein Login mit Passwort nicht mehr möglich ist, sondern eigene Zertifikate benutzt werden, dann ist diese Freigabe nicht nur komfortabel sondern auch sehr sicher möglich.
  
  Kommen wir zuerst einmal zur Einrichtung des OpenSSH-Servers.
  Diese führt man im Idealfall per Telnet durch, da der ssh-Server ja ggf. noch gar nicht existiert oder im Verlauf ausgetauscht werden wird.
  
  Hierzu geben wir erst einmal auf der Box
  

  opkg list_installed *ssh*

  sowie
  

  opkg list_installed *dropbear*

  ein, um herauszufinden, ob bereits ein ssh-Server installiert wurde und wenn ja welcher.
  
  Dies wären - am Beispiel von OpenPLi 4.0 - die Minimalvoraussetzungen für den Zugang per ssh und Dateitransfers über sftp:
  

  root@ultimo:~# opkg list_installed *ssh*
  openssh-keygen - 6.4p1-r0
  openssh-sftp-server - 6.4p1-r0
  openssh-sshd - 6.4p1-r0
  root@ultimo:~#
  root@ultimo:~# opkg list_installed *dropbear*
  root@ultimo:~#

  
  Wird hierbei ein installiertes Paket "dropbear" gefunden, so haltet nun bitte für einen Moment im Hinterkopf, daß es ggf. vor der Installation von OpenSSH deinstalliert werden muß.
  
  Sollten in der Ausgabe weder der openssh-sshd noch der openssh-sftp-server aufgelistet sein, so kann man ihn mit dem Befehl
  

  opkg list *ssh*

  suchen.
  
  Diese Liste kann etwas länger ausfallen, z.B. so:
  
  Spoiler

  root@ultimo:~# opkg list *ssh*
  autossh - 1.4c-r0 - autossh version 1.4c-r0  autossh
  autossh-dev - 1.4c-r0 - autossh version 1.4c-r0 - Development files  autossh  This package
   contains symbolic links, header files, and related   items necessary for
   software development.
  openssh - 6.4p1-r0 - Secure rlogin/rsh/rcp/telnet replacement  Secure rlogin/rsh/rcp/telnet
   replacement (OpenSSH) Ssh (Secure Shell) is   a program for logging into
   a remote machine and for executing commands on   a remote machine.
  openssh-dev - 6.4p1-r0 - Secure rlogin/rsh/rcp/telnet replacement - Development files  Secure
   rlogin/rsh/rcp/telnet replacement (OpenSSH) Ssh (Secure Shell) is   a
   program for logging into a remote machine and for executing commands on
   a remote machine.  This package contains symbolic links, header files,
   and related items necessary for software development.
  openssh-keygen - 6.4p1-r0 - Secure rlogin/rsh/rcp/telnet replacement  Secure rlogin/rsh/rcp/telnet
   replacement (OpenSSH) Ssh (Secure Shell) is   a program for logging into
   a remote machine and for executing commands on   a remote machine.
  openssh-misc - 6.4p1-r0 - Secure rlogin/rsh/rcp/telnet replacement  Secure rlogin/rsh/rcp/telnet
   replacement (OpenSSH) Ssh (Secure Shell) is   a program for logging into
   a remote machine and for executing commands on   a remote machine.
  openssh-scp - 6.4p1-r0 - Secure rlogin/rsh/rcp/telnet replacement  Secure rlogin/rsh/rcp/telnet
   replacement (OpenSSH) Ssh (Secure Shell) is   a program for logging into
   a remote machine and for executing commands on   a remote machine.
  openssh-sftp - 6.4p1-r0 - Secure rlogin/rsh/rcp/telnet replacement  Secure rlogin/rsh/rcp/telnet
   replacement (OpenSSH) Ssh (Secure Shell) is   a program for logging into
   a remote machine and for executing commands on   a remote machine.
  openssh-sftp-server - 6.4p1-r0 - Secure rlogin/rsh/rcp/telnet replacement  Secure rlogin/rsh/rcp/telnet
   replacement (OpenSSH) Ssh (Secure Shell) is   a program for logging into
   a remote machine and for executing commands on   a remote machine.
  openssh-ssh - 6.4p1-r0 - Secure rlogin/rsh/rcp/telnet replacement  Secure rlogin/rsh/rcp/telnet
   replacement (OpenSSH) Ssh (Secure Shell) is   a program for logging into
   a remote machine and for executing commands on   a remote machine.
  openssh-sshd - 6.4p1-r0 - Secure rlogin/rsh/rcp/telnet replacement  Secure rlogin/rsh/rcp/telnet
   replacement (OpenSSH) Ssh (Secure Shell) is   a program for logging into
   a remote machine and for executing commands on   a remote machine.
  sshpass - 1.05-r0 - sshpass version 1.05-r0  sshpass
  sshpass-dev - 1.05-r0 - sshpass version 1.05-r0 - Development files  sshpass  This package
   contains symbolic links, header files, and related   items necessary for
   software development.
  root@ultimo:~#

  
  Was wir hierbei suchen sind der eigentliche OpenSSH-Server und ggf. - sofern getrennt "abgepackt" - dessen sftp-Server-Funktionalität.
  Die richtigen Pakete sollten also "openssh-sshd" (d für Daemon, also Server) oder "openssh-server" für den OpenSSH-Server und
  "openssh-sftp-server" oder "openssh-sftpd" o.ä. heißen.
  
  Sobald die richtigen Pakete identifiziert sind, müßt Ihr nun zuerst einmal einen ggf. installierten dropbear deinstallieren, dies erfolgt durch Eingabe von
  

  opkg remove dropbear

  wobei Ihr "dropbear" ggf. durch den zu Beginn gefundenen Paketnamen von dropbear ersetzen müßt.
  
  Die Installation von OpenSSH erfolgt dann mittels
  

  opkg install openssh-sshd openssh-sftp-server

  wobei openssh-sshd und openssh-sftp-server natürlich noch durch die Paketnamen zu ersetzen sind, die Ihr auf Eurer Box gefunden habt.
  
  Spätestens nach einem Neustart der Box sollte diese nun per ssh (z.B. mit
  Sie müssen registriert sein, um Links zu sehen.
  oder
  Sie müssen registriert sein, um Links zu sehen.
  ) erreichbar sein.
  Sofern Ihr das Standard-Passwort der Box in ein anständiges Passwort (Kein Begriff aus einem Wörterbuch/Namensbuch, Groß+Kleinbuchstaben, Zahlen und Zeichen wie Klammern u.ä.) geändert habt, kann dieser Zugang auch verhältnismäßig sicher (Absolute Sicherheit gibt es nicht) nach außen geöffnet werden.
  
  Das besondere ist nun, daß derselbe Zugang zugleich auch für den Zugriff über jeden besseren FTP-Client (z.B.
  Sie müssen registriert sein, um Links zu sehen.
  ,
  Sie müssen registriert sein, um Links zu sehen.
  ,
  Sie müssen registriert sein, um Links zu sehen.
  u.v.m.) genutzt werden kann und zwar sowohl per IPv4 als auch per IPv6!

 

[Schimmelreiter]

AW: E2-Receiver mit IPv6 nutzen (Dual Stack und DS-lite) - incl. CS

Schritt 2: Box für IPv6 einrichten

Teil 4: Virtuelles Privates Netzwerk (VPN)

Ein VPN mit IPv4-Payload zwischen zwei Boxen ermöglicht es beiden Seiten, alle anderen Dienste und Funktionen (Samba, CS, ftp, ...) der beteiligten Boxen weiterhin über IPv4 zu betreiben!
Daraus folgt, daß man allein über das VPN gleichzeitig alle anderen Probleme durch fehlenden IPv6-Support erschlagen kann, selbst wenn wirklich nur das VPN auf IPv6 umgestellt wurde!

Wie bei den meisten vorangegangenen Punkten bekommt man aber auch hier als Benutzer von den Image-Erstellern grundlos Knüppel zwischen die Beine geworfen:
Die meisten Images enthalten eine völlig antiquierte Version von OpenVPN <2.3.0.
Es wird aber mindestens OpenVPN 2.3.0 benötigt, um VPN-Verbindungen über IPv6 aufbauen zu können (Das ist der wichtigste Teil) oder IPv6-Traffic über den Tunnel transportieren zu können (Das wäre die Kür).

Aus diesem Grunde habe ich Euch einen OpenVPN 2.3.2 für MIPS-Boxen (Vu+, X-Trend, Dream Multimedia) kompiliert, der zumindest unter OpenPLi 4.0 als direktes Drop-In-Replacement für die veraltete Version verwendet werden kann. Den Download findet Ihr Link ist nicht mehr aktiv..

Leider bin ich momentan (noch) nicht in der Lage, Euch OpenVPN auch für andere Architekturen (sh4, ppc, ...) anzubieten, erster Ansprechpartner ist aber sowieso immer das Team, welches das Image erstellt. Es bringt viel mehr, wenn die Images out-of-the-box ordentlich funktionieren, als wenn diese erst im Nachhinein vom Benutzer repariert werden müssen.

Zur Vereinfachung berücksichtige ich in der folgenden Anleitung IPv6 nur als Trägernetz, denn das ist das, was die meisten von Euch interessieren wird:
Nur durch IPv6-Support im OpenVPN-Server und Client kann ein Server auch dann noch sauber erreicht werden, wenn der Anschluß auf dem er läuft nur über eine DS-lite-Anbindung verfügt.
und
IPv6 für das VPN-Trägernetz genügt, um eine VPN-Verbindung zu einem Server hinter DS-lite aufzubauen und danach alles weitere notfalls weiterhin per IPv4 durch den Tunnel hindurch zu realisieren.


OpenVPN IPv6-tauglich machen

1. Prüfen, ob ein veralteter OpenVPN installiert ist und diesen ggf. entfernen
   Hierzu geben wir erst einmal auf der Box
   

   opkg list_installed *openvpn*

   ein.
   
   Sieht das Ergebnis so aus:
   

   Topf:~# opkg list_installed *openvpn*
   Topf:~#

   dann ist kein OpenVPN installiert und Ihr könnt direkt zu Schritt 2 springen.
   
   Lautet das Ergebnis hingegen
   

   root@ultimo:~# opkg list_installed *openvpn*
   openvpn - 2.x.y-r0

   ... so ist openvpn bereits installiert.
   
   Es gibt nun zwei Möglichkeiten:
   • Steht dort als Ergebnis eine Versionsnummer >= 2.3.0, so habt Ihr gute Chancen, daß dieser IPv6-tauglich ist.
     
     Dies könnt Ihr so überprüfen:
     

     openvpn --version

     
     Direkt in der ersten Zeile findet Ihr die Angabe, ob der IPv6-Support mit eingebaut wurde:
     

     OpenVPN 2.3.2 mipsel-oe-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Mar 17 2014

     
     Wenn das der Fall ist, könnt Ihr zu Schritt 3 übergeben.
   • Habt Ihr hingegen eine Version < 2.3.0, dann ist der vorhandene openvpn höchstwahrscheinlich unbrauchbar.
     Sofern Ihr ein Paket (ipk) mit einem für Eure Box verwendbaren openvpn habt, dann könnt Ihr den veralteten openvpn nun mit folgendem Befehl deinstallieren ...
     

     root@ultimo:~# opkg remove openvpn

     wobei "openvpn" durch den vorgefundenen Namen des installierten openvpn zu ersetzen ist.
     Danach könnt Ihr mit Schritt 2 fortfahren.
2. Aktuellen OpenVPN installieren
   Zuerst einmal sollte geprüft werden, ob sich nicht zwischenzeitlich im Feed für das verwendete Image ein aktualisierter OpenVPN findet.
   
   Dazu dienen die folgenden Befehle:
   

   opkg update
   opkg list *openvpn*

   
   Befindet sich openvpn 2.3.0 oder höher im Feed des Images, so kann dieser nun mittels
   

   opkg install openvpn

   installiert werden.
   
   Danach solltet Ihr noch - wie unter Schritt 1 beschrieben - mittels
   

   openvpn --version

   überprüfen, ob wirklich IPv6-Support eingebaut wurde.
   
   Wenn ja, könnt Ihr nun mit Schritt 3 weitermachen.
   
   Fehlt der IPv6-Support, könnt Ihr den alten openvpn direkt wieder mit
   

   opkg remove openvpn

   deinstallieren.
   
   Wenn Ihr ein ipk mit einem aktuellen OpenVPN habt, z.B. aus meinem Download (s.o.), so solltet Ihr dieses spätestens jetzt auf die Box kopieren (Mein zip bitte vorher auspacken!).
   
   Unter der Annahme, daß Ihr das .ipk auf der Box in /hdd/movie gespeichert habt, kann es nun mit
   

   opkg install /hdd/movie/openvpn_2.3.2-r0_mips32el.ipk

   installiert werden.
   Dabei openvpn_2.3.2-r0_mips32el.ipk natürlich durch den tatsächlichen Namen des Paketes ersetzen, wenn Ihr nicht meinen Download sondern eine andere Quelle verwendet.
   
   Die korrekte Installation kann nun mittels
   

   openvpn --version

   überprüft werden.
   
   Das Ergebnis sieht für meine Version so aus:
   
   Spoiler

   root@ultimo:/etc/openvpn# openvpn --version
   OpenVPN 2.3.2 mipsel-oe-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Mar 17 2014
   Originally developed by James Yonan
   Copyright (C) 2002-2010 OpenVPN Technologies, Inc. <sales@openvpn.net>
   Compile time defines: enable_crypto=yes enable_debug=yes enable_def_auth=yes enable_dependency_tracking=no enable_dlopen=unknown enable_dlopen_self=unknown enable_dlopen_self_static=unknown enable_eurephia=yes enable_fast_install=yes enable_fragment=yes enable_http_proxy=yes enable_iproute2=no enable_libtool_lock=yes enable_lzo=yes enable_lzo_stub=no enable_management=yes enable_multi=yes enable_multihome=yes enable_pam_dlopen=no enable_password_save=yes enable_pedantic=no enable_pf=yes enable_pkcs11=no enable_plugin_auth_pam=no enable_plugin_down_root=no enable_plugins=no enable_port_share=yes enable_selinux=no enable_server=yes enable_shared=yes enable_shared_with_static_runtimes=no enable_silent_rules=no enable_small=no enable_socks=yes enable_ssl=yes enable_static=yes enable_strict=no enable_strict_options=no enable_systemd=no enable_win32_dll=yes enable_x509_alt_username=no with_crypto_library=openssl with_gnu_ld=yes with_libtool_sysroot=no with_mem_check=no with_plugindir=no

   
   Danach weiter mit Schritt 3.
3. OpenVPN konfigurieren
   
   Dies wäre eigentlich der einzig notwendige Schritt, wenn Image-Ersteller nicht der falschen Regel "never change a broken system" folgen würden.
   • Server
     Für jeden Server auf einem IPv6-tauglichen System sollte jedes Vorkommen von tcp bzw. udp in der Konfigurationsdatei durch tcp6 bzw. udp6 ersetzt werden.
     
     Beispiel:
     
     Aus
     

     dev tun
     ifconfig 10.8.0.1 10.8.0.2
     secret /tmp/flash/openvpn/static.key
     keepalive 10 60
     comp-lzo
     ping-timer-rem
     persist-tun
     persist-key
     port 1194
     [COLOR="#FF0000"]proto tcp-server[/COLOR]

     wird
     

     dev tun
     ifconfig 10.8.0.1 10.8.0.2
     secret /tmp/flash/openvpn/static.key
     keepalive 10 60
     comp-lzo
     ping-timer-rem
     persist-tun
     persist-key
     port 1194
     [COLOR="#008000"]proto tcp6-server[/COLOR]

     
     Für alle anderen Vorkommen von udp bzw. tcp gilt das selbe:
     proto udp -> proto udp6
     etc. pp.
     
     Fertig ist ein OpenVPN-Server, der eingehende Verbindungen sowohl per IPv6 als auch per IPv4 annimmt!
     
     Für Server hinter DS-lite-Anschlüssen ist dies also ein Muß, da sie über IPv4 eh nicht erreicht werden können!
     
     Aber auch für alle anderen Server (Entsprechende IPv6-Eignung des Anschlusses und Betriebssystems vorausgesetzt) ist es absolut problemlos, diese Änderung ebenfalls durchzuführen:
     IPv4-only-Clients können sich trotzdem problemlos über IPv4 verbinden, zusätzlich aber auch noch die IPv6-Clients ...
   • Client
     
     Analog zum Server ist einfach nur "udp" bzw. "tcp" durch "udp6" und "tcp6" zu ersetzen.
     
     Hierbei ist aber vorher zu prüfen, ob der Server bereits auf IPv6-Support umgestellt wurde, denn ein Client mit der Einstellung
     

     proto tcp6-client

     kann sich nicht mit einem Server verbinden, der mit "proto tcp-server" (ohne "6") eingerichtet wurde.