Newbie problem: queryHit not recognized by LimeWire
 

Hi guy,
I wrote a small program that connects to an ultrapeer and receives a certain query message with queryHit message. I'm testing my thingy vs. gtk-gnutella (works fine, even downloading a file from myself) and vs. LimeWire.
The problem is that LimeWire won't even show the queryHit i've sent in it's GUI (while gtk-gnutella does). I thought maybe it's because i'm not sending a urn, so i did - but still no luck. I'm not sending the other extra (QHD, i think). Than i thought it might be something with the TTL and HOPS - but i tried changing values and still it didn't work.
I am connecting both my LimeWire and my small client to the same ultrapper, thus getting the query i'm sending and sending back queryHit (obviously a wrong one, since it's not displayed in the GUI).
Following are the details, please help me understand what's wrong with me (besides the obvious, of course).

Query (that limewire sent my small client after i hit the search button):
GUID
payload (query)
TTL - 2
Hops - 1
Length - 27
Min Speed - 132
Search - aaa bbb ccc ddd eee

queryHit (that my small client sends back and LimeWire doesn't show as a result but gtk-gnutella does):
GUID (same one as from query)
payload (queryHit)
TTL - 4
Hops - 0 (i guess i'm wrong here or in the TTL but i tried few things)
queryHit
count - 1
port (my prog's port)
ip (my prog's ip)
speed - 260
Hit
index - 963 (rand)
size - size (of a file i'm testing with)
name - aaa bbb ccc ddd eee (exact as in the query)
extra - urn:sha1:"urn i made up"
Servent ID - i made up but i'm consistent

Regards (and thanks in advance),
Snayit

Maybe LimeWire drops "exact" matches by default nowadays. Hops 0 is correct, a TTL of 4 is probably OK but overkill, just use the Hops value of the query + 1 as TTL for the reply.

Thanks for the response
 

I also tried - when i got TTL 2 and Hops 1 to send TTL 3 and Hops 0, but still didn't help. What else could be the problem?

It could be the IP address or the port number. Is that a private IP address or a public one? In doubt, try the standard port number. What I meant with "exact" matches is the filename. It's rather unlikely that a legit reply matches the search term bit-by-bit. Try a random filename instead because might the receiver might consider such replies spam. Maybe LimeWire ignores small files. If possible try to capture a valid reply in the wild and just use that with GUID corrected of course. I could imagine there's something wrong
with your layout at the end of the packet which is ignored by gtk-gnutella but not LimeWire.
Provide a hexdump of packet you send.

Thanks so much for the help
 

attached is my packet dump. I forgot to mention that i'm running both my application and LimeWire on the same machine, does it make any difference?

Not sure it attached the file, trying again.
 

Sorry...

The packet looks fine to me. Well, yes if the receiver has the same IP address as given in the packet, that could be a reason for a client to ignore the reply albeit that wouldn't be good behaviour. Maybe LimeWire requires that you send extended query hit data and specify your vendor ID. Again, that's not quite clever but it might help against lazy/stupid spammers. It's probably best if you directly ask some LimeWire developer.

I'll check in another computer too
 

Thanks for all your help :)

Snayit

I checked several more things, and i have another question:
 

Can it be a GUID problem? Must i encode my IP and port into the GUID or something? now i also checked my program vs. Phex and it works too, only LimeWire and FrostWire won't accept my queryHit.

Thanks,
Snayit

Found the problem
 

My problem was that i did not have a QHD in my message, so i've added it and it works now.

Thanks.