[FTTH] Tiscali FTTH - Pre-installazione linea (info/richieste/prezzi/FAQ)

[smz]

Salve a tutti,

sto cercando di utilizzare il mio router Ubiquiti EdgeRouter Lite (F/W 2.0.6) al posto del Technicolor fornito da Tiscali, ma non riesco a cavare un ragno dal buco...

Il problema è a livello di inizializzazione della sessioene PPPoE. APPARENTEMENTE l'Ubiquiti nel pacchetto PPPoE PADI inserisce un parametro che "non piace" ai Cisco che stanno dall'altra parte: si tratta del parametro Host-Uniq, che il Technicolor non invia mentre l'Ubiquiti invia, random o secondo impostazione utente.

Questo è il pacchetto inviato dal Technicolor in fase di boot:



al quale il Cisco di Tiscali risponde:



... e poi le cose vanno avanti con la negoziazione del link.


Con l'Ubiquiti, invece, il PADI diventa:



... che il Cisco ignora regalmente, senza nemmeno degnarsi di una risposta (e l'Ubquiti continua a ritrasmettere il PADI...)

L'altra ovvia differenza è il MAC address, ma tendo ad escludere problemi: ho anche provato a spoofare il MAC del Technicolor sull'ethernet dell Ubiquiti, ma non è cambiato nulla.

Qualcuno si è già scornato con problemi simili? Qualche idea su come risolvere?

Grazie!
Sergio

[tolwyn]

al tempo usai senza problemi proprio un er (non il lite, vabeh) sulla mia ftth tiscali senza alcun problema

[smz]

Originariamente inviato da tolwyn

al tempo usai senza problemi proprio un er (non il lite, vabeh) sulla mia ftth tiscali senza alcun problema

Firmware diverso? Io sto usando l'ultimo, 2.0.6
Eri su OpenFiber?

Ho cross-postato sul forum di Ubiquiti: vediamo cosa dicono lì...

Ciao!

[tolwyn]

tiscali su of sìsì, ma fw ovviamente meno recente non ricordo quale perchè appunto provai indietro nel tempo, avevo da poco attivato l'allacciamento si parla di metà 2017

[net83it]

stamane da Palermo ping verso Milano aumentano del 30/40% circa. sino ad ieri 21, da oggi 28/30
da una decina di giorni noto inoltre che l'upload supera tranquillamente i 300, punta massima 359

[Slash82]

Originariamente inviato da net83it

stamane da Palermo ping verso Milano aumentano del 30/40% circa. sino ad ieri 21, da oggi 28/30
da una decina di giorni noto inoltre che l'upload supera tranquillamente i 300, punta massima 359

stessa cosa 26-27ms.

Ieri mentre facevo lo speedtest e ho fatto 940 ( https://www.speedtest.net/my-result/...-4f64e74eacd5), ho notato che avevo sui 27-28ms.
Verso le 20 ho rifatto lo speedtest, ho fatto sui 300-350 e il ping da cmd era sui 20-21 ( il solito ping a cui siamo abituati).
E' una questione di instradamenti, forse quello più performante come velocità è un po' più lungo, mentre quello più breve è più saturo e vai più lento in dowload

[LuKe.Picci]

@smz perchè non vedo nessun tag vlan nel pacchetto inviato dal technicolor? come hai fatto la cattura?

[amd-novello]

Originariamente inviato da Radagast82

https://casa.tiscali.it/fibra-adsl/o...rnet_fibra_1G/
ofs. Migro o peggioro?

è quella che ho io. 1000/300
tiscali non è presente nel pop della città e usa la struttura OF fino a quando comincia la sua. credo sia MI

Originariamente inviato da Radagast82

fatta richiesta su tiscali, usando il codice di migrazione.
devo comunque dare disdetta a vodafone o basta questo?

io non l'ho fatta a wind la disdetta. vedo fra poco che arriva la fattura se è andato tutto bene. non è necessario comunque. sul sito tiscali lo scrive per evitare problemi ma di solito va tutto liscio. per dire io negli anni sono passato da wind a fw a vodafone a wind a tiscali e tutto ok

[ZioMatt]

Originariamente inviato da LuKe.Picci

Alcune righe faccio fatica a comprenderle, in particolare la quarta e la quinta. Per la quarta, è vero che per un certo MTU fissato il payload del ping ICMP massimo è pari a MTU-qualcosa. La quinta è un vaneggiamento, per me non ha alcun senso. Quindi in sostanza ogni numero che vedi a sinistra non indica sempre un valore di MTU, e non ho intenzione di controllare a cosa equivalga. Io la ignorerei, fa più confusione che altro.


Hai una perdita di efficienza solo quando mandi effettivamente un pacchetto di dimensioni massime. Supponiamo di voler trasmettere 1 milione di byte in TCP senza che vi sia alcun errore di trasmissione e alcuna necessità di ritrasmissione. Supponiamo che TCP sia già a regime e la finestra sia al massimo della sua apertura, cioè che il protocolla abbia preso massima confidenza sulla qualità del link e che non capiti mai di dover attendere un ACK in ritardo prima di poter trasmettere il prossimo pacchetto.

No attenzione, il TCP trasmette sempre pacchetti di dimensione tale da riempire il sottostante frame IP (ovviamente posto che lo stream di dati abbia almeno 1.5k di informazioni in coda, se si tratta di un keystroke su un terminale ovviamente il pacchetto sarà piccolo); le finestre di trasmissione e ricezione, algoritmi di slow-start e congestion non influiscono sulle dimensioni del singolo pacchetto inviato.
Inoltre, la "dimensione massima" non si verifica mai, perché questa viene aumentata ad ogni RTT fintantoché non vengono persi pacchetti, in quel caso viene abbassata e ricomincia il processo di crescita, con metodologie diverse a seconda dell'algoritmo di congestion adottato dallo stack TCP.

Tieni conto che inviare pacchetti con MTU diversi (l'interfaccia del tuo PC conosce solamente l'MTU del link locale, di solito impostato ai canonici 1500 byte) provoca nel router una frammentazione di ogni pacchetto, raddoppiando l'overhead Eth/PPP/IP per ogni trama TCP trasmessa...
Le cose sarebbero diverse in caso di connessioni su IPv6, ove non è prevista la possibilità nei router di transit di frammentare, ma la condizione di "superati limiti" viene segnalata al mittente, che abbasserà quindi la dimensione dei pacchetti verso quella destinazione.

@MiloZ se vuoi vedere la differenza, fai uno speedtest impostando manualmente dalle proprietà della scheda di rete del PC un MTU di 1470.

La differenza tra i 1470 e i 1492 onestamente non me la spiego...

[ZioMatt]

Originariamente inviato da LuKe.Picci

@smz perchè non vedo nessun tag vlan nel pacchetto inviato dal technicolor? come hai fatto la cattura?

Immagino con uno switch managed tra router e ONT, così da propagare la vlan tagged in una porta SPAN...
Windows è di una rogna assurda quando si tratta di acquisire dati con interfacce in monitor, spesso e volentieri non vedi dati di VLAN tagged perché scartati dai driver come pacchetti non validi... forse solo lo stack delle versioni Windows Server contempla le tagged VLAN, ma su questo non ho certezze...

[tolwyn]

confermo il comportamento sotto win10 workstation con i driver di alcune nic almeno nella mia esperienza

[gcesab]

Giusto per la cronaca e perche' potrebbe servire a qualcuno...

Il firewall non c'entrava nulla, ho cambiato l'indirizzo locale del Fritz (era 192.168.178.1) e tutto e' rientrato nella norma.

Misteri delle telecomunicazioni...

[deran]

Ma come mai i ping sono così "alti"?
Io con vodafone (open fiber) a Milano ho generalmente 2/3ms di ping... Passando a tiscali sempre OF devo aspettarmi ping simili?

[imsims22]

Originariamente inviato da LuKe.Picci

https://help.ubnt.com/hc/en-us/articles/115011654907
https://help.ubnt.com/hc/en-us/articles/115009403308

Di cui cito una parte:

non ho capito che dovrei fare? O_O

[imsims22]

ragazzi ma puo centrare che ho ip statico?

cioè l'0isntradamento diverso?

infatti mi localizza sempre a milano, no catania

[LuKe.Picci]

Originariamente inviato da ZioMatt

il TCP trasmette sempre pacchetti di dimensione tale da riempire il sottostante frame IP (ovviamente posto che lo stream di dati abbia almeno 1.5k di informazioni in coda

si (hai ragione) ma anche no (vedi sotto)

Originariamente inviato da ZioMatt

le finestre di trasmissione e ricezione, algoritmi di slow-start e congestion non influiscono sulle dimensioni del singolo pacchetto inviato

ovviamente la dimensione della finestra non influisce

Originariamente inviato da ZioMatt

Inoltre, la "dimensione massima" non si verifica mai, perché questa viene aumentata ad ogni RTT fintantoché non vengono persi pacchetti

corretto, per massima intendevo una dimensione attuale raggiunta tale da non limitare il libero flusso di pacchetti

Originariamente inviato da ZioMatt

@MiloZ se vuoi vedere la differenza, fai uno speedtest impostando manualmente dalle proprietà della scheda di rete del PC un MTU di 1470.

Non noterebbe alcuna differenza, il suo pc già adesso con MTU a 1500 non fa mai uscire un solo pacchetto TCP da più di 1430 byte.
Il primo SYN dell'handshake inviato dal suo PC non ha payload (se non sbaglio), è grosso quanto il solo header IP+TCP, per un totale di 40 byte (sempre che non mi sbagli) ed ha MSS impostato a 1460 (essendo l'MTU della scheda a 1500).
Il secondo pacchetto dell'handshake, SYN+ACK ricevuto, di nuovo non ha payload, ma ha MSS impostato a 1430.
A quel punto qualsiasi pacchetto inviato avrà anche lui MSS=min(SYN.mss, SYN+ACK.mss). Pertanto non potrà mai venir fuori pacchetto ip da più di 1470 byte.
Se fosse come dici tu qualsiasi pc con MTU impostato a 1500 (tutti quelli al mondo di default) causerebbe continua frammentazione. La risposta alla domanda "Chi diavolo è che imposta l'MSS del SYN+ACK a 1430??" cerca indietro in questa discussione.

Originariamente inviato da ZioMatt

La differenza tra i 1470 e i 1492 onestamente non me la spiego...

Evidentemente Tiscali ha (o aveva tanto tempo fa) bisogno di quel margine extra per fare ulteriore tunneling. Detto questo però non capita di rado di beccare utenti Vodafone che lamentano problemi da "MTU troppo alto", quindi a me sta più che bene il margine di sicurezza extra.

Nel caso ve lo foste perso, torno a ripetervi: l'MTU delle linee Tiscali non è (forse lo era) 1470, è 1492. Non vedrete tuttavia mai uscire in TCP (e solo TCP, non UDP, non ICMP, non ESP, ecc) un pacchetto IP da più di 1470 byte, per quanto spiegato prima.

[imsims22]

questi i valori dellONT

ho provato a collegarmi in PPOE dal pc diretto sull'ONT senza router tencicolro

peggio ancora
700/200

[LuKe.Picci]

Scusa ma qual era il tuo problema?

[amd-novello]

non vedere il giga pieno non è un problema
capita a tutti

i tuoi valori sono perfettamente oscillatori. magari evitare di fare test ogni giorno e goderti la linea

[ZioMatt]

Originariamente inviato da LuKe.Picci

Non noterebbe alcuna differenza, il suo pc già adesso con MTU a 1500 non fa mai uscire un solo pacchetto TCP da più di 1430 byte.
Il primo SYN dell'handshake inviato dal suo PC non ha payload (se non sbaglio), è grosso quanto il solo header IP+TCP, per un totale di 40 byte (sempre che non mi sbagli) ed ha MSS impostato a 1460 (essendo l'MTU della scheda a 1500).
Il secondo pacchetto dell'handshake, SYN+ACK ricevuto, di nuovo non ha payload, ma ha MSS impostato a 1430.
A quel punto qualsiasi pacchetto inviato avrà anche lui MSS=min(SYN.mss, SYN+ACK.mss). Pertanto non potrà mai venir fuori pacchetto ip da più di 1470 byte.
Se fosse come dici tu qualsiasi pc con MTU impostato a 1500 (tutti quelli al mondo di default) causerebbe continua frammentazione. La risposta alla domanda "Chi diavolo è che imposta l'MSS del SYN+ACK a 1430??" cerca indietro in questa discussione.



Evidentemente Tiscali ha (o aveva tanto tempo fa) bisogno di quel margine extra per fare ulteriore tunneling. Detto questo però non capita di rado di beccare utenti Vodafone che lamentano problemi da "MTU troppo alto", quindi a me sta più che bene il margine di sicurezza extra.

Nel caso ve lo foste perso, torno a ripetervi: l'MTU delle linee Tiscali non è (forse lo era) 1470, è 1492. Non vedrete tuttavia mai uscire in TCP (e solo TCP, non UDP, non ICMP, non ESP, ecc) un pacchetto IP da più di 1470 byte, per quanto spiegato prima.

Tutto corretto, ho verificato anche sulla mia connessione ADSL... ma questo appunto riguarda solo il TCP, perché ci sono i router impostati per variare la MSS al volo in fase di routing. Il valore scelto dipende dalle destinazioni, ho visto nelle prove anche valori di 1300 byte...

Tutti gli altri protocolli come giustamente facevi notare invece frammenteranno... uno su tutti QUIC, l'alternativa proposta da Google come fetch di contenuti, che lavora su pacchetti UDP...