Temporary fix for unresolved wxHttp symbol under ubuntu, XLX priority

[F4FXL]

This uses wget to download the XLX host file. Not best solution, but at least more universal. This should solve https://github.com/dl5di/OpenDV/issues/119 until better solution is found

This also adds the ability for XLX to override the content of local hosts file or not. new in config file xlxOverrideLocal Default is to override local files.

[johnhays]

This is a problem that Luc and the XLX community really needs to clean up.

http://ar-dns.net

(Adrian, I will be integrating your XRF entries soon.)

On Wed, Feb 15, 2017 at 2:35 PM, vk4tux notifications@github.com wrote:

When you get the XLX host file, are you filtering out pre-existing XRF, DCS matches from those host files, before you add or overwrite ?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/dl5di/OpenDV/pull/120#issuecomment-280162569, or mute the thread https://github.com/notifications/unsubscribe-auth/AGP0elgRlsfzR4tD1MoGsInNg3p00AT3ks5rc32VgaJpZM4MBcNh .

--

---

John D. Hays K7VE

PO Box 1223, Edmonds, WA 98020-1223 http://k7ve.org/blog http://twitter.com/#!/john_hays

[n8ohu]

At one time, I remember that Jonathan had added the ability to have multiple versions of the host files so users could have custom ones, with is how my gateway is set up; has that been removed now? If so, perhaps we should consider how to adapt that old method to allow for specific startup configurations that need it; at the time I used it, I was accessing an XRF reflector on the same network as my gateway.

[LX1IQ]

Adrian, You really don’t get it? Let me explain it for the very last time to bring the actual situation to the point. First of all, it is not my intention to replace any existing host files or to make a rude takeover by the XLX. I’m nor the D-Star police neither the reflector number keeper. Every sysop who decides to run a reflector system should make his homework and check the existing reflectors before deploying a new one!! I was simply asked by many software and hardware developers, if it would be possible to provide a live host file of the XLX Reflectors. That is exactly what the XLXAPI-SERVER is doing. It is generating a live host file in different formats for all registered XLX Reflectors only. No more no less!! I don’t care about, what the developers or the end-users are doing with this list. They can use it, merge it, ignore it, override other host-files, whatever they want. If you have a problem with the XLX host file or the XLX Reflector system, simply ignore it and don’t bother me anymore with your childish accusations about rude takeover or steeling reflector numbers. I guess that the users which are using the XLX host file are smart enough to know what to do with the XLX host file. Thank you for your understanding.

73, de LX1IQ – Luc -

[F4FXL]

Hi all,

Please step a little back Gentlemen. Noone is accusing of takeover. I have no links with the XLX team (but do appreciate their work in providing a modern reflector system). What drove me to implement this is the fact that with the increasing popularity of XLx reflectors, it came to light that most gateway sysops do not make their homework and maintain their hosts files. This PR also adds the ability for the gateway sysop to set priority between his hosts files and the downloaded ones. This has been requested when i first implemented the feature back in december. There is a new option in the config file xlxOverrideLocal. When set to 1 the downloaded list will override the one from the hosts files i.e. duplicate hosts will be taken from the downloaded list. My apologize for not implementing any earlier and for not providinding clear instructions.

@n8ohu I do not think defaulting xlxOverrideLocal to false is a good idea. I've experienced too many gateway with outdated hosts files. But if this is general consensus, let's do so...

73 Geoffrey F4FXL

[F4FXL]

Adrian, I totally agree taht existing number shall not be hijacked. This feature provides a way for sysops to decide what to do with duplicates. It was never meant to be a Trojan horse in order "to have XLX take over the world".

I did my homework for XLX208. I expect all reflector sysops to do so.

[F4FXL]

PS : updating github hosts files is useless if gateway sysops do not pull the files regularly. Just thinking as a user which travels and cannot reach a reflector because the sysop does not bother updating his files regularly.

[F4FXL]

IMHO completely dropping the hosts file stuff and going for @johnhays dns would be best solution.

[n8ohu]

Hosts files for custom requirements, like hosting both an xreflector amd gateway on the same ip address as I have done in the past, and use dns as primary outbound would be the best option. All the hosts files really should be needed for is startup anyway; if you don't plan to link at startup, dns should be adequate.

[mcdermj]

On Feb 17, 2017, at 4:27 AM, vk4tux notifications@github.com wrote:

The host file determines the port used to connect ; 20001/30001/30051 used, so is required

See https://en.wikipedia.org/wiki/SRV_record https://en.wikipedia.org/wiki/SRV_record

— Jeremy McDermond nh6z@nh6z.net mailto:nh6z@nh6z.net

On 17/02/17 22:00, Geoffrey Merck wrote:

IMHO completely dropping the hosts file stuff and going for @johnhays https://github.com/johnhays dns would be best solution.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/dl5di/OpenDV/pull/120#issuecomment-280631692, or mute the thread https://github.com/notifications/unsubscribe-auth/AIVGYJKD6aA1Oyrkn-x7Z6A8qelBBVv2ks5rdYvWgaJpZM4MBcNh.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/dl5di/OpenDV/pull/120#issuecomment-280636408, or mute the thread https://github.com/notifications/unsubscribe-auth/AAMtiXRGhdRN7sYD-78VcjFX_M56gS6Aks5rdZIagaJpZM4MBcNh.

[johnhays]

SRV records are right for advertizing ports and I can support them in the DNS service I am pulling together at http://ar-dns.net

However, without providing host level SRV records, one implementation could be that clients try each protocol to talk to an XLX reflector, and pick the first one that works.

We should get to the point where DNS is the primary mechanism to get IP addresses, on ar-dns.net I have provided subdomains for xlx, dcs. dplus, dextra (to be implemented) and have a fallback to downloaded host files (or AFRX) -- but the host file should not need to be segregated into multiple host files for the various protocols if we can keep each host (reflector/gateway) uniquely named.

Our big problem right now is that host files are being distributed for XLX which have aliases for REF/DCS/XRF reflectors and they conflict with already established reflectors for each of those protocols.

As a side note, I think LOC records could be interesting as well https://en.wikipedia.org/wiki/LOC_record

We really need to start engineering and building these systems on solid, standardized, and proven technologies rather than hacks and tricks

On Fri, Feb 17, 2017 at 8:23 AM, Jeremy McDermond notifications@github.com wrote:

On Feb 17, 2017, at 4:27 AM, vk4tux notifications@github.com wrote:

The host file determines the port used to connect ; 20001/30001/30051 used, so is required

See https://en.wikipedia.org/wiki/SRV_record https://en.wikipedia.org/ wiki/SRV_record

— Jeremy McDermond nh6z@nh6z.net mailto:nh6z@nh6z.net

--

---

John D. Hays K7VE

PO Box 1223, Edmonds, WA 98020-1223 http://k7ve.org/blog http://twitter.com/#!/john_hays

[g4klx]

There seems to be fundamental misunderstanding about how the host files work within the gateway. Firstly for DCS and D-Plus, the host files are only used for initial linking while the gateway starts up. Shortly after that the gateway gets the correct addresses from the official sources, in the case of D-Plus this is mandatory as it is part of the authorisation process. In the case of DExtra the host file is used all of the time.

I suggested to Bob W6KD that the dxrfd program be modified to update their details with a centralised server so that it is possible to keep track of any address changes quickly.

I see talk of using a DNS, that's great, but unless you can guarantee that it's updated as well as the official sources for DCS and D-Plus, it makes no sense. Another problem with DNS is that it could stall the main loop in the gateway, unless you can guarantee that it responds in 5ms or less, and I know that that is impossible. On a bad-ish Internet link, each call can stall for a minute or so.

I think you should sit down with Bob W6KD and sort out a new mechanism for DExtra, and leave DCS and D-Plus as they are.

[johnhays]

The DNS lookup can be resolved with proper coding using a separate thread.

To have an updated DNS is a function of having authoritative sources, and a little bit of cooperation to avoid naming conflicts.

Currently ircddbgateway needs to be restarted every time a new hosts file is pulled in, using DNS would mean that updated information could be pulled at any time.

On Fri, Feb 17, 2017 at 12:51 PM, Jonathan Naylor notifications@github.com wrote:

There seems to be fundamental misunderstanding about how the host files work within the gateway. Firstly for DCS and D-Plus, the host files are only used for initial linking while the gateway starts up. Shortly after that the gateway gets the correct addresses from the official sources, in the case of D-Plus this is mandatory as it is part of the authorisation process. In the case of DExtra the host file is used all of the time.

I suggested to Bob W6KD that the dxrfd program be modified to update their details with a centralised server so that it is possible to keep track of any address changes quickly.

I see talk of using a DNS, that's great, but unless you can guarantee that it's updated as well as the official sources for DCS and D-Plus, it makes no sense. Another problem with DNS is that it could stall the main loop in the gateway, unless you can guarantee that it responds in 5ms or less, and I know that that is impossible. On a bad-ish Internet link, each call can stall for a minute or so.

I think you should sit down with Bob W6KD and sort out a new mechanism for DExtra, and leave DCS and D-Plus as they are.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dl5di/OpenDV/pull/120#issuecomment-280763094, or mute the thread https://github.com/notifications/unsubscribe-auth/AGP0ermCUekT-WyQEDl574afXsJe675yks5rdghigaJpZM4MBcNh .

--

---

John D. Hays K7VE

PO Box 1223, Edmonds, WA 98020-1223 http://k7ve.org/blog http://twitter.com/#!/john_hays

[johnhays]

Robin told me other than frequency range, all other communications should be the same as the other DVAPs

On Feb 17, 2017 20:38, "vk4tux" notifications@github.com wrote:

Going back to ;

Add support for the 220 MHz DVAP.

• master https://github.com/dl5di/OpenDV

1 parenta7559a7 https://github.com/dl5di/OpenDV/commit/a7559a7c330db199bc6582508936cf 820251f2e0commit7aba26631e8cfd29026333fff5b92cbe3b725ca4@g4klxg4klx https://github.com/g4klxcommittedon 25 Nov 2016

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dl5di/OpenDV/pull/120#issuecomment-280821405, or mute the thread https://github.com/notifications/unsubscribe-auth/AGP0elff9CppNgLGuzuvAGatAFLNapzQks5rdnXRgaJpZM4MBcNh .

[F4FXL]

Adrian, this is fixed with https://github.com/dl5di/OpenDV/pull/120 which has not been merged yet.You could clone from my fork if you want to have it.

-------- Message d'origine -------- De : vk4tux notifications@github.com Date : 18/02/2017 05:36 (GMT+01:00) À : dl5di/OpenDV OpenDV@noreply.github.com Cc : Geoffrey Merck f4fxl@planetemax.com, Author author@noreply.github.com Objet : Re: [dl5di/OpenDV] Temporary fix for unresolved wxHttp symbol under ubuntu, XLX priority (#120)

Geoffrey, I though this was fixed or sub-dued ? Today on armhf odroid

ubuntu . fresh git clone;

libCommon.a(libCommon_a-XLXHostsFileDownloader.o): In function

`wxProtocol::SetTimeout(long)':

/usr/include/wx-3.0/wx/protocol/protocol.h:91: undefined reference to

`wxProtocol::SetDefaultTimeout(unsigned int)'

libCommon.a(libCommon_a-XLXHostsFileDownloader.o): In function

`CXLXHostsFileDownloader::Download(wxString const&)':

/home/odroid/OpenDV/ircDDBGateway/Common/XLXHostsFileDownloader.cpp:46:

undefined reference to `wxHTTP::Connect(wxString const&, unsigned short)'

/home/odroid/OpenDV/ircDDBGateway/Common/XLXHostsFileDownloader.cpp:26:

undefined reference to `wxHTTP::~wxHTTP()'

/home/odroid/OpenDV/ircDDBGateway/Common/XLXHostsFileDownloader.cpp:52:

undefined reference to `wxHTTP::GetInputStream(wxString const&)'

/home/odroid/OpenDV/ircDDBGateway/Common/XLXHostsFileDownloader.cpp:77:

undefined reference to `wxSocketBase::Close()'

/home/odroid/OpenDV/ircDDBGateway/Common/XLXHostsFileDownloader.cpp:26:

undefined reference to `wxHTTP::~wxHTTP()'

collect2: error: ld returned 1 exit status

Makefile:1345: recipe for target 'ircddbgateway' failed

make: *** [ircddbgateway] Error 1

root@odroid64:~/OpenDV/ircDDBGateway# ?

root@odroid64:~/OpenDV/ircDDBGateway# uname -a

Linux odroid64 3.14.29-29 #1 SMP PREEMPT Fri Feb 26 11:00:53 BRT 2016

aarch64 aarch64 aarch64 GNU/Linux

root@odroid64:~/OpenDV/ircDDBGateway#

dstarrepeater is ok ;

g++ -g -O2 -o dstarrepeaterd

DStarRepeater/dstarrepeaterd-DStarRepeaterApp.o

DStarRepeater/dstarrepeaterd-DStarRepeaterLogger.o libCommon.a

-L/usr/lib/aarch64-linux-gnu -pthread -lwx_baseu-3.0 -lusb-1.0 -lasound

make[1]: Leaving directory '/home/odroid/OpenDV/DStarRepeater'

root@odroid64:~/OpenDV/DStarRepeater#

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/dl5di/OpenDV","title":"dl5di/OpenDV","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/dl5di/OpenDV"}},"updates":{"snippets":[{"icon":"PERSON","message":"@vk4tux in #120: Geoffrey, I though this was fixed or sub-dued ? Today on armhf odroid \nubuntu . fresh git clone;\n\nlibCommon.a(libCommon_a-XLXHostsFileDownloader.o): In function \nwxProtocol::SetTimeout(long)':\n/usr/include/wx-3.0/wx/protocol/protocol.h:91: undefined reference to \nwxProtocol::SetDefaultTimeout(unsigned int)'\nlibCommon.a(libCommon_a-XLXHostsFileDownloader.o): In function \nCXLXHostsFileDownloader::Download(wxString const\u0026)':\n/home/odroid/OpenDV/ircDDBGateway/Common/XLXHostsFileDownloader.cpp:46: \nundefined reference towxHTTP::Connect(wxString const\u0026, unsigned short)'\n/home/odroid/OpenDV/ircDDBGateway/Common/XLXHostsFileDownloader.cpp:26: \nundefined reference to wxHTTP::~wxHTTP()'\n/home/odroid/OpenDV/ircDDBGateway/Common/XLXHostsFileDownloader.cpp:52: \nundefined reference towxHTTP::GetInputStream(wxString const\u0026)'\n/home/odroid/OpenDV/ircDDBGateway/Common/XLXHostsFileDownloader.cpp:77: \nundefined reference to wxSocketBase::Close()'\n/home/odroid/OpenDV/ircDDBGateway/Common/XLXHostsFileDownloader.cpp:26: \nundefined reference towxHTTP::~wxHTTP()'\ncollect2: error: ld returned 1 exit status\nMakefile:1345: recipe for target 'ircddbgateway' failed\nmake: *** [ircddbgateway] Error 1\nroot@odroid64:~/OpenDV/ircDDBGateway# ?\n\n\nroot@odroid64:~/OpenDV/ircDDBGateway# uname -a\nLinux odroid64 3.14.29-29 #1 SMP PREEMPT Fri Feb 26 11:00:53 BRT 2016 \naarch64 aarch64 aarch64 GNU/Linux\nroot@odroid64:~/OpenDV/ircDDBGateway#\n\n\ndstarrepeater is ok ;\n\ng++ -g -O2 -o dstarrepeaterd \nDStarRepeater/dstarrepeaterd-DStarRepeaterApp.o \nDStarRepeater/dstarrepeaterd-DStarRepeaterLogger.o libCommon.a \n-L/usr/lib/aarch64-linux-gnu -pthread -lwx_baseu-3.0 -lusb-1.0 -lasound\nmake[1]: Leaving directory '/home/odroid/OpenDV/DStarRepeater'\nroot@odroid64:~/OpenDV/DStarRepeater#\n\n\n"}],"action":{"name":"View Pull Request","url":"https://github.com/dl5di/OpenDV/pull/120#issuecomment-280821308"}}}

[F4FXL]

Which protocol to use for xlx could simply be an option in the client. Simple and straight forward.

-------- Message d'origine -------- De : "John Hays (K7VE)" notifications@github.com Date : 17/02/2017 19:09 (GMT+01:00) À : dl5di/OpenDV OpenDV@noreply.github.com Cc : Geoffrey Merck f4fxl@planetemax.com, Author author@noreply.github.com Objet : Re: [dl5di/OpenDV] Temporary fix for unresolved wxHttp symbol under ubuntu, XLX priority (#120)

SRV records are right for advertizing ports and I can support them in the

DNS service I am pulling together at http://ar-dns.net

However, without providing host level SRV records, one implementation could

be that clients try each protocol to talk to an XLX reflector, and pick the

first one that works.

We should get to the point where DNS is the primary mechanism to get IP

addresses, on ar-dns.net I have provided subdomains for xlx, dcs. dplus,

dextra (to be implemented) and have a fallback to downloaded host files (or

AFRX) -- but the host file should not need to be segregated into multiple

host files for the various protocols if we can keep each host

(reflector/gateway) uniquely named.

Our big problem right now is that host files are being distributed for XLX

which have aliases for REF/DCS/XRF reflectors and they conflict with

already established reflectors for each of those protocols.

As a side note, I think LOC records could be interesting as well

https://en.wikipedia.org/wiki/LOC_record

We really need to start engineering and building these systems on solid,

standardized, and proven technologies rather than hacks and tricks

On Fri, Feb 17, 2017 at 8:23 AM, Jeremy McDermond notifications@github.com

wrote:

On Feb 17, 2017, at 4:27 AM, vk4tux notifications@github.com wrote:

The host file determines the port used to connect ; 20001/30001/30051

used, so is required

See https://en.wikipedia.org/wiki/SRV_record <https://en.wikipedia.org/

wiki/SRV_record>

—

Jeremy McDermond

nh6z@nh6z.net mailto:nh6z@nh6z.net

--

---

John D. Hays

K7VE

PO Box 1223, Edmonds, WA 98020-1223

http://k7ve.org/blog http://twitter.com/#!/john_hays

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/dl5di/OpenDV","title":"dl5di/OpenDV","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/dl5di/OpenDV"}},"updates":{"snippets":[{"icon":"PERSON","message":"@johnhays in #120: SRV records are right for advertizing ports and I can support them in the\nDNS service I am pulling together at http://ar-dns.net\n\nHowever, without providing host level SRV records, one implementation could\nbe that clients try each protocol to talk to an XLX reflector, and pick the\nfirst one that works.\n\nWe should get to the point where DNS is the primary mechanism to get IP\naddresses, on ar-dns.net I have provided subdomains for xlx, dcs. dplus,\ndextra (to be implemented) and have a fallback to downloaded host files (or\nAFRX) -- but the host file should not need to be segregated into multiple\nhost files for the various protocols if we can keep each host\n(reflector/gateway) uniquely named.\n\nOur big problem right now is that host files are being distributed for XLX\nwhich have aliases for REF/DCS/XRF reflectors and they conflict with\nalready established reflectors for each of those protocols.\n\nAs a side note, I think LOC records could be interesting as well\nhttps://en.wikipedia.org/wiki/LOC_record\n\nWe really need to start engineering and building these systems on solid,\nstandardized, and proven technologies rather than hacks and tricks\n\nOn Fri, Feb 17, 2017 at 8:23 AM, Jeremy McDermond \u003cnotifications@github.com\u003e\nwrote:\n\n\u003e\n\u003e \u003e On Feb 17, 2017, at 4:27 AM, vk4tux \u003cnotifications@github.com\u003e wrote:\n\u003e \u003e\n\u003e \u003e The host file determines the port used to connect ; 20001/30001/30051\n\u003e \u003e used, so is required\n\u003e\n\u003e See https://en.wikipedia.org/wiki/SRV_record \u003chttps://en.wikipedia.org/\n\u003e wiki/SRV_record\u003e\n\u003e\n\u003e —\n\u003e Jeremy McDermond\n\u003e nh6z@nh6z.net \u003cmailto:nh6z@nh6z.net\u003e\n\u003e\n\u003e --\n\n------------------------------\nJohn D. Hays\nK7VE\n\nPO Box 1223, Edmonds, WA 98020-1223\n \u003chttp://k7ve.org/blog\u003e \u003chttp://twitter.com/#!/john_hays\u003e\n"}],"action":{"name":"View Pull Request","url":"https://github.com/dl5di/OpenDV/pull/120#issuecomment-280724156"}}}

[F4FXL]

Unfortunately I have no trick to get rid of the DEBUG thing in the main window. Maybe it is switched on and off by using the generate "generqte debug symbols" when invoking the compiler.
The autoconf stuff made some stuff easier (e.g. creating debian packages at the cost of complexifing the whole build process, but this is another issue.
I think DEBUG was meant to indicate this was compiled with debug symbols. When you create the deb packages it also creates packages for the debug symbols. I can easily imagine someone having problems just installs the debug symbols and thus will help to better diagnose the issue.

wx 2.8 is being obsoleted in many distrubutions, IMHO it is better ot move on to 3.0.x

)

[johnhays]

My service regularly pulls your file and automatically updates from it.

On Feb 22, 2017 02:09, "vk4tux" notifications@github.com wrote:

John XRF updated today with new entries ;

Dear Adrian,

Thanks always !! Can you please update the follow XRF host please? My friend built them this week.

XRF095 xrf095.dip.jp http://xrf095.dip.jp XRF373 xrf373.dip.jp http://xrf373.dip.jp XRF515 shounandstar.dip.jp http://shounandstar.dip.jp

http://www.arrg.us/HF/DExtra_Hosts.txt http://www.arrg.us/HF/DExtra_Hosts.txt

Best regards.

73, Yoshi / JH1TWX from Tokyo, Japan.

http://vk4tux.duckdns.org/OD/DExtra_Hosts.txt

On 16/02/17 08:41, John Hays (K7VE) wrote:

This is a problem that Luc and the XLX community really needs to clean up.

http://ar-dns.net

(Adrian, I will be integrating your XRF entries soon.)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dl5di/OpenDV/pull/120#issuecomment-281625439, or mute the thread https://github.com/notifications/unsubscribe-auth/AGP0enkYtQ1xOt1DfEUykZ2-sH2An_3qks5rfAlTgaJpZM4MBcNh .

[vk4tux]

Adrian, You really don’t get it? Let me explain it for the very last time to bring the actual situation to the point. First of all, it is not my intention to replace any existing host files or to make a rude takeover by the XLX. I’m nor the D-Star police neither the reflector number keeper. Every sysop who decides to run a reflector system should make his homework and check the existing reflectors before deploying a new one!! I was simply asked by many software and hardware developers, if it would be possible to provide a live host file of the XLX Reflectors. That is exactly what the XLXAPI-SERVER is doing. It is generating a live host file in different formats for all registered XLX Reflectors only. No more no less!! I don’t care about, what the developers or the end-users are doing with this list. They can use it, merge it, ignore it, override other host-files, whatever they want. If you have a problem with the XLX host file or the XLX Reflector system, simply ignore it and don’t bother me anymore with your childish accusations about rude takeover or steeling reflector numbers. I guess that the users which are using the XLX host file are smart enough to know what to do with the XLX host file. Thank you for your understanding.

73, de LX1IQ – Luc -

Luc, yes quite right sorry. Once XLX prefix linking using XLX host file is introduced, there will be no need to argue, as XLX will then have independent acess, and usage.