* [B.A.T.M.A.N.] routing problem?
@ 2007-11-09 14:23 Stefano Scipioni
2007-11-10 11:43 ` Axel Neumann
0 siblings, 1 reply; 13+ messages in thread
From: Stefano Scipioni @ 2007-11-09 14:23 UTC (permalink / raw)
To: The list for a Better Approach To Mobile Ad-hoc Networking
I'm testing batman 0.3 exp rv 777
traceroute give me a problem
root@sala:~$ traceroute 10.0.1.1
traceroute: can't find interface
root@sala:~$ ip route ls tab 66
10.1.5.104 dev ath0 proto static scope link src 10.1.5.102
10.1.5.130 via 10.1.5.104 dev ath0 proto static
10.1.5.129 via 10.1.5.1 dev ath0 proto static
10.1.5.1 via 10.1.5.104 dev ath0 proto static
root@sala:~$ ip route ls tab 65
10.0.1.0/24 via 10.1.5.1 dev ath0 proto static
root@sala:~$ traceroute 10.0.1.1
traceroute: can't find interface
root@sala:~$ ping 10.0.1.1
PING 10.0.1.1 (10.0.1.1): 56 data bytes
64 bytes from 10.0.1.1: seq=0 ttl=61 time=9.119 ms
64 bytes from 10.0.1.1: seq=1 ttl=61 time=8.486 ms
traceroute works If I utilize source address option.
What is my mistake?
Also if one of nodes has no batman-exp running on it I can't reach it
from neighbours (I use batmand on ath0 interface, not an alias)?
Perhaps I have to use --no-unreachable-rule?
Stefano
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [B.A.T.M.A.N.] routing problem?
2007-11-09 14:23 [B.A.T.M.A.N.] routing problem? Stefano Scipioni
@ 2007-11-10 11:43 ` Axel Neumann
2007-11-11 15:55 ` Stefano Scipioni
0 siblings, 1 reply; 13+ messages in thread
From: Axel Neumann @ 2007-11-10 11:43 UTC (permalink / raw)
To: The list for a Better Approach To Mobile Ad-hoc Networking
On Freitag 09 November 2007, Stefano Scipioni wrote:
> I'm testing batman 0.3 exp rv 777
>
> traceroute give me a problem
>
> root@sala:~$ traceroute 10.0.1.1
> traceroute: can't find interface
> root@sala:~$ ip route ls tab 66
> 10.1.5.104 dev ath0 proto static scope link src 10.1.5.102
> 10.1.5.130 via 10.1.5.104 dev ath0 proto static
> 10.1.5.129 via 10.1.5.1 dev ath0 proto static
> 10.1.5.1 via 10.1.5.104 dev ath0 proto static
> root@sala:~$ ip route ls tab 65
> 10.0.1.0/24 via 10.1.5.1 dev ath0 proto static
> root@sala:~$ traceroute 10.0.1.1
> traceroute: can't find interface
> root@sala:~$ ping 10.0.1.1
> PING 10.0.1.1 (10.0.1.1): 56 data bytes
> 64 bytes from 10.0.1.1: seq=0 ttl=61 time=9.119 ms
> 64 bytes from 10.0.1.1: seq=1 ttl=61 time=8.486 ms
>
> traceroute works If I utilize source address option.
> What is my mistake?
i think theres no mistake, busybox-traceroute is just to stupid to figure out
the correct src ip. In my test, tcpdump showed that it uses the first
(non-alias) address of the outgoing interface. No matter if the route to the
destination specifies the src address or not. Did you use an alias interfaces
for this scenrio?
And even better, the traceroute on my notebook chooses the correct outgoing
src address but unless i specify it also manually it does not work either.
The reason is a corrupted udp checksum which is verified by the final
destination of the packet.
>
> Also if one of nodes has no batman-exp running on it I can't reach it
> from neighbours (I use batmand on ath0 interface, not an alias)?
> Perhaps I have to use --no-unreachable-rule?
For correct routing between batman-nodes and non-batman nodes you need to set
routes manually. If a multi-homed node is involved with the same netmask on
multiple interfaces then you must also specify the src address for the manual
routing entry like: ip r add 10.0.1.1/32 dev ath0 src 10.1.5.102
And on the batman-node you must either HNA announce the ip of the non-batman
node using -a (this will automaticall disable the unreachable rule to hit for
the ip address of the non-batman node).
Or, just as you suggested, launch batman with the --no-unreachable-rule.
ciao,
axel
>
> Stefano
> _______________________________________________
> 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [B.A.T.M.A.N.] routing problem?
2007-11-10 11:43 ` Axel Neumann
@ 2007-11-11 15:55 ` Stefano Scipioni
2007-11-11 17:16 ` [B.A.T.M.A.N.] routing problem? / Changes in exp rv790 Axel Neumann
0 siblings, 1 reply; 13+ messages in thread
From: Stefano Scipioni @ 2007-11-11 15:55 UTC (permalink / raw)
To: The list for a Better Approach To Mobile Ad-hoc Networking
2007/11/10, Axel Neumann <axel@open-mesh.net>:
> On Freitag 09 November 2007, Stefano Scipioni wrote:
> > I'm testing batman 0.3 exp rv 777
> >
> > traceroute give me a problem
> >
> > root@sala:~$ traceroute 10.0.1.1
> > traceroute: can't find interface
> > root@sala:~$ ip route ls tab 66
> > 10.1.5.104 dev ath0 proto static scope link src 10.1.5.102
> > 10.1.5.130 via 10.1.5.104 dev ath0 proto static
> > 10.1.5.129 via 10.1.5.1 dev ath0 proto static
> > 10.1.5.1 via 10.1.5.104 dev ath0 proto static
> > root@sala:~$ ip route ls tab 65
> > 10.0.1.0/24 via 10.1.5.1 dev ath0 proto static
> > root@sala:~$ traceroute 10.0.1.1
> > traceroute: can't find interface
> > root@sala:~$ ping 10.0.1.1
> > PING 10.0.1.1 (10.0.1.1): 56 data bytes
> > 64 bytes from 10.0.1.1: seq=0 ttl=61 time=9.119 ms
> > 64 bytes from 10.0.1.1: seq=1 ttl=61 time=8.486 ms
> >
> > traceroute works If I utilize source address option.
> > What is my mistake?
>
> i think theres no mistake, busybox-traceroute is just to stupid to figure out
> the correct src ip. In my test, tcpdump showed that it uses the first
> (non-alias) address of the outgoing interface. No matter if the route to the
> destination specifies the src address or not. Did you use an alias interfaces
> for this scenrio?
No, I use master address
> And even better, the traceroute on my notebook chooses the correct outgoing
> src address but unless i specify it also manually it does not work either.
> The reason is a corrupted udp checksum which is verified by the final
> destination of the packet.
I choose to utilize tcptraceroute in kamikaze packages
Now I have other question about routing...
I have 4 nodes: A,B,C and D
A-------B-------D
\-------C-------/
fromA> D via B dev ath0 proto static
fromD> A via C dev ath0 proto static
When A talk to D choose B while when D talk to A choose C.
In this scenario node D can't talk to A for example with ping.
Is correct this type of routing?
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [B.A.T.M.A.N.] routing problem? / Changes in exp rv790
2007-11-11 15:55 ` Stefano Scipioni
@ 2007-11-11 17:16 ` Axel Neumann
2007-11-11 20:41 ` [B.A.T.M.A.N.] batmand crash / core dump Michael Burmeister-Brown
0 siblings, 1 reply; 13+ messages in thread
From: Axel Neumann @ 2007-11-11 17:16 UTC (permalink / raw)
To: The list for a Better Approach To Mobile Ad-hoc Networking
Hi
> Now I have other question about routing...
>
> I have 4 nodes: A,B,C and D
>
>
> A-------B-------D
> \-------C-------/
>
> fromA> D via B dev ath0 proto static
> fromD> A via C dev ath0 proto static
I have difficulties to clearly understand the last two lines.
Is this what routing table 66 or table 65 tells you at node A and D. Perhaps
its easier if you just paste the command and output of the command which
revealed this information, might also simplify to find other reasons for
strange behavior.
In this sense, one question? Do you use different networks/netmasks for the
different links. Because this might be one reason for problems.
The thing is:
when the batman network of node A is different from the batman networks used
by node D then D will not search its routing table 66 for the appropriate
route to node A. Even if the correct route form D to A is listed by the
command: ip r ls t 66
The problem are the rules which are configured by the batman daemon.
The command: "ip rule" on node D might show something like:
0: from all lookup local
6599: from all lookup 65
6600: from all to x.y.D.0/24 lookup 66
32766: from all lookup main
32767: from all lookup default
while on node A it might show the same except for one line:
6600: from all to x.y.A.0/24 lookup 66
Rule 6600 tells the network layer to only search table 66 for certain
destinations. And if D is searching for a destination in x.y.A.0/24 it will
not fit :-(.
Anyway, because there has been so much confusion about this, i changed this
with exp 0.3 revision 790. The daemon now configures the critical rule as:
6600: from all lookup 66
No more restrictions for table 66. This should always fit.
Since revision 790, also the unreachable rule is omitted by default, which has
been another reason for confusion.
If you (or others) want to have back the old unreachable rules or the
restrictive mask for table 66, the daemon may be started with the
--more-rules switch.
>
> When A talk to D choose B while when D talk to A choose C.
> In this scenario node D can't talk to A for example with ping.
does ping really not work?
>
> Is correct this type of routing?
Why not? According to your setup, both routes would work. This would be a
typical case for asymmetric routing. But generally nothing speaks against
such a route.
ciao
/axel
> _______________________________________________
> 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [B.A.T.M.A.N.] batmand crash / core dump
2007-11-11 17:16 ` [B.A.T.M.A.N.] routing problem? / Changes in exp rv790 Axel Neumann
@ 2007-11-11 20:41 ` Michael Burmeister-Brown
2007-11-11 22:30 ` [B.A.T.M.A.N.] batman gw nodes and routing (rv792) Predrag Balorda
` (2 more replies)
0 siblings, 3 replies; 13+ messages in thread
From: Michael Burmeister-Brown @ 2007-11-11 20:41 UTC (permalink / raw)
To: The list for a Better Approach To Mobile Ad-hoc Networking
Hi,
We are seeing a crash in batmand (beta, rv767-792) on kamikaze 7.09 /
atheros 2.6 / mips.
I am trying to get a core dump for Marek, but no file is created despite
doing ulimit -c 20000.
Does anyone know what must be done to get a core dump on this platform?
Thanks!
-----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 Axel Neumann
Sent: Sunday, November 11, 2007 9:16 AM
To: The list for a Better Approach To Mobile Ad-hoc Networking
Subject: Re: [B.A.T.M.A.N.] routing problem? / Changes in exp rv790
Hi
> Now I have other question about routing...
>
> I have 4 nodes: A,B,C and D
>
>
> A-------B-------D
> \-------C-------/
>
> fromA> D via B dev ath0 proto static
> fromD> A via C dev ath0 proto static
I have difficulties to clearly understand the last two lines.
Is this what routing table 66 or table 65 tells you at node A and D.
Perhaps
its easier if you just paste the command and output of the command which
revealed this information, might also simplify to find other reasons for
strange behavior.
In this sense, one question? Do you use different networks/netmasks for
the
different links. Because this might be one reason for problems.
The thing is:
when the batman network of node A is different from the batman networks
used
by node D then D will not search its routing table 66 for the
appropriate
route to node A. Even if the correct route form D to A is listed by the
command: ip r ls t 66
The problem are the rules which are configured by the batman daemon.
The command: "ip rule" on node D might show something like:
0: from all lookup local
6599: from all lookup 65
6600: from all to x.y.D.0/24 lookup 66
32766: from all lookup main
32767: from all lookup default
while on node A it might show the same except for one line:
6600: from all to x.y.A.0/24 lookup 66
Rule 6600 tells the network layer to only search table 66 for certain
destinations. And if D is searching for a destination in x.y.A.0/24 it
will
not fit :-(.
Anyway, because there has been so much confusion about this, i changed
this
with exp 0.3 revision 790. The daemon now configures the critical rule
as:
6600: from all lookup 66
No more restrictions for table 66. This should always fit.
Since revision 790, also the unreachable rule is omitted by default,
which has
been another reason for confusion.
If you (or others) want to have back the old unreachable rules or the
restrictive mask for table 66, the daemon may be started with the
--more-rules switch.
>
> When A talk to D choose B while when D talk to A choose C.
> In this scenario node D can't talk to A for example with ping.
does ping really not work?
>
> Is correct this type of routing?
Why not? According to your setup, both routes would work. This would be
a
typical case for asymmetric routing. But generally nothing speaks
against
such a route.
ciao
/axel
> _______________________________________________
> 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
_______________________________________________
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [B.A.T.M.A.N.] batman gw nodes and routing (rv792)
2007-11-11 20:41 ` [B.A.T.M.A.N.] batmand crash / core dump Michael Burmeister-Brown
@ 2007-11-11 22:30 ` Predrag Balorda
2007-11-12 14:31 ` Axel Neumann
2007-11-11 22:34 ` [B.A.T.M.A.N.] vis and batman-exp (rv780-792) Predrag Balorda
2007-11-12 17:13 ` [B.A.T.M.A.N.] batmand crash / core dump Axel Neumann
2 siblings, 1 reply; 13+ messages in thread
From: Predrag Balorda @ 2007-11-11 22:30 UTC (permalink / raw)
To: 'The list for a Better Approach To Mobile Ad-hoc Networking'
This is my setup - I sincerely hope ascii-art holds up as it took some time
to create! :-)
gateway
Internet ---- 123.456.789.100 router1
10.0.0.1 --- 10.0.0.10 router2
router3
(ath0) 105.0.0.1 --batman-- 105.0.0.2 --batman--
105.0.0.3
(eth0) 10.0.1.0 10.0.2.0
10.0.3.0
(bat0) 169.254.0.0 --PtP-- 169.254.2.79
(bat0) 169.254.0.0 --------------PtP-----------
169.254.2.80
I have read the bmx pdf and it is excellent. Everything works as it should
on batman-exp rv792. But I have a problem. The guide assumes that your
gateway to the public internet is my 'router1' and it also assumes that you
have a firewall running on all those routers.
It also ends up with double-nat (well, actually triple-nat in my case). I
have gotten rid of one level of nat (on router1). But I'm still left with a
double nat.
Nat happens when default route traffic from batman nodes is sent down bat0
tunnel and then once again when my gateway passes it onto the public ip
space.
I have succeeded in creating a setup where no nat is done when client nodes
connect to 10.0.0.0/24 network (10.0.0.0/24 hna on router1) but if I want to
go out onto the internet I simply have to do
iptables -t nat -A POSTROUTING -o bat0 -j MASQUERADE
on each batman node, otherwise nodes themselves can get out but their eth0
clients cannot (i.e. from 10.0.2.0/24 or 10.0.3.0/24 - 10.0.1.0/24 doesn't
have this problem as it has a default route entry in the output of 'route' -
other batman nodes don't)
Can someone with a bit more experience in these matters give me a hand. I
will probably end up having to use batman on gateway node as well but I'd
rather have this possibility of a gw node not runnig batman.
Thanks again!
Pele
^ permalink raw reply [flat|nested] 13+ messages in thread
* [B.A.T.M.A.N.] vis and batman-exp (rv780-792)
2007-11-11 20:41 ` [B.A.T.M.A.N.] batmand crash / core dump Michael Burmeister-Brown
2007-11-11 22:30 ` [B.A.T.M.A.N.] batman gw nodes and routing (rv792) Predrag Balorda
@ 2007-11-11 22:34 ` Predrag Balorda
2007-11-12 7:57 ` Stefano Scipioni
2007-11-12 17:13 ` [B.A.T.M.A.N.] batmand crash / core dump Axel Neumann
2 siblings, 1 reply; 13+ messages in thread
From: Predrag Balorda @ 2007-11-11 22:34 UTC (permalink / raw)
To: 'The list for a Better Approach To Mobile Ad-hoc Networking'
Does batman-exp work with vis (B.A.T.M.A.N. visualisation server 0.3-beta)?
I don't seem to be getting any topology info but batman beta 0.3 was working
with the same setup.
Pele
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [B.A.T.M.A.N.] vis and batman-exp (rv780-792)
2007-11-11 22:34 ` [B.A.T.M.A.N.] vis and batman-exp (rv780-792) Predrag Balorda
@ 2007-11-12 7:57 ` Stefano Scipioni
2007-11-12 13:53 ` Axel Neumann
0 siblings, 1 reply; 13+ messages in thread
From: Stefano Scipioni @ 2007-11-12 7:57 UTC (permalink / raw)
To: pele, The list for a Better Approach To Mobile Ad-hoc Networking
2007/11/11, Predrag Balorda <predrag.balorda@gmail.com>:
> Does batman-exp work with vis (B.A.T.M.A.N. visualisation server 0.3-beta)?
> I don't seem to be getting any topology info but batman beta 0.3 was working
> with the same setup.
>
> Pele
I changed in vis.h:
#define VIS_COMPAT_VERSION 21
Stefano
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [B.A.T.M.A.N.] vis and batman-exp (rv780-792)
2007-11-12 7:57 ` Stefano Scipioni
@ 2007-11-12 13:53 ` Axel Neumann
2007-11-12 14:00 ` Predrag Balorda
0 siblings, 1 reply; 13+ messages in thread
From: Axel Neumann @ 2007-11-12 13:53 UTC (permalink / raw)
To: The list for a Better Approach To Mobile Ad-hoc Networking
thanks for the tip. Now changed this in rv 794
Modified:
trunk/batman-experimental/batman.h
Log:
change VIS_COMPAT_VERSION to 21
/axel
On Montag 12 November 2007, Stefano Scipioni wrote:
> 2007/11/11, Predrag Balorda <predrag.balorda@gmail.com>:
> > Does batman-exp work with vis (B.A.T.M.A.N. visualisation server
> > 0.3-beta)? I don't seem to be getting any topology info but batman beta
> > 0.3 was working with the same setup.
> >
> > Pele
>
> I changed in vis.h:
> #define VIS_COMPAT_VERSION 21
>
> Stefano
> _______________________________________________
> 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: [B.A.T.M.A.N.] vis and batman-exp (rv780-792)
2007-11-12 13:53 ` Axel Neumann
@ 2007-11-12 14:00 ` Predrag Balorda
0 siblings, 0 replies; 13+ messages in thread
From: Predrag Balorda @ 2007-11-12 14:00 UTC (permalink / raw)
To: 'The list for a Better Approach To Mobile Ad-hoc Networking'
Thanks, works now!
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 Axel Neumann
Sent: Monday, November 12, 2007 2:54 PM
To: The list for a Better Approach To Mobile Ad-hoc Networking
Subject: Re: [B.A.T.M.A.N.] vis and batman-exp (rv780-792)
thanks for the tip. Now changed this in rv 794
Modified:
trunk/batman-experimental/batman.h
Log:
change VIS_COMPAT_VERSION to 21
/axel
On Montag 12 November 2007, Stefano Scipioni wrote:
> 2007/11/11, Predrag Balorda <predrag.balorda@gmail.com>:
> > Does batman-exp work with vis (B.A.T.M.A.N. visualisation server
> > 0.3-beta)? I don't seem to be getting any topology info but batman beta
> > 0.3 was working with the same setup.
> >
> > Pele
>
> I changed in vis.h:
> #define VIS_COMPAT_VERSION 21
>
> Stefano
> _______________________________________________
> 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
_______________________________________________
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [B.A.T.M.A.N.] batman gw nodes and routing (rv792)
2007-11-11 22:30 ` [B.A.T.M.A.N.] batman gw nodes and routing (rv792) Predrag Balorda
@ 2007-11-12 14:31 ` Axel Neumann
0 siblings, 0 replies; 13+ messages in thread
From: Axel Neumann @ 2007-11-12 14:31 UTC (permalink / raw)
To: pele, The list for a Better Approach To Mobile Ad-hoc Networking
Hi,
On Sonntag 11 November 2007, Predrag Balorda wrote:
> This is my setup - I sincerely hope ascii-art holds up as it took some time
> to create! :-)
gateway
Inet -- 123.456.789.100 router1
10.0.0.1 --- 10.0.0.10 router2 router3
(ath0) 105.0.0.1 --batman-- 105.0.0.2 --batman-- 105.0.0.3
(eth0) 10.0.1.0 10.0.2.0 10.0.3.0
(bat0) 169.254.0.0 --PtP-- 169.254.2.79
(bat0) 169.254.0.0 --------------PtP----------- 169.254.2.80
>
> I have read the bmx pdf and it is excellent. Everything works as it should
> on batman-exp rv792. But I have a problem. The guide assumes that your
> gateway to the public internet is my 'router1' and it also assumes that you
> have a firewall running on all those routers.
just an idea...
The document does not yet mention the option for the old, stateless,
batmand-0.2-based one-way-tunnel. The one-way-tunnel only entunnel uplink
internet data (from the client node to the gw node). No tunnels are used for
downlink internet data (from the GW node to the client). For downlink
traffic, the GW node just forwards the data. Therefore the inner IP address
must be a valid and known IP address in your mesh - usually the batman
address of the client node.
With rv 795, the source address of the entunneled packets at the client side
can also be an addresses from a non-batman interface (like eth0 in your
setup) if this address ranges have been HNA announced by the client node.
You can enable them at the gw side with --one-way-tunnel 1
At the client side, you can enable --one-way-tunnel <value> with a value
larger than 0. The value defines a preference for the tunnel types offerred
by the selected GW (higher value = more preferred). You can disable the
0.3-default-two-way-tunnel with --two-way-tunnel 0
(see also --dangerous for very short help)
This way it should be possible to:
- do SNAT only on your gateway. No (S)NAT on any batman node
- configure a default route at router 1 to your gateway
- configure a 10.0.0.0/16 route at the gateway to router 1
- for the uplink traffic packets from client-node-dhcp-clients are entunnelled
at the client-node but with the original client-node-dhcp-clients ip address
as the inner tunnel src address.
- the client-node-dhcp-clients ip address ranges are announced by the
corresponding clients
- for the downlink traffic let the batman daemon on router 1 choose the
correct next hop towards the client node which announced the correspoding
network destination address.
- maybe other (dis)advantages, depending on your personal preferences like: no
blackhole-GW-detection, no means for a GW node to control the maximum number
of connected client nodes, less tunnel-protocol-overhead,...
happy routing,
/axel
>
> It also ends up with double-nat (well, actually triple-nat in my case). I
> have gotten rid of one level of nat (on router1). But I'm still left with a
> double nat.
>
> Nat happens when default route traffic from batman nodes is sent down bat0
> tunnel and then once again when my gateway passes it onto the public ip
> space.
>
> I have succeeded in creating a setup where no nat is done when client nodes
> connect to 10.0.0.0/24 network (10.0.0.0/24 hna on router1) but if I want
> to go out onto the internet I simply have to do
>
> iptables -t nat -A POSTROUTING -o bat0 -j MASQUERADE
>
> on each batman node, otherwise nodes themselves can get out but their eth0
> clients cannot (i.e. from 10.0.2.0/24 or 10.0.3.0/24 - 10.0.1.0/24 doesn't
> have this problem as it has a default route entry in the output of 'route'
> - other batman nodes don't)
>
> Can someone with a bit more experience in these matters give me a hand. I
> will probably end up having to use batman on gateway node as well but I'd
> rather have this possibility of a gw node not runnig batman.
>
> Thanks again!
>
> Pele
>
> _______________________________________________
> 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [B.A.T.M.A.N.] batmand crash / core dump
2007-11-11 20:41 ` [B.A.T.M.A.N.] batmand crash / core dump Michael Burmeister-Brown
2007-11-11 22:30 ` [B.A.T.M.A.N.] batman gw nodes and routing (rv792) Predrag Balorda
2007-11-11 22:34 ` [B.A.T.M.A.N.] vis and batman-exp (rv780-792) Predrag Balorda
@ 2007-11-12 17:13 ` Axel Neumann
2007-11-24 13:02 ` Marek Lindner
2 siblings, 1 reply; 13+ messages in thread
From: Axel Neumann @ 2007-11-12 17:13 UTC (permalink / raw)
To: The list for a Better Approach To Mobile Ad-hoc Networking
Hi,
i've also experienced this problem - on mips and mipsel kamikaze. I also
remember that it causually worked but not today :-(
If you find any solution to this problem please let me know
thanks,
axel
On Sonntag 11 November 2007, Michael Burmeister-Brown wrote:
> Hi,
>
> We are seeing a crash in batmand (beta, rv767-792) on kamikaze 7.09 /
> atheros 2.6 / mips.
>
> I am trying to get a core dump for Marek, but no file is created despite
> doing ulimit -c 20000.
>
> Does anyone know what must be done to get a core dump on this platform?
>
> Thanks!
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [B.A.T.M.A.N.] batmand crash / core dump
2007-11-12 17:13 ` [B.A.T.M.A.N.] batmand crash / core dump Axel Neumann
@ 2007-11-24 13:02 ` Marek Lindner
0 siblings, 0 replies; 13+ messages in thread
From: Marek Lindner @ 2007-11-24 13:02 UTC (permalink / raw)
To: The list for a Better Approach To Mobile Ad-hoc Networking
Hi,
> i've also experienced this problem - on mips and mipsel kamikaze. I also
> remember that it causually worked but not today :-(
> If you find any solution to this problem please let me know
I reproduced this *exact* error on my notebook (debian unstable) and I get a
core dump. This problem of not getting a core dump must be related to
OpenWRT.
Greetings,
Marek
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2007-11-24 13:02 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-11-09 14:23 [B.A.T.M.A.N.] routing problem? Stefano Scipioni
2007-11-10 11:43 ` Axel Neumann
2007-11-11 15:55 ` Stefano Scipioni
2007-11-11 17:16 ` [B.A.T.M.A.N.] routing problem? / Changes in exp rv790 Axel Neumann
2007-11-11 20:41 ` [B.A.T.M.A.N.] batmand crash / core dump Michael Burmeister-Brown
2007-11-11 22:30 ` [B.A.T.M.A.N.] batman gw nodes and routing (rv792) Predrag Balorda
2007-11-12 14:31 ` Axel Neumann
2007-11-11 22:34 ` [B.A.T.M.A.N.] vis and batman-exp (rv780-792) Predrag Balorda
2007-11-12 7:57 ` Stefano Scipioni
2007-11-12 13:53 ` Axel Neumann
2007-11-12 14:00 ` Predrag Balorda
2007-11-12 17:13 ` [B.A.T.M.A.N.] batmand crash / core dump Axel Neumann
2007-11-24 13:02 ` Marek Lindner
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).