About the 2 macs and 1 linux on a LAN

John F. Kohler jkohler2 at earthlink.net
Mon Jul 17 12:00:49 PDT 2000


Just fooling around from the root prompt at the path Scott Doty recommended , I
tried the following:

[root at jfkhost network-scripts]#cat ifcfg-eth0

and I got the following:

DEVICE="eth0"
USERCTL="yes"
ONBOOT="yes"
BOOTPROTO="none"
BROADCAST=192.168.1.255
NETWORK=192.168.1.0      (should this be 192.168.1.1?)
NETMASK="255.255.255.0"
IPADDR="192.168.1.4"
IPXNETNUM_802_2=""
ipxprimary_802_2="no"
IPXACTIVE_802_2="no"
IPXNETNUM_802_3=""
IPXPRIMARY_802_3="no"
IPXACTIVE_802_3="no"
IPXNETNUM_ETHERII=""
IPXPRIMARY_ETHERII="no"
IPXNETNUM_SNAP=""
IPXPRIMARY_SNAP="NO"
IPXACTIVE_SNAP='no"

I don't know what to make of that, unless it is a bunch of settings.

John

ME wrote:

> On Mon, 17 Jul 2000, John F. Kohler wrote:
> > I was able to complete the following command
> > #/sbin/ifconfig
> > with the following result
> >
> > lo        Link encap:local loopback
> >     `    inet addr:127.0.0.1 mask:255.0.0.0
> >     UP LOOPBACK RUNNING  MTU:3924 Metric:1
> >         RX packets:18 errors:0 dropped:0 overruns:0 frame:0
> >         TX packets:18 errors:0 dropped:0 overruns:0 carrier:0
> >         collisions:0 txqueuelen:0
>
> Yes, this is what is called the "loopback" interface. It is used for many
> things. Primarily, it is used to allow your machine to talk to itself over
> a kind-of pseudo-network. Packets traverse the same chains and rules that
> incoming and outgoing packets might pass, but packets to/from "loopback"
> do not (or are not supposed to) go to the wire/physical media.
>
> When you have the Kingston card working as it should, then you should not
> only see "lo" as an interface but also "eth0" as another interface too.
>
> Incidentally, you would also see the above if you just did:
> # ifconfig lo
> when typing ifconfig byitself such as:
> # ifconfig
>
> all (have not come across) linux distros are likely to show you all of the
> interfaces the kernel/system knows about. If you have a PPP connection,
> then you might see ppp0 as an interface, a SLIP connection might show sl0,
> a second PPP interface might be ppp1.
>
> > # /sbin/depmod-a
> > got no respons, just another
> > root prompt.
>
> Good. depmod is often not verbose in responses. It usually works, and says
> nothing. When you see messages from depmod, they are often a result of an
> error or two. (No errors is a good thing.)
>
> >
> > Then I tried /sin/modprobe tulip debug=6
> >
> > and this was the response
> >
> > /lib/modules/2.2.14-5.o/net/tulip.o:invalid parameter parm_irq
> > /lib/modules/2.2.14.5.0/net/tulip.o:insmod /lib/modules/2.2.14-5.0/net/tulip.o
> > failed.
> > /lib/modules/2.2.14-5.0/net/tulip.o: insmod tulip failed
> >
> > By this, I wonder if the kernel can't talk to the kingston card or if the
> > kingston card will not
> > answer back.
>
> We can look into other arguements to offer the module when inserting it.
>  I'll try to respondmore later...
>
> -ME




More information about the talk mailing list