[Linux-cluster] wireshark dissector for DLM

Patrick Caulfield pcaulfie at redhat.com
Tue Dec 11 14:22:32 UTC 2007


Masatake YAMATO wrote:
>>> Hi,
>>>
>>> I've submitted a patch to dissect communications between DLM3 nodes.
>>> The patch is not accepted as part of wireshark.
>>> However, I hope the patch itself may be useful for you.
>>> So I'd like to introduce the page where I submitted the patch.
>>>
>>> http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2084
>> That's nice work, thank you !
>>
>> Has it been refused for inclusion or are they just wanting some minor
>> points changed? It looks like the latter to me. It would be great if
>> this could be included with a wireshark release, building it yourself
>> can be a bit of an adventure ;)
> 
> Now the patch is accepted. So you don't have to apply the patch
> by yourself. However, you have to build by yourself.
> 
> For trying the patch:
> 
>      (1) install autotools, svn, gcc and pcap library to your system.
>      (2) do 
>      	 $ svn co http://anonsvn.wireshark.org/wireshark/trunk/ wireshark
>      (3) do
>          $ cd wireshark; ./autogen.sh; ./configure; make; ./wireshark
>      (4) touch /mnt-where-gfs-is-mounted/something-file
> 
> If GUI labels explaining the protocol is broken or not good, 
> please, let me know. 
> 
> 
> Which protocol you want to dissect next?
> totem? udp:5405 may be the target.
> 
>     # Please read the openais.conf.5 manual page
> 
>     totem {
> 	    version: 2
> 	    secauth: off
> 	    threads: 0
> 	    interface {
> 		    ringnumber: 0
> 		    bindnetaddr: 192.168.2.0
> 		    mcastaddr: 226.94.1.1
> 		    mcastport: 5405
> 	    }
>     }
> 
>     logging {
> 	    debug: off
> 	    timestamp: on
>     }
> 
>     amf {
> 	    mode: disabled
>     }
> 
> 
> I'd like to provide dissectors for all protocols used in RHCS and
> GFS. The dissectors may be useful for shooting troubles and
> understanding the software.  However, I have limited time to hack, so
> I have to prioritize protocols. Inputs are welcome.

I think totem would be the next most useful one, yes.

Personally I'd like the old kernel (RHEL4) cman protocol done, but
obsolete protocols are probably not a good use of your time ;-)

Patrick




More information about the Linux-cluster mailing list