>
>On Thursday 2012-06-14 08:17, Hans Schillstrom wrote:
>
>>Hello,
>>
>>I think it is wrong to always force the DF bit in IPv4, it's better to have an option
>
>Do you experience an actual problem?
Yes, with almost every UDP protos.
>
>>If an application don't set the DF bit, usually it doesn't expect to
>>get an icmp back either.
>
>Applications often don't have the means to set DF, think SOCK_STREAM.
Yeah I do, and TCP usually set the DF bit and if you inherit that it should not be a problem.
BTW, I don't see any real use case for TCP except for a "remote" tcpdump
>
>>The result is that the packet will be dropped...
>
>And exactly because of that, an ICMP message should be generated, to
>notify the sender about a reduced MTU, so that the TEE destination does
>in fact get the messages.
Inherit - don't force, it's a better idea
if you don't set it you don't expect an ICMP either.
>
>>
>>To retain backwards compatibility I suggest adding a new option like
>>
>>--ipv4-df-copy Do not force "Don't Fragment" on the copied packet just copy the bit.
>>
>>In IPv6 we don't have that option, so nothing has to be done there.
>>
>>
>>diff --git a/include/linux/netfilter/xt_TEE.h b/include/linux/netfilter/xt_TEE.h
>>index 5c21d5c..e5fca8a 100644
>>--- a/include/linux/netfilter/xt_TEE.h
>>+++ b/include/linux/netfilter/xt_TEE.h
>>@@ -4,6 +4,7 @@
>> struct xt_tee_tginfo {
>> union nf_inet_addr gw;
>> char oif[16];
>>+ int df_copy;
>>
>> /* used internally by the kernel */
>> struct xt_tee_priv *priv __attribute__((aligned(8)));
>
>As Pablo mentioned, you cannot touch this structure.
I know this was just a RFC, I should have made a note about that :-)
>"int" is also a bad idea. - See my very own "Writing Netfilter Modules"
>pdf for details.
Thanks
/Hans
--
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
