Hello, i looked into the problem of fragmenting packets on layer2 to solve the mtu issue. I found a unforeseen problem : oversized packets will be dropped by the bridge module ( if bat0 is in a bridge ). I think the reason can be found here net/bridge/br_forward.c on line 44
43 /* drop mtu oversized packets except gso */ 44 if (packet_length(skb) > skb->dev->mtu && !skb_is_gso(skb)) 45 kfree_skb(skb);
Possible solution: make a patch for the bridge module
if (packet_length(skb) > skb->dev->mtu && !skb_is_gso(skb) && !(skb->dev->priv_flags & IFF_CAN_FRAG))
IFF_CAN_FRAG must be added to include/linux/if.h and batman-adv has to set this flag on bat0
I can make a patch for mainline inclusion, do you believe it is going to be accepted ?
regards, andreas
On Thu, May 27, 2010 at 04:23:50PM +0200, Andreas Langer wrote:
Hello, i looked into the problem of fragmenting packets on layer2 to solve the mtu issue. I found a unforeseen problem : oversized packets will be dropped by the bridge module ( if bat0 is in a bridge ). I think the reason can be found here net/bridge/br_forward.c on line 44
43 /* drop mtu oversized packets except gso */ 44 if (packet_length(skb) > skb->dev->mtu && !skb_is_gso(skb)) 45 kfree_skb(skb);
I don't quite understand the problem. If you have implemented fragmentation, you will naturally increase the MTU on bat0 so that it is the standard for Ethernet. So this statement will not trigger.
Andrew
On Thursday 27 May 2010 23:07:00 Andrew Lunn wrote:
I don't quite understand the problem. If you have implemented fragmentation, you will naturally increase the MTU on bat0 so that it is the standard for Ethernet. So this statement will not trigger.
AFAIK batman-adv determines the minimal MTU automatically, so that you can't simply increase the mtu on bat0. But you are right - if the fragmentation is enabled batman-adv could allow higher mtu values.
Cheers, Marek
On Thu, May 27, 2010 at 11:30:15PM +0800, Marek Lindner wrote:
On Thursday 27 May 2010 23:07:00 Andrew Lunn wrote:
I don't quite understand the problem. If you have implemented fragmentation, you will naturally increase the MTU on bat0 so that it is the standard for Ethernet. So this statement will not trigger.
AFAIK batman-adv determines the minimal MTU automatically, so that you can't simply increase the mtu on bat0. But you are right - if the fragmentation is enabled batman-adv could allow higher mtu values.
We discussed this a while ago. Actually fragmentation should be considered the last resort. It if first better to try header compression, to make the frame small enough that it can be sent without fragmentation. I think you had a quick look at using the PPP compression code, but i guess it did not go any further.
We only need to fragment when compression is not possible.
In either case, we should remove the automatic MTU calculation, and just offer the default for Ethernet. Let the compression and fragmentation code solve any differences.
Andrew
On Thursday 27 May 2010 23:42:36 Andrew Lunn wrote:
We discussed this a while ago. Actually fragmentation should be considered the last resort. It if first better to try header compression, to make the frame small enough that it can be sent without fragmentation. I think you had a quick look at using the PPP compression code, but i guess it did not go any further.
We only need to fragment when compression is not possible.
I read about the compression and I still think it is a good idea. Unfortunately, it requires deep packet inspection and would only work for 99% of the IPv4 traffic. Besides, both solutions do not exclude each other.
Regards, Marek
b.a.t.m.a.n@lists.open-mesh.org
-
Andreas Langer -
Andrew Lunn -
Marek Lindner