dswifi broken in r26?

[eudoxus]

I just returned to using devkitPro after quite a while, and was pleased to see the progress since r20.

Unfortunately, there seem to be issues with dswifi in the latest release. I haven't used any previous versions, so I can't verify it was broken recently, but I don't see any complaints in the forum, and I'm rather sure it isn't my configuration causing the problem.

For example, I have verified that my WFC connection information is valid and that I can connect to my AP by using a proper Wifi NDS game (Zelda Phantom Hourglass), but none of the dswifi examples will connect to my AP. Even using the autoconnect.nds which loads the stored WFC information fails to connect to my access point. I have even tried my AP unsecured and attempting a connecting using the ap_search.nds example, but still could not connect.

I thought it might have been somehow related to my platform (Linux x64), so I tried it in Windows XP as well, with the same results.

Am I missing something? Has this functionality been verified in r26? I am using a NDS Lite, not sure if it matters. Let me know what information if any could help.

Thanks

[eudoxus]

I reinstalled r26 and found that the most recent versions of libnds, dswifi and default arm7 that work are:

libnds-1.3.3
dswifi 0.3.7
default arm7 0.5.2

something got broken between these versions and now.

Let me know if I can be of any help.

[WinterMute]

This works fine with libnds 1.3.4, dswifi 0.3.8 and default_arm7 0.5.3.

Please do not advise people to downgrade or link to old versions of binaries. This causes major support headaches.

[eudoxus]

I downloaded the latest versions of all devkitPro components once again and installed them:

default_arm7-0.5.3.tar.bz2
devkitARM_r26-x86_64-linux.tar.bz2
dswifi-0.3.8.tar.bz2
libfat-nds-1.0.4.tar.bz2
libnds-1.3.4.tar.bz2
maxmod-nds-1.0.5.tar.bz2
nds-examples-20090531.tar.bz2

I immediately went into /opt/devkitPro/examples/nds/dswifi/autoconnect and made the example with no errors.

I copied the autoconnect.nds onto my m3 flashcart, ran it up on my DS Lite, and...

Code: Select all

   Simple Wifi Connection Demo
Connecting via WFC Data ...
Failed to connect!

I went ahead and moved /opt/devkitPro/ to /opt/devkitPro_r26/, then moved my r25 devkitPro directory back to /opt/devkitPro/, went into /opt/devkitPro/examples/nds/dswifi/autoconnect and made the example with no errors.

I copied the autoconnect.nds onto my m3 flashcart, ran it up on my DS Lite, and...

Code: Select all

   Simple Wifi Connection Demo
Connecting via WFC Data ...
Connected

ip     : 10.0.0.4
gateway: 10.0.0.1
mask   : 255.255.255.0
dns1   : 10.0.0.1
dns2   : 0.0.0.0

What would cause this disparity? Especially the disparity between r26 code that you say works fine but definitely refuses to work on my end? Could a difference in DS versions be the culprit? If so, why would r24 work perfectly, r25 work somewhat and r26 seem to be totally broken?

I don't mean to be a bother, and I apologize for suggesting users downgrade... it was just the only solution that worked for me. I'm hoping we can figure out what is going on and resolve this problem.

If you can't recreate the problem on your end we aren't going to make any progress though. This autoconnect.nds example works fine for you? Are you using an original DS? I don't have one myself to test it on... and unfortunately my flashcart is made for DS Lites only.

If any other users here could chime in and let us know how the dswifi examples in the latest devkitPro work for them, it would be good to get verification that it isn't just me.

In the meantime I'll build devkitPro from source and see if I can isolate the source of the problem using diff...

[eudoxus]

Well, I pulled buildscripts from the devkitPro CVS, and managed to get everything built after some small modifications to config/tc-arm.c in gas, which had some errors due to -Werrors and the new GCC.

Unfortunately it seems the version built is from actually from around 12/10/2008, which would correspond with r24. So every thing works fine when using this version.

I dug around in your CVS some more, and looking at the logs, it seems you have stopped updating CVS at the end of 2008? For example latest symbolic name for dswifi is dswifi-0_3_5? Did you guys have to move from CVS to something else because you had too many yahoos like me digging around in there?

Anyway, I'm just here to help. I'll grab the source for the packages straight from the sourceforge pages, and compare them that way.

Cheers.

[melw]

Well, I pulled buildscripts from the devkitPro CVS
...
looking at the logs, it seems you have stopped updating CVS at the end of 2008?

devkitPro has been using svn for quite some time: http://sourceforge.net/scm/?type=svn&group_id=114505

To confirm this is an issue with your DS Lite, and not in your toolchain, can you test whether this autoconnect.nds works or fails on your DS? (compiled with dkA r26 / libnds 1.3.4 / dswifi 0.3.8 - works over here just as it should.)

[eudoxus]

WinterMute, maybe you want to move this thread to the bug reports forum?

melw, thanks for chiming in... that explains why the CVS seemed in repose.

I'm happy to say that I actually found the exact cause of my problems, and it makes total sense as to why no one else is having a problem.

I have MAC address filtering enabled on my wireless router. The bug I isolated in r26 incorrectly writes the bytes read from the firmware into the main WifiData structure. So with my MAC address wrong in this structure, my AP was rejecting the connection because the packet headers had an incorrect MAC that didn't correspond with the correct MAC I pulled from the DS WFC interface when setting my routers' ACL.

Thanks to diff, this wasn't horribly agonizing. Just a bit painful. For reference, I used:

Code: Select all

diff -urNp -x '*svn*'  dswifi-src-0.3.7 dswifi-src-0.3.8 > dswifi.patch

on the two directories to get the differences between the versions, excluding the svn nonsense. It didn't actually strike me at this time that I was looking in CVS previously and the latest source packages are full of SVN tags. Anyway, the important bits of the patch follow.

First in wifi_shared.h:

Code: Select all

@@ -225,17 +225,18 @@ typedef struct WIFI_MAINSTRUCT {
 	u16 curChannel, reqChannel;
 	u16 curMode, reqMode;
 	u16 authlevel,authctr;
-	u32 flags9, flags7, reqPacketFlags;
+	vu32 flags9, flags7;
+	u32 reqPacketFlags;
 	u16 curReqFlags, reqReqFlags;
 	u32 counter7,bootcounter7;
-	char MacAddr[6];
+	u16 MacAddr[3];
 	u16 authtype;
 	u16 iptype,ipflags;
 	u32 ip,snmask,gateway;
 
 	// current AP data
 	char ssid7[34],ssid9[34];
-	u8 bssid7[6], bssid9[6];
+	u16 bssid7[3], bssid9[3];
 	u8 apmac7[6], apmac9[6];
 	char wepmode7, wepmode9;
 	char wepkeyid7, wepkeyid9;

So the MacAddr member of the WIFI_MAINSTRUCT structure was changed to a u16 array from a char array.

Now the juicy part in wifi_arm7.c:

Code: Select all

@@ -885,7 +861,7 @@ void Wifi_Init(u32 wifidata) {
 	// load in the WFC data.
 	GetWfcSettings();
 
-	for(i=0;i<6;i++)  WifiData->MacAddr[i]=ReadFlashByte(0x36+i);
+	for(i=0;i<3;i++)  WifiData->MacAddr[i]= ReadFlashByte(0x36+i) + (ReadFlashByte(0x36+i+1)<<8);
 
 	W_IE=0;
 	Wifi_WakeUp();

This loop doesn't write the data to MacAddr as intended. After the loop, MacAddr is filled with the bytes from the following firmware addresses : 0x36, 0x37, 0x37, 0x38, 0x38, 0x39. The intention is obviously to write the bytes from 0x36, 0x37, 0x38, 0x39, 0x40, 0x41.

changing this line to:

Code: Select all

for(i=0;i<6;i++)  ((char*)WifiData->MacAddr)[i]=ReadFlashByte(0x36+i);

corrects the problem.

After changing this code, rebuilding dswifi and default_arm7, now I can connect to my AP without a problem using r26!

I also found another bug in the code while I was meandering about. In wifi_arm9.c, the function Wifi_GetData(...) is defined as:

Code: Select all

int Wifi_GetData(int datatype, int bufferlen, unsigned char * buffer) {
	int i;
	if(datatype<0 || datatype>=MAX_WIFIGETDATA) return -1;
	switch(datatype) {
	case WIFIGETDATA_MACADDRESS:
		if(bufferlen<6 || !buffer) return -1;
		for(i=0;i<6;i++) {
			buffer[i]=WifiData->MacAddr[i];
		}
		return 6;
	case WIFIGETDATA_NUMWFCAPS:
		for(i=0;i<3;i++) if(!(WifiData->wfc_enable[i]&0x80)) break;
		return i;
	}
	return -1;
}

The line:

Code: Select all

buffer[i]=WifiData->MacAddr[i];

should be:

Code: Select all

buffer[i]=((unsigned char*)WifiData->MacAddr)[i];

I'm glad to have found the problem... I'm surprised that other issues in dswifi didn't arise because of this. At least now I know it wasn't just me, and plugged potential problems from this in the future. Glad to be able to give back to devkitPro.

Just wanted to take this opportunity to thank all you guys, WinterMute, Chishm, Sstair, Joat, et al. You've done a great service to the community by opening up all sorts of new possibilities for owners of the devices targeted by devkitPro.

Cheers.

[eudoxus]

I see these fixes got committed to svn.

Thanks.

[WinterMute]

Thanks for pointing this out, probably never would have noticed without mac filtering.