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