[Cerowrt-devel] that latest build I did is looking good

[Dave Taht]

I have been abusing it on a picostation and nanostation now for 48
hours. The archer c7v2 (as a source specific gateway) for a week. A
couple wndr3800s. No crashes. Can still trigger the dreaded wifi TX
DMA bug, but it seems harder now. DID regularly crash the iwl in one
box. [3]

My mission was to get to something that I could deploy here at a small
scale and just let run for a month while away in the eu, and that was
looking dicy there for a while. (I am glad to have basically started
in april!)

So... we do, finally, have an openwrt build that uses cake, has the
minstrel-blues patches, and andrews minimum variance patches, working
dnssec (we hope!), and a new version of babel with ecn enabled, has
snmp, that does dhcp-pd fairly right, and works with comcast. I also
have things (odhcp6c is way better than isc, dibbler, wide) working
fairly well with another debian based firewall.

If/when new cake or sqm stuff arrives my plan (barring other major
bugs elsewhere) is to just incrementally build that and tc-adv out of
the above frozen repo. [1]

:whew: Have to go climb a couple trees this week. Have 3 source
specific gateways up, might get two more. [2]

* babel bug - channel diversity routing does not autodetect the actual
channel you are on. Setting it manually works, but is a pita to
remember to do... fixing it is a mere matter of grokking the iw
nl80211 code.

* Juliusz does not like having a routing protocol that uses ecn but
does not respond to it (yet!), (I agree partially) but me, what I see
is routing suffering from congestive failures periodically, and I am
most interested in what is going on at precisely the point of
congestion... particularly the rtt timestamps now in babel... so I
left it in. DID prove that even a minimalistic routing protocol in a
fq_codel environment on present day wifi can suffer from significant
congestive loss. (or in this case, get CE marked). Distinguishing
between path connectivity loss - and congestion - seems worthwhile in
a routing protocol.....

Pull up wireshark on:
http://snapon.lab.bufferbloat.net/~d/newrouters/linuxcap.cap
use a ipv6.traffic_class.ce == 1 filter in wireshark.

An observation: routing stuff that does not use IP (like arp, and I
think batman and ISIS) cannot use ecn at all...

- I did not bother testing hnetd. Simply not enough time to test it.
What I plan to do is just backhaul a few fixed ipv6 prefixes to the
core locations that can use them after finishing up:
https://github.com/dtaht/ipv6_selfassign - and try to do more to
figure out hnetd at ietf, or look over dhcp-pd again for internal use.

- did not do package signing

[1] If you have any missing packages you need from that repo, tell me
now. But the goal is to push up tc-adv and cake into the openwrt
mainline repos next.... running on things like the linksys 1200ac...
then get minstrel-blues straightened out... and start on per station
queueing... - and I am still not in a position to do another
cerowrt-like effort. Where do we go with this? I feel like we are
limping along....

Still, if you want to play along, knowing full well we will be stuck
here for months or forever:

 http://snapon.lab.bufferbloat.net/~cero3/lupin/ar71xx/

[2] a pita in my environment is to get the picos and nanos setup right
(unbridged, adhoc, snmp, etc) , so I am doing separate builds for
that.

[3] Some flent data here: snapon.lab.bufferbloat.net/~d/newrouters.tgz

everything with the word "linux" in the title was a the iwl using
linux box. the other tests were driven by OSX. It was
interesting/depressing to see how much more airtime the osx box
grabbed, while the linux box was quite fair to the AP. Do not have any
longer range tests... that awaits tree-climbing.

-- 
Dave Täht
worldwide bufferbloat report:
http://www.dslreports.com/speedtest/results/bufferbloat
And:
What will it take to vastly improve wifi for everyone?
https://plus.google.com/u/0/explore/makewififast