Re: Batman-adv nodes do not recieve OGMs

On Wednesday 01 April 2009 03:13:01 Kai Timmer wrote:
> Actually i already tried that and it didn't change anything. And when
> that is really the problem, why is the module than even starting to
> send messages?

Athough the interface is down batman still runs internally to trigger events, 
timeouts, link quality updates, etc. That does not mean the packets go out 
although the logs might indicate packets were sent. You can easily verify 
whether the packets leave the system or not by using the battools or tcpdump. 

I agree with Simon: If you experience connection problems first make sure that 
ping & friends run smoothly. 

Regards,
Marek

Re: [PATCH] Don't detach batmand to background by default

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 

[PATCH 1/2] Add parameter to disable fork to background

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@...>
---
 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
 <at>  <at>  -138,6 +138,7  <at>  <at>  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" );

[PATCH 2/2] Sanitise batmand process by reexecuting it

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@...>
---
 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
 <at>  <at>  -46,7 +46,28  <at>  <at>  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++ ) {

[PATCHv2 2/2] Sanitise batmand process by reexecuting it

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@...>
---
 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
 <at>  <at>  -46,7 +46,28  <at>  <at>  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++ ) {

[PATCH] Don't access random memory after forwarding broadcast

B.A.T.M.A.N. advanced iterates over every known interface when receiving
data and tries to forward as much as possible data from the same
interface as possible using a while-loop inside the outer loop.
When it receives a broadcast ethernet frame which needs to be forwarded
again it will try to send it to every known interface again. This loop
is inside the first one and used the same pos variable as the outer
loop. After the inner loop has finished it will point to a memory
location which is not part of the interface list, but the while loop
starts again and tries to access this memory region without knowing what
it is and to what it belongs. This could lead to a kernel oops or any
kind of other unspecified behavior of the kernel.
The inner loop should use a seperate position variable to iterate over
all interfaces for the broadcast.

Signed-off-by: Sven Eckelmann <sven.eckelmann@...>
---
 batman-adv-kernelland/routing.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/batman-adv-kernelland/routing.c b/batman-adv-kernelland/routing.c
index 73e786e..89bfb3f 100644
--- a/batman-adv-kernelland/routing.c
+++ b/batman-adv-kernelland/routing.c
 <at>  <at>  -567,7 +567,7  <at>  <at>  int receive_raw_packet(struct socket *raw_sock, unsigned char *packet_buff, int

 int packet_recv_thread(void *data)
 {
-	struct batman_if *batman_if;
+	struct batman_if *batman_if, *batman_bcastif;
 	struct ethhdr *ethhdr;

Re: [PATCH] Don't access random memory after forwarding broadcast

On Thursday 02 April 2009 22:23:12 Sven Eckelmann wrote:
> B.A.T.M.A.N. advanced iterates over every known interface when receiving
> data and tries to forward as much as possible data from the same
> interface as possible using a while-loop inside the outer loop.
> When it receives a broadcast ethernet frame which needs to be forwarded
> again it will try to send it to every known interface again. This loop
> is inside the first one and used the same pos variable as the outer
> loop. After the inner loop has finished it will point to a memory
> location which is not part of the interface list, but the while loop
> starts again and tries to access this memory region without knowing what
> it is and to what it belongs. This could lead to a kernel oops or any
> kind of other unspecified behavior of the kernel.
> The inner loop should use a seperate position variable to iterate over
> all interfaces for the broadcast.

Great catch !

Regards,
Marek

bmxd debug level 8

Hi Axel, Hi bmxd users
as my network grows, bmxd -cd8 gets kind of... not so useful (as the
output doesn't fit on one page anymore). for my part, i'm mostly interested,
in what bmxd thinks about the neighbours. so, what do you guys think about
splitting it into two parts?

cheers

  --Jan 

_______________________________________________
B.A.T.M.A.N mailing list
B.A.T.M.A.N@...
https://lists.open-mesh.net/mm/listinfo/b.a.t.m.a.n

Trouble with SSH in L2 batman network

Hi

I have configured a Layer 2 mesh (Using batman kernel module) on
Routerboard 433.  These are boards equipped with 2 interfaces.  I have
configured/created a virtual interface on every physical interface.
So for E.g. my routerboard 1 (RB1) has ath0 (Phy interface - Adhoc
mode), ath1 (Virtual interface - Master mode), ath2 (Phy interface -
Adhoc mode) and ath3 (Virtual interface in Master mode).

My set up has 2 routerboards - one is wired and the other is wireless.
Thus RB1 has (ath0, ath1, ath2, ath3 and eth0)
RB2 has (ath0, ath1, ath2, ath3)

The proc is as follows on both RB1 and RB2

root <at> open-mesh:~# cat /proc/net/batman-adv/interfaces
ath0 ath2

I have created a bridge between all interfaces.
The bridge config on RB1 is:

root <at> open-mesh:~# brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.000c422fbfe4       no                  eth0
                                                                         ath1
                                                                         ath3
                                                                         bat0

The bridge config on RB2 is:
root <at> open-mesh:~# brctl show

Re: Trouble with SSH in L2 batman network

Sorry was not clear in the configuration

= = AP to AP wireless link
^ ^ AP to client wireless link
Server1 and RB1 on wired n/w

  My configuration is like this:

 -Server 1 --|
                |
                |-----(RB1) =   =   (RB2)
                        ^                 ^
                        ^                 ^
                        ^                 ^
                      C1              C2

> On Tue, Apr 7, 2009 at 5:18 PM, Gargi Purohit <gaargie@...> wrote:
>> Hi
>>
>> I have configured a Layer 2 mesh (Using batman kernel module) on
>> Routerboard 433.  These are boards equipped with 2 interfaces.  I have
>> configured/created a virtual interface on every physical interface.
>> So for E.g. my routerboard 1 (RB1) has ath0 (Phy interface - Adhoc
>> mode), ath1 (Virtual interface - Master mode), ath2 (Phy interface -
>> Adhoc mode) and ath3 (Virtual interface in Master mode).
>>
>> My set up has 2 routerboards - one is wired and the other is wireless.
>> Thus RB1 has (ath0, ath1, ath2, ath3 and eth0)
>> RB2 has (ath0, ath1, ath2, ath3)
>>