Okay, let's get this party started!
One of the biggest gaps in functionality for Linux right now is support for the wireless network adapter.
As a bit of background, networking on the Wii is implemented using several modules, working together:
* SO ("socket") -- this layer vends the
Berkeley Socket API (connect, listen, send, receive, etc).
* NCD ("Network Configuration Driver") -- this handles configuring the network adapters, choosing the appropriate one and obtaining an IP for it
* ETH (USB Ethernet driver) -- this is a driver for the official Nintendo USB Ethernet adapter
* WD ("Wireless Driver"?) -- this driver controls the lower-level WL driver; it also is the driver that contains the logic to deal with "Nitro" (DS) connections
* WL ("Wireless Link"?) -- this driver interfaces to the
BCM43xx wifi adapter, probably over SDIO.
Currently, libogc uses the network adapter through SO, the high-level interface. This is not an appropriate interface for Linux to use, because its IP stack would really rather be dealing with raw frames. There are evil hacks that can interface that with a BSD-sockets layer, but we really don't want to go there. Networking is supported under Linux using its native driver for the USB-Ethernet adapter, in place of ETH and the rest of the stack.
What we need to do is either find a way to directly talk to the BCM43xx chipset from the Broadway (somewhat unlikely), or find an appropriate interface amongst the above-mentioned modules.
I've placed some info on the
Wiibrew Wiki, but I'll expand here in the hopes that someone will take this project and push it further:
* WL -- /dev/wl0 seems to have exactly one ioctl -- 2 -- and it takes in a command ID which is in the range 0-300 or so. If you could match these up cleanly with, say,
these docs -- that would be a viable option.
* WD -- WD talks to WL; in part, this is probably so that it can disable normal WiFi and switch to bizarro DS WiFi, but that doesn't mean we couldn't use it. It exposes
/dev/net/wd/command, which looks like it might have useful functions like "send frame", but to figure out how you need to call that, you'll need to reverse SO.
* SO -- There is a high-level API (/dev/net/ip/top) that is unsuitable. This driver talks to both the usbeth driver and the wd driver via two similar interfaces -- /dev/net/usbeth/top and /dev/net/wd/top. That seems like a good candidate, because it's an abstraction point over general network interfaces. There is also a /dev/net/ip/bottom, which is probably a low-level version of /dev/net/ip/top -- it would also be a good candidate, but I don't see any code using it yet, so again, you'd have to reverse SO to figure out how it works.