|
||||||||||
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 > > |