Anyone else unable to download newtiles??
DSDPlus LRRP tiles
- Thread starter PDXh0b0
- Start date
I don't use LRRP much, but was doing some testing while on the road and wanted to see what I was receiving data for. I too had the same issue, so it looks like I wasn't the only one.
Tile Usage Policy
operations.osmfoundation.org
The tiles come from OpenStreetMap's servers. They don't guarantee uptime. Plus I guess it's possible DSDPlus doesn't do one or more of the MUSTS, or does one or more of the MUST NOTS.
Mike
Same! I seem to be having the same issue here. I see the map, but the more you zoom in on a specific location, the blurrier the map becomes.
There have been no updates on my end recently to DSD+ or anything similar. It just stopped working on its own....Strange. I tried loading a random tile from a URL on the web, and the tile(s) load fine. It might be an issue with DSD+.
Any workaround for this to get the tiles to load corectly?
There have been no updates on my end recently to DSD+ or anything similar. It just stopped working on its own....Strange. I tried loading a random tile from a URL on the web, and the tile(s) load fine. It might be an issue with DSD+.
Any workaround for this to get the tiles to load corectly?
Last edited:
Not that I'm aware of. Apparently OpenStreetMaps either is having difficulties in general OR has problems with the way DSDPlus may have been fetching tiles historically. I emailed the author when it was first reported, so he/she/it is aware
There is a thread here
community.openstreetmap.org
that says changes were made in July and again in August at OpenStreetMap. I would guess that is the source of the issues. The post is the announcement of changes but the conversation seems to include the folks who work on the system. There was additional info about a second update within the replies.
Technical updates to the tile.openstreetmap.org service (OpenStreetMap.org Standard Layer)
Right, but the standard browser user agent is (was) not allowed by OSM. I think according to the terms of use that the name of the App is expected in the user agent when there is no referrer header. (I was able to get the tiles to load by temporarily changing the user agent in developer tools -...
community.openstreetmap.org
Interesting, I don't get any tiles that indicate it was "blocked" due to a policy reason. So either they are blocking IP addresses, or DSDplus is pointing to a now defunct source for the tiles or something. Otherwise I'd expect if it was an incorrect user agent or lack of attribution or something like that, we'd all be seeing tiles come up with a notice of why each tile's access has been blocked.
The LRRP may not be capable of HTTPS. I believe normally it uses HTTP to call the tiles. And at least at this moment, OSM automatically redirects HTTP requests to HTTPS. If LRRP doesn't support HTTPS, that's the issue.
m
The LRRP may not be capable of HTTPS. I believe normally it uses HTTP to call the tiles. And at least at this moment, OSM automatically redirects HTTP requests to HTTPS. If LRRP doesn't support HTTPS, that's the issue.
m
Yeah, I agree, this is not an OpenStreetMap problem—the tiles on the web load without any issues for me.
I think this might be the actual issue here. That DSD may be having a problem grabbing the tiles from OSM. I was trying to find a configuration file in DSD that allowed me to change the data source, but I couldn't locate one; it must be hardcoded into the program.
I believe I saw this explained in the notes.txt for a LRRP.exe update a few months ago.
Found it this morning, around line 1760. It explains something about using stunnel. All tho I still haven't gotten it to work. But I can try again. Here's the direct quote from the note.txt file
Code:
LRRP 1.15
Code changes have reduced the size of the LRRP.exe file by 35 kB
User-selected distance units (miles or km) are now saved in the LRRP.cfg file
Pressing 'B' now moves the LRRP map display to the background, i.e. behind all other
visible windows. LRRP.exe remains in focus, which lets you manipulate the map while
other windows (DSD+. FMP24/FMPA) are visible in the foreground.
LRRP.exe uses the HTTP protocol to connect to Open Streetmap servers to download map tiles,
but those servers now only accept HTTPS connections. We will not be modifying LRRP.exe
to use HTTPS; instead, LRRP.exe now makes local HTTP connections to port 3000.
To enable retrieval of OSM map tiles, users must download and install the stunnel proxy.
The current download location is: https://www.stunnel.org/downloads
Download and run stunnel-x.xx-win32-installer.exe
The stunnel installer will walk you through the setup process.
Install stunnel for all users and select all of the default choices.
In the text window that opens, just press Enter at each prompt.
The stunnel.conf file has to be edited; these lines should be present at the end of the file:
[mylocalproxy]
client = yes
accept = 127.0.0.1:3000
connect = tile.openstreetmap.org:443
When stunnel is installed and configured correctly, LRRP.exe will be able to download
OSM map tiles through the stunnel proxy.
Last edited:
In addition to my post above. It appears that the stunnel program is only needed for LRRP 1.15. In the Notes.txt file for LRRP 1.17, it states that stunnel is not required for OSM to function. Im using LRRP 1.26 (latest).
Im at a loss here lol. I guess my question is: Is there a way to change the OSM data source in DSD+? It must be hardcoded into the program. I was going to check if the link that DSD+ is using to retrieve tiles from OSM is broken or not, and if I can modify it to point correctly from my end.
Mike @mtindor, you mentioned that you emailed the DSD+ authors about this issue. Any Response?
Code:
LRRP 1.17
Open Streetmap servers have returned to accepting HTTP connections, so the stunnel
program is currently not needed to download map tiles. LRRP 1.17 connects directly
to the Open Streetmap servers instead of relying on HTTPS connections through stunnel.Im at a loss here lol. I guess my question is: Is there a way to change the OSM data source in DSD+? It must be hardcoded into the program. I was going to check if the link that DSD+ is using to retrieve tiles from OSM is broken or not, and if I can modify it to point correctly from my end.
Mike @mtindor, you mentioned that you emailed the DSD+ authors about this issue. Any Response?
Tried stunnel myself, no luck there. I believe lrpp is blocked because it doest give accreditation on the map
They said they think it's the HTTPS thing again. So at this time you will have to use stunnel -- and probably forever into the future, because I doubt OSM will revert back to allowing access to the tiles over HTTP, and from the notes.txt file it looks like the author has no plan in the future to ever add support for HTTPS in the LRRP app itself.
If that were the case, you'd see a screenfile of tiles indicating that it blocked due to lack of attribution.
Ok thanks! I just tried to get stunnel up and running and had no luck again. I might be missing something. Im a little slow lol. Im having trouble getting past this step:
Code:
The stunnel.conf file has to be edited; these lines should be present at the end of the file:
[mylocalproxy]
client = yes
accept = 127.0.0.1:3000
connect = tile.openstreetmap.org:443
When stunnel is installed and configured correctly, LRRP.exe will be able to download
OSM map tiles through the stunnel proxy.I have the [mylocalproxy] entry in the stunnel.conf file. However, it doesn't seem to be connecting correctly, as per the stunnel log and the LRRP app. Any guidance would be appreciated. TIA.
Wish I could help. I don't use stunnel. I did install the latest version though and get the same message. I'm guessing older versions (that were available back when DSDPlus notes were added with stunnel instructions) did not concern themselves with MITM attacks and thus didn't require authentication. It's probably going to require an SSL cert or some keys of some sort to be generated and then added to the conf file under the server and client sections in order for it to work.
Ok, Thanks for your help, Mike!
This stuff is a headscratcher for me for sure. Frustrating. I want it to work because I believe the LRRP map in DSD+ is the best map available compared to some other programs. However, it's weird that this happened all of a sudden when everything was working fine before (a week ago or so). Something must have happened on the backend, likely due to conflicts with the OSM HTTPS and its communication with DSD+. Hopefully, a solution other than stunnel can be found.
I started working on something in stunnel with PSK auth. Not successful yet, but probably because I'm confused about the PSK Server / PSK Client IP/Port information that needs to be entered. If I get it working I'll be sure to share. Wont' be tonight though. Sleep is calling.
I'm guessing that in those notes, the current version of LRRP at that time was purposefully set up to NOT connect directly to OSM but to stunnel, and that the newest version might be set up to connect directly to OSM. I'll have to see if I can come up with copy of LRRP 1.15 to test with the stunnel I have running now with PSK auth.
Forget that mumbo jumbo above. I'm probably wrong about that 3000 stuff too. But I'll work on things tomorrow when I'm in the right headspace.
Last edited:
Ok a few things.
1. the author does intend to remedy the current LRRP.exe situation
2. LRRP 1.15 should work (and will be available on the server to download soon) with stunnel
3. The latest LRRP will not work with stunnel
4. Once LRRP.exe 1.15 is on the server and I have figured out how to make it work with the latest stunnel I'll post the info
5. Keep in mind that a lot of things were done with LRRP.EXE since 1.15 (see notes.txt) so support for some things wont exist in 1.15
But it's a potential workaround until #1 above occurs.
1. the author does intend to remedy the current LRRP.exe situation
2. LRRP 1.15 should work (and will be available on the server to download soon) with stunnel
3. The latest LRRP will not work with stunnel
4. Once LRRP.exe 1.15 is on the server and I have figured out how to make it work with the latest stunnel I'll post the info
5. Keep in mind that a lot of things were done with LRRP.EXE since 1.15 (see notes.txt) so support for some things wont exist in 1.15
But it's a potential workaround until #1 above occurs.
Ok. IF you want LRRP to work right now AND you download the latest version of stunnel (that barks about MITM attacks) AND you are okay with the fact that you are using a version of LRRP.EXE that is 7 years old and missing some things, proceed.
1. Download the old LRRP.EXE
- this is LRRP 1.15 from 2018
- rename your current LRRP.EXE and then unzip this and put it in your DSDPlus folder
Now, for the latest stunnel (and it's complaining about MITM attacks)
2. Add some files to support PSK authentication in stunnel:
In c:\users\<user>\AppData\Local\Programs\stunnel\config\ directory , create the following files :
And of course you chould change those test1 lines to something else. You never have to type it in. That's just authenticating the PSK client with the PSK server.
3. in the Stunnel GUI, edit the configuration and reload -- adding right above the Gmail stuff:
[PSK server]
accept = 3001
connect = 3002
ciphers = PSK
PSKsecrets = psk.txt
[PSK client 1]
client = yes
accept = 127.0.0.1:3002
connect = localhost:3001
PSKsecrets = psk1.txt
4. Reload the stunnel.conf configuration via the GUI
5. Fire up the old LRRP.exe
Works for me. Just keep in mind that there are certain things not supported in LRRP 1.15 that are supported in the latest version. Track through notest.txt to see what will be missing.
Mike
1. Download the old LRRP.EXE
- this is LRRP 1.15 from 2018
- rename your current LRRP.EXE and then unzip this and put it in your DSDPlus folder
Now, for the latest stunnel (and it's complaining about MITM attacks)
2. Add some files to support PSK authentication in stunnel:
In c:\users\<user>\AppData\Local\Programs\stunnel\config\ directory , create the following files :
Code:
psk.txt
-------
test1:oaP4EishaeSaishei6rio6xeeph3az
psk1.txt
---------
test1:oaP4EishaeSaishei6rio6xeeph3azAnd of course you chould change those test1 lines to something else. You never have to type it in. That's just authenticating the PSK client with the PSK server.
3. in the Stunnel GUI, edit the configuration and reload -- adding right above the Gmail stuff:
[PSK server]
accept = 3001
connect = 3002
ciphers = PSK
PSKsecrets = psk.txt
[PSK client 1]
client = yes
accept = 127.0.0.1:3002
connect = localhost:3001
PSKsecrets = psk1.txt
4. Reload the stunnel.conf configuration via the GUI
5. Fire up the old LRRP.exe
Works for me. Just keep in mind that there are certain things not supported in LRRP 1.15 that are supported in the latest version. Track through notest.txt to see what will be missing.
Mike
Attachments
Last edited:
