kern/167646: IPv6 TCP connection hangs/drops when time/clock on the client is stepped backwards

[Martin Birgmeier]

>Number:         167646
>Category:       kern
>Synopsis:       IPv6 TCP connection hangs/drops when time/clock on the client is stepped backwards
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun May 06 16:10:11 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator:     Martin Birgmeier
>Release:        9.0.0, 8.2.0
>Organization:
MBi at home
>Environment:
X server running on:
FreeBSD mizar-v1.xyzzy 9.0-RELEASE FreeBSD 9.0-RELEASE #2: Sun Apr  1 19:48:11 CEST 2012     root at mizar.xyzzy:/usr/obj/.../hal/z/SRC/FreeBSD/release/9.0.0/sys/XYZZY_SMP  amd64

Client running on:
FreeBSD hal.xyzzy 8.2-RELEASE FreeBSD 8.2-RELEASE #4: Sat Aug 27 09:30:11 CEST 2011     root at hal.xyzzy:/z/OBJ/FreeBSD/amd64/RELENG_8_2_0_RELEASE/src/sys/XYZZY_SMP  amd64
>Description:
I am using xterm over IPv6. The client is 8.2.0 and runs several xterms which connect to the X server on 9.0.0. When a backward time step happens on the client, some of the TCPv6 connections get stuck (the affected xterm windows do not refresh any more) and are ultimately lost.

For me, this can happen when ntpd steps the time on the client (it happened twice today, when the first and the third time step occurred):
[0]# grep ntp /var/log/messages
..
May  6 08:34:56 hal ntpd[965]: time reset -0.354682 s
May  6 08:34:56 hal ntpd[965]: kernel time sync status change 2001
May  6 11:58:33 hal ntpd[965]: time reset -0.148885 s
May  6 11:58:33 hal ntpd[965]: kernel time sync status change 6001
May  6 12:02:53 hal ntpd[965]: kernel time sync status change 2001
May  6 17:35:29 hal ntpd[965]: time reset -0.274529 s

It seems that connections via IPv4 are not affected (not fully sure about that).

This is not limited to xterm sessions, see https://bugs.freedesktop.org/show_bug.cgi?id=23325 As can be seen, this problem seems to exist since quite some time.

>How-To-Repeat:
Establish an IPv6 xterm connection. Step the time on the client (where the xterm runs) backwards.
>Fix:


>Release-Note:
>Audit-Trail:
>Unformatted: