- If you use isolate on a node connection you will continue to receive
- all information from the isolated partner, however you will not pass
- any information back to the isolated node. There are times when you
- would like to forward only spots across a link (maybe during a contest
- for example). To do this, isolate the node in the normal way and put
- in a filter in the /spider/filter/spots directory to override the
- isolate. This filter can be very simple and consists of just one line
- ....
-
-
-
- $in = [
- [ 1, 0, 'd', 0, 3] # The last figure (3) is the hop count
- ];
-
-
-
-
-
- There is a lot more on filtering in the next section.
-
-
- 6\b6.\b. F\bFi\bil\blt\bte\ber\bri\bin\bng\bg (\b(O\bOl\bld\bd S\bSt\bty\byl\ble\be u\bup\bpt\bto\bo v\bv1\b1.\b.4\b44\b4)\b)
-
- Filters can be set for spots, announcements and WWV. You will find
- the directories for these under /spider/filter. You will find some
- examples in the directories with the suffix _\b._\bi_\bs_\bs_\bu_\be. There are two
- types of filter, one for incoming information and one for outgoing
- information. Outgoing filters are in the form _\bC_\bA_\bL_\bL_\bS_\bI_\bG_\bN_\b._\bp_\bl and
- incoming filters are in the form _\bi_\bn_\b__\bC_\bA_\bL_\bL_\bS_\bI_\bG_\bN_\b._\bp_\bl. Filters can be set
- for both nodes and users.
-
-
- All filters work in basically the same way. There are several
- elements delimited by commas. There can be many lines in the filter
- and they are read from the top by the program. When writing a filter
- you need to think carefully about just what you want to achieve. You
- are either going to write a filter to _\ba_\bc_\bc_\be_\bp_\bt or to _\br_\be_\bj_\be_\bc_\bt. Think of a
- filter as having 2 main elements. For a reject filter, you would have
- a line or multiple lines rejecting the things you do not wish to
- receive and then a default line accepting everything else that is not
- included in the filter. Likewise, for an accept filter, you would
- have a line or multiple lines accepting the things you wish to receive
- and a default line rejecting everthing else.
-
-
- In the example below, a user requires a filter that would only return
- SSB spots posted in Europe on the HF bands. This is achieved by first
- rejecting the CW section of each HF band and rejecting all of VHF, UHF
- etc based on frequency. Secondly, a filter rule is set based on CQ
- zones to only accept spots posted in Europe. Lastly, a default filter
- rule is set to reject anything outside the filter.
-
-
-
- $in = [
- [ 0, 0, 'r', # reject all CW spots
- [
- 1800.0, 1850.0,
- 3500.0, 3600.0,
- 7000.0, 7040.0,
- 14000.0, 14100.0,
- 18068.0, 18110.0,
- 21000.0, 21150.0,
- 24890.0, 24930.0,
- 28000.0, 28180.0,
- 30000.0, 49000000000.0,
- ] ,1 ],
- [ 1, 11, 'n', [ 14, 15, 16, 20, 33, ], 15 ], #accept EU
- [ 0, 0, 'd', 0, 1 ], # 1 = want, 'd' = everything else
- ];
-
-
-
-
-
- The actual elements of each filter are described more fully in the
- following sections.
-
-
- 6\b6.\b.1\b1.\b. S\bSp\bpo\bot\bts\bs
-
- The elements of the Spot filter are ....
-
-
-
- [action, field_no, sort, possible_values, hops]
-
-
-
-
-
- There are 3 elements here to look at. Firstly, the action element.
- This is very simple and only 2 possible states exist, accept (1) or
- drop (0).
-
- The second element is the field_no. There are 13 possiblities to
- choose from here ....
-
-
-
- 0 = frequency
- 1 = call
- 2 = date in unix format
- 3 = comment
- 4 = spotter
- 5 = spotted dxcc country
- 6 = spotter's dxcc country
- 7 = origin
- 8 = spotted itu
- 9 = spotted cq
- 10 = spotter's itu
- 11 = spotter's cq
- 12 = callsign of the channel on which the spot has appeared
-
-
-
-
-
- The third element tells us what to expect in the fourth element.
- There are 4 possibilities ....
-
-
-
- n - numeric list of numbers e.g. [ 1,2,3 ]
- r - ranges of pairs of numbers e.g. between 2 and 4 or 10 to 17 - [ 2,4, 10,17 ]
- a - an alphanumeric regex
- d - the default rule
-
-
-
-
-
- The fifth element is simply the hops to set in this filter. This
- would only be used if the filter was for a node of course and
- overrides the hop count in hop_table.pl.
-
-
- So, let's look at an example spot filter. It does not matter in the
- example who the filter is to be used for. So, what do we need in the
- filter? We need to filter the spots the user/node requires and also
- set a default rule for anything else outside the filter. Below is a
- simple filter that stops spots arriving from outside Europe.
-
-
-
- $in = [
- [ 0, 4, 'a', '^(K|N|A|W|VE|VA|J)'], # 0 = drop, 'a' = alphanumeric
- [ 1, 0, 'd', 0, 1 ], # 1 = want, 'd' = everything else
- ];
-
-
-
-
-
- So the filter is wrapped in between a pair of square brackets. This
- tells Spider to look in between these limits. Then each line is
- contained within its own square brackets and ends with a comma. Lets
- look carefully at the first line. The first element is 0 (drop).
- Therefore anything we put on this line will not be accepted. The next
- element is 4. This means we are filtering by the spotter. The third
- element is the letter "a" which tells the program to expect an
- alphanumeric expression in the fourth element. The fourth element is
- a list of letters separated by the pipe symbol.
-
-
- What this line does is tell the program to drop any spots posted by
- anyone in the USA, Canada or Japan.
-
-
- The second line is the default rule for anything else. The "d" tells
- us this and the line simply reads... accept anything else.
-
-
- You can add as many lines as you need to complete the filter but if
- there are several lines of the same type it is neater to enclose them
- all as one line. An example of this is where specific bands are set.
- We could write this like this ....
-
-
-
- [ 0,0,'r',[1800.0, 2000.0], 1],
- [ 0,0,'r',[10100.0, 10150.0], 1],
- [ 0,0,'r',[14000.0, 14350.0], 1],
- [ 0,0,'r',[18000.0, 18200.0], 1],
-
-
-
-
-
- But the line below achieves the same thing and is more efficient ....
-
-
-
- [ 0, 0, 'r',
- [
- 1800.0, 2000.0, # top band
- 10100.0, 10150.0, # WARC
- 14000.0, 14350.0, # 20m
- 18000.0, 18200.0, # WARC
- [ ,1 ],
-
-
-
-
-
-
- 6\b6.\b.2\b2.\b. A\bAn\bnn\bno\bou\bun\bnc\bce\bem\bme\ben\bnt\bts\bs
-
-
-
-
- # This is an example announce or filter allowing only West EU announces
- #
- # The element list is:-
- # 0 - callsign of announcer
- # 1 - destination * = all, <callsign> = routed to the node
- # 2 - text
- # 3 - * - sysop, <some text> - special list eg 6MUK, ' ', normal announce
- # 4 - origin
- # 5 - 0 - announce, 1 - wx
- # 6 - channel callsign (the interface from which this spot came)
-
- $in = [
- [ 1, 0, 'a', '^(P[ABCDE]|DK0WCY|G|M|2|EI|F|ON)' ],
- [ 0, 0, 'd', 0 ]
- ];
-
- In this example, only the prefixes listed will be allowed. It is
- possible to be quite specific. The Dutch prefix "P" is followed by
- several secondary identifiers which are allowed. So, in the example,
- "PA" or "PE" would be ok but not "PG". It is even possible to allow
- information from a single callsign. In the example this is DK0WCY, to
- allow the posting of his Aurora Beacon.
-
-
- 6\b6.\b.3\b3.\b. W\bWW\bWV\bV
-
-
-
-
- # This is an example WWV filter
- #
- # The element list is:-
- # 0 - nominal unix date of spot (ie the day + hour:13)
- # 1 - the hour
- # 2 - SFI
- # 3 - K
- # 4 - I
- # 5 - text
- # 6 - spotter
- # 7 - origin
- # 8 - incoming interface callsign
-
- # this one doesn't filter, it just sets the hop count to 6 and is
- # used mainly just to override any isolation from WWV coming from
- # the internet.
-
- $in = [
- [ 1, 0, 'd', 0, 6 ]
- ];
-
-
-
-
-
- It should be noted that the filter will start to be used only once a
- user/node has logged out and back in again.
-
- I am not going to spend any more time on these filters now as they
- will become more "comprehensive" in the near future.
-
-
- 7\b7.\b. F\bFi\bil\blt\bte\ber\bri\bin\bng\bg (\b(N\bNe\bew\bw S\bSt\bty\byl\ble\be v\bv1\b1.\b.4\b45\b5 a\ban\bnd\bd l\bla\bat\bte\ber\br)\b)
-
- 7\b7.\b.1\b1.\b. G\bGe\ben\bne\ber\bra\bal\bl f\bfi\bil\blt\bte\ber\br r\bru\bul\ble\bes\bs
-
- Upto v1.44 it was not possible for the user to set their own filters.
- From v1.45 though that has all changed. It is now possible to set
- filters for just about anything you wish. If you have just updated
- from an older version of DXSpider you will need to update your new
- filters. You do not need to do anything with your old filters, they
- will be renamed as you update.
-
-
- There are 3 basic commands involved in setting and manipulating
- filters. These are _\ba_\bc_\bc_\be_\bp_\bt, _\br_\be_\bj_\be_\bc_\bt and _\bc_\bl_\be_\ba_\br. 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 up to 10 lines in it. You do this using, for example ...
-
- accept/spots .....
- reject/spots .....
-
-
-
-
- where ..... are the specific commands for that type of filter. There
- are filters for spots, wwv, announce, wcy and (for sysops) connects.
- See each different accept or reject command reference for more
- details.
-
- There is also a command to clear out one or more lines in a filter.
- They are ...
-
-
-
- clear/spots 1
- clear/spots all
-
-
-
-
- There is clear/xxxx command for each type of filter.
-
-
- and you can check that your filters have worked by the command ...
-
-
-
-
- show/filter
-
-
-
-
-
- For now we are going to use spots for the examples, but you can apply
- the same principles to all types of filter.
-
-
- 7\b7.\b.2\b2.\b. T\bTy\byp\bpe\bes\bs o\bof\bf f\bfi\bil\blt\bte\ber\br
-
- There are two main types of filter, _\ba_\bc_\bc_\be_\bp_\bt or _\br_\be_\bj_\be_\bc_\bt. You can use
- either to achieve the result you want dependent on your own preference
- and which is more simple to do. It is pointless writing 8 lines of
- reject filters when 1 accept filter would do the same thing! Each
- filter has 10 lines (of any length) which are tried in order. If a
- line matches then the action you have specified is taken (ie reject
- means ignore it and accept means take it)
-
-
- If you specify reject filters, then any lines that arrive that match
- the filter will be dumped but all else will be accepted. If you use
- an accept filter, then ONLY the lines in the filter will be accepted
- and all else will be dumped. For example if you have a single line
- _\ba_\bc_\bc_\be_\bp_\bt filter ...
-
-
-
- accept/spots on vhf and (by_zone 14,15,16 or call_zone 14,15,16)
-
-
-
-
- then you will _\bO_\bN_\bL_\bY get VHF spots _\bf_\br_\bo_\bm or _\bt_\bo CQ zones 14, 15 and 16.
-
- If you set a reject filter like this ...
-
-
-
- reject/spots on hf/cw
-
-
-
-
- Then you will get everything _\bE_\bX_\bC_\bE_\bP_\bT HF CW spots. You could make this
- single filter even more flexible. For example, if you are interested
- in IOTA and will work it even on CW even though normally you are not
- interested in CW, then you could say ...
-
-
-
- reject/spots on hf/cw and not info iota
-
-
-
-
- But in that case you might only be interested in iota and say:-
-
-
-
- accept/spots not on hf/cw or info iota
-
-
-
-
- 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
- same line) but don't attempt this until you are sure you know what you
- are doing!
-
-
- You can arrange your filter lines into logical units, either for your
- own understanding or simply convenience. Here is an example ...
-
-
-
- reject/spots 1 on hf/cw
- reject/spots 2 on 50000/1400000 not (by_zone 14,15,16 or call_zone 14,15,16)
-
-
-
-
- What this does is to ignore all HF CW spots and also rejects any spots
- on VHF which don't either originate or spot someone in Europe.
-
-
- This is an example where you would use a line number (1 and 2 in this
- case), if you leave the digit out, the system assumes '1'. Digits
- '0'-'9' are available. This make it easier to see just what filters
- you have set. It also makes it more simple to remove individual
- filters, during a contest for example.
-
-
- You will notice in the above example that the second line has
- brackets. Look at the line logically. You can see there are 2
- separate sections to it. We are saying reject spots that are VHF or
- above _\bA_\bP_\bA_\bR_\bT from those in zones 14, 15 and 16 (either spotted there or
- 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
-
-
-
-
- The simple way to remember this is, if you use OR - use brackets.
- Whilst we are here CASE is not important. 'And BY_Zone' is just the
- same as 'and by_zone'.
-
- As mentioned earlier, setting several filters can be more flexible
- than simply setting one complex one. Doing it in this way means that
- if you want to alter your filter you can just redefine or remove one
- or more lines of it or one line. For example ...
-
-
-
- reject/spots 1 on hf/ssb
-
-
-
-
- would redefine our earlier example, or
-
-
-
- clear/spots 1
-
-
-
-
- To remove all the filter lines in the spot filter ...
-
-
-
- clear/spots all
-
-
-
-
-
- 7\b7.\b.3\b3.\b. F\bFi\bil\blt\bte\ber\br o\bop\bpt\bti\bio\bon\bns\bs
-
- You can filter in several different ways. The options are listed in
- the various helpfiles for accept, reject and filter.
-
-
- 7\b7.\b.4\b4.\b. D\bDe\bef\bfa\bau\bul\blt\bt f\bfi\bil\blt\bte\ber\brs\bs
-
- Sometimes all that is needed is a general rule for node connects.
- This can be done with a node_default filter. This rule will always be
- followed, even if the link is isolated, unless another filter is set
- specifically. Default rules can be set for nodes and users. They can
- be set for spots, announces, WWV and WCY. They can also be used for
- hops. An example might look like this ...
-
-
-
- accept/spot node_default by_zone 14,15,16,20,33
- set/hops node_default spot 50
-
-
-
-
- This filter is for spots only, you could set others for announce, WWV
- and WCY. This filter would work for ALL nodes unless a specific
- filter is written to override it for a particular node. You can also
- set a user_default should you require. It is important to note that
- default filters should be considered to be "connected". By this I
- mean that should you override the default filter for spots, you need
- to add a rule for the hops for spots also.
-
-
- 7\b7.\b.5\b5.\b. A\bAd\bdv\bva\ban\bnc\bce\bed\bd f\bfi\bil\blt\bte\ber\bri\bin\bng\bg
-
- Once you are happy with the results you get, you may like to
- experiment.
-
-
- The previous example that filters hf/cw spots and accepts vhf/uhf
- spots from EU can be written with a mixed filter, for example ...
-
-
-
- rej/spot on hf/cw
- acc/spot on 0/30000
- acc/spot 2 on 50000/1400000 and (by_zone 14,15,16 or call_zone 14,15,16)
-
-
-
-
- Note that the first filter has not been specified with a number. This
- will automatically be assumed to be number 1. In this case, we have
- said _\br_\be_\bj_\be_\bc_\bt _\ba_\bl_\bl _\bH_\bF _\bs_\bp_\bo_\bt_\bs _\bi_\bn _\bt_\bh_\be _\bC_\bW _\bs_\be_\bc_\bt_\bi_\bo_\bn _\bo_\bf _\bt_\bh_\be _\bb_\ba_\bn_\bd_\bs _\bb_\bu_\bt _\ba_\bc_\bc_\be_\bp_\bt _\ba_\bl_\bl
- _\bo_\bt_\bh_\be_\br_\bs _\ba_\bt _\bH_\bF_\b. _\bA_\bl_\bs_\bo _\ba_\bc_\bc_\be_\bp_\bt _\ba_\bn_\by_\bt_\bh_\bi_\bn_\bg _\bi_\bn _\bV_\bH_\bF _\ba_\bn_\bd _\ba_\bb_\bo_\bv_\be _\bs_\bp_\bo_\bt_\bt_\be_\bd _\bi_\bn _\bo_\br _\bb_\by
- _\bo_\bp_\be_\br_\ba_\bt_\bo_\br_\bs _\bi_\bn _\bt_\bh_\be _\bz_\bo_\bn_\be_\bs _\b1_\b4_\b, _\b1_\b5 _\ba_\bn_\bd _\b1_\b6. Each filter slot actually has a
- 'reject' slot and an 'accept' slot. The reject slot is executed BEFORE
- the accept slot.
-
-
- It was mentioned earlier that after a reject test that doesn't match,
- the default for following tests is 'accept', the reverse is true for
- 'accept'. In the example what happens is that the reject is executed
- first, any non hf/cw spot is passed to the accept line, which lets
- through everything else on HF. The next filter line lets through just
- VHF/UHF spots from EU.
-
-
-
- 8\b8.\b. O\bOt\bth\bhe\ber\br f\bfi\bil\blt\bte\ber\brs\bs
-
- 8\b8.\b.1\b1.\b. F\bFi\bil\blt\bte\ber\bri\bin\bng\bg M\bMa\bai\bil\bl
-
- In the /spider/msg directory you will find a file called
- badmsg.pl.issue. Rename this to badmsg.pl and edit the file. The
- original looks something like this ....
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- # the list of regexes for messages that we won't store having
- # received them (bear in mind that we must receive them fully before
- # we can bin them)
-
-
- # The format of each line is as follows
-
- # type source pattern
- # P/B/F T/F/O/S regex
-
- # type: P - private, B - bulletin (msg), F - file (ak1a bull)
- # source: T - to field, F - from field, O - origin, S - subject
- # pattern: a perl regex on the field requested
-
- # Currently only type B and P msgs are affected by this code.
- #
- # The list is read from the top down, the first pattern that matches
- # causes the action to be taken.
-
- # The pattern can be undef or 0 in which case it will always be selected
- # for the action specified
-
-
-
- package DXMsg;
-
- @badmsg = (
- );
-
-
-
-
-
- I think this is fairly self explanatory. It is simply a list of
- subject headers that we do not want to pass on to either the users of
- the cluster or the other cluster nodes that we are linked to. This is
- usually because of rules and regulations pertaining to items for sale
- etc in a particular country.
-
-
- 8\b8.\b.2\b2.\b. F\bFi\bil\blt\bte\ber\bri\bin\bng\bg D\bDX\bX c\bca\bal\bll\blo\bou\but\bts\bs