Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[PATCH\,RFC\]\s+explicit\s+connection\s+confirmation\s*$/: 28 ]

Total 28 documents matching your query.

1. [PATCH,RFC] explicit connection confirmation (score: 1)
Author: ger <shemminger@xxxxxxxx>
Date: Thu, 14 Aug 2003 09:11:56 -0400
atch does?!?! -- Pekka Savola "You each name yourselves king, yet the
/archives/netdev/2003-08/msg00399.html (21,795 bytes)

2. Re: [PATCH,RFC] explicit connection confirmation (score: 1)
Author: shmulik.hen@xxxxxxxxx>
Date: Mon, 25 Aug 2003 13:09:03 +0200
t4/drivers/net/ni5010.c 2003-07-15 17:22:18.000000000 +0530 +++ linux
/archives/netdev/2003-08/msg00795.html (8,675 bytes)

3. t 2.4.20-rc1 (score: 1)
Author: xxx>
Date: Thu, 7 Nov 2002 04:32:08 -0500
(please CC on replies, I am not on this list) Hi, This patch gives userland the ability to decide whether to react with an incoming TCP SYN with a SYN-ACK or a RST. It was hacked up after Linux Kongr
/archives/netdev/2002-11/msg00053.html (21,834 bytes)

4. outing (score: 1)
Author: xx>
Date: Thu, 7 Nov 2002 12:27:33 +0100
And reading, like a webserver would do? I think this approach smells, btw - doesn't this mean that processes will now be woken up on receiving a SYN instead of after completion of the handshake? Woul
/archives/netdev/2002-11/msg00054.html (9,748 bytes)

5. on (score: 1)
Author: tenh@xxxxxxx>
Date: Thu, 7 Nov 2002 07:09:56 -0500
Will do nothing, but this can easily be changed. I remind you of the fact that this option has to be explicitly enabled on a listening socket, so that apps have to be adapted to use the new interface
/archives/netdev/2002-11/msg00055.html (9,671 bytes)

6. 20-rc1 (score: 1)
Author: adi@xxxxxxxxxx>
Date: Thu, 7 Nov 2002 08:36:28 -0500 (EST)
Could you not have used netfilter for this? You have the app sending controls to add netfilter policies and delete them when not needed. cheers, jamal
/archives/netdev/2002-11/msg00059.html (8,452 bytes)

7. : [PATCH,RFC] explicit connection confirmation (score: 1)
Author: "Jacky Hsiao" <jacky@xxxxxxxxxxxxxxxxx>
Date: Thu, 7 Nov 2002 14:49:18 +0100
I like having this ability - I dislike offering it to an unsuspecting userspace. Yes, but in your setup, a spoofable SYN packet will spawn a process for many daemons, unless they are modified to firs
/archives/netdev/2002-11/msg00061.html (10,140 bytes)

8. st (score: 1)
Author: xxxxxxxxxxxx>
Date: Thu, 7 Nov 2002 09:30:02 -0500
Userspace needs to turn on the option first, so your 'unsuspecting' does not apply. Again, if the app decides to turn on TCP_CONFIRM_CONNECT, then it's up to the app to deal with it properly. There a
/archives/netdev/2002-11/msg00062.html (10,197 bytes)

9. on (score: 1)
Author: xx>
Date: Thu, 7 Nov 2002 10:27:58 -0500
netfilter, yeah, sure, 'could have', but please. 'Make it a netfilter module' is generally what people say when they are confronted with a feature they don't like. There was a thread about this in p
/archives/netdev/2002-11/msg00063.html (10,655 bytes)

10. on (score: 1)
Author: xx>
Date: Thu, 7 Nov 2002 17:24:24 +0100
Ah ok, I thought 'TCP_CONFIRM_CONNECT' was a TCP connection state like SYN_RECV. Exactly. Ok, cool. Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://lartc.org Linux A
/archives/netdev/2002-11/msg00064.html (10,305 bytes)

11. IPv6 development plan ? (score: 1)
Author: g@xxxxxxxxxx>
Date: Fri, 8 Nov 2002 06:22:00 -0500 (EST)
apology if i sounded like one of those adolescent netfilter dangerous fools who show up with "mama, look what i can do with a packet now that ive read netfilter docs" My angle was to avoid being intr
/archives/netdev/2002-11/msg00073.html (9,219 bytes)

12. mation (score: 1)
Author: adi@xxxxxxxxxx>
Date: Fri, 8 Nov 2002 12:52:05 +0100
This came up a long time ago on bugtraq in a discussion how to easily prevent certain IP addresses from DoSsing your TCP daemon. Right now, userspace is always forced to complete the threeway handsha
/archives/netdev/2002-11/msg00075.html (10,521 bytes)

13. c1 (score: 1)
Author: i@xxxxxxxxxx>
Date: Fri, 8 Nov 2002 06:56:03 -0500
it would also be useful for transparent proxying. presently all connections diverted to a proxy are immediately accepted, regardless of whether the second connection (proxy->real destination) succeed
/archives/netdev/2002-11/msg00076.html (10,672 bytes)

14. mation (score: 1)
Author: x>
Date: Fri, 8 Nov 2002 13:28:03 -0500
No, you don't sound such, sorry for reacting the way i did. Sorry but I don't like fish nor armani suits :-) My specific application is a proxy application that replaces the in-kernel IP masquerading
/archives/netdev/2002-11/msg00078.html (10,354 bytes)

15. [PATCH,RFC] explicit connection confirmation (score: 1)
Author: Lennert Buytenhek <buytenh@xxxxxxx>
Date: Thu, 14 Aug 2003 09:11:56 -0400
Hi, Below is the original email I sent to netdev about nine months ago announcing selective connection acceptance support for TCP sockets. I have forward-ported the 2.4.18 patch to 2.6.0-test2, inclu
/archives/netdev/2003-08/msg01371.html (21,911 bytes)

16. Re: [PATCH,RFC] explicit connection confirmation (score: 1)
Author: Harald Welte <laforge@xxxxxxxxxxxx>
Date: Mon, 25 Aug 2003 13:09:03 +0200
That is great! Thanks for not forgetting about this issue. I think this feature would really be great to develop _really_ transparent proxies. I'm not a core networking guy, but it looks fine to me.
/archives/netdev/2003-08/msg01767.html (8,808 bytes)

17. [PATCH,RFC] explicit connection confirmation (score: 1)
Author: Lennert Buytenhek <buytenh@xxxxxxx>
Date: Thu, 7 Nov 2002 04:32:08 -0500
(please CC on replies, I am not on this list) Hi, This patch gives userland the ability to decide whether to react with an incoming TCP SYN with a SYN-ACK or a RST. It was hacked up after Linux Kongr
/archives/netdev/2002-11/msg00271.html (21,834 bytes)

18. Re: [PATCH,RFC] explicit connection confirmation (score: 1)
Author: bert hubert <ahu@xxxxxxx>
Date: Thu, 7 Nov 2002 12:27:33 +0100
And reading, like a webserver would do? I think this approach smells, btw - doesn't this mean that processes will now be woken up on receiving a SYN instead of after completion of the handshake? Woul
/archives/netdev/2002-11/msg00272.html (9,838 bytes)

19. Re: [PATCH,RFC] explicit connection confirmation (score: 1)
Author: Lennert Buytenhek <buytenh@xxxxxxx>
Date: Thu, 7 Nov 2002 07:09:56 -0500
Will do nothing, but this can easily be changed. I remind you of the fact that this option has to be explicitly enabled on a listening socket, so that apps have to be adapted to use the new interface
/archives/netdev/2002-11/msg00273.html (9,761 bytes)

20. Re: [PATCH,RFC] explicit connection confirmation (score: 1)
Author: jamal <hadi@xxxxxxxxxx>
Date: Thu, 7 Nov 2002 08:36:28 -0500 (EST)
Could you not have used netfilter for this? You have the app sending controls to add netfilter policies and delete them when not needed. cheers, jamal
/archives/netdev/2002-11/msg00277.html (8,482 bytes)


This search system is powered by Namazu