TCP/IP stack overhaul (Step 3 of 4)

Guide target £8,900

Our network stack dates back to 1997, fully 2 years before the WiFi alliance was even formed, so there’s a simple reason why there’s no integration of WiFi into RISC OS. Networking touches all 4 corners of the operating system, so has been split into 4 steps to try to keep the changes manageable. With Step 1 and Step 2 already outlined, this bounty describes how WiFi will be built on top of the new stack; the final step not included here will expand horizons to support larger IPv6 address space.

Details

Since the network stack is derived from FreeBSD, an amount of study will be required up front to understand how the various properties of WiFi are arranged. This will determine the most flexible way to implement everything. For example, the desktop front end that users interact with should support more than 1 wireless interface, potentially supporting 2.4GHz and 5GHz radios or both, which in turn communicates via a driver (conceptually similar to the ethernet drivers we have today) which could be connected via one of several bus types (a serial bus like SDIO or SPI, USB dongle, PCI or PCI express, even on a podule!) and may offload some of the work to the main CPU such as encryption and decryption. The following list of activities outlines the sort of arrangement that might result, and includes two chipset drivers – one for the widely available Atheros family, and one for the Raspberry Pi’s built in Broadcom radio.

• Design of RISC OS APIs
  • Adapt or extend the DCI4 interface to add wireless properties
  • Extend the showstat utility to support these new properties
  • Registration of radio state service calls

• Security
  • Software assistance for chipsets that offload work to the ARM

• Desktop front end
  • Design a Toolbox application to present the list of networks on each interface
  • A dialogue or dialogues to connect to a network using whichever authentication is used
  • Dynamically configure the interface (without requiring a reboot)
  • Detection of whether additional log on steps are needed, for example hotel WiFi often needs to navigate to a web page to enter the room number
  • Animation of the icon bar icon to reflect the current radio state
  • Option to save previously seen connections

• Configuration
  • Enable any portions of the Internet module or wider stack relating to WiFi (from Step 2)
  • Presentational changes in InetSetup
  • Extra switches to the ifconfig utility
  • Failover selection when more than one interface is configured, and one drops

• Drivers
  • Write a driver for the Atheros family, using the new RISC OS APIs
  • Write a driver for the Raspberry Pi’s built in BCM43438 chipset

Deliverables

• Applicable changes to
  • Enable features previously switched off in the main TCP/IP stack
  • InetSetup and similar configuration tools
  • The territory system
• C source code to newly created modules
  • The software packet level decrypt/encrypt
  • Atheros DCI driver
  • BCM43438 DCI driver
  • Desktop front end WiFi Manager
• Documentation
  • User level documentation detailing examples of how to connect
  • Programmer level documentation for DCI driver authors to add further WiFi chipsets themselves

In the event that this bounty reaches a target that attracts a developer before Step 2 is underway, they will have to wait to begin because it builds upon those earlier improvements.

Donations	98
Guide target	£8,900.00
Total	£8,720.00 (97%)
State	Underway
Help	More information about the bounty scheme Bounty scheme discussion forum

All bounties