Skip to content

Commit fd6149d

Browse files
ij1davem330
authored andcommitted
tcp: Restore ordering of TCP options for the sake of inter-operability
This is not our bug! Sadly some devices cannot cope with the change of TCP option ordering which was a result of the recent rewrite of the option code (not that there was some particular reason steming from the rewrite for the reordering) though any ordering of TCP options is perfectly legal. Thus we restore the original ordering to allow interoperability with/through such broken devices and add some warning about this trap. Since the reordering just happened without any particular reason, this change shouldn't cost us anything. There are already couple of known failure reports (within close proximity of the last release), so the problem might be more wide-spread than a single device. And other reports which may be due to the same problem though the symptoms were less obvious. Analysis of one of the case revealed (with very high probability) that sack capability cannot be negotiated as the first option (SYN never got a response). Signed-off-by: Ilpo Järvinen <[email protected]> Reported-by: Aldo Maggi <[email protected]> Tested-by: Aldo Maggi <[email protected]> Signed-off-by: David S. Miller <[email protected]>
1 parent b63365a commit fd6149d

File tree

1 file changed

+17
-6
lines changed

1 file changed

+17
-6
lines changed

net/ipv4/tcp_output.c

Lines changed: 17 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -362,6 +362,17 @@ struct tcp_out_options {
362362
__u32 tsval, tsecr; /* need to include OPTION_TS */
363363
};
364364

365+
/* Beware: Something in the Internet is very sensitive to the ordering of
366+
* TCP options, we learned this through the hard way, so be careful here.
367+
* Luckily we can at least blame others for their non-compliance but from
368+
* inter-operatibility perspective it seems that we're somewhat stuck with
369+
* the ordering which we have been using if we want to keep working with
370+
* those broken things (not that it currently hurts anybody as there isn't
371+
* particular reason why the ordering would need to be changed).
372+
*
373+
* At least SACK_PERM as the first option is known to lead to a disaster
374+
* (but it may well be that other scenarios fail similarly).
375+
*/
365376
static void tcp_options_write(__be32 *ptr, struct tcp_sock *tp,
366377
const struct tcp_out_options *opts,
367378
__u8 **md5_hash) {
@@ -376,6 +387,12 @@ static void tcp_options_write(__be32 *ptr, struct tcp_sock *tp,
376387
*md5_hash = NULL;
377388
}
378389

390+
if (unlikely(opts->mss)) {
391+
*ptr++ = htonl((TCPOPT_MSS << 24) |
392+
(TCPOLEN_MSS << 16) |
393+
opts->mss);
394+
}
395+
379396
if (likely(OPTION_TS & opts->options)) {
380397
if (unlikely(OPTION_SACK_ADVERTISE & opts->options)) {
381398
*ptr++ = htonl((TCPOPT_SACK_PERM << 24) |
@@ -392,12 +409,6 @@ static void tcp_options_write(__be32 *ptr, struct tcp_sock *tp,
392409
*ptr++ = htonl(opts->tsecr);
393410
}
394411

395-
if (unlikely(opts->mss)) {
396-
*ptr++ = htonl((TCPOPT_MSS << 24) |
397-
(TCPOLEN_MSS << 16) |
398-
opts->mss);
399-
}
400-
401412
if (unlikely(OPTION_SACK_ADVERTISE & opts->options &&
402413
!(OPTION_TS & opts->options))) {
403414
*ptr++ = htonl((TCPOPT_NOP << 24) |

0 commit comments

Comments
 (0)