Error running weathercan package - fatal SSL/TLS alert (e.g. handshake failed))

1

I am running the "weathercan" data package (https://cran.r-project.org/web/packages/weathercan/index.html; https://github.com/ropensci/weathercan) and keep getting an error when trying to retrieved data from the Environment and Climate Change historic weather data website. I've re-installed the package, I even reinstalled R and RStudio after deleting everything R from my system, but the error persists.

The package works fine when I look up stations up, e.g.,

stations_search(coords = c(44.140125, -80.363136), dist = 20, interval = "day")

I get: enter image description here

But whenever I try to retrieve data I get an error. For example:

Station_data <- weather_dl(station_ids = 4497, start = "2000-01-01", end = "2002-05-30", interval = "day")

Returns:

Error: Problem with mutate() input html. x schannel: next InitializeSecurityContext failed: SEC_E_ILLEGAL_MESSAGE (0x80090326) - This error usually occurs when a fatal SSL/TLS alert is received (e.g. handshake failed). i Input html is purrr::map(...).

enter image description here

Run rlang::last_error() to see where the error occurred, give this:

<error/dplyr:::mutate_error> Problem with mutate() input html. x schannel: next InitializeSecurityContext failed: SEC_E_ILLEGAL_MESSAGE (0x80090326) - This error usually occurs when a fatal SSL/TLS alert is received (e.g. handshake failed). i Input html is purrr::map(...). Backtrace:

  1. weathercan::weather_dl(...)
  2. base::.handleSimpleError(...)
  3. dplyr:::h(simpleError(msg, call)) Run rlang::last_trace() to see the full context.

This is all beyond my understanding, so I'm stuck here.

Any insights would be helpful.

Thanks

r
ssl
dplyr
purrr
handshake
asked on Stack Overflow Oct 1, 2020 by TAD

1 Answer

1

[Update 2020-10-17]

This solution has also been reported on the weathercan issue

It looks like curl uses two SSL backends for Windows: OpenSSL and Windows Secure Channel. By default curl uses the Windows Secure Channel which is supposed to be best, but doesn't quite have the full functionality of OpenSSL (more details).

My best guess is that something changed on the ECCC server that required a functionality not provided by Windows Secure Channel. When I forced my windows testing platform (AppVeyor) to use OpenSSL I had no more problems.

If you would like to try this, you'll have to add the following to your .Renviron file (which is loaded during R's startup):

CURL_SSL_BACKEND=openssl

If you're unsure how to edit your .Renviron file, you can use the usethis package to find/create and open it for you (restart R afterwards):

install.packages("usethis")
usethis::edit_r_environ()

Disclaimer: I don't think there are security drawbacks for doing this, but I'm not a network specialist by any stretch!


[Original Answer]

I'm the developer of the weathercan package. Unfortunately I have some details for you but not exactly a solution.

I've been trying to track down the origins of this problem. From what I can see it's actually problem between R and the ECCC server, which (so far) only seems to crop up on Windows, but not for everyone (I run Ubuntu 20.04 and Windows 10 and can't reproduce it, but others on Windows 10 and 8 have run into the problem).

You can follow the discussion in a reported issue, here: https://github.com/ropensci/weathercan/issues/104

The reason why we think this isn't strictly a weathercan issue is because if users with this problem try to download an ECCC file directly, e.g.,

read.csv("https://climate.weather.gc.ca/climate_data/bulk_data_e.html?format=csv&stationID=51097&timeframe=1&submit=Download%2BData&Year=2020&Month=10")

they run into a similar problem (and read.csv() is a function from the utils package).

answered on Stack Overflow Oct 15, 2020 by Steffi LaZerte • edited Oct 17, 2020 by Steffi LaZerte

User contributions licensed under CC BY-SA 3.0