adigostin / mstp-lib Goto Github PK

i.e., from STP_StopBridge, call the enableLearning and enableForwarding callbacks for every tree of every port wherelearning and forwarding are false.

Make this explicit in the documentation of STP_StopBridge, explaining that the learning and forwarding states of a port are relevant only to STP and shouldn't be messed with while STP isn't running.

Also remove from simulator the code that restores learning and forwarding there.

(parameters)

In rcvMsgs():

if (port->rcvdInternal)
{
    ...
    for (unsigned int messageIndex = 0; messageIndex < mstiMessageCount; messageIndex++)
    {
        const MSTI_CONFIG_MESSAGE* message = &mstiMessages [messageIndex];

CrossWorks 4.0.6 uses gcc-arm-6-2017-q2-update, as described here: https://www.rowley.co.uk/crossworks/gpl_sources.htm

Implementation of StpCallback_EnableBpduTrapping and StpCallback_TransmitGetBuffer are different than for most other switches.

i.e., replace STP_OnPortEnabled with STP_OnPort_s_Enabled.

#3

How can I change the following parameters:

• Hello Time
• Forwarding Delay
• Max Age

Delete this:
"It is recommended that the application, before passing a received BPDU frame to the STP library, performs a check for malformed frames by comparing the value in the EtherType/Size field of the frame to the length of the received frame. Such malformed frames should be discarded, not passed to the STP library."

The library checks the BPDU anyway, and it is also unclear in this paragraph what the app is supposed to do with regard to short frames padded to 64 bytes.

• STP_BRIDGE::trees
• STP_BRIDGE::ports
• PORT::trees

In other implementations of RSTP that I've seen, the BPDU is only transmitted every hello time, or when there is a topology change: 1 BPDU per hello period in stable conditions.
Toying with the simulator, I have noticed that, on every hello period, 2 BPDUs are transmitted from the designated ports. Looks like one of the BPDUs received on the root port triggers the transmission of a BPDU on the designated ports, which is added to the BPDU transmitted on hello time.

This seems like unnecessary traffic. Is this intentional? Does this respect the 802.1 standard?
Thanks

or better something containing the standard name "macOperational"

When BEGIN is asserted, for example due to changing the protocol version with STP_SetStpVersion(), each state machine must enter a well-defined state and execute the "state entry" code.

Bug: if a state machine is already in that state when BEGIN is asserted, then the "state entry" code is not executed. See this comment in various state machines: // The entry block for this state has been executed already.

Fix: In RestartStateMachines(), force the state of all state machines to "undefined" (value 0) after asserting BEGIN and before running the state machines. This will cause them to always transition to the well-defined state and execute its entry code.

In 802.1Q-2018, see:
13.27.28 fdbFlush
13.27.2 ageingTime

In stp.h flush parameter is uint:

typedef void  (*STP_CALLBACK_DEBUG_STR_OUT)  (const struct STP_BRIDGE* bridge, int portIndex, int treeIndex, const char* nullTerminatedString, unsigned int stringLength, unsigned int flush);

In documentation StpCallback_DebugStrOut.html flush is bool type.

All usages inside stp_log.cpp provide true/false as flush argument

• Build simulator for Debug and launch it.
• Load attached file: 24.zip.
• Select second bridge.
• In the property grid, change StpVersion from MSTP to RSTP.
• Wait a few seconds => assertion failure dialog pops up.