Dual NIC and crossover cable

Hello,
I'm having a bit of a odd networking problem.

I've got a linux 2.4 computer with two network cards and would
like to ping from one port to the other through a crossover
cable. (it's for basic hardware verification).

If I just ping the other NIC linux is clever enough and route it
through the loopback instead, so I have turned off loopback interface.

lo : off
eth0 : 192.168.2.2
eth1 : 192.168.2.5

By adding an explicit -host route for the 'other' network card I am
able to send out ping echo request on eth0 (as seen on the
LED/iptables/sniffer)
# ping -I eth0 192.168.2.5

But I don't recive any echo request on eth1 (according to
iptables/sniffer).
Where does this ping end up ?

I must be doing something wrong..any suggestions ?

Thanks.
Devlin

On 4 Aug 2005 14:32:19 -0700, devlin <(E-Mail Removed)> wrote:
> Hello,
> I'm having a bit of a odd networking problem.
>
> I've got a linux 2.4 computer with two network cards and would
> like to ping from one port to the other through a crossover
> cable. (it's for basic hardware verification).
>
> If I just ping the other NIC linux is clever enough and route it
> through the loopback instead, so I have turned off loopback interface.
>
> lo : off
> eth0 : 192.168.2.2
> eth1 : 192.168.2.5
>
> By adding an explicit -host route for the 'other' network card I am
> able to send out ping echo request on eth0 (as seen on the
> LED/iptables/sniffer)
> # ping -I eth0 192.168.2.5
>
> But I don't recive any echo request on eth1 (according to
> iptables/sniffer).
> Where does this ping end up ?
>
> I must be doing something wrong..any suggestions ?

I imagine you have conflicting routing (same network for both interfaces).
I have not tried this, but try configuring each nic for netmask
255.255.255.255 and broadcast same as its IP and then host routes to the
other IP:

route add -host 192.168.2.5 /dev/eth0
route add -host 192.168.2.2 /dev/eth1

But Linux may still know that both IPs are local, so it might not even
go out over the wire.

David Efflandt wrote:
> On 4 Aug 2005 14:32:19 -0700, devlin <(E-Mail Removed)> wrote:
>>Hello,
>>I'm having a bit of a odd networking problem.
>>
>>I've got a linux 2.4 computer with two network cards and would
>>like to ping from one port to the other through a crossover
>>cable. (it's for basic hardware verification).
>>
>>If I just ping the other NIC linux is clever enough and route it
>>through the loopback instead, so I have turned off loopback interface.
>>
>>lo : off
>>eth0 : 192.168.2.2
>>eth1 : 192.168.2.5
>>
>>By adding an explicit -host route for the 'other' network card I am
>>able to send out ping echo request on eth0 (as seen on the
>>LED/iptables/sniffer)
>> # ping -I eth0 192.168.2.5
>>
>>But I don't recive any echo request on eth1 (according to
>>iptables/sniffer).
>>Where does this ping end up ?
>>
>>I must be doing something wrong..any suggestions ?
>
> I imagine you have conflicting routing (same network for both interfaces).
> I have not tried this, but try configuring each nic for netmask
> 255.255.255.255 and broadcast same as its IP and then host routes to the
> other IP:
>
> route add -host 192.168.2.5 /dev/eth0
> route add -host 192.168.2.2 /dev/eth1
>
> But Linux may still know that both IPs are local, so it might not even
> go out over the wire.
>

That's true!

Using "-I eth0" with "ping" is the way to tell the kernel to realy use
the NIC (as long as theer's no routing conflict).
But there's no way to tell the kernel that the answer must also use
the NIC. There's a short-cut in the IP-Stack.

Next problem is a kind of security feature. The Kernel does not
accept IP packets coming from a NIC where the source IP address
is a local one. Some other PC could otherwise spoof the source IP
address and perform DoS attacs and your Kernel would allow the
traffic, because he thinks it's local traffic.

There was a thread in this newsgroup last year (April/May) about that.
Try to find "Toni Erdmann" with Google-News.

HTH
Toni

Hi all...

Me too have similar situation and am doing my first linux project.
Could you please tell me where ..which location of kernel part I can
find this funda happening ....like Linux/IP stack comparing or finding
the source and destination address are same and re-directing packets to
echo port if source and destination IP address are same?

like file path...?

thanks a lot

Jaggu wrote:
> Hi all...
>
> Me too have similar situation and am doing my first linux project.
> Could you please tell me where ..which location of kernel part I can
> find this funda happening ....like Linux/IP stack comparing or finding
> the source and destination address are same and re-directing packets to
> echo port if source and destination IP address are same?
>
> like file path...?
>

It's sufficient that the destination address of
a packet is any of the local IP addresses to
route the packet via lo.

It's in the IP routing. Unless you understand it,
please do not mess with it. It's the core part
of the networking - a careless modification
will break things, for sure.

Please tell what you're trying to accomplish.
Maybe there's a totally different way to achieve
the desired results.

--

Tauno Voipio
tauno voipio (at) iki fi

Hi Tauno, Thanks a lot....I have an single network interface in the
embedded system I use, as such this port cannot be seen outside(so I
cannot connect to other hosts through cross over cable) rather its data
transmitting pin is internally connected to receiver pin ans other pins
also.

I need to run some application like FTP(on same host) and during it I
need to profile the system (ethernet driver, ftp protocol, kernel, file
system etc) that is my major intention. As such I cannot do FTP because
the packets are not really transmitted to the interface instead they
get software loopbacked(source and destination is same).

so In this situation how can I make packets travel to ether core and
come back?
(I dont want to use raw sockets....and writing data directly to
ethernet core)

thank you

Jaggu wrote:
> Hi Tauno, Thanks a lot....I have an single network interface in the
> embedded system I use, as such this port cannot be seen outside(so I
> cannot connect to other hosts through cross over cable) rather its data
> transmitting pin is internally connected to receiver pin ans other pins
> also.
>
> I need to run some application like FTP(on same host) and during it I
> need to profile the system (ethernet driver, ftp protocol, kernel, file
> system etc) that is my major intention. As such I cannot do FTP because
> the packets are not really transmitted to the interface instead they
> get software loopbacked(source and destination is same).
>
> so In this situation how can I make packets travel to ether core and
> come back?
> (I dont want to use raw sockets....and writing data directly to
> ethernet core)


Is this the same question you posted earlier
to another group?

IIRC, the suggestion was to use raw sockets. What's
wrong with the solution? If the problem is
learning the raw sockets, just go bite the
bullet and tackle the learning: the knowledge
may be worth its tedium in gold later.

There is little (or actually: no) sense to
test the interface with a high-level application
like FTP (it's FTP-TCP-IP-Ethernet). The added
protocol layers only complicate your task, if the
purpose is to show that the interface works.

If you want to show that a high-level
application runs on your interface, you
*do* have to provide the physical layer
interface and another computer to run
the test with.

(Been there - done that: some embedded
Ethernet interfaces and TCP/IP stacks)

--

Tauno Voipio
tauno voipio (at) iki fi

Hi Tauno,

>
>>
> IIRC, the suggestion was to use raw sockets. What's
> wrong with the solution? If the problem is
> learning the raw sockets, just go bite the
> bullet and tackle the learning: the knowledge
> may be worth its tedium in gold later.

raw sockets is fine, I do agree, I love to do that , problem is
this doesn't solve my final intention.When I profile with this solution
I cannot precisely estimate the overall burden to processor given due
to high speed ports like ethernet etc in real time. In real time the
burden depends on device driver and protocol (depends on application).
With raw sockets I cannot estimate top layers burden.
>
> There is little (or actually: no) sense to
> test the interface with a high-level application
> like FTP (it's FTP-TCP-IP-Ethernet). The added
> protocol layers only complicate your task, if the
> purpose is to show that the interface works.
>

No, my intention is not show that the interface works. I know its
non-sense to profile real scenario without actual hardware setup like
without PHY.Iam helpless, am provided as such.I know added protocol
complicates my task but gives me to estimate real time scenario.

thanks for your time and consideration

Jaggu wrote:
> Hi all...
>
> Me too have similar situation and am doing my first linux project.
> Could you please tell me where ..which location of kernel part I can
> find this funda happening ....like Linux/IP stack comparing or finding
> the source and destination address are same and re-directing packets to
> echo port if source and destination IP address are same?
>
> like file path...?
>
> thanks a lot
>

We faced the problem to have a 'ppp0' and 'eth0'
interface and we wanted to send data over ppp0
and receive it thru eth0 (and back) - just to measure
the delays.

Our solution was to modify
"net/ipv4/fib_frontend.c" of 2.4.19 near line 233
to let UDP packets pass, even though the source IP
address is a local one.

The solution was proposed by Ben Greear in 'linux.kernel' mailing list.

http://groups.google.de/groups?q=Gre...ofh.it&rnum=10

http://groups.google.de/groups?hl=de...om%26rnum%3D19

http://groups.google.de/groups?hl=de...om%26rnum%3D27

Toni

Jaggu wrote:

> Hi Tauno, Thanks a lot....I have an single network interface in the
> embedded system I use, as such this port cannot be seen outside(so I
> cannot connect to other hosts through cross over cable) rather its data
> transmitting pin is internally connected to receiver pin ans other pins
> also.
>
> I need to run some application like FTP(on same host) and during it I
> need to profile the system (ethernet driver, ftp protocol, kernel, file
> system etc) that is my major intention. As such I cannot do FTP because
> the packets are not really transmitted to the interface instead they
> get software loopbacked(source and destination is same).
>
> so In this situation how can I make packets travel to ether core and
> come back?
> (I dont want to use raw sockets....and writing data directly to
> ethernet core)
>
> thank you
>

We used 'ppp0' and 'eth0'. The solution below worked for
this configuration. Don't know, whether it works for a
single NIC or not.

You need this patch based on 2.4.19
(just comment or delete those two lines)

--- linux-2.4.19/net/ipv4/fib_frontend.c Fri Aug 2 17:39:46 2002
+++ linux-2.4.19.dev/net/ipv4/fib_frontend.c Sun Sep 15 21:16:44 2002
@@ -233,8 +233,19 @@

- if (res.type != RTN_UNICAST)
- goto e_inval_res;


You need two applications that bind to the interface explicitly
(as "ping -I eth0" does).

int sockfd;
char interface_name[32]; // = "eth0"
struct ifreq iface;

socket(sockfd, ..., SOCK_DGRAM, ....)
bind(sockfd,....,"port")

strncpy(iface.ifr_ifrn.ifrn_name,interface_name,IF NAMSIZ);
if ( setsockopt(sockfd,SOL_SOCKET,SO_BINDTODEVICE,
(void *)&iface,sizeof(iface)) < 0 )
{
perror("setsockopt(...,SO_BINDTODEVICE,...) failed\n" );
exit(1);
}

sendto(sockfd,...)

Toni