Forum Discussion

John_Buchanan_1's avatar
John_Buchanan_1
Icon for Altocumulus rankAltocumulus
Jan 12, 2016

ASM policy import Error: Malformed XML: DBD::mysql::db do failed: Duplicate entry

When trying to re-import a policy I had exported (I turned off staging for all new signatures using search/replace function of my text editor), I run in to the following error:

 

Error: Malformed XML: DBD::mysql::db do failed: Duplicate entry '20-ýf-1.2 %âãÏÓ 1 0 obj <

 

Is this most likely due to one of the oddly named parameters contained within my policy, or some unrelated issue?

 

Big-IP is running 11.6.0 HF5, I exported the active policy, turned off staging for signatures, and then attempted to re-import policy as an inactive policy, and receive this error.

 

If I export/import my policy in binary format it re-imports without error, but of course then I cannot modify it in a text editor.

 

ASM Advanced WAF
security
waf

3 Replies

Sort By
  • Arnaud_Lemaire's avatar
    Arnaud_Lemaire
    Icon for Employee rankEmployee
    Jan 15, 2016

    Hello John,

     

    if you did not edited the xml file (which could change some charater encoding) i would log a case to F5 support. from the last comment it seems you edited it, if i open a policy exported on a windows machine with notepad++ i can see that encoding is UTF-8 without BOM. test with another advanced editor to see if you did not change it during your edit.

     

  • John_Buchanan's avatar
    John_Buchanan
    Icon for Nimbostratus rankNimbostratus
    Jan 18, 2016

    Was hoping what you'd mentioned was the key, but this happens even without opening/editing the policy file. I can export from my first ASM pair and immediately attempt to import to my 2nd ASM pair and I receive this error. Is it possible that some unusual character(s) or syntax in one of my named parameters could cause this?

     

    I think I'll try one or two more things and then reach out to F5 directly.

     

  • John_Buchanan's avatar
    John_Buchanan
    Icon for Nimbostratus rankNimbostratus
    Jan 18, 2016

    I discovered that this was due to parameters defined within my policy with unusual names that were also nearly identical across my two ASM pair. I am once again able to import my policy from pair 1 on pair 2, and vice versa. I'll have to find another way to prevent these unusually named parameters from being flagged as injection attempts.