[Babel-users] some thoughts towards babel-1.9

[Dave Taht]

On Mon, Jan 2, 2017 at 6:28 AM, Benjamin Henrion <zoobab at gmail.com> wrote:
> On Mon, Dec 12, 2016 at 6:25 PM, Dave Taht <dave.taht at gmail.com> wrote:
>> I've long been testing a few out of tree patches for babel and long
>> have had the intent to try a few more once the first phase of the
>> make-wifi-fast work was completed - which it mostly is, so far as lede
>> is concerned ( https://lwn.net/Articles/705884/ ) - and babel-1.8
>> stablized.
>>
>> I wrote up some of my thinking then in:
>>
>> https://github.com/dtaht/rabeld/blob/master/rabel.md
>
> You are right about the 2 remarks on diversity, the code needs to be
> adapted to handle 802.11AC, and how it minimize channel interference,
> especially nowadays with using multiple channels at once.

Merely handling channel detection at all again would be good. Code for
this, using the correct API, exists in olsrv2, but my brain crashes
when looking at netlink. Then there's merely HT20 vs HT40... and THEN
ac really wonks up the ideas.

> For the wired link case, I am surprised babel considers it "interfering"!

I can't remember how I drew this conclusion, whether it was from
packet captures or from the code, but it appeared to be the case at
the time.

> On this topic, I wanted to BAN hoping on the same channel, as this is
> a really bad feature of wifi mesh.

Not sure if I understand. There are plenty of cases where using the
same channel again makes sense, for example where a directional 5ghz
radio has a ton more bandwidth than a weaker 2.4ghz omni to a given
point.

One test case we did not explore yet with the make-wifi-fast code was
where there is a 5 ghz channel in AP mode with an adhoc backchannel on
the same radio. My hope is we vastly improved the behavior in that
scenario... but to deploy it we needed

> At some point, I should find some time to install a proper outdoor
> testbed somewhere to try that kind of configuration.

The yurtlab (and 110 acre campus) is uninhabitably cold in the winter
(at least to a californian - no snow, though). I'd hoped to do a new
deployment (30+ radios) by this past september, but we weren't done
make-wifi-fast yet. With the time available before spring (say, may),
it seems possible to work on other bothersome problems (ipv6 address
assignment, source specific routing, name services, monitoring, and
security, and other rabel-ish issues)

(If anyone out here wants to bundle up and climb a few roofs with me,
getting a partial deployment along the 2 main backbones would be nice,
long before then....)

> I have tried to simulate that with hwmod kernel module, but did not go very far.
>
> --
> Benjamin Henrion <bhenrion at ffii.org>
> FFII Brussels - +32-484-566109 - +32-2-3500762
> "In July 2005, after several failed attempts to legalise software
> patents in Europe, the patent establishment changed its strategy.
> Instead of explicitly seeking to sanction the patentability of
> software, they are now seeking to create a central European patent
> court, which would establish and enforce patentability rules in their
> favor, without any possibility of correction by competing courts or
> democratically elected legislators."



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org