Need help to set [DF] flag on all udp outgoing packets?

I gets "router may not support packets fragmentation" with any mtu I uses is there explanation to this??? And why I keep getting icmp packets need to fragment and how to fix it???

  • Then lower the MTU on the PS4. :wink:
  • Make sure you didn't firewall ICMP-Fragmentation-Needed packet

I tried with every mtu even 1500 and it still shows that message on ps4 also I gets icmp messages that packets need to frags, can you tell me what the cause of this is it isp or is it my router but I tried with 3 different routers and I gets same message I am lost on this.

:frowning_face:

I don't think you want to fix your issue.

To be clear...you are lowering the MTU, correct?

2 Likes

Seriously, you should stop asking how to do weird and unusual configurations that nobody else seems to need, and instead ask what you need to do, read the answers you get, and follow the advice you receive.

For example, if your console complains that your router does not support fragmentation, tagging all packets as "do not fragment" seems like the exact opposite of what you need.

Packets get fragmented when they are larger than the maximum accepted by the link between two nodes. Packets that cannot be fragmented have to be dropped. Just because you mark them as DF will not magically make them fit.

If you have trouble with packet fragmentation, the first test you should do is to lower the MTU on all interfaces on your router. You will lose some throughput, however.

5 Likes

What config did you add that caused this message to appear?

:bulb: I realized in your past threads...this wasn't broken! :wink:

You haven't mentioned this problem before...but then I recall you made this thread:

and that I already noted:

and you noted:

So how did it break? You tell us. :thinking:

EDIT: And you obviously fix this by setting the PS4's MTU to 1365 or lower.

I thought when I set packets to DF they will not be dropped due fragmentation process as I gets that message in all mtu, I tried 1420 1464 1472 1492 1500 1373 1365 "router may not support packets fragmentation"

I swear I don't know why this happens I tried lowering mtu with both ps4 and router (eth0 pppoe-wan) that all I did but the problem isn't with router as I get same message on ps4 using 3 different routers

:laughing:

Have you tried...............................................

1364?????????????????????

:thinking:

(I'd try 1345.)

I tried 1345 I am not getting icmp anymore thanks for your help :sweat_smile: but I am still getting ps4 error message about fragmentation do you know what to do about it or what cause of it?

Again, please answer:

(I would guess that you blocked ICMP Fragmentation-Needed packets from being received on LAN.)

Let us know the results of: http://www.letmecheck.it/mtu-test.php

Other site that will show information:

I installed fresh new openwrt and I changed mtu to 1345 for eth0 lan interface (I have only one ethernet adapter) and pppoe mtu is 1337 automatically the result of letmecheck

Sending 32 bytes to 41.41.15.13  <-  not fragmented

Sending 750 bytes to 41.41.15.13  <-  not fragmented

Sending 1125 bytes to 41.41.15.13  <-  not fragmented

Sending 1313 bytes to 41.41.15.13  <-  FRAGMENTED!

Sending 1219 bytes to 41.41.15.13  <-  not fragmented

Sending 1266 bytes to 41.41.15.13  <-  not fragmented

Sending 1290 bytes to 41.41.15.13  <-  not fragmented

Sending 1302 bytes to 41.41.15.13  <-  not fragmented

Sending 1308 bytes to 41.41.15.13  <-  not fragmented

Sending 1311 bytes to 41.41.15.13  <-  FRAGMENTED!

Sending 1309 bytes to 41.41.15.13  <-  not fragmented

Sending 1310 bytes to 41.41.15.13  <-  FRAGMENTED!

Sending 1309 bytes to 41.41.15.13  <-  not fragmented


From the tests we did, we can assume that 1309 bytes is the largest unfragmented packet
size. The MTU size would be 1337, made up from 1309 payload and 28 ICMP/IP Headers
and payload information. 

The current maximum payload size is not divisible by 8.
The actual size of the payload (data) will be limited to: 1304

The maximum MTU size for 41.41.15.13 is:    1337

NB: The Internet Protocol requires that hosts must be able to process IP datagrams of at least
576 bytes (for IPv4) or 1280 bytes (for IPv6)

And speed guide

IP Address: [ **41.41.15.13** ](https://www.speedguide.net/ip/41.41.15.13) (host-41.41.15.13.tedata.net)
Client OS:  **Android**
Browser: Chrome 83.0.4103.60
User Agent: Mozilla/5.0 (Linux; Android 9; FLA-LX1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.60 Mobile Safari/537.36
*Please Read the [Analyzer FAQ](https://www.speedguide.net/faq_in.php?category=98) if the above is [not your IP address](https://www.speedguide.net/faq/3-my-readings-are-inaccurate-how-do-i-fix-that-23).*

**[TCP options string](https://www.speedguide.net/_iframe_term.php?seek=TCP1323OPTS)**  =  **020405110402080a002955280000000001030308**
**[MTU](https://www.speedguide.net/_iframe_term.php?seek=MTU)**  =  **1337**
MTU is not fully optimized for broadband. Consider increasing your MTU to 1500 for better throughput. If you are using a router, it could be limiting your MTU regardless of Registry settings.
**[MSS](https://www.speedguide.net/_iframe_term.php?seek=MSS)**  =  **1297**
MSS is not optimized for broadband. Consider increasing your MTU value.
**[Default TCP Receive Window (RWIN)](https://www.speedguide.net/_iframe_term.php?seek=RWIN)**  =  **87808**
RWIN Scaling (RFC1323) = 8 bits (scale factor: 2^8=256)
Unscaled TCP Receive Window = 343

You seem to be using Google Chrome. Note that Chrome can modify the TCP Window for sockets it creates under some OSes, and therefore servers may not get your OS-assigned RWIN value. [FAQ](https://www.speedguide.net/faq/8-the-analyzer-reads-my-rwin-value-incorrectly-359)
RWIN is  **not**  multiple of MSS. If your OS supports setting RWIN directly, consider changing it to a multiple of MSS for optimum performance.
Other RWIN values that might work well with your current MTU/MSS:
64850  (up to 2 Mbit lines, depending on latency. MSS * 50)
129700 (1-5 Mbit lines, depending on latency. MSS * 50 * 2)
259400 (2-15 Mbit lines, depending on latency. MSS * 50 * 2^2)
518800 (10-30 Mbit lines, depending on latency. MSS * 50 * 2^3)
1037600 (30-100 Mbit lines depending on latency. MSS * 50 * 2^4)
[ **bandwidth**  *** delay product** ](https://www.speedguide.net/faq/what-is-the-bandwidth-delay-product-185) (Note this is not a [speed test](https://www.speedguide.net/speedtest/)):

Your current TCP Window limits you to: 3512 kbps (439 KBytes/s) @ 200ms latency
Your current TCP Window limits you to: 1405 kbps (176 KBytes/s) @ 500ms latency
**[MTU Discovery (RFC1191)](https://www.speedguide.net/_iframe_term.php?seek=MTU)**  =  **ON**
**[Time to live left](https://www.speedguide.net/_iframe_term.php?seek=TTL)**  =  **48 hops**
TTL value is ok.
**[Timestamps (RFC1323)](https://www.speedguide.net/_iframe_term.php?seek=TIMESTAMPS)**  =  <strong>ON
*Note: Timestamps add 12 bytes to the TCP header of each packet, reducing the space available for useful data.*</strong>
**[Selective Acknowledgements (RFC2018)](https://www.speedguide.net/_iframe_term.php?seek=SACKOPTS)**  =  **ON**
**[IP type of service field (RFC1349)](https://www.speedguide.net/articles/tcp-optimizer-2-documentation-windows-9x-xp-2003-4237#advanced_qos)**  =  **00000000 (0)**

:man_facepalming:

Why did you do this before the test???

Please test again without doing this.

1 Like

And BTW, my suggestion was to do this on the PS4 (i.e. the device with a problem).

IP Address: [ **41.41.15.13** ](https://www.speedguide.net/ip/41.41.15.13) (host-41.41.15.13.tedata.net)
Client OS:  **Android**
Browser: Chrome 83.0.4103.60
User Agent: Mozilla/5.0 (Linux; Android 9; FLA-LX1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.60 Mobile Safari/537.36
*Please Read the [Analyzer FAQ](https://www.speedguide.net/faq_in.php?category=98) if the above is [not your IP address](https://www.speedguide.net/faq/3-my-readings-are-inaccurate-how-do-i-fix-that-23).*

**[TCP options string](https://www.speedguide.net/_iframe_term.php?seek=TCP1323OPTS)**  =  **020405ac0402080a002aae920000000001030308**
**[MTU](https://www.speedguide.net/_iframe_term.php?seek=MTU)**  =  **1492**
MTU is optimized for PPoE DSL broadband. If not, consider raising MTU to 1500 for optimal throughput.
**[MSS](https://www.speedguide.net/_iframe_term.php?seek=MSS)**  =  **1452**
MSS is optimized for PPPoE DSL broadband. If not, consider raising your MTU value.
**[Default TCP Receive Window (RWIN)](https://www.speedguide.net/_iframe_term.php?seek=RWIN)**  =  **87808**
RWIN Scaling (RFC1323) = 8 bits (scale factor: 2^8=256)
Unscaled TCP Receive Window = 343

You seem to be using Google Chrome. Note that Chrome can modify the TCP Window for sockets it creates under some OSes, and therefore servers may not get your OS-assigned RWIN value. [FAQ](https://www.speedguide.net/faq/8-the-analyzer-reads-my-rwin-value-incorrectly-359)
RWIN is  **not**  multiple of MSS. If your OS supports setting RWIN directly, consider changing it to a multiple of MSS for optimum performance.
Other RWIN values that might work well with your current MTU/MSS:
63888  (up to 2 Mbit lines, depending on latency. MSS * 44)
127776 (1-5 Mbit lines, depending on latency. MSS * 44 * 2)
255552 (2-15 Mbit lines, depending on latency. MSS * 44 * 2^2)
511104 (10-30 Mbit lines, depending on latency. MSS * 44 * 2^3)
1022208 (30-100 Mbit lines depending on latency. MSS * 44 * 2^4)
[ **bandwidth**  *** delay product** ](https://www.speedguide.net/faq/what-is-the-bandwidth-delay-product-185) (Note this is not a [speed test](https://www.speedguide.net/speedtest/)):

Your current TCP Window limits you to: 3512 kbps (439 KBytes/s) @ 200ms latency
Your current TCP Window limits you to: 1405 kbps (176 KBytes/s) @ 500ms latency
**[MTU Discovery (RFC1191)](https://www.speedguide.net/_iframe_term.php?seek=MTU)**  =  **ON**
**[Time to live left](https://www.speedguide.net/_iframe_term.php?seek=TTL)**  =  **47 hops**
TTL value is ok.
**[Timestamps (RFC1323)](https://www.speedguide.net/_iframe_term.php?seek=TIMESTAMPS)**  =  <strong>ON
*Note: Timestamps add 12 bytes to the TCP header of each packet, reducing the space available for useful data.*</strong>
**[Selective Acknowledgements (RFC2018)](https://www.speedguide.net/_iframe_term.php?seek=SACKOPTS)**  =  **ON**
**[IP type of service field (RFC1349)](https://www.speedguide.net/articles/tcp-optimizer-2-documentation-windows-9x-xp-2003-4237#advanced_qos)**  =  **00000000 (0**

And

Letmecheck

Sending 32 bytes to 41.41.15.13  <-  not fragmented

Sending 750 bytes to 41.41.15.13  <-  not fragmented

Sending 1125 bytes to 41.41.15.13  <-  not fragmented

Sending 1313 bytes to 41.41.15.13  <-  not fragmented

Sending 1407 bytes to 41.41.15.13  <-  not fragmented

Sending 1454 bytes to 41.41.15.13  <-  not fragmented

Sending 1478 bytes to 41.41.15.13  <-  FRAGMENTED!

Sending 1466 bytes to 41.41.15.13  <-  FRAGMENTED!

Sending 1460 bytes to 41.41.15.13  <-  not fragmented

Sending 1463 bytes to 41.41.15.13  <-  not fragmented

Sending 1465 bytes to 41.41.15.13  <-  FRAGMENTED!

Sending 1464 bytes to 41.41.15.13  <-  not fragmented

Sending 1465 bytes to 41.41.15.13  <-  FRAGMENTED!

Sending 1464 bytes to 41.41.15.13  <-  not fragmented


From the tests we did, we can assume that 1464 bytes is the largest unfragmented packet
size. The MTU size would be 1492, made up from 1464 payload and 28 ICMP/IP Headers
and payload information. 

The maximum MTU size for 41.41.15.13 is:    1492

NB: The Internet Protocol requires that hosts must be able to process IP datagrams of at least
576 bytes (for IPv4) or 1280 bytes (for IPv6)
1 Like
  • This is your MTU
  • Now play the game...do not add any configs...let us know if you get the message
1 Like

I tried with mtu 1492 on ps4 and still getting message can this because of outside of my router???

Yes...in other threads, you were told that this could be your ISP.

Since you reset to defaults and didn't change configs, I'm inclined to believe it's the ISP.

I hope you didn't set a config again.

I didn't :grinning:

1 Like