Date: Wed, 13 Feb 2013 13:57:38 -0800 From: Doug Hardie <bc979@lafn.org> To: Eugene Grosbein <egrosbein@rdtc.ru> Cc: freebsd-stable@freebsd.org, yongari@freebsd.org Subject: Re: Unusual TCP/IP Packet Size Message-ID: <796949D9-C945-478F-BF63-A5C0BC0CF6A9@lafn.org> In-Reply-To: <511B6B21.5030606@rdtc.ru> References: <96AE8BD1-79C2-4743-854F-B8386C54E4A1@lafn.org> <511B6B21.5030606@rdtc.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On 13 February 2013, at 02:29, Eugene Grosbein <egrosbein@rdtc.ru> = wrote: > 13.02.2013 17:25, Doug Hardie =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >> Monitoring a tcpdump between two systems, a FreeBSD 9.1 system has = the following interface: >>=20 >> msk0: flags=3D8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 = mtu 1500 >> = options=3Dc011b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,TSO4,VLAN_HWTSO,LINK= STATE> >> 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=20 >> nd6 options=3D29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> >> media: Ethernet autoselect (100baseTX = <full-duplex,flowcontrol,rxpause,txpause>) >> status: active >>=20 >>=20 >> It sent the following packet: (data content abbreviated) >>=20 >> 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...=E2=80=A6=E2=80=A6. >>=20 >>=20 >> 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? >=20 > 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. Thanks. Now all the packets are 1500 or under. They all are received = with a SSL header.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?796949D9-C945-478F-BF63-A5C0BC0CF6A9>