https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=288558
Bug ID: 288558
Summary: icmp does not reset the fragment offset field when it
is going to reply an ICMP packet
Product: Base System
Version: 13.5-RELEASE
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: [email protected]
Reporter: [email protected]
Created attachment 262567
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=262567&action=edit
Proposed change to fix the issue
When ICMP module is going to reply an ICMP packet, icmp_reflect(), it would
inherit the ipv4 header of the RX ICMP packet firstly then change the related
field at the ipv4 header accordingly. But the IPv4 flags field used to store
fragmentation info is not changed.
If a DF, don't fragmentation, is set at a RX ICMP packet, the ICMP Reply packet
would keep the DF bit set. The ICMP reply packet would be dropped at
sys/netinet/ip_output.c::ip_output() if the ICMP reply packet is larger than
the network interface's MTU.
/* Balk when DF bit is set or the interface didn't support TSO. */
if ((ip_off & IP_DF) ||
(m->m_pkthdr.csum_flags & (CSUM_TSO | CSUM_INNER_TSO))) {
error = EMSGSIZE;
IPSTAT_INC(ips_cantfrag);
goto bad;
}
/*
* Too large for interface; fragment if possible. If successful,
* on return, m will point to a list of packets to be sent.
*/
error = ip_fragment(ip, &m, mtu, ifp->if_hwassist);
Setting Test interface's MTU as 1460 and host interface's MTU as 1500
My Host is Linux, and I can see PINGs fail when using
$ ping -I enp0s31f6 192.168.1.129 -s 1472 -c 3
PING 192.168.1.129 (192.168.1.129) from 192.168.1.2 enp0s31f6: 1472(1500) bytes
of data.
^C
--- 192.168.1.129 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2046ms
--
You are receiving this mail because:
You are the assignee for the bug.
