Date: Sun, 24 Jul 2005 15:46:01 +0200 From: Max Laier <max@love2party.net> To: freebsd-hackers@freebsd.org Cc: Edwin <edwin@verolan.com>, Giorgos Keramidas <keramida@freebsd.org> Subject: Re: help w/panic under heavy load - 5.4 Message-ID: <200507241546.08255.max@love2party.net> In-Reply-To: <20050724023845.GA15209@asx01.verolan.com> References: <20050719034215.GB20752@asx01.verolan.com> <200507240027.54127.max@love2party.net> <20050724023845.GA15209@asx01.verolan.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart3496715.Ok8sqIYstl Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 24 July 2005 04:38, Edwin wrote: > If I understand correctly...(albeit an overly brief understanding :)) > > 1. ethernet packet comes in - stuck into an mbuf > 2. ether_demux calls ip_fastforward passing the mbuf struct > 3. mbuf struct is copied/munged into ip struct by mtod > 4. ntohs is called to change ip->ip_len to host byte order > incidentally - ip_len should be set to ntohs(ip->ip_len) > as well - it seems like neither one of those calls worked? > 5. also - the call to set hlen to ip->ip_hl <<2 didn't work out well > either - right? since hlen =3D -1057417216, and i think it's > supposed to be 20 (5*4) - am I correct there as well? 4. and 5. are strange but not of too much significance. Given that we got= =20 through the initial sanity checks and that neither is used further down, th= is=20 might jut be an optimization effect. You could try to mark ip_len as=20 volatile. > 6. due to ip->ip_len being in network byte order still a little > gremlin helps us to think we have a 10240 byte packet and we > need to fragment it... > 7. in ip_fragment - ip->ip_len is still 10240 - so we assume that we > need to make several fragments - however, the mbuf is correct > (len =3D 40) > 8. in ip_fragment - to create the 'second' fragment, we try to copy > 1480 bytes @ offset 1500 out of the mbuf that only has a valid > data length of 40-bytes??? That's what happens, yes. > Are we really looking for the cause of ip->ip_len not being in the correct > order @ the right time then? - in that case - there's two possibilities > that I see - and I don't think that ntohs not working (1) is too realisti= c, > so I would suppose we are looking for what flipped it in the first place? > > 1. either ntohs didn't work for some reason, or > 2. it was already in host order, and the ntohs call flipped it back to > network order Neither seems very likely. My guess is really *something* along the way=20 messing things up - pfil is the only suspect I have, right now. > If you feel that it's a ipfw/ipfil issue - I can easily take IPFIREWALL* > options out of the kernel and build a new one - just give me about 15 > minutes. Yes please and make sure it isn't loaded as a module either. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart3496715.Ok8sqIYstl Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBC45ugXyyEoT62BG0RAtS1AJ9xYibWUEqzu7MT9dasOd5+b6ujcQCeMgZx U2/m9JEBc05ffYYLqcGA7h8= =l/Op -----END PGP SIGNATURE----- --nextPart3496715.Ok8sqIYstl--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200507241546.08255.max>