From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 0441321F3C4 for ; Sat, 13 Sep 2014 12:28:00 -0700 (PDT) Received: from hms-beagle.home.lan ([93.194.226.142]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MIe0O-1XV4qJ0Fmi-002Dbv; Sat, 13 Sep 2014 21:27:55 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sebastian Moeller In-Reply-To: Date: Sat, 13 Sep 2014 21:27:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <55089E42-3800-42B9-AD4D-D6186C0335FE@gmx.de> References: To: Richard X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:WYb/iXOBYQnby9W4Kn9SUtzVCzTAjupAuayA/jcsJ8gFfaSN2Ng RjRh9hwXI+dlz0hkhV4gDILXcJ31YCUsMwLscjRltwqjz8FiBOIQwxeLOxMvUiPwMHfVu6H ZWQU+45XTtcACyAhsoPSbkIOvyY6DcLLq8J96eUAPFzx0ZuGVUOStVaU+Q+mFW4N317k2hK 3HMP/S1/UmNP6aXR2WXWw== X-UI-Out-Filterresults: notjunk:1; Cc: cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] Possible Bug(s) in Cero 3.10.50-1 X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Sep 2014 19:28:29 -0000 Hi Richard, On Sep 13, 2014, at 20:06 , Richard wrote: > Hi, all. End user here. Just thought I'd post a few possible bugs I've = run > into since updating to 3.10.50-1. I'm not exactly sure if these have = been > reported or are intentional, but I figured it couldn't hurt to post = them anyway. >=20 > 1) When using PPPoE on the outbound interface, traffic skips = classification > MARKS set by iptables in the QOS_MARK_ge00 chain entirely. This is = whilst > using simple.qos. Everything is placed in the 1:12 class in HTB in = both > ingress and egress regardless of rules set. This was tried using = 3.10.34-4 > and then a fresh install of 3.10.50-1. >=20 > 2) In 3.10.50-1, whilst running multiple Intermediate Functional = Blocks, > restarting SQM often has a chance to not close IFBs after the first = IFB. i.e > Anything after ifb0 has a chance to not close. Cero then creates a new > Block(s) after the ones that haven't closed as it believes they are = still in > use. Doing this enough eventually fills up all available Blocks and = then > ingress shaping fails to start. Ah, so how do you get into this situation from the GUI exactly? = If you have a simple set of steps to get to this failure mode I would = appreciate to learn. So that I can go fix the IFB detection in cerowrt = (one of the issues with IFBs is that I can figure out if (and which) fib = is attached to a real interface, but I have found no way to query an IFB = to figure out which interface it is attached to; so SQM currently tries = to reuse its own IFB devices, but that fails if they are detached from = their real interface before sqm-scripts sees them. Also SQM takes IFB = down after use and avoid to reassign up IFBs that are not attached to = interfaces for which SQM is active=85) BTW, I tend to deselect the =93enable=94 box in the GUI and then = hit the =93Save & Apply=94 button which does not lead to an excess in = generated/blocked IFBs for me, but maybe a different approach to = interact with the GUI leads to the IFB inflation. But no matter what the = cause, I would like to fix that=85 (the whole idea of the complicated = IFB handling was to allow SQM to coexist nicely with manually configured = IFBs so the hands-off approach if SQM is not sure who owns an IFB) >=20 > Workaround for me has been to SSH in, stop SQM completely, and then = start it > back up again whenever I change settings as that ensures any lingering = IFBs > are closed down.=20 >=20 >=20 > Unfortunately, I foolishly forgot to keep any logs using cerostats.sh = and no > longer have a modem to test PPPoE on; the one I had couldn't hold the = DSL > line for very long and was subsequently returned. I also ran into = something > which I thought was Bug #442 after updating to 3.10.50-1. I had moved = from > 3.10.34-4 using the sysupgrade image. >=20 > The router seemed to lock up twice within the first 15mins after boot = and > again after reboot. Only the 2.4Ghz network went nuts while 5Ghz = remained > fine. Everything on the 2.4Ghz network was still connected, yet = nothing on > 2.4 could get through - both to the internet and to the router itself. Interestingly, I had similar things happen on the same radio, in = may case disabling an re-enabling the wifi interfaces for the 2.4GHz = radio solved to issue, but that was before 3.10.50-1, no lock ups with = that. I always re-entered the network configuration via the GUI on each = upgrade (but only used sysupgrade images for ages, with the =93-n=94 = flag specified to not keep old config files=85) > I > then decided to do a clean install and haven't run into it since. This = is > something which has happened to me before on an earlier release and I = only > ever seem to run into this bug whenever I use a sysupgrade image, or = restore > my settings from an archive.=20 >=20 > Something I've noticed is that #442 (or something similar) never seems > happen if I do a clean install and rewrite my settings from scratch...=20= > Just a thought. >=20 > I think that's about it. >=20 >=20 > And if anyone's willing to answer this, I know this isn't exactly the = place > ask this, but, aside from having Cero handle external ICMPs requests, = is > there any inherent performance/security/bufferbloat benefits from = having > Cero handle my external ip over a gateway --> router combo? Potentially you could avoid double NAT by having cerowrt handle = the pppoe session and still keep cerowrt=92s nice numbering scheme... >=20 > Right now, my setup consist of a gateway and I'm unable to put it in = bridge > mode. The gateway does NAT, has SPI disabled, and has a static route = and DMZ > defined towards Cero. Cero is connected to the end of it with = Masquerading > disabled and the firewall still up. Every device we have runs through = Cero. So I have something similar, except the ISP router does not = allow to disable the firewall or configure a DMZ or enable ICMP echo = requests from the outside, but all end devices are connected via cerowrt = in default mode (NAT and firewall active), so basically double NATed. = But so far everything work just fine. On the plus side, if I = configure/upgrade cerowrt in un-usable state there is still the ISP = router to fall back to=85 Best Regards Sebastian >=20 > I'd like to know anything at all before I decide to go looking for = another > dedicated modem, or if I should even bother to go looking in the first = place. >=20 > Hope this helps! > =97Regards, Richard >=20 > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel