MS3FGX

Under Windows, RT2500 is the ONLY chipset that is supported, nothing else will work. Under Linux, you can use both RT2500 cards and USB devices that use the RT2750 chipset (namely, the Nintendo Wi-Fi USB Connector).

I am writing my first simple program making use of the Wifilib, and I have run into a problem. Here is the code in question: #define MAXPORT 200 #define STARTPORT 1 ... int sockfd, port; struct sockaddr_in sain; struct hostent *h; int x, y; // Static assignment of scan parameters h = gethostbyname("rgc.homelinux.org"); x = STARTPORT; y = MAXPORT; // Create the socket sain.sin_family = AF_INET; sain.sin_addr = *((struct in_addr *)h->h_addr_list[0]); printf("Start Port: %i\n", x); printf("End Port: %i\n",y); printf("--------------------------------\n"); printf("Now Scanning...\n"); for(port = x; port <= y; port++) { sockfd = socket(AF_INET, SOCK_STREAM, 0); sain.sin_port = htons(port); if(connect(sockfd, (struct sockaddr *)&sain, sizeof(sain)) == 0) { printf("Port %i is open!\n",port); close(sockfd); } close(sockfd); } shutdown(sockfd,0); close(sockfd); printf("Done!\n"); Obviously, the video setup, connecting to the AP, etc, has been omitted here. Anyway, this is a very simple port scanner. As you can see, this simply increments the port variable, creates a socket, sees if it gets an answer, and if it does, prints a little message. If I take this code and build it on my Linux machine, it scans the target fine. But, when I am running it on the DS, it scans up to the first open port on the target, and then stops. Well not exactly stops, but after the first hit the loop takes something like 30 seconds to go though before it moves on to the next port. I have not waited around to see if it actually picks up on the next open port or not (the target, my external IP, only has ports 22 and 80 open). I am no expert with sockets, much less DS programming, but I assume what is happening here is that once the socket actually connects up to the target once, it is refusing to be reopened against the new port. I thought perhaps close() was behaving differently here, so I tried with shutdown() in it's place, but as I recall, that only made matters worse. Anyone know what the problem might be?

Are you doing this just for testing purposes, or to create a full program? For a very simple test UDP listening server, you could use netcat. For example: nc -lu -p 123 This will make netcat listen for incoming UDP data on port 123, and print it to the terminal. To send data to this server, you could use the UDP test mode of the wifi_lib_test program.

Looks cool, but I don't use Windows. I hope eventually somebody will make a program like this with XMMS support.

This is easily one of the most anticipated homebrew WiFi projects for me, I really hope that it is still in development.

That does buffer forever for me on XMMS, but seems to play for my brother with WinAmp.

You might want to check out streamtuner. It is a Linux program to browse online stream directories, including SHOUTcast. Naturally, it is open source, so you should be pretty useful to look over.

Yeah, that would be ideal. Be able to pull down the list of servers from SHOUTcast, and list them on the bottom screen with the important information (max listeners, bitrate, etc). Then just be able to touch one to start listening.

The DS Download Play only runs software that has the RSA signature on it, to prevent running unauthorized software. The only way around this so far is to reflash the DS with FlashMe (a replacement firmware) that disables the RSA signature check and will run any binary sent to the DS. In the end though, most people would rather have the ability to get the RSA signature on homebrew binaries, and be able to run them on the stock firmware. Hence the quest to create RSA signed homebrew. Anyway, I don't think this has been mentioned anywhere, but is there any word on what platform this software is running on/will be developed for? I know it is using the RTL2500 card, as the WMB server does, so I am going to assume then that is is also using the driver for WMB, which means Windows. So then to continue this line of logic, this software would have the same platform limitations as the WMB server, in that it can only be ported to a different platform once a compatible driver has been written for that platform?

LibOGC (the Gamecube homebrew library) also uses LWIP for it's TCP/IP implementation. When you put up on the main site you were having trouble getting LWIP to work without a native OS, I tried to contact you wil the LibOGC information (I had worked on some of the networking in it) but found that the LibOGC site was down, so I had no useful information to provide for you, other than my word that it would indeed work without an OS....eventually. Though, now that I think of it, the LWIP implementation on the GC did seem to have some glitches with sockets. I recall I was writing a network debugger for it, and had a lot of very difficult to track down bugs when it came to establishing listening sockets (at least in the way my program wanted to do it).

PuTTY would be a fairly obvious port. It has been ported to cell phones, after all.

Dillo itself is small, and may seem simple, but it has many dependencies that would need to be replicated for the DS and/or statically linked into the binary.

Yes You will need to load whatever homebrew program with WiFi support as you normally would. This will not change any of the current requirements for booting homebrew software.

There is no browser. This is just an API for homebrew developers to access the WiFi hardware and use the lwip TCP/IP stack. The only program that uses it so far is the IRC test program that is being worked on with the TCP/IP implementation.