Korg Remote Desktop

[xinyiman]

So far everything works. It is a pity that the information obtained is not that which allows A and B to establish a P2P connection. Because bidirectional NAT means that when A tries to connect to B it uses a different port than the one used to connect to the controller.

As would be expected: it's a different session with a different endpoint.

I've obviously been wasting my time explaining that you either need to keep a reflector in the link or need to have preexisting pinholes open (which realistically implies that the endpoints are known), so I won't bother saying anything else.

MarkMLl

Sorry MarkMLl then I didn't understand what you meant. What is a reflector in the link? Excuse my ignorance.

[xinyiman]

And how do you create a pre-opened UDP "holes" as you say?

[rvk]

Of course, the controller communicated the data from client A to client B and vice versa. But when client A communicates with the outgoing controller it uses port 1900 (example) of the router when instead it has to create the P2P connection with client B it uses port 1901 (example) due to bidirectional nat (change port based on destination ). Then the port communicated to the controller becomes useless.

You still don't understand.
The controller can see what the external translated port is of A.
It should send THAT port to B, so B can use THAT external port to communicate with A.

The moment you get to the controller A port 1900 doesn't matter anymore for B. It should use the port the controller sends.

The only port thats open is the one the controller sees.
So that's why the controller is important (and is definitely not useless).

[xinyiman]

But in fact I read the port from the controller.
Practically client A sends a string to the controller and the controller from that string retrieves the ip and the source port and communicates it to client B.

[rvk]

But in fact I read the port from the controller.
Practically client A sends a string to the controller and the controller from that string retrieves the ip and the source port and communicates it to client B.

But that's the whole point.
A doesn't know it's own EXTERNAL NAT port.
Only the controller can determine this by examining the packet (not the string).

So the string A sends is useless and can be anything (I.e. "ABCD").

So the controller really needs to examine the socket info (from which EXTERNAL port is B sending) and send external_Ip_of_B:external_port to B.

And to send this to B it also needs to know the external port of B because it can also only communicate with B over that EXTERNAL port of B (and not the internal port B uses to send something to C).

Please read the steps of that wiki again.
A can't pass it's own external port of the NAT via a string because it doesn't know it itself. Only the controller can determine that port.

[xinyiman]

That's exactly what I did. I sent a string without the door and the ip. The controller reads the door and the ip.

[rvk]

That's exactly what I did. I sent a string without the door and the ip. The controller reads the door and the ip.

You said the controller reads the ip and port from that string.

How does the controller determine the external port and ip?
Can you give a small code sample if that?

After that you send it to B.
Does B actually receive something?

[xinyiman]

I said that badly. I meant that I send a string to the controller. The controller receives a string  (for examples "ABCD") which means read the ip and port from here. Then the controller reads the information from the packet data identifying the source.

Si B receives the data from A correctly and vice versa. The problem is that they then have to connect to endpoints other than the controller and then the bidirectional nat changes the output ports for me. If I can, tonight I update the project code (also adding the controller source) and send it to you.

[rvk]

The problem is that they then have to connect to endpoints other than the controller and then the bidirectional nat changes the output ports for me.

Yes. If B can send a packet to A your a step closer.
Now A should disregard the port it got from C (controller) and read the external port of B from that packet. That's the final port it can use to contact B.

If it doesn't receive a packet from B, it can send a packet to B from the port it got from C (controller). When B receives that, it can use that external port for future communication and it should send A an acknowledgment so A can again see the external port.

BTW, this is ALL explained in the flow section of the wiki.

[xinyiman]

Ok, I'll try. Thank you very much (I missed this step). I'll update you tomorrow.

[nummer8]

https://github.com/Maickonn/AllaKore_Remote

Here a Delphi implementation of a remote desktop with a server as middle man.
File transfer is implemented.

Maybe it helps

[rvk]

Si B receives the data from A correctly and vice versa. The problem is that they then have to connect to endpoints other than the controller and then the bidirectional nat changes the output ports for me. If I can, tonight I update the project code (also adding the controller source) and send it to you.

BTW. I don't think you are yet at the step B recieves data from A (like you said).
In that case the hole is already punched.
(You probably meant "the data of A" and not "the data from A".)

Are you sure you don't have a restricted cone nat or symetric nat on both sides? Then, when A tries to communicate with B it uses a different external port from that used with communication with S (and visa versa).
In that case you can't punch holes that way.

Note that you should send both a packet from A to B and from B to A (with ports received from S). Otherwise it won't work. One of the packages need to arrive (while the other is ussually dropped by one of the NATs).

How did you determine the external port is different from that with the communication with S?
(Because you can't see that because the NAT of B will drop the package)

If both hosts have Restricted cone NATs or Symmetric NATs, the external NAT ports will differ from those used with S. On some routers, the external ports are picked sequentially, making it possible to establish a conversation through guessing nearby ports.

[xinyiman]

Si B receives the data from A correctly and vice versa. The problem is that they then have to connect to endpoints other than the controller and then the bidirectional nat changes the output ports for me. If I can, tonight I update the project code (also adding the controller source) and send it to you.

BTW. I don't think you are yet at the step B recieves data from A (like you said).
In that case the hole is already punched.
(You probably meant "the data of A" and not "the data from A".)

Are you sure you don't have a restricted cone nat or symetric nat on both sides? Then, when A tries to communicate with B it uses a different external port from that used with communication with S (and visa versa).
In that case you can't punch holes that way.

Note that you should send both a packet from A to B and from B to A (with ports received from S). Otherwise it won't work. One of the packages need to arrive (while the other is ussually dropped by one of the NATs).

How did you determine the external port is different from that with the communication with S?
(Because you can't see that because the NAT of B will drop the package)

If both hosts have Restricted cone NATs or Symmetric NATs, the external NAT ports will differ from those used with S. On some routers, the external ports are picked sequentially, making it possible to establish a conversation through guessing nearby ports.

In fact they are not yet in the data passage. Unfortunately I use google translate and the sentence has been transformed badly. The correct one is:

"the data of A"

My tests are done from my home network.

So both A and B are in my lan, but I want to be able to get them to communicate via the controller that is on the internet. So both A and B go through a bidirectional NAT. I'm not sure if I have a two way NAT, I deduced it from the fact that my code works if I move the controller to local network and it doesn't work if I move the controller over the internet.

[rvk]

So both A and B are in my lan, but I want to be able to get them to communicate via the controller that is on the internet. So both A and B go through a bidirectional NAT. I'm not sure if I have a two way NAT, I deduced it from the fact that my code works if I move the controller to local network and it doesn't work if I move the controller over the internet.

In that case it's also important that loopback of the external IP is enabled on the router. Not all routers have this.

If you have a small webserver on your PC on port 80 and you redirect port 80 to that PC on the router, are you able to access EXTERNAL_IP:80 and get the website?
If that works... you can put the controller on the internet and test with two internal clients.

Otherwise you need to take a whole other approach (i.e. using internal IP addresses and internal port).
A and B need to send in a string "internal_IP:internal_port".

For the connector...

*) if both A and B have the same external IP, the connector can send "internal_IP_A:internal_port_A" to B and "internal_IP_B:internal_port_B" to A. Both should be able to communicate directly.

*) if external IP of A and B are different, the connector sends "external_IP_A:external_port_A" to B and "external_IP_B:external_port_B" to A. Both A and B send each other a packet. One packet will be dropped and the other will be passed. But after that, communication between A and B should work (if there is not a restrictive NAT).

So when A and B are on the same network, internal IP:Ports are used. When they are not, a hole is punched for communication.

If for testing that both A and B are on different networks, but they are really not... loopback should be enabled. Otherwise you really can't test this.

[xinyiman]

I created a small test example (taken from the KRD code). Could you try it out and tell me if I am doing something wrong in implementing UDP hole punching? So at least we talk looking at the same code and we can't get it wrong.

Thanks

To understand how the program works, follow these steps (first locally, then on 3 different PCs on the LAN and finally moving the controller out of the LAN)

1. Launch the controller executable which will respond with something like this

UDP Hole Punching Controller
MAX_CONNECTIONS: 100
MAX_INACTIVE_MS: 30000
SOURCE_PORT: 1985
PWD:

2. Start a client instance and set the controller ip address in the field identified as "Controller IP:" which by default is 127.0.0.1

3. Start a second client instance and set the controller's ip address in the field identified as "Controller IP:" which by default is 127.0.0.1 and then click on the "Invert" check

4. On instance 1 of the client click on the "Start conn" button which will return an id in the memo field (Ex: 1qhlUQ)

5. On instance 2 of the client click on the "Start conn" button which will return an id in the memo field (Ex: NnGLQ8)

6. Enter in the "Remote id session:" field of instance 1 the id of instance 2 (Ex: NnGLQ8)

7. Enter in the "Remote id session:" field of instance 2 the id of instance 1 (Ex: 1qhlUQ)

8. On both instances, click on the "Start P2P" button

If everything works, you should find a list of sent and received messages in the memo of both instances

Ex.


ControllerMyId  :A
ControllerIp    :127.0.0.1
ControllerPort  :4999
ControllerTS    :0
127.0.0.1:4999 --> A msg_1
127.0.0.1:4999 <-- B msg_1
127.0.0.1:4999 --> A msg_2
127.0.0.1:4999 <-- B msg_2
127.0.0.1:4999 --> A msg_3
127.0.0.1:4999 <-- B msg_3
127.0.0.1:4999 --> A msg_4
127.0.0.1:4999 <-- B msg_4
127.0.0.1:4999 --> A msg_5
127.0.0.1:4999 <-- B msg_5
127.0.0.1:4999 --> A msg_6
127.0.0.1:4999 <-- B msg_6
127.0.0.1:4999 --> A msg_7
127.0.0.1:4999 <-- B msg_7
127.0.0.1:4999 --> A msg_8
127.0.0.1:4999 <-- B msg_8
127.0.0.1:4999 --> A msg_9
127.0.0.1:4999 <-- B msg_9
127.0.0.1:4999 --> A msg_10
127.0.0.1:4999 <-- B msg_10

Obviously if you run all three programs on the same computer you don't even have to change the IP Controller of the two instances, leave it at 127.0.0.1