Simon 'corecode' Schubert wrote: > > Are you using NAT? > > yep. > > > The libalias incremental checksum calculation is incorrect; > > it assumes that a two's complement network order underflow > > will result in the same value as a one's complement host > > order underflow. This results in off-by-one errors. > > so is this an optimisation issue or not? when compiling with -O it works > again. furthermore i don't know if my bind uses the internal address or > the external one for queries.
The short answer is "I don't know". The longer answer is "It depends". The problem is that there are certain optimizations that are permissable, which could break associativity on the carry. The only way to tell would be to have a dump that included wire/before NAT/after NAT/decode, and then see where it blew up. I made the assumption (perhaps invalid) that when you said the checksum calculation was invalid that it was invalid on check vs. being invalid on transmit. That it's the incremental checksum calculation is a good bet anyway, since the optimized machine dependent code that's used in the standard path isn't going to change much anyway. > > There's also printing it out in tcp_input when you get a bad > > checksum. If you see a lot of "0xfffe", then you'll know it's > > an off-by-one error. > > yah, got lots of them, seen in tcpdump -vvvxXlei gif0 ;] > > > If the problem is only on ACK packets... I can tell you that > > the tcp_respond() code path is not really throughly exercised. > > tho i've seen these problems recently on UDP DNS lookups, too. then i > switched back to -O Most likely it's the TTL update, then, near border underflow cases. I had a recent situation where I was doing sequence adjustment, and by using the loopback for testing, I ended up with the sequence number randomness causing the problem about 45% of the time, because of the probability of underflow being so much higher. THe easy answer is that you need to ntohs((u_short)ip->ip_ttl) before you add it, and then do the incremental update in HTONS(ip->ip_seq); /* adjust */ HTONS(ip-ip_seq);. The harder way would be to correct the carry for the byte swapped order, but it's a real pain to do. If you look at the code in RFC 1141, it shows how to do this, but it's not exactly correct because of the problem RFC 1624 points out. Basically, you end up needing to do the complemnatry math, instead of the complement of the regular math. Hope this helps. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
