OS/2, eCS & ArcaOS - Technical > Networking

Samba connection - how to troubleshoot what gets sent and received?

(1/3) > >>

Dariusz Piatkowski:
Guys!

I've had a pesky problem on my OS/2 box for a while now, that being on Samba connections Lucide takes far too long to open a PDF that's sitting out there on my NAS box. This is not just a Lucide issue, GSView as well as QPDFView show the same behaviour.

We are talking here PDF files that are about 70-150k in size that take 5-10 secs to open up.

To be clear, I am using NetDrive Samba plugin to make this work, and that could certainly be adding, I just can't tell.

What I can see is that as I open a PDF file my TCP/IP monitor shows multiple traffic spikes, they continue (back and forth) until the file is opened up. Now nearly each one of these are spikes are actually larger than the actual PDF file itself, so that's literally flooring me as I can't for the life of me understand what is causing the traffic to happen.

Alright...so how can I troubleshoot this in order to figure out what all that "overhead" is that appears to be moving back and forth?

I've got Wireshark installed, so I could capture the packets as the transactions start...but is there something a little more human-digestable? I'm thinking Samba logging perhaps?

Thanks!

Paul Smedley:
Hi Dariusz,

--- Quote from: Dariusz Piatkowski on January 25, 2022, 03:59:19 am ---I've had a pesky problem on my OS/2 box for a while now, that being on Samba connections Lucide takes far too long to open a PDF that's sitting out there on my NAS box. This is not just a Lucide issue, GSView as well as QPDFView show the same behaviour.

We are talking here PDF files that are about 70-150k in size that take 5-10 secs to open up.

To be clear, I am using NetDrive Samba plugin to make this work, and that could certainly be adding, I just can't tell.

What I can see is that as I open a PDF file my TCP/IP monitor shows multiple traffic spikes, they continue (back and forth) until the file is opened up. Now nearly each one of these are spikes are actually larger than the actual PDF file itself, so that's literally flooring me as I can't for the life of me understand what is causing the traffic to happen.

Alright...so how can I troubleshoot this in order to figure out what all that "overhead" is that appears to be moving back and forth?

I've got Wireshark installed, so I could capture the packets as the transactions start...but is there something a little more human-digestable? I'm thinking Samba logging perhaps?

--- End quote ---

Samba logs please. Create a file \ndpsmb.dbg on the drive where ndpsmb.dll is installed. Run your test, then send me \var\log\log.ndpsmb

Mike Kölling:
Hi Darius,

kindly try to disable the "Supports EA" flag when you mount the share of your NAS. That helped me in a similar case.

Greetings from Potsdam, Germany.
Mike

Paul Smedley:
Hi Mike,

--- Quote from: Mike Kölling on January 25, 2022, 10:13:39 am ---kindly try to disable the "Supports EA" flag when you mount the share of your NAS. That helped me in a similar case.

--- End quote ---

I forget now if you sent me logs about this,  but it would be nice to NOT have to disable the supports EA flag, and handle this more gracefully in the plugin.

Cheers,

Paul

Dariusz Piatkowski:
Hi Mike!


--- Quote from: Mike Kölling on January 25, 2022, 10:13:39 am ---Hi Darius,

kindly try to disable the "Supports EA" flag when you mount the share of your NAS. That helped me in a similar case.

Greetings from Potsdam, Germany.
Mike

--- End quote ---

The NAS box does not support EAs, so I have that disabled in my NetDrive share configuration.

I remember trying to troubleshoot this a while back...I think I captured the LOGs that Paul is talking about and it looked like the PDFs were getting transfered in tiny chunks, we are talking here like 2-3K, while other objects (such as JPEGs for example) would max out at about 32K.

OK, yeah, I saved that old debug log and here is what I found:

1) JPEGs

--- Code: ---...
NdpQueryPathInfo <public\DOCUMENTS\Family\Finance\TAX\2016\US Info\2016 - MI - Tax Refund Statement.jpg> () 0
2020/06/11 16:18:53.50: 9 2: smbopen in [0x6e3a80] -1
2020/06/11 16:18:53.50: 4 2: cli_open(\public\DOCUMENTS\Family\Finance\TAX\2016\US Info\2016 - MI - Tax Refund Statement.jpg) attr 00000000 mode 100 denymode 04
2020/06/11 16:18:53.51: 9 2: smbopen <public\DOCUMENTS\Family\Finance\TAX\2016\US Info\2016 - MI - Tax Refund Statement.jpg> (\public\DOCUMENTS\Family\Finance\TAX\2016\US Info\2016 - MI - Tax Refund Statement.jpg) 00000100 08000040 00000000 0. file = 17556
2020/06/11 16:18:53.51: 9 2: NdpFileQueryInfo in [0x6e3a80]
2020/06/11 16:18:53.51: 9 2: fname \public\DOCUMENTS\Family\Finance\TAX\2016\US Info\2016 - MI - Tax Refund Statement.jpg
2020/06/11 16:18:53.51: 9 2: btime 1494688532 Sat May 13 11:15:32 2017
2020/06/11 16:18:53.51: 9 2: atime 1591275626 Thu Jun  4 09:00:26 2020
2020/06/11 16:18:53.51: 9 2: mtime 1494688532 Sat May 13 11:15:32 2017
2020/06/11 16:18:53.51: 9 2: ctime 1494688532 Sat May 13 11:15:32 2017
2020/06/11 16:18:53.51: 9 2: ftimeLastAccess 11:15:32
2020/06/11 16:18:53.51: 9 2: NdpFileQueryInfo <\public\DOCUMENTS\Family\Finance\TAX\2016\US Info\2016 - MI - Tax Refund Statement.jpg> 0
2020/06/11 16:18:53.51: 9 2: NdpFileSetFilePtrL in [0x6e3a80]
2020/06/11 16:18:53.51: 4 2: lseek 1 0 0
2020/06/11 16:18:53.51: 9 2: NdpFileSetFilePtrL <\public\DOCUMENTS\Family\Finance\TAX\2016\US Info\2016 - MI - Tax Refund Statement.jpg> 0 1 0 0
2020/06/11 16:18:53.51: 9 2: NdpFileQueryInfo in [0x6e3a80]
2020/06/11 16:18:53.51: 9 2: fname \public\DOCUMENTS\Family\Finance\TAX\2016\US Info\2016 - MI - Tax Refund Statement.jpg
2020/06/11 16:18:53.51: 9 2: btime 1494688532 Sat May 13 11:15:32 2017
2020/06/11 16:18:53.51: 9 2: atime 1591275626 Thu Jun  4 09:00:26 2020
2020/06/11 16:18:53.51: 9 2: mtime 1494688532 Sat May 13 11:15:32 2017
2020/06/11 16:18:53.51: 9 2: ctime 1494688532 Sat May 13 11:15:32 2017
2020/06/11 16:18:53.51: 9 2: ftimeLastAccess 11:15:32
2020/06/11 16:18:53.51: 9 2: NdpFileQueryInfo <\public\DOCUMENTS\Family\Finance\TAX\2016\US Info\2016 - MI - Tax Refund Statement.jpg> 0
2020/06/11 16:18:53.51: 9 2: NdpFileRead in [0x6e3a80], ulRead = 32768
2020/06/11 16:18:53.52: 4 2:  smbwrp_read successful, nread = 32768, ret = 0
...

--- End code ---

2) PDFs

--- Code: ---...
NdpQueryPathInfo <PUBLIC\DOCUMENTS\Family\FINANCE\TAX\2016\US Info\2016 - MTOR - Paystub - FINAL.pdf> (\PUBLIC\DOCUMENTS\Family\FINANCE\TAX\2016\US Info\2016 - MTOR - Paystub - FINAL.pdf) 0
2020/06/11 20:53:17.76: 9 2: smbopen in [0x6fb340] -1
2020/06/11 20:53:17.76: 4 2: cli_open(\PUBLIC\DOCUMENTS\Family\FINANCE\TAX\2016\US Info\2016 - MTOR - Paystub - FINAL.pdf) attr 00000000 mode 100 denymode 04
2020/06/11 20:53:17.76: 9 2: smbopen <PUBLIC\DOCUMENTS\Family\FINANCE\TAX\2016\US Info\2016 - MTOR - Paystub - FINAL.pdf> (\PUBLIC\DOCUMENTS\Family\FINANCE\TAX\2016\US Info\2016 - MTOR - Paystub - FINAL.pdf) 00000100 08000040 00000000 0. file = 17563
2020/06/11 20:53:17.76: 9 2: NdpRsrcQueryInfo in
2020/06/11 20:53:17.76: 9 2: NdpRsrcQueryInfo 0
2020/06/11 20:53:17.76: 9 2: NdpFileSetFilePtrL in [0x6fb340]
2020/06/11 20:53:17.76: 4 2: lseek 2 0 0
2020/06/11 20:53:17.76: 9 2: NdpFileSetFilePtrL <\PUBLIC\DOCUMENTS\Family\FINANCE\TAX\2016\US Info\2016 - MTOR - Paystub - FINAL.pdf> 0 2 4322 0
2020/06/11 20:53:17.76: 9 2: NdpFileSetFilePtrL in [0x6fb340]
2020/06/11 20:53:17.76: 4 2: lseek 2 0 4322
...

--- End code ---

I'll get a NEW log built because that was way back in 2020 (June) and I'm pretty sure we've had Samba client updates since.

Navigation

[0] Message Index

[#] Next page

Go to full version