[B.A.T.M.A.N.] problems running batman rev350

[B.A.T.M.A.N.] problems running batman rev350

[Dragan Noveski]

hi list,
i am new here and just trying to use batman rev350 compiled on 
2.6.21.1-rt3 kernel on ibm-thinkpad-R50e. the rt-patch (for low-latency 
audio work) comes from:

http://people.redhat.com/mingo/realtime-preempt/

i am using a atmel-wlan adapter and the atmel driver from:

git-clone http://honk.sigxcpu.org/git/at76c503a.git/


the driver runs pretty stable, if i use olsrd to join the network here, i use following script to start the protocol:

 #!/bin/sh
    iwconfig eth2 mode ad-hoc essid olsr.freifunk.net channel 10 ap 02:CA:FF:EE
    ifconfig eth2 104.130.30.9
    ifconfig eth2 up
    olsrd


.........

except of some timeouts, which are pretty rarely, that runs good.

i am starting batman with:

#!/bin/bash
    iwconfig eth2 mode ad-hoc essid olsr.freifunk.net channel 10
    ifconfig eth2 105.130.30.9
    ifconfig eth2 up
    sleep 1
    batmand -d 1 -p 105.131.41.5 -r 1 eth2


and

#!/bin/bash
batmand -c -d 2

in another terminal.

when batman starts, the 'batmand -c' script shows, that i am connected 
to another gateway, but not to preferred one:

     Gateway              Router (#/128) 
=> 105.192.99.62      105.130.30.1 ( 3), gw_class 10 - 6 MBit, 
reliability: 0 
   105.192.99.61      105.130.30.1 ( 1), gw_class  7 - 2 MBit, 
reliability: 0 
   105.131.83.5       105.130.30.1 ( 1), gw_class 11 - >6 MBit, 
reliability: 0 
   105.131.41.5       105.130.30.1 ( 2), gw_class 11 - >6 MBit, 
reliability: 0 
   105.192.99.103     105.130.30.1 ( 3), gw_class  7 - 2 MBit, 
reliability: 0 
   105.192.99.192     105.130.30.1 ( 2), gw_class 10 - 6 MBit, 
reliability: 0

...........

this always is a number 105.192.99.....(.62, .103, .192).
this condition than stays for 2 or 3 up to 10 minutes, and in that time 
i cannot even ping the 105.130.30.1 which is the next  point here.

after some minutes, the connection changes, so that 'batmand -c' shows 
that i am connected to 105.131.41.5 and i am able to ping 141.1.1.1.
unfortunately, after some minutes (or even shorter), the batman script 
stops and the terminal is at the prompt again. there is no segfault, 
using 'ulimit -c unlimited' will not produce a core-dump. i suppose that 
this is not a driver bug, cause looking at this moment at 'dmesg', i can 
see that the driver is loaded using the 02:ca:ff:ee:ba:by - if i stop 
batmand and start olsrd, i will be connected to the internet as expected.

i am really not aware of what else information i could provide to you, 
in order to make batmand running stable here, but if you have any idea, 
please let me know!

cheers,
doc

Re: [B.A.T.M.A.N.] problems running batman rev350

[Axel Neumann]

Hey Dragan,

>
>  #!/bin/sh
>     iwconfig eth2 mode ad-hoc essid olsr.freifunk.net channel 10 ap
> 02:CA:FF:EE ifconfig eth2 104.130.30.9

(just to be shure) this should be 02:CA:FF:EE:BA:BE 

..
>
> i am starting batman with:
>
> #!/bin/bash
>     iwconfig eth2 mode ad-hoc essid olsr.freifunk.net channel 10
>     ifconfig eth2 105.130.30.9
>     ifconfig eth2 up
>     sleep 1
>     batmand -d 1 -p 105.131.41.5 -r 1 eth2
can  you start batmand in background with: 
batmand -r 1 -p 105.131.41.5  eth2
instead and tell if the problem continues. This command instantly returns your 
prompt but a:
ps -aux | grep batmand
should show the running main-daemon in the background.
Also please check that there are no predefined host routes for the 105.0.0.0/8 
network before you start batmand and after it stopped. Meaning a:
route -n | grep ^105 
berfore and after the daemon is running should only show:
105.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 eth2
While batmand is running it should of course show routing entries for all 
other known batman nodes but if such host routes are still there after the 
daemon stopped it is a definitive sign for an uncorect termination of teh 
daemon.

>
> #!/bin/bash
> batmand -c -d 2
>
> in another terminal.

It should of course always be possible to access the debug output from the 
running batmand main-daemon by launching a batmand-client with
batmand -c -d <1-4>
or in batch mode (providing just a single outputpage and returns to the 
prompt) with:
batmand -c -d <1-4> -b
However, it would be interesting to know if the crash is related to existence 
of a batmand-client connecting to the main daemon. For example for 
batmand-0.2.0-rc2-rv350 (and before) debug level 4:
batmand -c -d 4
is known to cause the batmand to crash after a short time and it might be 
possible that this problems also occur with other debug-levels.
Try 
batmand -c -d 1
and 
batmand -c -d 2
instead.

ciao,
axel


>
> when batman starts, the 'batmand -c' script shows, that i am connected
> to another gateway, but not to preferred one:
>
>      Gateway              Router (#/128)
> => 105.192.99.62      105.130.30.1 ( 3), gw_class 10 - 6 MBit,
> reliability: 0
>    105.192.99.61      105.130.30.1 ( 1), gw_class  7 - 2 MBit,
> reliability: 0
>    105.131.83.5       105.130.30.1 ( 1), gw_class 11 - >6 MBit,
> reliability: 0
>    105.131.41.5       105.130.30.1 ( 2), gw_class 11 - >6 MBit,
> reliability: 0
>    105.192.99.103     105.130.30.1 ( 3), gw_class  7 - 2 MBit,
> reliability: 0
>    105.192.99.192     105.130.30.1 ( 2), gw_class 10 - 6 MBit,
> reliability: 0
>
> ...........
>
> this always is a number 105.192.99.....(.62, .103, .192).
> this condition than stays for 2 or 3 up to 10 minutes, and in that time
> i cannot even ping the 105.130.30.1 which is the next  point here.
>
> after some minutes, the connection changes, so that 'batmand -c' shows
> that i am connected to 105.131.41.5 and i am able to ping 141.1.1.1.
> unfortunately, after some minutes (or even shorter), the batman script
> stops and the terminal is at the prompt again. there is no segfault,
> using 'ulimit -c unlimited' will not produce a core-dump. i suppose that
> this is not a driver bug, cause looking at this moment at 'dmesg', i can
> see that the driver is loaded using the 02:ca:ff:ee:ba:by - if i stop
> batmand and start olsrd, i will be connected to the internet as expected.
>
> i am really not aware of what else information i could provide to you,
> in order to make batmand running stable here, but if you have any idea,
> please let me know!
>
> cheers,
> doc
> _______________________________________________
> B.A.T.M.A.N mailing list
> B.A.T.M.A.N@open-mesh.net
> https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n

Re: [B.A.T.M.A.N.] problems running batman rev350

[Dragan Noveski]

Axel Neumann wrote:
> Hey Dragan,
>
>   
>>  #!/bin/sh
>>     iwconfig eth2 mode ad-hoc essid olsr.freifunk.net channel 10 ap
>> 02:CA:FF:EE ifconfig eth2 104.130.30.9
>>     
>
> (just to be shure) this should be 02:CA:FF:EE:BA:BE 
>   

of course, it was a copy+paste issue...
> ..
>   
>> i am starting batman with:
>>
>> #!/bin/bash
>>     iwconfig eth2 mode ad-hoc essid olsr.freifunk.net channel 10
>>     ifconfig eth2 105.130.30.9
>>     ifconfig eth2 up
>>     sleep 1
>>     batmand -d 1 -p 105.131.41.5 -r 1 eth2
>>     
> can  you start batmand in background with: 
> batmand -r 1 -p 105.131.41.5  eth2
> instead and tell if the problem continues. This command instantly returns your 
> prompt but a:
> ps -aux | grep batmand
> should show the running main-daemon in the background.
>   
that looks good in the moment here!
it is connecting to the preferred gateway very fast, but again it stops 
after some minutes (running 'batmand -c -d 2' in another terminal).
> Also please check that there are no predefined host routes for the 105.0.0.0/8 
> network before you start batmand and after it stopped. Meaning a:
> route -n | grep ^105 
> berfore and after the daemon is running should only show:
> 105.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 eth2
> While batmand is running it should of course show routing entries for all 
> other known batman nodes but if such host routes are still there after the 
> daemon stopped it is a definitive sign for an uncorect termination of teh 
> daemon.
>   
this is strange, after killing batmand, sometimes this command will give 
out a long list of nodes, and sometimes it is behaving as you are 
expecting it.

>   
>> #!/bin/bash
>> batmand -c -d 2
>>
>> in another terminal.
>>     
>
> It should of course always be possible to access the debug output from the 
> running batmand main-daemon by launching a batmand-client with
> batmand -c -d <1-4>
> or in batch mode (providing just a single outputpage and returns to the 
> prompt) with:
> batmand -c -d <1-4> -b
> However, it would be interesting to know if the crash is related to existence 
> of a batmand-client connecting to the main daemon. For example for 
> batmand-0.2.0-rc2-rv350 (and before) debug level 4:
> batmand -c -d 4
> is known to cause the batmand to crash after a short time and it might be 
> possible that this problems also occur with other debug-levels.
> Try 
> batmand -c -d 1
> and 
> batmand -c -d 2
> instead.
>   
when i am running batmand without debug and :

'batmand -c -d 2', batmand is stopping after couple of minutes.

trying now to run only batmand without -d option and no client, lets see for how long it will be running?!


cheers,
doc

p.s. example, batmand was stopping now again and several minutes after it is stopped:

murija2:/home/nowhiskey# route -n | grep ^105
105.192.99.3    105.130.1.67    255.255.255.255 UGH   0      0        0 eth2
105.131.10.1    105.130.30.1    255.255.255.255 UGH   0      0        0 eth2
105.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 eth2
murija2:/home/nowhiskey# 
...........


'ps ax' does not shows any batman process running.

but my feeling is, that when i do not start 'batmand -c' i will be connected much more faster. but this statement unfortunately is not very informative.

> ciao,
> axel
>
>
>   

Re: [B.A.T.M.A.N.] problems running batman rev350

[Dragan Noveski]

Dragan Noveski wrote:
> Axel Neumann wrote:
>> Hey Dragan,
>>
>>  
>>>  #!/bin/sh
>>>     iwconfig eth2 mode ad-hoc essid olsr.freifunk.net channel 10 ap
>>> 02:CA:FF:EE ifconfig eth2 104.130.30.9
>>>     
>>
>> (just to be shure) this should be 02:CA:FF:EE:BA:BE   
>
> of course, it was a copy+paste issue...
>> ..
>>  
>>> i am starting batman with:
>>>
>>> #!/bin/bash
>>>     iwconfig eth2 mode ad-hoc essid olsr.freifunk.net channel 10
>>>     ifconfig eth2 105.130.30.9
>>>     ifconfig eth2 up
>>>     sleep 1
>>>     batmand -d 1 -p 105.131.41.5 -r 1 eth2
>>>     
>> can  you start batmand in background with: batmand -r 1 -p 
>> 105.131.41.5  eth2
>> instead and tell if the problem continues. This command instantly 
>> returns your prompt but a:
>> ps -aux | grep batmand
>> should show the running main-daemon in the background.
>>   
> that looks good in the moment here!
> it is connecting to the preferred gateway very fast, but again it 
> stops after some minutes (running 'batmand -c -d 2' in another terminal).
>> Also please check that there are no predefined host routes for the 
>> 105.0.0.0/8 network before you start batmand and after it stopped. 
>> Meaning a:
>> route -n | grep ^105 berfore and after the daemon is running should 
>> only show:
>> 105.0.0.0       0.0.0.0         255.0.0.0       U     0      0        
>> 0 eth2
>> While batmand is running it should of course show routing entries for 
>> all other known batman nodes but if such host routes are still there 
>> after the daemon stopped it is a definitive sign for an uncorect 
>> termination of teh daemon.
>>   
> this is strange, after killing batmand, sometimes this command will 
> give out a long list of nodes, and sometimes it is behaving as you are 
> expecting it.
>
>>  
>>> #!/bin/bash
>>> batmand -c -d 2
>>>
>>> in another terminal.
>>>     
>>
>> It should of course always be possible to access the debug output 
>> from the running batmand main-daemon by launching a batmand-client with
>> batmand -c -d <1-4>
>> or in batch mode (providing just a single outputpage and returns to 
>> the prompt) with:
>> batmand -c -d <1-4> -b
>> However, it would be interesting to know if the crash is related to 
>> existence of a batmand-client connecting to the main daemon. For 
>> example for batmand-0.2.0-rc2-rv350 (and before) debug level 4:
>> batmand -c -d 4
>> is known to cause the batmand to crash after a short time and it 
>> might be possible that this problems also occur with other debug-levels.
>> Try batmand -c -d 1
>> and batmand -c -d 2
>> instead.
>>   
> when i am running batmand without debug and :
>
> 'batmand -c -d 2', batmand is stopping after couple of minutes.
>
> trying now to run only batmand without -d option and no client, lets 
> see for how long it will be running?!
>
>
> cheers,
> doc
>
> p.s. example, batmand was stopping now again and several minutes after 
> it is stopped:
>
> murija2:/home/nowhiskey# route -n | grep ^105
> 105.192.99.3    105.130.1.67    255.255.255.255 UGH   0      0        
> 0 eth2
> 105.131.10.1    105.130.30.1    255.255.255.255 UGH   0      0        
> 0 eth2
> 105.0.0.0       0.0.0.0         255.0.0.0       U     0      0        
> 0 eth2
> murija2:/home/nowhiskey# ...........
>
>
> 'ps ax' does not shows any batman process running.
>
> but my feeling is, that when i do not start 'batmand -c' i will be 
> connected much more faster. but this statement unfortunately is not 
> very informative.
>
>> ciao,
>> axel
>>
>>
>>   
>
look, i am running batman now for longer than a half hour and it did not 
stopped.
it is running with:

#!/bin/bash
    iwconfig eth2 mode ad-hoc essid olsr.freifunk.net channel 10
    ifconfig eth2 105.130.30.9
    ifconfig eth2 up
    sleep 1
    batmand -p 105.131.41.5 -r 1 eth2

no batman-client is running, so perhaps really this is the originally 
problem?!

cheers,
doc

Re: [B.A.T.M.A.N.] problems running batman rev350

[Dragan Noveski]

Dragan Noveski wrote:
> Dragan Noveski wrote:
>> Axel Neumann wrote:
>>> Hey Dragan,
>>>
>>>  
>>>>  #!/bin/sh
>>>>     iwconfig eth2 mode ad-hoc essid olsr.freifunk.net channel 10 ap
>>>> 02:CA:FF:EE ifconfig eth2 104.130.30.9
>>>>     
>>>
>>> (just to be shure) this should be 02:CA:FF:EE:BA:BE   
>>
>> of course, it was a copy+paste issue...
>>> ..
>>>  
>>>> i am starting batman with:
>>>>
>>>> #!/bin/bash
>>>>     iwconfig eth2 mode ad-hoc essid olsr.freifunk.net channel 10
>>>>     ifconfig eth2 105.130.30.9
>>>>     ifconfig eth2 up
>>>>     sleep 1
>>>>     batmand -d 1 -p 105.131.41.5 -r 1 eth2
>>>>     
>>> can  you start batmand in background with: batmand -r 1 -p 
>>> 105.131.41.5  eth2
>>> instead and tell if the problem continues. This command instantly 
>>> returns your prompt but a:
>>> ps -aux | grep batmand
>>> should show the running main-daemon in the background.
>>>   
>> that looks good in the moment here!
>> it is connecting to the preferred gateway very fast, but again it 
>> stops after some minutes (running 'batmand -c -d 2' in another 
>> terminal).
>>> Also please check that there are no predefined host routes for the 
>>> 105.0.0.0/8 network before you start batmand and after it stopped. 
>>> Meaning a:
>>> route -n | grep ^105 berfore and after the daemon is running should 
>>> only show:
>>> 105.0.0.0       0.0.0.0         255.0.0.0       U     0      
>>> 0        0 eth2
>>> While batmand is running it should of course show routing entries 
>>> for all other known batman nodes but if such host routes are still 
>>> there after the daemon stopped it is a definitive sign for an 
>>> uncorect termination of teh daemon.
>>>   
>> this is strange, after killing batmand, sometimes this command will 
>> give out a long list of nodes, and sometimes it is behaving as you 
>> are expecting it.
>>
>>>  
>>>> #!/bin/bash
>>>> batmand -c -d 2
>>>>
>>>> in another terminal.
>>>>     
>>>
>>> It should of course always be possible to access the debug output 
>>> from the running batmand main-daemon by launching a batmand-client with
>>> batmand -c -d <1-4>
>>> or in batch mode (providing just a single outputpage and returns to 
>>> the prompt) with:
>>> batmand -c -d <1-4> -b
>>> However, it would be interesting to know if the crash is related to 
>>> existence of a batmand-client connecting to the main daemon. For 
>>> example for batmand-0.2.0-rc2-rv350 (and before) debug level 4:
>>> batmand -c -d 4
>>> is known to cause the batmand to crash after a short time and it 
>>> might be possible that this problems also occur with other 
>>> debug-levels.
>>> Try batmand -c -d 1
>>> and batmand -c -d 2
>>> instead.
>>>   
>> when i am running batmand without debug and :
>>
>> 'batmand -c -d 2', batmand is stopping after couple of minutes.
>>
>> trying now to run only batmand without -d option and no client, lets 
>> see for how long it will be running?!
>>
>>
>> cheers,
>> doc
>>
>> p.s. example, batmand was stopping now again and several minutes 
>> after it is stopped:
>>
>> murija2:/home/nowhiskey# route -n | grep ^105
>> 105.192.99.3    105.130.1.67    255.255.255.255 UGH   0      0        
>> 0 eth2
>> 105.131.10.1    105.130.30.1    255.255.255.255 UGH   0      0        
>> 0 eth2
>> 105.0.0.0       0.0.0.0         255.0.0.0       U     0      0        
>> 0 eth2
>> murija2:/home/nowhiskey# ...........
>>
>>
>> 'ps ax' does not shows any batman process running.
>>
>> but my feeling is, that when i do not start 'batmand -c' i will be 
>> connected much more faster. but this statement unfortunately is not 
>> very informative.
>>
>>> ciao,
>>> axel
>>>
>>>
>>>   
>>
> look, i am running batman now for longer than a half hour and it did 
> not stopped.
> it is running with:
>
> #!/bin/bash
>    iwconfig eth2 mode ad-hoc essid olsr.freifunk.net channel 10
>    ifconfig eth2 105.130.30.9
>    ifconfig eth2 up
>    sleep 1
>    batmand -p 105.131.41.5 -r 1 eth2
>
> no batman-client is running, so perhaps really this is the originally 
> problem?!
>
> cheers,
> doc
ok, it is obviously  now: if i start batmand without the -d option and 
if i do not start 'batmand -c'
everything runs just smoothly!

i will be experimenting with this in the next days (probably monday) and 
will report my experience.

cheers,
doc

Re: [B.A.T.M.A.N.] problems running batman rev350

[Marek Lindner]

Hi,


> ok, it is obviously  now: if i start batmand without the -d option and
> if i do not start 'batmand -c'
> everything runs just smoothly!
>
> i will be experimenting with this in the next days (probably monday) and
> will report my experience.

thanks for your bug report. I just issued 2 patches. Number one reenables core 
dumps on segmentation fault. Batman listens for that signal and tries to 
clean up the routing table, interfaces, etc. Therefore batman exited 
gracefully and the core dump was not created.

But if batman had received SIGSEGV it would print the message "Error - SIGSEGV 
received !". It seems that did not happen ?!
I got the idea that you may be disconnect with your client in the very moment 
when batman tries to write a message into the connection. The kernel would 
recognize the disconnect and sends SIGPIPE to batman which exits as this is 
the default behaviour. The second patch changes that. It is a wild 
guess ...  :-)

Please, try it out.

Regards,
Marek

Re: [B.A.T.M.A.N.] problems running batman rev350

[Dragan Noveski]

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

Marek Lindner wrote:
> Hi,
>
>
>   
>> ok, it is obviously  now: if i start batmand without the -d option and
>> if i do not start 'batmand -c'
>> everything runs just smoothly!
>>
>> i will be experimenting with this in the next days (probably monday) and
>> will report my experience.
>>     
>
> thanks for your bug report. I just issued 2 patches. Number one reenables core 
> dumps on segmentation fault. Batman listens for that signal and tries to 
> clean up the routing table, interfaces, etc. Therefore batman exited 
> gracefully and the core dump was not created.
>
> But if batman had received SIGSEGV it would print the message "Error - SIGSEGV 
> received !". It seems that did not happen ?!
> I got the idea that you may be disconnect with your client in the very moment 
> when batman tries to write a message into the connection. The kernel would 
> recognize the disconnect and sends SIGPIPE to batman which exits as this is 
> the default behaviour. The second patch changes that. It is a wild 
> guess ...  :-)
>
> Please, try it out.
>
> Regards,
> Marek
> _______________________________________________
> B.A.T.M.A.N mailing list
> B.A.T.M.A.N@open-mesh.net
> https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n
>
>   
hi and thanks for the response!

since i got the core dump created now, i suppose that the patches are in 
rev352?

pleas tell me what to do with the core file, but for now i will attach it.

cheers,
doc

[-- Attachment #2: core.5825.bz2 --]
[-- Type: application/octet-stream, Size: 13219 bytes --]

Re: [B.A.T.M.A.N.] problems running batman rev350

[Dragan Noveski]

Marek Lindner wrote:
> Hi,
>
>
>   
>> since i got the core dump created now, i suppose that the patches are in
>> rev352?
>>
>> pleas tell me what to do with the core file, but for now i will attach it.
>>     
>
> to fully debug your problem I need the binary you created the core dump with. 
> Do not create a new binary - I have to have the binary which was running 
> during the segmentation fault.
>
> Regards,
> Marek
>
>   
where can i upload the binary?

cheers,
doc

Re: [B.A.T.M.A.N.] problems running batman rev350

[Axel Neumann]

Hello Dragan,

If you want you can try rv360 now. Marek fixed two of the bugs indicated by 
you. Hopefully its better now and thanks a lot for your help. 

Seems like your real-time kernel makes you a real-time debugger :-)

ciao,
axel



On Monday 21 May 2007 13:33, Dragan Noveski wrote:
> Marek Lindner wrote:
> > Hi,
> >
> >> since i got the core dump created now, i suppose that the patches are in
> >> rev352?
> >>
> >> pleas tell me what to do with the core file, but for now i will attach
> >> it.
> >
> > to fully debug your problem I need the binary you created the core dump
> > with. Do not create a new binary - I have to have the binary which was
> > running during the segmentation fault.
> >
> > Regards,
> > Marek
>
> where can i upload the binary?
>
> cheers,
> doc
> _______________________________________________
> B.A.T.M.A.N mailing list
> B.A.T.M.A.N@open-mesh.net
> https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n