From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 5E479200830 for ; Tue, 10 Apr 2012 10:58:11 -0700 (PDT) Received: by wibhr17 with SMTP id hr17so60374wib.10 for ; Tue, 10 Apr 2012 10:58:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=V9rx8y84QpJxhqvzcAjQO8pYBvEX6tNeLJnrj0rrTVs=; b=vbnM7qszrNcw5iQKNQN6jlrla2N3XfrxDFhO+vh6wf9MvITBfj6hM5tNEG+yMqKYPz Y4x6cUMA6cidovRBoIRwSOyAyAv8gq0N4BvbiEil+A9JhheBLhzslVWYbSNLWLkL8/Ia df/hooaopXwgKZk9oRF3Sp7qVgdb1zcKCnsQcpk4NhLN5+ipVsjps+1X3UBERXp+U4iy B73fos3ERUJx+QO62aNkYqnrqEH3leEPp0X3IPkns1kmUSmluIlstDGBjzKDjqPaglDb kPmBlY16xT395buT96FJuKt1LDAE1Zxsfe0qg0yVYsM1+wdQ4CTQVYDTcRRWhkCeGl5e Csog== MIME-Version: 1.0 Received: by 10.180.86.132 with SMTP id p4mr9136143wiz.15.1334080688550; Tue, 10 Apr 2012 10:58:08 -0700 (PDT) Received: by 10.223.127.194 with HTTP; Tue, 10 Apr 2012 10:58:08 -0700 (PDT) Date: Tue, 10 Apr 2012 10:58:08 -0700 Message-ID: From: Dave Taht To: cerowrt-devel@lists.bufferbloat.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [Cerowrt-devel] some of the advanced stuff (sort of) in cerowrt 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, 10 Apr 2012 17:58:12 -0000 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. --=20 Dave T=E4ht SKYPE: davetaht US Tel: 1-239-829-5608 http://www.bufferbloat.net