jr@oglvee.UUCP (Jim Rosenberg) (04/11/89)
Lately I've discovered that if a UNIX machine is answering the phone at 1200 baud and the caller is calling at 2400 in MNP auto-reliable mode, the MNP handshake seems to toggle the receiver's getty to 2400 just like that, just about every time. The modems in both cases are similar: Multitech external and Multitech internal. Both have MNP, but only the caller is in auto- reliable mode; the receiver is running plain vanilla. The manual describes the MNP handshake as a "Link Request". MNP functions with no start & stop bits, so I assume this Link Request is sent with no start & stop bits also. My understanding is that getty will be toggled by anything that looks like a null (0x0) -- and that's the *only* way getty toggles. (A break should appear as a null with a framing error at any baud rate.) Is the Link Request *guaranteed* to toggle getty? Under what combinations of baud rates? Or does this simply happen as a lucky accident? Lucky accidents do happen. It appears that if the caller is calling at 1200 and the receiver is answering the phone at 2400, if the caller transmits a CR the receiver will hear two bytes, one of which is 0x80. If getty is stripping parity this will come out as 0x0 and woila, getty will toggle. (Good luck going back!) What exactly is the composition of the Link Request? What will it look like to a modem not set up for MNP? More to the point, where can I read up on MNP? -- Jim Rosenberg pitt Oglevee Computer Systems >--!amanue!oglvee!jr 151 Oglevee Lane cgh Connellsville, PA 15425 #include <disclaimer.h>
davidsen@steinmetz.ge.com (Wm. E. Davidsen Jr) (04/12/89)
I have had really bad luck autobauding with MNP modems. They seem to
eat the BREAK sent by uucp to force baudrate change. Fortunately other
characters seem to work, but I don't see any incoming data when sending
BREAK.
I'm using MT224E and Micom (don't remember the model) modems.
--
bill davidsen (wedu@crd.GE.COM)
{uunet | philabs}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -mejac@penguin.UUCP (James Carter) (04/12/89)
In article <475@oglvee.UUCP>, jr@oglvee.UUCP (Jim Rosenberg) writes: > Lately I've discovered that if a UNIX machine is answering the phone at 1200 > baud and the caller is calling at 2400 in MNP auto-reliable mode, the MNP > handshake seems to toggle the receiver's getty to 2400 just like that, just > about every time. The modems in both cases are similar: Multitech external > and Multitech internal. Both have MNP, but only the caller is in auto- I'm pretty sure you have an accident here, but only because both of your modems are by the same manufacturer. I have been using the MT224EH as the only working modem on this 3B1 for about a year now, and had a devil of a time getting it set up properly. The modem serial port is strapped for NO-AUTO- BAUD, but the modem phone port is set to auto-baud. This forces the modem to buffer the data, and conduct speed changes. I also had to disable the modems own handshaking so that only the remote devices perform the xon/xoff (the modems do pass it through, but take no action). The cable had to be correct, the cpu port had to ignore dtr/rts/cts, the modems had to do the speed changes, and they had to ignore stop/start, before I finally got everything to work with lot's of different remotes. -- ========================================================================== Disclaimer: are you kidding? I own the place! James A. (JC) Carter Penguin Business Systems, Inc.
ram@tslanpar.UUCP (ram) (04/12/89)
Let me start by saying I'm running Microcom modems (9624s) which allow me to
set the serial port speed and modem speed to different values.
I end up with the gettys running at 19.2 and let the modems come to an
agreement on what speed they want to run all by themselves.
We have found that MNP class 6 modems running full out in error free (e
protocol) can hit around 15K baud.
Regards,
Richard Meestersdavid@ms.uky.edu (David Herron -- One of the vertebrae) (04/12/89)
When a pair of modems are negotiating MNP modes they're doing this
*AFTER* they've printed 'CONNECT' to their serial ports and they
do this by sending BREAKS at each other in particular ways.
I'd call it a lucky accident that it does something useful to the
getty. Normally you'd expect the getty to get confused because of
the noise it'd see.
--
<- David Herron; an MMDF guy <david@ms.uky.edu>
<- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<-
<- The problem with mnemonics is they mean different things to different people.ram@tslanpar.UUCP (ram) (04/13/89)
In article <11482@s.ms.uky.edu>, david@ms.uky.edu (David Herron -- One of the vertebrae) writes: > When a pair of modems are negotiating MNP modes they're doing this > *AFTER* they've printed 'CONNECT' to their serial ports and they > do this by sending BREAKS at each other in particular ways. > > I'd call it a lucky accident that it does something useful to the > getty. Normally you'd expect the getty to get confused because of > the noise it'd see. In my experience, the modems negotiate their MNP mode BEFORE they actually send the CONNECT message to the host. Using Uutry under Svr3.1 on an ATT3b2 computer, the modem (A Microcom 9624) establishes its connection speed (indicated by the color and flashing of the HS light), then sends CONNECT to the host. If it really was sending breaks after the connection, the getty would lose its mind and change baud rates several times. Regards, Richard Meesters. "I disclaim, Really I do!"
jr@oglvee.UUCP (Jim Rosenberg) (04/14/89)
In article <13575@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: > I have had really bad luck autobauding with MNP modems. They seem to >eat the BREAK sent by uucp to force baudrate change. Fortunately other >characters seem to work, but I don't see any incoming data when sending >BREAK. I will not profess to be a complete wizard on this subject, but I think the trick to getting BREAK to work with MNP is to put enough delays into your send sequence that the MNP handshake has had a chance to succeed or fail. I run a link with cgh. Paul Homchick (cgh!paul) instructed all his net neighbors to be sure to put some delays before sending a BREAK when he ran an MNP modem. I had my system set up so it wouldn't send BREAK til the first timeout, & that always worked just fine. What has me puzzled is just how MNP seems to toggle getty *WITHOUT SENDING* the BREAK. -- Jim Rosenberg pitt Oglevee Computer Systems >--!amanue!oglvee!jr 151 Oglevee Lane cgh Connellsville, PA 15425 #include <disclaimer.h>
jr@oglvee.UUCP (Jim Rosenberg) (04/14/89)
In article <11482@s.ms.uky.edu> david@ms.uky.edu (David Herron -- One of the vertebrae) writes: >When a pair of modems are negotiating MNP modes they're doing this >*AFTER* they've printed 'CONNECT' to their serial ports ^^^^^^^ You sure about this?? When I dial out auto-reliable to an MNP modem configured for auto-reliable there is a noticeable delay after the speaker shuts off and then I see the message: CONNECT RELIABLE I.e. it sure looks like the handshake happens *before* the CONNECT message is printed. >and they >do this by sending BREAKS at each other in particular ways. ^^^^^^^^^^^^^^ I'd like to know the details. If MNP is working without start & stop bits it would make sense for the dialing modem to send out its Link Request that way and see if it gets a valid response. It would make sense that this has to happen before it can print out the CONNECT RELIABLE message. If the answering modem is *not* in MNP auto-reliable mode it would indeed print CONNECT immediately -- but of course if you've got a getty connected to it you should have the modem in quiet mode, so it wouldn't print anything. (Unless you want all remote users to log in under the uid CONNECT! :-)) Help, We're just blundering around in the dark here: Is there an MNP wizard in the house? Who can really tell us in detail how the MNP handshake works?? Chuck Forsberg, you there?? -- Jim Rosenberg pitt Oglevee Computer Systems >--!amanue!oglvee!jr 151 Oglevee Lane cgh Connellsville, PA 15425 #include <disclaimer.h>
caf@omen.UUCP (Chuck Forsberg WA7KGX) (04/17/89)
In article <477@oglvee.UUCP> jr@.UUCP (Jim Rosenberg) writes:
:Chuck Forsberg, you there??
MNP Auto-Reliable has the calling modem interrogate the called
modem with a character sequence. Hayes AFT operates the
other way, with the called modem interrogating the calling
modem.
Suffice it to say that not all host systems do the "right"
thing when confronted with an MNP interrogation. That's why
Professional-YAM's dialing scripts (advpho.t for ZCOMM)
default to non-MNP unless specified.
Example:
exec-pcbbs if jMODEM,32 speed 19200 %l-414-963-3581/mnp_s; goto exec_pc1
speed 4800 %l-414-964-5160/mnp_s
If a V.32 modem is connected, call the special V.32 number with
a 19200 bps interface speed and MNP with software handshaking
(useable on Unix and Xenix). Otherwise use MNP with 4800 bps
interface speed.
Chuck Forsberg WA7KGX ...!tektronix!reed!omen!caf
Author of YMODEM, ZMODEM, Professional-YAM, ZCOMM, and DSZ
Omen Technology Inc "The High Reliability Software"
17505-V NW Sauvie IS RD Portland OR 97231 503-621-3406
TeleGodzilla:621-3746 FAX:621-3735 CIS:70007,2304 Genie:CAF