Hi Al, thank you for the traces.
I tried to identify the canges between 1.6 (as it is in the Wireshark dissector right now or/and in the "TIPC 1.5/1.6 Protocol Specification") and 1.7 (as it is in the "TIPC Message Format Reference" or/and in the traces). I have to admit, that I didn't check the TIPC source for that. Could you please give me some comments when there is a questionmark, when it's incomplete or just wrong? It could be, that there are things mentioned that didn't change when I got them wrong before. In case fields were added, I'm going to dissect them in the future. I'm not going to remove fields, if they had a meaning *and* were evaluated before. DATA MESSAGE - "Options Position" was removed, this also means that there are no options added anymore BCAST_PROTOCOL - "originating node" and "destination node" are now set - "network id" is introduced MSG_BUNDLER - "message type" is now set - "broadcast ack no", "link level ack no" and "link level seq no" are now set - "originating node" and "destination node" are now set LINK_PROTOCOL - "originating node" and "destination node" are now set - "timestamp" is introduced although not used right now CONN_MANAGER - sequence number is obsolete and can be disabled since it was never really used - there is a 9th word added to the header, which holds "msg count". This field was only in the internal msg header for MSG_BUNDLER and CHANGEOVER_PROTOCOL before. What's the use of this field in here? ROUTE_DISTRIBUTOR - this changed heavily - now words 5, 6 and 7 are set and "item size" was added. - does the "standard route item" replace the old "Figure 32: External Routing Table message format" for the message types 0,1 and 2? Did msg types 3 and 4 stay as they were (just the added/removed "Node Address" in word 10)? - same question about "item size" as in NAME_DISTRIBUTOR. CHANGEOVER_PROTOCOL - "redundant link" is not used anymore - "originating node" and "destination node" are now set NAME_DISTRIBUTOR - "transport level sequence number" is not used any more - "item size" came up to determine the size of the publication. If this would e.g. be set to 2 there would only be "name type" and "name instance" in the publication - or is this always 7 now and might be different in future versions? - what is the exact meaning of "port id node", "scope" and "dist", which were added? MSG_FRAGMENTER - "originating node" and "destination node" are now set LINK_CONFIGURATION - "media id" was added in word 5 and "media address area" is a 4 word version of "bearer level originating address" Hope I overlooked only few things, Martin On 10/5/07, Stephens, Allan <[EMAIL PROTECTED]> wrote: > I'm posting the email below to let the rest of the TIPC world know that > Martin has got the TIPC 1.7 traffic examples he was asking for. I > didn't post it directly to the TIPC mailing list since I didn't want to > clutter up people's inboxes with the large attachment ... > > Regards, > Al > > -----Original Message----- > From: Stephens, Allan > Sent: Friday, October 05, 2007 1:22 PM > To: 'Martin Peylo' > Subject: RE: [tipc-discussion] Subdissectors for Wireshark Plug-in > > Hi Martin: > > I've attached a Wireshark capture file containing TIPC 1.7 traffic. It > should contain examples of most message classes (with the likely > exceptions of ROUTE_DISTRIBUTOR and CHANGEOVER_PROTOCOL). Please let me > know if you have any problems processing these packets. Once you're > happy with your results, let me know what else I need to send you to > help you complete your work in this area. > > Thanks, > Al > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of > > Martin Peylo > > Sent: Monday, October 01, 2007 1:12 PM > > To: [email protected] > > Subject: Re: [tipc-discussion] Subdissectors for Wireshark Plug-in > > > > Hi, > > > > i just wanted to announce that I uploaded the Wireshark changes for > > reassembling fragmented TIPCv2 packages. The dissector also tries to > > call heuristic dissectors for encapsulated protocols now. Until they > > release version 0.9.7 one has to grab the sources from SVN in order to > > > use the changes. > > > > I still have *not* received *any* traces for TIPC 1.7 to enhance the > > dissector for it. Is nobody using Wireshark for tracing? Please send > > samples to "tipc AT izac DOT de" - don't worry about filling up my > > mailbox, I'm my own email provider, so there should be > 100GB left > > ;-) > > > > Regards, > > Martin > > > > > > On 9/14/07, Martin Peylo <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > > > > > Since - anyone please correct me if I'm wrong - there could be > > > > > "Direct Addressed Messages" which have *no* port name set, > > > > [snip!] > > > > > Could anyone clarify for what reason "Directed > > Addressed Messages" > > > > > could occure, I acctually never traced them. > > > > > > > > TIPC's data messages (user values 0 through 3, representing "low > > > > priority" through "critical priority" application data) > > come in four > > > > flavours. > > > > > > Oh, I forgot mentioning that - for sure you have to set USER > > > corresponding to the used priority when doing: > > > dissector_add("tipc.usr", USER, my_proto_handle); > > > > > > > The "named" and "mcast" message types have info in the > > TIPC header > > > > to specify the message's destination (a port name and port name > > > > sequence, respectively); these message types typically > > occur when an > > > > application sends connectionless traffic. The "conn" > > type is used > > > > to carry connection-oriented traffic over an already established > > > > connection; since the sending socket/port already knows > > the port ID > > > > of the other end of the connection, there is no need for any port > > > > name information to be present in the TIPC header. > > > > > > There would be several ways to handle the dissection of > > > connection-oriented traffic in Wireshark: > > > a) implement some kind of connection tracking > > > b) using heuristic dissectors > > > c) just dissecting any TIPC data > > > > > > a) might be some work to do and it would not work if one starts > > > capturing after the connection is already established > > > b) Is reasonable extra work in the encapsulated data > > dissector, while > > > it might not be necessary for the beginning (i.e. when > > there is only > > > one encapsulated protocol used in the network). I'll submit > > the patch > > > for the heuristic dissection of TIPC data to the Wireshark guys as > > > soon as it is shown that it works. > > > c) might be the easiest way, while one has to do a) or b) > > when there > > > is more than one encapsulated protocol used in the network > > > > > > > The "direct" type is used to carry connectionless traffic to a > > > > destination that was specified using a port ID, rather > > than a port > > > > name; again, no port name info is present in the TIPC > > header because > > > > it is not required. Situations where this sort of > > message might be > > > > generated > > > > include: a) an application obtains a port ID as part of a > > > > subscription event generated by TIPC's topology server and then > > > > sends a message to that port ID (using sendto() or > > sendmsg()), and > > > > b) a server obtains a client's port ID when it receives a message > > > > from the client (using > > > > recvfrom() or recvmsg()) and then sends a reply back to > > that client > > > > port ID (using sendto() or sendmsg()). > > > > > > Here one has to stick to the options b) or c) mentioned above. Also > > > the publish messages the could be evaluated to associate > > the port IDs > > > with the port names. That would be some extra work... > > > > > > > [...] > > > > A number of changes were made to the header formats were > > made during > > > > the development of TIPC 1.7, and I'm not sure if the current > > > > Wireshark dissector for TIPC has been updated to reflect > > this. Most > > > > of the changes were relatively minor, so the existing dissector > > > > should still be OK for most purposes, but it would be nice to get > > > > things brought completely up to date. Martin, can you comment on > > > > the current state of things? > > > > > > So far I did not do anything for TIPC 1.7 - I didn't see > > that there > > > is already a "TIPC Message Format Reference". Since I have no > > > installation of 1.7 so far, could someone please send me > > captures of > > > the miscellaneous packages to "tipc AT izac DOT de"? > > > > > > Regards, > > > Martin > > > > > > > -------------------------------------------------------------- > > ----------- > > This SF.net email is sponsored by: Microsoft Defy all challenges. > > Microsoft(R) Visual Studio 2005. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > _______________________________________________ > > tipc-discussion mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/tipc-discussion > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > tipc-discussion mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/tipc-discussion > ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ tipc-discussion mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tipc-discussion
