Wireshark-dev: Re: [Wireshark-dev] OpcUa update

From: Ulf Lamping <ulf.lamping@xxxxxx>
Date: Mon, 07 May 2007 22:08:41 +0200

Gerhard Gappmeier wrote:

it loads the file imediately on my computer without any delay.
I tried the fuzzy file also with tshark.
I called "tshark -r sample.cap", is this right?
Because it didn't crash for me. I tried it several times.

Any ideas why it behaves different for you?
I'm currently working on revision 21246.
Compiled with VC6 on windows.

Gerald already gave you some notes. BTW: accessing "unknown" memory can result in virtually *every* possible response ...

Some points that I've seen immediately:
- you *must* end *every* value_string you use by a an ending sequence
{ 0, NULL }, otherwise unexpected values coming from the network will
result in an access

Ok, I'll fix that.

That's the main point that *needs* to be fixed and I guess it's the cause of the regression test problems. Unless there are other problems as well ;-)

violation, as the corresponding access functions will run into the
wrong memory areas
- e.g. opcua.c / g_szMessageTypes unnecessarily re-implements a
value_string - this bloats code size and complexity

I don't know how to do this with value_string.
I'm parsing textual protocol message signatures and not numbers:
e,g, "UATH" -> "Hello Message"
      "UAMA" -> "Abort Message"
      ...
static char* g_szMessageTypes[] =
{
    "Hello message",
    "Acknowledge message",
    "Disconnect message",
    "Data message, last chunk in message.",
    "Data message, further chunks must follow.",
    "Abort message",
    "Error message",
    "Invalid message",
    "Unknown message"
};
How does this small string table bloat the code size?
It wouldn't be smaller with value_string.
And the parsing code always defaults to "Unkown message", so there is no
way for an out of bounds szenerio
like with the value_string arrays and so I don't need NULL at the end here.

Sorry for the noise, I didn't saw the pfctParse, so you'll actually need the if/switch construct anyway, regardless of the strings - just forget this one ...

Regards, ULFL