Messages on wrong GSM channel

[mo-krauti]

SUMMARY
The GSMTAP output contains packets with message types on the CCCH (e.g. System Information Type 3), that cannot be sent on the CCCH.

STEPS TO REPRODUCE
Steps to reproduce the behavior:

1. Connect Samsung Galaxy S5 mini (SM-G800F) via usb
2. Run scat -t sec -L "nas,rrc" -u -i 4 -m e303
3. Look at GSMPTAP packets in wireshark

EXPECTED and ACTUAL RESULT
Expected: System Information Type 3 messages are sent on BCCH, see GSM 04.08 Section 9.1.35
Actual Result: System Information Type 3 messages report being sent on CCCH

This is only an example, there are no packets at all on any other channel from the um interface. The capture occasionaly contains a dtap packet sent on gsm abis interface.

ENVIRONMENT

• OS: Fedora Linux 43
• SCAT version: 1.4.0
• Python version: 3.14.0
• Cellular device: Samsung Galaxy S5 Mini (SM-G800F)
• Baseband type: Samsung
• DIAG method: USB

ADDITIONAL INFORMATION
I forced 2G only connection in the device settings.

[peremen]

The _parse_sdm_common_signaling of SdmCommonParser is in charge of decoding the GSM RR signaling messages. As far as I know, there is no distinction on the control channel on the GSM RR signaling message of the SDM. So if I need to mark the SIs as "BCCH" in the GSMTAP header, then I need to inspect more on the payload.

Also, when the payload type of a GSMTAP packet is Um, then it calls the gsm_a_ccch dissector regardless of the channel (see https://gitlab.com/wireshark/wireshark/-/blob/master/epan/dissectors/packet-gsmtap.c#L1390). The description CCCH may come from this dissector: I also checked another trace from OsmoBSC's GSMTAP, and for the SI3 the GSMTAP header's channel type is shown as BCCH, but the dissection result shows (CCCH) (RR) System Information Type 3.

Please parse the Um payload for the control channel information, instead of relying on what is provided. This is upstream limitation.