Title says it all... There is no functional difference (other than filesystem location) between the running-config and the persistent config in /etc.

The persistent config is saved automatically by poed. If I delete it, it is automatically reconstituted based on the current poed settings. Since the file is saved as part of background processing by poed, there is no safe way to snapshot the poed state.

To reproduce:

1. disable a port
2. execute poecli restore
3. note that the port is no longer disabled.

The restore function should ideally restore port configuration from the last saved running-config.

The poed software saves volatile state (locks etc.) in /tmp instead of a secure, volatile location in /run.

We are studying this PoE function now.
According to the information in the readme file, Readme.md, there will be a folder "smbus2", but we can not find it now.
Do you miss to push this third party library to github?

Folder Architeture

• smbus2 – The third party library used for i2c communications in python.

Invoking poecli with an invalid port specifier does not report the error correctly

1. The error is sent to stdout instead of stderr (trampling any JSON output)
2. The system exit code is 0, indicating the command succeeded.

If I disable a port in poed, then reset the agent, it appears to briefly re-enable the port, potentially creating an unsafe config.

root@localhost:~# poecli set -p 1 -e 0
root@localhost:~# poecli show -p 1

Port  Status             En/Dis   Priority  Protocol        Class  PWR Consump  PWR Limit    Voltage    Current
----  -----------------  -------  --------  --------------  -----  -----------  -----------  ---------  --------
1     Port Off (0x1A)    disable    low     IEEE802.3AF/AT    4         0 (mW)   30000 (mW)    0.0 (V)    0 (mA)

root@localhost:~# systemctl restart poed
root@localhost:~# poecli show -p 1

Port  Status             En/Dis   Priority  Protocol        Class  PWR Consump  PWR Limit    Voltage    Current
----  -----------------  -------  --------  --------------  -----  -----------  -----------  ---------  --------
1     Port Off (0x1B)    enable     low     IEEE802.3AF/AT    0         0 (mW)   30000 (mW)    0.0 (V)    0 (mA)

root@localhost:~# poecli show -p 1

Port  Status             En/Dis   Priority  Protocol        Class  PWR Consump  PWR Limit    Voltage    Current
----  -----------------  -------  --------  --------------  -----  -----------  -----------  ---------  --------
1     Port Off (0x1A)    disable    low     IEEE802.3AF/AT    4         0 (mW)   30000 (mW)    0.0 (V)    0 (mA)

root@localhost:~# poecli show -p 1

Port  Status             En/Dis   Priority  Protocol        Class  PWR Consump  PWR Limit    Voltage    Current
----  -----------------  -------  --------  --------------  -----  -----------  -----------  ---------  --------
1     Port Off (0x1A)    disable    low     IEEE802.3AF/AT    4         0 (mW)   30000 (mW)    0.0 (V)    0 (mA)

I had to insert some debug statements into the driver to illustrate this, but intermittently some of the devices get into a state where the serial link to the poe chipset breaks down and cannot sync. A reset of poed does not fix the issue and a 'restore' (poe chipset factory reset) also does not fix the issue. Anecdotally I have found that rebooting the device can correct the issue.

Nov 19 01:03:40 lab05-ihm-infra-sw1 poed.py[1396]: ERR: Failed to get system power bank
Nov 19 01:03:40 lab05-ihm-infra-sw1 poed.py[1396]: ERR: MSG: 00 00 00 00 00 00 00 00 00 00 00 00 00 03 af
Nov 19 01:03:40 lab05-ihm-infra-sw1 poed.py[1396]: ERR: Tx key is 2, Rx key should be 82, but received 0
Nov 19 01:03:40 lab05-ihm-infra-sw1 poed.py[1396]: ERR: MSG: 00 00 00 00 00 00 00 00 00 00 00 00 00 03 af
Nov 19 01:03:40 lab05-ihm-infra-sw1 poed.py[1396]: ERR: Tx key is 2, Rx key should be 82, but received 0
Nov 19 01:03:40 lab05-ihm-infra-sw1 poed.py[1396]: ERR: MSG: 00 00 00 00 00 00 00 00 00 00 00 00 00 03 af
Nov 19 01:03:40 lab05-ihm-infra-sw1 poed.py[1396]: ERR: Tx key is 2, Rx key should be 82, but received 0
Nov 19 01:03:40 lab05-ihm-infra-sw1 poed.py[1396]: ERR: MSG: 00 00 00 00 00 00 00 00 00 00 00 00 00 03 af
Nov 19 01:03:40 lab05-ihm-infra-sw1 poed.py[1396]: ERR: Tx key is 2, Rx key should be 82, but received 0
Nov 19 01:03:40 lab05-ihm-infra-sw1 poed.py[1396]: ERR: MSG: 00 00 00 00 00 00 00 00 00 00 00 00 00 03 af
Nov 19 01:03:40 lab05-ihm-infra-sw1 poed.py[1396]: ERR: Tx key is 2, Rx key should be 82, but received 0
Nov 19 01:03:40 lab05-ihm-infra-sw1 poed.py[1396]: ERR: MSG: 00 00 00 00 00 00 00 00 00 00 00 00 00 03 af
Nov 19 01:03:40 lab05-ihm-infra-sw1 poed.py[1396]: ERR: Tx key is 2, Rx key should be 82, but received 0
Nov 19 01:03:40 lab05-ihm-infra-sw1 poed.py[1396]: ERR: Traceback (most recent call last):
Nov 19 01:03:40 lab05-ihm-infra-sw1 poed.py[1396]: ERR:   File "/opt/poeagent/drivers/poe_driver_pd69200.py", line 133, in _communicate
Nov 19 01:03:40 lab05-ihm-infra-sw1 poed.py[1396]: ERR:     self._check_rx_msg(rx_msg, tx_msg)
Nov 19 01:03:40 lab05-ihm-infra-sw1 poed.py[1396]: ERR:   File "/opt/poeagent/drivers/poe_driver_pd69200.py", line 112, in _check_rx_msg
Nov 19 01:03:40 lab05-ihm-infra-sw1 poed.py[1396]: ERR:     raise RuntimeError("Key field in Tx/Rx message is mismatch")

Poed maintains a system-wide exclusive lock for access to the PoE chipset communications channel. This lock is maintained poorly and the error recovery for failed lock attempts is incorrect. This can lead invalid poed state.

1. the try/except code that manages the exclusive lock includes the safe code path inside the lock exception handler. Meaning, the safe code path can throw an exception similar to the lock syscall and poed cannot tell the difference.
2. Exception handling for a failed lock attempt does not provide adequate context to the user as to the failure cause or location
3. Failed lock attempts are ignored (the safe code path result skipped).

On poed startup, poed attempts to load and apply settings in the volatile and/or persistent config. This step sometimes fails. The error shown in the log does not indicate why the load failed, and does not provide any guidance on how much of the config was applied.

There appears to be some sort of timing/race condition between poecli set and poecli cfg -s. If the poed config is saved shortly after a recent set command the port settings are not correctly reflected in the saved config. In all cases the actual poed state is correct (the poecli set command did work).

Try the following:

poecli set -e 1 -p 1-48
poecli cfg -s
grep -c "enable" /etc/poe_agent/poe_perm_cfg.json
poecli set -e 0 -p 1-48
poecli cfg -s
grep -c "enable" /etc/poe_agent/poe_perm_cfg.json
...

That is, if you repeatedly enable then disable all ports, with a config-save in-between, you should see alternately '0' and '48' printed out above. What actually happens is that the number of enabled ports is incorrect (not the expected '0' or '48') and there is a corresponding error in the poed systemd journal to the effect of "unable to save config".

The restore function performs several actions:

1. resets the PoE chip
2. (supposedly) re-initializes the PoE chip according to the driver init defaults

What this command should do is

1. (optionally) reset the PoE chip
2. apply driver init defaults.
3. load a persistent config of my choice

When I run the restore command, it immediately complains that it cannot load the persistent config. This implies that persistent config is either not applied, or not applied consistently.
Given that poed automatically overwrites the persistent config at regular intervals, this effectively means that "restore" leaves the PoE system in an unknown/inconsistent state