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).
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.
Potentially useful info about port 445 use can be found at
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).
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).
Just installed 3.0.5, doesn't handle it yet either.
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
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
> 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.