cerowrt-next plans

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

RE: [Cerowrt-devel] cerowrt-next plans

[dpreed]

[-- Attachment #1: Type: text/plain, Size: 6315 bytes --]


Regarding AHCP...  it occurs to me that AHCP might be a better choice than the alternatives for use in Amateur Radio internet environments with IPv6.
 
I would like to see a very future-oriented approach to IPv6 in Amateur Radio.   There are some quirks in the rules for Amateur Radio that mean that Amateur Radio subnetworks (unlike "open wireless" networks) have to have every message transported directly traceable to a licensed operator, cannot be obscured, and cannot contain "music".   (I know, the rebel in me feels this is not a good thing, but when operating with my Ham hat, I understand the reason to color within these lines, in order to be a "good netizen" in Ham circles, and to be constructive in gaining support from the various constituencies that support Amateur Radio's special status worldwide. There is no benefit whatever to using terms like "war-driving" in conjunction with Amateur Radio just to get your name in the papers).
 
It's perfectly reasonable to carry IPv6 traffic as datagrams over radio networks operated by cooperating Amateurs. (and could be hugely beneficial in situations like Hurricane Sandy)  What we don't have is a "stack" that is best tuned for this style of internetworking.
 
Part of the stack needs to include IPv6 address assignment and routing, and also bufferbloat-prevention.  My thought is that AHCP and other components useful for Cerowrt deployment would be suitable for an Amateur Radio IPv6 stack.  Also, I have some ideas about low-level ways to ensure that there is always a responsible, licensed "control operator" for any messages delivered over Amateur Radio-licensed IPv6 transport paths, which I have begun working on.
 
That long discursion suggests that a simple AHCP server and client implementation would be very, very helpful in a wider scope of usage.  One that brought IPv6 to Raspberry Pi might be just the ticket, since interfacing such a board to off-the-shelf transceivers is pretty easy for many Ham hobbyists.  (beware - you really should be aware of the "band management" done by the ARRL, so you stay in the subbands where digital signalling is encouraged.  The 1.2 GHz band and above are preferable, and maybe the digital portion of  440 MHz, esp. if you don't disrupt the FM phone activity there).
 
-----Original Message-----
From: "Dave Taht" <dave.taht@gmail.com>
Sent: Friday, November 23, 2012 12:27pm
To: cerowrt-devel@lists.bufferbloat.net, "bloat-devel" <bloat-devel@lists.bufferbloat.net>
Subject: [Cerowrt-devel] cerowrt-next plans



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
_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[-- Attachment #2: Type: text/html, Size: 7394 bytes --]

Re: [Cerowrt-devel] cerowrt-next plans

[Outback Dingo]

[-- Attachment #1: Type: text/plain, Size: 4170 bytes --]

wheres this ubnt build ? Ive got a few ubiquiti devices id like to test it
on


On Fri, Nov 23, 2012 at 12:27 PM, Dave Taht <dave.taht@gmail.com> wrote:

> 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
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>

[-- Attachment #2: Type: text/html, Size: 5354 bytes --]

Re: [Cerowrt-devel] cerowrt-next plans

[David Lang]

[-- Attachment #1: Type: TEXT/Plain, Size: 6670 bytes --]

Playing Devil's advocate here.

Why do you need IPV6 for HAM use (other than the fact that it's new). There 
aren't enough users to exhaust the IPv4 address space, and the packets are 
larger so they take more airtime.

David Lang AG6AH



  On Fri, 23 Nov 2012, dpreed@reed.com wrote:

> Regarding AHCP...  it occurs to me that AHCP might be a better choice than the alternatives for use in Amateur Radio internet environments with IPv6.
> 
> I would like to see a very future-oriented approach to IPv6 in Amateur Radio.   There are some quirks in the rules for Amateur Radio that mean that Amateur Radio subnetworks (unlike "open wireless" networks) have to have every message transported directly traceable to a licensed operator, cannot be obscured, and cannot contain "music".   (I know, the rebel in me feels this is not a good thing, but when operating with my Ham hat, I understand the reason to color within these lines, in order to be a "good netizen" in Ham circles, and to be constructive in gaining support from the various constituencies that support Amateur Radio's special status worldwide. There is no benefit whatever to using terms like "war-driving" in conjunction with Amateur Radio just to get your name in the papers).
> 
> It's perfectly reasonable to carry IPv6 traffic as datagrams over radio networks operated by cooperating Amateurs. (and could be hugely beneficial in situations like Hurricane Sandy)  What we don't have is a "stack" that is best tuned for this style of internetworking.
> 
> Part of the stack needs to include IPv6 address assignment and routing, and also bufferbloat-prevention.  My thought is that AHCP and other components useful for Cerowrt deployment would be suitable for an Amateur Radio IPv6 stack.  Also, I have some ideas about low-level ways to ensure that there is always a responsible, licensed "control operator" for any messages delivered over Amateur Radio-licensed IPv6 transport paths, which I have begun working on.
> 
> That long discursion suggests that a simple AHCP server and client implementation would be very, very helpful in a wider scope of usage.  One that brought IPv6 to Raspberry Pi might be just the ticket, since interfacing such a board to off-the-shelf transceivers is pretty easy for many Ham hobbyists.  (beware - you really should be aware of the "band management" done by the ARRL, so you stay in the subbands where digital signalling is encouraged.  The 1.2 GHz band and above are preferable, and maybe the digital portion of  440 MHz, esp. if you don't disrupt the FM phone activity there).
> 
> -----Original Message-----
> From: "Dave Taht" <dave.taht@gmail.com>
> Sent: Friday, November 23, 2012 12:27pm
> To: cerowrt-devel@lists.bufferbloat.net, "bloat-devel" <bloat-devel@lists.bufferbloat.net>
> Subject: [Cerowrt-devel] cerowrt-next plans
>
>
>
> 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
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel

[-- Attachment #2: Type: TEXT/PLAIN, Size: 164 bytes --]

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

Re: [Cerowrt-devel] cerowrt-next plans

[dpreed]

[-- Attachment #1: Type: text/plain, Size: 9535 bytes --]


Two reasons come to mind - I'm sure there are more.
 
1) IPv6 adress space is not exhausted and "owned" by a whole lot of ISPs.   It's quite reasonable to get a full prefix for this purpose.
 
2) IPv6 is the future of the Internet, especially suitable to "open Internet" applications where the "open Internet" is extensible and routable.  I think Hams should be encouraged to experiment with such technologies where appropriate - that's why Amateur Radio was created: to advance the state of the art of both operations and technology, and engage people of technical talent in that quest.
 
There's no particular reason why the IPv6 headers cannot be compressed using one of many "header compression" techniques, in whatever encapsulation is used to map IP datagrams to the wireless transmission layer (layer 2).  It turns out that I invented the first such header compression for IP and TCP/IP and UDP/IP packets in about 1978, when the "layer 2" bindings for encapsulating IP over serial lines (at 300 bit/sec) were still in flux (my tech report on the subject was listed as "prior art" when Motorola/Codex tried to claim they invented it in a patent lawsuit against some  Internet router's serial link implementation - I think it was probably one of Cisco's, since Van Jacobsen was the one who contacted me many years later).  Such compression can make the IP headers smaller than the IPv4 headers would be.
 
In general, as Hams get into "Internetworking" (which is far from the current practice of circuit-switched repeaters) there are lots of interesting problems where Hams can advance the state of the art into areas where commercial folks don't want to solve the problem.
 
Setting up ad hoc, interoperable emergency wireless communications nets that also interoperate with whatever wired/fiber infrastructure is available is one obvious example of a problem that Hams can experiment with solving.
 
I am prototyping experimental Part 97 radio systems that use SDR-based, adaptive waveform, very wideband transmission modes (likely to be most useful in the 5 GHz and 10 GHz Amateur bands, where one can build QRP SDR transceivers that fit in a 3"x5" board, running a full Android or openwrt stack).
 
David KB1YFR
 
 
 
-----Original Message-----
From: "David Lang" <david@lang.hm>
Sent: Friday, November 23, 2012 5:41pm
To: dpreed@reed.com
Cc: "Dave Taht" <dave.taht@gmail.com>, "bloat-devel" <bloat-devel@lists.bufferbloat.net>, cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] cerowrt-next plans



Playing Devil's advocate here.

Why do you need IPV6 for HAM use (other than the fact that it's new). There 
aren't enough users to exhaust the IPv4 address space, and the packets are 
larger so they take more airtime.

David Lang AG6AH



 On Fri, 23 Nov 2012, dpreed@reed.com wrote:

> Regarding AHCP...  it occurs to me that AHCP might be a better choice than the alternatives for use in Amateur Radio internet environments with IPv6.
> 
> I would like to see a very future-oriented approach to IPv6 in Amateur Radio.   There are some quirks in the rules for Amateur Radio that mean that Amateur Radio subnetworks (unlike "open wireless" networks) have to have every message transported directly traceable to a licensed operator, cannot be obscured, and cannot contain "music".   (I know, the rebel in me feels this is not a good thing, but when operating with my Ham hat, I understand the reason to color within these lines, in order to be a "good netizen" in Ham circles, and to be constructive in gaining support from the various constituencies that support Amateur Radio's special status worldwide. There is no benefit whatever to using terms like "war-driving" in conjunction with Amateur Radio just to get your name in the papers).
> 
> It's perfectly reasonable to carry IPv6 traffic as datagrams over radio networks operated by cooperating Amateurs. (and could be hugely beneficial in situations like Hurricane Sandy)  What we don't have is a "stack" that is best tuned for this style of internetworking.
> 
> Part of the stack needs to include IPv6 address assignment and routing, and also bufferbloat-prevention.  My thought is that AHCP and other components useful for Cerowrt deployment would be suitable for an Amateur Radio IPv6 stack.  Also, I have some ideas about low-level ways to ensure that there is always a responsible, licensed "control operator" for any messages delivered over Amateur Radio-licensed IPv6 transport paths, which I have begun working on.
> 
> That long discursion suggests that a simple AHCP server and client implementation would be very, very helpful in a wider scope of usage.  One that brought IPv6 to Raspberry Pi might be just the ticket, since interfacing such a board to off-the-shelf transceivers is pretty easy for many Ham hobbyists.  (beware - you really should be aware of the "band management" done by the ARRL, so you stay in the subbands where digital signalling is encouraged.  The 1.2 GHz band and above are preferable, and maybe the digital portion of  440 MHz, esp. if you don't disrupt the FM phone activity there).
> 
> -----Original Message-----
> From: "Dave Taht" <dave.taht@gmail.com>
> Sent: Friday, November 23, 2012 12:27pm
> To: cerowrt-devel@lists.bufferbloat.net, "bloat-devel" <bloat-devel@lists.bufferbloat.net>
> Subject: [Cerowrt-devel] cerowrt-next plans
>
>
>
> 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
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[-- Attachment #2: Type: text/html, Size: 11442 bytes --]

Re: [Cerowrt-devel] cerowrt-next plans

[Juliusz Chroboczek]

Sorry for the extremely late reply (it's been over a month!), but I'm
only slowly recovering from a massive mail backlog.

>>> it occurs to me that AHCP might be a better choice than the
>>> alternatives for use in Amateur Radio internet environments with IPv6.

>> Why do you need IPV6 for HAM use

> Two reasons come to mind - I'm sure there are more.

Another reason is that a number of things are much easier to implement
in IPv6.  This is especially true of link-local stuff, which is highly
non-portable in IPv4, and quite reasonable in IPv4.

That's the main reason why I never bothered defining AHCP over IPv4 --
the current implementation of AHCP is almost completely portable POSIX
code, while a typical DHCPv4 implementation needs to manually craft IP
packets and push them through a raw socket.  (The Babel protocol is
defined over both IPv4 and IPv6, has it's only ever been implemented
over link-local IPv6.  Note that that it can advertise IPv4 routes, it
just happens to carry them over IPv6.)

In short -- IPv6 helps keeping the developers sane.  And that's
hopefully worth a few wasted bits here and there.

-- Juliusz