VirgilioTin: ADSL in panne

Da ieri sera è impossibile connettersi al servizio dal Veneto

Roma - Da ieri sera tutti gli abbonati del Veneto stanno sperimentando problemi di connessione con il servizio ADSL di VirgilioTin.

I problemi riscontrati dai clienti del servizio, assicurano dall'assistenza, sono in corso di soluzione e si spera di riuscire a ripristinare il servizio entro la giornata di oggi.

Le prime segnalazioni dell'impossibilità di connettersi alla Rete sono cominciate ad arrivare in redazione dalle ore 20 di ieri.
TAG: adsl
21 Commenti alla Notizia VirgilioTin: ADSL in panne
Ordina
  • Dal 16 Ottobre avevo fatto la richiesta per l'Adsl nel mio comune che risultava coperto stando al sito della telecom e anche al 187; dopo almeno 4 solleciti finalmente in data 16 Dicembre è venuto un tecnico della Netsiel ad installare il Modem Adsl e fare le opportune configurazioni, ma con grande sorpresa il modem non si allinea.Il tecnico, dopo un giro di telefonate ci informa che il problema dipende dalla centrale di Napoli che non ha ancora configurato le centraline nel mio comune (Acquaviva delle Fonti-BA) e che nel giro di qualche giorno avrebbero messo tutto ok!
    Dopo almeno altri 15 solleciti fatti al 187, telecom di bari, telecom di napoli non senza aver parlato con personale incompetente ho deciso di fare la disdetta dal contratto ADSL.
    Voci di amici che lavorano nel settore, mi hanno informato che è vero che 'ADSL risulta attivabile nel mio paese, ma sostanzialmente non è così in quanto bisogna ancora programmare le centraline, il tutto è stato fatto come una operazione di marketing per accaparrarsi subito clienti per un servizio che in realtà non è ancora attivo. Scusate lo sfogo ma quando è troppo è troppo.
    non+autenticato
  • il problema DUP! è anche più comunemente chiamato TCP Chorusing, è spesso creato da sistemi che bindano più stack tcp/ip allo stesso macaddress.
    L'impatto è ovviamente quello di rendere un network (o parte di esso) inusabile, il funzionamento del DHCP e dell'attribuzione deve essere chiesto al carrier visto che su altre tratte funziona tutto correttamente.
    non+autenticato
  • Da ieri ci sono diverse disfunzioni su BBB (siti esteri principalmente) in
    modo particolare per gli abbonamenti V-FAST.
    Ho fatto diverse prove dall'estero, con pazienza ed attenzione, ed ecco
    cosa è emerso (il mio IP dinamico all'atto delle prove era 62.211.150.14):

    $ /usr/sbin/traceroute 62.211.150.14
    traceroute to 62.211.150.14 (62.211.150.14), 30 hops max, 38 byte packets
    1 router.dedicatedns.com (209.239.000.000) 0.879 ms 0.668 ms 0.505 ms
    2 BCR2-G400.dedicatedns.com (208.49.89.18) 0.659 ms 0.644 ms 0.559 ms
    3 pos12-0-0.ar1.PHI1.gblx.net (208.49.224.93) 2.715 ms 2.625 ms 4.630
    ms
    4 pos4-0-155M.cr2.PHI1.gblx.net (206.132.118.221) 2.806 ms 2.620 ms
    2.613 ms
    5 pos0-0-622M.cr2.NYC2.gblx.net (206.132.249.158) 9.705 ms 5.215 ms
    4.892 ms
    6 so0-1-0-622M.ar2.NYC2.gblx.net (208.48.234.206) 5.021 ms 5.330 ms
    5.237 ms
    7 TelecomItalia1.so-2-1-0.ar2.NYC2.gblx.net (208.48.33.6) 98.829 ms
    98.849 ms 98.725 ms
    8 ge9-0-mil8-mila.mil.seabone.net (195.22.208.7) 98.528 ms 98.873 ms
    98.730 ms
    9 ibs-adsl3-it-mi8.seabone.net (195.22.196.78) 98.956 ms 99.350 ms
    99.257 ms
    10 r-mi213-fa4.interbusiness.it (151.99.75.218) 99.469 ms 99.089 ms
    99.242 ms
    11 151.99.75.159 (151.99.75.159) 99.493 ms 100.083 ms 100.068 ms
    12 151.99.101.102 (151.99.101.102) 104.235 ms 103.702 ms 103.416 ms
    13 r-to081-6.interbusiness.it (62.86.98.24) 141.604 ms 103.523 ms
    102.849 ms
    14 62.211.150.14 (62.211.150.14) 160.271 ms 159.211 ms 159.656 ms

    quindi fino a qui tutto benone velocità e risposta dei nodi sicuramente
    notevole, tempi medi sempre inferiore ai 100ms qualche lentezza negli
    ultimi tre passaggi ma tutto sommato trascurabile.
    Ma ecco alla prova del fuoco...

    $ ping 62.211.150.14
    PING 62.211.150.14 (62.211.150.14) from 209.239.000.000: 56(84) bytes of
    data.
    64 bytes from 62.211.150.14: icmp_seq=0 ttl=117 time=165.0 ms
    64 bytes from 62.211.150.14: icmp_seq=1 ttl=117 time=164.1 ms
    64 bytes from 62.211.150.14: icmp_seq=1 ttl=117 time=172.2 ms (DUP!)
    64 bytes from 62.211.150.14: icmp_seq=2 ttl=117 time=164.5 ms
    64 bytes from 62.211.150.14: icmp_seq=2 ttl=117 time=171.5 ms (DUP!)
    64 bytes from 62.211.150.14: icmp_seq=3 ttl=117 time=163.3 ms
    64 bytes from 62.211.150.14: icmp_seq=3 ttl=117 time=171.7 ms (DUP!)
    64 bytes from 62.211.150.14: icmp_seq=4 ttl=117 time=163.3 ms
    64 bytes from 62.211.150.14: icmp_seq=4 ttl=117 time=171.2 ms (DUP!)
    64 bytes from 62.211.150.14: icmp_seq=5 ttl=117 time=165.8 ms
    64 bytes from 62.211.150.14: icmp_seq=5 ttl=117 time=173.0 ms (DUP!)
    64 bytes from 62.211.150.14: icmp_seq=6 ttl=117 time=191.3 ms
    64 bytes from 62.211.150.14: icmp_seq=6 ttl=117 time=199.5 ms (DUP!)
    64 bytes from 62.211.150.14: icmp_seq=7 ttl=117 time=162.1 ms
    64 bytes from 62.211.150.14: icmp_seq=7 ttl=117 time=169.4 ms (DUP!)
    64 bytes from 62.211.150.14: icmp_seq=8 ttl=117 time=164.3 ms
    64 bytes from 62.211.150.14: icmp_seq=8 ttl=117 time=172.6 ms (DUP!)
    64 bytes from 62.211.150.14: icmp_seq=9 ttl=117 time=164.0 ms
    64 bytes from 62.211.150.14: icmp_seq=9 ttl=117 time=172.2 ms (DUP!)
    64 bytes from 62.211.150.14: icmp_seq=10 ttl=117 time=161.0 ms
    64 bytes from 62.211.150.14: icmp_seq=10 ttl=117 time=168.8 ms (DUP!)
    64 bytes from 62.211.150.14: icmp_seq=11 ttl=117 time=163.1 ms
    64 bytes from 62.211.150.14: icmp_seq=11 ttl=117 time=173.6 ms (DUP!)
    64 bytes from 62.211.150.14: icmp_seq=12 ttl=117 time=163.0 ms
    64 bytes from 62.211.150.14: icmp_seq=12 ttl=117 time=170.5 ms (DUP!)
    64 bytes from 62.211.150.14: icmp_seq=13 ttl=117 time=162.5 ms
    64 bytes from 62.211.150.14: icmp_seq=13 ttl=117 time=170.7 ms (DUP!)
    64 bytes from 62.211.150.14: icmp_seq=14 ttl=117 time=165.2 ms
    64 bytes from 62.211.150.14: icmp_seq=14 ttl=117 time=173.3 ms (DUP!)

    --- 62.211.150.14 ping statistics ---
    15 packets transmitted, 15 packets received, +14 duplicates, 0% packet loss
    round-trip min/avg/max = 161.0/169.4/199.5 ms


    oppsss !!! ecco che è successo... scopro quindi con estrema felicità che
    non è colpa del mio server o del mio client.

    Fatto le stesse prove con Tiscali, Libero ADSL, FastWeb, Colt-Telecom,
    Infostrada; il risultato è che con tutti gli atlri carrier il problema
    (DUP!) non si manifesta a tutto funziona benone.

    A questo punto vi rimando alle guide del Tcp/Ip per non entrare in
    squisite questioni tecniche su router etc.etc. e sull'interpretazione del
    fatto che DUP! si abbia da ieri solo con connessioni ADSL di Virgilio TIN

    gigi
    non+autenticato
  • > A questo punto vi rimando alle guide del
    > Tcp/Ip per non entrare in
    > squisite questioni tecniche su router
    > etc.etc. e sull'interpretazione del
    > fatto che DUP! si abbia da ieri solo con
    > connessioni ADSL di Virgilio TIN
    per tutti (spiegazione limitata):
    dup = duplicate acknowledgments
    da vedere broadcasting and multicasting (capitoli dopo il 10 di solito in ogni tcp/ip book)
    >The problem is dup acks. If TCP packets arrive
    >out of order, you get dup acks, and the sender
    >will resend even though the link layer has
    >already filled the hole.
    ====
    >sends a duplicate ACK
    >whenever it receives a new segment that it
    >cannot acknowledge because it has not yet
    >received all the previous segments


    > gigi
    c'e gigi ??? e la cremeria ??? (lo so, sono scemo)
    ;-0)

    non+autenticato
  • Almeno da quando l'ho attivato pochi giorni fa.
    A parte alcuni tribolamenti con certo loro personale UTONTO al call center, risolto con qualche saracca all' UTONTO di turno che poi mi ha passato una pesona veramente competente che al telefono e ognuno davanti ai propri picci , (lui da Roma presso la sede Virgilio Tin) e io dal mio Bunker, mi ha risolto il problema.
    Il problema per il quale non riuscivo a connettermi, nonostante la visita nel mio Bunker di 3 "esperti" nella configurazione di cui 1 ho allontanato x manifesta incompetenza, dicevo il problema era che avendo installato sul mio picci un Modem ADSL Ethernet(ora collegato all' Hub, loro avevano configurato in centrale un Modem USB che chiaramente non poteva colloquiare col mio x differenza di protoolli.
    Risilto telematicamente il problema di connessione, mi sono subito collegato alla linea ADSL (e fino ad ora funza che è una meraviglia salvo una paio di interruzioni x loro "upgrade" di Server).
    Comunque, voglio aggiungere che il personale ai loro call center sono sempre stati gentili e solerti. (speriamo che continui altrimenti si cambierà provider).
    bye from Alien.

    non+autenticato
  • a bologna , mi associo alla toccata di maroni, mi sembra che vada bene , scarico quasi sempre a 25 30 35 k al s. insomma prima andavo a 2. 3 k se andava bene Sorride.non me ne intendo ma comincio a pensare che ogni zona faccia storia a se . se in un posto hanno centraline tenute da cacca allora il servizio andra di conseguenza, se i tecnici sono incompetenti ecc ecc....
    non+autenticato
CONTINUA A LEGGERE I COMMENTI
1 | 2 | 3 | Successiva
(pagina 1/3 - 12 discussioni)