cram@sunpix.East.Sun.COM (Marc W. Howard) (04/15/91)
I recently upgraded a machine to a CVG Super Modem 9600 (V.42). Doing this killed uucp between this system and another with a Telebit T2500. Previously the link worked okay at 2400 baud (no compression or error checking). Now when the two systems start up they do the initial handshake, agree on using 'g' protocol, and then proceed to alarm themselves to death. The two systems are both running the same version of HDB uucp. Also the link works fine for normal login (i.e., tip) applications. Does anyone out there have a magic cookie to use to initialize the CVG-9600 modem? Or is there a way to change the protocol between the two machines to avoid this behaviour? Less desirable would be changing the Telebit's setup since it communicates with several other machines. Thanx, Marc W. Howard Sun Microsystems Inc. Research Triangle Park, NC cram@sunpix.East.Sun.COM
david@kessner.denver.co.us (David Kessner) (04/16/91)
In article <704@sunpix.East.Sun.COM> cram@sunpix.East.Sun.COM (Marc W. Howard) writes: > I recently upgraded a machine to a CVG Super Modem 9600 (V.42). Doing >this killed uucp between this system and another with a Telebit T2500. >Previously the link worked okay at 2400 baud (no compression or error >checking). Now when the two systems start up they do the initial handshake, >agree on using 'g' protocol, and then proceed to alarm themselves to death. >The two systems are both running the same version of HDB uucp. Also the >link works fine for normal login (i.e., tip) applications. > cram@sunpix.East.Sun.COM Does it actually 'just hangup' when doing the UUCP transfer-- thus causing the alarms? Here is why I ask... I have an ATI 9600etc/c modem, and UUCP with a T2500. When I connect at 9600 with V.32 but no MNP or V.42bis it works flawlessly. When I use compression/correction it will connect fine, but will hang up (causing Alarms) after awhile (after 1-2 min). I've tried ALL possible combinations of baud-rates/settings/handshaking with no avail. The modem works fine when connecting to ALL other machines. ATI Tech support Babbles worse than the V.P. Danny-Q... So, I am wondering if your problem and mine are related. If they are, it sounds like a T2500 problem, but who knows? Oh. The T2500 I was talking to had "the most recent ROM's"... -- David Kessner - david@kessner.denver.co.us | do { 1135 Fairfax, Denver CO 80220 (303) 377-1801 (p.m.) | . . . If you cant flame MS-DOS, who can you flame? | } while( jones);
root@zswamp.uucp (Geoffrey Welsh) (04/16/91)
Marc W. Howard (cram@sunpix.East.Sun.COM ) wrote: >I recently upgraded a machine to a CVG Super Modem 9600 (V.42). You mean GVC, right? >Doing this killed uucp between this system and another with a >Telebit T2500. Previously the link worked okay at 2400 baud I played *briefly* with a GVC V.32/V.42 modem and had some problems with it. Having configured several modems from USRobotics and Telebit (among others), I found it difficult to believe that I had made a significant error in configuring this one, but I could not in the time provided trace down any significant form of bug. On the other hand, if you're used to 'configuring' 2400 bps modems, it's possible that you just haven't configured some of the many things which simply don't appear in discussions of 2400s but are critical at 9600+. GVC is pretty good about fixing mites if and when they find them. Sorry I couldn't be more specific; I don't have one of these modems nor one of the manuals handy. -- UUCP: watmath!xenitec!zswamp!root | 602-66 Mooregate Crescent Internet: root@zswamp.fidonet.org | Kitchener, Ontario FidoNet: SYSOP, 1:221/171 | N2M 5E6 CANADA Data: (519) 742-8939 | (519) 741-9553 The mile is traversed not by a single leap, but by a procession of coherent steps; those who insist on making the trip in a single element will be failing long after you and I have discovered new worlds. -- me
gandrews@netcom.COM (Greg Andrews) (04/16/91)
In article <704@sunpix.East.Sun.COM> cram@sunpix.East.Sun.COM (Marc W. Howard) writes: > > I recently upgraded a machine to a CVG Super Modem 9600 (V.42). Doing >this killed uucp between this system and another with a Telebit T2500. >Previously the link worked okay at 2400 baud (no compression or error >checking). Now when the two systems start up they do the initial handshake, >agree on using 'g' protocol, and then proceed to alarm themselves to death. >The two systems are both running the same version of HDB uucp. Also the >link works fine for normal login (i.e., tip) applications. > >Less desirable would be changing the Telebit's setup since it communicates >with several other machines. > Have you made sure that the CVG modem is not using XON/XOFF? How about the T2500? If the T2500 has no trouble to other sites with the same modulation (2400), then it's not likely to be a problem in the T2500's settings. However, if this is the only site that uses 2400 (all the others use PEP), and the CVG already does have XON/XOFF disabled, then it may require a change to the T2500's settings... -- .------------------------------------------------------------------------. | Greg Andrews | UUCP: {apple,amdahl,claris}!netcom!gandrews | | | Internet: gandrews@netcom.COM | `------------------------------------------------------------------------'
neal@mnopltd.UUCP (04/18/91)
-> I recently upgraded a machine to a CVG Super Modem 9600 (V.42). Doing
->this killed uucp between this system and another with a Telebit T2500.
->Previously the link worked okay at 2400 baud (no compression or error
->checking). Now when the two systems start up they do the initial handshake,
->agree on using 'g' protocol, and then proceed to alarm themselves to death.
->The two systems are both running the same version of HDB uucp. Also the
->link works fine for normal login (i.e., tip) applications.
->
-> Does anyone out there have a magic cookie to use to initialize the
->CVG-9600 modem? Or is there a way to change the protocol between the two
->machines to avoid this behaviour? Less desirable would be changing the
->Telebit's setup since it communicates with several other machines.
->
This is not my answer; it belongs to two other guys who lent it to me; I don't
fully understand the answer, but it did work when I had the exact same symptoms:
- Check to make sure all chunks of the link have xon/xoff flow control
disabled.
------------------------------------------------------------------------------
Neal Rhodes MNOP Ltd (404)- 972-5430
President Lilburn (atlanta) GA 30247 Fax: 978-4741
emory!mnopltd!neal
gatech!emory!mnopltd!neal
------------------------------------------------------------------------------sw@ (Steve Warner) (04/18/91)
In article <704@sunpix.East.Sun.COM> cram@sunpix.East.Sun.COM (Marc W. Howard) writes: > > I recently upgraded a machine to a CVG Super Modem 9600 (V.42). Doing >this killed uucp between this system and another with a Telebit T2500. >Previously the link worked okay at 2400 baud (no compression or error >checking). Now when the two systems start up they do the initial handshake, >agree on using 'g' protocol, and then proceed to alarm themselves to death. >The two systems are both running the same version of HDB uucp. Also the >link works fine for normal login (i.e., tip) applications. In most UUCP connections using error corrected modems that I have had to debug, the most common problem has been flow control. And the most common flow problem is(was) that one or more modems are eating XON/XOFF characters. Make sure you have XON/XOFF pass thru on, on both modems. Sometimes your sys admin will be reluctant to do this, but it will work. If the modems eat these characters, uucico will fail fail fail. -Steve -- ---- Steve Warner - Fremont, CA, USA etc... replies to: sun!indetech!stables!sw (forget what the header says)
bdavis@nic.cerf.net (Barry Davis) (04/20/91)
In article <1991Apr15.212635.16619@kessner.denver.co.us>, david@kessner.denver.co.us (David Kessner) writes: > In article <704@sunpix.East.Sun.COM> cram@sunpix.East.Sun.COM (Marc W. Howard) writes: > > I recently upgraded a machine to a CVG Super Modem 9600 (V.42). Doing > >this killed uucp between this system and another with a Telebit T2500. [deleted] > > cram@sunpix.East.Sun.COM > > Does it actually 'just hangup' when doing the UUCP transfer-- thus causing the > alarms? Here is why I ask... > > I have an ATI 9600etc/c modem, and UUCP with a T2500. When I connect at > 9600 with V.32 but no MNP or V.42bis it works flawlessly. When I use > compression/correction it will connect fine, but will hang up (causing Alarms) > after awhile (after 1-2 min). [deleted] > So, I am wondering if your problem and mine are related. If they are, it > sounds like a T2500 problem, but who knows? > -- > David Kessner - david@kessner.denver.co.us I was having similar problems with a leased-line SLIP link using Telebit T2500 modems with V.32/V.42/V.42bis/MNP4-5. It seemed that the two T2500 modems could not connect when I was using either V.42/V.42bis or MNP4-5 for error correction and/or data compression. Upon contacting Telebit, I was told that there is an apparent problem with using error correction or data compression over V.32. Since I had tried every possible combination of V.32 and V.42 V.42bis/MNP4-5, this seemed to be the only logical answer. I was told that a fix was to be included in the next firmware release (Rev. 7.1 ??). You might want to inquire with Telebit as to your specific problem if flow control or V.32 UUCP spoofing has been eliminated as a problem in your application. Good Luck! =============================================================================== Cerafin E. Castillo ______ ______ TCP/IP LAN/WAN Connectivity \ / INET: cec@emulex.com EMULEX Corporation ______ \/ ______ 2880 Zanker Rd., Suite 204 /\ UUCP: uunet!emulex!cec San Jose, CA 95131 ______/ \______ (408) 452-4777 E M U L E X "Beauty does what Beauty does best; it's Beautiful!" ================================================================================
gandrews@netcom.COM (Greg Andrews) (04/20/91)
In article <342@nic.cerf.net> bdavis@nic.cerf.net (Barry Davis) writes: > >I was having similar problems with a leased-line SLIP link using Telebit T2500 >modems with V.32/V.42/V.42bis/MNP4-5. It seemed that the two T2500 modems >could not connect when I was using either V.42/V.42bis or MNP4-5 for error >correction and/or data compression. Upon contacting Telebit, I was told that >there is an apparent problem with using error correction or data compression >over V.32. > Who did you talk with? I'm certainly not aware of ANY problems getting a V.32/MNP or V.32/LAP-M link going between two T2500 modems over leased or dialup lines. > > Since I had tried every possible combination of V.32 and V.42/V.42bis >/MNP4-5, this seemed to be the only logical answer. I was told that >a fix was to be included in the next firmware release (Rev. 7.1 ??). You >might want to inquire with Telebit as to your specific problem if flow >control or V.32 UUCP spoofing has been eliminated as a problem in your >application. Good Luck! > I don't understand - how could uucp spoofing be a factor between a T2500 and another brand of modem (ATI)?? Flow control could certainly cause trouble, but spoofing wouldn't have been enabled. It might cause trouble for SLIP if it were mistakenly enabled in your setup... To address Marc's problem, I've seen trouble with an ATI 9600 modem also in MNP and LAP-M modes. I had to transfer a file to a customer and they only had that modem available. After a screenful of data, everything became garbled. The customer claimed they can connect to lots of different modems in MNP or LAP-M mode without this trouble. I've made connections to lots of other modems with my T2500, including the local CompuServe V.32 and 2400 nodes every day of the week, without problems. A V.32 connection without error control worked fine to the ATI modem and the file was sent without any further trouble. There's definitely a problem with error control between the T2500 and the ATI modem. I suspect the ATI isn't doing something right, but I don't have any solid evidence one way or the other. I submitted a problem report asking that it be investigated by the engineers. -- .------------------------------------------------------------------------. | Greg Andrews | UUCP: {apple,amdahl,claris}!netcom!gandrews | | | Internet: gandrews@netcom.COM | `------------------------------------------------------------------------'
bdavis@nic.cerf.net (Barry Davis) (04/24/91)
In article <1991Apr20.104127.14981@netcom.COM>, gandrews@netcom.COM (Greg Andrews) writes: > In article <342@nic.cerf.net> bdavis@nic.cerf.net (Barry Davis) AKA > Cerafin E. Castillo, writes: > > > >I was having similar problems on a leased-line SLIP link using Telebit T2500 > >modems with V.32/V.42/V.42bis/MNP4-5. It seemed that the two T2500 modems > >could not connect when I was using either V.42/V.42bis or MNP4-5 for error > >correction and/or data compression. Upon contacting Telebit, I was told > >there is an apparent problem with using error correction or data compression > >over V.32. > > > > Who did you talk with? I'm certainly not aware of ANY problems getting > a V.32/MNP or V.32/LAP-M link going between two T2500 modems over leased > or dialup lines. > > > > > Since I had tried every possible combination of V.32 and V.42/V.42bis > >/MNP4-5, this seemed to be the only logical answer. I was told that > >a fix was to be included in the next firmware release (Rev. 7.1 ??). > I would like to clarify my report of problems using V.42/MNP over V.32 in Telebit T2500 modems. This is due to this posting and a direct reply I received from Telebit (modems@america.telebit.com). My leased-line SLIP link using Telebit T2500s (GE7.00) and Data Probe hybrids is in line with Telebit recommendations. My leased line is heavily conditioned and I was trying to squeeze a little more performance and stability from SLIP between my two Emulex P400B terminal servers. There were no line problems to be dealt with. Using V.32, I was not able to get V.42/MNP working at all. I was supported by Telebit in my testing, and I know the product settings pretty well by now, so there was little left to chance in so far as modem settings are concerned. I have gone to using Penril Alliance modems since they can do V.42/V.42bis over both V.32 and V.32bis. They are also 4-wire leased line capable. Although I believe, and I was told, that there is a problem with BOTH V.42 and MNP over V.32, this is the direct reply I received from Telebit: |Date: Mon, 22 Apr 91 17:22:33 PDT |From: Telebit Support acct <modems@america.telebit.COM> |Message-Id: <9104230022.AA01447> |To: cec@emulex.com |Subject: T2500 V.42 |Status: RO | | |Cerafin, | |I got your reply to David Kessner and when you said "I called Telebit and |they said it was an apparent problem with error correction or data comp." |How did you talk to? We KNOW there is a problem w/ MNP, but we're not aware |of a problem with V.42 or V.42bis. As a matter of fact, when people run into |the MNP problem, we SUGGEST that they use V.42 for their error correction/data |compression as it has no problems. Maybe you need to call Tech. Support so |we can properly configure your modem to work in V.42 mode. It's easy...set |the following: S97=1 S106=1 X3 at BOTH ends and the modems WILL connect in |V.42 mode. I'm doing this e-mail in V.42 mode calling into the Sun, so I |know for a fact that it works.....leased line prob's?...cockpit error? ||GE7.02 and GF7.02 will fix the MNP problems...it'll be out soon. I'll also |reply to David so we can properly straighten him out. | |Jim Tremolini.....Telebit Technical Support. This answered a lot of my questions as to V.42/MNP with V.32... As for your next comment: > > You might want to inquire with Telebit as to your specific problem if flow > >control or V.32 UUCP spoofing has been eliminated as a problem in your > >application. Good Luck! > > > > I don't understand - how could uucp spoofing be a factor between a T2500 > and another brand of modem (ATI)?? Flow control could certainly cause > trouble, but spoofing wouldn't have been enabled. It might cause trouble > for SLIP if it were mistakenly enabled in your setup... > > To address Marc's problem,... [deleted] > Greg Andrews Since Marc's application was UUCP related, I figured that V.32 UUCP spoofing might have played into the picture. Just trying to cover the basics... =============================================================================== Cerafin E. Castillo ______ ______ TCP/IP LAN/WAN Connectivity \ / INET: cec@emulex.com EMULEX Corporation ______ \/ ______ 2880 Zanker Rd., Suite 204 /\ UUCP: uunet!emulex!cec San Jose, CA 95131 ______/ \______ (408) 452-4777 E M U L E X "Beauty does what Beauty does best; it's Beautiful!" ================================================================================