[prev in list] [next in list] [prev in thread] [next in thread] 

List:       9fans
Subject:    [9fans] aquarela less woeful
From:       Akshat Kumar <akumar () mail ! nanosouffle ! net>
Date:       2010-07-30 17:19:26
Message-ID: AANLkTimiaENBtVXPj_T30sQBfNn0HU_wDCDaey7enYeP () mail ! gmail ! com
[Download RAW message or body]

For the less patient, I'll state the fix
before the spiel et explanation:

diff -n /n/sources/plan9/sys/src/cmd/aquarela/smbcomsessionsetupandx.c
aquarela/smbcomsessionsetupandx.c
/n/sources/plan9/sys/src/cmd/aquarela/smbcomsessionsetupandx.c:59 c
aquarela/smbcomsessionsetupandx.c:59
< 	s->peerinfo.maxlen = smbnhgets(pdata); pdata += 2;
---
> 	s->peerinfo.maxlen = 61440; pdata += 2;

The Explanation:

I had problems connecting from newer
Windows clients (Vista, 7, Server 2008,
etc.) to aquarela (XP, and everything
older works fine however). Even after
setting up to use the old authentication
methods (LM+NTLM), the connection
was not being established. The logs
look something like this:

cpu% aquarela -d allcmds -p
Aquarela 0.5 running
SMB_COM_NEGOTIATE request: tid 0xffff pid 0xfeff uid 0x0000 mid 0x0000
received:
0x0000   ff53 4d42 7200 0000 0018 53c8 0000 0000        .SMBr.....S.....
0x0010   0000 0000 0000 0000 ffff fffe 0000 0000        ................
0x0020   0062 0002 5043 204e 4554 574f 524b 2050        .b..PC NETWORK P
0x0030   524f 4752 414d 2031 2e30 0002 4c41 4e4d        ROGRAM 1.0..LANM
0x0040   414e 312e 3000 0257 696e 646f 7773 2066        AN1.0..Windows f
0x0050   6f72 2057 6f72 6b67 726f 7570 7320 332e        or Workgroups 3.
0x0060   3161 0002 4c4d 312e 3258 3030 3200 024c        1a..LM1.2X002..L
0x0070   414e 4d41 4e32 2e31 0002 4e54 204c 4d20        ANMAN2.1..NT LM
0x0080   302e 3132 00                                   0.12.
smbnegotiate: 'PC NETWORK PROGRAM 1.0'
smbnegotiate: 'LANMAN1.0'
smbnegotiate: 'Windows for Workgroups 3.1a'
smbnegotiate: 'LM1.2X002'
smbnegotiate: 'LANMAN2.1'
smbnegotiate: 'NT LM 0.12'
reply: ok
sending:
0x0000   ff53 4d42 7200 0000 0088 0080 0000 0000        .SMBr...........
0x0010   0000 0000 0000 0000 ffff fffe 0000 0000        ................
0x0020   1105 0003 0100 0100 ffff 0100 0000 0100        ................
0x0030   0300 0000 1400 0000 2b51 0b60 c82a cb01        ........+Q.`.*..
0x0040   a401 0815 0044 a423 ec94 f29b 5100 5000        .....D.#....Q.P.
0x0050   4c00 4100 4e00 3900 0000                       L.A.N.9...
SMB_COM_SESSION_SETUP_ANDX request: tid 0x0000 pid 0xfeff uid 0x0000 mid 0x0002
received:
0x0000   ff53 4d42 7300 0000 0018 0788 0000 0000        .SMBs...........
0x0010   0000 0000 0000 0000 0000 fffe 0000 0200        ................
0x0020   0d75 0082 0000 0001 0000 0003 0000 0018        .u..............
0x0030   0018 0000 0000 00d4 0000 0045 00e7 8aaa        ...........E....
0x0040   a0dd dee7 993e 8cf4 f121 5da2 77ed 85c5        .....>...!].w...
0x0050   0d91 cabd b3e7 8aaa a0dd dee7 993e 8cf4        .............>..
0x0060   f121 5da2 77ed 85c5 0d91 cabd b300 6100        .!].w.........a.
0x0070   6b00 7500 6d00 6100 7200 0000 0000 0000        k.u.m.a.r.......
0x0080   0000 04ff 00be 0008 0001 0031 0000 5c00        ...........1..\.
0x0090   5c00 3100 3900 3200 2e00 3100 3600 3800        \.1.9.2...1.6.8.
0x00a0   2e00 3200 2e00 3100 3400 3100 5c00 4900        ..2...1.4.1.\.I.
0x00b0   5000 4300 2400 0000 3f3f 3f3f 3f00             P.C.$...?????.
andxcommand: SMB_COM_TREE_CONNECT_ANDX offset 130
client.maxbuffersize: 0
client.maxmpxcount: 1
vcnumber: 0
sessionkey: 0x00000003
caseinsensitivepasswordlength: 24
casesensitivepasswordlength: 24
clientcapabilities: 0x000000d4
account: akumar
primarydomain:
nativeos:
nativelanman:
authentication succeeded
reply: error 2/1
SMB_COM_NEGOTIATE request: tid 0x0000 pid 0xfeff uid 0x0000 mid 0x0000

... and the client tries again.
Everything is OK here, except that client.maxbuffersize = 0;
in aquarela source, this relates back to s->peerinfo.maxlen=0
at smbcomtreeaconnectandx. Since this is a parameter to be
received from the client, and the packet format has not changed
at this level, between versions, I can only suspect that there
is a mistake in the new Samba code, where the MaxBufferSize
parameter is 0 (perhaps left nil or unset?). In any case, this
buffer size is simply a specification of the size of the reply
packet; by trial, I've seen that this doesn't change from 61440
on Windows XP clients, and 60 kB seems a reasonable size
(consider the data that's actually being sent immediately
afterwards). Thus, to avoid confusion, I don't see a problem in
simply specifying a static size for s->peerinfo.maxlen. It works
so far!

Any alternative solutions?


Best,
ak

[prev in list] [next in list] [prev in thread] [next in thread]