Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

C daemon creates a general protection fault when client disconnects #1456

Open
cpswan opened this issue Oct 16, 2024 · 2 comments · May be fixed by #1462
Open

C daemon creates a general protection fault when client disconnects #1456

cpswan opened this issue Oct 16, 2024 · 2 comments · May be fixed by #1462
Assignees
@cpswan @XavierChanth
Labels
bug Something isn't working

Comments

@cpswan
Copy link
Member

cpswan commented Oct 16, 2024 •
edited
Loading

Describe the bug

When a client disconnects from the C daemon (running on OpenWRT) a message like this shows in the system log:

[  344.115795] traps: sshnpd[2540] general protection fault ip:7f9a6e754edf sp:7ffecf34cf58 error:0 in libc.so[7f9a6e744000+4c000]

We also get this in the general logs:

Wed Oct 16 16:15:20 2024 authpriv.info dropbear[2541]: Exit (root) from <::1:40072>: Disconnect received
Wed Oct 16 16:15:20 2024 daemon.info sshnpd[1682]: [WARN] 2024-10-16 16:15:20.786001 | child_exit_handler | Received signal: 1853387673
Wed Oct 16 16:15:20 2024 kern.info kernel: [  344.115795] traps: sshnpd[2540] general protection fault ip:7f9a6e754edf sp:7ffecf34cf58 error:0 in libc.so[7f9a6e744000+4c000]

Steps to reproduce

  1. First I install the csshnpd package on an OpenWRT test VM
  2. Then I configure the daemon and copy a key in place
  3. And then I start the daemon
  4. Connect with sshnp from my WSL2
  5. Disconnect (cleanly) with ^d

Expected behavior

Normal operation of C daemon does not cause kernel traps.

Additional context

The daemon seems to survive this without being restarted by the init process.
@cpswan cpswan added the bug Something isn't working label Oct 16, 2024
@XavierChanth
Copy link
Member

Which version of the code is this running?
We currently have signal traps in place to try and exit cleanly in sshnpd when a ^C is sent, but maybe we should just ditch that idea altogether.

@cpswan
Copy link
Member Author

cpswan commented Oct 16, 2024

This is with c0.2.0

@XavierChanth XavierChanth linked a pull request Oct 18, 2024 that will close this issue
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@cpswan cpswan

@XavierChanth XavierChanth

Labels
bug Something isn't working
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

fix: don't try to safely exit if we receive SIGINT atsign-foundation/noports
2 participants
@cpswan @XavierChanth