From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp191.iad.emailsrvr.com (smtp191.iad.emailsrvr.com [207.97.245.191]) (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 0635E21F115 for ; Mon, 21 Jan 2013 13:47:40 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp29.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 71D50148611; Mon, 21 Jan 2013 16:47:39 -0500 (EST) X-Virus-Scanned: OK Received: from legacy2.wa-web.iad1a (legacy2.wa-web.iad1a.rsapps.net [192.168.2.218]) by smtp29.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 504771485D5; Mon, 21 Jan 2013 16:47:39 -0500 (EST) Received: from reed.com (localhost [127.0.0.1]) by legacy2.wa-web.iad1a (Postfix) with ESMTP id 29636E00B6; Mon, 21 Jan 2013 16:47:39 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Mon, 21 Jan 2013 16:47:39 -0500 (EST) Date: Mon, 21 Jan 2013 16:47:39 -0500 (EST) From: dpreed@reed.com To: "Dave Taht" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20130121164739000000_17842" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: Message-ID: <1358804859.167924837@apps.rackspace.com> X-Mailer: webmail7.0 Cc: cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] cerowrt-3.7.3-2 released 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: Mon, 21 Jan 2013 21:47:41 -0000 ------=_20130121164739000000_17842 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AHow random do you need things to be? Security needs true randomness, b= ut there is nothing else I know of where you need "entropy" sources to achi= eve sufficient unpredictability to meet the need of some algorithm. A simp= le pseudo-random sequence is good enough.=0A =0A-----Original Message-----= =0AFrom: "Dave Taht" =0ASent: Monday, January 21, 2013= 2:47pm=0ATo: cerowrt-devel@lists.bufferbloat.net=0ASubject: [Cerowrt-devel= ] cerowrt-3.7.3-2 released=0A=0A=0A=0AAnd is at:=0A=0A[http://snapon.lab.bu= fferbloat.net/~cero2/cerowrt/wndr/3.7.3-2] http://snapon.lab.bufferbloat.ne= t/~cero2/cerowrt/wndr/3.7.3-2=0A=0A+ resync with openwrt=0A+ uftp4 alpha = =0A+ quagga update=0A + Hopefully the last ipv6 instruction traps killed (t= hx ketan and robert!)=0A- I see rngd eating a ton of cpu on a given transfe= r. I'd been meaning to look at the quality of the new entropy stuff for age= s, and have long hoped to be rid of that daemon=0A=0AAfter we do a bit more= testing I'll tag and push the source to this version, and then get crackin= g on higher layers in the stack again.=0A=0AA bit about uftp4 support. My i= ntent with getting uftp into cerowrt 18 months ago was to have an easy mult= icast test, which would let someone (for example) set a rate of 1Mbit and o= bserve what happens to a wireless network, observe packet loss at various d= istances from the AP, etc, as well as get a grip on the timing delays induc= ed by the power save mode in wifi (basically storing all multicast content = and broadcasting it as "content after beacon", (CAP, also known colloquiall= y as "crap after beacon"))...=0A=0AAnyway, while I was thinking that as my = basic use case in this project... =0A=0ADennis Bush was actually off making= a new version do more useful things. We got to talking last week... I've t= ried the ipv4 support and it's nifty. Ipv6 didn't work but perhaps my x86 b= uild is bad.=0A=0A-- =0ADave T=C3=A4ht=0A=0AFixing bufferbloat with cerowrt= : [http://www.teklibre.com/cerowrt/subscribe.html] http://www.teklibre.com/= cerowrt/subscribe.html ------=_20130121164739000000_17842 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= How random do you need things to be?   Security needs true random= ness, but there is nothing else I know of where you need "entropy" sources = to achieve sufficient unpredictability to meet the need of some algorithm.&= nbsp; A simple pseudo-random sequence is good enough.

=0A

 

=0A

-----Origin= al Message-----
From: "Dave Taht" <dave.taht@gmail.com>
Sen= t: Monday, January 21, 2013 2:47pm
To: cerowrt-devel@lists.bufferbloat= .net
Subject: [Cerowrt-devel] cerowrt-3.7.3-2 released

= =0A
=0A

And= is at:

http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/3.7= .3-2

+ resync with openwrt
+ uftp4 alpha
+ quagga= update
+ Hopefully the last ipv6 instruction traps killed (thx ketan= and robert!)
- I see rngd eating a ton of cpu on a given transfer. I'= d been meaning to look at the quality of the new entropy stuff for ages, an= d have long hoped to be rid of that daemon

After we do a bit mor= e testing I'll tag and push the source to this version, and then get cracki= ng on higher layers in the stack again.

A bit about uftp4 suppor= t. My intent with getting uftp into cerowrt 18 months ago was to have an ea= sy multicast test, which would let someone (for example) set a rate of 1Mbi= t and observe what happens to a wireless network, observe packet loss at va= rious distances from the AP, etc, as well as get a grip on the timing delay= s induced by the power save mode in wifi (basically storing all multicast c= ontent and broadcasting it as "content after beacon", (CAP, also known coll= oquially as "crap after beacon"))...

Anyway, while I was thinkin= g that as my basic use case in this project...

Dennis Bush was = actually off making a new version do more useful things. We got to talking = last week... I've tried the ipv4 support and it's nifty. Ipv6 didn't work b= ut perhaps my x86 build is bad.

--
Dave T=C3=A4ht
Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subsc= ribe.html

=0A
 ------=_20130121164739000000_17842--