Project

General

Profile

Actions

Bug #7211

open

RepeaterBook query yields: unknown file format

Added by Al Nagy about 5 years ago. Updated almost 5 years ago.

Status:
New
Priority:
High
Assignee:
-
Category:
-
Target version:
-
Start date:
11/05/2019
Due date:
% Done:

0%

Estimated time:
Chirp Version:
daily
Model affected:
(All models)
Platform:
Windows
Debug Log:
I read the instructions above:

Description

i get the error (Unknown File Format every thin i try to import from repeater book.
hawkdriver


Files

debug.log (22.5 KB) debug.log debug.log James Jeffers, 11/07/2019 12:51 PM
20191113_224131.jpg (4.32 MB) 20191113_224131.jpg just a empty tab Michael Adams, 11/13/2019 07:44 PM

Related issues 4 (1 open3 closed)

Has duplicate Bug #7293: Repeaterbook errorRejected11/17/2019

Actions
Has duplicate Bug #7263: Repeaterbook errorRejected11/12/2019

Actions
Has duplicate Bug #7207: unknown file formatClosed11/05/2019

Actions
Has duplicate Bug #7553: Cannot import data from either RepeaterBook or RadioReferenceNew01/12/2020

Actions
Actions #1

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.

Actions #2

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

Actions #3

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

Actions #4

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.

Actions #5

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.

Actions #6

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?

Actions #7

Updated by Michael Adams almost 5 years ago

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?

Actions #8

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.

Actions #9

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.

Actions #10

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.

Actions #11

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.

Actions #12

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.

Actions #13

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
Actions #14

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.

Actions #15

Updated by Bob Kepford almost 5 years ago

How can I help test your hack?

Actions #16

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.

Actions #17

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.

Actions #18

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?

Actions #19

Updated by John Mendyka almost 5 years ago

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

Actions

Also available in: Atom PDF