Virtueller COM Port, AT commands

> Wie ist damit am besten umzugehen?

dmesg oder /var/log/messages konsultieren und den Übeltöter artgerecht 
dem Sondermüll zuführen (gute Kandidaten: Unbedachte Aufrufe von z.B. 
mtp-probe oder usb_modeswitch verursachen regelmäßig solche und ähnliche 
Probleme).

Jim Meba schrieb:
> Hört sich nach einem Modem Manager oder ähnlichem an. Welche
> Distribution ist das?

Aktuelle Linux Mint.

dmesg gibt folgendes aus:

[10210.024266] cdc_acm 4-2.2:1.0: This device cannot do calls on its 
own. It is not a modem.
[10210.024296] cdc_acm 4-2.2:1.0: ttyACM0: USB ACM device

Es ist also kein Dienst sondern ein Kernel-Treiber. Sollte man eher 
versuchen, dem Host die Initialisierung abzugewöhnen oder muss sich das 
Device wie ein Modem verhalten und die Anfragen entsprechend 
beantworten?

Übernommen habe ich die Deskriptordaten aus der ST 
Beispielimplementierung und richtig, der Wert für bInterfaceProtocol 
aktiviert die AT-Befehle.

1

    struct __attribute__((packed)) CdcCommunicationInterfaceDescriptor {

2

        uint8_t     bLength             = sizeof(CdcCommunicationInterfaceDescriptor);

3

        uint8_t     bDescriptorType     = 0x04;     // Interface

4

        uint8_t     bInterfaceNumber    = 0;

5

        uint8_t     bAlternateSetting   = 0;

6

        uint8_t     bNumEndpoints       = 1;

7

        uint8_t     bInterfaceClass     = 0x02;     // CDC

8

        uint8_t     bInterfaceSubclass  = 0x02;     // Abstract control mode

9

        uint8_t     bInterfaceProtocol  = 0x01;     // Common AT commands

10

        uint8_t     iInterface          = 0;

11

    };

Allerdings ändert sich nichts, wenn ich bInterfaceProtocol = 0 setze. 
Bei bInterfaceProtocol = 0xFF (vendor-specific) wird das Device nicht 
mehr richtig erkannt.

Ich habe mal einen Blick in die Sources des Moduls geworfen:

https://kernel.googlesource.com/pub/scm/linux/kernel/git/cmarinas/linux-aarch64/+/83a4eae9aeed4a69e89e323a105e653ae06e7c1f/drivers/usb/class/cdc-acm.c

Wirklich schlau werde ich daraus allerdings nicht. An irgendeiner Stelle 
müsste doch zu erkennen sein, was das Senden der AT-Befehle auslöst.

> An irgendeiner Stelle müsste doch zu erkennen sein, was das Senden der
> AT-Befehle auslöst.

Nicht der cdc-acm. Schau mal ins dmesg und/oder /var/log/messages (u.U. 
auch /var/log/debug oder /var/log/syslog), wer da Müll rumschickt. Wenn 
das nichts hilft protokollier mit, welche Prozesse das Gerät direkt nach 
dem Registrieren aufmachen.

g457 schrieb:

> Nicht der cdc-acm. Schau mal ins dmesg und/oder /var/log/messages (u.U.
> auch /var/log/debug oder /var/log/syslog), wer da Müll rumschickt. Wenn
> das nichts hilft protokollier mit, welche Prozesse das Gerät direkt nach
> dem Registrieren aufmachen.

Ok, /var/log/messages zeigt schon mehr an:

Aug 30 18:28:19 duke kernel: [23785.240472] cdc_acm 4-1.2:1.0: This 
device cannot do calls on its own. It is not a modem.
Aug 30 18:28:19 duke kernel: [23785.240510] cdc_acm 4-1.2:1.0: ttyACM0: 
USB ACM device
Aug 30 18:28:19 duke mtp-probe: checking bus 4, device 24: 
"/sys/devices/pci0000:00/0000:00:1d.2/usb4/4-1/4-1.2"
Aug 30 18:28:19 duke mtp-probe: bus: 4, device: 24 was not an MTP device
Aug 30 18:28:35 duke ModemManager[770]: <info>  Creating modem with 
plugin 'Generic' and '1' ports
Aug 30 18:28:35 duke ModemManager[770]: <warn>  Could not grab port 
(tty/ttyACM0): 'Cannot add port 'tty/ttyACM0', unhandled serial type'
Aug 30 18:28:35 duke ModemManager[770]: <warn>  Couldn't create modem 
for device at '/sys/devices/pci0000:00/0000:00:1d.2/usb4/4-1/4-1.2': 
Failed to find primary AT port

ModemManager klingt vielversprechend. Führ diesen mal dem angedachten 
Bestimmungszweck zu (i.e. plattmachen). Wenn das nichts hilft ist der 
mtp-probe der nächste Kandidat.

Der ModemManager kommt laut Log erst in Spiel, nachdem der 15s Timeout 
abgelaufen ist. mtp-probe gehört wohl zu udev, das sollte man vermutlich 
nicht einfach plattmachen.

> das sollte man vermutlich nicht einfach plattmachen.

Wieso nicht? Plattmachen heisst..
- Paket deinstallieren (geht häufig)
- den kaputten Automatismus deaktivieren (geht meistens)
- ..oder auf die Schwarze Liste setzen (geht manchmal)
- das zu unrecht kaputtgespielte Gerät auf die schwarze Liste des 
kaputten Automatismus setzen (geht manchmal)

Bis hierer ist alles voll offiziell. Wenns nicht hilft kann man auf 
eigene Gefahr auch weiter gehen, muss man aber nur sehr selten.

HTH und nix für ungut.

Gut, kann man alles machen. Mein ursprünglicher Gedanke war allerdings, 
es plattformübergreifend ohne großes Gefummel benutzen zu können.

> Mein ursprünglicher Gedanke war allerdings, es plattformübergreifend ohne
> großes Gefummel benutzen zu können.

Dann musst Du die Firmware so aufbohren, dass sie mit beliebigem(!) 
Datenmüll umgehen kann, z.B. über ein anständig abgesichertes (ggf. 
eigenes) Protokoll.