Bug #7211
openRepeaterBook query yields: unknown file format
0%
Description
i get the error (Unknown File Format every thin i try to import from repeater book.
hawkdriver
Files
Updated by Jason Faulhefer about 5 years ago
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.
Updated by James Jeffers about 5 years ago
I have also hit this issue. I've attached the debug.log.
OS: Windows 64bit
Build: CHIRP daily-20191029
Updated by James Jeffers about 5 years ago
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
Updated by Steve Covieo about 5 years ago
same issue here cannot get anything to show from repeater book. tried every chirp release as far back as september.
Updated by Erikon Rosamond almost 5 years ago
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.
Updated by Garrett Dow almost 5 years ago
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?
Updated by Michael Adams almost 5 years ago
- File 20191113_224131.jpg 20191113_224131.jpg added
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?
Updated by Jeff Johnson almost 5 years ago
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.
Updated by Jeff Johnson almost 5 years ago
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.
Updated by Dan Smith almost 5 years ago
- Subject changed from unknown file format to RepeaterBook query yields: unknown file format
Sorry, I hadn't seen this because of the unhelpful nondescript title. I just changed it.
Jeff is right, after the last RepeaterBook breakage due to cloudflare I changed chirp to proxy through chirp.danplanet.com so I would have more control over compatibility for the future. It looks like something has changed on the cloudflare or RepeaterBook side yet again to be more strict about SSL ciphers, and it is incompatible with whatever default config the requests library is using in the proxy app.
I will take a look and see what I can do, but I might be limited by where that runs. I won't be able to get to it until next week. Garrett, if there was any change you made recently or are able to relax those requirements on your end that would really help in the short term.
Updated by Jeff Johnson almost 5 years ago
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.
Updated by Dan Smith almost 5 years ago
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.
Updated by Josh Fornwall almost 5 years ago
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
Updated by Dan Smith almost 5 years ago
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.
Updated by Dan Smith almost 5 years ago
The hack was server-side, so ... just try a query from within chirp and let me know if it works now.
Updated by Walt Weber almost 5 years ago
Using 20191206 daily on Win32, "Import from Data Source -> RepeaterBook -> political query " succeeded on 11 December 2019.
Updated by Walt Weber almost 5 years ago
Seems as though the server-side hack worked, Dan -- maybe the status of "new" should be updated/changed?
Updated by John Mendyka almost 5 years ago
I'm still having this issue as well. This is very frustrating.