The manpage for recvmsg says -1 will be returned on error, Zero indicates an
"orderly shutdown", presumably only in case of stream sockets.
Further, UNIX Network Programming, Vol 1 says ".. a return value of 0 from
recvfrom is acceptable for a datagram protocol"
Such packets have been observed in the wild, aimed at PTP's multicast
address and port, possibly related to malformed management queries.
Patch to properly check return from recvmesg and not trigger the fault
codepath. Instead, such packets are treated as "Bad Message" the same as
non-zero but still too-short UDP payloads.
Signed-off-by: David Mirabito <davi...@arista.com>
---
port.c | 2 +-
sk.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/port.c b/port.c
index ad9554f..9264211 100644
--- a/port.c
+++ b/port.c
@@ -2563,7 +2563,7 @@ static enum fsm_event bc_event(struct port *p, int
fd_index)
msg->hwts.type = p->timestamping;
cnt = transport_recv(p->trp, fd, msg);
- if (cnt <= 0) {
+ if (cnt < 0) {
pr_err("port %hu: recv message failed", portnum(p));
msg_put(msg);
return EV_FAULT_DETECTED;
diff --git a/sk.c b/sk.c
index 30162eb..93ba77a 100644
--- a/sk.c
+++ b/sk.c
@@ -359,7 +359,7 @@ int sk_receive(int fd, void *buf, int buflen,
}
cnt = recvmsg(fd, &msg, flags);
- if (cnt < 1)
+ if (cnt < 0)
pr_err("recvmsg%sfailed: %m",
flags == MSG_ERRQUEUE ? " tx timestamp " : " ");
--
2.17.2 (Apple Git-113)
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
