Editing NatT protocol
From EMule Wiki
Warning: The database has been locked for maintenance, so you will not be able to save your edits right now. You may wish to cut-n-paste the text into a text file and save it for later.
The administrator who locked it offered this explanation: site maintenance
The edit can be undone.
Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision | Your text | ||
Line 5: | Line 5: | ||
NAT (Network Address Translation) Traversal allows Low ID to Low ID connections. | NAT (Network Address Translation) Traversal allows Low ID to Low ID connections. | ||
There are different techniques to achieve this, like STUN (Simple Traversal of UDP through NATs), or TURN (Traversal Using Relay NAT). For obvious reasons TURN is not suitable for any kind of file sharing applications. | There are different techniques to achieve this, like STUN (Simple Traversal of UDP through NATs), or TURN (Traversal Using Relay NAT). For obvious reasons TURN is not suitable for any kind of file sharing applications. | ||
− | The NatT for eMule uses there for STUN, as well as a attempt to become a High ID by reusing the Listening port for outgoing connections, if the NAT device is a Full Cone this technique will make the client fully | + | The NatT for eMule uses there for STUN, as well as a attempt to become a High ID by reusing the Listening port for outgoing connections, if the NAT device is a Full Cone this technique will make the client fully connectable, but it works only in a few cases. |
The main implementation using STUN can connect even through hardware firewalls, it only fails on Symmetric NAT’s, there are as well methods to penetrate these but they require to much overhead and are there fore like TURN not suitable for file sharing. | The main implementation using STUN can connect even through hardware firewalls, it only fails on Symmetric NAT’s, there are as well methods to penetrate these but they require to much overhead and are there fore like TURN not suitable for file sharing. | ||
Line 13: | Line 13: | ||
== NAT Tunneling == | == NAT Tunneling == | ||
To establish a communication tunnel from Alice to Bob through a NAT or a firewall Alice (A) sends first an call-back request to Carlo (C) witch records Alice’s UDP port and IP and relays them together with the request to Bob (B). | To establish a communication tunnel from Alice to Bob through a NAT or a firewall Alice (A) sends first an call-back request to Carlo (C) witch records Alice’s UDP port and IP and relays them together with the request to Bob (B). | ||
− | At this point Bob knows all he needs but Alice does not know enough (she does not know his UDP port). Now Bob tries to contact Alice directly over UDP (now his NAT/FW is open for messages form Alice) if she is behind a Full Cone Nat, she will get the message and will be able to reply. If she don’t answers after a short time Bob sends an own call-back request to Carlo or Dave (this depends on the later described different call-back relay schemes), he does the same as before and tells Alice the UDP port and IP of Bob. Now she can send him messages and he will receive them (this fails only if one of the two have a symmetric NAT, see the appendix for explanation). | + | At this point Bob knows all he needs but Alice does not know enough (she does not know his UDP port). Now Bob tries to contact Alice directly over UDP (now his NAT/FW is open for messages form Alice) if she is behind a Full Cone Nat, she will get the message and will be able to reply. If she don’t answers after a short time Bob sends an own call-back request to Carlo or Dave (this depends on the later described different call-back relay schemes), he does the same as before and tells Alice the UDP port and IP of Bob. Now she can send him messages and he will receive them (this fails only if one of the two have a symmetric NAT, see the appendix for explanation). If everything works they now have a working tunnel, to not loose it they exchange ping messages every few seconds as long as they need the tunnel. |
− | If everything works they now have a working tunnel, to not loose it they exchange ping messages every few seconds as long as they need the tunnel. | + | |
− | + | ||
<pre> | <pre> | ||
Line 30: | Line 28: | ||
<pre> | <pre> | ||
[uint8] pOPS // bit Field | [uint8] pOPS // bit Field | ||
− | // | + | // 4 reserved |
− | // | + | // 3 IdKind |
// 1 req answer | // 1 req answer | ||
− | [ID] // variable length determined by the Ping Options above | + | [ID] // variable length determined by the Ping Options above |
[Obfiscation] // uint8 obfuSetings | [Obfiscation] // uint8 obfuSetings | ||
// hash128 userHash | // hash128 userHash | ||
</pre> | </pre> | ||
− | |||
− | |||
− | |||
− | |||
− | |||
== Callback Methods == | == Callback Methods == | ||
=== eServer (Lugdunum) === | === eServer (Lugdunum) === | ||
− | The eserver call-back is supported since eserver 17.15, it requires | + | The eserver call-back is supported since eserver 17.15, it requires booth clients to be on the same server. The call-back is sent to the server from the client’s UDP socket for client to client communication (not from the regular one for client to servers communication), the packet must be obfuscated the server way otherwise it won’t be accepted, the reason why this is done over the client socket is that the server have to see the UDP port of the socket used for NatT. The eserver usually forwards the request from Alice to Bob over his TCP connection with the server this may be delayed up to 12 seconds (to send more requests in one TCP frame), but if the eserver knows a very recent client UDP port of Bob (he may have issued a request to some one seconds ago) than he forwards the call-back request imminently using UDP to Bob. The packet arrives on the client socket but is obfuscated as well the server way (not for simplicity but in order to allow Bob to verify that the packet really was sent by his server) so Bob have to look on the packet’s source IP and direct it to the server UDP socket processing function. The eserver may not forward the ID of Alice to Bob instead he sends a call-back request as if it would come from Bob to Alice telling her Bob’s UDP port that way and saving one UDP frame from Bob (Bob have to check if requester ID is 0 and if it is don’t issue an own call-back request to Alice after the ping fails). |
The client advertises his support of NatT by setting the flag SRVCAP_NATTRAVERSAL in the server login tag CT_SERVER_FLAGS. The server notifies his support by the SRV_TCPFLG_NATTRAVERSAL and SRV_UDPFLG_NATTRAVERSAL flags. | The client advertises his support of NatT by setting the flag SRVCAP_NATTRAVERSAL in the server login tag CT_SERVER_FLAGS. The server notifies his support by the SRV_TCPFLG_NATTRAVERSAL and SRV_UDPFLG_NATTRAVERSAL flags. | ||
Line 62: | Line 55: | ||
/* if eserver gave you a LOWID : the tcp port of the client as seen by eserver (if NAT : the port allocated by NAT device) */ | /* if eserver gave you a LOWID : the tcp port of the client as seen by eserver (if NAT : the port allocated by NAT device) */ | ||
</pre> | </pre> | ||
− | The seen port is sent in order to support the attempt described in the top to become a HighID by reusing the listening port, the server tries the connection attempt here form a different IP than his own, this | + | The seen port is sent in order to support the attempt described in the top to become a HighID by reusing the listening port, the server tries the connection attempt here form a different IP than his own, this behavior is optional. |
The UDP callback request packet have the following content: | The UDP callback request packet have the following content: | ||
<pre> | <pre> | ||
− | [uint32 | + | [uint32] Target ID (Bob's ID) |
− | [uint32 | + | [uint32] Requester ID (Alice's ID) |
</pre> | </pre> | ||
The forwarded packets the server sends over TCP or UDP have the same content: | The forwarded packets the server sends over TCP or UDP have the same content: | ||
<pre> | <pre> | ||
− | [uint32 | + | [uint32] Seen IP |
− | [uint16 | + | [uint16] Seen Client UDP Port |
− | [uint32 | + | [uint32] Requester ID (Alice's ID) (may be 0) |
− | [obfuscation | + | [obfuscation] // obtional |
− | + | // [uint8] obfuscation settings | |
− | + | // [hash 128] userhast | |
</pre> | </pre> | ||
Line 91: | Line 84: | ||
The OP_REASKCALLBACKUDP packet send to Carlo (Bob's buddy), have the following content: | The OP_REASKCALLBACKUDP packet send to Carlo (Bob's buddy), have the following content: | ||
<pre> | <pre> | ||
− | [hash128 | + | [hash128] // Target client Kad ID (Bob) |
− | [hash128 | + | [hash128] // File Hash of the pinged file |
// the part below is the unofficial mod part | // the part below is the unofficial mod part | ||
− | [uint8 | + | [uint8] // Mod Opcode (OP_NAT_CALLBACKREQUEST_KAD) |
− | [hash128 | + | [hash128] // Requesting client Kad ID (Alice) |
− | [uint32 | + | [uint32] // IP of Dave (Alice's buddy) |
− | [uint16 | + | [uint16] // UDP Port of Dave (D) |
− | [obfuscation | + | [obfuscation] // obtional obfuscation of Alice |
− | + | // [uint8] obfuscation settings | |
− | + | // [hash 128] userhast | |
</pre> | </pre> | ||
The second [hash128] (File Hash of the pinged file) is filled with 0's in order to allow Bob to distinguish this packet from a normal reask ping, the 0 hash is not valid as file hash but Carlo don't looks on anything excepted the "Target client Kad ID" so no problems occur here. | The second [hash128] (File Hash of the pinged file) is filled with 0's in order to allow Bob to distinguish this packet from a normal reask ping, the 0 hash is not valid as file hash but Carlo don't looks on anything excepted the "Target client Kad ID" so no problems occur here. | ||
Line 108: | Line 101: | ||
The packet Bob receives looks like following: | The packet Bob receives looks like following: | ||
<pre> | <pre> | ||
− | [uint32 | + | [uint32] // IP of Alice |
− | [uint16 | + | [uint16] // UDP Port of Alice |
− | [hash128 | + | [hash128] // File Hash of the pinged file |
// the part below is the unofficial mod part (unchanged) | // the part below is the unofficial mod part (unchanged) | ||
− | |||
... | ... | ||
</pre> | </pre> | ||
Line 122: | Line 114: | ||
<pre> | <pre> | ||
− | [hash128 | + | [hash128] // Target client user hash (Bob) |
− | [uint8 | + | [uint8] // Mod Opcode (OP_NAT_CALLBACKREQUEST_XS) |
− | [hash128 | + | [hash128] // Requesting client user hash (Alice) |
− | [uint32 | + | [uint32] // IP of Dave (Alice's XS buddy) |
− | [uint16 | + | [uint16] // UDP Port of Dave (D) |
− | [obfuscation | + | [obfuscation] // obtional obfuscation of Alice |
− | + | // [uint8] obfuscation settings | |
− | + | // [hash 128] userhast | |
</pre> | </pre> | ||
Line 136: | Line 128: | ||
The packet Bob receives looks like following: | The packet Bob receives looks like following: | ||
<pre> | <pre> | ||
− | [uint32 | + | [uint32] // IP of Alice |
− | [uint16 | + | [uint16] // UDP Port of Alice |
− | + | // rest unchanged | |
− | // rest unchanged | + | |
... | ... | ||
</pre> | </pre> | ||
− | Please refer to the | + | Please refer to the Additional Features for NatT section for further informations on the XS Buddy feature. |
== User Mode TCP == | == User Mode TCP == | ||
Line 162: | Line 153: | ||
Booth packets have the same content, like following: | Booth packets have the same content, like following: | ||
<pre> | <pre> | ||
− | [uint8 | + | [uint8] version |
− | [uint32 | + | [uint32] MAXFRAGSIZE (optional) |
</pre> | </pre> | ||
=== Communication === | === Communication === | ||
− | All send data segments are equipped with a unique sequence number indicating their position in the data stream. When Bob (B) receives a NAT_DATA segment form Alice (A) he acknowledges it with an NAT_DATA_ACK, if Alice don’t get the | + | All send data segments are equipped with a unique sequence number indicating their position in the data stream. When Bob (B) receives a NAT_DATA segment form Alice (A) he acknowledges it with an NAT_DATA_ACK, if Alice don’t get the acknowledgment she will resend the segment, she will also resend it if she gets acknowledgements for 3 segments with an higher sequence Number when the, while the a acknowledgment for the older segment is still missing (Fast retransmission). |
− | + | ||
− | + | ||
− | + | ||
<pre> | <pre> | ||
A B | A B | ||
... | ... | ||
− | DATA ---> | + | DATA ---> OnRecived(0) |
OnSend(0) <--- DATA_ACK | OnSend(0) <--- DATA_ACK | ||
... | ... | ||
Line 182: | Line 170: | ||
The NAT_DATA packet have the following format: | The NAT_DATA packet have the following format: | ||
<pre> | <pre> | ||
− | [uint32 | + | [uint32] Sequence Nr. |
− | [Data | + | [Data] (optional) |
</pre> | </pre> | ||
The NAT_DATA_ACK packet have the following format: | The NAT_DATA_ACK packet have the following format: | ||
<pre> | <pre> | ||
− | [uint32 | + | [uint32] Sequence Nr. |
− | [uint32 | + | [uint32] Receiving Window Size |
</pre> | </pre> | ||
Line 243: | Line 231: | ||
The packet may contain an uint32 error code that is parsed to the OnClose function. | The packet may contain an uint32 error code that is parsed to the OnClose function. | ||
<pre> | <pre> | ||
− | [uint32 | + | [uint32] ErrorCode |
</pre> | </pre> | ||
Line 254: | Line 242: | ||
The Source Packet is built the following way: | The Source Packet is built the following way: | ||
<pre> | <pre> | ||
− | [ | + | [hast128] // file hash |
− | [uint16 | + | [uint16] // source count |
// Source entries 1: | // Source entries 1: | ||
− | [uint32 | + | [uint32] // HybridID |
− | [uint16 | + | [uint16] // TCP Port |
− | [hash128 | + | [hash128] // User Hash |
− | [uint8 | + | [uint8] // Tag list length if == 0xff (in bytes *NOT* tag count) |
− | + | // [uint16] // long tag list length | |
[Nano Tag 1] | [Nano Tag 1] | ||
... | ... | ||
Line 275: | Line 263: | ||
</pre> | </pre> | ||
− | + | Yet used Nano Tags: | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | Nano Tags | + | |
{| style="font-size: 85%; text-align: Left;Border="1"; | {| style="font-size: 85%; text-align: Left;Border="1"; | ||
! rowspan=2 | NAME | ! rowspan=2 | NAME | ||
− | |||
! rowspan=2 | ID/SIZE | ! rowspan=2 | ID/SIZE | ||
! rowspan=2 | CONTENT | ! rowspan=2 | CONTENT | ||
Line 350: | Line 272: | ||
|- | |- | ||
|NT_ServerIPPort | |NT_ServerIPPort | ||
− | |||
| [byte16] | | [byte16] | ||
| [uint32][uint16] | | [uint32][uint16] | ||
|- | |- | ||
|NT_BuddyID | |NT_BuddyID | ||
− | |||
| [byte16] | | [byte16] | ||
| [hash128] | | [hash128] | ||
|- | |- | ||
|NT_BuddyIPPort | |NT_BuddyIPPort | ||
− | |||
| [byte16] | | [byte16] | ||
| [uint32][uint16] | | [uint32][uint16] | ||
|- | |- | ||
|NT_NATT | |NT_NATT | ||
− | |||
| [byte8] | | [byte8] | ||
| [uint8] | | [uint8] | ||
|- | |- | ||
|NT_XsBuddyIPPort | |NT_XsBuddyIPPort | ||
− | |||
| [byte16] | | [byte16] | ||
| [uint32][uint16] | | [uint32][uint16] | ||
|- | |- | ||
|NT_OBFU | |NT_OBFU | ||
− | |||
| [byte8] | | [byte8] | ||
| [uint8] | | [uint8] | ||
Line 381: | Line 297: | ||
|} | |} | ||
− | + | Note: The parsing function reads the Nano tag content length from the ID/SIZE field and ts there for able to skip unknown tags. | |
− | === | + | == XS Callback == |
− | + | ||
− | |||
− | |||
+ | == Port Reporting == | ||
+ | This feature is intended to allow a LowID on a full cone Nat become a HighID by advertising the reused TCP port allocated by the Nat device. Therefore it is necessary to get from a remote client the seen TCP Port. This feature is designed similar to the official IP Report feature. | ||
+ | |||
+ | The Requesting client sends an empty packet PUBLICPORT_REQ. | ||
+ | The remote client answers with PUBLICPORT_ANSWER witch contains only an [uint16] seen TCP Port. | ||
+ | |||
+ | = Appendix = | ||
+ | |||
+ | = Nano Tag = | ||
+ | The Nano tags used in Neo XS are designed to provide high flexibility at an ultra low Overhead, they are 2 tag types short and long they are distinguished by the first bit and build the following way: | ||
+ | |||
+ | Short tag (1 to 4 data bytes): | ||
+ | <pre> | ||
+ | [uint8] // [bit1] == 0 | ||
+ | // [bits2-3] // Data Len = (0,1,2,3)+1 (in bytes) | ||
+ | // [bits4-8] // Tag ID = {0-31} | ||
+ | [data] // data bytes | ||
+ | </pre> | ||
+ | |||
+ | Long tag (5 to 255 data bytes): | ||
+ | <pre> | ||
+ | [uint8] // [bit1] == 1 | ||
+ | // [bits2-8] // Tag ID = {32 - 127} note {0-31} would work but is not recommended | ||
+ | [uint8] // Data Len = (5,...,255) (in bytes) // 0-4 would also work but is not recommended | ||
+ | [data] // data bytes | ||
+ | </pre> | ||
== NAT Types == | == NAT Types == | ||
Line 409: | Line 348: | ||
|- | |- | ||
|OP_NAT_PING | |OP_NAT_PING | ||
− | | ' | + | | '_' |
|- | |- | ||
| | | | ||
|- | |- | ||
|OP_NAT_SYN | |OP_NAT_SYN | ||
− | | ' | + | | '_' |
|- | |- | ||
|OP_NAT_SYN_ACK | |OP_NAT_SYN_ACK | ||
− | | ' | + | | '_' |
|- | |- | ||
|OP_NAT_DATA | |OP_NAT_DATA | ||
− | | ' | + | | '_' |
|- | |- | ||
|OP_NAT_DATA_ACK | |OP_NAT_DATA_ACK | ||
− | | ' | + | | '_' |
|- | |- | ||
|OP_NAT_FIN | |OP_NAT_FIN | ||
− | | ' | + | | '_' |
|- | |- | ||
|OP_NAT_FIN_ACK | |OP_NAT_FIN_ACK | ||
− | | ' | + | | '_' |
|- | |- | ||
|OP_NAT_RST | |OP_NAT_RST | ||
− | | ' | + | | '_' |
|- | |- | ||
| | | | ||
|- | |- | ||
− | | | + | |CT_EMULE_BUDDYID |
− | | ' | + | | '_' |
|- | |- | ||
− | | | + | |CT_XS_EMULE_BUDDYIP |
− | | ' | + | | '_' |
|- | |- | ||
− | | | + | |CT_XS_EMULE_BUDDYUDP |
− | | ' | + | | '_' |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
|- | |- | ||
| | | | ||
|- | |- | ||
|OP_NAT_CALLBACKREQUEST_KAD | |OP_NAT_CALLBACKREQUEST_KAD | ||
− | | ' | + | | '_' |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
|- | |- | ||
| | | | ||
|- | |- | ||
|OP_XS_BUDDY_REQ | |OP_XS_BUDDY_REQ | ||
− | | ' | + | | '_' |
− | + | ||
− | + | ||
− | + | ||
|- | |- | ||
|OP_XS_BUDDYPING | |OP_XS_BUDDYPING | ||
− | | ' | + | | '_' |
|- | |- | ||
|OP_XS_MULTICALLBACKUDP | |OP_XS_MULTICALLBACKUDP | ||
− | | ' | + | | '_' |
|- | |- | ||
|OP_XS_MULTICALLBACKTCP | |OP_XS_MULTICALLBACKTCP | ||
− | | ' | + | | '_' |
|- | |- | ||
|OP_CALLBACKREQUEST_XS | |OP_CALLBACKREQUEST_XS | ||
− | | ' | + | | '_' |
|- | |- | ||
|OP_NAT_CALLBACKREQUEST_XS | |OP_NAT_CALLBACKREQUEST_XS | ||
− | | ' | + | | '_' |
|- | |- | ||
| | | | ||
|- | |- | ||
|OP_PUBLICPORT_REQ | |OP_PUBLICPORT_REQ | ||
− | | ' | + | | '_' |
|- | |- | ||
|OP_PUBLICPORT_ANSWER | |OP_PUBLICPORT_ANSWER | ||
− | | ' | + | | '_' |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
|- | |- | ||
|} | |} | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− |