help w/panic under heavy load - 5.4

[Max Laier]

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 = -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 
through the initial sanity checks and that neither is used further down, this 
might jut be an optimization effect.  You could try to mark ip_len as 
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 = 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 realistic,
> 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 
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.

-- 
/"\  Best regards,                      | mlaier at freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier at EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20050724/7517c295/attachment.bin