[ previous ] [ next ] [ threads ]
 
 From:  Fred Wright <fw at well dot com>
 To:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] known issues with 1.2b3
 Date:  Tue, 8 Feb 2005 12:53:29 -0800 (PST)
On Sun, 6 Feb 2005, Dave Warren wrote:

> > > > That's because as of 1.2b2, the TCP idle timeout for the firewall
> > is
> > > > 2.5 hours instead of the ipfilter default of 10 days (!) to keep
> > the
> > 
> > Why "(!)"?  I've sometimes kept remote console sessions up for days at
> > a time. :-)
> 
> Sure, but have you ever needed to leave it completely idle for days at a time?

Well, that particular system likes to generate peiodic output, but I was
mainly taking issue with the implication that there was something
ridculous about wanting a TCP connection up for 10 days. :-)

On Mon, 7 Feb 2005, Jesse Guardiani wrote:
> Manuel Kasper wrote:
> 
> 
> We're already running something to serve SNMP, right? Why not make
> sure that the SNMP daemon polls CPU? Then we kill two birds with one
> stone. We can poll the SNMP daemon locally to grab current CPU
> utilization for the status indicator, and those of us who would like
> to be able to graph CPU utilization will be able to do so.

You're assuming that the SNMPd wakes up periodically regardless of
incoming requests.

On Mon, 7 Feb 2005, Jesse Guardiani wrote:

> OK, here's a summarized update:
> 
> > 3.) TCP/IP connection drops
> >         My SSH connections die after about 2 hours
> >         under 1.2b3. I don't think this used to happen
> >         under 1.11. Someone else confirmed that this
> >         happens to them too. The connection isn't
> >         denied. It seems like it times out.
> 
> I think this one can be considered "resolved". I believe it
> was necessary due to the kernel HZ change, correct? Please

I never suggested that the timeout change had any relation to the HZ
change.  I mentioned the HZ change because, of all the changes listed in
the release notes, it seems like the one most likely to explain the WRAP
problem.  Even at that it's a long shot.

> 6.) The CPU meter on the status page is a bit quirky due to the
>     way CPU is sampled. The first time the meter is displayed it
>     reads higher than it should. In addition, if the refresh
>     button is clicked on the browser instead of the Status -> System
>     hyperlink then CPU usage reads higher than it should by about
>     30%.
> 
>     We can always write an FAQ about this, but I think it would be
>     better to fix the algorithm or polling method.

A simple workaround might be to have an "Update" button on the page, so
that it's unnecessary to use the browser's Reload/Refresh button.

					Fred Wright