What are some workarounds / fixes for UTM/IDP on Junos 12.1X44-D10.4 for SRX Series branch devices?

Question

The JNCIP / JNCIE-SEC latest courses use 12.1X44-D10.4 as the recommended Junos version. I setup a 30-day evaluation on my home SRX device to study JIPS, based on 12.1. At this point, I'm guessing that my problem is that trial licenses for 12.1X44-D10.4 might be equivalent to 12.2, 12.3, or entirely not supported. Here's what I'm trying now:

netops> request security idp security-package download full-update    
Will be processed in async mode. Check the status using the status checking CLI

root> request security idp security-package download status         
In progress:SignatureUpdate_tmp.xml.gz                          100 % 2034681 Bytes/ 2034681 Bytes

root> request security idp security-package download status    
Done;File applications.xml.gz is corrupt - MD5 hash match failed

Since the license installed properly (but not the IDP signatures), I was also going to manually request a download with the proper URL parameters (mentioned in KB19502)

I've had no luck on Juniper.net, but here are my planned next steps:

• Sniff the traffic / figure out which version it's trying to download
• Manually request a download, eg. https://services.netscreen.com/cgi-bin/index.cgi?device=jsrx650&feature=idp&os=10.3&detector=10.4.160100823&from=1817&to=1805&type=update
• Talk to my Juniper rep this week (and yes, I'm adding support on this device). Edit: opened a Customer Care ticket with Juniper, as it's a new device. Will follow up with resolution.
• I'm reading through the techpubs/documentation to see if there are any additional steps that could be causing this to fail, but I've tried the usual suspects like name resolution, system time/NTP, etc. etc.

Edit: downgrading to 12.1R5.5 did not fix the issue, and I'm still getting corrupt/md5 hash match failed. This does not appear to be due to lack of storage, which could cause weird errors like this.

Answer 1

It appeared this was an easy fix (I also tried 12.1R6.5 and 12.1X44-D11.5, to no avail).

First, I looked at the version of the signature DB that it's trying to download (2263):

 netops> request security idp security-package download check-server    
 Successfully retrieved from(https://services.netscreen.com/cgi-bin/index.cgi).
 Version info:2263(Detector=12.6.160130325, Templates=2263)

Then, I decided that this is possibly an actual bad md5 checksum (per what Junos expects), and I downloaded the previous version, 2262:

 netops> request security idp security-package download version full-update 2262    
 Will be processed in async mode. Check the status using the status checking CLI

It worked! I've had to do something similar on Netscreen, but it's been a while. I turned off automated updates, and I can get back to studying.

 netops> request security idp security-package download status    
 Done;Successfully downloaded from(https://services.netscreen.com/cgi-bin/index.cgi).
 Version info:2262(Tue May 14 16:27:00 2013 UTC, Detector=12.6.160130325)

Now that the download is finished, everything is installing properly:

 netops> request security idp security-package install          
 Will be processed in async mode. Check the status using the status checking CLI

 netops> request security idp security-package install status 
 In progress:performing DB update...

 netops> request security idp security-package install status    
 In progress:performing DB update for an xml (groups.xml)

 netops> request security idp security-package install status
 In progress:performing DB update for an xml (applications.xml)

 etc.

 netops> request security idp security-package install status    
 Done;Attack DB update : successful - [UpdateNumber=2262,ExportDate=Tue May 14 16:27:00   2013 UTC,Detector=12.6.160130325]
 Updating control-plane with new detector : successful
 Updating data-plane with new attack or detector : not performed
  due to no active policy configured.

I'm thinking that this is either a bug in SRX110H-VA, a combination of hardware/software release, or bad signature updates on services.netscreen.com. I'm pretty sure that I could just look through the XML, and figure out where the bad md5sum is (and fix it by hand), but I'll follow up once I hear back from Juniper.

Newest edit: I also had to manually download the policy template from Juniper, extract it with gzip -d templates.xml.gz, and place it in /var/db/idpd/sec-download/sub-download/. Once that was done, I was able to install it. The issue here is that the request security idp security-package install policy-templates command does not take a 'version', like the other idp commands. This will always be an issue when the head IDP policy has md5 errors, although I would hope that this isn't a frequent occurrence at Juniper.

 netops> request security idp security-package install policy-templates 
 Will be processed in async mode. Check the status using the status checking CLI

 netops> request security idp security-package install status              
 Done;policy-templates has been successfully updated into internal repository
 (=>/var/db/scripts/commit/templates.xsl)!