bernd@pfm.rmt.sub.org (Bernd Hennig) (01/18/91)
rjp@japan.Berkeley.EDU (Ronald Plummer) writes: >Anyone out there with any experience with either the DELL or MICROPORT >versions of SVR4 ? I'm interested on experience about MICROPORT SYS V Rel. 4 (Formular 1) too. Pse mail to bernd@pfm.rmt.sub.org -- Bernd Hennig | Eibenweg 4| 6500 Mainz | 06131/362779 | bernd@pfm.rmt.sub.org Man sollte seinen Feinden verzeihen - aber nicht, bevor sie am Galgen haengen Heinrich Heine 1797 - 1856
mandel@ux1.cso.uiuc.edu (Hector Mandel) (05/08/91)
I have been trying to set up a modem on my system with limited success. I am running UHC SVR4 on an i386 machine. Setting up the port monitor or the old uugetty stuff in /etc/inittab works fine for incoming connections to the modem on my serial port. I can dial in and connect, login etc. with no problem. HOWEVER, if I set up basic networking and try to call *out* using cu, it doesn't work. I've tried disabling the port monitor and setting up the port for outbound dialing only by configuring Dialers, Systems and Devices files, but it still won't work. cu returns a message saying "CAN'T ACCESS DEVICE". When I called UHC tech support, I was told that this is a bug in the ATT source code that they have been trying to fix since January. My main objective in posting this is to find out if this is indeed the case or if anyone out there has managed to get this to work with either Dell's or UHC's SVR4. Any responses or suggestions will be welcome. I realize that it is entirely possible that I'm just totally confused since I am a novice in the UNIX world, so if this is the case I would appreciate it if someone could give me some instructions. (I have done all this modem stuff with my ATT SVR3.2.2 system, so I have a rudimentary idea of what's going on at least. Thanks in advance for your help. Hector Mandel mandel@romulus.ehs.uiuc.edu uiucuxc!romulus.ehs.uiuc.edu!mandel "A skydiver is taken by the gravity of his situation." -- mandel@ux1.cso.uiuc.edu
urban@cbnewsl.att.com (john.urban) (05/09/91)
In article <1991May8.153108.21313@ux1.cso.uiuc.edu> mandel@ux1.cso.uiuc.edu (Hector Mandel) writes: >I have been trying to set up a modem on my system with limited success. I >am running UHC SVR4 on an i386 machine. Setting up the port monitor or >the old uugetty stuff in /etc/inittab works fine for incoming connections >to the modem on my serial port. I can dial in and connect, login etc. with >no problem. HOWEVER, if I set up basic networking and try to call *out* >using cu, it doesn't work. I've tried disabling the port monitor and >setting up the port for outbound dialing only by configuring Dialers, >Systems and Devices files, but it still won't work. cu returns a message >saying "CAN'T ACCESS DEVICE". Do you get this message with ttymon running on this port -OR- with uugetty running on this port ? Did this exact hardware configuration work on AT&T SVR3.2.2 ? Sincerely, John Ben Urban > >When I called UHC tech support, I was told that this is a bug in the ATT >source code that they have been trying to fix since January. My main >objective in posting this is to find out if this is indeed the case or if >anyone out there has managed to get this to work with either Dell's or >UHC's SVR4. >
mandel@ux1.cso.uiuc.edu (Hector Mandel) (05/09/91)
urban@cbnewsl.att.com (john.urban) writes: >>using cu, it doesn't work. I've tried disabling the port monitor and >>setting up the port for outbound dialing only by configuring Dialers, >>Systems and Devices files, but it still won't work. cu returns a message >>saying "CAN'T ACCESS DEVICE". >Do you get this message with ttymon running on this port -OR- with uugetty >running on this port ? Both. >Did this exact hardware configuration work on AT&T SVR3.2.2 ? I have not tried SVR3.2.2 on the same EXACT hardware, so I guess the answer is no. And I'm not about to try it right now either since I would have to install SVR3.2.2 and reinstall all 70 + diskettes of SVR4 afterwards!! GAAWWDD! :) :) :) At this point, I really want to find out whether it *should* work. Then I can start messing with the hardware. The UHC tech support people said that the problem is in the OS and not in my hardware ... I need to verify whether this is true or not. So if someone out there has succeeded in getting outbound (cu) to work with either Dell's or UHC's i386 SVR4, I would *really* like to hear from them! -- mandel@ux1.cso.uiuc.edu
tim@dell.co.uk (Tim Wright) (05/09/91)
In <1991May8.153108.21313@ux1.cso.uiuc.edu> mandel@ux1.cso.uiuc.edu (Hector Mandel) writes: >I have been trying to set up a modem on my system with limited success. I >am running UHC SVR4 on an i386 machine. Setting up the port monitor or >the old uugetty stuff in /etc/inittab works fine for incoming connections >to the modem on my serial port. I can dial in and connect, login etc. with >no problem. HOWEVER, if I set up basic networking and try to call *out* >using cu, it doesn't work. I've tried disabling the port monitor and >setting up the port for outbound dialing only by configuring Dialers, >Systems and Devices files, but it still won't work. cu returns a message >saying "CAN'T ACCESS DEVICE". The problem is the (pardon me) CRAP serial port driver supplied with V.4. It does not support "non modem-controlled" serial ports i.e. is DCD is not high, you cannot open the port. Actually, that is not really true. You have to open the port with O_NDELAY set, then set the CLOCAL flag and you can then use the port (tricky since many comms programs don't know how to do this). Or you can strap the modem DCD high all the time. However that means resorting to (Ugh) uugetty. There is an easier way. Get FAS2.08, change the include line for 'sys/macros.h' to sys/systm.h (I think), and install it. I'm working on a streams tty version, but don't hold your breath - the current version works OK due to the backwards compatability functions in the V.4 kernel. Tim -- Tim Wright, Dell Computer Corp., Bracknell | Domain: tim@dell.co.uk Berkshire, UK, RG12 1RW. Tel: +44-344-860456 | Uucp: ...!ukc!delluk!tim Smoke me a Kipper, I'll be back for breakfast - Red Dwarf
dewey@dell.dell.com (Dewey Coffman) (05/09/91)
In article <1991May8.194639.28749@ux1.cso.uiuc.edu> mandel@ux1.cso.uiuc.edu (Hector Mandel) writes: >urban@cbnewsl.att.com (john.urban) writes: > >>>using cu, it doesn't work. I've tried disabling the port monitor and >>>setting up the port for outbound dialing only by configuring Dialers, >>>Systems and Devices files, but it still won't work. cu returns a message >>>saying "CAN'T ACCESS DEVICE". > > >Both. > >>Did this exact hardware configuration work on AT&T SVR3.2.2 ? > >I have not tried SVR3.2.2 on the same EXACT hardware, so I guess the answer >is no. And I'm not about to try it right now either since I would have to >install SVR3.2.2 and reinstall all 70 + diskettes of SVR4 afterwards!! >GAAWWDD! :) :) :) > >At this point, I really want to find out whether it *should* work. Then I >can start messing with the hardware. The UHC tech support people said that >the problem is in the OS and not in my hardware ... I need to verify whether >this is true or not. So if someone out there has succeeded in getting >outbound (cu) to work with either Dell's or UHC's i386 SVR4, I would *really* >like to hear from them! > This works fine on Dell UNIX V.4. I've seen this message when 'uugetty' has already open'ed the port. I'd try turning off portmon or uugetty and if you still get the "CAN'T ACCESS DEVICE" error, then I'd say you have found a real bug. It sounds like the UHC people were correct, are you running a "Developer's release" or V.4 Version 2.0. I'm seem to remember there were quite a few changes between Version 1.0 and 2.0 that related to UUCP/CU/Async stuff. dewey -- Dewey Coffman UUCP: dell!sooner!dewey, cs.utexas.edu!dell!sooner!dewey
tony@mcrsys.UUCP (Tony Becker) (05/11/91)
From article <1991May8.194639.28749@ux1.cso.uiuc.edu>, by mandel@ux1.cso.uiuc.edu (Hector Mandel): > urban@cbnewsl.att.com (john.urban) writes: > >>>saying "CAN'T ACCESS DEVICE". > >>Did this exact hardware configuration work on AT&T SVR3.2.2 ? probably. > > mandel@ux1.cso.uiuc.edu Ok. Here's my two cents. 1) ATT requires DSR present to 'open' the port. Force it high. This is true for SVR4 as well as the 3B2. Its a feature. 2) Now you have DTR & RTS out, CTS & CD in (and TD/RD). a) for a modem connection (Dial in), the getty will respond if, and only if CD is high; so your modem MUST be set to auto answer. You can't force CD high, or the device driver can't tell getty that there is an incoming call. b) for a modem connecting (Dial out), the device driver will allow you to write to the modem when DTR goes high (it will on open), but you can't read from the modem until CD goes high, which it won't until AFTER you dial, which you can't because you can't read from the modem.... (catch 22). So for dial out, you must force CD in. This makes ports mutually exclusive to Dial In/Out. This is true on the 3B2. (It's STILL a feature). 3) What I Do... Configure the Modem/Port for a dial out case and use ringback, or some other inteligent program that looks for the modem to RING. When this happens, you can spawn a getty to the incoming call. Out going calls just require the ringback daemon to stay out of the way. This configuration also has the added advantage of locking the Port - Modem speed (to 9600bps) allowing a greater getty pick up for various incoming modem rates. The address out of rb.c is: Paul Traina (pst@anise.acc.com) Jon Zeeff (umix!b-tech!zeeff) Either are free to contact me for any other details, as I have modified their source for a Courier HST. -- tony ,....
urban@cbnewsl.att.com (john.urban) (05/13/91)
In article <1991May8.194639.28749@ux1.cso.uiuc.edu> mandel@ux1.cso.uiuc.edu (Hector Mandel) writes: >urban@cbnewsl.att.com (john.urban) writes: > >>>using cu, it doesn't work. I've tried disabling the port monitor and >>>setting up the port for outbound dialing only by configuring Dialers, >>>Systems and Devices files, but it still won't work. cu returns a message >>>saying "CAN'T ACCESS DEVICE". > >>Do you get this message with ttymon running on this port -OR- with uugetty >>running on this port ? > >Both. I forgot to ask this question before. The modem that you're using, does it have DTR strapped high or is it unstrapped? If its strapped high, then I don't know what the problem is. However, if it's unstrapped, you might not have the ,M in the Devices file for your "cu" port. ie: ACU tty01,M - 1200 hayes1200 The ,M "tells" cu, ct or uucico not to worry about DTR during the \M to \m Dialers string in the Dialers file. I the the BNU Guide talks about this. I don't have the guides in front of me. Sincerely, John Ben Urban att!garage!jbu
gandrews@netcom.COM (Greg Andrews) (05/14/91)
In article <1991May13.125733.8838@cbnewsl.att.com> urban@cbnewsl.att.com (john.urban) writes: > >I forgot to ask this question before. The modem that you're using, does it >have DTR strapped high or is it unstrapped? If its strapped high, then I >don't know what the problem is. However, if it's unstrapped, you might >not have the ,M in the Devices file for your "cu" port. > >ie: ACU tty01,M - 1200 hayes1200 > >The ,M "tells" cu, ct or uucico not to worry about DTR during the \M to \m >Dialers string in the Dialers file. I the the BNU Guide talks about this. >I don't have the guides in front of me. > Sorry to nitpick, but you're talking about DCD, not DTR. (very important distinction to the guy who's trying to fix a problem) >John Ben Urban >att!garage!jbu -- .------------------------------------------------------------------------. | Greg Andrews | UUCP: {apple,amdahl,claris}!netcom!gandrews | | | Internet: gandrews@netcom.COM | `------------------------------------------------------------------------'
gemini@geminix.in-berlin.de (Uwe Doering) (05/14/91)
urban@cbnewsl.att.com (john.urban) writes: >I forgot to ask this question before. The modem that you're using, does it >have DTR strapped high or is it unstrapped? If its strapped high, then I >don't know what the problem is. However, if it's unstrapped, you might >not have the ,M in the Devices file for your "cu" port. > >ie: ACU tty01,M - 1200 hayes1200 > >The ,M "tells" cu, ct or uucico not to worry about DTR during the \M to \m >Dialers string in the Dialers file. I the the BNU Guide talks about this. >I don't have the guides in front of me. This isn't quite right. I assume you meant DCD instead of DTR. DTR is an output while DCD is the carrier detect input that blocks the open() call if it is low. Uwe -- Uwe Doering | INET : gemini@geminix.in-berlin.de Berlin |---------------------------------------------------------------- Germany | UUCP : ...!unido!fub!geminix.in-berlin.de!gemini
urban@cbnewsl.att.com (john.urban) (05/14/91)
In article <G1WQAAK@geminix.in-berlin.de> gemini@geminix.in-berlin.de (Uwe Doering) writes: >urban@cbnewsl.att.com (john.urban) writes: > >>I forgot to ask this question before. The modem that you're using, does it >>have DTR strapped high or is it unstrapped? If its strapped high, then I >>don't know what the problem is. However, if it's unstrapped, you might >>not have the ,M in the Devices file for your "cu" port. >> >>ie: ACU tty01,M - 1200 hayes1200 >> >>The ,M "tells" cu, ct or uucico not to worry about DTR during the \M to \m >>Dialers string in the Dialers file. I think the BNU Guide talks about this. >>I don't have the guides in front of me. > >This isn't quite right. I assume you meant DCD instead of DTR. DTR is >an output while DCD is the carrier detect input that blocks the open() >call if it is low. > That's true I did mean DCD and not DTR. I was working from home yesterday and did not have all my crib sheets in front of me. However, the ,M is probably the fix that is needed. We add the ,M to the Device entries when we use a Hayes Modem. Sincerely, John Ben Urban
soward@inslab.uky.edu (John Soward) (07/01/91)
Can anyone enlighten me to what sort of bug fixes, enhancments,
changes, etc that may have occurred in the different sub-releases, I
appear to have AT&T SVR4/386 4.0.1 which is about 1 year old now...
(source code release) and it has a handfull of bugs, most of them slight,
but a few in the networking department are becoming more and more
annoying.....
thanx for any info,
--
________________________________________________________________________
/ "no, they're totally different. Their song goes 'bomp-bomp-bomp' /
/ but mine goes 'bomp-bomp-Bomp'...totally differnt" -V. Ice. /
/ john@ukpr.uky.edu | soward@s.ms.uky.edu | sysjohn@ukcc.uky.edu /
/_______________________________________________________________________/