FMP-Map 1.8 HTTPS compatibility relay — development preview

[Pro9578]

I found the earlier RadioReference discussions covering the 2018–2019
stunnel workaround. Those threads helped establish the history of the
problem, but they are closed and predate the current FMP-Map 1.8 /
LRRP 1.27 compatibility approach described here.

I have been working on a compatibility solution for the current
OpenStreetMap tile-download problem in FMP-Map 1.8.

The problem:

FMP-Map 1.8 requests tiles from tile.openstreetmap.org over plain HTTP.
The server now redirects HTTP requests to HTTPS, but FMP-Map does not
follow that redirect. Cached tiles still display, while uncached areas
remain blank or stretched.

The tested approach:

A local compatibility relay temporarily presents itself to FMP-Map as
tile.openstreetmap.org. It accepts FMP-Map's HTTP tile requests, sends
them upstream over HTTPS, and returns the resulting PNG data to FMP-Map.

LRRP's native HTTPS traffic is transparently tunneled through the same
session, so FMP-Map and LRRP can run concurrently and continue sharing
the normal Singles tile cache.

Nothing in FMP-Map, LRRP, or the DSD+ executables is patched.

Current local test results:

- FMP-Map 1.8 bearing display remains intact
- 672 new tiles downloaded in the first manual test
- 191 new tiles downloaded through the automatic launcher test
- FMP-Map HTTP-to-HTTPS relay: PASS
- LRRP HTTPS passthrough: PASS
- exact hosts-file restoration: PASS
- automatic shutdown and port release: PASS
- relay errors: 0

Before sharing a test package, I am completing a release-safety pass.

The community candidate now:

- replaces FMP-Map's generic "Internet Explorer" User-Agent with a
distinct FMPMapHTTPSRelay identity;
- restricts forwarding to OpenStreetMap PNG tile GET/HEAD requests;
- rejects unexpected Host headers and non-tile requests;
- displays visible "© OpenStreetMap contributors" attribution while
FMP-Map is active;
- contains no DSD+ executables, map tiles, personal paths, usernames,
configuration databases, or session logs;
- is intended only for ordinary interactive map viewing, not automated
prefetching or offline tile collection.

No download is attached to this initial post. I am opening the thread
first so it can serve as the public support/contact location included in
the relay's network identity.

I will update this thread after the isolated installer, rollback,
request-header audit, and bounded live test have all passed.

 

[Pro9578]

FMP-Map HTTPS Relay 0.1.0 is now available

The initial public release is attached to this post.

This package provides an HTTPS compatibility path for FMP-Map 1.8 OpenStreetMap tiles while preserving normal FMP-Map and LRRP operation.

It:

• accepts FMP-Map’s local HTTP tile requests and forwards them upstream over HTTPS;
• replaces the legacy Internet Explorer User-Agent with a contactable relay identity;
• transparently tunnels LRRP 1.27 native HTTPS traffic;
• preserves the shared Singles tile cache;
• displays OpenStreetMap attribution when FMP-Map starts;
• automatically restores the original hosts file after FMP-Map and LRRP close;
• installs no boot trigger or continuously running background service;
• includes a complete uninstaller and emergency-cleanup path.

Live-tested with:

• Windows 10 22H2
• PowerShell 7.5.4
• FMP-Map 1.8
• LRRP 1.27

Windows 11 has not yet been separately validated.

Before installation, extract the complete package and run:

VERIFY-PACKAGE.cmd

Then run:

INSTALL.cmd

Known limitation: the FMP-Map attribution plaque appears at startup and its link opens the OpenStreetMap copyright and licensing page. After focus leaves FMP-Map, the plaque may remain hidden until a later clean launch. It is intentionally not made permanently topmost because that could obscure FMP-freqlist location titles and other map information.

This package does not contain DSD+, FMP-Map, LRRP, configuration files, database files, or map tiles.

SHA-256:

10B1CCD13EF4C0B90072E9531A27C85049F83D9920DB1B378B75EADBE150AEB0

This is an independent compatibility utility and is not part of DSD+, RadioReference, or OpenStreetMap.

 

[mtindor]

I was under the impression that the latest DSDplus Public Release and Fast Lane Release do not have this issue. I was under the impression this was resolved. Are you working with old versions?

 

[Pro9578]

I was under the impression that the latest DSDplus Public Release and Fast Lane Release do not have this issue. I was under the impression this was resolved. Are you working with old versions?

Thank you for asking. I did verify this against the newest DSDPlus base files rather than relying only on an old installation.

The current base files still contain FMP-Map 1.8. The exact executable I tested is 77,340 bytes, dated September 23, 2020, with SHA-256:

2BF710A917320DC8B06F2B0C9E96A363A3CE6AB7F452806D90B01AEBFD149955

I confirmed that this FMP-Map 1.8 binary still requests tile.openstreetmap.org over plain HTTP, receives the HTTPS redirect, and does not follow it.

LRRP 1.27 is different: it already supports HTTPS directly. The relay’s local HTTPS tunnel is present only because the hosts override needed for FMP-Map would otherwise redirect LRRP’s HTTPS traffic to the local machine without a passthrough path.

So this is not based on an older FMP-Map version accidentally retained in my installation. The newest base files I checked still supplied the same FMP-Map 1.8 executable.

I would be interested to know whether there is a newer FMP-Map binary or another official configuration change that I may have missed.

 

[mtindor]

Thank you for asking. I did verify this against the newest DSDPlus base files rather than relying only on an old installation.

The current base files still contain FMP-Map 1.8. The exact executable I tested is 77,340 bytes, dated September 23, 2020, with SHA-256:

2BF710A917320DC8B06F2B0C9E96A363A3CE6AB7F452806D90B01AEBFD149955

I confirmed that this FMP-Map 1.8 binary still requests tile.openstreetmap.org over plain HTTP, receives the HTTPS redirect, and does not follow it.

LRRP 1.27 is different: it already supports HTTPS directly. The relay’s local HTTPS tunnel is present only because the hosts override needed for FMP-Map would otherwise redirect LRRP’s HTTPS traffic to the local machine without a passthrough path.

So this is not based on an older FMP-Map version accidentally retained in my installation. The newest base files I checked still supplied the same FMP-Map 1.8 executable.

I would be interested to know whether there is a newer FMP-Map binary or another official configuration change that I may have missed.

I'm not sure FMP-MAP will ever be updated to support SSL. DId you make dsdplusfastlane@gmail.com aware of the issue? There were those of us who made the author aware of the LRRP.exe issues with the HTTPS URLs, and the author fixed that.

Why not just use LRRP.exe?

 

[Pro9578]

No, I had not contacted the DSDPlus author before developing the relay. My immediate goal was to restore the currently distributed FMP-Map 1.8 without modifying any DSDPlus executable or waiting for a possible future update. I agree that a native correction would be preferable long-term, and I am happy to send the reproducible findings to the Fast Lane address.

I do not use LRRP as a substitute because it serves a different purpose in my setup. I use FMP-Map for its frequency/site/bearing workflow with FMP24 and FMP-freqlist. LRRP’s radio-location mapping is not a replacement for that workflow.

The shared Singles cache may also explain why the issue has been easy to overlook. LRRP 1.27 can retrieve fresh tiles over HTTPS, and FMP-Map can later display those cached tiles. That can make FMP-Map appear to be downloading normally. My isolated testing used uncached tiles with FMP-Map running by itself, which is where the HTTP redirect failure is reproducible.

The relay is therefore an interim, reversible compatibility option for users who want FMP-Map working now. It patches no DSDPlus binaries and can be removed cleanly if a native FMP-Map update is released.

 

[mtindor]

No, I had not contacted the DSDPlus author before developing the relay. My immediate goal was to restore the currently distributed FMP-Map 1.8 without modifying any DSDPlus executable or waiting for a possible future update. I agree that a native correction would be preferable long-term, and I am happy to send the reproducible findings to the Fast Lane address.

I do not use LRRP as a substitute because it serves a different purpose in my setup. I use FMP-Map for its frequency/site/bearing workflow with FMP24 and FMP-freqlist. LRRP’s radio-location mapping is not a replacement for that workflow.

The shared Singles cache may also explain why the issue has been easy to overlook. LRRP 1.27 can retrieve fresh tiles over HTTPS, and FMP-Map can later display those cached tiles. That can make FMP-Map appear to be downloading normally. My isolated testing used uncached tiles with FMP-Map running by itself, which is where the HTTP redirect failure is reproducible.

The relay is therefore an interim, reversible compatibility option for users who want FMP-Map working now. It patches no DSDPlus binaries and can be removed cleanly if a native FMP-Map update is released.

Understood. i guess I never knew what FMP-MAP's purpose ever was. I assumed i was another version of the LRRP mapping. Go figure.