gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

DS development > DSWIFI Lib with WEP 128 bits support

#108533 - Hermes - Thu Nov 09, 2006 11:09 pm

Hi.

I have finded a little bug in the dswifilib that it did not allow me to connect by WEP 128 bits, 13 bytes ascii and i post the modified fucntion in wifi_arm7.c


Code:

void Wifi_SetWepMode(int wepmode) {
   if(wepmode<0 || wepmode>7) return;
   if(wepmode==0) {
      WIFI_REG(0x32)=0x0000;
   } else {
      WIFI_REG(0x32)=0x8000;
   }
   if(wepmode==0) wepmode=1;
   wepmode&=~4; /* 0->no wep, 1-> 64 bits (5 chr), 2-> 128 bits (13 chr) 3->128 bits (16 chr)*/
   W_MODE_WEP = (W_MODE_WEP & 0xFFC7) | (wepmode<<3);
}



As you can see, only change the line: wepmode&=~4;

In my test i can see if you put the value 1, it work under WEP 64 bits, 5 chars and if you put the value 2, it work under WEP 128 bytes, 13 chars

Here the table of values (without my modification):


0-> no WEEP
1-> 64 bit, 5 chars
2-> 128 bits, 13 chars
3-> I think 128 bits, 16 chars
4-> unknown for me
5-> 64bits, 5 chars
6-> fail
7-> 64 bits, 5 chars

So you can see it is a good idea set to 0 this bit ;)

I am using the Nintendo Wifi USB Conector, modified to be an AP

#108619 - Xgame - Fri Nov 10, 2006 3:42 pm

I have a 3com access point wich work with game but dosen't work with homebrew(it has a 128-bit WEP). I'll try your stuff now!

#108621 - OOPMan - Fri Nov 10, 2006 3:46 pm

Have you mentioned this bug to sgstair?

I'll check and if not, let him know :-)
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI

You can find my NDS homebrew projects here...

#108698 - Hermes - Sat Nov 11, 2006 10:56 am

OOPMan wrote:
Have you mentioned this bug to sgstair?

I'll check and if not, let him know :-)


No. If you can contact with sgstair send this modification, but i think is a good idea post here this question for all the developers ;)

#108699 - OOPMan - Sat Nov 11, 2006 10:58 am

Indeed, thanks for posting :-)

I'll try and drop sgstair a line later today and point him in the direction of this forum thread.
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI

You can find my NDS homebrew projects here...

#108923 - sgstair - Mon Nov 13, 2006 4:21 am

"So you can see it is a good idea set to 0 this bit ;)"

Wait, what? how is it a good idea to clear that bit? it doesn't change anything at all, except prevent the user from specifying other undocumented WEP modes (which DO exist, 3 and 4 are valid WEP modes, though not the ones you're predicting)

if you pass in a 1 or 2, for 64bit/128bit wep, it will work just as well if you don't clear that bit... I fail to see how that changes anything. :\

-Stephen
_________________
http://blog.akkit.org/ - http://www.akkit.org/dswifi/

#108981 - Hermes - Mon Nov 13, 2006 8:58 pm

sgstair wrote:
"So you can see it is a good idea set to 0 this bit ;)"

Wait, what? how is it a good idea to clear that bit? it doesn't change anything at all, except prevent the user from specifying other undocumented WEP modes (which DO exist, 3 and 4 are valid WEP modes, though not the ones you're predicting)

if you pass in a 1 or 2, for 64bit/128bit wep, it will work just as well if you don't clear that bit... I fail to see how that changes anything. :\

-Stephen



Hummm, you read the WFC data from the flash, ok? When you connect using WFC datas, you use the WIFI connection settings.

In the wiki page you can see this info:

http://www.bottledlight.com/ds/index.php/Firmware/UserSettings


In the 0xE6 offset resides the WEP Mode info (you are using this data as argument for the Wifi_SetWepMode())

Well, WEP data for 128 bits, ASCII is 0x6. If you don't clear the bit, it fail.

So you decide: it is a bug or not, but it fail and it is very easy to resolve this problem.

PD: I can see that it has not been good idea to comment this failure here. Not problem, it is the last time i post mentioning a problem :(

#108982 - Mighty Max - Mon Nov 13, 2006 9:18 pm

Hermes wrote:

PD: I can see that it has not been good idea to comment this failure here. Not problem, it is the last time i post mentioning a problem :(


Oh comeone, don't get snappy.

We all make errors, and doint the bitmask in SetWepMode is one. The caller is in duty to select the wep mode it really wants, not SetWepMode to "guess" what the caller meant to say.

To fix this problem of different mode indizes in the save and the actual hardware, is has to be in the save-parser.

One might actually want to set one of the reserved modes and would be stuck in "wtf?!" state if it doesnt do what it sais ;)
_________________
GBAMP Multiboot

#108984 - OOPMan - Mon Nov 13, 2006 9:24 pm

If you think you've found a bug you should ALWAYS mention it, even if you're not sure.

If it is a bug, then it can be fixed and people are happy that it's been fixed.

If it's not a bug then you've still learned something.

So please continue to post stuff Hermes...

I suspect that, in this case, the English-Spanish divide may be mangling what Hermes is trying to say...
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI

You can find my NDS homebrew projects here...

#108988 - Hermes - Mon Nov 13, 2006 9:52 pm

OOPMan wrote:
If you think you've found a bug you should ALWAYS mention it, even if you're not sure.

If it is a bug, then it can be fixed and people are happy that it's been fixed.

If it's not a bug then you've still learned something.

So please continue to post stuff Hermes...

I suspect that, in this case, the English-Spanish divide may be mangling what Hermes is trying to say...


I have problems to understand some words in english, of course, but i have the the impression that sgtair has answered to me 'outside of tone'

If he think that it is strange i clear this bit, he can ask to me and I can try an better explanation

The problem exist but it is possible to fix in other point. The standard modes for NDS WIFI is in the Wiki info and i can see if for example, you put 0x7 mode (128 bits, 16 ASCII) it work from my AP as 64 bits 5 ASCII WEP mode).

From the WFC, when i connect using the WFC datas, it put the 0x5 value, and it connect to my AP as 64 bits 5 ASCII and 0x6 value don't work

So, it is very easy to think if you set this bit to 0, it work correctly (and works)

It change 5 to 1 (64 bits) and 6 to 2 (128, 13 chr) and 7 to 3 (easy to think it is 128 bits 16 chr).

if you set 4, it is a not standard value, so it don't have to much sense support this mode, and sets 5 and 7 work in the same way as 1 (in my AP) and 6 don't work as 128 bits and 13 chr

#108992 - Lick - Mon Nov 13, 2006 10:08 pm

I think he's trying to say this: the 0-7 values are used by software, but when talking to the hardware, you have to convert it to 0-3, by masking.
Software will be able to distinguish between more properties (0-7). Think Connection Setup textbox behavior. But the hardware doesn't care (0-3). It only cares about the number of characters in the password?

In other words, W_MODE_WEP takes a 2bit WEP mode, derived from the 3bit value.

This might be wrong, but it's how I interpret his explanation.
- Lick
_________________
http://licklick.wordpress.com

#108994 - Hermes - Mon Nov 13, 2006 10:26 pm

Lick wrote:
I think he's trying to say this: the 0-7 values are used by software, but when talking to the hardware, you have to convert it to 0-3, by masking.
Software will be able to distinguish between more properties (0-7). Think Connection Setup textbox behavior. But the hardware doesn't care (0-3). It only cares about the number of characters in the password?

In other words, W_MODE_WEP takes a 2bit WEP mode, derived from the 3bit value.

This might be wrong, but it's how I interpret his explanation.
- Lick


Yes! :D

If sgstair knows setting 4 here works, may be it can be changed to:

if(wepmode>4) wepmode-=4;

Sorry, if i cannot explain it correctly :$

#108996 - sgstair - Mon Nov 13, 2006 10:39 pm

Re: Hermes:
Yes, I did answer a bit harshly, sorry - I do see what you're talking about now. However, modifying that function is very much not the best way to solve the problem - the best way is to change the wep mode used by the AP record before the system requests that WEP mode, it's never a good idea to limit the options that the hardware can accept by modifying the end function like that. The 2 places where this would be best to do are either in Wifi_AssocStatus() on arm9, or GetWfcSettings() on arm7.
The reason that this hasn't been done yet is because I haven't had the time to explore all of the WEP key modes yet, so I haven't supported them all. (but it works for hex keys so I haven't exactly changed it :)

-Stephen
PS: there is no 128 bit / 16 chr mode - but other wep modes are supported...
PPS: If you're sure the modes 5 / 6 are the ascii 64 / 128bit wep modes, I can modify the lib to handle them properly.
_________________
http://blog.akkit.org/ - http://www.akkit.org/dswifi/

#108997 - Lick - Mon Nov 13, 2006 10:40 pm

W_MODE_WEP = (W_MODE_WEP & 0xFFC7) | ((wepmode&3) << 3);

This should work as well. ;)
_________________
http://licklick.wordpress.com

#108998 - sgstair - Mon Nov 13, 2006 10:46 pm

Lick:
You're halfway right- what he's meaning is the WFC data's value for the "wep mode" doesn't think bit 2 is important. Please do not confuse this with the idea that "the hardware doesn't need that bit" - it is my philosophy to never limit the hardware like that unless absolutely necessary - the clearing of bit 2 should be done of the side dealing with the WFC data, not the side talking to the hardware. For example - I do know that WEP modes 3 and 4 are valid and potentially useful modes; were I to apply the fix suggested here, it would be impossible to use WEP mode 4, even though it's a valid hardware mode (either 256bit or 320bit WEP if my memory serves correctly)
That's what got me all excited, the modification seemed to break things without any indication of being helpful. (I see now what was meant though, just that problem should be addressed elsewhere in the code)

-Stephen
_________________
http://blog.akkit.org/ - http://www.akkit.org/dswifi/

#109000 - Lick - Mon Nov 13, 2006 10:56 pm

Oh I see, I thought that the first two bits were the same and the third bit flagged some setting like 64bit/128bit. I see my mistake now.

Thanks!
- Lick
_________________
http://licklick.wordpress.com

#109006 - Hermes - Tue Nov 14, 2006 12:05 am

sgstair wrote:
Re: Hermes:
Yes, I did answer a bit harshly, sorry - I do see what you're talking about now. However, modifying that function is very much not the best way to solve the problem - the best way is to change the wep mode used by the AP record before the system requests that WEP mode, it's never a good idea to limit the options that the hardware can accept by modifying the end function like that. The 2 places where this would be best to do are either in Wifi_AssocStatus() on arm9, or GetWfcSettings() on arm7.
The reason that this hasn't been done yet is because I haven't had the time to explore all of the WEP key modes yet, so I haven't supported them all. (but it works for hex keys so I haven't exactly changed it :)

-Stephen
PS: there is no 128 bit / 16 chr mode - but other wep modes are supported...
PPS: If you're sure the modes 5 / 6 are the ascii 64 / 128bit wep modes, I can modify the lib to handle them properly.


Don't worry sgstair :D

i am sure 0x5 and 0x7 modes work as 64 bits 5 chars in my AP. I have tested it.

the best solution:

if(wepmode>4) wepmode-=4;

But also can be:

WifiData->wfc_enable[c] = 0x80 | (data[0xE6]&0x03);

You decide :D

I have made other change in the ARM7 code:

Code:


void Wifi_Init(u32 wifidata) {
   WifiData = (Wifi_MainStruct *)wifidata;

    InitFlashData(); // <- InitFlash here

   POWERCNT7 |= 2; // enable power for the wifi
   *((volatile u16 *)0x04000206) = 0x30; // ???

   // reset/shutdown wifi:
   WIFI_REG(0x4)=0xffff;
   Wifi_Stop();
   Wifi_Shutdown(); // power off wifi


It is because in Wifi_Shutdown(), you read a byte using ReadFlashByte() so:

if(ReadFlashByte(0x40)!=3) {
Wifi_RFWrite(0xC008);
}

And i think it is to 0, if you are calling to the InitFlashData() function after.


PD: In my next release of eSound and Multithread libs, i include the source code of your WIFI library 3.0A (i have integrated the lib in my ARM7 code). I hope you see this with good eyes. You have made a good work ;)

#109009 - Mighty Max - Tue Nov 14, 2006 12:25 am

Hermes wrote:

i am sure 0x5 and 0x7 modes work as 64 bits 5 chars in my AP. I have tested it.


Which one?
You tested what the WFC_wep_modes stand for if i read you right

But a WFC_wep_mode might not be a valid HW_wep_mode and vice versa.

Its like WFC talking spanish and the HW english. There are words that are nearly the same for both, but also words that sounds nearly the same that have a complete different meaning.

You need a knowing translator to solve that problem. Here: you got to fix the autoconnect translating the WFC setting into HW modes.

The hardware does i.e. not need to know how the wepcode is represented to the user, it just takes it bytes. Therefor the ascii and the hex modes of wfc translate into the very same hw mode.
_________________
GBAMP Multiboot

#109015 - Hermes - Tue Nov 14, 2006 1:21 am

Usually, when you use the WFC datas the mode is 0x5 for 64 bits 5 chars and it work as mode 0x1

if you set mode 0x7, it connect as 64 bit too. I have connected my utility Wifiloader in this moment with mode 0x7 (forced), with my AP in WEP 64 bits ;) (when i say it connect to 64 bits, it is because i am test it !)

#109029 - sgstair - Tue Nov 14, 2006 6:16 am

Well, there's one critical piece of information you haven't given - under what conditions does say mode 0x07 appear naturally, without you setting the mode? is it an AOSS mode, or something similar? Mapping all of the available modes to what they do is the step that has kept me from properly fixing the lib's behavior re: WFC data to begin with.

Also, Hermes, you still don't seem to get it - Mighty Max is the most clear about explaining it so far - the wep modes you're talking about are the WFC modes, and you're wanting to modify a function that sets a hardware mode - which evidently isn't compatible. I will be doing the translation in Wifi_AssocStatus (arm9) when I get around to adding it, as this leaves the most room for flexibility.

-Stephen
_________________
http://blog.akkit.org/ - http://www.akkit.org/dswifi/

#109035 - Lick - Tue Nov 14, 2006 8:11 am

Hermes wrote:
I have made other change in the ARM7 code:

Code:
void Wifi_Init(u32 wifidata) {
   WifiData = (Wifi_MainStruct *)wifidata;

    InitFlashData(); // <- InitFlash here

   POWERCNT7 |= 2; // enable power for the wifi
   *((volatile u16 *)0x04000206) = 0x30; // ???

   // reset/shutdown wifi:
   WIFI_REG(0x4)=0xffff;
   Wifi_Stop();
   Wifi_Shutdown(); // power off wifi


It is because in Wifi_Shutdown(), you read a byte using ReadFlashByte() so:

if(ReadFlashByte(0x40)!=3) {
Wifi_RFWrite(0xC008);
}

And i think it is to 0, if you are calling to the InitFlashData() function after.


I'm interested in this one, as it seems that this might cause the bug that I have when running a DSWifi enabled application twice without powering off. Perhaps this is the point where the full reset isn't completed.
_________________
http://licklick.wordpress.com

#109049 - sgstair - Tue Nov 14, 2006 1:44 pm

Granted, having the InitFlashData() earlier is probably a good idea, ultimately though it probably won't change anything.
The actual reset is 'WIFI_REG(0x4)=0xffff;', which quite completely and utterly resets the wifi hardware's internal state, after which all the registers are set up.

-Stephen
_________________
http://blog.akkit.org/ - http://www.akkit.org/dswifi/

#109342 - pepsiman - Fri Nov 17, 2006 12:58 pm

sgstair wrote:
PPS: If you're sure the modes 5 / 6 are the ascii 64 / 128bit wep modes, I can modify the lib to handle them properly.

http://www.bottledlight.com/ds/index.php/Firmware/UserSettings

WEP mode (0: disabled, 1: 5 byte hex WEP, 2: 13 byte hex WEP, 3: 16 byte hex WEP, 5: 5 byte ascii WEP, 6: 13 byte ascii WEP, 7: 16 byte ascii WEP

#109462 - gl0b - Sat Nov 18, 2006 1:42 pm

If wep 128bits code bugs, you can also enter the password in hex instead of ASCII. I was looking for this solution during months!
_________________
----!-----

Next generation DS