информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
За кого нас держат?Все любят медГде водятся OGRы
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Очередное исследование 19 миллиардов... 
 Оптимизация ввода-вывода как инструмент... 
 Зловреды выбирают Lisp и Delphi 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
если вы видите этот текст, отключите в настройках форума использование JavaScript
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
Ага, дело было так 04.06.03 19:27  Число просмотров: 996
Автор: PS <PS> Статус: Elderman
<"чистая" ссылка> <обсуждение закрыто>
1. Засылаем пакет (610 байт)
2. Он лежит в буфере сокета (видимо ACK действительно нет. почему ?)
3. Засылаем второй пакет (610 байт). Теперь у нас там лежит 1220. Жду...
4. Минут через 15 говорю netstat - опа ! А соединения уже нет. Кстати, на другой стороне (в другом городе нашей необъятной Родины) netstat утверждает что ESTABLISHED - весело.
5. Пытаюсь записать туда третий пакет. И только сейчас получаю облом в виде любимого SIGPIPE ! Ну слава богу, хоть так просигнализировал.

Итого: два пакета якобы ушли, на самом деле были потерянны. И еще один явно не ушел.

И как с этим работать ?
<programming>
Еще одна фигня с send 04.06.03 18:29  
Автор: PS <PS> Статус: Elderman
Отредактировано 04.06.03 18:33  Количество правок: 1
<"чистая" ссылка> <обсуждение закрыто>
Proto Recv-Q Send-Q Local Address Foreign Address (state)
tcp4 0 0 xxxx.4001 yyyy.1225 ESTABLISHED
tcp4 0 1220 xxxx.4000 yyyy1224 ESTABLISHED

В сокете на отправку лежат 1220 байт, и не уходят !

#define SOCKET_ERROR -1
...
	int flag;
	flag = 0;	

	int res = send( m_sock_writer, buffer, packetSize + sizeof(long), flag );
	if( res == SOCKET_ERROR )
	{
		m_log->Msg( 1, "WARNING ! Send socket was closed ! Restart your client !\n" );

		// We will restart writer socket in READ function !
		// READ function always catch error in connection, becouse stay on recv()
	
		delete[] buffer;
		return;
	}
	m_log->Msg( 0, "WRITER: OK.\n" );

---

Вот так, send() мне не возвращает -1. Типа все отправил, все ок. А на самом деле данные лежат в очереди, и их не могут получить.

Кто с такой фигней встречался ? Из-за чего может быть ?

P.S. OS: FreeBSD
P.P.S: блин, ну почему в виндах ни разу такой фигни не возникало !
Требуется помощь... 06.06.03 14:17  
Автор: PS <PS> Статус: Elderman
<"чистая" ссылка> <обсуждение закрыто>
В продолжение топика.
Ситуация сложиласть следующим образом:
Есть некий хост CCC, за ним сидят две машины AAA и BBB.
Если мы запустим клиент с машины AAA, то описанной в топике проблеммы не будет. Если запусим с BBB то проблемма возникает стабильно.
Коннект клиентов идет к некому хосту DDD.

Было произведенно сравнение параметров ядра машин AAA и BBB.
В листиге: AAA это <
BBB это >

И так < - работает нормально
> - теряет соединение после таймаута.

Кто знает за что отвечают нижеприведенные настройки, будте добры написать. И какая из настроек может вызывать проблемму.


< net.inet.ip.forwarding: 1
---
> net.inet.ip.forwarding: 0
24a25,35
> net.inet.ip.dummynet.hash_size: 64
> net.inet.ip.dummynet.curr_time: 1105839154
> net.inet.ip.dummynet.ready_heap: 0
> net.inet.ip.dummynet.extract_heap: 0
> net.inet.ip.dummynet.searches: 0
> net.inet.ip.dummynet.search_steps: 0
> net.inet.ip.dummynet.expire: 1
> net.inet.ip.dummynet.max_chain_len: 16
> 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
29c40
< net.inet.ip.fw.verbose_limit: 0
---
> net.inet.ip.fw.verbose_limit: 100
32c43
< net.inet.ip.fw.dyn_count: 107
---
> net.inet.ip.fw.dyn_count: 0
34c45
< net.inet.ip.fw.static_count: 34
---
> net.inet.ip.fw.static_count: 1
42,44c53
< net.inet.ip.maxfragpackets: 79
< net.inet.ip.maxfragsperpacket: 16
< net.inet.ip.sendsourcequench: 0
---
> net.inet.ip.maxfragpackets: 632
52c61
< net.inet.tcp.rfc1323: 0
---
> net.inet.tcp.rfc1323: 1
70c79
< net.inet.tcp.pcbcount: 22
---
> net.inet.tcp.pcbcount: 15
77d85
< net.inet.tcp.inflight_stab: 20
120c128
< net.link.generic.system.ifcount: 8
---
> net.link.generic.system.ifcount: 3
127a136,150
> net.link.ether.bridge_cfg:
> net.link.ether.bridge: 0
> net.link.ether.bridge_ipfw: 0
> net.link.ether.bridge_ipf: 0
> net.link.ether.bridge_ipfw_drop: 0
> net.link.ether.bridge_ipfw_collisions: 0
> net.link.ether.verbose: 0
> net.link.ether.bdg_split_pkts: 0
> net.link.ether.bdg_thru: 0
> net.link.ether.bdg_copied: 0
> net.link.ether.bdg_copy: 0
> net.link.ether.bdg_predict: 0
> net.link.ether.bdg_fw_avg: 0
> net.link.ether.bdg_fw_ticks: 0
> net.link.ether.bdg_fw_count: 0
Требуется помощь... 06.06.03 15:07  
Автор: NKritsky <Nickolay A. Kritsky> Статус: Elderman
<"чистая" ссылка> <обсуждение закрыто>
> В продолжение топика.
> Ситуация сложиласть следующим образом:
> Есть некий хост CCC, за ним сидят две машины AAA и BBB.
> Если мы запустим клиент с машины AAA, то описанной в топике
> проблеммы не будет. Если запусим с BBB то проблемма
> возникает стабильно.
> Коннект клиентов идет к некому хосту DDD.
>
> Было произведенно сравнение параметров ядра машин AAA и
> BBB.
> В листиге: AAA это <
> BBB это >
>
Вот за это спасибо. Такому челу и помочь приятно. Вот если бы ты ещё сказал, есть ли там ipf/ipfw и привел бы их правила...

> < net.inet.ip.forwarding: 1
> ---
> > net.inet.ip.forwarding: 0
Это - гейтовать или нет. Вряд ли оно.
> > net.inet.ip.dummynet.hash_size: 64
...
> > net.inet.ip.dummynet.red_max_pkt_size: 1500
Настройки dummynet'а могут в принципе гадить если траффик идет через кривые пайпы. Это задается в правилах ipfw
> < net.inet.ip.fw.verbose_limit: 0
> ---
> > net.inet.ip.fw.verbose_limit: 100
> 32c43
man ipfw, в данном случае роли не играет.
> < net.inet.ip.fw.dyn_count: 107
> ---
> > net.inet.ip.fw.dyn_count: 0
> 34c45
> < net.inet.ip.fw.static_count: 34
> ---
> > net.inet.ip.fw.static_count: 1
> 42,44c53
Судя по этим строчкам, на ААА стоит фаервол с 34 правилами. Кроме того там есть динамические правила. Но все это нас не колышет, так как на AAA проблем нету. На ВВВ правило одно. Что-то мне подсказывает что оно выглядит как
65535 allow ip from any to any
Выходит ipfw не гадит.
> < net.inet.ip.maxfragpackets: 79
> < net.inet.ip.maxfragsperpacket: 16
> < net.inet.ip.sendsourcequench: 0
> ---
> > net.inet.ip.maxfragpackets: 632
> 52c61
не должно колыхать.
> < net.inet.tcp.rfc1323: 0
> ---
> > net.inet.tcp.rfc1323: 1
> 70c79
Вот здесь может быть проблема. Я посмотрел по диагонали rfc1323 - "TCP Extensions for High Performance". Попробуй поменять этот oid
> < net.inet.tcp.pcbcount: 22
> ---
> > net.inet.tcp.pcbcount: 15
> 77d85
я думаю что это кол-во PCB. Из названия. Про PCB - по моему rfc0793
> < net.inet.tcp.inflight_stab: 20
> 120c128
не знаю. надо гуглить.
> < net.link.generic.system.ifcount: 8
> ---
> > net.link.generic.system.ifcount: 3
кол-во интерфейсов? не должно колыхать.
> 127a136,150
> > net.link.ether.bridge_cfg:
> > net.link.ether.bridge: 0
> > net.link.ether.bridge_ipfw: 0
> > net.link.ether.bridge_ipf: 0
> > net.link.ether.bridge_ipfw_drop: 0
> > net.link.ether.bridge_ipfw_collisions: 0
> > net.link.ether.verbose: 0
> > net.link.ether.bdg_split_pkts: 0
> > net.link.ether.bdg_thru: 0
> > net.link.ether.bdg_copied: 0
> > net.link.ether.bdg_copy: 0
> > net.link.ether.bdg_predict: 0
> > net.link.ether.bdg_fw_avg: 0
> > net.link.ether.bdg_fw_ticks: 0
> > net.link.ether.bdg_fw_count: 0
настройки бриджа. появляются если скомпилить ядро с опцией BRIDGE. но так как бридж задизаблен (net.link.ether.bridge: 0), не колышет.
Резюме.
tcpdump в зубы и сравнивай две сессии. Это не так уж много работы. А если хочется легких путей - попробуй тупо поменять net.inet.tcp.rfc1323
tcpdump :) 06.06.03 20:40  
Автор: PS <PS> Статус: Elderman
Отредактировано 06.06.03 23:34  Количество правок: 1
<"чистая" ссылка> <обсуждение закрыто>
Наконец то я продампил пакет. К сожалению дамп сделан только на серверной стороне.

Обозначения те же: AAA - работающий хост, BBB - не работающий хост, DDD - хост сервера.

Этот дамп можно даже не смотреть, сдесь все пучком:
18:49:23.660025 AAA.4429 > DDD.4001: S 2057889375:2057889375(0) win 57344 <mss 1460> (DF)
18:49:23.660115 DDD.4001 > AAA.4429: S 1197985352:1197985352(0) ack 2057889376 win 57344 <mss 1460> (DF)
18:49:23.840403 AAA.4429 > DDD.4001: . ack 1 win 58400 (DF)
18:49:23.885531 AAA.4430 > DDD.4000: S 4081744833:4081744833(0) win 57344 <mss 1460> (DF)
18:49:23.885574 DDD.4000 > AAA.4430: S 2376670431:2376670431(0) ack 4081744834 win 57344 <mss 1460> (DF)
18:49:24.053665 AAA.4430 > DDD.4000: . ack 1 win 58400 (DF)
18:49:24.191048 AAA.4429 > DDD.4001: P 1:8(7) ack 1 win 58400 (DF)
18:49:24.198336 DDD.4000 > AAA.4430: P 1:705(704) ack 1 win 58400 (DF)
18:49:24.286047 DDD.4001 > AAA.4429: . ack 8 win 58400 (DF)
18:49:24.503242 AAA.4429 > DDD.4001: P 8:22(14) ack 1 win 58400 (DF)
18:49:24.589325 AAA.4430 > DDD.4000: . ack 705 win 58400 (DF)
18:49:24.589488 DDD.4000 > AAA.4430: P 705:2113(1408) ack 1 win 58400 (DF)
18:49:24.596050 DDD.4001 > AAA.4429: . ack 22 win 58400 (DF)
18:49:25.078410 AAA.4430 > DDD.4000: . ack 2113 win 58400 (DF)
18:50:24.057083 AAA.4429 > DDD.4001: P 22:29(7) ack 1 win 58400 (DF)
18:50:24.064235 DDD.4000 > AAA.4430: P 2113:2817(704) ack 1 win 58400 (DF)
18:50:24.156954 DDD.4001 > AAA.4429: . ack 29 win 58400 (DF)
18:50:24.258543 AAA.4429 > DDD.4001: P 29:43(14) ack 1 win 58400 (DF)
18:50:24.354875 AAA.4430 > DDD.4000: . ack 2817 win 58400 (DF)
18:50:24.355054 DDD.4000 > AAA.4430: P 2817:4225(1408) ack 1 win 58400 (DF)
18:50:24.356947 DDD.4001 > AAA.4429: . ack 43 win 58400 (DF)
18:50:24.796839 AAA.4430 > DDD.4000: . ack 4225 win 58400 (DF)
19:00:24.078217 arp who-has DDD tell relay.MY.ru
19:00:24.078238 arp reply DDD is-at ;)
19:00:24.078547 AAA.4429 > DDD.4001: P 43:50(7) ack 1 win 58400 (DF)
19:00:24.085839 DDD.4000 > AAA.4430: P 4225:4929(704) ack 1 win 58400 (DF)
19:00:24.175998 DDD.4001 > AAA.4429: . ack 50 win 58400 (DF)
19:00:24.298094 AAA.4429 > DDD.4001: P 50:57(7) ack 1 win 58400 (DF)
19:00:24.390342 AAA.4430 > DDD.4000: . ack 4929 win 58400 (DF)
19:00:24.390457 DDD.4000 > AAA.4430: P 4929:5633(704) ack 1 win 58400 (DF)
19:00:24.395998 DDD.4001 > AAA.4429: . ack 57 win 58400 (DF)
19:00:24.673881 AAA.4430 > DDD.4000: . ack 5633 win 58400 (DF)
19:05:25.150023 AAA.4429 > DDD.4001: F 57:57(0) ack 1 win 58400 (DF)
19:05:25.150098 DDD.4001 > AAA.4429: . ack 58 win 58400 (DF)
19:05:25.150192 DDD.4001 > AAA.4429: F 1:1(0) ack 58 win 58400 (DF)
19:05:25.160256 AAA.4430 > DDD.4000: F 1:1(0) ack 5633 win 58400 (DF)
19:05:25.160298 DDD.4000 > AAA.4430: . ack 2 win 58400 (DF)
19:05:25.219736 AAA.4429 > DDD.4001: . ack 2 win 58400 (DF)
19:14:11.208768 DDD.4000 > AAA.4430: F 5633:5633(0) ack 2 win 58400 (DF)
19:14:11.342270 AAA.4430 > DDD.4000: . ack 5634 win 58400 (DF)


А вот сделующий представляет интерес. К сожеленью я забыл отключить "показ портов в текстовом виде", а сокет, видимо, хватанул 1110 порт, так что с nfsd-status придеться мириться ;(

18:04:23.709008 BBB.2844 > DDD.4001: S 2139116037:2139116037(0) win 57344 <mss 1460> (DF)
18:04:23.709095 DDD.4001 > BBB.2844: S 3551804060:3551804060(0) ack 2139116038 win 57344 <mss 1460> (DF)
18:04:23.824999 BBB.2844 > DDD.4001: . ack 1 win 58400 (DF)
18:04:23.835243 BBB.nfsd-status > DDD.4000: S 2026136892:2026136892(0) win 57344 <mss 1460> (DF)
18:04:23.835289 DDD.4000 > BBB.nfsd-status: S 2228898209:2228898209(0) ack 2026136893 win 57344 <mss 1460> (DF)
18:04:24.011503 BBB.nfsd-status > DDD.4000: . ack 1 win 58400 (DF)
--- Тут коннект закончен ---
18:04:24.015590 BBB.2844 > DDD.4001: P 1:8(7) ack 1 win 58400 (DF)
18:04:24.022831 DDD.4000 > BBB.nfsd-status: P 1:705(704) ack 1 win 58400 (DF)
18:04:24.115308 DDD.4001 > BBB.2844: . ack 8 win 58400 (DF)
18:04:24.283800 BBB.2844 > DDD.4001: P 8:22(14) ack 1 win 58400 (DF)
18:04:24.375312 DDD.4001 > BBB.2844: . ack 22 win 58400 (DF)
18:04:24.387495 BBB.nfsd-status > DDD.4000: . ack 705 win 58400 (DF)
18:04:24.387658 DDD.4000 > BBB.nfsd-status: P 705:2113(1408) ack 1 win 58400 (DF)
18:04:24.656212 BBB.nfsd-status > DDD.4000: . ack 2113 win 58400 (DF)
18:05:23.988828 BBB.2844 > DDD.4001: P 22:29(7) ack 1 win 58400 (DF)
18:05:23.995944 DDD.4000 > BBB.nfsd-status: P 2113:2817(704) ack 1 win 58400 (DF)
18:05:24.086221 DDD.4001 > BBB.2844: . ack 29 win 58400 (DF)
18:05:24.493683 BBB.2844 > DDD.4001: P 29:43(14) ack 1 win 58400 (DF)
18:05:24.495710 BBB.nfsd-status > DDD.4000: . ack 2817 win 58400 (DF)
18:05:24.501346 DDD.4000 > BBB.nfsd-status: P 2817:3521(704) ack 1 win 58400 (DF)
18:05:24.586222 DDD.4001 > BBB.2844: . ack 43 win 58400 (DF)
18:05:25.210808 BBB.nfsd-status > DDD.4000: . ack 3521 win 58400 (DF)
18:05:25.210919 DDD.4000 > BBB.nfsd-status: P 3521:4225(704) ack 1 win 58400 (DF)
18:05:25.590713 BBB.nfsd-status > DDD.4000: . ack 4225 win 58400 (DF)

-- Итак, шесть пакетов ушли, теперь клиент спит 10ть минут--

18:15:24.145774 arp who-has DDD tell relay.MY.ru
18:15:24.145790 arp reply DDD is-at ;)
18:15:24.146088 BBB.2844 > DDD.4001: P 43:50(7) ack 1 win 58400 (DF)
18:15:24.153605 DDD.4000 > BBB.nfsd-status: P 4225:4929(704) ack 1 win 58400 (DF)
18:15:24.245272 DDD.4001 > BBB.2844: . ack 50 win 58400 (DF)
18:15:24.330781 BBB > DDD: icmp: host BBB unreachable - admin prohibited filter
-- А вот это уже интересно, комментарий ниже.
18:15:24.353302 BBB.2844 > DDD.4001: P 50:57(7) ack 1 win 58400 (DF)
18:15:24.445355 DDD.4001 > BBB.2844: . ack 57 win 58400 (DF)
18:15:25.395417 DDD.4000 > BBB.nfsd-status: P 4225:5633(1408) ack 1 win 58400 (DF)
18:15:25.574337 BBB > DDD: icmp: host BBB unreachable - admin prohibited filter
18:15:27.695452 DDD.4000 > BBB.nfsd-status: P 4225:5633(1408) ack 1 win 58400 (DF)
18:15:27.877684 BBB > DDD: icmp: host BBB unreachable - admin prohibited filter
18:15:32.095519 DDD.4000 > BBB.nfsd-status: P 4225:5633(1408) ack 1 win 58400 (DF)
18:15:32.336842 BBB > DDD: icmp: host BBB unreachable - admin prohibited filter
18:15:40.695653 DDD.4000 > BBB.nfsd-status: P 4225:5633(1408) ack 1 win 58400 (DF)
18:15:57.695911 DDD.4000 > BBB.nfsd-status: P 4225:5633(1408) ack 1 win 58400 (DF)
18:16:29.896395 DDD.4000 > BBB.nfsd-status: P 4225:5633(1408) ack 1 win 58400 (DF)
18:16:30.073253 BBB > DDD: icmp: host BBB unreachable - admin prohibited filter
18:17:33.897361 DDD.4000 > BBB.nfsd-status: P 4225:5633(1408) ack 1 win 58400 (DF)
18:17:34.096106 BBB > DDD: icmp: host BBB unreachable - admin prohibited filter
18:18:37.898328 DDD.4000 > BBB.nfsd-status: P 4225:5633(1408) ack 1 win 58400 (DF)
18:19:41.899293 DDD.4000 > BBB.nfsd-status: P 4225:5633(1408) ack 1 win 58400 (DF)
18:19:42.181815 BBB > DDD: icmp: host BBB unreachable - admin prohibited filter
18:20:27.708766 BBB.2844 > DDD.4001: F 57:57(0) ack 1 win 58400 (DF)
18:20:27.708832 DDD.4001 > BBB.2844: . ack 58 win 58400 (DF)
18:20:27.708937 DDD.4001 > BBB.2844: F 1:1(0) ack 58 win 58400 (DF)
18:20:27.712845 BBB.nfsd-status > DDD.4000: F 1:1(0) ack 4225 win 58400 (DF)
18:20:27.712887 DDD.4000 > BBB.nfsd-status: . ack 2 win 58400 (DF)
18:20:27.807525 BBB.2844 > DDD.4001: . ack 2 win 58400 (DF)
18:20:45.900257 DDD.4000 > BBB.nfsd-status: P 4225:5633(1408) ack 2 win 58400 (DF)
18:20:46.137655 BBB.nfsd-status > DDD.4000: R 2026136894:2026136894(0) win 0

Итак я получил 13ю ошибку - "host unreachable - admin prohibited filter".
Почему ? Десять минут назад пакеты уходили и все было хорошо, что изменилось ?! Из-за чего такое может происходить. Почему только на BBB ?
Вообщем в моей голове kernel panic. Help !

P.S. Еще я забыл сказать, как теперь кажется, самое главное. Хоть хосты AAA и BBB сидят за CCC, но AAA имеет свой внешний адрес, т.е. использует CCC только как роутер, BBB наоборот - полностью локальная машина для сети, и использует CCC как "nat сервер". Может тут собака порылась ?
tcpdump форева, однозначно 07.06.03 14:08  
Автор: NKritsky <Nickolay A. Kritsky> Статус: Elderman
<"чистая" ссылка> <обсуждение закрыто>
> Наконец то я продампил пакет. К сожалению дамп сделан
> только на серверной стороне.
>
> Обозначения те же: AAA - работающий хост, BBB - не
> работающий хост, DDD - хост сервера.
>

если ты дампил на стороне DDD, а ВВВ сидит за натом, выходит пакеты от ВВВ имеют обратный адрес CCC. Так?

>
скипаем дамп...
>
> Итак я получил 13ю ошибку - "host unreachable - admin
> prohibited filter".
>
> P.S. Еще я забыл сказать, как теперь кажется, самое
> главное. Хоть хосты AAA и BBB сидят за CCC, но AAA имеет
> свой внешний адрес, т.е. использует CCC только как роутер,
> BBB наоборот - полностью локальная машина для сети, и
> использует CCC как "nat сервер". Может тут собака порылась
> ?
Вполне может быть.
Я не знаю, что за софтина делает нат на ССС, узнай это. Но пока могу сделать следующее предположение о принципе её работы:
Приходит Syn от ВВВ к DDD.
Создается структура примерно такого вида:
struct NATed_conn {
dword src_ip;
dword dst_ip;
word src_port;
word dst_port;
word proto;
word nated_port;//Optional если нат изменяет срц_порт
dword lastused;
}
После чего, каждый пакет проходящий через нат сравнивается по своим 5 определяющим параметрам (срц_ип,срц_порт,дст_ип,дст_порт,прото) со сриском таких структур, и если находится соответствие, хедеры переписываются, а в lastused записывается текущее время (тики, секунды, [micro|nano|pico|mega]секунды - что там у них есть). Если пакет является последним фином для тцп коннекшена, то структура удаляется (память-то не резиновая). А как быть с коннекшенами которые закончились аномально, без финов? Или с UDP коннекшенами, у которых финов вообще нету? Пишется функция remove_stale_conns , которая иногда пробегает по списку и выкидывает те структуры для которых getcurtime-lastused>N . Понятно? Или, если количество структур ограничено, и некуда вставить новую, демон находит коннекшен с самым старым lastused и выкидывает его чтобы вставить новый. Я думаю что нечто подобное произошло на машине CCC с твоим соединением. А когда оно перестало натится, пакет
18:15:24.245272 DDD.4001 > BBB.2844: . ack 50 win 58400 (DF)
пошел не к BBB а к ССС, а там ему выдали "от ворот поворот" в виде ICMP13 (это наверное фаерволл).
Выводы:
1. Узнай что за нат-демон стоит на ССС.
2. Постарайся узнать его принцип работы, если не сможешь, спроси на форуме.
3. Если проблема в нат-демоне, включи опцию SO_KEEPALIVE в клиентском сокете. Прога в сорцах, или в бинарнике? В любом случае это можно сделать. Ну вот собссно и все :)
И в заключение... 09.06.03 13:50  
Автор: PS <PS> Статус: Elderman
<"чистая" ссылка> <обсуждение закрыто>
"Надежное TCP" как показала практика совсем не надежно.

На моей стороне разрыв соединения можно чекать следующим способом:
bool TCPConnector::TestSocketOn( TCPConnector* me, int read_or_write, int socket, string who, int& err )
{
	int selRet;

	fd_set readfds;
	fd_set readfds2;
	fd_set exepfds;
	struct timeval tv;

who.c_str() );
	FD_ZERO( &readfds );
	FD_ZERO( &readfds2 );
	FD_ZERO( &exepfds );
	FD_SET( socket, &readfds );	
	FD_SET( socket, &exepfds );
	FD_SET( socket, &readfds2 );	
	tv.tv_sec = 5;
	tv.tv_usec= 0;

	if( read_or_write == TCPCON_TST_S_WRITE )
		selRet = select( (socket) + 1, &readfds2, &readfds, &exepfds, &tv );
	else
		selRet = select( (socket) + 1, &readfds, NULL, &exepfds, &tv );

	if( selRet == SOCKET_ERROR )
	{
		// So, socket failed. It is stranger situation.
		// I decide, that writer thread must be finished.
		err = 1;
		return false;
	}
	else if( selRet == 0 )
	{
		// Time out.
		// Try againg.
		err = 0;
		return false;
	}
	else if( selRet > 0 )
	{		
		if( FD_ISSET( socket, &exepfds ) )
		{			
			err = 2;
			return false;
		}
		if( read_or_write == TCPCON_TST_S_WRITE && FD_ISSET( socket, &readfds2 ))
		{
			char byte;
			int retVal = recv( socket, &byte, 1, MSG_PEEK );
			if( retVal == 0|retVal == SOCKET_ERROR|retVal == INVALID_SOCKET )
			{
				err = 2;
				return false;
			}
		}
	}// if

	err = 0;
	return true;
}

---

Но опять же - это не панацея. Я решил что лучший способ узнать о доставке пакета - это подтверждение. На каждый отправленный пакет нужно ждать подтверждение, если в течении некоторого времени его нет - считаем связь разорванной. На это все и было переписанно (счастливые, у вас были выходные... :( )
Кстати зашел вчера вечерком в один книждый магазинчик, там стоит книжечка по TCP/IP, желтенькая такая, трехтомная. Нашел нужную тему, а там русским по белому написанно, что для надежной доставки по TCP нужно самому реализовывать пакеты подтверждения. О как ! (от себя добавлю - на это можно, конечно, забить. И в большитстве случаев все работать будет. Но рано или поздно софт нарвется на то состояние в сети, о котором вся эта ветка ).
Еще одна фигня с send 04.06.03 19:08  
Автор: NKritsky <Nickolay A. Kritsky> Статус: Elderman
<"чистая" ссылка> <обсуждение закрыто>
> Proto Recv-Q Send-Q Local Address Foreign Address
> (state)
> tcp4 0 0 xxxx.4001 yyyy.1225 ESTABLISHED
> tcp4 0 1220 xxxx.4000 yyyy1224 ESTABLISHED
>
> В сокете на отправку лежат 1220 байт, и не уходят !
> Вот так, send() мне не возвращает -1. Типа все отправил,
> все ок. А на самом деле данные лежат в очереди, и их не
> могут получить.
>
> Кто с такой фигней встречался ? Из-за чего может быть ?
Первое что приходит в голову - нет места в окне TCP сессии. То есть - не пришел подтверждающий ACK на пакет № N а мы уже заслали N+K пакетов вперед. Подробности давай, посмотрим.
Вот например вопросы:
1. Нельзя ли получить tcpdump лог сессии.
2. Что значит "данные лежат в сессии"? Сколько они там лежат, погибает ли сокет по таймауту, жив ли удаленный хост, удаленный процесс.
Ага, дело было так 04.06.03 19:27  
Автор: PS <PS> Статус: Elderman
<"чистая" ссылка> <обсуждение закрыто>
1. Засылаем пакет (610 байт)
2. Он лежит в буфере сокета (видимо ACK действительно нет. почему ?)
3. Засылаем второй пакет (610 байт). Теперь у нас там лежит 1220. Жду...
4. Минут через 15 говорю netstat - опа ! А соединения уже нет. Кстати, на другой стороне (в другом городе нашей необъятной Родины) netstat утверждает что ESTABLISHED - весело.
5. Пытаюсь записать туда третий пакет. И только сейчас получаю облом в виде любимого SIGPIPE ! Ну слава богу, хоть так просигнализировал.

Итого: два пакета якобы ушли, на самом деле были потерянны. И еще один явно не ушел.

И как с этим работать ?
Немножко уточним. 04.06.03 19:41  
Автор: NKritsky <Nickolay A. Kritsky> Статус: Elderman
<"чистая" ссылка> <обсуждение закрыто>
1. Это произошло один раз, или это регулярные/постоянные траблы?
2. Если удастся повторить - сможешь снять tcpdump?
3. Хоть что-нибудь проходит по этому соединению, или фигня начинается при первых же 1220 байтах?
4. Кстати, может говорить не бАйты а байтА, типа как профессиональный жаргон (мы говорим не штОрмы а штормА), но это так, slightly offtopic.
5. Остальные ТСР соединения между этими двумя серверами - работают?
Немножко уточним. 04.06.03 19:50  
Автор: PS <PS> Статус: Elderman
<"чистая" ссылка> <обсуждение закрыто>
> 1. Это произошло один раз, или это регулярные/постоянные
> траблы?

Регулярные.

> 2. Если удастся повторить - сможешь снять tcpdump?

Если ничего другого не поможет - то придется.

> 3. Хоть что-нибудь проходит по этому соединению, или фигня
> начинается при первых же 1220 байтах?

Так, сначала (после accept) все идет просто отлично. Потом я иду курить, чел на другой стороне идет курить... мы курим где то 20 минут. И вот после такого таймаута send прекращает что либо посылать. (мистика, борьба FreeBSD с табакокурением)

> 4. Кстати, может говорить не бАйты а байтА, типа как
> профессиональный жаргон (мы говорим не штОрмы а штормА), но
> это так, slightly offtopic.

No comments.

> 5. Остальные ТСР соединения между этими двумя серверами -
> работают?

Есть еще одно соединение, на другой стороне в него делают send, я делаю только recv. Оно работает стабильно.
а если чел с той стороны через 20 мин пакет пошлет с его стороны соединение рвется? (RST) 07.06.03 14:34  
Автор: Killer{R} <Dmitry> Статус: Elderman
<"чистая" ссылка> <обсуждение закрыто>
Немножко уточним. 04.06.03 19:57  
Автор: NKritsky <Nickolay A. Kritsky> Статус: Elderman
<"чистая" ссылка> <обсуждение закрыто>
> > 2. Если удастся повторить - сможешь снять tcpdump?
>
> Если ничего другого не поможет - то придется.
Слушай, этож совсем нетрудно. По крайней мере на твоей стороне. Я всегда это делаю одним из первых шагов.
>
> > 3. Хоть что-нибудь проходит по этому соединению, или
> фигня
> > начинается при первых же 1220 байтах?
>
> Так, сначала (после accept) все идет просто отлично. Потом
> я иду курить, чел на другой стороне идет курить... мы курим
> где то 20 минут. И вот после такого таймаута send
> прекращает что либо посылать. (мистика, борьба FreeBSD с
> табакокурением)
>
О ! После таймаута. А что если я спрошу - есть ли между вами firewall'ы? И есть ли там правила вроде FreeBSDшных keep-sate? Мне кажется, что это могло бы стать причиной. Что если включить SO_KEEPALIVE на сокете?
1




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2025 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach