LTE-Sticks mit Hybrid SIM

      hefr54 schrieb:

      Also am Linux liegt es bestimmt nicht, sonst wäre es ja bei mir auch so ;)
      :~$ uname -a
      Linux pc 4.7.4-040704-generic #201609150330 SMP Thu Sep 15 07:32:22 UTC 2016 x86_64 GNU/Linux
      :~$ cat /etc/debian_version
      stretch/sid

      Keine Sondereinstellungen, einfach an eth0.

      same here

      Quellcode

      1. ​
      2. root@bananapi:~# uname -a
      3. Linux bananapi 3.4.112-Stricted+ #4 SMP PREEMPT Mon Sep 19 06:06:10 CEST 2016 armv7l GNU/Linux
      4. root@bananapi:~# cat /etc/debian_version
      5. 8.6
      6. root@bananapi:~#

      hab nur nen selber kompilierten kernel um einen treiber zu updaten

      Quellcode

      1. emkay@emkay-Aspire-7741:~$ uname -a
      2. Linux emkay-Aspire-7741 4.4.0-38-generic #57-Ubuntu SMP Tue Sep 6 15:42:33 UTC 2016 x86_64 x86_64 x8
      3. 6_64 GNU/Linux

      Quellcode

      1. emkay@emkay-Aspire-7741:~$ ip addr show
      2. 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
      3. link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
      4. inet 127.0.0.1/8 scope host lo
      5. valid_lft forever preferred_lft forever
      6. inet6 ::1/128 scope host
      7. valid_lft forever preferred_lft forever
      8. 2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
      9. link/ether 20:6a:8a:23:95:5a brd ff:ff:ff:ff:ff:ff
      10. inet 192.168.2.100/24 brd 192.168.2.255 scope global enp3s0
      11. valid_lft forever preferred_lft forever
      12. inet6 2003:56:c844:1465:fff0:594a:1a84:7df7/64 scope global noprefixroute dynamic
      13. valid_lft 604771sec preferred_lft 86371sec
      14. inet6 fe80::5cb3:53c8:55c4:9a8d/64 scope link
      15. valid_lft forever preferred_lft forever
      16. 3: wlp5s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
      17. link/ether 20:7c:8f:47:08:02 brd ff:ff:ff:ff:ff:ff

      Quellcode

      1. emkay@emkay-Aspire-7741:~$ ip route show
      2. default via 192.168.2.1 dev enp3s0 proto static metric 100
      3. 169.254.0.0/16 dev enp3s0 scope link metric 1000
      4. 192.168.2.0/24 dev enp3s0 proto kernel scope link src 192.168.2.100 metric 100

      @eMKay77

      Quellcode

      1. ​
      2. root@bananapi:~# ip addr show
      3. 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN group default
      4. link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
      5. inet 127.0.0.1/8 scope host lo
      6. inet6 ::1/128 scope host
      7. valid_lft forever preferred_lft forever
      8. 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
      9. link/ether 02:01:09:01:83:44 brd ff:ff:ff:ff:ff:ff
      10. inet 192.168.2.101/24 brd 192.168.2.255 scope global eth0
      11. inet6 2003:8e:6f77:5780:1:9ff:fe01:8344/64 scope global dynamic
      12. valid_lft 604766sec preferred_lft 86366sec
      13. inet6 fe80::1:9ff:fe01:8344/64 scope link
      14. valid_lft forever preferred_lft forever
      15. 3: tunl0: <NOARP> mtu 1480 qdisc noop state DOWN group default
      16. link/ipip 0.0.0.0 brd 0.0.0.0
      17. 5: tun1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 2048
      18. link/none
      19. inet 10.8.0.50/24 brd 10.8.0.255 scope global tun1
      20. 6: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 2048
      21. link/none
      22. inet 10.8.0.2/24 brd 10.8.0.255 scope global tun0
      23. root@bananapi:~# ip route show
      24. default via 192.168.2.1 dev eth0
      25. 10.8.0.0/24 dev tun1 proto kernel scope link src 10.8.0.50
      26. 10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.2
      27. 192.168.2.0/24 dev eth0 proto kernel scope link src 192.168.2.101

      @hefr54: die FW-Regeln kommen ja durch's Linux-RootFS - und das wird komplett ersetzt beim Update...
      Ich werd's nochmal vom RasPi an LAN2 nach USB- und WLAN-Aktivierung versuchen... (vielleicht ist's ein Nebeneffekt - ne Regel, welche versehentlich mit aufgehoben wird)

      EDIT: das war auch nix... werd's nachher mal mit ner älteren FW probieren - wenn's da geht, liegt's an der v3 - wenn nicht, an meinen Rechnern...
      (oder ihr spielt grad 'versteckte Kamera' mit mir :D )

      EDIT2: eine Idee hab' ich noch :)
      Im Moment läuft bei mir ja ne saubere v3 - nach Werksreset manuell konfiguriert. Es könnt aber ja sein, das der Telnet-Config-Schalter Nebeneffekte auf der Firewall auslöst... (die haben in der v3 zwar das Telnet-Bin entfernt - aber der Config-Schalter existiert noch und bei Update von v2 auf v3 bleibt er bestehen... Vielleicht öffnet er immernoch die Firewall.)
      Werd' also nachher einfach mal 'ne saubere v2-Config mit telnet=1 einspielen.

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

      Moin Leutz!

      Hab's :D

      Der letzte Gedanke war der Richtige: das Telnet-Config-Flag öffnet die LAN-seitige Firewall!
      Eventuell macht es sogar gar nichts Anderes, denn bei manchen Huaweis ist der übliche Rooting-Weg, per FTP-Back-Traversal die Firewall-Tabelle im cms-Binary zu patchen - was ja nur funktioniert, wenn hinter der Firewall ein funktionierender Telnet-Daemon darauf wartet, freigelassen zu werden...

      Die liebe Telekom hat uns also durch ihre Dummheit, nur das Binary zu entfernen, einen kleinen Weg offen gelassen - denn die LAN-seitige Firewall bekommt man immer noch auf.

      Ich hab' dafür jetzt einfach eine Werksreset-Config der FWv02...010, die ich noch rumliegen hatte benutzt. Einfach das Telnet-Flag setzen und in die v3 laden. (gut, ich musste danach manuell einrichten, aber egal)

      Dann reicht unter einer Bash-Shell

      Quellcode

      1. printf 'at^syscfgex=\"03\",3FFFFFFF,3,1,40,,\r' > /dev/tcp/172.10.10.1/1280
      Und schon hab' ich 'ne v3 auf 2600MHz fixiert :D
      (/dev/tcp/ ist ein bash-buildin, kein echtes Device -- es lenkt Ausgaben auf eine TCP-Verbindung -- gibt's auch für udp)
      Der Befehl gibt zwar in der Form keine Rückmeldung - ist aber hier auch nicht unbedingt nötig, Hauptsache es klappt :D

      mfg, emkay

      EDIT: natürlich kann man auch einfach von einer v02 mit aktiviertem Telnet updaten - dann bleibt das Flag erhalten.
      EDIT2: und das klappt übrigens dann auch auf LAN1 - und ist pingbar ;)
      EDIT3: da ist wirklich ein kompletter Stick drin...

      Quellcode

      1. at^setport?
      3. ^SETPORT:FF;6,3,12,14,13,16
      5. OK
      7. at^setport=?
      9. ^SETPORT:1: 3G MODEM
      10. ^SETPORT:2: 3G PCUI
      11. ^SETPORT:3: 3G DIAG
      12. ^SETPORT:5: 3G GPS
      13. ^SETPORT:A: BLUE TOOTH
      14. ^SETPORT:16: NCM
      15. ^SETPORT:6: GPS CONTROL
      16. ^SETPORT:A1: CDROM
      17. ^SETPORT:A2: SD
      18. ^SETPORT:10: 4G MODEM
      19. ^SETPORT:12: 4G PCUI
      20. ^SETPORT:13: 4G DIAG
      21. ^SETPORT:14: 4G GPS
      23. OK
      ...ist es jetzt beängstigend, daß das GPS-Modul an ist?
      (eventuell ist aber auch nur der Port gemapped - beim Stick kann man Linux-/VxWorks-Konsole auf GPS&Bluetooth mappen)

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

      hefr54 schrieb:

      Naja, ein Stick vielleicht nicht
      ich meint damit, das es die selben Portconfigs gibt, wie bei einem Stick - inkl. virtueller CDRom, USB-Modeswitch, etc. und die Firmware ist eine 21er... (normalerweise: 21=>NonHiLink-Stick, 22=>HiLink-Stick, 23=>LTE-Router)
      Das ist übrigens die gleiche Versions-Nr., wie die Telekom-gebrandete mit IPv6 für den e3276 -- nur ohne Branding...
      (muß doch mal versuchen, die auf den e3276 zu bekommen)

      genevt schrieb:

      Ich denke man sollte AT^SYSCFGEX="03",3FFFFFFF,2,4,44,, empfehlen

      Jein... in meiner Gegend ist die 2600er so schwach, daß mein SPH mit 44 die 1800er vorzieht - aber die 2600er ist trotzdem leistungsfähiger in der Bandbreite.

      mfg, emkay

      eMKay77 schrieb:


      at^setport=?

      ^SETPORT:1: 3G MODEM
      ^SETPORT:2: 3G PCUI
      ^SETPORT:3: 3G DIAG
      ^SETPORT:5: 3G GPS
      ^SETPORT:A: BLUE TOOTH
      ^SETPORT:16: NCM
      ^SETPORT:6: GPS CONTROL
      ^SETPORT:A1: CDROM
      ^SETPORT:A2: SD
      ^SETPORT:10: 4G MODEM
      ^SETPORT:12: 4G PCUI
      ^SETPORT:13: 4G DIAG
      ^SETPORT:14: 4G GPS

      OK[/code]...ist es jetzt beängstigend, daß das GPS-Modul an ist?
      (eventuell ist aber auch nur der Port gemapped - beim Stick kann man Linux-/VxWorks-Konsole auf GPS&Bluetooth mappen)


      Irgednwie schon.. O.o aber lustig finde ich auch "^SETPORT:A: BLUE TOOTH" soll das heißen der SPH kann Bluetoth?


      Edit; Grade mal selbst getestet und da is mir direkt die verbindung abgeraucht..

      im syslog tauchte dann das hier auf

      Quellcode

      1. 2016-09-23 12:33:53: LTE Tunnelverbindung verloren (HA003)
      2. 2016-09-23 12:33:53: SIM nicht nutzbar in diesem Geraet (SI002)
      3. 2016-09-23 12:33:37: Funkzellen Info: server,,0,0,0 (LT004)
      4. 2016-09-23 12:33:27: Funkzellen Info: server,,0,-66,0 (LT004)


      Doridian schrieb:

      Die von der T/Huawei waren wohl zu faul, mehrere Flags zu bauen, also ist "Telnet" wohl einfach eine Art "Engineer-Mode" im Allgemeinen. Lustig.
      Ja das glaub' ich fast auch - ein allgemeiner Debug-Mode. Gut möglich, daß die inneren Schnittstellen bewusst erreichbar sind ;)
      Und gut möglich, daß es deshalb sogar sinnvoller war, daß sie das telnetd-Binary entfernt haben, statt das Flag.

      Jingoro schrieb:

      lustig finde ich auch "^SETPORT:A: BLUE TOOTH" soll das heißen der SPH kann Bluetoth?
      Edit; Grade mal selbst getestet und da is mir direkt die verbindung abgeraucht..
      AT^SETPORT ist einer der gefährlichsten AT-Befehle bei Huawei-Devices. Wenn Du den falschen Port deaktivierst, trennst Du die Verbindung, die Du zum Zurücksetzen oder Flashen brauchst...

      Vereinfachst gesagt, verdrahtet der Befehl die inneren Baugruppen des Moduls mit den IO-Schnittstellen. Dabei gibt es zwei Modi, einmal vor und einmal nach dem Modeswitch (im Befehl getrennt durch ein Semikolon). Der SPH hat vor dem Modeswitch ein FF, was den Modeswitch deaktiviert. (kann man auch bei einem USB-Stick so machen - vereinfacht die Nutzung teils erheblich ;) ) -- mit Modeswitch meldet sich das Modul/der Stick sonst meist erstmal als CD-Rom mit den Treibern und wird erst nach dem Switch zum Modem.

      Die beiden irritierenden Ports beim SPH sind die bzgl. GPS... allerdings ist die Namensgebung auf den Normalzustand bezogen - es gibt die undokumentierte Möglichkeit, die Ports intern anders zu mappen um an zusätzliche Funktionen zu kommen. Und wahrscheinlich wurde das hier auch gemacht. (man kann das Testen, indem man das 33. Feld im NVRam ausliest - dafür braucht man aber den Datalock-Code und ganz ungefährlich ist das nicht...)
      Bei meinem Stick hab' ich zB. 5 und A auf Linux- und VxWorks-Konsole gemappt... :D

      Streng genommen würde GPS wegen der Homezone zwar auch Sinn ergeben, aber dann müsste der SPH ja eher auf dem Balkon stehen ;)

      mfg, emkay

      EDIT: Hab' da jetzt 'ne schöneres Variante zum senden von Befehlen gefunden:

      Quellcode

      1. printf 'at^syscfgex?\r' | nc -w1 172.10.10.1 1280
      baut eine Verbindung auf, sendet den Befehl, gibt eventuelle Ausgaben aus (darunter können auch Zufällige von anderen Befehlen sein, welche der SPH selbst gesendet hat) und beendet die Verbindung mit IdleTimeOut von einer (Milli-?)Sekunde... 'nc' steht dabei für netcat, welches mittlerweile auch für Windows verfügbar ist. (die kurze Verbindung sollte vor dem Abbruch der LTE-Verbindung schützen...) --> Befehle, welche sehr lange brauchen (at+cops=? zB.) funktionieren mit so kurzem TimeOut allerdings nicht...
      nc kann auch einfach telnet ersetzen:

      Quellcode

      1. nc 172.10.10.1 1280
      baut ähnlich telnet eine Verbindung auf, allerdings entgegen telnet ist diese raw...

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

      Schnup89 schrieb:

      Kurz zum Verständnis für mich:
      Wenn das lte modul die datenverbindung aufgebaut hat, über welches Interface/Schnittstelle werden dann die Daten übertragen? (im allgemeinen bei lte sticks)
      Auch das ist bei Huaweis teilweise einstellbar, beim SPH ist das NCM-Interface aktiv, welches wohl auf den 3000er-Port gemappt ist.
      Steuerbefehle können teilweise outband über den PCUI- oder Modem-Port gesendet werden, oder inband direkt im NCM-Kanal. (unter Linux gibt's deshalb extra einen Huawei-Treiber, welcher diesen 'Inband-Channel' nach außen führt, weil manche Module/Sticks Steuerbefehle nur über NCM sauber annehmen. Man hat dann einmal 'wwan' für Daten und einmal 'cdc-wdm' für Steuerung)

      Im Moment tippe ich auf:
      1280 => Steuerung
      3000 => Datenkanal

      mfg, emkay

      hefr54 schrieb:

      Hat jemand eine Idee wie sich die Modell-Bezeichnung auf dem Stick ändern lässt? (Root ist vorhanden)
      Manufacturer: HUAWEI
      Model: Hybrid (SPH)
      Revision: 21.260.00.00.000
      IMEI: 86423002134xxxx
      +GCAP: +CGSM,+DS,+ES

      Manufacturer: huawei
      Model: E3272 (Stick)
      Revision: 22.491.09.00.00
      IMEI: 86750301333xxxx
      +GCAP: +CGSM,+DS,+ES
      Habe schon alles umgekrempelt aber noch nichts gefunden ;(

      Gruß hefr
      Das sind im Grunde die ersten Datenfelder im NVRAM des Sticks (auch SN, IMEI, etc. stehen dort - IMEI geht allerdings auch mit AT^CIMEI) - wenn Du den zu deiner IMEI passenden Datalock-Code hast (Achtung: solltest Du die IMEI ändern, ändert sich auch der Datalock-Code!), kannst Du auf die Datenfelder mit 'AT^NVRD' und 'AT^NVWR' zugreifen - allerdings mußt Du die Daten in Hex haben...
      Vielleicht interessant: 'AT&F' macht ne Art Werksreset - danach ist selbst die alte IMEI wieder da. (hab' den Befehl mal 'probiert' und durfte danach von vorn anfangen - Portkonfig, Shells, etc. alles weg ;) )

      mfg, emkay

      @hefr54: da ich grad' nich am Rechner war/bin, hatte ich nur Kurzform geschrieben - in der Hoffnung, daß Dir der Startpunkt reicht ;)

      Wie Du gesehen hast, gibt's 65536 Datenfelder (0-65535) unterschiedlicher Länge.

      Quellcode

      1. at^nvrd=<INDEX>
      zeigt das Feld mit Nr=<INDEX> an. Die erste Zahl in der Antwort ist der Index, die zweite ist die Länge, der Rest nach dem zweiten Komma sind die Daten in Hex-Notation.

      Quellcode

      1. at^nvwr=<INDEX>,<LÄNGE>,<B1> <B2> <B3> ...
      schreibt im Feld <INDEX> mit Länge <LÄNGE> die Bytes <B1> <B2> <B3> ...

      Die Länge geschriebener Daten darf kürzer sein, als das gesammte Feld. Man kann also 15 Bytes in ein 20er-Feld schreiben.

      Eine komplette Liste der Datensätze hab' ich nicht - nur einzelne (IMEI, SN, SHELL...) -- und die gerade nicht zur Hand. Aber schau Dir mal die ersten 10 Datenfelder an, da irgendwo sollten die für Dich interessanten sein.

      @xdjbx: man kann alle Felder lesen/schreiben - wenn man weiß, was sie bedeuten ist das recht mächtig - wenn nicht eher gefährlich ;)
      (auch SIMLOCK-Counter rücksetzen geht zB.)

      mfg, emkay