Jump to content


  • Posts

  • Joined

  • Last visited

Posts posted by thoduv

  1. Problem:

    Connected OK but can't send/receive data!

    Probable Causes:

    * WEP could be incorrectly configured.

    * IP address may be manually incorrectly configured.

    * Router may be incompatible!

    And what about this error, but happening randomly ? (seeing it works everytime with WFC games)

    Router i'm using: Netgear DG384G


    With packet captures, i'm able to see that it doesn't send anything (not even ARP).

    It happens even with WEP disabled.

  2. Okay, I get it works, but it seems to be a very weird bug in Dswifi : it works if SGIP_DEBUG is undefined in sgIP_Config.h (compiled by sgstair as "Release" version). When SGIP_DEBUG is defined, so debug functions are enabled (and even if the log function do nothing), I can't get it work...

  3. Hi !


    I tried to send an HTTP request to an HTTP server and to receive the answer. But it doesn't work...


    Here is a packet capture where the request and the server answer can be seen : http://thoduv.drunkencoders.com/tmp/dswifi_http_test.pcap


    I won't show my code beacause it's too ugly, but I've tested it (exactly the same code) on my PC and it works.


    Using another protocol like Msn Messenger, this code works on DS (I manage to send a command to MSN server and receive the answer).


    I'm using a Netgear DG834G router/access point, which works fine with Nintendo WFC games.


    I did a lot of tries and searches but I definitively don't unterstand why it's not working (seeing it can be done : wifi_lib_test did it with TCP Connect test).


    Thanks !



  4. I've also tried... and I've also found that global_connectAP is always 0 : never updated in the lib.

    You must keep the AP "id" of the connected AP and get infos with Wifi_GetAP...

  5. I've implemented a simple TFTP-server that I'm going to use for a project later. TFTP works by sending one DATA packet, wait for ACK, send next DATA, and so on. This means only one packet is in the queue at any time and therefore the protocol is very sensitive to latency.


    I've only gotten about 5 kb/s transfer rates. I've discovered that the bottleneck is the communication between the ARM7 and the ARM9 processors. The ARM9 polls for new packages every 50 ms, when the Wifi_Timer_50ms() function is called. That means new packages are recieved 10 times every second. Since TFTP sends 512 bytes in every package you only get a transfer rate of 10 * 512 ~ 5 kb/s.


    This leads me to two questions:


    1. Why is it using polled communications between the processors when the IPC interrupts could be used?


    2. Why is the IP stack implemented on the ARM9 processor and not ARM7? It would be much more efficient if I could implement the TFTP-server in ARM7... The socket functions could be made available on both processors using IPC for ease of use.


    And another question:


    3. In wifi_lib_test TIMER3_DATA is set to -13106. Doesn't that give an interrupt every 100 ms instead of 50 ms?


    PS. using wifi_lib 0.2b





    2. I was also wondering why... :lol: It will be faster, no ? Can't the ARM7 CPU be used more than it is actually ? ;)


    And another question:


    4. Do you progress on the projet sgstair ? :P

  6. is this supposed to work with udp_test? it does nothing when i try it with my code and neither with this yet the official one works fine.


    You would probably have to change the internal IP and port. Since I'm protected by WEP here, I recompiled the source with the IP to send to as my outside line, forwarded port 8888, and stole a neighbor's wifi to test, and it seems to work fine. Make sure you aren't mismatching ports somewhere...


    WEP's working ? :D

  7. When will you release your lib with TCP support ? You known that UDP isn't used at all on the internet...

    The first reals internet apps will come when you will release DNS and TCP. Many devs and users are waiting for this first "useful" release for long times, and it doesn't arrive !..

  8. At present the app is limited to the rtl2500 chipset based cards, specificly the ones that firefly's driver works with.  The code for the tunnel app itself is designed to be mostly portable though, so only minimal effort will be required to port it to a new system if a driver exists.

    As such, yes, the driver is going to be the limiting factor for linux... but depending on how much free time I have, I may attempt to do the driver thing in linux as well.




    Wow ! ;) I hope you will have free time !

  9. Glad you all appreciate my work :devilboy:

    I've considered releasing the UDP/IP stack first, but really TCP/IP isn't too far away - my attention has just been directed elsewhere lately.

    We'll see if I can beat the odds and get all my other stuff done, and still release the wifi lib before MK:DS <_< that'd be a real win-win situation.




    Oh ! It's a great news ! :P I've also started a project that will use your lib !

  10. My computer is always on so that's not an issue.  Would the ds be able to connect through a laptops wireless nic card thingy(forget what it's called).  Would be cool if it did.


    It does with sgstair's stack (sgIp) or Online games like Mariokart. But it doesn't with Ds NIFI (wmb) or DS Tunneling (that is being made by sgstair).

  11. This "little good driver" doesn't exist at all for the moment, and there are no projects of. The only driver is for PCI card with Ralink RT2560 and its author Firefly don't absolutely want to release his source code... :blink: (He said that nobody knows how to use this code.)

  • Create New...