[ previous ] [ next ] [ threads ]
 
 From:  Fred Wright <fw at well dot com>
 To:  Dave Warren <MailList at devilsplayground dot net>, Jesse Guardiani <jesse at wingnet dot net>
 Cc:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: several messages
 Date:  Tue, 8 Feb 2005 12:38:45 -0800 (PST)
On Sun, 6 Feb 2005, Dave Warren wrote:

> > > >> 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.
> > > > 
> > > > 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?
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
> 
> 

On Mon, 7 Feb 2005, Jesse Guardiani wrote:

> Manuel Kasper wrote:
> 
> > On 04.02.2005 11:21 -0500, Jesse Guardiani wrote:
> > 
> >> Personally, I've seen just the opposite. Lots of CPU utilization
> >> on the first click, and very little on subsequent clicks.
> >> 
> >> Where is this CPU utilization info being pulled from? Can someone
> >> describe the algorithm?
> > 
> > The CPU load is sampled at the very moment you load index.php.
> > Unfortunately there's no way to get the current CPU load in figures
> > that are meaningful to most users (i.e. percent) without sampling the
> > CPU tick counters, waiting for a second and then sampling again.
> > That's also the way top(1) does it.
> > 
> > Even more unfortunately though, since most browsers also try to
> > reload the images and CSS when you refresh the page, on slower
> > platforms you get 100% CPU the moment the CPU load is sampled.
> > 
> > I haven't been able to come up with a better solution for this yet.
> > We could run a daemon to keep track of the CPU %, but wasting an
> > entire process for this would be a bit of an overkill.
> 
> 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.
> 
> -- 
> Jesse Guardiani, Systems Administrator
> WingNET Internet Services,
> P.O. Box 2605 // Cleveland, TN 37320-2605
> 423-559-LINK (v)  423-559-5145 (f)
> http://www.wingnet.net
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
> 
> 

On Mon, 7 Feb 2005, Jesse Guardiani wrote:

> OK, here's a summarized update:
> 
> Jesse Guardiani wrote:
> 
> > Hello,
> > 
> > I've been working a lot with m0n0wall lately, and
> > since I've run both 1.11 and 1.2b3, and I read this
> > list, I have come up with a minimal list of things
> > that are broken in 1.2b3. This list is not meant to
> > be all-inclusive. It is merely my observations.
> > However, I hope we can get together a list of
> > outstanding 1.2b3 issues to fix before 1.2 final
> > based on this list or something similar. In no
> > particular order:
> > 
> > 1.) bridging
> >         This seems totally broken in 1.2b3. I've
> >         been testing all night on a soekris 4801
> >         and I can't get any form of bridging working
> >         in 1.2b3. I can downgrade my firmware to
> >         1.11, get a working config, then upgrade to
> >         1.2b3 and it's instantly broken.
> 
> I was testing with the OPT1 interface bridged to the
> WAN interface, and a static IP bound to the WAN interface.
> 
> I've found that if I remove the static IP from the WAN
> interface that bridging becomes truly transparent under
> 1.11, and works equally well under 1.2b3. I've asked Manuel
> if we can add a knob to the webGUI to make it easier to
> assign "no IP" to the WAN interface. I had to clear mine
> by manually editing my config.xml file and then restoring it
> to my running m0n0wall box.
> 
> In addition, we need to confirm that creating bridge
> under 1.2b3 between OPT1 and WAN and a static IP on WAN
> does *NOT* work. If this is the case then perhaps we need
> to find some way to disallow this sort of misconfiguration
> or otherwise fix to underlying problem, if any.
> 
> 
> > 2.) lockups on WRAP hardware
> >         for some reason 1.2b3 causes lockups on WRAP
> >         hardware. I didn't see any resolutions to this
> >         in the archive, so I'm guessing this is an
> >         ongoing problem.
> 
> I've seen two possible explanations:
> 
> a.) a bad batch of WRAPS was supposedly produce around Sept 2004.
>     (this seems a bit unlikely as 1.2b2 seems to work fine on the
>      affected WRAPs)
> b.) perhaps the kernel HZ bump between 1.2b2 and 1.2b3 to 1000hz
>     is bringing out flaws in some WRAP older/buggy hardware/firmware?
> 
> It might help if we could collect the BIOS revision and hardware
> revision numbers of the affected boards.
> 
> 
> > 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
> see the new FAQ:
>     http://m0n0.ch/wall/docbook/faq-ssh-timeout.html
> 
> 
> > 4.) Captive Portal flakiness
> >         Captive Portal fails to honor MAC pass-through
> >         sometimes under 1.2b3. This is strange as it
> >         seems intermittent, but I've had it happen at
> >         least twice. Also, I've seen a lot of other
> >         posts regarding Captive Portal lately. Are
> >         there any other confirmed issues in 1.2b3?
> 
> No progress on this yet. I'll try to get some more concrete
> data soon.
> 
> In addition, I think we can add these to the list:
> 
> 5.) In both 1.11 and 1.2b3, Traffic Shaper appears to *NOT*
>     affect uploads on filtered, bridged connections. Please
>     see this thread for more info:
>     http://thread.gmane.org/gmane.comp.security.firewalls.m0n0wall/13358
> 
> 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.
> 
> Have I missed any issues? I try to read all of the posts, but I
> can't always be sure what's user error and what's a bug/issue.
>   
> 
> -- 
> Jesse Guardiani, Systems Administrator
> WingNET Internet Services,
> P.O. Box 2605 // Cleveland, TN 37320-2605
> 423-559-LINK (v)  423-559-5145 (f)
> http://www.wingnet.net
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
> 
>