Re: [Samba] Please help me decipher a two-packet NetBT conversation...

[Andrew Bartlett]

On Thu, 2005-01-20 at 10:33 -0600, David Black wrote:
> My clients are Windows XP SP1 and SP2, members of a Samba-PDC NT domain 
> (tested 3.0.7 and 3.0.10, same result).Attached is ethereal output 
> of a two packet client-server exchange that takes place when an offline 
> files sync is done.   SP1 quickly does this exchange twice - first 
> broadcast, then unicast (as attached) and goes on its way.  SP2 tries, 
> pauses many seconds, tries again, finally giving up and completing the sync.
> 
> Basically the client is attempting a SAM logon request with an empty 
> user name.  Samba responds with user unknown.   

Before you spend too much time barking up the wrong tree, my
understating is that the username in this UDP SamLogon request is not
honoured by any modern operating system, and user-unknown is the correct
reply.  Giving out this information would confirm/deny a given username
without authentication, which is considered a bad thing.  Samba has
always left it up to the logon process to actually decide this.

Andrew Bartlett

-- 
Andrew Bartletthttp://samba.org/~abartlet/
Authentication Developer, Samba Team   http://samba.org
Student Network Administrator, Hawker College  http://hawkerc.net


signature.asc
Description: This is a digitally signed message part
-- 
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/listinfo/samba

Re: [Samba] Please help me decipher a two-packet NetBT conversation...

[David Black]

Thanks for your response, Jerry.
I too would expect that response from Samba, given the seemingly odd 
request.  What I'm up against is the client - especially XP SP2, doesn't 
seem to "like" that response, retrying after a considerable pause.  

Absent any other trails to follow, I'd like to try making Samba give 
some other responses and see how the client responds.

Dave
Gerald (Jerry) Carter wrote:
This is the correct response based on my memory of the
network traffic.  You could be running down the wrong trail
here.  I haven't dug in to the offline caching support
so I can't comment on that too much.  But the response code
in your trace was right as far as I know.
--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/listinfo/samba

Re: [Samba] Please help me decipher a two-packet NetBT conversation...

[Gerald (Jerry) Carter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Black wrote:
| My clients are Windows XP SP1 and SP2, members of a Samba-PDC NT domain
| (tested 3.0.7 and 3.0.10, same result).Attached is ethereal output
| of a two packet client-server exchange that takes place when an offline
| files sync is done.   SP1 quickly does this exchange twice - first
| broadcast, then unicast (as attached) and goes on its way.  SP2 tries,
| pauses many seconds, tries again, finally giving up and completing the
| sync.
|
| Basically the client is attempting a SAM logon request with an empty
| user name.  Samba responds with user unknown.   Even at high log levels,
| I get nothing in the Samba logs.   I found one other reference to this
| sort of issue, on an earlier Samba list post in 2002, then a follow-up
| in 8/04, both unanswered.
|
This is the correct response based on my memory of the
network traffic.  You could be running down the wrong trail
here.  I haven't dug in to the offline caching support
so I can't comment on that too much.  But the response code
in your trace was right as far as I know.

cheers, jerry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFB7/HEIR7qMdg1EfYRAlB2AKDkkQ1mfVXEbXwhk4JPrCfwi6qKpgCeILdr
kKnH2vT7i3VNhrJwQ5s9tZc=
=Jz3Z
-END PGP SIGNATURE-
--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/listinfo/samba

[Samba] Please help me decipher a two-packet NetBT conversation...

[David Black]

My clients are Windows XP SP1 and SP2, members of a Samba-PDC NT domain 
(tested 3.0.7 and 3.0.10, same result).Attached is ethereal output 
of a two packet client-server exchange that takes place when an offline 
files sync is done.   SP1 quickly does this exchange twice - first 
broadcast, then unicast (as attached) and goes on its way.  SP2 tries, 
pauses many seconds, tries again, finally giving up and completing the sync.

Basically the client is attempting a SAM logon request with an empty 
user name.  Samba responds with user unknown.   Even at high log levels, 
I get nothing in the Samba logs.   I found one other reference to this 
sort of issue, on an earlier Samba list post in 2002, then a follow-up 
in 8/04, both unanswered.

I'd be happy to look at the Samba code to better understand how/why this 
is happening, but don't know where to start.  Advice is much appreciated.

Regards,
David Black
No. TimeSourceDestination   Protocol 
Info
   4191 14:45:44.739000 dblack-pc.magnalynx.com ha1.magnalynx.com NETLOGON 
SAM LOGON request from client

Frame 4191 (281 bytes on wire, 281 bytes captured)
Arrival Time: Jan 19, 2005 14:45:44.73900
Time delta from previous packet: 0.03000 seconds
Time since reference or first frame: 1238.005492000 seconds
Frame Number: 4191
Packet Length: 281 bytes
Capture Length: 281 bytes
Ethernet II, Src: 00:0d:60:af:59:fc, Dst: 00:0d:60:0f:01:d6
Destination: 00:0d:60:0f:01:d6 (ha1.magnalynx.com)
Source: 00:0d:60:af:59:fc (dblack-pc.magnalynx.com)
Type: IP (0x0800)
Internet Protocol, Src Addr: dblack-pc.magnalynx.com (192.168.10.151), Dst 
Addr: ha1.magnalynx.com (192.168.10.230)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
 00.. = Differentiated Services Codepoint: Default (0x00)
 ..0. = ECN-Capable Transport (ECT): 0
 ...0 = ECN-CE: 0
Total Length: 267
Identification: 0x31b6 (12726)
Flags: 0x00
0... = Reserved bit: Not set
.0.. = Don't fragment: Not set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 128
Protocol: UDP (0x11)
Header checksum: 0x715e (correct)
Source: dblack-pc.magnalynx.com (192.168.10.151)
Destination: ha1.magnalynx.com (192.168.10.230)
User Datagram Protocol, Src Port: netbios-dgm (138), Dst Port: netbios-dgm (138)
Source port: netbios-dgm (138)
Destination port: netbios-dgm (138)
Length: 247
Checksum: 0x7e57 (correct)
NetBIOS Datagram Service
Message Type: Direct_group datagram (17)
More fragments follow: No
This is first fragment: Yes
Node Type: P node (1)
Datagram ID: 0x8022
Source IP: dblack-pc.magnalynx.com (192.168.10.151)
Source Port: 138
Datagram length: 225 bytes
Packet offset: 0 bytes
Source name: DBLACK-PC<00> (Workstation/Redirector)
Destination name: MAGNALYNX<1c> (Domain Controllers)
SMB (Server Message Block Protocol)
SMB Header
Server Component: SMB
SMB Command: Trans (0x25)
Error Class: Success (0x00)
Reserved: 00
Error Code: No Error
Flags: 0x00
0...  = Request/Response: Message is a request to the server
.0..  = Notify: Notify client only on open
..0.  = Oplocks: OpLock not requested/granted
...0  = Canonicalized Pathnames: Pathnames are not canonicalized
 0... = Case Sensitivity: Path names are case sensitive
 ..0. = Receive Buffer Posted: Receive buffer has not been 
posted
 ...0 = Lock and Read: Lock&Read, Write&Unlock are not supported
Flags2: 0x
0...    = Unicode Strings: Strings are ASCII
.0..    = Error Code Type: Error codes are DOS error 
codes
..0.    = Execute-only Reads: Don't permit reads if 
execute-only
...0    = Dfs: Don't resolve pathnames with Dfs
 0...   = Extended Security Negotiation: Extended 
security negotiation is not supported
  .0..  = Long Names Used: Path names in request are 
not long file names
   .0.. = Security Signatures: Security signatures are 
not supported
   ..0. = Extended Attributes: Extended attributes are 
not supported
   ...0 = Long Names Allowed: Long file names are not 
allowed in the response
Process ID High: 0
Signature: 
Reserved: 
Tree ID: 0
Process ID: 0
User ID: 0
Multiplex ID: 0
Trans Request (0x25)
Word Count (WCT): 17
Total Parameter Count: 0
Total Data Count: 65
Max Parameter Count: 0
Max Data Count: 0
Max Setup Count: 0
Reserved: 00