cancel
Showing results for 
Search instead for 
Did you mean: 
7 Replies
JoyceRowe
New Member
New Member

Re: Very long delay scan job using SMB


@mcdvoice wrote:

Odd, the DNS thing should just be how long the DNS timeout is set to in your DNS settings, which is typically only 1 second.

When you mention different SMB versions, was that done here in CWIS?

1.JPG

Are the scans searchable? There have been reports in other firmware versions that caused real odd stuff via DNS when searchable was chosen, the reason given at the time I last heard was not reasonable to me, but the traces if I recall correctly looked like these.

 

I have a guy looking into what you provided here for comparison when he gets a chance, he may provide more to work with...

 


Very valuable information, it is not at all blogs that we find this, congratulations I was looking for something like that and found it here.

0 Kudos
scottg777
New Member
New Member

Re: Very long delay scan job using SMB

I ran into a simular issue. Scans would take about 1:30 to 2 minutes to transfer. I had to change the change the File Repository from Host Name to IPv4 and changed the dns to Google dns. 8.8.8.8. Scans would go through in about 10 seconds after that.
Joe Arseneau
Valued Advisor
Valued Advisor

Re: Very long delay scan job using SMB

I would need a log number to work in depth, which can't be done on the forum.

You would need to call Xerox and get to 2nd level support to have a trace analysis.

Please be sure to select "Accept Solution" and or select the thumbs up icon to enter Kudos for posts that resolve your issues. Your feedback counts!

Joe Arseneau
0 Kudos
fabiolaserra
Frequent Member
Frequent Member

Re: Very long delay scan job using SMB

No, the scan are not searchable. In any case the issue does not depend on file characteristics, because also the test takes very long time.

The smb versions are: v2 and v3, I also tried to check only v2 and only v3.

If you want, I can send you the complete wireshark trace, I noticed also something that seems strange to me about path destination. Can I pm you the file?

0 Kudos
Joe Arseneau
Valued Advisor
Valued Advisor

Re: Very long delay scan job using SMB

Odd, the DNS thing should just be how long the DNS timeout is set to in your DNS settings, which is typically only 1 second.

When you mention different SMB versions, was that done here in CWIS?

1.JPG

Are the scans searchable? There have been reports in other firmware versions that caused real odd stuff via DNS when searchable was chosen, the reason given at the time I last heard was not reasonable to me, but the traces if I recall correctly looked like these.

 

I have a guy looking into what you provided here for comparison when he gets a chance, he may provide more to work with...

 

Please be sure to select "Accept Solution" and or select the thumbs up icon to enter Kudos for posts that resolve your issues. Your feedback counts!

Joe Arseneau
0 Kudos
fabiolaserra
Frequent Member
Frequent Member

Re: Very long delay scan job using SMB

Hello,

Thank you for your reply. The firmware version should be very recent: 073.040.009.03700. IP v6 is completely off.

I see some attempts to write file. Each attempt has a dns request that takes some seconds (12-15). There are errors in both dns reply and smb sessions. The strangeness is that before upgrading firmware this behaviour did not occur. I post a part of wireshark log:

196.168.yyy.yyy represent server, 192.168.xxx.xxx is workcenter

447 18.436942 192.168.xxx.xxx 192.168.yyy.yyy SMB2 252 Negotiate Protocol Request
448 18.437221 192.168.yyy.yyy 192.168.xxx.xxx SMB2 318 Negotiate Protocol Response

449 18.440304 192.168.xxx.xxx 192.168.yyy.yyy DNS 86 Standard query 0x34f8 PTR yyy.yyy.168.192.in-addr.arpa
453 21.961338 192.168.yyy.yyy 192.168.xxx.xxx DNS 86 Standard query response 0x34f8 Server failure PTR yyy.yyy.168.192.in-addr.arpa
454 21.962014 192.168.xxx.xxx 192.168.yyy.yyy DNS 86 Standard query 0x34f8 PTR yyy.yyy.168.192.in-addr.arpa
456 25.961621 192.168.yyy.yyy 192.168.xxx.xxx DNS 86 Standard query response 0x34f8 Server failure PTR yyy.yyy.168.192.in-addr.arpa
457 25.963114 192.168.xxx.xxx 192.168.yyy.yyy DNS 86 Standard query 0x0c7b PTR yyy.yyy.168.192.in-addr.arpa
463 29.961914 192.168.yyy.yyy 192.168.xxx.xxx DNS 86 Standard query response 0x0c7b Server failure PTR yyy.yyy.168.192.in-addr.arpa
464 29.962538 192.168.xxx.xxx 192.168.yyy.yyy DNS 86 Standard query 0x0c7b PTR yyy.yyy.168.192.in-addr.arpa
473 33.962215 192.168.yyy.yyy 192.168.xxx.xxx DNS 86 Standard query response 0x0c7b Server failure PTR yyy.yyy.168.192.in-addr.arpa

474 33.964483 192.168.xxx.xxx 192.168.yyy.yyy SMB2 232 Session Setup Request, NTLMSSP_NEGOTIATE
475 33.964783 192.168.yyy.yyy 192.168.xxx.xxx SMB2 437 Session Setup Response, Error: STATUS_MORE_PROCESSING_REQUIRED, NTLMSSP_CHALLENGE

476 33.965188 192.168.xxx.xxx 192.168.yyy.yyy TCP 66 38200 → 445 [ACK] Seq=569 Ack=876 Win=5840 Len=0 TSval=17246321 TSecr=550173569
477 33.966975 192.168.xxx.xxx 192.168.yyy.yyy SMB2 722 Session Setup Request, NTLMSSP_AUTH, User: DOMAINNAME\scanner
478 33.967880 192.168.yyy.yyy 192.168.xxx.xxx SMB2 171 Session Setup Response
479 33.969024 192.168.xxx.xxx 192.168.yyy.yyy SMB2 182 Tree Connect Request Tree: \\192.168.yyy.yyy\IPC$
480 33.969622 192.168.yyy.yyy 192.168.xxx.xxx SMB2 150 Tree Connect Response
477 33.966975 192.168.xxx.xxx 192.168.yyy.yyy SMB2 722 Session Setup Request, NTLMSSP_AUTH, User: DOMAINNAME\scanner
478 33.967880 192.168.yyy.yyy 192.168.xxx.xxx SMB2 171 Session Setup Response
479 33.969024 192.168.xxx.xxx 192.168.yyy.yyy SMB2 182 Tree Connect Request Tree: \\192.168.yyy.yyy\IPC$
480 33.969622 192.168.yyy.yyy 192.168.xxx.xxx SMB2 150 Tree Connect Response
481 33.970449 192.168.xxx.xxx 192.168.yyy.yyy SMB2 230 Ioctl Request FSCTL_VALIDATE_NEGOTIATE_INFO
482 33.970613 192.168.yyy.yyy 192.168.xxx.xxx SMB2 143 Ioctl Response, Error: STATUS_FILE_CLOSED
483 33.971447 192.168.xxx.xxx 192.168.yyy.yyy SMB2 236 Ioctl Request FSCTL_DFS_GET_REFERRALS, File: \192.168.yyy.yyy\utenti
484 33.975250 192.168.yyy.yyy 192.168.xxx.xxx SMB2 143 Ioctl Response, Error: STATUS_NOT_FOUND
485 33.976082 192.168.xxx.xxx 192.168.yyy.yyy SMB2 138 Tree Disconnect Request
486 33.976246 192.168.yyy.yyy 192.168.xxx.xxx SMB2 138 Tree Disconnect Response
487 33.977056 192.168.xxx.xxx 192.168.yyy.yyy SMB2 186 Tree Connect Request Tree: \\192.168.yyy.yyy\utenti
488 33.977225 192.168.yyy.yyy 192.168.xxx.xxx SMB2 150 Tree Connect Response
489 33.978010 192.168.xxx.xxx 192.168.yyy.yyy SMB2 230 Ioctl Request FSCTL_VALIDATE_NEGOTIATE_INFO
490 33.978204 192.168.yyy.yyy 192.168.xxx.xxx SMB2 143 Ioctl Response, Error: STATUS_FILE_CLOSED

 

I tried also to use different versions of SMB but the result is always the same. The only thing I have to say about dns is that in DNS configuration page I see these errors:

Host Name not Verified
Domain Name not Verified

But they were not verified before upgrading, so I don't know if it could be the cause of my issue.

Note that I have only 1 dns server configured in xerox (that is the DC controller).

Fabio

EDIT: I manually registered the device.

EDIT 2: The error code means:  Answer authenticated: Answer/authority portion was not authenticated by the server. Non-authenticated data: Unacceptable.

0 Kudos
Joe Arseneau
Valued Advisor
Valued Advisor

Re: Very long delay scan job using SMB

If the firmware is anywhere even close to up to date, Network trace is built in.Do it and view it in Wireshark to find where the lag is. I'm guessing DNS (lower the timeout) or IPv6 (Just disable it completely)

3.JPG

 

Please be sure to select "Accept Solution" and or select the thumbs up icon to enter Kudos for posts that resolve your issues. Your feedback counts!

Joe Arseneau
0 Kudos
fabiolaserra
Frequent Member
Frequent Member

Very long delay scan job using SMB

Product Name: WorkCentre 7830/7835/7845/7855
Operating System: Windows Server 2012 R2 x64

Hello

I am facing a performance issue with scan to smb folders. It is not related to the dimension of files because also running a "Destination Test" task, it takes very long time (waiting 2.30 minutes it finally got "pass" results). 

I really cannot imagine the reason. I tried to scan to different servers, using Domain Controller users and local users (for example a test user created on my laptop). The result is always the same.

Using different protocols, such as FTP, is very fast.

Any ideas?

Thanks!

0 Kudos