14 ms·

A fifteen year old TCP bug?

546 points by Sec 16y ago

rboyd 16y ago
The only reply this PR got, was from Bruce Evans who critiqued my use of a simple (long) cast, which appears to have derailed this PR, sticking it in the usual never getting fixed limbo where unfortunately most of my PR's appear to end up. Looks to me like Bruce gave you some valuable advice. You spent more time complaining about the handling of your PR and documenting the issue on your blog than it would have taken you to fix your patch.
direxorg 16y ago
In 2002 we did custom patch for an energy company which had hundreds of outdated remote RS232 terminals hooked up via wireless links to the central station for control and monitoring. Their goal was to encrypt transmitted messages so it will not be intercepted and messed with during wireless transmission. Solution was Linux boxes on both sides that encrypts communication using OpenSSL... The problem was the terminal do not want to talk to Linux over crossover Ethernet because of.... you guessed... bug in TCP... To solve that we had to make patch for Linux kernel. and let me tell you that code in 2.4 kernel was very ugly with extremely funny comments :-) My companion since than developing drivers and "he feels that he is doing something important rather than boring UI". but all he is doing is mostly his own projects and drivers since updating open source IS a pain in the neck. I guess problem in collaborative work is the reason why people do open source vs something that have to be supported. What do you think?
pilom 16y ago
This is true hacking news! Discusses a possible new bug in TCP, teaches how TCP works, has links to useful and relevant books on the subject, AND includes remarks about how difficult it is for a newbie to actually make changes to open source software and not get yelled at. I love it!
- rwmj 16y ago
  .. and comes from a cool hackerish domain (42.org)
- mrspeaker 16y ago
  I agree - but it's funny that there's only a handful of comments. You just can't have an uninformed rant with such technical correctness (the best kind of correctness)!
feintruled 16y ago
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!
- stcredzero 16y ago
  I know of one commercial Smalltalk UI bug that persisted 12 years -- being reported all the while. To be fair, it was a very tricky low-level race condition, very hard to reproduce, though very serious. (Unhandled exception in the bowels of the UI library. Boom! Application goes down.) Still, the attitude of the vendor was just unbelievable from the POV of the customer. After dozens of reports, hundreds of messages, numerous pieces of documentation, it still took 12 years for engineers to even start thinking it was something besides user error -- even though multiple customers were reporting it. (I know because I worked for 3 of them!) There is a huge perceptual wall there. I know because I used to work for the vendor. I know how apparent this bug is at a production shop and how opaque it appears from inside the vendor's camp. (And despite my being from inside, I still got the "user error" chant!) EDIT: Oh, and I know of another UI bug that's been in their system for about 8 years. It's a Smalltalk newbie classic -- shoving non-identity keys into an IdentityDictionary. I could describe what it is to a Smalltalker in 2 sentences, and they could then find it and fix it. This vendor seems to have the same attitude about this bug, so I've already learned my lesson. They can keep their damn bug!
  - cletus 16y ago
    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 incredibly frustrating experience.
    - sedachv 16y ago
runjake 16y ago
The response to the bug report was by Bruce Evans, who is listed as the "Style Police-Meister" for FreeBSD. Apparently his job is to enforce standards & code style. Seems like he was doing his job. http://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/people.html http://www.freebsd.org/doc/en_US.ISO8859-1/articles/committe... Edit: edited for clarity. Thanks, pinko!
- pinko 16y ago
  I believe the comment above was meant as a response to the "The response to the bug report looks depressingly typical" comment elsewhere in this thread. It took me a minute to sort that out ("hmm, why is he referencing Bruce Evans?"), so I thought I'd mention it for anyone else trying to follow.
- deleted 16y ago
  [deleted]
ig1 16y ago
I only had a quick skim through the article (need to be off to the London HN meetup shortly!), but couldn't this be used to mount a DOS attack sucking up the number of available sockets on a server?
- pmjordan 16y ago
  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).
  - zwp 16y ago
    > if you could trick the server (64-bit FreeBSD) into connecting to sockets Proxies, SMTP gateways, FTP servers (active mode), ...
    - pmjordan 16y ago
      Proxies usually have connection limits. FTP might work.
    - delinka 16y ago
      "...on 32-bit [systems]" is the operative part of his statement. I'm pretty sure 'tricking' a client into opening connections to a server is trivial regardless of TCP bugs.
HenryR 16y ago
Is Stevens vol. 2 in the public domain now? If not, that's pretty poor form, linking to a scanned pdf of the book.
- uxp 16y ago
  No, actually it's not public domain. The 19th edition was printed and released in 2005. Pearson looks like it actively tries to protect it's copyrights to the series as well: http://www.foo.be/docs/TCPIP-Illustrated-1/ http://www.foo.be/docs/TCPIP-Illustrated-1/
- doki_pen 16y ago
  Wouldn't that be fair use? Do you have issue with the content being posted, or the fact that it's scanned?
  - estel 16y ago
    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.
    - btilly 16y ago
      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 http://www.chillingeffects.org/linking/faq.cgi#QID152 for more.
      - estel 16y ago
        That's true, but the original point was 'poor form', which this likely falls under also.
      - ZoFreX 16y ago
        It may not be illegal, but it's incredibly poor form.
barrkel 16y ago
So much of this is caused by unsigned types. They are evil; avoid them wherever you can.
- __david__ 16y ago
  I wouldn't say they are evil. In fact, both signed and unsigned are the same--the only difference is the "pain point" (the place where you subtract 1 and your world breaks) is in a different spot. 0 for unsigned, INT_MIN for signed. Both are perfectly fine as long as you stay in their good range.
  - barrkel 16y ago
    Yes - but 0 is much closer to the range most people put in their integer values than INT_MIN. The cliff you fall of off is far closer with unsigned integers.
- 1amzave 16y ago
  Care to elaborate? Unlike signed ones, unsigned integral types at least have well-defined behavior on shifting and overflow. (I'm speaking in terms C specifically here, of course.)
  - cpeterso 16y ago
    Signed ints are easier to range check at runtime. Given an unsigned int, it's difficult to detect an invalid result from combining or comparing signed and unsigned ints. Google's C++ Style Guide discourages using unsigned ints to represent nonnegative numbers (like sizes or counts). It recommends using runtime checks or assertions instead. http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Integer_Types http://google-styleguide.googlecode.com/svn/trunk/cppguide.x... Unsigned ints make sense for bit twiddling, but you should probably use a fixed-size uint32_t or uint64_t to ensure the results are consistent across various architectures.
    - seabee 16y ago
      > it's difficult to detect an invalid result from combining or comparing signed and unsigned ints Isn't this why you should compile with all warnings on?
pavel_lishin 16y ago
> As I had virtually no understanding of the TCP code, I liberally sprinkled it with printf()s And people say it's a stupid way to debug!
- SwellJoe 16y ago
  What people say that?
  - pavel_lishin 16y ago
    Pick any "how do you debug?" submission anywhere, and you'll see a lot of people claiming that using printf, etc, is retarded in the age of good debuggers. Maybe they're just a noisy minority.
    - SoftwareMaven 16y ago
      Using printf to debug when you could use a good debugger is...well, I wouldn't say stupid, just highly unproductive. The problem is there are a lot of problems that aren't debugger friendly, especially if you are new to a particular domain. The kernel, timing-related problems, remote systems, production systems (you have intelligent logging, right?), etc., all have extremely valid reasons for using printf debugging.
      - kahawe 16y ago
        One thing I am missing or haven't found in some of the debuggers I have used (mostly Java) is the feature to just print out the code execution and return values for a certain part of or the whole code. Those prints or printfs are great to get a quick overview of what's going on, if you ask me... instead of stepping through the whole thing.
    - branden 16y ago
      printf debugging is too simple and intuitive to justify an entire blog post. ;)

546 points by Sec 16y ago

rboyd 16y ago

The only reply this PR got, was from Bruce Evans who critiqued my use of a simple (long) cast, which appears to have derailed this PR, sticking it in the usual never getting fixed limbo where unfortunately most of my PR's appear to end up. Looks to me like Bruce gave you some valuable advice. You spent more time complaining about the handling of your PR and documenting the issue on your blog than it would have taken you to fix your patch.

direxorg 16y ago

In 2002 we did custom patch for an energy company which had hundreds of outdated remote RS232 terminals hooked up via wireless links to the central station for control and monitoring. Their goal was to encrypt transmitted messages so it will not be intercepted and messed with during wireless transmission. Solution was Linux boxes on both sides that encrypts communication using OpenSSL... The problem was the terminal do not want to talk to Linux over crossover Ethernet because of.... you guessed... bug in TCP... To solve that we had to make patch for Linux kernel. and let me tell you that code in 2.4 kernel was very ugly with extremely funny comments :-) My companion since than developing drivers and "he feels that he is doing something important rather than boring UI". but all he is doing is mostly his own projects and drivers since updating open source IS a pain in the neck. I guess problem in collaborative work is the reason why people do open source vs something that have to be supported. What do you think?

pilom 16y ago

This is true hacking news! Discusses a possible new bug in TCP, teaches how TCP works, has links to useful and relevant books on the subject, AND includes remarks about how difficult it is for a newbie to actually make changes to open source software and not get yelled at. I love it!

rwmj 16y ago
.. and comes from a cool hackerish domain (42.org)
mrspeaker 16y ago
I agree - but it's funny that there's only a handful of comments. You just can't have an uninformed rant with such technical correctness (the best kind of correctness)!

feintruled 16y ago

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!

stcredzero 16y ago
I know of one commercial Smalltalk UI bug that persisted 12 years -- being reported all the while. To be fair, it was a very tricky low-level race condition, very hard to reproduce, though very serious. (Unhandled exception in the bowels of the UI library. Boom! Application goes down.) Still, the attitude of the vendor was just unbelievable from the POV of the customer. After dozens of reports, hundreds of messages, numerous pieces of documentation, it still took 12 years for engineers to even start thinking it was something besides user error -- even though multiple customers were reporting it. (I know because I worked for 3 of them!) There is a huge perceptual wall there. I know because I used to work for the vendor. I know how apparent this bug is at a production shop and how opaque it appears from inside the vendor's camp. (And despite my being from inside, I still got the "user error" chant!) EDIT: Oh, and I know of another UI bug that's been in their system for about 8 years. It's a Smalltalk newbie classic -- shoving non-identity keys into an IdentityDictionary. I could describe what it is to a Smalltalker in 2 sentences, and they could then find it and fix it. This vendor seems to have the same attitude about this bug, so I've already learned my lesson. They can keep their damn bug!
- cletus 16y ago
  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 incredibly frustrating experience.
  - sedachv 16y ago

runjake 16y ago

The response to the bug report was by Bruce Evans, who is listed as the "Style Police-Meister" for FreeBSD. Apparently his job is to enforce standards & code style. Seems like he was doing his job. http://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/people.html http://www.freebsd.org/doc/en_US.ISO8859-1/articles/committe... Edit: edited for clarity. Thanks, pinko!

pinko 16y ago
I believe the comment above was meant as a response to the "The response to the bug report looks depressingly typical" comment elsewhere in this thread. It took me a minute to sort that out ("hmm, why is he referencing Bruce Evans?"), so I thought I'd mention it for anyone else trying to follow.
deleted 16y ago
[deleted]

ig1 16y ago

I only had a quick skim through the article (need to be off to the London HN meetup shortly!), but couldn't this be used to mount a DOS attack sucking up the number of available sockets on a server?

pmjordan 16y ago
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).
- zwp 16y ago
  > if you could trick the server (64-bit FreeBSD) into connecting to sockets Proxies, SMTP gateways, FTP servers (active mode), ...
  - pmjordan 16y ago
    Proxies usually have connection limits. FTP might work.
  - delinka 16y ago
    "...on 32-bit [systems]" is the operative part of his statement. I'm pretty sure 'tricking' a client into opening connections to a server is trivial regardless of TCP bugs.

HenryR 16y ago

Is Stevens vol. 2 in the public domain now? If not, that's pretty poor form, linking to a scanned pdf of the book.

uxp 16y ago
No, actually it's not public domain. The 19th edition was printed and released in 2005. Pearson looks like it actively tries to protect it's copyrights to the series as well: http://www.foo.be/docs/TCPIP-Illustrated-1/ http://www.foo.be/docs/TCPIP-Illustrated-1/
doki_pen 16y ago
Wouldn't that be fair use? Do you have issue with the content being posted, or the fact that it's scanned?
- estel 16y ago
  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.
  - btilly 16y ago
    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 http://www.chillingeffects.org/linking/faq.cgi#QID152 for more.
    - estel 16y ago
      That's true, but the original point was 'poor form', which this likely falls under also.
    - ZoFreX 16y ago
      It may not be illegal, but it's incredibly poor form.

barrkel 16y ago

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

__david__ 16y ago
I wouldn't say they are evil. In fact, both signed and unsigned are the same--the only difference is the "pain point" (the place where you subtract 1 and your world breaks) is in a different spot. 0 for unsigned, INT_MIN for signed. Both are perfectly fine as long as you stay in their good range.
- barrkel 16y ago
  Yes - but 0 is much closer to the range most people put in their integer values than INT_MIN. The cliff you fall of off is far closer with unsigned integers.
1amzave 16y ago
Care to elaborate? Unlike signed ones, unsigned integral types at least have well-defined behavior on shifting and overflow. (I'm speaking in terms C specifically here, of course.)
- cpeterso 16y ago
  Signed ints are easier to range check at runtime. Given an unsigned int, it's difficult to detect an invalid result from combining or comparing signed and unsigned ints. Google's C++ Style Guide discourages using unsigned ints to represent nonnegative numbers (like sizes or counts). It recommends using runtime checks or assertions instead. http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Integer_Types http://google-styleguide.googlecode.com/svn/trunk/cppguide.x... Unsigned ints make sense for bit twiddling, but you should probably use a fixed-size uint32_t or uint64_t to ensure the results are consistent across various architectures.
  - seabee 16y ago
    > it's difficult to detect an invalid result from combining or comparing signed and unsigned ints Isn't this why you should compile with all warnings on?

pavel_lishin 16y ago

> As I had virtually no understanding of the TCP code, I liberally sprinkled it with printf()s And people say it's a stupid way to debug!

SwellJoe 16y ago
What people say that?
- pavel_lishin 16y ago
  Pick any "how do you debug?" submission anywhere, and you'll see a lot of people claiming that using printf, etc, is retarded in the age of good debuggers. Maybe they're just a noisy minority.
  - SoftwareMaven 16y ago
    Using printf to debug when you could use a good debugger is...well, I wouldn't say stupid, just highly unproductive. The problem is there are a lot of problems that aren't debugger friendly, especially if you are new to a particular domain. The kernel, timing-related problems, remote systems, production systems (you have intelligent logging, right?), etc., all have extremely valid reasons for using printf debugging.
    - kahawe 16y ago
      One thing I am missing or haven't found in some of the debuggers I have used (mostly Java) is the feature to just print out the code execution and return values for a certain part of or the whole code. Those prints or printfs are great to get a quick overview of what's going on, if you ask me... instead of stepping through the whole thing.
  - branden 16y ago
    printf debugging is too simple and intuitive to justify an entire blog post. ;)