Unexpected KNX TP1 Control Field: Frame starts with 0xBE instead of expected 0xBC

[ct991218620]

Hello

I am analyzing KNX TP1 telegrams and noticed that some frames start with the control byte 0xBE.
According to the KNX TP1 standard, the lower bits of the control field in a standard frame should be 00, so the most common value is 0xBC

Knx-Ultimate Version
4.1.24

[Supergiovane]

Hi,
I'm checking the matter....

[Supergiovane]

Where are those “raw bytes” coming from (TP-UART/NCN5120, USB interface, KNXnet/IP tunneling/router, etc.) ?

[ct991218620]

hello, I found that those ‘raw bytes’ are actually coming from KNXnet/IP tunneling/router.

[Supergiovane]

In TP1, section 2.2.2 Control field of the KNX docs, defines the CTRL byte as follows for L_Data frames:

FT 0 r 1 p1 p0 0 0
So bits 1..0 are always 00 ⇒ a CTRL = 0xBE (…10) cannot be the control field of a valid TP1 telegram (while 0xBC can: FT=1, r=1, p1p0=11).

[ct991218620]

hello The iprouter is unable to properly forward the KNX telegrams sent from Node‑RED because it received a frame containing the byte 0xBE.

[Supergiovane]

The screenshot you sent is not a raw TP1 (on-the-wire) telegram. It’s a cEMI L_Data.ind frame, and the circled 0xBE is cEMI Control Field 1 (Ctrl1), not the TP1 “CTRL” byte.

Decoding the shown RawData:

• 29 = MessageCode L_Data.ind
• 00 = Additional Info Length
• BE = Ctrl1 (cEMI Control Field 1) → valid value in cEMI; it differs from 0xBC only by bit 0x02 (“Ack requested”)
• B0 = Ctrl2
• FF C8 = Source 15.15.200
• 09 01 = Destination 1/1/1
• 01 00 80 = NPDU = GroupValueWrite, 1-bit payload, value 0 (OFF)

So 0xBE here is perfectly normal for cEMI. If your IP router refuses to forward “because it received 0xBE”, it’s likely interpreting the wrong field as a TP1 control byte, or it has a bug/limitation.

To verify, please share the full KNXnet/IP frame (Routing 0x0530/0x0533 or Tunnelling 0x0420) or a Wireshark PCAP, not only the cEMI payload.

[ct991218620]

Sorry, it was my misunderstanding. 0xBE is indeed a cEMI‑defined byte, not the TP1 control byte.