Ppsspp: PSP to Computer AD HOC

[tilkinsc]

How does the PPSSPP and PSP ad hoc system work?

Is it possible to pair a device to a computer? What if the computer broadcasted a network? A lot of PSP games had an infrastructure mode in which would let two devices communicate over a network. This would be a cool addition feature to what has been worked on recently aside from graphical bugs.

[hrydgard]

Well, what I've actually been working on recently is a UWP port, and to do that correctly I needed a DX11 backend, which in turn required a LOT of reworking if I didn't want to end up with a ton of mostly-duplicate code again. And might as well fix bugs as I find them.

Anyway, that's beside the point. I really don't know more than rough overview about how the PSP networking works, all PPSSPP's network stuff has been contributed by others, so in this case, don't put your hopes on me.

[tilkinsc]

Alright fair enough.

[hrydgard]

Well, could still leave it open, maybe someone else will pick it up.

[tilkinsc]

Since infrastructure didn't mean using a public server, it would mean that one of the PSP devices was either used as a server and managed everything or they both managed everything, but updated a server on one of the PSP devices. Actually, the updated each other. The PSP does indeed show capabilities to host a server - even internet connections. So it is just a matter of supporting such a thing, faking the computer as a PSP. That may require some more internal lookat.

As for emulating AD HOC, I don't know enough about this still to make a hypothesis on how that would go down. I would need to check the code on PPSSPP.

[tilkinsc]

Okay so I am venturing on learning more about this. I am attempting to figure out what calls are made in a specific, downloaded game (monster hunter freedom unite). This will lead me to understanding what exactly is going on with the PSP to open sockets as necessary.

However, I don't know how to achieve seeing the specific code that will do this. How would one debug what is being called to open the infrastructure?

[hrydgard]

Well, I guess you'd add more logging to the various HLE function in Core/HLE/sceNetAdhoc*...

[ghost]

I was taking a look at the AdHoc code the other day. And it's kind of a mess. There are a lot of TODO and commented lines. So maybe it's not the "best" way to do it. But hey it work :)

[tilkinsc]

One huge issue I am facing right now in actually debugging is PPSSPP dictates the WLAN switch is off. So I will look through some disassembly. Another thing that is drawing me back is that the game crashes with the last version of PPSSPP that I use on game load, which is strange. So I defaulted back to official release. Some kind of 'stack error' says the weird windows issue report. Who knows. One last thing is the lack of resizability of the various frames in the disassembler...

The config file manages the mac and wlan switch and the like.

[tilkinsc]

This specific entry is going to document stuff. Definitely common knowledge coming back to edit this line.

sceWlanGetSwitchState returns 0 (1 on) inside of the config file.
sceWlanDevIsPowerOn ^^^
sceWlanGetEtherAddr returns an ethernet mac address inside of the config file.
http://pastebin.com/pN2LqM80 This homebrew gives light on how sockets go down. Given the example, it appears that it is typical socket stuff that could pretty well be emulated correctly through the correct returns from the psp libraries. This doesn't demonstrate how to connect to sockets using psp.
It appears that the other thing that matters is the switch state being active as well as Dev is powered on. It just boils down to connecting to a server or hosting one for the intranet. I am sure it is possible to port forward to let outsiders in...

Final remark would be there is no checking if the device referenced is a PSP as long as it operates within the ROMs.

[tilkinsc]

I have findings.

So I was talking with someone on Evolve (p2p tunnel network, like tunngle and hamachi) and they host a server for my favorite game which replaces coldbird.net. Evidently a person built it and they are just the host. While I didn't go further into that topic, I figured out that a little bit more of what I wanted.

So I was broadcasting ad hoc via psp in my game on (ad hoc) channel 1. I couldn't discover the network immediately. Idk. However, I got it to show by making a new network ad hoc and open. I assume this just forcefully updated my list of networks like it should of done it the first place..... but yeah. So I was able to connect and everything psp to computer. The question now is hooking up some sniffing and check out what is going on, as well as looking at PPSSPP ad hoc code.

I think there was already an attempt at this, but without PPSSPP being the target... I am thinking the target was more of a service like tunngle. Anyways, it is definitely possible as far as I can tell.

One thing that is certain is in order to play over the internet with something like tunngle, you must have 2 forms of connection. 1 is the psp and 2 is the internet. That requires an ethernet and a wireless or two wirelesses.

[tilkinsc]

This post is mine and is being edited as I go.

Data list: (12/03/2017) (added entries)

• Censored's chat log http://pastebin.com/yf4iczsJ
• Connecting to ad hoc network.... http://pastebin.com/snyhWL46
• Connected to ad hoc network http://pastebin.com/QR3Rb0Qs
• proAdhocServer used with CFW http://forums.ppsspp.org/showthread.php?tid=11398 which adenovan was talking about. I am less concerned with hacks around it then trying to fake a computer as a PSP.
• adenovan's suggested lookat source https://github.com/adenovan/AdhocServerPro
• Holy mother of documentation http://www.edepot.com/reviews_sony_psp.html
• As per the Marvell Libertas chip the psp has, http://download.cnet.com/Marvell-Libertas-802-11g-b-Wireless-LAN-Client-Adapter/3000-2112_4-166388.html might be the driver for such a thing, or at least give some lookat on how it works
• Link that details out PSP and PS3 Remote Play stuff http://www.neogaf.com/forum/showthread.php?t=361116
• Possible program that utilizes PSP and PS3 ad hoc WHICH MIGHT BE NATIVE so we can understand better the connection to PSP-PS3 that could be PSP-PC now https://store.playstation.com/#!/en-us/games/addons/adhoc-party/cid=UP9000-NPUA70069_00-ADHOCPARTY000000
• Wikipedia on Promiscuous mode https://en.wikipedia.org/wiki/Promiscuous_mode _"In non-promiscuous mode, when a NIC receives a frame, it drops it unless the frame is addressed to that NIC's MAC address or is a broadcast or multicast addressed frame. In promiscuous mode, however, the NIC allows all frames through, thus allowing the computer to read frames intended for other machines or network devices."_
• https://en.wikipedia.org/wiki/Promiscuous_mode#Some_applications_that_use_promiscuous_mode Some programs that can help us

Learn list: (12/03/2017) (solved 1 entry, added entry)

• What happens at the PSP level? (need bios/kernel for this)
• Is what happen at the PSP level something that matters? (5 frames then drop connection)

Resolved learn list: (09/07/2017) (added 2 entry)

• https://en.wikipedia.org/wiki/Wi-Fi_Direct Is psp ad hoc actually wifi direct?! no.
• What about the IPs? Do they use mac address as IP? Perhaps the adhoc code will let me understand. It actually communicates with device IDs rather than MAC or IP, MAC is just to give it a definite name and IP is a protocol. We would need to get the system to accept the device ID by handshaking okay. Only then will it allow communication between the two.
• What is the difference between channels automatic, 1, 9. and 11 Each channel operates on a different hop length, which is basically the difference between 90fm and 106fm in radio frequency modulation. So you can have two people in a network on channel 11 and two people on the same-named network on channel 9.
• I wonder if the PSP is its own DHCP, or if the PSP (when connecting ad hoc) does a whois that devices can do with the router. If you picked up wireshark you would understand.
  Actually, the PSP doesn't have a findable DHCP, since DHCP works the same in all situations. It is actually much different, and probably geared something more of ISATAP.
• It appears that CFW is hiding my MAC address... how to circumvent?
  There is a setting for this somewhere in CFW settings
• How tf do I connect an ad hoc computer to a server on either machine
  It is actually really simple. However, the problem is the PSP is a bit more embedded when it comes to ad hoc. A low level mechanic needs to be put in place to make the PSP recognize the computer as a psp and do its handshakes (hello, ping).
• Does PSP's ad hoc do UDP or TCP or any
  It actually can do any, and is dependant on the app when it has matchmade using ad hoc. The whole ad hoc system is a matchmaking server then direct connection through ip address through the matchmade ips.
• What packets do _the PSP_ send and how can a _protocol handler_ handle such a thing? This may be mandatory so that one can communicate with the other. Whether it would be monitoring networks via xlink kai or something, it needs figured out. https://en.wikipedia.org/wiki/Promiscuous_mode#Some_applications_that_use_promiscuous_mode We have tons of programs to do such a thing. Better get cracking. Probably want to do this on linux?

Tasklist: (04/17/2017)

1. Make a model that connects a PC, fake as PSP, to PSP
2. Clean up some ad hoc code
3. Add g_Config option to enable psp -> ppsspp
4. If already broadcasted, don't have to broadcast a new ad hoc network (Broadcast ad hoc network using an idle network card?) The PSP doesn't broadcast a new ad hoc network unless the respective network isn't found.
5. Open matchmaking server if needed on the network owner's psp (ip)
6. Open respective sockets the PSP expects (ports sniff?)
7. Relay information

[adenovan]

@Hydroque for your learn list number 2

1. TCP used on the host server (proAdhocServer). this server written by coldbird and the goal is to make the PSP work over internet. The server purpose is to emulate the matchmaking/matching system on game. Each Game create a group when matchmaking happen. you must look at this server code if you want to emulate the infrastructure mode like a real PSP do. i guess PSP infrastructure mode just a broadcast of this implementation on a wireless access point to let other PSP know a server is listening on that Access Point.

2. Most of the game communicate directly and use both TCP and UDP (commonly the Game use TCP for matching / matchmaking. and UDP after matchmaking to send game data to other peer) , each game also pick its own port to communicate. this one hard to emulate especially over internet and behind a nat. thats why most user use vpn service to tunnel the traffic, the vpn goal is to make user under one network and same subnet so they can communicated directly without their traffic blocked by firewall or nat. the solution of this point is available on Adamn's post http://forums.ppsspp.org/showthread.php?tid=16972&pid=121429#pid121429

3. PPSSPP and PSP communication use Pro-C CFW and Atpro.prx plugin on the PSP side , there is a psp/discovery function that not implemeted yet, im not sure but its maybe what you're looking at to implement. go look on the source here https://github.com/MrColdbird/aemu

[tilkinsc]

I appreciate the help, adenovan.

1. Currently I feel it is more appropriate to support the AD HOC feature (as per my intent) before getting into infrastructure. I feel like infrastructure would be easy. Since the PSP, when connected, is definitely a member of a router (modem/modem-router), you can port forward and potentially have the public send data to your psp. Your psp can indeed be a server. Correct me if I am wrong. With proAdhoc, this is a hacky way around something I want to be more direct. I guess that is what I am researching. Yunno http://forums.ppsspp.org/showthread.php?tid=11398

2. I am aware with what the vpn/tunnel software is doing in the background. They actually open a different strain of ips to host and the like on. Any tunnel software will make you install a driver/virtual network device which handles such a thing. However another thing is I am talking PSP to pc/android ppsspp - not pc ppsspp to android ppsspp. I desire playing the console with the computer. However, I hope to have immediate results when I sniff out the ad hoc connection broadcasted to see what is up.

I am still not sure what TCP or UDP is used for in this scenario. I believe censored's server is an implementation of coldbird too. I dunno. I forget. Censored may say it in that pastebin link. I actually don't know much about the coldbird project other than its general overview. But one thing is that the log from censored's server spits out UDP connections in the matchmaking which clashes with what you are trying to tell me. I assume that the port wouldn't be a problem as it is two identical games since the PSP does indeed broadcast the ad hoc network.

One issue I have is the understanding on how IPs line up in an ad hoc network. https://superuser.com/questions/109177/ip-address-of-host-of-wi-fi-ad-hoc-network Also, I did some connection and lookat. It appears that it takes a second for the computer to connect ad hoc to the PSP. It will give http://pastebin.com/snyhWL46 until http://pastebin.com/QR3Rb0Qs. However, I am not surprised if it just takes a second to actually connect because I am using a 2007 win7 laptop for testing.

1. I would need more information on what you are talking about. Are you saying there is successful ppsspp -> PSP connection? This seems only possible in hombrew?

[adenovan]

i look into your list of data, AFAIK

1. based on your data i think its possible to use PSP as a server and do an Adhoc directly without access point involved. we need to dig more information on PSP side adhoc network and fake the PPSSPP as PSP (hacking, sniffing needed,reverse engineering on psp side is needed) . this is a neat feature looking forward if you can dig more info on it and replace the proAdhocServer. current ADHOC implementation is indeed a hacky way to play ADHOC Game because the purpose it was build is to hook the PSP adhoc function with homebrew/plugin (atpro.prx) and emulate the communication to public IP.

2. the censored server you're talking about definitely based on coldbird server and looks like its only tunneled through evolve and the player status displayed on web. im host a similiar server by myself ( http://proindovpn.net ) and tunnel it with openvpn for android user , they love it , i drop the psp support because i didn't find any vpn homebrew / client on psp. my goal is only to create a large adhoc community over internet and centralized to play so we can easily play together without complicated setup (like Enable DMZ on router). if you're need a server code before it was ported to ppsspp you can find it here https://github.com/adenovan/AdhocServerPro

3. there is only successfull connection if proAdhocServer running on PPSSPP side or stand alone server is running on the server machine. yes the psp side need a homebrew / plugin to connect to it ( atpro.prx) with static ip configured. i think you already find out that info in my thread by yourself. there is no implementation of PPSSPP -> PSP successfull connection with PSP default adhoc function as host / server.

[tilkinsc]

I have been experimented with a Java application which opens a socket server on the pc, accepts connections from PSP (thru atpro.prx static/dynamic ip (only thing bad about dynamic is you have to refresh it when you relog into router and can't host servers public ip thereof longterm without updating users)). and connects the ports known to the evolve host. Information is gathered from the evolve host and sent from the computer to the PSP then. Basic, but it doesn't work. One of the problems I collide with is the lack of UPnP support. Sockets require a definite port and there are some ports that I can't listen to because I have no idea that they were attempted to be communicated with. While I believe I failed doing that, I learned that ports on ad hoc are a bitch.

The problem with connecting my computer to the PSP is I don't know what the PSP's ip is, how to open ports for listening and transfer (UDP/TCP), and how to acquire the PSP's ip. I am not familiar with ad hoc networks enough. I know that I get a cool ip, which I should of talked about. Summery: Learn how to connect two ad hoc devices to a server of either side. I also need to admit that I need to look at the names of the known ad hoc functions in the PSP. A pattern might show to me, But that is a little out of scope because I should be able to link a server easily.

It is possible that I can't continue with my efforts.

1. Can't build ppsspp
2. Why does MSVS exist as bigger than a modern game????
3. Lack of resources documenting ad hoc (sad, 'init?)

In reply,

1. I think it would be just a matter of relaying data to and from. I don't think it will be near as much bulk as the proadhoc server stuff. You just need to know the ports open, or have this so-called upnp that I am lightly familiar with.

1. It is good to have reference material.

2. I have successfully linked a ppsspp and psp using atpro.prx, and my efforts failed at the point of trying to link evolve with psp. (Thank god for the possibility of not a thousand relays)

A little bit more of my tunneling to evolve host. I did in-fact be able to connect and relay data. The TCP over 27513 or whatever the adhoc server runs on was known and that was how the people congregated. I failed at the part where actually connecting to the people the psp wanted. I have no idea what the ports were. However, for MHFU, censor reported that they were 20,000:20,004 give or take 1 max as index. So yeah the psp communicated to my computer (through atpro.prx infrastructure) to the evolve server. I have snapshots of such packets sent and received.

[tilkinsc]

http://www.thewindowsclub.com/smb-port-what-is-port-445-port-139-used-for
I believe that the PSP is netBIOs enabled. Reading this article alerts me that I may be able to communicate (and destroy) a psp by this port. I have this port open and listening.

Using NBSTAT command, the attacker can obtain some or all of the critical information related to

• A list of local NetBIOS names
• Computer name
• A list of names resolved by WINS
• IP addresses
• Contents of the session table with the destination IP addresses

With the above details at hand, the attacker has all the important information about the OS, services, and major applications running on the system. Besides these, he also has private IP addresses that the LAN/WAN and security engineers have tried hard to hide behind NAT. Moreover, User IDs are also included in the lists provided by running NBSTAT.
```

I don't really think so anymore.

[tilkinsc]

After loafing around in the headers of pspnet_adhocmatching.h I determined that there is a specific communication that goes down between PSP and PSP. A hello message that is game-specific is present that also has a neat callback, which I assume it is to handle the person joining. There is also a ping.

/** 
 * Linked list for sceNetAdhocMatchingGetMembers
 */
struct pspAdhocMatchingMember
{
    struct pspAdhocMatchingMember *next;
    unsigned char mac[6];
    char unknown[2];
};

^ this is the only thing that I could find that has any form of identification on who the hell connected.

@hrydgard Hey do you have a list of all functions with respect to their memory address visible in that disassembler which are actually used? I think there is more internal things to be observed in the bios, , anyways, I just wanted to correctly observe the functions in use.

I need to test further and will complete this post.

[tilkinsc]

If anyone has any binaries (prx) or disassembly that I can use to look at the PSP's internal ad hoc mechanics that would be great. My PSP 1000 won't let me go into kernel mode to rip at CFW 6.60 ._.

I added a new link that documents the PSP like a hawk. It is nice. So much stuff I didn't know as well as the history. It has a more full file structure. But I wanted to note that firmware 1.5 and 1.0 allows running unencrypted code, the first needed two PBPs or so it went. I wonder if the ad hoc change severly between these two. The documentation article stated that there was a lot of changes which gave birth to so much that it was preferred to change the psp to running unencrypted code (unsigned I guess) as CFW. Pretty neat. I assume it DIDN'T change it if at all as per the documentation detailing each of the patches that sony threw out in the article.

[tilkinsc]

I am still updating the learn list and the such as I figure this stuff out. I have it down to the hardware. We already know the the ad hoc works sufficiently. But we need the lower level depth for knowing how they truely work at the machine level.

[tilkinsc]

http://www.neogaf.com/forum/showthread.php?t=361116

So this is a link to 'PSP Remote Play Reverse Engineered', in which, talks about the 'hacking' of PSP to PS3. My thoughts on this is that the PSP AdHoc could be more directly monitored closely when it comes to connections. We already can use infrastructure instead of ad hoc with CFW, and that works flawlessly with adhoc server. I am not sure if the code builds upon the exact operations of the PSP, but it seems to solve the 'I am connected to the network but idk how to broadcast to other PSP using my PC to tell them I claim this IP, have a game with me'

Perhaps pissing with PS3 and PSP ad hoc may be in the future, as that is definitely possible... and homebrew exists for PS3.

[adenovan]

Some Europe user mention about adhoc party to play betwenn psp and ps3. You might interested to reverse this one https://store.playstation.com/#!/en-us/games/addons/adhoc-party/cid=UP9000-NPUA70069_00-ADHOCPARTY000000 he use adhoc party on ps3

[tilkinsc]

That was what I was getting at, @adenovan . Good find.

" Because it uses the PS3™ system's built-in Wi-Fi,"
Meaning the PS3™ understands the PSP wifi adhoc config thereof?

"The PlayStation®3 system must be connected to the Internet with a broadband network "
Makes me wonder if there is a patch, which is hacky...

"Each player must have both a PSP® system and a PS3™ system in order to use this feature"
This one is a 'no crap'

"Perfect for gamers with a PSP® system who want to play online but don't have access to a wireless internet connection "
Makes me seriously think it is a hack, and not really ad hoc and...
"with some games that include the Ad Hoc feature "
justifies my fear.

I am not sure how to use this either.

[adenovan]

At least it an official software from Sony. Some user tell me they have like 30 channel (psp network) on online mode, in ppsspp we can simulate this with 30 proadhocserver but the difference is we can't fake the server as legit psp adhoc network without hacking the client. if we can implement that server hack on ppsspp it will be great it can reduce complexity of playing adhoc in ppsspp. The mechanic looks like same with psp infrastructure mode.

[tilkinsc]

Oh. I was not aware that it was official from Sony. That makes it a bit different. The point of not knowing how to use it and how to obtain files to look at is still up there. I will do some research in the near future.

[tilkinsc]

I wonder if it is possible to create an ad hoc network of a certain type similar to psp, and name it what it would be expected to find. Then I can use software to see what the PSP tries to communicate with the machine. I should really learn more about the process of connecting via driver level.

[tilkinsc]

So I actually got somewhere. I started back up today. I made an ad hoc network on my computer named 'PSP_AULUS103901_L_MH3P000'. I got some broadcast packets from the network when the PSP turned on ad hoc (channel 11). It seems like it also made my computer break from having the ad hoc connection, and instead, connect to that network. Pretty neat. I could probably figure out something off of this. My psp died though, ~and my makeshift cord I made isn't charging it now :(~ is super picky

[tilkinsc]

I wrote some update on #7268 that should belong here. Referencing it. I should really create a post saying everything current as this may be better read as a single blob of text.

[ANR2ME]

I think Xlink Kai is able to fake a console or handheld broadcasts but requires a compatible network adapter (PSP-Xlink Mode or have promiscuous mode) with customized driver sometimes as i remember.

As i remember promiscuous mode is often used by hackers to monitor a network :)
https://landetective.com/products/internet-monitor/manual/traffic-analysis.html
https://www.teamxlink.co.uk/wiki/doku.php?id=evo7:how_to_tell_if_you_adapter_will_work_on_xlinkkai

[adenovan]

Once hydroque can dig that handshake on driver leve I guess we can start developing the psp mode adhoc.

Its on transport layer so the matching library need to modified as close as matching library on psp. If the network is not an ip protocol I think the current matching library will not understand what is going on (the pro adhoc server).

So for what im understanding if we planned to do a development on this mode every single ppsspp instance should run new matching library and its must close to the original on the psp or we modifybthe adhoc server to make it understand the handshake and register the game . The driver level handshake digging by hydroque just to make the host machine adapter connect to the adhoc network.

After matching library complete the game will open the socket they need to communicate to each other. Just make sure the communication is not blocked on the network.

Thats all, it should work if we can really dig what is going on in the original psp matching library.

[tilkinsc]

@adenovan
From what I know so far, and I believe I said this (too lazy to scroll up), the beginning of the handshake occurs when the PSP inits ad hoc and looks for an available network under the same ssid. If one isn't found, then it broadcasts one itself. It will try to do a handshake when one is found, though, so that is what I need to look into. I want to recapture some packets using microsofts network monitor.

[tilkinsc]

Todo: create a ad hoc Homebrew which emulates a standard game to observe ip address assignment between the two psp. I do not have two PSPs to do this with. Welp. Time to start a go-fund-me. https://www.gofundme.com/psp-for-developing-ad-hoc-with-pc

Reason: perhaps there are static IP addresses and handshaking is not necessary.

[adenovan]

@Hydroque im thingking the same perhaps the adhoc network created use static ssid and the ssid is hidden. And my assumption is that static ssid is unique for each channel. If the network not found the psp will create one. The group name or the game region code might be related to that network. There is some call to wlan adapter on hle function to see the adapter state. Looks like the call determine the network is adhoc mode or infrastructure mode

[tilkinsc]

adenovan: The ssid is broadcasted, definitely, and I don't believe there is a secondary network behind the scenes. The ssid broadcasted is unique to the game - it is whatever the programmer chooses with, seemingly, some stipulation. For example, PSP_AULUS103901_L_MH3P000 is the ssid used by MHFU in the first lobby. If we take a second and look at static IPs, you would think that 'broadcasting yet another ad hoc game right next to each other so that lobby 1 would get used and lobby 1 would try to get used again' would clash with each other. This is actually the case! This is what channels are used for (1, 8, 11, etc). MHFU sets up the game in a way where it will show the people in the lobby as in-game or even black out the lobby so you can't pick it. Static IP might be the way it is working. That being said, the plugin for the CFW shouldn't be a giant leap from supporting ad hoc to infrastructure. I wonder if it is just an easy if statement blockage to do infrastructure and some catalyst supporting it. Perhaps it is redefining symbols to point to other addresses.

Also, how tf would the game find out that there are people in the lobby already? Perhaps it doesn't support different channels? Even if it didn't, the network still exists... and this is definitely kernel/driver stuff. How curious.

[adenovan]

Most of The game find out people in the lobby after it connected to the matching library. It will call sceNetAdhocctlScan for looking other peer in the network.

Just find out how we can connect to matching library on psp and simulate that on the ppsspp. List of the network ssid for each game will be good to have. You can find adhoc supported title on proadhocserver.cpp and their game code region.

[JacobMrox]

How hard is it to add infrastructure support? all the PSP did was allow you to scan for wifi and create your access point to connect to, the rest is done in the games (the game chooses the server it wants to connect too etc..) How about programming it so that it directly uses the PC's network connection, no need for a GUI, anything is better than a freeze/crash I guess. I'm not sure how this stuff work but I assume it isn't harder than implementing Ad-hoc to lan functions or is it?

Because right now, when trying to connect via infrastructure (which should just use your internet connection technically if it was to be added as a feature in PPSSPP) you'd get this error message:
Main E[SCEUTIL]: HLE\sceUtility.cpp:497 UNIMPL 00000000=sceUtilityNetconfUpdate(2)'

Technically the pro plugin already establishes a Ad-hoc to infrastructure connection, some of its code could be reused for establishing infrastructure to PC network connection, but actual infrastructure support is still a necessity as well.

[tilkinsc]

@JacobMrox Thanks for voicing your concern. >MY< goal is to emulate a PC as a PSP so they can connect to eachother. I am not sure what your first paragraph was talking about, as it set up no context when claiming things. The PSP needs some form of connection establishment in order for an IP assignment - this means that the two devices are in the network and listening to each other. This is the standard communication.

Like I said many times here, the problem is the computer isn't assigned an IP address and the PSP wouldn't know who to send the packets to. With lack of understanding of what the PSP wants to establish the connection, research is being taking place.

[JacobMrox]

I understand, you're talking about Adhoc though, I wasn't claiming things, I was just saying that Adhoc to lan (being more complex) is being worked on but Infrastructure mode (non-adhoc) support is still not available, even though, in theory it would be easier to add.

As for Adhoc on PC not being able to communicate with PSP, you're right, the thing is, the PSP itself would scan for local devices that way, and speaking of IP, it needs an option to define the IP on the emulator, I suppose that would solve the issue, though I'm just speaking from my own experience, PCSX2 has that option for its plugins at least.

[tilkinsc]

I see what you are saying now with a little bit more specification. I haven't tried infrastructure mode and I don't know if ppsspp supports it. From the code I looked at, it all revolved around AD HOC and no hint of infrastructure. I get the layout that could be in place to fix it and I definitely see it as an easier option to add. The first part of what you described is ad hoc to lan, yes, but namely it is ad hoc to infrastructure.

--// Update //--

Well congratulations. The psp supports IPV6. It communicates directly with my computer with an unique IPV6 identifying both devices. At least at first look. The computer only negotiates connections made >from< the psp to the computer using IPV6. This means windows is recognizing IPV6 (duh).
I wonder what happens if I try to host a server on PSP on port whatever and try to connect to it. >It is definitely an established connection,< but it seems to keep pinging the computer over and over and over and over with broadcasts. It uses a UDP protocol.

[JacobMrox]

Yeah you're right, I should've been more specific, the Pro Adhoc Plugin is specifically designed to establish Adhoc (PSP Lan) to Infrastructure connection.
And that's why I'm surprised why isnt there Infrastructure support, since I'm planning to revive a certain online game servers and emulator/PPSSPP players wouldn't be able to join due to the lack of Infrastructure support.

[tilkinsc]

@JacobMrox
That will be an especially difficult feat. Usually you'd use logged, routed information to determine what packets are what and use them as you see fit. This is how private servers are made (along with hacking a client to use a certain IP address or route it to another IP). You would have to build on-top of ppsspp most likely. If you ask kindly,

The ad hoc psp plugin for CFW isn't necessarily wanted, for you run the risk of bricking your PSP. I think it is very stable. The problem you face is connecting to a certain IP and the port-forwarding issues that occur thereof. You rely on a psp to run the server with infrastructure, which it probably isn't built for - but made possible using coldbird's setup and ad hoc - which is the link to everything. Since ad hoc is the most predominant and we have this, it really isn't the focus, I can see the cheek turned on infrastructure for that reason.

//

I honestly think the PSP isn't communicating with IPv6... I really want to say it doesn't. Once I get my charger working again I will do more tests. ~I am in the process of purchasing one online now~ because my makeshift one is being a hassle now and I am too lazy to fix the wires - alas I have no solder.

Well more specifically what is going on is DHCPv6 (windows) or whatever is definitely communicating via non-ip route. The dhcpv6 just is the communication protocol for such an event, because hey it's DHCP's job. Well it doesn't actually need to assign such an IP and it may be a go-to to manage an unknown device or the DHCPv4 didn't work by error. Either way windows will try to set an ip and it will continuously send packets over and over for 5 seconds then disconnect then reconnect with the same strategy.

//

This post will be updated on my current actions.

~1. Download NMAP, a port scan utility to point it at my found IP addresses below to see if anything is possible communication-wise.~

~2. Upload Microsoft Network Monitor logs to display what I have been researching~

Computer Connected to PSP's Ad-hoc.zip
(see number 4 to 7)

1. Theorize what the packets mean ._.

2. Attempt to isolate all bytes in pairs of 4's with the ruling: first byte has to be > 0, last byte has to be > 0, in an attempt to locate what looks like a valid ip address trying to be imposed. Why? I dunno, perhaps I will find 192.168.2.6 (from number 4)
   ^ probably not gonna do

3. Use a tool to anchor a network sniffer in the ad hoc network between two PSP devices so I can sniff out anything. This might not be possible. This probably will not work because the two devices connect, yes, but the packet sniffer device is subject to number 4 below.

4. Perhaps I can find a tool that will try promiscuous mode as @ANR2ME suggested above. The reason for this is the idea is clear to actually find out what we are doing here.
   https://landetective.com/products/internet-monitor/manual/traffic-analysis.html
   https://www.teamxlink.co.uk/wiki/doku.php?id=evo7:how_to_tell_if_you_adapter_will_work_on_xlinkkai

The problem I have now is the requirements to use such a program.

1. I wonder if all packets are always the same basically. This might aid in the ability to decipher the packets the PSP sends. In theory it would seem the PSP would send packets over to other PSP to handshake. Like 'Player is playing mhfu on route AULUS32918_L_MHF2D000' or whatever it says. Then the other PSP agrees by the validity of the packet. (So basically if I make the hardware communication (loopback) send back the same packets it would be connected to kinda itself). I dunno. Just listing possibilities. This may be a valid option because number 1 below.

[tilkinsc]

This post will be updated on my findings.

1. When the psp tries to connect to the PC, it can't. It won't. In a loop of around 5 seconds, it will connect, disconnect for 5 seconds, and continue forever.

2. The PSP broadcasts valid wifi broadcast packets which are then attempted to be handled by windows. In failure to actually communicate, an ip from the autoconfig will be used under subnet mask 255.255.0.0. For example, 169.254,115.60. This may be a valid IP address to be used very briefly while the connection is open, however it is unbeknownst because lack of ad hoc binary on the PSP to test such a thing.

3. The PSP firmware assumes that, on channel 11 (doesn't matter what channel), there is another device's network to be able to connect to, if found. There is no actual communication problem with the two network adapters.

4. When the computer isn't connected to the network, but the PSP is broadcasting, on connection to the PSP's ad hoc network, windows tries to negotiate but it fails. It will eventually resolve to a autoconfig on window's side, but it retains an ip address of 192.168.2.6 dynamic. Windows actually sends a packet over to the PSP which is designated at 224.0.0.252 via UDP at port 5355 as 'Linked multicast name resolution. The process System (a windows process which is fancy for kernel services) also sends a packet to it, but the target ip address is 192.168.2.255, which is invalid for the most part but is associated with netbios at port 137 via UDP.

5. No matter what IP you try to use, no actual connection is made and therefore no data will be exchanged and servers will not resolve to host.

6. The WIFI beacon broadcasted use SNAP protocol and have octets bolstered to the packet. I think this may be the handshake. https://en.wikipedia.org/wiki/Subnetwork_Access_Protocol states that "SNAP supports identifying protocols by Ethernet type field values; it also supports vendor-private protocol identifier spaces." and "Subnetwork Access Protocol (SNAP) is a mechanism for multiplexing" (multiplexing: "incorporate into a multiplex signal or system.") so this is the communication the PSP has with the PC. It attempts to talk to it. "packets are usually transmitted with Ethernet II headers rather than with LLC and SNAP headers. On other network types, the LLC and SNAP headers are required in order to multiplex different protocols on the link layer, as the MAC layer doesn't itself have an EtherType field, so there's no alternative framing that would have a larger available payload." gives insight into what it is. The specific one let out by PSP is a broadcast.

7. The snap protocol seems to be sending out like 5 different packets all sent at like 0.10 seconds after one another or so while the PSP is hosting the network. Well... attached to them are the almighty blob which is an average of 82-86-242 bytes. I found my PSP's device name! That's it. I dunno what all the other scribbles mean or how to even go about discovering what the bytes add up to.

8. It may be a requirement to make a new driver for each modem. The problem is the uncertainty that I can communicate via hardware with the PSP before IP resolution like most of above and the post above talks about.

9. http://preview.tinyurl.com/ybn75q9e (http://tinyurl.com/ybn75q9e) This link to quora leads me to believe that there is ways to communicate two devices together without the need to actually connect.
   "On Windows machines, computers that are set up as DHCP clients but do not have access to a DHCP server will automatically assign themselves a Link-local IP address in the 169.254.0.0/16 range. This is the default setting in Windows and can be disabled. That means you can indeed use a crossover cable to hook up two computers to transfer files without statically assigning IP addresses.
   It is probably quicker to just set the IP address on each machine rather than wait for DHCP to time out, however." Which makes sense, correctly defines that if DHCP and (windows) APIA are disabled, no communcation would occur between the network's clients being connected. So there is definitely a step of resolution that needs to take place for the PSP to allow communication. This link also makes me believe that it is pretty much impossble. So basically a custom DHCP is what you could look at.
   Post-edit: Wait a minute. I wonder if the PSP /is/ the DHCP and its having trouble doing such a thing.

[adenovan]

@Hydroque if PSP to PPSSPP handshake is hard on adhoc network, can we just support infrastructure mode ? i mean PPSSPP and PSP Communciation must go into an access point with infrastructure mode on PSP.

looks like i might sniff my AP with 2 psp playing on infrastructure mode . and observe the packet send on initial connection.

im curious about the header on pspsdk apctl and specially this line...
https://github.com/pspdev/pspsdk/blob/master/src/net/pspnet_apctl.h

define PSP_NET_APCTL_EVENT_CONNECT_REQUEST 0

define PSP_NET_APCTL_EVENT_SCAN_REQUEST 1

define PSP_NET_APCTL_EVENT_SCAN_COMPLETE 2

define PSP_NET_APCTL_EVENT_ESTABLISHED 3

define PSP_NET_APCTL_EVENT_GET_IP 4

define PSP_NET_APCTL_EVENT_DISCONNECT_REQUEST 5

define PSP_NET_APCTL_EVENT_ERROR 6

define PSP_NET_APCTL_EVENT_INFO 7

define PSP_NET_APCTL_EVENT_EAP_AUTH 8

define PSP_NET_APCTL_EVENT_KEY_EXCHANGE 9

define PSP_NET_APCTL_EVENT_RECONNECT 10

that may the game handshake on infrastructure mode...

[tilkinsc]

Infrastructure is already supported through ad hoc via CFW plugin and coldbird ad hoc. It would be a waste of time to try to support because infrastructure involves an external matchmaking service from Sony. Although not all games.

I think this problem being completed sufficiently Bridges a gap we have in systems comnunicating that we don't have yet in existence. I don't have a second psp nor a way to packet sniff from other devices.

[adenovan]

yeah it already implemented but missing some implementation like create game mode , and all other stuff on adhoc ctl , im not sure how to observe that API on psp , can psp auto test use to inspect that API? some games may be compatbile when it implemented.

i really want to look at what that internal api doing with 2 psp playing adhoc mode. guess i need to setup the auto test ( not familiar with it )..

if it really hard to mess with PC driver , scanning pro adhoc server on the Access Point is not a bad idea like @ANR2ME said on other issues, we just need to modfiy coldbird aemu into scanning the access point . we need to implement that scanning on PPSSPP first.

[ANR2ME]

@adenovan i think it's two different issue, the scanning i mentioned before was just to make PPSSPP user easily connect to AdhocServer without typing the IP

While what @Hydroque trying to do (if i'm not mistaken) is understanding the proprietary adhoc protocol used by PSP (which i think it's a slightly modified from a standard adhoc protocol) so he can make emulators/PPSSPP communicate directly with PSP without using AdhocServer (even without CFW)

In a case like xlinkkai, if i'm not mistaken what it did is rerouting raw proprietary packets (accessed using promiscuous mode) from a PSP to another PSP through PC connected to internet, and the otherside (which is also a real PSP, even with OFW) will be able to recognized that proprietary packet automatically without xlinkkai need to understand the structure of that proprietary packet.
PSP <-> PC <-> internet <-> PC <-> PSP

However, in a case of communication between PSP and emulators directly using adhoc you'll need a network chipset capable of promiscuous mode to get the proprietary packets and also need to understand it's structure, i think both PSP & PC doesn't need to have IP when in adhoc as long the raw packet can be accessed, afterall PSP only use MAC to recognize each PSP in adhoc mode.

[adenovan]

wow interesting i did not know that xlinkai can forward that raw packet without replacing the adhoc module on psp. it just like and adhoc bridge over internet.

yep im aware what is he doing but (if i am not mistaken) its possibly need some setup or ask user to replace driver on PC (might be not compatble if hardware not supported the mode like some wlan chipste not supported on xlinkai), and what about android , can it use promiscuous mode too ( a rooted one maybe)?

what is aemu currently doing is tunnel the packet over ip by replacing some adhoc module right, and the replacement module is not complete yet on aemu plugin (some adhocctl state on create game mode is unimplemented) , need to improve that btw, and by implemented what you suggested on aemu we can make a module wihout user placing a text file on the psp. it might help to less complicate the setup needed for PSP as client and PPSSPP host the server to play locally . (hmm its still a hack over IP but its work on most of PPSSPP supported platform).

[ANR2ME]

since most linux driver support promiscuous mode, android might be the same, but you still need to have supported chipset

[adenovan]

@Hydroque i put your go fund me link to my online adhoc community, if i have more spare money from my daily work as full stack web developer i also will support your finding

[JacobMrox]

@hydroque, wrong, not all games use a matchmaking service from Sony. Some had their own, and some still connect to specific urls. Here is a screenshot from a game server I was working on reviving on a PSP (emulated on PS Vita)
https://cdn.discordapp.com/attachments/313690369579679744/374144796085977091/IMG_20171029_133621.jpg
Note: this is not adhoc nor adhoc to infrastructure/pro plugin, this is actual infrastructure I.E. Connected to internet and the game decides everything else, I just made a dns here to make it load some other page instead of the "service down" message.

[adenovan]

@JacobMrox if the server is already died it will be hard task for you , reviving a official online server may require the proper packet response asked by the games and provided by the online server which is absolutely need sniffing the packet from the official server and document it. hydroque already mention on althought not all games, some notes to make a private server if there is a legal for the online service make sure you re not violate it. some guy have a successfull story on rescued the outbreak ps 2 games server and behind that online server for sony there is exist a SNAP Protocol which may related to PSP online infrastructure. almost all of the private online server i meet sniff all the packet given by the official server before its shutted down..

[JacobMrox]

@adenovan, not a huge issue, we have some and other ways to still sniff them.

[tilkinsc]

@adenovan thank you I appreciate the contribution.

[tilkinsc]

So I know for sure that the PPSSPP requires the hardware to talk to it using its very own protocol. The file C:\Windows\System32\drivers\etc\protocol may be of use. However, I have not figured out how to write such a protocol.

The process goes like this after all: PSP creates standard Ad Hoc network, PSP finds Ad Hoc network and tries to connect to it by sending its very own protocol (IP/UDP/TCP, but a new one of these) request. If I can do this, I can mimic the two devices interacting with each other by debugging the core two responses from a PSP->existing network and existing network -> PSP.

The only reason I am stumped is I lack ability to send a correct message from the PC to the PSP. It should be almost exactly like how a PSP asks to join the existing Ad Hoc network.

https://docs.microsoft.com/en-us/windows-hardware/drivers/network/ndis-protocol-drivers2

I think the first step to actually doing this is create only a relay in that we can use the computer as a PSP but it actually reroutes EVERYTHING to the other PSP.

[tilkinsc]

Here are my findings on the packets.

Windows tries its hardest to do DHCP and formal handshaking to set up negotiations. But PSP don't care.

Capture.zip

Let's review the packets.

My PSP Fat 1000 Specs:
Mac - 00:16:FE:4F:EF:86
Nickname - P636
Firmware - 6.60 PRO-C
System Language - English
Date - 1/8/2011 1:37 AM

Test Game: Monster Hunter Freedom Unite English

The first 32 bytes of a packet are reserved for the PSP. This must be the packet descriptor. Each packet sent has data that changes and data that doesn't change. Most of this is constant. The first 16 bytes are always constant. Bytes 0x10 and 0x11 may change. In two different states.

State 1:
I am not really sure what happens here. I am assuming I am missing an additional packet where 0x10 and 0x11 would be 0x00 0x0C. Between these kinds of packets 0x10 always increments by _some number_.

      | 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F |
0000  > FF FF FF FF FF FF 00 16 FE 4F EF 86 88 C8 00 02
0010  > 0F 0C 00 00 00 00 00 00 00 00 00 00 00 00 00 00

State 2:
This is where bytes 0x10 and 0x11 are 0x01 0x02. After a 0x00 there exists your PSP name. Each of these packets are 166 bytes long and have the exact same contents. They happen every 5 or 7 packets. Probably only 5 due to timing :?

      | 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F |
0000  > FF FF FF FF FF FF 00 16 FE 4F EF 86 88 C8 00 01
0010  > 01 02 00 80 50 36 33 36 00 00 00 00 00 00 00 00   ....P636........

The delta between the increases on byte 0x10 between multiple packets make no sense. I don't see a clear pattern. At all. I don't want to rule out something to do with a formula and a for statement. As for the textual representation in hex it also doesn't make much sense. The number seems to rock back and forth though.

After these 32 bytes it's anyone's guess. This data doesn't say much and I can't find other packets with the same data sent between packets. Although, the packets don't go over 256 bytes in size. They can only be 96, 144, or 256 bytes.

Packet Sizes (Not including 166 byte State 2 packets):
96 bytes - 5
144 bytes - 7
256 bytes - 13
Total: 25 entries, 5 omitted which ensures my 'state 2 packet every 5 packets' theory

When I ran the two files through a similarity checker it didn't find anything between any of it besides the P636 nickname. I will do additional tests later to see if I can reproduce some changes to the 32 byte header, meaning if I changed the GH maybe.

I have coined together how to communicate between the two devices. I will program a test case for a PSP and put it to the test. Theory is using raw sockets and the mac address is known by these packets being sent every 5 seconds of the users in the area.

[ANR2ME]

So I know for sure that the PPSSPP requires the hardware to talk to it using its very own protocol. The file C:\Windows\System32\drivers\etc\protocol may be of use. However, I have not figured out how to write such a protocol.

The process goes like this after all: PSP creates standard Ad Hoc network, PSP finds Ad Hoc network and tries to connect to it by sending its very own protocol (IP/UDP/TCP, but a new one of these) request. If I can do this, I can mimic the two devices interacting with each other by debugging the core two responses from a PSP->existing network and existing network -> PSP.

The only reason I am stumped is I lack ability to send a correct message from the PC to the PSP. It should be almost exactly like how a PSP asks to join the existing Ad Hoc network.

https://docs.microsoft.com/en-us/windows-hardware/drivers/network/ndis-protocol-drivers2

I think the first step to actually doing this is create only a relay in that we can use the computer as a PSP but it actually reroutes EVERYTHING to the other PSP.

This is exactly what XLink Kai did :) and they need Promiscuous mode to do that.

https://en.wikipedia.org/wiki/Promiscuous_mode

In IEEE 802 networks such as Ethernet, token ring, and IEEE 802.11, and in FDDI, each frame includes a destination MAC address. In non-promiscuous mode, when a NIC receives a frame, it drops it unless the frame is addressed to that NIC's MAC address or is a broadcast or multicast addressed frame. In promiscuous mode, however, the NIC allows all frames through, thus allowing the computer to read frames intended for other machines or network devices.

Btw, if you want to analyze the packet isn't it better to use/create a simple adhoc homebrew than using a commercial game?

[tilkinsc]

Promiscuous mode nor xlinkkai isn't necessary at all. I know all but a few things now and its definitely possible without.

I said hi to the PSP :)

I changed the Mac Address of a state 2 packet to my adapter. I then sent a state 2 packet to Mac FF:FF:FF:FF:FF:FF just like the PSP did but I changed the name of P636 to something like Q636. The PSP responded with many packets.

[tilkinsc]

So heres how Ad Hoc works. Each PSP managers their own stuff, so its only locally done stuff. That's why MHFU has the limitation of client sided monsters. Anyways...

The PSP broadcasts indefinitely 5 unique size types of packets: 96, 144, 166, 256.

A 96 length packet is unknown and there is seemingly no respond to sending one of these out.
A 144 length packet is a unknown and there is seemingly no respond to sending one of these out.
A 166 length packet is a discovery packet, which is used to chain together negotiations between a PSP, and upon rebroadcast the PSP responds with a 326 length packet that has its broadcasting 166 packet in it (and ofc I swapped the P636 nick for Q636 where applicable), and upon receiving this 326 length packet it sends back a 292 length packet with no information being seen before.
A 256 length packed is a unknown and there is seemingly no respond to sending one of these out.

Moreover in the State 2 packets being sent out, each response tier seems to ++ byte 0x11.

I found out the timings of sending of each packet. Or at least roughly the timings, as some have a delay before they are sent again.

96 - 2 sends with a 0.26 delay between then 2 second delay
144 - 1 send of 0.66 delay, with maybe no additional delay
166 - 1 send of 1 delay, with no additional delay
256 - 1 send of 0.26 delay, with maybe no additional delay

I have not observed any attempt of IPs being set up.

[ANR2ME]

So heres how Ad Hoc works. Each PSP managers their own stuff, so its only locally done stuff. That's why MHFU has the limitation of client sided monsters. Anyways...

The PSP broadcasts indefinitely 5 unique size types of packets: 96, 144, 166, 256.

A 96 length packet is unknown and there is seemingly no respond to sending one of these out.
A 144 length packet is a unknown and there is seemingly no respond to sending one of these out.
A 166 length packet is a discovery packet, which is used to chain together negotiations between a PSP, and upon rebroadcast the PSP responds with a 326 length packet that has its broadcasting 166 packet in it (and ofc I swapped the P636 nick for Q636 where applicable), and upon receiving this 326 length packet it sends back a 292 length packet with no information being seen before.
A 256 length packed is a unknown and there is seemingly no respond to sending one of these out.

Moreover in the State 2 packets being sent out, each response tier seems to ++ byte 0x11.

I found out the timings of sending of each packet. Or at least roughly the timings, as some have a delay before they are sent again.

96 - 2 sends with a 0.26 delay between then 2 second delay
144 - 1 send of 0.66 delay, with maybe no additional delay
166 - 1 send of 1 delay, with no additional delay
256 - 1 send of 0.26 delay, with maybe no additional delay

I have not observed any attempt of IPs being set up.
Isn't because PSP's Adhoc doesn't use IP to communicate between each other and only use MAC?
PSP only use IP on Infrastructure mode, right?

[adenovan]

this 96, 144, 166, 256 packet is specific to mhfu game only the packet contain character name, model and bunch of other stuff. me personally really doesnt care about that packet it go throught pdpSend hle function which is broadcast packet on mhfu and each game has their unique packet size.

maybe you should only focus on 32bytes first packet there is the network scan and handshake implementation. psp only use mac address and port to do communications as long as you on same network and know the peer mac and port you can play together.

[tilkinsc]

I was actually wrong about it being 32 bytes. It is actually smaller than that. Something like 16 + <7 bytes. However, that clears some stuff up about what I have been viewing. I was originally confirming data transfer to the PSP in the first place (raw packet transfers are hard to figure out). I don't think that there is a handshake to begin with. MHFU communicates with peers through broadcasts and packets sent to specific MACs found being broadcast by the state 2 packet. I think the State 2 packet is a discovery packet. This means that it constantly is sent out to aid in the discovery of MACs. Each game could have their implementation of this though.

I will first need to be able to compile PPSSPP. This is my goal for now. Once I do that I can open up some sockets and gather some broadcast packets. I should be able to convert them into PPSSPP ready packets somehow.

[tilkinsc]

The types of packets we are dealing with are Ethernet Packets. This is what the basic component structure of an ethernet packet is...

[6 byte destination][6 byte source][2 byte protocol][blob data]

Ad Hoc is a connection-less network. Your NIC is likely to fake the connection of IPs using programs on your computer. This is namely done by Microsoft programs. So you wouldn't be able to 'get the PSPs IP' so to speak, because there isn't one in the first place. The PSPs don't have a handshake between PSP to PSP. They just appear in range and the program would reach out and connect depending on the broadcasting packet. The MAC is found this way also. I have no clue how the ports work though. They might have a unique identifier system for that.

So basically you just need to write a packet router so that PPSSPP can speak to the PSP. It should already be set up if the packets are the same. As for the game 'ports', this should be emulated publicly and broadcasted in the same manor as any other packet I have seen so far. This would be PSP bios.

I have confirmed that state 2 packet with length 166 is standard between games. Twisted Metal Head On (TMHO) is broadcasting the same exact packet. The only difference between MHFU and TMHO is that it is memset with FF at first. OR, since 0x90-0x93 is 0xFF, MHFU memsets a sub range inside the packet with 0x00.

[ANR2ME]

Port is part of Protocol header.

Btw, have you checked & analyze all the structs of adhoc server emulation? it's suppose to emulate a PSP's adhoc communication, so all those structs being used by adhoc should give enough info of what's in the raw packet headers being sent/recv by PSP, although it's wrapped in TCP/IP or UDP/IP due to emulation, but the raw struct should be the same one used by a real PSP.

[tilkinsc]

Could you drop me some sources?

[ANR2ME]

Could you drop me some sources?

It's there included in PPSSPP source, but if you want the standalone version you can get it here https://github.com/MrColdbird/aemu

[tilkinsc]

PPSSPP source is everywhere. I can't really tell what's going on anywhere from a glance. I will check this over and extract what information I can.

From a first glance it looks like the discover section is completely blank. Therefore I don't think I am going to find any struct data here that is relevant. To the state 2 packets. This is what I am after.

[adenovan]

only focus on 3 source file, look on proadhoc.h, proadhoc.cpp and scenetadhoc.cpp the source of discovery emulation mostly in hle function that have CTL name. ex : SceNetAdhocctl, ctl = computational tree logic.

[tilkinsc]

Ok I know enough to get started on writing test cases for data sniffing in the packets. I don't know all the ad hoc functions I need to create a test case though. I asked hrydgard for a functions list but he prolly ignored this post and deletes it in his email.

So I will take a look at learning some of this stuff.

[theAkito]

What's the status of this today?

[adenovan]

without cfw looks like no luck on psp side unless we know more information by reversing on the wlan hardware and the default encryption used on psp side to do adhoc , beside of that many sceNet , sceNetAdhocctl , sceNetAdhocMatching still not properly tested to document all the apis how its work.

[tilkinsc]

I could very well do this. I don't own two PSPs so that is my current roadblock.

[adenovan]

well then im thingking too much on host machine actually that running windows or android we need dynamic ssid on first step

PSP adhoc network is open wireless without password after all

SSID prefixed with PSP_A(GAMEID)_L_(CONTROLNAME)

when creating much test i found some driver crash captured by psplink maybe usefull

Thread ID - 0x02F47E49
Th Name   - SceWlanMac
Module ID - 0x02F5F231
Mod Name  - sceWlan_Driver
EPC       - 0x88198408
Cause     - 0x10000010
BadVAddr  - 0x8002013A
Status    - 0x00088603
zr:0x00000000 at:0x00000001 v0:0x8002013A v1:0x10000020
a0:0x881BD488 a1:0x881B4FE8 a2:0x00000070 a3:0x0000002D
t0:0xFFFFFFC8 t1:0x881B4FD0 t2:0xFFFFFFE8 t3:0x00000017
t4:0xA8020054 t5:0x00010000 t6:0x881B4F20 t7:0x88017028
s0:0x881B4FE8 s1:0x00000070 s2:0x881B4FE8 s3:0x881BD488
s4:0x0000002D s5:0xFFFFFFC8 s6:0x00000000 s7:0xFFFFFFFF
t8:0x00000001 t9:0x881B4F18 k0:0x00000000 k1:0x00000000
gp:0x881B5290 sp:0x882F2BC0 fp:0x00040000 ra:0x88198408
0x88198408: 0x8C430000 '..C.' - lw         $v1, 0($v0)

[MojoJojoDojo]

There is still hope for infrastructure/PSN emulation : https://www.youtube.com/watch?v=G7uvDFSw6A0
It's for ps3 but it might be similar to how PSP does it too.

[ANR2ME]

There is still hope for infrastructure/PSN emulation : https://www.youtube.com/watch?v=G7uvDFSw6A0
It's for ps3 but it might be similar to how PSP does it too.

Currently only support matchmaking for P2P multiplayer (probably similar to AdhocServer), while a true infrastructure mode (ie. Client-Server mode) relies on dedicated server hosted by each publisher, right? thus requires a private server (ie. DeSSE) for each game if the publisher are no longer hosting it.

But knowing how PSN authentication works like this might help in PSP network emulation (ie. implementation of sceNp) too probably, even though it will only support P2P over the internet similar to Adhoc emulation with Adhoc Server.
I think games like Patapon 3 doesn't relies on dedicated server on infrastructure mode (since you can choose as Host/Join on infrastructure mode), thus might works as long we can do the matchmaking on PSN emulation.

[tilkinsc]

This is nothing AdhocServer isn't doing. Thusly, infrastructure mode on the PSP had nothing to do with P2P connections, there was always a matchmaking server - lest everyone had to port forward their router to allow PSP IP connections inbound and outbound.

This thread is for Ad Hoc only. It is already bloated as is.

Oh and for the record, I already created a program to join PPSSPP thru matchmaking only thru pure ad hoc, on the game twisted metal.

[ANR2ME]

Oh and for the record, I already created a program to join PPSSPP thru matchmaking only thru pure ad hoc, on the game twisted metal.

That's pretty cool if you're able to communicate using pure adhoc (ie. real PTP/PDP protocol instead of emulated one using TCP/UDP). Are you using NPcap to send/recv the packet? Are those packets encrypted?

[tilkinsc]

PTP/PDP is just fancy talk. Protocols are just formats of raw packets i.e. they are typically just headers. TCP is a packet format standard aswell. Think of it like the 54 byte header to BMP files. The fact you call it PTP or PDP is meaningless, but as for how they are sent - thats useful. A TCP protocol will keep connections alive. A UDP just throws packets out as if it may never reach the destination. An IP protocol is just like UDP in the regard. Remember, the stack looks like this, raw -> IP -> UDP , raw -> IP -> TCP. Every UDP, TCP, and PTP, PDP packets have IP headers in that regard.

The packets sent and received are thru direct broadcast exclusively aka 'ethernet' (no, not your rj45 cable). You have to talk to the devices manually yourself with specific attention to the IP header. It's really easier done than said.

The packets themselves are not encrypted. The contents can be encrypted as the contents are 'implementation defined'. In my test case scenario, I joined the PSP lobby thru sheer packet sniffing and duplication followed by modification of the destination and sender fields of the IP header. Easy stuff.

As I only have one PSP, I can't tell what the specifics they share when connecting together are to mimic it. It will always be flawed because I can't then mimic the behavior in PPSSPP code.

[ANR2ME]

Ah i see, i guess you are using CFW-PRO? where sceNet* API already replaced with a wrapper for TCP/UDP so that it can be used on adhoc server over the internet, while the real adhoc protocol on PSP (ie. PDP/PTP) doesn't contains an IP and only use MAC.
If it is like that i think you're trying to reinventing the wheel (ie. adhoc server/aemu/pro-online project), unlike XLink Kai which is dealing with a true PDP/PTP protocol (ie. using promiscuous mode) that can works with OFW, but due to the encryption on the wireless adapter hardware, it doesn't know the contents of the packet and can only pass it through to the other side over the internet by wrapping it with TCP/UDP.

[tilkinsc]

Ah i see, i guess you are using CFW-PRO? where sceNet* API already replaced with a wrapper for TCP/UDP so that it can be used on adhoc server over the internet, while the real adhoc protocol on PSP (ie. PDP/PTP) doesn't contains an IP and only use MAC.

No. PDP/PTP implements IP headers, but a modified format. I haven't deciphered it all. Like I said, though, all of it is sent thru broadcasting aka 'ethernet' so there is never an exchange of ip address - just MAC. Any old wireless adapter can send out a raw packet into the air for a MAC to pick up. 802.11 is a standard, 802.11b 802.11g etc are implementations of that standard, 802.11b can talk with 802.11g. So its not difficult to do - and yes you should buy hardware that can supports the device. I know that both my old acer laptop and my netgear WNDA4100 both work with the PSP.

If it is like that i think you're trying to reinventing the wheel (ie. adhoc server/aemu/pro-online project), unlike XLink Kai which is dealing with a true PDP/PTP protocol (ie. using promiscuous mode)

You seem to forget the original intent of developing this software - I am trying to connect a PSP with a PC and interface with PPSSPP. Nothing more. Nothing less. Promicuous mode is only needed to sniff the packets for understanding what is going on in the immediate exchange to keep the PSP linked to the PC. From here on out I will not reply to anything including xlink kai - it is irrelevant to my purpose. There is no encryption between my products used for testing. The packets are sniffed fully. The data is readable. Games understand the packet data - encrypted or not. The only thing that matters is the packet headers and what the fields mean, when to send them out, and anything else.

Here is a diagram:

Perhaps I am trying to say is I am wanting to implement a driver which natively interfaces with the PSP and PPSSPP condones to the standard.

[adenovan]

@tilkinsc for you to analyze , its between vita , brite 3000 , psp-go adhoc broadcast over channel 6

adhoc_sniff.zip

[tilkinsc]

The packets seem to be missing the data attached to the packet. Anyways, it wouldn't be much help to me because I lack a development environment. Good news though, I just cashed in my CurseForge mod money and some money into a secondary psp 3000. I have both 1000 and 3000 now. It should be arriving Sept 3. -> Sept 9. and I will have a play with it then.

[adenovan]

most of the data is on llc layer ,

broadcom adapter lost almost all of packet transmitted even its near the wireless range thats why on the first attempt only wireless beacon shown.

I use usb stick adapter on 01.pcap as old as psp wireless adapter and the game packet is there

[tilkinsc]

It will be easier to parse it myself. I've already done some super cool things using a script talking to a psp. So I can't wait to actually jump into this project, knowing I understand a lot of it. Add this to my list of 30 things I am trying to do at once :)

Update:
PSP Arrive 8/31 by 8pm

Update:
The PSP was last used in 2009. They were a furry. I'm setting up the PSP to be ready for testing! Sadly, they are charging and I got CFW set up in the meanwhile. Going to get WireShark again and set up my modem setup.

[MojoJojoDojo]

This is very nice I hope for good progress on this.

[MojoJojoDojo]

If you are still working on it.
JPCSP is getting more progress with emulating local wireless/adhoc like a real psp would over HLE :
https://github.com/jpcsp/jpcsp/commits/master
Even got how the encryption works over wlan somewhat.

[adenovan]

drop resource on dfa the key

https://www.youtube.com/watch?v=LxCd80cYdOw&feature=youtu.be

[tilkinsc]

The project is going really well. I got a PSP talking with a computer, which then translates it over to another PSP for testing purposes. The latency is extremely low (lower if it was connected to PPSSPP). It's basically a 'proxy' at this point which also modifies said packet's data (if I want to). I am probably not going to add anything to PPSSPP because that would involve a lot more work than I can handle in its current state. Perhaps once I am done playing around with the packets exchanged I can open source it.

And yes, the computer is directly connected to the PSP. I have implemented the computer as being another player, which the fruit of it is another character spawns and acts exactly like another player.