LTE-Sticks mit Hybrid SIM

      Nur mal ne Anmerkung, ne kleine, ich sitze z.b. seit ca 2 -3 Monaten dran um CWE Mode für NDS Karten in oscam zu bekommen (damit kann man mit gepairten Karten TV gucken - mit offiziellen abo)
      nur durch Änderung seitens cisco muss man teilweise immer wieder von fast 0 Beginnen, ich hätte das auch gern lieber schneller, aber es ist nunmal so das man viel viel Geduld brauch,
      manchmal auch paar Tage Pause, weil man halt Abstand und neue Umsetz ideen etc.
      Irgendwann klappts aber ....

      In der Ruhe liegt die Kraft

      hefr54 schrieb:

      Es könnte mit etwas Glück und ein bisschen umherschrauben sogar die "hybrid" vom SPH reinpassen.
      Mal sehen ob es klappt

      habe mir den router mal eben angeschaut,
      mit pech wird daraus nichts, der router besitzt 2 SoC's einen ​ARM® Cortex™-A9(BCM4709) und einen mit mips architektur (BCM63168)
      wenn der linux teil nun auf dem ARM läuft kannst du es vergessen
      Hallo zusammen,

      ich habe vor einigen Tagen angefangen mich mit dem Thema "Telekom Hybrid" zu beschäftigen. Mein Ziel ist es, so geht es denke ich mal den meisten hier, eine Alternative zum SPH zu haben, am besten mit OpenWRT o.ä.. Ich habe mich schon durch die meisten der 35 Seiten durchgewühlt, trotzdem fällt es mir gerade etwas schwer alle Zusammenhänge und bisherige Erkenntnisse zu erfassen. Vielleicht wäre es möglich eine Zusammenfassung zum Aufbau der LTE Verbindung beim SPH zu schreiben, damit Neueinsteiger, wie ich eine Basis haben, auf der sie mitarbeiten können. Oder gibt es soetwas vllt. sogar schon? (Ich habe sowas zumindest nicht gefunden)

      Danke und Gruß
      lal12
      Da das Python script von Schnup89 bei mir nicht so ganz wollte, habe ich mal ein kleines C Programm geschrieben, welches den GRE Setup Request rausschickt.
      Es sendet eigentlich genau das gleiche Paket raus wie Schnupes script, der einzige Unterschied ist, dass bei mir eine SourceMAC drin steht, denke aber nicht dass das der Grund ist.
      Ich benutze allerdings auch keinen LTE Stick, (der ist noch auf dem Versandweg) sondern ein altes Smartphone (Ascend P7), möglicherweise liegt hier das Problem.

      Wäre von euch einer so freundlich mein Prog mal bei sich zu testen? Da es bisher noch nicht auf eine Antwort wartet muss man manuell in Wireshark/tcpdump etc. schauen ob eines ankommt. Es muss als root ausgeführt werden und als erster Parameter muss das Interface angegeben werden, z.B.

      Quellcode

      1. sudo ./greReq wwan0
      .

      Kompiliert wird es mit

      Quellcode

      1. g++ GRE_Req.cpp -o greReq
      . Es gibt keine Abhängigkeiten alles POSIX bzw. Linux.

      Die angehängte Datei ist der Quellcode, müsst ihr umbenennen in .cpp (das lässt er mich aber nicht hochladen).
      Dateien
      • GRE_Req.txt

        (3,16 kB, 265 mal heruntergeladen, zuletzt: )

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „lal12“ ()

      Habe ein paar kleine Änderungen gemacht, sollte jetzt kompilieren. Wundert mich gerade, dass es überhaupt kompiliert, hatte einen Header nicht eingebunden.

      genevt schrieb:

      @lal12 willst du wirklich IPV6-Header selber schreiben, what could possibly go wrong

      Soweit ich das gerade im Kopf habe gibt es keine andere Möglichkeit, als den IPv6 Header selber zu schreiben. Bei IPv4 gibt es eine socket option, die sich setzen lässt, um den Header vom Kernel schreiben zu lassen. Soweit ich weiß funktioniert die aber bei IPv6 nicht, ist leider ohnehin teils etwas mangelhaft dokumentiert, die ganze API für IPv6.
      Dateien
      • GRE_Req.txt

        (3,17 kB, 247 mal heruntergeladen, zuletzt: )

      genevt schrieb:

      Wie sieht denn der Dump aus?

      Hatte ich eben überlesen, meinst du den Wireshark Capture? Hänge einen Mitschnitt an. Ein Paket ist mit SrcIP, eines ohne (wie beim python script).

      hefr54 schrieb:

      :thumbsup:

      Könntest du die Aussage etwas spezifizieren? :D
      Heißt das es kompiliert? Dass der HAAP eine Antwort schickt? ...
      Dateien
      • capture.pcapng

        (484 Byte, 229 mal heruntergeladen, zuletzt: )
      Ja, die "Wireshark-Datei", meinte ich.
      Da sehe ich nämlich das Problem: Du verwendest die linklokale Adresse. Hast du überhaupt eine richtige IPv6-Adresse bei Verwendung des Handies als Modem?

      PS: Mein Firefox sieht dieses Textfeld nicht als Textfeld an, dadurch stehen viele Features für die Textbearbeitung nicht zur Verfügung, ich habe nicht mal einen Cursor. @Stricted solltest du etwas geändert haben, bitte zurück ändern.
      Ok, vllt sollte ich mich im Bereich IPv6 doch mal fortbilden ^^. Ich dachte link local Adressen sind auch die öffentlichen bei IPv6, deswegen ja die Datenschutz Problematik bei v6.
      Sowas hatte ich auch überlegt, dass ich nicht direkt das LTE Interface bekomme, sondern irgend ein virtuelles im Handy.
      Also das Handy meldet gerade: fe80::fa01:13ff:fe35:d327.
      Moin @hefr54

      hefr54 schrieb:

      nachdem ich mal jedes Binäry aus /bin des SPH lesbar
      gemacht habe sind da ziemlich viele Verbindungen von dem "hybrid" zu Anderen wie "cms", "dhcp6c" usw.
      aufgefallen
      Die Verbindungen sind einfach zu erklären: cms ist sowas, wie der Master-Controller im SPH - der ist zu fast allem Verbunden.
      Und der hybrid-Prozeß muß ja den dhcp6c für die GRE-Interfaces starten - also auch nicht verwunderlich.

      Also cms startet hybrid (und auch sonst fast alles im SPH) - hybrid startet dhcp6c (aber auch 'ip' oder 'xdslcmd')... da der SPH ein geschlossenes System ist, haben die sich gespart, das über Interfaces zu machen und es einfach hardcoded im Quellcode hinterlegt --> das kann man selbst aber ruhig anders/sauberer lösen -- nichts zwingt mich, alles genauso zu machen, wie der SPH :D
      (zb. in dem man per Config-Datei die Pfade zu unumgänglichen Tools setzt, welche der Client benötigt...)

      Ich richte mich nicht nach dem SPH - ich richte mich danach, welche Funktionalität und Informationen notwendig sind um das Protokoll umzusetzen...

      Zum Beispiel nutzt der hybrid-Prozeß des SPHs direkt xdslcmd um an die DSL-Informationen zu kommen - für einen allgemeinen Client macht das keinen Sinn, weil xdslcmd ja nicht immer vorhanden ist. Deshalb werde ich das wohl über ein Interface-Script lösen, das man per Config setzen kann. Dem Client kann dann egal sein, wie das Script die Sync-Werte ermittelt (welches Tool es dafür aufruft oder ob es einfach fixierte Werte liefert ;) ) --> Hauptsache, es liefert die Sync-Werte.
      Und für eine andere Plattform passt man dann nur das Script an - nicht den Client :D

      hefr54 schrieb:

      inzwischen hat die "T" aus allen aktuellen FW's "telnet" und "cli" entfernt
      das ist nicht verwunderlich - alle Huawei-Speedports basieren auf dem selben Betriebssystem, solche Änderungen werden Upstream gemacht -- und treffen dann alle davon abgeleiteten Geräte...

      mfg, emkay

      hefr54 schrieb:

      Diese Antwort habe ich im vorstehenden Beitrag nicht gefunden oder habe ich was übersehen?
      Das Problem ist, daß ich aus Deinen Fragen manchmal einfach nich wirklich schlau werde...
      Der Client setzt zwei bereits initialisierte/funktionierende/verbundene Netzwerkinterfaces vorraus.
      Beim Asus wären das zB. das interne VDSL und ein externes LTE-Device.
      Für den logischen Ablauf empfehle ich den Draft + Google-Translate :D

      Oder stell eben verständliche direkte Fragen - dann kann man eventuell auch direkt antworten... ;)

      hefr54 schrieb:

      na nicht ganz....
      Falsches Ergebnis aus falschen Daten abgeleitet...
      Natürlich nutzen Router-Hersteller eigene (meist BusyBox-basierte) linuxoide Betriebssysteme (bis auf wenige Ausnahmen - zB. Arcadyan) --> es wäre etwas umständlich, für jedes Gerät von vorn anzufangen... :D
      Das ist mit ein Grund, warum Bugfixes oft lang dauern - man schaut erstmal, ob es ein Fehler des einzelnen Geräts ist, oder ein Upstream-Fehler, der das Grundsystem betrifft --> in letzterem Fall muß der Fehler upstream behoben werden - inkl. Beta-Test bei allen davon abgeleiteten Systemen/Devices...
      (also auf gut Deutsch: ein SPH-Fehler könnte ein HUAWEI-Speedport-Fehler sein, müsste dann oben behoben werden - mit Beta-Tests bei allen HUAWEI-basierten Speedports)

      mfg, emkay

      hefr54 schrieb:

      Eigentlich wollte ich nur wissen auf welcher Hardware der Client laufen soll
      Naja - exakt diese Frage hatte ich Dir schon an anderer Stelle direkt beantwortet...
      Und auch hier hatte ich das meines Wissens schon erwähnt.

      -- direkte Ziel-Plattform ist Asus DSL-AC87VG + Netgear LB111x (jeweils Stock-Firmware, Client-Integration per USB)
      -- Huawei E3276 mit IPv6 fähiger Firmware statt LB111x werde ich wohl zusätzlich testen, weil er halt hier rumliegt...
      -- Portierung auf andere linuxoide posix-kompatible Systeme sollte trivial sein
      -- der Client soll hardware-agnostisch sein - andere xDSL-/LTE-Hardware funktioniert, solange sie ein normales Netzwerk-Interface zur Verfügung stellt.
      (der Client selbst soll sich nicht um die einzelnen Verbindungen kümmern - nur um das Bonding)
      --> für den Asus soll das auf einen fertig präparierten USB-Stick hinauslaufen - einstecken und fertig.

      mfg, emkay