your mail
Chris Hammack (chammack@cse.unl.edu)
Wed, 29 Jul 1998 00:06:43 +0200
>
> 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).
Yes it is always the same...
This should say "Kearney Public Schools Sun Network; Unauthorized access
Prohibited.;blue!login:"
_uaruy ]ubl}s Sxoo}s S}~ N}twork
]~au}xor}zed=qcc}ss }roh}rit}t
bl}u!lwin:
As you can see if you know what it's supposed to say you can kind
of make it out.
An interesting note is that I can actually log in and run commands on the
system but everything is so garbled up it's impossible to tell
what's really going on--but you can tell the commands you are running
are being executed.
>
> > 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)
>
No, it's not compiled in.
> [..]
> > 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.
>
I might be lost but I was unable to find a jumbo tty patch for
Solaris 2.5.1. I should note that I have the "recommended" and
"year2000" patchsets installed from Sun.
>
> 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.
>
If anyone has suggestions please contact me directly at chammack@cse.unl.edu
-- I do not subscribe to the list this was cc'd to
Thanks,
Chris