|Summary:||Printing to smb share hangs|
|Product:||[Retired] Red Hat Linux||Reporter:||Hans de Goede <hdegoede>|
|Component:||redhat-config-printer||Assignee:||Jay Fenlason <fenlason>|
|Status:||CLOSED ERRATA||QA Contact:||David Lawrence <dkl>|
|Version:||9||CC:||fenlason, jfeeney, twaugh|
|Fixed In Version:||0.6.73-1||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2003-09-09 08:03:41 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
|Bug Blocks:||79579, 100644|
Description Hans de Goede 2002-12-30 13:09:15 UTC
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)
Comment 1 Tim Waugh 2003-01-01 12:35:48 UTC
_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..).
Comment 2 Hans de Goede 2003-01-02 12:48:38 UTC
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.
Comment 3 Hans de Goede 2003-01-02 12:50:01 UTC
Created attachment 89051 [details] output of printconf-tui --Xexport
Comment 4 Tim Waugh 2003-01-03 12:25:23 UTC
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.
Comment 5 giulioo 2003-01-06 20:05:58 UTC
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.
Comment 6 Tim Waugh 2003-01-06 20:58:13 UTC
What does this say?: smbclient //neelje/apollo password -N -P -c quit
Comment 7 Hans de Goede 2003-01-08 11:58:51 UTC
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 188.8.131.52:139 (Connection refused) Error connecting to 184.108.40.206 (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: 220.127.116.11 Address: 18.104.22.168#53 Name: neeltje.highrise.nl Address: 22.214.171.124 [hans@shalem hans]$ cat /etc/resolv.conf search highrise.nl nameserver 126.96.36.199 nameserver 188.8.131.52 ---- 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.
Comment 8 Hans de Goede 2003-01-08 11:59:58 UTC
One additonal remark, still this shouldn't cause the printjob to hang, but should just fail.
Comment 9 Tim Waugh 2003-01-08 12:49:54 UTC
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.
Comment 10 Hans de Goede 2003-01-08 15:59:00 UTC
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).
Comment 11 Tim Waugh 2003-01-08 16:13:55 UTC
[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?
Comment 12 Hans de Goede 2003-01-08 17:00:10 UTC
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.
Comment 13 Tim Waugh 2003-01-08 17:07:35 UTC
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?
Comment 14 Hans de Goede 2003-01-08 20:29:37 UTC
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.
Comment 15 Tim Waugh 2003-01-08 20:41:07 UTC
Please add '-s 100' to the strace command line so that we can see what the error says. Thanks.
Comment 16 Hans de Goede 2003-01-11 16:39:13 UTC
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.
Comment 17 Hans de Goede 2003-01-11 16:47:58 UTC
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.
Comment 18 Tim Waugh 2003-01-11 17:43:40 UTC
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.
Comment 19 Jay Fenlason 2003-03-06 20:15:32 UTC
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.)
Comment 20 Tim Waugh 2003-03-06 21:34:02 UTC
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?
Comment 21 Tim Waugh 2003-07-31 08:43:00 UTC
Comment 22 Hans de Goede 2003-08-03 14:46:42 UTC
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.
Comment 23 Hans de Goede 2003-08-04 15:35:26 UTC
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.
Comment 24 Tim Waugh 2003-08-14 09:55:16 UTC
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.
Comment 25 Hans de Goede 2003-08-14 10:36:36 UTC
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 :)
Comment 26 Tim Waugh 2003-08-29 12:47:48 UTC
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?
Comment 27 Hans de Goede 2003-08-29 17:16:28 UTC
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
Comment 28 Tim Waugh 2003-08-29 17:41:24 UTC
Aha. Hopefully 0.6.73-1 contains the fix.
Comment 29 Tim Waugh 2003-09-08 09:06:18 UTC
Please let me know if it works for you. Thanks.
Comment 30 Hans de Goede 2003-09-09 08:03:41 UTC
Works like a charm!
Comment 31 Tim Waugh 2003-09-17 08:56:08 UTC
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