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

[ronnie sahlberg]

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 trigger the warnings.  Wireshark developers
are not supposed to
keep track of what are false warnings that are bogus or what are real
problems.
* if you have a problem with the compiler, bring it up with them. we are
not compiler developers or maintainers.
* work on your people skills. You are rubbing people that could help you in
seriosly the wrong way.


On Wed, Mar 31, 2021 at 5:21 PM Constantine Gavrilov 
wrote:

> I have a question regarding for a special form of automatic builds that I
> do not understand.
>
> Occasionally, I get an email for additional pipeline build that is
> different from default pipeline linked to the ticket. It is a wider set of
> compilers and distributions.
>
> Several questions:
>
>1. What is the significance of this and when it is triggered?
>2. Why it is not linked to MR (meaning I cannot see this failure in
>MR)?
>3. Shall I fix these failures?
>4. How do I know that the issue is fixed, since such builds are not
>linked to MR?
>5.
>
> I have looked at this particular one, and it is a a bug in compiler:
>
> guint64 off =...; /* take from command context, now looking at reply */
> if (off < 40)
> proto_add_item(,  40-off,.);
>
> So, the error (in CLANG-11) is (40-off) is 64-bit and passing it as 32-bit
> parameter "looses high-order bits".
>
> First, the compiler shall see that no loss of value takes place because of
> the "IF" statement here. Second, since when passing 64-bit value as a
> 32-bit parameter shall be a compiler error in C language?
>
> I can easily fix this (check the value in saved context, and if it is
> above possible payload length return, then declare off as 32-bit), but I
> need to know if CLANG-11 (with draconian compile options) is a MUST to
> pass.
>
>
> -
> 
> Constantine Gavrilov
> Storage Architect
> Master Inventor
> Tel-Aviv Storage Lab IDT Lead
> Tel-Aviv IBM Storage Lab
> 1 Azrieli Center, Tel-Aviv
> 
> - Forwarded by Constantine Gavrilov/Israel/IBM on 03/31/2021 10:07 AM
> -
>
> From:GitLab 
> To:
> Date:03/30/2021 05:37 PM
> Subject:[EXTERNAL] Failed pipeline for nvmeof_getlog_page |
> wireshark | 3a8e09ef
> Sent by:git...@mg.gitlab.com
> --
>
>
> Pipeline #278885577 has failed!   Project Constantine Gavrilov / wireshark
> Branch nvmeof_getlog_page Commit
> ‍‍‍ZjQcmQRYFpfptBannerStart
> *This Message Is From an External Sender *
> This message came from outside your organization.
> ZjQcmQRYFpfptBannerEnd
>
> Pipeline #278885577 has failed!
>
>
> Project
> Constantine Gavrilov / wireshark
> 
> Branch
> nvmeof_getlog_page
> 
>
> Commit
> 3a8e09ef
> 
> NVMe: Get LogPage: Commands Supported and Effects
> Commit Author
> Constantine Gavrilov 
>
>
>
> Pipeline #278885577
> triggered
> by
> Constantine Gavrilov 
>
> had 1 failed build.
> Failed builds
> build
>
> clang-11 
>
>
>
>
> You're receiving this email because of your account on gitlab.com. Manage
> all notifications  · Help
> 
>
>
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[ronnie sahlberg]

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
> captures when trying to figure out bugs in our code.
>
> I often have captures with a lot of different types of packets and
> need to find a particular set of packets of mixed type, eg SMB2
> followed by the NFS packets caused by the SMB2 request or SMB2
> followed by the Kerberos packets caused etc.
>
> What I would like to be abe to do is to set up a filter string for a
> specific type of SMB2 request, say, based on source and dest IP and
> maybe type (ie, a CREATE, or whatever) and then go to the first such
> packet in the capture and then examine the subsequent packets to see
> if they satisfy my criteria. If they don't then I would like to go the
> next packet that satisfies my filter string and examine them, and so
> on until I find what I am looking for.
>
> I will usually also have filtered already on two types of frames (or a
> few types) like SMB2 || NFS.
>
> Currently, the only way I can think to do this is to filter on SMB2,
> select the first one I am interested in, unfilter (or refilter),
> examine the packets, and if they are not what I am interested in,
> refilter on SMB2 and select the next packet, and so on. The workflow
> is quite painful.
>
> Is there a simpler way to do this?
>
> If not, could we add a button for Next packet satisfying filter?
>
> --
> Regards,
> Richard Sharpe
> (何以解憂？唯有杜康。--曹操)(传说杜康是酒的发明者)
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[ronnie sahlberg]

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 sahlberg  wrote:
>
> 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!
> > >
> > > Thank you Outreachy, Git, and Wireshark for the opportunity, happy
> > > to be working together!
> >
> > Welcome!  I'm looking forward to working together (starting with an
> > initial wireshark patch to get the lay of the land, then fleshing out
> > the plan for the project, then executing on it in earnest).
> >
> > A question for wireshark developers: are there preferences for what a
> > high quality dissector looks like?  [1] talks about portability and
> > robustness but doesn't address other aspects of convention such as how
> > long functions should be (like [2] does).  Is there a rule of thumb
> > like "when in doubt, do things the way 
> > does?"
>
> Only speaking for myself. This one is tricky.
> Most dissectors I think follows [1] and [2] pretty closely, with the
> exception that I don;t think
> there is any concern about lengths of a function. For a lot of
> protocols you may end up with
> switch statements with hundreds of cases and then that is just how it
> is. Or similar.
>
> Now, this is not uniform across all dissectors. Wireshark has grown
> organically over more than two decades
> and styles and preferences, which at the end of the day are dictated
> by the developers, change.
>
> So do not be surprised to find some dissectors that are very different
> in style. In some cases it might
> just be that the dissector is very old and also for an obscure
> protocol that almost no one cares about.
> Sometimes it is that simple.
>
> I would see [1] and [2] as good guidelines but not absolute law. Then
> also when in doubt look at how are things done
> in popular protocols where there are many developers involved and
> where the dissector is well maintained.
> For example  packet-smb2.c  is pretty modern and has a fair amount of
> crunch to keep up with the evolving standard.
>
> Modern and popular(i.e. people care about them) dissectors also are
> much more likely to contain useful examples of more advanced features
> such as
> * ExpertInfo,
> * Preferences,
> * Reassembly,
> * lots of Generated items (things that are not part of the packet
> itself but still useful to show when wireshark deducts it),
> * state tracking such as keeping track on Request and Response
> matching and response times.
> etc etc etc.
>
> This makes the dissectors more daunting to look at since there are so
> many different concepts there ontop of just "show what the bits and
> bytes mean" but at the same time they show these extra things that we
> usually have in a good/popular/mature dissector.
>
>
> But at the end of the day, for every protocol, what makes a good
> dissector is what an experienced engineer would need to do his/her
> job.
> I think that means that it takes a lot of subject-matter-expert
> knowledge to know what is useful and what is not and here you probably
> have as good or probably better input on what the dissection features should 
> be.
>
> Hypothetical example: say if wireshark had a feature where it would
> reassemble objects and store them under their hash somewhere
> and it allowed you to right-click on a sha1 in the dissection pane and
> then "export object as file". Would that be useful?
> You would know if it would be useful for git developers and engineers.
> I have no idea.
>
> ronnie
>
> >
> > Excited,
> > Jonathan
> >
> > [1] https://gitlab.com/wireshark/wireshark/-/raw/master/doc/README.developer
> > [2] https://www.kernel.org/doc/html/v5.9/process/coding-style.html
> > ___
> > Sent via:Wireshark-dev mailing list 
> > Archives:https://www.wireshark.org/lists/wireshark-dev
> > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> >  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[ronnie sahlberg]

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!
> >
> > Thank you Outreachy, Git, and Wireshark for the opportunity, happy
> > to be working together!
>
> Welcome!  I'm looking forward to working together (starting with an
> initial wireshark patch to get the lay of the land, then fleshing out
> the plan for the project, then executing on it in earnest).
>
> A question for wireshark developers: are there preferences for what a
> high quality dissector looks like?  [1] talks about portability and
> robustness but doesn't address other aspects of convention such as how
> long functions should be (like [2] does).  Is there a rule of thumb
> like "when in doubt, do things the way 
> does?"

Only speaking for myself. This one is tricky.
Most dissectors I think follows [1] and [2] pretty closely, with the
exception that I don;t think
there is any concern about lengths of a function. For a lot of
protocols you may end up with
switch statements with hundreds of cases and then that is just how it
is. Or similar.

Now, this is not uniform across all dissectors. Wireshark has grown
organically over more than two decades
and styles and preferences, which at the end of the day are dictated
by the developers, change.

So do not be surprised to find some dissectors that are very different
in style. In some cases it might
just be that the dissector is very old and also for an obscure
protocol that almost no one cares about.
Sometimes it is that simple.

I would see [1] and [2] as good guidelines but not absolute law. Then
also when in doubt look at how are things done
in popular protocols where there are many developers involved and
where the dissector is well maintained.
For example  packet-smb2.c  is pretty modern and has a fair amount of
crunch to keep up with the evolving standard.

Modern and popular(i.e. people care about them) dissectors also are
much more likely to contain useful examples of more advanced features
such as
* ExpertInfo,
* Preferences,
* Reassembly,
* lots of Generated items (things that are not part of the packet
itself but still useful to show when wireshark deducts it),
* state tracking such as keeping track on Request and Response
matching and response times.
etc etc etc.

This makes the dissectors more daunting to look at since there are so
many different concepts there ontop of just "show what the bits and
bytes mean" but at the same time they show these extra things that we
usually have in a good/popular/mature dissector.


But at the end of the day, for every protocol, what makes a good
dissector is what an experienced engineer would need to do his/her
job.
I think that means that it takes a lot of subject-matter-expert
knowledge to know what is useful and what is not and here you probably
have as good or probably better input on what the dissection features should be.

Hypothetical example: say if wireshark had a feature where it would
reassemble objects and store them under their hash somewhere
and it allowed you to right-click on a sha1 in the dissection pane and
then "export object as file". Would that be useful?
You would know if it would be useful for git developers and engineers.
I have no idea.

ronnie

>
> Excited,
> Jonathan
>
> [1] https://gitlab.com/wireshark/wireshark/-/raw/master/doc/README.developer
> [2] https://www.kernel.org/doc/html/v5.9/process/coding-style.html
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[ronnie sahlberg]

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 various fields 
> > that are part of the header, and it’s convenient/logical to group those 
> > fields within the header subtree.  However, doing so results in a Packet 
> > Diagram that only shows the raw bytes of the subtree rather than the 
> > individual fields contained within the subtree.
> >
> > So either I’m doing something wrong, in which case I welcome any 
> > suggestions for improving the display, or there seems to be a current 
> > limitation to the way the Packet Diagram behaves with respect to subtrees.  
> > Has anyone else noticed this?
> > ...
> >
> > Is there a way to achieve this while still grouping the fields within a 
> > subtree?
> >
> >
> > Not in a subtree currently. If you look around line 600 of 
> > ui/qt/packet-diagram.cpp, you'll see that it only groups the top level 
> > fields in each protocol.
>
> That's correct. I wanted to keep the initial implementation as simple, naive, 
> and lazy as possible.
>
> > For the same reason, bitmask fields that are grouped together not in a 
> > subtree, using proto_tree_add_bitmask_list()
> > (like packet-rtp.c#L2072 with octet1_fields), then they are displayed 
> > separately (in master, post commit
> > https://gitlab.com/wireshark/wireshark/-/commit/7654bb260d08fdb7adeafce1877fa3c38f3465ae
> >  
> > 
> >  ), whereas
> > for bitmask fields that are added with a subtree with 
> > proto_tree_add_bitmask() only the top level header
> > item appears.
> >
> > You can see some images here: 
> > https://gitlab.com/wireshark/wireshark/-/merge_requests/959 
> > 
> > There you can see bitmask fields that are displayed properly because there 
> > is no subtree.
> >
> > I agree it would be a nice enhancement to travel down into the children of 
> > items that have children, though I imagine
> > you'd have to take care in some cases; e.g., dissect_e164_msisdn() from 
> > packet-e164.[ch] is used a lot in various dissectors,
> > and has a header that has the entire number, with child that only has the 
> > country code (but not a child for the non country code digits).
> > The simplest way to descend into the subtree for a E.164 number would thus 
> > only has an entry for the country code but leave the
> > other bits blank. Or you could have issues with dealing with overlaps.
>
> Would it make sense to add second-level items only if they collectively fit 
> the offset+size of the top-level item? In this case we'd skip the 
> second-level country code child, but we'd add it if dissect_e164_msisdn() 
> added a non-country code sibling field.

I think so, it is worth trying.
When it expands these subtrees I think it would be nice also if it
would put an extra thick border around the entire subtree.
So it is easy to visually see what the different subtrees are.
(See smb2 as an example, it has two subtrees in every pdu, header and
command, and nothing else)

(
I tested adding a new flag for items so you you could tell wireshark
to step down into these subtrees.
It was mainly driven by SMB2 which only has two top level items and I
wanted to at least show the content of "smb2/header" instead of it
just being a 64 byte blob
but threw it away because it would be unrealistic to go through all
dissectors manually and individually flag which trees to expand
)

>
> BTW, for 1- and possibly 2-bit fields we might want to take inspiration from 
> https://twitter.com/vivekrj/status/1269649718059118601 and rotate the label 
> 90 degrees.
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[ronnie sahlberg]

Hi Emily

I got confused. I worked in Jonathans team about 5-6 years ago and
since I am old fart I couldn't realize that maybe they had other
people join since I left.
Hence I assumed you were the intern.

Just me being senile. No harm meant.

Regardless, a git dissectors will be totally awesome 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:36:23PM -0700, Junio C Hamano wrote:
> >
> > "brian m. carlson"  writes:
> >
> > > On 2020-09-19 at 09:12:53, ronnie sahlberg wrote:
> > >> Hi Jonathan,
> > >> Hi Emily
> > >>
> > >> Emily, you want to contribute to wireshark? That is awesome. I think I
> > >> speak for everyone to send a HUGE welcome
> > >> your way and hope your experience working on and with wireshark be 
> > >> excellent!
> > >
> > > I think there's been a misunderstanding.  I think the proposal was to
> > > have Emily and Jonathan, who are both significant contributors to Git,
> > > doing the mentoring from the Git side, along with someone from the
> > > Wireshark side.  I don't think we know yet if anyone will be interested
> > > in working on it, but it seems from the response to be a proposal that
> > > has interest in both projects.
> > >
> > > Feel free to correct me if I've misunderstood.
> >
> > That matches my understanding.
>
> Right - brian and Junio are correct, I'm hoping to co-mentor with
> Jonathan. Ronnie, I'm really pleased to see this warm welcome, which
> makes me optimistic about the kind of experience an intern would have on
> this project. It would be really great if we could get a volunteer to
> serve as point-of-contact if the mentee is not sure about something
> they want to send to the Wireshark list, and possibly to come to an
> introductory real-time chat (video/voice/IM) to provide a little
> overview and nudge in the right direction.
>
> It sounds to me like we have enough enthusiasm to put this project on
> the list, though - if I understood my conversation with Jonathan last
> week he's planning to add that. Feel free to correct me :)
>
> Thanks, Ronnie and Richard!
>
> > > > (
> > > > Jonathan, remember that smb2 client I was working on, libamb2?  I got
> > > > it to run on PlayStation2 now. It is totally awesome being able to use
> > > > SMB3.1.1 and full encryption to copy file between the PS2 memory card
> > > > and Azure cloud file server :-)
> > > > )
>
> (This actually sounds awesome. Got a repo or blog post up somewhere?)
>
>  - Emily
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[ronnie sahlberg]

Hi Jonathan,
Hi Emily

Emily, you want to contribute to wireshark? That is awesome. I think I
speak for everyone to send a HUGE welcome
your way and hope your experience working on and with wireshark be excellent!

I think a git dissector would be really awesome.
We do have a packet-git.c already in wireshark, but looking at it it
is very barebones (understatement of the year:-)
but getting a real full blown git protocol implementation would be
totally awesome.

I am more than happy to provide feedback and advice for Emily. We do
have pretty good development documentation so it should be pretty easy
to get started and get a development environment up and running.


(
Jonathan, remember that smb2 client I was working on, libamb2?  I got
it to run on PlayStation2 now. It is totally awesome being able to use
SMB3.1.1 and full encryption to copy file between the PS2 memory card
and Azure 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
> projects.
>
> Emily (cc-ed) and I would be interested in mentoring an outreachy
> intern on adding support for the Git protocol to wireshark.  We think
> this would be helpful for documenting the spec better, for making
> debugging easier for future Git developers, and for helping people
> working on systems involving Git (e.g. CI systems) to understand the
> behavior of the systems they oversee.  We think that a co-mentor
> within wireshark would be helpful for making sure an intern is set up
> for success (helping them find pointers, making sure their approach is
> on the right track, etc).
>
> This would be a project under the Git umbrella
> <https://www.outreachy.org/communities/cfp/git/>.
>
> What do you think?  Does this sound interesting to you?
>
> Thanks,
> Jonathan
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[ronnie sahlberg]

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 community.
>
> Why? Nothing is broken at the moment, so nothing needs fixing, AFAICT.
>
> I would suggest the following alternative approach that the Samba team
> seems to have adopted:
>
> https://wiki.samba.org/index.php/How_to_do_Samba:_Nicely
>
> As far as I can recall, there have been no instances of the behavior
> the Contributor Covenant seems to protect against, so what is the
> point here?
>
> Is someone saying that Wireshark is bad because of harassment on the lists?
>
> > I propose that we adopt the "Contributor Covenant" version 2 [1] for our 
> > community.
> > This is a well established CoC with a good scope (including code review, 
> > mailing lists, ask.wireshark.org, Sharkfest).
> >
> > The instance to handel reports should be a team consisting of 3 or 5 well 
> > accepted community members (not only core
> > devs). The email address to reach them should be an alias or so 
> > (repo...@wireshark.org).
> > We should have a wiki page where the team members are listed (similar to 
> > node.js [2]).
> >
> > [3] gives a nice overview of CoC and is a good starting point to read. [4] 
> > is a scientific paper discussing some aspects
> > of different CoC.
> >
> > So, what's your opinion? Any concerns? Any suggestions?
> >
> > Cheers
> > Uli
> >
> > [1] https://www.contributor-covenant.org/version/2/0/code_of_conduct.html
> > [2] https://github.com/nodejs/admin/blob/master/CODE_OF_CONDUCT.md
> > [3] https://opensource.guide/code-of-conduct/
> > [4] https://www.win.tue.nl/~aserebre/SANER2017.pdf
> >
> >
> > ___
> > Sent via:Wireshark-dev mailing list 
> > Archives:https://www.wireshark.org/lists/wireshark-dev
> > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> >  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
>
>
>
> --
> Regards,
> Richard Sharpe
> (何以解憂？唯有杜康。--曹操)(传说杜康是酒的发明者)
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Bzip2 support

[ronnie sahlberg]

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,
> >
> > It (http://sourceware.org/bzip2/manual/manual.html#limits) now says: 
> > "Further ahead, it would be nice to be able to do random access into files. 
> > This will require some careful design of compressed file formats."
>
> gzip format wasn't carefully designed for that, either, but it can be - and 
> has been - made to work.  It requires storing dictionary state.

Yepp. BGZIP and its library you can link with does this. I even built
a fuse filesystem to transparently "unzip" these kind of files.

What BGZIP does is that it will restart a new dictionary every ~64k
bytes and also stores an index in a separate file.
The bgzip file itself is compatible with gzip so you can uncompress it
using vanilla gzip
but in order to do random reads/seek in the file you need the index file.

It works, quite well.
The problem I found is that when you restart with a new dictionary
every ~64kb there is not much for the compression engine to work with
so compression ratio is usually (in my cases) quite poor compared to
normal gzip.
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[ronnie sahlberg]

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 time.

Except in your situation where we have lost so many packets that we no
longer have any knowledge of pdu boundaries.
In that situation the only thing that can bring wireshark back on
track is to find a frame where the start of the SMB pdu is at the
start of the tcp segment.

We could do a lot better here especially for SMB since we can fairly
strong heusirsitics :
i.e. we can verify that the 4-byte length looks sane, we can verify
that the 'S' 'M' 'B' 0xff/0xfe/0xfd signature is there, we can check
that the command opcode is sane
and even check that the sessionid matches sessions from before the gap
in packets.


Hypothetically we could add a mechanism where a protocol could
register a callback to the tcp dissector and say
"if you have lost track of the pdu boundaries, and the attempt to call
the dissector at tcp segment offet 0 was also rejected then
call this special 'serach the whole segment to find a new PDU start' callback."

That should make it possible to automatically find those headers and
also dissect them.




On Mon, Dec 31, 2018 at 12:58 PM Richard Sharpe
 wrote:
>
> Hi folks,
>
> I recently had to perform some surgery on a packet capture that had
> dropped packets.
>
> I was capturing a GbE link that was operating at capacity and a few
> packets were dropped in the area I was interested in.
>
> I was chasing the reason that the current Mac OS X smbfs would
> disconnect from the server on some occasions.
>
> I was interested in the SMB headers and had no interest in the data
> carried in SMB writes or reads, and fortunately, none of the dropped
> packets in the area I was interested in covered SMB headers.
>
> Using wireedit, mergecap and Wireshark's ability to export packets
> from a point in the capture I was able to put together a new capture
> that showed me all the SMB info, by:
>
> 1. Exporting a singe frame where the NetBIOS/SMB header was in the
> middle of a TCP segment,
> 2. Remove the portion from before the NetBIOS header and adjust the
> sequence number (that is, essentially split the segment into two),
> 3. Merge the adjusted packet with the packets from after its position
> in the capture,
> 4. Make up the missing few packets/segments by saving the packet from
> before the missing segment, duplicating the data and adjusting the
> sequence numbers.
>
> This worked quite well and I was able to determine that the Mac OS X
> smbfs was sometimes not sending an SMB request and thus causing
> crediting issues.
>
> That lead me to think of the following changes that would be useful:
>
> 1. It would be useful to have a right-mouse-button menu item that
> allows you to split a frame into two TCP segments at the point where
> the mouse is pointing.
>
> This would possibly allow Wireshark to correctly dissect the data
> starting at that point, especially if you save the capture from the
> new frame forward.
>
> 2. It would also be useful if you could tell Wireshark: Please insert
> a TCP segment with random data to cover the missing segments that it
> so conveniently warns you about.
>
> Perhaps these could be handled by adding some sort of pcap-ng
> annotation to the frames specifying additional actions.
>
> Anyway, can anyone think of other ways to achieve what I want and
> other ideas like these?
>
> --
> Regards,
> Richard Sharpe
> (何以解憂？唯有杜康。--曹操)(传说杜康是酒的发明者)
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[ronnie sahlberg]

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
> >  secrets before they are used.
> > - Place secrets before the packet blocks that require them. Consumers
> >  can read and decrypt in one pass. Disadvantage: producers cannot
> >  always guarantee availability of secrets while writing the capture.
> > - Place a single secret block before the first packet block. Consumers
> >  can read and decrypt in one pass. Disadvantage: requires producers to
> >  post-process (rewrite) the capture file to insert secrets.
>
> The third of those appears to be a special case of the second of those.  I 
> don't see any need to require the secrets to be before the *first* packet 
> block if the first packet block doesn't require the secret; presumably 
> "before the packet blocks that require them" just means "*somewhere* before 
> the packet blocks that require them", which is *allowed* to be "before all 
> packet blocks in the file" but not *required* to be "before all packet blocks 
> in the file".
>
> If the secret isn't available by the time the first packet requiring the 
> secret for decryption is ready to be written to the capture, *somebody* will 
> have to do some form of two-pass processing.
>
> The first option says the consumer must do so; that's inconvenient for a 
> consumer doing one-pass processing (tcpdump, TShark without the -2 option), 
> and isn't even really good for at least some consumers doing two-pass 
> processing (Wireshark, TShark with the -2 option), because dissection is done 
> on the first pass.
>
> The second and third option require either the producer, or some 
> post-processor, to write a new version of the file putting the secrets before 
> the packets that require them.  The producer isn't necessarily responsible 
> for doing so; one might have tcpdump, or dumpcap (or some program using 
> dumpcap, such as TShark or Wireshark) write out a capture with no secrets, 
> and then have another program (a utility, or Wireshark after having read in 
> the file and then given the secret in question) write out a new file with the 
> secrets early enough in the file ("before all the packet blocks" is probably 
> the simplest implementation).
>
> A producer that *does* happen to have the secret available before seeing any 
> packets that require the secret *could* write it directly.
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] compilation problem

[ronnie sahlberg]

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
> packet-ssl-utils.c `libgcrypt-config --cflags --libs`
>
> In returns it gives --
> ssikder@ssikder:~/Desktop/wireshark_source_code/epan/dissectors$
> packet-ssl-utils.h:29:18: fatal error: epan/packet.h: No such file or
> directory compilation terminated.
>
> Since the epan/packet.h file is available in the certain folder, although it
> could not find. it gives error.
>
> my question is regarding this scenerio...
>
> is one such specific file compilation valid ?
> is there any false command in my compilation ?
>
>
> Thanks in advance...
>
>
>
>
> Kind Regards,
>
> Samsuddin Sikder
>
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[ronnie sahlberg]

You can just disable relative sequence numbers in the preferences for tcp.


On Mon, Nov 17, 2014 at 9:38 AM, Matt  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 wireshark assumes base_seq == 0 to be an unitialized value, it
> triggers some error as wireshark tries to set again and again the base
> seq. Here is the output of a single 3WHS (custom printf), in peculiar
> in the 4th line, which is the ACK of the 3WHS, wiresharks sets
> base_seq =seq-1, ie 0-1 and it wraps the seq number (ugly).
>
> Setting base seq to : 0
> Setting base seq to : 0
> Setting rev base seq to : 0
> Setting base seq to : 4294967295
> Setting rev base seq to : 0
> Setting rev base seq to : 0
> Setting base seq to : 0
> Setting base seq to : 0
> Setting rev base seq to : 0
> Setting base seq to : 0
> Setting rev base seq to : 0
> Setting base seq to : 1
>
> I understand it seems a corner case but I don't believe have an ISN
> equal to 0 is forbidden by the RFC ?!
> I was wondering if I could add some boolean such as "base_seq_set" in
> mptcp_info_t to prevent such a behavior.
>
> Regards
> Matt
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[ronnie sahlberg]

My 5 cent :   I think they should be removed.



On Mon, Oct 6, 2014 at 12:03 PM, Bálint Réczey  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 you prefer removing this from the commit message?
> Guy raised the issue in https://code.wireshark.org/review/#/c/4438 ,
> but I think the question deserves more attention than being just a
> valid code-review comment.
>
> Cheers,
> Balint
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Qt License Change

[ronnie sahlberg]

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  wrote:
> http://blog.qt.digia.com/blog/2014/08/20/adding-lgpl-v3-to-qt/
>
> I don't *think* this affects us, but I haven't thought about it too hard.
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] How can Wireshark improve

[ronnie sahlberg]

On Sat, Apr 19, 2014 at 12:48 PM, Guy Harris  wrote:
>
> On Apr 19, 2014, at 12:24 PM, Richard Sharpe  
> 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 !=
>> NT_STATUS_SUCCESS"
>
> Presumably you mean "show me all the SMB2 transactions (requests and matching 
> responses) where the response returned an error".
>
> There's now a mechanism to, when saving filtered packets, save "related" 
> packets.  I think this was introduced to allow the earlier fragments/segments 
> of a reassembled packet to be saved, along with the final packet that matched 
> the filter, but in at least some cases somebody might want to save the 
> requests corresponding to replies that match the filter.
>
> So perhaps there should be a way to have a display filter show related 
> packets in addition to packets that match the packet-matching expression.

+100

Way back I added special code to the nfs dissector so that certain
filter fields would match both the request and the response. A kludge.
But it would be really nice to have a way to flag control that a match
will also match all related packets. And have it work for all
request/response protocols.

>
> However, there are multiple flavors of "related", and sometimes you might 
> want the corresponding requests but *not* other fragments/segments, and other 
> times you might want the other fragments/segments but *not* the corresponding 
> requests, and sometimes you might want both.

Yes.  I think in most cases you want to split packet relations up into
two buckets :
"packets are related because they form a request/reply (and or cancel) pair"
and
"packets are related for some other reason".

We could fix this by changing all request/response fields to a new
FT_REQUEST_REPONSE type.



> ___
> Sent via:Wireshark-dev mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[ronnie sahlberg]

Wireshark has lots of reverse engineered protocols. So that should not stop you.

For example, the whole CIFS/SMB family of protocols used to be reverse
engineered, eventhough now in later times the documentation to those
protocols are now available so errors in the decoding can be fixed.


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  wrote:
>
>> Without knowing the protocol, I'd say there's almost always room for
>> improvement.  Open a bug with a sample capture and see if someone can
>> figure out how to strengthen the check.
>
> Ok, thanks. I will open a bug request then.
>
>> ps. you mentioned your dissector is hosted on sourceforge; would you
>> consider submitting it to Wireshark?
>
> The dissector is of a proprietary protocol which is completely reverse
> engineered. There is no official documentation available.
> The protocol is used in programmable logic controlles by Siemens, I
> think the most common vendor in Europe for those controllers.
>
> I don't know if there are other reverse engineered protocols in
> wireshark, but for myself I would like when the delivered plugins with
> wireshark refer to official documents or rfcs, and not guessed as my
> dissector.
> Is there a official wireshark point of view?
>
> The website is:
> http://sourceforge.net/projects/s7commwireshark/
>
> There are some sample captures available.
>
> --
> Regards
> Thomas Wiens
>
>
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[ronnie sahlberg]

sgtm

On Fri, Feb 21, 2014 at 10:37 AM, Bill Meier  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 interesting.
>
> All the different protocols which run over tcp wouldn't need to be disabled
> to just show the payloads as 'data" (and not show things like "malformed"
> because some dissector mistakenly tries to dissect data).
>
>
> Thoughts ? Am i missing something ?
>
> (This might be a nice little project fpr me to learn QT ...).
>
>
> Bill
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[ronnie sahlberg]

On Wed, Feb 5, 2014 at 12:54 PM, Evan Huus  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 appear to be extracted from C code at some
> point in the past. We already have an 'ignore' rule set up for the
> whole "dtds/" directory, so I'm happy ignoring these as well unless
> there is some way we should be embedding license information in them?
>
> 'epan/dissectors/pidl/mapi/request.cnf.c'
> 'epan/dissectors/pidl/mapi/response.cnf.c'
>
> These two appear to be Ronnie's. They're not entirely C code so I'm
> not sure if embedding a license header is possible. Ronnie, I assume
> we're safe to add an exception for these as well?

Thank you for doing this work.
Yes, please add an exception.
Or, since the files do contain some code fragments, you can add a GPL header.


>
> 'epan/reedsolomon.h'
> 'epan/reedsolomon.c'
>
> These two simply say "May be used under the terms of the GNU public
> license" which presumably means GPLv1. I have not been able to find
> specific information on compatibility, but it appears that the GPLv1
> does not have an "or later" clause. This means we need to
> remove/replace/relicense it. I found another reed-solomon C library
> (http://sourceforge.net/projects/rscode/) but it's only available
> under the GPLv3+ which we also can't use. *sigh*. Anyone have any
> ideas?
>
> 'epan/dtd_grammar.h'
> 'epan/dfilter/grammar.h'
>
> These two are generated by lemon, so we can just add an ignore rule for them.
>
> 'doc/make-authors-short.pl'
> 'docbook/custom_layer_pdf.xsl'
>
> This two appear to have been written by Ulf Lamping. The latter is
> XML, not C, so (as with the DTD files above) I'm not sure what that
> means for its status.
>
> 'doc/make-authors-format.pl'
> 'doc/perlnoutf.pl'
>
> These two appear to have been written by Graeme Hewson.
>
> 'autogen.sh'
>
> The very first version was written by Gilbert Ramirez according to
> git, but it's undergone so many changes since then I'm not sure how we
> should attribute it...
>
> ---
>
> So it looks like the only potentially problematic one is going to be
> the reedsolomon code. The rest involve either tracking down the
> original author, or agreeing (eg for autogen.sh) that we should just
> add a GPLv2+ header and be done with it.
>
> Thoughts?
>
> Evan
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[ronnie sahlberg]

On Wed, Jan 15, 2014 at 3:10 PM, Joerg Mayer  wrote:
> commit b01a99c385bc80566cff9134f93b5d4680dd5a58
> Author: Martin Mathieson 
> Date:   Tue Jan 14 11:09:47 2014 +
>
> Provide hook for calling EEA1 implementation (Snow3G).  Implementation 
> not supplied due to licensing conditions.  TODO: EIA1.
>
> svn path=/trunk/; revision=54782
>
> This violates the GPLv2 requirement of not linking against code that is
> neither GPLv2 compatible nor a system library.
> This is not what open source is about. As long as we'd have any implementation
> that's GPLv2+ compatible with an identical API it would be fine to use another
> implementation, but code linking against a lib that doesn't exist is not 
> acceptable.

That matches my understanding too.
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[ronnie sahlberg]

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 defaults to the
current/RFC version) but where we can still switch back to obsolete
pre-rfc versions of the protocol.

in Kerberos5 we automatically support both a special pre-rfc1510
version of the protocol that is used by packetcable?  as well as the
rfc version of the protocol.
In that case there is no preference setting since it is trivial to
detect/handle the subtle differences at runtime.
(I think one field that is optional in pre-rfc1510 became a mandatory
field in rfc1510 and beyond.)




On Wed, Dec 18, 2013 at 10:33 AM, Evan Huus  wrote:
> This was originally filed as bug 9569. The situation is sufficiently
> unusual that I really don't know what the best solution is, so I
> figured I'd ask for general comments from the list. The company who
> created and used the TPNCP protocol (and submitted the packet-tpncp.c
> dissector) wants to reuse that name for a new, different protocol and
> are asking us to disable the old dissector to avoid conflicts. The bug
> has more detail.
>
> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9569
>
> Thoughts?
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[ronnie sahlberg]

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 dissectors (hello smb) has
some really huge value_strings for the response value.
Since a search across a linear valuestring is linear it would be nice
if it could also "bubble" frequent entries towards the head if the
array.



On Thu, Oct 10, 2013 at 4:51 PM, Evan Huus  wrote:
> On Thu, Oct 10, 2013 at 6:22 PM, Evan Huus  wrote:
>> It might be simpler and almost as efficient to have
>> recently-successful heuristic dissectors bubble nearer to the top of
>> the list so they are tried sooner. Port/conversation lookups are
>> hash-tables for the most part and likely won't be made noticeably
>> faster by caching.
>
> The attached trivial patch more-or-less implements the above idea. It
> isn't easy to bubble dissectors to the very head of the list because
> we don't have a modifiable pointer, but it was surprisingly easy to
> bubble them to *second* in the list, which should still be a
> substantial improvement if there are many expensive heuristics.
>
> I don't have any long heuristic captures that I can easily time, but
> I've run a few short ones and at least it doesn't seem to break
> anything.
>
> Let me know if it helps,
> Evan
>
>> On Thu, Oct 10, 2013 at 4:22 PM, Anders Broman  wrote:
>>> Hi,
>>> If we in the UDP/TCP/(SCTP?) dissectors saved next dissector on the first
>>> pas in say per packet data we could avoid
>>> repeated calls to heuristic dissectors and port/conversation lookups making
>>> the second pas faster.
>>> Does any one see any pitfalls with this idea?
>>>
>>> I can think of two ways of implementing it:
>>> - A new entry in pinfo "previous protocol" or something like that.
>>> or
>>> - make dissector_try_uint(), dissector_try_heuristic(),
>>> try_conversation_dissector() return the protocol
>>> or NULL;
>>>
>>> The second is perhaps cleaner but requires more changes or we could make new
>>> functions
>>> dissector_try_heuristic_ret_proto() etc or something like that.
>>>
>>> Comments?
>>>
>>> Regards
>>> Anders
>>>
>>>
>>> ___
>>> Sent via:Wireshark-dev mailing list 
>>> Archives:http://www.wireshark.org/lists/wireshark-dev
>>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Wireshark PIDL generated dissectors

[ronnie sahlberg]

The tool.
I think that wireshark has been used a de-facto fork for PIDL the tool
since many many years. But a fork that is occasionally synced back
with upstream.
That is the only way we can make sure that we will always be able to
even compile the IDL in wireshark to a working dissector.

On Mon, Oct 7, 2013 at 1:57 PM, Guy Harris  wrote:
>
> On Oct 3, 2013, at 8:04 PM, ronnie sahlberg  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 for samba and one for wireshark.
>>
>> Switching to samba PIDL seems to be a lot of work for miniscule gain.
>> And who will do the work?
>
> Are you referring to forking PIDL, the language, or to forking PIDL, the tool 
> that translates PIDL-the-language descriptions into code for 
> {Samba,Wireshark,...}?
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Wireshark PIDL generated dissectors

[ronnie sahlberg]

>What do you propose?

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 for samba and one for wireshark.

Switching to samba PIDL seems to be a lot of work for miniscule gain.
And who will do the work?


On Thu, Oct 3, 2013 at 7:58 PM, Andrew Bartlett  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 approach.
>
> Given Matthieu was working on generated dissectors only last week, it
> does not seem totally unreasonable.
>
> What do you propose?
>
> Andrew Bartlett
>
> --
> Andrew Bartlett
> http://samba.org/~abartlet/
> Authentication Developer, Samba Team   http://samba.org
> Samba Developer, Catalyst IT   http://catalyst.net.nz
>
>
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Wireshark PIDL generated dissectors

[ronnie sahlberg]

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,   wrote:
> The check_col function in the Wireshark source has been deprecated for
> awhile, but never officially removed.  I've been modifying the source
> (removing calls) so that it can be officially removed.  The last big hurdle
> was the DCE/RPC generated dissector files.  I've had a difficult time trying
> to regenerate the dissectors with the necessary modified source, so I just
> manually updated dissectors to mimic what the source should generate.
> Attached is a patch that contains the modifications to "PIDL source" that
> generates the dissector files (and not the dissector files themselves).  I
> couldn't tell from the Wireshark wiki [1] if this was maintained by samba or
> Wireshark, so now both will now have a copy, with the source already
> committed to Wireshark repository [3].
>
> Patch is also available in Wireshark bugzilla [3].
>
> Michael Mann
>
> [1] http://wiki.wireshark.org/Pidl
> [2] http://anonsvn.wireshark.org/viewvc?view=revision&revision=52313
> [3] https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8804
>
>
>
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Wireshark PIDL generated dissectors

[ronnie sahlberg]

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  wrote:
> On Tue, 2013-10-01 at 10:55 -0400, mman...@netscape.net wrote:
>> The check_col function in the Wireshark source has been deprecated for 
>> awhile, but never officially removed.  I've been modifying the source 
>> (removing calls) so that it can be officially removed.  The last big hurdle 
>> was the DCE/RPC generated dissector files.  I've had a difficult time trying 
>> to regenerate the dissectors with the necessary modified source, so I just 
>> manually updated dissectors to mimic what the source should generate.
>> Attached is a patch that contains the modifications to "PIDL source"
>> that generates the dissector files (and not the dissector files
>> themselves).  I couldn't tell from the Wireshark wiki [1] if this was
>> maintained by samba or Wireshark, so now both will now have a copy,
>> with the source already committed to Wireshark repository [3].
>>
>> Patch is also available in Wireshark bugzilla [3].
>>
>> Michael Mann
>>
>> [1] http://wiki.wireshark.org/Pidl
>> [2] http://anonsvn.wireshark.org/viewvc?view=revision&revision=52313
>> [3] https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8804
>
> PIDL is maintained by the Samba team, the canonical repository is in our
> master branch of git://git.samba.org/samba.git
>
> From the Samba perspective:
>
> I would warn that patching the generated code only passes the pain of
> fixing this properly down to the next person who needs to work here.
>
> As improvements are made to the IDL files or the parser, the generated
> files need to be re-generated, and then someone has the un-enviable
> choice of throwing away manual changes, or reverse engineering these
> back into the compiler.
>
> Even if you think you have modified them correctly to match your PIDL
> changes, please persevere to get the files re-generated using PIDL.
> Only then will we really know the generator generates the code
> correctly, and only then will the solution be long-term maintainable.
>
> Thanks,
>
> Andrew Bartlett
>
> --
> Andrew Bartlett
> http://samba.org/~abartlet/
> Authentication Developer, Samba Team   http://samba.org
> Samba Developer, Catalyst IT   http://catalyst.net.nz
>
>
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] OID list usage

[ronnie sahlberg]

Which oid list are you referring to exactly ?


On Thu, Sep 12, 2013 at 12:18 AM, Bart J. Smit  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)populates a database table by parsing the list on demand
> by the end user.
>
> I had a look for subscription/publication information in ask.wireshark.org,
> but did not find an answer to these questions:
>
> - Do you have a policy for data transfers from the OID list?
> - Do you have a preferred minimum interval between downloads?
> - Is there a mechanism that could alert list subscribers when there are
> updates?
> - Are incremental updates available?
>
> Thanks for your great work and for any answers you can give me,
>
> Bart...
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[ronnie sahlberg]

On Fri, Aug 9, 2013 at 9:02 AM, Richard Sharpe
 wrote:
> On Fri, Aug 9, 2013 at 8:52 AM, Christopher Maynard
>  wrote:
>> Richard Sharpe  writes:
>>
>>> I can across a capture yesterday where there were DNS queries for a
>>> KDC in a Windows AD environment. The query returned 230 KDCs!
>>>
>>> Searching for a particular one was hard.
>>>
>>> It would be nice to have a right click menu item in either the details
>>> pane or the data pane where you can search for a particular string (or
>>> chars or hex equivalent) and have the string highlighted in the data
>>> pane and the detail pane sync'd to that.
>>>
>>
>> Isn't there a filter you can use, such as: dns.qry.name == "The KDC name"?
>>
>> Alternatively, it seems you're referring to the Edit -> Find Packet (Ctrl+F)
>> functionality, combined with Edit -> Find Next (Ctrl+N) and/or Edit -> Find
>> Previous (Ctrl+B).  Is there something that feature doesn't provide that
>> you're looking for?
>
> Sure, I can do the search, and I did, but the actual info I am
> interested in, like the priority, etc, is buried among 230 entries and
> I have to patiently scroll until I find it.
>
> That is hard to do.

You can use
CTRL-F String/PacketDetails 
That should work for your use-casebut it would probably be even
better if the normal "Displayfilter" search would do it too, where
possible.
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[ronnie sahlberg]

On Fri, Aug 9, 2013 at 8:52 AM, Christopher Maynard
 wrote:
> Richard Sharpe  writes:
>
>> I can across a capture yesterday where there were DNS queries for a
>> KDC in a Windows AD environment. The query returned 230 KDCs!
>>
>> Searching for a particular one was hard.
>>
>> It would be nice to have a right click menu item in either the details
>> pane or the data pane where you can search for a particular string (or
>> chars or hex equivalent) and have the string highlighted in the data
>> pane and the detail pane sync'd to that.
>>
>
> Isn't there a filter you can use, such as: dns.qry.name == "The KDC name"?
>
> Alternatively, it seems you're referring to the Edit -> Find Packet (Ctrl+F)
> functionality, combined with Edit -> Find Next (Ctrl+N) and/or Edit -> Find
> Previous (Ctrl+B).  Is there something that feature doesn't provide that
> you're looking for?
>

I think he means something like this:

If you take the dns.cap sample capture from the wiki and then
CTRL-F * Display filter  dns.resp.ns == "ns-ext.sth1.isc.org"
It will bring you to frame #29 but it will not auto-select the field
in that packet. It just brings you to the packet in question.

On the other hand, IF you CTRL-F * string/packet-bytes sth1  it will
bring you to packet #29 and also highlight the first field there for
these bytes.
(Now DNS is special so you can not string/packet-bytes search for the
full name since due to dns compression will mangle the strings. You
can search for individual components though. But it is still
unreliable, it will find something and highlight something but maybe
not what you want)

However, what does work and what probably is what Richard can use is:
CTRL-F String/Packet-Details  ns-ext.sth1.isc.orgi.e. the full dns
name. This will find the right packet and will also automatically
select/highlight the right row in the display tree.



Display filters are harder since they might not map to a single hf
field when they match  (a==1 && b==2which of a or b should we
highlight?)
but we could special case CTRL-F Display-Filter so that IF the the
display filter consists of a single field then try to find and
highlight that specific field when jumping to the packet that matched.

thus CTRL-F Displayfilter  ip.addr==1.2.3.4 would find the first
ip.addr field and highlight it
but  CTDL-F DisplayFilter ip.addr==1.2.3.4 && tcp   would not work 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
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[ronnie sahlberg]

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 it very cheap, near zero cost for both allocations and free,
especially for a lot of small shortlived allocations.

This is important especially if you have really big captures  where
the original malloc()/free()  real allocators became impossibly slow.


On Thu, Jun 20, 2013 at 11:08 PM, Dirk Jagdmann  wrote:
>> C++. It snuck in with Qt. Should we allow C++ in the rest of the code or
>> at least use C++ compilation everywhere?
>
> A tough call. If we go C++ we should have a plan to use the STL classes with 
> our
> concept of memory (allocator scope). I've started a short discussion last 
> year,
> but somebody found out, that using STL objects on the heap with the C++
> allocators doesn't have the same semantics (and really doesn't work) with our
> packet or file lifetime scopes.
>
> However a second approach with C++ objects managed by smart pointers and those
> smart pointers being aware of the packet/file/application lifetime might work.
> We should research this, write guidelines how to use C++ objects in Wireshark
> and then make a decision if we want to allow C++ features everywhere.
>
> Another advantage would be that we can use real C++ exceptions.
>
> --
> ---> Dirk Jagdmann
> > http://cubic.org/~doj
> -> http://llg.cubic.org
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Jurassic packets

[ronnie sahlberg]

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  wrote:
> For Monday's Sharkfest keynote I wanted to show everyone what things
> looked like back in the early days of the project. After doing
> unspeakable things to a Red Hat 6.2 VM I managed to get a copy of
> Ethereal 0.2.0 up and running. Screenshot attached.
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] epan/dissectors/dcerpc/idl2wrs.c?

[ronnie sahlberg]

I say Delete it.

It is the original proof of concept hack I did before we switched to PIDL.

I abandoned this for PIDL in 2005  and should have deleted it then.



On Sat, Jun 1, 2013 at 3:03 PM, Guy Harris  wrote:
> Is that a functional translator from some flavor of DCE RPC IDL (OSF, 
> Microsoft, Samba PIDL) to a Wireshark dissector?
>
> If the IDL is PIDL, is it better than Samba's translator, inferior to Samba's 
> translator, or none of the above?
>
> Should we be building it with the autotools and with MSVC++, or should we 
> leave it out of the CMake build?  (I see no point in building it with some of 
> those but not others.)
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[ronnie sahlberg]

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, Rion Carter  wrote:
> Hi,
>
> I'm trying to extract raw bytes from a tvbuff_t and am not having much luck.
> As a simple test I have code which tries to extract the bytes and write it
> to a file. When I compile and run I get an output file with only 4 bytes in
> it when I know there is more (extracting certificates).
>
> Here is what I've got. Any help is appreciated:
>
> guint8* extracted = (guint8*)ep_tvb_memdup(tvb, 0, -1);
> fwrite(extracted, size of extracted), 1, file);
>
> It's been awhile since I used c file io, and I'm pretty new to Wireshark
> dev. I may be missing obvious or going about this in the wrong fashion.
>
> Rion
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[ronnie sahlberg]

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  wrote:
> This is a tangential issue that has always confused me.
>
> Why do we malloc+memcpy data for reassembly when we already have
> 'virtual' composite TVBs?
>
> Wouldn't it be more efficient (in time and memory) to create a
> composite TVB for each reassembly and then build the reassembled
> packet in it? You would never have to copy or allocate any actual
> packet data...
>
> Or am I misunderstanding how composite TVBs actually work?
>
> Thanks,
> Evan
>
> P.S. Clearly some protocols where the payload is XORed or hashed
> wouldn't be able to do this, but most protocols doing reassembly just
> carry the raw payload bytes.
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] SRP dissector for wireshark

[ronnie sahlberg]

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 things like conversations etc.
But this should be fairly straightforward.

SCSI dissector is called today from at least :
iSCSI, FCP, NDMP, USB,  and a handful of other layers too.


Have a look at the iSCSI dissector. I think that should be a good
example on how / what to track and how to invoke the SCSI dissection.





On Tue, Mar 5, 2013 at 1:09 AM, Carmel Bregman  wrote:
> Hello all,
>
>
>
> I’m working on a dissector for SRP (SCSI RDMA Protocol).
>
> I have the SRP header parsing complete and I have a short question:
>
>
>
> How do I parse CDB as SCSI cmd? I assume that this is done in FC but I
> couldn’t figure out how it’s done – can you help me here?
>
>
>
> Thanks,
>
> Carmel Bregman
>
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Packet Loss due to Disk Contention with Running Dumpcap in a high packet rate environment

[ronnie sahlberg]

How high bandwidths are we talking about here ?


Without going to expensive higher end storage, the fastest is probably
if you can use a dedicated disk and stream directly to the raw disk.
This should avoid any of the seeks that a filesystem would induce when
writing to both file, journal and the fs metadata.
And should allow you to capture at near the peak sequential write
speed of your spindle.


regards
ronnie sahlberg



On Wed, Dec 12, 2012 at 11:33 AM, John Powell  wrote:
> Hi Everyone,
>
> I am using DUMPCAP to capture packets in a high packet rate environment.
>
> My operating system is: CENTOS 6.3
>
> I am experience this problem on source compiled versions:  wireshark-1.6.12
> and wireshark-1.8.4.
>
> In order to allow DUMPCAP to be run as a NON-ROOT user I am using the
> following:
>
> setcap 'CAP_NET_RAW+eip CAP_NET_ADMIN+eip' /usr/local/bin/dumpcap -v
>
> The issue is that I am experiencing packet loss to apparent disk contention
> when writing the packets to the disk - see attached file:
> packet-loss-atop.txt
>
> To help alleviate the problem I have tried the following:
>
> Disabled SELINUX
> Disabled AUDIT
> RAID 0 (striped disks) to load share the writing out of the data
>
> ARRAY /dev/md2 level=raid0 num-devices=2
>devices=/dev/sda4,/dev/sdb4
>
> Turn off journals on ext4
>
> tune2fs -o journal_data_writeback /dev/md2
> tune2fs -O ^has_journal /dev/md2
> change fstab to:
>
> UUID=.. /data   ext4defaults,data=writeback 0 0
>
> Use -B option on Dumpcap to buffer the data
>
> root  /usr/local/bin/dumpcap -B 16 -i 2 -f vlan and (not vrrp and not
> udp port 1985 and not ether host 01:00:0c:cc:cc:cc) -g -b filesize:25 -b
> duration:900 -w /data/eth1.cap
>
> These changes have increased the throughput but I still experience packet
> loss - see attached IO Graph: packet-loss-io-graph.jpg
>
> The Vendor solutions we have looked at will not decode UNISTIM signalling
> properly which is requirement for this tool.
>
> Any suggestions on how to better configure either the operating system or
> wireshark to increase packet capture throughput will be greatly appreciated.
>
> Thanks in advance for your assistance.
>
> -John
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

wireshark-dev@wireshark.org

[ronnie sahlberg]

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
 wrote:
> Hi,
>
> Attached is a patch to handle extended responses for NTCreate&X
> requests for CIFS.
>
> I have tested this patch with captures I have and it seems to decode
> the additional information correctly.
>
> Could someone with commit privileges either push it or let me know
> what changes are needed please?
>
> --
> Regards,
> Richard Sharpe
> (何以解憂？唯有杜康。--曹操)
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Conversation tracking

[ronnie sahlberg]

Tobias,
below

On Sat, May 12, 2012 at 2:25 AM, Tobias Weiss  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 
> first stage have a fixed length (4 byte) and the packets of the second stage 
> can have an arbitrary length but with a fixed header (8 bytes).

Ok so the sequence for the protocol would then be something like

TCP session setup
1 or more stage 1 PDUs
1 or more stage 2 PDUs
TCP session closure

and this applies to both directions of the TCP session?

>
> Unfortunately the content of a 4 byte frame can be the beginning of the 8 
> byte header. So I have to figure out where stage 1 ends and stage 2 starts. 
> But as the payload of one TCP frame can contain the last stage 1 frame(s) and 
> the first stage 2 frame, this is not straightforward. So my idea was to do 
> this just once with the first packet and save the state in the conversation 
> data and subsequently reuse that information. Because detecting the end of 
> stage 1 is pretty easy if you know where you are in the stream.
>
> And now I'm not sure if something like this could happen within the same 
> conversation:
>
> TCP connect -> stage 1 frames -> stage 2 frames -> TCP disconnect -> TCP 
> connect -> stage 1 frames -> stage 2 frames
>
> In this case I cannot just save the packet number where stage 1 ends if my 
> dissector gets the same conversation for multiple connects/disconnects.
>

In this case this would be logged as two separate conversations, so
that should not be a problem.
But packet number alone might not be sufficient anyway since as you
say the transition from stage 1 to stage 2 is never guaranteed to be
on a tcp segment boundary.


What I would suggest here is that you create a conversation,
then attach a special state structure to this conversation that
contains something like

struct stage_transition {
 intframe ;   // packet number where stage 1 - > 2 transition occured
 intoffset;// offset into the data of that frame where the
transition occured
}

Attach two of these structures to the conversation, one for each
direction of the tcp flow.
Create some mechanism to be able to determine "direction" to know
which one to pick.
Perhaps "high portnumber -> low portnumber == forward"  and "low port
number -> high portnumber == reverse" ?

When initially reading the capture file (pinfo->fd.flags.visited == 0)
  you build and track these structures.
When you re-filter or re-process the packet (pinfo->fd.flags.visited
!= 0) you just read from these structures.





> Tobi
>
>
>
> "RUOFF, LARS (LARS)" 
> Sent by: wireshark-dev-boun...@wireshark.org
>
> 05/11/2012 11:33 AM
>
> Please respond to
> Developer support list for Wireshark 
>
> To
> Developer support list for Wireshark 
> cc
> Subject
> Re: [Wireshark-dev] Conversation tracking
>
>
>
>
>
> Hi Tobi,
> I don't understand your concern. (but that may be due to my weird 
> understanding of English)
> If those packets are part of the same stream, i.e. they are being identified 
> as belonging to the same conversation (by whatever means, eg adress-port 
> mapping etc.), then the whole point of conversation tracking is that you will 
> get the *same* conversation object for all those packets.
> So you can store things in there and retrieve them when dissecting another 
> packet of that same conversation.
>
> Regards,
> Lars
>
>
>
> 
>
> From: wireshark-dev-boun...@wireshark.org 
> [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Tobias Weiss
> Sent: vendredi 11 mai 2012 16:30
> To: Developer support list for Wireshark
> Subject: Re: [Wireshark-dev] Conversation tracking
>
>
>
> Right now I'm puzzled: I wanted to use conversation tracking in order to save 
> information about the state of the communication across packet dissection.
>
> The dissector is called completely out of order (which is reasonable) but I 
> get always the same conversation, even when dissecting an older packet than 
> the last one. So saving the state of the communication is completely 
> pointless if the same conversation is used for dissecting random packets. 
> Here is an example just in case you don't understand my possibly weird 
> English ;-)
>
> I have a stream of 10 packets and something interesting was send in packet 
> number 3. Now I want to save this information in the conversations data in 
> order to reuse it when dissecting future packets. But the dissector is called 
> randomly (which is ok) but always with the same conversation (which is 
> absolutely not ok in this case).
>
> I simply cannot rely on the saved information. So how am I supposed to use 
> conversation tracking in a sane way (as far as I can see I can't _track_ 
> anything)???
>
> Tobi
>
>
>
>
> Tobias Weiss 
> Sent by: wireshark-dev-boun...@wireshark.org
>
> 05/10/2012 06:03 PM
> Please respond to

Re: [Wireshark-dev] Regarding wireshark design

[ronnie sahlberg]

Perhaps the answer can be found in the documentation ?


On Thu, May 10, 2012 at 9:28 PM, Singh, Anand  wrote:
> Hi,
>                Can you please let me know how does it talk with raw packets. 
> Is it using existing TCP stack or is it directly communication with lower 
> 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:29 PM
> To: Developer support list for Wireshark
> Subject: 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  
> wrote:
>> Hi,
>>
>>   Can anyone give me thorough reference on how exactly
>> wireshark work while displaying packet on linux. Where do I start to
>> get insights of design of wireshark. What is the code flow, from which
>> file I start browsing the code. I will greatly help me understand
>> wirshark existing code & enhance the code for my usage.
>>
>>
>>
>> Regards
>>
>> Anand
>>
>>
>>
>>
>>
>> P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.
>>
>> This e-mail (including any attachments) is confidential and may be
>> legally privileged. If you are not an intended recipient or an
>> authorized representative of an intended recipient, you are prohibited
>> from using, copying or distributing the information in this e-mail or its 
>> attachments.
>> If you have received this e-mail in error, please notify the sender
>> immediately by return e-mail and delete all copies of this message and
>> any attachments. Thank you.
>>
>>
>> __
>> _ Sent via:    Wireshark-dev mailing list
>> 
>> Archives:    http://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>
>> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
> ___
> Sent via:    Wireshark-dev mailing list 
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>             mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
>
>
> ___
> Sent via:    Wireshark-dev mailing list 
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>             mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Regarding wireshark design

[ronnie sahlberg]

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  wrote:
> Hi,
>
>   Can anyone give me thorough reference on how exactly
> wireshark work while displaying packet on linux. Where do I start to get
> insights of design of wireshark. What is the code flow, from which file I
> start browsing the code. I will greatly help me understand wirshark existing
> code & enhance the code for my usage.
>
>
>
> Regards
>
> Anand
>
>
>
>
>
> P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.
>
> This e-mail (including any attachments) is confidential and may be legally
> privileged. If you are not an intended recipient or an authorized
> representative of an intended recipient, you are prohibited from using,
> copying or distributing the information in this e-mail or its attachments.
> If you have received this e-mail in error, please notify the sender
> immediately by return e-mail and delete all copies of this message and any
> attachments. Thank you.
>
>
> ___
> Sent via:    Wireshark-dev mailing list 
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>             mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Wireshark compile options

[ronnie sahlberg]

CFLAGS="-pg" ./configure

should do the trick


On Sun, Mar 4, 2012 at 3:14 PM, James dsouza  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 build it with this option? I am not sure in which Make file and where
> I should add this option. Thanks in advance.
>
>
>
>
>
> ___
> Sent via:    Wireshark-dev mailing list 
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>             mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[ronnie sahlberg]

Hi Stefan.



Wireshark supports a lot more than just SCSI over iSCSI

It dissects SCSI over USB, FCOE, raw-FC, FCIP, iFCP (I never got
access to traces for mFCP :-( )   and also over NDMP.
I never got access to HyperSCSI traces either, so that is missing too.

Since I never got HyperSCSI or mFCP (very short-lived attempt from HBA
vendors)  those two are the only ones today I think where we miss
decode.
virt-scsi from QEMU sounds interesting!





SCSI has a very well defined API in wireshark  so assind a new
transport should be trivial.

I have done so several times.


First you need a DLT value from the tcpdump folks to wrap your packets in.
Once you have that  it should be semi-trivial to hook the
SCSI-dissector into your transport/DLT


Depending on what the framing looks like, you need at least a wrapper
around the SCSI payload that can contain
an I_T identifier, then  a LUN field, and then scoped per LUN you need
a task-tag or similar.
Wireshark would need I_T to be able to track initiators and targets
separately and form a "conversation" between an arbitrary pair.
A LUN identifier to track different luns on the same I_T separately.
Finally it also needs a task-tag so that on a specific ILT nexus it
will be able to match a SCSI CDB with DATA-IN/OUT blobs and a SCSI
response/sense

to make it map well  you might need to wrap thing inside a

struct scsi_wrapper {
initiator identifier
target identifier
lun
task-tag
opcode (cdb, datain, dataout, response/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  wrote:
> Wireshark today supports SCSI dissectors for iSCSI.
>
> In the QEMU system emulator we have an emulated SCSI target which
> handles devices for SCSI Parallel Interface (SPI), USB Mass Storage
> Device, and now supports the new virtio-scsi transport (for efficient
> virtual machine SCSI I/O).
>
> Cong and I would like to add pcap support to the emulated SCSI target
> in QEMU, making it easy to use Wireshark for SCSI debugging and
> analysis.  I'm looking for advice on getting started because we are
> not familiar with Wireshark/dissector internals.
>
> I believe the SCSI dissector does not support raw CDB dissection - it
> requires a SCSI transport dissector (currently iSCSI).  A few options
> come to mind:
>
> 1. Change the SCSI dissector to support top-level dissecting of raw
> SCSI CDBs without transport information (initiator, target, and other
> metadata).
>
> 2. Add virtio-scsi and perhaps SPI SCSI transport dissectors.
>
> 3. A simpler approach I'm missing? :)
>
> Suggestions appreciated.
>
> Stefan
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[ronnie sahlberg]

I am ok with putting the presentation on the wiki.


On Thu, Jan 19, 2012 at 1:37 AM, Jeff Morriss  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
> showing some of the cool things you can do with Wireshark. Unfortunately the
> link has since gone bad.
>
> I happen to have a copy of the presentation locally (I had referred to it in
> some internal training I did).  Would it be acceptable to attach it to the
> wiki?
>
> The presentation says at the bottom:
>
>> Storage Developer Conference 2008
>> © 2008 Insert Copyright Information Here. All Rights Reserved.
>
>
> Or would it be a bad precedent to start attaching potentially large files
> there?
>
> Regards,
> -Jeff
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[ronnie sahlberg]

Make each of them an expansion
and show the generic ".node" field inside the expansion with a help
blurb of "matches either sender or receiver"
?

Wireshark has a 5 digit number of filterable fields already   so for
users to find that a certain field exists and can be used is "tricky".
Unless your 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  wrote:
> Hi
>
> Ok, always ready to learn something new, but answer me this:
>
>  You have two fields displayed, in my case:
>
> Sender: 0x0001
> Receiver: 0x0002
>
> How do you add a generated field, which will match either one of these
> entries, so that you can ask:
>
> opensafety.msg.node == 0x0002
>
> and only receive messages where either the Sender or the Receiver
> field has the value 0x0002 ?
>
> Using generated fields, just clobbers up the display in such a case,
> because you would have to have 2 entries for [Node] which confuses the
> user. Or am I overlooking some special usage of generated fields here?
>
> One definite negative side-effect of using hidden fields is of course,
> that you can not use the "Apply as .." or "Prepare as .." entries, and
> that the user has to know about them. But that was already mentioned
> earlier.
>
> regards,
> Roland
>
>
> On Mon, Oct 31, 2011 at 11:03 AM, Anders Broman
>  wrote:
>> Hi,
>> I'd say using a generated field is more elegant :-)
>> /Anders
>>
>> -Original Message-
>> From: wireshark-dev-boun...@wireshark.org 
>> [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Roland Knall
>> Sent: den 31 oktober 2011 10:51
>> To: Developer support list for Wireshark
>> Subject: Re: [Wireshark-dev] Is it still ok to create hidden items ?
>>
>> Hi
>>
>> As I just came across something regarding this issue, there is a counter 
>> argument to the whole "if it is not there, the user may not find it" idea. 
>> Looking at the way the IP dissector is used, hidden fields have their 
>> merits. ip.addr is a more generic way of avoiding ( ip.src == x || ip.dest 
>> == x ). I plan to use it in the same way in the openSAFETY dissector, where 
>> I have the fields opensafety.msg.sender and opensafety.msg.receiver, and I 
>> am currently implementing a opensafety.msg.node matching either one.
>>
>> The most elegant solution for such a case is still using hidden fields.
>>
>> regards,
>> Roland
>>
>> On Thu, Oct 27, 2011 at 4:04 PM, Teto  wrote:
>>> Thanks for both of your ideas. What bothers me with Michaels'idea is
>>> that I wonder how many wireshark users know of or use "contains" and
>>> "matches" compared to eq or == keywords. From that point of view,
>>> Jeff's idea looks as a good idea.
>>>
>>> On Thu, Oct 27, 2011 at 3:34 PM, Jeff Morriss  
>>> wrote:
>>>>
>>>> Teto wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Just had a question about what's the best practice. I have a packet
>>>>> with a field contianing several keywords. I intend to split those
>>>>> keywords so that one can filter display based upon a keyword.
>>>>> My problem is am compelled to display each keyword separately (one
>>>>> itemp per kewyord and group them in a subtree) or could I display
>>>>> all of them in one item in the main tree (my preference) and then
>>>>> create several hidden fields (one per keyword). I wonder if that
>>>>> last
>>>>
>>>> Why not combine the two?  Put one item (or maybe even just a text 
>>>> entry--from proto_tree_add_text()) with all the keywords (possibly added 
>>>> with proto_tree_append_text()) and then create a subtree below that with 
>>>> each keyword individually?
>>>>
>>>> This is how we get, for example, nice summary lines for the TCP protocol 
>>>> (including port numbers, etc.) while keeping the port numbers themselves 
>>>> as separate filterable items in the TCP subtree.
>>> __
>>> _ Sent via:    Wireshark-dev mailing list
>>> 
>>> Archives:    http://www.wireshark.org/lists/wireshark-dev
>>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>>
>>> mailto:wireshark-dev-requ...@wireshark.org?subjec

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

[ronnie sahlberg]

Hi,

I think one of the reasons why one should avoid hidden items is that
if they dont
show up in the dissect pane, users might not be aware that they exist at all.
And then they will not be able to use them.

Wireshark supports so very many different filter fields that it is not
practical to use 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


On Thu, Oct 27, 2011 at 8:54 PM, Teto  wrote:
> Hi,
>
> Just had a question about what's the best practice. I have a packet
> with a field contianing several keywords. I intend to split those
> keywords so that one can filter display based upon a keyword.
> My problem is am compelled to display each keyword separately (one
> itemp per kewyord and group them in a subtree) or could I display all
> of them in one item in the main tree (my preference) and then create
> several hidden fields (one per keyword). I wonder if that last
> solution is good since I read in proto.h :
> /* HIDING PROTOCOL FIELDS IS DEPRECATED, IT'S CONSIDERED TO BE BAD GUI
> DESIGN! */
>
> What would you advise me ?
>
> Matt
> ___
> Sent via:    Wireshark-dev mailing list 
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>             mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[ronnie sahlberg]

I think registering a destructor for an allocated is very useful, but
it would be very uncommon.
Most allocations never need a destructur, so it shouldnt be made
mandatory in the allocation functions.

So instead of creating a new API for allocations with a destructor I
would suggest adding a new _add_destructor call instead.
That way you can add destructors to existing objects after they are
allocated, post allocation time.


something like :

object = se_alloc(...);
se_set_emem_destructor(object,  void (*your_callback)(void
*object), void *private_data);


Then this can just add the destructor to a linked list of
struct se_destructors {
struct se_destructors *next;
void *object;
void *private_data;
void (*callback)(void *object, void *private_data);
};


I threw a private_data pointer in there too.
Once you have callbacks you almost always enbd up wanting 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  wrote:
> 2011/5/2 Guy Harris :
>>
>> A separate "cleanup" routine, called when the capture is closed, *before* 
>> the se_allocated memory is freed, might be useful...
>
> Do you mean separate as global? I.e. with setup code like
>
>  register_se_cleanup_callback(my_module_cb);
>
> ?
>
> --
>  Max
> ___
> Sent via:    Wireshark-dev mailing list 
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>             mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[ronnie sahlberg]

You should be able to either build a statically linked version of wireshark,
or copy the normally built dynamically linked version as well as the
various shared libraries wireshark comes with and just wrap it inside
a small shell-script that sets the LD_LIBRARY_PATH so that ld.so can
find 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  wrote:
> I have been tasked to come up with a Wireshark configuration that can sit on
> a USB thumb drive and get plugged into a Linux system and run.
>
> The building would, obviously, take place on a separate platform.  All I
> would need on the "thumb" is the actual executables.
>
> I looked through the official documentation, and it wants me to "install"
> Wireshark onto the system I want to run it on.
>
> There is a Portable Wireshark for the Microsoft operating systems.  Can the
> same thing happen for Linux ?
> ___
> Sent via:    Wireshark-dev mailing list 
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>            mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Query

[ronnie sahlberg]

rfc 791 and 792


On Fri, Dec 31, 2010 at 4:52 PM, prathiba meenu  wrote:
> Hi,
> Could you please tell what are all the things needed to calculate checkum of
> ICMP and ICMPv6?
>
> --
> Thanks & Regards,
> Prathiba.H
>
> ___
> Sent via:    Wireshark-dev mailing list 
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>             mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[ronnie sahlberg]

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  wrote:
> Can I use something like tcp_dissect_pdus() for UDP packets? Specifically,
> Kerberos over UDP - I think we can get the PDU length from the packet and
> get a complete PDU.
>
> ___
> Sent via:    Wireshark-dev mailing list 
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>             mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[ronnie sahlberg]

Yeah

The scsi dissector does need some tlc
to clean up and to harmonize the dissection according to the latest
versions of the standard.

For handling flags,
you may want to look at some examples such as

...
   static const int *aca_fields[] = {
&hf_scsi_inq_aerc,  /* obsolete in spc3 and forward */
&hf_scsi_inq_trmtsk,/* obsolete in spc2 and forward */
&hf_scsi_inq_normaca,
&hf_scsi_inq_hisup,
&hf_scsi_inq_rdf,
NULL
};
...
/* aca flags */
proto_tree_add_bitmask(tree, tvb_v, offset_v,
hf_scsi_inq_acaflags, ett_scsi_inq_acaflags, aca_fields, FALSE);
offset_v+=1

which can simplify creating/dissecting bitfields.



this would be a reasonable summer of code project for a student,
go through all of spc/sbc/ssc/smc/mmc and update wireshark accordingly.
at the same time, and to have 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
 wrote:
> On Sat, Dec 4, 2010 at 6:29 AM, Chris Maynard  wrote:
>> Richard Sharpe  writes:
>>
>>> If there are any suggestions for other changes, let me know.
>>
>> Hi Richard.  It looks like there are other bit-oriented fields besides
>> hf_scsi_control that could benefit from this as well: hf_scsi_inquiry_flags,
>> hf_scsi_modesel_flags, ...
>>
>> There also seem to be a lot of proto_tree_add_text() calls (I count 186 of
>> them).  I haven't looked at them all, but I suspect most would be better 
>> added
>> using proto_tree_add_item() so those fields could be filterable as well.
>>
>> I saw that you posted a patch on Thursday.  Could you open up a bug report 
>> and
>> submit the patch(es) there instead?  I think it will make it easier to track 
>> and
>> the patches won't get lost.  Thanks.
>>
>
> I created bug https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5466
> for this since it has nothing to do with iSCSI...
>
> The patch I first posted needs reworking so I will not attach it yet.
>
> I will attach patches as I get make changes.
>
> --
> Regards,
> Richard Sharpe
> ___
> Sent via:    Wireshark-dev mailing list 
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>             mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[ronnie sahlberg]

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  wrote:

> sahlb...@wireshark.org wrote:
> > http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=34269
> >
> > User: sahlberg
> > Date: 2010/09/27 08:31 PM
> >
> > Log:
> >  The array sminmpec_values should not be declated static since it is
> >  referenced from several dissectors
> >
> > Directory: /trunk/tools/
> >   ChangesPathAction
> >   +1 -1  make-sminmpec.plModified
> >
>
> I thought I fixed all the references (to use sminmpec_values_ext instead
>  of sminmpec_values).
>
> Did I miss some ?? :)
>
> Bill
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[ronnie sahlberg]

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 also shouldnt hardcode the size of the array in the for loop like
that,   use something like  sizeof[ports] / sizeof(ports[0])
instead.



On Tue, Mar 23, 2010 at 9:30 AM, Brian Oleksa
 wrote:
> Olivier
>
> Yes...looks like I do. Any thoughts on how I can fix this..??
>
> Thanks,
> Brian
>
> void proto_reg_handoff_helen(void) {
>    static gboolean initialized = FALSE;
>
>    int i;
>
>    for (i = 0; i < 25; i++) {
>
>        if (!initialized) {
>            data_handle = find_dissector("data");
>            helen_handle = create_dissector_handle(dissect_helen,
> proto_helen);
>            dissector_add("udp.port", ports[i], helen_handle);
>        }
>    }
>    initialized = TRUE;
> }
>
>
>
> wsgd wrote:
>> Perhaps you call create_dissector_handle for each port ?
>>
>> Olivier
>>
>> Brian Oleksa a écrit :
>>
>>> Guy
>>>
>>> Actuallythis is what I am doing:
>>>
>>> dissector_add("udp.port", ports[i], helen_handle);
>>>
>>> Where ports has a list of port numbers in it.
>>>
>>> static int ports[25] = {5136, 5000, 5220, 42250, 5, 5221, 5222,
>>> 49901, 49501, 49510, 42251, 42250, 5226, 47001, 5227, 7636, 59201,
>>>     59202, 59203, 59204, 59205, 59206, 59207, 59209, 59210};
>>>
>>> Is this a problem..??  How do I get around this..??
>>>
>>> Thanks,
>>> Brian
>>>
>>>
>>>
>>> Guy Harris wrote:
>>>
>>>
 On Mar 22, 2010, at 1:04 PM, Brian Oleksa wrote:




> When I right click on a packet and select decode asunder the
> transport tab... there is like 14 of my protocols in the selection box.
> (so I see the word HELEN 14 times in a row)
>
> Does anybody know why this is..??
>
>
>
 You're only calling dissector_add() or dissector_add_handle() once, right? 
  You're not calling it, for example, every time a preference is set?
 ___
 Sent via:    Wireshark-dev mailing list 
 Archives:    http://www.wireshark.org/lists/wireshark-dev
 Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
              mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe



>>> ___
>>> Sent via:    Wireshark-dev mailing list 
>>> Archives:    http://www.wireshark.org/lists/wireshark-dev
>>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>>              mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
>>>
>>>
>>>
>>>
>>
>>
>>
> ___
> Sent via:    Wireshark-dev mailing list 
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>             mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] INTERLINK dissector plugin added

[ronnie sahlberg]

On Tue, Mar 16, 2010 at 8:13 PM, Joerg Mayer  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
>> used in BMW cars (real and simulated) for all kinds of gadget communication
>> (for example to and from the combination display or the iDrive). I assume 
>> only
>> a few engineers at BMW will ever use this, so I added the dissector as a 
>> plugin.
>>
>> I prepared a table for sub-dissectors for particular type/version 
>> combinations
>> but did not add any. Hopefully some BMW engineers will fill this part later 
>> on.
>
> And of course: Where do I get the sniffer hw so I can actually do the
> sniffing :-)
>


At the same place where you give a guy 50$ so he can add 20k km to the
odo for your tax rebate enjoyment.
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] preliminary code submission

[ronnie sahlberg]

Any particular reason this is not licensed under GPL?


I am not sure that this licence is compatible with GPLv2 which may
hinder its inclusion into wireshark.
It is not known to the gpl folks and thus not explicitely listed as
gpl compatible.
http://www.gnu.org/licenses/license-list.html


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 11, 2010 at 9:33 AM, Brian Oleksa
 wrote:
> Chris
>
> Thanks for all the great advice. Attached is the updated code based on some
> of your suggestions.
>
> Per your suggestions:
> I have registered the port that my dissector is using with IANA.
> I have added my companies license info at the top of my dissector.
> I put the handoff and register routines at the bottom.
> I have defined a value_string constant for the gpsStatus.
>
> You mentioned that the helen_sub_item assignment is not needed.
> I have not removed it yet. All this displays is that it is a helen packet as
> it does start with 0xbead.
> I guess your thoughts are that I do not need to display 0xbead..?? I can
> easily move this ...but I just wanted to get your thoughts on why you think
> I should not display this.
>
> I also tried to replace FT_ABSOLUTE_TIME with FT_UNIT64 and replace the
> proto_tree_add_time_format with the add_unit_format that you provided but I
> ended up with the following error.
> conversion from guint64 to guint32 possible loss of data.
> But I cannot seem to locate the different value declarations.
>
> Codes:
> You mention that there is a number of Helen Packet Codes that I am not
> supporting in my dissector yet. These "extra" codes are for "add ons" or
> what we call "plugins" to the Minotaur SA application.
> For now... We just want to support the core Minotaur SA extensions which are
> (GPS, Flow and Host). Once this code is submitted and a part of the core
> wireshark distribution we will submit patches to add these other "codes".
> Right now... these extra codes are subject to change.
>
> I did however add the range_string helen_code[]...but I am not 100% sure how
> to rip out my switch/case to replace it with your suggestion.
>
> I have alot of your suggestions in my code...but I either commented it out
> or am not using it.
>
> You also mentioned the following (see CHRIS MAYNARD WROTE:)...but I was
> having a bit of a problem following exactly what you are saying here.
>
> Thanks for the help.,
> Brian
>
> CHRIS MAYNARD WROTE:
>
> So you're missing a lot of the codes, but even the codes that you currently
> do support seem to be lacking.  Take for example the GPS Extension:  First
> off, you don't populate the "Fields Available" field at all.  It should be
> added to the helen tree then sub-treed with the bits comprising it (i.e.,
> have its own ett so it can expand independently of other trees).  It's nice
> to have a 1-line summary of all bitfields so you don't necessarily have to
> expand the tree to decipher which bits are set.  The Boolean bits themselves
> are usually populated from msb to lsb, although the fields indicated must be
> populated according to the "spec".  Unfortunately, the Helen "spec" is
> ambiguous in this regard.  Here's an example of what the tree could look
> like as I describe (I assume the fields are added according to lsb to msb
> based on your implementation, but I indicate which fields are present from
> msb to lsb, as this yields a left-to-right expansion of the tree, which is
> what you normally see.):
>
> Not expanded, you would see:
>
> + Fields Available: 0x61 (speed, bearing, status)
>
> And when expanded, you would see:
>
> - Fields Available: 0x61 (speed, bearing, status)
>  0... = Number of Satellites: Not Present
>  .1.. = Speed: Present
>  ..1. = Bearing: Present
>  ...0 = Altitude: Not Present
>  0... = Latitude: Not Present
>  .0.. = Longitude: Not Present
>  ..0. = Time: Not Present
>  ...1 = Status: Present
>
>
>
>
>
>
>
>
> Maynard, Chris wrote:
>>
>> Hi Brian,
>>
>> I found some (the?) documentation on Helen here:
>> https://www.darkcornersoftware.com/confluence/display/open/Packet+Structure.
>>  I have no idea if this is the definitive Helen specification or not, but
>> based on the documentation, here is some additional feedback:
>>
>> Header:
>> This 1st assignment of helen_sub_item is not needed:
>>        helen_sub_item =

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

[ronnie sahlberg]

metze
great patches, as usual.


applied, thanks.



On Sat, Jan 30, 2010 at 1:10 AM, Stefan (metze) Metzmacher
 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
>
> ___
> Sent via:    Wireshark-dev mailing list 
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>             mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[ronnie sahlberg]

ouch,   it is partially machinegenerated!

when did that happen ? :-)


On Wed, Jan 27, 2010 at 7:30 PM, ronnie sahlberg
 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 with a slightly different
> asn, used by packetcable)
>
>
> The vast majority of the code in apcket-kerberos.c is not really the
> actual pdu definitions as of 1510
> but things likes vast numbers of microsoft (and other) extensions to
> various fields.
>
> value strings   that are not defined in 1510
>
> and of course, the whole decryption code   and microsoft PAC code.
>
>
> Since the packetstructure in rfc1510 is such a very small part of
> packet-kerberos.c  I dont think 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, Stephen Fisher
>  wrote:
>> I've started working with Kerberos at work, and I was analyzing packets
>> with Wireshark when I noticed that a number of the packet detail field
>> names are pretty terse.  Is packet-kerberos.c written by hand, generated
>> with ASN.1 or both?  I'm guessing both.  Is there a move to change it to
>> entirely one way or the other?  I was wanting to expand some field names
>> for things such as cusec.  I realize that hf_krb_cusec has a description
>> for the status line of "micro second component of client time" but I
>> still think that cusec could be expanded in the details pane.  Maybe
>> something like "Client microseconds" or "Microseconds" under a Client
>> tree title.
>>
>>
>> Steve
>>
>> ___
>> Sent via:    Wireshark-dev mailing list 
>> Archives:    http://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>             mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
>>
>
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[ronnie sahlberg]

packet-kerberos.c is handwritten.

packet-kerberos contains a whoole lot more than just rfc1510
(it even handles a pre rfc version of 1510 with a slightly different
asn, used by packetcable)


The vast majority of the code in apcket-kerberos.c is not really the
actual pdu definitions as of 1510
but things likes vast numbers of microsoft (and other) extensions to
various fields.

value strings   that are not defined in 1510

and of course, the whole decryption code   and microsoft PAC code.


Since the packetstructure in rfc1510 is such a very small part of
packet-kerberos.c  I dont think 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, Stephen Fisher
 wrote:
> I've started working with Kerberos at work, and I was analyzing packets
> with Wireshark when I noticed that a number of the packet detail field
> names are pretty terse.  Is packet-kerberos.c written by hand, generated
> with ASN.1 or both?  I'm guessing both.  Is there a move to change it to
> entirely one way or the other?  I was wanting to expand some field names
> for things such as cusec.  I realize that hf_krb_cusec has a description
> for the status line of "micro second component of client time" but I
> still think that cusec could be expanded in the details pane.  Maybe
> something like "Client microseconds" or "Microseconds" under a Client
> tree title.
>
>
> Steve
>
> ___
> Sent via:    Wireshark-dev mailing list 
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>             mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[ronnie sahlberg]

I have checked in the wireshark patch in anticipation for the pidl patches.


One nice thing that this allows is that we may soon be able to use
pidl to describe a whole lot of additional, normal,
protocols, just like the samba project already does.


I would like to experiment creating such a dissector and document the
process later for the wireshark project for use.


One nice thing is that PIDL is an actively supported and maintained
tool to do exactly that. A single language to describe several types
of protocols.




On Wed, Jan 20, 2010 at 10:33 AM, Julien Kerihuel
 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
>> so they wont collide with your patch.)
>>
>>
>> This patch can be applied right now, in anticipation of adding the
>> pidl patches later.
>
> Ronnie,
>
> Thanks I was looking for a correct place to initialize the variable.
> The new version of the patch is attached to this e-mail.
>
> Cheers,
> Julien.
>
>>
>>
>>
>>
>> On Wed, Jan 20, 2010 at 1:58 AM, Julien Kerihuel
>>  wrote:
>>         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.
>>         > >
>>         > > I can apply these two patches to wireshark if you want me to.
>>         >
>>         > > Is the pidl patch ok with the upstream pidl maintainer (jelmer?) 
>> ?
>>         > It's mostly ok, but it should be looking at the alignment 
>> information in
>>         > the level table rather than looking at IDL properties directly.
>>         Looks OK for me, I'll rework the patch to fetch information
>>         there rather than within properties directly. It may however
>>         require some time (few days). I'm currently trying to
>>         implement other things within wireshark/pidl for string
>>         support.
>>
>>         FYI, similarly to the nstring/astring patch, I have added a
>>         wireshark/pidl implementation for ascstr3
>>         [size(16bit)][string] based on the same logic - in this case
>>         we look whether we have .*LIBNDR_FLAG_STR_SIZE2.* flag or not
>>         associated to the IDL element - type being obviously string.
>>
>>         Finally I have found a couple more functions where I forgot to
>>         propagate the di->no_align fix in packet-dcerpc.c (including
>>         the dissect_nastring one).
>>
>>         It tends to be a little difficult to maintain all the patches
>>         properly and I'm not very good at svn diff and diff
>>         editing ... Anyway will do the necessary changes and come with
>>         an updated version here.
>>
>>         Cheers,
>>         Julien.
>>
>>
>>
>>         > > On Tue, Jan 19, 2010 at 1:25 AM, Julien Kerihuel
>>         > >  wrote:
>>         > > > Hi Lists,
>>         > > >
>>         > > > Prior submitting the wireshark's part of this patch onto the 
>> wireshark
>>         > > > bugzilla, I thought it might be worthwhile to have feedback 
>> from
>>         > > > developers first.
>>         > > >
>>         > > > MAPI content is non-NDR compatible. It can be dissected using 
>> the
>>         > > > existing NDR layer functions in 
>> epan/dissectors/packet-dcerpc-ndr.c but
>>         > > > it requires offsets to be left intact prior effective 
>> dissection, which
>>         > > > means there shouldn't be any offset adjustment when 
>> LIBNDR_FLAG_NOALIGN
>>         > > > flag is used in PIDL.
>>         > > >
>>         > > > The following patches implement such behavior:
>>         > > > 1. It adds a no_align gboolean variable to dcerpc_info 
>> structure
>>         > > > (default set to FALSE)
>>         > > > 2. when pidl generates the code and LIBNDR_FLAG_NOALIGN flag 
>> is used, it
>>         > > > sets the no_align gboolean to TRUE which turns offste 
>> adjustment off in
>>         > > > wireshark.
>>         > > >
>>         > > > I couldn't

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

[ronnie sahlberg]

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
so they wont collide with your patch.)


This patch can be applied right now, in anticipation of adding the pidl
patches later.






On Wed, Jan 20, 2010 at 1:58 AM, Julien Kerihuel
wrote:

>  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.
> >
> > I can apply these two patches to wireshark if you want me to.
>
> > Is the pidl patch ok with the upstream pidl maintainer (jelmer?) ?
> It's mostly ok, but it should be looking at the alignment information in
> the level table rather than looking at IDL properties directly.
>
>  Looks OK for me, I'll rework the patch to fetch information there rather
> than within properties directly. It may however require some time (few
> days). I'm currently trying to implement other things within wireshark/pidl
> for string support.
>
> FYI, similarly to the nstring/astring patch, I have added a wireshark/pidl
> implementation for ascstr3 [size(16bit)][string] based on the same logic -
> in this case we look whether we have .*LIBNDR_FLAG_STR_SIZE2.* flag or not
> associated to the IDL element - type being obviously string.
>
> Finally I have found a couple more functions where I forgot to propagate
> the di->no_align fix in packet-dcerpc.c (including the dissect_nastring
> one).
>
> It tends to be a little difficult to maintain all the patches properly and
> I'm not very good at svn diff and diff editing ... Anyway will do the
> necessary changes and come with an updated version here.
>
> Cheers,
> Julien.
>
>
>  > On Tue, Jan 19, 2010 at 1:25 AM, Julien Kerihuel
> >  wrote:
> > > Hi Lists,
> > >
> > > Prior submitting the wireshark's part of this patch onto the wireshark
> > > bugzilla, I thought it might be worthwhile to have feedback from
> > > developers first.
> > >
> > > MAPI content is non-NDR compatible. It can be dissected using the
> > > existing NDR layer functions in epan/dissectors/packet-dcerpc-ndr.c but
> > > it requires offsets to be left intact prior effective dissection, which
> > > means there shouldn't be any offset adjustment when LIBNDR_FLAG_NOALIGN
> > > flag is used in PIDL.
> > >
> > > The following patches implement such behavior:
> > > 1. It adds a no_align gboolean variable to dcerpc_info structure
> > > (default set to FALSE)
> > > 2. when pidl generates the code and LIBNDR_FLAG_NOALIGN flag is used, it
> > > sets the no_align gboolean to TRUE which turns offste adjustment off in
> > > wireshark.
> > >
> > > I couldn't come up with a nicer solution so far, but these tiny patches
> > > truly improves the overall development effort for the MAPI dissector. It
> > > basically prevents from writing hand-written code for most of the MAPI
> > > calls. This also means this may help keeping the conformance files - in
> > > particular request.cnf.c and response.cnf.c - readable and prevent them
> > > from exponentially growing up.
> > >
> > > Another advantage is that it becomes conceivable to generate code for
> > > structures or others some non-dceprc dissectors using pidl. You would
> > > only have to describe the structures, specify LIBNDR_FLAG_NOALIGN flag
> > > and you would have automatic dissection code generated which you can
> > > refer to (or cut and paste).
> > >
> > > Cheers,
> > > Julien.
> > >
> > > ---
> > >
> > > Julien Kerihuel
> > > j.kerih...@openchange.org
> > > OpenChange Project Manager
> > >
> > > GPG Fingerprint: 0B55 783D A781 6329 108A  B609 7EF6 FE11 A35F 1F79
> > >
> > >
> > >
>
>
>
>
> Julien Kerihuel
> j.kerih...@openchange.org
> OpenChange Project Manager
>
> GPG Fingerprint: 0B55 783D A781 6329 108A  B609 7EF6 FE11 A35F 1F79
>
>
>
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[ronnie sahlberg]

The wireshark patch for this is fine.

I can apply these two patches to wireshark if you want me to.


Is the pidl patch ok with the upstream pidl maintainer (jelmer?) ?



On Tue, Jan 19, 2010 at 1:25 AM, Julien Kerihuel
 wrote:
> Hi Lists,
>
> Prior submitting the wireshark's part of this patch onto the wireshark
> bugzilla, I thought it might be worthwhile to have feedback from
> developers first.
>
> MAPI content is non-NDR compatible. It can be dissected using the
> existing NDR layer functions in epan/dissectors/packet-dcerpc-ndr.c but
> it requires offsets to be left intact prior effective dissection, which
> means there shouldn't be any offset adjustment when LIBNDR_FLAG_NOALIGN
> flag is used in PIDL.
>
> The following patches implement such behavior:
> 1. It adds a no_align gboolean variable to dcerpc_info structure
> (default set to FALSE)
> 2. when pidl generates the code and LIBNDR_FLAG_NOALIGN flag is used, it
> sets the no_align gboolean to TRUE which turns offste adjustment off in
> wireshark.
>
> I couldn't come up with a nicer solution so far, but these tiny patches
> truly improves the overall development effort for the MAPI dissector. It
> basically prevents from writing hand-written code for most of the MAPI
> calls. This also means this may help keeping the conformance files - in
> particular request.cnf.c and response.cnf.c - readable and prevent them
> from exponentially growing up.
>
> Another advantage is that it becomes conceivable to generate code for
> structures or others some non-dceprc dissectors using pidl. You would
> only have to describe the structures, specify LIBNDR_FLAG_NOALIGN flag
> and you would have automatic dissection code generated which you can
> refer to (or cut and paste).
>
> Cheers,
> Julien.
>
> ---
>
> Julien Kerihuel
> j.kerih...@openchange.org
> OpenChange Project Manager
>
> GPG Fingerprint: 0B55 783D A781 6329 108A  B609 7EF6 FE11 A35F 1F79
>
>
>
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Erroneous data in TCP display

[ronnie sahlberg]

That makes sense for ordinary tcp since the window size is undefined
during the initial syn.

I have checked in a change to wireshark so it does not show the window
size for the initial syn packet.


There is an exception for the
old/obsolete/abandoned/genuinely-bad-idea varient called T-TCP
where the window size during the syn phase did have a semantic meaning.
Fortunately no one is using t-tcp any more and if someone does, they shouldnt.


regards
ronnie sahlberg


On Tue, Nov 17, 2009 at 6:50 AM, Ed Franks  wrote:
> I'm a developer for a TCP/IP stack.  I have been getting customer complaints
> about setting an initial window size of 0.  When I explain that we don't do
> this, they reply "Wireshark says you do."
>
> After examining several Wireshark traces, I see that the display for the
> initial SYN packet does, indeed, show a value for "window" (sometimes 0,
> sometimes other values).  The value obviously comes from the window field
> of the TCP header.
>
> However, "window" is always relative to "ACK", and ACK is never present
> in the initial SYN.
>
> Might it be possible to either omit the "window" value when it is undefined
> or at least show it as "???".  This would be true only for the initial SYN.
>
> If anyone knows why a stack would set the SYN packet window field to non-zero
> (and what it would mean), I would appreciate a pointer to the relevant RFC.
>
> BTW, you provide an excellent product.  It has more than once re-directed the
> "smoking gun" from my software to a failing network device.
> ___
> Sent via:    Wireshark-dev mailing list 
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>             mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[ronnie sahlberg]

On Mon, Nov 9, 2009 at 10:31 AM, Guy Harris  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 one thing that I don't like (although
>> I do it sometimes) is to do a commit that does several things at once.
>> With git, I could commit each patch (which is done locally) and
>> eventually
>> push all commits to the central repository while maintaing the
>> indivitual
>> character of the commits.
>
> The way I work is that I have multiple "working trees" for various
> projects, with modified versions of various source files.
>
> For Wireshark, I do "svn update" on occasion, resolve the conflicts
> myself, and check the code in when it's "done".
>
> For libpcap and tcpdump, which now use Git, that's not so easy, as I
> don't check in my work until it's "done", and then push it.  "git
> pull" gets upset when I've modified files; it doesn't work the way
> "cvs update" and "svn update" work.
>
> I presume "git stash" is one of the tools to be used in this case,
> with a "git stash save" before "git pull" and a "git stash pop"
> after.  When I tried that, it appeared to do a local commit of the
> work done so far; if I then do more work and another "git commit",
> will both of those commits get pushed individually, or do they get
> pushed as one single commit to the remote repository?  I'd prefer the
> latter, as there's no point in exposing individual checkpoints for
> work I've done in the history on the remote repository.
>
> (Currently, I work around it by diffing my tree, backing out my
> changes, doing a "git pull", and then reapplying my changes.  That's
> the Git tool I *really* want, but I don't have time to become a
> porcelain craftsman)

You shouldnt work in the main branch.
Only use the main branch for pulling and pushing to the main repo.

When you want to work on a patch you should first create temporary
local branch and then do all the changes you want in that branch.
git branch work-patch-abc
git checkout work-patch-abc -f

Once you are happy with the patches you either merge the changes back
into the master branch and push
git checkout master -f
git merge work-patch-abc
git push

or you cherry pick the patches you want
git checkout master -f
git log work-patch-abc   (and pick the hash for the patches you want)
git-cherry-pick 
git push


git is different from other systems. To really benefit from it you
should use branches, lots of branches.
(Git is different from other systems also in that branches are fast
and easy to work with,   not like some systems where branches are
convoluted, slow and will make your life miserable)
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[ronnie sahlberg]

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 is less than optimal from a maintenance perspective since you would
now have a "third" encoding to maintain. :-(


ronnie s




On Wed, Sep 2, 2009 at 8:46 AM, Alex Lindberg wrote:
> I am working on an ASN1 based dissector where there where major changes
> between V1 and V2 of the protocol.  As such I must select in the proto.cnf
> file the correct branch of the ASN1 tree to use.  As an example:
>
> Both v1 and v2:
> FirstFoo ::= SEQUENCE
> {
>   version       [0] INTEGER
>   dataMessasge  [1] FooBar
> }
>
> v1:
> FooBar ::= SEQUENCE
> {
>   item1 [0] IA5String
>   item2 [1] INTEGER
> }
>
> v2:
> FooBar ::= CHOICE
> {
>   item1 [0] IA5String
>   item2 [1] INTEGER
> }
>
> I am using an IF statement based on version to call the dissector of either
> the v1 or v2 construction of FooBar.  I have added the v1 version of FooBar
> to the end of the ASN1 definition so v1 Foobar becomes:
>
> FooBarV1 ::= SEQUENCE
> {
>   item1 [0] IA5String
>   item2 [1] INTEGER
> }
>
> and the dissector is dissector_xxx_FooBarV1.   When the v1 dissector is
> called, wireshark complains that with a "DISSECTOR_ASSERT_NOT_REACHED" error
> which indicates that the type and value don't match correctly during
> decoding.
>
> I suppect that I should pass the correct ASN1 definitions to the v1
> dissector, but don't see how that is to be done.  asn2ws created the
> necessary data structures.
>
> Any help would, as always, be greatly appreciated.
>
> Alex Lindberg
>
>
> ___
> Sent via:    Wireshark-dev mailing list 
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>             mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[ronnie sahlberg]

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 really much of a big deal.




On Mon, Aug 17, 2009 at 5:45 PM, Selçuk Cevher wrote:
> Hi,
>
> I made some tests with Wireshark using some sample PCAP files.
>
> I noticed that Wireshark stores the sequence number of the first segment
> belonging to a specific connection that it comes across in the PCAP file as
> the ISN (initial sequence number) of that connection.
>
> I always thought that there might be a possibility that the first segment of
> a TCP stream (with the sequence number of ISN+1) may appear "after", for
> example, 2nd segment of a certain TCP connection.
>
> Was this thought totally wrong that we never come across such a case ? or
> Does Wireshark not handle such a case which may actually occur in practice ?
>
> ___
> Sent via:    Wireshark-dev mailing list 
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>             mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] krb5 dcerpc decryption

[ronnie sahlberg]

Thanks for the warning.

Ill try to port these changes over to samba4 pidl.
There are some changes in samba4 pidl we would need to import as well.



On Tue, Jul 28, 2009 at 4:46 PM, Anders Broman wrote:
> Hi Guys,
> Note that we have made some local changes to the tool:
> http://anonsvn.wireshark.org/viewvc/trunk/tools/pidl/lib/Parse/Pidl/Wireshar
> k/
> http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=28961
>
> Regards
> Anders
> -Ursprungligt meddelande-
> Från: wireshark-dev-boun...@wireshark.org
> [mailto:wireshark-dev-boun...@wireshark.org] För ronnie sahlberg
> Skickat: den 28 juli 2009 05:02
> Till: Stefan (metze) Metzmacher
> Kopia: wireshark-dev@wireshark.org
> Ämne: Re: [Wireshark-dev] krb5 dcerpc decryption
>
> Hi Metze,
>
> Can you check those two patches again?
> I can not decrypt any of the captures you sent.
>
> I built wireshark with your patch and also patched mit 1.6.3 with the
> second patch and load it with
> LD_PRELOAD=./lib/libk5crypto.so
>
> But can not decrypt any of the packets.
> The modified  krb5_dk_decrypt_maybe_trunc_hmac() is called from
> wireshark but this statement is never true :
>       if (hdr[0] == 0x05 && hdr[1] == 0x04) {
>
>
> I agree, we should have our own code here, just as we have for arcfour.
> Once I can get the decryption working using these hacks, I can look
> into re-implementing this code inside wireshark.
>
>
>
> The pidl command line to generate a ws dissector looks like this :
> pidl lsa.idl --ws-parser
>
>
> regards
> ronnie sahlberg
>
>
> On Sat, Jul 25, 2009 at 6:47 PM, Stefan (metze)
> Metzmacher wrote:
>> Hi Ronnie,
>>
>> could you please apply this patch
>>
> http://gitweb.samba.org/?p=metze/wireshark/wip.git;a=commitdiff;h=d4e3184d5f
> aca653ef053b3469ad3f8ec7605b7e
>>
>> With that patch decryption of aes encrypted traffic works as long as no
>> header signing is used.
>>
>> I tried some hacks to decrypt it when header signing is on
>> and use a hacked mit krb5 1.6 version loaded with LD_LIBRARY_PATH
>>
>> See
>>
> http://gitweb.samba.org/?p=metze/wireshark/wip.git;a=shortlog;h=refs/heads/w
> s-metze-gssapi-20090725
>>
>> I think we should have aes specific decryption code in wireshark like we
>> have for arcfour in packet-spnego.c.
>>
>> With this hacks I can decrypt every packet of the attached captures.
>>
>> BTW: with what commandline do I have to generate pidl dissectors?
>>     I want to add it for the DFS-R (FrsTransport) Interface.
>>
>> metze
>>
> ___
> Sent via:    Wireshark-dev mailing list 
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>             mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
>
> ___
> Sent via:    Wireshark-dev mailing list 
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>             mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] krb5 dcerpc decryption

[ronnie sahlberg]

Hi Metze,

Can you check those two patches again?
I can not decrypt any of the captures you sent.

I built wireshark with your patch and also patched mit 1.6.3 with the
second patch and load it with
LD_PRELOAD=./lib/libk5crypto.so

But can not decrypt any of the packets.
The modified  krb5_dk_decrypt_maybe_trunc_hmac() is called from
wireshark but this statement is never true :
   if (hdr[0] == 0x05 && hdr[1] == 0x04) {


I agree, we should have our own code here, just as we have for arcfour.
Once I can get the decryption working using these hacks, I can look
into re-implementing this code inside wireshark.



The pidl command line to generate a ws dissector looks like this :
pidl lsa.idl --ws-parser


regards
ronnie sahlberg


On Sat, Jul 25, 2009 at 6:47 PM, Stefan (metze)
Metzmacher wrote:
> Hi Ronnie,
>
> could you please apply this patch
> http://gitweb.samba.org/?p=metze/wireshark/wip.git;a=commitdiff;h=d4e3184d5faca653ef053b3469ad3f8ec7605b7e
>
> With that patch decryption of aes encrypted traffic works as long as no
> header signing is used.
>
> I tried some hacks to decrypt it when header signing is on
> and use a hacked mit krb5 1.6 version loaded with LD_LIBRARY_PATH
>
> See
> http://gitweb.samba.org/?p=metze/wireshark/wip.git;a=shortlog;h=refs/heads/ws-metze-gssapi-20090725
>
> I think we should have aes specific decryption code in wireshark like we
> have for arcfour in packet-spnego.c.
>
> With this hacks I can decrypt every packet of the attached captures.
>
> BTW: with what commandline do I have to generate pidl dissectors?
>     I want to add it for the DFS-R (FrsTransport) Interface.
>
> metze
>
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[ronnie sahlberg]

There are a number of places where the "length" variable comes after the
array.
I think there are even places where there are other variables separating the
"length" and the array apart in some places.

This is all allowed in DCE/RPC and the reason for this is that "length" is
just a normal variable.
When used in this way
...
   [length_is(len)] foo_t entries[];
   ...
   int len;

This will actually encode "len" twice on the wire.
First it will encode the array like this :

uint32_t  "length" (*)
element 0
element 1
...
element len-1

I.e. the length of the array is encoded together with the array and it
contains the value of "lenth" as the length of the array.

A short while later you will then also have the variable "length" itself
being encoded with obviously the same value.


I.e. "length" is encoded twice, first it is encoded as part of the
(conformance data of the) array itself
and a second time as the variable "length" itself.
Therefore it does not matter where in the IDL you specify the array and its
length in relation to eachother.


(* this is a simplified example,   the array size "length" is actually not
encoded at the head of the array but much earlier in the byse-sequence. It
is actually encoded at the head of the encapsulating structure)


regards
ronnie sahlberg



On Tue, Apr 28, 2009 at 10:32 AM, Harsha  wrote:

> On Mon, Apr 27, 2009 at 3:38 PM, Harsha  wrote:
> > I did a quick read of the relevant part of DCE RPC specs, but in all
> > the cases I saw it always had the size and then the array. In those
> > cases it is trivial to first extract the size and use the size to
> > extract the array contents.
> Here is an example in Wireshark code where the length of the array and
> then the array are extracted-
> void ept_lookup(
> [in] handle_t hEpMapper,
> [in] unsigned long inquiry_type,
> [in, ptr] UUID* object,
> [in, ptr] RPC_IF_ID* Ifid,
> [in] unsigned long vers_option,
> [in, out] ept_lookup_handle_t* entry_handle,
> [in, range(0,500)] unsigned long max_ents,
> [out] unsigned long* num_ents,
> [out, length_is(*num_ents), size_is(max_ents)] ept_entry_t entries[],
> <-
> [out] error_status* status );
>
> Related dissecting code that extracts the length of the array and then
> array is in epm_dissect_ept_map_resp() in packet-dcerpc-epm.c.
>
> Unfortunately I don't see any other case where the array comes ahead
> of its length.
>
> Thanks,
> Harsha
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[ronnie sahlberg]

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 the SLAB_ allocator in slab.h eons
ago.
This did improve performance very significantly at that time, but there are
still speedups to gain, though not as low hanging anymore.

One thing that could make dissection faster is if we can get rid of all
usage of SLAB for the field_info type and make it use cheap and fast
ep_ allocated memory instead.


This would mainly be stuff down in the epan/ftypes directory.
I remember I started preparing some of the functions there to allow a
migration to ep_ allocation but did not do all of them.
One I remember would be problematic was the pcre one.

The first step would be to analyze all codepaths where data is created by
calling into the epan/ftypes helpers and make sure the scope
of useage for these are valid if they are allocated with an ep_ scope.

Second would be to get rid of all the use of SLAB for field_info and just
rely on ep_ allocations.

This would be more problematic though since there are instances when a tree
of field_info is created but the tree is valid and referenced across several
packets/the entire capture. I never had time to analyze this properly but if
the cause is identified, maybe using se_ allocations for the second style of
field_info allocations, which scope to use identified by a parameter to the
functions?





2009/3/22 yami 

> Hi Didier,
>
> Thank you for trying the patch :) and all the good comments given.
>
> I've attached a new patch to the wiki. Please see my detailed reply below.
>
>
> On Fri, Mar 20, 2009 at 6:30 AM, didier  wrote:
>
>> Hi,
>>
>> Le mercredi 18 mars 2009 à 23:05 +0800, yami a écrit :
>> > Thanks, I've written a page in Wiki:
>> >   http://wiki.wireshark.org/Development/FastFiltering
>> Nice work.
>>
>> - If compiled without NDEBUG defined I get a failed assert:
>> epan/dfilter/wslimmat.c :1680 : fix_variables:  "v->assignment == v"
>>
> It seems like a 'bug' of gcc optimization. We can simply remove this
> assertion, see explanations below.
>
> The assertion fails, but the 'real' value of v->assignment and v are equal.
> I came to this conclusion by following experiments (is there any better
> way?):
>
> experiment 1. without NDEBUG defined, but using '-O0' to compile, not
> assertion failure occurs.
> experiment 2. no change to Makefile, simply add printf(v->assignment, v) to
> fix_pointer(), no assertion failure
> experiment 3. no change to Makefile, add following to fix_variables() after
> the assert line:
>   if (v->assignment != v)
>   printf("not hold v->assignment=%p, v=%p\n", v->assignment, v);
>   else
>   printf("hold v->assignment=%p, v=%p\n", v->assignment, v);
>
> The assertion fails (simply print, no abort), however output is:
>  hold v->assignment=0x8070508, v=0x8070508
>
> which just says the opposite.
>
>
>> valgrind doesn't complain and it seems to work with NDEBUG but only for
>> simple stuff ie udp && dns, something like !(tcp.stream eq 1)
>> && !(tcp.stream eq 2) doesn't return the right result.
>> ie:
>> follow TCP stream, filter out this stream, follow TCP this stream, and
>> so on.
>> Does it work for you?
>
>
> This is a bug, I've fixed '!' (TEST_OP_NOT) part at least. I'll test the
> patch more.
>
>>
>>
>> - stupid but Limmat uses the original BSD license which is incompatible
>> with the GPL.
>>
>
> Really? I've thought BSD license is looser than GPL (can you give me more
> details?).
> On the other hand, I find Wireshark code has already contains similar
> licenses (am I right?), for example,
> Menu -> Help -> About Wireshark -> License -> Part III has metioned some.
>
>>
>> - On the other hand if expressions are made incrementally via popup
>> menus is a full SAT solver need?
>>
>
> Perhaps you are right, but I'm not sure.
>
> However using a SAT solver (even if it is a simple one) is the most
> generalized way, which requires no special handling. And it is also a good
> example of how math is applied in real life :)
>
> Cons are
> 1. SAT solvers are complicated. (But we may use a simple algorithm)
> 2. Public available SAT solvers are mainly wrote by researchers, which may
> not have time to maintain the software.
>
>>
>> eg:
>> Something like
>> tcp.stream eq 1 --> H1
>>
>> !(tcp.stream eq 1) --> !H1 --> H2
>>
>> tcp.stream eq 2 --> H3
>>
>> !(tcp.stream eq 1) && !(tcp.stream eq 2) --> H2 && !H3
>>
>> may be good enough.
>>
>> Didier
>>
>>
>>
>>
>> ___
>> Sent via:Wireshark-dev mailing list 
>> Archives:http://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>> mailto:wireshark-dev-requ...@wireshark.org
>> ?s

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

[ronnie sahlberg]

>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)



On Mon, Feb 23, 2009 at 9:57 PM, יוני תובל  wrote:

> hi , thanks .
> it seems to be working , but only when i raise the flag 
> "pinfo->can_desegment=1
> "  inside the get_len method .
> but i noticed that the TCP checksum test fails in all the reassembled
> packets .
> why is that ?
> actually it also fails when i send the whole message in one buffer ...
> so its probably a different issue . . .
>
>
> thanks
> 2009/2/23 Guy Harris 
>
>>
>> On Feb 23, 2009, at 12:59 AM, יוני תובל wrote:
>>
>> > i tried to return the entire message length . still fails .
>> > (it only succeeds when the tvb consists of the entire message )
>> > What about he offest value we pass to the get_len method .
>>
>> It's the offset into the tvbuff handed to the get_len routine of the
>> first byte of the packet whose length should be returned.
>>
>> Presumably the PDUs consist of a 2-byte length field (in network byte
>> order?) followed by that number of bytes of data, and, in the get_len
>> routine, you fetch the length value from the packet, add 2 to it, and
>> return that value.
>>
>> ___
>> Sent via:Wireshark-dev mailing list 
>> Archives:http://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>> mailto:wireshark-dev-requ...@wireshark.org
>> ?subject=unsubscribe
>>
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[ronnie sahlberg]

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=rev&revision=25368
>
> User: etxrab
> Date: 2008/05/22 10:55 PM
>
> Log:
>  Fix some of the Errors/warnings detected by checkapi.
>
> Directory: /trunk/epan/crypt/
>  ChangesPath   Action
>  +1 -1  Makefile.commonModified
>  +4 -0  Makefile.nmake Modified
>
> Directory: /trunk/epan/
>  ChangesPath Action
>  +1 -1  addr_resolv.cModified
>  +1 -1  emem.c   Modified
>
> Directory: /trunk/gtk/
>  ChangesPath   Action
>  +1 -2  Makefile.commonModified
>  +7 -2  Makefile.nmake Modified
>
> Directory: /trunk/
>  ChangesPath  Action
>  +2 -2  Makefile.nmakeModified
>  +1 -1  dumpcap.c Modified
>
> ___
> Wireshark-commits mailing list
> [EMAIL PROTECTED]
> http://www.wireshark.org/mailman/listinfo/wireshark-commits
>
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] jumping tcp packets

[ronnie sahlberg]

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 thus
you get missed packets unless you have a high-end disk subsystem.

What is the line speed and throughput you are looking at?


On Thu, Apr 3, 2008 at 7:35 PM, Maria de Fatima Requena
<[EMAIL PROTECTED]> wrote:
> Hi
>
>  I am implementing a skinny sniffer using winpcap and I am experimenting 
> problems while parsing packets. Some of them are just missed to my 
> application. I am using wireshark to see what is really happening, and I cant 
> understand it
>
>  This is part of my code (callback function called by winpcap):
>
>
>  void packet_handler(u_char *param, const struct pcap_pkthdr *header, const 
> u_char *pkt_data)
>  {
> ip_header *ih=NULL;
> udp_header *uh=NULL;
> tcp_header *th=NULL;
> u_int ip_len;
> u_short tcp_len;
> char* sipP,*sipBody;
> char* skinnyP;
> std::string payload;
> int longSIP;
> map::iterator it;
>
> Logger* mainLog=0;
>
>
> /* retireve the position of the ip header */
> ih = (ip_header *) (pkt_data +
> 14); //length of ethernet header
>
> /* retrieve the position of the udp header */
> ip_len = (ih->ver_ihl & 0xf) * 4;
>
> mainLog=Logger::GetLogger("main");
>
> if (ih->proto==0x06)//tcp == 0x06
> {
> th = (tcp_header *) ((u_char*)ih + ip_len);
>
> u_short sport=ntohs(th->sdPorts.sport);
> u_short dport=ntohs(th->sdPorts.dport);
>
> if (sport==2000||dport==2000)//0x7d0=2000
> {
>  ...
>
>  This function is run inside a thread as:
>
>  pcap_loop((pcap_t *)handle,0, packet_handler, NULL);
>
>  With this instruction: if (ih->proto==0x06)//tcp == 0x06 I would be able to 
> see every TCP incoming packet anyway, many packets wireshark is able to 
> capture, are left for me. Can anyone have an idea of what is happening?
>
>  Thanks in advance
>
>
>
>
>  María de Fátima Requena Cabot (2488)
>  +34 91 787 23 00 alhambra-eidos.es
>
>
>  ___
>  Wireshark-dev mailing list
>  Wireshark-dev@wireshark.org
>  http://www.wireshark.org/mailman/listinfo/wireshark-dev
>
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] ethernet over USB

[ronnie sahlberg]

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 frames.


With wireshark on Linux you were capturing not USB frames  but rather
the Ethernet frames running on the virtual link layer provided by USB.


Your stack looks like this :

IP
Ethernet
Upper USB layer
Lower USB layer

With snoopy you captures tiny frames in the Lower USB layer and with
Wireshark you captured packets all the way up in the Ethernet layer.
thats why there is no real relation between what Wireshark saw on
linux and what snoopy saw on windows.   Two different layers.


To get something similar to what snoopy captured from your linux box
you must make it capture traffic on a much lower layer.


To be able to capture the USB layer on linux you need a new version of
TCPdump (download and install the latest tcpdump/libpcap svc version)
and also recompile your linux kernel so that it provides a pcap-like
interface to the USB layer.

http://wiki.wireshark.org/CaptureSetup/USB?highlight=%28usb%29

describes what you need to do to capture the usb frames on linux.


Since libpcap now has an encapsulation type for USB frames   which
usbmon in linux uses to write wireshark compatible pcap files,  you
may want to ping the snoopypro people and ask them if they can make
usbsnoopy compatible with libpcap and write libpcap files.



2008/2/2 Bill Fassler <[EMAIL PROTECTED]>:
> Just in case someone is as interested as me, I meant to attach these files:
>
>
>
> Bill Fassler <[EMAIL PROTECTED]> wrote:
>
>  Well I found a packet to packet correlation between the two sniffers and
> then I tried to hand dissect the snoopypro packet based on what I could
> learn from the Wireshark Capture.
>
> I have a couple questions, I understand this might be outside the normal
> scope of things here, so if nobody knows or doesn't want to spend the time
> looking at this I'll certainly understand.
>
> I am trying to understand as much through "reverse engineering" before I
> resort
> to the "protocol standard".  I like to try to do this because on rare
> occasions you
> run into proprietary protocols and you can't get your hands on any
> "standard".
>
> 1) What is the traffic inbetween real ethernet packets.  Hearbeat packets as
> Tyson seems to suggest or something more perplexing?
>
> 2) What is in the Ethernet header/wrapper where it seems there are only
> a few relevant bytes of data and many many empty (0x00 bytes)
>
> 3) How did I screw up on the byte size of my hand dissection? (highlighted
> below)
>
> The development team and the helpful users here have helped and saved me
> much time in the past, so I thought I would toss this over the fence:
>
> Here is the raw USB capture for this packet (according to SnoopyPro)
>
> 01008e0024006200ae936c17012456da9ca1b3f3080045542bdf400080014b75c0a80103c0a80101b2c476016d07177500ec560008000800caa65000c8eb5600c4eb56004051510003000300
>
>
> 
> Raw Ethernet captured by snoopypro and hand dissected
> *
> I am trying to understand this USB wrapper/header which seems to be the same
> for every packet with just a few exceptions:
>
> 01008e0024006200
>
> Destination:
> ae936c170124
> Source:
> 56da9ca1b3f3
> Traffic ID (Ethernet):
> 0800
> Version:
> 4
> Header Length: |
> 5 |
>| <== I lost continuity here.  Wireshark claims 20
> bytes, but I
>| <== couldn't see how that was obtained. (seems like
> more to
>   |  <== me when I count them manually)
>    |
> Total Length:
> 54 (84)
> Identification:
> 2bdf
> Flags:
> 4
> Fragment offset:
> 000
> Time to live:
> 80 (128)
> Protocol IMCP:
> 01
> Header Checksum:
> 4b75
> Source:
> c0a80103
> Destination:
> c0a80101
> Type:
> 00 (Ping Reply)
> Code:
> 00
> Internet Control Message protocol checksum:
> b2c4
> Identifier:
> 7600
> Sequence Numer:
> 0001
>
> Ethernet payload:
> 6d07177500ec560008000800caa65000c8eb5600c4eb56004051510003000300
>
>
> **
> Dissected Wireshark capture of same packet
> *
>   No. TimeSourceDestination   Protocol
> Info
>   7 12.412641   1

Re: [Wireshark-dev] RPC RQUOTA protocol

[ronnie sahlberg]

As jaap said,  the interface description for ONC-RPC services can
often be found in
/usr/include/rpcsvc

Here is a link to an interface description that defines both version 1
and version2 of rquota
http://ninna.tom.sfc.keio.ac.jp/sa/sources/quota-tools/rquota.x

It should be fairly straightforward to add rquota v2


If you can provide example captures I can add it for you



On Nov 29, 2007 7:35 AM,  <[EMAIL PROTECTED]> wrote:
> All,
>
> I'm having difficulty finding information that discusses either the RQUOTA V1 
> or V2 protocol.  Was there ever an RFC or something like it issued for RQUOTA 
> ?
>
> I'd like to look into adding V2 support to the RQUOTA dissector in Wireshark.
>
> Thanks,
>
> Frank Schorr
> ___
> Wireshark-dev mailing list
> Wireshark-dev@wireshark.org
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

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

[ronnie sahlberg]

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 PM, Stephen Fisher <[EMAIL PROTECTED]> wrote:
> I'm stumbling through (is there a README somewhere?) trying to add my
> first ASN.1 based dissector (T.124 / Generic Conference Control) to
> Wireshark and I'm running into the following error.  I mostly copied the
> asn1/t124 files from asn1/t125.  This is another layer in a Microsoft
> Remote Desktop Protocol (RDP) session above t.125.
>
> [EMAIL PROTECTED]:/usr/local/src/wireshark/asn1/t124>make generate_dissector
> python ../../tools/asn2wrs.py \
> -b -X -T \
> -p t124 \
> -c ./t124.cnf \
> -s ./packet-t124-template \
> -D . \
>  GCC-PROTOCOL.asn
> ASN.1 to Wireshark dissector compiler
> Traceback (most recent call last):
>   File "../../tools/asn2wrs.py", line 7671, in ?
> eth_main()
>   File "../../tools/asn2wrs.py", line 7602, in eth_main
> ast.extend(yacc.parse(f.read(), lexer=lexer, debug=pd))
>   File "/usr/local/src/wireshark/tools/yacc.py", line 346, in parse
> tok = self.errorfunc(errtoken)
>   File "../../tools/asn2wrs.py", line 7455, in p_error
> raise ParseError(t, input_file)
> __main__.ParseError: GCC-PROTOCOL.asn:54: Unexpected token 
> UniversalString('UniversalString')
> make: *** [packet-t124.c] Error 1
>
> Am I doing something wrong, or does it not like part of the .asn file?
>
> Also, how do I go about creating the t.124.cnf file?  (My attempt above
> was using the t125.cnf file)
>
>
> Thanks,
>
> Steve
> ___
> Wireshark-dev mailing list
> Wireshark-dev@wireshark.org
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] proto_filter_names hash collision

[ronnie sahlberg]

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, Guy Harris <[EMAIL PROTECTED]> wrote:
> >
> > Kukosa, Tomas wrote:
> > > It seems that we have reached critical number of protocols.
> > > I have met collision of built in "p7" protoco with my private "nu"
> > > protocol. They both have the same g_str_hash() value.
> > >
> > > Does it make sence to create hash from the protocol filter name
> > > which has usually 2-4 characters?
> > >
> > > BTW the g_str_hash() for full protocol name takes quite much time during
> > > startup. Does it make sence to check full protocol name duplicity? Is
> > > not it enough to check short name and filter name duplicity?
> >
> > Does it make sense to do all those sanity checks only if a special
> > command-line flag is supplied to TShark, so that the checks are done as
> > part of the build process, rather than being done every time you run
> > Wireshark or TShark?
> > ___
> > Wireshark-dev mailing list
> > Wireshark-dev@wireshark.org
> > http://www.wireshark.org/mailman/listinfo/wireshark-dev
> >
>
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] proto_filter_names hash collision

[ronnie sahlberg]

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 critical number of protocols.
> > I have met collision of built in "p7" protoco with my private "nu"
> > protocol. They both have the same g_str_hash() value.
> >
> > Does it make sence to create hash from the protocol filter name
> > which has usually 2-4 characters?
> >
> > BTW the g_str_hash() for full protocol name takes quite much time during
> > startup. Does it make sence to check full protocol name duplicity? Is
> > not it enough to check short name and filter name duplicity?
>
> Does it make sense to do all those sanity checks only if a special
> command-line flag is supplied to TShark, so that the checks are done as
> part of the build process, rather than being done every time you run
> Wireshark or TShark?
> ___
> Wireshark-dev mailing list
> Wireshark-dev@wireshark.org
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

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

[ronnie sahlberg]

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 anything like this  :-)



On Nov 13, 2007 5:01 AM, Neil Piercy <[EMAIL PROTECTED]> wrote:
> If the protocol has bitfields they can be defined in the hf structs, but
> what is the best way to cope if these fields can be at different bit
> offsets within the byte ? E.g. a 4 bit field which can occur as the
> lower 4 bits or the upper 4 bits of a byte.
>
> The more I think about it, the general way would be to add a bit offset
> to _every_ existing proto_tree_add_*() to go with the existing byte
> offset, but is there a simpler way which
> A) maintains the bitmask display in the main packet field view which the
> hf bitmasks provide.
> B) isnt just a text decode - is based on hf entries.
>
> Neil
> ___
> Wireshark-dev mailing list
> Wireshark-dev@wireshark.org
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] New Dissector: LLRP

[ronnie sahlberg]

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 considered for inclusion in Wireshark,
> patch request SVN #1957.  It is for the EPCglobal Low-Level Reader Protocol
> (see http://llrp.org for more information). A sample capture file is
> included with the patch submission.
>
> Matt Poduska
>
>
> ___
> Wireshark-dev mailing list
> Wireshark-dev@wireshark.org
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

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

[ronnie sahlberg]

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 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
> > http://www.wireshark.org/mailman/listinfo/wireshark-dev
> >
>
>
> ___
> Wireshark-dev mailing list
> Wireshark-dev@wireshark.org
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>
>
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

[Wireshark-dev] More ITU-T standards available

[ronnie sahlberg]

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
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] decoding Remote Desktop Protocol

[ronnie sahlberg]

Maybe legacy mode is not used anymore in modern implementations?

Looking at frame 6 in his capture RDP-002...
the user data transported ontop ox x.224 is definitely BER encoded.

It starts with 0x7fthen what follows is definitely BER.

Frame 6/7 starts with   BER APPLICATION 5/6
Could 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: Wednesday, October 24, 2007 10:09 PM
> > To: Developer support list for Wireshark
> > Subject: 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 family as well as the old
> > legacy encoding through google.
> > (the old legacy encoding means the dissector has to be written by hand
> > since asn2wrs can not be used)
> >
> >
> > On 10/25/07, DePriest, Jason R. <[EMAIL PROTECTED]> wrote:
> > > After Tenable announced that they are going to have operating system
> > > detection based on Remote Desktop fingerprinting available to Direct
> > > Feed customers
> > (http://blog.tenablesecurity.com/2007/10/windows-operati.html),
> > > I thought it would be great to figure out how they are doing that.
> > >
> > > Unfortunately, I can't seem to locate any good technical
> > documentation
> > > on how RDP does what it does.
> > >
> > > I considered looking at the linux programs that use it
> > (rdesktop) and
> > > trying to read their code, but I don't write code myself so it would
> > > be hit or miss.
> > >
> > > RDP is Microsoft's baby and I don't know where to look for
> > in depth docs on it.
> > >
> > > Does anyone have a link or two to some helpful stuff that would help
> > > me break the code?  Or will I just need to figure it the hard way?
> > >
> > > Thanks!
> > >
> > > -Jason
> > >
> > > --
> > > NOTICE:  This email is being sent in clear-text across the public
> > > Internet.  Therefore, any attempts to include unenforceable legalese
> > > restrictions are ridiculous and pointless.  If you can read this,
> > > consider yourself authorized (whether I like it or not).
> > > ___
> > > Wireshark-dev mailing list
> > > Wireshark-dev@wireshark.org
> > > http://www.wireshark.org/mailman/listinfo/wireshark-dev
> > >
> > ___
> > Wireshark-dev mailing list
> > Wireshark-dev@wireshark.org
> > http://www.wireshark.org/mailman/listinfo/wireshark-dev
> >
> ___
> Wireshark-dev mailing list
> Wireshark-dev@wireshark.org
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] decoding Remote Desktop Protocol

[ronnie sahlberg]

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 to and including
the X.224 layer for remote desktop.

Please if you feel like it   give T.12x a try and put it ontop of this
dissector.


On 10/25/07, Stephen Fisher <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 24, 2007 at 11:39:15AM -0500, DePriest, Jason R. wrote:
>
> > Unfortunately, I can't seem to locate any good technical documentation
> > on how RDP does what it does.
> >
> > I considered looking at the linux programs that use it (rdesktop) and
> > trying to read their code, but I don't write code myself so it would
> > be hit or miss.
> >
> > RDP is Microsoft's baby and I don't know where to look for in depth
> > docs on it.
> >
> > Does anyone have a link or two to some helpful stuff that would help
> > me break the code?  Or will I just need to figure it the hard way?
>
> There is little to no public documentation on Remote Desktop.  I wanted
> to implement RDP dissection in Wireshark a while back and gave up (I had
> just finished off the VNC dissector which was a pain even with
> documentation).  Your best bet is to read the source code to rdesktop
> (which is poorly documented if I remember correctly) and the articles
> under the "Documentation" section of www.rdesktop.org.  It is a shame
> they did not document the protocol(s) in a nice fashion while writing
> the code to rdesktop.  I do not mean to discourage you or anyone from
> trying to figure it out as it would be a great feature to have in
> Wireshark.  I would be willing to help if someone could figure out at
> least enough to get started :)
>
>
> Steve
> ___
> Wireshark-dev mailing list
> Wireshark-dev@wireshark.org
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] decoding Remote Desktop Protocol

[ronnie sahlberg]

X.224 is documented here :
http://www.itu.int/rec/T-REC-X.224-199511-I/en



On 10/25/07, ronnie sahlberg <[EMAIL PROTECTED]> wrote:
> Please start a wiki page and add as many example captures as possible
> and interested people can start chipping in.
>
> Maybe the rdesktop people can/want to help out as well?
>
>
>
>
> On 10/25/07, DePriest, Jason R. <[EMAIL PROTECTED]> wrote:
> > From the EULA
> > 2.  ADDITIONAL LICENSING REQUIREMENTS AND/OR USE RIGHTS.
> > a.  Distributable Code.  The software contains code that you are
> > permitted to modify and distribute internally within your organization
> > if you comply with the terms below.
> > i.  Right to Use and Distribute.  The code and text files listed below
> > are "Distributable Code."
> > •   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 sahlberg  wrote:
> > > > 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 connect to RDP just fine,   the source
> > > code for rdesktop should contain everything anyone would need to
> > > implement a dissector.
> > ___
> > Wireshark-dev mailing list
> > Wireshark-dev@wireshark.org
> > http://www.wireshark.org/mailman/listinfo/wireshark-dev
> >
>
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] decoding Remote Desktop Protocol

[ronnie sahlberg]

Please start a wiki page and add as many example captures as possible
and interested people can start chipping in.

Maybe the rdesktop people can/want to help out as well?




On 10/25/07, DePriest, Jason R. <[EMAIL PROTECTED]> wrote:
> From the EULA
> 2.  ADDITIONAL LICENSING REQUIREMENTS AND/OR USE RIGHTS.
> a.  Distributable Code.  The software contains code that you are
> permitted to modify and distribute internally within your organization
> if you comply with the terms below.
> i.  Right to Use and Distribute.  The code and text files listed below
> are "Distributable Code."
> •   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 sahlberg  wrote:
> > > 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 connect to RDP just fine,   the source
> > code for rdesktop should contain everything anyone would need to
> > implement a dissector.
> ___
> Wireshark-dev mailing list
> Wireshark-dev@wireshark.org
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] decoding Remote Desktop Protocol

[ronnie sahlberg]

> 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 connect to RDP just fine,   the source
code for rdesktop should contain everything anyone would need to
implement a dissector.
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] decoding Remote Desktop Protocol

[ronnie sahlberg]

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 family as well as the old
legacy encoding through google.
(the old legacy encoding means the dissector has to be written by hand
since asn2wrs can not be used)


On 10/25/07, DePriest, Jason R. <[EMAIL PROTECTED]> wrote:
> After Tenable announced that they are going to have operating system
> detection based on Remote Desktop fingerprinting available to Direct
> Feed customers (http://blog.tenablesecurity.com/2007/10/windows-operati.html),
> I thought it would be great to figure out how they are doing that.
>
> Unfortunately, I can't seem to locate any good technical documentation
> on how RDP does what it does.
>
> I considered looking at the linux programs that use it (rdesktop) and
> trying to read their code, but I don't write code myself so it would
> be hit or miss.
>
> RDP is Microsoft's baby and I don't know where to look for in depth docs on 
> it.
>
> Does anyone have a link or two to some helpful stuff that would help
> me break the code?  Or will I just need to figure it the hard way?
>
> Thanks!
>
> -Jason
>
> --
> NOTICE:  This email is being sent in clear-text across the public
> Internet.  Therefore, any attempts to include unenforceable legalese
> restrictions are ridiculous and pointless.  If you can read this,
> consider yourself authorized (whether I like it or not).
> ___
> Wireshark-dev mailing list
> Wireshark-dev@wireshark.org
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

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

[ronnie sahlberg]

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 called once anyway



On 10/11/07, keith mercer <[EMAIL PROTECTED]> wrote:
> I have opened the following bugzilla:
> http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1905
>
> Hopefully I have done it correctly, and have provided the needed material as
> this is the first time I have ever done this. :)
>
> This plugin will enable the dissection of CFM EOM ethernet packets defined
> by IEEE 802.1ag/D8.1 and also recognizes the opcodes defined by the ITU
> recommendations in Y.1731 as well as dissect AIS PDUs.  I plan on adding
> everything defined in Y.1731 in a future once I am sure I am heading down
> the right road with the current version of the code.
>
> Thanks to Anders Broman for fixing up the etypes.h and packet-ethertype.c so
> the ethertype does not come up as 'unknown'. ;)
>
> --Keith Mercer
>
>  
> Ask a question on any topic and get answers from real people. Go to Yahoo!
> Answers.
>
>
> ___
> Wireshark-dev mailing list
> Wireshark-dev@wireshark.org
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>
>
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] FTAM ASN.1 copyright

[ronnie sahlberg]

Since it is an ASN file, and since it is freely downloadable from their website
as i read hte section below we should be ok :

http://www.itu.int/ITU-T/ipr/

# ITU-T Software Copyright Guidelines
[Download Word or PDF file]



2.2  Software that should not raise any IPR issues when including
it in a Recommendation
The vast majority of software included in ITU-T Recommendations fall
within this category.
This category includes software that is submitted to a Study Group
without any restrictions (as
provided for in Recommendation A.1, clause 3.1.5). For example this
includes, but is not limited to,
formal description techniques such as SDL, MSC, ASN.1, GDMO, TTCN. The
copyright for these
is treated in the same way as text and has no restrictions in order to
permit the normal distribution
of this material for discussions within the appropriate groups and
possible use, in whole or in part,
in any resulting ITU-T Recommendations which are published. In
addition, given that the material
 Software Copyright Guidelines issue 2.1.1 March 2005
  -6-
was submitted without any restrictions, the material can be used by
those implementing the
Recommendation, free from any copyright assertion by the submitter; however, the
Recommendation would still be subject to the restrictions established
by the ITU in respect to its
copyright interests in the Recommendation as a document. Of course,
normal technical
considerations concerning selection of the most appropriate means of
expression (natural language,
formal description, software, etc.) apply.
This category also includes software that is collaboratively developed
by an ITU-T Study
Group that is not subject to any entity's proprietary claim of copyright.
For all software in this category, Section 3 of these Guidelines, and
Annexes A, B, C, and D, do not
apply.


On 10/11/07, Anders Broman <[EMAIL PROTECTED]> wrote:
> Hi,
> At least the file is freely downloadable from
> http://www.itu.int/ITU-T/asn1/database/iso/8571-4/1988/index.html
>
> If (strict)copyright is to be applied to ASN1 or PIDL and other protocol
>  Describing languages any one using it in open source can only publish the
>  Generated code I suppose.
>
> But strictly speaking can one even copy part of an RFC (or other spec) into
> a program without violating copyright?
> Can MIB:s from RFC:s be used? Etc etc
> Regards
> Anders
>
> -Ursprungligt meddelande-
> Från: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] För Gerald Combs
> Skickat: den 10 oktober 2007 23:46
> Till: Developer support list for Wireshark
> Ämne: [Wireshark-dev] FTAM ASN.1 copyright
>
> Someone recently pointed out that the top of asn1/ftam/ISO8571-FTAM.asn has
> the
> following notice:
>
> -- Module ISO8571-FTAM (ISO 8571-4:1988)
> --
> -- Copyright ? ISO/IEC 1988. This version of
> -- this ASN.1 module is part of ISO/IEC 8571-4:1988;
> -- see the ISO|IEC text itself for full legal notices.
>
> Do we need to get permission from the ISO to use and distribute this file?
> ___
> Wireshark-dev mailing list
> Wireshark-dev@wireshark.org
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>
> ___
> Wireshark-dev mailing list
> Wireshark-dev@wireshark.org
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] Single TCP segment having multiple PDUs not working

[ronnie sahlberg]

try using tcp_dissect_pdus() to handle the case with pdus transported
ontop of tcp
it will take care of this for you automatically


On 9/28/07, Zongjun <[EMAIL PROTECTED]> wrote:
> Hey guys,
>
> According to my capture, I don't have situations where ONE PDU spans over
> multiple TCP segment. In stead, mine is the other round: Single segment
> having multiple PDUs.
>
> But using the folling code, what I observed is wireshark did put multiple
> PDU info inside the Detail Window after TCP, however these PDUs are always
> the same. But in the bottom hexdump window, they are definitely from
> different PDU.
>
> I noticed there has been a similar issue before Wireshark-dev: Re:
> [Wireshark-dev] Dissect multiple PDUs in one TCP Segment.
> But again, it is not for single segment having multiple PDU.
>
> Anyone see the same issue?
>
> Thanks,
> Zongjun
>
>
> static void
> dissect_myproto(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree)
> {
> gint offset = 0; // always points to the front
> gint available = 0; // how many bytes still available to consume
>
> while((available = tvb_reported_length_remaining(tvb,
> offset)) > 0)
> {
>   printf("available = %d\n", available);
>
>
>
>
>   /* make entry in the Protocol column on summary display */
>   if (check_col(pinfo->cinfo, COL_PROTOCOL))
> col_set_str(pinfo->cinfo, COL_PROTOCOL, PSNAME);
>
>
>
>
>   /* create the myproto protocol tree */
>   if (tree) {
> myproto_item = proto_tree_add_item(tree, proto_myproto, tvb, offset,
> -1, FALSE);
>
>
>
>
> myproto_tree = proto_item_add_subtree(myproto_item,
> ett_myproto);
>
> offset +=
> dissect_MyProtoMessage_PDU(tvb,pinfo,myproto_tree);
>
>
>
>
>   }
>   printf("offset = %d\n", offset);
>
>
>
>
>   if(tvb_reported_length_remaining(tvb, offset) > 0)
> {
>   printf("haha, we get a multiple PDU. \n");
> }
>} //while:
> }
>
>
> ___
> Wireshark-dev mailing list
> Wireshark-dev@wireshark.org
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>
>
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

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

[ronnie sahlberg]

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 PROTECTED]> wrote:
>
>  Hi ,
>
> We have used Linux 64 bit machine to compile and test our dissectors. Now
> we want the same to be done in Windows XP, Vista and Solaris environment.
>
> Can somebody please explain the steps or tell me where can I find the
> information regarding the same.
>
> BR,
> Tarani
>
> The information contained in this electronic message and any attachments
> to this message are intended for the exclusive use of the addressee(s) and
> may contain proprietary, confidential or privileged information. If you are
> not the intended recipient, you should not disseminate, distribute or copy
> this e-mail. Please notify the sender immediately and destroy all copies of
> this message and any attachments.
>
> WARNING: Computer viruses can be transmitted via email. The recipient
> should check this email and any attachments for the presence of viruses. The
> company accepts no liability for any damage caused by any virus transmitted
> by this email.
>
> www.wipro.com
>
> ___
> Wireshark-dev mailing list
> Wireshark-dev@wireshark.org
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>
>
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

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

[ronnie sahlberg]

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 card
> > > from which the mac was used as seed. I usually use a BCD encoded
> > > vlan-tag-number as the LA-mac, this would result in something
> > > like "Local_00:01:30" for vlan 130 :-)
> >
> > I don't think that's a good idea. Just leave the number in there,
> > because otherwise addresses local_00:01:02 and local_00:01:02 would look
> > the same, while the first local might have a value of 36:37:38 and
> > the second local value might be 02:00:00
>
> True, but that risk is already there for a lot of Vendors:
>
> [EMAIL PROTECTED]:~/wireshark$ grep "^..:" manuf | awk '{print $2}' | sort | 
> uniq -c | sort -rn | head
>  321 Cisco
>   52 Private
>   28 NokiaDanma
>   23 NortelNetw
>   22 TexasInstr
>   22 Intel
>   21 Nortel
>   19 3com
>   18 SamsungEle
>   18 HewlettPac
> [EMAIL PROTECTED]:~/wireshark$
>
> Of course the risk is bigger in this case, although I think in practice
> it would not occur very often :-)
>
> Maybe just adding a line:
>
> 02:00:00Local   # LOCALLY ADMINISTRATED ADDRESS
>
> would be an option. That way, there are no duplicates. This is of course
> only beneficial other people besides me choose their locally administrated
> addresses within 02:00:00:XX:XX:XX .
>
> Are there any other people that choose their addresses like this?
>
> Cheers,

Microsoft Cluster creates a local mac address for the cluster by taking the
mac address of the primary node and just flipping the la bit.

If the primary node of the cluster has
04:05:06 -> Xerox

then the "virtual" mac address for the cluster itself will be
06:05:06

in that situation it is useful to do the matching by masking out the la bit
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

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

[ronnie sahlberg]

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 of the primary node and then
> setting the locally administrated bit, to make sure there is a single
> mac address that follows the cluster ip address during failover.
>
> MS cluster for example does this.
>
>
> The multicast bit is tricker since there is for unknown reasons some 3
> byte prefixes that already have this bit set !   But they are so few
> and rare it hardly matters and they can probably be ignored.
>
>
> I would suggest only doing this for when matching with the three byte prefixes
> of the form AA:BB:CC
>
>
> Additionally, maybe if you find a match for
> AA:BB:CC Vendor
> and if the LA bit was set then you could change the string it resolved into
> to "Vendor(Cluster)" instead of just "Vendor"
>

Ah crap, you need to do it in two passes since there are real MACs
that already come with the LA bit set.

So when matching the AA:BB:CC entries in manuf
1, First try to match it exactly
   if you find a match, then thats the match.
   i.e.  52:54:4C   Novell2000
   which would resolve into "Novell2000"

2, If that fails, then try to match it by stripping off the LA bit   with & 0xfd
In that case 3E:00:00:xx:xx:xx would match
3C:00:003Com
But the original address would have the LA bit set so it should then be
resolved into "3Com(Cluster)"


You have to be careful in which order you try to resolve them as well so that
you dont mixup
00:01:00EquipTrans
and
02-01-00-00-00-00/16MS-NLB-PhysServer-01



I think the optimal would be to resolve your examples as
04:05:06 -> Xerox
06:05:06 -> Xerox(Cluster)
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

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

[ronnie sahlberg]

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 make sure there is a single
mac address that follows the cluster ip address during failover.

MS cluster for example does this.


The multicast bit is tricker since there is for unknown reasons some 3
byte prefixes that already have this bit set !   But they are so few
and rare it hardly matters and they can probably be ignored.


I would suggest only doing this for when matching with the three byte prefixes
of the form AA:BB:CC


Additionally, maybe if you find a match for
AA:BB:CC Vendor
and if the LA bit was set then you could change the string it resolved into
to "Vendor(Cluster)" instead of just "Vendor"

I think it is very rare that this bit is set nowadays except for when
one is using some sort of clustering software with ip and mac
failover.




On 8/15/07, Ulf Lamping <[EMAIL PROTECTED]> wrote:
> Hi List!
>
> The current Ethernet manuf name resolving (resolve the manufacturer name - 
> the first three bytes of the Ethernet address, e.g. 04:05:06 -> Xerox) 
> doesn't work if the address uses the Ethernet broadcast or locally 
> administered flags (see 
> http://wiki.wireshark.org/Ethernet?highlight=%28ethernet%29#head-93bbcf02a0070b56eaae6b5f3f4ba6112c64522a
>  for details about these flags).
>
> Currently only the resolving of 04:05:06 -> Xerox does work, 05:05:06, 
> 06:05:06 and 07:05:06 are not resolved, although the manufaturer part is the 
> same.
>
> I've implemented an experimental change in epan/addr_resolv.c, which strips 
> down both flags before doing the actual manuf resolvings - which is working 
> well:
>
> 04:05:06 -> Xerox
> 05:05:06 -> Xerox
> 06:05:06 -> Xerox
> 07:05:06 -> Xerox
>
> Unfortunately, this "hides" both flags a little bit (although the display of 
> these flags wasn't very "prominent" already before), so I'm unsure if the 
> change should go into the Wireshark sources or not.
>
> I think only the manuf resolvings as described above should be changed, the 
> wka (well-known-addresses) aka full address resolution (00-E0-2B-00-00-00 -> 
> Extreme-EDP) should not be changed.
>
> Comments?
>
> Regards, ULFL
> __
> Erweitern Sie FreeMail zu einem noch leistungsstärkeren E-Mail-Postfach!
> Mehr Infos unter http://produkte.web.de/club/?mc=021131
>
> ___
> Wireshark-dev mailing list
> Wireshark-dev@wireshark.org
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] TCP Reassembly issues

[ronnie sahlberg]

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 flags set.
>
> The sequence number does not necessarily reset to 0 at the start of a
> sequence
> of fragments, it just runs sequentially from the fragment where the first
> bit
> is set.
>
> Because the protocol sequence number is repeated between hosts, I needed to
> invent a unique one to link related application message fragments together,
> hence the static seq_number.  The aim of this is to allow many conversations
> between hosts that are individually identifiable, but reuse the protocol
> sequence number.  If I understand correctly, you are saying that I should
> only
> increment this and add fragments when first finding a fragment, i.e. the
> flag.visited is false.

Maybe packet-nbd.c is useful.
NBD clients often reuse the transaction ID once a previous transaction
has completed making tracking more difficult.

NBD has a structure attached to each conversation,   this structure
contains two hashtables,
one for unacked packets which is populated on initial scan
and a second hashtable which is used later.
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

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

[ronnie sahlberg]

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 where one can see which sids
are known and mapped.

it would take a lot of time to fix it correctly so it becomes useful.
maybe i will do it soon   i hope


On 7/9/07, Martin Mathieson <[EMAIL PROTECTED]> wrote:
> I'm seeing this error when starting wireshark (despite tshark below in
> the error output).
>
> Ronnie - will you be adding samr.hnd back again as a field, or should
> this filter expression (in packet-smb-sidsnooping.c) be changed now?
>
>
> tshark: Couldn't register
> proto_reg_handoff_smb_sidsnooping()/samr_query_dispinfo tap: Filter
> "samr and samr.opnum==40 and ( samr.hnd or samr.rid or samr.acct_name
> or samr.level )" is invalid - "samr.hnd" is neither a field nor a
> protocol name.
> ___
> Wireshark-dev mailing list
> Wireshark-dev@wireshark.org
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

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

[ronnie sahlberg]

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 article would not of been possible without the
> developers guide.
>
> Note: The article is designed for the Win32 environment.
>
> http://www.codeproject.com/useritems/custom_dissector.asp
>
> Regards
> Ken
> ___
> Wireshark-dev mailing list
> Wireshark-dev@wireshark.org
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

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

[ronnie sahlberg]

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 M2M protocol to carry
> WiMAX burst packets over Ethernet. The M2M plugin is registered as an
> Ethernet protocol, and in turn calls the WiMAX plugin.
>
> Mike
>
>
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

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

[ronnie sahlberg]

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
virtually the entire asn for both dialects of kerberos we support,
so asn2wrs'ifying it will not really increase the coverage of it.

Third, the dissector contains a lot of special stuff that vendors
(==ms) added to kerberos that is not ans1 defined,things such as
storing nt_status codes inside salt fields and also calling off to NDR
stuff like the PAC in w2k domains

Fourth, there is a lot of code to handle the decryption feature  which
also ties into the various places where krb is used un conjunction
with gss-api for decryption of packets (== dcerpc and secure ldap)


maybe it is easier and less work to just handmassage the existing
dissector to use the new signatures instead of asn2wrs'ifying it ?



On 5/7/07, Anders Broman (AL/EAB) <[EMAIL PROTECTED]> wrote:
> Hi,
> Could you do the asn2wrs changes and send me the file then I could do some 
> experiments and
> see how much work is involved? At least you have taken care of T38 then there 
> is Kerberos
> and some gsm stuff so it might not be to difficult.
> Regards
> Anders
>
> 
>
> Från: [EMAIL PROTECTED] genom Kukosa, Tomas
> Skickat: må 2007-05-07 09:42
> Till: Developer support list for Wireshark
> Ämne: 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.cpacket-ber.hpacket-camel.c ...
>
>
>
> Hi,
>
> BTW when you are making such large changes do not you think about
> changing of packet-ber from "field oriented" to "type oriented"?
>
> I.e. replacing
>
>  field_function() {
>type_function(hf_field);
>  }
>  sequence_structure[] = {
>   {..., field_function},
>  }
>
> with code
>
>  sequence_structure[] = {
>   {&hf_field, ..., type_function},
>  }
>
> I did the same for PER last year and generated code is much shorter.
>
> Unfortunately it will be probaly very hard for BER as there are much BER
> code written by hands which can not be regenerated but has to be
> changed.
>
> regards,
>   Tomas
>
>
> Mailcode: NdD2sKHg
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Anders Broman
> (AL/EAB)
> Sent: Monday, May 07, 2007 8:57 AM
> To: Developer support list for Wireshark
> Subject: Re: [Wireshark-dev] [Wireshark-commits] rev
> 21705:/trunk//trunk/plugins/asn1/:
> asn1.hpacket-asn1.c/trunk/epan/dissectors/:packet-MAP_DialoguePDU.cpacke
> t-acp133.c packet-acse.cpacket-ansi_map.c packet-ber.cpacket-ber.h
> packet-camel.c ...
>
> Hi,
> I thought as much but there is still a lot of work to get the actx into
> all the BER dissecors. I'm taking it a step
> At the time.
> Regards
> Anders
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Kukosa, Tomas
> Sent: den 7 maj 2007 07:58
> To: wireshark-dev@wireshark.org
> Subject: Re: [Wireshark-dev] [Wireshark-commits] rev 21705:
> /trunk//trunk/plugins/asn1/: asn1.h
> packet-asn1.c/trunk/epan/dissectors/:
> packet-MAP_DialoguePDU.cpacket-acp133.c packet-acse.c packet-ansi_map.c
> packet-ber.cpacket-ber.h packet-camel.c ...
>
> Hello Anders,
>
> I had not checked X.690 (BER) specification before I defined PER
> external structures in asn1_ctx_t.
> I expected BER uses encoding based on X.680 definition.
>
> I think we could merge most of PER and BER items in external structure.
>
> I will move PER items one layer upper and you can reuse them later in
> BER too.
>
> Regards,
>   Tomas
>
>
> Mailcode: NdD2sKHg
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> [EMAIL PROTECTED]
> Sent: Monday, May 07, 2007 12:34 AM
> To: [EMAIL PROTECTED]
> Subject: [Wireshark-commits] rev 21705: /trunk/ /trunk/plugins/asn1/:
> asn1.h packet-asn1.c /trunk/epan/dissectors/: packet-MAP_DialoguePDU.c
> packet-acp133.c packet-acse.c packet-ansi_map.c packet-ber.c
> packet-ber.h packet-camel.c ...
>
> http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=21705
>
> User: etxrab
> Date: 2007/05/06 10:34 PM
>
> Log:
>  Start introducing actx to ber functions.
>
> Directory: /trunk/plugins/asn1/
>   ChangesPath Action
>   +45 -0 asn1.h   Modified
>   +0 -1  packet-asn1.cModified
>
> Directory: /trunk/epan/dissectors/
>   ChangesPath Action
>   +20 -20packet-MAP_DialoguePDU.c Modified
>   +56 -56packet-acp133.c  Modified
>   +103 -103  packet-acse.cModified
>   +501 -501  packet-ansi_map.cModified
>   +13 -10packet-ber.c Modified
>   +2 -1  packet-ber.h Modif

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

[ronnie sahlberg]

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] On Behalf Of
> [EMAIL PROTECTED]
> Sent: Wednesday, May 02, 2007 2:35 PM
> To: [EMAIL PROTECTED]
> Subject: [Wireshark-commits] rev 21644: /trunk/epan/dissectors/
> /trunk/epan/dissectors/: packet-per.c
>
> http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=21644
>
> User: sahlberg
> Date: 2007/05/02 12:34 PM
>
> Log:
>  comment out a unused function so that wireshark builds on suse again
>
> Directory: /trunk/epan/dissectors/
>   ChangesPathAction
>   +2 -1  packet-per.cModified
>
> ___
> Wireshark-commits mailing list
> [EMAIL PROTECTED]
> http://www.wireshark.org/mailman/listinfo/wireshark-commits
> ___
> Wireshark-dev mailing list
> Wireshark-dev@wireshark.org
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] Fwd: FW: [PATCH] New protocol dissector - Kingfisher

[ronnie sahlberg]

can you please provide some example captures we can test the dissector with

you also have to terminate the value_string with a {0,NULL} entry or
it may SEGV if you receive a corrupted packet.



On 4/18/07, Rob Casey <[EMAIL PROTECTED]> wrote:
> Re-sent from Google mail due to local mail server issues.
>
>
> -- Forwarded message --
> From: Rob Casey <[EMAIL PROTECTED]>
> Date: Apr 19, 2007 9:02 AM
> Subject: FW: [PATCH] New protocol dissector - Kingfisher
> To: [EMAIL PROTECTED]
>
>
>
>  --
>  *From:* Rob Casey [mailto:[EMAIL PROTECTED]
> *Sent:* Thursday, 19 April 2007 12:20 AM
> *To:* 'wireshark-dev@wireshark.org'
> *Subject:* [PATCH] New protocol dissector - Kingfisher
>
>  To whom it may concern,
>
> Attached is a patch against the current subversion tree to incorporate a new
> dissector into Wireshark to implement support versions 2 and 3 of the
> Kingfisher protocol.  This protocol - derived from and very similar in
> structure to the Modbus TCP protocol - is used in communication between
> Kingfisher remote telemetry units (RTUs) and remote I/O devices within
> telemetry and SCADA systems - Further information about Kingfisher RTUs can
> be found at http://www.rtunet.com (or the parent corporate web site at
> http://www.cse-semaphore.com).
>
> It is worthy to note that while IANA has assigned the port number 4058 for
> Kingfisher communications via TCP and UDP (
> http://www.iana.org/assignments/port-numbers), this patch includes a define
> option to additionally dissect Kingfisher traffic directed to port 473 -
> This is the result of the historical use of this port by Series 2 Kingfisher
> RTUs for Kingfisher protocol traffic.
>
> Regards,
> Rob
>
>
>  Rob Casey
> R&D Manager
> RTUnet / CSE Semaphore Australia
> Unit 8, 3-5 Gilda Court
> Mulgrave, Victoria
> Australia
>
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev