[Commotion-dev] Current state on handsets

[Jeremy Lakeman]

On Sat, Feb 25, 2012 at 6:52 AM, Hans-Christoph Steiner
<hans at guardianproject.info> wrote:
>
>
>> Can you specify which models are affected in detail? And its "safe" to
>> install it on all others that are in the "compatible" list? We are sure
>> we have a couple of willing participants quick if we can assure them
>> that it can't screw up their phone.
>
> If you are looking for real assurances, then this isn't the best
> software to work with.  Its very beta.  On some devices, it works easily
> and seamlessly.  On a couple devices, it nukes the wifi, requiring a
> factory reset to restore it.  So if no one has run Serval on a
> particular device, the result will probably be good, but might be quite
> bad.

As I've said, Droids, and possibly only when running CyanogenMod, are
the only devices we know of that have stopped working.

>> What do think, would batman still do something useful in the "walking
>> speed pedestrian scenario" or is it using totally the wrong approach in
>> this case? How much effort would it be to switch to a routing management
>> layer that is known to being able to cope better with these kinds of
>> dynamics?
>
> Try it and tell us :)  I think its worth trying with a few technically
> savvy people, and if it works, then try spreading it more.

With BATMAN if you are trying a phone call and wander out of 1hop
radio range, you'll hear silence for up to 30 seconds before suddenly
hearing something again.
You can easily flip to olsr from our settings. Try it and tell us.

Longer term we *will* be writing our own mesh routing code. That won't
actually change the routing table, initially running in layer 3 user
space. Optimised for real time traffic on a meandering network. That
can detect broken links and change paths in sub 100ms time scales. Or
at least we hope we can do that anyway. I'm doing some very low level
link state R&D at the moment towards this goal.

>
>>>> Our development branch has a store and forward file transfer system
>>>> built in, that we're also using for delay tolerant text messaging, and
>>>> collaborative mapping (still a work in progress).
>>
>> Ideal would be if one can mimic a subscribe-to-a-named-channel
>> communication paradigm, similar to twitter, but operating on "local"
>> namespace scope. So when you are physically connected to this ad-hoc net
>> - you can read what others post into the channel if you're subscribed to
>> it.

Yeah, we're planning on enabling communications between group members
via a pre-shared private key.
But we won't be relying on network security at all as we want everyone
to be able to join the network and help route packets.
For the moment, any text messages sent to "*" will be delivered to everyone.
Note that you'll have to install SMSDroid and WebSMS to use as a front
end for sending text messages using our network layer. We will build
our own UI into our application, but we haven't gotten around to it
yet. And we'll probably use this same UI as the basis for a push to
talk / voicemail / group chat interface with reliable delivery.

>> But for a start it would be nice to just "see" how the network changes
>> over time - visualizing the routing table growing/shrinking or
>> something. This is what floats our nerd boats...
>>
>> How much effort would it be to get that?

Our peer list window actively scans the network for nodes running our
software, and displays registered phone numbers, connectivity and hop
count information for each peer. It's not a map but it's better than
nothing.

> One thing that might work is Bonjour/XMPP/nDNS chat, but I don't know
> off hand an Android client that supports it.   Basically, it allows you
> advertise your IM account over the local network (in this cash, the
> BATMAN mesh), and then directly IM people.
>
>

>>>> And everything we've done also works in wifi client / hotspot mode
>>>> between devices connected to the same network. Useful if you can't get
>>>> root on some devices.
>>
>> Thats nice, so root is only necessary for getting ad-hoc mode to run?
>> The rest of the serval stack can be assumed to work on non-rooted devices?
>
> At this point, if you want mesh networking, then you'll need root.
>

Correct on both counts. Though you will run into packet filtering
issues on some devices in wifi client mode. Some devices just don't
receive broadcast packets when their screen turns off, others never
receive them at all.

> .hc
>
>>>> Note that there's basically no security at this point.
>>
>> That's not a problem from our point of view. It's a "fun experiment",
>> not intended to be used for any security/privacy relevant communication.
>> yet :)
>>

Another thing to note, some devices won't join an adhoc network that
was started by a different type of device. For example Huawei ideos
phones wont join a network started by samgsung galaxy's. Probably some
kind of BSSID related issue, the only way we've found to fix it is to
turn adhoc on every device off and on again...