kTCP wedged by RST

Description

What is expected ? kTCP handles basic connectivity reliably
What is observed ? heap leaks and hangups on telnet + FTP

Configuration

Version (commit or release): master build
Emulator or HW platform: QEMU ne2k kvm

How to reproduce ?

Does the problem always happen ? even the minimal case - usually (leak/hang on first killed ftp upload)
List the steps to reproduce the problem

As easy as

timeout 1 bash -c "yes | curl -s --max-time 5 -T - 'ftp://$IP/k.txt' -u root:" >/dev/null 2>&1

The killed FTP upload triggers an RST which then leads to kTCP panic and then wedge. Note that on FDD images the timeout must be tuned down so that ftp upload writes ~50KB and does not fill the floppy and causes another bug.

Raw data

Screenshot(s):

Log file:

issue-stock-serial.log

Additional information
The vibe-coded fix is at duzenko@38bd6f4.
To review/understand it would strictly require a person with the kernel/kTCP communication knowledge, who I'm not regretfully.
It probably does something wrong/stupid, but still fixes the symptom and thus demonstrates the problem.
Note: I can still reproduce another wedge on a PM build in VBox with faster PCnet card, but QEMU is pretty stable with the fix.

@duzenko

Hello @duzenko,

Geez, sorry, I completely missed seeing this. I'll take a look and report back, thanks!

I'm trying to reproduce this on QEMU: I'm running macOS and it doesn't have timeout, so I'm trying to think of a way to force a RST to be transmitted. Any other ideas?

The vibe-coded fix is at duzenko@38bd6f4.

I've reviewed the fix, and I think it looks pretty good, but want to play with it a bit when I can get a RST to reproduce the bug.

ftp upload writes ~50KB and does not fill the floppy and causes another bug.

Does ftpd not return an error when it runs out of space? I can look into that also.

@duzenko

@duzenko,

Using the following shell script instead of timeout on macOS, and also just running curl and typing ^C to kill the connection (both which should send an RST?) and everything is normal on the ELKS/QEMU side, no errors and keeps working multiple times. That is, I can't yet get this to repeat. I added some debug code checking for RST received in ktcp in ESTABLISHED and SYNRECV states and apparently no RST is being sent by macOS on curl's forced TCP connection termination, it seems?

# Run command in the background
bash -c "yes | curl -s --max-time 5 -T - 'ftp://localhost:2121//file' -u root:" &

# Get the process ID
PID=$!

# Sleep for 1 second, then kill the process if it is still running
(sleep 1 && kill -HUP $PID) 2>/dev/null & watchers_pid=$!

# Wait for the main command to finish
wait $PID 2>/dev/null

The vibe-coded fix is at duzenko@38bd6f4.

I have more carefully reviewed your proposed fix, can you prepare a PR for it? Perhaps others can duplicate this on Linux. I would still like to be able to have some replication of the problem before committing a fix.

Thank you!

Are you running your QEMU with vt-x on? Or software emulation?

My AI says that your kill does not apply to curl itself and suggests to test with one of these

# faithful to the original — Homebrew coreutils, signals the whole process group
gtimeout 1 bash -c "yes | curl -s --max-time 5 -T - 'ftp://localhost:2121/file' -u root:"

# no install: drop the wrapper so $! is curl itself, and use a signal it can't catch
yes | curl -s --max-time 5 -T - 'ftp://localhost:2121/file' -u root: &
sleep 1
kill -9 $!

Or how about docker linux container?

BTW do you run ps in elks after each curl run?
Your repro seems to wedge it too, after maybe 10th run. Mine typically after 1-2.

do you run ps in elks after each curl run?

I'm seeing the un-reaped child of ftpd, is that what you're seeing? I will look into that, should be waited on by ftpd, but does correct itself after a couple commands.

Still not able to reproduce even with your suggestions. #2801 showed the same hang (caused by ktcp not returning a failure code, just like your AI found) but reproducible under some additional circumstances. I'm going to continue to try to put together a test harness to reproduce - both issues are definitely a bug and need fixing. I will keep you posted, thanks!

@duzenko

I have reviewed both @duzenko's code here as well as the many fixes in #2801. Both contain a similar but not identical fix for the reported ktcp hang/deadlock problem, which I know fully understand. @duzenko's code also contains three additional fixes which need to be handled.

I have created a list of all these and #2801's issues and will be submitting PRs to fix each of them as I am able to reproduce them.
@duzenko, no need to produce a PR at this point, lets keep this open until these are fixed which I hope to get done soon. Thank you.

@duzenko

@duzenko, #2809 should fix most all the issues you have run into here. Most of that PR consists of your vibe-coded proposal with a few mods, but I've also added a number of other fixes as well, as I'm back deep diving into the ktcp and kernel networking code. I'm still working on enhancements for better usage of ktcp's limited heap, so that SBRK FAIL messages can also be curtailed.

Please test when you have a minute and let me know the results, thanks!

Navigation Menu

Repository navigation

kTCP wedged by RST #2781

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

kTCP wedged by RST #2781

Description

Activity

ghaerr commented on Aug 5, 2026

ghaerr commented on Aug 5, 2026

ghaerr commented on Aug 6, 2026

duzenko commented on Aug 7, 2026

duzenko commented on Aug 7, 2026

ghaerr commented on Aug 8, 2026

ghaerr commented on Aug 9, 2026

ghaerr commented on Aug 11, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions