Quectel CAT 6 LTE am USB Port vom SPH

      Quectel CAT 6 LTE am USB Port vom SPH

      Moin @All,

      mein Modem ist angekommen und somit habe ich mich mal an die Treiber gemacht, das Ergebnis sieht schon mal gut aus. Die Datenrate hat sich eigentlich verdoppelt im Gegensatz zum Internen LTE Modem!




      Ich habe die aktuelle Firmware am laufen und das Gerät mit Telenetzugang erweitert.

      Jetzt die Treiber nach /lib/usblte, dh nach /etc kopiert und das /etc/profile angepasst.



      mount -t usbfs none /proc/bus/usb
      +mount -t sysfs /sys /sys
      ....
      makedevs -d /etc/devicetable /
      +busybox-mips mknod -m 666 /dev/cdc-wdm0 c 180 176
      ....
      mkdir -p /dev/pts
      mount -t devpts devpts /dev/pts
      /bin/busybox-mips telnetd -l /bin/sh
      iptables -I INPUT_FIREWALL -s 192.168.1.0/24 -j ACCEPT
      sleep 60
      iptables -t nat -I POSTROUTING -s 192.168.1.0/24 -j MASQUERADE --mode fullcone
      iptables -I FORWARD -s 192.168.1.0/24 -d 172.10.10.1 -j ACCEPT

      +test -e /lib/usblte/ecb.ko && insmod /lib/usblte/ecb.ko
      +test -e /lib/usblte/pcbc.ko && insmod /lib/usblte/pcbc.ko
      +test -e /lib/usblte/mii.ko && insmod /lib/usblte/mii.ko
      +test -e /lib/usblte/usbnet.ko && insmod /lib/usblte/usbnet.ko
      +test -e /lib/usblte/usbserial.ko && insmod /lib/usblte/usbserial.ko
      +test -e /lib/usblte/usb_wwan.ko && insmod /lib/usblte/usb_wwan.ko
      +test -e /lib/usblte/option.ko && insmod /lib/usblte/option.ko
      +test -e /lib/usblte/qcserial.ko && insmod /lib/usblte/qcserial.ko
      +test -e /lib/usblte/cdc-wdm.ko && insmod /lib/usblte/cdc-wdm.ko
      +test -e /lib/usblte/qmi_wwan.ko && insmod /lib/usblte/qmi_wwan.ko



      Moden an USB Port stecken, sollte dann ein /dev/cdc-wdm0 zu finden sein, sowie ein ifconfig wwan0

      Dann in der erste Telnetkonsole:


      busybox-mips microcom /dev/ttyUSB2

      AT+CGDCONT=1,"IP","nonbonding.hybrid"
      AT+QNETDEVSTATUS=1
      AT$QCRMCALL=1,1,1,2,1

      AT+QNETDEVSTATUS?


      Kommt ein +QNETDEVSTATUS: 1,2,4,1 ist man Online :)

      Zweite Telnetkonsole auf:


      ifconfig wwan0 up
      busybox-mips udhcpc -f -n -q -t 5 -i wwan0 -s /etc/dh

      Optional:
      iptables -t nat -A POSTROUTING -o wwan0 -j MASQUERADE


      ping -I wwan0 heise.de , sollte dann funktionieren.
      Es ist zwar noch nonbonding aber es funktioniert schon sehr gut.

      Ich kämpfe noch ein wenig mit der iptables, vieleicht kann da jemand helfen. z.B. Firewall, Routing für wwan0.

      Ich raffe auch das Umleiten von 172.x.x.x nicht, wollte hier einen Proxy programmieren um das QuectelModem mit zu bedienen um Bondig hinzu bekommen (mic & cms)

      Grüße ThomasK
      Dateien

      Dieser Beitrag wurde bereits 7 mal editiert, zuletzt von „ThomasK“ ()

      Moin!

      Coole Sache!

      Ich selbst bin ja eher ein 'minimal invasiver'... ich würd' wohl dazu tendieren, das externe Modem an die Stelle des Internen zu setzen - dann würde der sph/mic das Bonding übernehmen.
      Je nach AT-Kommando-Satz würde der mic dann auch die Einstellungen übernehmen, sonst müsst man das irgendwo 'einschleifen'.

      Leider ist in der Firmware vieles hardcoded, der mic und auch andere Binaries rufen CLI-Tools mit vorgegeben Argumenten auf.

      Aber definitiv schön, mal wieder was 'Neues' zu sehen :D

      mfg, emkay
      öhm Sekunde....

      Als ich das als letztes in meiner Region getestet hatte war da nix mit dem APN in einem E3276 stick oder Huawei kompakt router. eine NCM verbindung mit dem nonhybrid-APN
      und "normalem" full Inet mit v4 und einem v6 /64 und den obligaten ips 2.x.x.x gabs bei mir nur im SPPro....

      Braucht das nonhybrid nicht unbedingt den HAAP server im non-bonding mode zum quasi sinnlos-tunneln ?

      ...dann haben die irgendwas geändert.

      Evtl. existiert im nonbonding mode ohne HAAP tatsächlich noch ein imei fencing damit man keine normalen LTE router/Sticks einsetzen kann.
      Da müsste man dann wohl die IMEI auch noch anpassen auf etwas aus dem SPH/SPP Range ?

      Bin da gerade überascht das der APN normal jetzt wohl nutzbar wäre..

      ...jetzt fehlt mir nur noch eine xml-datei für den "Mic" der mir die bridge aufsplittet und LAN4 als PPPoe/Bridge Port für ein externes Modem aufmacht....

      Dann können wir das SPH als reinen "HAAP-Converter" einsetzen. Modem dann extern etwas gutes mit Broadcom-Chipset und LTE-Device auf CAT6 oder CAT16+
      und dort angebracht wo auch die (Richt-) Antenne wirklich steht.....

      Die sache mit den 172er ips ist das man das terminal von /dev/ttyUSBx als Hayes console dann erreichen kann. Ueber diese IPs kommuniziert der SPH ja auch mit seinem
      Onboard Modul. Theoretisch müsstest eigentlich die IPs auf dein Modul verbiegen und die Hayes commands für das QuecTel & co device etwas anpassen anpassen für den Init.

      Normalerweise würde dann statt dem internen modem das Externe Moden genutzt werden. Die Huawei Driver dazu ENTLADEN im kernel könnte auch helfen,
      so hättest du das ttyUSB und wdm-device von deinem exernen Modem an ersten stellen. So wie ich das sehe wird hier ebenfalls NVM Mode verwendet.
      Prüfen muesstest Du das die NCM Treiber da auch passend sind bei den Buffers. Huawei hat leider beim NCM Protokoll einige non-standard Werte gesetzt.
      ggfs. musst du das ncm kernel modul mit einem extra "Buffer-Paramater" dann laden. Es sei denn der ncm driver erkennt ueber die PCI-ID den hersteller und setzt hier die
      Werte per default dann korrekt. Das Thema könnte ein Fallstrick werden und kann zu Hängern im cdc/wdm mode kommen unter load....

      schaut aber mal gut aus soweit :)

      sauber gemacht!

      eMKay77 schrieb:

      Moin!

      Coole Sache!

      Ich selbst bin ja eher ein 'minimal invasiver'... ich würd' wohl dazu tendieren, das externe Modem an die Stelle des Internen zu setzen - dann würde der sph/mic das Bonding übernehmen.
      Je nach AT-Kommando-Satz würde der mic dann auch die Einstellungen übernehmen, sonst müsst man das irgendwo 'einschleifen'.

      Leider ist in der Firmware vieles hardcoded, der mic und auch andere Binaries rufen CLI-Tools mit vorgegeben Argumenten auf.

      Aber definitiv schön, mal wieder was 'Neues' zu sehen :D

      mfg, emkay


      Aehm. in gewissem Umfang bei den kleinen at inits sollte ein hex editor beim init patch da helfen.
      längere Sachen und Cell-Settings / Band config usw dann wie gewohnt ueber tty / echo commands noch ans device senden.

      Ich denke die decrypted config sollte da noch ein wenig hilfreich sein einige parameter verbiegen zu können.

      Ich suche hier auch noch die möglichkeit die vorhandenen Parameter für die VDSL/WAN und Bridge Sache entsprechend umzubauen und dann die config wieder zu crypten.
      Ich möchte den LAN4 port für pppoe gleich beim "mic"-init von der bridge auskoppeln und alles mit pppoe nur ueber LAN 4 an ein externes device senden.
      damit ich das modem noch managen kann würde ich ueber das tagged vlan7 noch ein untagges zwischennetz ueber die fw.sh mit einem "ifconfig xyz" noch drauf setzen.
      So wäre dann auch das nachgeschaltete externe Modem ueber den SPH noch erreichbar. mit einer passenden Firewalregel und MASQUERADE auch so, das
      NTP, SYSLOG, DNS, SMTP, SNMP des Modems ueber NAT noch nach aussen kommt und so wäre das Modem davor vollständig managebar.
      (Das Zyxel VMG1312 wäre hier ideal oder das Thomson DGA 4130/DGA4132, eine FB 7581 mit BRCM chipsatz tuts da aber auch)

      So wie ich das sehe, wäre in der xml config wo die WAN und LAN bridge zusammengebastelt wird eigentlich alles vorhanden. ich hänge nur noch an der umformulierung.

      Das nach dem init mit diversen shell commands wieder manuell im Nachgang zu setzen ist da eher etwas unsauber finde ich....

      Mein Praxisproblem aufgrund einer sehr langen Leitung ist recht Simpel:

      Ich brauche ein Broadcom-Modem um ueberhaupt noch 50 MBit netto aus der VDSL holen zu können - dazu muss das Modem aber direkt neben den APL - jeder letzte Meter zählt hier.

      Beim LTE am Land der uebliche Telekom "machen wir nur in Deutschland so Zirkus":

      Völlig überlastete 800er Station direkt vorm Ort und dauerhaft 7-15 MBit für den ganzen Ort - un in 9 km Entfernung 1800+2100 Mit problemlos 180 MBit.

      Lösung: Eine 80cm RichtfunkSCHUESSEL - also keine Flachantenne oder Yagi. die Schuessel bündelt auf echte 24-27 db Gewinn! - Hat einen Öffnungswinkel von etwa
      5 Grad und damit hole ich mit die fehlenden Frequenzen mit "grünem" SNR in Haus. Und auch Hier: Die Antenne wiederum ist am Dach - also 30 Meter vom SPH entfernt.
      LTE Modem muss direkt bei der Antenne sein - VDSL Modem direkt neben dem APL - der SPH dann in Der Wohnung. Ethernet mit 100 Meter ist problemlos.
      mit dem USB bei mehr als 5 Meter sicher ein Problem, aber auch hibt es Konverter-Lösungen, sogar galvanisch getrennt.

      PS: die "bis zu 300 MBit" ueber LTE sind so mit fast 200 MBit halbwegs dann auch vorhanden. Allerdings eine Richtfunkschuessel als "Mindesthaushalts-Standard" ist schon affig :)
      In Österreich habe ich selbst vor +10 Jahren sowas nicht gebraucht. Da habe ich meine 200-300 MBit eigentlich ueberall schon seit Jahren als Basis-Datenrate
      bei allen Anbietern. In DE bekommst immer nur 1/10 der vertraglichen Leistung als bitterer Standard seit Jahren. Andererseits was will ich mit 300+ MBit in einer Grosstadt wo es ein Ueberangebot
      an FTTH/S-Vectorinbg gibt? Am Land sollte es ja auch ankommen ^^ Dafür ist Hybrid ja auch gedacht.
      Ich betreue einen Bekannten in AT der auch Hybrid hat. Der hat ne ADSL-Klapperleitung mit 10 MBit/1 MBit, aber eine LTE-Verbindung mit 350-400 MBit und die hat er fast rund um die Uhr.
      Dort ist die ADSL-Line das Backup. Der Kram rennt aber Festnetzstabil am Land drüben.

      Ich sag nur: HA35-22, siehe die Diskussion wo ich Dich auch eingeladen habe. Ich bin immer noch dran den DE tauglich zu machen. Die Sourcen fuer den HA35-22 sind im B310/B311 Modell enthalten!
      - Das ist der Sourcecode der einige 100 MB gross ist. (also eine 00.00.00) open Version. Die Codebase ist komplett inkl. einem usbl-loader. einzig einen usbl-safe loader muss man noch bauen
      (Thema Balloon USB Loader und Huawei)

      EIne MicroUSB-Buchse auf das Mobo nachlösen oder fixes Kabel dran. der 5. pin auf der Platine wäre dann für die Needle-Methode. dann schaltet der HA35-2 sofort einen com-port
      in den bootloader mode und das Balloon-Tool tut wie bei allen anderen sticks und Routern hier ganz genau so.....

      Ich spech es deshalb an, weil du Huawei-ueblich hier dasselbe xml-basierte webinterface wie bei den E5186 sachen hast.

      Einfach die xml-dateien für den tunnelserver anpassen. den haap.-t-mobile.de kennt er bereits. evtl. die CID und IMEI noch anpassen
      Und dann hat der zu connecten (leider aber nur CAT4) jedoch hat der in der Openversion Unmangen an settable vlans für VDSL, Voip ist vollständig anpassbar und
      unzählige config optionen. Auch ipv6 subdelegation weiterer /64 an nchgelagerte router ist hier problemlos machbar.

      Das schwarze T-Mobile Austria sim unlocked device um 30 euro aus willhaben.at nehmen - oder um 10-15 euro den weissen sim-locked A1 und mit den baloon loader noch den simlock entfernen....
      wie man halt mag....