[debian] connessione usb

[Ikitt]

Originariamente inviato da UNIX-based
ciao,
scusami ancora ma non ho capito bene un (altro) paio di cose.

Purtroppo adesso sono di fretta e posso rispondere solo a poco, sperando di non inserire troppe boiate nel mezzo

con:

grep -E "^[ \t]*SYNCH_ATTEMPTS[ \t]*=" eciadsl.conf | tail -1 | cut -f 2 -d '=' | tr -d " \t"

oppure

grep SYNCH_ATTEMPTS eciadsl.conf | cut -d= -f2

non ottengo la stessa cosa?

No. La prima versione cerca una riga che
- inizi con un qualsiasi numero di spazi o tab e
- contenga la stringa "SYNCH_ATTEMPTS" e
- contenga, dopo la suddetta, un qualsiasi numero di spazi o tab e
- contenga, dopo i suddetti, un segno di uguale.
La seconda versione cerca semplicemente una riga contenente SYNCH_ATTEMPTS.

Cosi`, si ha che

abbaSYNCH_ATTEMPTScabbayabba

soddisfa la seconda regexp ma non (correttamente) la prima.

perchè tutta questa preoccupazione per i tab (il motivo delle "extended regular expression" no?)

ma come viene identificato il tab:

"[ \t]"
" \t"
"\t"

?

con \t. "[ ]" nel contesto delle regexp e` un'altro operatore. Nel caso specifico("[ \t]*") si hanno i seguenti elementi basilari:
' ' (spazio)
\t (tab)
[ ]
*

[Ikitt]

Originariamente inviato da UNIX-based

Oct 30 05:33:25 debian kernel:  printing eip:
Oct 30 05:33:25 debian kernel: c01ddf65
Oct 30 05:33:25 debian kernel: Oops: 0000
Oct 30 05:33:25 debian kernel: CPU:    0
Oct 30 05:33:25 debian kernel: EIP:    0010:[<c01ddf65>]    Not tainted
Oct 30 05:33:25 debian kernel: EFLAGS: 00010246
Oct 30 05:33:25 debian kernel: eax: 00000000   ebx: 00000023   ecx: 00000000   edx: 0000003f
Oct 30 05:33:25 debian kernel: esi: 00000000   edi: cfae53e0   ebp: cf34821c   esp: cec85edc
Oct 30 05:33:25 debian kernel: ds: 0018   es: 0018   ss: 0018
Oct 30 05:33:25 debian kernel: Process pppoeci (pid: 348, stackpage=cec85000)
Oct 30 05:33:25 debian kernel: Stack: 00000023 d085c5bc 00000000 cf34821c 00000023 00000001 cf348000 cf348200
Oct 30 05:33:26 debian pppd[355]: Modem hangup
Oct 30 05:33:29 debian kernel:        00001180 c42b8720 cfae53e0 00000282 c142e760 c01de9a2 cf34821c c01e3a43
Oct 30 05:33:30 debian kernel:        cf34821c cf9db0a0 fffffdfd cf9db0a8 cfa76dc0 c42b8720 00008800 00000000
Oct 30 05:33:30 debian pppd[355]: Connection terminated.
Oct 30 05:33:30 debian kernel: Call Trace: [<d085c5bc>] [<c01de9a2>] [<c01e3a43>] [<c01e4397>] [<c0143708>]
Oct 30 05:33:30 debian pppd[355]: Connect time 3497.5 minutes.
Oct 30 05:33:30 debian kernel:    [<c01438b2>] [<c0106e7b>]
Oct 30 05:33:30 debian pppd[355]:

io da solo ci faccio poco e nulla...

Hai trovato un bel kernel oops.
Hai presente gli errori irreversibili in windows? ecco, tipo quello. Se non li hai presente, buon per te.
Sostanzialmente si tratta di un'errore non-critico del kernel. Sembra che qualcosa non vada per il verso giusto, o forse con gli eciadsl e` cosa (relativamente, spero) normale?
Io sto su ethernet, non so come sia la situazione.

[Ilmalcom]

Originariamente inviato da Ikitt
con \t. "[ ]" nel contesto delle regexp e` un'altro operatore. Nel caso specifico("[ \t]*") si hanno i seguenti elementi basilari:
' ' (spazio)
\t (tab)
[ ]
*

Forse questo pezzo è un po' poco chiaro, ma il buon Ikitt era di fretta, quindi provo a darti una rilettura rapida io.

[ \t]* -> le parentesi quadre contengono un set di caratteri e l'espressione matcha se incontra uno dei caratteri fra parentesi. Quindi questa regexp sta per "uno spazio O un tab" e l'asterisco che segue indica 0 o più occorrenze di spazi o tab. Spero di essere stato chiaro

Edit perchè ero stato poco chiaro pure io :P

[iDleR]

SE hai il modem in affitto con alice, la sostiuzione in eth è gratuita...però io li ho minacciati di morte se non provvedevano a portarmelo entro una settimana...

[UNIX-based]

ok, grazie mille
si, ora mi sono ricordato: con [ab] si intende a o b...
grazie!!!

ma... scusate... cos'è un tab?
un po' di spazi o un numero preciso di spazi?
sennò
\t
è uguale a
\ *

Originariamente inviato da Ikitt
Hai trovato un bel kernel oops.
Hai presente gli errori irreversibili in windows? ecco, tipo quello. Se non li hai presente, buon per te.
Sostanzialmente si tratta di un'errore non-critico del kernel. Sembra che qualcosa non vada per il verso giusto, o forse con gli eciadsl e` cosa (relativamente, spero) normale?
Io sto su ethernet, non so come sia la situazione.

addio, niente da farci?
quindi non è colpa della linea adsl...?
cambiare kernel?
o è una questione hardware...

[edit]a, giusto per imparare... dal log quali parametri hai definito determinanti per dedurre?[/edit]

[Ikitt]

Originariamente inviato da UNIX-based
ma... scusate... cos'è un tab?

E`... Un tab, e` un carattere ASCII come gli altri

un po' di spazi o un numero preciso di spazi?
sennò
\t
è uguale a
\ *

E` un vero e proprio carattere, che puo` essere visualizzato con un numero variabile di spazio, 4 di solito ma anche 2 od 8...

addio, niente da farci?
quindi non è colpa della linea adsl...?
cambiare kernel?
o è una questione hardware...

Non ne ho sinceramente idea. La situazione eciadsl e` un po` "hackish" (leggasi: soluzione che non brilla per pulizia) da quel che mi risulta, ma ho una conoscenza molto superficiale della questione

[edit]a, giusto per imparare... dal log quali parametri hai definito determinanti per dedurre?[/edit]

Prevalentemente queste due:

Oct 30 05:33:25 debian kernel: Oops: 0000
Oct 30 05:33:25 debian kernel:  printing eip:

Poi c'e` il dump dei registri del processore e lo stack delle chiamate, e` abbastanza evidente

[Ikitt]

Originariamente inviato da UNIX-based
il 'super-grep' viene fatto sul file /etc/eciadsl/eciadsl.conf no? che poi viene buttato in tail ecc...
ma il mio eciadsl.conf è questo:[...]
dove non compare nè SYNCH_ATTEMPTS, nè ECILOAD2_OPTIONS.
e quindi?

Quindi spero/credo/presumo che lo script abbia dei default preimpostati per quelle due, ma credo proprio per tutte, le variabili configurabili

[UNIX-based]

Originariamente inviato da Ikitt
Non ne ho sinceramente idea. La situazione eciadsl e` un po` "hackish" (leggasi: soluzione che non brilla per pulizia) da quel che mi risulta, ma ho una conoscenza molto superficiale della questione

io meno...
a parte gli scherzi... siccome in un anno di linux la disconnessione improvvisa è una cosa che mi succede solo ultimamente, da un paio di mesi, cercavo di risalire al problema, sia dai log del kernel, sia dallo script di connessione).
scusami quindi se insisto, non è la linea.... nemmeno il kernel, provare a cambiarlo sarebbe fuori luogo...?

Quindi spero/credo/presumo che lo script abbia dei default preimpostati per quelle due, ma credo proprio per tutte, le variabili configurabili

scusa ma qui non posso dire di aver capito...
credo che invece sia importante per risolvere questo ciclo while:

while [ $CNT -le $synch_attempts -a $RET -ne 0 ]; do
        "$BIN_DIR/eci-load2" $eciload2_options
        RET=$?
        sleep 1
        CNT=$(expr $CNT + 1)
done

perchè mi restituisce "failed to get synchronization" al riavvio?

if [ $RET -eq 0 ]; then
        echo "synchronization successful"
else
    echo "failed to get synchronization"
    exit -1
fi

se invece riavvio si riconnette alla prima...
"mi basterebbe almeno riconnettermi "al volo" appena mi accorgo...

grazie comunque mille per la disponibilità...
...e complimenti perchè qualsiasi cosa ti venga proposta... "qualcosa" sai

[Ikitt]

Originariamente inviato da UNIX-based
siccome in un anno di linux la disconnessione improvvisa è una cosa che mi succede solo ultimamente,

Non so che dire, l'unico problema che ho riscontrato io sinora con l'ADSL era riconducibile a telecom :di56:

credo che invece sia importante per risolvere questo ciclo while:

while [ $CNT -le $synch_attempts -a $RET -ne 0 ]; do
        "$BIN_DIR/eci-load2" $eciload2_options
        RET=$?
        sleep 1
        CNT=$(expr $CNT + 1)
done

perchè mi restituisce "failed to get synchronization" al riavvio?

if [ $RET -eq 0 ]; then
        echo "synchronization successful"
else
    echo "failed to get synchronization"
    exit -1
fi

Beh, l'unica spiegazione che mi viene in mente e', come detto, che eci-load2 e' fallito "synch_attempts" volte. Occorrerebbe una verifica incrociata nei log per capire come mai questo accade.

Riguardo al fatto che tu non specifichi SYNCH_ATTEMPTS nel file di config, presumo che il programma (script) di connessione abbia comunque un valore preimpostato per questa variabile, chesso', 5, e che appunto venga usato quello salvo diversa esplicita segnalazione via file di conf.
Questo per evitare errori grossolani di funzionamento nei casi in cui, appunto, tale valore non sia indicato nella configurazione fatta dall'utente.