Спеціальна (та AFAICT) незначно недокументована поведінка в iputils ping
: ви пінг себе.
Якщо у вас ping 0
це є, що відбувається (сильно відредагований і прокоментований для ясності):
if (inet_aton(target, &whereto.sin_addr)) == 1) {
// convert string to binary in_addr
}
// inet_aton returns 1 (success) and leaves the `in_addr` contents all zero.
if (source.sin_addr.s_addr == 0) {
// determine IP address of src interface, via UDP connect(), getsockname()
}
// special case for 0 dst address
if (whereto.sin_addr.s_addr == 0)
whereto.sin_addr.s_addr = source.sin_addr.s_addr;
inet_aton()
це не POSIX, але я припускаю, що він копіює поведінку, inet_addr()
коли конвертується менше 4 десяткових знаків. У випадку без крапкового одиничного числа воно просто зберігається у двійковій мережевій адресі та 0x00000000
еквівалентно пунктирній формі 0.0.0.0
.
Ви можете бачити це, якщо ви strace
(як root):
# strace -e trace=network ping 0
socket(PF_INET, SOCK_RAW, IPPROTO_ICMP) = 3
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(1025),
sin_addr=inet_addr("0.0.0.0")}, 16) = 0
getsockname(4, {sa_family=AF_INET, sin_port=htons(58056),
sin_addr=inet_addr("127.0.0.1")}, [16]) = 0
...
PING 0 (127.0.0.1) 56(84) bytes of data.
Ви також можете побачити зміни, якщо замість цього прив'язати до певного інтерфейсу:
# strace -e trace=network ping -I eth0 0
socket(PF_INET, SOCK_RAW, IPPROTO_ICMP) = 3
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4
setsockopt(4, SOL_SOCKET, SO_BINDTODEVICE, "eth0\0", 5) = 0
connect(4, {sa_family=AF_INET, sin_port=htons(1025),
sin_addr=inet_addr("0.0.0.0")}, 16) = 0
getsockname(4, {sa_family=AF_INET, sin_port=htons(58408),
sin_addr=inet_addr("192.168.0.123")}, [16]) = 0
setsockopt(3, SOL_RAW, ICMP_FILTER, ...)
[...]
PING 0 (192.168.0.123) from 192.168.0.123 eth0: 56(84) bytes of data.
Хоча 0 може трактуватися як 0,0.0,0, а широкомовна адреса у багатьох випадках очевидно не те, що робить ping . Це спеціальні випадки, коли це означає "первинний IP відповідного інтерфейсу" (з деякими додатковими обробками для багатоадресних / трансляційних випадків).
RFC 1122 §3.2.1.3 пояснює поведінку: і 0,0.0.0, і IP-адреса з відключеною мережею ("номер хоста", наприклад, 0.0.0.1 у випадку зворотного зв'язку) означають "цей хост у цій мережі".
(a) { 0, 0 }
This host on this network. MUST NOT be sent, except as
a source address as part of an initialization procedure
by which the host learns its own IP address.
See also Section 3.3.6 for a non-standard use of {0,0}.
(b) { 0, <Host-number> }
Specified host on this network. It MUST NOT be sent,
except as a source address as part of an initialization
procedure by which the host learns its full IP address.
Принаймні у випадку 0 або 0,0.0.0, так ping
поводиться iputils , інші пінг-програми та інші ОС можуть поводитися по-різному. Наприклад, FreeBSD пінгує 0.0.0.0 за маршрутом за замовчуванням (що, на мою думку, не є "правильним" поведінкою).
ping 1
або 0.0.0.1
не дуже працює, як сподівались (не для мене все одно, iputils-sss20101006 ).