Hi, one server in my domain seems to only respond to ports 137-139, not the new port 445 (it seems to silently drop any packet). Thus, a smbclient -L //server -Uuser doesn't work, with a shockingly long timeout (5 minutes, per the URL given above). Thankfully smbclient has a -p parameter, so a smbclient -p 139 -L //server -Uuser works marvellously, except for the fact that that doesn't really help me a lot since then a CUPS Samba networked printer still fails to work since I simply cannot (and shouldn't, since it's a Samba thing) manually specify a port 139 exclusivity in CUPS. In other words, the current modus operandi is a major problem for me, since I cannot print without telling those people to reconfigure their server/firewall to actually reject a port 445 connection. And I'd rather avoid that. It tends to be a slightly weak appearance, you know? ;-( Implementing the solution outlined in the URL given above thus sounds good to me. You could also ask me to get the dropped port 445 reconfigured to get rejected, but Micro$oft software probably has no issues with the existing setup here, so Samba should probably behave the same without requiring further reconfiguration in many networks which choose to silently drop 445 (having to double-connect to both 445 and 139 is indeed slightly painful for the network, though). I cannot test current CVS here, since it's a RHEL production machine and I'm thus hesistant to potentially mess up my system by installing source compiled versions all over the system. So apologies if a solution has actually been implemented there already. Hopefully I chose the bug component correctly... The originally installed Samba 3.0.2-6.3E packages also didn't work, of course. I was tempted to set Severity to major... Anything else, please feel free to ask. Thanks!
Potentially useful info about port 445 use can be found at http://ntsecurity.nu/papers/port445/
Verified that 3.0.4 doesn't seem to contain a fix for this issue yet.
In other words, our local server used for printing doesn't offer CIFS (445), but instead only smbfs (139). See also http://groups.google.de/groups?threadm=1ZeDs-4HN-5%40gated-at.bofh.it for another report about this specific problem. Adjusting Severity to major, since this causes complete loss of printing for me. Haven't tried 3.0.5pre1 for lack of an RPM yet, though (it contains a fix that might actually fix that very issue). Some weeks later I may actually tend to trying to fix it myself, but I'd rather spare myself from having to dig through the presumably huge Samba codebase if I could avoid it (Wine and my acx100 wireless driver is enough fun already). Thanks!
Just installed 3.0.5, doesn't handle it yet either. http://groups.google.de/groups?selm=cd6uc8%241ttj%241%40FreeBSD.csie.NCTU.edu.tw contains a patch that would probably fix this issue (just found it; haven't tested it yet, sorry)
the current behavior is by design. The long timeout sounds like a possible firewall issue. The connection should simply be refused. and the reconnect on port 139. If you have a problem with cups sending to smb printers, you should probably file a bug with the cups developers.
(In reply to comment #5) Gerald (Jerry) Carter writes: > The long timeout sounds like a possible firewall issue. It is, as the original poster indicated. As is the situation I ran across that led me to this bug. > The connection should simply be refused. As the original poster indicated, it is desirable not to have to adjust firewalls to be "unstealthy" and explicitly reject connections. > and the reconnect on port 139. > the current behavior is by design. My understanding is that the preferred design is to make simultaneous connections to both ports, and use whichever responds first. This is the design suggested by Andrew Bartlett in the mailing list message the original poster referenced: http://www.mail-archive.com/samba@lists.samba.org/msg34211.html And supposedly the implementation chosen by Microsoft. This could be argued to be a feature enhancement rather than a bug, but as long as it is in the queue to be implemented at some point, that's all that matters to me. > If you have a problem with cups... In my case I observed the problem with smbclient, and I presume the issue is in an underlying library.