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