Newsgroup: it.comp.os.linux.sys
Titolo: Simulare distacco e reinserimento device usb

Mi connetto ad internet con un cellulare edge/gprs via usb.
A volte la connessione si blocca, senza disconnettersi.
Allora mi disconnetto normalemte killando il processo che tiene
su l'interfaccia ppp0.
Tuttavia spesso questo non basta per uccidere anche pppd che
resta lì a far niente (è sempre dovuto al device bloccato visto
che pppd lavora su quel file speciale /dev/ttyACM0).
Se a quel punto forzo la situazione killando pppd, trovo che
il modem è in uno stato di blocco:
- la riconnessione non funziona, pur riprovando diverse volte
Visto che è un po' che uso questi aggeggi dividerei i problemi.
Perchè non si riconnette?
1- il device è in uno stato di "tilt" per quanto riguarda la
   comunicazione gprs.
2- la comunicazione tra pc e modem è corrotta in qualche modo:
    - minicom non riesce a comunicarvi e se provo devo killare
      forzosamente anche lui.
Il punto 1 accade tutte le volte che la connessione si blocca in
questo modo...cioè la colpa è del cellulare/rete gprs.
Il punto due a cadenza random si manifesta come conseguenza del
punto 1, ma non sempre: a volte il kill di pppd o anche la
semplice disconnessione, causa il ripristino della comunicazione
pc-usb-cell. Quando questo accade siamo fortunati in quanto
minicom riesce a comunicare col modem e spessoquesto consente di
tentare lo sblocco della situazione cellulare-retegprs mediante
vari comandi at, tra cui chiamate a numeri di telefono ecc che di
solito sbloccano il cellulare.
Ok.
Ma quando si verifica anche la situazione 2, come fare a
sbloccare la comunicazione modem-usb-pc?
Ho notato che qusi sempre funziona una manovra non molto
elegante:
 staccare e riattaccare il cavo usb dal pc.
Voglio fare però via software questa operazione.
come procedere?
provo a scaricare e ricaricare i moduli cdc-acm che
governano il dispoditivo (con usbserial comunque è uguale...).
Capita che a volte questa manovra ripristini la comunicazione, ma
spesso fallisce miseramente.
Nel kernel della slackware-11 che avevo prima, avevo praticamente
risolto scaricando e ricaricando il modulo:
ohci_hcd
Non so se è meglio prendersela con l'ehci_hdc...oppure con quello
sopracitato. Fatto sta che comunque funzionava.
Ora sulla slack 12.1 sono partito con un kernel huge. dal make
menuconfig ho notato che quei ohci_hdci ed ehci_hcd sono
compilati builtin. Quindi il giochetto con modprobe non posso più
farlo (a meno di ricompilarli come moduli).
Se avete avuto la pazienza di leggere questo lungo antefatto, a
questo punto vi chiederei la domanda in oggetto:
volendo simulare il distacco e riattacco di un device usb, come
posso comportarmi alla luce di quanto detto sulla situazione
dell'attuale kernel?
______________________________
johnnynews at vfemail dot net

 dell'attuale kernel?
direi che ricompialrlo e e mettere i sopracitati come moduli
in ogni caso, ma quesi dispositivi non sono visti come usb-seriali?
non caso potresi provare a fare quelo giochtto con usbserial...
cmq prova a fare così
dmesg|grep ACM, e li dovresti vedere quale è il modulo che realmente
riconosce il device quando lo attacchi

 non caso potresi provare a fare quelo giochtto con usbserial...
ma come minchia scrivo?
è troppo caldo.....


Una cosa del genere serve anche a me.
Secondo me la soluzione migliore è cercare di togliere la corrente via usb
al dispositivo attraverso un qualche comando, ma non ho ancora avuto modo
di guardarci. Poi dicci come hai risolto...

 di guardarci. Poi dicci come hai risolto...
Da quanto ho letto da qualche parte 'sta feature c'era nel kernel, poi 
l'han tolta mi pare...
Enrico

 riconosce il device quando lo attacchi
l'ho staccato e al riattacco, queste sono le 3 righe che si sono
aggiunte al file /var/log/messages:
======
Aug  7 16:18:37 slack-12 kernel: usb 2-2: new full speed USB \
                         device using ohci_hcd and address 4
Aug  7 16:18:37 slack-12 kernel: usb 2-2: configuration #1   \
                                        chosen from 1 choice
Aug  7 16:18:37 slack-12 kernel: cdc_acm 2-2:1.1: ttyACM0:   \
                                              USB ACM device
=====
Mi pare di capire che usa il modulo ohci_hcd come "controler usb"
(si dice così?). E i cdc_acm come driver per il device.
Comunque vediamo anche il dmesg
=====
dmesg |grep ACM
cdc_acm 2-2:1.1: ttyACM0: USB ACM device
cdc_acm 2-2:1.1: ttyACM0: USB ACM device
cdc_acm 2-2:1.1: ttyACM0: USB ACM device
=====
Ok... e fin qui lo sapevamo...sono in uso i cdc-acm. e il device
corrisponde al file speciale è /dev/ttyACM0.
-
restano le domande però:
- c'è un modo migliore ma comunque efficace per simulare il
   distacco usb oppure l'unica è ricompilare il kernel mettendo
   ochi_hdc come modulo? Ed eventualmente tale ricompiazione
   potrebbe avere effetti indesiderati? oppure si può fare senza
   preoccuparsi troppo?



Scusa ma non ho rispsoto senza prima leggere anche questo 



Si, penso anch'io, in quel modo dovrebbe simulare perfettamente
la manovra "stacca-riattacca".
Però non ho veramente idea di come realizzarla via software.
Limitatamente al discorso del cellulare, la comunicazione cell PC
praticamente viene sempre ripristinata scaricando e ricaricando
il modulo ohci_hcd. Il problema poi è ripristinare la
comunicazione tra cell e rete gprs, lì a volte fallisce tutto
miseramente....ma dipende molto anche dalla rete, dicono che umts
vada meglio. Comunque spegnendo e riaccendendo il cell si
ripristina anche quella (peccato non sia possibile farlo via
software...avevo letto qualcosa sul comando AT+CFUN ma a quanto
pare il nokia 6230 non lo supporta.
Saluti, se avete idee non esitate ad intervenire eh...  ;-)


 compilate mofularmente e ora invece le mette builtin?
Perche`, in teoria, builtin sono piu` veloci (non c'e` il context switch
con LKM). Che poi sia da te ritenuto una boiata... beh, il compilatore
e` da quella parte[1]...
Enrico
[1] Hai voluto Slackware? Sopportala :P

 [1] Hai voluto Slackware? Sopportala :P
Qualcosa si deve pur sopportare!  :-P
anche a costo di affrontare il *dramma* della ricompilazione del
kernel.... ;-)


 il *dramma* della ricompilazione del kernel.... ;-)
Se hai una macchina decente non più di venti minuti per configurare, 
compilare ed installare un kernel.  Non lo chiamerei un dramma :-)
E poi è più sopportabile una Slackware dove ti puoi gestire la 
macchina o quelle distribuzioni Windows style dove non sai mai cosa i 
tool di aggiornamento stanno facendo.
Ciao
Giovanni
-- 
   A computer is like an air conditioner,
   it stops working when you open Windows.
   Registered Linux user #337974  < 
http://giovanni.homelinux.net/
 >

 tool di aggiornamento stanno facendo.
Concordo, soprattutto per un uso a livello più avanzato.


 
Io ho avuto in passato parecchi guai con la chiavetta USB per il 
wi-fi.  Usavo ndiswrapper che supporta il driver fornito per WinXP non 
essendoci il supporto sotto Linux.  Ogni tanto si bloccava e dovevo 
togliere la chiavetta per far ripartire il wi-fi e avere la 
connessione.  Rimuovendo il modulo ndiswrapper ottenevo lo stesso 
effetto anche se qualche volta mandava in crash il sistema.
Rimuovendo il driver e ricaricandolo dovrebbe far cadere e poi 
ripristinare la connessione.  Scrivo dovrebbe perché non ho la 
garanzia che funzioni in modo analogo.


 garanzia che funzioni in modo analogo.
Fin qui t'avevo seguito nel discorso  ;-)
Ma a quale modulo ti riferisci? È su questo che volevo una
conferma  :-)


Ciao JonnyNewbie.
Hai avviato un thread piuttosto interessante e sei stato anche molto chiaro
nell'esprimerti strutturando sequenzialmente le domande che ti sei posto
(il che mi fa pensare anche che tu non sia "esattamente" un "newbie" ;-) ).
Ti dico quello che il tuo post e i successivi del thread mi
hanno "ispirato".
1) Il malfunzionamento del tuo cellulare (blocco dell'upstream/downstream) è
(quasi) certamente imputabile al mancato aggiornamento del firmware. Può
darsi che si verifichi solo quando fai upload corposi. Il driver cdc_acm
comunque non mi risulta abbia questo problema del blocco (è un driver
piuttosto semplice, che delega la maggior parte dei controlli al firmware
del dispositivo 3G), problema che si presenta invece nell'accoppiata fra
altri driver e altri modem 3G.
2) Hai fatto bene a porti il problema teorico della simulazione del distacco
di un device USB, ma, da un lato, temo che non ci sia altra soluzione che
quella che hai già pensato tu, cioè la rimozione del modulo che fa da
controller USB (il che implica che il controller sia compilato come
modulo "pluggable"); dall'altro lato, trattandosi di un cellulare (diverso
sarebbe se si trattasse di un modem USB privo dello switch per il power
on/off), ti basta spegnere e riaccendere il cellulare e il gioco è fatto.
3) Il kill che usi per uscire dell'impasse e tutto quanto hai scritto ("la
comunicazione tra pc e modem è corrotta in qualche modo:..."; "come fare a
sbloccare la comunicazione modem-usb-pc?..." ; "provo a scaricare e
ricaricare i moduli cdc-acm che governano il dispoditivo...") mi fanno
pensare (soprattutto me lo fanno pensare sia il fatto che spesso non basti
scaricare il driver cdc_acm che pilota il modem, sia il fatto che anche
usando usbserial la situazione non cambi) che il nocciolo del problema stia
proprio ***nel firmware*** del cellulare/modem (cioè in una sua
incompatibilità col driver Linux, ma la "colpa" è spesso dei device, cioè
del modo in cui il firmware dei device implementa le specifiche ufficiali
di comunicazione). Probabilmente è qualcosa che riguarda il controllo di
flusso: tipo buffer sovraccarico. Se anche la via di un comando AT [*]
inviato con Minicom (ma il cellulare, quando è in tilt accetta comandi in
input?) non riesce a sbloccare la situazione, l'unica via d'uscita è un
reset hardware del modem (spegnere il cellulare), o un reset del BUS di
comunicazione, che puoi fare anche togliendo e ricaricando poi,
con "modprobe -r" e "modprobe", il controller USB. Ma qui allora torniamo
al punto di partenza; forse non c'è via d'uscita: o spegni e riaccendi il
cellulare, o rimuovi il controller USB e poi lo ricarichi (ma devi avere i
moduli compilati come loadable).
[*]
Se non lo conosci già, dai un'occhiata a questo documento (non si sa mai):
http://www.forum.nokia.com/info/sw.nokia.com/id/95672052-6c77-488d-a055-acef77e4cdc5/AT_Command_Set_For_Nokia_GSM_And_WCDMA_Products_v1_2_en.pdf.html

 proprio ***nel firmware*** del cellulare/modem (cioè in una sua
[cut]
A conferma di quanto sopra affermato porto la mia esperienza: ho un 
disco esterno USB che in determinate condizioni non viene più rilevato 
dal sistema.
Purtroppo anche scaricando il modulo con modprobe non si ottiene alcun 
effetto: va disconnesso fisicamente.
-- 
Fa freddo nello scriptorium, il pollice mi duole. Lascio questa 
scrittura, non so per chi, non so più intorno a che cosa...
U. Eco

 builtin sarebbe una boiata?
Se ho frainteso la tua frase, offendendoti, ti chiedo scusa. Il punto,
pero`, e` che da quello che vedo _tutti_ gli utilizzatori di Slackware
prendono per oro colato le decizioni prese da Volkerding. Questa storia
del modulo USB compilato ne e`un perfetto esempio. Probabilmente Patrick
lo ha compilato statico per i propri comodi (e.g. perche` ha un disco
USB), lo ha messo nella distribuzione e lo ha messo a disposizione. Ora,
io non dico che questo comportamento sia sbagliato (la distribuzione e`
sua, e fa come gli pare), ma non posso nemmeno dire che non crea
problemi agli utilizzatori di Slackware (e tu ne sei un perfetto
esempio). Il problema e` pero` dato dal fatto che molti prendono queste
decisioni come oro colato, e non gli interessa se sono giuste o
sbagliate: dopo tutto, ha scelto Patrick Volkerding
Enrico

 sbagliate: dopo tutto, ha scelto Patrick Volkerding
Vero , pero' succede solo ai "newbie" , chi usa slack da >3 anni sa' che per
prima cosa e' bene ricompilarsi il kernel su misura , visto che quelli di
default sono appunto "generic" , poi c'e' la solita questione "monolitico o
modulare?", io opto per i moduli (sul mio desktop), inoltre sono quasi
obbligato visto che la mia scheda wifi PCI non ne vuole sapere di
funzionare in WPA col driver rt61pci del vanilla , si certo posso metterlo
in /etc/modprobe.d/blacklist , ma preferisco ricompilare il tutto ed
eliminarlo (uso rt61 di serialmonkey ,
http://tinyurl.com/drnvg
) .
-- 
Unfirmed

 sbagliate: dopo tutto, ha scelto Patrick Volkerding
Meglio se le decisioni le prende PV piuttosto che lasciarle pendere al 
malefici apt-get, yast o rpm.


 effetto: va disconnesso fisicamente.
Aspetta: questo che hai portato ad esempio è un altro discorso.
Apro un nuovo thread: "Disco esterno USB: riconoscimento"

 moduli compilati come loadable).
Dimenticavo, dandola un po' troppo per scontata, di menzionare l'opzione
dell'aggiornamento del firmware del cellulare, sempre che ciò sia
possibile.

 sbagliate: dopo tutto, ha scelto Patrick Volkerding
Può darsi...ma non è il mio caso, tant'è che ho chiesto qui per
capirci di più, senza dare per scontato nulla.
Detto questo, ripeto, nessuna offesa tranquillo. Ma volevo solo
fare chiarezza sul mio post.

 AT_Command_Set_For_Nokia_GSM_And_WCDMA_Products_v1_2_en.pdf.html
Sì, ce l'ho:
=====
$ ls doc/dialup/
AT_Command_Set_For_Nokia_GSM_And_WCDMA_Products_v1_2_en.pdf
..
..
=====
;-)
grazie comunque, ottimo documento anche se un po' criptico in
certi casi.
Quel documento però serve nella "fase 2" (ripristino
comunicazione cellulare---rete-gprs) non nella prima fase in cui
bisogna assicurarsi che la comunicazione cell---pc sia sana.
Le due cose penso siano da considerare in modo distinto ed
indipendente no?
Comunque, gia che siamo in argomento, ho tentato di simulare lo
spegnimento del telefono, o per lo meno della comunicazione radio,
col comando AT+CFUN, ma a quanto pare il mio modello non lo
supporta...così ho lasciato perdere.
Ho notato comunque che sono efficaci anche i comandi at+cgatt,
per resettare la rete gprs, ma non sempre funzionano neanche
loro.
Mi veniva in mente il discorso della sveglia:
metto la sveglia
spengo il telefono
poi suona accendendosi da solo
Quindi nel telefono deve esserci una memoria che sta in qualche
misura attiva e fa girare almeno un orologio...giusto?
Ecco sarebbe interessante riuscire a controllare quella memoria
via AT o comandi del genere dicendo al modem, spegniti, aspetta
un 10 secondi e riaccenditi. Questa operazione si potrebbe
includere nello script che dicevo e usarla come ultima spiaggia
nel caso in cui dopo tutte le manovre "soft" l'interfaccia ppp0
continuasse ad essere down.
E' solo un'idea tanto per dire, perchè non penso sia pssibile
dare un ordine del genere al cellulare via AT.
Rinnovo comunque il ringrazziamento per il tuo intervento molto
chiaro e puntuale. Spero in altri tuoi interventi, per eventuali
altri aspetti che ho tirato in ballo.
Saluti.   :-)

 indipendente no?
Direi di sì.
Se fai progressi tienici aggiornati.

Solo per dire che forse una soluzione diversa da quelle già dette (rimozione
del modulo e scollegamento fisico del device) esiste.
E' da un po', infatti, che pensavo al ***sistema di hotplug*** come un
qualcosa che potrebbe contenere la soluzione per questo tipo di problemi.
Infatti, anche a me (e sicuramente a molti altri) interessa capire se è
possibile simulare un distacco di un device e di suo reinserimento in modo
che riparta la procedura di hotplug.
Nel mio caso si tratta degli hard disk USB che, quando avvio la connessione
via modem (del cellulare: HSDPA, Nokia 6120) collegato a una porta USB,
vengono scollegati per ordine del kernel:
---
linux hald: unmounted /dev/sda1 from '/media/RECOVERY' on behalf of uid 0
---
Il motivo per cui questo avvenga non lo so, ma ha sicuramente a che fare col
Nokia (forse c'entra un "sovraccarico" del sistema USB?).
Fatto sta che, se abbatto la connessione via Nokia e avvio in parallelo alla
sessione in corso un'altra sessione facendo un login come altro utente, la
procedura di hotplug dei dischi USB riparte.
Se "switcho" (ctrl-alt-F7) sull'altra sessione (quella iniziale) e poi
digito mount le partizioni dei dischi USB sono montate (cioè la procedura
di automount ha dato i suoi effetti a seguito dell'hotplug al momento del
nuovo login). Torno (ctrl-alt-F8) sulla nuova sessione ed esco. Ora sono
nella sessione iniziale: di nuovo mount... le partizioni non ci sono più.
Infatti in /var/log/messages c'è:
---
linux hald: unmounted /dev/sda1 from '/media/RECOVERY' on behalf of uid 1001
---
(1001 è l'altro utente del secondo login)
Quindi, nella mia distro (SuSE 10.2) ci sono degli script che generano un
evento di hotplug all'avvio di una sessione, ma anche di unplug, direi,
all'uscita. OK, niente di nuovo, ma devo capire meglio il funzionamento del
tutto.
Se vuoi cimentarti anche tu, puoi leggere questo documento:
http://en.opensuse.org/SDB:SUSE_Linux_Hotplug_System_Overview
Si riferisce a OpenSuSE, però le linee portanti dovrebbero valere a
prescindere dalla distro.
Il punto è capire come generare un evento di hotplug (in e out).
Che ne pensi?
==> Non potrebbe valere anche per il tuo problema? Cioè per ***simulare il
distacco del telefonino***?
(nel mio caso, il kernel smonta le partizioni del disco USB perché, se
capisco bene, simula un distacco del disco per un motivo tecnico legato al
funzionamento dell'HUB USB; mi sa che c'entra l'assorbimento di energia: è
come se il telefonino, nonostante sia alimentato da batteria, togliesse
agli HD l'energia che necessita loro per funzionare e che prelevano dal
cavo USB, oppure c'è di mezzo qualcosa che riguarda il funzionamento dei
BUS USB, legato sempre ai flussi di energia)
Se qualcuno ha info utili in proposito, BEN VENGANO !

 Se qualcuno ha info utili in proposito, BEN VENGANO !
Mi accodo anch'io alla richiesta.

 device.
Questo è dovuto al fatto che il modulo cdc_acm è un driver "di secondo
livello" rispetto a ohci_hcd (o a uhci_hcd o a ehci_hcd), cioè rispetto al
modulo che fa da controller per il device USB.
cdc_acm si occupa solo della gestione del collegamento 3G, cioè della
comunicazione col chipset che presiede alla comunicazione 3G.
ohci_hcd (o uhci_hcd o ehci_hcd) è necessario affinché cdc_acm possa entrare
in gioco, perché senza di lui la comunicazione col device USB non è
possibile. In altre parole: prima il kernel deve occuparsi di comunicare
col device via USB. E a questo presiede il controller (OHCI, UHCI o EHCI).
Poi viene in ballo la funzione specifica del device nella forma del chipser
modem 3G. E a questo pensa cdc_acm (o altro driver idoneo).
MORALE: il display si accende quando la comunicazione col device USB riesce
via controller USB, cioe via modulo ohci_hcd (o uhci_hcd o ehci_hcd).
La SIMULAZIONE DI EVENTO DI HOTPLUG riguarderebbe dunque il controller USB,
proprio come se tu staccassi il telefonino dalla porta USB. cdc_acm in
questo non c'entra (è --appunto-- un driver "di secondo livello", che si
occupa della funzione specifica del "pezzo di ferro", non del fatto che la
comunicazione via USB col "pezzo di ferro" riesca).
==> Se qualcuno ha seguito il thread fin qui e ne sa più di noi sul sistema
di hotplug, a questo punto (direi)... prego, parli pure :-)

 di hotplug, a questo punto (direi)... prego, parli pure :-)
Non posso che unirmi all'appello.

 Quindi togliendo realmente corrente al device oppure no?
No: vale quanto hai detto tu sopra, cioè il distacco fisico comporta una
perturbazione anche a livello di corrente elettrica.

 sistema rende la cosa molto "naturale", 
Senza offesa, ma la ricompilazione del kernel non la vedo come una cosa
"naturale", e sinceramente non vedo quale sia la semplicita`, ad
esempio, rispetto ai meccanismi presenti in Debian, Gentoo, Red Hat
Enrico

 nell'installazione.
Non installo ed uso qualcosa che non mi piace (sia per motivi tecnici
che per motivi filosofici), a meno che non sia costretto. Detto questo,
cio` che ho scritto e` dovuto alla mia interpretazione delle parole di
Johnny, che lamentava che il kernel era compilato in modo particolare
(ovvero con alcune parti statiche invece di modulari). Ora, una cosa del
genere su le distribuzioni da te denigrate non succede, e non perche`
sono piu` fighe, ma perche` hanno una politica dietro proprio per queste
evenienze. Detto questo, posso comunque affermare che:
- Quello detto da Unlocked risulta falso (a meno che non vogliamo
  considerarti l'eccezione che conferma la regola);
- Come al solito non accetti critiche quando sei il primo a criticare
  gli altri;
- Ha ragione Adamo: l'animo del flamer ce l'ho nel sangue :)
Enrico

 wrote:

Mi riferivo nel particolare all'utilizzo di un kernel vanilla
intonso, tutto qui. Su debian (che non conosco e quindi non ho
voce in capitolo) ho letto che invece si opta per l'applicazione
di patch (che sicuramente avroanno il loro perchè, non lo metto
certo in dubbio). Quello che intendevo è che se si usa Debian e
la si usa in modo avanzato svolgendo compiti anche solo come la
ricompilazione del kernel, probabilmente bisogna tenere in conto
che il sistema si aspetta un kernel con certe caratteristiche
(patch ecc ecc), d'altra parte debian gestisce di suo, in modo
più evoluto l'aggiornamento, l'installazione/rimozione pacchetti,
rispetto a Slackware...questo la rende intrinsecamente più
"complicata"...invece da qaunto ho capito io in slackware il
cofano è praticamente sempre aperto e la complessità viene
demandata alla volontàdi chi la usa.
Detto questo, direi che il discorso Slackware o non Salckware è
un tema poco interessante in questa discussione. Che voleva
esssere molto più centrata sulla questione usb, al limite con
divagazioni graitissime sul controllo software di modem/cellulari
gprs/umts.
Saluti  :-)

 evenienze.
Devo anche aggiungere che l'instllazione di slackware che ho
seguito, è partita dalla messa in piedi di un sistema minimale:
Ho usato il cd della 12.0 e ho selezionato una directory di
un'altra partizione come source, nella quale avevo
precedentemente fatto un rsync, per una serie di pacchetti per
mettere in piedi appunto il sistema minimale della 12.1.
Come kernel ho SCELTO l'huge, per andare sul sicuro, Ma non è
l'unico kernel che Volkerding mette a disposizione. E magari
negli altri ha preso scelte differenti, più vicine alle distro
che hai in mente tu.
Spero che il "qui pro quo", sia risolto e mi auguro si poss
tornare a scrivere/leggere di ciò che riguarda il subject della
discussione
Saluti  :-)