Mailing List Archive: Ethereal: dev

RE: [Ethereal-users] ethereal v0.8.14.1 and 0.8.14 on NT4SP5 grabs a packet it GPF's when decoding

Index | Next | Previous | View Threaded

hennessy at excalibureng

Dec 15, 2000, 8:41 PM

Post #1 of 15 (378 views)
Permalink

RE: [Ethereal-users] ethereal v0.8.14.1 and 0.8.14 on NT4SP5 grabs a packet it GPF's when decoding

Hi all,

I've got a problem with a particular packet that relaibly GPF's ethereal
and tethereal (on NT4). Per Gilbert's Ramirez's suggestion I'm posting the
packet concerned to ethereal-dev for comment....

Actually, attached are two frames from a recent capture session I did -
frame numbers 292 and 13097- both are extracted from the same capture dump
(of 100,000 frames) using editcap, and one reliably GPF's my ethereal and
tethereal v0.8.14.1 when trying to decode it.

dump file tcap3.13097 is the one that doesnt decode, whilst tcap3.292 is OK
- its picked purely because its the first frame in the session of the same
general type (ie SMBgetattr) , but doesnt display this problem - ie it
decodes in tethereal/ethereal without crashing.

Using a combination of windump (the windows tcpdump) and a slightly
modified version of a script called tcpformat.pl I found, I've managed to
decode the bad frame to the point where I think the problem is probably in
the SMB decoding portion (although I havnt checked the checksums in the IP
and TCP headers as yet - thats the next job).

The commands used to do this decoding are below and the files generated
from them are attached, in case it helps anyone more savvy with SMB packet
formats than I to spot whats up.

windump -e -x -r tcap3.292 | perl tcpformat.pl > tcap3.292.tcpformat.txt
windump -e -x -r tcap3.13097 | perl tcpformat.pl >
tcap3.13097.tcpformat.txt

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 [at] excalibureng

Postal Address : PO Box 1088 Newcastle NSW 2300, Australia
Street Address : 80 Chin Chen Street, Islington,
Newcastle, 2296, Australia
------------------------------------------------------------------------
----------

On Friday, December 15, 2000 11:55 PM, Gilbert Ramirez
[SMTP:gram [at] xiexie] wrote:
> On Fri, 15 Dec 2000 15:44:16 +1000
> Michael Hennessy <hennessy [at] excalibureng> wrote:
>
> > The packet in question is available for testing if someone wants to
have a
> > go at it - its only 153 bytes long.
> >
>
> That's what we need. Either send the packet trace to ethereal-dev,
> if it can be made public, or send it to me or another Ethereal
> developer with instructions not to make it public.
>
> --gilbert

Attachments:

tcap3.292 (0.15 KB)

tcap3.13097 (0.15 KB)

tcap3.292.tcpformat.txt (1.01 KB)

tcap3.13097.tcpformat.txt (1.01 KB)

sharpe at ns

Dec 16, 2000, 7:23 AM

Post #2 of 15 (372 views)
Permalink

Re: RE: [Ethereal-users] ethereal v0.8.14.1 and 0.8.14 on NT4SP5 grabs a packet it GPF's when decoding [In reply to]

Hi,

Well, I have confirmed that the packet crashes Ethereal under Win95, and is
read OK under Linux.

I do not have a build environment for Win9X or NT, so I cannot do much
more, and I do not currently have the time to create a build environment
for Win9X or NT either.

At 01:41 PM 12/16/00 +1000, Michael Hennessy wrote:
>
>Hi all,
>
>I've got a problem with a particular packet that relaibly GPF's ethereal
>and tethereal (on NT4). Per Gilbert's Ramirez's suggestion I'm posting the
>packet concerned to ethereal-dev for comment....
>
>Actually, attached are two frames from a recent capture session I did -
>frame numbers 292 and 13097- both are extracted from the same capture dump
>(of 100,000 frames) using editcap, and one reliably GPF's my ethereal and
>tethereal v0.8.14.1 when trying to decode it.
>
>dump file tcap3.13097 is the one that doesnt decode, whilst tcap3.292 is OK
>- its picked purely because its the first frame in the session of the same
>general type (ie SMBgetattr) , but doesnt display this problem - ie it
>decodes in tethereal/ethereal without crashing.
>
>
>
>Using a combination of windump (the windows tcpdump) and a slightly
>modified version of a script called tcpformat.pl I found, I've managed to
>decode the bad frame to the point where I think the problem is probably in
>the SMB decoding portion (although I havnt checked the checksums in the IP
>and TCP headers as yet - thats the next job).
>
>The commands used to do this decoding are below and the files generated
>from them are attached, in case it helps anyone more savvy with SMB packet
>formats than I to spot whats up.
>
>windump -e -x -r tcap3.292 | perl tcpformat.pl > tcap3.292.tcpformat.txt
>windump -e -x -r tcap3.13097 | perl tcpformat.pl >
>tcap3.13097.tcpformat.txt
>
>
>
>
>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 [at] excalibureng
>
>Postal Address : PO Box 1088 Newcastle NSW 2300, Australia
>Street Address : 80 Chin Chen Street, Islington,
> Newcastle, 2296, Australia
>------------------------------------------------------------------------
>----------
>
>
>On Friday, December 15, 2000 11:55 PM, Gilbert Ramirez
>[SMTP:gram [at] xiexie] wrote:
>> On Fri, 15 Dec 2000 15:44:16 +1000
>> Michael Hennessy <hennessy [at] excalibureng> wrote:
>>
>> > The packet in question is available for testing if someone wants to
>have a
>> > go at it - its only 153 bytes long.
>> >
>>
>> That's what we need. Either send the packet trace to ethereal-dev,
>> if it can be made public, or send it to me or another Ethereal
>> developer with instructions not to make it public.
>>
>> --gilbert
>Attachment Converted: "c:\eudora\attach\tcap3.292"
>
>Attachment Converted: "c:\eudora\attach\tcap3.13097"
>16:56:55.005498 0:d0:b7:88:43:f7 0:0:e8:cf:31:1c ip 113: 192.168.0.1.139 >
192.168.0.15.1025: P 15849027:15849086(59) ack 2777904 win 7302 (DF)
>Version: 4 Header Length: 5 Differentiated Services Field: 0x00
>Total Length: 99 Identification: 0x 69c
>Flags: 0x04
>Fragment Offset: 0 Time to Live: 128 Protocol: 6
>Header Checksum: 0x7298
>Options: 0 Padding: 1
>Source Address: 192.168.0.1 Destination Address: 192.168.0.15
> Source Port: 139
> Destination Port: 1025
> Sequence Number: 15849027
> Acknowledgement Number: 2777904
> Header Length: 5
> Code Bits: 24 ACK PSH
> Window Size: 7302
> Checksum: 0xb0af
> Urgent Pointer: 0
> Options: 00000037
> Data: (length of 59 bytes)
> 00 00 00 37 ff 53 4d 42 08 00 00 00 00 80 00 80
...7.SMB........
> 00 00 00 00 00 00 00 00 00 00 00 00 04 08 8d 11
................
> 00 08 83 c3 0a 20 00 00 9e 36 0e d7 00 00 00 00 .....
...6......
> 00 00 00 00 00 00 00 00 00 00 00 ...........
>-----------------------------------------
>16:59:35.477974 0:d0:b7:88:43:f7 0:0:e8:cf:35:18 ip 113: 192.168.0.1.139 >
192.168.0.14.1025: P 16779010:16779069(59) ack 2354633 win 7420 (DF)
>Version: 4 Header Length: 5 Differentiated Services Field: 0x00
>Total Length: 99 Identification: 0xe7cd
>Flags: 0x04
>Fragment Offset: 0 Time to Live: 128 Protocol: 6
>Header Checksum: 0x9167
>Options: 0 Padding: 1
>Source Address: 192.168.0.1 Destination Address: 192.168.0.14
> Source Port: 139
> Destination Port: 1025
> Sequence Number: 16779010
> Acknowledgement Number: 2354633
> Header Length: 5
> Code Bits: 24 ACK PSH
> Window Size: 7420
> Checksum: 0x12ab
> Urgent Pointer: 0
> Options: 00000037
> Data: (length of 59 bytes)
> 00 00 00 37 ff 53 4d 42 08 00 00 00 00 80 00 80
...7.SMB........
> 00 00 00 00 00 00 00 00 00 00 00 00 04 08 f5 29
...............)
> 00 08 01 5c 0a 20 00 00 21 7c 86 10 02 00 00 00 ...\.
..!|......
> 00 00 00 00 00 00 00 00 00 00 00 ...........
>-----------------------------------------
>

Regards
-------
Richard Sharpe, sharpe [at] ns
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

gharris at flashcom

Dec 16, 2000, 1:17 PM

Post #3 of 15 (374 views)
Permalink

Re: RE: [Ethereal-users] ethereal v0.8.14.1 and 0.8.14 on NT4SP5 grabs a packet it GPF's when decoding [In reply to]

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.

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.

gharris at flashcom

Dec 16, 2000, 1:30 PM

Post #4 of 15 (375 views)
Permalink

Re: RE: [Ethereal-users] ethereal v0.8.14.1 and 0.8.14 on NT4SP5 grabs a packet it GPF's when decoding [In reply to]

On Sat, Dec 16, 2000 at 12:17:19PM -0800, Guy Harris wrote:
> I shall compare its dissection with what Microsoft's Network Monitor
> claims to be the date and time.

Well, Network Monitor seems to think not that it was done around the
turn of the century, but that it was done by Men From The Future - it
gives the file a modification date/time of Jul 1, 2041 8:57:36.0.

It is not inconceivable that the author of the SMB dissector in Network
Monitor was confused as well; Microsoft have used several different
date/time formats in SMB (changing, I suspect, as their choice of SMB
server OS changed from whatever to Xenix to OS/2 to NT...), and if
you're not one of the folks in the SMB group there, you may well not
know what the Secret Code is for which requests use which formats.

sharpe at ns

Dec 16, 2000, 3:40 PM

Post #5 of 15 (373 views)
Permalink

Re: RE: [Ethereal-users] ethereal v0.8.14.1 and 0.8.14 on NT4SP5 grabs a packet it GPF's when decoding [In reply to]

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 [at] ns
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

hennessy at excalibureng

Dec 16, 2000, 5:27 PM

Post #6 of 15 (377 views)
Permalink

RE: RE: [Ethereal-users] ethereal v0.8.14.1 and 0.8.14 on NT4SP5 grabs a packet it GPF's when decoding [In reply to]

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 [at] excalibureng

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 [at] ns] 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 [at] ns
> 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
>

sharpe at ns

Dec 16, 2000, 6:26 PM

Post #7 of 15 (372 views)
Permalink

RE: RE: [Ethereal-users] ethereal v0.8.14.1 and 0.8.14 on NT4SP5 grabs a packet it GPF's when decoding [In reply to]

At 10:27 AM 12/17/00 +1000, Michael Hennessy wrote:
>
>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.....)

OK, it seems to me that NT uses a different date/time format, which is
neither the UTIME format or DOS_DATE and DOS_TIME format, as I have
modified Ethereal to dissect the date/time in both formats for an NT
capture, and both are incorrect, it seems ...

However, what bothers me is what exactly is the format of time_t.

>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 [at] excalibureng
>
>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 [at] ns] 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 [at] ns
>> 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
>>
>

Regards
-------
Richard Sharpe, sharpe [at] ns
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

guy at netapp

Dec 16, 2000, 7:14 PM

Post #8 of 15 (374 views)
Permalink

Re: RE: [Ethereal-users] ethereal v0.8.14.1 and 0.8.14 on NT4SP5 grabs a packet it GPF's when decoding [In reply to]

> OK, it seems to me that NT uses a different date/time format,

To quote one of the CIFS drafts:

3.5 Time And Date Encoding

When SMB requests or responses encode time values, the following
describes the various encodings used.

struct {
USHORT Day : 5;
USHORT Month : 4;
USHORT Year : 7;
} SMB_DATE;

The Year field has a range of 0-119, which represents years 1980
- 2099. The Month is encoded as 1-12, and the day ranges from
1-31

struct {
USHORT TwoSeconds : 5;
USHORT Minutes : 6;
USHORT Hours : 5;
} SMB_TIME;

Hours ranges from 0-23, Minutes range from 0-59, and TwoSeconds
ranges from 0-29 representing two second increments within the
minute.

typedef struct {
ULONG LowTime;
LONG HighTime;
} TIME;

TIME indicates a signed 64-bit integer representing either an
absolute time or a time interval. Times are specified in units
of 100ns. A positive value expresses an absolute time, where
the base time (the 64- bit integer with value 0) is the
beginning of the year 1601 AD in the Gregorian calendar. A
negative value expresses a time interval relative to some base
time, usually the current time.

typedef unsigned long UTIME;

UTIME is the number of seconds since Jan 1, 1970, 00:00:00.0.

SMB_DATE and SMB_TIME are DOS-style dates and times; UTIME is a
UNIX-style time (although I think it's seconds since Jan 1, 1970,
00:00:00.0 *local* time, not Jan 1, 1970, 00:00:00.0 GMT), and TIME is
what, in Win32, is called a "FILETIME".

It's UNIX-like, in that it's time ticks since a fixed epoch, but the
epoch is different, and, instead of being seconds, or seconds plus a
microsecond offset as two numbers, or seconds plus a nanosecond offset
as two numbers, it's tenths of microseconds as one number.

(UTIME is what appears in the document "Microsoft Networks/OpenNET FILE
SHARING PROTOCOL, INTEL Part Number 138446, Document Version 2.0", from
November 7, 1988.

SMB_DATE and SMB_TIME appear in "Microsoft Networks SMB FILE SHARING
PROTOCOL EXTENSIONS, SMB File Sharing Protocol Extensions Version 2.0,
Document Version 3.3", also from November 7, 1988, which says it's for
"Operating Systems richer in function than MS-DOS 3.x", and cites OS/2.

I wonder whether UTIME was used when they thought Xenix was the server
OS of choice, and SMB_DATE/SMB_TIME was used when they thought OS/2 was
the server OS of choice, and, now that NT, even if NT 5.0 has been
renamed "Windows 2000", is the server OS of choice, they use TIME.)

It appears that NetApp's servers return UTIME in response to the core
"get attributes" request, which agrees with the "Microsoft
Networks/OpenNET FILE SHARING PROTOCOL" document, so I don't know what
the deal is with that packet.

guy at netapp

Dec 16, 2000, 7:21 PM

Post #9 of 15 (374 views)
Permalink

Re: RE: [Ethereal-users] ethereal v0.8.14.1 and 0.8.14 on NT4SP5 grabs a packet it GPF's when decoding [In reply to]

> At 10:27 AM 12/17/00 +1000, Michael Hennessy wrote:
> OK, it seems to me that NT uses a different date/time format, which is
> neither the UTIME format or DOS_DATE and DOS_TIME format, as I have
> modified Ethereal to dissect the date/time in both formats for an NT
> capture, and both are incorrect, it seems ...

Network Monitor thinks the time field in the "get attributes" reply is 4
bytes long; unless the four bytes after the 0x00 0x21 0x7c 0x86 are part
of an 8-byte value of type TIME (for which read FILETIME), it's not in
the NT format I mentioned (10ths of microseconds since an epochal date
back in 1601).

It's probably treating the time as an *unsigned* number of seconds since
January 1, 1970, 00:00:00.0, hence it's past 2038 (2041) rather than
before 1970 (1905).

guy at netapp

Dec 16, 2000, 7:23 PM

Post #10 of 15 (374 views)
Permalink

Re: RE: [Ethereal-users] ethereal v0.8.14.1 and 0.8.14 on NT4SP5 grabs a packet it GPF's when decoding [In reply to]

> Where did you get that info about number of 10ths of a second?

Tenths of microseconds, not tenths of seconds:

TIME indicates a signed 64-bit integer representing either an
absolute time or a time interval. Times are specified in units
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
of 100ns. ...
^^^^^^^^

sharpe at ns

Dec 16, 2000, 7:24 PM

Post #11 of 15 (374 views)
Permalink

RE: RE: [Ethereal-users] ethereal v0.8.14.1 and 0.8.14 on NT4SP5 grabs a packet it GPF's when decoding [In reply to]

Hi,

It is clear that there is a problem here ...

For now, to prevent problems with Windows, I propose adding a check to
dissect_smbu_time and _date to check if _gmtime is null, and if so, return
"Bad date format" etc.

Regards
-------
Richard Sharpe, sharpe [at] ns
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

sharpe at ns

Dec 16, 2000, 7:56 PM

Post #12 of 15 (373 views)
Permalink

Re: RE: [Ethereal-users] ethereal v0.8.14.1 and 0.8.14 on NT4SP5 grabs a packet it GPF's when decoding [In reply to]

At 06:14 PM 12/16/00 -0800, Guy Harris wrote:
>> OK, it seems to me that NT uses a different date/time format,
>
>To quote one of the CIFS drafts:
>
> 3.5 Time And Date Encoding
>
> When SMB requests or responses encode time values, the following
> describes the various encodings used.
>
> struct {
> USHORT Day : 5;
> USHORT Month : 4;
> USHORT Year : 7;
> } SMB_DATE;
>
> The Year field has a range of 0-119, which represents years 1980
> - 2099. The Month is encoded as 1-12, and the day ranges from
> 1-31
>
> struct {
> USHORT TwoSeconds : 5;
> USHORT Minutes : 6;
> USHORT Hours : 5;
> } SMB_TIME;
>
> Hours ranges from 0-23, Minutes range from 0-59, and TwoSeconds
> ranges from 0-29 representing two second increments within the
> minute.
>
> typedef struct {
> ULONG LowTime;
> LONG HighTime;
> } TIME;
>
> TIME indicates a signed 64-bit integer representing either an
> absolute time or a time interval. Times are specified in units
> of 100ns. A positive value expresses an absolute time, where
> the base time (the 64- bit integer with value 0) is the
> beginning of the year 1601 AD in the Gregorian calendar. A
> negative value expresses a time interval relative to some base
> time, usually the current time.
>
> typedef unsigned long UTIME;
>
> UTIME is the number of seconds since Jan 1, 1970, 00:00:00.0.
>
>SMB_DATE and SMB_TIME are DOS-style dates and times; UTIME is a
>UNIX-style time (although I think it's seconds since Jan 1, 1970,
>00:00:00.0 *local* time, not Jan 1, 1970, 00:00:00.0 GMT), and TIME is
>what, in Win32, is called a "FILETIME".
>
>It's UNIX-like, in that it's time ticks since a fixed epoch, but the
>epoch is different, and, instead of being seconds, or seconds plus a
>microsecond offset as two numbers, or seconds plus a nanosecond offset
>as two numbers, it's tenths of microseconds as one number.

OK, I have seen that stuff as well. What I cannot understand yet is that
Windows 95 understands both the UTIME format returned by Samba, which is
definitely seconds since 1970 (in localtime), as well as what NT is returning.

So, there is some state info it is getting hold of.

Where did you get that info about number of 10ths of a second?

>(UTIME is what appears in the document "Microsoft Networks/OpenNET FILE
>SHARING PROTOCOL, INTEL Part Number 138446, Document Version 2.0", from
>November 7, 1988.

Hmmm, I seem to have misplaced my copies of this document :-(

>SMB_DATE and SMB_TIME appear in "Microsoft Networks SMB FILE SHARING
>PROTOCOL EXTENSIONS, SMB File Sharing Protocol Extensions Version 2.0,
>Document Version 3.3", also from November 7, 1988, which says it's for
>"Operating Systems richer in function than MS-DOS 3.x", and cites OS/2.
>
>I wonder whether UTIME was used when they thought Xenix was the server
>OS of choice, and SMB_DATE/SMB_TIME was used when they thought OS/2 was
>the server OS of choice, and, now that NT, even if NT 5.0 has been
>renamed "Windows 2000", is the server OS of choice, they use TIME.)
>
>It appears that NetApp's servers return UTIME in response to the core
>"get attributes" request, which agrees with the "Microsoft
>Networks/OpenNET FILE SHARING PROTOCOL" document, so I don't know what
>the deal is with that packet.
>

Regards
-------
Richard Sharpe, sharpe [at] ns
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

sharpe at ns

Dec 16, 2000, 8:01 PM

Post #13 of 15 (375 views)
Permalink

Re: RE: [Ethereal-users] ethereal v0.8.14.1 and 0.8.14 on NT4SP5 grabs a packet it GPF's when decoding [In reply to]

At 06:21 PM 12/16/00 -0800, Guy Harris wrote:
>> At 10:27 AM 12/17/00 +1000, Michael Hennessy wrote:
>> OK, it seems to me that NT uses a different date/time format, which is
>> neither the UTIME format or DOS_DATE and DOS_TIME format, as I have
>> modified Ethereal to dissect the date/time in both formats for an NT
>> capture, and both are incorrect, it seems ...
>
>Network Monitor thinks the time field in the "get attributes" reply is 4
>bytes long; unless the four bytes after the 0x00 0x21 0x7c 0x86 are part
>of an 8-byte value of type TIME (for which read FILETIME), it's not in
>the NT format I mentioned (10ths of microseconds since an epochal date
>back in 1601).
>
>It's probably treating the time as an *unsigned* number of seconds since
>January 1, 1970, 00:00:00.0, hence it's past 2038 (2041) rather than
>before 1970 (1905).

Yes, I agree that it is a 4-byte quantity, because in some other captures I
have from NT, the length field, which is right after the last write time,
is correct, and has the correct value in it.

So, what is that damn format. Just checking to see if it is 10ths of
seconds, in an unsigned format ...

Regards
-------
Richard Sharpe, sharpe [at] ns
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

sharpe at ns

Dec 16, 2000, 8:27 PM

Post #14 of 15 (374 views)
Permalink

Re: RE: [Ethereal-users] ethereal v0.8.14.1 and 0.8.14 on NT4SP5 grabs a packet it GPF's when decoding [In reply to]

At 06:23 PM 12/16/00 -0800, you wrote:
>> Where did you get that info about number of 10ths of a second?
>
>Tenths of microseconds, not tenths of seconds:
>
> TIME indicates a signed 64-bit integer representing either an
> absolute time or a time interval. Times are specified in units
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> of 100ns. ...
> ^^^^^^^^

OK, my mistake ...

I have an example of a date in 28-Nov-2000 here and I cannot see anyway
that what NT has returned can be interpreted as the words swapped, or
10-ths of a second, or anything like that.

I have asked on the SNIA mailing list to see if they know anything about this.

Regards
-------
Richard Sharpe, sharpe [at] ns
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

sharpe at ns

Dec 16, 2000, 9:06 PM

Post #15 of 15 (374 views)
Permalink

Re: RE: [Ethereal-users] ethereal v0.8.14.1 and 0.8.14 on NT4SP5 grabs a packet it GPF's when decoding [In reply to]

At 06:23 PM 12/16/00 -0800, you wrote:
>> Where did you get that info about number of 10ths of a second?
>
>Tenths of microseconds, not tenths of seconds:
>
> TIME indicates a signed 64-bit integer representing either an
> absolute time or a time interval. Times are specified in units
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> of 100ns. ...
> ^^^^^^^^

OK,

after further checking, I think that NT might simply be returning crap in
the SMBgetatr response.

I have a trace of doing a Properties info for a file, and I notice that the
client (Win 95) does a SMBgetatr and then an SMBopenX. The response to the
SMBopenX contains the correct last write date, so clearly NT can get it
right in some cases, but looks like it gets it wrong in some cases as well.

It looks like the client works around the problems in NT.

Regards
-------
Richard Sharpe, sharpe [at] ns
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

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads