hierynomus / smbj

Server Message Block (SMB2, SMB3) implementation in Java
Other
713 stars 180 forks source link

Unregister cached server for same hostname #783

Closed dheid closed 1 year ago

dheid commented 1 year ago

Hi @hierynomus !

Our infrastructure team sometimes switches the machines behind the same hostnames. In this case, smbj throws an exception, because it keeps the servers in an in-memory list were they stay until an application restart. That forces us to restart the application.

I made a change so that no exception will be thrown but instead the cached server will be unregistered and newly registered if it changed on the same hostname. It would save us much restarting effort, if you could merge this patch. Thanks in advance!!!

Best wishes

Daniel

sonatype-lift[bot] commented 1 year ago

Sonatype Lift is retiring

Sonatype Lift will be retiring on Sep 12, 2023, with its analysis stopping on Aug 12, 2023. We understand that this news may come as a disappointment, and Sonatype is committed to helping you transition off it seamlessly. If you’d like to retain your data, please export your issues from the web console. We are extremely grateful and thank you for your support over the years.

📖 Read about the impacts and timeline

hierynomus commented 1 year ago

@dheid Thank you for the PR, however in its current form it is contrary to what the specification says:

3.2.5.2 Receiving an SMB2 NEGOTIATE Response
[...]
If the client implements the SMB 3.x dialect family, the client MUST look up the server entry in ServerList where Server.ServerName matches the Connection.ServerName. If an entry is found,
the client MUST set Connection.Server to the server entry found.
[...]
If the client implements the SMB 3.x dialect family and Connection.Server is not NULL, the client MUST disconnect the connection if any of the following conditions is satisfied:
 Connection.Server.ServerGUID does not match ServerGUID in the response.
 Connection.Server.DialectRevision does not match DialectRevision in the response.
 Connection.Server.SecurityMode does not match SecurityMode in the response.
 Connection.Server.Capabilities does not match Capabilities in the response.

What I think should happen is (this is not specified anywhere):

Alternatively: Introduce a flag in the SmbConfig which disables the ServerList validation, and whose default setting is to be compatible with the spec.

dheid commented 1 year ago

That's a good idea! I will do that as soon as I come back from my vacation

JozefDropco commented 1 year ago

Server list cleanup Isnt it same as #719 which I have already provider a fix for?

hierynomus commented 1 year ago

Yes @JozefDropco, it might well also solve the case of @dheid. I've just polished PR #719 now, and fixed the failing testcase there.

hierynomus commented 1 year ago

@dheid Please take a look at the merged master. This incorporates #719, which probably should also solve your case. If so, please let me know.

dheid commented 1 year ago

@hierynomus Yes, this will solve our problem. We can close the PR.

dheid commented 1 year ago

@hierynomus Will there be a new release soon? Asking for a friend ;-)