The specification for identifying mainline clients is the "v" key in the root dictionary of every message.
Various clients send you an "ip" key, to helpfully convince you what your external ip and port are.
Obviously evil (or just plain buggy) clients will try to convince you otherwise.
These are in the wild. I noticed a South Korean client that claimed that it was a uTorrent client (UTz\xAD) that:
114.200.XX.XX:345YY v:UTz\xAD is trying to convince me I'm: 114.200.XX.XX:440ZZ
The port was correct, but the ip was the buggy/malicious clients own.
A Vietnamese 'uTorrent' client (UTy\xA3) claimed that I was 192.168.1.1:440ZZ, which while it had the port correct, thought I was on an internal network.
113.182.XX.XX:44XXX v:UTy\xA3 is trying to convince me I'm: 192.168.1.1:440ZZ
Other UTy\xA3 clients claimed similar nonsense
A US client thinks I'm in Belgium and one from Pakistan thinks I'm on its LAN.
50.33.XX.XX:10XXX v:UTy\xA3 is trying to convince me I'm: 94.224.YY.YY:440ZZ
182.186.XX.XX:47XXX v:UTy\xA3 is trying to convince me I'm: 192.168.1.1:440ZZ
Tokens are passed with each message, to supposedly help identify each message. Many clients just don't bother making this meaningful.
Some variations that I've noticed:
The UT client seems to use 4 bytes of random looking data
The LT, and Zo clients seems to use 2 bytes
Timestamp ie. a number rendered in ascii 10047026 which appears to increase by one with each request.
Some use a random-looking string of 8 bytes
One particularly broken client had the token of ASCII '1', and kept requesting data from differing port numbers
Another uses the format 'abcde12733' with the number part increasing due to different queries.
Yet another uses the format 'get_peers608', with the number part increasing.
There appears to be an oddity with some clients identifying as UT (Mostly UTy\xA3) requesting find_node with the following pattern:
0000xxxx0000xxxx0000xxxx0000xxxx0000xxxx
It's statistically improbable that you'd want to look for an node like this.