home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / unix / ultrix / 6778 < prev    next >
Encoding:
Text File  |  1992-09-08  |  3.3 KB  |  97 lines
  1. Xref: sparky comp.unix.ultrix:6778 comp.unix.bsd:5363
  2. Newsgroups: comp.unix.ultrix,comp.unix.bsd
  3. Path: sparky!uunet!ftpbox!mothost!lmpsbbs!supra!rittle
  4. From: rittle@supra (Loren James Rittle)
  5. Subject: A major BSD socket bug?
  6. Organization: Land Mobile Products Sector, Motorola Inc.
  7. Date: Wed, 9 Sep 1992 05:31:47 GMT
  8. Message-ID: <1992Sep9.053147.411@lmpsbbs.comm.mot.com>
  9. Followup-To: comp.unix.ultrix
  10. Summary: sockets in non-blocking mode appear to have problems
  11. Sender: Loren J. Rittle <rittle@comm.mot.com>
  12. Nntp-Posting-Host: 145.1.80.40
  13. Lines: 82
  14.  
  15. I have reproduced this bug (be it in my code or the BSD OS) under
  16. both ULTRIX 4.2A and SunOS 4.1.2.  As I don't read any sun groups, I didn't
  17. know where to crosspost there.  The example below is under 20 lines of code.
  18. If you are a BSD hacker, please take a look.
  19.  
  20. Thanks,
  21. Loren
  22.  
  23. /* It appears that whenever recvfrom() doesn't block and yet doesn't
  24.    return a packet (due to being in non-blocking mode), it hoses the
  25.    socket in some way.  Any later call to recvfrom() that returns a
  26.    valid packet fails to write the sender's network address in the
  27.    sockaddr stucture that was passed to recvfrom().  Any number of
  28.    correctly matched SEND() - RECV pairs (i.e. SEND() comes before RECV)
  29.    can be inserted above the extra RECV with the same results
  30.    occurring.  I have cut this example to the bone in the hopes that
  31.    people will look at it.  Thanks to you if you do take the time. */
  32.  
  33. #include <stdio.h>
  34. #include <sys/types.h>
  35. #include <sys/socket.h>
  36. #include <netinet/in.h>
  37. #include <sys/ioctl.h>
  38.  
  39. struct sockaddr_in a = {AF_INET, 0xf1f1};
  40. struct sockaddr_in rcv = {AF_INET, 0xf1f1};
  41. int s, rcvsize = sizeof rcv, one = 1;
  42. char m[80];
  43.  
  44. #define ERROR(a) do { perror (a); exit (1); } while (0)
  45. #define SEND(m) if (sendto (s,m,sizeof m,0,&a,sizeof a)==-1) ERROR ("sendto");
  46. #define RECV rcv.sin_addr.S_un.S_addr = 0; m[0] = '\0'; \
  47.         recvfrom (s, m, sizeof m, 0, &rcv, &rcvsize); \
  48.         printf ("%d %s\n", rcv.sin_addr.S_un.S_addr, m)
  49.  
  50. int main ()
  51. {
  52.   if ((s = socket (AF_INET, SOCK_DGRAM, 0)) == -1) ERROR ("socket");
  53.  
  54.   if (bind (s, &a, sizeof a) == -1) ERROR ("bind");
  55.  
  56.   if (ioctl (s, FIONBIO, (char *) &one) == -1) ERROR ("ioctl");
  57.  
  58.   SEND ("hello1"); 
  59.   RECV; /* AND PRINT NETWORK ADDRESS OF SENDER AND MESSAGE */
  60.   RECV; /* THIS RECV DOESN'T FIND ANYTHING BUT DOESN'T BLOCK */
  61.   SEND ("hello2"); /* QUEUE UP ONE MORE MESSAGE ON OUR SOCKET */
  62.   RECV; /* BOGUS NETWORK ADDRESS OF SENDER IS PRINTED! */
  63.  
  64.   return 0;
  65. }
  66.  
  67. /* Output from a DECstation 5100 running Ultrix 4.2A:
  68.  
  69.    rittle@supra 631> uname -a
  70.    ULTRIX supra 4.2 0 RISC
  71.    rittle@supra 632> gcc test2.c   # c89 and cc output session similar.
  72.    rittle@supra 633> a.out
  73.    676331921 hello1
  74.    0
  75.    0 hello2
  76.  
  77.   Output from a Sun running SunOS 4.1.2 looked similar:
  78.  
  79.   56> uname -a
  80.   SunOS asun 4.1.2 1 sun4c
  81.   57> cc test2.c -ldl
  82.   58> a.out
  83.   2130706433 hello1
  84.   0
  85.   0 hello2
  86.  
  87.   It seems to me that the correct output (for my machine) should be:
  88.   676331921 hello1   # 676331921 is 145.1.80.40 - my machine's IP address BTW...
  89.   0
  90.   676331921 hello2
  91.  
  92.   Anyone have a clue as to what is going on?  Did I find a bug that afflicts
  93.   many versions of BSD UNIX, or is my code or thought process buggy? */
  94. --
  95. "I really doubt it," he said, "it's far more likely he was bumped off by
  96.  someone on the net." - The rumors of Mark's death are greatly exaggerated.
  97.