On Friday 02 April 2010 08:52:29 Linus Lüssing wrote:

Hi Floh1111,

Welcome to the B.A.T.M.A.N. mailing list :).

Thank you :)

On Fri, Apr 02, 2010 at 12:54:02AM +0200, Clemens John wrote:

...

Hi,

I use batman advanced ("# batctl o" says "B.A.T.M.A.N. adv 0.2.1-beta r1578") on OpenWrt trunk and I have the following problem:

I have a wlan meshnetwork in ahdemo mode which uses batman. The meshnetwork is used by clients without batman and therefore I have another network on the same wifi device in ad mode which is bridged with bat0. The bridge is in the network 10.18.1.0/24.

I think its like described in http://www.open-mesh.org/wiki/batman-adv-quick- start-guide

Yes, this configuration looks quite good already if I didn't miss anything and if you're having wifi cards with an atheros chip. What kind of devices are you using?

I use Fonera and Dlink Dir300 wich have a atheros chip inside.

...

The problem is, that I have a vpn network on tap0 (10.18.0.0/24) and I dont know how I can link this two networks/interfaces to each other with batman. I tried to assign tap0 to batman, but this doesnt work.

I want to be able to ping hosts that uses batman in the vpn and in the wlan network. How can I do this?

Ok, now I have some more questions already :). What do you want to gain with this vpn exactly, merging a couple of mesh clouds or getting the network behind the vpn into the mesh? What is creating this vpn right now, how are the two sites connected with each other (over network identified with 'lan' I guess?). Does pinging inside of the vpn itself without any mesh work?

Yes the vpn network is created over lan. The VPN is created by an central openvpn server in tap mode and ping inside the vpn works without batman. The VPN is used to connect several mesh clouds which can´t sea each other wireless. Ping from one Mesh device to another meshdevice on the other side of the vpn tunnel works. I think because they are both in the 10.18.1.0/24 network.

But the devices which are connected to the vpn network have a ip from 10.18.0.0/24 and should also be reachable from the 10.18.1.0/24 (wlan) network and this doesnt work so far. I can ping the mac adresses inside the vpn from the wlan network with batctl but not with normal ipv4 ping.

From the configuration now, it looks like you're having another batman-adv on the other side of the vpn as you've assigned tap0 to batman. So keep in mind that the recipient on the other side of the tunnel will get batman-adv ethernet frames only which encapsulate the payload - there has to be a batman-adv on the other side to unwrap the IP packets again. And if there is a batman-adv on the other side of the tunnel, make sure the vpn itself is transporting whole ethernet frames and not only ip packets (in tinc this is "switched" mode for instance or in OpenVPN having "dev tap" and not "dev tun").

Yes the setup is like you describe it.

I just give you an output of my devices on a Dir300 connected to vpn and wlan. Maybe this can be usefull for you.

root@OpenWrt:~# ifconfig ath0 Link encap:Ethernet HWaddr 00:24:01:17:B7:55 inet6 addr: fe80::224:1ff:fe17:b755/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:367 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 B) TX bytes:25573 (24.9 KiB)

ath1 Link encap:Ethernet HWaddr 06:24:01:17:B7:55 inet6 addr: fe80::424:1ff:fe17:b755/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:4979 errors:0 dropped:85 overruns:0 frame:0 TX packets:2736 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:359248 (350.8 KiB) TX bytes:224416 (219.1 KiB)

bat0 Link encap:Ethernet HWaddr 3A:53:93:D9:7D:15 inet6 addr: fe80::3853:93ff:fed9:7d15/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1476 Metric:1 RX packets:586 errors:0 dropped:0 overruns:0 frame:0 TX packets:168 errors:0 dropped:15 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:34784 (33.9 KiB) TX bytes:27239 (26.6 KiB)

br-mesh Link encap:Ethernet HWaddr 00:24:01:17:B7:55 inet addr:10.18.1.101 Bcast:10.18.1.255 Mask:255.255.255.0 inet6 addr: fe80::bca2:f0ff:fe00:96c8/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:586 errors:0 dropped:0 overruns:0 frame:0 TX packets:176 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:34784 (33.9 KiB) TX bytes:28219 (27.5 KiB)

eth0 Link encap:Ethernet HWaddr 00:24:01:17:B7:56 inet addr:192.168.178.59 Bcast:192.168.178.255 Mask:255.255.255.0 inet6 addr: fe80::224:1ff:fe17:b756/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:12931 errors:0 dropped:0 overruns:0 frame:0 TX packets:3442 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1952051 (1.8 MiB) TX bytes:454599 (443.9 KiB) Interrupt:4 Base address:0x1000

lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:4 errors:0 dropped:0 overruns:0 frame:0 TX packets:4 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:486 (486.0 B) TX bytes:486 (486.0 B)

tap0 Link encap:Ethernet HWaddr 8E:61:AE:E8:03:4A inet addr:10.18.0.8 Bcast:10.18.0.255 Mask:255.255.255.0 inet6 addr: fe80::8c61:aeff:fee8:34a/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:11484 errors:0 dropped:0 overruns:0 frame:0 TX packets:2232 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:726488 (709.4 KiB) TX bytes:164026 (160.1 KiB)

wifi0 Link encap:UNSPEC HWaddr 00-24-01-17- B7-55-00-00-00-00-00-00-00-00-00-00 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:13256 errors:0 dropped:0 overruns:0 frame:197 TX packets:3131 errors:8 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:195 RX bytes:1887585 (1.7 MiB) TX bytes:321699 (314.1 KiB) Interrupt:3 Memory:b0000000-b000ffff

...

My configs look like this:

---

/etc/conf/network

config 'interface' 'loopback'

    option 'ifname' 'lo'
    option 'proto' 'static'
    option 'ipaddr' '127.0.0.1'
    option 'netmask' '255.0.0.0'

config 'interface' 'lan'

    option 'proto' 'dhcp'
    option 'ifname' 'eth0'

config 'interface' 'mesh'

    option 'type' 'bridge'
    option 'ifname' 'ath0 bat0'
    option 'proto' 'static'
    option 'ipaddr' '10.18.1.101'
    option 'netmask' '255.255.255.0'

config 'interface' 'vpn'

    option 'proto' 'none'
    option 'ifname' 'tap0'

---

/etc/conf/wireless

config wifi-device wifi0

    option type     atheros
    option channel  6

config wifi-iface

    option device   wifi0
    option mode     ahdemo
    option bssid    02:CA:FF:EE:BA:BE

config wifi-iface

    option device   wifi0
    option mode     ap
    option ssid     oldenburg.freifunk.net

---

/etc/conf/batman-adv-kernelland

config batman-adv-kernelland general

    option interface                'ath1 tap0'
    option originator_interval
    option log_level

thanks Floh1111

On Friday 02 April 2010 13:50:32 Linus Lüssing wrote:

...

I use Fonera and Dlink Dir300 wich have a atheros chip inside.

Ah, great, those Dlink routers are the ones I'm using here too :).

hehe

...

Yes the vpn network is created over lan. The VPN is created by an central openvpn server in tap mode and ping inside the vpn works without batman. The VPN is used to connect several mesh clouds which can´t sea each other wireless. Ping from one Mesh device to another meshdevice on the other side of the vpn tunnel works. I think because they are both in the 10.18.1.0/24 network.

But the devices which are connected to the vpn network have a ip from 10.18.0.0/24 and should also be reachable from the 10.18.1.0/24 (wlan) network and this doesnt work so far.

Yes, you're right, if a host has a /24 subnet and wants to be able to reach another host on a different /24 subnet, then they need an extra (default) route entry in their routing table. In your setup, why aren't you just using a /16 subnet instead if you want them to reach each other over direct links without any routing?

I don´t exactly know why we are using different subnets, because I´m not verry familiar with networks. But I think it is, because we have different projects in our network with different vpn/24 subnets and wlan/24 subnets which should all be able to be connected to a bigger network. Olsr did this routing entrys by default I think. What can I do to make batman do this automatically too or is this just completely the wrong way?

How are you doing this and how is this done in other networks?

...

I can ping the mac adresses inside the vpn from the wlan network with batctl but not with normal ipv4 ping.

...

From the configuration now, it looks like you're having another batman-adv on the other side of the vpn as you've assigned tap0 to batman. So keep in mind that the recipient on the other side of the tunnel will get batman-adv ethernet frames only which encapsulate the payload - there has to be a batman-adv on the other side to unwrap the IP packets again. And if there is a batman-adv on the other side of the tunnel, make sure the vpn itself is transporting whole ethernet frames and not only ip packets (in tinc this is "switched" mode for instance or in OpenVPN having "dev tap" and not "dev tun").

Yes the setup is like you describe it.

Ups, ok, sooo, you want the complex stuff :)? Just want to note, that this has not extensively been tested yet, I had just tried it here with a friend and this test for one tunnel worked unexpectetly good. However, we don't know yet if there might occure some undesired things in larger scales. But if you are up to an adventure and want to share your experiences with this, great :).

I think I'll better write a little description and article in our wiki about how our test setup looks like as there seem to be some more people getting interested in it.

It would be great if you would send me the link when the article is ready.

And I also want to point out, that establishing such vpn inter cloud links with the routers themselves has the following downside: With tinc + those DIR300 routers, we measured a maximum total throughput of 300kB/s which might be or might not be what you are looking for. This is because VPN software is copying the data from kernel to userspace and back a couple of times. Haven't measured anything with OpenVPN though, but as far as I know they are also doing this copying (there is no kernel module for OpenVPN afaik).

Cheers, Linus

Tanks, Floh1111

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Hi,

I have been reading the other mails but I don't fully understand what you are trying to achieve here. Nevertheless, I'll try to write something. If I got it all wrong, please let me know. :-)

Thanks :)

It is important to keep in mind that IP addresses are totally irrelevant to make this setup work. I mention this since you seem to have experience with layer 3 routing. Even if the tap interfaces had no IP addresses batman-adv would route the traffic through. Unless you need to access services on the VPN interfaces via IPs you can safely run them without.

We have a openvpn with tap running to connect our clouds.

If you IP networks don't share the same broadcast domain (e.g. 10.18.1.0/24 vs 10.18.0.0/24) batman-adv won't propate IP routing entries because it assumes that is what you want. To resolve this you have 2 choices:

The easy way: Move all nodes into the same broadcast domain. All nodes will be able to communicate with each other without problems. Disadvantage: If you have many nodes (100+) in close range it will create considerable (ethernet) broadcast overhead.

100+? It would be just nice if we would have 10 ;) We had the /16-setup running with olsrd with a big overhead.

The routing way: Let your VPN nodes know how to reach to "other" IP networks by adding routing entries. Naturally, this will reduce the broadcast overhead but requires a mechanism to distribute the routes (as batman-adv won't do it for you). There a couple of standard ways you can choose from. Depending on your setup & needs one or the other might be more interesting to use which brings us back to my initial question. :-)

Which ways are you thinking of?

Our initial problem is: - - several node-clouds, connected via openvpn - - these nodes also use the vpn as a gateway in the world wide web - - the gateway also monitores the nodes, so it must be able to access the nodes, but it runs in openvz VE, so the kernelland-module is not usable

tia bjo

On Saturday 03 April 2010 06:54:02 Marek Lindner wrote:

Ok, since your setup is rather small I would suggest going with the easiest solution possible. I'm always a big fan of making little steps that work well instead of aiming for the big goal which you never reach because you die in the process of getting there.

In a classical batman-adv setup the router(s) with the internet connection run a DHCP server and provide IPs/default route/etc for all the nodes & wifi- clients in range.

To connect the VPNs I see 2 feasible approaches:

• You run batman-adv over the VPN which will bring some overhead since the

routing messages will be relayed over the VPN. Depending on the number of nodes this may or may not be an issue. To keep things simple all nodes run in the same IP address space.

We decided to keep it simple for testing. We changed the netmasks of all ip adresses (VPN and Wifi) from /24 to /16 but it doesnt work.

I can see all Nodes with # batctl o

but not with ping.

------------- root@OpenWrt:~# cat /etc/config/network config 'interface' 'loopback' option 'ifname' 'lo' option 'proto' 'static' option 'ipaddr' '127.0.0.1' option 'netmask' '255.0.0.0'

config 'interface' 'lan' option 'proto' 'dhcp' option 'ifname' 'eth0'

config 'interface' 'mesh' option 'type' 'bridge' option 'ifname' 'ath0 bat0' option 'proto' 'static' option 'ipaddr' '10.18.1.1' option 'netmask' '255.255.0.0'

------------- root@OpenWrt:~# ifconfig ath0 Link encap:Ethernet HWaddr 00:24:01:17:B7:55 inet6 addr: fe80::224:1ff:fe17:b755/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:28 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 B) TX bytes:2324 (2.2 KiB)

ath1 Link encap:Ethernet HWaddr 06:24:01:17:B7:55 inet6 addr: fe80::424:1ff:fe17:b755/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:580 errors:0 dropped:18 overruns:0 frame:0 TX packets:337 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:18512 (18.0 KiB) TX bytes:17574 (17.1 KiB)

bat0 Link encap:Ethernet HWaddr 9A:14:E1:3B:F4:88 inet6 addr: fe80::9814:e1ff:fe3b:f488/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1476 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:16 errors:0 dropped:16 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:944 (944.0 B)

br-mesh Link encap:Ethernet HWaddr 00:24:01:17:B7:55 inet addr:10.18.1.101 Bcast:10.18.255.255 Mask:255.255.0.0 inet6 addr: fe80::ec23:2fff:fe06:37f3/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:25 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 B) TX bytes:2034 (1.9 KiB)

eth0 Link encap:Ethernet HWaddr 00:24:01:17:B7:56 inet addr:192.168.178.59 Bcast:192.168.178.255 Mask:255.255.255.0 inet6 addr: fe80::224:1ff:fe17:b756/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:3782 errors:0 dropped:0 overruns:0 frame:0 TX packets:791 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:533232 (520.7 KiB) TX bytes:93762 (91.5 KiB) Interrupt:4 Base address:0x1000

lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:19 errors:0 dropped:0 overruns:0 frame:0 TX packets:19 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:1958 (1.9 KiB) TX bytes:1958 (1.9 KiB)

tap0 Link encap:Ethernet HWaddr 42:49:50:CF:69:3E inet addr:10.18.0.8 Bcast:10.18.255.255 Mask:255.255.0.0 inet6 addr: fe80::4049:50ff:fecf:693e/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:402 errors:0 dropped:0 overruns:0 frame:0 TX packets:4 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:31752 (31.0 KiB) TX bytes:368 (368.0 B)

wifi0 Link encap:UNSPEC HWaddr 00-24-01-17- B7-55-00-00-00-00-00-00-00-00-00-00 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:5172 errors:0 dropped:0 overruns:0 frame:424 TX packets:374 errors:1 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:195 RX bytes:716632 (699.8 KiB) TX bytes:29035 (28.3 KiB) Interrupt:3 Memory:b0000000-b000ffff

------------- root@OpenWrt:~# route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.178.0 * 255.255.255.0 U 0 0 0 eth0 10.18.0.0 * 255.255.0.0 U 0 0 0 br-mesh 10.18.0.0 * 255.255.0.0 U 0 0 0 tap0 default 192.168.178.1 0.0.0.0 UG 0 0 0 eth0

------------- root@OpenWrt:~# traceroute 10.18.0.3 traceroute to 10.18.0.3 (10.18.0.3), 30 hops max, 38 byte packets 1 10.18.1.101 (10.18.1.101) 3002.434 ms !H 3010.472 ms !H 3009.891 ms !H

10.18.0.3 is a vpn node (tap0) and running batman-adv but traceroute thinks, that it can be connected on the mesh-bridge???

I can´t figure out his problem. Hopefully someone of you can help me.

Greetings Floh1111