Using an existing mesh network to extend the range of serval

[Jonathan]

Note: I'm quite new to this stuff so feel free to correct me if I make wrong assumptions.

Hi.

I am a student, and while exploring the mesh networks scene I came across Serval and I like it.

Since Serval's range is limited to the range of wifi (when there are no more phones around) I thought, maybe there is a way to extend its range. Serval uses a mesh protocol, when in ad-hoc mode, to connect two phones and doesn't use a mesh protocol when in client mode (is it true?). What if I build a mesh network of routers (OpenWrt) using OLSR to emulate a network like freifunk and put one phone in one end of the mesh and another phone in the other end of the mesh and see if I can connect them.

I installed OpenWRT on two routers and set up OLSR with HNA4 on them. Then I installed Serval on two phones and chose client mode on both of them. I connected phone1 to router1 and phone2 to router2, and tried to ping between them. The set up is two LANs, one 192.168.1.0/24 on router1 and the second is 192.168.2.0/24 on router2. Phone1 got the address 192.168.1.15 from router1 and phone2 got the address 192.168.2.15 from router2. Because of the HNA4 the ping from phone1 to phone2 worked.

Now I tried to use serval to call from phone1 to phone2. I saw immediately that the phones don't see each other and I couldn't make a call from one of them to the other. I am trying to figure out why is that and what do I have to do to make it work.

First thought is that serval uses broadcast packets to announce its existence in the network and the broadcast packets are not being transferred from one network to the other. Is it true? Is there anything I could do about it?

Second thought is, I only tried client mode. Is it possible to make serval treat the routers as phones running serval although they only have OLSR? I still don't have the set up of how to do that in mind.

After I succeed in making it work I'll check if it is practical for real life use.

Thank you.

[Jeremy Lakeman]

Yep, you're mostly correct.

Serval sends broadcast packets, to discover neighbours and resolve
phone numbers, that can only be heard by other devices on the same IP
subnet. We use the same peer discovery process on whatever network
servald is configured to use. In your setup you'd have to run servald
on each router so our routing protocol can extend the mesh network, or
bridge the networks together into one big subnet.

Compiling servald to run on your openwrt devices should be fairly easy
right now, we build it for linux and osx all the time for testing. But
the routing code we have built is fairly simplistic and not well
tested for multi-hop situations.

While we could invest time in trying to debug and improve our current
routing approach, I've been designing and simulating a different
approach to routing that I'd like to implement instead. But there are
still a number of big changes that need to be made to our daemon
before I can really start that. Plus we have a number of other
priorities that we need to work on.

Another option we've been working on quite recently, is the ability to
co-exist on an olsr network. We've written an olsr plugin that can
relay broadcast frames on behalf of our servald daemon. Plus we've
added the capability to send unicast packets directly to any IPv4
address for delivering packets without using our mesh route
calculation code. So serval devices can discover each other on an olsr
network and then communicate directly. Again this could do with some
further testing, and the code isn't in our master branch yet. But
using it would require some additional work to get olsr and our plugin
running on android, plus appropriate user configuration to enable it.

> --
> 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/-/GYp4P25wLj8J.
> 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.

[Jonathan Lahav]

Hello and thank you very much for your detailed answer. It took me a long time to understand all of the possible scenarios hence the long delay before the following message.

Before I start, I have to clarify something. You mentioned "servald", but I had a really hard time finding any online text about "servald" or "the serval daemon". Now I suspect that "servald" is what is called "serval-dna" on github. Is that correct?

> In your setup you'd have to run servald on each router so our routing protocol can extend the mesh network

If I understand what you say, each router would have to run OLSR and servald for that to work, and all of the phones would have to connect using client mode. The broadcast messages on the LANs would still not travel from one phone to the other, but it would reach the router which in turn will remember the existence of the sending phone and populate this information to his neighboring routers on the ad-hoc network interface used for OLSR routing, and from each receiving router it would reach the LANs connected to it. We would have two parallel propagation systems, one for routing (OLSR, so devices could send packets to each other), and one for peer discovery (servald).

This sounds like a feasible solution, like you said, although it would require installing additional software on an existing networks' routers, which is unfavorable, but apparently inevitable.

> or bridge the networks together into one big subnet.

Is this the simplest solution? It looks like it. It is good for testing purposes so it's good you mentioned it, but I think it is safe to say that it won't fit real networks  because it is simply not how they are set up.

> But the routing code we have built is fairly simplistic and not well tested for multi-hop situations.

What are the implications of it? Do you say I should wait before trying to make it work or maybe in my scenario it doesn't matter and in the future it would scale to larger networks?

> I've been designing and simulating a different approach to routing that I'd like to implement instead

Do you really mean routing approach? I'm a bit confused. I though that routing is being taken care of by OLSR, or maybe you mean peer discovery approach?

Does it already have a name? Is it described in any online document? It sounds interesting.

> Another option we've been working on quite recently, is the ability to co-exist on an olsr network...

I initially thought that the plugin's purpose is so one won't have to install another deamon on his router in order for the  first option you described to work, but only a plugin. Now I see that I probably got it wrong. What is it then?

When you say "co-exist" you mean that the phones would use ad-hoc mode and be part of the OLSR network? What is the difference between that and using client mode regarding broadcast peer discovery? I'm not sure about that but wouldn't the broadcast reach only the direct neighbors? If that's the case, then wouldn't we still need servald on the routers for peer discovery? The only difference I see is that we won't need HNA4 for the phones to be able to ping each other, but the discovery would be the same, wouldn't it?

> Plus we've added the capability to send unicast packets directly to any IPv4

> address for delivering packets without using our mesh route calculation code.

What is this about? Isn't it already working on regular mesh networks with OLSR and HNA4?

I'm sorry it turned out to be that long. I don't want to take too much of your time so I would appreciate even short answers. I'm really interested in the subject and I couldn't find enough documentation on the subject.

Thank you very much, and good luck with your work.

Jonathan

[Jeremy Lakeman]

On Fri, Oct 5, 2012 at 10:20 PM, Jonathan Lahav <j.l...@gmail.com> wrote:
> Hello and thank you very much for your detailed answer. It took me a long
> time to understand all of the possible scenarios hence the long delay before
> the following message.
>
> Before I start, I have to clarify something. You mentioned "servald", but I
> had a really hard time finding any online text about "servald" or "the
> serval daemon". Now I suspect that "servald" is what is called "serval-dna"
> on github. Is that correct?

Correct. We've tried to build as much new functionality as possible
into servald, leaving the "batphone" / "Serval Mesh" android layer for
user interactions.
In future servald would form the basis of any port to another
platform, very little of the android code would be useful. In fact we
mainly develop and test servald on linux and OSX.

>> In your setup you'd have to run servald on each router so our routing
>> protocol can extend the mesh network
> If I understand what you say, each router would have to run OLSR and servald
> for that to work, and all of the phones would have to connect using client
> mode. The broadcast messages on the LANs would still not travel from one
> phone to the other, but it would reach the router which in turn will
> remember the existence of the sending phone and populate this information to
> his neighboring routers on the ad-hoc network interface used for OLSR
> routing, and from each receiving router it would reach the LANs connected to
> it. We would have two parallel propagation systems, one for routing (OLSR,
> so devices could send packets to each other), and one for peer discovery
> (servald).
> This sounds like a feasible solution, like you said, although it would
> require installing additional software on an existing networks' routers,
> which is unfavorable, but apparently inevitable.

Correct. Currently servald is built to form its own route-able mesh
network, without touching the actual IP routing table. Mainly because
we've thought of a number of use cases where we won't be able to rely
on traditional layer 3 routed mesh networking.
The servald daemon currently treats all configured network interfaces
as if they have the properties of an adhoc mesh. We send all traffic
via broadcast packets since this doesn't waste any additional airtime.
And we stuff many small messages, destined for different neighbours,
into one packet.
But that means that if other network nodes can't be reached by a
broadcast packet, we can't discover them. So if servald's own routing
protocol is going to work, it has to run on every device in the mesh,
just as olsr would.
And it also means we cause more traffic than we need to on other types
of networks. A large number of servald instances on the same switched
ethernet network are going to be wasting a lot of their available
bandwidth just making sure they are all still there.

>> or bridge the networks together into one big subnet.
> Is this the simplest solution? It looks like it. It is good for testing
> purposes so it's good you mentioned it, but I think it is safe to say that
> it won't fit real networks because it is simply not how they are set up.

And it's not going to scale...

>> But the routing code we have built is fairly simplistic and not well
>> tested for multi-hop situations.
> What are the implications of it? Do you say I should wait before trying to
> make it work or maybe in my scenario it doesn't matter and in the future it
> would scale to larger networks?

I mean we haven't really tested it, I can't tell you exactly what our
current implementation can and can't do.

>> I've been designing and simulating a different approach to routing that
>> I'd like to implement instead
> Do you really mean routing approach? I'm a bit confused. I though that
> routing is being taken care of by OLSR, or maybe you mean peer discovery
> approach?
> Does it already have a name? Is it described in any online document? It
> sounds interesting.

I think the best possible mesh routing approach is going to break the
traditional OSI network model.
While it might be a better ideal to implement everything in the
kernel, that's going to limit our options for device support.
It's much simpler for us at the moment, to implement our ideas at the
application layer.
servald effectively has it's own complete network stack. It has its
own implementation of network addresses, a routing table, port
binding, ... All of which has the potential to give us much better
information about, and control of, the network.

I outlined a few ideas here;
https://plus.google.com/100061940421685613355/posts/XvdBm9Y8S6q
Some of which even survived in my simulator.

But I need to "till the soil" a bit first. The lower layers of the
network stack and local peer discovery still need a fair amount of
work before I'll start trying to build a better routing engine.

>> Another option we've been working on quite recently, is the ability to
>> co-exist on an olsr network...
> I initially thought that the plugin's purpose is so one won't have to
> install another deamon on his router in order for the first option you
> described to work, but only a plugin. Now I see that I probably got it
> wrong. What is it then?

Well we already have our daemon that can relay packets, it has its own
scheduling engine, packet queue's etc.
Trying to re-work what we have to fit into an olsr plugin doesn't feel
like the direction we want to move in.

> When you say "co-exist" you mean that the phones would use ad-hoc mode and
> be part of the OLSR network? What is the difference between that and using
> client mode regarding broadcast peer discovery? I'm not sure about that but
> wouldn't the broadcast reach only the direct neighbors? If that's the case,
> then wouldn't we still need servald on the routers for peer discovery? The
> only difference I see is that we won't need HNA4 for the phones to be able
> to ping each other, but the discovery would be the same, wouldn't it?

What I mean is, on a device running olsr and servald, you configure
servald to send mesh-wide messages via a small plugin in olsr. We
leverage olsr's efficient flooding mechanism to get those messages to
all nodes, even if most of them aren't running the servald daemon or
plugin.

We still configure servald to listen for incoming packets on the olsr
facing network interfaces, but completely disable servald's own mesh
routing discovery processes.

When one of these mesh-wide messages arrives via the plugin, we record
where it came from and can then send any replies as unicast responses
back across the mesh routed network. A small number of serval nodes
should be able to resolve each others phone numbers on a larger olsr
network, they should even be able to have a phone conversation without
flooding the voice packets unnecessarily.

All of that has been implemented now, but could definitely use more
testing. And we haven't thought about how to deploy it.

>> Plus we've added the capability to send unicast packets directly to any
>> IPv4
>> address for delivering packets without using our mesh route calculation
>> code.
> What is this about? Isn't it already working on regular mesh networks with
> OLSR and HNA4?

(It's a piece of the puzzle above)

[Jonathan Lahav]

I think I get it. Would it be right to conclude that the easiest way, which is still versatile enough, to currently add Serval support to a current mesh is to install servald on the routers? (I think I'd start without the plugin at first).

I would love to try and make it work. The obvious next steps would be to get a serval-dna build for OpenWrt and the configurations for it.

I saw talks about the need to package serval-dna on OpenWrt, but I also saw that a makefile for OpenWrt is already present on serval-dna's github page. Who wrote it? There should probably be someone working on it, and since this would be my first build on OpenWrt I would have preferred if someone already has experience with that.

What about the configurations? any guidance? any document?

And quite important, can I use the market version of Serval on the phones for this test?

I would report any results you are interested in to you if you like.

[Paul Gardner-Stephen]

Hello,

On Sun, Oct 7, 2012 at 9:14 PM, Jonathan Lahav <j.l...@gmail.com> wrote:
> I think I get it. Would it be right to conclude that the easiest way, which
> is still versatile enough, to currently add Serval support to a current mesh
> is to install servald on the routers? (I think I'd start without the plugin
> at first).

Yes, that would work.

> I would love to try and make it work. The obvious next steps would be to get
> a serval-dna build for OpenWrt and the configurations for it.

Correct.

> I saw talks about the need to package serval-dna on OpenWrt, but I also saw
> that a makefile for OpenWrt is already present on serval-dna's github page.
> Who wrote it? There should probably be someone working on it, and since this
> would be my first build on OpenWrt I would have preferred if someone already
> has experience with that.

Someone did say that they were going to work on openwrt packaging of
servald. I am not sure how far they have got. If that person is
lurking on the list, it would be great to hear of any progress.

> What about the configurations? any guidance? any document?

Configuration for servald? That is fairly easy:

Set the SERVALINSTANCE_PATH environment variable to the directory
where you want it to use.
Then in that directory create a file serval.conf with:
interface=+

Then to start servald, use:

servald start

> And quite important, can I use the market version of Serval on the phones
> for this test?

No, you would need a newer build. A reasonably recent one is in
http://developer.servalproject.org/files/perth

> I would report any results you are interested in to you if you like.

That would be great.

Paul.

[Jonathan Lahav]

I have started to work on packaging servald for OpenWrt. I have set up a build anvironment  and fixed the openwrt-makefile from the github page so it would be correctly parsed. The one on github is not parsable by the build system.

I don't know exactly how to build it yet so when trying to build the package there were errors (headers folder not configured correctly?) and I have to leave it for some time, so I'm posting the current status here if anyone wants to take a look and give some comments.

Are there special build instructions for serval-dna? I don't totally understand the makefile so I'm not sure yet how it is trying to be built.

[Paul Gardner-Stephen]

Hello,

On Thu, Oct 11, 2012 at 11:55 PM, Jonathan Lahav <j.l...@gmail.com> wrote:
> I have started to work on packaging servald for OpenWrt. I have set up a
> build anvironment and fixed the openwrt-makefile from the github page so it
> would be correctly parsed. The one on github is not parsable by the build
> system.

Ok. I will commit your new version to the serval-dna repository in an
openwrt branch.
I have, however, changed all mentions to "dna" to "servald" which is
the newer name for the program, since it now does much more than just
DNA lookups.

> I don't know exactly how to build it yet so when trying to build the package
> there were errors (headers folder not configured correctly?) and I have to
> leave it for some time, so I'm posting the current status here if anyone
> wants to take a look and give some comments.
>
> Are there special build instructions for serval-dna? I don't totally
> understand the makefile so I'm not sure yet how it is trying to be built.

The serval-dna build process for normal platforms is pretty much:
autoconf
configure
make

I did notice that in your openwrt-makefile you have the line that
tries to run make disabled. Was that on purpose?

Paul.

[Paul Gardner-Stephen]

Now tracking this issue and changes here:
https://github.com/servalproject/serval-dna/issues/26

On Fri, Oct 12, 2012 at 9:38 PM, Paul Gardner-Stephen

[Jonathan Lahav]

I used the makefile from serval-dna's page as a base. I didn't change any command yet, I only changed the syntax so it would be parsed correctly by the current version of the build system.

The line is commented out for some reason in the original file so I didn't chage it before sending it here. I'm trying to figure out how to build the package, until I manage to do it, I don't know what the right commands are.

[Jonathan Lahav]

I think I'll be back working on that tomorrow.

[Jonathan Lahav]

Ok. I have it.
Attached to this mail are two files, one is a build of servald which works on the latest beta of OpenWrt (named Attitude Adjustment), and the second is the Makefile and patch used to build this package. There are still no default config file and no init script for servald.

It was harder than I thought so I asked the OpenWrt community for help and someone named Jow was kind enough to sort it out. He said that building a separate version of naCl won't work so he changed to configurations of the build so servald would depend on the present version of naCl.

He built this version of the package and he changed it to serval-dna instead of servald, I guess it's because of the name of the repo. The binary is called servald.

I have reflashed two routers with AA (Attitude Adjustment, the beta of OpenWrt), and configured it again as described in the first message of this thread. Ping works between the phones, but even though I have servald installed and run as you described (the environment variable and config file), the two serval phones don't see each other.

Next step would be to debug it and see what's happening. How is it done?

[Jeremy Lakeman]

/me applauds.

Either run servald in foreground mode;
> servald start foreground

Or configure a log file via a SERVALD_LOG_FILE environment variable,
or log.file configuration option.

The configuration file itself is located at
${SERVALINSTANCE_PATH}/serval.conf. If SERVALINSTANCE_PATH isn't
defined, this defaults to /var/serval-node. Which is also where we
save our keystore.

We should probably write an init script and default config file, plus
a "make install" target...

The default logging options may give you enough clues. But you can
turn on ludicrous levels of debugging via the various debug.xxx
configuration options (listed in log.c). Note that config values are
only read on startup.

I'm guessing the routers don't have their interfaces configured
correctly, but that's just a guess.

If servald is listening and responding on the access point interface,
the phones should see the router in their peer list.

Are your routers immediate neighbours on the adhoc mesh side?

If you want to test our olsr plugin, you can find our patches here;
https://github.com/servalproject/olsr/tree/master/lib/relay

Though we haven't done any work to support bridging between serval
routed networks and olsr based networks yet. It's all or nothing at
the moment.

[Paul Gardner-Stephen]

Hello,

Great work!

We will, however, need to use our bundled version of NaCl, because it
is a hybrid between two different versions in the latest changes to
servald. In the meantime, we have rolled the NaCl build into our
regular makefile, thus resolving the problem at the source. More on
this in a moment.

Now, onto the issue where the phones:

First, the issue described above is critical, because otherwise the
phones and router servalds will be using incompatible crypto. I have
made (and attached) a first cut at what I think should work. Please
try it and let me know if it works. If it does, we will create a
serval-openwrt repository to keep it in, and track changes from there,
if not, show me the build errors and we will track it down.

Second, did you configure servald on the router to monitor the
relevant interfaces? The following command will do it:
servald config set interfaces=+
(this just puts interfaces=+ into serval.conf, which you can do
manually as part of your install if you wish).
Replace + with +interface if you only want it to chat on a single interface.
Note that Rhizome doesn't currently correctly limit its space usage,
which is likely to be an issue on an OpenWRT router with tiny storage.

Paul.

[Jeremy Lakeman]

On Wed, Oct 24, 2012 at 12:15 PM, Paul Gardner-Stephen
<pa...@servalproject.org> wrote:
> Hello,
>

> Great work!
>
> We will, however, need to use our bundled version of NaCl, because it
> is a hybrid between two different versions in the latest changes to
> servald. In the meantime, we have rolled the NaCl build into our
> regular makefile, thus resolving the problem at the source. More on
> this in a moment.
>
> Now, onto the issue where the phones:
>
> First, the issue described above is critical, because otherwise the
> phones and router servalds will be using incompatible crypto. I have
> made (and attached) a first cut at what I think should work. Please
> try it and let me know if it works. If it does, we will create a
> serval-openwrt repository to keep it in, and track changes from there,
> if not, show me the build errors and we will track it down.

We don't want to create a new repository that will quickly get out of
date. We need to be able to build for OpenWRT from our master branch,
until it's working we can create a new branch to track the changes you
two are making.

[Jonathan Lahav]

@Jeremy

> Either run servald in foreground mode;
> > servald start foreground

I'm a bit confused. Yesterday I ran servald on the routers, and checked with htop that servald is indeed running in the background. Today when I ran it like that, in foreground, I saw that it segfaults right away and quits. The output is attached in a text file. I don't know what happened, maybe yesterday I was dreaming or something, or maybe I changed something since then.

> I'm guessing the routers don't have their interfaces configured
> correctly, but that's just a guess.

Do you have any possible mistake on your mind that I may have done?

> Are your routers immediate neighbours on the adhoc mesh side?

Yes they are.

> If you want to test our olsr plugin...

I have decided to first try using the stand alone servald and only when it works I may try with the plugin. Do you suggest otherwise?

@Paul

> Please try it and let me know if it works.

Ok, I will. It may take some time.

> did you configure servald on the router to monitor the relevant interfaces?

Yes I did. I put it in the config file and exported the environment variable.

> Note that Rhizome doesn't currently correctly limit its space usage, which is likely to be an issue on an OpenWRT router with tiny storage.

As long as I don't use it, it won't take up space, right?

That segfault is funny. They don't come and go without recompilation in my experience so it's most likely that I somehow overlooked it yesterday, and that is why it didn't work.

I'm going to recompile it with your Makefile.

[Jonathan Lahav]

I don't have much time right now, but I thuoght I'd give it a go blindly and see what happens. I tried to build serval-dna using the files you composed, and it tries to link against an amd64 version of NaCl (the host system is amd64). The output is attached.

I think I'll look into it tommorow.

[Paul Gardner-Stephen]

Hello,

In the openwrt makefile, replace the PKG_SOURCE_VERSION line with the
following and try again:

PKG_SOURCE_VERSION:=be3b529504450680065008aab95e2ed3f1a5a3d5

With this change, the build process should not even try to link to a libnacl.a

As for the segfault, that's a bit interesting. If the network
interface configuration is different from last time, it could behave
differently (different interfaces up/down, different IP
addresses/netmasks).

If you have gdb on the router, run:

gdb `which servald`
set args start foreground
run

and then it should show you exactly where the segfault occurs. You
may need to tweak the servald build process to remove the -O2 and
replace it with -g to get line number level granularity in the stack
trace.

Paul.

[Jeremy Lakeman]

On Thu, Oct 25, 2012 at 12:03 AM, Jonathan Lahav <j.l...@gmail.com> wrote:
> @Jeremy
>
>> Either run servald in foreground mode;
>> > servald start foreground
>
> I'm a bit confused. Yesterday I ran servald on the routers, and checked with
> htop that servald is indeed running in the background. Today when I ran it
> like that, in foreground, I saw that it segfaults right away and quits. The
> output is attached in a text file. I don't know what happened, maybe
> yesterday I was dreaming or something, or maybe I changed something since
> then.
>

Odd, but if it's the "start foreground" process itself that is
crashing you wouldn't have hit that code before.

[Kim Hawtin]

On Thu, Oct 25, 2012 at 12:03 AM, Jonathan Lahav <j.l...@gmail.com> wrote:

>> servald start foreground
> I'm a bit confused. Yesterday I ran servald on the routers, and checked with
> htop that servald is indeed running in the background. Today when I ran it
> like that, in foreground, I saw that it segfaults right away and quits. The
> output is attached in a text file. I don't know what happened, maybe
> yesterday I was dreaming or something, or maybe I changed something since
> then.

INFO: rhizome_http.c:157:rhizome_http_server_start() RHIZOME HTTP
SERVER, START port=4110 fd=9
INFO: dna_helper.c:156:dna_helper_start() DNAHELPER none configured
ERROR: server.c:378:crash_handler() Caught SIGSEGV (11) Segmentation fault
INFO: performance_timing.c:178:dump_stack() overlay_interface_discover
INFO: performance_timing.c:178:dump_stack() parseCommandLine
ERROR: log.c:436:log_backtrace() mkstemp: Invalid argument [errno=22]
INFO: server.c:402:crash_handler() Re-sending signal 11 to self
Segmentation fault

> That segfault is funny. They don't come and go without recompilation in my
> experience so it's most likely that I somehow overlooked it yesterday, and
> that is why it didn't work.

What user is the process running as?

If it is not root, it might barf if trying to open a socket to listen
on below 1024 as a non-root users.

SIG 11's are not exactly common?
Does mkstemp() have permission to write to disk in the expected
location? Is there enough space?
Is mkstemp() expecting an argument with a null terminated string?

cheers,

Kim
--
"Art without engineering is dreaming; engineering without art is
calculating." --SKR

[Jonathan Lahav]

@Paul
> replace the PKG_SOURCE_VERSION line...
Yes. It was built successfully.

 
> If the network interface configuration is different from last time, it could behave differently

After a long time playing with it I found out that if the interfaces line is not properly configured, servald complains but runs fine (it may not do anything but it doesn't crash). If the line contains "interfaces=+" or "interfaces=+wlan0" servald instantly crashes with the error output I previously posted.

> If you have gdb on the router, run...
It doesn't show any more information than what it showed without gdb. Probably that's because missing debugging symbols as you said.

> You may need to tweak the servald build process to remove the -O2 and replace it with -g...
I struggled with the debug build since you sent this mail and I had yet to succeed. I was told to "make" the package like this:

make package/serval-dna/{clean,compile} V=99 TARGET_OPTIMIZATION="-ggdb3 -O0" STRIP="/bin/true"

The build process does change, but it fails to compile with these errors:

cp: cannot stat '/home/jonathan/OpenWrt/build/trunk/staging_dir/toolchain-mips_gcc-4.6-linaro_uClibc-0.9.33.2/lib/libuClibc-*.so': No such file or directory
cp: cannot stat '/home/jonathan/OpenWrt/build/trunk/staging_dir/toolchain-mips_gcc-4.6-linaro_uClibc-0.9.33.2/lib/libcrypt-*.so': No such file or directory
cp: cannot stat '/home/jonathan/OpenWrt/build/trunk/staging_dir/toolchain-mips_gcc-4.6-linaro_uClibc-0.9.33.2/lib/libm-*.so': No such file or directory
cp: cannot stat '/home/jonathan/OpenWrt/build/trunk/staging_dir/toolchain-mips_gcc-4.6-linaro_uClibc-0.9.33.2/lib/libpthread-*.so': No such file or directory

I tried to see whether it's trying to use a wrong toolchain, or maybe it tries to compile something dynamically where ususally it compiles it statically, or maybe some components are missing from the build root of OpenWrt, but I couldn't find the problem myself since I don't know enough about their build environment. I asked on their forum but no answer yet.

I think that the last version of our makefile is quite good. The package is being build successfully and the daemon runs, sort of. I think we shuold keep this version until we find out how to overcome the segfault.

BTW, I didn't tell you before but I'm part of the mobile networks security group of JCT (Dr. Ariel Stulman's group).

@Jeremy

> Odd, but if it's the "start foreground" process itself that is crashing you wouldn't have
> hit that code before.

It was probably different interfaces array in the config file. Foregroung or background does not matter.

@Kim
The process runs as root.

>Does mkstemp() have permission to write to disk in the expected
> location? Is there enough space?
> Is mkstemp() expecting an argument with a null terminated string?

These are interesting points, especially the "enough space" part, because this is a router and the space is small.
I don't know how to answer these questions. Maybe the others here would know what to check?


So, for now I don't have a debug build. If there is anything else I can check without the debug build I would gladly do it. Otherwise I'm a bit stuck for the moment. If anyone want instructions of how to set up a similar build root it is not that hard. Maybe this is the time to call the mysterious other guy who was supposed to work on the port? Maybe he knows the OpenWrt build system better?

[Jeremy Lakeman]

Quick look again at your earlier segfault.
The stack trace is generated from our IN() / OUT() instrumentation that we have manually added to some methods.

overlay_interface_discover calls one of the following;

#ifdef HAVE_IFADDRS_H
    if (no_route != 0)
      no_route = doifaddrs();
#endif

#ifdef SIOCGIFCONF
    if (no_route != 0)
      no_route = lsif();
#endif


#ifdef linux
    if (no_route != 0)
      no_route = scrapeProcNetRoute();
#endif

Which are all in lsif.c. Each of those calls overlay_interface_register in overlay_interface.c when they discover an interface. overlay_interface_register checks if the interface name is configured and tries to bind a socket. Since the segfault is only occurring when an interface matches, I'd start looking at overlay_interface_register and the methods in lsif to make sure these methods are dealing with memory pointers correctly on this platform.

If you can't get gdb to work, you could scatter the code in these methods with DEBUG("..."); or D; macro's, which will then write a log entry for each line of code that is executed before the segfault occurs.

[Paul Gardner-Stephen]

Hello,

I did wonder if you were at JCT ...

I have committed the openwrt makefile into the serval-dna repo, with the directory structure preserved under openwrt/

Let me know if the committed version still builds, or if I have messed something up.  Once that is settled, Jeremy's suggestions for tracking down the segfault are a good path of attack.

servald doesn't need to run as root, and therefore once you finish testing, it should be setup to  not run as root.

Paul.

[Jonathan Lahav]

Confirmed. The Makefile you uploaded works and servald builds fine.

[Paul Gardner-Stephen]

Super.  Now to find the segfault ... 

[Jonathan Lahav]

I  couldn't add debugging symbols yet, but I disabled the strip of the binary so I got one more line of information, it might help a bit:
Program received signal SIGSEGV, Segmentation fault.
0x0044d2c0 in doifaddrs ()

I didn't have the time to add the debug lines yet.

[Jeremy Lakeman]

Having a quick look at that function, and a man page for getifaddrs, we may need to first check that ifa->ifa_addr and ifa->ifa_netmask are not NULL.

[Jonathan Lahav]

Now that we know that it's in this function, should I add debug lines to more specific places, or maybe it's better if I wait for a new version to test?

[Jeremy Lakeman]

Sure, go ahead.

However, after reading;
http://www.kernel.org/doc/man-pages/online/pages/man3/getifaddrs.3.html

I think all you need to do is add;

          for (ifa = ifaddr; ifa != NULL; ifa = ifa->ifa_next) {
+               if (ifa->ifa_addr == NULL)
+                   continue;

[Jonathan Lahav]

I have made the change you suggested and the segfault is gone. Now I think we can officially declare that servald works on OpenWrt :)

I couldn't, however, see any change on the phones. I have them running now for some time in client mode as described before, and they see only themselves on the network.

The config file contains "interfaces=+" and I have exported SERVALINSTANCE_PATH.

Maybe I'm doing something wrong, but for now I couldn't make it work.

[Paul Gardner-Stephen]

Hi Jonathan,

Glad to hear the segfault has gone.

As for still nothing happening, that is a bit of a mystery.

As it happens it now looks like we will bet getting some OpenWRT hardware here (already on its way) and doing some work with that fairly soon, so we will hopefully be able to start looking into some of these things.  

But in the meantime, you might like to turn on some of ServalD's internal debugging to get some useful messages about whether it is seeing any packets and interfaces.  Look at log.c and conf.c for where debugFlagMask is, and you will find the debug flag parsing code.  This will give you an idea of which debug settings you want.  For example, the following will cause servald to log every received packet:

servald config set debug.rx 1

You probably then want to run it in foreground so you can see what it is showing:

servald start foreground

You probably also want to enable:

servald config set debug.interfaces 1

Give those a try, and see what you discover.

Paul.

[Jeremy Lakeman]

We've also recently discovered a bug in the handling of the interfaces config. Have you tried listing each interface explicitly?

[Jonathan Lahav]

I first tried with Jeremy's suggestion and indeed, it makes a difference. It still doesn't work, but the OpenWrt router reacts to the presence of another servald instance on the network.

I configured the interfaces array like that:

interfaces=+wlan0-1,+br-lan

wlan0-1 is the ad-hoc connection and br-lan is the bridged lan interface. It is bridged because the ethernet ports and the wireless are in the same subnet. This is the local network and the default configuration of OpenWrt.

When running "servald start foreground" serval shows us that it knows the correct IP addresses associated with the interfaces and then repeats a line of error which is caused by the br-lan interface where the phone is connected. For now I didn't connect the second router, only one router and one phone.

The output is as follows:

# servald start foreground

INFO:  log.c:87:open_logging()  No logfile configured -- logging to stderr

INFO:  commandline.c:560:app_server_start()  Foreground server process /usr/bin/servald

WARN:  rhizome_database.c:48:rhizome_set_datastore_path()  Rhizome datastore path not configured -- using instance path '/root'

INFO:  overlay.c:85:overlayServerMode()  Running in overlay mode.

INFO:  rhizome_http.c:157:rhizome_http_server_start()  RHIZOME HTTP SERVER, START port=4110 fd=7

INFO:  dna_helper.c:156:dna_helper_start()  DNAHELPER none configured

INFO:  overlay_interface.c:430:overlay_interface_init_socket()  Interface br-lan addr 192.168.1.255, is up

INFO:  overlay_interface.c:430:overlay_interface_init_socket()  Interface wlan0-1 addr 10.81.0.255, is up

INFO:  overlay_address.c:376:overlay_address_append_self()  ticks_per_full_address = 4

INFO:  overlay_address.c:442:find_subscr_buffer()  Asking for explanation of C0872DB1187302

INFO:  overlay_address.c:482:overlay_address_parse()  Could not resolve address, sender has not been set

INFO:  overlay_address.c:482:overlay_address_parse()  Could not resolve address, sender has not been set

DEBUG: overlay_address.c:552:send_please_explain()  Queued please explain

INFO:  overlay_route.c:189:get_node()  ADD OVERLAY NODE sid=C0872DB1187302991BD4C8655E0838BA3B05BFB58191ED302A069959E4F9F614

DEBUG: overlay_address.c:229:set_reachable()  C0872DB1187302991BD4C8655E0838BA3B05BFB58191ED302A069959E4F9F614 is now reachable via broadcast

ERROR: overlay_address.c:527:overlay_address_parse()  Unsupported abbreviation code 16

ERROR: overlay_address.c:527:overlay_address_parse()  Unsupported abbreviation code 16

ERROR: overlay_address.c:527:overlay_address_parse()  Unsupported abbreviation code 16

ERROR: overlay_address.c:527:overlay_address_parse()  Unsupported abbreviation code 16

ERROR: overlay_address.c:527:overlay_address_parse()  Unsupported abbreviation code 16

ERROR: overlay_address.c:527:overlay_address_parse()  Unsupported abbreviation code 16

ERROR: overlay_address.c:527:overlay_address_parse()  Unsupported abbreviation code 16

ERROR: overlay_address.c:527:overlay_address_parse()  Unsupported abbreviation code 16

DEBUG: overlay_address.c:220:set_reachable()  C0872DB1187302991BD4C8655E0838BA3B05BFB58191ED302A069959E4F9F614 is now reachable directly

INFO:  overlay_route.c:534:overlay_route_recalc_node_metrics()  PEER REACHABLE, sid=C0872DB1187302991BD4C8655E0838BA3B05BFB58191ED302A069959E4F9F614

ERROR: overlay_address.c:527:overlay_address_parse()  Unsupported abbreviation code 16

ERROR: overlay_address.c:527:overlay_address_parse()  Unsupported abbreviation code 16

ERROR: overlay_address.c:527:overlay_address_parse()  Unsupported abbreviation code 16

ERROR: overlay_address.c:527:overlay_address_parse()  Unsupported abbreviation code 16

and so on... I didn't understand the meaning of the error.

[Jonathan Lahav]

Here is the output in a text file.

[Jeremy Lakeman]

You'll need to have the same version of servald running on the phone and router.
Pull the latest code from serval-dna for the routers. If you don't want to build your own version of the phone apk, you can try this release build apk I prepared earlier;

http://developer.servalproject.org/files/Serval-0.90-alpha-20-g1fdba04.apk

[Jonathan Lahav]

I'm quite excited. All of the Serval devices see each other and I can make a phone call between the two phones!

Thank you for your support.

[Jonathan Lahav]

If you need more details about the setup I have here or anything else I would be happy to supply the information.

[Romana Challans]

Jonathan,

you know, a write up of your process for web site/wiki revamp(in progress) would be fantastic…

If you wouldn't mind? I know it is a big ask:)

For everyone else on list busily doing wonderful things with Serval Mesh - the same goes for all of you. It is something we struggle to do, as we are often so busy at the coalface developing!

Romana:)

Romana Challans
Co-founder, UX Lead, IEEE Liaison
http://servalproject.org
Phone : (+61) 0403865721 Skype : timelady

[Jonathan Lahav]

Yeah, no promises, but I think I can do that :)
What exactly are you interested in? The process included choosing an operating system for the routers, choosing the hardware, installing the firmware, configuring a little test mesh network, "porting" servald to OpenWrt, and making a call through the routers. Do you want a general description of the process? or a step by step guide?

[Jonathan Lahav]

Ah, yes, and what is the format of the document? Wiki page (what's the address)? doc, odt, google doc? etc.

[Andrew Bettison]

Hi Jonathan,

A blog post with all the gory details bragging about your success would be great!

If you prefer to just contribute technical comments on the build and integration process that aren't captured in the Makefile, a document aimed at developers, in Markdown format or plain text, would be tickety-boo.

Whatever you end up writing, if it contains most of the information necessary to reproduce your success, I will eventually re-work it into build instructions for OpenWRT, in line with the other build instructions I am writing, and it will end up in the doc directory of serval-dna.� Whatever you can manage will be gratefully received.

Thanks again, and well done!
Andrew

On 04/11/12 20:02, Jonathan Lahav wrote:

Ah, yes, and what is the format of the document? Wiki page (what's the address)? doc, odt, google doc? etc.

On Sun, Nov 4, 2012 at 11:31 AM, Jonathan Lahav <j.l...@gmail.com> wrote:

Yeah, no promises, but I think I can do that :)
What exactly are you interested in? The process included choosing an operating system for the routers, choosing the hardware, installing the firmware, configuring a little test mesh network, "porting" servald to OpenWrt, and making a call through the routers. Do you want a general description of the process? or a step by step guide?

On Sun, Nov 4, 2012 at 12:40 AM, Romana Challans <rom...@servalproject.org> wrote:

Jonathan,

you know, a write up of your process for web site/wiki revamp(in progress) would be fantastic�

If you wouldn't mind? I know it is a big ask:)

For everyone else on list busily doing wonderful things with Serval Mesh - the same goes for all of you. It is something we struggle to do, as we are often so busy at the coalface developing!

Romana:)

Romana Challans
Co-founder, UX Lead, IEEE Liaison
http://servalproject.org

Phone : (+61) 0403865721 Skype :�timelady

On 04/11/2012, at 3:14 AM, Jonathan Lahav <j.l...@gmail.com> wrote:

If you need more details about the setup I have here or anything else I would be happy to supply the information.

On Sat, Nov 3, 2012 at 6:39 PM, Jonathan Lahav <j.l...@gmail.com> wrote:

I'm quite excited. All of the Serval devices see each other and I can make a phone call between the two phones!

Thank you for your support.

oup/serval-project-developers?hl=en.

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

[Romana Challans]

Jonathan,

to agree with Andrew:

A blog post is a fantastic effort indeed

We have a Wiki (Dokuwiki, but standard Wiki formatting) which links off the Serval developer site: http://developer.servalproject.org/site/?page_id=687 will help you:)

Just let me know what access you want, fro whatever formats required and I will set it up.

And of course, as Andrew said, it will make its way into instructions - so write once, use often:)

Thanks again, Romana:)

On 05/11/2012, at 10:09 AM, Andrew Bettison <and...@servalproject.org> wrote:

Hi Jonathan,

A blog post with all the gory details bragging about your success would be great!

If you prefer to just contribute technical comments on the build and integration process that aren't captured in the Makefile, a document aimed at developers, in Markdown format or plain text, would be tickety-boo.

Whatever you end up writing, if it contains most of the information necessary to reproduce your success, I will eventually re-work it into build instructions for OpenWRT, in line with the other build instructions I am writing, and it will end up in the doc directory of serval-dna.  Whatever you can manage will be gratefully received.

Thanks again, and well done!
Andrew


On 04/11/12 20:02, Jonathan Lahav wrote:

Ah, yes, and what is the format of the document? Wiki page (what's the address)? doc, odt, google doc? etc.

On Sun, Nov 4, 2012 at 11:31 AM, Jonathan Lahav <j.l...@gmail.com> wrote:

Yeah, no promises, but I think I can do that :)
What exactly are you interested in? The process included choosing an operating system for the routers, choosing the hardware, installing the firmware, configuring a little test mesh network, "porting" servald to OpenWrt, and making a call through the routers. Do you want a general description of the process? or a step by step guide?

On Sun, Nov 4, 2012 at 12:40 AM, Romana Challans <rom...@servalproject.org> wrote:

Jonathan,

you know, a write up of your process for web site/wiki revamp(in progress) would be fantastic…

If you wouldn't mind? I know it is a big ask:)

For everyone else on list busily doing wonderful things with Serval Mesh - the same goes for all of you. It is something we struggle to do, as we are often so busy at the coalface developing!

Romana:)

Romana Challans
Co-founder, UX Lead, IEEE Liaison
http://servalproject.org

Phone : (+61) 0403865721 Skype : timelady

On 04/11/2012, at 3:14 AM, Jonathan Lahav <j.l...@gmail.com> wrote:

If you need more details about the setup I have here or anything else I would be happy to supply the information.

On Sat, Nov 3, 2012 at 6:39 PM, Jonathan Lahav <j.l...@gmail.com> wrote:

I'm quite excited. All of the Serval devices see each other and I can make a phone call between the two phones!

Thank you for your support.

oup/serval-project-developers?hl=en.

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

--
You received this message because you are subscribed to the Google Groups "Serval Project Developers" group.
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.

|_       Romana Challans
(_)\_  http://timelady.com/blog/ 

[Romana Challans]

Jonathan,

to agree with Andrew:

A blog post is a fantastic effort indeed

We have a Wiki (Dokuwiki, but standard Wiki formatting) which links off the Serval developer site: http://developer.servalproject.org/site/?page_id=687 will help you:)

Just let me know what access you want, fro whatever formats required and I will set it up.

And of course, as Andrew said, it will make its way into instructions - so write once, use often:)

forgot to add: Any format you like, I will translate as needed - perhaps send to me directly.

Thanks again, Romana:)

[Wayne Abroue]

Hi All

I have been following this with half a eye, but I am now very excited, Congrats Jonathan.

I for one would be very interested to give this a go on my existing VT mesh.

Wayne

Kransmesh

[Jonathan Lahav]

There is still one subject which needs some attention. In the beginning we talked about two opstions of how to connect the phones through the mesh. One was what we did, which is installing servald on the routers. The second was using the serval plugin for OLSR to leverage the OLSR flooding bechanism for advertising nodes on the mesh.

Currently the limitations of our setup are:
1) servald must run on every node in the mesh. This is problematic because usually one does not have control over a whole mesh network.
2) As far as I understand, every device on the whole mesh must have a unique IP address on the mesh, and they all have to be directly accessible to each other (in our example we used HNA4 for that).

I assume that using the OLSR plugin has advantages over using servald on each node. Let's sum up the advantages. I'll list whatever I think which might be incorrect because I don't know the plugin, please correct me if anything is wrong.
1) servald must run *only* on nodes directly connected to phones (the plugin will run there also). All other nodes can run only the plugin. That way phones which are connected to "servald routers" would be able to talk with each others, while the "plugin routers" would only connect between the "servald routers". Phones connected to "plugin routers" would not be able to call or recieve calls. Is that correct?
2) About each device having a unique IP address, I think it is still the case and the plugin does not matter here.
3) The mesh wouldn't be as flooded with servald messages as while using servald on each router.

Are there more advantages? Are there disadvantages?

What does running the plugin on our OpenWrt devices involve? Is there any more porting necessary? recompilation?

[Jeremy Lakeman]

On Mon, Nov 5, 2012 at 8:08 PM, Jonathan Lahav <j.l...@gmail.com> wrote:
> There is still one subject which needs some attention. In the beginning we
> talked about two opstions of how to connect the phones through the mesh. One
> was what we did, which is installing servald on the routers. The second was
> using the serval plugin for OLSR to leverage the OLSR flooding bechanism for
> advertising nodes on the mesh.
>
> Currently the limitations of our setup are:
> 1) servald must run on every node in the mesh. This is problematic because
> usually one does not have control over a whole mesh network.
> 2) As far as I understand, every device on the whole mesh must have a unique
> IP address on the mesh, and they all have to be directly accessible to each
> other (in our example we used HNA4 for that).
>
> I assume that using the OLSR plugin has advantages over using servald on
> each node. Let's sum up the advantages. I'll list whatever I think which
> might be incorrect because I don't know the plugin, please correct me if
> anything is wrong.

> 1) servald must run *only* on nodes directly connected to phones (the plugin
> will run there also). All other nodes can run only the plugin.

The plugin only needs to run on nodes with servald, olsr's message
flooding has default behaviour for unknown message types that ensures
the messages will reach all nodes running the plugin within the TTL
hop count limit.

But at the moment, every phone would need to be running olsr and be a
first class citizen on the mesh as well. We haven't built any process
for discovery of remote phones across an olsr network.

> That way
> phones which are connected to "servald routers" would be able to talk with
> each others, while the "plugin routers" would only connect between the
> "servald routers". Phones connected to "plugin routers" would not be able to
> call or recieve calls. Is that correct?

Right. If the routers aren't running servald, the phones would need
some other way to discover phones attached to other parts of the
network.

> 2) About each device having a unique IP address, I think it is still the
> case and the plugin does not matter here.

The olsr side of the network must have unique addresses or it wouldn't
work. But for serval's purposes each AP could be on the same private
subnet, the servald routers shouldn't have any difficulty relaying
messages in this case.

> 3) The mesh wouldn't be as flooded with servald messages as while using
> servald on each router.

At the moment, the only messages that would be sent via the plugin are
phone number lookup requests. Responses and phone calls should be sent
as unicast IP traffic directly between the two servald end points.

> Are there more advantages? Are there disadvantages?
>
> What does running the plugin on our OpenWrt devices involve? Is there any
> more porting necessary? recompilation?

We haven't tried to build our plugin on openwrt. It currently exists
as the last 4 commits in this repository;
https://github.com/servalproject/olsr

Re-applying these changes to any recent version of olsr should be
reasonably simple. Using the plugin is not very well tested or
documented yet. It's a proof of concept, but I'm not really convinced
that it's the right way forward.

If we move forward with the olsr plugin solution, we could use olsr
messages to discover all of the other servald nodes. Then use this
information to swap routing information about all of the known serval
phones. But we'd still need servald to run on each router with phones
attached.

In some ways, Serval Mesh phones communicating over an existing olsr
mesh network will be very similar to the problems we'd face
communicating over the internet.

With servald running on every node in the network, we can take over
responsibility for discovering routing paths. But attached to a
network with traditional IP routing, we don't really need to solve the
routing side of the problem at all.

What we need is a directory service that we can use to resolve phone
numbers, public keys, and currently routeable IP addresses. In some
ways this would be similar to DNS lookups.

I've implemented a very basic directory service, that can run in
memory on a single node running servald. It's (barely) good enough for
a proof of concept at this point. Basically, every phone pings the
directory service every now and again so that the server can remember
their IP address and other details. Since this solution also currently
requires all serval traffic to pass through the directory server, it
wont scale. And I probably need to change the message format to
prevent a server from sending fake responses.

If you'd like to try it out, build the directory_service target from
our makefile. The directory service can then be configured to run on a
server;
>servald config set dna.helper.executable "[path]/directory_service"
Then restart servald. You'll also need to know the server's IP address
and public key;
>servald id self

On each phone, you can then set the config for the service, via an adb shell;
>servald config set directory.service [key]
And tell the phone where to contact the directory service;
>servald config set [key].address [IP address]
>servald config set [key].interface [phone's wifi interface]

I realise that setting configuration this way is not going to cut it
for end users. And setting this configuration on a phone isn't well
tested, you'll probably need to remove the directory.service config
again for normal operation.

We need to build some kind of discovery process, application
preferences activity or simple configuration file import. And we need
to discover the correct interface to use automatically, either by
trial and error or by reading the routing table for a match.

And we need to detect when a direct connection between phones can be
made so that we don't overload the directory server. But what I've
built is a start at least.

[Jonathan Lahav]

Thank you for the detailed answer. I will work through it and compare the different possibilities, it would take me some time.

[Alex P-B]

Heyah, This is all very interesting!
Could you give me any pointers towards compiling servald for openwrt?

I am in the process of setting extending my OLSR network - It would be very handy to route phone calls through it.
the wifi in handsets cant really seem to cut it around here (lots of trees and hills)
Solar powered openwrt nodes should do fine though.

[Paul Gardner-Stephen]

Hello,

As it happens, this is something that people have been working on
lately, and I will be working on in a more systematic manner in the
next couple of weeks.

See: https://github.com/servalproject/serval-dna/issues/26

We are also looking at using hybrid radio solutions with Dragroves so
that we can plug UHF radio modules in and use them as low-bandwidth
but longer-range mesh links.

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/-/ZV1X4tR-JMcJ.

[Bryce Lynch]

On Wed, Nov 21, 2012 at 10:36 AM, Alex P-B <cho...@gmail.com> wrote:

Solar powered openwrt nodes should do fine though.

Can you wait until we get v0.3a of Byzantium Linux up?  We've just finished Commotion compatibility, including OLSR support.

--
The Doctor [412/724/301/703] [ZS (MED)]
https://drwho.virtadpt.net/
"I am everywhere."

[Jonathan Lahav]

@Alex
Building servald now is just like building any other OpenWrt package. I used the OpenWrt documentations and the Makefile which can be found in serval-dna's github repo.

Some guidance:
Here is the Makefile: https://github.com/servalproject/serval-dna/tree/master/openwrt
The documentations I used to create the build environment: http://wiki.openwrt.org/about/toolchain

If you follow the documentation you will build the entire OpenWrt firmware. When you are almost done, add servald's Makefile to where all the other Makefiles are, and run menuconfig. Menuconfig's index will be updated and servald would be added as an option. Just check it, and make again, then servald will be built.

Notes:

• It should be possible to build the package without building OpenWrt using their SDK. I tried it and failed, but you may have more luck. Here it is: http://wiki.openwrt.org/doc/howto/obtain.firmware.sdk
  
• Building OpenWrt takes a long time. Be prepared.

I'm attaching a binary version of servald which should be compatible with Attitude Adjustment and the version of Serval for android Jeremy posted here before. You can give it a shot and see if it runs before trying to build it yourself.

--
You received this message because you are subscribed to the Google Groups "Serval Project Developers" group.

[Alex P-B]

@Jonathan
Thanks! This is exactly the information I was after. The binary installs and starts fine. I'll revert the phones back to the corresponding alpha and give things ago.


@Bryce
Sounds like a good release, I'll have have a look at what's coming up.

@Paul
thanks for the info - longer range wireless would be fantastic - I'll have a read up on dragrove.

Seems I lost my last message, sorry if this is a double post.

To unsubscribe from this group, send email to serval-project-developers+unsub...@googlegroups.com.

[Chozabu]

@Jonathan
Thanks! This is exactly the information I was after. I'll give the binary a go first and let you know the results.


@Bryce
That's awesome news! though I don't see exactly why you are asking me to wait for though?

@Paul
thanks for the info - longer range wireless would be fantastic - I'll have a read up on dragrove.

-Alex "Chozabu" P-B

My site

Want to make a Wheelz level?

[Wayne Abroue]

Hi All

Glad to hear of the progress on servald. Having played with it quite a
while back I was just wondering if the cell limitation has been solved
in Android.

I run a villagetelco mesh in adhoc mode, with cell identifier with all
nodes running layer2 batman-adv. . If I can only get the phones to
connect to it in adhoc mode I would have village wide comms using
serval.

The limitation a year ago was the adhoc drivers not been able to specify cell.

Wayne

[Bryce Lynch]

On Fri, Nov 23, 2012 at 10:45 AM, Chozabu <cho...@gmail.com> wrote:

@Bryce
That's awesome news! though I don't see exactly why you are asking me to wait for though?

Truthfully, sleep deprivation. <sheepish grin>

I'd clicked send scant hours before asking myself why I'd sent that message.

[Paul Gardner-Stephen]

Hello,

That limitation still exists.

What you could do us run a VAP on your mesh potatoes, and use the
Android phones in client mode to connect to that. We are implementing
exactly this on the Dragrove/Draginos, which use the same atheros
chipset as the MP, so you should just be able to copy our config. See
recent commits in https://github.com/servalproject/dragino for what to
change -- but be aware that this is a work in progress, and not yet
finished.

Paul.

> Wayne

[Wayne Abroue]

On Wed, Nov 28, 2012 at 2:28 AM, Paul Gardner-Stephen
<pa...@servalproject.org> wrote:
> Hello,
>
> On Tue, Nov 27, 2012 at 8:23 PM, Wayne Abroue <ple...@gmail.com> wrote:
>> Hi All
>>
>> Glad to hear of the progress on servald. Having played with it quite a
>> while back I was just wondering if the cell limitation has been solved
>> in Android.
>>
>> I run a villagetelco mesh in adhoc mode, with cell identifier with all
>> nodes running layer2 batman-adv. . If I can only get the phones to
>> connect to it in adhoc mode I would have village wide comms using
>> serval.
>>
>> The limitation a year ago was the adhoc drivers not been able to specify cell.
>
> That limitation still exists.
>
> What you could do us run a VAP on your mesh potatoes, and use the
> Android phones in client mode to connect to that. We are implementing
> exactly this on the Dragrove/Draginos, which use the same atheros
> chipset as the MP, so you should just be able to copy our config. See
> recent commits in https://github.com/servalproject/dragino for what to
> change -- but be aware that this is a work in progress, and not yet
> finished.
>
> Paul.
>
>> Wayne

Hi Paul

I nearly thought I had missed something important. Yes, I already run
the nodes with AP VAP's so this is good already.

So basically I must only run servald on the AP interfaces of all
nodes, or must it run on the mesh interface also? Sorry I am not that
clear on the workings of serval.

My AP interfaces are all connected L2 , for security I have blocked
all arping and only allow certified dhcp clients. Would I have to
specifically allow the phone IP's?


Wayne

[Jeremy Lakeman]

I can't say I'd recommend running servald on a layer2 batman-adv
network. It's far too chatty at the moment as it assumes all network
interfaces have adhoc-like behaviour. eg broadcast packets are as
cheap to send as unicasts, and they'll only reach your immediate
network neighbours.

We need to add a "wired network" flag to our interface definition.
This would control the number of broadcast discovery packets we send
and swap to sending unicast packets to all peers.

Not very complicated changes, but I don't know if/when we'll find the
time to make them.

[Wayne Abroue]

On Wed, Nov 28, 2012 at 7:08 AM, Jeremy Lakeman
<jer...@servalproject.org> wrote:
> I can't say I'd recommend running servald on a layer2 batman-adv
> network. It's far too chatty at the moment as it assumes all network
> interfaces have adhoc-like behaviour. eg broadcast packets are as
> cheap to send as unicasts, and they'll only reach your immediate
> network neighbours.
>
> We need to add a "wired network" flag to our interface definition.
> This would control the number of broadcast discovery packets we send
> and swap to sending unicast packets to all peers.
>
> Not very complicated changes, but I don't know if/when we'll find the
> time to make them.
>

Thanks Jeremy

Good to know, I'll go back to lurking for a while then.

Wayne