forum.opennet.ru - "Непонятная проблема видимо с фрагментацией пакетов" (11)

форумы

помощь

поиск

регистрация

майллист

вход/выход

слежка

"Непонятная проблема видимо с фрагментацией пакетов"

Форумы OpenNET: Виртуальная конференция (Public)
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[Проследить за развитием треда]

"Непонятная проблема видимо с фрагментацией пакетов"
Сообщение от xOr (ok) on 30-Сен-07, 15:45
Добрый день! Возникла проблема с сервером доступа в интернет при настройке подключения через PPTP. Все рациональные объяснения у меня кончились. Помогите пожалуйста! Конфигурация: Сервер доступа в интернет на FreeBSD. На нем работает mpd для соединения с провайдером по PPTP и natd для раздачи трафика. Сервер подключен к провайдеру через роутер, также осуществляющий NAT. Клиенты - FreeBSD: (natd - mpd) - router-nat - vpn.corbina.net Проблема: Если клиент качает из интернета - всё нормально, скорость хорошая, если же он открывает сайт, то некоторые сайты долго не грузятся, загружаются медленно, некоторые не появляются вообще. Спидометр numion.com показывает хорошую скорость на вход-выход потоковых данных, однако тест, загружающий картинки, показывает всего три-четыре картинки за всё время работы, остальные не появляются. Возможно причина связана с различием MTU в локальной сети, интернете и PPTP канале. В локалке MTU 1500 (Ethernet), в интернете наверное тоже на всём протяжении каналов. А вот PPTP канал пропускает IP пакеты размером до 1460 байт. Однако, ping-ом со стороны клиентов проверно, что сервер фрагментирует пакеты нормально. И даже перефрагментирует. Например пакет размером немного более 1500, разбитый на две части в локалке, в туннель посылается также в виде двух частей, размером 1460+остаток. К тому же ошибки фрагментирования исходящих пакетов не повлияли бы так на работу, так как HTTP запросы обычно короткие. Есть мысль, что фрагментирование не происходит на той стороне (у провайдера), в результате большие пакеты, посылаемые сайтами, не проходят через туннель. tcpdump-ом это проверено. Но самое интересное, что если создавать подключение с самого сервера доступа, всё работает отлично! Большие пакеты возвращаются обратно. В ходе попыток устранить проблему были максимально упрощены правила фаервола ipfw. Запрет ICMP пакетов не может происходить. У меня работал подсчет трафика через ipacctd а также очереди шейпинга, отключение этого всего ничего не изменило. В настройке MPD указаны MTU и MRU 1460 (т.к. провайдер в ходе согласования предлагает именно такую величину). Пробовал ставить MRU равный 1492. При этом есть неявное ощущение, что сайты открываются быстрее (не указывать тоже пробовал). Предполагаю что дело в том, что данный размер проходит по туннелю, и большее количество серверов ограничивает пакет до этого размера в попытках создать соединение. Перезапуск всех служб (mpd, natd) и самого сервера ни к чему не приводит. Если клиент работает через прокси, запущенный на сервере (squid), то всё работает нормально (т.к. соединение осуществляется с сервера). Провайдер - Корбина. Т.к. они выдают адрес другой стороны туннеля такой же, как адрес PPTP сервера, то для нормальной маршрутизации приходится адрес другой стороны назначать жестко вручную. Соединение работает при указании любого адреса. Сначала указывал серый адрес. Потом была идея, что возможно они посылают icmp пакет о необходимости фрагментирования с этого адреса, поэтому он не доходит до серверов сайтов. Поставил реальный адрес из той же подсети, что их VPN сервера. Ничего не изменилось. Возможно нужно всё же чтобы адрес совпадал, но тогда не будет ничего работать вообще (другого способа обойти проблему с маршрутизацией не нашел). Раньше PPTP терминация производилась на аппаратном роутере, а на FreeBSD был только NAT, и всё работало. Клиенты - FreeBSD: (nat) - router-nat-pptp - vpn.corbina.net Роутер - D-Link DI-604. С терминацией PPTP он глючил, поэтому перенес её на сервер. Судя по тому, что с самого сервера всё нормально, проблем в PPTP, как и в роутере, через который идет PPTP, быть не должно. Дело или в natd, но у него нет совершенно никаких настроечных опций, или в ядре, что-то связанное с маршрутизацией. Пробовал менять некоторые параметры sysctl, но тщетно. Самое интересное, что когда терминация PPTP производилась на железке, то там с MTU соответственно тоже было узкое место, но при этом сервер нормально всё маршрутизировал. Если проблма с фрагментацией при использовании ната - то почему фрагменты пакетов вообще не появляются на интерфейсе ng0? А если проблема с фрагментацией на стороне провайдера, почему с самого сервера всё отлично работает? Подключить сервер без промежуточного роутера возможности нет. Кто знаком с проблемами, связанными с фрагментацией, разницей в MTU, подскажите пожалуйста возможные причины! Или причина кроется в другом. Подробная конфигурация: FreeBSD 4.10 Локальный интерфейс: fxp0 Локальный адрес: 172.27.0.3/22 Локальный адрес шлюза в сеть провайдера - в той же подсети. Внешний интерфейс (PPTP): ng0 Внешний адрес (выдаваемый по PPTP) 89.x.x.x ipfw, с трафиком: 00020 101 6345 allow tcp from me to any 1723 00021 73 4940 allow tcp from any 1723 to me 00022 1106917 586778546 allow gre from any to any 01110 0 0 allow ip from any to any via lo0 01530 322322 135234505 divert 8673 ip from any to 89.x.x.x in recv ng0 07010 367932 405391989 divert 8673 ip from 172.27.0.0/22 to any out xmit ng0 10540 599684 592065007 allow ip from me to any 10550 225834 195756021 allow ip from any to me 15010 2445401 1418662308 allow ip from any to any natd: /sbin/natd -a 89.x.x.x -p 8673 -P /var/run/nat.pid -f /etc/natd.conf natd.conf: use_sockets same_ports redirect_port tcp 172.27.x.x:80 80 redirect_port tcp 172.27.x.x:21 21 #и так далее несклько штук - это перенаправление входящих соединений Версия MPD 3.17 Пересобирал ядро с патчем ng_pptpgre.patch-4.10.txt для устранения ошибок no buffer space available также для этого добавил опцию set pptp disable delayed-ack в mpd.links Корбина работает без шифрования, с авторизацией CHAP. mpd.conf: default: load vpn1 vpn1: new -i ng0 vpn1 vpn1 set bundle authname "login" set iface disable on-demand set iface disable proxy-arp set iface enable tcpmssfix set iface idle 0 set iface route default set bundle no multilink set bundle no compression set bundle no encryption set link accept chap set link no pap set link no acfcomp protocomp set link mtu 1460 set link mru 1460 set link keep-alive 30 120 # set link enable no-orig-auth set ipcp no vjcomp set ipcp ranges 0.0.0.0/0 192.168.x.x/32 open mpd.links: vpn1: set link type pptp set pptp peer vpn.corbina.net set pptp disable incoming set pptp enable originate outcall set pptp disable delayed-ack sysctl.conf: net.inet.ip.fw.one_pass=0 net.inet.ip.dummynet.expire=1 net.inet.ip.dummynet.hash_size=256 net.inet.ip.dummynet.max_chain_len=64 net.link.ether.inet.log_arp_wrong_iface=0 kern.ipc.maxsockbuf=1048576 net.inet.tcp.delayed_ack=0 #эти три опции пробовал менять - не помогает net.inet.tcp.rfc1323=0 net.inet.tcp.always_keepalive=1 net.local.stream.sendspace=65535 net.local.stream.recvspace=65535 net.inet.tcp.sendspace=131072 net.inet.tcp.recvspace=131072 net.local.dgram.recvspace=65535 net.inet.udp.recvspace=65535 net.inet.udp.maxdgram=57344 net.inet.raw.recvspace=65535 kern.ipc.somaxconn=4096 kern.maxfiles=4096 kern.maxfilesperproc=2048 net.inet.ip.ttl=255 kern.polling.user_frac=20 kern.polling.idle_poll=1 kern.polling.poll_in_trap=1 kern.polling.enable=1 sysctl net.inet: net.inet.ip.portrange.lowfirst: 1023 net.inet.ip.portrange.lowlast: 600 net.inet.ip.portrange.first: 1024 net.inet.ip.portrange.last: 5000 net.inet.ip.portrange.hifirst: 49152 net.inet.ip.portrange.hilast: 65535 net.inet.ip.portrange.randomized: 1 net.inet.ip.forwarding: 1 net.inet.ip.redirect: 1 net.inet.ip.ttl: 255 net.inet.ip.rtexpire: 1600 net.inet.ip.rtminexpire: 10 net.inet.ip.rtmaxcache: 128 net.inet.ip.sourceroute: 0 net.inet.ip.intr_queue_maxlen: 50 net.inet.ip.intr_queue_drops: 0 net.inet.ip.accept_sourceroute: 0 net.inet.ip.fastforwarding: 0 net.inet.ip.keepfaith: 0 net.inet.ip.gifttl: 30 net.inet.ip.subnets_are_local: 0 net.inet.ip.dummynet.hash_size: 256 net.inet.ip.dummynet.curr_time: 3982531 net.inet.ip.dummynet.ready_heap: 0 net.inet.ip.dummynet.extract_heap: 16 net.inet.ip.dummynet.searches: 1340097 net.inet.ip.dummynet.search_steps: 1340051 net.inet.ip.dummynet.expire: 1 net.inet.ip.dummynet.max_chain_len: 64 net.inet.ip.dummynet.red_lookup_depth: 256 net.inet.ip.dummynet.red_avg_pkt_size: 512 net.inet.ip.dummynet.red_max_pkt_size: 1500 net.inet.ip.fw.enable: 1 net.inet.ip.fw.one_pass: 0 net.inet.ip.fw.debug: 1 net.inet.ip.fw.verbose: 1 net.inet.ip.fw.verbose_limit: 10 net.inet.ip.fw.dyn_buckets: 256 net.inet.ip.fw.curr_dyn_buckets: 256 net.inet.ip.fw.dyn_count: 1 net.inet.ip.fw.dyn_max: 1000 net.inet.ip.fw.static_count: 41 net.inet.ip.fw.dyn_ack_lifetime: 300 net.inet.ip.fw.dyn_syn_lifetime: 20 net.inet.ip.fw.dyn_fin_lifetime: 1 net.inet.ip.fw.dyn_rst_lifetime: 1 net.inet.ip.fw.dyn_udp_lifetime: 10 net.inet.ip.fw.dyn_short_lifetime: 5 net.inet.ip.fw.dyn_grace_time: 10 net.inet.ip.maxfragpackets: 128 net.inet.ip.maxfragsperpacket: 16 net.inet.ip.sendsourcequench: 0 net.inet.ip.check_interface: 0 net.inet.icmp.maskrepl: 0 net.inet.icmp.icmplim: 200 net.inet.icmp.drop_redirect: 0 net.inet.icmp.log_redirect: 0 net.inet.icmp.icmplim_output: 1 net.inet.icmp.bmcastecho: 0 net.inet.tcp.rfc1323: 0 net.inet.tcp.rfc1644: 0 net.inet.tcp.mssdflt: 512 net.inet.tcp.keepidle: 7200000 net.inet.tcp.keepintvl: 75000 net.inet.tcp.sendspace: 131072 net.inet.tcp.recvspace: 131072 net.inet.tcp.keepinit: 75000 net.inet.tcp.delacktime: 100 net.inet.tcp.v6mssdflt: 1024 net.inet.tcp.log_in_vain: 0 net.inet.tcp.blackhole: 0 net.inet.tcp.delayed_ack: 0 net.inet.tcp.reass.maxsegments: 256 net.inet.tcp.reass.cursegments: 0 net.inet.tcp.reass.overflows: 0 net.inet.tcp.path_mtu_discovery: 1 net.inet.tcp.slowstart_flightsize: 1 net.inet.tcp.local_slowstart_flightsize: 4 net.inet.tcp.newreno: 1 net.inet.tcp.tcbhashsize: 512 net.inet.tcp.do_tcpdrain: 1 net.inet.tcp.pcbcount: 114 net.inet.tcp.icmp_may_rst: 1 net.inet.tcp.isn_reseed_interval: 0 net.inet.tcp.inflight_enable: 0 net.inet.tcp.inflight_debug: 0 net.inet.tcp.inflight_min: 6144 net.inet.tcp.inflight_max: 1073725440 net.inet.tcp.inflight_stab: 20 net.inet.tcp.syncookies: 1 net.inet.tcp.syncache.bucketlimit: 30 net.inet.tcp.syncache.cachelimit: 15359 net.inet.tcp.syncache.count: 0 net.inet.tcp.syncache.hashsize: 512 net.inet.tcp.syncache.rexmtlimit: 3 net.inet.tcp.msl: 30000 net.inet.tcp.rexmit_min: 1000 net.inet.tcp.rexmit_slop: 200 net.inet.tcp.always_keepalive: 1 net.inet.udp.checksum: 1 net.inet.udp.maxdgram: 57344 net.inet.udp.recvspace: 65535 net.inet.udp.log_in_vain: 0 net.inet.udp.blackhole: 0 net.inet.accf.unloadable: 0 net.inet.raw.maxdgram: 8192 net.inet.raw.recvspace: 65535 Опции ядра в CUSTOM: maxusers 0 options NMBCLUSTERS=65535 options NBUF=512 options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=10 options IPFIREWALL_FORWARD options IPDIVERT options NETGRAPH options NETGRAPH_IFACE options NETGRAPH_BPF options NETGRAPH_KSOCKET options NETGRAPH_MPPC_ENCRYPTION options NETGRAPH_PPP options NETGRAPH_PPPOE options NETGRAPH_PPTPGRE options NETGRAPH_SOCKET options NETGRAPH_TTY options NETGRAPH_VJC options NETGRAPH_ASYNC options NETGRAPH_ECHO options NETGRAPH_ETHER options NETGRAPH_HOLE options NETGRAPH_L2TP options NETGRAPH_LMI options NETGRAPH_ONE2MANY options NETGRAPH_RFC1490 options NETGRAPH_TEE options NETGRAPH_UI options DUMMYNET options DEVICE_POLLING options HZ=1000 Пример удачной сессии с самого сервера: tcpdump -i ng0 -v host 217.21.33.27 tcpdump: listening on ng0 15:08:36.160826 89.x.x.x.4564 > 217.21.33.27.http: S [tcp sum ok] 17076150 88:1707615088(0) win 65535 <mss 1420> (DF) [tos 0x10] (ttl 255, id 9844, len 44 ) 15:08:36.198855 217.21.33.27.http > 89.x.x.x.4564: S [tcp sum ok] 28994479 2:289944792(0) ack 1707615089 win 16384 <mss 1420> (ttl 116, id 6264, len 44) 15:08:36.199115 89.x.x.x.4564 > 217.21.33.27.http: . [tcp sum ok] ack 1 wi n 65535 (DF) [tos 0x10] (ttl 255, id 9914, len 40) 15:08:50.328457 89.x.x.x.4564 > 217.21.33.27.http: P [tcp sum ok] 1:16(15) ack 1 win 65535 (DF) [tos 0x10] (ttl 255, id 30135, len 55) 15:08:50.560474 217.21.33.27.http > 89.x.x.x.4564: . [tcp sum ok] ack 16 w in 65520 (DF) (ttl 116, id 8989, len 40) 15:08:51.809225 89.x.x.x.4564 > 217.21.33.27.http: P [tcp sum ok] 16:18(2) ack 1 win 65535 (DF) [tos 0x10] (ttl 255, id 32165, len 42) 15:08:51.919481 217.21.33.27.http > 89.x.x.x.4564: P 1:193(192) ack 18 win 65518 (DF) (ttl 116, id 9377, len 232) 15:08:51.919653 89.x.x.x.4564 > 217.21.33.27.http: . [tcp sum ok] ack 193 win 65535 (DF) [tos 0x10] (ttl 255, id 32337, len 40) 15:08:51.921208 217.21.33.27.http > 89.x.x.x.4564: . 193:1613(1420) ack 18 win 65518 (DF) (ttl 116, id 9378, len 1460) 15:08:51.921357 89.x.x.x.4564 > 217.21.33.27.http: . [tcp sum ok] ack 1613 win 65535 (DF) [tos 0x10] (ttl 255, id 32342, len 40) 15:08:51.956889 217.21.33.27.http > 89.x.x.x.4564: . 1613:3033(1420) ack 1 8 win 65518 (DF) (ttl 116, id 9379, len 1460) 15:08:51.956961 217.21.33.27.http > 89.x.x.x.4564: . 3033:4453(1420) ack 1 8 win 65518 (DF) (ttl 116, id 9380, len 1460) 15:08:51.957161 89.x.x.x.4564 > 217.21.33.27.http: . [tcp sum ok] ack 3033 win 65535 (DF) [tos 0x10] (ttl 255, id 32391, len 40) 15:08:51.957911 217.21.33.27.http > 89.x.x.x.4564: . 4453:5873(1420) ack 1 8 win 65518 (DF) (ttl 116, id 9381, len 1460) 15:08:51.957989 217.21.33.27.http > 89.x.x.x.4564: . 5873:7293(1420) ack 1 8 win 65518 (DF) (ttl 116, id 9382, len 1460) 15:08:51.960736 89.x.x.x.4564 > 217.21.33.27.http: . [tcp sum ok] ack 4453 win 65535 (DF) [tos 0x10] (ttl 255, id 32400, len 40) 15:08:51.967267 89.x.x.x.4564 > 217.21.33.27.http: . [tcp sum ok] ack 5873 win 65535 (DF) [tos 0x10] (ttl 255, id 32412, len 40) 15:08:51.971660 89.x.x.x.4564 > 217.21.33.27.http: . [tcp sum ok] ack 7293 win 65535 (DF) [tos 0x10] (ttl 255, id 32420, len 40) 15:08:51.994658 217.21.33.27.http > 89.x.x.x.4564: . 7293:8713(1420) ack 1 8 win 65518 (DF) (ttl 116, id 9402, len 1460) 15:08:51.994852 217.21.33.27.http > 89.x.x.x.4564: . 8713:10133(1420) ack 18 win 65518 (DF) (ttl 116, id 9403, len 1460) 15:08:51.996422 89.x.x.x.4564 > 217.21.33.27.http: . [tcp sum ok] ack 8713 win 65535 (DF) [tos 0x10] (ttl 255, id 32471, len 40) 15:08:52.000579 89.x.x.x.4564 > 217.21.33.27.http: . [tcp sum ok] ack 1013 3 win 65535 (DF) [tos 0x10] (ttl 255, id 32475, len 40) 15:08:52.000762 217.21.33.27.http > 89.x.x.x.4564: . 10133:11553(1420) ack 18 win 65518 (DF) (ttl 116, id 9404, len 1460) 15:08:52.000889 217.21.33.27.http > 89.x.x.x.4564: FP 11553:12937(1384) ac k 18 win 65518 (DF) (ttl 116, id 9405, len 1424) 15:08:52.006529 89.x.x.x.4564 > 217.21.33.27.http: . [tcp sum ok] ack 1155 3 win 65535 (DF) [tos 0x10] (ttl 255, id 32493, len 40) 15:08:52.010290 89.x.x.x.4564 > 217.21.33.27.http: . [tcp sum ok] ack 1293 8 win 65535 (DF) [tos 0x10] (ttl 255, id 32501, len 40) 15:08:52.013342 89.x.x.x.4564 > 217.21.33.27.http: F [tcp sum ok] 18:18(0) ack 12938 win 65535 (DF) [tos 0x10] (ttl 255, id 32507, len 40) 15:08:52.049852 217.21.33.27.http > 89.x.x.x.4564: . [tcp sum ok] ack 19 w in 65518 (DF) (ttl 116, id 9406, len 40) ^C 63028 packets received by filter 0 packets dropped by kernel Пример сессии с клиента: 1. Локальный интерфейс: tcpdump -i fxp0 -v host 217.21.33.27 tcpdump: listening on fxp0 15:14:50.540301 172.27.x.x.4619 > 33-27.dsl.aichyna.com.http: S [tcp sum ok] 15 70137065:1570137065(0) win 65535 <mss 1460,nop,wscale 0,nop,nop,timestamp 683581 842 0> (DF) [tos 0x10] (ttl 255, id 47618, len 60) 15:14:50.576813 33-27.dsl.aichyna.com.http > 172.27.x.x.4619: S [tcp sum ok] 64 7251895:647251895(0) ack 1570137066 win 16384 <mss 1420,nop,wscale 0,nop,nop,tim estamp 0 0> (ttl 115, id 38006, len 60) 15:14:50.576963 172.27.x.x.4619 > 33-27.dsl.aichyna.com.http: . [tcp sum ok] ac k 1 win 65535 <nop,nop,timestamp 683581879 0> (DF) [tos 0x10] (ttl 255, id 4763 0, len 52) 15:14:58.189522 172.27.x.x.4619 > 33-27.dsl.aichyna.com.http: P [tcp sum ok] 1: 16(15) ack 1 win 65535 <nop,nop,timestamp 683589492 0> (DF) [tos 0x10] (ttl 255 , id 49736, len 67) 15:14:58.404459 33-27.dsl.aichyna.com.http > 172.27.x.x.4619: . [tcp sum ok] ac k 16 win 65520 <nop,nop,timestamp 1670044 683581842> (DF) (ttl 115, id 40248, le n 52) 15:14:58.792857 172.27.x.x.4619 > 33-27.dsl.aichyna.com.http: P [tcp sum ok] 16 :18(2) ack 1 win 65535 <nop,nop,timestamp 683590095 1670044> (DF) [tos 0x10] (t tl 255, id 49863, len 54) 15:14:58.901817 33-27.dsl.aichyna.com.http > 172.27.x.x.4619: P 1:193(192) ack 18 win 65518 <nop,nop,timestamp 1670048 683590095> (DF) (ttl 115, id 40484, len 244) 15:14:58.902152 172.27.x.x.4619 > 33-27.dsl.aichyna.com.http: . [tcp sum ok] ac k 193 win 65535 <nop,nop,timestamp 683590204 1670048> (DF) [tos 0x10] (ttl 255, id 49871, len 52) 15:15:11.381245 33-27.dsl.aichyna.com.http > 172.27.x.x.4619: . [tcp sum ok] 16 41:1653(12) ack 18 win 65518 <nop,nop,timestamp 1670174 683590204> (DF) (ttl 115 , id 44559, len 64) 15:15:11.381428 172.27.x.x.4619 > 33-27.dsl.aichyna.com.http: . [tcp sum ok] ac k 193 win 65535 <nop,nop,timestamp 683602685 1670048> (DF) [tos 0x10] (ttl 255, id 51700, len 52) 15:15:21.460687 33-27.dsl.aichyna.com.http > 172.27.x.x.4619: . [tcp sum ok] 16 41:1653(12) ack 18 win 65518 <nop,nop,timestamp 1670274 683602685> (DF) (ttl 115 , id 47539, len 64) 15:15:21.461145 172.27.x.x.4619 > 33-27.dsl.aichyna.com.http: . [tcp sum ok] ac k 193 win 65535 <nop,nop,timestamp 683612765 1670048> (DF) [tos 0x10] (ttl 255, id 52843, len 52) 15:15:21.521485 33-27.dsl.aichyna.com.http > 172.27.x.x.4619: . [tcp sum ok] 16 41:1653(12) ack 18 win 65518 <nop,nop,timestamp 1670274 683612765> (DF) (ttl 115 , id 47541, len 64) 15:15:21.521920 172.27.x.x.4619 > 33-27.dsl.aichyna.com.http: . [tcp sum ok] ac k 193 win 65535 <nop,nop,timestamp 683612826 1670048> (DF) [tos 0x10] (ttl 255, id 52849, len 52) 15:15:46.432241 33-27.dsl.aichyna.com.http > 172.27.x.x.4619: . [tcp sum ok] 16 41:1653(12) ack 18 win 65518 <nop,nop,timestamp 1670524 683612826> (DF) (ttl 115 , id 54273, len 64) 15:15:46.432413 172.27.x.x.4619 > 33-27.dsl.aichyna.com.http: . [tcp sum ok] ac k 193 win 65535 <nop,nop,timestamp 683637738 1670048> (DF) [tos 0x10] (ttl 255, id 56763, len 52) 15:15:56.435676 172.27.x.x.4619 > 33-27.dsl.aichyna.com.http: F [tcp sum ok] 18 :18(0) ack 193 win 65535 <nop,nop,timestamp 683647742 1670048> (DF) [tos 0x10] (ttl 255, id 58495, len 52) 15:15:56.474899 33-27.dsl.aichyna.com.http > 172.27.x.x.4619: . [tcp sum ok] ac k 19 win 65518 <nop,nop,timestamp 1670624 683647742> (DF) (ttl 115, id 57373, le n 52) ^C 280613 packets received by filter 0 packets dropped by kernel 2. Внешний интерфейс (сразу говорю, что все те же пакеты): tcpdump -i ng0 -v host 217.21.33.27 tcpdump: listening on ng0 15:14:50.541398 89.x.x.x.4619 > 217.21.33.27.http: S [tcp sum ok] 15701370 65:1570137065(0) win 65535 <mss 1460,nop,wscale 0,nop,nop,timestamp 683581842 0> (DF) [tos 0x10] (ttl 254, id 47618, len 60) 15:14:50.576601 217.21.33.27.http > 89.x.x.x.4619: S [tcp sum ok] 64725189 5:647251895(0) ack 1570137066 win 16384 <mss 1420,nop,wscale 0,nop,nop,timestamp 0 0> (ttl 116, id 38006, len 60) 15:14:50.577205 89.x.x.x.4619 > 217.21.33.27.http: . [tcp sum ok] ack 1 wi n 65535 <nop,nop,timestamp 683581879 0> (DF) [tos 0x10] (ttl 254, id 47630, len 52) 15:14:58.190192 89.x.x.x.4619 > 217.21.33.27.http: P [tcp sum ok] 1:16(15) ack 1 win 65535 <nop,nop,timestamp 683589492 0> (DF) [tos 0x10] (ttl 254, id 4 9736, len 67) 15:14:58.404202 217.21.33.27.http > 89.x.x.x.4619: . [tcp sum ok] ack 16 w in 65520 <nop,nop,timestamp 1670044 683581842> (DF) (ttl 116, id 40248, len 52) 15:14:58.808433 89.x.x.x.4619 > 217.21.33.27.http: P [tcp sum ok] 16:18(2) ack 1 win 65535 <nop,nop,timestamp 683590095 1670044> (DF) [tos 0x10] (ttl 254 , id 49863, len 54) 15:14:58.901601 217.21.33.27.http > 89.x.x.x.4619: P 1:193(192) ack 18 win 65518 <nop,nop,timestamp 1670048 683590095> (DF) (ttl 116, id 40484, len 244) 15:14:58.904088 89.x.x.x.4619 > 217.21.33.27.http: . [tcp sum ok] ack 193 win 65535 <nop,nop,timestamp 683590204 1670048> (DF) [tos 0x10] (ttl 254, id 49 871, len 52) 15:15:11.380993 217.21.33.27.http > 89.x.x.x.4619: . [tcp sum ok] 1641:165 3(12) ack 18 win 65518 <nop,nop,timestamp 1670174 683590204> (DF) (ttl 116, id 4 4559, len 64) 15:15:11.383196 89.x.x.x.4619 > 217.21.33.27.http: . [tcp sum ok] ack 193 win 65535 <nop,nop,timestamp 683602685 1670048> (DF) [tos 0x10] (ttl 254, id 51 700, len 52) 15:15:21.444668 217.21.33.27.http > 89.x.x.x.4619: . [tcp sum ok] 1641:165 3(12) ack 18 win 65518 <nop,nop,timestamp 1670274 683602685> (DF) (ttl 116, id 4 7539, len 64) 15:15:21.465095 89.x.x.x.4619 > 217.21.33.27.http: . [tcp sum ok] ack 193 win 65535 <nop,nop,timestamp 683612765 1670048> (DF) [tos 0x10] (ttl 254, id 52 843, len 52) 15:15:21.503332 217.21.33.27.http > 89.x.x.x.4619: . [tcp sum ok] 1641:165 3(12) ack 18 win 65518 <nop,nop,timestamp 1670274 683612765> (DF) (ttl 116, id 4 7541, len 64) 15:15:21.538159 89.x.x.x.4619 > 217.21.33.27.http: . [tcp sum ok] ack 193 win 65535 <nop,nop,timestamp 683612826 1670048> (DF) [tos 0x10] (ttl 254, id 52 849, len 52) 15:15:46.431858 217.21.33.27.http > 89.x.x.x.4619: . [tcp sum ok] 1641:165 3(12) ack 18 win 65518 <nop,nop,timestamp 1670524 683612826> (DF) (ttl 116, id 5 4273, len 64) 15:15:46.433848 89.x.x.x.4619 > 217.21.33.27.http: . [tcp sum ok] ack 193 win 65535 <nop,nop,timestamp 683637738 1670048> (DF) [tos 0x10] (ttl 254, id 56 763, len 52) 15:15:56.437576 89.x.x.x.4619 > 217.21.33.27.http: F [tcp sum ok] 18:18(0) ack 193 win 65535 <nop,nop,timestamp 683647742 1670048> (DF) [tos 0x10] (ttl 2 54, id 58495, len 52) 15:15:56.474701 217.21.33.27.http > 89.x.x.x.4619: . [tcp sum ok] ack 19 w in 65518 <nop,nop,timestamp 1670624 683647742> (DF) (ttl 116, id 57373, len 52) ^C 100221 packets received by filter 0 packets dropped by kernel Пример фрагментируемого пинга с клиента: glukow# ping -s 2000 www.ru PING www.ru (194.87.0.50): 2000 data bytes 2008 bytes from 194.87.0.50: icmp_seq=0 ttl=54 time=16.495 ms 2008 bytes from 194.87.0.50: icmp_seq=1 ttl=54 time=15.541 ms 2008 bytes from 194.87.0.50: icmp_seq=2 ttl=54 time=15.081 ms 2008 bytes from 194.87.0.50: icmp_seq=3 ttl=54 time=14.901 ms 2008 bytes from 194.87.0.50: icmp_seq=4 ttl=54 time=14.864 ms 2008 bytes from 194.87.0.50: icmp_seq=5 ttl=54 time=14.143 ms ^C --- www.ru ping statistics --- 6 packets transmitted, 6 packets received, 0% packet loss round-trip min/avg/max/stddev = 14.143/15.171/16.495/0.721 ms На внутреннем: 15:29:03.713248 172.27.x.x > www.ru: icmp: echo request (frag 23159:1480@0+) ( tl 255, len 1500) 15:29:03.713286 172.27.x.x > www.ru: icmp (frag 23159:528@1480) (ttl 255, len 48) 15:29:03.729014 www.ru > 172.27.x.x: icmp: echo reply (frag 32104:1480@0+) [to 0x28] (ttl 54, len 1500) 15:29:03.729024 www.ru > 172.27.x.x: icmp (frag 32104:528@1480) [tos 0x28] (t l 54, len 548) 15:29:04.714403 172.27.x.x > www.ru: icmp: echo request (frag 23436:1480@0+) ( tl 255, len 1500) 15:29:04.714531 172.27.x.x > www.ru: icmp (frag 23436:528@1480) (ttl 255, len 48) 15:29:04.728972 www.ru > 172.27.x.x: icmp: echo reply (frag 32891:1480@0+) [to 0x28] (ttl 54, len 1500) 15:29:04.728982 www.ru > 172.27.x.x: icmp (frag 32891:528@1480) [tos 0x28] (t l 54, len 548) .........и т.д....... На внешнем: 15:29:03.717402 89.x.x.x > 194.87.0.50: icmp: echo request (frag 23159:144 0@0+) (ttl 254, len 1460) 15:29:03.717449 89.x.x.x > 194.87.0.50: icmp (frag 23159:568@1440) (ttl 25 4, len 588) 15:29:03.724117 194.87.0.50 > 89.x.x.x: icmp: echo reply (wrong icmp csum) (frag 32104:40@0+) [tos 0x28] (ttl 55, len 60) 15:29:03.725737 194.87.0.50 > 89.x.x.x: icmp (frag 32104:1440@40+) [tos 0x 28] (ttl 55, len 1460) 15:29:03.725804 194.87.0.50 > 89.x.x.x: icmp (frag 32104:528@1480) [tos 0x 28] (ttl 55, len 548) 15:29:04.717957 89.x.x.x > 194.87.0.50: icmp: echo request (frag 23436:144 0@0+) (ttl 254, len 1460) 15:29:04.718014 89.x.x.x > 194.87.0.50: icmp (frag 23436:568@1440) (ttl 25 4, len 588) 15:29:04.724241 194.87.0.50 > 89.x.x.x: icmp: echo reply (wrong icmp csum) (frag 32891:40@0+) [tos 0x28] (ttl 55, len 60) 15:29:04.725646 194.87.0.50 > 89.x.x.x: icmp (frag 32891:1440@40+) [tos 0x 28] (ttl 55, len 1460) 15:29:04.725707 194.87.0.50 > 89.x.x.x: icmp (frag 32891:528@1480) [tos 0x 28] (ttl 55, len 548) ..... и т.д........ Это пинг с FreeBSD 4.9. Кстати при пинге с Windows клиента, никаких сообщений о wrong checksum не было (к сожалению лога нет)!
Высказать мнение \| Ответить \| Правка \| Cообщить модератору

Оглавление

Непонятная проблема видимо с фрагментацией пакетов, xOr, 23:21 , 01-Окт-07, (1)

Непонятная проблема видимо с фрагментацией пакетов, konst, 23:50 , 01-Окт-07, (2)

Непонятная проблема видимо с фрагментацией пакетов, xOr, 02:25 , 02-Окт-07, (3)

Непонятная проблема видимо с фрагментацией пакетов, xOr, 12:43 , 03-Окт-07, (4)

Непонятная проблема видимо с фрагментацией пакетов, frey, 12:58 , 03-Окт-07, (5)

Непонятная проблема видимо с фрагментацией пакетов, xOr, 22:50 , 03-Окт-07, (6)

Непонятная проблема видимо с фрагментацией пакетов, xOr, 23:59 , 03-Окт-07, (7)

Непонятная проблема видимо с фрагментацией пакетов, frey, 15:11 , 04-Окт-07, (8)

Причина найдена, решение нет!, xOr, 21:44 , 06-Окт-07, (9)

Причина найдена, решение нет!, xOr, 03:33 , 07-Окт-07, (10)

Причина найдена, решение нет!, stec, 04:33 , 19-Дек-07, (11)

Сообщения по теме [Сортировка по времени | RSS]

1. "Непонятная проблема видимо с фрагментацией пакетов"

Сообщение от xOr (ok) on 01-Окт-07, 23:21

Наверное смутил всех объемом логов.  Всегда просили максимально подробно описать проблему, видимо переборщил.
Есть хоть какие-нибудь мнения по этой проблеме?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "Непонятная проблема видимо с фрагментацией пакетов"

Сообщение от konst (??) on 01-Окт-07, 23:50

>Наверное смутил всех объемом логов.  Всегда просили максимально подробно описать проблему,
>видимо переборщил.
>
>Есть хоть какие-нибудь мнения по этой проблеме?
Здесь уже были подобные темы недавно:
Напр.
http://www.opennet.ru/openforum/vsluhforumID1/48524.html
http://www.opennet.ru/openforum/vsluhforumID15/1261.html
Из одной из тем:
Попробуй в mpd.conf указать опцию: set iface enable tcpmssfix

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

3. "Непонятная проблема видимо с фрагментацией пакетов"

Сообщение от xOr (??) on 02-Окт-07, 02:25

>>Есть хоть какие-нибудь мнения по этой проблеме?
>
>Здесь уже были подобные темы недавно:
>Напр.
>http://www.opennet.ru/openforum/vsluhforumID1/48524.html
>http://www.opennet.ru/openforum/vsluhforumID15/1261.html
>
>Из одной из тем:
>
>Попробуй в mpd.conf указать опцию: set iface enable tcpmssfix
У меня стоит эта опция (конфиг в первом сообщении).
По первой ссылке там вообще была раздача через MPD, а у меня доступ.
А в отличие от темы 2-й ссылки, с самой системы всё отлично работает (а также через если клиенты работают через прокси на этой системе) Не работает транзитом.
Также когда на клиенте настраивали внешний (в инете) прокси, то тоже как ни странно лучше работало (но не тестили почти).

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

4. "Непонятная проблема видимо с фрагментацией пакетов"

Сообщение от xOr (??) on 03-Окт-07, 12:43

Настроил на другом сервере. Там FreeBSD 4.9
Всё то же самое. Картинки грузятся очень долго, большинство не грузится (в тесте numion.com).  Этот же сервер является роутером с nat через обычный Ethernet канал и через DSL маршрутизатор (то есть всего на нем 3 аплинка).  Они работают нормально, только через PPTP проблемы.  Настройки для всех похожие, nat + fwd на нужный шлюз в зависимости от адреса источника (задаваемого натом).
При подключении с виндозного компа а также с самого аппаратного роутера, такой проблемы нет.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

5. "Непонятная проблема видимо с фрагментацией пакетов"

Сообщение от frey (ok) on 03-Окт-07, 12:58

Настройки mpd - это хорошо, но действительно ли mtu на интерфейсе меняется?
Сделай руками ifconfig pppX mtu 1460 и посмотри результат.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

6. "Непонятная проблема видимо с фрагментацией пакетов"

Сообщение от xOr (ok) on 03-Окт-07, 22:50

>Настройки mpd - это хорошо, но действительно ли mtu на интерфейсе меняется?
>
>Сделай руками ifconfig pppX mtu 1460 и посмотри результат.
Вроде меняется:
ng0: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> mtu 1460
        inet6 fe80::251:ff:fe00:8f%ng0 prefixlen 64 scopeid 0x7
        inet 89.x.x.x --> 192.168.x.x netmask 0xffffffff

И в логах MPD этот факт тоже отображен:
mpd: [vpn0] setting interface ng0 MTU to 1460 bytes
Сделал вручную, ничего не изменилось.
Впрочим, исходящие HTTP запросы и так маленькие, они бы по любому проскочили.
Кроме того, уже смотрел на интерфейсе tcpdump'ом - исх. пакеты фрагментируются правильно.
А что происходит со входящими на той стороне - никто не знает.  Но всё таки они сами запрашивали 1460.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

7. "Непонятная проблема видимо с фрагментацией пакетов"

Сообщение от xOr (??) on 03-Окт-07, 23:59

А есть ли данные по количеству соединений, одновременно обслуживаемых натом? (natd).
У меня есть подозрение, что нат просто отбрасывает новые подключения.
У меня несколько тысяч одновременных соединений (благодаря файлообменным системам).
Никаких настроек типа размера таблицы, в самом natd нет.  Может быть это зависит от переменных ядра, или вообще неограничено?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

8. "Непонятная проблема видимо с фрагментацией пакетов"

Сообщение от frey (ok) on 04-Окт-07, 15:11

В линуксе /proc/sys/net/nf_conntrack_max, зависит от количества памяти, устанавливается через sysctl.
Например при гб виртуальной памяти - 32768 соединений.
Как в бсд, не могу сказать.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

9. "Причина найдена,  решение нет!"

Сообщение от xOr (ok) on 06-Окт-07, 21:44

>В линуксе /proc/sys/net/nf_conntrack_max, зависит от количества памяти, устанавливается через sysctl.
>Например при гб виртуальной памяти - 32768 соединений.
>Как в бсд, не могу сказать.
Нашел опции в BSD (количество сокетов, сетевых буферов), но они не помогают. И вообще видимо отвечают за соединения с сервера, а не чере него.
Отследив трафик при соединении с тестовым внешним веб-сервером, я установил причину проблем.
Причина отсутствия связи со многими сайтами:
Пакеты не фрагментируются со стороны провайдера перед передачей в PPTP.   Поэтому все пакеты больше MTU pptp канала (1460) пропадают.   Сервер pptp провайдера генерирует ICMP сообщения о необходимости фрагментации, но, видимо, большинство сайтов не реагируют на них, или же эти пакеты где-то пропадают по ходу машрута.
Причина нормальной работы с самого сервера доступа:
При установке TCP соединения с самого сервера доступа, в параметрах TCP указывается MSS (1420) соответствующее MTU своего интерфейса, поэтому удаленный сервер не может послать сегмент TCP более указанного MSS и IP пакеты получаются не более MTU pptp канала. Сервер видимо использует MTU своих интерфейсов для определения MSS.
А компьютеры, работающие через сервер доступа как шлюз используют бОльший MSS (т.к. не знают о интерфейсах на пути маршрута, и используют своё значение MTU), и в результате отсутствия фрагментации со стороны провайдера, большие пакеты с той стороны не проходят.
Почему же тогда не работает опция MPD tcpmssfix, которая должна изменять MSS устанавливаемых TCP соединений? Правильность её указания проверялась.
Замечено, что в ответе от сервера MSS изменено (в логах неработающего соединения см. 2-ю строчку на обоих серверах)  с 1460 на 1420.  Но в запросе серверу MSS не меняется (так и осталось 1456, см. 1ю строчку тех же логов).    Соответственно входящие соединения работают хорошо, а исходящие только с маленькими файлами.
Если tcpmssfix должна менять MSS только исходящих пакетов, значит у меня не работает эта опция, а у провайдера она работает.    Если она должна менять MSS в обоих направлениях, значит у меня она работает криво, а у провайдера отсутствует.
Что можете посоветовать?
Ещё загадка, почему фрагментируются и собираются ICMP пакеты?  С моей стороны фрагментируются все пакеты, но на веб-сервер пакет ICMP приходит уже собранный, такого же размера, как отправленный клиентом. Целый же ответ посылает и веб-сервер, и он проходит на сервер доступа в виде двух фрагментов (кстати переразбиты немного по другому, чем на выходе).   То есть получается что корбина фрагментирует ICMP пакеты (и собирает их), а на остальные забивает?   (Правда пришедший фгармент ICMP был опознан tcpdump'ом на сервере как поврежденный, но может это просто потому что это фрагмент, а tcpdump стал проверять его как целый пакет.  Пинг ведь не сообщает об ошибках).  С сервера так же хорошо пингуется, как через него.  И входящий фрагментированный пинг также отлично проходит.
Как обстоит с фрагментацией UDP - не знаю, не проверял.
Да и вообще с какой стати провайдер не фрагментирует пакеты? У кого есть возможность, проверьте пожалуйста, везде ли и всегда ли так происходит с корбиной.   Может они фрагментируют только ICMP и, возможно, UDP (потому что иначе будет с ними проблема), а для соединений TCP надеются на выбор инициатором правильного MSS, и, возможно, сами используют tcpmssfix для входящих соединений.  Таким образом снижается нагрузка на сервер в результате отключения фрагментации IP содержащих TCP. Такая ли большая нагрузка, не думаю.
А может чтобы запретить распределение трафика? Конечно, когда клиент подключается непосредственно по pptp, он создает соединения с правильными MSS и проблем нет.  Но как же тогда аппаратные роутеры? Через тот же DI604 всё прекрасно работало.  Видимо всё же у меня опция не работает. Но почему, версия MPD должна её поддерживать (у меня 3.17,  в инете написано что не поддерживают ранее 3.15).
Ещё кто знает как заставить свой веб-сервер реагировать на ICMP сообщения о необходимости фрагментации (в нем указывается MTU), расскажите пожалуйста! (возможно это опция sysctl?).
Логи:
В снифах время у серверов различается, поэтому не смотрите на него.
Адрес клиента: 192.168.15.15  интерфейс  fxp0
Внешний адрес сервера доступа: 89.179.x.x   интерфейс ng0
Адрес веб-сервера: 85.21.x.x   интерфейс rl1
Пинг исходящий фрагментируемый:
Внутренний интерфейс сервера доступа:
tcpdump: listening on fxp0
18:39:29.130401 192.168.15.15 > 85.21.x.x: icmp: echo request (ttl 255, id 1898, len 1496)
18:39:29.144098 85.21.x.x > 192.168.15.15: icmp: echo reply (ttl 246, id 19214, len 1496)
Внешний интерфейс сервера доступа:
tcpdump: listening on ng0
18:39:35.804524 89.179.x.x > 85.21.x.x: icmp: echo request (frag 1916:1440@0+) (ttl 254, len 1460)
18:39:35.804596 89.179.x.x > 85.21.x.x: icmp (frag 1916:36@1440) (ttl 254, len 56)
18:39:35.816119 85.21.x.x > 89.179.x.x: icmp: echo reply (wrong icmp csum) (frag 19305:40@0+) (ttl 247, len 60)
18:39:35.817645 85.21.x.x > 89.179.x.x: icmp (frag 19305:1436@40) (ttl 247, len 1456)
Удаленный веб-сервер:
tcpdump: listening on rl1
18:47:21.509364 89.179.x.x > 85.21.x.x: icmp: echo request (ttl 246, id1898, len 1496)
18:47:21.509573 85.21.x.x > 89.179.x.x: icmp: echo reply (ttl 255, id 19214, len 1496)

Непроходящее исходящее соединение:
Удаленный WEB-сервер:
16:36:41.365108 89.179.x.x.1955 > 85.21.x.x.80: S [tcp sum ok] 2949227298:2949227298(0) win 14600 <mss 1456,nop,wscale,nop,nop,sackOK> (ttl 244, id 17880, len 52)
16:36:41.365346 85.21.x.x.80 > 89.179.x.x.1955: S [tcp sum ok] 1033236390:1033236390(0) ack 2949227299 win 65535 <mss 1460,nop,wscale 0> (DF) (ttl 255,id 62643, len 48)
16:36:41.378741 89.179.x.x.1955 > 85.21.x.x.80: . [tcp sum ok] ack 1 win 15620 (ttl 244, id 17882, len 40)
16:36:41.386167 89.179.x.x.1955 > 85.21.x.x.80: P 1:243(242) ack 1 win 15620 (ttl 244, id 17883, len 282)
16:36:41.386347 85.21.x.x.80 > 89.179.x.x.1955: . [tcp sum ok] ack 243 win 65535 (DF) (ttl 255, id 62644, len 40)
16:36:41.388123 85.21.x.x.80 > 89.179.x.x.1955: . 1:1457(1456) ack 243 win 65535 (DF) (ttl 255, id 62645, len 1496)
16:36:41.388189 85.21.x.x.80 > 89.179.x.x.1955: . 1457:2913(1456) ack 243 win 65535 (DF) (ttl 255, id 62646, len 1496)
16:36:42.387280 85.21.x.x.80 > 89.179.x.x.1955: . 1:1457(1456) ack 243 win 65535 (DF) (ttl 255, id 62668, len 1496)
16:36:44.586908 85.21.x.x.80 > 89.179.x.x.1955: . 1:1457(1456) ack 243 win 65535 (DF) (ttl 255, id 62771, len 1496)
16:36:48.786184 85.21.x.x.80 > 89.179.x.x.1955: . 1:1457(1456) ack 243 win 65535 (DF) (ttl 255, id 62893, len 1496)
Сервер доступа:
16:28:48.218500 89.179.x.x.1955 > 85.21.x.x.80: S [tcp sum ok] 2949227298:2949227298(0) win 14600 <mss 1456,nop,wscale 0,nop,nop,sackOK> (ttl 254, id 17880, len 52)
16:28:48.226847 85.21.x.x.80 > 89.179.x.x.1955: S [tcp sum ok] 1033236390:1033236390(0) ack 2949227299 win 65535 <mss 1420,nop,wscale 0> (DF) (ttl 245,id 62643, len 48)
16:28:48.231698 89.179.x.x.1955 > 85.21.x.x.80: . [tcp sum ok] ack 1 win 15620 (ttl 254, id 17882, len 40)
16:28:48.238749 89.179.x.x.1955 > 85.21.x.x.80: P 1:243(242) ack 1 win 15620 (ttl 254, id 17883, len 282)
16:28:48.247600 85.21.x.x.80 > 89.179.x.x.1955: . [tcp sum ok] ack 243 win 65535 (DF) (ttl 245, id 62644, len 40)
16:29:05.896532 89.179.x.x.1955 > 85.21.x.x.80: R [tcp sum ok] 243:243(0) ack 1 win 0 (ttl 254, id 17905, len 40)
Ответы pptp провайдера  веб-серверу, на которые он не реагирует:
17:36:21.121094 85.21.17.33 > 85.21.x.x: icmp: 89.179.x.x unreachable - need to frag (mtu 1460) (ttl 248, id 11500, len 56)
....и т.д.....
После изменения MTU на удаленном вебсервере на 1460 сразу начинает отлично загружаться вся страница:
Удаленный веб-сервер:
16:43:04.261243 89.179.x.x.1974 > 85.21.x.x.80: S [tcp sum ok] 2780101647:2780101647(0) win 14600 <mss 1456,nop,wscale 0,nop,nop,sackOK> (ttl 244, id 18231, len 52)
16:43:04.261494 85.21.x.x.80 > 89.179.x.x.1974: S [tcp sum ok] 2909055853:2909055853(0) ack 2780101648 win 65535 <mss 1420,nop,wscale 0> (DF) (ttl 255,id 18782, len 48)
16:43:04.273510 89.179.x.x.1974 > 85.21.x.x.80: . [tcp sum ok] ack 1 win 15620 (ttl 244, id 18233, len 40)
16:43:04.293690 89.179.x.x.1974 > 85.21.x.x.80: P 1:243(242) ack 1 win 15620 (ttl 244, id 18234, len 282)
16:43:04.293905 85.21.x.x.80 > 89.179.x.x.1974: . [tcp sum ok] ack 243 win 65535 (DF) (ttl 255, id 18783, len 40)
16:43:04.295692 85.21.x.x.80 > 89.179.x.x.1974: . 1:1421(1420) ack 243 win 65535 (DF) (ttl 255, id 18784, len 1460)
16:43:04.295760 85.21.x.x.80 > 89.179.x.x.1974: . 1421:2841(1420) ack 243 win 65535 (DF) (ttl 255, id 18785, len 1460)
16:43:04.318118 89.179.x.x.1974 > 85.21.x.x.80: . [tcp sum ok] ack 2841win 15620 (ttl 244, id 18236, len 40)
16:43:04.318323 85.21.x.x.80 > 89.179.x.x.1974: . 2841:4261(1420) ack 243 win 65535 (DF) (ttl 255, id 18788, len 1460)
16:43:04.318361 85.21.x.x.80 > 89.179.x.x.1974: . 4261:5681(1420) ack 243 win 65535 (DF) (ttl 255, id 18789, len 1460)
16:43:04.318398 85.21.x.x.80 > 89.179.x.x.1974: . 5681:7101(1420) ack 243 win 65535 (DF) (ttl 255, id 18790, len 1460)
16:43:04.337070 89.179.x.x.1974 > 85.21.x.x.80: . [tcp sum ok] ack 5681win 15620 (ttl 244, id 18238, len 40)
16:43:04.337387 85.21.x.x.80 > 89.179.x.x.1974: P 7101:7548(447) ack 243 win 65535 (DF) (ttl 255, id 18791, len 487)
16:43:04.347811 89.179.x.x.1974 > 85.21.x.x.80: . [tcp sum ok] ack 7548win 15620 (ttl 244, id 18239, len 40)
16:43:04.414215 89.179.x.x.1975 > 85.21.x.x.80: S [tcp sum ok] 3507368160:3507368160(0) win 14600 <mss 1456,nop,wscale 0,nop,nop,sackOK> (ttl 244, id 18240, len 52)
16:43:04.414433 85.21.x.x.80 > 89.179.x.x.1975: S [tcp sum ok] 4162152195:4162152195(0) ack 3507368161 win 65535 <mss 1420,nop,wscale 0> (DF) (ttl 255,id 18792, len 48)
16:43:04.424305 89.179.x.x.1975 > 85.21.x.x.80: . [tcp sum ok] ack 1 win 15620 (ttl 244, id 18242, len 40)
16:43:04.437838 89.179.x.x.1975 > 85.21.x.x.80: P 1:287(286) ack 1 win 15620 (ttl 244, id 18243, len 326)
16:43:04.438046 85.21.x.x.80 > 89.179.x.x.1975: . [tcp sum ok] ack 287 win 65535 (DF) (ttl 255, id 18794, len 40)
16:43:04.438912 85.21.x.x.80 > 89.179.x.x.1975: . 1:1421(1420) ack 287 win 65535 (DF) (ttl 255, id 18795, len 1460)
...............и т.д...........
Сервер доступа:
16:35:11.154233 89.179.x.x.1974 > 85.21.x.x.80: S [tcp sum ok] 2780101647:2780101647(0) win 14600 <mss 1456,nop,wscale 0,nop,nop,sackOK> (ttl 254, id 18231, len 52)
16:35:11.160945 85.21.x.x.80 > 89.179.x.x.1974: S [tcp sum ok] 2909055853:2909055853(0) ack 2780101648 win 65535 <mss 1420,nop,wscale 0> (DF) (ttl 245,id 18782, len 48)
16:35:11.166939 89.179.x.x.1974 > 85.21.x.x.80: . [tcp sum ok] ack 1 win 15620 (ttl 254, id 18233, len 40)
16:35:11.185946 89.179.x.x.1974 > 85.21.x.x.80: P 1:243(242) ack 1 win 15620 (ttl 254, id 18234, len 282)
16:35:11.193766 85.21.x.x.80 > 89.179.x.x.1974: . [tcp sum ok] ack 243 win 65535 (DF) (ttl 245, id 18783, len 40)
16:35:11.198988 85.21.x.x.80 > 89.179.x.x.1974: . 1:1421(1420) ack 243 win 65535 (DF) (ttl 245, id 18784, len 1460)
16:35:11.199249 85.21.x.x.80 > 89.179.x.x.1974: . 1421:2841(1420) ack 243 win 65535 (DF) (ttl 245, id 18785, len 1460)
16:35:11.211520 89.179.x.x.1974 > 85.21.x.x.80: . [tcp sum ok] ack 2841win 15620 (ttl 254, id 18236, len 40)
16:35:11.221249 85.21.x.x.80 > 89.179.x.x.1974: . 2841:4261(1420) ack 243 win 65535 (DF) (ttl 245, id 18788, len 1460)
16:35:11.221505 85.21.x.x.80 > 89.179.x.x.1974: . 4261:5681(1420) ack 243 win 65535 (DF) (ttl 245, id 18789, len 1460)
16:35:11.221691 85.21.x.x.80 > 89.179.x.x.1974: . 5681:7101(1420) ack 243 win 65535 (DF) (ttl 245, id 18790, len 1460)
16:35:11.231233 89.179.x.x.1974 > 85.21.x.x.80: . [tcp sum ok] ack 5681 win 15620 (ttl 254, id 18238, len 40)
16:35:11.237153 85.21.x.x.80 > 89.179.x.x.1974: P 7101:7548(447) ack 243 win 65535 (DF) (ttl 245, id 18791, len 487)
16:35:11.241853 89.179.x.x.1974 > 85.21.x.x.80: . [tcp sum ok] ack 7548 win 15620 (ttl 254, id 18239, len 40)
16:35:11.307659 89.179.x.x.1975 > 85.21.x.x.80: S [tcp sum ok] 3507368160:3507368160(0) win 14600 <mss 1456,nop,wscale 0,nop,nop,sackOK> (ttl 254, id 18240, len 52)
16:35:11.313757 85.21.x.x.80 > 89.179.x.x.1975: S [tcp sum ok] 4162152195:4162152195(0) ack 3507368161 win 65535 <mss 1420,nop,wscale 0> (DF) (ttl 245,id 18792, len 48)
16:35:11.318195 89.179.x.x.1975 > 85.21.x.x.80: . [tcp sum ok] ack 1 win 15620 (ttl 254, id 18242, len 40)
16:35:11.330728 89.179.x.x.1975 > 85.21.x.x.80: P 1:287(286) ack 1 win 15620 (ttl 254, id 18243, len 326)
16:35:11.337276 85.21.x.x.80 > 89.179.x.x.1975: . [tcp sum ok] ack 287 win 65535 (DF) (ttl 245, id 18794, len 40)
16:35:11.341855 85.21.x.x.80 > 89.179.x.x.1975: . 1:1421(1420) ack 287 win 65535 (DF) (ttl 245, id 18795, len 1460)
............и т.д...............

После возврата MTU вебсервера к значению 1500, он всё равно больше не посылал пакеты более 1460.  Перезапуск apache не помог, видимо эта настройка была запомнена на уровне протоколов.
down/up интерфейса помог восстановить реальное значение MTU (может повысить MTU возможно только после перезапуска интерфейса, в отличие от понижения?)
Запрос с самого сервера доступа.
Трафик показан на веб-сервере (т.к. на сервере доступа он не отличается - пакеты проходят, т.к. они не более 1460 байт):

17:14:22.765875 89.179.x.x.1542 > 85.21.x.x.80: S [tcp sum ok] 1632167149:1632167149(0) win 65535 <mss 1420> (DF) (ttl 247, id 7401, len 44)
17:14:22.767301 85.21.x.x.80 > 89.179.x.x.1542: S [tcp sum ok] 1647898909:1647898909(0) ack 1632167150 win 65535 <mss 1460> (DF) (ttl 255, id 12507, len 44)
17:14:22.774881 89.179.x.x.1542 > 85.21.x.x.80: . [tcp sum ok] ack 1 win 65535 (DF) (ttl 247, id 7413, len 40)
17:14:31.127249 89.179.x.x.1542 > 85.21.x.x.80: P [tcp sum ok] 1:17(16)ack 1 win 65535 (DF) (ttl 247, id 7539, len 56)
17:14:31.127450 85.21.x.x.80 > 89.179.x.x.1542: . [tcp sum ok] ack 17 win 65535 (DF) (ttl 255, id 12990, len 40)
17:14:32.443786 89.179.x.x.2121 > 85.21.x.x.53: [udp sum ok]  935+ SRV?_sip._udp.sip.corbina.ru. (42) (ttl 246, id 25121, len 70)
17:14:32.444302 85.21.x.x.53 > 89.179.x.x.2121:  935 NXDomain 0/1/0 (105) (ttl 255, id 13017, len 133)
17:14:38.035614 89.179.x.x.1542 > 85.21.x.x.80: P [tcp sum ok] 17:40(23) ack 1 win 65535 (DF) (ttl 247, id 7638, len 63)
17:14:38.035799 85.21.x.x.80 > 89.179.x.x.1542: . [tcp sum ok] ack 40 win 65535 (DF) (ttl 255, id 13199, len 40)
17:14:38.784220 89.179.x.x.1542 > 85.21.x.x.80: P [tcp sum ok] 40:42(2)ack 1 win 65535 (DF) (ttl 247, id 7650, len 42)
17:14:38.784666 85.21.x.x.80 > 89.179.x.x.1542: . [tcp sum ok] ack 42 win 65535 (DF) (ttl 255, id 13205, len 40)
17:14:38.787398 85.21.x.x.80 > 89.179.x.x.1542: . 1:1421(1420) ack 42 win 65535 (DF) (ttl 255, id 13206, len 1460)
17:14:38.787455 85.21.x.x.80 > 89.179.x.x.1542: . 1421:2841(1420) ack 42 win 65535 (DF) (ttl 255, id 13207, len 1460)
17:14:38.794868 89.179.x.x.1542 > 85.21.x.x.80: . [tcp sum ok] ack 1421 win 65535 (DF) (ttl 247, id 7655, len 40)
17:14:38.795104 85.21.x.x.80 > 89.179.x.x.1542: . 2841:4261(1420) ack 42 win 65535 (DF) (ttl 255, id 13210, len 1460)
17:14:38.795142 85.21.x.x.80 > 89.179.x.x.1542: . 4261:5681(1420) ack 42 win 65535 (DF) (ttl 255, id 13211, len 1460)
17:14:38.796613 89.179.x.x.1542 > 85.21.x.x.80: . [tcp sum ok] ack 2841 win 65535 (DF) (ttl 247, id 7659, len 40)
17:14:38.796801 85.21.x.x.80 > 89.179.x.x.1542: . 5681:7101(1420) ack 42 win 65535 (DF) (ttl 255, id 13212, len 1460)
17:14:38.796832 85.21.x.x.80 > 89.179.x.x.1542: P 7101:7491(390) ack 42 win 65535 (DF) (ttl 255, id 13213, len 430)
17:14:38.802785 89.179.x.x.1542 > 85.21.x.x.80: . [tcp sum ok] ack 4261 win 65535 (DF) (ttl 247, id 7665, len 40)
17:14:38.805069 89.179.x.x.1542 > 85.21.x.x.80: . [tcp sum ok] ack 5681 win 65535 (DF) (ttl 247, id 7671, len 40)
17:14:38.805332 89.179.x.x.1542 > 85.21.x.x.80: . [tcp sum ok] ack 7101 win 65535 (DF) (ttl 247, id 7673, len 40)
17:14:38.805410 89.179.x.x.1542 > 85.21.x.x.80: . [tcp sum ok] ack 7491 win 65535 (DF) (ttl 247, id 7675, len 40)
17:14:55.119691 85.21.x.x.80 > 89.179.x.x.1542: F [tcp sum ok] 7491:7491(0) ack 42 win 65535 (DF) (ttl 255, id 13455, len 40)
17:14:55.123882 89.179.x.x.1542 > 85.21.x.x.80: . [tcp sum ok] ack 7492
Входящий трафик на сервер доступа с удаленного веб-сервера (поменялись ролями). Показано полное HTTP соединение до разрыва сервером:
На веб-сервере:
19:56:39.632044 85.21.x.x.4820 > 89.179.x.x.80: S [tcp sum ok] 1093746367:1093746367(0) win 65535 <mss 1460,nop,wscale 0,nop,nop,timestamp 84658660 0> (DF) [tos 0x10]  (ttl 255, id 39951, len 60)
19:56:39.640613 89.179.x.x.80 > 85.21.x.x.4820: S [tcp sum ok] 2168287178:2168287178(0) ack 1093746368 win 65535 <mss 1420> (DF) (ttl 247, id 34017, len 44)
19:56:39.641029 85.21.x.x.4820 > 89.179.x.x.80: . [tcp sum ok] ack 1 win 65535 (DF) [tos 0x10]  (ttl 255, id 39953, len 40)
19:56:47.418410 85.21.x.x.4820 > 89.179.x.x.80: P [tcp sum ok] 1:25(24)ack 1 win 65535 (DF) [tos 0x10]  (ttl 255, id 40071, len 64)
19:56:47.425733 89.179.x.x.80 > 85.21.x.x.4820: . [tcp sum ok] ack 25 win 65535 (DF) (ttl 247, id 34125, len 40)
19:56:52.702467 85.21.x.x.4820 > 89.179.x.x.80: P [tcp sum ok] 25:48(23) ack 1 win 65535 (DF) [tos 0x10]  (ttl 255, id 40178, len 63)
19:56:52.710336 89.179.x.x.80 > 85.21.x.x.4820: . [tcp sum ok] ack 48 win 65535 (DF) (ttl 247, id 34276, len 40)
19:56:53.635142 85.21.x.x.4820 > 89.179.x.x.80: P [tcp sum ok] 48:50(2)ack 1 win 65535 (DF) [tos 0x10]  (ttl 255, id 40191, len 42)
19:56:53.640337 89.179.x.x.80 > 85.21.x.x.4820: . [tcp sum ok] ack 50 win 65535 (DF) (ttl 247, id 34281, len 40)
19:56:53.645500 89.179.x.x.80 > 85.21.x.x.4820: . 1:1421(1420) ack 50 win 65535 (DF) (ttl 247, id 34283, len 1460)
19:56:53.645647 89.179.x.x.80 > 85.21.x.x.4820: . 1421:2841(1420) ack 50 win 65535 (DF) (ttl 247, id 34285, len 1460)
19:56:53.645893 85.21.x.x.4820 > 89.179.x.x.80: . [tcp sum ok] ack 1421win 65320 (DF) [tos 0x10]  (ttl 255, id 40194, len 40)
19:56:53.648894 85.21.x.x.4820 > 89.179.x.x.80: . [tcp sum ok] ack 2841win 65320 (DF) [tos 0x10]  (ttl 255, id 40197, len 40)
19:56:53.655944 89.179.x.x.80 > 85.21.x.x.4820: . 2841:4261(1420) ack 50 win 65535 (DF) (ttl 247, id 34289, len 1460)
19:56:53.656096 89.179.x.x.80 > 85.21.x.x.4820: . 4261:5681(1420) ack 50 win 65535 (DF) (ttl 247, id 34291, len 1460)
19:56:53.656190 85.21.x.x.4820 > 89.179.x.x.80: . [tcp sum ok] ack 4261win 65320 (DF) [tos 0x10]  (ttl 255, id 40200, len 40)
19:56:53.656714 89.179.x.x.80 > 85.21.x.x.4820: P 5681:5778(97) ack 50 win 65535 (DF) (ttl 247, id 34294, len 137)
19:56:53.657963 85.21.x.x.4820 > 89.179.x.x.80: . [tcp sum ok] ack 5681win 65320 (DF) [tos 0x10]  (ttl 255, id 40203, len 40)
19:56:53.659511 85.21.x.x.4820 > 89.179.x.x.80: . [tcp sum ok] ack 5778win 65535 (DF) [tos 0x10]  (ttl 255, id 40206, len 40)
19:57:09.704783 89.179.x.x.80 > 85.21.x.x.4820: F [tcp sum ok] 5778:5778(0) ack 50 win 65535 (DF) (ttl 247, id 34572, len 40)
19:57:09.704962 85.21.x.x.4820 > 89.179.x.x.80: . [tcp sum ok] ack 5779win 65535 (DF) [tos 0x10]  (ttl 255, id 40727, len 40)
19:57:09.705255 85.21.x.x.4820 > 89.179.x.x.80: F [tcp sum ok] 50:50(0)ack 5779 win 65535 (DF) [tos 0x10]  (ttl 255, id 40728, len 40)
19:57:09.710296 89.179.x.x.80 > 85.21.x.x.4820: . [tcp sum ok] ack 51 win 65535 (DF) (ttl 247, id 34576, len 40)
На сервере доступа (там запущен apache):
19:48:47.666118 85.21.x.x.4820 > 89.179.x.x.80: S [tcp sum ok] 1093746367:1093746367(0) win 65535 <mss 1420,nop,wscale 0,nop,nop,timestamp 84658660 0> (DF) (ttl 247, id 39951, len 60)
19:48:47.666383 89.179.x.x.80 > 85.21.x.x.4820: S [tcp sum ok] 2168287178:2168287178(0) ack 1093746368 win 65535 <mss 1420> (DF) (ttl 255, id 34017, len 44)
19:48:47.674687 85.21.x.x.4820 > 89.179.x.x.80: . [tcp sum ok] ack 1 win 65535 (DF) (ttl 247, id 39953, len 40)
19:48:55.452729 85.21.x.x.4820 > 89.179.x.x.80: P [tcp sum ok] 1:25(24) ack 1 win 65535 (DF) (ttl 247, id 40071, len 64)
19:48:55.453131 89.179.x.x.80 > 85.21.x.x.4820: . [tcp sum ok] ack 25 win 65535 (DF) (ttl 255, id 34125, len 40)
19:49:00.737469 85.21.x.x.4820 > 89.179.x.x.80: P [tcp sum ok] 25:48(23) ack 1 win 65535 (DF) (ttl 247, id 40178, len 63)
19:49:00.737712 89.179.x.x.80 > 85.21.x.x.4820: . [tcp sum ok] ack 48 win 65535 (DF) (ttl 255, id 34276, len 40)
19:49:01.668941 85.21.x.x.4820 > 89.179.x.x.80: P [tcp sum ok] 48:50(2) ack 1 win 65535 (DF) (ttl 247, id 40191, len 42)
19:49:01.669188 89.179.x.x.80 > 85.21.x.x.4820: . [tcp sum ok] ack 50 win 65535 (DF) (ttl 255, id 34281, len 40)
19:49:01.670561 89.179.x.x.80 > 85.21.x.x.4820: . 1:1421(1420) ack 50 win 65535 (DF) (ttl 255, id 34283, len 1460)
19:49:01.670718 89.179.x.x.80 > 85.21.x.x.4820: . 1421:2841(1420) ack 50 win 65535 (DF) (ttl 255, id 34285, len 1460)
19:49:01.679831 85.21.x.x.4820 > 89.179.x.x.80: . [tcp sum ok] ack 1421 win 65320 (DF) (ttl 247, id 40194, len 40)
19:49:01.680120 89.179.x.x.80 > 85.21.x.x.4820: . 2841:4261(1420) ack 50 win 65535 (DF) (ttl 255, id 34289, len 1460)
19:49:01.680202 89.179.x.x.80 > 85.21.x.x.4820: . 4261:5681(1420) ack 50 win 65535 (DF) (ttl 255, id 34291, len 1460)
19:49:01.682829 85.21.x.x.4820 > 89.179.x.x.80: . [tcp sum ok] ack 2841 win 65320 (DF) (ttl 247, id 40197, len 40)
19:49:01.683000 89.179.x.x.80 > 85.21.x.x.4820: P 5681:5778(97) ack 50 win 65535 (DF) (ttl 255, id 34294, len 137)
19:49:01.690261 85.21.x.x.4820 > 89.179.x.x.80: . [tcp sum ok] ack 4261 win 65320 (DF) (ttl 247, id 40200, len 40)
19:49:01.692222 85.21.x.x.4820 > 89.179.x.x.80: . [tcp sum ok] ack 5681 win 65320 (DF) (ttl 247, id 40203, len 40)
19:49:01.694005 85.21.x.x.4820 > 89.179.x.x.80: . [tcp sum ok] ack 5778 win 65535 (DF) (ttl 247, id 40206, len 40)
19:49:17.735512 89.179.x.x.80 > 85.21.x.x.4820: F [tcp sum ok] 5778:5778(0) ack 50 win 65535 (DF) (ttl 255, id 34572, len 40)
19:49:17.740112 85.21.x.x.4820 > 89.179.x.x.80: . [tcp sum ok] ack 5779 win 65535 (DF) (ttl 247, id 40727, len 40)
19:49:17.740403 85.21.x.x.4820 > 89.179.x.x.80: F [tcp sum ok] 50:50(0)ack 5779 win 65535 (DF) (ttl 247, id 40728, len 40)
19:49:17.740561 89.179.x.x.80 > 85.21.x.x.4820: . [tcp sum ok] ack 51 win 65535 (DF) (ttl 255, id 34576, len 40)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

10. "Причина найдена,  решение нет!"

Сообщение от xOr (ok) on 07-Окт-07, 03:33

Решил проблему с MSS установкой tcpmssd.
Опция в mpd.conf   set iface enable tcpmssfix  почему-то заменяет MSS только для входящих.  Провайдер кстати это вообще не делает.
Обсуждение уже этой проблемы тут: http://www.opennet.ru/openforum/vsluhforumID1/76635.html

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

11. "Причина найдена,  решение нет!"

Сообщение от stec (??) on 19-Дек-07, 04:33

>Решил проблему с MSS установкой tcpmssd.
>Опция в mpd.conf   set iface enable tcpmssfix  почему-то заменяет
>MSS только для входящих.  Провайдер кстати это вообще не делает.
>
>
>Обсуждение уже этой проблемы тут: http://www.opennet.ru/openforum/vsluhforumID1/76635.html
Пинг (icmp )сообщения не выставляет бит DF запрет фрагментации.
втупает механиз согласования максимального Mtu по сети от хоста до удаленного вебсервера  примеру. Вероятно на сети они не проходят и Mtu согласовать не удается. MSS это обход проблемы невозможности согласования mtu за счет занижения объема данных переданных в каждом пакете. Примерно так.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема

Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Непонятная проблема видимо с фрагментацией пакетов"
Сообщение от xOr (ok) on 01-Окт-07, 23:21
Наверное смутил всех объемом логов. Всегда просили максимально подробно описать проблему, видимо переборщил. Есть хоть какие-нибудь мнения по этой проблеме?
Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	2. "Непонятная проблема видимо с фрагментацией пакетов"
	Сообщение от konst (??) on 01-Окт-07, 23:50
	>Наверное смутил всех объемом логов. Всегда просили максимально подробно описать проблему, >видимо переборщил. > >Есть хоть какие-нибудь мнения по этой проблеме? Здесь уже были подобные темы недавно: Напр. http://www.opennet.ru/openforum/vsluhforumID1/48524.html http://www.opennet.ru/openforum/vsluhforumID15/1261.html Из одной из тем: Попробуй в mpd.conf указать опцию: set iface enable tcpmssfix
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	3. "Непонятная проблема видимо с фрагментацией пакетов"
	Сообщение от xOr (??) on 02-Окт-07, 02:25
	>>Есть хоть какие-нибудь мнения по этой проблеме? > >Здесь уже были подобные темы недавно: >Напр. >http://www.opennet.ru/openforum/vsluhforumID1/48524.html >http://www.opennet.ru/openforum/vsluhforumID15/1261.html > >Из одной из тем: > >Попробуй в mpd.conf указать опцию: set iface enable tcpmssfix У меня стоит эта опция (конфиг в первом сообщении). По первой ссылке там вообще была раздача через MPD, а у меня доступ. А в отличие от темы 2-й ссылки, с самой системы всё отлично работает (а также через если клиенты работают через прокси на этой системе) Не работает транзитом. Также когда на клиенте настраивали внешний (в инете) прокси, то тоже как ни странно лучше работало (но не тестили почти).
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	4. "Непонятная проблема видимо с фрагментацией пакетов"
	Сообщение от xOr (??) on 03-Окт-07, 12:43
	Настроил на другом сервере. Там FreeBSD 4.9 Всё то же самое. Картинки грузятся очень долго, большинство не грузится (в тесте numion.com). Этот же сервер является роутером с nat через обычный Ethernet канал и через DSL маршрутизатор (то есть всего на нем 3 аплинка). Они работают нормально, только через PPTP проблемы. Настройки для всех похожие, nat + fwd на нужный шлюз в зависимости от адреса источника (задаваемого натом). При подключении с виндозного компа а также с самого аппаратного роутера, такой проблемы нет.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	5. "Непонятная проблема видимо с фрагментацией пакетов"
	Сообщение от frey (ok) on 03-Окт-07, 12:58
	Настройки mpd - это хорошо, но действительно ли mtu на интерфейсе меняется? Сделай руками ifconfig pppX mtu 1460 и посмотри результат.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	6. "Непонятная проблема видимо с фрагментацией пакетов"
	Сообщение от xOr (ok) on 03-Окт-07, 22:50
	>Настройки mpd - это хорошо, но действительно ли mtu на интерфейсе меняется? > >Сделай руками ifconfig pppX mtu 1460 и посмотри результат. Вроде меняется: ng0: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> mtu 1460 inet6 fe80::251:ff:fe00:8f%ng0 prefixlen 64 scopeid 0x7 inet 89.x.x.x --> 192.168.x.x netmask 0xffffffff И в логах MPD этот факт тоже отображен: mpd: [vpn0] setting interface ng0 MTU to 1460 bytes Сделал вручную, ничего не изменилось. Впрочим, исходящие HTTP запросы и так маленькие, они бы по любому проскочили. Кроме того, уже смотрел на интерфейсе tcpdump'ом - исх. пакеты фрагментируются правильно. А что происходит со входящими на той стороне - никто не знает. Но всё таки они сами запрашивали 1460.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	7. "Непонятная проблема видимо с фрагментацией пакетов"
	Сообщение от xOr (??) on 03-Окт-07, 23:59
	А есть ли данные по количеству соединений, одновременно обслуживаемых натом? (natd). У меня есть подозрение, что нат просто отбрасывает новые подключения. У меня несколько тысяч одновременных соединений (благодаря файлообменным системам). Никаких настроек типа размера таблицы, в самом natd нет. Может быть это зависит от переменных ядра, или вообще неограничено?
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	8. "Непонятная проблема видимо с фрагментацией пакетов"
	Сообщение от frey (ok) on 04-Окт-07, 15:11
	В линуксе /proc/sys/net/nf_conntrack_max, зависит от количества памяти, устанавливается через sysctl. Например при гб виртуальной памяти - 32768 соединений. Как в бсд, не могу сказать.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	10. "Причина найдена, решение нет!"
	Сообщение от xOr (ok) on 07-Окт-07, 03:33
	Решил проблему с MSS установкой tcpmssd. Опция в mpd.conf set iface enable tcpmssfix почему-то заменяет MSS только для входящих. Провайдер кстати это вообще не делает. Обсуждение уже этой проблемы тут: http://www.opennet.ru/openforum/vsluhforumID1/76635.html
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	11. "Причина найдена, решение нет!"
	Сообщение от stec (??) on 19-Дек-07, 04:33
	>Решил проблему с MSS установкой tcpmssd. >Опция в mpd.conf set iface enable tcpmssfix почему-то заменяет >MSS только для входящих. Провайдер кстати это вообще не делает. > > >Обсуждение уже этой проблемы тут: http://www.opennet.ru/openforum/vsluhforumID1/76635.html Пинг (icmp )сообщения не выставляет бит DF запрет фрагментации. втупает механиз согласования максимального Mtu по сети от хоста до удаленного вебсервера примеру. Вероятно на сети они не проходят и Mtu согласовать не удается. MSS это обход проблемы невозможности согласования mtu за счет занижения объема данных переданных в каждом пакете. Примерно так.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору

Архив \| Удалить	Индекс форумов \| Темы \| Пред. тема \| След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 \| 2 \| 3 \| 4 \| 5 ] [Рекомендовать для помещения в FAQ]