/dev/ttyUSB1 na herstart verdwenen

[hufkes]

Op mijn Synology gebruik ik een Sl.aesh cc2652rb stick, deze is correct geflashed en heeft ook tijden gewerkt maar sinds een update met herstart van de NAS krijg ik hem niet meer aan de praat.

Het probleem lijkt te zitten in het nu compleet ontbreken van de dev/ttyUSB0 waar deze voorheen netjes naar de USB stick verwees, krijg ik het nu niet meer voor elkaar.

De stick wordt wel gezien en is in de interface van DSM7 ook onder info aanwezig en lijkt daar correct herkend.

code:

USB Device: CP210x UART Bridg - Silicon Labs

code:

hufkes@LocoCollectio:/volume1/homes/hufkes$ lsusb
|__usb1          1d6b:0002:0404 09  2.00  480MBit/s 0mA 1IF  (Linux 4.4.180+ xhci-hcd xHCI Host Controller 0000:00:15.0) hub
  |__1-1         10c4:ea60:0100 00  1.10   12MBit/s 100mA 1IF  (Silicon Labs slae.sh cc2652rb stick - slaesh's iot stuff 00_12_4B_00_23_90_D9_F2)
  |__1-4         f400:f400:0100 00  2.00  480MBit/s 200mA 1IF  (Synology DiskStation ***)
|__usb2          1d6b:0003:0404 09  3.00 5000MBit/s 0mA 1IF  (Linux 4.4.180+ xhci-hcd xHCI Host Controller 0000:00:15.0) hub

Drivers zijn aanwezig en in mijn startup script heb ik het volgende staan:

code:

hufkes@LocoCollectio:/volume1/homes/hufkes$ sudo cat /usr/local/etc/rc.d/start-usb-drivers.sh
case $1 in
  start)
    insmod /lib/modules/usbserial.ko > /dev/null 2>&1
    insmod /lib/modules/cp210x.ko > /dev/null 2>&1
    insmod /lib/modules/ch341.ko > /dev/null 2>&1
    ;;
  stop)
    exit 0
    ;;
  *)
    exit 1
    ;;
esac

Script is executable, lijkt ook gedraaid te zijn, maar weet zo niet waar ik dit terug kan vinden. Als ik hem nogmaals vanuit de shell aanroep krijg ik in ieder geval geen errors, maar ook niet het gewenste resultaat.

Dmesg geeft me de volgende meldingen over de usb, de laatste regels is de reactie op unpluggen. Er wordt dus wel degelijk iets herkend.

code:

hufkes@LocoCollectio:/volume1/homes/hufkes$ dmesg | grep usb
[   36.651210] usbcore: registered new interface driver usbfs
[   36.657359] usbcore: registered new interface driver hub
[   36.663342] usbcore: registered new interface driver ethub
[   36.669491] usbcore: registered new device driver usb
[   37.175511] usb usb2: We don't know the algorithms for LPM for this host, disabling LPM.
[   37.483540] usb 1-1: new full-speed USB device number 2 using xhci_hcd
[   37.750521] usb 1-4: new high-speed USB device number 3 using xhci_hcd
[   54.227854] usb-storage 1-4:1.0: USB Mass Storage device detected
[   54.228062] scsi host6: usb-storage 1-4:1.0
[   54.228153] usbcore: registered new interface driver usb-storage
[   54.991847] systemd[1]: Starting Mount usb fs...
[   55.725093] usbcore: registered new interface driver usblp
[   55.752978] usbcore: registered new interface driver usbhid
[   55.759211] usbhid: USB HID core driver
[  154.284198] usbcore: registered new interface driver usbserial
[  154.851687] usbcore: registered new interface driver ftdi_sio
[  154.858148] usbserial: USB Serial support registered for FTDI USB Serial Device
[  154.879978] usbcore: registered new interface driver cdc_acm
[46995.745948] usb 1-1: USB disconnect, device number 2
[47001.821497] usb 1-1: new full-speed USB device number 4 using xhci_hcd
[47521.683771] usb 1-1: USB disconnect, device number 4
[47533.633316] usb 1-1: new full-speed USB device number 5 using xhci_hcd

/dev/ttyUSB0 is dus geheel verdwenen na restart en wordt zoals gezegd ook niet meer aangemaakt:

code:

hufkes@LocoCollectio:/volume1/homes/hufkes$ ls /dev/ttyU*
ls: cannot access '/dev/ttyU*': No such file or directory

Moet ik soms die /dev/ttyUSB0 dan zelf nog aanmaken? Zo ja hoe en wanneer dan precies en waarom maakte hij het eerst wel zelf? Ik kom in google dingen tegen als

code:

sudo mknod /dev/ttyUSB0 c 188 0

en dan lijkt inderdaad een verwijzing naar het device aangemaakt te worden, maar ik zie ook opmerkingen dat mknod oud en niet nodig zou zijn, dat het device eigenlijk automatisch gemaakt zou moeten worden? En hoe weet ik of die settings van MAJOR en MINOR correct zijn, wat betekenen die 188 en die 0 eigenlijk? De help van mknod geeft me niet veel houvast, er wordt hiermee blijkbaar alleen een unbuffered special file aangemaakt met die naam en settings, maar ook daarna opnieuw draaien van de insmod commando's zorgt niet voor de juiste koppeling...

Mijn docker container met zigbee2mqtt krijgt er in ieder geval op deze manier nog geen connectie mee..

code:

Zigbee2MQTT:info  2021-11-03 11:01:10: Starting zigbee-herdsman (0.13.164)
Zigbee2MQTT:error 2021-11-03 11:01:10: Error while starting zigbee-herdsman
Zigbee2MQTT:error 2021-11-03 11:01:10: Failed to start zigbee
Zigbee2MQTT:error 2021-11-03 11:01:10: Exiting...
Zigbee2MQTT:error 2021-11-03 11:01:10: Error: Error while opening serialport 'Error: Error: No such device or address, cannot open /dev/ttyUSB0'

Iemand een idee, ik vergeet vast iets heel simpels maar kom met mijn beperkte linux kennis niet verder.

[BoAC]

Misschien geeft je script wel errors, maar het script dumpt alle errors naar /dev/null

Die mknod hoeft je niet uit te voeren, dat doet udev wel voor je verwacht ik

Je kunt controleren met lsmod of je drivers wel geladen zijn die je verwacht.

[hufkes]

BoAC schreef op woensdag 3 november 2021 @ 11:52:
Misschien geeft je script wel errors, maar het script dumpt alle errors naar /dev/null

Ja dat zie ik, maar die heb ik ook wel eens weggehaald maar weet gewoon niet waar hij dan tijdens de startup die eventuele errors naartoe zou schrijven.. Als ik nadien vanuit ssh de insmod commando's herhaal, geeft dit keurig de errormelding dat het bestand al bestaat.

code:

hufkes@LocoCollectio:/volume1/homes/hufkes$ sudo insmod /lib/modules/usbserial.ko
insmod: ERROR: could not insert module /lib/modules/usbserial.ko: File exists

Die mknod hoeft je niet uit te voeren, dat doet udev wel voor je verwacht ik
Je kunt controleren met lsmod of je drivers wel geladen zijn die je verwacht.

Dat dacht ik ook begrepen te hebben, maar gebeurt dus om de een of andere reden nog niet.

Drivers lijken dus met mijn beperkte kennis geladen te zijn, maar hier de relevante output van lsmod:

code:

hufkes@LocoCollectio:/volume1/homes/hufkes$ lsmod | grep 'ftdi\|usb\|serial\|cp210'
ftdi_sio               38372  0
usbserial              21209  1 ftdi_sio
usbhid                 25951  0
hid                    87850  2 hid_generic,usbhid
usblp                  10810  0
usb_storage            49145  0
usbcore               199863  12 etxhci_hcd,usblp,uhci_hcd,usb_storage,usbserial,ehci_hcd,ehci_pci,usbhid,ftdi_sio,cdc_acm,xhci_hcd,xhci_pci
usb_common              2829  1 usbcore

[ Voor 25% gewijzigd door hufkes op 03-11-2021 12:03 ]

[Shakespeare2000]

Was de update 'binnen' DSM 7? Of van 6 naar 7?
In het geval van de laatste: misschien helpt dit je verder.

[hufkes]

Nee was een update van dsm7 zelf, DSM 7.0.1-42218.
De nas is vrij nieuwe en de update naar 7 heb ik als eerste gedaan toen ik hem kreeg. Daarna heeft alles dus gewerkt tot gisteren.

[me1299]

Ik denk dat Shakespeare2000 het bij het juiste eind heeft.

[hufkes]

me1299 schreef op woensdag 3 november 2021 @ 12:17:
Ik denk dat Shakespeare2000 het bij het juiste eind heeft.

Geloof dat ik niet precies snap wat je hiermee bedoelt, de link waar hij naar verwijst doet het alleen wanneer de drivers aanwezig zijn en doet m.i vrijwel hetzelfde als wat ik in het opstart script heb staan. Verder schrijft Marius ook duidelijk dat bij een herstart je het script opnieuw moet draaien, dat voldoet voor mijn situatie eigenlijk niet aangezien is uiteraard graag mijn HA weer terug heb na een eventuele herstart.

De statements die in dat script staan, komen m.i. overeen met wat ik doe, alleen een chmod op een /dev/ttyUSB0 die niet bestaat heeft geen effect natuurlijk.

--

Op dit moment lijkt het alsof ik het euvel heb gevonden, aan de hand van een heel ander topic werd ik op het pad gezet van een misschien niet out of the box snappen wat voor stick het is.
Ik heb daarom de vendorID en productID toegevoegd aan /sys/bus/usb-serial/drivers/ftdi_sio/new_id

Deze gegevens kun je halen uit de output van lsusb:

code:

 |__1-1         10c4:ea60:0100 00  1.10   12MBit/s 100mA 1IF  (Silicon Labs slae.sh cc2652rb stick - slaesh's iot stuff 00_12_4B_00_23_90_D9_F2)

De 10c4 is vID, de ea60 is het pID, middels een sudo vi van dat bestand op de eerste regel gezet gescheiden door een spatie, dus niet de : zoals in de output van lsusb.

Nadat ik deze had toegevoegd en opnieuw opgestart heb, lijkt alles wél automatisch weer bij te komen

Relevante output van dmesg nu als volgt:

code:

hufkes@LocoCollectio:~$ dmesg | grep 'usb\|serial\|cp210\|xhci'
[    0.000000] Command line: 
[   33.652634] usbcore: registered new interface driver usbfs
[   33.658787] usbcore: registered new interface driver hub
[   33.664772] usbcore: registered new interface driver ethub
[   33.670920] usbcore: registered new device driver usb
[   33.695825] xhci_hcd 0000:00:15.0: xHCI Host Controller
[   33.702747] xhci_hcd 0000:00:15.0: new USB bus registered, assigned bus number 1
[   33.912151] xhci_hcd 0000:00:15.0: hcc params 0x200077c1 hci version 0x100 quirks 0x00009010
[   33.921580] xhci_hcd 0000:00:15.0: cache line size of 64 is not supported
[   34.162792] xhci_hcd 0000:00:15.0: xHCI Host Controller
[   34.168647] xhci_hcd 0000:00:15.0: new USB bus registered, assigned bus number 2
[   34.176992] usb usb2: We don't know the algorithms for LPM for this host, disabling LPM.
[   34.484761] usb 1-1: new full-speed USB device number 2 using xhci_hcd
[   34.751788] usb 1-4: new high-speed USB device number 3 using xhci_hcd
[   50.971252] systemd[1]: Created slice system-serial\x2dgetty.slice.
[   50.984077] systemd[1]: Starting system-serial\x2dgetty.slice.
[   51.727062] usb-storage 1-4:1.0: USB Mass Storage device detected
[   51.727205] scsi host6: usb-storage 1-4:1.0
[   51.727296] usbcore: registered new interface driver usb-storage
[   52.400059] systemd[1]: Starting Mount usb fs...
[   53.198329] usbcore: registered new interface driver usblp
[   53.243662] usbcore: registered new interface driver usbhid
[   53.249916] usbhid: USB HID core driver
[  152.580417] usbcore: registered new interface driver usbserial
[  152.606909] cp210x: module verification failed: signature and/or required key missing - tainting kernel
[  152.617821] usbcore: registered new interface driver cp210x
[  152.624100] usbserial: USB Serial support registered for cp210x
[  152.630805] cp210x 1-1:1.0: cp210x converter detected
[  152.636654] usb 1-1: cp210x converter now attached to ttyUSB0
[  153.373323] usbcore: registered new interface driver ftdi_sio
[  153.379823] usbserial: USB Serial support registered for FTDI USB Serial Device
[  153.479234] usbcore: registered new interface driver cdc_acm

De melding

code:

[  152.606909] cp210x: module verification failed: signature and/or required key missing - tainting kernel

snap ik niet, iemand nog een idee?

Verder blijkt nu ook het desbetreffende bestand na herstarten weer leeg te zijn, ik weet niet wat hij precies gedaan heeft, maar zelfs na meerdere keren opnieuw starten komt de stick braaf terug. Het lijkt dus alsof eenmalig zo'n item in new_id zetten wel een blijvend effect heeft. Uitleg over die new_id suggereert m.i. dat het bestand de nieuwe ID's moet blijven bevatten, maar goed.

code:

What:       /sys/bus/usb/drivers/.../new_id
Date:       October 2011
Contact:    [e-mail]
Description:
        Writing a device ID to this file will attempt to
        dynamically add a new device ID to a USB device driver.
        This may allow the driver to support more hardware than
        was included in the driver's static device ID support
        table at compile time. The format for the device ID is:
        idVendor idProduct bInterfaceClass RefIdVendor RefIdProduct
        The vendor ID and device ID fields are required, the
        rest is optional. The `Ref*` tuple can be used to tell the
        driver to use the same driver_data for the new device as
        it is used for the reference device.
        Upon successfully adding an ID, the driver will probe
        for the device and attempt to bind to it.  For example::

          # echo "8086 10f5" > /sys/bus/usb/drivers/foo/new_id

        Here add a new device (0458:7045) using driver_data from
        an already supported device (0458:704c)::

          # echo "0458 7045 0 0458 704c" > /sys/bus/usb/drivers/foo/new_id

        Reading from this file will list all dynamically added
        device IDs in the same format, with one entry per
        line. For example::

          # cat /sys/bus/usb/drivers/foo/new_id
          8086 10f5
          dead beef 06
          f00d cafe

        The list will be truncated at PAGE_SIZE bytes due to
        sysfs restrictions.

What:       /sys/bus/usb-serial/drivers/.../new_id
Date:       October 2011
Contact:    [e-mail]
Description:
        For serial USB drivers, this attribute appears under the
        extra bus folder "usb-serial" in sysfs; apart from that
        difference, all descriptions from the entry
        "/sys/bus/usb/drivers/.../new_id" apply.

[theezeefje]

-

[ Voor 100% gewijzigd door theezeefje op 16-01-2022 20:45 . Reden: nevermind, niet goed gelezen ]

[Gagnant]

DSM 7 ondersteunt geef USB devices meer.
Volg deze stappen om het werkend te krijgen: https://mariushosting.com...add-usb-support-on-dsm-7/

[Hero of Time]

Beetje onnodig om een topic van ruim een jaar oud te kicken om naar een site te linken waar eerder al naar is gelinkt.

Om te voorkomen dat er nog reacties hier op komen of mensen over anderhalf jaar hetzelfde doen, sluit ik dit topic uit voorzorg.