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
| ||
|
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
Powered by blists - more mailing lists