While I may not be absolutely sure about this, because it's Bearshare you're testing with, what you might be receiving is a Bearshare spy packet as well as a ping. Basically it's an encrypted packet of some sort that Bearshare sends to everyone, but is intended for other Bearshare servents. It supposedly contains versioning information (as stated by Vinnie), but nobody has really been able to verify the information contained in it. It always shows up as a query and always has a payload of 88 bytes. And apparently the IP address field within this packet is always wrong so it's no use trying to respond to it.

After giving it a bit of thought, this theory fits rather well because you stated you're receiving a total of 134 bytes. Well, if you do the math, the header of a gnutella packet is always 23 bytes. A ping is basically just a header packet... it has no payload. The Bearshare spy packet is a query with a payload of 88 bytes meaning the entire packet is 111 bytes. Add everything up and you've got 134 bytes. Following this theory through, I am assuming this is the very first packet that is sent out by Bearshare whenever a connection is established with a Bearshare servent. So, assuming the address from this packet is the address that you used to respond to with a pong, it would explain why your Bearshare servent didn't report receiving any data.

At any rate you'll have to filter that spy packet out. According to what I've read on it, it shows up as a query but isn't structured as one. A normal query ends in a null and this packet doesn't terminate this way so the best thing to do is just ignore any query packets that don't terminate with a null. You'll also find that you receive this same packet when you first connect to a host cache.

Here's the thread about the Bearshare spy packets.