Date: Fri, 20 Aug 2004 12:05:25 -0700 From: "David W. Hankins" <David_Hankins@isc.org> To: current@freebsd.org Subject: on amd64 tcp4 cksums are bad (FYI) Message-ID: <20040820190525.GA21626@isc.org>
next in thread | raw e-mail | index | archive | help
--vtzGhvizbBRQ85DL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable When connecting to remote hosts via tcp6, all is good: =3D=3D=3D 11:46:01.279473 [server].ssh > [client].59270: P [tcp sum ok] 1:52(51) ack = 1 win 58548 <nop,nop,timestamp 127298059 86994545> [flowlabel 0x2fb65] (len= 83, hlim 64) 11:46:01.280145 [client].59270 > [server].ssh: P [tcp sum ok] 1:52(51) ack = 52 win 32844 <nop,nop,timestamp 86994564 127298059> [flowlabel 0x6f2c8] (le= n 83, hlim 64) =3D=3D=3D When connecting to the same host from the same client just via tcp4, all is not quite so good: =3D=3D=3D 11:46:06.667847 IP (tos 0x0, ttl 64, id 62863, offset 0, flags [DF], lengt= h: 1148) [server].ssh > [client].59540: P [tcp sum ok] 3924:5020(1096) ack = 4132 win 57920 <nop,nop,timestamp 127303449 87000040> 11:46:06.668774 IP (tos 0x0, ttl 64, id 1465, offset 0, flags [DF], length= : 156) [client].59540 > [server].ssh: P [bad tcp cksum 100e (->fe32)!] 4132= :4236(104) ack 5020 win 33304 <nop,nop,timestamp 87000083 127303449> =3D=3D=3D This is as observed via tcpdump on [client], which is what is producing the bad checksums. Obviously it doesn't cause a problem since no one listens to TCP checksums, but it's interesting. I only noticed it because I was tcpdump'ing for completely unrelated reasons, and it caught my eye. Client machine is amd64, running 64-bit mode 5-current fresh as of yesterday. Network interface is e1000, so fxp. Server is also freebsd but 4.10 I think, and 32-bit i386 architecture (not that it should matter). The client and server are dual-stack (v4 and v6 native addresses and on the same subnet...just local switch fabric). Also, while investigating this, witness caught a lock order reversal: fxp0: promiscuous mode enabled lock order reversal 1st 0xffffffff80653de0 bpf global lock (bpf global lock) @ /usr/src/sys/ne= t/bpf =2Ec:381 2nd 0xffffffff80851448 fxp0 (network driver) @ /usr/src/sys/dev/fxp/if_fxp= .c:23 88 KDB: stack backtrace: witness_checkorder() at witness_checkorder+0x654 _mtx_lock_flags() at _mtx_lock_flags+0x4a fxp_ioctl() at fxp_ioctl+0x6f ifpromisc() at ifpromisc+0x98 bpf_detachd() at bpf_detachd+0xae bpfclose() at bpfclose+0xf8 spec_close() at spec_close+0x1fe vn_close() at vn_close+0x7a vn_closefile() at vn_closefile+0x59 fdrop_locked() at fdrop_locked+0x9f closef() at closef+0x40 close() at close+0xe0 syscall() at syscall+0x4b0 Xfast_syscall() at Xfast_syscall+0xa8 --- syscall (6, FreeBSD ELF64, close), rip =3D 0x200a65640, rsp =3D 0x7ffff= fffe6c8, rbp =3D 0x7fffffffe710 --- --=20 David W. Hankins "If you don't do it right the first time, Operations Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --vtzGhvizbBRQ85DL Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBJkt1cXeLeWu2vmoRAm/HAJ9+6+Jg877u/eC5VxVhgk1Ic0h65gCeLcAJ YXVFDSS3nZf5pkB0WTTp7FY= =zVnx -----END PGP SIGNATURE----- --vtzGhvizbBRQ85DL--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040820190525.GA21626>