iptables fails to parse -x (expand numbers) option because "pkts" header has more than one leading blank

[IsmaelSF]

Hi, turning -x option in iptables, parser fails trying to decode line starting with "pkts" due to more than one leading white space.

Chain DOCKER-ISOLATION-STAGE-2 (4 references)
  pkts              bytes target     prot opt in     out     source               destination
       0        0 DROP       all  --  any    docker0  anywhere             anywhere
       0        0 DROP       all  --  any    br-b01fa3a90d3b  anywhere             anywhere
       0        0 DROP       all  --  any    br-642643a59593  anywhere             anywhere
       0        0 DROP       all  --  any    br-3e698d2f6bc4  anywhere             anywhere
44758639 38517421321 RETURN     all  --  any    any     anywhere             anywhere

Fails with:

Traceback (most recent call last):
  File "/usr/local/bin/jc", line 8, in 
    sys.exit(main())
             ^^^^^^
  File "/usr/local/lib/python3.11/site-packages/jc/cli.py", line 965, in main
    JcCli().run()
  File "/usr/local/lib/python3.11/site-packages/jc/cli.py", line 947, in run
    self._run()
  File "/usr/local/lib/python3.11/site-packages/jc/cli.py", line 911, in _run
    self.standard_parse_and_print()
  File "/usr/local/lib/python3.11/site-packages/jc/cli.py", line 803, in standard_parse_and_print
    self.create_normal_output()
  File "/usr/local/lib/python3.11/site-packages/jc/cli.py", line 755, in create_normal_output
    self.data_out = self.parser_module.parse(
                    ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/jc/parsers/iptables.py", line 258, in parse
    if headers[0] == 'target' and line.startswith(' '):
       ~~~~~~~^^^
IndexError: list index out of range

Seems that (line 250 in iptables.py):

elif line.startswith('target') or line.find('pkts') ==1 or line.startswith('num'):

could be

elif line.startswith('target') or line.find('pkts') >=1 or line.startswith('num'):

in order to detect this specific case.

Thank you for your excellent work!

[kellyjonbrazil]

Thank you for reporting this! I'll try the change and make sure it doesn't break any tests.

[kellyjonbrazil]

I updated the iptables parser in the dev branch:

https://github.com/kellyjonbrazil/jc/blob/dev/jc/parsers/iptables.py

You can test by copy/pasting the file into your parser plugin folder:

• Linux/unix: $HOME/.local/share/jc/jcparsers
• macOS: $HOME/Library/Application Support/jc/jcparsers
• Windows: $LOCALAPPDATA\jc\jc\jcparsers

[IsmaelSF]

I was doing some additional tests with very large counters that I found in one of my systems and seems that one additional character is needed in the condition "<=3" .

Looking directly to iptables source code confirm it:

        if (!(format & FMT_NOCOUNTS)) {
                if (format & FMT_KILOMEGAGIGA) {
                        printf(FMT("%5s ","%s "), "pkts");
                        printf(FMT("%5s ","%s "), "bytes");
                } else {
                        printf(FMT("%8s ","%s "), "pkts");
                        printf(FMT("%10s ","%s "), "bytes");
                }
        }

If you want to update the test case:

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination
11291792498 217331852907122 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
  555958 33533576 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
128628404869 172804745659762 INPUT_direct  all  --  *      *       0.0.0.0/0            0.0.0.0/0
128627559128 172804718596050 INPUT_ZONES_SOURCE  all  --  *      *       0.0.0.0/0            0.0.0.0/0
128627559125 172804718595966 INPUT_ZONES  all  --  *      *       0.0.0.0/0            0.0.0.0/0
   26599  1082920 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate INVALID
    1761    79571 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            reject-with icmp-host-prohibited

And one additional minor change, update parser docs to include "-x" as supported.

[kellyjonbrazil]

Thanks - I figured that might be the case. 😄 I'll update the parser and tests.

[kellyjonbrazil]

Added in v1.25.2