Are you telnetting into netbsd/sun3 from a non NetBSD box?  If so, then
your problem is probably that the telnet daemon is going into linemode when
the client doesn't really understand the linemode option of the telnet
negotiation.  This is a problem with SunOS4 based telnet clients where the
client negotiates timing mark, and the telnet daemon on NetBSD interprets
that as a signal to go into linemode.  The fix is to compile the telnetd
with -DLINEMODE and -DKLUDGELINEMODE turned off.  (Actually, just turning
off -DLINEMODE will also turn off -DKLUDGELINEMODE because the second
cannot occur without the first being defined.  Also, just turning off
-DKLUDGELINEMODE is not enough.)
I believe Solaris 2 (SunOS 5) based clients work, but I don't know about
other vendor telnet clients.
-Brian

On Jan 23,  3:37pm, der Mouse wrote:
} Subject: Re:  mail signal handling...
} > Anyone else still use plain old mail?
} 
} Yes, me...though not on NetBSD. :-)  (I don't, yet, handle my mail on
} NetBSD; when I do, I'll be using my own UA, loosely patterned after MH.)
} 
} > If so, do you notice that ^C to interrupt letters may not work all
} > the time?  On my -current system, the first letter I abort works, but
} > any further attempts fail; I can only stop a letter by sending it, or
} > by killing mail outright.  This is a pain.
} 
} The reason I'm replying is that I too have seen some very strange
} behavior surrounding ^C (which is in fact my VINTR character).
} 
} In particular, sometimes (usually related to typing ^C at times when
} "things are changing", as the shell starts an application or as an
} application exits) the tty driver gets into a weird state where a ^C is
} "hanging fire".  In this state, (a) my shell, which normally does
} command-line editing, stops doing command-line editing, instead not
} echoing anything until I type RETURN and then echoing the whole thing,
} (b) commands built-in to the shell like "set" work normally, aside from
} the lack of echo and editing as I type them, (c) programs like ls that
} don't attempt to read any input run fine, producing output, though the
} shell is still weirded out when they exit, and (d) any program that
} tries to read input (cat is the one I canonically run when I notice
} this state) get an immediate SIGINT upon starting.  Interestingly, when
} a case (d) program starts, not only does the program die with SIGINT,
} but I see the ^C echoed to the pseudo-tty!  (I have never seen this
} happen on a "real" tty, but I use "real" ttys so seldom this is not
} surprising.)
} 
} This is almost the opposite of what you're seeing, but they are both
} weirdnesses surrounding ^C, so it's hard to think they're entirely
} unrelated.
} 
} The thing with the shell not doing command-line editing may or may not
} be significant.  I have not yet investigated enough to find out whether
} (i) the shell decides it's not talking to a tty (it makes this decision
} anew each time it goes to read a command line) or (ii) the tty driver
} isn't passing the bytes out to userland until an entire line has been
} typed.  I currently favor (ii) because _some_ command-line editing
} kinda sorta vaguely almost works (even though I get no echo I can do at
} least a little by typing blind).
} 
} The systems on which this happens are NetBSD/sun3 at approximately 1.2.
} 
} 					der Mouse
} 
} 			       mouse@rodents.montreal.qc.ca
} 		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
>-- End of excerpt from der Mouse