Description of problem: support for specifying the port name to use when connecting to s share/service is broken for versions between 3.0.11 and 3.0.20, so when using 3.0.14a (as is current in FC3 and FC4) on a server behind a firewall which blocks access to port 445 entirely (don't ask why) the connection is slowed down to multiple timeout expiry delays when port 445 is first tried and then the fallback to port 139 kicks in. The delays are in the 60 seconds per connection. Furthermore the -p (or --port) support is broken in releases up to 3.0.20a. Thus FC3 and FC4 currently interoperate badly with "old" shares which cannot be reconfigured (eg samba shares on fileservers running reliable on "foreign" hardware) Version-Release number of selected component (if applicable): samba-client-3.0.14a-2 How reproducible: Everytime Steps to Reproduce: 1. every use of smbclient 2. even when -p 139 is specified 3. Actual results: command take more than 60 seconds to complete; with 3.0.8 (FC3 basic release) the delay is not noticable when -p 139 is specified; delay is present without specifying -p 139, since the firewall does not respond for those "illegal" port 445 messages. Expected results: no delays, at least when -p 139 is specified. The option "smb ports" of release 3.0.20 could be honoured when it is specified as "139 445" (as opposed to the nonetheless better default of "445 139") or even "139", to not try on port 445 at all, even when -p is not specified. But this is an samba project issue. Additional info: Update FC4 from 3.0.14a to 3.0.20 (or even 3.0.24) release version. Bug 162286 dated 2005-07-01 is addressing same problem, but is still at NEW. Strange, eh? Is a tesing version of the rpm available?
This report targets the FC3 or FC4 products, which have now been EOL'd. Could you please check that it still applies to a current Fedora release, and either update the target product or close it ? Thanks.
*** This bug has been marked as a duplicate of 162286 ***
issue resolved