@@ -106,14 +106,22 @@ void extract_padding(int fd, unsigned long *offset)
return;
padding = (512 - (*offset % 512)) % 512;
- if (padding) {
- TRACE("Expecting %d padding bytes at end-of-file", padding);
+ if (!padding)
+ return;
+
+ TRACE("Expecting %d padding bytes at end-of-file", padding);
+ do {
len = read(fd, buf, padding);
if (len < 0) {
DEBUG("Failure while reading padding %d: %s", fd, strerror(errno));
return;
}
- }
+ padding -= len;
+ } while (len > 0);
+
+ if (padding > 0)
+ DEBUG("Expected %d more bytes of padding", padding);
+ return;
return;
}
@@ -229,7 +229,6 @@ static int extract_files(int fd, struct swupdate_cfg
*software)
(skip == SKIP_FILE ? "Not required: skipping" : "required"));
fdout = -1;
- offset = 0;
/*
Hi, Is there anything else that I can do to help with this? We're seeing sporadic update failures when using swupdate-client stemming from this issue. Best regards, Nick On Tuesday, June 6, 2023 at 8:17:42 AM UTC-5 Nick Potenski wrote: The stream interface would not read all data from the socket due to two separate issues. This could cause swupdate to close the socket fd before a client has written all data, which results in an EPIPE on the client. First, stream_interface.c's extract_files() reset its offset variable before processing each file. This value is 4-byte aligned but not 512-byte aligned, so when it was used by cpio-utils.c's extract_padding() to compute the expected padding, it would produce an incorrect padding amount. Second, cpio-utils.c's extract_padding() could fail to read all padding in cases where the client uses a smaller chunk size, especially one less than the padding size, such as the swupdate-client reference implementation's 256 byte chunk size. Signed-off-by: Nick Potenski <nick.p...@garmin.com> --- core/cpio_utils.c | 14 +++++++++++--- core/stream_interface.c | 1 - 2 files changed, 11 insertions(+), 4 deletions(-) * If images are not streamed directly into the target