Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    NUT Package (2.8.1 and above)

    Scheduled Pinned Locked Moved
    UPS Tools
    38
    265
    96.8k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • dennypageD
      dennypage @dmitri
      last edited by

      @dmitri said in NUT Package (2.8.1 and above):

      After upgrading to 2.7.1-RC the issues went away.

      Are you running NUT 2.8.1 there?

      D 1 Reply Last reply Reply Quote 0
      • D
        dmitri @dennypage
        last edited by

        @dennypage Just double checked, yes 2.8.1 NUT package on 2.7.1-RC.

        1 Reply Last reply Reply Quote 1
        • S
          sgnoc
          last edited by sgnoc

          @dennypage I've done some additional testing. Initially when I tried the updated package I was receiving connection lost/established messages. I've restarted pfSense, removed all nut packages, reinstalled nut (pfsense-pkg-nut, and the nut package itself), removed nut, installed the nut-devel-2023.10.07_01 and restarted the service.

          I then did some testing and grabbed some logs. So far I haven't received any more connection lost notices, but they were sporadic over an hour timeframe. Here are the logs/info, in case you see anything that jumps out. I do see no matching INFO_* value for OID listed for a bunch of different OID values (in the log).

          [23.09-RELEASE][admin@netgate]/tmp/acme: upsc CyberPowerCP2200
battery.charge: 100
battery.current: 3.50
battery.date: 12/22/2022
battery.runtime: 3300
battery.runtime.elapsed: 0
battery.voltage: 81.10
battery.voltage.nominal: 72
device.contact: Shaun
device.description: UPS SNMP Card
device.location: Basement
device.mfr: CYBERPOWER
device.model: OL2200RTXL2U
device.serial: WBGEP2000038
device.type: ups
driver.debug: 0
driver.flag.allow_killpower: 0
driver.name: snmp-ups
driver.parameter.pollinterval: 2
driver.parameter.port: 10.10.5.10
driver.parameter.synchronous: auto
driver.state: quiet
driver.version: 2.8.0.1
driver.version.data: cyberpower MIB 0.55
driver.version.internal: 1.30
input.frequency: 60
input.transfer.reason: noTransfer
input.voltage: 123
output.current: 3.50
output.frequency: 60
output.voltage: 120.20
ups.delay.reboot: 0
ups.delay.shutdown: 180
ups.delay.start: 0
ups.firmware: S1A14
ups.id: CP2200
ups.load: 19
ups.mfr: CYBERPOWER
ups.model: OL2200RTXL2U
ups.serial: WBGEP2000038
ups.status: OL
ups.temperature: 34
ups.test.date: 11/12/2023
ups.test.result: Ok

          [23.09-RELEASE][admin@netgate]/tmp/acme: snmpwalk -v 1 -c public 10.10.5.10 SNMPv2-SMI::enterprises.3808.1.1.1
SNMPv2-SMI::enterprises.3808.1.1.1.1.1.1.0 = STRING: "OL2200RTXL2U"
SNMPv2-SMI::enterprises.3808.1.1.1.1.1.2.0 = STRING: "CP2200"
SNMPv2-SMI::enterprises.3808.1.1.1.1.2.1.0 = STRING: "S1A14"
SNMPv2-SMI::enterprises.3808.1.1.1.1.2.3.0 = STRING: "WBGEP2000038"
SNMPv2-SMI::enterprises.3808.1.1.1.1.2.4.0 = STRING: "1.4.0"
SNMPv2-SMI::enterprises.3808.1.1.1.1.2.5.0 = NULL
SNMPv2-SMI::enterprises.3808.1.1.1.1.2.6.0 = INTEGER: 2200
SNMPv2-SMI::enterprises.3808.1.1.1.1.2.7.0 = INTEGER: 1800
SNMPv2-SMI::enterprises.3808.1.1.1.1.2.8.0 = INTEGER: 180
SNMPv2-SMI::enterprises.3808.1.1.1.1.2.9.0 = NULL
SNMPv2-SMI::enterprises.3808.1.1.1.2.1.1.0 = INTEGER: 2
SNMPv2-SMI::enterprises.3808.1.1.1.2.1.2.0 = Timeticks: (0) 0:00:00.00
SNMPv2-SMI::enterprises.3808.1.1.1.2.1.3.0 = STRING: "12/22/2022"
SNMPv2-SMI::enterprises.3808.1.1.1.2.1.4.0 = INTEGER: 36
SNMPv2-SMI::enterprises.3808.1.1.1.2.2.1.0 = Gauge32: 100
SNMPv2-SMI::enterprises.3808.1.1.1.2.2.2.0 = Gauge32: 811
SNMPv2-SMI::enterprises.3808.1.1.1.2.2.3.0 = NULL
SNMPv2-SMI::enterprises.3808.1.1.1.2.2.4.0 = Timeticks: (330000) 0:55:00.00
SNMPv2-SMI::enterprises.3808.1.1.1.2.2.5.0 = INTEGER: 1
SNMPv2-SMI::enterprises.3808.1.1.1.2.2.8.0 = INTEGER: 72
SNMPv2-SMI::enterprises.3808.1.1.1.2.2.9.0 = NULL
SNMPv2-SMI::enterprises.3808.1.1.1.3.1.1.0 = INTEGER: 1
SNMPv2-SMI::enterprises.3808.1.1.1.3.2.1.0 = Gauge32: 1230
SNMPv2-SMI::enterprises.3808.1.1.1.3.2.2.0 = Gauge32: 1232
SNMPv2-SMI::enterprises.3808.1.1.1.3.2.3.0 = Gauge32: 1230
SNMPv2-SMI::enterprises.3808.1.1.1.3.2.4.0 = Gauge32: 600
SNMPv2-SMI::enterprises.3808.1.1.1.3.2.5.0 = INTEGER: 1
SNMPv2-SMI::enterprises.3808.1.1.1.3.2.6.0 = INTEGER: 1
SNMPv2-SMI::enterprises.3808.1.1.1.4.1.1.0 = INTEGER: 2
SNMPv2-SMI::enterprises.3808.1.1.1.4.1.2.0 = INTEGER: 1
SNMPv2-SMI::enterprises.3808.1.1.1.4.1.3.0 = STRING: "40~70 Hz"
SNMPv2-SMI::enterprises.3808.1.1.1.4.2.1.0 = Gauge32: 1200
SNMPv2-SMI::enterprises.3808.1.1.1.4.2.2.0 = INTEGER: 600
SNMPv2-SMI::enterprises.3808.1.1.1.4.2.3.0 = Gauge32: 19
SNMPv2-SMI::enterprises.3808.1.1.1.4.2.4.0 = Gauge32: 35
SNMPv2-SMI::enterprises.3808.1.1.1.4.2.5.0 = Gauge32: 342
SNMPv2-SMI::enterprises.3808.1.1.1.4.2.6.0 = NULL
SNMPv2-SMI::enterprises.3808.1.1.1.4.2.7.0 = NULL
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.1.0 = INTEGER: 24
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.1.1 = INTEGER: 1
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.1.2 = INTEGER: 2
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.1.3 = INTEGER: 3
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.1.4 = INTEGER: 4
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.1.5 = INTEGER: 5
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.1.6 = INTEGER: 6
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.1.7 = INTEGER: 7
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.1.8 = INTEGER: 8
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.1.9 = INTEGER: 9
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.1.10 = INTEGER: 10
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.1.11 = INTEGER: 11
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.1.12 = INTEGER: 12
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.1.13 = INTEGER: 13
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.1.14 = INTEGER: 14
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.1.15 = INTEGER: 15
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.2.1 = STRING: "Outlet1"
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.2.2 = STRING: "Outlet2"
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.2.3 = STRING: "Outlet3"
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.2.4 = STRING: "Outlet4"
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.2.5 = STRING: "Outlet5"
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.2.6 = STRING: "Outlet6"
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.2.7 = STRING: "Outlet7"
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.2.8 = STRING: "Outlet8"
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.2.9 = STRING: "Outlet9"
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.2.10 = STRING: "Outlet10"
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.2.11 = STRING: "Outlet11"
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.2.12 = STRING: "Outlet12"
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.2.13 = STRING: "Outlet13"
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.2.14 = STRING: "Outlet14"
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.2.15 = STRING: "Outlet15"
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.3.1 = INTEGER: 0
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.3.2 = INTEGER: 0
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.3.3 = INTEGER: 0
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.3.4 = INTEGER: 0
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.3.5 = INTEGER: 0
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.3.6 = INTEGER: 0
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.3.7 = INTEGER: 0
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.3.8 = INTEGER: 0
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.3.9 = INTEGER: 0
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.3.10 = INTEGER: 0
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.3.11 = INTEGER: 0
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.3.12 = INTEGER: 0
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.3.13 = INTEGER: 0
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.3.14 = INTEGER: 0
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.3.15 = INTEGER: 0
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.4.1 = INTEGER: 2
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.4.2 = INTEGER: 2
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.4.3 = INTEGER: 2
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.4.4 = INTEGER: 2
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.4.5 = INTEGER: 2
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.4.6 = INTEGER: 2
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.4.7 = INTEGER: 2
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.4.8 = INTEGER: 2
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.4.9 = INTEGER: 2
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.4.10 = INTEGER: 2
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.4.11 = INTEGER: 2
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.4.12 = INTEGER: 2
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.4.13 = INTEGER: 2
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.4.14 = INTEGER: 2
SNMPv2-SMI::enterprises.3808.1.1.1.5.1.2.1.4.15 = INTEGER: 2
SNMPv2-SMI::enterprises.3808.1.1.1.5.2.1.0 = INTEGER: 120
SNMPv2-SMI::enterprises.3808.1.1.1.5.2.4.0 = INTEGER: 2
SNMPv2-SMI::enterprises.3808.1.1.1.5.2.9.0 = Timeticks: (0) 0:00:00.00
SNMPv2-SMI::enterprises.3808.1.1.1.5.2.10.0 = Timeticks: (18000) 0:03:00.00
SNMPv2-SMI::enterprises.3808.1.1.1.5.2.11.0 = Timeticks: (18000) 0:03:00.00
SNMPv2-SMI::enterprises.3808.1.1.1.5.2.13.0 = INTEGER: 2
SNMPv2-SMI::enterprises.3808.1.1.1.5.2.14.0 = INTEGER: 0
SNMPv2-SMI::enterprises.3808.1.1.1.5.2.15.0 = INTEGER: 2
SNMPv2-SMI::enterprises.3808.1.1.1.5.2.16.0 = INTEGER: 0
SNMPv2-SMI::enterprises.3808.1.1.1.5.2.17.0 = INTEGER: 1
SNMPv2-SMI::enterprises.3808.1.1.1.5.2.18.0 = INTEGER: 20
SNMPv2-SMI::enterprises.3808.1.1.1.5.2.19.0 = NULL
SNMPv2-SMI::enterprises.3808.1.1.1.5.2.20.0 = NULL
SNMPv2-SMI::enterprises.3808.1.1.1.6.2.1.0 = INTEGER: 1
SNMPv2-SMI::enterprises.3808.1.1.1.6.2.2.0 = INTEGER: 1
SNMPv2-SMI::enterprises.3808.1.1.1.6.2.3.0 = INTEGER: 1
SNMPv2-SMI::enterprises.3808.1.1.1.6.2.5.0 = NULL
SNMPv2-SMI::enterprises.3808.1.1.1.6.2.6.0 = INTEGER: 1
SNMPv2-SMI::enterprises.3808.1.1.1.7.2.2.0 = INTEGER: 1
SNMPv2-SMI::enterprises.3808.1.1.1.7.2.3.0 = INTEGER: 1
SNMPv2-SMI::enterprises.3808.1.1.1.7.2.4.0 = STRING: "11/12/2023"
SNMPv2-SMI::enterprises.3808.1.1.1.7.2.6.0 = INTEGER: 1
SNMPv2-SMI::enterprises.3808.1.1.1.7.2.7.0 = NULL
SNMPv2-SMI::enterprises.3808.1.1.1.7.2.8.0 = NULL
SNMPv2-SMI::enterprises.3808.1.1.1.8.1.1.1.1.1 = INTEGER: 1
SNMPv2-SMI::enterprises.3808.1.1.1.8.1.1.1.1.2 = INTEGER: 2
SNMPv2-SMI::enterprises.3808.1.1.1.8.1.1.1.1.3 = INTEGER: 3
SNMPv2-SMI::enterprises.3808.1.1.1.8.1.1.1.1.4 = INTEGER: 4
SNMPv2-SMI::enterprises.3808.1.1.1.8.1.1.1.1.5 = INTEGER: 5
SNMPv2-SMI::enterprises.3808.1.1.1.8.1.1.1.2.1 = INTEGER: 4
SNMPv2-SMI::enterprises.3808.1.1.1.8.1.1.1.2.2 = INTEGER: 1
SNMPv2-SMI::enterprises.3808.1.1.1.8.1.1.1.2.3 = INTEGER: 3
SNMPv2-SMI::enterprises.3808.1.1.1.8.1.1.1.2.4 = INTEGER: 4
SNMPv2-SMI::enterprises.3808.1.1.1.8.1.1.1.2.5 = INTEGER: 2
SNMPv2-SMI::enterprises.3808.1.1.1.10.1.0 = INTEGER: 1
SNMPv2-SMI::enterprises.3808.1.1.1.10.2.0 = Gauge32: 34

          Here is the file with the output (ran for about 100 seconds) from: /usr/local/libexec/nut/snmp-ups -a ups -DDDDDD 2>&1 | tee /tmp/out
          output.txt

          I'm hoping the restart and reinstall of everything fixed whatever was causing the connection losts messages, but I'll update again if they reoccur.

          Update about 2 hours later: The reboot and uninstall/reinstall of all NUT packages (to the devel package) seemed to do the trick. I haven't had a single connection lost notice since then. No idea why it was having issues after I tried the devel package, but it seems to be good now.

          1 Reply Last reply Reply Quote 1
          • T
            tman222
            last edited by

            Upgraded to the new NUT package (2.8.2) and I'm happy to report that I was able to remove the interruptonly flag and now see no more disconnects on the USB connected Cyberpower UPS. Thanks @dennypage for all your hard work updating and maintaining this pfSense package.

            dennypageD 1 Reply Last reply Reply Quote 1
            • dennypageD
              dennypage @tman222
              last edited by

              @tman222 said in NUT Package (2.8.1 and above):

              Thanks @dennypage for all your hard work updating and maintaining this pfSense package.

              You are most welcome

              1 Reply Last reply Reply Quote 0
              • evertE
                evert @dennypage
                last edited by

                @dennypage said in NUT Package (2.8.1 and above):

                Call for testing!

                We are in a testing/feedback phase for the 2.8.1 pfSense NUT package. Many of you have experienced issues with the 2.8.0 version and are running custom builds. I would like to ask you to test the new package prior to a general release.

                The 2.8.1 packages are available from the Redmine issue here. In order to install the package, you must be running 23.09. Be sure to select the correct package for your architecture.

                Can you tell me where I can get the previous package? I'm on 23.05.1 and upgraded NUT to 2.8.2 yesterday. Package management let me do this, even though NUT 2.8.2 apparently doesn't work with 23.05.1. Result: a busted nut...
                (I'll upgrade to 23.09 soon, but I can't do this during office hours)

                dennypageD 1 Reply Last reply Reply Quote 0
                • GertjanG
                  Gertjan @Unoptanio
                  last edited by

                  @Unoptanio said in NUT Package (2.8.1 and above):

                  maybe I found it, can you confirm?
                  nano /boot/loader.conf

                  Not that file, as pfSense can wipe / purge / empty / modify / do whatever it wants with the content.

                  Read System Tunables and you'll find the one you need : /boot/loader.conf.local

                  No "help me" PM's please. Use the forum, the community will thank you.
                  Edit : and where are the logs ??

                  1 Reply Last reply Reply Quote 1
                  • dennypageD
                    dennypage @evert
                    last edited by

                    @evert said in NUT Package (2.8.1 and above):

                    @
                    Can you tell me where I can get the previous package? I'm on 23.05.1 and upgraded NUT to 2.8.2 yesterday. Package management let me do this, even though NUT 2.8.2 apparently doesn't work with 23.05.1. Result: a busted nut...
                    (I'll upgrade to 23.09 soon, but I can't do this during office hours)

                    It shouldn’t show up in 23.05.1. Did you switch update streams? Best I can suggest is to remove the package and reinstall.

                    evertE 1 Reply Last reply Reply Quote 1
                    • S
                      sgnoc
                      last edited by

                      @dennypage I got prompted on package manager that 2.8.2 was available and upgraded. Since then, I've started receiving the communication lost and established. I'm running a CyberPower UPS. I tried to put the nut-devel-2023.10.07_1.pkg back on, but it doesn't seem to be working with the other portion of NUT that was installed with 2.8.2. Was 2.8.2 the fix or is that still a version that hasn't been patched yet?

                      What's my best bet to get this working again until a permanent fix is available? Thanks!

                      dennypageD 1 Reply Last reply Reply Quote 0
                      • dennypageD
                        dennypage @sgnoc
                        last edited by

                        @sgnoc 2.8.2 of the pfSense package is the final release version.

                        The content of the underlying NUT package, nut-devel-2023.10.07_1, is the same as the prerelease test version. The only change in the new pfSense package (pfSense-pkg-nut-2.8.2) is that it states a dependency on nut-devel-2023.10.07_1 instead of nut-2.8.0.

                        A current install on 23.09 should show this:

                        [23.09-RELEASE][root@fw]/root: pkg info | grep nut
nut-devel-2023.10.07_1         Network UPS Tools
pfSense-pkg-nut-2.8.2          Network UPS Tools
[23.09-RELEASE][root@fw]/root:
                        S 1 Reply Last reply Reply Quote 0
                        • S
                          sgnoc @dennypage
                          last edited by

                          @dennypage I'm showing both of those packages, but oddly enough I'm now getting sporadic lost communication notices again, where I was not with the patch before this 2.8.2 update.

                          It's only happening a few times a day, but it is consistently a lost communication notice, exactly 3 seconds later a second lost communication notice and 5 seconds after that an established communication notice. I've already uninstalled and reinstalled to see if that would do it. I'll try and dig around to see why this may have happened from the patch to this update, since there shouldn't be a difference.

                          1 Reply Last reply Reply Quote 0
                          • Q
                            q54e3w
                            last edited by

                            All working with 2.8.2 here with Eaton 9PX3000. Only change required was subdriver changing from pw to eaton_pw_nm2. Thanks @dennypage for maintaining this package, super appreciated.

                            dennypageD 1 Reply Last reply Reply Quote 1
                            • dennypageD
                              dennypage @q54e3w
                              last edited by

                              @q54e3w I appreciate you saying that. Thanks.

                              1 Reply Last reply Reply Quote 0
                              • evertE
                                evert @dennypage
                                last edited by

                                @dennypage said in NUT Package (2.8.1 and above):

                                @evert said in NUT Package (2.8.1 and above):

                                @
                                Can you tell me where I can get the previous package? I'm on 23.05.1 and upgraded NUT to 2.8.2 yesterday. Package management let me do this, even though NUT 2.8.2 apparently doesn't work with 23.05.1. Result: a busted nut...
                                (I'll upgrade to 23.09 soon, but I can't do this during office hours)

                                It shouldn’t show up in 23.05.1. Did you switch update streams? Best I can suggest is to remove the package and reinstall.

                                We are on the regular 'Latest Stable Version' branch. Ah well, I came in early today and updated the whole thing to 23.09 and that resolved my issues 😎

                                And... Lo and behold! Our UPS is finally having a proper connection to the pfSense box 🤗

                                1 Reply Last reply Reply Quote 0
                                • evertE
                                  evert
                                  last edited by

                                  A bit confused by the versioning: pfSense now has nut 2.8.2, but the official NUT release is 2.8.1 if I interpret this page correctly.

                                  What happens when the official NUT release hits 2.8.2?

                                  dennypageD 1 Reply Last reply Reply Quote 0
                                  • dennypageD
                                    dennypage @evert
                                    last edited by

                                    @evert Yea, we had a little oops at the end, and a commit went in that should not have. The published version of the pfSense package itself shows as 2.8.2. By the time I discovered it, it was too late to change it.

                                    It should stay 2.8.2 (2.8.2_1, 2.8.2_2, 2.8.2_3...) until 2.8.3 or 3.0.0 is released.

                                    UnoptanioU 1 Reply Last reply Reply Quote 0
                                    • UnoptanioU
                                      Unoptanio @dennypage
                                      last edited by Unoptanio

                                      @dennypage

                                      Good morning,
                                      I updated to pfsense 2.7.1 with Nut ver 2.8.2

                                      The quirk is always inserted in the boot loader.
                                      hw.usb.quirk.0="0x04b4 0x5500 0x0000 0xffff UQ_HID_IGNORE"

                                      I confirm that the Riello VST1100 UPS is working well without disconnection of the USB port

                                      Soon I will also let you know for the "Riello Sentinel Pro 2200" and "Riello Sentinel Dual SDU 6Kw" models

                                      For Riello VST1100:

                                      UPS Detail

This table contains all the variables reported by the UPS via the upsc command. Note that many UPSs report only a subset of the available variables. Also note that some UPSs, particularly those using usbhid, may report an incorrect value for a variable. This is generally not a cause for concern. For additional information, see the Network UPS Tools site

Variable	Value
battery.capacity	9
battery.charge	100
battery.runtime	5940
battery.voltage	27.4
battery.voltage.nominal	24
device.mfr	RPS S.p.a.
device.model	ULC2
device.serial	
device.type	ups
driver.debug	0
driver.flag.allow_killpower	0
driver.name	riello_usb
driver.parameter.pollinterval	2
driver.parameter.port	auto
driver.parameter.synchronous	auto
driver.state	updateinfo
driver.version	2.8.0.1
driver.version.internal	0.10
driver.version.usb	libusb-1.0.0 (API: 0x1000102)
input.bypass.frequency	50.00
input.bypass.voltage	230
input.frequency	50.00
input.voltage	230
output.frequency	50.00
output.frequency.nominal	50.0
output.L1.current	0
output.L1.power	0
output.L1.realpower	0
output.L2.current	0
output.L2.power	0
output.L2.realpower	0
output.L3.current	0
output.L3.power	0
output.L3.realpower	0
output.power.percent	12
output.voltage	230
output.voltage.nominal	230
ups.delay.reboot	5
ups.delay.shutdown	5
ups.firmware	SWM039-01-04
ups.load	12
ups.mfr	RPS S.p.a.
ups.model	ULC2
ups.power.nominal	1100
ups.productid	5500
ups.realpower.nominal	880
ups.serial	
ups.status	OL
ups.temperature	42
ups.vendorid	04b4

                                      pfSensePlus24.03 2U BareMetal Asrock Industrial IMB-X1314MicroATX
                                      CPU: i7-13700@5.2GHz, RAM:32GB ECC, n°2 Samsung 870EVO SATA 2.5” SSD 1TB (ZFS) Raid1
                                      n°3 Intel i225-LM 2500/1000/100Mbps, n°1 NIC Intel i350-T4V2 10/100/1000 Mbps 4*GLAN, n°1 Intel X520-DA2

                                      1 Reply Last reply Reply Quote 1
                                      • mlakeM
                                        mlake
                                        last edited by

                                        Version info:
                                        pfSense: 23.09-RELEASE (amd64)
                                        nut: 2.8.2

                                        I'm running into a strange issue with NUT/upsmon where, when my remote OpenVPN tunnel reconnects (pfSense acting as the client), the router briefly loses connection to my USB-connected UPS and I receive emails like the following from the router:

                                        Notifications in this message: 1
================================

10:17:29 UPS Notification from [PFSENSE_FQDN] - Sun, 03 Dec 2023 10:17:29 -0600

Communications with UPS ups lost

                                        Notifications in this message: 2
================================

10:17:33 UPS Notification from [PFSENSE_FQDN] - Sun, 03 Dec 2023 10:17:33 -0600

Communications with UPS ups lost
10:17:38 UPS Notification from [PFSENSE_FQDN] - Sun, 03 Dec 2023 10:17:38 -0600

Communications with UPS ups established

                                        And here's the relevant portion of the System Log from the same time:

                                        Dec 3 10:17:16	php-fpm	405	/vpn_openvpn_client.php: Configuration Change: [USER]@172.17.37.5 (Local Database): Updated OpenVPN client to server [OPENVPN_REMOTE_SERVER]:1194 RemoteVPN
Dec 3 10:17:17	check_reload_status	446	Syncing firewall
Dec 3 10:17:17	php-fpm	405	OpenVPN terminate old pid: 58538
Dec 3 10:17:18	kernel		ovpnc2: link state changed to DOWN
Dec 3 10:17:18	check_reload_status	446	Reloading filter
Dec 3 10:17:18	php-fpm	405	OpenVPN PID written: 80663
Dec 3 10:17:18	check_reload_status	446	Reloading filter
Dec 3 10:17:23	kernel		ovpnc2: link state changed to UP
Dec 3 10:17:23	check_reload_status	446	rc.newwanip starting ovpnc2
Dec 3 10:17:24	php-fpm	50903	/rc.newwanip: rc.newwanip: Info: starting on ovpnc2.
Dec 3 10:17:24	php-fpm	50903	/rc.newwanip: rc.newwanip: on (IP address: [OVPN_REMOTE_IP]) (interface: REMOTE_VPN[opt5]) (real interface: ovpnc2).
Dec 3 10:17:25	php-fpm	50903	/rc.newwanip: Removing static route for monitor 1.0.0.1 and adding a new route through [OVPN_REMOTE_GW]
Dec 3 10:17:26	php-fpm	50903	/rc.newwanip: The command '/sbin/route -n6 get 'default' 2>/dev/null | /usr/bin/egrep 'flags: <.*PROTO.*>'' returned exit code '1', the output was ''
Dec 3 10:17:26	php-fpm	50903	/rc.newwanip: Creating rrd update script
Dec 3 10:17:28	php-fpm	50903	/rc.newwanip: Netgate pfSense Plus package system has detected an IP change or dynamic WAN reconnection - [OVPN_REMOTE_IP] -> [OVPN_REMOTE_IP] - Restarting packages.
Dec 3 10:17:28	check_reload_status	446	Starting packages
Dec 3 10:17:28	check_reload_status	446	Reloading filter
Dec 3 10:17:28	snmpd	76516	disk_OS_get_disks: adding device 'mmcsd0boot1' to device list
Dec 3 10:17:28	snmpd	76516	disk_OS_get_disks: adding device 'mmcsd0boot0' to device list
Dec 3 10:17:29	php-fpm	405	/rc.start_packages: Restarting/Starting all packages.
Dec 3 10:17:29	php-fpm	405	/rc.start_packages: Stopping service nut
Dec 3 10:17:29	upsmon	37971	Signal 15: exiting
Dec 3 10:17:29	upsd	22980	User local-monitor@127.0.0.1 logged out from UPS [ups]
Dec 3 10:17:29	upsd	22980	mainloop: Interrupted system call
Dec 3 10:17:29	upsd	22980	Signal 15: exiting
Dec 3 10:17:29	usbhid-ups	54011	Signal 15: exiting
Dec 3 10:17:29	php-fpm	405	/rc.start_packages: Starting service nut
Dec 3 10:17:29	upsmon	94129	Startup successful
Dec 3 10:17:29	upsmon	94715	UPS [ups]: connect failed: Connection failure: Connection refused
Dec 3 10:17:29	upsmon	94715	Communications with UPS ups lost
Dec 3 10:17:29	usbhid-ups	3404	Startup successful
Dec 3 10:17:30	upsd	64401	listening on 127.0.0.1 port 3493
Dec 3 10:17:30	upsd	64401	listening on ::1 port 3493
Dec 3 10:17:30	upsd	64401	not listening on 127.0.0.1 port 3493
Dec 3 10:17:30	upsd	64401	listening on 172.17.37.1 port 3493
Dec 3 10:17:30	upsd	64401	Connected to UPS [ups]: usbhid-ups-ups
Dec 3 10:17:30	upsd	64401	Found 1 UPS defined in ups.conf
Dec 3 10:17:30	upsd	64746	Startup successful
Dec 3 10:17:31	php-cgi	30150	notify_monitor.php: Message sent to [EMAIL_ADDRESS] OK
Dec 3 10:17:32	upsmon	69466	Startup successful
Dec 3 10:17:32	upsmon	70265	UPS [ups]: connect failed: Connection failure: Connection refused
Dec 3 10:17:32	upsmon	70265	Communications with UPS ups lost
Dec 3 10:17:32	php-fpm	405	/rc.start_packages: Configuration Change: (system): pfBlockerNG: saving DNSBL changes
Dec 3 10:17:32	check_reload_status	446	Syncing firewall
Dec 3 10:17:33	usbhid-ups	83567	Startup successful
Dec 3 10:17:33	php-fpm	405	/rc.start_packages: Configuration Change: (system): pfBlockerNG: saving Firewall rules
Dec 3 10:17:33	check_reload_status	446	Syncing firewall
Dec 3 10:17:33	upsd	53148	listening on 127.0.0.1 port 3493
Dec 3 10:17:33	upsd	53148	listening on ::1 port 3493
Dec 3 10:17:33	upsd	53148	not listening on 127.0.0.1 port 3493
Dec 3 10:17:33	upsd	53148	listening on 172.17.37.1 port 3493
Dec 3 10:17:33	upsd	53148	Connected to UPS [ups]: usbhid-ups-ups
Dec 3 10:17:33	upsd	53148	Found 1 UPS defined in ups.conf
Dec 3 10:17:33	upsd	53361	Startup successful
Dec 3 10:17:33	check_reload_status	446	Reloading filter
Dec 3 10:17:33	tail_pfb	54842	[pfBlockerNG] Firewall Filter Service stopped
Dec 3 10:17:33	php_pfb	55146	[pfBlockerNG] filterlog daemon stopped
Dec 3 10:17:33	php-fpm	405	[pfBlockerNG] Restarting firewall filter daemon
Dec 3 10:17:33	tail_pfb	57941	[pfBlockerNG] Firewall Filter Service stopped
Dec 3 10:17:33	php_pfb	58420	[pfBlockerNG] filterlog daemon stopped
Dec 3 10:17:33	tail_pfb	60618	[pfBlockerNG] Firewall Filter Service started
Dec 3 10:17:34	php_pfb	61034	[pfBlockerNG] filterlog daemon started
Dec 3 10:17:34	php-fpm	405	/rc.start_packages: Configuration Change: (system): [pfSense-pkg-WireGuard] De-installed earlyshellcmd(s).
Dec 3 10:17:34	php-fpm	405	/rc.start_packages: Configuration Change: (system): [pfSense-pkg-WireGuard] Installed earlyshellcmd(s).
Dec 3 10:17:34	php-fpm	405	/rc.start_packages: Configuration Change: (system): [pfSense-pkg-WireGuard] De-installed interface group (WireGuard).
Dec 3 10:17:34	php-fpm	405	/rc.start_packages: Configuration Change: (system): [pfSense-pkg-WireGuard] Installed interface group (WireGuard).
Dec 3 10:17:34	php-fpm	405	/rc.start_packages: Configuration Change: (system): [pfSense-pkg-WireGuard] De-installed Unbound ACL group (WireGuard).
Dec 3 10:17:34	php-fpm	405	/rc.start_packages: Configuration Change: (system): [pfSense-pkg-WireGuard] Installed Unbound ACL group (WireGuard).
Dec 3 10:17:34	php-fpm	405	/rc.start_packages: Configuration Change: (system): [pfSense-pkg-WireGuard] Applied package default settings as necessary.
Dec 3 10:17:34	check_reload_status	446	Syncing firewall
Dec 3 10:17:34	tail_pfb	73724	[pfBlockerNG] Firewall Filter Service stopped
Dec 3 10:17:34	php_pfb	74675	[pfBlockerNG] filterlog daemon stopped
Dec 3 10:17:35	tail_pfb	77851	[pfBlockerNG] Firewall Filter Service started
Dec 3 10:17:35	php_pfb	77971	[pfBlockerNG] filterlog daemon started
Dec 3 10:17:35	upsd	53361	User monuser@172.17.37.4 logged into UPS [ups]
Dec 3 10:17:37	upsd	53361	User monuser@172.17.37.50 logged into UPS [ups]
Dec 3 10:17:37	upsd	53361	User local-monitor@127.0.0.1 logged into UPS [ups]
Dec 3 10:17:37	upsmon	70265	Communications with UPS ups established
Dec 3 10:18:03	php-cgi	30150	notify_monitor.php: Message sent to [EMAIL_ADDRESS] OK

                                        I am able to 100% reproduce this by restarting the OpenVPN client connection, which seems strange for a USB-connected device. I've had this same UPS connected for about a year without any issues, but I started getting these emails after upgrading to pfSense 23.09 and nut 2.8.2 the other week.

                                        I do have my pfSense system set up as the nut 'master' for a few other devices on my network, including my two Synology NASes. Nothing complicated, but I do have the two "LISTEN" directives in the Additional configuration lines for upsd.conf section:

                                        LISTEN 127.0.0.1
LISTEN 172.17.37.1

                                        And to further confuse things, while going through the logs to debug this, I also see some entries like the following that don't seem to be related to OpenVPN activity, but do suggest some USB issues:

                                        Dec 3 09:02:48	kernel		ugen0.2: <American Power Conversion Back-UPS RS 1000MS FW:950.e3 .D USB FW:e3> at usbus0 (disconnected)
Dec 3 09:02:48	usbhid-ups	77697	Got disconnected by another driver: Device not configured
Dec 3 09:02:50	usbhid-ups	77697	libusb1: Could not open any HID devices: no USB buses found
Dec 3 09:02:50	upsd	22894	Data for UPS [ups] is stale - check driver
Dec 3 09:02:52	usbhid-ups	77697	libusb1: Could not open any HID devices: no USB buses found
Dec 3 09:02:54	usbhid-ups	77697	libusb1: Could not open any HID devices: no USB buses found
Dec 3 09:02:55	upsmon	66759	Poll UPS [ups] failed - Data stale
Dec 3 09:02:55	upsmon	66759	Communications with UPS ups lost
Dec 3 09:02:56	kernel		ugen0.2: <American Power Conversion Back-UPS RS 1000MS FW:950.e3 .D USB FW:e3> at usbus0
Dec 3 09:02:56	upsd	22894	UPS [ups] data is no longer stale
Dec 3 09:03:00	upsmon	66759	Communications with UPS ups established
Dec 3 09:03:22	php-cgi	27865	notify_monitor.php: Message sent to [EMAIL_ADDRESS] OK

                                        Any ideas on this? It seems like a lot has changed with the 2.8.x branch and I wasn't having issues until recently, so I'm not sure how relevant some of the old conversations are.

                                        Thanks!

                                        dennypageD 2 Replies Last reply Reply Quote 0
                                        • dennypageD
                                          dennypage @mlake
                                          last edited by

                                          @mlake said in NUT Package (2.8.1 and above):

                                          Dec 3 10:17:28 check_reload_status 446 Starting packages
                                          Dec 3 10:17:28 check_reload_status 446 Reloading filter

                                          When you restart OpenVPN, the log shows that the interface (ovpnc2) going down, and then comming back up. pfSense reloads everything when an interface changes state like that. In short, the restart of NUT (and the other packages) is expected behavior.

                                          I am not knowledgeable enough on OpenVPN to know if there has been a change in how OpenVPN deals with interfaces in 23.09.

                                          mlakeM 1 Reply Last reply Reply Quote 0
                                          • mlakeM
                                            mlake @dennypage
                                            last edited by

                                            @dennypage Right, and that doesn’t surprise me. What I can’t figure out is why reloading the network interfaces causes a connection error for a USB-connected UPS.

                                            1 Reply Last reply Reply Quote 0
                                            • First post
                                              Last post