[ previous ] [ next ] [ threads ]
 
 From:  Manuel Kasper <mk at neon1 dot net>
 To:  Kasper Pedersen <m0n0list dash kkp2 at kasperkp dot dk>
 Cc:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] Post mortem autopsy on a dead monowall
 Date:  Tue, 14 Nov 2006 21:07:57 +0100
On 14.11.06 19:48 +0100, Kasper Pedersen wrote:

> became unresponsive and consumed 100% CPU. I froze the VM (and I
> still have the frozen one), copied the memory image to a Linux box,

Wow, that's the kind of bug report I've always been looking for! This
helps us much more than just "my m0n0wall locked up yesterday, and I
had to reboot it". :) Thanks, Kasper!

I should have more time to investigate this in detail later this
week, but in the meantime, I converted the packets from your
packetsearch.txt file into a pcap file for easier viewing with
Ethereal:

https://neon1.net/temp/packetsearch.cap

(Ethernet headers are bogus and packets were not truncated for proper
size so garbage may appear after the actual packet)

Some packets seem to be completely corrupted, and on the outer IP
header of the ICMP unreachables, the length field appears to have
already been swapped to host byte order by the kernel (i.e. 7682 is
probably actually 542 bytes, which makes sense since the inner IP
packet has 514 bytes, + 28 bytes for the IP/ICMP header).

I can't see any packets that have the More Fragments bit set or a
non-zero fragment offset, but still, something appears to be fishy
here, and I would not be surprised if ipfilter 3.4 choked on some
weird combination of fragmentation and ICMP messages. This is
definitely a good start.

> goes 'Aha!', my next approach, when the flu I've caught has passed,
> is to find/make a tool to send strange unreachables.

That would be very nice - or maybe try a few of the countless
existing tools that generate invalid ICMP packets.

Thanks again!

- Manuel