No reply to DHCP DISCOVER

cmac has asked for the wisdom of the Perl Monks concerning the following question:

I'm trying to send a DHCP DISCOVER message in accordance with the WPAD procedure given in Wikipedia and an old IETF draft. Following hints in the POD for Net::DHCP::Packet I have the following code:

use IO::Select;
use IO::Socket::INET;
use Net::DHCP::Constants;
use Net::DHCP::Packet;

my $socket = IO::Socket::INET->new(Proto => 'udp',
                                   Broadcast => 1,
                                   PeerPort  => '67',
                                   LocalPort => '4111',
                                   PeerAddr  => '255.255.255.255')
  or die ($@);

# create and send DHCP Packet
my $disc = Net::DHCP::Packet->new(
              xid => int(rand(0xFFFFFFFF)),
              Flags => 0x8000, # ask for broadcast answer
              DHO_DHCP_MESSAGE_TYPE() => DHCPDISCOVER())
    or die "Can't create DHCP discover packet: $!";

$socket->send($disc->serialize())
    or die "Can't send DHCP discover packet: $!";

my @ready = IO::Select->new($socket)->can_read(5);
if (@ready) {
  my $newmsg;
  $socket->recv($newmsg, 1024)
      or die "Can't recv DHCP discover packet: $!";
  my $packet = Net::DHCP::Packet->new($newmsg);
  # site-local option 252 "auto-proxy-config"
  my $wpad = $packet->getOptionValue(252);
[download]

On my home Mac OS X machines and work Windows XP machine, there is no answer to the discover packet: @ready is always empty after 5 seconds. Without the select and if statements, the recv hangs interminably.

For those into tcpdump output, here are one case and another.

Suggestions will be much appreciated, even if they just suggest a more appropriate forum on which to ask for help.

Thanks,
cmac

Comment on No reply to DHCP DISCOVER Select or Download Code

Replies are listed 'Best First'.
Re: No reply to DHCP DISCOVER by amedico (Sexton) on Mar 23, 2010 at 17:21 UTC
Do you have any reason to believe 4111 is a valid source port for a DHCP request packet? I've only ever seen 68 used, and I expect many DHCP servers and firewalls are hard-coded to expect that.	[reply]
Re^2: No reply to DHCP DISCOVER by cmac (Monk) on Mar 24, 2010 at 02:25 UTC
Well, DISCOVER is semantically similar to INFORM. Actually I think it started with INFORM, and at some point it morphed into DISCOVER. Use of > 1023 as the local port was to avoid permission problems on Unix boxes. I reasoned that I should be able to ask for a reply on any port I want, no? So I changed the message type to INFORM and the LocalPort to 67 or 68: my $socket = IO::Socket::INET->new(Proto => 'udp', Broadcast => 1, PeerPort => '67', LocalPort => '68', PeerAddr => '255.255.255.255') or die ($@); # create and send DHCP Packet my $disc = Net::DHCP::Packet->new(xid => int(rand(0xFFFFFFFF)), DHO_DHCP_MESSAGE_TYPE() => DHCPINFORM()) or die "Can't create DHCP discover packet: $!"; $socket->send($disc->serialize()) or die "Can't send DHCP discover packet: $!"; my @ready = IO::Select->new($socket)->can_read(5); if (@ready) { my $newmsg; $socket->recv($newmsg, 1024) or die "Can't recv DHCP discover packet: $!"; [download] But those changes don't result in receiving a reply, nor does inserting or removing the `Flags => 0x8000,` in the Packet->new call. Stepping through these has taught that nothing happens until the send call, at which time we get the following on tcpdump: dual-1-25:~ $ sudo tcpdump -evvv tcpdump: listening on en0, link-type EN10MB (Ethernet), capture size 9 +6 bytes 19:18:21.323270 00:03:93:ab:f2:44 (oui Unknown) > Broadcast, ethertype + IPv4 (0x0800), length 342: (tos 0x0, ttl 64, id 11213, offset 0, fla +gs [none], proto UDP (17), length 328) 192.168.1.2.bootps > broadcast +host.bootps: BOOTP/DHCP, Request from 00:00:00:00:00:00 (oui Ethernet +), length 300, xid 0x12345678, Flags [Broadcast] (0x8000) 19:18:21.335493 00:24:01:47:07:41 (oui Unknown) > Broadcast, ethertype + IPv4 (0x0800), length 314: (tos 0x0, ttl 64, id 0, offset 0, flags [ +none], proto UDP (17), length 296) 192.168.1.1.bootps > broadcasthost +.bootpc: BOOTP/DHCP, Reply, length 268, xid 0x12345678, Flags [Broadc +ast] (0x8000) 19:18:22.154360 00:03:93:ab:f2:44 (oui Unknown) > 00:24:01:47:07:41 (o +ui Unknown), ethertype IPv4 (0x0800), length 84: (tos 0x0, ttl 64, id + 5403, offset 0, flags [none], proto UDP (17), length 70) 192.168.1.2 +.52733 > 192.168.1.1.domain: [udp sum ok] 8378+ PTR? 2.1.168.192.in-a +ddr.arpa. (42) 19:18:22.194739 00:24:01:47:07:41 (oui Unknown) > 00:03:93:ab:f2:44 (o +ui Unknown), ethertype IPv4 (0x0800), length 88: (tos 0x0, ttl 248, i +d 47363, offset 0, flags [DF], proto UDP (17), length 70) 192.168.1.1 +.domain > 192.168.1.2.52733: [udp sum ok] 8378 NXDomain q: PTR? 2.1.1 +68.192.in-addr.arpa. 0/0/0 (42) 19:18:22.201699 00:03:93:ab:f2:44 (oui Unknown) > 00:24:01:47:07:41 (o +ui Unknown), ethertype IPv4 (0x0800), length 84: (tos 0x0, ttl 64, id + 7025, offset 0, flags [none], proto UDP (17), length 70) 192.168.1.2 +.52029 > 192.168.1.1.domain: [udp sum ok] 21785+ PTR? 1.1.168.192.in- +addr.arpa. (42) 19:18:22.242546 00:24:01:47:07:41 (oui Unknown) > 00:03:93:ab:f2:44 (o +ui Unknown), ethertype IPv4 (0x0800), length 88: (tos 0x0, ttl 248, i +d 23813, offset 0, flags [DF], proto UDP (17), length 70) 192.168.1.1 +.domain > 192.168.1.2.52029: [udp sum ok] 21785 NXDomain q: PTR? 1.1. +168.192.in-addr.arpa. 0/0/0 (42) 19:18:27.190310 00:24:01:47:07:41 (oui Unknown) > 00:03:93:ab:f2:44 [download] Can anyone see anything from this? cmac	[reply] [d/l] [select]
Re: No reply to DHCP DISCOVER by pilcrow (Sexton) on Mar 23, 2010 at 17:17 UTC
I'm not sure about a more appropriate forum, but, as I read the references you supplied, you ought to be sending a `DHCPINFORM` (unicast if you can), and not a `DHCPDISCOVER`. You might also need `LocalPort => 68` Good luck.	[reply]