search for: devcrypto

...fusing it. This seems like a reasonable explanation based on what I've seen so far. > It's not a configuration we test, so you're mostly on your own to debug it. It's entirely possible there's a bug there; if so, I'd expect it to be something like a fd being closed while devcrypto is still depending on it. > > I'd suggest turning on LogVerbose=* so you can see which process (represented by it's PID) is doing what, though that probably won't be represented in the devcrypto debug messages unless you hack something similar in. Too bad, I was hoping it was a te...

...39;s possible sshd's multiprocess model and/or file descriptor handling is confusing it. It's not a configuration we test, so you're mostly on your own to debug it. It's entirely possible there's a bug there; if so, I'd expect it to be something like a fd being closed while devcrypto is still depending on it. I'd suggest turning on LogVerbose=* so you can see which process (represented by it's PID) is doing what, though that probably won't be represented in the devcrypto debug messages unless you hack something similar in. On Tue, 8 Oct 2024, Peter Rashleigh wrote...

...uire open descriptors to devices. Also note that this could be a loadable module. >> It's not a configuration we test, so you're mostly on your own to debug it. It's entirely possible there's a bug there; if so, I'd expect it to be something like a fd being closed while devcrypto is still depending on it. >> >> I'd suggest turning on LogVerbose=* so you can see which process (represented by it's PID) is doing what, though that probably won't be represented in the devcrypto debug messages unless you hack something similar in. > Too bad, I was hopin...

...then tried upgrading to openssh 9.8p1, openssl 3.3.2, and cryptodev-linux 1.13. Now, the session starts and I get a login prompt. After authentication, the MOTD and LastLog are printed, but then the session is terminated. The output of '/usr/sbin/sshd -ddd' is below. Note the "error in devcrypto" message - this happens because of an ioctl call (CIOCCPHASH) for a non-existent session ID (details below). .... Starting session: shell on pts/0 for engadmin from 192.168.254.45 port 51222 id 0 debug2: fd 4 setting TCP_NODELAY debug3: set_sock_tos: set socket 4 IP_TOS 0x48 debug2: channel 0...