| |
G0SYR > NODES 18.04.05 13:34l 99 Lines 3873 Bytes #999 (0) @ WW
BID : 7010G0SYR
Read: DL8ZY GUEST DK3HG DH8GHH
Subj: Re: #TMP netrom node entries
Path: DB0FHN<DB0CL<DB0PDF<DB0SM<DB0EA<DB0RES<ON0RET<SR1BSZ<SP7MGD<IZ0AWG<
KP4IG<ED1ZAC<CX2SA<GB7YFS<GB7CIP<GB7CIP<GB7CIP
Sent: 050418/1126Z @:GB7CIP.#32.GBR.EU $:7010G0SYR
T:From: g0syr <g0syr@gb7cip.ampr.org>
T:Newsgroups: ampr.packet.nodes
T:Message-Id: <p31godvvwwca.1xmht8qyz1ev5$.dlg@40tude.net>
Hi Brian, Hank and all,
On Sat, 9 Apr 2005 20:31:00 +0000,
n1uro%n1uro.#wma.ma.usa.noam@gb7cip.ampr.org wrote:
> From: N1URO@N1URO.#WMA.MA.USA.NOAM
> To : NODES@WW
>
> Those #TMP:xx#xxx nodes entries you see are what's known in the netrom
> world as "slime trails". Slime nodes occur when a sysop of a netrom node
> allows unlisted nodes to make netrom connects to it. Many node ops feel its
> ok to allow slime node connects however as you pointed out, this is not really
> good practice to do. In time, if the node does not connect through, they'll
> eventually get dropped from the table you see them on.
>
> Here in the northeast USA we don't permit slime trails in the few netrom
> systems that are still up. Another way to eliminate such is to use FlexNet
> which doesn't do netrom :)
>
> 73 de Brian N1URO
Thanks for the useful comments from Brian and Hank
I have done a bit of digging although I can't be sure this is
the only source I have seen an example of the creation of these
problem entries and it does appear to be a node or nodes that is
broadcasting these tempory entries back onto the network with
high quality values so they do not die and corrupt the rest
of the network.
Although the #temp entry has been seen, the most problematic
entries created in quite large numbers seem to be #tmp and #TMP
(I suspect that some older nodes will not process lower case
aliases and the #TMP is just another version of #tmp).
Checking around I have ruled out TNOS nodes as they use ##temp
and I've never seen that. The only nodes I've found so far
using #tmp are (X)NET nodes versions 1.36 and 1.37.
Earlier versions such as 1.30 seem to use #temp.
This seems the most likely candidate for generating the problem.
It is difficult to tie to a single node as (X)NET'S routing
is so uncontrolled that its difficult to track the entries back to
the source, but I have just seen an example at the node
X-PKT:VE2PKT-3 which is running (X)NET 1.37 connected directly to
STECAT:VE2PKT-4 an XROUTER node.
Tracking a slime trail back through this node only a few minutes
after it had been created showed this entry on STECAT (XROUTER)
that would normally generate slime entries without aliases in
the more traditional form.
VE2PKT-4:STECAT} Nodes:
Routes to: #tmp:G0SYR-1 FR=30
> 150 5 33 GB7YB 0.00 0 0 <
150 5 49 VE2PKT-3 0.00 0 0
This was seen only minutes after MYGATE:G0SYR-1, a node that
doesn't appear on the network (my slime generator) had created
a slime trail that passed through X-PKT:VE2PKT-3 and STECAT:VE3PKT-4.
Note the high quality value of 150 and alias making it a valid
entry that STECAT will pass on to the rest of the network given
half a chance.
I'm a littled worried about that QUALITY value of 150 as I'm
suspicious this may be due to a configuration in XROUTER ??
so could it be a combination of two problems making the problem
worse.
Checking around the only node that I could find that might have
generated this entry is X-PKT:VE2PKT-3 the (X)NET 1.37 node, as
checking the entry at GB7YB (another XROUTER node the entry was
still correct)
VE2PKT-4:STECAT} Trying GB7YB
VE2PKT-4:STECAT} Connected to GB7YB
GB7YB:YORKS} Nodes:
Routes to: :G0SYR-1
10 0 11 G6HJP-3 0.00 0 0
10 0 10 G0CGL-1 0.00 0 0
showing the expected slime entries.
So does anyone know if this is simply poor implementation
causing (X)NET to broadcast these entries or a configuration
error that could lead to these problems?
I wonder if anyone else has any useful observations to add.
Pass me the cudgel Hank :-)
--
73 de Bryan g0syr.ampr.org [ 44.131.244.60 ]
Amprnet mail g0syr@gb7cip.ampr.org
AX25 mail G0SYR@GB7CIP.#32.GBR.EU
Internet Mail g0syr@beeb.net
Read previous mail | Read next mail
| |
