Re: Non compliant hosts with invalid reversed IP

From: "Philippe Verdy" <[email protected]>
> From: "Philippe Verdy" <[email protected]>
>>I can see now a lot of hosts returning QueryHits with nont compliant IP addresses.
>> This is really visible because they indicate results with IPs like:
>>    *.0.0.10 instead of 10.0.0.*
>>    *.*.168.192 instead of 192.168.*.*
>> (these are addresses for hosts behind a router)
>> 
>> Really, the byte order of IP addresses is reversed!
>> Which servent is doing that? (I have lots of results with such addresses, and for this reason, I had to include these two sets of addresses in my hosts filter, however, it means that these servents will also reverse any IP address even if they are not firewalled, so there's no way to identify them clearly).
>> 
>> Is there a signature that can be checked in QueryHits? Can this servent be corrected using a different vendor signature?
> 
> Note that this coincides with a MUCH higher difficulty to connect to the Gnet (hundreds of connection requests failing, and the need to wait for about 30 minutes to get the first connection); I don't think this is caused by spammers or an attack, but really by an incompatible change in some major servent (possibly LimeWire itself in some version?)
> 
> If the IP address format was changed, how is it indicated and how to preserve the compatibility?

For information, I had to clear my local "gnutella.net" hosts cache (except the UHC and Gwebcache addresses) to restore working connections.

It seems that there has been for some time some spammer feeding the Gnet with lots of IP addresses that also owrked when reversed, and given that LimeWire currently prefers connecting first to Gnutella hosts in the local gnutella.net hosts cache before trying the UHC and the Gwebcaches, invalid IP addresses are kept are retried even if none are working now. (may be these were not spammers, but temporary test versions of some vendors, including LimeWire development versions, but I did not find such bug correction in the sources.)

But even with this clearing, I still get lots of replies in Pings and QueryHits, where IP addresses are still in little-endian format instead of the standard network byte order (big endian, "24.1.2.3" is stored so that the first byte is 24, and not 3).