Miniport driver configuration for receiving/indicating Multicast data

NTDEV
1

Hey guys,

So, I have my my Miniport driver working so that it’s receiving data from my bus driver (which is popping the ethernet/IP packets out of the incoming transport stream over PCI) over my direct call interface, and indicating the data up to NDIS (or technically the protocol driver sitting above my mp driver).

I’m able to see the multicast traffic come across my mp driver interface using Wireshark just fine (since it sets my mp driver in ‘Promiscuous mode’, and all traffic is indicated up).

I have an application that’s creating a UdpClient(), invoking JoinMulticastGroup() on the multicast address that I’m interested in (“224.1.1.77” - and I see this address in the wireshark data), and listening for data. However, for some reason the app is not getting the data. Furthermore, I expect to see some kind of OID_802_3_MULTICAST_LIST to come down from NDIS in my mp driver when the app joins the multicast group, but I don’t (verified via dbgPrint()). I do see this print:

“–GetMcast: ea29320a f730cd58”

But this must be from the protocol driver or NDIS, because my driver isn’t printing this out.

I’m sure what’s happening is that my mp driver doesn’t indicate the data up to NDIS because the 224.1.1.77 multicast address isn’t in the multicast list in my mp driver, or maybe the PacketFilter isn’t set correctly (I see it set to ‘11’ shortly after the driver installs).

Now, I can take the same app, and tell it to listen for multicast traffic on 224.1.1.87, and it reads the multicast data just fine from another NIC card installed on the box (which obviously has a separate multicast feed).

So what trigger’s the OID_802_3_MULTICAST_LIST to be sent down to an adapter/mp driver? Also, how does the app know which interface to listen on? I know these are dumb questions, but this is all new to me…:slight_smile: I’m learning as I go.

Thanks for any insight!

Jason Summerour

2

I’m reading in the following paper:

http://www.osronline.com/ddkx/network/23ethoid_8b8y.htm

that for Ethernet Operational Characteristic OID, OID_802_3_MULTICAST_LIST,

“To receive a multicast packet, the protocol driver must later set the packet filter to include the NDIS_PACKET_TYPE_MULTICAST flag. At any time, it can disable multicast packet reception by canceling this flag. The order in which the protocol driver enables reception for multicast packets is not important.”

and

“A protocol driver can set the packet filter to enable all multicast packets, and do the filtering itself.”

So, how do you tell the protocol driver to do these things? I don’t see anywhere in the mp device object within the Device Manager where I can tweak such options, nor in the settings for the LAN device properties box from within “Network Connections”.

I was hoping to see some options in the Internet Protocol (TCP/IP) entry from within the LAN properties for my device, but I don’t see anything about setting up multicast.

I know…stupid questions…but again this is all new to me. LoL Thanks again!

Jason

3

I strongly suggest running NDIStest against your miniport if you have not
done so. It’s a great tool to catch obvious bugs in early development or
prototyping stage. It’s not very useful for catching problems in production
drivers except for getting logo.

Calvin

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Tuesday, January 26, 2010 11:15 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Miniport driver configuration for receiving/indicating
Multicast data

Hey guys,

So, I have my my Miniport driver working so that it’s receiving data from my
bus driver (which is popping the ethernet/IP packets out of the incoming
transport stream over PCI) over my direct call interface, and indicating the
data up to NDIS (or technically the protocol driver sitting above my mp
driver).

I’m able to see the multicast traffic come across my mp driver interface
using Wireshark just fine (since it sets my mp driver in ‘Promiscuous mode’,
and all traffic is indicated up).

I have an application that’s creating a UdpClient(), invoking
JoinMulticastGroup() on the multicast address that I’m interested in
(“224.1.1.77” - and I see this address in the wireshark data), and listening
for data. However, for some reason the app is not getting the data.
Furthermore, I expect to see some kind of OID_802_3_MULTICAST_LIST to come
down from NDIS in my mp driver when the app joins the multicast group, but I
don’t (verified via dbgPrint()). I do see this print:

“–GetMcast: ea29320a f730cd58”

But this must be from the protocol driver or NDIS, because my driver isn’t
printing this out.

I’m sure what’s happening is that my mp driver doesn’t indicate the data up
to NDIS because the 224.1.1.77 multicast address isn’t in the multicast list
in my mp driver, or maybe the PacketFilter isn’t set correctly (I see it set
to ‘11’ shortly after the driver installs).

Now, I can take the same app, and tell it to listen for multicast traffic on
224.1.1.87, and it reads the multicast data just fine from another NIC card
installed on the box (which obviously has a separate multicast feed).

So what trigger’s the OID_802_3_MULTICAST_LIST to be sent down to an
adapter/mp driver? Also, how does the app know which interface to listen
on? I know these are dumb questions, but this is all new to me…:slight_smile: I’m
learning as I go.

Thanks for any insight!

Jason Summerour

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

4

I don’t have the HCT, which seems to be the only way to get it. These drivers are for our internal use only, and won’t necessarily need to go through the WHQL certification process. :\ I’d be glad to use NDISTest otherwise. :slight_smile:

5

I think you can use the “route” command to add a multicast route on your
interface. See if that coaxes the required OIDs to go to your MP.

Thomas F. Divine
http://www.pcausa.com

From:
Sent: Tuesday, January 26, 2010 3:55 PM
To: “Windows System Software Devs Interest List”
Subject: RE:[ntdev] Miniport driver configuration for receiving/indicating
Multicast data

> I don’t have the HCT, which seems to be the only way to get it. These
> drivers are for our internal use only, and won’t necessarily need to go
> through the WHQL certification process. :\ I’d be glad to use NDISTest
> otherwise. :slight_smile:
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

6

Ahh, yes, that seemed to do the trick for adding the multicast address in the mc address list down in my mp driver! Thanks Thomas! :slight_smile:

Unfortunately, I still don’t have data flowing up, possibly because of the packet filtering? How would I go about setting the packet filter to set the NDIS_PACKET_TYPE_ALL_MULTICAST / NDIS_PACKET_TYPE_MULTICAST bit? I’m guessing that the last thing I have to set to indicate the data up to NDIS when not in promiscuous mode.

Thanks again!

Jason

7

I’m not an expert in MC, but generally MC addresses are added when there is
a service or application that is interested in joining a MC group.

Do you return non-zero value for oid_802_3_maximum_list_size? Probably or
route add wouldn’t have worked…

I doubt that there would be any application (except for diagnostic
protocols…) that would set NDIS_PACKET_FILTER_ALL_MULTICAST in normal
operation.

Is this a NDIS 6 MP? (Sorry, I wasn’t paying attention…).

Is there anything funny about your MAC address?

Perhaps there is something different in the network that your miniport
connects to. Something that indicates to the system that it shouldn’t bother
using the IF for MC.

Just grasping at straws…

Thomas F. Divine
http://www.rawether.net

From:
Sent: Tuesday, January 26, 2010 4:20 PM
To: “Windows System Software Devs Interest List”
Subject: RE:[ntdev] Miniport driver configuration for receiving/indicating
Multicast data

> Ahh, yes, that seemed to do the trick for adding the multicast address in
> the mc address list down in my mp driver! Thanks Thomas! :slight_smile:
>
> Unfortunately, I still don’t have data flowing up, possibly because of the
> packet filtering? How would I go about setting the packet filter to set
> the NDIS_PACKET_TYPE_ALL_MULTICAST / NDIS_PACKET_TYPE_MULTICAST bit? I’m
> guessing that the last thing I have to set to indicate the data up to NDIS
> when not in promiscuous mode.
>
> Thanks again!
>
> Jason
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

8

Hi Thomas,

This is an NDIS 5.1 mp driver.

I return 32 for oid_802_3_maximum_list_size OID.

As far as the mac address goes, I am currently using a hard coded mac address (11-22-33-44-55). Now, this won’t be the mac that we use in production, as we have a range of mac address to use there, but for testing I had hoped that this would be fine (and there are no other devices in the my dev system w/ this mac).

Here’s an ipconfig dump of the nic:

Ethernet adapter Local Area Connection 4:

Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : TWC TS_II_NDIS Driver #109
Physical Address. . . . . . . . . : 11-22-33-44-55-66
Dhcp Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
Autoconfiguration IP Address. . . : 169.254.19.237
Subnet Mask . . . . . . . . . . . : 255.255.0.0
Default Gateway . . . . . . . . . :

The destination mac address in the multicast data is 01:00:5e:00:00:0d, and the multicast IP address is 224.1.1.77. The routing table is set up as follows:

Route Table

Interface List
0x1 … MS TCP Loopback interface
0x2 …00 1f bc 00 fb ab … Realtek PCIe GBE Family Controller #2 - Packet S
cheduler Miniport
0x3 …00 1f bc 00 fb aa … Realtek PCIe GBE Family Controller - Packet Sche
duler Miniport
0x4 …11 22 33 44 55 66 … TWC TS_II_NDIS Driver #109 - Packet Scheduler Mi
niport

===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 10.50.40.1 10.50.41.234 20
10.50.40.0 255.255.254.0 10.50.41.234 10.50.41.234 10
10.50.41.234 255.255.255.255 127.0.0.1 127.0.0.1 10
10.255.255.255 255.255.255.255 10.50.41.234 10.50.41.234 10
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
169.254.0.0 255.255.0.0 169.254.19.237 169.254.19.237 30
169.254.19.237 255.255.255.255 127.0.0.1 127.0.0.1 30
169.254.255.255 255.255.255.255 169.254.19.237 169.254.19.237 30
224.0.0.0 240.0.0.0 10.50.41.234 10.50.41.234 10
224.0.0.0 240.0.0.0 169.254.19.237 169.254.19.237 30
224.1.1.77 255.255.255.255 169.254.19.237 169.254.19.237 1
255.255.255.255 255.255.255.255 10.50.41.234 10.50.41.234 1
255.255.255.255 255.255.255.255 169.254.19.237 2 1
255.255.255.255 255.255.255.255 169.254.19.237 169.254.19.237 1
Default Gateway: 10.50.40.1

Persistent Routes:
Network Address Netmask Gateway Address Metric
224.1.1.77 255.255.255.255 169.254.19.237 1

Thanks Thomas!

Jason

9

What are the IP addresses of the remote nodes? In particular, are they on
the 169.254.0.0 subnet? If not, then no hope of communicating with them.

Have you tried assigning a static IP address to your interface?

Thomas F. Divine
http://www.rawether.net

From:
Sent: Tuesday, January 26, 2010 4:59 PM
To: “Windows System Software Devs Interest List”
Subject: RE:[ntdev] Miniport driver configuration for receiving/indicating
Multicast data

> Hi Thomas,
>
> This is an NDIS 5.1 mp driver.
>
> I return 32 for oid_802_3_maximum_list_size OID.
>
> As far as the mac address goes, I am currently using a hard coded mac
> address (11-22-33-44-55). Now, this won’t be the mac that we use in
> production, as we have a range of mac address to use there, but for
> testing I had hoped that this would be fine (and there are no other
> devices in the my dev system w/ this mac).
>
> Here’s an ipconfig dump of the nic:
>
> Ethernet adapter Local Area Connection 4:
>
> Connection-specific DNS Suffix . :
> Description . . . . . . . . . . . : TWC TS_II_NDIS Driver #109
> Physical Address. . . . . . . . . : 11-22-33-44-55-66
> Dhcp Enabled. . . . . . . . . . . : Yes
> Autoconfiguration Enabled . . . . : Yes
> Autoconfiguration IP Address. . . : 169.254.19.237
> Subnet Mask . . . . . . . . . . . : 255.255.0.0
> Default Gateway . . . . . . . . . :
>
> The destination mac address in the multicast data is 01:00:5e:00:00:0d,
> and the multicast IP address is 224.1.1.77. The routing table is set up
> as follows:
>
> Route Table
> ===========================================================================
> Interface List
> 0x1 … MS TCP Loopback interface
> 0x2 …00 1f bc 00 fb ab … Realtek PCIe GBE Family Controller #2 -
> Packet S
> cheduler Miniport
> 0x3 …00 1f bc 00 fb aa … Realtek PCIe GBE Family Controller -
> Packet Sche
> duler Miniport
> 0x4 …11 22 33 44 55 66 … TWC TS_II_NDIS Driver #109 - Packet
> Scheduler Mi
> niport
> ===========================================================================
> ===========================================================================
> Active Routes:
> Network Destination Netmask Gateway Interface
> Metric
> 0.0.0.0 0.0.0.0 10.50.40.1 10.50.41.234
> 20
> 10.50.40.0 255.255.254.0 10.50.41.234 10.50.41.234
> 10
> 10.50.41.234 255.255.255.255 127.0.0.1 127.0.0.1
> 10
> 10.255.255.255 255.255.255.255 10.50.41.234 10.50.41.234
> 10
> 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
> 169.254.0.0 255.255.0.0 169.254.19.237 169.254.19.237
> 30
> 169.254.19.237 255.255.255.255 127.0.0.1 127.0.0.1
> 30
> 169.254.255.255 255.255.255.255 169.254.19.237 169.254.19.237
> 30
> 224.0.0.0 240.0.0.0 10.50.41.234 10.50.41.234
> 10
> 224.0.0.0 240.0.0.0 169.254.19.237 169.254.19.237
> 30
> 224.1.1.77 255.255.255.255 169.254.19.237 169.254.19.237 1
> 255.255.255.255 255.255.255.255 10.50.41.234 10.50.41.234 1
> 255.255.255.255 255.255.255.255 169.254.19.237 2 1
> 255.255.255.255 255.255.255.255 169.254.19.237 169.254.19.237 1
> Default Gateway: 10.50.40.1
> ===========================================================================
> Persistent Routes:
> Network Address Netmask Gateway Address Metric
> 224.1.1.77 255.255.255.255 169.254.19.237 1
>
> Thanks Thomas!
>
> Jason
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

10

So, I tried using a static IP for the machine, but that didn’t help, and I don’t think it should have. My C# app wants to listen for multicast traffic over 224.1.1.77, and thus it *attempts* to join that group, as shown below (where ipAddr is 224.1.1.77, port is 7777, and joinMcastGroup is true):

private void Listen(IPAddress ipAddr, int port, bool joinMcastGroup)
{
ipEndPoint = new IPEndPoint(ipAddr, port);
udpClient = new UdpClient(port);
if (joinMcastGroup)
{
udpClient.JoinMulticastGroup(ipAddr, 64);
}

udpClient.Client.SetSocketOption(
SocketOptionLevel.Socket, SocketOptionName.ReceiveBuffer, SocketRecvBuffSize);

udpClient.BeginReceive(Receive, null);
}

Here’s the wierd part…When this app connects to the multicast traffic on another mcast ip addr (224.1.1.87) on another NIC on the machine, I see an IGMP v2 join message show up on Wireshark. Likewise, I see an IGMP v2 leave message when I stop the app. This works, and is as expected.

Now, when I start the app listening to my NDIS interface/nic, I see an IGMP v3 join message, with it’s mode set to ‘EXCLUDE’ my 224.1.1.77 address. When I stop the app, I see it sending out an IGMP v3 leave message, with it’s mode set to ‘INCLUDE’ the 224.1.1.77’ address. So, why does the same app, send out two different versions of IGMP messages, and why is it attempting to EXCLUDE the address that I want to listen for when using my NDIS driver???

IGMPv3 supports applications that explicitly signal sources from which they want to receive traffic. With IGMPv3, receivers signal membership to a multicast host group in the following two modes:

INCLUDE mode
In this mode, the receiver announces membership to a host group and provides a list of IP addresses (the INCLUDE list) from which it wants to receive traffic.

EXCLUDE mode
In this mode, the receiver announces membership to a host group and provides a list of IP addresses (the EXCLUDE list) from which it does not want to receive traffic. This indicates that the host wants to receive traffic only from other sources whose IP addresses are not listed in the EXCLUDE list. To receive traffic from all sources, like in the case of the Internet Standard Multicast (ISM) service model, a host expresses EXCLUDE mode membership with an empty EXCLUDE list.

Anyone have any ideas? Obviously I have something configured differently in my NDIS driver versus the other NICs installed on the system, and I was hoping that this tid-bit of info would shed some light on the difference.

Thanks guys!

Jason

11

I’ll give a think, but it’s not an area I am familiar with.

You can use OIDScope to see if there are differences between your miniport
and the other miniport configuration.

http://pcausa.com/Utilities/ndistools.htm

Good luck!

Thomas F. Divine
http://www.pcausa.com

From:
Sent: Wednesday, January 27, 2010 11:51 AM
To: “Windows System Software Devs Interest List”
Subject: RE:[ntdev] Miniport driver configuration for receiving/indicating
Multicast data

> So, I tried using a static IP for the machine, but that didn’t help, and I
> don’t think it should have. My C# app wants to listen for multicast
> traffic over 224.1.1.77, and thus it attempts to join that group, as
> shown below (where ipAddr is 224.1.1.77, port is 7777, and joinMcastGroup
> is true):
>
> private void Listen(IPAddress ipAddr, int port, bool joinMcastGroup)
> {
> ipEndPoint = new IPEndPoint(ipAddr, port);
> udpClient = new UdpClient(port);
> if (joinMcastGroup)
> {
> udpClient.JoinMulticastGroup(ipAddr, 64);
> }
>
> udpClient.Client.SetSocketOption(
> SocketOptionLevel.Socket, SocketOptionName.ReceiveBuffer,
> SocketRecvBuffSize);
>
> udpClient.BeginReceive(Receive, null);
> }
>
> Here’s the wierd part…When this app connects to the multicast traffic on
> another mcast ip addr (224.1.1.87) on another NIC on the machine, I see an
> IGMP v2 join message show up on Wireshark. Likewise, I see an IGMP v2
> leave message when I stop the app. This works, and is as expected.
>
> Now, when I start the app listening to my NDIS interface/nic, I see an
> IGMP v3 join message, with it’s mode set to ‘EXCLUDE’ my 224.1.1.77
> address. When I stop the app, I see it sending out an IGMP v3 leave
> message, with it’s mode set to ‘INCLUDE’ the 224.1.1.77’ address. So,
> why does the same app, send out two different versions of IGMP messages,
> and why is it attempting to EXCLUDE the address that I want to listen for
> when using my NDIS driver???
>
> IGMPv3 supports applications that explicitly signal sources from which
> they want to receive traffic. With IGMPv3, receivers signal membership to
> a multicast host group in the following two modes:
>
> INCLUDE mode
> In this mode, the receiver announces membership to a host group and
> provides a list of IP addresses (the INCLUDE list) from which it wants to
> receive traffic.
>
> EXCLUDE mode
> In this mode, the receiver announces membership to a host group and
> provides a list of IP addresses (the EXCLUDE list) from which it does not
> want to receive traffic. This indicates that the host wants to receive
> traffic only from other sources whose IP addresses are not listed in the
> EXCLUDE list. To receive traffic from all sources, like in the case of the
> Internet Standard Multicast (ISM) service model, a host expresses EXCLUDE
> mode membership with an empty EXCLUDE list.
>
> Anyone have any ideas? Obviously I have something configured differently
> in my NDIS driver versus the other NICs installed on the system, and I was
> hoping that this tid-bit of info would shed some light on the difference.
>
> Thanks guys!
>
> Jason
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

12

Hey Thomas,

Thanks for the cool tool! :slight_smile: Unfortunately, everthing seems to match between the two NICs, including OIDs and their values (except for Xmit OIDs, which my driver dosen’t support). :frowning:

I’ll bet David Cattley would know…where are you David? :slight_smile:

Jason

13

I would not make that bet. Thomas has been three strides ahead of me on
every post to this thread. I am quite sure I don’t fill his shoes.

I did notice however that your chosen ‘fake’ MAC address might be an issue.
You have chosen to use a multicast address as your station address.
‘11-xx-xx-xx-xx-xx’ is a multicast address. Now that might not be an issue
but it sure is strange.

I realize that your link is half-duplex. None the less, what do you do with
send requests?

When you take an IP multicast datagram and inject it up as a receive, how do
you form the MAC header? What do you put in the two address fields?

If you happen to be putting the current (local) station address in the
sender’s address, it will look like a reflected loopback packet. If you have
not set the option in your MC socket to hear your own MC sends, the system
(TCPIP) might be filtering it out.

But otherwise, I’ve got nothing but other straws to grasp at. I would be
tracing the packet as it went up through the various layers to try an
determine if and where it got filtered out.

Good Luck,
Dave Cattley

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Wednesday, January 27, 2010 12:39 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Miniport driver configuration for receiving/indicating
Multicast data

Hey Thomas,

Thanks for the cool tool! :slight_smile: Unfortunately, everthing seems to match between
the two NICs, including OIDs and their values (except for Xmit OIDs, which
my driver dosen’t support). :frowning:

I’ll bet David Cattley would know…where are you David? :slight_smile:

Jason

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

14

Hey David!

I am creating an Ethernet II header, which has the dest/src mac addresses that came in the packet, and the 0x0800 type field. I have to create an Ethernet II header because we’re getting a very odd Motorola Ethernet header (coming from the Motorola encoder). But, it does not have the local MAC address in there.

Let me change the 11-22-33-44-55-66 mac address to one within our production range of IPs, and see if it fixes anything. That’s a very good point!

Oh, and I drop all send requests on the ground (but complete the request, so NDIS thinks it got sent).

So, lemme’ try this, and I’ll post my results! :slight_smile:

Thanks guys!

jason

15

Because you have indicated that Wireshark shows your multicast packets I
assume then that the byte order on the EtherType field is correct: 08-00 ,
right? Because putting 0x0800 into a USHORT field would result in 00-80 in
the Ethertype, not what you are expecting.

Good Luck,
Dave Cattley

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Wednesday, January 27, 2010 1:44 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Miniport driver configuration for receiving/indicating
Multicast data

Hey David!

I am creating an Ethernet II header, which has the dest/src mac addresses
that came in the packet, and the 0x0800 type field. I have to create an
Ethernet II header because we’re getting a very odd Motorola Ethernet header
(coming from the Motorola encoder). But, it does not have the local MAC
address in there.

Let me change the 11-22-33-44-55-66 mac address to one within our production
range of IPs, and see if it fixes anything. That’s a very good point!

Oh, and I drop all send requests on the ground (but complete the request, so
NDIS thinks it got sent).

So, lemme’ try this, and I’ll post my results! :slight_smile:

Thanks guys!

jason

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

16

Yep, I was wary of the MAC address as well.

You may need to inspect some of the packets that are being sent and spoof
replies. One case comes to mind: Windows expects packets (ok, frames…)
sent to the Ethernet Broadcast address or to a MC address in the MC address
list to be looped back to the host.

(Dave, correct me if I’m wrong on this…).

Thomas F. Divine
http://www.pcausa.com

From:
Sent: Wednesday, January 27, 2010 1:44 PM
To: “Windows System Software Devs Interest List”
Subject: RE:[ntdev] Miniport driver configuration for receiving/indicating
Multicast data

> Hey David!
>
> I am creating an Ethernet II header, which has the dest/src mac addresses
> that came in the packet, and the 0x0800 type field. I have to create an
> Ethernet II header because we’re getting a very odd Motorola Ethernet
> header (coming from the Motorola encoder). But, it does not have the
> local MAC address in there.
>
> Let me change the 11-22-33-44-55-66 mac address to one within our
> production range of IPs, and see if it fixes anything. That’s a very good
> point!
>
> Oh, and I drop all send requests on the ground (but complete the request,
> so NDIS thinks it got sent).
>
> So, lemme’ try this, and I’ll post my results! :slight_smile:
>
> Thanks guys!
>
> jason
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

17

I think whether or not a NIC supports self-loopback & whether or not that
capability is claimed in OID_GEN_MAC_OPTIONS determines if NDIS steps in and
does the loopback automatically or not. I (perhaps incorrectly) assumed
that Mr. Summerour derived his virtual miniport from NETVMINI which sets
NDIS_MAC_OPTION_NO_LOOPBACK and thus ‘punts’ loopback to the wrapper.

The only reply spoofing I have used in the past was ARP (and on occasion
DHCP).

It never occurred to me that additional help to make MC work might be
necessary. That is something I will have to try on a Virtual Ethernet
device.

Cheers,
Dave Cattley

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Thomas F. Divine
Sent: Wednesday, January 27, 2010 2:04 PM
To: Windows System Software Devs Interest List
Subject: Re: RE:[ntdev] Miniport driver configuration for
receiving/indicating Multicast data

Yep, I was wary of the MAC address as well.

You may need to inspect some of the packets that are being sent and spoof
replies. One case comes to mind: Windows expects packets (ok, frames…)
sent to the Ethernet Broadcast address or to a MC address in the MC address
list to be looped back to the host.

(Dave, correct me if I’m wrong on this…).

Thomas F. Divine
http://www.pcausa.com

From:
Sent: Wednesday, January 27, 2010 1:44 PM
To: “Windows System Software Devs Interest List”
Subject: RE:[ntdev] Miniport driver configuration for receiving/indicating
Multicast data

> Hey David!
>
> I am creating an Ethernet II header, which has the dest/src mac addresses
> that came in the packet, and the 0x0800 type field. I have to create an
> Ethernet II header because we’re getting a very odd Motorola Ethernet
> header (coming from the Motorola encoder). But, it does not have the
> local MAC address in there.
>
> Let me change the 11-22-33-44-55-66 mac address to one within our
> production range of IPs, and see if it fixes anything. That’s a very good

> point!
>
> Oh, and I drop all send requests on the ground (but complete the request,
> so NDIS thinks it got sent).
>
> So, lemme’ try this, and I’ll post my results! :slight_smile:
>
> Thanks guys!
>
> jason
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

18

David,

The new mac address 00-25-8E-00-00-01 didn’t cause the mc to start working. :confused:

Yes, you did incorrectly assume that I derived my mp from NETVMINI. :slight_smile:

So, in watching the mc joins over another NIC, I see an ICMP QUERY msg come across (from the router I assume), which I think is asking, ‘hey, anyone interested in any multicast traffic?’. Once the NIC gets that message, then I see another ICMP JOIN msg go out saying ‘yeah, I’m interested in 224.1.1.87’. At that point, the mc data flows up fine on that NIC.

So, I’m thinking that what I have to do is once the mp driver is ‘ready’, I need to send up an ICMP QUERY msg, so that my NIC will send down the ICMP JOIN msg, which will then trigger the mc address that I’m interested in ‘224.1.1.77’ to be added to my mp driver’s MulticastList, at which point the data will start flowing up. That’s the theory anyway.

I’ll give that a try and post back tomorrow (have to run out and do some errands).

Thanks guys!

Jason

19

Okay, got it working!!!

Since my mp driver isn’t a typical driver (which typically communicates w/ a NIC hardware board that’s actually connected to a physical router), I had to spoof a IGMP QUERY (version 2) message in my bus driver, and send it up to the mp driver, which then sent it up to NDIS.

This message is periodically sent out from a router, asking “hey, is anyone interested in multicast traffic?”. I don’t know exactly how this msg is handled in NDIS for each network interface, but until it gets this message, no application can request a multicast join, and receive mc data properly (over that interface).

Once I sent the IGMP QUERY message up, I started seeing the proper OID_802_3_MULTICAST_LIST msg come down to my mp driver, when I ran the app asking to join mc address ‘224.1.1.77’. Once the ‘224.1.1.77’ mc address got added to the address list, data was then allowed to then be indicated up to NDIS, and the app received it.

Problem solved, and I learned something useful. :slight_smile:

Since my mp driver receives a transport stream (containing Ethernet/Ip/Udp data) directly from my bus driver, it’s not connected to a router, hence the reason it never received the IGMP QUERY msg, and I had to spoof one.

Thanks for everyones help!

Jason