МТС, КОМСТАР-Регионы (проводной доступ в Интернет)

Могу сказать, что все зависит от Вашего ТВ-кабеля от щитка до телевизора, от качества припайки в ящике и на разветвителях в подъезде. В моем доме на Ранней, 12 все идеально показывает, что первый канал в новогоднюю ночь был четким и цветным, что Карусель. Звоните в Гранат оставляйте заявки, раз у Вас такое творится.... Но дело может быть абсолютно не в Гранате, потому что сигнал хороший идет, пусть смотрят что у Вас с сигналом, как у соседей.

Похоже, что это известная проблема, которая называется Path MTU Discovery Black Hole.
Довольно подробно описана здесь http://www.opennet.ru/base/net/pppoe_mtu.txt.html и здесь http://zooom.com.ua/linux/ustanovka-i-nast...black-hole.html.
Вообщем, видимо какой-то роутер, который стоит после pppoe-сервера(если смотреть с моей стороны) начал резать icmp-пакеты, из-за чего пакеты от web-серверов больше определенного размера, до меня не доходят.

Когда я создаю pppoe-соединение напрямую с компа, то винда ограничивает максимальный размер tcp-пакета в соответствии с mtu pppoe-соединения. Поэтому все работает.
Когда pppoe-соединение создано роутером, то винда о нем ничего не знает и создает tcp-соединение с сайтом с максимальным размером tcp-пакетов как для сети с mtu 1500. Сайт пытается слать пакеты слишком большого размера, pppoe-сервер их не пропускает и отправляет назад icmp с указанием максимального размера пакета, но их какой-то роутер по пути режет и до сайта они не доходят, и сайт продолжает слать большие пакеты. И так до бесконечности.

andrelo1
если вы выставляете на роутере меньшее, чем стандартное mtu - роутер отсылает пакеты, которые ему указаны...
у меня после установки 1400 на роутере вообще никаких проблем нет! ни на компе, ни на ноуте, ни на телефоне...

andrelo1
Винда как раз прекрасно знает, какой мту использует роутер. Он сам ей об этом сообщил. И при этом не важно, какой мту задан в винде по умолчанию. Попингуйте роутер с запретом фрагментации и сами все увидите.

Мне кажется, что с роутером что-то не то, коли без него все работает нормально.

Для виндов:
ping ya.ru -f -l <размер MTU>
Начните с 1400 и добавляйте десятками, например:
ping ya.ru -f -l 1400
ping ya.ru -f -l 1410
...
ping ya.ru -f -l 1500

Последнее значение, на котором передача проходила и будет нормальным значением MTU. При тестировании, на роутре лучше поставить большее, дабы в форточку пакетики лезли не обращая внимания на ограничения вашего роутера, а обрезаясь только на стороне провайдера.

Только целевой адрес, наверное, неправильно выбран — работа сайтов Яндекса перестала быть показателем с тех пор, как ТТ с ним запирился.

Amael, вы не правы. Но можете использовать другой адрес, дабы быть спокойным.

paulv
На роутере поставил mtu=1492, больше не дает.
Максимальный пинг, который проходит до ya.ru без фрагментации это 1462, т.е. MTU=1462+8(ICMP)+20(IP) = 1490.

Заметил еще одну странность - установка mtu на роутере почему-то ни на что не влияет. Ставлю 1100, но ping размером 1400 спокойно доходит до ya.ru. Видимо установка mtu вообще не работает.

Cybertim
По моему роутер не обязан сообщать о том какой у него mtu. Винда о нем узнает только когда попытается отправить большой пакет через роутер и он его отбросит с посылкой icmp, в котором будет содержаться mtu.

Пробовал анализировать трафик с помощью Microsoft Network Monitor.
Вот как выглядит попытка зайти на google.com:

В первых трех пакетах, в которых инициируется соединение, хосты договариваются о максимальном размере tcp-пакета. И там стоит значение 1460( MaxSegmentSize ):

Т.е. винда, когда устанавливает соединение с google.com, про значение mtu на роутере ничего не знает, а использует значение mtu для Ethernet 1500( 1460(MaxSegmentSize)+20(TCP)+20(IP) ).

В четвертом пакете посылается GET запрос размером 642 байта. После этого google.com начинает посылать ответы на запрос, но доходят только маленькие пакеты, а большие, которые больше mtu pppoe соединения (>1490) отбрасываются pppoe-сервером. При этом, по идее, pppoe-сервер должен отсылать google.com icmp с максимальным размером пакета, а google.com должен скорректировать размер отсылаемых пакетов. Но этого почему-то не происходит.

Вот так выглядит открытие сайта google.com, если провод воткнут напрямую в комп:

Тут уже винда сама создает pppoe соединение и при создании соединения с google.com устанавливает MaxSegmentSize = 1440 :

Поэтому google.com на этот раз использует tcp-пакеты размером не более 1440, соответственно они все доходят.

MTU опция в DHCP для MS не работает, совсем забыл сказать (посыпаю голову пеплом). Прискорбный баг от MS, так что поиск нужного размера фрейма нужно завершать не на роутере, а на ПК.
Ставим максимальный доступный MTU на роутере, дальнейшие махинации на ПК (для Win систем!).

andrelo1
Интересное исследование. Посмотрел Microsoft Network Monitor трафик у себя. Действительно, при установке связи с гуглом в первом фрейме имеем картину:

То есть Windows использует мту 1500. Однако в ответ гугл шлет пакеты строго согласующиеся размером с мту, выставленному на маршрутизаторе.
Максимальное значение MTU, при котором всё работает - 1490 (стандарт 1492).
Ответ гугла при таком значение на маршрутизаторе (в винде мту 1500)

При значении МТУ на маршрутизаторе 1400

Ну и для МТУ 1460 :-)

то есть все соответствует формуле MSS = MTU - 40

Повторюсь, что при этом значение мту в винде не меняется:

То есть все "толстые" фреймы пролезают и, соответственно, все устройства, включая телефон, получают данные из сети без дополнительных манипуляций.

ЗЫ Сорри, но таблички не очень красиво вставились

Это сообщение отредактировал Cybertim - 3.01.2012 - 17:55

Cybertim
andrelo1
да я гляжу вам обоим не отдыхается...

Cybertim
Вот у тебя как раз получается красивая картинка, когда хосты сначала договорились о передаче пакетов по 1460 байт, но потом google.com скорректировал размер пакета до MTU - 40, так как пакеты по 1460 не пролезали. Тут как раз сработала технология Path MTU discovery.

В моем случае это почему-то не работает. Я подозреваю, что это так называемый MTU Discovery Black Hole. Т.е. кто-то на пути до google.com режет icmp-пакеты type=3 code=4, по которым как раз google.com должен скорректировать размер отсылаемых пакетов.

Можешь скинуть результат "tracert google.com", чтобы сравнить цепочку шлюзов, через которые идет соединение с google.com ? Может так как-то можно вычислить какой шлюз в моей цепочке может резать icmp-пакеты.

Вот:

У меня такая цепочка получается:

То есть отличаются только вторым шлюзом. Если мое предположение о том что кто-то режет icmp верно, то это может быть только asr-1000-2.ttel.ru [85.158.48.30]. Хотя с другой стороны второй шлюз у меня не всегда 85.158.48.30, а меняется раз от раза. То есть он получается не один такой ?

Законектился через тот же 85.158.48.17

Проблема осталась. Видимо теория про "черную дыру" не подтверждается.
Нужно думать в другом направлении .