|From:||Pavel Emelyanov <firstname.lastname@example.org>|
|To:||Linux Netdev List <email@example.com>, Tejun Heo <firstname.lastname@example.org>, Eric Dumazet <email@example.com>|
|Subject:||[RFC][PATCH 0/2] TCP connection repair|
|Date:||Wed, 29 Feb 2012 19:13:08 +0400|
|Cc:||David Miller <firstname.lastname@example.org>|
Hi. Here's another approach to transparent TCP connection hijacking (previous one was here ). This one is _much_ more straightforward and patches TCP code a little bit more. I'd like to have comments on the idea itself early, so here is the very-very basic functionality, just to demonstrate the concept. The idea briefly is -- introduce the "repair" mode of a TCP socket. In this mode any API call to the socket (bind/connect/sendmsg/etc.) does not result in packets sent over the network, but instead modifies the socket locally in an expected way. I.e., the connect() in the repair mode assigns peer's credentials to the sock and just turns one into the connected state without issuing SYN-s or whatever. The bind() call on the socket under repair forcibly binds one to the desired IP and port ignoring any (potential) local conflicts (just like if everybody else has the SO_REUSEADDR set). The sendmsg() just queues data for transmission (however, this is not implemented in this set, need more thinking on how to make it symmetrical to the receive queue), etc. The protocol sequences are also to be get/set, so a couple of another sockopts are introduced for this. I think, that it makes sense to have this ability in a form of non-obscure API, since the connection migration can be used not only by checkpoint/restore project, but also by various load balancing solutions. E.g., a server can accept the connection, read the app-level header out of the stream, take the balancing decision based on _it_ (rather than just TCP and/or IP header) and then pass the existing connection to another host. Of course, switching socket to the repair mode is only allowed for CAP_SYS_ADMIN. What do you think? With the set provided you can do only simple tricks, e.g. transparently passing a connection between echo server and telnet to another echo server task and proceed with echoing messages. Thanks, Pavel  http://lwn.net/Articles/454304/
Copyright © 2012, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds