Hi,
> I have solved my problem.
>
> It is related to the TCP checksum offload function: I am using as embedded
> platform PCEngines Alix 3d2, that do not support this function (and also
> qemu virtual machines do not support it).
>
> This patch disable the tx checksum offload and everything now
Hi,
> I have solved my problem.
>
> It is related to the TCP checksum offload function: I am using as embedded
> platform PCEngines Alix 3d2, that do not support this function (and also
> qemu virtual machines do not support it).
>
> This patch disable the tx checksum offload and everything now
Dear all,
I have solved my problem.
It is related to the TCP checksum offload function: I am using as embedded
platform PCEngines Alix 3d2, that do not support this function (and also
qemu virtual machines do not support it).
This patch disable the tx checksum offload and everything now works fi
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 chec
Dear Marek,
On Tue, Oct 6, 2009 at 2:55 PM, Marek Lindner 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
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
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 wrote:
> On Tue, Oct 06, 2009 at 01:11:00PM +0200, a wrot
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 n
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: mtu 1500 q
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.51 BAT 52:54:00:00:20:01 > 52:54:00:00:30:01: UCAST, ttl 50, IP
> 192.168.100.2
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: mtu 1476 qdisc pfifo_fast state
UNKNO
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.51 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.
Dear Andrew,
2009/10/6 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
> >
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 I
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 app
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,
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 --- EX
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: mtu 1500 qdisc pfifo_fast state
UNKNOWN qlen 1000
link/ether 52
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 "
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
>
> 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
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.
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.1
22 matches
Mail list logo