From owner-freebsd-stable@FreeBSD.ORG  Wed Feb 13 10:30:03 2013
Return-Path: <owner-freebsd-stable@FreeBSD.ORG>
Delivered-To: freebsd-stable@freebsd.org
Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115])
 by hub.freebsd.org (Postfix) with ESMTP id 8411EC2F;
 Wed, 13 Feb 2013 10:30:03 +0000 (UTC)
 (envelope-from egrosbein@rdtc.ru)
Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5])
 by mx1.freebsd.org (Postfix) with ESMTP id 2E4B1974;
 Wed, 13 Feb 2013 10:30:02 +0000 (UTC)
Received: from eg.sd.rdtc.ru (localhost [127.0.0.1])
 by eg.sd.rdtc.ru (8.14.6/8.14.6) with ESMTP id r1DATwiP084062;
 Wed, 13 Feb 2013 17:29:59 +0700 (NOVT)
 (envelope-from egrosbein@rdtc.ru)
Message-ID: <511B6B21.5030606@rdtc.ru>
Date: Wed, 13 Feb 2013 17:29:53 +0700
From: Eugene Grosbein <egrosbein@rdtc.ru>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU;
 rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7
MIME-Version: 1.0
To: Doug Hardie <bc979@lafn.org>
Subject: Re: Unusual TCP/IP Packet Size
References: <96AE8BD1-79C2-4743-854F-B8386C54E4A1@lafn.org>
In-Reply-To: <96AE8BD1-79C2-4743-854F-B8386C54E4A1@lafn.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Cc: freebsd-stable@freebsd.org, yongari@freebsd.org
X-BeenThere: freebsd-stable@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Production branch of FreeBSD source code <freebsd-stable.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-stable>,
 <mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable>
List-Post: <mailto:freebsd-stable@freebsd.org>
List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
 <mailto:freebsd-stable-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Feb 2013 10:30:03 -0000

13.02.2013 17:25, Doug Hardie пишет:
> Monitoring a tcpdump between two systems, a FreeBSD 9.1 system has the following interface:
> 
> msk0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
> 	options=c011b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,TSO4,VLAN_HWTSO,LINKSTATE>
> 	ether 00:11:2f:2a:c7:03
> 	inet 10.0.1.199 netmask 0xffffff00 broadcast 10.0.1.255
> 	inet6 fe80::211:2fff:fe2a:c703%msk0 prefixlen 64 scopeid 0x1 
> 	nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
> 	media: Ethernet autoselect (100baseTX <full-duplex,flowcontrol,rxpause,txpause>)
> 	status: active
> 
> 
> It sent the following packet:  (data content abbreviated)
> 
> 02:14:42.081617 IP 10.0.1.199.443 > 10.0.1.2.61258: Flags [P.], seq 930:4876, ack 846, win 1040, options [nop,nop,TS val 401838072 ecr 920110183], length 3946
> 	0x0000:  4500 0f9e ea89 4000 4006 2a08 0a00 01c7  E.....@.@.*.....
> 	0x0010:  0a00 0102 01bb ef4a ece1 680b ae37 1bbc  .......J..h..7..
> 	0x0020:  8018 0410 3407 0000 0101 080a 17f3 8ff8  ....4...…….
> 
> 
> The indicated packet length is 3946 and the load of data shown is that size.  The MTU on both interfaces is 1500.  The receiving system received 3 packets.  There is a router and switch between them.  One of them fragmented that packet. This is part of a SSL/TLS exchange and one side or the other is hanging on this and just dropping the connection.  I suspect the packet size is the issue. ssldump complains about the packet too and stops monitoring.  Could this possibly be related to the hardware checksums?

You have TSO enabled on the interface, so large outgoing TCP packet is pretty normal.
It will be split by the NIC. Disable TSO with ifconfig if it interferes with your ssldump.

Eugene Grosbein