MCP2200 auf Ubuntu 24.04 LTS (Kernel 6.8)

Wie ich am 29. August geschrieben habe, hatte ich diverse Probleme mit „Ubuntu Server 24.04 LTS und HID Devices mit MCP2200 Chipsatz„.
Zwischenzeitlich war ich aber in der Lage das Problem weiter einzukreisen und zu Lösen.

Vermutung

Ende August gab es eine Erweiterung bei den Treibern im Linux Kernel. Folgende Diskussion habe ich hierzu gefunden: https://lore.kernel.org/lkml/202308180056.nB1KSUap-lkp@intel.com/T/.
Ende November ist es dann in den Quellcode eingeflossen: https://github.com/torvalds/linux/blob/master/drivers/hid/hid-mcp2200.c.

Diese Änderung floss dann vermutlich in Kernel 6.8, der mit Ubuntu 24.04 ausgeliefert wurde und dazu führte, dass das Relaisboard (USB Relay Module 4 Channels, for Home Automation – v2) der Firma Denkovi Assembly Electronics LTD, sobald as am USB Port angeschlossen wurde nun mit dem NEUEN Treiber versorgt wird und nicht mehr mit dem generischen HID Treiber.
Mit dem alten Treiber wurde im Devicetree von Linux das Gerät /dev/usb/hiddev0 angelegt. Das ist auch das Gerät, welches man in den Docker Container linken muss (--device=/dev/usb/hiddev0) damit das Relaisboard von dort aus angesprochen werden kann.

Das sieht man, wenn man sich den Ladevorgang via dmesg anschaut und vergleicht:

Ubuntu 22.04 dmesg

[ 2.437680] usb 1-2: new full-speed USB device number 2 using xhci_hcd
[ 2.591719] usb 1-2: New USB device found, idVendor=04d8, idProduct=00df, bcdDevice= 1.01
[ 2.591756] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2.591770] usb 1-2: Product: MCP2200 USB Serial Port Emulator
[ 2.591783] usb 1-2: Manufacturer: Microchip Technology Inc.
[ 2.591794] usb 1-2: SerialNumber: 0002460031
[ 2.884575] hid: raw HID events driver (C) Jiri Kosina
[ 2.889410] usbcore: registered new interface driver usbhid
[ 2.889425] usbhid: USB HID core driver
[ 2.893929] hid-generic 0003:04D8:00DF.0001: hiddev0,hidraw0: USB HID v1.11 Device [Microchip Technology Inc. MCP2200 USB Serial Port Emulator] on usb-0000:00:15.0-2/input2

Ubuntu 24.04 dmesg

[ 184.330464] usb 1-2: new full-speed USB device number 3 using ohci-pci
[ 184.857213] usb 1-2: New USB device found, idVendor=04d8, idProduct=00df, bcdDevice= 1.01
[ 184.857220] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 184.857221] usb 1-2: Product: MCP2200 USB Serial Port Emulator
[ 184.857223] usb 1-2: Manufacturer: Microchip Technology Inc.
[ 184.857224] usb 1-2: SerialNumber: 0001693160
[ 184.877118] hid-generic 0003:04D8:00DF.0002: hiddev0,hidraw1: USB HID v1.11 Device [Microchip Technology Inc. MCP2200 USB Serial Port Emulator] on usb-0000:00:06.0-2/input2
[ 184.901800] mcp2200 0003:04D8:00DF.0002: USB HID v1.11 Device [Microchip Technology Inc. MCP2200 USB Serial Port Emulator] on usb-0000:00:06.0-2/input2
[ 184.906240] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[ 184.906268] usbcore: registered new interface driver cdc_acm
[ 184.906270] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
[ 448.466402] usb 1-2: USB disconnect, device number 3
[ 457.088963] usb 1-2: new full-speed USB device number 4 using ohci-pci
[ 457.624849] usb 1-2: New USB device found, idVendor=04d8, idProduct=00df, bcdDevice= 1.01
[ 457.624855] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 457.624857] usb 1-2: Product: MCP2200 USB Serial Port Emulator
[ 457.624858] usb 1-2: Manufacturer: Microchip Technology Inc.
[ 457.624860] usb 1-2: SerialNumber: 0001693160
[ 457.636478] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[ 457.661624] mcp2200 0003:04D8:00DF.0003: USB HID v1.11 Device [Microchip Technology Inc. MCP2200 USB Serial Port Emulator] on usb-0000:00:06.0-2/input2

Schnelle Lösung

Es mag hier vermutlich eine elegante Lösung geben, aber die quick ’n‘ dirty Variante ist, den MCP2200 Kernel Treiber zu deaktivieren.

Eine temporäre Aktivierung (zum Testen) macht man mit dem Befehl:

modprobe -r hid_mcp2200

Die permanente Deaktivierung erfolgt dann, indem man einen Blacklist Eintrag in der Datei: „/etc/modprobe.d/blacklist.conf“ vornimmt:

# The MCP2200 kernel driver doesn't support the "USB Relay Module 4 Channels,
# for Home Automation – v2" from "Denkovi Assembly Electronics LTD".
# if the /dev/usb/hiddev* device is missing, you need to deactivate the kernel
# driver to fallback to the generic HID kernel driver.
blacklist hid_mcp2200

ACS Containerisierung

Wir sind aktuell dabei unsere Fenster im Haus zu tauschen, was dazu führte, dass wir die Wand am eingangsbereich neu machen mussten (Holz weg, richtig dämmen, verputzen, streichen).
Da wir von Anfang an den RFID Leser im Eingangsbereich nur „provisorisch“ installiert haben, habe ich mir nun ein schickes Edelstahlgehäuse anfertigen lassen.

Lesereinbau vorher/nachher

Der Leser war wärend der Zeit der Renovierung leider offline.

Reboot mit Problemen

Der Server für das Zugangskontrollsystem ist das Letzte Artefakt, das ich noch nicht Containerisiert habe. Ich habe zwar dran gearbeitete, aber es gab hier noch diverse Probleme und die Integrationstests haben letztlich auch gefehlt. Ich wollte dies in aller Ruhe im sommerurlaub mal angehen. einen alten gebrauchten Testrechner habe ich dafür auch schon installiert gehabt, aber zu diesem Zeitpunkt war das System nicht einsatzbereit.

Auf dem alten Rechner den Docker zum Laufen bringen klappt nicht, da das darunterliegende OS (Ubuntu 16.04 LTS) zu alt war für die Java Requirements. D.b. ich muss den Server komplett neu aufsetzen und ein „Schwenk“ zu einem Container wäre nicht so schnell machbar gewesen. Wäre aber wünschenswert, dann hätte man den Container einfach hin und her schieben können um den Server in Ruhe auf den neuesten Stand updaten zu können.

Aber da der Rechner ja eh schon unten war (aufgrund der Renovierungsarbeiten) wollte ich zumindest mal ein OS Update fahren um die ganzen aktuell anstehenden Patches in Ubuntu 16.04 LTS nachzuziehen. Dabei kam dann der Rechner nach dem Reboot nicht wieder hoch. Scheinbar hat nach der langen Uptime der Rechner (den LESv2 der Thomas Krenn AG) den Reboot nicht verkraftet. Fakt ist, es kommt kein Bild, keine Ausgabe, nichts.

Tja, da half dann nur noch Flucht nach vorne. Ich habe den kleinen alten Testrechner ein Intel NUC) in den Serverschrank gepackt und frisch das OS draufgepackt. Erst ein Ubuntu Server 24.04 LTS, und, aufgrund von Betriebsproblemen (siehe unten), einen Tag später ein Ubuntu Server 22.04 LTS.
Danach binnen 2 Tagen den ACS-Server als Container so fertig bekommen, dass er läuft und alle Funktionalitäten wieder abdeckt (Mail, Pushover, MQTT, Relais ansteuern).
Zwischenzeitlich läuft der Server sogar nicht priviligiert als NonRoot im readonly Modus, das war schon seit Anfang an ein Problem, dass ich aber im Laufe der letzten Tage lösen konnte.

Ubuntu Server 24.04 LTS und HID Devices mit MCP2200 Chipsatz

Ubuntu Server 24.04 LTS ist das aktuelle Ubuntu Betriebssystem. Daher war es naheliegend dieses auch zu verwenden. Ich verwende für das Öffnen der Türe aktuell ein per USB angeschlossenes Relaisboard (USB Relay Module 4 Channels, for Home Automation – v2) der Firma Denkovi Assembly Electronics LTD. Das Board verwendet einen MCP2200 Chip und gibt sich als HiD Device aus. In der Regel wird im Linux unter den Devices dann ein /dev/hidraw0 und ein /dev/usb/hiddev0 angelegt. Leider funktionierte das nur bis Ubuntu Server 22.04 LTS. In Ubuntu Server 24.04 LTS hat sich das System strikt geweigert das Relais so anzulegen wie ich es erwartet hätte. Leider habe ich nach 1 Tag udev Regeln anlegen dann aufgegeben und bin auf Ubuntu Server 22.04 LTS gegangen.

Das Verhalten muss ich bei Zeiten mal genauer untersuchen bzw. wenn es mir hier nicht gelingt eine Lösung zu finden eine Relais Alternative zu suchen. Denkovi hat hier ja diverse alternative Möglichkeiten. Ggf. switche ich ja zu einer IP basierten Lösung.

ACS Komponenten im Container

Es laufen alle Komponenten des Zugangskontrollsystems nun auf einem Container. Damit werden Migrationsszenarien deutlich einfacher werden. Die Java Komponenten laufen in einem Debian Basiscontainer mit JRE21. Alle anderen Komponenten basieren auf schlanken Alpine Basiscontainern.

Alle Container sind mit Trivy sicherheitsüberprüft. Alle erkannten Vulnerabilities werden im Buildprozess dann entsprechend behandelt.

KomponenteBasisStand
ACS ServerDebian + JRE21Containerisiert
ACS ManagerAlpine + Nginx + PHP 8.1Containerisiert
ACS Tag ManagerDebian + JRE21Containerisiert
ACS Pushover ServiceAlpine + Python 3.11Containerisiert
REDISAlpineContainerisiert
LDAPAlpineContainerisiert
MQTTAlpineContainerisiert
ACS, Stand der Containerisierung

Offene Punkte

  1. Hausinterne DNS Probleme in den Griff bekommen: Entweder die Namensauflösung im ACS Server anpassen (herkömmlich statt den Ubunt Standard mit resolverd) oder, da es ein generelles Problem ist, hier mal eine echte Lösung finden.
  2. Erhöhung der RFID Leser Sensitivität, durch Durchbrechen des Faradayschen Käfigs. Leider schirmt der Edelstahlkasten die elektromagnetische Strahlung sehr ab. Ich versuche heute mla mit der Flex den Käfig mit einem Schnitt zu unterbrechen.
  3. RFID Leser mit Ubuntu Server 24.04 LTS ans Laufen bringen (siehe oben).

Zugangskontrollsystem Version 2

Auslöser

Das System lief sauber durch, der Watchdog den ich entwicklet hatte, hat auch seine Arbeit getan. Als wir in Urlaub gingen hatten wir unseren Nachbarn ebenfalls Transponder gegeben. Das System funktionierte bis 3 Tage vor unserer Rückkehr aus den USA.

Seitdem verliert der Server die Verbindung zum Leser. Was auch immer geschah oder wie auch immer es geschah konnte ich bislang nicht ermitteln. Auch lässt sich der Javaprozess nicht mehr starten ohne dass der Prozess sich gleich wieder beendet.

Nun all das hat mich nun bewogen darüber nachzudenken die Plattform zu wechseln.

Plattformwechsel für Version 2

Der proof of concept aus Version 1 war durchaus erfolgreich. Allerdings bin ich mit der Lösung auf dem Raspberry 1 nicht so ganz zufrieden. Folgende Gründe sprechen für einen Plattformwechsel:

  • Die Firma FEIG ELECTRONIC GmbH unterstützt aktuell nur den Raspberry 1 (ARMv6) alle Bemühungen, die ARMv7 Treiber auf dem Raspberry 2 zum Laufen zu bringen, scheiterten bislang.
  • Die Raspberry Treiber (ARMv6) haben bis heute keine Möglichkeit verschlüsselt mit dem Leser zu kommunizieren. Der Bug wurde bereits 2015 gemeldet. Bislang gibt es hier allerdings keine Lösung.
  • Der Raspberry 1 hat leider nur 512 MB Ram, dies hat von Anfang an zu Engpässen geführt.
  • Es gibt beim Raspberry bekannte Probleme mit längeren Laufzeiten, wenn das Betriebssystem auf einer SD-Karte liegt. Das ist zwar schick, aber SD-Karten sind ja für häufige Schreibzyklen nicht ausgelegt.
  • Um Filesystemcrashes bei Stromausfall vorzubeugen kommt die PiUSV zum einsatz. Die Firma CW2 hat allerdings Konkurs angemeldet was bedeutet man müsste sich hier nach einer Alternative umsehen.
  • Das Gehäuse für den Server ist custom made. Ein professionelles, maßgeschneidertes Gehäuse erstellen zu lassen ist relativ teuer (im Vergleich zu den restlichen Komponenten)
  • Die bislang verwendeten Komponenten (PiUSV und PiFaceDigital2) sind sehr Raspberry spezifisch.

Das scheinbar größte Problem für mich war eine vernünftige Alternative für das Relayboard (PiFace) zu finden. Es sollte möglichst Betriebssystem unabhängig sein und mit Java ansteuerbar sein.

Nach einigen recherchen wurde ich bei der Bulgarischen Firma Denkovi Assembly Electronics LTD fündig. Ich entschied mich für das Produkt: USB Four(4) Relay Output Module,Board for Home Automation v2 und orderte dies.
Der Versandt ging zügig und problemlos. Die mitgelieferten Tools funktionierten problemlos unter Windows. Allerdings gab es aktuell keine Beispiele für Java. Ich kontaktierte die Firma und bekam 2 Tage später ein Beispielpaket für Java, welches ich zerlegte und die für mich interessanten Bestandteile herauslöste.
Aktuell habe ich nun eine eigene Java Bibliothek erstellt, mit der ich das Relayboard steuern kann.

Nun brauche ich noch einen neuen Server, der folgende Eigenschaften haben sollte:

  • Passiv gekühlt
  • Klein und stromsparend
  • x86 Technologie (um ein „normales“ Linux darauf laufen zu lassen)
  • richtige Festplatte
  • 2 Ethernet Schnittstellen (um das Lesernetz und das Administrationsnetz zu trennen)
  • mind. 2 USB Ports besser 4
  • passendes Gehäuse

Ich habe mich für den „Low Energy Server v2“ (LESv2) der Firma Thomas-Krenn.AG entschieden. Den Server werde ich noch diese Woche bestellen.

Ich werde über die Entwicklung weiter in diesem Blog berichten.