From owner-freebsd-net@FreeBSD.ORG Sun Dec 31 00:53:26 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 82C4E16A40F for ; Sun, 31 Dec 2006 00:53:26 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outY.internet-mail-service.net (outY.internet-mail-service.net [216.240.47.248]) by mx1.freebsd.org (Postfix) with ESMTP id 673A013C457 for ; Sun, 31 Dec 2006 00:53:24 +0000 (UTC) (envelope-from julian@elischer.org) Received: from shell.idiom.com (HELO idiom.com) (216.240.47.20) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Sat, 30 Dec 2006 16:36:06 -0800 Received: from [192.168.2.4] (home.elischer.org [216.240.48.38]) by idiom.com (8.12.11/8.12.11) with ESMTP id kBV0rJnv016283; Sat, 30 Dec 2006 16:53:21 -0800 (PST) (envelope-from julian@elischer.org) Message-ID: <459709FF.30205@elischer.org> Date: Sat, 30 Dec 2006 16:53:19 -0800 From: Julian Elischer User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Yar Tikhiy References: <457DCD47.5090004@elischer.org> <200612120045.41425.max@love2party.net> <4583119B.20608@elischer.org> <200612160446.02644.max@love2party.net> <4584CE0C.3020307@elischer.org> <458C426A.9060604@elischer.org> <20061224093951.GD49045@comp.chem.msu.su> <459032EA.1030601@elischer.org> <20061226061610.GD81280@comp.chem.msu.su> <4591A2D3.50708@elischer.org> <20061230173053.GB94532@comp.chem.msu.su> In-Reply-To: <20061230173053.GB94532@comp.chem.msu.su> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Max Laier , Andre Oppermann , freebsd-net@freebsd.org Subject: Re: [was] addition to ipfw (read vlans from bridge).. 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, 31 Dec 2006 00:53:26 -0000 Yar Tikhiy wrote: > However, I have one question regarding "etype", please see below. > >> Index: netinet/ip_fw2.c >> + /* >> + * if we have an ether header, >> + */ >> + if (args->eh) >> + etype = (ntohs(args->eh->ether_type)) == ETHERTYPE_VLAN; > > And here we assign a boolean value to etype. Is it intended? > Looks like a error to me. Apparently it should read: > > etype = ntohs(args->eh->ether_type); > good catch! From owner-freebsd-net@FreeBSD.ORG Sun Dec 31 19:09:53 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7E6A416A415 for ; Sun, 31 Dec 2006 19:09:53 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outF.internet-mail-service.net (outF.internet-mail-service.net [216.240.47.229]) by mx1.freebsd.org (Postfix) with ESMTP id 5DA3713C43E for ; Sun, 31 Dec 2006 19:09:53 +0000 (UTC) (envelope-from julian@elischer.org) Received: from shell.idiom.com (HELO idiom.com) (216.240.47.20) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Sun, 31 Dec 2006 10:52:29 -0800 Received: from [192.168.2.4] (home.elischer.org [216.240.48.38]) by idiom.com (8.12.11/8.12.11) with ESMTP id kBVJ9nXW082192; Sun, 31 Dec 2006 11:09:50 -0800 (PST) (envelope-from julian@elischer.org) Message-ID: <45980AFD.6010902@elischer.org> Date: Sun, 31 Dec 2006 11:09:49 -0800 From: Julian Elischer User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Yar Tikhiy References: <457DCD47.5090004@elischer.org> <200612120045.41425.max@love2party.net> <4583119B.20608@elischer.org> <200612160446.02644.max@love2party.net> <4584CE0C.3020307@elischer.org> <458C426A.9060604@elischer.org> <20061224093951.GD49045@comp.chem.msu.su> <459032EA.1030601@elischer.org> <20061226061610.GD81280@comp.chem.msu.su> <4591A2D3.50708@elischer.org> <20061230173053.GB94532@comp.chem.msu.su> In-Reply-To: <20061230173053.GB94532@comp.chem.msu.su> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Max Laier , Andre Oppermann , freebsd-net@freebsd.org Subject: Re: [was] addition to ipfw (read vlans from bridge).. 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, 31 Dec 2006 19:09:53 -0000 Yar Tikhiy wrote: > > However, I have one question regarding "etype", please see below. > [...] >> >> + /* >> + * if we have an ether header, >> + */ >> + if (args->eh) >> + etype = (ntohs(args->eh->ether_type)) == ETHERTYPE_VLAN; > > And here we assign a boolean value to etype. Is it intended? > Looks like a error to me. Apparently it should read: > > etype = ntohs(args->eh->ether_type); exactly.. cut-n-paste-o > > But some processing of the (etype == ETHERTYPE_VLAN) case may be > missing here. ipfw should not really be interested in the VLAN case with these changes. From owner-freebsd-net@FreeBSD.ORG Sun Dec 31 20:23:11 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A318216A403; Sun, 31 Dec 2006 20:23:11 +0000 (UTC) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from mail-gw2.york.ac.uk (mail-gw2.york.ac.uk [144.32.128.247]) by mx1.freebsd.org (Postfix) with ESMTP id 41CCD13C44B; Sun, 31 Dec 2006 20:23:10 +0000 (UTC) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from ury.york.ac.uk (ury.york.ac.uk [144.32.108.81]) by mail-gw2.york.ac.uk (8.13.6/8.13.6) with ESMTP id kBVKN78e012129; Sun, 31 Dec 2006 20:23:07 GMT Received: from ury.york.ac.uk (localhost.york.ac.uk [127.0.0.1]) by ury.york.ac.uk (8.13.8/8.13.8) with ESMTP id kBVKN6ib073468; Sun, 31 Dec 2006 20:23:06 GMT (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from localhost (gavin@localhost) by ury.york.ac.uk (8.13.8/8.13.8/Submit) with ESMTP id kBVKN2GY073435; Sun, 31 Dec 2006 20:23:06 GMT (envelope-from gavin.atkinson@ury.york.ac.uk) X-Authentication-Warning: ury.york.ac.uk: gavin owned process doing -bs Date: Sun, 31 Dec 2006 20:23:02 +0000 (GMT) From: Gavin Atkinson X-X-Sender: gavin@ury.york.ac.uk To: Steve Clement In-Reply-To: <4593B7BA.7020803@localhost.lu> Message-ID: <20061231200737.A23766@ury.york.ac.uk> References: <20061225231213.O11113@ury.york.ac.uk> <4593B7BA.7020803@localhost.lu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin.atkinson@ury.york.ac.uk Cc: freebsd-net@freebsd.org, damien.bergamini@free.fr, gabor@freebsd.org Subject: Re: wpi (Intel 3945) driver 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, 31 Dec 2006 20:23:11 -0000 On Thu, 28 Dec 2006, Steve Clement wrote: > It throws quite a lot of 702 errors at me, especially when there is heavy > traffic load! Yes, I need to look into these at some point. > Also I am currently in Berlin at the CCC (events.ccc.de) and the WiFi traffic > is quite heavy and I don't get a packet out to the world (I can sniff the > traffic) but obtaining a dhcp-lease or any other active communication is > impossible. But it works for you when traffic is less busy? > also when I try to unload the driver it wouldn't unload. Does it give any error messages on the console when it fails to unload? > So I did repeatedly: > > kldunload if_wpi > kldunload if_wpi > kldunload if_wpi > kldunload if_wpi > kldunload if_wpi > > and by the fifth time the kernel crashes with a page fault, now I don't know > whether that is a Kernel issue or a driver issue, who handles unload > requests? Without seeing details of the page fault, it's impossible to say. It would be useful if you could compile a kernel, making sure you have the "standard" -CURRENT debugging options: options KDB options DDB options GDB options INVARIANTS options INVARIANT_SUPPORT options WITNESS options WITNESS_SKIPSPIN up the value of wpi_debug on line 79 of if_wpi.c to 3 and recompile the wpi modules as well. I'd need to see anything logged to the console, as well as the output of "tr" when the machine panics and drops to the debugger (digital photos are fine). Gavin From owner-freebsd-net@FreeBSD.ORG Sun Dec 24 09:40:14 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 11EF816A407 for ; Sun, 24 Dec 2006 09:40:14 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.freebsd.org (Postfix) with ESMTP id 105FB13C473 for ; Sun, 24 Dec 2006 09:40:12 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.3) with ESMTP id kBO9dw6r052074; Sun, 24 Dec 2006 12:39:58 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.3/Submit) id kBO9dqHp052070; Sun, 24 Dec 2006 12:39:52 +0300 (MSK) (envelope-from yar) Date: Sun, 24 Dec 2006 12:39:51 +0300 From: Yar Tikhiy To: Julian Elischer Message-ID: <20061224093951.GD49045@comp.chem.msu.su> References: <457DCD47.5090004@elischer.org> <200612120045.41425.max@love2party.net> <4583119B.20608@elischer.org> <200612160446.02644.max@love2party.net> <4584CE0C.3020307@elischer.org> <458C426A.9060604@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <458C426A.9060604@elischer.org> User-Agent: Mutt/1.5.9i Cc: Max Laier , Andre Oppermann , freebsd-net@freebsd.org Subject: Re: [was] addition to ipfw (read vlans from bridge).. 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, 24 Dec 2006 09:40:14 -0000 On Fri, Dec 22, 2006 at 12:39:06PM -0800, Julian Elischer wrote: > > Taking to heart comments by Andre and Max (Laier), > I have redone this patch in a different manner. > > The aim is to be able to see inside vlans when bridging. > Now, this is a 6.x patch to bridge.c because that is what we > are using, but I will make a similar patch to if_bridge.c > for 6 and 7 if this meets with approval. > > > Basically if it is a vlan packet, take off the whole vlan header instead > of just the ether header, but pass to ipfw, an ether header with > the real protocol field substituted in. > when finishing put back everything we removed before. > > > The only addition I'd do to this would be to add a sysctl > to turn it on if people thought it would be break POLA too much > to have it work by default. Excuse me, but I'd like to second Andre's opinion. We should stop fiddling with the mbuf contents in favour of teaching ipfw (or the interface code between bridge and ipfw) of 802.1q (or its generalisation.) Now that the 802.1q VLAN technology has been well integrated in the general Ethernet framework by IEEE, there is very litte sense left in such hacks. If ipfw is to stay L2-agnostic, then let's just pass the offset of the IP header into the mbuf to it. The 802.1q header is so nice and simple and easy to parse at any level. So this patch can be OK in 6.x for the only sake of preserving the pfil ABI, but it should die along with it. An extended interface is apparently called for in HEAD. There is also work in progress to introduce nested VLANs AKA Q-n-Q. They seem to present a challenge to the scheme you are implementing. > Index: bridge.c > =================================================================== > RCS file: /usr/local/cvsroot/freebsd/src/sys/net/Attic/bridge.c,v > retrieving revision 1.93.2.1 > diff -u -r1.93.2.1 bridge.c > --- bridge.c 25 Aug 2005 05:01:19 -0000 1.93.2.1 > +++ bridge.c 22 Dec 2006 20:29:16 -0000 > @@ -103,6 +103,7 @@ > #include > #include /* for struct arpcom */ > #include > +#include > #include > #include > > @@ -932,13 +933,17 @@ > bdg_forward(struct mbuf *m0, struct ifnet *dst) > { > #define EH_RESTORE(_m) do { \ > - M_PREPEND((_m), ETHER_HDR_LEN, M_DONTWAIT); \ > + M_PREPEND((_m), has_vlan_hdr? sizeof(evl):ETHER_HDR_LEN, M_DONTWAIT); \ > if ((_m) == NULL) { \ > bdg_dropped++; \ > return NULL; \ > } \ > if (eh != mtod((_m), struct ether_header *)) \ > - bcopy(&save_eh, mtod((_m), struct ether_header *), ETHER_HDR_LEN); \ > + if (has_vlan_hdr) { \ > + bcopy(&save_eh, mtod((_m), struct ether_header *), ETHER_HDR_LEN); \ > + } else { \ > + bcopy(&evl, mtod((_m), struct ether_header *), sizeof(evl)); \ > + } \ > else \ > bdg_predict++; \ > } while (0); > @@ -949,6 +954,8 @@ > int error; > struct ifnet *real_dst = dst; /* real dst from ether_output */ > struct ip_fw_args args; > + int has_vlan_hdr; > + struct ether_vlan_header evl; > struct ether_header save_eh; > struct mbuf *m; > > @@ -1022,9 +1029,21 @@ > * Furthermore, the mbuf chain might be replaced at various > * places. To deal with this we copy the header to a temporary > * location, strip the header, and restore it as needed. > + * If we have a vlan header we need to synthesize the > + * encapsulated ether header and instead store the vlan header > + * for replacement later. > */ > - bcopy(eh, &save_eh, ETHER_HDR_LEN); /* local copy for restore */ > - m_adj(m0, ETHER_HDR_LEN); /* temporarily strip header */ > + if (eh->ether_type == ETHERTYPE_VLAN) { > + bcopy(eh, &evl, sizeof(evl)); /* local copy for restore */ > + bcopy(eh, &save_eh, ETHER_HDR_LEN); /* what is passed to ipfw */ > + save_eh.ether_type = evl.evl_proto; /* but with the final proto */ > + has_vlan_hdr = 1; > + m_adj(m0, sizeof(evl)); /* temporarily strip header */ > + } else { > + bcopy(eh, &save_eh, ETHER_HDR_LEN); /* local copy for restore */ > + has_vlan_hdr = 0; > + m_adj(m0, ETHER_HDR_LEN); /* temporarily strip header */ > + } > > /* > * Check that the IP header is aligned before passing up to the packet > _______________________________________________ > 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" -- Yar From owner-freebsd-net@FreeBSD.ORG Mon Dec 25 05:13:04 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5CA6416A40F for ; Mon, 25 Dec 2006 05:13:04 +0000 (UTC) (envelope-from boris@ntmk.ru) Received: from mail.ntmk.ru (mail.ntmk.ru [217.114.241.6]) by mx1.freebsd.org (Postfix) with ESMTP id 13C2913C46E for ; Mon, 25 Dec 2006 05:13:04 +0000 (UTC) (envelope-from boris@ntmk.ru) Received: from boris.nikom.ru ([10.1.16.195]) by mail.ntmk.ru with esmtp (Exim 4.62) (envelope-from ) id 1GygvW-0001bQ-8q; Mon, 25 Dec 2006 08:55:02 +0500 Message-ID: <458F4B96.1060400@ntmk.ru> Date: Mon, 25 Dec 2006 08:55:02 +0500 From: Boris Kovalenko User-Agent: Thunderbird 1.5.0.9 (X11/20061221) MIME-Version: 1.0 To: Gloomy Group , freebsd-net@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit Cc: Subject: Re: FreeBSD PPPoE server and IP Conflict 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, 25 Dec 2006 05:13:04 -0000 Hello! This is a know feature, You should use net.inet.ip.same_prefix_carp_only=1 to avoid this. Unfortunatelly can't remember in what version of FreeBSD this one was introduced and fixed. > Hi list, > > > I have setup freebsd pppoe server in 6.0. My ppp.conf server is as > follows. Problem I have been facing is server assigns the same ip > address to the two different clients and the clients IP get conflicted. > I have followed WARTA project papers to do the bandwidth shaping for > pppoe server (http://www.hpi.net/whitepapers/warta/) > > Can anybody tell my why freebsd pppoe server assign > to same ip address for different clients. > Like when user "abc" connect he get 192.168.2.10 IP and when > another user connect at the same time he also gets the same ip address > i.e. 192.168.2.10. Any suggestion for freebsd pppoe server with radius > authentication. > > default: > enable lqr > set lqrperiod 5 > enable echo > enable lqr echo > enable pap > #allow users > allow mode direct > set mru 1480 > set mtu 1480 > set timeout 7200 > set speed sync > set ifaddr 202.xx.xx.xxx 202.xx.xx.1-202.xx.xx.254 > set radius /etc/radius.conf > accept dns > > _________________________________________________________________ > Dave vs. Carl: The Insignificant Championship Series.  Who will win? > http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/direct/01/?href=http://davevscarl.spaces.live.com/?icid=T001MSN38C07001 > > > _______________________________________________ > 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" > > -- With respect, Boris From owner-freebsd-net@FreeBSD.ORG Mon Dec 25 11:08:45 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 66C6A16A582 for ; Mon, 25 Dec 2006 11:08:45 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 5305313C48B for ; Mon, 25 Dec 2006 11:08:45 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id kBPB8jJ3034618 for ; Mon, 25 Dec 2006 11:08:45 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id kBPB8iON034614 for freebsd-net@FreeBSD.org; Mon, 25 Dec 2006 11:08:44 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 25 Dec 2006 11:08:44 GMT Message-Id: <200612251108.kBPB8iON034614@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: linimon set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to you 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, 25 Dec 2006 11:08:45 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- a kern/38554 net changing interface ipaddress doesn't seem to work s kern/39937 net ipstealth issue o kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/95665 net [if_tun] "ping: sendto: No buffer space available" wit o kern/106722 net [net] [patch] ifconfig may not connect an interface to 5 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- s kern/19875 net A new protocol family, PF_IPOPTION, to handle IP optio o conf/23063 net [PATCH] for static ARP tables in rc.network s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s kern/60293 net FreeBSD arp poison patch o kern/95267 net packet drops periodically appear f kern/95277 net [netinet] IP Encapsulation mask_match() returns wrong o kern/102035 net [plip] plip networking disables parallel port printing o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o kern/106999 net [netgraph] [patch] ng_ksocket fails to clear multicast 10 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Dec 25 20:02:06 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8FAAA16A416 for ; Mon, 25 Dec 2006 20:02:06 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outH.internet-mail-service.net (outH.internet-mail-service.net [216.240.47.231]) by mx1.freebsd.org (Postfix) with ESMTP id 6F19C13C478 for ; Mon, 25 Dec 2006 20:02:06 +0000 (UTC) (envelope-from julian@elischer.org) Received: from shell.idiom.com (HELO idiom.com) (216.240.47.20) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Mon, 25 Dec 2006 11:45:22 -0800 Received: from [192.168.2.4] (home.elischer.org [216.240.48.38]) by idiom.com (8.12.11/8.12.11) with ESMTP id kBPK0D9i085929; Mon, 25 Dec 2006 12:00:40 -0800 (PST) (envelope-from julian@elischer.org) Message-ID: <45902DC5.6030101@elischer.org> Date: Mon, 25 Dec 2006 12:00:05 -0800 From: Julian Elischer User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Kevin Sanders References: <1166802209.7642.17.camel@hades.no-ip.org> <20061222160550.GD47710@lor.one-eyed-alien.net> <375baf50612220932m30f84567jdda28b7fc0e62e61@mail.gmail.com> <458C6ACC.2020605@elischer.org> <458C6CDF.4010203@elischer.org> <375baf50612230855o114c4c32gff314327a0b8a05b@mail.gmail.com> In-Reply-To: <375baf50612230855o114c4c32gff314327a0b8a05b@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Fabr?cio Barros Cabral Subject: Re: Intercepting a packet, changing it and re-injecting into the network 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, 25 Dec 2006 20:02:06 -0000 Kevin Sanders wrote: > On 12/22/06, Julian Elischer wrote: >> >> >> just as a reference point, >> Using ipfw I was able to saturate a Gb bridge >> (between 2 bge interfaces) while filtereing against a >> table of 128000 addresses. (in FreeBSD 4.8) using 30% cpu.. >> machines have gotten faster since then but the OS has slowed a bit. >> > > That's what I'm looking for. Were you using polling or any non-default HZ > setting for that? Thanks. > > Kevin > _______________________________________________ > 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" it was 4.11 remember but I had no nonstandard settings. We've moved to 6.1 but I have not repeated the tests yet. From owner-freebsd-net@FreeBSD.ORG Mon Dec 25 20:47:54 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E0BE616A415 for ; Mon, 25 Dec 2006 20:47:54 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outF.internet-mail-service.net (outF.internet-mail-service.net [216.240.47.229]) by mx1.freebsd.org (Postfix) with ESMTP id B326D13C47A for ; Mon, 25 Dec 2006 20:47:54 +0000 (UTC) (envelope-from julian@elischer.org) Received: from shell.idiom.com (HELO idiom.com) (216.240.47.20) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Mon, 25 Dec 2006 12:31:17 -0800 Received: from [192.168.2.4] (home.elischer.org [216.240.48.38]) by idiom.com (8.12.11/8.12.11) with ESMTP id kBPKMABj007699; Mon, 25 Dec 2006 12:22:35 -0800 (PST) (envelope-from julian@elischer.org) Message-ID: <459032EA.1030601@elischer.org> Date: Mon, 25 Dec 2006 12:22:02 -0800 From: Julian Elischer User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Yar Tikhiy References: <457DCD47.5090004@elischer.org> <200612120045.41425.max@love2party.net> <4583119B.20608@elischer.org> <200612160446.02644.max@love2party.net> <4584CE0C.3020307@elischer.org> <458C426A.9060604@elischer.org> <20061224093951.GD49045@comp.chem.msu.su> In-Reply-To: <20061224093951.GD49045@comp.chem.msu.su> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Max Laier , Andre Oppermann , freebsd-net@freebsd.org Subject: Re: [was] addition to ipfw (read vlans from bridge).. 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, 25 Dec 2006 20:47:55 -0000 Yar Tikhiy wrote: > On Fri, Dec 22, 2006 at 12:39:06PM -0800, Julian Elischer wrote: >> Taking to heart comments by Andre and Max (Laier), >> I have redone this patch in a different manner. >> >> The aim is to be able to see inside vlans when bridging. >> Now, this is a 6.x patch to bridge.c because that is what we >> are using, but I will make a similar patch to if_bridge.c >> for 6 and 7 if this meets with approval. >> >> >> Basically if it is a vlan packet, take off the whole vlan header instead >> of just the ether header, but pass to ipfw, an ether header with >> the real protocol field substituted in. >> when finishing put back everything we removed before. >> >> >> The only addition I'd do to this would be to add a sysctl >> to turn it on if people thought it would be break POLA too much >> to have it work by default. > > Excuse me, but I'd like to second Andre's opinion. We should stop > fiddling with the mbuf contents in favour of teaching ipfw (or the > interface code between bridge and ipfw) of 802.1q (or its > generalisation.) Now that the 802.1q VLAN technology has been well > integrated in the general Ethernet framework by IEEE, there is very > litte sense left in such hacks. If ipfw is to stay L2-agnostic, > then let's just pass the offset of the IP header into the mbuf to > it. The 802.1q header is so nice and simple and easy to parse at > any level. So this patch can be OK in 6.x for the only sake of > preserving the pfil ABI, but it should die along with it. An > extended interface is apparently called for in HEAD. You are the one who complained that it should not be done in ipfw, and that we should do it the same way we currently handled the removal and re-addition of the ethernet header. So that's what I did. (in the bridge code), by teaching the ethernet header handling code to handle vlan tags as well. If what you are suggesting is that we pass into ipfw an 'offset' into the packet as well as the packet, then yes I like that idea, but I didn't see Andre suggest it. I can however submit another patch that does that.. However I'd like to hear from you a response to the mail I sent you with a pure cleanup patch that removes mopst occurrances of mtod() from ipfw.. if you did not get that email I can resend it to you. > > There is also work in progress to introduce nested VLANs AKA Q-n-Q. > They seem to present a challenge to the scheme you are implementing. not a permanent problem.. it could be modified to handle it. but I'll take it into account in the next version if you think it is a required feature.. what is the maximum nesting level? From owner-freebsd-net@FreeBSD.ORG Mon Dec 25 21:40:37 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 818FA16A403 for ; Mon, 25 Dec 2006 21:40:37 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.179]) by mx1.freebsd.org (Postfix) with ESMTP id 0E1B013C47C for ; Mon, 25 Dec 2006 21:40:37 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.66.33.103] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis), id 0ML25U-1GyxYB19bX-0001Qf; Mon, 25 Dec 2006 22:40:06 +0100 From: Max Laier Organization: FreeBSD To: Julian Elischer Date: Mon, 25 Dec 2006 22:39:51 +0100 User-Agent: KMail/1.9.4 References: <457DCD47.5090004@elischer.org> <20061224093951.GD49045@comp.chem.msu.su> <459032EA.1030601@elischer.org> In-Reply-To: <459032EA.1030601@elischer.org> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1706852.BfUdVVsOLA"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200612252239.59737.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: Yar Tikhiy , Andre Oppermann , freebsd-net@freebsd.org Subject: Re: [was] addition to ipfw (read vlans from bridge).. 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, 25 Dec 2006 21:40:37 -0000 --nextPart1706852.BfUdVVsOLA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 25 December 2006 21:22, Julian Elischer wrote: > Yar Tikhiy wrote: > > On Fri, Dec 22, 2006 at 12:39:06PM -0800, Julian Elischer wrote: > >> Taking to heart comments by Andre and Max (Laier), > >> I have redone this patch in a different manner. > >> > >> The aim is to be able to see inside vlans when bridging. > >> Now, this is a 6.x patch to bridge.c because that is what we > >> are using, but I will make a similar patch to if_bridge.c > >> for 6 and 7 if this meets with approval. > >> > >> > >> Basically if it is a vlan packet, take off the whole vlan header > >> instead of just the ether header, but pass to ipfw, an ether header > >> with the real protocol field substituted in. > >> when finishing put back everything we removed before. > >> > >> > >> The only addition I'd do to this would be to add a sysctl > >> to turn it on if people thought it would be break POLA too much > >> to have it work by default. > > > > Excuse me, but I'd like to second Andre's opinion. We should stop > > fiddling with the mbuf contents in favour of teaching ipfw (or the > > interface code between bridge and ipfw) of 802.1q (or its > > generalisation.) Now that the 802.1q VLAN technology has been well > > integrated in the general Ethernet framework by IEEE, there is very > > litte sense left in such hacks. If ipfw is to stay L2-agnostic, > > then let's just pass the offset of the IP header into the mbuf to > > it. The 802.1q header is so nice and simple and easy to parse at > > any level. So this patch can be OK in 6.x for the only sake of > > preserving the pfil ABI, but it should die along with it. An > > extended interface is apparently called for in HEAD. > > You are the one who complained that it should not be done in ipfw, > and that we should do it the same way we currently handled the > removal and re-addition of the ethernet header. So that's what I did. > (in the bridge code), by teaching the ethernet header handling code > to handle vlan tags as well. I'm not sure if you are mistaking Yar for me here. As for my concerns -=20 consider them withdrawn. I still don't like the idea that the code in=20 net*inet*/ip_fw2.c gets to know about VLAN internals, but if everybody=20 feels that it does belong there - fine. I hereby resign from this=20 thread. Anyway, I hope everybody is having happy holidays. > If what you are suggesting is that we pass into ipfw an 'offset' > into the packet as well as the packet, then yes I like that idea, > but I didn't see Andre suggest it. > > I can however submit another patch that does that.. > > However I'd like to hear from you a response to the mail > I sent you with a pure cleanup patch that removes mopst occurrances > of mtod() from ipfw.. if you did not get that email I can resend it > to you. > > > There is also work in progress to introduce nested VLANs AKA Q-n-Q. > > They seem to present a challenge to the scheme you are implementing. > > not a permanent problem.. it could be modified to handle it. > but I'll take it into account in the next version if > you think it is a required feature.. what is the maximum > nesting level? =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1706852.BfUdVVsOLA Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBFkEUvXyyEoT62BG0RApkcAJ9E1S63eP7DqN+3zZwRl7Ge4wY6cgCfeFDR 9LuTd4M+g+6WLSRMdIqSVR0= =sx1w -----END PGP SIGNATURE----- --nextPart1706852.BfUdVVsOLA-- From owner-freebsd-net@FreeBSD.ORG Mon Dec 25 23:52:58 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B33A916A40F for ; Mon, 25 Dec 2006 23:52:58 +0000 (UTC) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from mail-gw0.york.ac.uk (mail-gw0.york.ac.uk [144.32.128.245]) by mx1.freebsd.org (Postfix) with ESMTP id 547D713C494 for ; Mon, 25 Dec 2006 23:52:58 +0000 (UTC) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from ury.york.ac.uk (ury.york.ac.uk [144.32.108.81]) by mail-gw0.york.ac.uk (8.13.6/8.13.6) with ESMTP id kBPNKvhD010168 for ; Mon, 25 Dec 2006 23:20:57 GMT Received: from ury.york.ac.uk (localhost.york.ac.uk [127.0.0.1]) by ury.york.ac.uk (8.13.8/8.13.8) with ESMTP id kBPNKvqo048549 for ; Mon, 25 Dec 2006 23:20:57 GMT (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from localhost (gavin@localhost) by ury.york.ac.uk (8.13.8/8.13.8/Submit) with ESMTP id kBPNKurl048546 for ; Mon, 25 Dec 2006 23:20:57 GMT (envelope-from gavin.atkinson@ury.york.ac.uk) X-Authentication-Warning: ury.york.ac.uk: gavin owned process doing -bs Date: Mon, 25 Dec 2006 23:20:56 +0000 (GMT) From: Gavin Atkinson X-X-Sender: gavin@ury.york.ac.uk To: freebsd-net@freebsd.org Message-ID: <20061225231213.O11113@ury.york.ac.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin.atkinson@ury.york.ac.uk Subject: wpi (Intel 3945) driver 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, 25 Dec 2006 23:52:58 -0000 Hi all, Is anybody actively developing this driver? I've been debugging it for the last day or two and am now at the point where it's pretty stable for me (at least, I no longer get deadlocks and the issue of the firmware getting confused seems resolved). I have a load of other changes I intend to make, and a few bits which would be nice to merge in from the OpenBSD driver, but obviously I don't want to continue doing this if somebody else has done any work on it. If nobody has, then I'm happy to take up the job of centrally co-ordinating patches, with a view to getting the driver to the point where it could be merged into the main FreeBSD tree. I'm already keeping my changes in my local CVS repo... Gavin From owner-freebsd-net@FreeBSD.ORG Tue Dec 26 00:33:22 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3FF7016A40F for ; Tue, 26 Dec 2006 00:33:22 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.t-hosting.hu (server.t-hosting.hu [217.20.133.7]) by mx1.freebsd.org (Postfix) with ESMTP id F110913C46F for ; Tue, 26 Dec 2006 00:33:21 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by server.t-hosting.hu (Postfix) with ESMTP id 46BF19BFC24; Tue, 26 Dec 2006 01:01:28 +0100 (CET) X-Virus-Scanned: amavisd-new at t-hosting.hu Received: from server.t-hosting.hu ([127.0.0.1]) by localhost (server.t-hosting.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ObDJH+zR3yh0; Tue, 26 Dec 2006 01:01:25 +0100 (CET) Received: from [192.168.2.186] (catv-50635cb6.catv.broadband.hu [80.99.92.182]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server.t-hosting.hu (Postfix) with ESMTP id BEC539AE125; Tue, 26 Dec 2006 01:01:24 +0100 (CET) Message-ID: <45906653.4050101@FreeBSD.org> Date: Tue, 26 Dec 2006 01:01:23 +0100 From: Gabor Kovesdan User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Gavin Atkinson References: <20061225231213.O11113@ury.york.ac.uk> In-Reply-To: <20061225231213.O11113@ury.york.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: wpi (Intel 3945) driver 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, 26 Dec 2006 00:33:22 -0000 Gavin Atkinson schrieb: > > Hi all, > > Is anybody actively developing this driver? > > I've been debugging it for the last day or two and am now at the point > where it's pretty stable for me (at least, I no longer get deadlocks > and the issue of the firmware getting confused seems resolved). I > have a load of other changes I intend to make, and a few bits which > would be nice to merge in from the OpenBSD driver, but obviously I > don't want to continue doing this if somebody else has done any work > on it. > > If nobody has, then I'm happy to take up the job of centrally > co-ordinating patches, with a view to getting the driver to the point > where it could be merged into the main FreeBSD tree. I'm already > keeping my changes in my local CVS repo... > > Gavin Hello, I don't have the knowledge to work on it, but I'd like to test your version. I always had allocation issues with a wpi driver that was flying over and over threads and could never get it to work, so I really would like to test your one if you could upload it somewhere. Or I can make a mirror if you don't have the opportunity. Regards, Gabor From owner-freebsd-net@FreeBSD.ORG Tue Dec 26 00:37:08 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4B0EA16A40F for ; Tue, 26 Dec 2006 00:37:08 +0000 (UTC) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from mail-gw0.york.ac.uk (mail-gw0.york.ac.uk [144.32.128.245]) by mx1.freebsd.org (Postfix) with ESMTP id DDB3E13C473 for ; Tue, 26 Dec 2006 00:37:07 +0000 (UTC) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from ury.york.ac.uk (ury.york.ac.uk [144.32.108.81]) by mail-gw0.york.ac.uk (8.13.6/8.13.6) with ESMTP id kBQ0b5Uu012267; Tue, 26 Dec 2006 00:37:05 GMT Received: from ury.york.ac.uk (localhost.york.ac.uk [127.0.0.1]) by ury.york.ac.uk (8.13.8/8.13.8) with ESMTP id kBQ0b4e0077589; Tue, 26 Dec 2006 00:37:04 GMT (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from localhost (gavin@localhost) by ury.york.ac.uk (8.13.8/8.13.8/Submit) with ESMTP id kBQ0b4VD077586; Tue, 26 Dec 2006 00:37:04 GMT (envelope-from gavin.atkinson@ury.york.ac.uk) X-Authentication-Warning: ury.york.ac.uk: gavin owned process doing -bs Date: Tue, 26 Dec 2006 00:37:04 +0000 (GMT) From: Gavin Atkinson X-X-Sender: gavin@ury.york.ac.uk To: Gabor Kovesdan In-Reply-To: <45906653.4050101@FreeBSD.org> Message-ID: <20061226002323.L11113@ury.york.ac.uk> References: <20061225231213.O11113@ury.york.ac.uk> <45906653.4050101@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin.atkinson@ury.york.ac.uk Cc: freebsd-net@FreeBSD.org Subject: Re: wpi (Intel 3945) driver 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, 26 Dec 2006 00:37:08 -0000 On Tue, 26 Dec 2006, Gabor Kovesdan wrote: > I don't have the knowledge to work on it, but I'd like to test your version. > I always had allocation issues with a wpi driver that was flying over and > over threads and could never get it to work, so I really would like to test > your one if you could upload it somewhere. Or I can make a mirror if you > don't have the opportunity. So far I've made no changes that would make a difference to initial attach. I wonder if you could set wpi_debug to 5 (on line 78 of wpi/if_wpi.c) and recompile the module, then: reboot sysctl debug.bootverbose=1 kldload wpi_ucode/wpi_ucode.ko kldload wpi/if_wpi.ko (if that's not enough to demonstrate the problem, recreae it now) and send me all lines that are output (they should make their way to /var/log/messages ), along with the output of pciconf -l Thanks! Gavin From owner-freebsd-net@FreeBSD.ORG Tue Dec 26 04:38:19 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 82B8616A407; Tue, 26 Dec 2006 04:38:19 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.freebsd.org (Postfix) with ESMTP id 9A21113C473; Tue, 26 Dec 2006 04:38:16 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.3) with ESMTP id kBQ4c390000312; Tue, 26 Dec 2006 07:38:03 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.3/Submit) id kBQ4c1kA000311; Tue, 26 Dec 2006 07:38:01 +0300 (MSK) (envelope-from yar) Date: Tue, 26 Dec 2006 07:38:01 +0300 From: Yar Tikhiy To: Max Laier Message-ID: <20061226043800.GC81280@comp.chem.msu.su> References: <457DCD47.5090004@elischer.org> <20061224093951.GD49045@comp.chem.msu.su> <459032EA.1030601@elischer.org> <200612252239.59737.max@love2party.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200612252239.59737.max@love2party.net> User-Agent: Mutt/1.5.9i Cc: freebsd-net@freebsd.org, Andre Oppermann , Julian Elischer Subject: Re: [was] addition to ipfw (read vlans from bridge).. 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, 26 Dec 2006 04:38:19 -0000 On Mon, Dec 25, 2006 at 10:39:51PM +0100, Max Laier wrote: > On Monday 25 December 2006 21:22, Julian Elischer wrote: > > Yar Tikhiy wrote: > > > On Fri, Dec 22, 2006 at 12:39:06PM -0800, Julian Elischer wrote: > > >> Taking to heart comments by Andre and Max (Laier), > > >> I have redone this patch in a different manner. > > >> > > >> The aim is to be able to see inside vlans when bridging. > > >> Now, this is a 6.x patch to bridge.c because that is what we > > >> are using, but I will make a similar patch to if_bridge.c > > >> for 6 and 7 if this meets with approval. > > >> > > >> > > >> Basically if it is a vlan packet, take off the whole vlan header > > >> instead of just the ether header, but pass to ipfw, an ether header > > >> with the real protocol field substituted in. > > >> when finishing put back everything we removed before. > > >> > > >> > > >> The only addition I'd do to this would be to add a sysctl > > >> to turn it on if people thought it would be break POLA too much > > >> to have it work by default. > > > > > > Excuse me, but I'd like to second Andre's opinion. We should stop > > > fiddling with the mbuf contents in favour of teaching ipfw (or the > > > interface code between bridge and ipfw) of 802.1q (or its > > > generalisation.) Now that the 802.1q VLAN technology has been well > > > integrated in the general Ethernet framework by IEEE, there is very > > > litte sense left in such hacks. If ipfw is to stay L2-agnostic, > > > then let's just pass the offset of the IP header into the mbuf to > > > it. The 802.1q header is so nice and simple and easy to parse at > > > any level. So this patch can be OK in 6.x for the only sake of > > > preserving the pfil ABI, but it should die along with it. An > > > extended interface is apparently called for in HEAD. > > > > You are the one who complained that it should not be done in ipfw, > > and that we should do it the same way we currently handled the > > removal and re-addition of the ethernet header. So that's what I did. > > (in the bridge code), by teaching the ethernet header handling code > > to handle vlan tags as well. > > I'm not sure if you are mistaking Yar for me here. As for my concerns - > consider them withdrawn. I still don't like the idea that the code in > net*inet*/ip_fw2.c gets to know about VLAN internals, but if everybody > feels that it does belong there - fine. I hereby resign from this > thread. IMO ipfw should be taught of VLAN internals only if we are going to implement L2 filtering in it. But if not, a simple offset of the IP header computed at the link layer of the stack would do. That would allow for different VLAN or whatever encapsulations as well. -- Yar From owner-freebsd-net@FreeBSD.ORG Tue Dec 26 05:40:42 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3F3A516A403 for ; Tue, 26 Dec 2006 05:40:42 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outT.internet-mail-service.net (outT.internet-mail-service.net [216.240.47.243]) by mx1.freebsd.org (Postfix) with ESMTP id 2029213C481 for ; Tue, 26 Dec 2006 05:40:42 +0000 (UTC) (envelope-from julian@elischer.org) Received: from shell.idiom.com (HELO idiom.com) (216.240.47.20) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Mon, 25 Dec 2006 21:24:02 -0800 Received: from [192.168.2.4] (home.elischer.org [216.240.48.38]) by idiom.com (8.12.11/8.12.11) with ESMTP id kBQ5ebnu007534; Mon, 25 Dec 2006 21:40:38 -0800 (PST) (envelope-from julian@elischer.org) Message-ID: <4590B5D5.6080009@elischer.org> Date: Mon, 25 Dec 2006 21:40:37 -0800 From: Julian Elischer User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Max Laier References: <457DCD47.5090004@elischer.org> <20061224093951.GD49045@comp.chem.msu.su> <459032EA.1030601@elischer.org> <200612252239.59737.max@love2party.net> In-Reply-To: <200612252239.59737.max@love2party.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Yar Tikhiy , Andre Oppermann , freebsd-net@freebsd.org Subject: Re: [was] addition to ipfw (read vlans from bridge).. 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, 26 Dec 2006 05:40:42 -0000 Max Laier wrote: > > I'm not sure if you are mistaking Yar for me here. As for my concerns - > consider them withdrawn. I still don't like the idea that the code in > net*inet*/ip_fw2.c gets to know about VLAN internals, but if everybody > feels that it does belong there - fine. I hereby resign from this > thread. > In the latest patch it doesn't.. The only knowledge of vlans is added to if_bridge.c and bridge.c (in 6.x) > Anyway, I hope everybody is having happy holidays. not bad.. > >> If what you are suggesting is that we pass into ipfw an 'offset' >> into the packet as well as the packet, then yes I like that idea, >> but I didn't see Andre suggest it. >> >> I can however submit another patch that does that.. >> >> However I'd like to hear from you a response to the mail >> I sent you with a pure cleanup patch that removes mopst occurrances >> of mtod() from ipfw.. if you did not get that email I can resend it >> to you. you are right max.. I sent the email to you not Yar.. it was just a cleanup patch. >> >>> There is also work in progress to introduce nested VLANs AKA Q-n-Q. >>> They seem to present a challenge to the scheme you are implementing. >> not a permanent problem.. it could be modified to handle it. >> but I'll take it into account in the next version if >> you think it is a required feature.. what is the maximum >> nesting level? > From owner-freebsd-net@FreeBSD.ORG Tue Dec 26 06:16:24 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2384916A407; Tue, 26 Dec 2006 06:16:24 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.freebsd.org (Postfix) with ESMTP id 3176913C46D; Tue, 26 Dec 2006 06:16:22 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.3) with ESMTP id kBQ6GBJC001911; Tue, 26 Dec 2006 09:16:12 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.3/Submit) id kBQ6GBPF001910; Tue, 26 Dec 2006 09:16:11 +0300 (MSK) (envelope-from yar) Date: Tue, 26 Dec 2006 09:16:11 +0300 From: Yar Tikhiy To: Julian Elischer Message-ID: <20061226061610.GD81280@comp.chem.msu.su> References: <457DCD47.5090004@elischer.org> <200612120045.41425.max@love2party.net> <4583119B.20608@elischer.org> <200612160446.02644.max@love2party.net> <4584CE0C.3020307@elischer.org> <458C426A.9060604@elischer.org> <20061224093951.GD49045@comp.chem.msu.su> <459032EA.1030601@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <459032EA.1030601@elischer.org> User-Agent: Mutt/1.5.9i Cc: Max Laier , Andre Oppermann , freebsd-net@freebsd.org Subject: Re: [was] addition to ipfw (read vlans from bridge).. 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, 26 Dec 2006 06:16:24 -0000 On Mon, Dec 25, 2006 at 12:22:02PM -0800, Julian Elischer wrote: > Yar Tikhiy wrote: > >On Fri, Dec 22, 2006 at 12:39:06PM -0800, Julian Elischer wrote: > >>Taking to heart comments by Andre and Max (Laier), > >>I have redone this patch in a different manner. > >> > >>The aim is to be able to see inside vlans when bridging. > >>Now, this is a 6.x patch to bridge.c because that is what we > >>are using, but I will make a similar patch to if_bridge.c > >>for 6 and 7 if this meets with approval. > >> > >> > >>Basically if it is a vlan packet, take off the whole vlan header instead > >>of just the ether header, but pass to ipfw, an ether header with > >>the real protocol field substituted in. > >>when finishing put back everything we removed before. > >> > >> > >>The only addition I'd do to this would be to add a sysctl > >>to turn it on if people thought it would be break POLA too much > >>to have it work by default. > > > >Excuse me, but I'd like to second Andre's opinion. We should stop > >fiddling with the mbuf contents in favour of teaching ipfw (or the > >interface code between bridge and ipfw) of 802.1q (or its > >generalisation.) Now that the 802.1q VLAN technology has been well > >integrated in the general Ethernet framework by IEEE, there is very > >litte sense left in such hacks. If ipfw is to stay L2-agnostic, > >then let's just pass the offset of the IP header into the mbuf to > >it. The 802.1q header is so nice and simple and easy to parse at > >any level. So this patch can be OK in 6.x for the only sake of > >preserving the pfil ABI, but it should die along with it. An > >extended interface is apparently called for in HEAD. > > You are the one who complained that it should not be done in ipfw, > and that we should do it the same way we currently handled the > removal and re-addition of the ethernet header. So that's what I did. > (in the bridge code), by teaching the ethernet header handling code > to handle vlan tags as well. > > If what you are suggesting is that we pass into ipfw an 'offset' > into the packet as well as the packet, then yes I like that idea, > but I didn't see Andre suggest it. Do you consider only ideas by Andre? ;-) By Andre's opinion I meant this: Please have the ipfw code examine the vlan tag in the mbuf instead of fiddling with the mbuf contents. -- Andre If we want ipfw to know of L2, then examining the VLAN tag in it is OK. If not really, then ipfw (or any pfil filter) can get just the offset of IP. > I can however submit another patch that does that.. > > However I'd like to hear from you a response to the mail > I sent you with a pure cleanup patch that removes mopst occurrances > of mtod() from ipfw.. if you did not get that email I can resend it > to you. Pardon, but you seem to mistake me for Max Laier. :-) OTOH this is a good chance for me to ask you a similar question: Did you recieve my mail on m_copym() usage in the kernel? I can resend it to you if you didn't. ;-) Honestly, I'd appreciate much if you dropped a line on the topic. > >There is also work in progress to introduce nested VLANs AKA Q-n-Q. > >They seem to present a challenge to the scheme you are implementing. > > not a permanent problem.. it could be modified to handle it. > but I'll take it into account in the next version if > you think it is a required feature.. what is the maximum > nesting level? Infinity. Why to introduce such a hard limit? Well, 802.1ad allows just two tags: the customer (C) tag and the service (S) tag, but each gets its own ethertype. C-TAG's is 81-00 while S-TAG's is 88-a8. I don't think we support the different ethertypes yet, so Q-n-Q is just the nesting of type 81-00 tags. (802.1ad appears a funny reading: it's essentially a patch against the 802.1q text!) Cisco and Juniper boxes seem to have a limit of two tags as well. While they may have a reason to (all those ASICs, you know,) we don't have it. Allowing for only two tags will tempt us into duplicating code instead of developing fair algos and interfaces. -- Yar From owner-freebsd-net@FreeBSD.ORG Tue Dec 26 18:11:42 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5D87E16A403 for ; Tue, 26 Dec 2006 18:11:42 +0000 (UTC) (envelope-from Sylvie.Dupuy@ccr.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.freebsd.org (Postfix) with ESMTP id EAE8B13C481 for ; Tue, 26 Dec 2006 18:11:41 +0000 (UTC) (envelope-from Sylvie.Dupuy@ccr.jussieu.fr) Received: from moka.ccr.jussieu.fr (moka.ccr.jussieu.fr [134.157.1.23]) by shiva.jussieu.fr (8.13.7/jtpda-5.4) with ESMTP id kBQHKTeY052024 for ; Tue, 26 Dec 2006 18:20:29 +0100 (CET) X-Ids: 164 Received: from localhost (sd@localhost) by moka.ccr.jussieu.fr (8.10.0/jtpda-5.3.3) with ESMTP id kBQHKS83620994 for ; Tue, 26 Dec 2006 18:20:28 +0100 Date: Tue, 26 Dec 2006 18:20:28 +0100 (NFT) From: Sylvie DUPUY To: freebsd-net@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (shiva.jussieu.fr [134.157.0.164]); Tue, 26 Dec 2006 18:20:30 +0100 (CET) X-Virus-Scanned: ClamAV 0.88.5/2380/Tue Dec 26 13:11:33 2006 on shiva.jussieu.fr X-Virus-Status: Clean X-Miltered: at shiva.jussieu.fr with ID 459159DD.003 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! Subject: trunk on re0 interface 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, 26 Dec 2006 18:11:42 -0000 Hi, I got a FreeBSD (6.1) connected to a Cisco switch 2950 (12.1). The speed on the re0 interface is 100 Mbps full duplex but when it get connected to the Cisco it turns out 10baseT half-duplex ? I can create VLAN attached to this interface, and this seems to work but is there anyway to speed up the tagging process ? (ifconfig tells this interface does hardware tagging) Any hint about this ? Thanks a lot, Sylvie From owner-freebsd-net@FreeBSD.ORG Tue Dec 26 19:33:51 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BC59E16A403 for ; Tue, 26 Dec 2006 19:33:51 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outQ.internet-mail-service.net (outQ.internet-mail-service.net [216.240.47.240]) by mx1.freebsd.org (Postfix) with ESMTP id 863E113C470 for ; Tue, 26 Dec 2006 19:33:51 +0000 (UTC) (envelope-from julian@elischer.org) Received: from shell.idiom.com (HELO idiom.com) (216.240.47.20) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Tue, 26 Dec 2006 11:17:07 -0800 Received: from [10.251.18.229] (nat.ironport.com [63.251.108.100]) by idiom.com (8.12.11/8.12.11) with ESMTP id kBQJRqwO011468; Tue, 26 Dec 2006 11:27:54 -0800 (PST) (envelope-from julian@elischer.org) Message-ID: <459177B0.2030006@elischer.org> Date: Tue, 26 Dec 2006 11:27:44 -0800 From: Julian Elischer User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Yar Tikhiy References: <457DCD47.5090004@elischer.org> <200612120045.41425.max@love2party.net> <4583119B.20608@elischer.org> <200612160446.02644.max@love2party.net> <4584CE0C.3020307@elischer.org> <458C426A.9060604@elischer.org> <20061224093951.GD49045@comp.chem.msu.su> <459032EA.1030601@elischer.org> <20061226061610.GD81280@comp.chem.msu.su> In-Reply-To: <20061226061610.GD81280@comp.chem.msu.su> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Max Laier , Andre Oppermann , freebsd-net@freebsd.org Subject: Re: [was] addition to ipfw (read vlans from bridge).. 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, 26 Dec 2006 19:33:51 -0000 Yar Tikhiy wrote: >> >> If what you are suggesting is that we pass into ipfw an 'offset' >> into the packet as well as the packet, then yes I like that idea, >> but I didn't see Andre suggest it. > > Do you consider only ideas by Andre? ;-) By Andre's opinion I > meant this: > > Please have the ipfw code examine the vlan tag in the mbuf instead of > fiddling with the mbuf contents. At the moment I plan the ipfw code to be unaware of vlan headers. the plan is: Add an argument to ipfw which is the offset in the packet where the IP header may be found. Change the L2 users of ipfw to leave the packet alone, but calculate the correct offset to pass to ipfw. IPFW will make no assumptions as to what packet contents come before the offset. Bridge and L2 callers of ipfw will set the offset to non-0 values where the IP callers will set it to 0. The non IP callers may make some MAC information available to the ipfw code my some separate method, as it does at the moment. How this is done will depend if we want to support Q-n-Q, and if so, how much.. > > -- > Andre > > If we want ipfw to know of L2, then examining the VLAN tag in it > is OK. If not really, then ipfw (or any pfil filter) can get just > the offset of IP. What vlan tag? what if it's from an interface with no VLAN capacity.. What we need to do is make a convention so that vlan tags are always created at the lowest layer, even if HW vlan tagging is not supported, so that all packets look as if they have come from HW capable packets, and add code so that all non WH capable interfaces interpret Van tags at the lowest level, that way vlan packets always look the same. [...] > > Pardon, but you seem to mistake me for Max Laier. :-) OTOH this is > a good chance for me to ask you a similar question: Did you recieve > my mail on m_copym() usage in the kernel? I can resend it to you > if you didn't. ;-) Honestly, I'd appreciate much if you dropped a > line on the topic. > sure.. My reader may have misfiled it under spam.. send it again.. >>> There is also work in progress to introduce nested VLANs AKA Q-n-Q. >>> They seem to present a challenge to the scheme you are implementing. >> not a permanent problem.. it could be modified to handle it. >> but I'll take it into account in the next version if >> you think it is a required feature.. what is the maximum >> nesting level? > > Infinity. Why to introduce such a hard limit? Because an infinite limit complicates things? > Well, 802.1ad allows > just two tags: the customer (C) tag and the service (S) tag, but > each gets its own ethertype. C-TAG's is 81-00 while S-TAG's is > 88-a8. I don't think we support the different ethertypes yet, so > Q-n-Q is just the nesting of type 81-00 tags. (802.1ad appears a > funny reading: it's essentially a patch against the 802.1q text!) > Cisco and Juniper boxes seem to have a limit of two tags as well. > While they may have a reason to (all those ASICs, you know,) we > don't have it. Allowing for only two tags will tempt us into > duplicating code instead of developing fair algos and interfaces. > yes but algorythmically doing something we may never be required to do may lead to unneeded code slowdown. I guess we can look at it and decide. From owner-freebsd-net@FreeBSD.ORG Tue Dec 26 22:32:00 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4233916A40F for ; Tue, 26 Dec 2006 22:32:00 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outX.internet-mail-service.net (outX.internet-mail-service.net [216.240.47.247]) by mx1.freebsd.org (Postfix) with ESMTP id 07F9813C466 for ; Tue, 26 Dec 2006 22:31:59 +0000 (UTC) (envelope-from julian@elischer.org) Received: from shell.idiom.com (HELO idiom.com) (216.240.47.20) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Tue, 26 Dec 2006 14:15:14 -0800 Received: from [10.251.18.229] (nat.ironport.com [63.251.108.100]) by idiom.com (8.12.11/8.12.11) with ESMTP id kBQMVtwT006528; Tue, 26 Dec 2006 14:31:56 -0800 (PST) (envelope-from julian@elischer.org) Message-ID: <4591A2D3.50708@elischer.org> Date: Tue, 26 Dec 2006 14:31:47 -0800 From: Julian Elischer User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Yar Tikhiy References: <457DCD47.5090004@elischer.org> <200612120045.41425.max@love2party.net> <4583119B.20608@elischer.org> <200612160446.02644.max@love2party.net> <4584CE0C.3020307@elischer.org> <458C426A.9060604@elischer.org> <20061224093951.GD49045@comp.chem.msu.su> <459032EA.1030601@elischer.org> <20061226061610.GD81280@comp.chem.msu.su> In-Reply-To: <20061226061610.GD81280@comp.chem.msu.su> Content-Type: multipart/mixed; boundary="------------050704060807020601030604" Cc: Max Laier , Andre Oppermann , freebsd-net@freebsd.org Subject: Re: [was] addition to ipfw (read vlans from bridge).. 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, 26 Dec 2006 22:32:00 -0000 This is a multi-part message in MIME format. --------------050704060807020601030604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ok, so, here is a patch for general review by ipfw types. This is the first of two related changes. It is MOSTLY a cleanup of ip_fw2.c, removing a bunch of mtod() operations and replacing them with a cached value of the address of the IP header. It also has a couple of (commented out) references to args->L3offset which is the next commit. This explains WHY we are mainignsome of the cleanups. Basically, this commit removes the assumption that mtod(m, struct ip *) returns the address of the IP header, as there may be other stuff before it in the packet. e.g. vlan headers and ethernet headers. The next commit would actually implement that by modifying the callers to no longer strip such heaers off but instead, to set the offset correctly. (and uncomment those bits in this diff) The AIM of this code is to make it easier to do layer 2 based IP filtering when there may be a variety of L2 headers on the front of the packet. The idea is to make the changes in a way that ipfw (a layer 3 animal) does not need to know any of the details of the layer 2 encapsulation, of to know how to interpret L2 headers on the ffront of the packet. it needs to only know how much to skip over. Comments welcome. --------------050704060807020601030604 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="vlclean.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="vlclean.diff" Index: netinet/ip_fw2.c =================================================================== RCS file: /usr/local/cvsroot/freebsd/src/sys/netinet/ip_fw2.c,v retrieving revision 1.155 diff -u -r1.155 ip_fw2.c --- netinet/ip_fw2.c 12 Dec 2006 12:17:56 -0000 1.155 +++ netinet/ip_fw2.c 26 Dec 2006 22:14:16 -0000 @@ -667,10 +667,12 @@ } static void -send_reject6(struct ip_fw_args *args, int code, u_int hlen) +send_reject6(struct ip_fw_args *args, int code, u_int hlen, struct ip6_hdr *ip6) { + struct mbuf *m; + + m = args->m; if (code == ICMP6_UNREACH_RST && args->f_id.proto == IPPROTO_TCP) { - struct ip6_hdr *ip6; struct tcphdr *tcp; tcp_seq ack, seq; int flags; @@ -678,18 +680,11 @@ struct ip6_hdr ip6; struct tcphdr th; } ti; - - if (args->m->m_len < (hlen+sizeof(struct tcphdr))) { - args->m = m_pullup(args->m, hlen+sizeof(struct tcphdr)); - if (args->m == NULL) - return; - } - - ip6 = mtod(args->m, struct ip6_hdr *); - tcp = (struct tcphdr *)(mtod(args->m, char *) + hlen); + tcp = (struct tcphdr *)((char *)ip6 + hlen); if ((tcp->th_flags & TH_RST) != 0) { - m_freem(args->m); + m_freem(m); + args->m = NULL; return; } @@ -705,14 +700,20 @@ flags = TH_RST; } else { ack = ti.th.th_seq; - if (((args->m)->m_flags & M_PKTHDR) != 0) { - ack += (args->m)->m_pkthdr.len - hlen + if ((m->m_flags & M_PKTHDR) != 0) { + /* + * total new data to ACK is: + * total packet length, + * minus the header length, + * minus the tcp header length. + */ + ack += m->m_pkthdr.len - hlen - (ti.th.th_off << 2); } else if (ip6->ip6_plen) { - ack += ntohs(ip6->ip6_plen) + sizeof(*ip6) - - hlen - (ti.th.th_off << 2); + ack += ntohs(ip6->ip6_plen) + sizeof(*ip6) - + hlen - (ti.th.th_off << 2); } else { - m_freem(args->m); + m_freem(m); return; } if (tcp->th_flags & TH_SYN) @@ -721,14 +722,28 @@ flags = TH_RST|TH_ACK; } bcopy(&ti, ip6, sizeof(ti)); - tcp_respond(NULL, ip6, (struct tcphdr *)(ip6 + 1), - args->m, ack, seq, flags); - + /* + * m is only used to recycle the mbuf + * The data in it is never read so we don't need + * to correct the offsets or anything + */ + tcp_respond(NULL, ip6, tcp, m, ack, seq, flags); } else if (code != ICMP6_UNREACH_RST) { /* Send an ICMPv6 unreach. */ - icmp6_error(args->m, ICMP6_DST_UNREACH, code, 0); - +#if 0 + /* + * Unlike above, the mbufs need to line up with the ip6 hdr, + * as the contents are read. We need to m_adj() the + * needed amount. + * The mbuf will however be thrown away so we can adjust it. + * Remember we did an m_pullup on it already so we + * can make some assumptions about contiguousness. + */ + if (args->L3offset) + m_adj(m, args->L3offset); +#endif + icmp6_error(m, ICMP6_DST_UNREACH, code, 0); } else - m_freem(args->m); + m_freem(m); args->m = NULL; } @@ -746,7 +761,8 @@ */ static void ipfw_log(struct ip_fw *f, u_int hlen, struct ip_fw_args *args, - struct mbuf *m, struct ifnet *oif, u_short offset, uint32_t tablearg) + struct mbuf *m, struct ifnet *oif, u_short offset, uint32_t tablearg, + struct ip *ip) { struct ether_header *eh = args->eh; char *action; @@ -892,13 +908,12 @@ snprintf(dst, sizeof(dst), "[%s]", ip6_sprintf(ip6buf, &args->f_id.dst_ip6)); - ip6 = (struct ip6_hdr *)mtod(m, struct ip6_hdr *); - tcp = (struct tcphdr *)(mtod(args->m, char *) + hlen); - udp = (struct udphdr *)(mtod(args->m, char *) + hlen); + ip6 = (struct ip6_hdr *)ip; + tcp = (struct tcphdr *)(((char *)ip) + hlen); + udp = (struct udphdr *)(((char *)ip) + hlen); } else #endif { - ip = mtod(m, struct ip *); tcp = L3HDR(struct tcphdr, ip); udp = L3HDR(struct udphdr, ip); @@ -942,7 +957,7 @@ break; #ifdef INET6 case IPPROTO_ICMPV6: - icmp6 = (struct icmp6_hdr *)(mtod(args->m, char *) + hlen); + icmp6 = (struct icmp6_hdr *)(((char *)ip) + hlen); if (offset == 0) len = snprintf(SNPARGS(proto, 0), "ICMPv6:%u.%u ", @@ -1673,13 +1688,22 @@ * sends a reject message, consuming the mbuf passed as an argument. */ static void -send_reject(struct ip_fw_args *args, int code, int ip_len) +send_reject(struct ip_fw_args *args, int code, int ip_len, struct ip *ip) { +#if 0 + /* XXX When ip is not guaranteed to be at mtod() we will + * need to account for this */ + * The mbuf will however be thrown away so we can adjust it. + * Remember we did an m_pullup on it already so we + * can make some assumptions about contiguousness. + */ + if (args->L3offset) + m_adj(m, args->L3offset); +#endif if (code != ICMP_REJECT_RST) { /* Send an ICMP unreach */ /* We need the IP header in host order for icmp_error(). */ if (args->eh != NULL) { - struct ip *ip = mtod(args->m, struct ip *); ip->ip_len = ntohs(ip->ip_len); ip->ip_off = ntohs(ip->ip_off); } @@ -2039,6 +2063,8 @@ * args->m (in/out) The packet; we set to NULL when/if we nuke it. * Starts with the IP header. * args->eh (in) Mac header if present, or NULL for layer3 packet. + * args->L3offset Number of bytes bypassed if we came from L2. + * e.g. often sizeof(eh) ** NOTYET ** * args->oif Outgoing interface, or NULL if packet is incoming. * The incoming interface is in the mbuf. (in) * args->divert_rule (in/out) @@ -2060,12 +2086,11 @@ * IP_FW_NETGRAPH into netgraph, cookie args->cookie * */ - int ipfw_chk(struct ip_fw_args *args) { /* - * Local variables hold state during the processing of a packet. + * Local variables holding state during the processing of a packet: * * IMPORTANT NOTE: to speed up the processing of rules, there * are some assumption on the values of the variables, which @@ -2075,15 +2100,18 @@ * * args->eh The MAC header. It is non-null for a layer2 * packet, it is NULL for a layer-3 packet. + * **notyet** + * args->L3offset Offset in the packet to the L3 (IP or equiv.) header. * * m | args->m Pointer to the mbuf, as received from the caller. * It may change if ipfw_chk() does an m_pullup, or if it * consumes the packet because it calls send_reject(). * XXX This has to change, so that ipfw_chk() never modifies * or consumes the buffer. - * ip is simply an alias of the value of m, and it is kept - * in sync with it (the packet is supposed to start with - * the ip header). + * ip is the beginning of the ip(4 or 6) header. + * Calculated by adding the L3offset to the start of data. + * (Until we start using L3offset, the packet is + * supposed to start with the ip header). */ struct mbuf *m = args->m; struct ip *ip = mtod(m, struct ip *); @@ -2154,6 +2182,7 @@ struct in_addr src_ip, dst_ip; /* NOTE: network format */ u_int16_t ip_len=0; int pktlen; + u_int16_t etype = 0; /* Host order stored ether type */ /* * dyn_dir = MATCH_UNKNOWN when rules unchecked, @@ -2202,14 +2231,20 @@ p = (mtod(m, char *) + (len)); \ } while (0) + /* + * if we have an ether header, + */ + if (args->eh) + etype = (ntohs(args->eh->ether_type)) == ETHERTYPE_VLAN; + /* Identify IP packets and fill up variables. */ if (pktlen >= sizeof(struct ip6_hdr) && - (args->eh == NULL || ntohs(args->eh->ether_type)==ETHERTYPE_IPV6) && - mtod(m, struct ip *)->ip_v == 6) { + (args->eh == NULL || etype == ETHERTYPE_IPV6) && ip->ip_v == 6) { + struct ip6_hdr *ip6 = (struct ip6_hdr *)ip; is_ipv6 = 1; args->f_id.addr_type = 6; hlen = sizeof(struct ip6_hdr); - proto = mtod(m, struct ip6_hdr *)->ip6_nxt; + proto = ip6->ip6_nxt; /* Search extension headers to find upper layer protocols */ while (ulp == NULL) { @@ -2354,16 +2389,16 @@ break; } /*switch */ } - args->f_id.src_ip6 = mtod(m,struct ip6_hdr *)->ip6_src; - args->f_id.dst_ip6 = mtod(m,struct ip6_hdr *)->ip6_dst; + ip = mtod(m, struct ip *); + ip6 = (struct ip6_hdr *)ip; + args->f_id.src_ip6 = ip6->ip6_src; + args->f_id.dst_ip6 = ip6->ip6_dst; args->f_id.src_ip = 0; args->f_id.dst_ip = 0; - args->f_id.flow_id6 = ntohl(mtod(m, struct ip6_hdr *)->ip6_flow); + args->f_id.flow_id6 = ntohl(ip6->ip6_flow); } else if (pktlen >= sizeof(struct ip) && - (args->eh == NULL || ntohs(args->eh->ether_type) == ETHERTYPE_IP) && - mtod(m, struct ip *)->ip_v == 4) { + (args->eh == NULL || etype == ETHERTYPE_IP) && ip->ip_v == 4) { is_ipv4 = 1; - ip = mtod(m, struct ip *); hlen = ip->ip_hl << 2; args->f_id.addr_type = 4; @@ -2407,6 +2442,7 @@ } } + ip = mtod(m, struct ip *); args->f_id.src_ip = ntohl(src_ip.s_addr); args->f_id.dst_ip = ntohl(dst_ip.s_addr); } @@ -2573,15 +2609,14 @@ case O_MAC_TYPE: if (args->eh != NULL) { - u_int16_t t = - ntohs(args->eh->ether_type); u_int16_t *p = ((ipfw_insn_u16 *)cmd)->ports; int i; for (i = cmdlen - 1; !match && i>0; i--, p += 2) - match = (t>=p[0] && t<=p[1]); + match = (etype >= p[0] && + etype <= p[1]); } break; @@ -2733,12 +2768,12 @@ case O_IPOPT: match = (is_ipv4 && - ipopts_match(mtod(m, struct ip *), cmd) ); + ipopts_match(ip, cmd) ); break; case O_IPVER: match = (is_ipv4 && - cmd->arg1 == mtod(m, struct ip *)->ip_v); + cmd->arg1 == ip->ip_v); break; case O_IPID: @@ -2752,9 +2787,9 @@ if (cmd->opcode == O_IPLEN) x = ip_len; else if (cmd->opcode == O_IPTTL) - x = mtod(m, struct ip *)->ip_ttl; + x = ip->ip_ttl; else /* must be IPID */ - x = ntohs(mtod(m, struct ip *)->ip_id); + x = ntohs(ip->ip_id); if (cmdlen == 1) { match = (cmd->arg1 == x); break; @@ -2769,12 +2804,12 @@ case O_IPPRECEDENCE: match = (is_ipv4 && - (cmd->arg1 == (mtod(m, struct ip *)->ip_tos & 0xe0)) ); + (cmd->arg1 == (ip->ip_tos & 0xe0)) ); break; case O_IPTOS: match = (is_ipv4 && - flags_match(cmd, mtod(m, struct ip *)->ip_tos)); + flags_match(cmd, ip->ip_tos)); break; case O_TCPDATALEN: @@ -2866,7 +2901,7 @@ case O_LOG: if (fw_verbose) ipfw_log(f, hlen, args, m, - oif, offset, tablearg); + oif, offset, tablearg, ip); match = 1; break; @@ -3204,7 +3239,7 @@ is_icmp_query(ICMP(ulp))) && !(m->m_flags & (M_BCAST|M_MCAST)) && !IN_MULTICAST(ntohl(dst_ip.s_addr))) { - send_reject(args, cmd->arg1, ip_len); + send_reject(args, cmd->arg1, ip_len, ip); m = args->m; } /* FALLTHROUGH */ @@ -3216,7 +3251,9 @@ (is_icmp6_query(args->f_id.flags) == 1)) && !(m->m_flags & (M_BCAST|M_MCAST)) && !IN6_IS_ADDR_MULTICAST(&args->f_id.dst_ip6)) { - send_reject6(args, cmd->arg1, hlen); + send_reject6( + args, cmd->arg1, hlen, + (struct ip6_hdr *)ip); m = args->m; } /* FALLTHROUGH */ --------------050704060807020601030604-- From owner-freebsd-net@FreeBSD.ORG Tue Dec 26 23:54:48 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0E1D516A403 for ; Tue, 26 Dec 2006 23:54:48 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (noop.in-addr.com [208.58.23.51]) by mx1.freebsd.org (Postfix) with ESMTP id DB87013C463 for ; Tue, 26 Dec 2006 23:54:47 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from gjp by noop.in-addr.com with local (Exim 4.54 (FreeBSD)) id 1GzLqd-0006Hz-8d for freebsd-net@freebsd.org; Tue, 26 Dec 2006 18:36:43 -0500 Date: Tue, 26 Dec 2006 18:36:43 -0500 From: Gary Palmer To: freebsd-net@freebsd.org Message-ID: <20061226233643.GA13257@in-addr.com> Mail-Followup-To: freebsd-net@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: trunk on re0 interface 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, 26 Dec 2006 23:54:48 -0000 On Tue, Dec 26, 2006 at 06:20:28PM +0100, Sylvie DUPUY wrote: > Hi, > > I got a FreeBSD (6.1) connected to a Cisco switch 2950 (12.1). > The speed on the re0 interface is 100 Mbps full duplex but when it get > connected to the Cisco it turns out 10baseT half-duplex ? If you have the re0 locked at 100 full duplex, you implicitly turn off autonegotiation and the other end of the link doesn't know what to do. Either use autonegotiation on both ends, or fix the speed and duplex on both ends. From owner-freebsd-net@FreeBSD.ORG Wed Dec 27 03:14:22 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DF1A616A40F for ; Wed, 27 Dec 2006 03:14:22 +0000 (UTC) (envelope-from stephanwehner@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by mx1.freebsd.org (Postfix) with ESMTP id 7EAE813C46D for ; Wed, 27 Dec 2006 03:14:22 +0000 (UTC) (envelope-from stephanwehner@gmail.com) Received: by nf-out-0910.google.com with SMTP id x37so4686759nfc for ; Tue, 26 Dec 2006 19:14:21 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=Eeis7bqNTcv0r6K6geBOC1rrKDu0py6D4Y7CYpkCEayo7FXy9JheT7kCpe11HElwvmpgvk9R2r0Js2pl1DxOTOjuHqPj3Fr70AIGOJ9knpOT4mAYxpA3v64D6popQpjbSscNopCVbQACXokYgfJAfwy+lr9PZ7bjEvfC+5z4IDM= Received: by 10.78.18.3 with SMTP id 3mr3425720hur.1167187539891; Tue, 26 Dec 2006 18:45:39 -0800 (PST) Received: by 10.78.142.3 with HTTP; Tue, 26 Dec 2006 18:45:39 -0800 (PST) Message-ID: Date: Tue, 26 Dec 2006 18:45:39 -0800 From: "Stephan Wehner" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Diagnose co-location networking problem 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, 27 Dec 2006 03:14:23 -0000 I just got a server and put it in a co-location. It runs RELEASE FreeBSD 6.1-RELEASE #0, pound, lighttpd and ruby on rails. Most of the times I find the server responds nicely. But periodically it doesn't respond properly when accessing its webpages: Type URL in browser, hit return, no page appears. Try again and again and after a few times it appears. Other sites are accessible during these problematic times. Also, in parallel I am connected to the server through ssh, and there are not problems with that. Even during those times when the web pages don't appear, I can type and see the result. Before installing it at the datacentre, the server was working without problems on the local network. So I am thinking the problem may be with the co-location operation. How can I make sure? How can I diagnose this? The only idea I had was to run tcpdump on my Linux client (tcpdump host stbgo.org), and indeed I can see entries lines this: 18:32:24.970139 sucrose.sugarmotor.net.34503 > vps-18-138.virtualprivateservers.ca.http: S 2468438613:2468438613(0) win 5840 (DF) 18:32:25.670135 sucrose.sugarmotor.net.34508 > vps-18-138.virtualprivateservers.ca.http: S 2493895298:2493895298(0) win 5840 (DF) 18:32:49.670152 sucrose.sugarmotor.net.34508 > vps-18-138.virtualprivateservers.ca.http: S 2493895298:2493895298(0) win 5840 (DF) [note next is almost half a minute later] 18:33:12.970162 sucrose.sugarmotor.net.34503 > vps-18-138.virtualprivateservers.ca.http: S 2468438613:2468438613(0) win 5840 (DF) 18:33:12.985071 vps-18-138.virtualprivateservers.ca.http > sucrose.sugarmotor.net.34503: S 2788301288:2788301288(0) ack 2468438614 win 65535 (DF) But I am not sure what these lines are telling me; other than "sucrose" tried a few times, and then got a response (last line). Any hints? Thanks Stephan -- Stephan Wehner > http://stephan.sugarmotor.org > http://stephansmap.org > http://www.trafficlife.com > http://www.buckmaster.ca From owner-freebsd-net@FreeBSD.ORG Wed Dec 27 04:03:20 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1B2FC16A407 for ; Wed, 27 Dec 2006 04:03:20 +0000 (UTC) (envelope-from alex@pilosoft.com) Received: from bawx.pilosoft.com (colo-69-31-40-106.pilosoft.com [69.31.40.106]) by mx1.freebsd.org (Postfix) with ESMTP id C63E313C46E for ; Wed, 27 Dec 2006 04:03:19 +0000 (UTC) (envelope-from alex@pilosoft.com) Received: from bawx.pilosoft.com (localhost [127.0.0.1]) by bawx.pilosoft.com (8.12.5/8.12.5) with ESMTP id kBR3BFm0017855; Tue, 26 Dec 2006 22:11:15 -0500 Received: from localhost (alex@localhost) by bawx.pilosoft.com (8.12.5/8.12.5/Submit) with ESMTP id kBR3BEOf017851; Tue, 26 Dec 2006 22:11:14 -0500 X-Authentication-Warning: bawx.pilosoft.com: alex owned process doing -bs Date: Tue, 26 Dec 2006 22:11:14 -0500 (EST) From: alex@pilosoft.com To: Stephan Wehner In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net@freebsd.org Subject: Re: Diagnose co-location networking problem 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, 27 Dec 2006 04:03:20 -0000 On Tue, 26 Dec 2006, Stephan Wehner wrote: > Most of the times I find the server responds nicely. But periodically it > doesn't respond properly when accessing its webpages: Type URL in > browser, hit return, no page appears. Try again and again and after a > few times it appears. DNS. try tcpdump -n -alex From owner-freebsd-net@FreeBSD.ORG Wed Dec 27 05:55:48 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6B1D316A407 for ; Wed, 27 Dec 2006 05:55:48 +0000 (UTC) (envelope-from stephanwehner@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by mx1.freebsd.org (Postfix) with ESMTP id 080D813C463 for ; Wed, 27 Dec 2006 05:55:47 +0000 (UTC) (envelope-from stephanwehner@gmail.com) Received: by nf-out-0910.google.com with SMTP id p48so4492655nfa for ; Tue, 26 Dec 2006 21:55:46 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=OYEaIpwmbgfz0LlEtMgqYNLuMA8gVVRwo3bAvF0giI5s/ES6M7A36Lrga63cE/OFyGlM4+ahEhAoMlBdFo4rpgcpOnhbxFNWWyjEigFUVPQara8ViYN4cBgvu6ZoF1aJwflaQygycheqfP50mMeUZQlrSloKKWR08gDOuroWTVM= Received: by 10.78.185.16 with SMTP id i16mr3506399huf.1167198946825; Tue, 26 Dec 2006 21:55:46 -0800 (PST) Received: by 10.78.142.3 with HTTP; Tue, 26 Dec 2006 21:55:46 -0800 (PST) Message-ID: Date: Tue, 26 Dec 2006 21:55:46 -0800 From: "Stephan Wehner" To: alex@pilosoft.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: freebsd-net@freebsd.org Subject: Re: Diagnose co-location networking problem 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, 27 Dec 2006 05:55:48 -0000 Ok, thanks, I now ran tcpdump with -n. Here I am testing with a little script that continuously accesses one of the pages. Right at the beginning it doesn't get very far: first response after 90 seconds. What kind of DNS problem did you have in mind? Stephan $ sudo /usr/sbin/tcpdump -n host stbgo.org Password: tcpdump: listening on eth0 21:40:22.162536 192.168.2.54.35932 > 65.110.18.138.80: S 1526509984:1526509984(0) win 5840 (DF) 21:40:25.160150 192.168.2.54.35932 > 65.110.18.138.80: S 1526509984:1526509984(0) win 5840 (DF) 21:40:31.160150 192.168.2.54.35932 > 65.110.18.138.80: S 1526509984:1526509984(0) win 5840 (DF) 21:40:43.160143 192.168.2.54.35932 > 65.110.18.138.80: S 1526509984:1526509984(0) win 5840 (DF) 21:41:07.160149 192.168.2.54.35932 > 65.110.18.138.80: S 1526509984:1526509984(0) win 5840 (DF) 21:41:55.160152 192.168.2.54.35932 > 65.110.18.138.80: S 1526509984:1526509984(0) win 5840 (DF) 21:41:55.174033 65.110.18.138.80 > 192.168.2.54.35932: S 432853648:432853648(0) ack 1526509985 win 65535 (DF) 21:41:55.174139 192.168.2.54.35932 > 65.110.18.138.80: . ack 1 win 5840 (DF) 21:41:55.175738 192.168.2.54.35932 > 65.110.18.138.80: P 1:15(14) ack 1 win 5840 ( DF) 21:41:55.290528 65.110.18.138.80 > 192.168.2.54.35932: . ack 15 win 33304 (DF) 21:41:55.290665 192.168.2.54.35932 > 65.110.18.138.80: P 15:73(58) ack 1 win 5840 (DF) On 12/26/06, alex@pilosoft.com wrote: > On Tue, 26 Dec 2006, Stephan Wehner wrote: > > > Most of the times I find the server responds nicely. But periodically it > > doesn't respond properly when accessing its webpages: Type URL in > > browser, hit return, no page appears. Try again and again and after a > > few times it appears. > DNS. > > try tcpdump -n > > -alex > > -- Stephan Wehner > http://stephan.sugarmotor.org > http://stephansmap.org > http://www.trafficlife.com > http://www.buckmaster.ca From owner-freebsd-net@FreeBSD.ORG Wed Dec 27 05:59:12 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3BC1716A407 for ; Wed, 27 Dec 2006 05:59:12 +0000 (UTC) (envelope-from alex@pilosoft.com) Received: from bawx.pilosoft.com (colo-69-31-40-106.pilosoft.com [69.31.40.106]) by mx1.freebsd.org (Postfix) with ESMTP id E6D8913C46D for ; Wed, 27 Dec 2006 05:59:09 +0000 (UTC) (envelope-from alex@pilosoft.com) Received: from bawx.pilosoft.com (localhost [127.0.0.1]) by bawx.pilosoft.com (8.12.5/8.12.5) with ESMTP id kBR5p0m0018021; Wed, 27 Dec 2006 00:51:00 -0500 Received: from localhost (alex@localhost) by bawx.pilosoft.com (8.12.5/8.12.5/Submit) with ESMTP id kBR5p0iG018017; Wed, 27 Dec 2006 00:51:00 -0500 X-Authentication-Warning: bawx.pilosoft.com: alex owned process doing -bs Date: Wed, 27 Dec 2006 00:51:00 -0500 (EST) From: alex@pilosoft.com To: Stephan Wehner In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net@freebsd.org Subject: Re: Diagnose co-location networking problem 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, 27 Dec 2006 05:59:12 -0000 On Tue, 26 Dec 2006, Stephan Wehner wrote: > Ok, thanks, I now ran tcpdump with -n. > > Here I am testing with a little script that continuously accesses one of > the pages. Right at the beginning it doesn't get very far: first > response after 90 seconds. > > What kind of DNS problem did you have in mind? Sorry, this doesn't seem to be DNS.. It may be something related to link/autonegotiation, or it could be something beyond your control, on the Internet between the two hosts in question. Are you able to do a traceroute when your connections fail? Where does the trace stop? -alex From owner-freebsd-net@FreeBSD.ORG Wed Dec 27 09:32:18 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B68F116A403 for ; Wed, 27 Dec 2006 09:32:18 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from pobox.codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 6FDCF13C48D for ; Wed, 27 Dec 2006 09:32:18 +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:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=D7S46XvoCSQ8fJa7S5Oo+4y4P+Qa1QDtm8ZPkCYF7NY7jYQJ8H45eP683HFJ1+t5U6LCjLLKu742TMq4BqbAJvY3ZWNKHOATT5un1MWo1Sn63YRsGfLcCjJ4dk3JW8YmuEDCRh8UuPul9I7AuoCpHXBdO2hDUSva72MLoS90emE=; Received: from codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1GzV8r-000Lu2-Mt; Wed, 27 Dec 2006 12:32:09 +0300 Date: Wed, 27 Dec 2006 12:32:04 +0300 From: Eygene Ryabinkin To: Sylvie DUPUY Message-ID: <20061227093204.GB1090@codelabs.ru> References: MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-1.6 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_50 Cc: freebsd-net@freebsd.org Subject: Re: trunk on re0 interface 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, 27 Dec 2006 09:32:18 -0000 > I can create VLAN attached to this interface, and this seems to work > but is there anyway to speed up the tagging process ? (ifconfig tells > this interface does hardware tagging) Search for 'vlanhwtag' in ifconfig(8). -- Eygene From owner-freebsd-net@FreeBSD.ORG Wed Dec 27 14:07:22 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 62E3416A492 for ; Wed, 27 Dec 2006 14:07:22 +0000 (UTC) (envelope-from bv@bilver.wjv.com) Received: from wjv.com (fl-65-40-24-38.sta.embarqhsd.net [65.40.24.38]) by mx1.freebsd.org (Postfix) with ESMTP id A86E613C47E for ; Wed, 27 Dec 2006 14:07:21 +0000 (UTC) (envelope-from bv@bilver.wjv.com) Received: from bilver.wjv.com (localhost.wjv.com [127.0.0.1]) by wjv.com (8.13.8/8.13.1) with ESMTP id kBRDjZek060561; Wed, 27 Dec 2006 08:45:36 -0500 (EST) (envelope-from bv@bilver.wjv.com) Received: (from bv@localhost) by bilver.wjv.com (8.13.8/8.13.1/Submit) id kBRDjULQ060560; Wed, 27 Dec 2006 08:45:30 -0500 (EST) (envelope-from bv) Date: Wed, 27 Dec 2006 08:45:30 -0500 From: Bill Vermillion To: Stephan Wehner Message-ID: <20061227134530.GB60067@wjv.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Organization: W.J.Vermillion / Orlando - Winter Park ReplyTo: bv@wjv.com X-Spam-Status: No, score=-3.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on bilver.wjv.com Cc: freebsd-net@freebsd.org Subject: Re: Diagnose co-location networking problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bv@wjv.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Dec 2006 14:07:22 -0000 Earlier in the linear time track, on approximately Tue, Dec 26, 2006 at 18:45 , Stephan Wehner divulged this public information: > I just got a server and put it in a co-location. > It runs RELEASE FreeBSD 6.1-RELEASE #0, pound, lighttpd and ruby > on rails. > Most of the times I find the server responds nicely. But periodically > it doesn't respond properly when accessing its webpages: Type URL in > browser, hit return, no page appears. Try again and again and after a > few times it appears. That sounds like a transport problem between your machine and the server. It could be anywhere on the link. Is the colo doing any rate-limiting? I see this now and then with dropped packets from my machine to my servers. And I control the colo with a rack we have in the Level 3 space so I can trace the problems. One of the strangest - with intermittent long delays in packet returns made me think I had a problem with Level 3. I contact the NOC in the Denver area, and they checked, and saw no problems on their net, but they checked further, and what was happening was the my packets were a different route back to me than going to the server. [this is not a bug but it doesn't happen very often - usually when someone screws things up in routers]. Packets left Orlando via Sprint, went to Texas, crossed over to Level 3 there, back to Orlando and my rack, and then they would go out onto Level 3, and then go to a Sprinr router in Washington and come back through Atlanta. So the first thing I'd suggest is checking your connections via traceroute. And >>IF<< your provider does not block RECORD ROUTE and if the hop count is under 8 - you can try ping -R . That will show you the IP addresses from which the packets are leaving, as opposed to the addresses they are going to. > Other sites are accessible during these problematic times. Also, in > parallel I am connected to the server through ssh, and there are not > problems with that. Even during those times when the web pages don't > appear, I can type and see the result. When you way 'other sites are accessible' do you mean other sites on your machine, or other sites on the 'net. And what about other sites that are located in that colo that you don't control? > Before installing it at the datacentre, the server was working without > problems on the local network. Well there is always the chance the moving it created a problem - something shook loose. I've had the reverse when I was heading up a recording studio. Some of the early digital equipment we had would get flaky. We'd ship it by FedEX to the factory, and they'd find nothing, but change out something that may have caused it. Three times FedEX cured the problem in shipping - and each time another piece was changed. Finally - on number 4 - it worked at the factory, but they changed ALL the internal cables - and that fixed it permanently. It was the vibration in shipment that temporarily fixed things - but shipping an item out wasn't what I call a good fix :-) > So I am thinking the problem may be with the co-location operation. As above - it could be the colo - or it could be your network connections to the colo. Bill -- Bill Vermillion - bv @ wjv . com From owner-freebsd-net@FreeBSD.ORG Wed Dec 27 16:14:45 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8454016A40F for ; Wed, 27 Dec 2006 16:14:45 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from postfix2-g20.free.fr (postfix2-g20.free.fr [212.27.60.43]) by mx1.freebsd.org (Postfix) with ESMTP id 3FB6F13C46D for ; Wed, 27 Dec 2006 16:14:45 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp7-g19.free.fr (smtp7-g19.free.fr [212.27.42.64]) by postfix2-g20.free.fr (Postfix) with ESMTP id 6F325845E23 for ; Wed, 27 Dec 2006 15:55:35 +0100 (CET) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp7-g19.free.fr (Postfix) with ESMTP id 6D4A7555A; Wed, 27 Dec 2006 16:55:31 +0100 (CET) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 886BE9B465; Wed, 27 Dec 2006 15:56:38 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 630AC405B; Wed, 27 Dec 2006 16:56:38 +0100 (CET) Date: Wed, 27 Dec 2006 16:56:38 +0100 From: Jeremie Le Hen To: "Bjoern A. Zeeb" Message-ID: <20061227155638.GG2187@obiwan.tataz.chchile.org> References: <20061216094004.GA24480@harmless.hu> <20061216100556.T91892@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061216100556.T91892@maildrop.int.zabbadoz.net> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Gergely CZUCZY , freebsd-net@freebsd.org Subject: Re: [fbsd] Re: jail addresses and default bindings 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, 27 Dec 2006 16:14:45 -0000 On Sat, Dec 16, 2006 at 10:13:00AM +0000, Bjoern A. Zeeb wrote: > >this way it's hard to distingvish in a packet filter(let's say pf), > >among connections originating from within the jail itself or > >from the host system to the jail. > > I won't ask why you would want to do that if you control it > from the "host" system anyway... Additionally, ipfw(8) has the "jail" keyword, though it is easier to work with IP addresses since jail ids are bumped whenever you restart a jail. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-net@FreeBSD.ORG Wed Dec 27 16:25:01 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1B7F316A415 for ; Wed, 27 Dec 2006 16:25:01 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from marvin.harmless.hu (marvin.harmless.hu [195.56.55.204]) by mx1.freebsd.org (Postfix) with ESMTP id 9047A13C487 for ; Wed, 27 Dec 2006 16:25:00 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from localhost (marvin-mail [192.168.0.2]) by marvin.harmless.hu (Postfix) with ESMTP id 60E6A7C00C3; Wed, 27 Dec 2006 17:01:03 +0100 (CET) X-Virus-Scanned: by amavisd-new-2.4.2 (20060627) (Debian) at harmless.hu Received: from marvin.harmless.hu ([192.168.0.2]) by localhost (marvin.harmless.hu [192.168.0.2]) (amavisd-new, port 10024) with ESMTP id akIqo3ycPSCo; Wed, 27 Dec 2006 17:01:03 +0100 (CET) Received: from marvin.harmless.hu (localhost [127.0.0.1]) by marvin.harmless.hu (Postfix) with ESMTP id C95347BFD14; Wed, 27 Dec 2006 17:01:02 +0100 (CET) Date: Wed, 27 Dec 2006 17:01:02 +0100 From: Gergely CZUCZY To: Jeremie Le Hen Message-ID: <20061227160102.GA43151@harmless.hu> References: <20061216094004.GA24480@harmless.hu> <20061216100556.T91892@maildrop.int.zabbadoz.net> <20061227155638.GG2187@obiwan.tataz.chchile.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=x-unknown; protocol="application/pgp-signature"; boundary="Dxnq1zWXvFF0Q93v" Content-Disposition: inline In-Reply-To: <20061227155638.GG2187@obiwan.tataz.chchile.org> User-Agent: mutt-ng/devel-r804 (FreeBSD) Cc: "Bjoern A. Zeeb" , freebsd-net@freebsd.org Subject: Re: [fbsd] Re: jail addresses and default bindings 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, 27 Dec 2006 16:25:01 -0000 --Dxnq1zWXvFF0Q93v Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 27, 2006 at 04:56:38PM +0100, Jeremie Le Hen wrote: > On Sat, Dec 16, 2006 at 10:13:00AM +0000, Bjoern A. Zeeb wrote: > > >this way it's hard to distingvish in a packet filter(let's say pf), > > >among connections originating from within the jail itself or > > >from the host system to the jail. > >=20 > > I won't ask why you would want to do that if you control it > > from the "host" system anyway... >=20 > Additionally, ipfw(8) has the "jail" keyword, though it is easier to > work with IP addresses since jail ids are bumped whenever you restart > a jail. yes, i know. but it's not just the packet filter itself. this way i cannot make separate access control rules in PostgreSQLs configuration file which treats differently injail and host system connections, since both have the same originating IP address. i was pointed out to use sshd_config's bind directive, and netcat's -s, but in most client libraries i don't have this flexibility. clients tend to bind to IPADDR_ANY and leave the details to the IP stack itself. they just need to connect, doesn't select IP addresses to bind to. libpq (postgres's client library) doesn't offer this flexilbity, nor any other client libs i know at the moment. you cannot even configure a web broser(links, opera, firefox, etc) and tell it to which IPs it can use for browsing proposes and which ones are out of it's limits (for an example some addresses are held for jails). Bye, Gergely Czuczy mailto: gergely.czuczy@harmless.hu --=20 Weenies test. Geniuses solve problems that arise. --Dxnq1zWXvFF0Q93v Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) owFVVU2IHEUUXhPMocBDwKPgYy/ZYbvbnv1nkqiTbIgrUVcTCOoh1HS/nq6d6qpO VfX2djx6UchBchI8GA8eBAUFQU9C7uLBm0fx5FH8OfuqemYny8AM0/V+vu9736v+ 5LnzK+cu/vLt9++vP3z02TPfXPhusl41zqlpXHFzLFQ8TNNhvLU53KbveDdNt7fy ItvkKd/YTvduPPr0p+taOVQuvtPVOAKHJ+6lWnKhLkNWcmPRXW1cEe+xRdy+sLW2 wgmtRiCUFApPz+4YrmyBJr6hMp0LNR3B/UY7zOPaCOX4RCJjbym4i3kE+5jBxm4E G2m6A9xBujXa3hlt7h2+AespwY7gdTRYCYRbCK+hgtZQqRF7GajCbe76CsOdZYVh OhpujtJ07CukvsK1I41GwTiB9xAnywr0caWw0PIOhLtkgajm4DTkwjrCfSxsSeSA Q82zGToohHRo1iT6YEtZdTGI+kK80moKmVYKM6+KBW3EVCjuC0FhdAWtoG4KXIlw xIWklhZlQXF9hRDjD0ttHdjOOqw8mEV84sOubqQh+gBarS454HYGbdlBpxt60sic yCgXOPhMkkMU4ZCQOaN905B/2mzVd1tdtOOqIzGShHr1ncZ5HobMpewiEHXRru0N SCfbJ3tcqzDDrtWGhulK3UxJMupqAbkVaAgKlaHjWeAPB4fA89ygtUgSCpUtxMgt cIMwaaoaiUWJCo8p3WOnaMeNB87nSnRoCQ3MlG4TSnH9+JR2cNSQeB7bmZHNtU7Y ct6QceUTKj5DsFhzwx0CzzKCdqqWaSTBFIodkkpTg7ffvhUOCzFtKJ6E8Q2Q4Iqs BGeQO0vuKcj9tAmyY0IFdlzlZ8b6lE+iuQoTTeqU/Bg9emZ5hWcctNQtYUwQBQu1 pm0irXQTBt5Y4mHL/F6Pj/SYCGqbC+M7HWPkUTCFLuNerJg6B+UUVB5ZJgVBBikm hhvhWZOFvMXmmIRlhcQTMRFSuC6Zx5MPUIWdCc3o9+BwvL//zr3xm+8G1hIXlHJ0 JIVdWJoI0VSz2WI0/mHXj08hhlJzlSICgpagMAqk/2c9tGydMAJf34e1uh+WJZZn WHWDRSXQfkSBFQRWckKkIqa08TsANAs6Xibbudn8/eLBV7qik6TfrN5H5FbFFtYg I0FLV83EaOsvDKFmJLeu0fCIHGOw0CcR0CgGQSSHMmwmcemddHBo/RZR6TDWgmBR qdZ6J9RGE0Fi7jP7cK0wbA/zVtBFvw1SVCQtrBWBE+AJr2qyqiXoT8nnd65Eujd8 mPeqHZDBrnUYMXYTzRRlB9cfNNmDjlV06vQIpv3jJAuPX6VLs5Lel2XDWBz7e+Mu ovIWcrS4CdykP01Ydy3JC4Sf3gCV7a8n8prFhH30yvlnV/yLaPEWu3hu+uPK4y+e sK/H8h/255ftlR8e//3fzx8/eX7lc9HsZh9+9eLk1w/+ePjXCxd+//c3dvl/ =J0Ot -----END PGP SIGNATURE----- --Dxnq1zWXvFF0Q93v-- From owner-freebsd-net@FreeBSD.ORG Wed Dec 27 17:52:29 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4E86616A40F for ; Wed, 27 Dec 2006 17:52:29 +0000 (UTC) (envelope-from freebsd.org@ab.ote.we.lv) Received: from mx0.nttmcl.com (MX0.nttmcl.com [216.69.68.201]) by mx1.freebsd.org (Postfix) with ESMTP id 1F18813C463 for ; Wed, 27 Dec 2006 17:52:27 +0000 (UTC) (envelope-from freebsd.org@ab.ote.we.lv) Received: from [216.69.70.43] (bbq.nttmcl.com [216.69.70.43]) by mx0.nttmcl.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id kBRHZJ53029078 for ; Wed, 27 Dec 2006 09:35:24 -0800 Message-ID: <4592AED6.4040508@ab.ote.we.lv> Date: Wed, 27 Dec 2006 09:35:18 -0800 From: "Eugene M. Kim" User-Agent: Thunderbird 1.5.0.8 (X11/20061130) MIME-Version: 1.0 To: net@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: BIND running setuid with interface changes 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, 27 Dec 2006 17:52:29 -0000 Greetings, I am running a VPN gateway, where interfaces come and go frequently. I set up BIND so that it listens on all interfaces. It seems that, instead of listening on a wildcard IPv4 address (*:53, that is), BIND monitors for address changes on all interfaces and creates a separate listening socket for each address (note that IPv6 uses the wildcard address, but IPv4 does not): home 09:22:27 namedb # 61 sockstat|grep 'named.*:53' bind named 38200 20 udp6 *:53 *:* bind named 38200 21 tcp6 *:53 *:* bind named 38200 22 udp4 10.0.0.1:53 *:* bind named 38200 23 tcp4 10.0.0.1:53 *:* bind named 38200 24 udp4 127.0.0.1:53 *:* bind named 38200 25 tcp4 127.0.0.1:53 *:* home 09:25:12 namedb # 62 Then, when a new address comes up (such as on a dynamically created L2TP tun(4) interface), BIND tries to listen on it, but fails because it is running setuid as bind: Dec 27 02:32:00 home named[1121]: listening on IPv4 interface tun0, 10.0.2.129#53 Dec 27 02:32:00 home named[1121]: could not listen on UDP socket: permission denied The only workarounds that I can think of is either to run BIND as setuid root, or to restart (not reload) BIND every time a new VPN connection comes up, both of which I am not comfortable with. Any better ideas? Cheers, Eugene From owner-freebsd-net@FreeBSD.ORG Wed Dec 27 19:17:05 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DFD9716A403 for ; Wed, 27 Dec 2006 19:17:05 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with SMTP id 78F2313C46E for ; Wed, 27 Dec 2006 19:17:05 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 5900 invoked by uid 399); 27 Dec 2006 18:50:25 -0000 Received: from localhost (HELO ?192.168.0.5?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 27 Dec 2006 18:50:25 -0000 X-Originating-IP: 127.0.0.1 Message-ID: <4592C06F.6080106@FreeBSD.org> Date: Wed, 27 Dec 2006 10:50:23 -0800 From: Doug Barton Organization: http://www.freebsd.org/ User-Agent: Thunderbird 1.5.0.8 (X11/20061215) MIME-Version: 1.0 To: "Eugene M. Kim" References: <4592AED6.4040508@ab.ote.we.lv> In-Reply-To: <4592AED6.4040508@ab.ote.we.lv> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: BIND running setuid with interface changes 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, 27 Dec 2006 19:17:06 -0000 Eugene M. Kim wrote: > Greetings, > > I am running a VPN gateway, where interfaces come and go frequently. I > set up BIND so that it listens on all interfaces. > It seems that, instead of listening on a wildcard IPv4 address (*:53, > that is), BIND monitors for address changes on all interfaces and > creates a separate listening socket for each address (note that IPv6 > uses the wildcard address, but IPv4 does not): I suspect that you are using something like "listen-on-v6 { any; };" in which case this is normal behavior. > Then, when a new address comes up (such as on a dynamically created L2TP > tun(4) interface), BIND tries to listen on it, but fails because it is > running setuid as bind: That is also normal behavior. > The only workarounds that I can think of is either to run BIND as setuid > root, or to restart (not reload) BIND every time a new VPN connection > comes up, both of which I am not comfortable with. > > Any better ideas? Nope, sorry. That is how it works. Doug -- This .signature sanitized for your protection From owner-freebsd-net@FreeBSD.ORG Wed Dec 27 22:00:26 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 17AE516A403 for ; Wed, 27 Dec 2006 22:00:26 +0000 (UTC) (envelope-from skip.ford@verizon.net) Received: from vms042pub.verizon.net (vms042pub.verizon.net [206.46.252.42]) by mx1.freebsd.org (Postfix) with ESMTP id DCEE613C46E for ; Wed, 27 Dec 2006 22:00:25 +0000 (UTC) (envelope-from skip.ford@verizon.net) Received: from pool-71-168-196-193.pskn.east.verizon.net ([71.168.196.193]) by vms042.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JAY000KSD4L5J54@vms042.mailsrvcs.net> for net@freebsd.org; Wed, 27 Dec 2006 16:00:22 -0600 (CST) Date: Wed, 27 Dec 2006 17:00:19 -0500 From: Skip Ford In-reply-to: <4592AED6.4040508@ab.ote.we.lv> To: "Eugene M. Kim" Message-id: <20061227220019.GA1044@lucy.menantico.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline References: <4592AED6.4040508@ab.ote.we.lv> User-Agent: Mutt/1.4.2.1i Cc: net@freebsd.org Subject: Re: BIND running setuid with interface changes 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, 27 Dec 2006 22:00:26 -0000 Eugene M. Kim wrote: [snip] > Then, when a new address comes up (such as on a dynamically created L2TP > tun(4) interface), BIND tries to listen on it, but fails because it is > running setuid as bind: > > Dec 27 02:32:00 home named[1121]: listening on IPv4 interface tun0, 10.0.2.129#53 > Dec 27 02:32:00 home named[1121]: could not listen on UDP socket: permission denied > > The only workarounds that I can think of is either to run BIND as setuid > root, or to restart (not reload) BIND every time a new VPN connection > comes up, both of which I am not comfortable with. > > Any better ideas? mac_portacl(4) http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mac-portacl.html -- Skip From owner-freebsd-net@FreeBSD.ORG Wed Dec 27 22:37:11 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 315DD16A407 for ; Wed, 27 Dec 2006 22:37:11 +0000 (UTC) (envelope-from j.witteveen@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by mx1.freebsd.org (Postfix) with ESMTP id C0C0E13C47E for ; Wed, 27 Dec 2006 22:37:10 +0000 (UTC) (envelope-from j.witteveen@gmail.com) Received: by nf-out-0910.google.com with SMTP id x37so4964502nfc for ; Wed, 27 Dec 2006 14:37:09 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=AP07fjHFujIAqHMxq9D5MXIpW9+ho+RAtInEn1TWVJcV4DaGFbsu518RiUL/Gy4VLxGRAvWjRuLLQ0p7oW4IuvE9HtnAXBGWOFcg1doh87LA3ECgOdsh++XAfxpZhYirka0uU2gQDDW72DrkG8YN62wC8Izd24SOA++XdtCLfQQ= Received: by 10.49.26.18 with SMTP id d18mr17453576nfj.1167257548865; Wed, 27 Dec 2006 14:12:28 -0800 (PST) Received: by 10.48.207.6 with HTTP; Wed, 27 Dec 2006 14:12:28 -0800 (PST) Message-ID: <3993a4980612271412w51b74b3ana00ae6b084f9b9f6@mail.gmail.com> Date: Wed, 27 Dec 2006 23:12:28 +0100 From: "Jouke Witteveen" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Multicast not working as it did(?) 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, 27 Dec 2006 22:37:11 -0000 Hello, I'm trying to make wpa_supplicant work with wired drivers in FreeBSD (see [1] too). I copied some code from mtest (last updatet 3 years ago, but still present by default) and ran into a problem. When deleting a multicast address that was added with SIOCADDMULTI FreeBSD spits up a NOENT. All I can think of is that the address never got added. This seems to be possible, since my modified wpa_supplicant driver does not receive any packets. This behaviour is tested with 3c905TX (xl) and a Davicom 902 (dc) card. Any help on this issue is welcome, I suggest a review of mtest.c for the latest versions of FreeBSD. regards, - Jouke [1] http://lists.shmoo.com/pipermail/hostap/2006-December/014776.html From owner-freebsd-net@FreeBSD.ORG Wed Dec 27 22:45:33 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 10E4116A407 for ; Wed, 27 Dec 2006 22:45:33 +0000 (UTC) (envelope-from fbsd@synoptic.org) Received: from gort.synoptic.org (gort.synoptic.org [216.254.17.65]) by mx1.freebsd.org (Postfix) with ESMTP id CFA0413C46D for ; Wed, 27 Dec 2006 22:45:32 +0000 (UTC) (envelope-from fbsd@synoptic.org) Received: by gort.synoptic.org (Postfix, from userid 1000) id C200C6352813; Wed, 27 Dec 2006 14:18:44 -0800 (PST) Date: Wed, 27 Dec 2006 14:18:44 -0800 From: Matthew Hudson To: freebsd-net@freebsd.org Message-ID: <20061227221844.GA50395@gort.synoptic.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Subject: Re: Diagnose co-location networking problem 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, 27 Dec 2006 22:45:33 -0000 On Tue, Dec 26, 2006 at 06:45:39PM -0800, Stephan Wehner wrote: > So I am thinking the problem may be with the co-location operation. > > How can I make sure? How can I diagnose this? The only idea I had was > to run tcpdump on my Linux client (tcpdump host stbgo.org), and indeed > I can see entries lines this: > I troubleshoot issues just like this for a living so I hope I can be of some help. Others have already suggested some useful strategies so I'll try to focus on ones that I haven't seen mentioned yet. Off the bat based on what you've described I'd tend to suspect some sort of transparent proxy, be it a stateful firewall or a intermediary loadbalancer of some sort. The fact that your ssh connection from the same source IP (I'm assuming) isn't showing any symptoms would tend to de-emphasize layers 1-3 (IP on down to ethernet, ruling out packetloss due to ethernet duplex mismatch/cabling and bad IP routing, doesn't rule out rate limiting). However, if you've been experiencing intermittent pauses with your ssh session, even if they don't coincide with interruptions in http traffic then you may still have a packet loss issue. If you suspect packetloss, confirm with 'netstat -i' and look in the Ierrs and Oerrs columns, they should both be 0 if everything is spiff. Also check the TCP retransmit counters in 'netstat -s' (you will always have some retransmission, you just don't want a *lot* of it). I should note that I think this is a low probability based on symptoms. Actually based on the traffic snip you quoted, I tend to strongly suspect firewall/loadbalancer/proxy.. note the source IP: > 21:40:22.162536 192.168.2.54.35932 > 65.110.18.138.80: > S 1526509984:1526509984(0) win 5840 > (DF) the source IP is 192.168.2.54 which isn't a routable IP address. Unless you're coming through a VPN or are local to the network, this would be clear evidence that there is a box in the middle that's at least smart enough to do address translation. To troubleshoot everything else I would start with recording a full traffic capture from both the client and the server and try and reproduce the problem. It sounds like that shouldn't be a problem. On the client I'd run: tcpdump -n -s 1600 -i -w clientside.dmp host On the server I'd run tcpdump -n -s 1600 -i -w serverside.dmp Plan on clientside.dmp and serverside.dmp files getting large fast. That's ok, you just want to be sure to get everything. Let these two dumps run and then proceed to reproduce the problem. If you can, get a good mix of good connections vs failed ones. Then stop the dumps, it's time for analysis. For this, I'd recommend using the program 'tcptrace', which is in the ports tree. I'd start by looking in clientside.dmp for failed connection attempts/short connections. You can do this using the command tcptrace -n -b clientside.dmp and you should see something like this: hudson@Nikto:~/share > tcptrace -n -b dumpexample.dmp 1 arg remaining, starting with 'dumpexample.dmp' Ostermann's tcptrace -- version 6.6.1 -- Wed Nov 19, 2003 496 packets seen, 496 TCP packets traced elapsed wallclock time: 0:00:00.030771, 16119 pkts/sec analyzed trace file elapsed time: 0:00:25.364361 TCP connection info: 1: 10.192.4.16:59723 - 72.14.253.99:80 (a2b) 7> 7< (complete) 2: 195.64.132.11:29957 - 10.192.4.16:80 (c2d) 1> 3< 3: 10.192.4.16:51717 - 198.238.212.10:80 (e2f) 30> 41< 4: 10.192.4.16:64601 - 198.238.212.10:80 (g2h) 17> 9< 5: 10.192.4.16:54693 - 198.238.212.10:80 (i2j) 26> 15< (complete) 6: 10.192.4.16:65285 - 198.238.212.30:80 (k2l) 33> 52< 7: 10.192.4.16:54362 - 66.35.250.151:80 (m2n) 5> 5< (complete) 8: 10.192.4.16:65391 - 66.35.250.150:80 (o2p) 14> 16< (complete) This gives you a rough outline of the connections in the dump and tells you how many packets in either direction were sent. If the connection failed, you should see a very low packet count for the connection. Connection #2 in the above example would be suspect for instance. Once you have isolated an interesting connection, you can use tcpdump again to filter on that connection and get the full story: tcpdump -n -r dumpexample.dmp port 29957 My first hunch would be that there are intermittent connection establishment failures thanks to the firewall/loadbalancer. This would manifest itself as SYN's being seen on the client side that are not seen on the server side. (find a connection where SYN's aren't being answered in clientside.dmp and then check serverside.dmp to see if the SYN's are being received, crossreference by time). If the SYN's are making it to the server, then you have a server issue, if they aren't then we're still looking at a potential middlebox problem. When looking for the SYN's in the serverside dump, don't filter by IP address as it's possible that the failure is due to bad address translation somewhere... i.e. you may see SYN's being received at the same time that the client is sending them but with the wrong source IP address. If the problem isn't restricted to connection-establishment, then I'd look for connections in clientside.dmp that have long pauses in them and try to explain those pauses by comparing with serverside.dmp. To isolate connections with pauses in them, I'd again turn to the trusty 'tcptrace' program. This time however I'd use the '-l' ("long") switch to get more details on individual connections and grep for anomalies. Here's an example of tcptrace long output: TCP connection 1: host a: 10.192.4.16:59723 host b: 72.14.253.99:80 complete conn: yes first packet: Wed Dec 27 13:29:59.651504 2006 last packet: Wed Dec 27 13:30:02.302161 2006 elapsed time: 0:00:02.650656 total packets: 14 filename: dumpexample.dmp a->b: b->a: total packets: 7 total packets: 7 ack pkts sent: 6 ack pkts sent: 7 pure acks sent: 3 pure acks sent: 2 sack pkts sent: 0 sack pkts sent: 0 dsack pkts sent: 0 dsack pkts sent: 0 max sack blks/ack: 0 max sack blks/ack: 0 unique bytes sent: 1271 unique bytes sent: 2399 actual data pkts: 2 actual data pkts: 3 actual data bytes: 1271 actual data bytes: 2399 rexmt data pkts: 0 rexmt data pkts: 0 rexmt data bytes: 0 rexmt data bytes: 0 zwnd probe pkts: 0 zwnd probe pkts: 0 zwnd probe bytes: 0 zwnd probe bytes: 0 outoforder pkts: 0 outoforder pkts: 0 pushed data pkts: 2 pushed data pkts: 2 SYN/FIN pkts sent: 1/1 SYN/FIN pkts sent: 1/1 req 1323 ws/ts: Y/Y req 1323 ws/ts: N/N adv wind scale: 0 adv wind scale: 0 req sack: Y req sack: N sacks sent: 0 sacks sent: 0 urgent data pkts: 0 pkts urgent data pkts: 0 pkts urgent data bytes: 0 bytes urgent data bytes: 0 bytes mss requested: 1460 bytes mss requested: 1460 bytes max segm size: 762 bytes max segm size: 1430 bytes min segm size: 509 bytes min segm size: 151 bytes avg segm size: 635 bytes avg segm size: 799 bytes max win adv: 65535 bytes max win adv: 8190 bytes min win adv: 64882 bytes min win adv: 6444 bytes zero win adv: 0 times zero win adv: 0 times avg win adv: 65441 bytes avg win adv: 7317 bytes initial window: 509 bytes initial window: 2248 bytes initial window: 1 pkts initial window: 2 pkts ttl stream length: 1271 bytes ttl stream length: 2399 bytes missed data: 0 bytes missed data: 0 bytes truncated data: 0 bytes truncated data: 0 bytes truncated packets: 0 pkts truncated packets: 0 pkts data xmit time: 2.495 secs data xmit time: 2.566 secs idletime max: 2449.3 ms idletime max: 2519.2 ms throughput: 480 Bps throughput: 905 Bps I'd look at the fields 'elapsed time' and 'idletime max' (in the direction from the server to client only (in this case the "b->a" column), the other direction will always have long idle times due to the nature of HTTP). Some clever grepping should isolate interesting candidate connections which you can then isolate with tcpdump. At this point, if it is indeed a middlebox problem, there's probably not much you can do about it. But if you can isolate the symptoms and even provide example tcpdumps illustrating the problem, then you greatly increase the chances that your ISP's support staff can resolve the problem. Many times even if they know that a problem exists they may not know how to resolve it... having tcpdumps handy makes it easier for them to show the problem to someone else (say the firewall/loadbalancer vendor) who can tell them how to fix it. I know this from experience, I work at a company that makes loadbalancers. ;) Hope that helps, -- Matthew Hudson From owner-freebsd-net@FreeBSD.ORG Thu Dec 28 03:22:06 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F3FB216A415; Thu, 28 Dec 2006 03:22:05 +0000 (UTC) (envelope-from santosh.rastapur@neterion.com) Received: from barracuda.s2io.com (barracuda.s2io.com [72.1.205.138]) by mx1.freebsd.org (Postfix) with ESMTP id CB36713C463; Thu, 28 Dec 2006 03:22:05 +0000 (UTC) (envelope-from santosh.rastapur@neterion.com) X-ASG-Debug-ID: 1167275111-17879-16-2 X-Barracuda-URL: http://72.1.205.138:8000/cgi-bin/mark.cgi X-ASG-Whitelist: Client Received: from owa.neterion.com (unknown [72.1.205.142]) by barracuda.s2io.com (Spam Firewall) with ESMTP id 94BC22004986; Wed, 27 Dec 2006 22:05:11 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-ASG-Orig-Subj: TSO buffer size in 6.2 release Date: Wed, 27 Dec 2006 22:05:10 -0500 Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD77010FB358@nekter> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TSO buffer size in 6.2 release thread-index: AcclbpjGRCblM1JFT1eReJVCZj2nOQEuu/KA From: "Rastapur Santosh" To: X-Virus-Scanned: by Barracuda Spam Firewall at s2io.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=3.5 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=7.0 Cc: Andre Oppermann Subject: TSO buffer size in 6.2 release 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, 28 Dec 2006 03:22:06 -0000 Hi, After applying 6.x TSO patch to 6.2 RELEASE, in transmit routine, I am getting mbuf with buffer length around 2K with nttcp send. In FreeBSD current (7.0), I get mbufs with length around 64K. Is there a separate patch to 6.2 release for this? Thanks. -Santosh From owner-freebsd-net@FreeBSD.ORG Thu Dec 28 05:38:58 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B864D16A40F for ; Thu, 28 Dec 2006 05:38:58 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id 7BAEA13C46F for ; Thu, 28 Dec 2006 05:38:58 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so1240324ana for ; Wed, 27 Dec 2006 21:38:58 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=nTjv4hqLebP18Sk4+VB7/O04y+Rvvq+JjJDGkS18v6zgwSvpiMAJne7gfMMb5yGF876t2l94KDrDjQmMMdSKhpmKydy31MG2AjYOL6RLsbATUYBmka4UE7Cus5JP1I52c1LahS4adueJk1euGs907qvmTl2j6kymnY+cZnhddPo= Received: by 10.100.152.9 with SMTP id z9mr2188727and.1167282810054; Wed, 27 Dec 2006 21:13:30 -0800 (PST) Received: by 10.100.112.17 with HTTP; Wed, 27 Dec 2006 21:13:29 -0800 (PST) Message-ID: <2a41acea0612272113x13f5cac5jaf46e5129b59a604@mail.gmail.com> Date: Wed, 27 Dec 2006 21:13:30 -0800 From: "Jack Vogel" To: "Rastapur Santosh" In-Reply-To: <78C9135A3D2ECE4B8162EBDCE82CAD77010FB358@nekter> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <78C9135A3D2ECE4B8162EBDCE82CAD77010FB358@nekter> Cc: freebsd-net@freebsd.org, Andre Oppermann Subject: Re: TSO buffer size in 6.2 release 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, 28 Dec 2006 05:38:58 -0000 On 12/27/06, Rastapur Santosh wrote: > Hi, > > After applying 6.x TSO patch to 6.2 RELEASE, in transmit > routine, I am getting mbuf with buffer length around 2K with nttcp send. > In FreeBSD current (7.0), I get mbufs with length around 64K. Is there a > separate patch to 6.2 release for this? The patch for 6 is something I did, and its very dated at this point. I have not taken a look at it vs CURRENT in months. What needs to happen is the MFC, and that will be 6.3 not 6.2 I suspect. I am on vacation and not about to go investigating this right now, sorry :) Jack From owner-freebsd-net@FreeBSD.ORG Thu Dec 28 06:08:27 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7E89116A412 for ; Thu, 28 Dec 2006 06:08:27 +0000 (UTC) (envelope-from stephanwehner@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by mx1.freebsd.org (Postfix) with ESMTP id 1997013C475 for ; Thu, 28 Dec 2006 06:08:26 +0000 (UTC) (envelope-from stephanwehner@gmail.com) Received: by nf-out-0910.google.com with SMTP id x37so5064176nfc for ; Wed, 27 Dec 2006 22:08:26 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=q7rWBZHHjsaTMaZi4r9+fytS78eAb3GCOqp3NcWOQXobdgmYaPfwuk6pbEfZXQmDOlDciT3uLkrVi9Wrn2MO/rmoW6I7gYgB4nvf0cJi47ftOSU1bUAeuppZEhQArVOauKUN36U8sL31SHODq3/rfSSIyaP2EEwsMWr0biP6RNw= Received: by 10.78.47.15 with SMTP id u15mr276463huu.1167286105850; Wed, 27 Dec 2006 22:08:25 -0800 (PST) Received: by 10.78.142.3 with HTTP; Wed, 27 Dec 2006 22:08:25 -0800 (PST) Message-ID: Date: Wed, 27 Dec 2006 22:08:25 -0800 From: "Stephan Wehner" To: "Matthew Hudson" In-Reply-To: <20061227221844.GA50395@gort.synoptic.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061227221844.GA50395@gort.synoptic.org> Cc: freebsd-net@freebsd.org Subject: Re: Diagnose co-location networking problem 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, 28 Dec 2006 06:08:27 -0000 Ok, this is a little unfortunate: I can't run traceroute from the client PC (the service provider doesn't seem to like it). (Nor can I use ping) The server FreeBSD kernel doesn't support tcpdump. I should recompile it then, but not now. So I ran the netstat tests, seeing no other suggestion. Below is the output before and after "failed" accesses. If I understand, there seems no indication of lost packets. At least the problem is rather reproducible: run 'lynx -dump http://stbgo.org > /dev/null' in a loop, 15 times and a failure occurs. I also thought maybe the ssh session might be interfering, rather than showing a live connection; but without it the same occurs. Thanks a lot to all for now. Stephan # Both on client and server: $ netstat -i > /tmp/before $ netstat -s | grep -i ret >> /tmp/before ... run test .... recognize failure ... $ netstat -i > /tmp/after $ netstat -s | grep -i ret >> /tmp/after Client first. $ cat /tmp/before Kernel Interface table Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg eth0 1500 012471498 0 0 0 8604916 36 0 1 BMRU eth0: 1500 0 - no statistics available - BMRU eth0: 1500 0 - no statistics available - BMRU lo 16436 0 429696 0 0 0 429696 0 0 0 LRU 66656 segments retransmited TCPLostRetransmit: 0 TCPFastRetrans: 1233 TCPForwardRetrans: 18 TCPSlowStartRetrans: 476 $ cat /tmp/after Kernel Interface table Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg eth0 1500 012471903 0 0 0 8605107 36 0 1 BMRU eth0: 1500 0 - no statistics available - BMRU eth0: 1500 0 - no statistics available - BMRU lo 16436 0 429786 0 0 0 429786 0 0 0 LRU 66665 segments retransmited TCPLostRetransmit: 0 TCPFastRetrans: 1233 TCPForwardRetrans: 18 TCPSlowStartRetrans: 476 Now server $ cat /tmp/before_server Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll bge0 1500 00:0b:cd:4e:40:00 156342 3 146739 0 599 bge0 1500 65.110.18.136 df1 144448 - 145988 - - bge1* 1500 00:0b:cd:4e:41:11 0 0 0 0 0 pflog 33208 0 0 0 0 0 lo0 16384 34545 0 34545 0 0 lo0 16384 your-net localhost.stephan 34454 - 34454 - - pfsyn 2020 0 0 0 0 0 565 data packets (372083 bytes) retransmitted 38 data packets unnecessarily retransmitted 540 retransmit timeouts 156 retransmitted 0 invalid return addresses 0 no return routes $ cat /tmp/after_server Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll bge0 1500 00:0b:cd:4e:40:00 156579 3 146957 0 599 bge0 1500 65.110.18.136 df1 144671 - 146206 - - bge1* 1500 00:0b:cd:4e:41:11 0 0 0 0 0 pflog 33208 0 0 0 0 0 lo0 16384 34685 0 34685 0 0 lo0 16384 your-net localhost.stephan 34594 - 34594 - - pfsyn 2020 0 0 0 0 0 565 data packets (372083 bytes) retransmitted 38 data packets unnecessarily retransmitted 540 retransmit timeouts 156 retransmitted 0 invalid return addresses 0 no return routes From owner-freebsd-net@FreeBSD.ORG Thu Dec 28 12:07:51 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7775016A403 for ; Thu, 28 Dec 2006 12:07:51 +0000 (UTC) (envelope-from bv@bilver.wjv.com) Received: from wjv.com (fl-65-40-24-38.sta.embarqhsd.net [65.40.24.38]) by mx1.freebsd.org (Postfix) with ESMTP id 0B18F13C466 for ; Thu, 28 Dec 2006 12:07:50 +0000 (UTC) (envelope-from bv@bilver.wjv.com) Received: from bilver.wjv.com (localhost.wjv.com [127.0.0.1]) by wjv.com (8.13.8/8.13.1) with ESMTP id kBSC7lhn071856; Thu, 28 Dec 2006 07:07:47 -0500 (EST) (envelope-from bv@bilver.wjv.com) Received: (from bv@localhost) by bilver.wjv.com (8.13.8/8.13.1/Submit) id kBSC7fZ0071855; Thu, 28 Dec 2006 07:07:41 -0500 (EST) (envelope-from bv) Date: Thu, 28 Dec 2006 07:07:41 -0500 From: Bill Vermillion To: Stephan Wehner Message-ID: <20061228120741.GB71581@wjv.com> References: <20061227221844.GA50395@gort.synoptic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Organization: W.J.Vermillion / Orlando - Winter Park ReplyTo: bv@wjv.com X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on bilver.wjv.com Cc: freebsd-net@freebsd.org, Matthew Hudson Subject: Re: Diagnose co-location networking problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bv@wjv.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Dec 2006 12:07:51 -0000 On or about Wed, Dec 27, 2006 at 22:08 , while attempting a Zarathustra emulation Stephan Wehner thus spake: > Ok, this is a little unfortunate: I can't run traceroute from > the client PC (the service provider doesn't seem to like it). > (Nor can I use ping) So login to the FreeBSD machine and trace back to your client IP - or as close as you can get. That may mean just to the edge of your current provider but that may give you some idea. Bill -- Bill Vermillion - bv @ wjv . com From owner-freebsd-net@FreeBSD.ORG Thu Dec 28 12:52:18 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0238A16A403 for ; Thu, 28 Dec 2006 12:52:18 +0000 (UTC) (envelope-from steve@localhost.lu) Received: from linion.ion.lu (linion.ion.lu [80.90.47.168]) by mx1.freebsd.org (Postfix) with ESMTP id 43A2813C49E for ; Thu, 28 Dec 2006 12:52:17 +0000 (UTC) (envelope-from steve@localhost.lu) Received: (qmail 94823 invoked by uid 89); 28 Dec 2006 13:26:33 +0100 Received: from localhost (HELO ?127.0.0.1?) (steve@localhost.lu@127.0.0.1) by linion.ion.lu with SMTP; 28 Dec 2006 13:26:33 +0100 Message-ID: <4593B7BA.7020803@localhost.lu> Date: Thu, 28 Dec 2006 13:25:30 +0100 From: Steve Clement User-Agent: Thunderbird 1.5.0.9 (X11/20061222) MIME-Version: 1.0 To: Gavin Atkinson References: <20061225231213.O11113@ury.york.ac.uk> In-Reply-To: <20061225231213.O11113@ury.york.ac.uk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org, damien.bergamini@free.fr, gabor@FreeBSD.org Subject: Re: wpi (Intel 3945) driver 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, 28 Dec 2006 12:52:18 -0000 Gavin Atkinson wrote: > > Hi all, > > Is anybody actively developing this driver? > I don't think so! Thanks go out to Damien (merci bcp) who kicked it all of but had some issues with the people if I read correctly. Although it's never too late to ask whether he has made any other improvements or is maybe willing to help develop it further. At least there are people Using it as opposed to develop it, so we can test it! I use the wpi driver in the following way: kldload if_wpi load wpa_supplicant and connect to my WPA encrypted network and voilà we're online. I never had to load the wpi_ucode module for the firmware, if I do so it tells me it can't find the firmware! It throws quite a lot of 702 errors at me, especially when there is heavy traffic load! Also I am currently in Berlin at the CCC (events.ccc.de) and the WiFi traffic is quite heavy and I don't get a packet out to the world (I can sniff the traffic) but obtaining a dhcp-lease or any other active communication is impossible. also when I try to unload the driver it wouldn't unload. So I did repeatedly: kldunload if_wpi kldunload if_wpi kldunload if_wpi kldunload if_wpi kldunload if_wpi and by the fifth time the kernel crashes with a page fault, now I don't know whether that is a Kernel issue or a driver issue, who handles unload requests? I guess putting Gavin's work online/somewhere would be a good first step in pursuing this issue. Anyway, thanks a lot for your time and let's do something about the development of this driver! cheers, Steve From owner-freebsd-net@FreeBSD.ORG Thu Dec 28 16:31:20 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 83EB316A403 for ; Thu, 28 Dec 2006 16:31:20 +0000 (UTC) (envelope-from stephanwehner@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by mx1.freebsd.org (Postfix) with ESMTP id 1E2FA13C47C for ; Thu, 28 Dec 2006 16:31:19 +0000 (UTC) (envelope-from stephanwehner@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so3637890uge for ; Thu, 28 Dec 2006 08:31:19 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ibNL9ZZkFBGGm5x+YbukN5Kkw6JNPq+qyZLT3gYR04cm0MZkV30bb1nPSGt0Rx2UWPF2Ck8Y83EDO+9k50Qs2kCOweCHQKpFa2U0XZt/UKiAcpQekqd1GYTUtENfFrmDFWy4vtY8RH+q93iCp7JNxFcRtYZNuvj64oh1Dnk1h1M= Received: by 10.78.138.6 with SMTP id l6mr1880544hud.1167323478327; Thu, 28 Dec 2006 08:31:18 -0800 (PST) Received: by 10.78.142.3 with HTTP; Thu, 28 Dec 2006 08:31:18 -0800 (PST) Message-ID: Date: Thu, 28 Dec 2006 08:31:18 -0800 From: "Stephan Wehner" To: bv@wjv.com In-Reply-To: <20061228120741.GB71581@wjv.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061227221844.GA50395@gort.synoptic.org> <20061228120741.GB71581@wjv.com> Cc: freebsd-net@freebsd.org, Matthew Hudson Subject: Re: Diagnose co-location networking problem 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, 28 Dec 2006 16:31:20 -0000 > So login to the FreeBSD machine and trace back to your client IP - > or as close as you can get. That may mean just to the edge of your > current provider but that may give you some idea. Ok, here is the result. $ traceroute 64.114.83.92 traceroute to 64.114.83.92 (64.114.83.92), 64 hops max, 40 byte packets 1 VPS-18-137.virtualprivateservers.ca (65.110.18.137) 1.098 ms 0.991 ms 1.151 ms 2 a.core.65-110-0-1.van.data-fortress.com (65.110.0.1) 4.357 ms 1.557 ms 1.147 ms 3 64.69.87.37 (64.69.87.37) 1.740 ms 1.255 ms 1.150 ms 4 216.187.88.241 (216.187.88.241) 1.742 ms 2.438 ms 2.182 ms 5 204.239.129.214 (204.239.129.214) 1.910 ms 2.881 ms 3.489 ms 6 nwmrbc01dr02.bb.telus.com (154.11.4.72) 5.095 ms 3.309 ms 2.322 ms 7 64.114.45.106 (64.114.45.106) 6.555 ms 80.103 ms 9.048 ms 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * What does this tell?? By the way, other servers look "good". Meaning when I repeatedly access other websites (not my own) I don't see failures. Stephan > > Bill > -- > Bill Vermillion - bv @ wjv . com > -- Stephan Wehner > http://stephan.sugarmotor.org > http://stephansmap.org > http://www.trafficlife.com > http://www.buckmaster.ca From owner-freebsd-net@FreeBSD.ORG Thu Dec 28 17:20:26 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 259A816A403 for ; Thu, 28 Dec 2006 17:20:26 +0000 (UTC) (envelope-from robertusn@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.236]) by mx1.freebsd.org (Postfix) with ESMTP id E237713C473 for ; Thu, 28 Dec 2006 17:20:25 +0000 (UTC) (envelope-from robertusn@gmail.com) Received: by nz-out-0506.google.com with SMTP id i11so2003310nzh for ; Thu, 28 Dec 2006 09:20:25 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=h10T1Vhni1VFf4m+4piJmOce6rycoaf8yi/+hszVGMOv0TquHOiLfhFWm+AEKYZQvC8kvY208/Mq6ABy4w73KVGD20GRjkRNV380KRxH1EUEgTsaYqxSdaDTzAOD4GSMA6UBMr3FlQqthGMF9u7oCmkEO7G8SXHw76LF6N6rLO4= Received: by 10.65.100.14 with SMTP id c14mr21290618qbm.1167324702496; Thu, 28 Dec 2006 08:51:42 -0800 (PST) Received: by 10.65.81.17 with HTTP; Thu, 28 Dec 2006 08:51:42 -0800 (PST) Message-ID: <3713853f0612280851m243f9e75u918c0969b038a865@mail.gmail.com> Date: Thu, 28 Dec 2006 17:51:42 +0100 From: "Robert Usle" Sender: robertusn@gmail.com To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 472bba6669352cf1 Subject: ipsec-tools 0.6.6 problem 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, 28 Dec 2006 17:20:26 -0000 Hello list & Yvan. This is my second post regarding the one from: http://osdir.com/ml/freebsd-net@freebsd.org/msg20572.html Sorry for not replying, but my email provider simply sucks. Here's more info. --------------------------------- racoon.conf path include "/usr/local/etc/racoon"; path pre_shared_key "/usr/local/etc/racoon/psk.txt"; path certificate "/usr/local/etc/racoon/cert"; log debug; padding { maximum_length 20; # maximum padding length. randomize off; # enable randomize length. strict_check off; # enable strict check. exclusive_tail off; # extract last one octet. } listen { #isakmp ::1 [7000]; isakmp 89.217.11.250 [500]; isakmp 10.0.5.1 [500]; #admin [7002]; # administrative port for racoonctl. #strict_address; # requires that all addresses must be bound. } timer { # These value can be changed per remote node. counter 5; # maximum trying count to send. interval 2 sec; # maximum interval to resend. persend 1; # the number of packets per send. # maximum time to wait for completing each phase. phase1 60 sec; phase2 15 sec; } remote anonymous { exchange_mode aggressive,main,base; lifetime time 24 hour; proposal { encryption_algorithm 3des; hash_algorithm sha1; authentication_method pre_shared_key; dh_group 2; } } sainfo anonymous { lifetime time 12 hour ; encryption_algorithm des, 3des, des_iv64, des_iv32, null_enc, rijndael, blowfish; authentication_algorithm hmac_sha1, hmac_md5; compression_algorithm deflate ; } ----- kernel config: machine i386 cpu I686_CPU ident TUNED maxusers 512 makeoptions COPTFLAGS="-O2 -pipe" # FIREWALL and TrafficShaper options IPFIREWALL options IPFIREWALL_FORWARD options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=100 options IPFIREWALL_DEFAULT_TO_ACCEPT options IPFW2 options IPDIVERT options DUMMYNET options DEVICE_POLLING options HZ=2000 options MATH_EMULATE #Support for x87 emulation options INET #InterNETworking #options INET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options FFS_ROOT #FFS usable as root device [keep this!] options SOFTUPDATES #Enable FFS soft updates support options UFS_DIRHASH #Improve performance on big directories options MFS #Memory Filesystem #options MD_ROOT #MD is a potential root device #options NFS #Network Filesystem #options NFS_ROOT #NFS usable as root device, NFS required #options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem options CD9660_ROOT #CD-ROM usable as root, CD9660 required options PROCFS #Process filesystem ...skipping... pseudo-device ether # Ethernet support #pseudo-device sl 1 # Kernel SLIP #pseudo-device ppp 1 # Kernel PPP #pseudo-device tun # Packet tunnel. pseudo-device pty # Pseudo-ttys (telnet etc) pseudo-device md # Memory "disks" pseudo-device gif # IPv6 and IPv4 tunneling #pseudo-device faith 1 # IPv6-to-IPv4 relaying (translation) # The `bpf' pseudo-device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! pseudo-device bpf #Berkeley packet filter # USB support #device uhci # UHCI PCI->USB interface #device ohci # OHCI PCI->USB interface #device usb # USB Bus (required) #device ugen # Generic #device uhid # "Human Interface Devices" #device ukbd # Keyboard #device ulpt # Printer #device umass # Disks/Mass storage - Requires scbus and da #device ums # Mouse #device uscanner # Scanners #device urio # Diamond Rio MP3 Player ## USB Ethernet, requires mii #device aue # ADMtek USB ethernet #device cue # CATC USB ethernet #device kue # Kawasaki LSI USB ethernet # # FireWire support #device firewire # FireWire bus code #device sbp # SCSI over FireWire (Requires scbus and da) #device fwe # Ethernet over FireWire (non-standard!) #options DISABLE_PSE # Quota options QUOTA #enable disk quotas options IPSEC #IP security options IPSEC_ESP #IP security (crypto; define w/ IPSEC) ---------------------------------------------------------------------------------------- ----uname -a FreeBSD wall.s93l.pl 4.11-STABLE FreeBSD 4.11-STABLE #5: Sat Nov 18 09:14:30 CET 2006 root@wall.s93l.pl:/usr/obj/usr/src/sys/TUNED i386 --- /var/log/racoon.log 2006-12-28 17:30:49: INFO: @(#)ipsec-tools 0.6.6 (http://ipsec-tools.sourceforge.net) 2006-12-28 17:30:49: INFO: @(#)This product linked OpenSSL 0.9.7d-p1 17 Mar 2004 (http://www.openssl.org/) 2006-12-28 17:30:49: DEBUG: hmac(modp1024) 2006-12-28 17:30:49: DEBUG: compression algorithm can not be checked because sadb message doesn't support it. 2006-12-28 17:30:49: INFO: 10.0.5.1[500] used as isakmp port (fd=5) 2006-12-28 17:30:49: INFO: 89.217.11.250[500] used as isakmp port (fd=6) 2006-12-28 17:30:49: DEBUG: get pfkey X_SPDDUMP message 2006-12-28 17:30:49: DEBUG: get pfkey X_SPDDUMP message 2006-12-28 17:30:49: DEBUG: sub:0xbfbff524: 0.0.0.0/0[0] 192.168.2.0/24[0] proto=any dir=out 2006-12-28 17:30:49: DEBUG: db :0x80a5408: 192.168.2.0/24[0] 0.0.0.0/0[0] proto=any dir=in 2006-12-28 17:30:49: DEBUG: msg 1 not interesting 2006-12-28 17:30:49: DEBUG: caught rtm:2, need update interface address list 2006-12-28 17:30:49: DEBUG: msg 1 not interesting 2006-12-28 17:30:49: DEBUG: caught rtm:2, need update interface address list 2006-12-28 17:30:49: DEBUG: msg 1 not interesting 2006-12-28 17:30:49: DEBUG: caught rtm:2, need update interface address list 2006-12-28 17:30:50: DEBUG: msg 5 not interesting 2006-12-28 17:30:50: DEBUG: msg 1 not interesting 2006-12-28 17:30:50: DEBUG: caught rtm:2, need update interface address list 2006-12-28 17:30:50: DEBUG: msg 1 not interesting and so on..... infinite loop with 'caught rtm;2, need update interface address list --------------------------------------- I was trying to establish a vpn connection with Win XP host, now trying with asmax br-604G. There are 2 setkey commands now, (/usr/sbin/ & /usr/local/sbin) can I use both ? Also, sometimes I'm getting 'unsupported PF_KEY message REGISTER' after running setkey Let me know if you need more info, -- Robert From owner-freebsd-net@FreeBSD.ORG Thu Dec 28 17:31:45 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1D3F216A403 for ; Thu, 28 Dec 2006 17:31:45 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (noop.in-addr.com [208.58.23.51]) by mx1.freebsd.org (Postfix) with ESMTP id EA6AA13C466 for ; Thu, 28 Dec 2006 17:31:44 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from gjp by noop.in-addr.com with local (Exim 4.54 (FreeBSD)) id 1Gzz6U-000BlY-Nm; Thu, 28 Dec 2006 12:31:42 -0500 Date: Thu, 28 Dec 2006 12:31:42 -0500 From: Gary Palmer To: Stephan Wehner Message-ID: <20061228173142.GB13257@in-addr.com> Mail-Followup-To: Stephan Wehner , Matthew Hudson , freebsd-net@freebsd.org References: <20061227221844.GA50395@gort.synoptic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: freebsd-net@freebsd.org, Matthew Hudson Subject: Re: Diagnose co-location networking problem 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, 28 Dec 2006 17:31:45 -0000 On Wed, Dec 27, 2006 at 10:08:25PM -0800, Stephan Wehner wrote: > Ok, this is a little unfortunate: I can't run traceroute from the client PC > (the service provider doesn't seem to like it). (Nor can I use ping) /usr/ports/net/tcptraceroute You should normally be able to use tcptraceroute to get path information to systems that are listening on a TCP port (e.g. a web or mail server). You can try ports that aren't open on the other end, but that may be less useful. From owner-freebsd-net@FreeBSD.ORG Thu Dec 28 20:31:01 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 543FA16A407 for ; Thu, 28 Dec 2006 20:31:01 +0000 (UTC) (envelope-from fbsd@synoptic.org) Received: from gort.synoptic.org (gort.synoptic.org [216.254.17.65]) by mx1.freebsd.org (Postfix) with ESMTP id 242E113C466 for ; Thu, 28 Dec 2006 20:31:01 +0000 (UTC) (envelope-from fbsd@synoptic.org) Received: by gort.synoptic.org (Postfix, from userid 1000) id D1B8A6352814; Thu, 28 Dec 2006 12:31:00 -0800 (PST) Date: Thu, 28 Dec 2006 12:31:00 -0800 From: Matthew Hudson To: Stephan Wehner Message-ID: <20061228203100.GA1165@gort.synoptic.org> References: <20061227221844.GA50395@gort.synoptic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Cc: freebsd-net@freebsd.org Subject: Re: Diagnose co-location networking problem 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, 28 Dec 2006 20:31:01 -0000 On Wed, Dec 27, 2006 at 10:08:25PM -0800, Stephan Wehner wrote: > The server FreeBSD kernel doesn't support tcpdump. I should recompile it > then, but not now. Ok, that explains the private 192.168 IP address I saw in your earlier dumps, it was from the client (a detail mentioned but that I overlooked). > So I ran the netstat tests, seeing no other suggestion. Below is the output > before and after "failed" accesses. If I understand, there seems no > indication of lost packets. Actually there's significant indication of lost packets and clues that point to the location of the problem. I'll explain. > At least the problem is rather reproducible: run 'lynx -dump > http://stbgo.org > /dev/null' in a loop, 15 times and a failure occurs. I > also thought maybe the ssh session might be interfering, rather than > showing a live connection; but without it the same occurs. Generally two TCP connections on different sockets will never interfere with each other, except in extreme examples of congestion or pathologically configured address-translating gateways. > # Both on client and server: > $ netstat -i > /tmp/before > $ netstat -s | grep -i ret >> /tmp/before > ... run test .... recognize failure ... > $ netstat -i > /tmp/after > $ netstat -s | grep -i ret >> /tmp/after > > Client first. > > $ cat /tmp/before > Kernel Interface table > Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR > Flg > eth0 1500 012471498 0 0 0 8604916 36 0 1 > BMRU > eth0: 1500 0 - no statistics available - BMRU > eth0: 1500 0 - no statistics available - BMRU > lo 16436 0 429696 0 0 0 429696 0 0 0 > LRU > 66656 segments retransmited > TCPLostRetransmit: 0 > TCPFastRetrans: 1233 > TCPForwardRetrans: 18 > TCPSlowStartRetrans: 476 > $ cat /tmp/after > Kernel Interface table > Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR > Flg > eth0 1500 012471903 0 0 0 8605107 36 0 1 > BMRU > eth0: 1500 0 - no statistics available - BMRU > eth0: 1500 0 - no statistics available - BMRU > lo 16436 0 429786 0 0 0 429786 0 0 0 > LRU > 66665 segments retransmited > TCPLostRetransmit: 0 > TCPFastRetrans: 1233 > TCPForwardRetrans: 18 > TCPSlowStartRetrans: 476 So we're looking at the client here and there are few things of note: 1. No significant interface errors are being recorded so it's not a layer-2 (ethernet) issue. 2. The retansmit count went up by 9 while the overall transmit count went up by 191 packets, suggesting an approximate transient packetloss rate of 4.7% (9/191, fuzzy math) during the test which is significantly greater than the system-wide average of 0.8% (66665/8605107). Thus this possibly suggests that the client saw an abormal packetloss rate during the test. It may be the case that all of the successful connections experienced no packet loss and only the failed connect generated the retransmits. I'm not sure if initial SYN retransmits get counted in this column or not but I believe this still may be significant. (The assumptions made in these calculations are so grossly oversimplified that the evidence derived from them is weak at best). 3. The loopback saw 90 packets of activity. I don't know how long this test ran but that could be considered a little chatty. As a longshot, I'd run a tcpdump on loopback and run the test again, simply to make sure that no traffic is unintentionally getting diverted over the loopback interface (unlikely but I've actuallly seen bugs/bad firewall configs do this). > Now server > $ cat /tmp/before_server > Name Mtu Network Address Ipkts Ierrs Opkts Oerrs > Coll > bge0 1500 00:0b:cd:4e:40:00 156342 3 146739 0 > 599 bge0 1500 65.110.18.136 df1 144448 - 145988 > - - bge1* 1500 00:0b:cd:4e:41:11 0 0 0 > 0 0 pflog 33208 0 0 0 > 0 0 lo0 16384 34545 0 34545 > 0 0 lo0 16384 your-net localhost.stephan 34454 - 34454 > - - pfsyn 2020 0 0 0 > 0 0 565 data packets (372083 bytes) retransmitted > 38 data packets unnecessarily retransmitted > 540 retransmit timeouts > 156 retransmitted > 0 invalid return addresses > 0 no return routes > $ cat /tmp/after_server > Name Mtu Network Address Ipkts Ierrs Opkts Oerrs > Coll > bge0 1500 00:0b:cd:4e:40:00 156579 3 146957 0 > 599 bge0 1500 65.110.18.136 df1 144671 - 146206 > - - bge1* 1500 00:0b:cd:4e:41:11 0 0 0 > 0 0 pflog 33208 0 0 0 > 0 0 lo0 16384 34685 0 34685 > 0 0 lo0 16384 your-net localhost.stephan 34594 - 34594 > - - pfsyn 2020 0 0 0 > 0 0 565 data packets (372083 bytes) retransmitted > 38 data packets unnecessarily retransmitted > 540 retransmit timeouts > 156 retransmitted > 0 invalid return addresses > 0 no return routes And here are the server stats which seem to show very little but in fact are quite informative. 1. No significant interface errors, again ruling out layer-2. 2. pflog and pfsyn devices are registered in the kernel, suggesting PF firewalling has been compiled in. It doesn't seem that pflog is being used at all but this does beg the qustion, are you using any packetfiltering on the server? If so, I'd suggest disabling the packetfilter entirely and retesting to see if the issue is reproducable. 3. The retransmit count has gone up by zero, suggesting the server never sent a packet that it later had to retransmit. This strongly suggests to me that the nature of the connection problems is that the server never sees the client's SYN packets. This is fairly strong evidence pointing to an intelligent filtering device / proxy in the middle of the connection. (or even a firewall configuration on the server itself). Offhand, here's another test you can run: try and determine if this connection failure behavior is specific to HTTP or general to all TCP services. So far you've mentioned no troubles with SSH, I think you should test that further. Set up a similar test to your HTTP test but with SSH... I'd probably set up public-key authentication on a account on the server so that I could log in without a password and then run simple remote commands over ssh on the server: ssh myserver echo boink over and over again to see if any of those connections fail with a frequency similar to the HTTP test. If you're unable to reproduce the same failure behavior with a test like this then that suggests that the problem is only specific to HTTP which is practically a smoking gun that this is a firewall/loadbalancer/middlebox issue. You need some smarts in the middle to selectively interfere with one type of TCP traffic and not another.. there's no way that a routing problem could be so selective. It's also still possible that this could be a kernel issue since you've clearly tweaked your configuration (compiled out bpf, compiled in PF).. if you compile a GENERIC kernel and run it, can the test be reproduced? This is a more costly test but one to consider if all else fails. Also, there's another possibility. I noticed in your earlier messages that the IP address of the server is 65.110.18.138 which in-addr.arpa maps to VPS-18-138.virtualprivateservers.ca. Looking at virtualprivateservers.ca's website it seems that they specialize in virtualized servers, begging the question: is your server running in a virtual server (xen, whatnot)? If so then that opens up a slew of other possible issues and is important information to know. Oh, also, going back to the 198.168 address seen in the client dumps, it's clear that you're going through a NAT firewall or VPN or something on the way to your server. Thus are you able to reproduce this problem from a different external network? Actually, I just realized that you've provided enough information for me to run this test myself which I've now done. I ran the following test; i=0; while true; do ((i++)); echo $i; curl http://stbgo.org > /dev/null; done I was able to make over 64 consecutive connections without a single failure before I stopped the test (didn't want to spam your site). How sure are you that this isn't a client-side problem? cheers. -- Matthew Hudson > _______________________________________________ > 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 Thu Dec 28 21:46:46 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8662C16A407 for ; Thu, 28 Dec 2006 21:46:46 +0000 (UTC) (envelope-from bv@bilver.wjv.com) Received: from wjv.com (fl-65-40-24-38.sta.embarqhsd.net [65.40.24.38]) by mx1.freebsd.org (Postfix) with ESMTP id 0F3CC13C478 for ; Thu, 28 Dec 2006 21:46:45 +0000 (UTC) (envelope-from bv@bilver.wjv.com) Received: from bilver.wjv.com (localhost.wjv.com [127.0.0.1]) by wjv.com (8.13.8/8.13.1) with ESMTP id kBSLkfiL076574; Thu, 28 Dec 2006 16:46:41 -0500 (EST) (envelope-from bv@bilver.wjv.com) Received: (from bv@localhost) by bilver.wjv.com (8.13.8/8.13.1/Submit) id kBSLkVqe076573; Thu, 28 Dec 2006 16:46:31 -0500 (EST) (envelope-from bv) Date: Thu, 28 Dec 2006 16:46:31 -0500 From: Bill Vermillion To: Stephan Wehner Message-ID: <20061228214631.GA76315@wjv.com> References: <20061227221844.GA50395@gort.synoptic.org> <20061228120741.GB71581@wjv.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Organization: W.J.Vermillion / Orlando - Winter Park ReplyTo: bv@wjv.com X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on bilver.wjv.com Cc: freebsd-net@freebsd.org, Matthew Hudson Subject: Re: Diagnose co-location networking problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bv@wjv.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Dec 2006 21:46:46 -0000 Wise men talk because they have something to say, however on Thu, Dec 28, 2006 at 08:31 , Stephan Wehner just had to say something so we heard: > >So login to the FreeBSD machine and trace back to your client IP - > >or as close as you can get. That may mean just to the edge of your > >current provider but that may give you some idea. > Ok, here is the result. > $ traceroute 64.114.83.92 > traceroute to 64.114.83.92 (64.114.83.92), 64 hops max, 40 byte packets > 1 VPS-18-137.virtualprivateservers.ca (65.110.18.137) 1.098 ms > 0.991 ms 1.151 ms > 2 a.core.65-110-0-1.van.data-fortress.com (65.110.0.1) 4.357 ms > 1.557 ms 1.147 ms > 3 64.69.87.37 (64.69.87.37) 1.740 ms 1.255 ms 1.150 ms > 4 216.187.88.241 (216.187.88.241) 1.742 ms 2.438 ms 2.182 ms > 5 204.239.129.214 (204.239.129.214) 1.910 ms 2.881 ms 3.489 ms > 6 nwmrbc01dr02.bb.telus.com (154.11.4.72) 5.095 ms 3.309 ms 2.322 ms > 7 64.114.45.106 (64.114.45.106) 6.555 ms 80.103 ms 9.048 ms > 8 * * * > 9 * * * > 10 * * * > 11 * * * > 12 * * * > > What does this tell?? Well there in no name associated with 64.114.45.106. Whos shows that is allocated to Telus Communications in Burnaby, British Columbia. The IP right before that is also a Telus IP. So the next question is - what connects to 64.114.45.106. Is that an IP assigned to you and then you use NAT and/oa PAT to translate to local address. You target IP is in the same block that Telos is allocated as they have 64.114.0.0 thru 64.114.255.255 The target IP does have a name associated with it and that is zz83902.cipherkey.net. Cipherkey.net is shown as being located in Richmond BC. Are they providing services for you. If so you might check with them. > By the way, other servers look "good". Meaning when I repeatedly > access other websites (not my own) I don't see failures. That sounds like throttling or as another poster said some firewall/filtering taking place. I find the same problem as you do tracing to www.buckmaster.ca. I can't traceroute to it as it stops resonding at 64.114.45.106, so I'd say they are blocking things at that point - which isn't helping at all :-( o However the site comes up very fast. Bill > -- > Stephan Wehner > >http://stephan.sugarmotor.org > >http://stephansmap.org > >http://www.trafficlife.com > >http://www.buckmaster.ca -- Bill Vermillion - bv @ wjv . com From owner-freebsd-net@FreeBSD.ORG Fri Dec 29 11:33:45 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D696C16A416; Fri, 29 Dec 2006 11:33:45 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.freebsd.org (Postfix) with ESMTP id 1A30913C457; Fri, 29 Dec 2006 11:33:44 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.3) with ESMTP id kBT96239077747; Fri, 29 Dec 2006 12:07:18 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.3/Submit) id kBT95vXO077740; Fri, 29 Dec 2006 12:05:57 +0300 (MSK) (envelope-from yar) Date: Fri, 29 Dec 2006 12:05:56 +0300 From: Yar Tikhiy To: Julian Elischer Message-ID: <20061229090556.GD76083@comp.chem.msu.su> References: <457DCD47.5090004@elischer.org> <200612120045.41425.max@love2party.net> <4583119B.20608@elischer.org> <200612160446.02644.max@love2party.net> <4584CE0C.3020307@elischer.org> <458C426A.9060604@elischer.org> <20061224093951.GD49045@comp.chem.msu.su> <459032EA.1030601@elischer.org> <20061226061610.GD81280@comp.chem.msu.su> <459177B0.2030006@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <459177B0.2030006@elischer.org> User-Agent: Mutt/1.5.9i Cc: Max Laier , Andre Oppermann , freebsd-net@freebsd.org Subject: Re: [was] addition to ipfw (read vlans from bridge).. 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, 29 Dec 2006 11:33:46 -0000 On Tue, Dec 26, 2006 at 11:27:44AM -0800, Julian Elischer wrote: > Yar Tikhiy wrote: > > >> > >>If what you are suggesting is that we pass into ipfw an 'offset' > >>into the packet as well as the packet, then yes I like that idea, > >>but I didn't see Andre suggest it. > > > >Do you consider only ideas by Andre? ;-) By Andre's opinion I > >meant this: > > > > Please have the ipfw code examine the vlan tag in the mbuf instead of > > fiddling with the mbuf contents. > > At the moment I plan the ipfw code to be unaware of vlan headers. > the plan is: > Add an argument to ipfw which is the offset in the packet where > the IP header may be found. Change the L2 users of ipfw to > leave the packet alone, but calculate the correct offset to pass to > ipfw. IPFW will make no assumptions as to what packet contents come > before the offset. Bridge and L2 callers of ipfw will > set the offset to non-0 values where the IP callers will set it to > 0. The non IP callers may make some MAC information available to the > ipfw code my some separate method, as it does at the moment. How this > is done will depend if we want to support Q-n-Q, and if so, how much.. Sounds very resonable to me. > >If we want ipfw to know of L2, then examining the VLAN tag in it > >is OK. If not really, then ipfw (or any pfil filter) can get just > >the offset of IP. > > What vlan tag? what if it's from an interface with no VLAN capacity.. > What we need to do is make a convention so that vlan tags are always > created at the lowest layer, even if HW vlan tagging is not supported, > so that all packets look as if they have come from HW capable packets, > and add code so that all non WH capable interfaces interpret Van tags at > the lowest level, that way vlan packets always look the same. It depends. As of now, a network interface driver passes up, e.g., to ether_input(), just what it has got. I.e., a driver in VLAN_HWTAG mode reads the tag from a hardware register and stores it in m_pkthdr.ether_vtag while a driver unaware of VLANs just passes up an 802.1q tagged frame it received. Perhaps it's ether_input() that should fix the things up for us so that we don't have to modify every VLAN-ignorant driver. However, converting the in-band tag to the out-of-band tag will take 1 m_pullup() call and 1 bcopy() call and 1 m_adj() call per tagged frame received: if ((m->m_flags & M_VLANTAG) == 0) { m_pullup(m, sizeof(struct ether_vlan_header)); evh = mtod(m, struct ether_vlan_header *); m->m_pkthdr.ether_vtag = ntohs(evh->evl_tag); m->m_flags |= M_VLANTAG; bcopy((char *)evh, (char *)evh + ETHER_VLAN_ENCAP_LEN, ETHER_HDR_LEN - ETHER_TYPE_LEN); m_adj(m, ETHER_VLAN_ENCAP_LEN); } Now I cannot tell if there will be a noticable impact on performance relative to the approach when we just do things conditionally depending on M_VLANTAG being set or unset, e.g.: if (m->m_flags & M_VLANTAG) { tag = m->m_pkthdr.ether_vtag; } else { m_pullup(m, sizeof(struct ether_vlan_header)); evh = mtod(m, struct ether_vlan_header *); tag = ntohs(evh->evl_tag); } /* now do things based on tag, e.g., filtering... */ > >Pardon, but you seem to mistake me for Max Laier. :-) OTOH this is > >a good chance for me to ask you a similar question: Did you recieve > >my mail on m_copym() usage in the kernel? I can resend it to you > >if you didn't. ;-) Honestly, I'd appreciate much if you dropped a > >line on the topic. > > sure.. My reader may have misfiled it under spam.. > > send it again.. Resent... Thanks! > >>>There is also work in progress to introduce nested VLANs AKA Q-n-Q. > >>>They seem to present a challenge to the scheme you are implementing. > >>not a permanent problem.. it could be modified to handle it. > >>but I'll take it into account in the next version if > >>you think it is a required feature.. what is the maximum > >>nesting level? > > > >Infinity. Why to introduce such a hard limit? > > > Because an infinite limit complicates things? Not necessarily. It depends on what we are trying to do with the tags. E.g., if we want to find the IP header offset, computing it by skipping over an unlimited number of VLAN headers won't be more complex than skipping over just 1-2 of them as we need a loop already. > > Well, 802.1ad allows > >just two tags: the customer (C) tag and the service (S) tag, but > >each gets its own ethertype. C-TAG's is 81-00 while S-TAG's is > >88-a8. I don't think we support the different ethertypes yet, so > >Q-n-Q is just the nesting of type 81-00 tags. (802.1ad appears a > >funny reading: it's essentially a patch against the 802.1q text!) > >Cisco and Juniper boxes seem to have a limit of two tags as well. > >While they may have a reason to (all those ASICs, you know,) we > >don't have it. Allowing for only two tags will tempt us into > >duplicating code instead of developing fair algos and interfaces. > > > > yes but algorythmically doing something we may never be required > to do may lead to unneeded code slowdown. I guess we can look at it > and decide. Sure. -- Yar From owner-freebsd-net@FreeBSD.ORG Fri Dec 29 11:47:27 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D7A4516A7D8 for ; Fri, 29 Dec 2006 11:47:27 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.freebsd.org (Postfix) with ESMTP id 6F72013C43E for ; Fri, 29 Dec 2006 11:47:27 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (7wb71sbranb4i6f3@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id kBT6r1hA058421; Thu, 28 Dec 2006 22:53:01 -0800 (PST) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id kBT6r1Dv058418; Thu, 28 Dec 2006 22:53:01 -0800 (PST) (envelope-from jmg) Date: Thu, 28 Dec 2006 22:53:01 -0800 From: John-Mark Gurney To: tanniru.sankar@wipro.com Message-ID: <20061229065300.GD817@funkthat.com> Mail-Followup-To: tanniru.sankar@wipro.com, freebsd-net@freebsd.org References: <8B9F8433B684734581EB519F1A3E5AF43D88A5@blr-m3-msg.wipro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8B9F8433B684734581EB519F1A3E5AF43D88A5@blr-m3-msg.wipro.com> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: freebsd-net@freebsd.org Subject: Re: ' bus_dmamap_load_mbuf_sg ( ) ' function usage problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Dec 2006 11:47:28 -0000 tanniru.sankar@wipro.com wrote this message on Fri, Dec 29, 2006 at 12:13 +0530: > Is it possible to allocate contigous memory of MJUM9BYTES ( 9K ) > and dmamap_load in one segment ? You can use bus_dmamem_alloc, which will use contigmalloc to allocate the necessary memory... You can then attach your own mbuf to the memory... Allocating contigous memory is an expensive operation... If the card doesn't support sg, you'll probably get better performance by not doing jumbo frames... > -----Original Message----- > From: John-Mark Gurney [mailto:gurney_j@resnet.uoregon.edu] > Sent: Tuesday, December 19, 2006 2:19 AM > To: Tanniru Sankar (WT01 - Computing Systems & Storage) > Cc: freebsd-net@freebsd.org > Subject: Re: ' bus_dmamap_load_mbuf_sg ( ) ' function usage problem > > tanniru.sankar@wipro.com wrote this message on Mon, Dec 18, 2006 at > 20:05 +0530: > > I am facing a problem on FreeBSD 7.0 during mapping using ' > > bus_dmamap_load_mbuf_sg ( ) ' function . > > Details are below. > > > > It is AMD 64 bit machine. I have allocated jumbo buffer memory > > using ' m_getcl ' function. > > > > mp = m_getjcl(M_DONTWAIT, MT_DATA, M_PKTHDR, MJUM9BYTES); > > > > As it got success here, I am trying to map the buffer as below. > > > > err = bus_dmamap_load_mbuf_sg(dma_tag_rx, map, mp, &seg, &cnt, > > BUS_DMA_NOWAIT); > > > > Here it is getting error for the mbuf size equal to MJUM9BYTES. > > The type of error is ' EFBIG '. > > > > I have create rx jumbo dma tag with attributes as following. > > [...] > > > MJUM9BYTES, /* Maximum Size */ > > > > 1 , /* Number of Segments */ > > > > MJUM9BYTES, /* Maximum Segment Size */ > > This is probably the problem... Most likely the buffer is > non-contiguous in memory, and needs 3 segments to satisfy the mapping... > Try increasing the number of segments and see what happens... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Fri Dec 29 11:54:22 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 71F9416A47C for ; Fri, 29 Dec 2006 11:54:22 +0000 (UTC) (envelope-from robertusn@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.228]) by mx1.freebsd.org (Postfix) with ESMTP id 217A613C468 for ; Fri, 29 Dec 2006 11:54:22 +0000 (UTC) (envelope-from robertusn@gmail.com) Received: by nz-out-0506.google.com with SMTP id i11so2115479nzh for ; Fri, 29 Dec 2006 03:54:21 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=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; b=RFRjAx++MvRtlSFbs3eFTx4/3CyQR2t9/uf4b+U5mFQWU4VDMF48Jo4rOS7HRxS2DMsBUnDXRvlOh2tcMi0CECpN8/JIuzMvkWcPbRAh2fKSkgYfJXcgqFTHe8Aaq4rnO0oRsjnw0NZXToPmIOI7rcYjR6v2V9AHPCTHv/h2GUQ= Received: by 10.64.210.3 with SMTP id i3mr22224614qbg.1167386477137; Fri, 29 Dec 2006 02:01:17 -0800 (PST) Received: by 10.65.81.17 with HTTP; Fri, 29 Dec 2006 02:01:17 -0800 (PST) Message-ID: <3713853f0612290201ta72f712gaced5fae4ad94aba@mail.gmail.com> Date: Fri, 29 Dec 2006 11:01:17 +0100 From: "Robert Usle" Sender: robertusn@gmail.com To: freebsd-net@freebsd.org In-Reply-To: <3713853f0612280851m243f9e75u918c0969b038a865@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3713853f0612280851m243f9e75u918c0969b038a865@mail.gmail.com> X-Google-Sender-Auth: 93be99cc9684a15d Subject: Re: ipsec-tools 0.6.6 problem 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, 29 Dec 2006 11:54:22 -0000 On 12/28/06, Robert Usle wrote: > Hello list & Yvan. > > This is my second post regarding the one from: > http://osdir.com/ml/freebsd-net@freebsd.org/msg20572.html > > Sorry for not replying, but my email provider simply sucks. > > Here's more info. > Also there seems to be a problem with racoon. It crashes. Here's the log with "log debug;" enabled in racoon.conf. ----- 2006-12-29 10:36:48: INFO: @(#)ipsec-tools 0.6.6 (http://ipsec-tools.sourceforge.net) 2006-12-29 10:36:48: INFO: @(#)This product linked OpenSSL 0.9.7d-p1 17 Mar 2004 (http://www.openssl.org/) 2006-12-29 10:36:48: DEBUG: hmac(modp1024) 2006-12-29 10:36:48: DEBUG: compression algorithm can not be checked because sadb message doesn't support it. 2006-12-29 10:36:48: DEBUG: compression algorithm can not be checked because sadb message doesn't support it. 2006-12-29 10:36:48: DEBUG: anonymous sainfo selected. 2006-12-29 10:36:48: INFO: 10.0.5.1[500] used as isakmp port (fd=5) 2006-12-29 10:36:48: DEBUG: get pfkey X_SPDDUMP message 2006-12-29 10:36:48: DEBUG: get pfkey X_SPDDUMP message 2006-12-29 10:36:48: DEBUG: sub:0xbfbff554: 0.0.0.0/0[0] 192.168.2.0/24[0] proto=any dir=out 2006-12-29 10:36:48: DEBUG: db :0x80a5408: 192.168.2.0/24[0] 0.0.0.0/0[0] proto=any dir=in 2006-12-29 10:36:48: DEBUG: msg 1 not interesting 2006-12-29 10:36:48: DEBUG: caught rtm:2, need update interface address list 2006-12-29 10:36:48: DEBUG: msg 1 not interesting 2006-12-29 10:36:48: DEBUG: caught rtm:2, need update interface address list 2006-12-29 10:36:48: DEBUG: msg 1 not interesting 2006-12-29 10:36:48: DEBUG: caught rtm:2, need update interface address list 2006-12-29 10:36:48: DEBUG: msg 1 not interesting 2006-12-29 10:36:48: DEBUG: caught rtm:2, need update interface address list 2006-12-29 10:36:48: DEBUG: msg 1 not interesting 2006-12-29 10:36:48: DEBUG: caught rtm:2, need update interface address list 2006-12-29 10:36:48: DEBUG: msg 1 not interesting 2006-12-29 10:36:48: DEBUG: caught rtm:2, need update interface address list 2006-12-29 10:36:48: DEBUG: msg 1 not interesting 2006-12-29 10:36:48: DEBUG: caught rtm:2, need update interface address list 2006-12-29 10:36:48: DEBUG: msg 1 not interesting 2006-12-29 10:36:48: DEBUG: caught rtm:2, need update interface address list 2006-12-29 10:36:48: DEBUG: msg 1 not interesting 2006-12-29 10:36:48: DEBUG: caught rtm:2, need update interface address list 2006-12-29 10:36:48: DEBUG: msg 1 not interesting 2006-12-29 10:36:48: DEBUG: caught rtm:2, need update interface address list 2006-12-29 10:36:48: DEBUG: msg 1 not interesting 2006-12-29 10:36:48: DEBUG: caught rtm:2, need update interface address list 2006-12-29 10:36:48: DEBUG: msg 1 not interesting 2006-12-29 10:36:48: DEBUG: caught rtm:2, need update interface address list 2006-12-29 10:36:48: DEBUG: msg 1 not interesting 2006-12-29 10:36:48: DEBUG: caught rtm:2, need update interface address list 2006-12-29 10:36:48: DEBUG: msg 1 not interesting 2006-12-29 10:36:48: DEBUG: caught rtm:2, need update interface address list 2006-12-29 10:36:48: DEBUG: msg 1 not interesting 2006-12-29 10:36:48: DEBUG: caught rtm:2, need update interface address list 2006-12-29 10:36:48: DEBUG: msg 1 not interesting ...skipping... 2006-12-29 10:45:18: DEBUG: msg 1 not interesting 2006-12-29 10:45:18: DEBUG: caught rtm:2, need update interface address list 2006-12-29 10:45:18: DEBUG: msg 1 not interesting 2006-12-29 10:45:18: DEBUG: caught rtm:2, need update interface address list 2006-12-29 10:45:18: DEBUG: msg 1 not interesting 2006-12-29 10:45:18: DEBUG: caught rtm:2, need update interface address list 2006-12-29 10:45:18: DEBUG: msg 1 not interesting 2006-12-29 10:45:18: DEBUG: caught rtm:2, need update interface address list 2006-12-29 10:45:18: DEBUG: msg 1 not interesting 2006-12-29 10:45:18: DEBUG: caught rtm:2, need update interface address list 2006-12-29 10:45:18: DEBUG: msg 1 not interesting 2006-12-29 10:45:18: DEBUG: caught rtm:2, need update interface address list 2006-12-29 10:45:18: DEBUG: msg 1 not interesting 2006-12-29 10:45:18: DEBUG: caught rtm:2, need update interface address list 2006-12-29 10:45:18: DEBUG: msg 1 not interesting 2006-12-29 10:45:18: DEBUG: caught rtm:2, need update interface address list 2006-12-29 10:45:18: DEBUG: msg 1 not interesting 2006-12-29 10:45:18: DEBUG: caught rtm:2, need update interface address list 2006-12-29 10:45:18: DEBUG: msg 1 not interesting 2006-12-29 10:45:18: DEBUG: caught rtm:2, need update interface address list 2006-12-29 10:45:18: DEBUG: msg 1 not interesting 2006-12-29 10:45:18: DEBUG: caught rtm:2, need update interface address list 2006-12-29 10:45:18: DEBUG: msg 1 not interesting 2006-12-29 10:45:18: DEBUG: caught rtm:2, need update interface address list 2006-12-29 10:45:18: DEBUG: msg 1 not interesting 2006-12-29 10:45:18: DEBUG: caught rtm:2, need update interface address list 2006-12-29 10:45:18: DEBUG: msg 1 not interesting 2006-12-29 10:45:18: DEBUG: caught rtm:2, need update interface address list 2006-12-29 10:45:18: DEBUG: msg 1 not interesting 2006-12-29 10:45:18: DEBUG: caught rtm:2, need update interface address list 2006-12-29 10:45:18: DEBUG: msg 1 not interesting 2006-12-29 10:45:18: DEBUG: caught rtm:2, need update interface address list 2006-12-29 10:45:18: DEBUG: msg 1 not interesting 2006-12-29 10:45:18: DEBUG: caught rtm:2, need update interface address list 2006-12-29 10:45:18: DEBUG: msg 1 not interesting 2006-12-29 10:45:18: DEBUG: caught rtm:2, need update interface address list 2006-12-29 10:45:18: DEBUG: msg 1 not interesting 2006-12-29 10:45:18: DEBUG: caught rtm:2, need update interface address list 2006-12-29 10:45:18: DEBUG: msg 1 not interesting 2006-12-29 10:45:18: DEBUG: caught rtm:2, need update interface address list 2006-12-29 10:45:18: DEBUG: msg 1 not interesting 2006-12-29 10:45:18: DEBUG: caught rtm:2, need update interface address list 2006-12-29 10:45:20: ERROR: failed to select (Invalid argument) ------- Thanks, Robert From owner-freebsd-net@FreeBSD.ORG Fri Dec 29 12:02:30 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D0AC416A407 for ; Fri, 29 Dec 2006 12:02:30 +0000 (UTC) (envelope-from gloomygroup@hotmail.com) Received: from bay0-omc3-s13.bay0.hotmail.com (bay0-omc3-s13.bay0.hotmail.com [65.54.246.213]) by mx1.freebsd.org (Postfix) with ESMTP id 8D1E213C455 for ; Fri, 29 Dec 2006 12:02:30 +0000 (UTC) (envelope-from gloomygroup@hotmail.com) Received: from hotmail.com ([65.55.136.97]) by bay0-omc3-s13.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Fri, 29 Dec 2006 01:12:26 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 29 Dec 2006 01:12:25 -0800 Message-ID: Received: from 65.55.136.123 by by131fd.bay131.hotmail.msn.com with HTTP; Fri, 29 Dec 2006 09:12:24 GMT X-Originating-IP: [202.79.53.71] X-Originating-Email: [gloomygroup@hotmail.com] X-Sender: gloomygroup@hotmail.com In-Reply-To: <458F4B96.1060400@ntmk.ru> From: "Gloomy Group" To: boris@ntmk.ru, freebsd-net@freebsd.org Date: Fri, 29 Dec 2006 09:12:24 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 29 Dec 2006 09:12:25.0983 (UTC) FILETIME=[74FE60F0:01C72B29] Cc: Subject: Re: FreeBSD PPPoE server and IP Conflict 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, 29 Dec 2006 12:02:30 -0000 Thanks boris, Actually that looks like bug in freebsd 5.x and 6.x. After changing that value in sysctl it helped. Regards Bishal >From: Boris Kovalenko >To: Gloomy Group , freebsd-net@freebsd.org >Subject: Re: FreeBSD PPPoE server and IP Conflict >Date: Mon, 25 Dec 2006 08:55:02 +0500 > >Hello! > > This is a know feature, You should use net.inet.ip.same_prefix_carp_only=1 >to avoid this. Unfortunatelly can't remember in what version of FreeBSD >this one was introduced and fixed. > >>Hi list, >> >> >> I have setup freebsd pppoe server in 6.0. My ppp.conf server is as >>follows. Problem I have been facing is server assigns the same ip address >>to the two different clients and the clients IP get conflicted. >> I have followed WARTA project papers to do the bandwidth shaping for >>pppoe server (http://www.hpi.net/whitepapers/warta/) >> >> Can anybody tell my why freebsd pppoe server assign >>to same ip address for different clients. >> Like when user "abc" connect he get 192.168.2.10 IP and when another >>user connect at the same time he also gets the same ip address i.e. >>192.168.2.10. Any suggestion for freebsd pppoe server with radius >>authentication. >> >>default: >>enable lqr >>set lqrperiod 5 >>enable echo >>enable lqr echo >>enable pap >>#allow users >>allow mode direct >>set mru 1480 >>set mtu 1480 >>set timeout 7200 >>set speed sync >>set ifaddr 202.xx.xx.xxx 202.xx.xx.1-202.xx.xx.254 >>set radius /etc/radius.conf >>accept dns >> >>_________________________________________________________________ >>Dave vs. Carl: The Insignificant Championship Series. Who will win? >>http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/direct/01/?href=http://davevscarl.spaces.live.com/?icid=T001MSN38C07001 >> >> >>_______________________________________________ >>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" >> >> > > >-- >With respect, > Boris >_______________________________________________ >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" _________________________________________________________________ Fixing up the home? Live Search can help http://imagine-windowslive.com/search/kits/default.aspx?kit=improve&locale=en-US&source=hmemailtaglinenov06&FORM=WLMTAG From owner-freebsd-net@FreeBSD.ORG Fri Dec 29 13:01:22 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 46E4216A403 for ; Fri, 29 Dec 2006 13:01:22 +0000 (UTC) (envelope-from tanniru.sankar@wipro.com) Received: from wip-ectls-mx1.wipro.com (wip-ectls-mx1.wipro.com [203.91.193.21]) by mx1.freebsd.org (Postfix) with ESMTP id A6A9F13C46B for ; Fri, 29 Dec 2006 13:01:21 +0000 (UTC) (envelope-from tanniru.sankar@wipro.com) Received: from wip-ectls-mx1.wipro.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 72D8922058B; Fri, 29 Dec 2006 12:10:48 +0530 (IST) Received: from blr-ec-bh01.wipro.com (blr-ec-bh01.wipro.com [10.201.50.91]) by wip-ectls-mx1.wipro.com (Postfix) with ESMTP id 66F2222017A; Fri, 29 Dec 2006 12:10:48 +0530 (IST) Received: from blr-m3-msg.wipro.com ([10.114.50.99]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Dec 2006 12:10:48 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 29 Dec 2006 12:13:08 +0530 Message-ID: <8B9F8433B684734581EB519F1A3E5AF43D88A5@blr-m3-msg.wipro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ' bus_dmamap_load_mbuf_sg ( ) ' function usage problem Thread-Index: Acci5g/dMWkrdRXJRd2tArne+O331AILkL8g From: To: X-OriginalArrivalTime: 29 Dec 2006 06:40:48.0437 (UTC) FILETIME=[466F0650:01C72B14] Cc: freebsd-net@freebsd.org Subject: RE: ' bus_dmamap_load_mbuf_sg ( ) ' function usage problem 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, 29 Dec 2006 13:01:22 -0000 =20 Hi Mark, Is it possible to allocate contigous memory of MJUM9BYTES ( 9K ) and dmamap_load in one segment ?=20 =20 Thanks, Sankar =20 =20 =20 -----Original Message----- From: John-Mark Gurney [mailto:gurney_j@resnet.uoregon.edu]=20 Sent: Tuesday, December 19, 2006 2:19 AM To: Tanniru Sankar (WT01 - Computing Systems & Storage) Cc: freebsd-net@freebsd.org Subject: Re: ' bus_dmamap_load_mbuf_sg ( ) ' function usage problem tanniru.sankar@wipro.com wrote this message on Mon, Dec 18, 2006 at 20:05 +0530: > I am facing a problem on FreeBSD 7.0 during mapping using ' > bus_dmamap_load_mbuf_sg ( ) ' function . > Details are below. > =20 > It is AMD 64 bit machine. I have allocated jumbo buffer memory=20 > using ' m_getcl ' function. > =20 > mp =3D m_getjcl(M_DONTWAIT, MT_DATA, M_PKTHDR, MJUM9BYTES); > =20 > As it got success here, I am trying to map the buffer as below. > =20 > err =3D bus_dmamap_load_mbuf_sg(dma_tag_rx, map, mp, &seg, &cnt,=20 > BUS_DMA_NOWAIT); > =20 > Here it is getting error for the mbuf size equal to MJUM9BYTES. > The type of error is ' EFBIG '. > =20 > I have create rx jumbo dma tag with attributes as following. [...] > MJUM9BYTES, /* Maximum Size */ >=20 > 1 , /* Number of Segments */ >=20 > MJUM9BYTES, /* Maximum Segment Size */ This is probably the problem... Most likely the buffer is non-contiguous in memory, and needs 3 segments to satisfy the mapping... Try increasing the number of segments and see what happens... --=20 John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." The information contained in this electronic message and any attachments to= this message are intended for the exclusive use of the addressee(s) and= may contain proprietary, confidential or privileged information. If you= are not the intended recipient, you should not disseminate, distribute or= copy this e-mail. Please notify the sender immediately and destroy all= copies of this message and any attachments.=20 WARNING: Computer viruses can be transmitted via email. The recipient= should check this email and any attachments for the presence of viruses.= The company accepts no liability for any damage caused by any virus= transmitted by this email. =20 www.wipro.com From owner-freebsd-net@FreeBSD.ORG Fri Dec 29 15:48:19 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0B2D416A407 for ; Fri, 29 Dec 2006 15:48:19 +0000 (UTC) (envelope-from kmitch@guru.org) Received: from weenix.guru.org (weenix.guru.org [24.199.153.98]) by mx1.freebsd.org (Postfix) with ESMTP id CF70713C457 for ; Fri, 29 Dec 2006 15:48:18 +0000 (UTC) (envelope-from kmitch@guru.org) Received: from localhost (localhost.guru.org [127.0.0.1]) by weenix.guru.org (Postfix) with ESMTP id 4DDAD59926 for ; Fri, 29 Dec 2006 10:48:18 -0500 (EST) Received: from weenix.guru.org ([127.0.0.1]) by localhost (weenix.guru.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27343-04 for ; Fri, 29 Dec 2006 10:48:18 -0500 (EST) Received: from [161.44.11.166] (ssh-rtp-1.cisco.com [161.44.11.166]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by weenix.guru.org (Postfix) with ESMTP id DF779598A8 for ; Fri, 29 Dec 2006 10:48:17 -0500 (EST) Message-ID: <459538C7.5020704@guru.org> Date: Fri, 29 Dec 2006 10:48:23 -0500 From: Keith Mitchell User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at guru.org Subject: IP_SENDSRCADDR & vlan interfaces 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, 29 Dec 2006 15:48:19 -0000 Hi, I've been trying to get the avahi port working on my system and haven't been able to get it to work. I've done some debugging of the application as well as discussed the problem with the maintainer of avahi. As a result of the debugging, it appears as though avahi works just fine when I just have the physical interfaces on the machine configured. But, when I use a VLAN trunk and the vlan virtual interfaces it does not work. Avahi tries to send out messages on the interfaces with the following code which seems reasonable: memset(&io, 0, sizeof(io)); io.iov_base = AVAHI_DNS_PACKET_DATA(p); io.iov_len = p->size; memset(&msg, 0, sizeof(msg)); msg.msg_name = &sa; msg.msg_namelen = sizeof(sa); msg.msg_iov = &io; msg.msg_iovlen = 1; msg.msg_flags = 0; msg.msg_control = NULL; msg.msg_controllen = 0; if (src_address) { struct in_addr *addr; memset(cmsg_data, 0, sizeof(cmsg_data)); msg.msg_control = cmsg_data; msg.msg_controllen = sizeof(cmsg_data); cmsg = CMSG_FIRSTHDR(&msg); cmsg->cmsg_len = CMSG_LEN(sizeof(struct in_addr)); cmsg->cmsg_level = IPPROTO_IP; cmsg->cmsg_type = IP_SENDSRCADDR; addr = (struct in_addr *)CMSG_DATA(cmsg); addr->s_addr = src_address->address; msg.msg_controllen = cmsg->cmsg_len; } return sendmsg_loop(fd, &msg, 0); The eventually call to sendmsg() does return success but nothing ever appears on the wire. I've tried sniffing both on the machine avahi is running on as well as another machine on the network and nothing ever goes out. Is there any known issue with using sendmsg/IP_SENDSRCADDR on the vlan virtual interfaces (as I mentioned above this works fine when using physical interfaces and not the vlan psuedo interfaces)? Thanks. -- Keith Mitchell Email: kmitch@guru.org PGP key available upon request From owner-freebsd-net@FreeBSD.ORG Fri Dec 29 18:59:59 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 49DDE16A4B3 for ; Fri, 29 Dec 2006 18:59:59 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outN.internet-mail-service.net (outN.internet-mail-service.net [216.240.47.237]) by mx1.freebsd.org (Postfix) with ESMTP id 1E10713C481 for ; Fri, 29 Dec 2006 18:59:58 +0000 (UTC) (envelope-from julian@elischer.org) Received: from shell.idiom.com (HELO idiom.com) (216.240.47.20) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Fri, 29 Dec 2006 10:42:50 -0800 Received: from [192.168.2.5] (home.elischer.org [216.240.48.38]) by idiom.com (8.12.11/8.12.11) with ESMTP id kBTIxsDs037747; Fri, 29 Dec 2006 10:59:54 -0800 (PST) (envelope-from julian@elischer.org) Message-ID: <459565A9.201@elischer.org> Date: Fri, 29 Dec 2006 10:59:53 -0800 From: Julian Elischer User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Yar Tikhiy References: <457DCD47.5090004@elischer.org> <200612120045.41425.max@love2party.net> <4583119B.20608@elischer.org> <200612160446.02644.max@love2party.net> <4584CE0C.3020307@elischer.org> <458C426A.9060604@elischer.org> <20061224093951.GD49045@comp.chem.msu.su> <459032EA.1030601@elischer.org> <20061226061610.GD81280@comp.chem.msu.su> <459177B0.2030006@elischer.org> <20061229090556.GD76083@comp.chem.msu.su> In-Reply-To: <20061229090556.GD76083@comp.chem.msu.su> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Max Laier , Andre Oppermann , freebsd-net@freebsd.org Subject: Re: [was] addition to ipfw (read vlans from bridge).. 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, 29 Dec 2006 18:59:59 -0000 Yar Tikhiy wrote: > On Tue, Dec 26, 2006 at 11:27:44AM -0800, Julian Elischer wrote: >> Yar Tikhiy wrote: >> >>>> If what you are suggesting is that we pass into ipfw an 'offset' >>>> into the packet as well as the packet, then yes I like that idea, >>>> but I didn't see Andre suggest it. >>> Do you consider only ideas by Andre? ;-) By Andre's opinion I >>> meant this: >>> >>> Please have the ipfw code examine the vlan tag in the mbuf instead of >>> fiddling with the mbuf contents. >> At the moment I plan the ipfw code to be unaware of vlan headers. >> the plan is: >> Add an argument to ipfw which is the offset in the packet where >> the IP header may be found. Change the L2 users of ipfw to >> leave the packet alone, but calculate the correct offset to pass to >> ipfw. IPFW will make no assumptions as to what packet contents come >> before the offset. Bridge and L2 callers of ipfw will >> set the offset to non-0 values where the IP callers will set it to >> 0. The non IP callers may make some MAC information available to the >> ipfw code my some separate method, as it does at the moment. How this >> is done will depend if we want to support Q-n-Q, and if so, how much.. > > Sounds very resonable to me. > >>> If we want ipfw to know of L2, then examining the VLAN tag in it >>> is OK. If not really, then ipfw (or any pfil filter) can get just >>> the offset of IP. >> What vlan tag? what if it's from an interface with no VLAN capacity.. >> What we need to do is make a convention so that vlan tags are always >> created at the lowest layer, even if HW vlan tagging is not supported, >> so that all packets look as if they have come from HW capable packets, >> and add code so that all non WH capable interfaces interpret Van tags at >> the lowest level, that way vlan packets always look the same. > > It depends. As of now, a network interface driver passes up, e.g., > to ether_input(), just what it has got. I.e., a driver in VLAN_HWTAG > mode reads the tag from a hardware register and stores it in > m_pkthdr.ether_vtag while a driver unaware of VLANs just passes up > an 802.1q tagged frame it received. Perhaps it's ether_input() that > should fix the things up for us so that we don't have to modify every > VLAN-ignorant driver. > > However, converting the in-band tag to the out-of-band tag will > take 1 m_pullup() call and 1 bcopy() call and 1 m_adj() call per > tagged frame received: but that gets done anyhow later when we convert it.. > > if ((m->m_flags & M_VLANTAG) == 0) { > m_pullup(m, sizeof(struct ether_vlan_header)); > evh = mtod(m, struct ether_vlan_header *); if (evh->evl_ncap_proto == ETHERTYPE_VLAN) { > m->m_pkthdr.ether_vtag = ntohs(evh->evl_tag); > m->m_flags |= M_VLANTAG; > bcopy((char *)evh, (char *)evh + ETHER_VLAN_ENCAP_LEN, > ETHER_HDR_LEN - ETHER_TYPE_LEN); > m_adj(m, ETHER_VLAN_ENCAP_LEN); } > } > > Now I cannot tell if there will be a noticable impact on performance > relative to the approach when we just do things conditionally > depending on M_VLANTAG being set or unset, e.g.: > > if (m->m_flags & M_VLANTAG) { > tag = m->m_pkthdr.ether_vtag; > } else { > m_pullup(m, sizeof(struct ether_vlan_header)); > evh = mtod(m, struct ether_vlan_header *); > tag = ntohs(evh->evl_tag); > } > /* now do things based on tag, e.g., filtering... */ > >>> Infinity. Why to introduce such a hard limit? >> >> Because an infinite limit complicates things? > > Not necessarily. It depends on what we are trying to do with the > tags. E.g., if we want to find the IP header offset, computing it > by skipping over an unlimited number of VLAN headers won't be more > complex than skipping over just 1-2 of them as we need a loop > already. 2 is not a loop if they are different.. note that the standard talks about 2 different ethertypes. Also how do we currently cope with multiple vlan tags considering that Andre has just incorporated a single vlan tag into the mbuf? (and what happens if we use old mtags and have multiple vlan tags? it is not defined what happens when there are multiple mtags with the same type. How do you get the 2nd one?) From owner-freebsd-net@FreeBSD.ORG Sat Dec 30 13:44:25 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 99F2416A403; Sat, 30 Dec 2006 13:44:25 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2-3.pacific.net.au [61.8.2.226]) by mx1.freebsd.org (Postfix) with ESMTP id 3D23A13C468; Sat, 30 Dec 2006 13:44:25 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout2.pacific.net.au (Postfix) with ESMTP id 8E6DC119293; Sun, 31 Dec 2006 00:41:03 +1100 (EST) Received: from epsplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (Postfix) with ESMTP id 814318C05; Sun, 31 Dec 2006 00:41:03 +1100 (EST) Date: Sun, 31 Dec 2006 00:41:02 +1100 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: Doug Barton In-Reply-To: <20061213135817.P1190@delplex.bde.org> Message-ID: <20061230233343.U745@epsplex.bde.org> References: <457F0C35.3020409@FreeBSD.org> <20061213135817.P1190@delplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: net@freebsd.org Subject: Re: [Fwd: Re: bge Ierr rate increase from 5.3R -> 6.1R] 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, 30 Dec 2006 13:44:25 -0000 [cc changed from developers to net] On Wed, 13 Dec 2006, Bruce Evans wrote: > On Tue, 12 Dec 2006, Doug Barton wrote: > >> This guy's first message about this problem was very detailed, and he >> seems highly motivated. Anyone want to help him out? > > This might be because bge now actually reports error statistics correctly > (so the larger counts are correct, or because the fixes in -current > aren't all in RELENG_6 (so the larger and smaller counts may both be > incorrect). I now think that this is a bug in mii (brgphy_service()) introduced or enlarged since FreeBSD-5.early. Under loads that can be handled, my 5701 often gets a small number of input errors every second, and returning immediately from brgphy_service() fixes these. bge uses the same logic as most NIC drivers for mii_tick(), and this is bad for interrupt latency, but the problem here seems to be mangling of packets and unrelated to interrupt latency (high loads just usually give a packet in flight for brgphy_service() to mangle?). > I can easily generate hundreds of thousands of input errors per second > by flooding my '5701 and '5705 bge devices with hundreds of thousands > more packets per second than they can handle. The error counts are 0 > in ~5.2 but are are correct in -current (dropped packets are counted > as input errors). The '5705 was most broken and hasn't been fixed in > RELENG_6. These happen under loads that can't be handled, and generally cause thousands of input errors every second. The hardware records dropped packets separately from other input errors, but unfortunately all types of input errors are counted together in if_ierrors, and I haven't done more than muck around in ddb to separate them. I have coalescence tuning sysctls that among other things allow tuning to the threshold where packets are dropped, keping the load large and constant. Playing with these showed that bge is not using its full rx ring to reduce its latency requirements. bge shouldn't drop packets on input unless it gets more than BGE_STD_RX_RING_COUNT = 512 rx descriptors behind, but instead it drops packets when it gets the following numbers behind: - 20 under combined rx+tx load. I can't explain this. Apparently some other hardware resource is running out. - 192 under rx-only load. 256 rx slots are lost by not allocating mbufs for them, since allocating mbufs would cost 1MB of memory and 1MB was considered large. See bge_init_rx_ring_std() and the bogus SSLOTS macro. There used to be similar bogusness for jumbo buffers and JSLOTS, but now JSLOTS is unused garbage -- mbufs are now allocated for the full jumbo ring without worrying that this takes much more than 1MB. I can't explain the remaining missing 64, but suspect BGE_CMD_RING_COUNT. With the limit of 192, polling at 1000 Hz breaks at an input rate of 192 kpps. Allocating 256 more std rx ring slots increases this limit to 448 kpps, which is close to the maximum that I can test. The extra 256 shouldn't be necessary, but are useful for avoiding various latency bugs. bge also has a "mini" rx ring which FreeBSD doesn't use. I don't really understand this or the interaction of the separate rx rings, but hope that the mini ring can be used to handle small packets and would only need an mbuf (not an mbuf cluster) for each packet, and with it and the jumbo ring the total hardware buffering would be 1024(mini) + 512(std) + 256(jumbo), with the 1024-entry event ring only used to communicate with the host and its size not really limiting buffering. Meeting a latency requirement of 1024+512 tiny-packet times is much easier than meeting one of 192 or 20 tiny-packet times. (I only actually saw the limits of 20 and 192 for full-sized (non jumbo) packets.) Fix for most of the 192 limit and nearby bogusness: %%% Index: if_bge.c =================================================================== RCS file: /home/ncvs/src/sys/dev/bge/if_bge.c,v retrieving revision 1.172 diff -u -2 -r1.172 if_bge.c --- if_bge.c 26 Dec 2006 18:33:55 -0000 1.172 +++ if_bge.c 28 Dec 2006 18:15:44 -0000 @@ -811,10 +814,4 @@ } -/* - * The standard receive ring has 512 entries in it. At 2K per mbuf cluster, - * that's 1MB or memory, which is a lot. For now, we fill only the first - * 256 ring entries and hope that our CPU is fast enough to keep up with - * the NIC. - */ static int bge_init_rx_ring_std(struct bge_softc *sc) @@ -822,8 +819,8 @@ int i; - for (i = 0; i < BGE_SSLOTS; i++) { + for (i = 0; i < BGE_STD_RX_RING_CNT; i++) { if (bge_newbuf_std(sc, i, NULL) == ENOBUFS) return (ENOBUFS); - }; + } bus_dmamap_sync(sc->bge_cdata.bge_rx_std_ring_tag, @@ -866,5 +863,5 @@ if (bge_newbuf_jumbo(sc, i, NULL) == ENOBUFS) return (ENOBUFS); - }; + } bus_dmamap_sync(sc->bge_cdata.bge_rx_jumbo_ring_tag, Index: if_bgereg.h =================================================================== RCS file: /home/ncvs/src/sys/dev/bge/if_bgereg.h,v retrieving revision 1.65 diff -u -2 -r1.65 if_bgereg.h --- if_bgereg.h 22 Dec 2006 02:59:58 -0000 1.65 +++ if_bgereg.h 30 Dec 2006 13:35:32 -0000 @@ -2327,13 +2329,7 @@ /* - * Memory management stuff. Note: the SSLOTS, MSLOTS and JSLOTS - * values are tuneable. They control the actual amount of buffers - * allocated for the standard, mini and jumbo receive rings. + * Memory management stuff. */ -#define BGE_SSLOTS 256 -#define BGE_MSLOTS 256 -#define BGE_JSLOTS 384 - #define BGE_JRAWLEN (BGE_JUMBO_FRAMELEN + ETHER_ALIGN) #define BGE_JLEN (BGE_JRAWLEN + (sizeof(uint64_t) - \ %%% Bruce From owner-freebsd-net@FreeBSD.ORG Sat Dec 30 15:53:18 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1D0AB16A40F for ; Sat, 30 Dec 2006 15:53:18 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (reverse-25.fdn.fr [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id A647913C45E for ; Sat, 30 Dec 2006 15:53:17 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from jayce.zen.inc (jayce.zen.inc [192.168.1.7]) by smtp.zeninc.net (smtpd) with ESMTP id 3A1203F17 for ; Sat, 30 Dec 2006 16:28:59 +0100 (CET) Received: by jayce.zen.inc (Postfix, from userid 1000) id 21F992E2BE; Sat, 30 Dec 2006 16:29:00 +0100 (CET) Date: Sat, 30 Dec 2006 16:28:59 +0100 From: VANHULLEBUS Yvan To: freebsd-net@freebsd.org Message-ID: <20061230152859.GA1519@jayce.zen.inc> References: <3713853f0612280851m243f9e75u918c0969b038a865@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3713853f0612280851m243f9e75u918c0969b038a865@mail.gmail.com> User-Agent: All mail clients suck. This one just sucks less. Subject: Re: ipsec-tools 0.6.6 problem 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, 30 Dec 2006 15:53:18 -0000 On Thu, Dec 28, 2006 at 05:51:42PM +0100, Robert Usle wrote: > Hello list & Yvan. Hi. [...] > listen > { > #isakmp ::1 [7000]; > isakmp 89.217.11.250 [500]; > isakmp 10.0.5.1 [500]; > #admin [7002]; # administrative port for racoonctl. > #strict_address; # requires that all addresses must be bound. > } Those addresses don't match the ifconfig output you sent in your previous mail, is that normal ? [....] > remote anonymous { > exchange_mode aggressive,main,base; This is a quite ugly config (I fear it comes from ipsec-tools examples....), but it is not related to your problem. [....] > 2006-12-28 17:30:49: INFO: 10.0.5.1[500] used as isakmp port (fd=5) > 2006-12-28 17:30:49: INFO: 89.217.11.250[500] used as isakmp port (fd=6) > 2006-12-28 17:30:49: DEBUG: get pfkey X_SPDDUMP message > 2006-12-28 17:30:49: DEBUG: get pfkey X_SPDDUMP message > 2006-12-28 17:30:49: DEBUG: sub:0xbfbff524: 0.0.0.0/0[0] > 192.168.2.0/24[0] proto=any dir=out > 2006-12-28 17:30:49: DEBUG: db :0x80a5408: 192.168.2.0/24[0] > 0.0.0.0/0[0] proto=any dir=in Could you also give us the output of "setkey -D -P" ? > 2006-12-28 17:30:49: DEBUG: msg 1 not interesting > 2006-12-28 17:30:49: DEBUG: caught rtm:2, need update interface address list > 2006-12-28 17:30:49: DEBUG: msg 1 not interesting > 2006-12-28 17:30:49: DEBUG: caught rtm:2, need update interface address list > 2006-12-28 17:30:49: DEBUG: msg 1 not interesting > 2006-12-28 17:30:49: DEBUG: caught rtm:2, need update interface address list > 2006-12-28 17:30:50: DEBUG: msg 5 not interesting > 2006-12-28 17:30:50: DEBUG: msg 1 not interesting > 2006-12-28 17:30:50: DEBUG: caught rtm:2, need update interface address list > 2006-12-28 17:30:50: DEBUG: msg 1 not interesting > and so on..... infinite loop with 'caught rtm;2, need update interface > address list Strange. The most common reason for an interface update is entering/leaving promiscous mode, or changing IP configuration, but I guess you don't do that many times per second.... Just to ba sure: do you have strange messages on console related to IP configuration ? [...] > There are 2 setkey commands now, (/usr/sbin/ & /usr/local/sbin) > can I use both ? For very basic usage, yes, but as you are using ipsec-tool's racoon, it is better to also use ipsec-tool's setkey, which is the /usr/local/sbin one. > Also, sometimes I'm getting 'unsupported PF_KEY message REGISTER' > after running setkey ? Are you sure your kernel has been correctly compiled/installed ??? Yvan. -- NETASQ http://www.netasq.com From owner-freebsd-net@FreeBSD.ORG Sat Dec 30 17:31:11 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0320E16A407; Sat, 30 Dec 2006 17:31:11 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.freebsd.org (Postfix) with ESMTP id 9F74313C461; Sat, 30 Dec 2006 17:31:09 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.3) with ESMTP id kBUHUsh3094732; Sat, 30 Dec 2006 20:30:54 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.3/Submit) id kBUHUr10094731; Sat, 30 Dec 2006 20:30:53 +0300 (MSK) (envelope-from yar) Date: Sat, 30 Dec 2006 20:30:53 +0300 From: Yar Tikhiy To: Julian Elischer Message-ID: <20061230173053.GB94532@comp.chem.msu.su> References: <457DCD47.5090004@elischer.org> <200612120045.41425.max@love2party.net> <4583119B.20608@elischer.org> <200612160446.02644.max@love2party.net> <4584CE0C.3020307@elischer.org> <458C426A.9060604@elischer.org> <20061224093951.GD49045@comp.chem.msu.su> <459032EA.1030601@elischer.org> <20061226061610.GD81280@comp.chem.msu.su> <4591A2D3.50708@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4591A2D3.50708@elischer.org> User-Agent: Mutt/1.5.9i Cc: Max Laier , Andre Oppermann , freebsd-net@freebsd.org Subject: Re: [was] addition to ipfw (read vlans from bridge).. 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, 30 Dec 2006 17:31:11 -0000 On Tue, Dec 26, 2006 at 02:31:47PM -0800, Julian Elischer wrote: > Ok, so, here is a patch for general review by ipfw types. > This is the first of two related changes. > > It is MOSTLY a cleanup of ip_fw2.c, removing a bunch of mtod() > operations and replacing them with a cached value of the address of the > IP header. > > It also has a couple of (commented out) references to > args->L3offset which is the next commit. This explains > WHY we are mainignsome of the cleanups. > Basically, this commit removes the assumption that > mtod(m, struct ip *) returns the address of the IP header, > as there may be other stuff before it in the packet. > e.g. vlan headers and ethernet headers. > > The next commit would actually implement that by modifying > the callers to no longer strip such heaers off but instead, > to set the offset correctly. (and uncomment those bits in > this diff) > > The AIM of this code is to make it easier to do layer 2 based > IP filtering when there may be a variety of L2 headers on the > front of the packet. The idea is to make the changes in a way > that ipfw (a layer 3 animal) does not need to know any of the > details of the layer 2 encapsulation, of to know how to interpret > L2 headers on the ffront of the packet. it needs to only know > how much to skip over. > > > Comments welcome. > Frankly, I am not too familiar with the details of the ip_fw2 implementation, but in general the change looks all right to me, especially if you omit style changes from it. However, I have one question regarding "etype", please see below. > Index: netinet/ip_fw2.c > =================================================================== > RCS file: /usr/local/cvsroot/freebsd/src/sys/netinet/ip_fw2.c,v > retrieving revision 1.155 > diff -u -r1.155 ip_fw2.c > --- netinet/ip_fw2.c 12 Dec 2006 12:17:56 -0000 1.155 > +++ netinet/ip_fw2.c 26 Dec 2006 22:14:16 -0000 > @@ -667,10 +667,12 @@ > } > > static void > -send_reject6(struct ip_fw_args *args, int code, u_int hlen) > +send_reject6(struct ip_fw_args *args, int code, u_int hlen, struct ip6_hdr *ip6) > { > + struct mbuf *m; > + > + m = args->m; > if (code == ICMP6_UNREACH_RST && args->f_id.proto == IPPROTO_TCP) { > - struct ip6_hdr *ip6; > struct tcphdr *tcp; > tcp_seq ack, seq; > int flags; > @@ -678,18 +680,11 @@ > struct ip6_hdr ip6; > struct tcphdr th; > } ti; > - > - if (args->m->m_len < (hlen+sizeof(struct tcphdr))) { > - args->m = m_pullup(args->m, hlen+sizeof(struct tcphdr)); > - if (args->m == NULL) > - return; > - } > - > - ip6 = mtod(args->m, struct ip6_hdr *); > - tcp = (struct tcphdr *)(mtod(args->m, char *) + hlen); > + tcp = (struct tcphdr *)((char *)ip6 + hlen); > > if ((tcp->th_flags & TH_RST) != 0) { > - m_freem(args->m); > + m_freem(m); > + args->m = NULL; > return; > } > > @@ -705,14 +700,20 @@ > flags = TH_RST; > } else { > ack = ti.th.th_seq; > - if (((args->m)->m_flags & M_PKTHDR) != 0) { > - ack += (args->m)->m_pkthdr.len - hlen > + if ((m->m_flags & M_PKTHDR) != 0) { > + /* > + * total new data to ACK is: > + * total packet length, > + * minus the header length, > + * minus the tcp header length. > + */ > + ack += m->m_pkthdr.len - hlen > - (ti.th.th_off << 2); > } else if (ip6->ip6_plen) { > - ack += ntohs(ip6->ip6_plen) + sizeof(*ip6) > - - hlen - (ti.th.th_off << 2); > + ack += ntohs(ip6->ip6_plen) + sizeof(*ip6) - > + hlen - (ti.th.th_off << 2); > } else { > - m_freem(args->m); > + m_freem(m); > return; > } > if (tcp->th_flags & TH_SYN) > @@ -721,14 +722,28 @@ > flags = TH_RST|TH_ACK; > } > bcopy(&ti, ip6, sizeof(ti)); > - tcp_respond(NULL, ip6, (struct tcphdr *)(ip6 + 1), > - args->m, ack, seq, flags); > - > + /* > + * m is only used to recycle the mbuf > + * The data in it is never read so we don't need > + * to correct the offsets or anything > + */ > + tcp_respond(NULL, ip6, tcp, m, ack, seq, flags); > } else if (code != ICMP6_UNREACH_RST) { /* Send an ICMPv6 unreach. */ > - icmp6_error(args->m, ICMP6_DST_UNREACH, code, 0); > - > +#if 0 > + /* > + * Unlike above, the mbufs need to line up with the ip6 hdr, > + * as the contents are read. We need to m_adj() the > + * needed amount. > + * The mbuf will however be thrown away so we can adjust it. > + * Remember we did an m_pullup on it already so we > + * can make some assumptions about contiguousness. > + */ > + if (args->L3offset) > + m_adj(m, args->L3offset); > +#endif > + icmp6_error(m, ICMP6_DST_UNREACH, code, 0); > } else > - m_freem(args->m); > + m_freem(m); > > args->m = NULL; > } > @@ -746,7 +761,8 @@ > */ > static void > ipfw_log(struct ip_fw *f, u_int hlen, struct ip_fw_args *args, > - struct mbuf *m, struct ifnet *oif, u_short offset, uint32_t tablearg) > + struct mbuf *m, struct ifnet *oif, u_short offset, uint32_t tablearg, > + struct ip *ip) > { > struct ether_header *eh = args->eh; > char *action; > @@ -892,13 +908,12 @@ > snprintf(dst, sizeof(dst), "[%s]", > ip6_sprintf(ip6buf, &args->f_id.dst_ip6)); > > - ip6 = (struct ip6_hdr *)mtod(m, struct ip6_hdr *); > - tcp = (struct tcphdr *)(mtod(args->m, char *) + hlen); > - udp = (struct udphdr *)(mtod(args->m, char *) + hlen); > + ip6 = (struct ip6_hdr *)ip; > + tcp = (struct tcphdr *)(((char *)ip) + hlen); > + udp = (struct udphdr *)(((char *)ip) + hlen); > } else > #endif > { > - ip = mtod(m, struct ip *); > tcp = L3HDR(struct tcphdr, ip); > udp = L3HDR(struct udphdr, ip); > > @@ -942,7 +957,7 @@ > break; > #ifdef INET6 > case IPPROTO_ICMPV6: > - icmp6 = (struct icmp6_hdr *)(mtod(args->m, char *) + hlen); > + icmp6 = (struct icmp6_hdr *)(((char *)ip) + hlen); > if (offset == 0) > len = snprintf(SNPARGS(proto, 0), > "ICMPv6:%u.%u ", > @@ -1673,13 +1688,22 @@ > * sends a reject message, consuming the mbuf passed as an argument. > */ > static void > -send_reject(struct ip_fw_args *args, int code, int ip_len) > +send_reject(struct ip_fw_args *args, int code, int ip_len, struct ip *ip) > { > > +#if 0 > + /* XXX When ip is not guaranteed to be at mtod() we will > + * need to account for this */ > + * The mbuf will however be thrown away so we can adjust it. > + * Remember we did an m_pullup on it already so we > + * can make some assumptions about contiguousness. > + */ > + if (args->L3offset) > + m_adj(m, args->L3offset); > +#endif > if (code != ICMP_REJECT_RST) { /* Send an ICMP unreach */ > /* We need the IP header in host order for icmp_error(). */ > if (args->eh != NULL) { > - struct ip *ip = mtod(args->m, struct ip *); > ip->ip_len = ntohs(ip->ip_len); > ip->ip_off = ntohs(ip->ip_off); > } > @@ -2039,6 +2063,8 @@ > * args->m (in/out) The packet; we set to NULL when/if we nuke it. > * Starts with the IP header. > * args->eh (in) Mac header if present, or NULL for layer3 packet. > + * args->L3offset Number of bytes bypassed if we came from L2. > + * e.g. often sizeof(eh) ** NOTYET ** > * args->oif Outgoing interface, or NULL if packet is incoming. > * The incoming interface is in the mbuf. (in) > * args->divert_rule (in/out) > @@ -2060,12 +2086,11 @@ > * IP_FW_NETGRAPH into netgraph, cookie args->cookie > * > */ > - > int > ipfw_chk(struct ip_fw_args *args) > { > /* > - * Local variables hold state during the processing of a packet. > + * Local variables holding state during the processing of a packet: > * > * IMPORTANT NOTE: to speed up the processing of rules, there > * are some assumption on the values of the variables, which > @@ -2075,15 +2100,18 @@ > * > * args->eh The MAC header. It is non-null for a layer2 > * packet, it is NULL for a layer-3 packet. > + * **notyet** > + * args->L3offset Offset in the packet to the L3 (IP or equiv.) header. > * > * m | args->m Pointer to the mbuf, as received from the caller. > * It may change if ipfw_chk() does an m_pullup, or if it > * consumes the packet because it calls send_reject(). > * XXX This has to change, so that ipfw_chk() never modifies > * or consumes the buffer. > - * ip is simply an alias of the value of m, and it is kept > - * in sync with it (the packet is supposed to start with > - * the ip header). > + * ip is the beginning of the ip(4 or 6) header. > + * Calculated by adding the L3offset to the start of data. > + * (Until we start using L3offset, the packet is > + * supposed to start with the ip header). > */ > struct mbuf *m = args->m; > struct ip *ip = mtod(m, struct ip *); > @@ -2154,6 +2182,7 @@ > struct in_addr src_ip, dst_ip; /* NOTE: network format */ > u_int16_t ip_len=0; > int pktlen; > + u_int16_t etype = 0; /* Host order stored ether type */ Here we suppose that etype will contain an ethertype value, don't we? > /* > * dyn_dir = MATCH_UNKNOWN when rules unchecked, > @@ -2202,14 +2231,20 @@ > p = (mtod(m, char *) + (len)); \ > } while (0) > > + /* > + * if we have an ether header, > + */ > + if (args->eh) > + etype = (ntohs(args->eh->ether_type)) == ETHERTYPE_VLAN; And here we assign a boolean value to etype. Is it intended? Looks like a error to me. Apparently it should read: etype = ntohs(args->eh->ether_type); But some processing of the (etype == ETHERTYPE_VLAN) case may be missing here. > + > /* Identify IP packets and fill up variables. */ > if (pktlen >= sizeof(struct ip6_hdr) && > - (args->eh == NULL || ntohs(args->eh->ether_type)==ETHERTYPE_IPV6) && > - mtod(m, struct ip *)->ip_v == 6) { > + (args->eh == NULL || etype == ETHERTYPE_IPV6) && ip->ip_v == 6) { > + struct ip6_hdr *ip6 = (struct ip6_hdr *)ip; > is_ipv6 = 1; > args->f_id.addr_type = 6; > hlen = sizeof(struct ip6_hdr); > - proto = mtod(m, struct ip6_hdr *)->ip6_nxt; > + proto = ip6->ip6_nxt; > > /* Search extension headers to find upper layer protocols */ > while (ulp == NULL) { > @@ -2354,16 +2389,16 @@ > break; > } /*switch */ > } > - args->f_id.src_ip6 = mtod(m,struct ip6_hdr *)->ip6_src; > - args->f_id.dst_ip6 = mtod(m,struct ip6_hdr *)->ip6_dst; > + ip = mtod(m, struct ip *); > + ip6 = (struct ip6_hdr *)ip; > + args->f_id.src_ip6 = ip6->ip6_src; > + args->f_id.dst_ip6 = ip6->ip6_dst; > args->f_id.src_ip = 0; > args->f_id.dst_ip = 0; > - args->f_id.flow_id6 = ntohl(mtod(m, struct ip6_hdr *)->ip6_flow); > + args->f_id.flow_id6 = ntohl(ip6->ip6_flow); > } else if (pktlen >= sizeof(struct ip) && > - (args->eh == NULL || ntohs(args->eh->ether_type) == ETHERTYPE_IP) && > - mtod(m, struct ip *)->ip_v == 4) { > + (args->eh == NULL || etype == ETHERTYPE_IP) && ip->ip_v == 4) { > is_ipv4 = 1; > - ip = mtod(m, struct ip *); > hlen = ip->ip_hl << 2; > args->f_id.addr_type = 4; > > @@ -2407,6 +2442,7 @@ > } > } > > + ip = mtod(m, struct ip *); > args->f_id.src_ip = ntohl(src_ip.s_addr); > args->f_id.dst_ip = ntohl(dst_ip.s_addr); > } > @@ -2573,15 +2609,14 @@ > > case O_MAC_TYPE: > if (args->eh != NULL) { > - u_int16_t t = > - ntohs(args->eh->ether_type); > u_int16_t *p = > ((ipfw_insn_u16 *)cmd)->ports; > int i; > > for (i = cmdlen - 1; !match && i>0; > i--, p += 2) > - match = (t>=p[0] && t<=p[1]); > + match = (etype >= p[0] && > + etype <= p[1]); > } > break; > > @@ -2733,12 +2768,12 @@ > > case O_IPOPT: > match = (is_ipv4 && > - ipopts_match(mtod(m, struct ip *), cmd) ); > + ipopts_match(ip, cmd) ); > break; > > case O_IPVER: > match = (is_ipv4 && > - cmd->arg1 == mtod(m, struct ip *)->ip_v); > + cmd->arg1 == ip->ip_v); > break; > > case O_IPID: > @@ -2752,9 +2787,9 @@ > if (cmd->opcode == O_IPLEN) > x = ip_len; > else if (cmd->opcode == O_IPTTL) > - x = mtod(m, struct ip *)->ip_ttl; > + x = ip->ip_ttl; > else /* must be IPID */ > - x = ntohs(mtod(m, struct ip *)->ip_id); > + x = ntohs(ip->ip_id); > if (cmdlen == 1) { > match = (cmd->arg1 == x); > break; > @@ -2769,12 +2804,12 @@ > > case O_IPPRECEDENCE: > match = (is_ipv4 && > - (cmd->arg1 == (mtod(m, struct ip *)->ip_tos & 0xe0)) ); > + (cmd->arg1 == (ip->ip_tos & 0xe0)) ); > break; > > case O_IPTOS: > match = (is_ipv4 && > - flags_match(cmd, mtod(m, struct ip *)->ip_tos)); > + flags_match(cmd, ip->ip_tos)); > break; > > case O_TCPDATALEN: > @@ -2866,7 +2901,7 @@ > case O_LOG: > if (fw_verbose) > ipfw_log(f, hlen, args, m, > - oif, offset, tablearg); > + oif, offset, tablearg, ip); > match = 1; > break; > > @@ -3204,7 +3239,7 @@ > is_icmp_query(ICMP(ulp))) && > !(m->m_flags & (M_BCAST|M_MCAST)) && > !IN_MULTICAST(ntohl(dst_ip.s_addr))) { > - send_reject(args, cmd->arg1, ip_len); > + send_reject(args, cmd->arg1, ip_len, ip); > m = args->m; > } > /* FALLTHROUGH */ > @@ -3216,7 +3251,9 @@ > (is_icmp6_query(args->f_id.flags) == 1)) && > !(m->m_flags & (M_BCAST|M_MCAST)) && > !IN6_IS_ADDR_MULTICAST(&args->f_id.dst_ip6)) { > - send_reject6(args, cmd->arg1, hlen); > + send_reject6( > + args, cmd->arg1, hlen, > + (struct ip6_hdr *)ip); > m = args->m; > } > /* FALLTHROUGH */ -- Yar From owner-freebsd-net@FreeBSD.ORG Sat Dec 30 17:52:22 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 36E5916A403 for ; Sat, 30 Dec 2006 17:52:22 +0000 (UTC) (envelope-from robertusn@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.232]) by mx1.freebsd.org (Postfix) with ESMTP id EEE0513C45D for ; Sat, 30 Dec 2006 17:52:21 +0000 (UTC) (envelope-from robertusn@gmail.com) Received: by nz-out-0506.google.com with SMTP id i11so2282604nzh for ; Sat, 30 Dec 2006 09:52:21 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=rDwpEKiR6bue7dRN3rRkXyAyR4bgY2JSS7aBXWtzB3uz4wqXmhtHhXKTyMjUeobfIqmJCer3Tb/xVX4ibjn0le9ypEeHw91D7laN1j79qeruj/41Tnc5sjQ6sOc82nKNTBTyb+qoVfgx3yMGZCCIWv4c7EOIR4NTY/F0CQjSOgE= Received: by 10.65.204.7 with SMTP id g7mr11934842qbq.1167501141356; Sat, 30 Dec 2006 09:52:21 -0800 (PST) Received: by 10.65.59.8 with HTTP; Sat, 30 Dec 2006 09:52:21 -0800 (PST) Message-ID: <3713853f0612300952i7180b1daw1dbd7af01bc75c72@mail.gmail.com> Date: Sat, 30 Dec 2006 18:52:21 +0100 From: "Robert Usle" Sender: robertusn@gmail.com To: "VANHULLEBUS Yvan" In-Reply-To: <20061230152859.GA1519@jayce.zen.inc> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3713853f0612280851m243f9e75u918c0969b038a865@mail.gmail.com> <20061230152859.GA1519@jayce.zen.inc> X-Google-Sender-Auth: 6832a37dc421c8d9 Cc: freebsd-net@freebsd.org Subject: Re: ipsec-tools 0.6.6 problem 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, 30 Dec 2006 17:52:22 -0000 On 12/30/06, VANHULLEBUS Yvan wrote: > On Thu, Dec 28, 2006 at 05:51:42PM +0100, Robert Usle wrote: > > Hello list & Yvan. > > Hi. > > > > [...] > > listen > > { > > #isakmp ::1 [7000]; > > isakmp 89.217.11.250 [500]; > > isakmp 10.0.5.1 [500]; > > #admin [7002]; # administrative port for racoonctl. > > #strict_address; # requires that all addresses must be bound. > > } > > Those addresses don't match the ifconfig output you sent in your > previous mail, is that normal ? Yes, sorry. I was trying to mask a real IP.. that's not the one I have attached to my interface. For security reasons. > [....] > > remote anonymous { > > exchange_mode aggressive,main,base; > > This is a quite ugly config (I fear it comes from ipsec-tools > examples....), but it is not related to your problem. Tried many others. > [....] > > 2006-12-28 17:30:49: INFO: 10.0.5.1[500] used as isakmp port (fd=5) > > 2006-12-28 17:30:49: INFO: 89.217.11.250[500] used as isakmp port (fd=6) > > 2006-12-28 17:30:49: DEBUG: get pfkey X_SPDDUMP message > > 2006-12-28 17:30:49: DEBUG: get pfkey X_SPDDUMP message > > 2006-12-28 17:30:49: DEBUG: sub:0xbfbff524: 0.0.0.0/0[0] > > 192.168.2.0/24[0] proto=any dir=out > > 2006-12-28 17:30:49: DEBUG: db :0x80a5408: 192.168.2.0/24[0] > > 0.0.0.0/0[0] proto=any dir=in > > Could you also give us the output of "setkey -D -P" Sure. 192.168.2.0/24[any] 0.0.0.0/0[any] any in ipsec esp/tunnel/10.0.5.40-10.0.5.1/require spid=53 seq=1 pid=7738 refcnt=1 0.0.0.0/0[any] 192.168.2.0/24[any] any out ipsec esp/tunnel/10.0.5.1-10.0.5.40/require spid=54 seq=0 pid=7738 refcnt=1 > > 2006-12-28 17:30:49: DEBUG: msg 1 not interesting > > 2006-12-28 17:30:49: DEBUG: caught rtm:2, need update interface address list > > 2006-12-28 17:30:49: DEBUG: msg 1 not interesting > > 2006-12-28 17:30:49: DEBUG: caught rtm:2, need update interface address list > > 2006-12-28 17:30:49: DEBUG: msg 1 not interesting > > 2006-12-28 17:30:49: DEBUG: caught rtm:2, need update interface address list > > 2006-12-28 17:30:50: DEBUG: msg 5 not interesting > > 2006-12-28 17:30:50: DEBUG: msg 1 not interesting > > 2006-12-28 17:30:50: DEBUG: caught rtm:2, need update interface address list > > 2006-12-28 17:30:50: DEBUG: msg 1 not interesting > > and so on..... infinite loop with 'caught rtm;2, need update interface > > address list > > Strange. The most common reason for an interface update is > entering/leaving promiscous mode, or changing IP configuration, but I > guess you don't do that many times per second.... I am not aware of any changes made. I am running snort, but even if I shutdown it, racoon still makes the loop. here's my ifconfig output: fxp0: flags=8843 mtu 1500 options=40 inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255 ether 00:03:47:c6:af:e6 media: Ethernet autoselect (100baseTX ) status: active xl0: flags=8843 mtu 1500 options=1 inet 89.217.11.250 netmask 0xfffffff8 broadcast 89.217.11.255 ether 00:04:75:c1:d7:76 media: Ethernet autoselect (10baseT/UTP) status: active xl1: flags=8843 mtu 1500 options=1 inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255 ether 00:01:02:e2:40:78 media: Ethernet autoselect (100baseTX ) status: active rl0: flags=8843 mtu 1500 options=40 inet 10.0.5.1 netmask 0xffffff00 broadcast 10.0.5.255 ether 00:e0:4c:e9:ec:83 media: Ethernet autoselect (100baseTX ) status: active rl1: flags=8843 mtu 1500 options=40 inet 10.0.6.1 netmask 0xffffff00 broadcast 10.0.6.255 ether 00:0a:cd:08:61:7d media: Ethernet autoselect (100baseTX ) status: active rl2: flags=8843 mtu 1500 options=40 inet 192.168.10.1 netmask 0xffffff00 broadcast 192.168.10.255 ether 00:0a:cd:08:61:6d media: Ethernet autoselect (none) status: no carrier lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 tun0: flags=8010 mtu 1500 inet 10.0.8.1 --> 10.0.8.2 netmask 0xffffffff tun0 (is an openvpn interface) As you can see POLLING is enabled on some of them. > Just to ba sure: do you have strange messages on console related to IP > configuration ? > > > [...] > > There are 2 setkey commands now, (/usr/sbin/ & /usr/local/sbin) > > can I use both ? > > For very basic usage, yes, but as you are using ipsec-tool's racoon, > it is better to also use ipsec-tool's setkey, which is the > /usr/local/sbin one. > > > > Also, sometimes I'm getting 'unsupported PF_KEY message REGISTER' > > after running setkey > > ? > > Are you sure your kernel has been correctly compiled/installed ??? I compiled it twice. No errors, standard make buildkernel/installkernel KERNCONF=TUNED Actually, I've managed to create an ipsec connection between this box & other FreeBSD box.. The problem appears when I'm trying to connect it with asmax br-604g router, which in fact is a piece of sh... I've already trashed it. The main problem is that the racoon dies from time to time, and that it puts so many interface related messages. Maybe I should reestablish the VPN connection between these 2 bsd boxes, and check if problems occur. Thanks and Hapy New Year ! -- Robert From owner-freebsd-net@FreeBSD.ORG Sat Dec 30 17:59:40 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 91AE816A512; Sat, 30 Dec 2006 17:59:40 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.freebsd.org (Postfix) with ESMTP id EE17E13C4BF; Sat, 30 Dec 2006 17:59:38 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.3) with ESMTP id kBUHxNkm094910; Sat, 30 Dec 2006 20:59:23 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.3/Submit) id kBUHxNxk094909; Sat, 30 Dec 2006 20:59:23 +0300 (MSK) (envelope-from yar) Date: Sat, 30 Dec 2006 20:59:23 +0300 From: Yar Tikhiy To: Julian Elischer Message-ID: <20061230175923.GC94532@comp.chem.msu.su> References: <4583119B.20608@elischer.org> <200612160446.02644.max@love2party.net> <4584CE0C.3020307@elischer.org> <458C426A.9060604@elischer.org> <20061224093951.GD49045@comp.chem.msu.su> <459032EA.1030601@elischer.org> <20061226061610.GD81280@comp.chem.msu.su> <459177B0.2030006@elischer.org> <20061229090556.GD76083@comp.chem.msu.su> <459565A9.201@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <459565A9.201@elischer.org> User-Agent: Mutt/1.5.9i Cc: Max Laier , Andre Oppermann , freebsd-net@freebsd.org Subject: Re: [was] addition to ipfw (read vlans from bridge).. 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, 30 Dec 2006 17:59:40 -0000 On Fri, Dec 29, 2006 at 10:59:53AM -0800, Julian Elischer wrote: > Yar Tikhiy wrote: > >On Tue, Dec 26, 2006 at 11:27:44AM -0800, Julian Elischer wrote: > >>Yar Tikhiy wrote: > >> > >>>>If what you are suggesting is that we pass into ipfw an 'offset' > >>>>into the packet as well as the packet, then yes I like that idea, > >>>>but I didn't see Andre suggest it. > >>>Do you consider only ideas by Andre? ;-) By Andre's opinion I > >>>meant this: > >>> > >>> Please have the ipfw code examine the vlan tag in the mbuf instead of > >>> fiddling with the mbuf contents. > >>At the moment I plan the ipfw code to be unaware of vlan headers. > >>the plan is: > >> Add an argument to ipfw which is the offset in the packet where > >> the IP header may be found. Change the L2 users of ipfw to > >> leave the packet alone, but calculate the correct offset to pass to > >> ipfw. IPFW will make no assumptions as to what packet contents come > >> before the offset. Bridge and L2 callers of ipfw will > >> set the offset to non-0 values where the IP callers will set it to > >> 0. The non IP callers may make some MAC information available to the > >> ipfw code my some separate method, as it does at the moment. How this > >> is done will depend if we want to support Q-n-Q, and if so, how much.. > > > >Sounds very resonable to me. > > > >>>If we want ipfw to know of L2, then examining the VLAN tag in it > >>>is OK. If not really, then ipfw (or any pfil filter) can get just > >>>the offset of IP. > >>What vlan tag? what if it's from an interface with no VLAN capacity.. > >>What we need to do is make a convention so that vlan tags are always > >>created at the lowest layer, even if HW vlan tagging is not supported, > >>so that all packets look as if they have come from HW capable packets, > >>and add code so that all non WH capable interfaces interpret Van tags at > >>the lowest level, that way vlan packets always look the same. > > > >It depends. As of now, a network interface driver passes up, e.g., > >to ether_input(), just what it has got. I.e., a driver in VLAN_HWTAG > >mode reads the tag from a hardware register and stores it in > >m_pkthdr.ether_vtag while a driver unaware of VLANs just passes up > >an 802.1q tagged frame it received. Perhaps it's ether_input() that > >should fix the things up for us so that we don't have to modify every > >VLAN-ignorant driver. > > > >However, converting the in-band tag to the out-of-band tag will > >take 1 m_pullup() call and 1 bcopy() call and 1 m_adj() call per > >tagged frame received: > > but that gets done anyhow later when we convert it.. Indeed, the main burden there should be the m_pullup() call, which cannot be avoided. > > > >if ((m->m_flags & M_VLANTAG) == 0) { > > m_pullup(m, sizeof(struct ether_vlan_header)); > > evh = mtod(m, struct ether_vlan_header *); > > if (evh->evl_ncap_proto == ETHERTYPE_VLAN) { > > > m->m_pkthdr.ether_vtag = ntohs(evh->evl_tag); > > m->m_flags |= M_VLANTAG; > > bcopy((char *)evh, (char *)evh + ETHER_VLAN_ENCAP_LEN, > > ETHER_HDR_LEN - ETHER_TYPE_LEN); > > m_adj(m, ETHER_VLAN_ENCAP_LEN); > } > > >} > > > >Now I cannot tell if there will be a noticable impact on performance > >relative to the approach when we just do things conditionally > >depending on M_VLANTAG being set or unset, e.g.: > > > >if (m->m_flags & M_VLANTAG) { > > tag = m->m_pkthdr.ether_vtag; > >} else { > > m_pullup(m, sizeof(struct ether_vlan_header)); > > evh = mtod(m, struct ether_vlan_header *); > > tag = ntohs(evh->evl_tag); > >} > >/* now do things based on tag, e.g., filtering... */ > > > > >>>Infinity. Why to introduce such a hard limit? > >> > >>Because an infinite limit complicates things? > > > >Not necessarily. It depends on what we are trying to do with the > >tags. E.g., if we want to find the IP header offset, computing it > >by skipping over an unlimited number of VLAN headers won't be more > >complex than skipping over just 1-2 of them as we need a loop > >already. > > 2 is not a loop if they are different.. note that the standard > talks about 2 different ethertypes. Also how do we currently And switch vendors use even more ethertypes for Q-in-Q frames, e.g., 0x9100 and 0x9200, but fortunately they should be configurable. For now, a Q-in-Q switch theoretically can interoperate with FreeBSD if using 0x8100 for service VLAN tags. > cope with multiple vlan tags considering that Andre has just > incorporated a single vlan tag into the mbuf? (and what happens > if we use old mtags and have multiple vlan tags? it is not defined what > happens when there are multiple mtags with the same type. How do you > get the 2nd one?) On the input path, 802.1q headers are processed one at a time. I.e., ether_input() calls vlan_input(), which in turn strips off one 802.1q header or clears the M_VLAN flag, and then calls ether_input(). Perhaps it will be an optimization to strip off all contiguous VLAN tags at once, but that is likely to break such things as the counters on the intermediate VLAN interfaces -- and bridging on them. I'm still seem to be dreaming of >2 nested VLANs. :-) -- Yar From owner-freebsd-net@FreeBSD.ORG Sat Dec 30 19:30:22 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6AA0F16A416; Sat, 30 Dec 2006 19:30:22 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2-3.pacific.net.au [61.8.2.226]) by mx1.freebsd.org (Postfix) with ESMTP id 3325C13C442; Sat, 30 Dec 2006 19:30:22 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.2.163]) by mailout2.pacific.net.au (Postfix) with ESMTP id 7E7E910D362; Sun, 31 Dec 2006 06:28:48 +1100 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (Postfix) with ESMTP id 1839427404; Sun, 31 Dec 2006 06:28:48 +1100 (EST) Date: Sun, 31 Dec 2006 06:28:48 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Doug Barton In-Reply-To: <20061230233343.U745@epsplex.bde.org> Message-ID: <20061231061903.J47883@delplex.bde.org> References: <457F0C35.3020409@FreeBSD.org> <20061213135817.P1190@delplex.bde.org> <20061230233343.U745@epsplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: oleg@freebsd.org, net@freebsd.org Subject: Re: [Fwd: Re: bge Ierr rate increase from 5.3R -> 6.1R] 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, 30 Dec 2006 19:30:22 -0000 On Sun, 31 Dec 2006, Bruce Evans wrote: > [cc changed from developers to net] > > On Wed, 13 Dec 2006, Bruce Evans wrote: > >> On Tue, 12 Dec 2006, Doug Barton wrote: >> >>> This guy's first message about this problem was very detailed, and he >>> seems highly motivated. Anyone want to help him out? >> >> This might be because bge now actually reports error statistics correctly >> (so the larger counts are correct, or because the fixes in -current >> aren't all in RELENG_6 (so the larger and smaller counts may both be >> incorrect). > > I now think that this is a bug in mii (brgphy_service()) introduced > or enlarged since FreeBSD-5.early. Under loads that can be handled, > my 5701 often gets a small number of input errors every second, and > returning immediately from brgphy_service() fixes these. bge uses the > same logic as most NIC drivers for mii_tick(), and this is bad for > interrupt latency, but the problem here seems to be mangling of packets > and unrelated to interrupt latency (high loads just usually give a > packet in flight for brgphy_service() to mangle?). More debugging showed that almost any of the reads of the phy in mii cause an input error, and the problem is apparently not present in FreeBSD-5.early because a bug maintaining sc->bge_link causes mii_tick() to almost never be called. The bug seems to have been fixed in if_bge.c 1.102. FreeBSD-5.early also seems to negotiate the link a bit faster than -current, but still too slowly. Bruce