Whoops... Sorry.
It's been a while since I've followed the devel kernel stuff. The only
address I remembered was the Linux kernel mailing list.
>
> > >From my /System.map around the value of EIP:
> >
> > c016eba0 t find_special
> > c016ecd0 t cleanup
> > c016ed40 t ip_fw_check
> > c016f2d0 t zero_fw_chain
>
> This trace is currupted: cleanup() is a leafnode. It's almost
> certainly the masq code barfing on a fragment. While that *shouldn't*
> happen, it doesn't surprise me since few people do this.
yes.. I noticed this later and looked up all the return addresses in the
call trace. Here's a better look:
Address closest to EIP and the addresses in the call trace (in order):
c016ecd0 t cleanup (EIP)
c016ed40 t ip_fw_check
c0170304 T ipfw_forward_check
c0149a6c T call_fw_firewall
c015819c T ip_forward
c0157538 T ip_rcv
c014c3f8 T net_bh
c0119570 T get_ioport_list
c010a560 T do_IRQ
c0108cec T ret_from_intr
c0107b7c T sys_rt_sigsuspend
And you're entirely right. It's barfing in ip_fw_check.
Unfortunately, it still barfs even with always defragment turned on. Unless
my kernel configuration is borked, there's still something that needs
fixing.
-- Brian Ristuccia brianr@osiris.ml.org bristucc@baynetworks.com bristucc@cs.uml.edu- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/