Bug 172350 - Multicast address setsockopt ENODEV
Multicast address setsockopt ENODEV
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: ttcp (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Radek Vokal
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2005-11-03 01:17 EST by Phil Manuel
Modified: 2007-11-30 17:07 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-11-08 17:35:30 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Phil Manuel 2005-11-03 01:17:04 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050921 Firefox/1.0.7 Mandriva/1.0.6-16.1.20060mdk (2006.0)

Description of problem:
We are using ttcp as a multicast listener.  When we use ttcp -rup 5005 it does run, but doesn't work.

We ran it with strace to see what was happening and noticed the following:-

write(2, "ttcp-r: socket\n", 15ttcp-r: socket
)        = 15
setsockopt(3, SOL_IP, IP_ADD_MEMBERSHIP, "\340\0\0\5\0\0\0\0", 8) = -1 ENODEV (No such device)
bind(3, {sa_family=AF_UNSPEC, sa_data="\23\215\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = 0
gettimeofday({1130997377, 483238}, NULL) = 0
getrusage(RUSAGE_SELF, {ru_utime={0, 0}, ru_stime={0, 0}, ...}) = 0

I used lshw to pickup the network card information

                description: Ethernet interface
                product: NetXtreme BCM5782 Gigabit Ethernet
                vendor: Broadcom Corporation
                physical id: 2
                bus info: pci@05:02.0
                logical name: eth0
                version: 03
                serial: 00:0f:20:39:82:e7
                size: 100MB/s
                capacity: 1GB/s
                width: 64 bits
                clock: 66MHz
                capabilities: bus_master cap_list ethernet physical mii 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd autonegociation
                configuration: autonegociation=on broadcast=yes driver=tg3 driverversion=3.22RH duplex=full ip= link=yes multicast=yes port=twisted pair speed=100MB/s
                resources: iomemory:fc500000-fc50ffff irq:5

We are using two other RHEL3 boxes as well in the environment all running the same updates.  One is set to transmit multicast traffic using the same ttcp binary.  The other listens using the same command as above and it sees the traffic.

The only difference that I can see is the network card and therefore the driver used is differnet per unit.

I have seen the other bug report with multicast and ENODEV, but we do not remove the module and re-insert it.  Plus it seems specific to a prticular module.

Version-Release number of selected component (if applicable):
use ttcp to listen on multicast address

How reproducible:

Steps to Reproduce:
1.Setup a box to send multicast traffic, i.e. ttcp -tup 5005
2.Setup a box that uses a network card that uses the tg3 driver to listen, ttcp -rup 5005
3.Setup a nother box to listen for multicast traffic ttcp -rup 5005
4. Send traffic via first box, see whether traffic is received ont he listeners

Actual Results:  ttcp listner on the tg3 network card receives no traffic as it doesn't listen, see strace output above

Expected Results:  We should have seen the test traffic

Additional info:
Comment 1 John W. Linville 2005-11-03 16:10:07 EST
3.22RH is pretty old...please try to recreate with the test kernels here:


Please post the results of using those kernels...thanks!
Comment 2 Phil Manuel 2005-11-03 18:17:38 EST
OK I tried 2.4.21-37.8.EL.jwltest.70 which uses 3.43RH tg3 driver and I still
have the same error.
Comment 3 John W. Linville 2005-11-04 10:07:34 EST
It looks to me like ttcp is calling setsockopt with an incomplete ip_mreqn  
structure and a source IP address of  When this fails to result in a  
match for a net device, -ENODEV is returned.  
I'm transferring to the ttcp owner for further analysis of why ttcp might use  
an incomplete ip_mreqn structure.  I have no explanation for how this might  
work elsewhere.  Could it be that the "broken" box does not have a default 
route set? 
Comment 4 Ernie Petrides 2005-11-04 14:46:42 EST
Changing component from "kernel" to "ttcp".
Comment 5 Phil Manuel 2005-11-06 17:34:13 EST
I think that it is not a ttcp issue as ttcp works correctly on two other 
servers that are on the same build as the server giving the issue. 
This should be with the driver for the network card, i.e. kernel component not 
with ttcp. 
The same source is used on earlier kernels as well, we call it in the same 
manner in virtually all cases. 
Comment 6 Phil Manuel 2005-11-08 17:35:30 EST
OK we re-read this bug and noticed the comment about no default route, and this
was the issue.  Adding a default route enabled this to work correctly.

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