Kenka Bancho won't stay connected to peer in Night Out mode

[usagiDamaci]

Game or games this happens in

ULUS-10442 - Kenka Bancho: Badass Rumble

What area of the game / PPSSPP

In the Night Out mode.
By choosing this mode from the main menu, selecting "With friend", loading any save data, and at last selecting "Leave". Once you leave, it turns on the network and then the lobby shows up, with a message box on top that says "Looking for a buddy to invite".

The emulator's chat works fine once you connect to a peer, but they get disconnected and reconnected every few seconds (with "PPSSPP Joined" repeating non-stop), and nothing happens in-game. The message box always stays there.

Here's a screenshot of the debugger:

My friend and I use the default Adhoc server with port offset set to 10000. We've successfully connected many times before in other games and we have both allowed the ports through firewall (10100, 10200 - Game's default ports are 100 and 200).

What should happen

It's really hard to find a video or anything where someone is playing the game in this mode and in multiplayer, but I imagine the message box should disappear, the peer gets added to one of the slots in the lobby, and once all preparations are done, both players probably start outside the Inn at last.
*Not sure if this gives some hints on how the connection may work different to other games, but I've read once that you can connect up to 3 players, also seen in the lobby having 3 slots.

Logs

No response

Platform

Windows

Mobile device model or graphics card (GPU)

AMD Radeon HD 3000

PPSSPP version affected

1.17.1

Last working version

No response

Graphics backend (3D API)

Direct3D 11

Checklist

• Test in the latest git build in case it's already fixed.
• Search for other reports of the same issue.
• Try resetting settings or older versions and include if the issue is related.
• Try without any cheats and without loading any save states.
• Include logs or screenshots of issue.

[anr2me]

It works fine on multiple instance tho

Are you using public adhoc server? which one?
Also, you may want to use UPnP or DMZ when testing a game for the first time instead of manually opening the port, in case there are more ports than need to be opened.

I'll need to test whether this game using clumsy later when i had the time, in order to find out whether this game is sensitive to high latency or not.

[anr2me]

I've tested this game with simulated 250ms latency and 15% chance of packet loss using clumsy, and the game still works fine

You should try a different public adhoc server or use built-in adhoc server(with VPN if you/your friend are behind NAT) to see whether there is an issue with the public adhoc server you're using.

[anr2me]

It even works with simulated 300 ms latency and 20% chance of packet loss O.o this game seems to be one of the most stable game i've seen.

Unfortunately, it didn't works properly with 25% chance of packet loss, can't even see the other player in lobby.

[usagiDamaci]

It even works with simulated 300 ms latency and 20% chance of packet loss O.o this game seems to be one of the most stable game i've seen.

Unfortunately, it didn't works properly with 25% chance of packet loss, can't even see the other player in lobby.

Woah, that's impressive, tbh. I was about to say something about high latency probably being the culprit because of it essentially playing like an MMO, but we have around 190 - 205 latency at worse.
Guess I'll have to check the packet loss, because that could easily be it, even if my friend isn't too far away.

Are you using public adhoc server? which one? Also, you may want to use UPnP or DMZ when testing a game for the first time instead of manually opening the port, in case there are more ports than need to be opened.

I'll need to test whether this game using clumsy later when i had the time, in order to find out whether this game is sensitive to high latency or not.

Ah, we use the socom.cc public server, and while I'm aware it isn't the most ideal thing to do, we could only play by opening ports due to some restrictions on my friend's firewall (it was the simplest solution we found that worked.)
Before that, we used to play via ZeroTier, but that didn't work either for us with Kenka Bancho, while it did work with Metal Slug Anthology.

[usagiDamaci]

In the end, I'll try some more things later when my friend can, and I'll come back to report if the public server or a high packet loss had to do with it, or if we find something else that helps.

[anr2me]

You can also try hosting your own adhoc server instead of relaying the packets through VPN, by enabling built-in adhoc server and forward the adhoc server port (TCP 27312 unaffected by port offset), only one adhoc server needed.
But both of you need to connect to the adhoc server using public IP in the PRO adhoc server IP address setting, so that the adhoc server won't see it as LAN/localhost IP.

PS: We should probably shows the public IP in the list too when available, since the adhoc server port is always forwarded when UPnP is enabled, may be retrieving the public IP using public API like https://api.bigdatacloud.net/data/client-ip or https://api.ipify.org?format=json or https://ipapi.co/ip/

[usagiDamaci]

You can also try hosting your own adhoc server instead of relaying the packets through VPN, by enabling built-in adhoc server and forward the adhoc server port (TCP 27312 unaffected by port offset), only one adhoc server needed. But both of you need to connect to the adhoc server using public IP in the PRO adhoc server IP address setting, so that the adhoc server won't see it as LAN/localhost IP.

Right now we've just tried to connect via my public IP as the PRO Adhoc server, and once again, no luck :(

So far, as I didn't know of anything better to try, I pinged him through cmd and there was no packet lost. Then we tried playing with my IP. First with the PRO Adhoc option On in my friend's side, then with it Off, also on his'. Both times, we could chat to each other, but everything else worked the same. It kept connecting and disconnecting.

We both had WLAN on, server set to my IP, and UPnP on. Then we turned on Forced First Connect, Simulate UMD, and Minimum Timeout to 50 ms, so as to test if that helped with anything.

At least, here's a log I made with DebugLog on the last try (everything set to Error except for SCENET set to Debug):
ppsspplog_04032024.txt

[Double-0-seven7]

This game definitely works on a public server.
I even got gameplay of it recorded here:
https://youtu.be/kp4yfPPyhRs?si=wu4Oek6mq1OTzILu
I think that at first the game runs fine for both players but slowly it starts to desync.
Not sure if thats the intended behaviour online but it is what it is.

[anr2me]

Desync after a long game session are pretty common i guess, i even experiencing it while playing MH game with a friend on LAN long time ago using PPSSPP, but not the kind of desync that gets you disconnected, it was a desync where my friend was attacking a monster but from my side of view he's attacking empty space.

Also during my test with one of Naruto game (was it Kizuna drive? i forgot), the miss-positioning kind of desync gets worse at a higher chance of packet loss.
Probably these kind of games use some kind of accumulation on the coordinate, thus when some packets got lost it didn't get accumulated and eventually getting the wrong coordinate.

[anr2me]

You can also try hosting your own adhoc server instead of relaying the packets through VPN, by enabling built-in adhoc server and forward the adhoc server port (TCP 27312 unaffected by port offset), only one adhoc server needed. But both of you need to connect to the adhoc server using public IP in the PRO adhoc server IP address setting, so that the adhoc server won't see it as LAN/localhost IP.

Right now we've just tried to connect via my public IP as the PRO Adhoc server, and once again, no luck :(

So far, as I didn't know of anything better to try, I pinged him through cmd and there was no packet lost. Then we tried playing with my IP. First with the PRO Adhoc option On in my friend's side, then with it Off, also on his'. Both times, we could chat to each other, but everything else worked the same. It kept connecting and disconnecting.

We both had WLAN on, server set to my IP, and UPnP on. Then we turned on Forced First Connect, Simulate UMD, and Minimum Timeout to 50 ms, so as to test if that helped with anything.

At least, here's a log I made with DebugLog on the last try (everything set to Error except for SCENET set to Debug): ppsspplog_04032024.txt

It's difficult to tell what happen with only one side of the log, since we need to compare the time stamp on both side.

For example, the games seems to be communicating properly for a while, but suddently your friend left the group for unknown reason (since we can't see the logs on your friend side at the same time stamp)

35:23:392 MyThread-Net D[SCENET]: HLE\sceNetAdhoc.cpp:1746 sceNetAdhocPdpSend[2:10200](BC): Sent 92 bytes to 200.xx.xx.xxx:10100

35:23:393 MyThread-Net D[SCENET]: HLE\sceNetAdhoc.cpp:1746 sceNetAdhocPdpSend[2:10200](BC): Sent 92 bytes to 200.xx.xx.xxx:10100

35:23:425 MyThread-Net D[SCENET]: HLE\sceNetAdhoc.cpp:1746 sceNetAdhocPdpSend[2:10200](BC): Sent 92 bytes to 200.xx.xx.xxx:10100

35:23:426 MyThread-Net D[SCENET]: HLE\sceNetAdhoc.cpp:1746 sceNetAdhocPdpSend[2:10200](BC): Sent 92 bytes to 200.xx.xx.xxx:10100

35:23:430 MyThread-Net I[SCENET]: HLE\proAdhocServer.cpp:1003 AdhocServer: PPSSPP-Friend (MAC: 9c:2c:c5:xx:xx:xx - IP: 200.xx.xx.xxx) left ULUS10442 group MATCH
35:23:431 MyThread-Net I[SCENET]: HLE\proAdhoc.cpp:1479 Received 5 Bytes of Data from Adhoc Server
35:23:431 MyThread-Net D[SCENET]: HLE\proAdhoc.cpp:1655 FriendFinder: OPCODE_DISCONNECT
35:23:431 MyThread-Net I[SCENET]: HLE\proAdhoc.cpp:1658 FriendFinder: Incoming Peer Data Delete Request...
35:23:431 MyThread-Net I[SCENET]: HLE\proAdhoc.cpp:488 Removing Friend Peer 9c:2c:c5:xx:xx:xx [200.xx.xx.xxx]
35:23:539 MyThread-Net I[SCENET]: HLE\proAdhocServer.cpp:693 AdhocServer: PPSSPP-Friend (MAC: 9c:2c:c5:xx:xx:xx - IP: 200.xx.xx.xxx) stopped playing ULUS10442
35:23:950 MyThread-Net I[SCENET]: HLE\proAdhocServer.cpp:550 AdhocServer: New Connection from 200.xx.xx.xxx
35:23:972 MyThread-Net I[SCENET]: HLE\proAdhocServer.cpp:644 AdhocServer: PPSSPP-Friend (MAC: 9c:2c:c5:xx:xx:xx - IP: 200.xx.xx.xxx) started playing ULUS10442
35:24:097 MyThread-Net I[SCENET]: HLE\proAdhocServer.cpp:907 AdhocServer: PPSSPP-Friend (MAC: 9c:2c:c5:xx:xx:xx - IP: 200.xx.xx.xxx) joined ULUS10442 group MATCH
35:24:101 MyThread-Net I[SCENET]: HLE\proAdhoc.cpp:1479 Received 139 Bytes of Data from Adhoc Server
35:24:101 MyThread-Net I[SCENET]: HLE\proAdhoc.cpp:1584 FriendFinder: Incoming OPCODE_CONNECT [9c:2c:c5:xx:xx:xx][200.xx.xx.xxx][PPSSPP-Friend]
35:24:101 MyThread-Net W[SCENET]: HLE\proAdhoc.cpp:230 Friend Peer Already Existed! Updating [9c:2c:c5:xx:xx:xx][200.xx.xx.xxx][PPSSPP-Friend]
35:24:126 MyThread-Net D[SCENET]: HLE\sceNetAdhoc.cpp:1746 sceNetAdhocPdpSend[2:10200](BC): Sent 92 bytes to 200.xx.xx.xxx:10100

35:24:127 MyThread-Net D[SCENET]: HLE\sceNetAdhoc.cpp:1746 sceNetAdhocPdpSend[2:10200](BC): Sent 92 bytes to 200.xx.xx.xxx:10100

35:24:159 MyThread-Net D[SCENET]: HLE\sceNetAdhoc.cpp:1746 sceNetAdhocPdpSend[2:10200](BC): Sent 92 bytes to 200.xx.xx.xxx:10100

35:24:160 MyThread-Net D[SCENET]: HLE\sceNetAdhoc.cpp:1746 sceNetAdhocPdpSend[2:10200](BC): Sent 92 bytes to 200.xx.xx.xxx:10100

[usagiDamaci]

Sadly, my friend couldn't play lately, but I tried to connect with myself and see what happened. Two instances with separate settings (as Player1 and Player2), different MAC addresses, different save data, and using socom.cc.

Still the same results.

At least, I could ask my friend about it and he told me his screen was also stuck here, back when we tried to play together. Though I'm thinking it's something on my end that I'm still not figuring out...

Not sure if this will help, but since the instances couldn't connect either, I might as well share the logs.
ppsspplog_07032024_A-info.txt
ppsspplog_07032024_B-info.txt

[anr2me]

You can't use socom or any public server (not even LAN IP will works) with multiple instance, multiple instance only works with localhost (and any other non-localhost servers can't works/play together with localhost)

[anr2me]

Btw, there is another possibility why on your friend side the game decided to leave the group and rejoined.

The game send data using broadcast to all players (indicated by the (BC) in the logs, thus the game didn't know (nor care) whether the data have successfully sent to all players or not.
The game on your friend side might be unable to receives the data due to port remapping on the public IP (ie. similar to "Data from unknown port" issue on AdhocMatching/GameMode), and after a certain time elapsed (ie. in-game timeout) without receiving anything (because the port that got opened was different), the game probably left the group to start over again.

Unfortunately we can't detects, whether there are port remapping occurred or not when the game use an arbitrary socket/port, since the sender and receiver port can be anything (depends on the game).
Unlike games that use AdhocMatching/GameMode libraries where we know that the sender and the receiver supposed use the same port (using a single socket), thus can detects when the sender was using a different port.

Not really sure why a port remapping can occurs, as there aren't much information about it, a possible reason is that somewhere between your router and your ISP's router(s), the port your friend tried to forward was already taken, in this kind of situation, there are 2 possible way for the involved router to handle the case:

1. Remap the port to a different (most-likely random) port.
2. Replace the owner (internal IP) of the port to the new owner, but this can be bad for security reason, as someone on the same network can took over a web service with malicious intent. This is less-likely to happen if your ISP's router were configured by prioritizing security. However, on a cheap router i had, taking over a mapped port owned by a different IP/device on the same network was possible by using UPnP during my test long ago.

Anyway, if a port remapping did occurred, try changing the port offset to a different value (ie. 5000, 20000 or even 50000) to see whether it can solve your/your friend issue.

[usagiDamaci]

I've been busy lately but over the weekend we managed to make it work at last!
(We even reconnected the game more than twice to make sure it didn't just randomly work, lol)

Soo, as soon as I saw your last post, we decided to try the game again over the night. First we made sure we could connect to each other in another game. It was working alright, so we moved to Kenka Bancho again, and at last, we immediately connected.

We had turned on Forced First Connect, Simulate UMD, changed Port Offset to 20000, and used socom.cc as the Adhoc Server. Minimum Timeout at 50 ms actually gave us more lag, and it seems that the game runs slower on the host's side. Other than that, we got no disconnects and surprisingly never desynced as well.

...
Anyway, if a port remapping did occurred, try changing the port offset to a different value (ie. 5000, 20000 or even 50000) to see whether it can solve your/your friend issue.

About the ports, I think you might be right about the port remapping, but I also came to think that maybe his or my ISP were blocking the 10000 offseted ports (10100, 10200), as I've read that some trojans were reportedly using those not too long ago. But no idea.

Kinda long but wanted to specify what we did and saw, in case it would help someone else in the future regarding what to check or try.

[usagiDamaci]

And of course, thanks a lot for helping us out with this, @anr2me!
It might've been something silly but we found a solution .

[anr2me]

Regarding "Minimum Timeout" it only made a difference when your actual latency exceeding the minimum timeout.
It's only useful on games that disconnects (and gives up) after timeout reached instead of retrying, so people with high latency can still play (but with delays caused by high latency) instead of getting disconnected (Well, it's depends on how the game handles the timeout cases).

A possible reason, why it slows down the game, probably because the game use short timeout on every frame, thus causing the frames to be delayed.
For example, if the game supposed to use 5ms timeout while checking incoming data every frame (on 30 FPS games each frame need 1000/30 = 33.33 milliseconds), so when the timeout got overridden with 50ms each frame will took additional (up to) 50ms on cases where there are no data that can be received immediately, but if there are data ready to be received it won't take much time.

Anyway, since this issue has been resolved, i'll close this.

PS: i wondered whether we should use a different default Port Offset value (ie. 13000 or 20000), if the lower port range of 10000 are really used by trojans/malwares, since most adhoc games seems to use ports with small numbers.
And, according to this, ports within the range 10000-20000 might be used by VoIP.