Windows TCP Handshake Проблема - PullRequest
       16

Windows TCP Handshake Проблема

3 голосов
/ 27 октября 2010

Я пытаюсь создать TCP-соединение от встроенного контроллера к серверу Windows Vista. Я пишу серверную часть Windows приложения.

Когда контроллер пытается установить соединение, может потребоваться много попыток установить соединение. Я использовал Wireshark для отладки проблемы, и кажется, что стек Windows TCP не соответствует правильному протоколу квитирования.

Свалка проволочной акулы:

"No","Time","Source","Destination","Protocol","Info"

Try1:

"39","9.025322","10.0.0.252","10.0.0.92","TCP","49153 > xinuexpansion4 [SYN] Seq=0 Win=127 Len=0"
"40","9.025377","10.0.0.92","10.0.0.252","TCP","xinuexpansion4 > 49153 [ACK] Seq=1 Ack=1 Win=2048 Len=0"
"47","10.031750","10.0.0.252","10.0.0.92","TCP","49153 > xinuexpansion4 [RST] Seq=0 Win=127 Len=0"

Попробуйте 2:

"55","12.193941","10.0.0.252","10.0.0.92","TCP","49154 > xinuexpansion4 [SYN] Seq=0 Win=127 Len=0"
"56","12.194045","10.0.0.92","10.0.0.252","TCP","xinuexpansion4 > 49154 [ACK] Seq=1 Ack=1 Win=2048 Len=0"
"57","13.200431","10.0.0.252","10.0.0.92","TCP","49154 > xinuexpansion4 [RST] Seq=0 Win=127 Len=0"

Попробуйте 3:

"67","18.529871","10.0.0.252","10.0.0.92","TCP","49156 > xinuexpansion4 [SYN] Seq=0 Win=127 Len=0"
"68","18.529957","10.0.0.92","10.0.0.252","TCP","xinuexpansion4 > 49156 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1460"
"69","18.536318","10.0.0.252","10.0.0.92","TCP","49156 > xinuexpansion4 [ACK] Seq=1 Ack=1 Win=127 Len=0"

10.0.0.252 - контроллер, инициирующий соединение, 10.0.0.92 - ПК с Windows.

Насколько я понимаю, правильная последовательность: SYN, SYN + ACK, SYN. В большинстве случаев я получаю SYN, ACK, RST (то есть Windows отвечает ACK, а не SYN + ACK). В приведенном выше дампе показано 3 попытки подключения, третья работает.

Могу ли я что-нибудь сделать, чтобы «исправить» Windows, чтобы она правильно реагировала?

РЕДАКТИРОВАТЬ - 2 захвата пакета

Ответы [ 3 ]

3 голосов
/ 01 ноября 2010

Я посмотрел на ваши файлы pcap, и единственные различия, которые я вижу, это:

(1) Клиент Windows отправляет «случайные» начальные порядковые номера в своих пакетах SYN, тогда как встроенный клиент отправляет начальные порядковые номера, такие как 1, 2, 3, в свои пакеты SYN. Пока сервер не имеет абсолютно никакого состояния соединения TCP для 4-х кортежей (исходный IP-адрес, исходный порт, Dest IP-адрес, Dest-порт), это не должно иметь никакого значения, о котором я знаю, но я хотел бы упомянуть об этом на случай это помогает вам или кому-то еще придумать идею.

(2) Клиент Windows отправляет пакеты SYN с параметрами TCP, тогда как встроенный клиент отправляет пакеты SYN без параметров TCP. Опять же, насколько я знаю, это не должно вызывать поведение, которое вы наблюдаете, и, опять же, возможно, это будет звонком для кого-то еще.

Если вы хотите увидеть более подробную информацию о заголовках пакетов и их декодировании, я рекомендую tshark, который входит в состав пакета wireshark. Вы можете получить много деталей, используя такую ​​командную строку:

tshark -n -V -x -r Embeded-4-attempts.pcap > Embeded-4-attempts.txt

Что касается наблюдения «требуется еще 1 попытка подключения», которое вы сделали выше, я укажу, что клиенту требуется еще 1 раз, чтобы достичь нового начального порядкового номера, который сервер Windows Vista еще не видел, поскольку Держу пари, что каждый раз, когда вы перезагружаете клиент, он начинает с отправки пакета SYN с порядковым номером 1, затем 2 при следующей попытке подключения, затем 3 и т. Д. Возможно, сервер Windows Vista ждет, чтобы увидеть новый начальный порядковый номер, прежде чем он правильно отреагирует на соединение.

Хм. Теперь, когда я думаю об этом, возможно, проблема в том, что сервер Vista не отвечает правильно на RST-пакеты от клиента? Если это так, сервер считает, что все эти клиентские подключения все еще активны, в то время как клиент не имеет связанного с ними состояния. Сервер отвечает ACK на попытки подключения, для которых он все еще имеет состояние, а не SYN-ACK, потому что у него все еще есть состояние для них. Клиент не имеет для них состояния и ведет себя так, как будто они являются новыми соединениями. Перезагрузка клиента заставляет его вернуться к тому же порту источника TCP и исходным порядковым номерам, что и в прошлый раз, когда он загружался, потому что его простой стек TCP не рандомизирует эти значения, как, вероятно, клиент Windows.

В любом случае, пища для размышлений. Если у вас есть доступ к исходному коду для простого TCP-клиента, проверьте, можно ли использовать случайные исходные порты и начальные порядковые номера при выполнении новых запросов на подключение.

0 голосов
/ 29 октября 2010

Вы пытались подключиться к серверу Vista с клиента, работающего под управлением полной ОС, такой как Windows или Linux, с использованием, скажем, telnet?В Linux, по крайней мере, вы можете указать номер порта TCP для подключения в командной строке и посмотреть, может ли это установить соединение с вашим сервером Vista.

Одна возможность проверить: работает ли сервер Vistaкакой-то брандмауэр, который предотвращает соединение?

0 голосов
/ 27 октября 2010

во время сбоя рукопожатия это соответствует протоколу.RST разрешено сбросить соединение как часть протокола.Вопрос в том, почему происходит сброс?Есть ли система между двумя машинами, которая отправляет сброс?Если вы запускаете и сервер, и клиент в одной системе, вы все равно получаете сброс (это может указывать на ошибку в вашем коде)?если вы запускаете сервер в другой ОС, в том же сетевом гнезде, что и сервер Windows, вы видите RST?

...