From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 5AF0521F35E for ; Sun, 14 Sep 2014 03:45:20 -0700 (PDT) Received: by mail-ob0-f171.google.com with SMTP id wn1so1951561obc.2 for ; Sun, 14 Sep 2014 03:45:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=L0h56yCc3z5zj63HdbUAME7wLklmXY2ViMjR9pGLQ4Q=; b=RqhuDQNSk6WFMQ3eMq2qldkjFKKgQc6SkdP1bJtRYVpnunrMC5F8CFgEudftFpgT5z QCbPJ4GI0sKE9M7Na5R8b0QPszBWa/YMH0tNxp06LEAqrk52NKxueHpJae3PegdLeDXK b01inh1pttqv8GMdog42lA/xvJB2IvIKz3gW1mYUSyhvng6oyxs3kGVNpvg57alS1lro +uR4m/MGmOlEO4oNBgK5+aQSYxukyxpm8unvB8gq8rmnx6u86wrMkPaDpVLFOWVE4VCi 4FDvO5N3XNiSOfFaQ5N4RN2c4DfAe0Ntw5VgoUk7XZ6WvSXulWyKT26FwcFgDR0ZWpnW B6lA== MIME-Version: 1.0 X-Received: by 10.60.65.135 with SMTP id x7mr20478910oes.45.1410691519610; Sun, 14 Sep 2014 03:45:19 -0700 (PDT) Received: by 10.202.227.76 with HTTP; Sun, 14 Sep 2014 03:45:19 -0700 (PDT) Received: by 10.202.227.76 with HTTP; Sun, 14 Sep 2014 03:45:19 -0700 (PDT) In-Reply-To: References: Date: Sun, 14 Sep 2014 03:45:19 -0700 Message-ID: From: Dave Taht To: Richard O Content-Type: multipart/alternative; boundary=001a11c20b7aea04ce05030436e7 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 10:45:49 -0000 --001a11c20b7aea04ce05030436e7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable One of the features of the work going on in the ubnt beta forums was the discovery that you can create named ifb interfaces. So we could switch sqm to a 1 to 1 mapping of ge00-ifb, se00-ifb, etc. and thus have an easier time tearing them down. I figure that QoS chain needs to be applied to the pppoe interface not the ge00 interface? I generally have encouraged folk to always reinstall from scratch. Now that we are maturing and getting stabler, in place upgrades are becoming more interesting... I generally have more faith in cero's fire walling and nat handling than most third party equipment. So bridging is often better. But what I'd like most to happen for dsl is finding a good openwrt compatible dsl/wifi modem and have that as something to recommend to debloat ers on that tech. On Sep 13, 2014 11:07 AM, "Richard" wrote: > Hi, all. End user here. Just thought I'd post a few possible bugs I've ru= n > 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 classificati= on > 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. > > 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 IF= Bs > 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 somethi= ng > which I thought was Bug #442 after updating to 3.10.50-1. I had moved fro= m > 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 o= n > 2.4 could get through - both to the internet and to the router itself. 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 onl= y > 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 pla= ce > 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? > > Right now, my setup consist of a gateway and I'm unable to put it in brid= ge > 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 Masqueradin= g > disabled and the firewall still up. Every device we have runs through Cer= o. > > I'd like to know anything at all before I decide to go looking for anothe= r > dedicated modem, or if I should even bother to go looking in the first > place. > > Hope this helps! > =E2=80=94Regards, Richard > > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel > --001a11c20b7aea04ce05030436e7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

One of the features of the work going on in the ubnt beta fo= rums was the discovery that you can create named ifb interfaces. So we coul= d switch sqm to a 1 to 1 mapping of ge00-ifb, se00-ifb, etc. and thus have = an easier time tearing them down.

I figure that QoS chain needs to be applied to the pppoe int= erface not the ge00 interface?

I generally have encouraged folk to always reinstall from sc= ratch. Now that we are maturing and getting stabler, in place upgrades are = becoming more interesting...

I generally have more faith in cero's fire walling and n= at handling than most third party equipment. So bridging is often better. B= ut what I'd like most to happen for dsl is finding a good openwrt compa= tible dsl/wifi modem and have that as something to recommend to debloat ers= on that tech.

On Sep 13, 2014 11:07 AM, "Richard" &l= t;rocon46@hotmail.com> wrote:=
Hi, all. End user h= ere. 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 be= en
reported or are intentional, but I figured it couldn't hurt to post the= m 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<= br> 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 sti= ll in
use. Doing this enough eventually fills up all available Blocks and then ingress shaping fails to start.

Workaround for me has been to SSH in, stop SQM completely, and then start i= t
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 n= o
longer have a modem to test PPPoE on; the one I had couldn't hold the D= SL
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<= br> 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<= br> 2.4 could get through - both to the internet and to the router itself. 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<= br> ever seem to run into this bug whenever I use a sysupgrade image, or restor= e
my settings from an archive.

Something I've noticed is that #442 (or something similar) never seems<= br> 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 t= he 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?

Right now, my setup consist of a gateway and I'm unable to put it in br= idge
mode. The gateway does NAT, has SPI disabled, and has a static route and DM= Z
defined towards Cero. Cero is connected to the end of it with Masquerading<= br> disabled and the firewall still up. Every device we have runs through Cero.=

I'd like to know anything at all before I decide to go looking for anot= her
dedicated modem, or if I should even bother to go looking in the first plac= e.

Hope this helps!
=E2=80=94Regards, Richard

_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.= bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel
--001a11c20b7aea04ce05030436e7--