CHIRP

I confirmed this as well. Import no longer works with that error. And Query seems to work except the new tab is empty. Doesn't populate the query.

James Jeffers wrote:

I have also hit this issue. I've attached the debug.log.
OS: Windows 64bit
Build: CHIRP daily-20191029
device: BF-F8HP

same issue here cannot get anything to show from repeater book. tried every chirp release as far back as september.

Getting the same "Unknown file format" when importing from repeaterbook data source.
Having same issue that Query works but populates an empty tab.
Latest build of Chirp and 64bit Windows.

This is Garrett, KD6KPC, owner of Repeaterbook.com. I am trying to troubleshoot. I saw that the firewall was blocking some instances because of a failed browser integrity check. I turned that off and the problem persists. Is there a way to see what data the query is returning?

Michael Adams wrote:

Garrett Dow wrote:

This is Garrett, KD6KPC, owner of Repeaterbook.com. I am trying to troubleshoot. I saw that the firewall was blocking some instances because of a failed browser integrity check. I turned that off and the problem persists. Is there a way to see what data the query is returning?

When I do a wget on 'http://chirp.danplanet.com/query/rb/1.0/app_direct?loc=96003&band=14&dist=25', which is from a log file the server returns: ERROR 500: Internal Server Error. I don't know enough to tell if the parameters being passed in are bad or if the server has a problem.

To be more clear, chirp goes through chirp.danplanet.com as a proxy to get data from repeaterbook.com. There appears to be a problem with the server on the danplanet.com website that is returning status=500. This seems to have changed around April. A direct query to repeaterbook.com (as per the pre-April code) seems to return just the header, but I could have the parameter wrong.

When I revert to version 3220, which goes directly to repeaterbook.com it works. It just uses the URL:
http://www.repeaterbook.com/repeaters/downloads/chirp.php?func=default&state_id=06&band=%%&freq=%&band6=%&loc=%&county_id=085&status_id=%&features=%&coverage=%&use=%
I can also put that URL into a browser and download the data. Since it is http, SSL shouldn't be involved, but I have no experience with cloudflare and what it might require.

Okay one of the original problems was that cloudflare was redirecting to https and urllib2 in python2 was having trouble with that. So the proxy just goes straight to the new URL, which is https. If that has changed to allow http-only again, then I should be able to flip the proxy. I can try that when I get home and see.

While it appears the link returns without error, the content seems to be only the headers, regardless of parameters:

HTTP/1.1 301 Moved Permanently
Date: Sat, 16 Nov 2019 19:22:27 GMT
Transfer-Encoding: chunked
Connection: keep-alive
Cache-Control: max-age=3600
Expires: Sat, 16 Nov 2019 20:22:27 GMT
Location: https://www.repeaterbook.com/repeaters/downloads/chirp.php?func=default&state_id=26&band=14&loc=%&call=%&use=%
Server: cloudflare
CF-RAY: 536bd572a8f97e2b-DTW

HTTP/2 200
date: Sat, 16 Nov 2019 19:22:28 GMT
content-type: application/vnd.ms-excel
set-cookie: __cfduid=d9f58c5cc3b0c572cd4d4fe1aec3a94a71573932147; expires=Sun, 15-Nov-20 19:22:27 GMT; path=/; domain=.repeaterbook.com; HttpOnly; Secure
x-powered-by: PHP/5.6.40
content-disposition: attachment; filename=RepeaterBook_CHIRP_1911161422.csv
content-description: PHP Generated Data from RepeaterBook.com
set-cookie: 233fb5a3823cc98b910bb80ee84e8e0c=c702287a8f3e42f95eb3e3b5c2e888cc; path=/; domain=.repeaterbook.com; secure; HttpOnly
vary: Accept-Encoding,User-Agent
cf-cache-status: DYNAMIC
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
server: cloudflare
cf-ray: 536bd5735af77e3d-DTW

Location,Name,Frequency,Duplex,Offset,Tone,rToneFreq,cToneFreq,DtcsCode,DtcsPolarity,Mode,TStep,Comment

Okay I put in a really (really) gross hack, which seems to work for the moment. Can someone else confirm?

Garrett, if you are able to revert whatever recent SSL version handshake change caused this regression, or allow non-HTTPS traffic to the relevant URLs, that would really help out.

How can I help test your hack?

The hack was server-side, so ... just try a query from within chirp and let me know if it works now.

Using 20191206 daily on Win32, "Import from Data Source -> RepeaterBook -> political query " succeeded on 11 December 2019.

Seems as though the server-side hack worked, Dan -- maybe the status of "new" should be updated/changed?

I'm still having this issue as well. This is very frustrating.