Joel Fernandes writes:
I have a question about sending ping requests from one interface to
another on the same linux machine .
if I'm not mistaken you need a kernel patch for that to work. They can be
found here: http://www.ssi.bg/~ja/#loop (the Send-To-Self section).
The Ping request is being received at the other interface but it is
not generating a response.
Use case: An interface "mesh1" (source) with IP 192.168.3.2 is trying
to ping "mesh0" (destination) with IP 192.168.3.1
The ARP response itself is not being sent from the destination node
(mesh0) to source.
root@joel-laptop:/proc# tcpdump -ennqti mesh0 \( arp or icmp \) -v
tcpdump: listening on mesh0, link-type EN10MB (Ethernet), capture size 96 bytes
02:00:00:00:01:00 > ff:ff:ff:ff:ff:ff, ARP, length 42: Ethernet (len
6), IPv4 (len 4), Request who-has 192.168.3.1 tell 192.168.3.2, length
28
Only ARP requests seen at destination, No ARP response generated!!
but I manage to get past this problem by manually adding entries to
the ARP table of the source interface (mesh1):
root@joel-laptop:/proc# arp -i mesh1 -s 192.168.3.1 02:00:00:00:00:00
Once I add the ARP entries, the ping command is able send packets
from one interface to the other but for some reason, a ping response
is not generated, this seems very strange:
root@joel-laptop:/usr/src/# ping -I mesh1 192.168.3.1
[ping doesn't return anything]
I think the kernel is not routing packets to 192.168.3.2 or 192.168.3.1
out through the external interface. For sending the packet you overcome this
by explicitly setting the outgoing interface (thus overriding routing), but
the response packet is routed according to the kernel's idea of its
destination. You can check this by looking it the output of these two
commands:
ip route get 192.168.3.1
ip route get 192.168.3.2
I think what you'll see is that packets to 192.168.3.2 (the source) are
getting routed via loopback, so you won't see a response.
Perhaps it's kind of simplistic, but I don't see why Julian would keep
updating the send-to-self patches for recent kernels if this would just
work with stock kernels. Then again, he might have his reasons, I don't
know.
Regards,
roel
Monitoring the destination interface of the ping (mesh0):
root@joel-laptop:/proc# tcpdump -ennqti mesh0 \( arp or icmp \) -v
192.168.3.2 > 192.168.3.1: ICMP echo request, id 14124, seq 1, length 64
02:00:00:00:01:00 > 02:00:00:00:00:00, IPv4, length 98: (tos 0x0, ttl
64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.3.2 > 192.168.3.1: ICMP echo request, id 14124, seq 2, length 64
02:00:00:00:01:00 > 02:00:00:00:00:00, IPv4, length 98: (tos 0x0, ttl
64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.3.2 > 192.168.3.1: ICMP echo request, id 14124, seq 3, length 64
02:00:00:00:01:00 > 02:00:00:00:00:00, IPv4, length 98: (tos 0x0, ttl
64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.3.2 > 192.168.3.1: ICMP echo request, id 14124, seq 4, length 64
So the ping packets are being received at destination but the
destination is not sending a response for some reason.. Both ARP and
ICMP responses are not being generated by the destination node thought
it _is_ receiving the requests as verified above.
This seems to be a problem with the network layer of the network
interfaces. I tried looking at the proc entries and seeing if ICMP or
ARP was disabled but everything looks ok.
Any suggestions for solving or understanding this problem is much appreciated,
thanks,
Joel
--
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
