[tg] abt srource IP addr in server log..

[Barbara Denny]

Hello,

You must remember TG is only a user process.  Whatever
happens regarding source address selection takes
place in the kernel if you have not specified it.
It is possible to tell the kernel which source
address you want to use if their are multiple ones.
In TG there is undocumented feature of giving 2 IP
addresses in the association spec. The first one is 
the source; the second is the destination. Glancing 
at the code, it looks like it is set up to work with 
udp, but not tcp (testing also seems to verify this).
If you really want to force the binding to a
particular
source address when you BEGIN the tcp connection,
you can modify the code (see prot_dgram.c for an 
example. The change would be made in prot_stream.c). 
I might be able to make the change and test it out 
soon to verify it works for TCP.I just don't have 
the time today and I won't have the time to do an 
official release of TG soon.

Remember on the receive side you can use
INADDR_ANY (0.0.0.0) in the script to accept the 
"connection" from any address.  The source 
address of the data flow will be recorded in
the ouput file for the data sink. If the source
address doesn't change when you are using
udp, I imagine this is just the way things 
work in the linux kernel. Even though the
path is now through you other link, the source
address doesn't get modified.  I don't have
the resources to replicate your test case.

I am not sure what you asking me regarding 
ressession setup with TCP. I am not sure exactly 
what you are trying to do and what behaviour you are
seeing. If the TCP connection breaks when you change
links, myy immediate reaction is to think the problem 
you are having with TG and TCP has nothing to do 
with TG  and TG cannot "fix" it.  It has to do with 
the  Internet  architecture.  TCP uses the IP address 
to help identify the connection.  If you do something
to  force the IP address to "change", you will cause 
the connection to break.   However, maybe you want to 
do something else but I need to understand what that 
is. Right now I don't know. Now if the kernel really
doesn't bother to "invalidate" the source address
when it uses a different interface then there is
a chance the tcp connection won't break.  Again, I
don't have the resources to replicate your test.  
You could try running tcpdump to see what goes 
on the wire in the udp and tcp case. It is interesting
that you are reporting that UDP doesn't change
its source address when you cause packets to
use the other link. This would make me think that
the TCP connection might have a chance of staying
up.  Now whether this is the correct behavior is
another question...

Overall it sounds like you are trying to show 
some type of fault tolerant behavior, versus emulating

mobility.  In some ways, the problem is similar
so I suggest looking into those areas to deepen
your understanding. There probably is also some 
discussion of it under the topic of multihoming too.


barbara

--- prashant soni <soni_prash at yahoo.co.uk> wrote:

> 
> dear barbara
> thnx it seems it will work for me as u have rightly
> pointed out abt [ ] in using options,..
>  
> one more problem i am facing..
> 
> actually i have set  a kind of demonstration for
> redundent communication between two Fedora core3
> machines connected through two crossover cable (one
> primary another secondary channel) Two NIC in each
> comp..Two IP for each comp...
> now data usually goes thru primary srource IP ,
> (primary cable.) and .if i unplug it it goes thru
> secondary channel (cable)..thru secondary srs IP..
> to destination..
> [ little static routing table database trick ]
> n it works for UDP..for TCP applications  it
> requires resession setup..
> 
> now my problem is when i use TG for generating
> random UDP packets at server log it shows only one 
> srs IP address..though i have unpluged that cable n
> data r coming from secondary cable thru seconadry
> NIC.. TG server log shows same IP for source..why
> ?????
> hope i m clear in my question.. 
> 
> for TCP application .. resession setup how could i
> employ in TG  whenever primary chennel goes
> out...some hints r welcome
> 
> thanx..
> 
> Flying is learning how to throw yourself at the
> ground and miss. 
> Prashant Soni 
> Room No 330, Sarayu Hostel 
> IIT Madras, Chennai - 36,mo no 09380552468 
> _______________________________________________
> tg mailing list
> tg at postel.org
> http://www.postel.org/mailman/listinfo/tg
> _______________________________________________
> tg mailing list
> tg at postel.org
> http://www.postel.org/mailman/listinfo/tg
>