Date: Fri, 31 May 96 10:22:20 GMT From: kbracey@art.acorn.co.uk (Kevin Bracey) To: freebsd-bugs@freebsd.org Subject: net/????: TCP bugs Message-ID: <31AEC85C@kbracey>
next in thread | raw e-mail | index | archive | help
Apologies for not posting this with the relevant program, but I'm not actually running FreeBSD. I've just ported FreeBSD's network stack (using a hybrid of -stable and -current), and came across two apparent bugs. 1) netinet/tcp_var.h (-current) TCP_REXMTVAL is defined as: #define TCP_REXMTVAL(tp) \ ((((tp)->t_srtt >> (TCP_RTT_SHIFT - TCP_RTTVAR_SHIFT)) \ + ((tp)->t_rttvar) >> TCP_RTTVAR_SHIFT)) This is incorrect, and should be: #define TCP_REXMTVAL(tp) \ ((((tp)->t_srtt >> (TCP_RTT_SHIFT - TCP_RTTVAR_SHIFT)) \ + ((tp)->t_rttvar * 4) >> TCP_RTTVAR_SHIFT)) The former leads to a retransmission sequence (for initial connect) like: Transmit - wait 6 secs - TX - wait 3 - TX - wait 6 - TX - wait 12 when it should of course be Transmit - wait 6 secs - TX - wait 12 - TX - wait 24 - TX - wait 48 That's then correct for a first time connection (t_srtt will be 0), but I'm still not sure that it's correct if t_srtt is set. I have a suspicion that the brackets are incorrectly placed. 2) netinet/tcp_usrreq.c & netinet/tcp_timer.c (-current and -stable) tcp_slowtimo() calls tcp_usrreq(PRU_SLOWTIMO), and then compares its return value to NULL. It seems to be expecting tcp_usrreq to return the new value of tp, so it can tell if the connection's been dropped. But tcp_usrreq returns an error code. It would seem then that t_idle and t_duration are not updated on any slowtimo that causes a TCP timer to go off. On an related note, have any FreeBSD people had problems accessing http://www.sgi.com/ recently? For the last week or two, if net.inet.tcp.rfc1323 is on, my HTTP fetches have been frequently truncated to 10K or so, with the disconnection apparently being triggered by the remote end. In practice this means that many images go missing. It works perfectly if net.inet.tcp.rfc1323 is off. I'm trying to figure out if it is a problem with a) my port, b) FreeBSD, or c) SGI's server. Thanks, Kevin Bracey Acorn RISC Technologies
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?31AEC85C>