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