During the investigation of the PR panic when using pf and route-to (maybe: bad fragment handling?) http://lists.freebsd.org/pipermail/freebsd-pf/2012-May/006577.html
we found that under some circumstances the ip_len in an mbuf ends up in the wrong byte order, eventually triggering an m_copym panic, variations of which were reported before (without resolution). Adding a patch to assert the correct byte order in various places http://www.benzedrine.cx/fbsd-byteorder.diff produced a panic in ipfw's pfil hook panic: ipfw_check_hook:281 ASSERT_HOST_BYTE_ORDER 45056 176 ipfw_check_hook() at ipfw_check_hook+0x511 pfil_run_hooks() at pfil_run_hooks+0xf1 ip_output() at ip_output+0x6de ip_forward() at ip_forward+0x19e ip_input() at ip_input+0x680 swi_net() at swi_net+0x15a i.e. ip_len is in host byte order during pfil_run_hooks(), which calls ipfw_check_hook(), where ip_len is converted to net byte order. Then ipfw_chk() is called (no other rules but a default allow), and back at the end of ipfw_check_hook(), ip_len is converted back to host byte order. But here the assert fails: after the conversion, ip_len is still in net byte order! I tried to find an explanation of how either ipfw_check_hook() or ipfw_chk() could possibly swap the byte order another time in between those two checks, but I couldn't find any. May I please ask an ipfw developer to take a look and review the analysis so far? Joerg Pulz might be available for further questions or patches. Thank you! Daniel _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[email protected]"
