I received an email not long ago indicating that there was a bug in the checksumming code in the lib – and as it turns out there was indeed an instance where the checksum was still being calculated incorrectly – this bug only affects UDP packets, and not very many of them (I’d estimate somewhere around 1 in 30000 packets may be affected, given average use)
Anyway, a patch has been made, the dswifi CVS repository at devkitpro has been updated with the modified code, if you would like to update it. I will not be releasing an updated compiled release package for this bug, as there is a rewrite planned of the whole thing in the near future.
Sorry for the lack of updates lately, I’m still not quite sure what things I should be working on and what order to get them done in – I will post more when I finish making up my mind :)
RSS feed for comments on this post. | TrackBack URI
October 26th, 2006 at 2:21 pm
How big of a
bribedonation would it take for that decision to end up ad hoc mode?October 26th, 2006 at 2:33 pm
Hi, although I don’t understand everything you are talking about.. I am pretty sure I am 1 of the 30000 you mentioned.
I can’t connect with the homebrew BeUP on my DS Lite. I’ve been trough all forums and tips and finaly the creator of BeUP told me I might own one of the very few DS’s thats not compataible with the SgStair’s library. That lead me to you! So if I understand it right, the maker of BeUP will have to implement this update of yours in his program, and then it will work on my DS?
October 27th, 2006 at 2:13 am
eli: unfortuantely the lack of ad-hoc mode in the recent versions has been due to the hardware making it very difficult to do ad-hoc; I have yet to find a good way to do it.
Twan: Hiya, unfortunately I can say with great certainty that this wasn’t your problem; the bug I’m speaking of only infrequently affects UDP communications, where BeUP uses TCP for it’s communication, so it would be unaffected by this bug. There are a few inconsistencies that make certain types of wifi setups difficult to deal with in this version, but the next version will make a much greater effort to connect correctly in any situation.
October 27th, 2006 at 3:31 am
Well, that’s still some good news, at last :p I’ll be waiting for your next version then. Thanks for the info.
October 27th, 2006 at 3:42 am
oh, but there I forgot to tell you something: Im using a DS Lite, but my sister has a normal DS and can connect with BeUP without problems. And she uses exactly the same wifi settings…
October 27th, 2006 at 10:19 am
Hi !
Congratulation for the wifi lib ! But il tried to use your malloc code and i sometimes wHeapAlloc return NULL without any error…
Did you already see this bug ?
October 27th, 2006 at 1:21 pm
Twan: unfortunate :\ hopefully the next wifi lib will work better for you; there may be some small configuration thing causing problems but I don’t have enough info to troubleshoot it.
gdpasmini: hiya; I have not encountered this problem, and I’ve written some test code that pushes my malloc code pretty far. I would need more information to even have an idea of what’s going wrong for you.
October 30th, 2006 at 11:13 am
Actually, i really don’t know why that return NULL.. I hoped you would know ! ;-)
I have an other problem, i didn’t succeed to remove the traces. So i have all the time informations about packets sent and received…
Could you tell me how i could to remove it ?
Thank you !
November 10th, 2006 at 8:01 am
Dude,
I think I found another little “buglet” that may cause some grief.
I’ve been playing with the source to DSWifi and the Lib test demo you posted.
I was having some strange crashs / deadlock situations when the Arm7 & 9 are trying to Sync after the call to Wifi_Init(int flags) on the arm9, I think I’ve tracked it down to the following lines IN Wifi_Init()
erasemem(&Wifi_Data_Struct,sizeof(Wifi_Data_Struct));
WifiData = (Wifi_MainStruct *) (((u32)&Wifi_Data_Struct) | 0×00400000); // should prevent the cache from eating us alive.
The problem (as I see it) is that although the erasemem function works ok, the result is still in the Arm9 cache and hasn’t been written back to main memory yet, depending on the amount of data or operations kicking around this could be quite a while. To fix this problem either move the erasemem call to AFTER the assignment of the WifiData pointer and pass that to erasemem OR fully flush the cache as the last line to erasemem – both seem to work.
I also suspect that as the cache lines are 64 bytes wide, ** potentially ** another problem could arise from a variable that happens to sit within either 64 bytes either side of Wifi_Data_Struct might also cause problems when it drops out of the cache – I’d fix that by embedding Wifi_Data_Struct within another structure that’s got at least 64bytes of padding on either side.
Hope this helps and keep up the good work!
JT.
November 10th, 2006 at 5:59 pm
Hi JT,
Oddly enough, some of this has already come up in discussion about the wifi library, so a while ago a DC_FlushAll() was added right after the 2 lines you mention.
I entirely hadn’t considered that the buffer would be unaligned and the previous/next cache lines would pose a problem, but indeed they could. I’ve now fixed this by adding padding to the start/end of the struct and the changes are in CVS now. (though, of note, cache lines are 32 bytes)
Thanks for your observations :)