From: Frank Lind <flind@haystack.mit.edu>
To: linux-kernel@vger.kernel.org
Cc: knobi@knobisoft.de
Subject: Multicast problems between 2.4.20 and 2.4.21?
Date: Mon, 24 May 2004 16:37:14 -0400 [thread overview]
Message-ID: <40B25CFA.3000105@haystack.mit.edu> (raw)
Hi,
Was there ever a resolution to the multicast issues with kernels beyond
2.4.20?
I have a very similar problem that has shown up with code which works
fine prior with 2.4.20-6smp (Redhat 9) and then stops working for later
kernels. I ran into this upgrading a machine to RedHat Enterprise
(2.4.21-9.ELsmp) but it also happens under Fedora (2.6.5-1.358smp). I
was going to try some separate kernel compiles and also a different
distribution when I get a chance to try to localize the change. I
haven't been able to find a clear reason why this is happening yet. I
was wondering if anyone had any additional insights beyond what showed
up in the kernel mailing lists so far (i.e. Any changes in Multicast
code between 2.4.20 and 2.4.22/23)?
I am able to get the multicasting to work under these kernels by
changing my bind calls to use the INADDR_ANY instead of binding to the
address and port I'm using for the multicast group. I haven't found good
documentation that this is the "correct" way to do this but I ran into
some comments for multicast under ipv6 which made me think it was worth
a try. This substitution gets the machines multicasting but I've had
some problems that appear to be the switch selectively deciding to
deliver data or not depending on if certain machines connect to the
multicast group. (This needs more testing but basically if a machine
using the 2.4.20 kernel joins then some of the newer kernel machines
stop getting packets for reasons I don't understand yet).
I noted it was asked why the network switch might matter. There is a
note from HP on their Procurve switches indicates that certain IP
addresses are not IGMP filtered. In particular 224.0.0.x gets no IGMP
filtering :
http://www.hp.com/rnd/pdfs/IGMP_Tech_Note.pdf
I got bit by this one a while back in that my network was getting
flooded despite using IGMP in the code.
-- Frank
--
Frank D. Lind email: flind@haystack.mit.edu
MIT Haystack Observatory WWW: http://www.haystack.mit.edu
Route 40 tel: 781 981 5570
Westford, MA 01886 USA fax: 781 981 5766
next reply other threads:[~2004-05-24 20:38 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-24 20:37 Frank Lind [this message]
2004-05-25 9:49 ` Multicast problems between 2.4.20 and 2.4.21? Martin Knoblauch
2004-05-25 17:38 ` David S. Miller
2004-05-25 18:15 ` Martin Knoblauch
2004-05-25 18:18 ` Frank Lind
2004-05-25 19:59 ` David S. Miller
2004-05-25 20:14 ` Martin Knoblauch
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=40B25CFA.3000105@haystack.mit.edu \
--to=flind@haystack.mit.edu \
--cc=knobi@knobisoft.de \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox