From: minima Date: Sat, 8 Sep 2001 22:43:51 +0000 (+0000) Subject: update the docs on filtering X-Git-Tag: R_1_48~40 X-Git-Url: http://dxcluster.net/gitweb/gitweb.cgi?a=commitdiff_plain;h=71ce25e28013877858408ae610c9eaf6d1fb001c;p=spider.git update the docs on filtering --- diff --git a/Changes b/Changes index aa2ffe23..13ef5838 100644 --- a/Changes +++ b/Changes @@ -1,3 +1,5 @@ +08Sep01======================================================================= +1. Update the sgml docs on filtering a bit. 06Sep01======================================================================= 1. prevent nodes appearing as users from incoming PC16s 2. Change ping averaging to be like TCP and become a smoothed RTT. diff --git a/cmd/set/var.pl b/cmd/set/var.pl index 1870d1a6..d2ea1d13 100644 --- a/cmd/set/var.pl +++ b/cmd/set/var.pl @@ -10,7 +10,7 @@ my ($self, $line) = @_; return (1, $self->msg('e5')) if $self->priv < 9 || $self->remotecmd; -my ($var, $rest) = split /\s+/, $line, 2; +my ($var, $rest) = split /=|\s+/, $line, 2; $rest =~ s/^=\s*//; Log('DXCommand', $self->call . " set $var = $rest" ); eval "$var = $rest"; diff --git a/cmd/show/var.pl b/cmd/show/var.pl index b09193c2..3f071571 100644 --- a/cmd/show/var.pl +++ b/cmd/show/var.pl @@ -15,9 +15,9 @@ my $f; my @out; foreach $f (@f) { - print "\$f = $f\n"; +# print "\$f = $f\n"; my $var = eval "$f"; - if ($var) { + if (defined $var) { my $dd = Data::Dumper->new([ $var ], [ "$f" ]); $dd->Indent(1); $dd->Quotekeys(0); diff --git a/html/adminmanual-1.html b/html/adminmanual-1.html index 78a3afcc..34f3fb0c 100644 --- a/html/adminmanual-1.html +++ b/html/adminmanual-1.html @@ -31,30 +31,45 @@ these do not have any protection from loops. Certainly AK1A does not handle loops well at all. It is therefore necessary to have some form of protection for these nodes.

-

This is achieved by using filtering on a route basis. There is a -default setting to help to protect the network, especially useful for new -and inexperienced SysOps. The idea is simple. When Spider is started -for the first time and a connection is made to or from another node, -the default is to only send the nodes you already have that are in your -own zone. For example, in the UK the default setting would be to send -only UK nodes to any connection. This can be filtered further (down to -a single node if needed) or expanded as required. -

+

In fact DXSpider has had a simple system for some time which is called +isolation. This is similar to what, in other systems such as +clx, is called passive mode. A more detailed explanation +of isolation is given further below. This system is still available +and, for simple networks, is probably all that you need. +

+

The new functionality introduced in version 1.48 is filtering the node +and user protocol frames on a "per interface" basis. We call this +route filtering. This is used instead of +isolation. +

+

What this really means is that you can control more or less completely +which PC protocol frames, to do with user and node management, pass to +each of your partner nodes. You can also limit what comes into your +node from your partners. You can even control the settings that your +partner node has for the routing information that it sends to you +(using the rcmd command).

1.2 Route Filters

-

As mentioned in the introduction, a default setting exists. If this is -all you want to use then that is fine, you have nothing else to do. -However, if you want to make any alterations then you need to know -a bit about filters. -

-

It is possible to reset the default setting for node connections should -you wish to do so, however this can be dangerous to the network unless -you have some experience in how all this works.... be careful! It is -also possible to change settings for one connection only. You can, -therefore, have many different filters set dependent on the amount of -node links you have. +

Initially when route filters were being tested we generated a +"default" filter. Unfortunately it quickly became apparent that this +might suit the UK cluster network but didn't really fit anybody else. +However using a default filter is an appropriate thing to do. How, is +explained further on. +

+

The first thing that you must do is determine whether you need to do route filtering at all. If you are a "normal" node with two or three partners +and you arranged in an "official" non-looping tree type network, then you do +not need to do route filtering and you will feel a lot better for not +getting involved. If you are successfully using isolation then you +also probably don't need to use route filtering. +

+

You will only require this functionality if you are +"well-connected". What that means is that you are connected to several +different parts of (say) the EU cluster and, at the same time, also +connected to two or three places in the US which, in turn are +connected back to the EU. This is called a "loop" and if you are +seriously looped then you need filtering.

I should at this stage give a little bit of background on filters. All the filters in Spider work in basically the same way. You can either @@ -62,23 +77,31 @@ accept or reject various options in order to create the filter rules you wish to achieve. Some filters are user settable, others can only be altered by the sysop. Route filtering can only be done by the sysop.

-

1.3 The default_node filter +

+Anyway, without further discouragement, let me start the process +of explanation. +

+

1.3 The node_default filter

-

As discussed previously, a default setting exists that only sends nodes -from your own zone. This can be overridden by using the default_node -filter option like this ... +

All normal systems should have a default routing filter and it should +usually be set to send only the normal, unlooped, view of your +"national" network. Here in the UK that means nodes from the UK and +Eire, in EU it is more complex as the networks there grew up in a more +intertwined way. +

+

+The generic commands are:- 

-reject/route default_node <filter_option>
+reject/route node_default <filter_option>
 
 or
 
-accept/route default_node <filter_option>
+accept/route node_default <filter_option>
-

where filter_option is one of the following ...

@@ -87,16 +110,67 @@ call <prefixes> call_dxcc <numbers> call_itu <numbers> call_zone <numbers> -origin <prefixes> -origin_dxcc <numbers> -origin_itu <numbers> -origin_zone <numbers> +channel <prefixes> +channel_dxcc <numbers> +channel_itu <numbers> +channel_zone <numbers>
-

Please be careful if you alter this setting, it will affect ALL your links!

+

For the default routing filter then you have two real choices: either +a "national" view or the "safe" option of only your own +callsign. Examples of each (for my node: GB7DJK) are:- +

+

+
+acc/route node_default call_dxcc 61,38
+acc/route node_default call gb7djk
+
+
+

GB7DJK uses the first of these. The DXCC countries can be obtained from the +show/prefix command. +

+

The example filters shown control output TO all your +partner nodes unless they have a specific filter applied to them (see +next section). +

+

It is also possible to control the incoming routing +information that you are prepared to accept FROM your partner +nodes. The reason this is necessary is to make sure that stuff like +mail, pings and similar commands a) go down the correct links and b) +don't loop around excessively. Again using GB7DJK as an example a typical +default input filter would be something like: +

+

+
+rej/route node_default input call_dxcc 61,38 and not channel_dxcc 61,38
+
+
+

What this does is accept node and user information for our national +network from nodes that are in our national network, but rejects such +information from anyone else. Although it doesn't explicitly say so, +by implication, any other node information (not from the UK and Eire) +is accepted. +

+

As I imagine it will take a little while to get one's head around all of this you +can study the effect of any rules that you try by watching the debug output +after having done:- +

+

+
+set/debug filter
+
+
+

After you have got tired of that, to put it back the way it was:- +

+

+
+unset/debug filter
+
+
+

1.4 General route filtering

@@ -113,31 +187,41 @@ accept/route <node_call> <filter_option>

-

where filter_option is one of the following ... +

Here are some examples of route filters ... 

-call <prefixes>
-call_dxcc <numbers>
-call_itu <numbers>
-call_zone <numbers>
-origin <prefixes>
-origin_dxcc <numbers>
-origin_itu <numbers>
-origin_zone <numbers>
+rej/route gb7djk call_dxcc 61,38 (everything except  UK+EIRE nodes)
+rej/route all     (equiv to [very] restricted mode)
+acc/route gb7djk call_dxcc 61,38 (send only UK+EIRE nodes)
+acc/route gb7djk call gb7djk     (equiv to SET/ISOLATE)
+

In practice you will either be opening the default filter out for a +partner by defining a specific filter for that callsign:-

-

Here are some examples of route filters ... +

+
+acc/route gb7baa all
+acc/route gb7baa input all
+
+
+

or restricting it quite a lot, in fact making it very nearly like an isolated node, like this:- 

-rej/route gb7djk call_dxcc 61,38 (everything except  UK+EIRE nodes)
-rej/route all     (equiv to [very] restricted mode)
-acc/route gb7djk call_dxcc 61,38 (send only UK+EIRE nodes)
-acc/route gb7djk call gb7djk     (equiv to SET/ISOLATE)
+acc/route pi4ehv-8 call gb7djk
+rej/route pi4ehv-8 input call_dxcc 61,38
+

This last example takes everything except UK and Eire from PI4EHV-8 +but only sends him my local configuration (just a PC19 for GB7DJK and +PC16s for my local users). +

+

It is possible to do much more complex rules, there are up to 10 +accept/reject pairs per callsign per filter. For more information see the +next section. +

1.5 General filter rules

@@ -153,7 +237,7 @@ are accept, reject and clear. First we will look generally at filtering. There are a number of things you can filter in the DXSpider system. They all use the same general mechanism.

-

In general terms you can create a 'reject' or an 'accept' filter which can have +

In general terms you can create a "reject" or an "accept" filter which can have up to 10 lines in it. You do this using, for example ...

diff --git a/html/adminmanual.html b/html/adminmanual.html index f986c0d8..0e84bafb 100644 --- a/html/adminmanual.html +++ b/html/adminmanual.html @@ -25,7 +25,7 @@ Contents
  • 1.1 Introduction
  • 1.2 Route Filters -
  • 1.3 The default_node filter +
  • 1.3 The node_default filter
  • 1.4 General route filtering
  • 1.5 General filter rules
  • 1.6 Types of filter diff --git a/sgml/adminmanual.sgml b/sgml/adminmanual.sgml index cc6ba498..d91dab68 100644 --- a/sgml/adminmanual.sgml +++ b/sgml/adminmanual.sgml @@ -36,31 +36,49 @@ handle loops well at all. It is therefore necessary to have some form of protection for these nodes.

    -This is achieved by using filtering on a route basis. There is a -default setting to help to protect the network, especially useful for new -and inexperienced SysOps. The idea is simple. When Spider is started -for the first time and a connection is made to or from another node, -the default is to only send the nodes you already have that are in your -own zone. For example, in the UK the default setting would be to send -only UK nodes to any connection. This can be filtered further (down to -a single node if needed) or expanded as required. - +In fact DXSpider has had a simple system for some time which is called +isolation. This is similar to what, in other systems such as +clx, is called passive mode. A more detailed explanation +of isolation is given further below. This system is still available +and, for simple networks, is probably all that you need. + +

    +The new functionality introduced in version 1.48 is filtering the node +and user protocol frames on a "per interface" basis. We call this +route filtering. This is used instead of +isolation. + +

    +What this really means is that you can control more or less completely +which PC protocol frames, to do with user and node management, pass to +each of your partner nodes. You can also limit what comes into your +node from your partners. You can even control the settings that your +partner node has for the routing information that it sends to you +(using the rcmd command). Route Filters -

    -As mentioned in the introduction, a default setting exists. If this is -all you want to use then that is fine, you have nothing else to do. -However, if you want to make any alterations then you need to know -a bit about filters. - -

    -It is possible to reset the default setting for node connections should -you wish to do so, however this can be dangerous to the network unless -you have some experience in how all this works.... be careful! It is -also possible to change settings for one connection only. You can, -therefore, have many different filters set dependent on the amount of -node links you have. +

    +Initially when route filters were being tested we generated a +"default" filter. Unfortunately it quickly became apparent that this +might suit the UK cluster network but didn't really fit anybody else. +However using a default filter is an appropriate thing to do. How, is +explained further on. + +

    +The first thing that you must do is determine whether you need to do route filtering at all. If you are a "normal" node with two or three partners +and you arranged in an "official" non-looping tree type network, then you do +not need to do route filtering and you will feel a lot better for not +getting involved. If you are successfully using isolation then you +also probably don't need to use route filtering. + +

    +You will only require this functionality if you are +"well-connected". What that means is that you are connected to several +different parts of (say) the EU cluster and, at the same time, also +connected to two or three places in the US which, in turn are +connected back to the EU. This is called a "loop" and if you are +seriously looped then you need filtering.

    I should at this stage give a little bit of background on filters. All @@ -69,22 +87,30 @@ accept or reject various options in order to create the filter rules you wish to achieve. Some filters are user settable, others can only be altered by the sysop. Route filtering can only be done by the sysop. -The default_node filter +

    +Anyway, without further discouragement, let me start the process +of explanation. + +The node_default filter

    -As discussed previously, a default setting exists that only sends nodes -from your own zone. This can be overridden by using the default_node -filter option like this ... +All normal systems should have a default routing filter and it should +usually be set to send only the normal, unlooped, view of your +"national" network. Here in the UK that means nodes from the UK and +Eire, in EU it is more complex as the networks there grew up in a more +intertwined way. + +

    +The generic commands are:- -reject/route default_node <filter_option> +reject/route node_default <filter_option> or -accept/route default_node <filter_option> +accept/route node_default <filter_option> -

    where filter_option is one of the following ... @@ -92,16 +118,66 @@ call <prefixes> call_dxcc <numbers> call_itu <numbers> call_zone <numbers> -origin <prefixes> -origin_dxcc <numbers> -origin_itu <numbers> -origin_zone <numbers> +channel <prefixes> +channel_dxcc <numbers> +channel_itu <numbers> +channel_zone <numbers> -

    Please be careful if you alter this setting, it will affect ALL your links! +

    +For the default routing filter then you have two real choices: either +a "national" view or the "safe" option of only your own +callsign. Examples of each (for my node: GB7DJK) are:- + + +acc/route node_default call_dxcc 61,38 +acc/route node_default call gb7djk + + +GB7DJK uses the first of these. The DXCC countries can be obtained from the +show/prefix command. + +

    +The example filters shown control output TO all your +partner nodes unless they have a specific filter applied to them (see +next section). + +

    +It is also possible to control the incoming routing +information that you are prepared to accept FROM your partner +nodes. The reason this is necessary is to make sure that stuff like +mail, pings and similar commands a) go down the correct links and b) +don't loop around excessively. Again using GB7DJK as an example a typical +default input filter would be something like: + + +rej/route node_default input call_dxcc 61,38 and not channel_dxcc 61,38 + + +What this does is accept node and user information for our national +network from nodes that are in our national network, but rejects such +information from anyone else. Although it doesn't explicitly say so, +by implication, any other node information (not from the UK and Eire) +is accepted. + +

    +As I imagine it will take a little while to get one's head around all of this you +can study the effect of any rules that you try by watching the debug output +after having done:- + + +set/debug filter + + +After you have got tired of that, to put it back the way it was:- + + +unset/debug filter + + General route filtering

    @@ -116,20 +192,6 @@ or accept/route <node_call> <filter_option> -

    -where filter_option is one of the following ... - - -call <prefixes> -call_dxcc <numbers> -call_itu <numbers> -call_zone <numbers> -origin <prefixes> -origin_dxcc <numbers> -origin_itu <numbers> -origin_zone <numbers> - -

    Here are some examples of route filters ... @@ -140,6 +202,31 @@ acc/route gb7djk call_dxcc 61,38 (send only UK+EIRE nodes) acc/route gb7djk call gb7djk (equiv to SET/ISOLATE) +In practice you will either be opening the default filter out for a +partner by defining a specific filter for that callsign:- + + +acc/route gb7baa all +acc/route gb7baa input all + + +or restricting it quite a lot, in fact making it very nearly like an isolated node, like this:- + + +acc/route pi4ehv-8 call gb7djk +rej/route pi4ehv-8 input call_dxcc 61,38 + + +This last example takes everything except UK and Eire from PI4EHV-8 +but only sends him my local configuration (just a PC19 for GB7DJK and +PC16s for my local users). + +

    +It is possible to do much more complex rules, there are up to 10 +accept/reject pairs per callsign per filter. For more information see the +next section. + + General filter rules

    @@ -156,7 +243,7 @@ generally at filtering. There are a number of things you can filter in the DXSpider system. They all use the same general mechanism.

    -In general terms you can create a 'reject' or an 'accept' filter which can have +In general terms you can create a "reject" or an "accept" filter which can have up to 10 lines in it. You do this using, for example ... diff --git a/txt/adminmanual.txt b/txt/adminmanual.txt index 0a9b21d6..21590b7a 100644 --- a/txt/adminmanual.txt +++ b/txt/adminmanual.txt @@ -68,7 +68,7 @@ 1.1 Introduction 1.2 Route Filters - 1.3 The default_node filter + 1.3 The node_default filter 1.4 General route filtering 1.5 General filter rules 1.6 Types of filter @@ -285,33 +285,49 @@ of protection for these nodes. - This is achieved by using filtering on a route basis. There is a - default setting to help to protect the network, especially useful for - new and inexperienced SysOps. The idea is simple. When Spider is - started for the first time and a connection is made to or from another - node, the default is to only send the nodes you already have that are - in your own zone. For example, in the UK the default setting would be - to send only UK nodes to any connection. This can be filtered further - (down to a single node if needed) or expanded as required. + In fact DXSpider has had a simple system for some time which is called + isolation. This is similar to what, in other systems such as clx, is + called passive mode. A more detailed explanation of isolation is given + further below. This system is still available and, for simple + networks, is probably all that you need. + The new functionality introduced in version 1.48 is filtering the node + and user protocol frames on a "per interface" basis. We call this + route filtering. This is used instead of isolation. + + + What this really means is that you can control more or less completely + which PC protocol frames, to do with user and node management, pass to + each of your partner nodes. You can also limit what comes into your + node from your partners. You can even control the settings that your + partner node has for the routing information that it sends to you + (using the rcmd command). + 1.2. Route Filters - As mentioned in the introduction, a default setting exists. If this - is all you want to use then that is fine, you have nothing else to do. - However, if you want to make any alterations then you need to know a - bit about filters. + Initially when route filters were being tested we generated a + "default" filter. Unfortunately it quickly became apparent that this + might suit the UK cluster network but didn't really fit anybody else. + However using a default filter is an appropriate thing to do. How, is + explained further on. - It is possible to reset the default setting for node connections - should you wish to do so, however this can be dangerous to the network - unless you have some experience in how all this works.... be careful! - It is also possible to change settings for one connection only. You - can, therefore, have many different filters set dependent on the - amount of node links you have. + The first thing that you must do is determine whether you need to do + route filtering at all. If you are a "normal" node with two or three + partners and you arranged in an "official" non-looping tree type + network, then you do not need to do route filtering and you will feel + a lot better for not getting involved. If you are successfully using + isolation then you also probably don't need to use route filtering. + You will only require this functionality if you are "well-connected". + What that means is that you are connected to several different parts + of (say) the EU cluster and, at the same time, also connected to two + or three places in the US which, in turn are connected back to the EU. + This is called a "loop" and if you are seriously looped then you need + filtering. I should at this stage give a little bit of background on filters. All the filters in Spider work in basically the same way. You can either accept or reject various options in order to create the filter @@ -320,20 +336,30 @@ sysop. - 1.3. The default_node filter - As discussed previously, a default setting exists that only sends - nodes from your own zone. This can be overridden by using the - default_node filter option like this ... + Anyway, without further discouragement, let me start the process of + explanation. + 1.3. The node_default filter - reject/route default_node + All normal systems should have a default routing filter and it should + usually be set to send only the normal, unlooped, view of your + "national" network. Here in the UK that means nodes from the UK and + Eire, in EU it is more complex as the networks there grew up in a more + intertwined way. + + + + The generic commands are:- - or - accept/route default_node + reject/route node_default + + or + + accept/route node_default @@ -346,11 +372,10 @@ call_dxcc call_itu call_zone - origin - origin_dxcc - origin_itu - origin_zone - + channel + channel_dxcc + channel_itu + channel_zone @@ -359,6 +384,66 @@ links! + For the default routing filter then you have two real choices: either + a "national" view or the "safe" option of only your own callsign. + Examples of each (for my node: GB7DJK) are:- + + + + acc/route node_default call_dxcc 61,38 + acc/route node_default call gb7djk + + + GB7DJK uses the first of these. The DXCC countries can be obtained + from the show/prefix command. + + + The example filters shown control output TO all your partner nodes + unless they have a specific filter applied to them (see next section). + + + It is also possible to control the incoming routing information that + you are prepared to accept FROM your partner nodes. The reason this is + necessary is to make sure that stuff like mail, pings and similar + commands a) go down the correct links and b) don't loop around + excessively. Again using GB7DJK as an example a typical default input + filter would be something like: + + + + rej/route node_default input call_dxcc 61,38 and not channel_dxcc 61,38 + + + + + What this does is accept node and user information for our national + network from nodes that are in our national network, but rejects such + information from anyone else. Although it doesn't explicitly say so, + by implication, any other node information (not from the UK and Eire) + is accepted. + + + As I imagine it will take a little while to get one's head around all + of this you can study the effect of any rules that you try by watching + the debug output after having done:- + + + + set/debug filter + + + + + After you have got tired of that, to put it back the way it was:- + + + + unset/debug filter + + + + + 1.4. General route filtering Exactly the same rules apply for general route filtering. You would @@ -375,35 +460,48 @@ + Here are some examples of route filters ... - where filter_option is one of the following ... + rej/route gb7djk call_dxcc 61,38 (everything except UK+EIRE nodes) + rej/route all (equiv to [very] restricted mode) + acc/route gb7djk call_dxcc 61,38 (send only UK+EIRE nodes) + acc/route gb7djk call gb7djk (equiv to SET/ISOLATE) - call - call_dxcc - call_itu - call_zone - origin - origin_dxcc - origin_itu - origin_zone + In practice you will either be opening the default filter out for a + partner by defining a specific filter for that callsign:- - Here are some examples of route filters ... + acc/route gb7baa all + acc/route gb7baa input all - rej/route gb7djk call_dxcc 61,38 (everything except UK+EIRE nodes) - rej/route all (equiv to [very] restricted mode) - acc/route gb7djk call_dxcc 61,38 (send only UK+EIRE nodes) - acc/route gb7djk call gb7djk (equiv to SET/ISOLATE) + + or restricting it quite a lot, in fact making it very nearly like an + isolated node, like this:- + + acc/route pi4ehv-8 call gb7djk + rej/route pi4ehv-8 input call_dxcc 61,38 + + + + + This last example takes everything except UK and Eire from PI4EHV-8 + but only sends him my local configuration (just a PC19 for GB7DJK and + PC16s for my local users). + + + It is possible to do much more complex rules, there are up to 10 + accept/reject pairs per callsign per filter. For more information see + the next section. @@ -423,14 +521,13 @@ the DXSpider system. They all use the same general mechanism. - In general terms you can create a 'reject' or an 'accept' filter which + In general terms you can create a "reject" or an "accept" filter which can have up to 10 lines in it. You do this using, for example ... - - accept/spots ..... - reject/spots ..... + accept/spots ..... + reject/spots ..... @@ -459,8 +556,7 @@ - - show/filter + show/filter @@ -496,7 +592,6 @@ then you will ONLY get VHF spots from or to CQ zones 14, 15 and 16. - If you set a reject filter like this ... @@ -526,6 +621,7 @@ + which achieves exactly the same thing. You should choose one or the other until you are comfortable with the way it works. You can mix them if you wish (actually you can have an accept AND a reject on the @@ -562,9 +658,6 @@ originated there). If you did not have the brackets to separate the 2 sections, then Spider would read it logically from the front and see a different expression entirely ... - - - (on 50000/1400000 and by_zone 14,15,16) or call_zone 14,15,16 @@ -592,6 +685,9 @@ clear/spots 1 + + + To remove all the filter lines in the spot filter ... @@ -694,36 +790,6 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - # # hop table construction #