Jump to content


Premium Members
  • Posts

  • Joined

  • Last visited

Posts posted by sgstair

  1. Hi,


    1) The lib was written in a way so it does not recognize that an AP existing without a SSID broadcast is possible.


    2) Support will be added in the next version of the lib (which is at least a few months away)


    3) It could be hacked in, but that doesn't directly help existing apps much (they would have to recompile). I've been investigating a change that could make it work, but I have not completed it yet.


    So, no help yet... This is just a bit difficult to support with the current lib.



  2. Yes, this is a known issue. The DS library closesocket() abruptly terminates the connection rather than allowing it to wait to complete. This will be fixed in a future version - in the meantime though, it's suggested to use shutdown, and wait for the other end to close the socket before closing it. (use recv() and wait for it to return 0)

    There isn't a better solution at this time <_<



  3. Hi, You are most certainly losing data, but it's not due to the wifi lib.

    The current buffer size in the wifi lib is indeed 8192 bytes, which means the maximum number of bytes that can be sent is 8191 bytes. The "send" call does fail when you send more bytes than are available in the buffer- but it fails telling you how many bytes it sent; this is by the design of the BSD Sockets layer, to allow you to know that a certain number of bytes were sent.

    I think it's very unlikely that you would be losing data if you handled the return code of send() appropriately and retried the send of the bytes that weren't sent until they were added to the buffer


    Also, if you're pretty new to packet sniffers, a lot of times "malformed" packets come up in normal traffic. They're more likely in the case of DS traffic as the wifi hardware is far from perfect and often packets get retransmitted a lot. (wireshark/ethereal almost always mark duplicate packets as "malformed")


    Let me know if you continue to have problems after fixing your use of send(), I'm not aware of any errors in this code path but it's not a very well tested one.



  4. Oh right - yes, the header does provide signal strength. And it's a bit of a hack to get to it, but it's right next to the speed (I meant to say strength, not speed - but managed to confuse them in my reply)

    See here (though not entirely accurate): http://akkit.org/info/dswifi.htm#FmtRx


    The wifi RX header is in the buffer right -before- the pointer the "raw" API gives you, so you have to compute the address and read it. Next version will provide easier access.

    (Also the RSSI readings are more complex than indicated, I'll document this sometime.)

  5. For non-promiscuous packet receiving, is it possible to get the signal-strength issue?


    (Promiscuous mode would be a win, but wouldn't be essential, for what I want to do, as I can fake it with some ARP spamming)


    Yup, And actually if you are connected to an AP, you can receive all 1-2mbit packets "attached" to that AP.

    When you enable raw packet capture you have the ability to get a header including the speed.. though it's a little bit of a hack.

  6. Hi all - the DS Wifi lib 0.3.3 is out now, correcting one of the biggest annoyances so far, which was connection problems with newer DS lites.


    If you're still having problems with the wifi lib, first try the 0.3.3 test app at http://akkit.org/dswifi/wifi_lib_test.nds

    If you can connect to your Access Point with that app, then probably whatever app you are having trouble with hasn't upgraded yet, and you should pester the author ;) Or, start a new thread and complain about it, or something. Poiint is, If the wifi lib test works for you, please don't post your problems in this thread.


    If the wifi lib test doesn't work for you: there are a few reasons that this might be. I'd like to hear about if if there are problems but just saying you're having problems is -not- very useful.

    What I'd like to hear is, specificly what problem you're having... What state it stops working at in the wifi test app, or how the test app behaves that you think is strange.

    I also need to know what sort of Access Point you're using (model number would be good) what type of DS you're using and how recently you got it. And what homebrew device you are using to run the test app. This information is very useful for troubleshooting problems, if nothing else I can probably obtain the same hardware and test with it!

    If commercial DS games don't work with the router, this is also a very important piece of information. The wifi lib should work in most cases DS games do now. I hope :)

    Sometimes routers can be configured to make the DS wifi connection work, or be more stable too. In order to be able to research this though it's very important to know what type of router you're using.



    That being said, there are still a few common connection problems that are known:



    Using Nintendo WiFi USB stick for connection. This works for commercial games but not for the wifi lib.


    Presently the wifi lib doesn't support using the wifi USB stick with it's own drivers. There are methods to convert the usb stick into a generic software Access Point, that will work with the dswifi lib. Supporting the usb stick natively is planned but not a high priority right now.

    (Here's a gbadev post that details how to make the usb stick act like a generic soft-AP: Gbadev.org forum post)



    Both the ds wifi lib and commercial games cannot connect to the AP


    Depends on the access point. Many access points have a way to control the "base rate set", but it might not be called that. Look in the router/access point web interface for any mention of a "Base rate set" or "B/G compatibility mode" - if you have a similar option, you should set the base rate set to 1-2Mbit or the compatiblity mode to "Wireless-B" or "802.11B"

    Additionally, neither commercial games nor the wifi lib currently support WPA, so if the Access Point is using WPA encryption, it must be set back to none or WEP only, for the DS to connect.



    Wifi lib can't connect, stuck on ASSOCSTATUS_SEARCHING - but commercial games connect fine


    the ds wifi lib doesn't yet support probe requests, as such the access point needs to be broadcasting "beacons" in order for the wifi lib to see it and be able to connect. All routers should have a setting to enable or disable sending beacons, it will probably be a checkbox called something like "Enable SSID Broadcast" or "Allow broadcast of name (SSID)" or "Send Beacons" or something of that nature. It needs to be enabled in order for the DS to see the router. Also if the router allows you to set the beacon transmit rate, it should be 1 or 2 mbit in order for the DS to be able to receive them.



    (If there are other problems/solutions, they'll be added here. It's entirely likely I've missed a few)

    Good luck and happy wifi-ing :)

  7. Not quite - the wifi lib can provide channel changing but doesn't currently receive all packets in promiscuous mode.


    (There is a way to do this, but it's not documented and requires some lower level hacking at this point - I haven't confirmed that it works yet, either...)

  8. Hiya,

    1) this is a side effect of how wireless works - several channels overlap, so it's possible for a channel 7 station to receive data from channels 2 through 12, though it's much better at receiving data on channel 7. This is why channels 1, 7, and 13 are often used by the firmware, because 1,7,13 are sufficiently spaced that they don't receive packets from each other.

    2) This is known, the "promiscuous mode" of the wifi lib is not perfect. There are some people who have managed to make it work, but I don't have the solution around at the moment. It involces changing the filter register on the arm7... I will post a reply if I find the value it needs to be set to.



  9. Hiya F2bnp - I'm not sure what your problem is, but it might be related to the apps you're testing with using an older version of the wifi lib.

    For your convenience I've uploaded a new version of the wifi lib test, compiled with the newest lib verion available (the app should say "Version 0.3.1 (+CVS)") - please try connecting with this app, that can be found at http://akkit.org/dswifi/wifi_lib_test.nds.

    If that still doesn't work, it's likely that your problem is elsewhere, and I will try to help you find it.


    (Also, for reference, 0.3.1 is newer than 0.3d, and +CVS means it includes from CVS the code fixes the problem mentioned in the other thread)


  10. Hiya;

    A few things to note, I'm not presently aware of a good way to "receive all packets" - the closest you're likely to come is to "receive all packets associated with a specific group" - which can be achieved by first connecting to a fake access point where you supply the MAC address (BSSID), and then disconnecting - before expecting to receive packets.


    At present, outgoing packets are not appreciably modified (unless WEP is enabled), besides the last 4 bytes of the packet being overwritten with a CRC. The hardware may deny sending certain packets if the 802.11 header isn't correct enough.


    When capturing, only packets with valid preamble/crc make it in.



  11. Magin: Yes, that's exactly what the problem is. I suspected it was the other day, and mentioned it to crediar on IRC, but I haven't done anything about it yet. The better solution (and what the nintendo driver uses) is to call the swi delay function, rather than running around in a waitloop. I'll try to get this fix put in the lib soon, regardless of how it gets implemented.



  12. lokicat: thanks - I'll look into it further.

    Please note that the -O0 'trick' is just that, it's not changing anything except for how optimized the code is - if there are timing-specific problems, it has the potential to change them, but it is generally not fixing anything unless the compiler is broken... which it's not.

    I still don't know what the problem is, but I'll do what I can to find out...



  13. Magin, lokicat; I think this is probably more likely related to the flashcard you're using to run the wifi apps - can you tell me what flash card you're using? There may be a hidden problem with the lib that doesn't show up except under very specific timing, which is triggered by the way the flashcard boots or something... but if I can't duplicate it, it's a lot more difficult to fix.



  14. Hiya Magin,

    This is an interesting discovery but also very strange, as the apps I have compiled with devkitpro R20 using -O2 do indeed work correctly on my DSlites (though they're the older kind.)

    I can think of a few places in the code where optimization might cause problems... but if it were a bad problem I would have noticed, instead it seems like it might be a timing issue or maybe very specific to the new hardware?

    If you have a chance, can you test the wireless lib test app I've compiled, at http://akkit.org/dswifi/wifi_lib_test.nds -- this *is* compiled with devkitpro R20, using -O2... but so far, from what I know it does work for everyone.




  15. G19: I'll answer this - I'm not a lawyer but some things are pretty well defined.


    Legality in this country in many cases is defined mostly by proving intent, and there are a large number of legal uses / intentions for using flashcards. Consider for example, knives... They can easily be used to kill people, but have countless other legal uses as well. Obviously the flashcard doesn't have such an overwhelming number of legal uses compared to the illegal ones, but they still exist, and stores that sell them use that to their advantage. The bottom line is: the act of selling a flashcard isn't illegal, as it's difficult / impossible to prove that the flashcard is intended for illegal purposes; the act of downloading a pirated Rom file is illegal, as it's blatantly copyright infringement, and very simple to prove. So, there really aren't any problems with the logic of selling flashcards and also banning links to commercial roms.

    Of course, the situation is a good deal more complex than this, but this is a reasonable representation of how things are.



  16. Hiya


    Yes, you are correct in your observation that the DS resends a lot of data; and this is something I'll be addressing in my rewrite (as it stands, the current version of sgIP will probably not be maintained further)

    you are also correct that the patch will likely break TCP - it looks like it may break if there's some data loss, or a few other conditions it looks like.

    (this is actually probably better addressed by sending large blocks of data at once, though I probably have some code that makes this a bit less efficient too)

    Anyway, it's nice to see people playing around with it, though I promise the next version will be a lot better.



  • Create New...