Filed here because the samoyed fork has issues disabled; this is the tracking issue referenced by packet-net/samoyed#3 (the revert).
Symptom: after several AX.25 bulk-transfer sessions each torn down mid-flight by KISS TCP disconnect, the simulated channel wedges permanently: the next session cannot complete a SABM/UA handshake; the TNC logs Waited too long for clear channel. Discarding packet below. and every subsequently queued frame eventually drains into that discard path. Only restarting the TNC process recovers.
Bisection (all on net-sim main, two-node afsk1200 topology, packet.net tools/Packet.LinkBench as the driver):
Repro: run 6× LinkBench --channel netsim --payload 16k --k 4 --run-timeout-s 25 (each times out mid-transfer and disconnects its KISS clients), then one clean --payload 2k --k 2 probe. Probe fails on the flush build, passes on the others.
Mid-wedge state (SIGQUIT goroutine dumps): both TNCs structurally idle — xmit threads parked in tq_wait_while_empty, KISS client readers in conn.Read, recv threads in stdin read; net-sim's txReaders/rxFeeders/watchdogs all in their normal select/read states. No deadlock anywhere; the frames are accepted, queued, then discarded by wait_for_clear_channel timing out (hdlc_rec_data_detect_any reporting busy for 60 s+). Suspicion: an interaction between tq_flush_matching/ax25_delete on flushed frames and channel/DCD or render state — possibly a frame freed by the flush while still referenced somewhere in the transmit/render path. Not yet pinned down.
Interim state: flush reverted (packet-net/samoyed#3); the echo-timing fix and the #2 tq lost-wakeup fix are retained and validated. The motivating problem (a departed client's frames continuing to air) is mitigated host-side for test workloads (per-run SSIDs + post-unclean-teardown settle in LinkBench). A redesign should probably mark frames as abandoned for the xmit thread to skip at dequeue (no list surgery, no delete from a second thread) instead of removing+deleting them out from under the queue.
🤖 Generated with Claude Code
Filed here because the samoyed fork has issues disabled; this is the tracking issue referenced by packet-net/samoyed#3 (the revert).
Symptom: after several AX.25 bulk-transfer sessions each torn down mid-flight by KISS TCP disconnect, the simulated channel wedges permanently: the next session cannot complete a SABM/UA handshake; the TNC logs
Waited too long for clear channel. Discarding packet below.and every subsequently queued frame eventually drains into that discard path. Only restarting the TNC process recovers.Bisection (all on net-sim main, two-node afsk1200 topology, packet.net
tools/Packet.LinkBenchas the driver):Repro: run 6×
LinkBench --channel netsim --payload 16k --k 4 --run-timeout-s 25(each times out mid-transfer and disconnects its KISS clients), then one clean--payload 2k --k 2probe. Probe fails on the flush build, passes on the others.Mid-wedge state (SIGQUIT goroutine dumps): both TNCs structurally idle — xmit threads parked in
tq_wait_while_empty, KISS client readers inconn.Read, recv threads in stdin read; net-sim's txReaders/rxFeeders/watchdogs all in their normal select/read states. No deadlock anywhere; the frames are accepted, queued, then discarded bywait_for_clear_channeltiming out (hdlc_rec_data_detect_anyreporting busy for 60 s+). Suspicion: an interaction betweentq_flush_matching/ax25_deleteon flushed frames and channel/DCD or render state — possibly a frame freed by the flush while still referenced somewhere in the transmit/render path. Not yet pinned down.Interim state: flush reverted (packet-net/samoyed#3); the echo-timing fix and the #2 tq lost-wakeup fix are retained and validated. The motivating problem (a departed client's frames continuing to air) is mitigated host-side for test workloads (per-run SSIDs + post-unclean-teardown settle in LinkBench). A redesign should probably mark frames as abandoned for the xmit thread to skip at dequeue (no list surgery, no delete from a second thread) instead of removing+deleting them out from under the queue.
🤖 Generated with Claude Code