[FR] SMB 2.0 or 3.0 support

[AlenoxNoEnd]

Checks

• I have checked existing wOPL feature requests for duplicates and found none

Describe the FR

No response

Describe the solution you'd like

SMB 1.0 is very slow

Describe alternatives you've considered

No response

Additional context

No response

[Wolf3s]

Checks

• I have checked existing wOPL feature requests for duplicates and found none

Describe the FR

No response

Describe the solution you'd like

SMB 1.0 is very slow

Describe alternatives you've considered

No response

Additional context

No response

I'm working on that on the following branch to study how to implement a server to stream games.

[instinctualjealousy]

While supporting newer SMB would be good, I think you guys should all be considering UDPFS, which unlike strict UDPBD isn't locked to a block device (or a virtualization of one), but it also still has block device support for people who want that.

From what I can tell, UDPFS doesn't support VMC currently. It's not a limitation of being able to write to the host filesystem, as NHDDL does that for its ISO cache without issue.

SMB is apparently a chonky boi anyways and getting around it outright would be pretty great.

There are a couple of servers for it I'm aware of:
The reference server
UDPFSD by pcm720

[Wolf3s]

While supporting newer SMB would be good, I think you guys should all be considering UDPFS, which unlike strict UDPBD isn't locked to a block device (or a virtualization of one), but it also still has block device support for people who want that.

From what I can tell, UDPFS doesn't support VMC currently. It's not a limitation of being able to write to the host filesystem, as NHDDL does that for its ISO cache without issue.

SMB is apparently a chonky boi anyways and getting around it outright would be pretty great.

There are a couple of servers for it I'm aware of: The reference server UDPFSD by pcm720

There is a branch that is working on that also i have a build of it.

[Wolf3s]

WOPNPS2LD-UDPFS.zip

[instinctualjealousy]

WOPNPS2LD-UDPFS.zip

Deviating the purpose of this issue somewhat, but this build blackscreens for me.

[Wolf3s]

WOPNPS2LD-UDPFS.zip

Deviating the purpose of this issue somewhat, but this build blackscreens for me.

Weird, for me it works nicely, perhaps it´s somewhat the config file.

[instinctualjealousy]

The main build from 3 weeks ago works fine, so I'm going to start it up and write out config if it hasn't already.

[instinctualjealousy]

It starts, so that's definitely a thing!

[Wolf3s]

It starts, so that's definitely a thing!

But it's showing all games?

[instinctualjealousy]

How far along is the UI development for this feature? I'm not seeing anything in the UI that's cluing me in on enablement/configuration of UDPFS, I see the ETH device is still heavily paired with SMB (makes sense). I haven't used OPL in a while, but I think I should be able to figure this out on my own, unless something's hardcoded to run and doesn't have UI currently.

I can't change my subnet if it's a hardcoded 192.168 IP currently. That was a problem with some earlier attempts at UDPBD in OPL, for some reason.

As for my environment, the only issue I can think of is I don't currently have my ISOs named in OPL format (I'm using UDPFS with nhddl/neutrino currently) with the ID prefixed. I can fix this temporarily for testing, but I just want to make sure I can get the UDPFS working before going to the trouble (not a slight against you, thank you for putting in the work).

[Wolf3s]

How far along is the UI development for this feature? I'm not seeing anything in the UI that's cluing me in on enablement/configuration of UDPFS, I see the ETH device is still heavily paired with SMB (makes sense). I haven't used OPL in a while, but I think I should be able to figure this out on my own, unless something's hardcoded to run and doesn't have UI currently.

I can't change my subnet if it's a hardcoded 192.168 IP currently. That was a problem with some earlier attempts at UDPBD in OPL, for some reason.

As for my environment, the only issue I can think of is I don't currently have my ISOs named in OPL format (I'm using UDPFS with nhddl/neutrino currently) with the ID prefixed. I can fix this temporarily for testing, but I just want to make sure I can get the UDPFS working before going to the trouble (not a slight against you, thank you for putting in the work).

It´s on BDM start mode plus look for BDM devices settings you can find a UDPFS option.

[instinctualjealousy]

I won't be able to test this currently because it looks like you're doing the same thing the old UDPBD-enabled OPL builds were doing, which is using a hardcoded IP. I'm not reworking my entire subnet to make this work. I think for now (for testing purposes), you should at least use the IPCONFIG.DAT if not the Network Settings IP and what its currently set to as the client IP, that way you won't have to code up UI for it.

C:\Users\Adam>C:\Users\Adam\scoop\apps\udpfsd\current\udpfsd.exe -fsroot E:\PS2UDPFS
2026/05/09 11:10:21 fs: mounted root filesystem E:\PS2UDPFS (read-only: false)
2026/05/09 11:10:21 fs: enabled decompression for ZSO, CSO
2026/05/09 11:10:21 udpfsd: listening for incoming discovery packets on 0.0.0.0:62966
2026/05/09 11:10:21 udpfsd: listening for incoming data packets on 0.0.0.0:49256
2026/05/09 11:12:25 [192.168.1.10:62966]: discovery request received
2026/05/09 11:12:25 [192.168.1.10:62966]: discovery request received
2026/05/09 11:12:26 [192.168.1.10:62966]: discovery request received
2026/05/09 11:12:28 [192.168.1.10:62966]: discovery request received

I'm going to be a bit opinionated below, but by all means do things how you want and in a way that's most convenient for you.

UDPFS isn't actually a block device, which makes this a little confusing. UDPBD is, which makes this even more confusing. The current UDPFS server spec supports both. The currently implemented UDPFS should probably be an ETH device/toggleable between SMB and itself (at the top of the Network Settings page, perhaps). It could leverage all those settings fields that are applicable to UDPFS (the IP settings block, at the very least, with DHCP support included). Obviously, the login credentials and SMB server blocks can be completely grayed/unsettable when UDPFS is selected. UDPFS is multicast, so the PS2 doesn't need to know the IP of the host server unlike SMB (sure you know this).

I think if UDPBD is ever reimplemented into wOPL, it should absolutely be in the BDM device config as it was and as UDPFS currently is. Still, it should use the Network Settings IP, as it is a network device- a hardcoded IP is a big no-no.

I notice UDPFS servers support connecting via both protocols in the same instance. I don't think there would be harm in letting OPL connect to both at the same time (since ETH and BDM could be enabled simultaneously by the user). but I don't know if you could glean extra functionality out of this configuration even if it did work. This is only a concern if both were implemented as described, which I'm not expecting of anyone.

Edit: Not that it affects me, but does UDPFS obey the Ethernet link mode setting?

[Wolf3s]

I won't be able to test this currently because it looks like you're doing the same thing the old UDPBD-enabled OPL builds were doing, which is using a hardcoded IP. I'm not reworking my entire subnet to make this work. I think for now (for testing purposes), you should at least use the IPCONFIG.DAT if not the Network Settings IP and what its currently set to as the client IP, that way you won't have to code up UI for it.

C:\Users\Adam>C:\Users\Adam\scoop\apps\udpfsd\current\udpfsd.exe -fsroot E:\PS2UDPFS
2026/05/09 11:10:21 fs: mounted root filesystem E:\PS2UDPFS (read-only: false)
2026/05/09 11:10:21 fs: enabled decompression for ZSO, CSO
2026/05/09 11:10:21 udpfsd: listening for incoming discovery packets on 0.0.0.0:62966
2026/05/09 11:10:21 udpfsd: listening for incoming data packets on 0.0.0.0:49256
2026/05/09 11:12:25 [192.168.1.10:62966]: discovery request received
2026/05/09 11:12:25 [192.168.1.10:62966]: discovery request received
2026/05/09 11:12:26 [192.168.1.10:62966]: discovery request received
2026/05/09 11:12:28 [192.168.1.10:62966]: discovery request received

I'm going to be a bit opinionated below, but by all means do things how you want and in a way that's most convenient for you.

UDPFS isn't actually a block device, which makes this a little confusing. UDPBD is, which makes this even more confusing. The current UDPFS server spec supports both. The currently implemented UDPFS should probably be an ETH device/toggleable between SMB and itself (at the top of the Network Settings page, perhaps). It could leverage all those settings fields that are applicable to UDPFS (the IP settings block, at the very least, with DHCP support included). Obviously, the login credentials and SMB server blocks can be completely grayed/unsettable when UDPFS is selected. UDPFS is multicast, so the PS2 doesn't need to know the IP of the host server unlike SMB (sure you know this).

I think if UDPBD is ever reimplemented into wOPL, it should absolutely be in the BDM device config as it was and as UDPFS currently is. Still, it should use the Network Settings IP, as it is a network device- a hardcoded IP is a big no-no.

I notice UDPFS servers support connecting via both protocols in the same instance. I don't think there would be harm in letting OPL connect to both at the same time (since ETH and BDM could be enabled simultaneously by the user). but I don't know if you could glean extra functionality out of this configuration even if it did work. This is only a concern if both were implemented as described, which I'm not expecting of anyone.

Edit: Not that it affects me, but does UDPFS obey the Ethernet link mode setting?

There's a block device option yes, UDPFS_BD if you see on modules folder but yeah uou are right atm . i'm doing something similar to OPL's with udpbd, so sorry about the dissapointment but it's experimental thing, i will plan to switch to block device to ioman to work toghether on smb1 so in the end will be configurable.

[instinctualjealousy]

I found a way to add a second IP to my NIC, so I added a static of 192.168.1.1 to talk back and forth with the PS2.

2026/05/09 23:31:00 udpfsd: listening for incoming discovery packets on 0.0.0.0:62966
2026/05/09 23:31:00 udpfsd: listening for incoming data packets on 0.0.0.0:50707
2026/05/09 23:38:15 [192.168.1.10:62966]: discovery request received
2026/05/09 23:38:15 udpfsd/discovery: [192.168.1.10:62966]: wrong packet type 2 (expected 0/DISCOVERY)
2026/05/09 23:38:16 udpfsd/discovery: [192.168.1.10:62966]: wrong packet type 2 (expected 0/DISCOVERY)
2026/05/09 23:38:16 udpfsd/discovery: [192.168.1.10:62966]: wrong packet type 2 (expected 0/DISCOVERY)
2026/05/09 23:38:17 udpfsd/discovery: [192.168.1.10:62966]: wrong packet type 2 (expected 0/DISCOVERY)

I can't actually confirm if my dual-IP setup is working, this could be a side-effect of wrong subnet still. I didn't see this on the last attempt prior to the change, though... that said, no evidence of PC-to-PS2 communication because of this error (and PS2-to-PC due to the nature of the beast will be received even when on the wrong subnet).

There's also definitely something wrong with init. No config, it froze before loading up, it froze before loading up on me again this time, and I actually loaded up the older build, reset some settings (BDM, network, resolution) and hit save. Went back into the UDPFS branch, and boom it boots again. Turned UDPFS on, the error above on the server and no game list. Weird! Some setting is making it start-sick, just as a lack of settings did.