Wireshark-dev: Re: [Wireshark-dev] OpcUa update
From: Ulf Lamping <[email protected]>
Date: Wed, 09 May 2007 09:48:30 +0200
Gerhard Gappmeier wrote:
Nevertheless I attached an update where I fixed the missing { 0, NULL }entries
in the value_string arrays.
Good, that had to be fixed anyway.
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.
I found the reason for the problem:

This is not a bug in your code, but a problem which seems to be newly introduced in MSVC2005 (compared to MSVC6) with the changes to localtime (localtime64 was introduced).
Calling localtime with a fairly huge value 218939827321, causes it to 
crash (to my feeling, localtime should accept all values in the possible 
range). This is triggered in to_str.c function *abs_time_to_str()*, 
around line 482, caused by a field named "PublishTime" - as I don't have 
the context, I don't know where the exact opcua code is that triggered 
this - but it doesn't really matter.
However, this is a problem in the call to localtime and not in your 
code. As a first try, I'd put a simple "if(abs_time->secs > 2000000000)" 
in the code, so the problematic localtime call is not triggered when the 
value is too large (but that's probably an ugly hack). After this, the 
fuzz tests on your code runs smoothly now (at least so far ;-).
I'll take a deeper look at your code if I've fixed the current problem ...
In the GUI it also works, just shows malformed packets which is normal when you modify the capture file with garbage.

The slowness I've noticed was caused by slow network name resolution. This should be catched by ADNS (which is existing and enabled), but seems to currently work not. I don't know the real cause (maybe MSVC2005 DLL problems?), but switching off network name resolution works for now (one problem at a time).
Regards, ULFL