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 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 254: Line 242:
 
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]       // 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]         // Tag list length if == 0xff (in bytes *NOT* tag count)
if len == 0xff [uint16 2] // long tag list length
+
                // [uint16] // long tag list length
 
[Nano Tag 1]
 
[Nano Tag 1]
 
...
 
...
Line 281: Line 269:
  
 
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.
 
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:
 
A normal Low2High Callback request looks like following:
  
 
<pre>
 
<pre>
[hash128 16]     // Target client user hash
+
[hash128]     // Target client user hash
[uint8 1]        // Mod Opcode (OP_CALLBACKREQUEST_XS)
+
[uint8]        // Mod Opcode (OP_CALLBACKREQUEST_XS)
[uint16 2]      // Requesting clients TCP Port
+
[uint16]      // Requesting clients TCP Port
[obfuscation 17] // obtional obfuscation  
+
[obfuscation] // obtional obfuscation  
                // [uint8 1] obfuscation settings
+
              // [uint8] obfuscation settings
                // [hash128 16] userhast
+
              // [hash 128] userhast
 
</pre>
 
</pre>
  
 
The packet is modified slightly by the buddy and sent as following to the Low ID client:
 
The packet is modified slightly by the buddy and sent as following to the Low ID client:
 
<pre>
 
<pre>
[uint32 4]      // IP of the requester
+
[uint32]      // IP of the requester
[uint16 2]      // UDP Port of requester
+
[uint16]      // UDP Port of requester
[uint8 1]        // Mod Opcode (OP_CALLBACKREQUEST_XS)
+
[uint8]        // Mod Opcode (OP_CALLBACKREQUEST_XS)
 
// rest unchanged like above
 
// rest unchanged like above
 
...
 
...
Line 320: Line 298:
 
= Appendix =
 
= Appendix =
  
== Nano Tag ==
+
= 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:
 
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):
 
Short tag (1 to 4 data bytes):
 
<pre>
 
<pre>
[uint8 1] // [bit1] == 0
+
[uint8]   // [bit1] == 0
           // [bits2-3] // Data Len n = (0,1,2,3)+1 (in bytes)
+
           // [bits2-3] // Data Len = (0,1,2,3)+1 (in bytes)
 
           // [bits4-8] // Tag ID = {0-31}
 
           // [bits4-8] // Tag ID = {0-31}
[data n] // data bytes
+
[data]   // data bytes
 
</pre>
 
</pre>
  
 
Long tag (5 to 255 data bytes):
 
Long tag (5 to 255 data bytes):
 
<pre>
 
<pre>
[uint8 1] // [bit1] == 1
+
[uint8]   // [bit1] == 1
 
           // [bits2-8] // Tag ID = {32 - 127} note {0-31} would work but is not recommended
 
           // [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
+
[uint8]   // Data Len = (5,...,255) (in bytes) // 0-4 would also work but is not recommended
[data n] // data bytes
+
[data]   // data bytes
 
</pre>
 
</pre>
  
Line 380: Line 358:
 
|-
 
|-
 
|}
 
|}
 
== Additional Modifications ==
 
 
=== Fix for eServer Connect ===
 
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!
 
 
  
 
== NAT Types ==
 
== NAT Types ==
Line 409: Line 378:
 
|-
 
|-
 
|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