I’m not whining, I just had hoped we’d tried hard enough to encourage folk to do things differently with what we were trying to do and documented, here:
To get peeps fiddling with that stuff rather than fitting the whole smeer into their pre-conceptions of how to do this stuff.
So I’m willing to try and address all these ‘it’s not the same as a normal router’ issues, but trying to change at least a few of those preconceptions along the way would be helpful. Ideas?
Perhaps it would be good to finish the docs, so one can understand how this new-to-me mesh networking works?
I follow http://jupiter.lab.bufferbloat.net/cerowrt/mesh.html and get a pretty page, but the “how to” page of http://www.bufferbloat.net/projects/cerowrt/wiki/Mesh is empty.
but I will get cracking on release and experimenters notes ASAP.
I don’t even know how to configure the QoS stuff (although the docs tell me I should) but that is inexperience. If I had it tweaked properly, I still don’t know how to quantify the improvement other than anecdotal human-based observations of better or worse.
The principal (and lame) test we use is latency under load - lots of up/downloads while pinging elsewhere.
The mesh stuff is interesting, and I have two wndr3700v2 boxes now so it is potentially useful even) but once done, I don’t know what to DO with it. >What do you want tested? How can it be measured and quantified as “working” beyond just playing?
I put up preliminary doc on the mesh stuff on the web site. I’ll settle for documentation and tools that get it ‘working’ for more people, then move on to playing. I’ve internalized ahcp and babel so much that I can’t simply explain the wonders of mesh networking (being able to move freely between wired and wireless networks with an open ssh connection for example)
Same with the bloat. Is there a daemon I can run which measures something I can report?
Perhaps we need a long-running measurement and reporting daemon. :) Or SNMP hooks? I’m willing to install snmpd (which I already have anyway) and >let it be probed remotely.
Yes we do. We also have netperf getting fired out of xinetd, with permissions (at least on most machines) on being probed from the lab. Longer term the plan was to allow snmp via the vpn.
This is the first OpenWRT box I’ve ever used, and most of the stuff I really want (VPNs etc) on the CeroWRT box don’t match what a “standard” OpenWRT >install would use, it seems.
I’m not really sure what you mean here - both strongswan and openvpn are available via an opkg update; opkg list; opkg install the_package
More stuff can be built as per your needs. At some point soon I’ll have a one-line build-yer-own-cerowrt script done.
Specifically, I have a IPv4 /27 and would love to have it exposed to the UI, or at least know how to configure it on the box.
Openwrt does not use /XX for ipv4 markings, but old style 255.255.255.224. It should be visible in the ui.
Bridging seems to not work as expected, or at least not work as I expect it; if I bridge through the UI, and yes it is wired+wireless, the wired >ends up in the bridge but the wireless does not, but if I use command-line tools to re-add it (brctl I think it is?) it does add it until I touch >any interface config.
How about we have a voice/irc chat and run through some stuff together? Everybody lives on #bufferbloat on chat.freenode.net - but I’d like to chat via voice, via skype….
After switching away from the Xen-hosted NetBSD router (yes, virtual routers FTW!) my next hop latency as measured by the Ripe NCC Atlas probe dropped from about 1.95ms average to 1.09ms average.
This is probably because it has to travel through less wires overall.