Estou tentando enviar comandos para uma porta tcp usando netcat e resposta de canal |
quando eu executo netcat e digito o meu comando ele imprime a resposta corretamente, mas quando eu passar o comando de um pipe ele envia o comando corretamente mas não imprime resposta
Então, isso funciona corretamente:
netcat localhost 9009
enquanto isso apenas envia o comando, mas não imprime resposta:
echo 'my_command' | netcat localhost 9009
por quê?
Como posso fazer netcat para imprimir o texto de resposta?
Como @Patrick disse, esse problema geralmente ocorre devido a netcat ter saído antes que a resposta seja dada. Você soluciona isso adicionando -q 2 à linha de comando, ou seja, informe netcat para esperar cerca de 2 segundos após a detecção de EOF na entrada padrão. Obviamente, você também pode esperar alguns segundos.
Use isto:
cat <(echo command) - | nc host port
O problema é que nc fechará a conexão imediatamente após stdin ser fechado, o que é muito rápido para uma simples string my_command , e assim nunca terá a chance de receber uma resposta. (Se você enviar um arquivo muito grande, verá que ele pode receber uma resposta antes de enviar o arquivo).
Digite cat com - como segundo argumento: Faz com que cat ouça em stdin para mais conteúdo no canal após enviar o conteúdo do primeiro argumento. O primeiro argumento é apenas pegar o comando echo através de cat - ele também pode ser um arquivo com seus comandos a la cat < file - | ... .
Como alternativa, faça isso:
(echo command; while true; do sleep 0.01; echo -n "#"; done) | nc host port
Isso envia caracteres # ilimitados na segunda linha da entrada. Usar # funciona como um controle remoto que ignoraria isso como um comentário. Eu escolhi um pequeno tempo de espera de 10 milissegundos aqui, então ele reage mais rápido no final da conexão. YMMV.
A desvantagem disso pode ser que cat ou while loop e nc continuem sendo executados até você atingir ^C ou ^D no shell. Isso realmente depende do fim remoto.
Adicionar um tempo limite usando -w 1 (OSX netcat) ou -i 1 (nmap's ncat) faz com que feche a conexão e nc após 1 segundo, mas cat continuará funcionando até que você digite algum caractere e o canal quebra (eu acho).
No entanto, funciona se o lado remoto fechar automaticamente a conexão depois de receber e manipular o comando - isso também encerrará o nc client e o processo de piping nele.
Esta resposta é baseada nesta esta resposta a uma pergunta de superusuário idêntica .
Diferentes versões do openbsd-netcat são peculiares, precisando de combinações diferentes de -w <seconds> , -q <seconds> , -N e até mesmo de argumentos diferentes dependendo do que está sendo executado na outra extremidade da conexão. O uso de opções de tempo limite com determinadas versões ou servidores causa atrasos, e não usá-los pode resultar em um atraso extremamente longo (infinito?). E eu esperaria diferentes peculiaridades com o gnu netcat, mas não sei se elas são diferentes entre versões dele.
Por exemplo, a versão 1.130_3 do archlinux demora muito (para sempre?) quando eu faço isso:
$ echo response | nc -l 9999 &
[1] 15190
$ time echo request | nc localhost 9999
request
response
(wait forever possibly)
Mas funciona com -N adicionado ao servidor ou ao cliente.