This series' stream identification post showed how EthSwt identifies frames as streams. This post shows what the Firewall module needs that information for — and why every API involved is still marked DRAFT in the SWS.

Every API mentioned in this post (EthSwt_ExtractStreamHandleIdx, EthSwt_GetStreamHandleIdxStatistics/GetStreamStatistics, EthSwt_SetStreamState) is explicitly marked Status: DRAFT (atp.Status=draft) in the R25-11 SWS. Keep that in mind for practical use — these interfaces may still change in future AUTOSAR releases.

Why does the firewall need the switch?

Ethernet frame inspection with per-stream filtering can be extended by the AUTOSAR Firewall module with more advanced inspection techniques such as stateful packet inspection and deep packet inspection. By the time a frame reaches the Firewall module for inspection, it has already passed pre-filtering via per-stream filtering (see the stream identification post) — but the firewall needs to know which filter rule let the frame through, in order to continue inspecting it correctly.

Extracting the StreamHandleIdentifier

Std_ReturnType EthSwt_ExtractStreamHandleIdx(
    const Eth_DataType* DataPtr,     // payload of the received frame
    uint16              LenByte,     // payload length in bytes
    uint16*             StreamHandleIdxPtr
);

The function extracts the StreamHandleIdx from the switch vendor-specific part of the network packet header. The switch fabric (see the switch fabric architecture post) adds this value to the frame by modifying the header or by appending metadata to the network packet.

The SWS explicitly states: this metadata is not standardized and depends on the switch vendor. EthSwt_ExtractStreamHandleIdx hides this vendor dependency behind a uniform API, but the underlying frame format remains vendor-specific.

Reading out statistics: the bucket concept

Many switches count how often a per-stream filtering rule matches — usually in the form of buckets, where a bucket counts matches for multiple filter rules together.

void EthSwt_GetStreamStatistics(
    uint8 SwitchIdx
);
// Result comes back asynchronously via EthIf_StreamStatisticsIndication

The flow is deliberately asynchronous: EthSwt_GetStreamStatistics only triggers the readout (note the void return type!) — the driver later delivers the result via EthIf_StreamStatisticsIndication with NumberOfBuckets and a pointer to the concatenated bucket values.

Depending on the switch type, bucket values are either reset on readout or persist. So the firewall can compute consistently regardless of the specific switch type, the SWS requires EthSwt to deliver monotonically increasing count values starting at 0 since boot — if the switch resets internally, the driver adds the accumulated values itself.

Runtime toggling of filter rules

The Firewall module can be switched by BswM into different states (different rule sets active). To keep the per-stream filter rules consistent with that, there’s EthSwt_SetStreamState:

void EthSwt_SetStreamState(
    uint8   SwitchIdx,
    uint8   StreamHandleIdx,
    boolean StreamActivityStatus   // TRUE = active, FALSE = inactive
);

Per the SWS, this function is typically called by a diagnostic application via EthIf to selectively (de)activate a configured stream filter rule — e.g. when the firewall switches to a different operating state and certain streams are no longer relevant as a result.

Summary

AspectKey takeaway

StreamHandleIdentifier

Extracted from vendor-specific frame metadata, not from a standardized header field

Statistics

Asynchronous bucket concept, monotonically increasing over the entire boot runtime

Runtime control

EthSwt_SetStreamState (de)activates individual streams to match the firewall state

Maturity

All three APIs are still marked DRAFT in R25-11