From owner-freebsd-net@FreeBSD.ORG Sun Nov 2 00:35:17 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EE9C106567E for ; Sun, 2 Nov 2008 00:35:17 +0000 (UTC) (envelope-from prvs=julian=185d67ddd@elischer.org) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id 29AD58FC14 for ; Sun, 2 Nov 2008 00:35:17 +0000 (UTC) (envelope-from prvs=julian=185d67ddd@elischer.org) Received: from unknown (HELO julian-mac.elischer.org) ([10.251.60.45]) by smtp-outbound.ironport.com with ESMTP; 01 Nov 2008 17:06:42 -0700 Message-ID: <490CEF11.4010007@elischer.org> Date: Sat, 01 Nov 2008 17:06:41 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Joe Pellegrino References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: A netgraph question. 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: Sun, 02 Nov 2008 00:35:17 -0000 Joe Pellegrino wrote: > > OK so here it goes. I actually have two seperate questions involving > netgraph, I am new to this subject so please bare with me. If there is a > better way to achieve these goals too, please suggest them but I think > netgraph is the way to go. > I'll try answer your questions.. > The first part involves allowing a userland program to communicate with > a kernel module, similar to how netlink works in Linux. The second part > involves intercepting network packets and possibly manipulating them > before they are allowed to proceed, similar to how netfilter works. I > believe I can do both of these with the netgraph (ng_socket and possibly > ng_ether). I haven't looked closely at ng_ether yet so I'll focus on > ng_socket. > > I have been able to create a ng_socket (Control and Data) using the > socket call as described in "All About NetGraphs" and the man page. I've > also been able to 'name' the node using bind. I was able to verify this > using ngctl. I know (from the man page) I should eventually be able to > send/receive using the sendto/recvfrom functions once the connection is > established. But beyond this I don't know how to proceed. So the > question is what are the next steps. For example: > > Although I see a named netgraph node there are no hooks. ng_socket says > it supports an arbitrary number of hooks so how do I create the hooks? > Then of course how do I connect them. Hooks are created on demand.. you need to send a 'connect' or 'mkpeer' message to the node(s) on which you want t script level, you just use the ngctl program to do it for you. Hooks are always made in pairs. so you need two nodes to connect. The mkpeer message does this for you, and creates a new node and connects them together by two hooks of the names you specify. Have you looked at the sample netgraph scripts in /usr/share/examples/netgraph? > > Of course I realize that I proabably need to create a node on the kernel > side so which type of netgraph node would be suggested? How is it > created and then hooked to the ng_socket? for fun you could use the ng_echo node type which would send everything you want back to you.. Alternatively when you kldload the ng-ether node type, then all the ethernets will grow nodes to match them so you can connect to them directly. You could connect an ng_bpf (packet filter) node to the ng_ether node and pass specific packets only on to the socket. I'm not sure if teh bpf filter assumes it has the whole packet or just the IP packet, but assuming your interface was em0, so you could do something like: # hook the 'lower' hook of em0 to the bpf filter. ngctl mkpeer 'em0' bpf lower input #name the bpf node so we can reference it easily ngctl name em0.lower filter # connect the upper part of the filter to the ethernet # so that packets not accepted are sent on as before ngctl connect em0 filter upper nomatch # we need to connect the 'match' hook of the filter to something # that we can connect to later so use a 'tee' node as a paperweight. ngctl mkpeer filter tee match left ngctl name filter.match paperweight # now program the bpf node's 'input' hook to filter packets # as shown in the ng_bpf man page [steal code from ng_bpf man page] # program the 'match' hook with a null program to pass it's packets # (outgoing packets) straight back to 'lower' [steal code from ng_bpf man page] # now connect to the 'right' hook of the tee # to get output. nghook -a paperweight right you should now have hex encoded output of all packets you have selected by the bpf filter. the weakness of this is that I'm not sure if the ng_bpf node handles ethernet packets.. yo may need ot use some other node.. if you want to write your own node, start with the code in /usr/src/sys/netgraph/ng_sample.c to compile it, go to /usr/src/sys/modules/netgraph and copy one of the existing directories modify the makefile to reference you new file and use 'make' > > Again I am looking to allow some IPC between a userland program and a > kernel module similar to the Linux netlink. I've been through most man > pages and can't seem to find a lot of good documentation or example code > so I am hoping to get some pointers here. BTW If this is the wrong list > please directly to the right place to ask. Thanks in advance. not sure what netlink does.. (will look on google :-) > > ---jdp > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sun Nov 2 01:13:16 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A730B106564A for ; Sun, 2 Nov 2008 01:13:16 +0000 (UTC) (envelope-from brian.mcginty@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by mx1.freebsd.org (Postfix) with ESMTP id 57BD68FC1A for ; Sun, 2 Nov 2008 01:13:16 +0000 (UTC) (envelope-from brian.mcginty@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so741532ywe.13 for ; Sat, 01 Nov 2008 18:13:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=CCb3sAu5R6zAgqSxE2fLudI6a3Tdp942onGiPl8FEi4=; b=D1NaBDfKknaiOJd3ilxIto8wSNYb7ElMZK1aRnxf5xaNuNn/WM+qzY25ce9EQ1VteE VOuV9uUZl/5I3hg3Pkr63aZA9FRGQzWq1wEMejqo6DJkViIFkTjSMP8Ed9dtFZCjTzgh tHOuykyDeAjhQdNME/nOnuwl81wQ0zrOH4d48= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=XWkBN+VMgWg+07ZW2W6A7rtESHdqOVWeH3o6OL7VRI4ilA7YG3w1GAAmkwGWCQOSEu bXnnCpBGtMMwOtwAVzuz3wI2XvRXJnAp4kKaeO7rbr34HpBIcHE+L84XqdDfthVIbKhy /7AUt/n/9iVEodhe0V9ZgE663JrZq7d1og3cc= Received: by 10.90.117.20 with SMTP id p20mr11501405agc.2.1225586799998; Sat, 01 Nov 2008 17:46:39 -0700 (PDT) Received: by 10.90.27.6 with HTTP; Sat, 1 Nov 2008 17:46:39 -0700 (PDT) Message-ID: <601bffc40811011746x5c684e3fs89e3019688a333ab@mail.gmail.com> Date: Sat, 1 Nov 2008 17:46:39 -0700 From: "Brian McGinty" To: "Mihail Balikov" In-Reply-To: <499a3e640810282326p99e0d1eud93c7ecd310c8145@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <499a3e640810282326p99e0d1eud93c7ecd310c8145@mail.gmail.com> Cc: freebsd-net@freebsd.org Subject: Re: ixgbe vs mxge 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: Sun, 02 Nov 2008 01:13:16 -0000 I don't know nothing about mxge so I can't comment, but I know that FreeBSD ixgbe driver is not even close to that of the Linux version. I switched to Linux just for ixgbe as our network was being standardized on 10G, and I think that's the best bet. The Linux version of the driver is actively worked on and I got a lot of help and bug fixes from the maintainers of the driver, whereas the FreeBSD driver is hopelessly neglected and broken. Brian On Tue, Oct 28, 2008 at 11:26 PM, Mihail Balikov wrote: > Hi, > > I would like to setup 10gbit bridge on FreeBSD7 , but I'm little bit > confused which vendor to choose for the NICs. > Can you send me some feed back? > > regards, > Mihail Balikov > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Sun Nov 2 01:18:04 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 083D110656AD for ; Sun, 2 Nov 2008 01:18:04 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.237]) by mx1.freebsd.org (Postfix) with ESMTP id CC6BF8FC29 for ; Sun, 2 Nov 2008 01:18:03 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1804991rvf.43 for ; Sat, 01 Nov 2008 18:18:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=Tvkk977O8ZLhOIMU/fSvyEwi1SECqRB5X1TTOXJI7ZM=; b=JhK1Vj8rOwWOJeIpxdd4unxbVjYe9eq5L4JPAiob8bC+JIxIvYv4zjARNrIC1Pk+Ch o4IgslxJZ4W109Lnw9vzrsQiycoVsybEl7wEmgA+bdWKC6HoKg3TLMTJll2t5XWmP4Z+ ncHWR/r6Gqi1XIg/SXvoJbi/BtRu39xYg/COw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=VANET8LX49BNpdbsRFQMiZ6v97SRstp+m9OJqnu5Npu5ZX8oBXRwS4AgFdZ+UBeJyC jDV8NcqjVYvERZIJ7n7yYAYmspEt2IdalrqtJNWSkRNrMBJOp1w+reQd8SwIMxe9bMWd MA80OLZzU+BOOyl8Yl5FWYnetR/kPK69Xp8yI= Received: by 10.141.197.14 with SMTP id z14mr7830839rvp.283.1225588683643; Sat, 01 Nov 2008 18:18:03 -0700 (PDT) Received: by 10.140.157.8 with HTTP; Sat, 1 Nov 2008 18:18:03 -0700 (PDT) Message-ID: <3c1674c90811011818m6a6bfeb6o1973aed13813b845@mail.gmail.com> Date: Sun, 2 Nov 2008 01:18:03 +0000 From: "Kip Macy" Sender: mat.macy@gmail.com To: freebsd-net@freebsd.org In-Reply-To: <601bffc40811011746x5c684e3fs89e3019688a333ab@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <499a3e640810282326p99e0d1eud93c7ecd310c8145@mail.gmail.com> <601bffc40811011746x5c684e3fs89e3019688a333ab@mail.gmail.com> X-Google-Sender-Auth: 28e9beacf309d47e Subject: Re: ixgbe vs mxge 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: Sun, 02 Nov 2008 01:18:04 -0000 As a point of reference for fellow readers: http://www.google.com/search?hl=en&q=brian.mcginty+freebsd&btnG=Google+Search&aq=f&oq= On Sun, Nov 2, 2008 at 12:46 AM, Brian McGinty wrote: > I don't know nothing about mxge so I can't comment, but I know that > FreeBSD ixgbe driver is not even close to that of the Linux version. I > switched to Linux just for ixgbe as our network was being standardized > on 10G, and I think that's the best bet. The Linux version of the > driver is actively worked on and I got a lot of help and bug fixes > from the maintainers of the driver, whereas the FreeBSD driver is > hopelessly neglected and broken. > > Brian > > On Tue, Oct 28, 2008 at 11:26 PM, Mihail Balikov wrote: >> Hi, >> >> I would like to setup 10gbit bridge on FreeBSD7 , but I'm little bit >> confused which vendor to choose for the NICs. >> Can you send me some feed back? >> >> regards, >> Mihail Balikov >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Sun Nov 2 01:21:27 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A365106568D for ; Sun, 2 Nov 2008 01:21:27 +0000 (UTC) (envelope-from jdp@elvis.rowan.edu) Received: from elvis.rowan.edu (elvis.rowan.edu [150.250.64.69]) by mx1.freebsd.org (Postfix) with ESMTP id B85748FC16 for ; Sun, 2 Nov 2008 01:21:26 +0000 (UTC) (envelope-from jdp@elvis.rowan.edu) Received: from elvis.rowan.edu (localhost [127.0.0.1]) by elvis.rowan.edu (8.13.8+Sun/8.13.8) with ESMTP id mA21LPjL016473; Sat, 1 Nov 2008 21:21:25 -0400 (EDT) Received: from localhost (jdp@localhost) by elvis.rowan.edu (8.13.8+Sun/8.13.8/Submit) with ESMTP id mA21LOfF016469; Sat, 1 Nov 2008 21:21:24 -0400 (EDT) Date: Sat, 1 Nov 2008 21:21:23 -0400 (EDT) From: Joe Pellegrino To: Julian Elischer In-Reply-To: <490CEF11.4010007@elischer.org> Message-ID: References: <490CEF11.4010007@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: A netgraph question. 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: Sun, 02 Nov 2008 01:21:27 -0000 On Sat, 1 Nov 2008, Julian Elischer wrote: > I'll try answer your questions.. > > Hooks are created on demand.. > you need to send a 'connect' or 'mkpeer' message to the node(s) > on which you want t script level, you just use the ngctl program > to do it for you. > > Hooks are always made in pairs. so you need two nodes to connect. > The mkpeer message does this for you, and creates a new node and connects > them together by two hooks of the names you specify. > > Have you looked at the sample netgraph scripts in > /usr/share/examples/netgraph? > Yep, I've looked at those but if I recall they are all scripts. I am looking for some C or C++ example. Basically on the userland side I have something like: #include <..> #include int main () { int s1 = socket (PF_NETGRAPH, SOCK_DGRAM, NG_CONTROL) int s2 = socket (PF_NETGRAPH, SOCK_DGRAM, NG_DATA) bind(...); } This gives me a node with a name, set with bind, of type socket and no hooks. The kernel module I don't have any netgraph code yet but I figure it will involve a set of calls similar to the userland program. So if I want to interact with the socket the userland program created, what kind of node do I create in the module? Another ng_socket or a ng_ksocket or something different. Then how do I go about connecting the two hooks? >> Of course I realize that I proabably need to create a node on the kernel >> side so which type of netgraph node would be suggested? How is it created >> and then hooked to the ng_socket? > > for fun you could use the ng_echo node type which would send everything you > want back to you.. > > Alternatively when you kldload the ng-ether node type, then all the ethernets > will grow nodes to match them so you can connect to them directly. > > You could connect an ng_bpf (packet filter) node to the ng_ether node > and pass specific packets only on to the socket. > I'll look into this for the other half of what I am playing with. I looked at bpf by itself and it seemed to me it made a copy of the packet, with the original continuing up the stack rather than diverting the packet. But I am getting ahead of myself. I'd like to get the userland <-> module part together first. :) And all the example code are scripts. Am I missing someting? >> pages and can't seem to find a lot of good documentation or example code so >> I am hoping to get some pointers here. BTW If this is the wrong list please >> directly to the right place to ask. Thanks in advance. > > not sure what netlink does.. > (will look on google :-) > Thanks for your help, there is a reasonable entry in the wiki about it. ---jdp From owner-freebsd-net@FreeBSD.ORG Sun Nov 2 02:14:33 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A4301065670 for ; Sun, 2 Nov 2008 02:14:33 +0000 (UTC) (envelope-from prvs=julian=185d67ddd@elischer.org) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id F20AE8FC0A for ; Sun, 2 Nov 2008 02:14:32 +0000 (UTC) (envelope-from prvs=julian=185d67ddd@elischer.org) Received: from unknown (HELO julian-mac.elischer.org) ([10.251.60.58]) by smtp-outbound.ironport.com with ESMTP; 01 Nov 2008 19:14:21 -0700 Message-ID: <490D0CFB.5040102@elischer.org> Date: Sat, 01 Nov 2008 19:14:19 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Joe Pellegrino References: <490CEF11.4010007@elischer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: A netgraph question. 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: Sun, 02 Nov 2008 02:14:33 -0000 Joe Pellegrino wrote: > On Sat, 1 Nov 2008, Julian Elischer wrote: > >> I'll try answer your questions.. >> >> Hooks are created on demand.. >> you need to send a 'connect' or 'mkpeer' message to the node(s) >> on which you want t script level, you just use the ngctl program >> to do it for you. >> >> Hooks are always made in pairs. so you need two nodes to connect. >> The mkpeer message does this for you, and creates a new node and >> connects them together by two hooks of the names you specify. >> >> Have you looked at the sample netgraph scripts in >> /usr/share/examples/netgraph? >> > > Yep, I've looked at those but if I recall they are all scripts. I am > looking for some C or C++ example. Basically on the userland side I have > something like: > > #include <..> > #include > > int main () { > int s1 = socket (PF_NETGRAPH, SOCK_DGRAM, NG_CONTROL) > int s2 = socket (PF_NETGRAPH, SOCK_DGRAM, NG_DATA) > bind(...); > > } > > This gives me a node with a name, set with bind, of type socket and no > hooks. > > The kernel module I don't have any netgraph code yet but I figure it > will involve a set of calls similar to the userland program. So if I > want to interact with the socket the userland program created, what kind > of node do I create in the module? Another ng_socket or a ng_ksocket or > something different. Then how do I go about connecting the two hooks? > >>> Of course I realize that I proabably need to create a node on the >>> kernel side so which type of netgraph node would be suggested? How is >>> it created and then hooked to the ng_socket? >> >> for fun you could use the ng_echo node type which would send >> everything you want back to you.. >> >> Alternatively when you kldload the ng-ether node type, then all the >> ethernets will grow nodes to match them so you can connect to them >> directly. >> >> You could connect an ng_bpf (packet filter) node to the ng_ether node >> and pass specific packets only on to the socket. >> > > I'll look into this for the other half of what I am playing with. I > looked at bpf by itself and it seemed to me it made a copy of the > packet, with the original continuing up the stack rather than diverting > the packet. But I am getting ahead of myself. I'd like to get the > userland <-> module part together first. :) And all the example code are > scripts. Am I missing someting? have you done man 3 netgraph to look at the netgraph management library? for example programs, see: /usr/src/usr.sbin/nghook /usr/src/usr.sbin/ngctl /usr/ports/net/mpd (you'll need to download the sources with "make") > >>> pages and can't seem to find a lot of good documentation or example >>> code so I am hoping to get some pointers here. BTW If this is the >>> wrong list please directly to the right place to ask. Thanks in advance. >> >> not sure what netlink does.. >> (will look on google :-) >> > > Thanks for your help, there is a reasonable entry in the wiki about it. > > ---jdp From owner-freebsd-net@FreeBSD.ORG Sun Nov 2 18:34:21 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 326A51065674 for ; Sun, 2 Nov 2008 18:34:21 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by mx1.freebsd.org (Postfix) with ESMTP id AF18E8FC08 for ; Sun, 2 Nov 2008 18:34:19 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so1784077fgb.35 for ; Sun, 02 Nov 2008 10:34:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=X3K6DJ2K+cyw5LZtEuHe8zsXkD8HzfYu1+kfD92WWPA=; b=po2OM+ITgfJCF238XShxdgBKx5I8uBOhpmi7dIx0tvDrOunu2KmdYGP9AvLoZ9FGw3 Wlx/f+j/PsgatiYVA5EypWVbjkggWPrQ+c22zC8V+dm/e9KVeX58OgOJgKEv23CUlDfx N8vuEKU9sc99CyY32sWetswokFAVUvSNsLD6w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=Sw/Q5sB0L2b3z6YhxDXTgObgffAjF9Nzp61HPGA6v4Wb011opO027BNd8DLiyjMpyT RrrkOAxPJ6vgWdHcZ6QiNq8CrvYEfzMRcgH8i6mqr2sJdCU+i4wQKCD/LI0QkrpigYX7 XqyS8iaF1r/rOYwMVNRuNOWRMeBg6kISDqt/g= Received: by 10.181.137.17 with SMTP id p17mr3922519bkn.40.1225650858138; Sun, 02 Nov 2008 10:34:18 -0800 (PST) Received: by 10.180.208.16 with HTTP; Sun, 2 Nov 2008 10:34:18 -0800 (PST) Message-ID: <2a41acea0811021034x45b86de1q43ef867333dfbd20@mail.gmail.com> Date: Sun, 2 Nov 2008 10:34:18 -0800 From: "Jack Vogel" To: "Brian McGinty" In-Reply-To: <601bffc40811011746x5c684e3fs89e3019688a333ab@mail.gmail.com> MIME-Version: 1.0 References: <499a3e640810282326p99e0d1eud93c7ecd310c8145@mail.gmail.com> <601bffc40811011746x5c684e3fs89e3019688a333ab@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Mihail Balikov Subject: Re: ixgbe vs mxge 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: Sun, 02 Nov 2008 18:34:21 -0000 You know I generally try to maintain courtesy and civility in my dealings with the community but this really ticks me off. I have stayed out of this thread because I figured it was only fair that those with obvious bias should do so. Hopelessly neglected and broken?? ...the driver is maintained by me, and I am in the same organization as the developers of the Linux driver. If anyone has real questions about my driver and our hardware you may contact me. Jack Vogel Sr. Network Engineer Intel Lan Access Division On Sat, Nov 1, 2008 at 5:46 PM, Brian McGinty wrote: > I don't know nothing about mxge so I can't comment, but I know that > FreeBSD ixgbe driver is not even close to that of the Linux version. I > switched to Linux just for ixgbe as our network was being standardized > on 10G, and I think that's the best bet. The Linux version of the > driver is actively worked on and I got a lot of help and bug fixes > from the maintainers of the driver, whereas the FreeBSD driver is > hopelessly neglected and broken. > > Brian > > On Tue, Oct 28, 2008 at 11:26 PM, Mihail Balikov > wrote: > > Hi, > > > > I would like to setup 10gbit bridge on FreeBSD7 , but I'm little bit > > confused which vendor to choose for the NICs. > > Can you send me some feed back? > > > > regards, > > Mihail Balikov > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Sun Nov 2 19:24:18 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 653ED1065670 for ; Sun, 2 Nov 2008 19:24:18 +0000 (UTC) (envelope-from karl.triebes@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by mx1.freebsd.org (Postfix) with ESMTP id E6EBF8FC0C for ; Sun, 2 Nov 2008 19:24:17 +0000 (UTC) (envelope-from karl.triebes@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so1802147fgb.35 for ; Sun, 02 Nov 2008 11:24:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=mdwaj9dzW4TbtFwg2Le/dq/mXdV6KzPcA4XIaQ22Ulk=; b=AMbkI8ydEo6bRSjY68lrBPhZngVDAi5+jYqaiZmi0iHv9JAhqna3v4HfSidC5HQWpU THZksML0OdCV36loxfovxsMVJ0nOAOFpHbU2Dh/MUkU/3/i+2bE86fsUKYMzGg4PMl/K D3yuHeA+Q9UxfFMxg8qeIvmGDnpV6qwCSXp9c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=x3vkpF0vpARQE9T1hF9tfRG3mKTobFI6zZ+GYX9a4JxGCOO5gHVOZ0N4ymy3CSJYCc Lwt4cKi0qByTBOX+Ps5s5UosEvCKpwrkj8uNU36jPyltT0Ee7s7H9KQqEDLMSrwkCKKb Vo7KkuhryU8mzc2iZiwT4Qba3DX7pcHoCHLOM= Received: by 10.86.3.4 with SMTP id 4mr10164706fgc.44.1225652022939; Sun, 02 Nov 2008 10:53:42 -0800 (PST) Received: by 10.86.49.9 with HTTP; Sun, 2 Nov 2008 10:53:42 -0800 (PST) Message-ID: <26a198490811021053u61d5a438tb03786868580ce51@mail.gmail.com> Date: Sun, 2 Nov 2008 10:53:42 -0800 From: "Karl Triebes" To: "Kip Macy" In-Reply-To: <3c1674c90811011818m6a6bfeb6o1973aed13813b845@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <499a3e640810282326p99e0d1eud93c7ecd310c8145@mail.gmail.com> <601bffc40811011746x5c684e3fs89e3019688a333ab@mail.gmail.com> <3c1674c90811011818m6a6bfeb6o1973aed13813b845@mail.gmail.com> Cc: freebsd-net@freebsd.org Subject: Re: ixgbe vs mxge 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: Sun, 02 Nov 2008 19:24:18 -0000 On Sat, Nov 1, 2008 at 5:18 PM, Kip Macy wrote: > As a point of reference for fellow readers: > > http://www.google.com/search?hl=en&q=brian.mcginty+freebsd&btnG=Google+Search&aq=f&oq= And your point is? From owner-freebsd-net@FreeBSD.ORG Sun Nov 2 19:31:25 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69503106564A for ; Sun, 2 Nov 2008 19:31:25 +0000 (UTC) (envelope-from karl.triebes@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by mx1.freebsd.org (Postfix) with ESMTP id 59B598FC1F for ; Sun, 2 Nov 2008 19:31:23 +0000 (UTC) (envelope-from karl.triebes@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so1804174fgb.35 for ; Sun, 02 Nov 2008 11:31:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=hdMQYRTzaUJ4ycw7qxfNPUpKrZSGWUGCkZEiGu60QYA=; b=tQf1C2Tw+a7kf7HVwwAvqt0EgDFHcQdMuPPAnGRZerNSdpee98LmvxZnh/SD/E/lPe 6GpqdJDpnsyOwWfio+3DuArP6gG70zCxEbcAcjq2fa6LzDc5710Fucb4zibnOezwNYrk lFmKBden2rsHvwNOqLLkM2BN6lPPqNTNHfWWQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=sjjzTQfG1/ZHRVG5dUr8GucHy8PVkpNMJLskU+muinJ80C1fSjV9BqnAOGsPPQ2Xwi kjrSmkzBBE4Kz+CoWfkn4evaI55Fb58CniHzOtP1ezPKofZDoBR1ZzY389cLtozsLF3l UqqF/Y9OG38e8cLrrfkAqltUxGUtXX8JoE1ho= Received: by 10.86.76.16 with SMTP id y16mr10271869fga.17.1225652440906; Sun, 02 Nov 2008 11:00:40 -0800 (PST) Received: by 10.86.49.9 with HTTP; Sun, 2 Nov 2008 11:00:40 -0800 (PST) Message-ID: <26a198490811021100y247296cen92dc290a9d60ce03@mail.gmail.com> Date: Sun, 2 Nov 2008 11:00:40 -0800 From: "Karl Triebes" To: "Jack Vogel" In-Reply-To: <2a41acea0811021034x45b86de1q43ef867333dfbd20@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <499a3e640810282326p99e0d1eud93c7ecd310c8145@mail.gmail.com> <601bffc40811011746x5c684e3fs89e3019688a333ab@mail.gmail.com> <2a41acea0811021034x45b86de1q43ef867333dfbd20@mail.gmail.com> Cc: Brian McGinty , Mihail Balikov , freebsd-net@freebsd.org Subject: Re: ixgbe vs mxge 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: Sun, 02 Nov 2008 19:31:25 -0000 Jack, On Sun, Nov 2, 2008 at 10:34 AM, Jack Vogel wrote: > You know I generally try to maintain courtesy and civility in my > dealings with the community but this really ticks me off. > > I have stayed out of this thread because I figured it was only > fair that those with obvious bias should do so. > > Hopelessly neglected and broken?? ...the driver is maintained by > me, and I am in the same organization as the developers of the > Linux driver. If anyone has real questions about my driver and > our hardware you may contact me. I didn't mean to offend you or your work in anyway, maybe ixgbe has turned around over the past few months. This is good news and hopefully you'll see wider adoption of ixgbe. Cheers, Brian From owner-freebsd-net@FreeBSD.ORG Sun Nov 2 22:38:05 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E9F4106568A for ; Sun, 2 Nov 2008 22:38:05 +0000 (UTC) (envelope-from jdp@elvis.rowan.edu) Received: from elvis.rowan.edu (elvis.rowan.edu [150.250.64.69]) by mx1.freebsd.org (Postfix) with ESMTP id 3796C8FC19 for ; Sun, 2 Nov 2008 22:38:04 +0000 (UTC) (envelope-from jdp@elvis.rowan.edu) Received: from elvis.rowan.edu (localhost [127.0.0.1]) by elvis.rowan.edu (8.13.8+Sun/8.13.8) with ESMTP id mA2Mc45p029869; Sun, 2 Nov 2008 17:38:04 -0500 (EST) Received: from localhost (jdp@localhost) by elvis.rowan.edu (8.13.8+Sun/8.13.8/Submit) with ESMTP id mA2Mc33J029865; Sun, 2 Nov 2008 17:38:03 -0500 (EST) Date: Sun, 2 Nov 2008 17:38:03 -0500 (EST) From: Joe Pellegrino To: Julian Elischer In-Reply-To: <490D0CFB.5040102@elischer.org> Message-ID: References: <490CEF11.4010007@elischer.org> <490D0CFB.5040102@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: A netgraph question. 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: Sun, 02 Nov 2008 22:38:05 -0000 On Sat, 1 Nov 2008, Julian Elischer wrote: > Joe Pellegrino wrote: >> On Sat, 1 Nov 2008, Julian Elischer wrote: >> > have you done man 3 netgraph to look at the netgraph management library? > Looked at that today and I might be able to get something going. I tried to use the ng_echo node in a module. The code looked something like this: #include #include #include #include #include #include #include #include extern struct ng_type typestruct; static int event_handler(struct module *module, int event, void *arg) { int e = 0; /* Error, 0 for normal return status */ switch (event) { case MOD_LOAD: uprintf("Hello Free Software Magazine Readers! \n"); ng_newtype(&typestruct); break; case MOD_UNLOAD: uprintf("Bye Bye FSM reader, be sure to check http://freesoftwar emagazine.com !\n"); break; default: e = EOPNOTSUPP; /* Error, Operation Not Supported */ break; } return(e); } /* The second argument of DECLARE_MODULE. */ static moduledata_t hello_conf = { "hello_fsm", /* module name */ event_handler, /* event handler */ NULL /* extra data */ }; DECLARE_MODULE(hello_fsm, hello_conf, SI_SUB_DRIVERS, SI_ORDER_MIDDLE); However, trying to load this module results in: # kldload ./hello_fsm.ko kldload: can't load ./hello_fsm.ko: No such file or directory So to start, how can I use ng_echo in a module? According to the man 4 of netgraph the ng_newtype should construct a new node right? And I presume once I get that module running and an ng_echo module loaded, I'll try to communicate with it from userspace but what about the above is incorrect? Thanks. :) ---jdp > for example programs, see: > /usr/src/usr.sbin/nghook > /usr/src/usr.sbin/ngctl > /usr/ports/net/mpd (you'll need to download the sources with "make") > > From owner-freebsd-net@FreeBSD.ORG Sun Nov 2 23:51:59 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17779106567C for ; Sun, 2 Nov 2008 23:51:59 +0000 (UTC) (envelope-from andrew@modulus.org) Received: from email.octopus.com.au (host-122-100-2-232.octopus.com.au [122.100.2.232]) by mx1.freebsd.org (Postfix) with ESMTP id CB7668FC21 for ; Sun, 2 Nov 2008 23:51:58 +0000 (UTC) (envelope-from andrew@modulus.org) Received: by email.octopus.com.au (Postfix, from userid 1002) id 3A35C17E8B; Mon, 3 Nov 2008 10:34:33 +1100 (EST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on email.octopus.com.au X-Spam-Level: X-Spam-Status: No, score=-1.3 required=10.0 tests=ALL_TRUSTED, DNS_FROM_SECURITYSAGE autolearn=no version=3.2.3 Received: from [10.20.30.101] (60.218.233.220.exetel.com.au [220.233.218.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: admin@email.octopus.com.au) by email.octopus.com.au (Postfix) with ESMTP id 189D417E59; Mon, 3 Nov 2008 10:34:29 +1100 (EST) Message-ID: <490E3900.2080508@modulus.org> Date: Mon, 03 Nov 2008 10:34:24 +1100 From: Andrew Snow User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Jack Vogel References: <499a3e640810282326p99e0d1eud93c7ecd310c8145@mail.gmail.com> <601bffc40811011746x5c684e3fs89e3019688a333ab@mail.gmail.com> <2a41acea0811021034x45b86de1q43ef867333dfbd20@mail.gmail.com> In-Reply-To: <2a41acea0811021034x45b86de1q43ef867333dfbd20@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: ixgbe vs mxge 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: Sun, 02 Nov 2008 23:51:59 -0000 Jack Vogel wrote: > Hopelessly neglected and broken?? ...the driver is maintained by > me, and I am in the same organization as the developers of the > Linux driver. Hi Jack, Of course, most people in the community use the fruit of your labours on a daily basis and are pleased with the results. I have deployed many Pro/1000 cards at home and work using the em driver with great success, and I thank you again for your efforts in improving the state of the FreeBSD driver. I am curious about the ixgbe driver as I have never had a chance to play with any 10G hardware: is it as fast and reliable as the em-based 1G solution? - Andrew From owner-freebsd-net@FreeBSD.ORG Mon Nov 3 04:01:12 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B59791065673 for ; Mon, 3 Nov 2008 04:01:12 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by mx1.freebsd.org (Postfix) with ESMTP id 7D74D8FC16 for ; Mon, 3 Nov 2008 04:01:12 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so2188229rvf.43 for ; Sun, 02 Nov 2008 20:01:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=TWuGKPWepn5JNv6rVGA5GBdfcT0Gxf9mPxpeSKAmXX8=; b=Oq38UC8Rb3uRI8dws1D1JXrcEU+iaQfEQrToi6P3LGrCxHKos9EQtjeRmpNMSksCH9 JVKO8OiRZ/TLMQypE/0lEcr9aUuKtthHzrwWRuV2mtNmxa82k6XBM7IAYXzB9c+9iVib pxBBj7/QOdQsjkYxqLbGcTpqlU8nkxnhBjZ9E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=cUr0b7kqmE2R3rxAArCp78105ZzvXE8Vrxxbd8rnxWxg6+bTrKLJ/Ab1GXEEW4tpgz sFApkxB3jx4DHi6jBEPUzR4BOuKR8wHhbFiLdhPGOSlnrE4sv3BWROWyjOWmczblRhtP H/FO7Dfcpwfr42mmpWixJG2jQr53jCXwCdEfU= Received: by 10.140.226.13 with SMTP id y13mr8646920rvg.2.1225684872033; Sun, 02 Nov 2008 20:01:12 -0800 (PST) Received: from michelle.cdnetworks.co.kr ([211.53.35.84]) by mx.google.com with ESMTPS id f21sm19212630rvb.5.2008.11.02.20.01.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 02 Nov 2008 20:01:10 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id mA33xA8g094976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Nov 2008 12:59:10 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id mA33x8Hs094975; Mon, 3 Nov 2008 12:59:08 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Mon, 3 Nov 2008 12:59:08 +0900 From: Pyun YongHyeon To: Milan Obuch Message-ID: <20081103035908.GC94302@cdnetworks.co.kr> References: <200810300829.35980.freebsd-net@dino.sk> <200810302241.01863.freebsd-net@dino.sk> <20081031011125.GC82781@cdnetworks.co.kr> <200810311029.56471.freebsd-net@dino.sk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200810311029.56471.freebsd-net@dino.sk> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: re weird bug X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2008 04:01:12 -0000 On Fri, Oct 31, 2008 at 10:29:55AM +0100, Milan Obuch wrote: > On Friday 31 October 2008 02:11:25 Pyun YongHyeon wrote: > > On Thu, Oct 30, 2008 at 10:41:01PM +0100, Milan Obuch wrote: > > > On Thursday 30 October 2008 11:26:56 Pyun YongHyeon wrote: > > > > On Thu, Oct 30, 2008 at 08:29:35AM +0100, Milan Obuch wrote: > > > > > Hi, > > > > > yesterday I csup'ped my 8-current sources on my MSI Wind netbook > > > > > (again) and tried to build new kernel. There is again a problem > > > > > with re interface. It just does not work, with following > > > > > > > > > > re0: port > > > > > 0xc000-0xc0ff mem 0xffd10000-0xffd10fff,0xffd00000-0xffd0ffff irq > > > > > 16 at device 0.0 on pci1 re0: Chip rev. 0x34800000 > > > > > re0: MAC rev. 0x00200000 > > > > > re0: PHY write failed > > > > > re0: PHY write failed > > > > > re0: MII without any phy! > > > > > device_attach: re0 attach returned 6 > > > > > > > [ snip ] > > > > > > > > > That's known issue for newer RealTek PCIe controllers. Would you > > > > please try the patch at the following URL? > > > > http://people.freebsd.org/~yongari/re/re.ephy.patch.20081021 > > > > > > > > Since it's not easy to reproduce this issue please make sure to > > > > (cold and warm) reboot several times until you can put confidence > > > > in the patch. > > > > > > I tried, but no change - with patch applied re still does not work > > > unless I boot with verbose logging, no matter whether I boot cold or > > > warm. > > > > Thanks for testing. If you look into patched if_re.c you can see a > > "#if 1" in function re_ephy_config(). How about changing it to > > "#if 0" to enable more aggresive reprogramming for EPHY register? > > I tried. Again, no change - rlphy not working normally, but everything works > when booting with verbose logging. > Hmm, I have no idea how verbosed booting can hide the issue. > If there is anything else I could test, let me know. Booting with verbose > logging is acceptable for me for now, so do not feel any pressure from my > side. I just like to test when something will be available for test. > I vaguely guess hardware was not properly initialized. How about this one? http://people.freebsd.org/~yongari/re/re.phy.patch.20081103 -- Regards, Pyun YongHyeon From owner-freebsd-net@FreeBSD.ORG Mon Nov 3 11:06:56 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC997106567E for ; Mon, 3 Nov 2008 11:06:56 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A9F438FC18 for ; Mon, 3 Nov 2008 11:06:56 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mA3B6uYU010980 for ; Mon, 3 Nov 2008 11:06:56 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mA3B6u75010976 for freebsd-net@FreeBSD.org; Mon, 3 Nov 2008 11:06:56 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 3 Nov 2008 11:06:56 GMT Message-Id: <200811031106.mA3B6u75010976@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org 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: Mon, 03 Nov 2008 11:06:56 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o kern/128181 net [fxp] panic in fxp_add_rfabuf o conf/128030 net [request] Isn't it time to enable IPsec in GENERIC? o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net [ixgbe] [patch] wrong error counting o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net arp: Segmentation fault (core dumped) s kern/127587 net [bge] [request] if_bge(4) doesn't support BCM576X fami f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126984 net [carp][patch] add carp userland notifications via devc o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126924 net [an] [patch] printf -> device_printf and simplify prob o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o bin/126822 net wpa_supplicant(8): WPA PSK does not work in adhoc mode o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and f kern/126564 net [ath] doesn't work with my PCI-E X1 wireless network a o kern/126561 net [nlm] [patch] NLM (rpclockd) RPC UNLOCK failure (stall o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126469 net [fxp] [panic] fxp(4) related kernel panic o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [in] Network: internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre f kern/125195 net [fxp] fxp(4) driver failed to initialize device Intel o kern/125079 net [ppp] host routes added by ppp with gateway flag (regr o kern/124904 net [fxp] EEPROM corruption with Compaq NC3163 NIC o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124609 net [ipsec] [panic] ipsec 'remainder too big' panic with p o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123881 net [tcp] Turning on TCP blackholing causes slow localhost o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123200 net [netgraph] Server failure due to netgraph mpd and dhcp f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/123066 net [ipsec] [panic] kernel trap with ipsec o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122839 net [multicast] FreeBSD 7 multicast routing problem p kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122427 net [apm] [panic] apm and mDNSResponder cause panic during o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122195 net [ed] Alignment problems in if_ed o kern/122068 net [ppp] ppp can not set the correct interface with pptpd o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o kern/121983 net [fxp] fxp0 MBUF and PAE o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] LOR icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [PATCH] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [panic] gnugk causes kernel panic when closing UDP soc o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119361 net [bge] bge(4) transmit performance problem o kern/119345 net [ath] Unsuported Atheros 5424/2424 and CPU speedstep n o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o kern/118880 net [ip6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116328 net [bge]: Solid hang with bge interface o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/116077 net [ip] [patch] 6.2-STABLE panic during use of multi-cast o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/113842 net [ip6] PF_INET6 proto domain state can't be cleared wit o kern/112722 net [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear o kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo f kern/92552 net A serious bug in most network drivers from 5.X to 6.X o kern/92090 net [bge] bge0: watchdog timeout -- resetting s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 s kern/60293 net FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [PATCH] for static ARP tables in rc.network 187 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Nov 3 16:19:02 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 460FB1065677 for ; Mon, 3 Nov 2008 16:19:02 +0000 (UTC) (envelope-from jjfitzgerald@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id EF02F8FC18 for ; Mon, 3 Nov 2008 16:19:01 +0000 (UTC) (envelope-from jjfitzgerald@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so936312yxb.13 for ; Mon, 03 Nov 2008 08:19:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=zhwKmjX/1CttPjOp8QcGXns3IjBzLSvVyOZplDsuz9c=; b=rWzadx98lMIIL5vS9ZMTL+I96FGNMGqk/gKfARrMlXSgt66waBu2+khQ1x81pfkJEr XSVz0SHY0AYLUdawLAhyzA1ostQnZpFMQuZTOiWasozD1qcG3v1h1eeQo8jMFtjciBdF pZTYIV6U8fgj4g8ahdpQvH+h7TslCx5wCJOSk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=AH9HW7njYQPwQ/46NN3gAn4d9VKaSn2p3H7zFmOJBTnAkqXvx1xbVn0Hc8Q++JhtQ6 qhmwpVweF18wtPpNnOsA+Wkn9+dGFA9pIeCqIrxvv6vKcNFXB217Z3r9qaAcCBNLcDX5 lCHKo50Wvqx/NRpdXpYUwr2KeH46Yi2JY8nWY= Received: by 10.151.111.15 with SMTP id o15mr490967ybm.205.1225727517096; Mon, 03 Nov 2008 07:51:57 -0800 (PST) Received: by 10.151.27.10 with HTTP; Mon, 3 Nov 2008 07:51:57 -0800 (PST) Message-ID: <5e49673f0811030751i292a80f4pf9ed6300ec46a504@mail.gmail.com> Date: Mon, 3 Nov 2008 10:51:57 -0500 From: "John Fitzgerald" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: ipf / ipnat bad nat 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: Mon, 03 Nov 2008 16:19:02 -0000 Hey all, I manage a pretty busy website and I've been perplexed by this problem for some time. ipnat -s shows something like this: mapped in 837904779 out 1055985985 added 79997334 expired 0 no memory 0 bad nat 500334 inuse 11764 rules 5 wilds 0 What troubles me is the "bad nat" that you see there. It goes up pretty quickly (hundreds per minute), especially during high traffic times. My ipnat.rules is pretty simple: #outgoing map bce0 192.168.1.0/24 -> 0.0.0.0/32 portmap tcp/udp auto map bce0 192.168.1.0/24 -> 0.0.0.0/32 #incoming rdr bce0 0.0.0.0/0 port 80 -> 192.168.1.100 port 80 tcp age 30 rdr bce0 0.0.0.0/0 port 443 -> 192.168.1.100 port 443 tcp age 30 And my ipf.rules is simple enough: # localhost pass in quick on lo0 all pass out quick on lo0 all #internal interface pass in quick on bce3 all pass out quick on bce3 all #web traffic pass in quick on bce0 proto tcp from any to any port = 80 flags S/SA keep state pass in quick on bce0 proto tcp from any to any port = 443 flags S/SA keep state #all outgoing pass out quick proto tcp from any to any flags S/SA keep state pass out quick proto icmp from any to any keep state pass out quick proto udp from any to any keep state #block the rest block in quick on bce0 all My internal interface is bce3 and external is bce0. Any thoughts what could be causing the bad nat? Thanks -- From owner-freebsd-net@FreeBSD.ORG Mon Nov 3 18:46:07 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B86A10657BE for ; Mon, 3 Nov 2008 18:46:06 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from proxy.meer.net (proxy.meer.net [64.13.141.13]) by mx1.freebsd.org (Postfix) with ESMTP id 309CF8FC2A for ; Mon, 3 Nov 2008 18:46:06 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [64.13.141.3]) by proxy.meer.net (8.14.2/8.14.2) with ESMTP id mA3IK0L6096835; Mon, 3 Nov 2008 10:20:03 -0800 (PST) (envelope-from gnn@neville-neil.com) Received: from mail2.meer.net (mail2.meer.net [64.13.141.16]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id mA3IJouJ061771; Mon, 3 Nov 2008 10:19:52 -0800 (PST) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (209.249.190.254.available.above.net [209.249.190.254] (may be forged)) (authenticated bits=0) by mail2.meer.net (8.14.1/8.14.1) with ESMTP id mA3IJnwd087576; Mon, 3 Nov 2008 10:19:50 -0800 (PST) (envelope-from gnn@neville-neil.com) Date: Mon, 03 Nov 2008 13:19:49 -0500 Message-ID: From: "George V. Neville-Neil" To: "Jack Vogel" In-Reply-To: <2a41acea0811021034x45b86de1q43ef867333dfbd20@mail.gmail.com> References: <499a3e640810282326p99e0d1eud93c7ecd310c8145@mail.gmail.com> <601bffc40811011746x5c684e3fs89e3019688a333ab@mail.gmail.com> <2a41acea0811021034x45b86de1q43ef867333dfbd20@mail.gmail.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.3 (i386-apple-darwin9.5.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Canit-CHI2: 0.50 X-Bayes-Prob: 0.5 (Score 0, tokens from: ) X-Spam-Score: 0.00 () [Tag at 5.00] X-CanItPRO-Stream: default X-Canit-Stats-ID: 2125173 - 1bc183f3b33d X-Scanned-By: CanIt (www . roaringpenguin . com) on 64.13.141.13 Cc: Brian McGinty , Mihail Balikov , freebsd-net@freebsd.org Subject: Re: ixgbe vs mxge 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: Mon, 03 Nov 2008 18:46:07 -0000 At Sun, 2 Nov 2008 10:34:18 -0800, Jack Vogel wrote: > > You know I generally try to maintain courtesy and civility in my > dealings with the community but this really ticks me off. And we appreciate both your work and your professionalism. > I have stayed out of this thread because I figured it was only > fair that those with obvious bias should do so. > > Hopelessly neglected and broken?? ...the driver is maintained by > me, and I am in the same organization as the developers of the > Linux driver. If anyone has real questions about my driver and > our hardware you may contact me. > I have every expectation that the 10G driver will be a fine piece of software, just like the igb and em before them. Best, George From owner-freebsd-net@FreeBSD.ORG Mon Nov 3 22:40:18 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8EACC1065675 for ; Mon, 3 Nov 2008 22:40:18 +0000 (UTC) (envelope-from freebsd-net@dino.sk) Received: from loki.netlab.sk (loki.netlab.sk [84.245.65.11]) by mx1.freebsd.org (Postfix) with ESMTP id 080298FC14 for ; Mon, 3 Nov 2008 22:40:17 +0000 (UTC) (envelope-from freebsd-net@dino.sk) Received: from via.dino.sk (home.dino.sk [84.245.95.252]) (AUTH: PLAIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by loki.netlab.sk with esmtp; Mon, 03 Nov 2008 23:40:00 +0100 id 0002E00F.490F7DC0.00016548 From: Milan Obuch To: freebsd-net@freebsd.org, pyunyh@gmail.com Date: Mon, 3 Nov 2008 23:39:06 +0100 User-Agent: KMail/1.9.10 References: <200810300829.35980.freebsd-net@dino.sk> <200810311029.56471.freebsd-net@dino.sk> <20081103035908.GC94302@cdnetworks.co.kr> In-Reply-To: <20081103035908.GC94302@cdnetworks.co.kr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200811032339.07412.freebsd-net@dino.sk> Cc: Subject: Re: re weird bug 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: Mon, 03 Nov 2008 22:40:18 -0000 On Monday 03 November 2008 04:59:08 Pyun YongHyeon wrote: [ snip ] > I vaguely guess hardware was not properly initialized. How about > this one? > http://people.freebsd.org/~yongari/re/re.phy.patch.20081103 This bug seems again to disappear - csup two days ago, kernel built with no patches and everything works. Something like this happened already in the past. No idea whether it has something with if_re being built as module, but if it happens again, I will test this possibility, too. Regards, Milan From owner-freebsd-net@FreeBSD.ORG Tue Nov 4 01:48:08 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 186A81065675 for ; Tue, 4 Nov 2008 01:48:08 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.249]) by mx1.freebsd.org (Postfix) with ESMTP id B46B28FC1E for ; Tue, 4 Nov 2008 01:48:07 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by an-out-0708.google.com with SMTP id b6so152556ana.13 for ; Mon, 03 Nov 2008 17:48:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=MqDVuviHRQWuRzB9FwTCsrn1qvXubGTdOeJK6d+U0TM=; b=fGKy5gAP9wR+unBAcGb+wGC4n6Ycl/IYL4KGLpxlkMUrh0Mg3z/x5e6fZVbHdnR4hT JqZv5OyTkvHj4/I61isa1VRy5aqOyNRgMSPQ2jNmju/7NmXsb3tv9Ocs6DFQUMs2VDE9 MuUnLM/R3bKkq2BaI6QYZghB/bhQE35pXRlng= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=p3qMmh3VZ9YYenK37+e1kLyGhDi0Pyoy378yftJ5voUMZCUDeMaCUE8ipG+li1rGPv 4yaYe0Hg0FTGNk5HWKjO689wnJxVgaZvzg7YVXbTaFVspjZ0PB8I0wG3cCh6v4Ed5tMt zyjzhMM/CRbdwu2CX6LKXbIyiF9TdieUFeQ3U= Received: by 10.101.69.6 with SMTP id w6mr360278ank.140.1225763287015; Mon, 03 Nov 2008 17:48:07 -0800 (PST) Received: from michelle.cdnetworks.co.kr ([211.53.35.84]) by mx.google.com with ESMTPS id b37sm332530ana.10.2008.11.03.17.48.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 03 Nov 2008 17:48:06 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id mA41k5B9098541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Nov 2008 10:46:05 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id mA41k4V4098540; Tue, 4 Nov 2008 10:46:04 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Tue, 4 Nov 2008 10:46:04 +0900 From: Pyun YongHyeon To: Milan Obuch Message-ID: <20081104014604.GB98154@cdnetworks.co.kr> References: <200810300829.35980.freebsd-net@dino.sk> <200810311029.56471.freebsd-net@dino.sk> <20081103035908.GC94302@cdnetworks.co.kr> <200811032339.07412.freebsd-net@dino.sk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200811032339.07412.freebsd-net@dino.sk> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: re weird bug X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2008 01:48:08 -0000 On Mon, Nov 03, 2008 at 11:39:06PM +0100, Milan Obuch wrote: > On Monday 03 November 2008 04:59:08 Pyun YongHyeon wrote: > > [ snip ] > > > I vaguely guess hardware was not properly initialized. How about > > this one? > > http://people.freebsd.org/~yongari/re/re.phy.patch.20081103 > > This bug seems again to disappear - csup two days ago, kernel built with no > patches and everything works. Something like this happened already in the Yeah, this is one of reason that makes it hard to fix. > past. No idea whether it has something with if_re being built as module, but > if it happens again, I will test this possibility, too. > Ok. Please let me know your findings. -- Regards, Pyun YongHyeon From owner-freebsd-net@FreeBSD.ORG Tue Nov 4 22:26:56 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71AD41065678 for ; Tue, 4 Nov 2008 22:26:56 +0000 (UTC) (envelope-from vova@sw.ru) Received: from relay.sw.ru (mailhub.sw.ru [195.214.232.25]) by mx1.freebsd.org (Postfix) with ESMTP id E49858FC20 for ; Tue, 4 Nov 2008 22:26:55 +0000 (UTC) (envelope-from vova@sw.ru) Received: from vbook.fbsd.ru ([77.232.23.6]) (authenticated bits=0) by relay.sw.ru (8.13.4/8.13.4) with ESMTP id mA4LjSdk018294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Nov 2008 00:45:29 +0300 (MSK) Received: from vova by vbook.fbsd.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KxTiK-000161-8y; Wed, 05 Nov 2008 00:45:28 +0300 From: Vladimir Grebenschikov To: freebsd-net Content-Type: multipart/mixed; boundary="=-1KSOd52xDRg62Eo4cAeQ" Date: Wed, 05 Nov 2008 00:45:27 +0300 Message-Id: <1225835127.3428.19.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov Cc: mav@freebsd.org Subject: net/mpd, net/mpd5 do not work on 8-CURRENT 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, 04 Nov 2008 22:26:56 -0000 --=-1KSOd52xDRg62Eo4cAeQ Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi These ports are still using set line discipline ioctl to configure ng_tty, but it is not work any more (with new ttys). src/modem.c: if (ioctl(m->fd, TIOCSETD, &ldisc) < 0) ... mpd log: [skylink] opening link "umodem0"... [umodem0] link: OPEN event [umodem0] LCP: Open event [umodem0] LCP: state change Initial --> Starting [umodem0] LCP: LayerStart [umodem0] device: OPEN event in state DOWN [umodem0] chat script succeeded [umodem0] ioctl(TIOCSETD, 6): Inappropriate ioctl for device [umodem0] device is now in state OPENING [umodem0] device: DOWN event in state OPENING [umodem0] device is now in state DOWN [umodem0] link: DOWN event [umodem0] LCP: Down event Appropriate commit log is attached. I've seen mav@'s comment on that commit, but no further actions. Any hope to make mpd work with recent 8-CURRENT ? -- Vladimir B. Grebenschikov vova@fbsd.ru --=-1KSOd52xDRg62Eo4cAeQ Content-Disposition: inline Content-Description: Attached message - cvs commit: src/share/man/man4 ng_tty.4 src/sys/netgraph ng_tty.c ng_tty.h Content-Type: message/rfc822 Return-path: Envelope-to: vova@fbsd.ru Delivery-date: Fri, 03 Oct 2008 09:26:50 +0400 Received: from mx2.freebsd.org ([69.147.83.53]) by fbsd.ru with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KldBi-0001Hk-F6 for vova@fbsd.ru; Fri, 03 Oct 2008 09:26:50 +0400 Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id D41E316185E; Fri, 3 Oct 2008 05:19:27 +0000 (UTC) (envelope-from owner-cvs-src@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id AC53010657A3; Fri, 3 Oct 2008 05:19:24 +0000 (UTC) (envelope-from owner-cvs-src@freebsd.org) Delivered-To: cvs-src@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA3F01065686; Fri, 3 Oct 2008 05:19:16 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from repoman.freebsd.org (repoman.freebsd.org [IPv6:2001:4f8:fff6::29]) by mx1.freebsd.org (Postfix) with ESMTP id A6B668FC13; Fri, 3 Oct 2008 05:19:16 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from repoman.freebsd.org (localhost [127.0.0.1]) by repoman.freebsd.org (8.14.3/8.14.3) with ESMTP id m935JGcx043025; Fri, 3 Oct 2008 05:19:16 GMT (envelope-from thompsa@repoman.freebsd.org) Received: (from svn2cvs@localhost) by repoman.freebsd.org (8.14.3/8.14.3/Submit) id m935JGwx043022; Fri, 3 Oct 2008 05:19:16 GMT (envelope-from thompsa@repoman.freebsd.org) Message-Id: <200810030519.m935JGwx043022@repoman.freebsd.org> X-Authentication-Warning: repoman.freebsd.org: svn2cvs set sender to thompsa@repoman.freebsd.org using -f From: Andrew Thompson Date: Fri, 3 Oct 2008 05:14:54 +0000 (UTC) To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org X-FreeBSD-CVS-Branch: HEAD Cc: Subject: cvs commit: src/share/man/man4 ng_tty.4 src/sys/netgraph ng_tty.c ng_tty.h X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: owner-cvs-src@freebsd.org Errors-To: owner-cvs-src@freebsd.org X-Evolution-Source: pop://vova@mx.fbsd.ru/ Mime-Version: 1.0 thompsa 2008-10-03 05:14:54 UTC FreeBSD src repository Modified files: share/man/man4 ng_tty.4 sys/netgraph ng_tty.c ng_tty.h Log: SVN rev 183562 on 2008-10-03 05:14:54Z by thompsa Update ng_tty for MPSAFE TTY. This changes from a line discipline to the tty_hooks mechanism. Data will come in directly via rint_bypass and sent to the peer node in a single mbuf. As line disciplines are no longer used a new netgraph command called NGM_TTY_SET_TTY is used to attach the tty. This takes a pointer to to the open file descriptor of the tty and registers the tty hooks. When the tty disappears the node will shutdown. Thanks to: ed Sponsored by: Hobnob, Inc Revision Changes Path 1.18 +16 -16 src/share/man/man4/ng_tty.4 1.38 +281 -454 src/sys/netgraph/ng_tty.c 1.5 +1 -0 src/sys/netgraph/ng_tty.h _______________________________________________ cvs-src@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-src To unsubscribe, send any mail to "cvs-src-unsubscribe@freebsd.org" --=-1KSOd52xDRg62Eo4cAeQ-- From owner-freebsd-net@FreeBSD.ORG Wed Nov 5 13:40:34 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C078106568B for ; Wed, 5 Nov 2008 13:40:34 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.181]) by mx1.freebsd.org (Postfix) with ESMTP id 18DB08FC14 for ; Wed, 5 Nov 2008 13:40:33 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by el-out-1112.google.com with SMTP id v27so1754139ele.13 for ; Wed, 05 Nov 2008 05:40:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=G07HkaoFhaQbqsX3AZq0aW/RkaxIRSQl92NyBDgR2FI=; b=TA/+pDXMt4KyhGsJYI3SAzKBtrdn/TmZqx9eMS53URWC7SFN32eN9ABQc3qnO4zXCa tuQPGMoKsWZm8tk1W6fbQ8O+OyD4bgtF+tz0vaiGGMbkHFchc58+B9JQDFecWLnm1sMk DLN+Sr23ar3w/L8IdGb6JWz+ktQNTQPHNuMGo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=AZtfkM+c+x1oQdPVaLX8eoCf17EUdpp+7BatrgqZRITJME5JswuBb5HucjKH3KL3dy Hbx8PooGcxNPKJ/2E4Gwfc8hTDjMyDZdemzorlJhHHR4pGX4BOY/YzknFue7fF1MtQZY AZ8bHIPdQ2gL+7/s3YS/2nQdu/bQ4FrEmxcE8= Received: by 10.90.99.3 with SMTP id w3mr646845agb.111.1225892432368; Wed, 05 Nov 2008 05:40:32 -0800 (PST) Received: by 10.90.81.10 with HTTP; Wed, 5 Nov 2008 05:40:32 -0800 (PST) Message-ID: Date: Wed, 5 Nov 2008 16:40:32 +0300 From: pluknet To: "FreeBSD Net" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: CARP performance tuning question. 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: Wed, 05 Nov 2008 13:40:34 -0000 Hi. AT work we use device carp(4) under high load: The problem is that the server experiences a bad interactivity (from 70k states and very bad from 120-150k) i.e. when a network workload (and interrupts count) begin to increase. >From top(1): CPU states: 0.0% user, 0.0% nice, 0.4% system, 76.3% interrupt, 23.3% idle PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND 13 root 1 -44 -163 0K 8K WAIT 407:43 57.86% swi1: net ATM pfctl -s info shows such numbers: State Table Total Rate current entries 153972 searches 6052078938 4800.8/s inserts 120373545 95.5/s removals 120219573 95.4/s It works currently under UP, but could be rebuilt to work under SMP (Xeon 5130) if that helps. Can someone give hints to decrease interrupt count and to help with the server stability at all? Thanks. -- wbr, pluknet From owner-freebsd-net@FreeBSD.ORG Wed Nov 5 13:50:56 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D7D910656B2 for ; Wed, 5 Nov 2008 13:50:56 +0000 (UTC) (envelope-from ivo.vachkov@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by mx1.freebsd.org (Postfix) with ESMTP id 2761E8FC27 for ; Wed, 5 Nov 2008 13:50:55 +0000 (UTC) (envelope-from ivo.vachkov@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so1340773ywe.13 for ; Wed, 05 Nov 2008 05:50:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=kmk0iowSn1PZLl7dNAxBwas7BLAImeQB7ismrxHDx04=; b=lqdLlSrvd+M1cF9VJJ4CuAiyKNhvpnQL+x59DoiwOrQ7cpzhsA1MNegUz7sUGmekds tCGxl31aKgOAmCNxWr7vKR8ZtK6FSHTxifeoayD1CxbBpjG/ud9YRjeHoXp+VODjt/Ef GJFTnZ0b8y6/0Qx02O4lKPhSuMVuzuLAvxnoA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=skBF7fMW10qaH2HCegbI26wgHarrtSNEc4vMQpSdsu3gQqnQYpLZSZMc8mYsecnztj MOz4Wz/svY0j9JnndB4crttp85zs5eJCTH77zcDX5v0J0W+ToAhumR9Frje6v/1miUOD 7DMXJrEQvWojnw3Z25VeUknlvGA94NY4Dwipk= Received: by 10.151.7.4 with SMTP id k4mr1656222ybi.185.1225891100009; Wed, 05 Nov 2008 05:18:20 -0800 (PST) Received: by 10.150.211.7 with HTTP; Wed, 5 Nov 2008 05:18:20 -0800 (PST) Message-ID: Date: Wed, 5 Nov 2008 15:18:20 +0200 From: "Ivo Vachkov" To: "FreeBSD Net" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Probably typo in netintro(4) manpage 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: Wed, 05 Nov 2008 13:50:56 -0000 Hello all, I'm using FreeBSD CURRENT (as of 04 Nov 2008) and while reading netintro(4) i found something i think is typo. Near the end of the INTERFACE section there is an example: ... /* * Structure used in SIOCAIFCONF request. */ struct ifaliasreq { char ifra_name[IFNAMSIZ]; /* if name, e.g. "en0" */ struct sockaddr ifra_addr; struct sockaddr ifra_broadaddr; struct sockaddr ifra_mask; }; ... I think the "SIOCAIFCONF" should be "SIOCAIFADDR". Reference: netintro(4), sys/sockio.h /ipv From owner-freebsd-net@FreeBSD.ORG Wed Nov 5 18:26:25 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C6871065672; Wed, 5 Nov 2008 18:26:25 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 32E438FC0A; Wed, 5 Nov 2008 18:26:25 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mA5IQPKs074017; Wed, 5 Nov 2008 18:26:25 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mA5IQPRF074013; Wed, 5 Nov 2008 18:26:25 GMT (envelope-from linimon) Date: Wed, 5 Nov 2008 18:26:25 GMT Message-Id: <200811051826.mA5IQPRF074013@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/128598: [bluetooth] WARNING: attempt to net_add_domain(bluetooth) after domainfinalize() 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: Wed, 05 Nov 2008 18:26:25 -0000 Old Synopsis: WARNING: attempt to net_add_domain(bluetooth) after domainfinalize() New Synopsis: [bluetooth] WARNING: attempt to net_add_domain(bluetooth) after domainfinalize() Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Nov 5 18:25:24 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=128598 From owner-freebsd-net@FreeBSD.ORG Wed Nov 5 18:27:46 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CEE90106567A; Wed, 5 Nov 2008 18:27:46 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A5CB18FC21; Wed, 5 Nov 2008 18:27:46 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mA5IRkph074098; Wed, 5 Nov 2008 18:27:46 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mA5IRkR2074094; Wed, 5 Nov 2008 18:27:46 GMT (envelope-from linimon) Date: Wed, 5 Nov 2008 18:27:46 GMT Message-Id: <200811051827.mA5IRkR2074094@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: bin/128602: [an] wpa_supplicant(8) crashes with an(4) 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: Wed, 05 Nov 2008 18:27:46 -0000 Old Synopsis: wpa_supplicant crashes with an(4) New Synopsis: [an] wpa_supplicant(8) crashes with an(4) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Nov 5 18:26:44 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=128602 From owner-freebsd-net@FreeBSD.ORG Wed Nov 5 18:48:10 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B89C1065688 for ; Wed, 5 Nov 2008 18:48:10 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id 7D1E88FC08 for ; Wed, 5 Nov 2008 18:48:09 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so85577yxb.13 for ; Wed, 05 Nov 2008 10:48:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=9g3D/zDStSEOcrj49V7M6OsqBK7BZnFBjtNcHLKAEUM=; b=IdDWRcJeub09hO2Fg6G6WQahI9m7h7tQrFWi+SbFOIXtaW4jzeMLNYUJUJPnDTvq5D bIaQMCOQgqzXqaIM472E39iQMy7ru80UixGpJt4a4+IpA77ri1e/2bF2B3dg8ixy6D/N wkj8V/84/XdTUzzVyuebS6hW+PX12+wcLVRpA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=BzEo3H1SUp4BJo0GYMVYa2UPNQxb2WiW3eizS9InJF38rls8UMQUYRfWBkiEZBn+xh a/Npbp8Gwpg6POFQ/+R3m6srdZ4IQrCt7b5TO4QjvAM8XJSZHi3KiPCzFrsjhIRMiena yOle4qDqIJTpkOUIVFHWg62EMq0NSRvIpZdYY= Received: by 10.90.83.18 with SMTP id g18mr954860agb.68.1225910888432; Wed, 05 Nov 2008 10:48:08 -0800 (PST) Received: by 10.90.81.10 with HTTP; Wed, 5 Nov 2008 10:48:08 -0800 (PST) Message-ID: Date: Wed, 5 Nov 2008 21:48:08 +0300 From: pluknet To: linimon@freebsd.org In-Reply-To: <200811051826.mA5IQPRF074013@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200811051826.mA5IQPRF074013@freefall.freebsd.org> Cc: freebsd-net@freebsd.org, freebsd-bugs@freebsd.org Subject: Re: kern/128598: [bluetooth] WARNING: attempt to net_add_domain(bluetooth) after domainfinalize() 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: Wed, 05 Nov 2008 18:48:10 -0000 2008/11/5 : > Old Synopsis: WARNING: attempt to net_add_domain(bluetooth) after domainfinalize() > New Synopsis: [bluetooth] WARNING: attempt to net_add_domain(bluetooth) after domainfinalize() > > Responsible-Changed-From-To: freebsd-bugs->freebsd-net > Responsible-Changed-By: linimon > Responsible-Changed-When: Wed Nov 5 18:25:24 UTC 2008 > Responsible-Changed-Why: > Over to maintainer(s). > > http://www.freebsd.org/cgi/query-pr.cgi?pr=128598 As far as I know you can safely ignore this warning. BTW it was introduced somewhere between 5.x and 6.x. -- wbr, pluknet From owner-freebsd-net@FreeBSD.ORG Wed Nov 5 23:06:40 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EC8D1065686; Wed, 5 Nov 2008 23:06:40 +0000 (UTC) (envelope-from jasonh@borisch.com) Received: from mail.borisch.com (mx1.borisch.com [209.255.13.26]) by mx1.freebsd.org (Postfix) with ESMTP id 02E528FC17; Wed, 5 Nov 2008 23:06:39 +0000 (UTC) (envelope-from jasonh@borisch.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from 192.168.200.7 ([192.168.200.7]) by exchange2k3.exchange.borisch.com ([192.168.0.232]) with Microsoft Exchange Server HTTP-DAV ; Wed, 5 Nov 2008 22:54:35 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook Web Access 6.5.7651.60 X-MimeCtl: Produced By Microsoft Exchange V6.5.7651.60 Content-class: urn:content-classes:message X-Mailer: Microsoft Outlook Web Access 6.5.7651.60 X-MimeCtl: Produced By Microsoft Exchange V6.5.7651.60 Date: Wed, 5 Nov 2008 17:54:34 -0500 Message-ID: <6AB9DD44-C91B-4F0D-8F5C-168C57D44911@mimectl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ath driver (Linksys WMP110 RangePlus) ar5416 thread-index: Ack/mXjL9OqrXpvCTuOxqBYPTTHW9Q== From: "Jason J. Hellenthal" To: , Cc: Subject: ath driver (Linksys WMP110 RangePlus) ar5416 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: Wed, 05 Nov 2008 23:06:40 -0000 Anyone know if the Linksys WMP110 RangePlus support will be added to = 7-stable. I would rather use a native driver for this card for more = features but the ndis driver seems to be working great for a couple of = weeks now with no flaw. =20 This is what the device reports in pciconf. ndis0@pci0:1:8:0: class=3D0x028000 card=3D0x00721737 chip=3D0x0023168c = rev=3D0x01 hdr=3D0x00 vendor =3D 'Atheros Communications Inc.' device =3D 'AR5008 Wireless Network Adapter' I have tried the ath module and it never picked up the card and I don't = have to much time to modify or look into this any more than I already = have. =20 The driver name from under windows is ar5416.sys. [from Linksys support = on cd/disc] =20 If additional information or resources is needed I will be more than = willing to provide whatever needed. =20 Thanks in advance... =20 -- J. Hellenthal (892) Aerospace Special Operations Support Borisch Manufacturing Corporation =20 http://www.Borisch.com/ jasonh@Borisch.com = =20 "... as we enjoy great advantages from the inventions of others, we = should be glad of an opportunity to serve others by any invention of = ours; and this we should do freely and generously." -- Benjamin Franklin =20 P Only print if necessary =20 From owner-freebsd-net@FreeBSD.ORG Thu Nov 6 09:18:28 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA0A5106567F for ; Thu, 6 Nov 2008 09:18:28 +0000 (UTC) (envelope-from jon.otterholm@ide.resurscentrum.se) Received: from mail1.cil.se (mail1.cil.se [217.197.56.125]) by mx1.freebsd.org (Postfix) with ESMTP id 7B9B28FC0C for ; Thu, 6 Nov 2008 09:18:28 +0000 (UTC) (envelope-from jon.otterholm@ide.resurscentrum.se) X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from 192.168.2.30 ([192.168.2.30]) by edusrv05.edu.irc.local ([192.168.44.14]) with Microsoft Exchange Server HTTP-DAV ; Thu, 6 Nov 2008 09:06:27 +0000 MIME-Version: 1.0 User-Agent: Microsoft-Entourage/12.13.0.080930 Content-class: urn:content-classes:message Date: Thu, 6 Nov 2008 10:06:21 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CARP and L2 src-MAC Thread-Index: Ack/7u+EiDuKCoXJOk2ol5ujoaesuA== From: "Jon Otterholm" To: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: CARP and L2 src-MAC 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: Thu, 06 Nov 2008 09:18:29 -0000 Hi. We have a situation where we want to use CARP in a TPSDA-network and got some problems.=20 The master CARP router ARP response contains the correct virtual MAC but uses the physical interface MAC in L2 header. This is OK for the client = but the switches in between the router and the client will not learn the = virtual MAC. This will work in a =B3normal=B2 switched network but will fail in = a TPSDA network where all L2 devices will not learn the virtual MAC. In this = case the network is built upon Alcatel iSAM FTTU and because all = CARP-messages is broadcast they will not learn the virtual MAC. Is it possible to tweak CARP to use the virtual MAC in L2 header instead = of the physical interface MAC? Could this be implemented as a feature controlled by a sysctl? //Jon From owner-freebsd-net@FreeBSD.ORG Thu Nov 6 10:53:46 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65BB410657A1 for ; Thu, 6 Nov 2008 10:53:46 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from fallbackmx10.syd.optusnet.com.au (fallbackmx10.syd.optusnet.com.au [211.29.132.251]) by mx1.freebsd.org (Postfix) with ESMTP id EA1748FC0C for ; Thu, 6 Nov 2008 10:53:45 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail36.syd.optusnet.com.au (mail36.syd.optusnet.com.au [211.29.133.76]) by fallbackmx10.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id mA6AhBJB028562 for ; Thu, 6 Nov 2008 21:43:11 +1100 Received: from server.vk2pj.dyndns.org (c122-106-215-175.belrs3.nsw.optusnet.com.au [122.106.215.175]) by mail36.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id mA6Ah8MZ018156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Nov 2008 21:43:09 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id mA6Ah8oE054886; Thu, 6 Nov 2008 21:43:08 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id mA6Ah8SQ054885; Thu, 6 Nov 2008 21:43:08 +1100 (EST) (envelope-from peter) Date: Thu, 6 Nov 2008 21:43:07 +1100 From: Peter Jeremy To: pluknet Message-ID: <20081106104307.GC51239@server.vk2pj.dyndns.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/Uq4LBwYP4y1W6pO" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.18 (2008-05-17) Cc: FreeBSD Net Subject: Re: CARP performance tuning question. 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: Thu, 06 Nov 2008 10:53:46 -0000 --/Uq4LBwYP4y1W6pO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Whilst I don't doubt that you have a problem, your comments don't correlate particularly well with the data you have provided and this makes it difficult to immediately suggest a solution. On 2008-Nov-05 16:40:32 +0300, pluknet wrote: >AT work we use device carp(4) under high load: carp(4) is solely a failover mechanism. It either generates or receives somewhat under 1pps per carp interface and the state it maintains is basically 'master' or 'backup'. I suspect the 'load' is being caused by pf(4), possibly in conjunction with pfsync(4). >The problem is that the server experiences a bad interactivity (from >70k states and very bad from 120-150k) >i.e. when a network workload (and interrupts count) begin to increase. > >>From top(1): >CPU states: 0.0% user, 0.0% nice, 0.4% system, 76.3% interrupt, 23.3% i= dle > PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMM= AND > 13 root 1 -44 -163 0K 8K WAIT 407:43 57.86% swi1:= net I agree that swi1 is using a significant amount of CPU but top is still reporting >23% idle so you shouldn't be getting poor interactive performance. >ATM pfctl -s info shows such numbers: > >State Table Total Rate > current entries 153972 > searches 6052078938 4800.8/s > inserts 120373545 95.5/s > removals 120219573 95.4/s That shows the load on pf(4) but doesn't really reflect what the system is doing as a whole. >It works currently under UP, but could be rebuilt to work under SMP >(Xeon 5130) if that helps. Unfortunately, I don't know if this will help or not because I'm not sure what bottleneck you are hitting. >Can someone give hints to decrease interrupt count and to help with >the server stability at all? Well, you haven't actually reported what the interrupt count or what instability you are seeing so this is a bit difficult. Can you please provide some more information: - output from 'uname -a' - output from 'vmstat -i; sleep 10; vmstat -i' under load - output from 'netstat -i' - 10-15 seconds of output from 'netstat -i 1' under load - What is the box doing? Is it a straight filtering router? Does it handle NAT? Is it running apps itself (eg web, ftp, mail)? - What speed are the interface(s) running at? - What instability problems are you seeing? - Please provide more details on what you mean by 'bad interactivity'. - How complex is your pf ruleset? How many rules? Anything unusual? - What scheduler are you using? - What is the full output of 'pfctl -s info'? --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --/Uq4LBwYP4y1W6pO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkkSyjsACgkQ/opHv/APuIdoiQCgsTHYbDRYx+VnitKkbpy1OsmJ TEoAn0ZxKbz0Hy2BRiBTbVjzjEVVJD6G =Ef3M -----END PGP SIGNATURE----- --/Uq4LBwYP4y1W6pO-- From owner-freebsd-net@FreeBSD.ORG Thu Nov 6 12:30:51 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91B9C106564A for ; Thu, 6 Nov 2008 12:30:51 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.181]) by mx1.freebsd.org (Postfix) with ESMTP id 48EFF8FC26 for ; Thu, 6 Nov 2008 12:30:50 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by el-out-1112.google.com with SMTP id v27so282242ele.13 for ; Thu, 06 Nov 2008 04:30:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=Kqw75D/i7wEk8GRFxDs3owldEFdr53J6sIm+yLVyNSY=; b=owJDRG5tmU7hjCsxKEBxALB/+4rQ2lDSrzRPcj4aEXtHDgNfUk24vd/4hQz/0b/MX7 IwxkVoGZeR177Tfp9sBfaRl6RujCgQ5KqlRJQ81/HhMr72klvtG6R8CZjdHBqVOExCyz /Ls5NEJ5rSbJ1x3Hfu2wdo2D++9h2sWnXhpRg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=pMsMbnwDP5qD77eQUn/7F2YZnL1Qh9UVfg8UCOChxhujnkROrgyUC6mZ5UAhT6hyjj erSUyw5jklbthFvPKM0uhJuRUNAB2OCzD0LoGZvcwoOQJhLfZkHaxoICJZeePtcU3VMt hXghraHjTWKSkPzNAodr9n0eRQhOcGV0s14+k= Received: by 10.90.31.8 with SMTP id e8mr1772192age.37.1225974649704; Thu, 06 Nov 2008 04:30:49 -0800 (PST) Received: by 10.90.81.10 with HTTP; Thu, 6 Nov 2008 04:30:49 -0800 (PST) Message-ID: Date: Thu, 6 Nov 2008 15:30:49 +0300 From: pluknet To: "Peter Jeremy" In-Reply-To: <20081106104307.GC51239@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20081106104307.GC51239@server.vk2pj.dyndns.org> Cc: FreeBSD Net Subject: Re: CARP performance tuning question. 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: Thu, 06 Nov 2008 12:30:51 -0000 2008/11/6 Peter Jeremy : > Whilst I don't doubt that you have a problem, your comments don't > correlate particularly well with the data you have provided and > this makes it difficult to immediately suggest a solution. > > On 2008-Nov-05 16:40:32 +0300, pluknet wrote: >>AT work we use device carp(4) under high load: > > carp(4) is solely a failover mechanism. It either generates or receives > somewhat under 1pps per carp interface and the state it maintains is > basically 'master' or 'backup'. I suspect the 'load' is being caused > by pf(4), possibly in conjunction with pfsync(4). > >>The problem is that the server experiences a bad interactivity (from >>70k states and very bad from 120-150k) >>i.e. when a network workload (and interrupts count) begin to increase. >> >>>From top(1): >>CPU states: 0.0% user, 0.0% nice, 0.4% system, 76.3% interrupt, 23.3% idle >> PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND >> 13 root 1 -44 -163 0K 8K WAIT 407:43 57.86% swi1: net > > I agree that swi1 is using a significant amount of CPU but top is > still reporting >23% idle so you shouldn't be getting poor interactive > performance. > >>ATM pfctl -s info shows such numbers: >> >>State Table Total Rate >> current entries 153972 >> searches 6052078938 4800.8/s >> inserts 120373545 95.5/s >> removals 120219573 95.4/s > > That shows the load on pf(4) but doesn't really reflect what the > system is doing as a whole. > >>It works currently under UP, but could be rebuilt to work under SMP >>(Xeon 5130) if that helps. > > Unfortunately, I don't know if this will help or not because I'm not > sure what bottleneck you are hitting. > >>Can someone give hints to decrease interrupt count and to help with >>the server stability at all? > > Well, you haven't actually reported what the interrupt count or > what instability you are seeing so this is a bit difficult. > > Can you please provide some more information: > - output from 'uname -a' > - output from 'vmstat -i; sleep 10; vmstat -i' under load > - output from 'netstat -i' > - 10-15 seconds of output from 'netstat -i 1' under load > - What is the box doing? Is it a straight filtering router? Does it > handle NAT? Is it running apps itself (eg web, ftp, mail)? > - What speed are the interface(s) running at? > - What instability problems are you seeing? > - Please provide more details on what you mean by 'bad interactivity'. > - How complex is your pf ruleset? How many rules? Anything unusual? > - What scheduler are you using? > - What is the full output of 'pfctl -s info'? > Thanks for your answer and, please, ignore this premature mail. It would need a bit more analysis. -- wbr, pluknet From owner-freebsd-net@FreeBSD.ORG Thu Nov 6 13:18:42 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BBB2B1065688 for ; Thu, 6 Nov 2008 13:18:42 +0000 (UTC) (envelope-from jon.otterholm@ide.resurscentrum.se) Received: from mail1.cil.se (mail1.cil.se [217.197.56.125]) by mx1.freebsd.org (Postfix) with ESMTP id 50B8E8FC17 for ; Thu, 6 Nov 2008 13:18:42 +0000 (UTC) (envelope-from jon.otterholm@ide.resurscentrum.se) Received: from 192.168.2.30 ([192.168.2.30]) by edusrv05.edu.irc.local ([192.168.44.14]) with Microsoft Exchange Server HTTP-DAV ; Thu, 6 Nov 2008 13:18:45 +0000 User-Agent: Microsoft-Entourage/12.13.0.080930 Date: Thu, 06 Nov 2008 14:18:40 +0100 From: Jon Otterholm To: "freebsd-net@freebsd.org" Message-ID: Thread-Topic: CARP and L2 src-MAC Thread-Index: AclAEi8Q5WpAyAHMnkeQ3QaTC+Kn1w== In-Reply-To: <20081106104718.GD51239@server.vk2pj.dyndns.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: CARP and L2 src-MAC 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: Thu, 06 Nov 2008 13:18:42 -0000 On 2008-11-06 11.47, "Peter Jeremy" wrote: > On 2008-Nov-06 10:06:21 +0100, Jon Otterholm > wrote: >> Is it possible to tweak CARP to use the virtual MAC in L2 header instead of >> the physical interface MAC? Could this be implemented as a feature >> controlled by a sysctl? > > In my testing, Max Laier's carpdep patches do this. See > http://lists.freebsd.org/pipermail/freebsd-net/2008-March/017103.html Can we find this in HEAD? //Jon From owner-freebsd-net@FreeBSD.ORG Thu Nov 6 16:00:24 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EDCB106575C for ; Thu, 6 Nov 2008 16:00:18 +0000 (UTC) (envelope-from ivo.vachkov@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by mx1.freebsd.org (Postfix) with ESMTP id 57EB78FC13 for ; Thu, 6 Nov 2008 16:00:09 +0000 (UTC) (envelope-from ivo.vachkov@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so268081yxb.13 for ; Thu, 06 Nov 2008 08:00:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=DVL0M5ZbGIFtKES/vndfP+yuR8RyrpPsRkcbTMMBqzU=; b=t7FXW3WM/4ddGbih5Qm3KdkkeujTnr++GtmcooJKY4pxGYWeKw5AsgB3iGKN1/vZWq GBagbgyJUbxBAS0AmORMQnT9pDNa1YYjZaIDwJh2rpQyDM+2omlEql9ghTC4QofqHeq2 0QgxMJ56rklcDIpbpCTgZs5kwD3b5TQ+T+AO8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=nJuKYFK4XQJgARZ9/Er/2xk863TjRvZPOF4SoVN17eE0UL86IVYCuzdS9uXoD4vawy XhCf/FsidOxHB5ceOmVw9ak1jkgkEaL/9Os8gPBL4T2rQKHucZoYAVgOJ0gKM+ZAxv6P 3OxfX8NG+WpBd1GFsJ0zAA+TozyGz3iU+e8sg= Received: by 10.151.114.6 with SMTP id r6mr1612697ybm.62.1225986606373; Thu, 06 Nov 2008 07:50:06 -0800 (PST) Received: by 10.150.211.7 with HTTP; Thu, 6 Nov 2008 07:50:06 -0800 (PST) Message-ID: Date: Thu, 6 Nov 2008 17:50:06 +0200 From: "Ivo Vachkov" To: "FreeBSD Net" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: BPF question 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: Thu, 06 Nov 2008 16:00:24 -0000 Hello all, I am using simple write() calls to send packets over BPF file descriptor. The BPF file descriptor is in buffered read mode (I assume this is the default and I do not set it explicitly). From what I see my write() calls are somewhat buffered. Since timing is relatively important for my project I'd like to ask if there is a way "flush" the write buffer. Setting O_DIRECT flag on the file descriptor doesn't seem to have any effect. /ipv -- "UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity." Dennis Ritchie From owner-freebsd-net@FreeBSD.ORG Thu Nov 6 16:15:17 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E3B41065679; Thu, 6 Nov 2008 16:15:17 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id BD0B88FC18; Thu, 6 Nov 2008 16:15:16 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 3A33941C752; Thu, 6 Nov 2008 17:00:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id nrF-sonKpvdY; Thu, 6 Nov 2008 17:00:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id ADA7541C751; Thu, 6 Nov 2008 17:00:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 2FC80444888; Thu, 6 Nov 2008 15:58:58 +0000 (UTC) Date: Thu, 6 Nov 2008 15:58:58 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: FreeBSD current mailing list Message-ID: <20081106153035.R16105@maildrop.int.zabbadoz.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: src-committers@freebsd.org, FreeBSD net mailing list Subject: Kernel without INET X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: FreeBSD net mailing list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2008 16:15:17 -0000 Hi, some might have wondered about lots of small commits I have done the last two days. I had been trying to compile a kernel without any networking a few weeks ago and that failed; I had needed to add (I think it was) INET, ether and loop. So I had been trying to get rid of that requirement the last days. As a partial victory it seems to be possible again to build a kernel without any networking now. I'll have to check with my original setup but I have a stripped down LINT file I tested with. Obviously the long term goal is to be able to build a kernel without INET support (again?). As an intermediate step that will mean without INET and INET6 and once that works and IPX only would compile *cough*, then work on a (LINT) kernel with nooption INET. It'll be a long long way to go and this is nothing to finish within a week or two. Do not think about doing a quick sweep over the rest of the tree. You would wonder what depends on INET these days. I have more patches mailed out or pending here. While we had been trying to make it possible to build without INET6 most of the time, someone doing review on my code told me that if compaining about 'kernel needs INET' I should put some code under #ifdef INET. I did. The bottom line is that I now ask you to consider this for all new code as well. I am very well aware that some code, as is, would already require a maze of #ifdefs (I have a sample of that) so we need to be careful and apply the checks sensibly. Regards, Bjoern PS: please obey Reply-To: -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From owner-freebsd-net@FreeBSD.ORG Thu Nov 6 17:06:38 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38B651065686 for ; Thu, 6 Nov 2008 17:06:38 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 157908FC17 for ; Thu, 6 Nov 2008 17:06:38 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTP id 9932146B03; Thu, 6 Nov 2008 12:06:37 -0500 (EST) Date: Thu, 6 Nov 2008 17:06:37 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Ivo Vachkov In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Net Subject: Re: BPF question 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: Thu, 06 Nov 2008 17:06:38 -0000 On Thu, 6 Nov 2008, Ivo Vachkov wrote: > I am using simple write() calls to send packets over BPF file descriptor. > The BPF file descriptor is in buffered read mode (I assume this is the > default and I do not set it explicitly). From what I see my write() calls > are somewhat buffered. Since timing is relatively important for my project > I'd like to ask if there is a way "flush" the write buffer. Setting O_DIRECT > flag on the file descriptor doesn't seem to have any effect. The write(2) system call does no buffering in userspace (unlike, say, fwrite(3)), and when you write to a BPF device it essentially goes straight into the network interface output queue, so there should be no need for a flush mechanism. Could you describe the buffering effect you're seeing a bit more? Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Thu Nov 6 17:54:14 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC6A5106564A for ; Thu, 6 Nov 2008 17:54:14 +0000 (UTC) (envelope-from ivo.vachkov@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by mx1.freebsd.org (Postfix) with ESMTP id 6BCB88FC0C for ; Thu, 6 Nov 2008 17:54:14 +0000 (UTC) (envelope-from ivo.vachkov@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so298522ywe.13 for ; Thu, 06 Nov 2008 09:54:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=sbov47NFBC+mLEE8jPqU9r/BkZEMb5w71mavCtFTQQ0=; b=ByssGNCq/YqAi6KbopzgWL3XN7sRMyOXNDO5OFaME6cm/nfWu79STCRxjJuO2K9mif OPJawv3hwTR28X05Qp2KhS2CE3pM5gGCEaksWMmkCwj68vpL4FhsxiNpHJJRhAM62YGo gcbyqjQJQpl+jBk6PhHxDbUhD+C+ePc/7/xX0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=ULLSUtbU1gSsg2Ap53FePw8sAScNBp08JuGcAA73CghWvpoKWP2iyxjYRR8QNFzXUY fSkNpWD1gp/Xoru/CB7fVES5eKrbXaCTjT7cZRFfZQTZJCsgodPcsBrUIF9A6x3hbsuv aCLcBMJ0CJhAL2mtIQYW1nKfxoDJK1y6b3bzo= Received: by 10.151.145.21 with SMTP id x21mr1802177ybn.233.1225994053663; Thu, 06 Nov 2008 09:54:13 -0800 (PST) Received: by 10.150.211.7 with HTTP; Thu, 6 Nov 2008 09:54:13 -0800 (PST) Message-ID: Date: Thu, 6 Nov 2008 19:54:13 +0200 From: "Ivo Vachkov" To: "Robert Watson" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: FreeBSD Net Subject: Re: BPF question 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: Thu, 06 Nov 2008 17:54:15 -0000 I use following code: /* Send Announce Packet */ int zc_freebsd_sendannounce(int fd, unsigned char *mac, int zc_addr) { unsigned char *announce = NULL; int i = 0; unsigned int packet_len = 0; struct ether_header *eth_hdr = NULL; struct ether_arp *eth_arp = NULL; if (mac == NULL || zc_addr == 0 || zc_addr == -1) return -1; packet_len = sizeof(struct ether_header) + (sizeof(struct ether_arp) >= ETHER_PAYLOAD ? sizeof(struct ether_arp) : ETHER_PAYLOAD); /* Allocate announce packet */ if ((announce = malloc(packet_len)) == NULL) return -1; memset(announce, 0, packet_len); /* Populate Announce Packet * * eth_hdr * saddr - iface mac * daddr - ff:ff:ff:ff:ff:ff * type = ETHERTYPE_ARP * * eth_arp - ARP REQUEST * sender hw addr - iface mac * sender ip addr - zc_addr * target hw addr - 00:00:00:00:00:00 * target ip addr - zc_addr */ eth_hdr = (struct ether_header *)announce; eth_arp = (struct ether_arp *)((char *)eth_hdr + sizeof(struct ether_header)); memcpy(eth_hdr->ether_dhost, eth_bcast_addr, ETHER_ADDR_LEN); memcpy(eth_hdr->ether_shost, mac, ETHER_ADDR_LEN); eth_hdr->ether_type = htons(ETHERTYPE_ARP); eth_arp->arp_hrd = htons(ARPHRD_ETHER); eth_arp->arp_pro = htons(ETHERTYPE_IP); eth_arp->arp_hln = ETHER_ADDR_LEN; eth_arp->arp_pln = IP_ADDR_LEN; eth_arp->arp_op = htons(ARPOP_REQUEST); memcpy(eth_arp->arp_sha, mac, ETHER_ADDR_LEN); memcpy(eth_arp->arp_spa, &zc_addr, IP_ADDR_LEN); memcpy(eth_arp->arp_tha, eth_null_addr, ETHER_ADDR_LEN); memcpy(eth_arp->arp_tpa, &zc_addr, IP_ADDR_LEN); /* Send packet over the wire */ if ((i = write(fd, announce, packet_len)) < 0) { free(announce); return -1; } free(announce); return 0; } and later in my code i call this function in a loop: for (i = 0; i < ANNOUNCE_NUM; i++) { printf("ANNOUNCE ...\n"); fflush(stdout); /* Get initial time */ if (clock_gettime(CLOCK_REALTIME, &ts0) < 0) { perror("clock_gettime"); return -1; } /* Send Announce Packet */ if (zc_freebsd_sendannounce(bpf_fd, mac, zc_addr) < 0) { printf("zc_freebsd_sendannounce(): error\n"); return -1; } /* Possibly check for conflicts here */ /* Get time after select() */ if (clock_gettime(CLOCK_REALTIME, &ts1) < 0) { perror("clock_gettime"); return -1; } printf("ts0.sec |%ld|, ts0.nsec |%ld|\n", ts0.tv_sec, ts0.tv_nsec); fflush(stdout); printf("ts1.sec |%ld|, ts1.nsec |%ld|\n", ts1.tv_sec, ts1.tv_nsec); fflush(stdout); /* wait ANNOUNCE_INTERVAL or the rest of it */ ts0.tv_sec = ANNOUNCE_INTERVAL - (ts1.tv_sec - ts0.tv_sec) >= 0 ? ANNOUNCE_INTERVAL - (ts1.tv_sec - ts0.tv_sec) : 0; ts0.tv_nsec = ((ANNOUNCE_INTERVAL - ts0.tv_sec) * 1000000000) - (ts1.tv_nsec - ts0.tv_nsec) >= 0 ? ((ANNOUNCE_INTERVAL - ts0.tv_sec) * 1000000000) - (ts1.tv_nsec - ts0.tv_nsec) : 0; nanosleep(&ts0, NULL); } /* ANNOUNCE_NUM for() */ >From the two printf()'s above i see the nanosleep() is effective. However, when I check the packet flow with Wireshark (on the same host where this code is running) I see the announce packets timed only miliseconds away from one another. Could this be an issue with Wireshark ?! Right now I have only one computer to work on, but i'll test the timing from another computer asap. P.S. I'm implementing part of RFC3927 (ZeroConf) as part of a bigger project On Thu, Nov 6, 2008 at 7:06 PM, Robert Watson wrote: > > On Thu, 6 Nov 2008, Ivo Vachkov wrote: > >> I am using simple write() calls to send packets over BPF file descriptor. >> The BPF file descriptor is in buffered read mode (I assume this is the >> default and I do not set it explicitly). From what I see my write() calls >> are somewhat buffered. Since timing is relatively important for my project >> I'd like to ask if there is a way "flush" the write buffer. Setting O_DIRECT >> flag on the file descriptor doesn't seem to have any effect. > > The write(2) system call does no buffering in userspace (unlike, say, > fwrite(3)), and when you write to a BPF device it essentially goes straight > into the network interface output queue, so there should be no need for a > flush mechanism. Could you describe the buffering effect you're seeing a > bit more? > > Robert N M Watson > Computer Laboratory > University of Cambridge > From owner-freebsd-net@FreeBSD.ORG Thu Nov 6 18:14:04 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAA0A106568C for ; Thu, 6 Nov 2008 18:14:04 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 86E158FC20 for ; Thu, 6 Nov 2008 18:14:04 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender; b=JDfbUW3ID7+6w05IpFCMFIwDH/rcK5Za3pnnxnCmWsB08XmpN6aMiG6RipnoD4qzxTrwFpM2Gi3lX7Y72Is+6rrVNY4AgXfg89yOmQvbhSUPROVW/DZB1oVSuoOrnersqo+02x/DA2KFoTI3pKLUPu4OoEla/OaJt9nUHIpeDwA=; Received: from amnesiac.at.no.dns (dns.ccsem.infn.it [192.135.15.3]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1Ky9Mp-0007kr-4A; Thu, 06 Nov 2008 21:14:03 +0300 Date: Thu, 6 Nov 2008 21:14:00 +0300 From: Eygene Ryabinkin To: Ivo Vachkov Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lYetfuAxy9ic4HK3" Content-Disposition: inline In-Reply-To: Sender: rea-fbsd@codelabs.ru Cc: FreeBSD Net , Robert Watson Subject: Re: BPF question 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: Thu, 06 Nov 2008 18:14:05 -0000 --lYetfuAxy9ic4HK3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Just a side note. Thu, Nov 06, 2008 at 07:54:13PM +0200, Ivo Vachkov wrote: > P.S. I'm implementing part of RFC3927 (ZeroConf) as part of a bigger proj= ect Had you glanced at /usr/ports/net/howl and may be /usr/ports/net/avahi? --=20 Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual =20 )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook=20 {_.-``-' {_/ # --lYetfuAxy9ic4HK3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkkTM+cACgkQthUKNsbL7Yh7TgCglaJmkxHxe0mRDLFTj6X7aY4o EEUAn08mK1AERjfYB826/ghLcCU56GCf =TQ8p -----END PGP SIGNATURE----- --lYetfuAxy9ic4HK3-- From owner-freebsd-net@FreeBSD.ORG Thu Nov 6 18:27:02 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBAE1106564A; Thu, 6 Nov 2008 18:27:02 +0000 (UTC) (envelope-from ivo.vachkov@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by mx1.freebsd.org (Postfix) with ESMTP id 7C0A58FC1D; Thu, 6 Nov 2008 18:27:02 +0000 (UTC) (envelope-from ivo.vachkov@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so307136ywe.13 for ; Thu, 06 Nov 2008 10:27:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=U3jeooZfAMr8DEhCboG75VUu8yyG7JIN8+NkH+r7/cg=; b=khOZERF6FTfQlkwKzk1KSFb+GNOCYugP0yhOTPiWzXqS/nBJYwTeL/bEXaBBtScOfL g+0M7O+b4PS4uMwjDcBpOINRZSd3PzqOnJRkPe8gSv1DX0yXZ1Yr6S0aAW2KjLdrW3Dn YKT2ej0snBgV4BJoc7ewWClSgc9itddQEuC5U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=aXfIa8x9dFbel4BDbTS7UnF2vQ+NzymLxS4J4Dm99sQjEgx4a2hVXshc7Mhb6/gD/j DjEj7IRl8WennP9Xx12qFpLBEBsa0Wk+V+9E1R2mejvZIhvtAMx5Q3brdoxg8sqagrOJ NaflQj9JL+ge59g2D7K05Z0jL1pdATsKwn5oU= Received: by 10.151.114.6 with SMTP id r6mr1835702ybm.200.1225996021786; Thu, 06 Nov 2008 10:27:01 -0800 (PST) Received: by 10.150.211.7 with HTTP; Thu, 6 Nov 2008 10:27:01 -0800 (PST) Message-ID: Date: Thu, 6 Nov 2008 20:27:01 +0200 From: "Ivo Vachkov" To: "Eygene Ryabinkin" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: FreeBSD Net , Robert Watson Subject: Re: BPF question 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: Thu, 06 Nov 2008 18:27:02 -0000 I "evaluated" Avahi, but it is too big for my needs. I will check howl too. However Zeroconf seems relatively easy to implement, plus i need this module to work in cooperation with others. The License does matter too :) On Thu, Nov 6, 2008 at 8:14 PM, Eygene Ryabinkin wrote: > Just a side note. > > Thu, Nov 06, 2008 at 07:54:13PM +0200, Ivo Vachkov wrote: >> P.S. I'm implementing part of RFC3927 (ZeroConf) as part of a bigger project > > Had you glanced at /usr/ports/net/howl and may be /usr/ports/net/avahi? > -- > Eygene > _ ___ _.--. # > \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard > / ' ` , __.--' # to read the on-line manual > )/' _/ \ `-_, / # while single-stepping the kernel. > `-'" `"\_ ,_.-;_.-\_ ', fsc/as # > _.-'_./ {_.' ; / # -- FreeBSD Developers handbook > {_.-``-' {_/ # > -- "UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity." Dennis Ritchie From owner-freebsd-net@FreeBSD.ORG Thu Nov 6 19:33:54 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2AA3D1065679 for ; Thu, 6 Nov 2008 19:33:54 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id 7668F8FC0A for ; Thu, 6 Nov 2008 19:33:53 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id B3F56730AC; Thu, 6 Nov 2008 20:21:03 +0100 (CET) Date: Thu, 6 Nov 2008 20:21:03 +0100 From: Luigi Rizzo To: net@freebsd.org Message-ID: <20081106192103.GA46651@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: Two copies of resolver routines in libc ? 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: Thu, 06 Nov 2008 19:33:54 -0000 i was recently re-looking at the problem mentioned in http://lists.freebsd.org/pipermail/freebsd-hackers/2003-August/002399.html (bogus dns servers on my ISP, telecomitalia, which takes forever to resolve AAAA queries, coupled with the absence, on the FreeBSD resolver has no way to disable AAAA queries when IPV6 is compiled in, which happens with GENERIC kernels). While looking for a workaround (attached, read later), i noticed that libc has two versions of the resolver routines: one is in /usr/src/lib/libc/resolv/res_query.c the other one is embedded into /usr/src/lib/libc/net/getaddrinfo.c which includes a slightly modified version of res_nquery, res_ndots, res_nquerydomain (all parts of the routines documented in resolver(3)). If we are lucky, this is just replicated code. But i am not even sure they are the same, e.g. in the handling of options (in resolv.conf or the environment variable RES_OPTIONS). This is really annoying, because generally you don't know if an application uses getaddrinfo() or the traditional gethost*() routines (which in turn use resolver(3)), so it is hard to tell whether applications have a consistent behaviour. If someone has time, it would be worthwhile trying to merge the two versions of the code into one (and i believe we should make getaddrinfo use the standard stuff in resolv/ --- As for a fix to my problem: --- i wanted some trick to disable, in the resolver, the generation of AAAA queries. resolver(5) mentions some options that can be put in /etc/resolv.conf or in the RES_OPTIONS environment variable, to control the behaviour of the resolver. Some more options are undocumented but implemented, e.g. looking at /usr/src/lib/libc/resolv/res_init.c you find these additional options: retrans: retry: inet6 insecure1 insecure2 rotate no-check-names edns0 dname nibble: nibble2: v6revmode: The code below (which is completely trivial) add an additional option, "noaaaa", which disables the generation of AAAA requests. Just do setenv RES_OPTIONS noaaaa and you are done. I don't know of other ways to disable these requests on normal address resolutions, other than build a kernel without INET6. As you see below (and this relates to my original complaint), i had to make the modification in two places :( because things like ssh and telnet use getaddrinfo(), whereas e.g. firefox uses res_query(). I have no idea what is used by /usr/bin/host or /usr/bin/dig , because they do not seem to use any of the library routines. Any interest to have this into the system ? cheers luigi Index: net/getaddrinfo.c =================================================================== RCS file: /home/ncvs/src/lib/libc/net/getaddrinfo.c,v retrieving revision 1.69.2.10 diff -u -r1.69.2.10 getaddrinfo.c --- net/getaddrinfo.c 28 Sep 2007 06:23:03 -0000 1.69.2.10 +++ net/getaddrinfo.c 6 Nov 2008 20:35:39 -0000 @@ -85,6 +85,7 @@ #include #include "res_config.h" +#include "res_private.h" #ifdef DEBUG #include @@ -2257,6 +2258,8 @@ oflags = res->_flags; + if (res->options & RES_NOAAAA && type == ns_t_aaaa) + continue; /* ignore this request */ again: hp->rcode = NOERROR; /* default */ Index: resolv/res_init.c =================================================================== RCS file: /home/ncvs/src/lib/libc/resolv/res_init.c,v retrieving revision 1.2.2.3 diff -u -r1.2.2.3 res_init.c --- resolv/res_init.c 22 Dec 2006 07:33:20 -0000 1.2.2.3 +++ resolv/res_init.c 6 Nov 2008 20:34:00 -0000 @@ -636,6 +636,8 @@ !strncmp(cp, "no-tld-query", sizeof("no-tld-query") - 1)) { statp->options |= RES_NOTLDQUERY; + } else if (!strncmp(cp, "noaaaa", sizeof("noaaaa") - 1)) { + statp->options |= RES_NOAAAA; } else if (!strncmp(cp, "inet6", sizeof("inet6") - 1)) { statp->options |= RES_USE_INET6; } else if (!strncmp(cp, "insecure1", sizeof("insecure1") - 1)) { Index: resolv/res_private.h =================================================================== RCS file: /home/ncvs/src/lib/libc/resolv/res_private.h,v retrieving revision 1.1.1.1.2.1 diff -u -r1.1.1.1.2.1 res_private.h --- resolv/res_private.h 17 Jul 2006 10:09:58 -0000 1.1.1.1.2.1 +++ resolv/res_private.h 6 Nov 2008 19:08:29 -0000 @@ -3,6 +3,9 @@ #ifndef res_private_h #define res_private_h +// additional debug flags to disable AAAA queries +#define RES_NOAAAA 0x00800000 + struct __res_state_ext { union res_sockaddr_union nsaddrs[MAXNS]; struct sort_list { Index: resolv/res_query.c =================================================================== RCS file: /home/ncvs/src/lib/libc/resolv/res_query.c,v retrieving revision 1.3.2.1 diff -u -r1.3.2.1 res_query.c --- resolv/res_query.c 17 Jul 2006 10:09:58 -0000 1.3.2.1 +++ resolv/res_query.c 6 Nov 2008 20:45:23 -0000 @@ -90,6 +90,7 @@ #include #include #include "port_after.h" +#include "res_private.h" /* Options. Leave them on. */ #define DEBUG @@ -126,10 +127,12 @@ again: hp->rcode = NOERROR; /* default */ + if (statp->options & RES_NOAAAA && type == ns_t_aaaa) { + return 0; /* ignore this request */ + } #ifdef DEBUG if (statp->options & RES_DEBUG) - printf(";; res_query(%s, %d, %d)\n", name, class, type); + printf(";; res_nquery(%s, %d, %d)\n", name, class, type); #endif n = res_nmkquery(statp, QUERY, name, class, type, NULL, 0, NULL, From owner-freebsd-net@FreeBSD.ORG Thu Nov 6 22:04:04 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 24DB51065795 for ; Thu, 6 Nov 2008 22:04:04 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from fallbackmx08.syd.optusnet.com.au (fallbackmx08.syd.optusnet.com.au [211.29.132.10]) by mx1.freebsd.org (Postfix) with ESMTP id 30B758FC17 for ; Thu, 6 Nov 2008 22:04:01 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail16.syd.optusnet.com.au (mail16.syd.optusnet.com.au [211.29.132.197]) by fallbackmx08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id mA6AlN9t015620 for ; Thu, 6 Nov 2008 21:47:24 +1100 Received: from server.vk2pj.dyndns.org (c122-106-215-175.belrs3.nsw.optusnet.com.au [122.106.215.175]) by mail16.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id mA6AlJZi003815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Nov 2008 21:47:21 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id mA6AlI1a054935; Thu, 6 Nov 2008 21:47:18 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id mA6AlIiH054934; Thu, 6 Nov 2008 21:47:18 +1100 (EST) (envelope-from peter) Date: Thu, 6 Nov 2008 21:47:18 +1100 From: Peter Jeremy To: Jon Otterholm Message-ID: <20081106104718.GD51239@server.vk2pj.dyndns.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fXStkuK2IQBfcDe+" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-net@freebsd.org Subject: Re: CARP and L2 src-MAC 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: Thu, 06 Nov 2008 22:04:04 -0000 --fXStkuK2IQBfcDe+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2008-Nov-06 10:06:21 +0100, Jon Otterholm wrote: >Is it possible to tweak CARP to use the virtual MAC in L2 header instead of >the physical interface MAC? Could this be implemented as a feature >controlled by a sysctl? In my testing, Max Laier's carpdep patches do this. See http://lists.freebsd.org/pipermail/freebsd-net/2008-March/017103.html --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --fXStkuK2IQBfcDe+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkkSyzYACgkQ/opHv/APuIedHQCfU+y9/JhUY/sLrr4jlv8Kkseh mDEAn3PFbUIchKHJYjuUXooYs1qjCrV+ =gQUj -----END PGP SIGNATURE----- --fXStkuK2IQBfcDe+-- From owner-freebsd-net@FreeBSD.ORG Thu Nov 6 23:04:43 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 101771065672 for ; Thu, 6 Nov 2008 23:04:43 +0000 (UTC) (envelope-from citrin@citrin.ru) Received: from mail-chaos.rambler.ru (mail-chaos.rambler.ru [81.19.68.130]) by mx1.freebsd.org (Postfix) with ESMTP id BBC2E8FC28 for ; Thu, 6 Nov 2008 23:04:42 +0000 (UTC) (envelope-from citrin@citrin.ru) Received: from cmb.rambler.ramblermedia.com (unknown [91.78.191.235]) (Authenticated sender: citrin@citrin.ru) by mail-chaos.rambler.ru (Postfix) with ESMTPSA id 49ACD1702A for ; Fri, 7 Nov 2008 01:53:22 +0300 (MSK) Message-ID: <49137561.80403@citrin.ru> Date: Fri, 07 Nov 2008 01:53:21 +0300 From: Anton Yuzhaninov User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Subject: sysctl net.inet.tcp.syncache.count 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: Thu, 06 Nov 2008 23:04:43 -0000 % sysctl net.inet.tcp.syncache net.inet.tcp.syncache.rst_on_sock_fail: 1 net.inet.tcp.syncache.rexmtlimit: 3 net.inet.tcp.syncache.hashsize: 1024 net.inet.tcp.syncache.count: -84 net.inet.tcp.syncache.cachelimit: 102400 net.inet.tcp.syncache.bucketlimit: 100 Why number of entries in syncache is negative? % uname -srp FreeBSD 7.1-PRERELEASE amd64 -- Anton Yuzhaninov From owner-freebsd-net@FreeBSD.ORG Fri Nov 7 08:58:04 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0F5D106567C for ; Fri, 7 Nov 2008 08:58:04 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7DADE8FC0C for ; Fri, 7 Nov 2008 08:58:04 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTP id 0859946B5B; Fri, 7 Nov 2008 03:58:04 -0500 (EST) Date: Fri, 7 Nov 2008 08:58:03 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Anton Yuzhaninov In-Reply-To: <49137561.80403@citrin.ru> Message-ID: References: <49137561.80403@citrin.ru> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: sysctl net.inet.tcp.syncache.count 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: Fri, 07 Nov 2008 08:58:04 -0000 On Fri, 7 Nov 2008, Anton Yuzhaninov wrote: > % sysctl net.inet.tcp.syncache > net.inet.tcp.syncache.rst_on_sock_fail: 1 > net.inet.tcp.syncache.rexmtlimit: 3 > net.inet.tcp.syncache.hashsize: 1024 > net.inet.tcp.syncache.count: -84 > net.inet.tcp.syncache.cachelimit: 102400 > net.inet.tcp.syncache.bucketlimit: 100 > > Why number of entries in syncache is negative? The syncache entry is no longer protected by a single lock, since the locks on the syncache are now per-hash bucket, so it looks like it's been corrupted. This won't lead to other problems, as the count is updated as a statistic but never used to, for example, enforce limits. We should probably eliminate the statistic, since UMA already maintains the syncache entry count coherently as part of its own statistics, along with other useful information: robert@fledge:~> vmstat -z | head -1 ; vmstat -z | grep -i syncache ITEM SIZE LIMIT USED FREE REQUESTS FAILURES syncache: 104, 15392, 0, 222, 2638489, 0 I'm not convinced its worth adding the overhead of coherent statistics gathering for the cache entry count if we already have it elsewhere. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Fri Nov 7 21:06:11 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B14CA10656D3 for ; Fri, 7 Nov 2008 21:06:11 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id 4B4F78FC14 for ; Fri, 7 Nov 2008 21:06:11 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 27539 invoked by uid 399); 7 Nov 2008 20:39:30 -0000 Received: from localhost (HELO ?192.168.0.4?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 7 Nov 2008 20:39:30 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4914A782.6030509@FreeBSD.org> Date: Fri, 07 Nov 2008 12:39:30 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: FreeBSD net mailing list References: <20081106153035.R16105@maildrop.int.zabbadoz.net> In-Reply-To: <20081106153035.R16105@maildrop.int.zabbadoz.net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD current mailing list Subject: Re: Kernel without INET 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: Fri, 07 Nov 2008 21:06:11 -0000 Not that I object to this at all, but out of curiosity what is the motivation? I would imagine "embedded devices that run stuff not connected to the 'net" but hoping for something more interesting/exciting. :) Doug -- This .signature sanitized for your protection From owner-freebsd-net@FreeBSD.ORG Fri Nov 7 22:30:45 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF2861065670 for ; Fri, 7 Nov 2008 22:30:45 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.230]) by mx1.freebsd.org (Postfix) with ESMTP id B3F708FC12 for ; Fri, 7 Nov 2008 22:30:45 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1331934rvf.43 for ; Fri, 07 Nov 2008 14:30:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:mime-version:content-type:content-transfer-encoding :content-disposition:x-google-sender-auth; bh=KGwZrE6WcUXNQDG5kbdkxNvYakN+mJR8g56oGC1AUiE=; b=TyqT13yPN2rONhmOOhfeH5jRjr3tmIHIFKkDUJx2vICsgclZQ8Q1u6Im+yj6bI1oCa eQl8pr0ze0byo+uf4AXcJXh41RxdQziLOveYdOekva8xJdDotoZj2KKGebvKwUEK62Yw tflzkXTpqthdLPVmPPRBwlidCmSQAPUXOpjFs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition:x-google-sender-auth; b=ubGkBFQjewdMZkao2p9dldc/sssv2DoDZg1A8Oa1u8/oA8OR2WVkOmLBxM0cV7pwb9 QhFp+wDkrGq+BjkrCWXyUYlBkGi+w9S4Cp7DD9OWmW7ui56lJ4RUbNbGooedaNhl0Jar p+6a9AUoUuaXErG6kgdBdyUDRSMGt2eVyY0KU= Received: by 10.141.2.19 with SMTP id e19mr2052936rvi.291.1226097045477; Fri, 07 Nov 2008 14:30:45 -0800 (PST) Received: by 10.140.157.8 with HTTP; Fri, 7 Nov 2008 14:30:45 -0800 (PST) Message-ID: <3c1674c90811071430s1f07ba6cp372609809ef7f591@mail.gmail.com> Date: Fri, 7 Nov 2008 22:30:45 +0000 From: "Kip Macy" Sender: mat.macy@gmail.com To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 58a302c4e934f76f Subject: small radix_mpath patch 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: Fri, 07 Nov 2008 22:30:46 -0000 Calling arpresolve on an rtentry looked up by rtalloc_mpath_fib won't work because a gratuitous clone route is created without llinfo attached. As far as I can tell, routes should only ever be cloned for initial host route creation during a resolve to store arp information. Index: sys/net/radix_mpath.c =================================================================== --- sys/net/radix_mpath.c (revision 184756) +++ sys/net/radix_mpath.c (working copy) @@ -54,7 +54,7 @@ /* * give some jitter to hash, to avoid synchronization between routers */ -static u_int32_t hashjitter; +static uint32_t hashjitter; int rn_mpath_capable(struct radix_node_head *rnh) @@ -267,7 +267,7 @@ */ if (ro->ro_rt && ro->ro_rt->rt_ifp && (ro->ro_rt->rt_flags & RTF_UP)) return; /* XXX */ - ro->ro_rt = rtalloc1_fib(&ro->ro_dst, 1, 0UL, fibnum); + ro->ro_rt = rtalloc1_fib(&ro->ro_dst, 1, RTF_CLONING, fibnum); /* if the route does not exist or it is not multipath, don't care */ if (ro->ro_rt == NULL) @@ -299,7 +299,7 @@ return; } - rtfree(ro->ro_rt); + RTFREE_LOCKED(ro->ro_rt); ro->ro_rt = (struct rtentry *)rn; RT_LOCK(ro->ro_rt); RT_ADDREF(ro->ro_rt); From owner-freebsd-net@FreeBSD.ORG Sat Nov 8 08:40:01 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CBED1065676 for ; Sat, 8 Nov 2008 08:40:01 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from asuka.mahoroba.org (unknown [IPv6:2001:2f0:104:8010::1]) by mx1.freebsd.org (Postfix) with ESMTP id B250B8FC08 for ; Sat, 8 Nov 2008 08:40:00 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from kasuga.mahoroba.org (IDENT:eGz3pUyNVjfRNryqL1rld5BnswR2uK6zGuVs2vtwMy4WpgX3x7ZIN8Qa92izqT/x@kasuga.mahoroba.org [IPv6:2001:2f0:104:8010:20b:97ff:fe2e:b521]) (user=ume mech=CRAM-MD5 bits=0) by asuka.mahoroba.org (8.14.3/8.14.3) with ESMTP/inet6 id mA88dqxd070685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 Nov 2008 17:39:54 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Sat, 08 Nov 2008 17:39:52 +0900 Message-ID: From: Hajimu UMEMOTO To: Luigi Rizzo In-Reply-To: <20081106192103.GA46651@onelab2.iet.unipi.it> References: <20081106192103.GA46651@onelab2.iet.unipi.it> User-Agent: xcite1.57> Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.7 Emacs/22.2 (i386-pc-freebsd) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 7.1-PRERELEASE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/mixed; boundary="Multipart_Sat_Nov__8_17:39:51_2008-1" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (asuka.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Sat, 08 Nov 2008 17:39:54 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on asuka.mahoroba.org Cc: net@freebsd.org Subject: Re: Two copies of resolver routines in libc ? 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: Sat, 08 Nov 2008 08:40:01 -0000 --Multipart_Sat_Nov__8_17:39:51_2008-1 Content-Type: text/plain; charset=US-ASCII Hi, >>>>> On Thu, 6 Nov 2008 20:21:03 +0100 >>>>> Luigi Rizzo said: rizzo> While looking for a workaround (attached, read later), i noticed rizzo> that libc has two versions of the resolver routines: one is in rizzo> /usr/src/lib/libc/resolv/res_query.c rizzo> the other one is embedded into rizzo> /usr/src/lib/libc/net/getaddrinfo.c rizzo> which includes a slightly modified version of res_nquery, res_ndots, rizzo> res_nquerydomain (all parts of the routines documented in resolver(3)). Yes. rizzo> If we are lucky, this is just replicated code. No, the resolver functions in getaddrinfo.c has some addition of functionality. It was done for solving the query order problem. rizzo> But i am not even sure they are the same, e.g. in the handling of rizzo> options (in resolv.conf or the environment variable RES_OPTIONS). The basic functionality including the handling of options are same. rizzo> This is really annoying, because generally you don't know if an rizzo> application uses getaddrinfo() or the traditional gethost*() routines rizzo> (which in turn use resolver(3)), so it is hard to tell whether rizzo> applications have a consistent behaviour. You don't need to worry about it. rizzo> If someone has time, it would be worthwhile trying to merge rizzo> the two versions of the code into one (and i believe we should rizzo> make getaddrinfo use the standard stuff in resolv/ When we tried to solve the query order problem, we decided to have a modification code of the resolver into getaddrinfo.c. Because: - Hide the internal functions from outside of libc. - Don't change the resolver as possible to ease further merge from ISC BIND. Since we have the symbol versioning facility, we can hide the libc internal functions from outside of libc, these days. So, it may better to merge the two. I attached the proposed patch in this mail. Please review it. Sincerely, --Multipart_Sat_Nov__8_17:39:51_2008-1 Content-Type: text/x-patch; type=patch; charset=US-ASCII Content-Disposition: attachment; filename="resolver-multi.diff" Content-Transfer-Encoding: 7bit Index: lib/libc/net/getaddrinfo.c diff -u -p lib/libc/net/getaddrinfo.c.orig lib/libc/net/getaddrinfo.c --- lib/libc/net/getaddrinfo.c.orig 2007-09-06 03:08:14.000000000 +0900 +++ lib/libc/net/getaddrinfo.c 2008-11-07 16:06:49.000000000 +0900 @@ -94,6 +94,7 @@ __FBSDID("$FreeBSD: src/lib/libc/net/get #include #include "un-namespace.h" #include "libc_private.h" +#include "res_private.h" #ifdef NS_CACHING #include "nscache.h" #endif @@ -210,15 +211,6 @@ static const ns_src default_dns_files[] { 0 } }; -struct res_target { - struct res_target *next; - const char *name; /* domain name */ - int qclass, qtype; /* class and type of query */ - u_char *answer; /* buffer to put answer */ - int anslen; /* size of answer buffer */ - int n; /* result length */ -}; - #define MAXPACKET (64*1024) typedef union { @@ -279,11 +271,6 @@ static int addrinfo_marshal_func(char *, static int addrinfo_unmarshal_func(char *, size_t, void *, va_list, void *); #endif -static int res_queryN(const char *, struct res_target *, res_state); -static int res_searchN(const char *, struct res_target *, res_state); -static int res_querydomainN(const char *, const char *, - struct res_target *, res_state); - /* XXX macros that make external reference is BAD. */ #define GET_AI(ai, afd, addr) \ @@ -2117,7 +2104,7 @@ _dns_getaddrinfo(void *rv, void *cb_data return NS_NOTFOUND; } - if (res_searchN(hostname, &q, res) < 0) { + if (__res_nsearchN(res, hostname, &q) < 0) { free(buf); free(buf2); return NS_NOTFOUND; @@ -2407,355 +2394,3 @@ _yp_getaddrinfo(void *rv, void *cb_data, return NS_SUCCESS; } #endif - -/* resolver logic */ - -/* - * Formulate a normal query, send, and await answer. - * Returned answer is placed in supplied buffer "answer". - * Perform preliminary check of answer, returning success only - * if no error is indicated and the answer count is nonzero. - * Return the size of the response on success, -1 on error. - * Error number is left in h_errno. - * - * Caller must parse answer and determine whether it answers the question. - */ -static int -res_queryN(const char *name, struct res_target *target, res_state res) -{ - u_char *buf; - HEADER *hp; - int n; - u_int oflags; - struct res_target *t; - int rcode; - int ancount; - - rcode = NOERROR; - ancount = 0; - - buf = malloc(MAXPACKET); - if (!buf) { - RES_SET_H_ERRNO(res, NETDB_INTERNAL); - return -1; - } - - for (t = target; t; t = t->next) { - int class, type; - u_char *answer; - int anslen; - - hp = (HEADER *)(void *)t->answer; - - /* make it easier... */ - class = t->qclass; - type = t->qtype; - answer = t->answer; - anslen = t->anslen; - - oflags = res->_flags; - -again: - hp->rcode = NOERROR; /* default */ - -#ifdef DEBUG - if (res->options & RES_DEBUG) - printf(";; res_query(%s, %d, %d)\n", name, class, type); -#endif - - n = res_nmkquery(res, QUERY, name, class, type, NULL, 0, NULL, - buf, MAXPACKET); - if (n > 0 && (res->_flags & RES_F_EDNS0ERR) == 0 && - (res->options & (RES_USE_EDNS0|RES_USE_DNSSEC)) != 0U) - n = res_nopt(res, n, buf, MAXPACKET, anslen); - if (n <= 0) { -#ifdef DEBUG - if (res->options & RES_DEBUG) - printf(";; res_query: mkquery failed\n"); -#endif - free(buf); - RES_SET_H_ERRNO(res, NO_RECOVERY); - return (n); - } - n = res_nsend(res, buf, n, answer, anslen); - if (n < 0) { - /* - * if the query choked with EDNS0, retry - * without EDNS0 - */ - if ((res->options & (RES_USE_EDNS0|RES_USE_DNSSEC)) - != 0U && - ((oflags ^ res->_flags) & RES_F_EDNS0ERR) != 0) { - res->_flags |= RES_F_EDNS0ERR; - if (res->options & RES_DEBUG) - printf(";; res_nquery: retry without EDNS0\n"); - goto again; - } - rcode = hp->rcode; /* record most recent error */ -#ifdef DEBUG - if (res->options & RES_DEBUG) - printf(";; res_query: send error\n"); -#endif - continue; - } - - if (n > anslen) - hp->rcode = FORMERR; /* XXX not very informative */ - if (hp->rcode != NOERROR || ntohs(hp->ancount) == 0) { - rcode = hp->rcode; /* record most recent error */ -#ifdef DEBUG - if (res->options & RES_DEBUG) - printf(";; rcode = %u, ancount=%u\n", hp->rcode, - ntohs(hp->ancount)); -#endif - continue; - } - - ancount += ntohs(hp->ancount); - - t->n = n; - } - - free(buf); - - if (ancount == 0) { - switch (rcode) { - case NXDOMAIN: - RES_SET_H_ERRNO(res, HOST_NOT_FOUND); - break; - case SERVFAIL: - RES_SET_H_ERRNO(res, TRY_AGAIN); - break; - case NOERROR: - RES_SET_H_ERRNO(res, NO_DATA); - break; - case FORMERR: - case NOTIMP: - case REFUSED: - default: - RES_SET_H_ERRNO(res, NO_RECOVERY); - break; - } - return (-1); - } - return (ancount); -} - -/* - * Formulate a normal query, send, and retrieve answer in supplied buffer. - * Return the size of the response on success, -1 on error. - * If enabled, implement search rules until answer or unrecoverable failure - * is detected. Error code, if any, is left in h_errno. - */ -static int -res_searchN(const char *name, struct res_target *target, res_state res) -{ - const char *cp, * const *domain; - HEADER *hp = (HEADER *)(void *)target->answer; /*XXX*/ - u_int dots; - int trailing_dot, ret, saved_herrno; - int got_nodata = 0, got_servfail = 0, root_on_list = 0; - int tried_as_is = 0; - int searched = 0; - char abuf[MAXDNAME]; - - errno = 0; - RES_SET_H_ERRNO(res, HOST_NOT_FOUND); /* default, if we never query */ - dots = 0; - for (cp = name; *cp; cp++) - dots += (*cp == '.'); - trailing_dot = 0; - if (cp > name && *--cp == '.') - trailing_dot++; - - /* - * if there aren't any dots, it could be a user-level alias - */ - if (!dots && - (cp = res_hostalias(res, name, abuf, sizeof(abuf))) != NULL) - return (res_queryN(cp, target, res)); - - /* - * If there are enough dots in the name, let's just give it a - * try 'as is'. The threshold can be set with the "ndots" option. - * Also, query 'as is', if there is a trailing dot in the name. - */ - saved_herrno = -1; - if (dots >= res->ndots || trailing_dot) { - ret = res_querydomainN(name, NULL, target, res); - if (ret > 0 || trailing_dot) - return (ret); - if (errno == ECONNREFUSED) { - RES_SET_H_ERRNO(res, TRY_AGAIN); - return (-1); - } - switch (res->res_h_errno) { - case NO_DATA: - case HOST_NOT_FOUND: - break; - case TRY_AGAIN: - if (hp->rcode == SERVFAIL) - break; - /* FALLTHROUGH */ - default: - return (-1); - } - saved_herrno = res->res_h_errno; - tried_as_is++; - } - - /* - * We do at least one level of search if - * - there is no dot and RES_DEFNAME is set, or - * - there is at least one dot, there is no trailing dot, - * and RES_DNSRCH is set. - */ - if ((!dots && (res->options & RES_DEFNAMES)) || - (dots && !trailing_dot && (res->options & RES_DNSRCH))) { - int done = 0; - - for (domain = (const char * const *)res->dnsrch; - *domain && !done; - domain++) { - searched = 1; - - if (domain[0][0] == '\0' || - (domain[0][0] == '.' && domain[0][1] == '\0')) - root_on_list++; - - if (root_on_list && tried_as_is) - continue; - - ret = res_querydomainN(name, *domain, target, res); - if (ret > 0) - return (ret); - - /* - * If no server present, give up. - * If name isn't found in this domain, - * keep trying higher domains in the search list - * (if that's enabled). - * On a NO_DATA error, keep trying, otherwise - * a wildcard entry of another type could keep us - * from finding this entry higher in the domain. - * If we get some other error (negative answer or - * server failure), then stop searching up, - * but try the input name below in case it's - * fully-qualified. - */ - if (errno == ECONNREFUSED) { - RES_SET_H_ERRNO(res, TRY_AGAIN); - return (-1); - } - - switch (res->res_h_errno) { - case NO_DATA: - got_nodata++; - /* FALLTHROUGH */ - case HOST_NOT_FOUND: - /* keep trying */ - break; - case TRY_AGAIN: - got_servfail++; - if (hp->rcode == SERVFAIL) { - /* try next search element, if any */ - break; - } - /* FALLTHROUGH */ - default: - /* anything else implies that we're done */ - done++; - } - /* - * if we got here for some reason other than DNSRCH, - * we only wanted one iteration of the loop, so stop. - */ - if (!(res->options & RES_DNSRCH)) - done++; - } - } - - switch (res->res_h_errno) { - case NO_DATA: - case HOST_NOT_FOUND: - break; - case TRY_AGAIN: - if (hp->rcode == SERVFAIL) - break; - /* FALLTHROUGH */ - default: - goto giveup; - } - - /* - * If the query has not already been tried as is then try it - * unless RES_NOTLDQUERY is set and there were no dots. - */ - if ((dots || !searched || !(res->options & RES_NOTLDQUERY)) && - !(tried_as_is || root_on_list)) { - ret = res_querydomainN(name, NULL, target, res); - if (ret > 0) - return (ret); - } - - /* - * if we got here, we didn't satisfy the search. - * if we did an initial full query, return that query's h_errno - * (note that we wouldn't be here if that query had succeeded). - * else if we ever got a nodata, send that back as the reason. - * else send back meaningless h_errno, that being the one from - * the last DNSRCH we did. - */ -giveup: - if (saved_herrno != -1) - RES_SET_H_ERRNO(res, saved_herrno); - else if (got_nodata) - RES_SET_H_ERRNO(res, NO_DATA); - else if (got_servfail) - RES_SET_H_ERRNO(res, TRY_AGAIN); - return (-1); -} - -/* - * Perform a call on res_query on the concatenation of name and domain, - * removing a trailing dot from name if domain is NULL. - */ -static int -res_querydomainN(const char *name, const char *domain, - struct res_target *target, res_state res) -{ - char nbuf[MAXDNAME]; - const char *longname = nbuf; - size_t n, d; - -#ifdef DEBUG - if (res->options & RES_DEBUG) - printf(";; res_querydomain(%s, %s)\n", - name, domain?domain:""); -#endif - if (domain == NULL) { - /* - * Check for trailing '.'; - * copy without '.' if present. - */ - n = strlen(name); - if (n >= MAXDNAME) { - RES_SET_H_ERRNO(res, NO_RECOVERY); - return (-1); - } - if (n > 0 && name[--n] == '.') { - strncpy(nbuf, name, n); - nbuf[n] = '\0'; - } else - longname = name; - } else { - n = strlen(name); - d = strlen(domain); - if (n + d + 1 >= MAXDNAME) { - RES_SET_H_ERRNO(res, NO_RECOVERY); - return (-1); - } - snprintf(nbuf, sizeof(nbuf), "%s.%s", name, domain); - } - return (res_queryN(longname, target, res)); -} Index: lib/libc/resolv/res_private.h diff -u lib/libc/resolv/res_private.h.orig lib/libc/resolv/res_private.h --- lib/libc/resolv/res_private.h.orig 2007-06-04 02:02:28.000000000 +0900 +++ lib/libc/resolv/res_private.h 2008-11-07 15:58:01.000000000 +0900 @@ -14,9 +14,21 @@ char nsuffix2[64]; }; +struct res_target { + struct res_target *next; + const char *name; /* domain name */ + int qclass, qtype; /* class and type of query */ + u_char *answer; /* buffer to put answer */ + int anslen; /* size of answer buffer */ + int n; /* result length */ +}; + extern int res_ourserver_p(const res_state statp, const struct sockaddr *sa); +extern int +__res_nsearchN(res_state, const char *, struct res_target *); + #endif /*! \file */ Index: lib/libc/resolv/res_query.c diff -u -p lib/libc/resolv/res_query.c.orig lib/libc/resolv/res_query.c --- lib/libc/resolv/res_query.c.orig 2007-06-04 02:20:27.000000000 +0900 +++ lib/libc/resolv/res_query.c 2008-11-08 16:28:29.000000000 +0900 @@ -87,6 +87,8 @@ __FBSDID("$FreeBSD: src/lib/libc/resolv/ #include #include "port_after.h" +#include "res_private.h" + /* Options. Leave them on. */ #define DEBUG @@ -96,6 +98,10 @@ __FBSDID("$FreeBSD: src/lib/libc/resolv/ #define MAXPACKET 1024 #endif +static int res_nqueryN(res_state, const char *, struct res_target *); +static int res_nquerydomainN(res_state, const char *, const char *, + struct res_target *); + /*% * Formulate a normal query, send, and await answer. * Returned answer is placed in supplied buffer "answer". @@ -113,65 +119,117 @@ res_nquery(res_state statp, u_char *answer, /*%< buffer to put answer */ int anslen) /*%< size of answer buffer */ { + struct res_target q; + int n; + + memset(&q, 0, sizeof(q)); + q.name = name; + q.qclass = class; + q.qtype = type; + q.answer = answer; + q.anslen = anslen; + n = res_nqueryN(statp, name, &q); + return ((n < 0) ? n : q.n); +} + +static int +res_nqueryN(res_state statp, const char *name, struct res_target *target) +{ u_char buf[MAXPACKET]; - HEADER *hp = (HEADER *) answer; + HEADER *hp; int n; u_int oflags; + struct res_target *t; + int rcode; + int ancount; + + rcode = NOERROR; + ancount = 0; + + for (t = target; t; t = t->next) { + int class, type; + u_char *answer; + int anslen; + + hp = (HEADER *)(void *) t->answer; + + /* make it easier... */ + class = t->qclass; + type = t->qtype; + answer = t->answer; + anslen = t->anslen; - oflags = statp->_flags; + oflags = statp->_flags; again: - hp->rcode = NOERROR; /*%< default */ + hp->rcode = NOERROR; /*%< default */ #ifdef DEBUG - if (statp->options & RES_DEBUG) - printf(";; res_query(%s, %d, %d)\n", name, class, type); + if (statp->options & RES_DEBUG) + printf(";; res_query(%s, %d, %d)\n", name, class, + type); #endif - n = res_nmkquery(statp, QUERY, name, class, type, NULL, 0, NULL, - buf, sizeof(buf)); + n = res_nmkquery(statp, QUERY, name, class, type, NULL, 0, + NULL, buf, sizeof(buf)); #ifdef RES_USE_EDNS0 - if (n > 0 && (statp->_flags & RES_F_EDNS0ERR) == 0 && - (statp->options & (RES_USE_EDNS0|RES_USE_DNSSEC)) != 0U) - n = res_nopt(statp, n, buf, sizeof(buf), anslen); + if (n > 0 && (statp->_flags & RES_F_EDNS0ERR) == 0 && + (statp->options & (RES_USE_EDNS0|RES_USE_DNSSEC)) != 0U) + n = res_nopt(statp, n, buf, sizeof(buf), anslen); #endif - if (n <= 0) { + if (n <= 0) { #ifdef DEBUG - if (statp->options & RES_DEBUG) - printf(";; res_query: mkquery failed\n"); -#endif - RES_SET_H_ERRNO(statp, NO_RECOVERY); - return (n); - } - n = res_nsend(statp, buf, n, answer, anslen); - if (n < 0) { -#ifdef RES_USE_EDNS0 - /* if the query choked with EDNS0, retry without EDNS0 */ - if ((statp->options & (RES_USE_EDNS0|RES_USE_DNSSEC)) != 0U && - ((oflags ^ statp->_flags) & RES_F_EDNS0ERR) != 0) { - statp->_flags |= RES_F_EDNS0ERR; if (statp->options & RES_DEBUG) - printf(";; res_nquery: retry without EDNS0\n"); - goto again; + printf(";; res_query: mkquery failed\n"); +#endif + RES_SET_H_ERRNO(statp, NO_RECOVERY); + return (n); } + n = res_nsend(statp, buf, n, answer, anslen); + if (n < 0) { +#ifdef RES_USE_EDNS0 + /* + * if the query choked with EDNS0, retry + * without EDNS0 + */ + if ((statp->options & (RES_USE_EDNS0|RES_USE_DNSSEC)) + != 0U && + ((oflags ^ statp->_flags) & RES_F_EDNS0ERR) != 0) { + statp->_flags |= RES_F_EDNS0ERR; + if (statp->options & RES_DEBUG) + printf(";; res_nquery: retry without EDNS0\n"); + goto again; + } #endif + rcode = hp->rcode; /* record most recent error */ #ifdef DEBUG - if (statp->options & RES_DEBUG) - printf(";; res_query: send error\n"); + if (statp->options & RES_DEBUG) + printf(";; res_query: send error\n"); #endif - RES_SET_H_ERRNO(statp, TRY_AGAIN); - return (n); - } + continue; + } - if (hp->rcode != NOERROR || ntohs(hp->ancount) == 0) { + if (n > anslen) + hp->rcode = FORMERR; /* XXX not very informative */ + if (hp->rcode != NOERROR || ntohs(hp->ancount) == 0) { + rcode = hp->rcode; /* record most recent error */ #ifdef DEBUG - if (statp->options & RES_DEBUG) - printf(";; rcode = (%s), counts = an:%d ns:%d ar:%d\n", - p_rcode(hp->rcode), - ntohs(hp->ancount), - ntohs(hp->nscount), - ntohs(hp->arcount)); + if (statp->options & RES_DEBUG) + printf(";; rcode = (%s), counts = an:%d ns:%d ar:%d\n", + p_rcode(hp->rcode), + ntohs(hp->ancount), + ntohs(hp->nscount), + ntohs(hp->arcount)); #endif - switch (hp->rcode) { + continue; + } + + ancount += ntohs(hp->ancount); + + t->n = n; + } + + if (ancount == 0) { + switch (rcode) { case NXDOMAIN: RES_SET_H_ERRNO(statp, HOST_NOT_FOUND); break; @@ -190,7 +248,7 @@ again: } return (-1); } - return (n); + return (ancount); } /*% @@ -206,8 +264,24 @@ res_nsearch(res_state statp, u_char *answer, /*%< buffer to put answer */ int anslen) /*%< size of answer */ { + struct res_target q; + int n; + + memset(&q, 0, sizeof(q)); + q.name = name; + q.qclass = class; + q.qtype = type; + q.answer = answer; + q.anslen = anslen; + n = __res_nsearchN(statp, name, &q); + return ((n < 0) ? n : q.n); +} + +int +__res_nsearchN(res_state statp, const char *name, struct res_target *target) +{ const char *cp, * const *domain; - HEADER *hp = (HEADER *) answer; + HEADER *hp = (HEADER *)(void *) target->answer; char tmp[NS_MAXDNAME]; u_int dots; int trailing_dot, ret, saved_herrno; @@ -226,7 +300,7 @@ res_nsearch(res_state statp, /* If there aren't any dots, it could be a user-level alias. */ if (!dots && (cp = res_hostalias(statp, name, tmp, sizeof tmp))!= NULL) - return (res_nquery(statp, cp, class, type, answer, anslen)); + return (res_nqueryN(statp, cp, target)); /* * If there are enough dots in the name, let's just give it a @@ -235,8 +309,7 @@ res_nsearch(res_state statp, */ saved_herrno = -1; if (dots >= statp->ndots || trailing_dot) { - ret = res_nquerydomain(statp, name, NULL, class, type, - answer, anslen); + ret = res_nquerydomainN(statp, name, NULL, target); if (ret > 0 || trailing_dot) return (ret); if (errno == ECONNREFUSED) { @@ -280,9 +353,7 @@ res_nsearch(res_state statp, if (root_on_list && tried_as_is) continue; - ret = res_nquerydomain(statp, name, *domain, - class, type, - answer, anslen); + ret = res_nquerydomainN(statp, name, *domain, target); if (ret > 0) return (ret); @@ -366,8 +437,7 @@ res_nsearch(res_state statp, */ if ((dots || !searched || (statp->options & RES_NOTLDQUERY) == 0U) && !(tried_as_is || root_on_list)) { - ret = res_nquerydomain(statp, name, NULL, class, type, - answer, anslen); + ret = res_nquerydomainN(statp, name, NULL, target); if (ret > 0) return (ret); } @@ -401,6 +471,23 @@ res_nquerydomain(res_state statp, u_char *answer, /*%< buffer to put answer */ int anslen) /*%< size of answer */ { + struct res_target q; + int n; + + memset(&q, 0, sizeof(q)); + q.name = name; + q.qclass = class; + q.qtype = type; + q.answer = answer; + q.anslen = anslen; + n = res_nquerydomainN(statp, name, domain, &q); + return ((n < 0) ? n : q.n); +} + +static int +res_nquerydomainN(res_state statp, const char *name, const char *domain, + struct res_target *target) +{ char nbuf[MAXDNAME]; const char *longname = nbuf; int n, d; @@ -408,7 +495,8 @@ res_nquerydomain(res_state statp, #ifdef DEBUG if (statp->options & RES_DEBUG) printf(";; res_nquerydomain(%s, %s, %d, %d)\n", - name, domain?domain:"", class, type); + name, domain?domain:"", target->qclass, + target->qtype); #endif if (domain == NULL) { /* @@ -433,9 +521,9 @@ res_nquerydomain(res_state statp, RES_SET_H_ERRNO(statp, NO_RECOVERY); return (-1); } - sprintf(nbuf, "%s.%s", name, domain); + snprintf(nbuf, sizeof(nbuf), "%s.%s", name, domain); } - return (res_nquery(statp, longname, class, type, answer, anslen)); + return (res_nqueryN(statp, longname, target)); } const char * --Multipart_Sat_Nov__8_17:39:51_2008-1 Content-Type: text/plain; charset=US-ASCII -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ --Multipart_Sat_Nov__8_17:39:51_2008-1-- From owner-freebsd-net@FreeBSD.ORG Sat Nov 8 12:01:04 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 210E81065670 for ; Sat, 8 Nov 2008 12:01:04 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 9C78F8FC12 for ; Sat, 8 Nov 2008 12:01:03 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 227337521; Sat, 08 Nov 2008 13:01:02 +0200 Message-ID: <4915716D.3060603@FreeBSD.org> Date: Sat, 08 Nov 2008 13:01:01 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.17 (X11/20081029) MIME-Version: 1.0 To: Vladimir Grebenschikov References: <1225835127.3428.19.camel@localhost> In-Reply-To: <1225835127.3428.19.camel@localhost> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 08 Nov 2008 12:26:25 +0000 Cc: freebsd-net Subject: Re: net/mpd, net/mpd5 do not work on 8-CURRENT 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: Sat, 08 Nov 2008 12:01:04 -0000 Vladimir Grebenschikov wrote: > These ports are still using set line discipline ioctl to configure > ng_tty, but it is not work any more (with new ttys). > > Any hope to make mpd work with recent 8-CURRENT ? I have just committed some patches into 8-CURRENT and mpd5 CVS and now it works for me. But there are still some issues that must be fixed. -- Alexander Motin From owner-freebsd-net@FreeBSD.ORG Sat Nov 8 15:05:47 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4357810656A8 for ; Sat, 8 Nov 2008 15:05:47 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id AA4C48FC16 for ; Sat, 8 Nov 2008 15:05:46 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 9DD09730AC; Sat, 8 Nov 2008 16:10:23 +0100 (CET) Date: Sat, 8 Nov 2008 16:10:23 +0100 From: Luigi Rizzo To: Hajimu UMEMOTO Message-ID: <20081108151023.GA72747@onelab2.iet.unipi.it> References: <20081106192103.GA46651@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="x+6KMIRAuhnl3hBn" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: net@freebsd.org Subject: Re: Two copies of resolver routines in libc ? 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: Sat, 08 Nov 2008 15:05:47 -0000 --x+6KMIRAuhnl3hBn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Nov 08, 2008 at 05:39:52PM +0900, Hajimu UMEMOTO wrote: > Hi, > > >>>>> On Thu, 6 Nov 2008 20:21:03 +0100 > >>>>> Luigi Rizzo said: > > rizzo> While looking for a workaround (attached, read later), i noticed > rizzo> that libc has two versions of the resolver routines: one is in ... > rizzo> If we are lucky, this is just replicated code. > > No, the resolver functions in getaddrinfo.c has some addition of > functionality. It was done for solving the query order problem. ... > When we tried to solve the query order problem, we decided to have a > modification code of the resolver into getaddrinfo.c. Because: > > - Hide the internal functions from outside of libc. > - Don't change the resolver as possible to ease further merge from > ISC BIND. > > Since we have the symbol versioning facility, we can hide the libc > internal functions from outside of libc, these days. So, it may > better to merge the two. I attached the proposed patch in this mail. > Please review it. hi, thanks for the answer and the effort for merging back the two copies. I am looking at your proposed patch but i am not sure i understand it fully, so i would be grateful if you could explain me a few things (btw i am attaching a version of your patch constructed with 'diff -ubwp' and couple of formatting changes to remove whitespace differences; this should make the actual changes more evident): 1. i apologize for my ignorance, but i suppose there is a binding between __res_nsearchN() and res_nsearchN(), and the same for all function with and without the two leading __ . Where is this binding established, as i don't see anything in the diff that you sent. 2. res_*() now become wrappers around the newly introduced res_*N() functions. While this approach removes the duplication, it does not address the "ease further merge from ISC BIND" case, which definitely sounded as a valid concern. So i wonder, what is it that prevents you from acting the other way around, i.e. build the res_*N() around the existing res_*() functions ? This way the original ISC code would really be unmodified and perhaps the change would be even more confined. Does this constraint apply to all three functions (res_query, res_search, res_nquerydomain) or only for a subset of them ? From what i can tell, at least in res_nquery() the only significant change seems to be the following + if (n > anslen) + hp->rcode = FORMERR; /* XXX not very informative */ other than that it seems perfectly fine to implement res_nqueryN() as a wrapper around the original res_nquery(). For the other two functions and the other one (trspping TRYAGAIN) seems perfectly suitable to be implemented in 2. i don't completely understand what is the additional functionality in the resolver functions. You mention a 'query order problem' but i don't exactly understand what it is and how the functional change is implemented. thanks luigi --x+6KMIRAuhnl3hBn Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="resolv-ubwp.diff" Index: resolv/res_private.h =================================================================== RCS file: /home/ncvs/src/lib/libc/resolv/res_private.h,v retrieving revision 1.1.1.2 diff -u -w -b -p -r1.1.1.2 res_private.h --- resolv/res_private.h 3 Jun 2007 17:02:28 -0000 1.1.1.2 +++ resolv/res_private.h 8 Nov 2008 14:29:00 -0000 @@ -14,9 +14,21 @@ struct __res_state_ext { char nsuffix2[64]; }; +struct res_target { + struct res_target *next; + const char *name; /* domain name */ + int qclass, qtype; /* class and type of query */ + u_char *answer; /* buffer to put answer */ + int anslen; /* size of answer buffer */ + int n; /* result length */ +}; + extern int res_ourserver_p(const res_state statp, const struct sockaddr *sa); +extern int +__res_nsearchN(res_state, const char *, struct res_target *); + #endif /*! \file */ Index: resolv/res_query.c =================================================================== RCS file: /home/ncvs/src/lib/libc/resolv/res_query.c,v retrieving revision 1.5 diff -u -w -b -p -r1.5 res_query.c --- resolv/res_query.c 3 Jun 2007 17:20:27 -0000 1.5 +++ resolv/res_query.c 8 Nov 2008 14:31:50 -0000 @@ -87,6 +87,8 @@ __FBSDID("$FreeBSD: src/lib/libc/resolv/ #include #include "port_after.h" +#include "res_private.h" + /* Options. Leave them on. */ #define DEBUG @@ -96,6 +98,10 @@ __FBSDID("$FreeBSD: src/lib/libc/resolv/ #define MAXPACKET 1024 #endif +static int res_nqueryN(res_state, const char *, struct res_target *); +static int res_nquerydomainN(res_state, const char *, const char *, + struct res_target *); + /*% * Formulate a normal query, send, and await answer. * Returned answer is placed in supplied buffer "answer". @@ -113,10 +119,45 @@ res_nquery(res_state statp, u_char *answer, /*%< buffer to put answer */ int anslen) /*%< size of answer buffer */ { + struct res_target q; + int n; + + memset(&q, 0, sizeof(q)); + q.name = name; + q.qclass = class; + q.qtype = type; + q.answer = answer; + q.anslen = anslen; + n = res_nqueryN(statp, name, &q); + return ((n < 0) ? n : q.n); +} + +static int +res_nqueryN(res_state statp, const char *name, struct res_target *target) +{ u_char buf[MAXPACKET]; - HEADER *hp = (HEADER *) answer; + HEADER *hp; int n; u_int oflags; + struct res_target *t; + int rcode; + int ancount; + + rcode = NOERROR; + ancount = 0; + + for (t = target; t; t = t->next) { + int class, type; + u_char *answer; + int anslen; + + hp = (HEADER *)(void *) t->answer; + + /* make it easier... */ + class = t->qclass; + type = t->qtype; + answer = t->answer; + anslen = t->anslen; oflags = statp->_flags; @@ -154,15 +195,18 @@ again: goto again; } #endif + rcode = hp->rcode; /* record most recent error */ #ifdef DEBUG if (statp->options & RES_DEBUG) printf(";; res_query: send error\n"); #endif - RES_SET_H_ERRNO(statp, TRY_AGAIN); - return (n); + continue; } + if (n > anslen) + hp->rcode = FORMERR; /* XXX not very informative */ if (hp->rcode != NOERROR || ntohs(hp->ancount) == 0) { + rcode = hp->rcode; /* record most recent error */ #ifdef DEBUG if (statp->options & RES_DEBUG) printf(";; rcode = (%s), counts = an:%d ns:%d ar:%d\n", @@ -171,7 +215,16 @@ again: ntohs(hp->nscount), ntohs(hp->arcount)); #endif - switch (hp->rcode) { + continue; + } + + ancount += ntohs(hp->ancount); + + t->n = n; + } + + if (ancount == 0) { + switch (rcode) { case NXDOMAIN: RES_SET_H_ERRNO(statp, HOST_NOT_FOUND); break; @@ -190,7 +243,7 @@ again: } return (-1); } - return (n); + return (ancount); } /*% @@ -206,8 +259,24 @@ res_nsearch(res_state statp, u_char *answer, /*%< buffer to put answer */ int anslen) /*%< size of answer */ { + struct res_target q; + int n; + + memset(&q, 0, sizeof(q)); + q.name = name; + q.qclass = class; + q.qtype = type; + q.answer = answer; + q.anslen = anslen; + n = __res_nsearchN(statp, name, &q); + return ((n < 0) ? n : q.n); +} + +int +__res_nsearchN(res_state statp, const char *name, struct res_target *target) +{ const char *cp, * const *domain; - HEADER *hp = (HEADER *) answer; + HEADER *hp = (HEADER *)(void *) target->answer; char tmp[NS_MAXDNAME]; u_int dots; int trailing_dot, ret, saved_herrno; @@ -226,7 +295,7 @@ res_nsearch(res_state statp, /* If there aren't any dots, it could be a user-level alias. */ if (!dots && (cp = res_hostalias(statp, name, tmp, sizeof tmp))!= NULL) - return (res_nquery(statp, cp, class, type, answer, anslen)); + return (res_nqueryN(statp, cp, target)); /* * If there are enough dots in the name, let's just give it a @@ -235,8 +304,7 @@ res_nsearch(res_state statp, */ saved_herrno = -1; if (dots >= statp->ndots || trailing_dot) { - ret = res_nquerydomain(statp, name, NULL, class, type, - answer, anslen); + ret = res_nquerydomainN(statp, name, NULL, target); if (ret > 0 || trailing_dot) return (ret); if (errno == ECONNREFUSED) { @@ -280,9 +348,7 @@ res_nsearch(res_state statp, if (root_on_list && tried_as_is) continue; - ret = res_nquerydomain(statp, name, *domain, - class, type, - answer, anslen); + ret = res_nquerydomainN(statp, name, *domain, target); if (ret > 0) return (ret); @@ -366,8 +432,7 @@ res_nsearch(res_state statp, */ if ((dots || !searched || (statp->options & RES_NOTLDQUERY) == 0U) && !(tried_as_is || root_on_list)) { - ret = res_nquerydomain(statp, name, NULL, class, type, - answer, anslen); + ret = res_nquerydomainN(statp, name, NULL, target); if (ret > 0) return (ret); } @@ -401,6 +466,23 @@ res_nquerydomain(res_state statp, u_char *answer, /*%< buffer to put answer */ int anslen) /*%< size of answer */ { + struct res_target q; + int n; + + memset(&q, 0, sizeof(q)); + q.name = name; + q.qclass = class; + q.qtype = type; + q.answer = answer; + q.anslen = anslen; + n = res_nquerydomainN(statp, name, domain, &q); + return ((n < 0) ? n : q.n); +} + +static int +res_nquerydomainN(res_state statp, const char *name, const char *domain, + struct res_target *target) +{ char nbuf[MAXDNAME]; const char *longname = nbuf; int n, d; @@ -408,7 +490,8 @@ res_nquerydomain(res_state statp, #ifdef DEBUG if (statp->options & RES_DEBUG) printf(";; res_nquerydomain(%s, %s, %d, %d)\n", - name, domain?domain:"", class, type); + name, domain?domain:"", target->qclass, + target->qtype); #endif if (domain == NULL) { /* @@ -433,9 +516,9 @@ res_nquerydomain(res_state statp, RES_SET_H_ERRNO(statp, NO_RECOVERY); return (-1); } - sprintf(nbuf, "%s.%s", name, domain); + snprintf(nbuf, sizeof(nbuf), "%s.%s", name, domain); } - return (res_nquery(statp, longname, class, type, answer, anslen)); + return (res_nqueryN(statp, longname, target)); } const char * --x+6KMIRAuhnl3hBn-- From owner-freebsd-net@FreeBSD.ORG Sat Nov 8 16:29:25 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 562ED106567A for ; Sat, 8 Nov 2008 16:29:25 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from asuka.mahoroba.org (unknown [IPv6:2001:2f0:104:8010::1]) by mx1.freebsd.org (Postfix) with ESMTP id DD7508FC12 for ; Sat, 8 Nov 2008 16:29:24 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from kasuga.mahoroba.org (IDENT:uo7fobof0bKF250tFLCQcke7FGiwukNwBYa1Jw1+TFFFA47ZhHVJ6g4PIgfdP8Ac@kasuga.mahoroba.org [IPv6:2001:2f0:104:8010:20b:97ff:fe2e:b521]) (user=ume mech=CRAM-MD5 bits=0) by asuka.mahoroba.org (8.14.3/8.14.3) with ESMTP/inet6 id mA8GTGE5018336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 9 Nov 2008 01:29:18 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Sun, 09 Nov 2008 01:29:15 +0900 Message-ID: From: Hajimu UMEMOTO To: Luigi Rizzo In-Reply-To: <20081108151023.GA72747@onelab2.iet.unipi.it> References: <20081106192103.GA46651@onelab2.iet.unipi.it> <20081108151023.GA72747@onelab2.iet.unipi.it> User-Agent: xcite1.57> Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.7 Emacs/22.2 (i386-pc-freebsd) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 7.1-PRERELEASE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (asuka.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Sun, 09 Nov 2008 01:29:18 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on asuka.mahoroba.org Cc: net@freebsd.org Subject: Re: Two copies of resolver routines in libc ? 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: Sat, 08 Nov 2008 16:29:25 -0000 Hi, >>>>> On Sat, 8 Nov 2008 16:10:23 +0100 >>>>> Luigi Rizzo said: rizzo> thanks for the answer and the effort for merging back the two copies. rizzo> I am looking at your proposed patch but i am not sure i understand it fully, rizzo> so i would be grateful if you could explain me a few things (btw i rizzo> am attaching a version of your patch constructed with 'diff -ubwp' rizzo> and couple of formatting changes to remove whitespace differences; rizzo> this should make the actual changes more evident): Yes, I did 'diff -ubwp' to check during making this patch. :-) rizzo> 1. i apologize for my ignorance, but i suppose there is a binding rizzo> between __res_nsearchN() and res_nsearchN(), and the same rizzo> for all function with and without the two leading __ . Where rizzo> is this binding established, as i don't see anything in the rizzo> diff that you sent. The function with leading `__' is libc internal function. Since, we need to call res_searchN() from getaddrinfo.c, I couldn't make it static. So, I renamed res_searchN() to __res_nsearchN(). The rest (res_queryN() and res_nquerydomainN()) are not called from outside of res_query.c. So, I made them static without leading `__'. rizzo> 2. res_*() now become wrappers around the newly introduced res_*N() rizzo> functions. While this approach removes the duplication, it does rizzo> not address the "ease further merge from ISC BIND" case, which rizzo> definitely sounded as a valid concern. Yes, it is annoying thing. The differences in res_nsearch() and res_nquerydomain() are trivial. But, res_nquery() is bit complicate. However, the diff is trivial with `diff -bw', as you did. I think it confuses us that there are two copies of the resolver functions, too. However, I'm not sure which is better merging the two or leaving it as it is. rizzo> So i wonder, what is it that prevents you from acting the other rizzo> way around, i.e. build the res_*N() around the existing res_*() rizzo> functions ? This way the original ISC code would really be rizzo> unmodified and perhaps the change would be even more confined. Unfortunately, it is impossible. We need to have `for loop' in res_nquery() to solve the query order problem. It is the reason to have a copy in getaddrinfo.c. rizzo> Does this constraint apply to all three functions (res_query, res_search, rizzo> res_nquerydomain) or only for a subset of them ? Yes, this constraint apply to all three functions. Since, the res_nquerydomain() and res_nsearch() call res_nquery(), we need to have the modified version of them to change to call res_nqueryN(). rizzo> From what i can tell, at least in res_nquery() rizzo> the only significant change seems to be the following rizzo> + if (n > anslen) rizzo> + hp->rcode = FORMERR; /* XXX not very informative */ rizzo> other than that it seems perfectly fine to implement res_nqueryN() rizzo> as a wrapper around the original res_nquery(). It is a check for buffer overflow vulnerability. At a later time, we enlarged the buffers for answer in netdb functions. So, perhaps, this check became useless. But, I leaved it as it is for safety. rizzo> For the other two functions rizzo> and the other one (trspping TRYAGAIN) seems perfectly suitable to rizzo> be implemented in rizzo> 2. i don't completely understand what is the additional functionality rizzo> in the resolver functions. You mention a 'query order problem' rizzo> but i don't exactly understand what it is and how the functional rizzo> change is implemented. As basic use of the resolver to query AAAA RR and A RR, the query order is: 1) Call res_nquery(hostname, T_A) for A RR 2) Call res_nquery(hostname, T_AAAA) for AAAA RR With regard of domain name completion and sort_list. Imagine querying hosta with example.org and example.com in search list. The query order will be: 1) Call res_nquery(hosta, T_A) Query T_A RR for hosta 2) Call res_nquery(hosta.example.org, T_A) Query T_A RR for hosta.example.org 3) Call res_nquery(hosta.example.com, T_A) Query T_A RR for hosta.example.com 4) Call res_nquery(hosta, T_AAAA) Query AAAA RR for hosta 5) Call res_nquery(hosta.example.org, T_AAAA) Query T_AAAA RR for hosta.example.org 6) Call res_nquery(hosta.example.com, T_AAAA) Query T_AAAA RR for hosta.example.com It may cause the problem where either example.org or example.com cannot reply correctly. With the change, the query order will be: 1) Call res_nqueryN(hosta, T_A and T_AAAA) Query T_A RR for hosta Query AAAA RR for hosta Query T_A RR for hosta.example.org Query T_AAAA RR for hosta.example.org Query T_A RR for hosta.example.com Query T_AAAA RR for hosta.example.com Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-net@FreeBSD.ORG Sat Nov 8 16:38:05 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4471106567F for ; Sat, 8 Nov 2008 16:38:05 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from asuka.mahoroba.org (unknown [IPv6:2001:2f0:104:8010::1]) by mx1.freebsd.org (Postfix) with ESMTP id 2E3958FC27 for ; Sat, 8 Nov 2008 16:38:04 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from kasuga.mahoroba.org (IDENT:vvWgLIG5yJUSmgXytHZExhyU4XJYfCsQEPspPjjQIXCnQVSJzD3ypYpz+KNtA8sb@kasuga.mahoroba.org [IPv6:2001:2f0:104:8010:20b:97ff:fe2e:b521]) (user=ume mech=CRAM-MD5 bits=0) by asuka.mahoroba.org (8.14.3/8.14.3) with ESMTP/inet6 id mA8Gbw5e090941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 9 Nov 2008 01:37:58 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Sun, 09 Nov 2008 01:37:58 +0900 Message-ID: From: Hajimu UMEMOTO To: Luigi Rizzo In-Reply-To: References: <20081106192103.GA46651@onelab2.iet.unipi.it> <20081108151023.GA72747@onelab2.iet.unipi.it> User-Agent: xcite1.57> Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.7 Emacs/22.2 (i386-pc-freebsd) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 7.1-PRERELEASE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (asuka.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Sun, 09 Nov 2008 01:37:59 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on asuka.mahoroba.org Cc: net@freebsd.org Subject: Re: Two copies of resolver routines in libc ? 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: Sat, 08 Nov 2008 16:38:05 -0000 Hi, >>>>> On Sun, 09 Nov 2008 01:29:15 +0900 >>>>> Hajimu UMEMOTO said: ume> It may cause the problem where either example.org or example.com ume> cannot reply correctly. ume> With the change, the query order will be: ume> 1) Call res_nqueryN(hosta, T_A and T_AAAA) ume> Query T_A RR for hosta ume> Query AAAA RR for hosta ume> Query T_A RR for hosta.example.org ume> Query T_AAAA RR for hosta.example.org ume> Query T_A RR for hosta.example.com ume> Query T_AAAA RR for hosta.example.com Oops, it would be: 1) Call res_nqueryN(hosta, T_A and T_AAAA) Query T_A RR for hosta Query AAAA RR for hosta 2) Call res_nqueryN(hosta.example.org, T_A and T_AAAA) Query T_A RR for hosta.example.org Query T_AAAA RR for hosta.example.org 3) Call res_nqueryN(hosta.example.com, T_A and T_AAAA) Query T_A RR for hosta.example.com Query T_AAAA RR for hosta.example.com Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/