Subject: [dhcwg] Source address in Vista DHCP packets.

From: Simon Kelley <[email-masked]>
Date: Thu, 21 Feb 2008 11:20:59 +0000

I've just had some tcpdump output sent to me by someone who is having
problems getting Windows Vista to work with dnsmasq. Vista is emitting
DHCP packets which look like this. There's not enough information to be
sure if they are DISCOVER or REQUEST packets (and what flavour of
REQUEST), but my guess is that they are DISCOVER.

Client Ethernet Address: 00:17:c4:10:9a:3c [|bootp]
17:36:50.527538 IP (tos 0x0, ttl 128, id 442, offset 0, flags [none],
length: 328) 169.254.194.239.68 > 255.255.255.255.67: BOOTP/DHCP,
Request from 00:17:c4:10:9a:3c, length: 300, xid:0xe014ef8f, secs:768,
flags: [Broadcast] (0x8000)

Note that the source address in the IP header is 169.254.194.239 which
is in the APIPA range. I suspect that this is the cause of the problem,
(a badly configured firewall to dumping these packets before they get to
the DHCP server because of their source address), but that is not point
of this post. I think this behaviour is a standards violation.

From RFC 2131:
   DHCP messages broadcast by a client prior to that client obtaining
   its IP address must have the source address field in the IP header
   set to 0.

It looks like the Microsoft DHCP client violates this if DHCP has timed
out at some point and an APIPA address has been selected. Further
attempts at DHCP then have a wrong source address.

So: questions.

1) Has anyone else seen this? Can you clarify the circumstances under
which it occurs?

2) Is this really a standards violation?

3) If it is, does anyone have experience of the best way to report it as
bug to Microsoft?

Cheers,

Simon.

_______________________________________________
dhcwg mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Thu, 21 Feb 2008 09:26:29 -0700

> 1) Has anyone else seen this? Can you clarify the circumstances under

The old Mac client used to do this.   I think it's actually a good  
extension, because it eliminates the need for broadcast.   However...

> 2) Is this really a standards violation?

Yes, it is - the client is not following the standard, and because the  
standard doesn't actually allow for the client's current behavior,  
it's not reasonable to expect this to work.

> 3) If it is, does anyone have experience of the best way to report  

Not a clue.   I think some folks at microsoft do read this mailing  
list, though.

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 21 Feb 2008 11:32:21 -0800

> flags: [Broadcast] (0x8000)

That's really curious, you say this is Vista?

I only looked at an early Vista beta, but it used 0.0.0.0.  I still
have the tcpdump output here.  So this must have been a late (or
recent?) change.

I note they're setting the broadcast flag still, however, that matches
my output

> 3) If it is, does anyone have experience of the best way to report it as

Ask them about the broadcast bit too.  That's such a big step
backwards for people running busy networks.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
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
_______________________________________________
dhcwg mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/dhcwg

---

From: Simon Kelley <[email-masked]>
Date: Fri, 22 Feb 2008 10:00:44 +0000

> That's really curious, you say this is Vista?

This is a report about a Vista Home Basic on a public system, so degree
of confidence/repeatability is not high. I know that Windows will fall
back to APIPA and pick a 169.254.x.x address if DHCP fails, My guess is
that if APIPA happens but then the DHCP process restarts (wireless
network found, network cable plugged in) then the APIPA-allocated
address turns up in the source address of the DHCP packets. It's likely
that for a machine which is doing DHCP but has not yet done APIPA, the
source address is 0.0.0.0, so both your observations and mine are
probably true under different circumstances.

> have the tcpdump output here.  So this must have been a late (or

After my initial posting here, I got hold of a full binary packet dump,
and I can confirm that the offending packets are indeed DHCPDISCOVER.

> I note they're setting the broadcast flag still, however, that matches

Yes, awful, isn't it?

> backwards for people running busy networks.
If I ever find a way to report a bug to Microsoft, I will.

Cheers,

Simon.