Crazy Bearshare?
 

I am working on my own gnutella client. I've found some stange things with Bearshare:

1. If you send a ping to a bearshare client it only responds with addresses that are utilizing port 6346 and 6348.

2. If you look at the x-try of a bearshare client handshake they only ever report addresses that are using port 6346 and 6348.

The end result is that if you start with a bearshare seed, you will never connect to any other clients ever again because your cache will be full of bearshare clients.

Anyone have any insight?

Thanks,

Randy

In which header are you looking, X-Try or X-Try-Ultrapeer?

What mode was that remote servent in, and how many did you try?

What mode was your servent advertising, or did it?

What type of client did you identify your node as?

Gig you verify this by trying it with other servents on your end, like LimeWire, BearShare and Phex?

Are you sure the BearShare servent you probed didn't determine that you were firewalled?

Are you sure it's not a coincidence based on too small a sample run?

Post the text of your pings, followed by the exact text of the pongs.

Output
 

I've verified with a few hundred BearShare clients. It's easy to reproduce. Connect to a BearShare client and issue a ping. It will only respond with 6346/6348 clients. When you connect to any BearShare client check out the X-Try, 99.999% of the time it only has 6346/6348 clients. My app is operating in ultrapeer mode.

If I connect to limewire, or other hosts, they give all clients, not just 6346/6348 clients.

Handshake from two random bearshares:

GNUTELLA/0.6 200 OK
User-Agent: BearShare 5.2.5.6 (Polska)
X-Try: 41.201.101.6:6346,88.199.180.227:6346,77.253.171.1 1:6348,194.246.107.57:6348,83.27.214.173:6348,85.1 78.144.122:6348,89.228.64.32:6348,89.139.111.69:63 48,24.150.219.250:6346,62.238.207.82:6346
X-Requeries: false
X-Ultrapeer: True
X-Ultrapeer-Needed: True
X-Query-Routing: 0.1
Machine: 1,13,1023,1,1608
Pong-Caching: 0.1
Hops-Flow: 1.0
GGEP: 0.5
Bye-Packet: 0.1
X-Degree: 26
X-Ultrapeer-Query-Routing: 0.1
X-Max-TTL: 4
X-Dynamic-Querying: 0.1
X-Probe-Queries: 0.1
Vendor-Message: 0.1
X-Features: chat/0.1

GNUTELLA/0.6 200 OK
User-Agent: BearShare 5.2.1.9
X-Try: 69.121.82.22:6348,85.221.170.113:6348,85.179.193.1 61:6348,76.179.151.205:6346,81.171.28.169:6346,83. 7.161.41:6348,71.14.99.107:6348
X-Requeries: false
X-Ultrapeer: True
X-Ultrapeer-Needed: True
X-Query-Routing: 0.1
Machine: 1,13,446,1,2405
Pong-Caching: 0.1
Hops-Flow: 1.0
GGEP: 0.5
Bye-Packet: 0.1
X-Degree: 26
X-Ultrapeer-Query-Routing: 0.1
X-Max-TTL: 4
X-Dynamic-Querying: 0.1
X-Probe-Queries: 0.1
Vendor-Message: 0.1

Show your ping too. BearShare is probably trying to be compatible with you.

Do you mean to post the IP addresses of the response, or my packet?

By the way, could you expand on the "probably trying to be compatible with you" statement?

Thanks,

Randy

Show the packet header with all the fields.

BearShare adjusts it's behaviour for many factors, such as various header fields.

I know that from here I have no problem seeing a wider variety of port numbers than you do,
and that is probably because I am continuously operating as an ultrapeer with BearShare on a
non-firewalled connection. If you get BearShare 5.1.0b25, put it into ultrapeer mode and make
sure your connection isn't firewalled or your traffic isn't being "shaped" by your ISP, your
packet captures will probably show all the hosts instead of just the ones on default ports.

Thank you for the help Aaron, I will post shortly. One question though. On connect I am given the handshake above, which doesn't give the BearShare client enough time to verify if I am behind a firewall or not. If you look at the handshake above, it gives out all 6346/6348 addresses in its x-tries. Are you saying that BearShare will give out BearShare xtries and BearShare pings until it verifies that you are not firewalled and once it verifies that you are not firewalled it will give out all others?

Thanks,

Randy

Hold the phone. Now I'm seeing the limited results too. It looks like somebody's playing with
the remote controls again. I'm doing fine on my own port number but it looks like everybody
who is using the sabotaged versions 5.2 and up are being herded to just the two ports.

Try filtering out results from all BearShare versions 5.2 and 6 to see if anybody on older versions
is still showing up on other ports.

I am glad I am not losing my mind. =) I will filter and see what happens.