Bug 204186 - Panic in pf_normalize_ip (netpfil/pf/pf_norm.c:1349)
Summary: Panic in pf_normalize_ip (netpfil/pf/pf_norm.c:1349)
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 10.2-RELEASE
Hardware: amd64 Any
: --- Affects Some People
Assignee: freebsd-pf mailing list
Depends on: 203976
  Show dependency treegraph
Reported: 2015-11-01 07:11 UTC by ziyanm
Modified: 2018-10-19 22:07 UTC (History)
2 users (show)

See Also:

sanitised textdump (360.79 KB, text/plain)
2015-11-01 07:11 UTC, ziyanm
no flags Details
pf.conf (2.55 KB, text/plain)
2015-11-01 07:12 UTC, ziyanm
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description ziyanm 2015-11-01 07:11:19 UTC
Created attachment 162667 [details]
sanitised textdump

I can reliably trigger a panic with with the attached pf.conf on 10.2-RELASE-p6 with the attached pf.conf. This configuration worked well with 9.3-RELEASE.
Comment 1 ziyanm 2015-11-01 07:12:03 UTC
Created attachment 162668 [details]
Comment 2 Kristof Provost freebsd_committer 2015-11-01 09:47:23 UTC
This is the same problem as #203976

It'll go away if you change this:
> scrub in on $int_if no-df fragment crop
> scrub in on $int_if no-df fragment reassemble

It's fixed in CURRENT because we got rid of the 'crop' function (it just transparently maps to reassemble there).
Comment 3 ziyanm 2015-11-01 19:25:14 UTC
(In reply to Kristof Provost from comment #2)

Thanks for the tip Kristof. I made the change a couple of hours ago and everything seems fine since.

A bit off-topic, but I actually experienced occasional NFS server hangs back when I ran 9.3. I'm wondering if the fragment crop-ovl option was to blame.