Jump to content

Problem with receiving raw frames


masscat

Recommended Posts

Hello all,

 

I am porting my WMB host over to the DS and therefore need to be able to send and receive raw 802.11 frames. I tried using the raw send and receive functions from the Wifi lib but did not have any luck (does the DS have to be associated with an AP for these to work?). So a'hacking I went to do some experimenting.

 

I have removed the arm9 side of the wifi lib.

The ARM7 initialises the hardware with a call to Wifi_Init (using a local Wifi_MainStruct structure) and calls Wifi_Start.

The Wifi_Update function is not called from the VBlank handler on the ARM7.

Frames are transmitted by the ARM7 calling Wifi_TxQueue directly. This works fine and I can capture the beacons sent out on a PC.

An external (to the library) received processor function (rxFrameProcessor) is installed by the Wifi_Init.

The receive side does not fare so well. For testing I have reduced Wifi_Intr_RxEnd to the following.

void Wifi_Intr_RxEnd() { 
#define BUF_START 0x4c00 
#define BUF_END 0x5F60 
#define BUF_SIZE (BUF_END - BUF_START) 
#define BUF_CONTENTS_SIZE( write, read) ( (read) > (write) ? \ 
(BUF_SIZE - ((read) - (write))) : ( (write) - (read))) 

 int base; 
 int packetlen; 
 int full_packetlen; 
 int dest_offset; 
 int i, cut, temp; 
 int tIME; 
 int max_read_size; 
 tIME = REG_IME; 
 REG_IME = 0; 
 cut = 0; 

 int write_ptr = WIFI_REG(0x54) << 1; 
 int read_ptr = WIFI_REG(0x5A) << 1; 

 max_read_size = BUF_CONTENTS_SIZE( write_ptr, read_ptr); 

 if ( rxFrameProcessor != NULL) { 
   rxFrameProcessor( 0); 
 } 

 rxFrameProcessor( write_ptr); 
 WIFI_REG( 0x5a) = write_ptr >> 1; 
 REG_IME = tIME; 
 return; 
}

 

The code simply points the the read pointer to the current value of the write pointer (most of the other stuff is from previous experiments).

Now I would have thought this would happily sit there receiving frames forever but the interrupt appears to occur 128 times and then stop happening.

 

Does anybody know why this would happen? Is there something that I need to clear/reset that is not happening as I am not calling Wifi_Update?

 

Edit: the source has been removed from my webserver.

 

Any help much appreciated.

 

Ben

Edited by masscat
Link to comment
Share on other sites

Well I have done a bit more poking around and found out I was getting a "Count Overflow" interrupt just before the receive and, as I found out, transmit stopped. I am therefore assuming that the rx and tx gets disabled to prevent the counts from overflowing.

Clearing the counts (by calling Wifi_Intr_CntOverflow) every so often does indeed stop the rx and tx from stopping.

 

As far as the overflow interrupt goes, I do not know what is disabled and, therefore, what to reenble to get rx and tx working again. But just clearing the counts (i.e. the behaviour of Wifi_Intr_CntOverflow) does not work.

Could this cause a problem when using the normal Wifi library?

Link to comment
Share on other sites

I now have the WMB host sending out beacons and when a client turns up, allowing it to authenticate and associate. But no further can I go.

 

Problem number 2:

 

I cannot receive Data + CF-Ack frames (frame type 0x18). These frames are used by the client to pass its responses back to the host. They have a multicast destination address of 03:09:bf:00:00:10.

I have played around with the W_RXFILTER registers (0xd0) but these frames do not appear to be getting received even if 0xFFFF is written to this register.

 

Anybody know the register settings for receiving these frames or receiving all frames on the tuned channel?

 

When being a WMB host the DS acts as an AP, where as the DSWifi library acts as a normal station. Anybody know of any setup that needs changing in the AP situation.

Link to comment
Share on other sites

I now have the WMB host sending out beacons and when a client turns up, allowing it to authenticate and associate. But no further can I go.

 

Problem number 2:

 

I cannot receive Data + CF-Ack frames (frame type 0x18). These frames are used by the client to pass its responses back to the host. They have a multicast destination address of 03:09:bf:00:00:10.

I have played around with the W_RXFILTER registers (0xd0) but these frames do not appear to be getting received even if 0xFFFF is written to this register.

 

Anybody know the register settings for receiving these frames or receiving all frames on the tuned channel?

 

When being a WMB host the DS acts as an AP, where as the DSWifi library acts as a normal station. Anybody know of any setup that needs changing in the AP situation.

 

You're running into the same wall I have; there are some ways around this but most of them I don't know of yet. However, the next library version (0.3) will use a trick (I'll be adding it to the documentation too - once I've verified it works) to capture all packets; it might be a good idea to build your app on the next version of the lib. (but hey, you don't have to)

 

-Stephen

Link to comment
Share on other sites

Hopefully the new version of the library will solve the problem. The code I am using at the moment is just a small hack to the source of version 0.2b so moving to the new version, when it is released. will not be too much work. Keep up the good work.

I will carry on playing around and post anything useful to I find.

 

Ben

Link to comment
Share on other sites

  • 2 weeks later...

Here are some wifi register settings to allow me to receive data frames from the WMB client:

 

8012 = 0x703f
81ae = 0x1fff
80d0 = 0x0301
80e0 = 0x000d
8008 = 0xe000
8004 = 0x0001

 

I think the interesting one is the 8008 register. The MAC address and BSS id are set to the hardware address of the DS.

The wmb host is still not working (see here for more info).

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...