From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040904 Firefox/0.9.3 Description of problem: New install of FC3T2. Setting up printer same way as it works in FC1, FC2, FC3T1. Networked printer attached to Netgear PS110 print server with IP=192.168.1.102. Ping to print server OK. Set up using Networked Unix (LPD). Server 192.168.1.102, Printer L1. Printer is HP Desk Jet 970C. (Same problem with a second printer, Samsung ML-1750.) If I try a test page during setup, all looks ok, but it is never produced. I also tried no test page then printing a file from Gedit. The printer shows up in the Gedit print dialog. When I open System Tools > Print Manager, it's dialog opens, showing an icon for the printer, but a dialog labeled Question also pops up with "No printers found, Run the Printer configuration tool?" If I click OK, the Printer Configuration box opens, and the Description field contains "Network host '192.168.1.102' is busy, down, or unreachable, will retry in 30 seconds ..." However, a ping works just fine. If I click on the printer icon in Print Manager, it shows the job in the queue as printing. I'm not sure whether this is cups, printman, selinux or some other component. I originally had selinux as defaulted at install, but then added selinux=0 to the kernel line in grub.conf. Same results both ways. I can reboot to one of the other partitions listed at the beginning of this report and printing works just fine with the exact same setup. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.Define printer 2.Use Printer 3. Actual Results: No printed output Expected Results: Printed output Additional info:
Looking at the localhost:631 interface, the Device URL is the same in FC3T2 as it is in a working FC3T1 system: Device URL: lpd://192.168.1.102:515/L1
Please edit /etc/cups/cupsd.conf (as root) and change the 'LogLevel' line to read: LogLevel debug2 Then do this: service cups stop (to stop it) > /var/log/cups/error_log (to truncate the error log file) service cups start (to start it with the new LogLevel setting) Then submit your job again and attach the resulting /var/log/cups/error_log file. Thanks.
Created attachment 104369 [details] File requested by Tim Waugh
I did the above. Print manager shows the job as: Unknown gerry 1 158k Mon ... Printing Properties in Printer configuration shows: Network host '192.168.1.102' is busy; will retry in 30 seconds... I stopped cups again to terminate the log file entries Will now try to attach the log file
This is the problem line: I [27/Sep/2004:08:14:09 -0500] [Job 3] Connecting to 192.168.1.102 on port 0... But it seems as though the remote host is an ipp://... URI, not an lpd://... URI as you said. Am I looking at the wrong queue? hpdj970c seems to have an incorrect URI: DEVICE_URI=ipp://192.168.1.102:L1/printers/queue1 The ':L1' part is meant to be a port number. Does it work to instead use this?: ipp://192.168.1.102/printers/L1
Sorry for that, Tim. In my frustration to get it working, I had redefined the printer as you show above and had forgotten about it. I now have two printers defined, one hplpd and one, hpipp. I have sent a job to each as the lines in error_log show below. D [27/Sep/2004:10:03:26 -0500] StartJob: envp[10]="DEVICE_URI=ipp://192.168.1.102/printers/L1" D [27/Sep/2004:10:05:49 -0500] StartJob: envp[10]="DEVICE_URI=lpd://192.168.1.102/L1" Neither job is printing. Print Manager says each is printing. Printer Configuration says for hpipp: Network host '192.168.1.102 is busy; will retry in 30 seconds. for hplpd: Unable to connect to printer; will retry in 30 seconds... Connection timed out. If I ping the server: [root@gstpc ~]# ping 192.168.1.102 PING 192.168.1.102 (192.168.1.102) 56(84) bytes of data. 64 bytes from 192.168.1.102: icmp_seq=0 ttl=30 time=3.12 ms 64 bytes from 192.168.1.102: icmp_seq=1 ttl=30 time=3.13 ms 64 bytes from 192.168.1.102: icmp_seq=2 ttl=30 time=3.10 ms 64 bytes from 192.168.1.102: icmp_seq=3 ttl=30 time=3.09 ms 64 bytes from 192.168.1.102: icmp_seq=4 ttl=30 time=3.14 ms --- 192.168.1.102 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4002ms rtt min/avg/max/mdev = 3.093/3.119/3.142/0.039 ms, pipe 2 By this time, I wonder if there is a set of packages I could remove and reinstall for a fresh start at troubleshooting. Are there any more tests I can do for you? Printing to the printer with an DEVICE_URI=lpd://192.168.1.102/L1 setup in FC2 works fine.
I need to see the entire error_log file for a job you submit. Please follow the instructions in comment #2 again, now that you have corrected the URI. Thanks.
Created attachment 104379 [details] File requested by Tim Waugh I sent one job to the hplpd queue and waited a few minutes, then stopped cups to allow attaching this file.
Does 'telnet 192.168.1.102 515' connect?
No, it does not in FC3T2, but does in FC2.
Some iptables rule preventing output SYNs or something? Anyway, not CUPS problem. What does 'tcpdump -n host 192.168.1.102' say while you are telnetting?
I have not made any changes to iptables rules since a fresh install of FC2T3. I've just kept it up2date. Here is the output before I killed it: [root@gstpc gerry]# /usr/sbin/tcpdump -n host 192.168.1.102 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 07:30:15.584183 IP 192.168.1.102.printer > 192.168.1.100.1023: SP 24842105:24842 105(0) ack 2503960261 win 1024 <mss 1024> 07:30:15.585361 IP 192.168.1.100 > 192.168.1.102: icmp 52: host 192.168.1.100 un reachable - admin prohibited 07:30:16.588761 IP 192.168.1.102.telnet > 192.168.1.100.32800: SP 24896426:24896 426(0) ack 2597373140 win 1024 <mss 1024> 07:30:16.588810 IP 192.168.1.100 > 192.168.1.102: icmp 52: host 192.168.1.100 un reachable - admin prohibited 07:30:19.726331 IP 192.168.1.100.32800 > 192.168.1.102.telnet: S 2597373139:2597 373139(0) win 5840 <mss 1460,sackOK,timestamp 4294876162 0,nop,wscale 2> 07:30:19.730620 IP 192.168.1.102.telnet > 192.168.1.100.32800: . ack 1 win 1024 07:30:19.730672 IP 192.168.1.100 > 192.168.1.102: icmp 48: host 192.168.1.100 un reachable - admin prohibited 07:30:20.582119 arp who-has 192.168.1.102 tell 192.168.1.100 07:30:20.583265 arp reply 192.168.1.102 is-at 00:c0:02:56:70:62 07:30:25.877679 IP 192.168.1.102.netbios-dgm > 192.168.1.255.netbios-dgm: NBT UD P PACKET(138) 07:30:36.687214 IP 192.168.1.102.printer > 192.168.1.100.1023: SP 24842105:24842 105(0) ack 2503960261 win 1024 <mss 1024> 07:30:36.687261 IP 192.168.1.100 > 192.168.1.102: icmp 52: host 192.168.1.100 un reachable - admin prohibited 07:30:37.691614 IP 192.168.1.102.telnet > 192.168.1.100.32800: SP 24896426:24896 426(0) ack 2597373140 win 1024 <mss 1024> 07:30:37.691661 IP 192.168.1.100 > 192.168.1.102: icmp 52: host 192.168.1.100 un reachable - admin prohibited 14 packets captured 14 packets received by filter 0 packets dropped by kernel [root@gstpc gerry]#
This is not a problem with 192.168.1.102. The prohibition originates from 192.168.1.100.
I see you have closed this as NOTABUG. Just to be sure I wasn't working with a borked system, I did a fresh FC3T2 Personal Desktop install, and updated to the latest cups, desktop-printing packages. I then tried to install a networked LPD printer as before. Same results as detailed in this bug report history. This may not be a cups bug, or even a printing system bug, but it is definitely a bug in some FC3T2 component that is stopping LPD print server network printing from working. If this persists, there is no way I can use FC3. I have been using this print setup through all the releases (including all beta and test releases) of RHL and FC from RHL7.3 through FC3T2. I currently have a multi-boot system with FC1, FC2, FC3T1 and FC3T2 on individual partitions. The setup is working on FC1 and FC2. Until the last set of rawhide updates around 9/20, the release date for FC3T2, it was also working on FC3T1. I updated that system just before installing FC3T2, and paid no attention to it again until I just now checked the printing. It does not work now, even though I was using it routinely before 9/20. Can you suggest any other component that could be blocking this from working that I can test in some way and report a bug against to get it working again? Thanks. Gerry Tool
Perhaps FC1 or FC2 fetch different IP addresses for that machine? It really looks to me like a network problem of some sort, *external* to that machine.
Reassigning to kernel, in case it's a network problem *internal* to that machine.
Additional info. Since I have multiple kernels installed in my FC3T1 partition, I tried each of them. Communication with the print server works fine up through kernel 2.6.8-1.526, and fails with kernel 2.6.8-1.532 and later. My FC2 partition which communicates fine with the print server uses kernel 2.6.8-1.521 My FC3T1 partition is using kernel 2.6.8-1.541 In answer to comment #15, both systems fetch IP address 192.168.1.100 for my computer. The print server is static at 192.168.1.102.
Oops, looks like I forgot to actually change the component before reassigning. Done.
I have just downloaded, installed and fully updated FC3T3. This problem is still present. My Netgear print server at 192.168.1.102 cannot be accessed by the printing system or by telnet. It does respond to a ping. This is an important facility that will prevent me and anyone depending on a networked LPD print server (via CUPS) from using FC3 when it is released. This is with kernel 2.6.8-1.607.
Same problem noted with same print server. Installing the latest FC2 kernel fixes the problem. Telnet to port 23 works OK (not all that useful though).
OUt of curiosity, if you add 'install ipv6 /bin/true' to /etc/modprobe.conf, does that help? (It *shouldn't*, but...)
Thanks for the reply. No, that didn't make any difference. I still can't telnet to the printer IP address as I can in other systems, and the Printer Configuration tool says 'Unable to connect to printer; will retry in 30 seconds...; Connection timed out'
This problem still exists in kernel 640 in FC3 Release Candidate 1, fresh install. Exact same symptoms. It appears that no attention, except a question from Bill Nottingham, has been payed to this bug since Tim Waugh reassigned it to the kernel. Anyone depending on a networked LPD print server for printing will not be able to use FC3 until this is fixed.
FC3 RC2 kernel 643: still the same.
does setting /proc/sys/net/ipv4/tcp_adv_win_scale to 0 fix this ?
I would like to try that, but haven't been able to figure out how to "set" it. tcp_adv_win_scale is a file that contains a single line with the value 2. If I try to edit it as root, it won't let me save it. setting it with [root@gstpc-test ipv4]# set tcp_adv_win_scale=0 [root@gstpc-test ipv4]# cat tcp_adv_win_scale 2 obviously does nothing. What is the protocol necessary to set this? Thanks.
echo 0 > /proc/sys/net/ipv4/tcp_adv_win_scale
I executed the command and the situation did not change. The print server could not be accessed by the Printer Configuration tool, and I could not telnet to the server. Restarting cups did nothing. I rebooted and after reboot, the value is back to 2. Is there any other action I should have taken to test the result?
Just did a fresh install of FC3 Release Candidate 3. Problem is still there. This is still kernel 643.
Fresh install of Release Candidate 5 - problem is still there. A list member sent me the following off list. "Saw your posting on trouble with fc3 and print server. I had a similar problem with recent kernels. The problem, as well as I can determine, is that iptables behaves differently under the more recent kernels. Certain communications with the print server do not get recognized as established connections and are then rejected by the nominal iptables firewall configuration. (They seem to hang as half-open connections.) What I did to work around this problem is create a rule specifically allowing incoming traffic from the print server and the ipp port number. Then all works fine. BTW, I tried the recent fc3 kernels on an FC2 install and encountered the same problem with iptables. All works fine with kernel 521, but have this problem with later kernels. So it would seem not to be CUPS, but something in the kernel." Is this of any help. I do not know how to make the changes he suggests and have asked him in a reply if he can tell me what to do. If you know what to do, I will be anxious to try whatever you suggest.
Thanks to help from Steven Schwartz, I found a key to getting it to work. If I execute /sbin/service iptables off printing works. Of course this is not a valid fix for the problem, but might be a significant clue for finding a real fix.
Steven Scwartz came up with a change to /etc/sysconfig/iptables that allows my print server to work. I added -A RH-Firewall-1-INPUT -p tcp -s 192.168.1.102 --sport 515 -j ACCEPT as the third to last line in this file. I hope this is useful in solving this problem for all users. FC3 should ship with networked print servers working "out of the box."
Trying to understand selinux/iptables, I stumbled on something that may be the key to why networked LPD printing stopped working for me. I ran system-config-securitylevel and discovered on the Firewall Options tab a section labeled Trusted devices. eth0 was not checked. Former installs had a checkbox for selecting eth0 as a trusted device, and I always checked it since I wanted unfettered communication on my LAN which is isolated from the internet by a firewall (hardware router.) I think this option is no longer offered by anaconda, but am not sure. At any rate, I selected eth0 as a trusted device. I then looked in /etc/sysconfig/iptables and found that my added line noted in comment 32 was no longer there, but a new line -A RH-Firewall-1-INPUT -i eth0 -j ACCEPT was added, and printing now works without my modification to the file. So, this may just be a problem with changes in installation configuration where users that previously enabled eth0 as a trusted device no longer have an installation-time choice to do that. They somehow need to be told to manually change this setting in system-config-securitylevel or to add a specific ACCEPT line for the print server to the iptables file. I hope this is clear enough for you to decide how to best handle this for users that will have the same problem I did.
Gerry, While it may be OK for you to have eth0 as a trusted device, I believe you're in a minority. The vast majority of the population would prefer all external netdevs to default to a safe state. It's easy for you to override that, as you found out, but this way, crackers would have a tough time attacking a default configuration. I liked your original idea. IMHO, printconf-gui (and its equivalents) should silently add the rule you mentioned: -A RH-Firewall-1-INPUT -p tcp -s <printer-IP> --sport 515 -j ACCEPT if you specify a networked printer and iptables is active, and modify/remove this rule if the printer is modified/deleted. Since printer configuration requires root privileges, this won't cause any permissions problem.
This appears to be a special feature of the Netgear PS110. I ran into the same problems (except I was using Guarddog to set the iptables firewall, rather than system-config-securitylevel). I replaced my Netgear PS110's with Hawking HPS12U's, and everything worked properly (using LPR). For some reason, the PS110 initiates connections from port 515, which is unusual.
I'm using a TRENDnet TE100-P1P Print Server and got the same issue trying to pring via CUPS. The automatically generated "-A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT" firewall rule is not sufficient to get it work. Manually adding "-A RH-Firewall-1-INPUT -p tcp -s <printer-IP> --sport 631 -j ACCEPT" to "/etc/sysconfig/iptables" was necessary for me. Hope this helps.
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which may contain a fix for your problem. Please update to this new kernel, and report whether or not it fixes your problem. If you have updated to Fedora Core 4 since this bug was opened, and the problem still occurs with the latest updates for that release, please change the version field of this bug to 'fc4'. Thank you.
I am at FC4, and this problem has evidently been cured. I can print to a networked LPD printer with the firewall enabled or disabled without doing anything special with iptables. Thanks.