netcat não termina quando stdin fecha

7

Estou tentando enviar uma mensagem por meio de netcat . Depois de enviar a mensagem, netcat deve terminar.

Eu tentei o seguinte:

cat tsmmessage.bin | nc -u localhost 4300
nc -u localhost 4300 < message.bin

A opção -q indica:

-q seconds

after EOF on stdin, wait the specified number of seconds and then quit. If seconds is negative, wait forever.

Mas

nc -q0 -u localhost 4300 < message.bin

também não funciona.

O que estou perdendo?

    
por Frank Kusters 11.03.2015 / 08:06

3 respostas

4

Supondo que após o envio da conexão EOF permanecerá ocioso, você pode usar a opção -w timeout , que funciona para timeout sendo igual a zero (diferentemente da% estúpida-q opção ...)

cat tsmmessage.bin | nc -u localhost 4300 -w0
    
por 22.11.2016 / 07:40
2

Sem o sinal -q , sua instância de netcat esperará para sempre. Não há nenhuma mensagem "end of stream" com UDP, portanto, não há como netcat saber que stdin e a conexão de rede foram concluídas.

Por exemplo, usando o TCP / IP, isso funciona como esperado:

nc -l localhost 4300                     # Window 1
nc localhost 4300 </etc/group            # Window 2

Mas, como você determinou, o uso do UDP / IP nunca termina:

nc -u -l localhost 4300                  # Window 1
nc -u localhost 4300 </etc/group         # Window 2

É aqui que entra a flag -q . Mas infelizmente não aceita um valor de 0 . Também não aceita valores não inteiros. Aqui está a melhor alternativa que posso oferecer sem recorrer a timeout ou alguma outra utilidade externa:

nc -u -l localhost 4300                  # Window 1
nc -q 1 -u localhost 4300 </etc/group    # Window 2

Mesmo aqui, não é possível ter o tempo de escuta netcat esgotado normalmente. (A opção -w timeout é ignorada e -q é irrelevante.) Algo como isso pode ser útil em uma situação prática, de modo que netcat seja eliminado após 90 segundos:

timeout 90 nc -u -l localhost 4300       # Window 1
nc -q 1 -u localhost 4300 </etc/group    # Window 2
    
por 27.07.2017 / 11:08
-1

Tropeçou nisso quando pesquisando sobre praticamente o mesmo problema. Descobriu-se que a questão era que o netcat foi morto por bash logo depois que todos os dados foram sugados, sem ter nenhuma chance de receber a resposta.

Minha solução para isso foi adicionar algum atraso após a inserção dos dados, assim:

(echo INFO; sleep 1) | nc redis.service.consul 6379

Com um arquivo, isso pode parecer:

(cat tsmmessage.bin; sleep 5) | nc -u localhost 4300

Espero que isso ajude qualquer um que chegar mais adiante em sua busca pela verdade.

    
por 01.06.2016 / 08:14

Tags