* Re: [PATCH net-next] fib: introduce fib_alias_accessed() helper
From: David Miller @ 2010-10-21 10:11 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1287648218.6871.18.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 21 Oct 2010 10:03:38 +0200
> Perf tools session at NFWS 2010 pointed out a false sharing on struct
> fib_alias that can be avoided pretty easily, if we set FA_S_ACCESSED bit
> only if needed (ie : not already set)
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] Drivers: atm: Makefile: replace the use of <module>-objs with <module>-y
From: David Miller @ 2010-10-21 10:11 UTC (permalink / raw)
To: tdent48227; +Cc: chas, linux-kernel, netdev, linux-atm-general
In-Reply-To: <1287201209-2101-1-git-send-email-tdent48227@gmail.com>
From: Tracey Dent <tdent48227@gmail.com>
Date: Fri, 15 Oct 2010 23:53:29 -0400
> Changed <module>-objs to <module>-y in Makefile.
>
> Signed-off-by: Tracey Dent <tdent48227@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] netxen: make local function static.
From: David Miller @ 2010-10-21 10:11 UTC (permalink / raw)
To: shemminger; +Cc: amit.salecha, narender.kumar, rajesh.borundia, netdev
In-Reply-To: <20101018204010.1dc01291@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Mon, 18 Oct 2010 20:40:10 -0700
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] socket: localize functions
From: David Miller @ 2010-10-21 10:12 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20101018172729.68755c69@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Mon, 18 Oct 2010 17:27:29 -0700
> A couple of functions in socket.c are only used there and
> should be localized.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied.
^ permalink raw reply
* Re: [PATCH] bridge: make br_parse_ip_options static
From: David Miller @ 2010-10-21 10:12 UTC (permalink / raw)
To: bandan.das; +Cc: shemminger, netdev
In-Reply-To: <20101019112234.GB12005@stratus.com>
From: Bandan Das <bandan.das@stratus.com>
Date: Tue, 19 Oct 2010 07:22:34 -0400
> On 0, Stephen Hemminger <shemminger@vyatta.com> wrote:
>>
>> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>>
>> --- a/net/bridge/br_netfilter.c 2010-10-18 17:01:36.903364885 -0700
>> +++ b/net/bridge/br_netfilter.c 2010-10-18 17:01:48.106569141 -0700
>> @@ -213,7 +213,7 @@ static inline void nf_bridge_update_prot
>> * expected format
>> */
>>
>> -int br_parse_ip_options(struct sk_buff *skb)
>> +static int br_parse_ip_options(struct sk_buff *skb)
>> {
>> struct ip_options *opt;
>> struct iphdr *iph;
>>
>
> My main motivation behind not making this static was that
> there would be possibly other places in the bridge code
> (besides br_netfilter.c) where we enter the IP stack and might
> want to call this. Not sure if it's indeed the case though..
You can un-static it when the use is added.
Patch applied, thanks Stephen.
^ permalink raw reply
* [PATCH] ipv4: synchronize bind() with RTM_NEWADDR notifications
From: Timo Teräs @ 2010-10-21 10:12 UTC (permalink / raw)
To: netdev; +Cc: Timo Teräs
Otherwise we have race condition to user land:
1. process A changes IP address
2. kernel sends RTM_NEWADDR
3. process B gets notification
4. process B tries to bind() to new IP but that fails with
EADDRNOTAVAIL because FIB is not yet updated and inet_addr_type() in
inet_bind() does not recognize the IP as local
5. kernel calls inetaddr_chain notifiers which updates FIB
IPv6 side seems to handle the notifications properly: bind()
immediately after RTM_NEWADDR succeeds as expected. This is because
ipv6_chk_addr() uses inet6_addr_lst which is updated before address
notification.
Signed-off-by: Timo Teräs <timo.teras@iki.fi>
---
net/ipv4/af_inet.c | 9 +++++++++
net/ipv6/af_inet6.c | 4 +++-
2 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index 6a1100c..21200e4 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -466,6 +466,15 @@ int inet_bind(struct socket *sock, struct sockaddr *uaddr, int addr_len)
if (addr_len < sizeof(struct sockaddr_in))
goto out;
+ /* Acquire rtnl_lock to synchronize with possible simultaneous
+ * IP-address changes. This is needed because when RTM_NEWADDR
+ * is sent the new IP is not yet in FIB, but alas inet_addr_type
+ * checks the address type using FIB. Acquiring rtnl lock once
+ * makse sure that any address for which RTM_NEWADDR was sent
+ * earlier exists also in FIB. */
+ rtnl_lock();
+ rtnl_unlock();
+
chk_addr_ret = inet_addr_type(sock_net(sk), addr->sin_addr.s_addr);
/* Not specified by any standard per-se, however it breaks too
diff --git a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c
index 56b9bf2..6fc37f4 100644
--- a/net/ipv6/af_inet6.c
+++ b/net/ipv6/af_inet6.c
@@ -300,7 +300,9 @@ int inet6_bind(struct socket *sock, struct sockaddr *uaddr, int addr_len)
goto out;
}
- /* Reproduce AF_INET checks to make the bindings consitant */
+ /* Reproduce AF_INET checks to make the bindings consistent */
+ rtnl_lock();
+ rtnl_unlock();
v4addr = addr->sin6_addr.s6_addr32[3];
chk_addr_ret = inet_addr_type(net, v4addr);
if (!sysctl_ip_nonlocal_bind &&
--
1.7.1
^ permalink raw reply related
* Re: [PATCH net-next-2.6 1/5] jme: Fix PHY power-off error
From: David Miller @ 2010-10-21 10:12 UTC (permalink / raw)
To: cooldavid; +Cc: netdev, stable
In-Reply-To: <1287447044-24471-1-git-send-email-cooldavid@cooldavid.org>
All 5 patches applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] bnx2: Increase max rx ring size from 1K to 2K
From: David Miller @ 2010-10-21 10:13 UTC (permalink / raw)
To: mchan; +Cc: andy, jfeeney, netdev
In-Reply-To: <1287448254-14173-1-git-send-email-mchan@broadcom.com>
From: "Michael Chan" <mchan@broadcom.com>
Date: Mon, 18 Oct 2010 17:30:54 -0700
> A number of customers are reporting packet loss under certain workloads
> (e.g. heavy bursts of small packets) with flow control disabled. A larger
> rx ring helps to prevent these losses.
>
> No change in default rx ring size and memory consumption.
>
> Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
> Acked-by: John Feeney <jfeeney@redhat.com>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Ok, since the new limit is not the default, applied.
Thanks for the explanation Michael.
^ permalink raw reply
* Re: [PATCH net-next] sfc: make functions static
From: David Miller @ 2010-10-21 10:13 UTC (permalink / raw)
To: bhutchings; +Cc: shemminger, shodgson, linux-net-drivers, netdev
In-Reply-To: <1287421518.2252.219.camel@achroite.uk.solarflarecom.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Mon, 18 Oct 2010 18:05:18 +0100
> On Mon, 2010-10-18 at 08:27 -0700, Stephen Hemminger wrote:
>> Make local functions and variable static. Do some rearrangement
>> of the string table stuff to put it where it gets used.
>>
>> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>
> Acked-by: Ben Hutchings <bhutchings@solarflare.com>
>
> We might have to change some of these back in future, but I suppose
> there is no harm in making them static now.
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6] mlx4: make functions local and remove dead code.
From: David Miller @ 2010-10-21 10:13 UTC (permalink / raw)
To: yevgenyp; +Cc: shemminger, netdev, eli
In-Reply-To: <E113D394D7C5DB4F8FF691FA7EE9DB443CC3716F65@MTLMAIL.mtl.com>
From: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Date: Tue, 19 Oct 2010 09:37:44 +0200
>>
>> There is a whole section of code in this driver related to vlan tables
>> which is not accessed from any kernel code.
>>
>> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>>
>
> Thanks for sending this,
> There are patches under review at the moment (RDMA over Ethernet) that use this code:
> http://www.spinics.net/lists/linux-rdma/msg05512.html, which will be broken if the VLAN tables code is removed.
ok.
^ permalink raw reply
* Re: [PATCH net-next] bonding: make bond_resend_igmp_join_requests_delayed static
From: David Miller @ 2010-10-21 10:14 UTC (permalink / raw)
To: shemminger; +Cc: fubar, netdev, bonding-devel
In-Reply-To: <20101015140256.4192fd34@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Fri, 15 Oct 2010 14:02:56 -0700
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] vmxnet3: make bit twiddle routines inline
From: David Miller @ 2010-10-21 10:14 UTC (permalink / raw)
To: shemminger; +Cc: sbhatewara, pv-drivers, netdev
In-Reply-To: <20101015140620.63d0a615@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Fri, 15 Oct 2010 14:06:20 -0700
> Gcc doesn't usually handle inline across compilation units, and the
> functions don't have to be global in scope. Move the set/reset flag
> functions int the existing vmxnet3 header.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] pch_gbe: make local functions static
From: David Miller @ 2010-10-21 10:14 UTC (permalink / raw)
To: shemminger; +Cc: masa-korg, netdev
In-Reply-To: <20101015140914.01d8ef08@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Fri, 15 Oct 2010 14:09:14 -0700
> Make routines that are only used in one file static.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] bonding: make release_and_destroy static
From: David Miller @ 2010-10-21 10:15 UTC (permalink / raw)
To: shemminger; +Cc: fubar, bonding-devel, netdev
In-Reply-To: <20101015080934.6dc28388@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Fri, 15 Oct 2010 08:09:34 -0700
> Only used in main file.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] rtnetlink: remove rtnl_kill_links
From: David Miller @ 2010-10-21 10:15 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20101015081201.55eae031@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Fri, 15 Oct 2010 08:12:01 -0700
> The function rtnl_kill_links is defined but never used.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] xfrm: make xfrm_bundle_ok local
From: David Miller @ 2010-10-21 10:15 UTC (permalink / raw)
To: shemminger; +Cc: herbert, netdev
In-Reply-To: <20101015081419.79252990@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Fri, 15 Oct 2010 08:14:19 -0700
> Only used in one place.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] xfrm6: make xfrm6_tunnel_free_spi local
From: David Miller @ 2010-10-21 10:15 UTC (permalink / raw)
To: shemminger; +Cc: herbert, yoshfuji, netdev
In-Reply-To: <20101015081559.6ede35a0@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Fri, 15 Oct 2010 08:15:59 -0700
> Function only defined and used in one file.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net/nuc900: change dev_warn to dev_dbg when link down occurs
From: David Miller @ 2010-10-21 10:16 UTC (permalink / raw)
To: mcuos.com; +Cc: netdev, yachen, linux-kernel
In-Reply-To: <4CB86C87.5010207@gmail.com>
From: Wan ZongShun <mcuos.com@gmail.com>
Date: Fri, 15 Oct 2010 23:00:23 +0800
> Hi David,
>
> When I didnot connect the net cable, the warning infos are always
> showed,
> so I change the dev_warn to dev_dbg.
>
> Signed-off-by: Wan ZongShun <mcuos.com@gmail.com>
Your patch does not apply to the current tree.
^ permalink raw reply
* Re: [PATCH] net_sched: remove the unused parameter of qdisc_create_dflt()
From: David Miller @ 2010-10-21 10:16 UTC (permalink / raw)
To: hadi; +Cc: xiaosuo, shemminger, netdev, netem
In-Reply-To: <1287404425.3664.186.camel@bigi>
From: jamal <hadi@cyberus.ca>
Date: Mon, 18 Oct 2010 08:20:25 -0400
> On Sun, 2010-10-17 at 07:04 +0800, Changli Gao wrote:
>> The first parameter dev isn't in use in qdisc_create_dflt().
>
> And we can derive it from netdev_queue if ever needed in the future.
>
> Acked-by: Jamal Hadi Salim <hadi@cyberus.ca>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] smsc95xx: generate random MAC address once, not every ifup
From: David Miller @ 2010-10-21 10:17 UTC (permalink / raw)
To: bernard; +Cc: steve.glendinning, netdev, linux-omap
In-Reply-To: <20101018231639.GA15955@mersenne.largestprime.net>
From: Bernard Blackham <bernard@largestprime.net>
Date: Tue, 19 Oct 2010 10:16:39 +1100
> The smsc95xx driver currently generates a new random MAC address
> every time the interface is brought up. This makes it impossible to
> override using the standard `ifconfig hw ether` approach.
>
> Past patches tried to make the MAC address a module parameter or
> base it off the die ID, but it seems to me much simpler (and
> hopefully less controversial) to stick with the current random
> generation scheme, but allow the user to change the address.
>
> This patch does exactly that - it moves the random address
> generation from smsc95xx_reset() into smsc95xx_bind(), so that it is
> done once on module load, not on every ifup. The user can then
> override this using the standard mechanisms.
>
> Applies against 2.6.35 and linux-2.6 head.
>
> Signed-off-by: Bernard Blackham <b-omap@largestprime.net>
Applied.
^ permalink raw reply
* Re: [PATCH 0/2] bonding: checkpatch.pl cleanups in bond_3ad.c
From: David Miller @ 2010-10-21 10:17 UTC (permalink / raw)
To: bandan.das; +Cc: linux-kernel, netdev, joe, eric.dumazet
In-Reply-To: <1287296399-25142-1-git-send-email-bandan.das@stratus.com>
From: Bandan Das <bandan.das@stratus.com>
Date: Sun, 17 Oct 2010 02:19:57 -0400
> Just some cleanups based on errors/warnings reported by checkpatch.pl.
> There are still a ton of lines greater than 80 chars and I tried to fix
> a few that I came across.
Both patches applied, thank you.
^ permalink raw reply
* Re: [PATCH] ipv4: synchronize bind() with RTM_NEWADDR notifications
From: Eric Dumazet @ 2010-10-21 10:25 UTC (permalink / raw)
To: Timo Teräs; +Cc: netdev
In-Reply-To: <1287655930-16879-1-git-send-email-timo.teras@iki.fi>
Le jeudi 21 octobre 2010 à 13:12 +0300, Timo Teräs a écrit :
> Otherwise we have race condition to user land:
> 1. process A changes IP address
> 2. kernel sends RTM_NEWADDR
> 3. process B gets notification
> 4. process B tries to bind() to new IP but that fails with
> EADDRNOTAVAIL because FIB is not yet updated and inet_addr_type() in
> inet_bind() does not recognize the IP as local
> 5. kernel calls inetaddr_chain notifiers which updates FIB
>
> IPv6 side seems to handle the notifications properly: bind()
> immediately after RTM_NEWADDR succeeds as expected. This is because
> ipv6_chk_addr() uses inet6_addr_lst which is updated before address
> notification.
>
> Signed-off-by: Timo Teräs <timo.teras@iki.fi>
> ---
> net/ipv4/af_inet.c | 9 +++++++++
> net/ipv6/af_inet6.c | 4 +++-
> 2 files changed, 12 insertions(+), 1 deletions(-)
>
> diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
> index 6a1100c..21200e4 100644
> --- a/net/ipv4/af_inet.c
> +++ b/net/ipv4/af_inet.c
> @@ -466,6 +466,15 @@ int inet_bind(struct socket *sock, struct sockaddr *uaddr, int addr_len)
> if (addr_len < sizeof(struct sockaddr_in))
> goto out;
>
> + /* Acquire rtnl_lock to synchronize with possible simultaneous
> + * IP-address changes. This is needed because when RTM_NEWADDR
> + * is sent the new IP is not yet in FIB, but alas inet_addr_type
> + * checks the address type using FIB. Acquiring rtnl lock once
> + * makse sure that any address for which RTM_NEWADDR was sent
> + * earlier exists also in FIB. */
> + rtnl_lock();
> + rtnl_unlock();
You must be kidding ?
Really, this is a hot path...
^ permalink raw reply
* Re: [PATCH 9/9] tproxy: use the interface primary IP address as a default value for --on-ip
From: KOVACS Krisztian @ 2010-10-21 10:32 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: netdev, netfilter-devel, Patrick McHardy, David Miller
In-Reply-To: <alpine.LNX.2.01.1010211051560.22922@obet.zrqbmnf.qr>
Hi,
On Thu, 2010-10-21 at 11:12 +0200, Jan Engelhardt wrote:
> On Wednesday 2010-10-20 13:21, KOVACS Krisztian wrote:
> >+
> >+ if (!ipv6_addr_any(user_laddr))
> >+ return user_laddr;
> >+ laddr = NULL;
> >+
> >+ rcu_read_lock();
> >+ indev = __in6_dev_get(skb->dev);
> >+ if (indev)
> >+ list_for_each_entry(ifa, &indev->addr_list, if_list) {
> >+ /* FIXME: address selection */
>
> Per our realworld discussion, I believe we should add checks for
> some conditions (RFC 4862 section 2):
>
> 1. ignore tentative addresses
>
> if (ifa->ifa_flags & IFA_F_TENTATIVE)
> continue;
Yep, we should definitely do that.
> 2. tests for when the interface's ifa->preferred_lft == 0/deprecatedness:
>
> if (ctinfo == IP_CT_NEW/RELATED && (ifa->ifa_flags & IFA_F_DEPRECATED))
> continue;
Well, we can use the TPROXY target without conntrack so we cannot really
check if ctinfo==IP_CT_NEW/RELATED. However, we do address selection
only in case no established socket was found for the skb, so I think
it's safe to ignore addresses with IFA_F_DEPRECATED set.
Something like
if (ifa->ifa_flags & (IFA_F_TENTATIVE | IFA_F_DEPRECATED))
continue;
> 3. check for invalid addresses
> (There might be a flag like tentative..)
>
> if (ifa->valid_lft == 0)
> continue;
I didn't find such a flag and it seems that valid_lft contains the
lifetime in seconds, so I think it's not that simple. The addrconf.c
code does something like this:
unsigned long age = (jiffies - ifp->tstamp) / HZ;
if (age >= ifp->valid_lft) {
/* not valid */
}
The code also sets the deprecated flag when the preferred lifetime
expires and I think valid_lft must be less or equal to prefered_lft. If
this is the case then I think this case should be already covered by
checking for IFA_F_DEPRECATED above.
--KK
^ permalink raw reply
* Re: [PATCH] ipv4: synchronize bind() with RTM_NEWADDR notifications
From: Timo Teräs @ 2010-10-21 10:41 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1287656753.6871.46.camel@edumazet-laptop>
On 10/21/2010 01:25 PM, Eric Dumazet wrote:
> Le jeudi 21 octobre 2010 à 13:12 +0300, Timo Teräs a écrit :
>> Otherwise we have race condition to user land:
>> 1. process A changes IP address
>> 2. kernel sends RTM_NEWADDR
>> 3. process B gets notification
>> 4. process B tries to bind() to new IP but that fails with
>> EADDRNOTAVAIL because FIB is not yet updated and inet_addr_type() in
>> inet_bind() does not recognize the IP as local
>> 5. kernel calls inetaddr_chain notifiers which updates FIB
>>
>> IPv6 side seems to handle the notifications properly: bind()
>> immediately after RTM_NEWADDR succeeds as expected. This is because
>> ipv6_chk_addr() uses inet6_addr_lst which is updated before address
>> notification.
>>
>> Signed-off-by: Timo Teräs <timo.teras@iki.fi>
>> ---
>> net/ipv4/af_inet.c | 9 +++++++++
>> net/ipv6/af_inet6.c | 4 +++-
>> 2 files changed, 12 insertions(+), 1 deletions(-)
>>
>> diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
>> index 6a1100c..21200e4 100644
>> --- a/net/ipv4/af_inet.c
>> +++ b/net/ipv4/af_inet.c
>> @@ -466,6 +466,15 @@ int inet_bind(struct socket *sock, struct sockaddr *uaddr, int addr_len)
>> if (addr_len < sizeof(struct sockaddr_in))
>> goto out;
>>
>> + /* Acquire rtnl_lock to synchronize with possible simultaneous
>> + * IP-address changes. This is needed because when RTM_NEWADDR
>> + * is sent the new IP is not yet in FIB, but alas inet_addr_type
>> + * checks the address type using FIB. Acquiring rtnl lock once
>> + * makse sure that any address for which RTM_NEWADDR was sent
>> + * earlier exists also in FIB. */
>> + rtnl_lock();
>> + rtnl_unlock();
>
> You must be kidding ?
>
> Really, this is a hot path...
Is inet_bind() called from non-userland context? If yes, then this is a
bad idea. Otherwise I don't think it's that hot path...
The other idea of doing notifier calls before RTM_NEWADDR sending is
worse because it changes ordering of userland visible netlink notifications.
This looked like the easiest way out. If this is unacceptable, I guess
we are left with changing inet_addr_type() to not use FIB.
Or is there better ideas?
^ permalink raw reply
* Re: [PATCH 1/3] tproxy: kick out TIME_WAIT sockets in case a new connection comes in with the same tuple
From: Patrick McHardy @ 2010-10-21 10:45 UTC (permalink / raw)
To: KOVACS Krisztian; +Cc: netdev, netfilter-devel, David Miller
In-Reply-To: <20101020112142.6538.90622.stgit@este.odu>
Am 20.10.2010 13:21, schrieb KOVACS Krisztian:
> Without tproxy redirections an incoming SYN kicks out conflicting
> TIME_WAIT sockets, in order to handle clients that reuse ports
> within the TIME_WAIT period.
>
> The same mechanism didn't work in case TProxy is involved in finding
> the proper socket, as the time_wait processing code looked up the
> listening socket assuming that the listener addr/port matches those
> of the established connection.
>
> This is not the case with TProxy as the listener addr/port is possibly
> changed with the tproxy rule.
Applied, thanks.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox