I tried to compile it on openwrt but it says there is no build folder I guess it doesn't work on openwrt, is there smiliar packet or another way other than iptables to set DF Flag on all udp outgoing traffic ???
Do you actually understand what this does if installed on your router?
What proof do you have that you need to set DF on your packets (i.e. did your ISP say this is required or ICMP fragment messages)?
If an ICMP fragment message is sent to your OpenWrt from a router along the path, you do realize what happens if the routers is told not to fragment???
If the packet needs to be fragmented; and
You set a DF
What do you think happens?
(Clue: you'll have to uninstall it to ask here why it didn't work.)
You can simply set the MTU on your LAN. Lastly:
it's impossible to send a packet larger than your WAN anyway
your WAN is already < 1500
(Again, you failed to tell us the reason you want to do this is because you beleive these things will improve your ability to hit opponents on your shooter game on PlayStation4.)
I believe I have problem with fragmentation as I gets message in ps4 "the router in use may not support packets fragmentation" and in ps4 and I keep getting icmp message packet need to frag in games How to fix this "unreachable - need to frag (mtu 1365)"
1, yes it will say to server don't fragment packets
2. I gets icmp message in games packets need to frags
3. It will be dropped but packets get dropped anyway as the router doesn't support packets fragmentation
Yes I believe it will improve gameplay as I will avoid packets fragmentation loss
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???
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.
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.
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
I tried 1345 I am not getting icmp anymore thanks for your help but I am still getting ps4 error message about fragmentation do you know what to do about it or what cause of it?
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)**
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)