☰

UDP-сервер Netcat не отправляет ответ

tag-icon • tag-icon linux udp netcat
UDP-сервер Netcat не отправляет ответ

Я пытаюсь заставить OpenBSD netcat прослушивать UDP-соединения на определенном порту (3333) и интерфейсе (10.42.0.1) и отправлять фиксированный ответ. Чтобы добиться этого, я делаю:

echo "asd" | nc -k -u -l -p 3333 -s 10.42.0.1 -v

И затем я отправляю сообщение следующим образом:

echo qwe | nc -u 10.42.0.1 3333 -v

Выходы:

# Server side
Bound on h9ct3d3 3333
XXXXXqwe

# Client side
Connection to 10.42.0.1 3333 port [udp/*] succeeded!

Как видите, клиент не получает asd. Однако если я уберу -k, он его получит:

##### Server side
echo "asd" | nc -u -l -p 3333 -s 10.42.0.1 -v
Bound on h9ct3d3 3333
# ...
# Wait for the client to execute
# ...
Connection received on h9ct3d3 51318
XXXXXqwe

##### Client side
echo qwe | nc -u 10.42.0.1 3333 -v
# ...
# Wait for the above 'X'to finish
# ...
Connection to 10.42.0.1 3333 port [udp/*] succeeded!
asd

Я пробовал использовать цикл while без -k, но ncничего не возвращается:

#!/bin/bash

while true
do
    echo "Host message" | nc -q 0 -u -l -p 3333 -s 10.42.0.1 -v
    echo "restarting..."
done

Как мне это реализовать?

Моя версия netcat:

OpenBSD netcat (Debian patchlevel 1.206-1ubuntu1)

PD. Почему ncсервер "отправляет" эти странные Xсимволы? Клиент их никогда не читает, он просто ждет, пока они закончатся. Кажется, они отображаются каждую секунду.

решение1

Сервер не отправляет X; клиент отправляет их с интервалом в 1 секунду после первых двух, а серверотображаетих (как и должно быть). Если вы -vснимитеклиент, X не отправляются и не отображаются, а данные отправляются и отображаются немедленно (не через 3 сек.). Понятия не имеюпочему -vозначает «медленно отправьте 5 X символов»!

Страница руководства для -ksays

При использовании вместе с опцией -u сокет сервера не подключается и может принимать UDP-датаграммы от нескольких хостов.

В соответствии с этим, сервер -vрегистрирует данные Connection from {host} {port} received!при использовании -ul, но не при использовании -ulk. ЯподозреватьКод для отправки данных «ответа» зависит от подключенного сокета, и, таким образом, если оставить его неподключенным, ответ не будет получен, но я не копался в исходниках, чтобы это проверить.

-q 0не будет работать, потому что в UDP нет обнаружимого "конца соединения", тогда как в TCP есть (обмен FIN). Если в данных вашего клиента есть что-то распознаваемое — например, head -1если это всегда одна строка — логически должно быть возможно написать что-то, что распознает эти данные и убивает процесс, ncпозволяя циклу итерироваться, но я не смог разработать чистый способ получить pid доступного ncдля такого распознавателя/убийцы. Создаю CW на случай, если кто-то еще может предоставить здесь реальное решение.

Связанный контент