This is wierd!?
 

At first I thought I had a bug in my 'InspectPacket' Routine. All of the routed pongs i'm receiving have only spaces for the messageID. And the length is correct for a messageID(15). After reviewing my logfile with more attention, I found that this is ONLY the case when I recive a 'routed' pong. The pongs I recieve from my connected servant are correct, as well as the ping messageID's as well. The connected servant is BearShare 2.4.2 on another pc through my router/switch with BS. having 3 internet servants connected to it.

Any clues as to what i'm doing wrong?

Here is a clip of my logfile:

*Note: the empty brackets did contain 16 spaces, but pasting it here altered that. Trust me the MsgId length is correct, it was just full of " "'s

Received Ping On Connection: 1 At: 6/10/2002 6:44:05 AM
DescriptorID: {hñ Fº~ÿzvý
ˆ }
TTL: 1
Hops: 0
Payload Length: 0


Sent Pong On Connection: 1 At: 6/10/2002 6:44:05 AM
DescriptorID: {hñ Fº~ÿzvý
ˆ }
TTL: 1
Hops: 0
Payload Length: 14
IPAddress: 192.168.1.3
Port: 6346
Files Shared: 80
Files Size: 6MB


Sent Ping On Connection: 1 At: 6/10/2002 6:44:06 AM
DescriptorID: {ýíHÀÿsø½àÓÐ }
TTL: 7
Hops: 0
Payload Length: 0


Received Pong On Connection: 1 At: 6/10/2002 6:44:06 AM
DescriptorID: {ýíHÀÿsø½àÓÐ }
TTL: 7
Hops: 0
Payload Length: 14
IPAddress: 192.168.1.2
Port: 6346
Files Shared: 54
Files Size: 213MB


Received Pong On Connection: 1 At: 6/10/2002 6:44:09 AM
DescriptorID: { }
TTL: 1
Hops: 6
Payload Length: 14
IPAddress: 24.187.66.38
Port: 6346
Files Shared: 52
Files Size: 192MB


Received Pong On Connection: 1 At: 6/10/2002 6:44:11 AM
DescriptorID: { }
TTL: 4
Hops: 3
Payload Length: 14
IPAddress: 213.189.164.99
Port: 6346
Files Shared: 2
Files Size: 3MB


Received Pong On Connection: 1 At: 6/10/2002 6:44:17 AM
DescriptorID: { }
TTL: 2
Hops: 5
Payload Length: 14
IPAddress: 24.68.248.38
Port: 6346
Files Shared: 1
Files Size: 3MB


Received Pong On Connection: 1 At: 6/10/2002 6:44:22 AM
DescriptorID: { }
TTL: 6
Hops: 1
Payload Length: 14
IPAddress: 80.132.56.51
Port: 6346
Files Shared: 12
Files Size: 906MB


Sent Ping On Connection: 1 At: 6/10/2002 6:44:29 AM
DescriptorID: {\™-{¥^9‚ÿKuÉ> }
TTL: 7
Hops: 0
Payload Length: 0


Received Pong On Connection: 1 At: 6/10/2002 6:44:29 AM
DescriptorID: {\™-{¥^9‚ÿKuÉ> }
TTL: 7
Hops: 0
Payload Length: 14
IPAddress: 192.168.1.2
Port: 6346
Files Shared: 54
Files Size: 213MB


Received Pong On Connection: 1 At: 6/10/2002 6:44:36 AM
DescriptorID: { }
TTL: 2
Hops: 5
Payload Length: 14
IPAddress: 213.73.221.213
Port: 6346
Files Shared: 236
Files Size: 1GB


Received Pong On Connection: 1 At: 6/10/2002 6:44:39 AM
DescriptorID: { }
TTL: 2
Hops: 5
Payload Length: 14
IPAddress: 4.62.78.132
Port: 6346
Files Shared: 118
Files Size: 455MB


Received Ping On Connection: 1 At: 6/10/2002 6:44:44 AM
DescriptorID: {ÜÞHX,ÑËOÿ}.Go§ }
TTL: 1
Hops: 0
Payload Length: 0


Sent Pong On Connection: 1 At: 6/10/2002 6:44:44 AM
DescriptorID: {ÜÞHX,ÑËOÿ}.Go§ }
TTL: 1
Hops: 0
Payload Length: 14
IPAddress: 192.168.1.3
Port: 6346
Files Shared: 80
Files Size: 6MB


Received Pong On Connection: 1 At: 6/10/2002 6:44:48 AM
DescriptorID: { }
TTL: 4
Hops: 3
Payload Length: 14
IPAddress: 158.75.63.86
Port: 6346
Files Shared: 5
Files Size: 629MB


Received Pong On Connection: 1 At: 6/10/2002 6:44:49 AM
DescriptorID: { }
TTL: 4
Hops: 3
Payload Length: 14
IPAddress: 65.119.183.231
Port: 6346
Files Shared: 1246
Files Size: 5GB


Received Ping On Connection: 1 At: 6/10/2002 6:44:59 AM
DescriptorID: {Ì~3ã½Àý§ÿ#&h¹Ê }
TTL: 1
Hops: 0
Payload Length: 0


Sent Pong On Connection: 1 At: 6/10/2002 6:44:59 AM
DescriptorID: {Ì~3ã½Àý§ÿ#&h¹Ê }
TTL: 1
Hops: 0
Payload Length: 14
IPAddress: 192.168.1.3
Port: 6346
Files Shared: 80
Files Size: 6MB


Sent Ping On Connection: 1 At: 6/10/2002 6:45:07 AM
DescriptorID: {|èÖ†93ÿƒQÕìjŸ }
TTL: 7
Hops: 0
Payload Length: 0


Received Pong On Connection: 1 At: 6/10/2002 6:45:07 AM
DescriptorID: {|èÖ†93ÿƒQÕìjŸ }
TTL: 7
Hops: 0
Payload Length: 14
IPAddress: 192.168.1.2
Port: 6346
Files Shared: 54
Files Size: 213MB


Received Ping On Connection: 1 At: 6/10/2002 6:45:09 AM
DescriptorID: {•?HhYHåÿ8ÅV¤ }
TTL: 7
Hops: 0
Payload Length: 0


Sent Pong On Connection: 1 At: 6/10/2002 6:45:09 AM
DescriptorID: {•?HhYHåÿ8ÅV¤ }
TTL: 7
Hops: 0
Payload Length: 14
IPAddress: 192.168.1.3
Port: 6346
Files Shared: 80
Files Size: 6MB


Moak?, Morgwen?

Could well be a bug in BS. Routed pongs usually are cached pongs, so that could explain it. But I wasn't aware BS would cache pongs and also cache the TTL and Hops ( in my case, I don't )

But even if they are cached pongs, standard operating procedure would be to insert my messageID into the cached pong then send it to me. Correct? I am no real fan of Vinnie or his BS, (no pun intended) but I would almost have to give him a little more credit than distributing a version of BS with a flaw like this in it.

I assume that your app does not suffer this problem? Has anyone ever seen this before?

After a bit of research using a sniffer, i have found that ALL routed pongs (at least through Bearshare) have a messageID of: {00000000-0000-0000-0000-000000000000}. This does not seem to follow accepted procedure.

It is my understanding (correct me if i'm wrong) that when receiving a pong with a messageID that matches a previously seen ping, it is forwarded through the connection the ping was received (if not pongcaching).

If pongcaching Is being used, and the servant receives a ping, the servant dips into it's pongcache (if the cache is sufficently full) and INSERTS the message id of the RECEIVED ping (the receiving client never knows the difference, with exception of TTL & hops), and sends it back through the connection from which it came, this reducing traffic on the network.

I do understand there are variants of this scheme, but I have not seen any that stated you should insert a messageID of all zero's.

Is this normal practice? I mean, i guess theres nothing wrong with it. It make the identification of routed pongs a snap. but again, Is this normal practice? ie. do I need to incorporate this into my servant? It does not seem wise to hardcode something like this into pong handling routines.

Yes, it has to match your ping's message ID, or for whatever ping you have forwarded (which didn't show in your log). So it is either a bug in BS (although older version) or there's something in your code.

All pings in the log above where originated by my servant there where no forwarded pings at all. The only pings sent through this connection(the only connection) where created by me. Therefore all routed pongs to me are for me. Correct?

As you can see, when i sent a ping it had a messageID of X when I received a pong(ping reply) from the connected servant(hops = 0), the messageID matches X, BUT all other pongs received after (Hops > 0) have this 'zero'ed out' messageID.

This log was created using BS 2.4.4 ( I can't go much higher in the BS version because it will kick me off when it gets enough BS clients.

look at the log:


*Ping Sent By Me*

Sent Ping On Connection: 1 At: 6/10/2002 6:19:44 PM
MessageID: {Ü
Øî„0þÿhÎ?ò }
FuncID: 0
TTL: 7
Hops: 0
Payload Length: 0

*Pong From Connected Servant* **MessageID is Correct**

Received Pong On Connection: 1 At: 6/10/2002 6:19:45 PM
MessageID: {Ü
Øî„0þÿhÎ?ò }
FuncID: 1
TTL: 7
Hops: 0
Payload Length: 14
IPAddress: 192.168.1.2
Port: 6346
Files Shared: 56
Files Size: 215MB

*Routed Pong through Connected Servant* **MessageID is NOT Correct**

Received Pong On Connection: 1 At: 6/10/2002 6:19:45 PM
MessageID: { }
FuncID: 1
TTL: 6
Hops: 1
Payload Length: 14
IPAddress: 211.44.xxx.xxx
Port: 6346
Files Shared: 54
Files Size: 670MB

*Routed Pong through Connected Servant* **MessageID is NOT Correct**

Received Pong On Connection: 1 At: 6/10/2002 6:19:52 PM
MessageID: { }
FuncID: 1
TTL: 1
Hops: 6
Payload Length: 14
IPAddress: 200.255.xxx.xxx
Port: 6346
Files Shared: 34
Files Size: 70MB

**UPDATE**

Using Gnucleus, I monitored the good and bad packets being received. The image below tells the story. I personally would like to thank Vinnie for producing and distributing a such fine product as BearShare. Thank you for the hours of headbanging trying to debug my code that I thought must have been flawed. I will never again over-estamate you.

P.S. The connected servant was BearShare 2.6.2

Click here
 

This pretty much explains everything:
http://www.limewire.com/index.jsp/pingpong

YEs
 

I believe this defect is fixed in BearShare 3.0.0.

In any event, the GUID on pings and pongs doesn't really matter, since these messages are no longer routed.

Re: YEs
 

No longer routed?

As of 6/12/2002 7:07:11 AM they still where... in the sense that a servant still needs to see a pong as a response to one of it's previous pings.

At least by BearShare 2.6.2...:D

Re: YEs
 

Vinnie:

It's true that cached pongs are no longer routed, but the GUID does matter for some still though (I still feel we need to backward keep compatibility in mind for a while longer).

This is what I do when I return cached pongs:

-- Set the GUID to that of the received PING

-- Set the TTL to Hops + 1 of the PING (ie, Hops = 0 -> TTL = 1, Hops = 4 -> TTL = 5) I noticed from Gnutellian it varies a lot in your case

Gnutellian:

Most clients these days don't look at the GUID of pongs anymore. They they will just store any pong that passes by. This will cause their host cache to fill up faster, and without less frequent ping. This is part of the ping/pong caching, not just LimeWires, but many variants.

The GUID of all zeroes also ensures that in most cases, the pong can't be routed anymore because you wouldn't have a matching routing table. Personally, I would find it more elegant if the TTL/Hops was used insetad, but I have done (and still am) overriding some meanings of functions as well. Specifically, the ConnectBack feature (which, although recommended by someone else, would be replaced by an updated version).

This didn't occur to me before, because I wasn't aware Vinnie was actually doing this though, and the varying TTL/Hops trhew me off too.

ConnectBack
 

Just wanted to point out that the "Connect Back" feature is actually unnecessary...the original 0.4 Gnutella protocol specification is sufficient!

I had *great* results with BearShare by just advertising pongs when I want a connect back.

This is how we implemented auto-detect of firewalled status.

BearShare lets loose with pongs for up to 1 full minute (per hour). If it gets "ins" then we aren't firewalled, else we are firewalled.

You can see the state transitions in BearShare 3.0.0 by putting the cursor over the Hosts LED and observing the messages in the balloon; e.g. "Ponging for incoming connections"

Also, the Network balloon shows some other states, like the firewalled detection progress.

BearShare 2.6.x has these features as well, but lacks the enhanced feedback in the indicator area.

I highly recommend anyone who is interested in implementing connect-back features seriously think about just using pongs to entice other servents into providing a connect back.

Sorry for seeming like a maniac about It Vinnie, but...

I'm writing a servant, and don't have a staff of developers, it's just me...

As far as the 'Routed Pong' issue, I am following the specs outlined in:

http://www.limewire.com/index.jsp/pingpong

as well as general guidance from:

http://cvs.sourceforge.net/cgi-bin/v...ella/Draft.txt

Earlier in the thread, I myself even stated that it made the identification of pongs easier. I finally(prior to Vinnies posts)
had actually stopped looking at the MsgID in received pongs and just cached them if (TTL>1 and TTL <= MAX_TTL) and (hops > 0 and hops <= MAX_TTL) in an effort to get around this 'anomally'.

Hey, no blood, no foul.

Goodness, just noticed the many typos I made in my previous post.

I like the idea of simply using pings/pongs for firewall detection (by looking at any incoming connections as a response), but how long does that take though? And are you setting the "firewalled" status per connection, or globally? Just curious. The ConnectBack for supporting clients usually takes less than a few seconds.

Fortunately, I didn't.

Its like greased lightning. Try it yourself:
http://download.bearshare.com/BSTEST300b52.exe

Eh? The firewalled status applies to the local servent, not per connection. The status is tested when the first host is connected, and reset when the last host drops. It is also re-tested once per hour, in case their firewalled status changes.

You may not believe it, but user's firewalled status can actually change from hour to hour. Not only that, but they can get different IP addresses, and we re-detect that every hour too.

How? By establishing a few outgoing connections even though we don't need them. Its easy enough to 503 a 0.6 handshake on the 3rd set of headers even if you're outgoing. The Remote-IP does the job.

This even works to detect cases where their IP address changes due to DHCP, and they are using NAT.

A small number of users complained that they were becoming firewalled even though they knew they weren't. In EVERY case, it was user error, they had indeed become firewalled.

Yeah but its so much cooler to implement it in a way that even works with the original Gnutella 0.53 servent.

You're doing fine then. Some problems end up taking longer to solve than they should. Thats just how the cookie crumbles.

But the good news is, there are lots of seasoned Gnutella developers eager to help (myself included).

Looks like you found some.

Actually, I set the firewalled status per connection. Reason being if the Gnutella client is used within a larger network. For example, a school campus. It may be that incoming connections from the Internet are firewalled, but local connections (from dorm to dorm) are not. It's just a small thing though, but it would prevent any unnecesary "push" requests, as we all have noticed can sometimes not work as advertised among different versions (different developers).

hmm
 

If you want to support that feature, then why dont you just use the MIB and get a list of interfaces along with subnet masks?