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.
Yes.
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