[Commotion-dev] SPAN Android App

Wed Oct 17 14:35:17 UTC 2012

Have you tried playing with the various Android Wifi locks and sleep
modes?  There are some new ones in 4.x that should improve multicast
performance, for example.  This sounds related to that.

.hc

On 10/17/2012 09:11 AM, Robble, Jeff wrote:
> Your comment about the Samsung Galaxy S II burst mode is interesting. When
> we tested a network of 10+ Samsung Galaxy S II's and 10+ Samsung Galaxy
> Nexus's we noticed that the Samsung Galaxy Nexus's would eventually drop
> out of the network because other devices couldn't receive their OLSR
> "hello" broadcasts. It seemed like the Samsung Galaxy S II's were drowning
> them out. The Samsung Galaxy S II's could still communicate. All of the
> devices were on 802.11 channel 1 and transmitting at 32 dBm (according to
> iwconfig).
> 
> Your MDP approach sounds promising. Would you please provide an example of
> the packet layout for the experimental olsr mode?
> 
> 
> Jeffrey Robble
> Software Systems Engineer
> The MITRE Corporation (Bedford)
> Office: 781.271.2790
> 
> 
> 
> On 10/16/12 6:15 PM, "Jeremy Lakeman" <Jeremy.Lakeman at gmail.com> wrote:
> 
>> On Wed, Oct 17, 2012 at 4:51 AM, Robble, Jeff <jrobble at mitre.org> wrote:
>>> The packet layout helps clarify. 256-bit key addresses are used to
>>> determine how to route packets between serval daemons in user space. IP
>>> addresses are still used to send packets between devices over the
>>> wireless
>>> interface.
>>>
>>> I assume the "payload body" is the only part of each serval payload
>>> that's
>>> encrypted and it's encrypted using only the final destination's public
>>> key. Is that accurate?
>>
>> Correct.
>>
>>> You mention that the source IP address is used to only send a unicast
>>> reply. I assume that a message with payloads destined for specific peers
>>> (i.e. the message does not contain a broadcast) is sent via unicast to
>>> the
>>> next hop. Is that accurate or are all messages broadcast over the
>>> wireless
>>> interface, received by the serval daemon on each device, and filtered
>>> accordingly?
>>
>> We prefer to send broadcast packets so we can include payloads for
>> multiple neighbours in the same frame, and it more closely matches
>> what's happening at the physical layer. We will need to fall back to
>> unicast packets if our neighbour can't hear our own broadcast packets.
>> Many android devices filter broadcasts when entering a low power
>> state, and some filter broadcasts all the time.
>>
>> Though broadcast packets are more unreliable on ad-hoc wifi, if
>> there's a collision or interference the packet will be lost. While the
>> wifi layer will ack / nack unciast packets and will retry a few times
>> until successful, we've found a couple of devices like Samsung G SII
>> that retry so much in burst mode they consume all available bandwidth
>> for ~0.9 seconds.
>>
>> Since we're expecting to route packets over a mesh, if a transmission
>> fails it may indicate that the topology has changed and any retry may
>> need to take a different path. Though we haven't implemented retries
>> at the network level yet.
>>
>>> I'm trying to figure out if your version of OLSR is using IP addresses
>>> or
>>> 256-bit key addresses. Does serval perform a lookup on the next hop
>>> 256-bit key addresses to determine its IP address and then send the
>>> message via unicast to that IP address?
>>
>> If we're running in our new experimental olsr mode, we don't actively
>> try to determine the topology of the mesh at all, that's olsr's job.
>> We use a similar payload header for messages we send via olsr's
>> flooding service, and we establish a routing table entry mapping PK to
>> IPv4 address. Then we always send unicast IP packets directly to the
>> final destination. This has a lot in common with our approach for
>> routing payloads via the internet.
>>
>> Since we can run a network in either mode, we should be able to easily
>> compare our routing engine to olsr to compare performance. I'm not
>> expecting us to beat olsr yet, we've still got a lot of work to do.
>> But if we get close, we should be able to prove it.
>>
>> While serval does support devices with multiple interfaces, we haven't
>> tackled use cases where those interfaces use different modes of
>> routing. Either all devices should be in olsr mode, or all devices
>> should be routing via our protocol.
>>
>>> Jeffrey Robble
>>> Software Systems Engineer
>>> The MITRE Corporation (Bedford)
>>> Office: 781.271.2790
>>>
>>>
>>>
>>>
>>> On 10/15/12 8:20 PM, "Jeremy Lakeman" <Jeremy.Lakeman at gmail.com> wrote:
>>>
>>>> On Tue, Oct 16, 2012 at 9:04 AM, Robble, Jeff <jrobble at mitre.org> wrote:
>>>>> Thanks for the clarification Jeremy.
>>>>>
>>>>> So you're randomly generating a 256-bit key pair and using the public
>>>>> key
>>>>> as the device network address. When you want to send data the serval
>>>>> daemon encrypts it using the 256-bit IP address of the destination and
>>>>> encapsulates it in a IP/UDP packet. Am I misunderstanding?
>>>>
>>>> A picture is worth a thousand words... The logical structure of our
>>>> transmitted IP packets look something like this;
>>>>
>>>> [ethernet header; source MAC, dest MAC, ...]
>>>> [ip / udp header; source IP, dest IP, source port, dest port, ...]
>>>> [serval packet format version number]
>>>> [transmitting device PK]
>>>> [payload list;
>>>>  [payload;
>>>>    - original source PK
>>>>    - final destination PK or broadcast identifier for de-duplication
>>>>    - next hop PK
>>>>    - payload length
>>>>    - payload body
>>>>  ],
>>>>  ...
>>>> ]
>>>>
>>>> Though the wire format does have some space saving tricks for sending
>>>> short abbreviations for PK addresses that are already known by both
>>>> parties.
>>>>
>>>> When we receive a packet, we only use the source IP address to work
>>>> out where to send unicast reply packets destined for the "transmitting
>>>> device PK". And only if we're running in olsr mode or the transmitter
>>>> is in a different network sub-net.
>>>>
>>>> We then look through the payload list for anything addressed to us as
>>>> the destination or next hop address, and process and/or forward them.
>>>>
>>>> So yes, the network discovers public keys as it builds the routing
>>>> table and communicates with other devices. So we can easily encrypt
>>>> any packet with a PK destination over the network. But that doesn't
>>>> mean we've authenticated anyone's identity or done anything to detect
>>>> a man-in-the-middle attack.
>>>>
>>>> Public key verification is still best done in person. Though we are
>>>> also looking at verification via an audio channel; relying on your
>>>> brain's ability to do voice print verification of identity, while
>>>> confirming the fingerprint of a shared secret.
>>>>
>>>> Eventually we may also implement key signing for building a web of
>>>> trust.
>>>
> 
> 
> _______________________________________________
> Commotion-dev mailing list
> Commotion-dev at lists.chambana.net
> http://lists.chambana.net/mailman/listinfo/commotion-dev
> 