Re: smbwrapper use of port 139 vs 445... Ok to force to 139?
On Mon, Dec 23, 2002 at 03:53:08PM -0500, [EMAIL PROTECTED] wrote: >> For the purposes of getting a browse list, connecting to port 139 is a >> must. There are ways to get the equivalent of a browse list via AD, but >> I don't think it's LDAP-only, so port 445 doesn't even do any good in >> this regard. >> For the actual enumeration of and connecting to shares, port 445 is >> likely to give some performance increase due to the lower protocol >> overhead. You can also configure newer Windows machines (XP at least) to >> *not* support NetBIOS at all, in which case they'll only be listening on >> port 445. OTOH, there are also plenty of older machines (NT4 and below) >> that are 139-only. > If an XP or other "new" machine is configured to not support port 139, and it > becomes a master browser then how would one get the browse list? If NetBIOS is disabled, the machine won't participate in browse elections, so it will never become the master browser. If NetBIOS is enabled, I believe that AD-aware machines are given a slight edge (in the form of the 'os level' option) in the browse election. >> Theoretically, it might be optimal to use port 139 to collect browse >> lists, and then use 445-else-139 for everything else. Barring that, I >> think 139-else-445 would be the best option. > This may be possible to do. The function where cli_initialize() and > cli_connect() are called, is passed a server name and a share name. The share > name seems to be IPC$ for every call I've seen into here, but is likely a > "real" share name when opening a regular file. I have occasionally seen a > server name of IPC$ as well. I suppose I could trace and determine which case > is caused by which type of enumeration. Do you know offhand in which case(s) > of server and share names I'm looking for a browse list? What if I do > 139-else-445 if share is IPC$, and do 445-else-139 otherwise? AFAIK, the share name will always be IPC$ for server enumeration, but I don't know what other side effects this approach might have. Certainly, the IPC$ share name would be used for other things which are not NetBIOS-dependent. -- Steve Langasek postmodern programmer msg05069/pgp0.pgp Description: PGP signature
Re: smbwrapper use of port 139 vs 445... Ok to force to 139?
Steve Langasek <[EMAIL PROTECTED]> writes: > For the purposes of getting a browse list, connecting to port 139 is a > must. There are ways to get the equivalent of a browse list via AD, but > I don't think it's LDAP-only, so port 445 doesn't even do any good in > this regard. > > For the actual enumeration of and connecting to shares, port 445 is > likely to give some performance increase due to the lower protocol > overhead. You can also configure newer Windows machines (XP at least) to > *not* support NetBIOS at all, in which case they'll only be listening on > port 445. OTOH, there are also plenty of older machines (NT4 and below) > that are 139-only. If an XP or other "new" machine is configured to not support port 139, and it becomes a master browser then how would one get the browse list? > Theoretically, it might be optimal to use port 139 to collect browse > lists, and then use 445-else-139 for everything else. Barring that, I > think 139-else-445 would be the best option. This may be possible to do. The function where cli_initialize() and cli_connect() are called, is passed a server name and a share name. The share name seems to be IPC$ for every call I've seen into here, but is likely a "real" share name when opening a regular file. I have occasionally seen a server name of IPC$ as well. I suppose I could trace and determine which case is caused by which type of enumeration. Do you know offhand in which case(s) of server and share names I'm looking for a browse list? What if I do 139-else-445 if share is IPC$, and do 445-else-139 otherwise? Thanks, Derrell
Re: smbwrapper use of port 139 vs 445... Ok to force to 139?
On Mon, Dec 23, 2002 at 02:51:08PM -0500, [EMAIL PROTECTED] wrote: > My last known problem with smbwrapper on Linux is that sometimes hosts in a > workgroup, or shares on a host, are not returned by the cli_Net*Enum() > functions. On another list (debian.something), there is currently a > discussion of the fact that using port 445 can cause this problem, and in > fact, when I force the port to 139, the problem goes away. > I'm not terribly familiar with the protocol differences between what's sent on > port 139 and what's sent on port 445. > *Specifically for the purposes of smbwrapper...* > 1. Is there a reason not to force the port number to 139? > 2. Is there any service provided on port 445, not provided on port 139, that's >required for smbwrapper to return the correct data? > 3. Are there any servers that don't provide port 139 service at all? > 4. If #3 is "yes", what about trying 139 and falling back to 445 rather than >the current implementation which is the other way around? I understand the reason for using 445 as primary and falling back to 139 is that it's much more efficient (both on setup and during data transfer) than doing it the other way around. For the purposes of getting a browse list, connecting to port 139 is a must. There are ways to get the equivalent of a browse list via AD, but I don't think it's LDAP-only, so port 445 doesn't even do any good in this regard. For the actual enumeration of and connecting to shares, port 445 is likely to give some performance increase due to the lower protocol overhead. You can also configure newer Windows machines (XP at least) to *not* support NetBIOS at all, in which case they'll only be listening on port 445. OTOH, there are also plenty of older machines (NT4 and below) that are 139-only. Theoretically, it might be optimal to use port 139 to collect browse lists, and then use 445-else-139 for everything else. Barring that, I think 139-else-445 would be the best option. -- Steve Langasek postmodern programmer msg05067/pgp0.pgp Description: PGP signature
smbwrapper use of port 139 vs 445... Ok to force to 139?
My last known problem with smbwrapper on Linux is that sometimes hosts in a workgroup, or shares on a host, are not returned by the cli_Net*Enum() functions. On another list (debian.something), there is currently a discussion of the fact that using port 445 can cause this problem, and in fact, when I force the port to 139, the problem goes away. I'm not terribly familiar with the protocol differences between what's sent on port 139 and what's sent on port 445. *Specifically for the purposes of smbwrapper...* 1. Is there a reason not to force the port number to 139? 2. Is there any service provided on port 445, not provided on port 139, that's required for smbwrapper to return the correct data? 3. Are there any servers that don't provide port 139 service at all? 4. If #3 is "yes", what about trying 139 and falling back to 445 rather than the current implementation which is the other way around? Thanks, Derrell
