your thoughts on a particualar ipfw action.

[Dr. Rolf Jansen]

> Am 05.08.2016 um 02:44 schrieb Julian Elischer <julian at freebsd.org>:
> 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 :-)

Not exactly 'exasperation'. Moving targets are always kind of unpleasant - at least for me, perhaps I am not a sufficiently patient hunter :-)

> 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).

I meant, geoip would continue allowing a -t option argument without numbers, for example -t AU:RU:US:BR, and in that case it would continue with its present behaviour (mutually exclusive either -v XOR -x):

-v <fixed value> # default 0
-x <offset>      # in val = (C1-60)*1000 + C2*10 + offset

The -v and -x options as above are already on GitHub, the x-formula can be changed quickly. 

> your "US=50020" idea is nice but a lot of work I think for  you.

Not that much work. I like this one as well, because this is the most explicit way, that I can imagine, of associating a rule/action number with a country code.

I figure, that any kind of x-formula let people shoot themselves in the foot at one day or the other. Imagine you set up your sophisticated rule set in 2016 and in 2017 a colleague is asked by the boss to add another country code. The trouble may start by she/he forgets to add an action rule for the implicitly generated table argument, and it does not end with a possible violation of the implicitly reserved rule number range.

> 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}

Yes, why not? The nice thing of the "CC=nnnnn:..." feature is, that it is already useful as is, and that it is open for any further sophistication with shell script magics.  

> 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.

Yes, for us this is not a big deal. However, once this stuff is in the ports, I have to take into account the work of answering questions from the non-enlightened folks, on how to achieve the mapping between rule numbers and country codes. Perhaps, it is less hassle to simply add the "CC=nnnnn:..." feature and move on.


BTW:

In the course of preparing the packet for the ports, I am working now on a man file for the geoip db utilities (geoip, ipdb and ipdb-update.sh). I want to put it to section 1 - General Commands, OK?

Shall I remove the geod ipfw divert filter daemon from the distribution for the ports?

My initial incentive was Geo-blocking. However, I learned from your VPN usage example (in your other message), that these utilities may quite well serve for other objectives. Now, I am looking for a package title that does suggest a wider range of applications.

How about:

  "Utilities for IP based Geo-blocking/routing with IPFW"


Best regards

Rolf