Re: Fixed! (Re: mgetty isn't answering the phone (ioctl problem))
In [EMAIL PROTECTED] Rick Macdonald [EMAIL PROTECTED] writes: Joe Emenaker wrote: Why, after years and years of needing them, are the /dev/cua's suddenly, seemingly, obsolete? Rather than just saying RTFM, I've gathered it up for you. [snip] Maybe Debian should take the bold step of not creating /dev/cua* and making sure all Debian packages work correctly with /dev/ttyS*. This would mean making mgetty the only serial line getty, but much as I used to like uugetty, the fact that it has had no active maintainer for the last two years and that someone seems to decide to change how the linux console works every 6 months, makes uugetty's uugetty and normal console getty both pretty useless no anyway. -- John Henders - System Administrator - Mindlink!/Wimsey -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: Fixed! (Re: mgetty isn't answering the phone (ioctl problem))
On 26 Oct 1996, John Henders wrote: Maybe Debian should take the bold step of not creating /dev/cua* and making sure all Debian packages work correctly with /dev/ttyS*. This would mean making mgetty the only serial line getty, but much as I used to like uugetty, the fact that it has had no active maintainer for the last two years and that someone seems to decide to change how the linux console works every 6 months, makes uugetty's uugetty and normal console getty both pretty useless no anyway. Hello John, Does mgetty support the ring-back feature that uugetty has? That one is quite important to me as I have an answering machine and a modem on the same line. Nick -- Nick Busigin[EMAIL PROTECTED] To obtain my pgp public key, email me with the subject: get pgp-key -- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: Fixed! (Re: mgetty isn't answering the phone (ioctl problem))
Nick Busigin writes: On 26 Oct 1996, John Henders wrote: Maybe Debian should take the bold step of not creating /dev/cua* and making sure all Debian packages work correctly with /dev/ttyS*. This would mean making mgetty the only serial line getty, but much as I used to like uugetty, the fact that it has had no active maintainer for the last two years and that someone seems to decide to change how the linux console works every 6 months, makes uugetty's uugetty and normal console getty both pretty useless no anyway. Does mgetty support the ring-back feature that uugetty has? That one is quite important to me as I have an answering machine and a modem on the same line. The .99 beta I'm using does. It also supports PAP authentication for ppp and other cool features. -- John Henders - System Administrator - Mindlink!/Wimsey -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: Fixed! (Re: mgetty isn't answering the phone (ioctl problem))
Pete Harlan ([EMAIL PROTECTED]) wrote:
: In my experience, I've had to turn MGETTY OFF when I wanted to make an
: outbound PPP call. Dunno exactly why. I can dial out when I have MGETTY
: running, if I dial out with something like Minicom.
:
: This is because they're not putting their lockfiles in the same
: directory. Look at the compilation options for both of them and make
: sure that they're each using, e.g., /var/lock/LCK..ttyS0 for the
: lockfile, and that they write their pid in the file in ASCII format
: (not binary). (This is from the Linux FSSTND.)
:
: Kermit, Minicom, pppd, any modem software you write, mgetty, etc.,
: must agree on all of the above, and then it works like a dream.
The debian packages agree on those locations and should work without a problem.
If a package
uses a different location then its a bug which should be reported.
I am using the exact configuration mentioned above. Running mgetty on my modem
and pppd does outbound
connections like the one I am working from now.
--
{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}
{}FISH Internet System Administrator at Fuller Theological Seminary {}
{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}
PGP Public Key = FB 9B 31 21 04 1E 3A 33 C7 62 2F C0 CD 81 CA B5
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: Fixed! (Re: mgetty isn't answering the phone (ioctl problem))
On Wed, 23 Oct 1996, Daniel Stringfield wrote: Kermit, Minicom, pppd, any modem software you write, mgetty, etc., must agree on all of the above, and then it works like a dream. I use DCON.. its DCON that can't OPEN the port... pppd works fine, and mgetty work fine.. but its DCON that can't share the port... in that case, it's DCON that's broken. try reconfiguring or recompiling it so that it uses lock files in /var/lock. Craig -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: Fixed! (Re: mgetty isn't answering the phone (ioctl problem))
In my experience, I've had to turn MGETTY OFF when I wanted to make an outbound PPP call. Dunno exactly why. I can dial out when I have MGETTY running, if I dial out with something like Minicom. This is because they're not putting their lockfiles in the same directory. Look at the compilation options for both of them and make sure that they're each using, e.g., /var/lock/LCK..ttyS0 for the lockfile, and that they write their pid in the file in ASCII format (not binary). (This is from the Linux FSSTND.) Kermit, Minicom, pppd, any modem software you write, mgetty, etc., must agree on all of the above, and then it works like a dream. The serial HOWTO and the mgetty docs cover this and a lot more, btw. -- Pete Harlan [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: Fixed! (Re: mgetty isn't answering the phone (ioctl problem))
On Wed, 23 Oct 1996, Daniel Stringfield wrote: However, this has *not* fixed the bizzare problem with pppd thinking I don't have PPP support compiled in, even though I do. In my experience, I've had to turn MGETTY OFF when I wanted to make an outbound PPP call. Dunno exactly why. I can dial out when I have MGETTY running, if I dial out with something like Minicom. try using the 'lock' option in either /etc/ppp/options or on the pppd command line. Craig -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: Fixed! (Re: mgetty isn't answering the phone (ioctl problem))
On Wed, 23 Oct 1996, Philip Hands wrote: In my experience, I've had to turn MGETTY OFF when I wanted to make an outbound PPP call. Dunno exactly why. I can dial out when I have MGETTY running, if I dial out with something like Minicom. Sounds like your pppd is not getting its locks right. Possible causes: 1) it has not been told to use locks (``lock'' on the command line or in the options file sorts this out) That's done... 2) You may be mixing /dev/ttyS? with /dev/cua? devices --- mgetty doesn't like cua's and you should not use them at all on a port that mgetty is using. Everything uses ttyS3. 3) pppd has been compiled to put the locks in the wrong place. If you run: strings /usr/sbin/pppd | grep LCK you should get ``/var/lock/LCK..'' --- If not you need a different pppd. That's ok too.. A clasic symptom of this sort of locking failure is that you will see mgetty's attempts to reset the modem in the logs of the outgoing chat --- Mgetty doesn't know you're still using its line, so it goes ahead and resets it almost as soon as you start dialing. Mgetty reports no problems. Actually, MGETTY isn't the one having the problems, its the program I use to log into my ISP. I use DCON scripting, not 'chat'... It adds some cool features... It can't open the port when I have mgetty running on that same port. -- Daniel Stringfield mailto:[EMAIL PROTECTED] http://www.jax-inter.net/user/servo Send email for more information on the Jacksonville Linux Users Group! -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: Fixed! (Re: mgetty isn't answering the phone (ioctl problem))
On Tue, 22 Oct 1996, Joe Emenaker wrote: So, as near as I can tell, the modem was answering the modem on its own volition just moments before mgetty sent an ATA which, I believe, toggles the online state (hangs up if off-hook, picks up if on-hook). Hence, the two clicks, I guess. So, putting ATS0=0 in the init line for that tty fixed the problem. yep. agetty wants 'ATS0=1Q1E0' so that the modem answers the phone itself when it rings. S0=1 == answer after one ring, Q1 == quiet, E0 == echo off. mgetty wants 'ATS0=0E1Q0' so that the modem answers the phone only when told to (ATA) by mgetty. BTW, ATA doesn't toggle online state. ATA = Answer. It tells the modem to go off-hook and attempt to establish carrier. The reason why the ATA is causing the modem to hang up at that point is that most (all?) modems will hang up if they receive any characters from the serial port while they are trying to connect. You've probably seen that hitting enter or space in a terminal program while the modem is dialing will result in NO CARRIER. However, this has *not* fixed the bizzare problem with pppd thinking I don't have PPP support compiled in, even though I do. is ppp compiled into the kernel or as a module? try compiling it as a module, and make sure that either a) ppp is listed in /etc/modules or b) auto is listed in /etc/modules. Do you see something like: PPP: version 2.2.0 (dynamic channel allocation) PPP Dynamic channel allocation code copyright 1995 Caldera, Inc. PPP line discipline registered. show up at boot time? try running dmesg to display the most recent kernel messages...also, if the ppp message has scrolled out of the buffer, you can search for this text in /var/log/messages. If you DON'T see this message then you have either not compiled in ppp support or you have compiled it as a module but have failed to load the module. Also, the person who suggested that I use mgetty seemed to think I was kiiky for wanting to use uugetty. Well, if he's listening, I'd like to add that, under mgetty, I *still* can't dial out on the modem that mgetty is sitting on. The whole reason I wanted to use uugetty was that it supposedly allowed for dial-in and dial-out without having to do the inittab shuffle. mgetty works perfectly for dialin and dialout use. I have all 3 of my modems set up that way, even the one which is only ever used as my ppp link to the net (which is set to redial as soon as connection is lost) - i have it like that so that I have an emergency dial-in line if ppp connection is failing. getting it to work is really VERY simple and straightforward. here's what you need to know: - use the ttyS? devices for everything - dialin and dialout. - completely ignore anything you may have read about cua? and ttyS? devices. Linux no longer needs to do port locking with this barbaric method :-). Information you may have read saying that you have to use cua? devices for dialout use is obsolete and counter-productive. in fact, IMO /dev/cua? devices are obsolete. I can't think of any reason (except for supporting legacy software) why anyone would want to use them in preference to ttyS? devices. - put the word lock in /etc/ppp/options. This will force it to use lockfiles (in /var/lock/) - configure any other software which needs to use the modem so that it uses lockfiles in /var/lock. (e.g. uucico, cu, minicom - you'll find that the debian versions should already be configured to do this and is probably the default). - use mgetty. it knows about /var/lock already. no problems. It's a great program to start with and Chris L (the debian maintainer) has done a good job packaging it for debian. enjoy. Craig -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: Fixed! (Re: mgetty isn't answering the phone (ioctl problem))
On Wed, 23 Oct 1996, Pete Harlan wrote: In my experience, I've had to turn MGETTY OFF when I wanted to make an outbound PPP call. Dunno exactly why. I can dial out when I have MGETTY running, if I dial out with something like Minicom. This is because they're not putting their lockfiles in the same directory. Look at the compilation options for both of them and make sure that they're each using, e.g., /var/lock/LCK..ttyS0 for the lockfile, and that they write their pid in the file in ASCII format (not binary). (This is from the Linux FSSTND.) Kermit, Minicom, pppd, any modem software you write, mgetty, etc., must agree on all of the above, and then it works like a dream. I use DCON.. its DCON that can't OPEN the port... pppd works fine, and mgetty work fine.. but its DCON that can't share the port... -- Daniel Stringfield mailto:[EMAIL PROTECTED] http://www.jax-inter.net/user/servo Send email for more information on the Jacksonville Linux Users Group! -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: Fixed! (Re: mgetty isn't answering the phone (ioctl problem))
From: Pete Harlan [EMAIL PROTECTED] [ snip ] Look at the compilation options for both of them and make sure that they're each using, e.g., /var/lock/LCK..ttyS0 for the lockfile, and that they write their pid in the file in ASCII format (not binary). (This is from the Linux FSSTND.) Kermit, Minicom, pppd, any modem software you write, mgetty, etc., must agree on all of the above, and then it works like a dream. Except for the fact that I have to point minicom to /dev/ttyS0 (which is what mgetty is listening on) instead of /dev/cua0. I can see why it would be necessary to do this for management of locking, etc. But, after taking about 2 years to get myself thinking along the lines of separate devices for dialing *in* and *out*, I have a little trouble when someone basically says Eh, nevermind with the /dev/cua deal. Just use the ttyS devices.. Why, after years and years of needing them, are the /dev/cua's suddenly, seemingly, obsolete? - Joe -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: Fixed! (Re: mgetty isn't answering the phone (ioctl problem))
Joe Emenaker [EMAIL PROTECTED] writes: Why, after years and years of needing them, are the /dev/cua's suddenly, seemingly, obsolete? There was a post a long while back where the maintainer of the kernel serial devices said not to use cua's anymore if you can avoid it. He seemed to be indicating that they were now mostly around for compatibility purposes. -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: Fixed! (Re: mgetty isn't answering the phone (ioctl problem))
I use DCON.. its DCON that can't OPEN the port... pppd works fine, and mgetty work fine.. but its DCON that can't share the port... That would happen if DCON is trying to open, say, /dev/cua0, rather than /dev/ttyS0. mgetty will get in the way of that. The Serial Gods could tell you a lot more than I can, but I do know that if everyone uses ttySn then everyone is happy. I don't know what DCON is, but perhaps you can reconfigure it. Part of reconfiguring it is to make sure it obeys the locking conventions; as far as I know all the cuan devices did for you was a kernel-level lock, rather than the cooperative, user-space method used by programs sharing ttySn. Gorier detail: mgetty does a select() on ttyS0, waiting for the modem to do something (e.g., emit RING). Because mgetty has ttyS0 open, trying to open cua0 fails (or blocks, perhaps), which is presumably what's happening with DCON. But you can still open ttyS0, and use it; the first time you cause the modem to emit any characters, mgetty's select() returns, and if mgetty finds that someone else has written a lockfile it quits. If someone hasn't written a lockfile, then mgetty writes the lockfile itself and tries to make sense of what the modem is saying (usually RING, but maybe AT... if your program is trying to use the modem without having written the lockfile). The moral being that your program should open ttyS0, but if it hasn't written a lockfile before it talks to the modem, your program and mgetty will trip over each other trying to converse with it. -- Pete Harlan [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: Fixed! (Re: mgetty isn't answering the phone (ioctl problem))
Daniel Stringfield says he's using dcon scripting to connect to his isp, and that he's using locking in pppd, and that everyone uses ttyS3, and that the locks are in the right place, and... Actually, MGETTY isn't the one having the problems, its the program I use to log into my ISP. I use DCON scripting, not 'chat'... It adds some cool features... It can't open the port when I have mgetty running on that same port. Then you're not configuring it right. I just downloaded it and configured it (see how dedicated I am? :) and it 'worked' with mgetty. The reason I put quotes around 'worked' is because, according to dcon's own docs (this is dcon0.96), it doesn't perform locking. I had to write my own lock manually, and even then had to pad the beginning of the lockfile with spaces so mgetty would know it was ASCII, and finally I didn't bother to get the exact invocation of pppd working because it was clear that dcon didn't have any problems dialing into my provider, logging in, and starting pppd. (My pppd options are set up so all I have to do is type 'pppd' and I get connected; no dcon scripts, just a working /etc/ppp/options file; this interfered with final success of my dcon experiment, but the long and short of it is that dcon didn't have any trouble opening the port.) NB: If you want to use dcon (and I see no reason why you would; really, guy, rethink that decision!), you should manually write your lock using dcon's icky language and tell pppd *not* to use a lock (because dcon already locked it: pppd's lock attempt will fail). Don't worry about removing the lock when you're done; mgetty will eagerly do that for you. I'd be happy to show you my configurations for dcon, pppd, and mgetty. More to the point, I'd be happy to show you my script for 'chat' :) -- Pete Harlan [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: Fixed! (Re: mgetty isn't answering the phone (ioctl problem))
On Thu, 24 Oct 1996, Pete Harlan wrote: I use DCON.. its DCON that can't OPEN the port... pppd works fine, and mgetty work fine.. but its DCON that can't share the port... That would happen if DCON is trying to open, say, /dev/cua0, rather than /dev/ttyS0. mgetty will get in the way of that. The Serial Gods could tell you a lot more than I can, but I do know that if everyone uses ttySn then everyone is happy. I don't know what DCON is, but perhaps you can reconfigure it. No, its on /dev/ttyS3, both of them... Part of reconfiguring it is to make sure it obeys the locking conventions; as far as I know all the cuan devices did for you was a kernel-level lock, rather than the cooperative, user-space method used by programs sharing ttySn. Gorier detail: mgetty does a select() on ttyS0, waiting for the modem to do something (e.g., emit RING). Because mgetty has ttyS0 open, trying to open cua0 fails (or blocks, perhaps), which is presumably what's happening with DCON. But you can still open ttyS0, and use it; the first time you cause the modem to emit any characters, mgetty's select() returns, and if mgetty finds that someone else has written a lockfile it quits. If someone hasn't written a lockfile, then mgetty writes the lockfile itself and tries to make sense of what the modem is saying (usually RING, but maybe AT... if your program is trying to use the modem without having written the lockfile). The moral being that your program should open ttyS0, but if it hasn't written a lockfile before it talks to the modem, your program and mgetty will trip over each other trying to converse with it. Its DCON thats doing the tripping, is the problem :) -- Daniel Stringfield mailto:[EMAIL PROTECTED] http://www.jax-inter.net/user/servo Send email for more information on the Jacksonville Linux Users Group! -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: Fixed! (Re: mgetty isn't answering the phone (ioctl problem))
On Thu, 24 Oct 1996, Pete Harlan wrote: Daniel Stringfield says he's using dcon scripting to connect to his isp, and that he's using locking in pppd, and that everyone uses ttyS3, and that the locks are in the right place, and... Actually, MGETTY isn't the one having the problems, its the program I use to log into my ISP. I use DCON scripting, not 'chat'... It adds some cool features... It can't open the port when I have mgetty running on that same port. Then you're not configuring it right. I just downloaded it and configured it (see how dedicated I am? :) and it 'worked' with mgetty. I've never seen DCON in my life, to tell you the truth. As far as a package. Someone gave me the script, and the dcon binary, and said, here run this... I've been running the DCON for quite some time now... and I suppose its very outdated. I ought to slap the guy that gave it to me NB: If you want to use dcon (and I see no reason why you would; really, guy, rethink that decision!), you should manually write your lock using dcon's icky language and tell pppd *not* to use a lock (because dcon already locked it: pppd's lock attempt will fail). Don't worry about removing the lock when you're done; mgetty will eagerly do that for you. The only reason why I have been using it, is because it does automatic redial. Believe me, with my ISP, its a much needed feature.. And not to mention that I've been running it for a long time. (Before I ran debian, in fact) I'd be happy to show you my configurations for dcon, pppd, and mgetty. More to the point, I'd be happy to show you my script for 'chat' :) That'll work:) But I really want automatic redial. I haven't used chat in so long.. I dunno if you can do that or not... these days.. All in all, its been one of those 'it works, don't change it' things...:) -- Daniel Stringfield mailto:[EMAIL PROTECTED] http://www.jax-inter..net/user/servo Send email for more information on the Jacksonville Linux Users Group! -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: Fixed! (Re: mgetty isn't answering the phone (ioctl problem))
Joe Emenaker wrote: Why, after years and years of needing them, are the /dev/cua's suddenly, seemingly, obsolete? Rather than just saying RTFM, I've gathered it up for you. = This is explained in the mgetty file: /usr/doc/mgetty/ttyS-cua.txt QUOTE: Date:Mon, 13 May 1996 07:57:09 +1000 From: Tony Nugent [EMAIL PROTECTED] Can someone kindly explain the difference between the /dev/cua? and /dev/ttyS? devices? /dev/ttySxx devices are fully POSIX-compliant TTY devices. If you are only going to be using one set of tty devices, you should be using /dev/ttySxx. /dev/cuaXX devices are different from /dev/ttySXX in two ways --- first of all, they will allow you to open the device even if CLOCAL is not set and the O_NONBLOCK flag was not given to the open device. This allows programs that don't use the POSIX-mondated interface for opening /dev/ttySxx devices to be able to use /dev/cuaXX to make outgoing phone calls on their modem (cu stands for callout, and is taken from SunOS). The second way in which /dev/cuaXX differs from /dev/ttySXX is that if they are used, they will trigger a simplistic kernel-based locking scheme: If /dev/ttySXX is opened by one or more processes, then an attempt to open /dev/cuaXX will return EAGAIN. If /dev/cuaXX is opened by one or more processes, then an attempt to open /dev/ttySXX will result the open blocking until /dev/cuaXX is closed, and the carrier detect line goes high. While this will allow for simple lockouts between a user using a modem for callout and a getty listening on the line for logins, it doesn't work if you need to arbitrate between multiple programs wanting to do dialout --- for example, users wanting to do dialout and UUCP. I originally implemented the cuaXX/ttySXX lockout mechanism back before FSSTND established a standard convention for the use of tty lock files. Now that it's there, people should use the tty lock files and not try using /dev/cuaXX. The only reason why /dev/cuaXX hasn't disappeared yet is for backwards compatibility reasons. = And here's a quote from the Info file: /usr/info/mgetty.info-3.gz QUOTE: *Important note:* Use the `/dev/ttyS*' devices for getty and for dial-out (that is, for kermit, uucico, cu, seyon, ...) - *never* use `/dev/cua*'. Dialing out on `/dev/cua*' will result in the error message device busy. (There are reasons why `mgetty' cannot use the `ttyS*' vs. `cua*' kernel locking mechanism, see below). If *all* programs agree on using `/dev/cua*' only, it will work, too - but they have to agree on one variant. For some background about `ttyS' vs. `cua', you might want to read a mail from the author of the Linux serial drivers, Ted Ts'o, posted to the Linux-PPP mailing list. I have included it in `doc/ttyS-cua.txt'. Some guys seemingly can't resist posting misinformation to the net all the time, don't believe 'em. The `/dev/cua*' devices are *not* different from the `/dev/ttyS*' devices concerning data flow or modem control lines. The only difference is how the device reacts if you do an `open()': Opening `/dev/ttyS*' normally blocks until the carrier detect line goes active (unless `open()' is called with the `O_NDELAY' flag; `mgetty' and all dial-out programs do that), and opening `/dev/cua*' will return an error message (`errno=EBUSY') if another process has the device already open, thus *preventing dial-out on `/dev/cua*'* if `mgetty' is active on `/dev/ttyS*'. We use `/dev/ttyS*' all the time for dial-in *and* for dial-out, and believe me, it works, and it's the *only* combination that will work properly. The kernel locking mechanism only works if you use modem auto-answer (the getty process sleeps until the modem gets a carrier), and mgetty uses manual answer (it waits for the RING message from the modem), which will save your callers a lot of grief because their calls will only be answered if your computer is ready to receive a call. Part of the motivation for writing mgetty was being tired of losing lots of money for useless calls to a hung machine. I'd recommend against using `/dev/modem' as a link to the real device, but if you do that, make it a *hard link* to the appropriate `/dev/ttyS*'. A soft link will cause problems with the device ownership because of a peculiarity in the linux `chown()' implementation (that I refuse to work around). = And, here's a quickie from the mgetty FAQ: /usr/doc/mgetty/FAQ.gz Q: I have a Linux system, and while trying to dial out on /dev/cua1 (mgetty is running on /dev/ttyS1), it says device busy (EBUSY)??? A: use the same device (always!!) for dial-in and dial-out. On Linux, use /dev/ttySx, on SunOS and *BSD use /dev/cuax. -- ...RickM... -- TO UNSUBSCRIBE
Fixed! (Re: mgetty isn't answering the phone (ioctl problem))
...When I call from a normal phone, I hear a ring, a click, another click, and then that's it. A peek at /var/log/mgetty/mg_ttyS0.log shows: [snip] 10/22 16:42:03 yS0 waiting for ``RING'' ** found ** 10/22 16:42:03 yS0 cannot set controlling tty (ioctl): Operation not permitted [snip] It turns out that mgetty does NOT like being run from a login session. I guess the reason it couldn't set a controlling tty was because it already *had* one... the one I ran mgetty from. So, that gets back to, why wasn't it working when I was using it in inittab? Well, it turns out that the agetty line I had been using (before someone suggested I use mgetty) had set the modem's S0 register to 1. So, as near as I can tell, the modem was answering the modem on its own volition just moments before mgetty sent an ATA which, I believe, toggles the online state (hangs up if off-hook, picks up if on-hook). Hence, the two clicks, I guess. So, putting ATS0=0 in the init line for that tty fixed the problem. However, this has *not* fixed the bizzare problem with pppd thinking I don't have PPP support compiled in, even though I do. Also, the person who suggested that I use mgetty seemed to think I was kiiky for wanting to use uugetty. Well, if he's listening, I'd like to add that, under mgetty, I *still* can't dial out on the modem that mgetty is sitting on. The whole reason I wanted to use uugetty was that it supposedly allowed for dial-in and dial-out without having to do the inittab shuffle. Just thought you might like to know - Joe -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: Fixed! (Re: mgetty isn't answering the phone (ioctl problem))
Also, the person who suggested that I use mgetty seemed to think I was kiiky for wanting to use uugetty. Well, if he's listening, I'd like to add that, under mgetty, I *still* can't dial out on the modem that mgetty is sitting on. The whole reason I wanted to use uugetty was that it supposedly allowed for dial-in and dial-out without having to do the inittab shuffle. I've found mgetty to work much better for us than uugetty; but as for your claim, no, you _can_ dial in and out with either package. Email me directly and I'll help fix your mgetty (and ppp, probably) woes; having made every mistake in the book (including your 'ata toggles the line' trouble), I expect I can get yours working. No need to fill the list with it (but I did want to correct your uugetty mgetty claim.) Cheers, -- Pete Harlan [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: Fixed! (Re: mgetty isn't answering the phone (ioctl problem))
On Tue, 22 Oct 1996, Joe Emenaker wrote: However, this has *not* fixed the bizzare problem with pppd thinking I don't have PPP support compiled in, even though I do. In my experience, I've had to turn MGETTY OFF when I wanted to make an outbound PPP call. Dunno exactly why. I can dial out when I have MGETTY running, if I dial out with something like Minicom. -- Daniel Stringfield mailto:[EMAIL PROTECTED] http://www.jax-inter.net/user/servo Send email for more information on the Jacksonville Linux Users Group! -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: Fixed! (Re: mgetty isn't answering the phone (ioctl problem))
In my experience, I've had to turn MGETTY OFF when I wanted to make an outbound PPP call. Dunno exactly why. I can dial out when I have MGETTY running, if I dial out with something like Minicom. Sounds like your pppd is not getting its locks right. Possible causes: 1) it has not been told to use locks (``lock'' on the command line or in the options file sorts this out) 2) You may be mixing /dev/ttyS? with /dev/cua? devices --- mgetty doesn't like cua's and you should not use them at all on a port that mgetty is using. 3) pppd has been compiled to put the locks in the wrong place. If you run: strings /usr/sbin/pppd | grep LCK you should get ``/var/lock/LCK..'' --- If not you need a different pppd. A clasic symptom of this sort of locking failure is that you will see mgetty's attempts to reset the modem in the logs of the outgoing chat --- Mgetty doesn't know you're still using its line, so it goes ahead and resets it almost as soon as you start dialing. Cheers, Phil. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
