dswifi
dswifi copied to clipboard
devkitPro
Add support for WPA/WPA2 when running in DSi mode
The title should be self-explanatory, supporting WPA/WPA2 in DSi mode would in theory be possible using the already functional code in nocash's wifiboot.
I don't know enough about the internals of the DS(i) yet to be able to implement this myself, but I'm willing to help in any way that I can.
nocash's DS(i) software doesn't use any of the preexisting homebrew infrastructure, not even libnds (let alone dswifi). Adding Atheros Wifi support would entail writing an entirely new driver from scratch since nocash's code cannot really be used under our infrastructure. On top of that, dswifi is in dire need of a complete rewrite due to several historical reasons.
Writing a Wi-Fi/TCP/IP stack from scratch for the DS(i) sounds like it could be an interesting project, though it would take quite some time to fully realize.
Is there anyone I should reach out to first, or should I just start toying with it and see if I get anything functional out of my attempts?
Of all people to respond to this, you're probably the last person who would have crossed my mind :P
That said, to the best of my knowledge nobody knows too much about it aside from nocash, with the documentation on gbatek and fully functional implementation in pure assembly in wifiboot. Again, I only started looking into the DSi homebrew scene a few weeks ago, so it's quite possible that somebody who knows more about the community could give you some better pointers.
I'm more thinking in the sense of "what overarching design mistakes not to make" - I'm aware wading through gbatek and talking to the hardware would be my responsibility, here.
this exists now, in some state anyway https://github.com/thomtl/wifisdio https://www.youtube.com/watch?v=TvrUzWdxKag just figured I'd mention it for whoever is interested
I have a working driver w/ WPA2 and LwIP now at https://github.com/shinyquagsire23/dsiwifi, though I'm still in the process of getting it cleaned up and actually linkable to homebrew. My current plan is to keep the same API as dswifi, but with a new prefix (ie Wifi_InitDefault -> DSiWifi_InitDefault) and if it's running on an NDS or SDIO is disabled, it will just fall through to dswifi. I'll probably end up targeting https://github.com/mtheall/ftpd as a PoC.
@fincs "On top of that, dswifi is in dire need of a complete rewrite due to several historical reasons." Is this referring to sgIP specifically? I'd never actually written NDS homebrew until dsiwifi but all that I can vaguely gather is that people wanted an LwIP port for some reason.
@asiekierka I haven't figured out the threading requirement yet, but my understanding is that it may technically work fine as long as the POSIX sockets are done 100% outside of IRQs and the TCP thread is run off of timer3. Otherwise there's the synchronous/callback APIs available.
I mostly just made it separate because the Atheros drivers are 100% different from the Mitsumi drivers, and I had a vague idea of trying to make it a 3DS/DSi library? I actually ported it from 3DS to DSi but I think realistically 3DS would benefit from its own repo. But that's actually what I'm unsure about, every console with an Atheros would never want to use the Mitsumi, so a hybrid configuration would be a DSi library with dswifi linked in as a fallback, and if dswifi would take up too much extra space then linking only dsiwifi or dswifi would be beneficial. But realistically almost nothing from dsiwifi would end up backporting to dswifi I don't think.
Hmmm yeah I guess there's a point to be had there. I do think there's some value in explicitly depreciating dswifi and allowing old stuff to be compiled only for NDS/sgIP, while also making sure that anything new is explicitly compiled as a hybrid DSi application, with a hybrid DSi wifi library that only uses LwIP.