Skip to content

gatescheduling: fix: skip a link whose destination interface is not in the interface table - #1436

Open
tabgab wants to merge 1 commit into
inet-framework:masterfrom
tabgab:fix/gatescheduling-null-destination-interface
Open

tabgab wants to merge 1 commit into
inet-framework:masterfrom
tabgab:fix/gatescheduling-null-destination-interface

Conversation

@tabgab

@tabgab tabgab commented Nov 7, 2026

Copy link
Copy Markdown

Fixes #1434. On master 7ec0d4d, one commit.

A node can keep an interface outside its interface table, for example in a submodule with an interface table of its own (BridgingRouter in tests/module/lib, the Simu5G Upf). The topology has no destination interface for a link that ends at such an interface, and GateScheduleConfiguratorBase::addPorts dereferenced the null pointer.

Change

  1. addPorts: once the remote node is known, a link with no destination interface is skipped with an EV_WARN that names the local interface and the remote node. Its port stays without endNode and otherPort, exactly like the port of an unconnected interface.
  2. addFlows: the search for the output port of a flow ignores ports without an endNode, and a flow whose path needs such a link stops with
    Cannot find an output port with a connected destination interface from node 'client' to node 'extra' on the path of a flow
    
    instead of dereferencing the end iterator.

The two belong together: skipping the link in addPorts makes the dereference in addFlows reachable.

Why skip in addPorts and not stop

The link is legitimate, and the schedule of the TSN part usually does not involve it. The error is raised where it matters, for a stream whose path needs the link, and it names both nodes.

Eager and AlwaysOpen reach ports only through the paths that addFlows builds, and Z3 reads endNode and otherPort only through those paths (its loop over all ports reads the datarate only), so they are covered. TSNschedGateScheduleConfigurator reads port->endNode of every switch port (line 91), which is null for an unconnected switch port on master as well; it is not changed here.

Evidence

test (tests/module) case master with the fix
GateScheduleConfigurator_2.test link to an unregistered interface, stream elsewhere segfault (exit 139) runs to the time limit
GateScheduleConfigurator_3.test stream client -> extra over that link segfault (exit 139) exit code 1 and the message above
  • With the companion PR (guard band of a datarate-0 interface), both patches apply with git am without conflict, and the three new GateScheduleConfigurator_* tests pass together.
  • showcases/tsn/gatescheduling/eager, config Eager, runs to its time limit with the fix.
  • Release build, macOS arm64, OMNeT++ 6.5.0.

Not run: debug build; the full tests/module and fingerprint suites; Z3 and TSNsched (not built here); a real Simu5G Upf network against this INET; Linux and Windows.

…n the interface table

A node can keep an interface outside its interface table, for example
in a submodule with an interface table of its own. The topology has no
destination interface for a link that ends at such an interface, and
GateScheduleConfiguratorBase::addPorts dereferenced the null pointer.
The link is skipped and its port stays without an end node and another
port, like the port of an unconnected interface. The search of the
output port of a flow ignores such ports, and a flow whose path needs
one stops with an error that names the two nodes.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

gatescheduling: GateScheduleConfiguratorBase::addPorts dereferences a null destination interface (SIGSEGV)

1 participant