LINUX.ORG.RU
Форум — Development  

tcpdump && TCP connection establishment && SYN_RECV state


1

0 

На сервере develop у меня стоит apache.
Делаю telnet на 80 порт, немного жду и закрываю соединение 
вообще без передачи каких-либо данных.

olimpico_work ~ # telnet develop 80
Trying 192.168.70.201...
Connected to develop.
Escape character is '^]'.
^]quit

telnet> quit
Connection closed.
olimpico_work ~ # 


Вот что показывает при этом tcpdump на клиентской стороне:

olimpico_work ~ # tcpdump -i eth1 host develop and port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
11:23:44.187263 IP krivenok.41234 > develop.http: S 2779819717:2779819717(0) win 5840 <mss 1460,sackOK,timestamp 1348338 0,nop,wscale 7>
11:23:44.187387 IP develop.http > krivenok.41234: S 107518013:107518013(0) ack 2779819718 win 5792 <mss 1460,sackOK,timestamp 15521524 1348338,nop,wscale 2>
11:23:44.187423 IP krivenok.41234 > develop.http: . ack 1 win 46 <nop,nop,timestamp 1348338 15521524>


11:23:57.346185 IP krivenok.41234 > develop.http: F 1:1(0) ack 1 win 46 <nop,nop,timestamp 1349652 15521524>
11:23:57.346368 IP develop.http > krivenok.41234: F 1:1(0) ack 2 win 1448 <nop,nop,timestamp 15524815 1349652>
11:23:57.346405 IP krivenok.41234 > develop.http: . ack 2 win 46 <nop,nop,timestamp 1349652 15524815>

6 packets captured
6 packets received by filter
0 packets dropped by kernel
olimpico_work ~ # 


Вроде все правильно и логично - сначала 3-этапное установление
соединения, а затем его завершение.

При этом на сервере develop видел, что соединение установлено:

develop ~ # netstat -na | grep "70.198" | grep 80 
tcp        0      0 192.168.70.201:80       192.168.70.198:41234    ESTABLISHED 
develop ~ # 

Пока все хорошо.


А теперь делаем то же самое с сервером develop2 на котором тоже
стоит apache.

olimpico_work ~ # telnet develop2 80
Trying 192.168.70.205...
Connected to develop2.
Escape character is '^]'.
^]quit

telnet> quit
Connection closed.
olimpico_work ~ # 

Вот что показывает tcpdump:

olimpico_work ~ # tcpdump -i eth1 host develop2 and port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
11:30:53.644916 IP krivenok.49819 > develop2.http: S 2776473031:2776473031(0) win 5840 <mss 1460,sackOK,timestamp 1391155 0,nop,wscale 7>
11:30:53.645069 IP develop2.http > krivenok.49819: S 874752337:874752337(0) ack 2776473032 win 5792 <mss 1460,sackOK,timestamp 6177317 1391155,nop,wscale 7>
11:30:53.645104 IP krivenok.49819 > develop2.http: . ack 1 win 46 <nop,nop,timestamp 1391155 6177317>
11:30:57.245167 IP develop2.http > krivenok.49819: S 874752337:874752337(0) ack 2776473032 win 5792 <mss 1460,sackOK,timestamp 6177677 1391155,nop,wscale 7>
11:30:57.245214 IP krivenok.49819 > develop2.http: . ack 1 win 46 <nop,nop,timestamp 1391515 6177677,nop,nop,sack 1 {0:1}>
11:31:03.247796 IP develop2.http > krivenok.49819: S 874752337:874752337(0) ack 2776473032 win 5792 <mss 1460,sackOK,timestamp 6178277 1391515,nop,wscale 7>
11:31:03.247837 IP krivenok.49819 > develop2.http: . ack 1 win 46 <nop,nop,timestamp 1392114 6178277,nop,nop,sack 1 {0:1}>
11:31:15.255559 IP develop2.http > krivenok.49819: S 874752337:874752337(0) ack 2776473032 win 5792 <mss 1460,sackOK,timestamp 6179477 1392114,nop,wscale 7>
11:31:15.255603 IP krivenok.49819 > develop2.http: . ack 1 win 46 <nop,nop,timestamp 1393312 6179477,nop,nop,sack 1 {0:1}>
11:31:39.466169 IP develop2.http > krivenok.49819: S 874752337:874752337(0) ack 2776473032 win 5792 <mss 1460,sackOK,timestamp 6181897 1393312,nop,wscale 7>
11:31:39.466216 IP krivenok.49819 > develop2.http: . ack 1 win 46 <nop,nop,timestamp 1395728 6181897,nop,nop,sack 1 {0:1}>


11:31:46.678079 IP krivenok.49819 > develop2.http: F 1:1(0) ack 1 win 46 <nop,nop,timestamp 1396448 6181897>
11:31:46.678314 IP develop2.http > krivenok.49819: F 1:1(0) ack 2 win 46 <nop,nop,timestamp 6182618 1396448>
11:31:46.678353 IP krivenok.49819 > develop2.http: . ack 2 win 46 <nop,nop,timestamp 1396448 6182618>

14 packets captured
14 packets received by filter
0 packets dropped by kernel
olimpico_work ~ # 


При этом если смотреть на сервере, то соединение находится 
в состоянии SYNC_RECV:

develop2 EQ-scripts # netstat -na | grep "70.198" | grep 80
tcp        0      0 192.168.70.205:80       192.168.70.198:49819    SYN_RECV   
develop2 EQ-scripts # 


То есть обмен пакетов следующий:
-> SYN  
<- SYN/ACK
-> ACK
<- SYN/ACK
-> ACK
<- SYN/ACK
-> ACK
...
...

Насколько я понимаю состояние SYN_RECV говорит о том, что
получен SYN и отправлен SYN/ACK.
После получения ACK на SYN/ACK соединение должно перейти
из SYN_RECV в ESTABLISHED.
Но этого не происходит.
Такое ощущение, что TCP сервера вообще не получает последний
ACK и поэтому постоянно перепосылает SYN/ACK клиенту.
На что клиент честно отвечает ACK'ом как показано выше.

В чем может быть проблема?

P.S.

Я запустил tcpdump и на сервере (все то же самое, только
номера эфемерных портов другие):

develop2 EQ-scripts # tcpdump -i eth0 host 192.168.70.198 and port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
11:44:40.458868 IP krivenok.internal.44560 > develop2.http: S 896196718:896196718(0) win 5840 <mss 1460,sackOK,timestamp 1473788 0,nop,wscale 7>
11:44:40.461384 IP develop2.http > krivenok.internal.44560: S 959167485:959167485(0) ack 896196719 win 5792 <mss 1460,sackOK,timestamp 6260093 1473788,nop,wscale 7>
11:44:40.459054 IP krivenok.internal.44560 > develop2.http: . ack 1 win 46 <nop,nop,timestamp 1473788 6260093>
11:44:44.255015 IP develop2.http > krivenok.internal.44560: S 959167485:959167485(0) ack 896196719 win 5792 <mss 1460,sackOK,timestamp 6260473 1473788,nop,wscale 7>
11:44:44.255231 IP krivenok.internal.44560 > develop2.http: . ack 1 win 46 <nop,nop,timestamp 1474167 6260473,nop,nop,sack 1 {0:1}>
11:44:50.257519 IP develop2.http > krivenok.internal.44560: S 959167485:959167485(0) ack 896196719 win 5792 <mss 1460,sackOK,timestamp 6261073 1474167,nop,wscale 7>
11:44:50.257738 IP krivenok.internal.44560 > develop2.http: . ack 1 win 46 <nop,nop,timestamp 1474766 6261073,nop,nop,sack 1 {0:1}>
11:45:03.592464 IP develop2.http > krivenok.internal.44560: S 959167485:959167485(0) ack 896196719 win 5792 <mss 1460,sackOK,timestamp 6262273 1474766,nop,wscale 7>
11:45:03.592679 IP krivenok.internal.44560 > develop2.http: . ack 1 win 46 <nop,nop,timestamp 1475963 6262273,nop,nop,sack 1 {0:1}>
11:45:27.794962 IP develop2.http > krivenok.internal.44560: S 959167485:959167485(0) ack 896196719 win 5792 <mss 1460,sackOK,timestamp 6264693 1475963,nop,wscale 7>
11:45:27.795178 IP krivenok.internal.44560 > develop2.http: . ack 1 win 46 <nop,nop,timestamp 1478379 6264693,nop,nop,sack 1 {0:1}>
11:45:38.087399 IP krivenok.internal.44560 > develop2.http: F 1:1(0) ack 1 win 46 <nop,nop,timestamp 1479406 6264693>
11:45:38.087487 IP develop2.http > krivenok.internal.44560: F 1:1(0) ack 2 win 46 <nop,nop,timestamp 6265722 1479406>
11:45:38.087688 IP krivenok.internal.44560 > develop2.http: . ack 2 win 46 <nop,nop,timestamp 1479406 6265722>
^C
14 packets captured
38 packets received by filter
0 packets dropped by kernel
develop2 EQ-scripts # 


Видно, что ACK приходит.
← SlickEdit отказываеться билдить и компилить
Python → 

На всякий случай:

develop2 EQ-scripts # iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
develop2 EQ-scripts # iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
develop2 EQ-scripts #

Krivenok_Dmitry ★
() автор топика
Ответ на: комментарий от Krivenok_Dmitry 

ещё есть таблица mangle, имхо если нужно посмотреть все записи
iptables проще это сделать через iptables-save:

$ sudo iptables-save
# Generated by iptables-save v1.4.1.1 on Fri Oct  3 15:17:58 2008
*nat
:PREROUTING ACCEPT [1:329]
:POSTROUTING ACCEPT [1:114]
:OUTPUT ACCEPT [1:114]
COMMIT
# Completed on Fri Oct  3 15:17:58 2008
# Generated by iptables-save v1.4.1.1 on Fri Oct  3 15:17:58 2008
*mangle
:PREROUTING ACCEPT [8:1886]
:INPUT ACCEPT [8:1886]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [9:580]
:POSTROUTING ACCEPT [9:580]
COMMIT
# Completed on Fri Oct  3 15:17:58 2008
# Generated by iptables-save v1.4.1.1 on Fri Oct  3 15:17:58 2008
*filter
:INPUT ACCEPT [286:115071]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [250:48291]
COMMIT
# Completed on Fri Oct  3 15:17:58 2008

Eshkin_kot ★★
() 

Вообще, если углубиться в тему, то, да, установка TCP соединения 
проходит через 3 стадии так, как ты описал. Но вот закрытие происходит в 4 этапа.

терь собсно у меня вопрос... почему у тебя в первом случае 6 пакетов, а не 7?

вот тебе наглядный пример (telnet ya.ru 80):

root@think:~# tcpdump -i wlan0 'host ya.ru and port 80'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), capture size 96 bytes
19:53:41.258999 IP think.38309 > ya.ru.www: S 748885782:748885782(0) win 5840 <mss 1460,sackOK,timestamp 454118 0,nop,wscale 7>
19:53:41.261747 IP ya.ru.www > think.38309: S 3997722127:3997722127(0) ack 748885783 win 4096 <mss 1410,nop,wscale 0,nop,nop,timestamp 924620662 454118,sackOK,eol>
19:53:41.261771 IP think.38309 > ya.ru.www: . ack 1 win 46 <nop,nop,timestamp 454119 924620662>
19:53:46.879195 IP think.38309 > ya.ru.www: F 1:1(0) ack 1 win 46 <nop,nop,timestamp 455524 924620662>
19:53:46.884439 IP ya.ru.www > think.38309: . ack 2 win 4194 <nop,nop,timestamp 924626096 455524>
19:53:46.884600 IP ya.ru.www > think.38309: F 1:1(0) ack 2 win 4194 <nop,nop,timestamp 924626096 455524>
19:53:46.884634 IP think.38309 > ya.ru.www: . ack 2 win 46 <nop,nop,timestamp 455525 924626096>

7 packets captured
9 packets received by filter
0 packets dropped by kernel

Deleted
()
Ответ на: комментарий от Deleted

Да все верно у него с дампом, учи TCP-протокол. FIN может идти вместе с ACK. По сабжу - все очень удивительно. Я бы начал полное исследование двух серверов на предмет различий (маршруты к ним, sysctl, OS version)

anonymous
()
Ответ на: комментарий от Deleted 

> терь собсно у меня вопрос... почему у тебя в первом случае 6 пакетов, а не 7?

Есть такая тема - TCP delayed acknowledgments.
Насколько я понимаю, в данном примере работает именно 
она.

Из доки:
If delayed acknowledgments are supported by the systems, the final FIN 
could be bundled with the ACK into one segment.

Krivenok_Dmitry ★
() автор топика
Ответ на: комментарий от val-amart

упс, и без меня хватило умных людей =)

по теме:

действительно, странно... насчет работы протокола, то ты все понял верно, именно так и есть. такое ощущение, что dev2 или не видит ack'а (он не доходит до стэка), или он считает его некорректно сформированным или не подтверждающим его syn/ack.

выложи может более информативные .pcap файлы, или хотя б tcpdump -x. Также, какие ядра на указанных системах и с какими патчсетами? может еще какие приблуды держишь?

val-amart ★★★★★
()
Ответ на: комментарий от anonymous

>Да все верно у него с дампом, учи TCP-протокол

Уже :) про бандл фина и акк'а чет совсем вылетело из головы.

Deleted
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← SlickEdit отказываеться билдить и компилить
Development
Python →