Re: [Wireshark-dev] Conversations - addresses/ports, more general endpoints, and "circuits" with their own IDs

2019-01-07 Thread Guy Harris
On Jan 7, 2019, at 10:16 AM, Jaap Keuter wrote: > On 6 Jan 2019, at 19:54, Guy Harris wrote: > >> And not all conversations necessarily have specific endpoints. > > You mean, where the wildcards come into play? That too, but I was thinking of, for example, a "conversation" that includes all

Re: [Wireshark-dev] Conversations - addresses/ports, more general endpoints, and "circuits" with their own IDs

2019-01-07 Thread Jaap Keuter
> On 6 Jan 2019, at 19:54, Guy Harris wrote: > > On Jan 6, 2019, at 10:30 AM, Jaap Keuter wrote: > >> Rather than simplistic endpoint ID’s I think we need an ID tuple per >> endpoint, > > How is a tuple not itself an ID? It is, just not limited to the address/port combinations most of them

Re: [Wireshark-dev] Conversations - addresses/ports, more general endpoints, and "circuits" with their own IDs

2019-01-06 Thread Guy Harris
On Jan 6, 2019, at 10:30 AM, Jaap Keuter wrote: > Rather than simplistic endpoint ID’s I think we need an ID tuple per endpoint, How is a tuple not itself an ID? And not all conversations necessarily have specific endpoints. > which may be combined with one (or more) other tuples representing

Re: [Wireshark-dev] Conversations - addresses/ports, more general endpoints, and "circuits" with their own IDs

2019-01-06 Thread Jaap Keuter
Hi list, Rather than simplistic endpoint ID’s I think we need an ID tuple per endpoint, which may be combined with one (or more) other tuples representing single (and multipoint) connections. Examples are an aggregating tap/monitor port which monitors various VLANs, or an MPLS link. Or even

Re: [Wireshark-dev] Conversations - addresses/ports, more general endpoints, and "circuits" with their own IDs

2019-01-06 Thread Roland Knall
I am very much in favor for this development. There are aggregated protocols out there, where multiple packets are transported in a single frame, and it would very much make sense to be able to individually have them added to conversations. I think, from a conversation endpoint it should simply

Re: [Wireshark-dev] Conversations - addresses/ports, more general endpoints, and "circuits" with their own IDs

2019-01-05 Thread Luke Mewburn
[attempting a resend, 13 months later] On Sat, Oct 28, 2017 at 08:12:53PM -0700, Guy Harris wrote: | Michael Mann is looking at generalizing conversations to handle | arbitrary endpoints, presumably not necessarily in the form of an | AT_ address plus a PT_ numeric port ID. | | [...]

Re: [Wireshark-dev] Conversations - addresses/ports, more general endpoints, and "circuits" with their own IDs

2019-01-05 Thread Luke Mewburn
On 17-10-28 20:12, Guy Harris wrote: | Michael Mann is looking at generalizing conversations to handle | arbitrary endpoints, presumably not necessarily in the form of an | AT_ address plus a PT_ numeric port ID. Hi Guy, Was there any further development on this topic? (I did try & send a

[Wireshark-dev] Conversations - addresses/ports, more general endpoints, and "circuits" with their own IDs

2017-10-28 Thread Guy Harris
Michael Mann is looking at generalizing conversations to handle arbitrary endpoints, presumably not necessarily in the form of an AT_ address plus a PT_ numeric port ID. We also have the notion of "circuits", which are like conversations except that they're identified by a single "circuit ID"

[Wireshark-dev] Conversations lifetime

2014-04-15 Thread David Ameiss
I could be wrong, but I could swear that, until recently, conversations essentially had capture lifetime. So that, from one pass of the capture to the next, the conversations (and any proto data stored in them) remained. That does not seem to be the case now. Between one pass of the capture

Re: [Wireshark-dev] Conversations lifetime

2014-04-15 Thread Evan Huus
On Tue, Apr 15, 2014 at 1:57 PM, David Ameiss netsh...@ameissnet.com wrote: I could be wrong, but I could swear that, until recently, conversations essentially had capture lifetime. So that, from one pass of the capture to the next, the conversations (and any proto data stored in them)

Re: [Wireshark-dev] Conversations lifetime

2014-04-15 Thread David Ameiss
On 04/15/2014 02:18 PM, Evan Huus wrote: On Tue, Apr 15, 2014 at 1:57 PM, David Ameiss netsh...@ameissnet.com wrote: I could be wrong, but I could swear that, until recently, conversations essentially had capture lifetime. So that, from one pass of the capture to the next, the conversations

Re: [Wireshark-dev] Conversations lifetime

2014-04-15 Thread Guy Harris
On Apr 15, 2014, at 12:43 PM, David Ameiss netsh...@ameissnet.com wrote: It was apparently me. I setup some synthetic conversations (based on advertisements) with frame 0 In at least some places in Wireshark, a frame number of 0 is used to mean the frame number isn't known (or isn't known

[Wireshark-dev] Conversations?

2006-11-16 Thread Anergy Virt
Hi Some newbie questions: I want to ask how can I add extensions to current conversation in Wireshark for a protocol? Is there any startup resource available like README.xxx? Secondly how can one find out which tap is implemented in which file..for instance I am interested in tap for rsvp

Re: [Wireshark-dev] conversations

2006-10-04 Thread Brian Vandenberg
What is a conversation? I've looked in a few of the readmes, I've looked in the developer's guide, and googled for it on the wireshark.org site, and the term is never given much in the way of a definition. So, just what is one? -Brian ___

Re: [Wireshark-dev] conversations

2006-10-04 Thread Jaap Keuter
Hi, See README.developer chapter 2.2, and the epan/conversation.c is well documented. Thanx, Jaap On Wed, 4 Oct 2006, Brian Vandenberg wrote: What is a conversation? I've looked in a few of the readmes, I've looked in the developer's guide, and googled for it on the wireshark.org site,