Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm trying to fix a very strange problem remotely on a machine at a customer site. The machine is a Dell PowerEdge 1950. The machine's NIC is a dual-port on-board Broadcom NetXtreme II BCM5708 Gigabit Ethernet, using the bnx2 driver.

The primary interface eth0 works perfectly, and is in fact how I am ssh'd in.

However, the secondary interface eth1 is not transmitting. I can see this in ifconfig output, for example, where the TX field is always 0. However, it is receiving, and tcpdump shows ARP requests coming from the ISP's gateway on the other side.

The interface is physically connected to a Siemens BSTU4 modem, configured by the ISP. The link is properly set to 10MBps and full duplex, without negotation, as the ISP requested. A small /30 subnet is configured. For the sake of anonymity, let's say the machine is 3.3.3.2/30, and the ISP's gateway .1. The machine has no firewall settings whatsoever.

Even running something like arping -I eth1 3.3.3.1, and running tcpdump alongside, shows no traffic whatsoever being transmitted on the interface. (But the other side keeps steadily sending ARP requests, and that is all that can be seen.)

What could be causing this?


Here's some output, anonymized, which may hopefully help:

$ ethtool eth1
Settings for eth1:
    Supported ports: [ TP ]
    Supported link modes:   10baseT/Half 10baseT/Full 
                            100baseT/Half 100baseT/Full 
                            1000baseT/Full 
    Supports auto-negotiation: Yes
    Advertised link modes:  Not reported
    Advertised auto-negotiation: No
    Speed: 10Mb/s
    Duplex: Full
    Port: Twisted Pair
    PHYAD: 1
    Transceiver: internal
    Auto-negotiation: off
    Supports Wake-on: d
    Wake-on: d
    Link detected: yes

$ ip link show eth1
3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:15:c5:xx:xx:xx brd ff:ff:ff:ff:ff:ff

$ ip -4 addr show eth1
3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
    inet 3.3.3.2/30 brd 3.3.3.3 scope global eth1

$ ip -4 route show match 3.3.3.0/30
3.3.3.0/30 dev eth1  proto kernel  scope link  src 3.3.3.2
default via 10.0.0.5 dev eth0 
share|improve this question
1  
A trick to know the Dell model is to: dmidecode|less And look for PowerEdge XXXX. –  Kyle Smith May 26 '10 at 9:57
    
Thanks, good tip. Confirmed it's a PowerEdge 1950 then. :) –  Shtééf May 26 '10 at 10:25
    
The MTU could be too large for the modem, causing all traffic to be dropped. –  kmarsh May 26 '10 at 12:05
    
I don't believe this is true. The MTU is the standard 1500. What I've seen from MTU problems, small packets like ARP and ICMP would still make it through. And even if they wouldn't, the TX counter is not increasing. –  Shtééf May 26 '10 at 12:31
add comment

3 Answers

up vote 3 down vote accepted

First thing to check: Possible hardware problem. Are you using a known good cable? Check that again.

Do you get anything out of the RG45 when you plug it into a LAN tester? O-scope on the TX leads?

If there's a HW fault, you'll spend a lot of time looking for SW configuration issues and not find anything.

share|improve this answer
    
This is why I hate being remote. We got ourselves to blame for that I guess. I'm working with the folks on site to isolate any hardware problems. The reason I decided to post here as well, is because of the signals I'm getting from software that would indicate software is somehow to blame. (e.g. TX not incrementing.) I was hoping it's simply a software oversight that someone might recognize. –  Shtééf May 26 '10 at 12:58
    
I was hoping for a more exciting outcome, but it was firmware issue after all. An on-site technician ran some Dell firmware updates and the problem went away. Still good to know that those RX/TX counters are not all kept in the OS. Thanks for the pointers. :) –  Shtééf May 27 '10 at 14:22
    
@Shtééf: Glad you found and fixed the issue. –  mpez0 May 28 '10 at 13:14
add comment

Since you disabled auto negotiation and wouldn't have auto Auto-MDIX as a result, you may need to use a crossover cable as result. However, I would think that the transmit would still go up in this case.

share|improve this answer
    
Well, as I'm remote, I can't easily try this. But I did some research, and the Siemens BSTU4 does have auto MDI-X. I would also not expect to see link in software if that were the case. –  Shtééf May 26 '10 at 12:24
    
I wouldn't expect the Link either, but I am not sure. But I believe it doesn't matter if it has MDI-X or not, because if you disable auto negotiation I think that disables MDI-X as well. –  Kyle Brandt May 26 '10 at 12:28
add comment

Did you try a "traceroute -i eth1 www.google.com"? Maybe there is a routing problem.

share|improve this answer
    
Well, I cannot ping my gateway 3.3.3.1 from the machine itself. And from another machine on the public internet, a traceroute to 3.3.3.2 stops at (the other interface of) 3.3.3.1. So routes on the internet appear to be correct. –  Shtééf May 26 '10 at 10:20
    
There is NetFilter/IpTables or other packet filtering system? What do you find in the machine logs? –  lg. May 26 '10 at 10:32
    
SELinux or similar? –  lg. May 26 '10 at 10:45
    
All netfilter tables are empty, policy is ACCEPT. As for SELinux, /etc/selinux/config says SELINUX=disabled. (But I have no knowledge of SELinux, so if that is not sufficient, please tell.) –  Shtééf May 26 '10 at 12:08
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.