passive-to-passive connection

[terminator 0]

About the passive-to-passive user connection. How does that work?

I tried it in our university campus where we have NAT ( IPs 192.168.0.1/255) passive mode is the only option. In this case, connection to passive users in passive mode didn't work - I suppose it has to do something with the "NAT Traversal". Would it be possible to support passive-to-passive connections even when no NAT is in effect?

[FlipFlop 1]

It's possible that the hubsoft blocks it since the NAT traversal involves a few minor changes to the $ConnectToMe command. What hubsoft/version is used?

One other note: it takes two clients that use NAT traversal, so you will only be able to connect passive-passive if both clients are using this implementation. So both clients have to be StrongDC++ based and recent.

[Peetboy 0]

I was also trying it with my friend on our local network. We both have routers and forwarded ports but for this test we set the passive connection with NAT Traversal and it did not work. Hubsoft is Verlihub and we both have ApexDC.

[Big Muscle 1]

Try to fill in your external IP address (which is probably your router's address) in settings. NAT Traversal technique works correctly in ADC hubs only, because NMDC hubs doesn't provide you with your external IP (although there is some UserIP/UserIP2 in NMDC "protocol" which almost all NMDC hubs violates).

[PPK 0]

although there is some UserIP/UserIP2 in NMDC "protocol" which almost all NMDC hubs violates

You are wrong (as always), please read existing documentation for UserIP/UserIP2 protocol extension... then you will find that hubs don't violate anything :P

[terminator 0]

Current Software hub

ADCH++ ADC

DSHub ADC

NextHub ADC

µHub ADC

luadch ADC

What do I need to use passive mode

What settings do I need to get conection pasive to pasive (on hub software)

i need a tutorial with settings

[Big Muscle 1]

You are wrong (as always), please read existing documentation for UserIP/UserIP2 protocol extension... then you will find that hubs don't violate anything

Ah, you are partially right. There's no real NMDC protocol documentation and therefore it can't be violated. But if we talk about that reverse-engineered protocol pseudo-documentation, it states "hubs supporting the UserIP2 protocol extension should automatically send the client its own IP.", but almost all NMDC hubs report UserIP2 support although admin disables autosending IP to user (at least, such situation was some months ago and I haven't rechecked it since that time).

[PPK 0]

What settings do I need to get conection pasive to pasive (on hub software)

In ADC you don't need any setting on hub software. Main problem is that both users who want to make passive - passive connection must be passive because they are behind NAT and this NAT must support p2p NAT Traversal... in many cases passive - passive connection is not working because this requirement is not met.

Ah, you are partially right. There's no real NMDC protocol documentation and therefore it can't be violated. But if we talk about that reverse-engineered protocol pseudo-documentation, it states "hubs supporting the UserIP2 protocol extension should automatically send the client its own IP.", but almost all NMDC hubs report UserIP2 support although admin disables autosending IP to user (at least, such situation was some months ago and I haven't rechecked it since that time).

Now are you joking are are you really not able to read ? UserIP and UserIP2 are protocol extensions. Extensions that are not created by NMDC developer. Extensions that are not reverse engineered because they are both documented from beginning and for both is documentation available. And "should" is not "must" ... And if you are really unhappy with not working UserIP2 (you don't use UserIP without that 2) you can always get IP in many other ways.. easy way is when client is "calling home" for update file, or for dht bootstrap file ;)

[Big Muscle 1]

In ADC you don't need any setting on hub software. Main problem is that both users who want to make passive - passive connection must be passive because they are behind NAT and this NAT must support p2p NAT Traversal... in many cases passive - passive connection is not working because this requirement is not met.

in many cases? Have you ever tested it? :-D Yeah, NAT Traversal is not standardized but it is something which works almost in all cases (and also worked for me when I was not behind NAT but software firewall blocked ports) :-P yeah, "many" is relative, so you probably mean that "3 of 10" = "many".

And "should" is not "must" ...

You SHOULD study English more properly. http://www.thefreedictionary.com/should The main meaning of should is something that it's expected to happen.

And if you are really unhappy with not working UserIP2 (you don't use UserIP without that 2) you can always get IP in many other ways.. easy way is when client is "calling home" for update file, or for dht bootstrap file

I am not unhappy, I don't care that something doesn't work with NMDC protocol properly. Using update file or DHT bootstrap file is totally bad idea, because server can be down, and doing this periodically (for users with their IP changing very often) can overload the server. StrongDC++ updates its external IP in more clever way :-P

[PPK 0]

in many cases? Have you ever tested it? :-D Yeah, NAT Traversal is not standardized but it is something which works almost in all cases (and also worked for me when I was not behind NAT but software firewall blocked ports) :-P yeah, "many" is relative, so you probably mean that "3 of 10" = "many".

I don't need to test that, others do that already (emtee for example). p2p nat traversal is easy to code, but his support is bad (for example zyxel don't support it at all, in cisco/linksys is support in 86 % of devices... when you count all nats then support is around 60-70 %). It can be increased with using UDP hole punching instead of TCP hole punching, because UDP have much better support (more than 90%). Then it will be really "works almost in all cases" I'm sure that you know skype where is it used, and it is always not enough so they need to use active user in middle for pasive - pasive connection when nat travesal fail.

You SHOULD study English more properly. http://www.thefreedictionary.com/should The main meaning of should is something that it's expected to happen.

If you want it that that way... then you should use original documentation and not reverse-engineered one for something that is correctly documented from his creator (Ade is his name if you don't know... and original documentation using word "can" is here) And in case when you really read it, maybe you should read documentation for ADCGET too... partial filelist is ADC only feature as it is multiple times mentioned in DC++ changelog

StrongDC++ updates its external IP in more clever way :-P

Then i don't understand why you complains... then it must working in nmdc without need to have ip from hub :rolleyes:

[Guest Toast]

OMG cant the both of you just shut the **** up for once and crawl back to where ever the **** you came from pathetic that you keep on draggin each other threw the mudd each and every ****ing time

[Big Muscle 1]

If you want it that that way... then you should use original documentation and not reverse-engineered one for something that is correctly documented from his creator (Ade is his name if you don't know... and original documentation using word "can" is here) And in case when you really read it, maybe you should read documentation for ADCGET too... partial filelist is ADC only feature as it is multiple times mentioned in DC++ changelog

yeah, I have read it and...? There's written that "it can send in two ways, either ... or ...", so maybe you've mistaken it with just pure "it can send.", you can also read further - the fact I stated with "should" still pays, because note claims (shorten version, so you can understand it correctly): "DC++ will use the IP if it is returned by hub (of course, it can't use something which is not returned), but it is expected to happen" :-P

and about ADCGET... what the **** does it have to do with this topic? Or you're just trying to move the discussion away? But yeah, you are right, it is mentioned in DC++ changelog as ADC feature, but it's not mentioned in StrongDC++ changelog :D

Then i don't understand why you complains... then it must working in nmdc without need to have ip from hub

Where did I complain? I just stated the fact... ok, I made mistake - pseudoprotocol is not violated by NMDC hubs (at least not in the case of $UserIP2), but pseudo-protocol's extension is violated but it doesn't change anything... and it doesn't work in NMDC properly because this obsolete pseudo-protocol doesn't provide proper way of getting external IP (StrongDC++ does, but NMDC doesn't - and StrongDC++ is not the only client using NAT-T in NMDC now, also many users disable the getting external IP address).

[Lee 84]

Not interested in this... settle it privately. All you do is argue and it puts DC in bad light. I find it concerning how you both aren't native English speakers yet are convinced you've interpreted it correctly.

Sorry for the hijacking terminator :)