Stephen's Weblog

Hi everyone, it’s been a while, but here are my priorities in the homebrew realm for the immediate future. I’m going to disappoint some of you, sorry – but this is how it has to be.

The DSWifi project is going to be discontinued for the time being, until sometime next year. I’m not going to go into more detail on why, but I will not be continuing to work on it for now. I would like to turn it over to an individual or group of people if anyone would like to maintain it – if you’d like to do this, get in contact with me (on IRC, or leave a comment, or send an email…)

I will be starting a new project to reverse engineer the Wii’s wireless hardware, and build a new library based on it. This is expected to start around the start of december, and run a few months (who knows how long it will take)

The DSTunnel project is currently inactive, but I will make an attempt to revive it later this year, I would like to first complete the Wii wifi library, and I may actually build DSTunnel directly for the wii, or at least as one of the supported platforms.

I have 2 undisclosed DS projects that I will be working on… you’ll just have to wait and see what they are :)

Beyond all that, I have a few other general purpose libraries (besides the 802.11 and TCP/IP libs) that I’m going to start on at some arbitrary time (FAT lib, crypto lib, and some others) and a few emulator projects I want to work on.

So, that’s what my schedule looks like for the next several months – I now await your kind comments and harsh criticism ;)

I received an email not long ago indicating that there was a bug in the checksumming code in the lib – and as it turns out there was indeed an instance where the checksum was still being calculated incorrectly – this bug only affects UDP packets, and not very many of them (I’d estimate somewhere around 1 in 30000 packets may be affected, given average use)
Anyway, a patch has been made, the dswifi CVS repository at devkitpro has been updated with the modified code, if you would like to update it. I will not be releasing an updated compiled release package for this bug, as there is a rewrite planned of the whole thing in the near future.
Sorry for the lack of updates lately, I’m still not quite sure what things I should be working on and what order to get them done in – I will post more when I finish making up my mind :)

Another revision hits the presses, get your downloads at the Sourceforge dswifi files page.
There are some major bugfixes in this release, but besides that, it’s not really changing functionality much.
Many of you might thank me for the following changes:
*Fixed major bug in arm7 (potentially causing arm9 to lose track of the buffer, and lock up I/O – odd that I hadn’t seen this happen, but someone else certainly had, and let me know about it)
*Changed default behavior to use internal allocation system for memory (fixes interrupt allocation bug) (this was pretty stupid on my part, but it is fixed now. Now, for default behavior, the lib allocates a block of memory at startup and the default functions alloc/free from this small heap (you can still use your own, if you like, but you have to add an extra flag to the arm9′s init call, which is WIFIINIT_OPTION_USECUSTOMALLOC. The default heap size is 128k, but there are flags to specify 64k, 256k, and 512k as alternate heap sizes. 128k is probably more than most people will need, if you need lots of TCP connections (>7), then you will need to specify a larger heap size.)
*Fixed bug that could cause _CANNOTCONNECT to come up incorrectly when associating (this was a “transient” problem, occurred due to 2 state changes that were offset by a bit, causing a condition I didn’t initially expect – it is fixed now and Wifi_AssocStatus() should return values consistent with what you’d expect)
*Fixed blocking send() to actually be blocking. (odd that, I evidently didn’t set it up earlier. It is blocking-capable now though)

I’m not re-releasing the examples package because they’re essentially the same; there is only one difference and that’s I’ve removed the sgIP_malloc and sgIP_free functions from the wifi_lib_test project.
On a side note, if you do notice any bugs in the lib, please do contact me, via IRC (#dswifi on efnet or blitzed) or other means. I’m expecting to set up a bugtracker in the near future too, so there will be a more formal way to yell at me :)
Ok, And for those of you who are unhappy cause your favorite feature got left out (be it probe requests, the WFC data alternate WEP key format, or native Nintendo USB key compatibility) – sorry, but this project has become stagnant, probably because I’m continually trying to refine it and just don’t feel like it anymore really; I’ve decided to put the whole lib on standby for the immediate future, and when I continue (probably mid-november) I’ll start with a complete rewrite of the 802.11 system and the TCP stack, for version 0.5 – at that point I’ll have the chance to actually do some of these things *right*, and I perhaps won’t be as frustrated with a codebase based on flawed assumptions and a general lack of understanding ;)

I’ll post again sometime soon with information about what projects I am presently going to be pursuing, and which ones are on the back burner.

Just because I figured this should probably make it out to the public; I’ve done something horrible in the wifi lib that could potentially make code running alongside it crash. To be clear, this will be fixed in 0.3b, which I am trying to get out as soon as I have time to do so.
However, just because it’s good to know if you’re developing an app using 0.3a, here’s the details of the bug:
In the wifi lib, when receiving packets and under a few other circumstances, the Wifi lib in it’s present form performs a malloc call from within the Wifi_Timer() call, and can also perform a malloc call from within the Wifi_Sync function, for FIFO messages – the only problem is both of those calls are often within interrupts, so the possibility of pre-empting a malloc in “normal” code (which, malloc is also called in printf, for reference) is nontrivial. The only problem with this, is that malloc wasn’t really designed for that, so a malloc call preempting another malloc call can cause fatal problems, corrupt the heap, or crash your code.
There are a few ways to deal with this problem, the first of which is to use a seperate heap allocator, which is the solution I’ll be incorperating into 0.3b. Those of you in the know can also implement some form of locking, wrapping allocation calls in interrupt disabling code, or something similar.
Another thing to make note of is this modification will cause the wifi lib to eat up a specific amount of memory on startup (which will be user selectable, probably set to 64k or 128k for a default) – there will also be the option to disable the new memory management if you have your own solution; which will be an extra flag that will be necessary to use in the init call!
So, if you’ve had some problems with the wifi lib crashing for the past few versions, it’s likely my fault, combined with your use of malloc/printf; all will be fixed soon though, and 0.3b includes a few other bugfixes for various other problems – I’ll list the fixes when it comes out.

I’ve decided instead of doing the 802.11 rewrite now, I’ll make another release version before I start on the version that will become 0.5.
A few things are prompting me to do this, primarily because I’m engaged in figuring out how to use nintendo’s usb stick, and can have that functionality as well as the “finding hidden APs” in the near future rather than making everyone wait a lot longer. Also (thanks to BigRedPimp) I should be able to deliver compatibility for the AOSS access point records stored in the ds’s firmware.
So, just to let you all know I’m not scrapping my entire 802.11 stack and starting from scratch *just yet* ;)

That’s right, the new DS wifi lib has now been released! 0.3a is hot off the presses and better than ever!

Since the project is now on sourceforge, I’ve decided to let sourceforge handle the source and lib distribution for now – if you’d like the source, please refer to The DSWifi library on Sourceforge.
I am however still making one package available to the public, this package contains the latest examples that I’ve put together (the wifi_lib_test, and a new version of the wifi_example1 project I released with 0.3)
That package is available here: dswifi_lib_v0.3a_full.zip (440k)

Now, it would take a really long time to list all of the improvements over 0.3 that exist in 0.3a, but I’ll summarize the main points:
* working, stable, faster TCP
* several major bugs fixed in other parts of the lib
* more correct berkley sockets emulation (though still not perfect)
* Shared key authentication support!
* due to the last entry, and other things, a much wider range of router compatibility!
There are a number of other small things that have been fixed, just enjoy the new release!

I’m still looking forward to all the crazy & fun stuff I’m sure so many of you will come up with, based on this powerful library

Have fun!

Sorry guys, but I didn’t get around to writing the improvements I alluded to and completing a new lib last weekend – I realize we’re now near the end of the wifi game coding compo, and I don’t really have time still to get out a new version in time. Rather than stress everyone and release a new lib at the last minute, I’ve decided to attempt the release again this weekend (saturday) and in the meantime I encourage anyone entering in the ndshb wifi game compo to get the latest version from CVS and compile it (latest version as of well, last week) for use in your entry rather than using the last actual library release. If for whatever reason you can’t compile the lib, I may be able to help you out and provide an actual compiled lib of the latest CVS source.
Anyway, I’m just far too bogged down with work at the moment, but I’m looking forward with great interest to the results of the upcoming competition – again, good luck all :)

Again, a very small CVS update, addressing a few issues brought to my attention by people bugging me :)
This CVS update contains:
* DHCP fix! Now the intermittent failing of DHCP and the days of getting an IP of 0.0.0.0 should be over.
* FIONREAD support (As requested)
* connect() now operates in blocking mode! If you enable non-blocking mode before calling connect, it will still return immediately indicating success, but several people have asked for blocking mode (and I’ve been planning to add it anyway, just to be more “correct”)

That’s all the feature updates at the moment, and I must apologize because they’re not very well tested at this point, but they should work. (I just don’t have the time to test today… at all)
If for some reason they don’t work, please let me know, of course.
Additionally, this is already known to some of you, but I have plans to add many new features and release a new precompiled library on friday or saturday this week – among the features planned to be added are:
select() support,shared key authentication, support for ”hidden” APs (by way of probe requests), lingering TCP connections on close (so they shut down properly), and a few other large and small items. If you have requests, please post them :)
Anyway, need to get back to work…..

Again, no *really* major changes, but I thought I’d let you people know there has been a MAJOR TCP bug fixed, and as a result, connections are apparently rock solid stable :)
Many thanks go to DragonMinded for his persistence in making me track down the bugs, hehe. (and let me just say, some of the features coming up in DSOrganize will blow you away :)

Anyway, keep watching for more updates when I get some real features put in and not just bugfixes, and be sure to let me know if you find any bugs!

…is on cvs, this should fix the inet_addr / gethostbyname ip address resolution crash bug.
There’s also a TCP update, and it appears that some problems have been resolved (though probably not all)

Sorry about the lack of updates, I’ve been quite busy with other things.
As of present there are a lot of things half-done, so when I get some time I’ll add more.