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 < [email protected]> 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 <[email protected]> > 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 < > [email protected]> 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 <[email protected]> > > Sent: Wednesday, September 24, 2025 9:14:48 AM > > To: [email protected] > > Cc: wireshark; [email protected] > > 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 <[email protected]> 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 < > [email protected]<mailto:[email protected]>>: > > 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 > > <[email protected]<mailto:[email protected]>> 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 -- [email protected]<mailto: > [email protected]> > >> To unsubscribe send an email to [email protected] > <mailto:[email protected]> > > _______________________________________________ > > Wireshark-dev mailing list -- [email protected]<mailto: > [email protected]> > > To unsubscribe send an email to [email protected] > <mailto:[email protected]> > > _______________________________________________ > > Wireshark-dev mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > > > ________________________________ > > 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 -- [email protected] > > To unsubscribe send an email to [email protected] > > > ________________________________ > 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 -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ Wireshark-dev mailing list -- [email protected] To unsubscribe send an email to [email protected]
