azaydius

I don't see a problem with your implementation, so I have to ask a few questions (some may be silly, but if I don't ask then I can't be sure). Can you connect to your access point with other homebrew? The auto connect function you are using assumes you have the wifi information stored in the firmware from a retail game, is this true for you and if so can you connect with retail games? Have you tried using a different access point? If your answer to these is yes, then have you initialized your IRQ's properly as demonstrated in the wifi example? Like so: int wifi_connect(){ // send fifo message to initialize the arm7 wifi REG_IPC_FIFO_CR = IPC_FIFO_ENABLE | IPC_FIFO_SEND_CLEAR; // enable & clear FIFO u32 Wifi_pass= Wifi_Init(WIFIINIT_OPTION_USELED); REG_IPC_FIFO_TX=0x12345678; REG_IPC_FIFO_TX=Wifi_pass; *((volatile u16 *)0x0400010E) = 0; // disable timer3 //irqInit(); irqSet(IRQ_TIMER3, Timer_50ms); // setup timer IRQ irqEnable(IRQ_TIMER3); irqSet(IRQ_FIFO_NOT_EMPTY, arm9_fifo); // setup fifo IRQ irqEnable(IRQ_FIFO_NOT_EMPTY); REG_IPC_FIFO_CR = IPC_FIFO_ENABLE | IPC_FIFO_RECV_IRQ; // enable FIFO IRQ Wifi_SetSyncHandler(arm9_synctoarm7); // tell wifi lib to use our handler to notify arm7 // set timer3 *((volatile u16 *)0x0400010C) = -6553; // 6553.1 * 256 cycles = ~50ms; *((volatile u16 *)0x0400010E) = 0x00C2; // enable, irq, 1/256 clock while(Wifi_CheckInit()==0) { // wait for arm7 to be initted successfully while(VCOUNT>192); // wait for vblank while(VCOUNT<192); } // simple WFC connect: int i; Wifi_AutoConnect(); // request connect while(1) { i=Wifi_AssocStatus(); // check status if(i==ASSOCSTATUS_ASSOCIATED) { break; } if(i==ASSOCSTATUS_CANNOTCONNECT) { iprintf("Could not connect!\n"); return 0; break; } } return 1; }

I have a similar setup at my University and understand the difficulty. Two things have worked for me in the past, though not reliably. First, using dslinux, associate with the access point... use lynx to submit your login information and then reboot and immediately run your ds game. This worked for me for a while at least as it recognizes your ip address as being authenticated. That is assuming you dont have problems with dslinux. Second, depending on how secure the setup is at your Uni, you can authenticate with a wireless laptop and then manually setup your internet connection through the firmware and force the same IP that is given to your laptop. This may allow you to 'piggy back' on the authenticated IP. Of course, if your school is smarter than mine and uses mac address filtering, this wont work for you. Good luck!

I am wondering if anyone else has had similar problems with socket send using DSWifi? We have been developing a simple FTP client for the DS (for a school project) and will be releasing it to the community, but would like to fix a major bug we have been baffled by. We are able to connect to ftp sites, change directories, disconnect, reconnect, download, etc... The problem lies when we try to upload files. Essentially what happens is send fails when it has sent 8192 bytes. We have tried changing the buffer to a smaller size and the upload loop will iterate until the sent bytes reach this 'magic' number and then it returns error. Debugging this has been quite difficult as you can imagine. We have even setup a packet sniffer on the ftp server side in order to see what is going on and have received some malformed tcp packets during this process. This is what lead us to the error possibly being in the library. Receiving works wonderfully and there are no malformed packets during the download process. Any thoughts or suggestions would be greatly appreciated!