How to looparound and not loopback?

Suppose you have two network cards on the same PC
and connect them to a Linksys router and the router assigns
192.168.1.100 and 192.168.1.101

I want to test a UDP code that sends to one of these IP addresses
through the router.

However, the table route seem to force a loopback,
i.e. it knows that the destination IP address is on the same PC so
the router is never reached.


I want to force a looparound, where datagrams destined for IP2 go out
on IP1 card to the router, and back on card IP2, obviously making
sure
they do not go out again on IP1 in a loop but to the receiving code.


Is making changes to the route table the only solution? How?

(E-Mail Removed) wrote:
> Suppose you have two network cards on the same PC
> and connect them to a Linksys router and the router assigns
> 192.168.1.100 and 192.168.1.101
>
> I want to test a UDP code that sends to one of these IP addresses
> through the router.
>
> However, the table route seem to force a loopback,
> i.e. it knows that the destination IP address is on the same PC so
> the router is never reached.
>
>
> I want to force a looparound, where datagrams destined for IP2 go out
> on IP1 card to the router, and back on card IP2, obviously making
> sure
> they do not go out again on IP1 in a loop but to the receiving code.
>
>
> Is making changes to the route table the only solution? How?
>

That's not the way it works. You'd be trying to implement the TCP/IP
protocol in a way it wasn't intended. If you want to route between, you
need to have the NICS and the router interfaces (or sub-interfaces) on
different subnets. Even between two different computers on the same
subnet, packets are exchanged without the router being involved.

....kurt

On Mar 19, 11:38 pm, kurt <k...@nospam.olypen.com> wrote:
> mar...@hotmail.com wrote:
> > Suppose you have two network cards on the same PC
> > and connect them to a Linksys router and the router assigns
> > 192.168.1.100 and 192.168.1.101
>
> > I want to test a UDP code that sends to one of these IP addresses
> > through the router.
>
> > However, the table route seem to force a loopback,
> > i.e. it knows that the destination IP address is on the same PC so
> > the router is never reached.
>
> > I want to force a looparound, where datagrams destined for IP2 go out
> > on IP1 card to the router, and back on card IP2, obviously making
> > sure
> > they do not go out again on IP1 in a loop but to the receiving code.
>
> > Is making changes to the route table the only solution? How?
>
> That's not the way it works. You'd be trying to implement the TCP/IP
> protocol in a way it wasn't intended. If you want to route between, you

How it should work or how it was intended have nothing to do with
anything.
You possibly do not believe that any protocol, esp. a popular protocol
like
TCP/IP was developed (i.e. thousands of ideas tested thousands of
times by thousands of people) by networking physical computers. Then
take the applications that use such protocols. All such testing
requires
looparounds, loopbacks, and many tricks of the trade that do not have
anything to do with the intent of the protocols or applications.

"(E-Mail Removed)" <(E-Mail Removed)> wrote:
>
>How it should work or how it was intended have nothing to do with
>anything.

Eh?

>You possibly do not believe that any protocol, esp. a popular protocol
>like
>TCP/IP was developed (i.e. thousands of ideas tested thousands of
>times by thousands of people) by networking physical computers. Then
>take the applications that use such protocols. All such testing
>requires
>looparounds, loopbacks, and many tricks of the trade that do not have
>anything to do with the intent of the protocols or applications.

You *CANNOT* test serialized data communications code with a
loopback to the same machine.

That is true for RS-232 serial ports, it is also true for TCP/IP.

Trying to do it (which is simple enough with RS-232 that
beginners often do try it) leads to code that appears to work,
but does so *only* because the CPU deals with sequential code
synchronously. In real life that doesn't exist, and the code
fails when the two ends are on separate CPU'S.

TCP/IP was in fact developed on networked physical computers.

--
Floyd L. Davidson <http://www.apaflo.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) (E-Mail Removed)

On Mar 20, 3:39 am, f...@apaflo.com (Floyd L. Davidson) wrote:
> "mar...@hotmail.com" <mar...@hotmail.com> wrote:
>
> >How it should work or how it was intended have nothing to do with
> >anything.
>
> Eh?
>
> >You possibly do not believe that any protocol, esp. a popular protocol
> >like
> >TCP/IP was developed (i.e. thousands of ideas tested thousands of
> >times by thousands of people) by networking physical computers. Then
> >take the applications that use such protocols. All such testing
> >requires
> >looparounds, loopbacks, and many tricks of the trade that do not have
> >anything to do with the intent of the protocols or applications.
>
> You *CANNOT* test serialized data communications code with a
> loopback to the same machine.
>

Do not say *CANNOT* if you have a very limited background on this
subject.

> That is true for RS-232 serial ports, it is also true for TCP/IP.
>

Comparing RS-232 to TCP/IP is like comparing driving a school bus
on the bottom of rocky canyon. RS-232 is a physical interface like
Ethernet, you *CANNOT* compare RS-232 to TCP/IP because both
are intended for totally different tasks. Theoretically you can run
TCP/IP on top of RS-232.

> Trying to do it (which is simple enough with RS-232 that
> beginners often do try it) leads to code that appears to work,
> but does so *only* because the CPU deals with sequential code

What appears to work or not is is the eyes of beholder. If you have
a limited background in software development you always blame
bugs on something else simply because you are not able to
perform a real analysis just a guesswork.

> synchronously. In real life that doesn't exist, and the code
> fails when the two ends are on separate CPU'S.
>

Obviously you have serious problems with grasping the concepts of
multitasking/multiprocessing.

> TCP/IP was in fact developed on networked physical computers.
>

Anybody who knows anything about TCP/IP did most of the
development and testing using loopback or its equivalent,
especially in the early days back in the 70s/80s.
Most of the code can be easily tested in loopback/looparound
configurations. If you find a bug using networked physical
computers you can find the same bug in a loopback/looparound.

Believe me, I did development in X25 and SS7 in the 80s (both
based on serial data comm if it matters to you) and anybody who
would try to test his code using networked physical machines
would be declared nuts. It would be too expensive and too time
consuming.

All this is beyond the subject. The subject is how to modify the
route table. I did some reading in the meantime and found a solution
that works fine.

On Mar 20, 10:50 am, "mar...@hotmail.com" <mar...@hotmail.com> wrote:
> On Mar 20, 3:39 am, f...@apaflo.com (Floyd L. Davidson) wrote:
>
>
>
>
>
> > "mar...@hotmail.com" <mar...@hotmail.com> wrote:
>
> > >How it should work or how it was intended have nothing to do with
> > >anything.
>
> > Eh?
>
> > >You possibly do not believe that any protocol, esp. a popular protocol
> > >like
> > >TCP/IP was developed (i.e. thousands of ideas tested thousands of
> > >times by thousands of people) by networking physical computers. Then
> > >take the applications that use such protocols. All such testing
> > >requires
> > >looparounds, loopbacks, and many tricks of the trade that do not have
> > >anything to do with the intent of the protocols or applications.
>
> > You *CANNOT* test serialized data communications code with a
> > loopback to the same machine.
>
> Do not say *CANNOT* if you have a very limited background on this
> subject.
>
> > That is true for RS-232 serial ports, it is also true for TCP/IP.
>
> Comparing RS-232 to TCP/IP is like comparing driving a school bus
> on the bottom of rocky canyon. RS-232 is a physical interface like
> Ethernet, you *CANNOT* compare RS-232 to TCP/IP because both
> are intended for totally different tasks. Theoretically you can run
> TCP/IP on top of RS-232.
>
> > Trying to do it (which is simple enough with RS-232 that
> > beginners often do try it) leads to code that appears to work,
> > but does so *only* because the CPU deals with sequential code
>
> What appears to work or not is is the eyes of beholder. If you have
> a limited background in software development you always blame
> bugs on something else simply because you are not able to
> perform a real analysis just a guesswork.
>
> > synchronously. In real life that doesn't exist, and the code
> > fails when the two ends are on separate CPU'S.
>
> Obviously you have serious problems with grasping the concepts of
> multitasking/multiprocessing.
>
> > TCP/IP was in fact developed on networked physical computers.
>
> Anybody who knows anything about TCP/IP did most of the
> development and testing using loopback or its equivalent,
> especially in the early days back in the 70s/80s.
> Most of the code can be easily tested in loopback/looparound
> configurations. If you find a bug using networked physical
> computers you can find the same bug in a loopback/looparound.
>
> Believe me, I did development in X25 and SS7 in the 80s (both
> based on serial data comm if it matters to you) and anybody who
> would try to test his code using networked physical machines
> would be declared nuts. It would be too expensive and too time
> consuming.
>
> All this is beyond the subject. The subject is how to modify the
> route table. I did some reading in the meantime and found a solution
> that works fine.- Hide quoted text -
>
> - Show quoted text -

Would you mind sharing the solution you refer to ?

Thx,
Kalyan

On 19 Mar 2007, in the Usenet newsgroup comp.os.linux.networking, in article
<(E-Mail Removed) .com>, (E-Mail Removed)
wrote:

>Suppose you have two network cards on the same PC
>and connect them to a Linksys router and the router assigns
>192.168.1.100 and 192.168.1.101
>
>I want to test a UDP code that sends to one of these IP addresses
>through the router.
>
>However, the table route seem to force a loopback,
>i.e. it knows that the destination IP address is on the same PC so
>the router is never reached.

You have two choices. You can hack the networking code, and eliminate
the loopback function - this doesn't mean disabling the interface, but
actually re-working the stack so that the bits are sent out the appropriate
interface. Good luck with that, as the task is not simple.

The other choice would be to configure the Linksys router to act as a NAT
(network address translator) device - such that it accepts packets for
(example) 192.168.2.xxx and translates the address to the "other"
192.168.1.xxx destination. This will still have problems, as the _replies_
will be routed via the loopback as they will have source and destination
addresses on the same 192.168.1.xxx network.

>I want to force a looparound, where datagrams destined for IP2 go out
>on IP1 card to the router, and back on card IP2, obviously making sure
>they do not go out again on IP1 in a loop but to the receiving code.

This will work for "one-way" traffic, but not for TCP or anything that
required a reply of any form.

>Is making changes to the route table the only solution? How?

You've decided that the single/computer, two NIC method will solve some
problem - but you need to find a more appropriate solution to what ever
that original question is.

Old guy

"Kalyan Manchikanti" <(E-Mail Removed)> wrote:
>On Mar 20, 10:50 am, "mar...@hotmail.com" <mar...@hotmail.com> wrote:
>>
>> All this is beyond the subject. The subject is how to modify the
>> route table. I did some reading in the meantime and found a solution
>> that works fine.- Hide quoted text -
>>
>> - Show quoted text -
>
>Would you mind sharing the solution you refer to ?

Loopbacks are useful trouble shooting tools to test continuity
of physical circuits. As a testbed for code development it is a
serious mistake.

--
Floyd L. Davidson <http://www.apaflo.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) (E-Mail Removed)