SMB: NetBIOS Enabled = Error, Disabled = Nothing

[E P]

That's odd. I don't see any such behaviour here at all. It seems to work perfectly stable, so for me it's already an improved replacement for the Host interface, since no PC-side client is needed. Of course, I still leave PS2ClientLoader active on the PC, and it does detect the SMS connection even when using Samba (as its detection just uses 'ping'), but that doesn't interfere with the Samba traffic at all. I'm streaming a video right now, from the same PC I'm using to write this, so my router doesn't disturb the communication either.

It's a problem for XP for me here. I checked with myPS2 and saw the same thing when I enabled NetBIOS. The connection is established with XP on port 139 then quickly dropped and then tried again. Netstat is a great tool for spotting this.

I went back and tried EEUG's test SMB setup stuff and now get this:

start address 0x1000e0
gp address 00000000
loadmodule: fname host:smb.irx args 0 arg 
loadmodule: id 36, ret 0
dopen name smb: 
dopen fd = 2
smb: connecting...
smb: connected
smb: requesting session...
smb: negotiate start
smb: negotiate end, status is 1 (1 is OK)
smb: login start
smb: login end, status is 1 (1 is OK)
smb: connection thread exit
Login: -119
Login command received: 0 (0)
Mount: 1
dopen name smb1:/* 
dopen fd = -89
DOpen: -89
UMount: -54
Logout: 0

It looks like from some investigating that the XP share just can't be fully accessed. I tried different logins and did see via error codes what it does when the login credentials are incorrect. Anyway, from what I have been able to gather, the failure occurs just after the smb share is mounted for access. So for some reason unbenounced to me, the XP share just can't be accessed from SMS or myPS2 on port 139.

Not really, or at least not here. I too have Windows XP Pro SP2, with most of the latest updates (except IE7 which I declined in my last WindowsUpdate visit. I mostly use FireFox anyway, so I'll keep the old IE.).

I updated to IE7 for security reasons but I don't really like it. Like you I also use firefox and with the extensions I use I doubt I'll ever have much use for IE again. Still I don't think that updating to IE7 would have changed functionality with NetBIOS though. I did change the XP services back to the earlier XP SP2 defaults and it didn't make any difference.

2: The NetBIOS over TCP/IP dependency. This is mainly a documentation issue, but in long term it should be fixed for better compatibility with LAN setups that may need it disabled for other reasons.

Yeah, but using SMB through port 445 when netBIOS is disabled is a MS 2000/XP thing. I don't think windows NT/95/98/ME even have that particular implementation. All they use is port 139. For all intense purposes I think EEUG's implementation is complete from an open source or Linux perspective. By that I mean that it works for the lowest common denominator.

Granted I would like for the current SMB implementation to work as ntba2's does. MyPS2 switches over to port 445 when it finds NetBIOS disabled. That's why myPS2 works here but I can't help but wonder what the holdup is on my machine with SMB through port 139. I know I can share files with Linux and this machine so I'm confused to say the least.

3: The lack of full read/write support

That last point is no issue with SMS of course, but it will become important to us when we consider this SMB module as an alternative to the Host server in uLE. Without full read/write support we can't simply use it as a replacement, and having both in the same binary will cause significant size increase. In any case, that will be up to us to solve, if/when we decide to use it for uLE.

Sure, but I need to figure out where ps2ftpd goes astray first. If I can't figure that out, we might as well dump it along with ps2netfs. I would hate to do it but if it can't get it to work correctly with the required ps2smap and ps2ip then why bother.

I did try sending smaller files through FTP and no problems so far there. In the end I think Samba would be much better overall if it could be used as a PS2 side server. I still prefer doing most things from the PC side.

[dlanor]

It's a problem for XP for me here. I checked with myPS2 and saw the same thing when I enabled NetBIOS. The connection is established with XP on port 139 then quickly dropped and then tried again. Netstat is a great tool for spotting this.

I went back and tried EEUG's test SMB setup stuff and now get this:

----- snip ----- re: SMB test feedback, showing various error codes
In that list the first negative function result was "Login: -119", so something apparently went wrong there already, which could make other error codes redundant/misdirecting, as all file IO will fail after a failed login. But apparently this failure was not due to wrong login credentials, judging from your comments below, so what was it then...?!? Was the login valid or not ?
(Maybe I'm misinterpreting the result code for that.)

It looks like from some investigating that the XP share just can't be fully accessed. I tried different logins and did see via error codes what it does when the login credentials are incorrect. Anyway, from what I have been able to gather, the failure occurs just after the smb share is mounted for access.

Well the next definite error code in that list is this:
dopen name smb1:/*
dopen fd = -89

That clearly means that even if basic login worked, the request to open the share does not. So we need to consider any setup differences that may cause such refusal. And if there's any list available giving detailed interpretation of those error codes, that might provide additional clues.

So for some reason unbenounced to me, the XP share just can't be accessed from SMS or myPS2 on port 139.

I don't think the port # is the issue here, but rather some other detail in the configuration causing access to this share to be rejected for this caller. Two things that may be relevant to this problem are the user 'level' of the PS2 login credentials as well as the specific share permissions you have set.

I have set the 'Read' permission for users of type 'Everyone', which could explain why my setup works, while yours doesn't. But then again, my ps2 login actually has 'Administrators' status, so for me it should work with any active share with 'Read' enabled for any group.

I updated to IE7 for security reasons but I don't really like it. Like you I also use firefox and with the extensions I use I doubt I'll ever have much use for IE again.

Even with 'IE tab', I never got WindowsUpdate to work fully OK in FireFox, so at present that is the only site for which I revert to using IE directly. Making a huge browser update for such little use is meaningless, and in addition to that I was warned by a friend that the new IE changes were such as I wouldn't like, so that's the main reason I declined IE7.

Still I don't think that updating to IE7 would have changed functionality with NetBIOS though.

Right! The basic protocols should be unaffected by the browser installation.


----- snip ----- re: extending the SMS IRX for NetBIOS independency

Yeah, but using SMB through port 445 when netBIOS is disabled is a MS 2000/XP thing. I don't think windows NT/95/98/ME even have that particular implementation. All they use is port 139. For all intense purposes I think EEUG's implementation is complete from an open source or Linux perspective. By that I mean that it works for the lowest common denominator.

Correct, but why settle for limited compatibility when you don't have to ?
Since two variants of the protocol exist, it is better to support both.

Granted I would like for the current SMB implementation to work as ntba2's does. MyPS2 switches over to port 445 when it finds NetBIOS disabled. That's why myPS2 works here

Really ??? Because that is NOT how it works here.

My little LAN consists of the following machines:

"router" == DI-604
"PS2"    == my console
"ra1"    == my WinXP PC
"ra2"    == my Win2K PC

Previously I had 'NetBIOS over TCP/IP' disabled on both ra1 and ra2, and at that time their shares worked well with myPS2 but none of them worked with the new SMS.

But then I enabled 'NetBIOS over TCP/IP' on ra1 but left it disabled on ra2 (as SMS only can access one PC via Samba at present). With this setup both PCs can see all shares of each other, but SMS can only see shares on ra1, while myPS2 can only see shares on ra2.

So myPS2 does NOT have proper compatibility to both protocol variants, like I suggested we implement, as it refuses to use the legacy mode for ra1. Note that it is the responsibility of the client to adapt to this, like ra2 does in accessing the shares of ra1 using legacy mode, even though ra2 itself has disabled 'NetBIOS over TCP/IP'. So that setting only affects acceptance of incoming calls, and first choice of outgoing calls, with fallback to the other mode for failed outgoing calls. One reason for this rule is that each system only needs to use one port to listen for incoming calls in either mode, with only the port number differing depending on the mode used.

Thus shares on any old Win system can still be accessed from a WinXP or Win2K system even if they have legacy mode disabled, but the old system can only access shares on the new systems if those are set to accept legacy mode.

It makes a lot of sense if you think of it in terms of old versus new security methods instead...

Its pretty obvious that a new security system, operating fully in the new mode, should not accept commands from an obsolete system. But the new system should still retain the ability to command those obsolete systems.

Samba on SMS is currently implemented like an obsolete system, while myPS2 is handicapped in a brand new way, which even seems to differ between your installation and mine. (Possibly it can't adapt to a LAN containing mixed sets)

What we want here is a PS2 module that works like the newer Win systems, so that it can access all shares regardless of any mode settings of those systems, as well as their age. (Though still limited to the set permissions, of course.)

I need to figure out where ps2ftpd goes astray first. If I can't figure that out, we might as well dump it along with ps2netfs. I would hate to do it but if it can't get it to work correctly with the required ps2smap and ps2ip then why bother.

If we can't debug it in any other way, then I agree. We must choose one or the other, and to me Samba is potentially more useful than FTP.

However, if it is ever to replace our Host protocol as well, then it must first gain the ability to write data to the PC shares, and to access multiple PCs.

I did try sending smaller files through FTP and no problems so far there.

Sure, reducing size will always reduce the risk of an error within that block, but we need to preserve the integrity of massive transfers as well.

In the end I think Samba would be much better overall if it could be used as a PS2 side server. I still prefer doing most things from the PC side.

I know you do, but I don't see it happening with this module.

A Samba server is really the obverse of a Samba client, which is what we have now, so that would require building it up entirely from scratch.

Btw:
Our discussion has become rather uLE-centred now, so perhaps we should continue it in that forum instead of here.

Best regards: dlanor

[EEUG]

@dlanor: -119 means EINPROGRESS (SMS uses asynchronous connection/login procedure), so, it's actually not an error . -89 means ENMFILE. Log above tells me that login was OK, share connection was also OK, but SMB_TRANSACT2_FINDFIRST request failed (or returned no files). In this case you can insert printfs into SMB_FindFirst function to trace this stuff (or use 'ethereal'/'wireshark' software to trace port 139 activitiy)...

[dlanor]

@dlanor: -119 means EINPROGRESS (SMS uses asynchronous connection/login procedure), so, it's actually not an error .

Thanks for that clarification!

I had a hunch it could be something like that, as the other operations which followed should not even have been attempted after a real login failure.

-89 means ENMFILE. Log above tells me that login was OK, share connection was also OK, but SMB_TRANSACT2_FINDFIRST request failed (or returned no files). In this case you can insert printfs into SMB_FindFirst function to trace this stuff (or use 'ethereal'/'wireshark' software to trace port 139 activitiy)...

Well, I can't test that myself, as I never get these errors.
But hopefully EP can investigate it.

However, I can see that sort of thing happening for shares that were properly created, with access for the right groups and all, but without the proper permissions for the access group or user used in that test. After all, without 'Read' permissions no shares should be visible, and then SMB_FindFirst should return an error.

But in that case it's not so much an 'error', of course, as a proper refusal of unauthorized access.

Best regards: dlanor

[E P]

Well the next definite error code in that list is this:
dopen name smb1:/*
dopen fd = -89

That clearly means that even if basic login worked, the request to open the share does not. So we need to consider any setup differences that may cause such refusal. And if there's any list available giving detailed interpretation of those error codes, that might provide additional clues.

Yeah, It has to be a problem with accessing the share and its contents.

I don't think the port # is the issue here, but rather some other detail in the configuration causing access to this share to be rejected for this caller. Two things that may be relevant to this problem are the user 'level' of the PS2 login credentials as well as the specific share permissions you have set.

I tried different logins like my XP default Administrator account, adding 'Everyone' to the share with full access, and even granting admin privileges to the ps2 user login. Unfortunately, I had no luck with any of those combinations.

----- snip ----- re: extending the SMS IRX for NetBIOS independency
Correct, but why settle for limited compatibility when you don't have to ?
Since two variants of the protocol exist, it is better to support both.

I agree but you have to keep in mind that the use of port 445 is a Microsoft addition that started with Windows 2000. Many of the Linux networking gurus didn't like it at the time but they have to deal with it. All the port does is allows one to disable NetBIOS over TCP/IP only to use another port using a slightly different implementation for SMB connections. The issue I had earlier with myPS2 was that I had port 445 closed and forgot that it was the port that needed to be open when I disabled NetBIOS over TCP/IP.

----- snip ----- re: myPS2 network setup:
But then I enabled 'NetBIOS over TCP/IP' on ra1 but left it disabled on ra2 (as SMS only can access one PC via Samba at present). With this setup both PCs can see all shares of each other, but SMS can only see shares on ra1, while myPS2 can only see shares on ra2.

Hum, maybe it sticks to one protocol when it starts. I did see it try to connect with my XP machine through port 139 when NetBIOS enabled which didn't work for me of course. Then when I disabled it, it tried to connect at port 445 and succeeded. So I assumed that it just tried one implementation, then if it found NetBIOS disabled it tried the other port 445 implementation. I'll do some investigating with Linux on another machine, my XP machine, and MyPS2 running on my PS2.

Samba on SMS is currently implemented like an obsolete system, while myPS2 is handicapped in a brand new way, which even seems to differ between your installation and mine. (Possibly it can't adapt to a LAN containing mixed sets)

I don't have a network of computers running current Microsoft Operating Systems. I have one machine that runs both XP Pro SP2 and 98 SE and another computer that runs 98 SE. So I haven't been able to do much tinkering with SMB networking with the PS2. I do have another machine here that has XP home that's not mine but I think I can do some tests with it and mine to see if I can at least resolve my own problem with SMB on port 139.

What we want here is a PS2 module that works like the newer Win systems, so that it can access all shares regardless of any mode settings of those systems, as well as their age. (Though still limited to the set permissions, of course.)

Right, I'm with you there.

Our discussion has become rather uLE-centred now, so perhaps we should continue it in that forum instead of here.

Sure, I'll comment more on this in the uLE thread once I have some news to report.

-89 means ENMFILE. Log above tells me that login was OK, share connection was also OK, but SMB_TRANSACT2_FINDFIRST request failed (or returned no files). In this case you can insert printfs into SMB_FindFirst function to trace this stuff (or use 'ethereal'/'wireshark' software to trace port 139 activitiy)...

Thanks, I don't have any experience with packet sniffers so I'll try debug printfs. I'm going to try another XP machine first and see if I can atleast get it to work with it.

Edit: Update
I tried another XP machine and I get the same issue as before? Samba icon flickers and the port keeps changing(PS2 port connecting starts with 4097 then port++ until it dies). I'm now hedging a bet that NetBEUI is responsible. Both XP machines have similar configurations but the newer machine hasn't been battle tested as mine has. NetBEUI is installed but is disabled on both machines so I guess I need to uninstall it and see what happens. I use netBEUI on Windows 98 for additional security purposes, Network Bondage as some refer to call it.

I did get a chance just a little while ago to play with SMB stuff through Linux and its quite impressive. Streaming audio/video works really great over the common network protocol. This could be far better for new users that are confused about how to make host: work.

[dlanor]

----- snip ----- re: various stuff we agree on, though we still have different results...
It's weird. Doing virtually the same things, on very similar XP systems, still results in failure for you and success for me. We must be missing some crucial point somewhere. Something I just happen to have right, but you don't.


----- snip ----- re: myPS2 adaption to differing Samba port usage

Hum, maybe it sticks to one protocol when it starts. I did see it try to connect with my XP machine through port 139 when NetBIOS enabled which didn't work for me of course. Then when I disabled it, it tried to connect at port 445 and succeeded. So I assumed that it just tried one implementation, then if it found NetBIOS disabled it tried the other port 445 implementation.

I think you're right. It probably makes that test only on the first connection, sets some flag or port number parameter, and then sticks to that choice for the rest of that boot session.

This is of course a nonsense method, when the program supports contact with different machines on the network. Then the only correct methods are either to recheck at each connection, or at least do separate checks for each new machine contacted, storing those flags and/or port numbers in an array. That's something for us to keep in mind for the future too, if/when we add Samba to uLE.

I'll do some investigating with Linux on another machine, my XP machine, and MyPS2 running on my PS2.

Good. But I'm pretty sure it will confirm your guess about that initial testing by myPS2. As for Linux results, they can probably differ between different Linux distributions. But for this particular standard I think we have to rely on Windows' behaviour, whether we like it or not...

I don't have a network of computers running current Microsoft Operating Systems. I have one machine that runs both XP Pro SP2 and 98 SE and another computer that runs 98 SE. So I haven't been able to do much tinkering with SMB networking with the PS2. I do have another machine here that has XP home that's not mine but I think I can do some tests with it and mine to see if I can at least resolve my own problem with SMB on port 139.

Yes, port 139 is obviously what you need working, since one of your two machines is restricted to that by its single OS, and the other is sometimes running with the same restriction too.

-89 means ENMFILE. Log above tells me that login was OK, share connection was also OK, but SMB_TRANSACT2_FINDFIRST request failed (or returned no files). In this case you can insert printfs into SMB_FindFirst function to trace this stuff (or use 'ethereal'/'wireshark' software to trace port 139 activitiy)...

Thanks, I don't have any experience with packet sniffers so I'll try debug printfs. I'm going to try another XP machine first and see if I can atleast get it to work with it.

Edit: Update
I tried another XP machine and I get the same issue as before? Samba icon flickers and the port keeps changing(PS2 port connecting starts with 4097 then port++ until it dies). I'm now hedging a bet that NetBEUI is responsible. Both XP machines have similar configurations but the newer machine hasn't been battle tested as mine has. NetBEUI is installed but is disabled on both machines so I guess I need to uninstall it and see what happens. I use netBEUI on Windows 98 for additional security purposes, Network Bondage as some refer to call it.

Ooops! You lost me there. I haven't the faintest idea of how netBEUI would affect Samba.

Actually I think a lot of this mixture of obsolete and modern terminology is just misleading. For example, to switch between myPS2 and SMS Samba usage I must either disable or enable 'NetBIOS over TCP/IP". However, in both cases the traffic still uses IP datagrams, and my guess is that it still uses TCP as well, in which case it's still "NetBIOS over TCP/IP", only using a different port. So why not just call it "xxx Port NetBIOS" instead, which also allows for future changes...?

You'd almost think such confusing terminology intentional, when it reaches this degree...

I did get a chance just a little while ago to play with SMB stuff through Linux and its quite impressive. Streaming audio/video works really great over the common network protocol. This could be far better for new users that are confused about how to make host: work.

Yes I agree, though we do need to implement a server to share PS2 files the same way, as I think EEUG's module lacks that part.

But to resolve the problems we've discussed you should also test how Linux deals with the port choices. As I see it, the correct method is to access other systems by either port (whichever succeeds) even in the mode where the old port is disabled (as that applies to 'listening' only). But it's still interesting to know how Linux does it.

Best regards: dlanor

[E P]

----- snip ----- re: various stuff we agree on, though we still have different results...
It's weird. Doing virtually the same things, on very similar XP systems, still results in failure for you and success for me. We must be missing some crucial point somewhere. Something I just happen to have right, but you don't.

Yes, weird indeed.

Good. But I'm pretty sure it will confirm your guess about that initial testing by myPS2. As for Linux results, they can probably differ between different Linux distributions. But for this particular standard I think we have to rely on Windows' behaviour, whether we like it or not...

I don't think they differ too much distro-wise as most use the same libraries from official Samba project. Granted there could be differences between versions as the Samba project which is turning out new versions regularly.

Ooops! You lost me there. I haven't the faintest idea of how netBEUI would affect Samba.

I thought it might have interfered but I ruled it out by completely by removing netBEUI from one machine and testing without it.

What I have discovered is something you eluded to earlier: Improper share permissions possibly preventing the SMB connection from retrieving the share listing. That is the conclusion I keep coming to but the configuration of both XP machines says otherwise. Also the shares work fine with standard machine to machine networking shares whether it's XP to XP, XP to 98, or XP to Slax.

I did some tests; one test sharing a drive at its root and another with no sharing at all. After running EEUG's test ps2link and the earlier test stuff, I noticed that without sharing anything I got the same errors as before. In other words, it makes no difference whether I actually share anything or not as I get the same result. So as EEUG stated my problem occurs right at or around 'SMB_FindFirst'. I'm hoping I can solve it without a whole lot of debugging but it's not looking very good at the moment.

You'd almost think such confusing terminology intentional, when it reaches this degree...

Yeah, then when you get people who are new to the stuff they have to learn it all the hard way.

Yes I agree, though we do need to implement a server to share PS2 files the same way, as I think EEUG's module lacks that part.

Yes, it only has the client part of the equation like myPS2. A server would be much more difficult as you have to deal with PS2 sides individual device drivers and all those possible issues we've become aware of.

But to resolve the problems we've discussed you should also test how Linux deals with the port choices. As I see it, the correct method is to access other systems by either port (whichever succeeds) even in the mode where the old port is disabled (as that applies to 'listening' only). But it's still interesting to know how Linux does it.

I haven't done much with Linux and networking since I got it working. However, from what I've seen of Samba so far it very well could connect through port 445. It looks like the Samba project is pretty current with Microsoft's changing networking standards. Vista will likely set things back but I don't even want to open that can of worms here.

[dlanor]

What I have discovered is something you eluded to earlier:

I assume you meant 'alluded', as I'm not usually very 'elusive', or at least not intentionally so

Improper share permissions possibly preventing the SMB connection from retrieving the share listing. That is the conclusion I keep coming to but the configuration of both XP machines says otherwise. Also the shares work fine with standard machine to machine networking shares whether it's XP to XP, XP to 98, or XP to Slax.

But those results seem to rule out truly 'improper' permissions IMO.
Though perhaps some part of EEUG's SMB module has it's own definition of 'proper'...

I did some tests; one test sharing a drive at its root and another with no sharing at all. After running EEUG's test ps2link and the earlier test stuff, I noticed that without sharing anything I got the same errors as before. In other words, it makes no difference whether I actually share anything or not as I get the same result. So as EEUG stated my problem occurs right at or around 'SMB_FindFirst'. I'm hoping I can solve it without a whole lot of debugging but it's not looking very good at the moment.

Maybe we're just trying to be *too* smart here, and it's causing us to overlook simpler possibilities. I've just realized that a very simple bug could explain why it works for me and not for you.

You see, I have set the permission 'Read' of the group 'Everyone' for every single one of my shares. This means that regardless of scanning order, all shares found will always have read permission for any user. Now if you have not set such permission for all your shares, but only for some, then a simple bug in that FindFirst function could cause it to fail just because it found a share without such permission (or any) before the ones that do have it.

At such a time its proper response should be to stay in the loop, and continue testing the rest, but with the symptoms you got we already have reason to believe that something is *not* done the proper way. And a failure to do so in that particular routine could of course break the entire directory read sequence, causing precisely those symptoms.

Of course, that theory hinges entirely on the assumption that you have at least some share without such general 'Read' permission, and if you don't then this is just another idea 'down the drain'. But if you do have some such shares, then I suggest you try setting that permission for all of them, and see if that affects your results.

Yes, it only has the client part of the equation like myPS2. A server would be much more difficult as you have to deal with PS2 sides individual device drivers and all those possible issues we've become aware of.

Yes, I know, but in our case a lot of that work is already completed, in the form of our 'gen' family of IO functions. Like genOpen, genLseek, genRead, genClose, and all the others. We might have to extend that family a bit to include features we haven't used in uLE earlier, but it wouldn't be all that hard I think.

Note that I'm not at this stage envisioning a complete bidirectional Samba module as an IRX, since I think that would be too difficult to start with. Perhaps that can be done at a later stage, but for the time being I would be happy with a mixed solution with some of the stuff in IRX and the rest in the main ELF.

Or perhaps an even better solution would be to reimplement all the 'gen' functions, as a separate IRX of its own. Like a sort of 'generic' device driver providing an alternate way of accessing all the others...!?! And with such a device available, making a bidirectional Samba IRX should be much easier.

It looks like the Samba project is pretty current with Microsoft's changing networking standards. Vista will likely set things back but I don't even want to open that can of worms here.

I certainly agree. As far as I'm concerned that OS is still a dubious beta, and I'm not going to be the guinea pig to suffer all it's early diseases.

Best regards: dlanor

[E P]

I assume you meant 'alluded', as I'm not usually very 'elusive', or at least not intentionally so

Yeah, I misspelled 'alluded' and I let spell check correct it when I wasn't paying attention. I think I need to get caught back up on some sleep.

But those results seem to rule out truly 'improper' permissions IMO.
Though perhaps some part of EEUG's SMB module has it's own definition of 'proper'...

Yeah, but I can't help but wonder about MyPS2 as well since it does pretty much the same thing. With NetBIOS enabled, using port 139, I can't get access to the share with either SMB implementation. I know that the share works because once I disabled NetBIOS on the machine, then tried it again with myPS2, it connected. Sure it connects through port 445 but if the shares were bad it wouldn't work at all. So knowing this along with Linux working fine using NetBIOS(port 139) tells me it's something with XP on my XP Pro machine and this other computer running XP Media Center. It's has to be a NetBIOS/sharing configuration issue with these two XP versions. I'm narrowing down the possibilities but at the rate things are going I may need yet another fresh XP machine to play with.

Maybe we're just trying to be *too* smart here, and it's causing us to overlook simpler possibilities. I've just realized that a very simple bug could explain why it works for me and not for you.

Sure, I tend to overlook the obvious sometimes. I did manage to check by allowing every user group and all the users granting 'Read' permissions to my 'C' share. Of course the E$, IPC$, print$, ADMIN$, and C$ are locked because those are special administration shares. I even tried the 'Everyone' with full access using an Administrator account to login in from the PS2 side and it didn't work either.

Note that I'm not at this stage envisioning a complete bidirectional Samba module as an IRX, since I think that would be too difficult to start with. Perhaps that can be done at a later stage, but for the time being I would be happy with a mixed solution with some of the stuff in IRX and the rest in the main ELF.

Sure I couldn't see it done all in one swoop. There's still quite a bit to understand first. Plus an implementation of that sort of magnitude would be a nightmare without breaking it down into workable pieces first.

Or perhaps an even better solution would be to reimplement all the 'gen' functions, as a separate IRX of its own. Like a sort of 'generic' device driver providing an alternate way of accessing all the others...!?! And with such a device available, making a bidirectional Samba IRX should be much easier.

Yeah, that sounds reasonable. Kind of like how ps2ftpd and host: make some generic calls that correspond to drivers that do most of the heavy lifting.

[dlanor]

I did manage to check by allowing every user group and all the users granting 'Read' permissions to my 'C' share. Of course the E$, IPC$, print$, ADMIN$, and C$ are locked because those are special administration shares.

Even so, I think I went a little further than you, as I've set 'Read' permission of 'Everyone' for every one of the hard disk drives (partitions really) visible in 'My Computer'.

I even tried the 'Everyone' with full access using an Administrator account to login in from the PS2 side and it didn't work either.

Well, that should definitely work in any case, so I'm stumped as to why it doesn't work for you.


----- snip ----- re: bidirectional Samba distributed over EE and IOP components

Sure I couldn't see it done all in one swoop. There's still quite a bit to understand first. Plus an implementation of that sort of magnitude would be a nightmare without breaking it down into workable pieces first.

It sure would be, but in any case we must first gain full control, as well as full understanding, of EEUG's Samba module, before we can start on a bidirectional implementation.

Yeah, that sounds reasonable. Kind of like how ps2ftpd and host: make some generic calls that correspond to drivers that do most of the heavy lifting.

Exactly. Only even more generic in its nature, and allowing similar features in those modules to be simplified/eliminated. Even though it means adding a new module with lots of stuff in it, the long-term effect could even be to shrink the program as a whole, once we take full advantage of it.


Btw: No one should take the above as definite plans nailed down for implementation... These are just some of the ideas we're juggling at the moment. Only time can tell which of those ideas will really become implemented.

Best regards: dlanor