It has been observed that a Lenovo XCC can fail to produce the
appropriate attributes in the SLP data. In such a case, and only if we
are in the preconfig path (which means it is a candidate for discovery),
reset the XCC to try to correct the behavior.
If something happens to have the right ip, but no stored certificate
because it's not discovered, it was used as a data source if the
addpolicy was lax. Harden the flow by skipping unverifiable parts
of the chain.
Also apply fixes and lay groundwork for eventual 'secure' discovery
policy. As such a policy is too limited to be practical at this point
(SMM only) the full deal is postponed until it would be feasible.
This does not actually allow config deployment, but it can help in
ascertaining access for manual access to a switch.
A proper 'handler' will come later to add configuration, probably with
an emphasis on CNOS rather than ENOS.
eval_node can establish that this is a direct discovery attempt.
In that specific context, the check can be performed. Otherwise,
we can't check in this way, but the enclosure manager should raise the
error on behalf of the rest of the situation.
The _group function was not using fixup_attribute, add that.
Additionally, on the clear_ functions, use the aliases to make clearing
work with the shorthand as well.
In various scenarios, too many macs on a port can be a sign of trouble.
For example, a chained SMM configuration with head on switch port, or
incorrectly pointing a nodes net attributes at a switch uplink port, or
defining SMMs without any nodes, causing XCCs to think they are
rackmount. This sets some sanity value for avoiding problems. This is
of course a mitigation, invalid scenarios could still run afoul of the
limits, but it should catch a large chunk of offending scenarios.
If a session is closed, also kill off any associated
relays in progress. One exception, video port relay
in ESTABLISHED is left alone due to limitation, but
at least no new open.
When serving multiple browser, limit a forwarder to only the specific
client that authorized that forwarder. Previously, one client was
allowed to access another client's forwarding port if it happened to
know the location.
While we are limited to one 'listen' target at a time, we can
qualiify by the source address to at least provide distinct
behavior depending on the client.
This prevents sockets from opening up to the world that could be used
to connect to management interfaces directly, apart from the specific
requestors.
This should be a more bulletproof place to be. Note that it used
to be here and was moved because pyghmi used to call oem_init, but
pyghmi has been changed for a long time to no longer have that
requirement.
