ports/125153: cups breaks with PF interfaction in 7.0

[Mike Durian]

>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: