PAN-OS 8.0 MineMeld EDL Error: Downloaded file is not a text file

[aantony]

Minemeld EDL feed is failing with error in PAN-OS 8.0. Error: "Downloaded file is not a text file Using old copy for refresj." What am I missing here ?

[lmori]

Hi @aantony,

I think I have answered to your question on Slack, but for posterity most probably the problem is a bug in 8.0.0 that has been fixed in 8.0.1.

luigi

[vb0398]

I'm not sure if this is the right location for this conversation, but I'm not sure what would be the apporpriate group....

I have PAN-OS 8.06 installed, and I'm trying to download a text file as an EDL (similar to how you would download a file from minemeld), however, the URL contains an access key for authentication (i.e., the URL looks like http://someurl.com/file.txt?access_id=<access_id>) 

I'm assuming this is causing the "Downloaded file is not a text file" error message.  However, the file is indeed a text file.

Has anybody had this issue before?

Thanks for your time...

[lmori]

Hi @vb0398,

that error is a generic message error. I would probably start from doing a tcpdump on the management interface to see what's wrong with the communication with the remote server. It could be anything from wrong URL to incompatible sets of SSL ciphers.

[Mike.ship]

Definitely not fixed in 8.0.1 because we are running 8.0.6-h3 and it has started happening to us now as well.

[Scott_Dentler]

I'm seeing this issue with PAN-OS 8.0.8.

Any idea's to start troubleshooting would be great!

[lmori]

Hi @Scott_Dentler,

that error is misleading. I would start from checking the ms.log file for additional details, like:

- Certificate Error

- Authentication Errors

...

[Scott_Dentler]

Thanks lmori, 

I found a solution to my problem at least.  It just took some trial and error.  I thought my problem was I had a trailing "?tr=1" at the end of my Minemeld server I needed to remove.

For example:

The Objects > External Dynamic LIsts > O365-IPv4, the Source was: 

      http://minemeld_server.mydomain.com/feeds/office365_IPv4s?tr=1

With "?tr=1" listed the IPs in CIDR notation (13.107.6.156/31)

Without  "?tr=1" listed the IPs as IP ranges (13.107.6.156-13.107.6.157)

As soon as I dropped the "?tr=1" it worked great!

------------

On another note, it's broken again.

Palo Alto Documentation says the correct syntax is either format so I don't know why it stopped working... and yes, that means it was working for at least a month, then on 03/22/2018, it started erroring out... 

Now that I'm typing this, it appears to be happening again.

Removing the "?tr=1" fixed it from to 5/03 - 5/16, but now it's erroring out again.  ugh... 

[LydiaP]

Hi Scott, 

Did you manage to find a solution for this?