Bogus UDP packets?

I've been working on an application that uses UDP, and today I downloaded the PE demo to analyze my packet data. While PE does correctly report the UDP traffic going to/from the app, it also seems to be reporting additional large packets being received (on the order of around 1828 bytes or so, usually) coming from 0.0.0.0:0, which are filled with zero bytes and which aren't detected within my app by Winsock.

These packets come exactly at the rate at which I'm doing recvfrom() checks, and they occur even if recvfrom() says that no data is waiting. Socket Spy reports these mystery packets, and says they are filled entirely with zeros. The Statistics window does not detect them, however; the "Total Datagrams Received" counter stays constant unless I start sending/receiving "real" data. The problem occurs no matter what port I use.

Any tips would be appreciated.

 

Also, just as a note, I do intend to purchase PE (since it seems like an exceptional tool) if this problem gets resolved, since I need to be certain that all the packet data I'm looking at is real.

 

I'm also seeing this... anyone have any idea? Great software, but if its not accurate we can't buy it.

 

I think there is a small bug in the socket spy which is doing this on certain calls to recvfrom() and recv() with certain parameters. I will have to double check this but thanks for finding this issue.

 

Incase it helps, here's my setup for the recvfrom() call; it's pretty vanilla WinSock stuff:

Code:

static unsigned char sReceiveBuf[2048];
sockaddr_in addr;
int addrSize = sizeof(addr);
memset(&addr, 0, addrSize);
int result = recvfrom(mSocket, (char*)sReceiveBuf, sizeof(sReceiveBuf), 0, (sockaddr*)&addr, &addrSize);

Also, I guess I should mention in my case that the sender/receiver are usually on different ports, i.e. when I sendto() or recvfrom(), the sin_port is often different than the port the socket is on. I figure this is probably no big deal and not the cause of the bug (since it's pretty much standard-issue behavior for NAT-safe applications) but I thought I'd bring it up just incase.

 

Thanks Chris, I'm sure Jason will have a fix this soon.

 

Any progress on this?