5

For a project at work, I need to be able to test various Ethernet NICs by connecting them to a "loopback adapter plug", like this one on various embedded Linux boxen that come off a production assembly line. I'd like to be able to setup two different IP addresses (AddressA and AddressB) on one Ethernet interface, and then run a ping from AddressA to AddressB.

Ex:  ping -I AddressA AddressB

Is this even possible?

Also, is there a test available that would test the Ethernet interface solely on a L2 / MAC address level using the loopback plug? If I recall, RealTek had a diagnostics tool for their 8139 ethernet adapters that did a L2-only loopback test of sorts, and I was wondering if there was a linux tool that did the same.

UPDATE: Added comments about why I'm testing the boxes in the above comments. I'll have to try out some of these ideas this weekend to see what happens. Maybe make my own "loopback adapter plug" using a keystone jack + some wires from a hardware store, and try to see if I can peek at the signals using an oscilloscope or logic analyser to ensure that signals are actually hitting the wire. Since this seems to be harder than expected, our team at work made the decision to test the Linux boxen ethernet ports by picking up a small home NAT router and then pinging the router, and putting that in the hardware test fixtures. Still, I'm intrigued by the technical aspects of this and want to experiment on this subject on my own.

1

4 Answers 4

5

For sure :)

# ip address list dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:1e:4f:9b:4a:ab brd ff:ff:ff:ff:ff:ff
    inet 10.10.141.83/24 brd 10.10.141.255 scope global eth0
    inet6 fe80::21e:4fff:fe9b:4aab/64 scope link 
       valid_lft forever preferred_lft forever
# ip address add 10.10.141.253/24 dev eth0
# ip address list dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:1e:4f:9b:4a:ab brd ff:ff:ff:ff:ff:ff
    inet 10.10.141.83/24 brd 10.10.141.255 scope global eth0
    inet 10.10.141.253/24 scope global eth0
    inet6 fe80::21e:4fff:fe9b:4aab/64 scope link 
       valid_lft forever preferred_lft forever
# ping -I 10.10.141.83 10.10.141.253
PING 10.10.141.253 (10.10.141.253) from 10.10.141.83 : 56(84) bytes of data.
64 bytes from 10.10.141.253: icmp_seq=1 ttl=64 time=0.050 ms
64 bytes from 10.10.141.253: icmp_seq=2 ttl=64 time=0.034 ms
64 bytes from 10.10.141.253: icmp_seq=3 ttl=64 time=0.038 ms
^C
--- 10.10.141.253 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 0.034/0.040/0.050/0.010 ms
# ip address delete 10.10.141.253/24 dev eth0
# ping -I 10.10.141.83 10.10.141.253
PING 10.10.141.253 (10.10.141.253) from 10.10.141.83 : 56(84) bytes of data.
From 10.10.141.83 icmp_seq=1 Destination Host Unreachable
From 10.10.141.83 icmp_seq=2 Destination Host Unreachable
From 10.10.141.83 icmp_seq=3 Destination Host Unreachable
^C
--- 10.10.141.253 ping statistics ---
4 packets transmitted, 0 received, +3 errors, 100% packet loss, time 3016ms

Actually dead simple. :) (Just kidding, it's always simple if you already know it)

I'm not sure L2 would really work but with ip neigh you can should be able to modify the arp cache also (so much for dead simple)

4
  • 2
    Will those pings actually make it on to the wire, or will the IP stack of the machine realise that the destination IP is another address on the same interface and generate the response internally? Jun 9, 2009 at 22:41
  • I'm not sure but I think it's the IP stack taking care about it. A short test showed that I can add IPs that do not exist in my network and the pings will still work Jun 9, 2009 at 22:50
  • You might want to expand the ip commands so it's clearer what you're doing. "ip address list" is a little more obvious than "ip a ls". Jun 9, 2009 at 23:08
  • Good point, I'm used to the iproute toolset so much I tend to forget what this stuff actually stands for :) Jun 9, 2009 at 23:17
3

You might find that arping is more likely to hit the wire, as this uses arp, and therefore avoids the IP stack completely.

1

In this scenario its doubtful the signal will ever actually 'hit the wire'. Since the device will see that it has both IP address assigned to one interface, all of the MAC look-up / routing (if the two interfaces are in different subnets) will happen in the system itself and never hit the physical interface.

The loopback connector can be used to trick the box into seeing the interface as 'up' so you can do this testing, but just using a normal cable and a spare switchport would accomplish the same thing.

If instead you mean you will be connecting eth0 to eth1 in the same box, then you can just use a cross-over cable, but the same thing may happen as above.

Ethernet loopback plug: http://www.tikkiweb.net/loopback

2
  • The goal of my test would be to ensure that the PHY and MAC work on the ethernet adapter in the embedded PC, so it's a requirement that the signal hits the wire. The embedded PC has only one ethernet port, eth0, so I cannot use the cross-over cable recommendation. I was hoping there was an app similar to the RealTek 8X39 ethernet diagnostics suite for MS-DOS available in Linux that just tests the L2 hardware.
    – J. Polfer
    Jun 10, 2009 at 15:43
  • As I mentioned in my update, we've made the decision to "test" the port using a home router by bringing up eth0, pinging the router, and bringing down eth0 as you mention in your second paragraph. At this point, I'm more curious as to whether or not the signal will "hit the wire" when using a loopback plug, so thanks for your input. I still think I'm going to try playing around anyway.
    – J. Polfer
    Jun 10, 2009 at 15:49
1

I did a bit of research and found this page on converting the ethernet signals to light, and testing that in a loopback configuration: http://ronja.twibright.com/testing/ploss_tetrapolis_ping.php.

Unfortunately, this isn't a true ping, as you simply only see the same ICMP packet twice in Wireshark/tcpdump. It does guarantee that the signal hits the wire though.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .