From owner-freebsd-hackers Tue Sep 10 19:15:52 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA01325 for hackers-outgoing; Tue, 10 Sep 1996 19:15:52 -0700 (PDT) Received: from nexgen.ampr.org (max14-130.HiWAAY.net [206.104.17.130]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA01313 for ; Tue, 10 Sep 1996 19:15:41 -0700 (PDT) Received: (from dkelly@localhost) by nexgen.ampr.org (8.7.5/8.6.12) id VAA12315; Tue, 10 Sep 1996 21:14:25 -0500 (CDT) Message-ID: X-Mailer: XFMail 0.5-alpha [p0] on FreeBSD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Tue, 10 Sep 1996 20:30:38 -0500 (CDT) Organization: Amateur Radio N4HHE, Madison, AL. From: David Kelly To: hackers@freebsd.org Subject: pty's and slattach Cc: Jim Durham , John Perry Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In the amateur radio world where Linux dominates amateur radio operators have their (our) own suite of network protocols, namely AX.25. Linux developers have built AX.25 support into Linux kernels, yet there are many Linux users that don't use that mode for one reason or another. One of many derivatives of Phil Karn KA9Q's NET/NOS is usually run in DOS to produce an advanced network node. There are two (that I know of) derivatives for Un*x, WAMPES (out of Germany?) and TNOS (out of Tampa, FL) that continue the DOS tradition under Un*x... until something better comes along. Ok, so far we've got a single large do-everything binary that implements a BBS, telnet, ftp, nntp, smtp, slip, ppp, etc, over AX.25. But no connection back to the Un*x kernel. Whats currently used in Linux is a SL/IP connection thru a pty/tty pair. In TNOS an attach line to the kernal migh look like this if connecting to a host named "bsd": attach asy ttypf - slip bsd 2048 1024 38400 And you'd like to catch that slip connection (on the FreeBSD side) with: slattach -l -L /dev/ptypf or similar. Of course you should realize by now it works somewhere else but not in FreeBSD. What we get in /var/log/messages is: Sep 10 19:53:08 nexgen slattach[11472]: ioctl(TIOCSCTTY): Operation not permitted No telling what will break next when we get that fixed. :-) Studying /usr/src/sys/kern/tty_pty.c I find no mention of TIOCSCTTY. No wonder its not permitted. Studying /usr1/src/sbin/slattach/slattach.c we find: /* acquire the serial line as a controling terminal. */ if (ioctl(fd, TIOCSCTTY, 0) < 0) { syslog(LOG_ERR,"ioctl(TIOCSCTTY): %m"); exit_handler(1); } I don't know how to run gdb thru a daemon(0,0), but I'm quite sure this is where the error message originates and slattach quits. A bandaid approach would be to bypass the above in slattach. But I don't know enough about *why* the author of slattach.c wants to be a controlling terminal to be confident about skipping the ioctl(). And I don't know enough about the operation of the pty driver to be able to add support for TIOCSCTTY or answer the question, "why isn't it in there already?" Am going to start digging thru my texts and see what I can learn about terminal I/O. Gotta figure out what a "controlling terminal" is. And this other stuff about "process groups". Obviously lots of stuff works very well thru pty's. The most correct fix would be to take the amateur radio code and teach it to connect to the tun device directly. Or the sl devices. But for now I'd like to get this other stuff working thru pty. Oh, and before I forget to mention I'm running something between 2.1.0R and 2.1.5R.... if it makes any difference. Should I grab -current? Any suggestions? -- David Kelly N4HHE, dkelly@tomcat1.tbe.com (wk), dkelly@hiwaay.net (hm) ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system.