Upgrade to 2.0 loses config [SOLVED - international characters]

[jbp]

Hello,

I have a pfSense 1.2.3 box which I tried to upgrade to 2.0-RC1-i386-20110322-2318. I did the following:

1. Backed up the config from the main firewall
2. Fresh installed pfSense 1.2.3 on a new box and restored the config from the main firewall
3. Matched up the interfaces on the new box
4. Rebooted

After the reboot I am asked to configure the interfaces. This seems strange - the old interface configuration, firewall configuration - in fact the entire configuration - is GONE!

If I try to configure the interfaces again I get loads of errors such as:

Warning: Cannot use a scalar value as an array in
/etc/inc/config.lib.inc on line 513

Warning: Invalid argument supplied for foreach in
/etc/inc/xmlparse.inc on line 211

then the error:
"Network interface mismatch - running interface assignment option"

It doesn't matter what I enter from now on, the loop continues.

[UnderCover]

from what I have seen in other posts

double check the configuration for any international characters

[jbp]

Thanks for the hint. I tried with no international characters, but my config still gets hosed :(

[eri--]

Without posting your config either privately or attach it here no comments can be given.

[jbp]

You were right! I had  öäüß characters hidden in vpn descriptions. Thanks!

Can we make this a bug or a sticky?

[jlepthien]

@jbp:

You were right! I had  öäüß characters hidden in vpn descriptions. Thanks!

Can we make this a bug or a sticky?

It is not a bug. You should never ever use such characters in firewall products. Always dumb to do so…
Had this with lots of customers and this is not a pfSense specific problem...

[jbp]

@jlepthien:

It is not a bug. You should never ever use such characters in firewall products. Always dumb to do so…

I can't use characters from my own language? Why not?

Anyway, the reason this is a bug is that pfsense accepts characters which it does not support.

[eri--]

Well surely its evolutional but we are working on getting this fixed on the way.

[jlepthien]

@jbp:

@jlepthien:

It is not a bug. You should never ever use such characters in firewall products. Always dumb to do so…

I can't use characters from my own language? Why not?

Anyway, the reason this is a bug is that pfsense accepts characters which it does not support.

IT is international stuff. German words or umlauts in configs? Please…

[jbp]

We have two cases here:

1. pfsense lets people use characters from their own languages (until now)
2. pfsense doesn't let people use characters from their own languages
-> pfsense should reject characters it doesn't support.

[jbp]

@ermal:

Well surely its evolutional but we are working on getting this fixed on the way.

Thanks ermal.

[jimp]

@jbp:

We have two cases here:

1. pfsense lets people use characters from their own languages (until now)
2. pfsense doesn't let people use characters from their own languages
-> pfsense should reject characters it doesn't support.

They are supported in 2.0 where it's feasible to do so, they were not supported in 1.2.3, they just happened to work without exploding the config in certain specific spots. Other spots would explode the config there. Congratulations, you stepped on a land mine and it didn't go off.

The way the characters were stored in the config in 1.2.3 was invalid XML, it doesn't meet the spec, which is why the config is now rejected on 2.0. If you run your 1.2.3 config through a standard xmllint tool it will show you that they are invalid XML.

On 2.0 in description fields and some others that can take such characters, we CDATA escape the values so that they are properly handled in XML.