Re: [aclug-L] Modem configuration question

[John Goerzen <jgoerzen@xxxxxxxxxxxx>]

"Brian J. Chapman" <bchapman@xxxxxx> writes:

> At 04:14 PM 10/15/98 -0500, John Goerzen wrote:
> > Bzzt, wrong answer :-)    (nice try though <g>)
> 
> Oh thats right, answers are supposed to be in the form of a question. I'll
> take Outdated Linux Devices for $100 Alex! Heehee...Linux Jepordy, now
> that would make a cool game!

Hehe, it sure would.  Hmmm....  Now I'm thinking this would be a cool
thing to write.  Uh-oh.  Another project to distract me from other
things :-)

> Doh! Actually, now that you mentioned it, i think i did read somewhere
> about that. But that's the story of my life, learning things the hard way.

Hehe, you're not the only one.  Look what I get for recommending 3com
Ethernet cards: they go and mess things up so they no longer play
nicely with Linux (apparently; those Ethernet card vendors change
chipsets frequently).  I am also rather embarassed that I didn't think 
of a # sign in a pap secrets password file causing problems for over a 
week.  (DOH!)

> Guess how I learned to take a moment and make sure the power is off on a
> computer before removing any expansion cards!

Hehe :-)

> Yes! By all means! Anything you can give me.

OK.

The cua* devices are a holdover from older Unices.  When combined with
ttyS* devices, they have certain automated behavior when the ports are
connected to dumb terminals, or perhaps even to dumb modems.  However,
modern *getty programs do a much better job than the cua devices
provide, so it's best to ignore them and let them die.

> So would symlinks be okay to use on single user systems?, because thats
> all mine is.

The issue here is locking.  This is the operating system's attempt to
protect you from yourself :-)

Basically, the idea is that only one process should be talking on a
given serial port at any one time.  It is bad, for instance, if your
mouse driver and terminal program both are talking to the same port.
Neither a mouse nor a modem will work in that situation.

To this end, Unix has traditionally used "lockfiles" for serial
ports.  These lockfiles work based on the name of the port.  This is
all fine and dandy if all of the programs use ttyS2, for instance.

However, what if you have /dev/modem linked to ttyS2?  Some programs
will use /dev/modem, others may try to resolve the link to ttyS2, and
you may tell other programs just to use ttyS2 directly.  The result:
confusion.  The locking mechanism sees this as two separate devices,
/dev/modem and /dev/ttyS2.  This can mean that your devices may go
unlocked, and then you may accidentally get stray things into your
data stream.

It's not terribly hard to fire up pppd, forgetting that you have
minicom running, for instance.  (Yes, I've done this <g>) And if you
are using diald, you absolutely must get it right, which means no
/dev/modem link.  The reason is that diald may try to dialout when it
thinks the modem is not in use -- and if the modem really IS in use,
but diald thinks it's not, it can mess up whatever you're doing with
the modem.  So it does matter even on single-user machines.



-- 
John Goerzen   Linux, Unix consulting & programming   jgoerzen@xxxxxxxxxxxx |
Developer, Debian GNU/Linux (Free powerful OS upgrade)       www.debian.org |
----------------------------------------------------------------------------+
Visit the Air Capital Linux Users Group on the web at http://www.aclug.org
---
This is the Air Capitol Linux Users Group discussion list.  If you
want to unsubscribe, send the word "unsubscribe" to
aclug-L-request@xxxxxxxxxxxx.  If you want to post to the list, send your
message to aclug-L@xxxxxxxxxxxx.