route: Use the device mtu as the default for blackhole routes

PATCH In review Steffen Klassert 3 participants 12 messages Nov 23, 2011 – Nov 24, 2011

Subsystems (4)

Networking Network drivers IPv4/IPv6 Networking IPsec

lore

Share & tools

lore

Steffen Klassert

author maintainer

2011-11-23 12:12 UTC #0 lore raw

PATCH 1/5 route: Use the device mtu as the default for blackhole routes

As it is, we return null as the default mtu of blackhole routes. This may lead to a propagation of a bogus pmtu if the default_mtu method of a blackhole route is invoked. So return dst->dev->mtu as the default mtu instead.

Signed-off-by Steffen Klassert <[email protected]>

---
 net/ipv4/route.c |    2 +-
 net/ipv6/route.c |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

net/ipv4/route.c +1 -1

index 0c74da8..5b17bf1 100644
@@ -2757,7 +2757,7 @@ static struct dst_entry *ipv4_blackhole_dst_check(struct dst_entry *dst, u32 coo
 
 static unsigned int ipv4_blackhole_default_mtu(const struct dst_entry *dst)
 {
-	return 0;
+	return dst->dev->mtu;
 }
 
 static void ipv4_rt_blackhole_update_pmtu(struct dst_entry *dst, u32 mtu)

net/ipv6/route.c +1 -1

index 8473016..d8fbd18 100644
@@ -157,7 +157,7 @@ static struct dst_ops ip6_dst_ops_template = {
 
 static unsigned int ip6_blackhole_default_mtu(const struct dst_entry *dst)
 {
-	return 0;
+	return dst->dev->mtu;
 }
 
 static void ip6_rt_blackhole_update_pmtu(struct dst_entry *dst, u32 mtu)

Signature · 1 line

1.7.0.4

Steffen Klassert

author maintainer

2011-11-23 12:12 UTC #1 lore raw

PATCH 2/5 net: Rename the dst_opt default_mtu method to mtu

We plan to invoke the dst_opt->default_mtu() method unconditioally from dst_mtu(). So rename the method to dst_opt->mtu() to match the name with the new meaning.

Signed-off-by Steffen Klassert <[email protected]>

---
 include/net/dst.h      |    2 +-
 include/net/dst_ops.h  |    2 +-
 net/decnet/dn_route.c  |    6 +++---
 net/ipv4/route.c       |   10 +++++-----
 net/ipv6/route.c       |   10 +++++-----
 net/xfrm/xfrm_policy.c |    6 +++---
 6 files changed, 18 insertions(+), 18 deletions(-)

include/net/dst.h +1 -1

index 4fb6c43..666de31 100644
@@ -208,7 +208,7 @@ static inline u32 dst_mtu(const struct dst_entry *dst)
 	u32 mtu = dst_metric_raw(dst, RTAX_MTU);
 
 	if (!mtu)
-		mtu = dst->ops->default_mtu(dst);
+		mtu = dst->ops->mtu(dst);
 
 	return mtu;
 }

include/net/dst_ops.h +1 -1

index 9adb998..e1c2ee0 100644
@@ -17,7 +17,7 @@ struct dst_ops {
 	int			(*gc)(struct dst_ops *ops);
 	struct dst_entry *	(*check)(struct dst_entry *, __u32 cookie);
 	unsigned int		(*default_advmss)(const struct dst_entry *);
-	unsigned int		(*default_mtu)(const struct dst_entry *);
+	unsigned int		(*mtu)(const struct dst_entry *);
 	u32 *			(*cow_metrics)(struct dst_entry *, unsigned long);
 	void			(*destroy)(struct dst_entry *);
 	void			(*ifdown)(struct dst_entry *,

net/decnet/dn_route.c +3 -3

index a77d161..db48679 100644
@@ -112,7 +112,7 @@ static unsigned long dn_rt_deadline;
 static int dn_dst_gc(struct dst_ops *ops);
 static struct dst_entry *dn_dst_check(struct dst_entry *, __u32);
 static unsigned int dn_dst_default_advmss(const struct dst_entry *dst);
-static unsigned int dn_dst_default_mtu(const struct dst_entry *dst);
+static unsigned int dn_dst_mtu(const struct dst_entry *dst);
 static void dn_dst_destroy(struct dst_entry *);
 static struct dst_entry *dn_dst_negative_advice(struct dst_entry *);
 static void dn_dst_link_failure(struct sk_buff *);

@@ -135,7 +135,7 @@ static struct dst_ops dn_dst_ops = {
 	.gc =			dn_dst_gc,
 	.check =		dn_dst_check,
 	.default_advmss =	dn_dst_default_advmss,
-	.default_mtu =		dn_dst_default_mtu,
+	.mtu =			dn_dst_mtu,
 	.cow_metrics =		dst_cow_metrics_generic,
 	.destroy =		dn_dst_destroy,
 	.negative_advice =	dn_dst_negative_advice,

@@ -825,7 +825,7 @@ static unsigned int dn_dst_default_advmss(const struct dst_entry *dst)
 	return dn_mss_from_pmtu(dst->dev, dst_mtu(dst));
 }
 
-static unsigned int dn_dst_default_mtu(const struct dst_entry *dst)
+static unsigned int dn_dst_mtu(const struct dst_entry *dst)
 {
 	return dst->dev->mtu;
 }

net/ipv4/route.c +5 -5

index 5b17bf1..f1ac3ef 100644
@@ -138,7 +138,7 @@ static int rt_chain_length_max __read_mostly	= 20;
 
 static struct dst_entry *ipv4_dst_check(struct dst_entry *dst, u32 cookie);
 static unsigned int	 ipv4_default_advmss(const struct dst_entry *dst);
-static unsigned int	 ipv4_default_mtu(const struct dst_entry *dst);
+static unsigned int	 ipv4_mtu(const struct dst_entry *dst);
 static void		 ipv4_dst_destroy(struct dst_entry *dst);
 static struct dst_entry *ipv4_negative_advice(struct dst_entry *dst);
 static void		 ipv4_link_failure(struct sk_buff *skb);

@@ -193,7 +193,7 @@ static struct dst_ops ipv4_dst_ops = {
 	.gc =			rt_garbage_collect,
 	.check =		ipv4_dst_check,
 	.default_advmss =	ipv4_default_advmss,
-	.default_mtu =		ipv4_default_mtu,
+	.mtu =			ipv4_mtu,
 	.cow_metrics =		ipv4_cow_metrics,
 	.destroy =		ipv4_dst_destroy,
 	.ifdown =		ipv4_dst_ifdown,

@@ -1814,7 +1814,7 @@ static unsigned int ipv4_default_advmss(const struct dst_entry *dst)
 	return advmss;
 }
 
-static unsigned int ipv4_default_mtu(const struct dst_entry *dst)
+static unsigned int ipv4_mtu(const struct dst_entry *dst)
 {
 	unsigned int mtu = dst->dev->mtu;

@@ -2755,7 +2755,7 @@ static struct dst_entry *ipv4_blackhole_dst_check(struct dst_entry *dst, u32 coo
 	return NULL;
 }
 
-static unsigned int ipv4_blackhole_default_mtu(const struct dst_entry *dst)
+static unsigned int ipv4_blackhole_mtu(const struct dst_entry *dst)
 {
 	return dst->dev->mtu;
 }

@@ -2775,7 +2775,7 @@ static struct dst_ops ipv4_dst_blackhole_ops = {
 	.protocol		=	cpu_to_be16(ETH_P_IP),
 	.destroy		=	ipv4_dst_destroy,
 	.check			=	ipv4_blackhole_dst_check,
-	.default_mtu		=	ipv4_blackhole_default_mtu,
+	.mtu			=	ipv4_blackhole_mtu,
 	.default_advmss		=	ipv4_default_advmss,
 	.update_pmtu		=	ipv4_rt_blackhole_update_pmtu,
 	.cow_metrics		=	ipv4_rt_blackhole_cow_metrics,

net/ipv6/route.c +5 -5

index d8fbd18..76645d7 100644
@@ -77,7 +77,7 @@ static struct rt6_info *ip6_rt_copy(const struct rt6_info *ort,
 				    const struct in6_addr *dest);
 static struct dst_entry	*ip6_dst_check(struct dst_entry *dst, u32 cookie);
 static unsigned int	 ip6_default_advmss(const struct dst_entry *dst);
-static unsigned int	 ip6_default_mtu(const struct dst_entry *dst);
+static unsigned int	 ip6_mtu(const struct dst_entry *dst);
 static struct dst_entry *ip6_negative_advice(struct dst_entry *);
 static void		ip6_dst_destroy(struct dst_entry *);
 static void		ip6_dst_ifdown(struct dst_entry *,

@@ -144,7 +144,7 @@ static struct dst_ops ip6_dst_ops_template = {
 	.gc_thresh		=	1024,
 	.check			=	ip6_dst_check,
 	.default_advmss		=	ip6_default_advmss,
-	.default_mtu		=	ip6_default_mtu,
+	.mtu			=	ip6_mtu,
 	.cow_metrics		=	ipv6_cow_metrics,
 	.destroy		=	ip6_dst_destroy,
 	.ifdown			=	ip6_dst_ifdown,

@@ -155,7 +155,7 @@ static struct dst_ops ip6_dst_ops_template = {
 	.neigh_lookup		=	ip6_neigh_lookup,
 };
 
-static unsigned int ip6_blackhole_default_mtu(const struct dst_entry *dst)
+static unsigned int ip6_blackhole_mtu(const struct dst_entry *dst)
 {
 	return dst->dev->mtu;
 }

@@ -175,7 +175,7 @@ static struct dst_ops ip6_dst_blackhole_ops = {
 	.protocol		=	cpu_to_be16(ETH_P_IPV6),
 	.destroy		=	ip6_dst_destroy,
 	.check			=	ip6_dst_check,
-	.default_mtu		=	ip6_blackhole_default_mtu,
+	.mtu			=	ip6_blackhole_mtu,
 	.default_advmss		=	ip6_default_advmss,
 	.update_pmtu		=	ip6_rt_blackhole_update_pmtu,
 	.cow_metrics		=	ip6_rt_blackhole_cow_metrics,

@@ -1041,7 +1041,7 @@ static unsigned int ip6_default_advmss(const struct dst_entry *dst)
 	return mtu;
 }
 
-static unsigned int ip6_default_mtu(const struct dst_entry *dst)
+static unsigned int ip6_mtu(const struct dst_entry *dst)
 {
 	unsigned int mtu = IPV6_MIN_MTU;
 	struct inet6_dev *idev;

net/xfrm/xfrm_policy.c +3 -3

index 552df27..b8be51e 100644
@@ -2382,7 +2382,7 @@ static unsigned int xfrm_default_advmss(const struct dst_entry *dst)
 	return dst_metric_advmss(dst->path);
 }
 
-static unsigned int xfrm_default_mtu(const struct dst_entry *dst)
+static unsigned int xfrm_mtu(const struct dst_entry *dst)
 {
 	return dst_mtu(dst->path);
 }

@@ -2411,8 +2411,8 @@ int xfrm_policy_register_afinfo(struct xfrm_policy_afinfo *afinfo)
 			dst_ops->check = xfrm_dst_check;
 		if (likely(dst_ops->default_advmss == NULL))
 			dst_ops->default_advmss = xfrm_default_advmss;
-		if (likely(dst_ops->default_mtu == NULL))
-			dst_ops->default_mtu = xfrm_default_mtu;
+		if (likely(dst_ops->mtu == NULL))
+			dst_ops->mtu = xfrm_mtu;
 		if (likely(dst_ops->negative_advice == NULL))
 			dst_ops->negative_advice = xfrm_negative_advice;
 		if (likely(dst_ops->link_failure == NULL))

Signature · 1 line

1.7.0.4

Steffen Klassert

author maintainer

2011-11-23 12:13 UTC #2 lore raw

PATCH 3/5 net: Move mtu handling down to the protocol depended handlers

In reply to Steffen Klassert

We move all mtu handling from dst_mtu() down to the protocol layer. So each protocol can implement the mtu handling in a different manner.

Signed-off-by Steffen Klassert <[email protected]>

---
 include/net/dst.h      |    7 +------
 net/decnet/dn_route.c  |    4 +++-
 net/ipv4/route.c       |   11 +++++++++--
 net/ipv6/route.c       |   11 +++++++++--
 net/xfrm/xfrm_policy.c |    4 +++-
 5 files changed, 25 insertions(+), 12 deletions(-)

include/net/dst.h +1 -6

index 666de31..6faec1a 100644
@@ -205,12 +205,7 @@ dst_feature(const struct dst_entry *dst, u32 feature)
 
 static inline u32 dst_mtu(const struct dst_entry *dst)
 {
-	u32 mtu = dst_metric_raw(dst, RTAX_MTU);
-
-	if (!mtu)
-		mtu = dst->ops->mtu(dst);
-
-	return mtu;
+	return dst->ops->mtu(dst);
 }
 
 /* RTT metrics are stored in milliseconds for user ABI, but used as jiffies */

net/decnet/dn_route.c +3 -1

index db48679..94f4ec0 100644
@@ -827,7 +827,9 @@ static unsigned int dn_dst_default_advmss(const struct dst_entry *dst)
 
 static unsigned int dn_dst_mtu(const struct dst_entry *dst)
 {
-	return dst->dev->mtu;
+	unsigned int mtu = dst_metric_raw(dst, RTAX_MTU);
+
+	return mtu ? : dst->dev->mtu;
 }
 
 static struct neighbour *dn_dst_neigh_lookup(const struct dst_entry *dst, const void *daddr)

net/ipv4/route.c +9 -2

index f1ac3ef..11d1b20 100644
@@ -1816,7 +1816,12 @@ static unsigned int ipv4_default_advmss(const struct dst_entry *dst)
 
 static unsigned int ipv4_mtu(const struct dst_entry *dst)
 {
-	unsigned int mtu = dst->dev->mtu;
+	unsigned int mtu = dst_metric_raw(dst, RTAX_MTU);
+
+	if (mtu)
+		return mtu;
+
+	mtu = dst->dev->mtu;
 
 	if (unlikely(dst_metric_locked(dst, RTAX_MTU))) {
 		const struct rtable *rt = (const struct rtable *) dst;

@@ -2757,7 +2762,9 @@ static struct dst_entry *ipv4_blackhole_dst_check(struct dst_entry *dst, u32 coo
 
 static unsigned int ipv4_blackhole_mtu(const struct dst_entry *dst)
 {
-	return dst->dev->mtu;
+	unsigned int mtu = dst_metric_raw(dst, RTAX_MTU);
+
+	return mtu ? : dst->dev->mtu;
 }
 
 static void ipv4_rt_blackhole_update_pmtu(struct dst_entry *dst, u32 mtu)

net/ipv6/route.c +9 -2

index 76645d7..3399dd3 100644
@@ -157,7 +157,9 @@ static struct dst_ops ip6_dst_ops_template = {
 
 static unsigned int ip6_blackhole_mtu(const struct dst_entry *dst)
 {
-	return dst->dev->mtu;
+	unsigned int mtu = dst_metric_raw(dst, RTAX_MTU);
+
+	return mtu ? : dst->dev->mtu;
 }
 
 static void ip6_rt_blackhole_update_pmtu(struct dst_entry *dst, u32 mtu)

@@ -1043,8 +1045,13 @@ static unsigned int ip6_default_advmss(const struct dst_entry *dst)
 
 static unsigned int ip6_mtu(const struct dst_entry *dst)
 {
-	unsigned int mtu = IPV6_MIN_MTU;
 	struct inet6_dev *idev;
+	unsigned int mtu = dst_metric_raw(dst, RTAX_MTU);
+
+	if (mtu)
+		return mtu;
+
+	mtu = IPV6_MIN_MTU;
 
 	rcu_read_lock();
 	idev = __in6_dev_get(dst->dev);

net/xfrm/xfrm_policy.c +3 -1

index b8be51e..2118d64 100644
@@ -2384,7 +2384,9 @@ static unsigned int xfrm_default_advmss(const struct dst_entry *dst)
 
 static unsigned int xfrm_mtu(const struct dst_entry *dst)
 {
-	return dst_mtu(dst->path);
+	unsigned int mtu = dst_metric_raw(dst, RTAX_MTU);
+
+	return mtu ? : dst_mtu(dst->path);
 }
 
 static struct neighbour *xfrm_neigh_lookup(const struct dst_entry *dst, const void *daddr)

Signature · 1 line

1.7.0.4

Steffen Klassert

author maintainer

2011-11-23 12:14 UTC #3 lore raw

PATCH 4/5 route: struct rtable can be const in rt_is_input_route and rt_is_output_route

In reply to Steffen Klassert

Signed-off-by Steffen Klassert <[email protected]>

---
 include/net/route.h |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

include/net/route.h +2 -2

index db7b343..91855d1 100644
@@ -71,12 +71,12 @@ struct rtable {
 	struct fib_info		*fi; /* for client ref to shared metrics */
 };
 
-static inline bool rt_is_input_route(struct rtable *rt)
+static inline bool rt_is_input_route(const struct rtable *rt)
 {
 	return rt->rt_route_iif != 0;
 }
 
-static inline bool rt_is_output_route(struct rtable *rt)
+static inline bool rt_is_output_route(const struct rtable *rt)
 {
 	return rt->rt_route_iif == 0;
 }

Signature · 1 line

1.7.0.4

Steffen Klassert

author maintainer

2011-11-23 12:14 UTC #4 lore raw

PATCH 5/5 ipv4: Don't use the cached pmtu informations for input routes

In reply to Steffen Klassert

The pmtu informations on the inetpeer are visible for output and input routes. On packet forwarding, we might propagate a learned pmtu to the sender. As we update the pmtu informations of the inetpeer on demand, the original sender of the forwarded packets might never notice when the pmtu to that inetpeer increases. So use the mtu of the outgoing device on packet forwarding instead of the pmtu to the final destination.

Signed-off-by Steffen Klassert <[email protected]>

---
 net/ipv4/route.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

net/ipv4/route.c +2 -2

index 11d1b20..fb47c8f 100644
@@ -1816,15 +1816,15 @@ static unsigned int ipv4_default_advmss(const struct dst_entry *dst)
 
 static unsigned int ipv4_mtu(const struct dst_entry *dst)
 {
+	const struct rtable *rt = (const struct rtable *) dst;
 	unsigned int mtu = dst_metric_raw(dst, RTAX_MTU);
 
-	if (mtu)
+	if (mtu && rt_is_output_route(rt))
 		return mtu;
 
 	mtu = dst->dev->mtu;
 
 	if (unlikely(dst_metric_locked(dst, RTAX_MTU))) {
-		const struct rtable *rt = (const struct rtable *) dst;
 
 		if (rt->rt_gateway != rt->rt_dst && mtu > 576)
 			mtu = 576;

Signature · 1 line

1.7.0.4

Herbert Xu

maintainer

2011-11-23 15:52 UTC #5 lore raw

Re: [PATCH 5/5] ipv4: Don't use the cached pmtu informations for input routes

Quoted 7 lines · Steffen Klassert

The pmtu informations on the inetpeer are visible for output and input routes. On packet forwarding, we might propagate a learned pmtu to the sender. As we update the pmtu informations of the inetpeer on demand, the original sender of the forwarded packets might never notice when the pmtu to that inetpeer increases. So use the mtu of the outgoing device on packet forwarding instead of the pmtu to the final destination.

I disagree. MTU increases are detected by the source retrying, so they most certainly should notice if our cached value expires.

Cheers,

Signature · 3 lines

Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

David Miller

maintainer

2011-11-23 21:49 UTC #6 lore raw

Re: [PATCH 5/5] ipv4: Don't use the cached pmtu informations for input routes

From: Herbert Xu <[email protected]>
Date: Wed, 23 Nov 2011 23:52:45 +0800

Quoted 11 lines

Quoted 7 lines · Steffen Klassert
The pmtu informations on the inetpeer are visible for output and input routes. On packet forwarding, we might propagate a learned pmtu to the sender. As we update the pmtu informations of the inetpeer on demand, the original sender of the forwarded packets might never notice when the pmtu to that inetpeer increases. So use the mtu of the outgoing device on packet forwarding instead of the pmtu to the final destination.
I disagree. MTU increases are detected by the source retrying, so they most certainly should notice if our cached value expires.

Herbert, consider the issue one level higher :-)

The issue is that "we", the forwarding entity, end up with a cached on the input route and report this cached PMTU to the sender.

This takes a while to time out.

So even if the sender "probes" he will be kept from seeing new MTU space becomming available due to our cached value.

What Steffen is doing is simply re-instating the behavior we had before the inetpeer conversion occurred. We never used learned PMTU information on input routes, only output routes stored them.

But now that input and output routes share learned information from the same set of inetpeer entries, we have to accomodate cases like this one.

Herbert Xu

maintainer

2011-11-24 00:10 UTC #7 lore raw

Re: [PATCH 5/5] ipv4: Don't use the cached pmtu informations for input routes

Quoted 5 lines · David Miller

The issue is that "we", the forwarding entity, end up with a cached on the input route and report this cached PMTU to the sender.
This takes a while to time out.

I understand. However, this could be seen as an optimisation as if somehow we as a router discovered the smaller MTU this would save everybody behind us from having to disocver it by probing until our discovery expires.

Is there a particular scenario where this breaks? I could only think of policy routing cases but that's not unique to forwarding as it also affects us as a host.

Thanks,

Signature · 3 lines

Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

David Miller

maintainer

2011-11-24 00:18 UTC #8 lore raw

Re: [PATCH 5/5] ipv4: Don't use the cached pmtu informations for input routes

From: Herbert Xu <[email protected]>
Date: Thu, 24 Nov 2011 08:10:35 +0800

Quoted 3 lines

Is there a particular scenario where this breaks? I could only think of policy routing cases but that's not unique to forwarding as it also affects us as a host.

Steffen has a specific situation.

But regardless I think the current behavior is terrible.

It means there is a propagation delay of PMTU increasing which is on the order of the number of hops between the sender and the PMTU increased link. So if the PMTU timeout is X, the propagation time is X * N_HOPS.

Herbert Xu

maintainer

2011-11-24 01:01 UTC #9 lore raw

Re: [PATCH 5/5] ipv4: Don't use the cached pmtu informations for input routes

Quoted 4 lines · David Miller

It means there is a propagation delay of PMTU increasing which is on the order of the number of hops between the sender and the PMTU increased link. So if the PMTU timeout is X, the propagation time is X * N_HOPS.

That assumes that each router in the path would constantly probe to refresh its cached value, as otherwise they should all expire after X.

However, as this was the original behaviour, I think going back to it is fine.

I am curious in knowing exactly what scenario Steffen ran into that prompted this change though.

Cheers,

Signature · 3 lines

Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Steffen Klassert

author maintainer

2011-11-24 08:49 UTC #10 lore raw

Re: [PATCH 5/5] ipv4: Don't use the cached pmtu informations for input routes

Quoted 9 lines · Herbert Xu

Quoted 4 lines · David Miller
It means there is a propagation delay of PMTU increasing which is on the order of the number of hops between the sender and the PMTU increased link. So if the PMTU timeout is X, the propagation time is X * N_HOPS.
That assumes that each router in the path would constantly probe to refresh its cached value, as otherwise they should all expire after X.

Well, it simply got unpredictable how long pmtu propagation takes. This depends now on the network activity of the routers and on the individual configuration of the expiration time on each router. With the original behaviour, we could expect to notice a pmtu increase if we probe after our timeout X. Now we don't know when this is going to happen.

Btw. we leak a trigger to check if the learned pmtu information has expired in our current tree, the learned pmtu informations never expire. So we are doing good to not propagate our learned pmtu to other hosts :)

Herbert Xu

maintainer

2011-11-24 12:06 UTC #11 lore raw

Re: [PATCH 5/5] ipv4: Don't use the cached pmtu informations for input routes

Quoted 7 lines · Steffen Klassert

Well, it simply got unpredictable how long pmtu propagation takes. This depends now on the network activity of the routers and on the individual configuration of the expiration time on each router. With the original behaviour, we could expect to notice a pmtu increase if we probe after our timeout X. Now we don't know when this is going to happen.

With IPsec tunnel mode this already happens to an extent anyway. Any PMTU event outside the tunnel is invisible to hosts within it. Only the router can see those events.

However, as I said I'm not too bothered with this so feel free to go with your patch.

Cheers,

Signature · 3 lines

Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt