Linux Ethernet Bridging - Apr 2007 - [Bridge] Any way of knowing a packet's been defragmented

>----- Oorspronkelijk bericht -----
>Van
: Henrik Nordstrom [mailto:hno@marasystems.com]
>Verzonden
: donderdag
, augustus
 5, 2004 01:10 PM
>Eh.. I do not claim to be a bridge guru, but won't such bridge cause 
>serious havoc on the network much like PMTU blackholes does?
Someone who sets up such a bridge should obviously know what she is doing.
That's not our problem.
>You should either reject creating such bridge, or make sure to fragment 
>packets including ICMP MUST FRAGMENT generation when not allowed (which 
>requires an IP).
It's connection tracking that is responsible for the defragmentation and
connection tracking WILL refragment the packets, BUT only if the bridge code
doesn't drop the packet first.
The bridge code should obviously not send any ICMP message.

> -----Original Message-----
> From: bridge-bounces@lists.osdl.org 
> [mailto:bridge-bounces@lists.osdl.org] On Behalf Of Henrik Nordstrom
> 
> Eh.. I do not claim to be a bridge guru, but won't such bridge cause 
> serious havoc on the network much like PMTU blackholes does?
> 
> You should either reject creating such bridge,
IMO, the driver should not bridge any packets from a device with a
larger MTU to a device with a smaller MTU, which I suppose is almost the
same as forbidding such a bridge to be created, but I seem to remember
Stephen's commenting that the 802 bridge spec says it should be done the
way it is now.
> or make sure to fragment packets including ICMP MUST
> FRAGMENT generation when not allowed (which requires an IP).
The ethernet bridge driver is the wrong place to do IP or any other
higher-layer protocol.  Its job is to be a LAN in a box.  If a device
claims that it can only send packets up to a certain size, the bridge
honors that claim.

If connection tracking is coalescing ethernet packets into a size
greater than would otherwise be received from a device, then connection
tracking should be responsible for undoing that damage (where and when,
I don't know), otherwise the ethernet bridge driver will become a
monstrosity of stuff unrelated to ethernet.

On Wed, 4 Aug 2004, Bart De Schuymer wrote:
> Due to a recent change in the bridge code, we now need a way of knowing if
> a packet has been defragmented. The bridge code now checks on the packet
> size and drops packets that are too big for the output port. Defragmented
> packets will get refragmented later, so they shouldn't be dropped.
Well.. iptables does not really care why the packet is oversized. It
fragments any oversized packets.

Why does the bridge need to?

Regards
Henrik

>Van
: Henrik Nordstrom [mailto:hno@marasystems.com]
>Verzonden
: donderdag
, augustus
 5, 2004 07:55 AM
>Aan
: 'Bart De Schuymer'
>The question on why the bridge needs to drop oversized fragments instead 
>of simply letting iptables fragment them remains...
As Stephen explained, bridge ports of the same bridge device no longer need to
have the same mtu. So the bridge code needs to drop packets (ARP, IP, whatever)
that will be too long for the output port.
The whole idea behind the new flag is giving the bridge code enough information
so it doesn't drop to-be-fragmented packets.

cheers,
Bart

> -----Original Message-----
> From: Henrik Nordstrom [mailto:hno@marasystems.com] 
> The check should be after all 
> netfilter hooks just before the packet is given to the NIC 
> driver, dropped 
> on transmit because it can not be sent out on the target media, not 
> dropped in "bridge forwarding" because it seems to be bigger than
the
> intended target device.
That makes sense.

Regards,
Dan

Hello,

Due to a recent change in the bridge code, we now need a way of knowing if
a packet has been defragmented. The bridge code now checks on the packet
size and drops packets that are too big for the output port. Defragmented
packets will get refragmented later, so they shouldn't be dropped.
I've been reading the defragmentation code and can't find an easy way of
knowing if a packet has been defragmented.
It's easy to check for a changed size of the skb of course, but a mangle
target could be responsible for a changed size too, probably.
So, my question: is there currently a fast way to know this?
If not, would the netfilter core team oppose to adding a
NFC_DEFRAGMENTED flag for the nf_cache field of the skb, which is set
by the defragmentation code?

To be more concrete, I've attached the proposed addition below.

cheers,
Bart

--- linux-2.6.8-rc2-bk9/include/linux/netfilter.h.old	2004-08-04
22:46:45.000000000 +0200
+++ linux-2.6.8-rc2-bk9/include/linux/netfilter.h	2004-08-04 22:47:49.000000000
+0200
@@ -24,6 +24,7 @@
    <= 0x2000 is used for protocol-flags. */
 #define NFC_UNKNOWN 0x4000
 #define NFC_ALTERED 0x8000
+#define NFC_DEFRAGMENTED 0x10000
 
 #ifdef __KERNEL__
 #include <linux/config.h>
--- linux-2.6.8-rc2-bk9/net/ipv4/netfilter/ip_conntrack_core.c.old	2004-08-04
22:46:32.000000000 +0200
+++ linux-2.6.8-rc2-bk9/net/ipv4/netfilter/ip_conntrack_core.c	2004-08-04
22:48:20.000000000 +0200
@@ -1212,7 +1212,7 @@ ip_ct_gather_frags(struct sk_buff *skb)
 	}
 
 	ip_send_check(skb->nh.iph);
-	skb->nfcache |= NFC_ALTERED;
+	skb->nfcache |= NFC_ALTERED | NFC_DEFRAGMENTED;
 #ifdef CONFIG_NETFILTER_DEBUG
 	/* Packet path as if nothing had happened. */
 	skb->nf_debug = olddebug;