Re: [Dnsmasq-discuss] dnsmasq failing to compile
On Saturday 02 December 2006 21:56, Philip Wall wrote: Getting this during compile of a fresh dnsmasq 2.35 Kernel 2.6.19 They changed a bunch of things in this kernel. Slamd64 11 (slackware 64bit version) gcc 3.4.6 Previous versions had no problem building $ time make -j5 make I18N=-DNO_GETTEXT -f ../bld/Makefile -C src dnsmasq make[1]: Entering directory `/home/common/src/dnsmasq-2.35/src' cc -O2 -DNO_GETTEXT `echo | ../bld/pkg-wrapper pkg-config --cflags dbus-1` -Wall -W -c cache.c cc -O2 -DNO_GETTEXT `echo | ../bld/pkg-wrapper pkg-config --cflags dbus-1` -Wall -W -c rfc1035.c cc -O2 -DNO_GETTEXT `echo | ../bld/pkg-wrapper pkg-config --cflags dbus-1` -Wall -W -c util.c cc -O2 -DNO_GETTEXT `echo | ../bld/pkg-wrapper pkg-config --cflags dbus-1` -Wall -W -c option.c cc -O2 -DNO_GETTEXT `echo | ../bld/pkg-wrapper pkg-config --cflags dbus-1` -Wall -W -c forward.c cc -O2 -DNO_GETTEXT `echo | ../bld/pkg-wrapper pkg-config --cflags dbus-1` -Wall -W -c isc.c cc -O2 -DNO_GETTEXT `echo | ../bld/pkg-wrapper pkg-config --cflags dbus-1` -Wall -W -c network.c cc -O2 -DNO_GETTEXT `echo | ../bld/pkg-wrapper pkg-config --cflags dbus-1` -Wall -W -c dnsmasq.c cc -O2 -DNO_GETTEXT `echo | ../bld/pkg-wrapper pkg-config --cflags dbus-1` -Wall -W -c dhcp.c cc -O2 -DNO_GETTEXT `echo | ../bld/pkg-wrapper pkg-config --cflags dbus-1` -Wall -W -c lease.c cc -O2 -DNO_GETTEXT `echo | ../bld/pkg-wrapper pkg-config --cflags dbus-1` -Wall -W -c rfc2131.c cc -O2 -DNO_GETTEXT `echo | ../bld/pkg-wrapper pkg-config --cflags dbus-1` -Wall -W -c netlink.c cc -O2 -DNO_GETTEXT `echo | ../bld/pkg-wrapper pkg-config --cflags dbus-1` -Wall -W -c dbus.c cc -O2 -DNO_GETTEXT `echo | ../bld/pkg-wrapper pkg-config --cflags dbus-1` -Wall -W -c bpf.c cc -O2 -DNO_GETTEXT `echo | ../bld/pkg-wrapper pkg-config --cflags dbus-1` -Wall -W -c helper.c cc -o dnsmasq cache.o rfc1035.o util.o option.o forward.o isc.o network.o dnsmasq.o dhcp.o lease.o rfc2131.o netlink.o dbus.o bpf.o helper.o `echo | ../bld/pkg-wrapper pkg-config --libs dbus-1` make[1]: Leaving directory `/home/common/src/dnsmasq-2.35/src' real0m3.050s user0m4.116s sys 0m0.476s $ cat /etc/slackware-version ; gcc --version Slackware 10.2.1 (x86_64) gcc (GCC) 3.4.6 ... Perhaps you're missing some requisite library? But anyway, dnsmasq is provided in both Slackware and Slamd64: $ locate dnsmasq | grep '\.tgz$' /home/common/slamd64-10.2b/slackware/n/dnsmasq-2.24-x86_64-1.tgz /home/common/slamd64-11.0/slackware/n/dnsmasq-2.33-x86_64-1.tgz /home/common/slackware-10.1/slackware/n/dnsmasq-2.20-i486-1.tgz /home/common/slackware-10.2/slackware/n/dnsmasq-2.23-i486-1.tgz /home/common/slackware-11.0/slackware/n/dnsmasq-2.33-i486-1.tgz ... so you could: 1. installpkg it 2. Edit and run Fred's dnsmasq.SlackBuild cc -O2 -DNO_GETTEXT `echo | ../bld/pkg-wrapper pkg-config --cflags dbus-1` -Wall -W -c netlink.c netlink.c: In function `iface_enumerate': netlink.c:159: warning: implicit declaration of function `IFA_RTA' netlink.c:159: warning: initialization makes pointer from integer without a cast netlink.c:160: error: dereferencing pointer to incomplete type netlink.c:162: error: dereferencing pointer to incomplete type netlink.c:166: error: dereferencing pointer to incomplete type netlink.c:172: error: `IFA_LOCAL' undeclared (first use in this function) netlink.c:172: error: (Each undeclared identifier is reported only once netlink.c:172: error: for each function it appears in.) netlink.c:174: error: `IFA_BROADCAST' undeclared (first use in this function) netlink.c:181: error: dereferencing pointer to incomplete type netlink.c:185: error: dereferencing pointer to incomplete type netlink.c:190: error: `IFA_ADDRESS' undeclared (first use in this function) netlink.c:197: error: dereferencing pointer to incomplete type netlink.c:197: error: dereferencing pointer to incomplete type make[1]: *** [netlink.o] Error 1 make[1]: Leaving directory `/www/src/dnsmasq-2.35/src' make: *** [dnsmasq] Error 2 I'm running on a 2.6.18.2 kernel with /usr/src/linux pointing to linux-2.6.15.5 sources. So yes, maybe the 2.6.19 kernel is your problem. Although I have it on good authority that 2.6.19 is perfect, and any problems with it are your own %*^$*! fault. Linus said so. :) -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
RE: [Dnsmasq-discuss] Problem when WinXP firewall is activated (d oes not reply to ping)
As I understand it, the client should try an arping before using the address it has been given by the server. The interesting question is whether WinXP actually implements this arping. If Windows follows the specification on this, there should be no point in the server using arping. I'm going to check if WinXP does the arping check. DHCP client computers running Windows 2000 or Windows XP that obtain an IP address use a gratuitous ARP request to perform client-based conflict detection before completing configuration and use of a server offered IP address. If the DHCP client detects a conflict, it will send a DHCP decline message (DHCPDECLINE) to the server. So it seems that Windows XP does an ARP check before using an IP address. I'll check that with Wireshark on Monday. But the other problem with a SOHO including a DHCP server is that a SOHO is often rebooted (because the user changed settings which require a reboot, because of a power failure,...). So each time it reboots, the lease file is cleared. Which is a bug in the SOHO. Assuming by SOHO you mean WRT-54G-class stuff, then you might like to consider moving to DD-WRT. I worked with them to add hooks into dnsmasq so that the lease file can be stored in the non-volatile RAM and not trashed on a reboot. You might also like to consider asking the developers of your current firmware to implement the same thing. Could you give me pointers on how to do that? Is it always safe to reload an old lease file on reboot? I have the issue only in this case: the SOHO reboots, the WinXP PC (firewall enabled) has 192.168.1.20, the Linux PC also has 192.168.1.20, and in the lease file of dnsmasq, 192.168.1.20 corresponds to the MAC address of the WinXP PC. That does look like WinXP might be broken: I'd be interested in the results of your tests. Again, I'll have to check with Wireshark on Monday. Why do you think it's WinXP the problem? --Raphael
Re: [Dnsmasq-discuss] Problem when WinXP firewall is activated (d oes not reply to ping)
Raphaël Huck wrote: As I understand it, the client should try an arping before using the address it has been given by the server. The interesting question is whether WinXP actually implements this arping. If Windows follows the specification on this, there should be no point in the server using arping. I'm going to check if WinXP does the arping check. DHCP client computers running Windows 2000 or Windows XP that obtain an IP address use a gratuitous ARP request to perform client-based conflict detection before completing configuration and use of a server offered IP address. If the DHCP client detects a conflict, it will send a DHCP decline message (DHCPDECLINE) to the server. So it seems that Windows XP does an ARP check before using an IP address. I'll check that with Wireshark on Monday. But the other problem with a SOHO including a DHCP server is that a SOHO is often rebooted (because the user changed settings which require a reboot, because of a power failure,...). So each time it reboots, the lease file is cleared. Which is a bug in the SOHO. Assuming by SOHO you mean WRT-54G-class stuff, then you might like to consider moving to DD-WRT. I worked with them to add hooks into dnsmasq so that the lease file can be stored in the non-volatile RAM and not trashed on a reboot. You might also like to consider asking the developers of your current firmware to implement the same thing. Could you give me pointers on how to do that? Set the (rather misnamed) --leasefile-ro flag. That actually stops dnsmasq from using a lease file at all. Instead it relies a script which gets run at start-up and whenever a lease changes, to maintain the lease database. Dnsmasq needs to be pointed at this script using the --dhcp-script option. Using this mechanism, it is possible to store the lease database in any storage system (a SQL database, for instance). The dnsmasq distribution has a sample script (in contrib/wrt/lease_update.sh) which uses the nvram command to keep the lease database in the router's non-voltile memory. This is exactly what you need. Is it always safe to reload an old lease file on reboot? Yes. On a system which doesn't maintain system time over a reboot, dnsmasq needs to be compiled with HAVE_BROKEN_RTC set to cope with its idea of time changing over a reboot. This likely to be the case on a WRT-class router. I have the issue only in this case: the SOHO reboots, the WinXP PC (firewall enabled) has 192.168.1.20, the Linux PC also has 192.168.1.20, and in the lease file of dnsmasq, 192.168.1.20 corresponds to the MAC address of the WinXP PC. That does look like WinXP might be broken: I'd be interested in the results of your tests. Again, I'll have to check with Wireshark on Monday. Why do you think it's WinXP the problem? As far as I can see, the only order of events which could get to the situation you see is: Linux box has lease on 192.168.1.20 router reboots (and clears leasefile) Windows box takes a lease and gets 192.168.1.20 If the ARP check had worked during the windows box lease-aquisition, it would have seen the Linux box on 192.168.1.20, and taken an alternative address. Cheers, Simon.
Re: [Dnsmasq-discuss] Any plans on adding ability to store cachetodisk?
gypsy wrote: If Simon is offended, then so be it, but I mean no offense. I just fail to see how a save to/restore from disk could bloat the code; save/restore IS a basic feature. TTL will expire out any crap naturally. -- gypsy I'm not at all offended. In my role as dnsmasq-benevolent-dictator I get to have opinions about what's good to do in dnsmasq and what's not. I also get to hear arguments about what's good to do in dnsmasq and what's not, and sometimes I even change my mind (I did about the DHCP lease-change script, for instance, and forcing an address change when an already-configured host gets a static DHCP address). I guess if a I make too many bad calls, there's nothing to stop a fork: that's the Free Software way. I just happen not to have changed my mind about this. I'm still happy to hear arguments about it. Cheers, Simon.
