информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
За кого нас держат?Сетевые кракеры и правда о деле ЛевинаSpanning Tree Protocol: недокументированное применение
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 ФБР нашла русский след в атаках... 
 Массовый взлом SharePoint 
 Microsoft Authenticator прекращает... 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
tcpdump форева, однозначно 07.06.03 14:08  Число просмотров: 1068
Автор: 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 в клиентском сокете. Прога в сорцах, или в бинарнике? В любом случае это можно сделать. Ну вот собссно и все :)
<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