Hi,
I've been debugging a problem that we've had here with LTSP (diskless kiosks PXE booting, NFS mounting), and I've tracked down the problem to be unexpected behaviour (well *I* didn't expect it) in RHAS 3 (I imagine it's the same with other linux), kernel-2.4.21-20.EL .
Simply put, the LTSP kiosks would sometimes hang with a TFTP timeout immediately after getting their DHCP configuration, and sometimes they'd get further along then hang when trying to NFS mount. I spent a while attempting to debug TFTP and NFS before finally putting a sniffer on the wire and tracing the problem to another machine entirely.
The LTSP server is on 10.0.0.1 (yes, stupid choice - I've learnt my lesson) and I found that the clients when ARP-querying the network would also get another reply for 10.0.0.1. Arpwatch is running on the network, and didn't spot any duplicate IP addresses. The rogue 10.0.0.1 address was traced to another server with two interfaces - eth0 on the LAN with an address in our network range, and eth1 with 10.0.0.1 which was connected directly to another machine by crossover cable - neither of these two machines were routing between these networks.
eth0 on this machine was responding to ARP requests for 10.0.0.1 with the MAC address of eth1. My LTSP clients were then attempting to TFTP or NFS to that MAC address, and hanging (since it wasn't on the LAN). Is this expected behaviour? Shouldn't interfaces keep schtum about each other for fear of leaking information across networks? I've tried to google, and I've searched the kernel docs, but I can't find anything that would answer the question: is this right?
One lesson I've learnt is that you don't use the obvious ranges when assigning private IP addresses.
-- Illtud Daniel illtud.daniel@xxxxxxxxxxx Uwch Ddadansoddwr Systemau Senior Systems Analyst Llyfrgell Genedlaethol Cymru National Library of Wales Yn siarad drosof fy hun, nid LlGC - Speaking personally, not for NLW
- : send the line "unsubscribe linux-net" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
