Problemi con TIM - Thread ufficiale

[Aima]

Originariamente inviato da mavelot

Sei fuori strada....

Miiiii ma rispondi semplicemente, no?
Non pensavo fosse un affare di stato, evidentemente toccare i nas è davvero illegale ghghgh

Seriamente, perché facevi quella distinzione?

[mavelot]

Originariamente inviato da Aima

Eheheh non ti inalberare, mica stavo insinuando niente, era solo una possibile differenza che mi pareva il caso di valutare. Se rispondi a sto modo, mi fai pensare che insinuassi tu.
Cmq se giri un po' sui forum ci sono un sacco di altri casi in cui le persone postano la loro configurazione, col gateway predefinito con indirizzo pubblico.
Per quanto tu sia sicuramente esperto, si vede che non ti è mai capitato, ma evidentemente non è raro.

Non metto in dubbio...ritengo sia un numero insignificante, sulle migliaia di NAS telecom sparsi in tutta Italia...evidentemente qualche configurazione sporca deve pur esserci

[skryabin]

Originariamente inviato da mavelot

Non metto in dubbio...ritengo sia un numero insignificante, sulle migliaia di NAS telecom sparsi in tutta Italia...evidentemente qualche configurazione sporca deve pur esserci

io ti confermo che un paio di tracert dove non c'era il 192.168.100.1 sul tracert di alcune connessioni alice li ho visti anche io in passato nel mio piccolo (quando frequentavo gli ambienti di esl, cod e via dicendo e il ping era 40ms meno di adesso)
ma la storia del terzo hop che coincinde con l'ip del nas (che dovrebbe essere nascosto), questa la sto scoprendo adesso

[mavelot]

E' sempre bene far conoscere il meno possibile la struttura della rete....questa è una cosa ovvia....ecco il perchè del NAT. E' una pratica usuale anche nelle VPN...si chiama host insulation.

Inoltre NATTANDO gli utenti gli si da maggiore protezione, in quanto non conoscendo l'IP del gateway risulta più difficile raggiungere tutte le altre utenze che hanno lo stesso gateway

[skryabin]

Originariamente inviato da mavelot

E' sempre bene far conoscere il meno possibile la struttura della rete....questa è una cosa ovvia....ecco il perchè del NAT. E' una pratica usuale anche nelle VPN...si chiama host insulation.

Inoltre NATTANDO gli utenti gli si da maggiore protezione, in quanto non conoscendo l'IP del gateway risulta più difficile raggiungere tutte le altre utenze che hanno lo stesso gateway

dicevo prima, è un po' come collegare un pc via modem usb o col router via lan detti in termini grezzi...se ci metti il router hai un maggiore controllo su quello che passa e che non deve passare, e su cosa mostrare e cosa non mostrare.

[darkhim]

Microsoft Windows [Versione 6.1.7600]
Copyright (c) 2009 Microsoft Corporation. Tutti i diritti riservati.

C:\Users\Darkhim>ping 192.168.100.1

Esecuzione di Ping 192.168.100.1 con 32 byte di dati:
Risposta da 192.168.100.1: byte=32 durata=22ms TTL=254
Risposta da 192.168.100.1: byte=32 durata=21ms TTL=254
Risposta da 192.168.100.1: byte=32 durata=22ms TTL=254
Risposta da 192.168.100.1: byte=32 durata=21ms TTL=254

Statistiche Ping per 192.168.100.1:
Pacchetti: Trasmessi = 4, Ricevuti = 4,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 21ms, Massimo = 22ms, Medio = 21ms
______________________________________________________________

Microsoft Windows [Versione 6.1.7600]
Copyright (c) 2009 Microsoft Corporation. Tutti i diritti riservati.

C:\Users\Darkhim>tracert maya.ngi.it

Traccia instradamento verso maya.ngi.it [88.149.128.3]
su un massimo di 30 punti di passaggio:

1 <1 ms <1 ms <1 ms 10.0.0.254
2 22 ms 21 ms 21 ms 192.168.100.1
3 22 ms 22 ms 21 ms host129-35-static.42-88-b.business.telecomitalia
.it [88.42.35.129]
4 23 ms 22 ms 24 ms 172.17.6.17
5 22 ms 22 ms 22 ms 172.17.6.66
6 23 ms 22 ms 22 ms gw-mi-nap2-r-mi265.opb.interbusiness.it [151.99.
98.130]
7 23 ms 22 ms 23 ms 85.36.8.90
8 23 ms 23 ms 23 ms 212.239.110.46
9 24 ms 23 ms 22 ms shield1-ext.net.ngi.it [81.174.0.246]
10 24 ms 23 ms 23 ms maya.ngi.it [88.149.128.3]

Traccia completata.







Tutta la rete è composta da linksys/cisco system e dns proprietario su server dedicato debian interno alla lan (no telecom/opendns)
Gataway e Router tutti con so linux dd-wrt

Test eseguiti con Torrent aperto in idle e 5 pc online in internet.

Secondo voi può andare? o gli faccio mettere il fast path?

[tavolone]

ciao
ho fatto tracert con 192.168.100.1

è venuto fuori questo

Traccia instradamento verso 192.168.100.1 su un massimo di 30 punti di passaggio


1 2 ms 1 ms 1 ms 192.168.0.1
2 40 ms 39 ms 47 ms 192.168.100.1

Traccia completata.

E' pericoloso?? Avrò problemi??


Scherzo...il ping è rimasto uguale a quello di ieri e a quello che avevo prima del disastro di ieri.

[kevindavidmitnick]

ah ma allora ancora continuate a fare i loschi?

allora continuo a farlo anche io

Esecuzione di Ping 192.168.100.1 con 32 byte di dati:

Risposta da 192.168.100.1: byte=32 durata=21ms TTL=126
Risposta da 192.168.100.1: byte=32 durata=21ms TTL=126
Risposta da 192.168.100.1: byte=32 durata=21ms TTL=126
Risposta da 192.168.100.1: byte=32 durata=21ms TTL=126

Statistiche Ping per 192.168.100.1:
Pacchetti: Trasmessi = 4, Ricevuti = 4, Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 21ms, Massimo = 21ms, Medio = 21ms

questo con alice 20 mega, distante pochi chilometri dalla centrale (credo 3-4 occhio e croce)

[monomm]

Microsoft Windows [Versione 6.1.7600]
Copyright (c) 2009 Microsoft Corporation. Tutti i diritti riservati

C:\Users\Mauro>Ping 192.168.100.1

Esecuzione di Ping 192.168.100.1 con 32 byte di dati:
Risposta da 192.168.100.1: byte=32 durata=42ms TTL=254
Risposta da 192.168.100.1: byte=32 durata=41ms TTL=254
Risposta da 192.168.100.1: byte=32 durata=41ms TTL=254
Risposta da 192.168.100.1: byte=32 durata=41ms TTL=254

Statistiche Ping per 192.168.100.1:
Pacchetti: Trasmessi = 4, Ricevuti = 4,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 41ms, Massimo = 42ms, Medio = 41ms






Questo mi esce di ping a me , e' malaccio ?

[-Mirco-]

Originariamente inviato da kevindavidmitnick

ah ma allora ancora continuate a fare i loschi?

allora continuo a farlo anche io



questo con alice 20 mega, distante pochi chilometri dalla centrale (credo 3-4 occhio e croce)

mi sa che devi rivalutare un pò la quantificazione di quel "pochi"

[stranahw]

spostato in alice 20 mega
scusate

[Lanfi]

Originariamente inviato da mavelot

E' sempre bene far conoscere il meno possibile la struttura della rete....questa è una cosa ovvia....ecco il perchè del NAT. E' una pratica usuale anche nelle VPN...si chiama host insulation.

Inoltre NATTANDO gli utenti gli si da maggiore protezione, in quanto non conoscendo l'IP del gateway risulta più difficile raggiungere tutte le altre utenze che hanno lo stesso gateway

Mavelot per curiosità...l'ip con cui si presentano in internet gli utenti fastweb è l'ip del loro gateway? E in caso affermativo, non potrebbe costituire una minaccia alla sicurezza degli utenti?

Comunque ragazzi siamo in un ot madornale....anche se davvero molto interessante!

[NandoPC]

Ritornando al problema dell'altro ieri, hanno risolto o no ?

[tavolone]

Per quanto riguarda la mia zona è tornato tutto come prima e questo mi fa pensare che abbiano aggiustato il guasto. Esattamente come prima, purtroppo, perchè Io, ingenuamente, ho sperato in un piccolo miglioramento per quanto riguarda la banda agganciata ma pare che non sia così. Comunque visto quello che sono in grado di dire e fare i vari tecnici che si occupano di banda larga è davvero tanto non aver perso nulla di quello che c'era.
Qualcuno a notato differenze in peggio o in meglio in seguito alla riparazione??

[slowped]

Originariamente inviato da Lanfi

E in caso affermativo, non potrebbe costituire una minaccia alla sicurezza degli utenti?

E per quale motivo dovrebbe essere una minaccia per gli utenti il fatto che costoro vengono visti con l'indirizzo IP del router che gli fa il NAT?

[mavelot]

Originariamente inviato da tavolone

Qualcuno a notato differenze in peggio o in meglio in seguito alla riparazione??

MA che domanda è ???

Se un cavo a fibre ottiche viene danneggiato/tranciato, è evidente che il traffico non può più passare su quella tratta.
Si procede di solito con meccanismi automatici a reinstradare il traffico attraverso altri nodi. A volte occorrono aggiustamenti manuali per risolvere il problema.

E' chiaro che una volta riparato il cavo, e ripristinato il link tra i nodi (tralasciamo amplificatori e altri amenicoli sulla tratta), il traffico può essere reinstradato come in origine....ne più ne meno.

Un cavo riparato funziona come prima....ne meglio ne peggio (a parte questioni di propagazione nel mezzo)

[Melkor]

Questo è il mio ping su maya. Se il cavo è riparato non dovrebbe essere quella la causa, ma "qualcosina" che non va c'è sicuramente... Ieri pingavo 43 di media.

Esecuzione di Ping maya.ngi.it [88.149.128.3] con 32 byte di dati:
Risposta da 88.149.128.3: byte=32 durata=1290ms TTL=55
Risposta da 88.149.128.3: byte=32 durata=1251ms TTL=55
Risposta da 88.149.128.3: byte=32 durata=1319ms TTL=55
Risposta da 88.149.128.3: byte=32 durata=1231ms TTL=55

[mavelot]

Maya lo pingo come sempre a 21ms

IL cavo danneggiato non c'èntra niente....era per connettività internazionale

[skryabin]

Originariamente inviato da Melkor

Questo è il mio ping su maya. Se il cavo è riparato non dovrebbe essere quella la causa, ma "qualcosina" che non va c'è sicuramente... Ieri pingavo 43 di media.

Esecuzione di Ping maya.ngi.it [88.149.128.3] con 32 byte di dati:
Risposta da 88.149.128.3: byte=32 durata=1290ms TTL=55
Risposta da 88.149.128.3: byte=32 durata=1251ms TTL=55
Risposta da 88.149.128.3: byte=32 durata=1319ms TTL=55
Risposta da 88.149.128.3: byte=32 durata=1231ms TTL=55

spengi emule

[Melkor]

Originariamente inviato da skryabin

spengi emule

Ho chiamato anche il 187 ma non ci sono segnalazioni di guasti. Mi hanno resettato non so che e come per magia tutto è rimasto come prima.