From owner-freebsd-current@FreeBSD.ORG Fri Aug 20 19:05:26 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 816E116A4D2 for ; Fri, 20 Aug 2004 19:05:26 +0000 (GMT) Received: from kaboom.isc.org (kaboom.isc.org [204.152.187.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A0C343D58 for ; Fri, 20 Aug 2004 19:05:26 +0000 (GMT) (envelope-from David_Hankins@isc.org) Received: by kaboom.isc.org (Postfix, from userid 10200) id AF718B241F; Fri, 20 Aug 2004 12:05:25 -0700 (PDT) Date: Fri, 20 Aug 2004 12:05:25 -0700 From: "David W. Hankins" To: current@freebsd.org Message-ID: <20040820190525.GA21626@isc.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vtzGhvizbBRQ85DL" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: on amd64 tcp4 cksums are bad (FYI) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2004 19:05:26 -0000 --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 [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 [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 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 =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--