Re: [Wireshark-dev] Global conversation
Anders Broman skrev 2011-10-07 18:10: Mike Morrin skrev 2011-10-07 17:48: I think that it should be a bit more flexible: * Have conversations per protocol, with 1 or more identifier keys. * When a new identifier is observed, if it can be associated with an existing conversation which was created with a different key, then add the new key to the existing conversation, otherwise create a new conversation with the new key. * Allow conversations to be associated with conversations in other protocols. The set of associated conversations becomes the global conversation, but is flexible in terms of the sequence of build-up of supporting protocols. * A dissector can use a protocol/key pair to find a potentially associated conversion already existing in another protocol. * A dissector can access the set of keys for any protocol in an associated conversation How about something like * proto_conv_new(proto ,key(s)) Check if global/top/main conversation exist by matching the key with other protocols using that key. ( string key looking in a (hash)table of strings finding list of proto_conv ?) if not create it and create the proto_conv. Return proto_conv and possible top_conv * proto_conv_add_key(proto, key(s)); if a new key has turned up in the conversation look if there are matching proto_convs with a different top_conv if true join them. I'm sure there are many pitfall here and with phone call as an example what if two consecutive calls are made how to differentiate between them. Not sure that this as big a problem as it first seems: at some layer at least the protocol itself has this ambiguity, so it can provide an end of conversation explicitly - in fact I have previously thought this would be a good thing to add to the current conversations to distinguish re-use of identifiers in a new conversation. Another mater is performance and memory consumption. One awkward relationship to consider is that conversations in different protocols at different layers have different multiplicity relationships with the conversations above and below them, e.g. a MAC layer conversation may have multiple RLC conversations carried over it (or specifically in 3G, an RRC connection can be associated with multiple RABs), and in some cases a high level call may be carried over several different bearers (e.g. in 3G SRBs and RABs associated with voice call). It would be really useful to be able to filter on this relationship at any level, so a filter on a conversation at a layer which includes a multiplexor may get multiple higher layer conversations included, and filtering on any one of these higher conversations excludes the other higher layer conversations, but still includes the lower layer multiplex conversation which carries it. Perhaps you could consider conversations to be any such general relationship between endpoints, no matter how dynamic, e.g. in 3G TCP/IP/Ethernet terms, an Ethernet conversation can carry multiple IP conversations (and other protocol conversations), each of which can carry the TCP conversations, each of which may carry signalling for (typically more dynamic) higher layer conversations. Or has this abstracted too far? If the above could be made to work in a general way, the current bloat of the packet info structure might be reduced, as it tends to get custom data to handle some of the specific relationships. Neil This message contains confidential information and may be privileged. If you are not the intended recipient, please notify the sender and delete the message immediately. ip.access Ltd, registration number 3400157, Building 2020, Cambourne Business Park, Cambourne, Cambridge CB23 6DW, United Kingdom ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org 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] Global conversation
On Oct 7, 2011, at 5:51 AM, Anders Broman wrote: I've been contemplating the idea of making it possible to filter a call in the Telco world that could involve A multitude of protocols for example SIP, DIAMETER, H248, ISUP, BICC and a number of Mobile protocols. I suppose this is What mate tries to do. Has anybody written MATE For Dummies? It sounds fascinating and powerful, but I've never taken the time to look at it in detail, and it looks as if it has a steep learning curve. Perhaps it could be done if we had a Global conversation to which you cold add a List of per protocol conversations. One problem is to make it generic enough and in this particular scenario the subscriber number or similar would be the thing gluing the conversations together and that would only be Available in some messages. Another problem is when to create the global conversation e.g. what is the start. Presumably by a global conversation you mean a set of global conversations, i.e. that there wouldn't be a *single* global conversation - if you have multiple calls in a capture, each one would have a global conversation. The notion of a conversation being associated with a protocol in a broader sense than a registered Wireshark protocol would appear elsewhere, e.g. an NFSv2 or NFSv3 conversation could include mount, lock manager, quota daemon, etc. traffic. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org 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] Global conversation
Thus wrote Guy Harris (g...@alum.mit.edu): We should probably also add a notion of conversations available to dissectors at multiple layers (a notion more general than the current address-and-port-endpoint-pair notion, that can include multiple address layers, circuits for protocols that have a virtual circuit ID of some sort, and conversations at layers above the transport layer) that would definitely be helpful. As far as I can see, DVB-CI is an example that does not fit into the current mechanism very well. CI is not based on tcp/ip, a ci session looks like open_session_request(resource_id) session_opened(newly assigned session number) payload transfer(session_number, payload data) ... close session(session_number) For now, how would you create a conversation from this? I've been playing with a new port_type PT_DVBCI_SESSION_NUMBER and set both source and destination port to the session number. Does that make sense or is there a better approach? Thanks, Martin I've been contemplating the idea of making it possible to filter a call in the Telco world that could involve A multitude of protocols for example SIP, DIAMETER, H248, ISUP, BICC and a number of Mobile protocols. I suppose this is What mate tries to do. Perhaps it could be done if we had a Global conversation to which you cold add a List of per protocol conversations. One problem is to make it generic enough and in this particular scenario the subscriber number or similar would be the thing gluing the conversations together and that would only be Available in some messages. Another problem is when to create the global conversation e.g. what is the start. Thoughts? Regards Anders ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org 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 wireshark-dev@wireshark.org 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] Global conversation
On Fri, Oct 07, 2011 at 02:51:35PM +0200, Anders Broman wrote: Perhaps it could be done if we had a Global conversation to which you cold add a List of per protocol conversations. We could create a new set of conversation functions, such as: global_conversation_new() global_find_conversation() global_conversation_add_proto_data() (Although using global makes them a bit long) One problem is to make it generic enough and in this particular scenario the subscriber number or similar would be the thing gluing the conversations together and that would only be Available in some messages. Another problem is when to create the global conversation e.g. what is the start. Using a unique piece of information, such as the phone number, would allow each dissector that is capable of working with that global conversation to look up if it has already been created. Perhaps two pieces of informatino would be needed: a type of information and the information, e.g. PHONE_NUMBER and +111 or something more generic like passing a string phone-number and then the number itself. It sounds like a good idea, but would just need a few decisions to be made first. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org 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] Global conversation
-Original Message- From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Stephen Fisher Sent: 07 October 2011 16:32 To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] Global conversation On Fri, Oct 07, 2011 at 02:51:35PM +0200, Anders Broman wrote: Perhaps it could be done if we had a Global conversation to which you cold add a List of per protocol conversations. We could create a new set of conversation functions, such as: global_conversation_new() global_find_conversation() global_conversation_add_proto_data() (Although using global makes them a bit long) One problem is to make it generic enough and in this particular scenario the subscriber number or similar would be the thing gluing the conversations together and that would only be Available in some messages. Another problem is when to create the global conversation e.g. what is the start. Using a unique piece of information, such as the phone number, would allow each dissector that is capable of working with that global Conversation to look up if it has already been created. Perhaps two pieces of informatino would be needed: a type of information and the information, e.g. PHONE_NUMBER and +111 or something more generic like passing a string phone-number and then the number itself. It sounds like a good idea, but would just need a few decisions to be made first. I think that it should be a bit more flexible: * Have conversations per protocol, with 1 or more identifier keys. * When a new identifier is observed, if it can be associated with an existing conversation which was created with a different key, then add the new key to the existing conversation, otherwise create a new conversation with the new key. * Allow conversations to be associated with conversations in other protocols. The set of associated conversations becomes the global conversation, but is flexible in terms of the sequence of build-up of supporting protocols. * A dissector can use a protocol/key pair to find a potentially associated conversion already existing in another protocol. * A dissector can access the set of keys for any protocol in an associated conversation This message contains confidential information and may be privileged. If you are not the intended recipient, please notify the sender and delete the message immediately. ip.access Ltd, registration number 3400157, Building 2020, Cambourne Business Park, Cambourne, Cambridge CB23 6DW, United Kingdom ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org 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] Global conversation
Mike Morrin skrev 2011-10-07 17:48: -Original Message- From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Stephen Fisher Sent: 07 October 2011 16:32 To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] Global conversation On Fri, Oct 07, 2011 at 02:51:35PM +0200, Anders Broman wrote: Perhaps it could be done if we had a Global conversation to which you cold add a List of per protocol conversations. We could create a new set of conversation functions, such as: global_conversation_new() global_find_conversation() global_conversation_add_proto_data() (Although using global makes them a bit long) One problem is to make it generic enough and in this particular scenario the subscriber number or similar would be the thing gluing the conversations together and that would only be Available in some messages. Another problem is when to create the global conversation e.g. what is the start. Using a unique piece of information, such as the phone number, would allow each dissector that is capable of working with that global Conversation to look up if it has already been created. Perhaps two pieces of informatino would be needed: a type of information and the information, e.g. PHONE_NUMBER and +111 or something more generic like passing a string phone-number and then the number itself. It sounds like a good idea, but would just need a few decisions to be made first. I think that it should be a bit more flexible: * Have conversations per protocol, with 1 or more identifier keys. * When a new identifier is observed, if it can be associated with an existing conversation which was created with a different key, then add the new key to the existing conversation, otherwise create a new conversation with the new key. * Allow conversations to be associated with conversations in other protocols. The set of associated conversations becomes the global conversation, but is flexible in terms of the sequence of build-up of supporting protocols. * A dissector can use a protocol/key pair to find a potentially associated conversion already existing in another protocol. * A dissector can access the set of keys for any protocol in an associated conversation Something like that is what I was thinking about. /Anders This message contains confidential information and may be privileged. If you are not the intended recipient, please notify the sender and delete the message immediately. ip.access Ltd, registration number 3400157, Building 2020, Cambourne Business Park, Cambourne, Cambridge CB23 6DW, United Kingdom ___ Sent via:Wireshark-dev mailing listwireshark-dev@wireshark.org 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 wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
