Web server disconnecting before transfer complete

[aaron.teitlebaum]

Hi all,

I've been trying to use the built-in Do-More web server to transfer some data files with sizes on the order of 10-100 kB from a BX-DM1E to my PC. They're stored in subfolders inside of the /sd folder on the microSD card. I've tried using several tools to retrieve them, including wget, curl, and the Chrome web browser, and the problem I keep having is that most times the web server apparently closes the connection before the entire file is transferred.

There seems to be a pattern to where in the transfer the disconnection happens: on multiple retries it'll often happen after exactly the same number of bytes transferred, or if there's variation it's often by some whole multiple of 1024 bytes remaining in the file. For example, I'm currently trying to fetch a file that's 114716 bytes long, and on five repeated retries wget has reported "connection closed" at bytes 77852, 86044, 87040, 87040, and 87040. That means the bytes remaining were 36864 (36 * 1024), 28672 (28 * 1024), and 27676 (27.03 * 1024) respectively. Occasionally a file transfer will complete successfully, but it's rare. I'm reaching this PLC over a corporate VPN with a WiFi bridge as the last leg of the trip, but it's a reliable link with no packet loss, and the ping is about 100 ms.

Can anyone suggest why this might be happening or what I could do to correct the issue? Thanks.

[BobO]

Hi all,

I've been trying to use the built-in Do-More web server to transfer some data files with sizes on the order of 10-100 kB from a BX-DM1E to my PC. They're stored in subfolders inside of the /sd folder on the microSD card. I've tried using several tools to retrieve them, including wget, curl, and the Chrome web browser, and the problem I keep having is that most times the web server apparently closes the connection before the entire file is transferred.

There seems to be a pattern to where in the transfer the disconnection happens: on multiple retries it'll often happen after exactly the same number of bytes transferred, or if there's variation it's often by some whole multiple of 1024 bytes remaining in the file. For example, I'm currently trying to fetch a file that's 114716 bytes long, and on five repeated retries wget has reported "connection closed" at bytes 77852, 86044, 87040, 87040, and 87040. That means the bytes remaining were 36864 (36 * 1024), 28672 (28 * 1024), and 27676 (27.03 * 1024) respectively. Occasionally a file transfer will complete successfully, but it's rare. I'm reaching this PLC over a corporate VPN with a WiFi bridge as the last leg of the trip, but it's a reliable link with no packet loss, and the ping is about 100 ms.

Can anyone suggest why this might be happening or what I could do to correct the issue? Thanks.

No idea. I did a quick test on a local LAN and it works fine there. I kicked up the PLC scan time to force the download to take longer and it still seems fine.

You might try sending a file via HTTPCMD or FTPPUT to see how that behaves on the same network. While the webserver doesn't report any diagnostics, those instructions dump quite a bit. Might give you some insight.

[aaron.teitlebaum]

No idea. I did a quick test on a local LAN and it works fine there. I kicked up the PLC scan time to force the download to take longer and it still seems fine.

You might try sending a file via HTTPCMD or FTPPUT to see how that behaves on the same network. While the webserver doesn't report any diagnostics, those instructions dump quite a bit. Might give you some insight.

Unfortunately I can't test an HTTPCMD or FTPPUT because for security reasons devices on our network like PLCs can't make outgoing connections. However, I have done some more testing by transferring a file that's 113,141 bytes, but only 84,395 were received from the web server.

The connection isn't getting closed prematurely, instead chunks of the file are missing throughout. By comparing the complete file I downloaded in Do-More Designer to the incomplete file I got from the web server (see attached), I see that contiguous blocks of 1024 bytes (or multiples of 1024) are missing. I also captured the whole exchange with Wireshark and I see that 1024 bytes is the size of the TCP packet payload, so apparently packets are getting lost somewhere. However, Wireshark doesn't identify any issues with missing packets, so it seems like the HTTP server just never sent the missing packets. Also, if it's relevant, my average scan time is currently 2.2 ms.

Is this information of any use, or is there anything else I could provide? I'd love to be able to make full use of the web server, but the dropped packets are making it unreliable. Thanks.

[BobO]

Unfortunately I can't test an HTTPCMD or FTPPUT because for security reasons devices on our network like PLCs can't make outgoing connections. However, I have done some more testing by transferring a file that's 113,141 bytes, but only 84,395 were received from the web server.

The connection isn't getting closed prematurely, instead chunks of the file are missing throughout. By comparing the complete file I downloaded in Do-More Designer to the incomplete file I got from the web server (see attached), I see that contiguous blocks of 1024 bytes (or multiples of 1024) are missing. I also captured the whole exchange with Wireshark and I see that 1024 bytes is the size of the TCP packet payload, so apparently packets are getting lost somewhere. However, Wireshark doesn't identify any issues with missing packets, so it seems like the HTTP server just never sent the missing packets. Also, if it's relevant, my average scan time is currently 2.2 ms.

Is this information of any use, or is there anything else I could provide? I'd love to be able to make full use of the web server, but the dropped packets are making it unreliable. Thanks.

Have you attempted the same operation from the PLC side of the VPN?

[aaron.teitlebaum]

Have you attempted the same operation from the PLC side of the VPN?

Not yet, unfortunately this PLC is located in a different state. The next time I'm there I'll give it a try.