LINUX.ORG.RU

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

 , ,


0

1

Симптомы следующие. После нескольких дней аптайма перестают открываться некоторые сайты, от браузера не зависит. Причем с самими сайтами все в порядке, со смартфона через вафлю открываются отлично (вафлю раздает тот же роутер).

После танцев с бубном выяснил:
1) ребут роутера (tp-link tl-wr340gd) не помогает. В самом роутере кроме необходимого ничего особо не настраивал, разве что пару портов пробросил да жестко привязал комп к ip-адресу. Прошивка заводская;

2) перетыкание кабелей и замена патчкорда не помогает;

3) программный перезапуск сети (ifdown/ifup) не помогает;

4) помогает перезагрузка ОС.

5) помогает втыкание кабеля напрямую в комп (хотя не уверен, может со временем глюк проявится).

ОС - Debian testing x86. Вот пример дампа wireshark, когда глюк проявляется: http://dl.dropbox.com/u/998228/LOR/wireshark-network-fail

★★★★★

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

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

С компьютера на котором сайты не открываются пинги|(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
melkor217 ★★★★★
()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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
nu11 ★★★★★
() автор топика
Ответ на: комментарий от zolden

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

net.ipv4.tcp_timestamps = 0

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

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

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

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