Fixed
Created: Nov 14, 2023
Updated: Jan 5, 2024
Resolved Date: Dec 28, 2023
Found In Version: 10.23.30.3
Fix Version: 10.23.30.5
Severity: Standard
Applicable for: Wind River Linux LTS 23
Component/s: Kernel
we consulted Intel about ipIfStatsHCOutForwDatagrams’s behavior on G2/G3 and they provided reasonable explanation. The case is when G2/G3 node receives a packet with DF flag is set to 1 but for the outgoing interface MTU is lower than packet size so the packet is dropped. In this case Intel steps this counter while WindRiver does not. Intel’s explanation is following:
“Please refer to the updated figure attached at the bottom. I put additional color which clarifies following.
- Red thick line indicates how your test packet was processed.
- Statistics in red color box are supposed to be incremented.
- Your observation in your table look to be aligned with above.
Looking carefully at below the description from RFC 4293 which you referred to in your earlier post, it says that the counter should be incremented when 1) this entity was not their final IP destination and 2) for which it was successful in finding a path to their final destination. So, the chance for incrementing this counter will not depend on whether this packet was finally sent out, or not.
–
ipIfStatsHCOutForwDatagrams:
"The number of datagrams for which this entity was not their
final IP destination and for which it was successful in
finding a path to their final destination.
I buy this explanation/interpretation and seems to be correct according to cited RFC. Would it be possible yet to check if this counter could be increased in such case on linux kernel side?