digg.it

#!/usr/bin/python
import pprint
from SOAPpy import WSDL

soap = WSDL.Proxy('https://www.ovh.com/soapi/soapi-re-1.3.wsdl')
#login
session = soap.login('###NIC###-ovh', '###PASS###', 'it', 0)
print "login successfull"
#dedicatedFailoverList
result = soap.dedicatedFailoverList(session, '###NOMEDEDICATO###')
print "dedicatedFailoverList successfull"
pp = pprint.PrettyPrinter(indent=4)
pp.pprint(result) # your code here ...
#logout
soap.logout(session)
print "logout successfull"

login successfull
Traceback (most recent call last):
File "./example.py", line 13, in ?
result = soap.dedicatedFailoverList(session, '###NOMEDEDICATO###')
File "/usr/lib/python2.4/site-packages/SOAPpy/Client.py", line 453, in __call__
return self.__r_call(*args, **kw)
File "/usr/lib/python2.4/site-packages/SOAPpy/Client.py", line 475, in __r_call
self.__hd, self.__ma)
File "/usr/lib/python2.4/site-packages/SOAPpy/Client.py", line 379, in __call
p, attrs = parseSOAPRPC(r, attrs = 1)
File "/usr/lib/python2.4/site-packages/SOAPpy/Parser.py", line 1006, in parseSOAPRPC
t = _parseSOAP(xml_str, rules = rules)
File "/usr/lib/python2.4/site-packages/SOAPpy/Parser.py", line 985, in _parseSOAP
parser.parse(inpsrc)
File "/usr/lib/python2.4/site-packages/_xmlplus/sax/expatreader.py", line 109, in parse
xmlreader.IncrementalParser.parse(self, source)
File "/usr/lib/python2.4/site-packages/_xmlplus/sax/xmlreader.py", line 123, in parse
self.feed(buffer)
File "/usr/lib/python2.4/site-packages/_xmlplus/sax/expatreader.py", line 216, in feed
self._parser.Parse(data, isFinal)
File "/usr/lib/python2.4/site-packages/_xmlplus/sax/expatreader.py", line 363, in end_element_ns
self._cont_handler.endElementNS(pair, None)
File "/usr/lib/python2.4/site-packages/SOAPpy/Parser.py", line 234, in endElementNS
kind = (self._prem[kind[:i]], kind[i + 1:])
KeyError: u'typens'

svn export https://pywebsvcs.svn.sourceforge.net/svnroot/pywebsvcs/trunk/SOAPpy/ SOAPpy-0.12.0
tar -zcf SOAPpy-0.12.0-dev.tar.gz SOAPpy-0.12.0
rm -rf SOAPpy-0.12.0
mv SOAPpy-0.12.0-dev.tar.gz /usr/src/redhat/SOURCES

cd /usr/src/redhat/SPECS
wget http://digg.it/wp-content/uploads/2009/06/SOAPpy-0.12.0.spec
rpmbuild --define="dist .el5" --define "centos 5" -ba SOAPpy-0.12.0.spec
rpm -Uvh /usr/src/redhat/RPMS/noarch/SOAPpy-0.12.0-dev.el5.noarch.rpm

Recensione di una F5 mini (ADSL di NGI): era meglio Alice?

Cronologia dell’attivazione

14/05/2009: richiesta F5 7M/384 mini
21/05/2009: appuntamento telefonico Telecom per il giorno dopo!
22/05/2009: tecnico telecom 3 ore per infilare un cavo e giri vari in centrale e derivazioni per far finalmente sentire la portante. Mentre lui misurava con lo “strumento” la mia linea alla mia affermazione “siamo distanti dalla centrale, non andrà molto veloce!” ha prontamente replicato “la distanza non è elevata, è che ci sono parecchie derivazioni vecchie e marce“.
22/05/2009: NGI mi manda login/password dichiarando la linea attivata.
22/05/2009: la sera riesco finalmente a collegare il router ma non aggancia.

Date/Time  	Facility  	Severity  	Message
Jan 1 00:01:25 	user 	crit 	kernel: ADSL G.994 training
Jan 1 00:01:26 	user 	crit 	kernel: ADSL G.992 started
Jan 1 00:01:31 	user 	crit 	kernel: ADSL G.992 channel analysis
Jan 1 00:01:36 	user 	crit 	kernel: ADSL G.994 training
Jan 1 00:01:41 	user 	crit 	kernel: ADSL G.992 channel analysis
Jan 1 00:01:46 	user 	crit 	kernel: ADSL G.994 training
Jan 1 00:01:51 	user 	crit 	kernel: ADSL G.992 started
Jan 1 00:01:56 	user 	crit 	kernel: ADSL G.992 channel analysis
Jan 1 00:02:01 	user 	crit 	kernel: ADSL G.994 training
Jan 1 00:02:06 	user 	crit 	kernel: ADSL G.992 channel analysis
Jan 1 00:02:11 	user 	crit 	kernel: ADSL G.994 training
Jan 1 00:02:16 	user 	crit 	kernel: ADSL G.992 started
Jan 1 00:02:21 	user 	crit 	kernel: ADSL G.992 channel analysis
Jan 1 00:02:26 	user 	crit 	kernel: ADSL G.994 training
Jan 1 00:02:32 	user 	crit 	kernel: ADSL G.992 channel analysis
Jan 1 00:02:38 	user 	crit 	kernel: ADSL G.994 training
Jan 1 00:02:41 	user 	crit 	kernel: ADSL G.992 started
Jan 1 00:02:46 	user 	crit 	kernel: ADSL G.992 channel analysis
Jan 1 00:02:51 	user 	crit 	kernel: ADSL G.994 training
Jan 1 00:02:56 	user 	crit 	kernel: ADSL G.992 channel analysis
Jan 1 00:03:01 	user 	crit 	kernel: ADSL G.994 training
Jan 1 00:03:06 	user 	crit 	kernel: ADSL G.992 started
Jan 1 00:03:11 	user 	crit 	kernel: ADSL link down
Jan 1 00:03:16 	user 	crit 	kernel: ADSL G.994 training
Jan 1 00:03:21 	user 	crit 	kernel: ADSL G.992 channel analysis
Jan 1 00:03:22 	user 	crit 	kernel: Unable to send OAM cell over VPI/VCI
8/35 (error 9).
Jan 1 00:03:22 	user 	crit 	kernel: Unable to send OAM cell over VPI/VCI
8/35 (error 9).
Jan 1 00:03:26 	user 	crit 	kernel: ADSL G.994 training

22/05/2009: Rispondo all’email di attivazione segnalando il non funzionamento con il log del kernel. Lascio il router attaccato, così vedo la lucina dell’ADSL che lampeggia (training) e mi accorgo se per caso sistemano.
23/05/2009: (sabato). La mattina trovo il router connesso così controllo subito e vedo che è connesso a 320kbps downstream / 480 upstream. 320kbps ???? Si era connesso la notte, dopo 8 ore di tentativi. Così nel weekend rimane connesso a 320, o a volte 384, segnalando comunque vari CRC.
25/05/2009: 3 giorni dopo mi rispondono che loro non possono aiutarmi e che devo aprire un ticket su assistenza! Per loro la linea è attiva, quindi si tratta di un guasto! Apro subito il ticket allegando i dati forniti dal router:

28/05/2009: finalmente, dopo 6 giorni di linea connessa a 320kbit/384kbit o per diverse ore completamente disconnessa il router aggancia a 2500kbps. Il 28 faccio diverse prove sulla mia “nuova linea” finalmente funzionante e riesco anche a connettermi a 3.1mbps senza problemi di instabilità.

28/05/2009: Alle 23.30 stavo finalmente gioiendo della mia nuova linea “funzionante” quando cade la connessione e si riconnette a 320kbps per poi morire definitivamente dopo 30 minuti.

30/05/2009: A linea connessa a 320kbps NGI mi chiude il ticket: “il fornitore ha chiuso la segnalazione di guasto inerente la sua linea. Da nostre verifiche il problema sembra rientrato.” Quali verifiche visto che sono connesso a 320kbps e che tutta la notte non si connetteva??

01/06/2009: NGI “abbiamo chiesto un ulteriore verifica a telecom Italia sulla sua linea adsl.“

03/06/2009: Dopo altri 6 giorni di connessione con le stampelle o connessione assente del tutto decido di dedicare un po’ di tempo a capirne di più. Mi preoccupo quindi di testare la linea con DMT, ottimo strumento di analisi, che sul firmware originale dell’asus wl-600g dice l’SNR margin di ciascun tono e che mi permette di tracciare l’andamento dell’SNRM con questo il risultato:

Si nota come l’SNRM abbia notevoli fluttuazioni e come la curva dell’SNR db per tono al posto degli aspettati quasi 40db al centro dello spettro ha un bel buco di SNR -11db: A 560Khz il rumore è più ampio del segnale, tutto il gap tra i 200 e i 500khz (normalmente fascia privilegiata) non arriva a 20db.

Vista l’evidenza del problema anomalo scrivo subito ad NGI convinto che con un grafico del genere possano capire il problema immediatamente (o farlo capire a Telecom) per arrivare ad una veloce soluzione (sottolineo che il mio tono nei confronti di NGI è collaborativo e non incazzato, per ora).

04/06/2009: Ricevo una telefonata da un tecnico Telecom che mi dice che dalla centrale misurano un SNR di 20db, che a suo dire è molto buono. Cerco di spiegargli la storia dei 560Khz e della curva dell’SNR per tono ma vengo ignorato (o forse non compreso). Conferma, però, che è strano che con 20db il mio router si colleghi a 320kbps e dice che se la notte non si collega per ora è colpa di NGI (???). Poi interrompono la linea per fare dei test.

Dopo un po’ mi richiama e chiede di venire a fare dei test dal mio lato pensando che possa essere il mio modem ad avere problemi. Il suo strumento da gli stessi identici problemi e si collega a 320kbps. Gli faccio vedere i miei grafici DMT ma l’unico risultato è un “bello quel programma!“. Dopo un paio d’ore di telefonate in centrale e tentativi mi liquida dicendo che la loro linea funziona e che è un problema di instradamento ATM di NGI. (non sono il massimo esperto in materia ma che un problema di instradamento ATM possa variare le curve dell’SNR del loop DSL mi suona “alternativo”, ma mica posso mettermi a litigare con un tecnico Telecom, ditta con la quale non ho alcun contratto a cui appellarmi!).  Lo saluto e mi dice che girerà il guasto a chi di competenza e che io non devo fare nulla.

Nel frattempo riesco a provare un secondo router (identico) con però il firmware aggiornato all’ultima versione compilata da TheDrake che include un driver adsl per il chip broadcom più aggiornato (versione A2p023k proveniente dal modem USR9113) e che scambia molte più informazioni con DMT.

Verso le 14.40, ad un ennesima richiesta di resync fatta con DMT, il router si collega a più di 2mbps, per poi arrivare a 3168 come si vede da questo grafico:

Con il nuovo firmware non solo riesco a vedere gli SNR per tono, ma riesco anche a visualizzare quanti bit vengono allocati su ugnuno e quali toni quindi vengono usati. Questo è il grafico di una ADSL funzionante (vedete che al centro è quasi 40db?) e con un SRN margin estremamente stabile (vedete quanto è piatta la linea del terzo grafico?). La buona notizia è che è la mia linea e quindi forse il tecnico Telecom ha passato la palla alle persone giuste ed hanno capito e risolto il problema!

06/06/2009: al mio aggiornato in cui segnalavo che dal pomeriggio aveva cominciato ad andare bene NGI mi risponde “la Sua pratica risulta tutt’ora in lavorazione lato Telecom Italia. Le faremo sapere qulacosa non appena l’intervento verrà chiuso“

07/06/2009: Ore 14.40. Dopo 3 giorni esatti di ottimo funzionamento cade la linea per riconnettersi a 384kbps. Controllo immediatamente con DMT e il grafico dei toni è tornato ad essere quello brutto che avevo all’inizio. Alle 17 cade proprio la linea e non si riconnette più. Armato del nuovo firmware configuro il router per fare un sync “più estremo” accettando un margine segnale rumore di pochi decibel (adslctl configure –snr 10) riesco a fare il sync a circa 1mbps con un SNRM di 7db che però calano inesorabilmente e costantemente fino a mezzanotte in cui con 4.5db di SNRM mi cade la linea dopo un’ondata di errori CRC. A questo punto non mi connetto più con nessuno dei due router e con nessuna impostazione.

08/06/2009: Segnalo a NGI il problema e ricevo come risposta: “il fornitore afferma di aver risolto il problema sul suo circuito adsl. Da nostre verifiche il problema persiste, quindi abbiamo richiesto una nuova verifica.“.

09/06/2009: NGI mi dice che: “il fornitore ha chiuso la segnalazione di guasto inerente la Sua linea sostenendo la necessità di effettuare un downgrade della stessa a 1280/256 rate-adaptive causa eccessiva distanza da centrale.” Continua poi proponendomi di accettare per iscritto o di procedere alla disdetta/rimborso.

Cerco così di spiegare al tecnico NGI (quelli che mi rispondo all’assistenza sono tecnici?) tutta la trafila perchè convenga con me che non si tratta di un banale problema di distanza dalla centrale ed SNR ma di altro.

Riassumendo

La mia linea ha presentato due stati:

• Stato 0 – Linea non funzionante: La linea si collega a 320kbit (a meno che io non faccia hack del router in modo da accettare un SNRm inferiore ai 10db, che è lo standard del router) e a volte per 7 ore non si collega proprio. l’SNR margin oscilla del 30% nell’arco di pochi minuti. Più volte, nonostante connesso a 320kbit tra le 22 e le 2 di notte è caduta la linea per non ricollegarsi più fino alle 6 della mattina.
• Stato 1 – Linea funzionante: la linea si collega a 2-3Mbit e l’SNR margin è stabile senza alcuna oscillazione. Se uso l’hack del router per connetterlo con un SNRmargin più basso vado anche oltre i 4. Se provo a spingerlo a 5 vedo dei CRC. E questo è normalissimo con un a linea distante.

Dal giorno dell’ “ipotetica attivazione” così distribuiti:

• Stato 0 – dal 22 al 27 maggio. Linea down o 320kbit.
  
• Stato 1 – il 28 maggio è andata a 2500-3100kbps correttamente fino a sera
• Stato 0 – dalla sera del 28 maggio al 4 giugno o si connetteva a 320kbit ed ogni tanto cadeva la linea o non si connetteva proprio per varie ore (di solito tutta la notte down).
• Stato 1 – Dalle 14.40 del 4 giugno (2 ore dopo che era stato qui il tenico telecom) si è connesso a 3168 con un SNRm di 11db stabilissimo (nemmeno l’1% di oscillazione) ed è rimasto così fino alle 14.40 del 7 giugno.
• Stato 0 – Dalle 14.40 del 7 giugno la linea è di nuovo a 320 o disconnessa. Oppure si connette ad 1mbit se uso il modem hackato e vado a pochi db di SNRm.

La mia conclusione è che:

• In stato 1 la linea va bene (3-4mbps per un linea distante sono più che accettabili) e non c’è bisogno di limitarla (al limite la limito io aumentando l’SNRm del modem, se voglio).
• Quando è in stato 0 la linea non va per ore, o va a 320kbit (arrivo a 1mbps circa se abbasso l’SNRm ma con parecchi CRC) e comunque spesso cade anche a 320kbit (!!!) e rimane down per notti intere (!!!). Cosa potrebbe risolvere limitare la velocità a 1280 se già a 320 già non funziona??

Spero che NGI voglia seguirmi nella risoluzione del problema, altrimenti l’unica soluzione potrebbe essere quella di chiedere il rimborso ed attivare Alice. Almeno in quel caso potrò lamentarmi direttamente con il fornitore ed evitare di perdere tempo con un intermediario che sembra non ascoltare.

Aggiornamenti

09/06/2009: Dopo altre comunicazioni da NGI che sembra essere d’accordo con Telecom che il problema sia l’SNR dovuto alla distanza dalla centrale rispondo in questo modo:

Secondo me è significativo che per 3 giorni interi (72 ore esatte) la mia linea è stata connessa a più di 3000kbps, e che l’SNRm era piatto come non mai, non una fluttuazione che una! Nel grafico che ho allegato il 5 giugno (dmtm20090605_0920.png) potete vederlo con i vostri occhi.

Questa secondo me è la prova tangibile che il problema non è la distanza poichè posso assicurarvi che in quei 3 giorni casa mia non si è avvicinata alla centrale e l’SNRm non s’è mosso, con grafici di SNR/tono ottimali e costanti durante tutte le 72 ore.

(volendo sdrammatizzare potremmo supporre che io abbia scoperto, guardando molto star trek, come usare la curvatura per far si che la distanza apparente tra me e la centrale diminuisse, ma se fossimo in questo caso converrete con me che vale la pena approfondire che magari diventiamo tutti ricchi!)

Vedremo come prosegue e se NGI saprà confermarsi un’ottimo fornitore quale è stato in questi 8 anni in cui sono sempre stato loro cliente o se vedrò spezzate le mie illusioni.

30/06/2009
Lunedì e martedì scorso la linea è andata bene, poi di nuovo male.

Ho riaperto l’ennesimo guasto con NGI che ha girato la cosa a Telecom. Sabato mattina mi chiama una tecnica telecom dalla centrale per venire da me. Mentre sono al telefono controllo la linea che è completamente down. Glielo riferisco e mi dice che sta staccando e riattaccando fili in centrale.

Dopo pochi minuti la linea si connette bene (3mbit con 12db di SNRm). Quando arriva le faccio presente che dopo poco che mi aveva chiamato si era connesso correttamente. Non attacca nulla mi chiede i due parametri (velocità/SNRm) e chiama col cellulare. Li riferisce e poi esce di casa continuando a chiacchierare. Dopo 10 minuti torna e mi dice che hanno messo la linea in “monitoraggio” così durante il weekend potranno testarla e se ne va (notare che nuovamente in casa mia e nell’ultima scatola di derivazione non è stato fatto niente).

Dopo circa 1 ora la linea torna a funzionare lenta (320kbit, 10db SNRm): chiamo la tecnica al cellulare (visto che mi aveva chiamato perchè non trovava casa mia) e quando glielo riferisco mi chiede “io sono già tornata a forlì (sede telecom), com’è il tempo lì?” le rispondo che “sgocciola” e lei mi dice “comunque oggi non facciamo più niente, la linea è in monitoraggio, lunedì al rientro i tecnici analizzeranno i dati”.

A oggi sono ancora connesso a 320kbit.

Chissà cosa fanno con questo “monitoraggio” e chissà perchè in un mese in cui ho aperto 7 guasti non hanno deciso di “monitare” prima….

01/07/2009
Oggi è venuto un altro tecnico telecom, questa volta con uno strumento diverso dagli altri.

Dalla scatola di derivazione dietro casa ha provato “l’impedenza” (così ha detto) verso il mio router e verso la centrale. Verso il mio router tutto ok, mentre quando ha misurato verso la centrale ha detto “c’è qualcos’altro attaccato a questa linea, devo verificare le altre derivazioni o spostarti su un’altra coppia. comunque lei può andare, non ho bisogno di entrare in casa sua”.

Ovviamente pochi minuti prima che venisse il tecnico la linea si era messa ad andare bene e dopo qualche ora che se ne è andato ha ricominciato ad andare male (ultimamente succede sempre così).

Oggi c’era un sole che spaccava, quindi non può essere un fenomeno legato alla pioggia (ultimamente andava bene solo durante i temporali).

Comunque mi ha richiamato dopo un po’ dicendo che lui non poteva risolvere e che aveva girato il problema ai “tecnici di rete” che mi chiameranno domani o dopodomani per sostituire il doppino. Ora, il doppino da casa mia alla derivazione abbiamo stabilito già cento volte che va bene, spero che con sostituire il doppino intenda che rifanno un pezzo di connessione tra la scatola di derivazione dietro casa mia e la centrale. Non so perchè non abbiano provato a spostarmi su un’altra coppia (in quella scatola di derivazione ne arrivano almeno 16 e ce ne sono 4 occupate), ma questi sono loro segreti di stato!

02/07/2009
Oggi ho trovato la mia linea connessa a 8mbit con 7db di SRNm… allora ho rimesso i canonici 12db e mi connetto a 6.5mbit!!! MOLTO meglio di quando andava bene!

l’SNR massimo è passato dai 26/36 di prima (lento/veloce) ai 47 di adesso. L’attenuazione è passata dai 49db di prima a 38db. Forse hanno accorciato di 1km la mia linea????

Boh, che dire.. non so cosa hanno fatto e quanto durerà ma spero bene!

Conclusione

E’ già una settimana che la linea va bene, meglio di quando credevo andasse bene, molto meglio di quando andava male. E’ un peccato che ci siano voluti 40 giorni e 8-9 segnalazioni di guasti duranti i quali hanno cercato di convincermi che era inutile lamentarsi della velocità della mia linea che andava così per via della distanza (giuro che casa mia non si è avvicinata alla centrale e nemmeno l’opposto!).

Chissà se l’apertura di vari thread su forum per segnalare il problema e questo blog che risultava ai primi posti su google cercando l’adsl di ngi ha in qualche modo avuto un peso nella soluzione del problema ma tutto è bene ciò che finisce bene!

Se state leggendo questo post ed avete problemi simili ricordatevi di rompere le palle: in italia sembra l’unico modo per essere ascoltati.

Tags: adsl, alice, dmt, f5, ngi, wl600g

sh# service munin-node restart