[Commotion-dev] Unifying Serval and Commotion Mesh (Paul Gardner-Stephen)
stoker
mistr.stoker at gmail.com
Tue Jan 8 01:29:07 UTC 2013
Hans, I understand why you guys would want to stay away from custom
kernels, but I believe that in doing so there will be certain devices
which you simply cannot support. One solution might be to pre-compile
your own wireless kernel module driver and insmod / rmmod it as
necessary.
We don't have documentation on the device-specific issues, but I just
compiled the following list for you:
Ad-hoc mode support is disabled on the Galaxy Nexus CDMA/LTE 4G AOSP
4.0.2 ICS kernel (android-omap-tuna-3.0-mr0.1)
Add NL80211_IFTYPE_ADHOC back into supported interface modes list:
/drivers/net/wireless/bcmdhd/wl_cfg80211.c
static struct wireless_dev *wl_alloc_wdev(struct device *sdiofunc_dev) {
// …
wdev->wiphy->interface_modes =
BIT(NL80211_IFTYPE_STATION) | BIT(NL80211_IFTYPE_ADHOC)
| BIT(NL80211_IFTYPE_AP) | BIT(NL80211_IFTYPE_MONITOR);
// ...
}
Ad-hoc mode support is disabled on the Nexus 7 AOSP 4.1.2 JB kernel
(android-tegra3-grouper-3.1-jb-mr0)
Add NL80211_IFTYPE_ADHOC back into supported interface modes list:
/drivers/net/wireless/bcmdhd/wl_cfg80211.c
static s32 wl_setup_wiphy(struct wireless_dev *wdev, struct device
*sdiofunc_dev)
{
// ...
wdev->wiphy->interface_modes =
BIT(NL80211_IFTYPE_STATION) | BIT(NL80211_IFTYPE_ADHOC)
| BIT(NL80211_IFTYPE_AP) | BIT(NL80211_IFTYPE_MONITOR);
// ...
}
Ad-hoc mode is disabled on the Samsung Galaxy S III GSM SGH-i747 ICS kernel
Add NL80211_IFTYPE_ADHOC back into supported interface modes list:
/drivers/net/wireless/bcmdhd/src/wl/sys/wl_cfg80211.c
static s32 wl_setup_wiphy(struct wireless_dev *wdev, struct device
*sdiofunc_dev)
{
// ...
wdev->wiphy->interface_modes =
BIT(NL80211_IFTYPE_STATION) | BIT(NL80211_IFTYPE_ADHOC)
| BIT(NL80211_IFTYPE_AP) | BIT(NL80211_IFTYPE_MONITOR);
// ...
}
Yes, like Serval we also disable the wifi at the Android level.
SPAN's interest goes beyond enabling ad-hoc mode. We're interested in
providing a secure and transparent ad-hoc networking capability on the
Android and iOS platform. We're also interested in developing
mesh-aware apps, such as group voice chat and bit-torrent-like data
sharing.
I think that single ad-hoc management service would be best. We have a
management app that's simply a UI which makes calls to the service.
The advantage of a service over an app is that:
- other apps can send commands to it to start / stop the mesh
- other apps configure the MANET programmatically
- other apps can query the service for mesh-related information, like
a peer listing
- it can be configured to automatically restart if it's killed by the
Android platform (it will also run longer than an app before being
killed)
Apps which make use of the SPAN Manet Service simply make calls to a
ManetHelper class that's packaged in a JAR library. Those apps can
then implement the ManetObservable interface and register for event
callbacks when the peer listing changes, the device switches out of
ad-hoc mode, etc. Note that apps don't need to use the service to use
the ad-hoc network. The service provides a tool for mesh-aware apps.
Both SPAN and Serval are based on the Wireless Tether for Root Users
app. so there's probably a lot of overlap in the way we flip the
device into ad-hoc mode.
On Mon, Jan 7, 2013 at 3:24 PM, Paul Gardner-Stephen
<paul at servalproject.org> wrote:
> 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
>>
More information about the Commotion-dev
mailing list