☰

El servidor Netcat UDP no envía una respuesta

tag-icon • tag-icon linux udp netcat
El servidor Netcat UDP no envía una respuesta

Estoy intentando que OpenBSD netcat escuche las conexiones UDP en un puerto particular (3333) y una interfaz (10.42.0.1) y envíe una respuesta fija. Para lograr esto hago:

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

Y luego envío un mensaje haciendo:

echo qwe | nc -u 10.42.0.1 3333 -v

Las salidas son

# Server side
Bound on h9ct3d3 3333
XXXXXqwe

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

Como puede ver, el cliente no recibe asd. Sin embargo, si elimino el archivo -k, lo recibe:

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

Intenté usar un bucle while sin -k, pero ncnunca devolví:

#!/bin/bash

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

¿Cómo puedo hacer que esto funcione?

Mi versión de netcat es:

OpenBSD netcat (Debian patchlevel 1.206-1ubuntu1)

PD. ¿Por qué el ncservidor 'envía' esos Xpersonajes raros? El cliente nunca los lee, sólo espera a que terminen. Parecen mostrarse cada 1 segundo.

Respuesta1

El servidor no envía las X; el cliente los envía, a intervalos de 1 segundo después de los dos primeros, y el servidormuestraellos (como debería). Si te quitas -velcliente, las X no se envían ni se muestran, y los datos se envían y se muestran inmediatamente (no después de 3 segundos). no tengo ni ideapor qué -vsignifica 'enviar 5 X caracteres lentamente'!

La página de manual para -kdice

Cuando se usa junto con la opción -u, el socket del servidor no está conectado y puede recibir datagramas UDP de múltiples hosts.

De acuerdo con esto, el servidor -vregistra Connection from {host} {port} received!cuando se usa -ulpero no cuando se usa -ulk. Isospecharel código para enviar los datos de 'respuesta' depende de que el socket esté conectado y, por lo tanto, dejarlo sin conectar evita la respuesta, pero no he investigado la fuente para verificarlo.

-q 0no va a funcionar porque no hay un 'fin de conexión' detectable en UDP, mientras que sí lo hay en TCP (intercambio FIN). Si hay algo reconocible en los datos de su cliente, como head -1si son siempre una línea, lógicamente debería ser posible escribir algo que reconozca esos datos y finalice el ncproceso permitiendo que el bucle se repita, pero no lo he hecho. He podido encontrar una forma limpia de obtener el pid de ncdisponible para dicho reconocedor/asesino. Haciendo CW en caso de que alguien más pueda proporcionar una solución real aquí.

información relacionada