What the h*** is NAT2.5

I've been tracing this bug for nearly two weeks in my free time.
The bug made the Realtek RTL8186 SoC hardware--that I was working with--didn't forward PPPoE packets from its ethernet interface to its WLAN interface even if both of the interfaces had been bridged together by using brctl--the bridge utilities (http://bridge.sourceforge.net/).

After doing some quick code inspection from different subversion revision of the firmware source code--that I'm working with--I found a very suspicious piece of code:

...
/** clues from revision 14. This revision has the eth to WLAN forwarding works  */
        // set nat2.5 disable when client and mac clone is set
        apmib_get(MIB_WLAN_NAT25_MAC_CLONE, (void *)&intVal);
        if ((intVal == 1) && (mode == 1)) {
                pmib->ethBrExtInfo.nat25_disable = 1;
                pmib->ethBrExtInfo.macclone_enable = 1;
        }
        else {
                pmib->ethBrExtInfo.nat25_disable = 0;
                pmib->ethBrExtInfo.macclone_enable = 0;
        }
...

Now, in the code above, macclone is very clear from its name alone. But, what the h*** is Nat2.5? I've been working with IP layer NATs, but I've never heard of this Nat2.5 stuff. Upon searching the internet and cross checking the information with the Application Note I have at hand, I found out that it's some sort of "MAC address translation". It works this way:

Device_1_ethernet <---> RTL8186_ethernet<-->nat2.5<-->RTL8186_WLAN(client_mode)<-->WLAN_Access_Point

Nat2.5 will translate (transform as per the Application Note lingo) the MAC address of ethernet packets from the Device_1_ethernet to RTL8186_WLAN MAC address before forwarding the packets to the WLAN_Access_Point via the radio link.
At first, this sounds counter-intuitive. Why do you need the tranformation? I don't know for sure. Nonetheless, if we go back to the Ethernet vs WLAN/802.11 specification, it's clear that both 802.11 and Ethernet shares the same "Logical Link Control" sublayer (in the upper half of data link layer), but both of them have a different "Medium Access Control (MAC)" sublayer (in the lower half of data link layer). Because MACs from both protocol are different, then there should be "transformation". I think that's the reason.

Anyway, the following is the code in svn revision 115 before the fix

...
       // disable nat2.5 and macclone entirely -- darmawan
       pmib->ethBrExtInfo.nat25_disable = 1;
       pmib->ethBrExtInfo.macclone_enable = 0;
...

and this is the code after the fix.

...
       // Enable nat2.5 when in client mode, 
       // but disable macclone entirely -- darmawan
       apmib_get(MIB_WLAN_MODE, (void *)&mode);
       if (mode == CLIENT_MODE) {
               pmib->ethBrExtInfo.nat25_disable = 0;
       }
       else {
               pmib->ethBrExtInfo.nat25_disable = 1;
       }
       pmib->ethBrExtInfo.macclone_enable = 0;
...

So, that's it. There you have it, the freaking Nat2.5.

---

Post a Comment