Description of problem: Printing to an smb share on a win9x machine hangs, lpq says active, ps aux shows lotts of processes related to printing but nothing happens, and this continues for atleast 5 minutes. This is with a clean phoebe install (thus using cups)
_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