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

[Paul Gardner-Stephen]

Hello Hans,

On Tue, Jan 8, 2013 at 5:14 AM, Hans-Christoph Steiner
<hans at guardianproject.info> wrote:
>
> I'm happy to see you got adhoc working on some Samsung devices.  For the goals
> of Commotion MeshTether, custom kernels are not an option.  Do you have
> documentation on the specific issues that block adhoc mode on the devices
> where you used a custom kernel?  I ask because that is something that ideally
> we'd like to address for a popular devices.

I believe the problem is that the kernels on Android 4.0.1+ devices
specifically have removed ad-hoc wifi support.  On those devices, an
updated kernel is the only option.

This could be streamlined by enabling MeshTether/ServalMesh/SPAN to
pull kernels off the net and install them, without having to get
clockwork recovery or other tools specifically -- i.e., make it
trivial for an end user to do.

> When setting up adhoc mode on the Linux level, do you disable the wifi on the
> Android level?  This is what Serval does, but that doesn't work for MeshTether
> since the goal is to provide transparent TCP/IP networking.  Many if not most
> Android apps will check with Android whether the phone has a network
> connection before trying to use it.  So if the mesh app first tells Android to
> disable wifi, then uses the Linux tools to setup the network, Android will
> report there is no networking, all apps using this check will think there is
> no networking.
>
> I was able to get this working in MeshTether by setting the network config in
> both Android level and the Linux level.  Then the settings are in sync, and
> Android will report them properly to apps that ask.
>
> Last question from me: what kind of integration with Serval and MeshTether are
> you interested in?  IMHO, I think it would be great if we all joined efforts
> on the core bits, like an adhoc framework that includes the MethTether trick.
>  Also olsrd/batmand/etc. wrapping code.

>From a Serval perspective, I see the following strengths that might be
leveraged in a combined ad-hoc management application, taking the best
from each:

1. SPAN has specific interest in enabling ad-hoc as a goal unto itself
(whereas Serval and MeshTether/Commotion need ad-hoc mode as an
enabler for their core business)
2. Serval Mesh probably has the widest general handset support, and a
framework for adding scripts to support new handsets without
reinstalling the APK.
3. MeshTether has the trick for letting Android know that a network is
available.

I am sure that there are other advantages that each has, but it seems
to me that there are strengths in each that are worth combining into a
single Android ad-hoc management app.  Such a combined app would
probably give us leverage for inclusion in CyanogenMod and other
custom ROMs, as well as for encouraging Google/Android to do something
more definite about ad-hoc support in Android.

Paul.

> On 01/06/2013 03:35 PM, stoker wrote:
>> 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
>>>>
>>>
>
> _______________________________________________
> Commotion-dev mailing list
> Commotion-dev at lists.chambana.net
> https://lists.chambana.net/mailman/listinfo/commotion-dev
>