On Tue, 16 Nov 2010 10:51:23 +0300 Pavel Shilovsky <piastryyy@xxxxxxxxx> wrote: > 2010/11/15 Jeff Layton <jlayton@xxxxxxxxx>: > > On Sun, 14 Nov 2010 12:38:18 +0300 > > Pavel Shilovsky <piastryyy@xxxxxxxxx> wrote: > > > >> 2010/11/13 Pavel Shilovsky <piastryyy@xxxxxxxxx>: > >> > 2010/11/13 Jeff Layton <jlayton@xxxxxxxxx>: > >> >> > >> >> I don't think this patch deals correctly with servers that are > >> >> listening on RFC1001_PORT but not CIFS_PORT. With two mounts to the > >> >> same server that don't specify a port, you'll end up with two sockets, > >> >> right? > >> > > >> > >> And from another hand: If user doesn't specify the port we should > >> think that it means the 445 port. If user wants to mount 139 port, he > >> should specify this port manually. So, there is no error with the > >> patch in this case. > >> > >> From this point of view we should remove trying with 139 port if we > >> failed with 445 port. What do you think about it? > >> > > > > That sounds like a regression. The mount.cifs manpage says: > > > > port=arg > > sets the port number on the server to attempt to contact to > > negotiate CIFS support. If the CIFS server is not listening on this > > port or if it is not specified, the default ports will be tried > > i.e. port 445 is tried and if no response then port 139 is tried. > > > > > > I think we ought to preserve that behavior. Perhaps if no port is > > specified then match any TCP session that is on port 445 or port 139? > > > > Jeff, according to my patches (try #2) I think we should replace it this with: > > port=arg > sets the port number on the server to attempt to contact to > negotiate CIFS support. > If the CIFS server is not listening on this port, we return > with error. If it is not specified, > the default ports will be tried i.e. port 445 is tried and > if no response then port 139 is tried. > > Sounds correct to me. Care to do a manpage patch for mount.cifs? Thanks, -- Jeff Layton <jlayton@xxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
