Nintendo DS port of the lwIP IP stack

NOTE: this port is currently not being maintained as dswifi now has TCP.

This is a port of the lwIP IP stack over to the Nintendo DS. For the source download the HTML server demo tar ball.

The wireless side of things is based on the dswifi library. Thankfully Stephen Stair put in hooks to allow for the dswifi library's IP stack implementation to be replaced.

If you want to discuss or ask questions about the port venture over to the gbadev.org forums.

This is a very early release and somethings do not work. If you find any problems and/or fixes let me know.

Why lwIP?

A google search for "small IP stack" came up with it. The source for the stack is freely available and usable (the port current consists of a few header files plus the glue for interfacing between dswifi and the stack). After having a quick look at it, the stack seems to provide good functionality and it appears to still be an active project.

Using the Stack

The source code download contains some documentation of how to use the stack. Search the Internet for examples and other documentation. Have a look at the source as well.

The stack is not protected with semaphores. The port does not protect the stack so it is not reentrant. Therefore all functions the interface the stack must be called from the same thread of execution. As most people do not use any threading library on the DS this will only cause a problem if you call the stack from within an interrupt handler. Do not do this - see the html server source for an example of passing events from interrupt handers to the main loop.

Note: if you are using devkitARM r18 (with arm-elf-gcc version 4.1.0) compiling the header files from the lwIP stack will generate lots of warnings regarding the packed attribute. You can repress these by adding the -Wno-attributes option when running the compiler.

Configuring the Stack

The stack is very configurable. This is done by editing the lwipopts.h file (this should be the only file you need to edit within the source for the stack).

API

Currently you have to use the low level API (see doc/rawapi.txt) to interface with the stack. There is a Berkeley socket like interface in the source but it requires support of operating system type functionality (message passing and semaphores and the like) which has not been implemented in the current port. This may remain the case and a different socket like interface written depending on what seems to make most sense.

Things I have not played with

The reason for the port is that I want to use HTTP and therefore need TCP which dswifi does not curently supply. Therefore I have not played around with other areas of the stack. If things on this list work let me know.

• DHCP
• UDP
• PPP
• raw IP

Things that do not work

This list is by no means complete. I have done no real testing of the port and only found problems through using it.

• No copy TCP send - passing zero as the copy parameter to the tcp_write function locks up the program.

HTML Server Demo

As a demo of using the stack I have done a web server. It serves the same fixed response for any GET request but should show if your setup is working. You should be able to ping your DS as the stack implements ICMP.

The code is based around version 0.2b of the dswifi library's test program, so no WEP. Once running connect to your AP and when you get to the menu with the item "iwLP Test (no return)" select that and the web server test will run. At this point you should be able to ping your DS and, if you point firefox or the like at the DS's IP address, get the web page back from it

Note: The program will display the following:

Assertion "Test assert" failed at line 556 in test_lwip.c

This is not a problem and is only testing the assertion printing mechanism.

Controls

The controls to scroll around the messages was added in the 2006-04-10 version.

Debugging

If things are not working for you then you can turn on debug printout from the lwIP stack by changing:

to

in the file lwip-1.1.1/src/include/lwipopts.h. You can then enable debug for seperate areas of the stack (there are examples commented out in the header file).

Source tar balls

The binaries

Thoughts for the future

Things that may happen.

• Provide a Berkeley sockets like interface.
• Provide a DNS client.
• Have the choice to run the stack down on the ARM7 - nice as this is where the wifi happens (why do I see the ARM7 as being below the ARM9?). Maybe problems with code size if run in private memory or speed if run out of main memory. Some sort of split in the code, running some functions in private RAM and less frequence stuff in main RAM. Use a smaller stack like uIP.