On Tue, Jun 27, 2006 at 12:56:38AM +0200, Natanael Copa wrote: > On Mon, 2006-06-26 at 16:16 -0500, [EMAIL PROTECTED] wrote: > > > > The GNAP box doesn't issue a response, apparently because it can't see > > that the request is coming from one of its listed DHCP clients. > > Have you tried running dhcpd on the GNAP box?
I tried building ISC dhcpd for GNAP, but it required a huge raft of dependencies, some of which were failing to compile, so I gave up. I could try again, I suppose, but read on... > > So, does anybody know what might be going on here? I don't think that > > dnsmasq is (necessarily) the culprit, since tcpdump shows more > > information in the case of the packets dumped on the RedHat machine. > > To me it looks like its dnsmasq. The request packet arrives to your GNAP > box but dnsmasq is never responding. Right, but how would dnsmasq know that it should respond? Compare this packet dump on our old machine: 14:42:27.985373 msfc-ri-v17.uchicago.edu.bootps > bonzai.uchicago.edu.bootps: (request) hops:1 xid:0x20dcf2e1 secs:4 flags:0x8000 G:msfc-ri-v17.uchicago.edu ether 0:f:1f:dc:f2:e1 [|bootp] ...to this one on the GNAP box: 01:06:27.601181 IP msfc-ri-v17.uchicago.edu.bootps > bonzai.uchicago.edu.bootps: BOOTP/DHCP, Request [|bootp] Those packets come from the same client, but in the former case, there's a lot more information in the packet dump, including the MAC address of the originating client. If tcpdump sees the two packets differently, then either tcpdump isn't as smart on GNAP (possible), or information isn't being preserved as the packet makes its way up the stack, in which case dnsmasq is never going to see the MAC information it needs to match to the client's address. (Right?) > Try this one: > http://thekelleys.org.uk/dnsmasq/docs/FAQ > > Look for this part: > Q: This new DHCP server is well and good, but it doesn't work for me. > What's the problem? I've got a good broadcast address, and I can serve DHCP to clients on the local LAN segment. The GNAP machine doesn't currently have any firewalling in place. -mrj -- [email protected] mailing list
