LINUX.ORG.RU
Форум — Admin  

Frag needed and DF set (mtu = 1492) и mtu

 , ,


0

1

Что-то я туплю.
Есть такая сеть:

{PC}----wifi----{ROU1}----lan----{ROU2}----wifi----{ROU3}----ppp---INET

PC - ноут с которого сейчас пишу. Получает ip от ROU1 по dhcp. mtu 1500.
ROU1 соединен с ROU2 по lan. mtu 1500
ROU2 с ROU3 через wifi. mtu 1500.
У ROU1 к PC и ROU2 IP 192.168.3.1
У ROU2 к ROU1 IP 192.168.3.2
У ROU3 к ROU2 192.168.1.1
ppp mtu на ROU3 (adsl модем) 1492.
На ROU2 в iptables строчка в mangle присутствует
-A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

В итоге, если я пингую с PC или с ROU2 - ROU3 (192.168.1.1)
видим вот что:
hbars@hbars-book:~$ ping 192.168.1.1 -s 5000
PING 192.168.1.1 (192.168.1.1) 5000(5028) bytes of data.
5008 bytes from 192.168.1.1: icmp_seq=1 ttl=63 time=23.4 ms
5008 bytes from 192.168.1.1: icmp_seq=2 ttl=63 time=30.3 ms
5008 bytes from 192.168.1.1: icmp_seq=3 ttl=63 time=35.1 ms

Все ок.
Если пробую что-то за pppoe
hbars@hbars-book:~$ ping ya.ru -s 1464
PING ya.ru (93.158.134.3) 1464(1492) bytes of data.
                               ^^^^ mtu на ppp
1472 bytes from www.yandex.ru (93.158.134.3): icmp_seq=1 ttl=53 time=84.3 ms
1472 bytes from www.yandex.ru (93.158.134.3): icmp_seq=2 ttl=53 time=85.5 ms
1472 bytes from www.yandex.ru (93.158.134.3): icmp_seq=3 ttl=53 time=86.8 ms

Влазим в mtu.
и
hbars@hbars-book:~$ ping ya.ru -s 1467
PING ya.ru (213.180.193.3) 1467(1495) bytes of data.
From 100.64.44.84 (100.64.44.84) icmp_seq=1 Frag needed and DF set (mtu = 1492)

И ничего не пролазит.
Если пинговать с ROU2 - тоже самое.
Косяк у меня или у провайдера.
icmp разрешены.
-A INPUT -p icmp -m limit --limit 2/second -j ACCEPT
-A FORWARD -p icmp -j ACCEPT

Как решить?

★★★★★

ppp отусывает от твоего mtu на служебные заголовки. Надо на ROU3 просто увеличить в клиентской части размер mtu с учетом длины заголовков ppp (не помню точно размер).

bigov ★
()
Ответ на: комментарий от bigov

1492 - это предельный размер IP-пакета поверх PPPoE, которое жрет 6 байт на PPPoE-заголовок и 2 байта на PPP_IP, чтобы уместится в стандартный кадр 1500 байт. ТС ничего делать не надо, твой ROU3 делает все, как ты хочешь.

whoami ★
()
Ответ на: комментарий от whoami

И что он (ROU3) делает? Не пропускает пакеты больше 1492.
Ведь до его wifi интерфейса все нормально.

hbars ★★★★★
() автор топика
Ответ на: комментарий от hbars

речь идет о структуре TCP/IP пакета. mtu - длина пакета. Максимальный размер Ethernet-пакета составляет 1500 байт, а максимальный размер пакета, передаваемого через PPPoE, составляет 1492 байта. Заголовок PPPoE занимает 6 байт, а PPP Protocol ID 2 байта. Таким образом, ppp изменяет длину твоих пакетов, добавляя в них свою служебную информацию, которая дальше сервера провайдера не передается.

Как изменить размер MTU в ADSL/ppp маршрутизаторе зависит от твоей железки. Обычно через веб-мрду.

bigov ★
()
Ответ на: комментарий от bigov

А что та менять. У ppp стоит 1492.
Почему не работает фрагментация?
Что можно сделать на ROU2?
mtu на wifi уменьшал, в iptables --set-mss 1300 пробовал разные.
Эффект - 0.
ROU3 - обычный huawei HG532e. Там особо и крутить нечего.
Доступ к нему только через вэбморду.

hbars ★★★★★
() автор топика
Ответ на: комментарий от Michael89

На ROU2 что-то можно сделать чтобы это обойти?

hbars ★★★★★
() автор топика

a tracepath что показывает ?

100.64.44.84 - это кто ? То, что от него приходит icmp - это хорошо, значит tcp будет работать.

Для теста можно на PC сделать MTU для DGW 1492

ip ro add default via .... mtu 1492 advmss 1440

vel ★★★★★
()
Ответ на: комментарий от hbars

все наоборот - в настройках клиентской части ppp на ROU3 выбери ручную установку mtu = 1450. И будет тебе счастье :)

bigov ★
()
Ответ на: комментарий от bigov

Ну и что.

pi@wifi-router:~ $ ping 100.66.0.1  -s 1465
PING 100.66.0.1 (100.66.0.1) 1465(1493) bytes of data.
From 100.65.34.169 icmp_seq=1 Frag needed and DF set (mtu = 1450)
^C
--- 100.66.0.1 ping statistics ---
3 packets transmitted, 0 received, +1 errors, 100% packet loss, time 2007ms

100.66.0.1 шлюз провайдера
100.65.34.169 ip ppp на ROU3
Здесь все описал проще.

hbars ★★★★★
() автор топика
Ответ на: комментарий от hbars

«ping -M dont -s 1467 ya.ru» работает ?

я вижу только одну проблему - если провайдер или сам ROU3 блокирует icmp(3,4) от тебя, то тогда есть проблема и нужно всему, что форвардится иметь размер пакетов < 1492, а в tcp говорить, что mss хочу 1492-60 (-j TCPMSS --set-mss 1432)

Ситуацию можно легко проверить на линуксячем клиенте указав в параметрах маршрута по-умолчанию mtu и advmss.

vel ★★★★★
()
Ответ на: комментарий от vel

Все по-порядку.
Смотрим с ROU2 пинг на adsl модем (ROU3)

root@wifi-router:/var/log# ping 192.168.1.1 -s 3000
PING 192.168.1.1 (192.168.1.1) 3000(3028) bytes of data.
3008 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=82.8 ms
3008 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=39.0 ms
^C
--- 192.168.1.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 39.030/60.956/82.883/21.927 ms

Все ок. Для интереса пропингую человека который висит там на wifi.
root@wifi-router:/var/log# ping 192.168.1.3 -s 3000
PING 192.168.1.3 (192.168.1.3) 3000(3028) bytes of data.
3008 bytes from 192.168.1.3: icmp_seq=1 ttl=64 time=16.9 ms
3008 bytes from 192.168.1.3: icmp_seq=2 ttl=64 time=20.8 ms
3008 bytes from 192.168.1.3: icmp_seq=3 ttl=64 time=116 ms
^C
--- 192.168.1.3 ping statistics ---
4 packets transmitted, 3 received, 25% packet loss, time 3002ms
rtt min/avg/max/mdev = 16.939/51.433/116.554/46.074 ms

Тоже все ок.
Теперь его ip на ppp.
root@wifi-router:/var/log# ping 100.67.186.23 -s 3000
PING 100.67.186.23 (100.67.186.23) 3000(3028) bytes of data.
3008 bytes from 100.67.186.23: icmp_seq=1 ttl=64 time=17.6 ms
3008 bytes from 100.67.186.23: icmp_seq=2 ttl=64 time=13.2 ms
3008 bytes from 100.67.186.23: icmp_seq=3 ttl=64 time=13.2 ms

Ну и шлюз провайдера.
root@wifi-router:/var/log# ping 100.67.0.1 -s 3000
PING 100.67.0.1 (100.67.0.1) 3000(3028) bytes of data.
^C
--- 100.67.0.1 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2005ms

Все. Пакетами что влазят в mtu pppoe все нормально.
root@wifi-router:/var/log# ping 100.67.0.1 -s 1464
PING 100.67.0.1 (100.67.0.1) 1464(1492) bytes of data.
1472 bytes from 100.67.0.1: icmp_seq=1 ttl=249 time=75.7 ms
1472 bytes from 100.67.0.1: icmp_seq=2 ttl=249 time=69.5 ms
1472 bytes from 100.67.0.1: icmp_seq=3 ttl=249 time=67.6 ms
1472 bytes from 100.67.0.1: icmp_seq=4 ttl=249 time=64.1 ms

Делаю на ROU2
root@wifi-router:/var/log# ip ro sh
default via 192.168.1.1 dev wlan0 
192.168.1.0/24 dev wlan0  proto kernel  scope link  src 192.168.1.10 
192.168.3.0/24 dev eth0  proto kernel  scope link  src 192.168.3.2 
root@wifi-router:/var/log# ip ro del default
root@wifi-router:/var/log# ip ro add default via 192.168.1.1 mtu 1492
root@wifi-router:/var/log# ip ro sh
default via 192.168.1.1 dev wlan0  mtu 1492
192.168.1.0/24 dev wlan0  proto kernel  scope link  src 192.168.1.10 
192.168.3.0/24 dev eth0  proto kernel  scope link  src 192.168.3.2
В mangle:
-A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1432

Смотрим:
root@wifi-router:/etc/network/if-up.d# ping 100.67.0.1 -s 3000
PING 100.67.0.1 (100.67.0.1) 3000(3028) bytes of data.
^C
--- 100.67.0.1 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2005ms

root@wifi-router:/etc/network/if-up.d# ping 100.67.0.1 -s 1464
PING 100.67.0.1 (100.67.0.1) 1464(1492) bytes of data.
1472 bytes from 100.67.0.1: icmp_seq=1 ttl=249 time=67.0 ms
1472 bytes from 100.67.0.1: icmp_seq=2 ttl=249 time=70.3 ms
^C
--- 100.67.0.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 67.066/68.689/70.313/1.644 ms

Увы.
Где еще покрутить?
ps: --set-mss делал и меньше. Та же фигня.

hbars ★★★★★
() автор топика
Ответ на: комментарий от hbars

TCPMSS влияет только на размер фрейма TCP, и больше ни на что. ICMP вообще не затрагивается им.
Нужно искать где в ROU3 отключается фрагментация.
Хотя, фрагментация - зло и лучше в современном Интернете ее избегать.

whoami ★
()
Ответ на: комментарий от vel

Да. C tcp вроде все в порядке.

hbars ★★★★★
() автор топика
Ответ на: комментарий от vel

Вероятно что именно так. Потому как затык именно на их шлюзе pppoe.
Просто думал что можно как-то обойти на ROU2.

hbars ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Admin