From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 726E521F365 for ; Sun, 14 Sep 2014 02:26:02 -0700 (PDT) Received: from hms-beagle.home.lan ([93.194.226.142]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0Lw1vh-1YPBtV0bE5-017in1; Sun, 14 Sep 2014 11:26:00 +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: Sun, 14 Sep 2014 11:25:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55089E42-3800-42B9-AD4D-D6186C0335FE@gmx.de> To: Richard X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:/riAgEOGrMPpNzS6FDK8lCakQQ8BmsDucDeVMvXnc3guTjIw1+K k/JMXnbBF/iUBJZ9QcVHP4l2pQKl9f9Gv7ZZCrJDfGnvWPeGiPodq9AwHZ/76Fab9hqYRN0 RnlPuWPVzSjFE6rQuasomNh3qo9Wu8vf9Ihmb9RMnU6a3pFzSWIP+iDOL5u4qYMRSiE+TtZ x01ELFE9xaYqe32dXL/wA== 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: Sun, 14 Sep 2014 09:26:32 -0000 Hi Richard, On Sep 14, 2014, at 09:45 , Richard wrote: > Sebastian Moeller gmx.de> writes: >=20 >>=20 >> Hi Richard, >>=20 >> On Sep 13, 2014, at 20:06 , Richard hotmail.com> wrote: >>=20 >>> 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. >>=20 >> 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) >=20 >=20 > 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. Too bad, in case you find a way to force this failure mode, = please let me know so I can have a go at fixing it... >=20 >=20 >=20 >> 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 >>>=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. >>=20 >> 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. >=20 >=20 > Great! I'll keep that in mind next time instead of doing a hard reset. >=20 >=20 >> 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) >=20 >=20 > Wasn't aware of the -n flag. At least I don't have to TFTP to update = the > firmware anymore=85 I think a number of people have been quite happy with the = sysupgrade via the GUI (just de-select the =93keep sttings=94 check box = and you should be fine). I think what really could cause the issues = observed is when SQM's stop.sh fails half-way through (I will try to = have a look at that later...) >=20 >=20 >>=20 >>> 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? >>=20 >> Potentially you could avoid double NAT by having cerowrt handle = the pppoe > session and still keep >> cerowrt=92s nice numbering scheme... >>=20 >>>=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. >>=20 >> 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 >>=20 >=20 > 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. In theory fq_codel could not care less, as long as it is in = control of the bottleneck all should be fine, and latency under load = should remain well-behaved. >=20 > I have chosen to disable ICMP echo requests on the gateway, though, as = it's > something I can't seem to forward to Cero. Well, my ISP router does not respond to echo requests and does = not allow me to forward them to downstream devices and yet things just = work (note I am still ruing IPv4) > Excessive requests might fudge > the traffic shaping as it's something Cerowrt can't take into account. But that is a systematic problem with downstream shaping after = the the bottleneck-link (by creation of an artificial bottleneck), too = much incoming traffic of any kind will cause backlog in the buffers of = the device at the upstream end of the real bottleneck-link=85 So even if = the ICMP packets reach cerowrt this might still hose the downstream = latency under load... > 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.=20 I would hope that the real xdsl-router handles either the MSS = clamping for us or better yet properly handles the IPv6 path mtu = discovery (and at least in may case that works well) Best Regards Sebastian >=20 > Thanks for the input. > Richard >=20 >> Best Regards >> Sebastian >>=20 >>>=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 >>=20 >>=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel