From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 3BDB621F365 for ; Sun, 14 Sep 2014 00:45:16 -0700 (PDT) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XT4Uh-00021P-F8 for cerowrt-devel@lists.bufferbloat.net; Sun, 14 Sep 2014 09:45:12 +0200 Received: from CPE-60-231-27-24.lns5.cha.bigpond.net.au ([60.231.27.24]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 14 Sep 2014 09:45:11 +0200 Received: from rocon46 by CPE-60-231-27-24.lns5.cha.bigpond.net.au with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 14 Sep 2014 09:45:11 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: cerowrt-devel@lists.bufferbloat.net From: Richard Date: Sun, 14 Sep 2014 07:45:01 +0000 (UTC) Message-ID: References: <55089E42-3800-42B9-AD4D-D6186C0335FE@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 60.231.27.24 (Mozilla/5.0 (Windows NT 6.2; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0) 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: Sun, 14 Sep 2014 07:45:46 -0000 Sebastian Moeller gmx.de> writes: > > Hi Richard, > > On Sep 13, 2014, at 20:06 , Richard hotmail.com> 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. > > > > 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. > > > > 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…) I had a script I ran which just added DSCP MARKs in the -t mangle FORWARD table. To save me from deleting them if I made any changes, the script restarted both the firewall and SQM before adding my rules. It restarted them using the "/etc/init.d/firewall restart" and "/etc/init.d/sqm restart" commands. Messing about, using both the gui and reverting the script to use 'restart' instead of 'stop' and 'start', to try and trigger the problem again hasn't been fruitful. I've been unable to recreate it I'm afraid. > BTW, I tend to deselect the “enable” box in the GUI and then hit the “Save & Apply” 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… (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) > > > > > 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. > > > > > > 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. > > > > 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. Great! I'll keep that in mind next time instead of doing a hard reset. > I always re-entered the network configuration via the GUI on each upgrade (but only used sysupgrade > images for ages, with the “-n” flag specified to not keep old config files…) Wasn't aware of the -n flag. At least I don't have to TFTP to update the firmware anymore... > > > 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. > > > > 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... > > Just a thought. > > > > I think that's about it. > > > > > > 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’s nice numbering scheme... > > > > > 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… > Ah, well, I guess I have nothing to worry about then. I was worried that having Cero not handle my external address mainly might 'cause fq_codel not to work as well as it should. Hearing that you run a double NAT scenario with everything still working eases that worry. I have chosen to disable ICMP echo requests on the gateway, though, as it's something I can't seem to forward to Cero. Excessive requests might fudge the traffic shaping as it's something Cerowrt can't take into account. I'm aware it might break some websites that use MTU path discovery, but I figured using MSS clamping in Cero would solve any problems that might incur. That's my reasoning for it, anyway. Thanks for the input. Richard > Best Regards > Sebastian > > > > > 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. > > > > Hope this helps! > > —Regards, Richard > > > > _______________________________________________ > > Cerowrt-devel mailing list > > Cerowrt-devel lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/cerowrt-devel > >