From fenner@parc.xerox.com  Sat Feb 28 13:35:16 1998
Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93])
          by hub.freebsd.org (8.8.8/8.8.8) with SMTP id NAA21581
          for <FreeBSD-gnats-submit@freebsd.org>; Sat, 28 Feb 1998 13:35:15 -0800 (PST)
          (envelope-from fenner@parc.xerox.com)
Received: from fenestro.parc.xerox.com ([13.0.208.199]) by alpha.xerox.com with SMTP id <52036(1)>; Sat, 28 Feb 1998 13:35:13 PST
Received: (from fenner@localhost)
          by fenestro.parc.xerox.com (8.8.5/8.8.4)
	  id NAA04591; Sat, 28 Feb 1998 13:36:14 -0800 (PST)
Message-Id: <199802282136.NAA04591@fenestro.parc.xerox.com>
Date: Sat, 28 Feb 1998 13:36:14 PST
From: Bill Fenner <fenner@research.att.com>
Reply-To: fenner@research.att.com
To: FreeBSD-gnats-submit@freebsd.org
Subject: sb_cc counts control data as well as data data
X-Send-Pr-Version: 3.2

>Number:         5877
>Category:       kern
>Synopsis:       [socket] sb_cc counts control data as well as data data
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-net
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Feb 28 13:40:00 PST 1998
>Closed-Date:    
>Last-Modified:  Sun May 29 23:02:21 UTC 2011
>Originator:     Bill Fenner
>Release:        FreeBSD 3.0-CURRENT i386
>Organization:
Xerox
>Environment:

BSD since the beginning of time (well, 4.2 =)

>Description:

A socket's sb_cc field includes the length of control data (like the
source address, for PR_ADDR protocols, and any control info like if
SO_TIMESTAMP, IP_RECVIF, etc. are set).

Problems with this include:
- FIONREAD just returns sb_cc, but not all these bytes are readable
- This count is used to determine the high/low water marks on the
  socket.
Advantages are:
- sb_cc is really the length of the attached mbufs, so it's simple
  to compute.

>How-To-Repeat:

Adel Abushaev <adel@ksu.ru> reported the problem and included this pair of
test programs.

/* client.c */
#include <stdio.h>
#include <sys/types.h>
#include <sys/time.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>

void main()
{
   int sockfd;
   struct sockaddr_in servaddr_in;
   char buffer[512];

   memset(&servaddr_in, 0, sizeof(struct sockaddr_in));
  
   servaddr_in.sin_family = AF_INET;
   servaddr_in.sin_addr.s_addr = inet_addr("127.0.0.1");
   servaddr_in.sin_port = htons(4000);

   sockfd = socket(AF_INET, SOCK_DGRAM, 0);
   if (sockfd <= 0) 
   {
         perror("socket"); return;
   }

   sendto(sockfd, buffer, 512, 0, (struct sockaddr *)&servaddr_in,
          sizeof(struct sockaddr_in));

   close(sockfd);
}

/* server.c */ 
#include <stdio.h>
#include <sys/types.h>
#include <sys/time.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <sys/stat.h>
#include <sys/fcntl.h>
#include <sys/ioctl.h>

#ifdef SOLARIS
#include <sys/filio.h>
#endif

void main()
{
   int sockfd;
   struct sockaddr_in myaddr_in, peeraddr_in;
   unsigned addrlen;
   char buffer[512];
   struct timeval tim;
   int optval;
   fd_set fdsread, fdswrite, fdsexcept;

   memset(&myaddr_in, 0, sizeof(struct sockaddr_in));
   memset(&peeraddr_in, 0, sizeof(struct sockaddr_in));
  
   myaddr_in.sin_family = AF_INET;
   myaddr_in.sin_addr.s_addr = INADDR_ANY;
   myaddr_in.sin_port = htons(4000);

   sockfd = socket(AF_INET, SOCK_DGRAM, 0);
   if (sockfd <= 0) 
   {
         perror("socket"); return;
   }

   if (bind(sockfd, (struct sockaddr *)&myaddr_in, sizeof(struct sockaddr_in))
      < 0) 
   {
        perror("bind"); return;
   }

   FD_ZERO(&fdsread); FD_ZERO(&fdswrite); FD_ZERO(&fdsexcept);
   FD_SET(sockfd, &fdsread);
   tim.tv_sec=60; tim.tv_usec=0;
   select(sockfd+1, &fdsread, &fdswrite, &fdsexcept, &tim);
   if (FD_ISSET(sockfd, &fdsread))
   {
     ioctl(sockfd, FIONREAD, &optval); printf("ioctl: %d\n",optval); 
     optval=recvfrom(sockfd, buffer, 512, 0, (struct sockaddr *)&peeraddr_in,
          &addrlen); printf("recv: %d\n",optval);
     ioctl(sockfd, FIONREAD, &optval); printf("ioctl: %d\n",optval); 
   }

   close(sockfd);
}

>Fix:
	
Make sb_cc reflect the number of data bytes in the socket buffer,
instead of the amount of data+control.  This may be as simple as
fixing sballoc() and sbfree() in sys/socketvar.h to only count
MT_HEADER, MT_DATA, MT_OOBDATA mbufs, or may be much more involved.

>Release-Note:
>Audit-Trail:

From: Bosko Milekic <bmilekic@dsuper.net>
To: freebsd-gnats-submit@freebsd.org, fenner@parc.xerox.com
Cc:  
Subject: Re: kern/5877: sb_cc counts control data as well as data data
Date: Fri, 28 Apr 2000 20:00:33 -0400 (EDT)

 	Wouldn't you agree that the better solution would be to just fix the
   computation/adjusting of the high and low watermarks to not include
   control data, as sb_cc's count is also used for other purposes which may
   (or may not? [*]) involve the counting of the control data mbufs?
   	This is feasible with a new variable which would hold (sb_cc -
   control data) which need only be adjusted when control type mbufs are
   added to the sockbuf. This way, low and high watermarks can be adjusted
   as per that new value.
 
   [*] Of course, "may or may not" is ambiguous. I see sb_cc being a, as
   commented in socketvar.h, "_actual_ chars in buffer" count. Perhaps some
   other bit in the code also relies on this interpretation and assumes
   that, indeed, there are no mbufs attached to sb_mb when sb_cc is zero.
 
   Comments, anyone?
   
   --Bosko
 
 --
  Bosko Milekic * pages.infinit.net/bmilekic/index.html * www.technokratis.com
  bmilekic@dsuper.net * bmilekic@technokratis.com * b.milekic@marianopolis.edu
 
 
 
Responsible-Changed-From-To: freebsd-bugs->bmilekic 
Responsible-Changed-By: mike 
Responsible-Changed-When: Sat Jul 21 22:33:16 PDT 2001 
Responsible-Changed-Why:  

Over to Bosko Milekic <bmilekic@FreeBSD.org>.  He seems to have a 
good grasp of the problem and solution. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=5877 
Responsible-Changed-From-To: bmilekic->kbyanc 
Responsible-Changed-By: bmilekic 
Responsible-Changed-When: Mon Jan 13 16:29:50 PST 2003 
Responsible-Changed-Why:  
Over to kbyanc because this has been sitting around in my basket 
for way too long and I haven't done anything about it and I don't 
want to do anything about it. Recently, kbyanc has done some 
related work, and it was recommended to me to forward this 
to him. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=5877 
State-Changed-From-To: open->feedback 
State-Changed-By: linimon 
State-Changed-When: Fri Mar 9 00:09:01 UTC 2007 
State-Changed-Why:  
Is this still a problem with modern versions of FreeBSD? 


Responsible-Changed-From-To: kbyanc->linimon 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Fri Mar 9 00:09:01 UTC 2007 
Responsible-Changed-Why:  

http://www.freebsd.org/cgi/query-pr.cgi?pr=5877 
State-Changed-From-To: feedback->suspended 
State-Changed-By: linimon 
State-Changed-When: Fri Mar 9 07:29:19 UTC 2007 
State-Changed-Why:  
Submitter notes that this problem still recurs on 6.1.  Mark suspended 
awaiting someone to take an interest in this antique PR. 


Responsible-Changed-From-To: linimon->freebsd-bugs 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Fri Mar 9 07:29:19 UTC 2007 
Responsible-Changed-Why:  

http://www.freebsd.org/cgi/query-pr.cgi?pr=5877 
State-Changed-From-To: suspended->open 
State-Changed-By: kmacy 
State-Changed-When: Sun Nov 18 22:36:03 UTC 2007 
State-Changed-Why:  

Doesn't seem like this would be that hard to fix, at least in HEAD where I have the  
luxury of adding fields to the socket. 


Responsible-Changed-From-To: freebsd-bugs->kmacy 
Responsible-Changed-By: kmacy 
Responsible-Changed-When: Sun Nov 18 22:36:03 UTC 2007 
Responsible-Changed-Why:  

Doesn't seem like this would be that hard to fix, at least in HEAD where I have the   
luxury of adding fields to the socket.  


http://www.freebsd.org/cgi/query-pr.cgi?pr=5877 
Responsible-Changed-From-To: kmacy->freebsd-net 
Responsible-Changed-By: gavin 
Responsible-Changed-When: Sun May 29 23:00:57 UTC 2011 
Responsible-Changed-Why:  
kmacy has asked for all of his PRs to be reassigned back to the pool. 


http://www.freebsd.org/cgi/query-pr.cgi?pr=5877 
>Unformatted:
