From owner-freebsd-pf@FreeBSD.ORG Wed Dec 4 14:29:31 2013 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 56048EBF for ; Wed, 4 Dec 2013 14:29:31 +0000 (UTC) Received: from mail-ea0-f179.google.com (mail-ea0-f179.google.com [209.85.215.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D5621144E for ; Wed, 4 Dec 2013 14:29:30 +0000 (UTC) Received: by mail-ea0-f179.google.com with SMTP id r15so10642968ead.24 for ; Wed, 04 Dec 2013 06:29:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; bh=GXxk248+D7yEtRtwG0QMtDIl1Ric8xnvYd3vNMOy59w=; b=dmdBpYKZNbZ75nqLatjKrSTC5mvmQgsU356rmIkhjwCqiY1ZSQK/9nNvHcl0a7tYvu QvzucN+CKNeShKOU33/v7p444sWZMFhqHW8cGL7elTf16YNZy7zIY+1vPQlnmn2uNaeG a50+8MNVmwwVHV1/Vn6kydZR6Xinq9Ou20XRrzQ/QuZMwgJ3GQt2dgkpdHd3KErab5e0 0EXWJYMxmUQ7L+Qb32BnJaoSfh3wRGlMgJoMK0VOkx0PDWaT+4tAjBFOxoxDFUwHgMKe gvQiVXhJERR/H153vcAEuxQqstO8aD0aKWKAmrYAC+S+i6zREBgrj764mI33Y0FTQQOI EV/g== X-Gm-Message-State: ALoCoQlvpc/vQDfiJQt5BCIoZ+RkW5gCoGCU0asI/uiJ/PEAW8UIWq/IMDVNzyXKVSndVi7Se1Z5 X-Received: by 10.14.182.199 with SMTP id o47mr75925317eem.7.1386167363099; Wed, 04 Dec 2013 06:29:23 -0800 (PST) Received: from zvezda.localnet ([212.48.107.10]) by mx.google.com with ESMTPSA id g47sm95065582eeo.19.2013.12.04.06.29.22 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Dec 2013 06:29:22 -0800 (PST) From: Kajetan Staszkiewicz To: Gleb Smirnoff Subject: Re: [patch] Source entries removing is awfully slow. Date: Wed, 4 Dec 2013 15:29:21 +0100 User-Agent: KMail/1.13.7 (Linux/3.10.1; KDE/4.8.4; x86_64; ; ) References: <201303081419.17743.vegeta@tuxpowered.net> <201312021728.58010.vegeta@tuxpowered.net> <20131202163927.GM48919@glebius.int.ru> In-Reply-To: <20131202163927.GM48919@glebius.int.ru> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201312041529.21788.vegeta@tuxpowered.net> Cc: "freebsd-pf@freebsd.org" X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 14:29:31 -0000 Dnia poniedzia=C5=82ek, 2 grudnia 2013 o 17:39:27 Gleb Smirnoff napisa=C5= =82(a): > I won't object on any interface that is consistent and resides in the > '-K' and '-k' namespace. As said before, I am against utilizing new > letters for options to avoid clashing with pfctl syntax in OpenBSD. I have a nice commandline parser working, but I got blocked by one problem.= As=20 the parser is quite big and most options are common for -K and -k, the pars= er=20 is just one function for both operation modes (and a similar thing for the= =20 loops going over IP addresses found by given host names). Unfortunately=20 DIOCKILLSTATES and DIOCKILLSRCNODES are using separate structures. Whatever the parser reads, it puts the result in the following structure=20 (defined only inside pfctl, not kernel): struct pfioc_universal_kill { sa_family_t puk_af; int puk_proto; struct pf_rule_addr puk_src; struct pf_rule_addr puk_dst; struct pf_rule_addr puk_rdr; struct pf_state_cmp puk_pfcmp; char puk_ifname[IFNAMSIZ]; char puk_label[PF_RULE_LABEL_SIZE]; char puk_table[PF_TABLE_NAME_SIZE]; u_int puk_killed_states; u_int puk_killed_src_nodes; }; Which later gets translated for every ioctl to pfioc_src_node_kill or=20 pfioc_state_kill. To have the most clean and simple code it would make the most sense to use = the=20 aforementioned pfioc_universal_kill for both DIOCKILLSTATES and=20 DIOCKILLSRCNODES. But that would be a change of kernel api which I assume c= an=20 not take place inside major release, so translation of structures is curren= tly=20 the way to go. Please correct me if I am wrong. =2D-=20 | pozdrawiam / greetings | powered by Debian, FreeBSD and CentOS | | Kajetan Staszkiewicz | jabber,email: vegeta()tuxpowered net | | Vegeta | www: http://vegeta.tuxpowered.net | `------------------------^---------------------------------------'