-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I have a problem accessing a CUPS/Samba shared printer on a Windows XP x64
Professional system (WinNT5.2 kernel). It seems from my searching that
this is a problem affecting only 64-bit Windows clients, but perhaps not
all 64-bit Windows clients.
See also:
https://bugs.launchpad.net/fedora/+bug/482836
http://ubuntuforums.org/showthread.php?p=8263192
I'm running Samba v3.4.5 on a 32-bit Slackware v13 virtual machine, Linux
kernel v2.6.29.6. CUPS is v1.3.11. I have produced a log level 5 output
showing two clients connecting to the Samba system and trying to view
properties on the printer. The 32-bit client "Manager2b" succeeds,
the
64-bit client "MasterIm64VM" does not. The logs (and config) are in
http://thor.chguernsey.com/temp/samba3.4.5logs-0.tgz
(116kb, MD5SUM 04672e49116c4596820812db5cb8cdfb).
Detailed steps:
Both clients can browse to \\PrintA\ and see the printer "LJ2200-A"
and
the "Printers and Faxes" icon. Double-clicking the "Printers and
Faxes"
icon works and shows the printer again (now with "Add Printer" above
it)
BUT the 64-bit system shows the printer name as a box now. Copying and
pasting that box gives the non-ASCII hex values "e3 a0 88".
Right-clicking the entry and selecting Properties gives a box with a red
X saying "Printer properties cannot be displayed. Either the printer
name was typed incorrectly, or the specified printer has lost its
connection to the server. For more information, click Help."
The first obvious issue I see in the log occurs at line 14,505 in
s.masterim64vm:
[2010/01/26 11:39:01, 4] rpc_server/srv_pipe.c:2297(api_rpcTNP)
api_rpcTNP: \spoolss op 0x45 - api_rpcTNP: rpc command:
SPOOLSS_OPENPRINTEREX
checking name: \\PrintA\? <88>
For what it's worth, another server running Samba v3.4.3 with CUPS v1.3.7
has no problems with 64-bit clients (so far). I have been unable install
Samba v3.4.3 on the first server...Neither 32-bit nor 64-bit systems are
able to connect at all with v3.4.3 running on the server.
Daniel Johnson
Progman2000 at usa.net / djohnson at progman.us
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFLXzdF6vGcUBY+ge8RAkc3AKCTOwImjekcpqaQTGgls5G+2dbFswCfRQlZ
TqPNESxDbqko2KvL8mi50k4=TUjQ
-----END PGP SIGNATURE-----
On Tue, Jan 26, 2010 at 12:44:22PM -0600, Daniel Johnson wrote:> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I have a problem accessing a CUPS/Samba shared printer on a Windows XP x64 > Professional system (WinNT5.2 kernel). It seems from my searching that > this is a problem affecting only 64-bit Windows clients, but perhaps not > all 64-bit Windows clients. > > See also: > https://bugs.launchpad.net/fedora/+bug/482836 > http://ubuntuforums.org/showthread.php?p=8263192 > > I'm running Samba v3.4.5 on a 32-bit Slackware v13 virtual machine, Linux > kernel v2.6.29.6. CUPS is v1.3.11. I have produced a log level 5 output > showing two clients connecting to the Samba system and trying to view > properties on the printer. The 32-bit client "Manager2b" succeeds, the > 64-bit client "MasterIm64VM" does not. The logs (and config) are in > http://thor.chguernsey.com/temp/samba3.4.5logs-0.tgz > (116kb, MD5SUM 04672e49116c4596820812db5cb8cdfb).Ok, here's the deal. If you have 64-bit Windows clients at the moment you need to be using 3.3.10, not anything later. If you're using 32-bit Windows clients, you can use 3.4.5 or later. The reason (and Guenther can correct me if I'm wrong), is that in 3.4.x we changed from the hand-marshalled SPOOLSS RPC we used in 3.3.x, which was mostly correct after being worked on for many years, to pidl-generated SPOOLSS RPC directly from the idl files. Now our idl files are correct, but it turns out that the Windows idl parser for SPOOLSS is itself custom, and won't accept the normally marshalled RPC packets that the pidl-generated code creates. Guenter and Metze have been doing a lot of work on fixing this, and this is why 32-bit Windows clients work in 3.4.5. However there are still some changes needed for 64-bit Windows clients, and this will probably make it into an early patch for 3.5.x (it won't make 3.5.0, as it's too late to test the changes needed before we ship next month). I'm going to write this up as a tech-note for the next 3.4.x release and for 3.5.0 and get it into the release notes. Hope this hasn't caused you too many problems. Jeremy.