Имеем FreeBSD 5.2.1 + MPD 3.15 + Windows XP Pro + SP1. Соединение устанавливается но теряется половина пакетов с винды.На винде выглядит это так:
C:\Program Files\Far>ping -n 8 10.128.0.1
Обмен пакетами с 10.128.0.1 по 32 байт:
Ответ от 10.128.0.1: число байт=32 время<1мс TTL=64
Превышен интервал ожидания для запроса.
Ответ от 10.128.0.1: число байт=32 время=1мс TTL=64
Превышен интервал ожидания для запроса.
Ответ от 10.128.0.1: число байт=32 время<1мс TTL=64
Превышен интервал ожидания для запроса.
Ответ от 10.128.0.1: число байт=32 время<1мс TTL=64
Превышен интервал ожидания для запроса.Статистика Ping для 10.128.0.1:
Пакетов: отправлено = 8, получено = 4, потеряно = 4 (50% потерь),
Приблизительное время приема-передачи в мс:
Минимальное = 0мсек, Максимальное = 1 мсек, Среднее = 0 мсекНа фре так:
zv [13:19:01] /usr/local/etc/mpd# tcpdump -ni ng0
tcpdump: listening on ng0
13:19:33.980296 10.128.1.2 > 10.128.0.1: icmp: echo request
13:19:33.980331 10.128.0.1 > 10.128.1.2: icmp: echo reply
13:19:34.980212 10.128.1.2 > 10.128.0.1: icmp: echo request
13:19:34.980247 10.128.0.1 > 10.128.1.2: icmp: echo reply
13:19:40.127817 10.128.1.2 > 10.128.0.1: icmp: echo request
13:19:40.127852 10.128.0.1 > 10.128.1.2: icmp: echo reply
13:19:41.128028 10.128.1.2 > 10.128.0.1: icmp: echo request
13:19:41.128063 10.128.0.1 > 10.128.1.2: icmp: echo reply
13:19:46.134401 10.128.1.2 > 10.128.0.1: icmp: echo request
13:19:46.134437 10.128.0.1 > 10.128.1.2: icmp: echo reply
13:19:47.135750 10.128.1.2 > 10.128.0.1: icmp: echo request
13:19:47.135794 10.128.0.1 > 10.128.1.2: icmp: echo reply
13:19:52.142197 10.128.1.2 > 10.128.0.1: icmp: echo request
13:19:52.142233 10.128.0.1 > 10.128.1.2: icmp: echo reply
13:19:53.143471 10.128.1.2 > 10.128.0.1: icmp: echo request
13:19:53.143506 10.128.0.1 > 10.128.1.2: icmp: echo reply
^C
16 packets received by filter
0 packets dropped by kernelЕсли пинговать в обратную сторону, то все ок:
zv [13:33:24] /usr/ports/net/mpd# ping -c 8 10.128.1.2
PING 10.128.1.2 (10.128.1.2): 56 data bytes
64 bytes from 10.128.1.2: icmp_seq=0 ttl=128 time=12.817 ms
64 bytes from 10.128.1.2: icmp_seq=1 ttl=128 time=0.611 ms
64 bytes from 10.128.1.2: icmp_seq=2 ttl=128 time=0.614 ms
64 bytes from 10.128.1.2: icmp_seq=3 ttl=128 time=0.606 ms
64 bytes from 10.128.1.2: icmp_seq=4 ttl=128 time=0.856 ms
64 bytes from 10.128.1.2: icmp_seq=5 ttl=128 time=0.561 ms
64 bytes from 10.128.1.2: icmp_seq=6 ttl=128 time=0.559 ms
64 bytes from 10.128.1.2: icmp_seq=7 ttl=128 time=0.631 ms--- 10.128.1.2 ping statistics ---
8 packets transmitted, 8 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.559/2.157/12.817/4.030 msЧто это может быть и в какую сторону ковырять?
Возможно проблема с mpd. Кто нибудь с этим сталкивался?
Пакетов теряется не всегда половина. Вот еще информация:E:\Downloads>ping -n 8 10.128.0.1
Обмен пакетами с 10.128.0.1 по 32 байт:
Ответ от 10.128.0.1: число байт=32 время=1мс TTL=64
Ответ от 10.128.0.1: число байт=32 время<1мс TTL=64
Превышен интервал ожидания для запроса.
Ответ от 10.128.0.1: число байт=32 время<1мс TTL=64
Превышен интервал ожидания для запроса.
Ответ от 10.128.0.1: число байт=32 время<1мс TTL=64
Превышен интервал ожидания для запроса.
Ответ от 10.128.0.1: число байт=32 время<1мс TTL=64Статистика Ping для 10.128.0.1:
Пакетов: отправлено = 8, получено = 5, потеряно = 3 (37% потерь),
Приблизительное время приема-передачи в мс:
Минимальное = 0мсек, Максимальное = 1 мсек, Среднее = 0 мсекА вот так выглядит tcpdump на виндовой машине:
C:\Program Files\Far>windump -nqi1 not port 22
C:\WINDOWS\windump.EXE: listening on \Device\NPF_{4C436E2C-D027-4C14-A619-4C4555964FA8}
13:55:37.111834 IP 10.99.99.254 > 10.99.99.99: gre [KSv1] ID:c9c8 S:616 ppp: COMP 65:
13:55:37.112659 IP 10.99.99.99 > 10.99.99.254: gre [KSAv1] ID:8000 S:94 A:616 ppp: COMP 64:
13:55:38.110499 IP 10.99.99.254 > 10.99.99.99: gre [KSv1] ID:c9c8 S:617 ppp: COMP 65:
13:55:38.110847 IP 10.99.99.99 > 10.99.99.254: gre [KSAv1] ID:8000 S:95 A:617 ppp: COMP 64:
13:55:39.112230 IP 10.99.99.254 > 10.99.99.99: gre [KSv1] ID:c9c8 S:618 ppp: COMP 65:
13:55:39.606260 IP 10.99.99.99 > 10.99.99.254: gre [KAv1] ID:8000 A:618 ppp
13:55:44.549760 IP 10.99.99.254 > 10.99.99.99: gre [KSv1] ID:c9c8 S:619 ppp: COMP 65:
13:55:44.550138 IP 10.99.99.99 > 10.99.99.254: gre [KSAv1] ID:8000 S:96 A:619 ppp: COMP 64:
13:55:45.551203 IP 10.99.99.254 > 10.99.99.99: gre [KSv1] ID:c9c8 S:620 ppp: COMP 65:
13:55:46.047312 IP 10.99.99.99 > 10.99.99.254: gre [KAv1] ID:8000 A:620 ppp
13:55:50.558403 IP 10.99.99.254 > 10.99.99.99: gre [KSv1] ID:c9c8 S:621 ppp: COMP 65:
13:55:50.558831 IP 10.99.99.99 > 10.99.99.254: gre [KSAv1] ID:8000 S:97 A:621 ppp: COMP 64:
13:55:51.559838 IP 10.99.99.254 > 10.99.99.99: gre [KSv1] ID:c9c8 S:622 ppp: COMP 65:
13:55:52.058213 IP 10.99.99.99 > 10.99.99.254: gre [KAv1] ID:8000 A:622 ppp
13:55:56.567040 IP 10.99.99.254 > 10.99.99.99: gre [KSv1] ID:c9c8 S:623 ppp: COMP 65:
13:55:56.567441 IP 10.99.99.99 > 10.99.99.254: gre [KSAv1] ID:8000 S:98 A:623 ppp: COMP 64:16 packets received by filter
0 packets dropped by kernel
>Возможно проблема с mpd. Кто нибудь с этим сталкивался?
>Пакетов теряется не всегда половина. Вот еще информация:
>
>E:\Downloads>ping -n 8 10.128.0.1
>
>Обмен пакетами с 10.128.0.1 по 32 байт:
>
>Ответ от 10.128.0.1: число байт=32 время=1мс TTL=64
>Ответ от 10.128.0.1: число байт=32 время<1мс TTL=64
>Превышен интервал ожидания для запроса.
>Ответ от 10.128.0.1: число байт=32 время<1мс TTL=64
>Превышен интервал ожидания для запроса.
>Ответ от 10.128.0.1: число байт=32 время<1мс TTL=64
>Превышен интервал ожидания для запроса.
>Ответ от 10.128.0.1: число байт=32 время<1мс TTL=64
>
>Статистика Ping для 10.128.0.1:
> Пакетов: отправлено = 8, получено = 5, потеряно
>= 3 (37% потерь),
>Приблизительное время приема-передачи в мс:
> Минимальное = 0мсек, Максимальное = 1 мсек, Среднее
>= 0 мсек
>
>А вот так выглядит tcpdump на виндовой машине:
>
>C:\Program Files\Far>windump -nqi1 not port 22
>C:\WINDOWS\windump.EXE: listening on \Device\NPF_{4C436E2C-D027-4C14-A619-4C4555964FA8}
>13:55:37.111834 IP 10.99.99.254 > 10.99.99.99: gre [KSv1] ID:c9c8 S:616 ppp: COMP 65:
>13:55:37.112659 IP 10.99.99.99 > 10.99.99.254: gre [KSAv1] ID:8000 S:94 A:616 ppp: COMP 64:
>13:55:38.110499 IP 10.99.99.254 > 10.99.99.99: gre [KSv1] ID:c9c8 S:617 ppp: COMP 65:
>13:55:38.110847 IP 10.99.99.99 > 10.99.99.254: gre [KSAv1] ID:8000 S:95 A:617 ppp: COMP 64:
>13:55:39.112230 IP 10.99.99.254 > 10.99.99.99: gre [KSv1] ID:c9c8 S:618 ppp: COMP 65:
>13:55:39.606260 IP 10.99.99.99 > 10.99.99.254: gre [KAv1] ID:8000 A:618 ppp
>13:55:44.549760 IP 10.99.99.254 > 10.99.99.99: gre [KSv1] ID:c9c8 S:619 ppp: COMP 65:
>13:55:44.550138 IP 10.99.99.99 > 10.99.99.254: gre [KSAv1] ID:8000 S:96 A:619 ppp: COMP 64:
>13:55:45.551203 IP 10.99.99.254 > 10.99.99.99: gre [KSv1] ID:c9c8 S:620 ppp: COMP 65:
>13:55:46.047312 IP 10.99.99.99 > 10.99.99.254: gre [KAv1] ID:8000 A:620 ppp
>13:55:50.558403 IP 10.99.99.254 > 10.99.99.99: gre [KSv1] ID:c9c8 S:621 ppp: COMP 65:
>13:55:50.558831 IP 10.99.99.99 > 10.99.99.254: gre [KSAv1] ID:8000 S:97 A:621 ppp: COMP 64:
>13:55:51.559838 IP 10.99.99.254 > 10.99.99.99: gre [KSv1] ID:c9c8 S:622 ppp: COMP 65:
>13:55:52.058213 IP 10.99.99.99 > 10.99.99.254: gre [KAv1] ID:8000 A:622 ppp
>13:55:56.567040 IP 10.99.99.254 > 10.99.99.99: gre [KSv1] ID:c9c8 S:623 ppp: COMP 65:
>13:55:56.567441 IP 10.99.99.99 > 10.99.99.254: gre [KSAv1] ID:8000 S:98 A:623 ppp: COMP 64:
>
>16 packets received by filter
>0 packets dropped by kernel
http://www.bretterklieber.com/mpd/doc3/mpd47.htmlВ самом конце страницы
Windows XP insists on a very low MTU (usualy 1396 Bytes), this needs fragmentation, if bigger packets should be transmited over the link.
........Это похоже на то.
>http://www.bretterklieber.com/mpd/doc3/mpd47.html
>
>В самом конце страницы
>
>Windows XP insists on a very low MTU (usualy 1396 Bytes), this
>needs fragmentation, if bigger packets should be transmited over the link.
>
>........
>
>Это похоже на то.Все эти настройки выставлены. Да и разве 32-хбайтный пинг это большие пакеты?
ng0: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> mtu 1296
inet 10.128.1.1 --> 10.128.1.2 netmask 0xffffffffДа и большие пинги с фряхи на винду бегают без проблем:
zv [16:00:56] ~# ping -c5 -s2048 10.128.1.2
PING 10.128.1.2 (10.128.1.2): 2048 data bytes
2056 bytes from 10.128.1.2: icmp_seq=0 ttl=128 time=12.312 ms
2056 bytes from 10.128.1.2: icmp_seq=1 ttl=128 time=1.227 ms
2056 bytes from 10.128.1.2: icmp_seq=2 ttl=128 time=1.311 ms
2056 bytes from 10.128.1.2: icmp_seq=3 ttl=128 time=1.295 ms
2056 bytes from 10.128.1.2: icmp_seq=4 ttl=128 time=1.286 ms--- 10.128.1.2 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.227/3.486/12.312/4.413 msТут видимо дело в том, что mpd по разному формирует ответы. Это видно по последнему TCPdump'у, у тех пакетов которые винда не приняла отсутствует в конце : COMP xx:
>>13:55:37.112659 IP 10.99.99.99 > 10.99.99.254: gre [KSAv1] ID:8000 S:94 A:616 ppp: COMP 64:
это винда приняла
>>13:55:39.606260 IP 10.99.99.99 > 10.99.99.254: gre [KAv1] ID:8000 A:618 ppp
а это нетНо вот почему это происходит - вопрос...
>Что это может быть и в какую сторону ковырять?
отключить встроеный в винду firewall.
>>Что это может быть и в какую сторону ковырять?
>отключить встроеный в винду firewall.
Где это? Если речь о галке типа "защитить мое соединение" то я ее и не включал. Если что-то другое то можно поподробнее..?Вообще не совсем понимаю причем здесь файрвол? Ведь приведенный tcpdump снят с виндовой машины:
C:\Program Files\Far>windump -nqi1 not port 22
C:\WINDOWS\windump.EXE: listening on \Device\NPF_{4C436E2C-D027-4C14-A619-4C4555964FA8}
13:55:37.111834 IP 10.99.99.254 > 10.99.99.99: gre [KSv1] ID:c9c8 S:616 ppp: COMP 65:
13:55:37.112659 IP 10.99.99.99 > 10.99.99.254: gre [KSAv1] ID:8000 S:94 A:616 ppp: COMP 64:
13:55:38.110499 IP 10.99.99.254 > 10.99.99.99: gre [KSv1] ID:c9c8 S:617 ppp: COMP 65:
13:55:38.110847 IP 10.99.99.99 > 10.99.99.254: gre [KSAv1] ID:8000 S:95 A:617 ppp: COMP 64:
13:55:39.112230 IP 10.99.99.254 > 10.99.99.99: gre [KSv1] ID:c9c8 S:618 ppp: COMP 65:
13:55:39.606260 IP 10.99.99.99 > 10.99.99.254: gre [KAv1] ID:8000 A:618 ppp
13:55:44.549760 IP 10.99.99.254 > 10.99.99.99: gre [KSv1] ID:c9c8 S:619 ppp: COMP 65:
13:55:44.550138 IP 10.99.99.99 > 10.99.99.254: gre [KSAv1] ID:8000 S:96 A:619 ppp: COMP 64:
13:55:45.551203 IP 10.99.99.254 > 10.99.99.99: gre [KSv1] ID:c9c8 S:620 ppp: COMP 65:
13:55:46.047312 IP 10.99.99.99 > 10.99.99.254: gre [KAv1] ID:8000 A:620 ppp
13:55:50.558403 IP 10.99.99.254 > 10.99.99.99: gre [KSv1] ID:c9c8 S:621 ppp: COMP 65:
13:55:50.558831 IP 10.99.99.99 > 10.99.99.254: gre [KSAv1] ID:8000 S:97 A:621 ppp: COMP 64:
13:55:51.559838 IP 10.99.99.254 > 10.99.99.99: gre [KSv1] ID:c9c8 S:622 ppp: COMP 65:
13:55:52.058213 IP 10.99.99.99 > 10.99.99.254: gre [KAv1] ID:8000 A:622 ppp
13:55:56.567040 IP 10.99.99.254 > 10.99.99.99: gre [KSv1] ID:c9c8 S:623 ppp: COMP 65:
13:55:56.567441 IP 10.99.99.99 > 10.99.99.254: gre [KSAv1] ID:8000 S:98 A:623 ppp: COMP 64:И из него видно, что на все 8 ICMP запросов было ПОЛУЧЕНО 8 ответов (т.е. причем тут файрвол), но в трех случаях из восьми в конце пакета отсутствует : COMP 64: и это видимо является причиной того, что винда посчитала три пакета потерянными. Видимо виновата не винда, а mpd который неправильно их сформировал. Почему это происходит? Заменил mpd на 3.18 ... проблема осталась.
Из tcpdump'а на фре с ng0 видно что все ответы на icmp запросы одинаковые и совершенно непонятно почему их mpd (а может netgraph) упаковывает по разному...
>>>Что это может быть и в какую сторону ковырять?
>>отключить встроеный в винду firewall.
>Где это? Если речь о галке типа "защитить мое соединение" то я
>ее и не включал. Если что-то другое то можно поподробнее..?
>
>Вообще не совсем понимаю причем здесь файрвол? Ведь приведенный tcpdump снят с
>виндовой машины:
просто абсолютно симметричные симптомы наблюдались при включеном виндозном firewall, причем без разницы на каком интерфейсе, выключать нужно на всех интерфейсах... интересный момент, идет пинг 50% потерь, запускаю качать с ftp нечто, потерь во время кача нет... проблема была решена эмпирическим путем.
Дело не в mpd и не в Винде. Скорее всего дело в сетевой карте, которая смотрит на винду.
Если у тебя сетевая карта rl0 (Realteck), то меняй ее на xl0 (3-COM).
>Дело не в mpd и не в Винде. Скорее всего дело в
>сетевой карте, которая смотрит на винду.
>Если у тебя сетевая карта rl0 (Realteck), то меняй ее на xl0
>(3-COM).Или лчуше проверить стоят ли родны дрова на сетевуху на винде. Если стоят от Microsoft, то сноси их, и ставь родные. Либо с дискетки, либо с нета слей. Бывали случаи, что сетевухи меняли MAC адреса.
>Дело не в mpd и не в Винде. Скорее всего дело в
>сетевой карте, которая смотрит на винду.
>Если у тебя сетевая карта rl0 (Realteck), то меняй ее на xl0
>(3-COM).
fxp0 (Intel)
mpd обновить до 3.18, в конфиг в default
set iface tcpmssfixНа XP в обязательном порядке включить negotiate multilink on single link connection. Помогает в 99% случаев.
>mpd обновить до 3.18, в конфиг в default
>set iface tcpmssfix
Как я уже писал выше, mpd я обновил до 3.18 и данная строка в конфиге тоже присутствует. Это всетаки, насколько я понимаю, относиться к проблеме с размером пакетов, а в данном случае большие пакеты проходят, только с той же вероятностью как и маленькие...>На XP в обязательном порядке включить negotiate multilink on single link connection.
А это где? Можно подробнее?
>>На XP в обязательном порядке включить negotiate multilink on single link connection.
>А это где? Можно подробнее?
В настройках VPN-соединения. Где точно - не помню, у меня не ХР сейчас.Да, есс-но, выставить в конфиге mpd set bundle enable multilink
Неужели никто не сталкивался с подобной бедой?
>Неужели никто не сталкивался с подобной бедой?
я сталкивался, и не раз... попробовал еще раз - таже песня, включаешь встроеный виндозный firewall на любом! соединении, да же не поднятом WAN - 50% потерь (эзернет на vpn-сервер работает как часы), убираешь firewall все гут... проверь все соединения на наличие этого дела может поможет:)
>>Неужели никто не сталкивался с подобной бедой?
>я сталкивался, и не раз... попробовал еще раз - таже песня,
>включаешь встроеный виндозный firewall на любом! соединении, да же не поднятом
>WAN - 50% потерь (эзернет на vpn-сервер работает как часы),
>убираешь firewall все гут... проверь все соединения на наличие этого дела
>может поможет:)
Да. Так оно и есть. Какова же тогда альтернатива этой виндовой службе? Winroute + Firewall?