Ask Your Question

NAS issue in LAN...

asked 2018-10-05 14:26:15 +0000

apeiron69 gravatar image

Here I´m friends. Strange situation. I have a NAS in my router with IP This is reachable from all PC´s in a LAN, but one doesn´t connect it. From this PC I can connect all shared folders in other PC´s but not the NAS. I´ve traced this connection and it seems to have trouble connecting NAS on 445 port. I open the network and when I click on NAS (Technicolor) it waits for a minute and doen´t connect. The windows diagnostic says the NAS refuses connection but other pc can access it on port 445. Someone can hel me? The pc with the issue is the x.x.x.83. This is what happens...

<body lang="IT" style="tab-interval:35.4pt">

1004 13:30:15,365438 BROWSER 254 Local Master Announcement TECHNICOLOR, Workstation, Server, Print Queue Server, Xenix Server, NT Workstation, NT Server, Master Browser<o:p></o:p>

1005 13:30:15,368087 BROWSER 254 Domain/Workgroup Announcement CASA, NT Workstation, Domain Enum<o:p></o:p>

1069 13:30:31,710749 TCP 54 53394 → 139 [FIN, ACK] Seq=464 Ack=91 Win=17408 Len=0<o:p></o:p>

1070 13:30:31,724754 TCP 54 53394 → 139 [RST, ACK] Seq=465 Ack=91 Win=0 Len=0<o:p></o:p>

1083 13:30:32,763761 TCP 66 53399 → 445 [SYN] Seq=0 Win=17520 Len=0 MSS=1460 WS=256 SACK_PERM=1<o:p></o:p>

1084 13:30:32,765214 TCP 54 445 → 53399 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0<o:p></o:p>

1093 13:30:33,271597 TCP 66 [TCP Retransmission] 53399 → 445 [SYN] Seq=0 Win=17520 Len=0 MSS=1460 WS=256 SACK_PERM=1<o:p></o:p>

1094 13:30:33,272951 TCP 54 445 → 53399 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0<o:p></o:p>

1095 13:30:33,786965 TCP 66 [TCP Retransmission] 53399 → 445 [SYN] Seq=0 Win=17520 Len=0 MSS=1460 WS=256 SACK_PERM=1<o:p></o:p>

1096 13:30:33,788656 TCP 54 445 → 53399 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0<o:p></o:p>

1097 13:30:33,852705 TCP 66 53400 → 139 [SYN] Seq=0 Win=17520 Len=0 MSS=1460 WS=256 SACK_PERM=1<o:p></o:p>

1098 13:30:33,853845 TCP 66 139 → 53400 [SYN, ACK] Seq ...

edit retag flag offensive close merge delete


A link to a capture file that we can inspect using our favourite tool, Wireshark, is much more useful than a wall of (MS Office formatted) text.

grahamb gravatar imagegrahamb ( 2018-10-05 14:55:20 +0000 )edit

Thanks a lot. I'm new of nthis tool. Can you tell me if I should add a file saved as pcapng? Thank you

apeiron69 gravatar imageapeiron69 ( 2018-10-06 07:00:18 +0000 )edit

Pcapng or pcap, or any of the other capture formats that Wireshark can read. Save the file at a publicly accessible host, e.g CloudShark, Google Drive, DropBox etc. and post a link back to the file here.

grahamb gravatar imagegrahamb ( 2018-10-06 14:27:09 +0000 )edit

1 Answer

Sort by » oldest newest most voted

answered 2018-10-09 17:11:32 +0000

Eddi gravatar image

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

edit flag offensive delete link more


Thank you very much. While I find the way to post a correct file, I'd like to tell you that this PC has alway had problems with SMB connection to this NAS. No problem with other PC's connection but the NAS. The nice feature is that this is the 5th time I format the PC and this doesn't connect to the NAS. I've a fresh Windows 10 installation. This is a MSI G702PE Leopard with a Killer E2200 network adapter that I know has many issues but I've the same problems in WiFi with its own Intel AC-3160 adapter. I'll be more useful with a file that I'll load asap. Tha NAS doen't have password so it is not a problem with password. Thank you again ;)

apeiron69 gravatar imageapeiron69 ( 2018-10-12 12:10:00 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2018-10-05 14:26:15 +0000

Seen: 671 times

Last updated: Oct 12 '18