From owner-freebsd-net@FreeBSD.ORG Tue Jun 7 21:36:08 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3415B16A41C for ; Tue, 7 Jun 2005 21:36:08 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.73]) by mx1.FreeBSD.org (Postfix) with ESMTP id D7D1143D5D for ; Tue, 7 Jun 2005 21:36:07 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin02-en2 [10.13.10.147]) by smtpout.mac.com (Xserve/8.12.11/smtpout16/MantshX 4.0) with ESMTP id j57La6Re021100; Tue, 7 Jun 2005 14:36:07 -0700 (PDT) Received: from [192.168.1.6] (pool-68-161-53-96.ny325.east.verizon.net [68.161.53.96]) (authenticated bits=0) by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id j57La46V013163; Tue, 7 Jun 2005 14:36:05 -0700 (PDT) In-Reply-To: <42A60A03.2000101@luckie.org.nz> References: <4295A6CA.8080409@luckie.org.nz> <20050606081637.GA73886@lycra.luckie.org.nz> <20050606120851.GD734@empiric.icir.org> <20050606204008.GA91353@lycra.luckie.org.nz> <20050607101927.GA99034@lycra.luckie.org.nz> <20050607112340.GC812@empiric.icir.org> <42A5FB72.4010603@luckie.org.nz> <43393A5D-A13B-4385-A6E3-EDD21343277A@mac.com> <42A60A03.2000101@luckie.org.nz> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6C52F579-B9E9-43DF-A169-561209DA010B@mac.com> Content-Transfer-Encoding: 7bit From: Charles Swiger Date: Tue, 7 Jun 2005 17:36:02 -0400 To: Matthew Luckie X-Mailer: Apple Mail (2.730) Cc: freebsd-net@freebsd.org Subject: Re: bpf writes on tun device X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2005 21:36:08 -0000 On Jun 7, 2005, at 4:56 PM, Matthew Luckie wrote: >> Agreed. When you use BPF or PCAP to capture packets, for the >> DTL_NULL case there is a 4-byte offset between where PCAP says >> the packet starts and where the actual raw IP packet starts. >> If you want BPF/PCAP to return packets without the 4-byte offset, >> the associated datalink type is actually called DLT_RAW. Note >> that the behavior of DLT_NULL is useful in practice, since you >> can find out what the "ether type" of the packet was per > ethernet.h>: > > unless i'm mistaken, the 4 byte field is actually the address > family of the packet. so AF_INET, AF_INET6, etc. the ethertype > thing is for DLT_EN10MB devices. If you're trying to write traffic using socket(), sure, you might very well specify AF_INET as the first argument (domain), but the machine doesn't actually put the value of the address family into the link-level header of the packet that goes out across the wire. I agree that the ethertype thing is supposed to be for ethernet-style devices, but try sending some traffic over lo0, and capture it, and take a look at the first four bytes. Maybe I'm confused, but I remember seeing 0x0800 and 0x86dd, respectively, not 0x2 (AF_INET) or 30 (AF_INET6). When writing packets, I found that even using SOCK_RAW the kernel would fill in a lot of stuff that I didn't want it to, and instead I needed to talk with BPF directly or use something like libnet to build the packets. I am pretty sure this is why the ISC DHCP software depends on BPF, because it can't generate ARPOP_REQUESTS and so forth using the normal socket mechanisms to query whether an IP addr is in use...? -- -Chuck