[B.A.T.M.A.N.] batman-adv and TCP problem

[B.A.T.M.A.N.] batman-adv and TCP problem

[Andrea Ghittino]

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

Dear all,

I'm testing batman-adv in this scenario:

B1 -- GW -- EX

- B1 has only one interface (eth0) managed by batman
- GW has two interfaces: eth0, managed by batman and eth1
- EX has only one interface not managed by batman.

IP addresses:
- B1 - bat0: 192.168.10.1/24 - default gateway: 192.168.10.2
- GW: bat0: 192.168.10.2/24, eth1: 192.168.20.2/24
- EX: eth0: 192.168.20.3/24 - default gateway: 192.168.20.3

The three nodes are based on OpenWRT with kernel 2.6.28.10, but I have also
repeated the test using a Ubuntu 9.04 PC.

The IP connectivity is ok and I can ping from B1 to EX and vice versa.
I have installed a tcp echo server on the three nodes and it works between
B1-GW and GW-EX, but I have problem with B1-EX test.
B1 correctly receives data from EX, but EX application doesn’t receive data
from B1. I repeated the test without batman and everything works fine.
Do you have any suggestion?
Regards,

[-- Attachment #2: Type: text/html, Size: 1162 bytes --]

Re: [B.A.T.M.A.N.] batman-adv and TCP problem

[Marek Lindner]

Hi,

> The IP connectivity is ok and I can ping from B1 to EX and vice versa.
> I have installed a tcp echo server on the three nodes and it works between
> B1-GW and GW-EX, but I have problem with B1-EX test.
> B1 correctly receives data from EX, but EX application doesn’t receive data
> from B1. I repeated the test without batman and everything works fine.
> Do you have any suggestion?

could be a MTU problem. Does a big packet size ping work ?

Regards,
Marek

Re: [B.A.T.M.A.N.] batman-adv and TCP problem

[a]

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

No,

it is not a MTU problem. TCP packet are small (I'm sending only few
characters) and big packet size (1400 byte) ping works



2009/10/5 Marek Lindner <lindner_marek@yahoo.de>

>
> Hi,
>
> > The IP connectivity is ok and I can ping from B1 to EX and vice versa.
> > I have installed a tcp echo server on the three nodes and it works
> between
> > B1-GW and GW-EX, but I have problem with B1-EX test.
> > B1 correctly receives data from EX, but EX application doesn’t receive
> data
> > from B1. I repeated the test without batman and everything works fine.
> > Do you have any suggestion?
>
> could be a MTU problem. Does a big packet size ping work ?
>
> Regards,
> Marek
> _______________________________________________
> B.A.T.M.A.N mailing list
> B.A.T.M.A.N@lists.open-mesh.net
> https://lists.open-mesh.net/mm/listinfo/b.a.t.m.a.n
>

[-- Attachment #2: Type: text/html, Size: 1349 bytes --]

Re: [B.A.T.M.A.N.] batman-adv and TCP problem

[Marek Lindner]

On Monday 05 October 2009 20:12:20 a wrote:
> No,
> 
> it is not a MTU problem. TCP packet are small (I'm sending only few
> characters) and big packet size (1400 byte) ping works

The limit on ethernet is 1500 bytes - please try that.
If that still works you should log the traffic on the GW with "batctl td" to see 
what your packets are doing. Feel free to post the log here if you need help.

Regards,
Marek

Re: [B.A.T.M.A.N.] batman-adv and TCP problem

[a]

[-- Attachment #1.1: Type: text/plain, Size: 4810 bytes --]

Dear Marek,

The ping with 1500 byte packets works.

The three nodes are connected in this way:
B1 --- batman --- GW1 ------- EX1
eth1 on B1 and GW1 is managed by batman. eth2 on gw1 not.
The IP configuration is:

B1:
# ip a
eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state
UNKNOWN qlen 1000
    link/ether 52:54:00:00:20:01 brd ff:ff:ff:ff:ff:ff
bat0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1476 qdisc pfifo_fast state
UNKNOWN qlen 1000
    link/ether 00:ff:ad:e2:6f:dd brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.2/24 brd 192.168.100.255 scope global bat0
# ip r
192.168.100.0/24 dev bat0  proto kernel  scope link  src 192.168.100.2
default via 192.168.100.3 dev bat0

GW1;
# ip a
eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state
UNKNOWN qlen 1000
    link/ether 52:54:00:00:30:01 brd ff:ff:ff:ff:ff:ff
eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state
UNKNOWN qlen 1000
    link/ether 52:54:00:00:30:02 brd ff:ff:ff:ff:ff:ff
    inet 192.168.20.3/24 brd 192.168.20.255 scope global eth2
bat0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1476 qdisc pfifo_fast state
UNKNOWN qlen 1000
    link/ether 00:ff:15:c2:d0:73 brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.3/24 brd 192.168.100.255 scope global bat0
# ip r
192.168.100.0/24 dev bat0  proto kernel  scope link  src 192.168.100.3
192.168.20.0/24 dev eth2  proto kernel  scope link  src 192.168.20.3

EX1:
# ip a
bat0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 00:ff:a1:ff:bb:32 brd ff:ff:ff:ff:ff:ff
eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state
UNKNOWN qlen 1000
    link/ether 52:54:00:00:40:01 brd ff:ff:ff:ff:ff:ff
    inet 192.168.20.4/24 brd 192.168.20.255 scope global eth1
# ip r
192.168.20.0/24 dev eth1  proto kernel  scope link  src 192.168.20.4
default via 192.168.20.3 dev eth1

I repeated the TCP test between B1 (server) and EX1 (client); the dump on B1
is:

20:04:28.900000 BAT 52:54:00:00:30:01 > 52:54:00:00:20:01: UCAST, ttl 50, IP
192.168.20.4.39127 > 192.168.100.2.8001: TCP, flags [.S....], length 12
20:04:28.910000 BAT 52:54:00:00:20:01 > 52:54:00:00:30:01: UCAST, ttl 50, IP
192.168.100.2.8001 > 192.168.20.4.39127: TCP, flags [.S..A.], length 12
20:04:28.920000 BAT 52:54:00:00:30:01 > 52:54:00:00:20:01: UCAST, ttl 50, IP
192.168.20.4.39127 > 192.168.100.2.8001: TCP, flags [....A.], length 0
20:04:29.820000 BAT 52:54:00:00:30:01 > 52:54:00:00:20:01: UCAST, ttl 50, IP
192.168.20.4.39127 > 192.168.100.2.8001: TCP, flags [...PA.], length 4
20:04:29.830000 BAT 52:54:00:00:20:01 > 52:54:00:00:30:01: UCAST, ttl 50, IP
192.168.100.2.8001 > 192.168.20.4.39127: TCP, flags [....A.], length 0
20:04:29.830000 BAT 52:54:00:00:20:01 > 52:54:00:00:30:01: UCAST, ttl 50, IP
192.168.100.2.8001 > 192.168.20.4.39127: TCP, flags [...PA.], length 6
20:04:29.830000 BAT 52:54:00:00:20:01 > 52:54:00:00:30:01: UCAST, ttl 50, IP
192.168.100.2.8001 > 192.168.20.4.39127: TCP, flags [F...A.], length 0
20:04:29.850000 BAT 52:54:00:00:30:01 > 52:54:00:00:20:01: UCAST, ttl 50, IP
192.168.20.4.39127 > 192.168.100.2.8001: TCP, flags [....A.], length 12
20:04:32.830000 BAT 52:54:00:00:20:01 > 52:54:00:00:30:01: UCAST, ttl 50, IP
192.168.100.2.8001 > 192.168.20.4.39127: TCP, flags [...PA.], length 6
20:04:38.830000 BAT 52:54:00:00:20:01 > 52:54:00:00:30:01: UCAST, ttl 50, IP
192.168.100.2.8001 > 192.168.20.4.39127: TCP, flags [...PA.], length 6
20:04:42.290000 BAT 52:54:00:00:30:01 > 52:54:00:00:20:01: UCAST, ttl 50, IP
192.168.20.4.39127 > 192.168.100.2.8001: TCP, flags [F...A.], length 12
20:04:42.290000 BAT 52:54:00:00:20:01 > 52:54:00:00:30:01: UCAST, ttl 50, IP
192.168.100.2.8001 > 192.168.20.4.39127: TCP, flags [....A.], length 0


and you can find as attachment problem.cap, that contains the dump on EX1.
As you can see, packets arrive to EX1, but it seems that the application
doesn't recognize them and B1 sends it again! (I ended the communication
closing server application).

I have repeated the test without batman and everything works fine (ok.cap is
the dump on EX1 in this case).
A question: am I the first one with this problem?
thanks

andrea

2009/10/5 Marek Lindner <lindner_marek@yahoo.de>

> On Monday 05 October 2009 20:12:20 a wrote:
> > No,
> >
> > it is not a MTU problem. TCP packet are small (I'm sending only few
> > characters) and big packet size (1400 byte) ping works
>
> The limit on ethernet is 1500 bytes - please try that.
> If that still works you should log the traffic on the GW with "batctl td"
> to see
> what your packets are doing. Feel free to post the log here if you need
> help.
>
> Regards,
> Marek
> _______________________________________________
> B.A.T.M.A.N mailing list
> B.A.T.M.A.N@lists.open-mesh.net
> https://lists.open-mesh.net/mm/listinfo/b.a.t.m.a.n
>

[-- Attachment #1.2: Type: text/html, Size: 6004 bytes --]

[-- Attachment #2: problem.cap --]
[-- Type: application/cap, Size: 1114 bytes --]

[-- Attachment #3: ok.cap --]
[-- Type: application/cap, Size: 752 bytes --]

Re: [B.A.T.M.A.N.] batman-adv and TCP problem

[Sven Eckelmann]

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

a wrote:
> The ping with 1500 byte packets works.
How can you send 1500 bytes packets with an mtu of 1476?
Do the test with `ping -M do -s 1472 IP` (this should create an 1500 bytes 
packet and disables fragmentation).

> The three nodes are connected in this way:
> B1 --- batman --- GW1 ------- EX1
> eth1 on B1 and GW1 is managed by batman. eth2 on gw1 not.
> The IP configuration is:
> 
> B1:
> # ip a
> eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state
> UNKNOWN qlen 1000
>     link/ether 52:54:00:00:20:01 brd ff:ff:ff:ff:ff:ff
> bat0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1476 qdisc pfifo_fast state
> UNKNOWN qlen 1000
>     link/ether 00:ff:ad:e2:6f:dd brd ff:ff:ff:ff:ff:ff
>     inet 192.168.100.2/24 brd 192.168.100.255 scope global bat0
> # ip r
> 192.168.100.0/24 dev bat0  proto kernel  scope link  src 192.168.100.2
> default via 192.168.100.3 dev bat0

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.] batman-adv and TCP problem

[a]

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

It is correct. I'm using openwrt and, at the moment, without -M option.
1500byte packets work, with fragmentation.
However, my TCP packets are small (about 60bytes). I have verified TCPDump
file and packets arrive. It seems that the Linux IP stack does not forward
them to the application.
Moreover, if I disable batman on B1-GW1 link, it works

andrea

2009/10/5 Sven Eckelmann <sven.eckelmann@gmx.de>

> a wrote:
> > The ping with 1500 byte packets works.
> How can you send 1500 bytes packets with an mtu of 1476?
> Do the test with `ping -M do -s 1472 IP` (this should create an 1500 bytes
> packet and disables fragmentation).
>
> > The three nodes are connected in this way:
> > B1 --- batman --- GW1 ------- EX1
> > eth1 on B1 and GW1 is managed by batman. eth2 on gw1 not.
> > The IP configuration is:
> >
> > B1:
> > # ip a
> > eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state
> > UNKNOWN qlen 1000
> >     link/ether 52:54:00:00:20:01 brd ff:ff:ff:ff:ff:ff
> > bat0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1476 qdisc pfifo_fast state
> > UNKNOWN qlen 1000
> >     link/ether 00:ff:ad:e2:6f:dd brd ff:ff:ff:ff:ff:ff
> >     inet 192.168.100.2/24 brd 192.168.100.255 scope global bat0
> > # ip r
> > 192.168.100.0/24 dev bat0  proto kernel  scope link  src 192.168.100.2
> > default via 192.168.100.3 dev bat0
>
> Best regards,
>         Sven
>

[-- Attachment #2: Type: text/html, Size: 1976 bytes --]

Re: [B.A.T.M.A.N.] batman-adv and TCP problem

[Sven Eckelmann]

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

a wrote:
> It is correct. I'm using openwrt and, at the moment, without -M option.
> 1500byte packets work, with fragmentation.
> However, my TCP packets are small (about 60bytes). I have verified TCPDump
> file and packets arrive. It seems that the Linux IP stack does not forward
> them to the application.
> Moreover, if I disable batman on B1-GW1 link, it works
So it would be a good idea to do what Marek said. Give him a dump with `batctl 
td` on the gateway and if I could add something: complete tcpdump of both ends 
so we can see what packets receive on both sites.

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.] batman-adv and TCP problem

[a]

[-- Attachment #1.1: Type: text/plain, Size: 2498 bytes --]

Dear Sven, Marek

you can find as attachment the dump on eth2 of GW (tcpdump -ni eth2 -s 0 -w
gw.cap);
the output of batctl td -p 4 eth1 is:

10:29:15.510000 BAT 52:54:00:00:20:01 > 52:54:00:00:30:01: UCAST, ttl 50, IP
192.168.100.2.9001 > 192.168.20.4.45417: TCP, flags [...PA.], length 6
10:29:18.000000 BAT 52:54:00:00:30:01 > 52:54:00:00:20:01: UCAST, ttl 50, IP
192.168.20.4.38246 > 192.168.100.2.9002: TCP, flags [.S....], length 12
10:29:18.010000 BAT 52:54:00:00:20:01 > 52:54:00:00:30:01: UCAST, ttl 50, IP
192.168.100.2.9002 > 192.168.20.4.38246: TCP, flags [.S..A.], length 12
10:29:18.020000 BAT 52:54:00:00:30:01 > 52:54:00:00:20:01: UCAST, ttl 50, IP
192.168.20.4.38246 > 192.168.100.2.9002: TCP, flags [....A.], length 0
10:29:18.970000 BAT 52:54:00:00:30:01 > 52:54:00:00:20:01: UCAST, ttl 50, IP
192.168.20.4.38246 > 192.168.100.2.9002: TCP, flags [...PA.], length 5
10:29:18.980000 BAT 52:54:00:00:20:01 > 52:54:00:00:30:01: UCAST, ttl 50, IP
192.168.100.2.9002 > 192.168.20.4.38246: TCP, flags [....A.], length 0
10:29:18.990000 BAT 52:54:00:00:20:01 > 52:54:00:00:30:01: UCAST, ttl 50, IP
192.168.100.2.9002 > 192.168.20.4.38246: TCP, flags [...PA.], length 6
10:29:18.990000 BAT 52:54:00:00:20:01 > 52:54:00:00:30:01: UCAST, ttl 50, IP
192.168.100.2.9002 > 192.168.20.4.38246: TCP, flags [F...A.], length 0
10:29:19.000000 BAT 52:54:00:00:30:01 > 52:54:00:00:20:01: UCAST, ttl 50, IP
192.168.20.4.38246 > 192.168.100.2.9002: TCP, flags [....A.], length 12
10:29:21.970000 BAT 52:54:00:00:20:01 > 52:54:00:00:30:01: UCAST, ttl 50, IP
192.168.100.2.9002 > 192.168.20.4.38246: TCP, flags [...PA.], length 6
10:29:27.950000 BAT 52:54:00:00:20:01 > 52:54:00:00:30:01: UCAST, ttl 50, IP
192.168.100.2.9002 > 192.168.20.4.38246: TCP, flags [...PA.], length 6

andrea

On Tue, Oct 6, 2009 at 11:43 AM, Sven Eckelmann <sven.eckelmann@gmx.de>wrote:

> a wrote:
> > It is correct. I'm using openwrt and, at the moment, without -M option.
> > 1500byte packets work, with fragmentation.
> > However, my TCP packets are small (about 60bytes). I have verified
> TCPDump
> > file and packets arrive. It seems that the Linux IP stack does not
> forward
> > them to the application.
> > Moreover, if I disable batman on B1-GW1 link, it works
> So it would be a good idea to do what Marek said. Give him a dump with
> `batctl
> td` on the gateway and if I could add something: complete tcpdump of both
> ends
> so we can see what packets receive on both sites.
>
> Best regards,
>         Sven
>

[-- Attachment #1.2: Type: text/html, Size: 2993 bytes --]

[-- Attachment #2: gw.cap --]
[-- Type: application/cap, Size: 866 bytes --]

Re: [B.A.T.M.A.N.] batman-adv and TCP problem

[Andrew Lunn]

On Tue, Oct 06, 2009 at 12:33:55PM +0200, a wrote:
> Dear Sven, Marek
> 
> you can find as attachment the dump on eth2 of GW (tcpdump -ni eth2 -s 0 -w
> gw.cap);
> the output of batctl td -p 4 eth1 is:
> 
> 10:29:15.510000 BAT 52:54:00:00:20:01 > 52:54:00:00:30:01: UCAST, ttl 50, IP
> 192.168.100.2.9001 > 192.168.20.4.45417: TCP, flags [...PA.], length 6

192.168.100.2->192.168.20.4

> 10:29:18.000000 BAT 52:54:00:00:30:01 > 52:54:00:00:20:01: UCAST, ttl 50, IP
> 192.168.20.4.38246 > 192.168.100.2.9002: TCP, flags [.S....], length 12

192.168.20.4->192.168.100.2

> 10:29:18.010000 BAT 52:54:00:00:20:01 > 52:54:00:00:30:01: UCAST, ttl 50, IP
> 192.168.100.2.9002 > 192.168.20.4.38246: TCP, flags [.S..A.], length 12

192.168.100.2-> 192.168.20.4

However you said:

> IP addresses:
> - B1 - bat0: 192.168.10.1/24 - default gateway: 192.168.10.2
> - GW: bat0: 192.168.10.2/24, eth1: 192.168.20.2/24
> - EX: eth0: 192.168.20.3/24 - default gateway: 192.168.20.3

i.e, none of these IP addresses match!

Maybe you should give us all the networking details. 

      Andrew

Re: [B.A.T.M.A.N.] batman-adv and TCP problem

[a]

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

Dear Andrew,

I have sent yesterday night the IP configuration that I am using for the
test; I send it again

The three nodes are connected in this way:
B1 --- batman --- GW1 ------- EX1
eth1 on B1 and GW1 is managed by batman. eth2 on gw1 not.
The IP configuration is:

B1:
# ip a
eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state
UNKNOWN qlen 1000
    link/ether 52:54:00:00:20:01 brd ff:ff:ff:ff:ff:ff
bat0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1476 qdisc pfifo_fast state
UNKNOWN qlen 1000
    link/ether 00:ff:ad:e2:6f:dd brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.2/24 brd 192.168.100.255 scope global bat0
# ip r
192.168.100.0/24 dev bat0  proto kernel  scope link  src 192.168.100.2
default via 192.168.100.3 dev bat0

GW1;
# ip a
eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state
UNKNOWN qlen 1000
    link/ether 52:54:00:00:30:01 brd ff:ff:ff:ff:ff:ff
eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state
UNKNOWN qlen 1000
    link/ether 52:54:00:00:30:02 brd ff:ff:ff:ff:ff:ff
    inet 192.168.20.3/24 brd 192.168.20.255 scope global eth2
bat0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1476 qdisc pfifo_fast state
UNKNOWN qlen 1000
    link/ether 00:ff:15:c2:d0:73 brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.3/24 brd 192.168.100.255 scope global bat0
# ip r
192.168.100.0/24 dev bat0  proto kernel  scope link  src 192.168.100.3
192.168.20.0/24 dev eth2  proto kernel  scope link  src 192.168.20.3

EX1:
# ip a
bat0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 00:ff:a1:ff:bb:32 brd ff:ff:ff:ff:ff:ff
eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state
UNKNOWN qlen 1000
    link/ether 52:54:00:00:40:01 brd ff:ff:ff:ff:ff:ff
    inet 192.168.20.4/24 brd 192.168.20.255 scope global eth1
# ip r
192.168.20.0/24 dev eth1  proto kernel  scope link  src 192.168.20.4
default via 192.168.20.3 dev eth1


On Tue, Oct 6, 2009 at 12:54 PM, Andrew Lunn <andrew@lunn.ch> wrote:

> On Tue, Oct 06, 2009 at 12:33:55PM +0200, a wrote:
> > Dear Sven, Marek
> >
> > you can find as attachment the dump on eth2 of GW (tcpdump -ni eth2 -s 0
> -w
> > gw.cap);
> > the output of batctl td -p 4 eth1 is:
> >
> > 10:29:15.510000 BAT 52:54:00:00:20:01 > 52:54:00:00:30:01: UCAST, ttl 50,
> IP
> > 192.168.100.2.9001 > 192.168.20.4.45417: TCP, flags [...PA.], length 6
>
> 192.168.100.2->192.168.20.4
>
> > 10:29:18.000000 BAT 52:54:00:00:30:01 > 52:54:00:00:20:01: UCAST, ttl 50,
> IP
> > 192.168.20.4.38246 > 192.168.100.2.9002: TCP, flags [.S....], length 12
>
> 192.168.20.4->192.168.100.2
>
> > 10:29:18.010000 BAT 52:54:00:00:20:01 > 52:54:00:00:30:01: UCAST, ttl 50,
> IP
> > 192.168.100.2.9002 > 192.168.20.4.38246: TCP, flags [.S..A.], length 12
>
> 192.168.100.2-> 192.168.20.4
>
> However you said:
>
> > IP addresses:
> > - B1 - bat0: 192.168.10.1/24 - default gateway: 192.168.10.2
> > - GW: bat0: 192.168.10.2/24, eth1: 192.168.20.2/24
> > - EX: eth0: 192.168.20.3/24 - default gateway: 192.168.20.3
>
> i.e, none of these IP addresses match!
>
> Maybe you should give us all the networking details.
>
>      Andrew
> _______________________________________________
> B.A.T.M.A.N mailing list
> B.A.T.M.A.N@lists.open-mesh.net
> https://lists.open-mesh.net/mm/listinfo/b.a.t.m.a.n
>

[-- Attachment #2: Type: text/html, Size: 4895 bytes --]

Re: [B.A.T.M.A.N.] batman-adv and TCP problem

[Andrew Lunn]

On Tue, Oct 06, 2009 at 01:11:00PM +0200, a wrote:
> Dear Andrew,
> 
> I have sent yesterday night the IP configuration that I am using for the
> test; I send it again

Ah, sorry. I was looking at your first email. 
https://lists.open-mesh.net/pipermail/b.a.t.m.a.n/2009-October/001795.html

I had not noticed you now have a completely different IP address
scheme.

Why did you change?

    Andrew

Re: [B.A.T.M.A.N.] batman-adv and TCP problem

[a]

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

When I found the problem I have created a dedicated test bed, with the first
IP address schema; then, I come back to my original test bed with the IP
that you have seen in the last email

andrea

On Tue, Oct 6, 2009 at 1:19 PM, Andrew Lunn <andrew@lunn.ch> wrote:

> On Tue, Oct 06, 2009 at 01:11:00PM +0200, a wrote:
> > Dear Andrew,
> >
> > I have sent yesterday night the IP configuration that I am using for the
> > test; I send it again
>
> Ah, sorry. I was looking at your first email.
> https://lists.open-mesh.net/pipermail/b.a.t.m.a.n/2009-October/001795.html
>
> I had not noticed you now have a completely different IP address
> scheme.
>
> Why did you change?
>
>    Andrew
> _______________________________________________
> B.A.T.M.A.N mailing list
> B.A.T.M.A.N@lists.open-mesh.net
> https://lists.open-mesh.net/mm/listinfo/b.a.t.m.a.n
>

[-- Attachment #2: Type: text/html, Size: 1493 bytes --]

Re: [B.A.T.M.A.N.] batman-adv and TCP problem

[Marek Lindner]

Hi,

> you can find as attachment the dump on eth2 of GW (tcpdump -ni eth2 -s 0 -w
> gw.cap);
> the output of batctl td -p 4 eth1 is:

I could not find anything revealing in the logs you provided. Could you please 
follow Sven's suggestion to log both ends as well ?

Just to not forget the obvious:
* What batman-adv version are you running ?
* GW1 routes the packets - does this work via NAT or do you manually add 
routing entries to both ends ?


> A question: am I the first one with this problem?

AFAIK batman-adv has no problem transporting TCP traffic (unless you found an 
undiscovered bug nobody has seen before). The most common source of trouble is 
the configuration of the setup, in particular MTU settings or routing issues 
(which is why most people simply bridge).

Regards,
Marek

Re: [B.A.T.M.A.N.] batman-adv and TCP problem

[a]

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

Dear Marek,

On Tue, Oct 6, 2009 at 2:55 PM, Marek Lindner <lindner_marek@yahoo.de>wrote:

>
> Hi,
>
> > you can find as attachment the dump on eth2 of GW (tcpdump -ni eth2 -s 0
> -w
> > gw.cap);
> > the output of batctl td -p 4 eth1 is:
>
> I could not find anything revealing in the logs you provided. Could you
> please
> follow Sven's suggestion to log both ends as well ?
>
> I could log on every interface; I will do it and send .cap files.


> Just to not forget the obvious:
> * What batman-adv version are you running ?
>
revision 1439


> * GW1 routes the packets - does this work via NAT or do you manually add
>
GW1 routes packets, without NAT


> routing entries to both ends ?
>
>
> > A question: am I the first one with this problem?
>
> AFAIK batman-adv has no problem transporting TCP traffic (unless you found
> an
> undiscovered bug nobody has seen before). The most common source of trouble
> is
> the configuration of the setup, in particular MTU settings or routing
> issues
> (which is why most people simply bridge).
>

I understand your point about batman-adv; also for me, among batman nodes
everything works fine.
I will also test the system with bridge on GW


andrea

>
> Regards,
> Marek
> _______________________________________________
> B.A.T.M.A.N mailing list
> B.A.T.M.A.N@lists.open-mesh.net
> https://lists.open-mesh.net/mm/listinfo/b.a.t.m.a.n
>

[-- Attachment #2: Type: text/html, Size: 2642 bytes --]

Re: [B.A.T.M.A.N.] batman-adv and TCP problem

[a]

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

Dear all,

analyzing in deep the problem I have seen that the problem is the checksum:
as you can see in my previous .cap file, the packets with data from
192.168.100.2 have a wrong checksum (and my nodes are not using the HW
checksum offload function)
Then, I’m starting to investigate how the checksum is calculated. If you
have any suggestion or comment, you are welcome!

andrea




On Tue, Oct 6, 2009 at 3:14 PM, a <a.mailevent@gmail.com> wrote:

> Dear Marek,
>
> On Tue, Oct 6, 2009 at 2:55 PM, Marek Lindner <lindner_marek@yahoo.de>wrote:
>
>>
>> Hi,
>>
>> > you can find as attachment the dump on eth2 of GW (tcpdump -ni eth2 -s 0
>> -w
>> > gw.cap);
>> > the output of batctl td -p 4 eth1 is:
>>
>> I could not find anything revealing in the logs you provided. Could you
>> please
>> follow Sven's suggestion to log both ends as well ?
>>
>> I could log on every interface; I will do it and send .cap files.
>
>
>> Just to not forget the obvious:
>> * What batman-adv version are you running ?
>>
> revision 1439
>
>
>> * GW1 routes the packets - does this work via NAT or do you manually add
>>
> GW1 routes packets, without NAT
>
>
>> routing entries to both ends ?
>>
>>
>> > A question: am I the first one with this problem?
>>
>> AFAIK batman-adv has no problem transporting TCP traffic (unless you found
>> an
>> undiscovered bug nobody has seen before). The most common source of
>> trouble is
>> the configuration of the setup, in particular MTU settings or routing
>> issues
>> (which is why most people simply bridge).
>>
>
> I understand your point about batman-adv; also for me, among batman nodes
> everything works fine.
> I will also test the system with bridge on GW
>
>
> andrea
>
>>
>> Regards,
>> Marek
>> _______________________________________________
>> B.A.T.M.A.N mailing list
>> B.A.T.M.A.N@lists.open-mesh.net
>> https://lists.open-mesh.net/mm/listinfo/b.a.t.m.a.n
>>
>
>

[-- Attachment #2: Type: text/html, Size: 3530 bytes --]

Re: [B.A.T.M.A.N.] batman-adv and TCP problem

[a]

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

I also tested ping with -M option, from B1 to GW1:
ping -M do -s 1448 192.168.20.4

It works up to 1448 bytes, then starting from 1549 I receive the error
"From 192.168.100.2 icmp_seq=1 Frag needed and DF set (mtu = 1476)"

And my bat0 configuration is:

bat0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1476 qdisc pfifo_fast state
UNKNOWN qlen 1000


andrea

On Tue, Oct 6, 2009 at 11:43 AM, Sven Eckelmann <sven.eckelmann@gmx.de>wrote:

> a wrote:
> > It is correct. I'm using openwrt and, at the moment, without -M option.
> > 1500byte packets work, with fragmentation.
> > However, my TCP packets are small (about 60bytes). I have verified
> TCPDump
> > file and packets arrive. It seems that the Linux IP stack does not
> forward
> > them to the application.
> > Moreover, if I disable batman on B1-GW1 link, it works
> So it would be a good idea to do what Marek said. Give him a dump with
> `batctl
> td` on the gateway and if I could add something: complete tcpdump of both
> ends
> so we can see what packets receive on both sites.
>
> Best regards,
>         Sven
>

[-- Attachment #2: Type: text/html, Size: 1488 bytes --]

Re: [B.A.T.M.A.N.] batman-adv and TCP problem

[Andrew Lunn]

On Tue, Oct 06, 2009 at 11:26:01AM +0200, a wrote:
> It is correct. I'm using openwrt and, at the moment, without -M option.
> 1500byte packets work, with fragmentation.
> However, my TCP packets are small (about 60bytes). I have verified TCPDump
> file and packets arrive. It seems that the Linux IP stack does not forward
> them to the application.

Going back to your first email:

- B1 - bat0: 192.168.10.1/24 - default gateway: 192.168.10.2
- GW: bat0: 192.168.10.2/24,   eth1: 192.168.20.2/24
- EX: eth0: 192.168.20.3/24 - default gateway: 192.168.20.3

You default GW on EX does not make sense. You cannot use yourself as a
default gateway. It needs to be a remote device. In this case, EXs
default gateway should point to 192.168.20.2.

However, you say ping works, so that does not explain your problem.

Check your firewall rules. 

iptable -L

maybe one of the rules is causing the kernel to drop the packets.

      Andrew

Re: [B.A.T.M.A.N.] batman-adv and TCP problem

[a]

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

Dear Andrew,

2009/10/6 Andrew Lunn <andrew@lunn.ch>

> On Tue, Oct 06, 2009 at 11:26:01AM +0200, a wrote:
> > It is correct. I'm using openwrt and, at the moment, without -M option.
> > 1500byte packets work, with fragmentation.
> > However, my TCP packets are small (about 60bytes). I have verified
> TCPDump
> > file and packets arrive. It seems that the Linux IP stack does not
> forward
> > them to the application.
>
> Going back to your first email:
>
> - B1 - bat0: 192.168.10.1/24 - default gateway: 192.168.10.2
> - GW: bat0: 192.168.10.2/24,   eth1: 192.168.20.2/24
> - EX: eth0: 192.168.20.3/24 - default gateway: 192.168.20.3
>
> You default GW on EX does not make sense. You cannot use yourself as a
> default gateway. It needs to be a remote device. In this case, EXs
> default gateway should point to 192.168.20.2.
>
You are right. The gateway is 192.168.20.2


>
> However, you say ping works, so that does not explain your problem.
>
> Check your firewall rules.
>
> iptable -L
>
Checked; the ouput is the some for the three nodes:

 # iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

>
> maybe one of the rules is causing the kernel to drop the packets.
>


>      Andrew
> _______________________________________________
> B.A.T.M.A.N mailing list
> B.A.T.M.A.N@lists.open-mesh.net
> https://lists.open-mesh.net/mm/listinfo/b.a.t.m.a.n
>

[-- Attachment #2: Type: text/html, Size: 2929 bytes --]