[B.A.T.M.A.N.] no gateway / tun interface / default route

[B.A.T.M.A.N.] no gateway / tun interface / default route

[Freifunk Dresden]

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

Re: [B.A.T.M.A.N.] no gateway / tun interface / default route

[Axel Neumann]

Hello

On Donnerstag 18 Oktober 2007, Freifunk Dresden wrote:
> 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

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. 
>
> 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? --------------------------
I dont know!
> 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!
Thats OK!

> kernel: bat0: Disabled Privacy Extensions
this message I dont know!

> 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:
This is usual as well, batmand is searching for an unused tunnel name.
>
> ip route
> 10.203.71.21 dev vpn1  proto kernel  scope link  src 10.203.71.22
> 10.203.71.0/24 via 10.203.71.21 dev vpn1
> 10.63.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
so you have some overlapping IP ranges?
> 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

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

>
> 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]

That looks good.
>      Gateway              Router (#/128)
> => 10.12.0.1             10.12.0.1 (123), gw_class 33 - 1024KBit/256KBit,
> reliability: 0
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

>
> But the ip route list table bat_default contains only a throw entry and not
> the default route. 
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. 
> ip addr lists the interfaces but always without an ip 
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.
> 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?
Probably not :-)
>
> 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?
??? Which tunnel has been removed by batman and when?
>
> 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.

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

ciao
/axel
>
> Has anyone an idea what I have done wrong.
>
> Regards
>  Stephan
>
>
>
>
> _______________________________________________
> 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

Re: [B.A.T.M.A.N.] no gateway / tun interface / default route

[Axel Neumann]

hi,

> > 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? --------------------------

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


regards,
axel

Re: [B.A.T.M.A.N.] no gateway / tun interface / default route

[Marek Lindner]

Hi,

> > 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? --------------------------
>
> I dont know!

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


> > 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:
>
> This is usual as well, batmand is searching for an unused tunnel name.

But unnecessary and confusing. These errors can be avoided.


> >      Gateway              Router (#/128)
> > => 10.12.0.1             10.12.0.1 (123), gw_class 33 - 1024KBit/256KBit,
> > reliability: 0
>
> 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

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 the ip route list table bat_default contains only a throw entry and
> > not the default route.
>
> 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.

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. 



> > :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.
>
> It really sounds your GW is not reachable. Check your ip rules and if
> ping 10.12.0.1
> works.

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

Regards,
Marek

Re: [B.A.T.M.A.N.] no gateway / tun interface / default route

[Freifunk Dresden]

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).

> > 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.
> >
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


> >
> > 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).
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:
>> >> 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
> >
> > 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 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).

> > 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.
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?

> > ??? Which tunnel has been removed by batman and when?
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

Re: [B.A.T.M.A.N.] no gateway / tun interface / default route

[Marek Lindner]

Hi,

> 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.

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.


> 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).
> 
> is the table 67 for?
> Are there now four routing tables?

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.


> 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?

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.


> 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?

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

Re: [B.A.T.M.A.N.] no gateway / tun interface / default route

[Freifunk Dresden]

Hi,

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

>> 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).
>>
>> is the table 67 for?
>> Are there now four routing tables?
> 
> Which documentation ? We should fix that.

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

Re: [B.A.T.M.A.N.] no gateway / tun interface / default route

[Axel Neumann]

Hello, 
> >> >> 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
> > >
> > > 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 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. 
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.

> 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.
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.


> 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).
What is the benifit of this NAT here?
> 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).

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

Re: [B.A.T.M.A.N.] no gateway / tun interface / default route

[Freifunk Dresden]

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).

>> 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.
> 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 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

Re: [B.A.T.M.A.N.] no gateway / tun interface / default route

[Axel Neumann]

Hello,

On Sonntag 21 Oktober 2007, Freifunk Dresden wrote:
> 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).
>
> >> 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.
> >
> > 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 can happen if I do the SNAT? 

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.

> I think that OGMs are not FORWARDED. 
Right! They are flooded by being re-broadcasted .
> 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 
(then batman would have to trac the MAC addresses, but it is IP based )
> to calulate the  routes (not the source ip).
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

>
> Bye Stephan
>
> _______________________________________________
> 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

Re: [B.A.T.M.A.N.] no gateway / tun interface / default route

[Freifunk Dresden]

Hi,

> 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. 
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.

>> 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 
> (then batman would have to trac the MAC addresses, but it is IP based )
>> to calulate the  routes (not the source ip).
> 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. 
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

Re: [B.A.T.M.A.N.] no gateway / tun interface / default route

[Axel Neumann]

On Sonntag 21 Oktober 2007, Freifunk Dresden wrote:
> Hi,
>
> > 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.
>
> 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.
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.

> 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.
>

On Sonntag 21 Oktober 2007, Freifunk Dresden wrote:
> 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

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

> >> 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
> >
> > (then batman would have to trac the MAC addresses, but it is IP based )
> >
> >> to calulate the  routes (not the source ip).
> >
> > 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.
>
> 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?
Yes
>
> 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?
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

>
> Bye Stephan
>
> _______________________________________________
> 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

Re: [B.A.T.M.A.N.] no gateway / tun interface / default route

[Freifunk Dresden]

Hi,

> > 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.
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.

> > 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).
To be sure, if I add /A behind bbs then no HNA is created for this interface ip?

Bye Stephan

Re: [B.A.T.M.A.N.] no gateway / tun interface / default route

[Axel Neumann]

Hello

On Donnerstag 25 Oktober 2007, Freifunk Dresden wrote:
>
> > > 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).
>
> To be sure, if I add /A behind bbs then no HNA is created for this
> interface ip?
correct!

ciao,
/axel

>
> Bye Stephan
>
> _______________________________________________
> 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