Bug 240819 - PF scrub drop UDP Fragment
Summary: PF scrub drop UDP Fragment
Status: Closed Not A Bug
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 12.0-STABLE
Hardware: amd64 Any
: --- Affects Many People
Assignee: freebsd-pf (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-09-25 15:24 UTC by fabrice.bruel
Modified: 2019-09-26 13:24 UTC (History)
2 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description fabrice.bruel 2019-09-25 15:24:38 UTC 
Hello,

I've notice a problem with scrub and UDP packet on FreeBSD 12STABLE

Version :
# uname -a
FreeBSD R640-4 12.0-STABLE FreeBSD 12.0-STABLE #1 r348036M: Tue May 21 10:58:21 CEST 2019     root@PFWALL-GEN2:/usr/obj/PFWALL.amd64/usr/local/PFWall/FreeBSD/src/amd64.amd64/sys/PFWALL-AMD64  amd64

Describe :

If PF is activated with this scrub option :

scrub out all random-id
scrub all fragment reassemble

UDP fragment doesn't cross PF. removing this 2 line solve the issue.

Incoming packet seems to be "bad" in tcpdump :

# tcpdump -n -i bxe3 udp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on bxe3, link-type EN10MB (Ethernet), capture size 262144 bytes
16:23:13.231094 IP 10.2.0.22.2798 > 10.2.0.221.0: UDP, bad length 1420 > 1392
16:23:13.231116 IP 10.2.0.22 > 10.2.0.221: ip-proto-17
16:23:14.292550 IP 10.2.0.22.2799 > 10.2.0.221.0: UDP, bad length 1420 > 1392
16:23:14.292572 IP 10.2.0.22 > 10.2.0.221: ip-proto-17
16:23:15.354955 IP 10.2.0.22.2800 > 10.2.0.221.0: UDP, bad length 1420 > 1392

Note that's the MTU of the egress interface (bxe3 here) is 1500 :
# ifconfig bxe3
bxe3: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	options=522ba<TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO6,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO>

I've tried to remove tso, rxcsum,tso, with no result. Maybe it's more a IP issue ?


How to reproduce : 

# hping -2 -m 1400 -d 1420  ip_target
Comment 1 Kristof Provost freebsd_committer freebsd_triage 2019-09-25 21:19:55 UTC 
I think I've reproduced this, but I don't think it's a pf bug.

The packet gets dropped and counted as a short packet because the UDP destination port is 0. That check has been there since 2004.
The IP stack itself will also discart packets with a destination port of 0.

When I add '-p 53' to the hping command the packets do not get dropped by pf.

(Arguably it's an hping bug that it generates packets with UDP destination port 0, but its man page suggests that this is deliberate.)
Comment 2 Kristof Provost freebsd_committer freebsd_triage 2019-09-25 21:20:41 UTC 
(In reply to Kristof Provost from comment #1)
UDP (and TCP) destination port 0 is reserved, and should not be used. That's why pf drops the packet (when scrub is enabled).
Comment 3 fabrice.bruel 2019-09-26 13:24:57 UTC 
In fact we have a problem on video flows, udp fragmented. I think, I was able to reproduce the issue with hping, but you are right Kristof, with a destination port, it's work fine.



Thanks for your help

Fabrice