Richard, Guy,
parallel thinking - I noticed that theres not much difference in the data
portion of the packet between the frame that works and the one that GPF's
other than the Last Write timestamps, and I also noted that the date in the
packet that does decode (ie packet 292), as reported by tethereal/ethereal
is also strange:
Last Write Date: 1977-07-22
and that definitely not correct.....
(but having said that, the particular fragment/capture run is from an
application about which I currently know very little, but would expect
'last write' dates/times to be very close to current.....)
The machine generating the packet is an NT4 server - os details reported
as:
"Microsoft (R) Windows NT (TM) Server
Version 4.0 (Build 1381: Service Pack 4) x86 Multiprocessor Free"
and as far as I know is a fairly standard server build, but I havnt looked
too closely as yet.
regards,
Michael Hennessy
------------------------------------------------------------------------
----------
Excalibur Engineering Pty. Ltd.
Mobile Phone No : (+61) 0411 789392
Office Phone No. : (+61) 0249 400133
Office Fax No. : (+61) 0249 400266
Email Address : hennessy@xxxxxxxxxxxxxxxx
Postal Address : PO Box 1088 Newcastle NSW 2300, Australia
Street Address : 80 Chin Chen Street, Islington,
Newcastle, 2296, Australia
------------------------------------------------------------------------
----------
On Sunday, December 17, 2000 8:41 AM, Richard Sharpe
[SMTP:sharpe@xxxxxxxxxx] wrote:
> At 12:17 PM 12/16/00 -0800, Guy Harris wrote:
> >On Sun, Dec 17, 2000 at 12:23:29AM +1000, Richard Sharpe wrote:
> >> Well, I have confirmed that the packet crashes Ethereal under Win95,
and is
> >> read OK under Linux.
> >
> >...but gives a rather, umm, *interesting* value for the Last Write Date
> >and Last Write Time - a pre-war date, and by "pre-war" I mean prior to
> >the Great War, i.e. 1905-05-26.
> >
> >It turns out that the MSVC++ version of "gmtime()" returns NULL if
> >handed a date/time that predates the Epoch, and 1905-05-26 is about 64
> >1/2 years before the Epoch.
>
> OK, I have determined that the original code is decoding the date
> correctly. At least, it handles the dates returned from Samba. I do not
> know about dates returned from NT.
>
> What was that capture captured from?
>
> I suspect that we will have to code around the problem in this case.
>
> >I shall have to check some notes at work, but I suspect that the date
> >and time in this reply is *not* in the weird almost-UNIX-like date and
> >time format used by some SMB requests and replies, but may, instead, be
> >in DOS date/time format.
> >
> >If I apply the attached patch to "packet-smb.c", which changes the code
> >to assume a DOS date/time format in an SMB Get Attributes reply (and
> >also fixes the code that displays the date and time to use the correct
> >offsets when putting entries into the protocol tree), the last modified
> >date and time becomes 1996-08-00 16:51:56, which, although it's over
> >four years ago, is more likely to be correct than is a date near the
> >turn of the century.
> >
> >I shall compare its dissection with what Microsoft's Network Monitor
> >claims to be the date and time.
> >
>
> Regards
> -------
> Richard Sharpe, sharpe@xxxxxxxxxx
> Samba (Team member, www.samba.org), Ethereal (Team member, www.zing.org)
> Contributing author, SAMS Teach Yourself Samba in 24 Hours
> Author, Special Edition, Using Samba
>