search

hrydgard / ppsspp

A PSP emulator for Android, Windows, Mac and Linux, written in C++. Want to contribute? Join us on Discord at https://discord.gg/5NJB6dD or just send pull requests / issues. For discussion use the forums at forums.ppsspp.org.
https://www.ppsspp.org
Other
10.81k stars 2.12k forks source link

PSP to Computer AD HOC #9334

Open tilkinsc opened 7 years ago

tilkinsc commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

Alright fair enough.

hrydgard commented 7 years ago

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

tilkinsc commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

ghost commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

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

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

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

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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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.

  2. It is good to have reference material.

  3. 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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

@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.



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

[Computer Connected to PSP's Ad-hoc.zip](https://github.com/hrydgard/ppsspp/files/1189808/Computer.Connected.to.PSP.s.Ad-hoc.zip)
(see number 4 to 7)

3. Theorize what the packets mean ._.

4. 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

5. 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.

6. 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.

7. 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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

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

adenovan commented 6 years ago

@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 commented 6 years ago

@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 commented 6 years ago

@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..