Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A fifteen year old TCP bug?

blogmal.42.org

Post reply on HN
Print view View original

31–40 of 61 posts

Re: A fifteen year old TCP bug?

#31

Post by peterbotond »

cube13 wrote: post #28
feintruled wrote: post #4

The response to the bug report looks depressingly typical. Rejects the working fix with a wall of text speculation on numerous other possibly better fixes (without deigning to actually choose one). Nirvana fallacy in action!

It's a working fix, but isn't the proper fix. The real issue is the size difference of the long type for 32 and 64-bit architectures. Bruce Evans doesn't explicitly mention this fact, but it's the core of his reasoning. Since long is 64-bits on 64-bit architecture, and 32 on 32-bit architecture. This is the reason that 0xffffffff is showing up as a non-negative number on the 64-bit machine, but shows up as negative o…

a better fix to use the lmin macro. libkern.h.

http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/src/sys/sys...

Re: A fifteen year old TCP bug?

#32

Post by btilly »

estel wrote: post #22
doki_pen wrote: post #21

Earlier quoted context omitted.

Wouldn't that be fair use? Do you have issue with the content being posted, or the fact that it's scanned?

Quoting parts of the book to support some points made in the article would fall under fair use, but linking to a scan of the entire book would not.

Hosting a scan is not fair use, but linking to a copyright violation is not generally a copyright violation. Though a few courts have ruled that it can be if done for the specific purpose of knowingly disseminating illegal material. See http://www.chillingeffects.org/linking/faq.cgi#QID152 for more.

Re: A fifteen year old TCP bug?

#33

Post by cube13 »

peterbotond wrote: post #31
cube13 wrote: post #28

Earlier quoted context omitted.

It's a working fix, but isn't the proper fix. The real issue is the size difference of the long type for 32 and 64-bit architectures. Bruce Evans doesn't explicitly mention this fact, but it's the core of his reasoning. Since long is 64-bits on 64-bit architecture, and 32 on 32-bit architecture. This is the reason that 0xffffffff is showing up as a non-negative number on the 64-bit machine, but shows up as negative o…

a better fix to use the lmin macro. libkern.h. http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/src/sys/sys...

Not really. The line is this: long adv = min(recwin, (long)TCP_MAXWIN rcv_scale) - (tp->rcv_adv - tp->rcv_nxt);

So it's really: long = uint(long, (long)uint32) - (uint32-uint32)

Here's the problem on x64: you're converting a 64-bit long to a uint, then doing a subtraction with another uint, then placing that result into a 64-bit long. Since the compiler is just doing an assignment rather than a sign extension, which is why there is a large positive number rather than -1.

Changing it to use the lmin macro would make it: long = long(long, (long)uint32) - (uint32-uint32)

This still has the underlying issue(using 32-bit values in 64-bit buckets), which should work out fine, but may have issues down the road.

It makes more sense to change all the long types to int32/uint32 types rather than just cast longs everywhere. If recwin and adv were changed to int32, it would be: int32 = uint32(int32, uint32) - (uint32 - uint32)

While this potentially has issues if the uints are between 0x80000000 and 0xfffffff, it's a safer solution than using longs.

EDIT: added some explanation

Re: A fifteen year old TCP bug?

#34

Post by estel »

btilly wrote: post #32
estel wrote: post #22

Earlier quoted context omitted.

Quoting parts of the book to support some points made in the article would fall under fair use, but linking to a scan of the entire book would not.

Hosting a scan is not fair use, but linking to a copyright violation is not generally a copyright violation. Though a few courts have ruled that it can be if done for the specific purpose of knowingly disseminating illegal material. See http://www.chillingeffects.org/linking/faq.cgi#QID152 for more.

That's true, but the original point was 'poor form', which this likely falls under also.

Re: A fifteen year old TCP bug?

#36

Post by btmorex »

feintruled wrote: post #4

The response to the bug report looks depressingly typical. Rejects the working fix with a wall of text speculation on numerous other possibly better fixes (without deigning to actually choose one). Nirvana fallacy in action!

You have to do this if you want your codebase to get better over time rather than worse over time.

Re: A fifteen year old TCP bug?

#37

Post by ZoFreX »

btilly wrote: post #32
estel wrote: post #22

Earlier quoted context omitted.

Quoting parts of the book to support some points made in the article would fall under fair use, but linking to a scan of the entire book would not.

Hosting a scan is not fair use, but linking to a copyright violation is not generally a copyright violation. Though a few courts have ruled that it can be if done for the specific purpose of knowingly disseminating illegal material. See http://www.chillingeffects.org/linking/faq.cgi#QID152 for more.

It may not be illegal, but it's incredibly poor form.

Re: A fifteen year old TCP bug?

#38

Post by a1k0n »

barrkel wrote: post #9

So much of this is caused by unsigned types. They are evil; avoid them wherever you can.

A coworker of mine was just bit badly by Java's insistence that unsigned types are so evil that the language shouldn't have them. He calculated a 32-bit hash, but since the ints are all signed, he took the absolute value before the modulo with the hash table size. That's all well and good, but abs(-2147483648) is still -2147483648 in 32-bit two's complement arithmetic.

I'm sure I don't need to point out that this particular problem had nothing to do with unsigned types (they were signed!). A better rule of thumb is: never use "long" in C/C++ unless you really don't care whether it's 32 or 64 bits.

Re: A fifteen year old TCP bug?

#39

Post by SwellJoe »

sedachv wrote: post #27
cletus wrote: post #19

Earlier quoted context omitted.

1-2 years ago I had the exact same thing with a PHP bug (I know, PHP bugs... shocking!), specifically with mysqli. It would crash on LONGTEXT columns. Not reliably. Different people reported it in different forms over 2-3 years previous. all of them getting automated responses ("Please provide...") followed by ("Closed due to no activity for 7 days...") with the odd dismissive comment by a committer. It's an incredib…

This is why forks happen (I've forked two projects because of this, three if you count one I've deployed but haven't publicly released).

If you can fork it, you can include a patch in your bug report. Sometimes, that's all it takes to make things happen.

The most infuriating situations for me are when I submit a working patch, and it is ignored. This is, thankfully, very rare. In some cases, the patch leads to a better fix being written by the maintainer or someone else (an example of this for me was when I needed yum to support authenticated repositories; it didn't, so I patched it, posted the patch to the mailing list, and soon after one of the members of the team rewrote it to be more robust and have nicer configuration syntax within a week).

Re: A fifteen year old TCP bug?

#40

Post by pmjordan »

zwp wrote: post #23
pmjordan wrote: post #17

Earlier quoted context omitted.

Maybe, if you could trick the server (64-bit FreeBSD) into connecting to sockets open on 32-bit FreeBSD machines. I can't think of any common services that would be susceptible to this (they would normally be susceptible to being tricked into opening other kinds of long-standing connections, too, which is just as good for DoS).

> if you could trick the server (64-bit FreeBSD) into connecting to sockets Proxies, SMTP gateways, FTP servers (active mode), ...

Proxies usually have connection limits. FTP might work.
Post reply on HN