Internet Key Olicard 300 e ISP che non mi da l'IP

[joe]

Allora, abbiamo questa chiavetta:
http://www.olivetti.it/IT/Tool/Product/ ... 639&idp=60

Ufficialmente no supportata da linux, ma mi sa che sono riuscito in qualche modo a capire come farla digerire al pinguino.
Ora diciamo che è stata riconosciuta e che su:

Codice: Seleziona tutto

/tty/USB0

Abbiamo il nostro modem device, col quale posso tranquillamente inviare comandi AT (AT+CFUN=1, ATD*99***1#, ecc ecc tanto per dire). E che risponde OK regolarmente.
Siamo anche in grado di sostenere una sessione PPP direi, ma alla fine della sessione di CHAT quando ricevo il CONNECT da parte dell'ISP (TIM), ecco che invece di ottenere un indirizzo IP, questo non mi viene dato e la mia interfaccia ad esempio "ppp0" non è dotata di indirizzo IP.
E per forza di cose questo indirizzo deve darmelo l'isp direi proprio...

Chi comanda?
Solitamente in questi casi comanda uno script pppd in cui posso inserirsi comandi e opzioni particolari che in qualche modo influiscono sul comportamento della sessione PPP.

Ora mi/vi chiedo, c'è un qualche modo per "chiedere" all'isp di darmi l'ip all'atto del CONNECT?

Siccome ho a portata di mano anche una seconda chiavetta simile ma della Huaweii (E353), quest'ultima invece supportata da linux senza problemi, riconosciuta al volo ecc.
Stesso script pppd... ottenuto il CONNECT ecco che appare il mio indirizzo ip impostato dall'isp e anche dei DNS server dell'isp.
Sembra che la chiavetta della OLIVETTI faccia qualcosa in meno insomma... rispetto alla HUAWEEI che invece fa tutto da sola.

Vi allego il "/var/log/messages" relativo a due sessioni di connessione, la prima eseguita con successo utilizzando la Huaweei, la seconda invece effettuata con la Olicard 300 e come vedete, rimasta in sospeso dopo il CONNECT.

Mi viene in mente di aggiungere l'opzione "debug" nello script pppd, magari salta fuori qualche info in più, va bè eventualmente vi aggiorno sulle novità, per ora vi posto tutto così com'è fin ora.

Codice: Seleziona tutto

Mar  2 18:25:36 darkstar pppd[6431]: pppd 2.4.5 started by root, uid 0
Mar  2 18:25:37 darkstar chat[6433]: send (atz^M)
Mar  2 18:25:37 darkstar chat[6433]: expect (OK)
Mar  2 18:25:37 darkstar chat[6433]: ^M
Mar  2 18:25:37 darkstar chat[6433]: OK
Mar  2 18:25:37 darkstar chat[6433]:  -- got it 
Mar  2 18:25:37 darkstar chat[6433]: send (at+cgatt=1^M)
Mar  2 18:25:37 darkstar chat[6433]: expect (OK)
Mar  2 18:25:37 darkstar chat[6433]: ^M
Mar  2 18:25:37 darkstar chat[6433]: at+cgatt=1^M^M
Mar  2 18:25:37 darkstar chat[6433]: OK
Mar  2 18:25:37 darkstar chat[6433]:  -- got it 
Mar  2 18:25:37 darkstar chat[6433]: send (at+cgdcont=1,"IP","ibox.tim.it"^M)
Mar  2 18:25:37 darkstar chat[6433]: expect (OK)
Mar  2 18:25:37 darkstar chat[6433]: ^M
Mar  2 18:25:37 darkstar chat[6433]: at+cgdcont=1,"IP","ibox.tim.it"^M^M
Mar  2 18:25:37 darkstar chat[6433]: OK
Mar  2 18:25:37 darkstar chat[6433]:  -- got it 
Mar  2 18:25:37 darkstar chat[6433]: send (atd*99***1#^M)
Mar  2 18:25:37 darkstar chat[6433]: expect (CONNECT)
Mar  2 18:25:37 darkstar chat[6433]: ^M
Mar  2 18:25:37 darkstar chat[6433]: atd*99***1#^M^M
Mar  2 18:25:37 darkstar chat[6433]: CONNECT
Mar  2 18:25:37 darkstar chat[6433]:  -- got it 
Mar  2 18:25:37 darkstar chat[6433]: send (^M)
Mar  2 18:25:37 darkstar pppd[6431]: Serial connection established.
Mar  2 18:25:37 darkstar pppd[6431]: Using interface ppp0
Mar  2 18:25:37 darkstar pppd[6431]: Connect: ppp0 <--> /dev/ttyUSB4
Mar  2 18:25:38 darkstar pppd[6431]: PAP authentication succeeded
Mar  2 18:25:40 darkstar pppd[6431]: local  IP address 10.187.xxx.xxx
Mar  2 18:25:40 darkstar pppd[6431]: remote IP address 10.64.64.64
Mar  2 18:25:40 darkstar pppd[6431]: primary   DNS address 10.207.43.46
Mar  2 18:25:40 darkstar pppd[6431]: secondary DNS address 10.206.56.132

Codice: Seleziona tutto

Mar  2 18:53:45 darkstar pppd[6646]: pppd 2.4.5 started by root, uid 0
Mar  2 18:53:46 darkstar chat[6648]: send (atz^M)
Mar  2 18:53:46 darkstar chat[6648]: expect (OK)
Mar  2 18:53:46 darkstar chat[6648]: atz^M^M
Mar  2 18:53:46 darkstar chat[6648]: OK
Mar  2 18:53:46 darkstar chat[6648]:  -- got it 
Mar  2 18:53:46 darkstar chat[6648]: send (at+cfun=1^M)
Mar  2 18:53:47 darkstar chat[6648]: expect (OK)
Mar  2 18:53:47 darkstar chat[6648]: ^M
Mar  2 18:53:47 darkstar chat[6648]: at+cfun=1^M^M
Mar  2 18:53:47 darkstar chat[6648]: OK
Mar  2 18:53:47 darkstar chat[6648]:  -- got it 
Mar  2 18:53:47 darkstar chat[6648]: send (at+cgdcont=1,"IP","ibox.tim.it"^M)
Mar  2 18:53:47 darkstar chat[6648]: expect (OK)
Mar  2 18:53:47 darkstar chat[6648]: ^M
Mar  2 18:53:47 darkstar chat[6648]: at+cgdcont=1,"IP","ibox.tim.it"^M^M
Mar  2 18:53:47 darkstar chat[6648]: OK
Mar  2 18:53:47 darkstar chat[6648]:  -- got it 
Mar  2 18:53:47 darkstar chat[6648]: send (atd*99***1#^M)
Mar  2 18:53:47 darkstar chat[6648]: expect (CONNECT)
Mar  2 18:53:47 darkstar chat[6648]: ^M
Mar  2 18:53:47 darkstar chat[6648]: atd*99***1#^M^M
Mar  2 18:53:47 darkstar chat[6648]: CONNECT
Mar  2 18:53:47 darkstar chat[6648]:  -- got it 
Mar  2 18:53:47 darkstar chat[6648]: send (^M)
Mar  2 18:53:47 darkstar pppd[6646]: Serial connection established.
Mar  2 18:53:47 darkstar pppd[6646]: Using interface ppp1
Mar  2 18:53:47 darkstar pppd[6646]: Connect: ppp1 <--> /dev/ttyUSB0
Mar  2 18:53:48 darkstar pppd[6646]: PAP authentication succeeded

Ora perchè diavolo si ferma lì secondo voi?
Cos'ha la chiavetta numero uno che la numero due non ha?

Ieri ho provato anche a mettere la sim della chiavetta olivetti nella huaweei e s'è collegato tutto alla prima, quindi escluderei che si tratti di problemi relativi alla sim differente, non ce ne sarebbe motivo entrambe hanno credito residuo e offerte mensili regolarmente rinnovate...

Pareri, ipotesi, soluzioni secche sono le benvenute!
Come sempre



OT.NB.OT
Da pochi giorni mi accorgo che alla Tim hanno cambiato politiche.
Mentre da anni davano "ip pubblico" con tutti i benefici del caso, da qualche giorno vedo che alla connessione mi viene dato "ip privato" con tutte le limitazioni del caso.
In questi giorni si sente parlare di bada ultra larga ... ma per il momento si viene beffati da un banale NAT.
Cercando info in rete vedo che alcuni utenti già da mesi hanno riscontrato la cosa... Meditate gente...

Saluti privati!

[fgcl2k]

Prova a mettere l'opzione debug, come tu stesso hai suggerito. Negli script di connessione di PPP usi le stesse opzioni per le due chiavette?

[joe]

Ho fatto diverse prove senza però capirci molto di più e soprattutto senza riuscire ad indurre il "peer" della sessione PPP ad assegnarmi correttamente l'ip e consentirmi quindi di essere online.

Ho aggiunto qualche opzione, tra cui "user" che non dovrebbe essere necessaria specificando il numero telefonico della sim nella chiavetta.
Poi ho messo anche "debug".
E ancora "nodetach" che consente di trattenere il comando in foreground, in questo modo si può redirigere l'output su un file di log. Poi ho provato altre opzioni ma un po' a sentimento, questa era l'ultima versione (però c'è quel noipdefault:

Codice: Seleziona tutto

user 33xxxxxxxx
/dev/ttyUSB0
115200
defaultroute
connect '/usr/sbin/chat -v -f /etc/ppp/olikey.chat'
noauth
debug
noipdefault
nodetach
usepeerdns

Di seguito ecco anche lo script di chat per l'inizializzazione del modem.
È quasi identico a quello che uso con la huaweei solo che la olicard necessita il comando "AT+CFUN=1" in testa, penso che ne accenda la funzionalità radio richiesta dalla rete mobile, o qualcosa del genere.

Codice: Seleziona tutto

'' 'atz'
OK 'at+cfun=1'
OK 'at+cgdcont=1,"IP","ibox.tim.it"'
OK 'atd*99***1#'
CONNECT ''

Per completezza dovrei allegare anche il file di log.
Solo che adesso se attacco la chiavetta olicard potrebbe incasinarsi qualcosa.
Se già da quanto postato vedi cosa è da modificare fammi sapere.

Nel frattempo cerco di fare un tentativo e generare un log da allegare.

Grazie!

[joe]

Allego l'ultima versione dello script pppd.

E il log della sessione PPP dove viene negoziato IP ecc.
Stranamente sta volta sono riuscito a connettermi.
Sarebbe bello anche capire per quale santo, ma per il momento mi limito a riportare la situazione:

Codice: Seleziona tutto

user 33********
/dev/ttyUSB0
115200
defaultroute
connect '/usr/sbin/chat -v -f /etc/ppp/olikey.chat'
usepeerdns
noauth
debug
nodetach

E di seguito ecco anche il log lo metto in allegato.

Ho notato però una cosa.
Testando un po' la connessione, va molto più lenta della mia huaweii.
su speedof.me e su speedtest.net risulta un download e un upload di circa 0.7 - 0.8 Mbps.
Solitamente invece con la huaweei registro quasi 2 Mbps.
E dubito che sia l'orario particolare di adesso.

Non vorrei che nello script di chat vada aggiunto qualche comando per impostare "hspa".
Forse quel AT+CFUN=1 ? O forse qualcos'altro...
Per il momento non sono riuscito a trovare i comandi per la olicard...

[joe]

Allora gente sono riuscito aggiungendo un piccolo accorgimento allo script di chat:

Codice: Seleziona tutto

 cat /etc/ppp/olikey.chat
'' 'atz'
OK 'at+cfun=1'
OK 'at+cgdcont=1,"IP","ibox.tim.it"'
OK '\d'
'' 'atd*99***1#'
CONNECT '\d'

In pratica ho aggiunto un "delay" (penso sia di un secondo) dopo che l'isp risponde col CONNECT.
Quindi prima di iniziare la negoziazione PPP di IP e quant'altro si aspetta un secondo.

questo può essere dovuto al fatto in qualche modo appena arriva il CONNECT, il nostro modem sia ancora impegnato e non riesca a stare al passo della sessione PPP che invece il peer sta portando avanti.
A me questa ipotesi sembra parecchio strampalata.
Però col'inserimento del delay come spiegato ha funzionato 5 tentativi su 5 al primo colpo. Come ci s'aspetterebbe insomma.

Ora per esempio stavo provando a collegarmi con entrambe le chiavette contemporaneamente e ci sono riuscito.

Codice: Seleziona tutto

ppp0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 10.187.*.*  netmask 255.255.255.255  destination 10.64.64.64
        ppp  txqueuelen 3  (Point-to-Point Protocol)
        RX packets 991  bytes 227151 (221.8 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1010  bytes 124535 (121.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ppp1: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 10.187.*.*  netmask 255.255.255.255  destination 10.64.64.65
        ppp  txqueuelen 3  (Point-to-Point Protocol)
        RX packets 1005  bytes 258586 (252.5 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1235  bytes 175927 (171.8 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Ho constatato che cambiando l'instradamento di default da ppp0 a ppp1 e viceversa, effettivamente sul sito TIM vengo visto prima come il numero telefonico della sim-huawei e poi come il numero della sim-olicard.

PS.
Peccato che io non sia in grado di "affasciare" le due connessioni. Altrimenti si poteva andare a velocità maggiore...
Ovviamente una chiavetta e relativa offerta non è mia...

[joe]

Il problema tuttavia non è ancora risolto.
Perchè mi piacerebbe ottenere una velocità di navigazione più alta anche dalla chiavetta olicard.

Faccio qualche prova, aumentando il baud di comunicazione nello script pppd. Senza troppe speranze.

Aggiungo:
siccome la gestione di questa chiavetta è demandata al modulo usbserial e siccome in passato avevo letto di problemi di buffer limitato e conseguente velocità di navigazione internet ridotta, a che punto siao messi adesso con questa problematica? Quei problemini erano rientrati nelle versioni più recenti di usbserial.

Ne sapete nulla?
Ci sono alternative?

Ad esempio vedo che la huawei viene presa in consegna dal modulo "option".
Anni fa avevo anche sentito parlare di airprime...