1.2.0 RC9 - Limitation to Number of Address Groups

So full disclosure!
I’ve been testing this bug on a UBNT EdgeRouter Infiniti.
However, i’ve run all these tests on 1.2.0 RC9 and the issue is consistent. Though some of the shell that gets us there is a bit different.

I’m going to leave my troubleshooting in this post so you can get the full story. The limitation is somewhere in vyatta-cfg.


Is there a limitation to how many firewall groups you can have?

In my testing i have found a rather inconsistent problem with firewall groups. Specifically around the auto-completion on tab.

In my test i created the following script -

#!/bin/vbash
/opt/vyatta/sbin/vyatta-cfg-cmd-wrapper begin
for i in {1..220}
do
/opt/vyatta/sbin/vyatta-cfg-cmd-wrapper set firewall group address-group FIREWALLGROUP$i address 1.1.1.1
done
/opt/vyatta/sbin/vyatta-cfg-cmd-wrapper commit
/opt/vyatta/sbin/vyatta-cfg-cmd-wrapper end
exit

This script creates a preset number of firewall groups.

I found that once i added over 220 firewall address groups, this happens

set firewall name INSIDE-OUTSIDE rule 1 source group address-group (tab) vbash: unexpected EOF while looking for matching `''
vbash: syntax error: unexpected end of file
Possible completions:
<text>    Group of addresses

The firewall groups still work, but they won’t tab out. Making it hard to use.

I’m currently testing this on an EdgeRouter Infinity on firmware 1.10.7, however the problem persists across all EdgeRouters and VyOS.

I’ve also done this without using a script to generate the groups, the problem persists regardless of how the groups are created.

I also found the code that is running when you hit tab and put it in a script. Using this method returns all the firewall groups without issue -

#!/bin/vbash
#local -a array
array=(`cli-shell-api listActiveNodes firewall group address-group`)
array+=(`sudo /sbin/ipset -L -n | grep ADDRv4`)
array+=(`sudo /sbin/ipset -L -n | grep NETv4`)
echo -n ${array[@]}

It’s also worth mentioning that hitting tab when adding a NEW firewall group works fine too -

set firewall group address-group (tab)
Display all 222 possibilities? (y or n)
FIREWALLGROUP1 ......

Has anyone run across this problem and found a fix? Or am i just weird for having so many firewall groups? lol

edit:

I’ve dug a little deeper and found it appears to be a problem with my_cli_shell_api

I took the bash_completion file and prefixed set -x

This is the result i got -

++ /opt/vyatta/sbin/my_cli_shell_api -- getCompletionEnv set firewall name INSIDE-OUTSIDE rule 1 source group address-group ''
outstr='_cli_shell_api_comp_values=('\''FIREWALLGROUP1'\'' '\''FIREWALLGROUP2'\'' '\''FIREWALLGROUP3'\'' '\''FIREWALLGROUP4'\'' '\''FIREWALLGROUP5'\'' '\''FIREWALLGROUP6'\'' '\''FIREWALLGROUP7'\''
(truncated for readability)
'\''FIREWALLGROUP220'\'' '\''FIREWALLGROUP221'\'' '\''FIR); _cli_shell_api_last_comp_val=true; _cli_shell_api_comp_help='\'''\''; _cli_shell_api_hitems=('\''txt'\'' ); _cli_shell_api_hstrs=('\''Group of addresses'\'' ); '

You can see we call my_cli_shell_api with GetCompletionEnv.

The outstr has '"FIR);

Leaving an open quote.

I then changed one of the FIREWALLGROUP to only be FIREWALL. And reran my test. This time i got -

++ /opt/vyatta/sbin/my_cli_shell_api -- getCompletionEnv set firewall name INSIDE-OUTSIDE rule 1 source group address-group ''
outstr='_cli_shell_api_comp_values=('\''address-group'\'' '\''FIREWALL221'\'' '\''FIREWALLGROUP1'\'' '\''FIREWALLGROUP2'\'' '\''FIREWALLGROUP3'\'' '\''FIREWALLGROUP4'\'' '\''FIREWALLGROUP5'\''
(truncated for readability)
'\''FIREWALLGROUP218'\'' '\''FIREWALLGROUP219'\'' '\''FIREWALLGROUP220'\'' '\''FIREWALL); _cli_shell_api_last_comp_val=true; _cli_shell_api_comp_help='\'''\''; _cli_shell_api_hitems=('\''txt'\'' ); _cli_shell_api_hstrs=('\''Group of addresses'\'' ); '

This time i got more of the last variable. In fact i got 5 more characters. The exact number of characters i removed from another address group.

So!

I see a few possibilities.

  1. The environment variable being used can’t store that many characters.

This seems a bit unlikely as the limit would be relatively small.

  1. Something my_cli_shell_api does is truncating the output.

Any ideas?


I’ve done some more digging into this and found the source code for cli_shell_api.
Here’s the function that’s being called -

getCompletionEnv(Cstore& cstore, const Cpath& args)
{
  string env;
  if (!cstore.getCompletionEnv(args, env)) {
    exit(1);
  }
  printf("%s", env.c_str());
}

The cstore function is pretty long, and honestly cpp is not something i’ve spent a lot of time with.
Does anyone have any insight as to where the array is getting truncated?

Thanks