Virtueller COM Port, AT commands

[Oliver R. (Gast)]

Hallo,

ich habe einen virtuellen COM Port auf einem STM32 eingerichtet, der 
prinzipiell auch funktioniert. Sobald ich den Controller mit dem Host 
(Linux) verbinde, sendet der Rechner bei der Initialisierung eine Reihe 
von AT-Befehlen, auf die er wohl auch eine entsprechende Antwort 
erwartet.

Wie ist damit am besten umzugehen? Einfaches Ignorieren führt zu einem 
relativ langem Timeout (ca. 10 Sekunden) bevor z.B. screen als Terminal 
aufgerufen werden kann, was natürlich nervt.

[g457 (Gast)]

> 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 M. (turboj)]

Hört sich nach einem Modem Manager oder ähnlichem an. Welche 
Distribution ist das?

[Oliver R. (Gast)]

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

Aktuelle Linux Mint.

[Oliver R. (Gast)]

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?

[Frank K. (fchk)]

Oliver R. schrieb:
> 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?

Möglicherweise ist einer der USB Descriptoren in Deinem Device falsch.

Siehe http://www.usb.org/developers/devclass_docs/usbcdc11.pdf
und dort Kapitel 4 und 5 ab Seite 39. In den Descriptoren teilt das 
Device mit, was es ist: Modem, ISDN, ... und ob es AT-Befehle kann und 
etliches mehr.

fchk

[Oliver R. (Gast)]

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

    struct __attribute__((packed)) CdcCommunicationInterfaceDescriptor {
        uint8_t     bLength             = sizeof(CdcCommunicationInterfaceDescriptor);
        uint8_t     bDescriptorType     = 0x04;     // Interface
        uint8_t     bInterfaceNumber    = 0;
        uint8_t     bAlternateSetting   = 0;
        uint8_t     bNumEndpoints       = 1;
        uint8_t     bInterfaceClass     = 0x02;     // CDC
        uint8_t     bInterfaceSubclass  = 0x02;     // Abstract control mode
        uint8_t     bInterfaceProtocol  = 0x01;     // Common AT commands
        uint8_t     iInterface          = 0;
    };

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

[Frank K. (fchk)]

Oliver R. schrieb:

> Allerdings ändert sich nichts, wenn ich bInterfaceProtocol = 0 setze.

Hmm, sollte aber. Vielleicht ist hier der Wurm drin.

Mist, ich habe gerade keinen MCP2200 zur Hand, um nachzuschauen, wie der 
sich anmeldet.

fchk

[Oliver R. (Gast)]

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.

[g457 (Gast)]

> 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.

[Oliver R. (Gast)]

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

[g457 (Gast)]

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.

[Oliver R. (Gast)]

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.

[g457 (Gast)]

> 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.

[Oliver R. (Gast)]

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

[g457 (Gast)]

> 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.