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:CAFjb@aablue.UUCP (John B Scalia) (04/18/89)
In article <260@jwt.UUCP> john@jwt.UUCP (John Temples) writes: >In article <13575@steinmetz.ge.com> davidsen@crdos1 (bill davidsen) writes: >> I have had really bad luck autobauding with MNP modems. > >Don't MNP modems let you lock the interface speed to the computer like the >Trailblazer does? Seems like this would eliminate the problem, since getty >only has to deal with one baud rate. They should be able to do this. I can only speak for Multitech units, but as the owner of a 224EH with MNP 5, I know it can be locked at a fixed speed to communicate with the CPU. Standard Disclaimer: I have no vested interest in Multitech or any any other hardware mfgr. for that matter. -- A A Blueprint Co., Inc. - Akron, Ohio +1 216 794-8803 voice UUCP: {uunet!}aablue!jb Marriage is a wonderful institution, but who FidoNet: 1:157/697 wants to spend their life in an institution. EchoNet: US:OH/AKR.0
ram@tslanpar.UUCP (ram) (04/20/89)
In article <565@aablue.UUCP>, jb@aablue.UUCP (John B Scalia) writes: > In article <260@jwt.UUCP> john@jwt.UUCP (John Temples) writes: > >Don't MNP modems let you lock the interface speed to the computer like the > >Trailblazer does? Seems like this would eliminate the problem, since getty > >only has to deal with one baud rate. > > They should be able to do this. I can only speak for Multitech units, but as > the owner of a 224EH with MNP 5, I know it can be locked at a fixed speed to > communicate with the CPU. Microcom's AX line of modems also allow the serial port to be set to a fixed speed. I currently have my 9624s set to run the serial port at a constant 19.2 Kbaud. And yes, it does eliminate the problem with getty. Regards, Richard Meesters
root@nebulus.UUCP (Dennis S. Breckenridge) (04/27/89)
In article <135@tslanpar.UUCP>, ram@tslanpar.UUCP (ram) writes: > In article <565@aablue.UUCP>, jb@aablue.UUCP (John B Scalia) writes: > > In article <260@jwt.UUCP> john@jwt.UUCP (John Temples) writes: > > >Don't MNP modems let you lock the interface speed to the computer like the > > >Trailblazer does? Seems like this would eliminate the problem, since getty > > >only has to deal with one baud rate. > > > > They should be able to do this. I can only speak for Multitech units, but as > > the owner of a 224EH with MNP 5, I know it can be locked at a fixed speed to > > communicate with the CPU. > > Microcom's AX line of modems also allow the serial port to be set to a fixed > speed. I currently have my 9624s set to run the serial port at a constant > 19.2 Kbaud. And yes, it does eliminate the problem with getty. > > Regards, > Richard Meesters I have to agree with Richard. The MNP modems that are available from the vendor world implement MNP class 1-x. From my expirience I have found that the only modems that do a good job of MNP protocol are MICROCOM modems (hence the name Microcom Network Protocol). In a series of tests performed with Microcom, Telebit, AT&T 2224CEO, AT&T2296, Racal Vadic and others I have found that the Microcom is a clear winner. I get consistant 1500 chrs/sec on a uucp transfer. The MC9624 will talk to ANY other modem that I connect to without ANY problems or magic dialer scripts (try a TB+ to a 3B1). The TB+ locks the baud rate both in and out, the MC9624 locks incomming only and autobauds on outgoing. My site consists of 4 9624's, 1 AT&T 2224CEO and 1 TB+. I have had many lock ups on the TB+ (power it down and up to clear it) I used the AT&T modem to talk to AT&T (note the path). All of my downstream sites use Microcoms. They just work! They are simple to set up (try that with a TB+). I really don't know why the U.S. usenet sites selected TB+'s other than price. There is no standard modem yet for usenet here in Canada and I would like to see Microcom get a fair shake. -- ============================================================================== "A mind is a terrible thing to MAIL: Dennis S. Breckenridge waste!" 206 Poyntz Ave North York, Ontario M2N1J6 (416) 733-1696 UUCP: uunet!attcan!nebulus!dennis ICBM: 79 28 05 W / 43 45 01 N 50 megatons should do! ==============================================================================
henry@utzoo.uucp (Henry Spencer) (04/29/89)
In article <827@nebulus.UUCP> root@nebulus.UUCP (Dennis S. Breckenridge) writes: >...the Microcom is a clear winner. I get consistant 1500 chrs/sec >on a uucp transfer... Is that compressed news, or plain ASCII text? >TB+ locks the baud rate both in and out, the MC9624 locks incomming only >and autobauds on outgoing. Curious, my recollection is that you can do that with a TB+. (We don't lock either way on ours, so I'm not sure.) >... I have had many lock ups on the TB+ (power it down and up to clear it) Power problems? Obsolete firmware? We've had none on our pair. >... I really don't know why the U.S. usenet sites selected TB+'s >other than price. There is no standard modem yet for usenet here in Canada >and I would like to see Microcom get a fair shake. Sorry, you're too late, Canada has gone TB+ too, although apparently you hadn't noticed. Most of the major news-distribution sites in Toronto and elsewhere use TB+s to move the data. -- Mars in 1980s: USSR, 2 tries, | Henry Spencer at U of Toronto Zoology 2 failures; USA, 0 tries. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
root@nebulus.UUCP (Dennis S. Breckenridge) (04/30/89)
In article <1989Apr28.192557.23991@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes: > Is that compressed news, or plain ASCII text? That's compressed news and various other uucp transfers (binary and ascii) > Curious, my recollection is that you can do that with a TB+. (We don't > lock either way on ours, so I'm not sure.) The TB+ locks the baud rate in and out. The only way to get a TB+ to work at 19200 is to lock the baud rate. What does your xferstats say about speed? (assuming of course you are running HDB) > Power problems? Obsolete firmware? We've had none on our pair. attcan and I constantly lock up as well as attnts. I know I have to go a reset all of the damn modems when they do. It appears to be power (roms are 4.0) > Sorry, you're too late, Canada has gone TB+ too, although apparently you > hadn't noticed. Most of the major news-distribution sites in Toronto and > elsewhere use TB+s to move the data. Dont count on it. Price may change that! -- ============================================================================== "A mind is a terrible thing to MAIL: Dennis S. Breckenridge waste!" 206 Poyntz Ave North York, Ontario M2N1J6 (416) 733-1696 UUCP: uunet!attcan!nebulus!dennis ICBM: 79 28 05 W / 43 45 01 N 50 megatons should do! ==============================================================================
rjg@sialis.mn.org (Robert J. Granvin) (05/01/89)
>> Curious, my recollection is that you can do that with a TB+. (We don't >> lock either way on ours, so I'm not sure.) > >The TB+ locks the baud rate in and out. The only way to get a TB+ to work at >19200 is to lock the baud rate. What does your xferstats say about speed? >(assuming of course you are running HDB) Really? Hmmm... I've run Telebit Trailblazer+'s at 19.2K without locking the baud rate (assuming we're using the same terminology here...) >> Power problems? Obsolete firmware? We've had none on our pair. > >attcan and I constantly lock up as well as attnts. I know I have to go a reset >all of the damn modems when they do. It appears to be power (roms are 4.0) If it's power, it's not in the modem. Perhaps you could argue that the modem is too sensitive, but I have had one in an area that has (what I consider) poor power quality, and of the three that are in separate locations, none have required any human interventions. >> Sorry, you're too late, Canada has gone TB+ too, although apparently you >> hadn't noticed. Most of the major news-distribution sites in Toronto and >> elsewhere use TB+s to move the data. > >Dont count on it. >Price may change that! I'm not going to be one of the first to abandon my Trailblazer because some other modem may be cheaper. A full 90% of the sites I talk to have Trailblazers. Zero have the Microcoms in question. If a number of sites that I must talk to only install these modems, then I will consider obtaining one in addition to my Trailblazer. Until that time arrives, I'll not be buying one. I have no need to. I already own these other modems that have served me well and flawlessly. Does anyone really expect others to switch over because of price? It would be an endless cycle of money wasting if that were to happen... For your needs, purchase and install what you need and the flavor that serves you best. I did, and I can see no reasons to change anything at this point, or in the foreseeable future. -- ________Robert J. Granvin________ INTERNET: rjg@sialis.mn.org ____National Computer Systems____ CONFUSED: rjg%sialis.mn.org@shamash.cdc.com __National Information Services__ UUCP: ...uunet!rosevax!sialis!rjg
sl@unifax.UUCP (Stuart Lynne) (05/02/89)
In article <1989Apr28.192557.23991@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >In article <827@nebulus.UUCP> root@nebulus.UUCP (Dennis S. Breckenridge) writes: >>... I really don't know why the U.S. usenet sites selected TB+'s >>other than price. There is no standard modem yet for usenet here in Canada >>and I would like to see Microcom get a fair shake. > >Sorry, you're too late, Canada has gone TB+ too, although apparently you >hadn't noticed. Most of the major news-distribution sites in Toronto and >elsewhere use TB+s to move the data. Same here on the west coast. Both sites we receive news from have Trailblazers. We feed: 1200 2400 TB+ full news feed 1 6 8 mail exchange 2 2 small news feed 5 4 1 The largest block is TB+ for full feed. They account for most of the traffic and only a small amount of the total connect time. While I like to think that they got them to increase the amount of time available on my lines, I'm sure that what the really wanted was to not tie up their lines for hours every day pulling down news. At least two of the 2400 full feed sites are just waiting for approval of their TB purchase. -- Stuart.Lynne@wimsey.bc.ca uunet!van-bc!sl 604-937-7532(voice) 604-939-4768(fax)