wb2osz
Windows Direwolf eventually crashes when connected to RMS Packet via network KISS
Windows 10
I start up Direwolf 1.8 - configured to listen on a KISS port on localhost.
Next, I start RMS Packet that is configured to use network KISS using the port specified above on localhost.
If there is a lot of packet traffic on the frequency the radio is listening to (but may, or may not be directed at the system above), I see:
Received frame queue is out of control. Length=…. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another. application is not reading the frames from the other side.
This spins in the Direwolf console until Direwolf crashes (presumably with a buffer overflow.)
Note that no pseudo terminals since this is Windows.
Are there any workarounds?
Thanks Andrew
John,
Thanks for getting back to me on this!
I'm launching Direwolf 1.8 from a batch file (can't believe I said that - I'm a Unix guy) and there is nothing on the command line (i.e. no flags set).
Regards Andrew
On Fri, 7 Nov 2025 at 07:01, wb2osz @.***> wrote:
wb2osz left a comment (wb2osz/direwolf#620) https://github.com/wb2osz/direwolf/issues/620#issuecomment-3503048532
What is on the direwolf command line?
— Reply to this email directly, view it on GitHub https://github.com/wb2osz/direwolf/issues/620#issuecomment-3503048532, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMXPLT224HXEJ3EFF2BORML33SX5VAVCNFSM6AAAAACLM76FM2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKMBTGA2DQNJTGI . You are receiving this because you authored the thread.Message ID: @.***>
Depending on how much traffic "a lot of packet traffic" is, might it be possible that RMS Packet can't read and process the KISS frames coming from Direwolf fast enough to keep up? Admittedly, that would need to be a lot of traffic indeed. In that type of situation, Direwolf would block, waiting to send frames, until the client catches up. That, in turn, would cause Direwolf's received frame queue to back up, waiting for a chance to send more frames to the client.
If you have some other KISS client that you could use in place of RMS Packet to test this possibility, that might be a useful data point. Perhaps something that doesn't do anything other than log incoming packets, so that there's almost no work to be done for each received packet.
If you don't have anything handy, and you're minimally familiar with Python, you could try the 'listen' example that comes with PyHam AX.25. After installing the package, run:
$ python listen.py -k localhost:8001
(adjusting host and port as necessary). You'll see each packet displayed as it's received from Direwolf.
Martin,
Yeah, when I say "a lot of traffic" I'm talking relatively. There are intense bubbles of traffic - where an AUXC might be sending a form, then retries sending, but they are very short lived. The total payload is tiny - maybe 5 kbytes.
It's worth noting that there are two Winlink systems, one RMS - using Direwolf, and a post office about a mile away that uses soundmodem, on the same frequency both hear traffic directed at both. So there is inbound traffic but unhandled by the RMS should it be going to the P.O. or vice versa. Since a Winlink RMS keeps the socket to direwolf open continually, I wonder if the inbound buffer is overflowing even if some of the traffic is not being handled by the RMS.
Regarding Python - I used this for a good dozen years as a professional programmer. So, yes, I have no problem monitoring the port KISS port - thanks for pointing me in that direction!
I'll do some more observing also to see if I can isolate the conditions that's triggering this behaviour.
When I have a moment, I'll reconfigure the RMS using Direwolf to use AGW rather than KISS to see if that exhibits the same behaviour.
Kind regards Andrew
This is the first time I've heard of the "Received frame queue is out of control" error without "-p" on the command line. Let's gather more information and get this resolved.
The message is issued when later processing can't keep up with the received packets. The received packet queue is a linked list with dynamically allocated elements so the queue can't fill up until malloc() fails. It might just be a matter of increasing the threshold for reporting an issue.
Could you be more specific about what you mean by "crash?"
"kissutil" included with direwolf can also be used to monitor received packets from the KISS interface.
73, John WB2OSZ
I'm almost done adding a new debug option so we can see what is going on with the queue.
73, John WB2OSZ
I did three things to help investigate, and hopefully, solve the problem.
(1) Annoying warning messages now start at queue length of 40 rather than 10. This is not only received packets. Various other events go into the queue for processing.
(2) As Martin suggested, it might be that the TCP KISS client app is not reading the packets quickly enough and the TCP socket send buffer is filling up, the socket write is blocking, and items are not being removed from the queue. A possible solution might be adding "TCP_WMEM 1048576" in the configuration file.
(3) If that fails, add "-dq" option to the direwolf command line to enable debug output so we can see what is going on.
You can find the most recent build here: https://github.com/wb2osz/direwolf/actions/runs/19392352822/artifacts/4577534746 Look inside the zip file inside the zip file and find direwolf.exe in there.
73, John WB2OSZ