Hi Martin,
The funny thing is that it is not a VM. The real Problem is that we
are trying to setup a gridFTP transmission between Germany and UK (a
kind of parallel FTP), and at some point a package is lost. This
package is resent periodically, but the receiver never get's it.
Other packages sent afterward are received, it's just this
particular one that can't make it through (is not always the same
one, but once "missed", it can't get through again). It's like
something is inhibiting a package from being send more than once
(which makes no sense to me).
The first thing to notice is that the sender is behind a strict
firewall dropping ping ICMP packages (and possibly every other ICMP)
and we have different MTUs (9000 in Germany, 1500 in UK). I
suspected this might be related to fragmentation (all packages has
the don't fragment bit set), and the receiver not getting the proper
ICMP package, but this shouldn't happen in middle of the TCP
conversation but while setting it up (I think...)
Anyway, that's why I'd like to see exactly what happens on the
cable. This large packages are obviously not sent as this, but I've
already turned off segmentation on it (and tried turning every
offloading feature off). It doesn't matter, I still have large
packets with checksum errors (to note is that exactly those large
packets are the one with checksum errors, the others are just fine).
This is the only NIC installed, it appears though as it is not
honoring the system offloading properties.
I thought I might have missed some wireshark properties. I can't
find other explanation besides the NIC has to be configured in some
other way.
Thanks,
Estani
On 09/27/2010 04:31 AM, Martin Visser wrote:
The only thing I am wondering is whether you have
turned off "tcp
segmentation offload" at the physical level of the server, but
it is still on at the virtual machine guest level. (You haven't
said you are running in virtualised environment, but I had this
issue).
Do
you think this is causing a network operation issue, or is
just that wireshark isn't showing the data you expect?
Regards, Martin
MartinVisser99@xxxxxxxxx
On Fri, Sep 24, 2010 at 11:35 PM,
Estanislao Gonzalez <estanislao.gonzalez@xxxxxxx>
wrote:
Hi,
I've been reading a lot lately, but I still can't find the
source of my
problem.
For example this is a captured package at eth0:
6249 10.090368 remote.ip local.ip TCP
51402> 50383 [ACK] Seq=56628006 Ack=1578 Win=9216
Len=18824 TSV=240912663 TSER=21362093
These are the current settings:
# ethtool -k eth0
Offload parameters for eth0:
Cannot get device udp large send offload settings: Operation
not supported
rx-checksumming: on
tx-checksumming: on
scatter-gather: off
tcp segmentation offload: off
udp fragmentation offload: off
generic segmentation offload: off
generic-receive-offload: off
(I've already tried turning checksumming also off)
The TCP options are set to avoid reassembling streams and
not to
validate checksums.
If MTU is set to 9000 for the receiver, and 1500 for the
sender, why am
I still seeing large packages?
Any idea?
Thanks,
Estani
--
Estanislao Gonzalez
Max-Planck-Institut für Meteorologie (MPI-M)
Deutsches Klimarechenzentrum (DKRZ) - German Climate
Computing Centre
Room 108 - Bundesstrasse 45a, D-20146 Hamburg, Germany
Phone: +49 (40) 46 00 94-126
E-Mail: estanislao.gonzalez@xxxxxxx
___________________________________________________________________________
Sent via: Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
___________________________________________________________________________
Sent via: Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
--
Estanislao Gonzalez
Max-Planck-Institut für Meteorologie (MPI-M)
Deutsches Klimarechenzentrum (DKRZ) - German Climate Computing Centre
Room 108 - Bundesstrasse 45a, D-20146 Hamburg, Germany
Phone: +49 (40) 46 00 94-126
E-Mail: estanislao.gonzalez@xxxxxxx
|
