> > This is bogus. A all-zero async map means that no characters are
> > escaped, so everything is transmitted as-is. So, so all those
> > "special characters" are still being transmitted over the link. Besides
> > "special characters" aren't supposed to cause retrains, because the
> > connection should be 8-bit clean.
> >
> > However, if your asyncmap contains a lot of bits, PPP will have to
> > escape a lot of characters, causing a lot of extra traffic to be
> > transmitted.
>
> Well, could Jaime's suggestion (see below) be possible then? It may be
> possible that DUN<->ComOs are trying to do both hardware and software flow
> controls at the same time, thus causing "confusion" and eventual
> "lockups".
>
> On Mon, 25 Aug 1997, Jaime Bozza wrote:
> >Looking at it deeper, the async map is turning off CTRL-S and CTRL-Q,
> >which are XON/XOFF ... Could software flow control be confusing
> >something
> >somewhere? That would certainly cause the modem to simulate a "lockup",
> >which is what causes the eventual "Call Circuit Disconnect" to show up.
What if the PM3, though set to RTS/CTS for flow control, has a bug that
under certain conditions it interprets XON/XOFF when it shouldn't? Could
this be causing the modem port to stop transmitting data?
While the async map might not be the actual problem, I'm still real
curious as to why the port completely locks.
(And I'm starting to get desperate here. Maybe that's why all this looks
like a possibility. <G>)
Jaime Bozza
Nucleus Communications, Inc.