Повторная передача TCP продолжается даже после сброса флага RST - PullRequest
5 голосов
/ 14 февраля 2012

Насколько я понимаю, флаг сброса TCP (RST) устанавливается всякий раз, когда полученный сегмент не предназначен для текущего соединения, и это приводит к прерыванию текущего сеанса TCP.Но захват проволочной акулы, вставленный ниже, кажется, не следует этой теории.В основном конец A, который инициировал RESET (кадр № 466), сам пытается повторно передать кадры TCP в течение того же сеанса TCP, а также продолжает отвечать на любой последующий новый запрос на подключение [SYN] от конца B с помощью [RST, ACK], и этоПоведение повторяется 5 раз, и 3-х стороннее рукопожатие снова удается только во время 6-й попытки (кадр # 486).

464 04:35.1 50000 > enpc [PSH, ACK] Seq=31894 Ack=7454 Win=5345 Len=105             
465 04:35.2 enpc > 50000 [ACK] Seq=7454 Ack=31999 Win=32127 Len=0               
466 04:35.2 50000 > enpc [RST] Seq=31999 Win=0 Len=0                
467 04:35.4 [TCP Retransmission] 50000 > enpc [PSH, ACK] Seq=31894 Ack=7454 Win=5345 Len=105                
468 04:36.1 [TCP Retransmission] 50000 > enpc [PSH, ACK] Seq=31894 Ack=7454 Win=5345 Len=105                
469 04:37.5 [TCP Retransmission] 50000 > enpc [PSH, ACK] Seq=31894 Ack=7454 Win=5345 Len=105                
470 04:40.3 [TCP Retransmission] 50000 > enpc [PSH, ACK] Seq=31894 Ack=7454 Win=5345 Len=105                
471 04:45.9 [TCP Retransmission] 50000 > enpc [PSH, ACK] Seq=31894 Ack=7454 Win=5345 Len=105                
472 04:57.1 [TCP Retransmission] 50000 > enpc [PSH, ACK] Seq=31894 Ack=7454 Win=5345 Len=105                
473 05:17.1 fg-fps > 50000 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 SACK_PERM=1                
474 05:17.1 50000 > fg-fps [RST, ACK] Seq=1 Ack=1 Win=0 Len=0               
475 05:17.5 fg-fps > 50000 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 SACK_PERM=1                
476 05:17.5 50000 > fg-fps [RST, ACK] Seq=1 Ack=1 Win=0 Len=0               
477 05:18.0 fg-fps > 50000 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 SACK_PERM=1                
478 05:18.0 50000 > fg-fps [RST, ACK] Seq=1 Ack=1 Win=0 Len=0               
479 05:19.5 [TCP Retransmission] 50000 > enpc [PSH, ACK] Seq=31894 Ack=7454 Win=5345 Len=105                
480 05:23.2 fg-gip > 50000 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 SACK_PERM=1                
481 05:23.2 50000 > fg-gip [RST, ACK] Seq=1 Ack=1 Win=0 Len=0               
482 05:23.7 fg-gip > 50000 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 SACK_PERM=1                
483 05:23.7 50000 > fg-gip [RST, ACK] Seq=1 Ack=1 Win=0 Len=0               
484 05:24.2 fg-gip > 50000 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 SACK_PERM=1                
485 05:24.2 50000 > fg-gip [RST, ACK] Seq=1 Ack=1 Win=0 Len=0               
486 05:29.7 dyniplookup > 50000 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 SACK_PERM=1               
487 05:29.7 50000 > dyniplookup [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 SACK_PERM=1 WS=2             
488 05:29.7 dyniplookup > 50000 [ACK] Seq=1 Ack=1 Win=65536 Len=0               
489 05:29.7 dyniplookup > 50000 [PSH, ACK] Seq=1 Ack=1 Win=65536 Len=105                
490 05:29.7 50000 > dyniplookup [ACK] Seq=1 Ack=106 Win=5840 Len=0              
491 05:29.7 dyniplookup > 50000 [PSH, ACK] Seq=106 Ack=1 Win=65536 Len=105              

Мой вопрос:

Почему конец Aпродолжал повторно передавать пакеты через соединение, где RST был сгенерирован с его собственного конца?

1 Ответ

3 голосов
/ 10 мая 2012

Существует много причин, по которым может быть отправлено RST. Флаг сброса используется при получении сегмента TCP, который не предназначен для текущего открытого соединения или порта прослушивания. Например, если порт TCP закрыт, стек TCP в системе ответит RST.

Как правило, когда система отправляет сброс TCP, ей также устанавливается флаг ack при подтверждении попытки подключения. В вашем случае, нет ack-флага, который (из памяти) в соответствии с RFC выполняется только тогда, когда нет установленного соединения, которое есть в вашем случае, что подсказывает мне, что это брандмауэр или кажется промежуточным устройством (не частью соединения TCP), который отправляет сброс. Таким образом, сервер A на законных основаниях будет считать, что соединение живо.

Кадры 467-472 являются стандартным поведением повторной передачи TCP (из системы A), при этом время между попытками соединения удваивается, а сервер, в конечном итоге, перестает работать после последней попытки в кадре 472. Эти кадры являются повторными передачами кадра 464, что Похоже, что кадр 465 не был получен системой B. Я предполагаю, что вы сделали захват в системе B?

Я полагаю, что система A переместилась в положение ЗАКРЫТО только после отправки кадра 473, что объясняет, почему мы видим трехстороннее рукопожатие, инициированное из системы В.

Судя по вашему следу, трудно сказать гораздо больше, не зная о сети.

НТН!

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...