Vista Bug Costs Users In Swedish Town Their Internet 644
Lund, Sweden refuses to work around a Vista bug, so people who live there must choose between Vista and internet access. It's nice to see the right people being held accountable for a change.
Lund is... (Score:3, Informative)
Not a Vista bug (Score:2, Informative)
http://support.microsoft.com/default.aspx/kb/9282
This is in compliance with DHCP standards.
Ofcourse the incompetent Admins will blame Vista and not fix the router software.
Oops... (Score:3, Informative)
Nevermind then. (blush)
Re:router (Score:5, Informative)
In short, having a home router would solve the problem.
Lost in translation (Score:5, Informative)
Re:Not a Vista bug (Score:5, Informative)
"Which implementations support or require the broadcast flag?
The broadcast flag is an optional element of DHCP, but a client which sets it works only with a server or relay that supports it.
Clients
Microsoft Windows NT
DHCP client support added with version 3.5 sets the broadcast flag. Version 3.51 and later no longer set it. The exception is in the remote access support: it sets the flag when it uses DHCP to acquire addresses to hand out to its PPP clients.
tcp/ip-32 for Microsoft Windows for Workgroups (WFW)
Version 3.11a sets it, but version 3.11B doesn't.
Microsoft Windows 95
Does not set the broadcast flag."
So, I guess Vista only works with Servers that support it and it was an option to implemant it. End of Story.
Re:Vista DHCP client and Linux (Score:5, Informative)
A client that cannot receive unicast IP datagrams until its protocol
software has been configured with an IP address SHOULD set the
BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER or
DHCPREQUEST messages that client sends. The BROADCAST bit will
provide a hint to the DHCP server and BOOTP relay agent to broadcast
any messages to the client on the client's subnet. A client that can
receive unicast IP datagrams before its protocol software has been
configured SHOULD clear the BROADCAST bit to 0.
RFC1542 States
3.1.1 The BROADCAST flag
Normally, BOOTP servers and relay agents attempt to deliver BOOTREPLY
messages directly to a client using unicast delivery. The IP
destination address (in the IP header) is set to the BOOTP 'yiaddr'
address and the link-layer destination address is set to the BOOTP
'chaddr' address. Unfortunately, some client implementations are
unable to receive such unicast IP datagrams until they know their own
IP address (thus we have a "chicken and egg" issue). Often, however,
they can receive broadcast IP datagrams (those with a valid IP
broadcast address as the IP destination and the link-layer broadcast
address as the link-layer destination).
If a client falls into this category, it SHOULD set (to 1) the
newly-defined BROADCAST flag in the 'flags' field of BOOTREPLY
messages it generates. This will provide a hint to BOOTP servers and
relay agents that they should attempt to broadcast their BOOTREPLY
messages to the client.
If a client does not have this limitation (i.e., it is perfectly able
to receive unicast BOOTREPLY messages), it SHOULD NOT set the
BROADCAST flag (i.e., it SHOULD clear the BROADCAST flag to 0).
DISCUSSION:
This addition to the protocol is a workaround for old host
implementations. Such implementations SHOULD be modified so
that they may receive unicast BOOTREPLY messages, thus making
use of this workaround unnecessary. In general, the use of
this mechanism is discouraged.
If XP can receive unicast IP datagrams. why cant Vista? Either MS broke Vista or the TCP/IP stack is less functional than before. Either way, use of the broadcast flag is discouraged.
Re:Not a Vista bug (Score:5, Informative)
RFC 1542 sayeth
3.1.1 The BROADCAST flag [...] This addition to the protocol is a workaround for old host implementations. Such implementations SHOULD be modified so that they may receive unicast BOOTREPLY messages, thus making use of this workaround unnecessary. In general, the use of this mechanism is discouraged.
Re:Why Are People Celebrating (Score:3, Informative)
Ah, no, sorry, welcome to Sweden. I know things work a bit differently in the states, but we actually got competition.
Lunds energi drop fiber along with their heating pipes and sell net access over that. Other than that, you'd have at least four different DSL providers plus net over CATV. Chances are that you'd actually have another 100Mbit ethernet provider over in Lund on top of that.
Lunds energi is definitely not the only shop in town
Re:router (Score:5, Informative)
The article you reference contains the solution .. (Score:5, Informative)
RESOLUTION
Warning Serious problems might occur if you modify the registry incorrectly by using Registry Editor or by using another method. These problems might require that you reinstall your operating system. Microsoft cannot guarantee that these problems can be solved. Modify the registry at your own risk.
To resolve this issue, disable the DHCP BROADCAST flag in Windows Vista. To do this, follow these steps:
1. Click StartStart button, type regedit in the Start Search box, and then click regedit in the Programs list.
User Account Control permission If you are prompted for an administrator password or for confirmation, type your password, or click Continue.
2. Locate and then click the following registry subkey:c es\Tcpip\Parameters\Interfaces\{GUID}
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servi
In this registry path, click the (GUID) subkey that corresponds to the network adapter that is connected to the network.
3. On the Edit menu, point to New, and then click DWORD (32-bit) Value.
4. In the New Value #1 box, type DhcpConnDisableBcastFlagToggle, and then press ENTER.
5. Right-click DhcpConnDisableBcastFlagToggle, and then click Modify.
6. In the Value data box, type 1, and then click OK.
7. Close Registry Editor.
So Vista isn't (formally) going counter to protocol, it's just going counter to a 15-year old custom. Nonetheless, Vista *can* cooperate, it just needs to be told not to raise the DHCP BROADCAST flag. And yes, that route goes via a registry modification.
In summary: a tropical storm in a teacup.
The right people accountable?? (Score:3, Informative)
From the article, even in Swedish, it makes it clear that the town doesn't want to cooperate with Microsoft on providing data for the bugfix. The accountable party here, then, is the town internet provider and not Microsoft.
[Town]: Our internets doesn't work with Vista
[Microsoft]: Okay, do you have any data on why not?
[Town]: no but it's your fault, fix it!?!?
[Microsoft]: Well, what's even a short description of the problem? Side effects? Can your Linux server be changed to alleviate it in the meantime?
[Town]: THE INTERNETS IS BROKEN, FIX IT THOUGH OKAY!!!!????
Yeah, all Microsoft's fault. If this was on Mozilla or Novell or Linux bugzillas it would have been closed as "irrelevant".
Re:Why Are People Celebrating (Score:3, Informative)
Monthly fee
100 Mbit/s 349 kr 329 kr 299 kr
10 Mbit/s 199 kr 179 kr 159 kr
7 SEK = 1 $
Re:I have no sympathy for Lundis Energi (Score:4, Informative)
There are also reports that Cisco equipment won't work with it either.
Re:router (Score:2, Informative)
Re:router (Score:4, Informative)
"In general, an implementation should be conservative
in its sending behavior, and liberal in its receiving behavior. That
is, it should be careful to send well-formed datagrams, but should
accept any datagram that it can interpret (e.g., not object to
technical errors where the meaning is still clear)."
Re:How's this funny again? (Score:3, Informative)
Right, then they call their ISP, and they explain that Vista is broken. And the person is upset. But it's still a matter of something broken not being allowed on the network. Since it's supposedly a broken DHCP request, the people could buy a router and be done with it.
The funny thing is that that monopoly is no longer being humored, because the monopoly has been acting unconscionably for 10 years, and people don't have to put up with it anymore. It sucks that little people are getting squished, but Microsoft has (and arguably in this case, still is) squished the little people because they felt like it.
Hooray!
Re:Win95 & Win98 & Win2K & WinXP did i (Score:3, Informative)
From rfc-1542 that regulates the use of the broadcast flag:
And from the same rfc, a section that defines certain terms, including SHOULD
(also later defined in rfc-2119)
These two documents show that although the use of the BROADCAST flag is standard compliant (and we could argue that the DHCP server involved SHOULD try to answer them), the implementation of a modern DHCP client on a system capable of receiving unicast responses using the BROADCAST flag is not (at least without a very good reason to do so).
Considering that Microsoft has already made DHCP software capable of receiving unicast DHCP requests, and seeing that the fix proposed by Microsoft themselves is a simple change in a registry entry (meaning the software is in fact capable of receiving unicast responses), I'd say the software is not compliant.
I consider that behavior non compliant unless Microsoft had a very good explanation (the possibility of Vista running on a pc not capable of receiving unicast responses not a good one, since the flag should have been set the other way). It is at the very least gross imcompetence, if not outright malicious behaviour.
Re:Oops... (Score:2, Informative)
Summary (Score:5, Informative)
a)Per the RFC servers do not need to implement the broadcast flag, but it is a good idea if you want to support systems that use it.
b)Per RFC Vista doesn't need to clear the broadcast bit, but it is strongly recommended and setting it is intended for legacy clients only.
c)Lund's energi's network doesn't support the broadcast and thus Vista machines do not get an IP over DHCP since they set the broadcast bit.
d)For reasons we don't yet know, Lund energi won't implement a workaround on their server. I don't know enough about DHCP or their systems to tell why, so I guess there might be a technical issue or perhaps they are just being jerks.
e)The fix is to set a registry key, which is easy for technical users, but a pain for those who don't know about it.
My judgement is that Lund's energi has a shitty DHCP server and Vista is a shitty DHCP client. Since the fix is so simple ( adding a registry key ) this really ought to be a non-issue, but because Microsoft and Lund's energi are both incompetent crappy companies the end user is left with a problem that would actually be rather easy to resolve. Those in the know can work around it, but non-technical users are left without service while those responsible point the finger at one another. The sad thing is that this really isn't particularly surprising. Hmm, did I forget something? Oh yea, the article summary is wrong since there are scores of ISPs in Lund, and this only affects one of them. So yea, I'm not very surprised at all...
Re:So... (Score:5, Informative)
As I understood it, the bug was this: Vista will only accept broadcast replies to DHCP requests. Any multicast response is discarded for security reasons (!?). So their solution was to put a DHCP server on every level of our network (for us, one for every 200 users) or switch to a network that relayed the broadcasted replies (ie: hubs). They also told us it wasn't a bug so they wouldn't issue a patch to correct it. There was a KB article on the issue but when we had users call MS support and ask them to walk them through applying it, we got a bunch of angry calls back to us saying MS refused to help them with it. We also talked to Cisco a bit to see if they had any idea what we could do to relay the broadcast but they never got us a solution.
So in the end, we told MS that we'd either need a better way to fix this or we'd just tell our users not to use Vista. They seemed okay with us telling users not to use it so we have. A few of our users still use Vista with a home router and that seems to work alright. Luckily, there aren't too many Vista users yet and when faced with the option of buying and configuring a router or buying and configuring Windows XP, they've decided on XP. So all in all, it wasn't that big of a deal.
Jem Tallon
Re:The only thing that could make this better (Score:3, Informative)
Re:router (Score:3, Informative)
Since you claim to be reading the standards documents, you would be better of questioning your own reading comprehension skills.
Re:Okay.. (Score:2, Informative)
Re:router (Score:3, Informative)
I interpret this to mean that if the traffic is understandable, then it should be permitted unless there is some technical reason why it should not -- and RFC pedantry is not automatically a reason to prohibit it. For example, if it is interfering with the network or other hosts in some way, such as overloading a system or causing traffic disruptions, that is a valid technical reason for preventing use of the network.
Your definition of "it would be nice if" falls closer to the RFC definition of "may":
Re:The only thing that could make this better (Score:2, Informative)
I guess this depends on your definition of "user-friendly." I think Ubuntu is very friendly because it never insists on calling home to report on what software I'm running.
Re:router (Score:4, Informative)
Vista has a new TCP stack, it would be incredibly stupid to implement such an ancient bug, especially when all earlier versions of windows worked correctly.
Infact, the vista TCP stack does support receiving of unicast packets, and yet microsoft still chose to use the broadcast flag without reason. That's why this ridiculous behaviour can be turned off with a simple registry entry. The broadcast flag is intended for TCP stacks which _CANNOT_ support unicast, it is absoloutely incorrect to use it as the default on a stack which can support it.
The broadcast flag is only intended for compatibility with very old TCP stacks (i cant think of any which requires it, and it makes sense that this legacy functionality was intended to be removed when you weren't using any of these legacy systems.
So, did this swedish ISP have any reason to believe that people would be connecting ancient TCP stacks to their network? If not, it makes sense that they wouldn't support this legacy flag.
Re:The only thing that could make this better (Score:5, Informative)
Out of box Ubuntu supports my network card and with a few simple clicks my printer and I can start installing my favourite software.
My point here isn't to start a flame war, but rather that the Window's experience isn't so wonderful out of the box when the last service pack was 3 years before your current hardware came out. When you consider this, there is something to be said for Ubuntu's 6 month cycle.
Oh and I've never used a wireless adapter in XP (~6) or Vista (1) that worked out the box.
Re:Oh no, there's more. (Score:3, Informative)
Re:So... (Score:1, Informative)
http://support.microsoft.com/kb/928233 [microsoft.com]
http://www.askdavetaylor.com/dhcp_unicast_broadca
So basically the problem is that Vista is utilising a part of the DHCP standard that is not implemented on Lundis DHCP server.
It's the Linux system here which is failing to comply with the DHCP standard not the other way around.
I think this would be an entirely different story and an entirely different response from Lundis admin if this issue was with say... a new version of Apple OSX.
They should just update their DHCP server to something a little more up to date and compliant, and stop playing stupid anti-MS political games.
I don't really blame Microsoft for refusing to help your Vista users. As with most companies Microsoft charges for support, they're not going to help your users for free.
What sort of IT Administrators do you have ? Most of the civilised IT world would have a single administrator or at least appoint a single person to consult Microsoft and determine an appropriate solution, in this case a simple reg file distributed on a USB key or a login script would do the trick.
Re:router (Score:1, Informative)
http://support.microsoft.com/kb/928233 [microsoft.com]
http://www.askdavetaylor.com/dhcp_unicast_broadca
It sets the DHCP Unicast Broadcast flag.
Yeeeeeeep that them Vista DHCP packets be real broked I reckon rightly. Nice thunkin.
Anyway, here's Jim's answer:
This isn't so much a client issue as it is a server issue. In order for your Windows clients to receive DHCP responses by unicast rather than broadcast, you need to configure the DHCP server accordingly to allow clients to request a unicast response. To do so, you must modify the registry on the DHCP server (assuming a Windows-based DHCP server).
1. On the server, open the Registry Editor and navigate to the key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servi
2. If the IgnoreBroadcastFlag value does not exist in this key, create it as a DWORD value.
3. Set the value of IgnoreBroadcastFlag to to 1 to cause the server to ignore the client broadcast flag and always respond with multicast. Set the value of IgnoreBroadcastFlag to 0 to allow the clients to request unicast.
4. Close the Registry Editor and restart the DHCP server.
Vista's implementation is fine, it's the antiquated software Lundis admin are grimly determined to hang on to that's the problem.
Re:So... (Score:5, Informative)
I work for a networking company and a few months ago I fixed our BootP relay to be able to handle this.
If you read the DHCP RFC, you will discover that this broadcast packet is actually an optional part of the spec. Furthermore, it was designed for (at the time - circa 1993) LEGACY equipment that could not handle unicast responses.
Ie, I ask for an IP address, and because I'm a crappy old piece of hardware that can't handle it, I want the DHCP server to reply to me with a broadcast reply telling me my IP address. Normally such responce is unicast to your MAC address and everyone is happy.
Windows XP works fine and will accept a unicast reply. In Vista Microsoft had the brilliant idea that they should enable this flag by default - despite the fact that any modern computer should be able to handle a unicast reply - they could back in 1993 after all.
So yes, the fault is precisely with Microsoft for enabling an unnecessary and OPTIONAL part of the DHCP protocol by default, causing untold problems that could simply be avoided if they stuck to the XP way of doing things.
Re:router (Score:1, Informative)
So, it's looks like Vista uses the OLD approach (broadcast) by default instead of the current modern approach (Unicast). This is drain bamaged by Microsoft alright.
(The Linux box isn't supporting the OLD broadcast standard - completley opposite of what you're saying. Support for broadcast by a server is only a "SHOULD" and not a "MUST" in the relevant RFC, so the Linux box is adhering to standards.)
As for your other comment, "Jim"s article is a red-herring. His post is about causing the Windows DHCP *server* to send a Unicast response EVEN IF the client asks for a Broadcast response - which is not what a sane DHCP implementation should need to do, now, is it? His post is essentially "how to configure Windows DHCP servers to work around drain bamaged clients that ask for Broadcast for no good sane reason."
Read the comments on this post [technet.com]. Microsoft have been told. And as you can see, even they know that broadcast support in a server is only a should, not a must.
(WHY Microsoft changed Vista to use broadcast by default is the question - I cannot think of a sane reason for it. There are situations (such as with DHCP relay agents) that unicast will work when broadcast won't.)
Re:The only thing that could make this better (Score:2, Informative)
Re:So... (Score:1, Informative)
Re:router (Score:4, Informative)
1. There is one flag in DHCP protocol, the "BROADCAST" flag. The "Clarifications to BOOTP (RFC 1542)" gives a nice description of it's purpose (referenced from DHCP RFC2131).
2. Normally the server sends DHCP replies as unicast packets to a specific node.
3. It is suggested there are TCP/IP implementations unable to receive such a unicast packet before they have been fully configured, in which case they should set "the flag" to request that the server sends it's reply as a broadcast instead. Server should honor such a request. I guess such an implementation would configure their local MAC (or equivalent?) at the same time with their IP level settings, which might be a sensible thing to do in a simplistic single family (IP-only) network stack, which was designed before anybody thought of "auto-configuration" things like DHCP.
4. For some unknown reason, Vista sends DHCP requests with "the flag" set by default, even if it doesn't have said inability to receive unicast packets before being fully configured.
5. A DHCP server should honor such a request, though from reading the discussion here, I futher conclude that for various reasons, maintainers of certain servers and/or networks are unwilling to support broadcast replies to DHCP requests. At least in case of centralized DHCP servers this seems a reasonable decision.
Now, it's likely that MSFT has some purpose for setting the broadcast flag (other than pissing people up). So far this purpose is more or less a mystery to me. One possible reason I can immediately think of would be allowing a DHCP server to detect the presence of another DHCP server by monitoring DHCP reply broadcasts that somebody else sent (that could be useful for certain types of "zero-config" networking maybe?). But then again they might have another reason? Who knows.. maybe they wanna start selling DHCP relays? Or maybe they want Vista users to get static IPs?
Anyway, it doesn't seem like anyone is breaking the letter of the standard, as the DHCP requests Vista's sending are technically valid (although the flag isn't set for the specific rationale it exists for), yet the servers/networks/whatever aren't really required to support the flag either (although they "should").