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.
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.
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.
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?
kmort
Posted 2013-04-25T19:56:56.057
Reputation: 1 609
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 – 2013-04-25T20:03:53.107
@ernie,
rtiddsspy.exeone 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 turnedrtiddsspy.exeoff, and still didn't get the packets inrtiddsping. Note that the Windows Filtering Platform blocked the packets just the same, pointing now tortiddsping.exe. – kmort – 2013-04-25T20:17:59.517have 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 – 2013-04-25T20:23:19.767
@FrankThomas Yes I have tried that. See edit above. – kmort – 2013-04-25T20:35:47.880
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 – 2013-04-25T20:37:21.113
Interesting. I read it as
rtiddsping.exehas port 7910 open and was waiting for a packet. (This same binary can act as both publisher and a subscriber. You give it command line parameters to tell it if it is the publisher or subscriber. Probably should have said that before. Sorry. On this machine it is set up as a subscriber.) Interestingly enough, neither port shows up innetstat -a, nor are they well-known ports. – kmort – 2013-04-25T20:44:58.127