1

I stopped Windows 7 Firewall in Services, but it (or one of its minions) is still dropping packets.

I am trying to use rtiddsping (custom ping for the DDS framework I'm using) to debug a DDS communication problem between two Windows machines. The machine that should be receiving the ping drops them with the message "The Windows Filtering Platform has blocked a packet" showing up in the Event Viewer.

Event Properties Pic

I stopped Windows Firewall Service, but the packets still get dropped. I can see the blocked packets in Wireshark on the receiving machine. What's going on? What am I missing? Is Windows Filtering Platform something separate? I don't see it running in Services.

In response to @Frank below, yes, I have tried enabling the firewall and creating rules to allow the programs I desire. See picture below.

Firewall Rules Pic

In response to @ernie below, here are two screenshots from the Event Viewer with DDS Spy off. Notice it disallows both the inbound packet and the inbound connection.

Inbound Packet Pic

Inbound Connection Pic

Update: In response to @ernie in the comments below, I created a DDS application that publishes and subscribes on the same computer to see if WFP is working as designed and the DDS middleware is simply dropping the packet.

With the same computer publishing and subscribing, I did not see any blocked DDS packets in the Event Viewer and messages got through as expected. I think that when the Event Viewer says "The Windows Filtering Platform has blocked a packet" it means the packet stops there and does not get routed on.

Why are these packets are being blocked by WFP?

Improve this question
6
  • WFP is separate from the firewall, and is a Microsoft tech that lets programmers write tools to access packets. It looks like you're using a program (rtiddsspy.exe) which is intercepting the packets.
    – ernie
    Commented Apr 25, 2013 at 20:03
  • @ernie, rtiddsspy.exe one of the tools that isn't seeing them. It's supposed to be a DDS-Wireshark. So it should see them, but also allow them to be routed. I turned rtiddsspy.exe off, and still didn't get the packets in rtiddsping. Note that the Windows Filtering Platform blocked the packets just the same, pointing now to rtiddsping.exe.
    – kmort
    Commented Apr 25, 2013 at 20:17
  • have you tried enabling the firewall and creating an allow rule? I know, its antithetical, but I've found its an effective solution in cases where I've had the same problem.
    – Frank Thomas
    Commented Apr 25, 2013 at 20:23
  • @FrankThomas Yes I have tried that. See edit above.
    – kmort
    Commented Apr 25, 2013 at 20:35
  • I'm not 100% familiar with it, but the way I read those logs is that rtiddsping.exe used WFP to block the packet, which would seem to be as designed.
    – ernie
    Commented Apr 25, 2013 at 20:37

1 Answer 1

Reset to default
1

I don't know why the WFP appears to be blocking these packets, but I worked around finding this particular answer with some configuration for DDS. My best guess is I misconfigured DDS.

For Googlers, here's what I was missing:

1) An environment variable on the QNX side called NDDS_DISCOVERY_PEERS. Set it like this:

export NDDS_DISCOVERY_PEERS=udpv4://239.255.0.1,udpv4://127.0.0.1,udpv4://<remote_IP_here>

2) On the Windows 7 side, an environment variable by the same name. Set it like this:

set NDDS_DISCOVERY_PEERS=udpv4://239.255.0.1,udpv4://127.0.0.1,udpv4://<remote_IP_here>

3) One more note for folks new to DDS: the QOS settings for a particular topic need to be the same on both sides, or you'll have problems.

This comes from the RTI DDS 5.0 User Manual section 14.2.2

Also note that if you call rtiddsping -peer remoteIPaddress on both sides, you don't have to have the discovery environment variable set.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .