LTE-Sticks mit Hybrid SIM

      @hefr54: Du darfst nicht immer soviel darauf geben, was die Telekom sagt...
      wenn sich der Stick einbucht - ist zumindest LTE-Only-Betrieb greifbar ;)

      Und was genau meinst Du denn mit Bonding-Logik?
      Das wissen wir doch längst?
      -- 2 GRE-Tunnel
      -- Überlauf von DSL- auf LTE-Tunnel an SOAP-Grenze per Netfilter in Senderichtung
      -- Kombination der Tunnel durch gleiche IP in Empfangsrichtung

      Sollte eine Art Authentifizierung am HAAP notwendig sein, so kann man das am SPH mitlesen -- aber das hat ja mit Bonding nix zu tun.

      Das Schöne: das Ganze ist auf dumme Clients optimiert - der HAAP macht alles Kompliziertere, der SPH handelt nach Anweisung/Schema-F...

      Ich bleib dabei: die Datenverbindung ist das Wichtigste ;)

      mfg, emkay

      EDIT:
      Einwahl per NDISDUP/NDISCONN ohne Einbuchung --> nicht erfolgt.
      Einwahl per ATD ohne Einbuchung --> CONNECT 150000000
      --> was eigentlich bedeuten müsste, das es geklappt hat, aber ohne Einbuchung ja nich klappen sollte... (irgendwann evtl. doch mal nen neuen Stick besorgen - vielleicht gibt's da neue Modi, die meiner nich kennt...)

      Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „eMKay77“ ()

      @hefr54: unbekannte Modi sind keineswegs unlogisch - schließlich bedeutet gleiche Hardware-Basis nicht gleiche Firmware... ;)
      (ganz dumm wäre, wenn es einer 'speziellen', evtl. bewusst inkompatiblen Firmware bedarf - also normale Firmware bewusst ausgeschlossen wird)

      Und die Huawei-Sticks beherrschen je nach Generation, Firmware und Portkonfiguration unterschiedliche Schnittstellen und Kommandos...

      Dazu kommt, daß es offensichtlich noch Updates für das SPH-LTE-Modul gibt - aber trotzdem nicht für den e3276... (man könnt' ja jetzt versuchen, die des SPHs zu portieren... ;) )
      -- Unterschiede sieht man ja zB. schon bei ^syscfgex: der SPH kennt einen 'Roaming-Only-Mode', aber der e3276 nicht.

      Was mich immer noch etwas verwundert: der Stick wird scheinbar nicht vom Netz abgewiesen - er übergeht es einfach und sucht weiter...
      Es gibt also keine Meldung darüber, das das Einbuchen verweigert wurde o.Ä...
      (der Stick bleibt im 'nicht eingebucht aber suchend'-Modus)

      Der Stick zieht das Netz aus irgendeinem Grund gar nicht in Betracht - nutzt Hybrid da eventuell abweichende Parameter (Kennung / Modulation) - so daß man eine gepatchte LTE-Firmware bräuchte?
      (im Grunde würde schon eine kleine - evtl. bewusste - Abweichung reichen und 'normale' Sticks würden einen Bogen um das Netz machen...)

      mfg, emkay

      EDIT: Ich hab' ja momentan e3276 mit 21.436.03.00.00 -- neuere Non-HiLink konnt ich nicht finden. Neuere HiLink (und 'nen Weg das Update unter Linux zu machen) leider auch noch nicht. Übrigens sollte man auch bei ner HiLink-Version per AT^SETPORT einen passenden Modus für AT-Befehle setzen können...

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

      xdjbx schrieb:

      Nutzt du hiStudio ?
      Nöö - zuerst hab' ich noch screen benutzt, aber da das nicht auf der NDIS/CDC-WDM-Schnittstelle funktioniert, nehme ich nun 2 Terminals:
      -- im ersten läuft einfach 'cat /dev/cdc-wdm0'
      -- im zweiten schick ich die Befehle per Script

      Shell-Script

      1. #!/bin/sh
      3. printf "$*\r" > /dev/cdc-wdm0
      4. printf "$*\n"
      auf /dev/cdc-wmd0

      Das funktioniert soweit gut... ;)

      Übrigens: wenn ich mir direkt die Zellen anzeigen lasse, sehe ich sehr wohl meine LTE-Zelle als aktuelle und die anderen als überwachte Zellen.... irgendwas ist da seltsam :D

      mfg, emkay

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

      hefr54 schrieb:

      Moin,
      ich habe noch mal überall nachgelesen und bin jetzt zu der Erkenntnis gekommen, entweder jemand kommt an die Daten
      für die "Bonding Logik" oder man kann es vergessen. Ob sich der Stick einbucht oder nicht ist von zweitrangiger Bedeutung.
      Nur mit der Kenntnis der Bonding Logik geht es weiter :D

      Spricht denn etwas dagegen, wenn ich mir auf Basis der Specs eine Alternative aus LTE Modem, DSL und Bonding-Router selbst aufsetzte und betreibe?

      "Die GRE-Schnittstelle zw. Server und Client ist zwar offen gelegt, aber die eigentliche Bonding Logik ist da nicht enthalten."

      Ist eine Veröffentlichung der Schnittstellenbeschreibung angedacht?

      "Drittanbietern liegen alle Informationen vor um Hybrid-fähige Endgeräte zu entwickeln. Eine öffentliche Kommunikation dieser Informationen ist meines Wissens nicht geplant"


      Stammt von hier: telekomhilft.telekom.de/t5/Tel…agen/td-p/1387893/page/66

      Selbst im pfSense Forum winkt man ab ;) Schade eigentlich und an einen HA35-22am kommt man so einfach auch nicht ran.
      Die Kohle hätte ich noch investiert ;)

      Gruß hefr


      Die Bonding-Logik ist vollkommen offen (es gibt ja sogar RFCs dazu!). Da steht bis ins kleinste Detail, wie alles funktioniert.
      Das einzige "grosse Unbekannte" ist es, wie man mit einem LTE-Modem und Hybrid-SIM eine IPv6 bekommt, mit der man auf den HAAP kommt.

      Der Rest ist sicher nicht trivial, aber machbar und es ist bekannt, was gebraucht wird (vermutlich muss man den Kernel bearbeiten, bzw genauer das GRE Modul. Oder einfach das GRE-Modul kopieren und ein "HGRE"-Modul daraus basteln)

      Moin!

      Ich glaub' mittlerweile, daß man im günstigsten Fall einen Stick mit sehr aktueller Firmware braucht - welche man für die Älteren wohl nicht mehr bekommen wird. (eventuell mal mit dem Cat6-Flaggschiff versuchen, wenn's jemand hat)

      Im ungünstigsten Fall braucht man vielleicht eine gepatchte Firmware (auch wenn das eventuell gegen LTE-Specs verstoßen könnte - was aber die Telekom vielleicht nicht stört - wenn's die Bastler aus dem Netz hält ;) )

      Zumindest laut Config ist die erste Verbindung zum APN wohl noch IPv4 - eventuell ist dann im GRE-Tunnel erst IPv6.

      Was Lustiges am Rande: ich bekomme meine Funkzelle mit Status restricted Service, ich bekomme auch RSRP/RSRQ etc., aber jeder Versuch einer Datenverbindung freezed das Interface... dummerweise muß das nicht mal ein Fehler sein, weil bei geglückter Verbindung das Interface ja den Modus switched -- weshalb es gar nicht so einfach ist, den Fehlerfall von einem geglückten Versuch zu unterscheiden ;)
      (allerdings scheint der dhclient auch keine Daten über das Interface senden zu können...)

      Ein strace auf dem SPH ist mir ja nicht möglich - die haben mir jetzt schon das zweite Ticket geschlossen, ohne Austausch-Router...
      (schau mir grad' nebenbei die Unitymedia-Angebote an...)

      mfg, emkay

      genevt schrieb:

      eMKay77 schrieb:

      eventuell ist dann im GRE-Tunnel erst IPv6


      Das kann ich mit 2 bis 3 Beweisen (hier in Kurzform) widerlegen:
      - IP-Adressen der Interfaces
      - Paketmitschnitt auf dem 'lte'-Interface
      - Spezifikation

      - IP-Adressen der Interfaces
      im lte teil des routers (eigene firmware mit eigenen interfaces) kann durchaus eine ipv4 vorhanden sein ohne dass du etwas davon mitbekommst

      - Paketmitschnitt auf dem 'lte'-Interface
      auch hier siehst du nur das was direkt auf dem sph vor sich geht und dort ist nur die ipv6 bekannt
      dennoch kann in der lte firmware der grundlegende aufbau mittels ipv4 passieren

      - Spezifikation
      nur weil diese existiert muss man sich nich an selbige halten ;)

      Moin!

      @hefr54: ohne SIM wird aber wohl nicht zwischen aktueller (^lcellinfo=0) und Nachbar-Zellen (^lcellinfo=1) unterschieden...

      @genevt: ich bin da nach der Config gegangen - und dort steht für den APN nunmal "IPV4" -- was Du auf dem SPH siehst, ist komplett unabhängig vom Netz.
      (ein DSL-Router kann zB. in deinem LAN 'ne IPv6 haben, auch wenn dein ISP nur IPv4 unterstütz...) --> unabhängig davon ist dank @hefr54 jetzt klar, daß der +CDGCONT-Eintrag, welcher im LTE-Modul gespeichert ist, entgegen der Config wirklich als "IPV6" ausgewiesen ist --> und das ist dann wirklich beweiskräftig :D
      (was beim e3276 zum Problem wird, weil nur eine recht alte FW-Version IPv6-fähig sein soll...)

      Zur 'Spezifikation' mal allgemein: das ist ein Internet-Draft mit 6-monatiger Gültigkeit und kein wirklicher Standard -- weshalb man die Zurückhaltung von zB. AVM verstehen kann... (kann sich täglich ändern - und bei Hybrid ändert sich ja auch dauernd was)

      Allerdings gibt's 'nen neuen Ansatz dank @hefr54 : es gibt wirklich Gemeinsamkeiten aller SPHs(bzw. LTE-Module), nämlich die Seriennummer - eventuell kann ich die aber ähnlich der IMEI anpassen - einen Versuch ist es wert ;)

      mfg, emkay

      @Stricted: da hast Du halb Recht ;)

      In meiner Werksreset-Config steht's so wie bei Dir - in meiner Config-In-Use steht:

      Quellcode

      1. <APNProfile NumberOfInstances="1">
      2. <APNProfileInstance InstanceID="1" Enable="1" Description="test" APNname="hybrid.telekom" DialNumber="*99#" Username="telekom" Password="telekom" AuthenticationProtocol="PAP" ReadOnly="1" IPv4Enable="1" IPv6Enable="1"/>
      3. </APNProfile>
      --> also mit aktiviertem IPv4...
      Aber wie gesagt, @hefr54 hat ja den Eintrag aus dem LTE-Modul ausgelesen -- und der ist IPv6-Pur.

      mfg, emkay

      @Doridian: wenn ich recht erinner, gibt's bei den Sticks als Kennung:
      "IP", "IPV4", "IPV4V6", "PPP", "X25"...
      Aber fast immer scheint einfach "IP" benutzt zu werden - und das ist auch die einzige Kennung, welche mein e3276 momentan zu kennen scheint.
      (wie gesagt - es soll eine ältere, weniger beschnittene Firmware geben )
      - kann aber natürlich sein, das die Unterscheidung aus dem Befehl gekürzt wurde und nicht mehr nötig ist. (außerdem kennt der 3276 noch 1-2 weitere Kommandos, um Verbindungen aufzubauen - mit teils anderen Variablen)

      Aber eins nach dem anderen: erstmal echtes Einbuchen - dann seh' ich weiter...

      mfg, emkay