Hi Ulf,
I still cannot reproduce your problem.
Also with "tshark -Vxr Sample.cap".
Nevertheless I attached an update where I fixed the missing { 0, NULL
}entries
in the value_string arrays.
I also attached the result of tshark so you can compare it with yours.
Is the access violation catched in any way and produces only a log
entry,
or should I see an "Access Violation" message box?
I could not find any access violation entry in the file,
nor do I get a messagebox. It seems to just work for me.
In the GUI it also works, just shows malformed packets which is normal
when you modify the capture file with garbage.
regards,
Gerhard.
Ulf Lamping schrieb:
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
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev
|
Attachment:
opcua.zip
Description: Zip compressed data
Attachment:
result.zip
Description: Zip compressed data