campbell@redsox.UUCP (Larry Campbell) (10/23/88)
OK, I give up. I _cannot_ get uugetty to work. Either I'm doing something very obscurely wrong, or HDB uucp is totally braindead. I'm running ISC 386/ix, which is SVR3, with HDB uucp. I have two flavors of COM2 defined: /dev/tty01, which has no modem control, and /dev/ttyM01, which has modem control. If I run uugetty on /dev/tty01, then shortly after Ring Indicate blinks on, uugetty drops DTR. Since the modem has just answered the phone at this point, this means uugetty conveniently hangs up as soon as it answers. If I run uugetty on /dev/ttyM01, uugetty answers the phone OK, but uugetty and uucico trample each other, because uucico creates a lock file called LCK..tty01 while uugetty looks for LCK..ttyM01. So uucico comes along and prods the modem awake, then the modem and uugetty scream at each other for a while, making the whole system very unhappy. If I tell uucp to use /dev/ttyM01, then uucico dutifully waits for carrier to come up... forever, because the open won't complete until carrier comes up... at which point the poor guy trying to dial in gets really confused when uucico starts dialing at him. Am I screwed? Or is it possible to dial in and out on the same line? -- Larry Campbell The Boston Software Works, Inc. campbell@bsw.com 120 Fulton Street wjh12!redsox!campbell Boston, MA 02146
snoopy@sopwith.UUCP (Snoopy T. Beagle) (10/27/88)
In article <489@redsox.UUCP> campbell@sushi.UUCP (Larry Campbell) writes: |OK, I give up. I _cannot_ get uugetty to work. Either I'm doing something |very obscurely wrong, or HDB uucp is totally braindead. |I'm running ISC 386/ix, which is SVR3, with HDB uucp. I have two flavors of |COM2 defined: /dev/tty01, which has no modem control, and /dev/ttyM01, |which has modem control. |If I run uugetty on /dev/ttyM01, uugetty answers the phone OK, but uugetty |and uucico trample each other, because uucico creates a lock file called |LCK..tty01 while uugetty looks for LCK..ttyM01. So uucico comes along and |prods the modem awake, then the modem and uugetty scream at each other for a |while, making the whole system very unhappy. Sounds like the problem is in your kernel, rather than HDB. Under the scheme you are using, the device driver needs to prevent both tty01 and ttyM01 from being opened at the same time. Sounds like it isn't doing that. You might look through the documentation for the tty driver (tty(4)?) and make sure you have the major/minor device numbers set up right and all that. (sounds like you do, since your two /dev entries are accessing the same port in two different ways, but it wouldn't hurt to look.) I like my scheme better. Instead of having two /dev entries for each device, you supply a flag to the open call that says "I want to open this port so I can talk to the modem, so open it if CD is *not* there." (If CD is present, there is a call in progress, so *don't* open the device.) This supplies the same functionality, without having to have a second device entry cluttering up /dev ( causing slower directory searches, and making directory listings even bigger, and quite likely confusing humans), and with less work for the device driver to do (it doesn't have to insure that both devices aren't opened at once, since there is only one device. This allows less code in the kernel, and less potential for bugs. (like the one it appears you have)) The cost in my scheme is that it uses up a bit in the open flag, and you have to modify uucico and tip/cu to set this flag when opening the device. _____ /_____\ Snoopy /_______\ |___| tektronix!tekecs!sopwith!snoopy |___| sun!nosun!illian!sopwith!snoopy
mmengel@cuuxb.ATT.COM (Marc W. Mengel) (10/28/88)
In article <489@redsox.UUCP> campbell@sushi.UUCP (Larry Campbell) writes:
$OK, I give up. I _cannot_ get uugetty to work. Either I'm doing something
$very obscurely wrong, or HDB uucp is totally braindead.
$...
$If I tell uucp to use /dev/ttyM01, then uucico dutifully waits for carrier
$to come up... forever, because the open won't complete until carrier comes
$up... at which point the poor guy trying to dial in gets really confused
$when uucico starts dialing at him.
$
$Am I screwed? Or is it possible to dial in and out on the same line?
Use \M and \m in your Dialers file (to disable/enable carrier detect)
and "ttyM01,M" in your Devices file... (Why is it I seem to post this
about once a week? Probably because the 3.0 docs didn't bother to
mention it...)
$Larry Campbell The Boston Software Works, Inc.rick@pcrat.UUCP (Rick Richardson) (10/29/88)
In article <35@sopwith.UUCP> snoopy@sopwith.UUCP (Snoopy T. Beagle) writes: >|I'm running ISC 386/ix, which is SVR3, with HDB uucp. I have two flavors of >|COM2 defined: /dev/tty01, which has no modem control, and /dev/ttyM01, >|which has modem control. > >|If I run uugetty on /dev/ttyM01, uugetty answers the phone OK, but uugetty >|and uucico trample each other, because uucico creates a lock file called >|LCK..tty01 while uugetty looks for LCK..ttyM01. So uucico comes along and This may not solve your problem, but it worked for me when I had trouble trying to use the modem device and the direct device at the same time (I've since hacked in the dialin/out support into my device driver). My devices were named: com1 com1m And I had the same trouble as you do with the lock files. So I took advantage of a System V 'feature' - 14 character file names. I renamed the devices: xxxxxcom1 xxxxxcom1m Then, when the lock files get created by prepending 'LCK..' to the device name, both lock files end up with the same name. The best solution, though, is to apply steady pressure to the UNIX vendor to incorporate the dialin/out hacks into the device driver. -- Rick Richardson | JetRoff "di"-troff to LaserJet Postprocessor|uunet!pcrat!dry2 PC Research,Inc.| Mail: uunet!pcrat!jetroff; For anon uucp do:|for Dhrystone 2 uunet!pcrat!rick| uucp jetroff!~jetuucp/file_list ~nuucp/. |submission forms. jetroff Wk2200-0300,Sa,Su ACU {2400,PEP19200} 12013898963 "" \r ogin: jetuucp
steve@obed.uucp (stephen Samuel) (11/03/88)
In article <35@sopwith.UUCP>, snoopy@sopwith.UUCP (Snoopy T. Beagle) writes: > In article <489@redsox.UUCP> campbell@sushi.UUCP (Larry Campbell) writes: > |OK, I give up. I _cannot_ get uugetty to work. Either I'm doing something > |very obscurely wrong, or HDB uucp is totally braindead. > > |I'm running ISC 386/ix, which is SVR3, with HDB uucp. I have two flavors of > |COM2 defined: /dev/tty01, which has no modem control, and /dev/ttyM01, > |which has modem control. I think that you have a brain-damaged SVR3 box. You should have two flags that you can use: O_NDELAY which says to open a file without waiting for silly little things like CD active on a modem line and: CLOCAL (in the termio.h stuff) which says to ignore modem control. This makes it very easy to open a MODEM line and dial out while ignoring modem control. I have a short program that allows uses this trick to let you do 'stty's on a modem line whether or not it has a carrier. This is REAL useful sometimes when you're trying to figure out what uugetty/uucico is doing wrong. -- Stephen samuel !alberta!{obed,edm}!steve Look on the bright side... It might have worked!