By accident I had a typo and discovered that I can ping and ssh to IP address 10.8.290 ... right one octet is missing. Can someone explain it to me? Is this part of the protocol or some linux-black-magic (I am using Debian)?
user@ws:~$ ping -c3 10.8.290
PING 10.8.290 (10.8.1.34) 56(84) bytes of data.
64 bytes from 10.8.1.34: icmp_req=1 ttl=62 time=0.910 ms
64 bytes from 10.8.1.34: icmp_req=2 ttl=62 time=0.686 ms
64 bytes from 10.8.1.34: icmp_req=3 ttl=62 time=0.708 ms
--- 10.8.290 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1998ms
rtt min/avg/max/mdev = 0.686/0.768/0.910/0.100 ms
user@ws:~$ ssh root@10.8.290
The authenticity of host '10.8.290 (10.8.1.34)' can't be established.
ECDSA key fingerprint is 21:bd:7e:fb:1e:6d:1e:c1:e9:11:c0:a9:73:a8:cf:85.
Are you sure you want to continue connecting (yes/no)? no
Host key verification failed.
It works because you are using a value of 290 for the third byte of the ip address. A byte can store values from 0 to 255, giving 256 values. Since an IPv4 address is a 4 byte value passing 290 to the third byte leads to an integer overflow into the 4th byte -> 290 - 256 => 34
It has nothing to do with a protocol "feature". ping simply don't validate the values of the individual octets of the target command line argument and simply passes it to the lower level C function inet_aton() (aton means ascii to number). This results in pinging 10.8.1.34.
I'm not sure, but I expect other versions of ping (on Windows, BSD) behaving the same.