error(s) loading the rules after upgrade to 2.4.4-1

[pranav]

@jimp ,

Actualy it's LAN in upper case at both places and system absolutely takes it.
To prove it, here is output screenshot of /tmp/rules.debug where you can see "LAN" is listed in system aliases with value "{ em0 }" and under user alias also we have it listed there.

You are right about expected behavior that it should not allow me. However, in reality UI does allow me to create user alias of same name used for system alias (interface name).

[jimp]

I'm trying to figure out how it was allowed, however. I can't reproduce it here. It kicks back the alias and won't let me save it when it has that name.

So for me, I cannot:

• Create a new alias using the same name as an existing interface
• Rename an alias to the same name as an existing interface
• Rename an interface to the same name as an existing alias

I even tried using a mix of upper/lowercase to see if it would sneak by, but it was always caught and rejected.

[pranav]

Here is my version/build info.

2.4.4-RELEASE-p1 (amd64)
built on Mon Nov 26 11:40:26 EST 2018
FreeBSD 11.2-RELEASE-p4
The system is on the latest version.
Version information updated at Thu Dec 27 15:43:31 UTC 2018

Given this is VM on ESX, I can export it and send it to you. Let me know if that helps you better understand how this could be occurring.

[jimp]

Seeing it that state won't help as it won't explain how you managed to get it into that state, when all signs point to the input validation correctly rejecting what you are attempting when anyone else does it.

Remove the alias and try to add it back again, see if you receive an error or if it still lets you create it.

[pranav]

I removed alias to resolve following error.

"There were error(s) loading the rules: /tmp/rules.debug:45: syntax error - The line in question reads [45]: scrub on $LAN all fragment reassemble"

when you expressed that I should get error from input validation, i tried to add it back like you said and i was able to add it successfully and re-produce error.

In short, input validation you are referring to is not functioning as expected.

I am able to remove and re-add it successfully.

[jimp]

What does the config.xml section for your LAN interface look like?

[pranav]

@jimp

GUI shows all interface name in upper case including "LAN".

whereas, config.xml reads all name in lower case. This is another issue with GUI.

So, I tried to create another alias named "lan" in lower case and I got input validation error such as "Cannot use a reserved keyword as an alias name: lan"

So, answer to earlier question, how I got to this point is.

Any interface name given in upper case is shown as it is. However, due to bug interface names are stored in lower case in config.xml

This highlights fact that GUI is reading config info from some intermediate place other then config.xml.

Due to this when i upgraded from version 2.4.4 to 2.4.4-RELEASE-1, it absorbed everything from old config.xml including buggy GUI that kept showing uppercase interface name and errored config.xml which could not load all previously configured rules.

By removing user alias "LAN" I could address loading of all rules.

GUI is not reading from config.xml is still an issue and requires detail investigation and attention of expert such as yourself.

[jimp]

Seeing the GUI doesn't tell much, though, I need to see the exact block of config.xml for the <lan>...</lan> interface or at least the <descr> value, but preferably the whole block. You can mask/remove the IP address if you need to.

Looking at the alias page and interfaces page it already does a case insensitive match on the description vs alias name, however. I see one place that doesn't, where it checks for the reserved words, but even with that I still can't make it happen. I set the LAN interface to a description of lan and I still can't make an alias named lan or LAN.

[pranav]

Attached here are two blocks.

1. interfaces block from config.xml
2. aliases block from config.xml

1_1545944429878_interfaces_block_from_config.xml 0_1545944429878_aliases_block_from_config.xml

[jimp]

Your LAN interface has no <descr> tag which would explain why it is not checking it as expected. So it probably is that reserved keyword part that isn't matching as expected.

If you edit and save your LAN interface it should populate that tag and then it would kick that back.

I'll try to reproduce it here that way.

[jimp]

Yep, that did it. Issue here: https://redmine.pfsense.org/issues/9231

Fix pushed, will show up on Redmine shortly.