Re: [Wireshark-dev] Failed pipeline for nvmeof_getlog_page | wireshark | 3a8e09ef

It seems like you already know what is wrong and how to solve this. Why not just change your patch so it does not trigger this compiler error/warning? Maybe the compiler is overly sensitive here? Who knows. Why is this a problem for wireshark developers? Do this: * fix your code so it does not

Re: [Wireshark-dev] Is there a way to easily go to the next packet that satisfies a filter string without filtering the packets

Doesn't wireshark already have this? CTRL-F and then type in the filter string then click "Find" and it will cycle through the packets that are matching. On Sun, Mar 21, 2021 at 7:18 AM Richard Sharpe wrote: > > Hi folks, > > I use Wireshark a great deal in my job because I am always looking at

Re: [Wireshark-dev] [Outreachy] Internship blog 2020

Just a followup to clarify, Take [1] and [2] as good suggestions, then look at other dissectors and mimic them. We are pretty flexible and forgiving when it comes to style and as long as you mostly match what other dissectors look like no one will object. On Fri, Dec 4, 2020 at 1:28 PM ronnie

Re: [Wireshark-dev] [Outreachy] Internship blog 2020

On Fri, Dec 4, 2020 at 12:47 PM Jonathan Nieder wrote: > > Hi Joey, > > Joey Salazar wrote: > > > Very happy to be joining for this winter's internship! A short blog > > entry on the beginning of this journey here: https://jsal.home.blog/ > > > > A new entry every 2 weeks, check it out! > > > >

Re: [Wireshark-dev] Packet Diagram shows only raw bytes of a subtree instead of individual fields

On Tue, Dec 1, 2020 at 7:51 AM Gerald Combs wrote: > > On 11/26/20 11:03 AM, John Thacker wrote: > > > > On Thu, Nov 26, 2020 at 1:19 PM Maynard, Christopher via Wireshark-dev > > mailto:wireshark-dev@wireshark.org>> wrote: > > > > Many protocols contain subtrees, such as a header with

Re: [Wireshark-dev] Joint project with Git for outreachy

so whomever ends up being the intern or whatever doing it, I will be happy to help them get it going and have a successfull project that they can remember with joy and be proud of. regards ronnie sahlberg On Mon, Sep 21, 2020 at 2:17 AM Emily Shaffer wrote: > > On Sat, Sep 19, 2020 at 03:3

Re: [Wireshark-dev] Joint project with Git for outreachy

cloud file server :-) ) best regards Ronnie Sahlberg On Sat, Sep 19, 2020 at 8:21 AM Jonathan Nieder wrote: > > Hi wiresharkers, > > Outreachy <https://www.outreachy.org/> is a program similar to the > Google Summer of Code, providing internships to work on open source >

Re: [Wireshark-dev] Code of Conduct for our community

I agree, The samba one is much more comfortable. On Thu, Aug 6, 2020 at 3:07 AM Richard Sharpe wrote: > > On Wed, Aug 5, 2020 at 8:49 AM Uli Heilmeier wrote: > > > > All, > > > > As discussed in the last Remote Developer Den meeting I see a Code of > > Conduct (CoC) as helpful for our

Re: [Wireshark-dev] Bzip2 support

On Thu, Jun 27, 2019 at 7:17 AM Guy Harris wrote: > > On Jun 26, 2019, at 2:03 PM, Jaap Keuter wrote: > > > On 26 Jun 2019, at 19:41, Guy Harris wrote: > > > >> It could probably be done (note that for decompressing capture files that > >> would require the ability to do random access I/O, > >

Re: [Wireshark-dev] Something that would be useful in Wireshark when dealing with dropped packets

That is a really good idea, but instead of you having to manually search for where the next pdu starts, it would be possible to teach wireshark to do this automatically. We already track the PDU boundaries for SMB as well as a bunch other protocols so we know where a pdu starts/stops, most of the

Re: [Wireshark-dev] [pcap-ng-format] Proposal for storing decryption secrets in a pcapng block

What Guy said. On Fri, Oct 5, 2018 at 4:11 PM Guy Harris wrote: > > On Sep 30, 2018, at 10:47 AM, Peter Wu wrote: > > > Requirements for block placement: > > - No requirement. Producers are allowed to write the block anywhere. > > Disadvantages for consumers: requires a two-pass scan to collect

Re: [Wireshark-dev] compilation problem

Add "-I.." to your compiler flags. On Tue, Sep 12, 2017 at 7:12 PM, Sadik Sikder wrote: > Hello all > i am trying to compile a file like packet-ssl-utils.c. the compilation > command is below > > ssikder@ssikder:~/Desktop/wireshark_source_code/epan/dissectors$ gcc -o foo

Re: [Wireshark-dev] Wireshark may get ISN wrong

You can just disable relative sequence numbers in the preferences for tcp. On Mon, Nov 17, 2014 at 9:38 AM, Matt matta...@gmail.com wrote: Hi, I use wireshark to examinate some traces generated by a network simulator (ns3 www.nsnam.org) which set the ISN to 0 (no randomization yet). As

Re: [Wireshark-dev] Conflicts: field in commit messages

My 5 cent : I think they should be removed. On Mon, Oct 6, 2014 at 12:03 PM, Bálint Réczey bal...@balintreczey.hu wrote: Hi All, I usually leave the Conflicts: ... in the commit message after resolving conflicts to document that the merge was not automatic. Should I continue doings so

Re: [Wireshark-dev] Qt License Change

I think the biggest gotcha with LGPLv3 is that it is no longer compatible with GPLv2 only code. Wireshark does not have any GPLv2only code right? If not, we should be ok. On Wed, Aug 20, 2014 at 9:31 AM, Evan Huus eapa...@gmail.com wrote:

Re: [Wireshark-dev] How can Wireshark improve

On Sat, Apr 19, 2014 at 12:48 PM, Guy Harris g...@alum.mit.edu wrote: On Apr 19, 2014, at 12:24 PM, Richard Sharpe realrichardsha...@gmail.com wrote: One think I would like to be able to do is Show me all the SMB2 requests where the smb2.flags.is_response == true smb2.nt_status !=

Re: [Wireshark-dev] Heuristic check of T.125 dissector

. If the dissector is useful to others, then if it is based on reverse engineering instead of official documentation, include it. An incomplete, reverse engineered, dissector is better than no dissector at all. ronnie sahlberg On Tue, Feb 25, 2014 at 8:51 AM, Thomas Wiens th.wi...@gmx.de wrote

Re: [Wireshark-dev] Add a capability to disable/enable a dissector table ?

sgtm On Fri, Feb 21, 2014 at 10:37 AM, Bill Meier wme...@newsguy.com wrote: It seems to me that it would be nice to be able to disable/enable specific dissector and heuristic tables. For example, this would be useful when investigating tcp level issues for which tcp payload dissection is not

Re: [Wireshark-dev] Last few license header questions

On Wed, Feb 5, 2014 at 12:54 PM, Evan Huus eapa...@gmail.com wrote: The buildbot is down to reporting only 13 files with license header problems. Let's get them cleaned up and finally have that step pass :) --- 'diameter/dictionary.dtd' 'wimaxasncp/dictionary.dtd' These two DTD files both

Re: [Wireshark-dev] snow3g dissector in violation of GPLv2+

On Wed, Jan 15, 2014 at 3:10 PM, Joerg Mayer jma...@loplof.de wrote: commit b01a99c385bc80566cff9134f93b5d4680dd5a58 Author: Martin Mathieson martin.r.mathie...@googlemail.com Date: Tue Jan 14 11:09:47 2014 + Provide hook for calling EEA1 implementation (Snow3G). Implementation

Re: [Wireshark-dev] Thoughts on disabling an old dissector

I think we should keep the dissector but either rename it to *_legacy or something like someone suggested or control it via a preference. We have similar situations for other protocols already that can be used to highlught some of the options : In iSCSI we already have a preference (that

Re: [Wireshark-dev] Idea for faster dissection on second pas

That would be a good additions, but I always tried to do something like : as soon as the heuristic dissector found a match then it would explicitely register itself as the dissector for the conversation. Perhaps we can make something like that automatic? Similarly to the current discussion some

Re: [Wireshark-dev] Wireshark PIDL generated dissectors

, Oct 7, 2013 at 1:57 PM, Guy Harris g...@alum.mit.edu wrote: On Oct 3, 2013, at 8:04 PM, ronnie sahlberg ronniesahlb...@gmail.com wrote: There is very little overlap between samba needs and wireshark needs for PIDL. It is probably better to continue running two separate forks of PIDL, one

Re: [Wireshark-dev] Wireshark PIDL generated dissectors

Cool. And we contact you when samba-PIDL no longer can generate compileable wireshark dissectors? On Thu, Oct 3, 2013 at 7:13 PM, Andrew Bartlett abart...@samba.org wrote: On Tue, 2013-10-01 at 10:55 -0400, mman...@netscape.net wrote: The check_col function in the Wireshark source has been

Re: [Wireshark-dev] Wireshark PIDL generated dissectors

These are probably better maintained by wireshark than samba. I may be able to try taking a look at your patch during the weekend. Please ping me if I forget. On Tue, Oct 1, 2013 at 7:55 AM, mman...@netscape.net wrote: The check_col function in the Wireshark source has been deprecated for

Re: [Wireshark-dev] Wireshark PIDL generated dissectors

the work? On Thu, Oct 3, 2013 at 7:58 PM, Andrew Bartlett abart...@samba.org wrote: On Thu, 2013-10-03 at 19:44 -0700, ronnie sahlberg wrote: Cool. And we contact you when samba-PIDL no longer can generate compileable wireshark dissectors? Contacting the Samba Team would seem to be the correct

Re: [Wireshark-dev] OID list usage

Which oid list are you referring to exactly ? On Thu, Sep 12, 2013 at 12:18 AM, Bart J. Smit b...@smits.co.uk wrote: Hi, I am working on a FOSS project (http://github.com/bartsmit/bedtime) and I would like to incorporate information from your OID list. Currently the relevant script

Re: [Wireshark-dev] Seaching in the data pane would be useful ...

and would just jump to the matching packet, just like today That should be possible and would improve usability. At least for the case when searching for a single field which is likely the majority of light-use searches. ronnie sahlberg

Re: [Wireshark-dev] Seaching in the data pane would be useful ...

On Fri, Aug 9, 2013 at 9:02 AM, Richard Sharpe realrichardsha...@gmail.com wrote: On Fri, Aug 9, 2013 at 8:52 AM, Christopher Maynard christopher.mayn...@gtech.com wrote: Richard Sharpe realrichardsharpe@... writes: I can across a capture yesterday where there were DNS queries for a KDC in a

Re: [Wireshark-dev] using C++, was: Notes from Sharkfest '13

Technically you could use smart pointers, or other types too. But beware the performance impact, and do get numbers before changing. Ethereal/Wireshark does an enormous amount of small allocations and frees. One of my primary goals when we added the first emem allocators were performance. Make

Re: [Wireshark-dev] Jurassic packets

Can you try loading an NFS trace on it? I recall that in the old days, sniffers usually could not decode the NFS replies since they did not keep enough state around between request/response to identify what kind of response packet it was. On Thu, Jun 13, 2013 at 11:09 AM, Gerald Combs

Re: [Wireshark-dev] Extract bytes from a tvbuff_t

fwrite(extracted, sizeof(extracted), 1, file) extracted is a pointer so sizeof(extracted) is the size of pointers on your platform. Often 4 on 32-bit platforms and 8 on 64-bit. You need something like this : fwrite(extracted, tvb_get_length(tvb, 0), 1, file) On Sat, May 25, 2013 at 1:42 PM,

Re: [Wireshark-dev] Copying TVBs for Reassembly [Was: Filebacked-tvbuffs : GSoC'13]

I dont think composite tvbs actually work. or at least they didnt work when we originally wrote the reassembly code. On Thu, Apr 18, 2013 at 12:14 PM, Evan Huus eapa...@gmail.com wrote: This is a tangential issue that has always confused me. Why do we malloc+memcpy data for reassembly when

Re: [Wireshark-dev] SRP dissector for wireshark

SCSI dissection in wireshark is a bit different than most other protocols. There is no real protocol handler, instead you call out directly to the dissect CDB, dissect data-in dissect data-out dissect sense etc. In order to do this you also need to collect some additional metadata and track

Re: [Wireshark-dev] Patches to properly handle extended responses for NTCreateX

hf_smb_volume_guid shouldnt this be a FT_GUID ? Can you try making it FT_GUID and see if it works? On Thu, May 31, 2012 at 1:57 PM, Richard Sharpe realrichardsha...@gmail.com wrote: Hi, Attached is a patch to handle extended responses for NTCreateX requests for CIFS. I have tested this

Re: [Wireshark-dev] Conversation tracking

Tobias, below On Sat, May 12, 2012 at 2:25 AM, Tobias Weiss twe...@ra.rockwell.com wrote: Thanks for your quick replies (Jeff Lars). I guess I have to explain my real problem in more detail. I want to implement a dissector for a quite old protocol that has 2 stages. The packets of the

Re: [Wireshark-dev] Regarding wireshark design

There are READMEs in the doc subdirectory. README.developer is a good starting point. Otherwise, most of the code is pretty straightforward so it shouldnt be too hard to just read it. On Thu, May 10, 2012 at 8:52 PM, Singh, Anand anand.si...@landisgyr.com wrote: Hi,   Can

Re: [Wireshark-dev] Regarding wireshark design

level drivers like phy/Mac layer. Where do I find that code section where we accessing raw buffers. Regards Anand -Original Message- From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of ronnie sahlberg Sent: Thursday, May 10, 2012 4

Re: [Wireshark-dev] Wireshark compile options

CFLAGS=-pg ./configure should do the trick On Sun, Mar 4, 2012 at 3:14 PM, James dsouza james.dso...@gmail.com wrote: Hello,     I am new to Wireshark and want to use Wireshark with gprof which requires it to be compiled with -pg option. Where should this option be added so gcc would

Re: [Wireshark-dev] Wireshark SCSI dissectors for new transports

/sense) scsi * } if your transport also supports multiple datain/out blobs for a single task, in order to reassemble the data we would also need a offset/length for each datain/out blob. regards ronnie sahlberg On Tue, Feb 28, 2012 at 8:59 PM, Stefan Hajnoczi stefa...@gmail.com wrote

Re: [Wireshark-dev] Ronnie's Wireshark presentation / attaching files to the Presentations page on the wiki

I am ok with putting the presentation on the wiki. On Thu, Jan 19, 2012 at 1:37 AM, Jeff Morriss jeff.morriss...@gmail.com wrote: Hi Ronnie, Gerald, et al, This page on the wiki: http://wiki.wireshark.org/Presentations Points, among other things, to a presentation Ronnie made back in 2008

Re: [Wireshark-dev] Is it still ok to create hidden items ?

protocol is IP, TCP or UDP, unless the user can see the filter variable in the decode pane it pretty much does not exist. regards ronnie sahlberg On Mon, Oct 31, 2011 at 9:10 PM, Roland Knall rkn...@gmail.com wrote: Hi Ok, always ready to learn something new, but answer me this:  You have two

Re: [Wireshark-dev] Is it still ok to create hidden items ?

a list of all filterable items. So see it as if they show up in the dissect pane, this is how you tell the users 'these fields exist, you can filter on them' If they dont show up in the disset pane, no one will know about them or use them, i.e. they dont exist :-) regards ronnie sahlberg

Re: [Wireshark-dev] [PATCH] Re: Freeing memory of se_alloc'ated object

to pass data like this to it too. Then when before releasing all the se_ memory, just have it walk the list of callbacks and invoke them in turn first. regards ronnie sahlberg On Tue, May 3, 2011 at 8:31 AM, Max dmitr...@gmail.com wrote: 2011/5/2 Guy Harris g...@alum.mit.edu: A separate

Re: [Wireshark-dev] Portable Linux Wireshark with custom dissectors - possible ?

the wireshark libraries. But you cant use plugins like that so your custom dissectors have to be built in as normal dissectors. regards ronnie sahlberg On Wed, Mar 9, 2011 at 12:20 PM, Dan White y...@comcast.net wrote: I have been tasked to come up with a Wireshark configuration that can sit on a USB

Re: [Wireshark-dev] Query

rfc 791 and 792 On Fri, Dec 31, 2010 at 4:52 PM, prathiba meenu prathibame...@gmail.com wrote: Hi, Could you please tell what are all the things needed to calculate checkum of ICMP and ICMPv6? -- Thanks Regards, Prathiba.H

Re: [Wireshark-dev] UDP desegmentation - how to?

Fragmented UDP packets are reassembled in the IP layer. See the preferences for IP and enable the reassembly. This should reassemble fragmented Kerberos over UDP packets. regards ronnie sahlberg On Wed, Dec 22, 2010 at 7:58 PM, Kaul myk...@gmail.com wrote: Can I use something like

Re: [Wireshark-dev] Thinking of some changes to packet-scsi.c ...

something to generate data to test with, they could at the same time enhance dbench.samba.org and its iscsi backend to be able to generate such i/o. regards ronnie sahlberg On Sun, Dec 5, 2010 at 9:45 AM, Richard Sharpe realrichardsha...@gmail.com wrote: On Sat, Dec 4, 2010 at 6:29 AM, Chris Maynard

Re: [Wireshark-dev] [Wireshark-commits] rev 34269: /trunk/tools/ /trunk/tools/: make-sminmpec.pl

Yeah, there is a whole bunch of references to it. Since it was static in the generated file and declared extern in the header file this makes it not compile on some systems On Tue, Sep 28, 2010 at 9:20 PM, Bill Meier wme...@newsguy.com wrote: sahlb...@wireshark.org wrote:

Re: [Wireshark-dev] wireshark decode as..??

change it to if (!initialized) { data_handle = find_dissector(data); helen_handle = create_dissector_handle(dissect_helen, proto_helen); for (i = 0; i 25; i++) { dissector_add(udp.port, ports[i], helen_handle); } } You

Re: [Wireshark-dev] INTERLINK dissector plugin added

On Tue, Mar 16, 2010 at 8:13 PM, Joerg Mayer jma...@loplof.de wrote: On Tue, Mar 16, 2010 at 08:16:44AM +0100, Dr. Uwe Girlich wrote: I just added (with revision 32202) a new dissector plugin: INTERLINK (yes, I know, a too general name but that's what it is called by BMW). This protocol is

Re: [Wireshark-dev] preliminary code submission

There are also some sections I think might be problematic and which would require a more detailed analysis. Possible to re-licence it under GPLv2 or maybe one of the other licences that have been verified to be compatible and has the blessing of the gpl folks? regards ronnie sahlberg On Thu, Feb

Re: [Wireshark-dev] Some random patches I use...

metze great patches, as usual. applied, thanks. On Sat, Jan 30, 2010 at 1:10 AM, Stefan (metze) Metzmacher me...@samba.org wrote: Hi, I'm using a few patches in my private git branch of wireshark. It would be nice if they could go upstream. metze

Re: [Wireshark-dev] packet-kerberos.c: hand-written or ASN.1?

it is worth it to move it to machinegenerated code. (and if doing so, we would have to use a modified asn anyway, to not break packetcable) I think it is best if you just enhance the hf fields, one by one, as you find them too terse. regards ronnie sahlberg On Wed, Jan 27, 2010 at 6:25 PM

Re: [Wireshark-dev] packet-kerberos.c: hand-written or ASN.1?

ouch, it is partially machinegenerated! when did that happen ? :-) On Wed, Jan 27, 2010 at 7:30 PM, ronnie sahlberg ronniesahlb...@gmail.com wrote: packet-kerberos.c is handwritten. packet-kerberos contains a whoole lot more than just rfc1510 (it even handles a pre rfc version of 1510

Re: [Wireshark-dev] [PATCH] LIBNDR_FLAG_NOALIGN support in wireshark and PIDL

, in anticipation of adding the pidl patches later. On Wed, Jan 20, 2010 at 1:58 AM, Julien Kerihuel j.kerih...@openchange.orgwrote: On Tue, 2010-01-19 at 13:44 +1300, Jelmer Vernooij wrote: On Tue, 2010-01-19 at 11:13 +1100, ronnie sahlberg wrote: The wireshark patch for this is fine

Re: [Wireshark-dev] [PATCH] LIBNDR_FLAG_NOALIGN support in wireshark and PIDL

...@openchange.org wrote: On Wed, 2010-01-20 at 08:50 +1100, ronnie sahlberg wrote: Can you send me your new di-no_align patch and Ill check it in right now. I started applying it yesterday but modified it (to ensure we always initialize di-no_align in get_next_di(), but will reverse these local changes

Re: [Wireshark-dev] How about moving from svn to git?

On Mon, Nov 9, 2009 at 10:31 AM, Guy Harris g...@alum.mit.edu wrote: On Nov 7, 2009, at 3:08 AM, Joerg Mayer wrote: this is just something that went through my mind yesterday while working on the third patch on the same files and without a chance to commit between the patches. If there is

Re: [Wireshark-dev] Help with ASN based dissector

It might be possible to create a ANS.1/BER description that is compatible with both encodings. FooBar ::= SEQUENCE OF { kludge KludgeFooBar } KludgeFooBar ::= CHOICE { item1 [0] IA5String item2 [1] INTEGER } I think this might work and should be able to decode both types of encoding. It

Re: [Wireshark-dev] Wireshark's ISN handling

It does happen from time to time. Most commonly when you have a retransmitted packet early in the trace that has a sequence number before the first packet seen. In that case those retransmitted packets just get a negative sequence number (~ -2 billion something). You get used to it and it is not

Re: [Wireshark-dev] Parsing array and its size in EcDoRpcExt2

. It is actually encoded at the head of the encapsulating structure) regards ronnie sahlberg On Tue, Apr 28, 2009 at 10:32 AM, Harsha inet.har...@gmail.com wrote: On Mon, Apr 27, 2009 at 3:38 PM, Harsha inet.har...@gmail.com wrote: I did a quick read of the relevant part of DCE RPC specs, but in all

Re: [Wireshark-dev] one possible way to speed up filtering

Another way to greatly speed up filtering would be to pick up and clomplete the work to make it possible to use ep_* memory for all field types when dissecting a packet. When wireshark dissects a packet it performs a massive amount of malloc()/free(). This was partially addressed when I added

Re: [Wireshark-dev] reasebling packets - dissector question

but i noticed that the TCP checksum test fails That may be an issue. Try disabling TCP checksum validation in the preferences for TCP. By default, TCP reassembly will ignore all packets with a checksum failure or short packets. (i.e. packets captures with a snaplen smaller than the ethernet mtu)

Re: [Wireshark-dev] [Wireshark-commits] rev 25368: /trunk/ /trunk/epan/crypt/: Makefile.common Makefile.nmake /trunk/epan/: addr_resolv.c emem.c /trunk/gtk/: Makefile.common Makefile.nmake /trunk/: Ma

why did you remote wireshark-tap-register.c from the makefile? wireshark doesnt build under linux without this file. On Fri, May 23, 2008 at 3:55 PM, [EMAIL PROTECTED] wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=25368 User: etxrab Date: 2008/05/22 10:55 PM Log:

Re: [Wireshark-dev] jumping tcp packets

You would only be able to see the packets that you are fast enough to capture, process and write to disk. In particular for high speed networks it is an unfortunate fact-of-life that you wont be able to capture packets and write them to disk at the same speed as the packets arrive at the nic and

Re: [Wireshark-dev] ethernet over USB

Hi. I think you are comparing apples to oranges here. SnoopyPro is a USB capture tool and it captures the various layers of the USB protocol. When used for EthernetOverUSB several layers above the USB layer is where you will find Ethernet frames. So with SnoopyPro you are capturing USB

Re: [Wireshark-dev] Trouble adding an ASN.1 based dissector

If Im not mistaken T124 is encoded with aligned PER while T125 is BER so oyu also need to change the flags to asn2wrs to generate a PER dissector. You then also need to look at how other PER dissectors set whether it is aligned or unaligned PER from the template file. On Nov 24, 2007 8:26

Re: [Wireshark-dev] proto_filter_names hash collision

Instead of creating a hash and store it in a hashtable wouldnt it be better/faster to just store the names as the strings as is in a se-tree instead. That should be much faster. On Nov 21, 2007 8:13 AM, Guy Harris [EMAIL PROTECTED] wrote: Kukosa, Tomas wrote: It seems that we have reached

Re: [Wireshark-dev] proto_filter_names hash collision

or rather a pe-tree On Nov 21, 2007 9:45 AM, ronnie sahlberg [EMAIL PROTECTED] wrote: Instead of creating a hash and store it in a hashtable wouldnt it be better/faster to just store the names as the strings as is in a se-tree instead. That should be much faster. On Nov 21, 2007 8:13 AM

Re: [Wireshark-dev] Is there a good way of handling bitfields with different bitmask offsets ?

Not tested! grab the hfinfo structure and modify the fields at runtime : header_field_info *hfinfo; hfinfo = proto_registrar_get_nth(hf_index); hfinfo-bitmask = new bitmask hfinfo-bitshift = new bit shift very ugly. it could work. please do not contribute any code to wireshark that does

Re: [Wireshark-dev] New Dissector: LLRP

Please add a page to the wiki for this protocol with some screenshot and samplecaptures. See http://wiki.wireshark.org/WakeOnLAN for an excellent example on what a wikipage should look like. On Nov 7, 2007 1:42 AM, Matt Poduska [EMAIL PROTECTED] wrote: I've submitted a new dissector to be

Re: [Wireshark-dev] More ITU-T standards available

Dont thank me. Im just a messenger. Send an email to ITU-T and thank them. On Nov 5, 2007 6:30 PM, Abhik Sarkar [EMAIL PROTECTED] wrote: Brilliant news indeed! Thanks Ronnie! On Nov 5, 2007 11:09 AM, ronnie sahlberg [EMAIL PROTECTED] wrote: List, people with telco protocol

[Wireshark-dev] More ITU-T standards available

List, people with telco protocol interests Some really good news: http://www.itu.int/ITU-T/newslog/Free+Access+For+All+To+ITUT+Standards.aspx http://www.itu.int/ITU-T/publications/recs.html ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org

Re: [Wireshark-dev] decoding Remote Desktop Protocol

I have commited an initial and very limited X.224 dissector that registers TPKT on port 3389 and makes TPKT spawn off this port into X.224 instead. The X.224 dissector is very incomplete and only really dissects CR/CC/DT and only for class 0. But it is good enough for now as a start to decode up

Re: [Wireshark-dev] decoding Remote Desktop Protocol

this be MTrq/MTcf from T.125 ? On 10/26/07, Kukosa, Tomas [EMAIL PROTECTED] wrote: I can look if asn2wrs could generate at least some usefull code for T.128 Legacy mode. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ronnie sahlberg Sent

Re: [Wireshark-dev] decoding Remote Desktop Protocol

I think RDP is just using T.126 with some extra extensions. As far as I recall it is using the old legacy encoding and not ASN PER. I did find some documentation about this a long time ago but never had any traces/nor real interest in implementing it. It should be possible to find the T.126

Re: [Wireshark-dev] decoding Remote Desktop Protocol

The parser files are plain-text with no sort of licensing information in them. How likely is it that I would get in trouble for posting them to this list? I'll do some more reading before venturing into that. Please DON'T ! The files are still copyrighted. since the rdesktop tool can

Re: [Wireshark-dev] decoding Remote Desktop Protocol

. • Files with an .npl file extension. You may copy and distribute the object code form of code of only those files marked with an .npl file extension and copy and use such modified files solely for your internal use. So, no joy there. I bow to your wisdom. -Jason On 10/24/07, ronnie

Re: [Wireshark-dev] Adding CFM plugin and requesting review.

some comments 1, the libfile should be a header file packet-cmf.h with the usual boilerplates included 2, all value strings must be terminated with a {0,NULL} entry or else you risk reading beyond the end of the array. 3, get rid of theif (proto_cfm == -1) { this function should only be

Re: [Wireshark-dev] Steps to port wireshark to windows xp, vista and solaris

send your dissectors to the mailing list and someone will review it and give suggestions on what is portable and what needs fixing. once the dissector is in the mainline codebase it will be built and verified on windows hosts that are part of the buildfarm On 9/25/07, [EMAIL PROTECTED] [EMAIL

Re: [Wireshark-dev] Strip Ethernet broadcast / locally administered flags from address before doing manufacturer name resolvings?

On 8/17/07, Sake Blok [EMAIL PROTECTED] wrote: On Wed, Aug 15, 2007 at 04:26:23PM +0200, Joerg Mayer wrote: On Wed, Aug 15, 2007 at 03:31:08PM +0200, Sake Blok wrote: I can't imagine myself situations where you locally assign an address and still be interested in the manufacturor of the

Re: [Wireshark-dev] Strip Ethernet broadcast / locally administered flags from address before doing manufacturer name resolvings?

Sounds good. In particular doing this for the LocallyAdministrated would make sense since many active/passive cluster implementations pick a MAC address to represent the active node by taking the MAC address of the primary NIC of the primary node and then setting the locally administrated bit, to

Re: [Wireshark-dev] Strip Ethernet broadcast / locally administered flags from address before doing manufacturer name resolvings?

On 8/15/07, ronnie sahlberg [EMAIL PROTECTED] wrote: Sounds good. In particular doing this for the LocallyAdministrated would make sense since many active/passive cluster implementations pick a MAC address to represent the active node by taking the MAC address of the primary NIC

Re: [Wireshark-dev] TCP Reassembly issues

On 7/10/07, Graham Bloice [EMAIL PROTECTED] wrote: DNP application message fragments are carried in a transport layer which has a single byte header containing a 6 bit sequence number (tr_seq, 0-63) and two flags, first (tr_fir) and final (tr_fin). A single fragment message will have both

Re: [Wireshark-dev] Run-time error (samr.hnd disappeared)

i temporarily disabled sidsnooping for now. sidsnooping was an idea i had a long time ago but i never finished properly. it would be nice if it were enhanced in the future to actually look at most of the dcerpc commands where sids are mapped and used it. it would also be nice with a small gui

Re: [Wireshark-dev] Beginner article for custom dissector now on Code Project

You need to terminate the value_string with a {0,NULL} entry to tell wireshark where it ends. Othervise you risk reading beyond the end which will cause a segfault. On 7/1/07, Ken Thompson [EMAIL PROTECTED] wrote: I've recently published a beginner article on creating a custom dissector. This

Re: [Wireshark-dev] WiMAX and M2M plugin code

Do you have any example captures we can use to fuzz test the dissector with? On 5/18/07, Harvey, Michael [EMAIL PROTECTED] wrote: Here is the code for the WiMAX and M2M plugins. These are not supplied as patches but as plugin subdirectories. Since WiMAX is a wireless protocol, we created an

Re: [Wireshark-dev] [Wireshark-commits] rev21705:/trunk//trunk/plugins/asn1/:asn1.hpacket-asn1.c/trunk/epan/dissectors/:packet-MAP_DialoguePDU.cpacket-acp133.cpacket-acse.cpacket-ansi_map.c packet-ber

Is it really worth it to asn2wsr'ify the kerberos dissector? First, the dissector currently handles two different versions of kerberos, both the standard 1510 ASN but also the slightly different ASN used by packetcable. Second, the dissector as it is today is almost complete and dissects

Re: [Wireshark-dev] [Wireshark-commits] rev 21644: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-per.c

it broke SUSE Linux :-) not windows On 5/2/07, Kukosa, Tomas [EMAIL PROTECTED] wrote: Hi, I would fix it but I have to wail till result from builbot is available as do not have non-Windows environment. T. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]

Re: [Wireshark-dev] protocol question

since all your examples above are widely used and publicly available standardized protocols is there any particular reason why implementation of these protocols would have to be private and not be contributed to wireshark? (those parts that are missing from the existing dissectors that is) On

Re: [Wireshark-dev] [Wireshark-commits] rev 21262: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-dcerpc-atsvc.c packet-dcerpc-dfs.c packet-dcerpc-efs.c packet-dcerpc-eventlog.c packet-dcerpc

Note that I did not yet regenerate WKSSVC since this dissector would really need the not yet finished TYPE conformance file directive in order to handle the dependency for a type from SRVSVC properly. On 3/29/07, Joerg Mayer [EMAIL PROTECTED] wrote: On Thu, Mar 29, 2007 at 02:22:24AM +,

Re: [Wireshark-dev] State of pidl and idl/cnf files?

We kind of use the original idl files, or at least some of them. There are two exceptions where we are out of sync with samba and that is the EVENTLOG and the SRVSVC idl files where there are a additional fields and functions that samba have not yet merged into their idl files. PIDL still needs

Re: [Wireshark-dev] State of pidl and idl/cnf files?

Forgot: I think this was discussed some 2 years ago or so. I think the long term plans are that samba owns the idl files and we only use copies of them. We on the other hand should own the conformance files and any conformance files in samba should be deleted or linked to ours. On 3/29/07,

Re: [Wireshark-dev] [Patch] pragma warning

I dont think it is really realistic to have all autogenerated files always compile without any warnings. Maybe we should instead split Makefile.common up into three parts : First part : normal dissectors Second part : ANS2WRS generated dissectors which take extra compile time flags and

Re: [Wireshark-dev] [Patch] pragma warning

On 3/28/07, Ulf Lamping [EMAIL PROTECTED] wrote: ronnie sahlberg wrote: I dont think it is really realistic to have all autogenerated files always compile without any warnings. Maybe we should instead split Makefile.common up into three parts : First part : normal dissectors Second

Re: [Wireshark-dev] Patch to AMQP dissector

checked in On 3/27/07, Martin Sustrik [EMAIL PROTECTED] wrote: Hi Ronnie, here's a patch to AMQP dissector. The only change is that when there are seceral AMQP frames in single TCP packet, all of them are referred in the info column. Can you check it in? Thanks. Martin

Re: [Wireshark-dev] [Wireshark-commits] rev 21256: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-dcerpc-winreg.c packet-dcerpc-winreg.h /trunk/epan/dissectors/pidl/: winreg.idl

:-) Well those files are not supposed to be manually edited/modified anyway. I can change PIDL to always emit #ifdef _MSC_VER #pragma warning(disable:4005) #pragma warning(disable:4013) #endif at the head of the file. Are there any other pramgas you want it to emit as well? On

Re: [Wireshark-dev] Patches for compilation warnings

On 3/27/07, Peter Johansson [EMAIL PROTECTED] wrote: Oh, my bad. So how can one fix these problems then? I am not really on top of IDL, what should one generally do to correct this? I have sent patches to Jelmer that maintains PIDL that will address most of the warnings from the pidl generated

Re: [Wireshark-dev] Segmentation fault in dissector

Is this a proprietary dissector or a dissector you plan to contribute to wirehsark? On 3/27/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi, We are using a 32 bit machine and dissector is working fine. The same dissector when used in a 64 bit m/c is giving problems. I would like to

Re: [Wireshark-dev] [PATCH] bunch of warnings fixes

checked in On 3/26/07, Sebastien Tandel [EMAIL PROTECTED] wrote: One big patch is provided to apply all the changes. It contains warnings fixes and removed some declarations after statement too. I also provide patch-per-file.tar.gz containing one patch for each file affected by big patch,

  1   2   3   >