-----BEGIN PGP SIGNED MESSAGE-----
pskb_may_pull() is documented (well, __pskb_pull_tail) as:
* 2. It may change skb pointers.
I don't see that it actually moves or changes any of the pointers.
However, since it may move the data around, clearly the may go bad.
{We think we should be calling pskb_may_pull() on 2.4.4 and later to
reassemble all the fragments of an ESP packet into a single skbuff so that we
can decrypt it. Writing a decrypt routing to walk fragments isn't high on our
list of things to do, although we could probably steal an mbuf-capable one
from KAME}
My guess is that this screws the "h" pointers, and the "nh" pointers,
as well as the "mac" pointers.
skb->data should be correct.
mac.raw is trivially skb->data, I think.
(At least, for ethernet)
nh.iph may move depending on presence of 802.3 options, etc. Is there a simple
call to have it recalculated? I don't that we can rely on
dev->hard_header_len for incoming!
h.raw can be determined by adding nh.iph->ihl<<2.
Since we actually don't care about mac.raw at all, just nh.iph, if there is
a way to preserve that we, would be happy. Perhaps advancing skb->data to
nh.iph before calling pskb_may_pull().
Also, we have some code that says:
#ifdef IPH_is_SKB_PULLED
/* In Linux 2.4.4, the IP header has been skb_pull()ed before the
packet is passed to us. So we'll skb_push() to get back to it. */
if (skb->data == skb->h.raw) {
skb_push(skb, skb->h.raw - skb->nh.raw);
}
#endif /* IPH_is_SKB_PULLED */
It appears that we never enabled it, not is it clear when we should :-)
But, is there a document that explains how the skbuff is arranged on
different versions upon entry to the protocol_rcv() function?
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr@xxxxxxxxxxxxxxxxxxxxxx http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Finger me for keys
iQCVAwUBPAA7o4qHRg3pndX9AQGsIAP/ZAT8btc8+pgGD1gGfpi77/h6nk67qyRz
AcQpmr6nwgH5z0aiXRMK5WMvd04DVwPMTCYJiqIHG79kldGe93x4Szi2CtD/BnWX
uDCm0vk9P3lbDNO99RZGf0OzuWxWHzzioS8+Fdbabjurnk/CKUbHduSIVtLQ6HYV
dZyPYHcdswo=
=8jmz
-----END PGP SIGNATURE-----
|