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

[Hans of Guardian]

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
>