Windows kernel's WskSocket function fails to receive UDP from physical interface

zhax

Hello,
I am using Winsock (WskSocket, WskBind and WskReceiveFrom) in my driver to receive UDP packets on port 4000. Code is based on Windows-driver-samples (wsksample) and it works but only when I send the data locally on loopback interface. Driver do not receive the data when I send packet from other machine thought physical Ethernet interface. In other hand I am able to receive those packet in userpace by for e.g. Hercules app. I'm using clean Windows 10 installation without any antivirus. Before I will include the code, I want to ask is it proper approach to use WskSocket for receive UDP data in driver or should I maybe use Ndis? Are there some additional steps required like filtering settings?

I tried various socket flags, including changing INADDR_ANY to specific IP.

zhax

Edit:
My current suspicions are on receive function which is based on:
https://learn.microsoft.com/en-us/windows-hardware/drivers/network/receiving-data-over-a-datagram-socket
Is remote address set to NULL a correct value in this situation?

// Initiate the receive operation on the socket
Status =
Dispatch->WskReceiveFrom(
Socket,
DatagramBuffer,
0, // No flags are specified
NULL, // Not interested in the remote address
NULL, // Not interested in any associated control information
NULL,
NULL,
Irp
);

Maybe I should be using WskReceive()? Based on description I assumed it's for TCP...

MBond2

what parameters are you passing to WskBind?

zhax

SOCKADDR_IN LocalAddress;
LocalAddress.sin_family = AF_INET;
LocalAddress.sin_addr.s_addr = INADDR_ANY;
LocalAddress.sin_port = RtlUshortByteSwap(SOCKET_PORT);
...
Status = ((PWSK_PROVIDER_DATAGRAM_DISPATCH)(m_socket->Dispatch))->WskBind(m_socket, (PSOCKADDR)(&LocalAddress), 0, m_irp);

Alan_Adams

Something you may have already considered and ruled out, but I do recall that it seems like Microsoft's own firewall defaulted to not allowing UDP that wasn't from the local subset, or something similarly "variable" like that. Allowing us to see results of "this communication works, but this same communication does not work" by default, just depending on where the communication had originated from.

If your user-mode test had communication originating from exactly the same source, then this probably shouldn't be the issue. Still, if you didn't already, you might try explicitly opening Microsoft's firewall for your UDP traffic to the system process, since you confirmed you didn't have any third-party endpoint protection running that would be blocking the traffic. To at least confirm or rule out whether this has any effect on the behavior you're seeing.