netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 3/3] bridge-netfilter: fix refragmenting IP traffic encapsulated in PPPoE traffic
@ 2010-04-14 13:14 Bart De Schuymer
  2010-04-15 10:29 ` Patrick McHardy
  0 siblings, 1 reply; 4+ messages in thread
From: Bart De Schuymer @ 2010-04-14 13:14 UTC (permalink / raw)
  To: Netfilter Developer Mailing List; +Cc: Stephen Hemminger

bridge-netfilter: fix refragmenting IP traffic encapsulated in PPPoE
traffic

The MTU for IP traffic encapsulated inside PPPoE traffic is smaller
than the MTU of the Ethernet device (1500). Connection tracking
gathers all IP packets and sometimes will refragment them in
ip_fragment(). We then need to subtract the length of the
encapsulating header from the mtu used in ip_fragment(). The check in
br_nf_dev_queue_xmit() which determines if ip_fragment() has to be
called is also updated for the PPPoE-encapsulated packets.
nf_bridge_copy_header() is also updated to make sure the PPPoE data
length field has the correct value.

Signed-off-by: Bart De Schuymer <bdschuym@pandora.be>

--- nf-next-2.6/net/bridge/br_netfilter.c.ori3	2010-04-14 14:06:05.000000000 +0200
+++ nf-next-2.6/net/bridge/br_netfilter.c	2010-04-14 14:11:34.000000000 +0200
@@ -221,6 +221,8 @@ int nf_bridge_copy_header(struct sk_buff
 	skb_copy_to_linear_data_offset(skb, -header_size,
 				       skb->nf_bridge->data, header_size);
 	__skb_push(skb, nf_bridge_encap_header_len(skb));
+	if (unlikely(skb->protocol == htons(ETH_P_PPP_SES)))
+		((struct pppoe_hdr *)skb->data)->length = htons(skb->len-sizeof(struct pppoe_hdr));
 	return 0;
 }
 
@@ -744,7 +746,7 @@ static unsigned int br_nf_forward_arp(un
 static int br_nf_dev_queue_xmit(struct sk_buff *skb)
 {
 	if (skb->nfct != NULL && skb->protocol == htons(ETH_P_IP) &&
-	    skb->len > skb->dev->mtu &&
+	    skb->len + ((skb->nf_bridge->mask & BRNF_PPPoE) ? PPPOE_SES_HLEN:0) > skb->dev->mtu &&
 	    !skb_is_gso(skb))
 		return ip_fragment(skb, br_dev_queue_push_xmit);
 	else
--- nf-next-2.6/net/ipv4/ip_output.c.ori	2010-04-14 14:01:28.000000000 +0200
+++ nf-next-2.6/net/ipv4/ip_output.c	2010-04-14 14:02:41.000000000 +0200
@@ -468,6 +468,10 @@ int ip_fragment(struct sk_buff *skb, int
 
 	hlen = iph->ihl * 4;
 	mtu = dst_mtu(&rt->u.dst) - hlen;	/* Size of data space */
+#ifdef CONFIG_BRIDGE_NETFILTER
+	if (unlikely(skb->nf_bridge && (skb->nf_bridge->mask & BRNF_PPPoE)))
+		mtu -= PPPOE_SES_HLEN;
+#endif
 	IPCB(skb)->flags |= IPSKB_FRAG_COMPLETE;
 
 	/* When frag_list is given, use it. First, check its validity:

-- 
Bart De Schuymer
www.artinalgorithms.be

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH 3/3] bridge-netfilter: fix refragmenting IP traffic encapsulated in PPPoE traffic
  2010-04-14 13:14 [PATCH 3/3] bridge-netfilter: fix refragmenting IP traffic encapsulated in PPPoE traffic Bart De Schuymer
@ 2010-04-15 10:29 ` Patrick McHardy
  2010-04-20 13:33   ` Bart De Schuymer
  0 siblings, 1 reply; 4+ messages in thread
From: Patrick McHardy @ 2010-04-15 10:29 UTC (permalink / raw)
  To: Bart De Schuymer; +Cc: Netfilter Developer Mailing List, Stephen Hemminger

Bart De Schuymer wrote:
> bridge-netfilter: fix refragmenting IP traffic encapsulated in PPPoE
> traffic
> 
> The MTU for IP traffic encapsulated inside PPPoE traffic is smaller
> than the MTU of the Ethernet device (1500). Connection tracking
> gathers all IP packets and sometimes will refragment them in
> ip_fragment(). We then need to subtract the length of the
> encapsulating header from the mtu used in ip_fragment(). The check in
> br_nf_dev_queue_xmit() which determines if ip_fragment() has to be
> called is also updated for the PPPoE-encapsulated packets.
> nf_bridge_copy_header() is also updated to make sure the PPPoE data
> length field has the correct value.
> 
> Signed-off-by: Bart De Schuymer <bdschuym@pandora.be>
> 
> --- nf-next-2.6/net/bridge/br_netfilter.c.ori3	2010-04-14 14:06:05.000000000 +0200
> +++ nf-next-2.6/net/bridge/br_netfilter.c	2010-04-14 14:11:34.000000000 +0200
> @@ -221,6 +221,8 @@ int nf_bridge_copy_header(struct sk_buff
>  	skb_copy_to_linear_data_offset(skb, -header_size,
>  				       skb->nf_bridge->data, header_size);
>  	__skb_push(skb, nf_bridge_encap_header_len(skb));
> +	if (unlikely(skb->protocol == htons(ETH_P_PPP_SES)))
> +		((struct pppoe_hdr *)skb->data)->length = htons(skb->len-sizeof(struct pppoe_hdr));
>  	return 0;
>  }
>  
> @@ -744,7 +746,7 @@ static unsigned int br_nf_forward_arp(un
>  static int br_nf_dev_queue_xmit(struct sk_buff *skb)
>  {
>  	if (skb->nfct != NULL && skb->protocol == htons(ETH_P_IP) &&
> -	    skb->len > skb->dev->mtu &&
> +	    skb->len + ((skb->nf_bridge->mask & BRNF_PPPoE) ? PPPOE_SES_HLEN:0) > skb->dev->mtu &&
>  	    !skb_is_gso(skb))
>  		return ip_fragment(skb, br_dev_queue_push_xmit);
>  	else
> --- nf-next-2.6/net/ipv4/ip_output.c.ori	2010-04-14 14:01:28.000000000 +0200
> +++ nf-next-2.6/net/ipv4/ip_output.c	2010-04-14 14:02:41.000000000 +0200
> @@ -468,6 +468,10 @@ int ip_fragment(struct sk_buff *skb, int
>  
>  	hlen = iph->ihl * 4;
>  	mtu = dst_mtu(&rt->u.dst) - hlen;	/* Size of data space */
> +#ifdef CONFIG_BRIDGE_NETFILTER
> +	if (unlikely(skb->nf_bridge && (skb->nf_bridge->mask & BRNF_PPPoE)))
> +		mtu -= PPPOE_SES_HLEN;
> +#endif

I think it would be nice to encapsulate this in a small inline
function, perhaps nf_bridge_adjust_mtu(skb, mtu) or something
like that.

Please also fix the overly long lines.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH 3/3] bridge-netfilter: fix refragmenting IP traffic encapsulated in PPPoE traffic
  2010-04-15 10:29 ` Patrick McHardy
@ 2010-04-20 13:33   ` Bart De Schuymer
  2010-04-20 14:22     ` Patrick McHardy
  0 siblings, 1 reply; 4+ messages in thread
From: Bart De Schuymer @ 2010-04-20 13:33 UTC (permalink / raw)
  To: Patrick McHardy; +Cc: Netfilter Developer Mailing List, Stephen Hemminger

Patrick McHardy wrote:
> Bart De Schuymer wrote:
>> bridge-netfilter: fix refragmenting IP traffic encapsulated in PPPoE
>> traffic
> 
> I think it would be nice to encapsulate this in a small inline
> function, perhaps nf_bridge_adjust_mtu(skb, mtu) or something
> like that.
> 
> Please also fix the overly long lines.

Done, see below.

bridge-netfilter: fix refragmenting IP traffic encapsulated in PPPoE traffic
 
The MTU for IP traffic encapsulated inside PPPoE traffic is smaller
than the MTU of the Ethernet device (1500). Connection tracking
gathers all IP packets and sometimes will refragment them in
ip_fragment(). We then need to subtract the length of the
encapsulating header from the mtu used in ip_fragment(). The check in
br_nf_dev_queue_xmit() which determines if ip_fragment() has to be
called is also updated for the PPPoE-encapsulated packets.
nf_bridge_copy_header() is also updated to make sure the PPPoE data
length field has the correct value.

Signed-off-by: Bart De Schuymer <bdschuym@pandora.be>

--- nf-next-2.6/include/linux/netfilter_bridge.h.ori3	2010-04-20 14:59:36.000000000 +0200
+++ nf-next-2.6/include/linux/netfilter_bridge.h	2010-04-20 15:19:58.000000000 +0200
@@ -68,6 +68,13 @@ static inline unsigned int nf_bridge_enc
 	}
 }
 
+static inline unsigned int nf_bridge_mtu_reduction(const struct sk_buff *skb)
+{
+	if (unlikely(skb->nf_bridge->mask & BRNF_PPPoE))
+		return PPPOE_SES_HLEN;
+	return 0;
+}
+
 extern int br_handle_frame_finish(struct sk_buff *skb);
 /* Only used in br_device.c */
 static inline int br_nf_pre_routing_finish_bridge_slow(struct sk_buff *skb)
--- nf-next-2.6/net/ipv4/ip_output.c.ori	2010-04-14 14:01:28.000000000 +0200
+++ nf-next-2.6/net/ipv4/ip_output.c	2010-04-20 15:05:27.000000000 +0200
@@ -468,6 +468,10 @@ int ip_fragment(struct sk_buff *skb, int
 
 	hlen = iph->ihl * 4;
 	mtu = dst_mtu(&rt->u.dst) - hlen;	/* Size of data space */
+#ifdef CONFIG_BRIDGE_NETFILTER
+	if (skb->nf_bridge)
+		mtu -= nf_bridge_mtu_reduction(skb);
+#endif
 	IPCB(skb)->flags |= IPSKB_FRAG_COMPLETE;
 
 	/* When frag_list is given, use it. First, check its validity:
--- nf-next-2.6/net/bridge/br_netfilter.c.ori3	2010-04-14 14:06:05.000000000 +0200
+++ nf-next-2.6/net/bridge/br_netfilter.c	2010-04-20 15:03:10.000000000 +0200
@@ -744,7 +744,7 @@ static unsigned int br_nf_forward_arp(un
 static int br_nf_dev_queue_xmit(struct sk_buff *skb)
 {
 	if (skb->nfct != NULL && skb->protocol == htons(ETH_P_IP) &&
-	    skb->len > skb->dev->mtu &&
+	    skb->len + nf_bridge_mtu_reduction(skb) > skb->dev->mtu &&
 	    !skb_is_gso(skb))
 		return ip_fragment(skb, br_dev_queue_push_xmit);
 	else


-- 
Bart De Schuymer
www.artinalgorithms.be

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH 3/3] bridge-netfilter: fix refragmenting IP traffic encapsulated in PPPoE traffic
  2010-04-20 13:33   ` Bart De Schuymer
@ 2010-04-20 14:22     ` Patrick McHardy
  0 siblings, 0 replies; 4+ messages in thread
From: Patrick McHardy @ 2010-04-20 14:22 UTC (permalink / raw)
  To: Bart De Schuymer; +Cc: Netfilter Developer Mailing List, Stephen Hemminger

Bart De Schuymer wrote:
> bridge-netfilter: fix refragmenting IP traffic encapsulated in PPPoE traffic
>  
> The MTU for IP traffic encapsulated inside PPPoE traffic is smaller
> than the MTU of the Ethernet device (1500). Connection tracking
> gathers all IP packets and sometimes will refragment them in
> ip_fragment(). We then need to subtract the length of the
> encapsulating header from the mtu used in ip_fragment(). The check in
> br_nf_dev_queue_xmit() which determines if ip_fragment() has to be
> called is also updated for the PPPoE-encapsulated packets.
> nf_bridge_copy_header() is also updated to make sure the PPPoE data
> length field has the correct value.
> 

Applied, thanks Bart.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2010-04-20 14:22 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-04-14 13:14 [PATCH 3/3] bridge-netfilter: fix refragmenting IP traffic encapsulated in PPPoE traffic Bart De Schuymer
2010-04-15 10:29 ` Patrick McHardy
2010-04-20 13:33   ` Bart De Schuymer
2010-04-20 14:22     ` Patrick McHardy

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).