Re: New package: suite3270-3.2.20-1
On Tue, 18 Nov 2003, Corinna Vinschen wrote:
On Mon, Nov 17, 2003 at 02:51:15PM -0800, Peter A. Castro wrote:
After getting a successful login I did the following:
[EMAIL PROTECTED] ~ $ od -c
ret
ret
ret
ctrl-j
ctrl-j
ctrl-j
ctrl-d
000 \0 \n \0 \n \0 \n \0 \n \n \n
012
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 crnul
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
Hmm, I had a look into telnetd and it actually does conform to RFC 854,
AFAICS. There's a function called telrcv(), which apparently cares
for receiving characters from the client side. There's this stuff in
the code:
case TS_CR:
state = TS_DATA;
/* Strip off \n or \0 after a \r */
if ((c == 0) || (c == '\n')) {
break;
}
/* FALL THROUGH */
case TS_DATA:
[...]
As it turns out, telnetd is operating in so-called LINEMODE. An
explanation of linemode is given in telnetd/termstat.c though it's
not entirely clear to me how it works, admittedly. Linemode seems
to speed up the connection at least.
The idea behind line-mode is that the client is suppose to do local
editing of the input and only transmit data when enter or some other
flush/sync character is received as input.
The other mode is typically called character-at-a-time or kludge
linemode in which all characters are sent, real time, and the client
does no editing or buffering.
Anyway, if linemode is enabled (which is negotiated on server startup),
telnetd never calls the above code, since a few lines below it turns a
\r into a \n. When compiling telnetd without -DLINEMODE, that telnetd
is able to operate with c3270 as expected. It's also able to work
fine with a Linux and the Cygwin telnet client.
What's interest to me is that a c3270 trace shows that the Cygwin telnetd
is sending DO LINEMODE but c3270 is responding with WONT LINEMODE
which is supposed to mean that telnetd should not assume LINEMODE
semantics. A normal telnet client (using the toggle options command)
flow often shows DO LINEMODE, intially, but after some additional
options are exchanged, later flows a DONT LINEMODE. I haven't studied
the BSD code in detail, and so can't really say what's going on.
Alternatively, with other telnetd's (ie: Linux, AIX, Solaris) the telnet
flow is often DONT LINEMODE initially. I tried starting the telnetd
with the -k option, but to no avail.
On the other hand, telnetd on BSD systems is by default also build
with linemode on! So it's not quite clear to me what to do or if I
should do anything at all.
I think this is just one of those odd peculiarities of telnet protocol
implementation and not something you need to address. Again, c3270 isn't
really ment to be used as a normal NVT client anyways.
Corinna
--
Peter A. Castro [EMAIL PROTECTED] or [EMAIL PROTECTED]
Cats are just autistic Dogs -- Dr. Tony Attwood
Re: New package: suite3270-3.2.20-1
On Mon, Nov 17, 2003 at 02:51:15PM -0800, Peter A. Castro wrote:
After getting a successful login I did the following:
[EMAIL PROTECTED] ~ $ od -c
ret
ret
ret
ctrl-j
ctrl-j
ctrl-j
ctrl-d
000 \0 \n \0 \n \0 \n \0 \n \n \n
012
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 crnul
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
Hmm, I had a look into telnetd and it actually does conform to RFC 854,
AFAICS. There's a function called telrcv(), which apparently cares
for receiving characters from the client side. There's this stuff in
the code:
case TS_CR:
state = TS_DATA;
/* Strip off \n or \0 after a \r */
if ((c == 0) || (c == '\n')) {
break;
}
/* FALL THROUGH */
case TS_DATA:
[...]
As it turns out, telnetd is operating in so-called LINEMODE. An
explanation of linemode is given in telnetd/termstat.c though it's
not entirely clear to me how it works, admittedly. Linemode seems
to speed up the connection at least.
Anyway, if linemode is enabled (which is negotiated on server startup),
telnetd never calls the above code, since a few lines below it turns a
\r into a \n. When compiling telnetd without -DLINEMODE, that telnetd
is able to operate with c3270 as expected. It's also able to work
fine with a Linux and the Cygwin telnet client.
On the other hand, telnetd on BSD systems is by default also build
with linemode on! So it's not quite clear to me what to do or if I
should do anything at all.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Developermailto:[EMAIL PROTECTED]
Red Hat, Inc.
Re: New package: suite3270-3.2.20-1
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 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. For the sake of testing I changed telnetd to using all binary mode. It didn't change anything. Finally I added a debug output to login.exe, to look what arives at login. The output is written using binmode explicitely, like this: FILE *fp = fopen (/var/log/login.log, ab); if (fp) fprintf (fp, Logon attempt: %s, pwd %s\n, username, pp); fclose (fp); The first line is what arrives at login when telnetting in using a telnet client on Linux (please ignore the file offsets, I had to extract the info from a file full of log): $ cat /var/log/login.log Logon attempt: corinna, pwd mypasswd $ od -c /var/log/login.log 272 L o g o n a t t e m p t : 312 c o r i n n a , p w d m 332 y p a s s w d \n Next, the log from trying to login using telnetd as from the current package (using textmode). I tried three times, the first and second using the Enter key, the third using Ctrl-J: $ cat /var/log/login.log Logon attempt: corinna, pwd Logon attempt: , pwd Logon attempt: , pwd mypasswd $ od -c /var/log/login.log 135 L o g o n a t t e m p t : 155 c o r i n n a , p w d 175 \n L o g o n a t t e m p t : 215 , p w d\n L o g o n 235 a t t e m p t : , p w 255 d m y p a s s w d \n 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. 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?!? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
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 crlf, if the crlf telnet option it enabled, otherwise, it sends crnul ((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 crnul 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: [EMAIL PROTECTED] ~ $ od -c ret ret ret ctrl-j ctrl-j ctrl-j ctrl-d 000 \0 \n \0 \n \0 \n \0 \n \n \n 012 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 crnul 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 crnul that has this requirement. [snip] 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 crnul is actually being sent as part of the data stream to login. So, in the case of the above, login sees: useridcr \0passwordcr 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 crnul 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 crlf problem). Corinna -- Peter A. Castro [EMAIL PROTECTED] or [EMAIL PROTECTED] Cats are just autistic Dogs -- Dr. Tony Attwood
New package: suite3270-3.2.20-1
Daniel, et. all, This is a re-proposal of a package set for a suite of 3270 emulators. I've given it much thought and reorganized things based on various peoples suggestions. The suite is composed of one base package, suite3270-3.2.20-1, and several independent binary packages which reference the base package: suite3270-3.2.20-1 == http://www.fruitbat.org/Cygwin/suite3270/setup.hint.suite3270 http://www.fruitbat.org/Cygwin/suite3270/suite3270-3.2.20-1.tar.bz2 http://www.fruitbat.org/Cygwin/suite3270/suite3270-3.2.20-1-src.tar.bz2 c3270-3.2.20-1 == http://www.fruitbat.org/Cygwin/suite3270/setup.hint.c3270 http://www.fruitbat.org/Cygwin/suite3270/c3270-3.2.20-1.tar.bz2 pr3287-3.2.20-1 === http://www.fruitbat.org/Cygwin/suite3270/setup.hint.pr3287 http://www.fruitbat.org/Cygwin/suite3270/pr3287-3.2.20-1.tar.bz2 s3270-3.2.20-1 == http://www.fruitbat.org/Cygwin/suite3270/setup.hint.s3270 http://www.fruitbat.org/Cygwin/suite3270/s3270-3.2.20-1.tar.bz2 tcl3270-3.2.20-1 http://www.fruitbat.org/Cygwin/suite3270/setup.hint.tcl3270 http://www.fruitbat.org/Cygwin/suite3270/tcl3270-3.2.20-1.tar.bz2 x3270-3.2.20-1 == http://www.fruitbat.org/Cygwin/suite3270/setup.hint.x3270 http://www.fruitbat.org/Cygwin/suite3270/x3270-3.2.20-1.tar.bz2 I've decided to not prefix each emulator with the base package name. This is in keeping with how this suite is distributed in other distributions. If people can find them there they can find them here the same way. Each emulator is a distinct and separate binary package. This means the name space will be scattered, but I feel this is how it should be. People looking for 'x3270' will be looking for it under that name, not under a prefixed name of 'suite3270-x3270'. Each emulator has a specific purpose and usage and is only slightly complimentary to each other. I'd like to address a problem Corinna encountered while reviewing a previous incarnation of this suite: 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 could be a weird interaction having to do with ipc pipes and how carriage control is done, or perhaps it's one of the telnet protocol options (eg: crlf) causing carriage control to be translated into CR+LF. Unfortunately none of the 3270 emulators lets you set any of the normal telnet options which might help control this behaviour. This is largely because most of these options are ignored once a 3270 mode is negotiated. For what it's worth, I've connected to other unix (Linux, AIX, Solaris) telnet servers, which apparently do not have this problem. Only with the Cygwin telnet daemon does this appear to happen. A debug session of the telnet daemon and/or login would be needed to diagnose things further (something I don't really have the time to do). If you wish, at the login and password prompts, press Ctrl-J (LF) instead of Return and you can successfully login. However, you can't do all that much after logging in, unless you happen to have a termcap entry for 'ibm-3279-4-e' :) -- Peter A. Castro [EMAIL PROTECTED] or [EMAIL PROTECTED] Cats are just autistic Dogs -- Dr. Tony Attwood
