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,
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
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
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
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
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
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
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
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.dewrote:
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
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
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
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
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
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
Dear Marek,
On Tue, Oct 6, 2009 at 2:55 PM, Marek Lindner lindner_marek@yahoo.dewrote:
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
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.dewrote:
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
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.dewrote:
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
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
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
b.a.t.m.a.n@lists.open-mesh.org
-
a -
Andrea Ghittino
-
Andrew Lunn -
Marek Lindner -
Sven Eckelmann