This is our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Hi

I have a problem with setting my MTU lower then 536. Windows 7 Home Premium 64-bit SP1 . When i use a lower MTU about 300 i cant connect to server . With my second pc witch is using Windows Xp SP3 it works with a mtu 300.

« SpeedGuide.net TCP Analyzer Results »

Client OS/browser: Windows 7 (Firefox 39.0)

TCP options string: 0204010401010402 MSS: 260 MTU: 300 TCP Window: 65520 (multiple of MSS) RWIN Scaling: 0 bits
Unscaled RWIN : 65520 Recommended RWINs: 65520, 131040, 262080, 524160, 1048320 BDP limit (200ms): 2621kbps (328KBytes/s) BDP limit (500ms): 1048kbps (131KBytes/s) MTU Discovery: ON TTL: 49 Timestamps: OFF SACKs: ON IP ToS: 00000000 (0)

Can someone help me pls :/

asked 21 Jul '15, 12:37

NT%20Lucky's gravatar image

NT Lucky
6225
accept rate: 0%

edited 21 Jul '15, 14:08

Jim%20Aragon's gravatar image

Jim Aragon
7.2k733118


Normally, IPv4 requires a minimum MTU of 576, while IPv6 even enforces 1280. So I guess you're just too low.

Why even go for an MTU as low as 300? It doesn't make any sense unless you've got a very peculiar physical connection...

permanent link

answered 21 Jul '15, 12:43

Jasper's gravatar image

Jasper ♦♦
23.8k551284
accept rate: 18%

THX for answering :D

Like i said on windows xp it works but windows 7 not :/ and for me it is important .

Lower MTU reduce the ping and has other advanteges for me

you have no idea why i cant go lower the 536 ?

(21 Jul '15, 12:49) NT Lucky

Just for personal interest: Why does lower MTU reduce your ping time? The only environment I imagine where this could happen is a half duplex network with hubs. Do you have such a network?

(21 Jul '15, 12:55) Christian_R

Normally, lower MTU is bad because it hurts throughput, and same as @Christian_R I can't imagine why it would reduce latency (I guess that's what you're saying with "ping")

(21 Jul '15, 12:59) Jasper ♦♦

The throughput for me is not intresting . Yes it reduce latency.

If i want throughput i change MTU netsh interface ipv4 set subinterface "LAN-Verbindung" mtu=1492 store=persistent

that arjust 2-3 klicks to change between 300 and 1492 . But The problem is that windows 7 i think does not allow lower MTU then 536 and i want to know how i can change this

(21 Jul '15, 13:08) NT Lucky

My guess is - you can't. Starting with Win7 (actually, Vista), Windows has a completely new network stack that doesn't care about settings that worked in XP.

(21 Jul '15, 13:13) Jasper ♦♦

That is strange because my friend has also windows 7 and at his PC it works that is what is making me mad :/ I can ping the server so the packeg is send but cant connect :/

Pinging [193.192.59.109] with 32 bytes ->bytes=32 time=21ms TTL=58 Pinging [193.192.59.109] with 32 bytes ->bytes=32 time=22ms TTL=58 Pinging [193.192.59.109] with 32 bytes ->bytes=32 time=21ms TTL=58 Ping statistics for above hosts: Packets: Sent = 3, Received = 3, Lost = 0 (0% loss) Approximate round trip times (RTT) in milli-seconds: Minimum = 21ms, Maximum = 22ms, Average = 21ms

Pinging [193.192.59.109] with 300 bytes ->bytes=300 time=21ms TTL=58 Pinging [193.192.59.109] with 300 bytes ->bytes=300 time=21ms TTL=58 Pinging [193.192.59.109] with 300 bytes ->bytes=300 time=21ms TTL=58 Ping statistics for above hosts: Packets: Sent = 3, Received = 3, Lost = 0 (0% loss) Approximate round trip times (RTT) in milli-seconds: Minimum = 21ms, Maximum = 21ms, Average = 21ms

Pinging [193.192.59.109] with 1500 bytes ->bytes=1500 time=23ms TTL=58 Pinging [193.192.59.109] with 1500 bytes ->bytes=1500 time=23ms TTL=58 Pinging [193.192.59.109] with 1500 bytes ->bytes=1500 time=23ms TTL=58 Ping statistics for above hosts: Packets: Sent = 3, Received = 3, Lost = 0 (0% loss) Approximate round trip times (RTT) in milli-seconds: Minimum = 23ms, Maximum = 23ms, Average = 23ms

Pinging [193.192.59.109] with 3000 bytes ->bytes=3000 time=25ms TTL=58 Pinging [193.192.59.109] with 3000 bytes ->bytes=3000 time=24ms TTL=58 Pinging [193.192.59.109] with 3000 bytes ->bytes=3000 time=25ms TTL=58 Ping statistics for above hosts: Packets: Sent = 3, Received = 3, Lost = 0 (0% loss) Approximate round trip times (RTT) in milli-seconds: Minimum = 24ms, Maximum = 25ms, Average = 24ms

(21 Jul '15, 13:18) NT Lucky

Or it is the networkadapter Intel(R) 82583V Gigabit Network Connection

or it depends on other TCP settings like Path MTU Discovery and Filtering ICMP :( but i dont finde something at google thats why i postet her

(21 Jul '15, 13:24) NT Lucky
1

Out of curiosity - is this a game related "trick"? And how do you measure success? I doubt pings are what is used by whatever application/game you're using, so have you checked the real protocol packets for being "faster", too?

(21 Jul '15, 13:26) Jasper ♦♦

Thats strange because my friend has windows 7 and at his pc it works fine :/

Pinging [192.168.2.105] with 1500 bytes -> ..fragmented Pinging [192.168.2.105] with 750 bytes -> ..fragmented Pinging [192.168.2.105] with 375 bytes -> ..fragmented Pinging [192.168.2.105] with 188 bytes ->bytes=188 time=0ms TTL=64 Pinging [192.168.2.105] with 281 bytes -> ..fragmented Pinging [192.168.2.105] with 234 bytes ->bytes=234 time=0ms TTL=64 Pinging [192.168.2.105] with 257 bytes ->bytes=257 time=0ms TTL=64 Pinging [192.168.2.105] with 269 bytes ->bytes=269 time=0ms TTL=64 Pinging [192.168.2.105] with 275 bytes -> ..fragmented Pinging [192.168.2.105] with 272 bytes ->bytes=272 time=0ms TTL=64 Pinging [192.168.2.105] with 273 bytes -> ..fragmented The largest possible non-fragmented packet is 272 (300 - 28 ICMP & IP headers). You can set your MTU to 300

Pinging [192.168.2.105] with 300 bytes ->bytes=300 time=1ms TTL=64 Pinging [192.168.2.105] with 300 bytes ->bytes=300 time=0ms TTL=64 Pinging [192.168.2.105] with 300 bytes ->bytes=300 time=0ms TTL=64 Ping statistics for above hosts: Packets: Sent = 3, Received = 3, Lost = 0 (0% loss) Approximate round trip times (RTT) in milli-seconds: Minimum = 0ms, Maximum = 1ms, Average = 0ms

(21 Jul '15, 13:29) NT Lucky

that is trange my friend also has Windows 7 and at his pc it works

(21 Jul '15, 13:32) NT Lucky

Pinging [192.168.2.105] with 300 bytes ->bytes=300 time=1ms TTL=64

Pinging [192.168.2.105] with 300 bytes ->bytes=300 time=0ms TTL=64

Pinging [192.168.2.105] with 300 bytes ->bytes=300 time=0ms TTL=64

Ping statistics for above hosts: Packets: Sent = 3, Received = 3, Lost = 0 (0% loss) Approximate round trip times (RTT) in milli-seconds: Minimum = 0ms, Maximum = 1ms, Average = 0ms

(21 Jul '15, 13:33) NT Lucky

LOL gerade gesehen das du Deutscher bist ^^

(21 Jul '15, 13:39) NT Lucky

Hi, I found this here:

However, if MTU detection is disabled (that is, the value of EnablePMTUDiscovery is 0), the system uses a fixed MTU of 576 bytes. If you change the default value of the MTU entry, you override either setting as it pertains to the interface represented by this subkey.

This can be found here: https://technet.microsoft.com/en-us/library/cc938197.aspx


I saw that is an old entry at microsoft. So I convert this to a comment.

(21 Jul '15, 13:45) Christian_R

I dont have EnablePMTUDiscovery in the interface , so i ad D-Word EnablePMTUDiscovery 1 at HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\ interface-name

(21 Jul '15, 14:21) NT Lucky

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters has PathMTUDiscovery 1

(21 Jul '15, 14:31) NT Lucky

Yes you are right, I will post the answer in a few seconds.

(21 Jul '15, 14:39) Christian_R
1

As @Jasper hinted above, I think this is a wild goose chase. Your pings are to a public IP address, your friends pings are to a local private IP, i.e. your's are over the Internet, his are on his local LAN. No wonder results are different.

Pinging with different sizes of payloads will show slightly increased times with larger payloads as you're transmitting and receiving more data. This has nothing to do with MTU.

Reducing your MTU to such a small size will likely cause more packets to be sent to transfer the required data, thus increasing the overhead (and possibly latency) and making overall communication slower.

Do you have any source that explains why reducing the MTU so low has a positive effect?

(22 Jul '15, 00:15) grahamb ♦
1

Why am I reminded of a commercial: "That's not how this works. That's not how any of this works."

(22 Jul '15, 17:25) Hadriel
showing 5 of 18 show 13 more comments

Ok I think I got it, at least for Win8.1, but I hope Win7 is similar:

If you execute the command:

netsh interface ipv4 show global

You can see an entry MinMTU = 576

You can alter this entry by the following command:

 netsh int ipv4 set global minmtu=352

The value minmtu can be set to a value between 352 and 576 for IPv4 and is fix for IPv6 at 1280.

Otherwise you can compare the values of the stack with your friend with this tool maybe: https://github.com/ChristianRe/CRWinNetDiag <- Admins you are allowed to delete the link, I am not sure if it is against the rules in this forum. I do not want to work against the rules.

permanent link

answered 21 Jul '15, 15:12

Christian_R's gravatar image

Christian_R
1.8k2625
accept rate: 16%

edited 21 Jul '15, 15:44

no worries, links are fine as long as they point to a resource that helps.

(21 Jul '15, 15:17) Jasper ♦♦

At first thanks very much to all :D at least a MTU of 352 lower would be nice but its a good start ^^ mean while i found this hot fix at https://support.microsoft.com/en-us/kb/2896146 that allows to you to use MTU 352 like you wrote a Chris

(21 Jul '15, 15:45) NT Lucky
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×103
×25

question asked: 21 Jul '15, 12:37

question was seen: 2,082 times

last updated: 22 Jul '15, 17:25

p​o​w​e​r​e​d by O​S​Q​A