Primeiramente, se você está lidando com um appliance / iOT com um espaço limitado, eu lidaria com a saída no lado de chamada, ou seja, usando o > depois dos comandos ssh como em
ssh "command" > output.txt
Quanto a tcpdump , eu não o mataria como uma política o tempo todo, arriscando perder buffers. Você pode não ter saído talvez por causa disso.
Eu colocaria um limite nos pacotes capturados. Eu também tentaria não resolver o DNS. Como em, para capturar 100 pacotes:
tcpdump -nc 100 -i eth0 port 5600
Quando você está armazenando o arquivo de captura no sistema local, só deve executar cat localmente e não remotamente e localmente.
Da mesma forma, quando você está executando os níveis tcpdump e cat remotamente, você está lançando os dois ao mesmo tempo e tanto ocat local quanto o remoto não terão nada para mostrar.
Seguindo a sugestão de @MarkPlotnick, também adicionei -l a tcpdump para torná-la em buffer. Isso pode evitar a necessidade da opção -c . Eu usaria ambos.
Então, eu mudaria esse script para:
#!/bin/bash
html_tcpdumpfile=$(mktemp)
ssh remotemachine.mydomain.net "timeout -t 20 tcpdump -nlc 100 -i eth0 port 5060 " > $html_tcpdumpfile
cat $html_tcpdumpfile
rm $html_tcpdumpfile
Ou talvez nem precisemos criar explicitamente um arquivo temporário:
#!/bin/bash
ssh remotemachine.mydomain.net "timeout -t 20 tcpdump -nlc 100 -i eth0 port 5060 " \
| less
Por fim, aconselho a exclusão de todos os arquivos temporários criados, especialmente no lado remoto.
PS: o OP mencionado nos comentários do sistema remoto é BusyBox e, como tal, as opções timeout são diferentes do pacote coretutils . Eu também edito a pergunta para ela mencionar o BusyBox.