LTE-Sticks mit Hybrid SIM

      Stricted schrieb:

      eMKay77 schrieb:

      Sicher ist auch, daß im Android des LTE-Moduls ADB aktiv ist - soweit ich das sehen kann, auch über LAN.

      also auf den geöffneten ports ist nichts mit adb

      Quellcode

      1. E:\adb-tools>adb connect 127.10.10.1:3000
      2. unable to connect to 127.10.10.1:3000:3000
      4. E:\adb-tools>adb connect 127.10.10.1:20248
      5. unable to connect to 127.10.10.1:20248:20248
      7. E:\adb-tools>adb connect 127.10.10.1:1280
      8. unable to connect to 127.10.10.1:1280:1280
      10. E:\adb-tools>


      auch ein adb devices gibt nichts zurück
      Ich hab' ja auch nich gesagt, daß Du da drauf kommst - nur, daß ADB über LAN aktiv ist - weshalb die Chance hoch ist/war, daß einer der Ports ADB is.

      >>> Dein Test hätte aber doch auf 172.10.10.1 sein müssen?

      Naja, wie gesagt - bei mir (v3) scheinen die Ports eh zu.

      mfg, emkay

      EDIT: @hefr54: schon ein einzelner AT-Befehl würd' mir reichen...
      (evtl. geht's besser, wenn man vorher LTE über WebUI deaktiviert - dann hält sich der SPH vielleicht solange raus)

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

      eMKay77 schrieb:

      Ich hab' ja auch nich gesagt, daß Du da drauf kommst - nur, daß ADB über LAN aktiv ist - weshalb die Chance hoch ist/war, daß einer der Ports ADB is.

      wenn adb über lan aktiv ist müsste man ja auch drauf kommen

      eMKay77 schrieb:

      >>> Dein Test hätte aber doch auf 172.10.10.1 sein müssen?

      blöde tippfehler immer

      Quellcode

      1. ​
      2. E:\adb-tools>adb connect 172.10.10.1:1280
      3. connected to 172.10.10.1:1280
      5. E:\adb-tools>adb connect 172.10.10.1:3000
      6. connected to 172.10.10.1:3000
      8. E:\adb-tools>adb connect 172.10.10.1:20248
      9. connected to 172.10.10.1:20248
      11. E:\adb-tools>

      Quellcode

      1. E:\adb-tools>adb devices
      2. List of devices attached
      3. 172.10.10.1:20248 offline
      4. 172.10.10.1:3000 offline
      5. 172.10.10.1:1280 offline

      Quellcode

      1. ​
      2. E:\adb-tools>adb disconnect
      4. E:\adb-tools>adb devices
      5. List of devices attached
      7. E:\adb-tools>adb connect 172.10.10.1:1280
      8. connected to 172.10.10.1:1280
      10. E:\adb-tools>adb shell
      11. error: device offline
      13. E:\adb-tools>adb disconnect
      15. E:\adb-tools>adb connect 172.10.10.1:3000
      16. connected to 172.10.10.1:3000
      18. E:\adb-tools>adb shell
      19. error: device offline
      21. E:\adb-tools>adb disconnect
      23. E:\adb-tools>adb connect 172.10.10.1:20248
      24. connected to 172.10.10.1:20248
      26. E:\adb-tools>adb shell
      27. error: device offline
      29. E:\adb-tools>

      Ja, wobei die iptables bei mir für offen war für alle tcp ports.

      Neue Info:
      Sobald Werte auf dem SPH mit z.B.
      /bin/atcmd syscfg display
      geholt werden, und man in diesem Moment eine Verbindung auf Port 1280 zum Modem offen hat, gibts eine error:
      # atcmd syscfg display
      UNKNOWN ERROR

      Also sind die Werte die automatisch angezeigt werden auf Port 1280 wahrscheinlich von der Modem Firmware getriggert.

      hefr54 schrieb:

      Du bist nicht etwa auf LAN1? (ich denke du weißt das es da nicht geht)
      Mein Notebook ist zwar an LAN1, mein RasPi allerdings nicht... hab' allerdings zwischendurch auch umgesteckt - und auch per WLAN - nix...

      mfg, emkay

      EDIT: jetzt mal ganz doof --> ihr nutzt Windows, und das is weniger strikt? (oder setzt da irgendwo 'ne automatische Route?)
      (eigentlich dürfte das 'private' 172er ja nicht einfach so aus dem 'privaten' 192er-Netz erreichbar sein...)
      Ich hab bis jetzt nur Linux und Android (die meisten Tablets/Phones haben nen ADB-Client) getestet.

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

      @eMKay77 warum sollte die 172.10.10.1 nicht erreichbar sein? Der Client bekommst vom SP-H ein Default Gateway ... und dann forwarded er auch diese Pakete an dieses Netz, die Frage ist dann, ob in den IP-Tables der Traffic dahin geblockt ist.

      Quellcode

      1. ml0000002:~ dlucke$ ping 172.10.10.1
      2. PING 172.10.10.1 (172.10.10.1): 56 data bytes
      3. 64 bytes from 172.10.10.1: icmp_seq=0 ttl=62 time=3.290 ms
      4. ^C
      5. --- 172.10.10.1 ping statistics ---
      6. 1 packets transmitted, 1 packets received, 0.0% packet loss


      ...mein Mac kann das auch. Zwangsweise in der V3 unterwegs. ;o)

      Grüße

      danXde

      Schnup89 schrieb:

      Hat jemand tcpdump für den SPH kompiliert?

      ja, lade ich gleich auf die webdisk

      eMKay77 schrieb:

      EDIT: jetzt mal ganz doof --> ihr nutzt Windows, und das is weniger strikt? (oder setzt da irgendwo 'ne automatische Route?)
      (eigentlich dürfte das 'private' 172er ja nicht einfach so aus dem 'privaten' 192er-Netz erreichbar sein...)
      Ich hab bis jetzt nur Linux und Android (die meisten Tablets/Phones haben nen ADB-Client) getestet.

      mein banana pi kann verbinden (LAN2) mein windows rechner sieht die ports nichts (LAN1)

      @Striced: Danke für tcpdump.

      ATCMD schickt doch die Daten über IP :)
      Er nutzt den Rückkanal der TCP/55555 Verbindung, deswegen wird auch der SPH ungemütlich wenn man ihm diese Verbindung nimmt :D

      Hab mit die Kommandos beim ab und aufbau von LTE angesehen, und konnte folgende Kommunikations festhalten:

      Quellcode

      1. LTE Abgeschaltet im WebIF
      2. SPH-LTE: AT+CFUN=0
      3. LTE Eingeschaltet im WEbIF
      5. SPH->LTE: AT+CFUN=1
      7. SPH->LTE: AT+COPS?
      8. LTE->SPH: COPS: 0,2,"2601,7
      9. SPH->LTE: hybrid.telekom *99# telekom telekom 0 1
      11. **** FUNKSTILLE **** + ARP Request (Boot?)
      13. SPH->LTE: 58:2a:f7:c6:2e:36
      15. LTE->SPH: 2a01:59e:a081:f166:5a2c:80ff:fe13:92XX
      16. LTE->SPH: 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0,0.0.0.0 2a01:59e:a081:f166:5a2c:80ff:fe13:92XX 64
      17. LTE->SPH: fe80::c47e:70ff:fed8:XX
      18. LTE->SPH 2003:180:2:4000:0:2:0:53,2003:180:2:3000:0:2:0:53
      20. SPH->LTE: sub01-mic
      21. LTE->SPH: sub01-mic main-mic


      ​


      Das ist nur die Kommunikation auf dem 55555 Port, kein Arp kein nichts, deswegen haben mich die MAC-Adressen und IP's etwas verwundet :)

      Vielleicht kann ja einer von euch damit was anfangen.

      So - mit automatischer Konfiguration per DHCP und an LAN2 --> immer noch nix...
      Aber, ich dacht' mir dann, vielleicht wundert sich's Ubuntu ja auch ;)

      Und im Syslog steht (mehrfach):

      Quellcode

      1. Sep 22 03:32:33 emkay-Aspire-7741 NetworkManager[870]: <error> [1474507953.4173] platform-linux: do-add-ip4-route[2: 172.10.10.1/24 0]: failure 101 (Das Netzwerk ist nicht erreichbar)
      Ist also wohl ein Routingproblem, das mein Ubuntu 16.04 vielleicht etwas enger auslegt als Windows...

      Aber wie lege ich da jetzt 'ne passende Route an? Eine 172er-Route mit 192er-Gateway nimmt er nicht...
      Route auf dev eth?

      mfg, emkay

      EDIT: seh' jetzt erst --> die Log-Einträge sind schon etwas älter...

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