[conspire] Netzero/Breezy

[Rick Moen]

Quoting John Andrews (jla1200 at netzero.net):

>     Daniel or Rick
>     Daniel said add  L modem ttyS0 to the file etc/udev/links.conf .I have
> not tried this fix yet.
>  Is there a /dev/xxx that goes in the second column with that?

As Daniel said, the line for /etc/udev/links.conf (note leading slash,
which is _very important_) should be:

L modem	ttyS0

That's an instruction to the udev subsystem, at boot time, to create
(symbolic) link "modem" pointing to special file "ttyS0" inside the /dev
directory.

Let me give a little background explanation, for the benefit of those
who are curious.  If you're not, you're most welcome to skip whatever
bores you.  ;->

"udev" is a new software subsystem for the Linux kernel, introduced in
the 2.6 series (approximately), for the purpose of managing what's in
the /dev filesystem tree.  Ubuntu/Kubuntu uses it, on account of its
default 2.6.x kernel.

The /dev tree contains funny-looking files (that aren't regular files at
all; hence the term "special file") intended to serve strictly as entry
points to hardware that can then be used for that purpose by the kernel
and all other software.  

For example, serial ports ttyS0 through ttyS4 (aka COM1 through COM5)
are addressed with "major device number" = 4, and "minor device numbers"
= 64 through 68:

:r! ls -l /dev/ttyS*

crw-rw----  1 root dialout 4, 64 2004-09-18 04:52 /dev/ttyS0
crw-rw----  1 root dialout 4, 65 2004-09-18 04:52 /dev/ttyS1
crw-rw----  1 root dialout 4, 66 2004-09-18 04:52 /dev/ttyS2
crw-rw----  1 root dialout 4, 67 2004-09-18 04:52 /dev/ttyS3
crw-rw----  1 root dialout 4, 68 2004-09-18 04:52 /dev/ttyS4
^   ^       ^  ^     ^     ^  ^     ^         ^       ^- filename
|   |       |  |     |     |  |     |         |- last modified time
|   |       |  |     |     |  |     |- last modifed date
|   |       |  |     |     |  |-minor device number
|   |       |  |     |     |-major device number
|   |       |  |     |-owning group
|   |       |  |-owning user
|   |       |-total number of hard links to this file
|   |-rights mask
|-type of file (regular, directory, symlink, character, block, named pipe, socket)

(If those columns don't line up, then you really should stop reading
e-mail / newsgroups in variable-space typefaces.  Use a fixed-space
typeface such as Courier.)

On old-style Unixey systems, /dev's contents are completely static:  It 
gets populated at the time you install your operating system with
special files (block and character device files) corresponding to every 
type of hardware the OS designers anticipate you might ever connect to
your system.  Note:  The existence of a special file doesn't _in any way_
guarantee that the corresponding hardware exists, or that it's enabled
in the motherboard BIOS setup, or that your kernel has a driver for it.

(I mention that matter because it's a frequent stumbling block, during
Linux diagnosis:  "What do you mean, I need to verify that the serial
driver is loaded into my kernel, and that serial support is turned on in
the motherboard setup program?  I've checked that /dev/ttyS0 exists.
Doesn't that means it's supported?")

In roughly the Linux 2.4 series, an optional automated subsystem emerged
for populating /dev with special files for _only_ hardware actually
present and driver-supported on your system, "devfs".  This was used (by
default) by only one mass-market distribution, Mandrakelinux, now known
as Mandriva Linux -- but also Gentoo Linux and the LNX-BBC
micro-distribution.   However, there were some problems and limitations
with it, the most serious of which was its maintainer vanishing for a
couple of years in a row.  As a result, Greg Kroah-Hartman invented
"udev" as a replacement, in May 2003:

http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html

"udev" is still mysterious to most Linux users, even technical ones,
in part because most Linux systems still use 2.4.x kernels.  (For
example, it's _really_ new to me, personally.)  It has several major
advantages over everything that's come before:

o  It finally allows persistent, meaningful device names.
o  It eliminates the need for a static map of device numbers.
o  It emits D-BUS messaging information to tell other software about
   what devices the kernel knows (or has just learned) about.
o  It's commendably tiny, and operates almost entirely outside the kernel.

We old fogies really _should_ by this late date have converted all our
Linux systems over to 2.6.x kernels, read up on udev + hotfix + nameif +
D-BUS, and purged our minds of the dumb assuption of static /dev
contents that are manually edited by the sysadmin.  I haven't, so I'm
behind the curve, and feel bad about this.

Now, John:  Daniel originally created a /dev/modem symbolic link
("symlink") pointing to /dev/ttyS0 on your system for the Netzero
dialer's benefit, but apparently warned you, at the time, that because
udev creates the /dev tree from scratch every time you reboot, his 
manual creation of /dev/modem wasn't going to suffice over the long
term, and you'd have to convince udev to include that symlink in its
boot-up tasklist.  The /etc/udev/links.conf file is one place where a
sysadmin can specify exactly such a tasklist -- both additional special
files to create within /dev and symbolic links to put there.  Another is
/etc/udev/rules.d/10-local.rules , which you could create and add a line
like:

KERNEL="ttyS0", SYMLINK="modem"

>     Ls -l modem indicates a link is present in the /dev directory.

John, it's a little unsetlling to see you type things like "Ls", since
Linux filenames are case-sensitive and the correct command name is "ls".
Seeing that sort of thing -- and, again, I mean no personal criticism -- 
inevitably forces technical observers to wonder how accurately you are
reporting other crucial details.  Bitter experience has taught us that,
when the user isn't reporting details accurately, helpers often end up
wasting their and the user's time going on wild goose-chases.

Would you please get in the habit of double-checking things like the
above, and transcribing them _verbatim_?  You can do this either using
notepaper or copy-and-paste (if possible) or logging commands to file
using /usr/bin/script.  (Typing "script" commences the logging of all
command-lien activity from that point forward into an ASCII text file,
default name "typescript".  Typing "exit" ends logging.)

You can move files between computers using a DOS-formatted floppy:

$ mcopy typescript a:

...or by copying the file onto a USB flash drive.

To illustrate what I suggest, imagine that I wanted to show you what
"/dev/modem" pointed to on my system.  Then, I would do the following
and transcribe or copy it verbatim to this message:

$ ls -l /dev/modem
lrwxrwxrwx    1 root     root            5 Dec 17 07:03 /dev/modem -> ttyS0
$ 

Why don't you do that, as an exercise -- and to better inform us?  Also,
because udev recreates /dev from scratch upon each reboot, please
clarify, if /dev/modem _does_ exist, that you haven't created it
manually since the most recent startup.  Please note that my above
example illustrates my dictum that you should assume our motto is "Show
me" (the state of Missouri's motto):  Instead of _telling_ the mailing
list what /dev/modem points to, I _showed_ it.

(Don't worry if your command prompt is not just "$":  It probably will
be something more complex, such as your username, the hostname, and part
or all of the current directory.  This is normal.  I used "$" just for
simplicity.)

> The Netzero logon dialog boxes do not contain any way to specify /dev/modem
> or dev/ttyS0. Just a radio button to specify a hayes compatible modem.There
> is no way to tell NZ that it is an external serial modem .

OK, so Daniel's surmise that it's hard-coded for something, almost
certainly /dev/modem, is correct.

>     I.m having trouble getting a file that Windows 98 can read from
> OpenOffice.org. (.odt,.swd,.doc,.txt,.sxw,.sdw.). Otherwise I would send my
> terminal output.

Please see my prior e-mail's suggestions:  It's very difficult to help
you when you don't detail what _specifically_ you tried, but only say
you're "having trouble" or that something "doesn't work".

Remember:  If you cannot transcribe your terminal sessions using
software, you can always do it the old-fashioned way with notepaper.