[B.A.T.M.A.N.] strange batman aborting

[B.A.T.M.A.N.] strange batman aborting

[Jan Hetges]

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

Hi All
after two weeks uptime bmxd_rv804 just died! and not only that one,
but on a neighbouring node (~5 days uptime) as well.
So i restarted them, and about 26hrs later, they are both dead again.
So i enabled Lui's watchout4batman, maybe i see at least, which one 
dies first. Only unnormal in the log:
 user.warn kernel: nf_conntrack: table full, dropping packet.
any ideas?

cheers

  --Jan

p.s. both boxes run kamikaze 7.07 i386  

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [B.A.T.M.A.N.] strange batman aborting

[Axel Neumann]

Hi jan,

just sitting here with lui and discussing your problem...
batman usually terminates itself when it finds a firewall blocking its own 
packets. Seems like your firewall starts to drop packets beause the maximum 
number of possible connection tracking has been exceeded. You can find more 
information about that (and also how to increase the limit) here:
http://www.fli4l.de/fileadmin/doc/deutsch/html/fli4l-3.1.3/node9.html

to see the currently tracked connection look at 
cat /proc/net/ip_conntrack

ciao,
lui, axel

On Donnerstag 06 Dezember 2007, Jan Hetges wrote:
> Hi All
> after two weeks uptime bmxd_rv804 just died! and not only that one,
> but on a neighbouring node (~5 days uptime) as well.
> So i restarted them, and about 26hrs later, they are both dead again.
> So i enabled Lui's watchout4batman, maybe i see at least, which one
> dies first. Only unnormal in the log:
>  user.warn kernel: nf_conntrack: table full, dropping packet.
> any ideas?
>
> cheers
>
>   --Jan
>
> p.s. both boxes run kamikaze 7.07 i386

RE: [B.A.T.M.A.N.] strange batman aborting

[Predrag Balorda]

This table full thingy could be that you are reaching your upper limit on
connections. Perhaps someone playing with bittorrent (or similar) on your
network? You either increase the maximum number of connections or you
decrease the timeout values.
Just an idea...

Pele

-----Original Message-----
From: b.a.t.m.a.n-bounces@open-mesh.net
[mailto:b.a.t.m.a.n-bounces@open-mesh.net] On Behalf Of Jan Hetges
Sent: Thursday, December 06, 2007 3:34 AM
To: b.a.t.m.a.n@open-mesh.net
Subject: [B.A.T.M.A.N.] strange batman aborting

Hi All
after two weeks uptime bmxd_rv804 just died! and not only that one, but on a
neighbouring node (~5 days uptime) as well.
So i restarted them, and about 26hrs later, they are both dead again.
So i enabled Lui's watchout4batman, maybe i see at least, which one dies
first. Only unnormal in the log:
 user.warn kernel: nf_conntrack: table full, dropping packet.
any ideas?

cheers

  --Jan

p.s. both boxes run kamikaze 7.07 i386  

Re: [B.A.T.M.A.N.] strange batman aborting

[Jan Hetges]

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

On Thu, Dec 06, 2007 at 12:08:43PM +0100, Predrag Balorda wrote:
> connections. Perhaps someone playing with bittorrent (or similar) on your

no, two infected windoze boxes in my favourite e-cafe looking for new
friends (with port 135 open) in neighbouring networks ;-)

cheers

  --Jan

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [B.A.T.M.A.N.] strange batman aborting

[tetzlav]

Jan Hetges schrieb:
> Only unnormal in the log:
>  user.warn kernel: nf_conntrack: table full, dropping packet.
> any ideas?

I've had the same Problem (independent from batmand) on some kamikaze-boxes.
You can try to enlarge the max-memory for conntrack (default is 2048):

> root@MB-1-WDS:~$ sysctl net.ipv4.netfilter.ip_conntrack_max
> net.ipv4.netfilter.ip_conntrack_max = 2048
> root@MB-1-WDS:~$ sysctl -w net.ipv4.netfilter.ip_conntrack_max=8192
> net.ipv4.netfilter.ip_conntrack_max = 8192
> root@MB-1-WDS:~$ sysctl net.ipv4.netfilter.ip_conntrack_max       
> net.ipv4.netfilter.ip_conntrack_max = 8192

append something like this to /etc/sysctl.conf
net.ipv4.netfilter.ip_conntrack_max=8192


Regards
tetzlav

Re: [B.A.T.M.A.N.] strange batman aborting

[Jan Hetges]

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

Thanks All 

  --Jan

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[B.A.T.M.A.N.] exp-rv811 and exp-864 non-interoperable?

[Predrag Balorda]

Before I go round upgrading my routers, are these two incompatible because
it seems so? If so then I'll need to figure out the exact order of upgrading
(i.e furthest first - I don't want to have to climb roofs or walk too long)

Best regards,

Pele

P.S. also has anyone compared network throughput between beta and exp and
are there any benefits to beta over exp?
P.P.S I'm experimenting with PoE and guess which process is the first that
gets killed because of undervoltage?! :-)

Re: [B.A.T.M.A.N.] exp-rv811 and exp-864 non-interoperable?

[Jan Hetges]

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

Hi
first: could you please open a new tread, istead of replying OT ?!
On Mon, Dec 10, 2007 at 09:50:57AM +0100, Predrag Balorda wrote:
> Before I go round upgrading my routers, are these two incompatible because
> it seems so? If so then I'll need to figure out the exact order of upgrading
> (i.e furthest first - I don't want to have to climb roofs or walk too long)
if you read the ChangeLog, you see: 
12/09/07 15:48:20 863 863    axel   Incremented Compatibility Version !!

cheers 

  --Jan
> 
> Best regards,
> 
> Pele
> 
> P.S. also has anyone compared network throughput between beta and exp and
> are there any benefits to beta over exp?
> P.P.S I'm experimenting with PoE and guess which process is the first that
> gets killed because of undervoltage?! :-)
> 
> _______________________________________________
> 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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]