2007/11/10, Axel Neumann <axel(a)open-mesh.net>et>: No, I use master address 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?

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(a)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 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. does ping really not work? 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(a)open-mesh.net https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n

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

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:

Hi, On Sonntag 11 November 2007, Predrag Balorda wrote: 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 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

Hi, 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