Phones as walkie talkies

[®om]

Hello,

I am very new to serval project, and don't have a clear vision of involved protocols and mechanisms.

Imagine I want to use phones like walkie talkies: I speak, I would like my voice to be *physically* broadcasted to everyone on the mesh network (with only few people, e.g. 5). I don't want to open n-1 communication, I would like to use the natural broadcasting nature of WiFi.

In BatPhone, it seems to be possible to make 1 call at a time. According to you, would it be possible to broadcast ? How, technically (what would happen in what protocol) ?

I read this paper : http://developer.servalproject.org/site/docs/2011/Serval_Introduction.html
According to §2.5, I have the impression that collision is a problem for messages greater than 1K: will it work for an audio stream ?
On the contrary, §2.7 plans to allow live video streaming (broadcasting).

How would you do that ?

Thank you for your lights ;-)

®om

[Jeremy Lakeman]

Our voice over mesh protocol (VoMP) is mainly designed as a
replacement for SIP. It handles a similar state model; codec
negotiation, "I'm ringing", "they're ringing", in call with audio,
hangup. It's not really suitable for n-way communications.

We don't yet have any kind of voice mail system. And we've had a
number of requests for some kind of push-to-talk, group chat system as
well.

The idea I've been bouncing around for a while, is to include voice
messages into our text messaging UI. Incoming voice messages would be
listed between text messages and sorted based on arrival time. The
user would need some UI elements to control audio playback, and may
specify that incoming audio messages are played immediately. Playback
would be paused while the user is recording an outgoing message.

This neatly side-steps around the complexity an n-way voice
conferencing system would have. We don't have to worry about echo
cancellation, or mixing multiple incoming voice tracks together.

You can currently use our messaging interface to send broadcast text
messages. But it's a bit of a hack, and probably has some undiscovered
bugs. We plan to support encrypted private group messaging eventually.
We've talked about possible solutions, but we haven't started working
on anything yet.

Our current text messaging solution is built on rhizome, our store and
forward file transport service. Outgoing messages are appended to a
log file which is added / updated in rhizome. rhizome copies this new
file to other network neighbours, flooding the network. That way
messages should eventually arrive, even if there is no real-time path
to your intended recipient. It should work if their phone was off when
you sent the message, and yours is off when they turn theirs on again.

But using rhizome also adds to the latency between sending and
arrival. Something that could be annoying with a push-to-talk system
as the network transfer wouldn't start until the entire message was
recorded. Streaming a new message while it's being recorded could be
useful, but we should always fall back to transferring via rhizome for
the extra resilience it offers.

If we're going to modify our text messaging service again, we really
want to rip out the file parsing code & message database from the
android / java code and shift all of that directly into servald. When
the user opens the activity to view a message thread, the android code
should be able to implement a Cursor to browse the messages directly
out of the message log in the rhizome content store. Shifting this
processing into servald will also help when we start porting this
service to other platforms.

On Sat, Oct 6, 2012 at 5:37 AM, ®om <romain...@gmail.com> wrote:
> According to §2.5, I have the impression that collision is a problem for
> messages greater than 1K: will it work for an audio stream ?

I don't believe that packet size has much effect on collisions on
wifi. I believe two transmitters can only collide if they start
sending a packet at the same time, otherwise they'll hear each other
and wont transmit even if they are slightly out of range of each
other. But packet length could effect the resilience to other sources
of interference.

> On the contrary, §2.7 plans to allow live video streaming (broadcasting).
>
> How would you do that ?

Live video streaming isn't really supported on android. The SDK
interfaces are all designed around recording media files for later
playback.

There are approaches that might work on some phones. eg;
http://code.google.com/p/spydroid-ipcamera/

But we don't have any current plans to implement anything.

We could certainly add the option to automatically share recorded
videos and photos via rhizome, but we have to be careful about disk
space limits.

> Thank you for your lights ;-)

Keep asking good questions, and we'll keep trying to answer them.

[®om]

Thank you very much for your answer, but for really understand it, I think I need to better understand serval-dna/VoMP/rhizome..., especially the protocols layers.

For what I understand, OpenMesh (batman) encapsulates ethernet frames. But after, what happens ?

Is serval-dna over IP, under IP or "replacement" for IP?
What about VoMP ?
Over which protocols is built Rhizome ?

For the live video streaming (at least when connected to an access point), spydroid-ipcamera code is very intesting (using a local socket file descriptor for getting live video from webcam using Android API is a good trick). (I just found weird ads in a GPL app).

[®om]

As far as I know, serval-dna is a kind of ARP, but concretely how does it work on a mesh network ?
Could you please explain what happens when I compose a number, util the voice communication starts ?

[Jeremy Lakeman]

When you set your phone number, servald rolls a new random public /
private key pair for your identity and stores your key, name and
number in its keyring file.

servald provides a service that allows you to construct a payload,
addressed to another persons public key or flagged as a mesh-wide
broadcast, and deliver it across the network. We call that Mesh
Datagram Protocol (MDP), and use the overlay_mdp_frame structure for
passing these payloads between the commandline process and the servald
daemon.

When the servald daemon receives a packet to send it constructs an
overlay_frame structure, which represents the network format servald
uses when talking to other neighbouring devices. And it contains state
tracking information for the payload while it is being processed.

servald daemons also exchange overlay frames with each other to
discover the structure of the local network. Building a routing table
so we can work out which of our local neighbours can deliver a packet
closer to each possible destination.

servald periodically composes packets, packed with some number of
payloads and sends them within an IPv4 broadcast packet on the
network. Each payload has 3 addresses in its header; the source of the
payload, the final destination, and the next hop neighbour that we
expect to forward it onwards for us.

More recently we also added the capability to compose packets to an
IPv4 unicast address. Firstly so that we could communicate with other
devices on an olsr based mesh network, but this should also come in
handy for communicating with other devices over the internet.

servald will respond to a DNA_LOOKUP mdp packet, by searching the
local keyring file for that phone number and responding with an
encrypted payload with the public key, name and number. It will also
respond to wildcard queries with every identity in the keyring, though
we may make this capability optional in future to allow for silent
phone numbers.

When you open batphone's peer list, we dump the list of route-able
public keys from servald. If we haven't cached the details already, we
send each address a wildcard dna lookup to discover their name and
number.

When you use your phone's built in dialler to call a number, we send
out a broadcast dna lookup and show you all of the responses to pick
from.

When you initiate a phone call, the MDP handler in vomp.c starts
sending packets addressed to the other persons public key. The
comments in vomp.c has a fairly complete description of the typical
call life cycle.

> --
> You received this message because you are subscribed to the Google Groups
> "Serval Project Developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/serval-project-developers/-/xceGy4suadIJ.
>
> To post to this group, send email to
> serval-proje...@googlegroups.com.
> To unsubscribe from this group, send email to
> serval-project-dev...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/serval-project-developers?hl=en.

[Paul Gardner-Stephen]

Hello,

In addition to Jeremy's explanations, we have a security framework
document which is currently in draft form, and which we hope to put
out publicly as soon as I have had a chance to do a last sanity check
on the content. This document will both provide you with information
about your questions, as well as give you and others the opportunity
to provide us with feedback on our approach.

Paul.

On Thu, Oct 11, 2012 at 3:58 AM, ®om <romain...@gmail.com> wrote:

[®om]

Thank you very much for your detailed explanation.

@Paul Gardner-Stephen, I just found and read a version of the document you talk about (maybe an old version, some C code differs a bit, but it's not important). It helped a lot, thank you.
https://code.commotionwireless.net/attachments/download/72/ServalSecurityFramework_r6.pdf

If I summarize what I have understood for both your answers and the pdf, the protocol layers are something like this:

+-------------------+
|   App (eg VoMP)   | (with DID) ---,
+-------------------+               |
|  MDP (UDP-like)   | (with port)   |
+-------------------+               | DNA (ARP-like)
|        SOM        | (with SID) <--'
+--------+----+-----+
|  UDP   |    |     |
+--------+ or | UFH |
|   IP   |    |radio|
+--------+    +-----+
| BATMAN |      ???
+--------+

I think DNA allows to resolve a SID from a DID, the same way ARP resolves an IP into a MAC addr.

Is my understanding correct ? Please fix any mistake I wrote ;-)

(page 7 of the pdf)

sending a *broadcast MDP* frame requires the explicit disabling of encryption for that frame"

What does "broadcast MDP" mean: is *every* device on the entire mesh network supposed to receive the data ? Only single-hop accessible devices ?


I come back to my very first question: use phones as walkie-talkies, for a "small" local mesh network (5-25 devices). In your opinion, can "unicast" be sufficient (send n times the same data to different devices) ?

For simplicity, consider that each phone knows the SID of all others (pre-generated SID). In this very specific case, we do not need DID at all (or we can store a static list of dna_identity_status on sdcard of every device).

When someone wants to speak with A, B and C (they know their SID), for each audio packet captured, we can encapsulate them into RTP for streaming, then encapsulate in 3 "identical-payload" MDP packets for sending, one for A, one for B and one for C. If someone else wants to speak with B, D and E, we do the same.
My concern is about network-saturation. Do you think there is a chance it will work ?

[Jeremy Lakeman]

> I think DNA allows to resolve a SID from a DID, the same way ARP resolves an
> IP into a MAC addr.

That's essentially correct. MDP packets sent to port
MDP_PORT_DNALOOKUP, are used to resolve SID's for each phone number.

Once we have the SID, the application layer needs to remember it and
send all further communications to that address. From the
application's point of view, resolving from a DID to a SID has more in
common with a dns to IP lookup.

The network implementation is closer to ARP in the sense that the
resolution requests are flooded across the network.

>> sending a *broadcast MDP* frame requires the explicit disabling of
>> encryption for that frame"
>
>
> What does "broadcast MDP" mean: is *every* device on the entire mesh network
> supposed to receive the data ?

Yes, each device repeats the payload on every interface once, or until
the ttl expires. Not quite as bandwidth efficient as olsr's MDR
flooding process though.

> I come back to my very first question: use phones as walkie-talkies, for a
> "small" local mesh network (5-25 devices). In your opinion, can "unicast" be
> sufficient (send n times the same data to different devices) ?

Yes, an application could certainly do that.

> For simplicity, consider that each phone knows the SID of all others
> (pre-generated SID). In this very specific case, we do not need DID at all
> (or we can store a static list of dna_identity_status on sdcard of every
> device).

Or store the SID's in the android contact book, which we can already
do. That's what the little plus icon does on the peer list / phone
number lookup results. (Hmmm, we need to make that more obvious to the
user...)

> When someone wants to speak with A, B and C (they know their SID), for each
> audio packet captured, we can encapsulate them into RTP for streaming, then
> encapsulate in 3 "identical-payload" MDP packets for sending, one for A, one
> for B and one for C. If someone else wants to speak with B, D and E, we do
> the same.
> My concern is about network-saturation. Do you think there is a chance it
> will work ?

That could absolutely work. Provided you deal with the complexity of
echo cancellation (difficult on android) & audio mixing.

As I said earlier I think our preferred solution for multi-party
conversations would be more like a text messaging application, with
push-to-talk recording of new messages. But you could certainly
deliver the audio messages via mdp as you outlined above.

Simultaneously publishing the audio messages via rhizome would give
you better network resilience. And provide a "voice mail" like service
for very high latency conversations between occasionally connected
people.

[®om]

Very instructive.

Instead of RTP, maybe we could reuse a part of VoMP implementation which encodes/stream using speex codec (already implemented in serval I think). For echo cancellation, I would ignore it for the moment (I'll use a headset).

Your idea of providing a "voice mail" using rhizome is interesting, but for walkie-talkies, we want only "live" streaming, if we didn't receive/understand something, it's lost.

But I wonder, just for understanding, if for walkie-talkies I use hardcoded SID, and imagine I don't want encryption, couldn't I use directly the routing protocol without serval (batman) ?
If I reformulate, I think the benefits of serval is to use higher-level protocols (vomp, meshms, rhizome), and have addresses without collision (256bits), with encryption. If we have 25 devices with hardcoded SID, using your MDP-layer protocol, what are the benefits of serval in your opinion ?
In serval we use SID as devices identifier ; what is the device identifier on an OpenMesh/Batman ? IP ? How are they configured ? Does the IP never change ?

[®om]

Yes, each device repeats the payload on every interface once, or until
the ttl expires.

Great !
However, I think it is incompatible with encryption (using the SID key), isn't it ?

[®om]

In serval-dna, you have a Speex library, with speex_jni.cpp in batphone project. But did I miss something, I did not find where it was called ?

Do you use speex for VoMP ? In java files, I only found alaw/ulaw converter, but not any call to speex encoder.

[Jeremy Lakeman]

We didn't delete speex when we removed the rest of the SipDroid code
that used it. We were vaguely thinking that we might reinstate it at
some point, but never got around to it.
SipDroid's java codec interface can be found here if you'd like to reinstate it;
http://code.google.com/p/sipdroid/source/browse/#svn%2Ftrunk%2Fsrc%2Forg%2Fsipdroid%2Fcodecs
We'd also like to implement Opus, mainly because if we had opus we
probably wouldn't need to implement anything else.
Just note that vomp.c doesn't handle variable rate codecs, it expects
each block of encoded audio to be the same length.

Using cryptographically secure keys with MDP lets you ignore all of
the routing layer, and can provide protection from tampering and/or
security from eavesdropping without too much additional effort. It's
relatively simple to write a single threaded mdp client application in
C. You could look at directory_service.c for an example of one.

We haven't exposed any mdp primitives through a JNI interface at this
time. Instead the android application calls servald's command line
functions through a JNI interface. In hindsight it would have been
better to expose mdp handling to java and perhaps implement packet
handing code via another native call, but we haven't done that and it
will take a fair amount of effort to rework everything now. Instead
the android voice code uses the stream based monitor interface that
we've implemented.

> --
> You received this message because you are subscribed to the Google Groups
> "Serval Project Developers" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/serval-project-developers/-/_EkD-WC_VWIJ.

[Paul Gardner-Stephen]

Hello,

No. The destination is never* encrypted, and when you dispatch and MDP
packet for broadcast you specify that it is not encrypted, and
possibly not signed if you don't care about authentication, so that it
can be received by many parties.

Perhaps we need a multi-cast type system as well, but I think that MDP
broadcast will be fine for now. The main caveat is that the
verification of signed packets is currently too slow, so I would
disable signing of audio packets.

Paul.

> --
> You received this message because you are subscribed to the Google Groups
> "Serval Project Developers" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/serval-project-developers/-/tpTXKhreN9QJ.

[®om]

Le vendredi 12 octobre 2012 11:43:42 UTC+2, Jeremy Lakeman a écrit :

We haven't exposed any mdp primitives through a JNI interface at this
time. Instead the android application calls servald's command line
functions through a JNI interface.

 

 In command line, there is only "mdp ping" (which works ^^) :

 mdp ping <SID|broadcast> [<count>]
   Attempts to ping specified node via Mesh Datagram Protocol (MDP).

If I want to send a MDP packet from Java (as byte[]), what should I do ? Create another command "mdp send <sid> <data>" ?
In that case, I think I'll have to do some byte[]->String conversion (base64) in Java and the opposite in C : what about performances ?
What would you suggest ?

Le vendredi 12 octobre 2012 11:43:42 UTC+2, Jeremy Lakeman a écrit :

Instead the android voice code uses the stream based monitor interface that
we've implemented.

Please tell me more about this monitor interface. I don't really understand what it does.

Thank you for your help.

[Paul Gardner-Stephen]

Hello,

On Sat, Oct 27, 2012 at 1:46 AM, ®om <romain...@gmail.com> wrote:
> Le vendredi 12 octobre 2012 11:43:42 UTC+2, Jeremy Lakeman a écrit :
>>
>> We haven't exposed any mdp primitives through a JNI interface at this
>> time. Instead the android application calls servald's command line
>> functions through a JNI interface.
>
>
> In command line, there is only "mdp ping" (which works ^^) :
>
> mdp ping <SID|broadcast> [<count>]
> Attempts to ping specified node via Mesh Datagram Protocol (MDP).
>
> If I want to send a MDP packet from Java (as byte[]), what should I do ?
> Create another command "mdp send <sid> <data>" ?
> In that case, I think I'll have to do some byte[]->String conversion
> (base64) in Java and the opposite in C : what about performances ?
> What would you suggest ?

There is currently no Java interface to MDP, largely because we
haven't had time to make one.

It is possible to create and manipulate MDP sockets and packets from
C, so making a JNI bridge to the MDP client code. See mdp_client.h
for high-level API, and mdp_client.c for the implementation of these
things. commandline.c is where the "mdp ping" command is implemented,
and is the sole reference implementation of an MDP client, and would
be a good place to start.
I think some of the guys from the Commotion project are working on
some MDP-related documentation, but I am not sure when it will be
available.

> Le vendredi 12 octobre 2012 11:43:42 UTC+2, Jeremy Lakeman a écrit :
>>
>> Instead the android voice code uses the stream based monitor interface
>> that
>> we've implemented.
>
> Please tell me more about this monitor interface. I don't really understand
> what it does.

The monitor interface is a simplified interface to a number of Serval
daemon functions, in particular rhizome notifications and VoMP call
handling.

> Thank you for your help.

Happy to help,

Paul.

> --
> You received this message because you are subscribed to the Google Groups
> "Serval Project Developers" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/serval-project-developers/-/l4RztM-tyTQJ.

[®om]

Le samedi 27 octobre 2012 05:23:49 UTC+2, Paul Gardner-Stephen a écrit :

There is currently no Java interface to MDP, largely because we
haven't had time to make one.

No problem. Maybe I can make it (at least try).

 

It is possible to create and manipulate MDP sockets and packets from
C, so making a JNI bridge to the MDP client code.  See mdp_client.h
for high-level API, and mdp_client.c for the implementation of these
things.  commandline.c is where the "mdp ping" command is implemented,
and is the sole reference implementation of an MDP client, and would
be a good place to start.

If I correctly understand how it works, in Batphone, there is the Java-part which can call the native-part through JNI, and the native-part communicating with servald, which is a separate binary in a separate process. The batphone native-part communicates with servald essentialy through commandline.

+------+ JNI +--------+  cli  +---------+
| Java |---->| native ||---->|| servald |
+------+     +--------+       +---------+
                       monitor?

(of course, servald is native too, but it is not a shared library used by JNI)
Am I right ?

If I am, MDP is only accessible in servald, so there is 2 missings parts for using it in Java :
 - the JNI bindings ;
 - the communication between Batphone native part and servald.

For the second part, how would you do ? Is commandline the only/best way ?
Do you think it is a good idea to implement something like :
mdp send <sid> <data>

Or is there a better approach?

The monitor interface is a simplified interface to a number of Serval
daemon functions, in particular rhizome notifications and VoMP call
handling.

Is it an alternative to commandline for communicating with servald ?
If it is the case, should I use it instead of commandline for sending MDP packets ?
How does it work ?

Thank you

[Jeremy Lakeman]

All of the command line functions run within the java process, called via JNI.

We need to expose something equivalent to overlay_mdp_bind,
overlay_mdp_send, overlay_mdp_client_poll, overlay_mdp_recv,
overlay_mdp_client_done.

We also need to be very careful about concurrency. The servald code
has been written assuming that it will be single threaded. For now
we've simply made sure all JNI calls are "serialized" in the java
layer.

> --
> You received this message because you are subscribed to the Google Groups
> "Serval Project Developers" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/serval-project-developers/-/6cQBUmoTIBIJ.

[®om]

Le samedi 27 octobre 2012 13:23:35 UTC+2, Jeremy Lakeman a écrit :

All of the command line functions run within the java process, called via JNI.

Ah, ok !

The possibility to call servald directly in shell misled me : I thought Java executed a shell command to call servald.

In fact, it is directly a jni call which executes rawCommand (which is a good news for me). Thank you for your answer.

In that case, how does the shell command line works ? If I execute, in a shell :
/data/data/org.servalproject/bin/servald mdp ping ...
it is not in the same process as the serval daemon. How does it communicates with it ?

We need to expose something equivalent to overlay_mdp_bind,
overlay_mdp_send, overlay_mdp_client_poll, overlay_mdp_recv,
overlay_mdp_client_done.

OK, so at the "same level" as rawCommand (the java part will call mdp functions through JNI instead of rawCommand with parameters). Am I right ?

 

We also need to be very careful about concurrency. The servald code
has been written assuming that it will be single threaded. For now
we've simply made sure all JNI calls are "serialized" in the java
layer.

OK, I'll take care ;-)

Thank you again.

[®om]

Hi,

Did you have some time for testing the MDI JNI bindings I proposed :
https://github.com/servalproject/batphone/pull/51
https://github.com/servalproject/serval-dna/pull/39

Thank you for your feedbacks.

[Paul Gardner-Stephen]

Hello Rom,

Our apologies for not having been able to commit significant time to
this as yet.
We have been quite flat out satisfying the requirements of some grants.

The general approach and concept looks good, though, subject to Jeremy
being happy with the approach. Certainly it will be good to get MDP
socket support from in Java.

One minor concern I have is overlay_mdp_recv() becoming blocking.
Because servald is designed to be single-threaded, we need to be able
to support fully asynchronous operation. As servald may end up using
MDP socket services as a client (eg to talk to other servald instances
on other nodes to exchange various information), we need a
non-blocking solution. It might just be a flag passed in to
overlay_mdp_recv() to tell it to be non-blocking, so that we have that
option for when it is needed.

You will have probably noticed some substantial commits to serval-dna
in particular lately. If you can make sure that your patches marge
with those, that will begin to clear the way for us to integrate them.
Be sure to re-run all the test scripts in tests/ to make sure that
all functionality covered by our tests is unaffected.

Paul.

> --
> You received this message because you are subscribed to the Google Groups
> "Serval Project Developers" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/serval-project-developers/-/hlmT3IzFmGAJ.

[Paul Gardner-Stephen]

Hi Rom,

One other step that will be necessary for the contributions to the
serval-dna is that we would need a contributor agreement from
yourself, as I don't think we have one on record.

I realise that this is is a bit of a nuisance, but it is important so
that we can dual-license specific binary releases of serval-dna, in
particular, for making iOS or Windows Mobile releases in future, as
the application market rules for those platforms will reject GPL
licensed applications. This is an annoying compromise, but important
if we want to help as many people as possible.

Only Serval Project Inc. (SPI) would have the ability to dual-license,
and SPI is an incorporated non-profit association governed by its
articles of incorporation, and which outline the mission of SPI in
furthering the Serval Project, and also under the establishing South
Australian law prevents benefit flowing to the members and committee
of the association, except for bonafide services rendered. In other
words, we don't get rich from your contributions, and they will be
used to further the objectives of the Serval Project. We can provide
you with a copy of the articles of incorporation if you would like to
examine them.

Out contributor agreement is the standard one provided by the Harmony
Project, and is available for download from:
http://developer.servalproject.org/dokuwiki/lib/exe/fetch.php?media=content:software:developeragreements:serval_project_inc-entity.pdf

Let me know if your have any questions or concerns,

Paul.

[®om]

Thank you for your feedbacks.

Sorry for my late response, I have not had much time recently.

One minor concern I have is overlay_mdp_recv() becoming blocking.
Because servald is designed to be single-threaded, we need to be able
to support fully asynchronous operation.  As servald may end up using
MDP socket services as a client (eg to talk to other servald instances
on other nodes to exchange various information), we need a
non-blocking solution.  It might just be a flag passed in to
overlay_mdp_recv() to tell it to be non-blocking, so that we have that
option for when it is needed.

OK, I'll probably just add a flag which will be set to "blocking" when called from the jni code.
Anyway, when it is non-blocking, it crashes once the buffer is full (errno=11).

You will have probably noticed some substantial commits to serval-dna
in particular lately.  If you can make sure that your patches marge
with those, that will begin to clear the way for us to integrate them.
 Be sure to re-run all the test scripts in tests/ to make sure that
all functionality covered by our tests is unaffected.

OK, I will merge and re-run tests (probably not very soon, maybe next month).

[®om]

I had a look at this document. I will read it more closely.

If I accept it, I have to sign (manually + GPG?) and send it by mail ?

[®om]

For the moment, the routing protocol is a kind of black-box to me. I just use SID/port, and the packet magically arrive to the right target.

I would like to know a bit more about the protocol.

In this message (see ASCII-art schema):
https://groups.google.com/d/msg/serval-project-developers/bebngkEXesI/VcINI_S399wJ
I thought batman was at the lowest level. But in fact, it seems I was wrong: your batman-like protocol is at SOM level (overlay_route).

You said all your layers are implemented *above* IPv4/UDP. But how does it work? For example, what UDP-port does your batman use?

There is also overlay_oslr, where a port is configurable, but I did not find it for your batman protocol.

Another question: how to choose if we want to use oslr or batman?

Thank you ;-)

[®om]

I just found the default UDP port is 4110 (thanks to netstat and ack-grep).

$ ack-grep -w 4110
rhizome.h
45:#define RHIZOME_HTTP_PORT 4110

serval.h
146:#define PORT_DNA 4110

You seem to like the value 4110 (constants.h):
16 bit - Magic value 0x4110

;-)

One part of my question is resolved. The other: how to switch from batman-like to oslr (just for information, I don't really want to switch) ?

[Paul Gardner-Stephen]

Hello,

On Wed, Dec 19, 2012 at 8:54 PM, ®om <romain...@gmail.com> wrote:
> I had a look at this document. I will read it more closely.
>
> If I accept it, I have to sign (manually + GPG?) and send it by mail ?

We need a manually signed one. Scan and email to me, and then post
the original is best.

Thanks,

Paul.

> --
> You received this message because you are subscribed to the Google Groups
> "Serval Project Developers" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/serval-project-developers/-/tr5IONvC9bUJ.

[Paul Gardner-Stephen]

Hello,

On Wed, Dec 19, 2012 at 9:17 PM, ®om <romain...@gmail.com> wrote:
> For the moment, the routing protocol is a kind of black-box to me. I just
> use SID/port, and the packet magically arrive to the right target.
>
> I would like to know a bit more about the protocol.
>
> In this message (see ASCII-art schema):
> https://groups.google.com/d/msg/serval-project-developers/bebngkEXesI/VcINI_S399wJ
> I thought batman was at the lowest level. But in fact, it seems I was wrong:
> your batman-like protocol is at SOM level (overlay_route).
>
> You said all your layers are implemented *above* IPv4/UDP. But how does it
> work? For example, what UDP-port does your batman use?
>
> There is also overlay_oslr, where a port is configurable, but I did not find
> it for your batman protocol.

If using BATMAN, we use the normal BATMAN port, but we actually don't
usually use BATMAN, but rather our own built-in routing engine inside
the servald process, which uses port 4110.

> Another question: how to choose if we want to use oslr or batman?

So in older version of Serval Mesh you could enable olsrd or BATMAN as
a form of "legacy" mesh operation. But Serval Mesh really just uses
its own internal SID-based routing system. The precise operation of
that is under some flux as Jeremy continues to develop it.

Paul.

> Thank you ;-)
>
> Le mercredi 19 décembre 2012 11:24:45 UTC+1, ®om a écrit :
>>
>> I had a look at this document. I will read it more closely.
>>
>> If I accept it, I have to sign (manually + GPG?) and send it by mail ?
>

> --
> You received this message because you are subscribed to the Google Groups
> "Serval Project Developers" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/serval-project-developers/-/nOZXxPG5Y1IJ.

[Paul Gardner-Stephen]

Hello,

On Thu, Dec 20, 2012 at 7:20 PM, ®om <romain...@gmail.com> wrote:
> I just found the default UDP port is 4110 (thanks to netstat and ack-grep).
>
> $ ack-grep -w 4110
> rhizome.h
> 45:#define RHIZOME_HTTP_PORT 4110
>
> serval.h
> 146:#define PORT_DNA 4110

This, as mentioned, is for the internal SID-based routing system in
servald, not for an actual BATMAN-compatible IP-based routing system.

> You seem to like the value 4110 (constants.h):
> 16 bit - Magic value 0x4110
>
> ;-)

"411" is the directory assistance number in North America*, so it
seemed like a nice starting part for our port numbers and magic
numbers. We might change the final 0 to another digit in future
versions.

* We live in Australia, however, where the directory assistance number
is 1223, but that was to low, and 12230 was too high, where as 4110
seemed like about the right size number.

> One part of my question is resolved. The other: how to switch from
> batman-like to oslr (just for information, I don't really want to switch) ?

See other message.

Paul.

> Le mercredi 19 décembre 2012 11:47:57 UTC+1, ®om a écrit :
>>
>> For the moment, the routing protocol is a kind of black-box to me. I just
>> use SID/port, and the packet magically arrive to the right target.
>>
>> I would like to know a bit more about the protocol.
>>
>> In this message (see ASCII-art schema):
>>
>> https://groups.google.com/d/msg/serval-project-developers/bebngkEXesI/VcINI_S399wJ
>> I thought batman was at the lowest level. But in fact, it seems I was
>> wrong: your batman-like protocol is at SOM level (overlay_route).
>>
>> You said all your layers are implemented *above* IPv4/UDP. But how does it
>> work? For example, what UDP-port does your batman use?
>>
>> There is also overlay_oslr, where a port is configurable, but I did not
>> find it for your batman protocol.
>>
>> Another question: how to choose if we want to use oslr or batman?
>>
>> Thank you ;-)
>

> --
> You received this message because you are subscribed to the Google Groups
> "Serval Project Developers" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/serval-project-developers/-/NVf9YNgJ85UJ.

[®om]

I merged and pushed. Tests are ok (except tests/jni number 1 and 3, which fail even without my commits).

I e-mailed you my acceptation of the Contributor Agreement.

I still have to make overlay_mdp_recv() non blocking (with a flag).

[Paul Gardner-Stephen]

Sounds good.

If you can still post the original of your contributor agreement to
us, that would be super (Australian law is a bit funny sometimes about
copyright deeds).

Thanks,

Paul.

> --
> You received this message because you are subscribed to the Google Groups
> "Serval Project Developers" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/serval-project-developers/-/fhLApwXuXgIJ.

[Andrew Bettison]

Please see my comment in
https://github.com/servalproject/serval-dna/pull/39 regarding the
non-blocking flag. I do not believe it is necessary. Jeremy and I will
have to nut this out out and get back to you, but I think that we can
leave your code as-is for the purposes of merging.

> I still have to make overlay_mdp_recv() non blocking (with a flag). --

> You received this message because you are subscribed to the Google
> Groups "Serval Project Developers" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/serval-project-developers/-/fhLApwXuXgIJ.

> To post to this group, send email to
> serval-proje...@googlegroups.com.
> To unsubscribe from this group, send email to
> serval-project-dev...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/serval-project-developers?hl=en.

--
Andrew Bettison
Senior Software Engineer
and...@servalproject.org | Mobile +61 407185656 | Skype ajbettison