| |
G0SYR > XROUTE 25.08.06 11:08l 105 Lines 4574 Bytes #999 (0) @ WW
BID : 32596G0SYR
Read: OE3GMW GUEST
Subj: Re: #TMP problems
Path: DB0FHN<DB0FOR<DB0SIF<DB0FSG<DB0RGB<OK0PPL<DB0RES<ON0AR<F6BZU<F6DAA<
TU5EX<IW8PGT<VK4TRS<GB7YFS<GB7CIP<GB7CIP<GB7CIP
Sent: 060825/0904Z @:GB7CIP.#32.GBR.EU $:32596G0SYR
T:From: g0syr <g0syr@gb7cip.ampr.org>
T:Newsgroups: ampr.packet.xrouter
T:Message-Id: <wbhokyplousr$.t562oeurg6i5$.dlg@40tude.net>
On Wed, 23 Aug 2006 16:29:00 +0000, g6kui%gb7dby.#23.gbr.eu@gb7cip.ampr.org
wrote:
> Hi All,
> I've dicovered a "feature" in XRouter that had me pulling my hair out.
>
> It involves XRouter's use of #TMP for level 3 connects when the XRouter
> node has not received a nodes broadcast from the level3 (NetRom) connecting
> station. In such a case the XRouter node allocates the #TMP or #tmp allias.
> This is ok as long as it's the only one it has to deal with.
> But things go haywire if there are a number of #TMP allias - your return
> traffic can go to any of them except to the proper intended node.
>
> This situation does not correct itself on subsequent nodes broadcasts.
> If your (non-xrouter) node is connected to an xrouter node in this manner
> then anyone can make netrom connections through this non-xrouter node
> except the node itself and associated BBS or PMS.
>
> I've just endured a number of days of this problem.
>
> The Answer
> ==========
>
> Turn off the link to the xrouter node untill your entry in it's node table
> has expired.
> Then make sure that the next thing that the xrouter node sees of you is
> your nodes broadcast. If there is any other level3 traffic then you are
> back in the problem.
>
>
> Maybe the problem exists with other Netrom type nodes, I don't know, but
> as they usually only have a limited nodes list, the situation is unlikely
> to manifest itself. With XRouters large nodes list , the problem is just
> waiting to happen.
>
> I hope the above info is of interest and use to someone else.
>
> 73, Pete G6KUI
> Sysop ALVAST:G6KUI-1 and DBYBBS:GB7DBY
>
>
>
>
> Message sent with NPFPMS V2.54c
Hi Pete and all,
I may be wrong but I don't think this is a feature of XROUTER. I wrote
several bulletins about these #TMP entries probably a year or so ago and
did some investigation into them. As far as I'm aware XROUTER's tempory
entries are created WITHOUT the node name and are processed normally.
I did not fully trace the problem back to which node software/version
is causing the problem as it appeared to be more than one, as I have seen
both #TEMP and #TMP and #tmp and #temp versions of the corrupted entries.
Here is the top of my nodes list today,
GB7CP:CATHAM} Nodes:
#tmp:GB7TUT-1 #tmp:EI3RCW-8 #tmp:GB7WE #tmp:2E1GOR
#tmp:G0WKL-1 #tmp:G0WKL-2 #tmp:GB7DY-7 #tmp:GB7WE-8
#tmp:GB7GH-7 #tmp:GB3KD #tmp:G7DIR-2 #tmp:G0WKL-3
#tmp:G8LWS-1 #tmp:GB7WS-2 #tmp:GB7WV #TMP:GB7SYP-1
#tmp:G1NNA-8 #tmp:GB7NNA #tmp:GB7FD #TMP:GB7YDX-8
#tmp:G6TJZ-8 #TMP:GB7AYR
The problem seems to be getting worse so maybe node software causing
the problem is being installed at more node sites.
My best guess was that X(net) was the most likely source as I tested
several versions in the US and Canada which seemed to generate the
entries most readily but could not tie it down to which one.
Some versions of node software create these entries with the #TMP name
which is fine within it's own node table but in this case it appears the
faulty node is then including them in it's outgoing nodes broadcast so
they then are passed around the network causing the havoc you describe as
then two valid entries for the node now exist.
It can be very tricky to get rid of these entries as you describe, I see
today at BLOX there is still a corrupt entry for #TMP:GB7DBY so C DBYBBS
is failing at BLOX, one solution is to only use the node callsign for
connections and abandon the use of the node name as this problem makes
it very unreliable to use node names even locally.
The problem is very difficult to trace on the current network. I did
configure a test node on my LAN that was hidden externally so that I
could generate these connections from an unknown node, but because modern
internet based nodes update the network so quickly you had to be very
fast to spot the rogue node before the corruption had been passed on
to it's neighbours. Then you had to close the node down for several hours
before making another test. I'm afraid I became discouraged and put it
down to just one more feature of X(net) that disrupts the UK's network.
I would also be interested if anyone knows any more about this problem
--
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
| |
