☰

O servidor Netcat UDP não está enviando uma resposta

tag-icon • tag-icon linux udp netcat
O servidor Netcat UDP não está enviando uma resposta

Estou tentando fazer com que o netcat do OpenBSD escute conexões UDP em uma porta específica (3333) e interface (10.42.0.1) e envie uma resposta fixa. Para conseguir isso eu faço:

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

E então eu envio uma mensagem fazendo:

echo qwe | nc -u 10.42.0.1 3333 -v

As saídas são

# Server side
Bound on h9ct3d3 3333
XXXXXqwe

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

Como você pode ver, o cliente não recebe asd. No entanto, se eu remover o -k, ele o receberá:

##### 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

Eu tentei usar um loop while sem o -k, mas ncnunca retorna:

#!/bin/bash

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

Como posso fazer isso funcionar?

Minha versão do netcat é:

OpenBSD netcat (Debian patchlevel 1.206-1ubuntu1)

PD. Por que o ncservidor ‘envia’ esses caracteres estranhos X? O cliente nunca os lê, apenas espera que terminem. Eles parecem ser exibidos a cada 1 segundo.

Responder1

O servidor não está enviando os Xs; o cliente os envia, em intervalos de 1 segundo após os dois primeiros, e o servidorexibiçõeseles (como deveria). Se você tirar -vocliente, os Xs não são enviados ou exibidos e os dados são enviados e exibidos imediatamente (não após 3 segundos). Eu não tenho ideiapor que -vsignifica 'enviar 5 X caracteres lentamente'!

A página de manual -kdiz

Quando usado junto com a opção -u, o soquete do servidor não está conectado e pode receber datagramas UDP de vários hosts.

Consistente com isso, o servidor -vregistra Connection from {host} {port} received!ao usar -ul, mas não ao usar o -ulk. EUsuspeitoo código para enviar os dados de 'resposta' depende do soquete estar conectado e, portanto, deixá-lo não conectado impede a resposta, mas não procurei na fonte para verificar.

-q 0não vai funcionar porque não há 'fim de conexão' detectável no UDP, enquanto existe no TCP (troca FIN). Se houver algo reconhecível sobre os dados do seu cliente - como head -1se for, sempre, uma linha - logicamente, deveria ser possível escrever algo que reconheça esses dados e elimine o ncprocesso, permitindo a iteração do loop, mas não o fiz. consegui descobrir uma maneira limpa de obter o pid ncdisponível para esse reconhecedor/assassino. Fazer CW caso alguém possa fornecer uma solução real aqui.

informação relacionada