Hi,
I'm building a wifi lib around the sceNetApctlXXX APIs and have run into the same thing as others have. Namely that the PSP have trouble obtaining an IP using DHCP.
I've compared the network traffic generated when connecting using the "Test Connection" option in the network settings menu with the traffic generated from connecting through a call to sceNetApctlConnect. When using the PSP network settings menu a full DHCPDISCOVER-> DHCPACK sequence is performed. When using sceNetApctlConnect the sequence stops after the DHCPOFFER, i.e. the PSP does not issue a DHCPREQUEST to the server.
Has anyone successfully connected to a DHCP enabled access point using sceNetApctlConnect?
Any ideas of what to test in order to get this working?
sceNetApctlConnect and DHCP
not the right way
I ve managed to disasm wipeout wireless connection code and using sceNetApctlConnect is not the right way.
Wipeout never calls sceNetApctlConnect.
It uses sceUtilityNetconf dialog boxes with parameters that configures the dialog to allow only "Connect" function when a network is selected.
In fact, it is psp's os that connect not wipeout.
Wipeout only add one handler (sceNetApctlAddHandler method) to know when the connection is established (the pspftp handler may be usefull).
Sorry for my english... :)
If only i can speak french i would be more precise.
If you manage to make sceUtilityNetconf dialogs to work, you're done.
I gave up.
Wipeout never calls sceNetApctlConnect.
It uses sceUtilityNetconf dialog boxes with parameters that configures the dialog to allow only "Connect" function when a network is selected.
In fact, it is psp's os that connect not wipeout.
Wipeout only add one handler (sceNetApctlAddHandler method) to know when the connection is established (the pspftp handler may be usefull).
Sorry for my english... :)
If only i can speak french i would be more precise.
If you manage to make sceUtilityNetconf dialogs to work, you're done.
I gave up.
I've only tested the sceUtilityNetconf API briefly but without any luck (all I got was error codes. Can't remember which right now though). I'm not sure if I missed an API call or if the PSP needs to be set in a specific graphics mode for the dialogs to appear...
I guess I have to take a look at Wipeout and find out ;)
I'll post back if I get something going... :)
I guess I have to take a look at Wipeout and find out ;)
I'll post back if I get something going... :)
error code
In my test i received no error code but nothing happened.
Maybe you have to be in kernel mode ?
I know that u have to call sceUtilityNetconfUpdate in a loop.
Be in a specific graphic mode may be the right way.
Sorry but i can't help here!
Maybe you have to be in kernel mode ?
I know that u have to call sceUtilityNetconfUpdate in a loop.
Be in a specific graphic mode may be the right way.
Sorry but i can't help here!
Re: not the right way
Go ahead and speak French, I'll translate.pspkrazy wrote:If only i can speak french i would be more precise
re: DHCP problem theory
My theory is the combination of module and thread trickery is screwing up the DHCP handler.
This is not a regular "game". My WiFi sample program is using kernel memory module flags and kernel threads to get the flash0: prxs to load. Even regular user entry thunks aren't working in this configuration.
If you connect to a Access Point and ask for a DHCP address, the system creates is a DHCP thread and semaphore created (both named "SceNetDhcpClient")
But it appears the DHCP thread ends prematurely. The sempahore is still around when it gets back to your code.
Suggestion #1: disassemble the DHCP client handler code (pspnet_apctl.prx) and figure out a workaround
Suggestion #2: reimplement the standard DHCP protocol yourself (using UDP and broadcast - may also be tricky)
I started going down path #1 - but IMHO for the very specialized uses of WiFi on the PSP, I think requiring a static IP isn't too inconvenient
[and all-but-essential for apps where the PSP is a server]
-----
> Wipeout never calls sceNetApctlConnect.
FWIW: I've seen several different ways of connecting.
The "sceNetApctlConnect" is in the bowels of the "ApDialogDummyConnection" function. There look to be a few other configuration options depending on the way the game works (Adhoc and Infrastructure, Adhoc only)
This is very trial-and-error. Not only are we dealing with undocumented initialization sequences, but also running in a tricky configuration. If you find a combination that works better, go for it !
My theory is the combination of module and thread trickery is screwing up the DHCP handler.
This is not a regular "game". My WiFi sample program is using kernel memory module flags and kernel threads to get the flash0: prxs to load. Even regular user entry thunks aren't working in this configuration.
If you connect to a Access Point and ask for a DHCP address, the system creates is a DHCP thread and semaphore created (both named "SceNetDhcpClient")
But it appears the DHCP thread ends prematurely. The sempahore is still around when it gets back to your code.
Suggestion #1: disassemble the DHCP client handler code (pspnet_apctl.prx) and figure out a workaround
Suggestion #2: reimplement the standard DHCP protocol yourself (using UDP and broadcast - may also be tricky)
I started going down path #1 - but IMHO for the very specialized uses of WiFi on the PSP, I think requiring a static IP isn't too inconvenient
[and all-but-essential for apps where the PSP is a server]
-----
> Wipeout never calls sceNetApctlConnect.
FWIW: I've seen several different ways of connecting.
The "sceNetApctlConnect" is in the bowels of the "ApDialogDummyConnection" function. There look to be a few other configuration options depending on the way the game works (Adhoc and Infrastructure, Adhoc only)
This is very trial-and-error. Not only are we dealing with undocumented initialization sequences, but also running in a tricky configuration. If you find a combination that works better, go for it !
theory
Maybe the DCHP thread is created with user flag and then can't access modules created in our kernel thread ?
If only we find a way to use sockets and dhcp easily, a lot a great apps would arrive.
:(
does broadcasting work ?Suggestion #2: reimplement the standard DHCP protocol yourself (using UDP and broadcast - may also be tricky)
I've tried loadmodule patches from pspsdk to start modules (either flash ones and wipeout ones) in user mode and they started but i got errors ("module not imported" something like that) when i wanted to init them.My WiFi sample program is using kernel memory module flags and kernel threads to get the flash0: prxs to load. Even regular user entry thunks aren't working in this configuration.
If only we find a way to use sockets and dhcp easily, a lot a great apps would arrive.
:(
[apparently they fixed their problem, but for anyone else researching this topic]
This is very old information. This thread should be closed.
The "DHCP" problem was fixed over a year ago (Fall 2005!)
DHCP will work if you start the modules in the proper modes (some in user mode, some in kernel mode)
My WiFi .03 sample (http://www.aibohack.com/psp/wifitest.htm ), the pspsdk samples as well as all other WiFi derived apps do it the proper way.
If DHCP isn't working for you, you probably don't have your access point set up correctly, or you are porting/adapting a WiFi app and changed the module initialization.
This is very old information. This thread should be closed.
The "DHCP" problem was fixed over a year ago (Fall 2005!)
DHCP will work if you start the modules in the proper modes (some in user mode, some in kernel mode)
My WiFi .03 sample (http://www.aibohack.com/psp/wifitest.htm ), the pspsdk samples as well as all other WiFi derived apps do it the proper way.
If DHCP isn't working for you, you probably don't have your access point set up correctly, or you are porting/adapting a WiFi app and changed the module initialization.