Remote LPD queue not responding

Sometime after upgrading, I find that sending a file to an LPD queue on our server no longer works. ('Operation timed out.'

Printing initiated by a logged-on server user works normally.

The queue is 'RAW' and is plugged to an Epson-880.

Remote users using LPQ find that the local system is trying unsuccessfully to send the file to the server.

Remote can easily ping the server using this name; connection, and DNS resolution, are known to be good.

What is an appropriate strategy for analyzing and solving this problem?

- can you print locally ? (seems to work in your case) - can you ping the printserver with ip (

Naah... more basic than that. An M-B-F (Momentary Brain Fart) and a F-I-R-E-W-A-L-L!

/ ...

The 'appropriate strategy' is to change a line in /etc/lpd.perms from:

REJECT SERVICE=X NOT SERVER

(meaning accept only non-network jobs) to:

ACCEPT SERVICE=X NOT SERVER

And please don't reply saying 'that doesn't work on my distribution.' Why? Becasue you don't identify your distribution, which means anything always works.

Thanks to Paul Lutus for providing what turned out to be the other-half of the right answer to this puzzle.

The '/etc/lpd.perms' file controls access to the print queue and, indeed, there was now a statement in it which said

REJECT SERVICE=X NOT SERVER

As explained in the prologue comments in that file, 'SERVICE=X' refers to a request to start a job. The rule 'NOT SERVER' means that the job was not from the local user. The rule matches, and rejects the job.

I altered the file to include these three rules instead:

ACCEPT SERVICE=X SERVER ACCEPT SERVICE=X REMOTEIP=192.168.0.0/255.255.0.0 (see note) REJECT SERVICE=X

note: It was not clear to me if '192.168.0.0/16' would or would not have been accepted. I believe that it would be, and expect that it would be.

I'm a little dismayed that the print-spooler on the local machine never /said/ that 'the remote printer is 'rejecting' your request.' It behaved as though the remote was 'not answering the phone,' instead of 'permission

You are welcome.

Show me your netmask and I'll tell you if you are granting too much leeway. These are equivalents:

192.168.0.1/255.255.255.000 -and- 192.168.0.1/24 (class C)

192.168.0.1/255.255.000.000 -and- 192.168.0.1/16 (class

192.168.0.1/255.000.000.000 -and- 192.168.0.1/08 (class A)

Your example above allows access to the entire 192.168.0.0/255.255.0.0 class B network, by definition local, so you are probably OK. You can, if you prefer, specify a particular machine or set of machines.

I went through the same thing, which is why I remembered it. I ended up reading every line of every remotely relevant configuration file.

I am not sure what would happen if I let them, since they could not really get a TCP/IP connection set up (though perhaps they could mess me up with UDP packets), since I could not respond. But I block them with ipchains anyway, just in case.

/ ...

You do realize, don't you, that they cannot be coming from the Internet? The reason you see this specific address range so often in LAN conversations is because it is private by definition

Since the previous poster mentioned the packets are coming in on the ppp port, I would have to suspect that the 192.168.x.x packets are coming from his ISP (making the assumption that there's an ISP at the other end of his ppp link.) If that's the case, would it be correct to assume that there's a misconfiguration at the ISP's end? They really should not be forwarding those private address ranges down the pipe to the customer, right?

/ ...

Quite correct. This is abnormal IMHO, and evidence of either hacking of