is it a lack of mrouted 3.6 or the lack of little endian machines that's holding y'all back?
On Fri, Jul 28, 2017 at 12:31:44PM +0000, Florian Obser wrote: > this can probably go. I wandered in there because clang says: > > /usr/src/usr.sbin/mtrace/mtrace.c:949:12: warning: taking the absolute value > of unsigned type 'unsigned int' has no effect [-Wabsolute-value] > if (*s || abs(ntohl(n->tr_vifout) - ntohl(p->tr_vifout)) > > 100000) { > ^ > > OK? > > > diff --git mtrace/mtrace.c mtrace/mtrace.c > index 717c251c20c..a2ab28dbbf8 100644 > --- mtrace/mtrace.c > +++ mtrace/mtrace.c > @@ -148,8 +148,6 @@ int what_kind(struct resp_buf *buf, > char *why); > char * scale(int *hop); > void stat_line(struct tr_resp *r, struct tr_resp *s, > int have_next, int *res); > -void fixup_stats(struct resp_buf *base, > - struct resp_buf *prev, struct resp_buf *new); > int print_stats(struct resp_buf *base, > struct resp_buf *prev, struct resp_buf *new); > void check_vif_state(void); > @@ -929,86 +927,6 @@ stat_line(struct tr_resp *r, struct tr_resp *s, int > have_next, int *rst) > } > > /* > - * A fixup to check if any pktcnt has been reset, and to fix the > - * byteorder bugs in mrouted 3.6 on little-endian machines. > - */ > -void > -fixup_stats(struct resp_buf *base, struct resp_buf *prev, struct resp_buf > *new) > -{ > - int rno = base->len; > - struct tr_resp *b = base->resps + rno; > - struct tr_resp *p = prev->resps + rno; > - struct tr_resp *n = new->resps + rno; > - int *r = reset + rno; > - int *s = swaps + rno; > - int res; > - > - /* Check for byte-swappers */ > - while (--rno >= 0) { > - --n; --p; --b; --s; > - if (*s || abs(ntohl(n->tr_vifout) - ntohl(p->tr_vifout)) > 100000) { > - /* This host sends byteswapped reports; swap 'em */ > - if (!*s) { > - *s = 1; > - b->tr_qarr = byteswap(b->tr_qarr); > - b->tr_vifin = byteswap(b->tr_vifin); > - b->tr_vifout = byteswap(b->tr_vifout); > - b->tr_pktcnt = byteswap(b->tr_pktcnt); > - } > - > - n->tr_qarr = byteswap(n->tr_qarr); > - n->tr_vifin = byteswap(n->tr_vifin); > - n->tr_vifout = byteswap(n->tr_vifout); > - n->tr_pktcnt = byteswap(n->tr_pktcnt); > - } > - } > - > - rno = base->len; > - b = base->resps + rno; > - p = prev->resps + rno; > - n = new->resps + rno; > - > - while (--rno >= 0) { > - --n; --p; --b; --r; > - res = ((ntohl(n->tr_pktcnt) < ntohl(b->tr_pktcnt)) || > - (ntohl(n->tr_pktcnt) < ntohl(p->tr_pktcnt))); > - if (debug > 2) > - printf("\t\tr=%d, res=%d\n", *r, res); > - if (*r) { > - if (res || *r > 1) { > - /* > - * This router appears to be a 3.4 with that nasty ol' > - * neighbor version bug, which causes it to constantly > - * reset. Just nuke the statistics for this node, and > - * don't even bother giving it the benefit of the > - * doubt from now on. > - */ > - p->tr_pktcnt = b->tr_pktcnt = n->tr_pktcnt; > - r++; > - } else { > - /* > - * This is simply the situation that the original > - * fixup_stats was meant to deal with -- that a > - * 3.3 or 3.4 router deleted a cache entry while > - * traffic was still active. > - */ > - *r = 0; > - break; > - } > - } else > - *r = res; > - } > - > - if (rno < 0) return; > - > - rno = base->len; > - b = base->resps + rno; > - p = prev->resps + rno; > - > - while (--rno >= 0) (--b)->tr_pktcnt = (--p)->tr_pktcnt; > -} > - > -/* > * Print responses with statistics for forward path (from src to dst) > */ > int > @@ -1591,7 +1509,6 @@ or multicast at ttl %d doesn't reach its last-hop > router for that source\n", > > printf("Results after %d seconds:\n\n", > (int)((new->qtime - base.qtime) >> 16)); > - fixup_stats(&base, prev, new); > if (print_stats(&base, prev, new)) { > printf("Route changed:\n"); > print_trace(1, new); > > -- > I'm not entirely sure you are real. > -- I'm not entirely sure you are real.