19 May
2007
19 May
'07
2:55 p.m.
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
19 May
19 May
3:49 p.m.
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(a)open-mesh.net
https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n
5:02 p.m.
Axel Neumann wrote:
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.
Hey Dragan,
of course, it was a copy+paste issue...
#!/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
..
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).
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.
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.
ciao,
axel
5:31 p.m.
Dragan Noveski wrote:
Axel Neumann wrote:
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.
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
Hey Dragan,
of course, it was a copy+paste issue...
#!/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 ..
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).
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.
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.
ciao,
axel
6:44 p.m.
Dragan Noveski wrote:
Dragan Noveski wrote:
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
Axel Neumann wrote:
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.
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 Hey Dragan,
of course, it was a copy+paste issue...
#!/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 ..
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).
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.
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.
ciao,
axel
8:10 p.m.
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
21 May
21 May
10:35 a.m.
Marek Lindner wrote:
Hi,
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
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(a)open-mesh.net
https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n
5792
days inactive
5794
days old
b.a.t.m.a.n@lists.open-mesh.org
6 comments
3 participants
participants (3)
-
Axel Neumann -
Dragan Noveski -
Marek Lindner