Bug 209981 - select() doesn't work with multicast UDP
select() doesn't work with multicast UDP
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
5
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: David Miller
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-10-09 04:41 EDT by Christopher Hite
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-10-19 22:52:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
main code - illustrates the bug (2.54 KB, text/plain)
2006-10-09 10:44 EDT, Christopher Hite
no flags Details
Just standard headers on Linux, does windows compatiblity (1.01 KB, text/plain)
2006-10-09 10:46 EDT, Christopher Hite
no flags Details

  None (edit)
Description Christopher Hite 2006-10-09 04:41:50 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727)

Description of problem:
select() doesn't seem to work properly multicast.  mcasttest.cpp illustrates the problem.  cleansockets.h allows the code to be compiled on windows; it's just standard headers on linux.


Output:
setting up
recieving
select()ing
returned 0
FD_ISSET not set
got 1

This shows that select() is not detecting that the socket has recieved data, but it obviously has recieved data because recvfrom() returns packets.

Strangely the code works when compiled on windows and run under WINE!
>wine mcasttest.exe
returns:
setting up
recieving
select()ing
returned 1
FD_ISSET
got 1

This would imply the WINE people know about this problem and worked around it.  I've played with this for a while removing a few sockopts here and there, but for naught.


Version-Release number of selected component (if applicable):
kernel-2.6.17-1.2187_FC5 kernel-2.6.17-1.2174_FC5

How reproducible:
Always


Steps to Reproduce:
1) compile:
gcc -o mcasttest -lstdc++   mcasttest.cpp

2) send data:
./mcasttest s

3) recieve (on another shell):
 ./mcasttest

Actual Results:

setting up
recieving
select()ing
returned 0
FD_ISSET not set
got 1

Expected Results:

setting up
recieving
select()ing
returned 1
FD_ISSET
got 1

Additional info:
I've done an automatic update a few days ago.  I'm running:
[root@ares mcasttest]# rpm -q kernel
kernel-2.6.17-1.2174_FC5
kernel-2.6.17-1.2187_FC5
...
Fedora Core release 5 (Bordeaux)
i686
Comment 1 Christopher Hite 2006-10-09 10:44:38 EDT
Created attachment 138039 [details]
main code - illustrates the bug

Sorry for forgetting to attach this right away!
Comment 2 Christopher Hite 2006-10-09 10:46:35 EDT
Created attachment 138040 [details]
Just standard headers on Linux, does windows compatiblity
Comment 3 Dave Jones 2006-10-16 20:01:57 EDT
A new kernel update has been released (Version: 2.6.18-1.2200.fc5)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

In the last few updates, some users upgrading from FC4->FC5
have reported that installing a kernel update has left their
systems unbootable. If you have been affected by this problem
please check you only have one version of device-mapper & lvm2
installed.  See bug 207474 for further details.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

If this bug has been fixed, but you are now experiencing a different
problem, please file a separate bug for the new problem.

Thank you.
Comment 4 Christopher Hite 2006-10-17 11:50:22 EDT
Nope, it's still broken.  I recompiled it and it does the same thing.  select() 
returns nothing even thought the socket has data.
Comment 5 David Miller 2006-10-19 22:52:09 EDT
Your application is buggy.

The first select argument should be "socketId + 1".  Make that change
and it will work properly, I just verified that here.

If you copied the select() call from the Linux man page, you should
note that the example given in the manpage is select()'ing on file
descriptor "0", standard input, and therefore the first argument to
select should be "0 + 1".

Finally, you didn't provide the cleansockets.h header file, so I
had to spend the time to put one together.  Providing self-contained
test cases makes your problem get looked at faster, just a note for
the future.
Comment 6 Christopher Hite 2006-10-20 06:39:21 EDT
Ok, my bad!!! I should have read the MAN page.  I thought it was the number of
sockets.  On windows it's ignored.  Theoretically select() can always calculate
that parameter from the others, so debatebly it's a useless parameter.  Maybe
there's some speed benefit.

Anyway thanks.  Sorry.  I hope my company will give you money.  We've bought Red
Hat licenses in the past and the customer(ING bank) we're doing this for may
also give you something.

Just for the record that header file "cleansockets.h" was attached in the 2nd
comment.  Sorry I didn't attach it immediately.
Comment 7 David Miller 2006-10-20 15:49:01 EDT
The first argument to select() provides two things:

1) An optimization, which you noticed, which reduces the amount of the
   fd bitmaps which the select() implementation has to scan.

2) An upgrade path for increasing the size of fd_set transparently.  The
   kernel doesn't actually care how big these bitmaps are, all it would
   see is a larger first argument if "fd_set" were made larger in userspace
   and the application made use of that larger area.

Note You need to log in before you can comment on or make changes to this bug.