Wireshark

  • Riverbed Technology
  • WinPcap
the world's foremost network protocol analyzer
  • Wireshark
    • About
    • Download
    • Blog
  • Get Help
    • Ask a Question
    • FAQs
    • Documentation
    • Mailing Lists
    • Online Tools
    • Wiki
    • Bug Tracker
  • Develop
    • Get Involved
    • Developer's Guide
    • Browse the Code
    • Latest Builds

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

Date Index Thread Index Other Months All Mailing Lists
Date Prev Date Next Thread Prev Thread Next


From: Gerhard Gappmeier <gerhard.gappmeier@xxxxxxxxxxx>
Date: Mon, 07 May 2007 15:22:24 +0200

Hi,

> A fuzzed Sample.cap file (attached) crashed TShark and took a *very*
> long time (2 mins) to load in WS.
>
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.
>
> 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.
> 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.

regards,
Gerhard.


  • Follow-Ups:
    • Re: [Wireshark-dev] OpcUa update
      • From: Gerald Combs
    • Re: [Wireshark-dev] OpcUa update
      • From: Ulf Lamping
  • References:
    • Re: [Wireshark-dev] OpcUa update
      • From: Ulf Lamping
  • Prev by Date: Re: [Wireshark-dev] [Wireshark-commits] rev21705:/trunk//trunk/plugins/asn1/:asn1.hpacket-asn1.c/trunk/epan/dissectors/:packet-MAP_DialoguePDU.cpacket-acp133.cpacket-acse.cpacket-ansi_map.c packet-ber.cpacket-ber.hpacket-camel.c ...
  • Next by Date: Re: [Wireshark-dev] [Wireshark-commits]rev21705:/trunk//trunk/plugins/asn1/:asn1.hpacket-asn1.c/trunk/epan/dissectors/:packet-MAP_DialoguePDU.cpacket-acp133.cpacket-acse.cpacket-ansi_map.cpacket-ber.cpacket-ber.hpacket-camel.c ...
  • Previous by thread: Re: [Wireshark-dev] OpcUa update
  • Next by thread: Re: [Wireshark-dev] OpcUa update
  • Index(es):
    • Date
    • Thread

Wireshark and the "fin" logo are registered trademarks of the Wireshark Foundation