Hello group, I am just wondering what is happening when we "ping" the NIC on our own machine. I can understand that the ping programme is only a user level programme while the ping server is usually integrated into the kernel. So, I guess what happens when we "ping" an IP address is that: first, the ping programme sends requests to the kernel on the local machine. The kernel will look at the destination address of this ICMP request and if it is an externel address, the kernel will send this request out to the appropriate NIC, but if it heads to the NIC's address on the local machine, the kernel will handle this request without sending it to its own NIC or anywhere else. Then when the results of echo request come back, the kernel will send them back to the "ping" programme (in the case of pinging local NIC, the kernel will send the results back immediately). Any idea whether my understanding is correct? Thanks for anyone looking at this and have a nice day! Best wishes, Xiaochuan

> Generally speaking, "pings" are routed in exactly the same way as all > other IP packets. > So this can confirm that pinging the host's own NIC IP address will only induce the packets sending from "ping" program to "kernel" and then "kernel" to "ping" program. The echo request will not even be sent to the physical NIC... I think I can actually observer this: when pinging the local NIC's IP, the LED on the NIC doesnt blink, nor does the LED on the switch to which the NIC is connected... If the packet only travel between ping programme and the kernel, this explains why the LED doesnt blink.. Regards, Xiaochuan

On Fri, 16 Nov 2007, in the Usenet newsgroup comp.os.linux.networking, in article <fhk66c$mv3$1@gemini.csx.cam.ac.uk>, Xiaochuan Shen wrote: ]Robert Harris wrote: >> Generally speaking, "pings" are routed in exactly the same way as >> all other IP packets. > >So this can confirm that pinging the host's own NIC IP address will >only induce the packets sending from "ping" program to "kernel" and >then "kernel" to "ping" program. Ping (and virtually all other "user" applications) do not know anything about the network. The application creates a data packet and hands it to the kernel "hey - send this out please". The kernel then makes all of the decisions about which interface to use, and handles translating destination names to appropriate IP addresses and all. In the case where a packet is determined to be destined for "this" computer (and the kernel knows all of the IP addresses that belong to "this" computer), it just sticks the packet in the "loopback" transmit buffer... which is exactly the same as the "loopback" receive buffer - "hey, a packet just arrived". The only hardware involved is a chunk of kernel memory space (RAM). >The echo request will not even be sent to the physical NIC... The _packet_ (no matter what it is) won't be sent to the NIC. >I think I can actually observer this: >when pinging the local NIC's IP, the LED on the NIC doesnt blink, >nor does the LED on the switch to which the NIC is connected... The kernel knows what addresses belong to it. Why should it send the packet out on to the crowded highway... ah... out on to the Ethernet (or any other network) if it is of no interest to anyone else - why make unnecessary noise? Another question - if you send a packet out onto the wire, who sends it back to you? The other systems on the wire will just look at you and laugh. >If the packet only travel between ping programme and the kernel, >this explains why the LED doesnt blink.. Correct. The hardware can be a charred cinder - as long as the kernel was able to _load_ the NIC driver without complaints, then sending to the IP address of the NIC will work, because the NIC is not involved. Not plugged in? So what? Please don't post the same question to multiple newsgroups. Old guy