Connections.cgi

1

hi
I see a lot of message in the log app of this type


[Sun Nov 17 00:44:46 2024] connections.cgi: Use of uninitialized value $settings{"ORANGE_ADDRESS"} in concatenation (.) or string at /srv/web/ipfire/cgi-bin/connections.cgi line 43.
[Sun Nov 17 00:44:46 2024] connections.cgi: Use of uninitialized value in concatenation (.) or string at /srv/web/ipfire/cgi-bin/connections.cgi line 43.
[Sun Nov 17 00:44:46 2024] connections.cgi: Use of uninitialized value in concatenation (.) or string at /srv/web/ipfire/cgi-bin/connections.cgi line 43.
[Sun Nov 17 00:44:46 2024] connections.cgi: Use of uninitialized value in list assignment at /srv/web/ipfire/cgi-bin/connections.cgi line 78.
[Sun Nov 17 00:44:46 2024] connections.cgi: Use of uninitialized value $ovpnsettings{"DOVPN_SUBNET"} in hash element at /srv/web/ipfire/cgi-bin/connections.cgi line 132.
[Sun Nov 17 00:44:46 2024] connections.cgi: Argument "" isn't numeric in numeric eq (==) at /srv/web/ipfire/cgi-bin/connections.cgi line 307, <CONNTRACK> line 14.
[Sun Nov 17 00:44:46 2024] connections.cgi: Use of uninitialized value $sip in numeric eq (==) at /srv/web/ipfire/cgi-bin/connections.cgi line 307, <CONNTRACK> line 14.
[Sun Nov 17 00:44:46 2024] connections.cgi: Argument "" isn't numeric in numeric eq (==) at /srv/web/ipfire/cgi-bin/connections.cgi line 314, <CONNTRACK> line 14.

Are they important?

2

I suspect that you only have red, green & blue networks and no orange network.

The code for connections.cgi creates a variable %networks which collects all known networks together.

  42 # Collect all known networks
  43 my %networks = (
  44         # Localhost
  45         "127.0.0.0/8" => ${Header::colourfw},
  46 
  47         # Multicast
  48         "224.0.0.0/3" => $colour_multicast,
  49 
  50         # GREEN
  51         "$settings{'GREEN_ADDRESS'}/32" => ${Header::colourfw},
  52         "$settings{'GREEN_NETADDRESS'}/$settings{'GREEN_NETMASK'}" => ${Header::colourgreen},
  53 
  54         # BLUE
  55         "$settings{'BLUE_ADDRESS'}/32" => ${Header::colourfw},
  56         "$settings{'BLUE_NETADDRESS'}/$settings{'BLUE_NETMASK'}" => ${Header::colourblue},
  57 
  58         # ORANGE
  59         "$settings{'ORANGE_ADDRESS'}/32" => ${Header::colourfw},
  60         "$settings{'ORANGE_NETADDRESS'}/$settings{'ORANGE_NETMASK'}" => ${Header::colourorange},
  61 )

If any of the networks are not present, because they have not been installed, then the $settings value for that entry will be unitialised.

The reason that the warnings (and they are warnings, not errors) are in the logs is because the following lines were not commented out after the changes were made and evaluated.

  25 # enable only the following on debugging purpose
  26 use warnings;
  27 use CGI::Carp 'fatalsToBrowser';

I will submit a patch to comment those two lines out and hence stop those warning messages.

As I have all of the colour networks on my production and vm testing machines, I have not got any of those warning messages.

I will also check if there are any other .cgi files that have those entries commented out.

1 Like
3

This patch has two sides.

  • commenting out the warnings decreases the log output
  • the warnings show some problems in the source code. These should be checked in the test phase. Only approved cases shall be go into the production version ( switching off the warnings is ‘allowed’ then ).
4

That could be true, but then the code needs to be modified to check out whether you have Green & Red or Green, Red & Orange or Green, Red & Blue or Green, Red, Orange & Blue and only check for the $settings for the ones that are actually present.

Feel free to submit a patch to fix that.

I will not submit a patch for the connections.cgi to comment out the warnings, only for the few other cgi files that have them uncommented. Most cgi files have those two line commented out.

I have to admit when I have done updates to any of the cgi files I have rarely if ever uncommented those lines. Only when I had things that were not working correctly.

5

Looking a bit into the sources and the logs for displaying connections.cgi shows there are some more issues than the interfaces not defined.
Most of the errors are generated by the connection tracking analysis starting from line 241 ( based on CU189 ).

6

If you don’t want to look at it further then I could have a look at it but I have a lot of other things on my list so likely to be at least a month or three before I can get round to it.

Maybe someone needs to raise it as a bug then.

1 Like
7

I will look at it further.
My last post was just short sight at the issue.

Raising a bug may be another possibility.

8

I only looked at the first couple of warnings so missed at first sight that the later warnings were for different things.
Just a bit too busy to do much with it at the moment.

9

hi
Thank you for your good information courage for the solution.

10

I have made a warning free version now.
Next steps:

  • check equality of output unchanged <—> changed
  • send a patch
  • (check other WUI files)
11

I made a list yesterday of the other WUI cgi pages that had those lines uncommented.

fireinfo.cgi
fwhosts.cgi
log.dat
modem-status.cgi
wirelessclient.cgi

Nothing in the logs from those pages, although my setup would not be testing the last two as my connection doesn’t use them.

12

Thx.
I’ll look at others also.
Most warnings are about undefined/uninitialised variables. That usually doesn’t matter. But these messages are annoying when searching for errors ( logical not syntactic/semantic ).