[wt4hq] TunnelClient doesn't filter, kills uplink

[Olivier F5MZN]

Mario Lorenz wrote:
> Hi,
> 
> After several delays, I finally got around setting up a test network
> consisting of at least several nodes.
> I observed exactly what I feared:
> The tunnel client (v 1.7) does not include the station name learning
> logic that the new server has. This has the following effect:
> Assume a site with a few computers, and a GPRS uplink (due to faster
> modes not being available). Logsync being enabled.
> Late in the contest (say, 20k QSOs), one of the computer dies, and is
> duly replaced with a spare. That spare doesnt have any log, so when
> it comes up, it will start syncing the whole log.
> 
> Now, if that computer happens to sync to some remote computer, thats
> 1.6Megs that will have to go thru the Link, effectively killing it for
> 5..10 minutes. I can't comment on wheter and how often this will hapen
> since I haven't fully understood the protocol. Even if it does not
> happen, and it syncs the log from a PC on the local LAN, all that sync
> traffic is uplinked to the server by the client. The server will then
> throw that data away, so that uplink is completely unnecessary.
> Now, all that sync data on the LAN will clog the uplink, impacting
> regular QSO flow.
> 
> Steps to reproduce: Take your last year's log in one station on the lan,
> set up a remote tunnel server somewhere and set up the client, then
> connect a new PC on the same LAN, opening an empty HQ log there, and let
> it sync. Watch bandwith and response of your uplink.
> (without knowledge, but I assume it might get worse if the log was not
> empty, but partial (ie with holes), due to the additional IHAVE traffic
> instead of only blazing ADDQSOs)

Hello,

I have just uploaded wtTunnel version 1.8 which is intended to fix that 
behaviour. The wtTunnel software will now accept to forward a protocol 
to be destinated to a station when this station is outside of the LAN.

Please try and tell me if it works as expected.

73,
-- 
Olivier / f5mzn