Weekly Update – 2 May 2015

posted in: comm, news, uav | 0

So I guess I’ve made it a thing for myself to blog on a weekly basis.  So I’ll start with last week.  It doesn’t really surprise me that both of these developments came about in a single day.

Connection Bonding – Apparently not a good idea over WiFi.

Lack of LACP Packets

Link aggregation control protocol (LACP) wasn’t working for some reason, and I was determined to get to the root cause with my WireShark packet analyzer.

I have discovered one achilles heel in our plan to use Ubiquiti products for connection bonding: they depend on a version of the Linux kernel that does not pass LACP packets through its connection bridging module.  (Or at least that’s what I read on the forums and observed through my analyzer.)  And my guess is that for any other situation other than ours, it would be a good idea not to mix link aggregation and connection bridging.  Fair enough.

I am not sure about what exactly the IEEE 802.3ad standard states about “what to do when you don’t get LACP packets but the link is up,” but I will assume (and have observed) that it attempts to keep the link from transmitting packets over and over again by essentially only using one connection-bonded interface (usually the one with the lower eth* number).  This is entirely logical and will work for most wired network connections.  Unfortunately, we function over a wireless bridge, so it does not essentially apply in our network configuration.  This is especially so when the chosen connection on the other end is not the same connection on your particular end.

Lack of matched speeds

Unfortunately, our wireless transmission system would rely on different speeds (because why not bond 2.4GHz and 5.8GHz! twice the frequency redundancy, right).

The usual configuration of IEEE 802.3ad requires the interfaces to be of the same speed.  My guess is that it does some kind of round-robin assigning (while checking whether or not the connection is working with occasional LACP pings) of the different interfaces.

Lack of “ethtool accessibility”

LACP also relies on link detectability with ethtool.  I am unsure if this takes precedence over whether or not LACP packets are being received, but the Bullet and Nanostation products of the respective frequency do not turn off their ethernet interfaces when the wireless interface is not connected.  My guess is that this confuses LACP into thinking that whichever one with its ethernet up (whether or not it is actually connected to the other end) is capable of transmitting packets to the other side.

What to do instead?

Ubiquiti will probably not release a kernel that is new enough to have the updated connection bridging module loaded.  There’s a lot of proprietary magic in there that simply does not go through the Linux kernel through Ubiquiti’s MIPS processor (I wonder if they developed that themselves).  Although I still believe that connection bonding may actually work over wireless interfaces (I’m sorry, but my confidence has not been crushed just yet), we do not exactly have the finances to purchase large numbers of powerful USB wifi devices.  I’ll try to save that for next year.

We do have the power to use spanning tree protocol (STP) which enables automatic switchover of an interface in case one fails.  (And also for making the server-client connection aware… but that’s not really within the realm of possibility right now because I’m busy with other stuff…)  The original IEEE standards for STP are a bit slow, but who cares!  As long as it works for now, I’m happy.  (I’ll also have to assign the 5.8GHz Bullet – Nanostation set a higher bridge priority because they’re quite a lot faster.);

Can I have some pics?

Unfortunately, I didn’t really have anything picture-worthy…  Although, the tracking station seems to be taking on some progress.

But to be fair, I should have taken a picture of connection bonding when it actually worked.  Who would have known you could actually (LEGIT!) get 1GiBi/s!  I could download an illegal copy of a movie in less than sixteen seconds!  (That is — if I were somehow running large numbers of SSD’s in my system… and if I were not entirely scared of FakeRAID.)

Leave a Reply

Your email address will not be published. Required fields are marked *