Neuer APN: "nonbonding.hybrid"

      Neuer APN: "nonbonding.hybrid"

      Moin.

      Ich habe ueber das Engineer-Menü zufällig gesehen das im "non-bonding" mode / sofortstart, usw. ein anderer APN verwendet wird:
      "nonbonding.hybrid" anstelle von "hybrid.telekom". Google kennt diesen APN ueberhaupt nicht, scheint wohl erst neuerdings bei den Gen.5 Telekom Hybrid Verträgen Verwendung finden ?

      Ein Tunnel wird hier nicht aufgebaut ebenso auch kein ipv6 zum haap so wie ich das sehe.

      stattdessen gibts "2.x.x.x" externe ips, sowie ein /64 bei ipv6.

      Die standalone PPPoE-Verbindung auf einer Fritzbox kann aber weiterhin verwendet werden.


      Evtl. interessant für eigene Bonding-Lösungen wie MLVPN, UBOND oder OpenMPTCP Router als "WAN2" und dann wie gewohnt ueber eine externe VM selber bundeln....

      Müsste ich manuell nochmal in einem 0/8/15 huawei stick testen unter verwendung dieses APN und vorherigen IPV6 patch des Sticks selber.
      Das würde dann auch für den Einsatz eines TPL-Link MR600 der CAT6/CA kann bis 300MBit Sinn machen, sofern man 1800/2100/2600 frequenzen sich heranholen kann über
      Richtantennen am Land.


      Gruss
      Ich habe den nonbonding.hybrid apn mal ausprobiert und kriege damit ganz passable Geschwindigkeiten von 85MBit/s (im Vergleich zu den 12 MBit/s die die SPP schafft).
      Hat jemand eine Idee welches GRE-Bonding in der SPP genutzt wird? Vielleicht kann ich mein Openwrt nutzen um das Bonding der Telekom zu nutzen ohne eine eigene VM irgendwo hinstellen zu müssen.
      Da gibts nen älteres github proof-of-concept mit dem das grundsätztlich mal funktionsfähig ist.
      Wichtig ist das du eine route zum haap.t-online.de als reines ipv6 haben musst!
      Nutzt du also einen E3276 oder ein E3372 Stick, dann musst mit den obligaten "NVWREX.... 8514...." settings erst einmal ipv6 am stick enablen,
      sonst siehst du kein v6 ueber LTE - das ist default bei ALLEN sticks das v6 hier schon immer deaktiviert war wenn im modem-mode!

      evtl. musst du dann aber noch die CID faken zu einer ID des SPH oder SPP.
      Imei Fencing muesste aktuell nicht aktiv sein, zur Not musst dann bei der IMEI auch noch nachhelfen mit einer vom SPH z.b. ;)

      Nutz mal die Forumsuche zu dem github Proof-of-Concept. das ganze ist aber outdated ein wenig....
      Also mein (zugegeben alter) Huawei E3276 brauchte nur die richtige Firmware-Version um IPv6-Only Mode zu aktivieren... der war nämlich nicht 'schon immer deaktiviert', sodern wurde erst in späteren Versionen der Firmware abgeschafft.
      Und mehr brauchte der auch nicht, um mit dem Haap verbinden zu können (von nem Hybrid-Client der's GRE-Bonding macht mal abgesehen).

      Noch einfacher war's mit ner Netgear LTE-Bridge...

      Naja, aber das steht alles schon im Forum ;)

      mfg, emkay
      Klar. wenn man die russische Firmware drauf packt hast per Default v6 aktiv.
      Die bessere Option wäre allerdings eine der "polnischen" gemoddeten "M_AT" Open versionen
      und dann eben das nvwrex 8514... command um v6 dann extra aktiv zu haben.
      Ist beim 3372H das gleiche Spiel, nur der Bitwert der speicherstelle bei 8514 ist hier etwas anders ;)
      Du solltest eventuell das Forum mal lesen... ;)

      Es reicht eine ganz normale Original-Firmware - sie muß nur den richtigen Versionsstand haben.
      (die gibt's sogar Telekom gebrandet, wenn man will - hatte ich hier verlinkt: LTE-Sticks mit Hybrid SIM)

      --> das LTE-Modul im SPH hat übrigens 'ne Firmware des selben Versionsstandes. (ok - zumindest damals...)

      mfg, emkay

      PS: wow - der Link oben geht auf Oktober 2016 zurück... wie die Zeit vergeht.
      Ich habe die ganzen Threads eh vor ner Weile durchgeackert... jaja bei hunderten Threads kann schon mal das eine oder andere unter gehen :)

      Weil ich es auch gerade nochmal sehe. die alte branded Firmware, bzw die entsprechende Open mit 00.00.00 dazu hatte das per default
      noch offen. Ich war bei meinem Hinweis jedoch an die letzten Firmware für E3272, E3276 und E3372h angelehnt.

      Ich hatte die Teile ueber viele Jahre im PKW im LTE-Router im Einsatz und Cell-Wechsel und gewisse Inkompatibilitäten sind mit den neueren
      Firmwares da besser geworden - mit dem Nachteil das dann die signed firmwares hinzu kamen und ohne die Needle Methode
      keine Downgrades mehr möglich waren ;)

      Sicher geht die "initiale" alte Firmware auch und ist bei nem festen Standort da vielleicht sogar einfacher.

      Was mir aber einfällt ist, das die älteren Firmwares mit dem NCM Treiber in bestimmten Konfigurationen Probleme gemacht hatten. Diesbzgl.
      wurden da später ja am Stick und am Linux-Treiber einige Huawei spezifischen Sachen beim Buffering noch verbessert.

      Ein Thema was mir aus der Vergangenheit dazu einfällt ist das im Dauerbetrieb irgendwann die Ringbuffer voll waren und es keine weitere
      Kommunikation im RX oder TX Channel mehr gab - dazu gabs dann im syslog auch seitenweise "USB -urb Timeout err" Messages dann nach einigen Tagen.


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

      So aber jetzt nochmal Frage in die Runde - weil ich es gerade selber nicht testen kann...

      "nonbonding.hybrid" als APN - braucht ich da immer noch zwangsweise den HAAP on top, oder tut der am Standort dann
      auch normal mit der 2.x.x.x IP + 1x /64 ?

      Meine extra Huawei Gerätschaften aus AT sind noch auf dem Wege und mit nem SPH muss ich das ja nicht testen.... ;)

      @eMKay77: Ja dein Alter Thread.... Es geht hier aber um den NEUEN APN, der wohl erst im SPPro hinzukam der eben non-bonding
      als "voranschaltung" ermöglicht, bzw. LTE-only Betrieb. Beim alten hybrid-APN wissen wir ja das der HAAP erforderlich ist seit Jahren.
      DAS war genau das was ich da mal eben wissen wollte weil ich es ja mangels der Hardware in Reichweite nicht mehr testen konnte. :)
      --- wie ich die Telekom kenne... alles was dem User bei seinem Product ja jetzt irgend einen Vorteil bringt etwas unabhängiger agieren zu können wird
      dann aber wohl wieder künstlich beschränkt beizeiten - obwohl das Blödsinn ist den Tunnelserver mit Single-Connections zu belasten, wo es nichts
      zum binden gibt normal.

      Das nonbinding.hybrid ist soweit ich informiert bin als "Schnellstart" für Neuanschaltungen Wochen vor dem Schalttermin bei SPPro mit hinzugekommen.
      Ich hab das vorhin im SPPro Engineer-Menu auch noch mal gecheckt. Da stand der Status fuer HAAP nämlich auch auf deaktiv.

      Fein, dann kann ich das wenn meine HW aus Austria kommt dann mal mit nem E5186 testen und auch mal versuchen das in dem HA35-22 "open" mal durchzuspielen

      Tip übrigens:

      ich habe als 2. Hop bei der Telekom 192.168.225.1 "intern" gerade gesehen. Das ist Neu das die Telekom hier in Segmenten jetzt 192er auch einsetzt. bislang haben die sich
      auf 10er und 172er Adressen beschränkt beim LTE-Internen "ueber 6 hops hausintern filtern" :)

      Check doch bitte mal bitte ob Du auch in dem Prefix: 2.160.128.0/17 mit drin bist. Offenbar reicht der kleine Prefix für alle non-hybrid User in ganz Deutschland aus ?
      Ich frage deshalb weil ich diese Prefixe mit im Remote-VPN-Server mit adden muss, und evtl. haben die in Süddeutschland dann noch andere Bereiche im Einsatz.

      Beim aktiven Hybrid werden im Norden bei mir aktuell dann die Adressen us dem Prefix: 80.187.0.0/17 als Bonding-Produkt vergeben. Evtl. gibts da in Süddeutschland
      ja auch andere Bereiche noch zusätzlich.

      Jedenfalls macht der SPPro jetzt nichts weiter als "non-bonding" und hängt als Fallback an einer MLVPN-Lösung mit dran zusätzlich zu den beiden VDSL-Lines die aber leider
      am selben DSLAM terminieren - die sind im Servicefall dann immer beide offline.

      Uebrigens hat eine eigene bonding Lösung ueber Vtun/vtrunk/mlvpn bzw. OpenMPTCP Router bei Verwendung von TCP für die Tunnel den riesen Vorteil, das man die Tunnel
      mit einer MTU von 1500 fahren kann - auch wenn die drunter liegenden Links unterschiedliche MTUs haben. Mit UDP Tunneln ist das nicht machbar. Ich kann
      das leidige clamping mit der HA-Lösung vollständig abschalten bei dem TRaffic der dann durch die Tunnel rennt. Auch die Failoverzeit von maximal 200 msec bei Ausfall
      eines Tunnels sind absolut akzeptabel. Alle offenen Verbindungen bleiben immer bestehen - bis auch der letzte Link dann ausfällt.

      Als aktuellen Tip: netcup hat passende kleine VMs wo man noch extra v4 und extra /64 Prefixe ordern kann. Man kommt so auf ne Flat-Lösung von etwa 5 Euro im Monat.
      Dafür hat man dann aber auch static IPs und vor allem auch static v6 Prefixe im Office dauerhaft. Die Extra IPs werden bei denen auf das Hauptinterface des V-Servers gerouted.
      Man braucht die extra IPs dann einfach nur 1:1 durch die TUnnel jagen und hat sie exklusiv dann am Ende der Leitung. Das DTAG-Peering von netcup am Standort Nürnberg
      kann sich auch in Spitzenzeiten sehen lassen. Mit 2x50 MBit VDSL + 1x LTE "non-bonding" mit Dorfsender 800MHz sinds dann beim speedtest trozudem noch so um die 105 MBit netto geworden.
      Einzig beim Upstream macht die LTE-Verbindung - die den höchsten Upload hat dann einige Probleme mit kurzen Aussetzern, weil die Latenz hier höher ist als bei VDSL.
      Das zieht dann den ganzen Tunnel mit runter. Hat aber auch für saubere 22 MBit noch gereicht.

      Lange Rede... Das oben Beschriebe habe ich seit Monaten ueber eine Instanz im Wiener Rechenzentrum für die Server hier rennen und fürs Office dann ueber Nürnberg/netcup mit einem zweiten Tunnel.

      Verfügbar ist jedenfalls locker 99.999% mit günstigsten Lösungen.....

      ...dann wegen der good News den SPP in Kürze gegen einen Huawei E5186 Tauschen mit einer modded Firmware. Der macht ja auch CAT6, die Bänder können von Hand addiert werden und braucht massiv weniger
      Strom für einfaches LTE. Vor allem hat der ordentliche SMA-Buchsen auch für externe Antennen.... via willhaben.at so um die 15-20 Euro als "Hui Webgate von 3" massenweise zu bekommen übrigens.
      Öhm... ich hatte eben mal das Engineer-Menu ne Weile offen... also der SPP ist ja ne richtige SPY-Dose...

      Der hat ja sowieso tr069 daueroffen - und macht fleissig seine Updates - nicht nur einmal beim hochfahren.
      Ich habe Verständnis dafür sich gewisse Änderungen da mal beim hochfahren zu holen. IPTV Prefix-Listen upzudaten... aber...

      Besonders interessant ist das der trotz komplett ausgeschaltetem EasySupport/Autoupdates usw.
      sich vollständig beim Telekom_FON auch noch anmeldet und schön registiert bleibt - und das im Status DISABLED.
      Auch hier ohne Ende Updates. Im Logfile steht dann: "Sie können Telekom_FON jetzt nutzen" - im disabed mode ?
      - sollte das heissen ich kann trotzdem andere FON-Hotspots jetzt nutzen unterwegs ?

      ...das gefällt mir ueberhaupt nicht das die offensichtlichen "Hilfefunktionen" zwar im Webinterface abgeschaltet sind alle,
      das Teil aber für die Telekom & Anhang nach wie vor vollständig zugängig ist im Grunde....

      Passt das zur DSGVO wenn ich klar entschieden habe, alle Remote-Service zu deakvieren und ueber ein nicht offzielles
      Menu dann erfahre, was er dann doch so treibt mit Diensten die ich nicht haben will ?

      ...wird Zeit das wir die Kiste aufbekommen und dem abhelfen mal wie beim SPH :)

      TheHiman schrieb:

      a dein Alter Thread.... Es geht hier aber um den NEUEN APN, der wohl erst im SPPro hinzukam der eben non-bonding
      als "voranschaltung" ermöglicht, bzw. LTE-only Betrieb. Beim alten hybrid-APN wissen wir ja das der HAAP erforderlich ist seit Jahren.
      Es ging aber nicht um alter/neuer APN, sondern nur darum, daß Du der Meinung warst es wäre 'ne modifizierte Stick-Firmware nötig...

      godofdream schrieb:

      "nonbonding.hybrid" geht im moment auch ohne HAAP.
      Das ist mal interessant... werd' ich wohl mal meine LTE-Bridge rauskramen müssen und den Lancom auf Multi-WAN/Loadbalancing konfigurieren...
      (beizeiten dann mal testen, ob der Lancom nen GRE zum HAAP schafft - aber noch ist's ja scheinbar nicht notwendig)

      Endlich mal wieder was Neues :D

      mfg, emkay
      So meine Sim-karte ist heute erstmal wieder deaktiviert (wechsel von 16Mbit Hybrid auf 100Mbit, mal sehen ob das nach dem 8. Anlauf klappt).
      Angeblich ist an meinem Account schon ein Ausrufezeichen :| (habe mir auch Mühe gegeben die zu Ärgern.)
      Hole mir die LTE Option aber wieder.

      Die IP begann jedenfalls mit 2.160 muss jetzt aber warten bis ich meine neue SIM bekomme.

      bezüglich netcup:
      Will lieber den HAAP von der Telekom nutzen, schließlich zahle ich für das Dingens.
      Hast du einen besseren Ping/Durchsatz mit OpenMPTCP als mit dem HAAP?

      Ich habe hier ein tripple Setup: ADSL + LTE von der Telekom + LTE von Telefonica.
      ADSL mit 14Mbit/s und massiv Paketdrop
      Telefonica LTE schafft bei mir 45/40Mbit/s
      Telekom LTE schafft 85/20Mbit/s (noch optimierbar, ich muss dazu meine Richtantenne drehen)
      Über den SPP kam dank angelöteten Externen Antennen maximal 20Mbit/s durch, deshalb sind die direkt wieder rausgeflogen, und der SPP muss in den Keller.

      Ich empfehle dir auf jeden Fall den B818-263 (habe mir den für 150€ als gebrandete Vodafone variante geholt).
      Mit CAT 19 holst du dank Mimo 4x4 deutlich mehr raus (habe dem Router 4 externe Antennenanschlüsse gegönnt und 4 Richtfunkantennen mit unterschiedlicher Polarisation (jeweils 45° verdreht) auf den Nächsten Mast gerichtet) und dank dem Huawei-band-tool nimmt er auch das richtige Band.
      Carrier Aggregation ist an meinen möglichen Masten leider nur mit Band 3 machbar und das ist immer überlastet.
      Ich versuche demnächst aber andere/weiter entfernte Masten.


      Endlich mal wieder was Neues

      hatte auch schon paar Böse Ideen in Richtung Openwrt für den SPP. Aber werde womöglich das Ding zurückgeben und einen SVDSL Router mit Openwrt unterstützung holen.


      übrigens: E3372h-320 und B818-263 haben beide auf anhieb IPv6 unterstützt.

      Die Mimo Sachen + externe Richtfunkschuesseln damit ich ueberhaupt 1880+2100 importieren kann bringt bei mimo 4x4 gar nichts da ich dann auch 4 anschlüsse hier bräuchte :)
      bei der 800er Dorfstation und 10 MHz Bandbreite ist mimo 4x4 auch sinnfrei bis jetzt.

      Mimo 4x4 als Solches mit den in DE erhältlichen Geräten wirst du in allen 3 Netzen in AT auch ohne externe Antennen seit Jahren mehr Freude haben.
      Da hast auch mit 2x2 schon per Default um die 200 / 100 bei allen Anbietern am Land. In DE ueberhaupt mal ueber 100MBit zu kommen wenn man nicht
      gerade in einer Kleinzelle in der Stadt sitzt ist eigentlich kaum irgendwo machbar :(
      - und selbst wenn.... dann nur kurze Zeit in der Nacht teilweise. Von 300 MBit als 24/7 Stand ist man hier leider immer noch weit entfernt - dazu muss die Senderdichte auch erheblich besser
      werden und sämtliche Stationen zumindest mit Glas angebunden sein. Nimm als Beispiel mal die A1 Westautobahn Wien-Salzburg seit Jahren: etwa 1000 Meter Abstand ueber
      eine 300km Strecke seit Jahren schon - entlang der Strecke liegt das Glas Wien-Muenchen - da gabs noch nie wirklich Performance Probleme - auch nicht bei UMTS damals.


      Wenn die Telekom hier die 1500 MHz Frequenzen diedie seit Jahren ungenutzt liegen haben auch mal exklusiv für downstream nutzen täten sehen es in deutschland schon anders aus
      beim Hybrid :)

      Ich habe letzte nacht mit dem nonbonding-apn und einem SPPro mal was Neues erlebt:

      ein blackhole bis jetzt bei Verwendung des non-HAAP APNS! - keine ahnung ob das bug/basteln bei denen immer noch ist.
      jedenfalls hört es bei der 192.168.225.1 der telekom dann auf - alles andere ist ein blackhole - und das trotz nutzung deren SPP Kübels..

      Für die eigenständige Verbindung muss ich jetzt zwangsweise den hybrid-APN nutzen und leider auch den extra tunnel nur für LTE only und somit eine MTU bei 1448 unnötig.

      ->> könntest Du auch einmal testen ob deine 2er IPs noch Routing haben ? falls ja, seit wieviel Tagen hast du nonbonding schon aktiv ?
      (evtl. blocken die sogar bewusst wenn jemand bewusst nur den nonbonding APN tagelang verwendet dann diese Verwendung - dabei ist sie im
      SPPro regulär konfigurierbar im LTE setup (LTE: bonding deaktivieren / fallback only..)

      evtl. ist es nur temporär? In der Früh fiel dann nämlich im Anschluss das reguläre HAAP Bonding auch stundenlang aus, ebenfalls mit einem Blackhole....
      ...Das Linke ist ja, du bekommst IP Adressen zugewiesen und intern bei denen im Netz klemmt es dann - da ist nix mit Redunanz ohne o2 als echtes Backup auf diese Weise :(

      Ich hatte es ja schon angesprochen.. wirklich alles was dem Kunden wirklich hilft eine eigene Redunanz jenseits der kastrierten Geräte zu bauen wird einem irgendwie madig gemacht... ;)


      Zu Deiner Frage mit der Performance und eigener Lösung: JA: die Lösung ist redunanter - alleine weil sie mit unterschiedlichen Latenzen auch bei Überlast ganz anders Loadbalancen kann,
      vor allem gibts die sinnlosen Ausnahmeregeln regeln nicht und du hast volle Kontrolle über jegliches Forwarding und QoS - wobei immer alles ohne Unterbrechnungen durch den Tunnel rennt.
      - egal ob du nun 1 oder 8 WAN-Links bundelst. Steigen die Latenzen einzelner Links an, werden diese WAN-Links dann vorübergehend auch nicht mehr verwendet, das ist frei konfigurierbar.

      Du hast immer deine eigenen static IPs bei v4 und v6 egal welches Mediem gerade verwendet wird. Aktive TCP-Verbindungen intern hinterm NAT bleiben offen und es findet auch kein
      unnötiges v6 SLAAC & DHCPv6 verzögert ständig mehr statt durch fehlerhafte oder gammelige einzelne WAN-Links.

      Wenn ich also solche HAAP-Basteleien wie letzte Nacht und die Berichte in den Foren der Vergangenheit so lese bedeutet das auch das die Verlässlichkeit der ganzen Bonding Sachen
      absolut daneben ist aufs Jahr gesehen. Die direkte PPPoE Verbindung "Lokal" ist da weit aus stabiler. Jetzt hab ich so eine Bastelaktion selber mal genossen und nonbonding.hybrid
      ist nach wie vor ein komplettes Blackhole (seit 16 Stunden jetzt schon....)


      Wegen Deinem "neuen" Router:

      Thomson DGA 4130/4132 mit GPON Slot, OpenWRt 15.05.1 und V35b und ueber 25 verschiedene DSL-Treiber zur Verfügung was am besten passt!
      Project von Ansuel ist auf github:

      github.com/Ansuel/tch-nginx-gui


      Auch Baby Jumbo Frames (MTU1508) für pppoe mit vollen 1500 ist machbar mit dem Teil. Lass die Finger von dem Lantiq Zeuchs, das triggert nur DLM und reduziert Dir eine Leitung von 280 MBit tageweise gerne bis auf 185 MBit runter.
      Mit Broadcom ersparst Du Dir Einiges bei den S-Vector Sachen wenn die Leitung dann doch ein paar Meter haben sollte.

      dank des OpenWRT und Kernel 4.x kannst Du da im Grunde auch VoIP und anständiges Firewalling sogar auf demselben Gerät mit bauen.
      Einen "modemd" daemon für am USB-Port angeschlossene Sticks wird per Default auch mit unterstützt. Sparst Dir also ggfs weitere externe Geräte ein.

      Bis 100MBit Vecor tun die Zyxel mit MTU1508 Patch und neuerem adsl_phy driver eigentlich auch am besten. An einer längeren Leitung ohne Vectoring machen die Teile auch gerne
      4-5 MBit mehr im Downstream als die VGX-Chipsätze und mit dem "xdslctl" hast du auch viel mehr Tuningmöglichkeiten für US/DS Tuning.

      Ich hab bei mir zu gunsten des Downstreams dann den Upstream - der sowieso reduziert ist auf 12 MBit - einfach die Sendeleistung veringern können - was dem Downstream dann
      mit einem besseren SNR zu gute kam. Ist leider alles nicht sehr gut dokumentiert und man muss schon ein wenig suchen für alle Funktionen. Entscheidend ist aber, das das System
      OFFEN ist und DU tatsächlich Unmengen am "arm" DSL Treibern genau passend zu "deinem" DSLAM vor der Tür durchtesten kannst - bis DLM zuschlägt, hrhrhrh

      eMKay77 schrieb:

      TheHiman schrieb:

      a dein
      Endlich mal wieder was Neues :D

      mfg, emkay


      Wie ich eben ja schon schrieb. Toll - derzeit sogar non-haap mit original SPP aber jetzt nach 5 Tagen Blackhole ab dem 2. HOP...... entweder config fehler bei der Telekom oder bewusst geblockt für Leute die die VDSL Leitung
      direkt mit PPPoE ohne Tunnel nutzen wollen und die LTE-connection eigeneständig selber verschalten wollen mit ner Remote-VM..... :(
      - direkt wieder mit nur einem link zwangsweise durch den HAAP ohne den DSL-Anteil, die Latenz erhöhen und die MTU massiv runter ist weniger zielführend irgendwie dauerhaft....
      Mal ein neues Update von mir.
      Nach laaangen Diskussionen, Technikerterminen und einer **** Wut , durfte ich den SPP zurückgeben.

      Und nach 4 Monaten telefoniererei habe ich VDSL 100. (Meine Letzte Meile ist 740 Meter, da kann ich SVDL getrost vergessen, abgesehen davon, dass mein Endpunkt überlastet ist.)


      Mein jetziges Setup:

      Archer c7 mit Openwrt als Switch

      T VDSL 100/40 (95/33 kommen durch) über eine Fritzbox 7581 (Ich war geizig)

      T LTE Backup Option nonbonding über eine frequenzoptimierte B818-263 mit 2x20dbi Antennen

      Starlink 100-300/10-50 (Beta, deshalb schwankt es aber noch stark)


      Mein O2 wird jetzt abgekündigt (Auch wenn ich Telefonica extrem dankbar bin, weil die als einziges Internet sofort anbieten konnten)

      Wenn ich jetzt rausfinde wie ich ein Bonding mithilfe von meinem Openwrt über das haap mache bin ich glücklich.


      Moin!

      7581 ist doch gar nicht übel - und immerhin noch lieferbar... für 'Geizige' (und die meisten Anderen) wäre aber die 7530AX wohl die beste Wahl...
      (besseres WLAN, günstig und lieferbar)

      Hybrid ist eigentlich gar nicht mega-komplex: zum HAAP ein standard GRE-Tunnel pro Kanal, in Empfangsrichtung klatschen die Daten aus beiden Tunneln auf die gleiche IP und werden vom TCP-Stack sortiert.
      Problem ist die Kontroll-Schicht: besteht zwar aus wenigen Messages, die aber teils regelmäßig ausgetauscht werden - ich kenn' keinen 'production-ready' client/daemon dafür. (man könnt' wohl versuchen, den client vom SPH in nem OpenWRT-MIPS zum laufen zu bekommen - so ein wenig 'frankensteinen' :D )

      Mein Client ist nur 'halb' - nur LTE, hat 1-2 known issues und läuft nur mit ein wenig 'Handarbeit'... ich glaub' auto-restart fehlt auch noch.
      Könnte ihn aber zur Verfügung stellen, falls sich ein Ada-Entwickler findet, der daran arbeiten möchte...

      mfg, emkay