Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Device USB persistant udev / udevadm

Cristaux

Bonjour/Bonsoir,

J'ai un soucis, je souhaite que le "Device" d'un de mes périphériques USB reste persistant.

lsusb
Bus 004 Device 005: ID 0bda:8153 Realtek Semiconductor Corp. RTL8153 Gigabit Ethernet Adapter
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

Comme vous pouvez le constater ce n'est pas un USB de stockage mais une carte réseaux sur un port USB, J'ai créée une règle udev / udevadm la voici :

ACTION=="add", ATTR{idVendor}=="0bda", ATTR{idProduct}=="8153", ATTR{bConfigurationValue}!="$env{REALTEK_NIC_MODE}", MODE="0666", OWNER="cristaux", ATTR{devnum}="{9}"

Je me suis basée sur le fichier rules du constructeur "50-usb-realtek-net.rules". Je suppose que la valeur du Device ce situe ici :

cat /sys/devices/pci0000:00/0000:00:16.0/0000:0b:00.0/usb4/4-1/devnum

La commande cat me donne une seul valeur = 5, se qui correspond avec le Device actuelle.
Toutes ces informations corresponde bien à :

udevadm info -a -p $(udevadm info -q path -n /dev/bus/usb/004/005)

Cependant cette commande me retourne :

looking at device '/devices/pci0000:00/0000:00:16.0/0000:0b:00.0/usb4/4-1':
KERNEL=="4-1"
SUBSYSTEM=="usb"
DRIVER=="usb"
ATTR{bMaxPower}=="288mA"
ATTR{speed}=="5000"
ATTR{bMaxPacketSize0}=="9"
ATTR{quirks}=="0x400"
ATTR{bmAttributes}=="a0"
ATTR{bDeviceProtocol}=="00"
ATTR{ltm_capable}=="yes"
ATTR{version}==" 3.20"
ATTR{avoid_reset_quirk}=="0"
ATTR{bNumConfigurations}=="2"
ATTR{bNumInterfaces}==" 1"
ATTR{authorized}=="1"
ATTR{configuration}==""
ATTR{idVendor}=="0bda"
ATTR{idProduct}=="8153"
ATTR{bDeviceSubClass}=="00"
ATTR{urbnum}=="465614"
ATTR{manufacturer}=="Realtek"
ATTR{bDeviceClass}=="00"
ATTR{serial}=="000000"
ATTR{devnum}=="5"
ATTR{devpath}=="1"
ATTR{busnum}=="4"
ATTR{product}=="USB 10/100/1000 LAN"
ATTR{bcdDevice}=="3000"
ATTR{rx_lanes}=="1"
ATTR{maxchild}=="0"
ATTR{bConfigurationValue}=="1"
ATTR{tx_lanes}=="1"
ATTR{removable}=="unknown"

Quand j'essaye d’exécuter cette commande :

udevadm test /devices/pci0000:00/0000:00:16.0/0000:0b:00.0/usb4/4-1

ça me retourne :

Invalid inotify descriptor.
4-1: /etc/udev/rules.d/50-usb-realtek-net.rules:13 Failed to write ATTR{/sys/devices/pci0000:00/0000:00:16.0/0000:0b:00.0/usb4/4-1/devnum}, ignoring: Permission denied
DEVPATH=/devices/pci0000:00/0000:00:16.0/0000:0b:00.0/usb4/4-1
DEVNAME=/dev/bus/usb/004/005
DEVTYPE=usb_device
DRIVER=usb
PRODUCT=bda/8153/3000
TYPE=0/0/0
BUSNUM=004
DEVNUM=005
MAJOR=189
MINOR=388
ACTION=add
SUBSYSTEM=usb
ID_VENDOR=Realtek
ID_VENDOR_ENC=Realtek
ID_VENDOR_ID=0bda
ID_MODEL=USB_10_100_1000_LAN
ID_MODEL_ENC=USB\x2010\x2f100\x2f1000\x20LAN
ID_MODEL_ID=8153
ID_REVISION=3000
ID_SERIAL=Realtek_USB_10_100_1000_LAN_000000
ID_SERIAL_SHORT=000000
ID_BUS=usb
ID_USB_INTERFACES=:ffff00:020600:0a0000:
ID_VENDOR_FROM_DATABASE=Realtek Semiconductor Corp.
ID_MODEL_FROM_DATABASE=RTL8153 Gigabit Ethernet Adapter
REALTEK_NIC_MODE=1
ID_PATH=pci-0000:0b:00.0-usb-0:1
ID_PATH_TAG=pci-0000_0b_00_0-usb-0_1
USEC_INITIALIZED=2377194066
Unload module index
Unloaded link configuration context.

Ont peut bien voir que sur la deuxième ligne la permissions à bien était refuser. Sachant que même le fichier : "Reading rules file: /etc/udev/rules.d/50-usb-realtek-net.rules" à bien était lu par udevadm.

Maintenant si je fait ça :

chmod 777 /sys/devices/pci0000:00/0000:00:16.0/0000:0b:00.0/usb4/4-1/devnum

et que je ré-exécute la commande cette commande précédente :

udevadm test /devices/pci0000:00/0000:00:16.0/0000:0b:00.0/usb4/4-1

sa m'affiche ça :

Invalid inotify descriptor.
4-1: /etc/udev/rules.d/50-usb-realtek-net.rules:13 Failed to write ATTR{/sys/devices/pci0000:00/0000:00:16.0/0000:0b:00.0/usb4/4-1/devnum}, ignoring: Input/output error
DEVPATH=/devices/pci0000:00/0000:00:16.0/0000:0b:00.0/usb4/4-1
DEVNAME=/dev/bus/usb/004/005
DEVTYPE=usb_device
DRIVER=usb
PRODUCT=bda/8153/3000
TYPE=0/0/0
BUSNUM=004
DEVNUM=005
MAJOR=189
MINOR=388
ACTION=add
SUBSYSTEM=usb
ID_VENDOR=Realtek
ID_VENDOR_ENC=Realtek
ID_VENDOR_ID=0bda
ID_MODEL=USB_10_100_1000_LAN
ID_MODEL_ENC=USB\x2010\x2f100\x2f1000\x20LAN
ID_MODEL_ID=8153
ID_REVISION=3000
ID_SERIAL=Realtek_USB_10_100_1000_LAN_000000
ID_SERIAL_SHORT=000000
ID_BUS=usb
ID_USB_INTERFACES=:ffff00:020600:0a0000:
ID_VENDOR_FROM_DATABASE=Realtek Semiconductor Corp.
ID_MODEL_FROM_DATABASE=RTL8153 Gigabit Ethernet Adapter
REALTEK_NIC_MODE=1
ID_PATH=pci-0000:0b:00.0-usb-0:1
ID_PATH_TAG=pci-0000_0b_00_0-usb-0_1
USEC_INITIALIZED=2377194066
Unload module index
Unloaded link configuration context.

On peut bien voir deux erreurs : "ignoring: Input/output error" et "Invalid inotify descriptor."

J'ai déjà utiliser ses commandes :

udevadm trigger
sudo udevadm control --reload
reboot

Site du constructeur : https://www.realtek.com/en/component/zoo/category/network-interface-controllers-10-100-1000m-gigabit-ethernet-usb-3-0-software
Modele : RTL8153
Pilote/Drivers déjà installé, ça fonctionne nickel
Kernel : Linux ZNX 5.8.9 #1 SMP Wed Sep 16 18:52:38 CEST 2020 x86_64 x86_64 x86_64 GNU/Linux

S'il vous plaît, comment changer ou rendre le "Device persistant", ma priorité c'est qu'il devienne persistant, à chaque branchement et débranchement.
Je vous en remercie de votre aide, Cordialement Cristaux.

MicP

Bonjour

…J'ai créée une règle udev / udevadm la voici :

ACTION=="add", ATTR{idVendor}=="0bda", ATTR{idProduct}=="8153", ATTR{bConfigurationValue}!="$env{REALTEK_NIC_MODE}", MODE="0666", OWNER="cristaux", ATTR{devnum}="{9}"

Puisque sur ta machine ce périphérique est connecté au device 005 du bus 004,
pourquoi avoir mis la valeur 9 à ATTR{devnum}=

=======

… Je me suis basée sur le fichier rules du constructeur "50-usb-realtek-net.rules". …

Quel était le contenu de ce fichier ?
Un lien vers une page web d'où a été extrait ce fichier serait un plus.
Merci.

=======
Je ne comprends pas ce que tu veux dire par "persistant"
pourrais-tu nous dire ce que tu voudrais voir persister ?

Quel est le but de la démarche ?

Cristaux

Bonjour, merci d'avoir répondu,
J'ai mis la valeur 9, pour savoir si je pouvais la changer, comme je n'arrive pas à l’immobilisé (le Device USB).

Le contenue de "50-usb-realtek-net.rules" est : (Mais faut sache que ce code n'est pas complets par rapport au contenue du fichier car il y a beaucoup de régles concernent d'autres périphériques, se qui me concerne pas, donc j'ai choisis les rélgles indispensable).

ACTION!="add", GOTO="usb_realtek_net_end"
SUBSYSTEM!="usb", GOTO="usb_realtek_net_end"
ENV{DEVTYPE}!="usb_device", GOTO="usb_realtek_net_end"

# Modify this to change the default value
ENV{REALTEK_NIC_MODE}="1"

ATTR{idVendor}=="0bda", ATTR{idProduct}=="8153", ATTR{bConfigurationValue}!="$env{REALTEK_NIC_MODE}", ATTR{bConfigurationValue}="$env{REALTEK_NIC_MODE}"

LABEL="usb_realtek_net_end"

Voici le lien de téléchargement : https://realtekcdn.akamaized.net/rtdrivers/cn/nic1/r8152.53.56-2.14.0.tar?__token__=exp=1613407670~acl=/rtdrivers/cn/nic1/r8152.53.56-2.14.0.tar~hmac=469224d95cc79327bd51a3966c21444f1d785c388ddddf3f2b2205516067b5a6
Si jamais ce lien ne fonctionne pas, alors je vous guide vers https://www.realtek.com/en/component/zoo/category/network-interface-controllers-10-100-1000m-gigabit-ethernet-usb-3-0-software <<< RTL8153

J'utilise le mot persistant pour définir, que je veux que le Device reste immobilisé, qui ne bouge pas, que ce soit en débranchent ou en rebranchent le périphérique USB.
Je veux que le Device 005 dans le bus USB 004 reste immobile car le but de la démarche c'est que j'éxecute plusieurs VM avec des "bugs" de réseaux. Donc, j'utilise ce prériphérique USB > Ethernet, pour mes VMs. Je souhaite avoir ce périphérique dédiée à ma VM et une fois que je l'éteint/reboot, il faut que je recommence plusieurs manoeuvre.

MicP

…J'ai mis la valeur 9, pour savoir si je pouvais la changer, …

Non, le numéro de device correspond à un numéro qui est automatiquement attribué en fonction de la détection des périphériques par le système.

Donc, si tu débranches ta clef USB<->RJ45, et que tu la rebranches aussitôt, le numéro de device attribué par le système aura changé.

Par contre, si elle est rebranchée sur le même connecteur USB, le numéro de bus, lui, restera toujours le même.

Tu peux facilement le constater en regardant le retour de la commande lsusb

Donc, dans ta règle udev, pour identifier de manière fiable ta clef USB<-> RJ45,
n'utilises pas ce numéro de device mais plutôt le numéro de bus si elle doit toujours être connectée sur le même connecteur USB,
et les UsbIDs de cette clef USB<-> RJ45

=======
Quel système de virtualisation utilises-tu (qemu/kvm, virtualbox, VMWare, ou autre) ?

Pour qemu/kvm, à la place des numéro de bus et de device,
tu peux utiliser les UsbIDs de ta clef USB<-> RJ45 (0bda:8153) qui eux, ne changeront pas,
et ce quelque soit le connecteur USB sur lequel la clef USB<-> RJ45 sera connectée.
Voir : https://access.redhat.com/solutions/479683

Pour Virtualbox et VMware, ce doit aussi être possible, mais comme je ne les utilises pas,
il faudra faire des recherches pour trouver comment faire.

Cristaux

Bonjour,
J'utilise QEMU/KVM, j'ai suivie ton conseil mais le résultat ce trouve ici https://www.youtube.com/watch?v=k3fbaALPJkk, merci de votre aide.

En gros, j'aimerais bien ne plus rien modifié en rapport au périphérique (Carte réseaux USB), lorsque j’éteins/reboot la VMs ou même l’hôte (Mon Linux).

J'ai essayé plein de solutions, ROOT, écrasé tout le fichier XML et le réinsérer dans son propre dossier en étant modifier, éditer le fichier XML à l'état brut. Pour udev je peut faire fausse route. ajouter ce périphériques à plusieurs reprises sur différent Device/Port, Ou alors faire un script en un clic qui permet de mettre à jour le Device/Port dans la VM. Qu'en pensez vous ?

EDIT : Ou alors installer une autre carte réseaux virtuelle dans la VMs, mais pas celles-ci : rtl8139, e1000e
J'ai déjà essayer de faire un pont réseaux mais le résultat n'étais pas satisfaisant.

Si ma demande est un peu trop complexe, tempi, je vous en remercie.

Cordialement,

MicP

Bonjour

Ce que tu tentes de faire dans ta vidéo
est ce que j'avais fait, mais en supprimant la ligne directement dans le fichier xml
avec sed ou un simple éditeur de texte.

Au final, ma machine virtuelle retrouve ma clef USB au démarrage
quelque soit le connecteur USB sur lequel elle est branchée sur la machine hôte,
même si elle est connectée par l'intermédiaire d'un hub USB.

=======
Dans ce qui suit, maMachineVirtuelle est le nom de ma machine virtuelle.

La clef étant connectée et reconnue sur la machine virtuelle,
j'ai utilisé virsh pour créer un dump xml de la machine virtuelle concernée :

virsh -c qemu:///system dumpxml maMachineVirtuelle > maMachineVirtuelle.xml

Ensuite avec sed (ou un éditeur de texte),
j'ai supprimé dans le fichier maMachineVirtuelle.xml la ligne concernant l'adresse du périphérique usb
(bien sûr, tu adapteras cette ligne de commande avec l'adresse utilisée sur ta machine)

sed  -i.sauv  '/<address type="usb" bus="0" port="4">/d'  maMachineVirtuelle.xml

avec l'option i.sauv de la commande sed
une copie du fichier original non modifié nommée maMachineVirtuelle.xml.sauv sera créée.

Après modification, voilà tout ce qu'il restera dans le fichier maMachineVirtuelle.xml concernant ta clef USB :

<hostdev mode="subsystem" type="usb" managed="yes">
  <source>
    <vendor id="0x0bda"/>
    <product id="0x8153"/>
  </source>
</hostdev>

Puis, avec l'interface graphique virt-manager, j'ai supprimé la machine virtuelle
sans bien sûr supprimer le ou les disques virtuels qu'elle utilise => décocher la ou les cases concernant le ou les disques.
(on peut aussi le faire avec virsh en utilisant la commande undefine quand la machine virtuelle est arrêtée,
mais avec un clic droit sur le nom de la machine virtuelle, c'est plus rapide et j'évite toute erreur dans ma ligne de commande)

et avec virsh j'ai recréé la machine virtuelle en utilisant le fichier xml modifié :

virsh -c qemu:///system define maMachineVirtuelle.xml

Si la fenêtre virt-manager est ouverte au moment où on lance la ligne de commande ci-dessus,
on y voit alors la machine virtuelle réapparaître.

Après ça, à chaque démarrage de la machine,
quel que soit l'endroit où j'ai connecté ma clef USB sur la machine hôte,
la clef est reconnue dans la machine virtuelle.

=======
NOTE :
Dans cette page web, je relève l'extrait suivant concernant l'attribut managed

Note: The managed attribute is only used with type='pci' and is ignored by all the other device types,
        thus setting managed explicitly with other than a PCI device has the same effect as omitting it.
      Similarly, model attribute is only supported by mediated devices and ignored by all other device types.

Et c'est vrai que l'attribut managed n'est pas utilisé sur mes machines virtuelles pour les périphériques de type usb

Cristaux

Bonjour,

J'ai bien suivi votre tutoriel, ça fonctionne très bien après plusieurs reboot et arrêt complet du PC (shutdown) puis en relançant la VM à plusieurs reprises par contre il y a un petit bémol...
Le QEMU/KVM REmodifie le fichier XML qui ce situe dans le dossier initiale, à un moment donné (/etc/libvirt/qemu/win10.xml), donc j'ai recommencer le tuto et pour évité qu'il ce modifie j'ai rajouté c'est deux commande au démarrage de mon Linux :

chown zinux:zinux /etc/libvirt/qemu/win10-gaming.xml
chmod 555 /etc/libvirt/qemu/win10.xml

"chmod 555" uniquement pour la lecture et l’exécution du fichier, (Zinux est bien mon nom d'utilisateur)

Nous pouvons, fermé ce sujet, puis le renommer (ex : [RÉSOLU] Modification du fichier XML [QEMU/KVM] ).

Depuis le début je faisais fausse route avec udev, je pensais que c'était la solution, je me suis compliqué la vie lol, par hasard MicP avez-vous une adresse de réception du Bitcoin/Wallet ? Pour que je vous donne un peu de ma générosité 😉 ? (Je ne sais pas si j'ai le droit de posé ce genre de question).
Bien Cordialement, et MERCI BEAUCOUP. 😃

QUOI QUE, je parle un peu trop vite : après le démarrage ce matin je vois ceci, et la carte réseaux n'est plus reconnu sous Windows avec QEMU/KVM

Il faudrait la lancer à partir dans un terminal, puis rechanger les droits à la suite de la 1er commande, je pense...
Si jamais vous avez une autre idée, je suis preneur, merci.

MicP

Bonjour

Il y avait un bug dans libvirt : Libvirt does not generate addresses for USB host devices.
Mais "malheureusement" 🙂 le problème a été résolu,
alors que dans ton cas, tu aurais préféré qu'il n'y ait pas d'adresse.

=======
Il reste à trouver comment et quand
supprimer l'adresse de ta clef USB<->RJ45

Ça dépends de comment et à quel moment tu démarres et arrêtes cette machine virtuelle.

Avec ces informations, on pourra peut-être trouver un moyen de déclencher
le lancement d'un script qui supprimera dans le fichier /etc/libvirt/qemu/win10-gaming.xml
la ligne d'adresse de ta clef USB<->RJ45
ou simplement remplacera le fichier par /etc/libvirt/qemu/win10-gaming.xml
par un autre dans lequel la ligne d'adresse est absente.

Cristaux

Problème "résolus" ont m'a conseillé cette commande, ça permet de bloquer le fichier en écriture, aucune modification n'est permise :

Pour bloquer le fichier :

chattr +i /etc/libvirt/qemu/win10.xml

Pour débloquer le fichier :

chattr -i /etc/libvirt/qemu/win10.xml

Merci MicP pour ton aide.

MicP

Bonjour

Merci pour le retour.

Sur mon système Xubuntu,
pour pouvoir modifier l'attribut FS_IMMUTABLE_FL d'un fichier avec la commande chattr
il me faut les privilèges du compte root

=======
Je me suis rendu compte
que ce n'est pas l'adresse à laquelle je pensais qu'il fallait supprimer

Voilà un bloc xml pour un device usb à connecter sur ma machine virtuelle
quand la machine est à l'arrêt :

<hostdev mode="subsystem" type="usb" managed="yes">
  <source>
    <vendor id="0x174c"/>
    <product id="0x5136"/>
  </source>
  <address type="usb" bus="0" port="4"/>
</hostdev>

Et le revoilà une fois que la machine virtuelle a été lancée :

<hostdev mode="subsystem" type="usb" managed="yes">
  <source>
    <vendor id="0x174c"/>
    <product id="0x5136"/>
    <address bus="3" device="87"/>
  </source>
  <alias name="hostdev0"/>
  <address type="usb" bus="0" port="4"/>
</hostdev>

L'adresse qui serait supprimer (qui correspond à celle sur la machine hôte)
est l'adresse qui est entre les tags <source> et </source>

Mais l'autre adresse correspond à celle trouvée sur la machine virtuelle.

Je pense qu'Il doit peut-être exister une solution
dans la doc de libvirt

Mais bon, si la méthode chattr fonctionne
et te permet de faire ce qu'il te faut, tant mieux.