Suchergebnisse

Alles ok, tcpdump neu starten bis es wieder kommt dann müsste man die hybrid aushandlung verfolgen können

Wie in der shoutbox erwähnt binary übertragung nutzen. Bei mir hat die version von der webdisk funktioniert

Die pakete zu loggen ist nicht schwer. Tcpdump -n -i *interface* -w /mnt/*deinusbstick*/meincapture.pcap *interface* mit z.b rmnet0 ersetzen und das ganze bei einer einwahl, z.b nach/während einem atcmd : at^reset kommando. Dann kommt der schwierige teil mit wireshark: Dhcp pakete studieren/filtern und sonstige pakete finden welche mit dem hybrid-prozess zusammenhängen. Gruß aus Menorca

Per tcpdump auf dem sph müsste man alles was vor dem gre tunnel passiert miloggen können. Darin könnte man auch sehen ob der hybrid-server per dhcp kommt oder ggf. Mit einer http-anfrage eingelesen wird. Das kann ich gerne mal mitloggen, jedoch erst nächsten Montag

Supergeil, dann sind wir einen schritt weiter Bin aber gerade verreist und komme erst nächste woche dazu. Dann sollte ich mir so langsam mal ein raspberry + lte stick zulegen

Ok, dann kann's noch nicht funktionieren. @xdjbx Die Ports sind leider nicht erreichbar. # /etc/busybox-mips nc -w3 172.10.10.1 20253 nc: timed out # # /etc/busybox-mips nc -w3 172.10.10.1 20240 nc: timed out #

# /etc/busybox-mips printf 'at^nvrd=53810\r' | /etc/busybox-mips nc -w3 172.10.10.1 1280 ERROR # Mag er nicht... Hab mal alle Pakete auf Port 55555 nach einem AT^RESET mitgeloggt und ausgewertet. Der SPH scheint abzuwarten, bis er die IP-Infos vom LTE-MODEM bekommt. Ich glaube ohne die LTE-Modem Firmware kommen wir nicht weiter, ggf. sind dort die "Telekom Hybrid LTE Login" Funktionen programmiert.

Wer ein bisschen mit den AT-Kommandos spielen möchte und sich an den Meldungen stört: at^curc=0 Damit sind die "Statusmeldungen" vom LTE-Modem abgeschaltet. Danach mit at^curc=1 wieder einschalten.

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)

route add -net 172.10.10.0 netmask 255.255.255.0 gw 192.168.2.1 [Optional] dev eth01 edit: müsste aber mit ner default-route auf 192.168.2.1 ohne speziellen routingeintrag funktionieren

@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 Hab mit die Kommandos beim ab und aufbau von LTE angesehen, und konnte folgende Kommunikations festhalten: Quellcode (21 Zeilen) Zitat: „​“ 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 da…

Das Ding geht mir tierisch auf'n Sack (ich entschuldige mich ) Gestern die halbe Nacht mit strace versucht den Kommunikationsweg von atcmd herauszufinden -> Nichts. Schickt per IOCTL ein paar Daten auf B38400, nur finde ich das blöde ttyXXX nicht Ich glaube immer noch nicht, dass atcmd per IP auf's Modem zugreift Hat jemand tcpdump für den SPH kompiliert?

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.

@eMKay77 Kannst du im Engineer-Menü die Firmware des LTE-Moduls herauslesen? Vielleicht hast du eine neuere welche ggf. die Zugriffe aus anderen Netzen blockiert.

ok, danke, schade

busybox-mips stty -F /dev/ttyS0 115200 cs8 -cstopb -parenb mit dem könnte es funktionieren...

Schaut mal nach: # cat /proc/consoles ttyS0 -W- (EC p ) 4:64 ttyS0 -> Hab grad keine busybox-mips drauf, gibts da ein Output?

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 …

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

Wo könnte ich die hybridsock.c finden? strace: write(1, "FILE: hybridsock.c FUNC: HybridSockGetNextAvp LINE: 1079: ucType is 255\n", 72)