TCP-пакеты не перехвачены слушателем PHP
У меня есть устройство (локализатор GPS), которое отправляет пакеты TCP (я так думаю) на мой сервер по указанному IP-адресу и через данный порт. Поскольку у меня есть только SSH-доступ к этому серверу, я открыл две сессии и запустил tcpdump (с правильными параметрами) в одном из них и мой собственный слушатель (написанный на PHP) во втором.
Когда я соединяюсь с этим IP и портом из любого из моих браузеров, я ясно вижу трафик, захваченный обоими tcpdump и мой собственный слушатель. Итак, я предполагаю, что все работает отлично.
Однако, когда я заставляю свой локализатор отправлять данные на этот IP/ порт, только tcpdump отвечает, показывая, что он что-то захватил, а вывод моего собственного слушателя остается пустым.
Я новичок в области сетей и TCP, так что, возможно, я ошибочно предположил, что это TCP-соединение. Может кто-то, с большим опытом, подтвердить это, посмотрев на то, что tcpdump захватил:
10:43:37.028958 IP 87.111.103.7.2020 > 192.168.1.2.7777: Flags [S], seq 1457768261, win 5120, options [mss 1360,nop,wscale 0,nop,nop,TS[|tcp]>
10:43:37.029564 IP 192.168.1.2.7777 > 87.111.103.7.2020: Flags [S.], seq 1118512962, ack 1457768262, win 5792, options [mss 1460,nop,nop,TS[|tcp]>
10:43:37.526145 IP 87.111.103.7.2020 > 192.168.1.2.7777: Flags [.], ack 1, win 5200, options [nop,nop,TS val 79 ecr 35113125], length 0
10:43:37.526934 IP 192.168.1.2.7777 > 87.111.103.7.2020: Flags [P.], ack 1, win 362, options [nop,nop,TS val 35113175 ecr 79], length 152
10:43:38.225678 IP 87.111.103.7.2020 > 192.168.1.2.7777: Flags [.], ack 153, win 5048, options [nop,nop,TS val 80 ecr 35113175], length 0
10:43:43.765708 IP 87.111.103.7.2020 > 192.168.1.2.7777: Flags [P.], ack 153, win 5200, options [nop,nop,TS val 89 ecr 35113175], length 119
10:43:43.765768 IP 192.168.1.2.7777 > 87.111.103.7.2020: Flags [.], ack 120, win 362, options [nop,nop,TS val 35113799 ecr 89], length 0
10:43:44.445757 IP 87.111.103.7.2020 > 192.168.1.2.7777: Flags [P.], ack 153, win 5200, options [nop,nop,TS val 91 ecr 35113175], length 119
10:43:44.446014 IP 192.168.1.2.7777 > 87.111.103.7.2020: Flags [.], ack 120, win 362, options [nop,nop,TS val 35113867 ecr 91], length 0
10:47:38.675424 IP 192.168.1.2.7777 > 87.111.103.7.2020: Flags [F.], seq 153, ack 120, win 362, options [nop,nop,TS val 35137290 ecr 91], length 0
10:47:41.636064 IP 87.111.103.7.2020 > 192.168.1.2.7777: Flags [.], ack 154, win 5200, options [nop,nop,TS val 568 ecr 35137290], length 0
10:47:41.655520 IP 87.111.103.7.2020 > 192.168.1.2.7777: Flags [R.], seq 120, ack 154, win 5200, length 0
Это действительно соединение TCP (тип пакета)? Если да, то может ли кто-нибудь иметь представление, почему мой слушатель не отвечает, в то время как он правильно отвечает на TCP-соединение из браузера? Если это не TCP-соединение, то что это? Что должен слушать мой слушатель, чтобы захватить этот вид трафика?
РЕДАКТИРОВАТЬ: Что меня беспокоит здесь больше всего, это то, что каждое соединение от моего локализатора помечается tcpdump с length 0 (тогда как ответный ответ всегда имеет некоторую длину). Но я заметил, что подключения браузера также помечены length 0так что, возможно, это не настоящая проблема.
2 ответа
Просто чтобы ответить на последний вопрос (вы говорите, это самое тревожное)
Это то, что я вижу: все данные имеют длину, все без данных (syn,ack,fin,rst) имеют длину 0. Выглядит нормально.
87.111.103.7 port 2020 -- 192.168.1.2 port 7777
syn ->
<- syn ack
ack ->
<-data
ack ->
data ->
<- ack
data ->
<- ack
<- fin
fin ->
rst ->
Ваша свалка выглядит хорошо. Ваше устройство (я предполагаю, что это 192.168.1.2) отправляет пакеты длиной больше 0, и ваш сервер подтверждает получение через 0-байтовые пакеты ACK. Вам, безусловно, будет полезно включить -XX в вашей командной строке tcpdump.
tcpdump -XX port 2020