Oggi mi sono svegliato presto, con un pensiero che mi ronzava nella testa. Si, ho risolto il problema con fastweb, e il mio SIP server ora funziona alla perfezione. Pero’ i “tecnici” di fastweb hanno qualcosa come 15 tickets chiusi in un giorno dove sta scritto che le cose non funzionano a causa mia, della mia configurazione, e questo proprio non riuscivo a farmelo andare giu’.

Inizio a pensare a come convincerli del fatto che il problema e’ loro mentre faccio colazione, e un pensiero si fa sempre piu insistente nella mia testa. In fondo, ora il loro “GAD” e’ staccato, e quindi se fanno una verifica a loro risulta che la mia connessione sia “down”.

Decido quindi di tornare a Milano sulla scena del crimine, e di ingannare fastweb al fine di dimostrare quanto siano incompetenti. Non so se riusciranno a risolvere il problema, ma questo in fondo poco importa, tanto so come risolverlo da me, l’importante e’ che capiscano che il problema e’ loro, non mio!.

Prendo la macchina e mi butto in autostrada, e, durante il tragitto, telefono a fastweb annunciando che siamo senza connessione e che probabilmente il loro GAD e’ morto, non da’ piu segni di vita. L’operatrice ovviamente mi rivolge le domande di rito, tipo “avete provato a riavviare il GAD togliendo e rimettendo la spina?”, e ancora “le linee telefoniche invece funzionano?” e cosi’ via. Ma io insisto che ho fatto tutto, che nulla funziona, che devono fare uscire un tecnico. Detto fatto, mi annuncia che ha aperto la segnalazione e che verro’ richiamato a breve per prendere un appuntamento da parte del tecnico che verra’ a sistemare il problema.

Passano 2 ore, io sono in ufficio che aspetto ( con il GAD staccato ma con la connessione che funziona a meraviglia ), quando finalmente suona il cellulare. E’ lui, il tecnico di fastweb, mi annuncia che verra’ presso la nostra sede alle 14:30 ( ho chiamato alle 9… se avessi davvero un guasto avrei perso mezza giornata di lavoro minimo! ah, che assistenza! ).

Arrivamo le 14:30, una telefonata mi annuncia che il tecnico arrivera’ un po’ in ritardo ma di stare tranquillo che sta arrivando. In effetti oggi piove che quel tizio lassu’ la manda, quindi non mi stupisco piu di tanto pensando ai possibili ingorghi da pioggia nel traffico milanese, mi metto il cuore in pace e aspetto.

Arrivano le 15 e finalmente il tecnico suona il campanello. E’ arrivato. gli vado incontro per accompagnarlo nel piccolo NOC dell’ufficio esordendo con un bel “buongiorno, le svelo un segreto, il nostro GAD funziona benissimo, e’ stato un problema simulato, ora le spiego il vero problema…”, e gli spiego tutta la pappardella di cio’ che e’ successo il giorno prima, di quale sia il vero problema, di quali siano le soluzioni che ho provato (si, compreso il fatto di staccare quel cesso di GAD).

Il tecnico porello e’ un dipendende di una azienda esterna in appalto, e piu di tanto non ne capisce, e’ anzi preoccupato di come giustificare la sua uscita. Ma io lo incalzo e lo invito a chiamare qualcuno che possa davvero capire il mio problema, e lui, gentilissimo e assolutamente senza colpa in tutto questo, mi asseconda. Chiama un suo contatto all’interno di fastweb dicendomi “questo e’ un ragazzo davvero in gamba, se c’e’ qualcuno che puo’ aiutarti e’ lui”. E in effetti ammetto che la persona dall’altra parte del telefono e’ competente. Con la sua guida e le password del tecnico ( che ovviamente non mi ha rivelato ) entriamo nel GAD dal terminale seriale.

Il GAD e’ una macchina ARM con un Linux embedded (kernel montavista), busybox e una cavolo di shell che emula in tutto e per tutto una CLI di Cisco IOS ( che fantasia quelli di telsey ). inizio a guardare la configurazione, e subito mi accorgo di una cosa. Non ci sono filtri apparentemente, ma c’e’ un limite di banda e di connessioni sulla porta udp 5060, ebbravi fastwebbari!.

Ranzo via il filtro con il permesso del tecnico al telefono, e giro un po’ nella cli alla ricerca di altri eventuali filtri. Il nulla, non c’e’ nulla. Decido per un “reload” del firmware, giusto per vedere se torna per caso il limite di prima, e nel frattempo ho sempre il mio hping che viaggia da una macchina esterna e il mio tcpdump che sniffa la eth0 della mia linuxbox.

La regola di limit non torna su, bene, ma una cosa mi salta all’occhio. Mentre il GAD fa il riavvio, durante lo shutdown per un attimo arrivano i pacchetti che sto inviando con hping2 (circa 10 pacchetti, giusto giusto prima del termine dello shutdown), e mentre il GAD si riavvia, altri 4 pacchetti arrivano da quando viene su la scheda di rete a quando appare la scritta “starting configuration” al terminale. Strano, sembra proprio il comportamento tipico di regole di iptables applicate durante il boot in uno script di init!. Ma dalla cli invece il nulla, non risultano filtri di alcun genere.

Morale della storia, non siamo riusciti a risolvere il problema, ma i tecnici hanno dovuto ammettere ( anche per iscritto, mi sono fatto firmare una dichiarazione, non si sa mai potrebbe servirmi ) che il problema sta sul loro GAD, suggerendomi di attendere il cambio di contratto che ho in corso e che a breve mi fara’ cambiare il GAD con un router cisco, sperando che con quello il problema non si verifichi piu’.

Una cosa e’ comunque certa, nel firmware del GAD fastweb effettivamente FILTRA i pacchetti in ingresso sulla 5060 UDP!

A questo punto ringrazio il tecnico, lo lascio andare via, e appena uscito dalla porta spengo il gad, lo metto da parte, e rimetto la mia bella macchina linux davanti a tutto, e vivo felice con la mia bella rete che funziona. Per ora va bene cosi’, ne riparliamo quando mi cambieranno il router…

To be continued…