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
