Hi apeiron69
As Graham pointed a out, a trace file would help a lot.
The short packet list from your question allows a few educated guesses:
- Your workstation tries to connect to the NAS using TCP ports 139 and 445 simultaneously.
- You can access the share if at least one port answers.
- The client will terminate the second TCP connection, if the server answers on both ports.
- The server responds on TCP port 139. Client and server negotiate some dialect of SMB v1.
- The exact dialect will be visible from the trace file. An exotic dialect could cause problems. Exotic is anything except NT LM 0.12
- The workstation sends two SMB commands in packet 1139: An session setup request and a Tree Connect
- Sending two commands is allowed in SMB, but not understood by all implementations.
- The session setup includes a username and presumably a hashed password.
- Depending on the security configuration and SMB implementation the password could be hashed in different formats.
- A problem cold occur if the client only sends an LMHASH of the password, but the server only accepts an NTLM hash.
- The server does not answer to packet 1139. 30 seconds later the clients sends an SMB echo request to test if the server is still there. Note that this is an Echo Request in SMB, not the infamous ping ("ICMP echo request")
- The Echo Request is never answered.
- 30 seconds later the client terminates the connections.
It seems that you are using a very odd SMB implementation (Older Mac OS?) The odd part are the two SMB commands carried in one packet. This is known to cause problems on certain servers.
Please keep in mind, that any trace file that you post on CloudShark will probably include your password in a hashed form. Unfortunately we need all the details for a full analysis.
Good luck
