[Dxspider-support] Node INITing?

Dirk Koopman djk at tobit.co.uk
Fri Sep 7 18:24:20 BST 2001


On Fri, 2001-09-07 at 17:14, John Clayton wrote:
> Hi Dirk
> 
> something very strange happening of late on AK1A nodes.
> 
> On GB7DXC, GB7DJK and GB7MBC are not showing under SH/C/N, however, when
> you do SH/ST GB7DJK it says GB7DJK (at GB7DJK) - like it should.  Also
> when you do SH/NODE GB7DJK you get the answer GB7DJK   * 5.4-48 - like
> it should. If you try to do a RCMD/GB7DJK from GB7DXC you get the reply 
> *** Specified station GB7DJK is not a PacketCluster node ***.
> 
> All the above applies to both GB7DJK and GB7MBC and occurs on at least
> GB7DXC, GB7WDX, GB7PDX, GB7CDX and GB7BPQ (tried using RCMD from
> GB7DXC).
> 
> Has there by any chance been a change in the way that Spider is
> notifying nodes in the INIT stage of joining?
> 

This is caused by PC16s coming in with node callsigns on them. AFAIK
this is caused by clx nodes in 'passive' (or some other type of non full
protocol) mode picking up stuff and then passing them on via the (now)
highly looped EU cluster.

In the past these PC16s would have been dumped. Now Spider has the
possibility of being both a user and a node in the routing tables. I did
this because it just falls out from the way the new routing table is
done (there are, in effect, two routing tables).

It may be that what I should do is go back to the old behaviour of
ignoring incoming PC16s with node callsigns in them. The problem with
this is: ordering. It is perfectly feasable for a PC16 to come in from a
possible node and, some time later, a PC19 - in the old code that would
have been dumped.

I could introduce a 'once a node, always a node' paradigm but maybe that
will inconvenience someone else?

You, of course, always upgrade....

Dirk





More information about the Dxspider-support mailing list