Editing NatT protocol

From EMule Wiki
Jump to: navigation, search

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 connectible, but it works only in a few cases.
+
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). If this is not the first communication between Alice and Bob, Alice knows Bobs old UDP port and before she issue a call-back request she always tries to ping Bob directly. When the port is still valid, this will not only success on a full Cone NAT, but can also helps to save one call-back request on other NAT Types / Firewalls.<br>
+
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
               // 5 reserved
+
               // 4 reserved
               // 2 IdKind
+
               // 3 IdKind
 
               // 1 req answer
 
               // 1 req answer
[ID]          // variable length determined by the Ping Options above may not be set at all
+
[ID]          // variable length determined by the Ping Options above
 
[Obfiscation]  // uint8    obfuSetings
 
[Obfiscation]  // uint8    obfuSetings
 
               // hash128  userHash
 
               // hash128  userHash
 
</pre>
 
</pre>
There are yet 3 ID Kinds:
 
* IdKind == 0 :: means no ID field sent
 
* IdKind == 1 :: [uint32 4] ed2k ID
 
* IdKind == 2 :: [hash128 16] Kad ID
 
* IdKind == 3 :: [hash128 16] User Hash
 
  
 
== Callback Methods ==
 
== Callback Methods ==
  
 
=== eServer (Lugdunum) ===
 
=== eServer (Lugdunum) ===
The eserver call-back is supported since eserver 17.15, it requires both 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 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 behaviour is optional.
+
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 4] Target ID (Bob's ID)
+
[uint32] Target ID (Bob's ID)
[uint32 4] Requester ID (Alice's ID)
+
[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 4] Seen IP
+
[uint32] Seen IP
[uint16 4] Seen Client UDP Port
+
[uint16] Seen Client UDP Port
[uint32 4] Requester ID (Alice's ID) (may be 0)
+
[uint32] Requester ID (Alice's ID) (may be 0)
[obfuscation 17]  // optional
+
[obfuscation]  // obtional
                // [uint8 1] obfuscation settings
+
              // [uint8] obfuscation settings
                // [hash128 16] userhash
+
              // [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 16]      // Target client Kad ID (Bob)
+
[hash128]      // Target client Kad ID (Bob)
[hash128 16]      // File Hash of the pinged file
+
[hash128]      // File Hash of the pinged file
 
// the part below is the unofficial mod part
 
// the part below is the unofficial mod part
[uint8 1]         // Mod Opcode (OP_NAT_CALLBACKREQUEST_KAD)
+
[uint8]       // Mod Opcode (OP_NAT_CALLBACKREQUEST_KAD)
[hash128 16]      // Requesting client Kad ID (Alice)
+
[hash128]      // Requesting client Kad ID (Alice)
[uint32 4]       // IP of Dave (Alice's buddy)
+
[uint32]       // IP of Dave (Alice's buddy)
[uint16 2]       // UDP Port of Dave (D)
+
[uint16]       // UDP Port of Dave (D)
[obfuscation 17]  // obtional obfuscation of Alice
+
[obfuscation]  // obtional obfuscation of Alice
                  // [uint8 1 ] obfuscation settings
+
              // [uint8] obfuscation settings
                  // [hash128 16] userhast
+
              // [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 4]      // IP of Alice
+
[uint32]      // IP of Alice
[uint16 2]      // UDP Port of Alice
+
[uint16]      // UDP Port of Alice
[hash128 16]     // File Hash of the pinged file
+
[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)
[uint8 1]        // Mod Opcode (OP_NAT_CALLBACKREQUEST_KAD)
 
 
...
 
...
 
</pre>
 
</pre>
Line 122: Line 114:
  
 
<pre>
 
<pre>
[hash128 16]     // Target client user hash (Bob)
+
[hash128]     // Target client user hash (Bob)
[uint8 1]        // Mod Opcode (OP_NAT_CALLBACKREQUEST_XS)
+
[uint8]        // Mod Opcode (OP_NAT_CALLBACKREQUEST_XS)
[hash128 16]     // Requesting client user hash (Alice)
+
[hash128]     // Requesting client user hash (Alice)
[uint32 4]      // IP of Dave (Alice's XS buddy)
+
[uint32]      // IP of Dave (Alice's XS buddy)
[uint16 2]      // UDP Port of Dave (D)
+
[uint16]      // UDP Port of Dave (D)
[obfuscation 1]  // obtional obfuscation of Alice
+
[obfuscation]  // obtional obfuscation of Alice
                // [uint8 1] obfuscation settings
+
              // [uint8] obfuscation settings
                // Hash is not sent here because its already sent above
+
              // [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 4]      // IP of Alice
+
[uint32]      // IP of Alice
[uint16 2]      // UDP Port of Alice
+
[uint16]      // UDP Port of Alice
[uint8 1]        // Mod Opcode (OP_NAT_CALLBACKREQUEST_XS)
+
// rest unchanged
// rest unchanged like above
+
 
...
 
...
 
</pre>
 
</pre>
  
Please refer to the [[NatT_protocol#Additional Features for NatT|Additional Features for NatT]] section for further informations on the XS Buddy feature.
+
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 1] version
+
[uint8] version
[uint32 4] MAXFRAGSIZE (optional)
+
[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 acknowledgement 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).
+
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).
 
+
Note: The sequence number of sent segments always starts with 1 and is incremented by one.
+
 
+
  
 
<pre>
 
<pre>
 
A                    B
 
A                    B
 
             ...
 
             ...
DATA        --->  OnReceived(0)
+
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 4] Sequence Nr.
+
[uint32] Sequence Nr.
[Data n] (optional)
+
[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 4] Sequence Nr.
+
[uint32] Sequence Nr.
[uint32 4] Receiving Window Size  
+
[uint32] Receiving Window Size  
 
</pre>
 
</pre>
  
Line 232: Line 220:
 
Booth Packets have no content.
 
Booth Packets have no content.
  
To terminate an erroneous connection Alice (A) Sends an NAT_RST, packet and considers the connection closed, Bob (B) don’t answers on this packet and as well considers the connection closed at this point.
+
To terminate an errorless connection Alice (A) Sends an NAT_RST, packet and considers the connection closed, Bob (B) don’t answers on this packet and as well considers the connection closed at this point.
  
 
<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 4] ErrorCode
+
[uint32] ErrorCode
 
</pre>
 
</pre>
  
Line 250: Line 238:
  
 
== Neo XS ==
 
== Neo XS ==
Neo Source Exchange is an improved tag based source exchange protocol; it allows some over head saving as well as high flexibility and extendibility. It sends the IDHybrid, TCP Port and User Hash followed by a tag list with optional additional information’s like server IP, Port, Kad Buddy ID, IP, Port, NatT support Flags, XS Buddy IP, Port, Obfuscation Flags. This data are packed into so called Nano Tags (see the Appendix for Nano Tag specification).
+
Neo Source Exchange is an improved tag based source exchange protocol; it allows some over head saving as well as high flexibility and extendibility. It sends the IDHybrid, TCP Port and User Hash followed by a tag list with optional additional information’s like server IP, Port, Kad Buddy ID, IP, Port, NatT support Flas, XS Buddy IP, Port, Obfuscation Flags. This data are packed into so called Nano Tags (see the Appendix for Nano Tag specification).
  
 
The Source Packet is built the following way:
 
The Source Packet is built the following way:
 
<pre>
 
<pre>
[hash128 16]   // file hash
+
[hast128]       // file hash
[uint16 2]     // source count
+
[uint16 = n]   // source count
 
// Source entries 1:
 
// Source entries 1:
[uint32 4]     // HybridID
+
[uint32]       // HybridID
[uint16 2]     // TCP Port
+
[uint16]       // TCP Port
[hash128 16]   // User Hash
+
[hash128]       // User Hash
[uint8 1] len  // Tag list length (in bytes *NOT* tag count)
+
[uint8 = m]     // Nano Tag Count
if len == 0xff [uint16 2] // long tag list length
+
 
[Nano Tag 1]
 
[Nano Tag 1]
 
...
 
...
Line 275: Line 262:
 
</pre>
 
</pre>
  
Note: The parsing function reads the Nano tag content length from the ID/SIZE field and is there for able to skip unknown tags. Because the tag list length is sent instead of the tag count it is also possible to skip totally erroneous tag lists.
+
Yet used Nano Tags:
 
+
== XS Callback ==
+
The XS call-back is a buddy system that works without Kad, it is used for NatT Low2Low call-backs as well as for normal Low2High call-backs and it is preferred over the Kad call-back system. A High ID client may have more than one Low ID buddy (currently 3), a Low ID Client asks every XS call-back enabled client in his list one by one if he wants to become his buddy until he gets a positive answer. There for he sends an empty packet XS_BUDDY_REQ to the candidate. The remote client answers with XS_BUDDY_ANSWER witch contain an [uint8] result 1 or 0, if 0 (denied) than the xs buddy status of this client is set to DENIDED and he isn’t asked again unless all known clients have this status than its reset and they are asked again one by one. If the answer was 1 (accepted) the status is set to (HIGH_BUDDY) the remote client sets the status of our low ID client to LOW_BUDDY.
+
 
+
To keep the connection alive the Low Buddy sends every 10 minutes an empty ping packet XS_BUDDYPING, the High Buddy answers on this ping with the same empty packet, he don’t ping on its own.
+
 
+
<pre>
+
LowID                HighID
+
B_REQ        --->  SetXBS(L_B)
+
SetXBS(H_B)  <---    R_ANSW [1]
+
              ...
+
B_PING        --->
+
            <---    B_PING
+
              ...
+
</pre>
+
 
+
A normal Low2High Callback request looks like following:
+
 
+
<pre>
+
[hash128 16]    // Target client user hash
+
[uint8 1]        // Mod Opcode (OP_CALLBACKREQUEST_XS)
+
[uint16 2]      // Requesting clients TCP Port
+
[obfuscation 17] // obtional obfuscation
+
                // [uint8 1] obfuscation settings
+
                // [hash128 16] userhast
+
</pre>
+
 
+
The packet is modified slightly by the buddy and sent as following to the Low ID client:
+
<pre>
+
[uint32 4]      // IP of the requester
+
[uint16 2]      // UDP Port of requester
+
[uint8 1]        // Mod Opcode (OP_CALLBACKREQUEST_XS)
+
// rest unchanged like above
+
...
+
</pre>
+
 
+
== 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 1] // [bit1] == 0
+
          // [bits2-3] // Data Len n = (0,1,2,3)+1 (in bytes)
+
          // [bits4-8] // Tag ID = {0-31}
+
[data n]  // data bytes
+
</pre>
+
 
+
Long tag (5 to 255 data bytes):
+
<pre>
+
[uint8 1] // [bit1] == 1
+
          // [bits2-8] // Tag ID = {32 - 127} note {0-31} would work but is not recommended
+
[uint8 1] // Data Len n = (5,...,255) (in bytes) // 0-4 would also work but is not recommended
+
[data n]  // data bytes
+
</pre>
+
 
+
 
+
Nano Tags yet used by Neo Xs:
+
 
{| 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 | TYPE
 
 
! rowspan=2 | ID/SIZE
 
! rowspan=2 | ID/SIZE
 
! rowspan=2 | CONTENT
 
! rowspan=2 | CONTENT
Line 350: Line 271:
 
|-
 
|-
 
|NT_ServerIPPort
 
|NT_ServerIPPort
| Long
 
 
| [byte16]
 
| [byte16]
 
| [uint32][uint16]
 
| [uint32][uint16]
 
|-
 
|-
 
|NT_BuddyID
 
|NT_BuddyID
| Long
 
 
| [byte16]
 
| [byte16]
 
| [hash128]
 
| [hash128]
 
|-
 
|-
 
|NT_BuddyIPPort
 
|NT_BuddyIPPort
| Long
 
 
| [byte16]
 
| [byte16]
 
| [uint32][uint16]
 
| [uint32][uint16]
 
|-
 
|-
 
|NT_NATT
 
|NT_NATT
| Short
 
 
| [byte8]
 
| [byte8]
 
| [uint8]
 
| [uint8]
 
|-
 
|-
 
|NT_XsBuddyIPPort
 
|NT_XsBuddyIPPort
| Long
 
 
| [byte16]
 
| [byte16]
 
| [uint32][uint16]
 
| [uint32][uint16]
 
|-
 
|-
 
|NT_OBFU
 
|NT_OBFU
| Short
 
 
| [byte8]
 
| [byte8]
 
| [uint8]
 
| [uint8]
Line 381: Line 296:
 
|}
 
|}
  
== Additional Modifications ==
+
Note: The parsing function reads the Nano tag content length from the ID/SIZE field and ts there for able to skip unknown tags.
  
=== Fix for eServer Connect ===
+
== XS Callback ==
Due to the need of having the server's UDP Key it is needed to alternate the connection procedure to first obtain the server infos over UDP by OP_GLOBSERVSTATREQ, by the way this is sense full also for obfuscation to get the obfuscated server port.
+
  
=== Fix for Bandwidth Control ===
 
The sending/receiving functions of the Client UDP Socket must not count the size of NatT Data/Ack packets, this bandwidth is already counted by the EMSocket like regular TCP traffic. Counting it on the UDP Socket will result in false values and waisted bandwidth!
 
  
 +
== Port Reporting ==
 +
 +
= Appendix =
  
 
== NAT Types ==
 
== NAT Types ==
Line 409: Line 324:
 
|-
 
|-
 
|OP_NAT_PING
 
|OP_NAT_PING
| '0xD7'
+
| '_'
 
|-
 
|-
 
|
 
|
 
|-
 
|-
 
|OP_NAT_SYN
 
|OP_NAT_SYN
| '0xD0'
+
| '_'
 
|-
 
|-
 
|OP_NAT_SYN_ACK
 
|OP_NAT_SYN_ACK
| '0xD1'
+
| '_'
 
|-
 
|-
 
|OP_NAT_DATA
 
|OP_NAT_DATA
| '0xD2'
+
| '_'
 
|-
 
|-
 
|OP_NAT_DATA_ACK
 
|OP_NAT_DATA_ACK
| '0xD3'
+
| '_'
 
|-
 
|-
 
|OP_NAT_FIN
 
|OP_NAT_FIN
| '0xD4'
+
| '_'
 
|-
 
|-
 
|OP_NAT_FIN_ACK
 
|OP_NAT_FIN_ACK
| '0xD5'
+
| '_'
 
|-
 
|-
 
|OP_NAT_RST
 
|OP_NAT_RST
| '0xD6'
+
| '_'
 
|-
 
|-
 
|
 
|
 
|-
 
|-
|MT_EMULE_BUDDYID
+
|CT_EMULE_BUDDYID
| '0x40'
+
| '_'
 
|-
 
|-
|MT_XS_EMULE_BUDDYIP
+
|CT_XS_EMULE_BUDDYIP
| '0x42'
+
| '_'
 
|-
 
|-
|MT_XS_EMULE_BUDDYUDP
+
|CT_XS_EMULE_BUDDYUDP
| '0x62'
+
| '_'
|-
+
|
+
|-
+
|OP_NAT_CALLBACKREQUEST
+
| '0xA6'
+
|-
+
|OP_NAT_CALLBACKREQUESTED_UDP
+
| '0xA7'
+
|-
+
|OP_NAT_CALLBACKREQUESTED
+
| '0x37'
+
 
|-
 
|-
 
|
 
|
 
|-
 
|-
 
|OP_NAT_CALLBACKREQUEST_KAD
 
|OP_NAT_CALLBACKREQUEST_KAD
| '0xB0'
+
| '_'
|-
+
|
+
|-
+
|OP_NEO_ANSWERSOURCES
+
| '0x82'
+
 
|-
 
|-
 
|
 
|
 
|-
 
|-
 
|OP_XS_BUDDY_REQ
 
|OP_XS_BUDDY_REQ
| '0xB1'
+
| '_'
|-
+
|OP_XS_BUDDY_ANSWER
+
| '0xB2'
+
 
|-
 
|-
 
|OP_XS_BUDDYPING
 
|OP_XS_BUDDYPING
| '0xB3'
+
| '_'
 
|-
 
|-
 
|OP_XS_MULTICALLBACKUDP
 
|OP_XS_MULTICALLBACKUDP
| '0xB4'
+
| '_'
 
|-
 
|-
 
|OP_XS_MULTICALLBACKTCP
 
|OP_XS_MULTICALLBACKTCP
| '0xB5'
+
| '_'
 
|-
 
|-
 
|OP_CALLBACKREQUEST_XS
 
|OP_CALLBACKREQUEST_XS
| '0xBA'
+
| '_'
 
|-
 
|-
 
|OP_NAT_CALLBACKREQUEST_XS
 
|OP_NAT_CALLBACKREQUEST_XS
| '0xBB'
+
| '_'
 
|-
 
|-
 
|
 
|
 
|-
 
|-
 
|OP_PUBLICPORT_REQ
 
|OP_PUBLICPORT_REQ
| '0xA7'
+
| '_'
 
|-
 
|-
 
|OP_PUBLICPORT_ANSWER
 
|OP_PUBLICPORT_ANSWER
| '0xA8'
+
| '_'
|-
+
|
+
|
+
|-
+
|SRVCAP_NATTRAVERSAL
+
| '0x1000'
+
|-
+
|SRV_TCPFLG_NATTRAVERSAL
+
| '0x00001000'
+
|-
+
|SRV_UDPFLG_NATTRAVERSAL
+
| '0x00010000'
+
 
|-
 
|-
 
|}
 
|}
 
Note: The UDP range 0xD0 to 0xDF is completely reserver for NatT
 
 
== See also ==
 
 
* [[Nattraversal]]
 
 
[[category:Mod_protocol_extensions]]
 

Please note that all contributions to EMule Wiki may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see EMule Wiki:Copyrights for details). Do not submit copyrighted work without permission!

Cancel | Editing help (opens in new window)
Personal tools