This is the mail archive of the
mailing list for the Cygwin project.
Re: New package: suite3270-3.2.20-1
- From: "Peter A. Castro" <doctor at fruitbat dot org>
- To: cygwin-apps at cygwin dot com
- Date: Mon, 17 Nov 2003 14:51:15 -0800 (PST)
- Subject: Re: New package: suite3270-3.2.20-1
On Mon, 17 Nov 2003, Corinna Vinschen wrote:
> On Sat, Nov 15, 2003 at 12:15:16PM -0800, Peter A. Castro wrote:
> > On Sat, 1 Nov 2003, Corinna Vinschen wrote:
> > > Btw., I tried a test of the binary c3270.exe. From the man page I
> > > got the impression, the emulator should be able to connect to any
> > > telnet server. I don't have a OS/390 machine handy so I used the
> > > telnet server on Cygwin to connect to. But it fails. It connects
> > > and it shows a login prompt. Then the password is requested by login(1),
> > > the same as running a standard telnet session. But for some reason
> > > I'm always getting a "Login incorrect" message. When connecting with
> > > a normal telnet client, I can login, so I don't quite understand how
> > > this is supposed to work. Any hint?
> > This appears to be a CR/LF issue on the telnet server side of things. A
> > trace shows that on the client side, a Return sends only a CR (the
> > default key code for a Return). But, for whatever reason, the telnet
> > daemon is sending a CR+LF to the login program's input stream, so it sees
> > "userid^M" instead of "userid", which, obviously won't work. Same goes
> > for the password.
> It doesn't seem to be a CRLF/LF translation problem. First of all, the
After some further analysis, I agree, it's not a CR/LF problem, but it's
still a telnet daemon problem. See below.
> inetutils utilities are linked against /usr/lib/textmode.o which results
> in using textmode for all open descriptors, which haven't been explicitely
> opened in binmode. All pty related descriptors are not opened with
> O_BINARY. That means, telnet should filter out the CRs from all CRLFs.
Telnet has specific protocol control for handling carriage control.
Certain characters are special and treated in a special way. 0x00 is a
no-op character, meaning the daemon should not do anything with it. 0x0d
(<cr>) is carriage-return and 0x0a (<lf>) is line-feed. When an <eol> is
received by the telnet client, it transmits <cr><lf>, if the crlf telnet
option it enabled, otherwise, it sends <cr><nul> ((yes, 0x0d,0x00).
This is largely done by the client, but the server can request some
modifications. In c3270's case, the crlf option is off (with really no
way of turning it on), so it will always generate <cr><nul> as an <eol>
when Return is pressed.
I've just run an interesting little test and found what I think may be
the real problem.
After getting a successful login I did the following:
doctor@garfunkel ~ $ od -c
0000000 \0 \n \0 \n \0 \n \0 \n \n \n
Notice the \0's ? From above, if the crlf option is turned off, the
client sends 0x0d,0x00. It appears the telnet daemon is forwarding on
the 0x00 as part of the data stream. According to RFC 854, a <cr><nul>
combination is supposed to be treated as a straight carriage-return, so
the daemon is supposed to turn that pair of characters into a single <cr>
character. You can run c3270 in trace mode ("c3270 -trace <hostname>"
the trace appears in /tmp/x3trc.<pid>, make sure you don't have $DISPLAY
set) to see the data stream from the clients point of view. It's only
this special combination <cr><nul> that has this requirement.
> See what happens? No CR or LF in the name and in the password but...
> 1. The user name is ok when getting it from the command line (the first
> call to login by telnetd is done like this: `login -f name'.
> 2. In the second an third attempt, the user name is read from stdin by
> login directly. The username is never transmitted at all, regardless
> of using Enter or Ctrl-J.
> 3. The password is read from stdin by login in all three cases. For some
> reason the password goes through correctly when using Ctrl-J but not
> when using Enter.
It's because a <cr><nul> is actually being sent as part of the data
stream to login. So, in the case of the above, login sees:
And the first character the shell would see would be <\0>
> I also created a log with the telnetd which is using explicit binmode.
> The log is *exactly* the same as with the above standard telnetd so I
> don't repeat it here. As you noted, when using Ctrl-J on the first
> time I enter the username, it works. But as soon as login takes over,
> no chance anymore since the username never arrives at login.
> Unfortunately I don't see how that can be the fault of telnetd or login?!?
It really depends on weither telnetd is implementing <cr><nul> processing
correctly. As I've said, several other unix telnet daemons process this
correctly, so it's still a Cygwin telnet daemon problem (but not,
strictly, a "<cr><lf>" problem).
Peter A. Castro <firstname.lastname@example.org> or <Peter.Castro@oracle.com>
"Cats are just autistic Dogs" -- Dr. Tony Attwood