Eric Cooper wrote: >> The current development version of dnsmasq adds an option which >> tells dnsmasq to assume a named secondary interface instead, which >> should fix this. Are you in a position to build from source and test >> this? > > I built dnsmasq-2.53test22 in a lenny chroot and tried it. > I assume you mean the new interface prefix to DHCP ranges? > (There are a couple typos in the section of the man page > describing that feature: s/inteface/interface/, s/them/then/)
ACK the typos, thanks. That's not the facility you need to use. > > I had been using "bind-interfaces", which (silently) conflicts with > this option. Apparently it will only work with wildcard-bound > sockets? > > Also, my goal in using the aliased interface in the first place was so > that the DHCP replies would contain that address for the router and > dns-server options, but it doesn't (unless I override them). Dnsmasq > is still using the address of the primary (eth0) interface for both > these fields, and for the server-identifier field. > you need is to add bridge-interface=eth0:ucarp, eth0 to /etc/dnsmasq.conf. Which should treat any DHCP packets arriving on the eth0/eth0:ucarp physical interface as arriving at eth0:ucarp. >I don't understand this. Why wouldn't I at least have seen the DHCP >requests received by dnsmasq in the debug output? They're thrown away because they're presumed to be addresses to the address of eth0, and your listen-address configuration is deleting them. > And why does the DNS server portion work (as in, receive and reply to > packets on that secondary address) but not the DHCP server? The DNS packets have destination address, so the kernel is capable of assinging them to an interface, the DHCP packets don't, since the client is broadcasting and doesn't know its IP address. Cheers, Simon. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
