your mail

• Messages sorted by:[ date ][ thread ][ subject ][ author ]

Hi,

(CC:ing this to the mgetty mailing list, because some other reader might
have something to say -- please do not remove the CC:!)

Chris Hammack wrote:
[..]
> > > 2.  We have an old Sun ALM-2/mcp board.  it has 16 serial ports on it.
> > > It worked really well in SunOS 4.1.3 but we had to go to Solaris 2
> > > to run some apps that required it, and it has worked not nearly
> > > as well since then.  Anyhow, when you dial into one of these ports
> > > it throws the issue/login up but it is all garbled (you can read
> > > parts of it but some of the characters are mixed up).  I have
> > > tried different modems and cables, all the same result.
> > > 
> > > Strangely: if I open the port with tip, and answer the phone manually
> > > with an ATA, and send data from another modem, everything seems fine
> > > so it almost seems like maybe mgetty is not speaking in 8N1?
> > 
> > mgetty *is* speaking 8N1, as opposed to tip, which uses 7E1.  So, yes,
> > this could very well be a parity issue.
> > 
> > How did you "dial into one of those ports"?  If you used tip for that,
> > it's pretty clear - 7E1 on the calling end, 8N1 on the answering end...
> > 
> > (At least to my knowledge, tip still uses 7E1 as default).
> > 
> > > I have tried both the 1.0 release and the latest beta from July 5 and
> > > both produced the same results.
> > 
> > There are no differences regarding tty handling / parity in the last
> > couple of mgetty releases.  No change since 0.98 or so :-)
> > 
[..]
> Well, I think you are right about tip being 7E1, but I have an
> entry in /etc/remote which makes it 8N1.

Hmmm.  How exactly does the "character mix up" look like?  Are always the
*same* characters broken in always the *same* way (which would hint at
a parity problem), or do the results differ (which would hint at some
other problem).

> Here is what I am doing to test:
> 
> On Macintosh workstation via ethernet, telnet into the system, run tip on the 
> term/1 port (the wierd serial card).  Sit on the port.
> 
> Use Macintosh to dial modem (using Zterm) in 8n1.  Dial the number of
> the modem we're sitting on with tip.
> 
> Run ATA on the tip'd modem.   Modems connect.  I can send data (large
> text files even) back and forth without any corruption.

Then the parity settings should be ok, yes.

(You don't happen to use mgetty with "USE_GETTYDEFS" compiled in? If
you did so, switch it off, you don't want it, and it could be the
cause of your problems)

[..]
> I was considering not to worry about the multiplexor  by using your
> callback program: set a modem on the port that seems to work
> and have one of the multiplexor's modem's call back the user.
> Well, as it turns out, the multiplexor's not dialing out either
> with callback.
> 
> it does this:
> 
> 07/27 15:40:13 a/1  send: ATQ0V1H0[0d]
> 07/27 15:40:13 a/1  waiting for ``OK''
> 07/27 15:40:13 a/1   got:

This could be the famous SunOS/Solaris jumbo tty bug.  If the carrier 
detect (DCD) line is low, and the port is set to RTS/CTS flow control,
it won't receive ANY data anymore.  This is a well-known bug, and there
exist patches for it, but SunSoft is just not able to *integrate* those
patches into new operating system releases.

Look for the "jumbo tty patch", patch number is mentioned in the
mgetty Makefile.


In sendfax, I work around this problem, by not enabling RTS/CTS flow
control until after I know that DCD should be set, but it's possible that
I didn't bother to do that effort for "callback".  I will look into this.

gert
-- 
Gert Doering
Mobile communications ... right now writing from *AWAY* :-)) 
... mobile phone: +49 177 2160221 ... or mail me:  gert@greenie.muc.de