Thanks Joe. I'll see if the customer will let me investigate the problem
further. As a work around I've giving them the ability to specifity an
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
Yes, it is a guess on my part, somewhat guided by how I know certain
drivers work.
To get multicast, many cards filter out multicast in hardware, simply
discarding packets
entirely and not even interrupting upon their receipt. These cards must
be programmed by
an upper-level driver that understands the various kinds of multicast
capability.
A summary is:
* No ability; it's all done in software
* One multicast address can be programmed in
When the card is in multicast mode, any multicast which
does not match is ignored
* N multicast addresses, behavior as above
* 3COM had one that had a 4096-bit hash table; the
multicast address was hashed, and if the bit was 1
the packet caused an interrupt. Yes, it might interrupt
if there was a duplicate hash, but then the software stack
would sort the mess out
Now, if there is a bug of the type I'm hypothesizing, when you set the
multicast address
(joining the multicast group), the bug is that it programs only one of the
several NIC
cards. If the other card is another "smart multicast" card, then it will
probably have
defaulted to rejecting all multicast packets, relying on its driver to
program it when a
group is joined. But the bug is that only one of the N NIC cards gets
this programming.
Unfortunately, the Real Truth might only be determinable by using a bus
analyzer and
studying the traffic, not exactly the lowest-cost or easiest solution by
some huge measure
of cost or inconvenience. One source of information might be the NIC card
vendor; explain
the problem (seriously, when a friend of mine discovered a serious driver
bug, the vendor
said "Oh, yeah, we fixed that a year ago..." so also make sure you have
the latest
drivers). Note that vendor A may say "We've never had a problem" but it
might be that
they have never had a situation in which two of their cards were plugged
in, or one was
from Vendor A and one from Vendor B, and it might be the *other* driver
that is causing
the problem! So if the cards come from two different vendors, the first
thing I'd suggest
is getting two of one or two of the other. If you have a motherboard NIC
and a backplane
NIC, this isn't going to be a feasible solution; in that case, consider
two backplane NICs
so you can isolate the problem to a single vendor. Then again, it might
be the Microsoft
stacks. Overall, hard to deduce what is happening.
Since I believe the abstraction is as you describe, that you should see
the packets from
any source, the only rationale I can come up with is that one of the cards
is not getting
its multicast programming set, and the rest is a bit of
by-guess-and-by-golly reasoning
which may or may not come close to the truth.
Another source of Truth might be the OSR newsgroups (www.osr.com) where
they have lots of
network card driver experts hanging out. To post there, you would need to
say things like
which vendor(s) and model(s) did your NIC cards, try the swap-cards if
that is feasible,
and report your findings. Someone there might recognize the problem (I'm
thinking of the
kind of people who can say, "Oh, yeah, they didn't read the page about how
to handle
multiple NIC adapters, and that's probably where the bug is...") But
before you post
there, you should really go through the vendors, including Microsoft, if
you can.
joe
On Mon, 2 Nov 2009 10:15:49 -0600, "AliR" <AliR@online.nospam> wrote:
Hi Joe,
I didn't quite understand this statement:
and the problem may not be in the binding as much as it might be setting
the multicast in
must one of the NICs, thus the other one blocks any multicast receipts.
Are you saying the drive's bug is most likely in the multicast membership
part?
AliR.
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
news:f30ue5hlm3bigtjrf2rmaccu0m4sj9a8eq@4ax.com...
I'd be tempted at this point to single-step into the CAsyncSocket code
to
be sure that it
really passed the correct WinSock value in. Unfortunately, I suspect
that
it does, which
means you may be a victim of some kind of WinSock bug. Your
understanding
is my
understanding, also. Note that multicasting requires that you enable
the
multicast group,
and the problem may not be in the binding as much as it might be setting
the multicast in
must one of the NICs, thus the other one blocks any multicast receipts.
As a last-ditch experiment, if the NICs are on separate cards (as
opposed
to multiple
sockets on the motherboard) you could try switching the boards in the
backplane and see if
it binds to the "other one". This may then isolate it to a driver or
some
part of the
stack, and you can pursue it in one of the network groups, or report it
as
a bug.
joe
On Mon, 2 Nov 2009 09:32:43 -0600, "AliR" <AliR@online.nospam> wrote:
Hi guys,
I have a client that has a computer with two NICs in it. Each NIC is
connected to a different network. It appears that when my windows
service
application starts and creates a receiving multicast socket it binds to
one
of the NICs, and it happens to be the wrong one. (We verified this by
disabling the unrelated networks NIC and everything works fine at that
point).
My understanding of Bind was that if you passed NULL for the IP address
then
it will bind itself to all the network interfaces!
From CAsyncSocket::Bind
lpszSocketAddress
The network address, a dotted number such as "128.56.22.8". Passing the
NULL
string for this parameter indicates the CAsyncSocket instance should
listen
for client activity on all network interfaces.
Is that not true? Did I misunderstand something?
I'm guessing that I will have to ask the user of computers with multiple
IPs
for a specific IP to bind to. Is this the correct approach?
Thanks
AliR.
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm