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.
