witr@rwwa.COM (Robert W. Withrow) (02/08/91)
I am having major difficulties getting Intel SysvR4 UUCP to work using a V.32/V.42bis modem (to uunet). The problem is that uucico will quit (after a while) saying ``alarm n'' where n is 1 through 5. When this happens I see that my machine is sending a message to UUNET, but UUNET is not responding. My machine has NS16550A uarts, and I have tried both the built in ASY driver, and the FAS driver. Neither fixes the problem. I am trying determine whether SYSVR4 UUCP is broken, or if the problem is with UUNET. If someone knows any tricks about this, could he/she send me some mail? Thanks! -- --- Robert Withrow, R.W. Withrow Associates, Swampscott MA 01907 USA Tel: +1 617 598 4480, Fax: +1 617 598 4430, Uucp: witr@rwwa.COM
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (02/11/91)
In article <1991Feb7.224752.1932@rwwa.COM> witr@rwwa.COM (Robert W. Withrow) writes: | My machine has NS16550A uarts, and I have tried | both the built in ASY driver, and the FAS driver. Neither fixes the ^^^^^^^^^^^^^^ Does the new FAS have streams support? I had al older one which didn't, and I didn't even look at the new one yet. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
bernd@comp.vuw.ac.nz (Bernd Gill) (02/11/91)
In article <1991Feb7.224752.1932@rwwa.COM>, witr@rwwa.COM (Robert W. Withrow) writes: |> I am having major difficulties getting Intel SysvR4 UUCP to work |> using |> a V.32/V.42bis modem (to uunet). The problem is that uucico will |> quit |> (after a while) saying ``alarm n'' where n is 1 through 5. With high speed modems it is most important to have flow control set up properly. Any lost or corrupted packets cause alarms. Depending on what protocol you are using you need the following flow control: Protocol Used Modem Computer -------------------------------------------------------------------- g-protocol xon/xoff OFF xon/xoff OFF RTS/CTS ON RTS/CTS ON Error Correction OFF f-protocol xon/xoff OFF xon/xoff OFF RTS/CTS ON RTS/CTS ON Error Correction ON Modem Error Correction sometime interferes with the g-protocol (which uses software error correction) and should be OFF. -- Bernd Gill Dept. of Computer Science Victoria University of Wellington Email: bernd@comp.vuw.ac.nz Wellington, NEW ZEALAND Phone: +64 4 721-000 x8658
gemini@geminix.in-berlin.de (Uwe Doering) (02/12/91)
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) writes: >In article <1991Feb7.224752.1932@rwwa.COM> witr@rwwa.COM (Robert W. Withrow) writes: > >| My machine has NS16550A uarts, and I have tried >| both the built in ASY driver, and the FAS driver. Neither fixes the > ^^^^^^^^^^^^^^ > > Does the new FAS have streams support? I had al older one which >didn't, and I didn't even look at the new one yet. No. But some SysVr4 users reported that they could use FAS with the help of certain SysVr3 compatibility functions that are still in the kernel but are not guaranteed to be in future releases of SysVr4. On the other hand, I got reports from some people that FAS doesn't work under SysVr4 (kernel panics and the like). I don't know whether these contradicting statements are caused by differences between the SysVr4 versions (they were from different vendors), or by differences in kernel hacking experience. In the mean time I'm still waiting for my Dell SysVr4 copy. I'll start working on a port to STREAMS as soon as I get the tape. Uwe -- Uwe Doering | INET : gemini@geminix.in-berlin.de Berlin |---------------------------------------------------------------- Germany | UUCP : ...!unido!fub!geminix.in-berlin.de!gemini
jdeitch@jadpc.cts.com (Jim Deitch) (02/15/91)
In article <1991Feb10.201122.29918@comp.vuw.ac.nz> bernd@comp.vuw.ac.nz (Bernd Gill) writes: > >In article <1991Feb7.224752.1932@rwwa.COM>, witr@rwwa.COM (Robert W. >Withrow) writes: >|> I am having major difficulties getting Intel SysvR4 UUCP to work >|> using >|> a V.32/V.42bis modem (to uunet). The problem is that uucico will >|> quit >|> (after a while) saying ``alarm n'' where n is 1 through 5. > >With high speed modems it is most important to have flow control set up >properly. Any lost or corrupted packets cause alarms. Depending >on what protocol you are using you need the following flow control: > >Protocol Used Modem Computer >-------------------------------------------------------------------- >g-protocol xon/xoff OFF xon/xoff OFF > RTS/CTS ON RTS/CTS ON > Error Correction OFF > >f-protocol xon/xoff OFF xon/xoff OFF > RTS/CTS ON RTS/CTS ON > Error Correction ON > >Modem Error Correction sometime interferes with the g-protocol (which >uses software error correction) and should be OFF. HUH? That means: 1. I can't use a Telebit modem's uucp spoofing because the modem has to do pep for it to work, but that pep is an error correcting protocol done by the modem. Right? 2. That the uucp transfers that have been happening the last six months wern't really happening, and all those bits are on the floor behind my computer? 3. You made a mistake in the chart, and I am responding before the corrected one comes out. Which choice? Jim >-- >Bernd Gill Dept. of Computer Science > Victoria University of Wellington >Email: bernd@comp.vuw.ac.nz Wellington, NEW ZEALAND > Phone: +64 4 721-000 x8658 -- ARPANET: jadpc!jdeitch@nosc.mil INTERNET: jdeitch@jadpc.cts.com UUCP: nosc!jadpc!jdeitch
gandrews@netcom.COM (Greg Andrews) (02/17/91)
In article <1991Feb15.054602.913@jadpc.cts.com> jdeitch@jadpc.cts.com (Jim Deitch) writes: > >> [quoting Bernd Gill] >>With high speed modems it is most important to have flow control set up >>properly. Any lost or corrupted packets cause alarms. Depending >>on what protocol you are using you need the following flow control: >> >>Protocol Used Modem Computer >>-------------------------------------------------------------------- >>g-protocol xon/xoff OFF xon/xoff OFF >> RTS/CTS ON RTS/CTS ON >> Error Correction OFF >> >>Modem Error Correction sometime interferes with the g-protocol (which >>uses software error correction) and should be OFF. > >HUH? > > That means: >1. I can't use a Telebit modem's uucp spoofing because the modem > has to do pep for it to work, but that pep is an error correcting > protocol done by the modem. Right? > >2. That the uucp transfers that have been happening the last six > months wern't really happening, and all those bits are on the > floor behind my computer? > >3. You made a mistake in the chart, and I am responding before the > corrected one comes out. > >Which choice? > Um...er...door #3, but not because he's 'wrong' -- he's just overstating the case a little. Among all the modems on the market, there are very few that can separate the computer--->modem flow control path from the modem--->computer flow control path. For those modems, you have no choice but to use RTS/CTS (if your computer can support it), or disable all flow control. Telebit modems have the ability to define different types of flow control in the two directions. This allows the modem to ignore XON and XOFF bytes from the computer (they might appear in uucp transfers) while still sending XON/XOFF to the computer. The modem becomes transparent to data flow while still retaining the ability to pause the computer. Since the Telebit PEP mode has special support for uucp, it's able to do important things like disabling the XON/XOFF flow control to prevent alarms from the unexpected flow control characters. Definitely the exception to the rule (and note that this only happens when the modem is doing uucp spoofing -- plain connections would still have XON/XOFF active). Also, the assertion that modem error correction "interferes" with uucp is probably not right. There have been a lot of reports that error correction caused trouble with uucp, but just as many reports that it seems to work fine (my own experience). Most modems enable flow control and allow higher RS232 speeds when error correction is used. Could be the problems were caused by the modem's buffering and/or flow control rather than the error correction itself. -- .-------------------------------------------. | Greg Andrews | gandrews@netcom.COM | `-------------------------------------------'
witr@rwwa.COM (Robert W. Withrow) (02/18/91)
In article <24318@netcom.COM> gandrews@netcom.COM (Greg Andrews) writes: >Also, the assertion that modem error correction "interferes" with uucp >is probably not right. There have been a lot of reports that error >correction caused trouble with uucp, but just as many reports that it >seems to work fine (my own experience). Yes, and there is the rub. My interpretation is that each modem manufacturer has implemented V.42/V.42bis slightly differently (this was the gist of a Byte review of these modems) leading to incompatabilities. I know for a fact that I cannot do 9600 BPS UUCP using a Practical Periphials modem to a Telebit T2500 when using V.42(bis) LAP-M/compression. If I turn off the V.42/bis stuff the transfer works OK. The annoying thing is that you get into a p***ing match where both modem manufacturers swear that their modem is correct and the other guy is in the wrong. In my case there are 6 parties involved: 1)Me, 2)Intel (for the OS), 3)UUNET (for their computer), 4)Telebit, 5)Practical Periperals, and 6)the TELCO. And numbers 2 throug 6 have been precious little help in getting the problem solved! -- --- Robert Withrow, R.W. Withrow Associates, Swampscott MA 01907 USA Tel: +1 617 598 4480, Fax: +1 617 598 4430, Uucp: witr@rwwa.COM
gandrews@netcom.COM (Greg Andrews) (02/18/91)
In article <1991Feb17.195353.25156@rwwa.COM> witr@rwwa.COM (Robert W. Withrow) writes: > >Yes, and there is the rub. My interpretation is that each modem >manufacturer has implemented V.42/V.42bis slightly differently (this >was the gist of a Byte review of these modems) leading to >incompatabilities. I know for a fact that I cannot do 9600 BPS UUCP >using a Practical Periphials modem to a Telebit T2500 when using >V.42(bis) LAP-M/compression. If I turn off the V.42/bis stuff the >transfer works OK. > >The annoying thing is that you get into a p***ing match where both >modem manufacturers swear that their modem is correct and the other guy >is in the wrong. In my case there are 6 parties involved. > [list deleted] > >And [Telebit and PPI] have been precious little help in getting the >problem solved! > It's certainly possible for two sets of engineers to interpret the recommendation differently. It's also possible for one group of programmers (or both) to make mistakes in their code. I would expect a problem that really is an incompatibility between the modems would be easy to demonstrate to tech support. I can't think of any data sets that would work fine with Xmodem or Ymodem but would fail with uucp. Even so, Telebit tech support has a Unix system available for uucp testing. I would suggest that you call and try some test transfers. Kermit and X/Ymodem transfers can be done by any of the support techs. Uucp can be arranged in about ten minutes. -- .-------------------------------------------. | Greg Andrews | gandrews@netcom.COM | `-------------------------------------------'
shwake@raysnec.UUCP (Ray Shwake) (02/19/91)
witr@rwwa.COM (Robert W. Withrow) writes: >Yes, and there is the rub. My interpretation is that each modem >manufacturer has implemented V.42/V.42bis slightly differently (this >was the gist of a Byte review of these modems) leading to >incompatabilities. I know for a fact that I cannot do 9600 BPS UUCP >using a Practical Periphials modem to a Telebit T2500 when using >V.42(bis) LAP-M/compression. If I turn off the V.42/bis stuff the >transfer works OK. Ah, but are you using early T2500 or recent T2500? Telebit data sheets for the original T2500 did not indicate V.42bis support, but only MNP 2-5. Recent data sheets not only explicitly list V.42 and V.42bis support but additional goodies like callback. Thus, if your modem insists on running V.42bis/LAP-M when its counterpart insists it can't grok that protocol, you're doomed to failure. ----------- uunet!media!ka3ovk!raysnec!shwake shwake@rsxtech
rhealey@digibd.com (Rob Healey) (02/22/91)
In article <1991Feb17.195353.25156@rwwa.COM> witr@rwwa.COM (Robert W. Withrow) writes: >Yes, and there is the rub. My interpretation is that each modem >manufacturer has implemented V.42/V.42bis slightly differently (this >was the gist of a Byte review of these modems) leading to >incompatabilities. I know for a fact that I cannot do 9600 BPS UUCP >using a Practical Periphials modem to a Telebit T2500 when using >V.42(bis) LAP-M/compression. If I turn off the V.42/bis stuff the >transfer works OK. > Try puttsing with the direction that compression is allowed on the Telebit side. You CAN turn off compression and just use LAP-M, this worked betwixed my T2500 at home and the MultiTech at work. The T2500 can also be told to do compression in both, one or neither direction. What I did in the end was switch to MNP 5 and it all just worked. Why use LAP-M when MNP works just as well? The only way you'll get 4x compression out of V42.bis is if you transmit zeros... You'd be surprised how well zero's compress... B^). In my practical experience, MNP 5 does just as well as LAP-M/compression. -Rob