From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailhost.cotse.com (mail.cotse.net [66.203.85.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 41C5121F1A0 for ; Mon, 24 Mar 2014 18:16:19 -0700 (PDT) Received: from out.packetderm.com (out.packetderm.com [66.203.85.62]) by mailhost.cotse.com (8.14.5/8.14.5) with ESMTP id s2P1GHdS029387 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 24 Mar 2014 21:16:17 -0400 (EDT) (envelope-from cerowrt@decoy.cotse.net) Received: from localhost (localhost[127.0.0.1]) (authenticated bits=0) by smtp (5.7.4/5.7.4) with ESMTP id s2P1GHhs041604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Mon, 24 Mar 2014 21:16:17 -0400 (EDT) (envelope-from cerowrt@decoy.cotse.net) Message-ID: Date: Mon, 24 Mar 2014 21:16:17 -0400 From: Joseph Swick MIME-Version: 1.0 To: cerowrt-devel@lists.bufferbloat.net References: <20140324191203.GA78098@redoubt.spodhuis.org> <878urzia18.fsf@alrua-x1.karlstad.toke.dk> <5330AD18.5000508@etorok.net> <87lhvzgoiy.fsf@alrua-x1.karlstad.toke.dk> In-Reply-To: <87lhvzgoiy.fsf@alrua-x1.karlstad.toke.dk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [Cerowrt-devel] DNSSEC & NTP Bootstrapping 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: Tue, 25 Mar 2014 01:16:19 -0000 On 03/24/2014 07:33 PM, Toke Høiland-Jørgensen wrote: > Which is newer than -9 but older (I think; the tag is missing from > github) than -12. So an upgrade should probably fix it :) > > *off to upgrade my own install* > > -Toke > I just updated to .32-12 myself, I was on .28-16, and was seeing issues where dnsmasq would just stop serving up DNS requests. Hopefully if I'm watching the logfile I might see something if it happens again, but then I would also need to be watching the correct logfile. I do see a large jump in time after a cold-start in logread that goes from an old time to the correct time and logread -f does display the correct time. So it would look like that particular issue with logread might be fixed in -12. -Joseph