Almost there - but...

After 16 days of uptime (a new record) monowall went down. The device was 
rebooted but went down again a couple of hours later.

It seems that denying ICMP data does prolong the uptime of monowall, but 
apparently it's not enough.

My next steps are:
1) Deny fragmented packages in general
2) Move management to HTTPS
3) Install an I-BOOT device (http://www.dataprobe.com/power/iboot.html)
4) Find out if anyone returned from vacation and if so - find out which 
hardware rejoined the setup.

I have a couple of questions for the list:
1) Is there *ANY* way that mini_httpd can crash the entire box?
2) If you have a device that locks up: Are you allowing management from WAN
3) If you have a device that locks up: Are you allowing any type of 
fragmented data?
4) Anyone getting closer to a solution?

BR
Søren Vanggaard Jensen





>From: Lee Sharp <leesharp at hal dash pc dot org>
>To: "Soren Vanggaard Jensen" <svanggaard at hotmail dot com>,akemp at iquest dot net, 
>m0n0wall at lists dot m0n0 dot ch
>Subject: Re: [m0n0wall] Version 1.22 freeze
>Date: Thu, 06 Jul 2006 15:48:14 -0500
>
>On Thu, 06 Jul 2006 12:59:41 +0000
>  "Soren Vanggaard Jensen" <svanggaard at hotmail dot com> wrote:
>>It seems my case is getting stronger. Your posts and my uptime (now 6 
>>days, 6 hours - usually less than 2 days) since blocking all ICMP traffic.
>
>>Now, why is it that some (most) monowall installations dos not freeze even 
>>though outbound ICMP is allowed by default rules? I think there could be 2 
>>reasons:
>
>>1) The problem only occurs under heavy load conditions
>>2) The problem occurs only when a junk router, Accesspoint or PC (internet 
>>or LAN) does not handle fragmentation correctly.
>
>Or junk PC.  I have seen PCs with dieing nics send some bad stuff and knock 
>down an entire network.
>
>                       Lee