RE: Suppress / delay SYN-ACK
On Tuesday, October 17, 2006 2:54 PM, Eric Dumazet wrote: > > Well, did you solve Lennert problem if the final (third packet of > three packet TCP establishment handshake) packet is missing ? It > seems no timer will fire and tell you the socket is not usable... > Sorry, but I don't know what you exactly mean with this problem. On my first short tests, when I send the SYN-ACK with the ioctl and don't get an ACK, the first read on the socket returns "-1". So I can see that the connection is not established and usable. Martin - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Suppress / delay SYN-ACK
On Tuesday 17 October 2006 14:04, Martin Schiller wrote: > On Monday, October 16, 2006 9:02 AM, Lennert Buytenhek wrote: > > I wrote something like this a couple of years ago: > > > > http://marc.theaimsgroup.com/?l=linux-netdev&m=103666165629419&w=2 > > http://marc.theaimsgroup.com/?l=linux-netdev&m=106089519611631&w=2 > > > > There wasn't a whole lot of external interest, and my need for it > > disappeared, so I never really finished it, and there's a couple of > > unfixed bugs, > > Lennert's patch does nearly exactly the way how I tried to do it earlier by > myself and after porting the patch to kernel 2.6.15.4 and 2.6.11.12, which > I am currently using, it works great. > > The only change I've made is that I don't want to send the SYN-ACK only > with the first write() on the socket, because in my application the > requesting client is also the one who starts sending data. So I introduced > an ioctl() which simply runs tcp_confirm() to send the SYN-ACK. Well, did you solve Lennert problem if the final (third packet of three packet TCP establishment handshake) packet is missing ? It seems no timer will fire and tell you the socket is not usable... Eric - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Suppress / delay SYN-ACK
On Monday, October 16, 2006 9:02 AM, Lennert Buytenhek wrote: > > I wrote something like this a couple of years ago: > > http://marc.theaimsgroup.com/?l=linux-netdev&m=103666165629419&w=2 > http://marc.theaimsgroup.com/?l=linux-netdev&m=106089519611631&w=2 > > There wasn't a whole lot of external interest, and my need for it > disappeared, so I never really finished it, and there's a couple of > unfixed bugs, > Lennert's patch does nearly exactly the way how I tried to do it earlier by myself and after porting the patch to kernel 2.6.15.4 and 2.6.11.12, which I am currently using, it works great. The only change I've made is that I don't want to send the SYN-ACK only with the first write() on the socket, because in my application the requesting client is also the one who starts sending data. So I introduced an ioctl() which simply runs tcp_confirm() to send the SYN-ACK. So... Thanks a lot to everyone who gave me hints and tips to solve my problem. Martin - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Suppress / delay SYN-ACK
On Thu, Oct 12, 2006 at 10:08:53AM +0200, Martin Schiller wrote: > I'm searching for a solution to suppress / delay the SYN-ACK packet of a > listening server (-application) until he has decided (e.g. analysed the > requesting ip-address or checked if the corresponding other end of a > connection is available) if he wants to accept the connect request of the > client. If not, it should be possible to reject the connect request. I wrote something like this a couple of years ago: http://marc.theaimsgroup.com/?l=linux-netdev&m=103666165629419&w=2 http://marc.theaimsgroup.com/?l=linux-netdev&m=106089519611631&w=2 There wasn't a whole lot of external interest, and my need for it disappeared, so I never really finished it, and there's a couple of unfixed bugs, cheers, Lennert - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Suppress / delay SYN-ACK
On Friday, October 13, 2006 10:14 PM, Eric Dumazet wrote: > > Martin, I played with libnetfilter_queue > (http://www.netfilter.org/projects/libnetfilter_queue/index.html) > > With this single iptables rules, I was able to do what you want : > transmit the SYN message to a user application, that may DROP this > packet or let it pass normal TCP stack. > > iptables -A INPUT -p tcp --dport 333 --syn -j QUEUE > > Then hack nfqnl_test.c to meet your needs (see nfq_set_verdict(), > nfq_get_payload()) > > Be prepared to receive the 'same SYN' several time if your X.25 call > attempt is too long. > > (You have to be root unfortunatly) > > Eric Thanks, this sounds very interesting. I will have a closer look at that. Martin - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Suppress / delay SYN-ACK
DATA payload could be included in the SYN packet. TCP specs allow this AFAIK. Yes, but it isn't supposed to be delivered until the 3-way handshake is complete right? Are you speaking of 20 years old BSD API ? :) Nope - the bits in the RFCs about data not being delivered until the ISN's are validated. I may have some of the timing a bit wrong though. rick jones - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Suppress / delay SYN-ACK
Rick Jones a écrit : Eric Dumazet wrote: Rick Jones a écrit : More to the point, on what basis would the application be rejecting a connection request based solely on the SYN? True, it isn't like there would suddenly be any call user data as in XTI/TLI. DATA payload could be included in the SYN packet. TCP specs allow this AFAIK. Yes, but it isn't supposed to be delivered until the 3-way handshake is complete right? Are you speaking of 20 years old BSD API ? :) Martin, I played with libnetfilter_queue (http://www.netfilter.org/projects/libnetfilter_queue/index.html) With this single iptables rules, I was able to do what you want : transmit the SYN message to a user application, that may DROP this packet or let it pass normal TCP stack. iptables -A INPUT -p tcp --dport 333 --syn -j QUEUE Then hack nfqnl_test.c to meet your needs (see nfq_set_verdict(), nfq_get_payload()) Be prepared to receive the 'same SYN' several time if your X.25 call attempt is too long. (You have to be root unfortunatly) Eric - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Suppress / delay SYN-ACK
Eric Dumazet wrote: Rick Jones a écrit : More to the point, on what basis would the application be rejecting a connection request based solely on the SYN? True, it isn't like there would suddenly be any call user data as in XTI/TLI. DATA payload could be included in the SYN packet. TCP specs allow this AFAIK. Yes, but it isn't supposed to be delivered until the 3-way handshake is complete right? rick jones - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Suppress / delay SYN-ACK
On Friday, October 13, 2006 7:42 AM, Stephen J. Bevan wrote: > Say you are writing a transparent proxy i.e. when a TCP connection is > made through the box, rather than forwarding the TCP SYN, it is > delivered locally where it accepted and then the proxy makes a > separate TCP connection to original IP address. Thus all traffic > flows through a user-space proxy that can cache, log, virus scan, ... > etc. the traffic. Say also that the proxy is for a protocol that can > mediate peer<->peer connections via a server (e.g. most IM > protocols). Furher still assume that the client has the property > that if while trying to establish a peer<->peer connection it will > back off and use the server if it does not manage to establish the > peer<->peer TCP connection but if it does establish the connection > then it will not back off to use the server. Thus if a client is > behind the transparent proxy the proxy terminates the TCP connection > locally and at that point the client thinks it has connected to the > peer even though the proxy has yet to establish a connection to the > peer. > > Should the proxy fail to do so all it can do is drop the > client<->proxy connection at which point the client does not connect > via the server and the user of the client is not happy since if the > proxy wasn't there everything would have worked just fine. So, if > the proxy could delay the SYN/ACK until it has determined whether it > can really connect to the IP address in the SYN, then it can decide > whether to SYN/ACK or just not respond. > > Of course, the much simpler solution is to fix the client program so > that it will still back off to the server even if it does manage to > make a TCP connection. However, fixing other people's software is > easier said than done. So if you are trying to $ell a tranparent > proxy solution, you need to handle it somehow. Delayed SYN/ACK is > one such way, though not necessarily the best way. - > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to [EMAIL PROTECTED] More majordomo > info at http://vger.kernel.org/majordomo-info.html That's nearly exactly what our situation is: The machine on which the SYN-ACK-feature should be implemented is a TCP-to-X.25 Gateway. There are really stupid TCP terminals out there which connects to the Gateway and simply start sending their data after the connection between them and the Gateway is established. The Gateway otherwise has to check its internal routing-table, which X.25 Number should be called for the requesting TCP terminal and establish this X.25 connection. And now here is the point: If, why ever, the X.25 connection can't be established, the TCP-connection to the terminal has to be closed, or even better: NOT been established at all, so that the terminal can't send any data. So if you ask me, how often the connections should be rejected, i have to say: "Hopefully never", but so long as this stupid terminals will be very confused if the connection is firstly established and than suddenly closed, I think I can't resign this feature. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Suppress / delay SYN-ACK
Caitlin Bestler writes: > More to the point, on what basis would the application be rejecting a > connection request based solely on the SYN? Perhaps not the reason that Martin is interested in but ... Say you are writing a transparent proxy i.e. when a TCP connection is made through the box, rather than forwarding the TCP SYN, it is delivered locally where it accepted and then the proxy makes a separate TCP connection to original IP address. Thus all traffic flows through a user-space proxy that can cache, log, virus scan, ... etc. the traffic. Say also that the proxy is for a protocol that can mediate peer<->peer connections via a server (e.g. most IM protocols). Furher still assume that the client has the property that if while trying to establish a peer<->peer connection it will back off and use the server if it does not manage to establish the peer<->peer TCP connection but if it does establish the connection then it will not back off to use the server. Thus if a client is behind the transparent proxy the proxy terminates the TCP connection locally and at that point the client thinks it has connected to the peer even though the proxy has yet to establish a connection to the peer. Should the proxy fail to do so all it can do is drop the client<->proxy connection at which point the client does not connect via the server and the user of the client is not happy since if the proxy wasn't there everything would have worked just fine. So, if the proxy could delay the SYN/ACK until it has determined whether it can really connect to the IP address in the SYN, then it can decide whether to SYN/ACK or just not respond. Of course, the much simpler solution is to fix the client program so that it will still back off to the server even if it does manage to make a TCP connection. However, fixing other people's software is easier said than done. So if you are trying to $ell a tranparent proxy solution, you need to handle it somehow. Delayed SYN/ACK is one such way, though not necessarily the best way. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Suppress / delay SYN-ACK
Rick Jones a écrit : More to the point, on what basis would the application be rejecting a connection request based solely on the SYN? True, it isn't like there would suddenly be any call user data as in XTI/TLI. DATA payload could be included in the SYN packet. TCP specs allow this AFAIK. About iptables rules added on the fly by an application that want to protect its listen queue from random sources of 'blacklisted' peers, this has the limitation of granting sufficient rights to the user running the application. Eric - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Suppress / delay SYN-ACK
On Thu, 12 Oct 2006 15:54:49 -0700 Rick Jones <[EMAIL PROTECTED]> wrote: > > More to the point, on what basis would the application be rejecting a > > connection request based solely on the SYN? > > True, it isn't like there would suddenly be any call user data as in XTI/TLI. > > > There are only two pieces of information available: the remote IP > > address and port, and the total number of pending requests. The > > latter is already addressed through the backlog size, and netfilter > > rules can already be used to reject based on IP address. > > It would though allow an application to have an even more restricted set of > allowed IP's than was set in netfilter. Rather like allowing the application > to > set socket buffer sizes rather than relying on the system's default. > Some version of BSD sockets had this behaviour, perhaps you should use the same model. It was some socket option, I can't remember; what ever it wasn't widely adopted. Nothing says you can't just use shutdown() to force a RST on the addresses you don't want to talk to. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Suppress / delay SYN-ACK
More to the point, on what basis would the application be rejecting a connection request based solely on the SYN? True, it isn't like there would suddenly be any call user data as in XTI/TLI. There are only two pieces of information available: the remote IP address and port, and the total number of pending requests. The latter is already addressed through the backlog size, and netfilter rules can already be used to reject based on IP address. It would though allow an application to have an even more restricted set of allowed IP's than was set in netfilter. Rather like allowing the application to set socket buffer sizes rather than relying on the system's default. rick jones - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Suppress / delay SYN-ACK
On Thu, 2006-12-10 at 14:58 -0700, Caitlin Bestler wrote: > That would seem to limit the usefullness to scenarios where a given > remote IP address *might* be accepted based on total traffic load, > number of other connections from the same IP address, etc. If > *all* requests from that IP address are going to be rejected, why > not use netfilter? Netfilter or ingress tc may both work; I have a feeling that the poster needs to consult some policy+state in the application first which is more complex than what rate control or number of connections provide (DOS detection?)- in which case, theyd have to write a netfilter target. cheers, jamal - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Suppress / delay SYN-ACK
On 10/12/06, Rick Jones <[EMAIL PROTECTED]> wrote: Martin Schiller wrote: > Hi! > > I'm searching for a solution to suppress / delay the SYN-ACK packet of a > listening server (-application) until he has decided (e.g. analysed the > requesting ip-address or checked if the corresponding other end of a > connection is available) if he wants to accept the connect request of the > client. If not, it should be possible to reject the connect request. How often do you expect the incomming call to be rejected? I suspect that would have a significant effect on whether the whole thing is worthwhile. rick jones More to the point, on what basis would the application be rejecting a connection request based solely on the SYN? There are only two pieces of information available: the remote IP address and port, and the total number of pending requests. The latter is already addressed through the backlog size, and netfilter rules can already be used to reject based on IP address. That would seem to limit the usefullness to scenarios where a given remote IP address *might* be accepted based on total traffic load, number of other connections from the same IP address, etc. If *all* requests from that IP address are going to be rejected, why not use netfilter? - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Suppress / delay SYN-ACK
Martin Schiller wrote: Hi! I'm searching for a solution to suppress / delay the SYN-ACK packet of a listening server (-application) until he has decided (e.g. analysed the requesting ip-address or checked if the corresponding other end of a connection is available) if he wants to accept the connect request of the client. If not, it should be possible to reject the connect request. How often do you expect the incomming call to be rejected? I suspect that would have a significant effect on whether the whole thing is worthwhile. rick jones - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Suppress / delay SYN-ACK
On Thu, Oct 12, 2006 at 12:39:30PM +0200, Eric Dumazet ([EMAIL PROTECTED]) wrote: > > You should break your decision into per state change transformations. > > I think it is possible with either conntrack or netlink module Samir > > Bellabes creates (Network Events Connector > > subject) or even using syncookie algo changes. > > Hum.. they are some cases where conntrack is not an option (way too expensive > if your server handle XXX.XXX concurrent tcp streams) I think any netlink related work here can not be used for any kind of high performance setup - it will be too slow to send/receive one or more messages per state change for each new connection... > > But it will drastically change your server performance... > > Sure, at least its capacity to answer to SYN packets (session establishment > should be slower, unless the thread receiving/handling SYN packets has > realtime scheduling) Maybe it will be better to create some more complex protocol which will collect data before sending netlink message, or just use a procfs file or syscall/ioctl/socket option. > Eric -- Evgeniy Polyakov - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Suppress / delay SYN-ACK
On Thursday 12 October 2006 12:31, Evgeniy Polyakov wrote: > On Thu, Oct 12, 2006 at 12:13:26PM +0200, Martin Schiller ([EMAIL PROTECTED]) wrote: > > On Thursday, October 12, 2006 10:38 AM, Eric Dumazet wrote: > > > Well, it is already possible to delay the 'third packet' of an > > > outgoing connection with a litle hack. But AFAIK not the SYNACK of > > > incoming connection. It could be cool. Maybe some new syscalls are > > > needed: > > > > > > int syn_recv(int socklisten, ...); > > > /* give to user app the SYN packet */ > > > int syn_ack(int socklisten, ...); > > > /* User app has the ability to ask kernel tcp stack to : > > > DROP this packet. > > > REJECT the attempt > > > ACCEPT the attempt (sending a SYN/ACK) */ > > > > So, when do you mean the user-space application should run this syscalls? > > After the call to listen()? > > > > Another problem with this solution might be, that I don't want to block > > the listening socket with the processing of one request, because there > > could be a lot of simultaneous requests. > > You should break your decision into per state change transformations. > I think it is possible with either conntrack or netlink module Samir > Bellabes creates (Network Events Connector > subject) or even using syncookie algo changes. Hum.. they are some cases where conntrack is not an option (way too expensive if your server handle XXX.XXX concurrent tcp streams) > > But it will drastically change your server performance... Sure, at least its capacity to answer to SYN packets (session establishment should be slower, unless the thread receiving/handling SYN packets has realtime scheduling) Eric - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Suppress / delay SYN-ACK
On Thursday 12 October 2006 12:13, Martin Schiller wrote: > On Thursday, October 12, 2006 10:38 AM, Eric Dumazet wrote: > > Well, it is already possible to delay the 'third packet' of an > > outgoing connection with a litle hack. But AFAIK not the SYNACK of > > incoming connection. It could be cool. Maybe some new syscalls are > > needed: > > > > int syn_recv(int socklisten, ...); > > /* give to user app the SYN packet */ > > int syn_ack(int socklisten, ...); > > /* User app has the ability to ask kernel tcp stack to : > > DROP this packet. > > REJECT the attempt > > ACCEPT the attempt (sending a SYN/ACK) */ > > So, when do you mean the user-space application should run this syscalls? > After the call to listen()? > Exactly like when you call accept() on a non blocking listening socket. If your application did asked to received notification of SYN packets, it should be prepared to call accept() (to be notified of fully established connections) and/or syn_recv() (to be notified of SYN packets) So when poll()/select()/epoll() tells your socklisten has available events, your application would have to call both accept() and syn_recv() in a loop to empty all awaiting events. > Another problem with this solution might be, that I don't want to block the > listening socket with the processing of one request, because there could be > a lot of simultaneous requests. Yes I can imagine. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Suppress / delay SYN-ACK
On Thu, Oct 12, 2006 at 12:13:26PM +0200, Martin Schiller ([EMAIL PROTECTED]) wrote: > On Thursday, October 12, 2006 10:38 AM, Eric Dumazet wrote: > > > > Well, it is already possible to delay the 'third packet' of an > > outgoing connection with a litle hack. But AFAIK not the SYNACK of > > incoming connection. It could be cool. Maybe some new syscalls are > > needed: > > > > int syn_recv(int socklisten, ...); > > /* give to user app the SYN packet */ > > int syn_ack(int socklisten, ...); > > /* User app has the ability to ask kernel tcp stack to : > > DROP this packet. > > REJECT the attempt > > ACCEPT the attempt (sending a SYN/ACK) */ > > > > So, when do you mean the user-space application should run this syscalls? > After the call to listen()? > > Another problem with this solution might be, that I don't want to block the > listening socket with the processing of one request, because there could be > a lot of simultaneous requests. You should break your decision into per state change transformations. I think it is possible with either conntrack or netlink module Samir Bellabes creates (Network Events Connector subject) or even using syncookie algo changes. But it will drastically change your server performance... -- Evgeniy Polyakov - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Suppress / delay SYN-ACK
On Thursday, October 12, 2006 10:38 AM, Eric Dumazet wrote: > > Well, it is already possible to delay the 'third packet' of an > outgoing connection with a litle hack. But AFAIK not the SYNACK of > incoming connection. It could be cool. Maybe some new syscalls are > needed: > > int syn_recv(int socklisten, ...); > /* give to user app the SYN packet */ > int syn_ack(int socklisten, ...); > /* User app has the ability to ask kernel tcp stack to : > DROP this packet. > REJECT the attempt > ACCEPT the attempt (sending a SYN/ACK) */ > So, when do you mean the user-space application should run this syscalls? After the call to listen()? Another problem with this solution might be, that I don't want to block the listening socket with the processing of one request, because there could be a lot of simultaneous requests. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Suppress / delay SYN-ACK
On Thursday 12 October 2006 10:08, Martin Schiller wrote: > Hi! > > I'm searching for a solution to suppress / delay the SYN-ACK packet of a > listening server (-application) until he has decided (e.g. analysed the > requesting ip-address or checked if the corresponding other end of a > connection is available) if he wants to accept the connect request of the > client. If not, it should be possible to reject the connect request. > > My idea is to add two ioctl's: > - One to set the listening socket into "delay_synack" mode. > - And one to send the synack packet, if the connection should be > accepted. > > If the "delay_synack" mode is not enabled, the connection should just work > as usual. > > I had a look at the tcp/ipv4 stack for a while and have found out, that > this three-way-handshake is already done before anything comes up to > user-space when I am doing a call to accept(). So I think it wouldn't be > possible to add this feature with "a little hack". > Well, it is already possible to delay the 'third packet' of an outgoing connection with a litle hack. But AFAIK not the SYNACK of incoming connection. It could be cool. Maybe some new syscalls are needed: int syn_recv(int socklisten, ...); /* give to user app the SYN packet */ int syn_ack(int socklisten, ...); /* User app has the ability to ask kernel tcp stack to : DROP this packet. REJECT the attempt ACCEPT the attempt (sending a SYN/ACK) */ Maybe NETLINK (netfilter) is able to meet your need. > Does anybody have any hints for me where I should start to work? > > Regards, > Martin Schiller - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
