Workarounds for Vista's Networking Problems?
tridium asks: "I recently moved into a new place where the landlord left a Linksys WRT54G v2 router for us to use. The three laptops in the house running XP connected to it fine, but my desktop, running Vista RC1 build 5600, had to be hardwired. The Internet worked fine for a bit, but I noticed some websites weren't loading up (Google, Gmail, and several others), and IM clients weren't working. Vista's self-diagnosis said it couldn't communicate with the DNS server, so I researched and it seems the new TCP stack in Vista is wreaking havoc with my router. I upgraded the firmware from Linksys, tried manually setting IP settings, modified the registry to disable TCP window stacking, but nothing helped. Linksys support was also useless in fixing the problem. I'm at a loss and any help, short of downgrading to XP, would be greatly appreciated." Other people have experienced problems getting Vista to work with off-the-shelf routers. A thread from September identifies the new window scaling feature as a potential culprit, while another article says that Vista and SPI-enabled routers don't play well together. Whether the problem is related is unknown, but another thread offers some troubleshooting tips for anyone else who may be experiencing this problem. Has anyone figured out how to disable (or at least work around) some of the more troubling aspects of Vista's new TCP 'features'?
Vista RC1 build 5600?
For starters, try, oh, I dunno, a newer RC, if you were part of the test, or...wait for it...the release version?
This sort of story makes me a bit ill. I know this is Slashdot and all, but can we please have SOME sort of filter for "my lonely pre-release copy of Vista dosen't work on my home network" stories?
Wait a month and buy the real version of Vista instead of using an old, unfinished release candidate.
120 characters for a sig? That's bloody useless.
Microsoft technical support?
The instructions at this url worked for me: http://www.tech-recipes.com/modules.php?name=Forum s&file=viewtopic&t=2602#7746
I play games you insensitive clod!
Such is the life of a beta tester...
Oh, wait, you mean you were trying to use release canidate software it in a production environment (even if it is a home PC)? You found things didn't work correctly. Well, I'm sure you submitted your results through the appropriate channels at Microsoft, right?
Read the fine print next time; it's for testers and developers, not for getting a free OS for a year that works correctly in a production environment.
The article describes two separate issues: TCP window scaling, and SPI (Stateful Packet Inspection). These have very little to do with each other, excepting the fact that they're both networking features in Windows Vista.
From what I gather from a quick Google, the problem with TCP window scaling is actually one with crap routers that don't support the feature and misbehave upon encountering it. Furthermore, TCP window scaling is not new to Windows Vista. It was merely disabled by default in previous versions of Windows. The fix is extremely simple, see this article for information.
The second issue, with SPI, seems to indeed be a Vista bug, but I can find no evidence whatsoever that it exists in Vista RTM, or even RC1/RC2. It's seriously not "stuff that matters" anymore. Prerelease versions always have bugs! If you don't like it, wait for the RTM (or as is usually the case with Microsoft, the first service pack)!
Quality, performance, value; you get only two, and you don't always get to pick.
W...T...F...?
If this place were even approximately "News for Nerds", Our Illustrious Editor would have realized that calling TCP Window Scaling "new" rises to the same level as referring to the recently-inaugurated Clinton administration. Literally: RFC 1323 dates to 1992.
I love the scare quotes around "features" at the end of the summary to. God forfend that that evil Micro$oft CORRECTLY implement a TCP standard.
Sigh. Look folks. In this case, MS isn't at fault. It's craptacular consumer-grade network gear which cuts corners on standards compliance. I acknowlege freely that MS is an evil monopolistic corporation bent on world domination, but in this case that's beside the point.
Welcome to the Panopticon. Used to be a prison, now it's your home.
The problem is that most consumer-level hardware is only tested with the most common TCP settings, so, changing the TCP receive window (RWIN) or maximum transfer unit (MTU) often reveals hidden bugs in their TCP/IP implementations.
Even the subtle changes in timing of the packets may trigger previously undiscovered bugs.
In my case, the web interface of the Acorp LAN420 ADSL router was 'freezing' 75% of the times when accessed from Vista(RTM). Upgrading to the latest firmware solved this problem.
If everything else fails, you can try disabling RWIN scaling by running this as administator:
netsh interface tcp set global rss=disabled
netsh interface tcp set global autotuninglevel=disabled
(to see the list of available options, just run 'netsh interface tcp set global')
throw new SuccessException("Sig read successfully");
For me it stopped being funny after the 10,000th time. Imagine if every linux question were guaranteed to include multiple "Install the latest patch from Redmond" variants. Sure, it is funny once (especially the redmond one I just made up) but give it a rest once in a while. I'm extra unsympathetic to downmods since this used to be a guaranteed +5, Insightful. Stupid karma whores.
Anyway, even the most rabid linux fan has to admit that there are people who, for various reasons, use windows. Let them ask questions and get answers without snarky unhelpful "advice" from time to time ok?
Man, you really need that seminar!
This relates to a question I posed on Amiga.org:
t opic_id=35273&forum=22#forumpost417060
/dev/udp, etc.)
Amiga.org - Forum
http://www.amiga.org/modules/newbb/viewtopic.php?
"Is pluggable TCP/IP stacks feasible in mainstream operating systems?
On Amiga we have been graced with AmiTCP, Termite TCP, Miami, Genesis, and probably other TCP/IP stacks about which I do not know. IIRC, these mutated from an original stack produced by Commodore (AS225?) and all offer some compatibility to what appears to be ubiquitous among Amiga, the bsdsocket.library.
So I read about how Gibson Research decried the raw socket access introduced by the new Windows XP TCP/IP implentation (which has not caused the end of the world, best as I can tell,) and Windows Vista introduces another TCP/IP stack. All of these harken back to winsock.dll and winsock2.dll.
Then there's the TCP/IP stack within the Linux kernel, and found in most Unix implementations such as Solaris (/dev/tcp,
We run into so many issues with vendors' TCP/IP stacks (like Windows XP SP2's half-open connection limitation,) why do third party vendors not create third-party TCP/IP stacks? Or do they?
Regardless of the thought process behind the curiosity, could we speculate on the viability? Would it be a potential segregation of the mainstream OS world, or could one vendor's better implementation take over?
I see potential for the server market where many system builders, administrators, and maintainers would like to tweak system performance and security as much as possible. Would TCP/IP outside of the operating system allow for such an approach? And would it be too much of a potential black-eye for OS vendors to ever allow?"
He runs a Maq, you run a Toad?
Trolling is a art,
I don't always use unix-like operating systems; but when I do, I prefer FreeBSD.
Windows will let you add protocols to the system, and bind and unbind them from adapters as you see fit. Someone is perfectly free to write a replacement TCP stack. However as a practical matter it's unlikely to happen because the Windows TCP stack works great for most people. Yes, the /. crowd like to bitch, but then it's full of pedantic geeks that dislike Windows so they would. There's very little incentive to replace it. For the few things that need more than it provides (like Nmap), WinPcap seems to be what's popular.