Re: [B.A.T.M.A.N.] batman adv unicast fragmentation (version 3)

[Sven Eckelmann <sven.eckelmann@gmx.de>]

[-- Attachment #1: Type: Text/Plain, Size: 2717 bytes --]

Andreas Langer wrote:
> >> +			if (!(my_skb_push(frag_skb, hdr_len) >= 0 &&
> >> +				my_skb_push(skb, hdr_len) >= 0)) {
> >
> >Didn't you wanted to check if one of the my_skb_push failed and not if
> >both failed?
> 
> This part check if one failed, but you are right if you think that it looks
> too complicated. I changed it because it is easy to misunderstand this
> expression.

Yes, sry. I mixed it up :)

> And now some words to the implementation. This version of fragmentation
> handles only packets over a batX interface. My test setup follows:
> 
> laptop tap0 --> br0 (bat0/eth0) host1 eth1 ------> eth0 host2 -----> eth0
> host3
> 
> ping -s 1472 -M do xxx
> 
> 1472 bytes - data
> 28   bytes - icmp / ip
> 14   bytes - eth
> 
> Bat0 receives 1514 bytes (interface_tx, data_len), if data_len +
> unicast_packet is larger than the mtu of the sending interface, this
> packet will be fragmented.
> 
> In fragmentation 2.0 i would like to implement a solution for the problem
> described by simon ( i hope i understood him correctly). A node has two
> batman interfaces and the mtu of interface2 is smaller then interface1. In
> case a packet from iface1 (with the size of this mtu) travels to iface2,
> we currently have a problem. Version 2.0 will fix this.

You described the problem correct. Just for other people: batman interfaces 
means not a bat0 and a bat1 interface, but two interfaces which are part of 
bat0.

So for example you have a wifi connection with mtu 1530 between node1 and 
node2 (bat0 interface has mtu 1500) and the connection between node2 and node3 
is only a fast ethernet connection with mtu 1500 (no jumbo frames support). 

node1 <- mtu 1530 -> node2 <- mtu 1500 -> node3

When we send data like our 1472 ping (needs mtu 1500 on bat0, and on the real 
interface mtu 1523) to node3, it will not be fragmented between node1 and 
node2 - thus it will not be fragmented between node2 and node3 (they will just 
drop the packet).

So it must not only be fragmented on output (data send directly through bat0), 
but also on forward (when bat0 received data on a participating interface and 
forwards it to another/same participating interface).

I see following problem:
 * Data will be fragmented from node1 to node2
 * fragmented packet is to big to be transported to node3

Now we would have to fragment the fragmented packet again... which is ugly. 
But to be honest, bat0 in a mesh which supports fragmented unicast packets is 
hardcoded to 1500. That means that the link between node2 and node3 must have 
the mtu < 775. That would be uncommon and maybe could be forbidden by batman-
adv.

best regards,
	Sven

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]