[Dxspider-support] DXSpider mojo branch build 482

Sun Jan 22 11:37:40 GMT 2023

Hi

How are spots issued from my local network (192...) on the local 
interface treated? Will it  be dropped now or in the future?

73

Kjell, SM7GVF

On 2023-01-20 15:41, Dirk Koopman via Dxspider-support wrote:
> There is a new release on the mojo branch.
>
> The main changes that will be of interest are:
>
> 1. There is now a complete implementation of stopping logins from TOR 
> nodes and some other bad IP addresses. I maintain the badip.torexit, 
> badip.torrelay and badip.global files. If you follow the instructions 
> below for your local crontab,  you will keep a current set of 'bad ip 
> addresses'. You can also add your own local bad ip addresses with the 
> set/badip command. But if you think this IP address is a problem, tell 
> the support mailing list and I will add it to the 'global' list, which 
> will be distributed around those nodes that download the master lists.
>
> You will need to install Net::CIDR::Lite to utilise the badip stuff.
>
> 2. There is a mechanism for aliasing localhost on client connections 
> and/or other rfc1918 addresses for more complex node arrangements such 
> as web clusters etc. The default arrangement a simple node with one 
> external ip address will "just work" automatically, once it has either 
> connect to another node, or an external user connects.
>
> This means that sshing into a node, running a console and doing a few 
> dx commands will result in the external address appearing in the 
> routing tables locally and externally automatically. If you have a 
> more complex networking arrangement, please get in touch on here (or 
> privately) for advice.
>
> 3. There is a mechanism that uses information from incoming PC92 A 
> records as well as PC61 spots to "upgrade" PC11 spots into PC61s. 
> There is command 'show/spotstats' (or 'sh/spot' for short) that 
> displays some statistics as to how this is all going where you are in 
> the network. Don't be disheartened if you only see a small percentage 
> of upgrades. It depends very much on how many and which nodes that 
> only send PC11 spots you are connected to. I happen to get upwards of 
> 6% on my test machine, but that means there will be that many fewer 
> for some other node to do.
>
> I expect that there will be questions....
>
> 73 Dirk G1TLH
>
> Here is the Changes file:
>
> 20Jan23=======================================================================
> 1. Add the variable @main::localhost_names to allow other IP addresses to
>    be treated in the same way as localhost in item 1 on 19Jan23 below. 
> NOTE
>    you must include ALL the normal localhost names + any other interface
>    names that you might want to include:
>
>       set/var @main::localhost_names qw(127.0.0.1 ::1 192.168.1.30)
>
>    using the qw() construction is easier than:
>
>       set/var @main::localhost_names ('127.0.0.1', '::1', '192.168.1.30')
>
>    but either will work. You can define as many IP addresses as you 
> like and
>    they can be IPV4 or 6.
>
>    You do NOT need to fiddle with this unless you specifically have more
>    than just the normal definitions of localhost. So for 'normal' 
> nodes with
>    one external interface, you DO NOT NEED TO DO ANY OF THIS.
> 2. Added CTY-3304 prefix data
> 19Jan23=======================================================================
> 1. Introduce aliasing for localhost in DX Spots and outgoing PC92 A 
> records
>    on login. There are two variables which can be set with the alias 
> to use:
>       $main::localhost_alias_ipv4
>       $main::localhost_alias_ipv6
>    These can be set in the /spider/scripts/startup, but this is only
>    necessary if the node has more than one interface, or virtual 
> hosts. If
>    there is ONLY ONE ipv4 and/or ipv6 IP address on the node machine then
>    these variables will be automatically populated on first use. But 
> the SAFE
>    thing to do is to set them in the startup file.
>
>    THIS FEATURE IS EXPERIMENTAL...
> 18Jan23=======================================================================
> 1. Make sure than *every* channel has an IP address. Thank you (I 
> think) Kin
>    for pointing out that PC92 A records were not going out with IP 
> addresses.
>    I'm guessing that other things (like spots) had a similar problem.
> 15Jan23=======================================================================
> 1. Fix strange errors for carp on missing route_*_cache files on startup.
> 14Jan23=======================================================================
> 1. Fixed route PC11 promotions so that a new PC61 is actually 
> generated and
>    also sent instead of the original PC11 (to PC61 capable nodes).
> 13Jan23=======================================================================
> 1. Periodically store Routing tables and, if they are young enough 
> (def: 3hrs)
>    autotically restore them on restart of the node. This will short 
> circuit
>    the need to rebuild the routing tables from scratch on every restart -
>    which is normally for something like software update.
> 2. Fix pc11 debugging stats with the correct figures. Sigh... Also 
> move some
>    of the totals to a different place.
> 3. Add show/spotstats command which gives the current spot statistics 
> shown
>    during pc11 debugging (which means you don't need to set/deb pc11 
> unless
>    you really want that extra noise).
> 12Jan23=======================================================================
> 1. Regularise 'set/debug pc11' output to track all the routes through 
> PC11 and
>    PC61 processing and statistics.
> 11Jan23=======================================================================
> 1. Improve (?) the PC11 -> PC61 upgrading process that delays incoming 
> PC11s
>    for a very short time in the hope that a PC61 will come in to be used
>    instead. It will also upgrade a PC11 if we have an uptodate IP address
>    that has come in from the routing system PC92s. do a 'set/debug 
> pc11' to
>    see it in action.
> 2. I have chosen a definitive list of TOR exits and relays which can be
>    downloaded from http://www.dxspider.net/download/badip.torexit,
> http://www.dxspider.net/download/badip.torrelay and finally, for those IP
>    addresses that are deemed to be 'bad':
> http://www.dxspider.net/download/badip.global. I have added the following
>    lines to my /spider/local_cmd/crontab:
>
> 24 * * * * spawn('cd /spider/local_data; wget -qN 
> http://www.dxspider.net/download/badip.torexit')
> 24 * * * * spawn('cd /spider/local_data; wget -qN 
> http://www.dxspider.net/download/badip.torrelay')
> 24 * * * * spawn('cd /spider/local_data; wget -qN 
> http://www.dxspider.net/download/badip.global')
> 25 * * * * run_cmd('load/badip')
>
>    The tor files are downloaded from 
> https://lists.fissionrelays.net/tor/ at
>    15 minutes past every hour, please would you use some other minute than
>    23 or 24 to get your own local copies.
>
>    A 'set/debug badip' will show you what is being blocked.
> 3. Fix set/badip so that it appends new IP addresses correctly.
> 10Jan23=======================================================================
> 1. Add baddx on incoming callsign in RBN.
> 2. Search for all /spider/local_data/badip.* files to allow more 
> control on
>    which IP addresses are detected. e.g. badip.torexit, badip.torrelay 
> as well
>    as baddx.local. The suffixes, apart from .local (created by 
> set/badip) are
>    completely arbitrary. You can use whichever suffix name you like. 
> This is
>    a more useful arrangement for the ever increasing sources of "bad ip
>    addresses" that we need to deter.
>
>    NOTE: all badip.<suffix> are read only EXCEPT badip.local (which can be
>    altered in real time by the sysop using set/badip <ip address> ...).
>    If one uses periodic crontab jobs to update any other badip.<suffix>
>    files from web resources then don't forget to 'load/badip' afterwards.
> 3. Add a /spider/data/baddx.issue file which can be copied to (or used 
> as a
>    basis to create) /spider/local_data/baddx
> 09Jan23=======================================================================
> 1. Finish implemention of DXCIDR ip address filtering. This works on both
>    logins (treated the same as locked out - i.e. just disconnected) 
> and also
>    with PC61s where these sentences are just dropped. Also attempt to 
> prevent
>    any *following* PC11s with the same data getting through.
>
>    YOU WILL NEED either 'cpanm Net::CIDR::Lite' or debian/ubuntu based 
> distros
>    'apt install libnet-cidr-lite-perl'. RedHat based systems will have 
> similar
>    packages available.
>
> 2. Recognise PC18s coming from CC Clusters more nicely.
> 04Jan23=======================================================================
> 1. Fillout DXCIDR, attach checks in PC61 and logins. Login that fail will
>    simply disconnect, like locked out callsigns
> 2. Fix qrz.com URL in stock Internet.pm.
> 3. Fix DXHash issues (baddx, badnode, badspotter etc)
>
>
>
> _______________________________________________
> Dxspider-support mailing list
> Dxspider-support at tobit.co.uk
> https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.tobit.co.uk/pipermail/dxspider-support/attachments/20230122/84da13de/attachment-0001.htm>