Skip to contentSkip to conversation

ip6tables: use skb->len for accounting

PATCH Applied Changli Gao 3 participants 8 messages Jul 23, 2010

Subsystems (3)
Networking Network drivers netfilter
lore
Share & tools
lore

Changli Gao

author
#0 lore raw

PATCH 1/1 ip6tables: use skb->len for accounting

ip6tables: use skb->len for accounting

ipv6_hdr(skb)->payload_len is ZERO and can't be used for accounting, if the payload is a Jumbo Payload specified in RFC2675.

Signed-off-by Changli Gao <[email protected]>

----

 net/ipv6/netfilter/ip6_tables.c |    4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)
net/ipv6/netfilter/ip6_tables.c +1 -3
index dc41d6d..33113c1 100644
@@ -387,9 +387,7 @@ ip6t_do_table(struct sk_buff *skb,
 				goto no_match;
 		}
 
-		ADD_COUNTER(e->counters,
-			    ntohs(ipv6_hdr(skb)->payload_len) +
-			    sizeof(struct ipv6hdr), 1);
+		ADD_COUNTER(e->counters, skb->len, 1);
 
 		t = ip6t_get_target_c(e);
 		IP_NF_ASSERT(t->u.kernel.target);
#1 lore raw
Quoted 15 lines · Changli Gao

ip6tables: use skb->len for accounting

ipv6_hdr(skb)->payload_len is ZERO and can't be used for accounting, if the payload is a Jumbo Payload specified in RFC2675.

Signed-off-by Changli Gao <[email protected]>

----
net/ipv6/netfilter/ip6_tables.c | 4 +---

1 file changed, 1 insertion(+), 3 deletions(-)
net/ipv6/netfilter/ip6_tables.c +0 -0
index dc41d6d..33113c1 100644
@@ -387,9 +387,7 @@ ip6t_do_table(struct sk_buff *skb,
 				goto no_match;

net/ipv6/netfilter/ip6_tables.c ip6t_do_table(struct sk_buff *skb,

Quoted 10 lines
net/ipv6/netfilter/ip6_tables.c +1 -4
 		}
 
-		ADD_COUNTER(e->counters,
-			    ntohs(ipv6_hdr(skb)->payload_len) +
-			    sizeof(struct ipv6hdr), 1);
+		ADD_COUNTER(e->counters, skb->len, 1);
 
 		t = ip6t_get_target_c(e);
 		IP_NF_ASSERT(t->u.kernel.target);
--

I wonder how this fares with trailing padding or data, like, when you have a standard v4/v6 packet created in a raw socket, and append a bunch of \0s to it.

author
#2 lore raw
Quoted 7 lines · Jan Engelhardt

I wonder how this fares with trailing padding or data, like, when you have a standard v4/v6 packet created in a raw socket, and append a bunch of \0s to it.

For the packets received, ip_rcv, ipv6_rcv and bridge all call pskb_trim_rcsum before feeding them to netfilter. The raw packets are sent via dev_queue_xmit(), and they don't pass through the output path of netfilter. One case, maybe the queued packets mangled "wrongly" in userspace are reinjected, however, we can't prevent a user from changing the payload_len wrongly.

Signature · 2 lines
Regards,
Changli Gao([email protected])
#3 lore raw
Quoted 9 lines · Changli Gao
Quoted 7 lines · Jan Engelhardt

I wonder how this fares with trailing padding or data, like, when you have a standard v4/v6 packet created in a raw socket, and append a bunch of \0s to it.

Quoted 4 lines

For the packets received, ip_rcv, ipv6_rcv and bridge all call pskb_trim_rcsum before feeding them to netfilter. The raw packets are sent via dev_queue_xmit(), and they don't pass through the output path of netfilter.

That's not true, raw packets also pass through netfilter. However I agree that this patch makes sense to properly deal with jumbo frames, but you should also update xt_length for consistency.

author
#4 lore raw
Quoted 11 lines · Patrick McHardy
Quoted 5 lines · Changli Gao

For the packets received, ip_rcv, ipv6_rcv and bridge all call pskb_trim_rcsum before feeding them to netfilter. The raw packets are sent via dev_queue_xmit(), and they don't pass through the output path of netfilter.

That's not true, raw packets also pass through netfilter. However I agree that this patch makes sense to properly deal with jumbo frames, but you should also update xt_length for consistency.

In order to support jumbo frames, we have to change the type of min and max in xt_length_info to u32. I'll change xt_match.revision to 1, do I need to support the current revision 0 at the same time?

Signature · 2 lines
Regards,
Changli Gao([email protected])
#5 lore raw
Quoted 8 lines · Changli Gao
Quoted 7 lines · Patrick McHardy
Quoted 5 lines · Changli Gao

For the packets received, ip_rcv, ipv6_rcv and bridge all call pskb_trim_rcsum before feeding them to netfilter. The raw packets are sent via dev_queue_xmit(), and they don't pass through the output path of netfilter.

Quoted 7 lines
Quoted 4 lines

That's not true, raw packets also pass through netfilter. However I agree that this patch makes sense to properly deal with jumbo frames, but you should also update xt_length for consistency.

In order to support jumbo frames, we have to change the type of min and max in xt_length_info to u32.

I see. In that case I'll apply your skb->len patches as they are, so please make the xt_length change in a new patch.

Quoted 2 lines

I'll change xt_match.revision to 1,
do I need to support the current revision 0 at the same time?

You should simply keep the revision 0 code as it is. Revision 1, using skb->len, can be used for both IPv4 and IPv6.

#6 lore raw
In reply to Changli Gao
Quoted 8 lines · Changli Gao
Quoted 7 lines · Patrick McHardy
Quoted 5 lines · Changli Gao

For the packets received, ip_rcv, ipv6_rcv and bridge all call pskb_trim_rcsum before feeding them to netfilter. The raw packets are sent via dev_queue_xmit(), and they don't pass through the output path of netfilter.

Quoted 8 lines
Quoted 4 lines

That's not true, raw packets also pass through netfilter. However I agree that this patch makes sense to properly deal with jumbo frames, but you should also update xt_length for consistency.

In order to support jumbo frames, we have to change the type of min and max in xt_length_info to u32. I'll change xt_match.revision to 1, do I need to support the current revision 0 at the same time?

This is all already handled by xt_length.2. But alas, merge has been declined so far.

Applied
#7 lore raw
In reply to Changli Gao
Quoted 4 lines · Changli Gao

ip6tables: use skb->len for accounting

ipv6_hdr(skb)->payload_len is ZERO and can't be used for accounting, if the payload is a Jumbo Payload specified in RFC2675.

Applied, thanks.