#139783 - syncope - Mon Sep 10, 2007 3:45 am
Just need a reminder as to why 'Download play from PC', 'Ad-Hoc', and 'Downloadplay DStoDS' are still not solved for homebrew. It can't be just because of the RSA signature check, is it ?
How do flashcarts work around this anyway ? Whats the 'flaw' in the DS design that gives us all this goodnees ?
This is too general and high level to be piracy talk really.(no?)
#139793 - melw - Mon Sep 10, 2007 7:06 am
* Download play server for DS
* Download play server (WMB) for PC
Both methods require the DS to be flashed when transferring homebrew software to omit the RSA checks.
Ad-hoc networking between two DS's hasn't been done. Sgstair (author of the DS WiFi library) was unable to get it working, lacking proper documentation and processing power and it looks like nobody else has worked on it since. Feel free to work on this if you have any experience in network programming!
#139799 - simonjhall - Mon Sep 10, 2007 9:41 am
I did spend some time REing the adhoc hardware but I got encouraged by people to change project... I do hope to go back to it at some point though.
_________________
Big thanks to everyone who donated for Quake2
#139800 - nornagon - Mon Sep 10, 2007 9:50 am
simon, you should get back to work on the wifi stuff! :)
#139820 - sonny_jim - Mon Sep 10, 2007 1:51 pm
EDIT: Nevermind, spurious data ;-)
#139830 - ThomasS - Mon Sep 10, 2007 5:03 pm
| Quote: |
| simon, you should get back to work on the wifi stuff! :) |
I'd also be very happy if someone finally figured out ad-hoc :)
_________________
<dsFont> <Game Collection>
#139848 - Tockit - Mon Sep 10, 2007 9:34 pm
as far as I can think, this is the one thing that is truly missing from the homebrew scene for the DS.
most flashcarts DO support download play for commercial games - with just updates to firmware to make the fix. I've heard people say that this would never be possible, obviously only to be proven wrong by now.
the source for the firmware and OS on most flashcarts isn't open - but there is a new flashcart coming soon that boasts an open-source OS. isn't there some way to figure it out from there? I'm no programmer, so it's all speculation on my part.
the advent of ad-hoc connection in homebrew would the one thing that would make our scene unstoppable - and it's been a long time coming. :-o
_________________
-01011101001010101010 (frank)
#139851 - tepples - Mon Sep 10, 2007 10:37 pm
| Tockit wrote: |
| most flashcarts DO support download play for commercial games - with just updates to firmware to make the fix. I've heard people say that this would never be possible, obviously only to be proven wrong by now. |
All that means is that the warez tools don't mistakenly patch the client binaries (and thus don't break the signature) when patching the server. It doesn't mean that unsigned binaries such as homebrew will work through DS Download Play on a DS with stock firmware.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#139916 - Corsix - Tue Sep 11, 2007 3:35 pm
Could you not disassemble the code for a commercial game that does ad-hoc and see how it is done? (Or look at the stage 2 WMB of games which only send the stub over in a disassembler)
I know that tools like IDA can disassemble ARM processor code.
#139920 - Mighty Max - Tue Sep 11, 2007 3:45 pm
| Corsix wrote: |
| Could you not disassemble the code for a commercial game that does ad-hoc and see how it is done? (Or look at the stage 2 WMB of games which only send the stub over in a disassembler) |
It't not quite Ad-Hoc what they are using.
And tbh for DS<->DS wifi, no ad-hoc is needed. Just send toDS,fromDS= 0,0 Dataframes between the both DSs or to the broadcast address. Works just fine.
_________________
GBAMP Multiboot
#139923 - Lynx - Tue Sep 11, 2007 4:30 pm
Well, I don't really see a benefit to ad-hoc anyway. There aren't a lot of multiplayer WiFi games out there.. and even if they supported ad-hoc, I don't see it increasing the acceptence of WiFi multiplayer games.
_________________
NDS Homebrew Roms & Reviews
#139948 - nornagon - Tue Sep 11, 2007 11:26 pm
Lynx, the *reason* there aren't a lot of homebrew multiplayer WiFi games is because it doesn't work yet :-P
I think commercial games do multiplayer by having one DS act as an access point and the others connect to it as normal clients.
| Mighty Max wrote: |
| And tbh for DS<->DS wifi, no ad-hoc is needed. Just send toDS,fromDS= 0,0 Dataframes between the both DSs or to the broadcast address. Works just fine. |
Have you tried this? Do you have some code I could look at? What's the speed like?
#139963 - syncope - Wed Sep 12, 2007 3:04 am
Well go! Simon then! and didn't Masscat look into that as well ?
Oh right, t'was Juglak with the most promissing forray so far >>
[just had a hard time finding the link when starting this thread]
http://forum.gbadev.org/viewtopic.php?p=116869&highlight=#116869 (the last DL link is still working)
As he put it himself - I do also still hope it opens the floodgates.
The whole point of non-online wirelss play imo, is of course sharing and playing, your and other people's great work with people who do not have flashcarts [or flashed firmware for that matter] to begin with.
@MightyMax - What are you on about ? Still think its just a few timing kinks in the wifi lib that need to be ironed out ? Feel like sharing those insights in more detail and/or code..
As with many things it would be really nifty to have a library for that. LibDS-Server
..that's how the original Halo used to work. And it dynamically reassigned the server to the box with the best connection to all active players, mid gameplay mind you.
Yes I'm dreaming, but lesser dreams have already been fullfilled/granted within the DS comminity :D
#139970 - Dood77 - Wed Sep 12, 2007 4:37 am
| syncope wrote: |
| The whole point of non-online wirelss play imo, is of course sharing and playing, your and other people's great work with people who do not have flashcarts [or flashed firmware for that matter] to begin with. |
Well, for me the whole point would be no lag. But just because someone figures out how to do some sort of ad-hoc connection with two homebrew DS's, doesn't mean it will be one DS loads the program and then clicks "multiplayer" and the other just boots the normal screen and clicks download play. (Let alone sending it to an unflashed DS, oh why RSA, oh why...) More likely, I think, is a library totally built from scratch with raw frames.
_________________
If I use a term wrong or something then feel free to correct, I?m not much of a programmer.
Original DS Phat obtained on day of release + flashme v7
Supercard: miniSD, Kingston 1GB, Kingston 2GB
Ralink chipset PCI NIC
#139977 - melw - Wed Sep 12, 2007 8:24 am
Easyness of use, smaller lag, no server application needed, download play and sharing games (only one DS needs to have a copy in the first place) etc. Ad-hoc networking for the DS homebrew would indeed have lot of advantages. As Nornagon said, lack of multiplayer WiFi games is more of a result of incomplete network support on the developer level rather than anything else.
Mighty Max, so you got something working? Or just theorizing?
#139989 - tepples - Wed Sep 12, 2007 12:13 pm
If it's an alternative to download play you're after, you don't need to crack RSA. Instead, you can boot player 2, eject card, boot player 3, eject card, boot player 4, eject card, boot player 1, then choose Start Game.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#139992 - nornagon - Wed Sep 12, 2007 12:38 pm
I seem to recall speculation about a "WifiMe 2", in which the second stage in download play of some games does not check RSA (and so will run unsigned code that you inject). Still, I think homebrew download play on unflashed DSes isn't likely to happen without such trickery.
@tepples, that only works if the game in question doesn't use libfat during gameplay; also only with NoPass-style SLOT-1 flashcarts. Not much good on my ol' Supercard mini-SD, unfortunately. :(
#139994 - tepples - Wed Sep 12, 2007 1:17 pm
| nornagon wrote: |
| I seem to recall speculation about a "WifiMe 2", in which the second stage in download play of some games does not check RSA (and so will run unsigned code that you inject). |
Truth is that there aren't enough homebrew developers who know how to dump and disassemble carts to do this. It appears that most of the people who know how to dump and disassemble carts are the developers of piracy tools.
| Quote: |
| @tepples, that only works if the game in question doesn't use libfat during gameplay |
Commercial games don't read the file system during DS Download Play gameplay either.
| Quote: |
| also only with NoPass-style SLOT-1 flashcarts. |
It would still work with a separate NoPass and SLOT-2 flash card.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#139995 - nornagon - Wed Sep 12, 2007 1:46 pm
| tepples wrote: |
| Truth is that there aren't enough homebrew developers who know how to dump and disassemble carts to do this. It appears that most of the people who know how to dump and disassemble carts are the developers of piracy tools. |
I've done small amounts of disassembly before, but never DS stuff...
| tepples wrote: |
| Commercial games don't read the file system during DS Download Play gameplay either. |
Ahh, d'oh! :-)
| tepples wrote: |
| It would still work with a separate NoPass and SLOT-2 flash card. |
Truth. It's still a huge pain compared to actually having wireless stuff working, though.
#139996 - Corsix - Wed Sep 12, 2007 1:53 pm
I have a copy of IDA5, but no idea on how to do the dumping of carts. I would be interested to see if my x86 disassembly skills carry over into ARM disassembly.
#140003 - Mighty Max - Wed Sep 12, 2007 5:00 pm
| melw wrote: |
Mighty Max, so you got something working? Or just theorizing? |
Yes, just not between two DS, but the DS and the old wifime-card on my laptop (I still don't own a second flashed DS :p )
Once you have shared MACs (which you can do in several ways without breaking the 802.11 protocol, nor any other (802.3snap i.e.) you can simply send out dataframes to the destination MAC and you DS will happily receive them.
The only thing to be done here is prefixing your data with a standard 802.11 header (Version 0, Type = 2, SubType = 0, toDS=0,fromDS=0). Resend that data until you receive an ACK. On the other side, recognize a received frame with ACK and process the data beyond the header. Done.
I am currently not using sgstairs wifi code, but afaik he included all the necessary functions to do this on the ARM9.
Using the wifi hardware (the raw send/receives are the same on the arm7 as they are in sgIP, just nothing is processed/answered there instead it's put into a message queue to the arm9)
| Code: |
void Send802_11Data(unsigned char *toMAC,unsigned char *data, int length)
{
unsigned char *frame = (unsigned char *)malloc(24 + length) ;
memset(frame,0,24+length) ;
memcpy(frame+24,data,length) ;
memcpy(frame+10,ownMAC,6) ;
if (associatedAP)
{
memcpy(frame+4,associatedAP->bss,6) ;
memcpy(frame+16,toMAC,6) ;
*(unsigned short *)frame = 0x0108 ;
} else
{
memset(frame+16,0xFF,6) ;
memcpy(frame+4,toMAC,6) ;
*(unsigned short *)frame = 0x0008 ;
}
Send802_11NeedACK(frame,24+length) ;
free(frame) ;
}
|
Where Send802NeedAck just puts the data to sent into the MessageQueue to the AMR7 and into the list of waitingForACK to be resend when the data is not ACK'ed thus lost.
The receive interpretating function is then just a switch statement, which on fc.type = 2 does:
| Code: |
case 2: // data
{
SendAckTo(&frame->addr2[0]) ;
HandleData(data+24,length-24) ;
break ;
}
|
with SendAckTo beeing
| Code: |
typedef struct ACKFRAME
{
FRAMECONTROL fc ;
unsigned short duration ;
unsigned char address[6] ;
} ACKFRAME, *LPACKFRAME ;
void SendAckTo(unsigned char *mac)
{
ACKFRAME ack ;
memset(&ack,0,sizeof(ack)) ;
ack.fc.type = 1 ;
ack.fc.subType = 0x0D ;
memcpy(&ack.address[0],mac,6) ;
Send802_11((unsigned char *)&ack,sizeof(ack)) ;
} |
I'm not ready to release the code of the MessageQueue as it still needs some things fixed. But sgstairs build in functions should provide easy enough access to STA to STA data transfers.
Only when sending broadcasts i.e. to announce your MAC/ask for the MAC of the other station (so other STA or DS will try to read the data) you got to make sure that the data follows the 802.3snap, or you will probably end up with crashing an AP, as i did at the first.
_________________
GBAMP Multiboot
#140074 - melw - Thu Sep 13, 2007 8:35 am
| Mighty Max wrote: |
I am currently not using sgstairs wifi code, but afaik he included all the necessary functions to do this on the ARM9.
...
I'm not ready to release the code of the MessageQueue as it still needs some things fixed. But sgstairs build in functions should provide easy enough access to STA to STA data transfers. |
Took a quick look at the DSWiFi library, and there's indeed ready functions for processing raw 802.11 packets. Hopefully you can get your MessageQueue into a release state somewhere in the future (or PM me if you're ok with sharing the current version privately for research purposes). I'll take a closer look on using raw frames with Sgstair's library, but with my limited network programming experience I have no idea what's the outcome of all this (especially knowing that even the author of the library didn't get this finished :)
For the reference, snippets from dswifi9.h:
| Code: |
// Wifi_RawTxFrame: Send a raw 802.11 frame at a specified rate
// unsigned short datalen: The length in bytes of the frame to send
// unsigned short rate: The rate to transmit at (Specified as mbits/10, 1mbit=0x000A, 2mbit=0x0014)
// unsigned short * data: Pointer to the data to send (should be halfword-aligned)
// Returns: Nothing of interest.
extern int Wifi_RawTxFrame(unsigned short datalen, unsigned short rate, unsigned short * data);
// Wifi_RawSetPacketHandler: Set a handler to process all raw incoming packets
// WifiPacketHandler wphfunc: Pointer to packet handler (see WifiPacketHandler definition for more info)
extern void Wifi_RawSetPacketHandler(WifiPacketHandler wphfunc);
// Wifi_RxRawReadPacket: Allows user code to read a packet from within the WifiPacketHandler function
// long packetID: a non-unique identifier which locates the packet specified in the internal buffer
// long readlength: number of bytes to read (actually reads (number+1)&~1 bytes)
// unsigned short * data: location for the data to be read into
extern int Wifi_RxRawReadPacket(long packetID, long readlength, unsigned short * data);
|