Date: Tue, 1 Jul 2008 11:25:09 -0600 (MDT) From: Mike Durian <durian@shadetreesoftware.com> To: FreeBSD-gnats-submit@FreeBSD.org Subject: ports/125153: cups breaks with PF interfaction in 7.0 Message-ID: <200807011725.m61HP9fd040129@shadetreesoftware.com> Resent-Message-ID: <200807011800.m61I0Lc3009279@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>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@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:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200807011725.m61HP9fd040129>