try this: adb /usr/new/kermit Then run it and let it crash.  You'll get an adb prompt, look at the stack and see what system call number was pushed. I suspect it a versioning issue that Warner has been discussing as 2.X changed over time. That said, it might just be easier to try to recompile c-kermit. Clem On Sun, Aug 9, 2020 at 5:06 PM Will Senn &lt;will.senn(a)gmail.com <mailto:will.senn@gmail.com>> wrote: I'm running 211bsd pl 431 in SimH on FreeBSD. I've got networking working on a tap interface both inbound and outbound. I still have a few issues hanging around that are bugging me, but I'll eventually get to them. One that is of concern at the moment is kermit. It is in the system under /usr/new/kermit. When I call it, I get: kermit Bad system call - core dumped I don't see core anywhere and if I did, I'd need to figure out what to do with it anyway (mabye adb), but I'm wondering if anyone's used kermit successfully who is on pl 431 or knows what's going on? Thanks, Will -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF

Well, that sure sounds easy. I found the core file and figured out that: adb /usr/new/kermit kermit.core was the incantation to load stuff into adb. $c is the stack trace: $c 0177520: ~signal(016,01) from ~sysinit+034 0177542: ~sysinit() from ~main+010 0177560: _main() from start+0104 adb> ^D If this means it got signal 16... or 1 from the sysinit call (called from main), then according to man signal 16's urgent condition present on socket, and 01's just hangup. [...]