Странные глюки сети

Понятно что с сетью и роутером все в порядке, раз смартфон все открывает. С компьютера на котором сайты не открываются пинги|(telnet|nslookup) ходят до этих сайтов? Каков путь пакетов в интернет прокси\днс сервер\VPN\блокировщики рекламы используются? Локализуйте проблему.

С компьютера на котором сайты не открываются пинги|(telnet|nslookup) ходят до этих сайтов?

щито?

48	13.071910	91.208.42.67	192.168.0.101	TCP	74	http > 44527 [SYN, ACK] Seq=1499936258 Ack=1 Win=65535 Len=0 MSS=1260 WS=512 SACK_PERM=1 TSval=985812656 TSecr=34931948

Если бы оно не возникало перодически, я бы сказал что пакеты по MTU не выравниваются где-то. Похожие проявления - жесткие потери пакетов до некоторых сайтов.

пинги|(telnet|nslookup) ходят до этих сайтов?

пингует как-то странно. Пингую ixbt.com - 100% loss, в браузерах не открывается. Пингую habrahabr.ru - все пакеты доходят, но в браузере не открывается. И визуально между пакетами интервал секунд 5, а пишет около 50 ms. ЛОР стабильно пингуется без потерь, интервалы около 1 секунды как и должно быть, time=30 ms.

telnet пробовал на ixbt.com, не цепляется. С ДНС проблем точно нет

прокси\днс сервер\VPN\блокировщики рекламы используются?

проксей нет, есть PPTP до провайдера, поднято на роутере. Блокировщиков никаких нет, iptables не трогал

Локализуйте проблему.

да уж вторую неделю пытаюсь :)

была такая мысль. ifconfig говорит MTU:1500 на eth0. На роутере 1420 для PPTP (это максимум и он же дефолт)

Попробуй что-нибудь поменьше на eth0, хуже не станет :)

Если не взлетит - нужно будет поднимать проблемы текущей железки и драйвера (в т.ч. и сторонних модулей, которые на сети завязаны). Всякие хуавей-модемы и циско-впн умудряются вешать интферфейс только самим фактом своего существования.

попробовал 1200, толку ноль

< С ДНС проблем точно нет

я, конечно, нуб тот ещё, но откуда такая уверенность? а что у вас в resolv.conf прописано? а может быть у Вас какой-нибудь глючный локальный dnsmasq? или ещё лучше - сквид, который прицепил себе свои днс-сервера и теперь говорит браузеру, что «не, ничо не знаю, ничего не работает!».

да. лог не смотрел, а всё вышесказанное - моя больная фантазия.

Всякие хуавей-модемы

кстати год назад был именно хуавей-модем, работал как часы :)

Скинь лог после:

echo 0 > /proc/sys/net/ipv4/tcp_window_scaling

я, конечно, нуб тот ещё, но откуда такая уверенность?

эмм... как бы через wget отлично видно, что адреса резолвятся быстро и правильно

а может быть у Вас какой-нибудь глючный локальный dnsmasq?

у меня неглючный pdnsd. Выключать пробовал, да. Проксей никаких нет.

Скинь лог

который из?

кстати год назад был именно хуавей-модем, работал как часы :)

Ну, меня тоже миновало. Разве что ядро из транка оно вешало намертво. В целом железки хорошие, но всякое бывает )

который из?

Тьфуэ, дамп пакетов то есть

что видно в
ip -s -s l s dev eth0?

http://dl.dropbox.com/u/998228/LOR/wireshark-network-fail2

то же самое в принципе

ничего не выводит

sudo ip -s -s l

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 3000
    link/ether 00:1f:d0:35:23:7c brd ff:ff:ff:ff:ff:ff
    RX: bytes  packets  errors  dropped overrun mcast   
    3397786697 25222611 0       0       0       0      
    RX errors: length  crc     frame   fifo    missed
               0        0       0       0       0      
    TX: bytes  packets  errors  dropped carrier collsns 
    2346197896 30175254 0       0       0       0      
    TX errors: aborted fifo    window  heartbeat
               0        0       0       0 

мм...это wifi интерфейс на компутере? на рутере есть возможность посмотреть ошибки на интерфейсах?

нет, до компа витуха, вафля только для смартфона.

на рутере есть возможность посмотреть ошибки на интерфейсах?

есть куцый сислог, возможность сделать ping/traceroute и еще можно включить статистику. Но вроде как ошибки в статистике не видно, только трафик

Я бы подумал, что проблема на стороне рутера, у меня и то не такая хорошая статистика по ошибкам, но работает всё нормально...
Вперёд - к приключениям с новыми альтернативными прошивками

Я бы подумал, что проблема на стороне рутера,

как бы этому противоречат пункты 1 и 4. Но исключать тоже нельзя

Вперёд - к приключениям с новыми альтернативными прошивками

на мой унылый tp-link альтернативных прошивок в природе нет :)

Так, что-то я загнался насчёт MTU и window scaling.

Ты отправляешь SYN, тебе приходит хороший SYN-ACK, ты на него в ответ шлёшь RST. Зачем так делаешь?

Если считать реализацию tcp/ip в линуксе хорошей, а драйвер железки не обращающим на эти уровни внимания, возможны варианты:

1) Файрвол (локальный) или чего ещё похуже портит пакеты по дороге на интерфейс-обратно.

2) SYN-ACK приходит всё-таки кривой, только мы этого не заметили.

Зачем так делаешь?

без понятия. Запрос посылал wget'ом. В браузерах та же хрень

Файрвол (локальный) или чего ещё похуже

iptables девственно чист, на роутере файрвол и прочие приблуды выключены

кстати вот дамп для успешного соединение (тогда кабель втыкал напрямую, без роутера)

https://dl.dropbox.com/u/998228/LOR/wireshark - ixbt - normal

Меня еще смущает пакет номер 5, что-то в нем sequence number странно большой

iptables -t mangle -o PPTP_IFACE --insert FORWARD 1 -p tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:65495 -j TCPMSS --clamp-mss-to-pmtu

Мыльницы по дефолту выравнивают пакеты, не?

В dmesg случаем не сыпятся ошибки?

и что это значит?

нет, в логах чисто

судя по дампам, его мыльница - нет.

и что это значит?

это ответ на твой вопрос.
А это значит в правильной терминологии: google -> clamp-mss-to-pmtu

я так понимаю, это нужно на роутере прописать или на компе тоже сработает?

Судя по всему, ничем не закончилось?

пока ничем, я тогда ребут сделал. Как проявится в следующий раз - пошаманю с mtu на интерфейсе и iptables.

По идее, с mtu на роутере шаманить нужно. Но если понижение его на компе не помогает - скорее всего дело не в нём. Я в таких лучаях начинаю менять-смотреть всё что под руку попадётся :)

моя мыльница дает менять mtu только для pptp :(

сегодня баг вылез опять и я его таки победил после двух часов плясок :)

Дело было не в MTU - шаманил и с iptables разными способами, и на интерфейсе принудительно выставлял, толку нет. Потом заметил, что в ответе серверов, к которым нельзя подключиться, поломаны timestamp'ы. А в случаях успешного подключения они были в порядке. Ну и ведро естественно возмущалось такому безобразию и отсылало RST. Починилось банально:

net.ipv4.tcp_timestamps = 0

Было бы еще интересно выяснить, почему пакеты приходят с кривым временем в поле tsecr (точнее с устаревшим, как будто их почтой России доставляли). То ли провайдеры чего намутили, то ли в дебиане чего-то поменялось и ядро стало так болезненно реагировать на ломанный tsecr...

Какая-то фигня. Типа, если на клиенте и сервере стоит разное время - пакеты ходить не будут?

не, метки времени в пакетах могут отсчитываться не по системному времени. в ответе сервера есть две метки времени: самого сервера и последняя полученная. вот вторая ко мне приходила кривая.