bfd: Set next_tx correctly when processing packets

In the case where we have not yet sent a control packet for a bfd
connection, and we receive a control packet from the remote host,
bfd->next_tx is updated to an unusual value. This causes the logging to
incorrectly report that there has been long delays (in the order of
weeks) since the last bfd transmission time.

This patch only modifies bfd->next_tx in this case if we are not
expecting to immediately send a control packet. This should mean that
bfd->next_tx is either 0 (immediate tx) or in the order of time_msec().

Signed-off-by: Joe Stringer <joestringer@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>

diff --git a/lib/bfd.c b/lib/bfd.c
index 69b4f0e..a4179f8 100644 (file)
--- a/lib/bfd.c
+++ b/lib/bfd.c
@@ -760,7 +760,9 @@ bfd_process_packet(struct bfd *bfd, const struct flow *flow,
     rmt_min_rx = MAX(ntohl(msg->min_rx) / 1000, 1);
     if (bfd->rmt_min_rx != rmt_min_rx) {
         bfd->rmt_min_rx = rmt_min_rx;
-        bfd_set_next_tx(bfd);
+        if (bfd->next_tx) {
+            bfd_set_next_tx(bfd);
+        }
         log_msg(VLL_INFO, msg, "New remote min_rx", bfd);
     }