Bug #16027
closed
RTTsd can be incorrect when using a manual gateway monitoring data payload size of ``0``
Added by Leon Straathof 3 months ago.
Updated 3 months ago.
Category:
Gateway Monitoring
Affected Architecture:
amd64
Description
This issue has been reported before by others but because of not enough information always closed as not a bug. I have had the issue as well and found the reason/solution why this is a problem for some people who take very close notice of the reported numbers.
The reason seems to be that the check of the gateway is a custom ICMP request that has no payload. All OS that i know have a default payload for ICMP request, Windows has 32, Linux has 64 and FreeBSD has 56. There is no benefit of setting the payload to 0 as pfSense does. Because the minimal Ethernet frame length is 64 and a header without payload is only 20 so it will be padded anyway. My suggestion is to stick to the OS pfSense is build on defaults so 56. I can confirm that any installation that had problems with erratic RTTsd values had this solved when a playload of 56 is set.
I do not have any explanation why a payload of zero can give this problem, but since all OS makers seem to add a default payload my guess is they have a reason to do this. Maybe ask FreeBSD project if they know the why.
- Subject changed from RTTsd can be wrong in pfSense. to RTTsd can be incorrect when using a manual gateway monitoring data payload size of ``0``
- Status changed from New to Duplicate
Jim Pingle wrote in #note-1:
The default payload has been 1 for nearly 5 years now so there is nothing actionable here. Users can manually set their payload size to 0, but it's not that way for new installs/gateways and hasn't been for quite some time.
See ea0d5cbe0a49ff85ab592aadaafc8e806fd1297e
There are other problems with 0 size noted in the docs as well: https://docs.netgate.com/pfsense/en/latest/routing/gateway-configure.html#advanced-gateway-settings
Sorry my mistake on stating the default payload size as 0, i just meant default payload size that indeed is 1. The problem still remains the same erratic measurements. Also i did my homework on the usefullness of minimum size. The smallest ethernet frame is 64 byte and has a 18 byte header so 46 bytes left, minus 20 bytes for tcp header and 8 bytes for ICMP header. Leaves 18 bytes for payload and there is no savings setting the payload lower then this. Also getting erretic readings in some instances (i do not know why) and just changing the value to something all ICMP requests in OS variants haves solves it means they did this on purpose. Just going against this and say users can change it but letting them search for the why in vain is not very end user friendly. Then you don't have to care about defaults at all because any setting can be manually set.
Also available in: Atom
PDF
Updated by 
Updated by