Packets stop after ship_server receives 0x006F from PSOPC client

[GoogleCodeExporter]

What steps will reproduce the problem?
1.  Login with PSOPC client.
2.  Select ship and block.
3.  Create new game lobby at counter.

What is the expected output? What do you see instead?
PSOPC client joins new game lobby and client<->server communication continues.

Instead, the server receives 0x6F (client done bursting) and sends 0x1D (ping), 
but receives no response from client.  At this point, all communication stops 
for all lobbies; that is, all other clients also stop communicating entirely.

What version of the product are you using? On what operating system?
PSOPC client from Ives torrent (not Blue Burst) modified to point to my own 
server.  Server is SVN r665 running on Debian unstable x86_64.  Have tried 
running ship_server under MacOS X 10.8.3 64-bit with the same results (shipgate 
was still running on the Debian box, though).

The clients are running under wine (on both MacOS X with Wineskin 1.5.26 engine 
and under Debian with wine 1.5.6).  But do note that both clients work fine 
when connecting to sylverant.net.

Please provide any additional information below.
The default lobbies work fine -- both clients can see characters moving about, 
chats, etc.  The moment one player creates a new game lobby, all clients stop 
talking to the server.

The only thing I don't currently have configured is the v2maps, because I'm not 
entirely sure which ones to use and how to name them correctly (maybe you'd be 
so kind as to point me to a working set?).  I am, however, under the impression 
that it should work without them.

Even more information:  I realize from reading through your blog that you don't 
want people making their own public servers.. I'm trying to set this up for 
just my wife and I to play, and secondarily, because I like to tinker with this 
kind of stuff :)

Original issue reported on code.google.com by wah...@gmail.com on 31 Mar 2013 at 1:56

[GoogleCodeExporter]

The map data probably has nothing to do with this, although it may well be 
related to Issue #1. Linux is not a supported platform because of that bug, 
which is not even a bug with Sylverant itself, but an incompatibility between 
what PSO expects and what Linux's TCP/IP stack does.

Unfortunately, until someone finds a workaround for that problem, Sylverant 
will stay unsupported on Linux. If you want to tinker around with it, I 
recommend using FreeBSD as your OS, as that's actually what I run the main 
Sylverant server on (so it is the only OS I actively test it on).

I can tell you that it is completely unrelated to the map data, as that only 
impacts the ability to set up server-side drops.

As this is likely another incarnation of Issue #1, I'm going to mark this one 
closed as a duplicate of Issue #1.

Original comment by bluecrab on 6 Apr 2013 at 1:56

• Changed state: Duplicate
• Added labels: OpSys-Linux, Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

I thought the same at first, which is why I compiled it under MacOS X, where it 
does the same thing.  Also, it's not exactly the same behavior as you describe 
in Issue #1.

Original comment by wah...@gmail.com on 6 Apr 2013 at 1:59

[GoogleCodeExporter]

For my own sanity, I need to know.. in Issue #1, if a user creates a new game, 
can they still talk to the server provided no one else joins the game?  That 
is, can they issue commands like "/bstat" and can they get a quest list?  
Because my problem currently is that as soon as the game is created, all 
communications (including slash commands) halt for all users on the ship.  
There are no packets sent or received, to or from anyone, after a game is 
created.

This happens even if the ship server is running on a MacOS X box as well, so 
it's hard to believe it's the TCP stack bug you found in Issue #1, given the 
two OSes have very different TCPP stacks.

Original comment by wah...@gmail.com on 6 Apr 2013 at 2:13

[GoogleCodeExporter]

You do bring up a good point about the thing with Issue #1. That is 
specifically with joining an already existing team, not with creating a new one.

That said, I believe I've found the issue at fault here (at least, everything 
works on Mac OS X with this fix, so I'm figuring it'll fix it on Linux here 
too). Basically, what's going wrong is that when the done burst packet is 
received, the server locks a particular mutex twice, which it shouldn't do. I 
guess that on FreeBSD, the default mutex type is the error checking or 
recursive mutex, hence why it works there, but not on other platforms.

Anyway, this should be fixed in r666.

Original comment by bluecrab on 6 Apr 2013 at 3:18

• Changed state: Fixed
• Added labels: OpSys-OSX

[GoogleCodeExporter]

I swear I thought I checked the locks/unlocks, as I thought that was what was 
going on.. good catch!

Original comment by wah...@gmail.com on 6 Apr 2013 at 3:28

[GoogleCodeExporter]

The function that was causing the problem was lobby_handle_done_burst(), in 
lobby.c... In case you were wondering.

There are exactly two places that call that function (once in block.c and once 
in lobby.c), and in both places the lobby's lock is already held, so locking it 
again is definitely not the right thing to be doing.

Thanks for reporting the issue, and let me know for sure whether this fixes the 
problem on Linux as well (I strongly suspect it will).

Original comment by bluecrab on 6 Apr 2013 at 3:31

[GoogleCodeExporter]

Yeah I see it in your commit.  I've been going over your code over the last two 
weeks as much as I could (with two little kids biting my ankles and my RL job 
always getting in the way), trying to understand it all.  Ultimately I'd like 
to help you fix Issue #1, which is why I finally filed this bug, after I 
convinced myself it wasn't Issue #1.

Off record, if you could get ahold of me, I'd still like to know how to 
populate the v2 maps, if for no other reason than to satisfy my own OCD.. I'm 
guessing they come from the client maps but I'm really having issues figuring 
out how they map 1:1 to what your server is expecting.

Original comment by wah...@gmail.com on 6 Apr 2013 at 3:38

[GoogleCodeExporter]

It works!  Thanks again!  I will let you know when I make more progress on 
Issue #1.

Original comment by wah...@gmail.com on 6 Apr 2013 at 4:26

[GoogleCodeExporter]

Awesome. Marking this one as completely done then.

Original comment by bluecrab on 6 Apr 2013 at 9:05

• Changed state: Verified

[GoogleCodeExporter]

Just FYI, I'm seeing an issue similar to this again.  I don't know yet exactly 
what causes it, but I think it's after completing a quest when it warps us back 
to the lobby.

I'll spend more time looking into it shortly, but figured I'd let you know.

Original comment by wah...@gmail.com on 18 Apr 2013 at 11:59