# [mtu] navigazione estrema

## cloc3

finalmente ho buttato l'ultimo router wifi e riaccentrato il routing sotto il controllo di un server gentoo.

così, infatti, posso leggere i log e cominciare a capire dove si inceppa il segnale.

il problema principale viene dal forward delle connessioni wireless. adesso, infatti, è il server che smista verso internet il traffico dell'access point. per funzionare, ho dovuto prima di tutto aggiungere una riga in iptables per aggiustare il valore di mtu:

```

-A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1492

```

ma ancora non era sufficiente. il client, infatti, è molto distante e naviga con fatica, soprattutto nei siti più pesanti.  :Shocked: , ad esempio, era pressoché inaccessibile.

ho scoperto allora che le cose miglioravano molto riducendo il valore di mtu sulla scheda ath0 del client.

adesso, ho l'impressione che il valore migliore sia addirittura 100 (sic!).

esistono modi oggettivi per valutare il valore ottimale di mtu?

quali sono gli svantaggi e i problemi a cui potrei andare incontro, utilizzando dei valori tanto inferiori a quelli consigliati di default?

----------

## xdarma

 *cloc3 wrote:*   

> ho scoperto allora che le cose miglioravano molto riducendo il valore di mtu sulla scheda ath0 del client.
> 
> adesso, ho l'impressione che il valore migliore sia addirittura 100 (sic!).

 

Ma con 1500 non va bene?

----------

## oRDeX

Inatnto non confondiamo l'MSS (Maximum segment size, dimensione massima del segmento TCP), con l'MTU (Maximum transfer unit, dimensione massima del frame al livello 2).

Secondo me, fare prove sulla "navigazione" non ti da una stima precisa su quello che accade..Hai provato a fare dei ping di dimensione variabile, per capire se la frammentazione ti crea davvero problemi?

----------

## cloc3

 *oRDeX wrote:*   

> Hai provato a fare dei ping di dimensione variabile, per capire se la frammentazione ti crea davvero problemi?

 

con mtu=100:

```

cloc3@gentoo-live ~ $ ping -s 1484 www.pippo.it

PING www.pippo.it (195.128.235.47) 1484(1512) bytes of data.

1492 bytes from pippo.consultingweb.it (195.128.235.47): icmp_seq=1 ttl=118 time=174 ms

1492 bytes from pippo.consultingweb.it (195.128.235.47): icmp_seq=2 ttl=118 time=133 ms

1492 bytes from pippo.consultingweb.it (195.128.235.47): icmp_seq=6 ttl=118 time=117 ms

1492 bytes from pippo.consultingweb.it (195.128.235.47): icmp_seq=7 ttl=118 time=110 ms

```

con mtu=1500:

```

cloc3@gentoo-live ~ $ ping -s 1484 www.pippo.it

PING www.pippo.it (195.128.235.47) 1484(1512) bytes of data.

1492 bytes from pippo.consultingweb.it (195.128.235.47): icmp_seq=1 ttl=118 time=83.9 ms

1492 bytes from pippo.consultingweb.it (195.128.235.47): icmp_seq=5 ttl=118 time=80.3 ms

1492 bytes from pippo.consultingweb.it (195.128.235.47): icmp_seq=7 ttl=118 time=78.0 ms

1492 bytes from pippo.consultingweb.it (195.128.235.47): icmp_seq=8 ttl=118 time=79.4 ms

```

sembrerebbe che i valori standard siano più snelli. la prova si conferma con pacchetti più grossi, fino a 3550 byte.

eppure, con 1500 la navigazione è pressoché impossibile.

cosa altro posso guardare?

----------

## oRDeX

ma molto più semplicemente, il segnale wifi com'è?

----------

## federico

Controlla anche la scheda di rete. Io dopo aver smadonnato per mesi col samba del mio server, dove avevo in upload dal portatile verso il server samba max 100kb di banda, ho realizzato che e' la sk di rete baracca. Con un'altra tutto torna alla normalita' ... Misteri del kernel.

----------

## cloc3

 *oRDeX wrote:*   

> ma molto più semplicemente, il segnale wifi com'è?

 

molto debole.

per questo parlo di condizioni estreme.

vorrei capire, se mai è possibile, quanto si riesca a governare la situazione configurando bene i parametri di rete,

e come realizzare i test.

----------

## mrfree

Prova a disabilitare il rate automatico per la scheda wireless forzandone uno basso manualmente con 

```
iwconfig eth1 rate 5.5M
```

In passato mi è capitato che in particolari condizioni di distanza dall'AP e di traffico il driver iniziava a saltellare da un rate all'altro facendomi anche perdere l'associazione all'AP. Io la farei una prova dopo aver controllato le velocità supportate dalla tua scheda 

```
iwlist eth1 rate
```

----------

## oRDeX

Concordo con il fatto che, come suggerisce mrfree, abbassando il rate si può ottimizzare l'uso di un segnale debole..ma in condizioni estreme come questa, i pacchetti semplicemente non arrivano dall'altra parte. Stai giocando con l'MTU cercando di ottenere una situazione stocasticamente migliore, ma rimen il fatto che un tot di pacchetti dall'altra parte non ci arrivano proprio...E ripeto, con l'mtu puoi giocare fino ad un certo punto, ma non puoi risolvere la situazione (sempre che con tale operazione non inneschi malfunzionamenti di altro tipo).

Se manca il segnale c'è ben poco da fare..Prova, come ha detto mrfree ad abbassare il rate, se sei fortunato potrebbe funzionare meglio.

----------

## cloc3

 *mrfree wrote:*   

> Prova a disabilitare il rate automatico per la scheda wireless forzandone uno basso[/code]

 

nel mio caso, per navigare decentemente, è necessario ridurre sia il rate (36M o 48M) che l'mtu (proprio 100).

stranamente, però, i trasferimenti di dati dal server al client no richiedono una riduzione uguale della mtu.

mi spiego: se devo navigare su internet, devo ridurre la mtu a 100, se devo fare un semplice trasferimento dati , posso utilizzare valori di mtu più vicini ai default (l'ottimo è tra. 500 e 1000).

questa cosa proprio non la capisco.

----------

## mrfree

 *cloc3 wrote:*   

> nel mio caso, per navigare decentemente, è necessario ridurre sia il rate (36M o 48M) che l'mtu (proprio 100)

 

EEhhh!!! 36M/48M??! e lo chiami segnale debole??  :Smile: 

A questo punto escluderei che il tuo problema sia il segnale basso, forse la causa è da ricercare altrove anche in virtù dello strano comportamento legato all'mtu...

----------

