Transparent Wi-Fi module with RMII input

Question

I need to convert a Ethernet-connected embedded project with wireless connection.

I'm looking for a low-cost (main constraint, less than USD $15) and most open-source/-hardware possible Wi-Fi bridge module, like Vonets.

It need to behave transparent, redirecting all network frames (transport layer) to existent-and-already-stable IP stack implemented at current ETH hardware with minimal firmware modification; if possible, using existent RMII pins.

My first attempt was with ESP8266, but there's some very painful challenges:

• I couldn't just change transceiver and RJ-45 with it, because it's communication is UART-based (some module variants support SPI). To workaround that, I tried enabling PPPoS to communicate uC<->ESP8266, then sending data through ESP's built-in IP stack and forwarding it to Wi-Fi adapter and then to Internet.

However, although it's LwIP port had PPP_SUPORT #define's at source code (which seems to be added in a recent release v1.4.0 from March-2016), there's no documentation about enabling it and it's usage. Furthermore, IP forwarding also seems not be supported between virtual interface (e.g. ppp0) and "real" interface (e.g. wlan0).

1. Do you suggest some other hardware to do the "Wi-Fi bridge" job? Should ESP32 (not launched yet at the moment) the solution to convert RMII signals?
2. In the case of keep using ESP8266, there's another protocol or way to made it transparent?

Answer 1

While possible in principle, MII isn't really used for interfacing wireless PHYs, because all the small differences add up.

• 802.11 has different inter-frame gaps for different traffic classes to give it a crude priority schema
• MII only transports user datagrams, so association and authentication would need to be transported over MDIO.
• The destination MAC address in 802.11 is the next wireless hop, not the address of the next routing hop, so the packet needs to be rewritten, moving the next routing hop to the first auxiliary address field and adding the AP address
• ...

So basically the PHY would need to replicate the entire MAC logic anyway, and the effort in implementing the side channel communication would outweigh the savings from reusing the MII interface.

The main reasons to use the integrated MII Ethernet controller would be to use the multicast filter and packet size sorting in memory-constrained devices. The multicast filter needs to be replicated in the PHY, because of the way multicast packets are appended to the beacon, and the packet size sorter is only relevant for very small devices, where tighter integration and smaller footprint are even more important than ease of implementation.