OpenBCM V1.07b12 (Linux)

Packet Radio Mailbox

DB0FHN

[JN59NK Nuernberg]

 Login: GUEST





  
G6KUI  > XROUTE   23.08.06 18:46l 43 Lines 1497 Bytes #999 (0) @ WW
BID : 9456_G6KUI
Read: OE3GMW GUEST
Subj: #TMP problems
Path: DB0FHN<DB0RGB<DB0MRW<DK0WUE<7M3TJZ<ON0AR<I0TVL<IK1ZNW<VE3FJB<ON4HU<
      GB7YFS<GB7MAX<GB7DBY<GB7DBY
Sent: 060823/1629z @:GB7DBY.#23.GBR.EU NPF2.54c [G6KUI PMS Alvaston Derby]


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


Read previous mail | Read next mail


 18.05.2024 22:00:03lGo back Go up