[B.A.T.M.A.N.] MTU/connection problem

[B.A.T.M.A.N.] MTU/connection problem

[Clemens John]

[-- Attachment #1: Type: text/plain, Size: 1107 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [B.A.T.M.A.N.] MTU/connection problem

[Sven Eckelmann]

[-- Attachment #1: Type: Text/Plain, Size: 2223 bytes --]

Clemens John wrote:
> 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?

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [B.A.T.M.A.N.] MTU/connection problem

[Clemens John]

[-- Attachment #1: Type: Text/Plain, Size: 2646 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [B.A.T.M.A.N.] MTU/connection problem

[Linus Lüssing]

Hi Clemens,

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

Cheers, Linus
> 
> Thanks
> Clemens

Re: [B.A.T.M.A.N.] MTU/connection problem

[Clemens John]

[-- Attachment #1: Type: Text/Plain, Size: 1821 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [B.A.T.M.A.N.] MTU/connection problem

[Clemens John]

[-- Attachment #1: Type: Text/Plain, Size: 2336 bytes --]

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 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 :).
> 
> Cheers, Linus

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

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

Think we need help again^^
Clemens

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [B.A.T.M.A.N.] MTU/connection problem

[Linus Lüssing]

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

Re: [B.A.T.M.A.N.] MTU/connection problem

[Clemens John]

[-- Attachment #1: Type: Text/Plain, Size: 418 bytes --]

On Thursday 17 June 2010 17:19:52 Linus Lüssing wrote:
> 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?

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

Greetings
Clemens

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [B.A.T.M.A.N.] MTU/connection problem

[Marek Lindner]

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

Re: [B.A.T.M.A.N.] MTU/connection problem

[Linus Lüssing]

On Thu, Jun 17, 2010 at 08:43:59PM +0200, Marek Lindner wrote:
> 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.
Same for me, cya tonight :).

Cheers, Linus

Re: [B.A.T.M.A.N.] MTU/connection problem

[Michael Rack]

  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

And all your problems are gone :-D

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

Re: [B.A.T.M.A.N.] MTU/connection problem

[Linus Lüssing]

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
> 

Re: [B.A.T.M.A.N.] MTU/connection problem

[Clemens John]

[-- Attachment #1: Type: Text/Plain, Size: 829 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [B.A.T.M.A.N.] MTU/connection problem

[Marek Lindner]

On Friday 18 June 2010 19:40:57 Clemens John wrote:
> Which IRC server and Channel do we meet?

http://www.open-mesh.org/wiki/IRC

Cheers,
Marek

Re: [B.A.T.M.A.N.] MTU/connection problem

[Sven Eckelmann]

[-- Attachment #1: Type: Text/Plain, Size: 942 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]