Thread View: comp.sys.next.sysadmin
2 messages
2 total messages
Started by Joe Rosenfeld
Fri, 30 Oct 1992 18:54
Need to find a way to change comm parameters in Telnet session
Author: Joe Rosenfeld
Date: Fri, 30 Oct 1992 18:54
Date: Fri, 30 Oct 1992 18:54
26 lines
1454 bytes
1454 bytes
I have an unusual problem, which I am hoping some NeXTGuru and Internet/Telecommunications expert might have some insight into. I work at a University Law Library, where we use the internet for many things. One of our vendors, mead Data central, the creator of Lexis, has an unusual telecommunications system situation. When we telnet to the site on ANY platform, without using emulation software not available for the NeXT, we get a screen full of garbage. I have discovered that the reason for this garbage is that Lexis expects to see a 7-e-1 communications setup and the telnet session is eight bits. The problem is whether this can be somehow patched or configured into my NeXT telnet session, so that it appears or IS running as a 7-e-1 setup over internet telnet. Can this be done? any advice is appreciated. thanks and regards- Joe -- ----- ----------- Joe Rosenfeld cowboy@trans.csuohio.edu Automation Librarian joer@inca.law.csuohio.edu
Re: Need to find a way to change comm parameters in Telnet session
Author: Eric P. Scott
Date: Wed, 04 Nov 1992 03:55
Date: Wed, 04 Nov 1992 03:55
56 lines
2869 bytes
2869 bytes
In article <1992Oct30.185456.18118@news.csuohio.edu>
cowboy@trans.csuohio.edu (Joe Rosenfeld) writes:
>I work at a University Law Library, where we use the internet for many
>things. One of our vendors, mead Data central, the creator of Lexis, has
>an unusual telecommunications system situation. When we telnet to the
>site on ANY platform, without using emulation software not available for
>the NeXT, we get a screen full of garbage. I have discovered that the
>reason for this garbage is that Lexis expects to see a 7-e-1
>communications setup and the telnet session is eight bits.
Then they're violating protocol and are 100% responsible for
correcting the problem.
[RFC 1123]
| In NVT mode, a Telnet SHOULD NOT send characters with the
| high-order bit 1, and MUST NOT send it as a parity bit.
>The problem is whether this can be somehow patched or configured into my
>NeXT telnet session, so that it appears or IS running as a 7-e-1 setup
>over internet telnet. Can this be done? any advice is appreciated.
Telnet connections do not--and must not--operate 7-E.
If you are using a terminal that requires 7-E-1 (unusual these
days, but for the sake of argument), everything to the left of
the point I've labeled "demarcation" would have parity stripped
on input and generated on output; everything to the right would
be 7-N.
[view with fixed-pitch font]
demarcation
|
v
+---+ serial +------+
|TTY|--------|telnet| IP network
+---+ line |client|============>
+------+
In the inverse case, where a so-called "milking machine" is used
to make hard ports available via telnet service, the same rule
applies: the terminal server is responsible for making any
necessary conversions. NeXT's telnet client doesn't provide a
mechanism to to this because it's not supposed to!
The bottom line is: if the telnets at each end are operating with
the default modes, you should never see high bits on. If,
however, you've negotiated BINARY transmission (you can determine
this by using telnet's "toggle options" command), you should get
an 8-bit-clean path--but that's still a NO PARITY configuration.
When you pay big bucks to a commercial service provider, you
expect them to perform a competent job. The situation you
describe is inexcusable.
-=EPS=-
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads