OPL 0.8 network game name corruption

**mark_k** · 03-30-2011,11:44 AM

Hi,

I've been having some strange problems using OPL 0.8 loading games over the network.

Sharing a folder on my PC works fine, games load with no problems. I was connecting to port 445 on the PC.

Next I copied some games onto an old Buffalo HD-H250LAN NAS drive. I created CD and DVD directories for the ISO images and copied them over. Connecting to the NAS using my PC, I can see the files and they have the correct names.

I set OPL to load games from the NAS. I had to use port 139; I guess the NAS doesn't support access on port 445. OPL found the games and a few work fine. However, most filenames appear corrupted in the OPL game list. Starting a game whose name is shown corrupted doesn't work; OPL hangs with a yellow screen, probably because it's trying to read the wrong filename. The corrupted game names have "garbage" from the previous game name at the end. Maybe OPL is forgetting to clear a string buffer before copying the next filename there?

An example. The filename
"SCES_542.19.Buzz Junior Jungle Party PALrip.iso"
appears correctly in the OPL menu as
"Buzz Junior Jungle Party PALrip"
But the file
"SCUS_971.12.Extermination rip.iso"
which is alphabetically next in the directory, appears incorrectly as
"Extermination rip.isorty PALrip"

I've uploaded a couple of screenshots to show the corrupted names: http://i.imgur.com/x0zGjl.jpg and http://i.imgur.com/aHnig.jpg.

Here are some more examples. Real filename then OPL menu name. The rightmost part of each corrupted OPL name corresponds to the end of the previous game name. The "good" game names are only good because they are the maximum length allowed (32 characters), so overwrite the entire buffer.

Code:

SCES_515.92.Formula One 2003 PAL rip.iso	 - Formula One 2003 PAL rip		[good]
SCES_542.19.Buzz Junior Jungle Party PALrip.iso	 - Buzz Junior Jungle Party PALrip	[good]
SCUS_971.12.Extermination rip.iso		 - Extermination rip.isorty PALrip	[BAD]
SCUS_973.28.Gran Turismo 4 rip.iso		 - Gran Turismo 4 rip.isoty PALrip	[BAD]
SCUS_974.72.Shadow of the Colossus.iso		 - Shadow of the Colossus.isoALrip	[BAD]
SCUS_975.58.Jak and Daxter The Lost Frontier.iso - Jak and Daxter The Lost Frontier	[good]
SLES_506.84.Medal of Honor Frontline PAL rip.iso - Medal of Honor Frontline PAL rip	[good]
SLES_508.73.Reign of Fire PAL rip.iso		 - Reign of Fire PAL rip.isoPAL rip	[BAD]
SLES_512.58.James Bond 007 Nightfire PAL rip.iso - James Bond 007 Nightfire PAL rip	[good]
SLES_525.04.Trivial Pursuit Unhinged PAL rip.iso - Trivial Pursuit Unhinged PAL rip	[good]
SLES_525.70.Area 51 PAL.iso			 - Area 51 PAL.iso Unhinged PAL rip	[BAD]
SLES_527.37.Obscure PAL.iso			 - Obscure PAL.iso Unhinged PAL rip	[BAD]
SLES_535.87.Garfield II PAL rip.iso		 - Garfield II PAL rip.isod PAL rip	[BAD]
SLES_537.34.50 Cent Bulletproof PAL rip.iso	 - 50 Cent Bulletproof PAL rip.isop	[BAD]

**mark_k** · 03-30-2011,01:52 PM

Some more info about this...

I noticed that in addition to the corrupted names, quite a few games were missing from the OPL list. To try to workaround the corrupted names/missing games problem, I renamed all game files so the name part has 32 characters. For example,

Code:

"SLUS_123.45.Game Name Here.iso"

would become

Code:

"SLUS_123.45.Game Name Here                  .iso"

That seemed to work; now all games are shown in the list and they load properly. However, there is one remaining issue. Alphabetically, the first file in the CD directory is Ico, with filename

Code:

"SCUS_971.13.Ico                             .iso"

There are actually three entries for Ico in the OPL game list! The name for all three shows (correctly) as Ico. But the game ID code (displayed to the right of the list) is corrupted for two of them:

Code:

Name  Game ID shown
Ico   ..US_971.13
Ico   .CUS_971.13
Ico   SCUS_971.13

Only the third entry works. It seems OPL is not handling the first ".." and "." directory entries returned by the NAS properly.

If any of the OPL devs want to look into this, I can provide a Wireshark packet capture of the PS2<->NAS traffic if it would be helpful.

**mark_k** · 11-06-2012,09:37 AM

I've been looking at the Open PS2 Loader and PS2SDK source, and reading the SMB/CIFS specs. I might have found the cause of this problem.

In PS2SDK, the smb_FindFirstNext2() function is in iop/network/smbman/src/smb.c. Near the end of that function we have:

Code:

struct FindFirst2ResponseData_t *FFRspData = (struct FindFirst2ResponseData_t *)&SMB_buf[FFNRsp->smbTrans.DataOffset+4];

info->EOS = FFNRspParam->EndOfSearch;

if (FFNRspParam->SearchCount == 0)
	return -4;

info->fileInfo.Created = FFRspData->Created;
info->fileInfo.LastAccess = FFRspData->LastAccess;
info->fileInfo.LastWrite = FFRspData->LastWrite;
info->fileInfo.Change = FFRspData->Change;
info->fileInfo.FileAttributes = FFRspData->FileAttributes;
if (FFRspData->FileAttributes & EXT_ATTR_DIRECTORY)
		info->fileInfo.IsDirectory = 1;
info->fileInfo.AllocationSize = FFRspData->AllocationSize;
info->fileInfo.EndOfFile = FFRspData->EndOfFile;
for (i = 0, j =0; i < FFRspData->FileNameLen; i++, j+=CF)
	info->FileName[i] = FFRspData->FileName[j];

return 0;
}

Notice the for loop at the end where the filename is copied. In order for the destination string to be null-terminated, FFRspData->FileNameLen as returned by the NAS/server must include the length of the terminating zero byte. If it doesn't, we'll copy the filename without terminating zero. That means, if a longer string was previously at info->Filename, the end of it will be left over. That explains the problems I described at the start of this thread.

Take a look at the CIFS specification PDF which you can download from Microsoft: [MS-CIFS]: Common Internet File System (CIFS) Protocol.

In iop/network/smbman/src/smb.c the definition struct FindFirst2ResponseData_t corresponds to SMB_FIND_FILE_BOTH_DIRECTORY_INFO (pages 503-504 in [MS-CIFS].pdf):

Code:

struct FindFirst2ResponseData_t {
	u32	NextEntryOffset;
	u32	FileIndex;
	s64	Created;
	s64	LastAccess;
	s64	LastWrite;
	s64	Change;
	u64	EndOfFile;
	u64	AllocationSize;
	u32	FileAttributes;
	u32	FileNameLen;
	u32	EAListLength;
	u16	ShortFileNameLen;
	u8	ShortFileName[24];
	u8	FileName[0];
} __attribute__((packed));

From [MS-CIFS].pdf page 715:

<166> Section 2.2.8.1.7: If CAP_UNICODE has not been negotiated, Windows NT servers include the length of one NULL padding byte in the FileNameLength field value.

To me, that implies that while Windows NT servers include the NULL padding byte in the FileNameLength field, that isn't actually required. Some SMB/CIFS implementations might not include the terminating zero in FileNameLength. My guess is, that the Linux kernel used in the Buffalo LinkStation HD-H250LAN behaves like that. Maybe older Win 3.1/9x servers don't either???

I haven't dug out my old ethernet hub yet (which I need to have my laptop snoop on the PS2 ⟷ NAS network traffic) so can't say for sure that that is the problem, but it's the most likely explanation I think.

**mark_k** · 11-06-2012,01:36 PM

Here's a small modification to PS2SDK iop/network/smbman/src/smb.c which should (I hope) fix the problem. If anyone is able to apply the change and build Open PS2 Loader with it, please let me know. I'd be happy to test it.

Original:

Code:

for (i = 0, j =0; i < FFRspData->FileNameLen; i++, j+=CF)
	info->FileName[i] = FFRspData->FileName[j];

return 0;

Change that to read:

Code:

for (i = 0, j =0; i < FFRspData->FileNameLen; i++, j+=CF)
	info->FileName[i] = FFRspData->FileName[j];
// If FFRspData->FileNameLen did not include the terminating zero
// byte of the filename string, the preceding copy will not have
// copied the terminating zero.
if (info->FileName[FFRspData->FileNameLen - 1] != 0)	// Was last byte copied non-zero?
	info->FileName[FFRspData->FileNameLen] = 0;

return 0;

**mark_k** · 11-07-2012,10:14 AM

I finally managed to get a Wireshark capture of the PS2 ⟷ NAS traffic which shows the problem.

To easily look at the data, download the attached capture1.pcap.gz file, decompress and load into Wireshark.

I've also attached a screenshot of what the on-screen game list looked like afterwards. The on-screen game list looks like this:

Code:

21 Card Games PAL
Jak & Daxter - The Lost Frontier
James Pond Codename Robocod PAL
James Pond Codename Robocod PAL
James Pond Codename Robocod PAL
Power Rangers Dino Thunder
The Mummy (rip).isoLost Frontier
Tomb Raider Underworld (rip).iso

In this test the bad/corrupted names are two James Pond entries (OPL thinks the bogus ones start with . and .., because the . and .. entries in the DVD directory are returned immediately after the James Pond ISO) and The Mummy. The actual on-disk filenames as returned by the NAS are, in order:

Code:

(in CD directory)
.
..
SLES_533.57.21 Card Games PAL.iso
SLUS_200.65.Smuggler's Run.iso
SLUS_200.66.Half-Life.iso
SLUS_202.71.Shifters.iso
SLUS_209.44.Power Rangers Dino Thunder.iso
SLES_536.82.James Pond Codename Robocod PAL.iso
(in DVD directory)
.
..
SCUS_975.58.Jak & Daxter - The Lost Frontier.iso
SLUS_217.75.The Mummy (rip).iso
SLUS_218.58.Tomb Raider Underworld (rip).iso

Several games are missing from the OPL on-screen list: Half-Life, Shifters and Smuggler's Run don't appear at all. The reason for that is, OPL thinks their names are invalid. Because the Smuggler's Run filename partially overwrites the previous longer 21 Card Games filename, OPL thinks it is actually "SLUS_200.65.Smuggler's Run.isoiso". So that isn't included in the list. Similarly, the two following games have shorter names so OPL excludes them.

Let's look at the packet 35 data, which Wireshark shows as "Trans2 Response, FIND_NEXT2, Files: SLES_533.57.21 Card Games PAL.iso"

Code:

0000  00 15 c1 e1 28 97 00 07  40 fb f6 e2 08 00 45 00   ....(... @.....E.
0010  00 ec a6 c9 40 00 40 06  11 e9 c0 a8 00 05 c0 a8   ....@.@. ........
0020  00 04 00 8b 2f 1f 9d 02  95 0c 00 00 1d 31 50 18   ..../... .....1P.
0030  16 d0 ea 5f 00 00 00 00  00 c0 ff 53 4d 42 32 00   ..._.... ...SMB2.
0040  00 00 00 80 41 00 00 00  00 00 00 00 00 00 00 00   ....A... ........
0050  00 00 01 00 00 00 64 00  00 00 0a 08 00 80 00 00   ......d. ........
0060  00 08 00 38 00 00 00 80  00 40 00 00 00 00 00 89   ...8.... .@......
0070  00 00 01 00 00 00 00 00  00 00 80 00 00 00 00 00   ........ ........
0080  00 00 80 4f 8f f9 bc ef  cb 01 80 4f 8f f9 bc ef   ...O.... ...O....
0090  cb 01 80 4f 8f f9 bc ef  cb 01 80 4f 8f f9 bc ef   ...O.... ...O....
00a0  cb 01 00 78 2c 03 00 00  00 00 00 00 30 03 00 00   ...x,... ....0...
00b0  00 00 20 00 00 00 21 00  00 00 00 00 00 00 0c 00   .. ...!. ........
00c0  53 4c 45 53 5f 7e 31 4f  2e 49 53 4f 00 00 00 00   SLES_~1O .ISO....
00d0  00 00 00 00 00 00 00 00  53 4c 45 53 5f 35 33 33   ........ SLES_533
00e0  2e 35 37 2e 32 31 20 43  61 72 64 20 47 61 6d 65   .57.21 C ard Game
00f0  73 20 50 41 4c 2e 69 73  6f 00                     s PAL.is o.

The file length field is at offset 0xB6. It's 0x21 = 33. That is the length of "SLES_533.57.21 Card Games PAL.iso" not including the terminating zero. So it looks like my theory about the problem was right.

**mark_k** · 11-07-2012,02:00 PM

Yay! I managed to compile OPL myself with the change I described above and it does fix the problem.

I used loki7777's Ubuntu VM (Download Ubuntu Virtual Machine + enviroment to compile OPL), downloaded ps2sdk from https://github.com/ps2dev/ps2sdk, modified smb.c then did "make release" (which I think builds ps2sdk and copies the binaries to the appropriate place). I then built Open PS2 Loader.

**RandQalan** · 11-07-2012,02:20 PM

Did it fix your problems

**mark_k** · 11-07-2012,03:14 PM

Yep, maybe I should have written "it does fix the problem" in bigger letters.

**RandQalan** · 11-07-2012,03:59 PM

Originally Posted by mark_k

Yay! I managed to compile OPL myself with the change I described above and it does fix the problem.

I used loki7777's Ubuntu VM (Download Ubuntu Virtual Machine + enviroment to compile OPL), downloaded ps2sdk from https://github.com/ps2dev/ps2sdk, modified smb.c then did "make release" (which I think builds ps2sdk and copies the binaries to the appropriate place). I then built Open PS2 Loader.

That help

**Bat Rastard** · 11-08-2012,06:39 AM

Sorry I got sidetracked Mark. Once I made sure I had the most up-to-date PS2SDK, I inherited some Daughter Drama.

Apparently, 12 years is too late to toss her in the trash, and just split the stork with her mother ...

Anyhume, the build of OPL would've wasted your time anyway - "make release" was what I was doing wrong.

User Tag List

Thread: OPL 0.8 network game name corruption

Tweet

LinkBack

Thread Tools

Display


	Would you like to get all the new info from PSX-Scene in your email each day? Subscribe to our Daily Digest! Want to learn more about the team keeping you up to date with the latest scene news? Read about them now! Check out our Developer bios, too!