Modem in oggetto: Alice Gate Voip 2 Plus Wi-FiSapevate che ?? ... Il modello di router in oggetto se abbinato a certi profili ADSL Telecom potrebbe procurarvi grattacapi odiosi con conseguente blocco dell'apparato?
Oggi, con questo topic, vi svelerò vita, morte e miracoli annessi a questi fastidiosi problemi che affliggono tutti i possessori di questo modello di router AGPF¹ e che hanno sottoscritto una FLAT Telecom (SENZA VOIP o IPTV).
Parto, intanto, con una doverosa premessa atta a spiegare la situazione Telecom per quel che riguarda le tipologie di abbonamenti più comuni e ad uso privato poiché, vedrete, c'entra in maniera fondamentale...; poc'anzi avevo messo in evidenza un "SENZA VOIP" non a caso.
Dovete sapere che a seconda del tipo di abbonamento all'ADSL, il servizio di Amministrazione Remota (o + comunemente Telegestione) carica sugli apparecchi un file di configurazione differente. Per chi, ad esempio, sottoscrivesse una normale FLAT senza opzioni, si ritroverebbe, se dovesse usare uno dei loro apparecchi, una Telegestione funzionante, per così dire, a periodi!!
Il profilo Alice FLAT prevede:
- Telegestione attiva all'accensione dell'apparato e SOSPENSIONE dopo 1H30m
- Riattivazione della Telegestione trascorsi 10gg
Altro file di configurazione verrà caricato invece dalla sessione remota Regman per gli utenti FLAT+VOIP o FLAT+IPTV.
Questi profili, infatti, prevedono Servizio Regman in remoto attivo SEMPRE. Il motivo di cio' è semplice ed è presto detto... i servizi addizionali alla FLAT instradano il traffico dati entro il canale della VPN della Telegestione, per cui quest'ultima non puo' andarsene in pausa quando uno meno se l'aspetta!!!
Niente da dire allora... è tutto OK?? Non proprio!!!
Questo modello di router non digerisce il file di conf previsto per i profili FLAT, proprio perché non tollera affatto la sospensione della connessione adibita alla Telegestione con i parametri suggeriti da Telecom.
Cos'è che non funziona in particolare?La cosa che principalmente danneggia le risorse del router è in pratica il fatto contraddittorio per cui quando la Telegestione va in idle per 10 gg, viene forzata, in questo periodo di inattività, un'opzione che permetterebbe, On Demand, la connessione VPN, sospesa in precedenza, di uscire "dal sonno". Non avrebbe molto senso attivare il "Wake Up" della connessione "Telecom Italia" (nome della connessione VPN mappata) dato che è previsto un periodo di 10gg, trascoso il quale automaticamente lo stato verrebbe commutato a di nuovo "connected" con conseguente riassegnamento di un nuovo IP² per il tunnelling in VPN.
Il discorso a dire la verità non finisce qui, adesso Vi spiego cosa accade nei dettagli:
Trascorsa la prima ora e mezza il servizio di Teleg. questa passa dunque dallo stato attivo allo stato di "connessione in corso". A partire da adesso, ogni volta che chiederete al server DNS di risolvervi un IP in WAN che non risiede in cache, verrebbero spediti dei pacchetti all'indirizzo IP del gateway interno della connessione VPN per tentare inutilmente di fargli cambiare stato. Cosa che non accadrà mai poiché la connessione aspetta lo scadere del Timer di 864000 secondi (10g) e quindi se ne sbatte alla grande...
Come se NON bastasse... il timeout stabilito per la chiusura di queste connessioni/porte nel canale VPN non è affatto indifferente ed è fissato a 5400 secondi (1H30m) e badate... è un parametro che non ha niente a che dividere col tempo di attività di ogni sessione di Telegestione..nonostante sia anch'esso fissato a 5400.
Navigare con un browser, saltare da un sito all'altro, vuol dire fare lavorare il server DNS e fargli risolvere gli IP corrispondenti... ed è ritenuta normale attività. Ma in queste circostanze, ogni volta che si chiede al router questa operazione di risoluzione, a causa del "Wake Up on demand" attivo, si inviano continue richieste di "svegliati" alla VPN.. e queste, a lungo andare, mineranno la memoria riservata al NAT perché esse finiranno inevitabilmente per AMMASSARSI.
Esempio:Mi trovo nella fase di Telegestione in sospensione...
Apro il browser e vado a visitare Google per la prima volta da quando il router è acesso, e quindi l'IP non sta in cache poiché il suo DNS non era ancora mai stato risolto in precedenza.
Una volta inoltrata la richiesta, in automatico parte un seconda richiesta parallela di Wake Up per la telegestione con il rispettivo IP; quest'ultima conenssione nello specifico spedisce 10 Tx all'indirizzo del gateway e starà in vita per 5400 secs. come da previsione...
Passano 2 minuti e vado a visitare "ilpuntotecnico.com" anch'esso per la prima volta. A questo punto ci sono 2 possibilità... o verrà aperta una nuova porta nel NAT della VPN e inoltrati altri pacchetti wake up o questi ultimi andranno a ricongiungersi, se sono presenti, a quelli di una delle richieste precedenti.
1° caso
- porta LAN NAPT 3084 Telecom Italia 10Tx scadenza in 5280 secondi (5400 - 120)
- porta LAN NAPT 3085 Telecom Italia 5Tx scad. in 5400 secondi
2° caso
- porta LAN NAPT 3084 Telecom Italia 15Tx (10 + 5) scad. in 5400 secondi (il timeout viene resettato)
La situazione si prospetta infernale, e fa rabbrividire in entrambi i casi.
In pratica se si inizia, ad esempio, una sessione di navigazione a tutto spiano, potete da soli immaginare la reazione a catena che si verrebbe a delineare. Saltando da un sito all'altro col browser, ci si mette poco a fare "ingrassare" le richieste di wake up on demand. Vi ritrovere, prima o poi, di fronte a scenari apocalittici, tipo 9 porte aperte con ciascuna migliaia di pacchetti in Tx. La memoria riservata al NAT andrà così in un graduale esaurimento ben prima del trascorrere dei fatidici 10 giorni e le normali attività del router inizieranno a rallentare.
Per recuperare la situazione in questa terrificante prospettiva, ci sarà solo una cosa da fare... lasciare scadere le richieste in corso, quindi far trascorrete almeno un'ora e mezza e cessare ogni attività Internet o di Routing, con la riserva che non è detto che possiate effettivamente ritornare ad avere il controllo dell'apparato (dovrò effettivamente verificare meglio questa cosa).
Vi posto uno screenshot per rendere meglio l'idea...
Bene!!! Individuato il danno.... non ci resta che studiare le possibili soluzioni!!!
La prima cosa che a questo punto ci verrebbe da proporre sarebbe: <<E che diamine!!! Disattiviamo sto caxxo di Wake up on demand!!!>>
Hmm bene!! Sono d'accordo, vediamo così se possiamo risolvere!!
Ok vado subito a deselezionare la casellina apposita della scheda "PPP" della connessione "Telecom Italia " in "Network Connection"...
<< Uhm NON ME LA FA CAMBIARE>>
<<Cioè, sembra che la deselezioni, ma poi ritorna di nuovo selezionata>>
Come sarebbe a dire che non si puo' deselezionare!!!??
E in effetti la cosa è piuttosto strana!!! Alcune cose, mi accorgo, non posso cambiarle perché "lokkate" da qualche impostazione vincolante nel file di configurazione... Inoltre scopro dei presunti LEGAMI tra le connessioni mappate (come ad esempio la stessa Telecom Italia e la User Session) che apparentemente non sospettavo ci fossero....; sì in pratica cambio qualcosa di qua e me la ritrovo poi settata anche di là... decisamente un casino!!!
Poi quando credo di esser riuscito a cambiare qualcosa e vado persino a vedere nel file di configurazione mi ritrovo discordanze preoccupanti
<<Ma come? di là me la dà disattiva e di qua attiva?>>
Già, sembra quasi che ci sia qualche opzione che forza a mantenere le impostazioni correnti.
Non dovete preoccuparvi cmq!! E' tutto normale, le connessioni mappate hanno effettivamente dei vincoli di integrità fra di essi... sono stati creati apposta nel file .conf.
Si dovranno toccare cmq altri tasti per raggiungere il nostro scopo.
SOLUZIONIAnzitutto, scordatevi puredi flashare firmware, poiché nessuna versione in circolazione risolve questo casino; anche perché la cazzata risiede nel file .conf che Regman carica da Remoto attraverso la Telegestione e non nel firmware.
Posterò adesso 3 soluzioni tutte abbastanza efficaci per fixare il problema, sceglierete voi poi quale più vi aggrada...
La PRIMA e la SECONDA potranno essere attuate assieme, anche se una volta scelto di adottare il primo metodo la seconda alternativa risulterà essere quasi superflua nell'utilizzo in combo con la prima.
- 1. Ridefinizione dei parametri di Telegestione (metodo CONSIGLIATO)
Consigliato perché dovrebbe essere l'ovvio fixing che ci aspetteremmo che Telecom Italia attuasse nei suoi file .conf per gli AGPF con profili FLAT ONLY.
E' poi una soluzione OBIETTIVA, mirata a risolvere il problema una volta e per tutte, senza ricavarne ulteriori benefici.
Questo fixing vi permetterà di continuare ad "usufruire" della Telegestione (con questi profili tarrifari, a dirla tutta, sarà utile solo ad aggiornare i firmware, per il resto potrebbe SOLO fare danni ehm).
Fixerete inoltre il presunto bug dovuto allo spegnimento della spia "Internet" dell'apparato che è stata progettata con la formula "2 piccioni con una fava" . In pratica monitora sia connesione Internet che VPN con ovvi e sopsetti dubbi sulla reale utilità di codesta spia, poiché certe volte non si riesce a capire cosa stia realmente segnalando. Si spegne dopo 1H30m quando la VPN viene disabilitata, ma anche quando scade il timeout della sessione internet di 600 secondi (10 min) xD insomma il minestrone è servito!!!
Con questa procedura ci limiteremo solo a cambiare i parametri della Telegestione stabilendo noi quelli che riterremo più opportuni e giusti per evitare di mandare in tilt il router
Riepilogando: Sessioni di Teleg. da 1H30 intervallate da un periodo di 10gg di idle
Noi invertiremo il comportamento così: Sessioni di Teleg da 10gg intervallate da solo 30 sec. di idle
Questa soluzione è praticamente equivalente alla metodica proposta da Telecom poiché non abuseremo di + rispetto a prima "nel rompere le scatole" a Regman da remoto. Stiamo solo forzando a mantenere attiva la sessione vpn, senza inviare + traffico di quanto facevamo prima. A differenza della proposta Telecom però eviteremo che vengano instaurate connessioni di "wake up" inutili se non in quei INSIGNIFICANTI 30 secondi in cui la VPN andrà in sospensione.
Mano al telnet allora, poiché non sono opzioni che possiamo cambiare dalla console...
Il telnet di default è OFF, bisogna abilitarlo...
Andate nella console avanzata, percorso "Advanced>>Remote Administration" ed esponete ora il servizio Telnet (temporaneamente non preoccupatevi) su Internet spuntando la casella Using Primary Telnet Port (23), inoltre cambiate anche l'URL della Connection Request inserendo 1, altrimenti non potrete applicare le modifiche:
Confermate con OK e apritevi una shell da vs OS. Digitate telnet 192.168.1.1 e autenticatevi.
Adesso, per prima cosa, abilitiamo il telnet da locale, riportando, fra l'altro, le impostazioni modificate in precedenza allo stato originario:
conf set /admin/telnets/disabled 0
conf set /admin/telnets/ports/0/remote_access 0
conf set /cwmp/conn_req_url ConnectionRequest
conf reconf 1
Nota: per ogni comando eseguito, Discus vi ritornerà un valore ad indicarvi l'esito della transazione... se '0' è OK, altrimenti '1' Errore se si è verificato un problema.
Poi attuiamo le modifiche critiche:
conf set /dev/ppp0/idle_mng_disc_time 864000
conf set /dev/ppp0/reconn_time 30
conf reconf 1
Attendete per qualche istante la fine del logging e digitate exit per uscire dalla sessione Telnet.
FATTO.
Per verificare le modifiche, potete andare nelle opzioni avanzate del Discus e controllare il File di Configurazione facendo una semplice ricerca del testo "idle_mng_disc_time" con CTRL+F. Vi ritroverete i valori da voi settati col telnet.. potrete anche scorgere nelle vincinaze la riga "(nat_pers_time(5400))"... che indica il famigerato tempo di vita delle connessioni nattate nella VPN e che di proposito abbiamo deciso di lasciarlo a 5400 secondi... poiché adesso queste connessioni non verranno + sovraccaricate e possono tranquillamente rimanere anche per 1H30m... prima o poi si toglieranno di mezzo da sole e senza gravare sulla memoria.
Con queste impostazioni anche la spia "Internet" adesso acquisterà un senso poiché realmente segnalerà lo stato della "User Session" (cioè l'ADSL) e BASTA; insomma farà quello che ci aspettavamo....
Vi consiglio, infine, di appuntarvi da qualche parte la procedura che avete seguito, poiché dalla stessa Telegestione nel momento in cui ci saranno delle novità vi ri-upperanno il .conf da Regman 
e di conseguenza potreste ritrovarvi di nuovo il bug; in questo caso bisognerà nuovamente re-fixare.
2. Intercettazione delle connessioni UDP di Wake Up (MOMENTANEAMENTE SOSPESO)
Se non volete cambiare i parametri suggeriti da Telecom per la telegestione, potete intervinire a livello di Firewall; basterà creare delle regole ad hoc per bloccare tutti i tentativi di risveglio a richiesta della telegestione.
Andate nella sezione "Security" e poi nella scheda "Advanced Filtering". Qui vi ritroverete di fronte a una schermata che proporrà regole firewall per le richieste in entrata "Input Rule Sets" e in uscita cioè "Output Rule Sets; a noi interesserà gestire, in particolar modo, le sezione dedicata al traffico in uscita.
Non sognatevi minimamente di poter fare in questa sezione qualunque cosa vogliate, poiché anche qui esistono dei vincoli di mantenimento abbastanza severi. Ci sono dei presets veramente ostili alla modifica, e se per qualche motivo desideraste creare delle regole dal nulla per conto vostro, RICORDATE SEMPRE di ACCODARLE alle presets, altrimenti se li metterete prima o in mezzo, l'ordine corretto che si aspetterebbe la configurazione verrebbe compromesso, col risultato di non essere + capace di risalire alle regole esatte a cui attribuire dinamicamente gli IP corretti con ripercucssioni sul traffrico dati WAN; in parole povere rischierete d chiudere tutte le PORTE a Internet.
Noi adesso, non andremo cmq a creare una nuova regola ma piuttosto modificarne una già esistente nelle presets, proprio per evitare di sputtanre l'ordine...
Individuate esattamente la prima regola del gruppo "Telecom Italia Rules" delle Output Rule Sets, la numero 0 in sostanza quella che per il momento risulta disattivata...
Bene!! Adesso fate click su Edit (la matitina) e modifichimola opportunamente come segue:
Destination Adrress: qui dovrete mettere l'IP del Gateway interno cioè 192.168.100.1 (attenzione 100 e NON 1); servitevi dell'opzione "User Defined" nel menù a discesa per mappare l'ip.
Protocol: settate "UDP" sempre aiutandovi con l'opzione "User Defined", specificando inoltre come porta di destinazione la "2222"
Fatto questo, lasciate tutto il resto com'è e confermate con "OK". Ritornerete così nella schermata principale delle regole mappate e potrete vedere le modifiche applicate la regola n° 0... adesso non dovrete fare altro che spuntare la casella a sinistra per attivarla e confermare il tutto con OK.
Finito! Adesso quelle fastidiosissime connessioni UDP sendate al gateway verranno "uccise" sul nascere dal firewall... 
Vi consiglio di fare la STESSA cosa anche con la PRIMA regola del gruppo "User Session Rules" poiché in talune circostanze, anche da quel canale, a causa del solito LEGAME partiranno delle connessioni UDP dirette alla medesima destinazione e sempre con la stessa finalità; queste connessioni, tuttavia, hanno un ciclo di vita + breve rispetto a quelle della "Telecom Italia", rispondono cioè alle impostazioni proprie di quella conessione e differisce di parecchio in questo parametro... soli 300 secondi (5 min.) di vita delle connesioni "User Session" contro i 5400 secs di quelle "TI". Nonostante questo parametro, cmq, entrambe sono soggete allo stesso trattamento, per cui meglio bloccarle tutte nel caso in cui decidessero di darsi il cambio!!!
Attenzione! Questo metodo non fixa il comportamento della spia "Internet" per cui questa continuerà a funzionare come ricordavate.
- 3. Disattivazione della Telegestione
Basta a perdere tempo co sto piffero di telegestione!!! <<Ora la disattivo e la finiamo una volta e X SEMPRE>>
E' vero, non è certo questo il modo di risolvere le cose, ad ogni modo rimane sempre una scelta che, tra le altre cose, in una botta sola vi risolverebbe anche questo impiccio; poco ebiettiva ma sicuramente la + EFFICACE.
Senza contare poi... che avreste tutte le funzioni del router al vostro servizio e senza che da remoto ve li rimettano come prima; e qualora combinaste dei casini, apparentemente irreparabili, il pulsantello magico del Reset ripristinerebbe tutto allo stato originario.
Bando alle ciance dunque!!! Ci vuole davvero poco...
... entrate nella console del Discus e andate a fare una visitina alle "Netwok Connetcions" cliccate sulla "Telecom Italia" e poi disabilitatela
Poi andate nelle "Avanced>>Remote Administration" e disabilitate anch'essa:
(cambiate anche l'URL della Connection Request inserendo 1, altrimenti non potrete applicare le modifiche)
Infine riavviate la connessone ppp2 cioè la "User Session" da "Netwok Connetcions" poiché, a causa del LEGAME con la "Telecom Italia", andrà in idle dopo 600 secs e non potrete + navigare. Andate, dunque, nella medesima finestra "properties" come avevate fatto per la Telecom Italia, e a questo punto cliccate una volta "Disable" e dopo qualche istante "Enable". State tranquilli è un'operazione che, in seguito e una volta disattivata la telegestione, NON dovrete + fare.
Questa procedura, se volete potete anche effettuarla da Telnet...
Per prima cosa abilitate il servizio come già descritto in precedenza al PUNTO 1... dopo digitate:
conf set /dev/ppp0/enabled 0
conf set /cwmp/enabled 0
conf reconf 1
Adesso è tutto OK e di conessioni aperte a tradimento per sollecitare l'amministrazione remota a svegliarsi non ce ne saranno +; la Telegestione è OFF morta e defunta, e a quanto pare pure al router risulta che i morti, inutile continuare a chiamarli, tanto non si sveglieranno +. Regolare, infine, anche il comportamento della spia "Internet", poiché questa dovrà occuparsi di monitorare soltanto lo stato della "User Session".
Dunque, NO telegestione NO problems.
NOTE:
1. Non è accertato, da parte mia, se altre varianti di questo modello di router con firmware NON AGPF e quindi di differente famiglia siano effettivamente coinvolti.
2. Attenzione!! L'IP VPN non corrisponde all'IP pubblico della normale sessione ADSL, e il suo rinnovo non provoca nessun distacco dalla portante di riferimento.