From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 Date: Fri, 30 Jul 2010 10:19:26 -0700 Message-ID: From: Akshat Kumar To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Subject: [9fans] aquarela less woeful Topicbox-Message-UUID: 44e7c372-ead6-11e9-9d60-3106f5b1d025 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