You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In some cases, Direwolf sends an inaccurate 'Y' response to an AGW client, indicating there is one frame outstanding, waiting to be transmitted. But all frames have been transmitted. It should send Y=0.
The circumstances in which this occurs seem quite specific. In my case, I connect to a BBS and send a 'b' command; the BBS responds by disconnecting immediately. Next, I connect to the same BBS, using the same TCP connection to Direwolf. At this point, Direwolf is stuck on Y=1. The attached file Y1.txt shows this behavior. It's output from Direwolf with the command line option "-d au". The inaccurate Y values appear after 11:58:09.
The behavior seems correlated with the remote call sign. If I connect to a different BBS (using the same TCP connection to Direwolf), the connection starts correctly with Y=0. If I go back and connect to the problematic BBS, the connection starts with Y=1.
I used Windows 8.1, Direwolf version 1.7 and a DRA-65 audio adapter.
The text was updated successfully, but these errors were encountered:
This is likely related to the cause of issue #534 as described here: #534 (comment)
The data being collected for the 'Y' response is coming from the same data structure maintained in list_head. Since this data structure is never cleaned up, the second connection is reusing the same instance that was created for the first connection. That instance may contain stale data left over from the first connection that is now being provided as if it was relevant to the second connection.
In some cases, Direwolf sends an inaccurate 'Y' response to an AGW client, indicating there is one frame outstanding, waiting to be transmitted. But all frames have been transmitted. It should send Y=0.
The circumstances in which this occurs seem quite specific. In my case, I connect to a BBS and send a 'b' command; the BBS responds by disconnecting immediately. Next, I connect to the same BBS, using the same TCP connection to Direwolf. At this point, Direwolf is stuck on Y=1. The attached file Y1.txt shows this behavior. It's output from Direwolf with the command line option "-d au". The inaccurate Y values appear after 11:58:09.
Y1.txt
The behavior seems correlated with the remote call sign. If I connect to a different BBS (using the same TCP connection to Direwolf), the connection starts correctly with Y=0. If I go back and connect to the problematic BBS, the connection starts with Y=1.
I used Windows 8.1, Direwolf version 1.7 and a DRA-65 audio adapter.
The text was updated successfully, but these errors were encountered: