Gerard Seibert wrote: > OK, the ifconfig lo0 looks like this: > > ~ $ ifconfig lo0 > lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 > inet 127.0.0.1 netmask 0xff000000
No problems there.
> The sockstat | grep :25
>
> ~ $ sockstat | grep :25
>
> root master 681 11 tcp4 *:25 *:*
> root ntpd 519 6 udp6 fe80:1::250:baff:fe43:3a7f:123*:*
Your MTA is not listening on any IPv6 addresses -- that might be by design.
If that is so and if you're in the habit of telnet'ing to localhost port 25
to test things, you need to make it so that localhost resolves to 127.0.0.1
rather than ::1. That depends on where your system finds the info from. If
it's /etc/hosts then you can comment out the ::1 entry there and leave just
127.0.0.1. If it's the DNS, and assuming you don't have any control over
the server, then you can try tweaking /etc/nsswitch.conf so that host lookups
consult /etc/hosts first, and don't go to the DNS if they find an answer in
/etc/hosts.
Perhaps easier in the long run to get your MTA IPv6 enabled.
> And finally: sockstat | grep :515
>
> ~ $ sockstat | grep :515
>
> daemon lpd 915 6 tcp4 *:515 *:*
Again, lpd is not listening on any IPv6 addresses. According to the man
page it should default to listening on both IPv4 and IPv6 addresses.
You can try adding:
lpd_flags="-46"
into /etc/rc.conf and then '/etc/rc.d/lpd restart' That *should* be the
default, but it's worth trying.
> Finally, this is a quick list of what happens when I issue 'lpr'
> commands. You will notice that there is a slight difference in the error
> message displayed, but the result is the same. I can, however, print a
> test page using apsfilter. I am at my wits end to figure out what is
> happening. If I had any hair left, I would be pulling it out by now.
Printing from the localhost will generally use the Unix domain socket at
/var/run/printer. In fact, if all you want to do is print from localhost,
then putting:
lpd_flags='-s'
in rc.conf is a good move -- that stops lpd listening on any network
interfaces.
Also check /etc/hosts.lpd for sanity -- you need to list hosts allowed to
send jobs to the printer in that file.
If the remote hosts you're trying to print from are not Unix machines, then
you may have to add '-W' to the lpd_flags to permit lpd to accept print jobs
where the sending side does not use a privileged socket.
> ~ $ lpc status all
> Printer Printing Spooling Jobs Server Subserver Redirect
> Status/(Deb
> ug)
> [EMAIL PROTECTED] enabled enabled 0 none none
Ah... You aren't running the system lpr/lpd then? That produces output more
like this:
happy-idiot-talk:/etc:% lpc status all
lp:
queuing is enabled
printing is enabled
no entries in spool area
printer idle
If that is what you intended, then you'll have to consult the manuals for the
printer daemon you are running and adapt the instructions I gave above
appropriately.
> ~ $
> ~ $ lpr -Pscorpio /etc/printcap
> lpr: Connection refused
> ~ $
> ~ $ lpr -Pseibercom /etc/printcap
> lpr: Connection refused
> ~ $
> ~ $ lpr -Pseibercom.net /etc/printcap
> lpr: Connection refused
> ~ $
> ~ $ lpr /etc/printcap
> lpr: Error - scheduler not responding!
>
Also, if you describe what printers you have and where it might help -- the
above either shows a lot of attempts to connect to a network interface where
there
is no lpd listening, or the effect of some overzealous firewall rules dropping
lpr traffic.
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
Kent, CT11 9PW
signature.asc
Description: OpenPGP digital signature
