mmorse@Z.NSF.GOV ("Michael H. Morse") (11/01/90)
I am having a problem getting Xmodem to work between a Sun workstation
and a PC running a terminal emulator.
The PC uses a modem and a dial-up line to communicate, but it cannot
get to the workstation directly because the workstation has no serial
ports. Instead, the PC logs on to some other host, and then uses
telnet to get to the workstation.
We have a 3Com terminal server that is normally used in this situation,
but we've found that Xmodem does not work (the PC nacks everything it
gets) in this configuration. However, if the PC logs onto one of our
Ultrix hosts, and in effect uses it for a terminal server to telnet to
the workstation, Xmodem works fine. Subsequent tests have absolved the
terminal emulator (on the PC) and the xmodem program on the
workstation, leaving suspicion around the telnet implementation
on the terminal server.
I suspect this has something to do with parity, since the ASCII
characters transmitted by Xmodem, and received by the PC are
identical. Has anybody run into a similar problem? Any information on
how telnet reacts when raw mode is selected would be appreciated.
Thanks in advance.
--Mike
--
Michael Morse Internet: mmorse@note.nsf.gov
National Science Foundation BITNET: mmorse@NSF
Telephone: (202) 357-7659
FAX: (202) 357-7663BILLW@MATHOM.CISCO.COM (William Chops Westfield) (11/01/90)
Even when transferring text files, XMODEM needs a clear 8-bit path to accomadate its block counts and checksum. By definition, telnet is a 7 bit protocol, and you must negotiate "binary" mode to get an 8-bit path. The terminal server may be refusing binary mode negotiations, may just do binary incorrectly, or may just need configured differently. Also, some telnet implementations ignore the "7-bit" definition, and routinely send 8 bit data anyway. This is useful, but means that a telnet terminal server strictly adhering to the standard might not work as well as one with a more flexible interpretation. The Hosts Requirement document was carefully worded to allow 8-bit transmission, as long as you were doing actual "parity". Bill Westfield cisco Systems. -------
gpz@ESD.3Com.COM (G. Paul Ziemba) (11/02/90)
BILLW@MATHOM.CISCO.COM (William Chops Westfield) writes: >Even when transferring text files, XMODEM needs a clear 8-bit path to >accomadate its block counts and checksum. By definition, telnet is a >7 bit protocol, and you must negotiate "binary" mode to get an 8-bit >path. The terminal server may be refusing binary mode negotiations, >may just do binary incorrectly, or may just need configured differently. Unfortunately, I did not read the original query, so I'm guessing that the original poster (someone @z.nsf.gov) is trying to establish an 8-bit path from a 3com terminal server. This can be done...the following settings are needed: fcf=n flow-control-from disabled fct=n flow-control-to disabled bra=ig break-action ignore ecmc=d escape-cmd-char disabled depending on the comserver software version, you may also need to set xb=on transmit binary enabled lbra=l local-break-action listen (so you can break the connection locally) If that doesn't answer the original question, well, then, never mind :-) ~!paul -- Paul Ziemba api!gpz gpz@ESD.3com.com 408.764.5390 OS/2: just say no. "How much char could a char star star if char star could star char?" (quote stolen from mspercy@clemson.clemson.edu)
mperlman@Encore.COM (Mark Perlman) (11/02/90)
In article <9010312149.AA07742@z.nsf.gov> mmorse@Z.NSF.GOV ("Michael H. Morse") writes: > ... >I suspect this has something to do with parity, since the ASCII >characters transmitted by Xmodem, and received by the PC are >identical. Has anybody run into a similar problem? Any information on >how telnet reacts when raw mode is selected would be appreciated. Mike: I had a similar problem with uucp through a CMC Terminal Server. I had written a "reverse telnet" program to set a permanent circuit from the server to the host. To make a long story short, I found out that typically, telnet uses 7-bit mode, however, it is an option that is negotiable. It may be that Ultrix may default to 8-bit mode and the 3Com terminal server may default to 7-bit. The 3Com TS may not support 8-bit mode? I not sure about that. Hope that helps. +----------------------------------------------------------------------+ | Mark R. Perlman | | Independent Consultant 301-206-2016 | | 14014 Oakpointe Dr. mperlman@encore.com | | Laurel, MD 20707 uunet!gould!mperlman | +----------------------------------------------------------------------+
srodawa@vela.acs.oakland.edu (Ron Srodawa) (11/03/90)
Another thing to watch out for with 3COM terminal servers is the setting for Net AScii. It can be either UseLF or UseNul. Flip it and see if it fixes things. (This changes whether a CR si followed by a NUL or by a LF character on the net. Some systems don't care. Others go bonkers if the setting is wrong.) -- | Ronald J. Srodawa | Internet: srodawa@unix.secs.oakland.edu | | School of Engineering and CS | UUCP: srodawa@egrunix.UUCP | | Oakland University | Voice: (313) 370-2247 | | Rochester, Michigan 48309-4401 | |
mbt@bridge2.ESD.3Com.COM (Brad Turner) (11/03/90)
mmorse@Z.NSF.GOV ("Michael H. Morse") writes: >I am having a problem getting Xmodem to work between a Sun workstation >and a PC running a terminal emulator. >The PC uses a modem and a dial-up line to communicate, but it cannot >get to the workstation directly because the workstation has no serial >ports. Instead, the PC logs on to some other host, and then uses >telnet to get to the workstation. >We have a 3Com terminal server that is normally used in this situation, >but we've found that Xmodem does not work (the PC nacks everything it >gets) in this configuration. However, if the PC logs onto one of our >Ultrix hosts, and in effect uses it for a terminal server to telnet to >the workstation, Xmodem works fine. Subsequent tests have absolved the >terminal emulator (on the PC) and the xmodem program on the >workstation, leaving suspicion around the telnet implementation >on the terminal server. >I suspect this has something to do with parity, since the ASCII >characters transmitted by Xmodem, and received by the PC are >identical. Has anybody run into a similar problem? Any information on >how telnet reacts when raw mode is selected would be appreciated. >Thanks in advance. >--Mike >-- >Michael Morse Internet: mmorse@note.nsf.gov >National Science Foundation BITNET: mmorse@NSF > Telephone: (202) 357-7659 > FAX: (202) 357-7663 Mike, From your description above it sounds like you have the following topology. Ethernet | | Phone | PC--Modem1=========Modem2---TermServer-| Line | | |--WorkStation | If this is your topology then you should set up the termnial server parameters as follows for the duration of the Xmodem transfer: FlowControlTo=none FlowControlFrom=none BreakAction=(EscDTM) ECMChar=disable You can create a macro on the terminal server to do this and another macro to restore the parameters after the transfer. By default the terminal server attempts to negotiate a binary connection so the connection is 8-bits wide. It has been a while since I worked in tech support so let me know if this doesn't work (I'm winging it from memory.) I know that this can work since I've configured it and had it running in the past (Xmodem through our CS that is.) -brad- -- v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v Brad Turner |5400 Bayfront Plaza |Mktg.Engr.(408) 764-5261| I speak for myself 3Com Corp. |Santa Clara CA,95052|mbt@bridge2.ESD.3Com.Com| NOT for my employer
dab@BERSERKLY.CRAY.COM (David Borman) (11/05/90)
> Also, some telnet implementations ignore the "7-bit" definition, and > routinely send 8 bit data anyway. This is useful, but means that a > telnet terminal server strictly adhering to the standard might not work > as well as one with a more flexible interpretation. The Hosts Requirement > document was carefully worded to allow 8-bit transmission, as long as > you were doing actual "parity". ^^^^^^^^^^ > Bill Westfield That should have been "were NOT doing"... I assume that Bill just made a typeo. Everyone should be aware that the Hosts Requirement document was carefully worded to allow 8-bit transmission while in Telnet NVT mode, but we were very explicit that the eighth bit is NOT a "parity" bit, and any implementation that transmits 7-bit data with the eighth bit as a parity bit is broken. -David Borman, dab@cray.com
BILLW@MATHOM.CISCO.COM (William Chops Westfield) (11/06/90)
From: David Borman <dab@berserkly.cray.com> > you were doing actual "parity". ^^^^^^^^^^ > Bill Westfield That should have been "were NOT doing"... oops. It was a typo, and Dave is exactly correct. Sorry BillW -------
rxk@ain.ESD.3Com.COM (Rajeev Kochhar) (11/08/90)
mmorse@Z.NSF.GOV ("Michael H. Morse") writes: >I am having a problem getting Xmodem to work between a Sun workstation >and a PC running a terminal emulator. >The PC uses a modem and a dial-up line to communicate, but it cannot >get to the workstation directly because the workstation has no serial >ports. Instead, the PC logs on to some other host, and then uses >telnet to get to the workstation. >We have a 3Com terminal server that is normally used in this situation, >but we've found that Xmodem does not work (the PC nacks everything it >gets) in this configuration. However, if the PC logs onto one of our >Ultrix hosts, and in effect uses it for a terminal server to telnet to >the workstation, Xmodem works fine. Subsequent tests have absolved the >terminal emulator (on the PC) and the xmodem program on the >workstation, leaving suspicion around the telnet implementation >on the terminal server. >I suspect this has something to do with parity, since the ASCII >characters transmitted by Xmodem, and received by the PC are >identical. Has anybody run into a similar problem? Any information on >how telnet reacts when raw mode is selected would be appreciated. >Thanks in advance. >--Mike >-- >Michael Morse Internet: mmorse@note.nsf.gov >National Science Foundation BITNET: mmorse@NSF > Telephone: (202) 357-7659 > FAX: (202) 357-7663 The dicussion following the above posting raised a few points about the 3Com terminal server which I want to clarify. The server does support 8-bit (binary transmission) mode in Telnet. The server can initiate negotiation for 8-bit transmission any time during a session. When the server initiates a connection it negotiates 8-bit mode based on the setting of the XmitBinary (can be ON or OFF) parameter. Default value is off. When the terminal server is the server side of a connection it negotiates 8-bit mode by default. The server has a parameter called NetAscii which determines the character sequence transmitted when a <CR> is seen at the terminal port. Can be configured to transmit <CR><LF> or <CR><NULL>. However, in 8-bit mode, no extra characters are added to the data stream (i.e. NetAscii is ignored). For a completely transparent session the terminal parameters should be set as following: XmitBinary = ON FlowControlTo = none FlowControlFrom = none ECMChar = disable BreakChar = disable DataBits = 8 Parity = None Hope this helps, -Rajeev Kochhar 3Com Disclaimer: Comments reflect my own understanding and opinion.