> On 05/28/2010 06:59 AM, Masatake YAMATO wrote: >>>>> On 5/27/2010 at 04:26 AM, "Caplan, Michael"<[email protected]> wrote: >>>>>> Is there a corosync dissector available for Windows based Wireshark? >>>>> >>>>> I suspect the short answer to your question is "no". Work has been >>>>> done in this area, but this doesn't appear to have ever made it into >>>>> upstream Wireshark. See: >>>>> >>>>> >>>>> https://lists.linux-foundation.org/pipermail/openais/2009-February/010603.html >>>>> >>>>> There's an enhancement request for this filed upstream, with a patch >>>>> for totemnet and totemsrp support: >>>>> >>>>> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3232 >>>>> >>>>> However, this doesn't appear to have seen any action since May last >>>>> year. >>>> >>>> Yes. As explained in the comment in bugs.wireshark.org, I have to >>>> rewrite encryption/decryption code with using a library in wireshark; >>>> in my old patch, I wrote the code based on code in corosync. It is a >>>> bit >>>> hard work for me. About upper layer, there is a good news. These days >>>> we can write wireshark dissector in lua or python. >>>> >>>> BTW, Has the wire format of totemsrp changed since May last year? >>>> >>> no >> >> Steven, I have two more questions. >> >> >> Merge trunk revision 2660: >> r2660 | sdake | 2010-02-18 13:08:39 -0700 (Thu, 18 Feb 2010) | 3 lines >> >> Patch to set unset value in token hold cancel structure as to not >> crash >> wireshark. >> >> Index: exec/totemsrp.c >> =================================================================== >> --- exec/totemsrp.c (revision 2659) >> +++ exec/totemsrp.c (revision 2660) >> @@ -2627,6 +2627,7 @@ >> */ >> token_hold_cancel.header.type = MESSAGE_TYPE_TOKEN_HOLD_CANCEL; >> token_hold_cancel.header.endian_detector = ENDIAN_LOCAL; >> + token_hold_cancel.header.encapsulated = 0; >> token_hold_cancel.header.nodeid = instance->my_id.addr[0].nodeid; >> memcpy (&token_hold_cancel.ring_id,&instance->my_ring_id, >> sizeof (struct memb_ring_id)); >> >> 1. It seems that you used wireshark with my patch. >> Did my patch work well? >> >> I don't well about corosync yet. (I started writing the patch to learn >> the protocol.) So I don't convince myself that my patch covers whole >> the >> protcol. If you have something unsatisfied with my patch, please let >> me >> know. >> >> This question is applicable to the other corosync/openais experts. >> Any comments are welcome. >> >> 2. In the revision 2660 of corosync, you wrote "to not crash >> wireshark". >> If wireshark crashes, it is a bug of my side. I'd like to fix it >> anyway. >> >> I've looked at `encapsulated' field related code in my patch but I >> cannot find my mistake. So the question is "did wireshark really >> crash?" >> >> I guess, the wireshark didn't crash but could not recognize the >> corosync >> protocol; it just report it as UDP diagram. >> >> > > I don't have alot of details; HJ Lee in the community reported the > problem and submitted the patch. I have not tried wireshark although > it would be great if the wireshark code was merged, even without > encryption support, upstream. This would aid people in debugging.
Thanks, I'll contact HJ Lee. BTW, I'm happy if you put contributors name in the log of each `svn commit'. So I can know the contributors and contact them when I find something interesting in the log. The contributors may be happy and encouraged, too if their efforts are recorded officially. Masatake YAMATO > Regards > -steve > >> Regards, >> Masatake YAMATO > _______________________________________________ Openais mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/openais
