5 Ways to Improve your Wireless Network
While installing a wireless network may seem trendy, it makes good business sense. You have the flexibility and convenience of working untethered, plus you won't have to pay someone to come in and reroute network cables if you hire new employees or reconfigure your office floor plan.
Setting up a wireless network requires thought and planning. We spoke with Doug Potts, a security specialist at CDW, to find out what you can do to ensure their network works as smoothly and as securely as possible. The five steps to improving your wireless network are listed in order of their cost and complexity. Whether you take one or all five depends on the size of your budget and the level of security you need.
1. Set Up Wireless Encryption
Encrypting your network makes it difficult for hackers to crack in and use your wireless connection, access your data or other perform other malicious actions. "Encryption's an effective hacker deterrent," said Potts. "The thought of trying to hack a 128-bit or 256-bit cipher is enough to send a hacker packing — and looking for an easier target."
You have two types of encryption from which to choose: WEP and WPA with AES encryption. Potts likened 128-bit WEP encryption to a barking dog that frightens off a burglar. "Now AES, that's 256-bit — an even tougher type of encryption," Potts said. "That's like having the dog, an alarm system and a guard out front."
According to Potts, the 128-bit WEP encryption can be cracked, but it can take up to four hours of work to do it To date, he says, 256-bit AES has never been cracked.
Most wireless access points (APs) support both WEP and WPA standards, but not all client cards (the Wi-Fi card that plugs into your laptop) support AES encryption, which requires a dedicated chip.
"At the very minimum," said Potts, "everyone running a wireless network should have WEP installed and turned on."
Typically you'll pay about $50 to $100 more for an AP that supports AES. Potts says that if you're installing a wireless network for the first time, it's a good idea to invest in the security features that WPA offers. If you already have a wireless network, Potts recommends upgrading all of your APs to WPA over time as your budget allows.
2. Stick With the Same Vendor
Buying your APs and Wi-Fi cards from the same vendor increases your network performance and reduces compatibility issues, since not all vendors support the same features. Potts sited a feature called "Turbo mode" as an example.
"Some manufacturers build a Turbo mode into their APs and Wi-Fi cards," he said. "It's supposed to double your network throughput, but it only works if all your cards come from the same vendor. It could even be available only on a specific card within a vendor's line."
Potts continued, "D-Link has an AP and a Wi-Fi card that are specific to the Turbo mode feature. The company makes lots of cards and APs, but not all of them support that feature. This is true of most vendors," Potts said.
3. Do a Site Survey
Potts likes to ask his customers a question — Do you know where your wireless signal is? Unless you know exactly how far your wireless network reaches, and in what directions it travels, chances are you're leaking a Wi-Fi signal that anyone with a laptop and a Wi-Fi card — including hackers — can use for free.
"A site survey will tell you exactly how far your signal reaches," said Potts. "Take your laptop and Wi-Fi card and call up the utility that measures signal strength, [each maker has it's own — Cisco's is called ACU] and walk around your office with the utility running. That will tell you how far the signal reaches and the signals strength," said Potts. There's also lots of software that can help you do site surveys, such as the programs from Wireless Valley.
"If the signal's strong throughout the office, then go outside and keep walking around to see how far it leaks," he said. "I work on the fifth floor of a building in downtown Chicago, and when I'm in my office and I turn on my laptop, I can access the unprotected network from the coffee shop on the first floor."
Small businesses need to be aware that their network's AP signal could be traveling further than they want and creating a potential security breach. Potts pointed out that encryption offers a good deal of protection, but the longer someone has access to your network, the greater the chance they can crack it.
"Remember WEP encryption can be cracked," [argh] said Potts. "If your signal leaks out into the parking lot, you're giving someone the time and opportunity to hack you. If the signal's contained to your office, you significantly reduce the likelihood of an outside attack."
4. Place Your Wireless Network on Its own VLAN
Potts explained that a VLAN, or Virtual Local Area Network, is a way of segmenting your network so that employees can access only the job-related resources they need without having access to the entire network.
"Not everyone needs to know everything," said Potts "This is a way to add a layer of internal data protection to your business." This is a somewhat more costly addition to a wireless network, but a good option if your business requires compliance with HIPAA or other types of state and federal regulations or you want to make sure that your personnel or other backend data isn't readily accessible.
Potts pointed out that high-end equipment manufacturers typically support VLAN capability. "You'll find VLAN in Cisco, Proxim and 3Com products," said Potts, "but not in Linksys, D-Link or NetGear."
5. Set Up a Secondary Authentication Mechanism
Authentication is a way that people can prove they are who they say they are in order to access a network or any secure area. The most common authentication method is the user name and password. Potts said that companies that deal with highly sensitive data might want to consider adding a second method on top of the type they currently employ.
"Of these five steps, this is the most expensive option," he said. "A company would need to invest in a RADIUS server, which can range anywhere from $3,000 to $8,000 dollars depending on the size of the company."
However, a number of low cost solutions for small businesses exist to help them use authentication servers that utilize the protocol called 802.1X. They include software packages like LucidLink or Elektron that runs on a local computer to turn it into a RADIUS authentication server, or hosted RADIUS like WSC Guard or WiTopia.net.
Monday, January 11
How To Crack WEP and WPA Wireless Networks
How To Crack WEP and WPA Wireless Networks
Cracking WEP, WPA-PSK and WPA2-PSK wireless security using aircrack-ng
Introduction
With the popularity of wireless networks and mobile computing, an overall understanding of common security issues has become not only relevant, but very necessary for both home/SOHO users and IT professionals alike. This article is aimed at illustrating current security flaws in WEP/WPA/WPA2.
Successfully cracking a wireless network assumes some basic familiarity with networking principles and terminology, as well as working with command-line tools. A basic familiarity with Linux can be helpful as well.
Disclaimer: Attempting to access a network other than your own, or one you have permission to use is illegal insome U.S. jurisdictions. Speed Guide, Inc. are not to be held liable for any damages resulting from the use or misuse of the information in this article.
To successfully crack WEP/WPA, you first need to be able to set your wireless network card in "monitor" mode to passively capture packets without being associated with a network. This NIC mode is driver-dependent, and only a relatively small number of network cards support this mode under Windows.
One of the best free utilities for monitoring wireless traffic and cracking WEP/WPA-PSK keys is the aircrack-ng suite, which we will use throughout this article. It has both Linux and Windows versions (provided your network card is supported under Windows). The aircrack-ng site has a comprehensive list of supported network cards available here: NIC chipset compatability list.
If your network card is not supported under Windows, one can use a free Linux Live CD to boot the system. BackTrack 3 is probably the most commonly used distribution, since it runs from a Live CD, and has aircrack-ng and a number of related tools already installed.
For this article, I am using aircrack-ng version 1.0 on a Linux partition (Fedora Core 10, 2.6 32-bit kernel) on my Sony Vaio SZ-680 laptop, using the built-in Intel 4965agn network card. If you're using the BackTrack 3 CD aircrack-ng is already installed, with my version of linux it was as simple as finding it with:
yum search aircrack-ng
yum install aircrack-ng
The aircrack-ng suite is a collection of command-line programs aimed at WEP and WPA-PSK key cracking. The ones we will be using are:
airmon-ng - script used for switching the wireless network card to monitor mode
airodump-ng - for WLAN monitoring and capturing network packets
aireplay-ng - used to generate additional traffic on the wireless network
aircrack-ng - used to recover the WEP key, or launch a dictionary attack on WPA-PSK using the captured data.
1. Setup (airmon-ng)
As mentioned above, to capture network traffic wihtout being associated with an access point, we need to set the wireless network card in monitor mode. To do that under linux, in a terminal window (logged in as root), type:
iwconfig (to find all wireless network interfaces and their status)
airmon-ng start wlan0 (to set in monitor mode, you may have to substitute wlan0 for your own interface name)
Note: You can use the su command to switch to a root account.
Other related Linux commands:
ifconfig (to list available network interfaces, my network card is listed as wlan0)
ifconfig wlan0 down (to stop the specified network card)
ifconfig wlan0 hw ether 00:11:22:33:44:55 (change the MAC address of a NIC - can even simulate the MAC of an associated client. NIC should be stopped before chaning MAC address)
iwconfig wlan0 mode monitor (to set the network card in monitor mode)
ifconfig wlan0 up (to start the network card)
iwconfig - similar to ifconfig, but dedicated to the wireless interfaces.
2. Recon Stage (airodump-ng)
This step assumes you've already set your wireless network interface in monitor mode. It can be checked by executing the iwconfig command. Next step is finding available wireless networks, and choosing your target:
airodump-ng mon0 - monitors all channels, listing available access points and associated clients within range. It is best to select a target network with strong signal (PWR column), more traffic (Beacons/Data columns) and associated clients (listed below all access points). Once you've selected a target, note its Channel and BSSID (MAC address). Also note any STATION associated with the same BSSID (client MAC addresses).
running airodump-ng displays all wireless access points and associated clients in range, as well as MAC addresses, SSIDs, signal levels and other information about them.
WEP is much easier to crack than WPA-PSK, as it only requires data capturing (between 20k and 40k packets), while WPA-PSK needs a dictionary attack on a captured handshake between the access point and an associated client which may or may not work.
3. Capture Data (airodump-ng)
To capture data into a file, we use the airodump-ng tool again, with some additional switches to target a specific AP and channel. Most importantly, you should restrict monitoring to a single channel to speed up data collection, otherwise the wireless card has to alternate between all channels. Assuming our wireless card is mon0, and we want to capture packets on channel 6 into a text file called data:
airodump-ng -c 6 bssid 00:0F:CC:7D:5A:74 -w data mon0 (-c6 switch would capture data on channel 6, bssid 00:0F:CC:7D:5A:74 is the MAC address of our target access point, -w data specifies that we want to save captured packets into a file called "data" in the current directory, mon0 is our wireless network adapter)
Running airodump-ng on a single channel targeting a specific access point
Notes:
You typically need between 20,000 and 40,000 data packets to successfully recover a WEP key.
One can also use the "--ivs" switch with the airodump-ng command to capture only IVs, instead of whole packets, reducing the required disk space. However, this switch can only be used if targeting a WEP network, and renders some types of attacks useless.
4. Increase Traffic (aireplay-ng) - optional step for WEP cracking
An active network can usually be penetrated within a few minutes. However, slow networks can take hours, even days to collect enough data for recovering the WEP key.
This optional step allows a compatible network interface to inject/generate packets to increase traffic on the wireless network, therefore greatly reducing the time required for capturing data. The aireplay-ng command should be executed in a separate terminal window, concurrent to airodump-ng. It requires a compatible network card and driver that allows for injection mode.
Assuming your network card is capable of injecting packets, in a separate terminal window try:
aireplay-ng -3 -b 00:0F:CC:7D:5A:74 -h 00:14:A5:2F:A7:DE -x 50 wlan0
-3 --> this specifies the type of attack, in our case ARP-request replay
-b ..... --> MAC address of access point
-h ..... --> MAC address of associated client from airodump
-x 50 --> limit to sending 50 packets per second
wlan0 --> our wireless network interface
aireplay-ng allows for injecting packets to greatly reduce the time required to recover a WEP key
Notes:
To test whether your nic is able to inject packets, you may want to try: aireplay-ng -9 wlan0. You may also want to read the information available -here-.
To see all available replay attacks, type just: aireplay-ng
5. Crack WEP (aircrack-ng)
WEP cracking is a simple process, only requiring collection of enough data to then extract the key and connect to the network. You can crack the WEP key while capturing data. In fact, aircrack-ng will re-attempt cracking the key after every 5000 packets.
To attempt recovering the WEP key, in a new terminal window, type:
aircrack-ng data*.cap (assuming your capture file is called data...cap, and is located in the same directory)
aircrack-ng can successfully recover a WEP key with 10-40k captured packets. The retreived key is in hexadecimal, and can be entered directly into a wireless client omitting the ":" separators
Notes:
If your data file contains ivs/packets from different access points, you may be presented with a list to choose which one to recover.
Usually, between 20k and 40k packets are needed to successfully crack a WEP key. It may sometimes work with as few as 10,000 packets.
6. Crack WPA or WPA2 PSK (aircrack-ng)
WPA, unlike WEP rotates the network key on a per-packet basis, rendering the WEP method of penetration useless. Cracking a WPA-PSK/WPA2-PSK key requires a dictionary attack on a handshake between an access point and a client. What this means is, you need to wait until a wireless client associates with the network (or deassociate an already connected client so they automatically reconnect). All that needs to be captured is the initial "four-way-handshake" association between the access point and a client. WPA hashes the network key using the wireless access point's SSID as salt. This prevents the statistical key-grabbing techniques that broke WEP, and makes hash precomputation more dificult because the specific SSID needs to be added as salt for the hash.
With all that said, the weakness of WPA-PSK comes down to the passphrase. A short/weak passphrase makes it vulnerable to dictionary attacks.
To successfully crack a WPA-PSK network, you first need a capture file containing handshake data. This can be obtained using the same technique as with WEP in step 3 above, using airodump-ng.
You may also try to deauthenticate an associated client to speed up this process of capturing a handshake, using:
aireplay-ng --deauth 3 -a MAC_AP -c MAC_Client (where MAC_IP is the MAC address of the access point, and MAC_Client is the MAC address of an associated client).
Once you have captured a four-way handshake, you also need a large/relevant dictinary file with common passphrases. See related links below for some wordlist links.
You can, then execute the following command in a linux terminal window (assuming both the dictionary file and captured data file are in the same directory):
aircrack-ng -w dictionary_file capture_file
Notes:
Cracking WPA-PSK and WPA2-PSK may take much longer, and will only succeed with weak passphrases and good dictionary files.
Alternatively, there are tools like coWPAtty that can use precomputed hash files to speed up dictionary attacks. Those hash files can be very effective, but quite big in size. The Church of WiFi has computed hash tables for the 1000 most common SSIDs against a million common passphrases that are 7Gb and 33Gb in size...
Conclusion
As demonstrated above, WEP cracking has become increasingly easier over the years, and what used to take hundreds of thousands packets and days of capturing data can be accomplished today within 15 minutes with a mere 20k data frames.
Cracking WEP, WPA-PSK and WPA2-PSK wireless security using aircrack-ng
Introduction
With the popularity of wireless networks and mobile computing, an overall understanding of common security issues has become not only relevant, but very necessary for both home/SOHO users and IT professionals alike. This article is aimed at illustrating current security flaws in WEP/WPA/WPA2.
Successfully cracking a wireless network assumes some basic familiarity with networking principles and terminology, as well as working with command-line tools. A basic familiarity with Linux can be helpful as well.
Disclaimer: Attempting to access a network other than your own, or one you have permission to use is illegal insome U.S. jurisdictions. Speed Guide, Inc. are not to be held liable for any damages resulting from the use or misuse of the information in this article.
To successfully crack WEP/WPA, you first need to be able to set your wireless network card in "monitor" mode to passively capture packets without being associated with a network. This NIC mode is driver-dependent, and only a relatively small number of network cards support this mode under Windows.
One of the best free utilities for monitoring wireless traffic and cracking WEP/WPA-PSK keys is the aircrack-ng suite, which we will use throughout this article. It has both Linux and Windows versions (provided your network card is supported under Windows). The aircrack-ng site has a comprehensive list of supported network cards available here: NIC chipset compatability list.
If your network card is not supported under Windows, one can use a free Linux Live CD to boot the system. BackTrack 3 is probably the most commonly used distribution, since it runs from a Live CD, and has aircrack-ng and a number of related tools already installed.
For this article, I am using aircrack-ng version 1.0 on a Linux partition (Fedora Core 10, 2.6 32-bit kernel) on my Sony Vaio SZ-680 laptop, using the built-in Intel 4965agn network card. If you're using the BackTrack 3 CD aircrack-ng is already installed, with my version of linux it was as simple as finding it with:
yum search aircrack-ng
yum install aircrack-ng
The aircrack-ng suite is a collection of command-line programs aimed at WEP and WPA-PSK key cracking. The ones we will be using are:
airmon-ng - script used for switching the wireless network card to monitor mode
airodump-ng - for WLAN monitoring and capturing network packets
aireplay-ng - used to generate additional traffic on the wireless network
aircrack-ng - used to recover the WEP key, or launch a dictionary attack on WPA-PSK using the captured data.
1. Setup (airmon-ng)
As mentioned above, to capture network traffic wihtout being associated with an access point, we need to set the wireless network card in monitor mode. To do that under linux, in a terminal window (logged in as root), type:
iwconfig (to find all wireless network interfaces and their status)
airmon-ng start wlan0 (to set in monitor mode, you may have to substitute wlan0 for your own interface name)
Note: You can use the su command to switch to a root account.
Other related Linux commands:
ifconfig (to list available network interfaces, my network card is listed as wlan0)
ifconfig wlan0 down (to stop the specified network card)
ifconfig wlan0 hw ether 00:11:22:33:44:55 (change the MAC address of a NIC - can even simulate the MAC of an associated client. NIC should be stopped before chaning MAC address)
iwconfig wlan0 mode monitor (to set the network card in monitor mode)
ifconfig wlan0 up (to start the network card)
iwconfig - similar to ifconfig, but dedicated to the wireless interfaces.
2. Recon Stage (airodump-ng)
This step assumes you've already set your wireless network interface in monitor mode. It can be checked by executing the iwconfig command. Next step is finding available wireless networks, and choosing your target:
airodump-ng mon0 - monitors all channels, listing available access points and associated clients within range. It is best to select a target network with strong signal (PWR column), more traffic (Beacons/Data columns) and associated clients (listed below all access points). Once you've selected a target, note its Channel and BSSID (MAC address). Also note any STATION associated with the same BSSID (client MAC addresses).
running airodump-ng displays all wireless access points and associated clients in range, as well as MAC addresses, SSIDs, signal levels and other information about them.
WEP is much easier to crack than WPA-PSK, as it only requires data capturing (between 20k and 40k packets), while WPA-PSK needs a dictionary attack on a captured handshake between the access point and an associated client which may or may not work.
3. Capture Data (airodump-ng)
To capture data into a file, we use the airodump-ng tool again, with some additional switches to target a specific AP and channel. Most importantly, you should restrict monitoring to a single channel to speed up data collection, otherwise the wireless card has to alternate between all channels. Assuming our wireless card is mon0, and we want to capture packets on channel 6 into a text file called data:
airodump-ng -c 6 bssid 00:0F:CC:7D:5A:74 -w data mon0 (-c6 switch would capture data on channel 6, bssid 00:0F:CC:7D:5A:74 is the MAC address of our target access point, -w data specifies that we want to save captured packets into a file called "data" in the current directory, mon0 is our wireless network adapter)
Running airodump-ng on a single channel targeting a specific access point
Notes:
You typically need between 20,000 and 40,000 data packets to successfully recover a WEP key.
One can also use the "--ivs" switch with the airodump-ng command to capture only IVs, instead of whole packets, reducing the required disk space. However, this switch can only be used if targeting a WEP network, and renders some types of attacks useless.
4. Increase Traffic (aireplay-ng) - optional step for WEP cracking
An active network can usually be penetrated within a few minutes. However, slow networks can take hours, even days to collect enough data for recovering the WEP key.
This optional step allows a compatible network interface to inject/generate packets to increase traffic on the wireless network, therefore greatly reducing the time required for capturing data. The aireplay-ng command should be executed in a separate terminal window, concurrent to airodump-ng. It requires a compatible network card and driver that allows for injection mode.
Assuming your network card is capable of injecting packets, in a separate terminal window try:
aireplay-ng -3 -b 00:0F:CC:7D:5A:74 -h 00:14:A5:2F:A7:DE -x 50 wlan0
-3 --> this specifies the type of attack, in our case ARP-request replay
-b ..... --> MAC address of access point
-h ..... --> MAC address of associated client from airodump
-x 50 --> limit to sending 50 packets per second
wlan0 --> our wireless network interface
aireplay-ng allows for injecting packets to greatly reduce the time required to recover a WEP key
Notes:
To test whether your nic is able to inject packets, you may want to try: aireplay-ng -9 wlan0. You may also want to read the information available -here-.
To see all available replay attacks, type just: aireplay-ng
5. Crack WEP (aircrack-ng)
WEP cracking is a simple process, only requiring collection of enough data to then extract the key and connect to the network. You can crack the WEP key while capturing data. In fact, aircrack-ng will re-attempt cracking the key after every 5000 packets.
To attempt recovering the WEP key, in a new terminal window, type:
aircrack-ng data*.cap (assuming your capture file is called data...cap, and is located in the same directory)
aircrack-ng can successfully recover a WEP key with 10-40k captured packets. The retreived key is in hexadecimal, and can be entered directly into a wireless client omitting the ":" separators
Notes:
If your data file contains ivs/packets from different access points, you may be presented with a list to choose which one to recover.
Usually, between 20k and 40k packets are needed to successfully crack a WEP key. It may sometimes work with as few as 10,000 packets.
6. Crack WPA or WPA2 PSK (aircrack-ng)
WPA, unlike WEP rotates the network key on a per-packet basis, rendering the WEP method of penetration useless. Cracking a WPA-PSK/WPA2-PSK key requires a dictionary attack on a handshake between an access point and a client. What this means is, you need to wait until a wireless client associates with the network (or deassociate an already connected client so they automatically reconnect). All that needs to be captured is the initial "four-way-handshake" association between the access point and a client. WPA hashes the network key using the wireless access point's SSID as salt. This prevents the statistical key-grabbing techniques that broke WEP, and makes hash precomputation more dificult because the specific SSID needs to be added as salt for the hash.
With all that said, the weakness of WPA-PSK comes down to the passphrase. A short/weak passphrase makes it vulnerable to dictionary attacks.
To successfully crack a WPA-PSK network, you first need a capture file containing handshake data. This can be obtained using the same technique as with WEP in step 3 above, using airodump-ng.
You may also try to deauthenticate an associated client to speed up this process of capturing a handshake, using:
aireplay-ng --deauth 3 -a MAC_AP -c MAC_Client (where MAC_IP is the MAC address of the access point, and MAC_Client is the MAC address of an associated client).
Once you have captured a four-way handshake, you also need a large/relevant dictinary file with common passphrases. See related links below for some wordlist links.
You can, then execute the following command in a linux terminal window (assuming both the dictionary file and captured data file are in the same directory):
aircrack-ng -w dictionary_file capture_file
Notes:
Cracking WPA-PSK and WPA2-PSK may take much longer, and will only succeed with weak passphrases and good dictionary files.
Alternatively, there are tools like coWPAtty that can use precomputed hash files to speed up dictionary attacks. Those hash files can be very effective, but quite big in size. The Church of WiFi has computed hash tables for the 1000 most common SSIDs against a million common passphrases that are 7Gb and 33Gb in size...
Conclusion
As demonstrated above, WEP cracking has become increasingly easier over the years, and what used to take hundreds of thousands packets and days of capturing data can be accomplished today within 15 minutes with a mere 20k data frames.
Thursday, January 7
Windows 7 Tweaks for better broad band internet connection
Windows 7, Vista, 2008 Tweaks
Tweaking Windows 7 / Vista TCP/IP settings for broadband internet connections
2008.04.24 10:40 by Philip
Keywords: patch, Nagle, QoS, SynAttackProtect, DNS, DefaultTTL, NetDMA, TCP 1323 Options, MTU, auto-tunning, Compound TCP, Chimney Offload, CTCP, TCP Window, Registry, TCP/IP, tweak, Vista, Windows 7
Windows Vista introduces a number of new features to the TCP/IP stack, including CTCP, and TCP Window Auto-Tuning. This new implementation works much better by default than previous Windows versions with broadband internet connections, and is able to adjust the RWIN value on the fly, depending on the BDP (bandwidth-delay product). This, however, introduces some problems with older routers and restricts the user from tweaking some of the TCP/IP parameters. Still, there is always some room for improvement, and this article explains the known tweakable TCP/IP parameters.
To enter some of the commands below, you will need to run "elevated" command prompt. To do so, click the Start icon > Run > type: cmd , then click CTRL+SHIFT+ENTER. Alternatively, you can navigate to Start > All Programs > Accessories > right-click Command Prompt and choose "Run as Administrator".
Check the TCP/IP state
To check the current status of the Vista TCP/IP tweakable parameters, in elevated command prompt type the following command:
netsh int tcp show global
You will be presented with something like the following:
The settings, as well as their default and recommended state are explained below. The two most important tweakable parameters are "Auto-Tuning Level" and "Congestion Control Provider".
When checking the TCP state with the "netsh int tcp show global" command, it is also possible to see the following message below all those parameters:
** The above autotuninglevel setting is the result of Windows Scaling heuristics overriding any local/policy configuration on at least one profile.
It is displayed when the "Receive Window Auto-Tuning Level" is not explicitly set, or if the system deemed it necessary to make a change because of user prompted "repairing" of your network connection, for example.
TCP Auto-Tuning
To turn off the default RWIN auto tuning behavior, (in elevated command prompt) type:
netsh int tcp set global autotuninglevel=disabled
The default auto-tuning level is "normal", and the possible settings for the above command are:
disabled: uses a fixed value for the tcp receive window. Limits it to 64KB (limited at 65535).
higlyrestricted: allows the receive window to grow beyond its default value, very conservatively
restricted: somewhat restricted growth of the tcp receive window beyond its default value
normal: default value, allows the receive window to grow to accommodate most conditions
experimental: allows the receive window to grow to accommodate extreme scenarios (not recommended, it can degrade performance in common scenarios, only intended for research purposes. It enables RWIN values of over 16 MB)
Our recommendation: normal (unless you're experiencing problems).
If you're experiencing problems with your NAT router or SPI firewall, try the "restricted", "highlyrestricted", or even "disabled" state.
Notes:
- Reportedly, some older residential NAT routers with a SPI firewall may have problems with enabled tcp auto-tuning in it's "normal" state, resulting in slow speeds, packet loss, reduced network performance in general.
- auto-tuning also causes problems with really old routers that do not support TCP Windows scaling. See MSKB 935400
- netsh set commands take effect immediately after executing, there is no need to reboot.
- sometimes when using "normal" mode and long lasting connections (p2p software / torrents), tcp windows can get very large and consume too much resources, if you're experiencing problems try a more conservative (restricted) setting.
If you're experiencing problems with Auto-Tuning, see also:
MS KB 835400 - email issues
MS KB 934430 - network connectivity behind firewall problems
MS KB 940646 - 3G WWAN throughput issues
MS KB 929868 - web browsing issues
MS KB 932170 - slow network file transfer
Compound TCP - Improve throughput
Add-On Congestion Control Provider
The traditional slow-start and congestion avoidance algorithms in TCP help avoid network congestion by gradually increasing the TCP window at the beginning of transfers until the TCP Receive Window boundary is reached, or packet loss occurs. For broadband internet connections that combine high TCP Window with higher latency (high BDP), these algorithms do not increase the TCP windows fast enough to fully utilize the bandwidth of the connection.
Compound TCP (CTCP) is a newer method, available in Vista and Server 2008 (there is also a hotfix available for XP/2003). CTCP increases the TCP send window more aggressively for broadband connections (with large RWIN and BDP). CTCP attempts to maximize throughput by monitoring delay variations and packet loss. It also ensures that its behavior does not impact other TCP connections negatively.
By default, Vista has CTCP turned off, and Server 2008 turned on. Turning this option on can significantly increase throughput.
To enable CTCP, in elevated command prompt type:
netsh int tcp set global congestionprovider=ctcp
To disable CTCP:
netsh int tcp set global congestionprovider=none
Possible options are: ctcp, none, default (restores the system default value).
Recommended setting: ctcp
It is better to use this newer generation CTCP congestion control algorithm for most broadband connections, we highly recommend it being turned on.
ECN Capability
ECN (Explicit Congestion Notification, RFC 3168) is a mechanism that provides routers with an alternate method of communicating network congestion. It is aimed to decrease retransmissions. In essence, ECN assumes that the cause of any packet loss is router congestion. It allows routers experiencing congestion to mark packets and allow clients to automatically lower their transfer rate to prevent further packet loss. Traditionally, TCP/IP networks signal congestion by dropping packets. When ECN is successfully negotiated, an ECN-aware router may set a bit in the IP header (in the DiffServ field) instead of dropping a packet in order to signal congestion. The receiver echoes the congestion indication to the sender, which must react as though a packet drop were detected.
ECN is disabled by default in Vista and other modern TCP/IP implementations, as it is possible that it may cause problems with some outdated routers that drop packets with the ECN bit set, rather than ignoring the bit. To check whether your router supports ECN, you can use the Microsoft Internet Connectivity Evaluation Tool. The results will be displayed under "Traffic Congestion Test".
To enable ECN, in elevated command prompt type:
netsh int tcp set global ecncapability=enabled
Possible settings are: enabled, disabled, default (restores the state to the system default).
The default state is: disabled
Recommendation: enabled (only for short-lived, interactive connections and HTTP requests with routers that support it, in the presense of congestion/packet loss), disabled otherwise (for pure bulk throughput with large TCP Window, no regular congestion/packet loss, or outdated routers without ECN support).
Notes: ECN is only effective in combination with AQM (Active Queue Management) router policy. It has more noticeable effect on performance with interactive connections and HTTP requests, in the presense of router congestion/packet loss. Its effect on bulk throughput with large TCP Window are less clear.
More information on ECN: Explicit Congestion Notification (ECN) for TCP/IP
RSS - Receive-side Scaling
The receive-side scaling setting enables parallelized processing of received packets on multiple processors, while avoiding packet reordering. It avoids packet reordering y separating packets into "flows", and using a single processor for processing all the packets for a given flow. Packets are separated into flows by computing a hash value based on specific fields in each packet, and the resulting hash values are used to select a processor for processing the flow. This approach ensures that all packets belonging to a given TCP connection will be queued to the same processor, in the same order that they were received by the network adapter.
To set RSS:
netsh int tcp set global rss=enabled
Possible rss settings are: disabled, enabled, default (restores rss state to the system default).
Default state is: enabled
Recommended: enabled (if you have 2 or more processor cores and a NIC that can handle RSS)
TCP Chimney Offload
TCP chimney offload enables Windows to offload all TCP processing for a connection to a network adapter. Offloads are initiated on a per-connection basis. Compared to task offload, TCP chimney offload further reduces networking-related CPU overhead, enabling better overall system performance by freeing up CPU time for other tasks.
To set TCP Chimney Offload:
netsh int tcp set global chimney=enabled
Default state: enabled (under Vista), automatic (under Windows 7 and 2008 Server)
Recommended: enabled (under Vista), automatic (under Windows 7 and 2008 Server)
The possible states are disabled, enabled, default (Vista), automatic (only Windows 7 and 2008 Server) as follows:
automatic - This default setting is only available under Windows 7 and 2008 Server, it is not available udner Vista. It offloads if the connection is 10 GbE, has a RTT < 20ms, and the connection has exchanged at least 130KB of data. The device driver must also have TCP Chimney enabled.
default - this setting restores chimney offload to the system default. Setting this "default" state under Windows 7 and 2008 Server is possible, but it sets the system to the "automatic" mode described above.
disabled - this setting is maually configured as disabled.
enabled - this setting is manually configured as enabled.
Notes:
Under Windows 7 and Server 2008 the "default" and the additional "automatic" parameter set the system to the same "automatic" state.
For Chimney Offload to work, it needs to be enabled in both the OS and NIC. To enable the "TCP Offloading" setting in your NIC, navigate to the Device Manager, under Network Adapters, in the Advanced tab, and check "Enabled" in the box next to the TCP offload entry.
Direct Cache Access (DCA)
Windows 7 and 2008 Server (but not Vista) add NETDMA 2.0 Direct cache access support. Direct Cache Access (DCA) allows a capable I/O device, such as a network controller, to deliver data directly into a CPU cache. The objective of DCA is to reduce memory latency and the memory bandwidth requirement in high bandwidth (Gigabit) environments. DCA requires support from the I/O device, system chipset, and CPUs.
To enable DCA:
netsh int tcp set global dca=enabled
Available states are: enabled, disabled.
Default state: disabled
Recommended: enabled (provided the CPU/MoBo/NIC support it)
It is also possible to enable this setting by editing the Windows Registry instead of using netsh as follows:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
EnableDCA=1 (DWORD, entry does not exist by default. Set to 1 to enable, 0 to disable)
Setting MTU
It is sometimes useful to view and set the MTU value for a specific network interface manually. To view a list of active network interfaces and their MTU values in Vista using netsh, open command prompt as administrator and execute the following command:
netsh interface ipv4 show subinterface
You will be presented with a list of interfaces, and their respective MTU values as follows:
To change the MTU value of a specific network card, type the following in command prompt:
netsh interface ipv4 set subinterface "network interface name" mtu=#### store=persistent
Where "network interface name" is your specific network adapter name as obtained above (or viewable under Network adapters), and mtu=#### is the desired MTU value.
For example, if the name of your network card is "Wireless Network Connection" and you'd like to set its MTU to 1500, you'd have to type:
netsh interface ipv4 set subinterface "Wireless Network Connection" mtu=1500 store=persistent
Note: The maximum MTU value is usually 1500, and up to 1492 for PPPoE connections.
Manually tuning Registry Parameters
Many of the registry keys tuning TCP/IP parameters from previous Windows versions no longer work in Vista and Server 2008. Below is a list of the few we've confirmed to still work. Note that for changes to these settings to take effect the computer needs to be rebooted. As always, a registry backup is recommended if making any changes, and some proficiency in using regedit is required.
In regedit (Start icon > Run > type: regedit while logged in as administrator), you can navigate and edit the following keys.
MTU (Maximum Transmission Unit) - the maximum packet size.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{...}\
MTU=1500 (DWORD, entry does not exist by default)
The {....} part of the above path is the unique identifier of your network adapter. You can recognize the correct adapter by looking at it's IP address, if obtaining IP automatically labeled by: DhcpIPAddress=192.168.x.x text value, for example.
We recommend leaving this at default, unless you want to lower it. Vista uses the largest possible packet size for the underlying network by default.
Note: In some test environments, the correct MTU entry may be offset by 8. The 8 offset seems to coincide with the size of the PPPoE overhead. Check the result with the TCP Analyzer.
TCP 1323 Options
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\
Tcp1323Opts=1 (DWORD, entry created automatically by Windows when you run the "netsh int tcp set global autotuninglvl=..." command, set to 0 by default).
Setting this seems to have no effect, since auto-tuning uses the TCP 1323 scale factor and changes it on the fly, disregarding this setting. Additional testing may be required to determine it's effect if auto-tuning is turned off. Setting it to 1 is best for broadband connections.
NetDMA
NetDMA enables support for advanced direct memory access. In essence, it provides the ability to more efficiently move network data by minimizing CPU usage. NetDMA frees the CPU from handling memory data transfers between network card data buffers and application buffers by using a DMA engine.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
EnableTCPA=1 (DWORD, 1 to enable, 0 to disable NetDMA. Value not present by default in Vista)
Recommended setting is 1, a new DWORD value may need to be created if not already present in the registry.
DefaultTTL
TTL can be safely left alone in many cases. It is a limit to the time and number of hops/routers a packet will travel before being discarded. A number that's too small risks packets being discarded before reaching their destination. A number that's too large (over 128) will cause delay in when lost IP packets are discarded.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
DefaultTTL=64 (DWORD, set to a decimal value between 32 and 128. Recommended: 64)
TcpMaxDataRetransmissions
Determines how many times unacknowledged data (non-connect segment) is retransmitted before TCP aborts the connection. The retransmission timeout is doubled with each successive retransmission on a connection. It is reset when responses resume.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
TCPMaxDataRetransmissions=7 (DWORD, recommended: between 3 and 10, default registry value 255, default 5 in documentation)
SynAttackProtect
This undocumented setting provides protection against SYN denial of service (DoS) attacks. When enabled, connections timeout sooner if SYN attack is detected. When set at 1, TCPMaxDataRetransmissions can be lowered further.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
SynAttackProtect=1 (DWORD, recommended: 1, not present in registry by default)
Set DNS and Hosts Priority
As with previous versions of Windows, one can improve DNS and hostname resolution by increasing the priority of of related services, while keeping their order. This is explained in more defail in our Host Resolution article. Lower numbers mean higher process priority. The corresponding registry settings in Vista are as follows:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\ServiceProvider
LocalPriority=4 (DWORD, recommended: 4, default: 499) - local names cache
HostsPriority=5 (DWORD, recommended: 5, default: 500) - the HOSTS file
DnsPriority=6 (DWORD, recommended: 6, default: 2000) - DNS
NetbtPriority=7 (DWORD, recommended: 7, default: 2001) - NetBT name resolution, including WINS
TcpTimedWaitDelay (port allocation)
Short lived (ephemeral) TCP/IP ports above 1024 are allocated as needed by the OS. The default Vista values have improved from previous Windows versions, and are usually sufficient under normal load. However, in some instances under heavy load it it may be necessary to adjust the settings below to tweak the availability of user ports requested by an application.
If the default limits are exceeded under heavy loads, the following error may be observed: "address in use: connect exception". By default under Vista (when the values are not presend in the registry), the OS can allocate up to 16384 ephemeral ports above port 1024, and the OS waits for 120 seconds before reclaiming ports after an application closes the TCP connection. This is a considerable improvement over older Windows versions. However, if necessary, the following registry values can be added/edited:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
MaxUserPort=65535 (DWORD, not in the registry by default. Recommended: leave at default, or use a number above 16384 up to 65535 decimal as necessary) - maximum number of ports to use. 1024 is automatically subtracted from entered value to allow for reserved ports under 1024.
TcpTimedWaitDelay=30 (DWORD, 0xffffffff in registry by default. Recommended: 30 decimal, denoting 30 seconds) - time to wait before reclaiming ports, in seconds. Default time before reclaiming ports, if value is at 0xffffffff or not present in the registry is 120 seconds. Just reducing the delay is often sufficient without changing MaxUserPort, as it allows for reusing ports more efficiently.
Ephemeral ports can be checked and changed using netsh as well.
To query the current values, in command prompt, type:
netsh int ipv4 show dynamicportrange tcp (for UDP, use the same command, replacing only "tcp" with "udp" at the end)
To set both the starting, and max user port using netsh, in elevated command prompt run:
netsh int ipv4 set dynamicportrange protocol=tcp start=1025 num=64511 (start=NNN denoting the starting port, and num=NNN denoting the number of ports)
Notes:
By default, dynamic ports are allocated between ports 49152 and 65535 (for a total of 16384 ephemeral ports).
Using netsh allows to set both the starting port and port range. Editing the Registry allows for setting the port range, and the starting port is fixed at 1025. Deleting the MaxUserPort registry entry (or setting it to a value outside the allowed range) causes the OS to revert to using the default values.
Some system processes can install port filters to block certain port ranges. If ephemeral ports run into these filtered port ranges, TCP/IP applications will be unable to bind to any ports.
QoS Reserved Bandwidth
As with Windows XP, nework adapters have a "QoS Packet Scheduler" enabled by default, which reserves 20% of bandwidth by default for QoS applications that request priority traffic. Note this only has effect in the presence of running QoS applications that request priority traffic. Registry value is undocumented for the Vista version of Windows. To customize this setting, in the Windows Registry:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Psched
NonBestEffortLimit=0 (DWORD, not present in the registry by default. Recommended: 0 , possible values between 0 and 100) - indicates the percentage value of reserved bandwidth for QoS applications. Set to 0 to disable.
Notes: This tweak applies only to Windows versions that have Qos Packet Scheduler enabled. It will ONLY have effect in the presense of running QoS applications.
Gaming Tweak - Disable Nagle's algorithm
The tweak below allows for tweaking or disabling Nagle's alogrithm. Disabling "nagling" allows for very small packets to be transferred immediately without delay. Note that disabling Nagle's algorithm is only recommended for some games, and it may have negative impact on file transfers/throughput. The dafault state (Nagling enabled) improves performance by allowing several small packets to be combined together into a single, larger packet for more efficient transmission. While this improves overall performance and reduces TCP/IP overhead, it may briefly delay transmission of smaller packets. Keep in mind that disabling Nagle's algorithm may have some negative effect on file transfers, and can only help reduce delay in some games. To implement this tweak, in the registry editor (Start>Run>regedit) find:
This setting configures the maximum number of outstanding ACKs in Windows XP/2003/Vista/2008:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{NIC-id}
There will be multiple NIC interfaces listed there, for example: {1660430C-B14A-4AC2-8F83-B653E83E8297}. Find the correct one with your IP address listed. Under this {NIC-id} key, create a new DWORD value:
TcpAckFrequency=1 (DWORD value, 1=disable, 2=default, 2-n=send ACKs if outstanding ACKs before timed interval. Setting not present by default).
For gaming performance, recommended is 1 (disable). For pure throughput and data streaming, you can experiment with values over 2. If you try larger values, just make sure TcpAckFrequency*MTU is less than RWIN, since the sender may stop sending data if RWIN fills witout acknowledgement.
Also, find the following key (if present):
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSMQ\Parameters
Add a new DWORD value:
TCPNoDelay=1 (DWORD value, 0 to enable Nagle's algorithm, 1 to disable, not present by default)
To configure the ACK interval timeout (only has effect if nagling is enabled), find the following key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{NIC-id}
TcpDelAckTicks=0 (DWORD value, default=2, 0=disable nagling, 1-6=100-600 ms). Note you can also set this to 1 to reduce the nagle effect from the default of 200ms without disabling it.
Notes:
Reportedly, the above gaming tweak (disabling nagle's algorithm) can reduce WoW (World of Warcraft) latency by almost half!
XP/2003 needs hotfix or SP2 for it to work (MS KB 815230)
Vista needs hotfix or SP1 for it to work (MS KB 935458)
SG Vista TCP/IP Patch - automatic optimization
For user convenience, we also provide a quick way to apply all optimal values as recommended above using our SG Vista TCP/IP Patch. It allows for tweaking all the above netsh settings and registry values in one simple step (with the exception of the "gaming tweak" section). The patch also provides for easily reverting the settings to their Windows default values. To apply, save to your desktop and run as administrator (right-click -> run as administrator). Click Y when prompted to apply settings.
Tweaking Windows 7 / Vista TCP/IP settings for broadband internet connections
2008.04.24 10:40 by Philip
Keywords: patch, Nagle, QoS, SynAttackProtect, DNS, DefaultTTL, NetDMA, TCP 1323 Options, MTU, auto-tunning, Compound TCP, Chimney Offload, CTCP, TCP Window, Registry, TCP/IP, tweak, Vista, Windows 7
Windows Vista introduces a number of new features to the TCP/IP stack, including CTCP, and TCP Window Auto-Tuning. This new implementation works much better by default than previous Windows versions with broadband internet connections, and is able to adjust the RWIN value on the fly, depending on the BDP (bandwidth-delay product). This, however, introduces some problems with older routers and restricts the user from tweaking some of the TCP/IP parameters. Still, there is always some room for improvement, and this article explains the known tweakable TCP/IP parameters.
To enter some of the commands below, you will need to run "elevated" command prompt. To do so, click the Start icon > Run > type: cmd , then click CTRL+SHIFT+ENTER. Alternatively, you can navigate to Start > All Programs > Accessories > right-click Command Prompt and choose "Run as Administrator".
Check the TCP/IP state
To check the current status of the Vista TCP/IP tweakable parameters, in elevated command prompt type the following command:
netsh int tcp show global
You will be presented with something like the following:
The settings, as well as their default and recommended state are explained below. The two most important tweakable parameters are "Auto-Tuning Level" and "Congestion Control Provider".
When checking the TCP state with the "netsh int tcp show global" command, it is also possible to see the following message below all those parameters:
** The above autotuninglevel setting is the result of Windows Scaling heuristics overriding any local/policy configuration on at least one profile.
It is displayed when the "Receive Window Auto-Tuning Level" is not explicitly set, or if the system deemed it necessary to make a change because of user prompted "repairing" of your network connection, for example.
TCP Auto-Tuning
To turn off the default RWIN auto tuning behavior, (in elevated command prompt) type:
netsh int tcp set global autotuninglevel=disabled
The default auto-tuning level is "normal", and the possible settings for the above command are:
disabled: uses a fixed value for the tcp receive window. Limits it to 64KB (limited at 65535).
higlyrestricted: allows the receive window to grow beyond its default value, very conservatively
restricted: somewhat restricted growth of the tcp receive window beyond its default value
normal: default value, allows the receive window to grow to accommodate most conditions
experimental: allows the receive window to grow to accommodate extreme scenarios (not recommended, it can degrade performance in common scenarios, only intended for research purposes. It enables RWIN values of over 16 MB)
Our recommendation: normal (unless you're experiencing problems).
If you're experiencing problems with your NAT router or SPI firewall, try the "restricted", "highlyrestricted", or even "disabled" state.
Notes:
- Reportedly, some older residential NAT routers with a SPI firewall may have problems with enabled tcp auto-tuning in it's "normal" state, resulting in slow speeds, packet loss, reduced network performance in general.
- auto-tuning also causes problems with really old routers that do not support TCP Windows scaling. See MSKB 935400
- netsh set commands take effect immediately after executing, there is no need to reboot.
- sometimes when using "normal" mode and long lasting connections (p2p software / torrents), tcp windows can get very large and consume too much resources, if you're experiencing problems try a more conservative (restricted) setting.
If you're experiencing problems with Auto-Tuning, see also:
MS KB 835400 - email issues
MS KB 934430 - network connectivity behind firewall problems
MS KB 940646 - 3G WWAN throughput issues
MS KB 929868 - web browsing issues
MS KB 932170 - slow network file transfer
Compound TCP - Improve throughput
Add-On Congestion Control Provider
The traditional slow-start and congestion avoidance algorithms in TCP help avoid network congestion by gradually increasing the TCP window at the beginning of transfers until the TCP Receive Window boundary is reached, or packet loss occurs. For broadband internet connections that combine high TCP Window with higher latency (high BDP), these algorithms do not increase the TCP windows fast enough to fully utilize the bandwidth of the connection.
Compound TCP (CTCP) is a newer method, available in Vista and Server 2008 (there is also a hotfix available for XP/2003). CTCP increases the TCP send window more aggressively for broadband connections (with large RWIN and BDP). CTCP attempts to maximize throughput by monitoring delay variations and packet loss. It also ensures that its behavior does not impact other TCP connections negatively.
By default, Vista has CTCP turned off, and Server 2008 turned on. Turning this option on can significantly increase throughput.
To enable CTCP, in elevated command prompt type:
netsh int tcp set global congestionprovider=ctcp
To disable CTCP:
netsh int tcp set global congestionprovider=none
Possible options are: ctcp, none, default (restores the system default value).
Recommended setting: ctcp
It is better to use this newer generation CTCP congestion control algorithm for most broadband connections, we highly recommend it being turned on.
ECN Capability
ECN (Explicit Congestion Notification, RFC 3168) is a mechanism that provides routers with an alternate method of communicating network congestion. It is aimed to decrease retransmissions. In essence, ECN assumes that the cause of any packet loss is router congestion. It allows routers experiencing congestion to mark packets and allow clients to automatically lower their transfer rate to prevent further packet loss. Traditionally, TCP/IP networks signal congestion by dropping packets. When ECN is successfully negotiated, an ECN-aware router may set a bit in the IP header (in the DiffServ field) instead of dropping a packet in order to signal congestion. The receiver echoes the congestion indication to the sender, which must react as though a packet drop were detected.
ECN is disabled by default in Vista and other modern TCP/IP implementations, as it is possible that it may cause problems with some outdated routers that drop packets with the ECN bit set, rather than ignoring the bit. To check whether your router supports ECN, you can use the Microsoft Internet Connectivity Evaluation Tool. The results will be displayed under "Traffic Congestion Test".
To enable ECN, in elevated command prompt type:
netsh int tcp set global ecncapability=enabled
Possible settings are: enabled, disabled, default (restores the state to the system default).
The default state is: disabled
Recommendation: enabled (only for short-lived, interactive connections and HTTP requests with routers that support it, in the presense of congestion/packet loss), disabled otherwise (for pure bulk throughput with large TCP Window, no regular congestion/packet loss, or outdated routers without ECN support).
Notes: ECN is only effective in combination with AQM (Active Queue Management) router policy. It has more noticeable effect on performance with interactive connections and HTTP requests, in the presense of router congestion/packet loss. Its effect on bulk throughput with large TCP Window are less clear.
More information on ECN: Explicit Congestion Notification (ECN) for TCP/IP
RSS - Receive-side Scaling
The receive-side scaling setting enables parallelized processing of received packets on multiple processors, while avoiding packet reordering. It avoids packet reordering y separating packets into "flows", and using a single processor for processing all the packets for a given flow. Packets are separated into flows by computing a hash value based on specific fields in each packet, and the resulting hash values are used to select a processor for processing the flow. This approach ensures that all packets belonging to a given TCP connection will be queued to the same processor, in the same order that they were received by the network adapter.
To set RSS:
netsh int tcp set global rss=enabled
Possible rss settings are: disabled, enabled, default (restores rss state to the system default).
Default state is: enabled
Recommended: enabled (if you have 2 or more processor cores and a NIC that can handle RSS)
TCP Chimney Offload
TCP chimney offload enables Windows to offload all TCP processing for a connection to a network adapter. Offloads are initiated on a per-connection basis. Compared to task offload, TCP chimney offload further reduces networking-related CPU overhead, enabling better overall system performance by freeing up CPU time for other tasks.
To set TCP Chimney Offload:
netsh int tcp set global chimney=enabled
Default state: enabled (under Vista), automatic (under Windows 7 and 2008 Server)
Recommended: enabled (under Vista), automatic (under Windows 7 and 2008 Server)
The possible states are disabled, enabled, default (Vista), automatic (only Windows 7 and 2008 Server) as follows:
automatic - This default setting is only available under Windows 7 and 2008 Server, it is not available udner Vista. It offloads if the connection is 10 GbE, has a RTT < 20ms, and the connection has exchanged at least 130KB of data. The device driver must also have TCP Chimney enabled.
default - this setting restores chimney offload to the system default. Setting this "default" state under Windows 7 and 2008 Server is possible, but it sets the system to the "automatic" mode described above.
disabled - this setting is maually configured as disabled.
enabled - this setting is manually configured as enabled.
Notes:
Under Windows 7 and Server 2008 the "default" and the additional "automatic" parameter set the system to the same "automatic" state.
For Chimney Offload to work, it needs to be enabled in both the OS and NIC. To enable the "TCP Offloading" setting in your NIC, navigate to the Device Manager, under Network Adapters, in the Advanced tab, and check "Enabled" in the box next to the TCP offload entry.
Direct Cache Access (DCA)
Windows 7 and 2008 Server (but not Vista) add NETDMA 2.0 Direct cache access support. Direct Cache Access (DCA) allows a capable I/O device, such as a network controller, to deliver data directly into a CPU cache. The objective of DCA is to reduce memory latency and the memory bandwidth requirement in high bandwidth (Gigabit) environments. DCA requires support from the I/O device, system chipset, and CPUs.
To enable DCA:
netsh int tcp set global dca=enabled
Available states are: enabled, disabled.
Default state: disabled
Recommended: enabled (provided the CPU/MoBo/NIC support it)
It is also possible to enable this setting by editing the Windows Registry instead of using netsh as follows:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
EnableDCA=1 (DWORD, entry does not exist by default. Set to 1 to enable, 0 to disable)
Setting MTU
It is sometimes useful to view and set the MTU value for a specific network interface manually. To view a list of active network interfaces and their MTU values in Vista using netsh, open command prompt as administrator and execute the following command:
netsh interface ipv4 show subinterface
You will be presented with a list of interfaces, and their respective MTU values as follows:
To change the MTU value of a specific network card, type the following in command prompt:
netsh interface ipv4 set subinterface "network interface name" mtu=#### store=persistent
Where "network interface name" is your specific network adapter name as obtained above (or viewable under Network adapters), and mtu=#### is the desired MTU value.
For example, if the name of your network card is "Wireless Network Connection" and you'd like to set its MTU to 1500, you'd have to type:
netsh interface ipv4 set subinterface "Wireless Network Connection" mtu=1500 store=persistent
Note: The maximum MTU value is usually 1500, and up to 1492 for PPPoE connections.
Manually tuning Registry Parameters
Many of the registry keys tuning TCP/IP parameters from previous Windows versions no longer work in Vista and Server 2008. Below is a list of the few we've confirmed to still work. Note that for changes to these settings to take effect the computer needs to be rebooted. As always, a registry backup is recommended if making any changes, and some proficiency in using regedit is required.
In regedit (Start icon > Run > type: regedit while logged in as administrator), you can navigate and edit the following keys.
MTU (Maximum Transmission Unit) - the maximum packet size.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{...}\
MTU=1500 (DWORD, entry does not exist by default)
The {....} part of the above path is the unique identifier of your network adapter. You can recognize the correct adapter by looking at it's IP address, if obtaining IP automatically labeled by: DhcpIPAddress=192.168.x.x text value, for example.
We recommend leaving this at default, unless you want to lower it. Vista uses the largest possible packet size for the underlying network by default.
Note: In some test environments, the correct MTU entry may be offset by 8. The 8 offset seems to coincide with the size of the PPPoE overhead. Check the result with the TCP Analyzer.
TCP 1323 Options
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\
Tcp1323Opts=1 (DWORD, entry created automatically by Windows when you run the "netsh int tcp set global autotuninglvl=..." command, set to 0 by default).
Setting this seems to have no effect, since auto-tuning uses the TCP 1323 scale factor and changes it on the fly, disregarding this setting. Additional testing may be required to determine it's effect if auto-tuning is turned off. Setting it to 1 is best for broadband connections.
NetDMA
NetDMA enables support for advanced direct memory access. In essence, it provides the ability to more efficiently move network data by minimizing CPU usage. NetDMA frees the CPU from handling memory data transfers between network card data buffers and application buffers by using a DMA engine.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
EnableTCPA=1 (DWORD, 1 to enable, 0 to disable NetDMA. Value not present by default in Vista)
Recommended setting is 1, a new DWORD value may need to be created if not already present in the registry.
DefaultTTL
TTL can be safely left alone in many cases. It is a limit to the time and number of hops/routers a packet will travel before being discarded. A number that's too small risks packets being discarded before reaching their destination. A number that's too large (over 128) will cause delay in when lost IP packets are discarded.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
DefaultTTL=64 (DWORD, set to a decimal value between 32 and 128. Recommended: 64)
TcpMaxDataRetransmissions
Determines how many times unacknowledged data (non-connect segment) is retransmitted before TCP aborts the connection. The retransmission timeout is doubled with each successive retransmission on a connection. It is reset when responses resume.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
TCPMaxDataRetransmissions=7 (DWORD, recommended: between 3 and 10, default registry value 255, default 5 in documentation)
SynAttackProtect
This undocumented setting provides protection against SYN denial of service (DoS) attacks. When enabled, connections timeout sooner if SYN attack is detected. When set at 1, TCPMaxDataRetransmissions can be lowered further.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
SynAttackProtect=1 (DWORD, recommended: 1, not present in registry by default)
Set DNS and Hosts Priority
As with previous versions of Windows, one can improve DNS and hostname resolution by increasing the priority of of related services, while keeping their order. This is explained in more defail in our Host Resolution article. Lower numbers mean higher process priority. The corresponding registry settings in Vista are as follows:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\ServiceProvider
LocalPriority=4 (DWORD, recommended: 4, default: 499) - local names cache
HostsPriority=5 (DWORD, recommended: 5, default: 500) - the HOSTS file
DnsPriority=6 (DWORD, recommended: 6, default: 2000) - DNS
NetbtPriority=7 (DWORD, recommended: 7, default: 2001) - NetBT name resolution, including WINS
TcpTimedWaitDelay (port allocation)
Short lived (ephemeral) TCP/IP ports above 1024 are allocated as needed by the OS. The default Vista values have improved from previous Windows versions, and are usually sufficient under normal load. However, in some instances under heavy load it it may be necessary to adjust the settings below to tweak the availability of user ports requested by an application.
If the default limits are exceeded under heavy loads, the following error may be observed: "address in use: connect exception". By default under Vista (when the values are not presend in the registry), the OS can allocate up to 16384 ephemeral ports above port 1024, and the OS waits for 120 seconds before reclaiming ports after an application closes the TCP connection. This is a considerable improvement over older Windows versions. However, if necessary, the following registry values can be added/edited:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
MaxUserPort=65535 (DWORD, not in the registry by default. Recommended: leave at default, or use a number above 16384 up to 65535 decimal as necessary) - maximum number of ports to use. 1024 is automatically subtracted from entered value to allow for reserved ports under 1024.
TcpTimedWaitDelay=30 (DWORD, 0xffffffff in registry by default. Recommended: 30 decimal, denoting 30 seconds) - time to wait before reclaiming ports, in seconds. Default time before reclaiming ports, if value is at 0xffffffff or not present in the registry is 120 seconds. Just reducing the delay is often sufficient without changing MaxUserPort, as it allows for reusing ports more efficiently.
Ephemeral ports can be checked and changed using netsh as well.
To query the current values, in command prompt, type:
netsh int ipv4 show dynamicportrange tcp (for UDP, use the same command, replacing only "tcp" with "udp" at the end)
To set both the starting, and max user port using netsh, in elevated command prompt run:
netsh int ipv4 set dynamicportrange protocol=tcp start=1025 num=64511 (start=NNN denoting the starting port, and num=NNN denoting the number of ports)
Notes:
By default, dynamic ports are allocated between ports 49152 and 65535 (for a total of 16384 ephemeral ports).
Using netsh allows to set both the starting port and port range. Editing the Registry allows for setting the port range, and the starting port is fixed at 1025. Deleting the MaxUserPort registry entry (or setting it to a value outside the allowed range) causes the OS to revert to using the default values.
Some system processes can install port filters to block certain port ranges. If ephemeral ports run into these filtered port ranges, TCP/IP applications will be unable to bind to any ports.
QoS Reserved Bandwidth
As with Windows XP, nework adapters have a "QoS Packet Scheduler" enabled by default, which reserves 20% of bandwidth by default for QoS applications that request priority traffic. Note this only has effect in the presence of running QoS applications that request priority traffic. Registry value is undocumented for the Vista version of Windows. To customize this setting, in the Windows Registry:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Psched
NonBestEffortLimit=0 (DWORD, not present in the registry by default. Recommended: 0 , possible values between 0 and 100) - indicates the percentage value of reserved bandwidth for QoS applications. Set to 0 to disable.
Notes: This tweak applies only to Windows versions that have Qos Packet Scheduler enabled. It will ONLY have effect in the presense of running QoS applications.
Gaming Tweak - Disable Nagle's algorithm
The tweak below allows for tweaking or disabling Nagle's alogrithm. Disabling "nagling" allows for very small packets to be transferred immediately without delay. Note that disabling Nagle's algorithm is only recommended for some games, and it may have negative impact on file transfers/throughput. The dafault state (Nagling enabled) improves performance by allowing several small packets to be combined together into a single, larger packet for more efficient transmission. While this improves overall performance and reduces TCP/IP overhead, it may briefly delay transmission of smaller packets. Keep in mind that disabling Nagle's algorithm may have some negative effect on file transfers, and can only help reduce delay in some games. To implement this tweak, in the registry editor (Start>Run>regedit) find:
This setting configures the maximum number of outstanding ACKs in Windows XP/2003/Vista/2008:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{NIC-id}
There will be multiple NIC interfaces listed there, for example: {1660430C-B14A-4AC2-8F83-B653E83E8297}. Find the correct one with your IP address listed. Under this {NIC-id} key, create a new DWORD value:
TcpAckFrequency=1 (DWORD value, 1=disable, 2=default, 2-n=send ACKs if outstanding ACKs before timed interval. Setting not present by default).
For gaming performance, recommended is 1 (disable). For pure throughput and data streaming, you can experiment with values over 2. If you try larger values, just make sure TcpAckFrequency*MTU is less than RWIN, since the sender may stop sending data if RWIN fills witout acknowledgement.
Also, find the following key (if present):
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSMQ\Parameters
Add a new DWORD value:
TCPNoDelay=1 (DWORD value, 0 to enable Nagle's algorithm, 1 to disable, not present by default)
To configure the ACK interval timeout (only has effect if nagling is enabled), find the following key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{NIC-id}
TcpDelAckTicks=0 (DWORD value, default=2, 0=disable nagling, 1-6=100-600 ms). Note you can also set this to 1 to reduce the nagle effect from the default of 200ms without disabling it.
Notes:
Reportedly, the above gaming tweak (disabling nagle's algorithm) can reduce WoW (World of Warcraft) latency by almost half!
XP/2003 needs hotfix or SP2 for it to work (MS KB 815230)
Vista needs hotfix or SP1 for it to work (MS KB 935458)
SG Vista TCP/IP Patch - automatic optimization
For user convenience, we also provide a quick way to apply all optimal values as recommended above using our SG Vista TCP/IP Patch. It allows for tweaking all the above netsh settings and registry values in one simple step (with the exception of the "gaming tweak" section). The patch also provides for easily reverting the settings to their Windows default values. To apply, save to your desktop and run as administrator (right-click -> run as administrator). Click Y when prompted to apply settings.
Subscribe to:
Posts (Atom)
Posts
All Comments