kissutil sends data before socket is created

[maqifrnswa]

If kissutil is started and told to parse existing files in a directory, it will fail with:

./kissutil -v -f files/
Processing filenameTest.txt for transmit...
KD9PDP>ND1U:test
Sending to KISS TNC:
  000:  c0 00 9c 88 62 aa 40 40 e0 96 88 72 a0 88 a0 e1  ....b.@@...r....
  010:  03 f0 74 65 73 74 c0                             ..test.
ERROR writing KISS frame to socket.

but subsequent files work fine:

Processing filenameTest2.txt for transmit...
KD9PDP>ND1U:test
Sending to KISS TNC:
  000:  c0 00 9c 88 62 aa 40 40 e0 96 88 72 a0 88 a0 e1  ....b.@@...r....
  010:  03 f0 74 65 73 74 c0                             ..test.

To quote Jeff N6BA

I think what needs to happen is when invoking kissutil with STDIN or having it watch a directory (kissutil -f…) there needs to be some logic in there to make transmissions wait until the TCP socket connection is created (or fails) from the tnc_listen_net thread.

See:
https://groups.io/g/direwolf/message/2631

Around:

direwolf/src/kissutil.c

Line 579 in fe6cba2

int rc = SOCK_SEND(server_sock, (char*)kissed, klen);

[craigerl]

Give kissutil a few seconds to connect with a stdin pipe. I'm not sure why but there is about a 10 second lag before direwolf actually transmits this. buffer flush maybe?

PACKET="$USER>APRS,WIDE1-1:$STRING"
{
sleep 5 # allow kissutil time to make connection
echo $PACKET
} | kissutil -h direwolf.hostname

[wb2osz]

Connecting to the KISS server is done in a different thread which is used to read. As a quick hack I put a half second delay in there before trying to send anything to the TNC. This could be improved by considering the actual connection status.
I won't see any obvious reason for a delay of about 10 seconds. Will get back to this later.

[craigerl]

thanks, on closer inspection, it's not waiting 10 seconds, probably waiting for a clear channel on the direwolf side.