Should I see port 67 listening when dnsmasq is running? I ran nmap with this result:

Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2007-06-03 08:50 PDT
Interesting ports on fileserv.yerke.local (127.0.0.1):
Not shown: 1666 closed ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 4.4 (protocol 1.99)
25/tcp open smtp Sendmail 8.13.8/8.13.8
37/tcp open time (32 bits)
53/tcp open domain ISC Bind dnsmasq-2.33
80/tcp open http Apache httpd 2.2.4 ((Unix) mod_ssl/2.2.4 OpenSSL/0.9.8d DAV/2 PHP/5.2.2)
111/tcp open rpcbind 2 (rpc #100000)
113/tcp open ident OpenBSD identd
139/tcp open netbios-ssn Samba smbd 3.X (workgroup: MSHOME)
445/tcp open netbios-ssn Samba smbd 3.X (workgroup: MSHOME)
587/tcp open smtp Sendmail 8.13.8/8.13.8
631/tcp open ipp CUPS 1.1
752/tcp open status 1 (rpc #100024)
5432/tcp open postgresql PostgreSQL DB
6881/tcp open tcpwrapped
Service Info: OSs: Unix, OpenBSD

as you can see, dnsmasq is listening on 53 for DNS requests, but not on 67 for DHCP. I have uncommented and edited the dhcp-range option in the config file. If I try to use dhcp to assign addresses, there is no reply. Wireshark indicates that requests are getting into the machine through the firewall.

I am using Slackware 11.0 with dnsmasq 3.5 package from LinuxPackages.
I tuned off bind so that dnsmasq would have port 53 open to start.

I hope this is enough info.

Thanks,
Bert

No of course not.

Please post your dnsmasq configuration at a minimum, plus the reason why you installed a package from linuxpackages.net while there is already a dnsmasq package available in Slackware.

Eric

I did not expect to need to include the config file since, as I mentioned, the only change that I made was to uncomment and edit the dhcp-range option.

Nevertheless, here it is (comments removed):

domain-needed
bogus-priv
dhcp-range=192.168.0.50,192.168.0.150,255.255.255.0,12h


The only reason that I used the LinuxPackages upgrade was because I could not get the native version working (same issue) and I thought that something may have been fixed, some conflict or something. I have had luck in the past using Ken Z's HPLIP, for example, to get my Photosmart working over the network - something that you cannot do with the native package, as it does not include support for snmp...I know, it was a shot in the dark.

Thank you for the reply,
Bert

You configured dnsmsaq to hand out IP addresses in the range 192.168.0.0/255.255.255.0 . I assume that corresponds to the IP address range of your local subnet?
The nmap scan you ran, was targeted at the localhost address (127.0.0.1) from what I can see in your posted output. Since the "lo" interface does not belong to the 192.168.0.0/255.255.255.0 address range, dnsmasq will not bother listening for DHCP requests on that interface.
Try running nmap on your server's external interface (which should be 192.168.0.XXX) and see if there is a dnsmasq process listening at port 67 there.

Eric

I get the same result. As I understand, dnsmasq should listen on all adapters unless configured to listen on a specific one (or not to.)

I suspect some failure in the process itself, but I can't seem to find out what is inhibiting dhcp. Google has only provided cases where the firewall or configuration issues have been the problem, yet I can't find any case where there is no daemon listening on 67, except my own.

Is there a place that I could look for debugging? Some log file that I could look at? I am still new to Slackware and Linux, so some of the standard practices still escape me.

A side note:
In the process of trying to get this thing working, I removed the 2.35 version and returned to the 2.33 that is native to Slackware 11.0. From my limited experience I have found that as long as all of the files are in the right place, it should work as before.

Thanks again,
Bert

I'd advise to look in the log files. Like /var/log/messages .

Eric

/var/log/messages had this to say after restarting dnsmasq:


Jun 3 14:52:58 fileserv dnsmasq[1858]: exiting on receipt of SIGTERM
Jun 3 14:52:59 fileserv dnsmasq[26148]: started, version 2.33 cachesize 150
Jun 3 14:52:59 fileserv dnsmasq[26148]: compile time options: IPv6 GNU-getopt no-ISC-leasefile no-DBus I18N
Jun 3 14:52:59 fileserv dnsmasq[26148]: DHCP, IP range 192.168.0.50 -- 192.168.0.150, lease time 12h
Jun 3 14:52:59 fileserv dnsmasq[26148]: reading /etc/resolv.conf
Jun 3 14:52:59 fileserv dnsmasq[26148]: using nameserver 192.168.0.1#53
Jun 3 14:52:59 fileserv dnsmasq[26148]: read /etc/hosts - 3 addresses

Is it possible that it does not need to listen on 67? I'm not sure what to think about the compile time options. This is how the package is compiled out of the box and others seem to be using it without recompiling.

On my box, the command
reveals this:
It is listening, but for UDP ports only.
You could also try a UDP Scan with nmap:
Result:
Eric

Okay, I have the same results as you do. Now I know that the thing is doing, evidently, what it is supposed to.

Now I just need to find out why I can't get the Win boxes to get a reply. Wireshark is showing the request, but not the reply. Is it possible that the firewall is letting the packets in but not out? I would post the contents of rc.firewall except that it is very large.

I'll look at it to see if maybe it is the culprit.

Thanks so much,
Bert