[B.A.T.M.A.N.] Problem with B.A.T.M.A.N. 0.3.1 rv1206 (compatibility version 5)

[B.A.T.M.A.N.] Problem with B.A.T.M.A.N. 0.3.1 rv1206 (compatibility version 5)

[Max]

[-- Attachment #1: Type: text/plain, Size: 822 bytes --]

Good afternoon to everybody!

I have to deal with 2 big problems occurred when I run batmand 0.3.1 rv 1206
in meshboxs equipped with OpenWrt Kamikaze 8.09
I detect the following problems:
1) B.A.T.M.A.N. daemon only works whether launched in debug mode. I'm sure
about this because I'm monitoring the network with a packet sniffer.
2) When launched in debug mode (using the command batmand -d 3 ath0 &), the
daemon starts to generate OGMs and to fill up its routing tables in a
correct way. The problem occurs when I tries to ping an host in the network
because the routing process uses the default routing table (that has not
been modified by the batman daemon) and it is not aware on the correct
batman routing tables.

Does someone know how to solve these problems?
Thank you in advance.

Best regards,
Massimo Reineri

[-- Attachment #2: Type: text/html, Size: 876 bytes --]

Re: [B.A.T.M.A.N.] Problem with B.A.T.M.A.N. 0.3.1 rv1206 (compatibility version 5)

[Marek Lindner]

Hi,

> 1) B.A.T.M.A.N. daemon only works whether launched in debug mode. I'm sure
> about this because I'm monitoring the network with a packet sniffer.

how sure are you about this ? So far nobody could observe this bug. 
Batman checks whether the interface is up & running before sending packets. If 
the interface is not up batman will sit there and wait until the interface 
becomes available. May be thats what you saw ?


> 2) When launched in debug mode (using the command batmand -d 3 ath0 &), the
> daemon starts to generate OGMs and to fill up its routing tables in a
> correct way. The problem occurs when I tries to ping an host in the network
> because the routing process uses the default routing table (that has not
> been modified by the batman daemon) and it is not aware on the correct
> batman routing tables.

All packets go through the whole Linux routing mechanism not only the default 
table. Batman installs routing rules to jump to the batman routing tables 
(see: http://www.open-mesh.net/wiki/RoutingVodoo).
Please provide some more details regarding your setup, e.g. do you try to ping 
another batman node ? Do you try to ping a node that uses the same IP address 
space but has no batman running ?

Regards,
Marek

Re: [B.A.T.M.A.N.] Problem with B.A.T.M.A.N. 0.3.1 rv1206 (compatibility version 5)

[Marco Tozzini]

----- Original Message Follows -----
From: Max <rey.web.mail@gmail.com>

> Good afternoon to everybody!
> 
> I have to deal with 2 big problems occurred when I run
> batmand 0.3.1 rv 1206 in meshboxs equipped with OpenWrt
> Kamikaze 8.09 I detect the following problems:
> 1) B.A.T.M.A.N. daemon only works whether launched in
> debug mode. I'm sure about this because I'm monitoring the
> network with a packet sniffer

...

> 
> Best regards,
> Massimo Reineri
> 

Hi Massimo,

Please don't blame me for this, but ...
did you start batman this way:
batman -d 1 ath0
I my case batman remain in foreground and if you send ^C it
stops

I used
batmand ath0
and then
batman -c -d 1
to see what happens to daemon in background

Ciao
Marco

Re: [B.A.T.M.A.N.] Problem with B.A.T.M.A.N. 0.3.1 rv1206 (compatibility version 5)

[Max]

[-- Attachment #1: Type: text/plain, Size: 1739 bytes --]

Thank you Marek and Marco for your suggestions.

I have solved the following problem:
>2) When launched in debug mode (using the command batmand -d 3 ath0 &), the
> daemon starts to generate OGMs and to fill up its routing tables in a
> correct way. The problem occurs when I tries to ping an host in the
network
> because the routing process uses the default routing table (that has not
> been modified by the batman daemon) and it is not aware on the correct
> batman routing tables.

Now I'm able to ping every originator in the network. The problem is derived
from some iptables filters that stop the ping. Executing the following
command I remove the filters solving the problem:

iptables --flush
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

As concern the other problem it's still present.
In my meshboxes, BATMAN sends OGMs only when it's launched in debug mode
using the command
"batmand -d 3 ath0 &". In this case, I see OGMs travelling in the network
using Wireshark and the command "ip route ls table 66" lists all reachable
batman nodes.

When I launch the daemon in normal mode, using the command "batmand ath0",
no error is displayed but no OGMs is observed to be travelling in the
network using Wireshark. The only message displayed is:
"Interface activated: ath0
Using interface ath0 with address 10.0.0.1 and broadcast address
10.255.255.255"

Also the command "ip route ls table 66" does not produce any output.

And finally another question...
Is it normal to observe 3 different processes named batmand using the shell
command ps?


Thank you in advance!

Best regards,
Massimo

[-- Attachment #2: Type: text/html, Size: 1973 bytes --]

Re: [B.A.T.M.A.N.] Problem with B.A.T.M.A.N. 0.3.1 rv1206 (compatibility version 5)

[Marek Lindner]

On Thursday 19 March 2009 21:38:14 Max wrote:
> Now I'm able to ping every originator in the network. The problem is
> derived from some iptables filters that stop the ping. Executing the
> following command I remove the filters solving the problem:

Glad to hear that.


> When I launch the daemon in normal mode, using the command "batmand ath0",
> no error is displayed but no OGMs is observed to be travelling in the
> network using Wireshark. The only message displayed is:
> "Interface activated: ath0
> Using interface ath0 with address 10.0.0.1 and broadcast address
> 10.255.255.255"

Could you please run 
batmand -c -d 4
after you started the daemon ? This command will make batman start a "client" 
that connects to the running daemon that outputs error messages. Feel free to 
share these messages with us.  :-)


> And finally another question...
> Is it normal to observe 3 different processes named batmand using the shell
> command ps?

Batman uses threads to parallelize certain tasks (basically 2 threads). Older 
kernel versions / different thread implementations don't offer "real" threads 
but use processes instead. Usually, they create a control process that syncs 
the other "threads" (processes in this case), hence 2 + 1 processes in "ps".

Regards,
Marek

Re: [B.A.T.M.A.N.] Problem with B.A.T.M.A.N. 0.3.1 rv1206 (compatibility version 5)

[Max]

[-- Attachment #1: Type: text/plain, Size: 519 bytes --]

Hi Marek,
thank you for your support!

I have launched the batmand daemon with the command "batmand ath0" and it
displays the following message (as usual):

root@MeshBoxA:~# batmand ath0
Interface activated: ath0
Using interface ath0 with address 10.0.0.1 and broadcast address
10.255.255.255

Now, I type the command "batmand -c -d 4":

root@MeshBoxA:~# batmand -c -d 4

But it does not display anything and it does not return.
Moreover, no OGM packets are observed to be travelling using Wireshark.

regards,
Massimo

[-- Attachment #2: Type: text/html, Size: 605 bytes --]

Re: [B.A.T.M.A.N.] Problem with B.A.T.M.A.N. 0.3.1 rv1206 (compatibility version 5)

[Marek Lindner]

On Friday 20 March 2009 21:03:24 Max wrote:
> root@MeshBoxA:~# batmand -c -d 4
>
> But it does not display anything and it does not return.
> Moreover, no OGM packets are observed to be travelling using Wireshark.

That sounds interesting - we are coming closer to the root of the problem.

Did you compile batman yourself ? Are you using a selfbuilt OpenWRT ? What 
kind of hardware is a "meshbox" ?

Regards,
Marek

Re: [B.A.T.M.A.N.] Problem with B.A.T.M.A.N. 0.3.1 rv1206 (compatibility version 5)

[Max]

Hi Marek!
In my lab, meshbox is a miniPC with motherboard Lex System MV823A with
512 MByte of DDR SDRAM, a
Realtek 10/100 Mbps wired network card, 1 GByte of Flash Memory and 2
wireless network cards Atheros
complaint with the IEEE 802.11 a/b/g standards.

In such a meshbox, I installed OpenWRT Kamikaze 8.09.
In order to do that, I downloaded the OpenWRT trunk and all the
available packages from the OpenWRT repository.
Then, I built the image selecting all the interesting packages; among
these packages, in the network section,
I selected batmand (B.A.T.M.A.N. 3 routing daemon).
By the way, I did not compile batman by myself but it was directly
integrated in the Kamikaze image.

I hope to solve quikly this problem in order to start as soon as
possible some performance tests in the network.

I'm very grateful to you for your important suggestions and timely support.

Best regards,
Massimo

Re: [B.A.T.M.A.N.] Problem with B.A.T.M.A.N. 0.3.1 rv1206 (compatibility version 5)

[Marek Lindner]

Hi,

> In such a meshbox, I installed OpenWRT Kamikaze 8.09.
> In order to do that, I downloaded the OpenWRT trunk and all the
> available packages from the OpenWRT repository.
> Then, I built the image selecting all the interesting packages; among
> these packages, in the network section,
> I selected batmand (B.A.T.M.A.N. 3 routing daemon).
> By the way, I did not compile batman by myself but it was directly
> integrated in the Kamikaze image.

I downloaded the OpenWRT trunk and compiled the i386 image before loading it 
into a qemu environment. I can confirm that batman does nothing if started 
without a debug level. It seems the main thread is not doing anything. 
Interestingly, if I compile & run batman on my debian machine it runs without 
problems. I guess OpenWRT uses some different libs / compile time options / etc 
that provoke that problem.

As a short term workaround I suggest you start batman with a debug level and 
redirect the output:
batmand -d 3 wlan0 > /dev/null 2>&1

I will try to debug this during the coming days but can't promise anything as 
I'm looking for the needle in the haystack.

Regards,
Marek

Re: [B.A.T.M.A.N.] Problem with B.A.T.M.A.N. 0.3.1 rv1206 (compatibility version 5)

[Sven Eckelmann]

[-- Attachment #1: Type: text/plain, Size: 1243 bytes --]

On Monday 23 March 2009 18:13:32 Marek Lindner wrote:
> I downloaded the OpenWRT trunk and compiled the i386 image before loading
> it into a qemu environment. I can confirm that batman does nothing if
> started without a debug level. It seems the main thread is not doing
> anything. Interestingly, if I compile & run batman on my debian machine it
> runs without problems. I guess OpenWRT uses some different libs / compile
> time options / etc that provoke that problem.
Seems to a different behaviour when doing a fork+pthreads_create... somehow. 
Try to remove the fork and the setgid from posix/init.c:my_daemon and compile 
it again (against uclib of course). You should notice that it works without 
any problems.
If you do a static build against a current glibc on i386 (2.7 here) it works 
as expected.
So I would guess a uClibc specific behaviour when calling pthread_create after 
a fork. The thread (unix_listen) itself runs without any problems but the main 
thread seems to be blocked at
 pthread_create( &unix_if.listen_thread_id, NULL, &unix_listen, NULL );
in posix/init.c:apply_init_args.

Please read http://www.mail-archive.com/uclibc@uclibc.org/msg00357.html for 
some hints.

Best regards,
	Sven

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [B.A.T.M.A.N.] Problem with B.A.T.M.A.N. 0.3.1 rv1206 (compatibility version 5)

[P. Mazart]

Hello,

Am Montag, 23. März 2009 schrieb Marek Lindner:
> I guess OpenWRT uses some different libs / compile
> time options / etc that provoke that problem.

I hope I understood this thread right…

I run OpenWRT whiterussion RC6 with libpthread 0.9.27-1 and it runs ok with 
batmand_0.3.1-current_mipsel-wr-elf-32-lsb-dynamic.ipk (0.3.1 rv1203)

Best Regards
P.M.

Re: [B.A.T.M.A.N.] Problem with B.A.T.M.A.N. 0.3.1 rv1206 (compatibility version 5)

[Sven Eckelmann]

[-- Attachment #1: Type: text/plain, Size: 2503 bytes --]

On Monday 23 March 2009 23:05:34 Sven Eckelmann wrote:
> On Monday 23 March 2009 18:13:32 Marek Lindner wrote:
> > I downloaded the OpenWRT trunk and compiled the i386 image before loading
> > it into a qemu environment. I can confirm that batman does nothing if
> > started without a debug level. It seems the main thread is not doing
> > anything. Interestingly, if I compile & run batman on my debian machine
> > it runs without problems. I guess OpenWRT uses some different libs /
> > compile time options / etc that provoke that problem.
>
> Seems to a different behaviour when doing a fork+pthreads_create...
> somehow. Try to remove the fork and the setgid from posix/init.c:my_daemon
> and compile it again (against uclib of course). You should notice that it
> works without any problems.
> If you do a static build against a current glibc on i386 (2.7 here) it
> works as expected.
> So I would guess a uClibc specific behaviour when calling pthread_create
> after a fork. The thread (unix_listen) itself runs without any problems but
> the main thread seems to be blocked at
>  pthread_create( &unix_if.listen_thread_id, NULL, &unix_listen, NULL );
> in posix/init.c:apply_init_args.

Forgot to add my minimal testcase:

 #include <unistd.h>
 #include <stdio.h>
 #include <pthread.h>
 
 void* dummy_thread(void* unused)
 { 
 	printf("from thread\n");
 
 	return NULL;
 }
 
 int main(void)
 {
 	pthread_t t;
 
 	if (fork() == 0) {
		printf("from child\n");
 		pthread_create(&t, NULL, &dummy_thread, NULL);
 		printf("after create\n");
 	}
 	return 0;
 }

The output should be (last two lines can be swapped):
 from child
 from thread
 after create

I used the x86 toolchain from the current openwrt trunk to compile it.
 openwrt/build_dir/toolchain-i386_gcc-4.1.2_uClibc-0.9.29/gcc-4.1.2-final/gcc/gcc-cross fork_thread.c -static -lpthread -o fork_thread

The result was a stopping main thread at pthread_create. I did the same test
with 0.9.28.2 and 0.9.30.1
 Advanced configuration options  --->
  Toolchain Options  --->
   uClibc Version

0.9.28 worked without any problems and 0.9.30.1 without nptl showed the same
problem - the nptl version doesn't compile at the moment. So changing the
uclibc is a possible solution. Otherwise ask the openwrt developers to take
a look at the problem. Please add this example (or a similar one) and the
expected results + a list of uclibc versions which worked.

Best regards,
	Sven

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [B.A.T.M.A.N.] Problem with B.A.T.M.A.N. 0.3.1 rv1206 (compatibility version 5)

[Marek Lindner]

On Wednesday 25 March 2009 03:17:47 Sven Eckelmann wrote:
> 0.9.28 worked without any problems and 0.9.30.1 without nptl showed the
> same problem - the nptl version doesn't compile at the moment. So changing
> the uclibc is a possible solution. Otherwise ask the openwrt developers to
> take a look at the problem. Please add this example (or a similar one) and
> the expected results + a list of uclibc versions which worked.

Thanks a lot for sharing your test results. I suspected ulibc to be the 
culprit as we had trouble with fork() and pthread_create() before. Actually, 
thats the reason why batman has its own daemonize function. It seems they 
still have trouble with it.

I'll try to get in touch with some OpenWRT developers to see what can be done.

Regards,
Marek

[B.A.T.M.A.N.] [PATCH] Don't detach batmand to background by default

[Sven Eckelmann]

The current behaviour of batmand is to detach to background by default
when no debug mode is activated. This is problematic on different libc
implementations which don't support to use pthreads after the usage of
fork without calling exec* first. They will allow batmand to fork to the
background, but freeze the batmand main thread after calling
pthread_create.
This patch changes this behaviour to "not fork to the background unless
said otherwise". The user can now use the option -B to explicit say
that he knows what he is doing and that his system supports this
combinations of fork+pthreads_create. All other systems can use
 batmand tap1 > /dev/null 2>&1 &
or
 start-stop-daemon --start --background --exec /usr/sbin/batmand -- wlan0
to do the same.

Signed-off-by: Sven Eckelmann <sven.eckelmann@gmx.de>
---
 batman/batman.c      |    2 ++
 batman/man/batmand.8 |    3 +++
 batman/posix/init.c  |   11 ++++++++---
 3 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/batman/batman.c b/batman/batman.c
index fe9f66e..c8f9c88 100644
--- a/batman/batman.c
+++ b/batman/batman.c
@@ -136,6 +136,7 @@ void usage(void)
 	fprintf( stderr, "       -a add announced network(s)\n" );
 	fprintf( stderr, "       -A delete announced network(s)\n" );
 	fprintf( stderr, "       -b run connection in batch mode\n" );
+	fprintf( stderr, "       -B run daemon in the background\n" );
 	fprintf( stderr, "       -c connect via unix socket\n" );
 	fprintf( stderr, "       -d debug level\n" );
 	fprintf( stderr, "       -g gateway class\n" );
@@ -161,6 +162,7 @@ void verbose_usage(void)
 	fprintf( stderr, "       -A delete announced network(s)\n" );
 	fprintf( stderr, "          network/netmask is expected\n" );
 	fprintf( stderr, "       -b run connection in batch mode\n" );
+	fprintf( stderr, "       -B detach and run as daemon in the background\n" );
 	fprintf( stderr, "       -c connect to running batmand via unix socket\n" );
 	fprintf( stderr, "       -d debug level\n" );
 	fprintf( stderr, "          default:         0 -> debug disabled\n" );
diff --git a/batman/man/batmand.8 b/batman/man/batmand.8
index dced39b..fc897dc 100644
--- a/batman/man/batmand.8
+++ b/batman/man/batmand.8
@@ -40,6 +40,9 @@ Delete networks to the daemons list of available connections to another network(
 .B \-b run debug connection in batch mode
 The debug information are updated after a period of time by default, so if you use "-b" it will execute once and then stop. This option is useful for script integration of the debug output and is only available in client mode together with "-d 1" or "-d 2".
 .TP
+.B \-B run daemon in the background
+When this option is specified, batmand will detach and become a daemon. This is only possible if your libc supports the usage of threads in combination with fork.
+.TP
 .B \-c connect via unix socket
 Use this option to switch to client mode. Deploy it without any arguments to get the current configuration even if changed at runtime.
 .TP
diff --git a/batman/posix/init.c b/batman/posix/init.c
index 4848a4b..d87f8ce 100644
--- a/batman/posix/init.c
+++ b/batman/posix/init.c
@@ -229,7 +229,7 @@ void apply_init_args( int argc, char *argv[] ) {
 	struct debug_level_info *debug_level_info;
 	struct list_head *list_pos, *list_pos_tmp;
 	uint8_t found_args = 1, batch_mode = 0, info_output = 0, was_hna = 0;
-	int8_t res;
+	int8_t res, detach = 0;
 
 	int32_t optchar, option_index, recv_buff_len, bytes_written, download_speed = 0, upload_speed = 0;
 	char str1[16], str2[16], *slash_ptr, *unix_buff, *buff_ptr, *cr_ptr;
@@ -253,7 +253,7 @@ void apply_init_args( int argc, char *argv[] ) {
 	if ( strstr( SOURCE_VERSION, "-" ) != NULL )
 		printf( "WARNING: You are using the unstable batman branch. If you are interested in *using* batman get the latest stable release !\n" );
 
-	while ( ( optchar = getopt_long( argc, argv, "a:A:bcd:hHio:g:p:r:s:vV", long_options, &option_index ) ) != -1 ) {
+	while ( ( optchar = getopt_long( argc, argv, "a:A:bBcd:hHio:g:p:r:s:vV", long_options, &option_index ) ) != -1 ) {
 
 		switch ( optchar ) {
 
@@ -278,6 +278,11 @@ void apply_init_args( int argc, char *argv[] ) {
 				found_args++;
 				break;
 
+			case 'B':
+				detach++;
+				found_args++;
+				break;
+
 			case 'c':
 				unix_client++;
 				found_args++;
@@ -647,7 +652,7 @@ void apply_init_args( int argc, char *argv[] ) {
 		/* daemonize */
 		if (debug_level == 0) {
 
-			if (my_daemon() < 0) {
+			if (detach && my_daemon() < 0) {
 
 				printf("Error - can't fork to background: %s\n", strerror(errno));
 				restore_defaults();
-- 
1.6.2.1

Re: [B.A.T.M.A.N.] [PATCH] Don't detach batmand to background by default

[Marek Lindner]

On Thursday 26 March 2009 20:59:26 Sven Eckelmann wrote:
> This patch changes this behaviour to "not fork to the background unless
> said otherwise". The user can now use the option -B to explicit say
> that he knows what he is doing and that his system supports this
> combinations of fork+pthreads_create. All other systems can use
>  batmand tap1 > /dev/null 2>&1 &


Hi Sven,

thanks a lot for addressing this issue by sending your patch. Although I'm not 
too happy about the chosen approach. Changing the default behaviour and adding 
a new command line option seems not to be the best solution. Do you think we 
can put this exec call into batman itself and thus hiding this ulibc thread 
disaster ?

Regards,
Marek

Re: [B.A.T.M.A.N.] [PATCH] Don't detach batmand to background by default

[Sven Eckelmann]

[-- Attachment #1: Type: text/plain, Size: 2068 bytes --]

On Tuesday 31 March 2009 20:26:08 Marek Lindner wrote:
> thanks a lot for addressing this issue by sending your patch. Although I'm
> not too happy about the chosen approach. Changing the default behaviour and
> adding a new command line option seems not to be the best solution. Do you
> think we can put this exec call into batman itself and thus hiding this
> ulibc thread disaster ?
First thing is that you have to add a option to disable the fork to the 
background. Otherwise all batmand execs will again fork to the background and 
exec again a batmand. Then there is the issue of finding the right executable 
to execute. The argv[0] approach isn't ideal since there must not be any 
connections to the real executable. Take for example this small snipped:

 #include <unistd.h>
 int main()
 {
 	char* const argv[] = {"/fake", NULL};
 	execv("/bin/sh", argv);
 	return 0;
 }

Make a `echo $0` in a normal shell and one in the shell started by this 
program. An approach to start a program again is to use start the program 
again over /proc/self/exe. This can fail due to different reasons. First one 
is that there is no proc filesystem mounted. Second one is that there is that 
the file which was used to start the program was moved to another location (or 
deleted). Maybe there are other ways I don't know, but please don't suggest 
fexecve since this is even less POSIX and takes a similar approach, but 
involves more 'guessing' since you first have to open a file to get the 
correct fd.
Under (Free)BSD you will have to find a similar approach since it doesn't have 
/proc/self/exe unless you mounted linprocfs.

As you can see the real problem is the association between the process and 
it's executable you need to execute batmand again. I will post a proof-of-
concept patch to show this approach. Be prepared that it eats your pets and 
converts wine into water. I cannot test the patches again the current openwrt 
trunk since https://svn.openwrt.org/openwrt/trunk is broken at the moment.

Regards,
	Sven

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[B.A.T.M.A.N.] [PATCH 1/2] Add parameter to disable fork to background

[Sven Eckelmann]

The current behaviour of batmand is to detach to background by default
when no debug mode is activated. This is problematic on different libc
implementations which don't support to use pthreads after the usage of
fork without calling exec* first. They will allow batmand to fork to the
background, but freeze the batmand main thread after calling
pthread_create.
This patch adds a parameter to change the behaviour to not fork to the
background. It can be used to fork to the background from the outside
and workaround the fork+thread issue by setting this parameter.
Example usage is to call batmand using
 batmand -D tap1 > /dev/null 2>&1 &
or
 start-stop-daemon --start --background --exec /usr/sbin/batmand -- -D wlan0

Signed-off-by: Sven Eckelmann <sven.eckelmann@gmx.de>
---
 batman/batman.c      |    2 ++
 batman/man/batmand.8 |    3 +++
 batman/posix/init.c  |   11 ++++++++---
 3 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/batman/batman.c b/batman/batman.c
index 73214ac..d05833e 100644
--- a/batman/batman.c
+++ b/batman/batman.c
@@ -138,6 +138,7 @@ void usage(void)
 	fprintf( stderr, "       -b run connection in batch mode\n" );
 	fprintf( stderr, "       -c connect via unix socket\n" );
 	fprintf( stderr, "       -d debug level\n" );
+	fprintf( stderr, "       -B don't run daemon in the background\n" );
 	fprintf( stderr, "       -g gateway class\n" );
 	fprintf( stderr, "       -h this help\n" );
 	fprintf( stderr, "       -H verbose help\n" );
@@ -168,6 +169,7 @@ void verbose_usage(void)
 	fprintf( stderr, "                           2 -> list gateways\n" );
 	fprintf( stderr, "                           3 -> observe batman\n" );
 	fprintf( stderr, "                           4 -> observe batman (very verbose)\n\n" );
+	fprintf( stderr, "       -D not detach and doesn't run as daemon in the background\n" );
 
 	if ( debug_level_max == 5  )
 		fprintf( stderr, "                           5 -> memory debug / cpu usage\n\n" );
diff --git a/batman/man/batmand.8 b/batman/man/batmand.8
index 263b4c3..07f6300 100644
--- a/batman/man/batmand.8
+++ b/batman/man/batmand.8
@@ -61,6 +61,9 @@ allowed values: 1 -> list neighbors
 Note that debug level 5 can be disabled at compile time.
 .RE
 .TP
+.B \-D don't run daemon in the background
+When this option is specified, batmand will not detach and does not become a daemon.
+.TP
 .B \-g gateway class
 The gateway class is used to tell other nodes in the network your available internet bandwidth. Just enter any number (optionally followed by "kbit" or "mbit") and the daemon will guess your appropriate gateway class. Use "/" to seperate the down- and upload rates. You can omit the upload rate and batmand will assume an upload of download / 5.
 .RS 17
diff --git a/batman/posix/init.c b/batman/posix/init.c
index b0ef71d..bd10438 100644
--- a/batman/posix/init.c
+++ b/batman/posix/init.c
@@ -229,7 +229,7 @@ void apply_init_args( int argc, char *argv[] ) {
 	struct debug_level_info *debug_level_info;
 	struct list_head *list_pos, *list_pos_tmp;
 	uint8_t found_args = 1, batch_mode = 0, info_output = 0, was_hna = 0;
-	int8_t res;
+	int8_t res, no_detach = 0;
 
 	int32_t optchar, option_index, recv_buff_len, bytes_written, download_speed = 0, upload_speed = 0;
 	char str1[16], str2[16], *slash_ptr, *unix_buff, *buff_ptr, *cr_ptr;
@@ -253,7 +253,7 @@ void apply_init_args( int argc, char *argv[] ) {
 	if ( strstr( SOURCE_VERSION, "-" ) != NULL )
 		printf( "WARNING: You are using the unstable batman branch. If you are interested in *using* batman get the latest stable release !\n" );
 
-	while ( ( optchar = getopt_long( argc, argv, "a:A:bcd:hHio:g:p:r:s:vV", long_options, &option_index ) ) != -1 ) {
+	while ( ( optchar = getopt_long( argc, argv, "a:A:bcd:DhHio:g:p:r:s:vV", long_options, &option_index ) ) != -1 ) {
 
 		switch ( optchar ) {
 
@@ -306,6 +306,11 @@ void apply_init_args( int argc, char *argv[] ) {
 				found_args += ((*((char*)( optarg - 1)) == optchar) ? 1 : 2);
 				break;
 
+			case 'D':
+				no_detach++;
+				found_args++;
+				break;
+
 			case 'g':
 
 				if ( ( slash_ptr = strchr( optarg, '/' ) ) != NULL )
@@ -647,7 +652,7 @@ void apply_init_args( int argc, char *argv[] ) {
 		/* daemonize */
 		if (debug_level == 0) {
 
-			if (my_daemon() < 0) {
+			if (no_detach == 0 && my_daemon() < 0) {
 
 				printf("Error - can't fork to background: %s\n", strerror(errno));
 				restore_defaults();
-- 
1.6.2.1

[B.A.T.M.A.N.] [PATCH 2/2] Sanitise batmand process by reexecuting it

[Sven Eckelmann]

uclibc >=0.9.29 doesn't support threads after the call of fork in
linuxthreads mode without calling exec* first. We can now try to call
the binary again with execv to sanitise the current process and tell him
that he should not try to get into the daemon mode so we don't recursive
call batmand again.
This can fail when no linux procfs is mounted on /proc or /proc/self/exe
is a dangling symlink. In this case we continue without any changes.

Signed-off-by: Sven Eckelmann <sven.eckelmann@gmx.de>
---
 batman/posix/init.c |   28 ++++++++++++++++++++++++++--
 1 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/batman/posix/init.c b/batman/posix/init.c
index bd10438..5dbfe17 100644
--- a/batman/posix/init.c
+++ b/batman/posix/init.c
@@ -46,7 +46,28 @@ int8_t stop;
 
 
 
-static int my_daemon(void) {
+static void re_execute(int argc, char *argv[])
+{
+	char ** new_argv = NULL;
+	char* no_detach_flag = "-D";
+	int i;
+
+	new_argv = debugMalloc( sizeof(char *const) * (argc + 2), 5005 );
+	for (i = 0; i < argc; i++ ) {
+		new_argv[i] = argv[i];
+	}
+	new_argv[argc] = no_detach_flag;
+	new_argv[argc + 1] = NULL;
+
+
+	execv("/proc/self/exe", new_argv);
+
+	/* execv can fail due to different reasons
+	   so we must be able to continue anyway */
+	debugFree(new_argv, 5005);
+}
+
+static int my_daemon(int argc, char *argv[]) {
 
 	int fd;
 
@@ -83,6 +104,9 @@ static int my_daemon(void) {
 
 	}
 
+	/* Try to restart batmand in daemon mode to be sure that it is sanitised */
+	re_execute(argc, argv);
+
 	return 0;
 
 }
@@ -652,7 +676,7 @@ void apply_init_args( int argc, char *argv[] ) {
 		/* daemonize */
 		if (debug_level == 0) {
 
-			if (no_detach == 0 && my_daemon() < 0) {
+			if (no_detach == 0 && my_daemon(argc, argv) < 0) {
 
 				printf("Error - can't fork to background: %s\n", strerror(errno));
 				restore_defaults();
-- 
1.6.2.1

[B.A.T.M.A.N.] [PATCHv2 2/2] Sanitise batmand process by reexecuting it

[Sven Eckelmann]

uclibc >=0.9.29 doesn't support threads after the call of fork in
linuxthreads mode without calling exec* first. We can now try to call
the binary again with execv to sanitise the current process and tell him
that he should not try to get into the daemon mode so we don't recursive
call batmand again.
This can fail when no linux procfs is mounted on /proc or /proc/self/exe
is a dangling symlink. In this case we continue without any changes.

Signed-off-by: Sven Eckelmann <sven.eckelmann@gmx.de>
---
 batman/posix/init.c |   97 ++++++++++++++++++++++++++++++++------------------
 1 files changed, 62 insertions(+), 35 deletions(-)

diff --git a/batman/posix/init.c b/batman/posix/init.c
index bd10438..648ebd7 100644
--- a/batman/posix/init.c
+++ b/batman/posix/init.c
@@ -46,7 +46,28 @@ int8_t stop;
 
 
 
-static int my_daemon(void) {
+static void reexecute(int argc, char *argv[])
+{
+	char ** new_argv = NULL;
+	char* no_detach_flag = "-D";
+	int i;
+
+	new_argv = debugMalloc( sizeof(char *const) * (argc + 2), 5005 );
+	for (i = 0; i < argc; i++ ) {
+		new_argv[i] = argv[i];
+	}
+	new_argv[argc] = no_detach_flag;
+	new_argv[argc + 1] = NULL;
+
+
+	execv("/proc/self/exe", new_argv);
+
+	/* execv can fail due to different reasons
+	   so we must be able to continue here */
+	debugFree(new_argv, 5005);
+}
+
+static int my_daemon(int argc, char *argv[]) {
 
 	int fd;
 
@@ -83,6 +104,9 @@ static int my_daemon(void) {
 
 	}
 
+	/* Try to restart batmand in daemon mode to be sure that it is sanitised */
+	reexecute(argc, argv);
+
 	return 0;
 
 }
@@ -228,7 +252,7 @@ void apply_init_args( int argc, char *argv[] ) {
 	struct hna_node *hna_node;
 	struct debug_level_info *debug_level_info;
 	struct list_head *list_pos, *list_pos_tmp;
-	uint8_t found_args = 1, batch_mode = 0, info_output = 0, was_hna = 0;
+	uint8_t found_args = 1, batch_mode = 0, info_output = 0, was_hna = 0, i;
 	int8_t res, no_detach = 0;
 
 	int32_t optchar, option_index, recv_buff_len, bytes_written, download_speed = 0, upload_speed = 0;
@@ -572,14 +596,44 @@ void apply_init_args( int argc, char *argv[] ) {
 		if ( flush_routes_rules(1) < 0 )
 			exit(EXIT_FAILURE);
 
+
+		for (i = found_args; i < argc; i++) {
+			if (argv[i][0] == '-') {
+				fprintf(stderr, "%s: invalid option -- %s\n", argv[0], argv[i]);
+				usage();
+				exit(EXIT_FAILURE);
+			}
+		}
+
+		/* daemonize */
+		if (debug_level == 0) {
+
+			if (no_detach == 0 && my_daemon(argc, argv) < 0) {
+
+				printf("Error - can't fork to background: %s\n", strerror(errno));
+				restore_defaults();
+				exit(EXIT_FAILURE);
+
+			}
+
+			openlog("batmand", LOG_PID, LOG_DAEMON);
+
+		} else {
+
+			printf("B.A.T.M.A.N. %s%s (compatibility version %i)\n", SOURCE_VERSION, (strlen(REVISION_VERSION) > 3 ? REVISION_VERSION : ""), COMPAT_VERSION);
+
+			debug_clients.clients_num[ debug_level - 1 ]++;
+			debug_level_info = debugMalloc( sizeof(struct debug_level_info), 205 );
+			INIT_LIST_HEAD( &debug_level_info->list );
+			debug_level_info->fd = 2;
+			list_add( &debug_level_info->list, (struct list_head_first *)debug_clients.fd_list[debug_level - 1] );
+
+		}
+
+		log_facility_active = 1;
+
 		while (argc > found_args) {
 
-			if (argv[found_args][0] == '-') {
-				fprintf(stderr, "%s: invalid option -- %s\n", argv[0], argv[found_args]);
-				usage();
-				exit(EXIT_FAILURE);
-			}
-
 			batman_if = debugMalloc( sizeof(struct batman_if), 206 );
 			memset( batman_if, 0, sizeof(struct batman_if) );
 			INIT_LIST_HEAD( &batman_if->list );
@@ -649,33 +703,6 @@ void apply_init_args( int argc, char *argv[] ) {
 
 		}
 
-		/* daemonize */
-		if (debug_level == 0) {
-
-			if (no_detach == 0 && my_daemon() < 0) {
-
-				printf("Error - can't fork to background: %s\n", strerror(errno));
-				restore_defaults();
-				exit(EXIT_FAILURE);
-
-			}
-
-			openlog("batmand", LOG_PID, LOG_DAEMON);
-
-		} else {
-
-			printf("B.A.T.M.A.N. %s%s (compatibility version %i)\n", SOURCE_VERSION, (strlen(REVISION_VERSION) > 3 ? REVISION_VERSION : ""), COMPAT_VERSION);
-
-			debug_clients.clients_num[ debug_level - 1 ]++;
-			debug_level_info = debugMalloc( sizeof(struct debug_level_info), 205 );
-			INIT_LIST_HEAD( &debug_level_info->list );
-			debug_level_info->fd = 2;
-			list_add( &debug_level_info->list, (struct list_head_first *)debug_clients.fd_list[debug_level - 1] );
-
-		}
-
-		log_facility_active = 1;
-
 		pthread_create( &unix_if.listen_thread_id, NULL, &unix_listen, NULL );
 
 		/* add rule for hna networks */
-- 
1.6.2.1

Re: [B.A.T.M.A.N.] Problem with B.A.T.M.A.N. 0.3.1 rv1206 (compatibility version 5)

[Marek Lindner]

Hi,


> 2) When launched in debug mode (using the command batmand -d 3 ath0 &), the
> daemon starts to generate OGMs and to fill up its routing tables in a
> correct way. The problem occurs when I tries to ping an host in the network
> because the routing process uses the default routing table (that has not
> been modified by the batman daemon) and it is not aware on the correct
> batman routing tables.

Nico from OpenWRT opened a ticket which you can find here:
https://dev.openwrt.org/ticket/4915

He also applied a ulibc fix for this bug today:
https://dev.openwrt.org/changeset/15193

If you checkout the latest 8.09 OpenWRT branch batman should be working as 
expected. Could you verify this ?

Regards,
Marek