Re: [Wireshark-dev] API to adjust view in Wireshark

https://osqa-ask.wireshark.org/questions/49220/control-wireshark-gui-by-another-application/ which points to https://osqa-ask.wireshark.org/questions/47107/go-to-packet-via-an-api/ > did you have a look at the PluginIF work done by Roland Knall and that is part of the upcoming Wireshark 2.0? From

Re: [Wireshark-dev] API to adjust view in Wireshark

On Fri, Apr 19, 2024 at 10:33 AM Jeff Klingler wrote: > Hi, > > I am building a log viewer where if a user clicks on a log event it can > show the related PCAP related to that timeframe. Is there an API where I > can send a time and date to a Wireshark API and have the viewer jump to the >

[Wireshark-dev] API to adjust view in Wireshark

Hi, I am building a log viewer where if a user clicks on a log event it can show the related PCAP related to that timeframe. Is there an API where I can send a time and date to a Wireshark API and have the viewer jump to the nearest time period? Thanks! Jeff

Re: [Wireshark-dev] Bug report: Wireshark windows ignores the space character in the "ssh remote capture" feature for "ssh server password" login credentials

Hi Could you file an issue at https://gitlab.com/wireshark/wireshark/-/issues/new ? kind regards Roland Am Mi., 17. Apr. 2024 um 17:17 Uhr schrieb Nicolo Campari < nicolo.camp...@intecs.it>: > Hi, > > Wireshark windows ignores the space character in the "ssh remote capture" > feature for "ssh

[Wireshark-dev] Bug report: Wireshark windows ignores the space character in the "ssh remote capture" feature for "ssh server password" login credentials

Hi, Wireshark windows ignores the space character in the "ssh remote capture" feature for "ssh server password" login credentials and does not save it when saving credentials. Even mixing normal ascii char and spaces does not work. I am using wireshark Version 4.2.4 (v4.2.4-0-g1fe5bce8d665) on

[Wireshark-dev] MacOS Intel builds failing

Hi, The builds has been failing for a while: https://gitlab.com/wireshark/wireshark/-/pipelines/1251569220 Found @rpath/libbcg729.0.dylib in /usr/local/lib Found @rpath/libsnappy.1.dylib in /usr/local/lib Found @rpath/libssh.4.dylib in /usr/local/lib ERROR: Cannot resolve rpath

Re: [Wireshark-dev] RPM package error on Fedora-30

On 4/5/24 17:38, John Thacker wrote: On Fri, Apr 5, 2024 at 8:06 PM Ben Greear mailto:gree...@candelatech.com>> wrote: Hello, I cloned latest wireshark today, and tried to build an RPM package on an fedora-30 system. It fails with this error below..any ideas? Fedora-36

Re: [Wireshark-dev] RPM package error on Fedora-30

On Fri, Apr 5, 2024 at 8:06 PM Ben Greear wrote: > Hello, > > I cloned latest wireshark today, and tried to build an RPM package > on an fedora-30 system. > > It fails with this error below..any ideas? > > Fedora-36 worked as expected, and F30 could build with 'make', just not > 'make

[Wireshark-dev] RPM package error on Fedora-30

Hello, I cloned latest wireshark today, and tried to build an RPM package on an fedora-30 system. It fails with this error below..any ideas? Fedora-36 worked as expected, and F30 could build with 'make', just not 'make wireshark_rpm' -- Build files have been written to:

Re: [Wireshark-dev] Advice on how to integra IEC-61850 protocol mapping onto the existing MMS dissector

Hi, Yes you can contact me privately for further discussions if you want. Best regards Anders Den tis 2 apr. 2024 kl 23:57 skrev R Massink : > Hi Anders, > > That is awesome! I must admit I was not familiar enough with the .asn and > asn2wrs decoder to see how much I could do there. Therefore

Re: [Wireshark-dev] Advice on how to integra IEC-61850 protocol mapping onto the existing MMS dissector

Hi Anders, That is awesome! I must admit I was not familiar enough with the .asn and asn2wrs decoder to see how much I could do there. Therefore most of my code was outside of that part, but your approach is much cleaner. If it's ok, I'd like to discuss directly how I can help to get more of the

Re: [Wireshark-dev] Advice on how to integra IEC-61850 protocol mapping onto the existing MMS dissector

Hi, I took a stab at integrating some of it into the MMS dissector https://gitlab.com/wireshark/wireshark/-/merge_requests/15113. As far as I understand it,this will only decode "proper IEC 61850" fields. Best regards Anders Den sön 24 mars 2024 kl 19:41 skrev R Massink : > Hello, > > I've

Re: [Wireshark-dev] Wireshark Developer's Guide feedback

On Mar 29, 2024, at 11:23 AM, Krefta, Oliver O. - US via Wireshark-dev wrote: > Section 11.6.2.5 > My understanding is that tvb:reported_length_remaining() takes an optional > parameter specifying an offset. My own testing seems to confirm this. However > the function is documented as taking

Re: [Wireshark-dev] Wireshark Developer's Guide feedback

Hi, Thank you. I've created MR 15081 to address most of these concerns. I leave to update to the text the someone more in tune with the Lua API, I'm not sure what the best way to document this polymorphic beast is. Thanks, Jaap

[Wireshark-dev] Wireshark Developer's Guide feedback

Hi, I've been using the Wireshark Developer's Guide ( https://www.wireshark.org/docs/wsdg_html/ ) as a reference for developing a dissector using the Lua API. In doing so, I noticed a few potential errors in the documentation and wanted to give feedback. Section 11.6.2.5 My understanding is

[Wireshark-dev] Wireshark 4.2.4 is now available

I'm proud to announce the release of Wireshark 4.2.4. What is Wireshark? Wireshark is the world’s most popular network protocol analyzer. It is used for troubleshooting, analysis, development and education. Wireshark is hosted by the Wireshark Foundation, a nonprofit which promotes

[Wireshark-dev] Advice on how to integra IEC-61850 protocol mapping onto the existing MMS dissector

Hello, I've created an initial version of an IEC-61850 dissector for wireshark. It is available here: https://github.com/robidev/iec61850-dissector. IEC-61850 is a mapping on top of MMS that uses a subset of MMS PDU's for its purpose; substation communication. While an MMS dissector, which

Re: [Wireshark-dev] [PATCH 0/4] Wireshark SocketCAN updates

Hi Gerald, thanks for the pointer and the excellent documentation!! That was a 10 minutes job: https://gitlab.com/wireshark/wireshark/-/merge_requests/14886 I assumed the Wireshark development process taking place on the mailing list - but GitLab is even better. Happy review ;-) Many thanks

Re: [Wireshark-dev] [PATCH 0/4] Wireshark SocketCAN updates

Thanks for your contribution! Can you submit a merge request at https://gitlab.com/wireshark/wireshark/ ? Complete documentation on contributing code to Wireshark can be found in our Developer's Guide at https://www.wireshark.org/docs/wsdg_html/#ChSrcContribute On 3/18/24 3:46 AM, Oliver

[Wireshark-dev] [PATCH] socketcan: make CAN CC/FD/XL frame handling less invasive

The different CAN frame types are defined by Linux SLL_P types in the sll_protocol field and the length of the frame. LINUX_SLL_P_CANXL: The frame length for CAN XL can be 12 + 1 to 12 + 2048 (13 .. 2060) byte. Additionally the CANXL_XLF flag has to be set. LINUX_SLL_P_CAN and LINUX_SLL_P_CANFD:

[Wireshark-dev] [PATCH 4/4] socketcan: update CAN CiA 611-1 definitions

Signed-off-by: Oliver Hartkopp --- epan/dissectors/packet-socketcan.c | 13 - epan/dissectors/packet-socketcan.h | 17 ++--- 2 files changed, 18 insertions(+), 12 deletions(-) diff --git a/epan/dissectors/packet-socketcan.c b/epan/dissectors/packet-socketcan.c index

[Wireshark-dev] [PATCH 1/4] socketcan: simplify CAN packet type detection

The different CAN frame types are defined by Linux SLL_P types in the sll_protocol field and the length of the frame. LINUX_SLL_P_CANXL: The frame length for CAN XL can be 12 + 1 to 12 + 2048 (13 .. 2060) byte. Additionally the CANXL_XLF flag has to be set. LINUX_SLL_P_CAN and LINUX_SLL_P_CANFD:

[Wireshark-dev] [PATCH 0/4] Wireshark SocketCAN updates

This patchset simplifies the CAN packet type detection as it focusses on the rules to distiguish the different CAN CC/FD/XL frames from the Linux kernel API. Additionally some more content is shown in the dissector and the CAN CiA 611-1 definitions have been cleaned up and extended by CiA.

[Wireshark-dev] [PATCH 2/4] socketcan: display CANFD_FDF and CANXL_XLF flag content

Display the officially defined bits for CAN XL and CAN FD. While CANXL_XLF is a mandatory set bit value for CAN XL frames the CANFD_FDF bit might be set based on the used Linux kernel version. So both bits present valuable content for the user. Signed-off-by: Oliver Hartkopp ---

[Wireshark-dev] [PATCH 3/4] socketcan: display len8dlc content for Classical CAN

While the Classical CAN frame can transport only 8 byte of data the 4 bit data length code (DLC) has the ability to have a value range from 0 to 15. To be able to send and receive DLC values from 9 to 15 the struct can_frame contains an additional len8dlc element which can have values from 9 to 15

[Wireshark-dev] Running test_tls13_rfc8446 manually

Hi, I'm trying to figure out why the pipline for https://gitlab.com/wireshark/wireshark/-/merge_requests/14615 fails but can't get the syntax right: C:\development\build\run\RelWithDebInfo\tshark.exe -r C:\development\wireshark\test\captures\tls13-rfc8446.pcap

Re: [Wireshark-dev] Join wireshark to fix bugs

Hi Dario, Thanks, I'll check it out! BRS Charlie Cilia M 0407 96 4211 H 02 8677 5957 On Tue, 27 Feb 2024, 03:06 Dario Lombardo, wrote: > Hi Charlie, and welcome to the community. > Are you able to compile wireshark? If not, that's where to start. You can > find anything in the wireshark

Re: [Wireshark-dev] Join wireshark to fix bugs

Hi Charlie, and welcome to the community. Are you able to compile wireshark? If not, that's where to start. You can find anything in the wireshark developer's guide. https://www.wireshark.org/docs/wsdg_html_chunked/ Once you have compiled it, I guess you would add a dissector. Read chap 9.2 to

[Wireshark-dev] Join wireshark to fix bugs

Hi Can i be added to the developers mailing list? Can you also point me in the right direction as to how i get started? Email for contact is pegasus...@gmail.com BRS Charlie Cilia M 0407 96 4211 H 02 8677 5957 ___ Sent via:

Re: [Wireshark-dev] SCTP association analysis & selection does not work correctly

On Thu, Feb 22, 2024 at 10:24 AM Cristian Constantin via Wireshark-dev < wireshark-dev@wireshark.org> wrote: > Hi, > How to figure out if a fix for an issue like the one mentioned by John > above is part of a Wireshark release? And what Wireshark release is > part of... > The Gitlab page for

Re: [Wireshark-dev] SCTP association analysis & selection does not work correctly

Hi, How to figure out if a fix for an issue like the one mentioned by John above is part of a Wireshark release? And what Wireshark release is part of... Thank you, Cristian On Sat, Dec 23, 2023 at 4:45 AM John Thacker wrote: > > On Thu, Dec 7, 2023 at 3:32 AM Cristian Constantin via

Re: [Wireshark-dev] resolving external symbol for ASN.1 plugin issue

Dear John, Thanks a lot for your reply, that was exactly the issue and really helped me get unstuck. I've got it working now by using the WS_DLL_PUBLIC. Will think of how to best move forward. Cheers! Robin On Wed, Feb 21, 2024 at 12:57 AM John Thacker wrote: > On Tue, Feb 20, 2024 at 6:09 

Re: [Wireshark-dev] resolving external symbol for ASN.1 plugin issue

On Tue, Feb 20, 2024 at 6:09 PM R Massink wrote: > Hello, > > I've been active in creating a dissector for IEC61850, which is mapped on > top of mms. There is an integrated mms dissector that I'm using as a > template, while mapping all mms names to the IEC61850 equivalent. I have > been able to

[Wireshark-dev] resolving external symbol for ASN.1 plugin issue

Hello, I've been active in creating a dissector for IEC61850, which is mapped on top of mms. There is an integrated mms dissector that I'm using as a template, while mapping all mms names to the IEC61850 equivalent. I have been able to successfully use asn2wrs.py to generate a packet dissector

Re: [Wireshark-dev] SocketCAN Support is broken in latest Wireshark-v4.3.0rc0-1430-g600de02805d0

On 15.02.24 11:43, Guy Harris wrote: On Feb 15, 2024, at 12:01 AM, Oliver Hartkopp wrote: https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=c83c22ec1493c0b7cc77327bedbd387e295872b6 How does one request that the VCID information be provided on a PF_PACKET socket

Re: [Wireshark-dev] SocketCAN Support is broken in latest Wireshark-v4.3.0rc0-1430-g600de02805d0

On 2024-02-15 01:03, Guy Harris wrote: Wireshark 4.2.3, which includes the SocketCAN changes, has just been released. Presumably, various packagers of Wireshark 4.2.x will pick it up at some point. Many thanks for the information and your support! Marc created a pull-request for Linux

Re: [Wireshark-dev] SocketCAN Support is broken in latest Wireshark-v4.3.0rc0-1430-g600de02805d0

On Feb 15, 2024, at 12:01 AM, Oliver Hartkopp wrote: > Marc created a pull-request for Linux mainline upstream (net-next) and the > CAN XL VCID support will now show up in Linux 6.9: > >

Re: [Wireshark-dev] SocketCAN Support is broken in latest Wireshark-v4.3.0rc0-1430-g600de02805d0

Wireshark 4.2.3, which includes the SocketCAN changes, has just been released. Presumably, various packagers of Wireshark 4.2.x will pick it up at some point. ___ Sent via:Wireshark-dev mailing list Archives:

[Wireshark-dev] Wireshark 4.2.3 is now available

I'm proud to announce the release of Wireshark 4.2.3. What is Wireshark? Wireshark is the world’s most popular network protocol analyzer. It is used for troubleshooting, analysis, development and education. Wireshark is hosted by the Wireshark Foundation, a nonprofit which promotes

Re: [Wireshark-dev] SocketCAN Support is broken in latest Wireshark-v4.3.0rc0-1430-g600de02805d0

Hello Guy, On 2024-02-13 01:28, Guy Harris wrote: On Feb 12, 2024, at 1:15 PM, Oliver Hartkopp wrote: Excellent! That seems to be the right approach. OK, so: fix libpcap to put the priority/VCID field in big-endian order in CAN XL frames:

Re: [Wireshark-dev] SocketCAN Support is broken in latest Wireshark-v4.3.0rc0-1430-g600de02805d0

On 2024-02-12 21:53, Guy Harris wrote: On Feb 12, 2024, at 11:09 AM, Oliver Hartkopp wrote: On 2024-02-12 18:54, Guy Harris wrote: Thus, I specified that all multi-byte fields in the CAN XL header, in LINKTYPE_CAN_SOCKETCAN packets, are little-endian (unlike the header for CAN classic

Re: [Wireshark-dev] SCTP association analysis & selection does not work correctly

Hi, I have checked the pull request and saw that it was merged into master one month ago... I shall eventually compile wireshark from master and test it with _very large_ pcaps containing lots of SCTP associations :-) I'll let you know. Thanks a lot, Cristian On Sat, Dec 23, 2023 at 4:45 AM

Re: [Wireshark-dev] SocketCAN Support is broken in latest Wireshark-v4.3.0rc0-1430-g600de02805d0

On Feb 12, 2024, at 1:15 PM, Oliver Hartkopp wrote: > Excellent! That seems to be the right approach. OK, so: fix libpcap to put the priority/VCID field in big-endian order in CAN XL frames:

[Wireshark-dev] Sorting "Number of Packets" / SCTP Associations as strings ?!...

Hi, Now, come on guys, really?? Sorting this field as strings?... OS: Ubuntu cco@DEU1145:~$ cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=22.04 DISTRIB_CODENAME=jammy DISTRIB_DESCRIPTION="Ubuntu 22.04.3 LTS" Wireshark version as shown by "About Wireshark": Version 3.6.2 (Git v3.6.2

Re: [Wireshark-dev] SocketCAN Support is broken in latest Wireshark-v4.3.0rc0-1430-g600de02805d0

On 2024-02-12 18:54, Guy Harris wrote: On Feb 12, 2024, at 4:04 AM, Oliver Hartkopp wrote: I assume only ARM(64), X64 and Risc-V architectures will get in contact with CAN XL. And all these archs are little-endian. And the version of your Lua dissector at

Re: [Wireshark-dev] SocketCAN Support is broken in latest Wireshark-v4.3.0rc0-1430-g600de02805d0

On Feb 12, 2024, at 11:09 AM, Oliver Hartkopp wrote: > On 2024-02-12 18:54, Guy Harris wrote: > >> Thus, I specified that all multi-byte fields in the CAN XL header, in >> LINKTYPE_CAN_SOCKETCAN packets, are little-endian (unlike the header for CAN >> classic and CAN FD, in which the CAN

Re: [Wireshark-dev] SocketCAN Support is broken in latest Wireshark-v4.3.0rc0-1430-g600de02805d0

On Feb 12, 2024, at 4:04 AM, Oliver Hartkopp wrote: > I assume only ARM(64), X64 and Risc-V architectures will get in contact with > CAN XL. And all these archs are little-endian. And the version of your Lua dissector at

Re: [Wireshark-dev] SocketCAN Support is broken in latest Wireshark-v4.3.0rc0-1430-g600de02805d0

On 12.02.24 10:34, Guy Harris wrote: On Feb 12, 2024, at 1:21 AM, Guy Harris wrote: How many processors - as in "number of CPUs", not "number of instruction set architectures" - capturing CANbus traffic and producing SocketCAN headers are big-endian, and how many are little-endian? To

Re: [Wireshark-dev] SocketCAN Support is broken in latest Wireshark-v4.3.0rc0-1430-g600de02805d0

Hello Guy, On 2024-02-12 08:17, Guy Harris wrote: On Feb 11, 2024, at 1:19 PM, Oliver Hartkopp wrote: Although the Priority 0x242 and the VCID 0xCD are correctly displayed in the grey line the values below that line seem to be wrong (Priority 52480, VCID 2). Fixed in Wireshark change

Re: [Wireshark-dev] SocketCAN Support is broken in latest Wireshark-v4.3.0rc0-1430-g600de02805d0

Sorry for the noise. This issue seems to be fixed in libpcap in commit e50355893cd073c0 ("socketcan: *really* fix CAN FD support.") - canhdr->fd_flags &= ~(CANFD_FDF|CANFD_ESI|CANFD_BRS); + canhdr->fd_flags &=

Re: [Wireshark-dev] SocketCAN Support is broken in latest Wireshark-v4.3.0rc0-1430-g600de02805d0

Another small issue: On 2024-02-09 23:56, Guy Harris wrote: and the Wireshark main and 4.2 branches include changes to treat CAN frames without the CANXL_XLF flag or the CANFD_FDF flag as FD frames if they're exactly 72 bytes long, to work around the (fixed in the main and 1.10

Re: [Wireshark-dev] SocketCAN Support is broken in latest Wireshark-v4.3.0rc0-1430-g600de02805d0

On Feb 12, 2024, at 1:21 AM, Guy Harris wrote: > How many processors - as in "number of CPUs", not "number of instruction set > architectures" - capturing CANbus traffic and producing SocketCAN headers are > big-endian, and how many are little-endian? To be more specific, how many processors

Re: [Wireshark-dev] SocketCAN Support is broken in latest Wireshark-v4.3.0rc0-1430-g600de02805d0

On Feb 12, 2024, at 12:07 AM, Oliver Hartkopp wrote: > I'm sorry but the fix went into the wrong direction and removed the formerly > correct values in the grey'ed line. > > In the attached screenshot you can see from the plain data > > 00 cd 02 42 81 00 0a 00 af af af af 00 00 00 00 >

Re: [Wireshark-dev] SocketCAN Support is broken in latest Wireshark-v4.3.0rc0-1430-g600de02805d0

On Feb 11, 2024, at 1:19 PM, Oliver Hartkopp wrote: > Although the Priority 0x242 and the VCID 0xCD are correctly displayed in the > grey line the values below that line seem to be wrong (Priority 52480, VCID > 2). Fixed in Wireshark change fdf4ecdb4aea61f6e557d75172d27ca0ffea79d7. (All

Re: [Wireshark-dev] SocketCAN Support is broken in latest Wireshark-v4.3.0rc0-1430-g600de02805d0

On Feb 11, 2024, at 1:19 PM, Oliver Hartkopp wrote: > Shouldn't LINUX_SLL_P_CANXL be set to 0x000E like in > include/uapi/linux/if_ether.h for ETH_P_CANXL instead of 0x000F here? Fixed in libpcap commit 6735956299c5fbc803255a14fa493886e3cf81c6.

Re: [Wireshark-dev] SocketCAN Support is broken in latest Wireshark-v4.3.0rc0-1430-g600de02805d0

On Feb 11, 2024, at 1:53 PM, Oliver Hartkopp wrote: > This issue seems to be fixed in libpcap in commit e50355893cd073c0 > ("socketcan: *really* fix CAN FD support.") > > > - canhdr->fd_flags &= > ~(CANFD_FDF|CANFD_ESI|CANFD_BRS); > +

Re: [Wireshark-dev] Input plugin for PEAK Systems CAN interfaces

On Jan 4, 2024, at 7:53 AM, Miklós Márton wrote: > The PEAK-CAN to Wireshark question came up again, and I started to work on it > based on this wonderful piece of code: > https://github.com/theXappy/ExtcapNet > > I also reached the point to figure out how to handle over the CAN messages >

Re: [Wireshark-dev] SocketCAN Support is broken in latest Wireshark-v4.3.0rc0-1430-g600de02805d0

So the libpcap main and 1.10 branches include changes to not clear the CANFD_FDF flag for FD frames; put the multi-byte fields in the CAN XL header into little-endian byte order; and the Wireshark main and 4.2 branches include changes to treat CAN frames without the

Re: [Wireshark-dev] SocketCAN Support is broken in latest Wireshark-v4.3.0rc0-1430-g600de02805d0

On Feb 6, 2024, at 1:24 PM, Guy Harris wrote: > 1) Provide a capture file that contains CAN FD frames but that isn't > correctly dissected, so we can see *why* the FD frames aren't being detected OK, I managed to create the virtual CAN device on Ubuntu 22.04, recently updated, with a

[Wireshark-dev] SocketCAN Support is broken in latest Wireshark-v4.3.0rc0-1430-g600de02805d0

Hi all, unfortunately I did not get any feedback from subscribing to this list via https://www.wireshark.org/mailman/listinfo/wireshark-dev - so I'm just sending my issue directly to the list. I'm currently working on CAN XL support which is the latest CAN protocol after Classical CAN and

Re: [Wireshark-dev] SocketCAN Support is broken in latest Wireshark-v4.3.0rc0-1430-g600de02805d0

On Feb 6, 2024, at 10:42 AM, Oliver Hartkopp wrote: > I'm currently working on CAN XL support which is the latest CAN protocol > after Classical CAN and CAN FD. > > With Wireshark 3.6 I was able to add this dissector for CAN XL >

Re: [Wireshark-dev] Is this a known problem?

Hi Richard, Yes, downgrade to 4.0.x, Windows 2012 is not supported with Qt 6 https://gitlab.com/wireshark/wireshark/-/issues/18476#note_1747847702 Next 4.2 will be check to don't install on Windows 2012 (and 8) On Thu, Feb 1, 2024 at 5:58 AM Richard Sharpe wrote: > Hi folks, > > I installed

[Wireshark-dev] Is this a known problem?

Hi folks, I installed 4.2.2 on a Windows Server 2012 system and got the following error: "The procedure entry point SystemParametersInfoForDpi could not be located in the dynamic link library ..." [image: image.png] Is there a work-around? -- Regards, Richard Sharpe

Re: [Wireshark-dev] 4GB limit for RPC dissector?

Thanks John, that was really helpful! This isn't documented and also Google search for "wireshark 4GB limit" doesn't yield anything helpful. What makes things worse is if we split capture files into say 2GB chunks wireshark/tshark cannot correctly decode the individual files also since the RPC

Re: [Wireshark-dev] 4GB limit for RPC dissector?

On Fri, Jan 26, 2024, 4:27 AM Linux Smiths wrote: > > Can someone confirm this or if anyone has used wireshark/tshark to decode > RPC streams greater than 4GB your confirmation will be helpful too. Btw > I've tried all the protocol preferences and nothing helps. > > Thanks, > LS > > It's a known

[Wireshark-dev] 4GB limit for RPC dissector?

Hello, I am trying to check for all NFS WRITE RPC requests in a packet capture that's around 27GB in size. I know that all NFS WRITEs are 1MB in size, so there should be ~27K NFS WRITE requests in the capture, but tshark (and also wireshark) give up after exactly 4095. # ls -lh merged.pcap

Re: [Wireshark-dev] Tracking branches, GitHub and Launchpad

On Sun, Dec 17, 2023 at 11:37:23PM +0100, Pascal Quantin wrote: > 17 déc. 2023 23:29:59 Guy Harris : > > > On Dec 17, 2023, at 10:08 AM, Jaap Keuter wrote: > > > >> 1. The GitHub mirror is picking up all our cherry-pick branches, which now > >> run in the hundreds. > > > > 1.5. Are

[Wireshark-dev] GitLab security announcement

Hi all, GitLab recently announced that several security flaws were recently fixed on their platform, including two critical flaws: https://about.gitlab.com/releases/2024/01/11/critical-security-release-gitlab-16-7-2-released/ The Wireshark repositories are hosted on GitLab's SaaS platform

[Wireshark-dev] Wireshark 4.2.2 is now available

I'm proud to announce the release of Wireshark 4.2.2. What is Wireshark? Wireshark is the world’s most popular network protocol analyzer. It is used for troubleshooting, analysis, development and education. Wireshark is hosted by the Wireshark Foundation, a nonprofit which promotes

Re: [Wireshark-dev] Input plugin for PEAK Systems CAN interfaces

Hello Henri, It has been a while since we last mailed, I hope you are doing fine! The PEAK-CAN to Wireshark question came up again, and I started to work on it based on this wonderful piece of code: https://github.com/theXappy/ExtcapNet I also reached the point to figure out how to handle over

[Wireshark-dev] Wireshark 4.2.1 is now available

I'm proud to announce the release of Wireshark 4.2.1. What is Wireshark? Wireshark is the world’s most popular network protocol analyzer. It is used for troubleshooting, analysis, development and education. Wireshark is hosted by the Wireshark Foundation, a nonprofit which promotes

Re: [Wireshark-dev] SCTP association analysis & selection does not work correctly

On Thu, Dec 7, 2023 at 3:32 AM Cristian Constantin via Wireshark-dev < wireshark-dev@wireshark.org> wrote: > Hi Jeff, > > Yes, after enabling the respective protocol decoding option, SCTP > association analysis works. > SCTP association analysis is _quite_ slow, though. I'll check why it > is so

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

On 21/12/23 12:43, Bálint Réczey wrote: Hi João, On 2023. Dec 21., Thu at 12:02, João Valverde wrote: On 20/12/23 23:20, Anders Broman wrote: > Hi, > To me it is a useful feature to be able to easily build .deb packages > and make repos to easily update and maintain

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

Hi Guy, Guy Harris ezt írta (időpont: 2023. dec. 21., Cs, 21:04): > > On Dec 21, 2023, at 6:51 AM, Bálint Réczey wrote: > > > I'm not sure why libvirt dissector users should be "their users". In my > > eyes they are very much our users as well since they use Wireshark extended > > with the

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

On Dec 21, 2023, at 6:51 AM, Bálint Réczey wrote: > I'm not sure why libvirt dissector users should be "their users". In my eyes > they are very much our users as well since they use Wireshark extended with > the plugin and I'm happy that they get the best service. It appears that the

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

Hi Roland, Roland Knall ezt írta (időpont: 2023. dec. 20., Sze, 20:44): > > We messed up in a sense, that we should have found an argument and final position on API compatibility. Not that it did not work out well, but it "happened" instead of being planned > > That was, what I meant with

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

Hi João, On 2023. Dec 21., Thu at 12:02, João Valverde wrote: > > On 20/12/23 23:20, Anders Broman wrote: > > Hi, > > To me it is a useful feature to be able to easily build .deb packages > > and make repos to easily update and maintain wireshark across servers. > > This is a feature I vote for

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

Den tors 21 dec. 2023 12:03João Valverde skrev: > > On 20/12/23 23:20, Anders Broman wrote: > > Hi, > > To me it is a useful feature to be able to easily build .deb packages > > and make repos to easily update and maintain wireshark across servers. > > This is a feature I vote for us to keep

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

On 20/12/23 23:20, Anders Broman wrote: Hi, To me it is a useful feature to be able to easily build .deb packages and make repos to easily update and maintain wireshark across servers. This is a feature I vote for us to keep regardless of any opinion on how Debian build their packages. Maybe

Re: [Wireshark-dev] wireshark handles SCTP association indexing wrong under some circumstances -- multi-homing is wrongly reported where there is none

On Wed, Dec 20, 2023, 4:32 PM John Thacker wrote: > > On 6 Dec 2023, at 12:08, Ariel Burbaickij >> wrote: >> > >> > Hello all, >> > >> > we have a special setup here: SS7 E1 is converted to SCTP traffic with >> the following basic schema (I cannot share capture itself, just in case): >> > --

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

Hi, To me it is a useful feature to be able to easily build .deb packages and make repos to easily update and maintain wireshark across servers. This is a feature I vote for us to keep regardless of any opinion on how Debian build their packages. Maybe a Debian mailing list is a better place to

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

On 20/12/23 22:35, Roland Knall wrote: Am 20.12.2023 um 22:43 schrieb João Valverde :  On 20/12/23 21:21, Roland Knall wrote: Am 20.12.2023 um 22:02 schrieb João Valverde :  On 20/12/23 20:52, Roland Knall wrote: So people can link to our libraries to write other projets? And

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

> Am 20.12.2023 um 22:43 schrieb João Valverde : > >  > >> On 20/12/23 21:21, Roland Knall wrote: >> Am 20.12.2023 um 22:02 schrieb João Valverde : >>> >>>  >>> On 20/12/23 20:52, Roland Knall wrote: So people can link to our libraries to write other projets?

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

On 20/12/23 21:21, Roland Knall wrote: Am 20.12.2023 um 22:02 schrieb João Valverde :  On 20/12/23 20:52, Roland Knall wrote: So people can link to our libraries to write other projets? And expect it to work reliably? That is news to me. I have made this question many times over the

Re: [Wireshark-dev] wireshark handles SCTP association indexing wrong under some circumstances -- multi-homing is wrongly reported where there is none

> > > On 6 Dec 2023, at 12:08, Ariel Burbaickij > wrote: > > > > Hello all, > > > > we have a special setup here: SS7 E1 is converted to SCTP traffic with > the following basic schema (I cannot share capture itself, just in case): > > -- there are no INITs, HEARTBEATs/ACK, SACKs, just DATA chunks

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

> Am 20.12.2023 um 22:02 schrieb João Valverde : > >  > >> On 20/12/23 20:52, Roland Knall wrote: >> >> >> Am Mi., 20. Dez. 2023 um 21:24 Uhr schrieb João Valverde : >> >> >> >>On 20/12/23 16:06, Roland Knall wrote: >>> Ok, I am not ignoring those points, as I think those points

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

On 20/12/23 20:52, Roland Knall wrote: Am Mi., 20. Dez. 2023 um 21:24 Uhr schrieb João Valverde : On 20/12/23 16:06, Roland Knall wrote: > Ok, I am not ignoring those points, as I think those points are valid. > It makes sense, that building debian packages from the

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

Am Mi., 20. Dez. 2023 um 21:24 Uhr schrieb João Valverde : > > > On 20/12/23 16:06, Roland Knall wrote: > > Ok, I am not ignoring those points, as I think those points are valid. > > It makes sense, that building debian packages from the repository > > should behave in the same way as it does

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

On 20/12/23 16:06, Roland Knall wrote: Ok, I am not ignoring those points, as I think those points are valid. It makes sense, that building debian packages from the repository should behave in the same way as it does with the overall projects. Now, one could argue, that having multiple

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

We messed up in a sense, that we should have found an argument and final position on API compatibility. Not that it did not work out well, but it "happened" instead of being planned That was, what I meant with "messed up". I read their argument and I still disagree. It might be the best for

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

Roland Knall ezt írta (időpont: 2023. dec. 20., Sze, 17:06): > > Ok, I am not ignoring those points, as I think those points are valid. It > makes sense, that building debian packages from the repository should behave > in the same way as it does with the overall projects. Now, one could argue,

Re: [Wireshark-dev] Changes to the plugin registration API

Hi Roland, Roland Knall ezt írta (időpont: 2023. dec. 4., H, 13:16): > > I do not think we need to revert the whole change. I actually like the way > the new version check is implemented and think it is beneficial to a lot of > users, because it will reduce the number of changes they have to

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

Ok, I am not ignoring those points, as I think those points are valid. It makes sense, that building debian packages from the repository should behave in the same way as it does with the overall projects. Now, one could argue, that having multiple packages could have been avoided in the beginning

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

Keep in mind I am just a user but I'm not one to skip a good technical discussion. I'm ignoring your other points on purpose, there is only so much I can handle in one sitting. On 20/12/23 13:24, Bálint Réczey wrote: Having separate packages follows Debian packaging best practices and

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

Hi Balint It would be worth amending the Readme with this information, as well as the packaging section of the wiki, to ensure this information is not getting lost and future discussions may be avoided by pointing to it. kind regards Roland Am Mi., 20. Dez. 2023 um 14:24 Uhr schrieb Bálint

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

Hi, João Valverde ezt írta (időpont: 2023. nov. 27., H, 21:42): > > > > On 27/11/23 16:26, Jeff Morriss wrote: > > On Wed, Nov 22, 2023 at 11:54 AM João Valverde wrote: > > > > > > On 22/11/23 15:37, John Thacker wrote: > >> On Wed, Nov 22, 2023 at 9:40 AM João Valverde wrote: > >> >

Re: [Wireshark-dev] Tracking branches, GitHub and Launchpad

17 déc. 2023 23:29:59 Guy Harris : > On Dec 17, 2023, at 10:08 AM, Jaap Keuter wrote: > >> 1. The GitHub mirror is picking up all our cherry-pick branches, which now >> run in the hundreds. > > 1.5. Are cherry-pick branches deleted once the changes on those branches are > merged into the

Re: [Wireshark-dev] Tracking branches, GitHub and Launchpad

On Dec 17, 2023, at 10:08 AM, Jaap Keuter wrote: > 1. The GitHub mirror is picking up all our cherry-pick branches, which now > run in the hundreds. 1.5. Are cherry-pick branches deleted once the changes on those branches are merged into the version branch and, if not, why not? Do they serve

[Wireshark-dev] Tracking branches, GitHub and Launchpad

Hi, A few observations which probably needs attention. 1. The GitHub mirror is picking up all our cherry-pick branches, which now run in the hundreds. IMHO, these should not be mirrored in the first place. How can we clean this up? 2. Launchpad upstream repo mirrors of GitHub. IMHO, it should

[Wireshark-dev] Wiki editor permission request

Hi, I would like permission to edit the Wireshark wiki. My GitLab username is . V/r; Heidi Hintenach EHM Network Team MFCC/MCCOG/MEOD Peraton, Inc Office: 816-705-5442 SIPR Email: heidi.hintenach@usmc.smil.mil 2306 E. Bannister

  1   2   3   4   5   6   7   8   9   10   >