On Thursday 17 June 2010 10:44:59 Sven Eckelmann wrote:

Sounds a little bit like a device is configured wrong. Lets go through the devices:

Laptop:

• WiFi: MTU: 1500

Fonera:

• Incoming (to Laptop) WiFi: MTU 1500
• Outgoing (to Dir300) WiFi: MTU 1530
• Bridge (has bat0 and Incoming WiFi included): MTU 1500
• bat0 (has only Outgoing WiFi included): MTU 1500

Dir300:

• Incoming (to Fonera) WiFi: MTU 1530
• bat0 (only incoming device included): MTU 1500

This should work till Dir300. Now send 1500 Bytes large packets to each interesting partner (fonera, dir300) and check were it drops.

This can be done using `ping -M do -s 1472 $IP`.

If it works till dir300 and drops somewhere in the openvpn/virtual openwrt/internet connection then please check there. If it drops before then please check your configuration (running, not configuration files) and try to summarize those devices as I tried to do above.

How exactly is openvpn your connection to the internet configured? Do they work in an mode which adds extra headers? Do they fragment packets?

Best regards, Sven

Sry this should have been gone to the Batman list, so here it is again:

I did this and everything works fine till I try to connect over the vpn. So the vpn is the problem I think.

Here is some output of what I tried connecting over vpn:

[floh1111@flohdesktop ~]$ ping -M do -s 1467 10.18.1.1 PING 10.18.1.1 (10.18.1.1) 1467(1495) bytes of data. 1475 bytes from 10.18.1.1: icmp_seq=1 ttl=64 time=85.6 ms --> Works fine till package size 1467 or lower ---------- [floh1111@flohdesktop ~]$ ping -M do -s 1468 10.18.1.1 PING 10.18.1.1 (10.18.1.1) 1468(1496) bytes of data. --> Does not work with package size from 1468 to 1472, no error message ---------- [floh1111@flohdesktop ~]$ ping -M do -s 1473 10.18.1.1 PING 10.18.1.1 (10.18.1.1) 1473(1501) bytes of data. From 10.18.0.3 icmp_seq=1 Frag needed and DF set (mtu = 1500) --> Does not work too, but I get an error message trying package size 1473 or higher.

We are using OpenVPN in tap mode. Below is our server config: ---- mode server tls-server

port 1195 proto udp dev tap ca /etc/openvpn/ff/ca.crt cert /etc/openvpn/ff/ffsrv.crt key /etc/openvpn/ff/ffsrv.key # This file should be kept secret dh /etc/openvpn/dh1024.pem client-config-dir ccd client-to-client keepalive 10 120 comp-lzo max-clients 100 persist-key persist-tun status openvpn-status.log verb 3 -----

I don´t know if openvpn is adding some extra headers but maybe you know?

Thanks Clemens

On Thursday 17 June 2010 14:07:09 Linus Lüssing wrote:

Yep, tap mode in openvpn is adding an extra header, it encapsulates not only the ip-packet but also the ethernet frame into udp or tcp. (By the way, tun-mode also adds an extra header, but the packets are smaller - only IP packets encapsulated in UDP or TCP.)

May I ask whether you are bridging tap0 or if you are routing the packets (so having an ip address on tap0 and having according entries in your routing table)? If it's the latter, then you could just decrease the MTU on the tap0 interfaces to a fitting size and let the VPN routers do the PMTU discovery stuff automatically. But of course, then you probably wouldn't need tap-mode in this scenario, as it just adds additional overhead with the unnecessary ethernet frame in between.

I think we are bridging the VPN interface: root@OpenWrt:~# cat /etc/config/batman-adv-kernelland config batman-adv-kernelland general option interface 'ath1 tap0' option originator_interval option log_level

I know that tinc has two little, a bit hacky features in case of bridging tap0 with tap-mode (they call it switch-mode) to inform the other machines of the lower MTU in between. But I haven't heard of OpenVPN having similar features.

So I guess the easiest step would be the first suggestion, to do routing in between and lowering the MTU on the tap interfaces for a start before starting to experiment with (experimental) features and/or more complicated setups :).

So there is no "easy" or documented way how to do this with openvpn without routing? I would be happy if there is a way that is understandable.

If not, then I think the best way would be to try tinc.

Thanks Clemens

Hi Clemens,

wow, you're quick and eager, great spirit (woops, guess there is too much soccer talking around here during these days again :D)! Well, anyway, we'll get your setup fitting your needs, no worries :). Therefore, what are your plans for 20.00 tonight yet? It might be easier to discuss these things then via irc. Your goal might also not be 100% clear yet and from my guesses so far at least three possible ways come to my mind and others might have even different ideas for solutions :) (which are simpler than the ones I usually come up with :P). So chatting would be great to avoid misunderstandings. Marek and me and probably some more would be there then.

We tried tinc now, but the problem does still exist. Our Tinc config looks like this:

---

root@OpenWrt:~# cat /etc/tinc/batvpn/tinc.conf Hostnames=yes Mode=Switch name=floh1111 ConnectTo=batgw

#ConnectTo=harlingen

Normal ping over vpn till package size 1453 works. If I increase the package size to 1454 ping fails.

All devices have an mtu of 1530 except bat0 and br-mesh which have an mtu of 1500. Batman is running on the tinc device tap0 and our bridge looks like this:

---

config 'interface' 'mesh' option 'type' 'bridge' option 'ifname' 'ath0 bat0' option 'proto' 'static' option 'ipaddr' '10.18.1.101' option 'netmask' '255.255.128.0' option 'mtu' '1500' option 'dns' '10.18.0.1 10.18.0.254'

---

This feature of tinc only works on IP packets, not batman-adv ethernetframes. Sorry for not stating that before, thought you'd have a different / easier setup: sending ip packets over the vpn and just bridging the clients into the same subnet (so bridging ath0 + bat0 + tap0 and not adding tap0 into batman-adv). I think in version 1.0.12 of tinc, you also still had to enable PMTUDiscovery in the tinc.conf explicitly, also only 1.0.13 has a working implementation of the TCP mss tempering.

Anyway, this or your current setup, they both have pros and cons which we should talk about on irc, I guess :).

Cheers, Linus

If I decrease the mtu on the client that has no batman advanced to 1481, everything works fine.

Think we need help again^^ Clemens

On Thursday 17 June 2010 18:16:42 Clemens John wrote:

...

:). Therefore, what are your plans for 20.00 tonight yet?

Sry tonight I´m busy. But tomorrow same time?

Sure, tomorrow is fine as well.

Regards, Marek

Am Donnerstag 17 Juni 2010, 17:19:52 schrieb Linus Lüssing:

wow, you're quick and eager, great spirit (woops, guess there is too much soccer talking around here during these days again :D)! Well, anyway, we'll get your setup fitting your needs, no worries

:). Therefore, what are your plans for 20.00 tonight yet?

It might be easier to discuss these things then via irc. Your goal might also not be 100% clear yet and from my guesses so far at least three possible ways come to my mind and others might have even different ideas for solutions :) (which are simpler than the ones I usually come up with :P). So chatting would be great to avoid misunderstandings. Marek and me and probably some more would be there then.

Which IRC server and Channel do we meet?

Greetings Clemens

On Friday 18 June 2010 19:40:57 Clemens John wrote:

Am Donnerstag 17 Juni 2010, 17:19:52 schrieb Linus Lüssing:

...

wow, you're quick and eager, great spirit (woops, guess there is too much soccer talking around here during these days again :D)! Well, anyway, we'll get your setup fitting your needs, no worries

:). Therefore, what are your plans for 20.00 tonight yet?

It might be easier to discuss these things then via irc. Your goal might also not be 100% clear yet and from my guesses so far at least three possible ways come to my mind and others might have even different ideas for solutions :) (which are simpler than the ones I usually come up with :P). So chatting would be great to avoid misunderstandings. Marek and me and probably some more would be there then.

Which IRC server and Channel do we meet?

irc.freenode.net #batman

Best regards, Sven

On Fri, Jun 18, 2010 at 12:49:54PM +0200, Michael Rack wrote:

I've read the complete topic, but dont't know if your problem is solved.

You're right. The MTU is your Problem. And when i read your post, it was clear for me, that your problems results on your VPN Connection.

You need to do some MSS stuff on your OpenWRT Router.

/sbin/iptables -t mangle -A forward -i tap0 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1381:65535 -j TCPMSS --set-mss 1460 /sbin/iptables -t mangle -A forward -o tap0 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1381:65535 -j TCPMSS --set-mss 1460

Actually, this is pretty much what tinc is doing in switch mode with pmtu-discovery enabled in the config on tap0 automatically, dynamically - no need for iptables then. There are three problems with this: a) it only affects TCP and does not help with UDP yet (though tinc is desipte the mss tempering also faking "ICMP packet too big" messages). And b), I think he's bridging at the moment (though this needs to / should be clarified tonight) and not doing any routing over tap0, so simple iptables won't be enough for that. And c), I think at the moment he's not actually sending pure IP packets over tap0, so no tcp mss to temper with (again, should check that tonight and avoid playing ping pong with throwing guesses over the mailing list :) ).

Despite that, thanks for your suggestions (no offense ment :) ). I agree with you, it's definitely a MTU problem.

Cheers, Linus

And all your problems are gone :-D

Unfortunately, usually a little more tricky when dealing with layer 2 ;).

Liebe Grüße aus Freilassing,

Michael Rack RSM Freilassing -- RSM Freilassing Tel.: +49 8654 607110 Nocksteinstr. 13 Fax.: +49 8654 670438 D-83395 Freilassing www.rsm-freilassing.de

Am 17.06.2010 10:18, schrieb Clemens John:

...

Hi,

I have a problem to connect to the Internet. We are using Batman advanced 0.2.1 and IPv4 here in oldenburg. Our setup looks like this:

Laptop-[wifi]->Fonera-[wifi]->Dir300-->OpenVPN--> virtual OpenWrt machine-->internet.

The default route of the laptop goes to the virtual OpenWrt machine wich provides an Internet connection.

I can acces google (wget google.de) but not heise.de or golem.de. I´m not verry familar with network configurations but I heared that this might be an mtu problem.

All devices in the network (tap0, ath0, ath1, wifi0) have an mtu of 1524 except bat0 and br-mesh which have an mtu of 1500.

Our routers are configured to bridge connections from non batman devices (like the laptop) to bat0. This is done in the device "br-mesh".

Everythink works fine, except I can´t connect to internet websites that are not google.de.

When I decrease the mtu of the wireless device of the laptop to 1476 everything works fine. But I have to do this by hand and on a client this is bad.

Does anybody know what I´m doing wrong?

Greetings Clemens