MartinM's profile - activity

I am curious about the changes you need to make. I made it call the ORAN FH CUS dissector for the message types it hand

I am curious about the whatever changes you need to make. I made it call the ORAN FH CUS dissector for the message type

I have a draft change (https://gitlab.com/wireshark/wireshark/-/merge_requests/14947) to create a built-in/C dissector

If you can let me have a capture file, I will add support (I am the main author of packet-oran.c). Maybe add an issue a

If you can let me have a capture file, I will add support. Maybe add an issue at https://gitlab.com/wireshark/wireshark

If you can let me have a capture file, I will add support.

As per my comment above, this was supported/fixed in master and will be available in 4.1 development builds, and in rele

I attempted to fix this with https://gitlab.com/wireshark/wireshark/-/merge_requests/11871 around a week ago. Could you

Assuming that it is, here is the relevant function from epan/dissectors/packet-oran.c /* Special case for uncompressed/

Assuming that it is, here is the relevant function from epan/dissectors/packet-oran.c /* Special case for uncompressed/

Assuming that it is, here is the relevant function from epan/dissectors/packet-oran.c /* Special case for uncompressed/

You are talking about ORAN FH-CUS?

You are talking about ORAN FH-CUS?

As Chuck says, we should do better to explain why integrity isn't checked in this case. Also note that even with Zuc o

Could you make available a PCAP with the relevant RTCP frames?

In order for the mac-nr dissector to know how to dissect a DRB lcid, it needs to know how the mode, SN length and drb n

In order for the mac-nr dissector to know how to dissect a DRB lcid, it needs to know how the mode, SN length and drb n

I am working on adding v2.0 now.

I am working on adding v2.0 now.

This is just the way they are defined in the ASN1. I didn't look up the first one, but for the 2nd one (defined in 38.3

This is just the way they are defined in the RRC. I didn't look up the first one, but for the 2nd one (defined in 38.33

You can decrypt them if they are framed inside pdcp-nr. You need this in order to have a UE Identifier (in order to loo

I like this one's brevity, lack of repetition, and that it doesn't refer to what sounds like a formal management group (

There is no way to automatically/reliably convert a snort rule directly into a Wireshark display filter. But with the S

Wireshark can't open any Snort alert output format. Is there a format that contains full frames? https://gitlab.com/wi

You need to set the MAC-LTE dissector preferences appropriately. If all of the relevant RRC signalling is in the captur

It also needs to be clear (if it isn't already) if the scaling factor was forced by the preference setting 'Scaling fact

One way to look at this (under linux at least) would be to use the Snort post-dissector (https://wiki.wireshark.org/Snor

It looks like you need to go to Analyze | Enabled Protocols, find PDCP-LTE, expand it and check pdcp_lte_udp. It is heu

If you have messages in your traces that describe the SPI/keys, you could write a dissector for those messages and call

You could disable the preference 'Track status of SRs within UEs', which is on by default. The SR/grant tracking was us

You could disable the preference 'Track status of SRs within UEs', which is on by default.

I have uploaded and merged https://code.wireshark.org/review/#/c/28854/ Could you either try it, or send me a capture f

Updated/fixed after a comment from Pascal. The other thing to bear in mind about the SR event in the dissector, is that

I have uploaded https://code.wireshark.org/review/#/c/28854/ Could you either try it, or send me a capture file? The fo

I have uploaded https://code.wireshark.org/review/#/c/28854/ Could you either try it, or send me a capture file? The fo

I will try to add it before then.