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: Thu, 11 Nov 2010 13:58:02 -0800 From: "Hua Zhong" <hzhong@...il.com> To: "'Eric Paris'" <eparis@...hat.com>, <netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org> Cc: <davem@...emloft.net>, <kuznet@....inr.ac.ru>, <pekkas@...core.fi>, <jmorris@...ei.org>, <yoshfuji@...ux-ipv6.org>, <kaber@...sh.net> Subject: RE: [RFC PATCH] network: return errors if we know tcp_connect failed > Yes, I realize this is little different than if the > SYN was dropped in the first network device, but it is different > because we know what happened! We know that connect() call failed > and that there isn't anything coming back. I would argue that -j DROP should behave exactly as the packet is dropped in the network, while -j REJECT should signal the failure to the application as soon as possible (which it doesn't seem to do). It does not only make sense, but also is a highly useful testing technique that we use -j DROP in OUTPUT to emulate network losses and see how the application behaves. -- 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