From owner-freebsd-net@FreeBSD.ORG Sun Apr 27 01:00:17 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7CAC61065678 for ; Sun, 27 Apr 2008 01:00:17 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 0649F8FC1F for ; Sun, 27 Apr 2008 01:00:16 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JpvFV-0003fK-Fr for freebsd-net@freebsd.org; Sun, 27 Apr 2008 01:00:13 +0000 Received: from 78-1-98-246.adsl.net.t-com.hr ([78.1.98.246]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 27 Apr 2008 01:00:13 +0000 Received: from ivoras by 78-1-98-246.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 27 Apr 2008 01:00:13 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Ivan Voras Date: Sun, 27 Apr 2008 02:59:59 +0200 Lines: 86 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6C42CEAB82E66E66C020274C" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 78-1-98-246.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) In-Reply-To: X-Enigmail-Version: 0.95.6 Sender: news Subject: Re: Connecting P1i to FreeBSD 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, 27 Apr 2008 01:00:17 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6C42CEAB82E66E66C020274C Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable It might be a problem in the rum interface, because the device connects=20 perfectly to the iwi interface in the laptop. Here are ifconfigs for the = devices: rum0: flags=3D108843=20 metric 0 mtu 1500 ether 00:1c:f0:9d:08:b3 media: IEEE 802.11 Wireless Ethernet autoselect =20 (autoselect ) status: associated ssid bsd7adhoc channel 6 (2437 Mhz 11g) bssid c6:98:35:ef:28:ae authmode OPEN privacy OFF txpower 50 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11g 7 roam:rate11g 5 protmode CTS iwi0: flags=3D8843 metric 0 mtu 1= 500 ether 00:0e:35:4a:2d:e8 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect=20 ) status: associated ssid omg channel 10 (2457 Mhz 11g) bssid c6:e6:a6:49:5c:d7 authmode OPEN privacy OFF bmiss 10 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11g 7 roam:rate11g 5 protmode CTS I don't know if the differences are significant, but the first one=20 doesn't work and the second one does. One other thing: when on Windows (i.e. when it's working), the "link"=20 LED on the rum NIC flashes constantly, as well as the "act" LED. On=20 FreeBSD (when it's not), the "link" LED flashes occasionally (presumably = when there's data traffic), and the "act" link flashes as constantly as=20 before. Maybe it has something to do with the missing beacons from my past messag= es? The rum(4) man page has a CAVEAT about automatic control of transmit=20 speed but forcing it to DS/1Mbps mode 11b doesn't help (the device is=20 11b-only). --------------enig6C42CEAB82E66E66C020274C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIE9APldnAQVacBcgRAiEoAKC4Z1g0b7qGR7DYDkmzmYjAnRRxHACg/mvk tDi6yOETHbmx/C5Msu3Rr30= =3/TC -----END PGP SIGNATURE----- --------------enig6C42CEAB82E66E66C020274C-- From owner-freebsd-net@FreeBSD.ORG Sun Apr 27 02:05:08 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FDC21065673 for ; Sun, 27 Apr 2008 02:05:08 +0000 (UTC) (envelope-from martes@mgwigglesworth.com) Received: from omr5.networksolutionsemail.com (omr5.networksolutionsemail.com [205.178.146.55]) by mx1.freebsd.org (Postfix) with ESMTP id 036CF8FC16 for ; Sun, 27 Apr 2008 02:05:07 +0000 (UTC) (envelope-from martes@mgwigglesworth.com) Received: from mail.networksolutionsemail.com (ns-omr5.mgt.netsol.com [10.49.6.68]) by omr5.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id m3R256DB028309 for ; Sat, 26 Apr 2008 22:05:06 -0400 Received: (qmail 31422 invoked by uid 78); 27 Apr 2008 02:05:06 -0000 Received: from unknown (HELO ?192.168.10.27?) (martes@mgwigglesworth.com@76.182.161.209) by ns-omr5.lb.hosting.dc2.netsol.com with SMTP; 27 Apr 2008 02:05:06 -0000 From: Martes G Wigglesworth To: freebsd-net@freebsd.org In-Reply-To: References: <48134DDE.9010306@elischer.org> Content-Type: text/plain Organization: M.G.Wigglesworth,LLC Date: Sat, 26 Apr 2008 22:03:37 -0400 Message-Id: <1209261817.10040.111.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.0-2mdv2008.0 Content-Transfer-Encoding: 7bit Subject: Re: Multiple routing tables in action... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martes@mgwigglesworth.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Apr 2008 02:05:08 -0000 Sorry for my late entry into this interesting subject, however, what exactly was the original post displaying? I have 6.3-Stable running, and I don't even have the first command listed as "setfib", on my system. What did the setfib -l command do, so that you were able to see two distinctly different routing tables? On Sat, 2008-04-26 at 21:09 +0300, Ivo Vachkov wrote: > when do we get to see those patches ? :) > > On Sat, Apr 26, 2008 at 6:44 PM, Julian Elischer wrote: > > A little progress report > > > > From a recently installed (6.3) machine.... (plus patches) > > > > wsa02:julian 9] setfib -0 netstat -rn > > Routing tables > > > > Internet: > > Destination Gateway Flags Refs Use Netif Expire > > default 172.28.14.1 UGS 0 788 bce1 > > 127.0.0.1 127.0.0.1 UH 0 379 lo0 > > 172.28.5/24 172.28.14.1 UGS 0 10 bce1 > > 172.28.6.32/28 link#2 UC 0 0 em0 > > 172.28.6.33 00:15:2b:46:56:90 UHLW 1 0 em0 1190 > > 172.28.14/24 link#6 UC 0 0 bce1 > > 172.28.14.1 00:04:23:b5:a9:2b UHLW 3 0 bce1 1117 > > wsa02:julian 10] setfib -1 netstat -rn > > Routing tables > > > > Internet: > > Destination Gateway Flags Refs Use Netif Expire > > default 172.28.6.33 UGS 0 0 em0 > > 1.1.1/28 172.28.6.33 UGS 0 0 em0 > > 127.0.0.1 127.0.0.1 UH 0 1 lo0 > > 172.28.5/24 172.28.6.33 UGS 0 6 em0 > > 172.28.6.32/28 link#2 UC 0 0 em0 > > 172.28.6.33 00:15:2b:46:56:90 UHLW 4 6 em0 1182 > > wsa02:rjulian 11] > > > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > > > From owner-freebsd-net@FreeBSD.ORG Sun Apr 27 03:51:21 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B291A1065675 for ; Sun, 27 Apr 2008 03:51:21 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.251]) by mx1.freebsd.org (Postfix) with ESMTP id 6A3D18FC14 for ; Sun, 27 Apr 2008 03:51:21 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so1187226anc.13 for ; Sat, 26 Apr 2008 20:51:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=MXILP9kRPhgkQYE087AhFSMVgRwrl1N5bV3RvSv37sY=; b=Rif8W00PUov6yhYz9AyENH+gdmvlLPPpk3rh3Ph3Pmabh1nsIvCorQeb7lO5Gx3c+mA4sA4hGBDUP5NI9HUzyhDisGXZT/TVLlNhfdaA7GNY4jg1E2WGJQhkLefLqetijFL4ZT0LQD+f5Tzu5sdPwyVzm0P+cq9yArcoaHgnDJY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=CO07C5tbxCv61OiJomQ6d1tMN05+uIcAdRN95jZlTsGuRSHDzrRugu5NmrkoK0tZs5SrA7Tpt3EzjZTqpiZYbqorp5E3d0rUzoMgSoyve1xEsBOMkME2zcBZjWa5pecexoG9PbAUu/pQmb4nuSdOW9JQu1NhGsCb8RNt/+XPhLQ= Received: by 10.100.214.19 with SMTP id m19mr10016766ang.50.1209268280622; Sat, 26 Apr 2008 20:51:20 -0700 (PDT) Received: by 10.100.48.5 with HTTP; Sat, 26 Apr 2008 20:51:20 -0700 (PDT) Message-ID: Date: Sun, 27 Apr 2008 11:51:20 +0800 From: "Sepherosa Ziehau" To: freebsd-net In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: Kevin Lo Subject: Re: Connecting P1i to FreeBSD 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, 27 Apr 2008 03:51:21 -0000 On Sun, Apr 27, 2008 at 7:52 AM, Ivan Voras wrote: > Ivan Voras wrote: > > > Sepherosa Ziehau wrote: > > > > > > > Are you sure that your device works under IBSS mode? > > > > > > > Yes, since Windows doesn't support creating an AP from the card, and it > connects to Windows. Unless there are other modes that can do the same > thing... > > > > Actually there is a difference; here's a dump from laptop where the device > connects to the Windows machine: > > 23:49:18.013539 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6, > PRIVACY > 23:49:18.045340 Beacon (A2) [1.0* 2.0* 5.5* 11.0* Mbit] IBSS CH: 6, PRIVACY > 23:49:18.148408 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6, > PRIVACY > 23:49:18.374477 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6, > PRIVACY > 23:49:18.377198 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6, > PRIVACY > 23:49:18.379066 Probe Response (SpeedTouch425488) [1.0* 2.0* 5.5* 11.0* > 18.0 24.0 36.0 54.0 Mbit] CH: 6, PRIVACY > 23:49:18.659907 Beacon (A2) [1.0* 2.0* 5.5* 11.0* Mbit] IBSS CH: 6, PRIVACY > 23:49:18.734842 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6, > PRIVACY > 23:49:18.762218 Beacon (A2) [1.0* 2.0* 5.5* 11.0* Mbit] IBSS CH: 6, PRIVACY > 23:49:19.005423 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6, > PRIVACY > 23:49:19.008301 Probe Response (SpeedTouch425488) [1.0* 2.0* 5.5* 11.0* > 18.0 24.0 36.0 54.0 Mbit] CH: 6, PRIVACY > 23:49:19.026747 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6, > PRIVACY > 23:49:19.366882 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6, > PRIVACY > 23:49:19.376645 Beacon (A2) [1.0* 2.0* 5.5* 11.0* Mbit] IBSS CH: 6, PRIVACY > 23:49:19.411652 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6, > PRIVACY > 23:49:19.636460 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6, > PRIVACY > 23:49:19.637575 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6, > PRIVACY > 23:49:19.888667 Beacon (A2) [1.0* 2.0* 5.5* 11.0* Mbit] IBSS CH: 6, PRIVACY > 23:49:19.990770 Beacon (A2) [1.0* 2.0* 5.5* 11.0* Mbit] IBSS CH: 6, PRIVACY > 23:49:19.997530 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6, > PRIVACY > 23:49:20.268038 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6, > PRIVACY > 23:49:20.269293 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6, > PRIVACY > 23:49:20.271670 Probe Response (SpeedTouch425488) [1.0* 2.0* 5.5* 11.0* > 18.0 24.0 36.0 54.0 Mbit] CH: 6, PRIVACY > 23:49:20.274467 Beacon (SpeedTouch425488) [1.0* 2.0* 5.5* 11.0* 18.0 24.0 > 36.0 54.0 Mbit] ESS CH: 6, PRIVACY > 23:49:20.297986 Beacon (A2) [1.0* 2.0* 5.5* 11.0* Mbit] IBSS CH: 6, PRIVACY > 23:49:20.492967 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6, > PRIVACY > 23:49:20.502751 Beacon (A2) [1.0* 2.0* 5.5* 11.0* Mbit] IBSS CH: 6, PRIVACY > 23:49:20.629491 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6, > PRIVACY > 23:49:20.707738 Beacon (A2) [1.0* 2.0* 5.5* 11.0* Mbit] IBSS CH: 6, PRIVACY > 23:49:20.899123 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6, > PRIVACY > 23:49:20.901458 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6, > PRIVACY > 23:49:20.989459 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6, > PRIVACY > 23:49:21.124700 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6, > PRIVACY > 23:49:21.219413 Beacon (A2) [1.0* 2.0* 5.5* 11.0* Mbit] IBSS CH: 6, PRIVACY > 23:49:21.259747 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6, > PRIVACY > 23:49:21.321793 Beacon (A2) [1.0* 2.0* 5.5* 11.0* Mbit] IBSS CH: 6, PRIVACY > 23:49:21.530624 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6, > PRIVACY > 23:49:21.531691 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6, > PRIVACY > 23:49:21.533326 Probe Response (SpeedTouch425488) [1.0* 2.0* 5.5* 11.0* > 18.0 24.0 36.0 54.0 Mbit] CH: 6, PRIVACY > 23:49:21.833759 Beacon (A2) [1.0* 2.0* 5.5* 11.0* Mbit] IBSS CH: 6, PRIVACY > > I didn't get the "Beacon" entries before. I expected to see actual data > packets in tcpdump, but I assume they are not in the dump because we're only > looking at the 802.11 events with -y ieee802_11? > I think you are using iwi to do the tap, could you put iwi into monitor mode, since iwi is "smart" device which may filter certain type of frames in non-monitor mode? I tested my rum: the beacon template set in the hardware is trashed in a strange a pattern What I got in the air; fc duration and certain part of mac address is trashed: 11:04:57.256700 Assoc Request (sephe-adhoc) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 Mbit] 0x0000: 0000 2a01 0032 0430 4860 6c18 f32f 077a 0x0010: 4e9c 3b6a eb9f b01d afbe e402 0000 0000 0x0020: 6400 2200 000b 7365 7068 652d 6164 686f 0x0030: 6301 0882 848b 960c 1218 2403 0101 0602 0x0040: 9056 e96b 88d0 f6ef 5cc9 1d The actual beacon mbuf content: 80 00 00 00 ff ff ff ff ff ff 00 18 f3 2f 07 7a 4e 9c 3b 6a eb 9f 00 00 00 00 00 00 00 00 00 00 64 00 22 00 00 0b 73 65 70 68 65 2d 61 64 68 6f 63 01 08 82 84 8b 96 0c 12 18 24 03 01 01 06 02 00 00 2a 01 00 32 04 30 48 60 6c After several small code change, I found that beacon template size can't exceeds 64bytes. Small template space means you could only use rum IBSS in 11b mode. I have tried to setup BEACON_BASE1 but without result. If it is not a hardware design flaw then we will need data sheet to make it correct. Best Regards, sephe -- Live Free or Die From owner-freebsd-net@FreeBSD.ORG Sun Apr 27 03:52:59 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1DFC61065672 for ; Sun, 27 Apr 2008 03:52:59 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.250]) by mx1.freebsd.org (Postfix) with ESMTP id CAF288FC17 for ; Sun, 27 Apr 2008 03:52:58 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so1187286anc.13 for ; Sat, 26 Apr 2008 20:52:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=MrhfPoEQxJ4M/uK9wH/CNfeerUMbMbrQEKPVwpyaSHc=; b=gAO8C8RV3t+q8+/T7mI5V+aBAeHqGayuZtSIlqDPFDSoMDGTxNzLYCaYgGrFnqDT+iNFoCvaAVNtKqFJj0ON303ghsFnwwryVKtlXtVsOKEOzcmwjYm6VI5Oi9+JPWsoVPPlfQZgPpsv21sFlbRnyrMPjwr8Vjm5MYqSPm9JAZE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jh4KkQrIDMDAGwxsENzr01AtJJ7k8Bf+G5uDYm6cSJJHT2Tu1xR4TlBRjTflnQ8SKRbFZpOH12AjRmUOKj6kLd2YYH2eOaHJkXLjIH1tzGeane1eYBjvPzoF3iENi7H3TN7Fjiqwrcup08GIemukS4Z/1ovLF6YXqi340gbDFDQ= Received: by 10.100.91.17 with SMTP id o17mr9983974anb.145.1209268378186; Sat, 26 Apr 2008 20:52:58 -0700 (PDT) Received: by 10.100.48.5 with HTTP; Sat, 26 Apr 2008 20:52:58 -0700 (PDT) Message-ID: Date: Sun, 27 Apr 2008 11:52:58 +0800 From: "Sepherosa Ziehau" To: freebsd-net In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: Kevin Lo Subject: Re: Connecting P1i to FreeBSD 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, 27 Apr 2008 03:52:59 -0000 On Sun, Apr 27, 2008 at 11:51 AM, Sepherosa Ziehau wrote: > > On Sun, Apr 27, 2008 at 7:52 AM, Ivan Voras wrote: > > Ivan Voras wrote: > > > > > Sepherosa Ziehau wrote: > > > > > > > > > > Are you sure that your device works under IBSS mode? > > > > > > > > > > Yes, since Windows doesn't support creating an AP from the card, and it > > connects to Windows. Unless there are other modes that can do the same > > thing... > > > > > > > Actually there is a difference; here's a dump from laptop where the device > > connects to the Windows machine: > > > > 23:49:18.013539 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6, > > PRIVACY > > 23:49:18.045340 Beacon (A2) [1.0* 2.0* 5.5* 11.0* Mbit] IBSS CH: 6, PRIVACY > > 23:49:18.148408 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6, > > PRIVACY > > 23:49:18.374477 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6, > > PRIVACY > > 23:49:18.377198 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6, > > PRIVACY > > 23:49:18.379066 Probe Response (SpeedTouch425488) [1.0* 2.0* 5.5* 11.0* > > 18.0 24.0 36.0 54.0 Mbit] CH: 6, PRIVACY > > 23:49:18.659907 Beacon (A2) [1.0* 2.0* 5.5* 11.0* Mbit] IBSS CH: 6, PRIVACY > > 23:49:18.734842 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6, > > PRIVACY > > 23:49:18.762218 Beacon (A2) [1.0* 2.0* 5.5* 11.0* Mbit] IBSS CH: 6, PRIVACY > > 23:49:19.005423 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6, > > PRIVACY > > 23:49:19.008301 Probe Response (SpeedTouch425488) [1.0* 2.0* 5.5* 11.0* > > 18.0 24.0 36.0 54.0 Mbit] CH: 6, PRIVACY > > 23:49:19.026747 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6, > > PRIVACY > > 23:49:19.366882 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6, > > PRIVACY > > 23:49:19.376645 Beacon (A2) [1.0* 2.0* 5.5* 11.0* Mbit] IBSS CH: 6, PRIVACY > > 23:49:19.411652 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6, > > PRIVACY > > 23:49:19.636460 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6, > > PRIVACY > > 23:49:19.637575 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6, > > PRIVACY > > 23:49:19.888667 Beacon (A2) [1.0* 2.0* 5.5* 11.0* Mbit] IBSS CH: 6, PRIVACY > > 23:49:19.990770 Beacon (A2) [1.0* 2.0* 5.5* 11.0* Mbit] IBSS CH: 6, PRIVACY > > 23:49:19.997530 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6, > > PRIVACY > > 23:49:20.268038 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6, > > PRIVACY > > 23:49:20.269293 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6, > > PRIVACY > > 23:49:20.271670 Probe Response (SpeedTouch425488) [1.0* 2.0* 5.5* 11.0* > > 18.0 24.0 36.0 54.0 Mbit] CH: 6, PRIVACY > > 23:49:20.274467 Beacon (SpeedTouch425488) [1.0* 2.0* 5.5* 11.0* 18.0 24.0 > > 36.0 54.0 Mbit] ESS CH: 6, PRIVACY > > 23:49:20.297986 Beacon (A2) [1.0* 2.0* 5.5* 11.0* Mbit] IBSS CH: 6, PRIVACY > > 23:49:20.492967 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6, > > PRIVACY > > 23:49:20.502751 Beacon (A2) [1.0* 2.0* 5.5* 11.0* Mbit] IBSS CH: 6, PRIVACY > > 23:49:20.629491 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6, > > PRIVACY > > 23:49:20.707738 Beacon (A2) [1.0* 2.0* 5.5* 11.0* Mbit] IBSS CH: 6, PRIVACY > > 23:49:20.899123 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6, > > PRIVACY > > 23:49:20.901458 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6, > > PRIVACY > > 23:49:20.989459 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6, > > PRIVACY > > 23:49:21.124700 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6, > > PRIVACY > > 23:49:21.219413 Beacon (A2) [1.0* 2.0* 5.5* 11.0* Mbit] IBSS CH: 6, PRIVACY > > 23:49:21.259747 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6, > > PRIVACY > > 23:49:21.321793 Beacon (A2) [1.0* 2.0* 5.5* 11.0* Mbit] IBSS CH: 6, PRIVACY > > 23:49:21.530624 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6, > > PRIVACY > > 23:49:21.531691 Probe Response (A2) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6, > > PRIVACY > > 23:49:21.533326 Probe Response (SpeedTouch425488) [1.0* 2.0* 5.5* 11.0* > > 18.0 24.0 36.0 54.0 Mbit] CH: 6, PRIVACY > > 23:49:21.833759 Beacon (A2) [1.0* 2.0* 5.5* 11.0* Mbit] IBSS CH: 6, PRIVACY > > > > I didn't get the "Beacon" entries before. I expected to see actual data > > packets in tcpdump, but I assume they are not in the dump because we're only > > looking at the 802.11 events with -y ieee802_11? > > > > I think you are using iwi to do the tap, could you put iwi into > monitor mode, since iwi is "smart" device which may filter certain > type of frames in non-monitor mode? > > I tested my rum: the beacon template set in the hardware is trashed in > a strange a pattern BTW, the pattern is anything beyond 64bytes will be wrapped. See the dump and the beacon content. > > What I got in the air; fc duration and certain part of mac address is trashed: > 11:04:57.256700 Assoc Request (sephe-adhoc) [1.0* 2.0* 5.5* 11.0* 6.0 > > 9.0 12.0 18.0 Mbit] > 0x0000: 0000 2a01 0032 0430 4860 6c18 f32f 077a > 0x0010: 4e9c 3b6a eb9f b01d afbe e402 0000 0000 > 0x0020: 6400 2200 000b 7365 7068 652d 6164 686f > 0x0030: 6301 0882 848b 960c 1218 2403 0101 0602 > 0x0040: 9056 e96b 88d0 f6ef 5cc9 1d > > The actual beacon mbuf content: > 80 00 00 00 ff ff ff ff ff ff 00 18 f3 2f 07 7a > 4e 9c 3b 6a eb 9f 00 00 00 00 00 00 00 00 00 00 > 64 00 22 00 00 0b 73 65 70 68 65 2d 61 64 68 6f > 63 01 08 82 84 8b 96 0c 12 18 24 03 01 01 06 02 > 00 00 2a 01 00 32 04 30 48 60 6c > > After several small code change, I found that beacon template size > can't exceeds 64bytes. Small template space means you could only use > rum IBSS in 11b mode. I have tried to setup BEACON_BASE1 but without > result. If it is not a hardware design flaw then we will need data > sheet to make it correct. > > > > Best Regards, > sephe > > -- > Live Free or Die > -- Live Free or Die From owner-freebsd-net@FreeBSD.ORG Sun Apr 27 04:56:28 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3751A1065678 for ; Sun, 27 Apr 2008 04:56:28 +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 F3D1C8FC14 for ; Sun, 27 Apr 2008 04:56:27 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Sun, 27 Apr 2008 00:38:27 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 9CB152D6006; Sat, 26 Apr 2008 21:56:26 -0700 (PDT) Message-ID: <48140779.1060302@elischer.org> Date: Sat, 26 Apr 2008 21:56:25 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: martes@mgwigglesworth.com References: <48134DDE.9010306@elischer.org> <1209261817.10040.111.camel@localhost> In-Reply-To: <1209261817.10040.111.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Multiple routing tables in action... 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, 27 Apr 2008 04:56:28 -0000 Martes G Wigglesworth wrote: > Sorry for my late entry into this interesting subject, however, what > exactly was the original post displaying? I have 6.3-Stable running, > and I don't even have the first command listed as "setfib", on my > system. > > What did the setfib -l command do, so that you were able to see two > distinctly different routing tables? setfib -1 .. (that is "minus one") executes the following command with the default routing table (fib) set to the second table (table 1). setfib -0 (that's "minus zero") runs the folling arguments as a command with it's default routing table set to the first routing table (table 0). the setfib command is added as part of the patch. > > On Sat, 2008-04-26 at 21:09 +0300, Ivo Vachkov wrote: >> when do we get to see those patches ? :) >> >> On Sat, Apr 26, 2008 at 6:44 PM, Julian Elischer wrote: >>> A little progress report >>> >>> From a recently installed (6.3) machine.... (plus patches) >>> >>> wsa02:julian 9] setfib -0 netstat -rn >>> Routing tables >>> >>> Internet: >>> Destination Gateway Flags Refs Use Netif Expire >>> default 172.28.14.1 UGS 0 788 bce1 >>> 127.0.0.1 127.0.0.1 UH 0 379 lo0 >>> 172.28.5/24 172.28.14.1 UGS 0 10 bce1 >>> 172.28.6.32/28 link#2 UC 0 0 em0 >>> 172.28.6.33 00:15:2b:46:56:90 UHLW 1 0 em0 1190 >>> 172.28.14/24 link#6 UC 0 0 bce1 >>> 172.28.14.1 00:04:23:b5:a9:2b UHLW 3 0 bce1 1117 >>> wsa02:julian 10] setfib -1 netstat -rn >>> Routing tables >>> >>> Internet: >>> Destination Gateway Flags Refs Use Netif Expire >>> default 172.28.6.33 UGS 0 0 em0 >>> 1.1.1/28 172.28.6.33 UGS 0 0 em0 >>> 127.0.0.1 127.0.0.1 UH 0 1 lo0 >>> 172.28.5/24 172.28.6.33 UGS 0 6 em0 >>> 172.28.6.32/28 link#2 UC 0 0 em0 >>> 172.28.6.33 00:15:2b:46:56:90 UHLW 4 6 em0 1182 >>> wsa02:rjulian 11] >>> >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >>> >> >> > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sun Apr 27 15:36:44 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BBAEF1065673 for ; Sun, 27 Apr 2008 15:36:44 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (unknown [IPv6:2001:41d0:1:2ad2::1]) by mx1.freebsd.org (Postfix) with ESMTP id EC5DA8FC26 for ; Sun, 27 Apr 2008 15:36:43 +0000 (UTC) (envelope-from hlh@restart.be) Received: from restart.be (avoriaz.tunnel.bel [IPv6:2001:41d0:1:2ad2::fffe:0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "avoriaz.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 9576F1BAC5B for ; Sun, 27 Apr 2008 17:36:42 +0200 (CEST) Received: from morzine.restart.bel (morzine6.restart.bel [IPv6:2001:41d0:1:2ad2::1:2]) (authenticated bits=0) by restart.be (8.14.2/8.14.2) with ESMTP id m3RFadRc061639 for ; Sun, 27 Apr 2008 17:36:40 +0200 (CEST) (envelope-from hlh@restart.be) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=restart.be; s=avoriaz; t=1209310601; bh=LZ2mye+mh5wEoKZ9Ib3j6ftELhePmBXlDcfQLS2 nf/M=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=aRiih7+cPVF26St0F6BE51ZSV8SdtqP973B7E MMZ4gPANjaBG5RLdFDTtKrDPI2xR9aLsypk7Sg1NJtCG/DSxg== DomainKey-Signature: a=rsa-sha1; s=avoriaz; d=restart.be; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to: subject:content-type:content-transfer-encoding:x-scanned-by; b=Gvi41OKFUP3Sqps9p7g3iOoTAizJTBdCBTrU9CE+aUOujtzIk3TT7/nLESpm6o0d/ 232crUjWGqn1lJBU7d8+g== Message-ID: <48149D87.9070202@restart.be> Date: Sun, 27 Apr 2008 17:36:39 +0200 From: Henri Hennebert Organization: RestartSoft User-Agent: Thunderbird 2.0.0.12 (X11/20080427) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on IPv6:2001:41d0:1:2ad2::1:1 Subject: 7.0-STABLE - ping6 and tap - kernel crash 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, 27 Apr 2008 15:36:44 -0000 Hello, I encounter a crash during a ping6 on a tap interface. I am running an instance of Freebsd 7.0-RELEASE under qemu. on the host machine: # uname -a FreeBSD morzine.restart.bel 7.0-STABLE FreeBSD 7.0-STABLE #0: Sat Apr 26 17:49:50 CEST 2008 root@morzine.restart.bel:/usr/obj/usr/src/sys/MORZINE i386 # ifconfig -a em0: flags=8843 metric 0 mtu 1500 options=19b ether 00:e0:81:70:6b:68 inet6 fe80::2e0:81ff:fe70:6b68%em0 prefixlen 64 scopeid 0x1 inet 192.168.24.2 netmask 0xffffff00 broadcast 192.168.24.255 inet6 2001:41d0:1:2ad2::1:2 prefixlen 112 media: Ethernet 100baseTX (100baseTX ) status: active lo0: flags=8049 metric 0 mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet 127.0.0.1 netmask 0xff000000 tap0: flags=8843 metric 0 mtu 1500 ether 00:bd:2c:94:01:00 inet 192.168.22.1 netmask 0xffffff00 broadcast 192.168.22.255 inet6 fe80::2bd:2cff:fe94:100%tap0 prefixlen 64 scopeid 0x3 inet6 2001:41d0:1:2ad2::2:1 prefixlen 112 Opened by PID 1579 [tap0 is connected to the qemu] if I ping6 2001:41d0:1:2ad2::2:fe03 witch is not the ipv6 address off the qemu configuration, after one or 2 minutes, I get: kgdb -c /var/crash/vmcore.42 kernel [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". There is no member named pathname. Reading symbols from ./zfs.ko...Reading symbols from /bootfs/boot/kernel/zfs.ko.symbols...done. done. Loaded symbols for ./zfs.ko Reading symbols from ./if_tap.ko...Reading symbols from /bootfs/boot/kernel/if_tap.ko.symbols...done. done. Loaded symbols for ./if_tap.ko Reading symbols from ./ng_ether.ko...Reading symbols from /bootfs/boot/kernel/ng_ether.ko.symbols...done. done. Loaded symbols for ./ng_ether.ko Reading symbols from ./netgraph.ko...Reading symbols from /bootfs/boot/kernel/netgraph.ko.symbols...done. done. Loaded symbols for ./netgraph.ko Reading symbols from ./sound.ko...Reading symbols from /bootfs/boot/kernel/sound.ko.symbols...done. done. Loaded symbols for ./sound.ko Reading symbols from ./snd_hda.ko...Reading symbols from /bootfs/boot/kernel/snd_hda.ko.symbols...done. done. Loaded symbols for ./snd_hda.ko Reading symbols from ./acpi_video.ko...Reading symbols from /bootfs/boot/kernel/acpi_video.ko.symbols...done. done. Loaded symbols for ./acpi_video.ko Reading symbols from ./acpi.ko...Reading symbols from /bootfs/boot/kernel/acpi.ko.symbols...done. done. Loaded symbols for ./acpi.ko Reading symbols from ./coretemp.ko...Reading symbols from /bootfs/boot/kernel/coretemp.ko.symbols...done. done. Loaded symbols for ./coretemp.ko Reading symbols from ./accf_http.ko...Reading symbols from /bootfs/boot/kernel/accf_http.ko.symbols...done. done. Loaded symbols for ./accf_http.ko Reading symbols from ./daemon_saver.ko...Reading symbols from /bootfs/boot/kernel/daemon_saver.ko.symbols...done. done. Loaded symbols for ./daemon_saver.ko Reading symbols from ./agp.ko...Reading symbols from /bootfs/boot/kernel/agp.ko.symbols...done. done. Loaded symbols for ./agp.ko Reading symbols from ./aio.ko...Reading symbols from /bootfs/boot/kernel/aio.ko.symbols...done. done. Loaded symbols for ./aio.ko Reading symbols from /boot/modules/kqemu.ko...done. Loaded symbols for /boot/modules/kqemu.ko Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x6d8f17e6 fault code = supervisor read, page not present instruction pointer = 0x20:0xa06e4bd3 stack pointer = 0x28:0xf734fc30 frame pointer = 0x28:0xf734fc4c code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 14 (swi4: clock sio) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper(a08224e4,f734facc,a05b270f,a083dd24,0,...) at db_trace_self_wrapper+0x26 kdb_backtrace(a083dd24,0,a0804f82,f734fad8,0,...) at kdb_backtrace+0x29 panic(a0804f82,a083f01d,a5535224,1,1,...) at panic+0x10f trap_fatal(a089d000,6d8f1000,1,0,0,...) at trap_fatal+0x333 trap_pfault(81,f734fb74,a05d0bdc,a826e220,a5535000,...) at trap_pfault+0x270 trap(f734fbf0) at trap+0x3fa calltrap() at calltrap+0x6 --- trap 0xc, eip = 0xa06e4bd3, esp = 0xf734fc30, ebp = 0xf734fc4c --- icmp6_error2(a71e8500,1,3,0,a56e9800,...) at icmp6_error2+0xc3 nd6_llinfo_timer(ad2a3140,a5537440,0,f734fcbc,a05ba486,...) at nd6_llinfo_timer+0x158 softclock(0,0,a081e0bf,46b,0,...) at softclock+0x2ba ithread_loop(a55345b0,f734fd38,0,0,0,...) at ithread_loop+0x1ab fork_exit(a05926f0,a55345b0,f734fd38) at fork_exit+0x99 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xf734fd70, ebp = 0 --- Uptime: 11m32s Physical memory: 2030 MB Dumping 205 MB: 190 174 158 142 126 110 94 78 62 46 30 14 #0 doadump () at pcpu.h:195 195 pcpu.h: No such file or directory. in pcpu.h (kgdb) gnat show me nothing relevant - any idea ? Henri From owner-freebsd-net@FreeBSD.ORG Sun Apr 27 15:44:09 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86135106566B for ; Sun, 27 Apr 2008 15:44:09 +0000 (UTC) (envelope-from martes@mgwigglesworth.com) Received: from omr3.networksolutionsemail.com (omr3.networksolutionsemail.com [205.178.146.53]) by mx1.freebsd.org (Postfix) with ESMTP id 2D35E8FC12 for ; Sun, 27 Apr 2008 15:44:08 +0000 (UTC) (envelope-from martes@mgwigglesworth.com) Received: from mail.networksolutionsemail.com (ns-omr3.mgt.netsolmail.com [10.49.6.66]) by omr3.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id m3RFi7xw030308 for ; Sun, 27 Apr 2008 11:44:08 -0400 Received: (qmail 6718 invoked by uid 78); 27 Apr 2008 15:44:07 -0000 Received: from unknown (HELO ?192.168.10.27?) (martes@mgwigglesworth.com@76.182.161.209) by ns-omr3.lb.hosting.dc2.netsol.com with SMTP; 27 Apr 2008 15:44:07 -0000 From: Martes G Wigglesworth To: freebsd-net@freebsd.org Content-Type: text/plain Organization: M.G.Wigglesworth,LLC Date: Sun, 27 Apr 2008 11:42:39 -0400 Message-Id: <1209310959.10040.116.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.0-2mdv2008.0 Content-Transfer-Encoding: 7bit Subject: VLAN Trunking with Freebsd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martes@mgwigglesworth.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Apr 2008 15:44:09 -0000 I am sure this topic has been discussed before, however, I have been coming across unanswered inquiries within the last two months about possibly using the trunking aspect of 802.1q standard network routing, with only freebsd. I have attempted to create mulitple vlan interfaces and have failed, on 6.3-Stable. Does anyone know if the vlan emplimentation on Freebsd allows for trunking or, at the least, multiple vlans per physical device? -- Martes G Wigglesworth M.G.Wigglesworth,LLC From owner-freebsd-net@FreeBSD.ORG Sun Apr 27 15:47:35 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7C35106564A for ; Sun, 27 Apr 2008 15:47:35 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from pele.citylink.co.nz (pele.citylink.co.nz [202.8.44.226]) by mx1.freebsd.org (Postfix) with ESMTP id 79B928FC23 for ; Sun, 27 Apr 2008 15:47:35 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id 3D5CB2BDDF; Mon, 28 Apr 2008 03:47:34 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at citylink.co.nz Received: from pele.citylink.co.nz ([127.0.0.1]) by localhost (pele.citylink.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3AjEAdIoQbMU; Mon, 28 Apr 2008 03:47:29 +1200 (NZST) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP; Mon, 28 Apr 2008 03:47:29 +1200 (NZST) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id 6940F1142D; Mon, 28 Apr 2008 03:47:28 +1200 (NZST) Date: Mon, 28 Apr 2008 03:47:28 +1200 From: Andrew Thompson To: Martes G Wigglesworth Message-ID: <20080427154728.GF98671@citylink.fud.org.nz> References: <1209310959.10040.116.camel@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1209310959.10040.116.camel@localhost> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-net@freebsd.org Subject: Re: VLAN Trunking with Freebsd 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, 27 Apr 2008 15:47:35 -0000 On Sun, Apr 27, 2008 at 11:42:39AM -0400, Martes G Wigglesworth wrote: > I am sure this topic has been discussed before, however, I have been > coming across unanswered inquiries within the last two months about > possibly using the trunking aspect of 802.1q standard network routing, > with only freebsd. > > I have attempted to create mulitple vlan interfaces and have failed, on > 6.3-Stable. > > Does anyone know if the vlan emplimentation on Freebsd allows for > trunking or, at the least, multiple vlans per physical device? I sure does, maybe you could post your config to see where its going wrong. ifconfig em0.100 create ifconfig em0.101 create ifconfig em0.102 create ... ifconfig em0.110 create Andrew From owner-freebsd-net@FreeBSD.ORG Sun Apr 27 18:42:18 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18387106564A for ; Sun, 27 Apr 2008 18:42:18 +0000 (UTC) (envelope-from jhary@unsane.co.uk) Received: from unsane.co.uk (unknown [IPv6:2001:470:1f08:110::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8CB498FC12 for ; Sun, 27 Apr 2008 18:42:17 +0000 (UTC) (envelope-from jhary@unsane.co.uk) Received: from crab.unsane.co.uk (crab.unsane.co.uk [10.0.0.111]) (authenticated bits=0) by unsane.co.uk (8.14.0/8.14.0) with ESMTP id m3RIeq72018298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 27 Apr 2008 19:41:22 +0100 (BST) (envelope-from jhary@unsane.co.uk) Message-ID: <4814C8A5.9070605@unsane.co.uk> Date: Sun, 27 Apr 2008 19:40:37 +0100 From: Vince User-Agent: Thunderbird 2.0.0.12 (X11/20080426) MIME-Version: 1.0 To: Kevin Oberman References: <20080425211622.302CB45010@ptavv.es.net> In-Reply-To: <20080425211622.302CB45010@ptavv.es.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: ipfw can't be disabled for IPv56 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, 27 Apr 2008 18:42:18 -0000 Kevin Oberman wrote: >> Date: Fri, 25 Apr 2008 16:48:46 -0300 >> From: "Tobias P. Santos" >> >> Kevin Oberman wrote: >>> Running 7-STABLE of April 10, if I disable the firewall ('sysctl >>> net.inet.ip.fw.enable=0'), IPv4 traffic passes, but IPv6 will not. I had >>> to add a "allow ip from any to any" rule to get IPv6 to work pass >>> traffic. (Since I was accessing the system in question via IPv6, this >>> was a bit annoying!) >>> >>> Am I missing anything? The rc.subr script for ipfw just sets the sysctl I >>> did when it stops the firewall. >> >> net.link.ether.ipfw: 0 >> net.inet6.ip6.fw.enable: 1 <------------ voila!!! >> net.inet6.ip6.fw.debug: 1 > > Thanks! I need to file a PR to get that into the rc script. I should > have looked for a inet6 specific sysctl for this. Hate to say this but.... # # $FreeBSD: src/etc/rc.d/ip6fw,v 1.9 2007/04/02 15:38:53 mtm Exp $ # # PROVIDE: ip6fw # REQUIRE: routing # BEFORE: network_ipv6 # KEYWORD: nojail . /etc/rc.subr name="ip6fw" rcvar=`set_rcvar ipv6_firewall` start_cmd="ip6fw_start" stop_cmd="${SYSCTL_W} net.inet6.ip6.fw.enable=0" required_modules="ipfw" From owner-freebsd-net@FreeBSD.ORG Sun Apr 27 18:44:49 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3BA881065682; Sun, 27 Apr 2008 18:44:49 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0A2FC8FC1C; Sun, 27 Apr 2008 18:44:49 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m3RIimi6067793; Sun, 27 Apr 2008 18:44:48 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m3RIimjM067789; Sun, 27 Apr 2008 18:44:48 GMT (envelope-from linimon) Date: Sun, 27 Apr 2008 18:44:48 GMT Message-Id: <200804271844.m3RIimjM067789@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/123138: [bpf] [patch] bpf incorrectly determines outgoing routed packets as incoming when BIOCSDIRECTION is used 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, 27 Apr 2008 18:44:49 -0000 Old Synopsis: bpf incorrectly determines outgoing routed packets as incoming when BIOCSDIRECTION is used New Synopsis: [bpf] [patch] bpf incorrectly determines outgoing routed packets as incoming when BIOCSDIRECTION is used Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Apr 27 18:44:05 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=123138 From owner-freebsd-net@FreeBSD.ORG Sun Apr 27 19:04:12 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 608DE106566C; Sun, 27 Apr 2008 19:04:12 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2FD0E8FC18; Sun, 27 Apr 2008 19:04:12 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (gavin@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m3RJ4CDC068555; Sun, 27 Apr 2008 19:04:12 GMT (envelope-from gavin@freefall.freebsd.org) Received: (from gavin@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m3RJ4Cuf068551; Sun, 27 Apr 2008 19:04:12 GMT (envelope-from gavin) Date: Sun, 27 Apr 2008 19:04:12 GMT Message-Id: <200804271904.m3RJ4Cuf068551@freefall.freebsd.org> To: gavin@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: gavin@FreeBSD.org Cc: Subject: Re: kern/123147: [ti] [patch] ti(4) doesn't use mii, but kernel configs say it does 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, 27 Apr 2008 19:04:12 -0000 Synopsis: [ti] [patch] ti(4) doesn't use mii, but kernel configs say it does Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Sun Apr 27 19:03:42 UTC 2008 Responsible-Changed-Why: Over to maintainers http://www.freebsd.org/cgi/query-pr.cgi?pr=123147 From owner-freebsd-net@FreeBSD.ORG Sun Apr 27 20:55:07 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8276106564A for ; Sun, 27 Apr 2008 20:55:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 8C0228FC0A for ; Sun, 27 Apr 2008 20:55:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 66C8041C75E; Sun, 27 Apr 2008 22:55:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id 25aCdr5ksA7s; Sun, 27 Apr 2008 22:55:04 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id E437F41C758; Sun, 27 Apr 2008 22:55:04 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 9645244487F; Sun, 27 Apr 2008 20:54:13 +0000 (UTC) Date: Sun, 27 Apr 2008 20:54:13 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Henri Hennebert In-Reply-To: <48149D87.9070202@restart.be> Message-ID: <20080427205314.K66744@maildrop.int.zabbadoz.net> References: <48149D87.9070202@restart.be> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: 7.0-STABLE - ping6 and tap - kernel crash 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, 27 Apr 2008 20:55:07 -0000 On Sun, 27 Apr 2008, Henri Hennebert wrote: Hi, > I encounter a crash during a ping6 on a tap interface. > > I am running an instance of Freebsd 7.0-RELEASE under qemu. ... > gnat show me nothing relevant - any idea ? I suspect that this is most likely a race due to improper locking. I have seen it before. /bz -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From owner-freebsd-net@FreeBSD.ORG Sun Apr 27 23:22:29 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65F06106564A for ; Sun, 27 Apr 2008 23:22:29 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id D90B78FC0C for ; Sun, 27 Apr 2008 23:22:28 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JqGCK-0006J7-Ux for freebsd-net@freebsd.org; Sun, 27 Apr 2008 23:22:21 +0000 Received: from 78-1-103-226.adsl.net.t-com.hr ([78.1.103.226]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 27 Apr 2008 23:22:20 +0000 Received: from ivoras by 78-1-103-226.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 27 Apr 2008 23:22:20 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Ivan Voras Date: Mon, 28 Apr 2008 01:22:09 +0200 Lines: 83 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3A0D1FB44691DBF17F50A0D9" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 78-1-103-226.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) In-Reply-To: X-Enigmail-Version: 0.95.6 Sender: news Subject: Re: Connecting P1i to FreeBSD 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, 27 Apr 2008 23:22:29 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3A0D1FB44691DBF17F50A0D9 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Sepherosa Ziehau wrote: >> I think you are using iwi to do the tap, could you put iwi into >> monitor mode, since iwi is "smart" device which may filter certain >> type of frames in non-monitor mode? Do you still need these tests since you did your own with the rum=20 device? Apparently my iwi device causes kernel panic when switching=20 modes or some related activity, so it's difficult to work with. >> I tested my rum: the beacon template set in the hardware is trashed i= n >> a strange a pattern > BTW, the pattern is anything beyond 64bytes will be wrapped. See the > dump and the beacon content. Yes, I see what you mean... >> What I got in the air; fc duration and certain part of mac address is= trashed: >> 11:04:57.256700 Assoc Request (sephe-adhoc) [1.0* 2.0* 5.5* 11.0* 6.0= >> >> 9.0 12.0 18.0 Mbit] >> 0x0000: 0000 2a01 0032 0430 4860 6c18 f32f 077a >> 0x0010: 4e9c 3b6a eb9f b01d afbe e402 0000 0000 >> 0x0020: 6400 2200 000b 7365 7068 652d 6164 686f >> 0x0030: 6301 0882 848b 960c 1218 2403 0101 0602 >> 0x0040: 9056 e96b 88d0 f6ef 5cc9 1d >> >> The actual beacon mbuf content: >> 80 00 00 00 ff ff ff ff ff ff 00 18 f3 2f 07 7a >> 4e 9c 3b 6a eb 9f 00 00 00 00 00 00 00 00 00 00 >> 64 00 22 00 00 0b 73 65 70 68 65 2d 61 64 68 6f >> 63 01 08 82 84 8b 96 0c 12 18 24 03 01 01 06 02 >> 00 00 2a 01 00 32 04 30 48 60 6c >> >> After several small code change, I found that beacon template size >> can't exceeds 64bytes. Small template space means you could only use= >> rum IBSS in 11b mode. I have tried to setup BEACON_BASE1 but without= I tried, and I can't run rum in IBSS in 11b (at least the device in=20 question ignores it as always). Can you? >> result. If it is not a hardware design flaw then we will need data >> sheet to make it correct. I don't think it's a hardware fault since it "just works" in Windows=20 without any special configuration. Btw. what hardware revision is your rum device? Mine is C1 (found on the = label before the firmware version). I don't know about data sheets, but the Linux driver (rum-equivalent) is = available from the chips' vendor:=20 http://www.ralinktech.com/ralink/Home/Support/Linux.html It should be the one for RT2500USB. --------------enig3A0D1FB44691DBF17F50A0D9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIFQqhldnAQVacBcgRAqk/AKCGVoeJyqT/ABJ1VaUCiOKQs7hX/ACfXqvT WCk/6QUyq7adV2kR4LVA0Qc= =plcI -----END PGP SIGNATURE----- --------------enig3A0D1FB44691DBF17F50A0D9-- From owner-freebsd-net@FreeBSD.ORG Mon Apr 28 04:27:41 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1BC4E106564A for ; Mon, 28 Apr 2008 04:27:41 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from publicd.ub.mng.net (publicd.ub.mng.net [202.179.0.88]) by mx1.freebsd.org (Postfix) with ESMTP id C29CB8FC0C for ; Mon, 28 Apr 2008 04:27:40 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=daemon.micom.mng.net) by publicd.ub.mng.net with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JqKiw-000PZj-Bz for freebsd-net@freebsd.org; Mon, 28 Apr 2008 12:12:18 +0800 Message-ID: <48154EA2.6070105@micom.mng.net> Date: Mon, 28 Apr 2008 12:12:18 +0800 From: Ganbold User-Agent: Thunderbird 2.0.0.12 (X11/20080304) MIME-Version: 1.0 To: freebsd-net@freebsd.org X-Enigmail-Version: 0.95.6 OpenPGP: id=78F6425E Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: capturing packets on 250mb link 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, 28 Apr 2008 04:27:41 -0000 Hi all, What is the best way to capture packets on 250mb link? What kernel features/modules or tools (less CPU/RAM overhead) should I use? I have FreeBSD 7.0-STABLE machine ( CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2822.51-MHz 686-class CPU), FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs 1GM RAM, ad2: 76319MB at ata1-master SATA150). #uname -an FreeBSD ng1.micom.mng.net 7.0-STABLE FreeBSD 7.0-STABLE #3: Sat Apr 26 14:08:06 ULAT 2008 tsgan@ng1.micom.mng.net:/usr/obj/usr/src/sys/NG i386 #pciconf -lv|more ... bge0@pci0:2:0:0: class=0x020000 card=0x1659103c chip=0x165914e4 rev=0x11 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM5721 NetXtreme Gigabit Ethernet PCI Express' class = network subclass = ethernet ... Are there any considerations on hardware? thanks in advance, Ganbold -- Cats, no less liquid than their shadows, offer no angles to the wind. From owner-freebsd-net@FreeBSD.ORG Mon Apr 28 05:09:19 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06B6D1065673 for ; Mon, 28 Apr 2008 05:09:19 +0000 (UTC) (envelope-from msaf1980@rambler.ru) Received: from mxa.rambler.ru (mxa.rambler.ru [81.19.66.231]) by mx1.freebsd.org (Postfix) with ESMTP id 7A9E28FC1A for ; Mon, 28 Apr 2008 05:09:18 +0000 (UTC) (envelope-from msaf1980@rambler.ru) Received: from mcgi59.rambler.ru (mcgi59.rambler.ru [81.19.67.8]) by mxa.rambler.ru (Postfix) with ESMTP id 9655C73D3D for ; Mon, 28 Apr 2008 08:49:56 +0400 (MSD) Received: from mcgi59.rambler.ru (localhost [127.0.0.1]) by mcgi59.rambler.ru (Postfix) with ESMTP id 60A82B97B for ; Mon, 28 Apr 2008 08:49:55 +0400 (MSD) Received: from [85.115.161.131] by mcgi59.rambler.ru with HTTP (mailimap); Mon, 28 Apr 2008 08:49:51 +0400 From: misha saf To: Kris Kennaway Date: Mon, 28 Apr 2008 08:49:51 +0400 MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="windows-1251"; format="flowed" References: <200804250720.m3P7K3Jk019605@freefall.freebsd.org> <20080426130908.GE47671@hub.freebsd.org> In-Reply-To: <20080426130908.GE47671@hub.freebsd.org> Message-Id: <923282750.1209358191.50616216.62540@mcgi59.rambler.ru> X-Mailer: Ramail 3u, (untone) Cc: freebsd-net@FreeBSD.org Subject: Re: misc/123066: kernel trap with ipsec 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, 28 Apr 2008 05:09:19 -0000 * Kris Kennaway [Sat, 26 Apr 2008 13:09:08 +0000]: > On Fri, Apr 25, 2008 at 07:20:03AM +0000, misha saf wrote: > > The following reply was made to PR kern/123066; it has been noted by > GNATS. > > > > From: misha saf > > To: Kris Kennaway > > Cc: > > Subject: Re: misc/123066: kernel trap with ipsec > > Date: Fri, 25 Apr 2008 10:59:33 +0400 > > > > * Kris Kennaway [Fri, 25 Apr 2008 05:46:54 +0000]: > > > On Fri, Apr 25, 2008 at 04:13:40AM +0000, Mihail wrote: > > > > > > > (kgdb) backtrace > > > > #0 doadump () at pcpu.h:195 > > > > #1 0xc075df57 in boot (howto=260) at > > > /usr/src/sys/kern/kern_shutdown.c:409 > > > > #2 0xc075e219 in panic (fmt=Variable "fmt" is not available. > > > > ) at /usr/src/sys/kern/kern_shutdown.c:563 > > > > #3 0xc0a9766c in trap_fatal (frame=0xc884e934, eva=3621180904) > > > > at /usr/src/sys/i386/i386/trap.c:899 > > > > #4 0xc0a978f0 in trap_pfault (frame=0xc884e934, usermode=0, > > > eva=3621180904) > > > > at /usr/src/sys/i386/i386/trap.c:812 > > > > #5 0xc0a9829c in trap (frame=0xc884e934) at > > > /usr/src/sys/i386/i386/trap.c:490 > > > > #6 0xc0a7e21b in calltrap () at > > > /usr/src/sys/i386/i386/exception.s:139 > > > > #7 0xc0a952f6 in generic_bcopy () at > > > /usr/src/sys/i386/i386/support.s:498 > > > > Previous frame inner to this frame (corrupt stack?) > > > > > > Unfortunately we need the rest of the stack. Can you either try to > > > reproduce with DDB in the kernel and obtain a stack trace from > there, > > > or if this is not possible then try recompiling the kernel with -O > > > instead of -O2 which tends to produce better stack traces. > > > > > > Kris > > > That's all needed info ? > > No, stack frames 8 and beyond contained the important parts of the > stack trace, but were not displayed by gdb. What we need is what I > explained above. > > Kris > > -- > In God we Trust -- all others must submit an X.509 certificate. > -- Charles Forsythe -- db> trace Tracing pid 996 tid 100075 td 0xc1ed2210 generic_bcopy(c1c8b700, c1eeac80,0,14,9,...) at generic_bcopy+0x1a ipsec4_process_packet(c1c8b700, c1eeac80,20,0,c1f00924,...) at ipsec4_process_packet+0x28b ip_ipsec_output(c886db04, c1f00924,c886dae4,c886db0c,...) at ip_ipsec_output+0x1a3 ip_output(c1c8b700,0,c886dac8,20,0,...) at ip_output+0x8ef rip_output(c1c8b700,c1d3c630,1c8a8c0,0,...) at rip_output+0x35e rip_send(c1d3c630,0,c1c8b700,c1bcebd0,0,...) at rip_send+0x5c sosend_generic(c1d3c630,c1bcebd0,c886dbe8,c1c8b700,0,...) at sosend_generic+0x64 sosend(c1d3c630,c1bcebd0,c886dbe8,0,0,...) at sosend+0x3f kern_sendit(c1ed2210,3,c886dc64,0,0,...) at kern_sendit+0x106 sendit(0,8050cec,0,c886dc64,0,0,...) at sendit+0xb1 sendto(c1ed2210,c886dcfc,18,c886dd38,c866dd2c,...) at sendto+0x48 syscall(c886dd38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 ----syscal(133, FreeBSD ELF32, sendto), eip = 0x28156edf, esp = 0xbfbee7ec, ebp = 0xbfbee828 From owner-freebsd-net@FreeBSD.ORG Mon Apr 28 08:16:55 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7425D106566B for ; Mon, 28 Apr 2008 08:16:55 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.243]) by mx1.freebsd.org (Postfix) with ESMTP id 2F0FB8FC1C for ; Mon, 28 Apr 2008 08:16:54 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so1290350anc.13 for ; Mon, 28 Apr 2008 01:16:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=X+ZjakszOaekQjE9IDBeMD+rEJcmrCz4Cr2K6ImS8Ag=; b=CuK5Gz7ZfgYer8tJNWlqR/jt+rdIVCjDTVch2zhpUaNh8laVPUIR1WppfHKwofG6onDU+krHYU4ibDLSTK5NB+r93co/SMx7brgUjeT0sHAnifyQd6eb6NV04STgep+yp7w0qMdmGL7VrvNkxaDdPC14s4dDDACTaVnL9Y84dg0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=AYfM9QnXIRL2z7eORRW1z9kbP2KQeeOlIYMIiFaIf9qZCp1w/jLhoGErnDQm2OH2ITAL1RQOjXQD7WWbeaGkwxp9SIiF83ToAp2/HMRVArAvS+4kr8aWhqr4Sm/oIJKYFjW6HQ6b+aipDYccyGhlzjnx5OjbgapdmKaQnGdWyuM= Received: by 10.100.207.5 with SMTP id e5mr1027117ang.63.1209370614357; Mon, 28 Apr 2008 01:16:54 -0700 (PDT) Received: by 10.100.48.5 with HTTP; Mon, 28 Apr 2008 01:16:54 -0700 (PDT) Message-ID: Date: Mon, 28 Apr 2008 16:16:54 +0800 From: "Sepherosa Ziehau" To: freebsd-net In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Subject: Re: Connecting P1i to FreeBSD 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, 28 Apr 2008 08:16:55 -0000 On Mon, Apr 28, 2008 at 7:22 AM, Ivan Voras wrote: > Sepherosa Ziehau wrote: > > > > > > > I think you are using iwi to do the tap, could you put iwi into > > > monitor mode, since iwi is "smart" device which may filter certain > > > type of frames in non-monitor mode? > > > > > > > Do you still need these tests since you did your own with the rum device? > Apparently my iwi device causes kernel panic when switching modes or some > related activity, so it's difficult to work with. I just wanted to see whether the cause of your problem is the same as mine. Will iwi panic if you set "mediaopt monitor" before bringing it up? > > > > > > > > I tested my rum: the beacon template set in the hardware is trashed in > > > a strange a pattern > > > > > BTW, the pattern is anything beyond 64bytes will be wrapped. See the > > dump and the beacon content. > > > > Yes, I see what you mean... > > > > > ... > > > > > > After several small code change, I found that beacon template size > > > can't exceeds 64bytes. Small template space means you could only use > > > rum IBSS in 11b mode. I have tried to setup BEACON_BASE1 but without > > > > > > > I tried, and I can't run rum in IBSS in 11b (at least the device in > question ignores it as always). Can you? On old system, before you bring rum up: ifconfig rum0 mode 11b It works fine for me; beacon size is less than 64bytes, if I choose short essid (short essid will not make 11g work, since even one char essid would make beacon size go beyond 64bytes) But one thing I noticed, is that once you operate rum as IBSS starter, it always tries to sending beacons even if you set its operation mode back into STA, i.e. IBSS operation mode is "sticky" o_O. I suspect this is a driver bug. > > > > > > > > result. If it is not a hardware design flaw then we will need data > > > sheet to make it correct. > > > > > > > I don't think it's a hardware fault since it "just works" in Windows > without any special configuration. Nah, Windows puts rum into 11b mode and uses short essid when working as IBSS starter (see the tap you posted in the previous email), could you set essid to a 32 char string under Windows instead of "A2"? > > Btw. what hardware revision is your rum device? Mine is C1 (found on the > label before the firmware version). I do not have the hardware at hand now; Will take a look at it when I come back home. > > I don't know about data sheets, but the Linux driver (rum-equivalent) is > available from the chips' vendor: > http://www.ralinktech.com/ralink/Home/Support/Linux.html > It should be the one for RT2500USB. I took a look at it yesterday, when I tried to program BEACON_BASE1 :) I don't think 11g IBSS operation mode will work under Linux. That's why data sheet will be necessary to make it correct. Best Regards, sephe -- Live Free or Die From owner-freebsd-net@FreeBSD.ORG Mon Apr 28 08:25:08 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7875F106566B for ; Mon, 28 Apr 2008 08:25:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 336E08FC1A for ; Mon, 28 Apr 2008 08:25:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 12EC341C734; Mon, 28 Apr 2008 10:25:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id 0v2vYIv7sFjo; Mon, 28 Apr 2008 10:25:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id B17CE41C733; Mon, 28 Apr 2008 10:25:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id D31EC44487F; Mon, 28 Apr 2008 08:22:20 +0000 (UTC) Date: Mon, 28 Apr 2008 08:22:20 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: misha saf In-Reply-To: <923282750.1209358191.50616216.62540@mcgi59.rambler.ru> Message-ID: <20080428082020.C66744@maildrop.int.zabbadoz.net> References: <200804250720.m3P7K3Jk019605@freefall.freebsd.org> <20080426130908.GE47671@hub.freebsd.org> <923282750.1209358191.50616216.62540@mcgi59.rambler.ru> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@FreeBSD.org, Kris Kennaway , bug-followup@FreeBSD.org Subject: Re: misc/123066: kernel trap with ipsec 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, 28 Apr 2008 08:25:08 -0000 On Mon, 28 Apr 2008, misha saf wrote: Hi, > db> trace > Tracing pid 996 tid 100075 td 0xc1ed2210 > generic_bcopy(c1c8b700, c1eeac80,0,14,9,...) at generic_bcopy+0x1a > ipsec4_process_packet(c1c8b700, c1eeac80,20,0,c1f00924,...) at > ipsec4_process_packet+0x28b Could you alos lookup which line of code this is? gdb /path/to/kernel.debug l *ipsec4_process_packet+0x28b > ip_ipsec_output(c886db04, c1f00924,c886dae4,c886db0c,...) at > ip_ipsec_output+0x1a3 > ip_output(c1c8b700,0,c886dac8,20,0,...) at ip_output+0x8ef > rip_output(c1c8b700,c1d3c630,1c8a8c0,0,...) at rip_output+0x35e > rip_send(c1d3c630,0,c1c8b700,c1bcebd0,0,...) at rip_send+0x5c > sosend_generic(c1d3c630,c1bcebd0,c886dbe8,c1c8b700,0,...) at > sosend_generic+0x64 > sosend(c1d3c630,c1bcebd0,c886dbe8,0,0,...) at sosend+0x3f > kern_sendit(c1ed2210,3,c886dc64,0,0,...) at kern_sendit+0x106 > sendit(0,8050cec,0,c886dc64,0,0,...) at sendit+0xb1 > sendto(c1ed2210,c886dcfc,18,c886dd38,c866dd2c,...) at sendto+0x48 > syscall(c886dd38) at syscall+0x335 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > ----syscal(133, FreeBSD ELF32, sendto), eip = 0x28156edf, esp = 0xbfbee7ec, > ebp = 0xbfbee828 > _______________________________________________ > 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" > -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From owner-freebsd-net@FreeBSD.ORG Mon Apr 28 08:30:25 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5132106566B for ; Mon, 28 Apr 2008 08:30:25 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by mx1.freebsd.org (Postfix) with ESMTP id 84C468FC1D for ; Mon, 28 Apr 2008 08:30:25 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: by fg-out-1718.google.com with SMTP id 16so5656892fgg.35 for ; Mon, 28 Apr 2008 01:30:24 -0700 (PDT) Received: by 10.82.176.11 with SMTP id y11mr3404679bue.53.1209369702767; Mon, 28 Apr 2008 01:01:42 -0700 (PDT) Received: by 10.82.185.8 with HTTP; Mon, 28 Apr 2008 01:01:42 -0700 (PDT) Message-ID: Date: Mon, 28 Apr 2008 11:01:42 +0300 From: "Vlad GALU" To: Ganbold In-Reply-To: <48154EA2.6070105@micom.mng.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48154EA2.6070105@micom.mng.net> Cc: freebsd-net@freebsd.org Subject: Re: capturing packets on 250mb link 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, 28 Apr 2008 08:30:26 -0000 On 4/28/08, Ganbold wrote: > Hi all, > > What is the best way to capture packets on 250mb link? > What kernel features/modules or tools (less CPU/RAM overhead) should I use? Given your OS version, I'd say that setting the BPF buffer size to around 1MB and setting the monitor flag on the capture interface would give you very good results. In that combination we've been doing packtet capture at gigabit speeds without packet loss. > > I have FreeBSD 7.0-STABLE machine ( > CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2822.51-MHz 686-class CPU), > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > 1GM RAM, ad2: 76319MB at ata1-master SATA150). > > #uname -an > FreeBSD ng1.micom.mng.net 7.0-STABLE FreeBSD 7.0-STABLE #3: Sat Apr 26 > 14:08:06 ULAT 2008 tsgan@ng1.micom.mng.net:/usr/obj/usr/src/sys/NG i386 > > #pciconf -lv|more > ... > bge0@pci0:2:0:0: class=0x020000 card=0x1659103c chip=0x165914e4 > rev=0x11 hdr=0x00 > vendor = 'Broadcom Corporation' > device = 'BCM5721 NetXtreme Gigabit Ethernet PCI Express' > class = network > subclass = ethernet > ... > > Are there any considerations on hardware? > > thanks in advance, > > Ganbold > > -- > Cats, no less liquid than their shadows, offer no angles to the wind. > > _______________________________________________ > 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" > -- ~/.signature: no such file or directory From owner-freebsd-net@FreeBSD.ORG Mon Apr 28 08:50:03 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD0B710656C4 for ; Mon, 28 Apr 2008 08:50:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C59638FC21 for ; Mon, 28 Apr 2008 08:50:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m3S8o3hr041473 for ; Mon, 28 Apr 2008 08:50:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m3S8o3V6041472; Mon, 28 Apr 2008 08:50:03 GMT (envelope-from gnats) Date: Mon, 28 Apr 2008 08:50:03 GMT Message-Id: <200804280850.m3S8o3V6041472@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: "Bjoern A. Zeeb" Cc: Subject: Re: misc/123066: kernel trap with ipsec X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Bjoern A. Zeeb" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2008 08:50:04 -0000 The following reply was made to PR kern/123066; it has been noted by GNATS. From: "Bjoern A. Zeeb" To: misha saf Cc: Kris Kennaway , freebsd-net@FreeBSD.org, bug-followup@FreeBSD.org Subject: Re: misc/123066: kernel trap with ipsec Date: Mon, 28 Apr 2008 08:22:20 +0000 (UTC) On Mon, 28 Apr 2008, misha saf wrote: Hi, > db> trace > Tracing pid 996 tid 100075 td 0xc1ed2210 > generic_bcopy(c1c8b700, c1eeac80,0,14,9,...) at generic_bcopy+0x1a > ipsec4_process_packet(c1c8b700, c1eeac80,20,0,c1f00924,...) at > ipsec4_process_packet+0x28b Could you alos lookup which line of code this is? gdb /path/to/kernel.debug l *ipsec4_process_packet+0x28b > ip_ipsec_output(c886db04, c1f00924,c886dae4,c886db0c,...) at > ip_ipsec_output+0x1a3 > ip_output(c1c8b700,0,c886dac8,20,0,...) at ip_output+0x8ef > rip_output(c1c8b700,c1d3c630,1c8a8c0,0,...) at rip_output+0x35e > rip_send(c1d3c630,0,c1c8b700,c1bcebd0,0,...) at rip_send+0x5c > sosend_generic(c1d3c630,c1bcebd0,c886dbe8,c1c8b700,0,...) at > sosend_generic+0x64 > sosend(c1d3c630,c1bcebd0,c886dbe8,0,0,...) at sosend+0x3f > kern_sendit(c1ed2210,3,c886dc64,0,0,...) at kern_sendit+0x106 > sendit(0,8050cec,0,c886dc64,0,0,...) at sendit+0xb1 > sendto(c1ed2210,c886dcfc,18,c886dd38,c866dd2c,...) at sendto+0x48 > syscall(c886dd38) at syscall+0x335 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > ----syscal(133, FreeBSD ELF32, sendto), eip = 0x28156edf, esp = 0xbfbee7ec, > ebp = 0xbfbee828 > _______________________________________________ > 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" > -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From owner-freebsd-net@FreeBSD.ORG Mon Apr 28 08:58:06 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B6A5106566B for ; Mon, 28 Apr 2008 08:58:06 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from publicd.ub.mng.net (publicd.ub.mng.net [202.179.0.88]) by mx1.freebsd.org (Postfix) with ESMTP id E7F838FC0A for ; Mon, 28 Apr 2008 08:58:05 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=daemon.micom.mng.net) by publicd.ub.mng.net with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JqPBS-0001u6-T7; Mon, 28 Apr 2008 16:58:02 +0800 Message-ID: <4815919A.5070607@micom.mng.net> Date: Mon, 28 Apr 2008 16:58:02 +0800 From: Ganbold User-Agent: Thunderbird 2.0.0.12 (X11/20080304) MIME-Version: 1.0 To: Vlad GALU References: <48154EA2.6070105@micom.mng.net> In-Reply-To: X-Enigmail-Version: 0.95.6 OpenPGP: id=78F6425E Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: capturing packets on 250mb link 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, 28 Apr 2008 08:58:06 -0000 Vlad, Vlad GALU wrote: > On 4/28/08, Ganbold wrote: > >> Hi all, >> >> What is the best way to capture packets on 250mb link? >> What kernel features/modules or tools (less CPU/RAM overhead) should I use? >> > > Given your OS version, I'd say that setting the BPF buffer size to > around 1MB and setting the monitor flag on the capture interface would > give you very good results. In that combination we've been doing > packtet capture at gigabit speeds without packet loss. > Thanks Vlad. So then it means something like following will work in our case: #sysctl net.bpf.bufsize: 1048576 #ifconfig bge1 monitor up #tcpdump -i bge1 -s0 -w capture.log -C 2048 -W 100 Correct me if I'm wrong here. thanks, Ganbold > >> I have FreeBSD 7.0-STABLE machine ( >> CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2822.51-MHz 686-class CPU), >> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs >> 1GM RAM, ad2: 76319MB at ata1-master SATA150). >> >> #uname -an >> FreeBSD ng1.micom.mng.net 7.0-STABLE FreeBSD 7.0-STABLE #3: Sat Apr 26 >> 14:08:06 ULAT 2008 tsgan@ng1.micom.mng.net:/usr/obj/usr/src/sys/NG i386 >> >> #pciconf -lv|more >> ... >> bge0@pci0:2:0:0: class=0x020000 card=0x1659103c chip=0x165914e4 >> rev=0x11 hdr=0x00 >> vendor = 'Broadcom Corporation' >> device = 'BCM5721 NetXtreme Gigabit Ethernet PCI Express' >> class = network >> subclass = ethernet >> ... >> >> Are there any considerations on hardware? >> >> thanks in advance, >> >> Ganbold >> >> -- >> Cats, no less liquid than their shadows, offer no angles to the wind. >> >> _______________________________________________ >> 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" >> >> > > > -- Look out! Behind you! From owner-freebsd-net@FreeBSD.ORG Mon Apr 28 09:02:58 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3B841065672 for ; Mon, 28 Apr 2008 09:02:58 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.188]) by mx1.freebsd.org (Postfix) with ESMTP id 47DF48FC17 for ; Mon, 28 Apr 2008 09:02:58 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: by fk-out-0910.google.com with SMTP id b27so7106210fka.11 for ; Mon, 28 Apr 2008 02:02:57 -0700 (PDT) Received: by 10.82.145.7 with SMTP id s7mr3453677bud.81.1209373376095; Mon, 28 Apr 2008 02:02:56 -0700 (PDT) Received: by 10.82.185.8 with HTTP; Mon, 28 Apr 2008 02:02:56 -0700 (PDT) Message-ID: Date: Mon, 28 Apr 2008 12:02:56 +0300 From: "Vlad GALU" To: Ganbold In-Reply-To: <4815919A.5070607@micom.mng.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48154EA2.6070105@micom.mng.net> <4815919A.5070607@micom.mng.net> Cc: freebsd-net@freebsd.org Subject: Re: capturing packets on 250mb link 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, 28 Apr 2008 09:02:58 -0000 On 4/28/08, Ganbold wrote: > Vlad, > > > Vlad GALU wrote: > > > On 4/28/08, Ganbold wrote: > > > > > > > Hi all, > > > > > > What is the best way to capture packets on 250mb link? > > > What kernel features/modules or tools (less CPU/RAM overhead) should I > use? > > > > > > > > > > Given your OS version, I'd say that setting the BPF buffer size to > > around 1MB and setting the monitor flag on the capture interface would > > give you very good results. In that combination we've been doing > > packtet capture at gigabit speeds without packet loss. > > > > > > Thanks Vlad. So then it means something like following will work in our > case: > > #sysctl net.bpf.bufsize: 1048576 > #ifconfig bge1 monitor up > #tcpdump -i bge1 -s0 -w capture.log -C 2048 -W 100 > > Correct me if I'm wrong here. Yes, it should do the job. However I can't understand why you want a snaplen of 0, as 68 should be the minimum to accomodate the ethernet+ip+tcp/udp headers. > > thanks, > > Ganbold > > > > > > > > > > I have FreeBSD 7.0-STABLE machine ( > > > CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2822.51-MHz 686-class CPU), > > > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > > > 1GM RAM, ad2: 76319MB at ata1-master > SATA150). > > > > > > #uname -an > > > FreeBSD ng1.micom.mng.net 7.0-STABLE FreeBSD 7.0-STABLE #3: Sat Apr 26 > > > 14:08:06 ULAT 2008 tsgan@ng1.micom.mng.net:/usr/obj/usr/src/sys/NG > i386 > > > > > > #pciconf -lv|more > > > ... > > > bge0@pci0:2:0:0: class=0x020000 card=0x1659103c chip=0x165914e4 > > > rev=0x11 hdr=0x00 > > > vendor = 'Broadcom Corporation' > > > device = 'BCM5721 NetXtreme Gigabit Ethernet PCI Express' > > > class = network > > > subclass = ethernet > > > ... > > > > > > Are there any considerations on hardware? > > > > > > thanks in advance, > > > > > > Ganbold > > > > > > -- > > > Cats, no less liquid than their shadows, offer no angles to the wind. > > > > > > _______________________________________________ > > > 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" > > > > > > > > > > > > > > > > > > > > -- > Look out! Behind you! > -- ~/.signature: no such file or directory From owner-freebsd-net@FreeBSD.ORG Mon Apr 28 09:05:47 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 210541065686 for ; Mon, 28 Apr 2008 09:05:47 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by mx1.freebsd.org (Postfix) with ESMTP id B83198FC25 for ; Mon, 28 Apr 2008 09:05:46 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: by fg-out-1718.google.com with SMTP id 16so5671717fgg.35 for ; Mon, 28 Apr 2008 02:05:45 -0700 (PDT) Received: by 10.82.107.3 with SMTP id f3mr3447878buc.87.1209373545338; Mon, 28 Apr 2008 02:05:45 -0700 (PDT) Received: by 10.82.185.8 with HTTP; Mon, 28 Apr 2008 02:05:45 -0700 (PDT) Message-ID: Date: Mon, 28 Apr 2008 12:05:45 +0300 From: "Vlad GALU" To: Ganbold In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48154EA2.6070105@micom.mng.net> <4815919A.5070607@micom.mng.net> Cc: freebsd-net@freebsd.org Subject: Re: capturing packets on 250mb link 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, 28 Apr 2008 09:05:47 -0000 On 4/28/08, Vlad GALU wrote: > On 4/28/08, Ganbold wrote: > > Vlad, > > > > > > Vlad GALU wrote: > > > > > On 4/28/08, Ganbold wrote: > > > > > > > > > > Hi all, > > > > > > > > What is the best way to capture packets on 250mb link? > > > > What kernel features/modules or tools (less CPU/RAM overhead) should I > > use? > > > > > > > > > > > > > > Given your OS version, I'd say that setting the BPF buffer size to > > > around 1MB and setting the monitor flag on the capture interface would > > > give you very good results. In that combination we've been doing > > > packtet capture at gigabit speeds without packet loss. > > > > > > > > > > Thanks Vlad. So then it means something like following will work in our > > case: > > > > #sysctl net.bpf.bufsize: 1048576 > > #ifconfig bge1 monitor up > > #tcpdump -i bge1 -s0 -w capture.log -C 2048 -W 100 > > > > Correct me if I'm wrong here. > > > > Yes, it should do the job. However I can't understand why you want > a snaplen of 0, as 68 should be the minimum to accomodate the > ethernet+ip+tcp/udp headers. > Ah, I should have RTFM before. -- cut here -- Setting snaplen to 0 means use the required length to catch whole packets. -- and here -- > > > > > thanks, > > > > Ganbold > > > > > > > > > > > > > > > > I have FreeBSD 7.0-STABLE machine ( > > > > CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2822.51-MHz 686-class CPU), > > > > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > > > > 1GM RAM, ad2: 76319MB at ata1-master > > SATA150). > > > > > > > > #uname -an > > > > FreeBSD ng1.micom.mng.net 7.0-STABLE FreeBSD 7.0-STABLE #3: Sat Apr 26 > > > > 14:08:06 ULAT 2008 tsgan@ng1.micom.mng.net:/usr/obj/usr/src/sys/NG > > i386 > > > > > > > > #pciconf -lv|more > > > > ... > > > > bge0@pci0:2:0:0: class=0x020000 card=0x1659103c chip=0x165914e4 > > > > rev=0x11 hdr=0x00 > > > > vendor = 'Broadcom Corporation' > > > > device = 'BCM5721 NetXtreme Gigabit Ethernet PCI Express' > > > > class = network > > > > subclass = ethernet > > > > ... > > > > > > > > Are there any considerations on hardware? > > > > > > > > thanks in advance, > > > > > > > > Ganbold > > > > > > > > -- > > > > Cats, no less liquid than their shadows, offer no angles to the wind. > > > > > > > > _______________________________________________ > > > > 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" > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Look out! Behind you! > > > > > > -- > ~/.signature: no such file or directory > -- ~/.signature: no such file or directory From owner-freebsd-net@FreeBSD.ORG Mon Apr 28 09:13:22 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CDA3C1065673 for ; Mon, 28 Apr 2008 09:13:22 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from publicd.ub.mng.net (publicd.ub.mng.net [202.179.0.88]) by mx1.freebsd.org (Postfix) with ESMTP id 84DEA8FC12 for ; Mon, 28 Apr 2008 09:13:22 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=daemon.micom.mng.net) by publicd.ub.mng.net with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JqPQG-00020k-Gb; Mon, 28 Apr 2008 17:13:20 +0800 Message-ID: <48159530.4080908@micom.mng.net> Date: Mon, 28 Apr 2008 17:13:20 +0800 From: Ganbold User-Agent: Thunderbird 2.0.0.12 (X11/20080304) MIME-Version: 1.0 To: Vlad GALU References: <48154EA2.6070105@micom.mng.net> <4815919A.5070607@micom.mng.net> In-Reply-To: X-Enigmail-Version: 0.95.6 OpenPGP: id=78F6425E Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: capturing packets on 250mb link 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, 28 Apr 2008 09:13:23 -0000 Vlad GALU wrote: > On 4/28/08, Ganbold wrote: > >> Vlad, >> >> >> Vlad GALU wrote: >> >> >>> On 4/28/08, Ganbold wrote: >>> >>> >>> >>>> Hi all, >>>> >>>> What is the best way to capture packets on 250mb link? >>>> What kernel features/modules or tools (less CPU/RAM overhead) should I >>>> >> use? >> >>>> >>> Given your OS version, I'd say that setting the BPF buffer size to >>> around 1MB and setting the monitor flag on the capture interface would >>> give you very good results. In that combination we've been doing >>> packtet capture at gigabit speeds without packet loss. >>> >>> >>> >> Thanks Vlad. So then it means something like following will work in our >> case: >> >> #sysctl net.bpf.bufsize: 1048576 >> #ifconfig bge1 monitor up >> #tcpdump -i bge1 -s0 -w capture.log -C 2048 -W 100 >> >> Correct me if I'm wrong here. >> > > > Yes, it should do the job. However I can't understand why you want > a snaplen of 0, as 68 should be the minimum to accomodate the > ethernet+ip+tcp/udp headers. > Thanks Vlad. According to tcpdump(1): -s Snarf snaplen bytes of data from each packet rather than the default of 68 (with SunOS's NIT, the minimum is actually 96). 68 bytes is adequate for IP, ICMP, TCP and UDP but may truncate protocol information from name server and NFS packets (see below). Packets truncated because of a limited snapshot are indicated in the output with ``[|proto]'', where proto is the name of the protocol level at which the truncation has occurred. Note that taking larger snapshots both increases the amount of time it takes to process packets and, effectively, decreases the amount of packet buffering. This may cause packets to be lost. You should limit snaplen to the smallest number that will cap- ture the protocol information you're interested in. Setting snaplen to 0 means use the required length to catch whole pack- ets. Ganbold > >> thanks, >> >> Ganbold >> >> >> >> >>> >>>> I have FreeBSD 7.0-STABLE machine ( >>>> CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2822.51-MHz 686-class CPU), >>>> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs >>>> 1GM RAM, ad2: 76319MB at ata1-master >>>> >> SATA150). >> >>>> #uname -an >>>> FreeBSD ng1.micom.mng.net 7.0-STABLE FreeBSD 7.0-STABLE #3: Sat Apr 26 >>>> 14:08:06 ULAT 2008 tsgan@ng1.micom.mng.net:/usr/obj/usr/src/sys/NG >>>> >> i386 >> >>>> #pciconf -lv|more >>>> ... >>>> bge0@pci0:2:0:0: class=0x020000 card=0x1659103c chip=0x165914e4 >>>> rev=0x11 hdr=0x00 >>>> vendor = 'Broadcom Corporation' >>>> device = 'BCM5721 NetXtreme Gigabit Ethernet PCI Express' >>>> class = network >>>> subclass = ethernet >>>> ... >>>> >>>> Are there any considerations on hardware? >>>> >>>> thanks in advance, >>>> >>>> Ganbold >>>> >>>> -- >>>> Cats, no less liquid than their shadows, offer no angles to the wind. >>>> >>>> _______________________________________________ >>>> 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" >>>> >>>> >>>> >>>> >>> >>> >>> >> -- >> Look out! Behind you! >> >> > > > -- Slowly and surely the Unix crept up on the Nintendo user ... From owner-freebsd-net@FreeBSD.ORG Mon Apr 28 09:19:18 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2A77106567B for ; Mon, 28 Apr 2008 09:19:18 +0000 (UTC) (envelope-from dewayne_freebsd@yahoo.com) Received: from n78.bullet.mail.sp1.yahoo.com (n78.bullet.mail.sp1.yahoo.com [98.136.44.42]) by mx1.freebsd.org (Postfix) with SMTP id BA39C8FC16 for ; Mon, 28 Apr 2008 09:19:18 +0000 (UTC) (envelope-from dewayne_freebsd@yahoo.com) Received: from [216.252.122.218] by n78.bullet.mail.sp1.yahoo.com with NNFMP; 28 Apr 2008 09:19:18 -0000 Received: from [69.147.65.162] by t3.bullet.sp1.yahoo.com with NNFMP; 28 Apr 2008 09:19:18 -0000 Received: from [127.0.0.1] by omp407.mail.sp1.yahoo.com with NNFMP; 28 Apr 2008 09:19:18 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 221136.90366.bm@omp407.mail.sp1.yahoo.com Received: (qmail 94604 invoked by uid 60001); 28 Apr 2008 09:19:18 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=YQBwfERtLCW1SLlTeBDbZmBTt/1Y2B/0sBDLOok/21cAIi8k9z/5X5WXYSVMOr5kqRircEL8cALSBLrV7ttvQkXiKOaNvEQAOn2/owSbIPTDpzmBIG/BiTSEDJtHfsJBtRkKrjihHi8nZxyiCdDHnm1dhOVpoiCR3hhF9DwqtAY=; X-YMail-OSG: 71TTtEkVM1mzW9L4f_1ZFzr.EPOpozYwVnOuZxdFKV7Eaol.pT2c_3HhDKkA1uPtaQ_L.5S6I_UB6UaQHCWKTtr5FHlSWA6xsw-- Received: from [58.172.113.127] by web46006.mail.sp1.yahoo.com via HTTP; Mon, 28 Apr 2008 02:19:17 PDT Date: Mon, 28 Apr 2008 02:19:17 -0700 (PDT) From: Dewayne Geraghty To: freebsd-net@FreeBSD.org MIME-Version: 1.0 Message-ID: <995276.92553.qm@web46006.mail.sp1.yahoo.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: if_vge.c TX checksum errors on 6.3R-p2 7.0R-p1 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, 28 Apr 2008 09:19:18 -0000 Hi, I have four VIA motherboards each containing a vge0 device, three are misbehaving. On both the 7.0R-p1 and the 6.3Rp2 motherboards, the network cable needs to be unplugged and replugged into the motherboard, before ping will respond in either direction. The driver is issueing "incorrect" checksums during transmissions from the vge device, as observed from tcpdump -vvv. On 6.1R-p20 if_vge.c revision 1.14.2.7 is ok On 6.3-p1 if_vge.c revision is 1.14.2.13 On 7.0Rp1 if_vge.c revision is 1.31. I'd like to know if other's have experiencing similar problems and which version of if_vge they had to go to as a quick workaround, unfortunately I can't revert to 6.1 as we really need 7.0R for the fantastic auditing and MAC enhancements. I'm happy to provide as much detail as needed to correct the problem - including ssh access to a crash burn machine (of course via an rl0 or vr0 NIC). The motherboard running 6.3R-p1 uses the VT6122 chip on a VT8237R Southbridge. (6.1R-p20 that works correctly uses this motherboard) The motherboard running 7.0R-p1 is a VT6130 chipset on a VT8251 Southbridge. Regards, Dewayne. --------------------------------- Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. From owner-freebsd-net@FreeBSD.ORG Mon Apr 28 11:07:06 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EADCF106568F for ; Mon, 28 Apr 2008 11:07:06 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D6F5D8FC1E for ; Mon, 28 Apr 2008 11:07:06 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m3SB76Gf056204 for ; Mon, 28 Apr 2008 11:07:06 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m3SB76R1056200 for freebsd-net@FreeBSD.org; Mon, 28 Apr 2008 11:07:06 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 28 Apr 2008 11:07:06 GMT Message-Id: <200804281107.m3SB76R1056200@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2008 11:07:07 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri a kern/38554 net changing interface ipaddress doesn't seem to work s kern/39937 net ipstealth issue s kern/81147 net [net] [patch] em0 reinitialization while adding aliase s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument (regress o kern/92090 net [bge] bge0: watchdog timeout -- resetting f kern/92552 net A serious bug in most network drivers from 5.X to 6.X o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr s kern/105943 net Network stack may modify read-only mbuf chain copies o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112722 net [udp] IP v4 udp fragmented packet reject o kern/113842 net [ipv6] PF_INET6 proto domain state can't be cleared wi o kern/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/116077 net [ip] [patch] 6.2-STABLE panic during use of multi-cast f kern/116172 net [tun] [panic] Network / ipv6 recursive mutex panic o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/116328 net [bge]: Solid hang with bge interface o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117423 net [vlan] Duplicate IP on different interfaces o kern/117448 net [carp] 6.2 kernel crash (regression) o kern/118880 net [ipv6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card (regr o kern/119345 net [ath] Unsuported Atheros 5424/2424 and CPU speedstep n o kern/119361 net [bge] bge(4) transmit performance problem o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o kern/120266 net [panic] gnugk causes kernel panic when closing UDP soc o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time f kern/120725 net [bce] On board second lan port 'bce1' with Broadcom Ne f kern/120966 net [rum]: kernel panic with if_rum and WPA encryption o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o kern/121555 net Fatal trap 12: current process = 12 (swi1: net) o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 o kern/121983 net [fxp] fxp0 MBUF and PAE o kern/122033 net [ral] Lock order reversal in ral0 at bootup (regressio o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122082 net [in_pcb] NULL pointer dereference in in_pcbdrop o kern/122195 net [ed] Alignment problems in if_ed f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122427 net [apm] [panic] apm and mDNSResponder cause panic during o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122743 net [panic] vm_page_unwire: invalid wire count: 0 o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix f kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar o kern/122875 net [nfs] "rstatd: Can't get namelist. 1" - fbsd 7.0-stabl o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/123066 net [ipsec] [panic] kernel trap with ipsec 59 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- 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/64556 net [sis] if_sis short cable fix problems with NetGear FA3 o kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o bin/79228 net [patch] extend /sbin/arp to be able to create blackhol o kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/95267 net packet drops periodically appear o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/100519 net [netisr] suggestion to fix suboptimal network polling 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 conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/112179 net [sis] [patch] sis driver for natsemi DP83815D autonego o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o bin/117339 net [patch] route(8): loading routing management commands o kern/118727 net [netgraph] [patch] [request] add new ng_pf module a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118975 net [bge] [patch] Broadcom 5906 not handled by FreeBSD o bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o kern/119432 net [arp] route add -host -iface causes arp e o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/121242 net [ate] [patch] Promiscuous mode of if_ate (arm) doesn't o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121443 net [gif] LOR icmp6_input/nd6_lookup o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122068 net [ppp] ppp can not set the correct interface with pptpd o kern/122145 net error while compiling with device ath_rate_amrr o kern/122295 net [bge] bge Ierr rate increase (since 6.0R) (regression) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122697 net [ath] Atheros card is not well supported o amd64/122780 net [lagg] tcpdump on lagg interface during high pps wedge f kern/122839 net [multicast] FreeBSD 7 multicast routing problem f kern/122928 net [em] interface watchdog timeouts and stops receiving p o kern/123053 net [re] re(4) unsupported hardware revision o kern/123138 net [bpf] [patch] bpf incorrectly determines outgoing rout o kern/123147 net [ti] [patch] ti(4) doesn't use mii, but kernel configs 45 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Apr 28 11:30:16 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11C01106566B; Mon, 28 Apr 2008 11:30:16 +0000 (UTC) (envelope-from msaf1980@rambler.ru) Received: from mcgi75.rambler.ru (mcgi75.rambler.ru [81.19.67.218]) by mx1.freebsd.org (Postfix) with ESMTP id EF6978FC24; Mon, 28 Apr 2008 11:30:14 +0000 (UTC) (envelope-from msaf1980@rambler.ru) Received: from [85.115.161.131] by mcgi75.rambler.ru with HTTP (mailimap); Mon, 28 Apr 2008 15:30:12 +0400 From: misha saf To: "Bjoern A. Zeeb" Date: Mon, 28 Apr 2008 15:30:12 +0400 MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="windows-1251"; format="flowed" References: <200804250720.m3P7K3Jk019605@freefall.freebsd.org> <20080426130908.GE47671@hub.freebsd.org> <923282750.1209358191.50616216.62540@mcgi59.rambler.ru> <20080428082020.C66744@maildrop.int.zabbadoz.net> In-Reply-To: <20080428082020.C66744@maildrop.int.zabbadoz.net> Message-Id: <747012630.1209382212.63629384.16040@mcgi75.rambler.ru> X-Mailer: Ramail 3u, (untone) Cc: freebsd-net@FreeBSD.org, Kris Kennaway , bug-followup@FreeBSD.org Subject: Re: misc/123066: kernel trap with ipsec 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, 28 Apr 2008 11:30:16 -0000 * "Bjoern A. Zeeb" [Mon, 28 Apr 2008 08:22:20 +0000 (UTC)]: > On Mon, 28 Apr 2008, misha saf wrote: > > Hi, > > > db> trace > > Tracing pid 996 tid 100075 td 0xc1ed2210 > > generic_bcopy(c1c8b700, c1eeac80,0,14,9,...) at generic_bcopy+0x1a > > ipsec4_process_packet(c1c8b700, c1eeac80,20,0,c1f00924,...) at > > ipsec4_process_packet+0x28b > > > Could you alos lookup which line of code this is? > > gdb /path/to/kernel.debug > l *ipsec4_process_packet+0x28b > > -- > Bjoern A. Zeeb Stop bit received. Insert coin for new game. (gdb) l *ipsec4_process_packet+0x28b 0xc08fecab is in ipsec4_process_packet (/usr/src/sys/netipsec/ipsec_output.c:486). 481 */ 482 if (sav->tdb_xform->xf_type != XF_IP4) { 483 ip = mtod(m, struct ip *); 484 i = ip->ip_hl << 2; 485 off = offsetof(struct ip, ip_p); 486 error = (*sav->tdb_xform->xf_output)(m, isr, NULL, i, off); 487 } else { 488 error = ipsec_process_done(m, isr); 489 } 490 IPSECREQUEST_UNLOCK(isr); From owner-freebsd-net@FreeBSD.ORG Mon Apr 28 11:30:31 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52DF4106564A for ; Mon, 28 Apr 2008 11:30:31 +0000 (UTC) (envelope-from mobilepolice@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by mx1.freebsd.org (Postfix) with ESMTP id E8E5D8FC1B for ; Mon, 28 Apr 2008 11:30:30 +0000 (UTC) (envelope-from mobilepolice@gmail.com) Received: by yw-out-2324.google.com with SMTP id 5so845419ywh.13 for ; Mon, 28 Apr 2008 04:30:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type; bh=dgtBvvdnmp11m5SJiXl8FGUKbTg5v8+QRmazH2pVkhg=; b=D/v+YlipBrxOuTLkymSzeOJTzo2Kh2uKG22aPuI/zaBSjZXdi3E8AuIDAMNZO4tK/SNp+Qmp7RT5tmUab/3remDUNICaGBeWY+FRVNrqi9xWuCfzAMaiKNT1yaPl0jb+EwFQpwfuGy6ky+x3h6cz2uH19KKQYzL2sdqucSRPiN0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:mime-version:content-type; b=jrrJaPk28Qhxm03MoSzwsOsUzH5TIE+khO+kXmB6uMjffLE/uCnf1fJO3UwPr0LOlp7BWYHwPZBl3UwgWlisdNCdWaPQOvxeuxTvuPcOq8j5W1Yt+fJfgXL05OBoYxdcu8PnyKfZFI2KpSrZIcjOw7jC9EdoSsS2E6QFOU+27jY= Received: by 10.150.57.1 with SMTP id f1mr3534542yba.77.1209380486464; Mon, 28 Apr 2008 04:01:26 -0700 (PDT) Received: by 10.151.82.18 with HTTP; Mon, 28 Apr 2008 04:01:26 -0700 (PDT) Message-ID: Date: Mon, 28 Apr 2008 06:01:26 -0500 From: "David Todd" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_4439_20253452.1209380486436" Cc: seki@fexx.org Subject: custom modifications to libalias for detailed translation information (patch included) 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, 28 Apr 2008 11:30:31 -0000 ------=_Part_4439_20253452.1209380486436 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Gentlemen, I've expanded upon the work of Masahiro Sekiguchi 's patch for libalias located at: http://www.fexx.org/ybb/alias_db.c.diff.txt This alias_db.c diff modified libalias in a way to replace the original /var/log/alias.log file with one that reported running statistics in a format like such: + udp 219.63.255.49:1024 211.5.1.219:53 219.63.255.49:1024 *:* (0x8060100) + udp 219.63.255.49:1024 165.76.0.98:53 219.63.255.49:1024 *:* (0x8060180) + udp 219.63.255.49:1024 165.76.4.2:53 219.63.255.49:1024 *:* (0x8060200) + udp 219.63.255.49:1024 211.5.1.217:53 219.63.255.49:1024 *:* (0x8060280) + tcp 192.168.1.188:1346 210.142.46.154:80 219.63.255.49:1346 *:* (0x8060300) + udp 219.63.255.49:1024 210.141.108.194:53 219.63.255.49:1024 *:* (0x8060400) + udp 219.63.255.49:1024 210.239.166.194:53 219.63.255.49:1024 *:* (0x8060480) Obviously this patch was built for a much older version of libalias; circa 2003. I recently attempted to convert his work, modify it (relatively heavily) for my own uses and what I think makes a bit better sense; after a few weeks of testing and repeated modifications I'm ready to give it to whomever thinks they could make use of it. The highlights of my changes: * alias.log becomes 'alias' under /var/log; it is no longer a massive running list of connection #'s per protocol, but a one-line file updated every 20 seconds showing current protocol #'s. * alias.details is a new log under /var/log which provides interesting information on all of the active translated connections in a format that looks like this: total: 485 time: 1209374774 last_chg exp_t T- protocol source addr:port dest addr:port alias addr:port proxy addr:port 1209374770 00060 -00056 udp 192.0.21.10:8080 78.109.177.139:61878 *:8080 *:* 1209374733 00010 00000 tcp DIS:DIS 192.0.21.10:3276 209.85.133.18:80 68.52.101.103:3276 *:* 1209374635 00060 00000 icmp 68.52.101.103:1 67.15.240.42:256 68.52.101.103:1 *:* 1209374566 00300 -00092 tcp EST:DWN 68.52.101.103:11225 69.60.111.193:39357 68.52.101.103:11225 *:* 1209374747 00010 00000 tcp DIS:DIS 192.0.21.10:3261 209.85.133.19:80 68.52.101.103:3261 *:* 1209374078 00300 00000 tcp PERMLNK 192.0.21.10:5580 *:* *:5580 *:* (if your email client supports tabbed text properly the format of the log looks much cleaner) * modified TCP_EXPIRE_CONNECTED from 24 hours to 1 hour (did this for debugging purposes, it can be set to whatever standard there is) I ran into this bug: BUG: when a TCP connection is dropped locally (behind the nat) or remotely, sometimes libalias/natd does not mark the translated TCP connection as down/disconnected/dead. The connection will remain in the translation tables until libalias/natd is reloaded. This could be just a problem with natd but I do not have the proper tools or environment to figure out exactly where the problem is coming from, leading to this: * modification: when idelta > lnk->expire_time and LINK_TCP in IncrementalCleanup(), SetStateIn/Out ALIAS_TCP_NOT_CONNECTED, reset lnk->timestamp to current la->timeStamp and set lnk->expire_time to TCP_EXPIRE_SINGLEDEAD; on the pass after next of the IncrementalCleanup() function we'll come across the same translation entry, if it hasn't changed we'll expire it. The issue here is that after a period of time I had 1500+ TCP connections in my translation tables all showing a "time to expire" of 0 seconds (out of 86400); and no activity on the network to warrant such connections. In normal TCP connections when a packet is processed for a translation entry lnk->timestamp is updated, so idelta will never exceed lnk->expire_time as long as the link is actually communicating packets; I feel like this was a safe compromise and it has not negatively affected my computing habits yet - but granted, I am neither a power user nor everyone else, so this solution/hack/crapshoot is open for interpritation. It's my experience with most commercial firewalls will drop inactive links after 15 min-1hr, etc. I've abused calls to AliasLog with this patch. I'm still a relative novice to C programming and memory management, so the last thing I wanted to deal with was mallocing crap and working with string buffers/etc and create all kinds of havoc. I'm not sure what sort of impact this has on the performance of the program; from my experience I've had 6000+ established UDP and TCP connections going at once (with about 800KB/s load) and my 1Ghz Celeron machine has seen about 30% load; it's important to note that libalias was rewriting the alias.details log every 75 state changes, instead of every 20 seconds like it does now; so it's likely the load will be significantly lower. I know there's been some recent changes to alias_db.c in the CVS which I did not have at the time I started making these changes, so I tried to keep what I've changed to a minimum in order to insure an easy patching process if any of you decide to implement this. Thanks to Masahiro Sekiguchi for his original work as an inspiration for me to do this; I don't know if anyone else uses ipfw/natd anymore (I know I do!) but if they do, they might find this useful. Any comments are appreciated. Regards, David Todd ------=_Part_4439_20253452.1209380486436 Content-Type: application/octet-stream; name=libalias.patch Content-Transfer-Encoding: base64 X-Attachment-Id: f_ffkxl9o80 Content-Disposition: attachment; filename=libalias.patch LS0tIGFsaWFzX2RiLmMub3JpZwkyMDA4LTA0LTA4IDE4OjMxOjE1LjAwMDAwMDAwMCAtMDUwMAor KysgYWxpYXNfZGIuYwkyMDA4LTA0LTI4IDA0OjE0OjAzLjAwMDAwMDAwMCAtMDUwMApAQCAtMTU5 LDYgKzE1OSw3IEBACiAKICNpbmNsdWRlIDxzeXMvc29ja2V0Lmg+CiAjaW5jbHVkZSA8bmV0aW5l dC90Y3AuaD4KKyNpbmNsdWRlIDxhcnBhL2luZXQuaD4KIAogI2lmZGVmIF9LRVJORUwgIAogI2lu Y2x1ZGUgPG5ldGluZXQvbGliYWxpYXMvYWxpYXMuaD4KQEAgLTIxMCw3ICsyMTEsNyBAQAogCiAv KiBXaGVuIHRoZSBsaW5rIGlzIHVwICovCiAjaWZuZGVmIFRDUF9FWFBJUkVfQ09OTkVDVEVECi0j ZGVmaW5lIFRDUF9FWFBJUkVfQ09OTkVDVEVEICAgODY0MDAKKyNkZWZpbmUgVENQX0VYUElSRV9D T05ORUNURUQgICAzNjAwCQkvLyBvbGQ6IDg2NDAwICgyNCBob3VycykgPyEKICNlbmRpZgogCiAK QEAgLTMwNiw3ICszMDcsNyBAQAogI2RlZmluZSBMSU5LX0FERFIgICAgICAgICAgICAgICAgICAg ICAoSVBQUk9UT19NQVggKyAzKQogI2RlZmluZSBMSU5LX1BQVFAgICAgICAgICAgICAgICAgICAg ICAoSVBQUk9UT19NQVggKyA0KQogCi0JaW50CQlmbGFnczsJLyogaW5kaWNhdGVzIHNwZWNpYWwg Y2hhcmFjdGVyaXN0aWNzICAgKi8KKwlpbnQJCWZsYWdzOwkvKiBpbmRpY2F0ZXMgc3BlY2lhbCBy ZWNoYXJhY3RlcmlzdGljcyAgICovCiAJaW50CQlwZmxhZ3M7CS8qIHByb3RvY29sLXNwZWNpZmlj IGZsYWdzICovCiAKIC8qIGZsYWcgYml0cyAqLwpAQCAtNDA0LDYgKzQwNSwxMCBAQAogI2VuZGlm CiAKIC8qIExvZyBmaWxlIGNvbnRyb2wgKi8KK3N0YXRpYyB2b2lkCVNob3dMaW5rVHlwZShzdHJ1 Y3QgYWxpYXNfbGluayAqLCBzdHJ1Y3QgbGliYWxpYXMgKik7CitzdGF0aWMgdm9pZAlTaG93QWRk ckFuZFBvcnQoc3RydWN0IGluX2FkZHIsIHVfc2hvcnQsIHN0cnVjdCBsaWJhbGlhcyAqKTsKK3N0 YXRpYyB2b2lkCVNob3dBbGlhc0RldGFpbHMoc3RydWN0IGxpYmFsaWFzICopOworCiBzdGF0aWMg dm9pZAlTaG93QWxpYXNTdGF0cyhzdHJ1Y3QgbGliYWxpYXMgKik7CiBzdGF0aWMgaW50CUluaXRQ YWNrZXRBbGlhc0xvZyhzdHJ1Y3QgbGliYWxpYXMgKik7CiBzdGF0aWMgdm9pZAlVbmluaXRQYWNr ZXRBbGlhc0xvZyhzdHJ1Y3QgbGliYWxpYXMgKik7CkBAIC00NjAsNyArNDY1LDcgQEAKIEFsaWFz TG9nKGNoYXIgKnN0ciwgY29uc3QgY2hhciAqZm9ybWF0LCAuLi4pCiB7CQkKIAl2YV9saXN0IGFw OwotCQorCiAJdmFfc3RhcnQoYXAsIGZvcm1hdCk7CiAJdnNucHJpbnRmKHN0ciwgTElCQUxJQVNf QlVGX1NJWkUsIGZvcm1hdCwgYXApOwogCXZhX2VuZChhcCk7CkBAIC00NzAsNyArNDc1LDcgQEAK IEFsaWFzTG9nKEZJTEUgKnN0cmVhbSwgY29uc3QgY2hhciAqZm9ybWF0LCAuLi4pCiB7CiAJdmFf bGlzdCBhcDsKLQkKKwogCXZhX3N0YXJ0KGFwLCBmb3JtYXQpOwogCXZmcHJpbnRmKHN0cmVhbSwg Zm9ybWF0LCBhcCk7CiAJdmFfZW5kKGFwKTsKQEAgLTQ3OCwxMyArNDgzLDE0OCBAQAogfQogI2Vu ZGlmCiAKKworLyoKKyAqIEZ1bmN0aW9uOiBTaG93TGlua1R5cGUoKQorICogUmV0dXJuICA6IG5v dGhpbmcKKyAqIFNpZGUgRWZmOiBjYWxsIEFsaWFzTG9nIHdpdGggcmVzdWx0cyBvZiB0aGUgbGlu ayB0eXBlLCBpZiBsaW5rX3R5cGUgPSBMSU5LX1RDUAorICogIGNhbGwgR2V0U3RhdGVJbi9PdXQo bG5rKSB0byBwcm92aWRlIG1vcmUgZGV0YWlscyBhYm91dCB0aGUgY3VycmVudCBUQ1Agc3RhdGUu CisgKiBDYWxscyAgIDogQWxpYXNMb2csIEdldFN0YXRlSW4sIEdldFN0YXRlT3V0CisqLworc3Rh dGljIHZvaWQKK1Nob3dMaW5rVHlwZShzdHJ1Y3QgYWxpYXNfbGluayAqbG5rLCBzdHJ1Y3QgbGli YWxpYXMgKmxhKQoreworI2lmbmRlZiBfS0VSTkVMCisKKwlzd2l0Y2ggKGxuay0+bGlua190eXBl KSB7CisJCWNhc2UgTElOS19JQ01QOiAgICAgICAgIEFsaWFzTG9nKGxhLT5sb2dEZXRhaWxzLCAi JS0xMXMgIiwgImljbXAiKTsgICAgICAgYnJlYWs7CisJCWNhc2UgTElOS19UQ1A6CisJCQlBbGlh c0xvZyhsYS0+bG9nRGV0YWlscywgInRjcCAiKTsKKwkJCWlmIChsbmstPmZsYWdzICYgTElOS19Q RVJNQU5FTlQpIHsKKwkJCQlBbGlhc0xvZyhsYS0+bG9nRGV0YWlscywgIlBFUk1MTksgIik7CisJ CQl9IGVsc2UgeworCQkJCXN3aXRjaCAoR2V0U3RhdGVJbihsbmspKSB7CisJCQkJCWNhc2UgQUxJ QVNfVENQX1NUQVRFX0NPTk5FQ1RFRDoJCUFsaWFzTG9nKGxhLT5sb2dEZXRhaWxzLCAiRVNUOiIp OyBicmVhazsKKwkJCQkJY2FzZSBBTElBU19UQ1BfU1RBVEVfRElTQ09OTkVDVEVEOglBbGlhc0xv ZyhsYS0+bG9nRGV0YWlscywgIkRJUzoiKTsgYnJlYWs7CisJCQkJCWNhc2UgQUxJQVNfVENQX1NU QVRFX05PVF9DT05ORUNURUQ6CUFsaWFzTG9nKGxhLT5sb2dEZXRhaWxzLCAiRFdOOiIpOyBicmVh azsKKwkJCQkJZGVmYXVsdDoJCQkJQWxpYXNMb2cobGEtPmxvZ0RldGFpbHMsICJVTks6Iik7IGJy ZWFrOworCQkJCX0KKwkJCQlzd2l0Y2ggKEdldFN0YXRlT3V0KGxuaykpIHsKKyAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjYXNlIEFMSUFTX1RDUF9TVEFURV9DT05ORUNU RUQ6ICAgICAgICAgQWxpYXNMb2cobGEtPmxvZ0RldGFpbHMsICJFU1QgIik7IGJyZWFrOworICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNhc2UgQUxJQVNfVENQX1NUQVRF X0RJU0NPTk5FQ1RFRDogICAgICBBbGlhc0xvZyhsYS0+bG9nRGV0YWlscywgIkRJUyAiKTsgYnJl YWs7CisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY2FzZSBBTElBU19U Q1BfU1RBVEVfTk9UX0NPTk5FQ1RFRDogICAgIEFsaWFzTG9nKGxhLT5sb2dEZXRhaWxzLCAiRFdO ICIpOyBicmVhazsKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkZWZh dWx0OiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQWxpYXNMb2cobGEtPmxvZ0RldGFp bHMsICJVTksgIik7IGJyZWFrOworICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB9CisJ CQl9CisJCQlicmVhazsKKwkJY2FzZSBMSU5LX1VEUDogICAgICAgICAgQWxpYXNMb2cobGEtPmxv Z0RldGFpbHMsICIlLTExcyAiLCAidWRwIik7ICAgICAgICBicmVhazsKKwkJY2FzZSBMSU5LX0ZS QUdNRU5UX0lEOiAgQWxpYXNMb2cobGEtPmxvZ0RldGFpbHMsICIlLTExcyAiLCAiW2ZyYWdfaWRd Iik7ICBicmVhazsKKwkJY2FzZSBMSU5LX0ZSQUdNRU5UX1BUUjogQWxpYXNMb2cobGEtPmxvZ0Rl dGFpbHMsICIlLTExcyAiLCAiW2ZyYWdfcHRyXSIpOyBicmVhazsKKwkJY2FzZSBMSU5LX0FERFI6 ICAgICAgICAgQWxpYXNMb2cobGEtPmxvZ0RldGFpbHMsICIlLTExcyAiLCAiW2FkZHJdIik7ICAg ICBicmVhazsKKwkJY2FzZSBMSU5LX1BQVFA6ICAgICAgICAgQWxpYXNMb2cobGEtPmxvZ0RldGFp bHMsICIlLTExcyAiLCAiW3BwdHBdIik7ICAgICBicmVhazsKKwkJZGVmYXVsdDogICAgICAgICAg ICAgICAgQWxpYXNMb2cobGEtPmxvZ0RldGFpbHMsICJbJS05ZF0gIiwgbG5rLT5saW5rX3R5cGUp OyAgICAgICBicmVhazsKKwl9CisjZW5kaWYKK30KKworLyoKKyAqIEZ1bmN0aW9uOiBTaG93QWRk ckFuZFBvcnQoKQorICogUmV0dXJuICA6IG5vdGhpbmcKKyAqIFNpZGUgRWZmOiBzaW1wbGUgZXhw cmVzc2lvbiBmb3Igb3V0cHV0IG9mIElQIGFkZHJlc3MgYW5kIHBvcnQgb3IgIio6KiIKKyAqICB0 byBsb2dEZXRhaWxzIGxvZyBmaWxlLiBJbXBsZW1lbnRlZCB0byBwcmV2ZW50IGNvZGUgcmVwZWl0 aW9uLgorICogQ2FsbHMgICA6IEFsaWFzTG9nCisqLworc3RhdGljIHZvaWQKK1Nob3dBZGRyQW5k UG9ydChzdHJ1Y3QgaW5fYWRkciBhZGRyLCB1X3Nob3J0IHBvcnQsIHN0cnVjdCBsaWJhbGlhcyAq bGEpCit7CisjaWZuZGVmIF9LRVJORUwKKwlpZiAobGEtPmxvZ0RldGFpbHMpIHsKKwkJQWxpYXNM b2cobGEtPmxvZ0RldGFpbHMsCisJCQlwb3J0ID09IDAgPyAiJTE1czoqICAgICAgIiA6ICIlMTVz OiUtNnUgIiwKKwkJCWFkZHIuc19hZGRyID09IElOQUREUl9BTlkgPyAiKiIgOiBpbmV0X250b2Eo YWRkciksCisJCQludG9ocyhwb3J0KSk7CisJfQorI2VuZGlmCit9CisKKworLyoKKyAqIEZ1bmN0 aW9uOiBTaG93QWxpYXNEZXRhaWxzKHN0cnVjdCBsaWJhbGlhcyAqKQorICogUmV0dXJuICA6IG5v dGhpbmcKKyAqIFNpZGUgRWZmOiBXYWxrIG91ciBsaXN0IG9mIGxpbmtzIGV2ZXJ5IDIwIHNlY29u ZHMsIGFidXNpdmVseSBjYWxsIEFsaWFzTG9nCisgKiAgdG8gb3V0cHV0IGRldGFpbHMgb2YgYWxs IG9mIG91ciBsaW5rcyB0byAvdmFyL2xvZy9hbGlhcy5kZXRhaWxzOyB0aGlzIGZ1bmN0aW9uCisg KiAgd2lsbCBub3Qgd3JpdGUgdG8gdGhlIG91dHB1dCBmaWxlIGluIGtsZC1tb2RlLgorICogQ2Fs bHMgICA6IEFsaWFzTG9nIChhYnVzaXZlbHkpLCBTaG93QWRkckFuZFBvcnQsIFNob3dMaW5rVHlw ZSwgCisqLworc3RhdGljIHZvaWQKK1Nob3dBbGlhc0RldGFpbHMoc3RydWN0IGxpYmFsaWFzICps YSkKK3sKKworCWlmICgobGEtPmxhc3REZXRhaWxzVGltZSArIDIwKSA8PSBsYS0+dGltZVN0YW1w KSB7CQkvLyB1cGRhdGUgZXZlcnkgMjAgc2Vjb25kcy4KKwkJbGEtPmxhc3REZXRhaWxzVGltZSA9 IGxhLT50aW1lU3RhbXA7CisJfSBlbHNlIHsKKwkJcmV0dXJuOworCX0KKworCVNob3dBbGlhc1N0 YXRzKGxhKTsKKworI2lmbmRlZiBfS0VSTkVMCisJaWYgKGxhLT5sb2dEZXRhaWxzKSB7CisKKwkJ c3RydWN0IGFsaWFzX2xpbmsgKmxrOworCQlpbnQgaTsKKworCQlmcmVvcGVuKE5VTEwsICJ3Iiwg bGEtPmxvZ0RldGFpbHMpOwkJLy8gemVybyBvdXIgc3RyZWFtIGFuZCByZW9wZW4uCisKKwkJTElC QUxJQVNfTE9DS19BU1NFUlQobGEpOworCisJCUFsaWFzTG9nKGxhLT5sb2dEZXRhaWxzLAkJCS8v IHdyaXRlIGhlYWRlciB0byBzdHJlYW0KKwkJInRvdGFsOiAlZFxuIiBcCisJCSJ0aW1lOiAlZFxu IiBcCisJCSJsYXN0X2NoZyAgIGV4cF90IFQtICAgICBwcm90b2NvbCAgICAgICAgc291cmNlIGFk ZHI6cG9ydCAgICAgICAgIGRlc3QgYWRkcjpwb3J0ICAgICAgICBhbGlhcyBhZGRyOnBvcnQgICAg ICAgIHByb3h5IGFkZHI6cG9ydFxuIiwKKwkJbGEtPmljbXBMaW5rQ291bnQgKyBsYS0+dWRwTGlu a0NvdW50ICsgbGEtPnRjcExpbmtDb3VudCArIGxhLT5wcHRwTGlua0NvdW50ICsKKwkJbGEtPnBy b3RvTGlua0NvdW50ICsgbGEtPmZyYWdtZW50SWRMaW5rQ291bnQgKyBsYS0+ZnJhZ21lbnRQdHJM aW5rQ291bnQsCisJCWxhLT50aW1lU3RhbXApOworCisJCWZvciAoaSA9IDA7IGkgPCBMSU5LX1RB QkxFX09VVF9TSVpFOyBpKyspIHsJCS8vIHByb2JhYmx5IHNob3VsZCB0aW1lIHRoaXMgZnVuY3Rp b24gdG8gbWVhc3VyZSBpbXBhY3QuCisJCQlsayA9IExJU1RfRklSU1QoJmxhLT5saW5rVGFibGVP dXRbaV0pOworCQkJd2hpbGUgKGxrICE9IE5VTEwpIHsKKwkJCQlzdHJ1Y3QgYWxpYXNfbGluayAq bGtfbmV4dDsKKwkJCQlsa19uZXh0ID0gTElTVF9ORVhUKGxrLCBsaXN0X291dCk7CisKKwkJCQlB bGlhc0xvZyhsYS0+bG9nRGV0YWlscywgIiUxMGQgJTUuNWQgJTYuNWQgIiwKKwkJCQkJbGstPnRp bWVzdGFtcCwJCQkvLyB0aW1lIG9mIGxhc3QgcGFja2V0IHRocm91Z2ggY29ubmVjdGlvbgorCQkJ CQlsay0+ZXhwaXJlX3RpbWUsCQkvLyB0aW1lb3V0IHBlcmlvZCBhZnRlciBsYXN0IHBhY2tldAor CQkJCQkobGEtPnRpbWVTdGFtcCAtIGxrLT5leHBpcmVfdGltZSkgPiBsay0+dGltZXN0YW1wID8g MCA6IGxhLT50aW1lU3RhbXAgLSAobGstPnRpbWVzdGFtcCArIGxrLT5leHBpcmVfdGltZSkpOwor CQkJCQkvLyBkb24ndCBuZWVkIHRvIHNlZSBwb3NpdGl2ZSB2YWx1ZXMsIGVhc2llciB0byBsb29r IHRocm91Z2ggdGhlIGxvZyBmb3IgIjAwMDAwIgorCisJCQkJU2hvd0xpbmtUeXBlKGxrLCBsYSk7 CisJCQkJU2hvd0FkZHJBbmRQb3J0KGxrLT5zcmNfYWRkciwgbGstPnNyY19wb3J0LCBsYSk7CS8v IHNvdXJjZSAoaW50ZXJuYWwgYWRkcmVzcykKKwkJCQlTaG93QWRkckFuZFBvcnQobGstPmRzdF9h ZGRyLCBsay0+ZHN0X3BvcnQsIGxhKTsJLy8gZGVzdCAoZXh0ZXJuYWwgYWRkcmVzcykKKwkJCQlT aG93QWRkckFuZFBvcnQobGstPmFsaWFzX2FkZHIsIGxrLT5hbGlhc19wb3J0LCBsYSk7CS8vIGFs aWFzIChvdXIgcHVibGljIGFkZHJlc3MpCisJCQkJU2hvd0FkZHJBbmRQb3J0KGxrLT5wcm94eV9h ZGRyLCBsay0+cHJveHlfcG9ydCwgbGEpOwkvLyBwcm94eSA/CisJCQkJQWxpYXNMb2cobGEtPmxv Z0RldGFpbHMsICJcbiIpOworCisJCQkJbGsgPSBsa19uZXh0OworCQkJfQorCQl9CisJfQorI2Vu ZGlmCit9CisKKwogc3RhdGljIHZvaWQKIFNob3dBbGlhc1N0YXRzKHN0cnVjdCBsaWJhbGlhcyAq bGEpCiB7CiAKIAlMSUJBTElBU19MT0NLX0FTU0VSVChsYSk7Ci0vKiBVc2VkIGZvciBkZWJ1Z2dp bmcgKi8KKwogCWlmIChsYS0+bG9nRGVzYykgeworCisjaWZuZGVmIF9LRVJORUwKKwkJZnJlb3Bl bihOVUxMLCAidyIsIGxhLT5sb2dEZXNjKTsJCS8vIHplcm8gb3VyIHN0cmVhbSBhbmQgc3RhcnQg ZnJvbSB0aGUgdG9wCisjZW5kaWYKKwogCQlpbnQgdG90ICA9IGxhLT5pY21wTGlua0NvdW50ICsg bGEtPnVkcExpbmtDb3VudCArIAogCQkJbGEtPnRjcExpbmtDb3VudCArIGxhLT5wcHRwTGlua0Nv dW50ICsKIAkJCWxhLT5wcm90b0xpbmtDb3VudCArIGxhLT5mcmFnbWVudElkTGlua0NvdW50ICsK QEAgLTgxNCwxNyArOTU0LDE1IEBACiBDbGVhbnVwQWxpYXNEYXRhKHN0cnVjdCBsaWJhbGlhcyAq bGEpCiB7CiAJc3RydWN0IGFsaWFzX2xpbmsgKmxuazsKLQlpbnQgaSwgaWNvdW50OworCWludCBp OwogCiAJTElCQUxJQVNfTE9DS19BU1NFUlQobGEpOwotCWljb3VudCA9IDA7CiAJZm9yIChpID0g MDsgaSA8IExJTktfVEFCTEVfT1VUX1NJWkU7IGkrKykgewogCQlsbmsgPSBMSVNUX0ZJUlNUKCZs YS0+bGlua1RhYmxlT3V0W2ldKTsKIAkJd2hpbGUgKGxuayAhPSBOVUxMKSB7CiAJCQlzdHJ1Y3Qg YWxpYXNfbGluayAqbGlua19uZXh0OwogCiAJCQlsaW5rX25leHQgPSBMSVNUX05FWFQobG5rLCBs aXN0X291dCk7Ci0JCQlpY291bnQrKzsKIAkJCURlbGV0ZUxpbmsobG5rKTsKIAkJCWxuayA9IGxp bmtfbmV4dDsKIAkJfQpAQCAtODM3LDExICs5NzUsOSBAQAogc3RhdGljIHZvaWQKIEluY3JlbWVu dGFsQ2xlYW51cChzdHJ1Y3QgbGliYWxpYXMgKmxhKQogewotCWludCBpY291bnQ7CiAJc3RydWN0 IGFsaWFzX2xpbmsgKmxuazsKIAogCUxJQkFMSUFTX0xPQ0tfQVNTRVJUKGxhKTsKLQlpY291bnQg PSAwOwogCWxuayA9IExJU1RfRklSU1QoJmxhLT5saW5rVGFibGVPdXRbbGEtPmNsZWFudXBJbmRl eCsrXSk7CiAJd2hpbGUgKGxuayAhPSBOVUxMKSB7CiAJCWludCBpZGVsdGE7CkBAIC04NTIsMjEg Kzk4OCwyMyBAQAogCQlzd2l0Y2ggKGxuay0+bGlua190eXBlKSB7CiAJCWNhc2UgTElOS19UQ1A6 CiAJCQlpZiAoaWRlbHRhID4gbG5rLT5leHBpcmVfdGltZSkgewotCQkJCXN0cnVjdCB0Y3BfZGF0 ICp0Y3BfYXV4OwotCi0JCQkJdGNwX2F1eCA9IGxuay0+ZGF0YS50Y3A7Ci0JCQkJaWYgKHRjcF9h dXgtPnN0YXRlLmluICE9IEFMSUFTX1RDUF9TVEFURV9DT05ORUNURUQKLQkJCQkgICAgfHwgdGNw X2F1eC0+c3RhdGUub3V0ICE9IEFMSUFTX1RDUF9TVEFURV9DT05ORUNURUQpIHsKKwkJCQlpZiAo R2V0U3RhdGVJbihsbmspICE9IEFMSUFTX1RDUF9TVEFURV9DT05ORUNURUQKKwkJCQkgICAgfHwg R2V0U3RhdGVPdXQobG5rKSAhPSBBTElBU19UQ1BfU1RBVEVfQ09OTkVDVEVEKSB7CiAJCQkJCURl bGV0ZUxpbmsobG5rKTsKLQkJCQkJaWNvdW50Kys7CisJCQkJfSBlbHNlIHsKKwkJCQkJLyogZXhw aXJlX3RpbWUgaXMgdXAsIHNldCB0aGUgbGluayBhcyBkaXNjb25uZWN0ZWQsIG9uIHRoZSBwYXNz CisJCQkJCSAqIDEyMHMgZnJvbSBub3cgaWYgaXQncyBzdGlsbCBkaXNjb25uZWN0ZWQgdGhlbiB3 ZSdsbCBkdW1wIHRoZSBsaW5rLgorCQkJCQkgKi8KKwkJCQkJU2V0U3RhdGVJbihsbmssIEFMSUFT X1RDUF9TVEFURV9OT1RfQ09OTkVDVEVEKTsKKwkJCQkJU2V0U3RhdGVPdXQobG5rLCBBTElBU19U Q1BfU1RBVEVfTk9UX0NPTk5FQ1RFRCk7CisJCQkJCWxuay0+ZXhwaXJlX3RpbWUgPSBUQ1BfRVhQ SVJFX1NJTkdMRURFQUQ7CisJCQkJCWxuay0+dGltZXN0YW1wID0gbGEtPnRpbWVTdGFtcDsKIAkJ CQl9CiAJCQl9CiAJCQlicmVhazsKIAkJZGVmYXVsdDoKLQkJCWlmIChpZGVsdGEgPiBsbmstPmV4 cGlyZV90aW1lKSB7CisJCQlpZiAoaWRlbHRhID4gbG5rLT5leHBpcmVfdGltZSkKIAkJCQlEZWxl dGVMaW5rKGxuayk7Ci0JCQkJaWNvdW50Kys7Ci0JCQl9CiAJCQlicmVhazsKIAkJfQogCQlsbmsg PSBsaW5rX25leHQ7CkBAIC05NDMsMTMgKzEwODEsMTUgQEAKIAkJYnJlYWs7CiAJfQogCi0vKiBG cmVlIG1lbW9yeSAqLwotCWZyZWUobG5rKTsKIAogLyogV3JpdGUgc3RhdGlzdGljcywgaWYgbG9n Z2luZyBlbmFibGVkICovCiAJaWYgKGxhLT5wYWNrZXRBbGlhc01vZGUgJiBQS1RfQUxJQVNfTE9H KSB7Ci0JCVNob3dBbGlhc1N0YXRzKGxhKTsKKwkJU2hvd0FsaWFzRGV0YWlscyhsYSk7CiAJfQor CisvKiBGcmVlIG1lbW9yeSAqLworICAgICAgICBmcmVlKGxuayk7CisKIH0KIAogCkBAIC0xMDg5 LDcgKzEyMjksNyBAQAogI2VuZGlmCiAJfQogCWlmIChsYS0+cGFja2V0QWxpYXNNb2RlICYgUEtU X0FMSUFTX0xPRykgewotCQlTaG93QWxpYXNTdGF0cyhsYSk7CisJCVNob3dBbGlhc0RldGFpbHMo bGEpOwogCX0KIAlyZXR1cm4gKGxuayk7CiB9CkBAIC0yMjYyLDggKzI0MDIsMTUgQEAKIAkJaWYg KChsYS0+bG9nRGVzYyA9IG1hbGxvYyhMSUJBTElBU19CVUZfU0laRSkpKQogCQkJOwogI2Vsc2Ug CQkKLQkJaWYgKChsYS0+bG9nRGVzYyA9IGZvcGVuKCIvdmFyL2xvZy9hbGlhcy5sb2ciLCAidyIp KSkKKwkJaWYgKChsYS0+bG9nRGVzYyA9IGZvcGVuKCIvdmFyL2xvZy9hbGlhcyIsICJ3IikpKQog CQkJZnByaW50ZihsYS0+bG9nRGVzYywgIlBhY2tldEFsaWFzL0luaXRQYWNrZXRBbGlhc0xvZzog UGFja2V0IGFsaWFzIGxvZ2dpbmcgZW5hYmxlZC5cbiIpOwkgICAgICAgCisJCWVsc2UKKwkJCXJl dHVybiAoRU5PTUVNKTsKKworCQlpZiAoKGxhLT5sb2dEZXRhaWxzID0gZm9wZW4oIi92YXIvbG9n L2FsaWFzLmRldGFpbHMiLCAidyIpKSkgeworCQkJZnByaW50ZihsYS0+bG9nRGV0YWlscywgIlBh Y2tldEFsaWFzL0luaXRQYWNrZXRBbGlhc0xvZzogUGFja2V0IGFsaWFzIGxvZ2dpbmcgZW5hYmxl ZC5cbiIpOworCQkJbGEtPmxhc3REZXRhaWxzVGltZSA9IGxhLT50aW1lU3RhbXA7CisJCX0KICNl bmRpZgogCQllbHNlIAogCQkJcmV0dXJuIChFTk9NRU0pOyAvKiBsb2cgaW5pdGlhbGl6YXRpb24g ZmFpbGVkICovCkBAIC0yMjg0LDYgKzI0MzEsMTAgQEAKIAkJZnJlZShsYS0+bG9nRGVzYyk7CiAj ZWxzZQogCQlmY2xvc2UobGEtPmxvZ0Rlc2MpOworCQlpZiAobGEtPmxvZ0RldGFpbHMpIHsKKwkJ CWZjbG9zZShsYS0+bG9nRGV0YWlscyk7CisJCQlsYS0+bG9nRGV0YWlscyA9IE5VTEw7CisJCX0K ICNlbmRpZgogCQlsYS0+bG9nRGVzYyA9IE5VTEw7CiAJfQotLS0gYWxpYXNfbG9jYWwuaC5vcmln CTIwMDgtMDQtMDkgMTc6NDY6MjUuMDAwMDAwMDAwIC0wNTAwCisrKyBhbGlhc19sb2NhbC5oCTIw MDgtMDQtMjggMDI6NTM6MjYuMDAwMDAwMDAwIC0wNTAwCkBAIC0xMDAsNiArMTAwLDggQEAKIAlp bnQJCWZyYWdtZW50UHRyTGlua0NvdW50OwogCWludAkJc29ja0NvdW50OwogCisJaW50CQlsYXN0 RGV0YWlsc1RpbWU7CisKIAlpbnQJCWNsZWFudXBJbmRleDsJLyogSW5kZXggdG8gY2hhaW4gb2Yg bGluayB0YWJsZSAgICAqLwogCS8qIGJlaW5nIGluc3BlY3RlZCBmb3Igb2xkIGxpbmtzICAgKi8K IApAQCAtMTIwLDYgKzEyMiw3IEBACiAJY2hhciAgICAgICAgICAgKmxvZ0Rlc2M7ICAgICAgICAK ICNlbHNlIAogCUZJTEUgICAgICAgICAgICpsb2dEZXNjOwkKKwlGSUxFICAgICAgICAgICAqbG9n RGV0YWlsczsKICNlbmRpZgogCS8qIHN0YXRpc3RpY3MgbW9uaXRvcmluZyAqLwogCg== ------=_Part_4439_20253452.1209380486436-- From owner-freebsd-net@FreeBSD.ORG Mon Apr 28 11:50:05 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 698B6106567B for ; Mon, 28 Apr 2008 11:50:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 613058FC0C for ; Mon, 28 Apr 2008 11:50:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m3SBo4kB064228 for ; Mon, 28 Apr 2008 11:50:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m3SBo41d064227; Mon, 28 Apr 2008 11:50:04 GMT (envelope-from gnats) Date: Mon, 28 Apr 2008 11:50:04 GMT Message-Id: <200804281150.m3SBo41d064227@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: misha saf Cc: Subject: Re: misc/123066: kernel trap with ipsec X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: misha saf List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2008 11:50:05 -0000 The following reply was made to PR kern/123066; it has been noted by GNATS. From: misha saf To: "Bjoern A. Zeeb" Cc: Kris Kennaway , , Subject: Re: misc/123066: kernel trap with ipsec Date: Mon, 28 Apr 2008 15:30:12 +0400 * "Bjoern A. Zeeb" [Mon, 28 Apr 2008 08:22:20 +0000 (UTC)]: > On Mon, 28 Apr 2008, misha saf wrote: > > Hi, > > > db> trace > > Tracing pid 996 tid 100075 td 0xc1ed2210 > > generic_bcopy(c1c8b700, c1eeac80,0,14,9,...) at generic_bcopy+0x1a > > ipsec4_process_packet(c1c8b700, c1eeac80,20,0,c1f00924,...) at > > ipsec4_process_packet+0x28b > > > Could you alos lookup which line of code this is? > > gdb /path/to/kernel.debug > l *ipsec4_process_packet+0x28b > > -- > Bjoern A. Zeeb Stop bit received. Insert coin for new game. (gdb) l *ipsec4_process_packet+0x28b 0xc08fecab is in ipsec4_process_packet (/usr/src/sys/netipsec/ipsec_output.c:486). 481 */ 482 if (sav->tdb_xform->xf_type != XF_IP4) { 483 ip = mtod(m, struct ip *); 484 i = ip->ip_hl << 2; 485 off = offsetof(struct ip, ip_p); 486 error = (*sav->tdb_xform->xf_output)(m, isr, NULL, i, off); 487 } else { 488 error = ipsec_process_done(m, isr); 489 } 490 IPSECREQUEST_UNLOCK(isr); From owner-freebsd-net@FreeBSD.ORG Mon Apr 28 12:23:51 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 525A41065674; Mon, 28 Apr 2008 12:23:51 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8D0C88FC1C; Mon, 28 Apr 2008 12:23:50 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <4815C1D1.7040000@FreeBSD.org> Date: Mon, 28 Apr 2008 14:23:45 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: hotlips Internet admin References: <200804260110.m3Q1A5Nk006013@freefall.freebsd.org> In-Reply-To: <200804260110.m3Q1A5Nk006013@freefall.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org, peter@FreeBSD.org Subject: Re: kern/122875: "rstatd: Can't get namelist. 1" - fbsd 7.0-stable (works ok in 7.0-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: Mon, 28 Apr 2008 12:23:51 -0000 hotlips Internet admin wrote: > The following reply was made to PR kern/122875; it has been noted by GNATS. > > From: hotlips Internet admin > To: FreeBSD-gnats-submit@FreeBSD.org, freebsd-bugs@FreeBSD.org > Cc: bug-followup@FreeBSD.org > Subject: Re: kern/122875: "rstatd: Can't get namelist. 1" - fbsd 7.0-stable > (works ok in 7.0-release) > Date: Fri, 25 Apr 2008 20:50:51 -0400 (EDT) > > On Fri, 18 Apr 2008 FreeBSD-gnats-submit@FreeBSD.org wrote: > > |Thank you very much for your problem report. > |It has the internal identification `kern/122875'. > |The individual assigned to look at your > |report is: freebsd-bugs. > | > |You can access the state of your problem report at any time > |via this link: > | > |http://www.freebsd.org/cgi/query-pr.cgi?pr=122875 > | > |>Category: kern > |>Responsible: freebsd-bugs > |>Synopsis: "rstatd: Can't get namelist. 1" - fbsd 7.0-stable (works ok in 7.0-release) > |>Arrival-Date: Fri Apr 18 02:20:00 UTC 2008 > > > this also happens in FreeBSD 6.3-STABLE > > > I depend heavily on rpc.rstatd as a part of monitoring > servers and firewalls etc., so this is a serious issue > for me until I can get a fix or work-around Revert the recent commits by Peter until a fix is applied. Kris From owner-freebsd-net@FreeBSD.ORG Mon Apr 28 13:39:54 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 616701065672 for ; Mon, 28 Apr 2008 13:39:54 +0000 (UTC) (envelope-from andrew@modulus.org) Received: from email.octopus.com.au (host-122-100-2-232.octopus.com.au [122.100.2.232]) by mx1.freebsd.org (Postfix) with ESMTP id 2A4B28FC24 for ; Mon, 28 Apr 2008 13:39:53 +0000 (UTC) (envelope-from andrew@modulus.org) Received: by email.octopus.com.au (Postfix, from userid 1002) id 1C4C913612; Mon, 28 Apr 2008 23:39:52 +1000 (EST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on email.octopus.com.au X-Spam-Level: X-Spam-Status: No, score=-1.4 required=10.0 tests=ALL_TRUSTED autolearn=failed version=3.2.3 Received: from [10.20.30.101] (60.218.233.220.exetel.com.au [220.233.218.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: admin@email.octopus.com.au) by email.octopus.com.au (Postfix) with ESMTP id 389DC13577; Mon, 28 Apr 2008 23:39:42 +1000 (EST) Message-ID: <4815D39A.7060605@modulus.org> Date: Mon, 28 Apr 2008 23:39:38 +1000 From: Andrew Snow User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <995276.92553.qm@web46006.mail.sp1.yahoo.com> In-Reply-To: <995276.92553.qm@web46006.mail.sp1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Dewayne Geraghty Subject: Re: if_vge.c TX checksum errors on 6.3R-p2 7.0R-p1 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, 28 Apr 2008 13:39:54 -0000 Dewayne Geraghty wrote: > Hi, I have four VIA motherboards each containing a vge0 device, three are misbehaving. > > On both the 7.0R-p1 and the 6.3Rp2 motherboards, the network cable needs to be unplugged and replugged into the motherboard, before ping will respond in either direction. The driver is issueing "incorrect" checksums during transmissions from the vge device, as observed from tcpdump -vvv. Hello, We have had success with many of the Via EN12000E motherboards and FreeBSD. These have the VT6122 chip on VIA VT8237R-series South Bridge. We have used various versions of 6.0-6.2 and 7.0-STABLE and it has always performed flawlessly at 100m and gigabit speeds to various switches. I wonder if you have are experiencing an incompability with your switch or the device at the other end of the cable? That kind of behaviour smells like a link-level issue to me. - Andrew From owner-freebsd-net@FreeBSD.ORG Mon Apr 28 16:13:33 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2C0F1065681 for ; Mon, 28 Apr 2008 16:13:33 +0000 (UTC) (envelope-from yonyossef.lists@gmail.com) Received: from hu-out-0506.google.com (hu-out-0506.google.com [72.14.214.230]) by mx1.freebsd.org (Postfix) with ESMTP id 726418FC1F for ; Mon, 28 Apr 2008 16:13:33 +0000 (UTC) (envelope-from yonyossef.lists@gmail.com) Received: by hu-out-0506.google.com with SMTP id 28so1496374hub.8 for ; Mon, 28 Apr 2008 09:13:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=YBm4Pth/4LN4RzN11f/eINlF23PnxNefrhkqpwNrBSo=; b=J65z0dt1lzT8R2c0LKZgBaBw6VdnHbt8sTfwwml0ik4pWuI7A+pTxEGMGUN0D9yIqZKes5iBjAFZe5uLBsUDJaRpn0/BG/ENd0i5TXWaaiDdgw8EtRk6+YCRikGK8d1ygI2GkggJ9LJx3hyU+nnwDoRjaVd8wQP8p8Cku8VGK7I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=AkjDQiFrTGEytCzo/00vTsEVlpJoBJhaVvpdKzU0oA2C1ETYjq9OphTjsyh1DXJMbg+t/jvcirXzp+DHIS1Y/Gz2wsXgwHXLVVSA7rLDmrDYp51tquViq1tuBLxDSQi4NqA0p0ZwI2Yp14L148ZsYfDT8zSxF484Vgy4amrBxJE= Received: by 10.150.220.12 with SMTP id s12mr3915668ybg.74.1209398371739; Mon, 28 Apr 2008 08:59:31 -0700 (PDT) Received: by 10.151.84.2 with HTTP; Mon, 28 Apr 2008 08:59:31 -0700 (PDT) Message-ID: <20def4870804280859g3c18eae0x1af9e97ae8776916@mail.gmail.com> Date: Mon, 28 Apr 2008 18:59:31 +0300 From: "Mr Y" To: freebsd-questions@freebsd.org, freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: OS throws away large packets 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, 28 Apr 2008 16:13:34 -0000 Hi all, I'm trying to implement Large Recieve Offload for an Ethernet driver on FreeBSD 6.3, but all my >MTU packets are being thrown by the OS. I'm using mbuf chains in this imlpementation, each mbuf is a cluster of MCLBYTES bytes. They are linked by the m_next pointer. The first packet being thrown away is 2945 bytes long. Wireshark shows the packet that is being passed to the OS is correct. Do I need to set some OS parameter to make it recieve mbuf chains? Please help. - Yony From owner-freebsd-net@FreeBSD.ORG Mon Apr 28 17:45:06 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95CFB106564A; Mon, 28 Apr 2008 17:45:06 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from s200aog17.obsmtp.com (s200aog17.obsmtp.com [207.126.144.131]) by mx1.freebsd.org (Postfix) with SMTP id 8FA038FC21; Mon, 28 Apr 2008 17:45:05 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from source ([63.174.175.251]) by eu1sys200aob017.postini.com ([207.126.147.11]) with SMTP; Mon, 28 Apr 2008 17:45:04 UTC Received: from [172.17.2.235] (unknown [172.17.2.235]) by bbbx3.usdmm.com (Postfix) with ESMTP id C5109B8E1; Mon, 28 Apr 2008 17:20:44 +0000 (UTC) Message-ID: <48160770.2080509@tomjudge.com> Date: Mon, 28 Apr 2008 12:20:48 -0500 From: Tom Judge User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: Mr Y References: <20def4870804280859g3c18eae0x1af9e97ae8776916@mail.gmail.com> In-Reply-To: <20def4870804280859g3c18eae0x1af9e97ae8776916@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-questions@freebsd.org Subject: Re: OS throws away large packets 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, 28 Apr 2008 17:45:06 -0000 Mr Y wrote: > Hi all, > > I'm trying to implement Large Recieve Offload for an Ethernet driver on > FreeBSD 6.3, but all my >MTU packets are being thrown by the OS. > I'm using mbuf chains in this imlpementation, each mbuf is a cluster of > MCLBYTES bytes. They are linked by the m_next pointer. > The first packet being thrown away is 2945 bytes long. Wireshark shows the > packet that is being passed to the OS is correct. > > Do I need to set some OS parameter to make it recieve mbuf chains? > > Please help. > Hi Yony, I seem to remember some discussion about this list last year see the following threads: http://lists.freebsd.org/pipermail/freebsd-net/2007-September/015250.html http://lists.freebsd.org/pipermail/freebsd-net/2007-September/015350.html From my limited reading of these threads just now and possibly bad memory. It would seem that the MRU to MTU relationship is defined in the nic driver rather than enforced further up the stack or at least that seamed to be the case with the bce driver. Hope this is helpful, Tom From owner-freebsd-net@FreeBSD.ORG Mon Apr 28 19:12:06 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB4B01065670; Mon, 28 Apr 2008 19:12:06 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C84E78FC17; Mon, 28 Apr 2008 19:12:06 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (gavin@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m3SJC6Qo098927; Mon, 28 Apr 2008 19:12:06 GMT (envelope-from gavin@freefall.freebsd.org) Received: (from gavin@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m3SJC69g098923; Mon, 28 Apr 2008 19:12:06 GMT (envelope-from gavin) Date: Mon, 28 Apr 2008 19:12:06 GMT Message-Id: <200804281912.m3SJC69g098923@freefall.freebsd.org> To: gavin@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: gavin@FreeBSD.org Cc: Subject: Re: kern/123172: [bce] Watchdog timeout problems with if_bce 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, 28 Apr 2008 19:12:07 -0000 Old Synopsis: Watchdog timeout problems with if_bce New Synopsis: [bce] Watchdog timeout problems with if_bce Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Mon Apr 28 19:11:25 UTC 2008 Responsible-Changed-Why: Over to maintainers http://www.freebsd.org/cgi/query-pr.cgi?pr=123172 From owner-freebsd-net@FreeBSD.ORG Mon Apr 28 19:20:05 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 124411065673; Mon, 28 Apr 2008 19:20:05 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E28DB8FC0A; Mon, 28 Apr 2008 19:20:04 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from freefall.freebsd.org (jkim@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m3SJK4Zr000700; Mon, 28 Apr 2008 19:20:04 GMT (envelope-from jkim@freefall.freebsd.org) Received: (from jkim@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m3SJK4hi000696; Mon, 28 Apr 2008 19:20:04 GMT (envelope-from jkim) Date: Mon, 28 Apr 2008 19:20:04 GMT Message-Id: <200804281920.m3SJK4hi000696@freefall.freebsd.org> To: jkim@FreeBSD.org, freebsd-net@FreeBSD.org, jkim@FreeBSD.org From: jkim@FreeBSD.org Cc: Subject: Re: kern/123138: [bpf] [patch] bpf incorrectly determines outgoing routed packets as incoming when BIOCSDIRECTION is used 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, 28 Apr 2008 19:20:05 -0000 Synopsis: [bpf] [patch] bpf incorrectly determines outgoing routed packets as incoming when BIOCSDIRECTION is used Responsible-Changed-From-To: freebsd-net->jkim Responsible-Changed-By: jkim Responsible-Changed-When: Mon Apr 28 19:19:36 UTC 2008 Responsible-Changed-Why: This is my bug. Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=123138 From owner-freebsd-net@FreeBSD.ORG Mon Apr 28 19:54:40 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDDBF1065670; Mon, 28 Apr 2008 19:54:40 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B086D8FC1D; Mon, 28 Apr 2008 19:54:40 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (gavin@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m3SJseV3003339; Mon, 28 Apr 2008 19:54:40 GMT (envelope-from gavin@freefall.freebsd.org) Received: (from gavin@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m3SJse9B003335; Mon, 28 Apr 2008 19:54:40 GMT (envelope-from gavin) Date: Mon, 28 Apr 2008 19:54:40 GMT Message-Id: <200804281954.m3SJse9B003335@freefall.freebsd.org> To: a.zaaiman@nouzelle.com, gavin@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: gavin@FreeBSD.org Cc: Subject: Re: kern/123166: [re] CARP messages filtered by Realtek driver on > 6.2 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, 28 Apr 2008 19:54:40 -0000 Old Synopsis: CARP messages filtered by Realtek driver on > 6.2 New Synopsis: [re] CARP messages filtered by Realtek driver on > 6.2 State-Changed-From-To: open->feedback State-Changed-By: gavin State-Changed-When: Mon Apr 28 19:46:36 UTC 2008 State-Changed-Why: To submitter: Can you give the output of "pciconf -l" so that we know exactly what type of card you have? Also, are you able/willing to establish exactly which change has broken the card for you (by updating to 6-STABLE half way between 6.2 and 6.3 and seeing if you still see the problem)? From looking at the code there are a few commits that have the potential to be related. Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Mon Apr 28 19:46:36 UTC 2008 Responsible-Changed-Why: Over to maintainers http://www.freebsd.org/cgi/query-pr.cgi?pr=123166 From owner-freebsd-net@FreeBSD.ORG Mon Apr 28 20:50:47 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CA101065676; Mon, 28 Apr 2008 20:50:47 +0000 (UTC) (envelope-from vwe@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 339468FC20; Mon, 28 Apr 2008 20:50:47 +0000 (UTC) (envelope-from vwe@FreeBSD.org) Received: from freefall.freebsd.org (vwe@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m3SKol66008016; Mon, 28 Apr 2008 20:50:47 GMT (envelope-from vwe@freefall.freebsd.org) Received: (from vwe@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m3SKolus008012; Mon, 28 Apr 2008 20:50:47 GMT (envelope-from vwe) Date: Mon, 28 Apr 2008 20:50:47 GMT Message-Id: <200804282050.m3SKolus008012@freefall.freebsd.org> To: vwe@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: vwe@FreeBSD.org Cc: Subject: Re: kern/123123: [re][patch] Realtek RTL8111C detection and failure 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, 28 Apr 2008 20:50:47 -0000 Old Synopsis: [re] Realtek RTL8111C detection and failure New Synopsis: [re][patch] Realtek RTL8111C detection and failure Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Mon Apr 28 20:49:41 UTC 2008 Responsible-Changed-Why: this is looking like a PHY problem. Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=123123 From owner-freebsd-net@FreeBSD.ORG Mon Apr 28 20:59:40 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CEA31065670; Mon, 28 Apr 2008 20:59:40 +0000 (UTC) (envelope-from a.zaaiman@nouzelle.com) Received: from mx-in03.nouzelle.com (mx-in01.nouzelle.com [87.119.194.132]) by mx1.freebsd.org (Postfix) with ESMTP id B95E28FC27; Mon, 28 Apr 2008 20:59:39 +0000 (UTC) (envelope-from a.zaaiman@nouzelle.com) Received: from internal01.nouzelle.com (internal01.nouzelle.local [172.29.32.15]) by mx-in03.nouzelle.com (Postfix) with ESMTP id 37E6C40B5DF; Mon, 28 Apr 2008 22:27:54 +0200 (CEST) Received: from mailscan.nouzelle.com (mailscan.nouzelle.local [172.29.32.10]) by internal01.nouzelle.com (Postfix) with ESMTP id 201DF40B5C1; Mon, 28 Apr 2008 22:27:54 +0200 (CEST) X-Virus-Scanned: by amavisd-new at nouzelle.com X-Spam-Score: -4.379 X-Spam-Level: X-Spam-Status: No, score=-4.379 required=3 tests=[ALL_TRUSTED=-1.8, AWL=0.020, BAYES_00=-2.599] Received: from internal01.nouzelle.com ([172.29.32.15]) by mailscan.nouzelle.com (mailscan.nouzelle.com [172.29.32.10]) (amavisd-new, port 10026) with ESMTP id Jf6o0YyQA9hL; Mon, 28 Apr 2008 22:27:42 +0200 (CEST) Received: from nouzelle.com (unknown [172.29.32.30]) by internal01.nouzelle.com (Postfix) with ESMTP id DB43540B3E2; Mon, 28 Apr 2008 22:27:41 +0200 (CEST) Date: Mon, 28 Apr 2008 22:27:32 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <50EC980894F5144CB64BDF9B16BDEEF3056D77@NZL-EXCHANGE.nouzelle.local> Content-class: urn:content-classes:message In-Reply-To: <200804281954.m3SJse9B003335@freefall.freebsd.org> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-TNEF-Correlator: Thread-Topic: kern/123166: [re] CARP messages filtered by Realtek driver on > 6.2 thread-index: AcipabwMBpWFYgSOTkmab0xVISif0gABEjoA References: <200804281954.m3SJse9B003335@freefall.freebsd.org> From: "Auke Zaaiman" To: , , Cc: Subject: RE: kern/123166: [re] CARP messages filtered by Realtek driver on > 6.2 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, 28 Apr 2008 20:59:40 -0000 Hi, Below the output of pciconf -l: re0@pci0:8:0: class=3D0x020000 card=3D0x816910ec chip=3D0x816910ec = rev=3D0x10 hdr=3D0x00 re1@pci0:9:0: class=3D0x020000 card=3D0x816910ec chip=3D0x816910ec = rev=3D0x10 hdr=3D0x00 And yes, we are able and willing to establish exactly which change has broken the card. Can you give me details on where I can fetch the source I need to update to? Regards, Auke Zaaiman Nouzelle Internet Services -----Oorspronkelijk bericht----- Van: gavin@FreeBSD.org [mailto:gavin@FreeBSD.org]=20 Verzonden: maandag 28 april 2008 21:55 Aan: Auke Zaaiman; gavin@FreeBSD.org; freebsd-bugs@FreeBSD.org; freebsd-net@FreeBSD.org Onderwerp: Re: kern/123166: [re] CARP messages filtered by Realtek driver on > 6.2 Old Synopsis: CARP messages filtered by Realtek driver on > 6.2 New Synopsis: [re] CARP messages filtered by Realtek driver on > 6.2 State-Changed-From-To: open->feedback State-Changed-By: gavin State-Changed-When: Mon Apr 28 19:46:36 UTC 2008 State-Changed-Why:=20 To submitter: Can you give the output of "pciconf -l" so that we know exactly what type of card you have? Also, are you able/willing to establish exactly which change has broken the card for you (by updating to 6-STABLE half way between 6.2 and 6.3 and seeing if you still see the problem)? From looking at the code there are a few commits that have the potential to be related. Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Mon Apr 28 19:46:36 UTC 2008 Responsible-Changed-Why:=20 Over to maintainers http://www.freebsd.org/cgi/query-pr.cgi?pr=3D123166 From owner-freebsd-net@FreeBSD.ORG Mon Apr 28 21:24:30 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83739106566C; Mon, 28 Apr 2008 21:24:30 +0000 (UTC) (envelope-from vwe@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 59BAF8FC12; Mon, 28 Apr 2008 21:24:30 +0000 (UTC) (envelope-from vwe@FreeBSD.org) Received: from freefall.freebsd.org (vwe@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m3SLOU1x010271; Mon, 28 Apr 2008 21:24:30 GMT (envelope-from vwe@freefall.freebsd.org) Received: (from vwe@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m3SLOU37010267; Mon, 28 Apr 2008 21:24:30 GMT (envelope-from vwe) Date: Mon, 28 Apr 2008 21:24:30 GMT Message-Id: <200804282124.m3SLOU37010267@freefall.freebsd.org> To: josh@endries.org, vwe@FreeBSD.org, freebsd-net@FreeBSD.org From: vwe@FreeBSD.org Cc: Subject: Re: kern/123172: [bce] Watchdog timeout problems with if_bce 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, 28 Apr 2008 21:24:30 -0000 Synopsis: [bce] Watchdog timeout problems with if_bce State-Changed-From-To: open->feedback State-Changed-By: vwe State-Changed-When: Mon Apr 28 21:21:28 UTC 2008 State-Changed-Why: Please show us output of `ifconfig bge0' Also, can you please check if you still experience errors when disabling jumbo frames, checksum offloading and if setting hw.bce.msi_enable to another value (0) makes any difference? This appears to be most likely a DUP or related to PR kern/100858. http://www.freebsd.org/cgi/query-pr.cgi?pr=123172 From owner-freebsd-net@FreeBSD.ORG Tue Apr 29 00:17:28 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57B6D106566B for ; Tue, 29 Apr 2008 00:17:28 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outC.internet-mail-service.net (outc.internet-mail-service.net [216.240.47.226]) by mx1.freebsd.org (Postfix) with ESMTP id 145FE8FC15 for ; Tue, 29 Apr 2008 00:17:28 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Mon, 28 Apr 2008 21:59:25 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 8F86F2D601C for ; Mon, 28 Apr 2008 17:17:26 -0700 (PDT) Message-ID: <48166916.8090801@elischer.org> Date: Mon, 28 Apr 2008 17:17:26 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: FreeBSD Net Content-Type: multipart/mixed; boundary="------------070206030204090107090604" Subject: mbuf usage in packets.. 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, 29 Apr 2008 00:17:28 -0000 This is a multi-part message in MIME format. --------------070206030204090107090604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I wrote a cruddy little profiler to profile the packets being sent on my system.. after a bit of a live session including things like "ls -lR /usr" I dumped out the results: root@trafmon2:sysctl -b kern.ipc.mbufprofile wasted: 0 0 0 0 0 736 13092 66773 54226 0 23 2322 21696 0 0 0 used: 0 0 0 0 0 4 2355 43755 88719 23309 438 288 0 0 0 0 segments: 0 82974 75819 23 10 10 9 7 5 2 6 2 1 0 0 0 ================ Interpretation: for how many mbufs per packet: no packets had 0 segments (duh) but almost as many had 2 as had 1 0 - 0 1 - 82974 2 - 75819 3 - 23 4 - 10 5 - 10 6 - 9 7 - 7 8 - 5 9 - 2 10 - 6 11 - 2 12 - 1 One packet had 12 mbufs?! 13 - 0 14 - 0 15 - 0 for total packet data size: 0 hd 0 0 had 1 0 had 2,3 0 had 4-7 0 had 8-15 4 had 16-31 2355 had 32-63 43755 had 64-127 88719 had 128-255 23309 had 256-511 438 had 512-1023 288 had 1024-2047 for wasted space: 736 had between 16-31 unused bytes 13092 had 32-63 unused bytes 66773 had 64-127 unused bytes 54226 had 128-255 unused bytes 0 had 256-511 unused bytes (!) 23 had 512-1023 unused bytes 2322 had 1024-2047 unused bytes 21696 had 2048-4096 unused bytes (!) profiling diff attached.. --------------070206030204090107090604 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="mbprofile.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="mbprofile.diff" Index: conf/options =================================================================== RCS file: /usr/local/cvsroot/freebsd/src/sys/conf/options,v retrieving revision 1.626 diff -d -u -r1.626 options --- conf/options 20 Apr 2008 20:35:35 -0000 1.626 +++ conf/options 29 Apr 2008 00:04:47 -0000 @@ -388,6 +388,7 @@ LIBMCHAIN LIBALIAS MBUF_STRESS_TEST +MBUF_PROFILING NCP NETATALK opt_atalk.h PPP_BSDCOMP opt_ppp.h Index: kern/uipc_mbuf.c =================================================================== RCS file: /usr/local/cvsroot/freebsd/src/sys/kern/uipc_mbuf.c,v retrieving revision 1.177 diff -d -u -r1.177 uipc_mbuf.c --- kern/uipc_mbuf.c 25 Mar 2008 09:38:59 -0000 1.177 +++ kern/uipc_mbuf.c 29 Apr 2008 00:04:53 -0000 @@ -35,6 +35,7 @@ #include "opt_mac.h" #include "opt_param.h" #include "opt_mbuf_stress_test.h" +#include "opt_mbuf_profiling.h" #include #include @@ -1938,3 +1939,118 @@ } return (m0); } + +#ifdef MBUF_PROFILING + +#define MP_BUCKETS 32 /* don't just change this things may overflow.*/ +struct mbufprofile { + u_int64_t wasted[MP_BUCKETS]; + u_int64_t used[MP_BUCKETS]; + u_int64_t segments[MP_BUCKETS]; +} mbprof; + +#define MP_MAXDIGITS 21 /* strlen("16,000,000,000,000,000,000") == 21 */ +#define MP_NUMLINES 6 +#define MP_NUMSPERLINE 16 +#define MP_EXTRABYTES 64 /* > strlen("used:\nwasted:\nsegments:\n") */ +/* work out max space needed and add a bit of spare space too */ +#define MP_MAXLINE ((MP_MAXDIGITS+1) * MP_NUMSPERLINE) +#define MP_BUFSIZE ((MP_MAXLINE * MP_NUMLINES) + 1 + MP_EXTRABYTES) + +char mbprofbuf[MP_BUFSIZE]; + +void +m_profile(struct mbuf *m) +{ + int segments = 0; + int used = 0; + int wasted = 0; + + while (m) { + segments++; + used += m->m_len; + if (m->m_flags & M_EXT) { + wasted += MHLEN - sizeof(m->m_ext) + + m->m_ext.ext_size - m->m_len; + } else { + if (m->m_flags & M_PKTHDR) + wasted += MHLEN - m->m_len; + else + wasted += MLEN - m->m_len; + } + m = m->m_next; + } + /* be paranoid.. it helps */ + if (segments > MP_BUCKETS - 1) + segments = MP_BUCKETS - 1; + if (used > 10000000) + used = 10000000; + if (wasted > 10000000) + wasted = 10000000; + /* store in the appropriate bucket */ + /* don't bother locking. if it's slightly off, so what? */ + mbprof.segments[segments]++; + mbprof.used[fls(used)]++; + mbprof.wasted[fls(wasted)]++; +} + +static void +mbprof_textify(void) +{ + int offset; + char *c; + u_int64_t *p; + + + p = &mbprof.wasted[0]; + c = mbprofbuf; + offset = snprintf(c, MP_MAXLINE + 10, + "wasted:\n%lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld\n", + p[0], p[1], p[2], p[3], p[4], p[5], p[6], p[7], + p[8], p[9], p[10], p[11], p[12], p[13], p[14], p[15]); + p = &mbprof.wasted[16]; + c += offset; + offset = snprintf(c, MP_MAXLINE, + "%lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld\n", + p[0], p[1], p[2], p[3], p[4], p[5], p[6], p[7], + p[8], p[9], p[10], p[11], p[12], p[13], p[14], p[15]); + p = &mbprof.used[0]; + c += offset; + offset = snprintf(c, MP_MAXLINE + 10, + "used:\n%lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld\n", + p[0], p[1], p[2], p[3], p[4], p[5], p[6], p[7], + p[8], p[9], p[10], p[11], p[12], p[13], p[14], p[15]); + p = &mbprof.used[16]; + c += offset; + offset = snprintf(c, MP_MAXLINE, + "%lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld\n", + p[0], p[1], p[2], p[3], p[4], p[5], p[6], p[7], + p[8], p[9], p[10], p[11], p[12], p[13], p[14], p[15]); + p = &mbprof.segments[0]; + c += offset; + offset = snprintf(c, MP_MAXLINE + 10, + "segments:\n%lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld\n", + p[0], p[1], p[2], p[3], p[4], p[5], p[6], p[7], + p[8], p[9], p[10], p[11], p[12], p[13], p[14], p[15]); + p = &mbprof.segments[16]; + c += offset; + offset = snprintf(c, MP_MAXLINE, + "%lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld\n", + p[0], p[1], p[2], p[3], p[4], p[5], p[6], p[7], + p[8], p[9], p[10], p[11], p[12], p[13], p[14], p[15]); +} + +static int +mbprof_handler(SYSCTL_HANDLER_ARGS) +{ + int error; + + mbprof_textify(); + error = SYSCTL_OUT(req, mbprofbuf, strlen(mbprofbuf) + 1); + return (error); +} + +SYSCTL_PROC(_kern_ipc, OID_AUTO, mbufprofile, CTLTYPE_STRING|CTLFLAG_RD, + NULL, 0, mbprof_handler, "S", "mbuf profiling statistics"); +#endif + Index: net/if_ethersubr.c =================================================================== RCS file: /usr/local/cvsroot/freebsd/src/sys/net/if_ethersubr.c,v retrieving revision 1.244 diff -d -u -r1.244 if_ethersubr.c --- net/if_ethersubr.c 20 Mar 2008 06:19:34 -0000 1.244 +++ net/if_ethersubr.c 29 Apr 2008 00:04:56 -0000 @@ -37,6 +37,7 @@ #include "opt_mac.h" #include "opt_netgraph.h" #include "opt_carp.h" +#include "opt_mbuf_profiling.h" #include #include @@ -162,6 +163,7 @@ senderr(error); #endif + M_PROFILE(m); if (ifp->if_flags & IFF_MONITOR) senderr(ENETDOWN); if (!((ifp->if_flags & IFF_UP) && Index: sys/mbuf.h =================================================================== RCS file: /usr/local/cvsroot/freebsd/src/sys/sys/mbuf.h,v retrieving revision 1.224 diff -d -u -r1.224 mbuf.h --- sys/mbuf.h 25 Mar 2008 09:39:02 -0000 1.224 +++ sys/mbuf.h 29 Apr 2008 00:04:57 -0000 @@ -959,4 +959,12 @@ #endif /* _KERNEL */ +#ifdef MBUF_PROFILING + void m_profile(struct mbuf *m); + #define M_PROFILE(m) m_profile(m) +#else + #define M_PROFILE(m) +#endif + + #endif /* !_SYS_MBUF_H_ */ --------------070206030204090107090604-- From owner-freebsd-net@FreeBSD.ORG Tue Apr 29 00:45:12 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23B051065681 for ; Tue, 29 Apr 2008 00:45:12 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.225]) by mx1.freebsd.org (Postfix) with ESMTP id DA2DD8FC0A for ; Tue, 29 Apr 2008 00:45:11 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so3363220rvf.43 for ; Mon, 28 Apr 2008 17:45:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=4ze4jwFxOLTdY2ZP9SlQnCDkrLxnv4sHPrBzf3KcftI=; b=P/St5xWS/uIJxIj+7Jtdx0kvzZeAZnT5Hxe6xhRzwwtMRIjkaFimODqWM9VTgKdhQkePDid47zWACtrK15D7MDUSFeDJaXkHPva+PPaCVRLsqjH3XULupq8EtHUNccIHXABWml2Te92omdkZ55jXDrehBMlT00tq1rgHMj0fsys= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=DgRcp/JcvOpD58zlV2EXOZesdKgAK9REzTP/coYnIoAZ4jQKLgkXagCUtttKEdJx4YS53gr/bCx1qvzJmKP7BDO7WeGDQtfA9tLoA/juwfBsZF69SPLTY99tymkcbzZbBWNT0I1opPKrtoXC+NSvgzEE7wLBfJ6TwXFR2BfAibU= Received: by 10.140.88.11 with SMTP id l11mr565435rvb.74.1209429911357; Mon, 28 Apr 2008 17:45:11 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id k2sm7800167rvb.6.2008.04.28.17.45.08 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 28 Apr 2008 17:45:10 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id m3T0j4Bg078358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Apr 2008 09:45:04 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m3T0j2WH078357; Tue, 29 Apr 2008 09:45:02 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Tue, 29 Apr 2008 09:45:02 +0900 From: Pyun YongHyeon To: Dewayne Geraghty Message-ID: <20080429004502.GB78140@cdnetworks.co.kr> References: <995276.92553.qm@web46006.mail.sp1.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <995276.92553.qm@web46006.mail.sp1.yahoo.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@FreeBSD.org Subject: Re: if_vge.c TX checksum errors on 6.3R-p2 7.0R-p1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2008 00:45:12 -0000 On Mon, Apr 28, 2008 at 02:19:17AM -0700, Dewayne Geraghty wrote: > Hi, I have four VIA motherboards each containing a vge0 device, three are misbehaving. > > On both the 7.0R-p1 and the 6.3Rp2 motherboards, the network cable needs to be unplugged and replugged into the motherboard, before ping will respond in either direction. The driver is issueing "incorrect" checksums during transmissions from the vge device, as observed from tcpdump -vvv. > > On 6.1R-p20 if_vge.c revision 1.14.2.7 is ok > On 6.3-p1 if_vge.c revision is 1.14.2.13 > On 7.0Rp1 if_vge.c revision is 1.31. > I don't see any changes that would break Tx checksum offload on 7.0R and 6.3R. By chance do you use VLAN? If you run tcpdump on Tx side(e.g. host with vge(4)) and see incorrect checksum it's completely normal(You should check the checksum on receiver). Hardware will insert computed checksum on the fly and tcpdump just see packets before the checksum insertion of hardware. > I'd like to know if other's have experiencing similar problems and which version of if_vge they had to go to as a quick workaround, unfortunately I can't revert to 6.1 as we really need 7.0R for the fantastic auditing and MAC enhancements. I'm happy to provide as much detail as needed to correct the problem - including ssh access to a crash burn machine (of course via an rl0 or vr0 NIC). > > The motherboard running 6.3R-p1 uses the VT6122 chip on a VT8237R Southbridge. (6.1R-p20 that works correctly uses this motherboard) > The motherboard running 7.0R-p1 is a VT6130 chipset on a VT8251 Southbridge. > > Regards, Dewayne. > -- Regards, Pyun YongHyeon From owner-freebsd-net@FreeBSD.ORG Tue Apr 29 00:48:12 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5DCE9106566B for ; Tue, 29 Apr 2008 00:48:12 +0000 (UTC) (envelope-from emaste@freebsd.org) Received: from gw.sandvine.com (gw.sandvine.com [199.243.201.138]) by mx1.freebsd.org (Postfix) with ESMTP id F30A88FC15 for ; Tue, 29 Apr 2008 00:48:11 +0000 (UTC) (envelope-from emaste@freebsd.org) Received: from labgw2.phaedrus.sandvine.com ([192.168.3.11]) by gw.sandvine.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Apr 2008 20:36:08 -0400 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 12627) id CE8D111707; Mon, 28 Apr 2008 20:36:08 -0400 (EDT) Date: Mon, 28 Apr 2008 20:36:08 -0400 From: Ed Maste To: freebsd-current@freebsd.org, freebsd-net@freebsd.org Message-ID: <20080429003608.GA11308@sandvine.com> References: <20080325200033.GA5444@sandvine.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080325200033.GA5444@sandvine.com> User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 29 Apr 2008 00:36:09.0042 (UTC) FILETIME=[04788B20:01C8A991] Cc: Subject: Re: panic: _mtx_lock_sleep: recursed on non-recursive mutex if_addr_mtx 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, 29 Apr 2008 00:48:12 -0000 On Tue, Mar 25, 2008 at 04:00:33PM -0400, Ed Maste wrote: > GENERIC CURRENT as of this morning. > > panic: _mtx_lock_sleep: recursed on non-recursive mutex if_addr_mtx @ /d2/emaste/HEAD/src/sys/netinet6/ip6_output.c:719 > ... > panic() at panic+0x176 > _mtx_lock_sleep() at _mtx_lock_sleep+0x181 > _mtx_lock_flags() at _mtx_lock_flags+0xe1 > ip6_output() at ip6_output+0xe98 > mld6_sendpkt() at mld6_sendpkt+0x204 > mld6_input() at mld6_input+0x55c > icmp6_input() at icmp6_input+0xf0b > ip6_input() at ip6_input+0xa6d > ... What happens here is that mld6_input() does IF_ADDR_LOCK() to be able to walk the address list, and then ends up needing to send a packet: mld6.c 268 void 269 mld6_input(struct mbuf *m, int off) ... 330 switch(mldh->mld_type) { 331 case MLD_LISTENER_QUERY: ... 371 IF_ADDR_LOCK(ifp); 372 TAILQ_FOREACH(ifma, &ifp->if_multiaddrs, ifma_link) { ... 387 mld6_sendpkt(in6m, MLD_LISTENER_REPORT, 388 NULL); ... 399 } 400 IF_ADDR_UNLOCK(ifp); And then mld6_sendpkt() calls ip6_output() which needs to take the if_addr_mtx at: ip6_output.c 719 IN6_LOOKUP_MULTI(ip6->ip6_dst, ifp, in6m); - Ed From owner-freebsd-net@FreeBSD.ORG Tue Apr 29 01:48:57 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 580C6106566C for ; Tue, 29 Apr 2008 01:48:57 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outK.internet-mail-service.net (outk.internet-mail-service.net [216.240.47.234]) by mx1.freebsd.org (Postfix) with ESMTP id 10D0D8FC16 for ; Tue, 29 Apr 2008 01:48:57 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Mon, 28 Apr 2008 23:43:47 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 6783B2D6017 for ; Mon, 28 Apr 2008 18:48:55 -0700 (PDT) Message-ID: <48167E87.40100@elischer.org> Date: Mon, 28 Apr 2008 18:48:55 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: FreeBSD Net References: <48166916.8090801@elischer.org> In-Reply-To: <48166916.8090801@elischer.org> Content-Type: multipart/mixed; boundary="------------080802020406040206010104" Subject: Re: mbuf usage in packets.. 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, 29 Apr 2008 01:48:57 -0000 This is a multi-part message in MIME format. --------------080802020406040206010104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Julian Elischer wrote: > > I wrote a cruddy little profiler to profile the packets being sent > on my system.. > after a bit of a live session including things like "ls -lR /usr" > [...] > > profiling diff attached.. > slightly imporved version that allows you to clear the stats without rebooting --------------080802020406040206010104 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="mbprofile.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="mbprofile.diff" Index: kern/uipc_mbuf.c =================================================================== RCS file: /usr/local/cvsroot/freebsd/src/sys/kern/uipc_mbuf.c,v retrieving revision 1.177 diff -u -r1.177 uipc_mbuf.c --- kern/uipc_mbuf.c 25 Mar 2008 09:38:59 -0000 1.177 +++ kern/uipc_mbuf.c 29 Apr 2008 01:45:06 -0000 @@ -35,6 +35,7 @@ #include "opt_mac.h" #include "opt_param.h" #include "opt_mbuf_stress_test.h" +#include "opt_mbuf_profiling.h" #include #include @@ -1938,3 +1939,139 @@ } return (m0); } + +#ifdef MBUF_PROFILING + +#define MP_BUCKETS 32 /* don't just change this things may overflow.*/ +struct mbufprofile { + u_int64_t wasted[MP_BUCKETS]; + u_int64_t used[MP_BUCKETS]; + u_int64_t segments[MP_BUCKETS]; +} mbprof; + +#define MP_MAXDIGITS 21 /* strlen("16,000,000,000,000,000,000") == 21 */ +#define MP_NUMLINES 6 +#define MP_NUMSPERLINE 16 +#define MP_EXTRABYTES 64 /* > strlen("used:\nwasted:\nsegments:\n") */ +/* work out max space needed and add a bit of spare space too */ +#define MP_MAXLINE ((MP_MAXDIGITS+1) * MP_NUMSPERLINE) +#define MP_BUFSIZE ((MP_MAXLINE * MP_NUMLINES) + 1 + MP_EXTRABYTES) + +char mbprofbuf[MP_BUFSIZE]; + +void +m_profile(struct mbuf *m) +{ + int segments = 0; + int used = 0; + int wasted = 0; + + while (m) { + segments++; + used += m->m_len; + if (m->m_flags & M_EXT) { + wasted += MHLEN - sizeof(m->m_ext) + + m->m_ext.ext_size - m->m_len; + } else { + if (m->m_flags & M_PKTHDR) + wasted += MHLEN - m->m_len; + else + wasted += MLEN - m->m_len; + } + m = m->m_next; + } + /* be paranoid.. it helps */ + if (segments > MP_BUCKETS - 1) + segments = MP_BUCKETS - 1; + if (used > 10000000) + used = 10000000; + if (wasted > 10000000) + wasted = 10000000; + /* store in the appropriate bucket */ + /* don't bother locking. if it's slightly off, so what? */ + mbprof.segments[segments]++; + mbprof.used[fls(used)]++; + mbprof.wasted[fls(wasted)]++; +} + +static void +mbprof_textify(void) +{ + int offset; + char *c; + u_int64_t *p; + + + p = &mbprof.wasted[0]; + c = mbprofbuf; + offset = snprintf(c, MP_MAXLINE + 10, + "wasted:\n%lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld\n", + p[0], p[1], p[2], p[3], p[4], p[5], p[6], p[7], + p[8], p[9], p[10], p[11], p[12], p[13], p[14], p[15]); + p = &mbprof.wasted[16]; + c += offset; + offset = snprintf(c, MP_MAXLINE, + "%lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld\n", + p[0], p[1], p[2], p[3], p[4], p[5], p[6], p[7], + p[8], p[9], p[10], p[11], p[12], p[13], p[14], p[15]); + p = &mbprof.used[0]; + c += offset; + offset = snprintf(c, MP_MAXLINE + 10, + "used:\n%lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld\n", + p[0], p[1], p[2], p[3], p[4], p[5], p[6], p[7], + p[8], p[9], p[10], p[11], p[12], p[13], p[14], p[15]); + p = &mbprof.used[16]; + c += offset; + offset = snprintf(c, MP_MAXLINE, + "%lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld\n", + p[0], p[1], p[2], p[3], p[4], p[5], p[6], p[7], + p[8], p[9], p[10], p[11], p[12], p[13], p[14], p[15]); + p = &mbprof.segments[0]; + c += offset; + offset = snprintf(c, MP_MAXLINE + 10, + "segments:\n%lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld\n", + p[0], p[1], p[2], p[3], p[4], p[5], p[6], p[7], + p[8], p[9], p[10], p[11], p[12], p[13], p[14], p[15]); + p = &mbprof.segments[16]; + c += offset; + offset = snprintf(c, MP_MAXLINE, + "%lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld %lld\n", + p[0], p[1], p[2], p[3], p[4], p[5], p[6], p[7], + p[8], p[9], p[10], p[11], p[12], p[13], p[14], p[15]); +} + +static int +mbprof_handler(SYSCTL_HANDLER_ARGS) +{ + int error; + + mbprof_textify(); + error = SYSCTL_OUT(req, mbprofbuf, strlen(mbprofbuf) + 1); + return (error); +} + +static int +mbprof_clr_handler(SYSCTL_HANDLER_ARGS) +{ + int clear, error; + + clear = 0; + error = sysctl_handle_int(oidp, &clear, 0, req); + if (error || !req->newptr) + return (error); + + if (clear) { + bzero(&mbprof, sizeof(mbprof)); + } + + return (error); +} + + +SYSCTL_PROC(_kern_ipc, OID_AUTO, mbufprofile, CTLTYPE_STRING|CTLFLAG_RD, + NULL, 0, mbprof_handler, "A", "mbuf profiling statistics"); + +SYSCTL_PROC(_kern_ipc, OID_AUTO, mbufprofileclr, CTLTYPE_INT|CTLFLAG_RW, + NULL, 0, mbprof_clr_handler, "I", "clear mbuf profiling statistics"); +#endif + Index: sys/mbuf.h =================================================================== RCS file: /usr/local/cvsroot/freebsd/src/sys/sys/mbuf.h,v retrieving revision 1.224 diff -u -r1.224 mbuf.h --- sys/mbuf.h 25 Mar 2008 09:39:02 -0000 1.224 +++ sys/mbuf.h 29 Apr 2008 01:45:06 -0000 @@ -959,4 +959,12 @@ #endif /* _KERNEL */ +#ifdef MBUF_PROFILING + void m_profile(struct mbuf *m); + #define M_PROFILE(m) m_profile(m) +#else + #define M_PROFILE(m) +#endif + + #endif /* !_SYS_MBUF_H_ */ Index: net/if_ethersubr.c =================================================================== RCS file: /usr/local/cvsroot/freebsd/src/sys/net/if_ethersubr.c,v retrieving revision 1.244 diff -u -r1.244 if_ethersubr.c --- net/if_ethersubr.c 20 Mar 2008 06:19:34 -0000 1.244 +++ net/if_ethersubr.c 29 Apr 2008 01:45:06 -0000 @@ -37,6 +37,7 @@ #include "opt_mac.h" #include "opt_netgraph.h" #include "opt_carp.h" +#include "opt_mbuf_profiling.h" #include #include @@ -162,6 +163,7 @@ senderr(error); #endif + M_PROFILE(m); if (ifp->if_flags & IFF_MONITOR) senderr(ENETDOWN); if (!((ifp->if_flags & IFF_UP) && --------------080802020406040206010104-- From owner-freebsd-net@FreeBSD.ORG Tue Apr 29 05:22:43 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2819F1065681 for ; Tue, 29 Apr 2008 05:22:43 +0000 (UTC) (envelope-from silby@silby.com) Received: from relay00.pair.com (relay00.pair.com [209.68.5.9]) by mx1.freebsd.org (Postfix) with SMTP id AE0FF8FC19 for ; Tue, 29 Apr 2008 05:22:42 +0000 (UTC) (envelope-from silby@silby.com) Received: (qmail 69325 invoked from network); 29 Apr 2008 04:56:01 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 29 Apr 2008 04:56:01 -0000 X-pair-Authenticated: 209.68.2.70 Date: Mon, 28 Apr 2008 23:56:01 -0500 (CDT) From: Mike Silbersack To: Julian Elischer In-Reply-To: <48167E87.40100@elischer.org> Message-ID: <20080428235142.N40789@odysseus.silby.com> References: <48166916.8090801@elischer.org> <48167E87.40100@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Net Subject: Re: mbuf usage in packets.. 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, 29 Apr 2008 05:22:43 -0000 On Mon, 28 Apr 2008, Julian Elischer wrote: >> >> profiling diff attached.. >> > > slightly imporved version that allows you to clear the stats without > rebooting I see an indentation glitch and a spelling error or two, but the general concept looks great! If you want to wait a few days, maybe I could get around to making those fixes for you. If not, I think it's safe to commit. -Mike From owner-freebsd-net@FreeBSD.ORG Tue Apr 29 07:44:20 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A3231065670 for ; Tue, 29 Apr 2008 07:44:20 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outC.internet-mail-service.net (outc.internet-mail-service.net [216.240.47.226]) by mx1.freebsd.org (Postfix) with ESMTP id F17E78FC20 for ; Tue, 29 Apr 2008 07:44:19 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Tue, 29 Apr 2008 06:00:00 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 3C7F52D600E for ; Tue, 29 Apr 2008 00:44:19 -0700 (PDT) Message-ID: <4816D1D2.7010603@elischer.org> Date: Tue, 29 Apr 2008 00:44:18 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: multiple routing tables review patch ready for simple testing. 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, 29 Apr 2008 07:44:20 -0000 The patch can be found at http://www.freebsd.org/~julian/mrt.diff (or http://www.freebsd.org/~julian/mrt6.diff for RELENG_6) or source can be taken from perforce at: //depot/user/julian/routing/src a kernel needs to be created with the option ROUTETABLES=N e.g. +options ROUTETABLES=2 # max 16. 1 is back compatible. leaving this out will result in just a single routing table as per normal. the max is 16 but I have an artificial (even lower) at 8 but that may be gone by the time people try it :-) I ws informed early in this project that kernel routing tables should now be refered to as FIBs (forwarding Information base?). the new command "setfib" sets teh default fib for a process and all its decendents The ipfw command has been enhanced with fib and setfib commands netstat has been tweaked to cope with >1 table if used with setfib.. ipfw and setfib have man pages to look at. e.g. root@trafmon2:setfib -2 netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire 127.0.0.1 127.0.0.1 UH 0 0 lo0 172.28.0.0/24 link#3 UC 0 0 fxp0 172.28.0.1 00:c0:9f:41:cd:3c UHLW 1 0 fxp0 1189 172.28.10.0/24 link#2 UC 0 0 bge1 root@trafmon2:setfib -0 netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 172.28.0.1 UGS 0 20 fxp0 10.1.1.209 172.28.0.1 UGHS 0 0 fxp0 127.0.0.1 127.0.0.1 UH 0 20 lo0 172.28.0.0/24 link#3 UC 0 0 fxp0 172.28.0.1 00:c0:9f:41:cd:3c UHLW 3 0 fxp0 1188 172.28.10.0/24 link#2 UC 0 0 bge1 root@trafmon2: Currently it is IPV4 ONLY (other protocols will ignore the existance of other tables) there are two new sysctls. net.my_fibnum: 0 net.fibs: 3 Give it a test drive if you have any reason to want to do policy based routing or have multiple ISPs for different workloads etc. I'd like to get it out to a wider audience. all comments welcome. please read the file http://perforce.freebsd.org/fileViewer.cgi?FSPC=//depot/user/julian/routing/plan.txt&REV=5 for notes before using it. Julian From owner-freebsd-net@FreeBSD.ORG Tue Apr 29 08:20:04 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E213F106566C for ; Tue, 29 Apr 2008 08:20:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id CB8A98FC39 for ; Tue, 29 Apr 2008 08:20:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m3T8K4sD069989 for ; Tue, 29 Apr 2008 08:20:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m3T8K4I3069988; Tue, 29 Apr 2008 08:20:04 GMT (envelope-from gnats) Date: Tue, 29 Apr 2008 08:20:04 GMT Message-Id: <200804290820.m3T8K4I3069988@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Gavin Atkinson Cc: Subject: [Fwd: RE: kern/123166: [re] CARP messages filtered by Realtek driver on > 6.2] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Gavin Atkinson List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2008 08:20:05 -0000 The following reply was made to PR kern/123166; it has been noted by GNATS. From: Gavin Atkinson To: bug-followup@FreeBSD.org Cc: Subject: [Fwd: RE: kern/123166: [re] CARP messages filtered by Realtek driver on > 6.2] Date: Tue, 29 Apr 2008 09:13:29 +0100 -------- Forwarded Message -------- From: Auke Zaaiman Date: Mon, 28 Apr 2008 22:27:32 +0200 Hi, Below the output of pciconf -l: re0@pci0:8:0: class=0x020000 card=0x816910ec chip=0x816910ec rev=0x10 hdr=0x00 re1@pci0:9:0: class=0x020000 card=0x816910ec chip=0x816910ec rev=0x10 hdr=0x00 And yes, we are able and willing to establish exactly which change has broken the card. Can you give me details on where I can fetch the source I need to update to? From owner-freebsd-net@FreeBSD.ORG Tue Apr 29 10:02:37 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40F20106566B for ; Tue, 29 Apr 2008 10:02:37 +0000 (UTC) (envelope-from yoniy@mellanox.co.il) Received: from mellanox.co.il (mail.mellanox.co.il [194.90.237.43]) by mx1.freebsd.org (Postfix) with ESMTP id 1FB8B8FC12 for ; Tue, 29 Apr 2008 10:02:35 +0000 (UTC) (envelope-from yoniy@mellanox.co.il) Received: from Internal Mail-Server by MTLPINE1 (envelope-from yoniy@mellanox.co.il) with SMTP; 29 Apr 2008 12:35:52 +0300 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 29 Apr 2008 12:35:51 +0300 Message-ID: <6C2C79E72C305246B504CBA17B5500C903E6C3B1@mtlexch01.mtl.com> In-Reply-To: <48160770.2080509@tomjudge.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OS throws away large packets Thread-Index: AcipVDsANurcsXo+RzKO3aKAgW4uUgAelKmA From: "Yehonatan Yossef" To: "Tom Judge" , "Mr Y" Cc: freebsd-net@freebsd.org, freebsd-questions@freebsd.org, Liran Liss Subject: RE: OS throws away large packets 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, 29 Apr 2008 10:02:37 -0000 =20 > -----Original Message----- > From: Tom Judge [mailto:tom@tomjudge.com]=20 > Sent: Monday, April 28, 2008 8:21 PM > To: Mr Y > Cc: freebsd-questions@freebsd.org; freebsd-net@freebsd.org > Subject: Re: OS throws away large packets >=20 > Mr Y wrote: > > Hi all, > >=20 > > I'm trying to implement Large Recieve Offload for an=20 > Ethernet driver=20 > > on FreeBSD 6.3, but all my >MTU packets are being thrown by the OS. > > I'm using mbuf chains in this imlpementation, each mbuf is=20 > a cluster=20 > > of MCLBYTES bytes. They are linked by the m_next pointer. > > The first packet being thrown away is 2945 bytes long.=20 > Wireshark shows=20 > > the packet that is being passed to the OS is correct. > >=20 > > Do I need to set some OS parameter to make it recieve mbuf chains? > >=20 > > Please help. > >=20 >=20 > Hi Yony, >=20 > I seem to remember some discussion about this list last year=20 > see the following threads: >=20 > http://lists.freebsd.org/pipermail/freebsd-net/2007-September/015250.htm l > http://lists.freebsd.org/pipermail/freebsd-net/2007-September/015350.htm l > >From my limited reading of these threads just now and possibly bad memory. It would seem that the MRU to MTU relationship is defined in the nic driver rather than=20 > enforced further up the stack or at least that seamed to be the case with the bce driver. > >Hope this is helpful, >=20 > Tom Hi Tom, >From what I understand these threads are referring to the bce hardware configuration (bus configuration) and driver mbuf allocation size. Am I correct? In my case I'm not trying to receive packets >MTU from the HW, but to chain mbuf clusters, each is MCLBYTES long, and pass the mbuf chain to the OS. Since tcpdump (analyzed by wireshark) catches the packets above the driver and reports a good packet (and 2945 bytes long), I assume my driver functionality is ok. From what I know tcpdump is supposed to immitate the way the stack sees the packet, yet it is discarded. My logic says there is an OS parameter handled by the driver (at net device init time for example) that will set the OS to receive large mbuf chains, or a kernel tcp parameter. Is the tcp stack submitted to the mtu somehow? Yony From owner-freebsd-net@FreeBSD.ORG Tue Apr 29 16:17:19 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB2EC1065686; Tue, 29 Apr 2008 16:17:19 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 5AD478FC19; Tue, 29 Apr 2008 16:17:19 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m3TGHHLE048179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Apr 2008 09:17:18 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <48174A0D.1090302@freebsd.org> Date: Tue, 29 Apr 2008 09:17:17 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: Yehonatan Yossef References: <6C2C79E72C305246B504CBA17B5500C903E6C3B1@mtlexch01.mtl.com> In-Reply-To: <6C2C79E72C305246B504CBA17B5500C903E6C3B1@mtlexch01.mtl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC--Metrics: ebb.errno.com; whitelist Cc: Tom Judge , freebsd-net@freebsd.org, Liran Liss , freebsd-questions@freebsd.org, Mr Y Subject: Re: OS throws away large packets 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, 29 Apr 2008 16:17:19 -0000 Yehonatan Yossef wrote: > > > >> -----Original Message----- >> From: Tom Judge [mailto:tom@tomjudge.com] >> Sent: Monday, April 28, 2008 8:21 PM >> To: Mr Y >> Cc: freebsd-questions@freebsd.org; freebsd-net@freebsd.org >> Subject: Re: OS throws away large packets >> >> Mr Y wrote: >> >>> Hi all, >>> >>> I'm trying to implement Large Recieve Offload for an >>> >> Ethernet driver >> >>> on FreeBSD 6.3, but all my >MTU packets are being thrown by the OS. >>> I'm using mbuf chains in this imlpementation, each mbuf is >>> >> a cluster >> >>> of MCLBYTES bytes. They are linked by the m_next pointer. >>> The first packet being thrown away is 2945 bytes long. >>> >> Wireshark shows >> >>> the packet that is being passed to the OS is correct. >>> >>> Do I need to set some OS parameter to make it recieve mbuf chains? >>> >>> Please help. >>> >>> >> Hi Yony, >> >> I seem to remember some discussion about this list last year >> see the following threads: >> >> >> > http://lists.freebsd.org/pipermail/freebsd-net/2007-September/015250.htm > l > > http://lists.freebsd.org/pipermail/freebsd-net/2007-September/015350.htm > l > > >From my limited reading of these threads just now and possibly bad > memory. It would seem that the MRU to MTU relationship is defined in > the nic driver rather than > >> enforced further up the stack or at least that seamed to be the case >> > with the bce driver. > >> Hope this is helpful, >> >> Tom >> > > Hi Tom, > > >From what I understand these threads are referring to the bce hardware > configuration (bus configuration) and driver mbuf allocation size. Am I > correct? > In my case I'm not trying to receive packets >MTU from the HW, but to > chain mbuf clusters, each is MCLBYTES long, and pass the mbuf chain to > the OS. > Since tcpdump (analyzed by wireshark) catches the packets above the > driver and reports a good packet (and 2945 bytes long), I assume my > driver functionality is ok. From what I know tcpdump is supposed to > immitate the way the stack sees the packet, yet it is discarded. > My logic says there is an OS parameter handled by the driver (at net > device init time for example) that will set the OS to receive large mbuf > chains, or a kernel tcp parameter. Is the tcp stack submitted to the mtu > somehow? > > I don't see where you've identified what version of the os you're working with. There's a check in the 802.3 input path on earlier systems to discard frames >mtu. This was removed not too long ago with LRO in mind; check the history of sys/net/if_ethersubr.c. Sam From owner-freebsd-net@FreeBSD.ORG Tue Apr 29 17:14:23 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D46D106567C for ; Tue, 29 Apr 2008 17:14:23 +0000 (UTC) (envelope-from yoniy@mellanox.co.il) Received: from mellanox.co.il (mail.mellanox.co.il [194.90.237.43]) by mx1.freebsd.org (Postfix) with ESMTP id A8D4F8FC29 for ; Tue, 29 Apr 2008 17:14:21 +0000 (UTC) (envelope-from yoniy@mellanox.co.il) Received: from Internal Mail-Server by MTLPINE1 (envelope-from yoniy@mellanox.co.il) with SMTP; 29 Apr 2008 20:14:19 +0300 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 29 Apr 2008 20:14:18 +0300 Message-ID: <6C2C79E72C305246B504CBA17B5500C903E6C7C2@mtlexch01.mtl.com> In-Reply-To: <48174A0D.1090302@freebsd.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OS throws away large packets Thread-Index: AciqFIJUKNp79jeiTzOP/GeIbmc3CwAAR8ig From: "Yehonatan Yossef" To: "Sam Leffler" Cc: Tom Judge , freebsd-net@freebsd.org, Liran Liss , freebsd-questions@freebsd.org, Mr Y Subject: RE: OS throws away large packets 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, 29 Apr 2008 17:14:23 -0000 =20 > -----Original Message----- > From: Sam Leffler [mailto:sam@freebsd.org]=20 > Sent: Tuesday, April 29, 2008 7:17 PM > To: Yehonatan Yossef > Cc: Tom Judge; Mr Y; freebsd-net@freebsd.org;=20 > freebsd-questions@freebsd.org; Liran Liss > Subject: Re: OS throws away large packets >=20 > Yehonatan Yossef wrote: > > =20 > > > > =20 > >> -----Original Message----- > >> From: Tom Judge [mailto:tom@tomjudge.com] > >> Sent: Monday, April 28, 2008 8:21 PM > >> To: Mr Y > >> Cc: freebsd-questions@freebsd.org; freebsd-net@freebsd.org > >> Subject: Re: OS throws away large packets > >> > >> Mr Y wrote: > >> =20 > >>> Hi all, > >>> > >>> I'm trying to implement Large Recieve Offload for an > >>> =20 > >> Ethernet driver > >> =20 > >>> on FreeBSD 6.3, but all my >MTU packets are being thrown=20 > by the OS. > >>> I'm using mbuf chains in this imlpementation, each mbuf is > >>> =20 > >> a cluster > >> =20 > >>> of MCLBYTES bytes. They are linked by the m_next pointer. > >>> The first packet being thrown away is 2945 bytes long.=20 > >>> =20 > >> Wireshark shows > >> =20 > >>> the packet that is being passed to the OS is correct. > >>> > >>> Do I need to set some OS parameter to make it recieve mbuf chains? > >>> > >>> Please help. > >>> > >>> =20 > >> Hi Yony, > >> > >> I seem to remember some discussion about this list last=20 > year see the=20 > >> following threads: > >> > >> > >> =20 > >=20 > http://lists.freebsd.org/pipermail/freebsd-net/2007-September/015250.h > > tm > > l > > =20 > >=20 > http://lists.freebsd.org/pipermail/freebsd-net/2007-September/015350.h > > tm > > l > > =20 > > >From my limited reading of these threads just now and possibly bad > > memory. It would seem that the MRU to MTU relationship is=20 > defined in=20 > > the nic driver rather than > > =20 > >> enforced further up the stack or at least that seamed to=20 > be the case > >> =20 > > with the bce driver. > > =20 > >> Hope this is helpful, > >> > >> Tom > >> =20 > > > > Hi Tom, > > > > >From what I understand these threads are referring to the bce=20 > > >hardware > > configuration (bus configuration) and driver mbuf=20 > allocation size. Am=20 > > I correct? > > In my case I'm not trying to receive packets >MTU from the=20 > HW, but to=20 > > chain mbuf clusters, each is MCLBYTES long, and pass the=20 > mbuf chain to=20 > > the OS. > > Since tcpdump (analyzed by wireshark) catches the packets above the=20 > > driver and reports a good packet (and 2945 bytes long), I assume my=20 > > driver functionality is ok. From what I know tcpdump is supposed to=20 > > immitate the way the stack sees the packet, yet it is discarded. > > My logic says there is an OS parameter handled by the=20 > driver (at net=20 > > device init time for example) that will set the OS to receive large=20 > > mbuf chains, or a kernel tcp parameter. Is the tcp stack=20 > submitted to=20 > > the mtu somehow? > > > > =20 > I don't see where you've identified what version of the os=20 > you're working with. There's a check in the 802.3 input path=20 > on earlier systems to discard frames >mtu. This was removed=20 > not too long ago with LRO in mind; check the history of=20 > sys/net/if_ethersubr.c. >=20 > Sam >=20 Hi Sam, I have mentioned working on 6.3. FreeBSD 6.2 had this check in if_ethersubr.c / ether_input: 539 if (m->m_pkthdr.len > 540 ETHER_MAX_FRAME(ifp, etype, m->m_flags & M_HASFCS)) { 541 if_printf(ifp, "discard oversize frame " 542 "(ether type %x flags %x len %u > max %lu)\n", 543 etype, m->m_flags, m->m_pkthdr.len, 544 ETHER_MAX_FRAME(ifp, etype, 545 m->m_flags & M_HASFCS)); 546 ifp->if_ierrors++; 547 m_freem(m); 548 return; 549 } Patching it was explained by neterion in http://trac.neterion.com/cgi-bin/trac.cgi/wiki/FreeBSD. This check no longer exists in 6.3, nor any other oversize packet handling (I couldn't find any so far). I also get no error prints from the OS. From owner-freebsd-net@FreeBSD.ORG Tue Apr 29 17:14:59 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A89011065676 for ; Tue, 29 Apr 2008 17:14: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 90F3C8FC16 for ; Tue, 29 Apr 2008 17:14:59 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Tue, 29 Apr 2008 15:30:44 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 6A9EA2D6015; Tue, 29 Apr 2008 10:14:58 -0700 (PDT) Message-ID: <48175793.30606@elischer.org> Date: Tue, 29 Apr 2008 10:14:59 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: "Wilkinson, Alex" , FreeBSD Net References: <48134DDE.9010306@elischer.org> <20080429084032.GW71371@stlux503.dsto.defence.gov.au> In-Reply-To: <20080429084032.GW71371@stlux503.dsto.defence.gov.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Multiple routing tables in action... 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, 29 Apr 2008 17:14:59 -0000 Wilkinson, Alex wrote: > 0n Sat, Apr 26, 2008 at 08:44:30AM -0700, Julian Elischer wrote: > > >A little progress report > >From a recently installed (6.3) machine.... (plus patches) > > Ok, being ignorant to this, possibly a silly question: > > Why would i want or need multiple routing tables ? any time you wnat to base a route upon something other than just the destination address. It's basically called "Policy based routing". Trivial examples: You have two ISPs and you want to send all SMTP via one link and all other traffic via the other. You have 3 ISPs and want all traffic from the accounting department to go via a particular path (that is encrypted) but regular office chatter to go via another. I have other more complex examples in my work. I'm sure others have more solid examples as well. google for policy routing. From owner-freebsd-net@FreeBSD.ORG Tue Apr 29 17:18:20 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BFDD1065673 for ; Tue, 29 Apr 2008 17:18:20 +0000 (UTC) (envelope-from yoniy@mellanox.co.il) Received: from mellanox.co.il (mail.mellanox.co.il [194.90.237.43]) by mx1.freebsd.org (Postfix) with ESMTP id 99FB18FC19 for ; Tue, 29 Apr 2008 17:18:19 +0000 (UTC) (envelope-from yoniy@mellanox.co.il) Received: from Internal Mail-Server by MTLPINE1 (envelope-from yoniy@mellanox.co.il) with SMTP; 29 Apr 2008 20:18:18 +0300 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 29 Apr 2008 20:18:17 +0300 Message-ID: <6C2C79E72C305246B504CBA17B5500C903E6C7C6@mtlexch01.mtl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: OS throws away large packets Thread-Index: AciqHQPHKo0i2sbEQwOQ0ytUrodH6g== From: "Yehonatan Yossef" To: "Sam Leffler" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, freebsd-questions@freebsd.org, Liran Liss Subject: RE: OS throws away large packets 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, 29 Apr 2008 17:18:20 -0000 > >>> Hi all, > >>> > >>> I'm trying to implement Large Recieve Offload for an > >>> =20 > >> Ethernet driver > >> =20 > >>> on FreeBSD 6.3, but all my >MTU packets are being thrown > by the OS. > >>> I'm using mbuf chains in this imlpementation, each mbuf is > >>> =20 > >> a cluster > >> =20 > >>> of MCLBYTES bytes. They are linked by the m_next pointer. > >>> The first packet being thrown away is 2945 bytes long.=20 > >>> =20 > >> Wireshark shows > >> =20 > >>> the packet that is being passed to the OS is correct. > >>> > >>> Do I need to set some OS parameter to make it recieve mbuf chains? > >>> > >>> Please help. > >>> > >>> =20 > >> Hi Yony, > >> > >> I seem to remember some discussion about this list last > year see the > >> following threads: > >> > >> > >> =20 > >=20 > http://lists.freebsd.org/pipermail/freebsd-net/2007-September/015250.htm l > > =20 > >=20 > http://lists.freebsd.org/pipermail/freebsd-net/2007-September/015350.htm l > > =20 > > >From my limited reading of these threads just now and possibly bad > > memory. It would seem that the MRU to MTU relationship is > defined in > > the nic driver rather than > > =20 > >> enforced further up the stack or at least that seamed to > be the case > >> =20 > > with the bce driver. > > =20 > >> Hope this is helpful, > >> > >> Tom > >> =20 > > > > Hi Tom, > > > > >From what I understand these threads are referring to the bce=20 > > >hardware > > configuration (bus configuration) and driver mbuf > allocation size. Am > > I correct? > > In my case I'm not trying to receive packets >MTU from the > HW, but to > > chain mbuf clusters, each is MCLBYTES long, and pass the > mbuf chain to > > the OS. > > Since tcpdump (analyzed by wireshark) catches the packets above the=20 > > driver and reports a good packet (and 2945 bytes long), I assume my=20 > > driver functionality is ok. From what I know tcpdump is supposed to=20 > > immitate the way the stack sees the packet, yet it is discarded. > > My logic says there is an OS parameter handled by the > driver (at net > > device init time for example) that will set the OS to receive large=20 > > mbuf chains, or a kernel tcp parameter. Is the tcp stack > submitted to > > the mtu somehow? > > > > =20 > I don't see where you've identified what version of the os you're=20 > working with. There's a check in the 802.3 input path on earlier=20 > systems to discard frames >mtu. This was removed not too long ago=20 > with LRO in mind; check the history of sys/net/if_ethersubr.c. >=20 > Sam >=20 =20 Hi Sam, I have mentioned working on 6.3. =20 FreeBSD 6.2 had this check in if_ethersubr.c / ether_input: =20 539 if (m->m_pkthdr.len > 540 ETHER_MAX_FRAME(ifp, etype, m->m_flags & M_HASFCS)) { 541 if_printf(ifp, "discard oversize frame " 542 "(ether type %x flags %x len %u > max %lu)\n", 543 etype, m->m_flags, m->m_pkthdr.len, 544 ETHER_MAX_FRAME(ifp, etype, 545 m->m_flags & M_HASFCS)); 546 ifp->if_ierrors++; 547 m_freem(m); 548 return; 549 } =20 Patching it was explained by neterion in http://trac.neterion.com/cgi-bin/trac.cgi/wiki/FreeBSD. This check no longer exists in 6.3, nor any other oversize packet handling (I couldn't find any so far). I also get no error prints from the OS. =20 =20 From owner-freebsd-net@FreeBSD.ORG Tue Apr 29 17:25:16 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83DAA106567B for ; Tue, 29 Apr 2008 17:25:16 +0000 (UTC) (envelope-from agile.quad@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.242]) by mx1.freebsd.org (Postfix) with ESMTP id 3DE318FC19 for ; Tue, 29 Apr 2008 17:25:15 +0000 (UTC) (envelope-from agile.quad@gmail.com) Received: by an-out-0708.google.com with SMTP id b8so24126ana.13 for ; Tue, 29 Apr 2008 10:25:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=Dl/hDnKGbjZ/ENbmrIl1q1E0bktbvU0asdl1LJfIQt0=; b=IRaUfe0bfAEq7TYBJkCnnfYQHPjPDsEk1HEbldXFzdL8CXRTcuKNcagd19q3U38ys8MdhknNaLn8TfDyMMRRGVt+P35mOlBigLPAMPgxrcCWUEEg2RGoZbslu7YeqzblcA8Ci6hQaqOiM4RmHM8ZuMiPCP+woW2cnlUzObsdWOg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=mn9aaaywpBaiTNzIF9gEkqORmpFIpdK1WpUwvsQyZOx7kgf8GwCp5GRQcz32ytXYdCES11vUQ4I94zBYbbENHArRuJiaNL9Q5METDRjEthET/Ug3bXo/rMVKuaAiOOBkocupjKmDWD9KQbj3yZKc62NSboVpYY2IAMAvKxtNM6s= Received: by 10.100.241.17 with SMTP id o17mr1727420anh.4.1209489914835; Tue, 29 Apr 2008 10:25:14 -0700 (PDT) Received: by 10.100.211.16 with HTTP; Tue, 29 Apr 2008 10:25:13 -0700 (PDT) Message-ID: Date: Tue, 29 Apr 2008 20:25:13 +0300 From: Oleg To: pyunyh@gmail.com In-Reply-To: <20080417003713.GA28522@cdnetworks.co.kr> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_19208_11845697.1209489914812" References: <1733112647.20080417004353@gmail.com> <20080417003713.GA28522@cdnetworks.co.kr> Cc: freebsd-net@freebsd.org Subject: Re: [bfe] [panic] Serious error: bfe failed to map RX buffer 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, 29 Apr 2008 17:25:16 -0000 ------=_Part_19208_11845697.1209489914812 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, sorry for long delay, was too busy. So, I recheck return code of bus_dmamap_load(9) and its exactly ENOMEM. Here are fresh patch with your suggestions (diff with HEAD) Best Regards, Oleg Dolgov. 2008/4/17, Pyun YongHyeon : > On Thu, Apr 17, 2008 at 12:43:53AM +0300, quad wrote: > > Hi, > > > > FreeBSD amd64 7.0-RELEASE, ULE, SMP. > > > > On heavy loads bfe network driver after few messages > > > > Serious error: bfe failed to map RX buffer > > Serious error: bfe failed to map RX buffer > > Serious error: bfe failed to map RX buffer > > ... > > > > make kernel panic. > > > > Here patch. > > > > > It would be even better if you can show me the return code of > bus_dmamap_load(9). If the error code is not ENOMEM it requires > more bus_dma(9) clean up(bfe(4) needs lots of bus_dma(9) fixing > and I had no time so far.) > Since the caller of bfe_list_newbuf() expects 0 or ENOBUFS it would > be even better to return ENOBUFS for failure case instead of > returning error code of bus_dmamap_load(9). > > -- > Regards, > > Pyun YongHyeon > ------=_Part_19208_11845697.1209489914812 Content-Type: application/octet-stream; name=if_bfe.diff Content-Transfer-Encoding: base64 X-Attachment-Id: f_ffmqch8w Content-Disposition: attachment; filename=if_bfe.diff LS0tIC9ob21lL2FnaWxlL1Byb2plY3RzL2Fub25jdnMvc3JjL3N5cy9kZXYvYmZlL2lmX2JmZS5j CTIwMDgtMDMtMTggMDQ6MTE6NDAuMDAwMDAwMDAwICswMjAwCisrKyBpZl9iZmUuYwkyMDA4LTA0 LTI5IDE5OjU1OjI3LjAwMDAwMDAwMCArMDMwMApAQCAtNjQ3LDExICs2NDcsMTIgQEAKIAlzdHJ1 Y3QgYmZlX2RhdGEgKnI7CiAJdV9pbnQzMl90IGN0cmw7CiAJaW50IGVycm9yOworCWludCBhbGxv Y2F0ZWQ7CiAKIAlpZiAoKGMgPCAwKSB8fCAoYyA+PSBCRkVfUlhfTElTVF9DTlQpKQogCQlyZXR1 cm4gKEVJTlZBTCk7CiAKLQlpZihtID09IE5VTEwpIHsKKwlpZigoYWxsb2NhdGVkID0gKG0gPT0g TlVMTCkpKSB7CiAJCW0gPSBtX2dldGNsKE1fRE9OVFdBSVQsIE1UX0RBVEEsIE1fUEtUSERSKTsK IAkJaWYobSA9PSBOVUxMKQogCQkJcmV0dXJuIChFTk9CVUZTKTsKQEAgLTY3MCw4ICs2NzEsMTMg QEAKIAlyID0gJnNjLT5iZmVfcnhfcmluZ1tjXTsKIAllcnJvciA9IGJ1c19kbWFtYXBfbG9hZChz Yy0+YmZlX3RhZywgci0+YmZlX21hcCwgbXRvZChtLCB2b2lkICopLAogCQkJTUNMQllURVMsIGJm ZV9kbWFfbWFwX2Rlc2MsIGQsIEJVU19ETUFfTk9XQUlUKTsKLQlpZiAoZXJyb3IpCi0JCXByaW50 ZigiU2VyaW91cyBlcnJvcjogYmZlIGZhaWxlZCB0byBtYXAgUlggYnVmZmVyXG4iKTsKKwlpZiAo ZXJyb3IpIHsKKwkJaWYgKGFsbG9jYXRlZCkKKwkJCW1fZnJlZShtKTsKKwkJaWYgKGVycm9yICE9 IEVOT01FTSkKKwkJCXByaW50ZigiU2VyaW91cyBlcnJvcjogYmZlIGZhaWxlZCB0byBtYXAgUlgg YnVmZmVyLCBlcnJvciAlZFxuIiwgZXJyb3IpOworCQlyZXR1cm4gKEVOT0JVRlMpOworCX0KIAli dXNfZG1hbWFwX3N5bmMoc2MtPmJmZV90YWcsIHItPmJmZV9tYXAsIEJVU19ETUFTWU5DX1BSRVdS SVRFKTsKIAogCWN0cmwgPSBFVEhFUl9NQVhfTEVOICsgMzI7Cg== ------=_Part_19208_11845697.1209489914812-- From owner-freebsd-net@FreeBSD.ORG Tue Apr 29 17:30:30 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39E52106564A for ; Tue, 29 Apr 2008 17:30:30 +0000 (UTC) (envelope-from paul@gtcomm.net) Received: from gtcomm.net (web.gtcomm.net [72.10.164.67]) by mx1.freebsd.org (Postfix) with ESMTP id F01EB8FC0C for ; Tue, 29 Apr 2008 17:30:29 +0000 (UTC) (envelope-from paul@gtcomm.net) Received: from [192.168.1.8] (c-76-108-179-28.hsd1.fl.comcast.net [76.108.179.28]) by gtcomm.net (8.12.20/8.12.10) with ESMTP id m3THUKwL002614; Tue, 29 Apr 2008 14:30:20 -0300 Message-ID: <48175B91.1010202@gtcomm.net> Date: Tue, 29 Apr 2008 13:32:01 -0400 From: Paul User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Julian Elischer References: <48134DDE.9010306@elischer.org> <20080429084032.GW71371@stlux503.dsto.defence.gov.au> <48175793.30606@elischer.org> In-Reply-To: <48175793.30606@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , "Wilkinson, Alex" Subject: Re: Multiple routing tables in action... 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, 29 Apr 2008 17:30:30 -0000 I've been waiting for something like this. Linux has done policy routing for many many years and is very good at it. I prefer to use FreeBSD for routing though and this is a feature I have been waiting for :) Mainly to use with BGP , having multiple BGP routing tables. I would like it to be similar to Cisco's VRF or Juniper's routing instance, but maybe that's asking too much. We use it on our hardware routers for implementations such as having multiple bgp route tables and having customer bandwidth pricing change based on which routing table their traffic gets , say.. value customers, premium customers, customers who want only certain carriers in their bandwidth mix, etc. Would be fun to have support for FBSD with quagga/openbgpd etc.. and be able to use dscp for marking or any other policy based rule (source ip for instance). Thanks Julian.. This is a step forward in the right direction :) Julian Elischer wrote: > Wilkinson, Alex wrote: >> 0n Sat, Apr 26, 2008 at 08:44:30AM -0700, Julian Elischer wrote: >> >A little progress report >> >From a recently installed (6.3) machine.... (plus patches) >> >> Ok, being ignorant to this, possibly a silly question: >> >> Why would i want or need multiple routing tables ? > > any time you wnat to base a route upon something other than just > the destination address. It's basically called "Policy based > routing". > > > Trivial examples: > You have two ISPs and you want to send all SMTP via one link and > all other traffic via the other. > > You have 3 ISPs and want all traffic from the accounting department > to go via a particular path (that is encrypted) but regular office > chatter to go via another. > > I have other more complex examples in my work. > > I'm sure others have more solid examples as well. > > google for policy routing. > _______________________________________________ > 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 Tue Apr 29 18:19:13 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E67811065686 for ; Tue, 29 Apr 2008 18:19:13 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outC.internet-mail-service.net (outc.internet-mail-service.net [216.240.47.226]) by mx1.freebsd.org (Postfix) with ESMTP id CC03F8FC2D for ; Tue, 29 Apr 2008 18:19:13 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Tue, 29 Apr 2008 16:35:01 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 3CA812D6011; Tue, 29 Apr 2008 11:19:13 -0700 (PDT) Message-ID: <481766A2.7040809@elischer.org> Date: Tue, 29 Apr 2008 11:19:14 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Paul References: <48134DDE.9010306@elischer.org> <20080429084032.GW71371@stlux503.dsto.defence.gov.au> <48175793.30606@elischer.org> <48175B91.1010202@gtcomm.net> In-Reply-To: <48175B91.1010202@gtcomm.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , "Wilkinson, Alex" Subject: Re: Multiple routing tables in action... 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, 29 Apr 2008 18:19:14 -0000 Paul wrote: > I've been waiting for something like this. Linux has done policy > routing for many many years and is very good at it. I prefer to use > FreeBSD for routing though and this is a feature I have been waiting for :) > Mainly to use with BGP , having multiple BGP routing tables. I would > like it to be similar to Cisco's VRF or Juniper's routing instance, but > maybe that's asking too much. We use it on our hardware routers for > implementations such as having multiple bgp route tables and having > customer bandwidth pricing change based on which routing table their > traffic gets , say.. value customers, premium customers, customers who > want only certain carriers in their bandwidth mix, etc. Would be fun > to have support for FBSD with quagga/openbgpd etc.. and be able to use > dscp for marking or any other policy based rule (source ip for instance). > > Thanks Julian.. This is a step forward in the right direction :) The interaction with routing daemons is something I don't know enough about. I need someone who knows routing daemons to tell how to correctly tweek code that sends routing events. I think it is possible that events from a particular FIB should only be reported to routing sockets that are associated with that FIB. but I'm not sure about this. This would mean running a separate instance of the routing daemon for each FIB (VRF?). Does this sound right to people? > > > Julian Elischer wrote: >> Wilkinson, Alex wrote: >>> 0n Sat, Apr 26, 2008 at 08:44:30AM -0700, Julian Elischer wrote: >>> >A little progress report >>> >From a recently installed (6.3) machine.... (plus patches) >>> >>> Ok, being ignorant to this, possibly a silly question: >>> >>> Why would i want or need multiple routing tables ? >> >> any time you wnat to base a route upon something other than just >> the destination address. It's basically called "Policy based >> routing". >> >> >> Trivial examples: >> You have two ISPs and you want to send all SMTP via one link and >> all other traffic via the other. >> >> You have 3 ISPs and want all traffic from the accounting department >> to go via a particular path (that is encrypted) but regular office >> chatter to go via another. >> >> I have other more complex examples in my work. >> >> I'm sure others have more solid examples as well. >> >> google for policy routing. >> _______________________________________________ >> 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 Tue Apr 29 18:46:38 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD360106567A; Tue, 29 Apr 2008 18:46:38 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7AE428FC12; Tue, 29 Apr 2008 18:46:38 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (gavin@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m3TIkcmC030413; Tue, 29 Apr 2008 18:46:38 GMT (envelope-from gavin@freefall.freebsd.org) Received: (from gavin@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m3TIkcxj030409; Tue, 29 Apr 2008 18:46:38 GMT (envelope-from gavin) Date: Tue, 29 Apr 2008 18:46:38 GMT Message-Id: <200804291846.m3TIkcxj030409@freefall.freebsd.org> To: gavin@FreeBSD.org, freebsd-net@FreeBSD.org, gavin@FreeBSD.org From: gavin@FreeBSD.org Cc: Subject: Re: kern/123166: [re] CARP messages filtered by Realtek driver on > 6.2 (regression) 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, 29 Apr 2008 18:46:38 -0000 Synopsis: [re] CARP messages filtered by Realtek driver on > 6.2 (regression) Responsible-Changed-From-To: freebsd-net->gavin Responsible-Changed-By: gavin Responsible-Changed-When: Tue Apr 29 18:13:53 UTC 2008 Responsible-Changed-Why: I'll try and get further info from the submitter. To submitter: Firstly, does "ifconfig re0 promisc" make any difference? Secondly, you could try getting the most recent versions of the driver files from: http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/src/sys/dev/re/if_re.c?rev=1.46.2.39;content-type=text%2Fplain http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/src/sys/pci/if_rlreg.h?rev=1.51.2.13;content-type=text%2Fplain put the first into /usr/src/sys/dev/re and the second into /usr/src/sys/pci, recompile the kernel and test. Thirdly, if that hasn't fixed it, we need to establish when the breakage happened. The easiest way is to try different kernels (you shouldn't need to recompile the userland for this), and basically try to establish when the breakage was introduced to 6.x. Assuming you are using csup or cvsup to update your system, add the following line: *default date=2007.07.14.00.00.00 Then csup will bring sources down as they were on the 1st of August. Recompile, and see if CARP still works with that kernel. If so, move the date forward, and if not, go backwards in time. Some useful dates to try will probably be: 2007.02.01.00.00.00 2007.04.20.00.00.00 2007.05.01.00.00.00 2007.08.01.00.00.00 2007.09.20.00.00.00 2007.12.01.00.00.00 i.e. in the worst case, you may have to recompile your kernel three times to figure out between which of the above dates the breakage occured. (For reference, 6.2 was released on 2007.01.15, with 6.3 on 2008.01.18) http://www.freebsd.org/cgi/query-pr.cgi?pr=123166 From owner-freebsd-net@FreeBSD.ORG Tue Apr 29 18:47:26 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AEC171065672 for ; Tue, 29 Apr 2008 18:47:26 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.174]) by mx1.freebsd.org (Postfix) with ESMTP id 4616B8FC26 for ; Tue, 29 Apr 2008 18:47:26 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-066-047-238.pools.arcor-ip.net [88.66.47.238]) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis) id 0ML21M-1JqurM2XCi-0000i4; Tue, 29 Apr 2008 20:47:24 +0200 Received: (qmail 50251 invoked from network); 29 Apr 2008 18:46:02 -0000 Received: from myhost.laiers.local (192.168.4.151) by ns1.laiers.local with SMTP; 29 Apr 2008 18:46:02 -0000 From: Max Laier Organization: FreeBSD To: freebsd-net@freebsd.org Date: Tue, 29 Apr 2008 20:43:22 +0200 User-Agent: KMail/1.9.9 References: <48134DDE.9010306@elischer.org> <48175B91.1010202@gtcomm.net> <481766A2.7040809@elischer.org> In-Reply-To: <481766A2.7040809@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200804292043.22572.max@love2party.net> X-Provags-ID: V01U2FsdGVkX196g/xbTzLvKpnBCI/NwaKz9iOChaaQEsV8m17 16MhG9jHCBJjSlul1YygbkRNe4FkLDcscXNAork/HIteMEecYb kQ6oYs28zfplH7rez2CkQ== Cc: Julian Elischer , "Wilkinson, Alex" , Paul Subject: Re: Multiple routing tables in action... 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, 29 Apr 2008 18:47:26 -0000 On Tuesday 29 April 2008 20:19:14 Julian Elischer wrote: > Paul wrote: > > I've been waiting for something like this. Linux has done policy > > routing for many many years and is very good at it. I prefer to use > > FreeBSD for routing though and this is a feature I have been waiting > > for :) Mainly to use with BGP , having multiple BGP routing tables. > > I would like it to be similar to Cisco's VRF or Juniper's routing > > instance, but maybe that's asking too much. We use it on our > > hardware routers for implementations such as having multiple bgp > > route tables and having customer bandwidth pricing change based on > > which routing table their traffic gets , say.. value customers, > > premium customers, customers who want only certain carriers in their > > bandwidth mix, etc. Would be fun to have support for FBSD with > > quagga/openbgpd etc.. and be able to use dscp for marking or any > > other policy based rule (source ip for instance). > > > > Thanks Julian.. This is a step forward in the right direction :) > > The interaction with routing daemons is something I don't know > enough about. I need someone who knows routing daemons to tell > how to correctly tweek code that sends routing events. > > I think it is possible that events from a particular FIB should only > be reported to routing sockets that are associated with that FIB. > but I'm not sure about this. > > This would mean running a separate instance of the routing daemon for > each FIB (VRF?). Does this sound right to people? OpenBSD "added"[1] a field to the rt_msghdr to indicate/select the source/destination table. If we were to do the same at least OpenBGPB should work with fairly minimal changes. I think it's a sensible approach, too. A routing daemon wouldn't have to select over a dozen sockets to do what is needed and it will be much easier as well. If easily done, a way to "bind" a route socket to a table id would also be nice as it would easily make things work with multi table oblivious daemons. [1]http://www.openbsd.org/cgi-bin/cvsweb/src/sys/net/route.h.diff?r1=1.44&r2=1.45&f=h > > Julian Elischer wrote: > >> Wilkinson, Alex wrote: > >>> 0n Sat, Apr 26, 2008 at 08:44:30AM -0700, Julian Elischer wrote: > >>> >A little progress report > >>> >From a recently installed (6.3) machine.... (plus patches) > >>> > >>> Ok, being ignorant to this, possibly a silly question: > >>> > >>> Why would i want or need multiple routing tables ? > >> > >> any time you wnat to base a route upon something other than just > >> the destination address. It's basically called "Policy based > >> routing". > >> > >> > >> Trivial examples: > >> You have two ISPs and you want to send all SMTP via one link and > >> all other traffic via the other. > >> > >> You have 3 ISPs and want all traffic from the accounting department > >> to go via a particular path (that is encrypted) but regular office > >> chatter to go via another. > >> > >> I have other more complex examples in my work. > >> > >> I'm sure others have more solid examples as well. > >> > >> google for policy routing. > >> _______________________________________________ > >> freebsd-net@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-net > >> To unsubscribe, send any mail to > >> "freebsd-net-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-net@FreeBSD.ORG Tue Apr 29 18:57:32 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C5C5106566C for ; Tue, 29 Apr 2008 18:57:32 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outL.internet-mail-service.net (outl.internet-mail-service.net [216.240.47.235]) by mx1.freebsd.org (Postfix) with ESMTP id 519F18FC16 for ; Tue, 29 Apr 2008 18:57:32 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Tue, 29 Apr 2008 17:13:20 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id AB85A2D6012; Tue, 29 Apr 2008 11:57:31 -0700 (PDT) Message-ID: <48176F9D.9010908@elischer.org> Date: Tue, 29 Apr 2008 11:57:33 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Max Laier References: <48134DDE.9010306@elischer.org> <48175B91.1010202@gtcomm.net> <481766A2.7040809@elischer.org> <200804292043.22572.max@love2party.net> In-Reply-To: <200804292043.22572.max@love2party.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, "Wilkinson, Alex" , Paul Subject: Re: Multiple routing tables in action... 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, 29 Apr 2008 18:57:32 -0000 Max Laier wrote: > On Tuesday 29 April 2008 20:19:14 Julian Elischer wrote: >> Paul wrote: >>> I've been waiting for something like this. Linux has done policy >>> routing for many many years and is very good at it. I prefer to use >>> FreeBSD for routing though and this is a feature I have been waiting >>> for :) Mainly to use with BGP , having multiple BGP routing tables. >>> I would like it to be similar to Cisco's VRF or Juniper's routing >>> instance, but maybe that's asking too much. We use it on our >>> hardware routers for implementations such as having multiple bgp >>> route tables and having customer bandwidth pricing change based on >>> which routing table their traffic gets , say.. value customers, >>> premium customers, customers who want only certain carriers in their >>> bandwidth mix, etc. Would be fun to have support for FBSD with >>> quagga/openbgpd etc.. and be able to use dscp for marking or any >>> other policy based rule (source ip for instance). >>> >>> Thanks Julian.. This is a step forward in the right direction :) >> The interaction with routing daemons is something I don't know >> enough about. I need someone who knows routing daemons to tell >> how to correctly tweek code that sends routing events. >> >> I think it is possible that events from a particular FIB should only >> be reported to routing sockets that are associated with that FIB. >> but I'm not sure about this. >> >> This would mean running a separate instance of the routing daemon for >> each FIB (VRF?). Does this sound right to people? > > OpenBSD "added"[1] a field to the rt_msghdr to indicate/select the > source/destination table. If we were to do the same at least OpenBGPB > should work with fairly minimal changes. I would like someone who knows routing daemons to add this or tell me what needs to be done. > > I think it's a sensible approach, too. A routing daemon wouldn't have to > select over a dozen sockets to do what is needed and it will be much > easier as well. If easily done, a way to "bind" a route socket to a > table id would also be nice as it would easily make things work with > multi table oblivious daemons. I already have a socket option that works on routing sockets to bind them to a FIB. and /usr/bin/setfib can be used to make a fib-unaware process bind by default to a set fib. e.g. setfib -2 routed [args] > > From owner-freebsd-net@FreeBSD.ORG Tue Apr 29 19:11:03 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 688A0106566B for ; Tue, 29 Apr 2008 19:11:03 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outM.internet-mail-service.net (outm.internet-mail-service.net [216.240.47.236]) by mx1.freebsd.org (Postfix) with ESMTP id 4DE8F8FC31 for ; Tue, 29 Apr 2008 19:11:03 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Tue, 29 Apr 2008 17:26:51 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 1DABB2D6006; Tue, 29 Apr 2008 12:11:02 -0700 (PDT) Message-ID: <481772C7.8090300@elischer.org> Date: Tue, 29 Apr 2008 12:11:03 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Paul , FreeBSD Net References: <48134DDE.9010306@elischer.org> <20080429084032.GW71371@stlux503.dsto.defence.gov.au> <48175793.30606@elischer.org> <48175B91.1010202@gtcomm.net> <481766A2.7040809@elischer.org> <48176C65.4080600@gtcomm.net> In-Reply-To: <48176C65.4080600@gtcomm.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Multiple routing tables in action... 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, 29 Apr 2008 19:11:03 -0000 -net added to broaden the conversation Paul wrote: > The routing daemons run linked separate instances and create their own > RIB. Take a look at Cisco's VRF implementation. You can even have > interfaces assigned to the other routing instance so you could have > em0.001 on routing instance 1 and em0.002 on routing instance 2 and > without using any policies or firewall rules it would know that > everything coming on em0.002 uses the #2 instance and routes > accordingly. Same with Juniper. that's coming.. have patience.. we will have vimage (check google) plus multiple FIBS in each vimage.. for now use a firewall classifier. > Then you can export RIB entries , say > you have 5 BGP peers and you want to export 2 or 3 or all of them into > the 'main' routing instance you can set up a policy to add those learned > routes into the main instance and v-v. > Linux behaves a little bit differently as you have to make an 'ip rule' > entry for it but it doesn't use the firewall. for now this code asks you to use a firewall to classify incoming packets.. e.g. 100 setfib 2 ip from any to any in recv em0 > > I wish FreeBSD made a routing daemon that had total interactivity > between the OS and daemon which would be great.. Quagga is good but the > interaction is very annoying. Quagga has no idea what is going on on the > kernel level and the kernel has no idea what is going on with quagga. I'm not a routing daemon expert.. > Ex: if I add or remove a route from the kernel using 'route' command it > does not remove it in quagga. Would be great to have a BGP/OSPF combo > integrated into the kernel somehow. Sounds like Quagga needs to be made aware of routing events by listening for them on routing sockets. They are available. [chop] > I have need for > many many gigabit firewalls to put in front of many servers and the cost > for the hardware firewall devices is way too much to deploy in the > quantity that I need :/ > > Paul > If you have a roadmap, then get involved.. :-) We need end user quidance on some of this stuff. From owner-freebsd-net@FreeBSD.ORG Tue Apr 29 19:17:14 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 725A4106566C for ; Tue, 29 Apr 2008 19:17:14 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outO.internet-mail-service.net (outo.internet-mail-service.net [216.240.47.238]) by mx1.freebsd.org (Postfix) with ESMTP id 509C98FC0C for ; Tue, 29 Apr 2008 19:17:14 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Tue, 29 Apr 2008 17:33:02 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 9DEEE2D6012; Tue, 29 Apr 2008 12:17:13 -0700 (PDT) Message-ID: <4817743B.6090107@elischer.org> Date: Tue, 29 Apr 2008 12:17:15 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Kevin Oberman References: <20080429185100.57C2445010@ptavv.es.net> In-Reply-To: <20080429185100.57C2445010@ptavv.es.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net Subject: Re: multiple routing tables review patch ready for simple testing. 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, 29 Apr 2008 19:17:14 -0000 Kevin Oberman wrote: >> Date: Tue, 29 Apr 2008 00:44:18 -0700 >> From: Julian Elischer >> Sender: owner-freebsd-net@freebsd.org >> >> The patch can be found at >> http://www.freebsd.org/~julian/mrt.diff >> (or http://www.freebsd.org/~julian/mrt6.diff for RELENG_6) >> >> or source can be taken from perforce at: >> //depot/user/julian/routing/src >> >> a kernel needs to be created with the option ROUTETABLES=N >> >> e.g. >> +options ROUTETABLES=2 # max 16. 1 is back >> compatible. >> >> leaving this out will result in just a single routing table as per normal. >> >> the max is 16 but I have an artificial (even lower) at 8 but that may >> be gone by the time people try it :-) >> >> I ws informed early in this project that kernel routing tables should >> now be refered to as FIBs (forwarding Information base?). >> >> the new command "setfib" sets teh default fib for a process and all its >> decendents > > I have been working with big routers in my day job for years and it's > really frustrating to not have this sort of capability when I work with > FreeBSD, but I don't expect a general purpose OS to ever have the > routing capabilities of a dedicated router. > > I think this will really, really be nice for my needs, though. > > As terminology goes, I think you have it slightly off. > > Modern routers have two "classes" of tables to move packets between > interfaces: the RIB Routing information base) and the FIB (Forwarding > Information Base). A router has multiple RIBs, usually one for each > network layer protocol (IPv4 and IPv6, both unicast and multicast) and > added RIBs for policy based routes. They may be further broken up by the > protocol used to populate the table (BGP, OSPF, ISIS, MPLS, static, > connected, ...) > > The RIBs exports data, as needed to a single FIB which is used by the > ASICs (hardware forwarding engines) to do the actual forwarding of the > packets. In a real router, the forwarding of almost all packets is done > in hardware with no real involvement by the processor that determines the > routes. (N.B. This is a gross simplification of what modern routers > do or can do, but I don't want to send a book to the list.) > > A general purpose OS is a different beast as it has no physical > equivalent of the FIB. It may have multiple routing tables, though, to > I think setrib would be a term less likely to cause confusion then > setfib even though, in the case of your FreeBSD patches, it's really > both. The way I see it the routing daemons (e.g. quagga) have the RIBS and the kernel has FIBS because it doesn't really know the big picture. If we need to change the terminology now is the time.. I asked for comments on terminology before and this is what we came up with.. but once it gets committed.... it gets set in stone. From owner-freebsd-net@FreeBSD.ORG Tue Apr 29 19:48:26 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 27A181065687; Tue, 29 Apr 2008 19:48:26 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id F29D78FC17; Tue, 29 Apr 2008 19:48:25 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from freefall.freebsd.org (jhb@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m3TJmP0C036302; Tue, 29 Apr 2008 19:48:25 GMT (envelope-from jhb@freefall.freebsd.org) Received: (from jhb@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m3TJmPxv036298; Tue, 29 Apr 2008 19:48:25 GMT (envelope-from jhb) Date: Tue, 29 Apr 2008 19:48:25 GMT Message-Id: <200804291948.m3TJmPxv036298@freefall.freebsd.org> To: thn@saeab.se, jhb@FreeBSD.org, freebsd-net@FreeBSD.org, jhb@FreeBSD.org From: jhb@FreeBSD.org Cc: Subject: Re: kern/118975: [bge] [patch] Broadcom 5906 not handled by FreeBSD 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, 29 Apr 2008 19:48:26 -0000 Synopsis: [bge] [patch] Broadcom 5906 not handled by FreeBSD State-Changed-From-To: open->patched State-Changed-By: jhb State-Changed-When: Tue Apr 29 19:48:06 UTC 2008 State-Changed-Why: Patch committed to HEAD with minor tweaks. Responsible-Changed-From-To: freebsd-net->jhb Responsible-Changed-By: jhb Responsible-Changed-When: Tue Apr 29 19:48:06 UTC 2008 Responsible-Changed-Why: Patch committed to HEAD with minor tweaks. http://www.freebsd.org/cgi/query-pr.cgi?pr=118975 From owner-freebsd-net@FreeBSD.ORG Tue Apr 29 20:17:40 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17794106567E for ; Tue, 29 Apr 2008 20:17:40 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id C91C08FC1A for ; Tue, 29 Apr 2008 20:17:39 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 3DBB0104ACC; Tue, 29 Apr 2008 16:17:39 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Tue, 29 Apr 2008 16:17:39 -0400 X-Sasl-enc: YJC9qxZ3D2d4TYwdTkujsD/vao1YP3NAbJtcVn8fx9jQ 1209500258 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 7E00035A6E; Tue, 29 Apr 2008 16:17:38 -0400 (EDT) Message-ID: <48178261.20207@FreeBSD.org> Date: Tue, 29 Apr 2008 21:17:37 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.12 (X11/20080423) MIME-Version: 1.0 To: Julian Elischer References: <48134DDE.9010306@elischer.org> <20080429084032.GW71371@stlux503.dsto.defence.gov.au> <48175793.30606@elischer.org> <48175B91.1010202@gtcomm.net> <481766A2.7040809@elischer.org> In-Reply-To: <481766A2.7040809@elischer.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , "Wilkinson, Alex" , Paul Subject: Re: Multiple routing tables in action... 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, 29 Apr 2008 20:17:40 -0000 Julian Elischer wrote: > The interaction with routing daemons is something I don't know > enough about. I need someone who knows routing daemons to tell > how to correctly tweek code that sends routing events. As long as it doesn't break anything... > > I think it is possible that events from a particular FIB should only > be reported to routing sockets that are associated with that FIB. > but I'm not sure about this. Please look at the Linux rtnetlink socket, they use a tag-length-value protocol for just this reason. It seems reasonable that PF_ROUTE messages have some kind of filter applied to them until a more complete story can be realised for this. Most PF_ROUTE clients are savvy enough to ignore message types on the socket that they don't understand. If there is a need to announce route adds and deletes on the socket on a per-fib basis, it seems reasonable to stash it in one of the unused fields (if we've got any of those..urp) and change the rtm_type field for now. However it does take us further down a route (no pun intended) of incremental growth which has real risk (lack of or insufficiently rich test cases, requirements drift etc) and seems to be incumbent with open source in general. > > This would mean running a separate instance of the routing daemon for > each FIB (VRF?). Does this sound right to people? Sounds crap! You really, really don't want to be doing that if you can avoid it. Of course a lot of what's out there is not geared up to deal with it (and why would it be?) so it's fine for the time being, but it really, really can't be considered a complete, production-quality solution until the missing parts exist. cheers BMS P.S. I am impressed by the scope and ambition of your work even if I haven't had a chance to digest it fully yet, and I hope that my concern about production quality open source here is not misinterpreted as nay-saying or disapproval by anyone. From owner-freebsd-net@FreeBSD.ORG Tue Apr 29 20:25:57 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56BCE106566B for ; Tue, 29 Apr 2008 20:25:57 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id 2B74A8FC0A for ; Tue, 29 Apr 2008 20:25:57 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 6FA0C104B54; Tue, 29 Apr 2008 16:25:56 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Tue, 29 Apr 2008 16:25:56 -0400 X-Sasl-enc: rtOlRymV6ANotoC2zIJz8OFcaeCASGJulCOqR9RYlCPS 1209500756 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id B9FF66A27; Tue, 29 Apr 2008 16:25:55 -0400 (EDT) Message-ID: <48178452.4050700@FreeBSD.org> Date: Tue, 29 Apr 2008 21:25:54 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.12 (X11/20080423) MIME-Version: 1.0 To: Julian Elischer References: <20080429185100.57C2445010@ptavv.es.net> <4817743B.6090107@elischer.org> In-Reply-To: <4817743B.6090107@elischer.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , Kevin Oberman Subject: Re: multiple routing tables review patch ready for simple testing. 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, 29 Apr 2008 20:25:57 -0000 Julian Elischer wrote: >> >> A general purpose OS is a different beast as it has no physical >> equivalent of the FIB. It may have multiple routing tables, though, to >> I think setrib would be a term less likely to cause confusion then >> setfib even though, in the case of your FreeBSD patches, it's really >> both. > If we need to change the terminology now is the time.. > I asked for comments on terminology before and this is what we > came up with.. but once it gets committed.... it gets set in stone. The kernel forwarding table is not a RIB. In the past some apps have tried to use it as one. They really shouldn't do that. There are implementation constraints on the inter-process communication involved (PRC_ATOMIC, etc) which make it inherently unsuitable as a place for routing daemons to exchange routes, particularly when the system is under load, or running near load limits, as would be the case with a tightly engineered embedded system. I understand folk went down that road in the past, as a means to get something up and running quickly as a working demo, or as a hangover from the days when they were the only tools around, but it isn't the way to build a comms infrastructure. These days general purpose OSes are getting closer to specialised comms equipment in terms of what they can do, but more importantly, so are people's expectations of them -- and thus people's concern about whether or not it works tends to follow. cheers BMS From owner-freebsd-net@FreeBSD.ORG Tue Apr 29 20:42:03 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1F28106567E for ; Tue, 29 Apr 2008 20:42:02 +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 C837B8FC14 for ; Tue, 29 Apr 2008 20:42:02 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Tue, 29 Apr 2008 18:57:54 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id D8DC82D6004; Tue, 29 Apr 2008 13:42:01 -0700 (PDT) Message-ID: <4817881B.7010409@elischer.org> Date: Tue, 29 Apr 2008 13:42:03 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: "Bruce M. Simpson" References: <20080429185100.57C2445010@ptavv.es.net> <4817743B.6090107@elischer.org> <48178452.4050700@FreeBSD.org> In-Reply-To: <48178452.4050700@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , Kevin Oberman Subject: Re: multiple routing tables review patch ready for simple testing. 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, 29 Apr 2008 20:42:03 -0000 Bruce M. Simpson wrote: > Julian Elischer wrote: >>> >>> A general purpose OS is a different beast as it has no physical >>> equivalent of the FIB. It may have multiple routing tables, though, to >>> I think setrib would be a term less likely to cause confusion then >>> setfib even though, in the case of your FreeBSD patches, it's really >>> both. >> If we need to change the terminology now is the time.. >> I asked for comments on terminology before and this is what we >> came up with.. but once it gets committed.... it gets set in stone. > > The kernel forwarding table is not a RIB. > > In the past some apps have tried to use it as one. They really shouldn't > do that. > > There are implementation constraints on the inter-process communication > involved (PRC_ATOMIC, etc) which make it inherently unsuitable as a > place for routing daemons to exchange routes, particularly when the > system is under load, or running near load limits, as would be the case > with a tightly engineered embedded system. > > I understand folk went down that road in the past, as a means to get > something up and running quickly as a working demo, or as a hangover > from the days when they were the only tools around, but it isn't the way > to build a comms infrastructure. > > These days general purpose OSes are getting closer to specialised comms > equipment in terms of what they can do, but more importantly, so are > people's expectations of them -- and thus people's concern about whether > or not it works tends to follow. > basically what I've implemented is similar to cisco VRF in nature. Interfaces are not however assigned to FIB instance. each FIB may contain entries for each interface, and by default they do, but you can delete teh entries associated with a particular interface from a particular FIB so that fib will never use that interface. An interface may however be present in entries from multiple FIBs in which case the INCOMING packets on that interface need to be disambiguated with respect to which FIB they belong to. This is a job for an outside entity (from the fibs). In this case a packet classifier such as pf or ipfw is ideal for the job. providing an outside mechanism for implementing whatever policy the admin wants to set up. I find it is convenient to envision each routing FIB as a routing plane, in a stack of such planes. Each plane may know about the same interfaces or different interfaces. When a packet enters a routing plane it is routed according to the internal rules of that plane. Irrespective of how other planes may act. Each plane can only route a packet to interfaces that are know about on that plane. Incoming packets on an interface don't know what plane to go to and must be told which to use by the external mechanism. It IS possible that an interface in the future might have a default plane, but I haven't implemented this. if you have several alias addresses on an interface it is possible that some FIBS know about some of them and others know about other addresses. New addresses when added are added to each FIB and whatever is adding them shoudl remove them from the ones that don't need it. This may change but it fits in with how the current code works and keeps the diff to a manageable size. (and it suits what I need for work where a route manager daemon knows to do this.) > cheers > BMS From owner-freebsd-net@FreeBSD.ORG Wed Apr 30 02:50:41 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 570A4106564A for ; Wed, 30 Apr 2008 02:50:41 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180]) by mx1.freebsd.org (Postfix) with ESMTP id 238E18FC16 for ; Wed, 30 Apr 2008 02:50:40 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wa-out-1112.google.com with SMTP id j4so158591wah.3 for ; Tue, 29 Apr 2008 19:50:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=frl564WPH6DK0J2LW1gTLVHwo7ljeSNNoIe0WsNP91g=; b=U5lDUXX45B/7Pt3YiIbbYlRCjIWj/eX8dgRApKBzzQuKspyaUQDDUamsPaK7oax9HYU5xyfSb3srW6lIVFZfS2hkXAL4AB4T3ul2KeV9pgji1UdtE9H4iqq9DEBnIHuCT9oQwRArlvAu91/ziFxCLDcLJnOdmLqO3HaEnFwcxr0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=ggjKd17vEjug7dNZDD3ZHtNrugoWJrzrj++q8GJU1V1MhGfO/uO5QmOTqabH9kn6Mas/gYLfSMyx8SOynk4N9fevMw7BozdOHqEL0o87iTz2BKQhFWAfQzB5UjtgS5dtFsHYS3aGPpvk/cnrfBpr256YJcx6cEYKQLDeIozv1WY= Received: by 10.114.159.5 with SMTP id h5mr152385wae.222.1209523840740; Tue, 29 Apr 2008 19:50:40 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id z15sm368139pod.13.2008.04.29.19.50.37 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 29 Apr 2008 19:50:39 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id m3U2oXW1082702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Apr 2008 11:50:33 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m3U2oXNN082701; Wed, 30 Apr 2008 11:50:33 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Wed, 30 Apr 2008 11:50:33 +0900 From: Pyun YongHyeon To: Oleg Message-ID: <20080430025033.GA82598@cdnetworks.co.kr> References: <1733112647.20080417004353@gmail.com> <20080417003713.GA28522@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: [bfe] [panic] Serious error: bfe failed to map RX buffer X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2008 02:50:41 -0000 On Tue, Apr 29, 2008 at 08:25:13PM +0300, Oleg wrote: > Hi, sorry for long delay, was too busy. > So, I recheck return code of bus_dmamap_load(9) and its exactly ENOMEM. > Here are fresh patch with your suggestions (diff with HEAD) > Patch committed with minor changes(if_bfe.c rev 1.45). Thanks a lot! -- Regards, Pyun YongHyeon From owner-freebsd-net@FreeBSD.ORG Wed Apr 30 13:20:04 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50D501065681 for ; Wed, 30 Apr 2008 13:20:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3FFDE8FC14 for ; Wed, 30 Apr 2008 13:20:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m3UDK3AL034833 for ; Wed, 30 Apr 2008 13:20:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m3UDK3cK034832; Wed, 30 Apr 2008 13:20:03 GMT (envelope-from gnats) Date: Wed, 30 Apr 2008 13:20:03 GMT Message-Id: <200804301320.m3UDK3cK034832@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Josh Endries Cc: Subject: Re: kern/123172: [bce] Watchdog timeout problems with if_bce X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Josh Endries List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2008 13:20:04 -0000 The following reply was made to PR kern/123172; it has been noted by GNATS. From: Josh Endries To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/123172: [bce] Watchdog timeout problems with if_bce Date: Wed, 30 Apr 2008 08:58:23 -0400 It's been working well for a while, so I might have fixed whatever was causing the problem to manifest. I converted my lo0 jails to use real IPs, and removed my pf config that was routing things around, so I suspect that had something to do with it. I can't change it back right now, later this week/weekend I should be able to. I had jails on 127.0.0.x (a couple still are), namely the BIND jail, but my switch was load balancing it so the machine was BINATing the 10.0.0 address the switch was talking to with the local 127.0.0.3 address (iirc). The switch was NATing the 10 address to a real IP. The problem was that I also have some real IPs on this box, so the machine wanted to route packets out that interface, so I had to use route-to/reply-to for the BIND jail to get things to go back out the way they came in, instead of using the x.x.164/24 route or default route. It did work in the configuration, but had the watchdog errors. I think this might have something to do with the issue; I'll put things back and test it some more when I have some time. I did see that other PR, but since this is a newer version of FreeBSD, and I have no ACPI problems or problems booting (that I've noticed, at least), I decided to submit. They certainly could be related (we're both using amd64; unfortunately I can't change that to test i386). Here is some more info... jls: JID IP Address Hostname Path 5 x.x.164.7 smtp /jails/smtp/root 4 127.0.0.5 mx /jails/mx/root 3 x.x.164.4 ns /jails/ns/root 2 127.0.0.4 pkg /jails/pkg/root 1 127.0.0.2 mysql /jails/mysql/root /etc/pf.conf: nat on vlan2 from to any -> x.x.164.123 binat on vlan8 from $jail_mysql_ip to any -> $jail_mysql_exip block log (user) all pass in log (user) quick on vlan2 inet proto { tcp, udp } from any to $jail_ns_ip port domain keep state pass out log (user) quick on vlan2 inet proto { tcp, udp } from $jail_ns_ip to any port domain keep state pass quick log (user) on lo0 inet proto udp from to port domain keep state pass quick log (user) on lo0 inet proto tcp from to $jail_mysql_ip port 3306 keep state pass out log (user) quick on vlan8 inet proto tcp from $jail_mysql_exip to 10.0.1.2 port 3306 keep state pass in log (user) quick on vlan11 inet proto tcp from to vlan11 port 55185 keep state pass log (user) quick inet proto icmp all icmp-type $icmp_types keep state pass out log (user) quick on vlan2 inet proto tcp from x.x.164.123 to any keep state uname -a: FreeBSD hathor 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Tue Mar 24 13:36:33 EDT 2009 root@hathor:/jails/src/usr/obj/jails/src/usr/src/sys/ULEMAC amd64 kernel config: include GENERIC ident ULEMAC nooptions SCHED_4BSD options SCHED_ULE options MAC ifconfig: bce0: flags=8843 metric 0 mtu 1500 options=1bb ether 00:1f:29:06:d9:e2 media: Ethernet autoselect (100baseTX ) status: active lagg: laggdev lagg0 bce1: flags=8843 metric 0 mtu 1500 options=1bb ether 00:1f:29:06:d9:e2 media: Ethernet autoselect (100baseTX ) status: active lagg: laggdev lagg0 lo0: flags=8049 metric 0 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 inet 127.0.0.2 netmask 0xffffffff inet 127.0.0.4 netmask 0xffffffff inet 127.0.0.5 netmask 0xffffffff lagg0: flags=8843 metric 0 mtu 1500 options=1bb ether 00:1f:29:06:d9:e2 media: Ethernet autoselect status: active laggproto lacp laggport: bce1 flags=1c laggport: bce0 flags=1c vlan2: flags=8843 metric 0 mtu 1500 options=3 ether 00:1f:29:06:d9:e2 inet x.x.164.123 netmask 0xffffff00 broadcast x.x.164.255 inet x.x.164.4 netmask 0xffffffff broadcast x.x.164.4 inet x.x.164.7 netmask 0xffffffff broadcast x.x.164.7 media: Ethernet autoselect status: active vlan: 2 parent interface: lagg0 vlan8: flags=8843 metric 0 mtu 1500 options=3 ether 00:1f:29:06:d9:e2 inet 10.0.1.6 netmask 0xfffffff8 broadcast 10.0.1.7 media: Ethernet autoselect status: active vlan: 8 parent interface: lagg0 vlan11: flags=8843 metric 0 mtu 1500 options=3 ether 00:1f:29:06:d9:e2 inet 10.0.2.11 netmask 0xffffff00 broadcast 10.0.2.255 media: Ethernet autoselect status: active vlan: 11 parent interface: lagg0 vlan12: flags=8843 metric 0 mtu 1500 options=3 ether 00:1f:29:06:d9:e2 inet 10.0.0.10 netmask 0xfffffff8 broadcast 10.0.0.15 media: Ethernet autoselect status: active vlan: 12 parent interface: lagg0 pflog0: flags=141 metric 0 mtu 33160 I'll post again after I change it back and try what you suggested. Thanks, Josh From owner-freebsd-net@FreeBSD.ORG Wed Apr 30 15:38:26 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D43B010656C3 for ; Wed, 30 Apr 2008 15:38:26 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id 8E7F48FC23 for ; Wed, 30 Apr 2008 15:38:26 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 1F45910510D; Wed, 30 Apr 2008 11:38:25 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Wed, 30 Apr 2008 11:38:25 -0400 X-Sasl-enc: nJ9yUwWj48UeJbSUgz7xvEuSUs2uRhVBRjUB1OkycHdj 1209569904 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 342E72B569; Wed, 30 Apr 2008 11:38:24 -0400 (EDT) Message-ID: <4818926F.8010309@incunabulum.net> Date: Wed, 30 Apr 2008 16:38:23 +0100 From: Bruce M Simpson User-Agent: Thunderbird 2.0.0.12 (X11/20080423) MIME-Version: 1.0 To: Julian Elischer References: <20080429185100.57C2445010@ptavv.es.net> <4817743B.6090107@elischer.org> <48178452.4050700@FreeBSD.org> <4817881B.7010409@elischer.org> In-Reply-To: <4817881B.7010409@elischer.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , Kevin Oberman Subject: Re: multiple routing tables review patch ready for simple testing. 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, 30 Apr 2008 15:38:26 -0000 Julian Elischer wrote: > An interface may however be present in entries from multiple FIBs > in which case the INCOMING packets on that interface need to > be disambiguated with respect to which FIB they belong to. Yes, there is no way the forwarding code alone can do this. It should not be expected to, and it's important to maintain a clean functional separation there, otherwise one ends up in the same quagmire which has been plaguing a lot of QoS research projects over the years (Where do I put this bit of the system?) > > This is a job for an outside entity (from the fibs). > In this case a packet classifier such as pf or ipfw is ideal > for the job. providing an outside mechanism for implementing > whatever policy the admin wants to set up. Absolutely. This has been the intent from the beginning. There is no "one size fits all" approach here. We could put a packet classifier into the kernel which works just fine for DOCSIS consumer distribution networks, but has absolutely no relevance to an ATM backbone (these are the two main flavours of access for folk in the UK). > > I find it is convenient to envision each routing FIB as a routing > plane, in a stack of such planes. Each plane may know about the same > interfaces or different interfaces. When a packet enters a routing > plane it is routed according to the internal rules of that plane. > Irrespective of how other planes may act. Each plane can only route > a packet to interfaces that are know about on that plane. > Incoming packets on an interface don't know what plane to go to > and must be told which to use by the external mechanism. It > IS possible that an interface in the future might have a default > plane, but I haven't implemented this. This limitation seems fine for now. Users can't be expected to configure the defaults "by default" if they aren't supported, so, if overall the VRF-like feature defaults to off, and there are big flashing bold letters saying "You must fully configure the forwarding plane mappings if you wish to use multiple FIBs", then that's fine by me. > > if you have several alias addresses on an interface it is possible > that some FIBS know about some of them and others know about other > addresses. New addresses when added are added to each FIB and > whatever is adding them shoudl remove them from the ones that don't > need it. This may change but it fits in with how the current code > works and keeps the diff to a manageable size. In any event, for plain old IP forwarding, a node's endpoint addresses are used only as convenient ways of referring to physical links. To back up and give this some detailed background: For example, 192.0.2.1/24 might be configured on fxp0, and we receive a packet on another interface for 192.0.2.2. When resolving a route, the forwarding code needs to do a lookup to see from where 192.0.2.2 is reachable before the next-hop is resolved in the table. That happens on a per-FIB basis, when the patches are applied -- however the job of tagging input for which FIB is the job of the classifier. The problems with the above approach begin when an input interface resides in multiple virtual FIBs (no 1:1 mapping), or when you can't refer to it by an address (it has no address -- unnumbered point-to-point link, or addresses do not apply), or when you attempt to implement encapsulation (e.g. GRE, IPIP) in the forwarding layer. Then, you're reliant on each individual FIB having resolved next-hops correctly. The existing forwarding code already does some of this by forcing the ifp to be set for any route added to the table. This is done implicitly for routes which transit point-to-point interfaces. BSD has had some weaknesses in this area. It makes implementing things like VRRP particularly difficult, which is why the ifnet approach to CARP was used (the forwarding table gets to see a single ifp); it eliminates a level of possible recursion from that layer of the routing stack. With multicast, for example, next-hops can't be identified by IPv4 addresses alone. Every forwarding decision has potentially more than one result, and links are referred to by physical link (this could be an ifp, an interface index, a name, whatever), and where messages are forwarded is determined using a link-scope protocol such as IGMP. There, it's reasonable to expect that the user partitioned off the multicast forwarding planes into separate virtual FIBs, and that the appropriate rules in the classifier are configured. For SSM, the key (S,G) match has to happen in the input classifier, if one is going to route flows OK using the multiple FIB feature -- the multicast routing daemons have to be aware of it, 'cuz you can't run a separate instance of PIM for every set of flows -- PIM is greedy per-link, a !1:1 mapping problem exists, PIM has no way of telling separate instances apart (no hierarchy in the form of e.g. OSPF areas, and even OSPF won't let you put a link in more than one area -- virtual links don't count!) This is so much whizzing in the wind without a new MROUTING implementation though, and hierarchical multicast routing is a project in of itself. To summarize: For now, the limitations of the system should be documented so that users don't inadvertently configure local forwarding loops, even for unicast traffic; with multicast, the amplification effect of misconfiguration is inherently more damaging to a network. The IPv4 address of an interface can't be used as an identifier for source routing -- there is no way of knowing that was the next-hop used by the last-hop, the information just ain't there -- so if you have the same input interfaces in multiple virtual FIBs, you need to double check the appropriate match rules are in place for the flows to go where you want them to go. > (and it suits what I need for work where a route manager daemon > knows to do this.) This is another reason why I maintain that RIB and FIB should have functional separation. It's unreasonable to expect the kernel to perform next-hop resolution on every route presented to it, beyond that which is required by the link layer (i.e. ARP, and that should be functionally separated too). Recursive resolution also demands stack space, and this is a scarce kernel resource. Of course, well behaved routers are engineered such that the recursion takes place at RIB level, where limits and policy can be more easily applied, and before the route is plumbed into the hardware TCAM (or software FIB). Don't try to make the kernel do your dirty laundry. cheers BMS P.S. I see you tweaked verify_path() to do the lookup in the numbered FIB. Cool. I should point out that for ad-hoc networks, the ability to turn off RPF/uRPF for multicast is needed as the routing domain is often NOT fully converged -- so the RPF checks normally present may discard legitimate traffic which hasn't been forwarded yet. An encapsulation is typically used to maintain forwarding state which is relevant to the particular topology in use. From owner-freebsd-net@FreeBSD.ORG Wed Apr 30 16:18:57 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E1C91065670 for ; Wed, 30 Apr 2008 16:18:57 +0000 (UTC) (envelope-from SRS0=bb6f48e47a5a38716e51d34683d23a5c3f48e34e=686=es.net=oberman@es.net) Received: from postal1.es.net (postal3.es.net [IPv6:2001:400:14:3::8]) by mx1.freebsd.org (Postfix) with ESMTP id 4D7318FC1B for ; Wed, 30 Apr 2008 16:18:56 +0000 (UTC) (envelope-from SRS0=bb6f48e47a5a38716e51d34683d23a5c3f48e34e=686=es.net=oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal3.es.net (Postal Node 3) with ESMTP (SSL) id JWC75200; Tue, 29 Apr 2008 11:51:00 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 57C2445010; Tue, 29 Apr 2008 11:51:00 -0700 (PDT) To: Julian Elischer In-Reply-To: Your message of "Tue, 29 Apr 2008 00:44:18 PDT." <4816D1D2.7010603@elischer.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1209495060_21728P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Tue, 29 Apr 2008 11:51:00 -0700 From: "Kevin Oberman" Message-Id: <20080429185100.57C2445010@ptavv.es.net> X-Sender-IP: 198.128.4.29 X-Sender-Domain: es.net X-Recipent: ;; X-Sender: X-To_Name: Julian Elischer X-To_Domain: elischer.org X-To: Julian Elischer X-To_Email: julian@elischer.org X-To_Alias: julian Cc: FreeBSD Net Subject: Re: multiple routing tables review patch ready for simple testing. 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, 30 Apr 2008 16:18:57 -0000 --==_Exmh_1209495060_21728P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Date: Tue, 29 Apr 2008 00:44:18 -0700 > From: Julian Elischer > Sender: owner-freebsd-net@freebsd.org > > The patch can be found at > http://www.freebsd.org/~julian/mrt.diff > (or http://www.freebsd.org/~julian/mrt6.diff for RELENG_6) > > or source can be taken from perforce at: > //depot/user/julian/routing/src > > a kernel needs to be created with the option ROUTETABLES=N > > e.g. > +options ROUTETABLES=2 # max 16. 1 is back > compatible. > > leaving this out will result in just a single routing table as per normal. > > the max is 16 but I have an artificial (even lower) at 8 but that may > be gone by the time people try it :-) > > I ws informed early in this project that kernel routing tables should > now be refered to as FIBs (forwarding Information base?). > > the new command "setfib" sets teh default fib for a process and all its > decendents I have been working with big routers in my day job for years and it's really frustrating to not have this sort of capability when I work with FreeBSD, but I don't expect a general purpose OS to ever have the routing capabilities of a dedicated router. I think this will really, really be nice for my needs, though. As terminology goes, I think you have it slightly off. Modern routers have two "classes" of tables to move packets between interfaces: the RIB Routing information base) and the FIB (Forwarding Information Base). A router has multiple RIBs, usually one for each network layer protocol (IPv4 and IPv6, both unicast and multicast) and added RIBs for policy based routes. They may be further broken up by the protocol used to populate the table (BGP, OSPF, ISIS, MPLS, static, connected, ...) The RIBs exports data, as needed to a single FIB which is used by the ASICs (hardware forwarding engines) to do the actual forwarding of the packets. In a real router, the forwarding of almost all packets is done in hardware with no real involvement by the processor that determines the routes. (N.B. This is a gross simplification of what modern routers do or can do, but I don't want to send a book to the list.) A general purpose OS is a different beast as it has no physical equivalent of the FIB. It may have multiple routing tables, though, to I think setrib would be a term less likely to cause confusion then setfib even though, in the case of your FreeBSD patches, it's really both. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 --==_Exmh_1209495060_21728P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFIF24Ukn3rs5h7N1ERAhXmAJwPmPNlxZ/EHRu7rPuf/xalhFI6HQCeMePV fNU7NH6CZqIG4fSGfWI5Nb0= =6VQ+ -----END PGP SIGNATURE----- --==_Exmh_1209495060_21728P-- From owner-freebsd-net@FreeBSD.ORG Wed Apr 30 16:18:59 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42005106566B for ; Wed, 30 Apr 2008 16:18:59 +0000 (UTC) (envelope-from SRS0=bb6f48e47a5a38716e51d34683d23a5c3f48e34e=686=es.net=oberman@es.net) Received: from postal1.es.net (postal1.es.net [IPv6:2001:400:14:3::6]) by mx1.freebsd.org (Postfix) with ESMTP id 79ABE8FC26 for ; Wed, 30 Apr 2008 16:18:58 +0000 (UTC) (envelope-from SRS0=bb6f48e47a5a38716e51d34683d23a5c3f48e34e=686=es.net=oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id JYR65131; Tue, 29 Apr 2008 13:40:31 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id E429245010; Tue, 29 Apr 2008 13:40:31 -0700 (PDT) To: Julian Elischer In-Reply-To: Your message of "Tue, 29 Apr 2008 12:17:15 PDT." <4817743B.6090107@elischer.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1209501631_96830P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Tue, 29 Apr 2008 13:40:31 -0700 From: "Kevin Oberman" Message-Id: <20080429204031.E429245010@ptavv.es.net> X-Sender-IP: 198.128.4.29 X-Sender-Domain: es.net X-Recipent: ;; X-Sender: X-To_Name: Julian Elischer X-To_Domain: elischer.org X-To: Julian Elischer X-To_Email: julian@elischer.org X-To_Alias: julian Cc: FreeBSD Net Subject: Re: multiple routing tables review patch ready for simple testing. 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, 30 Apr 2008 16:18:59 -0000 --==_Exmh_1209501631_96830P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Date: Tue, 29 Apr 2008 12:17:15 -0700 > From: Julian Elischer > Sender: owner-freebsd-net@freebsd.org > > Kevin Oberman wrote: > >> Date: Tue, 29 Apr 2008 00:44:18 -0700 > >> From: Julian Elischer > >> Sender: owner-freebsd-net@freebsd.org > >> > >> The patch can be found at > >> http://www.freebsd.org/~julian/mrt.diff > >> (or http://www.freebsd.org/~julian/mrt6.diff for RELENG_6) > >> > >> or source can be taken from perforce at: > >> //depot/user/julian/routing/src > >> > >> a kernel needs to be created with the option ROUTETABLES=N > >> > >> e.g. > >> +options ROUTETABLES=2 # max 16. 1 is back > >> compatible. > >> > >> leaving this out will result in just a single routing table as per normal. > >> > >> the max is 16 but I have an artificial (even lower) at 8 but that may > >> be gone by the time people try it :-) > >> > >> I ws informed early in this project that kernel routing tables should > >> now be refered to as FIBs (forwarding Information base?). > >> > >> the new command "setfib" sets teh default fib for a process and all its > >> decendents > > > > I have been working with big routers in my day job for years and it's > > really frustrating to not have this sort of capability when I work with > > FreeBSD, but I don't expect a general purpose OS to ever have the > > routing capabilities of a dedicated router. > > > > I think this will really, really be nice for my needs, though. > > > > As terminology goes, I think you have it slightly off. > > > > Modern routers have two "classes" of tables to move packets between > > interfaces: the RIB Routing information base) and the FIB (Forwarding > > Information Base). A router has multiple RIBs, usually one for each > > network layer protocol (IPv4 and IPv6, both unicast and multicast) and > > added RIBs for policy based routes. They may be further broken up by the > > protocol used to populate the table (BGP, OSPF, ISIS, MPLS, static, > > connected, ...) > > > > The RIBs exports data, as needed to a single FIB which is used by the > > ASICs (hardware forwarding engines) to do the actual forwarding of the > > packets. In a real router, the forwarding of almost all packets is done > > in hardware with no real involvement by the processor that determines the > > routes. (N.B. This is a gross simplification of what modern routers > > do or can do, but I don't want to send a book to the list.) > > > > A general purpose OS is a different beast as it has no physical > > equivalent of the FIB. It may have multiple routing tables, though, to > > I think setrib would be a term less likely to cause confusion then > > setfib even though, in the case of your FreeBSD patches, it's really > > both. > > The way I see it the routing daemons (e.g. quagga) have the RIBS > and the kernel has FIBS because it doesn't really know the big picture. > > If we need to change the terminology now is the time.. > I asked for comments on terminology before and this is what we > came up with.. but once it gets committed.... it gets set in stone. On further review, I agree with you. The table in the kernel really is a FIB (or a logical equivalent), and not really a RIB, so I withdraw any objection to setfib. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 --==_Exmh_1209501631_96830P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFIF4e/kn3rs5h7N1ERAlxPAKCO5ZO0YINUOzolO7gzo44TJpRmCQCgo1Cl JZCHa/Ajm7DgE8sGaOgm8nE= =nyTT -----END PGP SIGNATURE----- --==_Exmh_1209501631_96830P-- From owner-freebsd-net@FreeBSD.ORG Wed Apr 30 17:25:49 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8C9E1065670 for ; Wed, 30 Apr 2008 17:25:49 +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 866598FC14 for ; Wed, 30 Apr 2008 17:25:49 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Wed, 30 Apr 2008 15:42:48 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id CD0582D6011; Wed, 30 Apr 2008 10:25:48 -0700 (PDT) Message-ID: <4818AB9F.7000607@elischer.org> Date: Wed, 30 Apr 2008 10:25:51 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Bruce M Simpson References: <20080429185100.57C2445010@ptavv.es.net> <4817743B.6090107@elischer.org> <48178452.4050700@FreeBSD.org> <4817881B.7010409@elischer.org> <4818926F.8010309@incunabulum.net> In-Reply-To: <4818926F.8010309@incunabulum.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , Kevin Oberman Subject: Re: multiple routing tables review patch ready for simple testing. 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, 30 Apr 2008 17:25:49 -0000 Bruce M Simpson wrote: > Julian Elischer wrote: >> An interface may however be present in entries from multiple FIBs >> in which case the INCOMING packets on that interface need to >> be disambiguated with respect to which FIB they belong to. > > Yes, there is no way the forwarding code alone can do this. > > It should not be expected to, and it's important to maintain a clean > functional separation there, otherwise one ends up in the same quagmire > which has been plaguing a lot of QoS research projects over the years > (Where do I put this bit of the system?) > >> >> This is a job for an outside entity (from the fibs). >> In this case a packet classifier such as pf or ipfw is ideal >> for the job. providing an outside mechanism for implementing >> whatever policy the admin wants to set up. > > Absolutely. This has been the intent from the beginning. > > There is no "one size fits all" approach here. We could put a packet > classifier into the kernel which works just fine for DOCSIS consumer > distribution networks, but has absolutely no relevance to an ATM > backbone (these are the two main flavours of access for folk in the UK). > >[...] >> It >> IS possible that an interface in the future might have a default >> plane, but I haven't implemented this. > > This limitation seems fine for now. [...] > > For SSM, the key (S,G) what's SSM? [...] > To summarize: > For now, the limitations of the system should be documented so that > users don't inadvertently configure local forwarding loops, even for > unicast traffic; with multicast, the amplification effect of > misconfiguration is inherently more damaging to a network. I'm not sure where I should add documentation. I haven't found the exact right place yet.. I have some notes but I haven't found a good place to put them > > cheers > BMS > > P.S. I see you tweaked verify_path() to do the lookup in the numbered > FIB. Cool. > > I should point out that for ad-hoc networks, the ability to turn off > RPF/uRPF for multicast is needed as the routing domain is often NOT > fully converged -- so the RPF checks normally present may discard > legitimate traffic which hasn't been forwarded yet. An encapsulation is > typically used to maintain forwarding state which is relevant to the > particular topology in use. I haven't changed any of that.. Basically I've kept clear of M/Cast. The way I see it, if you don't define ROUTETABLES=2 (or more) or don;t define it at all in your config then you get what you had before and I shouldn't have broken anything. I take it from this that you don't have any major complaints as far as what I've done. I'd like to get a few people to apply the diff and try it (more than just me for sure), and then I'd like to get it committed soon so that I can move on with it. I would like to get what is there now commited becasue it is a logical break before moving to more work. What is there is fully functional and consistent. and should be tested before more extensive changes occur so that we know where to look if there are problems. From owner-freebsd-net@FreeBSD.ORG Wed Apr 30 17:46:01 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 810FE106566C; Wed, 30 Apr 2008 17:46:01 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (ns1.bitblocks.com [64.142.15.60]) by mx1.freebsd.org (Postfix) with ESMTP id 57AB58FC18; Wed, 30 Apr 2008 17:46:01 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (localhost.bitblocks.com [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id 2E3275AD6; Wed, 30 Apr 2008 10:27:05 -0700 (PDT) To: Julian Elischer In-reply-to: Your message of "Tue, 29 Apr 2008 13:42:03 PDT." <4817881B.7010409@elischer.org> Date: Wed, 30 Apr 2008 10:27:05 -0700 From: Bakul Shah Message-Id: <20080430172705.2E3275AD6@mail.bitblocks.com> Cc: FreeBSD Net , "Bruce M. Simpson" , Kevin Oberman Subject: Re: multiple routing tables review patch ready for simple testing. 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, 30 Apr 2008 17:46:01 -0000 On Tue, 29 Apr 2008 13:42:03 PDT Julian Elischer wrote: > > Interfaces are not however assigned to FIB instance. each FIB may > contain entries for each interface, and by default they do, but you > can delete teh entries associated with a particular interface from > a particular FIB so that fib will never use that interface. > > An interface may however be present in entries from multiple FIBs > in which case the INCOMING packets on that interface need to > be disambiguated with respect to which FIB they belong to. This confuses me.... The whole point of a FIB is to decide the *next* hop for a given input packet. So questions. 1) A packet arrives on an interface. If this interface is associated with more than one FIB, which FIB does it get given to? 2) If that decision is taken by a a packet 'classifier', isn't it in effect doing the job of a FIB (deciding the next hop, which happens to be a local FIB)? Recall that basically a packet passes from a FIB to another FIB until it gets to its eventual destination. 3) When a local packets needs to be sent, which FIB gets it? Does setfib decides that? If there a default FIB? > This is a job for an outside entity (from the fibs). > In this case a packet classifier such as pf or ipfw is ideal > for the job. providing an outside mechanism for implementing > whatever policy the admin wants to set up. I believe having to use pf/ipfw will slow things down a bit so the question is what does associating an interface with multiple FIBs buy you? > if you have several alias addresses on an interface it is possible > that some FIBS know about some of them and others know about other > addresses. New addresses when added are added to each FIB and > whatever is adding them shoudl remove them from the ones that don't > need it. This may change but it fits in with how the current code > works and keeps the diff to a manageable size. > (and it suits what I need for work where a route manager daemon > knows to do this.) Wouldn't it make sense to treat each alias as on a separate logical interface? Then each logical interface belongs to exactly one FIB. On input you decide which logical inteface a packet arrived on by looking at its destination MAC address. That reduces confusion quite a bit, at least in my mind! What does doing more than this buy you? From owner-freebsd-net@FreeBSD.ORG Wed Apr 30 17:56:10 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C4261065671 for ; Wed, 30 Apr 2008 17:56:10 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id 3500D8FC26 for ; Wed, 30 Apr 2008 17:56:09 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 659761046ED; Wed, 30 Apr 2008 13:56:09 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 30 Apr 2008 13:56:09 -0400 X-Sasl-enc: C4SMOmoddiKT9Wu9JNZn4wD6r3+Rpf0zs+LVCpOAXv2h 1209578169 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id A342D1E7B3; Wed, 30 Apr 2008 13:56:08 -0400 (EDT) Message-ID: <4818B2B7.2070401@FreeBSD.org> Date: Wed, 30 Apr 2008 18:56:07 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.12 (X11/20080423) MIME-Version: 1.0 To: Bakul Shah References: <20080430172705.2E3275AD6@mail.bitblocks.com> In-Reply-To: <20080430172705.2E3275AD6@mail.bitblocks.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , Julian Elischer , Kevin Oberman Subject: Re: multiple routing tables review patch ready for simple testing. 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, 30 Apr 2008 17:56:10 -0000 Bakul Shah wrote: > 1) A packet arrives on an interface. If this interface is > associated with more than one FIB, which FIB does it get > given to? > If you only have a single FIB, there is no issue here. If you have multiple FIBs, the decision gets made by the classifier. > 2) If that decision is taken by a a packet 'classifier', > isn't it in effect doing the job of a FIB (deciding the > next hop, which happens to be a local FIB)? Recall that > basically a packet passes from a FIB to another FIB until > it gets to its eventual destination. > Up until now, the BSD forwarding code always forwarded packets on the basis of the destination address. In an IP environment this is totally reasonable. Most implementations work on this basis -- ultimately, there is a fan-out to a collection of tries which hold the prefix information, and there has to be a decision about which trie(s) to use for resolving the next-hop. Linux iproute2 works on this basis more or less. So the classifier is NOT doing the job of the FIB. > 3) When a local packets needs to be sent, which FIB gets it? > Does setfib decides that? If there a default FIB? > If you look at Julian's patch, he's added an option to the socket layer to control this. There is a default FIB which is used when no FIB tag exists. > I believe having to use pf/ipfw will slow things down a bit > so the question is what does associating an interface with > multiple FIBs buy you? > You only need to pass through pf/ipfw if you wish to source-route packets, or need to apply a forwarding policy decision more complex than the destination field, which is all rtalloc() has historically supported. If there is any additional latency or slowdown, it's down to how good your matching algorithms are as you enter the classifier. > > Wouldn't it make sense to treat each alias as on a separate > logical interface? Then each logical interface belongs to > exactly one FIB. On input you decide which logical inteface > a packet arrived on by looking at its destination MAC > address. That reduces confusion quite a bit, at least in my > mind! What does doing more than this buy you? > It doesn't buy anything because there is still no 1:1 mapping -- the link-layer destination address maps to an ifp, and multiple aliases exist on the ifp. You still need a classifier to look at other fields in the message and decide, based on policy, which FIB is used for next-hop resolution. Tag switching systems avoid the issue by prepending a tag, but of course, what does a packet go through upon entry to an MPLS domain? You guessed it: A classifier. cheers BMS From owner-freebsd-net@FreeBSD.ORG Wed Apr 30 18:02:06 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC2B5106566C for ; Wed, 30 Apr 2008 18:02:06 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id 982B78FC17 for ; Wed, 30 Apr 2008 18:02:06 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 47325E427D; Wed, 30 Apr 2008 14:02:06 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Wed, 30 Apr 2008 14:02:06 -0400 X-Sasl-enc: aMbGEFoXUAb4/l8zWABRx+R548Ga8aP/uGBH/5+mQ0au 1209578525 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 6EEB61781F; Wed, 30 Apr 2008 14:02:05 -0400 (EDT) Message-ID: <4818B41C.3090500@FreeBSD.org> Date: Wed, 30 Apr 2008 19:02:04 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.12 (X11/20080423) MIME-Version: 1.0 To: Bakul Shah References: <20080430172705.2E3275AD6@mail.bitblocks.com> <4818B2B7.2070401@FreeBSD.org> In-Reply-To: <4818B2B7.2070401@FreeBSD.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , Julian Elischer , Kevin Oberman Subject: Re: multiple routing tables review patch ready for simple testing. 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, 30 Apr 2008 18:02:06 -0000 Bruce M. Simpson wrote: >> >> Wouldn't it make sense to treat each alias as on a separate >> logical interface? Then each logical interface belongs to >> exactly one FIB. On input you decide which logical inteface >> a packet arrived on by looking at its destination MAC >> address. That reduces confusion quite a bit, at least in my >> mind! What does doing more than this buy you? >> > > It doesn't buy anything because there is still no 1:1 mapping -- the > link-layer destination address maps to an ifp, and multiple aliases > exist on the ifp. Let me qualify that further: You are talking about splitting network layer addresses onto their own logical interfaces, with the goal of having a 1:1 mapping for FIB resolution. This doesn't buy anything, because in IP, the previous hop never encodes the next-hop address it sends to -- it merely performs a lookup and forwards to you; your MAC address is the same for every IP address you have on the link, therefore it is not a unique identifier. UNLESS you use a separate MAC address for every IP alias which you add, in which case, you are merely pushing the mapping elsewhere in the stack; it actually adds more complexity in this case. From owner-freebsd-net@FreeBSD.ORG Wed Apr 30 18:08:13 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90628106568D for ; Wed, 30 Apr 2008 18:08:13 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id 5C2208FC15 for ; Wed, 30 Apr 2008 18:08:13 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id DA4A9104A0A; Wed, 30 Apr 2008 14:08:12 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 30 Apr 2008 14:08:12 -0400 X-Sasl-enc: yowCeEYZr4Jmo0RjI/HreOHRokVYeVhrmX1VrGCRbXc0 1209578892 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 408A424BF7; Wed, 30 Apr 2008 14:08:12 -0400 (EDT) Message-ID: <4818B58B.3050400@incunabulum.net> Date: Wed, 30 Apr 2008 19:08:11 +0100 From: Bruce M Simpson User-Agent: Thunderbird 2.0.0.12 (X11/20080423) MIME-Version: 1.0 To: Julian Elischer References: <20080429185100.57C2445010@ptavv.es.net> <4817743B.6090107@elischer.org> <48178452.4050700@FreeBSD.org> <4817881B.7010409@elischer.org> <4818926F.8010309@incunabulum.net> <4818AB9F.7000607@elischer.org> In-Reply-To: <4818AB9F.7000607@elischer.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , Kevin Oberman Subject: Re: multiple routing tables review patch ready for simple testing. 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, 30 Apr 2008 18:08:13 -0000 Julian Elischer wrote: > > what's SSM? Source-specific multicast, where multicast flows (channels) are identified by both their original source address, and group address. Multicast addresses have no meaning on their own beyond the scope of a single link. > I haven't changed any of that.. Basically I've kept clear of > M/Cast. The way I see it, if you don't define ROUTETABLES=2 (or more) > or don;t define it at all in your config then you get what you had > before and I shouldn't have broken anything. Cool! Doing multicast "right" is Hard. Doing it "right" in ad-hoc topologies is Harder. It makes sense to steer clear of it for now. It can no doubt benefit from the hierarchy offered by multiple FIBs, but again, the policy routing mechanisms don't really exist just now, and things like PIM need changes to encompass it. They will need to come into existence for the model to work on a macro scale, for the same reason SSM was put on the table. > > I take it from this that you don't have any major complaints > as far as what I've done. No problems here... I haven't tried testing. I would say though if we are going to be renaming rtalloc() and friends, that names should really change to be descriptive of what it does. It doesn't "allocate a route", it tries to look up a forwarding table entry, and returns a reference to it. cheers BMS From owner-freebsd-net@FreeBSD.ORG Wed Apr 30 18:29:56 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BB121065676 for ; Wed, 30 Apr 2008 18:29:56 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by mx1.freebsd.org (Postfix) with ESMTP id 2BC898FC26 for ; Wed, 30 Apr 2008 18:29:56 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: by yw-out-2324.google.com with SMTP id 5so328137ywh.13 for ; Wed, 30 Apr 2008 11:29:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; bh=5VYrOZtq7kI8dkycbZq2nzfUIzz8UjppzyIV+7kcnwo=; b=i1M7WbarKw4yu54YPzjmEV935vOLD/GKd7ypzoxGFlJa/Iw37qRZ77nuUv3Q5cQbxDewr29oGt5qQ5ySpE97aCQCnupbgnE+dJkrZoSYk4QvsGlfFWX2KjZoZlnS7nqTS7kIvsW5b+vAne06O8ENipMgpLk53Iutef0Lm3yUgZA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=g5MBHOeYabXbLdt217VKQGC1NgKrlS1/bz2OY/a8w3gcW77OV7trE2pl9DePPqoPSPPDKSFnbPQOj0vO8/kYYvVd2HOq5t3INVIMZwP4ditdz9GREHapta6sW/xUcyjTbcZBJBh6+b2mYRIs/HofvsQ/JuklGrtVrsHTm6cvbuc= Received: by 10.142.58.5 with SMTP id g5mr416118wfa.178.1209578481600; Wed, 30 Apr 2008 11:01:21 -0700 (PDT) Received: by 10.143.37.11 with HTTP; Wed, 30 Apr 2008 11:01:21 -0700 (PDT) Message-ID: <2e77fc10804301101i57c73a32n8273f7a8a96b7e6f@mail.gmail.com> Date: Wed, 30 Apr 2008 14:01:21 -0400 From: "Niki Denev" Sender: ndenev@gmail.com To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2525_18964599.1209578481602" X-Google-Sender-Auth: 59bfb918baba77c6 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: [PATCH] autoload if_vlan.ko on vlan creation 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, 30 Apr 2008 18:29:56 -0000 ------=_Part_2525_18964599.1209578481602 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I've noticed that autoloading of if_vlan.ko on vlan creation does not work in the case when the vlans are specified with the interface name. i.e. : fxp0.5 And the problem is that ifmaybeload() in ifconfig.c expects that all interfaces are in the format : if_${driver}${number}, which is not the case for vlans created in the above mentioned way (which is much more easier and intuitive IMHO) This patch fixes this for me, and probably others may find it useful. P.S.: Because of the assumption for the interface name that ifmaybeload() does, this patch looks more like a hack and probably a better way could be found for handling this case. P.S2: If "ifconfig fxp0." is typed this will autoload if_vlan.ko because we have a dot after the first number in the interface name (there is no check if there are other digits after the dot). I'm not sure if a more strict check is needed though because I can't imagine this can cause any real problems. --- ifconfig.c.orig 2008-04-30 12:29:25.000000000 -0400 +++ ifconfig.c 2008-04-30 12:44:50.000000000 -0400 @@ -935,18 +935,21 @@ if (noload) return; - /* trim the interface number off the end */ + /* locate interface number beginning */ strlcpy(ifname, name, sizeof(ifname)); for (dp = ifname; *dp != 0; dp++) - if (isdigit(*dp)) { - *dp = 0; + if (isdigit(*dp)) break; - } - /* turn interface and unit into module name */ - strcpy(ifkind, "if_"); - strlcpy(ifkind + MOD_PREFIX_LEN, ifname, - sizeof(ifkind) - MOD_PREFIX_LEN); + /* check the special case for vlan interfaces */ + if (strchr(dp, '.')) { + strcpy(ifkind, "if_vlan"); + } else { + /* turn interface and unit into module name */ + strcpy(ifkind, "if_"); + strlcpy(ifkind + MOD_PREFIX_LEN, ifname, + sizeof(ifkind) - MOD_PREFIX_LEN); + } /* scan files in kernel */ mstat.version = sizeof(struct module_stat); ------=_Part_2525_18964599.1209578481602 Content-Type: text/x-patch; name=ifconfig-vlan_create.patch Content-Transfer-Encoding: base64 X-Attachment-Id: f_ffo5m1pu0 Content-Disposition: attachment; filename=ifconfig-vlan_create.patch LS0tIGlmY29uZmlnLmMub3JpZwkyMDA4LTA0LTMwIDEyOjI5OjI1LjAwMDAwMDAwMCAtMDQwMAor KysgaWZjb25maWcuYwkyMDA4LTA0LTMwIDEyOjQ0OjUwLjAwMDAwMDAwMCAtMDQwMApAQCAtOTM1 LDE4ICs5MzUsMjEgQEAKIAlpZiAobm9sb2FkKQogCQlyZXR1cm47CiAKLQkvKiB0cmltIHRoZSBp bnRlcmZhY2UgbnVtYmVyIG9mZiB0aGUgZW5kICovCisJLyogbG9jYXRlIGludGVyZmFjZSBudW1i ZXIgYmVnaW5uaW5nICovCiAJc3RybGNweShpZm5hbWUsIG5hbWUsIHNpemVvZihpZm5hbWUpKTsK IAlmb3IgKGRwID0gaWZuYW1lOyAqZHAgIT0gMDsgZHArKykKLQkJaWYgKGlzZGlnaXQoKmRwKSkg ewotCQkJKmRwID0gMDsKKwkJaWYgKGlzZGlnaXQoKmRwKSkKIAkJCWJyZWFrOwotCQl9CiAKLQkv KiB0dXJuIGludGVyZmFjZSBhbmQgdW5pdCBpbnRvIG1vZHVsZSBuYW1lICovCi0Jc3RyY3B5KGlm a2luZCwgImlmXyIpOwotCXN0cmxjcHkoaWZraW5kICsgTU9EX1BSRUZJWF9MRU4sIGlmbmFtZSwK LQkgICAgc2l6ZW9mKGlma2luZCkgLSBNT0RfUFJFRklYX0xFTik7CisJLyogY2hlY2sgdGhlIHNw ZWNpYWwgY2FzZSBmb3IgdmxhbiBpbnRlcmZhY2VzICovCisJaWYgKHN0cmNocihkcCwgJy4nKSkg eworCQlzdHJjcHkoaWZraW5kLCAiaWZfdmxhbiIpOworCX0gZWxzZSB7CisJCS8qIHR1cm4gaW50 ZXJmYWNlIGFuZCB1bml0IGludG8gbW9kdWxlIG5hbWUgKi8KKwkJc3RyY3B5KGlma2luZCwgImlm XyIpOworCQlzdHJsY3B5KGlma2luZCArIE1PRF9QUkVGSVhfTEVOLCBpZm5hbWUsCisJCSAgICBz aXplb2YoaWZraW5kKSAtIE1PRF9QUkVGSVhfTEVOKTsKKwl9CiAKIAkvKiBzY2FuIGZpbGVzIGlu IGtlcm5lbCAqLwogCW1zdGF0LnZlcnNpb24gPSBzaXplb2Yoc3RydWN0IG1vZHVsZV9zdGF0KTsK ------=_Part_2525_18964599.1209578481602-- From owner-freebsd-net@FreeBSD.ORG Wed Apr 30 18:37:43 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDB4C106568A for ; Wed, 30 Apr 2008 18:37:43 +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 99F868FC29 for ; Wed, 30 Apr 2008 18:37:43 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Wed, 30 Apr 2008 16:54:52 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id D20762D6011; Wed, 30 Apr 2008 11:37:42 -0700 (PDT) Message-ID: <4818BC79.40605@elischer.org> Date: Wed, 30 Apr 2008 11:37:45 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Bakul Shah References: <20080430172705.2E3275AD6@mail.bitblocks.com> In-Reply-To: <20080430172705.2E3275AD6@mail.bitblocks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , "Bruce M. Simpson" , Kevin Oberman Subject: Re: multiple routing tables review patch ready for simple testing. 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, 30 Apr 2008 18:37:43 -0000 Bakul Shah wrote: > On Tue, 29 Apr 2008 13:42:03 PDT Julian Elischer wrote: >> Interfaces are not however assigned to FIB instance. each FIB may >> contain entries for each interface, and by default they do, but you >> can delete teh entries associated with a particular interface from >> a particular FIB so that fib will never use that interface. >> >> An interface may however be present in entries from multiple FIBs >> in which case the INCOMING packets on that interface need to >> be disambiguated with respect to which FIB they belong to. > > This confuses me.... > > The whole point of a FIB is to decide the *next* hop for a > given input packet. So questions. > 1) A packet arrives on an interface. If this interface is > associated with more than one FIB, which FIB does it get > given to? > which ever one you select, using the policy of your choice. that's what policy routing is about. if you don't WANT policy based routing, dont turn it on. > 2) If that decision is taken by a a packet 'classifier', > isn't it in effect doing the job of a FIB (deciding the > next hop, which happens to be a local FIB)? Recall that > basically a packet passes from a FIB to another FIB until > it gets to its eventual destination. the packet classifier selects a FIB which in turn implements a particular routing decision tree. In the degenerate case where a FIB has only one route then you are correct, but there are technical reasons why this is superior to just using a fwd rule in the firewall. > > 3) When a local packets needs to be sent, which FIB gets it? > Does setfib decides that? If there a default FIB? the socket has a fib assocuated with it. it is inherrited from the process which has a fib associated with it, which it inherrited from its parent which probbaly used the setfib syscall. A process can also use the setfib socket option to make a socket with a different FIB to its own default fib. > >> This is a job for an outside entity (from the fibs). >> In this case a packet classifier such as pf or ipfw is ideal >> for the job. providing an outside mechanism for implementing >> whatever policy the admin wants to set up. > > I believe having to use pf/ipfw will slow things down a bit > so the question is what does associating an interface with > multiple FIBs buy you? interfaces are not associated with FIBS on input. Just output.. i.e. a FIB knows about an interface or it doesn't. If it doesn't know about it it can't send an packets out that way can it? > >> if you have several alias addresses on an interface it is possible >> that some FIBS know about some of them and others know about other >> addresses. New addresses when added are added to each FIB and >> whatever is adding them shoudl remove them from the ones that don't >> need it. This may change but it fits in with how the current code >> works and keeps the diff to a manageable size. >> (and it suits what I need for work where a route manager daemon >> knows to do this.) > > Wouldn't it make sense to treat each alias as on a separate > logical interface? Then each logical interface belongs to > exactly one FIB. On input you decide which logical inteface > a packet arrived on by looking at its destination MAC > address. That reduces confusion quite a bit, at least in my > mind! What does doing more than this buy you? you are talking about vimage (for FreeBSD) or what cisco calls VRF. Stop thinking about receive interfaces... routing is only intersted in OUTGOING interfaces. From owner-freebsd-net@FreeBSD.ORG Wed Apr 30 18:41:47 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8EDF6106564A for ; Wed, 30 Apr 2008 18:41:47 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outD.internet-mail-service.net (outd.internet-mail-service.net [216.240.47.227]) by mx1.freebsd.org (Postfix) with ESMTP id 6BA1C8FC20 for ; Wed, 30 Apr 2008 18:41:47 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Wed, 30 Apr 2008 16:58:56 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id AD4E42D6011; Wed, 30 Apr 2008 11:41:46 -0700 (PDT) Message-ID: <4818BD6D.40806@elischer.org> Date: Wed, 30 Apr 2008 11:41:49 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: "Bruce M. Simpson" References: <20080430172705.2E3275AD6@mail.bitblocks.com> <4818B2B7.2070401@FreeBSD.org> In-Reply-To: <4818B2B7.2070401@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Bakul Shah , FreeBSD Net , Kevin Oberman Subject: Re: multiple routing tables review patch ready for simple testing. 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, 30 Apr 2008 18:41:47 -0000 Bruce M. Simpson wrote: > Bakul Shah wrote: >> 1) A packet arrives on an interface. If this interface is >> associated with more than one FIB, which FIB does it get >> given to? >> > > If you only have a single FIB, there is no issue here. > If you have multiple FIBs, the decision gets made by the classifier. > >> 2) If that decision is taken by a a packet 'classifier', >> isn't it in effect doing the job of a FIB (deciding the >> next hop, which happens to be a local FIB)? Recall that >> basically a packet passes from a FIB to another FIB until >> it gets to its eventual destination. >> > > Up until now, the BSD forwarding code always forwarded packets on the > basis of the destination address. > > In an IP environment this is totally reasonable. Most implementations > work on this basis -- ultimately, there is a fan-out to a collection of > tries which hold the prefix information, and there has to be a decision > about which trie(s) to use for resolving the next-hop. Linux iproute2 > works on this basis more or less. > > So the classifier is NOT doing the job of the FIB. > >> 3) When a local packets needs to be sent, which FIB gets it? >> Does setfib decides that? If there a default FIB? >> > > If you look at Julian's patch, he's added an option to the socket layer > to control this. > There is a default FIB which is used when no FIB tag exists. actually this ha changed in the latest code.. now all packets have a fib. as do all sockets and processes. If you do nothing those values are all 0 meaning FIB 0. > > >> I believe having to use pf/ipfw will slow things down a bit >> so the question is what does associating an interface with >> multiple FIBs buy you? >> > > You only need to pass through pf/ipfw if you wish to source-route > packets, or need to apply a forwarding policy decision more complex than > the destination field, which is all rtalloc() has historically supported. > > If there is any additional latency or slowdown, it's down to how good > your matching algorithms are as you enter the classifier. > >> >> Wouldn't it make sense to treat each alias as on a separate >> logical interface? Then each logical interface belongs to >> exactly one FIB. On input you decide which logical inteface >> a packet arrived on by looking at its destination MAC >> address. That reduces confusion quite a bit, at least in my >> mind! What does doing more than this buy you? >> > > It doesn't buy anything because there is still no 1:1 mapping -- the > link-layer destination address maps to an ifp, and multiple aliases > exist on the ifp. > > You still need a classifier to look at other fields in the message and > decide, based on policy, which FIB is used for next-hop resolution. > > Tag switching systems avoid the issue by prepending a tag, but of > course, what does a packet go through upon entry to an MPLS domain? > > You guessed it: A classifier. > > cheers > BMS > From owner-freebsd-net@FreeBSD.ORG Wed Apr 30 18:47:30 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90BB2106564A for ; Wed, 30 Apr 2008 18:47:30 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outZ.internet-mail-service.net (outz.internet-mail-service.net [216.240.47.249]) by mx1.freebsd.org (Postfix) with ESMTP id 6C1978FC23 for ; Wed, 30 Apr 2008 18:47:30 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Wed, 30 Apr 2008 17:04:40 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id A90012D6006; Wed, 30 Apr 2008 11:47:29 -0700 (PDT) Message-ID: <4818BEC4.7060800@elischer.org> Date: Wed, 30 Apr 2008 11:47:32 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Bruce M Simpson References: <20080429185100.57C2445010@ptavv.es.net> <4817743B.6090107@elischer.org> <48178452.4050700@FreeBSD.org> <4817881B.7010409@elischer.org> <4818926F.8010309@incunabulum.net> <4818AB9F.7000607@elischer.org> <4818B58B.3050400@incunabulum.net> In-Reply-To: <4818B58B.3050400@incunabulum.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , Kevin Oberman Subject: Re: multiple routing tables review patch ready for simple testing. 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, 30 Apr 2008 18:47:30 -0000 Bruce M Simpson wrote: > Julian Elischer wrote: >> >> what's SSM? > > Source-specific multicast, where multicast flows (channels) are > identified by both their original source address, and group address. > Multicast addresses have no meaning on their own beyond the scope of a > single link. > >> I haven't changed any of that.. Basically I've kept clear of >> M/Cast. The way I see it, if you don't define ROUTETABLES=2 (or more) >> or don;t define it at all in your config then you get what you had >> before and I shouldn't have broken anything. > > Cool! Doing multicast "right" is Hard. Doing it "right" in ad-hoc > topologies is Harder. > > It makes sense to steer clear of it for now. It can no doubt benefit > from the hierarchy offered by multiple FIBs, but again, the policy > routing mechanisms don't really exist just now, and things like PIM need > changes to encompass it. > > They will need to come into existence for the model to work on a macro > scale, for the same reason SSM was put on the table. > >> >> I take it from this that you don't have any major complaints >> as far as what I've done. > > No problems here... I haven't tried testing. please please do.. just apply the patch to a regular source tree and compile.. :-) > > I would say though if we are going to be renaming rtalloc() and friends, > that names should really change to be descriptive of what it does. > It doesn't "allocate a route", it tries to look up a forwarding table > entry, and returns a reference to it. It's important to not break source compatibility for 3rd party suppliers and users. (e.g. ironport, juniper, nokia, issilon, etc. etc.) they know about rtalloc... having said that I do plan on a pass over the code to rationalise some of the names that may have "evolved" during developement of the patch. > > cheers > BMS From owner-freebsd-net@FreeBSD.ORG Wed Apr 30 18:50:04 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76AF41065670 for ; Wed, 30 Apr 2008 18:50:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5B2318FC22 for ; Wed, 30 Apr 2008 18:50:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m3UIo4bX061646 for ; Wed, 30 Apr 2008 18:50:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m3UIo4E8061645; Wed, 30 Apr 2008 18:50:04 GMT (envelope-from gnats) Date: Wed, 30 Apr 2008 18:50:04 GMT Message-Id: <200804301850.m3UIo4E8061645@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: hotlips Internet admin Cc: Subject: Re: kern/122875: "rstatd: Can't get namelist. 1" - fbsd 7.0-stable (works ok in 7.0-release) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hotlips Internet admin List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2008 18:50:04 -0000 The following reply was made to PR kern/122875; it has been noted by GNATS. From: hotlips Internet admin To: Kris Kennaway Cc: bug-followup@FreeBSD.org Subject: Re: kern/122875: "rstatd: Can't get namelist. 1" - fbsd 7.0-stable (works ok in 7.0-release) Date: Wed, 30 Apr 2008 14:32:56 -0400 (EDT) On Mon, 28 Apr 2008, Kris Kennaway wrote: |hotlips Internet admin wrote: |> The following reply was made to PR kern/122875; it has been noted by GNATS. |> |> From: hotlips Internet admin |> To: FreeBSD-gnats-submit@FreeBSD.org, freebsd-bugs@FreeBSD.org |> Cc: bug-followup@FreeBSD.org |> Subject: Re: kern/122875: "rstatd: Can't get namelist. 1" - fbsd 7.0-stable |> (works ok in 7.0-release) |> Date: Fri, 25 Apr 2008 20:50:51 -0400 (EDT) |> |> On Fri, 18 Apr 2008 FreeBSD-gnats-submit@FreeBSD.org wrote: |> |Thank you very much for your problem report. |> |It has the internal identification `kern/122875'. |> |The individual assigned to look at your |> |report is: freebsd-bugs. | |> |You can access the state of your problem report at any time |> |via this link: |> | |> |http://www.freebsd.org/cgi/query-pr.cgi?pr=122875 |> | |> |>Category: kern |> |>Responsible: freebsd-bugs |> |>Synopsis: "rstatd: Can't get namelist. 1" - fbsd 7.0-stable (works |> ok in 7.0-release) |> |>Arrival-Date: Fri Apr 18 02:20:00 UTC 2008 |> this also happens in FreeBSD 6.3-STABLE |> I depend heavily on rpc.rstatd as a part of monitoring |> servers and firewalls etc., so this is a serious issue |> for me until I can get a fix or work-around | |Revert the recent commits by Peter until a fix is applied. I'm not sure if this is something i should do locally, or whether those commites are being reverted in the FBSD source tree if it's someting to do locally, I would need to know what to do in detail ... this also seems related to PR ports/123146 btw ... Thanks, Bruce Becker +1 416 410 0879 GTS Network Administration Toronto, Ont. Email: hostmaster@GTS.Infra-service.CA From owner-freebsd-net@FreeBSD.ORG Wed Apr 30 18:50:12 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36C431065673 for ; Wed, 30 Apr 2008 18:50:12 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (cl-162.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:a1::2]) by mx1.freebsd.org (Postfix) with ESMTP id CAF268FC17 for ; Wed, 30 Apr 2008 18:50:11 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.2/8.14.2) with ESMTP id m3UIoMP1099579; Wed, 30 Apr 2008 13:50:22 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.2/8.14.2/Submit) id m3UIoM9h099578; Wed, 30 Apr 2008 13:50:22 -0500 (CDT) (envelope-from brooks) Date: Wed, 30 Apr 2008 13:50:21 -0500 From: Brooks Davis To: Niki Denev Message-ID: <20080430185021.GA99435@lor.one-eyed-alien.net> References: <2e77fc10804301101i57c73a32n8273f7a8a96b7e6f@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7JfCtLOvnd9MIVvH" Content-Disposition: inline In-Reply-To: <2e77fc10804301101i57c73a32n8273f7a8a96b7e6f@mail.gmail.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Wed, 30 Apr 2008 13:50:22 -0500 (CDT) Cc: freebsd-net@freebsd.org Subject: Re: [PATCH] autoload if_vlan.ko on vlan creation 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, 30 Apr 2008 18:50:12 -0000 --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 30, 2008 at 02:01:21PM -0400, Niki Denev wrote: > Hi, >=20 > I've noticed that autoloading of if_vlan.ko on vlan creation does not > work in the case when the vlans are specified with the interface name. > i.e. : fxp0.5 And the problem is that ifmaybeload() in ifconfig.c > expects that all interfaces are in the format : if_${driver}${number}, > which is not the case for vlans created in the above mentioned way > (which is much more easier and intuitive IMHO) This patch fixes this > for me, and probably others may find it useful. What is the practical use of this feature? If you don't have the module loaded, the rc scripts won't even see the interface unless you manually set network_interfaces which has been documented as a deprecated configuration since 6.2 and will soon generate warnings in 7-stable. If you want to use an interface, why not add an appropriate entry to /boot/loader.conf and be done with it? -- Brooks > P.S.: Because of the assumption for the interface name that > ifmaybeload() does, this patch looks more like a hack and probably a > better way could be found for handling this case. P.S2: If "ifconfig > fxp0." is typed this will autoload if_vlan.ko because we have a dot > after the first number in the interface name (there is no check if > there are other digits after the dot). I'm not sure if a more strict > check is needed though because I can't imagine this can cause any real > problems. > >=20 > --- ifconfig.c.orig 2008-04-30 12:29:25.000000000 -0400 > +++ ifconfig.c 2008-04-30 12:44:50.000000000 -0400 > @@ -935,18 +935,21 @@ > if (noload) > return; >=20 > - /* trim the interface number off the end */ > + /* locate interface number beginning */ > strlcpy(ifname, name, sizeof(ifname)); > for (dp =3D ifname; *dp !=3D 0; dp++) > - if (isdigit(*dp)) { > - *dp =3D 0; > + if (isdigit(*dp)) > break; > - } >=20 > - /* turn interface and unit into module name */ > - strcpy(ifkind, "if_"); > - strlcpy(ifkind + MOD_PREFIX_LEN, ifname, > - sizeof(ifkind) - MOD_PREFIX_LEN); > + /* check the special case for vlan interfaces */ > + if (strchr(dp, '.')) { > + strcpy(ifkind, "if_vlan"); > + } else { > + /* turn interface and unit into module name */ > + strcpy(ifkind, "if_"); > + strlcpy(ifkind + MOD_PREFIX_LEN, ifname, > + sizeof(ifkind) - MOD_PREFIX_LEN); > + } >=20 > /* scan files in kernel */ > mstat.version =3D sizeof(struct module_stat); > --- ifconfig.c.orig 2008-04-30 12:29:25.000000000 -0400 > +++ ifconfig.c 2008-04-30 12:44:50.000000000 -0400 > @@ -935,18 +935,21 @@ > if (noload) > return; > =20 > - /* trim the interface number off the end */ > + /* locate interface number beginning */ > strlcpy(ifname, name, sizeof(ifname)); > for (dp =3D ifname; *dp !=3D 0; dp++) > - if (isdigit(*dp)) { > - *dp =3D 0; > + if (isdigit(*dp)) > break; > - } > =20 > - /* turn interface and unit into module name */ > - strcpy(ifkind, "if_"); > - strlcpy(ifkind + MOD_PREFIX_LEN, ifname, > - sizeof(ifkind) - MOD_PREFIX_LEN); > + /* check the special case for vlan interfaces */ > + if (strchr(dp, '.')) { > + strcpy(ifkind, "if_vlan"); > + } else { > + /* turn interface and unit into module name */ > + strcpy(ifkind, "if_"); > + strlcpy(ifkind + MOD_PREFIX_LEN, ifname, > + sizeof(ifkind) - MOD_PREFIX_LEN); > + } > =20 > /* scan files in kernel */ > mstat.version =3D sizeof(struct module_stat); > _______________________________________________ > 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" --7JfCtLOvnd9MIVvH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iD8DBQFIGL9tXY6L6fI4GtQRAgm2AJ9iuk9gxNQv2KGYKWO12XhCPnqbhwCfW8+k n0CgByPsxk3xfMcl5cUwMQ8= =BiHs -----END PGP SIGNATURE----- --7JfCtLOvnd9MIVvH-- From owner-freebsd-net@FreeBSD.ORG Wed Apr 30 19:13:45 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3AC6A106567A; Wed, 30 Apr 2008 19:13:45 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (mail.bitblocks.com [64.142.15.60]) by mx1.freebsd.org (Postfix) with ESMTP id 0E9228FC0C; Wed, 30 Apr 2008 19:13:45 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (localhost.bitblocks.com [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id 6C4B95AD6; Wed, 30 Apr 2008 12:13:44 -0700 (PDT) To: "Bruce M. Simpson" In-reply-to: Your message of "Wed, 30 Apr 2008 18:56:07 BST." <4818B2B7.2070401@FreeBSD.org> Date: Wed, 30 Apr 2008 12:13:44 -0700 From: Bakul Shah Message-Id: <20080430191344.6C4B95AD6@mail.bitblocks.com> Cc: FreeBSD Net , Julian Elischer , Kevin Oberman Subject: Re: multiple routing tables review patch ready for simple testing. 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, 30 Apr 2008 19:13:45 -0000 On Wed, 30 Apr 2008 18:56:07 BST "Bruce M. Simpson" wrote: > > 2) If that decision is taken by a a packet 'classifier', > > isn't it in effect doing the job of a FIB (deciding the > > next hop, which happens to be a local FIB)? Recall that > > basically a packet passes from a FIB to another FIB until > > it gets to its eventual destination. > > > > Up until now, the BSD forwarding code always forwarded packets on the > basis of the destination address. > > In an IP environment this is totally reasonable. Most implementations > work on this basis -- ultimately, there is a fan-out to a collection of > tries which hold the prefix information, and there has to be a decision > about which trie(s) to use for resolving the next-hop. Linux iproute2 > works on this basis more or less. > > So the classifier is NOT doing the job of the FIB. Thanks for the explanation! I guess we look at it somewhat differently. You seem to imply that using anything other than destination address is not a FIB's job. While to me a FIB can use anything it wants for its forwarding decision. > > Wouldn't it make sense to treat each alias as on a separate > > logical interface? Then each logical interface belongs to > > exactly one FIB. On input you decide which logical inteface > > a packet arrived on by looking at its destination MAC > > address. That reduces confusion quite a bit, at least in my > > mind! What does doing more than this buy you? > > > > It doesn't buy anything because there is still no 1:1 mapping -- the > link-layer destination address maps to an ifp, and multiple aliases > exist on the ifp. > > You still need a classifier to look at other fields in the message and > decide, based on policy, which FIB is used for next-hop resolution. Hmm... a few years ago when we looked at this stuff in the context of hardware assisted forwarding that used more than just the destination ip address (probably you'd call it "policy based routing"), it was not clear to me at the time whether it made sense to separate such classification. We were looking at a function something like nexthop = lookup(protocol, src addr, dst addr, src port, dst port, ...) I suppose it makes sense to feed everything except the dst addr to a classifier when doing this in software (and may be even hardware but there you have different constraints). For us the entire "forwarding table/classifier" was really just a funky microprogram. That is, each microinstruction ate some bits of a packet and decided which next instruction to fetch and execute. It wasn't clear to me at the time which was better -- should it eat the dst addr first or last. From owner-freebsd-net@FreeBSD.ORG Wed Apr 30 19:40:01 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C9CB1065677 for ; Wed, 30 Apr 2008 19:40:01 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.231]) by mx1.freebsd.org (Postfix) with ESMTP id 5504E8FC12 for ; Wed, 30 Apr 2008 19:39:56 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so381532rvf.43 for ; Wed, 30 Apr 2008 12:39:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=MNSNKFWO3RWyX4I36/gAAMpwwUorcG9mvxzDwN9rQI8=; b=d+0i+b2neItwmOciS8QbJH9LZR/ibj3v9Fg2XYlL7Ea2DudpPHAuIAOLhN4DPtDt4365DOq9GzfVyHHvnS4EMDJeiTutseEl5ZTNbwlS12KxX0ZPSkJ0icLqtEV74o/FrhRBZmE66VNYtShLwhCEneYk7wrBBphyuSfwqpnw6IE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=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=XQjggxPmqBinwn3cPCpI/Bf9jhKTyg84IoNoW61WwIyvZNvLw/z33U1XqDGAfA6OjrN7PLTWPbVfTMPYwOuNS1cbt4+/4v6Y9LvMz4UE2EA5wuxcYwMg7YHGFTS1qWsQCwRsMl9R2ECxovPk1UjeWm3TKLu14S9KYyFnOpVdhFc= Received: by 10.141.133.14 with SMTP id k14mr477352rvn.127.1209584395745; Wed, 30 Apr 2008 12:39:55 -0700 (PDT) Received: by 10.140.207.1 with HTTP; Wed, 30 Apr 2008 12:39:55 -0700 (PDT) Message-ID: <2e77fc10804301239v38fec840k24a2f3cdf2185344@mail.gmail.com> Date: Wed, 30 Apr 2008 15:39:55 -0400 From: "Niki Denev" Sender: ndenev@gmail.com To: "Brooks Davis" In-Reply-To: <20080430185021.GA99435@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2e77fc10804301101i57c73a32n8273f7a8a96b7e6f@mail.gmail.com> <20080430185021.GA99435@lor.one-eyed-alien.net> X-Google-Sender-Auth: 9c5d5c1ff8b9712f Cc: freebsd-net@freebsd.org Subject: Re: [PATCH] autoload if_vlan.ko on vlan creation 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, 30 Apr 2008 19:40:01 -0000 On Wed, Apr 30, 2008 at 2:50 PM, Brooks Davis wrote: > What is the practical use of this feature? If you don't have the > module loaded, the rc scripts won't even see the interface unless > you manually set network_interfaces which has been documented as a > deprecated configuration since 6.2 and will soon generate warnings in > 7-stable. If you want to use an interface, why not add an appropriate > entry to /boot/loader.conf and be done with it? > > -- Brooks > Well, it just bugged me that : ifconfig bridge|vlan|lagg create all autoload the required modules, while ifconfig fxp0.5 create does not. Anyways, the patch seems to be broken and probably fixing this just for one special case is not worth it... From owner-freebsd-net@FreeBSD.ORG Wed Apr 30 19:44:27 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C338106567F for ; Wed, 30 Apr 2008 19:44:27 +0000 (UTC) (envelope-from SRS0=3651f749e0b1fec988a2721464be7e35dc7f3a59=687=es.net=oberman@es.net) Received: from postal1.es.net (postal3.es.net [IPv6:2001:400:14:3::8]) by mx1.freebsd.org (Postfix) with ESMTP id C72AE8FC1F for ; Wed, 30 Apr 2008 19:44:26 +0000 (UTC) (envelope-from SRS0=3651f749e0b1fec988a2721464be7e35dc7f3a59=687=es.net=oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal3.es.net (Postal Node 3) with ESMTP (SSL) id KXW41925; Wed, 30 Apr 2008 12:44:25 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 3225A45010; Wed, 30 Apr 2008 12:44:25 -0700 (PDT) To: Julian Elischer In-Reply-To: Your message of "Wed, 30 Apr 2008 10:25:51 PDT." <4818AB9F.7000607@elischer.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1209584665_28987P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Wed, 30 Apr 2008 12:44:25 -0700 From: "Kevin Oberman" Message-Id: <20080430194425.3225A45010@ptavv.es.net> X-Sender-IP: 198.128.4.29 X-Sender-Domain: es.net X-Recipent: ; ; ; X-Sender: X-To_Name: Julian Elischer X-To_Domain: elischer.org X-To: Julian Elischer X-To_Email: julian@elischer.org X-To_Alias: julian Cc: FreeBSD Net , Bruce M Simpson Subject: Re: multiple routing tables review patch ready for simple testing. 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, 30 Apr 2008 19:44:27 -0000 --==_Exmh_1209584665_28987P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Date: Wed, 30 Apr 2008 10:25:51 -0700 > From: Julian Elischer > > Bruce M Simpson wrote: > > Julian Elischer wrote: > >> An interface may however be present in entries from multiple FIBs > >> in which case the INCOMING packets on that interface need to > >> be disambiguated with respect to which FIB they belong to. > > > > Yes, there is no way the forwarding code alone can do this. > > > > It should not be expected to, and it's important to maintain a clean > > functional separation there, otherwise one ends up in the same quagmire > > which has been plaguing a lot of QoS research projects over the years > > (Where do I put this bit of the system?) > > > >> > >> This is a job for an outside entity (from the fibs). > >> In this case a packet classifier such as pf or ipfw is ideal > >> for the job. providing an outside mechanism for implementing > >> whatever policy the admin wants to set up. > > > > Absolutely. This has been the intent from the beginning. > > > > There is no "one size fits all" approach here. We could put a packet > > classifier into the kernel which works just fine for DOCSIS consumer > > distribution networks, but has absolutely no relevance to an ATM > > backbone (these are the two main flavours of access for folk in the UK). > > > >[...] > > >> It > >> IS possible that an interface in the future might have a default > >> plane, but I haven't implemented this. > > > > > This limitation seems fine for now. > [...] > > > > > > For SSM, the key (S,G) > > what's SSM? Source Specific Multicast. It is a scheme for finding the source of a multicast stream without the need for MSDP. It is intended for broadcasting (in the radio/TV sense) streams from a single source. It is not suitable for conferencing as it can't work with multiple sources. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 --==_Exmh_1209584665_28987P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFIGMwZkn3rs5h7N1ERAoFQAJ0bKR34GDW4c7b9rZnoh8mBzxJppwCfcpVa d0dvYqJDKqZ3zuJsBBYwvyc= =jWLj -----END PGP SIGNATURE----- --==_Exmh_1209584665_28987P-- From owner-freebsd-net@FreeBSD.ORG Thu May 1 02:26:31 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 110BA106566C for ; Thu, 1 May 2008 02:26:31 +0000 (UTC) (envelope-from jonathan@kc8onw.net) Received: from mail-out2.fuse.net (mail-out2.fuse.net [216.68.8.171]) by mx1.freebsd.org (Postfix) with ESMTP id C72B78FC0A for ; Thu, 1 May 2008 02:26:30 +0000 (UTC) (envelope-from jonathan@kc8onw.net) X-CNFS-Analysis: v=1.0 c=1 a=QwBCIUr-RsEA:15 a=VuYw-kHUr20A:10 a=X86uxc7E6I0A:10 a=xUvkYoQocQKi/8Los98NoQ==:17 a=gwAFgIw1VGRuyHzWO4kA:9 a=Ovye5kR-A5DjkN21WFwA:7 a=DZkLKB85kF1ygLJytfmU2BjwBOwA:4 a=4akr5DboAQwA:10 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Received: from [208.102.162.227] ([208.102.162.227:50587] helo=mail.kc8onw.net) by mail-out2.fuse.net (ecelerity 2.1.1.22 r(17669)) with ESMTP id A4/9F-06210-0D629184 for ; Wed, 30 Apr 2008 22:11:28 -0400 Received: from www.kc8onw.net (localhost [127.0.0.1]) by mail.kc8onw.net (Postfix) with ESMTP id 88B5D28415 for ; Wed, 30 Apr 2008 22:11:28 -0400 (EDT) Received: from 214.13.212.26 (SquirrelMail authenticated user jonathan) by www.kc8onw.net with HTTP; Wed, 30 Apr 2008 22:11:28 -0400 (EDT) Message-ID: <58369.214.13.212.26.1209607888.squirrel@www.kc8onw.net> Date: Wed, 30 Apr 2008 22:11:28 -0400 (EDT) From: jonathan@kc8onw.net To: freebsd-net@freebsd.org User-Agent: SquirrelMail/1.5.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: em1: Unable to allocate bus resource: memory 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, 01 May 2008 02:26:31 -0000 (Please CC as I'm not subscribed to net@) I bought a new PCIe NIC a few months ago and was working with Jack Vogel on getting it to work but he was busy, then I got busy and things stalled. Does anyone else have any idea what might be wrong here? The card is recognized but the em driver fails to initialize it for some reason. I'm running 7-STABLE and the standard information is below. uname -a (system csuped within a couple hours of build time): FreeBSD storage.kc8onw.net 7.0-STABLE FreeBSD 7.0-STABLE #8: Wed Apr 30 14:20:32 ADT 2008 root@storage.kc8onw.net:/usr/obj/usr/src/sys/STORAGE i386 dmesg lines for em1 (full dmesg available if needed): em1: port 0xdc00-0xdc1f mem 0xfe8e0000-0xfe8fffff,0xfe8c0000-0xfe8dffff irq 16 at device 0.0 on pci3 em1: Unable to allocate bus resource: memory em1: Allocation of PCI resources failed pciconf -lv for em 1: em1@pci0:3:0:0: class=0x020000 card=0x10838086 chip=0x10b98086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = '82572EI PRO/1000 PT Desktop Adapter (Copper)' class = network subclass = ethernet Thank you, Jonathan From owner-freebsd-net@FreeBSD.ORG Thu May 1 02:39:25 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D4E2106566C for ; Thu, 1 May 2008 02:39:25 +0000 (UTC) (envelope-from andrew@modulus.org) Received: from email.octopus.com.au (host-122-100-2-232.octopus.com.au [122.100.2.232]) by mx1.freebsd.org (Postfix) with ESMTP id 275538FC1A for ; Thu, 1 May 2008 02:39:24 +0000 (UTC) (envelope-from andrew@modulus.org) Received: by email.octopus.com.au (Postfix, from userid 1002) id 4DC2A13CA9; Thu, 1 May 2008 12:39:22 +1000 (EST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on email.octopus.com.au X-Spam-Level: X-Spam-Status: No, score=-1.4 required=10.0 tests=ALL_TRUSTED autolearn=failed version=3.2.3 Received: from anzac.hos (132.169.233.220.exetel.com.au [220.233.169.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: admin@email.octopus.com.au) by email.octopus.com.au (Postfix) with ESMTP id EE41C137FA; Thu, 1 May 2008 12:39:17 +1000 (EST) Message-ID: <48192D55.2080604@modulus.org> Date: Thu, 01 May 2008 12:39:17 +1000 From: Andrew Snow User-Agent: Thunderbird 2.0.0.0 (X11/20070426) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <58369.214.13.212.26.1209607888.squirrel@www.kc8onw.net> In-Reply-To: <58369.214.13.212.26.1209607888.squirrel@www.kc8onw.net> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: jonathan@kc8onw.net Subject: Re: em1: Unable to allocate bus resource: memory 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, 01 May 2008 02:39:25 -0000 > I bought a new PCIe NIC a few months ago and was working with Jack Vogel > on getting it to work but he was busy, then I got busy and things stalled. > Does anyone else have any idea what might be wrong here? The card is > recognized but the em driver fails to initialize it for some reason. I'm > running 7-STABLE and the standard information is below. I experience the same problem with an Intel PCIe gigabit NIC. I don't know of any workaround, my cards are sitting on the shelf until someone works it out... - Andrew From owner-freebsd-net@FreeBSD.ORG Thu May 1 03:22:57 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F8EC106564A for ; Thu, 1 May 2008 03:22:57 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail07.syd.optusnet.com.au (mail07.syd.optusnet.com.au [211.29.132.188]) by mx1.freebsd.org (Postfix) with ESMTP id CEBB18FC0C for ; Thu, 1 May 2008 03:22:56 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c220-239-252-11.carlnfd3.nsw.optusnet.com.au (c220-239-252-11.carlnfd3.nsw.optusnet.com.au [220.239.252.11]) by mail07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m413Mr2N025083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 May 2008 13:22:54 +1000 Date: Thu, 1 May 2008 13:22:53 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Kris Kennaway In-Reply-To: <200804250550.m3P5o4f1010354@freefall.freebsd.org> Message-ID: <20080501130050.A93454@delplex.bde.org> References: <200804250550.m3P5o4f1010354@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@FreeBSD.org Subject: Re: misc/123066: kernel trap with ipsec 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, 01 May 2008 03:22:57 -0000 On Fri, 25 Apr 2008, Kris Kennaway wrote: > Unfortunately we need the rest of the stack. Can you either try to > reproduce with DDB in the kernel and obtain a stack trace from there, > or if this is not possible then try recompiling the kernel with -O > instead of -O2 which tends to produce better stack traces. I wonder why there haven't been more reports of gcc-4.2 -O[2] breaking things (I probably read the wrong lists). -O2 almost completely breaks kernel profiling and debugging using ddb, mainly by inlining functions that are only used once. Even -O is documented as enabling -funit-at-a-time, which is documented as enabling -finline-functions-called-once. -funit-at-a-time gives the possibility of inlining functions that are instantiated before they are used, and then -finline-functions-called-once tends to inline them. However, this doesn't seem to happen very often with only -O. Maybe -O only inlines small functions, but -O2 inlines all functions that are only called once. Losing the symbols and frames for large inlined functions is especially annoying. I started using -O2 for kernels about a year ago because although it it has little effect (usually negative) in normal use, it gave an optimization of a whole 1 to 5% in network microbenchmarks that I was working on. Bruce From owner-freebsd-net@FreeBSD.ORG Thu May 1 04:16:22 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E31CC106566C for ; Thu, 1 May 2008 04:16:22 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by mx1.freebsd.org (Postfix) with ESMTP id B1CB68FC29 for ; Thu, 1 May 2008 04:16:22 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by wa-out-1112.google.com with SMTP id j4so995096wah.3 for ; Wed, 30 Apr 2008 21:16:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=OFvYKamMKc+yuwzBg4/f1OjumkIhnW8b92LE1DkzpwU=; b=Oq+HQ8pVpINKUqEbqWScbiH+3D9I8AByV/21kQCthaGOMXU4kvEpAux5V/H8gHdwb6w0JHoH1G5BrIUwyYfY66+yvIMy5Gv4xzKaqQRpouCfSe2gW8op0LPWMReTNpd79hgtAJSAbbo9K6pBhLldzMAVh/Y1cOWbWZhbyHHlVQg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=f9m2dE2V+P6nfmR8A2uuL3zLBl0BVCTm2P3T/4YbxQeRlqw8TBpaIlzuFiqprcPetmiPOC5RqW3Xws2JQMfIx3DaMdBw5Fg2LlM4caJHkQaJPANBLPASJXenlGpWxbTomD3doIpNo2oKK+n5z1rRoI/ZfeaL0j93d03skF6E4T0= Received: by 10.114.191.1 with SMTP id o1mr1621391waf.117.1209614981676; Wed, 30 Apr 2008 21:09:41 -0700 (PDT) Received: by 10.114.177.4 with HTTP; Wed, 30 Apr 2008 21:09:41 -0700 (PDT) Message-ID: <2a41acea0804302109r35051d6rcfa99676b392310a@mail.gmail.com> Date: Wed, 30 Apr 2008 21:09:41 -0700 From: "Jack Vogel" To: "Andrew Snow" In-Reply-To: <48192D55.2080604@modulus.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <58369.214.13.212.26.1209607888.squirrel@www.kc8onw.net> <48192D55.2080604@modulus.org> Cc: freebsd-net@freebsd.org, jonathan@kc8onw.net Subject: Re: em1: Unable to allocate bus resource: memory 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, 01 May 2008 04:16:23 -0000 On Wed, Apr 30, 2008 at 7:39 PM, Andrew Snow wrote: > > > I bought a new PCIe NIC a few months ago and was working with Jack Vogel > > on getting it to work but he was busy, then I got busy and things > stalled. > > Does anyone else have any idea what might be wrong here? The card is > > recognized but the em driver fails to initialize it for some reason. I'm > > running 7-STABLE and the standard information is below. > > > I experience the same problem with an Intel PCIe gigabit NIC. I don't know > of any workaround, my cards are sitting on the shelf until someone works it > out... > You won't know if its still a problem if you don't take them off the shelf and try it :) I can't fix problems that I cannot reproduce... well, unless I get REAL lucky and fix something along the way, but that means that if you don't help me it likely won't get fixed :) Sometimes its frustrating, you can try hard... I can try hard, and we still can't solve something, but its the only way to proceed. I am hoping to MFC the em/igb drivers in HEAD soon, it would be helpful to me, and to everyone, if as many get out and test that driver as possible. Cheers, Jack From owner-freebsd-net@FreeBSD.ORG Thu May 1 04:30:33 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90969106564A for ; Thu, 1 May 2008 04:30:33 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by mx1.freebsd.org (Postfix) with ESMTP id 601EC8FC18 for ; Thu, 1 May 2008 04:30:33 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by wa-out-1112.google.com with SMTP id j4so1005788wah.3 for ; Wed, 30 Apr 2008 21:30:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=CHbhbwjh33ABNbDB8GMNQjPSRsETTp1WSdadfohK/Lg=; b=Zqyswy5sc4HmgkUiew0rffO9MjxMA7UpB3UfUCDHpaWVtRF3+227uv8bAFaI0Q3ILVh/9/76wOSY2J5RhJ9/Hqw8xv6YolmO6xXHlP22irVGcsFlq4LbJDUcdMdsDZ/bwlLIKJFybfav7KxICGsqL4czvE8azbciKS6d1yO6ZqQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=LZ86om3AZL198z61MopDSroqcf0LyG/IOSbxGk7IkcEaZSRb/lTVPlne799reL5ysfv3JbgJAkKW2c0seSoxE7GliFgdll//RLMgbQI9dc7uROJJ6ginIId/oFYKtjpyT4lor2AjImmHmQbItpWLenoXrA7RZBVScrF430pxJaQ= Received: by 10.114.25.3 with SMTP id 3mr1634760way.22.1209614661755; Wed, 30 Apr 2008 21:04:21 -0700 (PDT) Received: by 10.114.177.4 with HTTP; Wed, 30 Apr 2008 21:04:21 -0700 (PDT) Message-ID: <2a41acea0804302104u5479be90t6089d42049df3c4c@mail.gmail.com> Date: Wed, 30 Apr 2008 21:04:21 -0700 From: "Jack Vogel" To: jonathan@kc8onw.net In-Reply-To: <58369.214.13.212.26.1209607888.squirrel@www.kc8onw.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <58369.214.13.212.26.1209607888.squirrel@www.kc8onw.net> Cc: freebsd-net@freebsd.org Subject: Re: em1: Unable to allocate bus resource: memory 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, 01 May 2008 04:30:33 -0000 Try the driver in HEAD, it might even just build and work on 7, if not let me know. Jack On Wed, Apr 30, 2008 at 7:11 PM, wrote: > (Please CC as I'm not subscribed to net@) > > I bought a new PCIe NIC a few months ago and was working with Jack Vogel > on getting it to work but he was busy, then I got busy and things stalled. > Does anyone else have any idea what might be wrong here? The card is > recognized but the em driver fails to initialize it for some reason. I'm > running 7-STABLE and the standard information is below. > > uname -a (system csuped within a couple hours of build time): > FreeBSD storage.kc8onw.net 7.0-STABLE FreeBSD 7.0-STABLE #8: Wed Apr 30 > 14:20:32 ADT 2008 root@storage.kc8onw.net:/usr/obj/usr/src/sys/STORAGE > i386 > > dmesg lines for em1 (full dmesg available if needed): > em1: port > 0xdc00-0xdc1f mem 0xfe8e0000-0xfe8fffff,0xfe8c0000-0xfe8dffff irq 16 at > device 0.0 on pci3 > em1: Unable to allocate bus resource: memory > em1: Allocation of PCI resources failed > > pciconf -lv for em 1: > em1@pci0:3:0:0: class=0x020000 card=0x10838086 chip=0x10b98086 rev=0x06 > hdr=0x00 > vendor = 'Intel Corporation' > device = '82572EI PRO/1000 PT Desktop Adapter (Copper)' > class = network > subclass = ethernet > > Thank you, > Jonathan > > > > _______________________________________________ > 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 May 1 04:49:27 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0F76106566C for ; Thu, 1 May 2008 04:49:27 +0000 (UTC) (envelope-from jonathan@kc8onw.net) Received: from mail-out2.fuse.net (mail-out2.fuse.net [216.68.8.171]) by mx1.freebsd.org (Postfix) with ESMTP id 727908FC14 for ; Thu, 1 May 2008 04:49:27 +0000 (UTC) (envelope-from jonathan@kc8onw.net) X-CNFS-Analysis: v=1.0 c=1 a=SY06toJ_PqEA:15 a=tlCHpfXle7AA:10 a=R_1Sod5e6hMA:10 a=xUvkYoQocQKi/8Los98NoQ==:17 a=CaKZ-gDalch6H3oiRI0A:9 a=OUkRxKTmK5H4LGo6zjc4PhTkv6UA:4 a=LY0hPdMaydYA:10 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Received: from [208.102.162.227] ([208.102.162.227:50302] helo=mail.kc8onw.net) by mail-out2.fuse.net (ecelerity 2.1.1.22 r(17669)) with ESMTP id A1/B9-06210-5DB49184 for ; Thu, 01 May 2008 00:49:26 -0400 Received: from www.kc8onw.net (localhost [127.0.0.1]) by mail.kc8onw.net (Postfix) with ESMTP id A7B8628415; Thu, 1 May 2008 00:49:23 -0400 (EDT) Received: from 214.13.212.26 (SquirrelMail authenticated user jonathan) by www.kc8onw.net with HTTP; Thu, 1 May 2008 00:49:23 -0400 (EDT) Message-ID: <62563.214.13.212.26.1209617363.squirrel@www.kc8onw.net> In-Reply-To: <2a41acea0804302109r35051d6rcfa99676b392310a@mail.gmail.com> References: <58369.214.13.212.26.1209607888.squirrel@www.kc8onw.net> <48192D55.2080604@modulus.org> <2a41acea0804302109r35051d6rcfa99676b392310a@mail.gmail.com> Date: Thu, 1 May 2008 00:49:23 -0400 (EDT) From: jonathan@kc8onw.net To: "Jack Vogel" User-Agent: SquirrelMail/1.5.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org, Andrew Snow Subject: Re: em1: Unable to allocate bus resource: memory 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, 01 May 2008 04:49:27 -0000 On Thu, May 1, 2008 00:09, Jack Vogel wrote: > I am hoping to MFC the em/igb drivers in HEAD soon, it would be helpful > to me, and to everyone, if as many get out and test that driver as > possible. Can we just "csup -i src/sys/dev/em/ supfile" on a 7-stable system or are there other changes that need to happen as well? Jonathan From owner-freebsd-net@FreeBSD.ORG Thu May 1 04:55:12 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C3FB106576E for ; Thu, 1 May 2008 04:55:12 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180]) by mx1.freebsd.org (Postfix) with ESMTP id 6A5D28FC1F for ; Thu, 1 May 2008 04:55:12 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by wa-out-1112.google.com with SMTP id j4so1024345wah.3 for ; Wed, 30 Apr 2008 21:55:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=J/606VzPkogvjVUtARUZyUiV6Lv/aRa+Vx2f1L3tFb0=; b=wERId1k9n/Xq9LWMmj8B/Zi6icW3JpUWN9/FqwkUKFFkQ796f7SOS89pBrhGo/x2bvLagJdlOt/ZAotwlxuQnethXnfPjZxpLN4x8LWkq6v7F1+xkyaMR6YzvhIiAKu/zil0IrogNT4qooo2unfx8gSk30XVNbSz2zZElTF0gbA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Eeop02alF1UBcDTtgv+r8UEaIAnOU2iHBXxLH0ujzXfLqU8mYE6NomiXSWOBLw4a6qTAkteQ5X+Z0Erjnwv9ozHPIKA6nAi+FcuPtJYzWEx7FtYDlNzX6rK1p/VaGGFrbntJWmQrxAh/EEDCA3ptC3UvECNsYD/zeeGTYR1t+y8= Received: by 10.114.191.1 with SMTP id o1mr1662843waf.66.1209617711838; Wed, 30 Apr 2008 21:55:11 -0700 (PDT) Received: by 10.114.177.4 with HTTP; Wed, 30 Apr 2008 21:55:11 -0700 (PDT) Message-ID: <2a41acea0804302155x3d2a1ee0lbda2085fb0d347fe@mail.gmail.com> Date: Wed, 30 Apr 2008 21:55:11 -0700 From: "Jack Vogel" To: jonathan@kc8onw.net In-Reply-To: <62563.214.13.212.26.1209617363.squirrel@www.kc8onw.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <58369.214.13.212.26.1209607888.squirrel@www.kc8onw.net> <48192D55.2080604@modulus.org> <2a41acea0804302109r35051d6rcfa99676b392310a@mail.gmail.com> <62563.214.13.212.26.1209617363.squirrel@www.kc8onw.net> Cc: freebsd-net@freebsd.org, Andrew Snow Subject: Re: em1: Unable to allocate bus resource: memory 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, 01 May 2008 04:55:12 -0000 On Wed, Apr 30, 2008 at 9:49 PM, wrote: > On Thu, May 1, 2008 00:09, Jack Vogel wrote: > > I am hoping to MFC the em/igb drivers in HEAD soon, it would be helpful > > to me, and to everyone, if as many get out and test that driver as > > possible. > > Can we just "csup -i src/sys/dev/em/ supfile" on a 7-stable system or are > there other changes that need to happen as well? > > Jonathan hmmm, I'm not sure, I don't usually do that on a small directory, there are changes to files and Makefile. It depends if you are going to build as a module or static in the kernel? Jack From owner-freebsd-net@FreeBSD.ORG Thu May 1 05:10:58 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 735861065F0B for ; Thu, 1 May 2008 05:10:58 +0000 (UTC) (envelope-from andrew@modulus.org) Received: from email.octopus.com.au (host-122-100-2-232.octopus.com.au [122.100.2.232]) by mx1.freebsd.org (Postfix) with ESMTP id 2E9E88FC13 for ; Thu, 1 May 2008 05:10:57 +0000 (UTC) (envelope-from andrew@modulus.org) Received: by email.octopus.com.au (Postfix, from userid 1002) id D9D4513B3F; Thu, 1 May 2008 15:10:55 +1000 (EST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on email.octopus.com.au X-Spam-Level: X-Spam-Status: No, score=-1.4 required=10.0 tests=ALL_TRUSTED autolearn=failed version=3.2.3 Received: from anzac.hos (132.169.233.220.exetel.com.au [220.233.169.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: admin@email.octopus.com.au) by email.octopus.com.au (Postfix) with ESMTP id B04B812F8F; Thu, 1 May 2008 15:10:51 +1000 (EST) Message-ID: <481950DB.80808@modulus.org> Date: Thu, 01 May 2008 15:10:51 +1000 From: Andrew Snow User-Agent: Thunderbird 2.0.0.0 (X11/20070426) MIME-Version: 1.0 To: Jack Vogel References: <58369.214.13.212.26.1209607888.squirrel@www.kc8onw.net> <48192D55.2080604@modulus.org> <2a41acea0804302109r35051d6rcfa99676b392310a@mail.gmail.com> In-Reply-To: <2a41acea0804302109r35051d6rcfa99676b392310a@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, jonathan@kc8onw.net Subject: Re: em1: Unable to allocate bus resource: memory 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, 01 May 2008 05:10:58 -0000 Jack Vogel wrote: > You won't know if its still a problem if you don't take them off the > shelf and try it :) Good point. I wasn't trying to point the finger at you, I think you are doing a fantastic job overall :) The card in question is a Pro/1000PT desktop adapter on PCIe 1x bus. I had used some other cards in the meantime and forgot all about my PCIe card. Just got it out to try it again. While it didnt work in 6.2 (all packets would get silently dropped), it now works fine for me in 7.0! Thanks for all your good work. - Andrew From owner-freebsd-net@FreeBSD.ORG Thu May 1 05:22:18 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 572CE1065682 for ; Thu, 1 May 2008 05:22:18 +0000 (UTC) (envelope-from andrew@modulus.org) Received: from email.octopus.com.au (host-122-100-2-232.octopus.com.au [122.100.2.232]) by mx1.freebsd.org (Postfix) with ESMTP id 14AE48FC0C for ; Thu, 1 May 2008 05:22:18 +0000 (UTC) (envelope-from andrew@modulus.org) Received: by email.octopus.com.au (Postfix, from userid 1002) id EFAA31398F; Thu, 1 May 2008 15:22:16 +1000 (EST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on email.octopus.com.au X-Spam-Level: X-Spam-Status: No, score=-1.4 required=10.0 tests=ALL_TRUSTED autolearn=failed version=3.2.3 Received: from anzac.hos (132.169.233.220.exetel.com.au [220.233.169.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: admin@email.octopus.com.au) by email.octopus.com.au (Postfix) with ESMTP id CB72C12F8F; Thu, 1 May 2008 15:22:12 +1000 (EST) Message-ID: <48195384.5030204@modulus.org> Date: Thu, 01 May 2008 15:22:12 +1000 From: Andrew Snow User-Agent: Thunderbird 2.0.0.0 (X11/20070426) MIME-Version: 1.0 To: Alfred Perlstein References: <20080501045736.GU30325@elvis.mu.org> In-Reply-To: <20080501045736.GU30325@elvis.mu.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Some odd behaviour of vmstat and vmtotal... 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, 01 May 2008 05:22:18 -0000 > In deploying 7.0 at work we were finding a persistent problem when > running "vmstat 1" on systems. The problem shows up as a 10ms "pause" > in processing, usually packet stamping and forwarding by a user level > process. Thats interesting. I once did some quick and dirty profiling of vmtotal and found it runs extremely quickly. Are you running on slow machines (embedded perhaps)? Or do you have a situation where you perhaps have alot more VM objects created than normal? I can't think of a good example where this would be the case.. - Andrew From owner-freebsd-net@FreeBSD.ORG Thu May 1 05:53:09 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED34E1065672; Thu, 1 May 2008 05:53:09 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C151B8FC13; Thu, 1 May 2008 05:53:09 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m415r9k1048613; Thu, 1 May 2008 05:53:09 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m415r9jM048609; Thu, 1 May 2008 05:53:09 GMT (envelope-from linimon) Date: Thu, 1 May 2008 05:53:09 GMT Message-Id: <200805010553.m415r9jM048609@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-i386@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/122989: [swi] [panic] 6.3 kernel panic in swi1: net 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, 01 May 2008 05:53:10 -0000 Synopsis: [swi] [panic] 6.3 kernel panic in swi1: net Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu May 1 05:52:44 UTC 2008 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=122989 From owner-freebsd-net@FreeBSD.ORG Thu May 1 08:17:11 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 529FE106564A for ; Thu, 1 May 2008 08:17:11 +0000 (UTC) (envelope-from jonathan@kc8onw.net) Received: from mail-out1.fuse.net (mail-out1.fuse.net [216.68.8.175]) by mx1.freebsd.org (Postfix) with ESMTP id 15EF28FC24 for ; Thu, 1 May 2008 08:17:10 +0000 (UTC) (envelope-from jonathan@kc8onw.net) X-CNFS-Analysis: v=1.0 c=1 a=CIbuFNFJbHUA:15 a=tlCHpfXle7AA:10 a=R_1Sod5e6hMA:10 a=xUvkYoQocQKi/8Los98NoQ==:17 a=w3szO6ePOsQmPpjjKsMA:9 a=bdHGeDJskG5BQflIolQT7zbkHroA:4 a=jtOyKYpszwUA:10 a=LY0hPdMaydYA:10 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Received: from [208.102.162.227] ([208.102.162.227:50672] helo=mail.kc8onw.net) by mail-out1.fuse.net (ecelerity 2.1.1.22 r(17669)) with ESMTP id D8/1E-13383-58C79184 for ; Thu, 01 May 2008 04:17:10 -0400 Received: from www.kc8onw.net (localhost [127.0.0.1]) by mail.kc8onw.net (Postfix) with ESMTP id 2153528415; Thu, 1 May 2008 04:17:09 -0400 (EDT) Received: from 80.91.220.50 (SquirrelMail authenticated user jonathan) by www.kc8onw.net with HTTP; Thu, 1 May 2008 04:17:09 -0400 (EDT) Message-ID: <55561.80.91.220.50.1209629829.squirrel@www.kc8onw.net> In-Reply-To: <2a41acea0804302155x3d2a1ee0lbda2085fb0d347fe@mail.gmail.com> References: <58369.214.13.212.26.1209607888.squirrel@www.kc8onw.net> <48192D55.2080604@modulus.org> <2a41acea0804302109r35051d6rcfa99676b392310a@mail.gmail.com> <62563.214.13.212.26.1209617363.squirrel@www.kc8onw.net> <2a41acea0804302155x3d2a1ee0lbda2085fb0d347fe@mail.gmail.com> Date: Thu, 1 May 2008 04:17:09 -0400 (EDT) From: jonathan@kc8onw.net To: "Jack Vogel" User-Agent: SquirrelMail/1.5.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org, Andrew Snow Subject: Re: em1: Unable to allocate bus resource: memory 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, 01 May 2008 08:17:11 -0000 On Thu, May 1, 2008 00:55, Jack Vogel wrote: > On Wed, Apr 30, 2008 at 9:49 PM, wrote: > >> On Thu, May 1, 2008 00:09, Jack Vogel wrote: >> >>> I am hoping to MFC the em/igb drivers in HEAD soon, it would be >>> helpful to me, and to everyone, if as many get out and test that >>> driver as possible. >> >> Can we just "csup -i src/sys/dev/em/ supfile" on a 7-stable system or >> are there other changes that need to happen as well? >> >> Jonathan >> > > hmmm, I'm not sure, I don't usually do that on a small directory, there > are changes to files and Makefile. It depends if you are going to build as > a module or static in the kernel? I grabbed the dev/em folder for current, commented out the missing file in the makefile and would up with a bunch of errors like ": undefined reference to `e1000_pci_set_mwi'". Not as simple as I hoped :P Any ideas short of migrating the entire system to -head? I'd rather stay on 7 with patches if needed as this system needs to be reliable for extended periods of time. Thanks, Jonathan From owner-freebsd-net@FreeBSD.ORG Thu May 1 08:30:04 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2B0A106566C for ; Thu, 1 May 2008 08:30:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C75E08FC1C for ; Thu, 1 May 2008 08:30:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m418U42Q092119 for ; Thu, 1 May 2008 08:30:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m418U4uT092112; Thu, 1 May 2008 08:30:04 GMT (envelope-from gnats) Date: Thu, 1 May 2008 08:30:04 GMT Message-Id: <200805010830.m418U4uT092112@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Kris Kennaway Cc: Subject: Re: kern/122875: "rstatd: Can't get namelist. 1" - fbsd 7.0-stable (works ok in 7.0-release) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Kris Kennaway List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2008 08:30:05 -0000 The following reply was made to PR kern/122875; it has been noted by GNATS. From: Kris Kennaway To: hotlips Internet admin Cc: bug-followup@FreeBSD.org Subject: Re: kern/122875: "rstatd: Can't get namelist. 1" - fbsd 7.0-stable (works ok in 7.0-release) Date: Thu, 01 May 2008 10:22:39 +0200 hotlips Internet admin wrote: > On Mon, 28 Apr 2008, Kris Kennaway wrote: > |hotlips Internet admin wrote: > |> The following reply was made to PR kern/122875; it has been noted by GNATS. > |> > |> From: hotlips Internet admin > |> To: FreeBSD-gnats-submit@FreeBSD.org, freebsd-bugs@FreeBSD.org > |> Cc: bug-followup@FreeBSD.org > |> Subject: Re: kern/122875: "rstatd: Can't get namelist. 1" - fbsd 7.0-stable > |> (works ok in 7.0-release) > |> Date: Fri, 25 Apr 2008 20:50:51 -0400 (EDT) > |> > |> On Fri, 18 Apr 2008 FreeBSD-gnats-submit@FreeBSD.org wrote: > |> |Thank you very much for your problem report. > |> |It has the internal identification `kern/122875'. > |> |The individual assigned to look at your > |> |report is: freebsd-bugs. | > |> |You can access the state of your problem report at any time > |> |via this link: > |> | > |> |http://www.freebsd.org/cgi/query-pr.cgi?pr=122875 > |> | > |> |>Category: kern > |> |>Responsible: freebsd-bugs > |> |>Synopsis: "rstatd: Can't get namelist. 1" - fbsd 7.0-stable (works > |> ok in 7.0-release) > |> |>Arrival-Date: Fri Apr 18 02:20:00 UTC 2008 > |> this also happens in FreeBSD 6.3-STABLE > |> I depend heavily on rpc.rstatd as a part of monitoring > |> servers and firewalls etc., so this is a serious issue > |> for me until I can get a fix or work-around > | > |Revert the recent commits by Peter until a fix is applied. > > > I'm not sure if this is something i should do locally, > or whether those commites are being reverted in the > FBSD source tree > > > if it's someting to do locally, I would need to know > what to do in detail ... > > > this also seems related to PR ports/123146 btw ... The easiest thing for you to do will be to revert to an older 6.3-STABLE (or 6.3-RELEASE) until it is resolved in CVS. Kris From owner-freebsd-net@FreeBSD.ORG Thu May 1 11:20:00 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06A35106566C for ; Thu, 1 May 2008 11:20:00 +0000 (UTC) (envelope-from suzsuzsuz@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by mx1.freebsd.org (Postfix) with ESMTP id B25278FC1F for ; Thu, 1 May 2008 11:19:59 +0000 (UTC) (envelope-from suzsuzsuz@gmail.com) Received: by yw-out-2324.google.com with SMTP id 5so470214ywh.13 for ; Thu, 01 May 2008 04:19:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=c2htQqoSefR16F6MTW2lVEsnSUIJ2t0oueRlD9FloFk=; b=Vx3uLhoH6W9TVTztRgfqCJv/FMiVCwTz6TBu0rUcxltHZfPPVub3bZdKiTHRv/JVLIBfu41ySNMPPiVbLEsyAxiBVjDXXX6obPZArjYm2naT1uLVfeZG+PzCFhfDaNkJpKunnXTZ7vEWnTeurNe0dGgYkisgAVkKTtr6L3wMMrk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=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=UKTPPB1Bv3Xc6mSe5MRrHLqWhN8tX3S30TLmgEC/Z9t7oRy3gY9LHKvirpcsAnjrwAySoFwXFTU9JjKOK0oFo5amyXxZxkCiONuau3f4VDWiFrZlZmjTnUoYGo/RDzlhkgfB6F2RfmN3KoJ++LBXHUme5H8GNpcRcnTrmK+CK2U= Received: by 10.150.73.41 with SMTP id v41mr2132275yba.189.1209639201462; Thu, 01 May 2008 03:53:21 -0700 (PDT) Received: by 10.151.46.2 with HTTP; Thu, 1 May 2008 03:53:21 -0700 (PDT) Message-ID: Date: Thu, 1 May 2008 19:53:21 +0900 From: "SUZUKI, Shinsuke" Sender: suzsuzsuz@gmail.com To: "Ian Brown" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Google-Sender-Auth: 73cc37875e3fc5c4 Cc: freebsd-net@freebsd.org Subject: Re: Pim6sd daemon and global addresses 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, 01 May 2008 11:20:00 -0000 Hello, On Fri, Apr 25, 2008 at 3:25 PM, Ian Brown wrote: > from man pim6sd: > "pim6sd requires the node running the daemon to have an IPv6 global > address.". > Does that mean that it must have an IPv6 address which > it address has a global type? > Namely, must it be an address which starts with a global prefix, like > 2001::....? Yes. That's because some of a PIM-SM protocol message (PIM-Register/Register-Stop) requires a global unicast address. #In some cases PIM-Register/Register-Stop is not used. As it is #not always so obvious, pim6sd requires a global unicast address. > Second: is there a way to prevent the pim6sd daemon to send the PIM > hello messages, which it does regularly ? Please specify the following command in your pim6sd.conf, where xxx is the interface name you want to disable PIM-SM. phyint xxx disable; Thanks. ---- SUZUKI, Shinsuke From owner-freebsd-net@FreeBSD.ORG Thu May 1 16:20:03 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD5DB1065674 for ; Thu, 1 May 2008 16:20:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 98C338FC12 for ; Thu, 1 May 2008 16:20:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m41GK3dM059771 for ; Thu, 1 May 2008 16:20:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m41GK3b7059770; Thu, 1 May 2008 16:20:03 GMT (envelope-from gnats) Date: Thu, 1 May 2008 16:20:03 GMT Message-Id: <200805011620.m41GK3b7059770@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: =?ISO-8859-15?Q?Lars_K=F6ller?= Cc: Subject: Re: kern/122427: [apm] [panic] apm and mDNSResponder cause panic during shutdown (multicast) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?ISO-8859-15?Q?Lars_K=F6ller?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2008 16:20:03 -0000 The following reply was made to PR kern/122427; it has been noted by GNATS. From: =?ISO-8859-15?Q?Lars_K=F6ller?= To: bug-followup@FreeBSD.org, root@koellers.net Cc: Subject: Re: kern/122427: [apm] [panic] apm and mDNSResponder cause panic during shutdown (multicast) Date: Thu, 01 May 2008 18:12:27 +0200 Seems to be fixed in 6-STABLE with sys/netinet/in.c version 1.85.2.10 There seems to be other PR's which could be closed now. kern/108197 [panic] [gif] [ip6] if_delmulti reference counting panic kern/116077 [ip] [patch] 6.2-STABLE panic during use of multi-cast networking client kern/120266 [panic] gnugk causes kernel panic when closing UDP sockets kern/120343 [panic] Reproducible Crash - network interface related (kgdb output included) Regards Lars From owner-freebsd-net@FreeBSD.ORG Thu May 1 16:34:59 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D38961065673 for ; Thu, 1 May 2008 16:34:59 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.186]) by mx1.freebsd.org (Postfix) with ESMTP id 893AA8FC0C for ; Thu, 1 May 2008 16:34:59 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by rn-out-0910.google.com with SMTP id j40so520559rnf.12 for ; Thu, 01 May 2008 09:34:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=DhqVz5yTuAF8dnYyYMw3xkfDt5caS/yntjbbIHkyVhw=; b=G0ugGe8EGYA6w8aG5xZxnaOgWHedr54ITQdnprWU3/6KGZm2H6RSAcqZg1Capy3SJbV+v52qZfO1KLBszGvjf6VT8Ip0U7v4LNn7CzJbYRwMiQm3B8mjLvF9mVzSBsmBduLz3c1kUaUz/a70G59iiOlg1kJtUPRA3J6dMNGdgqw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=wIx5DC/PAPQsAvSEBs8kuawN2eVV5gTfTkSf+RUZxJKzPm8Uqu5b8P/haH/Et5QgeGv8/SgNLfiZKayyYPFMI4JS0Cbc7n13oAAzFAvmGsEGUGxP84ySt4ZbzJOAuEa3CDuc7paOX9SzAiV2L1L28BWmNBEs8p6W9ak//d28Agg= Received: by 10.114.158.1 with SMTP id g1mr2075621wae.111.1209659698290; Thu, 01 May 2008 09:34:58 -0700 (PDT) Received: by 10.114.177.4 with HTTP; Thu, 1 May 2008 09:34:58 -0700 (PDT) Message-ID: <2a41acea0805010934k4e3980b7w3927b57f9dd54ef6@mail.gmail.com> Date: Thu, 1 May 2008 09:34:58 -0700 From: "Jack Vogel" To: jonathan@kc8onw.net In-Reply-To: <55561.80.91.220.50.1209629829.squirrel@www.kc8onw.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <58369.214.13.212.26.1209607888.squirrel@www.kc8onw.net> <48192D55.2080604@modulus.org> <2a41acea0804302109r35051d6rcfa99676b392310a@mail.gmail.com> <62563.214.13.212.26.1209617363.squirrel@www.kc8onw.net> <2a41acea0804302155x3d2a1ee0lbda2085fb0d347fe@mail.gmail.com> <55561.80.91.220.50.1209629829.squirrel@www.kc8onw.net> Cc: freebsd-net@freebsd.org, Andrew Snow Subject: Re: em1: Unable to allocate bus resource: memory 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, 01 May 2008 16:34:59 -0000 On Thu, May 1, 2008 at 1:17 AM, wrote: > > On Thu, May 1, 2008 00:55, Jack Vogel wrote: > > On Wed, Apr 30, 2008 at 9:49 PM, wrote: > > > >> On Thu, May 1, 2008 00:09, Jack Vogel wrote: > >> > >>> I am hoping to MFC the em/igb drivers in HEAD soon, it would be > >>> helpful to me, and to everyone, if as many get out and test that > >>> driver as possible. > >> > >> Can we just "csup -i src/sys/dev/em/ supfile" on a 7-stable system or > >> are there other changes that need to happen as well? > >> > >> Jonathan > >> > > > > hmmm, I'm not sure, I don't usually do that on a small directory, there > > are changes to files and Makefile. It depends if you are going to build as > > a module or static in the kernel? > > I grabbed the dev/em folder for current, commented out the missing file in > the makefile and would up with a bunch of errors like ": undefined > reference to `e1000_pci_set_mwi'". > > Not as simple as I hoped :P Any ideas short of migrating the entire > system to -head? I'd rather stay on 7 with patches if needed as this > system needs to be reliable for extended periods of time. > > Thanks, > Jonathan If you can wait a week I should get to the MFC, if its urgent let me know and we can see, are you sure you got everything, that routine was something that got dropped out of osdep because the shared code no longer uses it. Jack From owner-freebsd-net@FreeBSD.ORG Thu May 1 16:36:06 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E162106567D for ; Thu, 1 May 2008 16:36:06 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.177]) by mx1.freebsd.org (Postfix) with ESMTP id F26A98FC0A for ; Thu, 1 May 2008 16:36:05 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by wa-out-1112.google.com with SMTP id j4so1525327wah.3 for ; Thu, 01 May 2008 09:36:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=ZStwJ2/y7W1G4JdXcUIXgzC/3nj1Cf692u2CNGkMF5I=; b=BvHs+G5NumVq1N0nIwTyTVAQkPBOAiJ4ltbt8xmXY5fMJtyD6+tv8/JKruoGOu+BsgHXnEImvyglzBS7HGq412aaDLd0UP4nSaPZcNAQSWDXO3Glnt9WUJceunPJsWuby7U6iaUn1OIbGUkZKVWcoPzPVIkZ04/PuXbV42QazzM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=LrecABCFIjWY/2G96rvFdRI9+jWTt84TIwmSkh3VhwU392AOFwQC9UZuVXWDklvxrF5U7JPXzeZnorX6JeU5aEQzDFe/k9ryo2iwb2F6+ckfgGaCFhA1yoqRHkFk3ANjqjQ2mVmelUobNdtfQfJYARdvlglmx69mIocCoLdP7as= Received: by 10.114.120.1 with SMTP id s1mr2081255wac.82.1209659765651; Thu, 01 May 2008 09:36:05 -0700 (PDT) Received: by 10.114.177.4 with HTTP; Thu, 1 May 2008 09:36:05 -0700 (PDT) Message-ID: <2a41acea0805010936q57470427pa693f1ccfd72488b@mail.gmail.com> Date: Thu, 1 May 2008 09:36:05 -0700 From: "Jack Vogel" To: "Andrew Snow" In-Reply-To: <481950DB.80808@modulus.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <58369.214.13.212.26.1209607888.squirrel@www.kc8onw.net> <48192D55.2080604@modulus.org> <2a41acea0804302109r35051d6rcfa99676b392310a@mail.gmail.com> <481950DB.80808@modulus.org> Cc: freebsd-net@freebsd.org, jonathan@kc8onw.net Subject: Re: em1: Unable to allocate bus resource: memory 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, 01 May 2008 16:36:06 -0000 On Wed, Apr 30, 2008 at 10:10 PM, Andrew Snow wrote: > Jack Vogel wrote: > > > You won't know if its still a problem if you don't take them off the > > shelf and try it :) > > > > > Good point. I wasn't trying to point the finger at you, I think you are > doing a fantastic job overall :) > > The card in question is a Pro/1000PT desktop adapter on PCIe 1x bus. I had > used some other cards in the meantime and forgot all about my PCIe card. > Just got it out to try it again. > > While it didnt work in 6.2 (all packets would get silently dropped), it now > works fine for me in 7.0! > > > Thanks for all your good work. Awesome, nice to hear that its an improvement, and you're welcome :) Jack From owner-freebsd-net@FreeBSD.ORG Thu May 1 16:50:19 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B4791065677 for ; Thu, 1 May 2008 16:50:19 +0000 (UTC) (envelope-from jonathan@kc8onw.net) Received: from mail-out1.fuse.net (mail-out1.fuse.net [216.68.8.175]) by mx1.freebsd.org (Postfix) with ESMTP id EE9CF8FC28 for ; Thu, 1 May 2008 16:50:18 +0000 (UTC) (envelope-from jonathan@kc8onw.net) X-CNFS-Analysis: v=1.0 c=1 a=CIbuFNFJbHUA:15 a=tlCHpfXle7AA:10 a=R_1Sod5e6hMA:10 a=xUvkYoQocQKi/8Los98NoQ==:17 a=XuVoVFUJk1nV3i29uxcA:9 a=XzdngWFpLwgFTni8HDGaHT1T6jkA:4 a=jtOyKYpszwUA:10 a=LY0hPdMaydYA:10 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Received: from [208.102.162.227] ([208.102.162.227:50304] helo=mail.kc8onw.net) by mail-out1.fuse.net (ecelerity 2.1.1.22 r(17669)) with ESMTP id 78/7E-13383-9C4F9184 for ; Thu, 01 May 2008 12:50:18 -0400 Received: from www.kc8onw.net (localhost [127.0.0.1]) by mail.kc8onw.net (Postfix) with ESMTP id DE9B528415; Thu, 1 May 2008 12:50:16 -0400 (EDT) Received: from 80.91.220.50 (SquirrelMail authenticated user jonathan) by www.kc8onw.net with HTTP; Thu, 1 May 2008 12:50:16 -0400 (EDT) Message-ID: <58402.80.91.220.50.1209660616.squirrel@www.kc8onw.net> In-Reply-To: <2a41acea0805010934k4e3980b7w3927b57f9dd54ef6@mail.gmail.com> References: <58369.214.13.212.26.1209607888.squirrel@www.kc8onw.net> <48192D55.2080604@modulus.org> <2a41acea0804302109r35051d6rcfa99676b392310a@mail.gmail.com> <62563.214.13.212.26.1209617363.squirrel@www.kc8onw.net> <2a41acea0804302155x3d2a1ee0lbda2085fb0d347fe@mail.gmail.com> <55561.80.91.220.50.1209629829.squirrel@www.kc8onw.net> <2a41acea0805010934k4e3980b7w3927b57f9dd54ef6@mail.gmail.com> Date: Thu, 1 May 2008 12:50:16 -0400 (EDT) From: jonathan@kc8onw.net To: "Jack Vogel" User-Agent: SquirrelMail/1.5.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org, jonathan@kc8onw.net, Andrew Snow Subject: Re: em1: Unable to allocate bus resource: memory 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, 01 May 2008 16:50:19 -0000 On Thu, May 1, 2008 12:34, Jack Vogel wrote: > On Thu, May 1, 2008 at 1:17 AM, wrote: > >> I grabbed the dev/em folder for current, commented out the missing file >> in the makefile and would up with a bunch of errors like ": undefined >> reference to `e1000_pci_set_mwi'". >> >> Not as simple as I hoped :P Any ideas short of migrating the entire >> system to -head? I'd rather stay on 7 with patches if needed as this >> system needs to be reliable for extended periods of time. > > If you can wait a week I should get to the MFC, if its urgent let me know > and we can see, are you sure you got everything, that routine was > something that got dropped out of osdep because the shared code no longer > uses it. It's not urgent. I only grabbed the dev/em directory so something probably changed elsewhere. If you can give me a heads up when the MFC occurs I would appreciate it. If the MFC doesn't get it working would having remote access help at all? Jonathan From owner-freebsd-net@FreeBSD.ORG Thu May 1 16:54:27 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A91AB1065670 for ; Thu, 1 May 2008 16:54:27 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.191]) by mx1.freebsd.org (Postfix) with ESMTP id 59FFF8FC27 for ; Thu, 1 May 2008 16:54:27 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by rn-out-0910.google.com with SMTP id j40so528371rnf.12 for ; Thu, 01 May 2008 09:54:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=/4DI2DmtZ4uYNwc52dmUmea1iVFXxG+eWfxLUVmnggI=; b=OJePsBiIOXsUwNFWn3PpVtWja1TPGgM392nEGDDLVMazp1Ly285TG/QyRRyBIceyN/t0HAG4DvpOu97VPUAgITA3bYQoIluAItiM+oUZ4hYC1JcTRTBt1ScyjLw6+zF3gbEPwBlCWgy+8ln5aVqweuQZNG0Ey6/hBSNKpm4DsCc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=cWEO7n4LSwVQIX8TGGLZpE2ePvA0Qrb6giT4BWtrKMJcGm28I8PTl5kJKNNEYyg/7kWKzHjqrAVPThNLb1jpUUlHjyrjtXUGOPv3X3yJ8JdKMW/09Iknhw37QFr1UAzcKDNF8yx/iDt53ciBCN3RKr6kAKU1m18ptzOHHOgj84Q= Received: by 10.115.79.1 with SMTP id g1mr2104389wal.43.1209660866301; Thu, 01 May 2008 09:54:26 -0700 (PDT) Received: by 10.114.177.4 with HTTP; Thu, 1 May 2008 09:54:26 -0700 (PDT) Message-ID: <2a41acea0805010954m3f6f4afdxd3a18a515e0a86e4@mail.gmail.com> Date: Thu, 1 May 2008 09:54:26 -0700 From: "Jack Vogel" To: jonathan@kc8onw.net In-Reply-To: <58402.80.91.220.50.1209660616.squirrel@www.kc8onw.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <58369.214.13.212.26.1209607888.squirrel@www.kc8onw.net> <48192D55.2080604@modulus.org> <2a41acea0804302109r35051d6rcfa99676b392310a@mail.gmail.com> <62563.214.13.212.26.1209617363.squirrel@www.kc8onw.net> <2a41acea0804302155x3d2a1ee0lbda2085fb0d347fe@mail.gmail.com> <55561.80.91.220.50.1209629829.squirrel@www.kc8onw.net> <2a41acea0805010934k4e3980b7w3927b57f9dd54ef6@mail.gmail.com> <58402.80.91.220.50.1209660616.squirrel@www.kc8onw.net> Cc: freebsd-net@freebsd.org, Andrew Snow Subject: Re: em1: Unable to allocate bus resource: memory 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, 01 May 2008 16:54:27 -0000 On Thu, May 1, 2008 at 9:50 AM, wrote: > On Thu, May 1, 2008 12:34, Jack Vogel wrote: > > On Thu, May 1, 2008 at 1:17 AM, wrote: > > > > >> I grabbed the dev/em folder for current, commented out the missing file > >> in the makefile and would up with a bunch of errors like ": undefined > >> reference to `e1000_pci_set_mwi'". > >> > >> Not as simple as I hoped :P Any ideas short of migrating the entire > >> system to -head? I'd rather stay on 7 with patches if needed as this > >> system needs to be reliable for extended periods of time. > > > > > If you can wait a week I should get to the MFC, if its urgent let me know > > and we can see, are you sure you got everything, that routine was > > something that got dropped out of osdep because the shared code no longer > > uses it. > > It's not urgent. I only grabbed the dev/em directory so something > probably changed elsewhere. If you can give me a heads up when the MFC > occurs I would appreciate it. If the MFC doesn't get it working would > having remote access help at all? Possibly, depends what I can do, we'll see when that time comes. Jack From owner-freebsd-net@FreeBSD.ORG Thu May 1 17:25:49 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 920DC1065684 for ; Thu, 1 May 2008 17:25:49 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: from blah.sun-fish.com (blah.sun-fish.com [217.18.249.150]) by mx1.freebsd.org (Postfix) with ESMTP id 45A818FC25 for ; Thu, 1 May 2008 17:25:49 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: by blah.sun-fish.com (Postfix, from userid 1002) id 84BB61B10EFF; Thu, 1 May 2008 19:09:17 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on blah.cmotd.com X-Spam-Level: X-Spam-Status: No, score=-10.6 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.3 Received: from [10.1.1.2] (unknown [192.168.25.10]) by blah.sun-fish.com (Postfix) with ESMTP id 00D291B10EFC for ; Thu, 1 May 2008 19:09:14 +0200 (CEST) Message-ID: <4819F901.50202@moneybookers.com> Date: Thu, 01 May 2008 20:08:17 +0300 From: Stefan Lambrev User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/7007/Thu May 1 17:34:23 2008 on blah.cmotd.com X-Virus-Status: Clean Subject: Re: TCP options order changed in FreeBSD 7, incompatible with some routers 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, 01 May 2008 17:25:49 -0000 Greetings, I'm little lost in this thread. Is there a solution for the problem and is it part of RELENG_7? If yes can someone tell me which version of which files fix this? -- Best Wishes, Stefan Lambrev ICQ# 24134177 From owner-freebsd-net@FreeBSD.ORG Thu May 1 20:00:08 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D33C1065676 for ; Thu, 1 May 2008 20:00:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id CB5688FC19 for ; Thu, 1 May 2008 20:00:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 9A07E41C76D; Thu, 1 May 2008 22:00:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id GhhzvBm4Zmr5; Thu, 1 May 2008 22:00:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 4D15E41C75E; Thu, 1 May 2008 22:00:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 3239444487F; Thu, 1 May 2008 19:58:45 +0000 (UTC) Date: Thu, 1 May 2008 19:58:44 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Stefan Lambrev In-Reply-To: <4819F901.50202@moneybookers.com> Message-ID: <20080501195433.Y47338@maildrop.int.zabbadoz.net> References: <4819F901.50202@moneybookers.com> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: TCP options order changed in FreeBSD 7, incompatible with some routers 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, 01 May 2008 20:00:08 -0000 On Thu, 1 May 2008, Stefan Lambrev wrote: Hi, > I'm little lost in this thread. > Is there a solution for the problem and is it part of RELENG_7? yes, just update to RELENG_7 and you should be fine. > If yes can someone tell me which version of which files fix this? ufff. RELENG_7 as of those version should be fine. 1.141.2.4 sys/netinet/tcp_output.c 1.157.2.3 sys/netinet/tcp_var.h I cannot say if simply picking those two will work as there had been other changes as well. There are plans for fixing 7.0 but not firm date so far. /bz -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From owner-freebsd-net@FreeBSD.ORG Fri May 2 02:05:01 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C49B6106564A for ; Fri, 2 May 2008 02:05:01 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by mx1.freebsd.org (Postfix) with ESMTP id 947EF8FC19 for ; Fri, 2 May 2008 02:05:01 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from [10.11.16.99] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Thu, 01 May 2008 19:04:49 -0700 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 5BAC52B1; Thu, 1 May 2008 19:04:49 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.11.18.52]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 474E52B0 for ; Thu, 1 May 2008 19:04:49 -0700 (PDT) Received: from mail-irva-13.broadcom.com (mail-irva-13.broadcom.com [10.11.16.103]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id GVO11934; Thu, 1 May 2008 19:04:48 -0700 (PDT) Received: from NT-IRVA-0751.brcm.ad.broadcom.com (nt-irva-0751 [10.8.194.65]) by mail-irva-13.broadcom.com (Postfix) with ESMTP id 2735E74CFE for ; Thu, 1 May 2008 19:04:48 -0700 (PDT) Received: from IRVEXCHHUB01.corp.ad.broadcom.com ([10.9.200.131]) by NT-IRVA-0751.brcm.ad.broadcom.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 May 2008 19:04:48 -0700 Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.9.200.129]) by IRVEXCHHUB01.corp.ad.broadcom.com ([10.9.200.131]) with mapi; Thu, 1 May 2008 19:04:47 -0700 From: "David Christensen" To: "freebsd-net@freebsd.org" Date: Thu, 1 May 2008 19:04:56 -0700 Thread-Topic: Not All Symbols Present in a Loadable Kernel Module Thread-Index: Acir+Oryg9fN3dzBQ8auKV2CI6ktVA== Message-ID: <5D267A3F22FD854F8F48B3D2B523819324F09D65FA@IRVEXCHCCR01.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US acceptlanguage: en-US MIME-Version: 1.0 X-OriginalArrivalTime: 02 May 2008 02:04:48.0086 (UTC) FILETIME=[E61B7F60:01C8ABF8] X-WSS-ID: 6404A94B3D02969485-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Not All Symbols Present in a Loadable Kernel Module 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, 02 May 2008 02:05:01 -0000 I'm trying to build the "bce" driver as a kernel module under RELENG_7 but = I'm finding that not all of the functions in the driver are exported as symbols= . This makes it difficult to "call" a function from ddb because I get the error "S= ymbol not found". I'm building and loading the driver from /usr/src/sys/modules/= bce. What am I doing wrong? How can I get all functions in the driver exported = as symbols usable by the debugger? Dave From owner-freebsd-net@FreeBSD.ORG Fri May 2 09:02:04 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 985521065671 for ; Fri, 2 May 2008 09:02:04 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [IPv6:2001:4200:7000:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id D5A578FC15 for ; Fri, 2 May 2008 09:02:03 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id D093D33CBE; Fri, 2 May 2008 11:02:00 +0200 (SAST) Date: Fri, 2 May 2008 11:02:00 +0200 From: John Hay To: Julian Elischer Message-ID: <20080502090200.GA57055@zibbi.meraka.csir.co.za> References: <20080430172705.2E3275AD6@mail.bitblocks.com> <4818BC79.40605@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4818BC79.40605@elischer.org> User-Agent: Mutt/1.4.2.1i Cc: FreeBSD Net Subject: Re: multiple routing tables review patch ready for simple testing. 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, 02 May 2008 09:02:04 -0000 > >This confuses me.... > > > >The whole point of a FIB is to decide the *next* hop for a > >given input packet. So questions. > >1) A packet arrives on an interface. If this interface is > > associated with more than one FIB, which FIB does it get > > given to? > > > > which ever one you select, using the policy of your choice. > > that's what policy routing is about. > if you don't WANT policy based routing, dont turn it on. > > > > >2) If that decision is taken by a a packet 'classifier', > > isn't it in effect doing the job of a FIB (deciding the > > next hop, which happens to be a local FIB)? Recall that > > basically a packet passes from a FIB to another FIB until > > it gets to its eventual destination. > > the packet classifier selects a FIB which in turn implements a > particular routing decision tree. > In the degenerate case where a FIB has only one route > then you are correct, but there are technical reasons why this is > superior to just using a fwd rule in the firewall. The linux guys seems to have multiple fibs (or whatever they call them) which they can chain together by giving them different priorities. The effect seems to be that a packet will be matched through the highest priority fib to the lowest until a route match is found en then is used. Will something like that be possible? I came across that kind of use with the olsr guys. They let olsrd twiddle one of the higher priority fibs and then put fallback routes in a lower priority fib. That way olsrd can override a route (even the default route) and when olsrd exists and deltes all its routes, the original ones are still in the lower priority fib and will be used. John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Fri May 2 09:47:57 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 780031065685; Fri, 2 May 2008 09:47:57 +0000 (UTC) (envelope-from vwe@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 561F08FC16; Fri, 2 May 2008 09:47:57 +0000 (UTC) (envelope-from vwe@FreeBSD.org) Received: from freefall.freebsd.org (vwe@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m429lud3054238; Fri, 2 May 2008 09:47:56 GMT (envelope-from vwe@freefall.freebsd.org) Received: (from vwe@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m429luC4054234; Fri, 2 May 2008 09:47:56 GMT (envelope-from vwe) Date: Fri, 2 May 2008 09:47:56 GMT Message-Id: <200805020947.m429luC4054234@freefall.freebsd.org> To: payne@gameone.com, vwe@FreeBSD.org, freebsd-net@FreeBSD.org From: vwe@FreeBSD.org Cc: Subject: Re: kern/120725: [bce] On board second lan port 'bce1' with Broadcom NetXtreme II BCM5708 1000Base-T 0.9.6 driver in Dell 1950 and 2950 behave super slow 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, 02 May 2008 09:47:57 -0000 Synopsis: [bce] On board second lan port 'bce1' with Broadcom NetXtreme II BCM5708 1000Base-T 0.9.6 driver in Dell 1950 and 2950 behave super slow State-Changed-From-To: feedback->closed State-Changed-By: vwe State-Changed-When: Fri May 2 09:47:48 UTC 2008 State-Changed-Why: We're sorry to not see any feedback received for quite some time. If you think this is still an issue which should be worked on, please provide the requested information and we'll be happy to reopen this ticket. Thank you for bringing this problem to attention! http://www.freebsd.org/cgi/query-pr.cgi?pr=120725 From owner-freebsd-net@FreeBSD.ORG Fri May 2 09:49:57 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F196B1065682 for ; Fri, 2 May 2008 09:49:57 +0000 (UTC) (envelope-from petar@morrison.andev.ch) Received: from morrison.andev.ch (morrison.andev.ch [78.47.142.202]) by mx1.freebsd.org (Postfix) with ESMTP id 96CA48FC25 for ; Fri, 2 May 2008 09:49:57 +0000 (UTC) (envelope-from petar@morrison.andev.ch) Received: by morrison.andev.ch (Postfix, from userid 1000) id 1DFE25DB74; Fri, 2 May 2008 11:38:40 +0200 (CEST) Date: Fri, 2 May 2008 11:36:55 +0200 From: Petar Bogdanovic To: freebsd-net@freebsd.org Message-ID: <20080502093655.GA3535@pintail.smokva.net> Mail-Followup-To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) Subject: authentication timeouts with ath(4) in hostap mode 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, 02 May 2008 09:49:58 -0000 Hi, I'm using an alix2c0 board with two winstron CM9 ath(4)-cards and FreeBSD 7: ifconfig ath0 (...) mediaopt hostap mode 11a channel 36 ssid sn.a -bgscan ifconfig ath1 (...) mediaopt hostap mode 11g channel 11 ssid sn.g -bgscan When I try to raise the traffic (i.e. dd | ssh AP dd) my Linux wpa_supplicant drops the connection and has to reassociate. This however does not work immediately; The supplicant fails a few times before reconnecting: <2>CTRL-EVENT-CONNECTED - Connection to 00:0b:0b:06:0d:09 completed (reauth) [id=0 id_str=] <2>CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) <2>Authentication with 00:0b:0b:06:0d:09 timed out. <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) <2>Authentication with 00:0b:0b:06:0d:09 timed out. <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) <2>Authentication with 00:0b:0b:06:0d:09 timed out. <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) <2>Authentication with 00:0b:0b:06:0d:09 timed out. <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) <2>Authentication with 00:0b:0b:06:0d:09 timed out. <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) <2>Authentication with 00:0b:0b:06:0d:09 timed out. <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) <2>Associated with 00:0b:0b:06:0d:09 <2>WPA: Key negotiation completed with 00:0b:0b:06:0d:09 [PTK=CCMP GTK=CCMP] <2>CTRL-EVENT-CONNECTED - Connection to 00:0b:0b:06:0d:09 completed (reauth) [id=0 id_str=] This happens more on the 11a than on the 11g network. When I'm next to the AP, the timeouts are almost gone but they still happen. (My laptop is just one room away from the AP). Here is the athstats-output of ath0 (11a): # ./athstats -i ath0 481546 data frames received 330669 data frames transmit 13395 tx frames with an alternate rate 78558 long on-chip tx retries 1431 tx failed 'cuz too many retries 36M current transmit rate 78 tx management frames 3 tx frames discarded prior to association 45 tx frames with no ack marked 2894 rx failed 'cuz of bad CRC 2 rx failed 'cuz decryption 92711 rx failed 'cuz of PHY err 92708 OFDM timing 3 OFDM restart 318332 beacons transmitted 1111 periodic calibrations 2 rfgain value change 22 rssi of last ack 23 avg recv rssi -96 rx noise floor 2530 switched default/rx antenna Antenna profile: [1] tx 173364 rx 123068 [2] tx 155874 rx 358671 All this is well known to me, since I had NetBSD running on this device for months and it suffered the same problems -- it was even worse, the timeouts occured every few minutes. Back then, it seemed that ath had some interrupt problems: ath0: device timeout as David Young from NetBSD noticed in his mail some time ago: http://mail-index.netbsd.org/tech-net/2007/11/29/0001.html FreeBSD doesn't seem to have this `device timeouts'. I don't see any in /var/log/messages and there are none when I'm connected to the device over a serial port. I'm a bit lost here, but ready to debug if someone knows more. Thanks, Petar From owner-freebsd-net@FreeBSD.ORG Fri May 2 15:44:23 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1FEDE106564A for ; Fri, 2 May 2008 15:44:23 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id E8D758FC18 for ; Fri, 2 May 2008 15:44:22 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 10B5B105035; Fri, 2 May 2008 11:44:22 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Fri, 02 May 2008 11:44:22 -0400 X-Sasl-enc: HcxQ4Xpi8vg9Ig4MumI948eGl/KbHmFDdGg+gY3wjwSa 1209743061 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 49C60135C0; Fri, 2 May 2008 11:44:21 -0400 (EDT) Message-ID: <481B36D4.3050103@FreeBSD.org> Date: Fri, 02 May 2008 16:44:20 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.12 (X11/20080423) MIME-Version: 1.0 To: John Hay References: <20080430172705.2E3275AD6@mail.bitblocks.com> <4818BC79.40605@elischer.org> <20080502090200.GA57055@zibbi.meraka.csir.co.za> In-Reply-To: <20080502090200.GA57055@zibbi.meraka.csir.co.za> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , Julian Elischer Subject: Re: multiple routing tables review patch ready for simple testing. 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, 02 May 2008 15:44:23 -0000 John Hay wrote: > The linux guys seems to have multiple fibs (or whatever they call them) > which they can chain together by giving them different priorities. The > effect seems to be that a packet will be matched through the highest > priority fib to the lowest until a route match is found en then is used. > Will something like that be possible? I came across that kind of use > with the olsr guys. They let olsrd twiddle one of the higher priority > fibs and then put fallback routes in a lower priority fib. That way > olsrd can override a route (even the default route) and when olsrd > exists and deltes all its routes, the original ones are still in the > lower priority fib and will be used. > XORP already does this without relying on any kernel support. Each routing protocol supplies an origin table of its own. The RIB makes the decision on which route to plumb to the kernel based on administrative distance. When xorp_olsr exits, its origin table is removed, and the winning routes are recalculated. You don't need to go to the kernel for this sort of thing unless you specifically need to implement route policy based on which interface(s) a packet came in on. From owner-freebsd-net@FreeBSD.ORG Fri May 2 17:43:00 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E967E106566C; Fri, 2 May 2008 17:43:00 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [IPv6:2001:4200:7000:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 265F88FC25; Fri, 2 May 2008 17:43:00 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id C769433CCD; Fri, 2 May 2008 19:42:58 +0200 (SAST) Date: Fri, 2 May 2008 19:42:58 +0200 From: John Hay To: "Bruce M. Simpson" Message-ID: <20080502174258.GA20244@zibbi.meraka.csir.co.za> References: <20080430172705.2E3275AD6@mail.bitblocks.com> <4818BC79.40605@elischer.org> <20080502090200.GA57055@zibbi.meraka.csir.co.za> <481B36D4.3050103@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <481B36D4.3050103@FreeBSD.org> User-Agent: Mutt/1.4.2.1i Cc: FreeBSD Net , Julian Elischer Subject: Re: multiple routing tables review patch ready for simple testing. 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, 02 May 2008 17:43:01 -0000 On Fri, May 02, 2008 at 04:44:20PM +0100, Bruce M. Simpson wrote: > John Hay wrote: > >The linux guys seems to have multiple fibs (or whatever they call them) > >which they can chain together by giving them different priorities. The > >effect seems to be that a packet will be matched through the highest > >priority fib to the lowest until a route match is found en then is used. > >Will something like that be possible? I came across that kind of use > >with the olsr guys. They let olsrd twiddle one of the higher priority > >fibs and then put fallback routes in a lower priority fib. That way > >olsrd can override a route (even the default route) and when olsrd > >exists and deltes all its routes, the original ones are still in the > >lower priority fib and will be used. > > > > XORP already does this without relying on any kernel support. > > Each routing protocol supplies an origin table of its own. The RIB makes > the decision on which route to plumb to the kernel based on > administrative distance. When xorp_olsr exits, its origin table is > removed, and the winning routes are recalculated. > > You don't need to go to the kernel for this sort of thing unless you > specifically need to implement route policy based on which interface(s) > a packet came in on. Yes I know that. But in the world of adhoc wireless mesh networking there are very few non-linux people, so they basically call the shots and use the linux kernel features to the full. To them it is unneeded complexity that the kernel already takes care of. :-/ In a sense I can understand them because their stuff also run on the small embedded stuff like the linksys wireless boxes and it needs to scale. The biggest adhoc olsr network is probably the Freifunk one that have more than 600 wireless nodes, mostly consisting of linksys boxes. On some boxes that are also connected to different kinds of networks, they run a different routing daemon into another fib and by setting the priorities on the fibs, they can decide which daemon's routes have the highest priority. And both routing daemons are happy because the other is not stomping on its feet. John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Fri May 2 18:02:28 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D33C11065670 for ; Fri, 2 May 2008 18:02:28 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outC.internet-mail-service.net (outc.internet-mail-service.net [216.240.47.226]) by mx1.freebsd.org (Postfix) with ESMTP id B73948FC12 for ; Fri, 2 May 2008 18:02:28 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Fri, 02 May 2008 16:49:07 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 8FFAA2D6004; Fri, 2 May 2008 11:02:27 -0700 (PDT) Message-ID: <481B5733.7020503@elischer.org> Date: Fri, 02 May 2008 11:02:27 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: John Hay References: <20080430172705.2E3275AD6@mail.bitblocks.com> <4818BC79.40605@elischer.org> <20080502090200.GA57055@zibbi.meraka.csir.co.za> In-Reply-To: <20080502090200.GA57055@zibbi.meraka.csir.co.za> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net Subject: Re: multiple routing tables review patch ready for simple testing. 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, 02 May 2008 18:02:28 -0000 John Hay wrote: >>> This confuses me.... >>> >>> The whole point of a FIB is to decide the *next* hop for a >>> given input packet. So questions. >>> 1) A packet arrives on an interface. If this interface is >>> associated with more than one FIB, which FIB does it get >>> given to? >>> >> which ever one you select, using the policy of your choice. >> >> that's what policy routing is about. >> if you don't WANT policy based routing, dont turn it on. >> >> >> >>> 2) If that decision is taken by a a packet 'classifier', >>> isn't it in effect doing the job of a FIB (deciding the >>> next hop, which happens to be a local FIB)? Recall that >>> basically a packet passes from a FIB to another FIB until >>> it gets to its eventual destination. >> the packet classifier selects a FIB which in turn implements a >> particular routing decision tree. >> In the degenerate case where a FIB has only one route >> then you are correct, but there are technical reasons why this is >> superior to just using a fwd rule in the firewall. > > The linux guys seems to have multiple fibs (or whatever they call them) > which they can chain together by giving them different priorities. The > effect seems to be that a packet will be matched through the highest > priority fib to the lowest until a route match is found en then is used. > Will something like that be possible? I came across that kind of use > with the olsr guys. They let olsrd twiddle one of the higher priority > fibs and then put fallback routes in a lower priority fib. That way > olsrd can override a route (even the default route) and when olsrd > exists and deltes all its routes, the original ones are still in the > lower priority fib and will be used. no we are going to do the simple thing.. such enhancements can be done later if there is a call for it. We will just have a number of tables that you can associate a packet with at a number of points in its path. having another table as the 'default route' for a table (i.e. if you don't find something look in another table) is something that would be relatively easy to do, but I have not done it. > > John From owner-freebsd-net@FreeBSD.ORG Fri May 2 19:47:28 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39D261065676 for ; Fri, 2 May 2008 19:47:28 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outM.internet-mail-service.net (outm.internet-mail-service.net [216.240.47.236]) by mx1.freebsd.org (Postfix) with ESMTP id 1BC378FC15 for ; Fri, 2 May 2008 19:47:28 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Fri, 02 May 2008 18:53:03 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 1C59B2D601F; Fri, 2 May 2008 12:47:27 -0700 (PDT) Message-ID: <481B6FCE.2080605@elischer.org> Date: Fri, 02 May 2008 12:47:26 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: John Hay References: <20080430172705.2E3275AD6@mail.bitblocks.com> <4818BC79.40605@elischer.org> <20080502090200.GA57055@zibbi.meraka.csir.co.za> <481B5733.7020503@elischer.org> In-Reply-To: <481B5733.7020503@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net Subject: Re: multiple routing tables review patch ready for simple testing. 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, 02 May 2008 19:47:28 -0000 Julian Elischer wrote: > John Hay wrote: >>>> This confuses me.... >>>> >>>> The whole point of a FIB is to decide the *next* hop for a >>>> given input packet. So questions. >>>> 1) A packet arrives on an interface. If this interface is >>>> associated with more than one FIB, which FIB does it get >>>> given to? >>>> >>> which ever one you select, using the policy of your choice. >>> >>> that's what policy routing is about. >>> if you don't WANT policy based routing, dont turn it on. >>> >>> >>> >>>> 2) If that decision is taken by a a packet 'classifier', >>>> isn't it in effect doing the job of a FIB (deciding the >>>> next hop, which happens to be a local FIB)? Recall that >>>> basically a packet passes from a FIB to another FIB until >>>> it gets to its eventual destination. >>> the packet classifier selects a FIB which in turn implements a >>> particular routing decision tree. >>> In the degenerate case where a FIB has only one route >>> then you are correct, but there are technical reasons why this is >>> superior to just using a fwd rule in the firewall. >> >> The linux guys seems to have multiple fibs (or whatever they call them) >> which they can chain together by giving them different priorities. The >> effect seems to be that a packet will be matched through the highest >> priority fib to the lowest until a route match is found en then is used. >> Will something like that be possible? I came across that kind of use >> with the olsr guys. They let olsrd twiddle one of the higher priority >> fibs and then put fallback routes in a lower priority fib. That way >> olsrd can override a route (even the default route) and when olsrd >> exists and deltes all its routes, the original ones are still in the >> lower priority fib and will be used. > > no we are going to do the simple thing.. > such enhancements can be done later if there is a call for it. > > We will just have a number of tables that you can associate a packet > with at a number of points in its path. having another table as the > 'default route' for a table (i.e. if you don't find something look in > another table) is something that would be relatively easy to do, but > I have not done it.hav Having been prodded to go look up OLSR i an say that this is exactly the kind of thing that multiple routing tables are useful for. OLSR is an overlay network and any machine that participated must have a split personality. First it must be able to think in terms of the basic local network, and it must be able to think in terms of the world from the perspective of the overlay. In this case you would set the overlay interfaces to work with FIB 1 so that packets are transported according to rules defined there and the application packets to the internet would be routed according to FIB 0 which would have entries for the overlay interfaces but not necessarily entries for the actual physical interfaces. (for example) From owner-freebsd-net@FreeBSD.ORG Fri May 2 19:57:39 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 245F11065674 for ; Fri, 2 May 2008 19:57:39 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 765768FC1C for ; Fri, 2 May 2008 19:57:38 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 32534 invoked from network); 2 May 2008 19:00:21 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 2 May 2008 19:00:21 -0000 Message-ID: <481B7232.60608@freebsd.org> Date: Fri, 02 May 2008 21:57:38 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Mark Hills References: <20080420025010.GJ73016@server.vk2pj.dyndns.org> <480BBD7E.8010700@freebsd.org> <480C9AC6.8090802@freebsd.org> <480E7901.5000804@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Peter Jeremy , rwatson@freebsd.org, freebsd-net@freebsd.org Subject: Re: read() returns ETIMEDOUT on steady TCP connection 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, 02 May 2008 19:57:39 -0000 Mark Hills wrote: > On Wed, 23 Apr 2008, Andre Oppermann wrote: > >> http://people.freebsd.org/~andre/tcp_output-error-log.diff >> >> Please apply this patch and enable the sysctl net.inet.tcp.log_debug=1 >> and report any output. You likely get some (normal) noise from syncache. >> What we are looking for is reports from tcp_output. > > Hi Andre, I've applied the patch and tested. > > Aside from syncache noise, I get a constant stream of 'error 55' > (ENOBUFS?), once the number of connection gets to around 150 at 192kbps. > > TCP: [192.168.5.43]:52153 to [192.168.5.40]:8080; tcp_output: error 55 > while sending > > 192.168.5.40 is the IP address of this host, running the server. > > I tried to correlate the point of the application receiving ETIMEDOUT > with these messages, but that is tricky as it seems to be outputting a > lot of messages, and multiple messages over eachother (see below). > > Because of the mention of no buffer space available, I checked the > values of net.inet.tcp.sendbuf* and recvbuf*, and increased the max > values with no effect. > > When I get time I will modify the kernel to print errors which aren't > ENOBUFS to see if there are any others. But in the meantime, this sounds > like a problem to me. Is that correct? > > Mark > > > :8080; tcp_output: error 55 while sending > TCP: [192.168.5.42]:57384T CtPo: > [[119922..116688..55..4402]]::85048400;1 ttoc p[_1o9u2t.p1u6t8:. > 5e.r4r0o]r: 8080;5 5t cwp_hoiultep uste:n deirnrgor 55 while sending > TCP: [192.168.5.42]:57382 to [192.168.5.40]:8080; tcp_output: error 55 > while sending > TCP: [192.168.5.42]:57381 to [192.168.5.40]:8080; tcp_output: error 55 > while sending > TCP: [192.168.5.42]:57380 to [192.168.5.40]:8080; tcp_output: error 55 > while sending After tracing through the code it seems you are indeed memory limited. Looking back at the netstat -m output: 12550/250/12800/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) This shows that the supply of 4k jumbo clusters is pretty much exhausted. The cache may be allocated to different CPUs and the one making the request at a given point may be depleted and can't get any from the global pool. The big question is why the denied counter doesn't report anything. I've looked at the code paths and don't see any obvious reason why it doesn't get counted. Maybe Robert can give some insight here. Try doubling the amount of 4k page size jumbo mbufs. They are the primary workhorse in the kernel right now: sysctl kern.ipc.nmbjumbop=25600 This should get further. Still more may be necessary depending on workloads. -- Andre From owner-freebsd-net@FreeBSD.ORG Fri May 2 20:15:43 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C18D3106567E for ; Fri, 2 May 2008 20:15:43 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by mx1.freebsd.org (Postfix) with ESMTP id 754F18FC15 for ; Fri, 2 May 2008 20:15:43 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so5690ywe.13 for ; Fri, 02 May 2008 13:15:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=Yi8we0zE6+DReN2ZxPQmFn+6dhAlmF2UKpHjf0vUcG8=; b=ZYaKJArJJryEn6uX4JoY8uxoo9NpCaEtpul+iCgnkrhzw6OsIOMwNpqOMQTPfMDJuO7BEhSuup21VMBaxCbpuYayG7klUOCzlXb/5rV7M4W4RXHQ5c1oYeM6kpkr5FkmbFqYV63PGzIflfsCjC1Ecdq8YfqGU1Bu8ktLQ56DbjQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=aRhdH+GWLht38wkeXyo0jZ9e7LD4QCowgQNJMPoctXDQ5+w5Ut5bMRzz5KqzCWL8UiLY6IneBgf2nxdyDfcaP8XIFDtrBcA7YC/s4/xnM82VWwZtZgpvJuLVqgTkN4DIMWeq3cskeu/lWkCzdtc9rY1f7wICzrOAcQROx6PiJWI= Received: by 10.150.51.9 with SMTP id y9mr3983087yby.39.1209759337950; Fri, 02 May 2008 13:15:37 -0700 (PDT) Received: by 10.151.11.1 with HTTP; Fri, 2 May 2008 13:15:37 -0700 (PDT) Message-ID: <3c0b01820805021315i482fe0acg3e9238a2f412770e@mail.gmail.com> Date: Fri, 2 May 2008 16:15:37 -0400 From: "Alexander Sack" To: "David Christensen" In-Reply-To: <5D267A3F22FD854F8F48B3D2B523819324F09D65FA@IRVEXCHCCR01.corp.ad.broadcom.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5D267A3F22FD854F8F48B3D2B523819324F09D65FA@IRVEXCHCCR01.corp.ad.broadcom.com> Cc: "freebsd-net@freebsd.org" Subject: Re: Not All Symbols Present in a Loadable Kernel Module 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, 02 May 2008 20:15:43 -0000 On Thu, May 1, 2008 at 10:04 PM, David Christensen wrote: > I'm trying to build the "bce" driver as a kernel module under RELENG_7 but I'm > finding that not all of the functions in the driver are exported as symbols. This > makes it difficult to "call" a function from ddb because I get the error "Symbol > not found". I'm building and loading the driver from /usr/src/sys/modules/bce. > What am I doing wrong? How can I get all functions in the driver exported as > symbols usable by the debugger? Are you building a debug kernel or regular kernel? Have you turned on debug symbols? makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols Just a quick thought...I'm assuming these symbols are listed under your final kernel image (nm it etc.). -aps From owner-freebsd-net@FreeBSD.ORG Fri May 2 20:56:47 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3190A106564A; Fri, 2 May 2008 20:56:47 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 029718FC1B; Fri, 2 May 2008 20:56:47 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m42Kukb8010247; Fri, 2 May 2008 20:56:46 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m42Kukel010243; Fri, 2 May 2008 20:56:46 GMT (envelope-from linimon) Date: Fri, 2 May 2008 20:56:46 GMT Message-Id: <200805022056.m42Kukel010243@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-i386@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/123330: [nsswitch] Enabling samba wins in nsswitch.conf causes sshd, ftpd, etc services to die 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, 02 May 2008 20:56:47 -0000 Old Synopsis: Enabling samba wins in nsswitch.conf causes sshd, ftpd, etc services to die New Synopsis: [nsswitch] Enabling samba wins in nsswitch.conf causes sshd, ftpd, etc services to die Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri May 2 20:55:46 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=123330 From owner-freebsd-net@FreeBSD.ORG Fri May 2 23:19:09 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EEC9A106564A for ; Fri, 2 May 2008 23:19:09 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id B63C08FC0C for ; Fri, 2 May 2008 23:19:09 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 046981051B4; Fri, 2 May 2008 19:19:09 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Fri, 02 May 2008 19:19:09 -0400 X-Sasl-enc: MVaacI9G0zRfJyxVB9x7YSGVnl2YXypHdMH41K2WbUTx 1209770348 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 63CE5262B6; Fri, 2 May 2008 19:19:08 -0400 (EDT) Message-ID: <481BA16B.9000803@FreeBSD.org> Date: Sat, 03 May 2008 00:19:07 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.12 (X11/20080423) MIME-Version: 1.0 To: Julian Elischer References: <20080430172705.2E3275AD6@mail.bitblocks.com> <4818BC79.40605@elischer.org> <20080502090200.GA57055@zibbi.meraka.csir.co.za> <481B5733.7020503@elischer.org> <481B6FCE.2080605@elischer.org> In-Reply-To: <481B6FCE.2080605@elischer.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net Subject: Re: multiple routing tables review patch ready for simple testing. 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, 02 May 2008 23:19:10 -0000 Julian Elischer wrote: > > OLSR is an overlay network Nope -- the express intention was that it could be used for basic IP connectivity, for mobile devices. In OLSR, every node is a potential IP forwarder unless it explicitly advertises itself as being unwilling to forward. > and any machine that participated must have a split personality. First > it must be able to think in terms of the basic local network, and it > must be able to think in terms > of the world from the perspective of the overlay. Applying routing policy gets more important at the border. The OLSR implementation in XORP is intended to give people a means of connectivity between MANET and non-MANET routing domains, by redistributing routes into the OLSR cloud. I daresay these capabilities will get more important, and relevant, to the MANET picture as time goes on, but it's best to leave them out of the operational picture for now, in my opinion. cheers BMS From owner-freebsd-net@FreeBSD.ORG Fri May 2 23:26:15 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2EFC106567C for ; Fri, 2 May 2008 23:26:15 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id 7DCAB8FC28 for ; Fri, 2 May 2008 23:26:15 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 2DD16E4716; Fri, 2 May 2008 19:26:15 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Fri, 02 May 2008 19:26:15 -0400 X-Sasl-enc: hj0c1SSrCigQOUA8+Lsw1KtTfLWFSCTl1911eF12YbZo 1209770774 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 6E0A214E10; Fri, 2 May 2008 19:26:14 -0400 (EDT) Message-ID: <481BA315.3000309@FreeBSD.org> Date: Sat, 03 May 2008 00:26:13 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.12 (X11/20080423) MIME-Version: 1.0 To: John Hay References: <20080430172705.2E3275AD6@mail.bitblocks.com> <4818BC79.40605@elischer.org> <20080502090200.GA57055@zibbi.meraka.csir.co.za> <481B36D4.3050103@FreeBSD.org> <20080502174258.GA20244@zibbi.meraka.csir.co.za> In-Reply-To: <20080502174258.GA20244@zibbi.meraka.csir.co.za> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , Julian Elischer Subject: Re: multiple routing tables review patch ready for simple testing. 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, 02 May 2008 23:26:15 -0000 John Hay wrote: >> You don't need to go to the kernel for this sort of thing unless you >> specifically need to implement route policy based on which interface(s) >> a packet came in on. >> > > Yes I know that. But in the world of adhoc wireless mesh networking > there are very few non-linux people, so they basically call the shots > and use the linux kernel features to the full. Not true. There's an awful lot going on behind closed doors in the MANET world, and from the sounds of the emanations, they might not be using Linux at all. > In a sense I can > understand them because their stuff also run on the small embedded > stuff like the linksys wireless boxes and it needs to scale. The > biggest adhoc olsr network is probably the Freifunk one that have > more than 600 wireless nodes, mostly consisting of linksys boxes. > The complexity of any system like that is still there, regardless of whether or not people choose to make it harder to debug code by prematurely pushing it into the kernel. > On some boxes that are also connected to different kinds of networks, > they run a different routing daemon into another fib and by setting > the priorities on the fibs, they can decide which daemon's routes > have the highest priority. And both routing daemons are happy because > the other is not stomping on its feet. > Yes, but this is largely to do with the fact that the Linux netlink socket allows daemons to coexist due to its use of a tag-length-value which captures that information, a different kettle of fish. The feature you describe is totally possible without adding complexity to Julian's current effort. cheers BMS From owner-freebsd-net@FreeBSD.ORG Sat May 3 00:07:00 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5AD981065682 for ; Sat, 3 May 2008 00:07:00 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by mx1.freebsd.org (Postfix) with ESMTP id 1CAD18FC18 for ; Sat, 3 May 2008 00:06:59 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from [10.11.16.99] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Fri, 02 May 2008 17:06:51 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 6E6952B1; Fri, 2 May 2008 17:06:51 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.11.18.52]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 59B522B0; Fri, 2 May 2008 17:06:51 -0700 (PDT) Received: from mail-irva-13.broadcom.com (mail-irva-13.broadcom.com [10.11.16.103]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id GVP69713; Fri, 2 May 2008 17:06:48 -0700 (PDT) Received: from NT-IRVA-0751.brcm.ad.broadcom.com (nt-irva-0751 [10.8.194.65]) by mail-irva-13.broadcom.com (Postfix) with ESMTP id CB55E74CFE; Fri, 2 May 2008 17:06:48 -0700 (PDT) Received: from IRVEXCHHUB01.corp.ad.broadcom.com ([10.9.200.131]) by NT-IRVA-0751.brcm.ad.broadcom.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 May 2008 17:06:48 -0700 Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.9.200.129]) by IRVEXCHHUB01.corp.ad.broadcom.com ([10.9.200.131]) with mapi; Fri, 2 May 2008 17:06:48 -0700 From: "David Christensen" To: "Alexander Sack" Date: Fri, 2 May 2008 17:06:53 -0700 Thread-Topic: Not All Symbols Present in a Loadable Kernel Module Thread-Index: AciskU/GzCFtOYnmQvKpV8iqtIh/CQAH8c7w Message-ID: <5D267A3F22FD854F8F48B3D2B523819324F09D6896@IRVEXCHCCR01.corp.ad.broadcom.com> References: <5D267A3F22FD854F8F48B3D2B523819324F09D65FA@IRVEXCHCCR01.corp.ad.broadcom.com> <3c0b01820805021315i482fe0acg3e9238a2f412770e@mail.gmail.com> In-Reply-To: <3c0b01820805021315i482fe0acg3e9238a2f412770e@mail.gmail.com> Accept-Language: en-US Content-Language: en-US x-cr-hashedpuzzle: CyrK FvcX GLP0 JUO2 KeY0 K0b1 Lv8T L3o3 NlR/ No9/ O1wC PqLN P3Tt SBON TqEO UkLe; 2; ZgByAGUAZQBiAHMAZAAtAG4AZQB0AEAAZgByAGUAZQBiAHMAZAAuAG8AcgBnADsAcABpAHMAeQBtAGIAbwBsAEAAZwBtAGEAaQBsAC4AYwBvAG0A; Sosha1_v1; 7; {158EEE88-137B-4857-BEE2-5ECF04497D89}; ZABhAHYAaQBkAGMAaABAAGIAcgBvAGEAZABjAG8AbQAuAGMAbwBtAA==; Sat, 03 May 2008 00:06:53 GMT; UgBFADoAIABOAG8AdAAgAEEAbABsACAAUwB5AG0AYgBvAGwAcwAgAFAAcgBlAHMAZQBuAHQAIABpAG4AIABhACAATABvAGEAZABhAGIAbABlACAASwBlAHIAbgBlAGwAIABNAG8AZAB1AGwAZQA= x-cr-puzzleid: {158EEE88-137B-4857-BEE2-5ECF04497D89} acceptlanguage: en-US MIME-Version: 1.0 X-OriginalArrivalTime: 03 May 2008 00:06:48.0724 (UTC) FILETIME=[94E45540:01C8ACB1] X-WSS-ID: 640573113M833137199-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "freebsd-net@freebsd.org" Subject: RE: Not All Symbols Present in a Loadable Kernel Module 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, 03 May 2008 00:07:00 -0000 > > I'm trying to build the "bce" driver as a kernel module under > RELENG_7 but I'm > > finding that not all of the functions in the driver are exported as > symbols. This > > makes it difficult to "call" a function from ddb because I get the > error "Symbol > > not found". I'm building and loading the driver from > /usr/src/sys/modules/bce. > > What am I doing wrong? How can I get all functions in the driver > exported as > > symbols usable by the debugger? > > Are you building a debug kernel or regular kernel? Have you turned on > debug symbols? > > makeoptions DEBUG=3D-g # Build kernel with gdb(1) > debug symbols > > Just a quick thought...I'm assuming these symbols are listed under > your final kernel image (nm it etc.). Yes, I'm building a debug kernel. I have the line listed above as well as the following: options KDB options DDB options GDB options INVARIANTS options INVARIANT_SUPPORT options WITNESS options WITNESS_SKIPSPIN Dave From owner-freebsd-net@FreeBSD.ORG Sat May 3 00:25:10 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1B991065677 for ; Sat, 3 May 2008 00:25:10 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 99DEB8FC1E for ; Sat, 3 May 2008 00:25:10 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from Macintosh-2.local ([10.0.0.194]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m430P9pc075622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 2 May 2008 17:25:10 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <481BB0E5.8000803@freebsd.org> Date: Fri, 02 May 2008 17:25:09 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <20080502093655.GA3535@pintail.smokva.net> In-Reply-To: <20080502093655.GA3535@pintail.smokva.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-Rhyolite-Metrics: ebb.errno.com; whitelist Subject: Re: authentication timeouts with ath(4) in hostap mode 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, 03 May 2008 00:25:11 -0000 Petar Bogdanovic wrote: > Hi, > > I'm using an alix2c0 board with two winstron CM9 ath(4)-cards and > FreeBSD 7: > > ifconfig ath0 (...) mediaopt hostap mode 11a channel 36 ssid sn.a -bgscan > ifconfig ath1 (...) mediaopt hostap mode 11g channel 11 ssid sn.g -bgscan > > > When I try to raise the traffic (i.e. dd | ssh AP dd) my Linux > wpa_supplicant drops the connection and has to reassociate. This however > does not work immediately; The supplicant fails a few times before > reconnecting: > > <2>CTRL-EVENT-CONNECTED - Connection to 00:0b:0b:06:0d:09 completed (reauth) [id=0 id_str=] > <2>CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys > <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) > <2>Authentication with 00:0b:0b:06:0d:09 timed out. > <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) > <2>Authentication with 00:0b:0b:06:0d:09 timed out. > <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) > <2>Authentication with 00:0b:0b:06:0d:09 timed out. > <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) > <2>Authentication with 00:0b:0b:06:0d:09 timed out. > <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) > <2>Authentication with 00:0b:0b:06:0d:09 timed out. > <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) > <2>Authentication with 00:0b:0b:06:0d:09 timed out. > <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) > <2>Associated with 00:0b:0b:06:0d:09 > <2>WPA: Key negotiation completed with 00:0b:0b:06:0d:09 [PTK=CCMP GTK=CCMP] > <2>CTRL-EVENT-CONNECTED - Connection to 00:0b:0b:06:0d:09 completed (reauth) [id=0 id_str=] > > > This happens more on the 11a than on the 11g network. When I'm next to > the AP, the timeouts are almost gone but they still happen. (My laptop > is just one room away from the AP). Here is the athstats-output of ath0 > (11a): > > # ./athstats -i ath0 > 481546 data frames received > 330669 data frames transmit > 13395 tx frames with an alternate rate > 78558 long on-chip tx retries > 1431 tx failed 'cuz too many retries > 36M current transmit rate > 78 tx management frames > 3 tx frames discarded prior to association > 45 tx frames with no ack marked > 2894 rx failed 'cuz of bad CRC > 2 rx failed 'cuz decryption > 92711 rx failed 'cuz of PHY err > 92708 OFDM timing > 3 OFDM restart > 318332 beacons transmitted > 1111 periodic calibrations > 2 rfgain value change > 22 rssi of last ack > 23 avg recv rssi > -96 rx noise floor > 2530 switched default/rx antenna > Antenna profile: > [1] tx 173364 rx 123068 > [2] tx 155874 rx 358671 So the obvious question is whether your system config has enough isolation of the radios for them not to impact each other? I have no experience with Alix boards but it's not uncommon for there to be power and signal issues when operating multiple radios in an enclosure (and yes, even with the radios on different bands). You don't indicate what you've done to diagnose this problem. Have you verified the packets are present in the air? Have you traced packets and/or phy errors around the time of the problem? Does turning off one radio give you stable operation? Have you tried different channels? Have you tried different boards? > > > All this is well known to me, since I had NetBSD running on this device > for months and it suffered the same problems -- it was even worse, the > timeouts occured every few minutes. Back then, it seemed that ath had > some interrupt problems: > > ath0: device timeout > > as David Young from NetBSD noticed in his mail some time ago: > > http://mail-index.netbsd.org/tech-net/2007/11/29/0001.html > > > FreeBSD doesn't seem to have this `device timeouts'. I don't see any in > /var/log/messages and there are none when I'm connected to the device > over a serial port. > > I'm a bit lost here, but ready to debug if someone knows more. netbsd's code base is many _years_ out of date wrt freebsd; comparing operation of the two systems is unlikely to be useful. Sam From owner-freebsd-net@FreeBSD.ORG Sat May 3 04:24:31 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B475F106566B for ; Sat, 3 May 2008 04:24:31 +0000 (UTC) (envelope-from paul.haddad@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by mx1.freebsd.org (Postfix) with ESMTP id 86B0D8FC12 for ; Sat, 3 May 2008 04:24:31 +0000 (UTC) (envelope-from paul.haddad@gmail.com) Received: by wa-out-1112.google.com with SMTP id j4so1480453wah.3 for ; Fri, 02 May 2008 21:24:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=ha9aNLIH+qXvzhytftE0fYenYXMjK3n61By+Ka+WOGs=; b=uaK7V4K9CWOq48qWEI7KEXCTPbB8e2+J2jqSMgE4LoPCt60TqKVUOxUnwF/G53eiu2ell1LZ3sxAmDIDNL4zlnrM9tKQZn8IN31bRcMuXhBqu4luXBRIxMRm8nhyozw5EE3XbJJmnEuGEo0tukkAoo2E16tI4kTTS2GQHBH/PbA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=Xjj3x+MPk2QncNfxIRRDW3Ae3k+z5QFJpZ1PRkZ7Q6zt/pipn88DuOTAYUbyBvs5u/ix637Tn9eYffEnQ3Vo5GXgRD+nETuMmpHzxsQay0qAE3JAN9keH4o9RAXV9Fj0gWzxThHAAm7e8rPvR/Hrvc4mMSOD2xGjlUV6es6s4Fk= Received: by 10.114.169.2 with SMTP id r2mr3674855wae.118.1209788671054; Fri, 02 May 2008 21:24:31 -0700 (PDT) Received: by 10.115.77.7 with HTTP; Fri, 2 May 2008 21:24:31 -0700 (PDT) Message-ID: <944074f30805022124n31e28fddkea80fcc78cbd8bc6@mail.gmail.com> Date: Fri, 2 May 2008 23:24:31 -0500 From: "Paul Haddad" To: net@freebsd.org In-Reply-To: <944074f30804191423v93d1acet9246269e4072d46a@mail.gmail.com> MIME-Version: 1.0 References: <944074f30804191423v93d1acet9246269e4072d46a@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Network Instability when upgrading to 4GB of RAM 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, 03 May 2008 04:24:31 -0000 All, As a follow up to myself I installed an Intel PCIe NIC and disabled the on board RTL based one and all my problems went away. Been running with 4GB installed for a couple days now with absolutely no network issues. So seems like there's some problem with RTL NICs and >= 4GB of RAM. -- Paul Haddad (paul.haddad@gmail.com paul@pth.com) From owner-freebsd-net@FreeBSD.ORG Sat May 3 07:14:33 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CA2A1065678 for ; Sat, 3 May 2008 07:14:33 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.181]) by mx1.freebsd.org (Postfix) with ESMTP id 34B9A8FC14 for ; Sat, 3 May 2008 07:14:32 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by wa-out-1112.google.com with SMTP id j4so1610045wah.3 for ; Sat, 03 May 2008 00:14:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=dTvy5H+nGN+ku0Y8JbsTLDfcHBjFVgVr3lyWzWsDFHI=; b=jSy5jZ44Evui6yyAVYfPsxiChuzspEMYdQA27JJ5dXeFD62RzrOtH6hm6ERrurVLJsRZwnolIkPWYPqlRKHSODg+zwQpGEmxzHqmscnTb9UCw6viVIzPLFpEycrU3S0p5nFcFf9Zf68NZ3NNqvqoQZFiD1uAWJNkKrSbs4s78Z8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=orGEN5CdV3AnUx0wpfAquZ0CoDIgDeHG6DQ//8filZ/7cL1+HkteIoHiOKGu4KxbgEq1rxfJHXENChtzhr4E9uhdQCgvXs9ELp8/fwQM7uihdNU+quoK8YUpzGblBgZAdTV6b33PRtUfvWZOJaZ5ZUGTJC0jwAN0HKaEpzUOp4Q= Received: by 10.114.196.13 with SMTP id t13mr3727570waf.219.1209798872697; Sat, 03 May 2008 00:14:32 -0700 (PDT) Received: by 10.114.177.4 with HTTP; Sat, 3 May 2008 00:14:32 -0700 (PDT) Message-ID: <2a41acea0805030014x244e1311v945e23266961193d@mail.gmail.com> Date: Sat, 3 May 2008 00:14:32 -0700 From: "Jack Vogel" To: "freebsd-net@freebsd.org" , "FreeBSD Stable List" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: MFC of em/igb drivers 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, 03 May 2008 07:14:33 -0000 I got the new drivers in Friday afternoon for those that don't see CVS messages. The igb driver is for 82575 and 82576 adapters, it has multiqueue support and MSIX, there will be more server type enhancements in that driver as I get the time. The em driver now will be client oriented, the latest hardware support however is for 82574, Hartwell, which is a really nice low cost PCIE dual-port adapter, that actually also has MSIX. This first released support for it will use 3 interrupt vectors, one for TX, one for RX, and Link. The hardware actually supports 5 vectors, so I am planning to add support for another RX and TX queue as my schedule allows. Hartwell is also the first adapter that has IEEE 1588 PTP support, the driver provides init and an ioctl interface to use that facility, I hope we see software support follow on soon. This is an early announcement, I am not sure on exact dates for availability but they should be soon. As ever, issues and bugs should be sent to me. Cheers everyone! Jack From owner-freebsd-net@FreeBSD.ORG Sat May 3 08:33:36 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B2721065675; Sat, 3 May 2008 08:33:36 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id DD1598FC0A; Sat, 3 May 2008 08:33:35 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id m438XWLa020703; Sat, 3 May 2008 16:33:32 +0800 (KRAST) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id m438XW76020702; Sat, 3 May 2008 16:33:32 +0800 (KRAST) (envelope-from eugen) Date: Sat, 3 May 2008 16:33:32 +0800 From: Eugene Grosbein To: Jack Vogel Message-ID: <20080503083332.GB2866@svzserv.kemerovo.su> References: <2a41acea0805030014x244e1311v945e23266961193d@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2a41acea0805030014x244e1311v945e23266961193d@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: "freebsd-net@freebsd.org" , FreeBSD Stable List Subject: Re: MFC of em/igb drivers 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, 03 May 2008 08:33:36 -0000 On Sat, May 03, 2008 at 12:14:32AM -0700, Jack Vogel wrote: > I got the new drivers in Friday afternoon for those that don't see CVS > messages. [skip] > As ever, issues and bugs should be sent to me. Cheers everyone! It seems the MFC to RELENG_7 has broken build of static kernels having device em but not having device igb: linking kernel.debug e1000_api.o(.text+0xcc6): In function `e1000_setup_init_funcs': /usr/local/obj/src/sys/dev/em/e1000_api.c:352: undefined reference to `e1000_init_function_pointers_82575' *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 1 error Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Sat May 3 10:17:22 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E45C1065672 for ; Sat, 3 May 2008 10:17:22 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: from mail5out.barnet.com.au (mail5.barnet.com.au [202.83.178.78]) by mx1.freebsd.org (Postfix) with ESMTP id 706A88FC27 for ; Sat, 3 May 2008 10:17:21 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: by mail5out.barnet.com.au (Postfix, from userid 1001) id 8402A2218A78; Sat, 3 May 2008 20:00:44 +1000 (EST) X-Viruscan-Id: <481C37CC0001637998C548@BarNet> Received: from mail5auth.barnet.com.au (mail5.barnet.com.au [202.83.178.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail5auth.barnet.com.au", Issuer "*.barnet.com.au" (verified OK)) by mail5.barnet.com.au (Postfix) with ESMTP id 2B7E821B2BCE for ; Sat, 3 May 2008 20:00:44 +1000 (EST) Received: from k7.mavetju (k7.mavetju.org [10.251.1.18]) by mail5auth.barnet.com.au (Postfix) with ESMTP id B753D2218A69 for ; Sat, 3 May 2008 20:00:43 +1000 (EST) Received: by k7.mavetju (Postfix, from userid 1001) id 64F7B314; Sat, 3 May 2008 20:00:43 +1000 (EST) Date: Sat, 3 May 2008 20:00:43 +1000 From: Edwin Groothuis To: freebsd-net@freebsd.org Message-ID: <20080503100043.GA68835@k7.mavetju> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: IPPROTO_DIVERT and PF_INET6 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, 03 May 2008 10:17:22 -0000 Greetings, Before somebody shoots me down on it: I know that ipfw_divert() is not suitable for IPv6 packets. So, to the point. This code: struct sockaddr_in6 addr6; struct in6_addr ip6_any = IN6ADDR_ANY_INIT; sin = socket(PF_INET6, SOCK_RAW, IPPROTO_DIVERT); if (sin == -1) errx(1, "Unable to create sin socket."); if (sin > fdmax) fdmax = sin; addr6.sin6_family = AF_INET6; addr6.sin6_addr = ip6_any; addr6.sin6_port = htons(8669); if (bind(sin, (struct sockaddr *) &addr6, sizeof(addr6)) == -1) errx(1, "Unable to bind incoming divert socket: %s", strerror(errno)); compiles and run fine, but it gives me this in the lsof output: nat6to4d 67887 root 3u IPv6 0xc8b05000 0t0 HOPOPTS *:* HOPOPTS is "0" according to /etc/protocols. Making everything IPv4, it gives this: nat6to4d 67899 root 3u IPv4 0xc865421c 0t0 DIVERT *:8669 which is what I expected. So why doesn't this get displayed for the IPv6 sockets? Edwin -- Edwin Groothuis | Personal website: http://www.mavetju.org edwin@mavetju.org | Weblog: http://www.mavetju.org/weblog/ From owner-freebsd-net@FreeBSD.ORG Sat May 3 12:05:50 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 394711065671 for ; Sat, 3 May 2008 12:05:50 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay01.kiev.sovam.com (relay01.kiev.sovam.com [62.64.120.200]) by mx1.freebsd.org (Postfix) with ESMTP id DCE778FC17 for ; Sat, 3 May 2008 12:05:49 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=skuns.kiev.zoral.com.ua) by relay01.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JsGBK-0000F7-8Z; Sat, 03 May 2008 14:45:34 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m43BjYFh055861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 May 2008 14:45:34 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m43BjTYA082227; Sat, 3 May 2008 14:45:29 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m43BjTTL082176; Sat, 3 May 2008 14:45:29 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 3 May 2008 14:45:29 +0300 From: Kostik Belousov To: Jack Vogel Message-ID: <20080503114529.GD18958@deviant.kiev.zoral.com.ua> References: <2a41acea0805030014x244e1311v945e23266961193d@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="urFn1nBM6XIasQZE" Content-Disposition: inline In-Reply-To: <2a41acea0805030014x244e1311v945e23266961193d@mail.gmail.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.4 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on skuns.kiev.zoral.com.ua X-Scanner-Signature: 565941832c2f675ae953af64aa3a5396 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 2754 [May 03 2008] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: "freebsd-net@freebsd.org" , FreeBSD Stable List Subject: Re: MFC of em/igb drivers 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, 03 May 2008 12:05:50 -0000 --urFn1nBM6XIasQZE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, May 03, 2008 at 12:14:32AM -0700, Jack Vogel wrote: > I got the new drivers in Friday afternoon for those that don't see CVS > messages. >=20 > The igb driver is for 82575 and 82576 adapters, it has multiqueue support= and > MSIX, there will be more server type enhancements in that driver as I get= the > time. >=20 > The em driver now will be client oriented, the latest hardware support ho= wever > is for 82574, Hartwell, which is a really nice low cost PCIE dual-port ad= apter, > that actually also has MSIX. This first released support for it will > use 3 interrupt > vectors, one for TX, one for RX, and Link. The hardware actually supports= 5 > vectors, so I am planning to add support for another RX and TX queue as my > schedule allows. >=20 > Hartwell is also the first adapter that has IEEE 1588 PTP support, the dr= iver > provides init and an ioctl interface to use that facility, I hope we > see software > support follow on soon. This is an early announcement, I am not sure on > exact dates for availability but they should be soon. >=20 > As ever, issues and bugs should be sent to me. Cheers everyone! Besides the broken tinderbox, you did not connected the igb module to the module build. Is this intentional ? --urFn1nBM6XIasQZE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkgcUFgACgkQC3+MBN1Mb4jRAACeIEvlQRKQywJNoEbpjx4e7riC SvEAn0ByN9L0j40bGn9Vj7AJaCTLVKR5 =qHeU -----END PGP SIGNATURE----- --urFn1nBM6XIasQZE-- From owner-freebsd-net@FreeBSD.ORG Sat May 3 13:52:54 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57FBE1065670 for ; Sat, 3 May 2008 13:52:54 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: from mail5out.barnet.com.au (mail5.barnet.com.au [202.83.178.78]) by mx1.freebsd.org (Postfix) with ESMTP id 238DF8FC16 for ; Sat, 3 May 2008 13:52:54 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: by mail5out.barnet.com.au (Postfix, from userid 1001) id 41BB92218AA0; Sat, 3 May 2008 23:52:53 +1000 (EST) X-Viruscan-Id: <481C6E350001026DFF9A10@BarNet> Received: from mail5auth.barnet.com.au (mail5.barnet.com.au [202.83.178.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail5auth.barnet.com.au", Issuer "*.barnet.com.au" (verified OK)) by mail5.barnet.com.au (Postfix) with ESMTP id EC93F21B23FA for ; Sat, 3 May 2008 23:52:52 +1000 (EST) Received: from k7.mavetju (k7.mavetju.org [10.251.1.18]) by mail5auth.barnet.com.au (Postfix) with ESMTP id A7CD52218A8B for ; Sat, 3 May 2008 23:52:52 +1000 (EST) Received: by k7.mavetju (Postfix, from userid 1001) id 7B605314; Sat, 3 May 2008 23:52:52 +1000 (EST) Date: Sat, 3 May 2008 23:52:52 +1000 From: Edwin Groothuis To: freebsd-net@freebsd.org Message-ID: <20080503135252.GB3159@k7.mavetju> References: <20080503100043.GA68835@k7.mavetju> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080503100043.GA68835@k7.mavetju> User-Agent: Mutt/1.4.2.3i Subject: Re: IPPROTO_DIVERT and PF_INET6 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, 03 May 2008 13:52:54 -0000 On Sat, May 03, 2008 at 08:00:43PM +1000, Edwin Groothuis wrote: > Before somebody shoots me down on it: I know that ipfw_divert() is > not suitable for IPv6 packets. Please note that the above statement is only partly true now: on my laptop ipfw_divert() can handle IPv6 forwards, but the problem described with opening prevents me from doing anything useful with it. Edwin -- Edwin Groothuis | Personal website: http://www.mavetju.org edwin@mavetju.org | Weblog: http://www.mavetju.org/weblog/ From owner-freebsd-net@FreeBSD.ORG Sat May 3 14:50:32 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 385DE1065671 for ; Sat, 3 May 2008 14:50:32 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by mx1.freebsd.org (Postfix) with ESMTP id E6E838FC0C for ; Sat, 3 May 2008 14:50:31 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so133122ywe.13 for ; Sat, 03 May 2008 07:50:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=LvPEoHMU8mN6cIxjhk+dVRciWbLQoYw6VA36Leqz4TI=; b=IWxNd/rigePmY+EgNMnq/xLG1fnT61YWcr9O6AexMCoY0bbbNJXv5T5RqyVP3rnAQboxTsfMleJ7RPVuGXKoGOm6V29RwkBVaBGE7m6LLR38TCz3su9pgqnu3ykpNnvCWUDeWNZIx1bLIbi3fQfP9ywSUNsb+5eOgbPnYqZj5Ys= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ioG+D8pkC3aFyywKGmok3zcVnLq1wBEDXUzCypJd0cY7ThOzX20CF2S3H8hfyGLSClwxWs9h2KnbmV7Ru8HsDr+i5YiwISEtP+hrBiOn0ut59SfSjhsKD+nq1Sm7nl7RQSJU0VMfXwNKrj1+62t5lhjqJtSaDhKz4JHUqA0Rb5g= Received: by 10.150.202.14 with SMTP id z14mr4557665ybf.95.1209826231146; Sat, 03 May 2008 07:50:31 -0700 (PDT) Received: by 10.151.11.1 with HTTP; Sat, 3 May 2008 07:50:31 -0700 (PDT) Message-ID: <3c0b01820805030750k2fc389b0y500914c36069e6cf@mail.gmail.com> Date: Sat, 3 May 2008 10:50:31 -0400 From: "Alexander Sack" To: "David Christensen" In-Reply-To: <5D267A3F22FD854F8F48B3D2B523819324F09D6896@IRVEXCHCCR01.corp.ad.broadcom.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5D267A3F22FD854F8F48B3D2B523819324F09D65FA@IRVEXCHCCR01.corp.ad.broadcom.com> <3c0b01820805021315i482fe0acg3e9238a2f412770e@mail.gmail.com> <5D267A3F22FD854F8F48B3D2B523819324F09D6896@IRVEXCHCCR01.corp.ad.broadcom.com> Cc: "freebsd-net@freebsd.org" Subject: Re: Not All Symbols Present in a Loadable Kernel Module 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, 03 May 2008 14:50:32 -0000 On Fri, May 2, 2008 at 8:06 PM, David Christensen wrote: > > > I'm trying to build the "bce" driver as a kernel module under > > RELENG_7 but I'm > > > finding that not all of the functions in the driver are exported as > > symbols. This > > > makes it difficult to "call" a function from ddb because I get the > > error "Symbol > > > not found". I'm building and loading the driver from > > /usr/src/sys/modules/bce. > > > What am I doing wrong? How can I get all functions in the driver > > exported as > > > symbols usable by the debugger? > > > > Are you building a debug kernel or regular kernel? Have you turned on > > debug symbols? > > > > makeoptions DEBUG=-g # Build kernel with gdb(1) > > debug symbols > > > > Just a quick thought...I'm assuming these symbols are listed under > > your final kernel image (nm it etc.). > > Yes, I'm building a debug kernel. I have the line listed above as well > as the following: > > options KDB > options DDB > options GDB > options INVARIANTS > options INVARIANT_SUPPORT > options WITNESS > options WITNESS_SKIPSPIN Dave: What symbols can you not access exactly and how are you installing/setting up debugging? I just built a RELENG_7 with DDB and I'm able to access bce symbols without a problem. I can examine them and call them. I'm not using options GDB however, only KDB/DDB. I would: - Make sure you have the right if_bce.ko/if_bce.ko.symbols files generated/installed which contains the debug sections of your ko (from the objcopy calls during the build - the binary is stripped with a section pointer to the if_bce.ko.symbols file for debugging information I believe) - If you are using GDB, make sure its pointed to the right source base so it can retrieve symbol information correctly - If you are using GDB, stub it out and just use DDB to verify that your build is sane (it works for me!) - If all else fails, you can always build bce statically (just to move forward etc.) -aps From owner-freebsd-net@FreeBSD.ORG Sat May 3 15:00:14 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 961511065671 for ; Sat, 3 May 2008 15:00:14 +0000 (UTC) (envelope-from petar@morrison.andev.ch) Received: from morrison.andev.ch (morrison.andev.ch [78.47.142.202]) by mx1.freebsd.org (Postfix) with ESMTP id F0EB98FC30 for ; Sat, 3 May 2008 15:00:13 +0000 (UTC) (envelope-from petar@morrison.andev.ch) Received: by morrison.andev.ch (Postfix, from userid 1000) id 2788A5DB70; Sat, 3 May 2008 17:00:56 +0200 (CEST) Date: Sat, 3 May 2008 16:59:06 +0200 From: Petar Bogdanovic To: freebsd-net@freebsd.org Message-ID: <20080503145906.GA3417@pintail.smokva.net> Mail-Followup-To: freebsd-net@freebsd.org References: <20080502093655.GA3535@pintail.smokva.net> <481BB0E5.8000803@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <481BB0E5.8000803@freebsd.org> User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: authentication timeouts with ath(4) in hostap mode 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, 03 May 2008 15:00:14 -0000 On Fri, May 02, 2008 at 05:25:09PM -0700, Sam Leffler wrote: > Petar Bogdanovic wrote: >> Hi, >> >> I'm using an alix2c0 board with two winstron CM9 ath(4)-cards and >> FreeBSD 7: >> >> ifconfig ath0 (...) mediaopt hostap mode 11a channel 36 ssid sn.a -bgscan >> ifconfig ath1 (...) mediaopt hostap mode 11g channel 11 ssid sn.g -bgscan >> >> >> When I try to raise the traffic (i.e. dd | ssh AP dd) my Linux >> wpa_supplicant drops the connection and has to reassociate. This however >> does not work immediately; The supplicant fails a few times before >> reconnecting: >> >> <2>CTRL-EVENT-CONNECTED - Connection to 00:0b:0b:06:0d:09 completed (reauth) [id=0 id_str=] >> <2>CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys >> <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) >> <2>Authentication with 00:0b:0b:06:0d:09 timed out. >> <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) >> <2>Authentication with 00:0b:0b:06:0d:09 timed out. >> <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) >> <2>Authentication with 00:0b:0b:06:0d:09 timed out. >> <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) >> <2>Authentication with 00:0b:0b:06:0d:09 timed out. >> <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) >> <2>Authentication with 00:0b:0b:06:0d:09 timed out. >> <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) >> <2>Authentication with 00:0b:0b:06:0d:09 timed out. >> <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) >> <2>Associated with 00:0b:0b:06:0d:09 >> <2>WPA: Key negotiation completed with 00:0b:0b:06:0d:09 [PTK=CCMP GTK=CCMP] >> <2>CTRL-EVENT-CONNECTED - Connection to 00:0b:0b:06:0d:09 completed (reauth) [id=0 id_str=] >> >> >> This happens more on the 11a than on the 11g network. When I'm next to >> the AP, the timeouts are almost gone but they still happen. (My laptop >> is just one room away from the AP). Here is the athstats-output of ath0 >> (11a): >> >> # ./athstats -i ath0 >> 481546 data frames received >> 330669 data frames transmit >> 13395 tx frames with an alternate rate >> 78558 long on-chip tx retries >> 1431 tx failed 'cuz too many retries >> 36M current transmit rate >> 78 tx management frames >> 3 tx frames discarded prior to association >> 45 tx frames with no ack marked >> 2894 rx failed 'cuz of bad CRC >> 2 rx failed 'cuz decryption >> 92711 rx failed 'cuz of PHY err >> 92708 OFDM timing >> 3 OFDM restart >> 318332 beacons transmitted >> 1111 periodic calibrations >> 2 rfgain value change >> 22 rssi of last ack >> 23 avg recv rssi >> -96 rx noise floor >> 2530 switched default/rx antenna >> Antenna profile: >> [1] tx 173364 rx 123068 >> [2] tx 155874 rx 358671 > > So the obvious question is whether your system config has enough isolation > of the radios for them not to impact each other? Do you mean the isolation between the four (2x11a/2x11g) pigtail cables inside the box? Well, when I take a look at the product sheet: http://pcengines.ch/pigsma.htm it looks that the cables aren't shielded at all. Is this question based on the high PHY error rate? This value is steadily growing on both interfaces -- here are the stats of ath1 (11g): # ./athstats -i ath1 938627 data frames received 1727374 data frames transmit 7883 tx frames with an alternate rate 93209 long on-chip tx retries 2871 tx failed 'cuz too many retries 11M current transmit rate 7127 tx management frames 3 tx frames discarded prior to association 1998 tx frames with no ack marked 1718962 tx frames with short preamble 4363254 rx failed 'cuz of bad CRC 5115659 rx failed 'cuz of PHY err 23579 OFDM timing 5092074 CCK timing 6 CCK restart 713605 beacons transmitted 2460 periodic calibrations 2 rfgain value change 18 rssi of last ack 21 avg recv rssi -96 rx noise floor 102 cabq frames transmitted 26685 switched default/rx antenna Antenna profile: [1] tx 1416324 rx 1017871 [2] tx 308291 rx 2758 I assume this one is related to the high AP-density -- there are about 13-15 11g networks available in our living room. Yesterday I tried the same tests with a freesbie client (FreeBSD 6.2) and a Windows client. The link of the former was totally stable. No disconnects on 11a and transfer rates around 2.7MB/s. 11g was stable and fast (3.3MB/s) too but the ALIX board suddenly rebooted. (this seems to be an other issue) The Windows client was stable and fast (3MB/s) on 11a but slow and lossy due disconnects on 11g. After all I also booted an old Debian based live-cd with an old kernel, old madwifi drivers and wpa_supplicant 4.9. It started to disconnect again (both modes). > Does turning off one radio give you stable operation? I just did a `ifconfig ath1 txpower 0' but no luck. Is there a ifconfig way to completely turn off the radio or do I have to unplug ath1 to be sure? > Have you verified the packets are present in the air? Have you traced > packets and/or phy errors around the time of the problem? How do I do that? > Have you tried different channels? Yes. On 11a it makes no difference (I tried 36 and 64). On 11g I get the best result on channel 11. This makes sense, since a lot of the other networks operate on channel 1 or 6. > you tried different boards? Unfortunately, I only have one ALIX board. But maybe I'll try a generic PC just for the sake of certainty. Sorry for the lack of information in my first mail and thanks for your answer, Petar From owner-freebsd-net@FreeBSD.ORG Sat May 3 15:45:09 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 614D4106567F for ; Sat, 3 May 2008 15:45:09 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 1A5468FC1C for ; Sat, 3 May 2008 15:45:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 6823241C72C; Sat, 3 May 2008 17:45:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id jvi5M-vcqe-D; Sat, 3 May 2008 17:45:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 60C8B41C759; Sat, 3 May 2008 17:45:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 19F3744487F; Sat, 3 May 2008 15:43:24 +0000 (UTC) Date: Sat, 3 May 2008 15:43:24 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Julian Elischer In-Reply-To: <4816D1D2.7010603@elischer.org> Message-ID: <20080503154219.C47338@maildrop.int.zabbadoz.net> References: <4816D1D2.7010603@elischer.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Net Subject: Re: multiple routing tables review patch ready for simple testing. 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, 03 May 2008 15:45:09 -0000 On Tue, 29 Apr 2008, Julian Elischer wrote: Hi, > a kernel needs to be created with the option ROUTETABLES=N > > e.g. > +options ROUTETABLES=2 # max 16. 1 is back > compatible. > > leaving this out will result in just a single routing table as per normal. > > the max is 16 but I have an artificial (even lower) at 8 but that may > be gone by the time people try it :-) After reading through this thread and not looking at the patch again for the moment, where does this limit come from? Do you think this could be extended to more in the future? -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From owner-freebsd-net@FreeBSD.ORG Sat May 3 16:39:57 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1CCF61065671 for ; Sat, 3 May 2008 16:39:57 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.226]) by mx1.freebsd.org (Postfix) with ESMTP id DC2E08FC14 for ; Sat, 3 May 2008 16:39:56 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1354464rvf.43 for ; Sat, 03 May 2008 09:39:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=jM+YOQijUkh035w39hQhoXh9pMxGx9lYzFbc0BfF+A0=; b=xX3o5AJyPym0nOPt0g/iODH8I6mg6V+VmHbc70NmaPC0kgPC3H4jn9fzBVPTYxwOzRIvweT6WZ9XrUQKHUNf23pG1169umjbznt+vvxMk5uJgZamEd5VVISmq3qTyG/4sDY997SRI/lBlQvQc0GonyuU3PiILbEYqyhWtX0+xn8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=wQVtro/RclO5e63EsPQ5gbhws9TuH1B5NCAs0MCkUmtr6cuVMbFP5cAMn2bMnlGpxJRbJRFYmlH2lNeal5fIzULccO8mHTbYR0H2fk+7TogimeZ+MpDB3gefxADoejWdR3UkozZ6y606w806GFJP7DgGYpgkuFodu2DigudG4EQ= Received: by 10.114.169.2 with SMTP id r2mr4073488wae.118.1209832795965; Sat, 03 May 2008 09:39:55 -0700 (PDT) Received: by 10.114.177.4 with HTTP; Sat, 3 May 2008 09:39:55 -0700 (PDT) Message-ID: <2a41acea0805030939ua3022ceq7939aea0754e9e71@mail.gmail.com> Date: Sat, 3 May 2008 09:39:55 -0700 From: "Jack Vogel" To: "Kostik Belousov" In-Reply-To: <20080503114529.GD18958@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2a41acea0805030014x244e1311v945e23266961193d@mail.gmail.com> <20080503114529.GD18958@deviant.kiev.zoral.com.ua> Cc: "freebsd-net@freebsd.org" , FreeBSD Stable List Subject: Re: MFC of em/igb drivers 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, 03 May 2008 16:39:57 -0000 On Sat, May 3, 2008 at 4:45 AM, Kostik Belousov wrote: > On Sat, May 03, 2008 at 12:14:32AM -0700, Jack Vogel wrote: > > > > I got the new drivers in Friday afternoon for those that don't see CVS > > messages. > > > > The igb driver is for 82575 and 82576 adapters, it has multiqueue support and > > MSIX, there will be more server type enhancements in that driver as I get the > > time. > > > > The em driver now will be client oriented, the latest hardware support however > > is for 82574, Hartwell, which is a really nice low cost PCIE dual-port adapter, > > that actually also has MSIX. This first released support for it will > > use 3 interrupt > > vectors, one for TX, one for RX, and Link. The hardware actually supports 5 > > vectors, so I am planning to add support for another RX and TX queue as my > > schedule allows. > > > > Hartwell is also the first adapter that has IEEE 1588 PTP support, the driver > > provides init and an ioctl interface to use that facility, I hope we > > see software > > support follow on soon. This is an early announcement, I am not sure on > > exact dates for availability but they should be soon. > > > > As ever, issues and bugs should be sent to me. Cheers everyone! > > Besides the broken tinderbox, you did not connected the igb module to > the module build. Is this intentional ? > No, not intentional, both issues are now fixed, sorry, was tired yesterday afternoon :) Jack From owner-freebsd-net@FreeBSD.ORG Sat May 3 17:40:05 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EBD3A106567C; Sat, 3 May 2008 17:40:05 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 043838FC28; Sat, 3 May 2008 17:40:04 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id m43HO1Ln019966; Sat, 3 May 2008 11:24:01 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <481C9FB1.4060407@samsco.org> Date: Sat, 03 May 2008 11:24:01 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: Jack Vogel References: <2a41acea0805030014x244e1311v945e23266961193d@mail.gmail.com> <20080503114529.GD18958@deviant.kiev.zoral.com.ua> <2a41acea0805030939ua3022ceq7939aea0754e9e71@mail.gmail.com> In-Reply-To: <2a41acea0805030939ua3022ceq7939aea0754e9e71@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=3.8 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: Kostik Belousov , "freebsd-net@freebsd.org" , FreeBSD Stable List Subject: Re: MFC of em/igb drivers 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, 03 May 2008 17:40:06 -0000 Jack Vogel wrote: > On Sat, May 3, 2008 at 4:45 AM, Kostik Belousov wrote: >> On Sat, May 03, 2008 at 12:14:32AM -0700, Jack Vogel wrote: >> >> >>> I got the new drivers in Friday afternoon for those that don't see CVS >> > messages. >> > >> > The igb driver is for 82575 and 82576 adapters, it has multiqueue support and >> > MSIX, there will be more server type enhancements in that driver as I get the >> > time. >> > >> > The em driver now will be client oriented, the latest hardware support however >> > is for 82574, Hartwell, which is a really nice low cost PCIE dual-port adapter, >> > that actually also has MSIX. This first released support for it will >> > use 3 interrupt >> > vectors, one for TX, one for RX, and Link. The hardware actually supports 5 >> > vectors, so I am planning to add support for another RX and TX queue as my >> > schedule allows. >> > >> > Hartwell is also the first adapter that has IEEE 1588 PTP support, the driver >> > provides init and an ioctl interface to use that facility, I hope we >> > see software >> > support follow on soon. This is an early announcement, I am not sure on >> > exact dates for availability but they should be soon. >> > >> > As ever, issues and bugs should be sent to me. Cheers everyone! >> >> Besides the broken tinderbox, you did not connected the igb module to >> the module build. Is this intentional ? >> > > No, not intentional, both issues are now fixed, sorry, was tired yesterday > afternoon :) > Is it still true that support for the 575 moved from em to igb? If so, please put an entry in src/UPDATING about it and ask the re/docs team to make sure it's documented in the next release notes. Scott From owner-freebsd-net@FreeBSD.ORG Sat May 3 17:43:49 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 199D91065670; Sat, 3 May 2008 17:43:49 +0000 (UTC) (envelope-from tim@gebbettco.com) Received: from outmail136022.authsmtp.co.uk (outmail136022.authsmtp.co.uk [62.13.136.22]) by mx1.freebsd.org (Postfix) with ESMTP id 964158FC16; Sat, 3 May 2008 17:43:48 +0000 (UTC) (envelope-from tim@gebbettco.com) Received: from mail-c188.authsmtp.com (mail-c188.authsmtp.com [62.13.128.25]) by punt3.authsmtp.com (8.13.8/8.13.8/Kp) with ESMTP id m43HSbsJ090891; Sat, 3 May 2008 18:28:37 +0100 (BST) Received: from [10.111.0.10] (host217-34-40-180.in-addr.btopenworld.com [217.34.40.180]) (authenticated bits=0) by mail.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id m43HSaxB073790; Sat, 3 May 2008 18:28:36 +0100 (BST) Message-ID: <481CA0C4.2040001@gebbettco.com> Date: Sat, 03 May 2008 18:28:36 +0100 From: Tim Gebbett User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Andre Oppermann References: <20080420025010.GJ73016@server.vk2pj.dyndns.org> <480BBD7E.8010700@freebsd.org> <480C9AC6.8090802@freebsd.org> <480E7901.5000804@freebsd.org> <481B7232.60608@freebsd.org> In-Reply-To: <481B7232.60608@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Server-Quench: 5d01e6d6-1936-11dd-aecc-001871e930f4 X-AuthRoute: OCdxaQwcClZJTQEy BS4OBiJcVQ4iYBZL BAkGMA9GIUINWEQM c1ACdR12OUxbHwkB C3YKU15WWFdyXi13 ag1PbgFDZkpQXg1q T0pMQFdNFEs1BR95 ZU9WIBl1dAJPeDB1 Z09rEHUPXEUvcxJ7 X09dFmsbZGY0PH1O BRMLagNUcQtNf0pM aVApUD1vNG8XJC8x E09ydyo8IShFLj8d bz0sCH8+Zns3Vjk6 DwseEDwjDAU5bB17 JBsgLFMXAEcWNC05 X-Authentic-SMTP: 61633239343939.cat.dmpriest.net.uk:953/Kp X-Report-SPAM: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-Virus-Status: No virus detected - but ensure you scan with your own anti-virus system! Cc: Peter Jeremy , rwatson@freebsd.org, Mark Hills , freebsd-net@freebsd.org Subject: Re: read() returns ETIMEDOUT on steady TCP connection 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, 03 May 2008 17:43:49 -0000 Hi Andre, Just to introduce myself, I am now helping Mark Hills with testing. Thank you for your suggestion, here are the results from a similar system (RELENG-7) with increasing kern.ipc.nmbjumbop to 25600. at 1600 streams using approx 340mbit, netstat -m was reporting 12550/250/12800/12800 4k (page size) jumbo clusters in use After the read() returns ETIMEDOUT, 3857/10551/14408/25600 4k (page size) jumbo clusters in use sysctl kern.ipc.nmbjumbop=25600 > 51200 After the read() returns ETIMEDOUT, 200/25400/25600/51200 4k (page size) jumbo clusters in use (current/cache/total/max) netstat -m: 4140/26205/30345 mbufs in use (current/cache/total) 256/3482/3738/25600 mbuf clusters in use (current/cache/total/max) 256/3328 mbuf+clusters out of packet secondary zone in use (current/cache) 3882/21718/25600/51200 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 17075K/100387K/117462K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/7/6656 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines Do you think we need to reel out further sysctls and should I apply the patch to see if tcp_output: error 55 is still occuring ? Thanks again, Tim Andre Oppermann wrote: > Mark Hills wrote: >> On Wed, 23 Apr 2008, Andre Oppermann wrote: >> >>> http://people.freebsd.org/~andre/tcp_output-error-log.diff >>> >>> Please apply this patch and enable the sysctl net.inet.tcp.log_debug=1 >>> and report any output. You likely get some (normal) noise from >>> syncache. >>> What we are looking for is reports from tcp_output. >> >> Hi Andre, I've applied the patch and tested. >> >> Aside from syncache noise, I get a constant stream of 'error 55' >> (ENOBUFS?), once the number of connection gets to around 150 at 192kbps. >> >> TCP: [192.168.5.43]:52153 to [192.168.5.40]:8080; tcp_output: error >> 55 while sending >> >> 192.168.5.40 is the IP address of this host, running the server. >> >> I tried to correlate the point of the application receiving ETIMEDOUT >> with these messages, but that is tricky as it seems to be outputting >> a lot of messages, and multiple messages over eachother (see below). >> >> Because of the mention of no buffer space available, I checked the >> values of net.inet.tcp.sendbuf* and recvbuf*, and increased the max >> values with no effect. >> >> When I get time I will modify the kernel to print errors which aren't >> ENOBUFS to see if there are any others. But in the meantime, this >> sounds like a problem to me. Is that correct? >> >> Mark >> >> >> :8080; tcp_output: error 55 while sending >> TCP: [192.168.5.42]:57384T CtPo: >> [[119922..116688..55..4402]]::85048400;1 ttoc p[_1o9u2t.p1u6t8:. >> 5e.r4r0o]r: 8080;5 5t cwp_hoiultep uste:n deirnrgor 55 while sending >> TCP: [192.168.5.42]:57382 to [192.168.5.40]:8080; tcp_output: error >> 55 while sending >> TCP: [192.168.5.42]:57381 to [192.168.5.40]:8080; tcp_output: error >> 55 while sending >> TCP: [192.168.5.42]:57380 to [192.168.5.40]:8080; tcp_output: error >> 55 while sending > > After tracing through the code it seems you are indeed memory limited. > Looking back at the netstat -m output: > > 12550/250/12800/12800 4k (page size) jumbo clusters in use > (current/cache/total/max) > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > > This shows that the supply of 4k jumbo clusters is pretty much exhausted. > The cache may be allocated to different CPUs and the one making the > request > at a given point may be depleted and can't get any from the global pool. > The big question is why the denied counter doesn't report anything. I've > looked at the code paths and don't see any obvious reason why it doesn't > get counted. Maybe Robert can give some insight here. > > Try doubling the amount of 4k page size jumbo mbufs. They are the > primary > workhorse in the kernel right now: > > sysctl kern.ipc.nmbjumbop=25600 > > This should get further. Still more may be necessary depending on > workloads. > From owner-freebsd-net@FreeBSD.ORG Sat May 3 20:39:31 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1B0D106564A for ; Sat, 3 May 2008 20:39:31 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.177]) by mx1.freebsd.org (Postfix) with ESMTP id AFB4C8FC12 for ; Sat, 3 May 2008 20:39:31 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by wa-out-1112.google.com with SMTP id j4so2125651wah.3 for ; Sat, 03 May 2008 13:39:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=m3nethyyEamyCAo59cZcIDVENs4NdLYbsTnMAQc3B6Y=; b=UuSw2TrZGhdAR3aZYsghrkg4Ppe9ZhhUefWyqjqzzrXJbhoZPc2JOFJ4b6bdI+BAI3qHu4AMOUP615oIwsiPtE7f5fJrrRPaHOrQ2oa8mXxKWz42/ieffY1O3dlJr4ZQjyo+kQ3OfAA/juLV8UXISdV+3OePmKAPEFswwsCk60c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=DEFFPraT4IgymGJAamp4/bk4ZoIp0NeeEajtyM/vCkvEup/ZK165lJILF1e7Gb3tFajrWKm+G8BV4HuW9W9SSvCcqd1do7JJfRqAgL5bo2QyAHJhEbHwvkBeCgIgImUtFnr3s8OyOpnAMkMnmQZ11VjIJPHcK6sDSEevJnvo7og= Received: by 10.115.110.6 with SMTP id n6mr4222068wam.92.1209847171241; Sat, 03 May 2008 13:39:31 -0700 (PDT) Received: by 10.114.177.4 with HTTP; Sat, 3 May 2008 13:39:31 -0700 (PDT) Message-ID: <2a41acea0805031339n3ff84f37i3aa815168d14dd94@mail.gmail.com> Date: Sat, 3 May 2008 13:39:31 -0700 From: "Jack Vogel" To: "Scott Long" In-Reply-To: <481C9FB1.4060407@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2a41acea0805030014x244e1311v945e23266961193d@mail.gmail.com> <20080503114529.GD18958@deviant.kiev.zoral.com.ua> <2a41acea0805030939ua3022ceq7939aea0754e9e71@mail.gmail.com> <481C9FB1.4060407@samsco.org> Cc: Kostik Belousov , "freebsd-net@freebsd.org" , FreeBSD Stable List Subject: Re: MFC of em/igb drivers 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, 03 May 2008 20:39:32 -0000 On Sat, May 3, 2008 at 10:24 AM, Scott Long wrote: > > Jack Vogel wrote: > > > On Sat, May 3, 2008 at 4:45 AM, Kostik Belousov > wrote: > > > > > On Sat, May 03, 2008 at 12:14:32AM -0700, Jack Vogel wrote: > > > > > > > > > > > > > I got the new drivers in Friday afternoon for those that don't see CVS > > > > > > > > messages. > > > > > > > > The igb driver is for 82575 and 82576 adapters, it has multiqueue > support and > > > > MSIX, there will be more server type enhancements in that driver as I > get the > > > > time. > > > > > > > > The em driver now will be client oriented, the latest hardware > support however > > > > is for 82574, Hartwell, which is a really nice low cost PCIE > dual-port adapter, > > > > that actually also has MSIX. This first released support for it will > > > > use 3 interrupt > > > > vectors, one for TX, one for RX, and Link. The hardware actually > supports 5 > > > > vectors, so I am planning to add support for another RX and TX queue > as my > > > > schedule allows. > > > > > > > > Hartwell is also the first adapter that has IEEE 1588 PTP support, > the driver > > > > provides init and an ioctl interface to use that facility, I hope we > > > > see software > > > > support follow on soon. This is an early announcement, I am not sure > on > > > > exact dates for availability but they should be soon. > > > > > > > > As ever, issues and bugs should be sent to me. Cheers everyone! > > > > > > Besides the broken tinderbox, you did not connected the igb module to > > > the module build. Is this intentional ? > > > > > > > > > > No, not intentional, both issues are now fixed, sorry, was tired yesterday > > afternoon :) > > > > > > Is it still true that support for the 575 moved from em to igb? If so, > please put an entry in src/UPDATING about it and ask the re/docs team to > make sure it's documented in the next release notes. > > Scott > Ahhh yes, I forgot about that, will do Scott. Jack From owner-freebsd-net@FreeBSD.ORG Sat May 3 22:42:11 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34B67106564A for ; Sat, 3 May 2008 22:42:11 +0000 (UTC) (envelope-from oleksandr.samoylyk@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by mx1.freebsd.org (Postfix) with ESMTP id E82768FC0C for ; Sat, 3 May 2008 22:42:10 +0000 (UTC) (envelope-from oleksandr.samoylyk@gmail.com) Received: by wa-out-1112.google.com with SMTP id j4so2189405wah.3 for ; Sat, 03 May 2008 15:42:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; bh=3NSaT2wSfv+5UBethFu5KevOGm2MPt5mlM0nzUcecow=; b=saPbX9N1eBOL8+B1l7yHOCACMId0aebt2lLe2o54RsQnqBmxjgN+zVUIATY9pabvKBUwdQTqHMwEZalxpyy0KzyAI31DQFsPouxg7t9ZsOjQUcuacyBiQx12NcKZ+HbjCfWfCOcFuz/d13MNmTGUe1q1HWrBNEvBERB5s6cH0y8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=PzjEm4RU8LU49CErcnDTWWfQDlFTLco+47N/cq0mdyaMf3QAC1Sokm5WFe7h0Lq5O3y3iaVVA99VhptDyHatz+EqxZnj62+82K9WRonydasxcawqOMWQt9dvK9Q7t5a1lTZmb8Ek9H9TPUnCxwWFqZt+XPz+K7Z7stzb/TVhCCI= Received: by 10.114.170.1 with SMTP id s1mr4260955wae.133.1209852975490; Sat, 03 May 2008 15:16:15 -0700 (PDT) Received: by 10.115.19.1 with HTTP; Sat, 3 May 2008 15:16:15 -0700 (PDT) Message-ID: <912a71490805031516p3c35f419o62d614fc1649c48d@mail.gmail.com> Date: Sun, 4 May 2008 01:16:15 +0300 From: "Oleksandr Samoylyk" Sender: oleksandr.samoylyk@gmail.com To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: ddf1adf2d3818ef0 Subject: Troubles with em on FreeBSD 7 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, 03 May 2008 22:42:11 -0000 Hi! I'm running a SMP FreeBSD box with mpd5 on it. # uname -a FreeBSD xxx.xxxxxxxxx.xxx 7.0-STABLE FreeBSD 7.0-STABLE #0: Sat May 3 12:40:02 EEST 2008 xxxxx@xxx.xxxxxxxxx.xxx:/usr/obj/usr/src/sys/XXXX amd64 # mpd5 -v Version 5.1 (root@xxx.xxxxxxxxx.xxx 09:53 1-May-2008) Somehow em0 begins to eat all CPU time of one core. # top -S last pid: 55827; load averages: 3.76, 3.42, 3.08 up 0+03:27:38 16:24:20 104 processes: 11 running, 81 sleeping, 12 waiting CPU states: 1.7% user, 0.0% nice, 21.4% system, 3.0% interrupt, 73.9% idle Mem: 71M Active, 89M Inact, 340M Wired, 336K Cache, 214M Buf, 7418M Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 29 root 1 -68 - 0K 16K CPU5 5 196:41 100.00% em0 taskq 11 root 1 171 ki31 0K 16K CPU7 7 175:41 94.09% idle: cpu7 16 root 1 171 ki31 0K 16K CPU2 2 175:45 91.26% idle: cpu2 15 root 1 171 ki31 0K 16K CPU3 3 180:18 89.45% idle: cpu3 14 root 1 171 ki31 0K 16K CPU4 4 177:13 87.89% idle: cpu4 17 root 1 171 ki31 0K 16K CPU1 1 165:27 86.87% idle: cpu1 12 root 1 171 ki31 0K 16K CPU6 6 176:18 83.25% idle: cpu6 18 root 1 171 ki31 0K 16K RUN 0 157:44 80.66% idle: cpu0 611 root 6 58 0 133M 44320K select 0 0:00 66.26% mpd5 21 root 1 -44 - 0K 16K CPU4 4 48:38 21.39% swi1: net 30 root 1 -68 - 0K 16K - 6 21:41 10.25% em1 taskq Everything is OK with outbound interface - em1. Current bandwidth - ~ 80 Mbit/s There are a lot of input errors on em0 (but no on em1): # netstat -w 1 -I em0 input (em0) output packets errs bytes packets errs bytes colls 8012 923 2838565 12504 0 7943345 0 7934 874 2469244 12555 0 7728764 0 7931 976 2712035 12482 0 8006760 0 8015 813 2694716 10669 0 7796656 0 7975 733 2475193 12306 0 8032129 0 7871 825 2548198 12269 0 7789452 0 8072 961 2647014 11924 0 7260788 0 7909 983 2576145 10552 0 7479881 0 ^C And systat -v looks strange with no interrupts on em0: 2 users Load 1.34 1.61 1.62 May 3 14:04 Mem:KB REAL VIRTUAL VN PAGER SWAP PAGER Tot Share Tot Share Free in out in out Act 68152 9452 231584 11936 7786368 count All 108516 10676 4486380 15448 pages Proc: Interrupts r p d s w Csw Trp Sys Int Sof Flt 3981 cow 22705 total 47 46k 10k 268k 6697 23k 10k 3973 zfod atkbd0 1 ozfod ata0 irq14 18.3%Sys 2.3%Intr 1.8%User 0.0%Nice 77.6%Idle %ozfod atapci1 19 | | | | | | | | | | | daefr 2001 cpu0: time =========+> 5699 prcfr 2 em0 irq256 55 dtbuf 12110 totfr 6695 em1 irq257 Namei Name-cache Dir-cache 100000 desvn react 2001 cpu3: time Calls hits % hits % 4217 numvn pdwak 2001 cpu1: time 12005 12004 100 304 frevn pdpgs 2001 cpu2: time 13 intrn 2001 cpu4: time Disks ad4 232692 wire 2001 cpu5: time KB/t 0.00 60640 act 2001 cpu7: time tps 0 28784 inact 2001 cpu6: time MB/s 0.00 336 cache %busy 0 7786032 free 219632 buf Latency grows up to 400 ms: # ping 10.0.0.1 PING 10.0.0.1 (10.0.0.1): 56 data bytes 64 bytes from 10.0.0.1: icmp_seq=0 ttl=64 time=17.619 ms 64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=27.497 ms 64 bytes from 10.0.0.1: icmp_seq=3 ttl=64 time=16.481 ms 64 bytes from 10.0.0.1: icmp_seq=4 ttl=64 time=24.535 ms 64 bytes from 10.0.0.1: icmp_seq=5 ttl=64 time=13.058 ms ^C --- 10.0.0.1 ping statistics --- 6 packets transmitted, 5 packets received, 16.7% packet loss round-trip min/avg/max/stddev = 13.058/19.838/27.497/5.346 ms # top -S last pid: 55827; load averages: 3.76, 3.42, 3.08 up 0+03:27:38 16:24:20 104 processes: 11 running, 81 sleeping, 12 waiting CPU states: 1.7% user, 0.0% nice, 21.4% system, 3.0% interrupt, 73.9% idle Mem: 71M Active, 89M Inact, 340M Wired, 336K Cache, 214M Buf, 7418M Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 29 root 1 -68 - 0K 16K CPU5 5 196:41 100.00% em0 taskq 11 root 1 171 ki31 0K 16K CPU7 7 175:41 94.09% idle: cpu7 16 root 1 171 ki31 0K 16K CPU2 2 175:45 91.26% idle: cpu2 15 root 1 171 ki31 0K 16K CPU3 3 180:18 89.45% idle: cpu3 14 root 1 171 ki31 0K 16K CPU4 4 177:13 87.89% idle: cpu4 17 root 1 171 ki31 0K 16K CPU1 1 165:27 86.87% idle: cpu1 12 root 1 171 ki31 0K 16K CPU6 6 176:18 83.25% idle: cpu6 18 root 1 171 ki31 0K 16K RUN 0 157:44 80.66% idle: cpu0 611 root 6 58 0 133M 44320K select 0 0:00 66.26% mpd5 21 root 1 -44 - 0K 16K CPU4 4 48:38 21.39% swi1: net 30 root 1 -68 - 0K 16K - 6 21:41 10.25% em1 taskq # sysctl dev.em.0 dev.em.0.%desc: Intel(R) PRO/1000 Network Connection Version - 6.7.3 dev.em.0.%driver: em dev.em.0.%location: slot=0 function=0 dev.em.0.%pnpinfo: vendor=0x8086 device=0x1096 subvendor=0x15d9 subdevice=0x0000 class=0x020000 dev.em.0.%parent: pci6 dev.em.0.debug: -1 dev.em.0.stats: -1 dev.em.0.rx_int_delay: 0 dev.em.0.tx_int_delay: 66 dev.em.0.rx_abs_int_delay: 66 dev.em.0.tx_abs_int_delay: 66 dev.em.0.rx_processing_limit: -1 I've tried both: options SCHED_ULE options SCHED_4BSD I've added just the following lines in my kernel config: options IPFIREWALL options IPFIREWALL_DEFAULT_TO_ACCEPT options NETGRAPH options NETGRAPH_PPP options NETGRAPH_PPTPGRE My sysctls: net.inet.ip.forwarding=1 net.inet.ip.fastforwarding=1 net.inet.ip.redirect=0 net.inet.ip.random_id=1 net.inet.ip.ttl=255 net.inet.ip.intr_queue_maxlen=4096 kern.maxfiles=131072 kern.maxfilesperproc=32768 kern.maxprocperuid=32768 kern.ipc.somaxconn=65535 kern.ipc.maxsockets=32768 kern.ipc.maxsockbuf=16777216 net.inet.tcp.rfc1323=1 net.inet.tcp.recvspace=65536 net.inet.tcp.sendspace=32768 net.inet.tcp.sendbuf_max=16777216 net.inet.tcp.recvbuf_max=16777216 net.inet.tcp.sendbuf_auto=1 net.inet.tcp.sendbuf_inc=8192 net.inet.tcp.recvbuf_auto=1 net.inet.tcp.recvbuf_inc=16384 net.inet.tcp.maxtcptw=40960 net.inet.tcp.msl=2500 net.inet.tcp.delayed_ack=0 net.inet.tcp.nolocaltimewait=1 net.inet.udp.checksum=0 net.inet.udp.recvspace=65535 net.inet.udp.maxdgram=57344 net.inet.icmp.icmplim=30 net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 net.local.stream.recvspace=65535 net.local.stream.sendspace=65535 net.isr.direct=1 kern.timecounter.hardware=TSC dev.em.0.rx_processing_limit=-1 If I set net.isr.direct to "0", than sw1: net begins to eat 100% of a core, but without errors: # netstat -w 1 -I em0 input (em0) output packets errs bytes packets errs bytes colls 6953 0 2860537 8703 0 4882814 0 6785 0 2587635 7683 0 4443958 0 7006 0 2576630 8718 0 4924591 0 6887 0 2652461 8272 0 4548049 0 6854 0 2610157 8689 0 5152459 0 6889 0 2586067 8265 0 5010795 0 6878 0 2586746 8255 0 4734959 0 ^C Moreover, with net.isr.direct=0 I can't create a PPTP tunnel. Please, help to solve the problem. Thanks! -- Oleksandr Samoylyk OVS-RIPE From owner-freebsd-net@FreeBSD.ORG Sat May 3 22:51:18 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74BA01065685 for ; Sat, 3 May 2008 22:51:18 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by mx1.freebsd.org (Postfix) with ESMTP id 1187C8FC1D for ; Sat, 3 May 2008 22:51:17 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so191256ywe.13 for ; Sat, 03 May 2008 15:51:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=LiILc45YAXmqNMAqPOGY9kj67BSHcN64hN8+3yUD0Xk=; b=r5OeEGGA22eMDt60UVeCepw8yHk2+DNIZhUPh2zHBlNzAZEpdTNz8Ry87bzQ8nP145PxxB5gU2Nh/Qa025gLV+Jk0PANs/zlOPYOCgq3vKVFXb8PNj953xS874AX4s8Cd1qQ2DJnTonVoeCZgkjzhIoZhyDMbQY4WnSdF9/itRA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WNC/M3rUDc0gTLM8DivdRVhw2s2iemIlcNiqCQiyDLzKcS/TTKtzAqokTDoYoGLyIhblC0wzPr792fEhlYHG+i1yBMeXWKcxq9ydNYD1VjWMAxNzV6bE3z7SqGWKGjdRw9qA+c1e37hmrHOu23Y6YbwakVNST8iNhx/53wCAwgA= Received: by 10.150.50.3 with SMTP id x3mr4834052ybx.29.1209855071555; Sat, 03 May 2008 15:51:11 -0700 (PDT) Received: by 10.151.11.1 with HTTP; Sat, 3 May 2008 15:51:11 -0700 (PDT) Message-ID: <3c0b01820805031551m5444d986y9f51f67264643874@mail.gmail.com> Date: Sat, 3 May 2008 18:51:11 -0400 From: "Alexander Sack" To: "Oleksandr Samoylyk" In-Reply-To: <912a71490805031516p3c35f419o62d614fc1649c48d@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <912a71490805031516p3c35f419o62d614fc1649c48d@mail.gmail.com> Cc: freebsd-net@freebsd.org Subject: Re: Troubles with em on FreeBSD 7 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, 03 May 2008 22:51:18 -0000 Oleksandr: Are you using DEVICE_POLLING by chance? If so, have you tried turning it off (ifconfig use -polling etc.)? Just curious. -aps On Sat, May 3, 2008 at 6:16 PM, Oleksandr Samoylyk wrote: > Hi! > > I'm running a SMP FreeBSD box with mpd5 on it. > > # uname -a > FreeBSD xxx.xxxxxxxxx.xxx 7.0-STABLE FreeBSD 7.0-STABLE #0: Sat May 3 > 12:40:02 EEST 2008 > xxxxx@xxx.xxxxxxxxx.xxx:/usr/obj/usr/src/sys/XXXX amd64 > > # mpd5 -v > Version 5.1 (root@xxx.xxxxxxxxx.xxx 09:53 1-May-2008) > > Somehow em0 begins to eat all CPU time of one core. > > # top -S > last pid: 55827; load averages: 3.76, 3.42, 3.08 > up 0+03:27:38 16:24:20 > 104 processes: 11 running, 81 sleeping, 12 waiting > CPU states: 1.7% user, 0.0% nice, 21.4% system, 3.0% interrupt, 73.9% idle > Mem: 71M Active, 89M Inact, 340M Wired, 336K Cache, 214M Buf, 7418M Free > Swap: 4096M Total, 4096M Free > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 29 root 1 -68 - 0K 16K CPU5 5 196:41 100.00% em0 taskq > 11 root 1 171 ki31 0K 16K CPU7 7 175:41 94.09% idle: cpu7 > 16 root 1 171 ki31 0K 16K CPU2 2 175:45 91.26% idle: cpu2 > 15 root 1 171 ki31 0K 16K CPU3 3 180:18 89.45% idle: cpu3 > 14 root 1 171 ki31 0K 16K CPU4 4 177:13 87.89% idle: cpu4 > 17 root 1 171 ki31 0K 16K CPU1 1 165:27 86.87% idle: cpu1 > 12 root 1 171 ki31 0K 16K CPU6 6 176:18 83.25% idle: cpu6 > 18 root 1 171 ki31 0K 16K RUN 0 157:44 80.66% idle: cpu0 > 611 root 6 58 0 133M 44320K select 0 0:00 66.26% mpd5 > 21 root 1 -44 - 0K 16K CPU4 4 48:38 21.39% swi1: net > 30 root 1 -68 - 0K 16K - 6 21:41 10.25% em1 taskq > > Everything is OK with outbound interface - em1. > > Current bandwidth - ~ 80 Mbit/s > > There are a lot of input errors on em0 (but no on em1): > > # netstat -w 1 -I em0 > input (em0) output > packets errs bytes packets errs bytes colls > 8012 923 2838565 12504 0 7943345 0 > 7934 874 2469244 12555 0 7728764 0 > 7931 976 2712035 12482 0 8006760 0 > 8015 813 2694716 10669 0 7796656 0 > 7975 733 2475193 12306 0 8032129 0 > 7871 825 2548198 12269 0 7789452 0 > 8072 961 2647014 11924 0 7260788 0 > 7909 983 2576145 10552 0 7479881 0 > ^C > > And systat -v looks strange with no interrupts on em0: > > 2 users Load 1.34 1.61 1.62 May 3 14:04 > > Mem:KB REAL VIRTUAL VN PAGER SWAP PAGER > Tot Share Tot Share Free in out in out > Act 68152 9452 231584 11936 7786368 count > All 108516 10676 4486380 15448 pages > Proc: Interrupts > r p d s w Csw Trp Sys Int Sof Flt 3981 cow 22705 total > 47 46k 10k 268k 6697 23k 10k 3973 zfod atkbd0 1 > ozfod ata0 irq14 > 18.3%Sys 2.3%Intr 1.8%User 0.0%Nice 77.6%Idle %ozfod atapci1 19 > | | | | | | | | | | | daefr 2001 cpu0: time > =========+> 5699 prcfr 2 em0 irq256 > 55 dtbuf 12110 totfr 6695 em1 irq257 > Namei Name-cache Dir-cache 100000 desvn react 2001 cpu3: time > Calls hits % hits % 4217 numvn pdwak 2001 cpu1: time > 12005 12004 100 304 frevn pdpgs 2001 cpu2: time > 13 intrn 2001 cpu4: time > Disks ad4 232692 wire 2001 cpu5: time > KB/t 0.00 60640 act 2001 cpu7: time > tps 0 28784 inact 2001 cpu6: time > MB/s 0.00 336 cache > %busy 0 7786032 free > 219632 buf > > Latency grows up to 400 ms: > # ping 10.0.0.1 > PING 10.0.0.1 (10.0.0.1): 56 data bytes > 64 bytes from 10.0.0.1: icmp_seq=0 ttl=64 time=17.619 ms > 64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=27.497 ms > 64 bytes from 10.0.0.1: icmp_seq=3 ttl=64 time=16.481 ms > 64 bytes from 10.0.0.1: icmp_seq=4 ttl=64 time=24.535 ms > 64 bytes from 10.0.0.1: icmp_seq=5 ttl=64 time=13.058 ms > ^C > --- 10.0.0.1 ping statistics --- > 6 packets transmitted, 5 packets received, 16.7% packet loss > round-trip min/avg/max/stddev = 13.058/19.838/27.497/5.346 ms > > # top -S > last pid: 55827; load averages: 3.76, 3.42, 3.08 > up 0+03:27:38 16:24:20 > 104 processes: 11 running, 81 sleeping, 12 waiting > CPU states: 1.7% user, 0.0% nice, 21.4% system, 3.0% interrupt, 73.9% idle > Mem: 71M Active, 89M Inact, 340M Wired, 336K Cache, 214M Buf, 7418M Free > Swap: 4096M Total, 4096M Free > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 29 root 1 -68 - 0K 16K CPU5 5 196:41 100.00% em0 taskq > 11 root 1 171 ki31 0K 16K CPU7 7 175:41 94.09% idle: cpu7 > 16 root 1 171 ki31 0K 16K CPU2 2 175:45 91.26% idle: cpu2 > 15 root 1 171 ki31 0K 16K CPU3 3 180:18 89.45% idle: cpu3 > 14 root 1 171 ki31 0K 16K CPU4 4 177:13 87.89% idle: cpu4 > 17 root 1 171 ki31 0K 16K CPU1 1 165:27 86.87% idle: cpu1 > 12 root 1 171 ki31 0K 16K CPU6 6 176:18 83.25% idle: cpu6 > 18 root 1 171 ki31 0K 16K RUN 0 157:44 80.66% idle: cpu0 > 611 root 6 58 0 133M 44320K select 0 0:00 66.26% mpd5 > 21 root 1 -44 - 0K 16K CPU4 4 48:38 21.39% swi1: net > 30 root 1 -68 - 0K 16K - 6 21:41 10.25% em1 taskq > > # sysctl dev.em.0 > dev.em.0.%desc: Intel(R) PRO/1000 Network Connection Version - 6.7.3 > dev.em.0.%driver: em > dev.em.0.%location: slot=0 function=0 > dev.em.0.%pnpinfo: vendor=0x8086 device=0x1096 subvendor=0x15d9 > subdevice=0x0000 class=0x020000 > dev.em.0.%parent: pci6 > dev.em.0.debug: -1 > dev.em.0.stats: -1 > dev.em.0.rx_int_delay: 0 > dev.em.0.tx_int_delay: 66 > dev.em.0.rx_abs_int_delay: 66 > dev.em.0.tx_abs_int_delay: 66 > dev.em.0.rx_processing_limit: -1 > > I've tried both: > options SCHED_ULE > options SCHED_4BSD > > I've added just the following lines in my kernel config: > > options IPFIREWALL > options IPFIREWALL_DEFAULT_TO_ACCEPT > > options NETGRAPH > options NETGRAPH_PPP > options NETGRAPH_PPTPGRE > > > My sysctls: > net.inet.ip.forwarding=1 > net.inet.ip.fastforwarding=1 > net.inet.ip.redirect=0 > net.inet.ip.random_id=1 > net.inet.ip.ttl=255 > net.inet.ip.intr_queue_maxlen=4096 > > kern.maxfiles=131072 > kern.maxfilesperproc=32768 > kern.maxprocperuid=32768 > > kern.ipc.somaxconn=65535 > kern.ipc.maxsockets=32768 > kern.ipc.maxsockbuf=16777216 > > net.inet.tcp.rfc1323=1 > net.inet.tcp.recvspace=65536 > net.inet.tcp.sendspace=32768 > net.inet.tcp.sendbuf_max=16777216 > net.inet.tcp.recvbuf_max=16777216 > net.inet.tcp.sendbuf_auto=1 > net.inet.tcp.sendbuf_inc=8192 > net.inet.tcp.recvbuf_auto=1 > net.inet.tcp.recvbuf_inc=16384 > net.inet.tcp.maxtcptw=40960 > net.inet.tcp.msl=2500 > net.inet.tcp.delayed_ack=0 > net.inet.tcp.nolocaltimewait=1 > > net.inet.udp.checksum=0 > net.inet.udp.recvspace=65535 > net.inet.udp.maxdgram=57344 > > net.inet.icmp.icmplim=30 > > net.inet.tcp.blackhole=2 > net.inet.udp.blackhole=1 > > net.local.stream.recvspace=65535 > net.local.stream.sendspace=65535 > > net.isr.direct=1 > > kern.timecounter.hardware=TSC > > dev.em.0.rx_processing_limit=-1 > > If I set net.isr.direct to "0", than sw1: net begins to eat 100% of a > core, but without errors: > # netstat -w 1 -I em0 > input (em0) output > packets errs bytes packets errs bytes colls > 6953 0 2860537 8703 0 4882814 0 > 6785 0 2587635 7683 0 4443958 0 > 7006 0 2576630 8718 0 4924591 0 > 6887 0 2652461 8272 0 4548049 0 > 6854 0 2610157 8689 0 5152459 0 > 6889 0 2586067 8265 0 5010795 0 > 6878 0 2586746 8255 0 4734959 0 > ^C > > Moreover, with net.isr.direct=0 I can't create a PPTP tunnel. > > Please, help to solve the problem. Thanks! > > -- > Oleksandr Samoylyk > OVS-RIPE > _______________________________________________ > 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 Sat May 3 23:33:44 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39C7A1065709 for ; Sat, 3 May 2008 23:33:44 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from mail.telesweet.net (news.telesweet.net [194.110.252.16]) by mx1.freebsd.org (Postfix) with ESMTP id 8083D8FC1C for ; Sat, 3 May 2008 23:33:42 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from localhost (localhost [127.0.0.1]) by mail.telesweet.net (Postfix) with ESMTP id 2676D101F2; Sun, 4 May 2008 02:06:50 +0300 (EEST) X-Virus-Scanned: by Telesweet Mail Virus Scanner X-Spam-Flag: NO X-Spam-Score: -1.44 X-Spam-Level: X-Spam-Status: No, score=-1.44 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1.44] Received: from [10.0.0.109] (pigeon-work.telesweet [10.0.0.109]) by mail.telesweet.net (Postfix) with ESMTP id 318CF10118; Sun, 4 May 2008 02:06:49 +0300 (EEST) Message-ID: <481CF009.4050606@samoylyk.sumy.ua> Date: Sun, 04 May 2008 02:06:49 +0300 From: Oleksandr Samoylyk User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: Alexander Sack References: <912a71490805031516p3c35f419o62d614fc1649c48d@mail.gmail.com> <3c0b01820805031551m5444d986y9f51f67264643874@mail.gmail.com> In-Reply-To: <3c0b01820805031551m5444d986y9f51f67264643874@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Troubles with em on FreeBSD 7 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, 03 May 2008 23:33:44 -0000 Alexander Sack wrote: > Oleksandr: > > Are you using DEVICE_POLLING by chance? If so, have you tried turning > it off (ifconfig use -polling etc.)? Just curious. > Surely, no :) # ifconfig em0 em0: flags=8843 metric 0 mtu 1500 options=19b I'm just trying the same configuration on i386. > > On Sat, May 3, 2008 at 6:16 PM, Oleksandr Samoylyk > wrote: >> Hi! >> >> I'm running a SMP FreeBSD box with mpd5 on it. >> >> # uname -a >> FreeBSD xxx.xxxxxxxxx.xxx 7.0-STABLE FreeBSD 7.0-STABLE #0: Sat May 3 >> 12:40:02 EEST 2008 >> xxxxx@xxx.xxxxxxxxx.xxx:/usr/obj/usr/src/sys/XXXX amd64 >> >> # mpd5 -v >> Version 5.1 (root@xxx.xxxxxxxxx.xxx 09:53 1-May-2008) >> >> Somehow em0 begins to eat all CPU time of one core. >> >> # top -S >> last pid: 55827; load averages: 3.76, 3.42, 3.08 >> up 0+03:27:38 16:24:20 >> 104 processes: 11 running, 81 sleeping, 12 waiting >> CPU states: 1.7% user, 0.0% nice, 21.4% system, 3.0% interrupt, 73.9% idle >> Mem: 71M Active, 89M Inact, 340M Wired, 336K Cache, 214M Buf, 7418M Free >> Swap: 4096M Total, 4096M Free >> >> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND >> 29 root 1 -68 - 0K 16K CPU5 5 196:41 100.00% em0 taskq >> 11 root 1 171 ki31 0K 16K CPU7 7 175:41 94.09% idle: cpu7 >> 16 root 1 171 ki31 0K 16K CPU2 2 175:45 91.26% idle: cpu2 >> 15 root 1 171 ki31 0K 16K CPU3 3 180:18 89.45% idle: cpu3 >> 14 root 1 171 ki31 0K 16K CPU4 4 177:13 87.89% idle: cpu4 >> 17 root 1 171 ki31 0K 16K CPU1 1 165:27 86.87% idle: cpu1 >> 12 root 1 171 ki31 0K 16K CPU6 6 176:18 83.25% idle: cpu6 >> 18 root 1 171 ki31 0K 16K RUN 0 157:44 80.66% idle: cpu0 >> 611 root 6 58 0 133M 44320K select 0 0:00 66.26% mpd5 >> 21 root 1 -44 - 0K 16K CPU4 4 48:38 21.39% swi1: net >> 30 root 1 -68 - 0K 16K - 6 21:41 10.25% em1 taskq >> >> Everything is OK with outbound interface - em1. >> >> Current bandwidth - ~ 80 Mbit/s >> >> There are a lot of input errors on em0 (but no on em1): >> >> # netstat -w 1 -I em0 >> input (em0) output >> packets errs bytes packets errs bytes colls >> 8012 923 2838565 12504 0 7943345 0 >> 7934 874 2469244 12555 0 7728764 0 >> 7931 976 2712035 12482 0 8006760 0 >> 8015 813 2694716 10669 0 7796656 0 >> 7975 733 2475193 12306 0 8032129 0 >> 7871 825 2548198 12269 0 7789452 0 >> 8072 961 2647014 11924 0 7260788 0 >> 7909 983 2576145 10552 0 7479881 0 >> ^C >> >> And systat -v looks strange with no interrupts on em0: >> >> 2 users Load 1.34 1.61 1.62 May 3 14:04 >> >> Mem:KB REAL VIRTUAL VN PAGER SWAP PAGER >> Tot Share Tot Share Free in out in out >> Act 68152 9452 231584 11936 7786368 count >> All 108516 10676 4486380 15448 pages >> Proc: Interrupts >> r p d s w Csw Trp Sys Int Sof Flt 3981 cow 22705 total >> 47 46k 10k 268k 6697 23k 10k 3973 zfod atkbd0 1 >> ozfod ata0 irq14 >> 18.3%Sys 2.3%Intr 1.8%User 0.0%Nice 77.6%Idle %ozfod atapci1 19 >> | | | | | | | | | | | daefr 2001 cpu0: time >> =========+> 5699 prcfr 2 em0 irq256 >> 55 dtbuf 12110 totfr 6695 em1 irq257 >> Namei Name-cache Dir-cache 100000 desvn react 2001 cpu3: time >> Calls hits % hits % 4217 numvn pdwak 2001 cpu1: time >> 12005 12004 100 304 frevn pdpgs 2001 cpu2: time >> 13 intrn 2001 cpu4: time >> Disks ad4 232692 wire 2001 cpu5: time >> KB/t 0.00 60640 act 2001 cpu7: time >> tps 0 28784 inact 2001 cpu6: time >> MB/s 0.00 336 cache >> %busy 0 7786032 free >> 219632 buf >> >> Latency grows up to 400 ms: >> # ping 10.0.0.1 >> PING 10.0.0.1 (10.0.0.1): 56 data bytes >> 64 bytes from 10.0.0.1: icmp_seq=0 ttl=64 time=17.619 ms >> 64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=27.497 ms >> 64 bytes from 10.0.0.1: icmp_seq=3 ttl=64 time=16.481 ms >> 64 bytes from 10.0.0.1: icmp_seq=4 ttl=64 time=24.535 ms >> 64 bytes from 10.0.0.1: icmp_seq=5 ttl=64 time=13.058 ms >> ^C >> --- 10.0.0.1 ping statistics --- >> 6 packets transmitted, 5 packets received, 16.7% packet loss >> round-trip min/avg/max/stddev = 13.058/19.838/27.497/5.346 ms >> >> # top -S >> last pid: 55827; load averages: 3.76, 3.42, 3.08 >> up 0+03:27:38 16:24:20 >> 104 processes: 11 running, 81 sleeping, 12 waiting >> CPU states: 1.7% user, 0.0% nice, 21.4% system, 3.0% interrupt, 73.9% idle >> Mem: 71M Active, 89M Inact, 340M Wired, 336K Cache, 214M Buf, 7418M Free >> Swap: 4096M Total, 4096M Free >> >> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND >> 29 root 1 -68 - 0K 16K CPU5 5 196:41 100.00% em0 taskq >> 11 root 1 171 ki31 0K 16K CPU7 7 175:41 94.09% idle: cpu7 >> 16 root 1 171 ki31 0K 16K CPU2 2 175:45 91.26% idle: cpu2 >> 15 root 1 171 ki31 0K 16K CPU3 3 180:18 89.45% idle: cpu3 >> 14 root 1 171 ki31 0K 16K CPU4 4 177:13 87.89% idle: cpu4 >> 17 root 1 171 ki31 0K 16K CPU1 1 165:27 86.87% idle: cpu1 >> 12 root 1 171 ki31 0K 16K CPU6 6 176:18 83.25% idle: cpu6 >> 18 root 1 171 ki31 0K 16K RUN 0 157:44 80.66% idle: cpu0 >> 611 root 6 58 0 133M 44320K select 0 0:00 66.26% mpd5 >> 21 root 1 -44 - 0K 16K CPU4 4 48:38 21.39% swi1: net >> 30 root 1 -68 - 0K 16K - 6 21:41 10.25% em1 taskq >> >> # sysctl dev.em.0 >> dev.em.0.%desc: Intel(R) PRO/1000 Network Connection Version - 6.7.3 >> dev.em.0.%driver: em >> dev.em.0.%location: slot=0 function=0 >> dev.em.0.%pnpinfo: vendor=0x8086 device=0x1096 subvendor=0x15d9 >> subdevice=0x0000 class=0x020000 >> dev.em.0.%parent: pci6 >> dev.em.0.debug: -1 >> dev.em.0.stats: -1 >> dev.em.0.rx_int_delay: 0 >> dev.em.0.tx_int_delay: 66 >> dev.em.0.rx_abs_int_delay: 66 >> dev.em.0.tx_abs_int_delay: 66 >> dev.em.0.rx_processing_limit: -1 >> >> I've tried both: >> options SCHED_ULE >> options SCHED_4BSD >> >> I've added just the following lines in my kernel config: >> >> options IPFIREWALL >> options IPFIREWALL_DEFAULT_TO_ACCEPT >> >> options NETGRAPH >> options NETGRAPH_PPP >> options NETGRAPH_PPTPGRE >> >> >> My sysctls: >> net.inet.ip.forwarding=1 >> net.inet.ip.fastforwarding=1 >> net.inet.ip.redirect=0 >> net.inet.ip.random_id=1 >> net.inet.ip.ttl=255 >> net.inet.ip.intr_queue_maxlen=4096 >> >> kern.maxfiles=131072 >> kern.maxfilesperproc=32768 >> kern.maxprocperuid=32768 >> >> kern.ipc.somaxconn=65535 >> kern.ipc.maxsockets=32768 >> kern.ipc.maxsockbuf=16777216 >> >> net.inet.tcp.rfc1323=1 >> net.inet.tcp.recvspace=65536 >> net.inet.tcp.sendspace=32768 >> net.inet.tcp.sendbuf_max=16777216 >> net.inet.tcp.recvbuf_max=16777216 >> net.inet.tcp.sendbuf_auto=1 >> net.inet.tcp.sendbuf_inc=8192 >> net.inet.tcp.recvbuf_auto=1 >> net.inet.tcp.recvbuf_inc=16384 >> net.inet.tcp.maxtcptw=40960 >> net.inet.tcp.msl=2500 >> net.inet.tcp.delayed_ack=0 >> net.inet.tcp.nolocaltimewait=1 >> >> net.inet.udp.checksum=0 >> net.inet.udp.recvspace=65535 >> net.inet.udp.maxdgram=57344 >> >> net.inet.icmp.icmplim=30 >> >> net.inet.tcp.blackhole=2 >> net.inet.udp.blackhole=1 >> >> net.local.stream.recvspace=65535 >> net.local.stream.sendspace=65535 >> >> net.isr.direct=1 >> >> kern.timecounter.hardware=TSC >> >> dev.em.0.rx_processing_limit=-1 >> >> If I set net.isr.direct to "0", than sw1: net begins to eat 100% of a >> core, but without errors: >> # netstat -w 1 -I em0 >> input (em0) output >> packets errs bytes packets errs bytes colls >> 6953 0 2860537 8703 0 4882814 0 >> 6785 0 2587635 7683 0 4443958 0 >> 7006 0 2576630 8718 0 4924591 0 >> 6887 0 2652461 8272 0 4548049 0 >> 6854 0 2610157 8689 0 5152459 0 >> 6889 0 2586067 8265 0 5010795 0 >> 6878 0 2586746 8255 0 4734959 0 >> ^C >> >> Moreover, with net.isr.direct=0 I can't create a PPTP tunnel. >> >> Please, help to solve the problem. Thanks! >> >> -- >> Oleksandr Samoylyk >> OVS-RIPE >> _______________________________________________ >> 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" >> -- Oleksandr Samoylyk OVS-RIPE