Re: Large Packages although TSO is off

[Martin Visser <martinvisser99 () gmail com>]

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 () gmail com


On Mon, Sep 27, 2010 at 5:40 PM, Estanislao Gonzalez <
estanislao.gonzalez () zmaw de> 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 () gmail com
>
>
> On Fri, Sep 24, 2010 at 11:35 PM, Estanislao Gonzalez <
> estanislao.gonzalez () zmaw de> 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 () zmaw de
> >
> >
> > ___________________________________________________________________________
> > Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
> > Archives:    http://www.wireshark.org/lists/wireshark-users
> > Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
> >             mailto:wireshark-users-request () wireshark org
> > ?subject=unsubscribe
>
>
> ___________________________________________________________________________
> Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org> <wireshark-users () wireshark org>
> Archives:    http://www.wireshark.org/lists/wireshark-users
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
>              mailto:wireshark-users-request () wireshark org?subject=unsubscribe <wireshark-users-request () 
> wireshark org?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 () zmaw de
___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request () wireshark org?subject=unsubscribe