Newsgroup: it.comp.os.linux.iniziare
Titolo: Regola UDEV e problemi con virgolette

Sto invano cercando di far funzionare una regola udev in modo che quando
attacco una chiavetta usb venga caricato un certo modulo del kernel e il
dispositivo venga poi aggiunto tra quelli gestiti dallo stesso modulo.
I comandi precisi sarebbero i seguenti, vi riporto direttamente lo
script, tanto sono due righe.
 
 
/usr/local/bin/olicard300-option.sh
------------------------------------
#!/bin/sh
 
/sbin/modprobe option
/usr/bin/echo "2020 4000" /sys/bus/usb-serial/drivers/option1/new_id
---------------------------------------------------------------------
 
 
La regola di UDEV invece è la seguente (vado a capo con "\"):
 
 
/etc/udev/rules.d/89-olicard300-option.rules
---------------------------------------------
SUBSYSTEMS=="usb", \
ATTRS{idVendor}=="2020", ATTRS{idProduct}=="4000", \
ATTRS{manufacturer}=="Network Connect", \
ATTRS{product}=="MT6225 ", \
RUN+="/usr/local/bin/olicard300-option.sh"
------------------------------------------------------
 
 
Ora, così funzionerebbe anche, ma volevo eliminare la necessità
dello script bash ausiliario, visto che vengono lanciati solo
due comandi in croce...
 
In pratica sto tentando di modificare la key "RUN+=" in modo che
contenga entrambi i comandi.
Leggendo in rete vedo che alcuni fanno anche così:
 
RUN+="/bin/sh -c 'comando1 comando2 etc'"
 
Nel mio caso salterebbe fuori qualcosa del genere (vado a capo con "\"):
 
RUN+="/bin/sh -c '/sbin/modprobe option; \
/usr/bin/echo \'2020\ 4000\\' > /sys/bus/usb-serial/drivers/option1/new_id'"
 
 
Se dal prompt della shell lancio il comando a mano:
 
$ /bin/sh -c 'eccecc'
 
funziona tutto senza problemi.
Invece da dentro la regola udev funziona solo il primo comando, ovvero
il "modprobe", mentre l'echo fallisce.
 
 
Ho provato a semplificare le cose per cercare di capirci:
 
RUN+="/bin/sh -c 'echo \'pippo\ pluto\\' > /tmp/paperopoli.log'"
 
 
Verifico che il comando funizoini da shell:
-----------------------------------------------------------
$ /bin/sh -c 'echo \'pippo\ pluto\\' > /tmp/paperopoli.log'
$ cat /tmp/paperopoli.log
pippo pluto
$ rm /tmp/paperopoli.log
------------------------
 
 
Ok, il comando funziona.
Ma se provo ad aggiornare le regole udev e staccare/riattaccare la
chiavetta, il comando non viene eseguito correttamente perchè in /tmp
non viene creato alcun file:
----------------------------
# udevadm control --reload
# cat /tmp/paperopoli.log 
cat: /tmp/paperopoli.log: File o directory non esistente
---------------------------------------------------------
 
dopo diversi tentativi sono arrivato ad una versione più semplice del
comando, ovvero ho rimosso le "single quotes" cioè gli apici singoli
dalla stringa stampada da echo:
 
------------------
RUN+="/bin/sh -c '                                       \
/usr/bin/echo paperino\ paperone > /tmp/paperopoli.log ; \ 
/usr/bin/echo pippo\ pluto >> /tmp/paperopoli.log'"
----------------------------------------------------------
 
È tutto su una riga nel file .rules.
E staccando/riattaccando la chiavetta dopo aver aggiornato
le regole udev:
 
--------------------------
# cat /tmp/paperopoli.log 
paperino paperone
pippo pluto
-------------------------
 
Finalmente sembra che quella sia la strada giusta.
 
Però mi chiedo....
Ma come ci si regola con eventuali apici all'interno
della key "RUN" ??
 
E come fare a monitorare quello che sta facendo udev
con quella regola?
 
Non so se è chiara la domanda....
Ad ogni modo provo a modificare la regola originale
togliendo gli apici dell'echo e semplicementa introducendo
l'escape dello spazio, vediamo se funge...
 

 RUN+="/bin/sh -c 'comando1 comando2 etc'"
puoi usare solo un RUN+ nelle regole?
 
ciao e buon linux
 

 ------------------------------------------------------
 
In quelle chiavette ci dovrebbe essere una directory nominata "Linux"
dentro la quale c'e` tutto l'occorrente per farla funzionare; perche`
non la usi?
 
Tra l'altro non c'e` traccia del modulo option, invece leggo:
 
modprobe -r usbserial
modprobe usbserial vendor=0x$VENDOR product=0x$PRODUCT
 


Il modulo usbserial che hai citato è da evitare e va lasciato come
ultima spiaggia da quanto ho letto in giro da fonti anche abbastanza
attendibili tipo il forum del progetto usb_modeswitch.
 
Il modulo "option" è stato creato proprio per supplire a varie limitazioni
del vecchio usbserial. È scritto anche nel sorgente (option.c o giù di
lì... ho dato un'occhiata sul sito del kernel, 
kernel.org
).
 
Per fare in modo che il device in questione cioè "2020:4000"
venga preso in consegna dal driver "option", basta stampare
vendor e product id sul file "new_id" come ho spiegato sopra.
 
È vero: la chiavetta al suo interno contiene una dir nominata
"linux-qualcosa.tar.gz". Quando è ancora vista come "Zero CD" e ha
nel mio caso id vendor e product "2020:0002" viene associata ad
un device simi CD tipo /dev/sr0 o /dev/sr1 a seconda che il PC
abbia già un lettore CD o meno.
Basta montare /dev/sr1 e guardarci dentro, poi si copia il contenuto
da qualche parte tipo in /tmp, si scompatta e al suo interno c'è un
banale "install.sh".
 
Personalmene ho dato un'occhiata a come funziona, ma lo trovo
parecchio incasinato e alla fine sai cosa fà:
utilizza il vecchio usbserial come hai riportato anche tu.
 
Però informandomi un po' in rete ho visto che "option" è
una soluzione migliore.
 
Tra l'altro nel mio caso, alla chiavetta vengono associati
ben 5 /dev/ttyUSB* e il modem HSPA viene collegato alla terza
(/dev/ttyUSB2) mentre le prime due, cioè USB0 e USB1 servirebbero
per la "mobile broadband", connessione via direct ethernet (dovrebbe
funzionare con libmbim in questo caso, anche se non sono ancora riuscito
a cavarci niente).
La USB3 invece dovrebbe servire tipo per inviare SMS quando la
connessione su USB2 è già attiva.
Le altre due sinceramente non ricordo, spetta...
 
---------------------------------------------
MI_00 Network Connect Mobile Broadband Device
MI_01 Network Connect Mobile Broadband Device 
MI_02 Network Connect HSPA Plus Modem
MI_03 Network Connect HSPA Plus Application Interface
MI_04 Network Connect HSPA Plus Speech Port
MI_05 Network Connect HSPA Plus Debug Port
MI_06 USB Mass Storage Device
-----------------------------
 
Questo specchietto me l'hanno passato qua:
 
http://www.draisberghof.de/usb_modeswitch/bb/viewtopic.php?f=3&t=2273
 
 
L'ultima, la 6, mi pare venga disattivata quando si esegue lo switch
da Zero CD a funzionlità Modem/ecc.
 
Io l'ho capita grosso modo così...

 puoi usare solo un RUN+ nelle regole?
 
Guarda sinceramente non sono ferratissimo sulla sintassi delle regole.
Da come ho capito, se ho capito bene il man, si potrebbe anche mettere:
 
RUN=comando1, RUN+=comando2
 
In questo caso potrebbe venire fuori qualcosa del genere:
----------------------------
RUN="/sbin/modprobe option",             \
RUN+="/usr/bin/echo '2020 4000' >        \
/sys/bus/usb-serial/drivers/option1/new_id
------------------------------------------
 
 
 
Però spezzando così i due comandi non sono sicuro che venga eseguito
prima il modprobe e solo dopo l'echo. E questo è necessario perchè
altrimenti il file new_id e parte del suo "path" non esisterebbero
ancora.
La formula:
 
RUN+="/bin/sh -c 'serie di comandi'"
 
(o anche "RUN=" senza il "+", dovrebbe funzionare ma non ho provato...)
 
...mi assicura che la serie di comandi venga eseguita in ordine.
Invece lo spezzatino con diversi:
 
RUN="comando1", RUN+="comando2", RUN+="comando3" ecc
 
non so per mia ignoranza se sesegue in ordine:
comando 1
comando 2
comando 3
 
Forse sì... Se mi confermate uqesto allora sarebbe una situazione più
pulita immagino.

 con quella regola?
 
Edita nel terminale
# udevadm monitor
e poi inserisci la chiavetta.
 
 


Questo si... però non vedi tipo i comandi passati alla shell
per capire cosa viene impartito e se è andato a buon fine.
Col comando sopra vedi colo cosa è successo attaccando la chiavetta
in termini di eventi vari... o sbaglio?
 
Guardavo se vi era qualcosa che dicesse di più...
Grazie ad ogni modo.