netdev - Re: [PATCH net-next] tcp: Add TCP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKfDRXgARYe3hw3vgpgup1X4bNjH0cpwYOfKUZK51HcOf2jeJA@mail.gmail.com>
Date:	Wed, 22 Oct 2014 19:08:03 +0200
From:	Kristian Evensen <kristian.evensen@...il.com>
To:	David Miller <davem@...emloft.net>
Cc:	Network Development <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next] tcp: Add TCP_FREEZE socket option

Hi,

On Wed, Oct 22, 2014 at 6:14 PM, David Miller <davem@...emloft.net> wrote:
> Instead, I would expect the device layer to trigger a notification
> during a "technology change" or whatever you want to call losing
> connectivity, whichi TCP can receive and use to start sending zero
> windows over all TCP connections using that path.

I totally agree that this is ideally something that should be
controlled by the device layer. However, these temporary disconnects
are not visible through any normal link events (like link down, loss
of address, ...). The only way to detect the events is to parse meta
data coming from devices and look at traffic statistics. This would
involve for example adding parsing of the different mobile broadband
protocols (QMI, MBIM, and so on) to the device layer. When looking at
for example the commits for the QMI driver, parsing QMI messages seems
to have intentionally been left up to user space applications to avoid
bloating driver.

> And therefore there should be a global option that turns this on for
> the entire system by default.
>
> This requires a lot more work than you have done here, you need to
> add all the notification handling, the logic in TCP to look at the
> attached route on send and trigger zero window probes if the device
> event has happened, etc.

Another approach I designed was to have a separate TCP Freeze module
and trigger the freeze/unfreeze through genetlink-messages. A user
space application will be responsible for monitoring the devices and
decide when to trigger the ZWAs. Would a design like that be
acceptable?

-Kristian
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html