[Bridge] [BUG] Dropping fragmented IP packets within VLAN frames on bridge

[Bridge] [BUG] Dropping fragmented IP packets within VLAN frames on bridge

Post by Patrick Mc » Sun, 27 May 2007 17:20:07



net/8021q ignores the VLAN header overhead, so we should probably do the
same here for consistency. Using IS_VLAN_IP (and IS_PPPOE_IP for current
-rc) looks fine, additionally we should probably also check for
skb->nfct != NULL to make sure that at least without connection tracking
the bridge doesn't perform fragmentation.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/
 
 
 

[Bridge] [BUG] Dropping fragmented IP packets within VLAN frames on bridge

Post by Patrick Mc » Mon, 28 May 2007 00:10:05


The MTU checks are self-explanatory. Just a comment above the function
stating that it tries to find out whether a packet needs to be
refragmented because it was defragmented by IPv4 connection tracking
and exceeds the MTU should be enough.



As I said, I don't think we should account for the VLAN header overhead,
the VLAN code itself doesn't even do it. And we should exclude packets
that don't have a connection tracking reference attached since we are
only undoing the damage connection tracking did by defragmenting it
and should avoid fragmenting other packets as good as possible.



It looks OK. But there is another problem, ip_fragment doesn't care
about the PPPoE overhead and produces a packet that will be too large
after restoring the PPPoE header. A second __fake_rtable that accounts
for the PPPoE overhead could probably fix that ..



Sure :)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/