Perilaku khusus (dan AFAICT) yang sedikit tidak terdokumentasi dalam iputils ping : Anda melakukan ping sendiri.
Jika Anda ping 0inilah yang terjadi (diedit dan dikomentari untuk kejelasan):
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()bukan POSIX, tapi saya berasumsi itu menyalin perilaku inet_addr()ketika kurang dari 4 desimal sedang dikonversi. Dalam kasus nomor tunggal dot-less, itu hanya disimpan ke alamat jaringan biner, dan 0x00000000setara dengan bentuk bertitik 0.0.0.0.
Anda dapat melihat ini jika strace(sebagai 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.
Anda juga dapat melihat perubahan jika Anda mengikat antarmuka tertentu :
# 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.
Sementara 0 dapat diperlakukan sebagai 0.0.0.0 dan alamat broadcast dalam banyak kasus itu jelas bukan apa yang dilakukan ping . Ini khusus-kasus ini berarti "IP utama dari antarmuka yang bersangkutan" (dengan beberapa penanganan tambahan untuk kasus multicast / broadcast).
RFC 1122 §3.2.1.3 menjelaskan perilaku: baik 0.0.0.0 dan alamat IP dengan jaringan ditutup ("nomor host", misalnya 0.0.0.1 dalam kasus loopback) berarti "host ini di jaringan ini".
(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.
Setidaknya dalam kasus 0 atau 0.0.0.0 itulah yang pingberperilaku iputils , ping lain dan OS lain mungkin berperilaku berbeda. Misalnya ping FreeBSD 0.0.0.0 melalui rute default (yang saya pikir tidak benar "perilaku").
ping 1atau 0.0.0.1tidak cukup bekerja seperti yang diharapkan (bukan untuk saya, iputils-sss20101006 ).