[Commotion-dev] Commotion-dev Digest, Vol 21, Issue 5
Teco Boot
teco at inf-net.nl
Tue Jan 8 15:43:57 UTC 2013
I'll jump in inline.
Op 8 jan. 2013, om 14:05 heeft stoker het volgende geschreven:
> Hi Eric,
>
> Here's a link to the Manet Voice Chat app. based on pttdroid:
> https://github.com/ProjectSPAN/android-manet-ptt/tree/master/builds
>
> It took a little tinkering to get multicast working in the original
> pttdroid app. As you said, it doesn't work out of the box.
I remember testing it with multicast, on WiFi-Direct. No multihop,
other than via soft-AP. Maybe mcast route was missing in your setup.
(check default or 224/4 to wlan0)
I planned to test olsr with bmf plugin. It should work, I think.
> I should
> not that the Manet Voice Chat app. doesn't use multicast at this time.
>
> While the Manet Voice Chat app. does support group chat, it actually
> opens up a UDP socket to each individual peer rather than a multicast
> socket. I'm not a multicast guru, but using multicast in a mesh seems
> to present a few problems:
>
> - The official ipv4 multicast address range is 224.0.0.0 through
> 239.255.255.255. I'm not sure what will happen if you try to use an
> address outside this range.
Then, it is not IPv4 multicast :-)
> It probably won't work. What if the mesh
> subnet is 192.168.11.x?
Source IP address is your configured address, in this subnet. Mcast
addresses are destinations only.
> How would you setup a multicast group inside
> that subnet? Maybe you don't need to.
Multicast addresses are by definition application specific. Similar to
TV channel (which was tuning on a frequency setting).
>
> - How do peers in your group know which multicast address to use?
This needs out-of-band hints. Could be URL, NFC of use a keyboard.
> How
> would we ensure that no other groups are using the same multicast
> address?
Random addresses and UDP port numbers would not collide that much.
Crypto would help to guarantee something.
Current PTT users have procedures for channel selection. Often, there
are much less channels than "private" mcast IP addresses (239/8).
> We might need to implement some sort of multicast address
> resolution handshake system.
Yes.
Or just use a dictionary.
>
> - How would multicast work over P2P VPN links? With tinc, a tun
> interface is created for each link. If peer A has a link to peer B,
> and a separate link to peer C, it's easiest for A to open a separate
> socket for B and C.
The OLSR BMF plugin can run in pseudo-broadcast mode. And still use
MPR flooding. We need to patch the MPR problem in olsrd. It is
disabled because ETX link metics. Plan is to have it fixed in OLSRv2
release.
(BMF is non-selective, thus broadcast type of distribution)
> An alternative idea is to create VPN subnets or
> groupings overlaying the mesh, and broadcast voice packets within the
> subnet, but then the question becomes a matter of how those subnets
> are created on-the-fly as new groups are created.
I don't like the crypto tunnels, too much overhead and addressing
problems. If crypto is needed, just crypt payload. Use transport mode
or something similar.
>
> These are open questions we're still thinking about. Any ideas?
More ideas than solutions....
I've have to catch up getting my test phone up and running. I'll connect
to Eric's phone.
Teco
>
>
> On Tue, Jan 8, 2013 at 4:44 AM, Eric de Vries <Eric.de.Vries at ict.nl> wrote:
>>
>> Hi Hans,
>>
>> afaik there is no specific documentation regarding the blocking of ad-hoc mode on the devices that use a custom kernel, obviously only in the specific case that NO custom kernel is used...
>> Everything is simply based on testing on the devices themselves... To be more specific : in our case we discovered that MeshTether simply did not work anymore when we received our new test-devices (Samsung Galaxy Nexus). Beforehand MeshTether did work on an older device (HTC Desire running android 2.3) and on some older tablets (Samsung Tabs running Android 3.2).
>> We discovered for example that some custom kernel's (like the Franco kernel for the GNex) actually made it possible to flip the wifi-chipset in ad-hoc mode on our new test device... In the end it's as simple as this :
>> - from android 4.x.x the used kernels do not support wext (wireless extensions) by default, which makes results in not being able to flip the chip in adhoc mode (just as stoker mentioned in his post)...
>>
>> From your accounts it sounds as if MeshTether is able to do that : so I was simply curious if you had a chance to run MesTether and/or setting the network config on a 4.x.x device, and have seen that working as well ?
>> Unfortunately the situation is changed since ICS, so I was wondering if your experiences are based on pre-ICS or if you had everything up and running on a non-rooted, non custom-kernel running device ?
>>
>> Also a question for stoker : do you also have the "customized" ptttdroid app hosted somewhere so that we could test it as well ? Also do you have the multicast (via UDP) mode running ? The standard version actually crashes whenever multicast is selected instead of broadcast...
>>
>> On 07/01/2013 13:44 PM, Hans 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.
>>>
>>> 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.
>>>
>>> .hc
>>
>>
>>
>> ________________________________________
>> Van: Commotion-dev [commotion-dev-bounces at lists.chambana.net] namens commotion-dev-request at lists.chambana.net [commotion-dev-request at lists.chambana.net]
>> Verzonden: maandag 7 januari 2013 21:48
>> Aan: commotion-dev at lists.chambana.net
>> Onderwerp: Commotion-dev Digest, Vol 21, Issue 5
>>
>> Send Commotion-dev mailing list submissions to
>> commotion-dev at lists.chambana.net
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> https://lists.chambana.net/mailman/listinfo/commotion-dev
>> or, via email, send a message with subject or body 'help' to
>> commotion-dev-request at lists.chambana.net
>>
>> You can reach the person managing the list at
>> commotion-dev-owner at lists.chambana.net
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Commotion-dev digest..."
>>
>>
>> Today's Topics:
>>
>> 1. Re: Unifying Serval and Commotion Mesh (Paul Gardner-Stephen)
>> (Hans-Christoph Steiner)
>> 2. Re: Unifying Serval and Commotion Mesh (Paul Gardner-Stephen)
>> (Paul Gardner-Stephen)
>> 3. Re: MeshTether to the Play Store (Dan Staples)
>> 4. Re: MeshTether to the Play Store (Hans-Christoph Steiner)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Mon, 07 Jan 2013 13:44:55 -0500
>> From: Hans-Christoph Steiner <hans at guardianproject.info>
>> To: stoker <mistr.stoker at gmail.com>
>> Cc: commotion-dev at lists.chambana.net
>> Subject: Re: [Commotion-dev] Unifying Serval and Commotion Mesh (Paul
>> Gardner-Stephen)
>> Message-ID: <50EB17A7.9050209 at guardianproject.info>
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>>
>> 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.
>>
>> 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.
>>
>> .hc
>>
>>
>>
>> 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
>>>>>
>>>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Tue, 8 Jan 2013 06:54:58 +1030
>> From: Paul Gardner-Stephen <paul at servalproject.org>
>> To: Hans-Christoph Steiner <hans at guardianproject.info>
>> Cc: commotion-dev at lists.chambana.net
>> Subject: Re: [Commotion-dev] Unifying Serval and Commotion Mesh (Paul
>> Gardner-Stephen)
>> Message-ID:
>> <CA+_T8-D7rm9c42xz1jL4Uruvfsw=ci0aiGOaNdgBs1MqOw58EA at mail.gmail.com>
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>> 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
>>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Mon, 07 Jan 2013 15:37:32 -0500
>> From: Dan Staples <danstaples at opentechinstitute.org>
>> To: commotion-dev at lists.chambana.net
>> Subject: Re: [Commotion-dev] MeshTether to the Play Store
>> Message-ID: <50EB320C.3070209 at opentechinstitute.org>
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>> I agree, it would be great to get it into the Play Store. That said, I
>> have no idea what the process is to do that. Users inevitably complain
>> in the comments section of apps when it doesn't work on their phone, so
>> that would be useful information to us.
>>
>> Dan
>>
>> On 01/05/2013 03:35 AM, Teco Boot wrote:
>>> Op 5 jan. 2013, om 01:07 heeft Hans of Guardian het volgende geschreven:
>>>
>>>> Are there any plans for getting MeshTether in the Google Play Store? I think that could be a good way to get a lot of testers. It should be listed with a fair amount of caveats, but it certainly would be a fast to find out which devices it works on.
>>>>
>>>> I don't think the risk of it damaging phones is high at all. Mostly the risk is that we'll get a fair amount of negative feedback because it won't work on most devices (i.e. Samsung).
>>> Any outcome that brings us to better support for ad hoc would be great. Blame and shame is one method.
>>> The app should have a pointer to a wiki, with blacklist, whitelist and howto for enabling ad hoc.
>>> We can easily get custom mod's on whitelist, by just pushing our fixes upstream.
>>>
>>> Teco
>>>
>>>> .hc
>>>> _______________________________________________
>>>> 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
>>>
>>
>> --
>> Dan Staples
>>
>> Open Technology Institute
>> https://commotionwireless.net
>>
>>
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Mon, 07 Jan 2013 15:48:02 -0500
>> From: Hans-Christoph Steiner <hans at guardianproject.info>
>> To: commotion-dev at lists.chambana.net
>> Subject: Re: [Commotion-dev] MeshTether to the Play Store
>> Message-ID: <50EB3482.2060803 at guardianproject.info>
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>>
>> Hey Dan,
>> http://developer.android.com/distribute/googleplay/publish/preparing.html
>>
>> I think the hardest part will be figuring out how OTI or Commotion should
>> manage it, but the process is not hard.
>>
>> .hc
>>
>> On 01/07/2013 03:37 PM, Dan Staples wrote:
>>> I agree, it would be great to get it into the Play Store. That said, I
>>> have no idea what the process is to do that. Users inevitably complain
>>> in the comments section of apps when it doesn't work on their phone, so
>>> that would be useful information to us.
>>>
>>> Dan
>>>
>>> On 01/05/2013 03:35 AM, Teco Boot wrote:
>>>> Op 5 jan. 2013, om 01:07 heeft Hans of Guardian het volgende geschreven:
>>>>
>>>>> Are there any plans for getting MeshTether in the Google Play Store? I think that could be a good way to get a lot of testers. It should be listed with a fair amount of caveats, but it certainly would be a fast to find out which devices it works on.
>>>>>
>>>>> I don't think the risk of it damaging phones is high at all. Mostly the risk is that we'll get a fair amount of negative feedback because it won't work on most devices (i.e. Samsung).
>>>> Any outcome that brings us to better support for ad hoc would be great. Blame and shame is one method.
>>>> The app should have a pointer to a wiki, with blacklist, whitelist and howto for enabling ad hoc.
>>>> We can easily get custom mod's on whitelist, by just pushing our fixes upstream.
>>>>
>>>> Teco
>>>>
>>>>> .hc
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>
>>
>>
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> _______________________________________________
>> Commotion-dev mailing list
>> Commotion-dev at lists.chambana.net
>> https://lists.chambana.net/mailman/listinfo/commotion-dev
>>
>>
>> ------------------------------
>>
>> End of Commotion-dev Digest, Vol 21, Issue 5
>> ********************************************
>>
>>
>>
>>
>> _______________________________________________
>> 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