Longhorn breaks VT1005V

Posts: 1715 · Posted: Fri Aug 12, 2005 3:16 pm Post subject:

and for how many years did Windows have the "ping of death" problem?

Posts: 23 · Vonage Forum Associate Joined: Aug 04, 2005 Posts: 23

The day Microsoft makes something that doesn't suck, is the day they make vacuums.

Posts: 38 · Vonage Forum Junior Joined: Jul 28, 2005 Posts: 38

gkdada,

I would respectfully disagree. DoS attacks would generally come from outside your network (WAN). These routers have shown no vulnerability to this. As you say, the router should not be able to be locked up, if indeed that is what is happening, by any ordinary code sent to or through it from the LAN side of the network. However because this IS happening does not mean the router is altogether to blame.

Say, for example, that you have a transformer that dutifully converts one type of source voltage into another type of destination voltage for consumption. However, due to an upgrade the source voltage changes and suddenly your transformer no longer operates at peak efficiency or fails repeatedly. Is the transformer to blame? Yes, but it was not the cause of the problem. The root cause of the problem would be the source voltage change.

Now, that being said, the router may likely be able to be upgraded or as is being suggested, replaced, to resolve this issue. However, to blame the problem completely on the router is not reasonable as the router is quite likely performing to specification. As both of us are likely aware, the Internet and IP is constantly changing. (http://www.rfc-editor.org/rfcxx00.html) To expect hardware to somehow morph in its shell and change with it is absurd.

Your turn...

Posts: 8 · New Forum Member Joined: Aug 12, 2005 Posts: 8

Exactly. Let us check the possibilities. When a packet is received:
1. It is either in a protocol that the router understands or it isn't. In the latter case, the packet should just be ignored.

2. The packet is either perfectly formed or it is malformed. In the latter case, the router should either ignore it or send a rebuke to the sender.

3. The packet is (while perfectly formed) violating some other aspect of communication. The response should again be the same as no. 2, with an additional option of disconnecting the sender.

To sum up, the options upon receiving a packet are: Accept, Ignore, Reject (and rebuke) or Disconnect. Going under-water is simply not an option.

If the Longhorn machine had lost internet connection but the phone was still working, I would have gone to Microsoft instead of Motorola. If the cable modem went down as well, I would have gone after D-Link (first).

Posts: 23 · Vonage Forum Associate Joined: Aug 04, 2005 Posts: 23

Quote:

Going under-water is simply not an option.

It most certainly is or this wouldn't be happening Wink

Posts: 14 · Vonage Forum Associate Joined: Mar 18, 2005 Posts: 14

myrddin wrote:

I would try telling Microsoft about this rather than Vonage, since it would seem the problem is more on their side.

Microsoft usually claims ALL problems involving non-MS hardware and software are the fault of somebody else. They break things right and left and then say it's the other guy's fault for not complying with the moving targets they facetiously call "standards."

Posts: 1715 · Posted: Fri Aug 12, 2005 11:06 pm Post subject:

Larc wrote:

myrddin wrote:

I would try telling Microsoft about this rather than Vonage, since it would seem the problem is more on their side.

Microsoft usually claims ALL problems involving non-MS hardware and software are the fault of somebody else. They break things right and left and then say it's the other guy's fault for not complying with the moving targets they facetiously call "standards."

Yep, even when using a stock Intel motherboard, Intel chipset, Intel audio, Intel video and Intel CPU, MS claims it's still a hardware issue. Which makes me wonder what they use in their offices.

Posts: 8 · New Forum Member Joined: Aug 12, 2005 Posts: 8

Bingo!

There is a service called "IP" which (according to MS) "Provides DDNS name registration and automatic IPv6 connectivity over an IPv4 network. If this service is stopped, other computers may not be able to reach it by name and the machine will only have IPv6 connectivity if it is connected to a native IPv6 network".

I stopped (and disabled) this service and the problem went away.

Translation: VT1005V CANNOT handle IPv6 packets. Motorola better do something about it and do it before longhorn ships.