26 Jun
2015
26 Jun
'15
8:28 a.m.
Here's what went down.
# Added functionality to our babeld fork
-x for dynamically removing interfaces (we only had -a to add them)
-F to enable the dynamic functionality (fungible mode)
-i to print the "kill -USR1" information for the running babeld
babeld no longer requires any interfaces to be specified when initially
started if fungible mode is enabled
# Switched our firmwares to using our babeld fork
Here it is:
https://github.com/sudomesh/sudowrt-packages/tree/master/net/babeld-sudowrt
We were only using them on the VPuN (exit) server before.
I haven't tried to recompile the firmware with this package added. Maybe
someone else can test that this compiles correctly?
max: be aware that VPuN servers will now have to start new versions with -F
to get the dynamic functionality
# Completed extender-node functionality
Everything now works as expected with babeld running on the extender nodes.
The extender nodes come up automatically and both the open and adhoc
networks work.
Due to feedback by Dave Taht I abandoned adding avahi-daemon as a reflector
on the extender nodes and pushed forwarding of mDNS traffic to the
milestone for a future release.
The one thing left to do for the extender nodes is to re-compile both
firmwares from scratch, flash two nodes and test that it all comes up as
expected. I've tried hard to bring the repositories in line with the
working configuration on my two test nodes, but I may have missed something.
# Added milestones and issues on github
Milestones:
https://github.com/sudomesh/sudowrt-firmware/milestones
Issues for upcoming version 0.2:
https://github.com/sudomesh/sudowrt-firmware/milestones/0.2%20-%20initial%2…
Please add any issues I may have missed. Also, please change things if you
disagree :) I just did what I thought made sense but I'm not married to
anything.
Yay progress!
--
marc/juul
26 Jun
26 Jun
9 a.m.
If y'all ever get out of SF, it is burner weekend at my site in los gatos... :)
I will be leaving for europe in mid-july, but have an established mesh here you
might want to look over, if you want.
On Fri, Jun 26, 2015 at 8:28 AM, Marc Juul <juul(a)labitat.dk> wrote:
Here's what went down.
# Added functionality to our babeld fork
-x for dynamically removing interfaces (we only had -a to add them)
-F to enable the dynamic functionality (fungible mode)
-i to print the "kill -USR1" information for the running babeld
babeld no longer requires any interfaces to be
specified when initially
started if fungible mode is enabled
# Switched our firmwares to using our babeld fork
Here it is:
https://github.com/sudomesh/sudowrt-packages/tree/master/net/babeld-sudowrt
1.6.0 added ipv6 source specific routing. 1.6.1 was a bug fix.
I believe in all cases, that
channel diversity is still broken in AP mode (the world moved to
nl80211), but might
still be correct for adhoc.
havent had the energy to copy/paste from the iw code over to babel.
We were only using them on the VPuN (exit) server before.
I am curious if you have also implemented the sqm-scripts there?
(measure your latency
with tools like flent)
I haven't tried to recompile the firmware with
this package added. Maybe
someone else can test that this compiles correctly?
max: be aware that VPuN servers will now have to start new versions with -F
to get the dynamic functionality
# Completed extender-node functionality
Everything now works as expected with babeld running on the extender nodes.
The extender nodes come up automatically and both the open and adhoc
networks work.
I note that you do have to set BSSID consistently throughout the mesh.
My own mild fork of babel was adding ecn support recently (as all my
nodes run fq_codel or cake with ecn enabled). This showed that a large
percentage of the routing issues I was having were actually congestive
in nature.
Of course, not having enough packet loss is also a problem. Setting
mcast_rate to something high helps on a variety of fronts. On the
picos I have gone as high as mcast_rate 9000, and might go higher,
given how promisquiously they connect.
It is also generally a good idea to turn off wmm.
Due to feedback by Dave Taht I abandoned adding avahi-daemon as a reflector
on the extender nodes and pushed forwarding of mDNS traffic to the milestone
for a future release.
The one thing left to do for the extender nodes is to re-compile both
firmwares from scratch, flash two nodes and test that it all comes up as
expected. I've tried hard to bring the repositories in line with the working
configuration on my two test nodes, but I may have missed something.
I have been testing successfully the new minstrel-blues (coupled power
and rate control) stuff along with andrew mcgregor's minimum variance
patches. Have not pushed them to openwrt, but they are part of my
default build.
The minimum variance stuff is neat - instead of choosing the best
average rate (which may vary wildly), minstrel now chooses the most
consistent rate, which makes tcps happier and makes for more
consistent results on other protocols, like voip. Patches have been
appying to chaos calmer and trunk for 4+ months now...
http://snapon.lab.bufferbloat.net/~cero3/minstrel_variance.tgz
# Added milestones and issues on github
Milestones:
https://github.com/sudomesh/sudowrt-firmware/milestones
Issues for upcoming version 0.2:
https://github.com/sudomesh/sudowrt-firmware/milestones/0.2%20-%20initial%2…
Please add any issues I may have missed. Also, please change things if you
disagree :) I just did what I thought made sense but I'm not married to
anything.
I am always also looking for more testers of "cake", which is in the
ceropackages-3.14 repo (along with tc-adv).
I started applying it to wifi recently (killing off mq entirely) with
a bandwidth limit. This cut memory use under congestive load by a lot
and seems to work well. Cake is not, however, anywhere near as baked
as minstrel-blues nor is it actually targetted at wifi. (that's
make-wifi-fast)
http://www.bufferbloat.net/projects/codel/wiki/Cake
Yay progress!
--
marc/juul
_______________________________________________
mesh-dev mailing list
mesh-dev(a)lists.sudoroom.org
https://sudoroom.org/lists/listinfo/mesh-dev
--
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
1:15 p.m.
1) I see you are using your own fork of babel 1.5.1, with ipc support.
What are you using the tunnelling interfaces for? rtt based routing vpns?
The current "babel way" is to just specify all possible interfaces at
start time. There is also support for additional conf files in a conf
dir now. There is some new syntax to make more options inheritable
(and the default openwrt configuration methods modified to suit)
Example babeld.conf #1:
default enable-timestamps true rtt-min 10 max-rtt-penalty 128
local-port 33123
log-file /dev/null
ipv6-subtrees true
diversity 3
# Hip addresses by their very nature are unroutable
redistribute local ip 2001:10::/28 ge 28 deny
redistribute local ip 1.0.0.0/24 ge 24 deny
# my two interfaces
interface eth0 enable-timestamps true rtt-min 2 # note that for saner
folk than I this should probably be 0
interface wlan0 enable-timestamps true rxcost 512 channel 1 #
automagic channel detection is broken, and currently, instead of
exporting a larger metric for wlan0 (which is a 2ghz node on a network
with much faster 5ghz nodes), I change the rxcost.
Certainly I agree that being more dynamic is a good idea, but it is
unclear how often you would want to just restart babel based on
interfaces coming and going.
2) the builtin, but painful, way to get a dump of babel stuff is to
connect locally with socat over the supported socket, and/or tunnel
with ssh for babelweb
ssh -N -T -L 33126:[::1]:33123 ranger # as one example
if babelweb supported it you could do a different ssh with an implicit tunnel.
3) there seemed to be some logic ripped out that worried me
30 Jun
30 Jun
5:03 a.m.
On Fri, Jun 26, 2015 at 9:00 AM, Dave Taht <dave.taht(a)gmail.com> wrote:
If y'all ever get out of SF, it is burner weekend
at my site in los
gatos... :)
Thanks for the invite! We should definitely meet up some time. I would've
been up for it this weekend but the house I was staying at caught on fire
and then became very wet.
I will be leaving for europe in mid-july, but have an established mesh
here you
might want to look over, if you want.
Definitely. When will you be back?
--
marc/juul
3467
days inactive
3471
days old
3 comments
2 participants
participants (2)
-
Dave Taht -
Marc Juul