Uso de netcat para enviar un paquete UDP sin enlace

que tienen una instancia que está a la escucha de los paquetes UDP en el puerto 6666, así como:

nc -ul 6666

En otra ventana de terminal, estoy tratando de enviar periódicamente un paquete UDP del puerto 6666 (para abrir el camino de retorno en mi router. esto sería en un guión que se repite cada 20 segundos para volver a abrir el puerto)

nc -u -p6666 mypinghost.com 4444

el problema es netcat falla en esta llamada de ping con el mensaje:

nc: bind falló: Dirección ya en uso

lo que implica que el oyente haber enlazado al puerto 6666 está bloqueando otro proceso de envío desde ese puerto, o posiblemente que netcat está tratando de obligar a 6666 para escuchar.

¿Es así como se escribe netcat, o puedo hacerle cosquillas de alguna manera para que me permita enviar un paquete sin vincularlo al puerto para escucharlo?

Fuente

2012-07-08 Jim Baldwin

No creo que pueda usar netcat de esa manera. Yo recomendaría escribir un script simple de Python que haga las tareas de envío y recepción en un proceso. De esta forma, puede mantener ese puerto de forma exclusiva y aun así realizar ambas tareas.

Fuente

2012-07-09 23:11:34 mhall

nc -ul 6666

Escuchar en el puerto UDP 6666.

nc -u -p6666 mypinghost.com 4444

Mediante el puerto de UDP 6666 como la fuente puerto, enviar a mypinghost: 4444.

nc: no se unen: Dirección ya en uso

Eso sería en el segundo netcat invocación, en 6666 ya está en uso por la primera.

lo que implica que el oyente haber enlazado al puerto 6666 está bloqueando otro proceso de envío desde ese puerto

correcta.

o posiblemente que netcat esté intentando vincularse al 6666 para escuchar.

Ydefinitivamente eso. Usted le dijo que hiciera eso, así que lo hizo.

Lo que estás tratando de hacer es imposible entre dos procesos en el mismo host.Solo un proceso puede usar un puerto UDP local específico a la vez, a menos que use SO_REUSEADDRESS, que netcat no parece implementar.

Como ha sugerido el otro afiche, la solución está en usar un solo proceso.

Fuente

2012-07-10 00:00:45 EJP

Estoy teniendo el mismo problema, y pensé que SO_REUSEADDRESS evita ese error. Pero luego los mensajes de devolución no son recogidos por el proceso de escucha, a menos que lo inicie luego de que el proceso de envío vincule el puerto. Según entiendo, esa opción se usa para "multidifusión" (que no creo que sea mi caso), pero ¿hay alguna forma de usarla para que los mensajes enviados al puerto 6666 vayan al proceso que desea recibirlos, en lugar del proceso más reciente para vincular el puerto? – Edmund

@ Edmund Los mensajes deben ir a todos los procesos que se reciben desde ese puerto. – EJP

Por "procesos que están recibiendo", ¿te refieres a aquellos que están vinculados a él, o aquellos que llaman 'recvfrom'? Da la casualidad, los datagramas UDP parecen ser recogidos de manera confiable solo por el proceso más reciente para enlazar. Incluso si ese proceso nunca llama 'recvfrom', todavía detiene que el otro no reciba nada. Pero esta discusión de comentarios se está llenando, así que haré una pregunta por separado e incluiré mi código, a menos que pueda pensar en algo simple que probablemente me esté perdiendo. ;-) – Edmund

Uso de netcat para enviar un paquete UDP sin enlace

Respuesta

Cuestiones relacionadas