Samsung SCX-4729FW (TCP mode): scanning gets stuck while receiving image (internal infinite loop)
SANE backends version: 22108dca
When scanning in TCP mode (in some Wi-Fi network congestion conditions), the SCX-4729FW gets stuck while receiving the image. SCX-4729FW was set not to use JPEG compression (black-listed).
I observed this issue both with Simple-Scan and scanimage front-ends. The issue is rather irregular, sometimes it gets stuck right at the first page, other times it's on later pages. Apparently, it's tied to TCP packet fragmentation which happens more when the network is congested. Stopping and then re-running the scan usually would complete it correctly. But it's not really a reliable workaround.
When running the front-end with SANE_DEBUG_XEROX_MFP=255 to enable debug logging, it appears that the code gets stuck in an infinite loop. Here's a fragment of the log file just before it gets stuck:
....
[17:48:46.022490] [xerox_mfp] acquiring, size per band v: 96, h: 1280, block: 368656, slack: 16
[17:48:46.022524] [xerox_mfp] READ_IMAGE
[17:48:46.022555] [xerox_mfp] :: dev_command(READ_IMAGE[0x29], 32)
[17:48:46.022809] [xerox_mfp] <> request len: 65536, [0, 0; 0]
[17:48:46.022843] [xerox_mfp] tcp_dev_request: wait for 65536 bytes
[17:48:48.614269] [xerox_mfp] tcp_dev_request: error Resource temporarily unavailable, bytes requested: 65536, bytes read: 59860
[17:48:48.614374] [xerox_mfp] <> got 59860, [0, 59860; 59860]
[17:48:48.614428] [xerox_mfp] <> request len: 5632, [0, 59860; 59860]
[17:48:48.614482] [xerox_mfp] tcp_dev_request: wait for 5632 bytes
[17:48:48.745748] [xerox_mfp] <> got 5632, [0, 65492; 65492]
[17:48:48.748849] [xerox_mfp] <> olen: 42241, clrlen: 42240, blocklen: 303164/23252, maxlen 0 (971 960 1630)
[17:48:48.748906] [xerox_mfp] ==> 42241
[17:48:48.749050] [xerox_mfp] sane_xerox_mfp_read: 0x7fe0f00088c0, 0x7fe0f0031101, 46080, 0x7fe107ffeb10
[17:48:48.750500] [xerox_mfp] <> olen: 23039, clrlen: 23040, blocklen: 303164/212, maxlen 23041 (977 960 1630)
[17:48:48.750538] [xerox_mfp] <> olen: 0, clrlen: 0, blocklen: 303164/212, maxlen 23041 (977 960 1630)
[17:48:48.750554] [xerox_mfp] ==> 23039
[17:48:48.750622] [xerox_mfp] sane_xerox_mfp_read: 0x7fe0f00088c0, 0x7fe0f003c510, 46081, 0x7fe107ffeb10
[17:48:48.750688] [xerox_mfp] <> olen: 0, clrlen: 0, blocklen: 303164/212, maxlen 46081 (977 960 1630)
[17:48:48.750705] [xerox_mfp] ==> 0
[17:48:48.750731] [xerox_mfp] sane_xerox_mfp_read: 0x7fe0f00088c0, 0x7fe0f003c510, 46081, 0x7fe107ffeb10
[17:48:48.750804] [xerox_mfp] <> olen: 0, clrlen: 0, blocklen: 303164/212, maxlen 46081 (977 960 1630)
[17:48:48.750821] [xerox_mfp] ==> 0
[17:48:48.750845] [xerox_mfp] sane_xerox_mfp_read: 0x7fe0f00088c0, 0x7fe0f003c510, 46081, 0x7fe107ffeb10
[17:48:48.750913] [xerox_mfp] <> olen: 0, clrlen: 0, blocklen: 303164/212, maxlen 46081 (977 960 1630)
[17:48:48.750929] [xerox_mfp] ==> 0
........This issue is likely applicable to other scanners using the xerox_mfp backend with TCP transport.
I've got some idea about what may be the problem in the current xerox_mfp code, but need to investigate and test it further.