> Hi, > > > Re-sending due to lack of acknowledgement/response: > > > > Ethereal (v0.10.4) is reporting received ASF RMCP ACK packets > > as being "malformed" when they appear to be perfectly > valid. Example: > > > > 0000 00 0f 1f d7 cd 46 00 b0 d0 21 00 48 08 00 45 00 > > 0010 00 20 3d 9a 00 00 20 11 fd 44 ac 10 01 ef ac 10 > > 0020 05 df 02 6f 02 6e 00 0c 93 84 06 00 01 86 00 00 > > 0030 00 00 00 00 00 00 00 00 00 00 00 00 > > > > This is an ASF RMCP ACK of an ASF RMCP Capabilities Request packet. > > > > I can only guess that Ethereal is assuming that ASF RMCP ACK > > packets are supposed to include a data block, when in fact > they do not > > (see section 3.2.2.1 Note 1 in the ASF Specification). > > > > Perhaps someone on the Ethereal development team can point > > out exactly what it is that Ethereal is expecting, but not > finding, in > > this packet? > > There is a development list you might use if you are trying > specifically to contact developers -althouth I believe most > of them subscribe to this also-. > > I suppose nobody can immediately derive your problem from > your description, so if you attach a trace -the trace file > with the packet, not only the hex dump- I can try and have a > look at it; with the disclaimer that I don't know a bit > about ASF, I can only try and find the place where the > program is expecting > something it does not find. If you add a pointer to the ASF > Specification it would probably also help. I attached a trace file that demonstrates this problem (a valid RMCP ack packet reported as "malformed" by Ethereal). Here's a link to the ASF specification: http://www.dmtf.org/standards/documents/ASF/DSP0136.pdf -Rob
Attachment:
bad_rmcp_ack
Description: Binary data
Powered by MHonArc 2.6.10