[Anders Broman <a.broman58@xxxxxxxxx>]

Hi,

Perhaps pcap-ng can be expanded to hold the metadata or the exported pdu dlt.

Best regards 

Anders

Den mån 29 sep. 2025 08:03wireshark via Wireshark-dev <wireshark-dev@xxxxxxxxxxxxx> skrev:

Hi Jaap,


Your first remark is exactly why i started this topic. My case could be exotic, but there might also be other use cases i'm not aware of. If we're going to decide to make changes, whichever direction it goes, it's going to take more time and experience than i have on my own. If there is interest in such changes, i'm able to contribute quite some time, if there's no interest it's up to me to find other solutions for my use case and that's fine too.

Next to my own use case i also see chances to improve analysis on other protocols like the ones that also do aggregation, but tunneling protocols might also benefit if the inner protocols are considered separate from the outer protocols.


For your second remark, we already have tools to convert our files to pcap's as a workaround for some problems. The problem is that the frames contain a huge amount of metadata which is lost in such a conversion. Given the current state, finding where a converted frame was in the original file (to re-gain the metadata) is quite challenging.

Best regards,
Wesley
________________________________
From: Jaap Keuter <jaap.keuter@xxxxxxxxx>
Sent: Saturday, September 27, 2025 11:43:15 AM
To: wireshark; Wireshark Deverloper Mailinglist
Subject: Re: [Wireshark-dev] Multiple packets per frame

Let op: Deze e-mail is van een externe afzender. Klik alleen op links en open bijlagen als je de afzender vertrouwt.


Hi Wesley,

So, we’re discussing reworking the whole of the core of Wireshark, to support a proprietary use case at this time. That is not to say that this is an interesting avenue to explore (I’ve got some other ideas about this too), but these changes are going to be invasive. I.e. the dissection engine, the tapping system doing the analysis, the filter system, the GUI which depends heavily on the packet list. On the other hand I think the more common use case is that of capturing on multiple interfaces at the same time, since that is the pcapng use case. So if anything, it should support that. All in all I think this is going to be time consuming, to say the least, and difficult to get right.

Why not take a different approach to this challenge? You say that these files aren’t pcap files and have some private file handler. Apparently, from this file format and/or file handler it does become clear what the various blocks in the frames are. So why not pre-process these proprietary format files into proper pcapng files first and then load these into Wireshark? This 1) keeps all your information about the files/format etc. private, and 2) allows for the use of Wireshark as is Right Now.

Thanks,
Jaap


> On 25 Sep 2025, at 10:50, wireshark via Wireshark-dev <wireshark-dev@xxxxxxxxxxxxx> wrote:
>
> Hi,
>
>
> Thanks for being open to discuss this issue. I fully understand that not being able to share makes things difficult, but i hope we can find a way around that.
>
>
> One idea i had is to implement the concept of subframes. This could be done by extending the packet_info struct with an array of pointers to packet_info struct's. In this way you could still pass it to dissectors, and dissectors could choose to add new subframes to the structure. This might have the least impact on all existing dissectors since they do not have to be aware of this.
>
> GUI-wise this could be displayed as "frame 1.1" (for frame 1, subframe 1) or as a tree like the
>
> packet details pane.
>
> Filters and other analysis would have to be altered to walk this tree of packets instead of a flat list.
>
>
> @Eugene:
>
> Part of the problem is that the files aren't pcaps, hence the private file handler. The packet details pane is mostly quite useful and correct. RTP analysis shows the most problems so i'll use that as an example.
>
> Image one frame containing 100 IP packets carrying RTP data for both directions of a call. Part of the RTP analysis uses timestamps to calculate things like throughput, jitter, etc. But since the analysis uses the frame timestamp it thinks all RTP packets arrived within the same microsecond, which of course messes up the complete analysis. This also confuses the player when it tries to reassemble the audio stream.
>
> Also, because the packet_info struct only contains one set of IP addresses, it mixes up both directions because all packets seem to have the same source and destination.
>
> I'll have to ask what i can do with screenshots, that could take some time.
>
>
> @Roland:
>
> I've checked the openSAFETY dissector and the example pcaps on the wiki, but i don't see something that looks like the issue i'm having. Maybe i'm not looking at the right place, the examples contain quite some frames. Is there a specific frame you are referring to?
>
> In the list archives i found a pcap with 802.11n traffic, this comes quite close to my case:
>
> https://lists.wireshark.org/archives/wireshark-dev/201704/msg00183.html
>
> Frame 3 shows the agreggation, especially the "IEEE 802.11 Aggregate MSDU" section. Also note what it does to the "Protocols in frame" field, which is technically correct but maybe not the most useful way to display it.
>
>
> Best regards,
>
> Wesley
>
> ________________________________
> From: Jaap Keuter <jaap.keuter@xxxxxxxxx>
> Sent: Wednesday, September 24, 2025 9:14:48 AM
> To: wireshark-dev@xxxxxxxxxxxxx
> Cc: wireshark; wireshark-dev@xxxxxxxxxxxxx
> Subject: Re: [Wireshark-dev] Re: Multiple packets per frame
>
>
> Let op: Deze e-mail is van een externe afzender. Klik alleen op links en open bijlagen als je de afzender vertrouwt.
>
>
> Hi,
>
> I think you are referring to this one:
> https://lists.wireshark.org/archives/wireshark-dev/201710/msg00000.html
>
> Send from my iPhone
>
> On 23 Sep 2025, at 21:20, Roland Knall <rknall@xxxxxxxxx> wrote:
>
> 
> Hi Eugene
>
> A very similar example for this is the way the openSAFETY dissector works. For that there are examples in the wireshark trace repository. Also, if you search through Wireshark-dev, there was a discussion ages ago between Evan Huus and myself and I also think Guy Harris, about what would be needed from a pure epan pov to achieve such a thing. (for instance, how would you handle duplicate information for the sub packages so that our other stuff like filters would still work correctly).
>
> I am all for pursuing that idea again.
>
> cheers
>
> Am Di., 23. Sept. 2025 um 21:11 Uhr schrieb Eugène Adell <eugene.adell@xxxxxxxxx<mailto:eugene.adell@xxxxxxxxx>>:
> Hi Wesley,
>
> thanks for talking about this very particular use case. I understand
> you cannot share any PCAP, even anonymized, which makes things
> difficult to solve. Do you think that would be possible to share a
> screenshot of the GUI, particularly of the Packet Details panel where
> we can see how things are interpreted and rendered ? Even if some
> parts are blurred or masked intentionally , that would help a lot.
>
> best regards
> E.A.
>
> Le lun. 22 sept. 2025 à 14:13, wireshark via Wireshark-dev
> <wireshark-dev@xxxxxxxxxxxxx<mailto:wireshark-dev@xxxxxxxxxxxxx>> a écrit :
>>
>> Hi All,
>>
>> I work for the Netherlands Forensic Institute (NFI, https://nfi.nl/ ) where i maintain a wireshark fork for internal use with a custom dissector and file handler. Unfortunately i'm not allowed to share this code or a capture.
>>
>> We have a (special?) use case where each frame can contain a high number of IP packets, i've even seen up to 100's in one frame. Those packets may be related (same sender/receiver or reverse, same service), but don't need to be. For most things dissection works as expected. Especially in cases where analysis spans multiple packets this breaks, sometimes in minor ways, sometimes with an unusable result. The cause of this seems to be that on quite some places there is the assumption that 1 frame == 1 IP packet. So far I found two places where this is visible:
>> 1) The packet_info struct is used per frame and can only hold one set of source/destination addresses and ports. In cases where more IP headers are available, the values of the last header that is analyzed will be the one that remain, the others are lost (at least in packet_info, not in the dissection tree of course).
>> 2) When referring to other packets (like pairing a request and response or stream analysis) this is done by frame number only. Of course this is ambiguous when a frame holds 10's or 100's of packets.
>> Because of this we run into multiple problems. TCP, QUIC and RTP are the first ones that come to mind. For some a workaround is a possible (like disabling TCP sequence number analysis), but others run into so much problems there is not much i can do to improve it.
>>
>> As far as i can see similar issues can also arise with dissectors available in public code. For example 802.11n and G.hn allow frame aggregation, although a bit more constrained than my case. For example 802.11n only allows aggregation of frames for the same destination MAC address. This might make it less visible, but it seems to be there none the less.
>>
>> I'd like to know if there is any interest to structurally solve these issues by removing this 1 frame == 1 IP packet assumption. As far as i can see that has quite some impact on wireshark, so that's probably something i'll need help with. But most important: Is there any interest to merge such changes?
>>
>> Best regards,
>> Wesley
>> ________________________________
>> Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten.
>>
>> Ministerie van Justitie en Veiligheid
>>
>> This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.
>>
>> Ministry of Justice and Security
>>
>> _______________________________________________
>> Wireshark-dev mailing list -- wireshark-dev@xxxxxxxxxxxxx<mailto:wireshark-dev@xxxxxxxxxxxxx>
>> To unsubscribe send an email to wireshark-dev-leave@xxxxxxxxxxxxx<mailto:wireshark-dev-leave@xxxxxxxxxxxxx>
> _______________________________________________
> Wireshark-dev mailing list -- wireshark-dev@xxxxxxxxxxxxx<mailto:wireshark-dev@xxxxxxxxxxxxx>
> To unsubscribe send an email to wireshark-dev-leave@xxxxxxxxxxxxx<mailto:wireshark-dev-leave@xxxxxxxxxxxxx>
> _______________________________________________
> Wireshark-dev mailing list -- wireshark-dev@xxxxxxxxxxxxx
> To unsubscribe send an email to wireshark-dev-leave@xxxxxxxxxxxxx
>
> ________________________________
> Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten.
>
> Ministerie van Justitie en Veiligheid
>
> This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.
>
> Ministry of Justice and Security
> _______________________________________________
> Wireshark-dev mailing list -- wireshark-dev@xxxxxxxxxxxxx
> To unsubscribe send an email to wireshark-dev-leave@xxxxxxxxxxxxx


________________________________
Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten.

Ministerie van Justitie en Veiligheid

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.

Ministry of Justice and Security
_______________________________________________
Wireshark-dev mailing list -- wireshark-dev@xxxxxxxxxxxxx
To unsubscribe send an email to wireshark-dev-leave@xxxxxxxxxxxxx