From owner-freebsd-ipfw@freebsd.org Fri Aug 5 05:44:12 2016 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E1C99BAD745 for ; Fri, 5 Aug 2016 05:44:12 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C08231689 for ; Fri, 5 Aug 2016 05:44:12 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-226-8.lns20.per1.internode.on.net [121.45.226.8]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id u755i6lK004677 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 4 Aug 2016 22:44:09 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: your thoughts on a particualar ipfw action. To: freebsd-ipfw@freebsd.org References: <20160805024301.H56585@sola.nimnet.asn.au> From: Julian Elischer Message-ID: <7486c7ce-49db-b6b9-a6bb-13f04b4ce6d6@freebsd.org> Date: Fri, 5 Aug 2016 13:44:01 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2016 05:44:13 -0000 On 5/08/2016 2:22 AM, Dr. Rolf Jansen wrote: > I am completely free of passions on this CC encoding thingy. I won't use this feature anyway. Please, may I suggest that the experts of the ipfw community come to an agreement, and I then I will change the implementation accordingly. > > Another possibility could be to attach the desired rule numbers directly to the country codes in the argument of the -t option, How about: > > geoip -t AU=50000:RU=50010:US=50020:BR=50030 > > The present behaviour would be kept without attached numbers. Please let me know your choices. Furthermore, if the new ipfw allows for more sophisticated table construction directives, that could be beneficial for country code based table processing, please advice. > I can hear the exasperation in your writing :-) I've lost track.. Was the present behaviour just a single value? or a generated number with -x offset? (not sure if you actually added that or just described it). your "US=50020" idea is nice but a lot of work I think for you. I guess you would do it with script geoip -t US=${LINE_US} |ipfw -q /dev/stdin ipfw add ${LINE_US} drop all tcp from any to any 80 ipfw add $((${LINE_US} + 1)) skipto ${FINISH_UP} probably in a shell function it would also allow you to put 'action numbers' rather than line numbers as it doesn't interpret the values, just passes them through. On the other hand the same thing can be achieved by embedding geoip in a loop in a script. I think we should just let you get on with your life and be happy with what you have given us. mapping a set of country codes to a number. I can always make more complicated setups using that and 15 minutes of shell script.