OpenBCM V1.07b12 (Linux)

Packet Radio Mailbox

DB0FHN

[JN59NK Nuernberg]

 Login: GUEST





  
G0SYR  > XROUTE   27.08.06 00:23l 90 Lines 4057 Bytes #999 (0) @ WW
BID : 22484G0SYR
Read: OE3GMW GUEST
Subj: Re: #TMP problems
Path: DB0FHN<DB0RGB<OK0PPL<DB0RES<F6GGY<F4BWT<IW2OAZ<IZ0AWG<IZ0AWG<IW8PGT<
      VK4TRS<GB7YFS<GB7CIP<GB7CIP<GB7CIP
Sent: 060826/2142Z @:GB7CIP.#32.GBR.EU $:22484G0SYR

T:From: g0syr <g0syr@gb7cip.ampr.org>
T:Newsgroups: ampr.packet.xrouter
T:Message-Id: <1178ahgel193$.2s2bggbzavk3.dlg@40tude.net>

Hi Peter, Pete and all

On Sat, 26 Aug 2006 00:16:00 +0000, g6hjp%gb7pfd.#48.gbr.eu@gb7cip.ampr.org
wrote:

> From: G6HJP@GB7PFD.#48.GBR.EU
> To  : XROUTE@WW
> 
>> 
>>Hi Pete and all,
>>That's interesting could you ask for more information about configuring
>>XROUTER to stop propagation of them as I would be interested and don't 
>>know of a way to prevent their propagation so more details would be
>>useful. Of course they are not only propagating through XROUTER nodes as
>>they are seen as valid entries by all nodes once they have been sent
>>in a nodes broadcast by the offending station.
>>I wonder how you know the problem is generated at GB7WV as in my 
>>observations it was almost impossible to tell where the problem came 
>>from. I realise that it's the corrupt entry at GB7WV that causes you 
>>the problem but how could you tell the entry was generated by XROUTER 
>>at GB7WV and not received from another node ?
>>
>>-- 
>>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
>>
> 
> Just had a quick look round the network and followed the path that the #tmp
> gave at Wolves.   As you have said it is effecting all Nodes, no matter what
> software they run.
> The entry at the Node too me to VA2TRG-5 via G0CNG-8.    Taking this route the
> system logged me into JNOS V2.0 system that was running BPQ as its front end.
> My immediate thought was maybe it could be BPQ, this is fairly old software
> now and could be a culprit.
> This is only my quick findings, but hope it helps a bit to find the problem.
> 
> Added below is are the Tmp enteries for my Node...as at 09:00 26 Aug 06
> 
> Please note I too have the VA2TRG entry, but note that SHELF is a correct
> Node that has been hidden by its Sysop.
> 
> NODE ADD #SHELF:G8NRY-14 GB7YB 15 25
> NODE ADD #TMP:VA2TRG-5 GB7YB 15 17
> XNODE ADD #TMP:VA2TRG-5 GB7YB 15 176 3
> NODE ADD #TMP:K2CAN-3 GB7YB 15 17
> XNODE ADD #TMP:K2CAN-3 GB7YB 15 60 3
> NODE ADD #tmp:GB7RMS G1NNB 8 48 GB7YB 15 18 GB7HP 2 11
> XNODE ADD #tmp:GB7RMS G1NNB 8 193 2 GB7YB 15 241 3
> 
> Hope we can track this Bug whatever down and restore the rdaio connectability.
> 
> 
> Peter, Sysop - G6HJP @ GB7PFD.#48.GBR.EU
> SYSOP of GB7PFD and Node FIELD.
> 
> /ACK
Hi Peter thanks for the input, it's very difficult to track the problem.
You need to start with a node that doesn't exist on the network so
that it can make outgoing netrom connections to nodes that don't
'know' about it thus creating a slime trail of tempory entries, the problem
is you need to check the precise route which can be difficult. But
any node that the path goes through will generate a tempory entry
but we need to spot which one that then propagates it in it's node
broadcast. So you need to connect out one step at a time checking
each step to check that that software is good before moving onto another.
Trouble is routes can change while you are testing and it only needs to
hop off down another route which can confuse you very easily which I why
I gave up without getting to the route cause. As we see #tmp, #TMP and #TEMP
sometimes it seems likely that its more than one version that is generating
the problem.
I don't think it's BPQ as this is a fairly recent phenomena that I became
aware of perhaps a couple of years ago, so I believe it's one of the more
recent additions to node software. 
I would add that my investigations only was looking at simnple traditional
netrom where routing is controlled by Quality and nodes broadcasts
there is the whole other minefield of Time Domain Routing to consider as
it seems possible the corruption could get in this way as nodes tend to
combine the TDR and Quality based routing into a single nodes table.

-- 
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


 18.05.2024 22:34:36lGo back Go up