lkml.org 
[lkml]   [2010]   [Jan]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] xt TCPMSS: SYN packets are allowed to contain data
    On Wed, 20 Jan 2010 21:51:33 +0000, Simon Arlott <simon@fire.lp0.eu>
    wrote:
    > On 20/01/10 21:41, Jan Engelhardt wrote:
    >> On Wednesday 2010-01-20 22:39, Jan Engelhardt wrote:
    >>
    >>>On Wednesday 2010-01-20 22:21, Simon Arlott wrote:
    >>>
    >>>>The TCPMSS target is dropping SYN packets where:
    >>>> 1) There is data, or
    >>>> 2) The data offset makes the TCP header larger than
    >>>> the packet.
    >>>>
    >>>>Both of these result in an error level printk.
    >>>>
    >>>>This change fixes the drop of SYN packets with data
    >>>>(because the MSS option can safely be modified) and
    >>>>passes packets with no MSS option instead of adding
    >>>>one (which is not valid).
    >>>
    >>>Can you explain why the automatic addition of a MSS option is removed?
    >>
    >> That is, of course, for the git log. If I followed the thread right, it

    >> was that adding the option could exceed the MTU. Well, can't we check
    >> for the outgoing MTU?
    >
    > The MSS option is for the MRU of whoever sent the SYN packet. There's no
    > way of knowing this information so it's not possible to avoid using an
    > MSS that is too large. With no option, "any" segment size could be used,
    > which implies 536 to match the MRU of 576.
    >
    > The other reason for not being able to add it is that it may increase
    the
    > packet size beyond an MRU/MTU limit if there is data. There's no
    guarantee
    > we'll see an ICMP error message if this occurs, because the limit
    doesn't
    > have to be local and the return path does not need to be the same. The
    > original host won't know that the packet is going to be increased in
    size.

    (I know little, so just my 2c)

    So... packets are 'tunneled' down a link where MSS is required/added.
    However packets which will not fit into the MTU of that 'tunnel' are send
    down it without MSS and without fragmentation? I wonder what would happen
    if all TCP MTUs worked that way...

    Maybe I've misunderstood how path MTU discovery works. But is it and TCP
    not built on the premise that the origin source host always receives the
    ACKs regardless of reverse route? With PMTU discovery built on that
    guarantee, to return the ICMP error to the same source the ACK would go?

    If ICMP is administrively crippled to break TCP its not iptables fault,
    nor the admin who is using TCP/ICMP correctly to signal available MTU.

    AYJ


    \
     
     \ /
      Last update: 2010-01-20 23:31    [W:3.554 / U:1.268 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site