[Commotion-dev] Unifying Serval and Commotion Mesh (Paul Gardner-Stephen)

[stoker]

Hi Hans,

We're currently in the process of getting our apps posted to Google
Play. In the meantime, I just posted the apks to GitHub. Check the
"builds" folder in each project repo.

As mentioned above, in order for the Manet Service to flip your device
in ad-hoc mode:

- your device must be rooted
- your wireless chipset driver must support ad-hoc mode
- your kernel must support wireless extensions (wext)

We successfully got SPAN to work on the following devices:

- Samsung Galaxy Tab 10.1
- Samsung Galaxy Nexus (custom kernel)
- Samsung Galaxy S II 4G Epic Touch
- ASUS Transformer Prime (custom kernel)
- ASUS Nexus 7 (custom kernel)

We've done most of our testing on the Samsung Galaxy Nexus. We posted
our custom kernels here:
https://github.com/monk-dot/SPAN/tree/master/kernels

You can install the kernel zips using ClockworkMod Recovery.

Some Samsung devices require custom kernel tweaks to work properly.
Sometimes it's as simple as adding ad-hoc mode back to the list of
supported wireless modes. Let us know which devices you're having
trouble with and we might be able to help.

We flip the device in ad-hoc mode at the linux level, so the Android
framework isn't aware. As far as the framework is concerned the wifi
is turned off. Thus, an app can't use the framework's WifiManager to
determine if wifi is enabled. That's a problem that we haven't spent
time trying to solve yet. Do you guys have a solution?

- stoker

On Fri, Jan 4, 2013 at 8:57 PM, Hans of Guardian
<hans at guardianproject.info> wrote:
>
> This sounds great, definitely a lot of overlap in missions and ripe for collaboration.  A couple quick questions:
>
> * do you have APKs that we can try?
>
> * are you able to get Samsungs into adhoc mode?
>
> * do you make Android itself aware of the status of the wifi device? I.e. can you see the IP, SSID, etc. in the Wifi Settings.
>
> .hc
>
> On Jan 4, 2013, at 7:36 PM, stoker wrote:
>
>> Thanks Eric for pulling SPAN into the conversation. I'm a bit late to
>> the party but thanks to Seamus I'm finally subscribed to the
>> commotion-dev mailing list.
>>
>> SPAN is a framework for mesh network experimentation on the Android
>> platform (iOS support is also in the works). Don't be turned off by
>> the "experimentation" aspect - SPAN is quite functional. We like to
>> express that SPAN is constantly being advanced and we're very open to
>> new ideas.
>>
>> Here's a high-level breakdown for those who aren't familiar with SPAN:
>>
>> - We have an Manet Service and associated API that allows apps to turn
>> ad-hoc mode on and off, configure various network settings
>> programmatically and through a config file, query the network status
>> and routing information, and return a list of reachable peers. Also,
>> the device can be configured connect to traditional network
>> infrastructure via the cell chip or a secondary wireless network
>> adapter.
>>
>> - We have a simple Manet Manager UI for configuring the network and
>> starting / stopping ad-hoc mode. We're working on allowing user to
>> share the app and config info by physically bumping phones (NFC).
>>
>> - We have a simple mesh network visualizer app developed using
>> Processing for Android.
>>
>> - We use standard Linux tools such as ifconfig, iwconfig, and iptables
>> to configure the wireless network adapter. As long as apps use the
>> right IP address they do not need to use the Manet Service API or be
>> modified in any way to make use of the ad-hoc network.
>>
>> - Currently we support OLSR, but are not tied to any particular
>> routing protocol. We're interested in supporting reactive protocols to
>> cut down on network chatter. We like the idea of remaining as silent
>> as possible until you need to send data; however, complete silence
>> doesn't seem possible because at a minimum beacon frames will be sent
>> out and handled by the MAC layer.
>>
>> - We're in the process of using tinc to create P2P VPN network
>> overlays on top of the mesh and using the openssl library to support a
>> variety of encryption algorithms.
>>
>> - Public keys will be side-loaded or shared by physically bumping
>> phones with peers. Key pairs will also be generated on the device.
>> We'll support X.509 certs if users have a CA. The Manet Manager will
>> provide a convenient UI for sharing and managing keys and certs.
>>
>> Here's a list of some of the things we want to stay away from:
>>
>> - Being tied to a custom routing or mesh networking protocol. Custom
>> solutions often work very well and have their merits, but as a mesh
>> experimentation framework we'd like our protocols to be plug-and-play
>> if possible. Wouldn't it be great if there was a common API for
>> interacting with such protocols? It would be even better if they
>> worked transparently. That's why we're leaning towards a global device
>> proxy that intercepts all outgoing and incoming packets and sends them
>> to our Manet Service for mesh-related processing.
>>
>> - Data interception and MITM attacks. The idea of sending your public
>> key over the open air without a pre-existing authentication mechanism
>> presents an opportunity for identify spoofing and a MITM attack.
>> That's why we plan on sharing keys via side-loading or a phone bump.
>> Also, broadcasting data packets makes it relatively simple to sniff
>> those packets without placing a malicious device in promiscuous mode
>> or monitor mode. We'd like to encapsulate full IP packets + headers in
>> VPN tunnel mode. Also, we'd like to encrypt the routing protocol
>> traffic itself to prevent malicious entities from manipulating the
>> network topology and perform DoS attacks.
>>
>> Some things of note:
>>
>> - SPAN provides a generic ad-hoc enabler - that is, if your device is
>> rooted, your wireless chipset driver module supports ad-hoc mode, and
>> your kernel supports wireless extensions (wext). Devices with Broadcom
>> chips work the best - about half the time the kernel or module code
>> needs to be slightly modified or built with new kernel options. It's
>> not our goal to customize a kernel for each Android device out there.
>> It would be great if there was a way to roll in the necessary kernel
>> modifications into CyanogenMod or the like, but the device-specific
>> nature of those customizations makes that relatively difficult. Also,
>> it seems that CyanogenMod's intention is to stay as "vanilla" as
>> possible and to focus kernel changes on performance and stability
>> improvements.
>>
>> - We modified the pttdroid app. to get group voice chat working over
>> the mesh. The intent is to provide a simple replacement for
>> traditional push-to-talk (PTT) land mobile radios (LMRs) in a close /
>> moderate range environment. The app. is very simple - it's not
>> session-based and uses UDP, which works well in a mesh where people go
>> in and out of range at will. Using the app. you can see what other
>> peers are in the network, talk to them individually, create groups of
>> them, or passively listen for all incoming communications. The app.
>> doesn't support SIP or connect to a VOIP gateway.
>>
>> Links:
>>
>> Google group discussion forum: https://groups.google.com/forum/#!forum/spandev
>>
>> Open source code: https://github.com/ProjectSPAN
>>
>> - stoker
>>
>> _______________________________________________
>> Commotion-dev mailing list
>> Commotion-dev at lists.chambana.net
>> https://lists.chambana.net/mailman/listinfo/commotion-dev
>>
>