v1.3.0rcX BETA bug reports and comments - CLOSED

[quantumx]

Overview:

Installed 1.3.0rc7 on another switch 4 days ago. Power Smart feature disabled a RocketM5 XW after 3 days - no errors recorded on port before or since. We disabled PS feature on the port. No other switch ports were affected (powering 3x RocketM XM, 2x AF5 - all cabling approximately the same length). Switch log is attached.

Switch:

Model WS-12-250A
Firmware 1.3.0rc7
Board Rev B

Cabling: ToughCable Carrier, UBNT shielded RJ45 termination, approximately 60m long

Switch Log:

Jun 13 20:07:16 switch[1387]: Port 11 unplugged, PoE Smart is disabling PoE
Jun 13 20:07:18 switch[1387]: Port 11 has link, disabling PoE
Jun 13 20:07:20 switch[1387]: PoE enabled on port 11, PoE Smart is starting cable check
Jun 13 20:07:24 switch[1387]: Port 11 cable check results: Open, Open, Short, Open
Jun 13 20:07:24 switch[1387]: Port 11 passed PoE Smart cable check, turning on power
Jun 13 20:30:03 UI: Configuration changed by x.x.x.x
Jun 13 20:30:03 UI: Port 11 PoE: changed from 'Off' to '24V' <- me enabling power
Jun 13 20:30:03 UI: Port 11 PoE_Smart: changed from 'Enabled' to 'Disabled' <- me disabling PS

Again, may I recommend that this feature not be enabled by default on an update?

[sirhc]

Thanks for the update but something had to cause it to think the cable was unplugged?

One reason this might have happened is the radio would have rebooted maybe a ping watchdog or something along those lines?

Yea we will be releasing another v1.3.0 soon and I think I will dumb down POE smart to only check cabling for cross shorts when you turn POE on.

Either way I think the next version of POE Smart will not turn POE off if you unplug a device or the link goes down.

I have to think about it.

People need to remember v1.3.0 is a BETA/RC firmware so please do not install it at critical locations stick with v1.2.2 STABLE

[quantumx]

Can guarantee that ping watchdog is disabled on both radio and switch.

I'm definitely not blaming you for this, we're simply observing and reporting the issue to help with the development process.

Would it make more sense to:

1. Check port for problems when PoE is initially enabled, dropping the port if a problem is detected

and

2. FLAG / LOG a port with a potential problem that is operating.

This would be more operator friendly, allowing for the identification of possible cabling problems, but limiting unplanned service outages.

[lligetfa]

One reason this might have happened is the radio would have rebooted maybe a ping watchdog or something along those lines?

Does not the smarts also watch the current draw on the port at the same time? A watchdog reboot should not stop the current draw.

[sirhc]

Currently POE smart would disable POE on a port if one of the 2 following conditions were met:
1) Ethernet link drop
2) Current draw dropped to 0

[adairw]

loading rc9

[ralliart12]

Currently POE smart would disable POE on a port if one of the 2 following conditions were met:
1) Ethernet link drop
2) Current draw dropped to 0

Am on RC9; what I observed:

1. If my PoE downstream device is linked via a patch panel; every time I power down & up the switch, PoE will not be re-activated for that device automatically. The logs appears like this (the part in brown is me manually activating PoE on that port):
Jan 1 08:00:08 kernel: vtss_port: Loaded port module on board Luton26, type 5
Jan 1 08:00:09 system: Setting MAC address from flash configuration: EC:13:B3:61:06:4A
Jan 1 08:00:10 system: starting ntpclient Jan 1 08:00:11 admin: adding lan (eth0) to firewall zone lan
Jan 1 08:00:18 pinger: Ignoring port bounces because date is wrong
Jan 1 08:00:20 dropbear[733]: Running in background
Jan 1 08:00:22 switch[760]: Port 2 unplugged, PoE Smart is disabling PoE
Jan 1 08:00:24 system: starting ntpclient
Jan 1 08:00:35 system: starting ntpclient
Jan 1 08:00:46 system: starting ntpclient
Jan 1 08:00:57 system: starting ntpclient
Jan 1 08:01:08 system: starting ntpclient
Jan 1 08:07:15 UI: Configuration changed by 192.168.1.103
Jan 1 08:09:53 UI: Port 2 PoE: changed from 'Off' to '48V'
Jan 1 08:09:56 switch[760]: PoE enabled on port 2, PoE Smart is starting cable check
Jan 1 08:10:01 switch[760]: Port 2 cable check results: Abnormal termination, Open, Abnormal termination, Abnormal termination
Jan 1 08:10:01 switch[760]: Port 2 passed PoE Smart cable check, turning on power

2. If my PoE downstream device is connected directly to the switch, power cycles will still automatically re-power up the device. The logs appears like this (there is no entry indicating the PoE power is automatically activated; though it is observed to be so):
Jan 1 08:00:08 kernel: vtss_port: Loaded port module on board Luton26, type 5
Jan 1 08:00:09 system: Setting MAC address from flash configuration: EC:13:B3:61:06:4A
Jan 1 08:00:10 system: starting ntpclient
Jan 1 08:00:11 admin: adding lan (eth0) to firewall zone lan
Jan 1 08:00:18 pinger: Ignoring port bounces because date is wrong
Jan 1 08:00:20 dropbear[733]: Running in background
Jan 1 08:00:24 system: starting ntpclient
Jan 1 08:00:35 system: starting ntpclient
Jan 1 08:00:46 system: starting ntpclient
Jan 1 08:00:57 system: starting ntpclient
Jan 1 08:01:08 system: starting ntpclient

*observations conducted with same switch, same downstream device, same PoE port (on the switch).

Which leads me to ponder how PoE smart should behave as well. Given the 2 conditions that may deactivate the PoE (when any one of them is true), wouldn't that defeat the purpose of PoE? Because I'm pretty sure I'm not the only user that connects a PD to the switch via a patch panel. So every time I power off the switch, the PD naturally loses power, which means it draws 0 current, & also means the Ethernet link is dropped. That means the 2 conditions resulting in PoE smart deactivating the PD will always be true the next time I power on the switch.

On the other hand, assuming I never power off the switch & never physically disconnect the PD, the 2 conditions that causes PoE smart to deactivate the PoE, will never be true.

Qn1) So am I right to say that, the only situation that requires the benefit of PoE smart, is when the PD (i) spoils; (ii) gets disconnected?

Qn2) Can PoE smart work with PDs that are hooked up via patch panels?

[sirhc]

I had requested that Eric change POE Smart to ONLY check for cross shorts on POE turn up on a Save/Apply and on a cold boot.

However I have not had time to check if he made these changes in v1.3.0rc11 which I posted yesterday.

I know that v1.3.0rc9 did NOT have these changes and I am not sure if rc11 has them?

I will skype this post to Eric and ask him to weigh in.

[Eric Stern]

This is fixed in rc11.

[ralliart12]

I had requested that Eric change POE Smart to ONLY check for cross shorts on POE turn up on a Save/Apply and on a cold boot...

If the PD is connected via a patch panel, will the PoE smart test still evaluates the status of the port as "unplugged" & still disable PoE on a cold boot?