ports/125153: cups breaks with PF interfaction in 7.0
Mike Durian
durian at shadetreesoftware.com
Tue Jul 1 18:00:21 UTC 2008
>Number: 125153
>Category: ports
>Synopsis: cups breaks with PF interfaction in 7.0
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: freebsd-ports-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Tue Jul 01 18:00:15 UTC 2008
>Closed-Date:
>Last-Modified:
>Originator: Mike Durian
>Release: FreeBSD 7.0-STABLE i386
>Organization:
>Environment:
System: FreeBSD cedar.shadetreesoftware.com 7.0-STABLE FreeBSD 7.0-STABLE #2: Sun Jun 29 12:37:20 MDT 2008 root at cedar.shadetreesoftware.com:/usr/obj/usr/src/sys/SHADETREE i386
>Description:
Cups, specificall the socket backend, fails with what I believe
to be a pf firewall interaction in 7.0-STABLE. This did fail
in 6.3.
The socket back end sends some data to the printer, but eventually
gets a write(2) failure. The errno is EPERM, which is think
is only generated by the firewall. At least the write(2) man page
doesn't document it.
In my case, I am trying to print a document through a VPN.
I have a gif tunnel set up with ipsec as described in the
FreeBSD handbook and some web site.
Here is my test case. /tmp/foo.pcl is a pre-rendered version
of the cups test page.
> DEVICE_URI=socket://superfly.boogie.com:9100 ktrace -f /tmp/cups_socket.out /usr/local/libexec/cups/backend/socket 1 durian foo 1 "" /tmp/foo.pcl
INFO: Attempting to connect to host superfly.boogie.com on port 9100
STATE: +connecting-to-device
STATE: -connecting-to-device
INFO: Connected to superfly.boogie.com...
DEBUG: Connected to 192.168.1.5:9100 (IPv4)...
PAGE: 1 1
DEBUG: backendRunLoop(print_fd=3, device_fd=4, use_bc=1, side_cb=0x8048f20)
DEBUG: Read 8192 bytes of print data...
STATE: -media-empty-error
STATE: -offline-error
INFO: Printer is now on-line.
DEBUG: Wrote 8192 bytes of print data...
DEBUG: Read 8192 bytes of print data...
DEBUG: Wrote 8192 bytes of print data...
DEBUG: Read 8192 bytes of print data...
DEBUG: Wrote 8192 bytes of print data...
DEBUG: Read 8192 bytes of print data...
DEBUG: Wrote 8192 bytes of print data...
DEBUG: Read 8192 bytes of print data...
DEBUG: Wrote 8192 bytes of print data...
DEBUG: Read 8192 bytes of print data...
DEBUG: Wrote 8192 bytes of print data...
DEBUG: Read 8192 bytes of print data...
DEBUG: Wrote 8192 bytes of print data...
DEBUG: Read 8192 bytes of print data...
DEBUG: Wrote 8192 bytes of print data...
DEBUG: Read 8192 bytes of print data...
DEBUG: Wrote 8192 bytes of print data...
DEBUG: Read 8192 bytes of print data...
DEBUG: Wrote 8192 bytes of print data...
DEBUG: Read 8192 bytes of print data...
DEBUG: Wrote 8192 bytes of print data...
DEBUG: Read 8192 bytes of print data...
ERROR: Unable to write print data: Operation not permitted
INFO: Print file sent, waiting for printer to finish...
The ktrace is rather large. Rather than include it all here,
I'll just excerpt the falling write(2):
39702 socket RET read 8192/0x2000
39702 socket CALL write(0x2,0xbfbfb3d0,0x28)
39702 socket GIO fd 2 wrote 40 bytes
"DEBUG: Read 8192 bytes of print data...
"
39702 socket RET write 40/0x28
39702 socket CALL select(0x5,0xbfbfbae0,0xbfbfba60,0,0)
39702 socket RET select 1
39702 socket CALL write(0x4,0xbfbfbb78,0x2000)
39702 socket RET write -1 errno 1 Operation not permitted
39702 socket CALL write(0x2,0xbfbfb3d0,0x3b)
39702 socket GIO fd 2 wrote 59 bytes
"ERROR: Unable to write print data: Operation not permitted
"
I suspect someone will want more data on my pf.conf file and
vpn setup. Please contact me and let me know what you'd like to
see.
I can work around the problem by adding IPSEC_FILTERTUNNEL to
the kernel build, but that has its own adverse effect on
asterisk. Since I did not need IPSEC_FILTERTUNNEL in 6.3,
I believe there is a new bug somewhere and have opted for
VoIP over printing.
The far end of the VPN is also running 7.0.
>How-To-Repeat:
Set up a VPN using gif and ipsec. Try using cups to print
to port 9100 on a printer on the far end of the VPN.
>Fix:
Adding "options IPSEC_FILTERTUNNEL" to the kernel config file
can work around this problem, but is not a viable solution for
me due to some bad interactions with asterisk.
>Release-Note:
>Audit-Trail:
>Unformatted:
More information about the freebsd-ports-bugs
mailing list