search for: oldmss

We have a Zenoss server in our main office monitoring (among many other things) an Apache server in a remote network, with a Tinc link between the two networks. The monitoring simply involves making an HTTP request to a URL once every 5 minutes and confirming that a response page comes back. Most of the requests to this particular web server succeed (and similar requests to other web servers

...t is always off by 1. > [...] > Am I correct in concluding that this cksum problem is a bug in Tinc? After investigating this further, I'm fairly certain that problem originates in the following lines of the clamp_mss() function in route.c: [...] csum ^= 0xffff; csum -= oldmss; csum += newmss; csum ^= 0xffff; packet->data[50] = csum >> 8; packet->data[51] = csum & 0xff; Since the TCP checksum value needs to be computed using one's compliment arithmetic, the above code generates new values that are off by one from the correct check...

...u_int8_t *)tcph; - for (i = sizeof(struct tcphdr); i <= tcp_hdrlen - TCPOLEN_MSS; i += optlen(opt, i)) { + for (i = sizeof(struct tcphdr); i + TCPOLEN_MSS <= tcp_hdrlen; i += optlen(opt, i)) { if (opt[i] == TCPOPT_MSS && opt[i+1] == TCPOLEN_MSS) { u_int16_t oldmss; -- You are receiving this mail because: You are watching all bug changes. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20170119/963b8361/attachment.html>