Bug 204186
| Summary: | Panic in pf_normalize_ip (netpfil/pf/pf_norm.c:1349) | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | ziyanm | ||||||
| Component: | kern | Assignee: | freebsd-pf (Nobody) <pf> | ||||||
| Status: | Closed FIXED | ||||||||
| Severity: | Affects Some People | CC: | kp, ziyanm | ||||||
| Priority: | --- | ||||||||
| Version: | 10.2-RELEASE | ||||||||
| Hardware: | amd64 | ||||||||
| OS: | Any | ||||||||
| Bug Depends on: | 203976 | ||||||||
| Bug Blocks: | |||||||||
| Attachments: |
|
||||||||
Created attachment 162668 [details]
pf.conf
This is the same problem as #203976 It'll go away if you change this: > scrub in on $int_if no-df fragment crop into > 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). (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. |
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.