[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