gbadev.org forum archive

Hi,

I was wondering why the WifiMe driver hasn't been ported to Linux or other UNIX's yet..

I myself use Linux for 99% of my development, and I think it's more or less irritating that I should switch to Win32 because this driver hasn't been ported. I mean, there's a perfect compiler toolchain (devkitARM) which is 100% compatible with Linux, but there is no way to do quick code testcycles. One could use the GBA flashcard, but not all are supported by the opensource flasher apps (ucon64 doesn't support my EZFIII for example). Therefore it would be better for the community if FireFly open-sourced the win32 driver, so someone can port it. I understand he has put lots of work in the driver and might not do that, but if he doesn't give out the source, he may at least give us some insight of the working of the driver. Else we (poor) Linux users have to reverse a closed-source win32 driver in order to code our own, this is a tedious task and doesn't support the homebrew community at all (IMHO).

I never wrote a driver for a NIC myself, so I don't know how many work it will be. But since Linux is opensource, we could take the existing RT2500 driver as a skeleton maybe..

Let me know what YOU think!

That is, unless someone owns stock in Microsoft Corporation... >:)
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

Tried using NDISwrapper or something similiar? Don't really know if it'd work with the wifimedriver, but it helped me earlier when I wanted to use a wlanadapter with only windowsdrivers available..

You'd still need some version og WMB though..

I'd like a linux driver for wifime too. That would be really great, I hate it to boot Windows so often since I got my WLAN card ....

Firefly just pointed me at this forum post. I will look further into this tonight (I hope).

Looks to me that he is at most interested in recompiling, not porting.

What we really need to get development going is that someone does a good writeup on what the packets look like, how the traffic works.. like a protocol description. If that was available people in the know would be able to write firmware for embedded stuff, linux drivers (and windows) for other cards..

This would really help development forward in my opinion.
_________________
I'm busy making powermoves.

RT2500 linux drivers are open-source:

Check it out:
http://www.ralinktech.com/supp-1.htm

&

http://rt2400.sourceforge.net/
_________________
----!-----

Next generation DS

The problem is not with the protocol on the DS side. It is a relatively standard 802.11b implementation. The problem is there is nothing on top of that 802.11b implementation to talk to. Windows and Linux both expect the system on the other end to have a network stack built on top of the raw 802.11b stuff.

Now, to get around that, you need a card that can send packets without modifying/resending/delaying them. This is much harder to find than it sounds, and the rt2500 card is the only one found so far to my knowledge.

There are network dumps out there of two DS'es starting a wireless multiboot dump. This is all the information that should be neccesary for someone of sufficient skill to get a driver up and running with the right card.

Finally, there was some work done on getting a Linux raw interface for the rt2500 card up and running. But there were bugs in it and then Firefly finished his Windows version, as far as I know, the author is no longer working on it.

I'm starting to get interested in writing a driver. No promises though, I'm attached to Win32 development projects and I haven't kept my Linux machines up. Is there a poll somewhere showing how many people would be interested?
_________________
Work in progress: Dual-Soft.com

Oh man, I tried to get this working for the longest time. If someone could create WiFiMe for Linux I'd be so happy!

Just made a poll:

http://forum.gbadev.org/viewtopic.php?p=46755#46755

gladius wrote:

Finally, there was some work done on getting a Linux raw interface for the rt2500 card up and running. But there were bugs in it and then Firefly finished his Windows version, as far as I know, the author is no longer working on it.

Who was the author? neimod perhaps? Maybe we can take his unfinished work as base code to work off :)

Edit: yes it was neimod, and no he's _not_ going to share his source :(

Code:

<bLAStY> neimod, where you the guy who started working on the linux rt2560 driver ?
<BigRedPmp> bLAStY: s/where/were/ ;)
<neimod> yes
<bLAStY> english is not my native language! </lame excuse>
<bLAStY> neimod: care to share your work with "the community" so we can continue to work on it ?
<neimod> nah :-P

Given that I only ever use Linux at home, and developing using a flash cart is too crippling to conceive, I'm prepared to offer a bounty (cash reward, not the chocolate bar) to the first person to release a Linux driver under the GPL which allows wireless booting of homebrew applications on a modified (FlashMe) Nintendo DS.

I would encourage other people to add their opinions on this idea, as well as their money to the reward!

If the response is positive, I'll post the full requirements and, of course, the value of the bounty.

Not such a bad idea. Maybe we can set up a bounty just like the currently running NDS WiFi bounty. I'm surely willing to donate some money for this, and maybe others as well.

What is the aim of the NDS WiFi project? Is implementing TCP/IP a first-step in writing a web browser for NDS? I'm surprised this hasn't been done commercially yet.

Anyway, what does everyone think the licensing of the open source Linux WiFime should be? GPL, or something else? Are there any requirements I've missed?

I think the aim of the wifi project is to just get a basic TCP/IP implementation working that anyone can use.

As for a commercial web browser, I don't think any commercial games that support TCP/IP (instead of just NiFi) have been released yet, so it's not surprising that there isn't one yet.

The kernel driver should to be GPL to be compatible with the kernel. The user space tools could be under pretty much any free license, though it might be a good idea to keep it all GPL for simplicity. I doubt there would be much benefit to putting the tools under a different license anyways.

-Michael

Yeah, I wasn't sure about the licence, because the TCP/IP project says it doesn't want any "contaminating" licences. They want an implementation that can be used by anyone, even in a closed source application, which wouldn't be possible under GPL. This isn't a concern for our driver, because no other software will ever use it (it'll always be just a driver), unlike the TCP/IP stack which could find its way into commercial games. Much the same is true for the tools which take the binary and send it to NDS.

Collecting the money from people might be difficult, though. If they just post messages here, there's no real way to make them pay up later. Similarly, I don't really want to take care of people's donations while we wait for the port, and people probably wouldn't want to send them to me anyway. It's not like anybody knows who I am, so why should they trust me?

Really, it'd be nice if a moderator or somebody else trustworthy (maybe StoneCypher would be interested?) could handle donations and setup a website for this project.

not used linux for a long time (since i dont beleive linux has anything anymore that XP lacks) but has anyone actually TRIED using NDISwrapper and wine to run the windows driver/apps? i cant see a reason why this wouldnt work

Yes, it has been TRIED. No, it doesn't WORK.

This is presumably due to the extremely low level nature of the drivers, and the wrapper probably expecting just a standard TCP/IP driver. If the wrapper makes any assumptions or optimises anything, the NDS compatibilty will go right out the window.

See somebody else asking this question here:

http://forum.gbadev.org/viewtopic.php?t=5819

its a shame u cant use the usb cards, because im sure i remember that unlike video etc, usb devices werent 'translated' in vmware, and u had to install the PROPER windows drivers... sure, complete windows emulation isnt perfect, but its a damn site nicer than dual boot.

Yeah, I tried using ndiswrapper under Fedora Core 4. It causes a kernel panic on or shortly after load because of several missing functions and an eventual NULL pointer reference, IIRC. A very patient and knowledgeable person might be able to implement the needed functions, but there's still no guarantee it would work properly even with those functions.

Just to get one thing clear... isn't WifiMe actually a program sent to the NDS to make it begin execution of the GBA cart (an alternative to FlashMe and PassMe) ? Is the software that allows execution of any code directly through wi-fi on modified systems actually known as something else?

WiFiMe simulates a DS Download Play server. It can be used in any of these use cases:

If you use WiFiMe to send a stub with an intact header, the receiving system will jump to the program in RAM if and only if the signature is correct. This mode of operation is most commonly used with demos assembled from packet logs captured from demo stations at E3 and other conventions.
If you use WiFiMe to send a signed stub with a header whose ARM7 execution address has been modified to point at the cart, the receiving system will jump to the cart, just as in PassMe.
If you have installed FlashMe on the receiving system, it will act as in case 1 but skip the signature check. This combination of WiFiMe and FlashMe "allows execution of any code directly through wi-fi on modified systems".

_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

What we need to do in order to get Linux wmb is to modify the official open source
rt2500 driver and make it send and accept raw packages. Nothing more, nothing less.

If that is done, FireFly has agreed to port wmb, and possibly releasing the source.

So, the fastest way to get Linux wmb is to sit down and write that driver, and I would
have done that myself if I had not been busy with other projects.
_________________
"no offense, but this is the gayest game ever"

Sausage Boy wrote:

What we need to do in order to get Linux wmb is to modify the official open source
rt2500 driver and make it send and accept raw packages. Nothing more, nothing less.

If that is done, FireFly has agreed to port wmb, and possibly releasing the source.

So, the fastest way to get Linux wmb is to sit down and write that driver, and I would
have done that myself if I had not been busy with other projects.

Someone(from these forums too I beleive) got some progress hacking the linux atheros driver a few months ago: http://members.fortunecity.com/infinityhq/dsdev/dsdev.html , not sure how far along it got.

I downloaded and install the free (GPL) rt2500 drivers from http://rt2x00.serialmonkey.com/wiki/index.php/Main_Page and installed them on my Fedora system. It works normally with my Linksys WMP54G, but I'm not sure where to go from there.

I looked at the echo test app source, but I'm not really clear to me what it is supposed to be doing . I ran it under windows, but I couldn't get any reaction out of it, so I must be misunderstanding what it is meant to do. WMB works fine on this setup, btw.

I don't have a lot of experience with kernel development, but if someone can point me in the right direction I'd love to try to get this working under linux. Thanks.

-Michael

nikarul wrote:

I looked at the echo test app source, but I'm not really clear to me what it is supposed to be doing . I ran it under windows, but I couldn't get any reaction out of it, so I must be misunderstanding what it is meant to do.

from echo example, main.cpp

Code:

void DeviceReadPacketCallback( PDEVICE_INFO lpDeviceInfo, PUCHAR lpBufferData, ULONG dwBufferSize)
{
PUCHAR lpFrameData;
ULONG dwFrameSize;
BOOL bOK;
// visual indicator that we received something
printf( ".");
// skip avs wlan header
if (*(ULONG*)(lpBufferData + 0) == _byteswap_ulong( 0x80211001))
{
   lpFrameData = lpBufferData + _byteswap_ulong( *(ULONG*)(lpBufferData + 4));
   dwFrameSize = dwBufferSize - _byteswap_ulong( *(ULONG*)(lpBufferData + 4));
}
else
{
   lpFrameData = lpBufferData + 0;
   dwFrameSize = dwBufferSize - 0;
}
// write packet
bOK = DeviceWritePacket( lpDeviceInfo, lpFrameData, dwFrameSize);
if (!bOK) printf( "DeviceWritePacket() failed\n");
}

That is what the app is supposed to do, re-transmit each received packet.

OK, that helps. However, I tried putting the DS in several wireless modes (PictoChat, DS Download Play, Mario 64 multiplayer), and that callback never gets called. Should it be responding to the DS signals?

-Michael

nikarul wrote:

OK, that helps. However, I tried putting the DS in several wireless modes (PictoChat, DS Download Play, Mario 64 multiplayer), and that callback never gets called. Should it be responding to the DS signals?

You might want to change the channel to 1, 7 or 13. There isn't going to be much Nintendo DS traffic on channel 11.

see main.cpp, function main

Code:

// set channel
bOK = DeviceSetChannel( &DeviceInfo, 11);
if (!bOK) printf( "DeviceSetChannel() failed\n");

Can PC Wi-Fi cards sold in the United States, where channel 13 has not been cleared for unlicensed use, even go to channel 13?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

tepples wrote:

Can PC Wi-Fi cards sold in the United States, where channel 13 has not been cleared for unlicensed use, even go to channel 13?

No, I don't think so. But then, neither will an American NDS!

What channel will be used instead, and are all these channels used at once, or just one at a time?

EDIT: Oh, and thanks for the clarification on WiFiMe functionality, Tepples

Alright, I fiddled around with the channels (on the windows version) and was able to capture what apparently are pictochat packets on channel 2 (channel 1 seems to be used by a neighbor's AP).

I've got echo compiling on linux, though most of the functionality isn't there yet. I tried using raw sockets with the wlan device, which I didn't really expect to work without any driver modifications but it's a starting point. Raw sockets are supposed to allow you to send and receive packets at the Layer 2 level, and it has support for 802.11* headers, however it may be ignoring packets without a valid IP header, I'm not really clear on that yet. Libpcap might be able to overcome that limitation, unless it's happening at the kernel level, but I haven't really looked at that at all yet.

So I guess the question is (and I'm sorry if this has been explained elsewhere) what changes had to be made to the windows driver to allow the necessary low level communication?

-Michael

nikarul wrote:

So I guess the question is (and I'm sorry if this has been explained elsewhere) what changes had to be made to the windows driver to allow the necessary low level communication?

The RT2560 Windows driver was written from scratch, so there wasn't anything to make changes to.

I guess what I am looking for is what exactly does the ReadFile() call in ThreadReadFileProc() expect to be returned? Every 802.11* packet received by the device, with the the header included? I just want to avoid making the echo program seem to work but then not work as expected for WMB, because the data returned is wrong.

-Michael

nikarul wrote:

I guess what I am looking for is what exactly does the ReadFile() call in ThreadReadFileProc() expect to be returned? Every 802.11* packet received by the device, with the the header included? I just want to avoid making the echo program seem to work but then not work as expected for WMB, because the data returned is wrong.

The wmb app zip file contains an example.cap file that should tell you what ReadFile() returns. It's basically a WLAN AVS header followed by a 802.11 frame with FCS at the end.

http://www.cr0.net:8040/code/network/aircrack-2.2-beta12.tgz

hostap-driver-0.3.9.patch
madwifi-cvs-20050707.patch
prism54-svn-20050724.patch
rt2500-cvs-20050724.patch
rtl8180-0.21.patch
wlanng-0.2.1-pre26.patch

From readme.txt

Quote:

How do I patch the driver for injection with aireplay ?

As of now, aireplay only supports injection on Prism2, PrismGT (FullMAC), Atheros, RTL8180 and Ralink 2500. Injection on other chipsets (including, but not limited to, HermesI, Aironet and Centrino) is not supported. Injection on Prism2 and Atheros is still pretty much experimental; if your card appears to hang (no packets captured or injected), disable the interface, reload the drivers and re-insert the card. Also consider updating the firmware (if Prism2). All drivers must be patched so as to support injection in Monitor mode. You will need the kernel headers that match your current running kernel. Alternatively, you may download the linux source and compile a custom kernel.

You should test these patches ASAP and if they work, provide me with a Linux version of the device routines in my "echo" example, if you ever want to see wmb.exe running on Linux that is.

I have to say that I get first success in using linux for multiboot. I was able to fake a pictochat channel using a combined version od aireplay and what you find at http://members.fortunecity.com/infinityhq/dsdev/dsdev.html.

I used a prism2 chipset, but any chipset that can send raw packets should work. I try to send some game beacons now...

Managed to make the DS see a game download... I hope this works out well.

Firefly, one question: Is there anything that can be seen on the DS when running your echo app? I think I can send and receive raw packets now, but I don't quite get the source of your app.

davine wrote:

Firefly, one question: Is there anything that can be seen on the DS when running your echo app? I think I can send and receive raw packets now, but I don't quite get the source of your app.

The echo example does what its name says, re-transmit each received packet. It has no purpose other than showing people how to use my driver. You can verify the correct workings of the echo example by using a DS to broadcast a WMB game and capture the echoed output with a 2nd card.

Well, I may have had a breakthrough. After looking at aireplay.c from aircrack, I used the same methods in echo to put my wireless card in raw packet mode and echo seems to be working.

I say seems, because I don't have the equipment to make sure that it is actually echoing the packets the way the windows echo does, but I did capture some of the packets it was reading to a log file and it looks (to my eye) similar to the packets I captured with the windows version. Very promising.

I've put a tarball up at http://digitalbytes.net:81/nds/. It includes source and linux binary. I haven't including all the extra checks for the various cards that aircrack supports, but theoretically, we should be able to support any card aircrack supports. I did patch my rt2500 driver with their patch, but I'm not sure if it's required for what echo does. If you are going to try it, I recommend getting aireplay working first and then try echo.

There are a few functions in device_rt2560_linux.cpp that I haven't implemented yet, mainly because I'm lazy, but all the critical ones (for echo) are there. The rest are not difficult to implement, so if they're required for WMB let me know.

-Michael

*EDIT* Forgot to mention, currently the code is hardcoded to use wlan0 for the wireless interface in a few places. The correct way to handle this would be to specify the device on the command line, but I haven't added that yet.

That's great, Nikarul!

I could not get the wmb to go any further right now. I still can not do an association. However, your code seems to work perfectly on my prism2 with the hostap driver. I checked the packets and they are exactly the same.

Keep up the good work!

Update:
I have been able to send the association packet I could not send before. I have not tried it yet in a connection attempt, but it's very promising!

Davine:

That's great news. Thanks for testing.

Firefly:

What's the next step? Is enough implemented for WMB to work?

-Michael

Okay, i have been able to connect to the DS and it is waiting for data now. The only thing I need now for Linux wmb is how exactly I have to send the data. I'm extremely tired now, but I will look into it tomorrow. Any help from you, Firefly?

Thanks Firefly and Nikarul!

Wonderful work!

How about dumping Polarium/Other game sending a demo and compare it to the other dump?
Could be useful...

Seems like wmb on linux isn't too far away now. :D
_________________
"no offense, but this is the gayest game ever"

Sausage Boy wrote:

How about dumping Polarium/Other game sending a demo and compare it to the other dump?
Could be useful...

That's what I'm tryinf right now. It's quite complicated, though, and I still don't understand much. If someone knows anything about it, or could provide me with a dump of DS that downloads a game from the windows wmb, I would be very grateful!

I'll give you dumps when I come home if you upload a program to do it somewhere.
I've written one based on Firefly's echo application, but I don't trust it at all.
_________________
"no offense, but this is the gayest game ever"

You can just use ethereal or airodump

I wonder if any of this is applicable to building a WMB capable linksys firmware, cause there'd be huge demand for that ;)

Good question. If aircrack can be made to run on a Linksys router, then I'd say there's a good chance that it would work. Maybe I'll play with getting it to work on my WRT54G this weekend.

-Michael

nikarul wrote:

What's the next step? Is enough implemented for WMB to work?

I just had a look at your code, nice job.

- The currently unimplemented functions DeviceGetMacAddress and DeviceGetChannel are being used in my WMB app.
- CreateMutex, WaitForSingleObject and CloseHandle are also needed, for serializing the access to the wifi device and .cap output file.

Thanks. I'll work on getting those going this weekend.

-Michael

Code:

BOOL DeviceGetMacAddress( PDEVICE_INFO lpDeviceInfo, PUCHAR lpMacAddress) {

ifreq ifr;

memset(&ifr, 0, sizeof(ifreq));

strcpy(ifr.ifr_name, "eth0"); //TODO get this from cmdline

   if (ioctl(lpDeviceInfo->Handle, SIOCGIFHWADDR, &ifr) == -1) {

   printf("Failed to get mac address.\n");

   return false;

}

memcpy(lpMacAddress,ifr.ifr_addr.sa_data,6);

return true;

}

[/code]

Alright, I just posted an updated tarball with the missing functions (thanks Davine for the DeviceGetMacAddress code).

I also implemented reading the wireless interface from the command line, rather than hardcoding the interface name.

A few caveats on the thread functions:

- CreateMutex ignores all of its arguments. It just creates a pthread mutex and returns a pointer to it.

- WaitForSingleObject assumes you're passing a handle created by CreateMutex.

- CloseHandle also assumes you're passing a handle created by CreateMutex.

- I haven't tested any of these three functions beyond compiling them. They are pretty straightforward and should work as advertised, but beware of bugs.

-Michael

*EDIT* Just fixed a bug with the MAC address code that davine pointed out. Forgot to convert the hardcoded eth0 to the cmdline iface. Just re-posted the tarball as rt2560_echo_linux_20050820-1.tar.bz2 and updated the above link.

I am going to try to compile your code on a fresh Gentoo 2005.1 installation as soon as I can fix a problem that prevents me from installing KDE using the package cd.

I am also going to need a function to set the tx rate to 2 Mbps. This was not necessary for the Windows version because my driver only supports one tx rate.

BOOL DeviceSetTxRate( PDEVICE_INFO lpDeviceInfo, FLOAT Rate);

EDIT: I managed to install KDE, now I need to figure out how to get internet connectivity so I can download your code.

EDIT: Internet works. I am editing this post from my freshly installed Gentoo 2005.1 system. Now I need to install a driver for my RTL8180 wifi card.

I patched and installed the driver for my RTL8180 card but there seems to be a problem trying to set the channel:

Code:

amd1200 source # ./echo wlan0

RT2560 Driver - Test Application "Echo" - Version 1.1

(c) 2005 Tim Schuerewegen

DeviceSetChannel failed: : Operation not permitted
DeviceSetChannel() failed
Press ENTER to abort
.
amd1200 source #

If I remove the setuid(..) line from your code then the error disappears.

Todo:
- function to set the tx rate
- fix the error above

Once that is complete and tested, I will try to port my wmb app.

Just remove the getuid(setuid()) call altogether. I was hoping root privileges could be dropped early on but you need them pretty much until the end of the program.

Setting the TX rate is a more serious problem. Linux has an ioctl() for doing that, but the rt2500 driver does not implement it. It seems to set up power levels in the init code and just run with that. It looks like it may be setting it to some sort of auto-detect setting. Is there any chance it might go to the correct level when talking to the DS? Otherwise, we'll probably have to find some way to hard code the correct value to start with.

-Michael

nikarul wrote:

Just remove the getuid(setuid()) call altogether. I was hoping root privileges could be dropped early on but you need them pretty much until the end of the program.

The setuid(..) call actually has no effect on the DeviceSetChannel error, I was wrong. It was "iwconfig wlan0 mode monitor" which made this error go away. It looks like you can set monitor mode using the SIOCSIWMODE ioctl and IW_MODE_MONITOR.

Quote:

Setting the TX rate is a more serious problem. Linux has an ioctl() for doing that, but the rt2500 driver does not implement it. It seems to set up power levels in the init code and just run with that. It looks like it may be setting it to some sort of auto-detect setting. Is there any chance it might go to the correct level when talking to the DS? Otherwise, we'll probably have to find some way to hard code the correct value to start with.

I am using a RTL8180 card, and the driver implements SIOCSIWRATE.

I found that the easiest and most reliable way to ensure that my card was using the right channel in monitor mode was to use the airmon.sh script that comes with aireplay. Just type for example

Code:

./airmon.sh start eth0 1

to start monitoring on channel 1 on device eth0.

[FireFly] wrote:

nikarul wrote:

Just remove the getuid(setuid()) call altogether. I was hoping root privileges could be dropped early on but you need them pretty much until the end of the program.

The setuid(..) call actually has no effect on the DeviceSetChannel error, I was wrong. It was "iwconfig wlan0 mode monitor" which made this error go away. It looks like you can set monitor mode using the SIOCSIWMODE ioctl and IW_MODE_MONITOR.

Quote:

Setting the TX rate is a more serious problem. Linux has an ioctl() for doing that, but the rt2500 driver does not implement it. It seems to set up power levels in the init code and just run with that. It looks like it may be setting it to some sort of auto-detect setting. Is there any chance it might go to the correct level when talking to the DS? Otherwise, we'll probably have to find some way to hard code the correct value to start with.

I am using a RTL8180 card, and the driver implements SIOCSIWRATE.

Ah, the setuid call would have no effect if you were running as root, that makes sense. Still, it should probably be removed if anyone wants to run it setuid root.

My driver does support SIOCSIWRATE. I was looking at SIOCSIWTXPOW for some reason. I guess I saw the TX and stopped there. Anyways, the only issue is that ioctl takes a LONG as it's value instead of a FLOAT. Does it actually need to be a float? It also appears to take the value in bits. Do I need to do any conversion to the Rate value you give me?

-Michael

nikarul wrote:

Anyways, the only issue is that ioctl takes a LONG as it's value instead of a FLOAT. Does it actually need to be a float? It also appears to take the value in bits. Do I need to do any conversion to the Rate value you give me?

That FLOAT value is the rate in Mbps, so you should multiply it by 1000000 before passing it to that IOCTL.

Alright, new tarball up with the latest changes. I removed the setuid() call, added DeviceSetTxRate(), and I also removed dependencies on libiw, which was causing binary compatibility issues for some people.

As before, I haven't tested DeviceSetTxRate() beyond compiling it, but the code is pretty straightforward. Let me know if you have any problems.

-Michael

I have made the necessary changes to the wmb source code so that it compiles on my Linux box, but it does not work yet. Will have to check the wifi output tomorrow to see what's going on.

This is just to let you people know that I compiled the echo application in linux, using a RTL8180 chipset, and managed to see the pictochat traffic. If any help is needed to make a driver for 8180, under windows or linux, just let me know. I used the open source RTL8180 driver from sourceforge.

Wow... okay, you guys are my gods. I WISH I had your level of skill. I came here today to find out if anyone had ported WMB to Linux, and I was pleasantly shocked with the level of progress you two had made.

nikarul, where do I send donations? :)

@[Firefly]: Any progress getting wmb to work on linux yet? Let me know if you need any help.

-Michael

I've been working getting the DS to communicate with my PC as well.

So far, I can successfully:

-send beacons
-recv beacons
-auth and associate with the DS
(consistently, instead of sporadically as before)
-start sending data packets

But I get deauthed when I start sending data packets, and I never get a data ack back from the DS. Which is pretty much where everyone seems to be stuck at when trying this out.

I am wondering if the card (prism fullmac) firmware is modifying the frames when sending some packets. Maybe time for another card to monitor what I am sending out.

Oh well, at least its fun and keeping me busy these days.

Ooh, and I also wrote a custom create beacon utility that accepts a custom icon, game name/desc etc as I was getting bored of just seeing bomberman and mario beacons.

But if anyone here has gotten data acks back from the DS, I would be really interested in knowing what I am missing.

Well, good luck to all.

Update - I changed network cards to a rt2500, and I get acks back with no problems. I am wondering what setting I may have had wrong on the prism. The iwpriv list was huge, there may have been something I missed. Oh well, off to play some more.

-Cloak

Last edited by cloak on Tue Dec 06, 2005 11:46 pm; edited 1 time in total

Hi all ! this is my first post here =)

I follow this forum since a had my japanese DS ... and i have just receceived a MSI PC54G2 (so with the Ralink RT2500 chipset) so i try to get my card working for the DS under Linux ...

I took the modified driver (for aircrack) and compile the dsmultiboot.c from Davine ... the sending procedure didn't work properly and i figure out that it was the send function who don't work ... just replace it by a write function and it's good !!

But now i've got the same problem =( i don't receive the ack from the DS when i want to start the DL .
Is the acknowledge sent on another channel ???

And keep up the good work !! what you all have already done is very great !!!

EDIT : Oki found the problem !!! just did on the wrong channel in the begining ....

I'm having a small problem following this thread. What exactly is the process to getting it to work under linux?

install aircrack but patch it first?
then what program do we use to send nds files?

Or is this a fishout of water still?

WMB doesn't work under linux yet. Several people here are trying different methods but no luck yet.

-Michael

Aha! Got linux WMB to work. ^_^

Source available, as well as the first test binary. Tested on a couple of rt2500 PCI cards so far.

http://wiki.tbble.net/NintendoDS/Libnifi

That's awesome TBBle! I hope you continue to make progress with this!

Does anyone know why Firefly stopped working on his wmb for linux and put up the closed sign on his site?

Since he hasn't released his source code yet, I doubt he ever will, but has anyone asked him if he is willing?

It'd be nice if someone would upgrade FF's driver to use Nintendo's official adapter :)

You mean this?
...
+ { USB_DEVICE(0x0411, 0x008b)}, /* Nintendo */ \
...

http://cvs.sourceforge.net/viewcvs.py/rt2400/source/rt2570/Module/rt2570sw.h?r1=1.27&r2=1.28

Hopefully the linux rt2570 driver works out of the box with my code... Anyone want to test?

TBBle wrote:

Aha! Got linux WMB to work. ^_^

Source available, as well as the first test binary. Tested on a couple of rt2500 PCI cards so far.

http://wiki.tbble.net/NintendoDS/Libnifi

Great work TBBle ! but i've tested your code and i've got a "no response seen to second packet"

It's the first 'Data' packet that must be send to the DS...

I've got the same problem on my testing application

So it seems that the authentification and association are good...
Taking a full successed capture file from Darkain site (the only one i've found) doesn't help me much because the packet seems the same =(

Is anyone have another capture that works, it would be great =)

TheKilled. wrote:

TBBle wrote:

Aha! Got linux WMB to work. ^_^

Source available, as well as the first test binary. Tested on a couple of rt2500 PCI cards so far.

http://wiki.tbble.net/NintendoDS/Libnifi

Great work TBBle ! but i've tested your code and i've got a "no response seen to second packet"

Grab the latest version, it's muchly improved. The main improvement is it no longer grinds your machine to a halt trying to scroll your screen 100 lines per second. Oh, and it can launch things other than Polarium from devices other than wlan1.

However, I'm not sure that's your problem there... A pcap of the session might help, since I don't think I'm checking for deauth that early in the piece. I don't recommend pcapping on the same machine, it also caused delays that meant the send failed more often for me.

I sometimes found redirecting output to a file would help the successrate, but again I usually didn't have any problems this early.

One thing, are you on linux 2.4 or 2.6? It might be a timer resolution issue... I prolly should timestamp more things. I'll do that next time I code on this.

Remember, the NDS is _very_ quick on the "give up!" button for WMB. It obviously works better when WMBing from another DS which is doing nothing but WMBing, so doesn't have unexpected 100ms delays. ^_^ I got nanosleep using 10ms basically by trial-and-error. I expect pthreads reduces the relationship between that number and clocktime.

cloak wrote:

But I get deauthed when I start sending data packets,

This took me ages to work out. Don't stop the beaconing once you start dataing, or the DS will drop the link after four seconds. ^_^

cloak wrote:

and I never get a data ack back from the DS.

I am wondering if the card (prism fullmac) firmware is modifying the frames when sending some packets.

You have to be talking to the DS at 2Mb/s, and I found that the prism54 in monitor mode would only talk 1Mb/s (I instrumented the driver, and it was _sending_ the 2Mb/s command to the hardware, but another machine confirmed the traffic coming out was 1Mb/s)

I did the same thing you did, and switched to an rt2500. ^_^

TBBle wrote:

One thing, are you on linux 2.4 or 2.6? It might be a timer resolution issue... I prolly should timestamp more things. I'll do that next time I code on this.

Remember, the NDS is _very_ quick on the "give up!" button for WMB. It obviously works better when WMBing from another DS which is doing nothing but WMBing, so doesn't have unexpected 100ms delays. ^_^ I got nanosleep using 10ms basically by trial-and-error. I expect pthreads reduces the relationship between that number and clocktime.

Thanks a lot for the quick answer =)
I've got a 2.6.8 kernel and rt2500-cvs-20051112 version of the lan driver (In fact it's probably not the latest .. i'll go check on it ...)

And i also stopped the beaconing once the DS starts to communicate (I've just tried with and i'm not deauthed as soon as before but still no data ACKs ... )

I just pcaping sometimes (i saw the differences in logging speed) it's the same in the use of printf

I'll post a pcap file as soon as i can =)
EDIT : the cap file

Last edited by TheKilled. on Tue Dec 13, 2005 10:50 pm; edited 2 times in total

TBBle wrote:

You have to be talking to the DS at 2Mb/s, and I found that the prism54 in monitor mode would only talk 1Mb/s (I instrumented the driver, and it was _sending_ the 2Mb/s command to the hardware, but another machine confirmed the traffic coming out was 1Mb/s)

I did the same thing you did, and switched to an rt2500. ^_^

Thanks for the hints. I never did have a 2nd machine to test with.

I will try out your code (since it seems its greatly progressed since I downloaded it some time ago) and let you know if if works on an unpatched ds.

I guess linux wmb is going to be tricky business with everyone wanting to wmb with cards other then the rt2500.

And thanks for your help. Your site was a good reference when I first started playing around. (that and g.linscott)

Great work TBBle! I've got the demos working on my CentOS box with a linksys wmp54g. I had to upgrade to the latest wireless-tools before it would build though. If anyone is interested, I'll post the RPM for it.

I can get the official demos working fine, but when I try to run an NDS file that I built, it gets the following error:

[root@tourian libnifi]# ./beacontest dseditor.nds ra0
Data check:
RSA: 242 (0xf2) bytes
HEAD: 352 (0x160) bytes
Mapping arm9 len 17364, offset 0x0200, pagesize is 0x1000
Failed to map arm9 bin: Invalid argument

I looked at the code, a call to mmap() is failing, though I'm not sure why. Should homebrew binaries work with beacontest?

-Michael

nikarul wrote:

[root@tourian libnifi]# ./beacontest dseditor.nds ra0
Data check:
RSA: 242 (0xf2) bytes
HEAD: 352 (0x160) bytes
Mapping arm9 len 17364, offset 0x0200, pagesize is 0x1000
Failed to map arm9 bin: Invalid argument

I looked at the code, a call to mmap() is failing, though I'm not sure why.

A slight piece of dumbassedness on my part. I'm gonna rewrite that part so it mmaps the entire ROM (I doubt anyone's interested in WMBing seperate arm7, arm9 and hdr bins...)

The problem is the base address of the ARM9 is supposed to be 4k aligned according to http://www.bottledlight.com/ds/index.php/FileFormats/NDSFormat and so's the mmap base call ("pagesize" above), so I didn't bother futzing with the base address as you'll see I did with arm7 a couple of lines below. (I'd suggest this is a bug in the code that assembled the homebrew, but if the NDS'll run it, then the spec's out.)

If you want to code a fix, port the arm7base and arm7offset stuff from just below to work for arm9. Otherwise, hang about, this is the first thing to fix tonight. ^_^ (The current code is a semi-holdover from the previous revision's static arrays. And I've always wanted to use mmap for something, and I got a little function-happy. -_-)

(Edit: Fixed and a new version uploaded. This also fixed the E3 demos which failed last night... Trauma Center is dangerously fun. ^_^)

Hi there!

I made a tutorial for the DS Wiki that explains how to set up TBBle's WMB for Linux. So, if anyone is having any trouble setting it up, you might want to check it out.

TBBle:
It's soooo great that you did this! I have waited for this since I bought my DS and now it's here. Thank you very much!
It would be cool if you could check the tutorials for errors and omissions.

Bye,
Tob

0xtob wrote:

It would be cool if you could check the tutorials for errors and omissions.

Nice, thanks. I've linked it from my site, and made some changes to it. ^_^

I'll have a look at that Sushi the Cat rom tonight, you really shouldn't be getting dire predictions of the end... ^_^

Tried the new version, it works great. Thanks!

-Michael

Ok !!!!

Thanks TBBle for your program !! It's working verywell !!!

Since the begining it was the driver who didn't work correctly !

Now even my homemade application works

So sorry for the previous posts i'll better check everything before posting now !!!

Oxtob Your tutorial is good i just tried it and it's working well !!
Errr just a question ... i add a modprobe rt2500 in order to get the module loaded you didn't mention it ...(perhaps depmod do it but i think it's just the module list updater/maker)

And thanks a lot everyone for your good work !!!

TheKilled. wrote:

i add a modprobe rt2500 in order to get the module loaded you didn't mention it ...(perhaps depmod do it but i think it's just the module list updater/maker)

I've changed that now. Good catch. ^_^ (I suspect the original author was using a laptop, so after depmod he inserted the PCMCIA device and hotplug/udev loaded the module automatically.)

TBBle wrote:

I'll have a look at that Sushi the Cat rom tonight, you really shouldn't be getting dire predictions of the end... ^_^

Cute game, but in this case it's not my fault. ^_^

Code:

tbble@mutsumi:~/wi/libnifi$ ./dumphdr.pl ../SushiDS.nds
../SushiDS.nds: 616009 bytes.
Game Title: .�
Game Code: ####
Maker Code:
Unit Code: 0x00
Device Code: 0x00
Card Size: 0x00
Card Info: Fill in!
Flags: 0x04
ARM9 SRC: 0x00000200
ARM9 EXE: 0x02000000
ARM9 CPY: 0x02000000
ARM9 LEN: 0x00092dc4
ARM7 SRC: 0x00093000
ARM7 EXE: 0x03800000
ARM7 CPY: 0x03800000
ARM7 LEN: 0x00002c28
Filename Table SRC: 0x00096640
Filename Table LEN: 0x00000009
FAT SRC: 0x0009664c
FAT LEN: 0x00000000
ARM9 Overlay SRC: 0x00000000
ARM9 Overlay LEN: 0x00000000
ARM7 Overlay SRC: 0x00000000
ARM7 Overlay LEN: 0x00000000
Unknown 2a: 0x00586000
Unknown 2b: 0x001808f8
Icon/Titles SRC: 0x00095e00
Secure CRC16: 0x0000
ROM timeout: 0x0000
ARM9 something: 0x00000000
ARM7 something: 0x00000000
Unknown 3c: Fill in!
ROM size: 0x00000000 <===== Provably incorrect... ^_^
Header size: 0x00000200
Unknown 5: Fill in!
GBA Logo: GBA Logo
Logo CRC16: 0x44c6
Header CRC16: 0x6483

It doesn't work for me correctly.
I'm using Ubuntu Breezy Badge (5.10) so I didn't install the driver manually. After following the instructions from the wiki I am here:

"....
wlan initited"

But then nothing happens, it doesn't appear on the DS and I don't get anything else than that. Tried it with Sushi DS and Polarium demo.

BTW: When starting rt2500.sh I got following error message: "Invalid command : rfmontx"
_________________
The future of gaming is mobile Handheld Gaming.

Ilomoga wrote:

BTW: When starting rt2500.sh I got following error message: "Invalid command : rfmontx"

You're not using the right version of the driver. Ubuntu Breezy is certainly not shipping the neccessary version, it predates the tested version by two months...

If you get it _working_ with another version, that'd be good to know. But for the moment, assume it'll only work with the exact tested version given.

Ah, ok, then I'll try the other driver from the wiki.
_________________
The future of gaming is mobile Handheld Gaming.

New version of the binaries uploaded. This is mainly a prettifying release. ^_^

Hi,

I always run rt2500.sh without parameters and wonder why it doesn't work or forget to modprobe the driver etc, so I added some checks in the script:

Code:

tmp=`lsmod | grep rt2500 | wc -l`
if [ $tmp -eq 0 ]; then
echo "You have to modprobe your driver first!"
exit 1
fi

if [ $# -eq 2 ]; then
echo "configure ..."
iwconfig $1 mode monitor
ip link set $1 up
iwconfig $1 rate 2M fixed
iwpriv $1 set WirelessMode=1
iwpriv $1 set TxRate=2
iwpriv $1 set TxPreamble=1
iwpriv $1 rfmontx 1
ifconfig $1 promisc
iwconfig $1 channel $2
exit 0
fi

echo "usage: rt2500.sh <interface> <channel>"
exit 1

You can add it to your page TBBle, if you like.

juhees

Thanks, I will.

For completeness (ie in case someone decides to compile the module into their kernel, call it something different, or otherwise make lsmod a poor check) it prolly should check sysfs to see if the driver is available, rather than what modules are loaded...

Maybe not...

Anyway, the actual plan is to have libnifi do the setup rather than calling iwconfig etc, but the wireless extensions code I borrowed is currently unable to _read_ the channel back correctly. (At my place, values vary between -2, -1 and 1 for channel 13...) This is low priority mainly because it's not on the critical path to WMB files.

It could quite easily parse through the loaded ethernet drivers, and select those for which it has code to support the driver, which would simultaenously buy me a place to hook in card-specific (ie iwpriv) calls.

I also might break out some of the more interesting WMB data transformations into libnifi as utility functions... Repeatable stuff like "fetch next beacon from data" and the CRC16 code I found, with a wrapper of some kind.

I'm currently focussing more on extending capread to be able to grab mutiple .nds files out of a single pcap (eg. if someone captured a day's worth of packets at a large video game show...), or alternatively making whosthere work so it can just directly download the .nds from a server. And once I work out which part of the flow identifies a given NDS/Game, hopefully extend beacontest to beacon and serve multiple games at once. ^_^

Hi and great work TBBle,

I'm trying to make your libnifi work with a RTL8180 chipset card, with the aircrack driver patch for packet injection.

Everything goes well until I get "no response seen to second packet". (I have "association accepted" before)
Packets seems to be sent and received if I trust airodump.
I tried some debugging stuff but nothing very conclusive (no packet seems to be received indeed after the association has been made).

Would you have any tips, first to know if my driver is working well, then (if it's the case) how I could find out what's wrong within libnifi ?

Thanks for your help !

Yet another script:

Code:

#!/bin/bash

WMB=/path/to/your/beacontest
DEV=ra0

# we have to be root
if [ `whoami` != "root" ]; then
echo "you have to be root"
exit 1;
fi

# there is no parameter, look if there is only one *.nds file in this dir
# if yes, upload it
if [ $# -eq 0 ]; then
file=`ls -1 *.nds 2> /dev/null`
tmp=`ls -1 *.nds 2> /dev/null | wc -l`
if [ $tmp -eq 1 ]; then
$WMB $file $DEV
exit $?
fi
echo "usage: wmb <nds-file>"
exit 1;
fi

# if there is one parameter, we try to upload this file
if [ $# -eq 1 ]; then
$WMB $1 $DEV
exit $?
fi

echo "usage: wmb <nds-file>"
exit 1;

call it "wmb" and place it in your ~/bin dir. chmod 755 ~/bin/wmb

What it does:
* saves some time (you don't have to type your interface every time, it's shorter that "beacontest")
* you get warned, if you are not root
* if there is just one *.nds file in that dir, it gets uploaded (you don't need a parameter at all ;-)
* you can use it in scriptes/Makefiles, beacontest won't be called beacontest forever i quess

You can distribute it with beacontest if you like.

juhees

Haiken wrote:

I'm trying to make your libnifi work with a RTL8180 chipset card, with the aircrack driver patch for packet injection.

Everything goes well until I get "no response seen to second packet". (I have "association accepted" before)
Packets seems to be sent and received if I trust airodump.
I tried some debugging stuff but nothing very conclusive (no packet seems to be received indeed after the association has been made).

Does whatever card you're using with airodump give you the AVS (prism2) headers? If so, it should report the bitrate being transmitted at. It _must_ be 2Mbps. The DS advertises that it'll take 1 and 2Mbps, but it won't actually accept data at 1Mbps, as far as I could test. This is what canned the prism54 fullmac, softmac _and_ at76c503 devices I tried...

(I've not used airodump, but I suggest you try ethereal instead.)

Just to confirm, no packets are received from the DS after association, or no packets at all?

Thanks for your support !

My card is a Dlink DWL-510

Here is what I get with airodump :

Code:

BSSID CH MB ENC PWR Packets LAN IP / # IVs ESSID

00:09:BF:91:EC:56 13 2 WEP -1 94 0 ..@.V?......

I don't know airodump very well but I guess the MB column means I transfer at 2Mbits. I can't use ethereal because I don't have a screen (nor GTK) on my linux computer ;)

Here is the output with some printf uncommented and modified like this

Code:

   if (!memcmp(wh->i_addr1, wlinfo->localmac, IEEE80211_ADDR_LEN))
      printf("Precheck, %d bytes...", bytes);
   if (!memcmp(wh->i_addr1, wlinfo->localmac, IEEE80211_ADDR_LEN))
      printf("Packet, Type %02x, subtype %02x, %d bytes\n", frametype, subtype, bytes);

so that "Precheck..." lines indicate packets coming from the DS

Code:

Read 188 bytes, arptype 801.
Read 188 bytes, arptype 801.
Read 188 bytes, arptype 801.
Read 30 bytes, arptype 801.
Precheck, 30 bytes...Packet, Type 00, subtype b0, 30 bytes
Got an AUTH1 as we expected
Sent AUTH2, 30 bytes
Read 10 bytes, arptype 801.
Read 30 bytes, arptype 801.
Read 30 bytes, arptype 801.
Precheck, 30 bytes...Packet, Type 00, subtype b0, 30 bytes
Got an AUTH1 as we expected
Sent AUTH2, 30 bytes
Read 10 bytes, arptype 801.
Read 30 bytes, arptype 801.
Read 30 bytes, arptype 801.
Precheck, 30 bytes...Packet, Type 00, subtype b0, 30 bytes
Got an AUTH1 as we expected
Sent AUTH2, 30 bytes
Read 10 bytes, arptype 801.
Read 30 bytes, arptype 801.
Read 10 bytes, arptype 801.
Precheck, 10 bytes...Packet, Type 04, subtype d0, 10 bytes
Read 10 bytes, arptype 801.
Precheck, 10 bytes...Packet, Type 04, subtype d0, 10 bytes
Read 66 bytes, arptype 801.
Precheck, 66 bytes...Packet, Type 00, subtype 00, 66 bytes
Got an ASSOC REQ like we'd hope
Association accepted
Sent ASSOC REPLY, 34 bytes
Read 10 bytes, arptype 801.
Read 34 bytes, arptype 801.
Read 66 bytes, arptype 801.
Precheck, 66 bytes...Packet, Type 00, subtype 00, 66 bytes
Got an ASSOC REQ like we'd hope
Association accepted
Sent ASSOC REPLY, 34 bytes
Read 10 bytes, arptype 801.
Read 34 bytes, arptype 801.
Read 38 bytes, arptype 801.
Read 10 bytes, arptype 801.
Precheck, 10 bytes...Packet, Type 04, subtype d0, 10 bytes
Read 10 bytes, arptype 801.
Precheck, 10 bytes...Packet, Type 04, subtype d0, 10 bytes
Read 10 bytes, arptype 801.
Precheck, 10 bytes...Packet, Type 04, subtype d0, 10 bytes
Read 38 bytes, arptype 801.
Read 38 bytes, arptype 801.
Read 38 bytes, arptype 801.
Read 38 bytes, arptype 801.
Read 38 bytes, arptype 801.
Read 38 bytes, arptype 801.
Read 38 bytes, arptype 801.
Read 38 bytes, arptype 801.
Read 38 bytes, arptype 801.
Read 38 bytes, arptype 801.
Read 38 bytes, arptype 801.
Read 38 bytes, arptype 801.
Read 38 bytes, arptype 801.
Read 38 bytes, arptype 801.
Read 38 bytes, arptype 801.
Read 38 bytes, arptype 801.
Read 38 bytes, arptype 801.
Read 188 bytes, arptype 801.
Read 38 bytes, arptype 801.
Read 38 bytes, arptype 801.
Read 38 bytes, arptype 801.
Read 38 bytes, arptype 801.
Read 38 bytes, arptype 801.
Read 38 bytes, arptype 801.
Read 38 bytes, arptype 801.
Read 38 bytes, arptype 801.
Read 38 bytes, arptype 801.
Read 38 bytes, arptype 801.
Read 38 bytes, arptype 801.
Read 38 bytes, arptype 801.
Read 38 bytes, arptype 801.
Read 38 bytes, arptype 801.
Read 38 bytes, arptype 801.
Read 38 bytes, arptype 801.
Read 38 bytes, arptype 801.
Read 38 bytes, arptype 801.
Read 188 bytes, arptype 801.
Read 38 bytes, arptype 801.
Read 38 bytes, arptype 801.
Read 38 bytes, arptype 801.
Read 38 bytes, arptype 801.
Read 38 bytes, arptype 801.
Read 38 bytes, arptype 801.
Read 38 bytes, arptype 801.
Read 38 bytes, arptype 801.
Read 38 bytes, arptype 801.
Read 38 bytes, arptype 801.
Read 38 bytes, arptype 801.
Read 38 bytes, arptype 801.
Read 38 bytes, arptype 801.
Read 38 bytes, arptype 801.
No response seen to second packet

So to answer your question, it seems I am well receiving ACK packets from the DS after association, but nothing else.

What I can't explain though is when I count packets reported by beacontest, I have more than indicated by airodump...

Haiken wrote:

I can't use ethereal because I don't have a screen (nor GTK) on my linux computer ;)

Use tcpdump then (with -w output.pcap) and open that up in Ethereal on whatever your desktop OS is. Plus that means you can post the .pcap file if we get really stuck. ^_^

Quote:

Code:

Precheck, 10 bytes...Packet, Type 04, subtype d0, 10 bytes

So to answer your question, it seems I am well receiving ACK packets from the DS after association, but nothing else.

That's whacky. You're also not seeing _many_ acks. (The rt2500 eats all the acks, so I dunno if you should be seeing them or not, but I'd figure one per packet sent)

Quote:

What I can't explain though is when I count packets reported by beacontest, I have more than indicated by airodump...

Maybe aerodump ignores certain packets (acks, for example?) because they're not interesting in the pursuit of WEP cracking...

Hmm. Are you using one NIC or two here? If you're capturing on the same card that's running beacontest, you're not getting any air-speed info, since you're not getting AVR headers (arp type 801 is raw 802.11, AVR is arp type 802, and includes info on the 802.11 carrier)

Which 8180 driver are you using? Try

Code:

iwpriv wlanwhatever prismhdr 1

(this is from the rtl8180-sa2400 driver, if you're using a different driver, have a look at iwpriv and see if there's anything tasty there)

Hi,

You guessed well I'm using the rtl8180-sa2400 driver, and I am capturing from the same card.

I have another rtl8180 based card but on a windows laptop and I have been unable to capture anything with it (can't set the speed to 2Mbps, it keeps going back to 11Mbps)

With iwpriv wlan0 prismhdr 1, here is the kind of stuff I get :

Quote:

...
Read 188 bytes, arptype 802.
Read 116 bytes, arptype 802.
Read 116 bytes, arptype 802.
Read 188 bytes, arptype 802.
Read 116 bytes, arptype 802.
Read 96 bytes, arptype 802.
Read 96 bytes, arptype 802.
Read 116 bytes, arptype 802.
Read 188 bytes, arptype 802.
Read 96 bytes, arptype 802.
Read 96 bytes, arptype 802.
Read 116 bytes, arptype 802.
Read 96 bytes, arptype 802.
Read 74 bytes, arptype 802.
Read 74 bytes, arptype 802.
Read 96 bytes, arptype 802.
Read 74 bytes, arptype 802.
Read 96 bytes, arptype 802.
Read 74 bytes, arptype 802.
Read 74 bytes, arptype 802.
Read 96 bytes, arptype 802.
Read 74 bytes, arptype 802.
Read 96 bytes, arptype 802.
...

I think someone else is playing with a DS in the neighbourhood because the "Read 116 bytes, arptype 802." packets were not here last night, and I see them even with eveything turned off ;o) (and without prismhdr too)
Anyway, the DS fails quickier, and beacontest reports no association established (actually not packets from the DS at all)

I'll try to make my other card capture nice pcaps tomorrow (and hope for no foreign packets floating around ;)

Haiken wrote:

I have another rtl8180 based card but on a windows laptop and I have been unable to capture anything with it (can't set the speed to 2Mbps, it keeps going back to 11Mbps)

The capturer doesn't need to be at 2Mbps, luckily. I use my prism54 to pcap, because it does a really good job of pcap, but refuses to let me set the transmit speed in monitor mode.

Quote:

With iwpriv wlan0 prismhdr 1, here is the kind of stuff I get :

Quote:

...
Read 188 bytes, arptype 802.
Read 116 bytes, arptype 802.
...

I think someone else is playing with a DS in the neighbourhood because the "Read 116 bytes, arptype 802." packets were not here last night, and I see them even with eveything turned off ;o) (and without prismhdr too)
Anyway, the DS fails quickier, and beacontest reports no association established (actually not packets from the DS at all)

You've hit the same problem I did. If you turn on iwpriv on the capturing card, when you transmit you get your packet back (direct from the Linux network stack, due to promiscuous mode) marked 802, but without the header at the top. That's why you're seeing 188 byte packets (your outgoing beacons) but the code's not recognising the response. (cf comments "I don't know if that's an rt2500-specific value" in nifi.c).

Firstly, uncomment the loop above the above comment (except the continue). The second 32-bit word should be the length of the header on incoming packets (From the above, it's 64-bytes, which is normal. ^_^), and it'll be part of the 802.11 header on the outgoing packets... The first 32-bit word in the incoming packets will hopefully be a guard value of some kind... rt2500 uses 0x44 (which is an invalid value to start an 802.11 header, according to the driver source). Once you know what the guard-value is, add it to the test directly above the comment and see what happens. (Hopefully, everything magically works...)

Then, get on to the rt2400 driver authors, and point out that txmon + prism2 headers gives data of unexpected dodgeyness... You can point them here for rt2500's discussion: http://rt2x00.serialmonkey.com/phpBB2/viewtopic.php?p=4668#4668

Okay, the guard value :

Code:

Read 188 bytes, arptype 802.
80 00 00 00 ff ff ff ff ff ff 00 09 bf 91 ec 56
00 09 bf 91 ec 56 e0 00 00 00 00 00 00 00 00 00
ce 00 21 00 01 02 82 84 03 01 0d 05 05 00 02 00
00 00 dd 88 00 09 bf 00 0a 00 00 00 01 00 40 00
11 00 40 00 56 dc 70 0b fe 01 08 00 11 00 40 00
00 00 00 04 f9 fc 04 09 62 00 8f 11 11 11 3c 33
33 33 11 11 11 11 33 33 33 33 11 11 11 11 33 33
33 33 11 11 11 11 33 33 33 33 11 11 11 11 33 33
33 33 11 11 11 11 33 33 33 33 11 11 11 11 30 33
33 33 11 11 11 21 33 33 33 f9 11 11 c1 ff 33 33
fa 9f 11 51 ff 17 33 b3 bf 33 11 f2 1f 11 33 d3
39 33 da ff df 4b ff ff ff ff 7a 55
Read 94 bytes, arptype 802.
80 21 10 01 00 00 00 40 00 00 00 00 00 02 15 1b
00 00 00 a0 fb 97 d5 7e 00 00 00 00 00 00 00 0d
00 00 00 14 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 c3 00 00 00 56 00 00 00 00 00 00 00 00
b0 10 a2 00 00 09 bf 91 ec 56 00 09 bf 3d c8 6f
00 09 bf 91 ec 56 20 00 00 00 01 00 00 00

0x80 is for outgoing packets,
0x01102180 for incoming packets
Btw, I had to byte-swap the discarlen, it valued 0x40000000 instead of 0x00000040 (driver bug ?)

Here's the result :

Quote:

Read 188 bytes, arptype 802.
Read 116 bytes, arptype 802.
Discarding 64 bytes of prism header
Read 116 bytes, arptype 802.
Discarding 64 bytes of prism header
Read 188 bytes, arptype 802.
Read 94 bytes, arptype 802.
Discarding 64 bytes of prism header
Precheck, 30 bytes...Packet, Type 00, subtype b0, 30 bytes
Got an AUTH1 as we expected
Sent AUTH2, 30 bytes
Read 10 bytes, arptype 802.
Read 30 bytes, arptype 802.
Read 94 bytes, arptype 802.
Discarding 64 bytes of prism header
Precheck, 30 bytes...Packet, Type 00, subtype b0, 30 bytes
Got an AUTH1 as we expected
Sent AUTH2, 30 bytes
Read 10 bytes, arptype 802.
Read 30 bytes, arptype 802.
Read 74 bytes, arptype 802.
Discarding 64 bytes of prism header
Precheck, 10 bytes...Packet, Type 04, subtype d0, 10 bytes
Read 74 bytes, arptype 802.
Discarding 64 bytes of prism header
Precheck, 10 bytes...Packet, Type 04, subtype d0, 10 bytes
Read 130 bytes, arptype 802.
Discarding 64 bytes of prism header
Precheck, 66 bytes...Packet, Type 00, subtype 00, 66 bytes
Got an ASSOC REQ like we'd hope
Association accepted
Sent ASSOC REPLY, 34 bytes
Read 10 bytes, arptype 802.
Read 34 bytes, arptype 802.
Read 38 bytes, arptype 802.
Read 74 bytes, arptype 802.
Discarding 64 bytes of prism header
Precheck, 10 bytes...Packet, Type 04, subtype d0, 10 bytes
Read 38 bytes, arptype 802.
Read 38 bytes, arptype 802.
Read 38 bytes, arptype 802.
Read 38 bytes, arptype 802.
Read 38 bytes, arptype 802.
Read 38 bytes, arptype 802.
Read 38 bytes, arptype 802.
Read 38 bytes, arptype 802.
Read 116 bytes, arptype 802.
Discarding 64 bytes of prism header
Read 38 bytes, arptype 802.
Read 38 bytes, arptype 802.
Read 38 bytes, arptype 802.
Read 38 bytes, arptype 802.
Read 38 bytes, arptype 802.
Read 38 bytes, arptype 802.
Read 38 bytes, arptype 802.
Read 38 bytes, arptype 802.
Read 38 bytes, arptype 802.
Read 188 bytes, arptype 802.
Read 38 bytes, arptype 802.
Read 38 bytes, arptype 802.
Read 116 bytes, arptype 802.
Discarding 64 bytes of prism header
Read 38 bytes, arptype 802.
Read 38 bytes, arptype 802.
Read 38 bytes, arptype 802.
Read 38 bytes, arptype 802.
Read 38 bytes, arptype 802.
Read 38 bytes, arptype 802.
Read 38 bytes, arptype 802.
Read 38 bytes, arptype 802.
Read 38 bytes, arptype 802.
Read 38 bytes, arptype 802.
Read 38 bytes, arptype 802.
Read 38 bytes, arptype 802.
Read 38 bytes, arptype 802.
Read 38 bytes, arptype 802.
Read 116 bytes, arptype 802.
Discarding 64 bytes of prism header
Read 38 bytes, arptype 802.
Read 38 bytes, arptype 802.
Read 188 bytes, arptype 802.
Read 38 bytes, arptype 802.
Read 38 bytes, arptype 802.
Read 38 bytes, arptype 802.
Read 38 bytes, arptype 802.
Read 38 bytes, arptype 802.
Read 38 bytes, arptype 802.
Read 38 bytes, arptype 802.
Read 38 bytes, arptype 802.
Read 38 bytes, arptype 802.
Read 116 bytes, arptype 802.
Discarding 64 bytes of prism header
Read 38 bytes, arptype 802.
Read 38 bytes, arptype 802.
Read 38 bytes, arptype 802.
Read 38 bytes, arptype 802.
Read 38 bytes, arptype 802.
No response seen to second packet

I think the 116 bytes packets are not mines :

Code:

Read 116 bytes, arptype 802.
80 21 10 01 00 00 00 40 00 00 00 00 00 16 d8 d4
00 00 04 96 72 70 96 f0 00 00 00 00 00 00 00 0d
00 00 00 0a 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 c9 00 00 00 5a 00 00 00 00 00 00 00 00
80 00 00 00 ff ff ff ff ff ff 00 40 f4 9d bc 28
02 e0 35 b7 dc f0 a0 25 1e e6 b1 76 01 00 00 00
64 00 22 00 00 03 41 4e 59 01 02 82 84 03 01 0d
06 02 00 00

No more luck :(

EDIT : finally got capturing to work on windows, cap file here :)
(For those who wonder, use airodump with a wildpacket driver)

Haiken wrote:

Okay, the guard value :

Code:

Read 188 bytes, arptype 802.
80 00 00 00 ff ff ff ff ff ff 00 09 bf 91 ec 56
00 09 bf 91 ec 56 e0 00 00 00 00 00 00 00 00 00
ce 00 21 00 01 02 82 84 03 01 0d 05 05 00 02 00
00 00 dd 88 00 09 bf 00 0a 00 00 00 01 00 40 00
11 00 40 00 56 dc 70 0b fe 01 08 00 11 00 40 00
00 00 00 04 f9 fc 04 09 62 00 8f 11 11 11 3c 33
33 33 11 11 11 11 33 33 33 33 11 11 11 11 33 33
33 33 11 11 11 11 33 33 33 33 11 11 11 11 33 33
33 33 11 11 11 11 33 33 33 33 11 11 11 11 30 33
33 33 11 11 11 21 33 33 33 f9 11 11 c1 ff 33 33
fa 9f 11 51 ff 17 33 b3 bf 33 11 f2 1f 11 33 d3
39 33 da ff df 4b ff ff ff ff 7a 55
Read 94 bytes, arptype 802.
80 21 10 01 00 00 00 40 00 00 00 00 00 02 15 1b
00 00 00 a0 fb 97 d5 7e 00 00 00 00 00 00 00 0d
00 00 00 14 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 c3 00 00 00 56 00 00 00 00 00 00 00 00
b0 10 a2 00 00 09 bf 91 ec 56 00 09 bf 3d c8 6f
00 09 bf 91 ec 56 20 00 00 00 01 00 00 00

0x80 is for outgoing packets,

That's an 802.11 beacon, no AVR header

Quote:

0x01102180 for incoming packets

That's the guard value ^_^

Quote:

Btw, I had to byte-swap the discarlen, it valued 0x40000000 instead of 0x00000040 (driver bug ?)

I'd say it's a driver bug, yes. Things in 802.11 are generally LE, and the above data shows that being BE.... Then again, I've not seen the AVR specs, so maybe it's the rt2500 that's wrong? Apart from 802.11, things are normally LE on the wire.

Quote:

Here's the result :

Quote:

Read 116 bytes, arptype 802.
Discarding 64 bytes of prism header

I think the 116 bytes packets are not mines :

Code:

Read 116 bytes, arptype 802.
80 21 10 01 00 00 00 40 00 00 00 00 00 16 d8 d4
00 00 04 96 72 70 96 f0 00 00 00 00 00 00 00 0d
00 00 00 0a 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 c9 00 00 00 5a 00 00 00 00 00 00 00 00
80 00 00 00 ff ff ff ff ff ff 00 40 f4 9d bc 28
02 e0 35 b7 dc f0 a0 25 1e e6 b1 76 01 00 00 00
64 00 22 00 00 03 41 4e 59 01 02 82 84 03 01 0d
06 02 00 00

Looks like a beacon from 00:40:f4:9d:bc:28 to me. So at least we know it's trimming the AVR headers correctly.

Quote:

EDIT : finally got capturing to work on windows, cap file here :)
(For those who wonder, use airodump with a wildpacket driver)

Which is good, but sadly doesn't give AVR headers so we don't know what speed it's transmitting at. But it does show that the NDS is happily associating, and then idling hopefully until 3 seconds after it misses a beacon... So the management part is working fine. I still expect it's the transmit speed, myself.... If only I had a hostap-capable NIC, I could maybe munge hostap to do this sort of nonsense for me.

Would dumping the incoming data to a pcap file be useful? That'd be fairly trivial to hack into libnifi, I reckon. It wouldn't help _here_ (since the machine with libnifi can't see how fast it's transmitting "on the wire") but it might be useful for other purposes?

I finally ended with a pcap that includes prism header (modified airodump + troppix on laptop)

But with this kind of doc I decode the transmit rate as being 2Mbits :/
(Note the doc gives our "guard value" except I have it BE)

So, everything looks good to me... :(

I'll try to look into to pcap to check is everything is really fine, unless you have other suggestions ?

Haiken wrote:

I finally ended with a pcap that includes prism header (modified airodump + troppix on laptop)

But with this kind of doc I decode the transmit rate as being 2Mbits :/
(Note the doc gives our "guard value" except I have it BE)

So, everything looks good to me... :(

I'll try to look into to pcap to check is everything is really fine, unless you have other suggestions ?

The pcap seems to have been marked as IEEE802_11 rather than IEEE802_11_RADIO_AVS so ethereal takes the first byte as saying "beacon" and so gives tasty nonsensical decodes...

But yeah, it says 2mb/s to me too.

Code:

#! /usr/bin/perl

use strict;
use Net::Pcap;

die "$0: <input.cap> <output.cap>\n\tChange the datalink type of a packet capture" unless @ARGV == 2;
my $perr;
my $pcap_in = Net::Pcap::open_offline($ARGV[0], \$perr);

print "Input datalink is \"",Net::Pcap::datalink_val_to_description(Net::Pcap::datalink($pcap_in)), "\"\n";

my $pcap_out = Net::Pcap::open_dead(DLT_IEEE802_11_RADIO_AVS, Net::Pcap::snapshot($pcap_in));

print "Output Datalink is \"",Net::Pcap::datalink_val_to_description(Net::Pcap::datalink($pcap_out)), "\"\n";

my $pcap_dump_out = Net::Pcap::dump_open($pcap_out, $ARGV[1]);

my %hdr;
my $pkt;
while ($pkt = Net::Pcap::next($pcap_in, \%hdr)) {
Net::Pcap::dump($pcap_dump_out, \%hdr, $pkt);
}
Net::Pcap::dump_close($pcap_dump_out);
Net::Pcap::close($pcap_in);

A little program to rewrite the pcap linktype so ethereal can make sense of it.

And _now_ ethereal is willing to read it, and it looks fine to me. >_<

Try moving the DS closer to the antenna. I found a 1 metre distance strongly affected the results (from 150cm to 50cm... O_O)

(Edit: I can't guestimate distance, it seems)
(Edit: Don't need Data::Dumper in the program)

Fisrt, sorry for my english!...

I was trying beacontest to load some demos in my NDS, but It was impossible. The process stop after the Wireless Multi Boot Host Association. No Feedback flow is recieved from NDS.

I tested the app using madwifi-ng and rt2570 (cvs drivers). On the first driver, Prism Header Bit rate is set to 1.0 Mb (althought I specify 2M with iwconfig) I don't know if it can be the fault. Using rt2570, it seems that Prism header bit rate is ok (2Mb).

After a day of testing i have no success... All cards are in monitor mode using channel 13, promisc, and 2M.

I don't know why i never recive any feedback flow from NDS. Please if someone can help... :) And.. What is that "especial feature" that has rt2500 and no others? Because I couldn't find info about it, people say "it runs only with rt2500", but, Why?

WereWolf wrote:

What is that "especial feature" that has rt2500 and no others? Because I couldn't find info about it, people say "it runs only with rt2500", but, Why?

Nothing particularly, apart from "it works". Specifically, the manufacturer's coughed up GPLd drivers which require no loadable firmware, meaning other driver authors can make the card do exactly what they need it to do, without being caught by limitations of the firmware on the card. Because the manufacturer is outside the US, they seem to have been less restrictive in what the card's firmware can do, so it's less inclined to try and make decisions for you.

Earlier 802.11 cards tried to hide their 802.11ness behind a veneer of 802.3 (ethernet) respectibility. Later 802.11 cards instead shout their 802.11ness to the world, but don't hear what you say to them so much as what they expect you to say to them. ^_^

Finally I bought an rt2500 pcmcia card, now i can send the game to NDS without problems, but NDS hangs after the Nintendo logo. My NDS has the new firmware, i don't know if that is the problem, althought, i send official demos from nintendo.

Hooray! I got it to work!

Notes for those who may also be hoping to get it to work:

Currently it seems as though the latest version of the RT2500 driver from CVS doesn't work so well... whereas the most recent beta lacks the controls which the WMB utility needs. So I got the driver code I needed by using a slightly different CVS command from what the tutorial on DSWiki suggested.
(EDIT): Never mind, I was mistaken. I looked at the RT2500 directory and didn't see the source code, and wound up building from the RT2x00 directory even though I'd read instructions telling me not do. I feel like a dur-head. :)

Rather than getting latest version of the source
(cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/rt2400 co -P source)

I instead retrieved a version from around the time the tutorial was written
(cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/rt2400 co -P -D 2005-12-17 source)

So is this utility capable of WifiMe at this point? I guess I thought the process for running Wifime once WMB was working would be a lot more straightforward... <shrug> Well, even if that part's not quite there yet I'm having a lot of fun playing with the WMB demos.
_________________
---GEC
I think that all the work that's been done by the homebrew community so far to support people who want to program for the GBA or DS is amazing.
Thank you, everyone, I look forward to taking advantage of your work.

Last edited by tetsujin on Fri Jan 13, 2006 3:51 am; edited 2 times in total

tetsujin wrote:

Currently it seems as though the latest version of the RT2500 driver from CVS doesn't work so well...

Oh lord, they broke it? I didn't notice anything on the CVS commit list... I'll have another look, and go yell at someone until they fix it again. ^_^

Quote:

...
cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/rt2400 co -P -D 2005-12-17 source

Excellent, thanks for that.

Quote:

So is this utility capable of WifiMe at this point? I guess I thought the process for running Wifime once WMB was working would be a lot more straightforward...

Yeah, me too. The latest build should produce a beacontest_wifime binary as well (you may need to make beacontest_wifime instead of just make) but it doesn't work.

Basically, my understanding of wifime is that it's just like Passme. So I got the passme source from Darkfader's page (The VHDL) and loaded it into the same spot in the header, overwriting the icon stored there. Then the trick is to change where the ARM9 starts, to be that code, and where the ARM7 starts, to be the GBA cart.

There's two occurances of the start location, once in the RSA-signed header block thing, and once in the actual NDS header. I _think_ the idea is to change the NDS header's version, recalc the CRCs, on the theory that the original firmware checks the RSA key against the block its attached to, gets a good signature, and then fires up the NDS rom without checking that the start values _match_ the signed start values in the RSA block.

I presume the new firmware fixes this by either barfing if the NDS doesn't match the signature, or ignoring the start-points and other bits in the NDS header that are duplicated in the RSA block.

Anyway, it probably _ought_ to be easy, but what would really help would be someone pcaping WMB.exe sending the same .nds file in both WiFiMe and non-WiFiMe modes, so I can see the differences.

I'm going to be at a conference until the end of the month, so I won't be making much progress (if any) on libnifi before then. But I'll be taking my laptop and trying to rewrite capread.c into perl, and supporting multiple streams in one pcap file, so someone can just pcap for a day at a wireless demo point, and go home that night and produce tasty new demo roms with no fuss and no muss. ^_^

(I might also try and corner any of the rt2x00 developers who's silly enough to show their faces at the conference and see if we can work out how dscape will support this sort of thing. Then we get free, instant support on, for example, the bcm43xx card in my PowerBook. ^_^)

I'd also love to pull apart the signature-checking tool on FireFly's site and work out how the RSA signature is actually checked, but my laptop's a PowerBook so I can't run wine on it. Might be time to put some effort into ReactOS on qemu?

WereWolf wrote:

Finally I bought an rt2500 pcmcia card, now i can send the game to NDS without problems, but NDS hangs after the Nintendo logo. My NDS has the new firmware, i don't know if that is the problem, althought, i send official demos from nintendo.

Good to know it works on the pcmcia version. (I expected it would, but hadn't tried it). That hang probably means the signature got boned. Which means I'm doing it wrong. Drat.

TBBle wrote:

tetsujin wrote:

Currently it seems as though the latest version of the RT2500 driver from CVS doesn't work so well...

Oh lord, they broke it? I didn't notice anything on the CVS commit list... I'll have another look, and go yell at someone until they fix it again. ^_^

Oops, actually I built the wrong driver the first time. Sorry for the confusion. For some reason I looked at the rt2500 directory and thought there was no code in it. At least I got up and running, though...
_________________
---GEC
I think that all the work that's been done by the homebrew community so far to support people who want to program for the GBA or DS is amazing.
Thank you, everyone, I look forward to taking advantage of your work.

I'm trying to stumble my way through fixing whatever's wrong with beacontest-wifime. So far I've found one bug, a typo at the location (beacontest.c:853 and onward) where the ARM9 and ARM7 addresses are being set. (it sets ndshead 0x24, then 0x25 three times, likewise for 0x34 and 0x35 three times, rather than once each for 0x24-0x27 and 0x34-0x37) I also rigged up the program to write the modified NDS file out to a new file called dump.nds so I could see if there's anything wrong with it using ndstool...

So far, still no joy, though at the moment I'm stuck using just my GBA MP for testing (I can't find the data cable and power supply for my old GBA cartridge programmer, and I don't even remember if my current computer configuration has a printer port...) so I feel like that's adding an extra unknown to the process. (If I simply had the code written to a normal flash cart, I think I'd have a greater degree of confidence that it'll work properly once beacontest-wifime is working correctly... Relying on a GBAMP which I've never used with an NDS before, I have no idea if I'm doing it right... What would happen if you successfully WiFiMe'd a DS that didn't have valid NDS code on the GBA slot?)

I've also been monkeying around with the altered Super Mario 64 .bin files from the wifime site, trying to figure out how to assemble them into a working .NDS file. No luck with that so far...
_________________
---GEC
I think that all the work that's been done by the homebrew community so far to support people who want to program for the GBA or DS is amazing.
Thank you, everyone, I look forward to taking advantage of your work.

tetsujin wrote:

What would happen if you successfully WiFiMe'd a DS that didn't have valid NDS code on the GBA slot?)

Just white screens I believe, like if you force FlashMe to boot from a GBA cart with no DS code.
_________________
Now with 20% More Old Man from Zelda 1 than ever before!

The 9th Sage wrote:

tetsujin wrote:

What would happen if you successfully WiFiMe'd a DS that didn't have valid NDS code on the GBA slot?)

Just white screens I believe, like if you force FlashMe to boot from a GBA cart with no DS code.

Ah, thanks. (The analogy doesn't work for me, since I've never booted any DS code from the GBA slot before... but white screens I can understand, so now I know it'll be a noticably different case from when the NDS simply rejects the downloaded binary and freezes on the gray logo.) I thought it'd probably be something like that but I didn't know for sure. :)
_________________
---GEC
I think that all the work that's been done by the homebrew community so far to support people who want to program for the GBA or DS is amazing.
Thank you, everyone, I look forward to taking advantage of your work.

The typical failure modes of WifiMe are listed here.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

tetsujin wrote:

So far I've found one bug, a typo at the location (beacontest.c:853 and onward) where the ARM9 and ARM7 addresses are being set. (it sets ndshead 0x24, then 0x25 three times, likewise for 0x34 and 0x35 three times, rather than once each for 0x24-0x27 and 0x34-0x37)

Thanks for that! Comitted to the tree.

Quote:

I've also been monkeying around with the altered Super Mario 64 .bin files from the wifime site, trying to figure out how to assemble them into a working .NDS file. No luck with that so far...

And in return...

Code:

#! /usr/bin/perl

use strict;

my $buff;

open HEADER, "<header.bin";
open ARM9, "<arm9.bin";
open ARM7, "<arm7.bin";
open RSA, "<rsa.bin";
open OUT, ">output.nds";

die "Bad read: $!" unless 0x160 == read HEADER, $buff, 0x160;

# lseek(outfile, 0x20, SEEK_SET);
# read(outfile, &arm9off, 4);
# lseek(outfile, 0x2c, SEEK_SET);
# read(outfile, &arm9len, 4);
# lseek(outfile, 0x30, SEEK_SET);
# read(outfile, &arm7off, 4);
# lseek(outfile, 0x3c, SEEK_SET);
# read(outfile, &arm7len, 4);
# lseek(outfile, arm9off, SEEK_SET);

my $arm9off = unpack("L",substr($buff, 0x20, 4));
my $arm9len = unpack("L",substr($buff, 0x2c, 4));
my $arm7off = unpack("L",substr($buff, 0x30, 4));
my $arm7len = unpack("L",substr($buff, 0x3c, 4));

my $romlen = unpack("L",substr($buff, 0x80, 4));

printf("arm9off: 0x%08x\n", $arm9off);
printf("arm9len: \%d\n", $arm9len);
printf("arm7off: 0x%08x\n", $arm7off);
printf("arm7len: \%d\n", $arm7len);
printf("romlen: 0x%08x\n", $romlen);

print OUT $buff;

die "Bad read: $!" unless $arm9len == read ARM9, $buff, $arm9len;

seek OUT, $arm9off, 0;

print OUT $buff;

die "Bad read: $!" unless $arm7len == read ARM7, $buff, $arm7len;

seek OUT, $arm7off, 0;

print OUT $buff;

seek RSA, 0x3c, 0;

die "Bad read: $!" unless 136 == read RSA, $buff, 136;

seek OUT, $romlen, 0;

print OUT $buff;

close OUT;
close RSA;
close ARM7;
close ARM9;
close HEADER;

(Edit: Gave it a burl with the bugfix... With lines 817 and 818 commented out (how I _think_ it should work) the DS boots the WiFiMe'd game. With them not commented out, it's two-white-screen time)

(Edit: Forgot that I only want 136 bytes of the dratted RSA... Code updated. However, output.nds won't boot in either wifime or non- mode... And a look at the .rsa file in the archive shows it with specific start offsets (different from Passme!) in the .rsa file. But it didn't WMB still. (White screens) >_< Comitted anyway.)

TBBle wrote:

(Edit: Gave it a burl with the bugfix... With lines 817 and 818 commented out (how I _think_ it should work) the DS boots the WiFiMe'd game. With them not commented out, it's two-white-screen time)

So does that mean you got WiFiMe mode to work? ((EDIT): Or are you running this on a Flashme'd DS?) (confused) Based on the comments I'd thought of commenting those lines out, too, but then again, those lines are just updating a copy of that information that was made in a previous step... <shrug> I dunno enough about this stuff. :)

I never even managed two-white-screens, there was always the logo up top that was midway through fading out (meaning, I think, that the NDS rejected the binary before jumping to the start addresses.)

(EDIT): Since I'm not really sure where to go from here I'm going to try stripping the WiFiMe-mode code down to the bare essentials - get rid of the customized beacon name and description, maybe the logo, too (though it's nice to see the customized logo, and therefore know that the NDS accepted that, at least.) - and find the stuff to use my flashcard and put the NDS code on that instead of relying on my GBAMP. I should also re-read the WiFiMe thread again, and take notes this time... There's some good technical info there but it's damn hard to find amongst all the "Will my card work with this?" questions. I was hoping to find some kind of "declaration of victory" thread from when the PassMe was originally developed, but I couldn't find it here, may need to try elsewhere.

Quote:

(Edit: Forgot that I only want 136 bytes of the dratted RSA... Code updated. However, output.nds won't boot in either wifime or non- mode... And a look at the .rsa file in the archive shows it with specific start offsets (different from Passme!) in the .rsa file. But it didn't WMB still. (White screens) >_< Comitted anyway.)

So even reassembled it, by itself, is not the answer, it seems...

(EDIT): This is sort of a question about the VHDL file from which the PassMe instructions came... When it's altering the game title to put an ARM instruction in there, it says the program counter at that point is 0x027ffe24. However, the ARM9 start address that's patched into the binary is 0x027ffe04. Which is correct? Or are both somehow correct? I don't know where in NDS memory the binary ends up after it's sent over WMB... I guess if you're able to run beacontest-wifime (on a Flashme'd DS?) then the address as stored in the header is correct, and the comment is wrong - and whatever's causing beacontest-wifime to fail is a function of the lockout...

(EDIT): Seems my misunderstanding of the addresses and the related commentary was incorrect. From information here on how to get the ARM9 out of its infinite loop after a successful PassMe boot:

Code:

*(volatile uint32 *)0x027FFE24 = 0x02004000;

So 0x27FFE24 is the ARM9 program counter itself, I guess? And 0x027EE00 is the place where the game title gets loaded...

There was a comment by Firefly on this page of the WiFiMe thread:

Tim Schuerewegen wrote:

Final version of my Wireless Multiboot "PassMe" hack. The previous version needed a small change to the PassMe boot code for taking control of the ARM9 CPU. This is no longer necessary. It is now compatible with existing PassMe homebrew binaries.

This suggests that he maybe had to do something differently with initial versions of WiFiMe to trap the ARM9 (though I can't imagine quite what - perhaps it was some specific jump location in the Super Mario 64 binary itself? But why would that change the process for taking control of the ARM9 again?) but that later he managed to turn it into something that didn't require different ARM9 bootstrap code... Suggesting that the mechanism PassMe uses may not work in WMB?
_________________
---GEC
I think that all the work that's been done by the homebrew community so far to support people who want to program for the GBA or DS is amazing.
Thank you, everyone, I look forward to taking advantage of your work.

Last edited by tetsujin on Sat Jan 14, 2006 4:28 am; edited 2 times in total

Hello all,

Was playing around with the rt2570 driver (USB wifi - the chipset used in Nintendo's WiFi adaptor) trying to get my PC to talk Pictochat and I've just discovered this project - good work. And happily it sort of works with my hacked driver.

It involves hacking the driver code as there is not a command to set short preamble in this driver. My driver code is fairly recent copy (about the start of Jan) out of the rt2400 cvs.

The file you need is rtusb_init.c.
In the function PortCfgInit change the following (about line 1900):

Code:

// PHY specification
pAdapter->PortCfg.PhyMode = PHY_11BG_MIXED;
// RTMPSetPhyMode(pAdapter, PHY_11BG_MIXED); // default in 11BG mixed mode
pAdapter->PortCfg.Dsifs = 10; // in units of usec
pAdapter->PortCfg.TxPreambleInUsed = Rt802_11PreambleLong; // use Long preamble on TX by defaut

// user desired power mode
pAdapter->PortCfg.WindowsPowerMode = Ndis802_11PowerModeCAM; // Ndis802_11PowerModeFast_PSP;
pAdapter->PortCfg.WindowsTxPreamble = Rt802_11PreambleAuto; // use Long preamble on TX by defaut

to this:

Code:

// PHY specification
pAdapter->PortCfg.PhyMode = PHY_11BG_MIXED;
// RTMPSetPhyMode(pAdapter, PHY_11BG_MIXED); // default in 11BG mixed mode
pAdapter->PortCfg.Dsifs = 10; // in units of usec
pAdapter->PortCfg.TxPreambleInUsed = Rt802_11PreambleShort; // use Short preamble on TX by defaut

// user desired power mode
pAdapter->PortCfg.WindowsPowerMode = Ndis802_11PowerModeCAM; // Ndis802_11PowerModeFast_PSP;
pAdapter->PortCfg.WindowsTxPreamble = Rt802_11PreambleShort; // use Short preamble on TX by defaut

See, changing Rt802_11PreambleLong or Auto to Short.
This change may break your driver for normal WiFi use so keep a non hacked copy of the module around if that is important to you.
You can then set the card up with the following commands:

Code:

ifconfig rausb0 up
iwpriv rausb0 rfmontx 1
iwconfig rausb0 mode monitor channel 13 rate 2M

Now for the some success part:
I can download and play the Electroplankton demo.
But the other demos I've tried (Sushi, table hockey, submarine, trauma) give me two grey screens. The top screen has the nintendo logo that starts to fade (in the case of Sushi the logo is corrupted) but then the DS just sits there. What does this indicate?

Ben

EDIT: changed the file from rtusb_info.c to the more correct rtusb_init.c

Last edited by masscat on Sun Jan 29, 2006 11:30 am; edited 1 time in total

masscat wrote:

Now for the some success part:
I can download and play the Electroplankton demo.
But the other demos I've tried (Sushi, table hockey, submarine, trauma) give me two grey screens. The top screen has the nintendo logo that starts to fade (in the case of Sushi the logo is corrupted) but then the DS just sits there. What does this indicate?

I got similar results using my RT2500-based Belkin card. This isn't a full list, but it's what I remember offhand.

(These tests with a non-flashme'd NDS, V2 firmware I think (blue screens when doing the Pictochat crash test) on an Intel-based Debian box with a Belkin F5D7000 v3001, rt2500 driver from 2005-12-17, and Linux 2.6.15)

Success:
DS Training for adults
electroplankton
Famicom Wars DS
Jump superstars demo
Meteos Demo (E3 version, IIRC. Probably the most fun out of the demos I've gotten to work.)
Pokemon torouze
Zelda Gallery

Failure:
Ganbare Goemon
Guru Guru Nagetto
Table hockey
submarine tech demo
trauma center
zelda preview trailer

Not having tried these demos with WMB.exe on Windows or any other mechanism, I can't say for sure that they're good copies - though I'd imagine they are.

(EDIT): BTW, nice work with that 2570 driver! Show it who's boss!

(EDIT): I've been tinkering with WiFiMe, of course, trying to get it to work, but I wonder now if that might be a bit pointless, if we haven't gotten all the official, known-working demos to work... The possibility that the WMB process itself is doing something wrong contaminates any attempts to figure out what does and doesn't work for WiFiMe...
_________________
---GEC
I think that all the work that's been done by the homebrew community so far to support people who want to program for the GBA or DS is amazing.
Thank you, everyone, I look forward to taking advantage of your work.

On Wifime:

Yes, my DS is Flashme'd... So trying to wifime and having it boot the WMB'd rom means it ignored the changes I made to the ROM header.

I reckon we can work this out if someone can supply a pcap of Super Mario 64 DS's slave being WMB'd, and a pcap of WiFiMe mode from Firefly's WMB, so we can look at the differences.

On rt2570 failures:

The fact that table hockey fails, and it failed for me too when I tried to WMB it with the .rsa file (DOTRSA mode in beacontest), while non-DOTRSA mode it works fine on my Flashme'd DS.

TBBle wrote:

On Wifime:

Yes, my DS is Flashme'd... So trying to wifime and having it boot the WMB'd rom means it ignored the changes I made to the ROM header.

I reckon we can work this out if someone can supply a pcap of Super Mario 64 DS's slave being WMB'd, and a pcap of WiFiMe mode from Firefly's WMB, so we can look at the differences.

Yeah, that's probably the simplest way...

I've been tinkering with the WiFiMe-mode code of beacontest, minimalizing the changes to the header. I left the CRC change in and turned everything else off except for the 4-byte ARM instruction that gets written to the game title field (even left the entry point addresses alone) and the thing still failed to boot... I'll need to run more tests to see what's up but so far the results aren't encouraging.

Quote:

On rt2570 failures:

The fact that table hockey fails, and it failed for me too when I tried to WMB it with the .rsa file (DOTRSA mode in beacontest), while non-DOTRSA mode it works fine on my Flashme'd DS.

Ah. So those files don't have RSA signatures internally or something? I guess I didn't understand that point...
_________________
---GEC
I think that all the work that's been done by the homebrew community so far to support people who want to program for the GBA or DS is amazing.
Thank you, everyone, I look forward to taking advantage of your work.

Ok I am following these instructions http://tobw.net/dswiki/index.php?title=Set_up_WMB_for_Linux with the exception that I used this cvs command
"cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/rt2400 co -P -D 2005-12-17 source"

Everything went like a dream up until the libnifi compile and I get this error

root:/home/darkshadow/libnifi# make
gcc -o nifi.o -c nifi.c -g
In file included from /usr/local/include/iwlib.h:127,
from nifi.c:23:
/usr/include/linux/socket.h:1:2: warning: #warning "You should include <sys/socket.h>. This time I will do it for you."
nifi.c: In function `wlaninit':
nifi.c:691: error: structure has no member named `b'
nifi.c:730: error: structure has no member named `b'
nifi.c:731: error: structure has no member named `b'
nifi.c:732: error: structure has no member named `b'
nifi.c:734: error: structure has no member named `b'
nifi.c: In function `startbeacon':
nifi.c:916: error: structure has no member named `b'
nifi.c:938: error: structure has no member named `flags'
nifi.c:938: error: `IW_FREQ_FIXED' undeclared (first use in this function)
nifi.c:938: error: (Each undeclared identifier is reported only once
nifi.c:938: error: for each function it appears in.)
make: *** [nifi.o] Error 1

The "./rt2500.sh ra0 13" command goes on fine I just need the beacontest file and I should be done
I am just trying to get official nds demos to work as I only have a stock ds.

Update I upgraded my wireless-tools from v16 to v27 and the libnifi compile worked fine I have tested a demo and it worked perfect.

Keep up the good work on wmb for Linux

Hey!

I have a Belkin FD7050 (v2000) USB dongle, plus Linux (Debian) with wireless tools.

-SNIP- Got things half working

I have build and installed the module (rt2570) and the device is now showing up as rausb0 in iwconfig.

When I run "./beacontest SushiDS.nds rausb0" I get:

Code:

NDS length mismatch... The end is nigh!
On a more serious note, the NDS header claims to be 0x0000 long, but the file is 0x96649 long.
Loading Beacon from data @ 0x00095e00
Configured interface rausb0 (00:09:bf:91:ec:56) on channel 13
wlan initited

When I run "DS Download Play" on the DS, Sushi DS is picked up (icon/name displayed etc)... though when I try and download it I get:

"Communication Error.
Download not Completed."

iwconfig:

Code:

rausb0 RT2500USB WLAN ESSID:""
Mode:Monitor Frequency=2.472 GHz Bit Rate=2 Mb/s
RTS thr:off Fragment thr:off
Encryption key:off
Link Quality=0/100 Signal level:-120 dBm Noise level:-200 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0

I ran into a problem with iwpriv, which was saying:

Code:

Invalid command : set

Anybody know why the .nds isn't downloading?

Last edited by justatest on Mon Jan 16, 2006 2:03 am; edited 2 times in total

shadowofdarkness wrote:

Ok I am following these instructions http://tobw.net/dswiki/index.php?title=Set_up_WMB_for_Linux with the exception that I used this cvs command
"cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/rt2400 co -P -D 2005-12-17 source"

Using a snapshot from December 17th was my idea, as a result of my initial confusion about the layout of source inside their directory structure. You might at some point want to run "CVS update -d -A" in your source directory, to get the latest - though the driver you want to build hasn't changed much since then, and apparently you've got it to work, so on the other hand you just might not want to mess with it. ("If it ain't broke...")
_________________
---GEC
I think that all the work that's been done by the homebrew community so far to support people who want to program for the GBA or DS is amazing.
Thank you, everyone, I look forward to taking advantage of your work.

justatest I am under the understanding that no usb card will work as they are to slow due to lag

tetsujin I may try newer because so far most work but some demos seem to mess up the odd time then work another

shadowofdarkness wrote:

justatest I am under the understanding that no usb card will work as they are to slow due to lag

tetsujin I may try newer because so far most work but some demos seem to mess up the odd time then work another

Too slow? I find that hard to believe (For WMB) as surely not much syncing has to be done. To clarify, i've managed to get my card talking to the DS, though I just can't get the demo to download.

justatest wrote:

When I run "./beacontest SushiDS.nds rausb0" I get:

Code:

NDS length mismatch... The end is nigh!
On a more serious note, the NDS header claims to be 0x0000 long, but the file is 0x96649 long.
Loading Beacon from data @ 0x00095e00
Configured interface rausb0 (00:09:bf:91:ec:56) on channel 13
wlan initited

When I run "DS Download Play" on the DS, Sushi DS is picked up (icon/name displayed etc)... though when I try and download it I get:

"Communication Error.
Download not Completed."

Among other things, SushiDS won't work over WMB unless your DS has been FlashMe'd... I'd try Meteos or Electroplankton, or one of the other official demos that'll work as-is using beacontest.

Quote:

iwconfig:

Code:

rausb0 RT2500USB WLAN ESSID:""
Mode:Monitor Frequency=2.472 GHz Bit Rate=2 Mb/s
RTS thr:off Fragment thr:off
Encryption key:off
Link Quality=0/100 Signal level:-120 dBm Noise level:-200 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0

I ran into a problem with iwpriv, which was saying:

Code:

Invalid command : set

Anybody know why the .nds isn't downloading?

iwpriv sends driver-specific commands to a particular wireless device's driver. The fact that "set" is being seen as an invalid command indicates that your driver doesn't match the versions known to work with the setup script for beacontest. (But I think the 2570 driver may be a different beast from the 2500 driver - not really sure.)

Did you read the message in this thread (a page or two back I think) from the guy who said he'd been successful in using an RT2570-based USB adaptor, by altering the 2570 driver to perform the WMB-specific setup internally? That may be the way to go at this point...
_________________
---GEC
I think that all the work that's been done by the homebrew community so far to support people who want to program for the GBA or DS is amazing.
Thank you, everyone, I look forward to taking advantage of your work.

Thanks for the great reply! Electroplankton wasn't loading either. Things looked a little cleaner at the beacontest side, though the DS was reporting the same error.

I'll take a look at the source code modification you mentioned.

For all you rt2570 users out there, I have stuck a page up on me website to help out with the hacked rt2570 driver.

http://masscat.afraid.org/ninds/hacking.php

Ben

Can somebody please comfirm that using the windows version of the WMB program they can download and play all of the offical demos on a non-flashme DS.

Edit: changed Wifime to WMB to avoid confusion

Last edited by masscat on Mon Jan 16, 2006 3:36 pm; edited 1 time in total

Thanks! I'm pretty sure that will work.

I was also wondering why only signed Nintendo roms work, when the following page (for the Windows Version) states that "...allow anyone with a Nintendo DS and a supported wireless network card to load any homebrew demo/app on their DS..."

http://aaronrogers.com/nintendods/wifime.php

Well, The actual beacontest has some bugs. If you have not a flashed DS most of Nintendo demos doesn't work . I saw a capture from WMB windows and the headers packets are not send at the same position that beacontest do, Header packets (.nds header), are send at the last on my ethereal capture file (using zelda preview trailer e3 demo and WMB windows). Beacontest signature packets and WMB windows signature packets are the same, then, the signature is not the problem. isn't it?

Anyways i cannot test more with it because i flashed my NDS last friday.

justatest wrote:

Thanks! I'm pretty sure that will work.

I was also wondering why only signed Nintendo roms work, when the following page (for the Windows Version) states that "...allow anyone with a Nintendo DS and a supported wireless network card to load any homebrew demo/app on their DS..."

http://aaronrogers.com/nintendods/wifime.php

Because, there's WMB and then there's WiFiMe.

WMB is just how you send code over the wireless ethernet to a Nintendo DS. The receiving unit needn't have any cartridges in it at all, it'll still be able to receive the download.

WiFiMe is a technique for using WMB to perform the same function as PassMe - trick the DS into running DS code from the GBA slot. This allows "anyone with a DS and a supported wireless network card (and a programmable GBA cart) to run any homebrew demo/app on their DS." If you then re-flash your DS with FlashMe, then you can WMB things directly that aren't signed.
_________________
---GEC
I think that all the work that's been done by the homebrew community so far to support people who want to program for the GBA or DS is amazing.
Thank you, everyone, I look forward to taking advantage of your work.

masscat wrote:

For all you rt2570 users out there, I have stuck a page up on me website to help out with the hacked rt2570 driver.

http://masscat.afraid.org/ninds/hacking.php

Ben

Right, I have built and installed your modified driver. The beacon is recieved by the DS.. but i'm getting the same "Communication error" as the previous driver.

Code:

/libnifi/bzr.tbble.net/libnifi# ./beacontest electroplankton_demo_e3_2005.nds ninusb0
NDS length + 136 matches NDS header: RSA signature appended.
Loading Beacon from data @ 0x001a0e00
Configured interface ninusb0 (00:09:bf:91:ec:56) on channel 13
wlan initited
Association accepted
Ready to send RSA after 18 sends
No response seen to RSA packet

dmesg is also showing the following:

Code:

usb.c: registered new driver rt2500usb
idVendor = 0x50d, idProduct = 0x7050
RT25usb Driver version 1.0.0
device ninusb0 entered promiscuous mode
usb-uhci.c: ENXIO 80000200, flags 0, urb c2628190, burb c2628390
usb-uhci.c: ENXIO 80000200, flags 0, urb c2628190, burb c2628390
[repeat lots]
protocol 0300 is buggy, dev ninusb0
protocol 0300 is buggy, dev ninusb0
[repeat lots]
NET: 2 messages suppressed.
protocol 0300 is buggy, dev ninusb0
protocol 0300 is buggy, dev ninusb0
[repeat lots]

Hello justatest,

The "protocol 0300 is buggy, dev ninusb0" stuff should not be a problem as that happen to me too.

How many times have you tried? Sometimes the connection fails and just running beacontest again will work fine.
Another thing you could try is taking the interface down and back up again before retrying.

Code:

ifconfig ninusb0 down
ifconfig ninusb0 up
iwpriv ninusb0 rfmontx 1
iwconfig ninusb0 mode monitor channel 13 rate 2M

Also what kernel version are you running? I am using a Debian image of kernel 2.6.14. Having looked at the driver code I believe you are running a 2.4 kernel. Now I don't think this should matter but I have not renamed the driver for 2.4 kernels (oops). So if you have the original driver module still loaded or available in your module directory and you may actually be using that - not sure what would happen if two drivers are called the same thing. Although the interface has been named ninusb0 some part of the hacked driver is running.

Cannot think of anything else a the moment.

Ben

Had tried it *MANY* times... but was getting the same error. Just tried again (bringing the interface down/up and reconfiguring as you said) and it worked! But now I can't get it to work again, whatever I do.

I think beacontest needs to be revisied to correct its bugs. It should in theory work flawlessly every time... but instead is extremely temperamental.

Thanks for supporting my noob questions :-D

justatest wrote:

Had tried it *MANY* times... but was getting the same error. Just tried again (bringing the interface down/up and reconfiguring as you said) and it worked! But now I can't get it to work again, whatever I do.

I think beacontest needs to be revisied to correct its bugs. It should in theory work flawlessly every time... but instead is extremely temperamental.

Thanks for the support my noob questions :-D

I did expect that you may have tried it more than once before giving up but I had to ask :). Good to hear that it has worked at least once for you.

The driver is more likely to be causing problems than beacontest. I am not too sure about the stablity of the rt2570 drivers as they are not as mature as the ones for the rt2500 and taking the driver up and down really should not make any difference but it can. Unfortunately, I believe they are not being developed further as the driver project is moving to a unified driver for all the ralink chipsets. This may help long term but for the time being we are stuck with what we've got.

Oh and one more thing: can WifiMe be used over Linux yet (using these drivers)?

I don't quite understand how WifiMe works. Surely a binary must be run before execution is passed to the GBA slot... but how can a binary possibly be run without being RSA signed?

My goal is to flash my DS's firmware without buying extra kit... i'm sure theres a way :-(

justatest wrote:

I don't quite understand how WifiMe works. Surely a binary must be run before execution is passed to the GBA slot... but how can a binary possibly be run without being RSA signed?

A bug in Nintendo DS firmware versions 1-3 allowed WiFiMe to say "Here's a signed binary to load, but jump into the GBA ROM instead." Firmware v4 got the entry point directly from the signed binary.

Quote:

My goal is to flash my DS's firmware without buying extra kit... i'm sure theres a way :-(

Were you part of the GBA homebrew scene?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

justatest wrote:

I think beacontest needs to be revisied to correct its bugs. It should in theory work flawlessly every time... but instead is extremely temperamental.

I think its use with USB adaptors is still rather new territory for the utility. I have had almost a 100% success rate with it using the Belkin PCI card in my machine. (Well, some of the demos don't work - but I think based on comments here that those demos are ones which don't have their RSA signature in the NDS file itself. Beacontest has a separate mode to handle that case, which apparently doesn't work yet.) That certainly doesn't mean that your troubles aren't the result of a fault in beacontest itself, but you have to bear in mind that this is software that's still in development. Obviously we'd all love for it to be 100% bug-free, compatible with as many adaptors and drivers as possible, capable of WiFiMe, DOTRSA, beaconing multiple demos at once, etc. - but it takes time, and some things are going to get prioritized before others. Look on the bright side. You've successfully used your USB wireless adaptor to WMB your DS once. That's more than anybody running Windows can say. :)

Things that don't work will be made to work when "someone" fixes them - and seriously, if you want something fixed, you have to consider that "someone" in that case might be "you". I came into this thread with a brand new DS, no wireless card, and hardly a clue about using wireless cards on Linux, and got up and running, found a bug (albeit a very easy-to-find one) in the WiFiMe code, and have resolved not to FlashMe my DS until I or someone else succeeds in getting beacontest-wifime to work, so that I can continue trying to solve that problem, or at least act as a tester if someone else fixes it...

If I had to guess why you're seeing such poor success rates with beacontest, and yet have gotten one successful boot out of it, I'd say that either you're getting very poor reception (which would be unlikely if you've got your NDS within a few feet of your USB adaptor, with no big metal computer in the way) or else your device driver still isn't accepting all the configuration parameters that are supposed to be set before you run beacontest - resulting in a configuration which somehow works, but unreliably. But masscat may know more about this since he's the one who got it to work. (I don't have a USB wireless adaptor...)

I also am hoping to FlashMe my DS using the WMB-for-Linux utilities - but so far that's not possible. How long it'll take is hard to say at this point. It'll be easier if "someone" captures the data put out by the Windows WiFiMe (It'll be a chore, but I really ought to see about doing this myself... can you run pcap on a Powerbook?) so we can simply copy what's done there - in the meantime I'm trying to learn more about it and contribute what I can.
_________________
---GEC
I think that all the work that's been done by the homebrew community so far to support people who want to program for the GBA or DS is amazing.
Thank you, everyone, I look forward to taking advantage of your work.

@tetsujin:

Yes of course... fully understood. Sorry if I sounded a little selfish in my previous post(s). I'm all for group participation, and without it, this and the many other accomplishments by the homebrew community wouldn't have become working realities. I'm very new and am just trying to catch up on what i've missed.

If I could help in any way I would and will.

justatest wrote:

@tetsujin:

Yes of course... fully understood. Sorry if I sounded a little selfish in my previous post(s). I'm all for group participation, and without it, this and the many other accomplishments by the homebrew community wouldn't have become working realities. I'm very new and am just trying to catch up on what i've missed.

If I could help in any way I would and will.

Well, it's sort of a practical thing, too. In broad terms, if you want something to happen, one of the most effective strategies is to do it yourself. (Though it's by no means the easiest way a lot of the time...) I'm pretty new here, too, but I'll try to share what I've learned so far.

If you can figure out how to get your setup working better, most likely you will learn something about what was going wrong, and that may be useful information for other people. I'd suggest trying to get your software closer to what masscat was using (kernel version?), and do your best to make sure that all those parameters which are supposed to be set for the driver to get the right preamble, data rate, etc. really are set.
_________________
---GEC
I think that all the work that's been done by the homebrew community so far to support people who want to program for the GBA or DS is amazing.
Thank you, everyone, I look forward to taking advantage of your work.

Here is how to associate with a DS that is hosting a WMB.

First send the DS an Authentication frame with flags set to zero and with the the parameters set as follows:

Authentication System : open (0x0000)
Authentication SEQ: 0x0001
Status code: success (0x0000)

Remember that you have to reorder the bytes in the frame so 0x0001 will appear in the frame as 0x01,0x00.
The DS will respond with an Authentication frame with SEQ 0x0002 and if it is happy a status code of success (0x0000).
You can now attempt to associate with the DS. For this to be successful you need to copy some data out to the Nintendo IE of the most recent beacon that the DS has sent you (I'm not sure if the data does change but I'm playing it safe) and into the SSID parameter of the AssocReq.

Copy 4 bytes starting at offset 0x18 from the Nintendo IE data into the first 4 bytes of the SSID parameter.
Copy 2 bytes starting at offset 0x10 from the Nintendo IE data into the following bytes (ie begining at offset 0x4) of the SSID parameter.

The DS will respond to your Assoc Req with a Assoc Resp and if is happy then the status code in the response will be success (0x0000), if the SSID in your request is not correct the status will be 0x0001. Any other status means you have problems elsewhere.
If the association is successful the DS will start shouting out data frames. This has worked for me with both Meteos and Mkart.

Hopefully understanding the client better will help with the hosting.

Ben

Here is a change for beacontest.c that MAY help with beacontest failing with "No response seen to RSA packet".
I managed to get two DS together and have been looking at a download between them. I have seem RSA response frames from the client that have values other than 0x01 in then fourth byte. I do not know why it varys. But until that is figured out do the follow change and see if you get any success.
The line you need to change is at about line 320 and in the function gotpredata.

Change this:

Code:

   if (data[0] == 0x04 && data[1] == 0x81 && data[2] == 0x07 && data[3] == 0x00)
      *(int *)context = 7; // Synced, ready for RSA
   if (data[0] == 0x04 && data[1] == 0x81 && data[2] == 0x08 && data[3] == 0x01)
      *(int *)context = 8; // Seen RSA, ready for data

to this:

Code:

   if (data[0] == 0x04 && data[1] == 0x81 && data[2] == 0x07 && data[3] == 0x00)
      *(int *)context = 7; // Synced, ready for RSA
   if (data[0] == 0x04 && data[1] == 0x81 && data[2] == 0x08)
      *(int *)context = 8; // Seen RSA, ready for data

The comparison on the fourth byte has been removed from the Seen RSA case.
Do this change at own risk and all that.
Ben

Wow! beacontest seems very reliable now. Thank you masscat.

Noticed an aweful lot of WifiMe references in beacontest.c. Is this undergoing development/testing or is it abandonned code?

I don't know much about the whole data transmission process, but now that I have a setup that works (e.g. DS/PC talking), is there any other way in which I can help?

I tried your changes masscat but it didn't seem to help I still get "No response seen to RSA packet" more often then not

justatest wrote:

Noticed an awful lot of WifiMe references in beacontest.c. Is this undergoing development/testing or is it abandonned code?

The WiFiMe code in beacontest was based upon the PassMe method, as it's assumed that WiFiMe works the same way. It is presently not working. I've been monkeying with it, trying to get it to work, but so far no luck. TBBle suggested that someone do a capture of the Windows WiFiMe so we can get a better idea of what it does, and what's missing from the beacontest version. (I may try to do it, if I can get the gear together and learn how to do the capture.)

I'm hoping to find out how much I can change the header of a demo and still WMB it successfully. In my initial attempts at this it seemed as though almost any change would cause the WMB to ultimately fail (I think I even tried changing only the game title field and CRC, and found that failed...) but I need to repeat the tests as I didn't document them.
_________________
---GEC
I think that all the work that's been done by the homebrew community so far to support people who want to program for the GBA or DS is amazing.
Thank you, everyone, I look forward to taking advantage of your work.

shadowofdarkness wrote:

I tried your changes masscat but it didn't seem to help I still get "No response seen to RSA packet" more often then not

Some suggestions. Check the code change is as stated in the post. See if there is a newer version of the beacontest source than you are using. If you are in a noisy environment, wirelessly speaking (computers on wireless network, cordless phones, baby monitors, somebody using a power drill and the like), then that could be affecting it.

As I said in the original post, I do not understand why the response varys at the moment. If you can program then you are in a good position to try and figure it out so start hacking about in the code and see what you can find out. As tetsujin said, if you have the skills start exploring and you may help everybody else along with yourself.
There are a lot of places for things to go wrong. We are using a hacked version of a beta driver (rt2570), beacontest is very much in development and the wmb process is not fully understood. Fortunately things will improve.

Edit: Forgot to add this: I found this presentation that gives an overview of Ni-Fi

http://www.cs.unc.edu/~jasleen/Courses/Fall05/projects/wmb_presentation.pdf
I'm having trouble connecting to the site at the mo though ;(

masscat wrote:

Some suggestions. Check the code change is as stated in the post. See if there is a newer version of the beacontest source than you are using. If you are in a noisy environment, wirelessly speaking (computers on wireless network, cordless phones, baby monitors, somebody using a power drill and the like), then that could be affecting it.

If you can program then you are in a good position to try and figure it out so start hacking about in the code and see what you can find out.

I checked and I had the newest beacontest source. I am guessing that my problems are because of what you mentioned. I live in a pretty cramped condo that has a massive wireless presense. When I scan for ssid's I can usually find 8-10 and that is only the ones that broadcast a ssid there are a couple more like mine that don't. along with the rest of the things you listed that I can't scan for I should have a massive amount of interference.

As for coding I would if I could, but I could not even do a hello world without a refresher to coding so I am no help. for sniffing traffic for logs I only have one ds (got it first day) and have never even came across someone who has one.

Well I feel useless to the wmb cause now.

shadowofdarkness:

Sounds like interference is your problem. I do not know enough about wireless lans to know what happens when things get crowded but you are likely to start missing lots of frames hence the "no response" thing.

It is useful to have people testing stuff and reporting problems so do not feel disheartened. And if things start working in your noisy environment then it shows the software is getting better.

I have been developing a WMB client and have hit, what I believe, is a bit of a insurmountable problem with my current approach.
You can read about it fully and get the source for the client (as is) at my website. Use the source for what ever you like.

http://masscat.afraid.org/ninds/hacking.php

To summerise: at the application level it is impossible to guarantee to see a frame from the host and send your response within the time that the host requires the response.

If anybody does run the client and gets it to print out "cannot do name yet" then let me know as that shows that at least some of the data exchange has been successful.

Ben

masscat wrote:

I have been developing a WMB client and have hit, what I believe, is a bit of a insurmountable problem with my current approach.
You can read about it fully and get the source for the client (as is) at my website. Use the source for what ever you like.

To summarise: at the application level it is impossible to guarantee to see a frame from the host and send your response within the time that the host requires the response.

I'm not sure I understand. I read your post and the explanation on your webpage - would this problem of latency at application level on the Linux system apply even to a Linux system which is running nothing else? (It seems a bit severe to drop into single-user mode and shut down everything to run a WMB client - but it's doable if that's what it takes.)

If there is a way to get a successful WMB download using the current code, even if it's fiddly, that could be useful to me as I attempt to help get WiFiMe mode working.
_________________
---GEC
I think that all the work that's been done by the homebrew community so far to support people who want to program for the GBA or DS is amazing.
Thank you, everyone, I look forward to taking advantage of your work.

tetsujin wrote:

I'm not sure I understand. I read your post and the explanation on your webpage - would this problem of latency at application level on the Linux system apply even to a Linux system which is running nothing else? (It seems a bit severe to drop into single-user mode and shut down everything to run a WMB client - but it's doable if that's what it takes.)

If there is a way to get a successful WMB download using the current code, even if it's fiddly, that could be useful to me as I attempt to help get WiFiMe mode working.

With the current code there is no way to download a WMB demo from a DS host. This is because I stopped developing it when I found I could not reply to the first data message sent by the DS.

I had not thought of single user mode - good idea. This may work, although it will be lots of fun trying to develop the program that way. There may still be a problem as the kernel could wonder off doing something else before giving control back to the app but I think that it is unlikely it would do this for long enough and often enough to cause a problem.

Well I'm off to single user land to see it it works, I may never make it back :).

I tried compiling your client and got this ouput if it is any help to you

darkshadow:~/broke_wmbclient$ make
gcc -g -W -Wall -O2 -c -o timed_actions.o timed_actions.c
gcc -g -W -Wall -O2 -c -o common.o common.c
common.c: In function `openraw':
common.c:43: error: storage size of 'ifr' isn't known
common.c:44: error: storage size of 'sll' isn't known
common.c:60: error: `ETH_P_ALL' undeclared (first use in this function)
common.c:60: error: (Each undeclared identifier is reported only once
common.c:60: error: for each function it appears in.)
common.c:43: warning: unused variable `ifr'
common.c:44: warning: unused variable `sll'
common.c: In function `enable_promisc':
common.c:95: error: storage size of 'ifr' isn't known
common.c:96: error: storage size of 'mr' isn't known
common.c:111: error: `PACKET_MR_PROMISC' undeclared (first use in this function)
common.c:113: error: `PACKET_ADD_MEMBERSHIP' undeclared (first use in this funct
ion)
common.c:95: warning: unused variable `ifr'
common.c:96: warning: unused variable `mr'
common.c: In function `setupSockets':
common.c:130: error: `ETH_P_ALL' undeclared (first use in this function)
common.c: In function `getIfHwAddress':
common.c:165: error: storage size of 'ifr' isn't known
common.c:165: warning: unused variable `ifr'
make: *** [common.o] Error 1

This is on my "Linux From Scratch" install with gcc version 3.4.1

masscat wrote:

Well I'm off to single user land to see it it works, I may never make it back :).

I am back. Unfortunately it was close but not quite. The time between the host sending the packet and the reply varies between about 0.1 and 2 milliseconds with the median (I had to look that up - how sad) being 1 ms or more. From captures, the time between the host sending its poll (to address 03:09:bf:00:00:00) and its ack (to address 03:09:bf:00:00:03) is about 1 ms. I think the client's reply has to come consistantly between these. Looking at captures where a DS is the client it produces a reply in less than 500 microsecond every time. So unless somebody knows how to reduce the latency of the kernel I a bit stumped as to how to proceed (this is all assuming that I am sending the right kind of reply to the host - I pretty sure I am but you never know) without generating replies at the driver/ieee802.11 stack and, therefore, within the kernel and triggered by the reception of a packet.

shadowofdarkness:
Sounds like your missing or have odd include files in /usr/include and /usr/include/linux. For example, PACKET_ADD_MEMBERSHIP is defined in /usr/include/linux/if_packet.h and ETH_P_ALL is defined in /usr/include/linux/if_ether.h on my machine. I do not know how you go about getting the correct includes with Linux from scratch as the kind people at Debian sort all that out for me.

masscat wrote:

So unless somebody knows how to reduce the latency of the kernel

These suggestions and queries may be crude or inaccurate, and reflect my limited knowledge of such issues, but they're the best I can offer.

I would assume you'd want the "pre-emptible kernel" options off, minimize (or eliminate) file I/O while the WMB client is operating, turn swap off... Other than that I don't know. But obviously this is getting closer and closer to the point of "impractical without kernel integration" so no one should fault you if you don't continue.
_________________
---GEC
I think that all the work that's been done by the homebrew community so far to support people who want to program for the GBA or DS is amazing.
Thank you, everyone, I look forward to taking advantage of your work.

tetsujin wrote:

"impractical without kernel integration"

I have come to that conclusion as the latency needs to be reduced by an order of magnitude.

As for kernel integration, I have been playing around in the rt2570 driver and have managed to get it to assoicate with a DS whilst the interface is in "managed" mode, like it would with a normal access point. This is not reliable yet but when it is I stick the driver on my website and post here. I should be able to do the change for the rt2500 too as the code is pretty similar. I cannot make any guarantees it will work for the rt2500 as I have no hardware.

If everything works as I hope this will allow the PC to talk to the DS and all the ieee802.11 stuff will be done for us. No more forming 802.11 frames, just send and receive the Nintendo data packets.

PS I had been wondering why data frames were sent to strange addresses (03:09:bf:00:00:00, 03:09:bf:00:00:03 and 03:09:bf:00:00:10). Well I just found out that these are multicast addresses and will therefore be picked up and used by any wireless station within the same BSS. I thought I was going to have to hack the driver to recognise them. You learn something new every day.

UPDATE: Well things are not going quite as I hoped. Things went well with the association and the PC will happily associate and the DS starts sending its data frames and you can send and receive data at the app level without worrying about 802.11 stuff, so all good there. The downside is that I do not think that the driver supports being CF-Polled. So a bit of hacking later and it now sends data when polled. Now I am finding it does not send the response out quickly enough (it is down to 500 microseonds and it needs to be about 200). I have posted on the rt2x00.serialmonkey site asking if anybody knows how to get the driver/hardware latency down or any other advice.
I think I will have a break from the client side for a while and work on the host again for a bit :).

EDIT: By popular demand (Pylot asked for it) I have put the driver source up on my website.

masscat wrote:

I have seem RSA response frames from the client that have values other than 0x01 in then fourth byte. I do not know why it varys.

Figured it out. The RSA response is only valid up to the third byte giving a message of 04,81,08. The rest of the data is just what happened to be sitting in the DS's messge buffer at the time of the send. This will be the sequence number from the last id message it transmitted and will therefore you will see values of 00, 01, 02, 03, and 04.
This resending old data can happen with other types of response where the bytes are not used and therefore not overwritten.

I just finished this for my computer and thought more people may like it to use your card for both wmb and normal internet surfing. Just save it as rt2500.sh and run to see it's paramaters.

[code]
#!/bin/sh
# Script by shadowofdarkness
# Script starts with variables that may need changing on your end

export NIC=ra0
export SSID=linksys
# Whatever you have set
export WEPKEY=xxxxxxxxxxxxxxxxxx
# If you don't have this setup the SET IT UP or use a different encryption but USE encryption
export NICK=LinuxRT2500
# Whatver you want not much uses it
export WLANCHANNEL=6
# Leave it 99% of the time
export IP=192.168.0.11
# Static only I don't know how to get it to use DHCP
export ROUTER=192.168.0.1
# May need to change the 0 to a 1
export PATH=$PATH:/usr/local/sbin/
# My Install doesn't parse /etc/profile when using "su" so I have to add this

case "$1" in
startwmb)
modprobe rt2500
iwconfig $NIC mode monitor
ip link set $NIC up
iwconfig $NIC rate 2M fixed
iwpriv $NIC set WirelessMode=1
iwpriv $NIC set TxRate=2
iwpriv $NIC set TxPreamble=1
iwpriv $NIC rfmontx 1
ifconfig $NIC promisc
iwconfig $NIC channel 13
;;

startwlan)
modprobe rt2500
iwconfig $NIC mode managed
iwconfig $NIC essid $SSID
iwconfig $NIC rate auto
iwconfig $NIC channel $WLANCHANNEL
iwconfig $NIC nick $NICK
iwconfig $NIC key restricted $WEPKEY
ifconfig $NIC $IP broadcast 192.168.1.255 up
route add default gw $ROUTER $NIC
;;

stop)
ifconfig $NIC down
rmmod rt2500
;;

restartwmb)
$0 stop
sleep 1
$0 startwmb
;;

restartwlan)
$0 stop
sleep 1
$0 startwlan
;;

*)
echo "Usage: $0 (startwmb|startwlan|restartwmb|restartwlan|stop)"
echo ""
echo "restart* can be used to switch from wmb to wlan and reverse or just to start fresh in current mode"
exit 1
;;
esac
[/code]

I have been playing around changing what gets sent to the DS.

If anything is changed in the nds header then my non-flashme DS fails to run the download, i.e. it stops with the nintendo logo partially faded. This happens even if the CRCs for the logo and entire header are recalculated. Therefore I am assuming that it must be failing the RSA signature test and this RSA check is done over the nds header, arm9 and arm7 binaries. Now if only the RSA frame is changed (the exe addresses) my DS runs the download i.e. the logo fades completely but from the wrong start address (the demo does not start). Unfortunately I do not have a gba flash cart so I do not know if this can lead to wifime.

So, I believe, beacontest will not allow a non-flashme DS to WifiMe as it is changing the NDS header (RSA fails). Therefore only change the fields in the RSA frame and see what happens.

PS you can get another WMB host implementation off my website - why I did it I do not know.

After messing with beacontest.c for a fiew days I managed to get it to send a working WiFiMe!

The modified file can be found at: http://www.datazap.net/sites/maricle_gaming/libnifi/beacontest.c

and a mirror can be found:
http://www.mariokartds.org/beacontest.c

Just replace the beacontest.c file in libnifi with this one.
As far as I know it only works with the polarium demo but it may work with others.

libnifi can be found at: http://wiki.tbble.net/NintendoDS/Libnifi

EDIT: I got bored and added some cool stuff to libnifi (nothing spectacular just the glider :P) you can find that at:

chttp://www.datazap.net/sites/maricle_gaming/libnifi/libnifi_bootme.tar

This now uses Masscats safer way of doing things with the header(below) and should work with any of the official demos that have the proper RSA keys.

Thanks to:
Tbble (for making libnifi)
Masscat (for realizing the rsa was the key(hehe))
and Rusty (for the mirror)

Last edited by labret on Mon Feb 06, 2006 1:04 am; edited 3 times in total

Hooray, good work labret, have to find myself a flash cart and do a bit of game development now.

Just curious labret, why are you writing the patched execution addresses into the nds file map at all? This should be alright as all the nds files I have looked at appear to have a gap from about offset 0x160 to 0x4000 as they are layed out just as the ROM would be, but that is not guaranteed (I think).

A safer way might be something like:

Code:

const uint8_t arm9_exe_patch[] = { 0x04, 0xfe, 0x7f, 0x02};
const uint8_t arm7_exe_patch[] = { 0xc0, 0x00, 0x00, 0x08};

memcpy( ndsrsa + 7, arm9_exe_patch, 4);
memcpy( ndsrsa + 11, arm7_exe_patch, 4);

But the main thing is it works, happy linux NDS development everyone.

EDIT forgot to ask the following:

I am a little confused over the WMB transfer process. When two DS are talking to each other they use a maximum size of 0x80 16bit words in the payload of the nds header, arm9 and arm7 data. But if I reduce my payload size to this (from 0xff) the the DS will say it has completed before all the data has been sent. The DS accepts the same number of packets as if the payload size was 0xff. Does anybody know how the DS is determining the expected payload size? It does not seem to be taking note of the field in the data message.

I was playing arround with the addresses untill I found some that worked and I just uploaded it like that :)

Well I got myself a GBAMP and a 256MB flash card (Crucial) but I cannot get it to wifime using labret beacontest-bootme. I get two white screens and nothing else.

My DS firmware is V3 (dark green screens)
I flashed the GBAMP with chishm's patch 2.11 (is there any way to tell if this is correctly installed othere than by the "now safe to turn your computer off" message?).
I have the flashme.nds installed on the root of the CF card as _BOOT_MP.nds (nothing else on the card).
I am using a rt2570 usb wireless adaptor but that should not matter as the transfer seems fine.

Any clues? Have others been successful, under linux, with a similar setup?
I am off to cry into some milk.

Ben

UPDATE: If I do the wifime thing with no CF card in the GBAMP then it boots to the MP's "no cf card" warning message, so it looks as though my problem is the CF card.

UPDATE2: After a bit of hacking around with the GBAMP firmware patch it appears that ARM9 is not doing what it should be (executing from the wrong address?) as the ARM7 code does not get passed the wait for the first reset memory ARM9 stuff.

UPDATE3: Controlling the ARM9: the arm9 jumps off and starts executing code from a strange address (0x027fe904). Having looked at firefly's wifime data this is actually the end of the RSA signature so the end of the signature has to be patched to be valid ARM9 code. So here is a change to beacontest.c (labret's version) to acheive this (copied from firefly's data), find the arm exe patch and replace it with the following:

Code:

const uint8_t arm9_exe_patch[] = { 0x04, 0xe9, 0x7f, 0x02};
const uint8_t arm7_exe_patch[] = { 0x00, 0x00, 0x00, 0x08};

memcpy( ndsrsa + 7, arm9_exe_patch, 4);
memcpy( ndsrsa + 11, arm7_exe_patch, 4);

/* Copy some ARM9 code into the end of the RSA signature frame */
const uint8_t arm9_rsa_code[] = {
0x0c, 0x00, 0x9f, 0xe5, 0x0c, 0x10, 0x9f, 0xe5,
0x00, 0x10, 0x80, 0xe5, 0x00, 0x10, 0x90, 0xe5,
0x11, 0xff, 0x2f, 0xe1, 0x24, 0xfe, 0x7f, 0x02,
0x10, 0xe9, 0x7f, 0x02
};
memcpy( ndsrsa + 7 + 0xc4, arm9_rsa_code, sizeof( arm9_rsa_code));

This still does not work for me but the GBAMP patch gets further and I think my problem is with the nds file on the cf card.

UPDATE 4: IT WORKS!! I copied moonshell (very nice - listening to my ogg files) onto the CF card and now I have homebrew working :). You can then flashme or do whatever else from there, just copy the nds files over onto the CF card. I have updated my WMB host with the changes above and it will go up on my website soon.

UPDATE 5: My WMB is up on my website - I borrowed your glider labret :)

WOW! I'm so glad you guys cracked it! This is very good news!

I would test it but no versions of beacontest seem to work any more with my DS. Not sure what it is.

beacontest isn't getting past "wlan initiated" and the DS isn't getting past "Looking for software..."

Anywhoo... nice work people!

Tested your WMB app and it seems to work perfectly... however I have a Nintendogs DS (yellow screen in Pictochat test) and it seems that WifiMe doesn't work with its firmware version (correct me if i'm wrong). Looks like my only alternative now is a passthrough device.

Was looking forward to this day... and my DS doesn't even support it :-(

Great work nonetheless.

masscat can you try to make some static binaries of your programs as I would like to try them but I am getting errors when trying to compile.

masscat wrote:

UPDATE 4: IT WORKS!! I copied moonshell (very nice - listening to my ogg files) onto the CF card and now I have homebrew working :). You can then flashme or do whatever else from there, just copy the nds files over onto the CF card. I have updated my WMB host with the changes above and it will go up on my website soon.

UPDATE 5: My WMB is up on my website - I borrowed your glider labret :)

Nice! I haven't been able to tinker with beacontest lately and now it seems I've been saved the trouble. Well, I'm sure I'll find some other way to contribute to the community... I guess for starters I can try building your WMB app and running on my hardware... SNESDS, here I come...

(EDIT):
So far with my GBAMP I'm only getting whitescreens with beacontest-bootme. I think I need to try with my normal flashcart - I'm pretty sure I reflashed my GBAMP correctly but using a regular flashcart removes at least one unknown from the equation...

No luck at all with masscat's wmb host - the NDS takes forever to see the beacon (about 3 minutes or something) and then when I try downloading it it almost immediately fails.

(EDIT again):
I was able to successfully boot the homebrew "PicrossDS" from the GBA slot using beacontest-bootme! Hoo-ray! Now I just need to figure out why my GBAMP ain't workin.... :(
_________________
---GEC
I think that all the work that's been done by the homebrew community so far to support people who want to program for the GBA or DS is amazing.
Thank you, everyone, I look forward to taking advantage of your work.

I have a GBAMP, and while my results aren't consistent, I eventually got the bootme variant to work. I had to change one line:
const uint8_t arm9_exe_patch[] = { 0x04, 0xe9, 0x7f, 0x02};
//const uint8_t arm9_exe_patch[] = { 0x04, 0xfe, 0x7f, 0x02};
Apparently the e9 value works for gbamp (at least sometimes) and the fe variant is the only one for others?

LoneTech wrote:

I have a GBAMP, and while my results aren't consistent, I eventually got the bootme variant to work. I had to change one line:
const uint8_t arm9_exe_patch[] = { 0x04, 0xe9, 0x7f, 0x02};
//const uint8_t arm9_exe_patch[] = { 0x04, 0xfe, 0x7f, 0x02};
Apparently the e9 value works for gbamp (at least sometimes) and the fe variant is the only one for others?

I think I'm missing a few key pieces in my understanding of WiFi Passme techniques... Here's my understanding of Passme1:

1: Passme circuit is configured to lie about certain data at certain times so the code will pass RSA check when that happens but still get executed with altered header.
2: Passme inserts an ARM9 instruction into four bytes of the "Game title" field - I don't know how to read ARM9 instructions but from what I understand this is an infinite loop, so probably it's something like "jump to this instruction"
3: Passme inserts new starting execution addresses for both processors - ARM7 to the cartridge slot and ARM9 to the infinite loop in the header.
4: (bootstrapping after Passme): ARM7 code loads data off the GBA cart, then changes the ARM9 instruction in the header to get it out of its loop, then jumps to its own ARM7 code that it just loaded.

Now here's my understanding of the WMB version, based on recent discussions here:
1: Header and code are transmitted intact.
2: RSA block is altered, containing the loop for the ARM9 and the jump addresses for both processors. (This, I assume, is the difference which once caused an early version of WiFiMe to require special bootstrap code different from Passme)
3: NDS does the RSA check on the header and code, but then uses jump addresses from RSA block instead. ARM9 jumps to somewhere in the RSA block(?), ARM7 goes to GBA slot.
4: Bootstrap code, as with Passme. (How does it get the ARM9 out of its loop?)

The reason I'm posting all this is because I'm confused about how you could change the ARM9 address without changing the location of the ARM instruction that gets inserted into the RSA header, and come up with something that works. (But then again, I can't find where in beacontest.c from the bootme version that ARM9 instruction appears... I can see where the ARM9 execution address is set, but not the instruction I'm expecting to see there..) Maybe you've come up with some kind of race condition, where the ARM7 will somehow manage to sometimes capture the ARM9 (which presumably isn't in an infinite loop) before it crashes?

I'm interested in the answers to these questions because I still haven't gotten anywhere with my GBAMP...
_________________
---GEC
I think that all the work that's been done by the homebrew community so far to support people who want to program for the GBA or DS is amazing.
Thank you, everyone, I look forward to taking advantage of your work.

I'm proceeding under five assumptions:

1: My current understanding of WMB Passme (as stated in previous post) is correct on all relevant points. (In particular, that one needs to write not only the address for ARM9, but also some ARM9 instructions which will be loaded into that address.)
2: Somehow by writing a destination address for the ARM9, but not instructions to be loaded there, labret's beacontest-bootme is able to boot from a flash card (where the code to be loaded, including bootloader to load code into RAM and cure the ARM9 is immediately memory-mapped) but not from a GBAMP (where, I'm guessing, the whole thing runs as ARM7 code and allows _BOOT_MP.nds to do that work). I think this may be a race condition under certain circumstances, in which the ARM9 is or is not re-captured before it winds up crashing.
3: The source of the 0x027ffe04 address for the ARM9 was, in fact, a mistake by masscat in manually unpacking and byte-swapping the 0x027fe904 address from his WMB host, or else simply the result of some earlier work - and that the address should be 0x027fe904.
4: Masscat's WMB host implementation does work as he described - in particular, reliably booting from the GBAMP.
5: My GBAMP is correctly flashed and should boot given a fully working Passme technique. (In other words, it's beacontest-bootme that's wrong, not my preparation of the GBAMP.)

I'm attempting to inspect masscat's wifime code and ensure that the corresponding code in beacontest-bootme matches. It's tough because masscat's code is a lot nicer to work with. :) (working by field name rather than offsets, using numeric literals and then byte-swapping them, rather than having four separate bytes, etc...) But here's what I've got so far.

(EDIT): I updated this bit of code in the message to reflect the change to arm7_exe_patch[] which allowed me to successfully boot off the GBAMP. The commentary immediately below this bit of code is for when the line read "...arm7_exe_patch[] = {0xc0, 0x00, 0x00, 0x08};"

Code:

const uint8_t arm9_exe_patch[] = { 0x04, 0xe9, 0x7f, 0x02};
const uint8_t arm7_exe_patch[] = { 0x00, 0x00, 0x00, 0x08};

memcpy(ndsrsa + 7, arm9_exe_patch, 4);
memcpy(ndsrsa + 11, arm7_exe_patch, 4);

/* Hardcode some arm9 code stuff into the header.
(Shamelessly ripped off from masscat's WMB/wifime
implementation by GEC) */
uint8_t arm9_loop_code[] =
{
0x0c, 0x00, 0x9f, 0xe5,
0x0c, 0x10, 0x9f, 0xe5,
0x00, 0x10, 0x80, 0xe5,
0x00, 0x10, 0x90, 0xe5,
0x11, 0xff, 0x2f, 0xe1,
0x24, 0xfe, 0x7f, 0x02,
0x10, 0xe9, 0x7f, 0x02,
};
memcpy((ndsrsa + 7 + 60 + 0x88), arm9_loop_code, 28);

7 corresponds to the 7 bytes that appear in ndsrsa[] before the first data field of masscat's rsa structure. 60 is the number of bytes in the rsa structure before rsa->rsa_data[]. 0x88 is the offset of the first value written to rsa_data by the wifime code in masscat's implementation.

When I try this with a GBAMP with CF cart installed, it gives me white screens. When I try it with GBAMP without CF cart, it seems to switch into GBA mode (showing the Game Boy logo, cropping the lower screen and turning the upper screen off) then gives me the GBAMP program, which complains about lack of CF card. (That's better than I've gotten from beacontest-bootme on GBAMP before...) Booting from the GBA flash cart still works normally with the modified beacontest-bootme. I'll update if I make any progress.

(As usual, thanks to everybody who did all the hard work so I can solve little problems by tinkering. :))

(EDIT): Success! The one detail I missed is the difference in the ARM7 execution address - 0x080000c0 in beacontest-bootme vs. 0x08000000 in masscat's implementation. So thanks to masscat for doing the necessary digging to make his implementation work so I could copy the details and apply them to beacontest... (masscat's wmb app looks nicer but I haven't gotten it to boot anything yet - fixing beacontest seemed an easier project to get my GBAMP going...)
_________________
---GEC
I think that all the work that's been done by the homebrew community so far to support people who want to program for the GBA or DS is amazing.
Thank you, everyone, I look forward to taking advantage of your work.

tetsujin:
Are you tuning your wireless card before running my WMB host? My host does not touch any of the wireless side of things it just sends/receives raw 802.11 packets to/from the interface. Once you have tuned the card you must use the same channel number when running the WMB host (-c option) as the channel number is placed in the beacons and if it is not the same it will cause the DS to tune away from the channel that the WMB host is actually transmitting on as soon as you start the download.
Also I only have a rt2570 based wifi adaptor but I do not see how the rt2500 would not work too. I am interested to see if my host works on your (and other peoples) setup.
For rt2500 adaptors you should be able to setup the card using the rt2500.sh scripts from libnifi.

Other things:
The execution addresses of 0x027fe904 (ARM9) and 0x08000000 (ARM7) are taken from the rsa.bin file that Firefly uses in his Windows WMB host to do WifiMe. As is the ARM9 machine code stuck on the end of the RSA frame. I understand the ARM7 address is the start of the GBA cart ROM. The ARM9 address is (I believe - otherwise how would it work?) the end of the RSA header (the patched machine code).
The machine code in the RSA header (I am assuming this as I have not decoded the machine code) patches the value at address 0x027FFE24 to an address within the RSA machine code. The code at this address loads the PC with the value stored at 0x027FFE24, hence it loops.
The address of 0x027ffe04 was actually copied from the original beacontest code I saw. It is later used by the GBAMP firmware patch to hold the ARM9 in a loop which is maybe from where it originated.
As for how the ARM9 gets out of the loop here is and extract from the GBAMP firmware patch which runs on the ARM7:

Code:

(*(vu32*)0x027FFE24) = (u32)TEMP_MEM; // Make ARM9 jump to the function

By writing to the address 0x027FFE24 the ARM9 will load its program counter with the address written, allowing it to branch to other code.

If you are interested in ARM machine code do a google search for "arm ddi 0100e" which should return you some links to a pdf of the ARM Architecture reference manual which has such things in it.

masscat wrote:

tetsujin:
Are you tuning your wireless card before running my WMB host? My host does not touch any of the wireless side of things it just sends/receives raw 802.11 packets to/from the interface. Once you have tuned the card you must use the same channel number when running the WMB host (-c option) as the channel number is placed in the beacons and if it is not the same it will cause the DS to tune away from the channel that the WMB host is actually transmitting on as soon as you start the download.
Also I only have a rt2570 based wifi adaptor but I do not see how the rt2500 would not work too. I am interested to see if my host works on your (and other peoples) setup.
For rt2500 adaptors you should be able to setup the card using the rt2500.sh scripts from libnifi.

I don't think I've made a mistake with the channel setting when running your program. I used the same wireless card tuning that I used for beacontest:

Code:

iwconfig $1 mode monitor
ip link set $1 up
iwconfig $1 rate 2M fixed
iwpriv $1 set WirelessMode=1
iwpriv $1 set TxRate=2
iwpriv $1 set TxPreamble=1
iwpriv $1 rfmontx 1
ifconfig $1 promisc
iwconfig $1 channel $2

Where $1 is ra0 and $2 is 13

Then I run:
wmb ~tetsujin/NDS/demos/famicom_wars_ds_demo_jap.nds -i ra0 -c 13

The DS is then "looking for software" for about three minutes (I timed it this time) before finding the beacon. The DS then almost immediately gets a communication error, while the wmb app gives me this:

Code:

Client 00:09:bf:4f:d9:0c has been authenticated
Client 00:09:bf:4f:d9:0c is now associated -- data exchange beginning shortly
wmb_data: Client 00:09:bf:4f:d9:0c has been waiting 1.000000 seconds - begining download
wmb_data: Got hello reply
wmb: Client 00:09:bf:4f:d9:0c has been idle for too long and has been removed

I don't know why it would work on the RT2570 and not the RT2500. That's why I decided to fix beacontest instead of the wmb app. :) Maybe now that I've got beacontest working I can look into why your wmb app isn't working on my setup. Either I'll find a misconfiguration on my end or I'll find a way to change your code to make it work.

Curiously, when beacontest runs it seems to give garbage numbers when telling me what channel it's on ((1) sometimes, (-2) this time.) - though it appears it's hardcoded for channel 13, and appears to set the channel itself - and it works. I've tried feeding -c 1 to your wmb app and it still gets the same results.

Quote:

Other things:
The execution addresses of 0x027fe904 (ARM9) and 0x08000000 (ARM7) are taken from the rsa.bin file that Firefly uses in his Windows WMB host to do WifiMe. As is the ARM9 machine code stuck on the end of the RSA frame. I understand the ARM7 address is the start of the GBA cart ROM. The ARM9 address is (I believe - otherwise how would it work?) the end of the RSA header (the patched machine code).

Yeah, figured as much. Thanks for the confirmation, though. My guess for how beacontest-bootme was working is "random chance" or some kind of favorable race condition.

Quote:

The machine code in the RSA header (I am assuming this as I have not decoded the machine code) patches the value at address 0x027FFE24 to an address within the RSA machine code. The code at this address loads the PC with the value stored at 0x027FFE24, hence it loops.
The address of 0x027ffe04 was actually copied from the original beacontest code I saw. It is later used by the GBAMP firmware patch to hold the ARM9 in a loop which is maybe from where it originated.

Ah, I was wondering how the same boot code could be used even if the initial ARM9 address was different... That makes sense.
_________________
---GEC
I think that all the work that's been done by the homebrew community so far to support people who want to program for the GBA or DS is amazing.
Thank you, everyone, I look forward to taking advantage of your work.

tetsujin:
Sounds like your adaptor is not tuning properly using the rt2500.sh script, as the only difference I can see between beacontest and my host is that beacontest sets the channel when it runs. And, yep, beacontest is hardcoded to channel 13.

The strange numbers beacontest prints for the channel it is using may point to a conflict between versions of wireless extensions installed. I have version 27 (with some of 28 if I understand the debian package correctly) of both the library and development files. My iwconfig reports itself as version 28 (iwconfig --version).

If you are using debian the packages (and their versions) are: libiw-dev (27+28pre10-1), libiw28 (27+28pre10-1), wireless-tools (27+28pre10-1)

One other thing you could try is run the following commands which is how I set up my adaptor with the only addition of the TxPreamble as this is not supported by the rt2570. I am taking the interface down to try and start with a blank slate:

Code:

ifconfig ra0 down
ifconfig ra0 up
iwpriv ra0 set TxPreamble=1
iwpriv ra0 rfmontx 1
iwconfig ra0 mode monitor channel 13 rate 2M

Of cause I could be doing something silly in my code :)

PS Has anybody run my WMB host using a rt2500 card?

EDIT: SILLY CODE MISTAKE: I was zeroing beyond the end of a structure which may do very strange things. Fixed in version 0.2.2.

Last edited by masscat on Wed Feb 08, 2006 9:43 pm; edited 1 time in total

The code inserted in the signature block is:

Code:

0: e59f000c ldr r0, [pc, #12] ; 14 <arm9_rsa_code+0x14>
4: e59f100c ldr r1, [pc, #12] ; 18 <arm9_rsa_code+0x18>
8: e5801000 str r1, [r0]
c: e5901000 ldr r1, [r0]
10: e12fff11 bx r1
14: 027ffe24 rsbeqs pc, pc, #576 ; 0x240
18: 027fe910 rsbeqs lr, pc, #262144 ; 0x40000

Of course these offsets are wrong. This looks like code to set the loop code up. My weak understanding leads me to think this reads the 14: and 18: lines into r0 and r1, then stores the 18: word in 0x027ffe24 (the familiar loop pointer), loads it again, and branches to that address. I imagine that 0x027fe910 is the intended address of the c: line. This would put the start address of this code at 0x027fe904, which is the address that works for me.

Here's a patch that might work better, as it more closely matches what the PassMe does:

Code:

ldr r0, LoopAddress
ldr r1, PassMeLoop
str r1, [r0, #0x00] @ Write the loop instruction to the header
str r0, [r0, #0x20] @ Store the address of the loop instruction
bx r0 @ Jump to the loop instruction
LoopAddress:
.word 0x027FFE04
PassMeLoop:
ldr pc, . + 0x20

Please note that I haven't tested this exact code (I'm working from memory).
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

masscat wrote:

EDIT: SILLY CODE MISTAKE: I was zeroing beyond the end of a structure which may do very strange things. Fixed in version 0.2.2.

Well, cool! I'll give it a go when I get home and let you know if it works! (If not, then I may be able to provide more assistance later - tonight and tomorrow I am unfortunately rather busy.)
_________________
---GEC
I think that all the work that's been done by the homebrew community so far to support people who want to program for the GBA or DS is amazing.
Thank you, everyone, I look forward to taking advantage of your work.

Hey,

I decided to put a bunch of printf's into wmb.c in order to try and see what it's doing when it's failing to get its beacon to the NDS. I added these lines:

Code:

fprintf(stderr, "wmb.c:429, (not) silently ignoring the frame\n");
fprintf(stderr, "wmb.c:435, checkAddr -> ignore frame\n");

(into the two main silent failure clauses at the end of process_management_frame())

Code:

fprintf(stderr, "wmb.c:751, read_size -> %d\n", read_size);

(after the read_size = read(...) call in main())

Code:

fprintf(stderr, "wmb.c:766, Management frame\n");
fprintf(stderr, "wmb.c:772, Data frame\n");
fprintf(stderr, "wmb.c:778, Unknown frame type %d\n", ieee80211_getFrameType(frame));

(inside case clauses of switch (ieee80211_getFrameType(frame)) {})

The resulting output goes something like this:

Code:

wmb.c:746, read_size -> 188
wmb.c:761, Management frame
wmb.c:432, checkAddr -> ignore frame
wmb.c:746, read_size -> 188
wmb.c:761, Management frame
wmb.c:432, checkAddr -> ignore frame
wmb.c:746, read_size -> 188
wmb.c:761, Management frame
wmb.c:432, checkAddr -> ignore frame

So I guess it's listening for traffic and thinking that nothing it sees is addressed to it. I'm not entirely sure what to make of that, but it's what I've got to share at this point.

(EDIT): I added a printf() inside of ieee80211_sendBeacon(), informing me that the beacon is 188 bytes in size (so the monitoring code is seeing its own beacon?) and confirming that the beacon thinks it's on channel 13. I've not yet been able to verify that the beacon really is on channel 13, I don't know how I would do that if I assume that the command "iwconfig ra0 channel 13" isn't working.
_________________
---GEC
I think that all the work that's been done by the homebrew community so far to support people who want to program for the GBA or DS is amazing.
Thank you, everyone, I look forward to taking advantage of your work.

chishm wrote:

Here's a patch that might work better, as it more closely matches what the PassMe does...

Yes, that works. The difference is that this version uses a single instruction at 0x27ffe04 for the loop, rather than two instructions at 0x27fe910. Also, as it writes this instruction itself, it manages to be independent of where this code is placed.

Code:

const unsigned char arm9_rsa_code[] = {
0x0c, 0x00, 0x9f, 0xe5, 0x0c, 0x10, 0x9f, 0xe5,
0x00, 0x10, 0x80, 0xe5, 0x20, 0x00, 0x80, 0xe5,
0x10, 0xff, 0x2f, 0xe1, 0x04, 0xfe, 0x7f, 0x02,
0x18, 0xf0, 0x9f, 0xe5
};

tetsujin wrote:

(EDIT): I added a printf() inside of ieee80211_sendBeacon(), informing me that the beacon is 188 bytes in size (so the monitoring code is seeing its own beacon?) and confirming that the beacon thinks it's on channel 13. I've not yet been able to verify that the beacon really is on channel 13, I don't know how I would do that if I assume that the command "iwconfig ra0 channel 13" isn't working.

The WMB host should receive all the frames it sends out as the wireless interface is in monitor mode and the driver should not be filtering the packets based on destination address and the like. So it is a good sign that the beacons are coming back (although the hardware does have a loopback feature that can be used to loop frames before they go out on the air but that really should not be enabled - I am sure it is not).

The beacons should be transmitted at a rate of 4 per second. The beacon interval (in microseconds) is set in wmb.c (the #define BEACON_TIME_INTERVAL). If the beacons are not getting transmitted at a reasonable rate (what this is I do not know) the client DS may not pick the advert up. Maybe worth timestamping the printouts of the received frames.
You can change the rate at which data is exchanged between the host and client (during the actual nds header, arm binaries download) by changing the following value in the initHostData function (again in wmb.c):

Code:

/* send data to a client at the following intervals */
/*data->send_interval = 500000;*/ /* FIXME: one/two second for testing*/
/* FIXME: going faster than 20000 tends to kill the rt2570 usb driver */
data->send_interval = 20000;

As you can see I was use an interval of one half of a second during testing.
If you want to print the contents of frames there is a function called printData that will give you out in a nice format.

The only way I can think of confirming that the beacons are actually going out on the correct channel is by capturing the packets using a different interface or another computer.

Thanks for your efforts testing this - I am curious why it is not working.

Edit: I have added a special version of my WMB host that uses the interface setup code from beacontest on my website. If this does not work with rt2500 cards then the problem is something to do with my application logic.

NinWMB_rt2500test.tar.bz

Hi,

Been a while since I've been able to do any testing. I tried NinWMB_rt2500test and I get the same results:I run wmb, NDS sits for a few minutes looking for a beacon. Then it finds it, I try to download it, and immediately the signal strength bars bottom out and the NDS aborts the attempt to download.

I'm not really sure what to look for. I guess my next test should be to try to monitor what my PC is broadcasting. Anybody know of a good tool to do that with an Apple Powerbook? I've not really played around with 802.11 too much before.

(EDIT): Oh yeah: that bit of data I mentioned before that appears on wmb's stderr when the failed download occurs? ("..idle for too long and has been removed", etc..) That only happens sometimes. Other times it doesn't print anything. I'm not sure if that means anything.
_________________
---GEC
I think that all the work that's been done by the homebrew community so far to support people who want to program for the GBA or DS is amazing.
Thank you, everyone, I look forward to taking advantage of your work.

Curiosity has got the better of me and I have got a rt2500 based PCI card.
After playing around with my WMB host it appears that the 802.11 sequence number is not being incremented. The driver for the rt2570 chipset sets up the hardware so that the sequence number automatically increments, this does not appear to be the same for the rt2500. I will implement the sequence number in the host code and see if that helps.

EDIT: Hooray, the sequence number fix is working for me. The fixed code is up on my website (version 0.2.3). Thanks to tetsujin for your willingness to test the host.

The other reason for getting a PCI card is that I believe that the my client driver for the rt2570 will not work because it is USB based (I understand that USB devices cannot interrupt the host - part of the bus specification) so I am going to play around and see if I can get a WMB client working with PCI. More news if things work out.

I have a rt2500 based PCMCIA card and had the same results as tetsujin. This latest version works fine on my hardware.. Thanks for your work on this.

Yeah, right on! Excellent work with all this stuff all around. I'll try the updated WMB host as soon as I get a chance. I wish I could've been more helpful but I'm just happy both apps (that is, both WMB hosts) are working now. So now you're looking to post the WMB host (and client) to the NDS itself? Excellent! Perhaps testing some of that stuff will be the excuse I need to buy a DS Lite. :)
_________________
---GEC
I think that all the work that's been done by the homebrew community so far to support people who want to program for the GBA or DS is amazing.
Thank you, everyone, I look forward to taking advantage of your work.

masscat wrote:

USB based (I understand that USB devices cannot interrupt the host - part of the bus specification)

They sort of can, but only with a tiny message, when given the opportunity. Mice and keyboards communicate mostly like this. For network chips, though, that means it sends a "got something" message when allowed, and then the computer has to go fetch the data when it gets around to it. Latency isn't the best, as you might imagine.

LoneTech wrote:

masscat wrote:

USB based (I understand that USB devices cannot interrupt the host - part of the bus specification)

They sort of can, but only with a tiny message, when given the opportunity. Mice and keyboards communicate mostly like this. For network chips, though, that means it sends a "got something" message when allowed, and then the computer has to go fetch the data when it gets around to it. Latency isn't the best, as you might imagine.

USB "Interrupt Transfers" (if that's what you're referring to) are actually the host polling the device. Although the receipt of data from one of these could be treated on the host side as an interrupt, I think calling it an interrupt is a stretch at best. (I think the term "Interrupt Transfer" is reasonable only in the sense that that's the functionality it's meant to approximate...)

masscat: I don't know why I didn't think of that. Of course a USB ethernet adaptor will have latency issues... I expect you could probably adjust the driver to make it poll more frequently, but probably the best rate you'd get is one poll per 1ms. It'll be cool if it turns out that the OS-level latency issues are minor enough that a PCI adaptor can work... Let me know if I can help, or maybe I'll just try to help when I have some time. (I really ought to try to get my hands deep enough into this thing that I can actually understand what's going on... that's the point at which I might actually be able to make meaningful contributions.
_________________
---GEC
I think that all the work that's been done by the homebrew community so far to support people who want to program for the GBA or DS is amazing.
Thank you, everyone, I look forward to taking advantage of your work.

^pure knowleage nice ^_^ yeah will USB's be supported soon or at all?

I cannot believe I have missed this topic for so long.

I noticed in the first 6 pages or so, some people were talking about RTL8180 cards, which is all that I have, but later on, it moves back to the programs being RTL2500 only, as usual.

Is is possible to get this working with an RTL8180 card? I tried masscat's program just now, but given the errors it came back with, it is not happy with the card.

TJ wrote:

Is is possible to get this working with an RTL8180 card? I tried masscat's program just now, but given the errors it came back with, it is not happy with the card.

What errors is the host coming out with? See if you get more luck with beacontest.

The linux versions of WMB hosts are not actually tied to particular driver/adaptor but use the interface provided by the OS to send/receive raw 802.11 frames on and off of the air. So if a driver/adaptor combination provide the required features to be able to talk to a Nintendo DS then they should work with the WMB hosts. These features are short preamble, a rate of 2M and the ability to transmit frames whilst in monitor mode. Currently I only know of the rt25x0 ralink driver/hardware combination that provide this (and only the rt2570 by a hacked version of the driver), but I have not investigated other hardware as I do not have access to it.
802.11b cards are unlikely to support short preamble as it was optional in the spec so therefore left out of most implementations (apparently).
If your card is supported by the aireplay application then it shows it supports transmitting whilst in monitor mode.
My WMB host does not support drivers that pass/expect frames with PRISM headers or any other sort of additions to the frames. I think beacontest supports PRISM headers.

The linux 802.11 stack is in a period of change at the moment and as a result of this it should prove less work to write drivers so in the future this could mean more and better wireless hardware support.

ultimateadvantage wrote:

^pure knowleage nice ^_^ yeah will USB's be supported soon or at all?

For WMB hosting, rt2570 based USB adaptors are supported right now with the hacked driver from my website.
For WMB clienting, I do not believe any USB adaptor will work because of latency issues. Whilst playing around with USB I found an interval of 500 microseconds between receiving of a frame and transmitting the reply and this could not be reduced. This, I believe, is because of the poll interval of the USB device by the controller.

ooo i c. so RT2570 based USB's wont work for clienting....crap! o well i should be happy that it can be a host :/

masscat wrote:

ultimateadvantage wrote:

^pure knowleage nice ^_^ yeah will USB's be supported soon or at all?

For WMB hosting, rt2570 based USB adaptors are supported right now with the hacked driver from my website.
For WMB clienting, I do not believe any USB adaptor will work because of latency issues. Whilst playing around with USB I found an interval of 500 microseconds between receiving of a frame and transmitting the reply and this could not be reduced. This, I believe, is because of the poll interval of the USB device by the controller.

what is your website?

See that little button with a picture of a house and "www" text below masscat's post?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

Quote:

These features are short preamble, a rate of 2M and the ability to transmit frames whilst in monitor mode. Currently I only know of the rt25x0 ralink driver/hardware combination that provide this (and only the rt2570 by a hacked version of the driver), but I have not investigated other hardware as I do not have access to it.
802.11b cards are unlikely to support short preamble as it was optional in the spec so therefore left out of most implementations (apparently).
If your card is supported by the aireplay application then it shows it supports transmitting whilst in monitor mode.

Well, I know for a fact my card has no problem running in 2 Mbps mode, as I use it for a soft AP to get online with the DS, and have it set for 2 Mbps in my soft AP script.

The RTL8180 is also supported by aireplay with the patched drivers (perhaps that is the problem, I am using the OSS drivers, but not patched).

The last one might be a problem, I don't know off hand if this card supports short preamble, but it is a 802.11b card, like you said, so there is a good chance it doesn't.

I'll get back on that machine and try to ascertain if it can do preamble, and copy the exact errors it gives me.

I have made some progress.

Using the patched drivers from Aircrack, and manually setting some values with iwconfig (Rate 2M, Channel 11, Monitor mode) I can now load up one of the E3 demos (Meteos), and the program starts up with it.

Going to the DS, I can actually see the download! But when I select it, it starts the transfer for about 1 second, and then says there is a communications error.

On the laptop, I see that the DS has authenticated, and then after I get the error on the DS, wmb shows "wmb:DSMAC has been idle for too long, and has been removed".

I am very close now, do you have any idea what could be causing it to fail? I had seen a few posts back about problems with preemptive kernels, could this be a result?

TJ:
I have looked at the posts regarding the RTL8180 on page 7 of this topic and it sounds like Haiken got to the same point as you using the beacontest WMB host. I could not tell from the posts if the problem was resolved or not (might be worth PMing Haiken to see what happened).
Capture the wireless packets (using Ethereal or tcpdump) whilst running the host and see if the host and the DS are sending any data frames after the association frames. Having looked at the aireplay code certain cards need headers stuck on the front of frames for transmit - I am not sure if this applies to the RTL8180 card and as the beacons frames appear to be getting out ok I would have thought not.
I am working on a change to my host to allow it to dump transmitted and received frames to PCAP files. It may be useful to compare what the host thinks it is transmitting to what actually gets on the air. I will post when it is on the website.
Also, make sure you are using at least version 0.2.3 of the WMB host.

EDIT: The PCAP dumping host is up on the website (version 0.3.1).

FWIW I just tested the Feb. 20 version of your WMB host, Masscat, and was able to run it and boot with its wifime-mode. (yay!) With that test concluded, I've done Flashme now, so I don't know how useful my DS will remain as a test.

(EDIT): OK, I got one for you... Now that my DS is flashed I'm trying to send things that I couldn't send before - homebrew and unsigned stuff. Some of these like OMalone work, others, like Sushi the Cat, don't. The ones that don't give me this kind of message:

Code:

Client 00:09:bf:4f:d9:0c has been authenticated
Client 00:09:bf:4f:d9:0c is now associated -- data exchange beginning shortly
wmb_data: Client 00:09:bf:4f:d9:0c has been waiting 1.000000 seconds - begining download
wmb_data: Got hello reply
wmb_data: Name complete - client is "fdX "
wmb_data: Got response to RSA
Idle complete 10
wmb: Client 00:09:bf:4f:d9:0c has been idle for too long and has been removed

Strange DEAUTH from 00:09:bf:4f:d9:0c

I can't do the self-capture right now but I'll see about it when I have some time.
_________________
---GEC
I think that all the work that's been done by the homebrew community so far to support people who want to program for the GBA or DS is amazing.
Thank you, everyone, I look forward to taking advantage of your work.

Yep, Sushi does not download with my DS either (non-flashme).
It looks as though the NDS header on the Sushi file is not properly formed (the ROM size field is set to zero). This stops the WMB host from reading it (it thinks it will read beyond the end of the file).
Doing a fix to use the file size instead of the ROM size field. Will put some error handling in too so it does not just silently not send the data.
I will edit this post when it is up.

EDIT: The Sushi fix is now in (version 0.3.2).

I am having a problem with my rt2500 card. When my PC first boots up the card does not seem to want to send out or receive frames when in monitor mode. I can resolve the problem by bringing the interface down, removing the module (rt2500) and then modprobing the module back in again.

The sequence of commands I use for bringing the interface up is as follows:

Code:

iwpriv ra0 rfmontx 1
iwpriv ra0 set TxPreamble=1
iwconfig ra0 mode monitor
ifconfig ra0 up
iwconfig ra0 channel 13 rate 2M

EDIT: fixed typo in code, it is now the command sequence I use.

EDIT:
More updates to the host (now version 0.4). This version has better data block transfer code so should stop the host thinking the transfer is complete and the DS not restarting.

Heya,

i'm currently testing this on a D-Link G650+,

Alltho i needed to change a line in the sourcecode to make it working (changed that the wrong arp-type is a warning, as my dlink is falsely reporting itself as type 0 instead of 801.

Now i can receive the beaons (= Entry in the gamelist) on my NDS, but there is no sign of any transfer on the ds nor the app. Does anyone know what could cause this behaviour?

I think the raw frame sending functions seem to work as it is showing up in the gamelist. Any help would be just great. (Need to reflash my gbamp *g* to homebrew proper again)

Thanks
Mighty Max

:edit: Ok, i got it to recognize the DS wanting to download. (Solution: install libpcap >= 0.7)

im now getting this:

Code:

man_log: Client 00:09:bf:4b:b0:78 has been authenticated

man_log: Client 00:09:bf:4b:b0:78 is now associated -- data exchange beginning shortly
wmb_data: Client 00:09:bf:4b:b0:78 has been waiting 1.000000 seconds - begining download
wmb: Client 00:09:bf:4b:b0:78 has been idle for too long and has been removed

man_log: DEAUTH from a strange station 00:09:bf:4b:b0:78

_________________
GBAMP Multiboot

What chipset does the G650+ use and what driver does it use under linux?

The problem sounds similar to that of people using RTL8180 based cards (see a few pages back) and I do not know if that got resolved by anybody. So if you can resolve this you could be helping many people.

I do not understand the need for a new pcap library as the wmbhost is not linked with it but then if it works then so be it.

The DS will sit there waiting until it receives a data frame from the wmbhost. So the wmbhost is either not transmitting frames or the replies from the DS are not coming back to the host.
Have a play around with the -p option (dumps pcap format files of tx and rx packets as seen by the wmbhost app - these can be loaded into the ethereal app) and see if the host thinks it is transmitting data and what it is seeing back (it should see its own packets if they are getting on to the air).
If you can, use another PC to capture frames to see what is actually on the air.

Good luck

Ben

The chipset of the D-Link G650+ is a Texas Instrument TNET1130.

It works perfectly with the open source ACX111 drivers found at http://www.hauke-m.de/menue1/computer/acx100-acx111.html

Reproduction (if anyone wants to try himself):
- booted Knoppix (Linux Live CD - sep 2005)
- installed pcap 0.9.4 (0.6 is preinstalled but does not implement arptype 801 sockets)
- compiled & loaded acx module
- set params to the wlan device

Code:

iwpriv wlan0 SetSPreamble 1 1
iwpriv wlan0 monitor 1 1
iwpriv wlan0 monitor 2 1
iwconfig wlan0 mode monitor
ifconfig wlan0 up
iwconfig wlan0 channel 13 rate 2M

- compiled the wmb
- ./wmbhost/wmbhost -i wlan0 -c 13 ndsmp.nds

After that you can startup your DS in wireless menu & select the download. Is associates with the wmb application, but never accepts any transfer data.

I've only checked the data that is received locally. The data packets send are occuring, as well as ACK frames from my DLink. But that is about it, there does not seem to come any ACK from the DS nor any data type frame.

My guess it that i set the monitor mode wrong, so that those packets are just not passed through, but i'm a noob to wlan on linux.

Got no other machine to just sniff from the air.

Gonna check further ...
_________________
GBAMP Multiboot

gbadev.org forum archive

DS Flash Equipment > WMB for Linux?

#46558 - blasty - Mon Jun 27, 2005 12:02 pm

#46562 - tepples - Mon Jun 27, 2005 1:10 pm

#46567 - Tosh - Mon Jun 27, 2005 3:05 pm

#46571 - Ilomoga - Mon Jun 27, 2005 3:43 pm

#46586 - blasty - Mon Jun 27, 2005 6:33 pm

#46712 - bagu - Wed Jun 29, 2005 7:45 am

#46738 - gl0b - Wed Jun 29, 2005 9:58 pm

#46739 - gladius - Wed Jun 29, 2005 10:54 pm

#46748 - FourScience - Thu Jun 30, 2005 2:26 am

#46756 - mrnull - Thu Jun 30, 2005 5:31 am

#46779 - blasty - Thu Jun 30, 2005 2:49 pm

#47077 - philip - Mon Jul 04, 2005 9:45 pm

#47117 - blasty - Tue Jul 05, 2005 11:02 am

#47485 - philip - Sat Jul 09, 2005 3:39 pm

#47486 - nikarul - Sat Jul 09, 2005 4:36 pm

#47492 - philip - Sat Jul 09, 2005 5:32 pm

#48062 - pixxel - Sat Jul 16, 2005 7:51 pm

#48066 - philip - Sat Jul 16, 2005 10:17 pm

#48099 - pixxel - Sun Jul 17, 2005 3:46 am

#48113 - nikarul - Sun Jul 17, 2005 6:21 am

#48589 - philip - Wed Jul 20, 2005 11:02 pm

#48591 - tepples - Wed Jul 20, 2005 11:35 pm

#48600 - Sausage Boy - Thu Jul 21, 2005 12:14 am

#48611 - mocnicom - Thu Jul 21, 2005 4:53 am

#48618 - nikarul - Thu Jul 21, 2005 5:38 am

#48622 - [FireFly] - Thu Jul 21, 2005 6:45 am

#48880 - nikarul - Sat Jul 23, 2005 5:12 pm

#48886 - [FireFly] - Sat Jul 23, 2005 5:37 pm

#48888 - tepples - Sat Jul 23, 2005 7:30 pm

#48937 - philip - Sun Jul 24, 2005 12:01 pm

#49114 - nikarul - Tue Jul 26, 2005 5:29 pm

#49115 - [FireFly] - Tue Jul 26, 2005 5:35 pm

#49184 - nikarul - Wed Jul 27, 2005 5:12 am

#49196 - [FireFly] - Wed Jul 27, 2005 7:19 am

#49493 - [FireFly] - Sat Jul 30, 2005 8:20 am

#49497 - davine - Sat Jul 30, 2005 12:32 pm

#49498 - davine - Sat Jul 30, 2005 12:41 pm

#49502 - [FireFly] - Sat Jul 30, 2005 3:44 pm

#50484 - nikarul - Wed Aug 10, 2005 4:29 am

#50657 - davine - Thu Aug 11, 2005 1:00 pm

#50686 - nikarul - Thu Aug 11, 2005 8:02 pm

#50694 - davine - Thu Aug 11, 2005 9:23 pm

#50702 - Sausage Boy - Thu Aug 11, 2005 10:51 pm

#50734 - davine - Fri Aug 12, 2005 2:21 pm

#50735 - Sausage Boy - Fri Aug 12, 2005 2:50 pm

#50740 - davine - Fri Aug 12, 2005 3:19 pm

#50761 - mocnicom - Fri Aug 12, 2005 7:39 pm

#50767 - nikarul - Fri Aug 12, 2005 8:25 pm

#51434 - [FireFly] - Fri Aug 19, 2005 3:33 pm

#51436 - nikarul - Fri Aug 19, 2005 4:06 pm

#51439 - davine - Fri Aug 19, 2005 4:44 pm

#51498 - nikarul - Sat Aug 20, 2005 7:05 pm

#52279 - [FireFly] - Mon Aug 29, 2005 8:18 am

#52324 - [FireFly] - Mon Aug 29, 2005 7:15 pm

#52362 - nikarul - Tue Aug 30, 2005 2:52 am

#52385 - [FireFly] - Tue Aug 30, 2005 1:01 pm

#52457 - davine - Wed Aug 31, 2005 1:59 am

#52469 - nikarul - Wed Aug 31, 2005 3:19 am

#52489 - [FireFly] - Wed Aug 31, 2005 8:11 am

#52584 - nikarul - Thu Sep 01, 2005 4:07 am

#52917 - [FireFly] - Sun Sep 04, 2005 5:25 pm

#53382 - ricbit - Thu Sep 08, 2005 2:09 am

#54272 - Ninja - Sat Sep 17, 2005 12:03 pm

#60186 - nikarul - Mon Nov 07, 2005 11:07 pm

#62279 - cloak - Tue Nov 29, 2005 1:17 am

#62861 - TheKilled. - Tue Dec 06, 2005 3:48 pm

#62994 - TheMikaus - Wed Dec 07, 2005 4:59 pm

#62999 - nikarul - Wed Dec 07, 2005 6:34 pm

#63333 - TBBle - Mon Dec 12, 2005 1:52 am

#63400 - WileEQuixote - Mon Dec 12, 2005 7:42 pm

#63402 - MaHe - Mon Dec 12, 2005 7:46 pm

#63430 - TBBle - Tue Dec 13, 2005 1:26 am

#63490 - TheKilled. - Tue Dec 13, 2005 5:11 pm

#63492 - TBBle - Tue Dec 13, 2005 5:50 pm

#63493 - TBBle - Tue Dec 13, 2005 5:55 pm

#63515 - TheKilled. - Tue Dec 13, 2005 10:10 pm

#63518 - cloak - Tue Dec 13, 2005 10:42 pm

#63636 - nikarul - Thu Dec 15, 2005 5:03 am