a strange issue between an AltaLink C8055 with firmware 103.xxx.030.32000 and a Windows Server 2016 Standard.
Scan to SMB share on the server works fine, the problem is that for example a simple one page PDF scan (it doesn't matter if colour or black and white) takes at least 120 seconds to succeed.
What could affect transfer speed?
Solved! Go to Solution.
I would need to see a network troubleshooting log (packet capture) to verify that I'm correct, but in my experience this is usually caused by failed reverse DNS lookups. An easy test to validate my assumption is to remove any DNS entries from the machines TCP/IP settings and retest scanning. Of course you'll need to have your scan configuration setup via IP and not hostname since we've removed DNS servers. If it works normally without DNS servers entered on the Xerox and you want to have DNS servers configured on the device then you'll need to look into your server side configuration and make sure that reverse dns zones and PTR's that are properly configured so the queries that the machine makes can complete.
thank you so much!
The problem was just the DNS server, once I changed it to a generic one the scan was made at normal speed.
What I don't fully understand is why it was so slow even scan destination was already set to use server IP address instead of hostname.
Anyway, thank you for your suggestion!
I'm glad that I was able to help you. I am not a domain admin nor would I call myself a expert on the inner workings of SMB filesharing, but I'll explain how I came about knowing this.
About 2 years ago a coworker of mine posed the same question that you had and provided a packet capture for me. Before I could even review the packet capture they had wiped out the machines settings and when reconfigured, without DNS, they noticed that the problem went away. I never really dug into the pcap because this was fine for the customer, problelm solved.
Late last year another coworker, in another state, escalated the same issue on the newer AltaLink machines and provided a packet capture.
I know enough about packet analysis to find out what the root cause of a problem is most of the time, so I had a look at those 2 packet captures side by side. What I saw in them was identical. Repeated reverse DNS lookups that continually failed causing scans to deliver slowly.
That led me to start gaining knowledge on SMB, reverse dns, reverse dns lookup zones, and PTR records. So rather than recommending that this new customer remove DNS servers; I recommended that they properly configure a reverse DNS zone and accompanying PTR record.
The Analyst that started the escalation closed the case the following day stating that the domain admin configured reverse DNS and PTR properly and the problem was resolved.
If you are interested in learning more through personal analysis you can take a packet capture using the built-in network troubleshooting log function found in the security section of the Xerox Embedded Web Server. Take a capture of the scanning process with your previous DNS servers configured and one with the new ones and take a look at the difference in Wireshark.