masscat

I have seen a case where 1 byte does not get transmitted in sequence, resulting in the need for the 1.5 second retransmit timeout to happen before it is sent. So anybody playing with the hack take care. Looking forward to the next dswifi release.

After playing with DSFTP I noticed that the download speed (DS to PC) was about 10 times less than the upload speed (PC to DS). After some investigation, it was apparent that dswifi was sending out all non-acknowledged data in each TCP packet it sent. This included data that the DS had already sent but the PC had not yet got round to sending the acknowledge for, thereby wasting bandwidth. To experiment with a solution I did a quick hack of dswifi to only send new data, i.e. not previously sent data. The resulting upload and download speeds are now of the same order. For those who are interested you can get a patch file against the dswifi cvs (dated 2006-10-05) with the hack. To install the patch change into the dswifi directory and run "patch -p0 <path/to/patchfile". It was experimental and may break TCP.

If the amount of data being sent is not large then it may not be sent out immediately and buffered instead. This is done to try to reduce the number of TCP packets sent reducing the cost of the TCP packet overhead. Normally you can set a socket option to cause data to be sent out immediately (TCP_NODELAY) but this functionality is not in dswifi yet. To get the same behaviour you can hack the dswifi source. In the function sgIP_TCP_Send there is the following comparison. if( j>SGIP_TCP_TRANSMIT_IMMTHRESH && rec->tcpstate==SGIP_TCP_STATE_ESTABLISHED) SGIP_TCP_TRANSMIT_IMMTHRESH is set to 40; unless there are more than 40 bytes waiting to be sent the packet will not get sent until the timer function fires. By setting SGIP_TCP_TRANSMIT_IMMTHRESH to 0 a call to send() will cause a packet to get sent out straight away.

I have made some shell scripts and awk programs to help investigate how to configure DS wifi hardware. More info here.

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).

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

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.

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?

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

According to the Ralink site the chipsets are called RT2500 (pci and pcmcia form factor) and RT2500USB (USB form factor). The RT2500USB chipset use the RT2571 chip as the baseband/MAC. The linux open source drivers (which are based on code from ralink) refer to RT2500USB devices as RT2570. To add to the confusion, you can currently use a RT2500USB device for WMB and Wifime BUT ONLY UNDER LINUX. See here and here for more information. Ben