no gateway / tun interface / default route

Hello,

I have problems with the gateway. The following setup is used:

Laptop: batmand -g 1024/200 -a 104.61.0.0/16 -s 10.12.0.1 --no-unreachable-rule --no-throw-rules --no-prio-rules --no-unresp-gw-check --resist-blocked-send wlan0 bbs /t 1 /i bbc /t 1 /i
wrt54gs: batmand batmand -d 4 -r 2 --t 63 --no-unreachable-rule --no-throw-rules --no-prio-rules --no-unresp-gw-check --resist-blocked-send eth1 bbs /t 1 /i bbc /t 1 /i

The laptop uses a proxy (squid) to only allow some URLs. Also the firewall only allows some specific ip ranges. Does this have any influence for the gateway detection?
--------------------------
Laptop:Linux 0-1.ddmesh 2.6.22.1 #1 Tue Jul 17 23:43:32 CEST 2007 i686 GNU/Linux

During start the laptop produces the following syslog entries.

Oct 18 21:54:53 0-1 batmand[13603]: Warning - batgat kernel modul interface (/dev/batgat) not usable: No such file or directory This may decrease the performance of batman!
Oct 18 21:54:53 0-1 batmand[13603]: Warning - batgat kernel modul interface (/dev/batgat) not usable: No such file or directory This may decrease the performance of batman!
Oct 18 21:54:53 0-1 batmand[13603]: Trying to name tunnel to bat0 ...
Oct 18 21:54:53 0-1 kernel: bat0: Disabled Privacy Extensions
Oct 18 21:54:53 0-1 batmand[13603]: success!
Oct 18 21:54:53 0-1 batmand[13603]: Trying to name tunnel to bat0 ...
Oct 18 21:54:53 0-1 batmand[13603]: Warning - batgat kernel modul interface (/dev/batgat) not usable: No such file or directory This may decrease the performance of batman!
Oct 18 21:54:53 0-1 batmand[13603]: Trying to name tunnel to bat0 ...
Oct 18 21:54:53 0-1 batmand[13603]: Error - can't create tun device (TUNSETIFF): Device or resource busy
Oct 18 21:54:53 0-1 batmand[13603]: Trying to name tunnel to bat1 ...
Oct 18 21:54:53 0-1 kernel: bat1: Disabled Privacy Extensions
Oct 18 21:54:53 0-1 batmand[13603]: success!
Oct 18 21:54:53 0-1 batmand[13603]: Error - can't create tun device (TUNSETIFF): Device or resource busy
Oct 18 21:54:53 0-1 batmand[13603]: Trying to name tunnel to bat2 ...
Oct 18 21:54:53 0-1 kernel: bat2: Disabled Privacy Extensions
Oct 18 21:54:53 0-1 batmand[13603]: success!

I have running openvpn that also use some tun and tap devices (using kmod_tun). All tunnel interfaces that are using kmod_tun have names different to tunX. Only one interface is using tap0.

ip route
192.168.100.2 dev vpn3 proto kernel scope link src 192.168.100.1

10.203.71.21 dev vpn1  proto kernel  scope link  src 10.203.71.22
192.168.99.2 dev vpn2  proto kernel  scope link  src 192.168.99.1
192.168.100.0/24 via 192.168.100.2 dev vpn3
192.168.178.0/24 dev eth0  proto kernel  scope link  src 192.168.178.2
169.254.2.0/24 dev bat2  proto static
169.254.0.0/24 dev bat0  proto static
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.2
169.254.1.0/24 dev bat1  proto static
192.168.99.0/24 via 192.168.99.2 dev vpn2
10.203.71.0/24 via 10.203.71.21 dev vpn1
104.61.0.0/16 via 10.203.71.21 dev vpn1
172.16.0.0/16 dev bbs  proto kernel  scope link  src 172.16.0.1
172.16.0.0/16 dev bbc  proto kernel  scope link  src 172.16.0.2

10.63.0.0/16 via 10.203.71.21 dev vpn1 105.61.0.0/16 via 10.203.71.21 dev vpn1
10.0.0.0/8 dev wlan0 proto kernel scope link src 10.12.0.1 default via 192.168.178.1 dev eth0

0-1:/home/ffdevel/ff-build/open-mesh.net# ip route list table bat_route
10.12.10.1 dev wlan0  proto static  scope link  src 10.12.0.1
10.12.10.17 dev wlan0  proto static  scope link  src 10.12.0.1
throw 104.61.0.0/16  proto static

0-1:/home/ffdevel/ff-build/open-mesh.net# ip route list table bat_hna
10.12.10.0/28 via 10.12.10.1 dev wlan0  proto static
10.12.10.16/28 via 10.12.10.17 dev wlan0  proto static
throw 104.61.0.0/16  proto static

0-1:/home/ffdevel/ff-build/open-mesh.net# ip route list table bat_default
throw 104.61.0.0/16  proto static

B.A.T.M.A.N. 0.3-exp, MainIF/IP: wlan0 10.12.0.1, WindSize: 128, BLT: 2, OGI: 1000, UT: 0d 0h 2m

Originator           viaIF         Router (brc rcvd lseq lvld) [    viaIF RTQ  RQ  TQ].. alternatives...
10.12.10.1          wlan0      10.12.10.1 (126 128 39555    0) [    wlan0 118 127 118]         10.12.10.17 (  2)
10.12.10.17         wlan0     10.12.10.17 (128 128 49229    0) [    wlan0 123 128 123]

--------------------------
wrt54gs:

The wrt54gl shows always:
Gateway Router (#/128)
=> 10.12.0.1 10.12.0.1 (123), gw_class 33 - 1024KBit/256KBit, reliability: 0

But the ip route list table bat_default contains only a throw entry and not the default route. ip addr lists the interfaces but always without an ip address assigned.
The batman revision I use is the batman-experimental Rev724. also some revisions before have the same result.

Despite the presens of --no-throw-rules throw rules are added to the batman routing tables to throw the hna entries. Is this wanted?

In older version I got a tunnel but this has be removed by batman. Perhaps because the client didn't not use it to much?

If I try to add a tunnl manually (ip route add default dev bat0 table bat_default)
and try to ping an internet address the client logread shows :kern.err batmand[6649]: Error - can't receive ip from gateway: number of maximum retries reached

The manually added default route is removed after a while by batmand.

Has anyone an idea what I have done wrong.

Regards
Stephan

Hello

Generally you should announce the ip address of your non-primary interfaces (bbs and bbc) with HNA. Otherwise the traffic you generate on these nodes might leave the node with a source IP address which is simply not known beyond that link. If you really want to completely hide the IP addresses of bbs and bbc then you need to do NAT for all locally generated packets, except for the OGMs.

I dont know!

Thats OK!

this message I dont know!

This is usual as well, batmand is searching for an unused tunnel name.

so you have some overlapping IP ranges?

ip rule
would be also interesting. Since you have used the --no-prio-rules, have you manually configured a rule like
ip rule add pref 6600 from all to 10.0.0.0/8 t 66

Can you ping all the other mesh IPs, particulary the GW: 10.12.0.1

That looks good.

In the first place, this just indicated that the local batmand has decided for one of the available GWs. It does not necessarily mean, that the connection to that GW was successfull

There is no default route until the client has decided for a GW. After the startup, the daemon waits a while before it decides for a GW. This is done to gather some statistics about the available GWs.

The bat0 tunnel interface does not get an IP address until the client node sends some data over the tunnel. But if the GW is not reachable (see above) it can never get one.

Probably not :-)

??? Which tunnel has been removed by batman and when?

It really sounds your GW is not reachable. Check your ip rules and if ping 10.12.0.1
works.

ciao
/axel

hi,

You definitely need to configure your firewall to accept port 4306 for GW and 4307 for visualization support.

regards,
axel

Hi,

No. The gateway detection itself is only influenced by the batman originator packets.

But unnecessary and confusing. These errors can be avoided.

Correct. The connection to the gateway itself is triggered as soon as you begin to use the tunnel. This output shows you to which gateway the connection will be established (assuming that the gateway responds).

But his output shows that the client has selected a gateway. Therefore a default route should exist. I guess you just looked into the wrong table. I assume that "bat_default" is table 67 ?! The batman default route can be found in table 68.

This indicates that port 4306 is blocked at the gateway side. The client will ask for an IP an that port.

Regards,
Marek

Hi,

I have got it working and below I copy/paste some text from previous posts of Marek and Axel.

First the problem was the firewall. As you have mentioned you have been an official port number 4305 assigned. Looking into the port list batman uses only port 4305. This is why I have assumed that all packages (at least OGMs and GW) are using this port.

The second problem is that the documentation speeks about three routing tables 65,66,67 where table 67 is used for adding the gateway routes.
I haven't added a rule to this table 68 (see ip rule below).

When table 68 is the table that carries the default route to dev bat0, what is the table 67 for?
Are there now four routing tables?

Here are my ip rules just for info (table 68 the the "new" table):

root@10-2:~# ip rule
0:      from all lookup local
100:    from all lookup gateway
200:    from all to 192.168.0.0/16 lookup main
201:    from all to 169.254.0.0/16 lookup main
202:    from all to 10.255.255.255 lookup main
203:    from all to 10.12.10.16/28 lookup main
300:    from all lookup bat_route
301:    from all to 172.16.0.0/12 lookup main
302:    from all lookup bat_hna
303:    from all lookup bat_default
#after adding the next rule it is working
304:    from all lookup 68
32766:  from all lookup main
32767:  from all lookup default

#batman

65      bat_hna
66      bat_route
67      bat_default

For my understanding, when batman starts it collects packages to decide what gateway should be used. It then adds the default route via dev bat0 and establishes the tunnel via UDP to port 4306.
The connection should be independent of whether a client (pda connected to router or local process) tries to use to connect the internet. If no internet connection was used for weeks, batmand should always have the default route added. If batman removes this default route, because no traffic through the tunnel was present for a while, how does batman detect a client trying to make an internet connection later and add this default route again?
Perhaps I didn't get you right.

Axel:

I don't understand your idea.
Each node in the network has an official ip of the 10.0.0.0/8 network. If I use additional interfaces for backbone (bbs,bbc) these interfaces have there own ip range 172.16.0.0/12. if a node wants to connect a fare away node it will use the "official" ip address from 10.0.0.0/8 range. If the only connection is via bbs or bbc the packages are natted to 172.12.. Only the the routers that are connected directly via the backbone (bbc->bbs) should have routing entries of 172.16.0.0/12. All other nodes in the network do not need to know these addresses and therefore I don't HNA these.
This avoids filling up the routing tables with ip addresses that finally point to the same node.

A.eth1-A.bbc=====backbone=========B.bbs-B.eth1 -------------------C.eth1----------D.eth1
10...1 172...1 172...2 10...2 10...3 10...4

Node D with IP 10.12.0.4 can send packages to node 10.12.0.1
The package is NATed in node B to be send over backbone interface (bbs).
Node A receives this package with ip 172.12.0.1 and because node A has also an interface with ip 10.12.0.1 the package has reached the target specified by node D (target:10.12.0.1).

This only can be batman privat data that are sent over the tunnel, because a local process needs the routing entry (default route to dev bat0). Right?

I have tried to add the default route via dev bat0 to table 67 just to check if only the routing entry is missing. durning this tests, batman has removed this route from this table after about one minute.
But because it is working now (table 68 and missing to add a rule for this) it is obsolete.

Many thanks to you and you all do a very good job :) Stephan

Hi,

true, we got 4305 assigned. Due to the internal programm design we could not multiplex the the batman originator messages and gateway tunneling over one port without a major rewrite. That is why we "hijacked" 4306 and 4307. This may change with future releases (after 0.3).
Let me mention that we clearly stated that fact (from the release announcement):
Pay attention to the fact that all ports used by B.A.T.M.A.N. are changing:
4305 for OGMs, 4306 for the tunneling and 4307 for the vis server. Adjust your firewall settings if required.

Which documentation ? We should fix that.
Some time ago we had to redesign the policy routing because the kernel would parse the entries in the wrong order (which was our mistake). This layout change made another table neccessay. In table 67 you (normally) find the unreachable rule which you obviously deactivated. Just start batmand with full policy routing enabled and you will quickly understand the differences.

This happens:
1. batmand analyzes the OGMs, selects a gateway and sets a default route towards its tun device (batX/gateX)
2. batmand waits for traffic coming though the tun device
3. on the first packet batmand tries to connect to the gateway and demands an IP for the tun device
4. the tunnel is fully established and data can flow through
5. after a certain idle time the IP is removed from the tun device and batmand returns to step 2

The removal of the default route can only be triggered if the gateway does not hand out an IP or the blackhole detection is reacting. It also happens if you select -r 3 and a better gateway is found.

The default route must be always present so that every traffic can start this process. Otherwise batmand will never know about your requirement of an IP.

Regards,
Marek

Hi,

thanks for you quick answer and the explaination how the gateway-ing is working.

Please see bmx.pdf of batman-experimental chapter 4.1.2
and page 27 almost at the end of this page.
(https://www.open-mesh.net/batman/doc/BMX/bmx.pdf/view)
Also found at the html version at "Customizing the used routing table and priority rules" and batmand --dangerous -H

I'm using experimental revision 724.

Bye Stephan

Hello,

Ok if you can ensure this, then there is no problem. But how do you do that?

We observed nodes (also with multiple interfaces and hidden non-primary interfaces) where local application have chosen the ip address of a non-primary interface as the source address for its outgoing traffic. From my understanding, the default behavior of most applications is to always use the IP address of the interface via which a packet is routed out, as the source address of an outgoing packet. So in case you send a ping to a node to which batmand has decided to route via your bbs device, the ping packet should by default have the IP address of this bbs device. If the destination node of the ping is link-local for the bbs device, then this is no problem because all link-local neighbors of bbs have learned about the IP address of the bbs device. But if the final destination of the ping packet is more than one hop away, then the destination node does not know anything about the IP address of bbs unless it has been announced with HNA.

How could any non-neighboring node respond to a packet with a 172.12.. source address?
I would say you better NAT to the IP addresses of your 10.10.0.0/8 because these are the addresses known by any node. But be careful not to NAT any OGMs and any forwarded traffic.

What is the benifit of this NAT here?

Yes I understand that that works from D to A. But does it also work with a ping send from node A to node D? The source address of the ping request would be 172.12.0.1 and when it finally arrives at node D, the receiver does not know how to reply!

ciao,
axel

Hello,

If I use SNAT to change the source address, all other nodes know where to send the ping answers:

The Ip of the wlan is 10.12.0.1
the ip of bbs is 172.16.0.1
iptables -t nat -I POSTROUTING -o bbs -j SNAT --to 10.12.0.1

A.eth1-A.bbc=====backbone=========B.bbs-B.eth1 -------------------C.eth1----------D.eth1
10...1 172...1 172...2 10...2 10...3 10...4

Sendint from A to D is not a problem, all packages the have the ip 172... as source address will be assigned the new 10er IP. Node B,C and D will send answer back to the 10er IP. Node B has a route to A over backbone (bbs).

What can happen if I do the SNAT? I think that OGMs are not FORWARDED. They only go OUT or come IN. because batmand does not use the iptable roles it does not know about the change of the source address.
The OGMs are generated for the original interface ip. OGMs that A sends to B will be received via WLAN and also via BBS. When I understand batmand right it uses the interface where the OGMs are comming from to calulate the routes (not the source ip).

Bye Stephan

Hello,

If you NAT any forwarded traffic, the source address of related packets is changed :-) Batmand supports asymmetric routing. That means the packets may be routed another way back than they have come. By doing NAT on the forwarded traffic within the mesh you may force packets to also pass along the NATting interface on their way back. But thats not very beautiful. And I am not shure about further side effects.
Anyway, forwarded packets will not show any traces from your hidden backbone node. They will be passed along with source and destination addresses in the 10.10.0.0/8 range.

Right! They are flooded by being re-broadcasted .

(then batman would have to trac the MAC addresses, but it is IP based )

NO! Batman uses the source IP of each received OGM to identify if the OGM has been received
- directly from the originator interface or
- from another intermediate interface.
This is important for many internal mechanisms.

ciao,
/axel

Hi,

Hmm... I'm still confused. For instance I have interface bbs with ip 172.0.0.1 and an interface wlan with ip 10.0.0.1
If I ping a node behind the bbs interface the package will be created with ip 172.0.0.1. The SNAT of the initiating node will change this to 10.0.0.1. The next node will receive this package through its bbs interface but sends the answer back to tho the node with ip 10.0.0.1. The outgoing interface is determind by the routing table of the second node. This means that asymetric routing is still possible. Because the routing entries that batman creates in the second node the package goes over bbs or wlan back to the first node.
But I see the point that batman internals may be disturbed when I change this source ip for batman packets. See next comment.

If I mark the batman udp packets for the port (4305) and only SNAT all other packages then batman should be working as designed, isn't it?

You said before that OGMs are not forwarded. So I can setup a firewall rule to avoid forwarding the port 4305. The ports 4306 and 4307 still must be forwarded. Is this right?

Bye Stephan

its still possible but with limitations.
Consider another setup where the path A - B - C _ D - E is just one of many possible paths between A and E. Now the link C _ D is such a "hidden link" and nodes C and D are NATting all packets traveling along. Then, when E receives a packet from A which has passed along ABCDE the source address of that packet indicates that it came from B and not from A. The batmand on E might have choosen a totally different route back from E to A (e.g. E-J-B-A) but because the source address of the packet shows Cs IP it must be routed back along C.

Yes this way it should work (assuming you care for your OGMs) But i still suggest something like:

iptables -t nat -A POSTROUTING -o bbs -s 172.16.0.1/32 -p UDP --sport 4305 --dport 4305 -j ACCEPT # rule must be processed before the next one iptables -t nat -A POSTROUTING -o bbs -s 172.16.0.1/32 -j SNAT --to 10.12.0.1

Yes

That should be no problem !

by the way. Since batmand-exp rv 730 the parametrization of --bmx-defaults is now enabled by default (it detects much better routes). This parametrization automatically hides all non-primary interfaces and announces them as HNA. You can revert the HNA announcements for a interface with the interface specific /A switch (since revision 747).

If you really want to stick to the behavior of BATMAN-III (batmand-0.2) then use the --generation-III directive as the first parameter.

See batmand --dangerous for short help.

Also thanks for the hints regarding the documentation of used routing tables.

ciao
/axel

Hi,

Only packages for the bbs/bbc interface and 172er ips are considered. This is the same as you have already mentioned.
If I SNAT also the OGMs (4305) routing is completely dead.

To be sure, if I add /A behind bbs then no HNA is created for this interface ip?

Bye Stephan

Hello

correct!

ciao,
/axel