[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

telnetd is not 8-bit clean?



I have connection between two computers as follows:

[ C ]--telephone line--[ P ]--ethernet--[ S ]

where C is the client on whose terminal I am, P
is a modem server that allows me to call to it,
and connect to S, which is the server I use.

Connection from P to S goes with the telnet protocol.
So, S is running telnetd so that I can log in.
I want to establish TCP/IP connection from C to S
and finally to the whole Internet. For this I am
using slirp on S and pppd on C.

I can get my hands to C and S, but not on P or the
lines between them. The problem seems to be in S:
everything worked before I installed Woody in S.
Before that I used RedHat 6.2 on S and the line
was perfectly clean: I didn't need to escape any
characters and everything worked fine.

The problem is, that after I installed Woody on S,
it stopped working. It looks like some characters
would not get over the line. When I first run slirp on S
and then pppd on C, I get weird error messages (shown below).

I also tried to transfer files with plain zmodem and sz/rz,
and the results were, that
- Upload from C to S works, but not well. Often the
  transferred byte counter jumps backward for a few kilobytes
  and pauses for a few seconds. However, it always finished
  successfully. The average bps rate stays at about 18000 even
  though it should be 28800.
- Download from S to C doesn't work: usually the line hangs
  just when I start the transfer. Actually I was able to download
  a small uuencoded file, but never a binary one.

So, it certainly looks like the line wouldn't be clean for
all characters. However, when specifically testing this, I can not
verify it. I used the linecheck program from the term package
(old program, but appears not to be part of Debian).
It reported that all characters were passed successfully over the
line, in both directions. Despite this, I tried setting slirp and
pppd to escape all characters between 0x7e--0xff and did set
asyncmap to ffffffff. Didn't help anything.

I suspected that the problem was with Debian slirp binary,
so I copied a known-to-work version from the RedHat. Nothing changed.
Where the problem could be? telnetd is the only program that
comes to my mind, anything other? Maybe I should copy the working
telnet daemon from RedHat to Debian? Any suggestions?

Jan 19 17:12:20 datazone pppd[193]: pppd 2.4.0b4 started by root, uid 0
Jan 19 17:13:00 datazone pppd[193]: Serial connection established.
Jan 19 17:13:00 datazone pppd[193]: Using interface ppp0
Jan 19 17:13:00 datazone pppd[193]: Connect: ppp0 <--> /dev/modem
Jan 19 17:13:02 datazone modprobe: can't locate module ppp-compress-21
Jan 19 17:13:02 datazone modprobe: can't locate module ppp-compress-26
Jan 19 17:13:02 datazone modprobe: can't locate module ppp-compress-24
Jan 19 17:13:02 datazone modprobe: can't locate module ppp-compress-21
Jan 19 17:13:02 datazone modprobe: can't locate module ppp-compress-26
Jan 19 17:13:02 datazone modprobe: can't locate module ppp-compress-24
Jan 19 17:13:02 datazone pppd[193]: Could not determine remote IP address:
defaulting to 10.64.64.64
Jan 19 17:13:02 datazone pppd[193]: local  IP address 10.0.2.15
Jan 19 17:13:02 datazone pppd[193]: remote IP address 10.64.64.64
Jan 19 17:13:02 datazone pppd[193]: IPCP terminated by peer
Jan 19 17:13:05 datazone pppd[193]: Connection terminated.
Jan 19 17:13:05 datazone pppd[193]: Connect time 0.1 minutes.
Jan 19 17:13:05 datazone pppd[193]: Sent 251 bytes, received 295 bytes.
Jan 19 17:13:05 datazone pppd[193]: Hangup (SIGHUP)
Jan 19 17:13:05 datazone pppd[193]: Exit.

10.64.64.64 is a completely wrong address. Here's what stty -a shows:

speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W;
lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon
-ixoff
-iuclc -ixany -imaxbel
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0
ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke




Reply to: