[Martin Visser <martinvisser99@xxxxxxxxx>]

Estanislao,

A couple of things:-

Whenver I hear about ICMP being blocked indiscriminately by security policy when an application has MTU issues then that is often an issue. ICMP is not a hacker tool, it is for Control and Management - block echos if you have must, but those in charge of security policy should leave networking to the experts ;-) Almost certainly if packets are being sent with a too large MTU and DF (Don't Fragment) being sent, at least one of your routers will be trying to tell you this.

Rather than do the wireshark capture on the server with the issue, setup port-mirroring on a switch and capture separately. That way you are not likely to have issue with way the driver might be presenting packets to wireshark. You really want to see what is being sent on the wire.

Regards, Martin

MartinVisser99@xxxxxxxxx

On Mon, Sep 27, 2010 at 5:40 PM, Estanislao Gonzalez <estanislao.gonzalez@xxxxxxx> wrote:

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