Re: [UDT] UDT (Appears) to not complete the full NAT cycle

[Sanjay U. <san...@ya...>]

Hi Yunhong,

Thanks for the suggestion. The suggested idea couldnt be made to work, since the server side has to connect to the client and client has to connect to the client. so this means server has to know before hand which client to connect. logically it does'nt fit into my application. Next, I tried this :-

bool rz = true;
int err = UDT::setsockopt( socket, 0, UDT_RENDEZVOUS, &rz, sizeof(bool));
if (err == UDT::ERROR) {
    printf("setsockopt(UDT_RENDEZVOUS) = %s\n", UDT::getlasterror().getErrorMessage());
}
int err = UDT::bind(socket, (SOCKADDR *) &addr, sizeof(addr));
if (err == UDT::ERROR) {
    printf("Bind Error: = %s\n", UDT::getlasterror().getErrorMessage());
    return 1;
}
UDT::listen( socket, 1);  // Making the socket Listen
UDTSOCKET newSocket = UDT::accept( socket, (sockaddr *) &newAddr, &nNewAddr);

this above code (I just tried) didnt work, it gave me "Send" "Debug" Error. And I suppose the way to use Rendezvous connection is to initiate connect from both ends as I said above, which really doesnt serve my application purpose.

If I understand correctly, UDT has a new port for reply, on the server side, so that it can keep accepting on the original port (listening on).

But as I see, this has some issues, when the clients are behind NAT's. I dont know if someone in the list has tried to work from behind NAT to have a connection. I am assuming from different cisco router docs, that they too have a similar policy as iptables for natting UDP packets.

Can you please answer me 
1) Can the UDT be used as a Server Client, where the server preserves the src port it listens on, for replies ?
2) And do we have a list of NAT's where the present UDT implementation works soundly. (I Know vmware nat it works)

warm regards



Yunhong Gu <yu...@la...> wrote: 

Hi, Sanjay,

The UDT server creates a new UDP socket upon receiving a new connection 
request. The new socket has a different port number.

You may use the RENDEZVOUS mode connection. It overkills,  but should 
work.

Yunhong

Yunhong Gu, Ph.D., Research Scientist

National Center for Data Mining
University of Illinois at Chicago
SEO 700, M/C 249, 851 S Morgan St
Chicago, IL 60607-7045
T (312) 413-9576
F (312) 355-0373

On Fri, 2 Jun 2006, Sanjay Upadhyay wrote:

> Hi Yunhong,
>
> Here is an issue which severely restricts UDT.  (apparently)
> I have an existing send / recv file, which seems to not work in an environment where the requester is behind an IPTABLES nat and the responder is on the lan without any firewall.
>
> REQUEST DIRECTION
>    CLIENT-A   -----> IPTABLES-NAT ---> SERVER
> RESPONSE DIRECTION (BROKEN)
>    SERVER     ------> IPTABLES-NAT  -X->  CLIENT-A
>
> here the iptables-nat is not sending the response back to the client-A where the request should go, hence the communication is not established, and a UDT::Connect() returns an error.
>
> Apparently it looks like an iptables-nat configuration issue. So I wrote down a simple UDP based communication from client-A to server and which works OK. SO, I turned to the ehthereal captures.. and here is what I got..
>
> Here is the setup
> Server listens on port 9800 with IP 192.168.0.78.
> client-A is behind a iptables-nat and has the 172.16.54.11 address.
> Nats public interface is 192.168.0.100 and internal interface is 172.16.54.1
>
> 1. CLIENT-A : -->  172.16.54.11:1456 --> 192.168.0.78:9800
> 2. NAT : <-- 172.16.54.11:1456  -->  172.16.54.1:9788
> 3. NAT:  --> 192.168.0.100:9788 --> 192.168.0.78:9800
> 4. SERVER: --> 192.168.0.78:13221 --> 192.168.0.100:9788
> 5. NAT: <-- Rejects, as the src port of the UDP response is 13221, while its looking for an UDP response with src port as 9800, for PORT Preservation and reforwarding back to 172.16.54.11:1456 (it's originating IP:PORT)
>
> Is there a way that the responses preserve the source port the (acting) server is listening on ?
>
> regards
>
>
> Sanjay Upadhyay
> Mobile +91-9231683108
> AIM/Yahoo/Hotmail (Screen Name) - saneax
> ICQ 76529342
> SKYPE glowfriend
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com



Sanjay Upadhyay
Mobile +91-9231683108
AIM/Yahoo/Hotmail (Screen Name) - saneax
ICQ 76529342
SKYPE glowfriend
 __________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com