2004-04-20 01:12:03

by Nick Popoff

[permalink] [raw]
Subject: Testing Dual Ethernet via Loopback

Greetings,

I am trying to write some software to test a dual port ethernet card. I
was hoping to be able to use an ethernet cable to just connect the
ethernet board to itself and then write a program that talks to itself to
make sure that both ports are working. However, I've noticed that Linux
is smart enough to realize it is talking to its own IP address, and it
just delivers the data internally rather than use the network hardware at
all.

So what I'm wondering is if there is a way to force Linux to actually
utilize its network hardware in sending these packets to itself? In other
words, a ping or file transfer from an IP assigned to eth0 to another IP
assigned to eth1 should fail if I unplug the network cable connecting the
two. Any advice on this would be much appreciated. I'm not afraid of
reading kernel source but have no idea where to start on this one.

I'm using 2.4.22 but would use any 2.4 or 2.6 kernel that supported this
behavior. The National Semiconductor DP83815 (natsemi.o) is the
ethernet chipset.



2004-04-20 13:46:38

by Antony Suter

[permalink] [raw]
Subject: Re: Testing Dual Ethernet via Loopback


No special kernel is needed. You have a proper crossover cable
connecting your ethernet cards?

You simply have to assign ip addresses to each card properly. It might
be easiest to assign different subnets to each.
192.168.1.1/255.255.255.0 to the first and 192.168.2.1/255.255.255.0 to
the second. That should get you started.

--
- Antony Suter (suterant users sourceforge net) "Bonta"
- "...through shadows falling, out of memory and time..."


Attachments:
signature.asc (189.00 B)
This is a digitally signed message part

2004-04-20 16:01:41

by Richard B. Johnson

[permalink] [raw]
Subject: Re: Testing Dual Ethernet via Loopback

On Tue, 20 Apr 2004, Antony Suter wrote:

>
> No special kernel is needed. You have a proper crossover cable
> connecting your ethernet cards?
>
> You simply have to assign ip addresses to each card properly. It might
> be easiest to assign different subnets to each.
> 192.168.1.1/255.255.255.0 to the first and 192.168.2.1/255.255.255.0 to
> the second. That should get you started.
>

That's how it should work. However, there appears to be a problem
with ARP (reported off-and-on over several years). The initial connection
fails or ends up going through 127.0.0.1, when you use two boards
on the same machine.

Here is an example:

Script started on Tue Apr 20 11:47:36 2004
# ifconfig
eth0 Link encap:Ethernet HWaddr 00:10:5A:27:7B:16
inet addr:10.100.2.224 Bcast:10.255.255.255 Mask:255.0.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:96538 errors:0 dropped:0 overruns:0 frame:0
TX packets:974 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
Interrupt:18 Base address:0xd000

eth0:1 Link encap:Ethernet HWaddr 00:10:5A:27:7B:16
inet addr:10.106.100.167 Bcast:10.255.255.255 Mask:255.0.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:18 Base address:0xd000

eth1 Link encap:Ethernet HWaddr 00:10:DC:A7:A7:3B
inet addr:10.100.2.223 Bcast:10.255.255.255 Mask:255.0.0.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
Interrupt:18

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:294 errors:0 dropped:0 overruns:0 frame:0
TX packets:294 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0

# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.0.0.0 * 255.0.0.0 U 0 0 0 eth0
10.0.0.0 * 255.0.0.0 U 0 0 0 eth1
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
default hidden-route 0.0.0.0 UG 0 0 0 eth0
# ping 10.100.2.223
64 bytes from 10.100.2.223 icmp-seq:0 ttl:64 time(ms):0.13 lost:0
64 bytes from 10.100.2.223 icmp-seq:0 ttl:64 time(ms):20.31 lost:0
64 bytes from 10.100.2.223 icmp-seq:1 ttl:64 time(ms):0.03 lost:0
64 bytes from 10.100.2.223 icmp-seq:1 ttl:64 time(ms):0.04 lost:0
64 bytes from 10.100.2.223 icmp-seq:2 ttl:64 time(ms):0.03 lost:0
64 bytes from 10.100.2.223 icmp-seq:2 ttl:64 time(ms):0.04 lost:0
64 bytes from 10.100.2.223 icmp-seq:3 ttl:64 time(ms):0.03 lost:0
64 bytes from 10.100.2.223 icmp-seq:3 ttl:64 time(ms):0.04 lost:0
64 bytes from 10.100.2.223 icmp-seq:4 ttl:64 time(ms):0.03 lost:0
# nslookup 10.100.2.223
Server: octans.analogic.com
Address: 10.100.2.1

*** octans.analogic.com can't find 10.100.2.223: Non-existent host/domain
# nslookup 10.100.2.223
Server: octans.analogic.com
Address: 10.100.2.1

Name: chaos.analogic.com
Address: 10.100.2.224

# uname -a
Linux chaos 2.4.26 #1 SMP Fri Apr 16 15:49:31 EDT 2004 i686
# exit
Script done on Tue Apr 20 11:49:32 2004

I'm on interface 10.100.2.224.
I can ping 10.100.2.223 *** WITH NO CABLE CONNECTED!!! ***

If I execute `ifconfig lo down`, the ping-able connection
goes away so I know how it's being propagated.

It's like Linux is trying to be "helpful" again, figures it
will find the best route to the other interface so it bypasses
the interface and goes through lo. In recent years, Linux has
gotten to be more and more "helpful" like that. This makes
troubleshooting in the real-world very difficult.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.26 on an i686 machine (5596.77 BogoMips).
Note 96.31% of all statistics are fiction.


2004-04-20 22:50:12

by Edgar Toernig

[permalink] [raw]
Subject: Re: Testing Dual Ethernet via Loopback

Nick Popoff wrote:
>
> So what I'm wondering is if there is a way to force Linux to actually
> utilize its network hardware in sending these packets to itself? In other
> words, a ping or file transfer from an IP assigned to eth0 to another IP
> assigned to eth1 should fail if I unplug the network cable connecting the
> two. Any advice on this would be much appreciated.

I don't know if there's some knob for that. What I'm always doing:
tcpdump on one interface and then a broadcast ping on the other one.

If you want to write a hardware test program maybe using raw ethernet
packets is the way to go. These can be send directly to a specific
interface and don't require it to be IP-configured. man 7 packet

Ciao, ET.

2004-04-22 20:01:40

by Pavel Machek

[permalink] [raw]
Subject: Re: Testing Dual Ethernet via Loopback

Hi!

> So what I'm wondering is if there is a way to force Linux to actually
> utilize its network hardware in sending these packets to itself? In other
> words, a ping or file transfer from an IP assigned to eth0 to another IP
> assigned to eth1 should fail if I unplug the network cable connecting the
> two. Any advice on this would be much appreciated. I'm not afraid of
> reading kernel source but have no idea where to start on this one.

tcpdump on eth0, ping non-existant IP on eth1?
--
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms

2004-04-22 20:56:06

by Richard B. Johnson

[permalink] [raw]
Subject: Re: Testing Dual Ethernet via Loopback

On Tue, 20 Apr 2004, Pavel Machek wrote:

> Hi!
>
> > So what I'm wondering is if there is a way to force Linux to actually
> > utilize its network hardware in sending these packets to itself? In other
> > words, a ping or file transfer from an IP assigned to eth0 to another IP
> > assigned to eth1 should fail if I unplug the network cable connecting the
> > two. Any advice on this would be much appreciated. I'm not afraid of
> > reading kernel source but have no idea where to start on this one.

`ifconfig lo down` should do it. This will (should) force linux
to actually use the address supplied and not sneak through the
loopback device.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.26 on an i686 machine (5557.45 BogoMips).
Note 96.31% of all statistics are fiction.


2004-04-22 22:38:47

by Anton Blanchard

[permalink] [raw]
Subject: Re: Testing Dual Ethernet via Loopback


> So what I'm wondering is if there is a way to force Linux to actually
> utilize its network hardware in sending these packets to itself? In other
> words, a ping or file transfer from an IP assigned to eth0 to another IP
> assigned to eth1 should fail if I unplug the network cable connecting the
> two. Any advice on this would be much appreciated. I'm not afraid of
> reading kernel source but have no idea where to start on this one.

Sounds like you need the send-to-self patch:

http://www.ssi.bg/~ja/

We've been using it a lot in the lab, it works well.

Anton

2004-04-22 23:16:52

by Nick Popoff

[permalink] [raw]
Subject: Re: Testing Dual Ethernet via Loopback


On Fri, 23 Apr 2004, Anton Blanchard wrote:
> Sounds like you need the send-to-self patch:
> http://www.ssi.bg/~ja/
> We've been using it a lot in the lab, it works well.

I tried this out yesterday with Linux 2.6.5 at it worked like a charm. Thank
you to everyone who replied with solutions and to the author of this patch!

I thought the idea of pinging an invalid IP from one interface while snooping
with ethereal on the other interface was very clever, but hard to use for
performance testing. :-)