[net.unix] Telnet problems

deb@gt-cmmsr.UUCP (Deborah Jackson) (02/05/86)

We have a very strange problem with our telnet program.  Our Vax 11/780
is running 4.2BSD (BRL) UNIX(TM).  The problem is that it seems to have
its own version of flow control which follows no protocol.  Whenever invoked,
either through our ethernet to our Data General or through the software
loop-back to itself, it stops after a seemingly arbitrary number of 
characters.  Typing any character (except ^S) causes it to continue
it's output.  Those characters are stored up (i.e. type-ahead) and
displayed after it's finished cat'ing a file, etc.  Since any character
will restart it, it's impossible to interupt a program's output -- ^Z
doesn't work either.  (It's a general nuisance.)

Here are the things I know for sure:
 1) It doesn't matter whether the built-in flow control switch is set or not
 2) telnet from the Data General to the Vax works just fine, so I don't 
    think it's a psuedo-port problem or a telnetd problem.
 3) Decreasing BUFSIZ (to force more flushes) helps a little, but doesn't
	solve the problem.
 4) rlogin works just fine (but the DG can't handle it--otherwise I wouldn't
	care if telnet worked or not!)
 5) ftp also runs without a hitch.

I've worked on several Vaxen running 4.2BSD and never seen this problem.
I've also never worked on a Vax with dmf32's before now, which leads me 
to believe they are the culprit.

Has anyone ever seen this problem?  Has anyone run telnet with dmf32's???
Any suggestions are greatly appreciated.

Thanks in advance,
Deb


-- 
Deborah Jackson

School of Electrical Engineering, Georgia Tech, Atlanta, GA 30332
uucp:  ...!{akgua,allegra,hplabs,ihnp4,seismo,ulysses}!gatech!gt-eedsp!deb
                                                                 ^^^^^

chris@umcp-cs.UUCP (Chris Torek) (02/06/86)

This is a bug in the dmf32 driver.  I have seen several versions
of the driver with the same bug (including one I was running for
some time; I fixed it about an hour after posting it to net.sources,
as I recall . . .).

Look at /sys/vaxuba/dmf.c.  Find the routine `dmfstart'.  It will
have a few lines commented something like this:

	/*
	 * If there are sleepers, and output has drained below low
	 * water mark, wake 'em up.
	 */

The code under this comment *should* look like this:

	if (tp->t_outq.c_cc <= TTLOWAT(tp)) {
		if (tp->t_state&TS_ASLEEP) {
			tp->t_state &= ~TS_ASLEEP;
			wakeup((caddr_t)&tp->t_outq);
		}
		if (tp->t_wsel) {
			selwakeup(tp->t_wsel, tp->t_state & TS_WCOLL);
			tp->t_wsel = 0;
			tp->t_state &= ~TS_WCOLL;
		}
	}

but the `if (tp->t_wsel)' clause is missing.  Add it, compile and
boot the new kernel, and all should be well again.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1415)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@mimsy.umd.edu

abe@pucc-j (Vic Abell) (02/06/86)

In article <134@gt-cmmsr.UUCP> deb@gt-eedsp.UUCP (Deborah Jackson) writes:
>
>We have a very strange problem with our telnet program.  Our Vax 11/780
>is running 4.2BSD (BRL) UNIX(TM).
>. . .  Whenever invoked,
>either through our ethernet to our Data General or through the software
>loop-back to itself, it stops after a seemingly arbitrary number of 
>characters. . . 
>I've also never worked on a Vax with dmf32's before now, which leads me 
>to believe they are the culprit.

Yes, the problem is a missing selwakeup() call in dmfstart() of dmf.c.
One should be inserted after line 533 (approximately):

dmfstart(tp)
	.
	.
	.
		if (tp->t_wsel) {
=====>			selwakeup(tp->t_wsel, tp->t_state & TS_WCOLL);
			tp->t_wsel = 0;
			tp->t_state &= ~TS_WCOLL;
		}