NUT package (2.8.0 and below)

spambait

pfsense 2.4.2-RELEASE-p1 (amd64)
nut 2.7.4_5

Polling an APC AP9631 on the LAN via SNMP.

When I reboot the appliance, UPS status shows as down. Log has a bunch of these:

Feb 19 21:40:27 upsmon 66529 Poll UPS [office-UPS] failed - Driver not connected
Feb 19 21:42:22 upsmon 67668 Startup successful
Feb 19 21:42:23 upsd 68233 listening on ::1 port 3493
Feb 19 21:42:23 upsd 68233 listening on 127.0.0.1 port 3493
Feb 19 21:42:23 upsd 68233 Can't connect to UPS [office-UPS] (snmp-ups-office-UPS): No such file or directory
Feb 19 21:42:23 upsd 68498 Startup successful
Feb 19 21:42:24 snmp-ups 68710 Startup successful

Now when I go to restart the service via the GUI In Services -> UPS, it starts up perfectly right away.

apcupsd was installed but I removed it when switching to NUT.

I tried using snmp v1 instead of v3 thinking I screwed up my v3 credentials but that doesn't seem to be the issue. Even with snmpv1 it wont come up after a reboot until I manually intervene.

I tried some of the retry and delay parameters in the additional parameters for ups.conf but they also didn't help with this


maxretry=3
retrydelay=10
pollinterval=5
snmp_retries=10
snmp_timeout=2
pollfreq=10

dennypage

Please give the following a try:

Get rid of pollfreq and pollinterval.

Set these variables in the Extra Arguments to driver section:


snmp_timeout=2
snmp_retries=10

Set these variables in the Advanced section for ups.conf:


retrydelay=30
maxretry=20

Now reboot the box. When the box comes up, go to the UPS status page. [Do not attempt to start the service manually] If the UPS shows as needing attention, wait for the page to refresh automatically. If it doesn't auto refresh, after a couple minutes refresh the page manually. Does the UPS show as running? Or is it still down?

spambait

@dennypage:

Please give the following a try:

Get rid of pollfreq and pollinterval.

Set these variables in the Extra Arguments to driver section:
snmp_timeout=2
snmp_retries=10
Set these variables in the Advanced section for ups.conf:
retrydelay=30
maxretry=20
Now reboot the box. When the box comes up, go to the UPS status page. [Do not attempt to start the service manually] If the UPS shows as needing attention, wait for the page to refresh automatically. If it doesn't auto refresh, after a couple minutes refresh the page manually. Does the UPS show as running? Or is it still down?

These settings work perfectly!

I am now back on SNMPv3 and NUT is performing as expected, across reboots and all. Thank you!

dennypage

That's good news. Now that it's working, you can probably tune the variables down quite a bit. In particular, the settings in Extra Arguments can likely be returned to their default values of 1 & 5. Or simply deleted.

spambait

@dennypage:

That's good news. Now that it's working, you can probably tune the variables down quite a bit. In particular, the settings in Extra Arguments can likely be returned to their default values of 1 & 5. Or simply deleted.

I think actually found a bug (with the AP9631, fw 6.5.0).

I just deployed a second AP9631 out of the box. Factory reset, flashed 6.5.0, factory reset again, set up SNMPv3 and had the same issues I described before where NUT cannot communicate.

I have now noticed that if I have SNMPv1 DISABLED, NUT will fail to connect via SNMPv3 no matter what extra settings I provide. Simply turning on SNMPv1 in the AP9631 (fw 6.5.0) immediately lets them communicate. Very strange. Further testing is needed.

I have replicated this on the previous installation where I can break the SNMPv3 communication between NUT and the AP9631 by disabling SNMPv1, don't even need to reboot.

this_fixes_it.JPG_thumb

this_breaks_it.JPG_thumb

dennypage

@spambait:

I just deployed a second AP9631 out of the box. Factory reset, flashed 6.5.0, factory reset again, set up SNMPv3 and had the same issues I described before where NUT cannot communicate.

I have now noticed that if I have SNMPv1 DISABLED, NUT will fail to connect via SNMPv3 no matter what extra settings I provide. Simply turning on SNMPv1 in the AP9631 (fw 6.5.0) immediately lets them communicate. Very strange. Further testing is needed.

I have replicated this on the previous installation where I can break the SNMPv3 communication between NUT and the AP9631 by disabling SNMPv1, don't even need to reboot.

It sounds like SNMPv3 may not be properly configured/functioning in NUT. Can you post the contents of /usr/local/etc/nut/ups.conf please?

spambait

@dennypage:

It sounds like SNMPv3 may not be properly configured/functioning in NUT. Can you post the contents of /usr/local/etc/nut/ups.conf please?

I am going to find an SNMPv3 client and try replicate this in a moment. If a different v3 client fails in the same way the issue is with AP9631.

If it doesn't then there may indeed be a NUT issue. Maybe it has some routine to check SNMPv1 availability before anything else, even if only SNMPv3 is needed.

I realize the credentials are in there but it's a sandbox setup so this is not really a concern. My full, unedited /usr/local/etc/nut/ups.conf:

retrydelay=30
maxretry=20
snmp_version=v3
privProtocol=AES
authProtocol=SHA
secName=pfSense
authPassword=VtwHzSj6XQlmp9OFFa28NJcUL93qq5zZ4
privPassword=TpWsICXWm4CeKtwUehtvcBpDnBW0KZCC

[S10-AP9631]
driver=snmp-ups
port=172.16.10.5
snmp_timeout=2
snmp_retries=10

dennypage

SNMP parameters are part of the UPS specification. As such, they go in the "Extra Arguments to driver" rather than in the "Additional configuration lines for ups.conf" section. The advanced section is only for Global Directives (see ups.conf), and anything that is not recognized as a global directive is ignored by NUT. I know it's confusing, but it's how NUT's configuration works. Anything that comes from the driver man page (snmp-ups in your case) goes into Extra Arguments to driver.

spambait

@dennypage:

SNMP parameters are part of the UPS specification. As such, they go in the "Extra Arguments to driver" rather than in the "Additional configuration lines for ups.conf" section. The advanced section is only for Global Directives (see ups.conf), and anything that is not recognized as a global directive is ignored by NUT. I know it's confusing, but it's how NUT's configuration works. Anything that comes from the driver man page (snmp-ups in your case) goes into Extra Arguments to driver.

That results in


[S10-AP9631]
driver=snmp-ups
port=172.16.10.5
snmp_timeout=2
snmp_retries=10
snmp_version=v3
privProtocol=AES
authProtocol=SHA
secLevel=authPriv
secName=pfSense
authPassword=VtwHzSj6XQlmp9OFFa28NJcUL93qq5zZ4
privPassword=TpWsICXWm4CeKtwUehtvcBpDnBW0KZCC

Edit: So it seems it was using SNMPv1 all along due to my mis-configuration resulting in the SNMPv3 stuff being ignored. There is no bug. Now that I have the correct structure in ups.conf it is indeed trying to connect SNMPv3 but it is not authenticating. The AP9631's built in baby IDS keeps sending me notifications now that there are failed SNMPv3 authentications from the pfSense IP.

I will switch her back to SNMPv1 for now and troubleshoot my SNMPv3 setup with qtmib

dennypage

That makes sense. For what it's worth, most people use a read-only SNMPv1 group for UPS monitoring. There isn't any sensitive information in the stream.

spambait

@dennypage:

That makes sense. For what it's worth, most people use a read-only SNMPv1 group for UPS monitoring. There isn't any sensitive information in the stream.

The docu said a write community is needed to facilitate shutdowns. I wanted the UPS and NUT to coordinate that NUT will shut down pfSense when there's not much runtime left and then tell the UPS to shut off the outlet in x minutes and come back up when AC power is restored and battery has at least y % charge.

Otherwise pfSense will just shut down and stay down until someone presses the power button or the BIOS power on time is reached.

dennypage

@spambait:

The docu said a write community is needed to facilitate shutdowns. I wanted the UPS and NUT to coordinate that NUT will shut down pfSense when there's not much runtime left and then tell the UPS to shut off the outlet in x minutes and come back up when AC power is restored and battery has at least y % charge.

Ah, yes. Needing write permission to kill power makes sense. Note that the pfSense NUT package version 2.7.4_5 does not support issuing the final power kill order. This will come with NUT package 2.7.4_6 which requires pfSense 2.4.3.

xx_robot_xx

Hello,

How do you configure power-kill after shutdown? I have pfsense 2.4.3 and latest version of nut..

dennypage

Power kill is enabled automatically with pfSense 2.4.3 and 2.7.4_6 of the NUT package. No configuration necessary.

kjstech

Hello,

I have a TrippLite Smart 1300VA unit connected via USB. dmesg does show it connected. This model is also one listed in NUT to use the USB driver (not the legacy TrippLite driver). I got readings from it very briefly last night when setting it up, but also a bunch of messages in the log about the data being stale. This was on pfSense 2.4.1.

Now it doesn't work at all. I upgraded to the latest NUT package. No dice. I upgraded pfSense to 2.4.3… no dice.

All I get is this in the status logs:
Apr 4 14:57:20 upsd 97125 User monuser@::1 logged into UPS [main]
Apr 4 14:57:20 upsmon 60509 Poll UPS [main] failed - Driver not connected
Apr 4 14:57:20 upsmon 60509 Communications with UPS main lost
Apr 4 14:57:25 upsmon 60509 Poll UPS [main] failed - Driver not connected
Apr 4 14:57:25 upsmon 60509 UPS main is unavailable
Apr 4 14:57:30 upsmon 60509 Poll UPS [main] failed - Driver not connected
Apr 4 14:57:35 upsmon 60509 Poll UPS [main] failed - Driver not connected

Like I said, system sees it, here's the USB stuff pulled from dmesg:
dmesg | grep usb
usbus0: EHCI version 1.0
usbus0 on ehci0
usbus0: 480Mbps High Speed USB v2.0
usbus1: EHCI version 1.0
usbus1 on ehci1
usbus1: 480Mbps High Speed USB v2.0
ugen0.1: <intel ehci="" root="" hub="">at usbus0
ugen1.1: <intel ehci="" root="" hub="">at usbus1
uhub0: <intel 1="" 9="" ehci="" root="" hub,="" class="" 0,="" rev="" 2.00="" 1.00,="" addr="">on usbus0
uhub1: <intel 1="" 9="" ehci="" root="" hub,="" class="" 0,="" rev="" 2.00="" 1.00,="" addr="">on usbus1
ugen1.2: <vendor 0x8087="" product="" 0x0024="">at usbus1
uhub2: <vendor 2="" 9="" 0x8087="" product="" 0x0024,="" class="" 0,="" rev="" 2.00="" 0.00,="" addr="">on usbus1
ugen0.2: <vendor 0x8087="" product="" 0x0024="">at usbus0
uhub3: <vendor 2="" 9="" 0x8087="" product="" 0x0024,="" class="" 0,="" rev="" 2.00="" 0.00,="" addr="">on usbus0
ugen0.3: <tripp lite="" tripp="" ups="">at usbus0
uhid0: <tripp 0="" 3="" lite="" tripp="" ups,="" class="" 0,="" rev="" 1.10="" 0.02,="" addr="">on usbus0
usbus0: EHCI version 1.0
usbus0 on ehci0
usbus0: 480Mbps High Speed USB v2.0
usbus1: EHCI version 1.0
usbus1 on ehci1
usbus1: 480Mbps High Speed USB v2.0
ugen1.1: <intel ehci="" root="" hub="">at usbus1
ugen0.1: <intel ehci="" root="" hub="">at usbus0
uhub0: <intel 1="" 9="" ehci="" root="" hub,="" class="" 0,="" rev="" 2.00="" 1.00,="" addr="">on usbus1
uhub1: <intel 1="" 9="" ehci="" root="" hub,="" class="" 0,="" rev="" 2.00="" 1.00,="" addr="">on usbus0
ugen0.2: <vendor 0x8087="" product="" 0x0024="">at usbus0
uhub2: <vendor 2="" 9="" 0x8087="" product="" 0x0024,="" class="" 0,="" rev="" 2.00="" 0.00,="" addr="">on usbus0
ugen1.2: <vendor 0x8087="" product="" 0x0024="">at usbus1
uhub3: <vendor 2="" 9="" 0x8087="" product="" 0x0024,="" class="" 0,="" rev="" 2.00="" 0.00,="" addr="">on usbus1
ugen0.3: <vendor 0x09ae="" product="" 0x3016="">at usbus0
uhid0: <vendor 0="" 3="" 0x09ae="" product="" 0x3016,="" class="" 0,="" rev="" 1.10="" 0.02,="" addr="">on usbus0
usbus0: EHCI version 1.0
usbus0 on ehci0
usbus0: 480Mbps High Speed USB v2.0
usbus1: EHCI version 1.0
usbus1 on ehci1
usbus1: 480Mbps High Speed USB v2.0
ugen1.1: <intel ehci="" root="" hub="">at usbus1
ugen0.1: <intel ehci="" root="" hub="">at usbus0
uhub0: <intel 1="" 9="" ehci="" root="" hub,="" class="" 0,="" rev="" 2.00="" 1.00,="" addr="">on usbus1
uhub1: <intel 1="" 9="" ehci="" root="" hub,="" class="" 0,="" rev="" 2.00="" 1.00,="" addr="">on usbus0
ugen1.2: <vendor 0x8087="" product="" 0x0024="">at usbus1
uhub2: <vendor 2="" 9="" 0x8087="" product="" 0x0024,="" class="" 0,="" rev="" 2.00="" 0.00,="" addr="">on usbus1
ugen0.2: <vendor 0x8087="" product="" 0x0024="">at usbus0
uhub3: <vendor 2="" 9="" 0x8087="" product="" 0x0024,="" class="" 0,="" rev="" 2.00="" 0.00,="" addr="">on usbus0
ugen0.3: <tripp lite="" tripp="" ups="">at usbus0
uhid0: <tripp 0="" 3="" lite="" tripp="" ups,="" class="" 0,="" rev="" 1.10="" 0.02,="" addr="">on usbus0

Anyone know how I can get this to work?
pfSense has been rebooted twice now. Once for the 2.4.3 upgrade. And another time after I removed NUT package and reinstalled NUT package. NUT is version 2.7.4_6.

Thanks!</tripp></tripp></vendor></vendor></vendor></vendor></intel></intel></intel></intel></vendor></vendor></vendor></vendor></vendor></vendor></intel></intel></intel></intel></tripp></tripp></vendor></vendor></vendor></vendor></intel></intel></intel></intel>

dennypage

@kjstech:

I have a TrippLite Smart 1300VA unit connected via USB. dmesg does show it connected. This model is also one listed in NUT to use the USB driver (not the legacy TrippLite driver).

Please run "usbconfig dump_device_desc" and post the output. Also, can you post the contents of /usr/local/etc/nut/ups.conf please? And lastly, the exact model number of the UPS.

Btw, where did you see the note about using the usbhid-ups vs. the tripplite_usb driver? I didn't find a Tripp Lite 1300VA model in the NUT HCL…

kjstech

Ok the model number is SMART1300LCDT. I was at work when I posted and I forgot the exact model number. I was told I can use usbhid-ups from here: http://networkupstools.org/ddl/Tripp_Lite/SMART1300LCDT.html

Here is the output of usbconfig dump_device_desc
ugen1.1: <intel ehci="" root="" hub="">at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)

bLength = 0x0012
bDescriptorType = 0x0001
bcdUSB = 0x0200
bDeviceClass = 0x0009 <hub>bDeviceSubClass = 0x0000
bDeviceProtocol = 0x0001
bMaxPacketSize0 = 0x0040
idVendor = 0x0000
idProduct = 0x0000
bcdDevice = 0x0100
iManufacturer = 0x0001 <intel>iProduct = 0x0002 <ehci root="" hub="">iSerialNumber = 0x0000 <no string="">bNumConfigurations = 0x0001

ugen0.1: <intel ehci="" root="" hub="">at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)

bLength = 0x0012
bDescriptorType = 0x0001
bcdUSB = 0x0200
bDeviceClass = 0x0009 <hub>bDeviceSubClass = 0x0000
bDeviceProtocol = 0x0001
bMaxPacketSize0 = 0x0040
idVendor = 0x0000
idProduct = 0x0000
bcdDevice = 0x0100
iManufacturer = 0x0001 <intel>iProduct = 0x0002 <ehci root="" hub="">iSerialNumber = 0x0000 <no string="">bNumConfigurations = 0x0001

ugen1.2: <vendor 0x8087="" product="" 0x0024="">at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)

bLength = 0x0012
bDescriptorType = 0x0001
bcdUSB = 0x0200
bDeviceClass = 0x0009 <hub>bDeviceSubClass = 0x0000
bDeviceProtocol = 0x0001
bMaxPacketSize0 = 0x0040
idVendor = 0x8087
idProduct = 0x0024
bcdDevice = 0x0000
iManufacturer = 0x0000 <no string="">iProduct = 0x0000 <no string="">iSerialNumber = 0x0000 <no string="">bNumConfigurations = 0x0001

ugen0.2: <vendor 0x8087="" product="" 0x0024="">at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)

bLength = 0x0012
bDescriptorType = 0x0001
bcdUSB = 0x0200
bDeviceClass = 0x0009 <hub>bDeviceSubClass = 0x0000
bDeviceProtocol = 0x0001
bMaxPacketSize0 = 0x0040
idVendor = 0x8087
idProduct = 0x0024
bcdDevice = 0x0000
iManufacturer = 0x0000 <no string="">iProduct = 0x0000 <no string="">iSerialNumber = 0x0000 <no string="">bNumConfigurations = 0x0001

ugen0.3: <tripp lite="" tripp="" ups="">at usbus0, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON (100mA)

bLength = 0x0012
bDescriptorType = 0x0001
bcdUSB = 0x0110
bDeviceClass = 0x0000 <probed by="" interface="" class="">bDeviceSubClass = 0x0000
bDeviceProtocol = 0x0000
bMaxPacketSize0 = 0x0008
idVendor = 0x09ae
idProduct = 0x3016
bcdDevice = 0x0002
iManufacturer = 0x0003 <retrieving string="" failed="">iProduct = 0x0001 <retrieving string="" failed="">iSerialNumber = 0x0005 <retrieving string="" failed="">bNumConfigurations = 0x0001

cat /usr/local/etc/nut/ups.conf
[main]
driver=usbhid-ups
port=auto

It worked for about a minute last night when I initially tried it, but then it stopped working and hasn't worked since. Now on the SSH console I randomly see these UPS main is unavailable messages.</retrieving></retrieving></retrieving></probed></tripp></no></no></no></hub></vendor></no></no></no></hub></vendor></no></ehci></intel></hub></intel></no></ehci></intel></hub></intel>

kjstech

I also wanted to add, I tried specifying more detail in the ups.conf like the port and description, and also change the poll interval.

[main]
driver=usbhid-ups
port=/dev/ugen0.3
desc="Tripp Lite TRIPP LITE UPS"
pollinterval=20

Still nothing.

It almost seems to be maybe a permissions problem? But even if I try to run it as root it shows this:
[2.4.3-RELEASE][root@pfSense.local]/usr/local/etc/nut: upsd -DDDD
Network UPS Tools upsd 2.7.4
0.000000 fopen /var/db/nut/upsd.pid: No such file or directory
0.000235 listen_add: added 127.0.0.1:3493
0.000376 listen_add: added ::1:3493
0.000393 setuptcp: try to bind to ::1 port 3493
0.000427 listening on ::1 port 3493
0.000439 setuptcp: try to bind to 127.0.0.1 port 3493
0.000457 listening on 127.0.0.1 port 3493
0.000580 Can't open /usr/local/etc/nut/ups.conf: Can't open /usr/local/etc/nut/ups.conf: Permission denied

[2.4.3-RELEASE][root@pfSense.local]/usr/local/etc/nut: ls -lah
total 164
drwxr-xr-x 2 root wheel 512B Apr 4 14:49 .
drwxr-xr-x 23 root wheel 2.0K Apr 4 14:56 ..
-rw-r–r-- 1 root wheel 14K Mar 16 13:16 cmdvartab
-rw-r--r-- 1 root wheel 76K Mar 16 13:16 driver.list
-rw-r--r-- 1 root wheel 15B Apr 4 12:28 nut.conf
-rw-r--r-- 1 root wheel 1.5K Mar 16 13:16 nut.conf.sample
-rw-r----- 1 root wheel 92B Apr 4 21:44 ups.conf
-rw-r--r-- 1 root wheel 4.5K Mar 16 13:16 ups.conf.sample
-rw-r----- 1 root wheel 28B Apr 4 21:42 upsd.conf
-rw-r--r-- 1 root wheel 4.5K Mar 16 13:16 upsd.conf.sample
-rw-r----- 1 root wheel 117B Apr 4 21:42 upsd.users
-rw-r--r-- 1 root wheel 2.1K Mar 16 13:16 upsd.users.sample
-rw-r----- 1 root wheel 115B Apr 4 21:42 upsmon.conf
-rw-r--r-- 1 root wheel 15K Mar 16 13:16 upsmon.conf.sample
-rw-r--r-- 1 root wheel 3.8K Mar 16 13:16 upssched.conf.sample

just for the hell of it, I did chmod 777 ups.conf since it seemed to be complaining about permissions reading that file.

Then it complained about upsd.users, so again for testing I did chmod 777 upsd.users

-rwxrwxrwx 1 root wheel 92B Apr 4 21:44 ups.conf
-rwxrwxrwx 1 root wheel 117B Apr 4 21:42 upsd.users

It kept looping no data available so I killed it.
upsd -DDDD
Network UPS Tools upsd 2.7.4
0.000000 fopen /var/db/nut/upsd.pid: No such file or directory
0.000255 listen_add: added 127.0.0.1:3493
0.000403 listen_add: added ::1:3493
0.000424 setuptcp: try to bind to ::1 port 3493
0.000483 listening on ::1 port 3493
0.000505 setuptcp: try to bind to 127.0.0.1 port 3493
0.000533 listening on 127.0.0.1 port 3493
0.000751 Can't connect to UPS [main] (usbhid-ups-main): No such file or directory
0.001695 /usr/local/etc/nut/upsd.users is world readable
0.001731 user_add_action: adding 'set' for admin
0.001747 user_add_instcmd: adding 'all' for admin
0.001764 user_add_action: adding 'login' for monuser
0.001776 user_add_action: adding 'master' for monuser
0.001789 user_add_action: adding 'fsd' for monuser
0.001824 mainloop: polling 2 filedescriptors
2.015622 mainloop: no data available
2.015697 mainloop: polling 2 filedescriptors
4.027074 mainloop: no data available
4.027150 mainloop: polling 2 filedescriptors
6.056806 mainloop: no data available
6.056881 mainloop: polling 2 filedescriptors
8.059687 mainloop: no data available
8.059757 mainloop: polling 2 filedescriptors
10.068805 mainloop: no data available
10.068882 mainloop: polling 2 filedescriptors
12.084621 mainloop: no data available
12.084699 mainloop: polling 2 filedescriptors
14.085689 mainloop: no data available
14.085777 mainloop: polling 2 filedescriptors
16.106784 mainloop: no data available
16.106835 mainloop: polling 2 filedescriptors
^C 17.722668 mainloop: Interrupted system call
17.722703 Signal 2: exiting

Does this help at all?

dennypage

@kjstech:

ugen0.3: <tripp lite="" tripp="" ups="">at usbus0, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON (100mA)

bLength = 0x0012
bDescriptorType = 0x0001
bcdUSB = 0x0110
bDeviceClass = 0x0000 <probed by="" interface="" class="">bDeviceSubClass = 0x0000
bDeviceProtocol = 0x0000
bMaxPacketSize0 = 0x0008
idVendor = 0x09ae
idProduct = 0x3016
bcdDevice = 0x0002
iManufacturer = 0x0003 <retrieving string="" failed="">iProduct = 0x0001 <retrieving string="" failed="">iSerialNumber = 0x0005 <retrieving string="" failed="">bNumConfigurations = 0x0001</retrieving></retrieving></retrieving></probed></tripp>

The "retrieving string failed" is something I haven't seen before and would seem problematic. First thing I would suggest is trying a USB port on the other bridge chip. I would also test a different cable.

kjstech

Ok I did try another USB port and its the same results.

I'm at work now, I can try a new USB A to B cable. There's 6 ports on the back, 2 on the front. Its a Dell Optiplex 390. It doesn't appear to have USB 3.0 - at least none of the ports are blue. I could also throw in a USB 3.0 PCIe card if none of the onboard ports work. TrippLite's website does not appear to have any firmware for this model. If it did I would plug into my Windows laptop temporally and update it.