[Cerowrt-devel] cerowrt-next plans

[Dave Taht]

I did finally get around to booting the ubnt linux 3.6.7 build I
talked about yesterday.

Yea! It worked.

Boo! I have a ton of patches to modify to get back to equivalence with
what's in cerowort-3.3.8-27

So I'm planning on forking the "stable" cerowrt 3.3 repository for new
development on 3.6,
and am calling it cerowrt-next. I may blow it away entirely and rebase
on openwrt. Nobody
look!

In the interim perhaps I'll stick up the ubnt-3.6.7 code, but there
seems to be no demand, sooo...

Updates:

* Steven Walker made a bunch of updates to ceropackages the other day,
I haven't tested.
   thx steven. If anyone wants an updated ccnx-6.2, in particular, it's there...

* Openwrt Head
* Radvd must die - in favor of either dnsmasq or quagga

Backports:

* IPv6 performance patch
* Multiple versions of fq_codel
* QFQ+
* Wireless diffserv patch
* Memory reduction patches in pfifo_fast and codel

Whatever other patches didn't make it up to openwrt

New development:

* Randomness/entropy framework infrastructure buildout
  The new randomness frame in 3.6 and later requires driver support in
order to work well.
  Good crypto in things like WPA, and SSL requires good entropy.

A lot of people have been thinking "ooh, random numbers fixed in
embedded linux since 3.6"

Um, no. Well, partially...

http://lwn.net/Articles/507115/

* TCP Fast Open test support
  TCP fast open is supported server side in 3.6. There is some
preliminary support for it in netperf now

* AHCP in dnsmasq

  After watching the deliberations on homenet, and knowing ahcp fits a
niche not addressed there,
  and knowing that it solves a need that cannot be met by SLAAC, dhcp,
dhcp-pd, or ospf+pd,
  and after losing many battles with ahcpd, and knowing AHCP NEEDS TWO
implementations
   to go ietf standard track...

  I started hacking on the core idea one weekend 18 months ago. I
figured if I just got a couple weekends
  more free I'd be able to get the protocol into dnsmasq at the cost
of a couple k in binary, and save a mb of ram.

   I decided that dnsmasq was the right place to stick it, given that
it managed address assignment
   already for multiple other protocols. It turns out than an AHCP
server is even simpler than the
   client. I then started having some thoughts towards having prefix
distribution and border discovery in it...

   and felt that writing a fresh implementation would be a good start
towards understanding these
   complex issues.

  Sadly, those weekends have not happened yet.  :(

  It would be nice to find someone to work with to continue getting
this into dnsmasq. ? Even as an exercise,
  it's a good exploration into how ipv6 multicast actually works....

  Anyway I just folded in somepatches that compiled and opened up the
port into the current dnsmasq tree
  and put it up on github. It does very little else...

  My github repo for dnsmasq-ahcp: https://github.com/dtaht/dnsmasq-ahcp
  Protocol Specification:
http://www.pps.univ-paris-diderot.fr/~jch/software/ahcp/draft-chroboczek-ahcp-00.html
  existing ahcp server/client code and doc:
http://www.pps.univ-paris-diderot.fr/~jch/software/ahcp/

  Alternatively getting another ahcp server written in another
language would be good.

* DLNA (?)
* small DHCP-PD support

Wide is not working out, isc and dibbler are too huge. It's time for
someone to write a small one... (not me!)

Other suggestions for the upcoming development cycle?

-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html