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
Hi,
- 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 ?
- 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
Thank you Marek and Marco for your suggestions.
I have solved the following problem:
- 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
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
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
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
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
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
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
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.
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
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
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();
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
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
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();
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();
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 */
Hi,
- 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
b.a.t.m.a.n@lists.open-mesh.org
-
Marek Lindner -
Max -
P. Mazart -
Sven Eckelmann