--juZjCTNxrMaZdGZC
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 15, 2006 at 09:08:45AM +0000, Michael van Elst wrote:
> martin@duskware.de (Martin Husemann) writes:
>=20
> >On Thu, Jun 15, 2006 at 08:31:12AM +0000, Emmanuel Dreyfus wrote:
> >> I experienced this unpleasant panic. I wonder if this issue is caused
> >> by some kernel data inconsistency (which means that the panic is legit=
imate),
> >> or by a bogus packet (which means we should only issue a warning and d=
rop
> >> the packet).
>=20
> >Or just m_pullup()? (no idea what ipsec splithdr does, so this might be a
> >stupid suggestion)
>=20
> It removes the IP header from an _outgoing_ packet before encapsulation.
>=20
> If the packet is generated on the host itself, the panic could be ok.
> If the packet is received and routed into an ipsec tunnel, it should
> have been dropped before. Maybe there is some optimization that
> skips checks for routed packets?

Actually, this can readily happen if something calls m_pulldown(). It will
leave a small or zero-length (I think zero, but I'm not 100% sure) mbuf at
the head of the chain and have everything in the next PDU along.

While I agree we should drop a packet that has zero length, just because=20
the first mbuf has zero length doesn't mean we should throw the thing out.=
=20
:-) Look at the next mbuf in the chain.

Take care,

Bill

--juZjCTNxrMaZdGZC
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFEl3jSWz+3JHUci9cRAmzoAJ9so+zimC8HZCTsRemnXE4AReYM4wCcD1II
V2gpFIiHmiWrbTY7hea7Sjs=
=ZE8C
-----END PGP SIGNATURE-----

--juZjCTNxrMaZdGZC--