O problema foi que eu esqueci de incluir ", pty" como uma opção para o EXEC: "/ usr / sbin / pppd ...", então o pppd estava silenciosamente travando.
Estou executando o NetBSD 6.1.4 e tenho uma instância stunnel com a seguinte configuração:
[https service]
accept = 443
CAfile = /u01/usbtether/CA/certs/rootCA.crt
cert = /usr/pkg/etc/stunnel/stunnel.pem
pty = yes
exec = /usr/sbin/pppd
execargs = pppd call phone
verify = 2
client = no
Tudo funciona bem, exceto por uma contagem crescente de erros de rx no outro lado. Eu quero comparar o tráfego do ppp antes e depois de deixar o stunnel. Minha estratégia até agora é usar socat. Eu mudei as linhas exec para apontar para um script de shell como
#!/bin/sh
socat -,echo=0,raw SYSTEM:'tee /root/pppd-in.log | socat -,echo=0,raw EXEC:"/usr/sbin/pppd call phone" | tee /root/pppd-out.log'
Mas eu não consigo pegar meus patos em uma fileira. Eu consegui fazer o loopback de tudo que o outro pppd envia, ou ignorar tudo que o outro pppd envia, mas não consigo obter a sintaxe correta para realmente passar os dados entre stunnel e pppd enquanto também descarrego entrada e saída em um arquivo (embora eu apenas me importe) sobre a saída).
Eu também tentei
#!/bin/sh
/usr/sbin/pppd call phone | tee /root/serial-out.log
Mas eu apenas pareço enviar um jargão de volta para o pppd de chamada (eu suponho que o pipe através do tee é como não incluir raw in socat?).
Então, qual é a melhor maneira de espionar os dados em um PTY?
Para maior interesse, os dados que recebo do outro lado do stunnel são ocasionalmente embaralhados um pouco. Por exemplo, posso receber um quadro ppp com um pacote IP de comprimento 100, seguido por um 0x7e e 10 bytes adicionais. Outro quadro, (que pode ter chegado vários quadros antes ou depois do quadro com bytes extras) chegará com um pacote IP que está faltando 8 bytes. Se eu pegasse esse pedaço extra e o colocasse no final, eu teria, presumivelmente, o pacote IP correto mais o FCS. Minha intenção com o snoop PTY é verificar se o pppd está enviando os dados assim (já que o pedaço faltando é sempre precedido por um byte 0x7e, acho que isso é provável), ou se algo estranho está acontecendo em trânsito.