On Monday 2010-03-22 17:58, Patrick McHardy wrote:
>>
>>>> and cause reentrancy. So we skip that too and go
>>>> + * directly to ip_finish_output.
>>
>> And since we don't want fragmentation, we would need to call
>> ip_finish_output2. That function is not exported, so it is copied. I
>> am not even sure what the IPv4 layer does when it has to fragment a
>> fragment (because fragments don't seem to carry IP_DF).
>
>I guess whether someone wants fragmentation is a question of the specific
>use case. In many possible cases conntrack might have defragmented the
>packet previously to reaching TEE, so it might actually be necessary to
>refragment the packet.
Aww..true.
>> Setting IP_DF on the cloned skb could possibly lead to a Packet Too
>> Big being sent back to the original sender - which should probably be
>> avoided too.
>
>Indeed. This might also happen if the packet is passed through another
>router of course.
Right. So let's set IP_DF on the teed packet and let the sender
reduce its packet size to accomodate for the (hidden) tee route :)
Is it ok if the Packet Too Big notification is received by the
original sender much later than an acknowledgement in reception to
the packet?
# Topology
digraph {
A -- internet_cloud;
internet_cloud -- R;
R -- B [label="mtu=1500"];
R -- C [label="mtu=1480"];
};
1. A->B TCP received by R
2. R clones to C
3. B receives and responds with TCP ACK
4. A receives ACK
5. A receives the PMTU update from R while trying to send to C
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
