The following is based on my limited understanding. I could easily be
wrong. Please correct me if I am.
On 11/13/19 12:25 AM, Jim Brain via cctalk wrote:
Some time ago, Chris Osborn (FozzTexx) forked a copy of my project to
fix some bugs and he also added in some parity code, which looks to
strip parity from the incoming serial connection (in the case that the
serial port is set as 8N1 and the computer attached to it sends in 7E1
or similar.
Are you sure that the parity stripping (for lack of a better
description) was meant to translate things between modems? I would
speculate that it was to transition from serial communications which
inherently depend on those settings to TCP connections (raw / cooked /
NVT / etc.) which inherently don't use those settings.
I am working to merge in all of his changes into the mainline codebase,
but I am unclear on prpper Hayes behavior. His Readme says:
"I also made the modem routines automatically detect parity and ignore it
in AT commands and print out modem responses in matching parity. Parity
is *not* stripped when sending data over the connection, which is how a
real modem behaves. This may or may not be what you want. Some servers
will expect an 8 bit connection and may not work."
Did Hayes modem really do that? I thought most later modems self
detected parity and speed and thus would have switched both the comm on
the serial port and the data sent to the other side in the same parity
(if the terminal was 7E1, the modem would configure as 7E1 and send 7
bit data to the other side.
My limited understanding is that modems were largely transparent to
serial communications. In that once the modems established the
connection, they blindly passed data back and forth, much like a null
modem would do. As such, devices on either end of the serial link would
need to be configured identically to be able to communicate with each other.
This makes me think that traditional modems would NOT alter ~> translate
communications parameters as data went through the modem.
But, maybe real modems did as Chris notes.
I'm guessing that modems did detect what settings were in use so that
they could match them to properly recognize and understand modem (AT)
commands. But I suspect that's the extent of what the detection was
used for.
Anyone have guidance on this? The goal of tcpser is to emulate a Hayes
modem as much as possible, but I never really thought about mismatched
parity on the RS232 line and how to deal with it.
--
Grant. . . .
unix || die
