_Any_ SMB share printing hangs to this machine, or is there some particular
set-up that makes this hang?  For example, what kind of security is there on the
share, and what workgroup etc settings are there?

What would be really great is the output of printconf-tui --Xexport (don't
forget to * out any passwords in it before attaching..).

I've tried printing to the said win9x machine with the printer configured with
either the cdj550 or the hpijs driver. No difference.

Printing text or postscript makes no difference, exept that with postscript in
the ps aux output ghostscript is there and with txt not.

Printing a txt file with smbclient from the commandline works.
Please note that the username aap in the configfile is bogus, this is with share
level access control but printconf-gui didn't lett me add a share without an
username.

I have the feeling the :"smb://aap:neeltje/neeltje/apollo 7 hans aap 1 cpi=12
lpi=7 page-bottom=36 page-left=36 page-right=36 page"

process in a ps auxw output is hanging.

Created attachment 89051 [details]
output of printconf-tui --Xexport

I expect it's because of the bogus user name.  redhat-config-printer-0.6.27-1
fixes the bug that prevented you from entering no user name.  Please try that
(and of course take the user name out).  Thanks.

FYI, if a share is password protected, win9x completely ignores any username you
use in
smbclient .. -U<dummy_username>%<real_pass>
and let you in as long as real_pass is ok.

What does this say?:

smbclient //neelje/apollo password -N -P -c quit

Ah that one does the trick (shows us (me?) howto solve the problem) :

[hans@shalem hans]$ smbclient //neelje/apollo neeltje -N -P -c quit
added interface ip=192.168.1.3 bcast=192.168.1.255 nmask=255.255.255.0
error connecting to 212.204.192.3:139 (Connection refused)
Error connecting to 212.204.192.3 (Connection refused)
Connection to neelje failed
[hans@shalem hans]$ cat /etc/hosts
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1               localhost.localdomain localhost
192.168.1.1             gw.highrise.nl gw
192.168.1.2             neeltje.highrise.nl neeltje
192.168.1.3             shalem.highrise.nl shalem
192.168.1.254           gollum.highrise.nl gollum
[hans@shalem hans]$ nslookup neeltje
Note:  nslookup is deprecated and may be removed from future releases.
Consider using the `dig' or `host' programs instead.  Run nslookup with
the `-sil[ent]' option to prevent this message from appearing.
Server:         194.109.6.66
Address:        194.109.6.66#53

Name:   neeltje.highrise.nl
Address: 212.204.192.3

[hans@shalem hans]$ cat /etc/resolv.conf
search highrise.nl
nameserver 194.109.6.66
nameserver 194.109.9.99


----

So what happens is that smbclient uses DNS to lookup neeltje and finds an old
dns entry (my lan used to have real ip's but has been renumbered to 192.168.1.x
since then, but the externally hosted dns was never updated to reflect this)

This used to work just fine since I always fixed this problem by adding my local
machines to /etc/hosts for some reason smbclient with the options you provided
bypasses /etc/hosts.

So there is the problem. I see 2 fixes:
1-you lett the smbprinting honor /etc/hosts
2-I cleanup my DNS so that it doesn't report invalid IP's

I think both should be applied, since other smb setups might depend on
/etc/hosts too.

One additonal remark, still this shouldn't cause the printjob to hang, but
should just fail.

The smb.conf name resolve order option should be used, or else your /etc/hosts
file should be fixed.

Also, a refused connection might be a transient error, so I think it is correct
to keep trying.  I imagine (but don't know for sure) that it will eventually
give up.

Oops,

I just found out that there's a typo in the smbclient cmdline you gave above and
I tried. Its trying todo stuff to neelje instead of neeltje note the missing t.
With the t in place "smbclient //neeltje/apollo password -N -P -c quit" says:

[hans@shalem hans]$ smbclient //neeltje/apollo neeltje -N -P -c quit
added interface ip=192.168.1.3 bcast=192.168.1.255 nmask=255.255.255.0

I thought maybe one of the additonal params you specified caused /etc/hosts to
be ignored, but that wasn't the problem. So we're back where we started,
printing hangs. This kinda figures since I've tried printing a txt file with
smbclient before and that worked (See above).

[hans@shalem hans]$ smbclient //neeltje/apollo neeltje -N -P -c quit
added interface ip=192.168.1.3 bcast=192.168.1.255 nmask=255.255.255.0

..and you got a prompt after that, right?  So it worked.

Have you tried a newer redhat-config-printer yet?

Just tried redhat-config-printer-0.6.29-1 removed the printer applied,
reinstalled it, printing still hangs

But I can confirm an empty username is ok now.

Okay, let's start prodding the backend process then.  Does 'strace -p ...' or
'gdb /usr/lib/cups/backend/smb ...' reveal anything interesting about what it's
up to?

Created attachment 89218 [details]
output of strace -p

Here's a log of strace -p, it seems to try to connect, get some strange error
and then wait 60 seconds. It does connect to the right IP, so the /etc/hosts
thingy most defenitly isn't the problem.

Looking more closely at the trace it seems the smb backend does something
different then smbclient does and that it is an smb protocol problem. easiest
fix is maybe to switch back to just calling smbclient from a wrapper script.

Otherwise it is probably best if you reproduce my situation here at home at RH.

Please add '-s 100' to the strace command line so that we can see what the error
says.  Thanks.

Created attachment 89304 [details]
output of strace -p -s 100

That -s 100 does the trick, it says the password is invalid, this isn't true,
but it does makes some sense. I've had a simular problem at work printing from
windows 2000 to an win98 machine, for some reason it only works when I set an
empty password, and this is m$ to m$, 98 running share level access. The
machine giving the problems here at home is a win95 (I think osr2).

My theory:
-the smb backend of cups tries to use an encrypted password and doesn't retry
with an unencrypted passwd, win95 still uses unencrypted passwords.

Note that this used to work just fine in 8.0 so people upgrading and switching
to cups will be unpleasently surprised.

Note: Smbclient appearently tries both encrypted and unencrypted password, or
somehow just knows which to use when.

Just tried setting the win95 share to an empty password, updated printconf
accordingly, and it works. So I really think its the password encryption thingy.

2 last remarks:
-still it shouldn't hang, a bad password is not something which will go away by 
 retrying.
-I can live with an empty password, but this is probably going to bite other
 people.

Well, /usr/lib/cups/backend/smb is just a symlink to /usr/bin/smbspool, which is
from samba-client.

So if it's an SMB backend problem (of not trying unencrypted passwords when it
should), it's in the samba package.

redhat-config-printer is setting an incorrect PrinterURI in
/etc/cups/printers.config
It should say
PrinterURI smb://username:password@workgroup/server/printer
Instead, the line reads
PrinterURI smb://username:password/server/printer
If I edit the file with either cupsconfig or by hand, printing works.

(Well, I also have to tell CUPS that it's a text-only printer that does not
understand postscript.  Despite enabling "text-only printer" in
redhat-config-printer, it insisted on sending postscript to it.)

The workgroup in this case is not known to redhat-config-printer (see the
'printconf-tui --Xexport' attachment).

Hans: if you fill in the 'workgroup' field in using the config tool, does that
fix the problem?

*ping*

Yeah I'm still here, I just had other priorities :) I'll try both scenarios
(with and without a workgroup se)t with severn this week.

As promised I've tried both scenarios:

With severn and without a workgroup the problem is still there.
With severn and with a workgroup everything works ok.

So yes the problem goes away once a workgroup is entered, but when you use
smb-tools from the cmdline you don't need to enter a workgroup and it _still_
works. Also under windows itself when you enter a share name you usually don't
include the workgroup, so I think it should work even without a workgroup, but
thats up to you.

Jay: Any idea why the smbclient command line can work even with the workgroup
omitted, but the smbspool command requires it?  This seems to be something that
smbclient can work out but smbspool can't.

I don't think smbspool needing a workgroup is the problem, as said above if I
also ommit the password (and tell the win95 machine there is no password)
everythi9ng works ok. The problem is that the URL with a password but without a
workgroup isn't recognised. This could mean 2 things:
1 it isn't possible te create a valid smbspool URL with a password and without a
workgroup
2 printconf doesn't know howot generate a correct URL with a password and
without a workgroup

My bet is on 2 :)

Well, the URI it is generating is this:

  smb://username:password/server/printer

If that's wrong, I need to know what the correct one is.  As Jay said above:

> redhat-config-printer is setting an incorrect PrinterURI in
> /etc/cups/printers.config
> It should say
> PrinterURI smb://username:password@workgroup/server/printer
> Instead, the line reads
> PrinterURI smb://username:password/server/printer

..but I don't *have* the workgroup unless the user tells me it.

Jay, do you have any insight to offer here?

From "man smbspool":

       · smb://server/printer

       · smb://workgroup/server/printer

       · smb://username:password@server/printer

       · smb://username:password@workgroup/server/printer

So the correct URI without a workgroup is:
smb://username:password@server/printer

Aha.  Hopefully 0.6.73-1 contains the fix.

Please let me know if it works for you.  Thanks.

Works like a charm!

An errata has been issued which should help the problem described in this bug report. 
This report is therefore being closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files, please follow the link below. You may reopen 
this bug report if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2003-276.html