Hi, I'm having a problem getting my (new) linux box talking to other machines through its ethernet cards. At present I have this arrangement:-
Linux box:
RH7.3, RealTek 8139 NIC -eth0, SiS900 - eth1
Switvh - Surcom EP-808X 10/100 switch.
PC:
Compaq Laptop, with a Xircom Ethernet II PS credit card network card.
I have set the IP addresses manually/statically to be :
eth0 192.168.0.1
eth1 192.168.0.9
Laptop 192.168.0.127
I've checked the Laptop on another LAN with the current configuration and it sees everything just fine.
When I try to ping it from the Linux Box I get :
PING 192.168.0.127 (192.168.0.127) from 192.168.0.1 : 56(84) bytes of data.
From 192.168.0.1 icmp_seq=1 Destination Host Unreachable
From 192.168.0.1 icmp_seq=2 Destination Host Unreachable
I tried to load a 'new' rtl8139.o but that was less than successful.
So now I'm keen to load the 'right' drivers and test the installation.
Any and all suggestions welcome.
Thanks
michaelk
12-16-2002, 11:50 AM
What distro are you running on the laptop and is it running a firewall?
What does the ifconfig command tell you? Does it show both eth0 and eth1 assigned an IP address and are they up? Which NIC is connected to the switch since the ping command is going out the eth0.
Do the switch link lights blink and show the correct settings when you ping?
rioguia
12-16-2002, 12:36 PM
how is your firewall setup? if you selected highest security you might be blocking yourself. to test this, turn off your firewall and then check your network connection by typing mii-tool and hitting return.
you have two nics in your linux box. it looks like you want to share your internet connection through your linux box. if so, have you set up your routing table? your ping packets might not be routed correctly.
to check type:
# route -n [return] (you should see something like below)
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.1.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 10.1.1.1 0.0.0.0 UG 0 0 0 eth0
If you do have a problem, you can try adding a default gateway (the last of the three lines above) with
/sbin/route add default gw 10.1.1.1 (substituting the correct IP address for 10.1.1.1
to check the status of your connection, type
mii-tools (if you get an OK at the end of the display, then you are all set)
and then if you still have problems post the results of your latest
route -n
beach_defender
12-16-2002, 05:38 PM
Hi,
Thanks for the advice. Covering off some of the questions.
1. the laptop is running Wincrap 95 SR2, no firewalls - it seems to work as I said below
3. More interestingly mii-tool gives -
eth0: 10 Mbit, half duplex, no
eth1: negotiated 100baseTx-FD,
4. route -n gives :Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
139.134.13.113 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.0.0 192.168.0.1 255.255.255.0 UG 0 0 0 eth0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 139.134.13.113 0.0.0.0 UG 0 0 0 ppp0
I'm not all that familar with mii-tool (in fact I'd never heard of it before) but if I'm reading it right, it seems that the card/driver is not working.
I'll try to update the rtl8139too.o
Anymore thoughts welcomed in great detail. Thanks in advance.
:confused:
rioguia
12-16-2002, 06:23 PM
sorry. i won't be much more help because it looks to me like you are using a modem (point-to-point) for your gateway and i don't have any experience with that.
since the point-to-point is first in the routing table, i would expect that your ping would start from that interface and go out the default interface (your same p-to-p) but I haven't heard anything about how that is connnected (plugged into) your network. if you don't intend this i would disable the modem temporarily and see how that simplifies your routing table issues. but since i don't know anything about modems and netowrking with them, i really don't have much to offer.
beach_defender
12-16-2002, 06:30 PM
Hi again,
Thanks for that, I get no joy regardless of whether the modem is active or not. I'm concerned about the results of the mii-tool utility. I think I'll keep trying.
Thanks for your help. If you have anymore thoughts let me know.
Cheers,
rioguia
12-16-2002, 08:29 PM
ok if the modem is not part of your network setup at issue, that simplifies things. disabling the modem is only part of the solution. by disabling the modem you are doing two things: (1) with the modem out of the way, you will probably advance your 192.168.0.1 interface to the top of the routing table (making the ping go out through eth0 most likely); but you are also disabling the default gateway. without knowing, i am assuming that you want the 192.168.0.1 to be your default gateway. if so, try disabling the modem and adding /sbin/route add default gw 192.168.0.1
then post your table back here
route -n
also can you tell us about your setup, eg.
______
internet
|
\/
router
|
\/
linux box (eth0)
(eth1)
|
\/
other pc
beach_defender
12-17-2002, 08:40 AM
Ok,
Killed the modem (had to start it up again to send this though)
route -n outputs:
Destination Gateway Genmask Flags Metric Ref Use Iface
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0
The current set up is :-
PPP connect to Internet through 56K Modem (I am upgrading to ADSL 'soon')
|
|
\/
Linux Box :
i think we are making progress. the only thing you are missing is that your eth0 forgot its configuration.
ifconfig eth0 192.168.0.1 netmask 255.255.255.0
then route -n (your routing table should look like this now)
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0
if you run into problems with the command line stuff above, try typing:
netconfig (your might need to netconfig eth0; sorry i'm not at a linux box to check)
its a really simple console tool that works really well.
beach_defender
12-18-2002, 08:24 AM
Hi again,
I've done the route -n thing and it produces exactly the output we'd hoped for.
I have a nasty feeling though that it is not a routing problem but at a lower level.
As I said earlier when I issue an mii-tool command I get a response that indicates there is no link present on eth0. I 'assume' this means its not talking to anything, so the routing tables are relatively irrelevant.
-- Does this dound like sound logic? (Logic appears all that is left at present)
I have downloaded several tools - rtl8139-diag and mii-diag to be specific and get the following results from them :-
mii-tool (recap)
eth0: 10 Mbit, half duplex, no link
eth1: negotiated 100baseTx-FD, link ok
mii-diag --force
Using the default interface 'eth0'.
Basic registers of MII PHY #32: 0000 0000 0000 0000 0000 0000 0000 0000.
No MII transceiver present!.
Basic mode control register 0x0000: Auto-negotiation disabled, with
Speed fixed at 10 mbps, half-duplex.
Basic mode status register 0x0000 ... 0000.
Link status: not established.
Link partner information is not exchanged when in fixed speed mode.
End of basic transceiver information.
rtl8138-diag :--
rtl8139-diag.c:v2.10 9/18/2002 Donald Becker (becker@scyld.com)
http://www.scyld.com/diag/index.html
Index #1: Found a RealTek RTL8139 adapter at 0x9800.
Realtek station address 00:02:44:4b:26:ea, chip type 'rtl8139C'.
Receiver configuration: Normal unicast and hashed multicast
Rx FIFO threshold 2048 bytes, maximum burst 2048 bytes, 32KB ring
Transmitter enabled with NONSTANDARD! settings, maximum burst 1024 bytes.
Flow control: Tx disabled Rx disabled.
The chip configuration is 0x10 0x4d, MII full-duplex mode.
No interrupt sources are pending.
Use '-a' or '-aa' to show device registers,
'-e' to show EEPROM contents, -ee for parsed contents,
or '-m' or '-mm' to show MII management registers.
I am concerned that the mii-tool and mii-diag seem to indicate that nothing is happening on the card.
Does anyone know if these diagnoses are indicative of simple configuration issues, worse than that or basicall irrelevant??
Thanks
Barry
rioguia
12-18-2002, 11:27 AM
barry:
i understand your concerns. what happens when you. when you are on the box with the suspect nic, what happens when you ping its own address?
i.e.
ping 192.168.0.1
beach_defender
12-18-2002, 05:12 PM
Hi again,
This is the result of pinging :-
PING 192.168.0.1 (192.168.0.1) from 192.168.0.1 : 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_seq=1 ttl=255 time=0.055 ms
64 bytes from 192.168.0.1: icmp_seq=2 ttl=255 time=0.024 ms
64 bytes from 192.168.0.1: icmp_seq=3 ttl=255 time=0.028 ms
Thanks again!
:-)
rioguia
12-18-2002, 06:23 PM
that is pretty much how a good card should respond and doesn't sound like it's a part of the hardware issue. have you tried changing out your cables? even better, can you borrow a cross over cable so you can directly plug your linux box into one of your other pc's and see if you can ping it? if mii-tool says there is no link, i've got to suspect either a hardware issue or your other computer's tcp/ip config doesn't match yours perhaps.
i.e.
when you go into your windows machine, right click on network neighborhood, select the tcp/ip tab. make sure that the output (ip respective addresses for the respective boxes are for the same network --e.g. 10.1.1.1 and 10.1.1.2 comparing the neighborhood tab to the output of ifconfig eth0)) and netmask are exactly like the output of ifconfig eth0
beach_defender
12-18-2002, 07:22 PM
Hi,
I've hooked up a crossover cable and get :--
[root@hpfm01 root]# ping 192.168.0.127
PING 192.168.0.127 (192.168.0.127) from 192.168.0.1 : 56(84) bytes of data.
From 192.168.0.1 icmp_seq=1 Destination Host Unreachable
From 192.168.0.1 icmp_seq=2 Destination Host Unreachable
From 192.168.0.1 icmp_seq=3 Destination Host Unreachable
--- 192.168.0.127 ping statistics ---
4 packets transmitted, 0 received, +3 errors, 100% loss, time 2999ms
, pipe 3
[root@hpfm01 root]# mii-tool
eth0: 10 Mbit, half duplex, no link
eth1: no autonegotiation, 10baseT-HD, link ok
The laptops set up looks like -
IP Address 192.168.0.127
Netmask 255.255.255.0
Gateway 192.168.0.1
Thanks still
rioguia
12-18-2002, 08:00 PM
i'm at a loss. i'm betting we are missing something really basic here. what happens when eth0 192.168.0.1 pings the other card (eth1 192.168.0.9) or laptop 192.168.0.127? i'll check back after i get home.
beach_defender
12-18-2002, 08:12 PM
Mate,
I'm really sorry about all this and I agree there is some REALLY simple step missing, but I'll probably take up serious drinking before we find it !!
Below is the result from pinging the various addresses from 192.168.0.1
[root@hpfm01 root]# ping 192.168.0.9
PING 192.168.0.9 (192.168.0.9) from 192.168.0.9 : 56(84) bytes of data.
64 bytes from 192.168.0.9: icmp_seq=1 ttl=255 time=0.059 ms
64 bytes from 192.168.0.9: icmp_seq=2 ttl=255 time=0.033 ms
64 bytes from 192.168.0.9: icmp_seq=3 ttl=255 time=0.033 ms
--- 192.168.0.9 ping statistics ---
3 packets transmitted, 3 received, 0% loss, time 2013ms
rtt min/avg/max/mdev = 0.033/0.041/0.059/0.014 ms
[root@hpfm01 root]# ping 192.168.0.127
PING 192.168.0.127 (192.168.0.127) from 192.168.0.1 : 56(84) bytes of data.
From 192.168.0.1 icmp_seq=1 Destination Host Unreachable
From 192.168.0.1 icmp_seq=2 Destination Host Unreachable
From 192.168.0.1 icmp_seq=3 Destination Host Unreachable
The interesting thing is that I don't even have eth1 (192.168.0.9) linked through a cable to the switch at present.
But I'll try that.
Barry
PS I really appreciate this - what do you do when not helping numbnuts like me?
rioguia
12-19-2002, 05:09 PM
sorry i took so long to get back to you. i checked back several times and didn't notice that the thread had run over to the second page so i missed your post until now.
ok, on the linux box with the two nics, you can ping the nics and eth0 and eth1 both respond. when you are pinging a nic on your own machine, its kind of like pinging the local host (127.0.0.1). no network traffic is actually generated (linux is efficent like that). its just a way to check the configuration of the nic.
hey, that reminds of of another angle we have not considered.
can you sit on the linux box with two nics, and ping 127.0.0.1 -c 3
and
ping localhost
if either of these have problems,
cat /etc/host.conf (For example, if your machine is bother.statsis.com with the IP address 123.123.123.123, your /etc/hosts would look like:
127.0.0.1 localhost (i think something like localdomain is ok here)
123.123.123.123 bother.stasis.com bother
cat /etc/resolve.conf (check the path and file names but they should be something like that; i'm not on a linux box just now).
/etc/networks
The /etc/networks file lists the names and addresses of your own, and other, networks. It is used by the route command, and allows you to specify a network by
name, should you so desire.
Every do the entries in your route matchere an entry in /etc/networks?
As an example,
default 0.0.0.0 # default route - mandatory
loopnet 127.0.0.0 # loopback network - mandatory
mynet 123.123.123.0 # Modify for your own network address
/etc/host.conf (It should contain the two lines:
order hosts,bind
multi on)
/etc/resolv.conf (should look like domain coco.com but i think localhost or local domain is ok)
nameserver 127.253.154.5
what do i do? i'm an attorney industry by day and a husband and father of two children under age two by night.
beach_defender
12-20-2002, 02:43 AM
Hi,
Here are the results:-
[barry@hpfm01 barry]$ ping 127.0.0.1 -c 3
PING 127.0.0.1 (127.0.0.1) from 127.0.0.1 : 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=255 time=0.057 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=255 time=0.029 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=255 time=0.027 ms
--- 127.0.0.1 ping statistics ---
3 packets transmitted, 3 received, 0% loss, time 1998ms
rtt min/avg/max/mdev = 0.027/0.037/0.057/0.015 ms
[barry@hpfm01 barry]$
[barry@hpfm01 barry]$ ping localhost
PING localhost (127.0.0.1) from 127.0.0.1 : 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=255 time=0.031 ms
64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=255 time=0.040 ms
64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=255 time=0.032 ms
AND[barry@hpfm01 barry]$ cat /etc/resolve.conf
cat: /etc/resolve.conf: No such file or directory
[barry@hpfm01 barry]$ du -
du: `-': No such file or directory
[barry@hpfm01 barry]$ su -
Password:
[root@hpfm01 root]# cat /etc/resolve.conf
cat: /etc/resolve.conf: No such file or directory
[root@hpfm01 root]#
[root@hpfm01 root]#
[root@hpfm01 root]# cat /etc/networks
cat: /etc/networks: No such file or directory
[root@hpfm01 root]#
I get more intrigued by this day-by-day. I have not had any chance to look at this today - I've had a few real jobs to do.
Have a merry christmas.
Barry
rioguia
12-20-2002, 11:10 AM
OK. You are right. something is fundimentally wrong if those files aren't present. let's get back to basics.
I was just reviewing the basics here. It's probably time to try a new card. If not, let's try to eliminate hardware configuration.
1. check your bios to make sure that plug and play is disabled.
2. dmesg | grep eth0 (lets see what how the kernel is detecting your cards; please post this back here)
and
2. dmesg | grep eth1 (lets see what how the kernel is detecting your cards; pleasepost this back here)
3. lspci | grep Ethernet (post this back here)
4. lsmod (check to make sure the correct modules are loaded for your cards)
5. cat /proc/interrupts (lets your see the hardware interrupt requests for your devices; under pci, sharing resources is not necessarily a bad thing but sometimes some hardware just don't like sharing; it has something to do with the magic of latency, etc; insert techno bable here))
6. cat /proc/ioports (lets your see the hardware i/o allocations for your devices)
7. mii-tool -v (lets see what issues are hidden here)
6. configure your eth0 nic by typing
netconfig
7. try pinging again.
another good thing to consider. if those files are really not there, we could try to provide them and see if it makes a difference. a good place to look for a step by step approach to networking is at
http://www.gui.uva.es/linux/LDP/nag/node65.html
beach_defender
12-23-2002, 06:54 PM
Hi again,
I've been busy for the last few days trying to ensure the continued supply of food for the family.
Below is the result of the commands you mentioned. I'll do the netconfig etc and get back to you.
[root@hpfm01 etc]# dmesg | grep eth0
eth0: RealTek RTL8139 Fast Ethernet at 0xde8ec000, 00:02:44:4b:26:ea, IRQ 3
eth0: Identified 8139 chip type 'RTL-8139C'
eth0: Setting half-duplex based on auto-negotiated partner ability 0000.
eth0: Promiscuous mode enabled.
device eth0 entered promiscuous mode
[root@hpfm01 etc]# dmesg | grep eth1
eth1: ICS LAN PHY transceiver found at address 1.
eth1: Using transceiver found at address 1 as default
eth1: SiS 900 PCI Fast Ethernet at 0xa000, IRQ 9, 00:e0:18:8a:98:92.
eth1: Media Link On 100mbps full-duplex
[root@hpfm01 etc]# lspci | grep Ethernet
00:03.0 Ethernet controller: Silicon Integrated Systems [SiS] SiS900 10/100 Ethernet (rev 90)
00:0f.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C (rev 10)
This is one of the more puzzling things I've ever had to do. In years (10 of them) I worked on Sun, HP, DEC and IBM unix boxes and really don't remember anything like this.
THanks again, I hope you have a wonderful holiday season,
And lastly :
eth0: 10 Mbit, half duplex, no link
product info: vendor 00:00:00, model 0 rev 0
basic mode: 10 Mbit, half duplex
basic status: no link
capabilities:
advertising:
eth1: negotiated 100baseTx-FD, link ok
product info: vendor 00:05:7d, model 4 rev 1
basic mode: autonegotiation enabled
basic status: autonegotiation complete, link ok
capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
[root@hpfm01 root]#
Would the USB interrupt clash cause this?
Barry
rioguia
12-27-2002, 05:38 PM
i'm really stumped.
did we ever talk about replacing the 8319.too with the 8139.c driver?
ftp://ftp.scyld.com/pub/network/rtl8139.c
for a discussion of the problems with this driver
http://www.scyld.com/network/rtl8139.html
regarding possible resource conflicts, PCI is supposed to be able to handle resource sharing (unlike the bad old days of industry standard architecture). it could be just a bad card.
regarding the possibility of bad hardware, i guess i would take out both cards and test them in another box, then put one of them into a different pci slot in your linux box and keep testing with the diagnostic software you referenced in this thread (for a very low level test, use the '-e' argument to show EEPROM contents). if i get a good, EEPROM result, i would try to get a ping across your cross-over cable or decide that the card is bad and try a new one. sorry, i really hate giving up but i've run out of ideas
justlinux.com
Copyright Internet.com Inc. All Rights Reserved.