About the 2 macs and 1 linux on a LAN

[John F. Kohler]

After some helpful hints from Scott Doty,
I did get a successful response from eth0; ( I also physically changed the kingston
card from one slot on the backplane to another one, just to help.

[root at jfkhost network-scripts]# /sbin/ifconfig eth0

eth0            Link encap:ethernet HWaddr 00:C0:F05B:10:5B
                    inet addr:192.168.1.4 Bcast: 192.168.1.255 Mask:255.255.255.0
                    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
                    RX packets:4 errors:5 dropped:0 overruns:0 frame:5
                    TX packets:75 errors:0 dropped:0 overruns:0 carrier:0
                    collisions:0 txqueuelen:100
                    interrupt:11 Base address:0x6000  (this last line conforms to
"qstart" info)

since I was encouraged by this response I tried to get the Linux to ping itself:

[root at jfkhost network-=scripts] ping 192.168.1.4
PING 192.168.1.4 (192.168.1.4) from 192.168.1.4 : 56(84) bytes of data
64 bytes from 192.168.1.4: icmp_seq=0 ttl255 time=0.4 ms
64 bytes from 192.168.1.4: icmp_seq=1 ttl=255 time=0.3 ms
64 bytes from 192.168.1.4: icmp_seq=2 ttl=255 time=0.2 ms
64 bytes from 192.168.1.4: icmp_seq=3 ttl=255 time=0.2 ms

... and so on and so on.
----192.168.1.4 ping statistics---
10 packets transmitted 10 packets received, 0% packet loss
round trip min/avg/max = 0.2/0.2/0.4 ms

[root at jfkhost network-scripts #

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