On 1/22/10 8:55 PM, Max Laier wrote:
On Friday 22 January 2010 19:49:19 John Baldwin wrote:
On Friday 22 January 2010 12:18:20 pm Max Laier wrote:
pf does change the byte order in the pfil hook, but changes it back on
return to the stack either when returning from the hook or when calling
back into the stack. There have been some issues where we missed returns
to the stack that would result in this situation, but since pf is not in
the trace, this is clearly not the case here.
That isn't necessarily the case. ip_input() invokes the PFIL hooks which
then return after possibly modifying the packet. The (possibly modified)
packet is then passed to ip_forward() from ip_input(). If the PFIL hook
modified the packet and returned ip_len in network byte order then it would
cause this breakage without showing up in the stack trace.
What I meant to say was: if we return from the pfil hook we either report
error (and/or consume the mbuf) or switch back to network byte order:
http://fxr.watson.org/fxr/source/contrib/pf/net/pf_ioctl.c?v=FREEBSD72#L3655
While I can't completely rule out that there is a double flip happening in
some obscure path through pf, I very much doubt this is what is going on (or
there would be more reports and it would happen straight away, not only after
passing some data). A quick search through the sources also didn't turn up
any red flags. All byte order operations inside pf are either temporary or
performed on a properly copied packet that is send back through the stack
(icmp error, tcp packet, ...).
Depending on how easily this can be reproduced, my money is on modifying a
shared mbuf (possibly inside enc(4)).
I have been running with a WITNESS kernel for 10 days now, and have
tried quite a few things to reproduce the problem, but no luck so far.
I'll post again if i find something.
Thanks to everyone involved!
Cheers,
Florian
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[email protected]"
