From b.candler@pobox.com  Mon Oct 18 11:23:50 2004
Return-Path: <b.candler@pobox.com>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 60B8D16A4CE
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 18 Oct 2004 11:23:50 +0000 (GMT)
Received: from sasl.smtp.pobox.com (puzzle.sasl.smtp.pobox.com [207.8.226.4])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 047B043D48
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 18 Oct 2004 11:23:50 +0000 (GMT)
	(envelope-from b.candler@pobox.com)
Received: from localhost.localdomain (localhost [127.0.0.1])
	by puzzle.pobox.com (Postfix) with ESMTP id DB35A13905A
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 18 Oct 2004 07:23:44 -0400 (EDT)
Received: from vaio.linnet.org (host217-40-157-153.in-addr.btopenworld.com [217.40.157.153])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by puzzle.pobox.com (Postfix) with ESMTP id 47640138DB7
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 18 Oct 2004 07:23:44 -0400 (EDT)
Received: from brian by vaio.linnet.org with local (Exim 4.30)
	id 1CJVcA-000LK3-Hz
	for FreeBSD-gnats-submit@freebsd.org; Mon, 18 Oct 2004 12:23:46 +0100
Message-Id: <E1CJVcA-000LK3-Hz@vaio.linnet.org>
Date: Mon, 18 Oct 2004 12:23:46 +0100
From: Brian Candler <b.candler@pobox.com>
Reply-To: Brian Candler <b.candler@pobox.com>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: libpcap opens bpf as O_RDONLY - doesn't work with ucarp
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         72814
>Category:       bin
>Synopsis:       [patch] libpcap opens bpf as O_RDONLY - doesn't work with ucarp
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    bms
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Mon Oct 18 11:30:25 GMT 2004
>Closed-Date:    Wed Aug 02 11:46:03 GMT 2006
>Last-Modified:  Wed Aug 02 11:46:03 GMT 2006
>Originator:     Brian Candler
>Release:        FreeBSD 4.10-STABLE i386
>Organization:
>Environment:
System: FreeBSD vaio.linnet.org 4.10-STABLE FreeBSD 4.10-STABLE #0: Sun Sep 26 17:08:21 BST 2004 root@vaio.linnet.org:/usr/obj/usr/src/sys/VAIO i386

also tested with FreeBSD-5.2.1-RELEASE

	
>Description:

libpcap opens /dev/bpfX as O_RDONLY rather than O_RDWR. This affects
applications which open bpf using pcap_open_live, then get the fileno and
try to use it to send packets. The particular application I have a problem
with is ucarp - http://www.ucarp.org/ - which is a VRRP-type failover
system deriving from OpenBSD.

I do realise that carp may find its way into the FreeBSD kernel post 5.3
but a userland implementation is still convenient.

However note that NetBSD works with ucarp, and NetBSD opens the bpf device
in O_RDWR mode unconditionally:
http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libpcap/pcap-bpf.c?rev=1.12
(search for bpf_open)

NetBSD and FreeBSD apparently both imported libpcap-0.8.3, so I don't know
where this difference arose.

>How-To-Repeat:
See src/contrib/libpcap/pcap-bpf.c
search for 'bpf_open'

Try installing and running ucarp - it silently fails to send packets.
Changing O_RDONLY to O_RDWR and make install for libpcap fixes it.
>Fix:

Consider:

(1) Changing libpcap to open in O_RDWR mode unconditionally, as NetBSD does

(2) Changing libpcap to attempt open in O_RDWR mode, fallback to O_RDONLY if
it fails.

         */
        do {
                (void)snprintf(device, sizeof(device), "/dev/bpf%d", n++);
-               fd = open(device, O_RDONLY);
+               fd = open(device, O_RDWR);
+               if (fd < 0 && errno == EACCES)
+                       fd = open(device, O_RDONLY);
        } while (fd < 0 && errno == EBUSY);

        /*

(3) Adding a new entry point to libpcap which does the same as
pcap_open_live but uses O_RDWR instead of O_RDONLY

>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->analyzed 
State-Changed-By: bms 
State-Changed-When: Thu Dec 9 10:30:32 GMT 2004 
State-Changed-Why:  
We're aware of this issue already and had tried to fix it in ways 
similar to 1) and 2). 

This resulted in a bit of a frenzied discussion about taking the files 
off the vendor branch. 

So the likely solution to this will be 3). This is not likely to happen 
until the next tcpdump import, and we're still waiting on tcpdump.org 
to make a new release (the last release was 9 months ago, and I was 
responsible for dealing with the last pcap/tcpdump import). 



Responsible-Changed-From-To: freebsd-bugs->bms 
Responsible-Changed-By: bms 
Responsible-Changed-When: Thu Dec 9 10:30:32 GMT 2004 
Responsible-Changed-Why:  
I'm the responsible party... 

http://www.freebsd.org/cgi/query-pr.cgi?pr=72814 
State-Changed-From-To: analyzed->closed 
State-Changed-By: bms 
State-Changed-When: Wed Aug 2 11:45:20 UTC 2006 
State-Changed-Why:  
Sam imported a more recent libpcap while I was probably busy off 
having a job/life/thing. It looks like libpcap now tries to open 
bpf in read-write mode by default and falls back to read-only 
if that fails. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=72814 
>Unformatted:
