lwIP sockets: a peer reset does not wake processes blocked in socket:send/2 or recv
Maintainers usually reply within 3 days
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 57/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- c, embedded-iot, erlang
- Domain
- backend, networking
Research direction
Read tcp_err_cb in src/libAtomVM/otp_socket.c, then compare its connected-socket handling with socket:close/1 and send_closed_notification. Check how the read and write selecting flags and their owners are handled, keeping in mind lwIP has already freed the pcb when this callback runs. Done means a peer reset wakes processes blocked in send/2 or recv, with no pcb function called after the reset.
Written by the indexing model from the issue text.
Description
On platforms using lwIP (rp2), tcp_err_cb in src/libAtomVM/otp_socket.c only answers a process trapped in socket:connect/2. For a connected socket it resets socket_state to SocketStateTCPConnected, which drops the SocketStateSelectingRead/SocketStateSelectingWrite flags, and nobody is notified.
Since #2345, socket:send/2 waits for write-readiness with nif_select_write/2 when the send buffer is full. If the peer sends a RST while a process is blocked there (or blocked in recv), the process stays blocked forever. A later socket:close/1 cannot abort it either, because the selecting flag was cleared.
Possible direction: in tcp_err_cb, for a connected socket, notify the owner of each selected direction (as socket:close/1 does with send_closed_notification) and keep the flags consistent, instead of resetting the state. Note that lwIP has already freed the pcb when tcp_err_cb runs, so tcp_pcb must be set to NULL and no pcb function may be called.
This was listed as a known limitation in #2345 and raised by @bettio in the review, where a follow-up issue was requested. Related: #2424.
- Dominant language
- Erlang
- Stars
- 2.3k
- Forks
- 171
- Avg merge
- 4d 11h
- Merged PRs (30d)
- 20
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from atomvm/AtomVM
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 3 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 3 days
-
lwIP sockets: a failed listen or connect leaves the socket lock held, a later close hangs foreverOpen
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Maintainers usually reply within 3 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 3 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 3 days
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
milind-soni/OpenMausBot#5829 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 80/100
finos/fluxnova-bpm-platform#387 ·
Maintainers usually reply within 4 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
OHDSI/Data2Evidence#3693 ·
Maintainers usually reply within 3 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Project-N-E-K-O/N.E.K.O#3725 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
kubernetes-sigs/headlamp#8408 ·
Maintainers usually reply within 1 day