something's wrong with network (MGS: PW)

[LuisFellp]

What happens?

when i try to play mgs:pw multilayer, using hotspot, it doesn't work. it gives a error.
on buildbot version (1.10.3-784) it gives a red text

i don't know the exact version were it started, but since 1.10.3 from play store, it doesn't work anymore

What should happen?

work

What hardware, operating system, and PPSSPP version? On desktop, GPU matters for graphical issues.

Exynos 7 Octa (7904), Android 10, 1.10.3-784

[Double-0-seven7]

You are using Android which can't use port offsets below 1024.
So this issue is not vaild.
Make sure its above it.

[LuisFellp]

@Pik-a-boo how i change it?

[LuisFellp]

nvm
i found it in seettings.ini, changed to 1025 and now is giving this error

[anr2me]

You need to use the same networking settings with the one that worked the last time for you (some networking settings might got reset if the last time you use was a very old one).
For Port Offset setting i recommend using 10000.
If you are using a wifi connection to play over the internet, you can also try enabling UPnP (assuming you didn't have DMZ/port forwarding being set up for this game), but if you only play on LAN with other players on the same wifi you won't be needing UPnP/DMZ/port forwarding.

May i know which PPSSPP version was the last time working for you for this game? how about 1.9.4 ?

You can try downloading older version of APK from here http://www.ppsspp.org/downloads.html

Anyway, you may want to consult your networking setting and router settings on official PPSSPP discord #multiplayer channel first, to make sure your issue is really a bug or just because of using the wrong settings. https://discordapp.com/channels/293316141479362560/508350481437818880

[Double-0-seven7]

MGS PW works good even now on the latest PPSSPP.
Could be an Android only issue because I only tried on PC.

[LuisFellp]

@anr2me on 1.9.4 it's working fine. used same settings that i used on 1.10.3 and 1.10.3-784

[anr2me]

Hmm.. that is strange.
It will probably takes time before i can test android since my phone is practically dead now, i will probably have a new phone within a week or two (waiting for a discounted price on Redmi 9 or Realme C12)

For the mean time it would be nice if you can pinpoint the last APK that worked for you, you can download them from the full list here https://buildbot.orphis.net/ppsspp/index.php?m=fulllist
Test it from the earliest v1.10 (assuming it's still working, if it's not you may need to test v1.9.3 as there is no 1.9.4 in the fulllist), jump at a large number to see if it broken or not, and go back half way and test again until you can shrink the gap.

PS: You may also want to test my recent test build first, just in case the issue has been resolved with my uncommited changes
Edit:
Win32&64: https://www.dropbox.com/s/i6699cyf1tzu29b/PPSSPP_1.10.3-adhocfix_Win32x64.zip?dl=0
Android(ARMv7): https://www.dropbox.com/s/dmz6jvesmm3uwp2/PPSSPP_1.10.3-adhocfix_ARMv7.apk?dl=0

[ghost]

@anr2me He is right.
the Co-op mode is not working properly and will give the screen that is in the first post here.
I thought it worked because the Versus mode works.
I tried playing from PC.
For some reason it decides to open port 537.

[ghost]

Picture of the log :

[anr2me]

@anr2me He is right.
the Co-op mode is not working properly and will give the screen that is in the first post here.
I thought it worked because the Versus mode works.
I tried playing from PC.
For some reason it decides to open port 537.

This issue doesn't seems to happen on Windows.
I tried to logs the port calculation with port offset 10000, before and after binding both are making use of the port offset, also the same before connecting, which is correct.

PS: the ports shown in socket error on my log are using the original port, so disregard that, but the socket error on binding in your logs are using the final calculated ports, i'll make them consistent later so it won't be confusing.

However, i did find disconnection issue due to timeout while in lobby, and have fixed it.

Looks like i need to test this on android later..

PS: When logging, try to use Info Log channel on at least SCENET, so i can see the HLE sequence too.

[ghost]

Ah right I did tried it on Linux because I didnt thought it will be different ...
At least now you know how it is.
Also I used port offset 0 because I played against a PSP user.

[anr2me]

Ah right I did tried it on Linux because I didnt thought it will be different ...
At least now you know how it is.
Also I used port offset 0 because I played against a PSP user.

if you're using port offset 0 it's normal for the game to use ports under 1024, you'll need sudo on linux for this, otherwise you won't be allowed to bind ports under 1024.

[anr2me]

I managed to "borrow" an android phone while the owner is sleeping ;) and test this game once since i need to put it back as soon as possible.

I found no issue related to port offset, it's shifting the port correctly, so the disconnection issue @LuisFellp had probably the "timeout" issue i bumped while testing this game on windows. (this game is using 63 seconds timeout when it happened, so it's just weird for the game not to receives any packet within 63 seconds)

However, after both players entering the mission, i walk around for a awhile on android and suddenly it just freezes permanently where i can't press anything or goes back to menu (ie. stop responding), i didn't had this issue on Windows tho, but probably need to do more testing just to make sure.

[hrydgard]

There are some recent reports of random freezes, might be unrelated to network. Trying to track it down but can't reproduce... #13494 for example

[anr2me]

After doing more logging to find out why it's getting timeout, something feels strange.

The timeout triggered by this code (now - peer->lastping) > context->timeout where u64_le now = CoreTiming::GetGlobalTimeUsScaled() and peer->lastping is at most also CoreTiming::GetGlobalTimeUsScaled() (but can be lower).

So how the heck the latest CoreTiming::GetGlobalTimeUsScaled()(now) ended having smaller number than an old one stored in lastping?? is this normal to happen on CoreTiming::GetGlobalTimeUsScaled?
PS: These timestamp usually being compared with value from sceKernelGetSystemTimeWide by the game.

And how come -86 > 63000000 = true?? weird stuff or may be because all variable being used are in u64_le thus getting weird behavior when the result is negative... it wasn't suppose to have negative number if now is always higher or equal than previous GetGlobalTimeUsScaled tho

[anr2me]

@LuisFellp Try this game again later after PR #13532 got merged

[Double-0-seven7]

Ah right I did tried it on Linux because I didnt thought it will be different ...
At least now you know how it is.
Also I used port offset 0 because I played against a PSP user.

if you're using port offset 0 it's normal for the game to use ports under 1024, you'll need sudo on linux for this, otherwise you won't be allowed to bind ports under 1024.

Just saying but maybe put a warning in brackets like you did with the UPNP option.
something like "(needs administrator access)".
You can put it as a red warning or on one of the options.

After doing more logging to find out why it's getting timeout, something feels strange.

The timeout triggered by this code (now - peer->lastping) > context->timeout where u64_le now = CoreTiming::GetGlobalTimeUsScaled() and peer->lastping is at most also CoreTiming::GetGlobalTimeUsScaled() (but can be lower).

So how the heck the latest CoreTiming::GetGlobalTimeUsScaled()(now) ended having smaller number than an old one stored in lastping?? is this normal to happen on CoreTiming::GetGlobalTimeUsScaled?
PS: These timestamp usually being compared with value from sceKernelGetSystemTimeWide by the game.

And how come -86 > 63000000 = true?? weird stuff or may be because all variable being used are in u64_le thus getting weird behavior when the result is negative... it wasn't suppose to have negative number if now is always higher or equal than previous GetGlobalTimeUsScaled tho

I wonder if this explains why games gets randomly stuck in a black screen or loading sometimes.

[anr2me]

Just saying but maybe put a warning in brackets like you did with the UPNP option.
something like "(needs administrator access)".
You can put it as a red warning or on one of the options.

Port under 1024 restrictions have nothing todo with UPnP and have nothing todo with PPSSPP either, it's a generaal restriction on most Operating System for all application (system app or certified app might not have this restriction i think, on android APK won't be allowed to bind these port as i remember)

I wonder if this explains why games gets randomly stuck in a black screen or loading sometimes.

Black screen are most-likely a crash in PSP game, it probably have nothing todo with timeout.
Timeouts should shows disconnection/desync dialog box on screen (those grayed grayed screen or custom dialog box)

[ghost]

Well looks like it's not a black screen issue but a timeout out so opened a seperate issue on this.

[LuisFellp]

@LuisFellp Try this game again later after PR #13532 got merged

I'm unable to test because my other phone bricked and I don't have noone to lend me one to test