J'ai des appareils fabriqu=C3=A9s en interne qui utilisent des chips FTDI p=
our
lesquels j'ai obtenu de la part de FTDI, il y a d=C3=A9j=C3=A0 de nombreuse=
s ann=C3=A9es,
une plage de PID.
En fait, j'utilise essentiellement le PID 0xEFE0, donc mon interface
appara=C3=AEt comme 0403:EFE0
Sur mes PC Linux (en l=E2=80=99occurrence "Mint" =C3=A0 jour), je dois lanc=
er en root,
un script pour initier la reconnaissance de connection, le contenu de mon
script /home/du2/Applications/utils/
Apr=C3=A8s avoir lanc=C3=A9 ce script, je peux bien communiquer avec mes ap=
pareil par
un port VCP du type /dev/ttyUSBx
La d=C3=A9connexion et reconnexion devient bien automatique, pas de soucis.
Par contre, je souhaiterais ne pas avoir =C3=A0 lancer manuellement ce scri=
pt et
j'ai pens=C3=A9 =C3=A0 une r=C3=A8gle UDEV, mais l=C3=A0 je nage, tous mes =
essais sont
infructueux. Et surtout je ne sais pas comment investiguer de fa=C3=A7on
efficace.
J'ai =C3=A9crit la r=C3=A8gle suivante dans /etc/udev/rules.d/99-axiome.rul=
es :
ACTION=3D=3D"add", SUBSYSTEM=3D=3D"usb", ATTR{idProduct}=3D=3D"EFE0",
ATTR{idVendor}=3D=3D"0403", RUN+=3D"/sbin sh
/home/du2/Applications/utils/Usb_axiome.sh"
Si quelqu'un voit mon erreur ou a une autre id=C3=A9e pour arriver au r=C3=
=A9sultat,
je lui en serai infiniment reconnaissant.
<div dir=3D"ltr">Bonjour la liste,<div><br></div><div>J'ai des appareil=
s fabriqu=C3=A9s en interne qui utilisent des chips FTDI pour lesquels j=
9;ai obtenu <span style=3D"color:rgb(34,34,34);font-family:arial,sans-serif=
;font-size:small;font-style:normal;font-variant-ligatures:normal;font-varia=
nt-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-=
indent:0px;text-transform:none;white-space:normal;word-spacing:0px;backgrou=
nd-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-col=
or:initial;float:none;display:inline">de la part de FTDI</span>, il y a d=
=C3=A9j=C3=A0 de nombreuses ann=C3=A9es,=C2=A0 une plage de PID.</div><div>=
En fait, j'utilise essentiellement le PID 0xEFE0, donc mon interface ap=
para=C3=AEt comme 0403:EFE0</div><div><br></div><div>Sur mes PC Linux (en l=
=E2=80=99occurrence "Mint" =C3=A0 jour), je dois lancer en root, =
un script pour initier la reconnaissance de connection, le contenu de mon s=
cript=C2=A0/home/du2/Applications/utils/
<p style=3D"margin:0px;text-indent:0px;white-space:pre-wrap">Usb_Axiome.sh =
est le suivant :</p></div><div><br></div><div><div>modprobe ftdi_sio</div><=
div>chmod 666 /sys/bus/usb-serial/drivers/ftdi_sio/new_id</div><div>echo &q=
uot;0403 EFE0" > /sys/bus/usb-serial/drivers/ftdi_sio/new_id</div><=
/div><div><br></div><div>Apr=C3=A8s avoir lanc=C3=A9 ce script, je peux bie=
n communiquer avec mes appareil par un port VCP du type /dev/ttyUSBx</div><=
div>La d=C3=A9connexion et reconnexion devient bien automatique, pas de sou=
cis.</div><div><br></div><div>Par contre, je souhaiterais ne pas avoir =C3=
=A0 lancer manuellement ce script et j'ai pens=C3=A9 =C3=A0 une r=C3=A8=
gle UDEV, mais l=C3=A0 je nage, tous mes essais sont infructueux. Et surtou=
t je ne sais pas comment investiguer de fa=C3=A7on efficace.</div><div><br>=
</div><div>J'ai =C3=A9crit la r=C3=A8gle suivante dans /etc/udev/rules.=
d/99-axiome.rules :</div><div><br></div><div><div>ACTION=3D=3D"add&quo=
t;, SUBSYSTEM=3D=3D"usb", ATTR{idProduct}=3D=3D"EFE0", =
ATTR{idVendor}=3D=3D"0403", RUN+=3D"/sbin sh /home/du2/Appli=
cations/utils/Usb_axiome.sh"</div></div><div><br></div><div>Si quelqu&=
#39;un voit mon erreur ou a une autre id=C3=A9e pour arriver au r=C3=A9sult=
at, je lui en serai infiniment reconnaissant.</div><div><br></div><div>D=
9;avance merci =C3=A0 ceux qui me lirons.</div><div>Danilo<br></div><div><b=
r></div></div>
Par contre, je souhaiterais ne pas avoir à lancer manuellement ce sc ript et j'ai pensé à une règle UDEV, mais là je nage, tous me s essais sont infructueux. Et surtout je ne sais pas comment investiguer de façon efficace.
Apparemment, il existe pas mal d'info sur comment debugger les règles udev. Comme celui qui consiste à utiliser <udevadm test> : Cf. https://www.jpichon.net/blog/2011/12/debugging-udev-rules/ Ma modeste contribution. Jean-Marc https://6jf.be/keys/ED863AD1.txt --Signature=_Thu__12_Apr_2018_10_05_51_+0200__VDrpYetwdRTckRK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEEWjgcRC0dCXkfm9hQHHLXC3pxPwFAlrPE18ACgkQQHHLXC3p xPzD6Q/9Gld8edSZVH3bpTMG7CPOU5hGK0/kmHYVCHakaKMXp5gRaYMrv1o6w2cw i6b4UmLtar+XMaHfzM1Iv3K5HaQ6uj9o8jQdlh4kL/dfM3Rt2TvLODmWcfQvyWhT fAar7eLhXM7P8A/TT19+GAdTy+JlDPySOCsEvbSn1Yh6HYoO8hqkqXCOFy4lenLd 8fHYvUJGt6XA98AzduZ585lcea8rWuzClPF4epwyPvTxof/MShgwN1bcns0PipRJ EeKAdfUOWT1ZSFm6E3Rsx3jVRybETg4ryUNE65xJ9lgWSbA8N4Sp+myGn18Be03W 2YWFS39qPg6StMWkCe/pody7qsULLX9qPLItTSz3Rn6L2SvVUIKPH5uZbTl9b9V5 8PBOFSkyPhRHxfsjzzoQXD0B2968yu/1OwCXcTn3WcSFVGwKfdr4rMXeRBuLlnS4 38qSPvFe1iiYMDG2S+Sx2dmlxDji3shL+w0WnZkJ1xE//W22GlktI5YLfUbpN7IV 410/pOr2RisHAGdwxzjedXP6JTbwhgsf9KkOPgsfxD8HeQHhMRUUSbuEqyRF9jtA /MoMm5JLUPGEGur0CVuzFs4qFYcSZp2B226OeQALkQ8aAatqZfX0cQkoo4hMRFza 7nToqM7vLCkYJT+KVzWTMB+8ugQNnBYbNgyIAu25cgS/HwPZQqI mN/ -----END PGP SIGNATURE----- --Signature=_Thu__12_Apr_2018_10_05_51_+0200__VDrpYetwdRTckRK--
Par contre, je souhaiterais ne pas avoir à lancer manuellement ce sc ript et
j'ai pensé à une règle UDEV, mais là je nage, tous me s essais sont
infructueux. Et surtout je ne sais pas comment investiguer de façon
efficace.
Apparemment, il existe pas mal d'info sur comment debugger les règles udev.
Comme celui qui consiste à utiliser <udevadm test> :
Par contre, je souhaiterais ne pas avoir à lancer manuellement ce sc ript et j'ai pensé à une règle UDEV, mais là je nage, tous me s essais sont infructueux. Et surtout je ne sais pas comment investiguer de façon efficace.
Apparemment, il existe pas mal d'info sur comment debugger les règles udev. Comme celui qui consiste à utiliser <udevadm test> : Cf. https://www.jpichon.net/blog/2011/12/debugging-udev-rules/ Ma modeste contribution. Jean-Marc https://6jf.be/keys/ED863AD1.txt --Signature=_Thu__12_Apr_2018_10_05_51_+0200__VDrpYetwdRTckRK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEEWjgcRC0dCXkfm9hQHHLXC3pxPwFAlrPE18ACgkQQHHLXC3p xPzD6Q/9Gld8edSZVH3bpTMG7CPOU5hGK0/kmHYVCHakaKMXp5gRaYMrv1o6w2cw i6b4UmLtar+XMaHfzM1Iv3K5HaQ6uj9o8jQdlh4kL/dfM3Rt2TvLODmWcfQvyWhT fAar7eLhXM7P8A/TT19+GAdTy+JlDPySOCsEvbSn1Yh6HYoO8hqkqXCOFy4lenLd 8fHYvUJGt6XA98AzduZ585lcea8rWuzClPF4epwyPvTxof/MShgwN1bcns0PipRJ EeKAdfUOWT1ZSFm6E3Rsx3jVRybETg4ryUNE65xJ9lgWSbA8N4Sp+myGn18Be03W 2YWFS39qPg6StMWkCe/pody7qsULLX9qPLItTSz3Rn6L2SvVUIKPH5uZbTl9b9V5 8PBOFSkyPhRHxfsjzzoQXD0B2968yu/1OwCXcTn3WcSFVGwKfdr4rMXeRBuLlnS4 38qSPvFe1iiYMDG2S+Sx2dmlxDji3shL+w0WnZkJ1xE//W22GlktI5YLfUbpN7IV 410/pOr2RisHAGdwxzjedXP6JTbwhgsf9KkOPgsfxD8HeQHhMRUUSbuEqyRF9jtA /MoMm5JLUPGEGur0CVuzFs4qFYcSZp2B226OeQALkQ8aAatqZfX0cQkoo4hMRFza 7nToqM7vLCkYJT+KVzWTMB+8ugQNnBYbNgyIAu25cgS/HwPZQqI mN/ -----END PGP SIGNATURE----- --Signature=_Thu__12_Apr_2018_10_05_51_+0200__VDrpYetwdRTckRK--
FF \\__/ FF
--000000000000adb71f0569a2f862 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable bonjour, lorsque vous plugger votre composant usb, si cela crée toujours un /dev/ttyUSBx, vous pouvez utiliser inotify qui detecte les changements, creation etc de fichiers. Me semble avoir utilisé des regles UDEV, avec des resultats aleatoires . cordialement Le jeu. 12 avr. 2018 10:43, Jean-Marc a écrit :
Par contre, je souhaiterais ne pas avoir à lancer manuellement ce script
et
j'ai pensé à une règle UDEV, mais là je nage, tous mes essais sont infructueux. Et surtout je ne sais pas comment investiguer de faço n efficace.
Apparemment, il existe pas mal d'info sur comment debugger les règle s udev. Comme celui qui consiste à utiliser <udevadm test> : Cf. https://www.jpichon.net/blog/2011/12/debugging-udev-rules/ Ma modeste contribution. Jean-Marc https://6jf.be/keys/ED863AD1.txt
--000000000000adb71f0569a2f862 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir="auto">bonjour,<div dir="auto"><br></div><div dir="auto">lor sque vous plugger votre composant usb, si cela crée toujours un /dev/t tyUSBx, vous pouvez utiliser inotify qui detecte les changements, creation etc de fichiers.</div><div dir="auto"><br></div><div dir="auto">Me semb le avoir utilisé des regles UDEV, avec des resultats aleatoires.</div> <div dir="auto"><br></div><div dir="auto">cordialement</div></div><br>< div class="gmail_quote"><div dir="ltr">Le jeu. 12 avr. 2018 10:43, Jean -Marc <<a href="mailto:"></a>> a écrit :<br></div><blockquote class="gmail_quote" style="margi n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thu, 12 Apr 2018 07:59:17 +0200<br> Danilo Uccelli <<a href="mailto:" target="_blank" re l="noreferrer"></a>> écrivait :<br> <br> > Par contre, je souhaiterais ne pas avoir à lancer manuellement ce script et<br> > j'ai pensé à une règle UDEV, mais là je nage, tous mes essais sont<br> > infructueux. Et surtout je ne sais pas comment investiguer de faç on<br> > efficace.<br> <br> Apparemment, il existe pas mal d'info sur comment debugger les règ les udev.<br> Comme celui qui consiste à utiliser <udevadm test> :<br> <br> Cf.<br> <a href="https://www.jpichon.net/blog/2011/12/debugging-udev-rules/" rel ="noreferrer noreferrer" target="_blank">https://www.jpichon.net/blog/2 011/12/debugging-udev-rules/</a><br> <br> Ma modeste contribution.<br> <br> Jean-Marc <<a href="mailto:" target="_blank" rel=" noreferrer"></a>><br> <a href="https://6jf.be/keys/ED863AD1.txt" rel="noreferrer noreferrer" target="_blank">https://6jf.be/keys/ED863AD1.txt</a><br> </div> --000000000000adb71f0569a2f862--
lorsque vous plugger votre composant usb, si cela crée toujours un
/dev/ttyUSBx, vous pouvez utiliser inotify qui detecte les changements,
creation etc de fichiers.
Me semble avoir utilisé des regles UDEV, avec des resultats aleatoires .
cordialement
Le jeu. 12 avr. 2018 10:43, Jean-Marc <jean-marc@6jf.be> a écrit :
> Par contre, je souhaiterais ne pas avoir à lancer manuellement ce script
et
> j'ai pensé à une règle UDEV, mais là je nage, tous mes essais sont
> infructueux. Et surtout je ne sais pas comment investiguer de faço n
> efficace.
Apparemment, il existe pas mal d'info sur comment debugger les règle s udev.
Comme celui qui consiste à utiliser <udevadm test> :
<div dir="auto">bonjour,<div dir="auto"><br></div><div dir="auto">lor sque vous plugger votre composant usb, si cela crée toujours un /dev/t tyUSBx, vous pouvez utiliser inotify qui detecte les changements, creation etc de fichiers.</div><div dir="auto"><br></div><div dir="auto">Me semb le avoir utilisé des regles UDEV, avec des resultats aleatoires.</div> <div dir="auto"><br></div><div dir="auto">cordialement</div></div><br>< div class="gmail_quote"><div dir="ltr">Le jeu. 12 avr. 2018 10:43, Jean -Marc <<a href="mailto:jean-marc@6jf.be">jean-marc@6jf.be</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margi n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thu, 12 Apr 2018 07:59:17 +0200<br>
Danilo Uccelli <<a href="mailto:danucc@gmail.com" target="_blank" re l="noreferrer">danucc@gmail.com</a>> écrivait :<br>
<br>
> Par contre, je souhaiterais ne pas avoir à lancer manuellement ce script et<br>
> j'ai pensé à une règle UDEV, mais là je nage, tous mes essais sont<br>
> infructueux. Et surtout je ne sais pas comment investiguer de faç on<br>
> efficace.<br>
<br>
Apparemment, il existe pas mal d'info sur comment debugger les règ les udev.<br>
Comme celui qui consiste à utiliser <udevadm test> :<br>
<br>
Cf.<br>
<a href="https://www.jpichon.net/blog/2011/12/debugging-udev-rules/" rel ="noreferrer noreferrer" target="_blank">https://www.jpichon.net/blog/2 011/12/debugging-udev-rules/</a><br>
<br>
Ma modeste contribution.<br>
<br>
Jean-Marc <<a href="mailto:jean-marc@6jf.be" target="_blank" rel=" noreferrer">jean-marc@6jf.be</a>><br>
<a href="https://6jf.be/keys/ED863AD1.txt" rel="noreferrer noreferrer" target="_blank">https://6jf.be/keys/ED863AD1.txt</a><br>
</blockquote></div>
--000000000000adb71f0569a2f862 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable bonjour, lorsque vous plugger votre composant usb, si cela crée toujours un /dev/ttyUSBx, vous pouvez utiliser inotify qui detecte les changements, creation etc de fichiers. Me semble avoir utilisé des regles UDEV, avec des resultats aleatoires . cordialement Le jeu. 12 avr. 2018 10:43, Jean-Marc a écrit :
Par contre, je souhaiterais ne pas avoir à lancer manuellement ce script
et
j'ai pensé à une règle UDEV, mais là je nage, tous mes essais sont infructueux. Et surtout je ne sais pas comment investiguer de faço n efficace.
Apparemment, il existe pas mal d'info sur comment debugger les règle s udev. Comme celui qui consiste à utiliser <udevadm test> : Cf. https://www.jpichon.net/blog/2011/12/debugging-udev-rules/ Ma modeste contribution. Jean-Marc https://6jf.be/keys/ED863AD1.txt
--000000000000adb71f0569a2f862 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir="auto">bonjour,<div dir="auto"><br></div><div dir="auto">lor sque vous plugger votre composant usb, si cela crée toujours un /dev/t tyUSBx, vous pouvez utiliser inotify qui detecte les changements, creation etc de fichiers.</div><div dir="auto"><br></div><div dir="auto">Me semb le avoir utilisé des regles UDEV, avec des resultats aleatoires.</div> <div dir="auto"><br></div><div dir="auto">cordialement</div></div><br>< div class="gmail_quote"><div dir="ltr">Le jeu. 12 avr. 2018 10:43, Jean -Marc <<a href="mailto:"></a>> a écrit :<br></div><blockquote class="gmail_quote" style="margi n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thu, 12 Apr 2018 07:59:17 +0200<br> Danilo Uccelli <<a href="mailto:" target="_blank" re l="noreferrer"></a>> écrivait :<br> <br> > Par contre, je souhaiterais ne pas avoir à lancer manuellement ce script et<br> > j'ai pensé à une règle UDEV, mais là je nage, tous mes essais sont<br> > infructueux. Et surtout je ne sais pas comment investiguer de faç on<br> > efficace.<br> <br> Apparemment, il existe pas mal d'info sur comment debugger les règ les udev.<br> Comme celui qui consiste à utiliser <udevadm test> :<br> <br> Cf.<br> <a href="https://www.jpichon.net/blog/2011/12/debugging-udev-rules/" rel ="noreferrer noreferrer" target="_blank">https://www.jpichon.net/blog/2 011/12/debugging-udev-rules/</a><br> <br> Ma modeste contribution.<br> <br> Jean-Marc <<a href="mailto:" target="_blank" rel=" noreferrer"></a>><br> <a href="https://6jf.be/keys/ED863AD1.txt" rel="noreferrer noreferrer" target="_blank">https://6jf.be/keys/ED863AD1.txt</a><br> </div> --000000000000adb71f0569a2f862--
Pascal Hambourg
Le 12/04/2018 à 07:59, Danilo Uccelli a écrit :
J'ai écrit la règle suivante dans /etc/udev/rules.d/99-axiome.rules : ACTION=="add", SUBSYSTEM=="usb", ATTR{idProduct}=="EFE0", ATTR{idVendor}=="0403", RUN+="/sbin sh /home/du2/Applications/utils/Usb_axiome.sh" Si quelqu'un voit mon erreur ou a une autre idée pour arriver au résultat,
Pas regardé le reste, mais "/sbin sh" me semble suspect. Que vient faire un chemin de répertoire au début d'une commande ? Accessoirement, faire exécuter par udev avec les privilèges root un script situé dans un emplacement qui est sous le contrôle d'un utilisateur normal ne me semble pas un excellente idée.
Le 12/04/2018 à 07:59, Danilo Uccelli a écrit :
J'ai écrit la règle suivante dans /etc/udev/rules.d/99-axiome.rules :
ACTION=="add", SUBSYSTEM=="usb", ATTR{idProduct}=="EFE0",
ATTR{idVendor}=="0403", RUN+="/sbin sh
/home/du2/Applications/utils/Usb_axiome.sh"
Si quelqu'un voit mon erreur ou a une autre idée pour arriver au résultat,
Pas regardé le reste, mais "/sbin sh" me semble suspect. Que vient faire
un chemin de répertoire au début d'une commande ?
Accessoirement, faire exécuter par udev avec les privilèges root un
script situé dans un emplacement qui est sous le contrôle d'un
utilisateur normal ne me semble pas un excellente idée.
J'ai écrit la règle suivante dans /etc/udev/rules.d/99-axiome.rules : ACTION=="add", SUBSYSTEM=="usb", ATTR{idProduct}=="EFE0", ATTR{idVendor}=="0403", RUN+="/sbin sh /home/du2/Applications/utils/Usb_axiome.sh" Si quelqu'un voit mon erreur ou a une autre idée pour arriver au résultat,
Pas regardé le reste, mais "/sbin sh" me semble suspect. Que vient faire un chemin de répertoire au début d'une commande ? Accessoirement, faire exécuter par udev avec les privilèges root un script situé dans un emplacement qui est sous le contrôle d'un utilisateur normal ne me semble pas un excellente idée.
Pascal Hambourg
Le 13/04/2018 à 07:31, Danilo Uccelli a écrit :
Effectivement un des problèmes était bien le manque de slash et j'ai aussi bien compris la faille de sécurité que cela crée.
Quel manque de slash ? Tu veux dire qu'il manquerait un / entre /sbin et sh ? Sûrement pas, car /sbin/sh n'existe pas ; sh est dans /bin.
J'ai donc donné à root la propriété du script.
Pas suffisant car le propriétaire non root du répertoire contenant le script peut toujours le supprimer, le renommer et le remplacer par ce qu'il veut.
Puis, j'ai réalisé que udev n'était pas la meilleure solution puisque il suffit d'exécuter le script une seule fois au démarrage, ensuite le périphérique se monte tout seul. J'ai donc fait un crontab en root, au démarrage.
Il y a mieux qu'un cronjob, je trouve. Pour charger un module au démarrage, on peut le mentionner dans le fichier /etc/modules. Pour qu'il soit chargé automatiquement lors de la détection d'identifiants donnés, on peut créer un alias pour modprobe (cf. man modprobe.d). Et modinfo nous apprend que le module ftdi_sio a deux paramètres vendor et product permettant de spécifier ses propres identifiants, qui peuvent être ajoutés par modprobe. # modinfo -p ftdi_sio debug:Debug enabled or not (bool) vendor:User specified vendor ID (default=0x0403) (ushort) product:User specified product ID (ushort) ndi_latency_timer:NDI device latency timer override (int) Cela pourrait être rassemblé dans un fichier /etc/modprobe.d/ftdi_sio.conf : alias usb:v0403pEFE0d*dc*dsc*dp*ic*isc*ip* ftdi_sio options ftdi_sio vendor=0x0403 product=0xEFE0 A tester et vérifier. Je ne suis pas sûr s'il faut 0x devant les identifiants en hexadécimal. Pour finir, note qu tu aurais pu et pourrais encore demander à ce que tes identifiants personnalisés soient ajoutés au module ftdi_sio directement dans les sources du noyau, comme beaucoup d'autres semblent l'être déjà.
Le 13/04/2018 à 07:31, Danilo Uccelli a écrit :
Effectivement un des problèmes était bien le manque de slash et j'ai aussi
bien compris la faille de sécurité que cela crée.
Quel manque de slash ? Tu veux dire qu'il manquerait un / entre /sbin et
sh ? Sûrement pas, car /sbin/sh n'existe pas ; sh est dans /bin.
J'ai donc donné à root la propriété du script.
Pas suffisant car le propriétaire non root du répertoire contenant le
script peut toujours le supprimer, le renommer et le remplacer par ce
qu'il veut.
Puis, j'ai réalisé que udev n'était pas la meilleure solution puisque il
suffit d'exécuter le script une seule fois au démarrage, ensuite le
périphérique se monte tout seul. J'ai donc fait un crontab en root, au
démarrage.
Il y a mieux qu'un cronjob, je trouve.
Pour charger un module au démarrage, on peut le mentionner dans le
fichier /etc/modules.
Pour qu'il soit chargé automatiquement lors de la détection
d'identifiants donnés, on peut créer un alias pour modprobe (cf. man
modprobe.d).
Et modinfo nous apprend que le module ftdi_sio a deux paramètres vendor
et product permettant de spécifier ses propres identifiants, qui peuvent
être ajoutés par modprobe.
# modinfo -p ftdi_sio
debug:Debug enabled or not (bool)
vendor:User specified vendor ID (default=0x0403) (ushort)
product:User specified product ID (ushort)
ndi_latency_timer:NDI device latency timer override (int)
Cela pourrait être rassemblé dans un fichier /etc/modprobe.d/ftdi_sio.conf :
alias usb:v0403pEFE0d*dc*dsc*dp*ic*isc*ip* ftdi_sio
options ftdi_sio vendor=0x0403 product=0xEFE0
A tester et vérifier. Je ne suis pas sûr s'il faut 0x devant les
identifiants en hexadécimal.
Pour finir, note qu tu aurais pu et pourrais encore demander à ce que
tes identifiants personnalisés soient ajoutés au module ftdi_sio
directement dans les sources du noyau, comme beaucoup d'autres semblent
l'être déjà.
Effectivement un des problèmes était bien le manque de slash et j'ai aussi bien compris la faille de sécurité que cela crée.
Quel manque de slash ? Tu veux dire qu'il manquerait un / entre /sbin et sh ? Sûrement pas, car /sbin/sh n'existe pas ; sh est dans /bin.
J'ai donc donné à root la propriété du script.
Pas suffisant car le propriétaire non root du répertoire contenant le script peut toujours le supprimer, le renommer et le remplacer par ce qu'il veut.
Puis, j'ai réalisé que udev n'était pas la meilleure solution puisque il suffit d'exécuter le script une seule fois au démarrage, ensuite le périphérique se monte tout seul. J'ai donc fait un crontab en root, au démarrage.
Il y a mieux qu'un cronjob, je trouve. Pour charger un module au démarrage, on peut le mentionner dans le fichier /etc/modules. Pour qu'il soit chargé automatiquement lors de la détection d'identifiants donnés, on peut créer un alias pour modprobe (cf. man modprobe.d). Et modinfo nous apprend que le module ftdi_sio a deux paramètres vendor et product permettant de spécifier ses propres identifiants, qui peuvent être ajoutés par modprobe. # modinfo -p ftdi_sio debug:Debug enabled or not (bool) vendor:User specified vendor ID (default=0x0403) (ushort) product:User specified product ID (ushort) ndi_latency_timer:NDI device latency timer override (int) Cela pourrait être rassemblé dans un fichier /etc/modprobe.d/ftdi_sio.conf : alias usb:v0403pEFE0d*dc*dsc*dp*ic*isc*ip* ftdi_sio options ftdi_sio vendor=0x0403 product=0xEFE0 A tester et vérifier. Je ne suis pas sûr s'il faut 0x devant les identifiants en hexadécimal. Pour finir, note qu tu aurais pu et pourrais encore demander à ce que tes identifiants personnalisés soient ajoutés au module ftdi_sio directement dans les sources du noyau, comme beaucoup d'autres semblent l'être déjà.
Danilo Uccelli
--0000000000006ef9900569b5df8c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Le 13 avril 2018 à 09:15, Pascal Hambourg a écrit :
Le 13/04/2018 à 07:31, Danilo Uccelli a écrit :
Effectivement un des problèmes était bien le manque de slash e t j'ai aussi bien compris la faille de sécurité que cela crée.
Quel manque de slash ? Tu veux dire qu'il manquerait un / entre /sbin et sh ? Sûrement pas, car /sbin/sh n'existe pas ; sh est dans /bin. J'ai donc donné à root la propriété du script.
Pas suffisant car le propriétaire non root du répertoire conten ant le script peut toujours le supprimer, le renommer et le remplacer par ce qu' il veut. Puis, j'ai réalisé que udev n'était pas la meilleure solut ion puisque il
suffit d'exécuter le script une seule fois au démarrage, ensui te le périphérique se monte tout seul. J'ai donc fait un crontab en root, au démarrage.
Il y a mieux qu'un cronjob, je trouve. Pour charger un module au démarrage, on peut le mentionner dans le f ichier /etc/modules. Pour qu'il soit chargé automatiquement lors de la détection d'i dentifiants donnés, on peut créer un alias pour modprobe (cf. man modprobe. d). Et modinfo nous apprend que le module ftdi_sio a deux paramètres ven dor et product permettant de spécifier ses propres identifiants, qui peuven t être ajoutés par modprobe. # modinfo -p ftdi_sio debug:Debug enabled or not (bool) vendor:User specified vendor ID (default=0x0403) (ushort) product:User specified product ID (ushort) ndi_latency_timer:NDI device latency timer override (int) Cela pourrait être rassemblé dans un fichier /etc/modprobe.d/ft di_sio.conf : alias usb:v0403pEFE0d*dc*dsc*dp*ic*isc*ip* ftdi_sio options ftdi_sio vendor=0x0403 product=0xEFE0 A tester et vérifier. Je ne suis pas sûr s'il faut 0x devant le s identifiants en hexadécimal. Pour finir, note qu tu aurais pu et pourrais encore demander à ce qu e tes identifiants personnalisés soient ajoutés au module ftdi_sio di rectement dans les sources du noyau, comme beaucoup d'autres semblent l'être d éjà.
Oui, c'est vrai, il est dans /bin, cependant il maquait bien le slash. Merci infiniment pour cette explication intéressante et détaill ée, je vais essayer tout ça. Danilo --0000000000006ef9900569b5df8c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Le 1 3 avril 2018 à 09:15, Pascal Hambourg <span dir="ltr"><<a href= "mailto:" target="_blank"></a >></span> a écrit :<br><blockquote class="gmail_quote" style="m argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class ="">Le 13/04/2018 à 07:31, Danilo Uccelli a écrit :<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1p x #ccc solid;padding-left:1ex"> <br> Effectivement un des problèmes était bien le manque de slash et j 'ai aussi<br> bien compris la faille de sécurité que cela crée.<br>
<br></span> Quel manque de slash ? Tu veux dire qu'il manquerait un / entre /sbin e t sh ? Sûrement pas, car /sbin/sh n'existe pas ; sh est dans /bin. <span class=""><br> <br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1p x #ccc solid;padding-left:1ex"> J'ai donc donné à root la propriété du script.<br>
<br></span> Pas suffisant car le propriétaire non root du répertoire contenan t le script peut toujours le supprimer, le renommer et le remplacer par ce qu'il veut.<span class=""><br> <br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1p x #ccc solid;padding-left:1ex"> Puis, j'ai réalisé que udev n'était pas la meilleure solution puisque il<br> suffit d'exécuter le script une seule fois au démarrage, ensu ite le<br> périphérique se monte tout seul. J'ai donc fait un crontab en root, au<br> démarrage.<br>
<br></span> Il y a mieux qu'un cronjob, je trouve.<br> Pour charger un module au démarrage, on peut le mentionner dans le fic hier /etc/modules.<br> Pour qu'il soit chargé automatiquement lors de la détection d 'identifiants donnés, on peut créer un alias pour modprobe (c f. man modprobe.d).<br> Et modinfo nous apprend que le module ftdi_sio a deux paramètres vendo r et product permettant de spécifier ses propres identifiants, qui peu vent être ajoutés par modprobe.<br> <br> # modinfo -p ftdi_sio<br> debug:Debug enabled or not (bool)<br> vendor:User specified vendor ID (default=0x0403) (ushort)<br> product:User specified product ID (ushort)<br> ndi_latency_timer:NDI device latency timer override (int)<br> <br> Cela pourrait être rassemblé dans un fichier /etc/modprobe.d/ftdi _sio.conf :<br> <br> alias usb:v0403pEFE0d*dc*dsc*dp*ic*i<wbr>sc*ip* ftdi_sio<br> options ftdi_sio vendor=0x0403 product=0xEFE0<br> <br> A tester et vérifier. Je ne suis pas sûr s'il faut 0x devant les identifiants en hexadécimal.<br> <br> Pour finir, note qu tu aurais pu et pourrais encore demander à ce que tes identifiants personnalisés soient ajoutés au module ftdi_sio directement dans les sources du noyau, comme beaucoup d'autres semblent l'être déjà.<br> <br> </div><br></div><div class="gmail_extra">Oui, c'est vrai , il est dans /bin, cependant il maquait bien le slash.</div><div class=" gmail_extra"><br></div><div class="gmail_extra">Merci infiniment pour cet te explication intéressante et détaillée, je vais essayer to ut ça.</div><div class="gmail_extra"><br></div><div class="gmail_e xtra">Danilo</div></div> --0000000000006ef9900569b5df8c--
Le 13 avril 2018 à 09:15, Pascal Hambourg <pascal@plouf.fr.eu.org> a écrit :
Le 13/04/2018 à 07:31, Danilo Uccelli a écrit :
Effectivement un des problèmes était bien le manque de slash e t j'ai aussi
bien compris la faille de sécurité que cela crée.
Quel manque de slash ? Tu veux dire qu'il manquerait un / entre /sbin et
sh ? Sûrement pas, car /sbin/sh n'existe pas ; sh est dans /bin.
J'ai donc donné à root la propriété du script.
Pas suffisant car le propriétaire non root du répertoire conten ant le
script peut toujours le supprimer, le renommer et le remplacer par ce qu' il
veut.
Puis, j'ai réalisé que udev n'était pas la meilleure solut ion puisque il
suffit d'exécuter le script une seule fois au démarrage, ensui te le
périphérique se monte tout seul. J'ai donc fait un crontab en root, au
démarrage.
Il y a mieux qu'un cronjob, je trouve.
Pour charger un module au démarrage, on peut le mentionner dans le f ichier
/etc/modules.
Pour qu'il soit chargé automatiquement lors de la détection d'i dentifiants
donnés, on peut créer un alias pour modprobe (cf. man modprobe. d).
Et modinfo nous apprend que le module ftdi_sio a deux paramètres ven dor et
product permettant de spécifier ses propres identifiants, qui peuven t être
ajoutés par modprobe.
# modinfo -p ftdi_sio
debug:Debug enabled or not (bool)
vendor:User specified vendor ID (default=0x0403) (ushort)
product:User specified product ID (ushort)
ndi_latency_timer:NDI device latency timer override (int)
Cela pourrait être rassemblé dans un fichier /etc/modprobe.d/ft di_sio.conf
:
alias usb:v0403pEFE0d*dc*dsc*dp*ic*isc*ip* ftdi_sio
options ftdi_sio vendor=0x0403 product=0xEFE0
A tester et vérifier. Je ne suis pas sûr s'il faut 0x devant le s
identifiants en hexadécimal.
Pour finir, note qu tu aurais pu et pourrais encore demander à ce qu e tes
identifiants personnalisés soient ajoutés au module ftdi_sio di rectement
dans les sources du noyau, comme beaucoup d'autres semblent l'être d éjà.
Oui, c'est vrai, il est dans /bin, cependant il maquait bien le slash.
Merci infiniment pour cette explication intéressante et détaill ée, je vais
essayer tout ça.
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Le 1 3 avril 2018 à 09:15, Pascal Hambourg <span dir="ltr"><<a href= "mailto:pascal@plouf.fr.eu.org" target="_blank">pascal@plouf.fr.eu.org</a >></span> a écrit :<br><blockquote class="gmail_quote" style="m argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class ="">Le 13/04/2018 à 07:31, Danilo Uccelli a écrit :<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1p x #ccc solid;padding-left:1ex">
<br>
Effectivement un des problèmes était bien le manque de slash et j 'ai aussi<br>
bien compris la faille de sécurité que cela crée.<br>
</blockquote>
<br></span>
Quel manque de slash ? Tu veux dire qu'il manquerait un / entre /sbin e t sh ? Sûrement pas, car /sbin/sh n'existe pas ; sh est dans /bin. <span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1p x #ccc solid;padding-left:1ex">
J'ai donc donné à root la propriété du script.<br>
</blockquote>
<br></span>
Pas suffisant car le propriétaire non root du répertoire contenan t le script peut toujours le supprimer, le renommer et le remplacer par ce qu'il veut.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1p x #ccc solid;padding-left:1ex">
Puis, j'ai réalisé que udev n'était pas la meilleure solution puisque il<br>
suffit d'exécuter le script une seule fois au démarrage, ensu ite le<br>
périphérique se monte tout seul. J'ai donc fait un crontab en root, au<br>
démarrage.<br>
</blockquote>
<br></span>
Il y a mieux qu'un cronjob, je trouve.<br>
Pour charger un module au démarrage, on peut le mentionner dans le fic hier /etc/modules.<br>
Pour qu'il soit chargé automatiquement lors de la détection d 'identifiants donnés, on peut créer un alias pour modprobe (c f. man modprobe.d).<br>
Et modinfo nous apprend que le module ftdi_sio a deux paramètres vendo r et product permettant de spécifier ses propres identifiants, qui peu vent être ajoutés par modprobe.<br>
<br>
# modinfo -p ftdi_sio<br>
debug:Debug enabled or not (bool)<br>
vendor:User specified vendor ID (default=0x0403) (ushort)<br>
product:User specified product ID (ushort)<br>
ndi_latency_timer:NDI device latency timer override (int)<br>
<br>
Cela pourrait être rassemblé dans un fichier /etc/modprobe.d/ftdi _sio.conf :<br>
<br>
alias usb:v0403pEFE0d*dc*dsc*dp*ic*i<wbr>sc*ip* ftdi_sio<br>
options ftdi_sio vendor=0x0403 product=0xEFE0<br>
<br>
A tester et vérifier. Je ne suis pas sûr s'il faut 0x devant les identifiants en hexadécimal.<br>
<br>
Pour finir, note qu tu aurais pu et pourrais encore demander à ce que tes identifiants personnalisés soient ajoutés au module ftdi_sio directement dans les sources du noyau, comme beaucoup d'autres semblent l'être déjà.<br>
<br>
</blockquote></div><br></div><div class="gmail_extra">Oui, c'est vrai , il est dans /bin, cependant il maquait bien le slash.</div><div class=" gmail_extra"><br></div><div class="gmail_extra">Merci infiniment pour cet te explication intéressante et détaillée, je vais essayer to ut ça.</div><div class="gmail_extra"><br></div><div class="gmail_e xtra">Danilo</div></div>
--0000000000006ef9900569b5df8c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Le 13 avril 2018 à 09:15, Pascal Hambourg a écrit :
Le 13/04/2018 à 07:31, Danilo Uccelli a écrit :
Effectivement un des problèmes était bien le manque de slash e t j'ai aussi bien compris la faille de sécurité que cela crée.
Quel manque de slash ? Tu veux dire qu'il manquerait un / entre /sbin et sh ? Sûrement pas, car /sbin/sh n'existe pas ; sh est dans /bin. J'ai donc donné à root la propriété du script.
Pas suffisant car le propriétaire non root du répertoire conten ant le script peut toujours le supprimer, le renommer et le remplacer par ce qu' il veut. Puis, j'ai réalisé que udev n'était pas la meilleure solut ion puisque il
suffit d'exécuter le script une seule fois au démarrage, ensui te le périphérique se monte tout seul. J'ai donc fait un crontab en root, au démarrage.
Il y a mieux qu'un cronjob, je trouve. Pour charger un module au démarrage, on peut le mentionner dans le f ichier /etc/modules. Pour qu'il soit chargé automatiquement lors de la détection d'i dentifiants donnés, on peut créer un alias pour modprobe (cf. man modprobe. d). Et modinfo nous apprend que le module ftdi_sio a deux paramètres ven dor et product permettant de spécifier ses propres identifiants, qui peuven t être ajoutés par modprobe. # modinfo -p ftdi_sio debug:Debug enabled or not (bool) vendor:User specified vendor ID (default=0x0403) (ushort) product:User specified product ID (ushort) ndi_latency_timer:NDI device latency timer override (int) Cela pourrait être rassemblé dans un fichier /etc/modprobe.d/ft di_sio.conf : alias usb:v0403pEFE0d*dc*dsc*dp*ic*isc*ip* ftdi_sio options ftdi_sio vendor=0x0403 product=0xEFE0 A tester et vérifier. Je ne suis pas sûr s'il faut 0x devant le s identifiants en hexadécimal. Pour finir, note qu tu aurais pu et pourrais encore demander à ce qu e tes identifiants personnalisés soient ajoutés au module ftdi_sio di rectement dans les sources du noyau, comme beaucoup d'autres semblent l'être d éjà.
Oui, c'est vrai, il est dans /bin, cependant il maquait bien le slash. Merci infiniment pour cette explication intéressante et détaill ée, je vais essayer tout ça. Danilo --0000000000006ef9900569b5df8c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Le 1 3 avril 2018 à 09:15, Pascal Hambourg <span dir="ltr"><<a href= "mailto:" target="_blank"></a >></span> a écrit :<br><blockquote class="gmail_quote" style="m argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class ="">Le 13/04/2018 à 07:31, Danilo Uccelli a écrit :<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1p x #ccc solid;padding-left:1ex"> <br> Effectivement un des problèmes était bien le manque de slash et j 'ai aussi<br> bien compris la faille de sécurité que cela crée.<br>
<br></span> Quel manque de slash ? Tu veux dire qu'il manquerait un / entre /sbin e t sh ? Sûrement pas, car /sbin/sh n'existe pas ; sh est dans /bin. <span class=""><br> <br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1p x #ccc solid;padding-left:1ex"> J'ai donc donné à root la propriété du script.<br>
<br></span> Pas suffisant car le propriétaire non root du répertoire contenan t le script peut toujours le supprimer, le renommer et le remplacer par ce qu'il veut.<span class=""><br> <br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1p x #ccc solid;padding-left:1ex"> Puis, j'ai réalisé que udev n'était pas la meilleure solution puisque il<br> suffit d'exécuter le script une seule fois au démarrage, ensu ite le<br> périphérique se monte tout seul. J'ai donc fait un crontab en root, au<br> démarrage.<br>
<br></span> Il y a mieux qu'un cronjob, je trouve.<br> Pour charger un module au démarrage, on peut le mentionner dans le fic hier /etc/modules.<br> Pour qu'il soit chargé automatiquement lors de la détection d 'identifiants donnés, on peut créer un alias pour modprobe (c f. man modprobe.d).<br> Et modinfo nous apprend que le module ftdi_sio a deux paramètres vendo r et product permettant de spécifier ses propres identifiants, qui peu vent être ajoutés par modprobe.<br> <br> # modinfo -p ftdi_sio<br> debug:Debug enabled or not (bool)<br> vendor:User specified vendor ID (default=0x0403) (ushort)<br> product:User specified product ID (ushort)<br> ndi_latency_timer:NDI device latency timer override (int)<br> <br> Cela pourrait être rassemblé dans un fichier /etc/modprobe.d/ftdi _sio.conf :<br> <br> alias usb:v0403pEFE0d*dc*dsc*dp*ic*i<wbr>sc*ip* ftdi_sio<br> options ftdi_sio vendor=0x0403 product=0xEFE0<br> <br> A tester et vérifier. Je ne suis pas sûr s'il faut 0x devant les identifiants en hexadécimal.<br> <br> Pour finir, note qu tu aurais pu et pourrais encore demander à ce que tes identifiants personnalisés soient ajoutés au module ftdi_sio directement dans les sources du noyau, comme beaucoup d'autres semblent l'être déjà.<br> <br> </div><br></div><div class="gmail_extra">Oui, c'est vrai , il est dans /bin, cependant il maquait bien le slash.</div><div class=" gmail_extra"><br></div><div class="gmail_extra">Merci infiniment pour cet te explication intéressante et détaillée, je vais essayer to ut ça.</div><div class="gmail_extra"><br></div><div class="gmail_e xtra">Danilo</div></div> --0000000000006ef9900569b5df8c--
