LTE-Sticks mit Hybrid SIM

      Ja und Nein.
      Ziel des ganzen ist ja immer noch die "Abschaffung" des Hybrid-Routers, da dieser als Internet-Connector und Router fungiert.
      In dem Falle würde man den SPH nur als LTE-Modem nutzen, und könnte die Hybrid-Verbindung mit eigener Hardware aufbauen, um herauszufinden ob das laufen würde.
      Im zweiten Step könnte man dann versuchen die SIM über ein LTE-Stick zum laufen zu bringen.

      Stricted schrieb:

      xdjbx schrieb:

      Mal einen Portscan gemacht auf die 172er IP ? :D

      lustig, genau das hatte ich nach meinem post gestartet

      Quellcode

      1. ​
      2. root@bananapi:~# nmap -p- 172.10.10.1
      4. Starting Nmap 6.47 ( http://nmap.org ) at 2016-09-17 07:31 CEST
      5. Nmap scan report for 172.10.10.1
      6. Host is up (0.0017s latency).
      7. Not shown: 65532 filtered ports
      8. PORT STATE SERVICE
      9. 1280/tcp open unknown
      10. 3000/tcp open ppp
      11. 20248/tcp open unknown
      13. Nmap done: 1 IP address (1 host up) scanned in 2313.81 seconds

      Bei mir:

      Quellcode

      1. emkay@emkay-Aspire-7741:~$ nmap -p- 172.10.10.1
      3. Starting Nmap 7.01 ( https://nmap.org ) at 2016-09-21 14:35 CEST
      4. Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
      5. Nmap done: 1 IP address (0 hosts up) scanned in 3.04 seconds
      --> scheint wohl gefiltert zu sein bei der v3 :(

      mfg, emkay

      eMKay77 schrieb:

      hab' ich schon - allerdings ging's bei @Stricted ja auch mit -p- ...

      grad nachgeschaut
      ich lasse am sph allgemein icmp zu deswegen geht auch der ping
      um genau zu sein habe ich diese iptables regeln hinzugefügt

      Quellcode

      1. ​
      2. /bin/iptables -D INPUT_FIREWALL ! -i br0 -p all -j DROP
      3. /bin/iptables -A INPUT_FIREWALL ! -i br0 -p icmp -j ACCEPT
      4. /bin/iptables -A INPUT_FIREWALL -p 41 -j ACCEPT
      5. /bin/iptables -A INPUT_FIREWALL ! -i br0 -p all -j DROP

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

      xdjbx schrieb:

      machst du das mit Windows ? Vielleicht musst du noch die Route zum sph IP hinzufügen ?

      muss ich unter windows nicht
      die route scheint also bekannt

      Quellcode

      1. ​
      2. C:\Users\Terra>ping 172.10.10.1
      4. Ping wird ausgeführt für 172.10.10.1 mit 32 Bytes Daten:
      5. Antwort von 172.10.10.1: Bytes=32 Zeit=1ms TTL=63
      6. Antwort von 172.10.10.1: Bytes=32 Zeit<1ms TTL=63
      7. Antwort von 172.10.10.1: Bytes=32 Zeit<1ms TTL=63
      8. Antwort von 172.10.10.1: Bytes=32 Zeit=1ms TTL=63
      10. Ping-Statistik für 172.10.10.1:
      11. Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
      12. (0% Verlust),
      13. Ca. Zeitangaben in Millisek.:
      14. Minimum = 0ms, Maximum = 1ms, Mittelwert = 0ms

      und er benutzt linux/ubuntu

      Aktuell gehe ich davon aus, dass der SPH nur Informationen per IP-Verbindung (TCP/55555) abfrägt.
      Bei einem Auf/Abbau des LTE werden dort nur die Standard abfragen LTEZelle, SIM Status, PIN etc. abgefragt.
      Da netstat keine weitere Kommunikation per IP mit dem LTE Modul offenbart, gehe ich davon aus, dass der SPH seine Kommandos per USB an das Modem schickt.


      ... Vielleicht wisst ihr das aber schon, wollte nur mal meine Erkenntnisse mitteilen :)

      Schnup89 schrieb:

      Da netstat keine weitere Kommunikation per IP mit dem LTE Modul offenbart, gehe ich davon aus, dass der SPH seine Kommandos per USB an das Modem schickt.

      würde irgendwie keinen sinn machen
      wenn er ja schon eine usb verbindung hat wozu dann noch zusätzlich mittels ip socket kommunizieren?

      edit:

      Quellcode

      1. ​
      2. root@sph ~ # busybox-mips stty -F /dev/ttyUSB0 115200 cs8 -cstopb -parenb
      3. stty: can't open '/dev/ttyUSB0': No such device or address
      4. root@sph ~ # busybox-mips stty -F /dev/ttyUSB1 115200 cs8 -cstopb -parenb
      5. stty: can't open '/dev/ttyUSB1': No such device or address
      6. root@sph ~ # busybox-mips stty -F /dev/ttyUSB2 115200 cs8 -cstopb -parenb
      7. stty: can't open '/dev/ttyUSB2': No such device or address
      8. root@sph ~ # busybox-mips stty -F /dev/ttyUSB3 115200 cs8 -cstopb -parenb
      9. stty: can't open '/dev/ttyUSB3': No such device or address

      keine usb verbindung

      @Schnup89: naja - sicher ist, das für AT-Kommandos eine Client/Server-System genutzt wird. (damit mehrere Prozesse konkurrierend mit dem LTE-Modul kommunizieren können)
      ---> das könnt' zwar auch per USB/Serial/GPIO erfolgen - TCP/IP ist aber wahrscheinlicher. (und deine Beobachtungen auf Port 1280 passen dazu)

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

      Ich frag' mich nur immernoch, warum mein SPH den Zugriff blockt - und eure nicht...

      mfg, emkay

      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

      Okay.
      Ich bleibe mal bei der IP-Verbindung vom Modem.

      Der SPH scheint keine IP-Verbindung ZU dem Modem aufzubauen.
      Der SPH hört auf Verbindungen auf Port 55555.

      Das Modem baut aktiv die Verbindung zum SPH 172.10.10.10 Port 5555 auf und schickt dort seine LTE Infos (SIM status, CellID, etc.).
      Beweis:
      netstat -t
      tcp 0 0 172.10.10.10:55555 172.10.10.1:45035 ESTABLISHED

      HigherPort (45035) ist der Source-Port also ist 55555 die Destination.
      Gegencheck: Destination NAT mit iptables eingerichtet.
      Alle Anfragen von 172.10.10.1 an 172.10.10.10 umgeleitet auf mein PC.
      Siehe da, mein PC bekommt die Anfrage vom Modem, wird aber direkt wieder abgebaut, da das Modem wahrscheinlich eine spezielle Antwort erwartet, bevor es daten schickt.

      Nun mal nachschauen welcher Prozess den Port 55555 geöffnet hat:
      ss -p
      172.10.10.10:55555 172.10.10.1:45035 users:(("mic",366,14))

      mic - den prozess gibt es also mal mit strace drangehängt:
      Da kommen dann die LTE Infos:
      AT^SYSINFO
      AT^LCELLINFO
      AT^CPIN?


      Hoffe ich hab jetzt, vorallem mit strace keinen Fehler in meinem Denkweise.
      Bin mit jetzt nur nicht sicher ob die Kommands über den Rückkanal 55555 zum Modem gesendet werden, oder ob die Kommandos ggf. über Serial/USB/etc. übertragen werden und per IP (ggf. aus Komfortgründen) an den SPH gesendet werden.

      ich krieg über cat /proc/bus/usb/devices nur ein

      ​T: Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2
      B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0
      D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
      P: Vendor=1d6b ProdID=0001 Rev= 3.04
      S: Manufacturer=Linux 3.4.11-rt19+ ohci_hcd
      S: Product=OHCI Host Controller
      S: SerialNumber=0000:00:09.0
      C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
      I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
      E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms

      T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 2
      B: Alloc= 0/800 us ( 0%), #Int= 0, #Iso= 0
      D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
      P: Vendor=1d6b ProdID=0002 Rev= 3.04
      S: Manufacturer=Linux 3.4.11-rt19+ ehci_hcd
      S: Product=EHCI Host Controller
      S: SerialNumber=0000:00:0a.0
      C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
      I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
      E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms