The tale of a TCP bug

[Stefan `Sec` Zehl]

Hi I'm back :)

On Fri, Apr 01, 2011 at 01:40 +0200, Stefan `Sec` Zehl wrote:
> I'll of course monitor this value and report back if I ever see it
> increase :-)

It did:

| ice:~>uptime
|  1:45PM  up 2 days, 17:01, 0 users, load averages: 1.29, 0.98, 0.60
| ice:~>sysctl net.inet.tcp.adv_neg
| net.inet.tcp.adv_neg: 120
| ice:~>

I currently have no idea why. But I think it would be a good idea to fix
that adv calculation on 64bit for the negative case anyway.

As my original attempt with a (long) cast was frowned upon, maybe
something like what OpenBSD did in r1.15 / 1998?

http://www.openbsd.org/cgi-bin/cvsweb/src/sys/netinet/tcp_output.c.diff?r1=1.14;r2=1.15

--- tcp_output.c.pre    2011-04-02 13:50:32.000000000 +0200
+++ tcp_output.c        2011-04-02 13:50:35.000000000 +0200
@@ -575,7 +575,7 @@
                 * taking into account that we are limited by
                 * TCP_MAXWIN << tp->rcv_scale.
                 */
-               long adv = min(recwin, (long)TCP_MAXWIN << tp->rcv_scale) -
+               long adv = lmin(recwin, (long)TCP_MAXWIN << tp->rcv_scale) -
                        (tp->rcv_adv - tp->rcv_nxt);
 
                if(min(recwin, (long)TCP_MAXWIN << tp->rcv_scale) <


If anyone has an idea what could trigger these cases, I'd be happy to
help debug. But without a clear testcase, it's a bit difficult.

CU,
    Sec
-- 
"few languages are as bad as PHP for doing serious development work"
-- Experiences of Using PHP in Large Websites
   <URL:http://www.ukuug.org/events/linux2002/papers/html/php/>