From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (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 633F421F2FA for ; Sat, 7 Jun 2014 10:55:07 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id cc10so2472919wib.11 for ; Sat, 07 Jun 2014 10:55:05 -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:content-transfer-encoding; bh=vRcQ4WvoVJ9jrCs5zssM7ztAn+aOuxNALeMzhVq7fSU=; b=eVUkHojPJyhlBvlublhdf6BBDsV3D45O6MNX1TcIpokcM7CjcpkTmvT5wCQczKhwdZ O/ZVM/8P3CkhHPBaVjR4CMTqrbcEKnYrEoTaA6+7McYLCfUbpzmKIxhFoNjWfa5pP3B5 ci0tP9kCOSBHaRlsmFiCs2iAU3KP1k1PBbzbTGLy5c4xvo9sJ8DmgeVRJeZtLDWau6/p WmMmZqpt/H1XL6dSuaT6B23jGhlQWWnf4kb/APvl3R9B34MclIhkOIjrdYcdE0OAPXVc 0YGB1grJW9sPe6haPoF8hm4Cvk9DX0sIfW6oc6ffAucKTzno3HknKqlo3flY/IAHKzR8 b/ug== MIME-Version: 1.0 X-Received: by 10.194.87.170 with SMTP id az10mr16911985wjb.1.1402163705231; Sat, 07 Jun 2014 10:55:05 -0700 (PDT) Received: by 10.216.207.82 with HTTP; Sat, 7 Jun 2014 10:55:05 -0700 (PDT) In-Reply-To: <539307BE.9070509@etorok.net> References: <539307BE.9070509@etorok.net> Date: Sat, 7 Jun 2014 10:55:05 -0700 Message-ID: From: Dave Taht To: =?UTF-8?B?VMO2csO2ayBFZHdpbg==?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] cerowrt_stability? 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, 07 Jun 2014 17:55:07 -0000 On Sat, Jun 7, 2014 at 5:38 AM, T=C3=B6r=C3=B6k Edwin wrote: > On 06/06/2014 05:46 PM, Dave Taht wrote: >> 1)how many are encountering bug 442 regularly? >> >> Getting it to occur is hard for me. I've only seen in once in the last >> several weeks, jg can have it happen inside of two days. It mostly >> seems to occur in conditions of poor signal strength, near as I can tell= . >> >> 2) aside from that, how are things? > > I am quite happy with 3.10.40-5, although I might try -6 soon as apparent= ly that has a new dnsmasq. > I don't use wireless that often these days anymore, so I can't say about = that bug. > I didn't have troubles with DNSSEC with the default config. > IPv6 works reliably too, in fact it is too reliable :) It happened once t= hat I DHCP/IPv4 was broken, but IPv6 still worked. > > There are just 2 strange things that weren't reproducible [1], sorry that= I can't give you more than anecdotal evidence: > 1. I booted the router, the interface went up, I read my email, tried to= search on startpage.com, but it was down (or so I thought), > so I searched google, but then none of the links in google work ... ah th= ere is no IPV4 address ... > Running DHCP didn't give me anything, and manually setting an IP addres= s on eth0 didn't help either as I wasn't able to ping / ssh the router on I= Pv4 > (and apparently ssh doesn't work on IPv6, might be my fault though) > I was able to open the web interface on IPv6, tried restarting dnsmasq = but that didn't fix things, so I just rebooted the router and then it worke= d. One of the problems is that openwrt is moving away from using dnsmasq as a dhcp server, in favor of their tightly integrated odhcp server. This is the opposite direction in which I'd prefer, I'd like addressing and naming to be more closely tied together than they are, (and dnsmasq's dhcp and dhcpv6 implementations are more mature) but the size and complexity of the code base for dnsmasq is intimidating, and the functionality needed is tied to ubus, and dhcp is a fairly simple protocol to implement, so there we are. So I have been in cases where odhcpd AND dnsmasq get enabled for some reason or another and bad things happen. Currently the new hnetd code relies on odhcp not dnsmasq, for dhcp service. There is also an open bug in dnsmasq (race condition), that results in it running away and giving you the result you had. There's a fix in 2.72beta2 for it. > > 2. At some point my internet speed and latency become very bad. I don't k= now if this was due to the fault of my ISP or not, but a reboot fixed it. > > A ping looked like this (over an ethernet connection): > PING www.google.com (173.194.44.52) 56(84) bytes of data. > 64 bytes from muc03s08-in-f20.1e100.net (173.194.44.52): icmp_seq=3D1 ttl= =3D55 time=3D2467 ms > 64 bytes from muc03s08-in-f20.1e100.net (173.194.44.52): icmp_seq=3D2 ttl= =3D55 time=3D2502 ms > 64 bytes from muc03s08-in-f20.1e100.net (173.194.44.52): icmp_seq=3D3 ttl= =3D55 time=3D2349 ms > I have seen this in a specific situation - ping flood, or (in my case), I'd accidentally implemented a version of tcp more like tcp relentless - so I ended up pouring out packets at 1gigE into the router, which can only handle 300mbit forwarding at best, in this case, simple.qos was enabled, so only 20mbit was egressing. So although htb and fq_codel kept working, the cpu was overloaded, and packet buffers remained full, leading to really huge lag especially in simple.qos (which deprioritizes ping) in the range you mention. I've thought about improving or removing the overload search of the flow space in fq_codel for this reason. What happens when you exceed the packet limit is that it does a complete search of the flow space to find the biggest flow (scanning 4k of data each time), and drops packets from that flow. Dropping tail in that case would be simpler and nearly as effective. Bumping up codel's drop rate faster in that sort of situation might be good too. Still, the root of that problem to me was that we can take gigE in but only put 300mbit out, so I don't know if it would have done any good in that case. > The good news is that I had a VoIP call running at the time, and I could = still understand everyone, in fact I only noticed > something was wrong when I finished the call and people told me I was ver= y lagged with my replies. > I think thats a success for cerowrt's SQM, that voip was still able to wo= rk even on a very lagged and slow line :) > > P.S. I use a variation of the attached script to configure my router, whi= ch is based on the script from the wiki. > > Best regards, > --Edwin > > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel > --=20 Dave T=C3=A4ht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_= indecent.article