LTE-Sticks mit Hybrid SIM

      @genevt: joa - Du holst Dir also die Parameter für den Tunnelaufbau über den Tunnel, für dessen Aufbau Du die Parameter brauchst... ;)

      Und nein, wenn Du einen IP-Raw-Socket hast, mußt Du den GRE-Header selbst bauen (vorallem, wenn wie hier, ein eigener GRE-Header notwendig ist, weil Huawei einen neuen GRE-Message-Type einführt) und wenn Du einen Interface-Raw-Socket nimmst, müsstest Du zusätzlich auch 'nen IP-Header bauen - das fertige Paket muß ja nicht nur auf's Interface, sondern seinen Weg zum HAAP finden...

      mfg, emkay

      @hefr54 ...wenn Du im Router das GRE2 anschaust, hat es nur eine IPv6 Adresse. Ergo werden die Pakete über IPv6 zum HAAP transportiert. Das am Ende auf beiden Seiten auch ein IPv4/IPv6 Interface existiert, ist klar, da ja Dual-Stack zum Einsatz kommt. Aber als Transport-Protokoll für die GRE-Pakete kommt offensichtlich ausschliesslich IPv6 zum Einsatz.

      Das etablieren der Transport-Tunnel wird offensichtlich nicht mit dokumentiert, sondern erst das Zuweisen des Dual-Stack-Internfaces auf Router-Seite.

      Grüße

      danXde

      hefr54 schrieb:

      beiden IPV6- Tunnel im IPV4-Tunnel

      Nein, es gibt kein Tunnel in Tunnel (außer man sieht PPP als Tunnel an, dann gibt es das auf DSL). Außen um den Tunnel gibt es auch kein IPv4 (es gibt das Gerücht, man hat bei Hybrid nur die IPv4-Adresse über DSL, da das Telekom VoIP kein v6 kann).

      @eMKay77: Ich mache später mal eine Grafik


      danXde schrieb:

      Das etablieren der Transport-Tunnel wird offensichtlich nicht mit dokumentiert

      Das ist auch nicht notwendig, da GRE sowas nicht kennt, es werden einfach die Pakete eingepackt und verschickt; es gibt keine Verbindnung, die andere Seite muss wissen, dass Pakete kommen; ein bisschen vergleichbar wie UDP.

      genevt schrieb:

      Ich mache später mal eine Grafik
      Ich habe es versucht mal so darzustellen, da ich schriftlich manchmal Probleme habe.

      Fester Teil bei Anlegen eines Ethernet-Interface auf einem üblichen Ethernet-Device eines Rechners:

      Brainfuck-Quellcode

      1. Ethernet
      2. ---------
      3. 802.3 PHY


      Der IP-Stack macht daraus:

      Brainfuck-Quellcode

      1. IP
      2. ---------
      3. Ethernet
      4. ---------
      5. 802.3 PHY

      Wenn du nun den IP-Stack nutzt, dann musst du dich um diese Schichten nicht kümmern, du gibst den IP-Stack nun ein paar Meta-Daten und den Payload, fertig!
      GRE-Tunnel macht dies:
      Fester Teil bei Anlegen eines GRE-Tunnels:

      Brainfuck-Quellcode

      1. GRE
      2. ---------
      3. IP

      Der GRE-Tunnel gibt dem IP-Stack, die Meta-Daten und als Payload seine eigenen Header und den eigentlichen Payload.
      Nun kann man (mein Programm, der IP-Stack, what ever) dem GRE-Interface Pakete als Payload und ein paar Flags geben und sollte fertig sein, da sich um alles darunter von anderen gekümmert wird. Das ist halt das Schichtenmodell.

      Wenn du weißt, was ich statt einer der von mir genutzten "enums" (eigentlich Bytewerte, aber durch die Defines fühlt es sich ein bisschen wie enums an) setzen muss, damit es auch mit Kernelmodul ip6_gre geht, her damit. Ich gehe davon aus, dass es fast richtig ist, weil es mit ip_gre geht.

      Moin!

      @hefr54 / @danXde: GRE ist ein transparenter Tunnel - Alles was auf einer Seite reingeht wird in GRE verpackt, über den Tunnel transportiert, und wird auf der anderen Seite wieder entpackt. Was das ist, ist dem Tunnel egal. Also IPv4, IPv6 oder RAW.
      Es sollte reichen dem fertigen Tunnel IPv6 und IPv4 zu verpassen, damit beides darüber laufen kann.

      @genevt: funktionieren tut Dein Code, wenn der HAAP Dir antwortet...

      Die Control-Messages brauchen einen speziellen GRE-Protocol-Type, den Linux Dir nicht einfach so schreibt... sonst erkennt der HAAP sie nicht als Steuernachricht. Deshalb steht im Draft extra nochmal, wie der Gesamt-Header, inklusive angepasstem GRE-Header auszusehen hat.

      Du kannst also als Steuerkanal nicht einfach einen zusätzlichen GRE-Tunnel aufbauen, sondern schickst die gebastelten GRE-Pakete einfach direkt an den HAAP. (ist fast wie ein GRE-UDP ausgelegt)

      Eigentlich hätten Sie dafür genauso gut auch UDP oder was auch immer nutzen können - nutzen aber GRE-Pakete, weil sie damit die Laufzeiten ermitteln wollen... (Steuernachrichten und Daten sollen den gleichen Weg nehmen)

      Laut Draft läuft die Steuerung also nicht per GRE-Tunnel, sondern per speziellen GRE-Paketen (ohne Tunnel).

      Bei einem IP-Raw-Socket kann man den Type setzen - zB. auf 47 für GRE...
      Wenn man, ähnlich IP, den GRE-Protocol-Type setzen könnte, ohne den Header selbst zu bauen - dann ginge das eventuell auch so, wie Du es grad' versuchst.
      Aber dann hätte man einen zusätzliche Tunnel, müsste trotzdem irgendwo basteln - dann kann man sich das auch sparen und den Header einfach selbst schreiben.

      Aber im Grunde ist's ja auch egal: ich wollt' Dir weder zu nahe treten - noch bin ich für Dein Code-Review zuständig :D
      Wenn der HAAP Dir einen Tunnel bestätigt, hattest Du Recht - aber ich würd' sagen, ohne den passenden Potocol-Type sieht der HAAP Deine Pakete wohl nicht als Control-Messages an.

      mfg, emkay

      Hi,

      brauche kurz hilfe.
      Habe mir den E3372h-153 zugelegt, Firmware geflasht, soweit alles ok.
      Bin Verbunden im 4G-Only Mode (sysconfig-Parameter gesetzt).

      Hat euer WWAN0-Adapter automatisch einen IPV6-Neighbour gefuden oder muss man da etwas zutun?

      Quellcode

      1. ​wwan0 Link encap:Ethernet HWaddr 00:1e:10:1f:00:00
      2. inet addr:169.254.62.145 Bcast:169.254.255.255 Mask:255.255.0.0
      3. inet6 addr: fe80::b0b4:a7ba:fee8:b03/64 Scope:Link
      4. UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
      5. RX packets:0 errors:0 dropped:0 overruns:0 frame:0
      6. TX packets:57 errors:0 dropped:0 overruns:0 carrier:0
      7. collisions:0 txqueuelen:1000
      8. RX bytes:0 (0.0 B) TX bytes:13001 (12.6 KiB)


      Quellcode

      1. ​ip -6 neigh show

      eMKay77 schrieb:

      Die Control-Messages brauchen einen speziellen GRE-Protocol-Type

      eMKay77 schrieb:

      Wenn man, ähnlich IP, den GRE-Protocol-Type setzen könnte, ohne den Header selbst zu bauen - dann ginge das eventuell auch so, wie Du es grad' versuchst.

      Dies mache ich mit der unscheinbaren Zeile:

      Quellcode

      1. socket_address.sll_protocol = 0x0101;

      Falls du jetzt einwenden willst, dass dass im Draft, etwas anderes als Protocol-Typ steht: In der Realität habe ich nur 0x0101 gesehen.

      Wie die Pakete aussehen sollen, weiß ich, das kann ich auch mit meinem Code bei IPv4 erreichen, aber bei IPv6 geht es irgendwie nicht. Am lebenden Objekt kann ich leider aktuell nicht testen.

      @Schnup89: ich kenn' bei Huawei eigentlich für LTE-Verbindungen durchgehend-Cyan - durchgehend-Blau müsst' eigentlich HSDPA o.Ä. sein...

      @genevt: nö, will nix einwenden... is ja Dein Code.

      mfg, emkay

      EDIT: morgen sollte mein Netgear da sein - danke nochmal an den Zuschuß der Sponsoren - werd' mich da erkenntlich zeigen...
      :D
      werd' aber zweigleisig weitermachen - also Stick und LTE-Bridge.
      (so groß ist der Unterschied ja nicht - Stick ist nur nerviger wegen FW, Initialisierung etc.)

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

      Ich muss bei meinem leider immer mit der Nadel ran, sobald ich eine neue Version haben möchte :D
      Bisher haben von 8, eigentlich zu dem Modell passenden, Firmwares nur 2 funktioniert, bei den anderen habe ich eine rotes blinken :S

      Hast du eine Hybrid-Sim und konntest du eine Verbindung mit dem E3372 aufbauen?

      Edit:
      Hat geklappt, habe jetzt die IPV6-Adressen :)
      Habe bisher alle Kommandos auf /dev/ttyUSB1 eingegben.
      Jetzt hab ich ttyUSB0 genutzt, und es geht.

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