Disabling loopback?

[Warthog]

Hi, I'm trying to do some hardware testing, testing two ethernet NICs I have configured in the same linux server.

I've configured the NICs as so:

eth5 Link encap:Ethernet HWaddr 00:07:43:01:20:EC
inet addr:192.168.0.10 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Interrupt:31 Memory:dfff0000-dfff0fff

eth6 Link encap:Ethernet HWaddr 00:07:43:01:20:ED
inet addr:192.168.0.11 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Interrupt:31 Memory:dfff0000-dfff0fff

I'd like to analyze packets I send from one NIC to the other. I only have one linux server capable of handling these prototype NICs.

However, it seems like the linux kernel is loopbacking packets I send from one interface to the other without ever going out to the NIC.

For instance when I ping through one interface sending to the other:

chris@sdp[38]:~% ping -I eth5 192.168.0.10
PING 192.168.0.10 (192.168.0.10) from 192.168.0.10 eth5: 56(84) bytes of data.
64 bytes from 192.168.0.10: icmp_seq=1 ttl=64 time=0.045 ms
64 bytes from 192.168.0.10: icmp_seq=2 ttl=64 time=0.018 ms
64 bytes from 192.168.0.10: icmp_seq=3 ttl=64 time=0.022 ms

The counters for both interfaces stay as 0. These seem to get routed through the kernel, and never make it out to the NIC:

RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

Is there any way to disable this kernel loopback so that packets are forced to go through the ethernet NIC, even though the destination is ultimately the other NIC in the same machine?

Thanks!

[dilbert]

For instance when I ping through one interface sending to the other:

chris@sdp[38]:~% ping -I eth5 192.168.0.10
PING 192.168.0.10 (192.168.0.10) from 192.168.0.10 eth5: 56(84) bytes of data.

Wouldn't you have to write "ping -I eth5 192.168.0.11" as x.x.x.10 is already on eth5?

To additionally monitor the traffic, maybe you could use ethereal, too. Maybe it gives you somewhat more info.
"cat /proc/net/dev" is presumably from the same network stack data as the content in "ifconfig" already is, I guess.

[Warthog]

Wouldn't you have to write "ping -I eth5 192.168.0.11" as x.x.x.10 is already on eth5?

To additionally monitor the traffic, maybe you could use ethereal, too. Maybe it gives you somewhat more info.
"cat /proc/net/dev" is presumably from the same network stack data as the content in "ifconfig" already is, I guess.

Ah yes, of course, my example was bad. The same behavior happens when I ping -I eth5 192.168.0.11, and that's the problem I was trying to solve. I'm pretty confident the information in ifconfig is correct, I'm not seeing packets arriving at the NIC.

[anomie]

I'd like to analyze packets I send from one NIC to the other. I only have one linux server capable of handling these prototype NICs.

Use tcpdump for this. (If you require a gui, you can use wireshark. This is the project the original ethereal team maintains.)

[dilbert]

With arping and ethereal you could watch one device sending and look if really anything doesn't come back.

arping sends first a broadcast packet and subsequently directed packets only. With " -b" you force it to send always broadcast packets and with " -I ethx" you can force it to use only the device ethx for sending.

[anomie]

OT -

dilbert:

http://www.wireshark.org/

Same developers, same code, different name. The Ethereal network protocol analyzer has changed its name to Wireshark.

[dilbert]

Thanks, anomie for that info. I thought I've seen it recently on a Windows box and thought it was a Windows-only product.

My only remark to tcpdump is, that unfortunately you see only the raw packets and not only for a beginner it is very much easier to have the raw data already broken up into meaningful English words, so get told what sort of packet it is. Almost all the data are translated into meaningful words, even the first three bytes of MAC addresses have the vendor name in English. And it's coloured ... and ... and ... and

[cyberinstru]

Is there any way to disable this kernel loopback so that packets are forced to go through the ethernet NIC, even though the destination is ultimately the other NIC in the same machine?

Basically when u ping from your system, the source IP is set to INADDR_ANY. And when the kernel finds the destination IP to be on the same system, it will simply loopback it.