conection problem on lan local and internet hub

[terminator 0]

I created a hubdc witch adch++ 2.81 on linux

I tried it in our university campus where we have NAT ( IPs 192.168.0.1/255) passive mode is the only option.

After some checking I saw this

I am in this situation and works well

But the next situation does not work

what settings should be made ​​to work?

[terminator 0]

excuse me but my English is not very good!

hub isn't on the private network, is on internet is have an ip 86.123.234.248

are 2 university campus, each having a server used as rooter for the private network inside each campus (IP 192.168.0.1/255)

server ip university campuses are 193.231.40.44/45

passive mode is the only option to connect to the hub and to download from other users outside the campus

users on the private network within a campus can not downlad each other using passive mode

hub is made just for the two campuses

passive mode and NAT traversal allows users to connect from one campus to campus but not inside two private networks within campuses

mode active allows connecting users within the private network on campus 1 and not allow users to connect to the campus 2

Green Line allows connection

The red line does not allow connection

[Mek 13]

As I replied to you via PM:

That's some very exotic network setup...

Of course you can only appear and work in active mode with users of the same network (campus) - to others you are passive. I don't think there is a viable solution for setup of Apex or any other DC client.

In your situation, I would create two hubs, each for one network and then connect to the first one in active mode, and to the other one in passive mode.

Let's keep our discussion here in public :)

[terminator 0]

according to tests made ​​me think that this is a bug dc client.

[Crise 26]

according to tests made ​​me think that this is a bug dc client.

The problem with campus networks tends to be with port forwarding... just changing your settings to active mode does not mean you are really in active mode. It just means that the client operates as if direct connections between users were possible, for them to be possible in this scenario ports need to be forwarded.

Your latest graph basically outlines a typical scenario where you have bunch of users connecting to a hub in the internet, behind different public facing routers which is (trivially) true for almost any two users from different geographical locations or ISP's. When DC client connects to a hub in the internet the fact that two users in said hub are from the same network does not make any difference to the client, because the client does not know this, as all users typically send their public facing IP to the hub... it attempts connecting using the known public IP for that user, so port forwarding is necessary for the connection to succeed.

The only difference to that typical scenario you have yet to state is that with campus networks you typically can not freely forward ports (although same can be true for home networks, f.ex. my ISP blocks most ports < 1000 for incoming connections), so yes if you have more than one user being forced to share the same public IP and port combination because of the fact that you can not forward ports it can't physically ever work because the port and IP the client tries to connect to are the same for two different users.

[terminator 0]

The problem with campus networks tends to be with port forwarding... just changing your settings to active mode does not mean you are really in active mode. It just means that the client operates as if direct connections between users were possible, for them to be possible in this scenario ports need to be forwarded.

you're right here we used dc + + and made thanks to automatic port mapping methods, DC++ is able to open the ports it needs and obtain your external IP address as well

Photo by setting

seting dc++ on atashament

Your latest graph basically outlines a typical scenario where you have bunch of users connecting to a hub in the internet, behind different public facing routers which is (trivially) true for almost any two users from different geographical locations or ISP's. When DC client connects to a hub in the internet the fact that two users in said hub are from the same network does not make any difference to the client, because the client does not know this, as all users typically send their public facing IP to the hub... it attempts connecting using the known public IP for that user, so port forwarding is necessary for the connection to succeed.

The only difference to that typical scenario you have yet to state is that with campus networks you typically can not freely forward ports (although same can be true for home networks, f.ex. my ISP blocks most ports < 1000 for incoming connections), so yes if you have more than one user being forced to share the same public IP and port combination because of the fact that you can not forward ports it can't physically ever work because the port and IP the client tries to connect to are the same for two different users.

I keep reading different cases and realize that this situation does not work

Peers Behind a Common NAT

First consider the simple scenario in which the two clients (probably unknowingly) happen to reside behind the same NAT, and are therefore located in the same private IP address realm, as shown in Figure . Client A has established a UDP session with server S, to which the common NAT has assigned its own public port number 62000. Client B has similarly established a session with S , to which the NAT has assigned public port number 62005.

http://www.brynosaur...000000000000000

Suppose that client A uses the hole punching technique outlined above to establish a UDP session with B , using server S as an introducer. Client sends a message requesting a connection to B. S responds to A with B 's public and private endpoints, and also forwards A's public and private endpoints to B. Both clients then attempt to send UDP datagrams to each other directly at each of these endpoints.

I would be an alternative to this case!

Client A and Client B uses a group setting something like this

Most importantly, the group name, username and local IP

this group you must recognize and hub and xml file that you send to the client must contain him and the group with information

example

<Nodes>

<Source CID="user ID" group="groupname" I4="IP address" U4="UDP port" SI="filesize" PF="is it partial file?"/>

<Node CID="user CID" I4="IP address" U4="UDP port"/>

</Nodes>

</Nodes>

groupname

<Node CID="user CID" I4="IP address"/>

</Nodes>

When the client receives the xml must be a condition

if the user of the client receives from the server xml file is part of that group with the change ip if not part of the group remains on public ip

expect answers for this idea!

[itachichigoku 0]

Ok I think I'm on the right track with this.

I can connect to hubs but search and file lists do not work on any DC clients

It appears that port forwarding is my next step but I am on campus, and not really sure how to go about this, or if there is another way around it.

I did used to be able to do whatever I wanted on DC here (with auto connection settings) but since updating to DC0.802 it hasn't worked for me. And I mean the same day - working, updated, not working. Since then I've tried other clients and tried reinstalling the older model but nothing did the trick. So that's where I'm at :)

[terminator 0]

I think it will be a solution

if the developers of this program will go into the details you've posted above

return to research and new ideas for that problem

I found a program that has settings in the picture below

Please someone explain the setting "config VPN and networks" and "Allow private (local) IP update IPs from webservice"

if these 2 settings I can help my case