[wt4hq] Bridgehead-Bug / LogSync

Laurent HAAS - F6FVY f6fvy at free.fr
Thu Jul 9 18:08:50 CEST 2009


Hi again

Mario Lorenz a écrit :

> Yes, this is the first condition, so that a station can recover locally
> should it crash due to RF exposure or somesuch.
> The second condition is that I would like NO logsync via the tunnel,
> ever (only the ADDQSO traffic for new Q's).
> It is my understanding after my last mail that this should be
> achievable by enabling SYNC everywhere, but setting bridgehead = 0 
> on all wt.ini files,

...and restarting these WT (to take the .ini modification into account 
because of the ini key bug described few days ago) if you did the ini 
modification while WT was running...

> so there is no bridgehead.
> Is this correct?

Except if there is a bug somewhere, I fully agree.

> And would you agree that, given those settings and the drawing above,
> if one tunnel goes down, and comes back up later,
> and the QSOs logged on SiteASTN1 during the outage (and replicated to SiteASTN2)
> show later up on SiteBSTN1 (and are dutifully replicated to SiteBSTN2),
> that there must be a problem somewhere?

I (unfortunately) agree ;-)

This is how it works (WT version > 3.21.1) :

If a PC is set to "BridgeHead=1", it is supposed to send QSO inventories 
to the LAN (IHAVE: frames - that are filtered/dumped by wtTunnel) and to 
the WAN (IHAVEWAN: frames are passing thru wtTunnel).

If a PC is set to "BridgeHead=0", it is supposed to send QSO inventories 
to the LAN _ONLY_ (IHAVE: frames - that are filtered/dumped by wtTunnel).

73

Larry - F6FVY


More information about the Wt4hq mailing list