Date: Fri, 19 May 1995 17:43:27 +0200 (MET DST) From: sven@stack.urc.tue.nl (Sven Berkvens) To: wollman@halloran-eldar.lcs.mit.edu (Garrett Wollman) Cc: sven@stack.urc.tue.nl, freebsd-questions@FreeBSD.org, unix@stack.urc.tue.nl Subject: Re: Lots of questions Message-ID: <199505191543.RAA22906@zen.stack.urc.tue.nl> In-Reply-To: <9505191502.AA24815@halloran-eldar.lcs.mit.edu> from "Garrett Wollman" at May 19, 95 11:02:52 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > > I mention the above because it may have something to do with my qeustion: > > when I type 'arp -a' to view the ARP cache, all it says (on all three > > machines) is: > > > ? (0.0.0.0) at (incomplete) > > This is a fairly clear indication that your `arp' binary doesn't match > the kernel. Other route-related binaries use a different interface to > the kernel and would return an error if they were out of date, but > `arp' just reads the routing table and prints out those entries that > are related to the Ethernets. > Hmmm... Strange. I recompiled the source which came with the 2.0 RELEASE distribution, but to no avail - the binaries are identical. Oh well :) Can I gather from this that the kernel itself DOES know the ARP cache, ie. it does not do an ARP resolve for ervery packet it sends? > > > When ELM does a read(2) to check for terminal input, read(2) returns > > 0 (I guess as an EOF condition). > > Actually, it returns -1 (an error) with errno set to EIO because of a > bug. > Not in my version... I can give you a ktrace.out which I did of a hanging ELM if you want. read(2) returns 0. > > ELM interprets this wrong (so does TIN for example) and does not see > > this as an error; even worse, these programs interpret it as a > > keystroke. > > Yes. These programs are broken. This used to be a big problem with > `vi'. Terry Lambert will claim that this is a job control problem; I > don't believe that. I have 'fixed' tin by adding a stupid little hack. There is a routine called ReadCh() in curses.c which reads a key amd returns EOF if there is an error. The rest of the program does NOT check for this EOF condition. What I did was fairly simple: return 'q' instead of 0. This makes the program quit automatically when there is an error :) > > > Why does the tty/pty immediate get chown(2)'ed back to root (and more > > important: who does this??) instead of leaving it behind as it was and > > then chown(2)-ing it to another user when necessary (like on SVR4)? > > Security. This greatly reduces the opportunity for someone to > ``capture'' a PTY before some unsuspecting (and broken) program tries > to open it. As to who does it, that's the responsibility of the > exiting telnetd, rlogind, or xterm. > Any program can still connect (the mode is 666). I've tried it: for i in /dev/ttyp[p-s]? do cat "$i" & done This captures all available tty's. When someone logs in, I capture one or two keystrokes (I guess the data goes to a random party that is trying to read(2) that device). After that, the connection is broken (I read something about a generation number in kernel)./ > > Another question: is there a stat-daemon available for FreeBSD? > > Meaning what? > Meaning: we have an SVR4 computer as well who wants to mount some drives too. The shell on that computer tries to lock its .ksh_history, which it can't because there is no statd on the FreeBSD side. Result: a hanging flock(2) on the SVR4 side. > -GAWollman > Sven Berkvens (http://www.stack.urc.tue.nl/~sven/)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199505191543.RAA22906>