CommunicationControl (0x28)
UDS CommunicationControl (0x28) enables or disables normal and network messages on an ECU. The sub-functions, request and response bytes and what to validate.
Updated This page as Markdown
In short
CommunicationControl (0x28) switches an ECU normal and network communication on or off, usually to silence the bus during flashing. The sub-function selects the control type, for example disableRxAndTx (03), and a communicationType byte selects which messages. The request 28 03 01 disables normal messages, the positive response 68 03 confirms it. It needs the extended session and the state must be dropped on session end or reset.
What is CommunicationControl (0x28)?
CommunicationControl turns an ECU normal (application) and network-management communication on or off. The sub-function byte selects the control type, and a communicationType byte selects which messages the control applies to.
A normal exchange:
| Direction | Bytes | Meaning |
|---|---|---|
| Request | 28 03 01 | disableRxAndTx, normal communication |
| Positive response | 68 03 | control accepted |
| Negative response | 7F 28 7F | serviceNotSupportedInActiveSession |
Other typical negative responses are 7F 28 12 (subFunctionNotSupported for an unknown control type), 7F 28 13 (incorrectMessageLengthOrInvalidFormat, missing communicationType), 7F 28 31 (requestOutOfRange, unsupported communicationType) and 7F 28 22 (conditionsNotCorrect).
Where is it defined?
ISO 14229-1:2020 defines CommunicationControl (0x28) in the Diagnostic and communication management functional unit. The standard lists the control-type sub-functions, the communicationType parameter with its message-type and subnet fields, and the rule that the service is session-dependent. Because it changes which messages the ECU sends and receives, it is tied to the session and, on return to the default session or after a reset, normal communication is restored. The transport on CAN is ISO 15765-2.
What it means in practice
CommunicationControl is a flashing helper, not an everyday read service, and it belongs in the extended or programming session. In validation, engineers check:
- the service answers only in the intended session and gives NRC 0x7F in the default session;
- an unknown control type gives NRC 0x12 and an unsupported communicationType gives NRC 0x31;
- a missing communicationType byte gives NRC 0x13;
- normal communication is restored on session timeout, session change and reset.
The security-relevant failure is an ECU that stays silent after the tester disconnects. We regularly see ECUs that keep CommunicationControl disabling normal traffic because the S3 timeout or reset does not restore it, which can take a function off the bus until a power cycle.
How AutoST tests it
AutoST flags CommunicationControl during enumeration as a risky service, records in which sessions it answers and with which negative response codes, and checks that normal communication returns after the session ends. Because it changes bus behaviour, AutoST keeps the service in the risk-scored set, and the session-survival check in enumeration surfaces an ECU that does not restore communication on an S3 timeout or reset.
FAQ
Frequently asked questions
What are the control-type sub-functions?
enableRxAndTx (0x00), enableRxAndDisableTx (0x01), disableRxAndEnableTx (0x02) and disableRxAndTx (0x03). They decide whether the ECU keeps receiving, keeps transmitting, both or neither.
What does the communicationType byte select?
It picks which messages the control applies to: normal communication (application messages), network management messages, or both. The low nibble selects the message type and the high nibble can target a specific subnet.
Why disable communication at all?
During flashing or a routine, application and network-management traffic would interfere, so the tester silences it on the ECU for the duration and re-enables it afterwards. The ECU must restore normal communication on session end or reset.
Sources
- ISO 14229-1:2020 Road vehicles, Unified diagnostic services (UDS), Part 1: Application layer, Diagnostic and communication management functional unit, CommunicationControl (0x28)
- ISO 15765-2 Road vehicles, Diagnostic communication over CAN (DoCAN), Part 2: Transport protocol and network layer services
Related pages
- GlossaryUDS (Unified Diagnostic Services)UDS (ISO 14229) is the diagnostic protocol of most automotive ECUs: sessions, services, DIDs and SecurityAccess. What it defines and why it is the first attack surface.
- GlossaryDiagnostic session (DiagnosticSessionControl 0x10)UDS DiagnosticSessionControl (0x10) switches an ECU between default, extended and programming session. Bytes, timing parameters and what to validate.
- GlossaryTesterPresent (0x3E)UDS TesterPresent (0x3E) keeps a non-default session alive. Request and response bytes, the suppress bit, the S3 server timer, and the session bugs it exposes.
- PlatformKnow every door into the ECU.AutoST enumerates an ECU over UDS: diagnostic endpoints, sessions, all 255 services and readable DIDs, plus XCP/CCP discovery. Risky services are flagged automatically.
- InsightsECU reset and session handling bugs, and how to test themHow to test UDS session and reset handling: session fallback, S3 timeout, security state after reset, TesterPresent keeping a session alive, and what each result means.
- Free toolsUDS Negative Response Code DecoderDecode a UDS negative response in a second: paste 7F 27 35 or a bare code and get the ISO 14229 name, the rejected service and what it means on the bench. Full NRC table.
