Hi! Those are very exciting things you're taking about Dave and surely the way to go forward. But looking at cerowrt from my living room's perspective, if I may, I must say that most crucial is the stuff that reduces latency, bufferbloat; improves "snappiness"; provides flexibility and ease to using apps. By that I mean: 1) QoS, ACM and bufferbloat work - which is very good at the moment for me and I appreciate that very much! 1b) TCP FastOpen - indeed sounds exciting and but also Proportional Rate Reduction (http://lwn.net/Articles/458610/) 2) UPNP / NATPMP / mDNSresponder - to help different apps reaching out - i am sort of losing grasp of which package does what, they seem to be intertwined (?) but cero has these packages currently (3.3.1-4) broken. 3) miniDLNA - DLNA is a good low-latency (?) / high-throughput use-case within the wireless (laptops, picture frames) and wired (TV, NAS) home network. Also minidlna package is broken too. 4) Some still sexy stuff for me: DNSSEC, IPv6 Regards, Maciej On Tue, Apr 10, 2012 at 7:58 PM, Dave Taht wrote: > It occurs to me that jim and I haven't talked about one of the side > goals of cerowrt that much. > > We spent a lot of time, early on, trying to find bits of network > research that seemed promising, make them more usable, and more > available to a wider audience to play with, on something that cost 100 > bucks... > > Simply getting to where we had a reliable, well understood, base > platform for real world day to day use - AND research - has taken all > year, and along the way we had to solve a lot of niggling problems. > > So here's a list of extra stuff that we felt was potentially useful > and interesting. > > And until now, although we'd made the packages more or less work, we > didn't always build them - the build takes long enough as it is! - but > the intent was to make them available as options. I plan to make as > many of these available as possible in the next builds, and > installabblevia the opkg utility. > > To me, this is the interesting stuff! Getting to use - understand - > and leverage these fascinating new technologies could eat my entire > life, and darn it, I have another build to do... > > I'm always up to adding (or hearing about!) more. There's a huge list > of stuff on the onboard web pages we ship by default and think is > stable and are willing to support, but this is the bleeding edge stuff > that we'd hoped people would try out in the longer run. > > * HIP. Boeing uses this to control industrial machinery inside of > other peoples' lans. It holds great potential as means to keep your > refrigerator updated and safe, as well as provide a useful abstraction > for separating a host's location, from it's identity. > I'd hoped to try this for things like snmp monitoring. > > regrettably openhip has a tough problem right now with puzzle > generation in the D1 crypto step on mips and while fascinated by > problems like that normally, ENOTIME. I'm going to build it, merely to > find out if I can get someone else to connect to me on the same arch > and have puzzles fail or succeed... > > * Kerberos Kerberos is one of the few universal single signon > facilities that actually works. It's amazing how much nicer my life is > when I'm at a facility that has it on. I don't ever have to login to > anything. While I build the package, convincing the universe to go to > kerberos seems difficult, but as an example of what could be done, if > we get fed up with dealing with capcha I wanted it out there. > > * VPN technologies. IPsec is supposed to be an intrinsic part of any > ipv6 implemention. It usually is not, as it's rather thoroughly > over-engineered (and underthought-out when it was developed), but > Strongswan has been part of cerowrt since day one. Convincing people > to try it (and get past the hurdles of cert generation, which is a > PITA) has been a problem. > > I ran into so many problems trying to get it to work inside of > corporate firewalls that I gave up on it, but that doesn't mean it's a > problem on the edge in the home. Yet. But I do note that it will work > much better over ipv6 in that you have nearly infinite address space > available, and it does, by default, work with ipv6. > > I note that people keep trying to make tcp do everything, and it > can't. UDP based applications can be made work much better, with a > crypto assist... > > Frustrated with ipsec, I got openvpn to work, over both udp and tcp. > As it turned out, the only thing I could get through the firewall in > france was openvpn over tcp, and working through that was a profound, > painful demonstration of the benefits of e2e connectivity over udp! > > Both are built into cerowrt at present. > > * TCP fast open. We've been tracking this work closely, but patches > are not going to land for a month or two more, and will need to bake a > bit. You can look up this topic on the web - it looks promising to cut > 10% or more of the typical latency of a short tcp connection. > > * CCNX: Both jim and I are huge fans of this project, check it out. > > Steve walker got previous version of ccnx to build, I updated to the > latest release and broke it. :( > > * Openflow: Stanford in particular is doing research into making > multiple switches act as one big switch, with a common configuration > language. It's interesting, especially if you think bridging can > scale. > > * Mesh routing protocols: While the default in cerowrt is babel, we've > been tracking the progress of quagga-re closely, which includes bgp, > ripng, ospf, ospfv6, isis, and babel. We also make available olsr, and > xorp - which is roughly a superset of quagga, with additional support > for multicast routing that I haven't explored, because xorp is kind of > large. It is however widely used. > > Regrettably the xorp package is mildly broken at present (just needs > love from someone) and someone needs to fix it, if they care. At the > moment, quagga gets most of the other interesting protocols available, > so I don't care. That much. > > * tcp-ledbat: ledbat is the underlying protocol of current bittorrent, > and it has problems.TCP-ledbat is an implementation for tcp, and is > available by default. > > * Test tools: One of the things I'm happiest about now is that the > netperf tool now has the ability to change socket priorities, > tcp congestion control algorithms, and TOS/Diffserv settings on the > fly - for both sides of the test - via remote control. > Interestingly - Diffserv settings don't generally survive an ipv4 > connection across the internet, ipv6 settings do. > > There are innumerable test tools that we have available (shaperprobe, > ditg, lft traceroute, etc) > > * Multicast: Multicast was a hot topic in the 90s and nearly dead now, > except for those few critical applications where it's absolutely > required. (which is a broader category than most people think. Without > multicast dns, dhcp, and radvd, none of our networks would work at > all) Being able to use it again, at a higher level application, seems > like a useful avenue to explore in the context of a home. Available > since the first cerowrt boot camp has been a version of multicast ftp > (uftp), pimd is on by default, mrd6 is there but too buggy to use... > > That about covers all the sexy stuff that I can remember. > > I've finished adding these all back in the build that I could, for my > next attempt at a release late this week. > > happy hacking. > > -- > Dave Täht > SKYPE: davetaht > US Tel: 1-239-829-5608 > http://www.bufferbloat.net > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel >