Linux installation: Second Ethernet interface ...

[mikebw at bilow.bilow.uu.ids.net (Mike Bilow)]

John Chambers wrote in a message to Mike Bilow:

 JC> From: John Chambers <root at minya>

I think you need a domain name somewhere.

 JC> | root wrote in a message to Mike Bilow:

 JC> Hmmm ... No, it was to discuss at blu.org, not to Mike.  But
 JC> maybe I can get  the  goofy mailer to correctly identify me
 JC> this time.  (But then there's a guy I'm working for now at
 JC> Digital - oops, I meant Compaq - whose   email  usually 
 JC> goes  out  identified  as  having  come  from
 JC> firstname.lastname at localhost.zko.dec.com.  ;-)

My mail program takes the personal name, such as it is, from the headers. This
system is rather old, and it actually is UUCP-connected.  If, by the time the
mail has been read and replied, it looks a bit funny, I'm sorry.

 JC> That's funny; every linux system I've ever used (not all 
 JC> that  many, but   several   different   releases)   have 
 JC> had  a  program  called control-panel, which is a GUI for
 JC> doing assorted superuserish  things to the system. The FAQs
 JC> and HOWTOs that I've been reading all like to suggest this
 JC> as the best way to configure your system. Are we perhaps
 JC> talking about different systems, both called "linux"?

I think I know Linux when I see it.  I'm prepared to accept that your Linux
distribution has some sort of GUI configuration tool, but this is not standard.
Command line tools and text files are standard, and the GUI tool probably just
spawns the usual command line tools and writes the usual text configuration
files.

 JC> Hmmm again.  This system (Redhat 5.1) has no file by  that 
 JC> name.   I tried the command
 JC>    find / -name '*modules.conf*' -print
 JC> and  it finds no files whatsoever.  I even have my old
 JC> system mounted so I can compare files, and it had no such
 JC> file name, either.  I also    grep modules.conf
 JC> /usr/doc/HOWTO/*
 JC> This directory has 31Mbytes of data, and there was only one
 JC> match, in the Busmouse document.  Are we in the same
 JC> universe?

If "modules.conf" exists on your system, it would be in "/etc".  This could
theoretically be modified in the modutils source, but that's unlikely.  If you
don't have this file, then there are several possibilities.  First, the old
(deprecated) file was "/etc/conf.modules", and this is still supported for
reasons of backward compatibility.  Second, you might have neither file, and
then "modprobe" runs on the default configuration which is hardcodeed into it.
You can issue "modprobe -c" to make it dump its current configuration.

By the way, I regard it as a serious security risk to have no files
"/etc/modules.conf" or "/etc/conf.modules" on a system with kerneld running. I
recommend that "/etc/conf.modules" should always exist as a zero length file
owned by root and with permissions 644.  Even if you don't need it,
"/etc/modules.conf" should always exist owned by root with permissions 644. If
either file does not exist, someone other than root could create it and get
their own binaries loaded with kernel privilege, which could be disastrous.

 JC> I just checked with "man kerneld", and its man page  lists 
 JC> no  files that it reads. In fact, the page doesn't contain
 JC> the string "file" in any capitalization. So it appears that
 JC> this kerneld doesn't read from any files (or it does and the
 JC> fact isn't documented).

As I said, kerneld does not read these files.  Instead, kerneld spawns the
"modprobe" utility which reads the configuration table generated by the
"depmod" utility based on the contents of "/etc/modules.conf".  You can
probably find out more useful information with "man depmod" and "man modprobe".

 JC> Hmmm yet again. Sounds like confused terminology. It seems
 JC> to me that interface  names  like  "eth0" don't refer to
 JC> hardware, but rather to software, in particular to kernel
 JC> data structures.  After all,  "lo0" is  an  interface name,
 JC> and it clearly doesn't refer to hardware, but just to a
 JC> software object in the kernel.  Granted, "eth0" does  refer
 JC> to hardware in some sense, though, which is why I'd call it
 JC> confused. 

Look, the mapping between interface names such as "eth0" and the driver modules
is specific to your hardware, and is set in your "/etc/modules.conf" file. 
This is done with a line like "alias eth1 3c509" or whatever.

 JC> In any case, "ifconfig eth1 up" is what the ifconfig  man 
 JC> page  says attaches interfaces, but this doesn't work:
 JC>    : ifconfig eth1 up
 JC>    : echo $?
 JC>    255
 JC>    : ifconfig eth1
 JC>    eth1: unknown interface.
 JC>    : 
 JC> So however eth1 is supposed to come into existence,  this 
 JC> isn't  it. One mystery so far is just who creates (or
 JC> attaches or activates) the lo0 and eth0 interfaces.  They
 JC> seem to just appear "as if by  magic", but  whoever does the
 JC> job doesn't make eth1 exist.  In my experience, this is
 JC> always a bit of black magic that is different on  every 
 JC> Unix system that I've ever seen.

Well, sure, don't listen to me.  I just write the damned drivers.  It's not
like I ever have time to test them to see if they work.  I just write these
messages to public mailing lists in a nefarious attempt to get you to take my
advice seriously and beat your head against your keyboard in frustration.

 JC> Hmmm ...  I read "man insmod" and tried running it a few
 JC> times.   The new  card  is a 3Com 3c509b, and there is a
 JC> 3c509.o module that might work.  But whenever I run insmod,
 JC> it just tells me:
 JC>    /lib/.../3c509.o:  init_module:  Device or resource busy
 JC> It's not obvious what this  might  mean.   How  can  the 
 JC> device  (or resource) be busy if it's not even loaded?

Try "lsmod".  But that just tells you if the driver is loaded.  If you have the
same type of card for both eth0 and eth1, then you don't need to reload the
driver to handle the second card.  You do need to let the kernel know how to do
all this stuff, and that is what "/etc/modules.conf" is for.

However, I can tell you right now that the most common reason for a 3C509 card
to fail under Linux is that you have it set in PnP mode.  One reason this is
common is because that is how they leave the factory now.  To change this, you
need to run the "3C5X9CFG" utility (under DOS) that comes on the Etherdisk. The
latest Etherdisk 6.0 for the 3C509 is available in a two-disk set from
"http://infodeli.3com.com";.  Linux can use the card in PnP mode, provided that
you use the "isapnp" tool utility to configure it at boot, but it is simpler to
run the card with PnP disabled and handle it as standard.  Obviously, if you
run two separate 3C509 cards in the same machine, they need to be on different
base addresses and IRQs.

 JC> Probably.  I just have to figure out what to  type.   And 
 JC> of  course there's  always  the  danger of totally killing
 JC> the system if I do it wrong (which is highly likely, since
 JC> this is a  new  system  full  of mystery, so I'm once again
 JC> just a bumbling novice at it all. But if I wait until I
 JC> understand it all, I'll die of old age first ...  ;-) 

 JC> (I've already done things a couple of times that seemed to 
 JC> tuen  the system  into  a  near-total zombie, and had to
 JC> resort to rebooting my old linux, zapping the new partition,
 JC> and installing from scratch. It seems somewhat fragile.)

We never claimed that Linux was user friendly.  We just claim that it works.
 
-- Mike