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

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....

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

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.

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

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

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....