Alright, I've got a pair of NICs running in an old P133 with the 2.4.22 kernel installed (did a Gentoo Stage 3 install for x86)

One of these cards uses via-rhine (a DFE-530TX), the other the 8139cp driver (unknown card).

lspci shows everything to be normal with these cards, as does isconfig. When either card is plugged into an active network, ifconfig will show the cards as receiving packets (RX type, typically not TX).

I've been having problems getting dhcp responses on either card on an active network. To do testing, I've plugged another working test box with dhcpd active onto a switch with the problem box. Those are the only two live connections on the network. When I try to run dhcpcd on the problem box, the request still times out. The dhcpd server on the other box nevers shows any information about a client asking for a lease.

What tools can I use to try seeing if these cards can actually do a proper send beyond dhcp? Is there some type of setting on ping that will let me simply send ping requests down a device, not to an IP?

What sort of misconfigurations would cause this behaviour? Drivers for both cards are compiled into the kernel, not as loadable modules, and like I said previously, ifconfig and lspci never make any complaints.

Thanks for any help or pointers

For tracking IP packets, I'd suggest Ethereal or tcpdump. (Tcpdump is command line (I think -- I haven't used it myself), so it will probably be a lot smaller to install. (I'm assuming getting packages onto a machine with flaky is going to be medium hard.)

I just thought of one major downside to Ethereal. It's an X application, and the thought of compiling X, a window manager and an application, getting them all onto the machine through unreliable network cards is NOT my idea of fun.

If you want to just verify that packets are getting sent back and forth, you can use ipchains/iptables and lots of logging. Won't tell you the contents, but it will tell you what IP address and port it came from and what IP & port it's going to.

I use telnet a lot just to check basic functionality. You'll have to mess with xinetd or something like that to get it going. (I'd suggest ssh, but it's considerably more complex. For trying to debug a (possible) network issue, the simpler the better.)

The closest thing I know to your question about sending something to a device would be arping. Kind of like an ARP equivalent to ping.

Actually, I just thought of something. Try turning the firewall off entirely (so that the only rules are blanket ACCEPTs on everything). I've had more weird problems crop up since I started using a software firewall than I've ever had out of ANYthing else.

There is (possibly) a configuration that could cause this. On AIX (IBM's commercial flavor of Unix), an adapter can be UP, DOWN, or DETACHED. DETACHED is all the way down. "DOWN" has only one half the functionality shut off (the transmit side, if I remember right.) I don't know how to do that in Linux (the ifconfig manpage doesn't mention anything like that intermediate status), but it might be possilble. If you didn't go in pretty deep into the guts of Gentoo's networking, don't worry about this one. Their networking stuff is pretty normal.

A couple of questions to make sure I understand the situation right:

What happens when you ping each of the IP addresses from within the box?

Can you ping anything outside the box (the default gateway being the most important one)?

I was rereading your post, and an important question occurred to me: Are both your test box (the DHCP server) and the client box (the problem child) on the same subnet? I figure they probably are (you sound like you know what you're doing for the most part), but since erroneous assumptions are the problem about 60% time, I like to check every one I can think of.

Hope this helps,

CHL

Also - trying DHCP right from the get go is adding variables to the equation. Try assigning all nics on both boxes static ip addresses first.

For looking at ip traffic from a command line, tcpdump does a good job.

Wow, thanks for the informative reply. The first thing I checked was using arping from the flaky box to the stable box. When I did, I got the following:
arping -bDI eth0 134.117.93.100
Unicast reply from 134.117.93.100, [MAC]
Basically, it sent out one probe and claimed to get one back immediately.

Next step was giving the flaky card a static IP, (192.168.1.1)
ifconfig eth0 up 192.168.1.1
ifconfig then reported that the card was up and running with that IP.
Trying to do a reverse arping from the stable machine to the flaky one got me this:
arping -bDI eth0 192.168.1.1
Unicast reply from 192.168.1.1 [MAC]

I should note that in both cases, the MAC addresses matched according to ifconfig. So I've managed to verify that ARP can go both ways across the flaky card (the flaky card I'm testing in this case is a DFE-530TX using via-rhine, I'm leaving the other card be for right now)

My next step will be to try out my dhcpd/dhcpcd connection again and post some output from that. But that'll involve some off-lineness as I reconfigure my network (I doubt the other guys in rez will appreciate a rogue DHCP server messing them up

Alright, that certainly didn't help matters! Here's what I did to try and do my localized DHCP test

Stable box (working as DHCP server):
Unplug switch from university network (leaves stable and flaky boxes plugged in)
> ifconfig eth0 down 0.0.0.0
> ifconfig eth0 up 192.168.1.1
> route add -host 255.255.255.255 dev eth0
> dhcpd -d -f
And the normal startup msg, no leases at the time

Flaky box:
> ifconfig eth0 up 0.0.0.0
> dhcpcd eth0
> #blank command prompt returns after dhcpcd times out
> ifconfig
#now shows only loopback
> arping -bDI eth0 192.168.1.1
> #after using ctr-c
62 packets sent, 0 received
> ifconfig eth0 up 192.168.1.2
> arping -bDI eth0 192.168.1.1
# same as before, had to force it to stop after 50+ packets failed

Stable box again:
> arping -bDI eth0 192.168.1.2
# and again a timeout, after it can't make the connection

And then to make matters worse, I couldn't get the stable box to pick up an IP from the main network after I plugged the switch back in again and tried to use DHCP to pick up my IP again. Fortunately, DHCP seems to be one of the few things in Winblows which isn't flaky so that's where I'm posting from

Any suggestions of things to do from here? Is there something in my hosts, dnsdomainname, resolv.conf or hostname I should be modifying to get this working? I'll post my dhcpd.conf file so you can see what that contains and anything else you ask for, as this is definitely a weird problem.

On the flaky box don't do the 'ifconfig eth0 up 0.0.0.0' before the 'dhcpcd eth0'.

Look in /var/log/messages on the stable DHCP server box. Do you see a request from the flaky box? Alternatively, on the stable box, run dhcpd from the command line:

/usr/sbin/dhcpd -f -d

I was running dhcpd from the command line, in the foreground with debug mode on when I ran it. I'm starting to try and use tcpdump right now to catch and dhcp requests the flaky card is or isn't making. I don't have software firewalls running in either box - I've got the kernel options for that stuff enabled, but I haven't emerged either iptables, ipchains or ipmasquerade (however that gets truncated) for either box so there shouldn't be any rules active.

OK, this problem just keeps getting freakier. After using tcpdump to look at incoming packets,
I found that in fact the flaky box _was_ sending out TCP packets of some sort.
Tragically, I don't know all my RFCs off by heart so I couldn't interpret
what could be wrong :S
I'll post a raw packet or two up here, so anyone familiar with the DHCP
protocol can help me out with why the queries aren't being replied to.

Alright, now things are just starting to get STRANGE
The situation currently is:
I've got a switch connecting the reznet to Boxes A & B
Box A can use dhcp to pick up its IP from the reznet and works fine
Box B can't use dhcp to pick up its IP from the reznet
If I localize the switch, a dhcp daemon running on Box A will server a dhcp request coming from Box B
If I use tcpdump to analyze the packets being sent from one box to the other while using dhcpcd (with the switch localized), they appear to be identical expcept for the XID


So there we have it - one box picks up with dhcp, the other one doesn't. Both have valid hostnames, identical dnsdomainname and resolv.conf files, as well as hosts files that properly id the loopback. On box B I've tried using the -B, -r and -Br flags but that hasn't changed anything

Any ideas, thoughts or suggestions from this point onwards?