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

Reply via email to