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 y
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=linu
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 lo
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
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 ma
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
va
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
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 s
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 origi
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, r
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.
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 onl
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 numb
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 addres
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
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 conn
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
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 conn
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
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
> > incom
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
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
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
23 matches
Mail list logo
