LINUX.ORG.RU
решено Форум — Admin  

Потери пакетов и кража интернета

 ,


0

4

Есть 2 вопроса:

1) На роутере-мыльнице (TP-Link WR741ND) откуда-то появились потери пакетов: 

root@OpenWrt:~# ifconfig eth1
eth1      Link encap:Ethernet  HWaddr F4:EC:34:B4:CA:C3  
          inet addr:176.53.224.13  Bcast:176.53.224.255  Mask:255.255.255.0
          inet6 addr: fe80::f6ec:38ff:feb3:cbc5/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:135580 errors:0 dropped:454 overruns:0 frame:0
          TX packets:73498 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:174144509 (166.0 MiB)  TX bytes:7958816 (7.5 MiB)
          Interrupt:4
Значение dropped невелико по сравнению с общим количеством пакетов, но растет на глазах (уже 458). Что вообще значит это поле? Роутер испытывался с 3 провайдерами, 2 использовали IPoE и с ними был ненулевой dropped, третий использовал кабельный мопед, там dropped был по нулям. Судя по top'у, роутер практически не нагружен, при скачивании чего-нибудь из Сети это поле растет примерно с той же скоростью, что и при простое, при подключении кабеля напрямую к десктопу dropped равно нулю. Кто-нибудь встречался с подобным?

2) ARP-таблица на том же роутере выглядит следующим образом: 

IP address       HW type     Flags       HW address            Mask     Device
192.168.1.100    0x1         0x2         00:1e:8c:d3:26:b2     *        br-lan
176.53.224.1     0x1         0x2         00:12:44:db:2b:c0     *        eth1
176.53.224.254   0x1         0x2         00:16:17:35:6f:c5     *        eth1
В качестве default gateway используется 176.53.224.1, при этом, судя по трейсроуту, все данные к 176.53.224.254 идут напрямую, в обход гейта (т.е. один хоп). Более того, пинг до .254 идет намного быстрее, в среднем 0.6 ms, а до .1 идет 1.8 ms. Пробовал смотреть в Wireshark - там вообще непонятная фигня, например, ответы DHCP идут сразу и с .1, и с .254. Ещё странности - сделаем arping до провайдерского DNS-сервера: 
arping -I eth1 176.53.209.209
ARPING to 176.53.209.209 from 176.53.224.13 via eth1
Unicast reply from 176.53.209.209 [0:16:17:35:6f:c5] 0.584ms
Unicast reply from 176.53.209.209 [0:12:44:db:2b:c0] 1.551ms
Unicast reply from 176.53.209.209 [0:12:44:db:2b:c0] 1.739ms
Unicast reply from 176.53.209.209 [0:12:44:db:2b:c0] 28.945ms
Unicast reply from 176.53.209.209 [0:12:44:db:2b:c0] 1.678ms
Мак-адрес из первого ответа - это .254, а из второго и последующих - это .1. Ну я сначала плюнул, т.к. не сильно разбираюсь как устроены провайдерские сети, может это нормально. Но сегодня просканировал порты на 176.53.224.1: 
Not shown: 997 closed ports
PORT    STATE    SERVICE      VERSION
135/tcp filtered msrpc
139/tcp filtered netbios-ssn
445/tcp filtered microsoft-ds
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Aggressive OS guesses: OpenBSD 3.5 (97%), OpenBSD 3.9 (97%), OpenBSD 4.4 (97%), HP Photosmart 8400 printer (97%), OpenBSD 4.0 (x86) (97%), HP LaserJet P1606dn printer (97%), Cisco 1700-series router (97%), Cisco 2950 switch (IOS 12.1) (97%), Cisco Catalyst Express 500 switch (IOS 12.2) (97%), OpenBSD 3.8 - 4.6 (97%)
No exact OS matches for host (test conditions non-ideal).
Откуда на промежуточной сетевой железяке smb-сервер? По поводу определения ОС nmap сам написал, что всё это по факту от балды. Возникли подозрения, что у меня тырят интернет. Насколько такое возможно? Никаких VPN не используется.

★★★★
← Firmware Bug
mount file exclude →

00:12:44:xxxxxx это cisco, если конечно никто не менял специально.
Частенько в домосетях небольшие провайдеры держат файлопомойки открытые всем пользователям.

bass ★★★★★
()
Последнее исправление: bass (всего исправлений: 1)
Ответ на: комментарий от bass

Ага, понятно. Но 00:16:17 - это Msi, лично я никогда не слышал, чтобы они производили какое-то сетевое оборудование.

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

это может быть wifi ретранслятор, например из MSI RG60.
В любом случае, для успокоения паранойи звони провайдеру с требованием наладить качество связи, заодно требуй предоставить всю схему твоей «последней мили».

bass ★★★★★
()
Последнее исправление: bass (всего исправлений: 1)
Ответ на: комментарий от bass

с требованием наладить качество связи

Хм, а что это даст? Думаю, что у них там таких требований по поводу качества связи за день набирается несколько десятков в лучшем случае, не будут же они так подробно копаться для каждого такого требования, тем более у меня нет каких-либо объективных причин, только догадки.

h31 ★★★★
() автор топика
Последнее исправление: h31 (всего исправлений: 2)
Ответ на: комментарий от h31

Главное, заверить хелп-деск что ты уже перезагрузился сам, перезагрузил всё оборудование в квартире и готов писать письмо начальнику. Тогда ты попадёшь на специалиста, а на любого вменяемого системного администратора слова: у меня ошибки на интерфейсе, действуют положительно, он начинает проверять.

bass ★★★★★
()

Откуда на промежуточной сетевой железяке smb-сервер?

Откуда вообще вы решили что там есть smb? State filtered какбы намекает что при попытке коннекта nmap получил icmp ответ о недоступности порта. И в 99% это произошло потому что вменяемые провайдеры фильтруют все что похоже на smb.

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

а на любого вменяемого системного администратора слова: у меня ошибки на интерфейсе, действуют положительно, он начинает проверять.

У ТС нет ошибок, у него dropped. Если ядро не знает что делать с пакетом, оно инкрементирует счетчик и дропает его. В новых ядрах достаточно чтобы на интерфейс попал тегированый фрейм, с вланом который на интерфейсе не настроен чтобы фрейм засчитался как dropped.

ventilator ★★★
()

ответы DHCP идут сразу и с .1, и с .254. Ещё странности - сделаем arping до провайдерского DNS-сервера

Это вероятно потому ваш провайдер резервирует роутер который смотрит в вашу сеть и использует vrrp или его аналог.

Возникли подозрения, что у меня тырят интернет.

Интересно прочитать логическую цепочку которая привела вас к этой идее. Если не считать случай «много непонятного происходит, меня явно обманывают».

Не совсем понятно есть ли у вас какая то проблема со связью, окромя того что dropped!=0

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

В новых ядрах достаточно чтобы на интерфейс попал тегированый фрейм

О, интересная идея. Завтра ещё раз посмотрю на десктопе, что он там присылает.
Кстати, а примерно с какой версии ядра это происходит?

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

В любом случае, для успокоения паранойи звони провайдеру с требованием наладить качество связи, заодно требуй предоставить всю схему твоей «последней мили».

После этого саппорт напротив такого пользователя напишет нелестный комментарий. И когда придется звонить о реальной проблеме саппорт будет сразу считать абонента неадекватным.

А требование схем, это даже любопытно услышать ответ.

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

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

[18291.920842] UDP: bad checksum. From yy.yy.yy.yy:53871 to xx.xx.xx.xx:1066 ulen 1437

PS: Я не вижу в ваших выкладках никаких аномальных симптомов.

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

Это вероятно потому ваш провайдер резервирует роутер который смотрит в вашу сеть и использует vrrp или его аналог.

Не совсем понял, можно подробнее?

«много непонятного происходит, меня явно обманывают»

Да, что-то типа такого. Довольно необычная схема, хотя провайдер небольшой (pulnet.ru), может не домовой в исходном смысле этого слова, но максимум районный.
Объективных проблем нет.

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

Посмотрел в сниффере - не заметил ни фреймов с прописанным vlan-ом, ни битых пакетов. Ну и ладно, если в дропнутых пакетах ничего полезного нет, то и фиг с ними.
Просто был неприятный опыт, когда реально пакеты терялись, а достичь тарифной скорости можно было только через торренты или многопоточные качалки с большим кол-вом потоков (видимо, TCP не мог разогнаться) - бодался с саппортом месяц наверное, в конце концов исправили.
Спасибо большое за советы!

h31 ★★★★
() автор топика
Последнее исправление: h31 (всего исправлений: 2)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Firmware Bug
Admin
mount file exclude →