Debugging SMB Connection

[flugruger]

Can you help with a question about debugging an SMB connection?
I have a channels trying to connect to a test and a production server. In both, the network engineer is seeing the connection traffic go to the correct IP addresses. The traffic, however, fails with a TCP reset from the servers.

I am looking for Mirth logging that would help debug this, but am not finding any. Can you point me to where I'd see a log of what's happening.

Also, do you have any debugging tips for this situation?

Thanks!

[jonbartels]

Which side of the connection is sending TCP RST?

MC Connection Log

Look at the channel dashboard. Down near the bottom is a tab that says "Connection Log". You should see that connecting, reading, idling, as your chanel runs.

Regular Logs

You can update log4j.properties to show more logging detail.

The relevant source file is https://github.com/nextgenhealthcare/connect/blob/e66d1122dbeebfcf5a8939beb93d720b2d5071fb/server/src/com/mirth/connect/connectors/file/filesystems/SmbFileConnection.java I don't see many logger statements there but it may help to turn up logging for that package.

You can also consider turning up logging for the entire jcifs.smb package.

[flugruger]

@jonbartels ... The network engineer said it was the destination server sending the TCP RST. (We use AWS, so I can't Wireshark it. )

In the connection logs, I'm not seeing anything capturing the error.
Regarding turning up the logging settings, since these Mirth instances are on AWS I do not have that option.
The info the source code is helpful.... knowing that there's not a lot of logging available will help me not chase my tail on that.

FYI, based on teammate feedback, I've also tried using different user name variations: straight user name, DOMAIN\USERNAME and [email protected]... none of it worked so far.

[jonbartels]

Shame about AWS getting in your way. Zen created our Gemini service to address problems like that. If you want to ditch AWS call me, ha ha.

Surprisingly this search turned up a lot of hits - https://duckduckgo.com/?t=ffab&q=SMB+TCP+RST&ia=web . The first few seem to suggest this could be an authentication issue. Of course that analysis is going to require you to see the packet capture which you said was challenging in another comment.

[tonygermano]

Which version of mirth are you using? Prior to 3.9 the SMB connectors only supported SMBv1.

[flugruger]

Hi @tonygermano ... We're on 3.9.1 and I have the SMB set to v3+ due to customer requirements.

[MichaelLeeHobbs]

We use AWS, so I can't Wireshark it.

https://medium.com/@macsat101/packet-sniffing-using-wireshark-on-aws-183b7983685d

[pacmano1]

Thanks @pacmano1 ... unfortunately, the VPN access is only from the AWS servers to the file server. So, I cannot do that testing. But your suggestion has helped me think of an option: have the client's server admin test using our service credentials.

Throwing it over the fence to them makes sense to me. Otherwise you get in "it's your software that is broken" argument(s).

[MichaelLeeHobbs]

@flugruger do you not have access to the server Mirth is running on? If not then you need to push the problem to who ever does. If you do there are many ways to test this outside mirth. Assuming it's a Linux box then start with tcpdump. Once you confirm it's not a network issue then use some Linux SMB tool to check from the Mirth host.

[flugruger]

@flugruger do you not have access to the server Mirth is running on? If not then you need to push the problem to who ever does. If you do there are many ways to test this outside mirth. Assuming it's a Linux box then start with tcpdump. Once you confirm it's not a network issue then use some Linux SMB tool to check from the Mirth host.

@MichaelLeeHobbs ... the Mirth instance runs on AWS. Our network engineer can monitor things there.
Unfortunately, nobody has been able to identify what's wrong. At this point, I'm asking the customer's interface engineer if he can accept an ORU into his interface engine, then extract the base64 PDF and drop the file to the server.

[MichaelLeeHobbs]

@flugruger the Mirth instance runs on AWS what does that mean? Is it running on an AWS instance, ECS Container, FarGate, eks, or something else? In all cases other than FarGate you have access to the vps that Mirth is running on. AWS is not some mystical magical cloud thing where stuff magically runs. There is no cloud it's just someone else's computer. My guts telling me you have a acl firewall issue on one or both side of the vpn. The first step is to confirm network connectivity specifically for SMB everything else is a waste of time.

[flugruger]

@MichaelLeeHobbs ... I appreciate the advice.