AUT0 - Network connection auto detection extension

the ‘AUT0’ extension (network connection auto detection extension).
Rationale: Detect if client is capable of initiating active connections.

After logging in:

Client -> ‘HCHK 12345 ABCD’.

Server sends a UDP packet containing token to the client’s IP address at the given port as shown in the INF message.

Server -> ‘ICHK ABCD’

The server should send it from a UDP socket bound to the same port as the TCP server, which means the server will
have to listen to both TCP and UDP.

If client receives the packet, it knows it can receive UDP connections, and will advertise it in the INF message as
a supported feature.

If the client does not receive any UDP packets within a few seconds, it MAY try to reconfigure the router using
UPnP/ZeroConf, and issue a HCHK command to the server again.

If the client still doesn’t receive any UDP packets, hole punching can be tried.
The server will send a UDP packet to the hub (using the port of the TCP server), and reissue the HCHK command.
The UDP packet SHOULD be echoed by the hub.
This UDP packet should contain simply ‘HECH {cid} {token}’ (Hub echo).

The hub should send a packet containing the token back:
‘IECH {token} {host:port}’, aswell as the same message via TCP.

If the client receives the message via UDP, it should now be able to determine the type of NAT.
If the client receives the message via TCP only it knows it has a firewall blocking icomming communication.
If the client does not receive the message, it should assume a firewall is blocking all UDP communication,
and resume in passive mode.

‘AUT0’ in the extensions message (SUP) for client and hub.
Server will also listen to UDP messages on the same port as the TCP port.

The server MUST now respond to the ‘HCHK’ command via TCP
The server MUST now respond to the ‘HECH’ command via UDP.

The client will always initiate communication.

Syntax: HCHK {port} {token}

  • port is a 16-bit port number where the client is listening for packets.
  • token is 4 bytes base32 encoded data specified by the client.

Client: ‘HCHK 1511 BACD’ (tcp)
Server: ‘ICHK BACD’ (udp)

Syntax: HECH {cid} {token}

  • cid is the client ID.
  • token is 4 bytes base32 encoded data specified by the client.

Server: ‘IECH BACD’ (udp)
Server: ‘IECH BACD’ (tcp)

Security considerations:
The hub must verify that IP address where the HECH command originated from
matches the IP address where the user with the given CID is connected from.
If the CID and IP does not match, or the CID is not used the hub MUST ignore
the request.

It would been a nice thing to have and surely needed.

It will need also the client sending both his TCP and TLS port in his INF as this is not the case now.

And there is 1 thing using UDP will not let you verify that there is a real clients TCP/TLS port listning on the clients side as far i know and you need a extra listner on the servers side.

Why not having the hub send a real tcp (with or without TLS layer depending on the SUP info form the client) from a diff port then the hubs port and realy negotiate like the first steps in the client-client file transfer using the RCM (one with ADC0 feature in string if client supports and one without), that way you do not need the client ports in the INF (you will get them from the clients CTM).

Using this would be a real test that it will be a TCP packet that is allowed (because a UDP is reaching the port does not mean a TCP can) and you can be sure its the DC client who is listning on that port and not something else.

I have been on a P2P before where they had a UDP system like proposed here and the client used port 443 default. That test failed completely the day Skype was launched and used same default port. And yes i know the client will verify that the port is in use but the above TCP verification avoids such probs completely and avoid sending extra INF fields and avoids a extra listning socket hubs side.

My 2 cents :laughing:

In Janurary;

[2011-01-16 01:03:32] On a different note, what does AUT0 do? I don’t get it. It’s… emulating RCM/CTM?
[2011-01-16 01:06:39] The port in CHK is useless information (it’s already supplied in INF) and the CID in ECH is also pointless (it’s an H-type message, so the hub already knows the CID)…
[2011-01-16 01:09:08] I’m not entirely sure it’s even needed. Clients can a) assume active b) fallback to NAT-T if connection fails for X tries.

In February;

[2011-02-25 21:57:04] did you ever had a look @ that AUTO extention proposal ? thats infact what is needed is 1 form or another but think it needs “sponsors” lol
[2011-02-25 21:57:22] is=in
[2011-02-25 21:57:55] IIRC, it’s pointless with NAT-T?
[2011-02-25 21:58:04] Or what was it about…
[2011-02-25 21:58:38] hub detects if client is active or passive and informs client
[2011-02-25 21:59:08] Implement NAT-T and don’t care?
[2011-02-25 21:59:52] and no its not useless because nat exist as 1 if people put themself active nat is not used and 2 not all routers support nat
[2011-02-25 22:01:45] these “misconfigurations” cause fustration for the client and endless ctm strings in the hub
[2011-02-25 22:02:10] 1) If users put themselves as “active” and the client detect that the client can’t connect (for some reason), the client could default back to NAT-T…
2) True, not all routers support NAT. However, I wonder whether people will understand “X hub tells you to check your connectivity” vs the client telling them so (or simply asking in the hub).
[2011-02-25 22:02:29] But if there’s an implementation, I’ll of course add it to ADC-Ext…
[2011-02-25 22:03:24] there is only a proposision made by toast, a copy of another old spec …
[2011-02-25 22:03:40] I’d have to re-read the proposal and change the writing to a simpler format since it’s slightly confusing, I think, as it is now.
[2011-02-25 22:03:52] a bit yes > :slight_smile:
[2011-02-25 22:05:08] Also, since I’m a little sceptical myself about its usefulness, I’d have to convince myself of its usefulness to include (or not) a “you should implement this regardless of NAT-T” comment…
[2011-02-25 22:13:23] Simple C-C for TCP could be done without an extension today…
[2011-02-25 22:13:55] true but then the client cant be “informed”
[2011-02-25 22:14:07] STA or MSG…
[2011-02-25 22:14:13] infact inhere is a very basic tester
[2011-02-25 22:15:55] then the client needs to send “something” to inform the hub he wants a test and can/will/use/receive the result
[2011-02-25 22:16:06] Technically, UDP could be tested also… E.g., assume that the hub “searches” for an item it knows/assumes the client has in its share…
[2011-02-25 22:16:59] yep there a same system as the “testsurs” could be used
[2011-02-25 22:17:20] a fake file that give a sch result
[2011-02-25 22:17:25] Right.
[2011-02-25 22:17:54] Doesn’t even have to be a fake file…
[2011-02-25 22:17:59] Simply search for “a”.
[2011-02-25 22:18:27] lol
[2011-02-25 22:18:46] if a user has shares yes lol
[2011-02-25 22:19:18] HTC Desire rox > :smiley:
[2011-02-25 22:19:26] Well, highly likely.
[2011-02-25 22:20:09] hehe new toys > :slight_smile:
[2011-02-25 22:20:58] Hm, it should be the other way around, shouldn’t it? Client searches for something… Not the hub.
[2011-02-25 22:21:24] no a BSCH should reach him
[2011-02-25 22:21:49] Well, URES is what you want to test…
[2011-02-25 22:22:18] thats outgoig no ?
[2011-02-25 22:22:34] Incoming from the client’s point of view.
[2011-02-25 22:23:15] Client searches and will get a URES, which is what you want to check; whether the client can receive UDP traffic.
[2011-02-25 22:23:49] you 100% right
[2011-02-25 22:24:02] Likewise with CTM… Client tries to connect to the hub…
[2011-02-25 22:24:11] (or, rather, some pseudo client.)
[2011-02-25 22:24:54] (Doesn’t really matter.)
[2011-02-25 22:25:24] (Well, most hubs probably don’t understand HCTM…)
[2011-02-25 22:26:01] infact the hub should be “passive client” emulating in both cases imho
[2011-02-25 22:26:53] but not for the searches offcourse there you are correct
[2011-02-25 22:27:35] So just say “if client and hub support AUTH, the client will perform a HCTM [and can simply disconnect if the hub connects] and a HSCH [searching for FOOBAR or something specifically stated]”.
[2011-02-25 22:29:48] true with one thing , hub should start with a rcm to receive the port and 2 of them 1 with feature ADCS and one without
[2011-02-25 22:30:12] as far i know the client does not send port info … in INF
[2011-02-25 22:30:44] The hub doesn’t have to start with RCM if the client does a CTM on connect…
[2011-02-25 22:30:49] It does.
[2011-02-25 22:31:03] Remember that an RCM generates a CTM.
[2011-02-25 22:31:39] So you place the responsibility with the client handling the message of notification.
[2011-02-25 22:31:59] yes
[2011-02-25 22:32:07] (Say, if the client hasn’t received a connection/RES after 30 seconds, it can inform the user.)
[2011-02-25 22:32:15] answer for dcpp team: where in core may catch sending RES adccommand as sample string or cast in string for adding this strings in cmd debug (with AdcDebug equal 1 this strings don’t shown) or this is unreal?
[2011-02-25 22:32:21] But yes, you want to have a FCC (but you aren’t required).
[2011-02-25 22:33:07] (By ‘have to’ I mean ‘unless you want to generate seamingly meaningless traffic for hubs’.)
[2011-02-25 22:34:13] thats exact what needs to be discused > :slight_smile:
[2011-02-25 22:36:06] egik: I can’t answer you, but you can always (I say ‘always’, even if I don’t maintain the question tracker) ask in Launchpad or on ADCPortal (if you don’t get an answer here).
[2011-02-25 22:38:59] Simplest SCH is probably searching for the TTH of an empty file.
[2011-02-25 22:39:29] that will not give a res
[2011-02-25 22:39:38] Why not?
[2011-02-25 22:40:46] client will only send res if tth found …
[2011-02-25 22:41:03] The hub responds, remember.
[2011-02-25 22:41:13] grrrrrrrrr lol
[2011-02-25 22:41:26] true
[2011-02-25 22:41:39] So hub can always respond to the empty file TTH.
[2011-02-25 22:41:44] yep
[2011-02-25 22:41:54] (or atleast in a HSCH context)
[2011-02-25 22:42:53] should solve udp
[2011-02-25 22:43:54] And client simply will do a HCTM and disconnect once the token matches and a connection is established.
[2011-02-25 22:44:40] also true
[2011-02-25 22:45:16] 2 times if hub supports adcs verification and that will be a prob
[2011-02-25 22:45:25] Right.
[2011-02-25 22:45:31] a normall adc has no certs
[2011-02-25 22:46:37] same will be the case for udps if its going to use diff ports
[2011-02-25 22:50:10] I still wonder whether the client telling the user “it seems you don’t support incoming connections, please do X” is useful. I mean, the user will notice quite quickly… But sure, if you want to get rid of annoying users. > :slight_smile:
[2011-02-25 22:50:42] (Granted, the user can’t tell for sure whether searches work immediately, unless they search for something that should generate responses.)
[2011-02-25 22:52:25] problem is that the “source” telling the client its settings are wrong should be more or less relaible, otherwise you could indeed have a “failiure” counter
[2011-02-25 22:52:38] Right.
[2011-02-25 22:54:27] 2300 CTM and RCM’s from 1 client that is misconfigured
[2011-02-25 22:54:31] lol
[2011-02-25 22:54:39] o_O
[2011-02-25 22:55:02] big shares and udp works on him
[2011-02-25 22:55:12] but not tcp > :slight_smile:
[2011-02-25 22:58:14] time for a > :beer: > intresting convo
[2011-02-25 23:00:27] what you sugest can even be done scriptwise
[2011-02-25 23:00:59] > :slight_smile:
[2011-02-25 23:01:03] so if you “word” it i will try to “make” it lol
[2011-02-26 00:14:01] only see 1 prob with your solution regarding auto pret and that it uses the server port to do the “verif” have no clue how well arnes shared_pointers deal with it … think we need him or collogic to answer that unless you know more
[2011-02-26 00:45:05] Pirre: Implementation issue…
[2011-02-26 00:45:52] Just connect to the port…Really simply…


[2011-02-02 11:01:28] Oh, ‘AUT0’. Cute pun.
[2011-02-02 11:02:22] “The server should send it from a UDP socket bound to the same port as the TCP server, which means the server will
have to listen to both TCP and UDP.” seems to address that concern though.
[2011-02-02 11:02:47] I’m not sure Toast quite understands UDP though, since it’s not technically entirely coherent
[2011-02-02 11:05:00] as i understoud it (and maybe i am wrong) , the verification uses a UDP packet to the client listners port what is TCP for xf
[2011-02-02 11:05:34]
The hub should send a packet containing the token back:
‘IECH {token} {host:port}’, aswell as the same message via TCP.

If the client receives the message via UDP, it should now be able to determine the type of NAT.
If the client receives the message via TCP only it knows it has a firewall blocking icomming communication.
If the client does not receive the message, it should assume a firewall is blocking all UDP communication, and resume in passive mode.
[2011-02-02 11:05:45] So, it seems to probe each protocol separately.
[2011-02-02 11:06:34] For the client, at least.
[2011-02-02 11:07:35] But I also don’t understand the separation between ‘hub’ and ‘server’. They’re different entities in that description, but what other machine is supposed to play the role of server?
[2011-02-02 11:07:49] Since it uses I/H commands
[2011-02-02 11:09:01] for me the logic is that when verifying the clients connection the client is the server
[2011-02-02 11:09:19] as thats exactly what is tested
[2011-02-02 11:10:03] so why have the ‘client’ as a separate role?
[2011-02-02 11:10:24] have no clue there
[2011-02-02 11:11:35] one’s interpretation of that protocol depends on how one assigns ‘client’ and ‘server’, so until/unless that’s clarified I think dealing with that proposal involves chasing ghosts
[2011-02-02 11:12:51] ye but a pitty it drags on that as its a nice feature capable of eliminating a lot of unneeded traffic in a hub
[2011-02-02 11:12:53] it is possible to imagine a protocol where one only has two machines but the roles are factored such that there’s a ‘floating’ role worth splitting out, but I don’t think (?) that’s what Toast is trying to communicate
[2011-02-02 11:12:56] Yes
[2011-02-02 11:13:15] So, try to get Toast to clarify it I guess - it looks like you already have, without success, though
[2011-02-02 11:13:33] not that good with words lol
[2011-02-02 11:14:02] (oh, other WINE quirk - ctrl-left/right in multiline edit controls just kind of stop at line boundaries. Other cursor movement keys mostly work though.)
[2011-02-02 11:15:10] Well, you’re partly objecting on other bases, too - e.g. the Skype/port 443 concern.
[2011-02-02 11:15:20] Have you asked him in this hub about it?
[2011-02-02 11:15:49] not yet, but i think the concept is taken from another hubsoft
[2011-02-02 11:16:14] Given his response to FleetCommand’s criticisms of his English, he’s got no basis to ignore you just because you don’t write even somewhat less smooth English. :stuck_out_tongue:
[2011-02-02 11:16:41] o toast will not do that > :slight_smile:
[2011-02-02 11:17:22] As in, Toast is just describing what some existing hub software already does?
[2011-02-02 11:17:48] Seems pointless without client support.
[2011-02-02 11:20:30] ye thats what i mean, think it was uhub but not 100% sure and there are already some clients (maybe svn) that have it implenetd
[2011-02-02 11:21:45] Oh. Then it’s even more important that either someone provides a more readable description of what they’re doing (if it’s a communication problem via Toast) or that some of the weirdness might be fixed (if Toast is describing it correctly).
[2011-02-02 11:22:29] And also means that Toast (or someone familiar with that hub software - e.g. jvk) is uniquely qualified to elaborate.
[2011-02-02 11:23:06] will ask around > :slight_smile: >
[2011-02-02 11:24:22] I broadly agree though that this is an obviously useful extension and is worth getting right.
[2011-02-02 11:27:57] > > only ref i can find and that it is used …
[2011-02-02 11:28:27] Oh, looks like Toast copy/pasted from that

Had a new discussion today about this, and I had roughly the same ideas as my previous noting in the paste above, but here is a more constructed way.

NATO - Network connection auto detection extension

The client have no way to verify whether it can manage incoming TCP and/or UDP connections and messages. This extension intend to provide this capability by making the hub responsible for helping the client ascertain this information.

Signal AUTO in the SUP to indicate support for this.

The client may send a HCTM where the hub connects to the client as in a normal client-client connection. The client may disconnect after it has received the INF (matching the token only) in the client-client connection. If no connection is established within two minutes (120 seconds), it means the client has probably failed to properly set up the network for active mode.

The client may send a HSCH for the 0-byte file hash where the hub responds with a URES for that file. Note that the hub must a) generate a CID for itself (as U-type messages require a CID) or b) generate a bot (with a CID) that sends the URES. If no message is receivedwithin two minutes (120 seconds), it means the client has probably failed to properly set up the network for active mode. Ten search results should be sent, to make sure that at least one arrived.

Implementations should, upon failure, indicate as such to the user and fall back to an alternative method of connectivity.

Note that the client should not perform this in all hubs it is connected to. It is up to the client to decide which hub it should do this verification in. A basic implementation may simply do it in the first hub it is connected to.

Note that this procedure must likely be done each time the client is started as the connectivity may have changed during the client’s downtime.