[mcc]

Moin in die Runde,

noch ein bischen was zu den FTDIs und Linux...

Nach ein bischen "Suchmaschinemassage" zeigte sich, dass für gaqngige Distributionen
"should work out of the box" angegeben ist. FTDI hat wohl Linux die Treiber in Quellcodeform zur Verfügung gestellt.

Wie testet man, ob es funtkioniert?
Man bootet sein Linux OHNE das FTDI-Kabel/Adapter einzustecken.
Dann auf der Kommandozeile
ls -rtl /dev/ > /tmp/devvorher.txt
und
sudo lsusb -v > /tmp/lsusb.vorher.txt

Dann steckert man das Kabel/den Adapter in seine Linux-Box und macht das nocheinmal:
ls -rtl /dev/ > /tmp/devnachher.txt
und
sudo lsusb > /tmp/lsusb.nachher.txt

Dann:
diff /tmp/devvorher.txt /tmp/devnachher.txt
und
diff /tmp/lsusb.vorher.txt /tmp/lsusb.nachher.txt

Als Unterschiede müssten in etwa (das unterscheidet sich von Linux zu Linux etwas und von FTDI-Kabel zu FTDI-Kabel) sowas rauskommen (das Datum ist
natürlich anders...und auch die Gruppenzugehörigkeit kann abweichen)
Für das Device unterhalb von /dev/.
crw-rw-rw- 1 root plugdev 254, 0 2019-04-01 19:38 gpiochip0
crw-rw-rw- 1 root plugdev 188, 0 2019-04-01 19:38 ttyUSB0

und für die Ausgabe von lsusb:

Bus 007 Device 004: ID 0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) IC

Hier weichen Bus-ID und die Chipbezeichnung (FT232) möglicherweise ab.
Jupp...die Firma hat eng mit der Dokumentarfilmreihe "Back to the Future" zusammengearbeitet...aus dieser Zeit stammt auch der Firmenname

Die Kernelmodule, die bei mir für den Adapter angezogen werden, sind:
ftdi_sio 53248 0
usbserial 32768 1 ftdi_sio

wobei "ftdi_sio" der Treiber für die Kontaktaufnahme zum FTDI-Chip ist und usbserial der generische Kerneltreiber ist, der ein serielles USB-Device zur Verfügung stellt.

HTH!
Cheers!
mcc

[mcc]

Moin, moin in die Runde,

Wenn wieder Erwarten die FTDI-Chips durch den Kernel einer Distribution nicht bereitgestellt werden, muss man selber ran...

Zu erklären, wie man im Allgemeinen einen Linux-Kernel konfiguriert, ist im Netz erklärt und hängt auch immer etwas
von der aktuell eingesetzten Distribution ab. Generell kann man aber sagen, dass das Kernelkonfigurieren und Selberkompilieren nur dann aussehen mag, wie "deep hack mode" und "Linux Magie", wenn man es noch nie gemacht
hat. In Wirklichkeit ist der ganze Vorgang WEIT WENIGER kompliziert und "gefährlich", als es den Anschein hat.
Wenn man immer einen funktionierenden Kernel und seine unveränderten Sourcen/Koniguration beibehält und den zweiten sowohl was die Sourcen/Konfiguration als auch den eigentlichen Kernel zusätzlich erzeugt und als Wahlmöglichkeit in den Bootloader einbindet, ist das Schlimmste, was einem passieren kann meiner Meinung nach ein Reboot in vorherigen, unveränderten Kernel (jedenfalls ist mir seit Kernel 1.02 nichts Anderes passiert... )

Dennoch auch hier der Reclaimer: FÜR DIE DIREKTEN UND INDIREKTN FOLGEN AUS DER ANWENDUNG DES HIER BESCHRIEBENEN ÜBERNEHME ICH KEINE VERANTWORTUNG!

Was braucht man zum Kernel-Backen?
Man benötigt die Kernel-Quellen und deren Konfiguration genau in der Form, wie sie aktuell im eigenen Linux eingesetzt werden. Hier sind in erster Linie diejenigen die erste Bezugsquelle, die die Distribution bereitstellen, die man gerade benutzt.
Weiterhin brauch man eine Compilier-Suite. Das dürfte in den allermeisten Fällen entweder gcc oder clang sein. Auch hier bitte die Distribution konsultieren.

Danach bitte entsprechend "Wie konfiguriere/kompiliere/installiere ich einen Lixnus-Kernel" (oder so ähnlich) aus der Anleitung der Distribution vorgehen und einen zweiten Kernel erzeugen -- mit genau der gleichen Konfiguration, wie er bereits vorhanden ist. Bootet und arbeitet dieser Kernel ohne Zicken hat man es geschafft: "A kernel was born!"

FTDI-Chips konfigurieren:
Man geht vom Root des Kernel-Konfigurationstools hierhin
-> Device Drivers
-> USB support (USB_SUPPORT [=y])
-> USB Serial Converter support (USB_SERIAL [=m])
Und aktiviert "USB FTDI Port Serial driver" entweder als Modul, welches beim Einstecken des Konverters geladen wird oder gleich direkt in den Kernel hinein. Ich plädiere für die zweite Möglichkeit, da man sich bei der ersten Möglichkeit eventuell noch mit der Erkenn-und-Lade-Mimik von Kernelmodulen herumschlagen muss.
Ich gehe davon aus, dass der ganze USB-Unterbau bereits fertig konfiguriert ist, da es sich hierbei um eine sehr weit verbreitete Technologie handelt.
Desweiteren muss man "USB Serial Converter support" anknipsen.
Dann nach Anleitung die neue Konfig abspeichern (von der Alten hat man ja vorher ein Backup gemacht ... ) und den Kernel nach Anleitung kompilieren und installieren.
Dann in den neuen Kernel booten und das FTDI-Kabel anstecken und mit lsusb und ls -rtl /dev prüfen, ob der Chip erkannt wurde.

Hallali!
Das Ganze ist wie Schuhe zubinden: Schriftlich erklärt ist das sprachlicher Drahtverhau....hat man es einmal gemacht, denkt man..."Und? War das schon Alles?"...

Viel Erfolg beim Kernelbacken und "NOKIA tieferlegen"

Cheers!
mcc

[mcc]

Moin moin in die Runde,

ein kleiner Fund am Rande...

Wenn man den NetMonitor aktiviert hat, befindet sich auf Seite 11 die Anzeige der Daten, die vom Mobilfunknetz
benötigt werden, damit man geortet werden kann.
Nein, nicht notwendigerweise NSA, CIA, BYE & TSCHAU...sondern das Netz muss dass wissen, sonst müssten ALLE
Sendemasten mit max. Power senden, um den Teilnehmer IRGENDWO zu erreichen...was natürlich technisch eine
echte Griff in die Sattelitenschüssel wäre.

Dort findet man:
MCC> Den Mobile Country Code: In welchen Land bin ich gerade eigentlich?
MNC> Den Mobile Network Code: Welcher Provider/welches Netzwerk beglückt mich gerade?
LAC> Den Local Area Code: Wo befinde ich mich im engeren Sinne (aber immer noch recht weiträumig...meistens)
CH> Die Kanalnummer: Sowas wie die aktuelle Sendefrequenz
CID> Die Cell ID: In welcher Funkzelle bin ich gerade (das ist schon recht genau).

Aus all diesen Daten kann man recht genau (GPS spielt da aber immer noch in einer völlig anderen Liga) bestimmen,
wo man gerade ist.....wenn man die Daten in GPS-Koordinaten umsetzen kann.

Ahaber: Wo openstreetmaps das Google Maps für Freidenker ist ist opencellid.org das Mekka für Handyenthusiasten.
Anmeldung notwendig, aber völlig kostenfrei und easy. Man bekommt eine API-Nummer (Hexstring) mit EMail
zugesandt. Damit kann man sich einloggen UND DEN GESAMTEN DATENSATZ ALLER SENDEMASTEN/ZELLEN ETC, DIE
OPENCELLID BEKANNT SIND HERUNTERLADEN!!! WARUM ICH DAS ALLES IN GROSSBUCHSTABEN SCHREIBE?....weiß ich auch gerade nicht...mir war nur danach, weil ich opencellid.org für eine gute Sache halte.

Cheers!
mcc

[mcc]

Moin,

und weiter geht's.

Irgendwie stehe ich gerade etwas im Dunkeln....

Grundsätzlich gilt beim Netzmonitor, dass nichts aktiviert/deaktiviert/verstellt wird, wenn man die Seiten des Netzmonitors mit den Cursortasten durchblättert. Viele Seiten sind auch nur zum Lesen gedacht und nicht zum
Einstellen.

Möchte man über eine hierfür vorgesehene Seite etwas ändern, muss diese direkt über das NetMonitor-Eingangs"menu" (hüstel) anspringen...

Nun denn:
Mit Seite 45 kann man den "Transmitter disable"n - also die Sendestufe des Handys ausschalten. Das ist prima zum Testen von Sendemastenlogik um zu probieren, wie sie sich verhalten, sollte ein Handy zwar etwas empfangen, aber plötzlich nicht mehr senden. Gleiches gilt natürlich in umgekehrter Richtung für die Firmware des Handys.
Ich dachte mir: "Ok, schalteste den Sender ab, sparste Strom und keeener kann Dir tracken..." ....dachte ich mir.

Nur seltsamerweise konnte ich trotz abgeschalteter Sendestufe mittels *100# meinen Kontostand abfragen.

Hmmmm.....entweder ich verstehe den sehr elaboriert formulierten Begriff aus der deutschen Literaturgeschichte, der da lautet "Sender aus!", falsch -- was mich angesichts seiner Kürze allerdings hinlänglich unwahrscheinlich und bis an die Grenzen des Absurden dem Unlogischen geweiht erscheint...oder der Krempel funzzt nicht, Alder! (Eyh!)

Ich wäre durchaus der Begeisterung zugeneigt, wenn einer der Forumsgötter herbeieilen könnte und kraft seiner Weisheit und Erleuchtung mir ein wenig Erkenntnis einschönke...

(Nur um allen Mißverständnissen vorzubeugen...dies ist INS KEINSTER WEISE als "spitz formulierte Aufforderung" gemeint...mir macht das Herumgedrechsele an der Sprache halt einfach nur Spass...vor allen an Stellen, wo sie stilmäßig eigentlich so überhaupt nicht passt! Halali!)

[ExiTus]? Irgendeine Idee, warum das nicht den Specs gehorchen will...oder was habe ich das nun gerade falsch verstanden?

Cheers!
mcc

[[ExiTuS]]

Danke erst einmal für die ausführliche Beschreibung zum Kabel, den Treibern und allem was dazu gehört! Großartig

Ja ja, der Net Monitor, eine Spielwiese für große Kinder
Er gibt eine Menge interessanter Details preis.

Zu Display 45:
Ich gehe ebenfalls davon aus, dass die Sendestufe tatsächlich deaktiviert ist, wenn sie deaktiviert wurde

Ich könnte mir vorstellen, dass du durch deinen "Anruf" explizit die Stufe wieder aktiviert hast, weil es eine manuelle Aktion war.
Um die "Funkstille" sicherzustellen, würde ich die Stufe deaktivieren und andere Displays im Auge behalten...
z.b. die aktuelle Serving Cell (Nachbarzellen sind hier egal) - da dürfte sich nach einem Spaziergang auf der Autobahn nichts mehr tun, d.h. kein Handover in eine andere BTS/Funkzelle.
Und auch ein PLU (also das Telefon meldet sich regelmäßig im Netz, um zu signalisieren, dass es noch aktiv ist) dürfte nicht stattfinden. Ein PLU findet i.d.R. zwischen 6 und 60 Minuten statt.
In Display 10 gibt es hilfreiche Daten zu TMSI und PLU (T321: Counter/Timeout) und Display 11 zur aktuellen Zelle.

Es gibt sicher einige Displays irgendwelchen weiteren Tx Countern. Diese müssten auch in Stillstand geraten.

Schöne Grüße
[EXiTuS]

[mcc]

Moin ExiTus,

vielen Dank für Deine Unterstützung...aber leider "bad news" von meiner Seite...:

Auf dem Weg vom Bahnhof in meine Butze bin ich wie folgt vorgegangen:
-- Am Bahnhof stehenbleiben
-- Nokia an
-- Pin eingeben
-- NetMonitor aufrufen
-- "Gehen Sie direkt nach 45, ziehe keine viertausend Daten von 11 ein, gehe direkt dorthin"
-- Es wird "Transmitter disabled" angezeigt
-- "Gehe jetzt doch zu 11 und ziehe viertausend Daten ein..."
-- und dann: Loslaufen....
...und siehe da: Die CID ändert sich. Und wenn ich Dich richtig verstanden habe, sollte das nicht geschehen...

Hmmmm....

Das mit den Timern muss ich mir noch mal ansehen...

Schönen Abend noch!
Cheers!
mcc

[mcc]

Moin moin in die Runde,

ich bin......verblüfft....mindestens.....sehr verblüfft!

Ich wollte mir einmal ansehen, was gammu mit meinem NOKIA 3310
so redet und habe mir 'interceptty' compiliert und installiert.
Dann habe ich quasi eine Kette gebildet:
NOKIA<--->Serial.USB.Converter<--->Linux.Kernel<--->
/dev/ttyUSB0<--->intercepttty(logfile)<--->/tmp/ttyUSB0<--->gammu

interceptty erzeugt ein zweites (um das schöne Donald-Wort zu nutzen) FAKE device, auf dem gammu arbeitet und leitet allen traffic an und von dem eigentlichen /dev/ttyUSB0 'rüber. Damit bekommt als "Man in the middle" den Traffic mit und kopiert ihn in ein logfile.
Soweit so schön...die Theorie.

Mit "gammu identify" purzeln auch schön die Daten ins logfile.
Mit "gammu nokianetmonitor 243" wird zwar der Netzmonitor gesetzt....aber ich sehe nicht ein einziges Byte vom Datenstrom.

WAS geht hier gerade ab? Ist ein NOKIA 3310 vielleicht doch flach und nicht rund?
"Flat Nokia" sozusagen? Und die Landung des Netmonitors hat nie stattgefunden?
Wo ist mein Aluhütchen?

Ich glaube das muss warten bis zum Wochenende....das verstehe ich heute abend nicht mehr...

Cheers!
mcc

[mcc]

Moin moin in die Runde,

also die Funktion von Seite 45 "Transmitter disabled" scheint bei meinem NOKIA 3310 nicht zu funktionieren.
Die Firmware ist v5.57 vom 05-07-02.

Ich habe heute meinen "Transmitter disabled" und anschließend einen Kollegen
gebeten, mir erst eine SMS zu schicken und mich dann anzurufen. Beides funktionierte
anstandslos.

Einen "Field test" zum Test von ausgefallenen Transmittern stelle ich mir irgendwie
anders vor...

Nun denn....es gibt noch andere Seiten im NetMonitor :/

Cheers!
mcc

[mcc]

(GRRRMPPPF! Das ganze nochmal! Login-Timeout...die ganze Nachricht weg! DANKE! )

Moin moin in die Runde,

also nochmal von vorne...

...ausgeschlafen und mit genügend Kaffee im Kopf kann ich auch wieder vernünftige Datenverkehrsmitschnitte hinbekommen.

Alles hier beschriebene findet unter Linux statt. Alle eingesetzten Programme sind OpenSource. Man benötigt das Programm gammu und interceptty (es wird zusätzlich interceptty-nicedump mit installiert...dazu gleich mehr).

Ersteinmal muss .gammurc angepasst werden. Meines sieht nun so aus:
[gammu]
port = /tmp/ttyUSB0
connection = fbus
logformat = nothing
use_locking = yes
name=

Ich habe mein .gammurc für diesen Zweck umbenannt nach .gammurc.sniff

/tmp/ttyUSB0 ist ein Device, welches von interceptty angelegt wird. Es klemmt sich quasi zwischen das Device /dev/ttyUSB0, welches durch den FTDI-Adapter erzeugt wird und /tmp/ttyUSB0, das gammu liest und beschreibt.

Und bevor jetzt der Timeout wieder zuschlägt....Fortsetzung folgt....

[mcc]

...Fortsetzung...

Es schaufelt den gesamten Datenverkehr zwischen den beiden Devices hin und her und spielt dabei den klassischen "Man in the Middle"-Attack...nur dass das eben kein "Attack" ist...sondern schlichte technische Neugierde.

Gleichzeitig schreibt interceptty die Daten in eine Datei.

Die Kommandozeile für interceptty lautet:
sudo interceptty -s 'ispeed 115200 ospeed 115200' /dev/ttyUSB0 /tmp/ttyUSB0 | intercept-nicedump > serial.trace.netmonitor.txt

Danach wird gammu mit

gammu -c .gammurc.sniff nokianetmonitor 243

gestartet.

Die enstandenen Daten sehen so aus:
[PRE]< 55 55 55 55 55 55 55 55 55 55 | UUUUUUUUUU
< 55 55 55 55 55 55 55 55 55 55 | UUUUUUUUUU
< 55 55 55 55 55 55 55 55 55 55 | UUUUUUUUUU
< 55 55 c1 55 55 55 55 55 55 55 | UU UUUUUUU
< 55 55 55 55 55 55 55 55 55 55 | UUUUUUUUUU
< 55 55 55 55 55 55 55 55 55 55 | UUUUUUUUUU
< 55 55 55 55 55 55 55 55 55 55 | UUUUUUUUUU
< 55 55 55 55 55 55 55 55 55 55 | UUUUUUUUUU
< 55 55 55 55 55 55 55 55 55 55 | UUUUUUUUUU
< 55 55 55 55 55 55 55 55 55 55 | UUUUUUUUUU
< 55 55 55 55 55 55 55 55 55 55 | UUUUUUUUUU
< 55 55 55 55 55 55 55 55 55 55 | UUUUUUUUUU
< 55 55 55 55 55 55 55 55 55 55 | UUUUUUUUUU
< 55 55 55 55 55 55 55 55 55 55 | UUUUUUUUUU
< 55 55 55 55 55 55 55 55 55 55 | UUUUUUUUUU
< 55 55 55 55 55 55 55 55 55 55 | UUUUUUUUUU
< 55 55 55 55 55 55 55 55 55 55 | UUUUUUUUUU
< 55 55 55 55 55 55 55 55 55 55 | UUUUUUUUUU
< 55 55 55 55 55 55 55 55 55 55 | UUUUUUUUUU
< 55 55 55 55 55 55 55 55 55 55 | UUUUUUUUUU
< 55 55 55 55 55 55 55 55 55 55 | UUUUUUUUUU
< 55 55 55 55 55 55 55 55 55 55 | UUUUUUUUUU
< 55 55 55 55 55 55 55 55 55 55 | UUUUUUUUUU
< 55 55 55 55 55 55 55 55 55 55 | UUUUUUUUUU
< 55 55 55 55 55 55 55 55 55 55 | UUUUUUUUUU
< 55 55 55 55 55 55 55 55 55 55 | UUUUUUUUUU
< 55 55 55 55 55 55 55 55 55 55 | UUUUUUUUUU
< 55 55 55 55 55 55 55 55 55 55 | UUUUUUUUUU
< 55 55 55 1e 00 0c d1 00 07 00 | UUU
< 01 00 03 00 01 40 00 52 d5 | @ R
> 1e 0c 00 7f 00 02 d1 00 cf 71 | q
> 1e 0c 00 d2 00 26 01 00 00 03 | &
> 56 20 30 35 2e 35 37 0a | V 05.57
> 30 35 2d 30 37 2d 30 32 0a | 05-07-02
> 4e 48 4d 2d 35 0a | NHM-5
> 28 63 29 20 4e 4d 50 2e 00 01 | © NMP.
> 41 3a a9 | A:
< 1e 00 0c 7f 00 02 d2 01 c0 7c | |
< 1e 00 0c 05 00 09 00 01 00 13 |
< 01 00 1e 01 41 00 4c 1f | A L
> 1e 0c 00 7f 00 02 05 01 1b 70 | p
> 1e 0c 00 05 00 0e 01 08 00 14 |
> 01 ff 1e 04 10 32 00 32 01 42 | 2 2 B
> 11 a2 |
< 1e 00 0c 7f 00 02 05 02 17 7f |
< 1e 00 0c 40 00 06 00 01 64 01 | @ d
< 01 42 77 04 | Bw
> 1e 0c 00 7f 00 02 40 02 5e 73 | @ ^s
> 1e 0c 00 40 00 0e 01 01 64 03 | @ d
> 01 4f 0d 01 01 01 1b 58 01 43 | O X C
> 6c 14 | l
< 1e 00 0c 7f 00 02 40 03 52 7e | @ R~
< 1e 00 0c 40 00 06 00 01 7e f3 | @ ~
< 01 43 6d f7 | Cm
> 1e 0c 00 7f 00 02 40 03 5e 72 | @ ^r
> 1e 0c 00 40 00 3a 01 01 7e 00 | @ : ~
> 00 01 64 03 01 4f 0d 01 01 01 | d O
> 1b 58 01 43 30 33 0a | X C03
> 4e 48 4d 2d 35 0a | NHM-5
> 28 63 29 20 4e 4d 50 2e 00 00 | © NMP.
> 00 00 00 00 8c 00 11 70 74 ff | pt
> ff ff ff ff ff ff ff 00 00 01 |
> 44 16 96 | D
< 1e 00 0c 7f 00 02 40 04 52 79 | @ Ry[/PRE]

Dabei sind Zeilen mit "<" Daten die gammu sendet und Zeilen mit ">" Daten die das NOKIA 3310 sendet.

Schönes Wochenende und viel Spass beim Stöbern!
Cheers!
mcc