DHCP relay with UDP source port of 67 causes ISC 3.0.2 to respond with UDP source port of 1

[David W. Hankins]

On Sat, Oct 28, 2006 at 01:55:07AM -0500, Frank Bulk wrote:
> When we do that, DHCP Discovers to ISC dhcpd (running on a 3rd-party
> appliance) returns to the CMTS with a DHCP Offer of 1/67 rather than the
> 67/67.  Many Windows client don't seem to like this offer because of the
> source port of 1 and just drop the packet, issuing another DHCP Discover.

The OFFERs came out of the DHCP server with source port 1?  Or
they came out of the CMTS with source port 1?

I think it is highly unlikely that the OFFERs came out of the
DHCP server, destined to the CMTS, as anything other than 67/67.

> We had to downgrade the CMTS to get our subscribers back to a good state,
> but I've been able to simulate the problem by using bittcap to inject
> earlier-captured DHCP Discover packets into the network.  When I change the
> source port to 68/67 using bittcape, those DHCP Discovers result in proper
> DHCP Offers of 67/67.

I think if the variable you changed is the CMTS, that it is hard to
imagine the bug being elsewhere.

> Has anyone else seen this, does newer ISC dhcpd code resolve this, and if
> not, where in the code is this being done so that this can be fixed?

This is news to me.  I don't think the dhcp server should care what
source port the relay uses, so long as it uses destination port 67.

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins