[Gerhard Gappmeier <gerhard.gappmeier@xxxxxxxxxxx>]

Hi Ulf,

sounds good.

Ragarding VS2005. I know that problem from other projects.

• time_t is 64 bit now: Use the define _USE_32BIT_TIME_T to make it backward compatible
• wchar_t is a built-in type now. This may also cause problems, because it was a "unsigned short" before. But you can switch this off too with a compiler switch.
• Use _CRT_SECURE_NO_DEPRECATE to avoid anoying warnings about ANSI C functions
  

regards,
Gerhard.

Ulf Lamping schrieb:

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

_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev