I've tested some settings that ought simulate a limited protocol between
clx (version 4.02) and a neighbor; in cluster_par in the section of
neighbor_A I defined
hops: dx/2 wwv/2 ann/2 node/-1 user/-1
# the doc states that negative hop numbers will block the respective
# PCxx messages, in this case PC19/21 and PC16/17
Neighbor_A is further defined as incoming active non-clx
(e.g. a pavilion dxc)
When neighbor_A connects, clx sends a PC19 with his own call. The HOP is 1.
Also the local users are send as PC16 with HOP 1. A true limited protocol
should not have send the local users.
Now while initialised, clx links to neighbor_B; active clx. The incoming PC19
of neighbor_B (and its connected active neighbors) is send to neighbor_A
with a 1<HOP<99, depending on the settings on neighbor_B. The same goes
for any other incoming node or user PCxx message via neighbor_B. They are
all forwarded to neighbor_A with 1<HOP<99. This should not happen on a limited
protocol link.
Perhaps this behaviour be explained by the phylosopfy of the clx development
team: not to influence the hops of any incoming PCxx message other than
decreasing them with 1. This way a limited protocol scheme will never be
possible although in some cases desirable when linking into a pavilion based
(foreign) network.
So..., be carefull when linking with a pavilion cluster and defining it as a
limited protocol link. It will not be a true limited protocol link.
73 de Aurelio-PA3EZL
qglqphro@francis.edu
ps. version 4.02 looking GOOD!!!