Bug 255704

Summary: Feature Request: ipfw: print time in ISO8601 or allow to pass time format string
Product: Base System Reporter: parv <parv.0zero9+freebsd>
Component: binAssignee: freebsd-ipfw (Nobody) <ipfw>
Status: Closed Feedback Timeout    
Severity: Affects Only Me CC: donner, parv.0zero9+freebsd
Priority: ---    
Version: 13.0-STABLE   
Hardware: Any   
OS: Any   

Description parv 2021-05-08 10:48:46 UTC 
ipfw with "-t" option currently prints the via ctime, supposedly for human consumption. That output of time stamp value is far too fractured for me to easily read and make sense of.

Parsing ipfw output to convert seconds since Unix epoch in desired time format is too brittle, as output could change depending on the options passed to ipfw.

There should be an option to print the date-time value in ISO8601 format for easier reading & understanding.

Another method could be to allow user to pass in a custom date-time format string -- via an option, environment variable, some tunable, etc. -- for ipfw to print time stamp in that format.
Comment 1 Lutz Donnerhacke freebsd_committer freebsd_triage 2021-05-09 13:04:33 UTC 
Just to understand correctly.

ipfw -T is designed for scripted postprocessíng.
Why does it not fit your needs?
Comment 2 parv 2021-05-15 07:16:24 UTC 
As I had noted earlier "[p]arsing ipfw output to convert seconds since Unix epoch in desired time format is too brittle, as output could change depending on the options passed to ipfw". Compare the output of "ipfw -T list" & "ipfw -aT list"; in the second form, second value from 2nd column to 4th (counting from 1) ...

# ipfw -T list | head -n2
00001 1621062170 allow ip from any to any via lo0
00002          0 check-state :default


# ipfw -aT list | head -n2
00001    383     15320 1621062170 allow ip from any to any via lo0
00002      0         0          0 check-state :default


Further, "0" is an unfortunate value to be present in second-since-Unix-epoch column to represent that this rule has not been used yet. Thus it needs to be treated as a special case -- outside of ipfw -- as time of 1970-01-01 00:00:00 UTC makes no sense here. As much is evident in "ipfw -t list" output where blanks are printed instead of a date-time value ...

# ipfw -t list | head -n2
00001 Fri May 14 21:02:50 2021 allow ip from any to any via lo0
00002                          check-state :default
Comment 3 Lutz Donnerhacke freebsd_committer freebsd_triage 2021-05-15 09:23:33 UTC 
(In reply to parv from comment #2)

I'm a bit confused.
My version of ipfw in 13-STABLE reacts to the option -T and -aT in the same way.

```
# ipfw -T show
00100 5197969 654927673 1621070102 allow ip from any to any
# ipfw -aT show
00100 5198030 654934164 1621070105 allow ip from any to any
```

This is easy to postprocess i.e.

```
# ipfw -T show | perl -pe '
   next unless s/ +(\d+) +(\d+) +(\d+)/ XxX/;
   $d = localtime($3);
   if ($3 > 0) {
      s/XxX/$d/;
   } else {
      s/XxX/                        /
   };'
00100 Sat May 15 11:19:54 2021 allow ip from any to any
07110                          fwd tablearg,8000 tcp ...
07110                          fwd tablearg,8000 tcp ...
07210                          allow ip from any to any
65535                          deny ip from any to any
```

You may write you a wrapper script which is using the options you really need.

Please don't get me wrong. The question is: "Is it worth the effort to include a special form of postprocessing into a system binary?"