Re: [Wireshark-dev] question on validation of a dissected string from a BASE_CUSTOM hf item

On Sun, Sep 17, 2023, 10:06 PM Guy Harris wrote: > On Sep 7, 2023, at 9:15 AM, John Dill wrote: > > > If so, perhaps what's called for is a new mechanism to provide private > *encodings*, so that the dissectors registration routine might do something > such as > > guint32 enc_frequency;

Re: [Wireshark-dev] question on validation of a dissected string from a BASE_CUSTOM hf item

On Sep 7, 2023, at 9:15 AM, John Dill wrote: > I have a question whether I can get the dissected string of the BASE_CUSTOM > header field so that I can do analysis on it and convert it to floating point > to do range analysis so I can issue an expert info if the value is valid but > out of

Re: [Wireshark-dev] question on validation of a dissected string from a BASE_CUSTOM hf item

You may have noticed "proto_tree_add_item_ret_display_string()" and perhaps found that it doesn't do what you want; it produces the display string for a default display representation and doesn't use your custom function. (Perhaps it should?) On Tue, Sep 12, 2023, 10:05 AM John Thacker wrote: >

Re: [Wireshark-dev] question on validation of a dissected string from a BASE_CUSTOM hf item

In general you don't want to do that, if your goal is to create an expert info. The string would not exist and thus the Expert Info would not show in the "Analyze -> Expert Information" dialog, or in other situations where the tree was not visible and the item was faked; you might have to

[Wireshark-dev] question on validation of a dissected string from a BASE_CUSTOM hf item

I have a question whether I can get the dissected string of the BASE_CUSTOM header field so that I can do analysis on it and convert it to floating point to do range analysis so I can issue an expert info if the value is valid but out of range. { _Receive_Frequency, {

[Wireshark-dev] Question about tvb decompressors

Hi guys, I was looking at porting from FreeRDP to wireshark the various RDP decompressors, and I've seen tvbuff_[zlib|lz77] and friends and they all seem stateless, so I was quite surprised. Does it mean that you can start decoding only the full stream, because I guess that if you take an

Re: [Wireshark-dev] Question / nit / ocd trigger

Not a why but when: https://gitlab.com/wireshark/wireshark/-/commit/5110b21fd8cba19554f0c4f7a52e96af3acf4927 typedef struct _packet_info { char *srcip; int ip_src; char *destip; int ipproto; int srcport; int destport; int iplen; int iphdrlen;} packet_info; Looks like "dest" was

Re: [Wireshark-dev] Question / nit / ocd trigger

On Mon, May 24, 2021 at 12:19 PM Graham Bloice wrote: > > > On Mon, 24 May 2021 at 16:22, Jason Cohen wrote: > >> One thing that has bothered me for years has been the TCP flags filters. >> ... >> >> Is there history, reasoning for this? Should there be some level of >> consistency? I

Re: [Wireshark-dev] Question / nit / ocd trigger

On Mon, 24 May 2021 at 16:22, Jason Cohen wrote: > One thing that has bothered me for years has been the TCP flags filters. > > The 6 primary TCP flags are: > SYN > ACK > PSH > RST > URG > FIN > > Then you get into the CWR, NS, ECE (ECN), etc... > > The filters in Wireshark all use the accepted,

[Wireshark-dev] Question / nit / ocd trigger

One thing that has bothered me for years has been the TCP flags filters. The 6 primary TCP flags are: SYN ACK PSH RST URG FIN Then you get into the CWR, NS, ECE (ECN), etc... The filters in Wireshark all use the accepted, known abbreviations save for RST and PSH. Those are spelled out as

Re: [Wireshark-dev] question regarding merge request workflow

On Wed, 11 Nov 2020 at 16:44, Robert Frohl wrote: > Hi wireshark devs, > > in my role as wireshark maintainer for openSUSE/SUSE I go a request for > SMCD(v2) protocol support. Which has a pending merge request [0]. With > the recent 3.4.0 release I suspect that the only option to fullfill this >

[Wireshark-dev] question regarding merge request workflow

Hi wireshark devs, in my role as wireshark maintainer for openSUSE/SUSE I go a request for SMCD(v2) protocol support. Which has a pending merge request [0]. With the recent 3.4.0 release I suspect that the only option to fullfill this request on short notice is a backport to 3.4. I was wondering

Re: [Wireshark-dev] Question about displaying of Sequence Number of GTP v2

On Thu, Jun 4, 2020 at 5:12 PM Дмитрий Кондратьев wrote: > Recently I discovered that the parameter Sequence Number for GTP v2 protocol > is displayed in such way: "Sequence Number: 0x00ff (16777215)" > But if you see specs then it is stated that Sequence Number is 24-bit field. > From my

Re: [Wireshark-dev] Question about displaying of Sequence Number of GTP v2

Hi, Le jeu. 4 juin 2020 à 17:11, Дмитрий Кондратьев a écrit : > Good afternoon all. > Recently I discovered that the parameter Sequence Number for GTP v2 > protocol is displayed in such way: "Sequence Number: 0x00ff (16777215)" > But if you see specs then it is stated that Sequence Number

[Wireshark-dev] Question about displaying of Sequence Number of GTP v2

Good afternoon all.Recently I discovered that the parameter Sequence Number for GTP v2 protocol is displayed in such way: "Sequence Number: 0x00ff (16777215)"But if you see specs then it is stated that Sequence Number is 24-bit field. From my perspective, it doesn't make sense to include two

[Wireshark-dev] Question about zip support

I am currently implementing import/export of profiles. As easy as the collection of the required information is, it becomes harder when it comes to zipping it. My initial intention was to just create a .zip container and use that. But it turns out zlib does not support .zip, as it only supports

Re: [Wireshark-dev] Question about dissector "enhancement" / bug

On Jun 28, 2019, at 7:11 AM, Maynard, Chris wrote: > You can find the download link by navigating from https://www.wireshark.org/ > -> Download -> More downloads and documentation can be found on the downloads > page -> Live on the Bleeding Edge: You can download source code packages and >

Re: [Wireshark-dev] Question about dissector "enhancement" / bug

Hi Jason, Indeed, not so easy to find. The roadmap[1] states the intention to have a decent snapshot of the current developments in 3.1 posted as development build on the front page at about July 18th. Thanks, Jaap [1] https://wiki.wireshark.org/Development/Roadmap

Re: [Wireshark-dev] Question about dissector "enhancement" / bug

June 28, 2019 9:36 AM > *To:* Developer support list for Wireshark > *Subject:* Re: [Wireshark-dev] Question about dissector "enhancement" / > bug > > > > >> See the automated build section, dev builds for Windows and OSX: > https://www.wireshark.org/download

Re: [Wireshark-dev] Question about dissector "enhancement" / bug

boun...@wireshark.org] On Behalf Of Jason Cohen Sent: Friday, June 28, 2019 9:36 AM To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] Question about dissector "enhancement" / bug >> See the automated build section, dev builds for Windows and OSX: >> h

Re: [Wireshark-dev] Question about dissector "enhancement" / bug

>> See the automated build section, dev builds for Windows and OSX: https://www.wireshark.org/download/automated/. >> These builds are produced when a merge is made to the appropriate master branch. The point wasn't for me. ;) it was for the thousands+ of users that depend on wireshark to

Re: [Wireshark-dev] Question about dissector "enhancement" / bug

On Fri, 28 Jun 2019 at 13:49, Jason Cohen wrote: > All fair points. I won't push any further. > > >> My pulled from the air guess is the set of users that need these > incremental dissector\protocol changes is much smaller than the entire set > of users, and their needs are served by the

Re: [Wireshark-dev] Question about dissector "enhancement" / bug

All fair points. I won't push any further. >> My pulled from the air guess is the set of users that need these incremental dissector\protocol changes is much smaller than the entire set of users, and their needs are served by the development branch. Yes, the set of users is much smaller than

Re: [Wireshark-dev] Question about dissector "enhancement" / bug

On Fri, 28 Jun 2019 at 06:50, Pascal Quantin wrote: > Hi, > > Le ven. 28 juin 2019 à 06:06, Anders Broman a > écrit : > >> >> >> Den fre 28 juni 2019 00:44Jason Cohen skrev: >> >>> The question about about weather or not adding dissection of additional >>> information in a dissector is an

Re: [Wireshark-dev] Question about dissector "enhancement" / bug

Hi, Le ven. 28 juin 2019 à 06:06, Anders Broman a écrit : > > > Den fre 28 juni 2019 00:44Jason Cohen skrev: > >> The question about about weather or not adding dissection of additional >> information in a dissector is an enhancement or a bug; I think this is kind >> of a grey area. If a

Re: [Wireshark-dev] Question about dissector "enhancement" / bug

Den fre 28 juni 2019 00:44Jason Cohen skrev: > The question about about weather or not adding dissection of additional > information in a dissector is an enhancement or a bug; I think this is kind > of a grey area. If a dissector doesn't completely dissect a header, would > a patch that

[Wireshark-dev] Question about dissector "enhancement" / bug

The question about about weather or not adding dissection of additional information in a dissector is an enhancement or a bug; I think this is kind of a grey area. If a dissector doesn't completely dissect a header, would a patch that completes it be considered fixing it? Does it switch between

Re: [Wireshark-dev] Question about asn2wrs

need this information available between different reassembled > payload, you should use the conversation. > > -- Darien > > *Sent:* Friday, November 09, 2018 at 5:37 PM > *From:* "Pascal Quantin" > *To:* "Developer support list for Wireshark" > *Subje

Re: [Wireshark-dev] Question about asn2wrs

er support list for Wireshark" Subject: Re: [Wireshark-dev] Question about asn2wrs   Le ven. 9 nov. 2018 à 16:27, Craig Jackson <cejackso...@gmail.com> a écrit : I think I figured out my path for this particular case. I can remember the current attribute set, and then use custom

Re: [Wireshark-dev] Question about asn2wrs

Le ven. 9 nov. 2018 à 16:27, Craig Jackson a écrit : > I think I figured out my path for this particular case. I can remember the > current attribute set, and then use custom functions for the display of > AttributeElement/attributeType and AttributeElement/attributeValue/numeric. > (I'll handle

Re: [Wireshark-dev] Question about asn2wrs

I think I figured out my path for this particular case. I can remember the current attribute set, and then use custom functions for the display of AttributeElement/attributeType and AttributeElement/attributeValue/numeric. (I'll handle the other choice later.) Now to choose where to store the

Re: [Wireshark-dev] Question about asn2wrs

Hi Craig, Le jeu. 8 nov. 2018 à 19:44, Craig Jackson a écrit : > I'm working on a decoder for the NISO Z39.50 protocol. This is an > ASN.1/BER protocol used in the library automation community. > > There some things I'm having trouble figuring out how to configure, and > there are also a bunch

[Wireshark-dev] Question about asn2wrs

I'm working on a decoder for the NISO Z39.50 protocol. This is an ASN.1/BER protocol used in the library automation community. There some things I'm having trouble figuring out how to configure, and there are also a bunch of things which have never been documented in asn2wrs. I'm wondering if one

Re: [Wireshark-dev] Question about building WSDG

On 4/10/18 3:35 PM, Graham Bloice wrote: > > > On 10 April 2018 at 01:30, Craig Jackson > wrote: > > I'm trying to submit some edits to the WSDG. I'm testing them against > the HTML version. > > If I change on of the source

Re: [Wireshark-dev] Question about building WSDG

On 10 April 2018 at 01:30, Craig Jackson wrote: > I'm trying to submit some edits to the WSDG. I'm testing them against the > HTML version. > > If I change on of the source asciidocs and execute: > > C:\development\wsbuild64>*msbuild docbook\developer_guide_html.vcxproj* >

Re: [Wireshark-dev] Question about building WSDG

> On 10 Apr 2018, at 02:30, Craig Jackson wrote: > > I'm still learning Cmake, msbuild, and vcxproj files, but this seems like a > bug. Would entering a bug be appropriate? Entering a bug is always(*) appropriate. (*) only when it’s not, but that is when it concerns

[Wireshark-dev] Question about building WSDG

I'm trying to submit some edits to the WSDG. I'm testing them against the HTML version. If I change on of the source asciidocs and execute: C:\development\wsbuild64>*msbuild docbook\developer_guide_html.vcxproj* Only developer-guide.xml gets rebuilt. If I make another change to the same file

Re: [Wireshark-dev] Question for LUA dissection

On Wed, Feb 07, 2018 at 07:40:52PM +0100, Roland Knall wrote: > On Wed, Feb 7, 2018 at 7:32 PM, Peter Wu wrote: > > > Hey Roland, > > > > > > The problem with dissect_tcp_pdus (and desegment_offset/desegment_len) > > is that it prevents the dissection from displaying until

Re: [Wireshark-dev] Question for LUA dissection

On Wed, Feb 7, 2018 at 7:32 PM, Peter Wu wrote: > Hey Roland, > > > The problem with dissect_tcp_pdus (and desegment_offset/desegment_len) > is that it prevents the dissection from displaying until everything is > available. > > In C, the reassembly API (epan/reassemble.h)

Re: [Wireshark-dev] Question for LUA dissection

Hey Roland, [moved quote downwards for context] On Wed, Feb 07, 2018 at 03:59:52PM +0100, Roland Knall wrote: > On Wed, Feb 7, 2018 at 3:57 PM, Jeff Morriss > wrote: > > > On Wed, Feb 7, 2018 at 9:38 AM, Roland Knall wrote: > > > >> Hi > >> > >>

Re: [Wireshark-dev] Question for LUA dissection

Yeah, the issue is, that the result of dissect_tcp_pdus is segmented, and I need to desegment on top of that. In C I would face the same issue, and there I would move to taps, as I do not need the info live I'll take a look at the threads though, thanks cheers On Wed, Feb 7, 2018 at 3:57 PM,

Re: [Wireshark-dev] Question for LUA dissection

On Wed, Feb 7, 2018 at 9:38 AM, Roland Knall wrote: > Hi > > Just a short question. > > I have a protocol, which transports information via TCP. Now we have a > segmented download via this protocol, which in turn is a TCP segmented > transfer. > > I can desegment_tcp_pdus, and

[Wireshark-dev] Question for LUA dissection

Hi Just a short question. I have a protocol, which transports information via TCP. Now we have a segmented download via this protocol, which in turn is a TCP segmented transfer. I can desegment_tcp_pdus, and end up with a couple of messages with the bigger blocks, which I now need to desegment

Re: [Wireshark-dev] Question about git style

OK On Thu, Jan 18, 2018 at 7:09 PM, Jaap Keuter wrote: > On 07-01-18 22:36, Dario Lombardo wrote: > > If I'm not mistaken, that is not requested. A draft change in gerrit is > a change > > sent to the special branch refs/drafts/master. This is a real draft, that > >

Re: [Wireshark-dev] Question about git style

I'm a dead-tree person when I'm learning things. I do use git-scm.org, but I find the older O'Reilly a little easier to understand. Craig On Jan 18, 2018 1:07 PM, "Jaap Keuter" wrote: > On 02-01-18 17:36, Craig Jackson wrote: > > > > The moral of the story is Read The

Re: [Wireshark-dev] Question about git style

On 07-01-18 22:36, Dario Lombardo wrote: > If I'm not mistaken, that is not requested. A draft change in gerrit is a > change > sent to the special branch refs/drafts/master. This is a real draft, that > differs from a regular change for the fact that it's not visible to others, > until it gets

Re: [Wireshark-dev] Question about git style

On 02-01-18 17:36, Craig Jackson wrote: > > The moral of the story is Read The O'Reilly Book. (RTORB?) And then read it > again . . . In fact read https://git-scm.com/book/en/v2 and this entertaining/geeky video tutorial "Git For Ages 4 And Up" by Michael Schwern

Re: [Wireshark-dev] Question about git style

On Tue, Jan 2, 2018 at 11:21 AM, Jaap Keuter wrote: > Hi, > > It seems that you’re no stranger to version control systems (VCS), but new > to git. I think it's important in this case to recognise that git is a > distributed VCS. That means that you have (a clone of) a

Re: [Wireshark-dev] Question about git style

You're correct. I've been using source code control systems since the days of punched cards and tape. (I even wrote a clone of SCCS in Burroughs ALGOL once, for my own edification.) However, I only have a reading knowledge of git. It looks like I have two options when working with gerrit: -

Re: [Wireshark-dev] Question about git style

Hi, It seems that you’re no stranger to version control systems (VCS), but new to git. I think it's important in this case to recognise that git is a distributed VCS. That means that you have (a clone of) a repository on your own, and gerrit is an online tool on the origin repository. You can

Re: [Wireshark-dev] Question about git style

You can do both. In all fairness, we do not enforce a particular working style with Wireshark, but please keep in mind, that other people must review the stuff. That being said, it usually goes with - it should compile and work - after commit. So submitting things, where you and up with a broken

[Wireshark-dev] Question about git style

I'm curious whether each submission to gerrit must be a single commit. I'm accustomed with other source management systems to making a branch and then committing fairly frequently. I would do intermediate commits before I had anything complete enough to be added to the mainline code of what I was

[Wireshark-dev] question about storing data

Hi I'm trying to create a dissector that filters a retransmission packet by comparing DSN. Retransmission packets have the same data sequence number as the original packet, so I want to store the DSN and compare if there is the same DSN. Where could I store the values of DSN? How do I create the

Re: [Wireshark-dev] Question about pcap_create and HAVE_REMOTE

On Wed, Mar 29, 2017 at 04:28:24PM -0700, Guy Harris wrote: > On Mar 29, 2017, at 2:04 PM, Joerg Mayer wrote: > > > does HAVE_REMOTE imply that libpcap supports pcap_create nowadays? If so, > > it would > > allow some nice cleanups ;) > > On Windows, where we do checks at run

Re: [Wireshark-dev] Question about pcap_create and HAVE_REMOTE

On Mar 29, 2017, at 2:04 PM, Joerg Mayer wrote: > does HAVE_REMOTE imply that libpcap supports pcap_create nowadays? If so, it > would > allow some nice cleanups ;) On Windows, where we do checks at run time (as we load WinPcap dynamically) as well as compile time, older

[Wireshark-dev] Question about pcap_create and HAVE_REMOTE

[Tried to ask this on tcpdump-workers first, but the mails silently dissappeared] Hello, does HAVE_REMOTE imply that libpcap supports pcap_create nowadays? If so, it would allow some nice cleanups ;) Thanks Jörg -- Joerg Mayer We

Re: [Wireshark-dev] question about tshark output

Hi, The absence of the value simply means the value is not there, which, given the field you requested, isn’t a surprise. Try reshuffling the order of fields requested and see what happens. Thanks, Jaap > On 03 Aug 2016, at 11:14, Martin Sehnoutka wrote: > > Hi, > > I

[Wireshark-dev] question about tshark output

Hi, I have a question about tshark output. Let's say, that I have capture like this: $ tshark -r test.pcap | head --lines 5 1 0.00 7.56.29.59 → 7.39.4.46TCP 74 53996→80 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=2800540155 TSecr=0 WS=1024 2 0.0002607.39.4.46 →

Re: [Wireshark-dev] Question on payload reassembly

rk-dev-boun...@wireshark.org [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Roland Knall Sent: 28 July 2016 15:39 To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] Question on payload reassembly Hi Just a short question, does your sequence counter repeat? If so, th

Re: [Wireshark-dev] Question on payload reassembly

Hi Just a short question, does your sequence counter repeat? If so, this can be an issue. Also, for the openSAFETY dissector it only worked properly, after I implemented fragment_add_seq_offset, so it will allways count internally beginning with 0. You can see that in line 1272 of

Re: [Wireshark-dev] Question on payload reassembly

On Thu, Jul 28, 2016 at 8:35 AM, John Dunlop wrote: > Hi, > > > > Hope someone can help me with a question of payload reassembly. > > > > First up, I have been trawling the e-mail archives to find an equivalent > answer and was wondering if there is a better way of

[Wireshark-dev] Question on payload reassembly

Hi, Hope someone can help me with a question of payload reassembly. First up, I have been trawling the e-mail archives to find an equivalent answer and was wondering if there is a better way of searching the e-mail archives than opening up each individual month/year? Now my actual question is

[Wireshark-dev] Question about traffic forwarding between two adapters based on WinPcap/Npcap

Hi list, This is a help request to me about traffic forwarding between two adapters based on WinPcap/Npcap. I am stuck on an issue. There're more talented minds familiar with WinPcap here, so I hope you could help. Let me summarize the question if you don't want to see the details in the previous

Re: [Wireshark-dev] Question regarding LTE RRC dissectors

Hi I am interested to know the best practice to debug the Plugin dissectors. Regards,Viswa From: Jagadeesan, Viswanathan Sent: Wednesday, December 02, 2015 6:23 PM To: 'Pascal Quantin' Cc: Developer support list for Wireshark Subject: RE: Question regarding LTE RRC dissectors Thanks.

Re: [Wireshark-dev] Question regarding LTE RRC dissectors

2015-12-02 23:36 GMT+01:00 Jagadeesan, Viswanathan < vjaga...@qti.qualcomm.com>: > > > > > *From:* Jagadeesan, Viswanathan > *Sent:* Wednesday, December 02, 2015 5:35 PM > *To:* 'pascal.quan...@gmail.com' > *Subject:* Question regarding LTE RRC dissectors > > > > Hi > > > > followup

Re: [Wireshark-dev] Question regarding LTE RRC dissectors

Hi Pascal As know that wire shark call the RRC dissector if packet has RRC payload of MAC->RLC->PDCP, otherwise it wouldn’t invoke. We need something like Ethernet MAC + IP + UDP + LTE RRC instead of Ethernet MAC + IP + UDP + MAC +RLC + PDCP +RRC. Any suggestions.

Re: [Wireshark-dev] Question regarding LTE RRC dissectors

Thanks. Exactly we need something. I thought, we can have The approach: External plugin register for UDP port 65534 Then Call external RRC dissector. Your suggestions: External plugin register for UDP port 65534 Then Call builtin RRC dissector. I am fine with your approach, any

Re: [Wireshark-dev] Question regarding LTE RRC dissectors

From: Jagadeesan, Viswanathan Sent: Wednesday, December 02, 2015 5:35 PM To: 'pascal.quan...@gmail.com' Subject: Question regarding LTE RRC dissectors Hi followup question, it does the creation of dissector dll for RRC successfully, when it loads on wireshark , it throws a error:

Re: [Wireshark-dev] Question regarding LTE RRC dissectors

Le 3 déc. 2015 12:06 AM, "Jagadeesan, Viswanathan" < vjaga...@qti.qualcomm.com> a écrit : > > Hi Pascal > > > > As know that wire shark call the RRC dissector if packet has RRC payload of MAC->RLC->PDCP, otherwise it wouldn’t invoke. We need something like > > Ethernet MAC + IP +

[Wireshark-dev] Question about changing Npcap loopback interface's MTU to 65536

Hi list, I have updated Npcap to 0.04-r4. This version modified Npcap Loopback Adapter's MTU to 65536, so the maximum packet size is 65550 (65536 + eth_hdr_size). But I found weird result in Wireshark's Interface Details dialog. 1) Npcap Loopback Adapter: Transmit Buffer Space 1514 Receive

Re: [Wireshark-dev] Question about changing Npcap loopback interface's MTU to 65536

Hi Yang, 2015-08-21 14:46 GMT+02:00 Yang Luo hslu...@gmail.com: Hi list, I have updated Npcap to 0.04-r4. This version modified Npcap Loopback Adapter's MTU to 65536, so the maximum packet size is 65550 (65536 + eth_hdr_size). But I found weird result in Wireshark's Interface Details

[Wireshark-dev] Question about stats_tree

Hi list I was planning to have stats_tree for hpfeeds, but I have a problem and I need some suggestion from you. In hpfeeds the channel is a user-defined string that is not defined by the protocol, and that is used to share infos in a set of consumer/producer. For that I can't create a pivot table

Re: [Wireshark-dev] Question about capturing from multiple interfaces that have the same MAC Address

Sent: Monday, September 15, 2014 3:23 PM To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] Question about capturing from multiple interfaces that have the same MAC Address On Sep 15, 2014, at 11:55 AM, Herb Falk h...@sisconet.com h...@sisconet.com wrote: On Sep 15

[Wireshark-dev] Question about capturing from multiple interfaces that have the same MAC Address

There appears to be an issue with Wireshark capturing information from interfaces that have the same MAC Address. Does somebody know if this is an issue, or where the code for interface/MAC address binding is? My particular situation is a failover situation where both NICs have been

Re: [Wireshark-dev] Question about capturing from multiple interfaces that have the same MAC Address

On Sep 15, 2014, at 10:44 AM, Herb Falk h...@sisconet.com h...@sisconet.com wrote: There appears to be an issue with Wireshark capturing information from interfaces that have the same MAC Address. So what is the issue? Does capture fail to start? If so, what error is reported? Do some

Re: [Wireshark-dev] Question about capturing from multiple interfaces that have the same MAC Address

Subject: Re: [Wireshark-dev] Question about capturing from multiple interfaces that have the same MAC Address On Sep 15, 2014, at 10:44 AM, Herb Falk h...@sisconet.commailto:h...@sisconet.com h...@sisconet.commailto:h...@sisconet.com wrote: There appears to be an issue with Wireshark

Re: [Wireshark-dev] Question about capturing from multiple interfaces that have the same MAC Address

On Sep 15, 2014, at 11:55 AM, Herb Falk h...@sisconet.com h...@sisconet.com wrote: On Sep 15, 2014, at 11:14 AM, Guy Harris g...@alum.mit.edu wrote: On Sep 15, 2014, at 10:44 AM, Herb Falk h...@sisconet.com h...@sisconet.com wrote: There appears to be an issue with Wireshark capturing

Re: [Wireshark-dev] Question about capturing from multiple interfaces that have the same MAC Address

support list for Wireshark Subject: Re: [Wireshark-dev] Question about capturing from multiple interfaces that have the same MAC Address On Sep 15, 2014, at 11:55 AM, Herb Falk h...@sisconet.com h...@sisconet.com wrote: On Sep 15, 2014, at 11:14 AM, Guy Harris g...@alum.mit.edu wrote: On Sep

[Wireshark-dev] Question regarding doxygen documentation

Hello, current doxygen generation only works in the source tree. Before I work on changing that I have a few questions regarding doxygen generation in general: - Is the line CHM_FILE = wireshark-gtk.chm outdated (as there are ui docs)? - Is there a good reason to have separate doxygen projects

Re: [Wireshark-dev] Question regarding emem - wmem conversion

Thanks for your description. On Thu, Sep 12, 2013 at 11:46 PM, Joerg Mayer jma...@loplof.de wrote: Here is what I do (now) - I'm on Linux: - cd epan/dissectors/ - Pick a letter from the alphabet. - grep emem.h packet-letter*.c - ../../tools/checkAPI.pl -g emem packet-letter*.c

Re: [Wireshark-dev] Question regarding emem - wmem conversion

I'm testing a way to speed up the process, for trivial cases. This is the script I'm using. #!/bin/bash for file in `../../tools/checkAPIs.pl -g emem packet-*.c 21 | egrep ep_alloc$ | awk ' { print $6 } ' | sed 's/://g'` do echo patching $file sed -i 's/#include epan\/emem.h/#include

Re: [Wireshark-dev] Question regarding emem - wmem conversion

On Fri, Sep 13, 2013 at 10:39:08AM +0200, Dario Lombardo wrote: Thanks for your description. On Thu, Sep 12, 2013 at 11:46 PM, Joerg Mayer jma...@loplof.de wrote: Here is what I do (now) - I'm on Linux: - cd epan/dissectors/ - Pick a letter from the alphabet. - grep emem.h

Re: [Wireshark-dev] Question regarding emem - wmem conversion

I'm trying to address se_alloc() calls. If I change this: Index: packet-infiniband_sdp.c === --- packet-infiniband_sdp.c (revision 52002) +++ packet-infiniband_sdp.c (working copy) @@ -31,6 +31,7 @@ #include epan/packet.h #include

Re: [Wireshark-dev] Question regarding emem - wmem conversion

using wmem_epan_scope() it seems to work. Is it correct to use that scope? On Fri, Sep 13, 2013 at 1:55 PM, Dario Lombardo dario.lombardo...@gmail.com wrote: I'm trying to address se_alloc() calls. If I change this: Index: packet-infiniband_sdp.c

Re: [Wireshark-dev] Question regarding emem - wmem conversion

On 2013-09-13, at 7:55 AM, Dario Lombardo dario.lombardo...@gmail.com wrote: I'm trying to address se_alloc() calls. If I change this: Index: packet-infiniband_sdp.c === --- packet-infiniband_sdp.c (revision 52002) +++

Re: [Wireshark-dev] Question regarding emem - wmem conversion

I've submitted a patch with epan scope. On Fri, Sep 13, 2013 at 2:30 PM, Evan Huus eapa...@gmail.com wrote: On 2013-09-13, at 7:55 AM, Dario Lombardo dario.lombardo...@gmail.com wrote: I'm trying to address se_alloc() calls. If I change this: Index: packet-infiniband_sdp.c

Re: [Wireshark-dev] Question regarding emem - wmem conversion

Joerg Mayer jmayer@... writes: ../../tools/checkAPIs.pl -g emem packet-cdp.c packet-cdp.c: found 69 useless add_text() vs. 76 add_something else() calls (90.79%) What should be done for that? Is that related to emem? No, I just couldn't find an option to turn off the default checks,

Re: [Wireshark-dev] Question regarding emem - wmem conversion

Christopher Maynard Christopher.Maynard@... writes: Strangely and rather non-intuitively, the option is --build, as in: ../../tools/checkAPIs.pl --build -g emem packet-cdp.c (It might be a good idea to choose another name for this option and document it in the usage ... along with the

[Wireshark-dev] Question regarding emem - wmem conversion

I just looked at packet-tacacs.c. The conversion looked straight forward, the em_alloc was easy to convert. Then I noticed calls to ep_address_to_str, which is done in epan/ep_address_to_str.c Is it OK to leave that and only convert the other strings, i.e. is it OK if some of the memory is handled

Re: [Wireshark-dev] Question regarding emem - wmem conversion

On Thu, Sep 12, 2013 at 11:12 AM, Joerg Mayer jma...@loplof.de wrote: I just looked at packet-tacacs.c. The conversion looked straight forward, the em_alloc was easy to convert. Then I noticed calls to ep_address_to_str, which is done in epan/ep_address_to_str.c Is it OK to leave that and

Re: [Wireshark-dev] Question regarding emem - wmem conversion

Evan, On Thu, Sep 12, 2013 at 11:23:33AM -0400, Evan Huus wrote: The only other thing to be aware of when doing conversions is that user table callbacks (UATs) sometimes use ep_ memory, but can be called from the preferences page when no packet is being dissected, so if you convert these to

Re: [Wireshark-dev] Question regarding emem - wmem conversion

On Thu, Sep 12, 2013 at 5:36 PM, Joerg Mayer jma...@loplof.de wrote: So if we could split this between a few people at least the trivial part could be done quickly. Can you please show us what should be done? I could get a part of it if it's clear what to do. Dario.

Re: [Wireshark-dev] Question regarding emem - wmem conversion

On Thu, Sep 12, 2013 at 11:36 AM, Joerg Mayer jma...@loplof.de wrote: Evan, On Thu, Sep 12, 2013 at 11:23:33AM -0400, Evan Huus wrote: The only other thing to be aware of when doing conversions is that user table callbacks (UATs) sometimes use ep_ memory, but can be called from the

Re: [Wireshark-dev] Question regarding emem - wmem conversion

Dear Joerg and Evan, Can any of you brief me about what should be done. I would like to get involved and learn. thanks :) sincerely, Kaushik. On Thu, Sep 12, 2013 at 10:08 PM, Evan Huus eapa...@gmail.com wrote: On Thu, Sep 12, 2013 at 11:36 AM, Joerg Mayer jma...@loplof.de wrote: Evan,

Re: [Wireshark-dev] Question regarding emem - wmem conversion

Hello Kauschik, On Fri, Sep 13, 2013 at 02:53:50AM +0530, kaushik varanasi wrote: Can any of you brief me about what should be done. I would like to get involved and learn. Here is what I do (now) - I'm on Linux: - cd epan/dissectors/ - Pick a letter from the alphabet. - grep emem.h

[Wireshark-dev] Question for data argument of dissector_try_heuristic

Hi Under Mac OS X some warnings came up, and among them is a repeated warning about an unused *data parameter for every call to a heuristic dissector. As I do use the heuristic dissector, but do not use the data argument, I looked up every occurence, where dissection is passed to a heuristic

Re: [Wireshark-dev] Question for data argument of dissector_try_heuristic

On Mar 25, 2013, at 1:57 PM, Roland Knall rkn...@gmail.com wrote: Under Mac OS X some warnings came up, and among them is a repeated warning about an unused *data parameter for every call to a heuristic dissector. Or, rather, a repeated warning about an unused *data parameter in every

Re: [Wireshark-dev] Question regarding decryption of ikev1 ISAKMP messages

Hi, Did this happen? What's the bug number? Thanks Jaap On 07/23/2012 04:43 PM, Alexis La Goutte wrote: Hi, It is better to create a bug in bugtracker ( https://bugs.wireshark.org ) to no forget your problem... Regards, On Thu, Jun 28, 2012 at 5:51 PM, Susanne Goldammer

Re: [Wireshark-dev] Question regarding decryption of ikev1 ISAKMP messages

Hi, It is better to create a bug in bugtracker ( https://bugs.wireshark.org ) to no forget your problem... Regards, On Thu, Jun 28, 2012 at 5:51 PM, Susanne Goldammer susanne.goldam...@gmx.de wrote: Hi all, today i was trying to use this feature to decrypt IKEv1 messages exchanged during

[Wireshark-dev] Question regarding decryption of ikev1 ISAKMP messages

Hi all, today i was trying to use this feature to decrypt IKEv1 messages exchanged during Main Mode. Herefor i added the Initiator Cookie and the Encryption Key to the IKEv1 Decryption Table. Unfortunately this did not help. I used Wireshark version 1.8.0. A source code analysis then showed up,

  1   2   3   >