From owner-freebsd-net@FreeBSD.ORG Sun Nov 21 17:12:11 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A4BCF16A4CF for ; Sun, 21 Nov 2004 17:12:11 +0000 (GMT) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7384C43D31 for ; Sun, 21 Nov 2004 17:12:11 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) iALHC9wN074973; Sun, 21 Nov 2004 09:12:10 -0800 (PST) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (h229.neville-neil.com [209.157.133.229] (may be forged)) by mail.meer.net (8.12.10/8.12.10/meer) with ESMTP id iALHC9nH051079; Sun, 21 Nov 2004 09:12:09 -0800 (PST) (envelope-from gnn@neville-neil.com) Date: Sun, 21 Nov 2004 09:12:10 -0800 Message-ID: From: gnn@freebsd.org To: James In-Reply-To: <20041115222310.GA93130@scylla.towardex.com> References: <20041115222310.GA93130@scylla.towardex.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.5 Emacs/21.2 (powerpc-apple-darwin) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: Initial review request for IPv6 Fast Forwarding and IP6STEALTH X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 21 Nov 2004 17:12:11 -0000 At Mon, 15 Nov 2004 17:23:10 -0500, James wrote: > Attached is initial code for ip6_fastforward() that I'm proposing > for FreeBSD 5.x. This code was written for an internally modified > FreeBSD 4.9, however in the next few weeks, I will be porting this > into FreeBSD 5.3 tree and submit a final draft for review back to > freebsd-net here. However in the mean time, if any experienced folks > can feed any suggestions or critics for this code, I will gladily > appreciate your input and make necessary changes for the final > draft. > > We have been testing this code on a core router in occaid.org IPv6 > network for a few days now, and so far we've had zero problems and > so far is running very stable. Hi James, A few comments for you: Issues found: ip6_forward_rt is a global value that is used without locking ASSERTS still include the old name apc_inet6_fastfwd Stats are updated directly but I don't think we lock those yet. Don't define M2MMAX in line, put it outside with a comment. If the mbuf is already freed then how can we safely use m->m_pkthdr.rcvif? at line 223 Improve the indenting in the commented case at line 298. I understand the idea, and it's good, but it's a bit confusing to read. Remove #if code at 553 which is specific to the APC product. Later, George From owner-freebsd-net@FreeBSD.ORG Sun Nov 21 18:11:47 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CB28516A4D7; Sun, 21 Nov 2004 18:11:47 +0000 (GMT) Received: from mx01.bos.ma.towardex.com (mx01.bos.ma.towardex.com [65.124.16.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C81043D5E; Sun, 21 Nov 2004 18:11:47 +0000 (GMT) (envelope-from haesu@mx01.bos.ma.towardex.com) Received: by mx01.bos.ma.towardex.com (TowardEX ESMTP 3.0p11_DAKN, from userid 1001) id 4FAD12F946; Sun, 21 Nov 2004 13:11:46 -0500 (EST) Date: Sun, 21 Nov 2004 13:11:46 -0500 From: James To: gnn@freebsd.org Message-ID: <20041121181146.GA76095@scylla.towardex.com> References: <20041115222310.GA93130@scylla.towardex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i cc: freebsd-net@freebsd.org cc: James Subject: Re: Initial review request for IPv6 Fast Forwarding and IP6STEALTH X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 21 Nov 2004 18:11:47 -0000 On Sun, Nov 21, 2004 at 09:12:10AM -0800, gnn@freebsd.org wrote: > Hi James, > > A few comments for you: Hi George, Thanks for your good comments and catch on the line 223! I'll integreate the fixes soon for the final draft. -J > > Issues found: > ip6_forward_rt is a global value that is used without locking > ASSERTS still include the old name apc_inet6_fastfwd > Stats are updated directly but I don't think we lock those yet. > Don't define M2MMAX in line, put it outside with a comment. > If the mbuf is already freed then how can we safely use m->m_pkthdr.rcvif? at line 223 > Improve the indenting in the commented case at line 298. I understand the idea, and it's good, but it's a bit confusing to read. > Remove #if code at 553 which is specific to the APC product. > > Later, > George -- James Jun TowardEX Technologies, Inc. Technical Lead Boston IPv4/IPv6 Web Hosting, Colocation and james@towardex.com Network design/consulting & configuration services cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net From owner-freebsd-net@FreeBSD.ORG Sun Nov 21 19:27:50 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BCAD916A4CE for ; Sun, 21 Nov 2004 19:27:50 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 158CF43D45 for ; Sun, 21 Nov 2004 19:27:50 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.205] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1CVxNE-00058X-00; Sun, 21 Nov 2004 20:27:48 +0100 Received: from [217.83.13.26] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1CVxND-0005le-00; Sun, 21 Nov 2004 20:27:48 +0100 From: Max Laier To: freebsd-net@freebsd.org Date: Sun, 21 Nov 2004 20:28:07 +0100 User-Agent: KMail/1.7.1 References: <419EBE2E.9080108@telia.com> In-Reply-To: <419EBE2E.9080108@telia.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1338536.3Tir5yaH6v"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200411212028.15015.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 cc: Pawel Worach Subject: Re: SACK (and PF) wierdness X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 21 Nov 2004 19:27:51 -0000 --nextPart1338536.3Tir5yaH6v Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Pawel, On Saturday 20 November 2004 04:46, Pawel Worach wrote: > I bumped into a wierd problem with SACK. > > Basically my setup is. > 192.168.1.10 .-crossover 192.168.1.200 > ftp server fxp0<->wireless ap<-> ~~~ <->laptop wireless ath0 > > I run ftp from the laptop to the server. > This is what happens: > ftp> get zero > local: zero remote: zero > 200 EPRT command successful. > 150 Opening BINARY mode data connection for 'zero'. > 476 KB 299.53 KB/s > 426 Data connection: Operation not permitted. > 487424 bytes received in 00:01 (299.49 KB/s) > > I started to look at tcpdump while this was happening and quickly > noticed that the connection got dropped by PF when SACK kicked in. > > pf: BAD state: TCP 192.168.1.10:20 192.168.1.10:20 192.168.1.200:50640=20 > [lo=3D3604799807 high=3D3604800103 win=3D33304 modulator=3D0 wscale=3D1]= =20 > [lo=3D4089843176 high=3D4089909784 win=3D33304 modulator=3D0 wscale=3D1] > 4:4 FPA seq=3D3604799807 ack=3D4089843176 len=3D296 ackskew=3D0 pkts=3D24= 97:1693=20 > dir=3Dout ,fwd =20 > pf: State failure on: 1 | This is an "off by one" due to the FIN flag - I suppose. 3604799807 + 296 i= s=20 3604800103, but the +1 from the FIN flag brings that out of window and caus= es=20 PF to drop the packet. > Nov 20 04:27:40 darkstar kernel: pf: BAD state: TCP=20 > 192.168.1.10:20 192.168.1.10:20 192.168.1.200:58378 [lo=3D1373010668 > high=3D1373010980 win=3D33304 mod ulator=3D0 wscale=3D1] [lo=3D3742879382 > high=3D3742945990 win=3D33304 modulator=3D0 wscale=3D1 ] 4:4 A seq=3D1373= 010668 > ack=3D3742879382 len=3D1448 ackskew=3D0 pkts=3D1266:851 dir=3Dout,f wd > Nov 20 04:27:40 darkstar kernel: pf: State failure on: 1 = =20 > | Nov 20 04:27:40 darkstar kernel: pf: BAD state: TCP > 192.168.1.10:20 192.168.1.10:20 192.168.1.200:58378 [lo=3D1373010668 > high=3D1373010980 win=3D33304 mod ulator=3D0 wscale=3D1] [lo=3D3742879382 > high=3D3742945990 win=3D33304 modulator=3D0 wscale=3D1 ] 4:4 A seq=3D1373= 010668 > ack=3D3742879382 len=3D1448 ackskew=3D0 pkts=3D1266:851 dir=3Dout,f wd These two make no sense at all (at least to me). seq + len is over the wind= ow=20 by 1136 and I don't have the slightest clue why that would be the case. I a= m=20 also a bit surprised that the two (three) state failures are so close=20 together (04:27:35 and 04:27:40). Really strange. > If I disable sack on the ftp server everything works fine. > > I can reproduce this problem 100%, I have never managed to transfer more > than 3Mb via ftp when SACK is on, with it off I see no problems, 11Mbit > wireless at ~650Kb/s > > Attached are three tcpdumps of the ftp data channel after a 'get > /dev/zero'. (I picked out the smallest ones, dropped after about 400kb of > zeros) They didn't make it to the Mailinglist - I am afraid. Can you upload it=20 somewhere or try to resend it via private mail? I'd be very interested. > related pf.conf rules, on ftp server: > pass out log quick on fxp0 inet proto tcp from fxp0 to any flags S/SA keep > state queue (bulk, fast) > and on client: > pass in log quick inet proto tcp from any port 20 to port >=3D > 1024 flags S/SA keep state > > Any ideas? More info? Not yet. But the "off by one" that triggered the first failure should be=20 tracked. I am not a TCP-expert myself, so I hope somebody can jump in here.= =20 Thanks. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1338536.3Tir5yaH6v Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBoOxOXyyEoT62BG0RAsltAJ9ts0OyMi4FUKA2CEWJ3gCDKN6/DwCeOW1U TRjo5wJBYaJu5wmDPQyHbN4= =zs43 -----END PGP SIGNATURE----- --nextPart1338536.3Tir5yaH6v-- From owner-freebsd-net@FreeBSD.ORG Sun Nov 21 19:58:22 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A5BC16A4CE for ; Sun, 21 Nov 2004 19:58:22 +0000 (GMT) Received: from av1-1-sn3.vrr.skanova.net (av1-1-sn3.vrr.skanova.net [81.228.9.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA87243D31 for ; Sun, 21 Nov 2004 19:58:20 +0000 (GMT) (envelope-from pawel.worach@telia.com) Received: by av1-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 4FDA238153; Sun, 21 Nov 2004 20:58:20 +0100 (CET) Received: from smtp1-1-sn3.vrr.skanova.net (smtp1-1-sn3.vrr.skanova.net [81.228.9.177]) by av1-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 337D73813C; Sun, 21 Nov 2004 20:58:20 +0100 (CET) Received: from [192.168.1.1] (h65n2fls35o895.telia.com [217.211.109.65]) by smtp1-1-sn3.vrr.skanova.net (Postfix) with ESMTP id E8E9538016; Sun, 21 Nov 2004 20:58:16 +0100 (CET) Message-ID: <41A0F1EF.7020804@telia.com> Date: Sun, 21 Nov 2004 20:52:15 +0100 From: Pawel Worach User-Agent: Mozilla Thunderbird 0.9 (X11/20041110) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Max Laier References: <419EBE2E.9080108@telia.com> <200411212028.15015.max@love2party.net> In-Reply-To: <200411212028.15015.max@love2party.net> Content-Type: multipart/mixed; boundary="------------000304040804060007060701" X-Content-Filtered-By: Mailman/MimeDel 2.1.1 cc: freebsd-net@freebsd.org Subject: Re: SACK (and PF) wierdness X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 21 Nov 2004 19:58:22 -0000 This is a multi-part message in MIME format. --------------000304040804060007060701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Max, Max Laier wrote: > > These two make no sense at all (at least to me). seq + len is over the window > by 1136 and I don't have the slightest clue why that would be the case. I am > also a bit surprised that the two (three) state failures are so close > together (04:27:35 and 04:27:40). Really strange. I just did a new test, a little bit more synchronized this time. Two new attachments. x-server.log - pf said this during the x run x.pcap - pcap taken on the client side during x run I got no state errors on the client. Both server and client run 6-CURRENT from yesterday. > > They didn't make it to the Mailinglist - I am afraid. Can you upload it > somewhere or try to resend it via private mail? I'd be very interested. At least you should have them now, sorry but I got nowhere to host them. -- Pawel --------------000304040804060007060701 Content-Type: text/plain; name="1-server.log" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="1-server.log" Nov 21 20:41:50 darkstar kernel: pf: BAD state: TCP 192.168.1.10:20 192.168.1.10:20 192.168.1.200:64383 [lo=133627114 high=133627802 win=33304 modulator=0 wscale=1] [lo=2384214636 high=2384281244 win=33304 modulator=0 wscale=1] 4:4 A seq=133627114 ack=2384214636 len=1448 ackskew=0 pkts=209:126 dir=out,fwd Nov 21 20:41:50 darkstar kernel: pf: State failure on: 1 | --------------000304040804060007060701 Content-Type: text/plain; name="2-server.log" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="2-server.log" Nov 21 20:46:15 darkstar kernel: pf: BAD state: TCP 192.168.1.10:20 192.168.1.10:20 192.168.1.200:61852 [lo=1505768606 high=1505769294 win=33304 modulator=0 wscale=1] [lo=3440585642 high=3440652250 win=33304 modulator=0 wscale=1] 4:4 A seq=1505768606 ack=3440585642 len=1448 ackskew=0 pkts=211:122 dir=out,fwd Nov 21 20:46:15 darkstar kernel: pf: State failure on: 1 | --------------000304040804060007060701-- From owner-freebsd-net@FreeBSD.ORG Mon Nov 22 01:41:02 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2445216A4CE for ; Mon, 22 Nov 2004 01:41:02 +0000 (GMT) Received: from microeletronica.com.br (mail.microeletronica.com.br [200.205.240.228]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F95E43D46 for ; Mon, 22 Nov 2004 01:41:00 +0000 (GMT) (envelope-from luiz@microeletronica.com.br) Received: (qmail 64552 invoked by uid 89); 22 Nov 2004 01:41:17 -0000 X-Qmail-Util: Version 0.3.3 X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=0.15.7 Received: from unknown (HELO luizsouza) (luiz@microeletronica.com.br@192.168.0.240) by microeletronica.com.br with RC4-MD5 encrypted SMTP; 22 Nov 2004 01:41:15 -0000 Message-ID: <00a101c4d03c$e3d9e660$f000a8c0@ad.adseguros.com.br> From: =?iso-8859-1?Q?Luiz_Ot=E1vio_Souza?= To: Date: Sun, 21 Nov 2004 23:42:20 -0300 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_009E_01C4D023.BE35B4C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Subject: X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 22 Nov 2004 01:41:02 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_009E_01C4D023.BE35B4C0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 8bit Hi, I've write this patch (before pf port, but still on use) for libalias/natd that permit a second alias address (-b or balance_address on natd) and use probability for second address (-r or balance_prob on natd). The -r option works with percent, from 0 to 100. With 0 the second alias address is disabled, with 100 the first alias address (-a) is disabled. With this, i can do load balance with two different links and compensate the difference. This patch work for me and i think that can work for others. Thanks for understanding my really bad english, ______________________ Luiz Otávio Souza luiz@microeletronica.com.br 14.8111.5025 ------=_NextPart_000_009E_01C4D023.BE35B4C0 Content-Type: application/octet-stream; name="patch.load.balance" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="patch.load.balance" --- lib/libalias/alias.h.ori Fri Nov 23 11:10:15 2001=0A= +++ lib/libalias/alias.h Mon Feb 3 22:51:59 2003=0A= @@ -44,6 +44,8 @@=0A= /* Initialization and control functions. */=0A= void PacketAliasInit(void);=0A= void PacketAliasSetAddress(struct in_addr _addr);=0A= +void PacketAliasSetBAddress(struct in_addr _addr);=0A= +void PacketAliasSetBProb(double p);=0A= void PacketAliasSetFWBase(unsigned int _base, unsigned int _num);=0A= unsigned int=0A= PacketAliasSetMode(unsigned int _flags, unsigned int _mask);=0A= @@ -169,6 +171,12 @@=0A= * PacketAliasOut() are reversed.=0A= */=0A= #define PKT_ALIAS_REVERSE 0x80=0A= +=0A= +/*=0A= + * If PKT_ALIAS_LOAD_BALANCE is set, so we work a little bit different=0A= + * XXX=0A= + */=0A= +#define PKT_ALIAS_LOAD_BALANCE 0x200=0A= =0A= /* Function return codes. */=0A= #define PKT_ALIAS_ERROR -1=0A= =0A= --- lib/libalias/alias_db.c.ori Wed Jul 24 00:21:24 2002=0A= +++ lib/libalias/alias_db.c Mon Feb 3 23:10:13 2003=0A= @@ -175,6 +175,7 @@=0A= /* Sizes of input and output link tables */=0A= #define LINK_TABLE_OUT_SIZE 101=0A= #define LINK_TABLE_IN_SIZE 4001=0A= +#define LINK_TABLE_BAL_SIZE 101=0A= =0A= /* Parameters used for cleanup of expired links */=0A= #define ALIAS_CLEANUP_INTERVAL_SECS 60=0A= @@ -320,6 +321,7 @@=0A= =0A= LIST_ENTRY(alias_link) list_out; /* Linked list of pointers for = */=0A= LIST_ENTRY(alias_link) list_in; /* input and output lookup tables = */=0A= + LIST_ENTRY(alias_link) list_bal;=0A= =0A= union /* Auxiliary data = */=0A= {=0A= @@ -346,6 +348,11 @@=0A= static struct in_addr aliasAddress; /* Address written onto source = */=0A= /* field of IP packet. = */=0A= =0A= +static struct in_addr baliasAddress; /* Balance Address used for load */=0A= + /* balancing - XXX */=0A= +=0A= +static double bprob; /* Balance probability */=0A= +=0A= static struct in_addr targetAddress; /* IP address incoming packets = */=0A= /* are sent to if no aliasing = */=0A= /* link already exists = */=0A= @@ -358,6 +365,8 @@=0A= static LIST_HEAD(, alias_link) /* link record is doubly indexed = */=0A= linkTableIn[LINK_TABLE_IN_SIZE]; /* into input and output lookup = */=0A= /* tables. = */=0A= +static LIST_HEAD(, alias_link)=0A= +linkTableBal[LINK_TABLE_BAL_SIZE];=0A= =0A= static int icmpLinkCount; /* Link statistics = */=0A= static int udpLinkCount;=0A= @@ -423,6 +432,8 @@=0A= static u_int StartPointOut(struct in_addr, struct in_addr,=0A= u_short, u_short, int);=0A= =0A= +static u_int StartPointBal(struct in_addr, struct in_addr);=0A= +=0A= static int SeqDiff(u_long, u_long);=0A= =0A= static void ShowAliasStats(void);=0A= @@ -470,6 +481,15 @@=0A= return(n % LINK_TABLE_OUT_SIZE);=0A= }=0A= =0A= +static u_int=0A= +StartPointBal(struct in_addr src_addr, struct in_addr dst_addr)=0A= +{=0A= + u_int n;=0A= + n =3D src_addr.s_addr;=0A= + n +=3D dst_addr.s_addr;=0A= +=0A= + return(n % LINK_TABLE_BAL_SIZE);=0A= +}=0A= =0A= static int=0A= SeqDiff(u_long x, u_long y)=0A= @@ -563,6 +583,9 @@=0A= FindLinkOut(struct in_addr, struct in_addr, u_short, u_short, int, int);=0A= =0A= static struct alias_link *=0A= +FindLinkOut2(struct in_addr, struct in_addr);=0A= +=0A= +static struct alias_link *=0A= FindLinkIn(struct in_addr, struct in_addr, u_short, u_short, int, int);=0A= =0A= =0A= @@ -940,6 +963,10 @@=0A= /* Adjust input table pointers */=0A= LIST_REMOVE(link, list_in);=0A= =0A= +/* Adjust balance table pointers */=0A= + if (packetAliasMode & PKT_ALIAS_LOAD_BALANCE)=0A= + LIST_REMOVE(link, list_bal);=0A= +=0A= /* Close socket, if one has been allocated */=0A= if (link->sockfd !=3D -1)=0A= {=0A= @@ -1120,6 +1147,13 @@=0A= /* Set up pointers for input lookup table */=0A= start_point =3D StartPointIn(alias_addr, link->alias_port, = link_type);=0A= LIST_INSERT_HEAD(&linkTableIn[start_point], link, list_in);=0A= +=0A= + /* Set up pointers for balance lookup table */=0A= + if (packetAliasMode & PKT_ALIAS_LOAD_BALANCE)=0A= + {=0A= + start_point =3D StartPointBal(src_addr, dst_addr);=0A= + LIST_INSERT_HEAD(&linkTableBal[start_point], link, = list_bal);=0A= + }=0A= }=0A= else=0A= {=0A= @@ -1248,6 +1282,27 @@=0A= return(link);=0A= }=0A= =0A= +static struct alias_link *=0A= +FindLinkOut2(struct in_addr src_addr,=0A= + struct in_addr dst_addr)=0A= +{=0A= + u_int i;=0A= + struct alias_link *link;=0A= + i =3D StartPointBal(src_addr, dst_addr);=0A= +=0A= + LIST_FOREACH(link, &linkTableBal[i], list_bal)=0A= + {=0A= + if (link->src_addr.s_addr =3D=3D src_addr.s_addr=0A= + && link->server =3D=3D NULL=0A= + && link->dst_addr.s_addr =3D=3D dst_addr.s_addr)=0A= + {=0A= + link->timestamp =3D timeStamp;=0A= + break;=0A= + }=0A= + }=0A= +=0A= + return(link);=0A= +}=0A= =0A= static struct alias_link *=0A= _FindLinkIn(struct in_addr dst_addr,=0A= @@ -1628,7 +1681,7 @@=0A= int create)=0A= {=0A= int link_type;=0A= - struct alias_link *link;=0A= + struct alias_link *link, *linkb;=0A= =0A= switch (proto)=0A= {=0A= @@ -1650,6 +1703,23 @@=0A= struct in_addr alias_addr;=0A= =0A= alias_addr =3D FindAliasAddress(src_addr);=0A= +=0A= + /* load balance hack - XXX */=0A= + if (packetAliasMode & PKT_ALIAS_LOAD_BALANCE)=0A= + {=0A= + linkb =3D FindLinkOut2(src_addr, dst_addr);=0A= + if (linkb =3D=3D NULL)=0A= + {=0A= + if (alias_addr.s_addr =3D=3D aliasAddress.s_addr)=0A= + {=0A= + if (random() < (long)(bprob * 0x7fffffff))=0A= + alias_addr =3D baliasAddress;=0A= + }=0A= + } else=0A= + if (linkb->alias_addr.s_addr !=3D alias_addr.s_addr)=0A= + alias_addr =3D linkb->alias_addr;=0A= + }=0A= +=0A= link =3D AddLink(src_addr, dst_addr, alias_addr,=0A= src_port, dst_port, GET_ALIAS_PORT,=0A= link_type);=0A= @@ -2518,6 +2588,25 @@=0A= aliasAddress =3D addr;=0A= }=0A= =0A= +=0A= +/* Set Balance Alias Address for load balancing - XXX */=0A= +void=0A= +PacketAliasSetBAddress(struct in_addr addr)=0A= +{=0A= + baliasAddress =3D addr;=0A= + if (! (packetAliasMode & PKT_ALIAS_LOAD_BALANCE))=0A= + packetAliasMode |=3D PKT_ALIAS_LOAD_BALANCE;=0A= +}=0A= +=0A= +/* Set Balance probability */=0A= +void=0A= +PacketAliasSetBProb(double p)=0A= +{=0A= + if (p > 0 && p <=3D 1)=0A= + bprob =3D p;=0A= + else=0A= + bprob =3D 0;=0A= +}=0A= =0A= void=0A= PacketAliasSetTarget(struct in_addr target_addr)=0A= =0A= --- sbin/natd/natd.c.ori Fri Feb 1 07:18:32 2002=0A= +++ sbin/natd/natd.c Mon Feb 3 23:06:27 2003=0A= @@ -113,6 +113,8 @@=0A= static u_short outPort;=0A= static u_short inOutPort;=0A= static struct in_addr aliasAddr;=0A= +static struct in_addr baliasAddr;=0A= +static double bprob;=0A= static int dynamicMode;=0A= static int ifMTU;=0A= static int aliasOverhead;=0A= @@ -150,6 +152,8 @@=0A= running =3D 1;=0A= assignAliasAddr =3D 0;=0A= aliasAddr.s_addr =3D INADDR_NONE;=0A= + baliasAddr.s_addr =3D INADDR_NONE;=0A= + bprob =3D 0;=0A= aliasOverhead =3D 12;=0A= dynamicMode =3D 0;=0A= logDropped =3D 0;=0A= @@ -176,6 +180,16 @@=0A= if (aliasAddr.s_addr !=3D INADDR_NONE && ifName !=3D NULL)=0A= errx (1, "both alias address and interface "=0A= "name are not allowed");=0A= +=0A= +/*=0A= + * Check if load balance probability is Ok=0A= + */=0A= + if (baliasAddr.s_addr !=3D INADDR_NONE)=0A= + {=0A= + if (bprob < 0 || bprob > 100)=0A= + errx (1, "balance probability valid value is 0..100");=0A= + }=0A= +=0A= /*=0A= * Check that valid port number is known.=0A= */=0A= @@ -298,6 +312,17 @@=0A= */=0A= if (aliasAddr.s_addr !=3D INADDR_NONE)=0A= PacketAliasSetAddress (aliasAddr);=0A= +=0A= +/*=0A= + * Set balancing address if it has been set=0A= + */=0A= + if (baliasAddr.s_addr !=3D INADDR_NONE)=0A= + {=0A= + PacketAliasSetBAddress (baliasAddr);=0A= + if (bprob !=3D 0)=0A= + PacketAliasSetBProb (bprob / 100);=0A= + }=0A= +=0A= /*=0A= * We need largest descriptor number for select.=0A= */=0A= @@ -822,6 +847,8 @@=0A= OutPort,=0A= Port,=0A= AliasAddress,=0A= + BAliasAddress,=0A= + BProb,=0A= TargetAddress,=0A= InterfaceName,=0A= RedirectPort,=0A= @@ -971,6 +998,22 @@=0A= "alias_address",=0A= "a" },=0A= =0A= + { BAliasAddress,=0A= + 0,=0A= + Address,=0A= + "x.x.x.x",=0A= + "address to use for load balance",=0A= + "balance_adddress",=0A= + "b" },=0A= +=0A= + { BProb,=0A= + 0,=0A= + Numeric,=0A= + "n",=0A= + "balance probability in percent",=0A= + "balance_prob",=0A= + "r" },=0A= +=0A= { TargetAddress,=0A= 0,=0A= Address,=0A= @@ -1183,6 +1226,14 @@=0A= =0A= case AliasAddress:=0A= memcpy (&aliasAddr, &addrValue, sizeof (struct in_addr));=0A= + break;=0A= +=0A= + case BAliasAddress:=0A= + memcpy (&baliasAddr, &addrValue, sizeof (struct in_addr));=0A= + break;=0A= +=0A= + case BProb:=0A= + bprob =3D (double) numValue;=0A= break;=0A= =0A= case TargetAddress:=0A= ------=_NextPart_000_009E_01C4D023.BE35B4C0-- From owner-freebsd-net@FreeBSD.ORG Mon Nov 22 11:01:59 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D05C916A4F2 for ; Mon, 22 Nov 2004 11:01:59 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id C65A443D45 for ; Mon, 22 Nov 2004 11:01:59 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id iAMB1xUK075962 for ; Mon, 22 Nov 2004 11:01:59 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id iAMB1x6M075957 for freebsd-net@freebsd.org; Mon, 22 Nov 2004 11:01:59 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 22 Nov 2004 11:01:59 GMT Message-Id: <200411221101.iAMB1x6M075957@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 22 Nov 2004 11:01:59 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2002/07/26] kern/41007 net overfull traffic on third and fourth adap o [2003/10/14] kern/57985 net [patch] Missing splx in ether_output_fram 2 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2001/02/08] kern/24959 net proper TCP_NOPUSH/TCP_CORK compatibility o [2003/07/11] kern/54383 net [nfs] [patch] NFS root configurations wit o [2004/10/11] kern/72502 net [patch] TCP should honour incoming RSTs e 3 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Nov 22 13:18:55 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B9A4816A4CE for ; Mon, 22 Nov 2004 13:18:55 +0000 (GMT) Received: from insomnia.benzedrine.cx (insomnia.benzedrine.cx [62.65.145.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id A567243D5F for ; Mon, 22 Nov 2004 13:18:54 +0000 (GMT) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (dhartmei@localhost [127.0.0.1]) iAMDIr5x032491 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Mon, 22 Nov 2004 14:18:53 +0100 (MET) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.13.1/8.12.10/Submit) id iAMDIqD4001279; Mon, 22 Nov 2004 14:18:52 +0100 (MET) Date: Mon, 22 Nov 2004 14:18:52 +0100 From: Daniel Hartmeier To: Pawel Worach Message-ID: <20041122131851.GA14128@insomnia.benzedrine.cx> References: <419EBE2E.9080108@telia.com> <200411212028.15015.max@love2party.net> <41A0F1EF.7020804@telia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41A0F1EF.7020804@telia.com> User-Agent: Mutt/1.4.1i cc: Max Laier cc: freebsd-net@freebsd.org Subject: Re: SACK (and PF) wierdness X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 22 Nov 2004 13:18:55 -0000 Pawel, could you provide a tcpdump -nvvvSXpi for an entire connection, from handshake to the point where it stalls? Please include the corresponding 'BAD state'/'State failure' messages and output of pfctl -vvss related to the connection (ideally all for the same connection, so timestamps are comparable). If the output is too long to post here, put it on a web server and post the URL, or mail the dump to Max and me privately. It does look like one peer is violating the other's window by sending too much data before acknowledgement. The state has picked up on the window scaling, so we need to see the entire TCP connection to determine whether the packet is dropped correctly or not. Daniel From owner-freebsd-net@FreeBSD.ORG Mon Nov 22 13:30:36 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 78DCB16A4CE for ; Mon, 22 Nov 2004 13:30:36 +0000 (GMT) Received: from kraid.nerim.net (smtp-101-monday.nerim.net [62.4.16.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E94B43D5D for ; Mon, 22 Nov 2004 13:30:35 +0000 (GMT) (envelope-from e-masson@kisoft-services.com) Received: from srvbsdnanssv.interne.kisoft-services.com (kisoftacces2.net1.nerim.net [62.212.107.52]) by kraid.nerim.net (Postfix) with ESMTP id C2C7941EDE for ; Mon, 22 Nov 2004 14:30:33 +0100 (CET) Received: from localhost (localhost [127.0.0.1])D68FCD7CC for ; Mon, 22 Nov 2004 14:30:33 +0100 (CET) Received: from srvbsdnanssv.interne.kisoft-services.com ([127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20979-08 for ; Mon, 22 Nov 2004 14:30:29 +0100 (CET) Received: by srvbsdnanssv.interne.kisoft-services.com (Postfix, from userid 1001) id 1208FD7CA; Mon, 22 Nov 2004 14:30:29 +0100 (CET) To: Mailing List FreeBSD Network From: Eric Masson X-Operating-System: FreeBSD 5.3-STABLE i386 Date: Mon, 22 Nov 2004 14:30:28 +0100 Message-ID: <867joeau4r.fsf@srvbsdnanssv.interne.kisoft-services.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at interne.kisoft-services.com Subject: gif4) & AltQ X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 22 Nov 2004 13:30:36 -0000 Hello, In a vpn application, I'm using gif tunnels backed by ipsec transport mode beetween two hosts on the Internet. Is there any hope to see gif(4) modified to integrate AltQ framework or is there any reason (except lack of maintainer/coder time) that would be a showstopper ? TIA Regards Eric Masson -- «Je suis en train de peaufiner les definitions de locales pour le vietnamien; est-ce que pour l'ordre alphabetique les lettres A(, A^, DD, E^, O^, O+ et U+ sont bien considerées comme des lettres à part ?» Pablo in Guide du linuxien pervers : "Les locales ? C'est simple !" From owner-freebsd-net@FreeBSD.ORG Mon Nov 22 14:05:19 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CB58A16A4CE for ; Mon, 22 Nov 2004 14:05:19 +0000 (GMT) Received: from vineyard.net (k1.vineyard.net [204.17.195.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B3F443D54 for ; Mon, 22 Nov 2004 14:05:17 +0000 (GMT) (envelope-from ericx_lists@vineyard.net) Received: from localhost (loopback [127.0.0.1]) by vineyard.net (Postfix) with ESMTP id 8DD7E91586; Mon, 22 Nov 2004 09:05:16 -0500 (EST) Received: from vineyard.net ([127.0.0.1]) by localhost (king1.vineyard.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 24685-01-62; Mon, 22 Nov 2004 09:05:16 -0500 (EST) Received: from vineyard.net (cheesenip.vineyard.net [204.17.195.113]) by vineyard.net (Postfix) with ESMTP id 5704091554; Mon, 22 Nov 2004 09:05:14 -0500 (EST) Message-ID: <41A1F219.2060504@vineyard.net> Date: Mon, 22 Nov 2004 09:05:13 -0500 From: "Eric W. Bates" User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: extech@dod.co.za References: <200411190806.iAJ86fVa081158@mail.cs.ait.ac.th> <200411191019190031.00AAC5C6@196.25.53.67> <200411191019510421.00AB444C@196.25.53.67> In-Reply-To: <200411191019510421.00AB444C@196.25.53.67> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS-king1 at Vineyard.NET cc: freebsd-net@freebsd.org Subject: Re: Gateway/Router X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 22 Nov 2004 14:05:19 -0000 Ip forwarding is on? Flag in rc.conf: gateway_enable=yes Will toggle: net.inet.ip.forwarding=1 Anton Bester wrote: >>>From the client can you ping the IP of ed0 >> >>ping 126...66 I think > > > ping IP of ed0 196...66 from client, no problem, but cannot ping 196...65, which is my cisco router to the outside. > > Must I not put in a static route?, but then again the default route points to 196...65 > > > _______________________________________________ > 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 Mon Nov 22 18:22:34 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D703316A4CE for ; Mon, 22 Nov 2004 18:22:34 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id B0D9843D55 for ; Mon, 22 Nov 2004 18:22:34 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id iAMINVtQ024717; Mon, 22 Nov 2004 10:23:31 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id iAMINVmY024716; Mon, 22 Nov 2004 10:23:31 -0800 Date: Mon, 22 Nov 2004 10:23:31 -0800 From: Brooks Davis To: Eric Masson Message-ID: <20041122182331.GB20652@odin.ac.hmc.edu> References: <867joeau4r.fsf@srvbsdnanssv.interne.kisoft-services.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GRPZ8SYKNexpdSJ7" Content-Disposition: inline In-Reply-To: <867joeau4r.fsf@srvbsdnanssv.interne.kisoft-services.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: Mailing List FreeBSD Network Subject: Re: gif4) & AltQ X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 22 Nov 2004 18:22:34 -0000 --GRPZ8SYKNexpdSJ7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 22, 2004 at 02:30:28PM +0100, Eric Masson wrote: > Hello, >=20 > In a vpn application, I'm using gif tunnels backed by ipsec transport > mode beetween two hosts on the Internet. >=20 > Is there any hope to see gif(4) modified to integrate AltQ framework or > is there any reason (except lack of maintainer/coder time) that would be > a showstopper ? I'm not sure ALTQ makes sense on a gif interface. ALTQ's operation depends on being fairly close to the point where packets hit the wire and gif is quite a ways from there (since it's riding on top of IP). I don't think there would be any objection to adding support, but gif does not have have a maintainer so you'd have to convince someone to find it intresting (or figure it out yourself.) I gather the changes aren't all that complex in general. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --GRPZ8SYKNexpdSJ7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBoi6iXY6L6fI4GtQRAl9gAJ9TJPlBewpI4cOEYl77a9GfpgIOeACeOQfQ g01QazHiTFl5yN+SQY2ky6M= =nRNl -----END PGP SIGNATURE----- --GRPZ8SYKNexpdSJ7-- From owner-freebsd-net@FreeBSD.ORG Mon Nov 22 18:26:47 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1727316A4CE for ; Mon, 22 Nov 2004 18:26:47 +0000 (GMT) Received: from shellma.zin.lublin.pl (shellma.zin.lublin.pl [212.182.126.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 93A1A43D3F for ; Mon, 22 Nov 2004 18:26:46 +0000 (GMT) (envelope-from pawmal-posting@freebsd.lublin.pl) Received: by shellma.zin.lublin.pl (Postfix, from userid 1018) id 30D07347121; Mon, 22 Nov 2004 19:29:12 +0100 (CET) Date: Mon, 22 Nov 2004 19:29:12 +0100 From: Pawel Malachowski To: freebsd-net@freebsd.org Message-ID: <20041122182912.GA33296@shellma.zin.lublin.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.4.2i Subject: Large NAT: ipf/ipnat, pf - opinions? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 22 Nov 2004 18:26:47 -0000 Hello, I'm interested in opinions/comparisons how ipnat and pf perform on FreeBSD 5.x in real working large NAT setups (about 50Mbit/s, few thousands of workstations, 300k of mappings or more). Problems noticed, memory and CPU consumption, mbufs utilization etc. TIA, -- Pawe³ Ma³achowski From owner-freebsd-net@FreeBSD.ORG Mon Nov 22 20:00:06 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1FE8316A4CF for ; Mon, 22 Nov 2004 20:00:06 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id 58BEF43D31 for ; Mon, 22 Nov 2004 20:00:05 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.206] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1CWKLz-0004Nn-00; Mon, 22 Nov 2004 21:00:03 +0100 Received: from [217.83.10.145] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1CWKLz-0001uE-00; Mon, 22 Nov 2004 21:00:04 +0100 From: Max Laier To: freebsd-net@freebsd.org Date: Mon, 22 Nov 2004 21:00:18 +0100 User-Agent: KMail/1.7.1 References: <867joeau4r.fsf@srvbsdnanssv.interne.kisoft-services.com> <20041122182331.GB20652@odin.ac.hmc.edu> In-Reply-To: <20041122182331.GB20652@odin.ac.hmc.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1455302.KRKWpJPmgl"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200411222100.26580.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 Subject: Re: gif4) & AltQ X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 22 Nov 2004 20:00:06 -0000 --nextPart1455302.KRKWpJPmgl Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 22 November 2004 19:23, Brooks Davis wrote: > On Mon, Nov 22, 2004 at 02:30:28PM +0100, Eric Masson wrote: > > Hello, > > > > In a vpn application, I'm using gif tunnels backed by ipsec transport > > mode beetween two hosts on the Internet. > > > > Is there any hope to see gif(4) modified to integrate AltQ framework or > > is there any reason (except lack of maintainer/coder time) that would be > > a showstopper ? > > I'm not sure ALTQ makes sense on a gif interface. ALTQ's operation > depends on being fairly close to the point where packets hit the wire > and gif is quite a ways from there (since it's riding on top of IP). Very true. It's more worthwhile to classify on gif and queue on the real=20 interface. Queueing on gif will only work in rate-limiting mode. > I don't think there would be any objection to adding support, but gif > does not have have a maintainer so you'd have to convince someone to > find it intresting (or figure it out yourself.) I gather the changes > aren't all that complex in general. That's true as well. Take a look at the patches on:=20 http://people.freebsd.org/~mlaier/ALTQ_driver/ and the altq(9) manpage to=20 learn how to modify a driver. It's more or less looking for if_snd and=20 modifying it according to the rules in altq(9). Not sure how *exactly* gif(= 4)=20 works, but I'll put it on my list (just not a high priority, right now). =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1455302.KRKWpJPmgl Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBokVaXyyEoT62BG0RApdmAJ9Fz3p9Uiy2UZ4hTuHW9ayzR7wMQwCdER3j x6Rm+vYaxaVG3eCvvjBwmK8= =6CUv -----END PGP SIGNATURE----- --nextPart1455302.KRKWpJPmgl-- From owner-freebsd-net@FreeBSD.ORG Mon Nov 22 20:17:08 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9C9EC16A4CE for ; Mon, 22 Nov 2004 20:17:08 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C6DD43D55 for ; Mon, 22 Nov 2004 20:17:08 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.155] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1CWKcV-0006cu-00; Mon, 22 Nov 2004 21:17:07 +0100 Received: from [217.83.10.145] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1CWKcU-00064t-00; Mon, 22 Nov 2004 21:17:06 +0100 From: Max Laier To: freebsd-net@freebsd.org Date: Mon, 22 Nov 2004 21:16:47 +0100 User-Agent: KMail/1.7.1 References: <20041122182912.GA33296@shellma.zin.lublin.pl> In-Reply-To: <20041122182912.GA33296@shellma.zin.lublin.pl> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3120092.GfOCXkcoAV"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200411222117.35177.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 cc: Pawel Malachowski Subject: Re: Large NAT: ipf/ipnat, pf - opinions? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 22 Nov 2004 20:17:08 -0000 --nextPart3120092.GfOCXkcoAV Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 22 November 2004 19:29, Pawel Malachowski wrote: > I'm interested in opinions/comparisons how ipnat and pf perform > on FreeBSD 5.x in real working large NAT setups (about 50Mbit/s, few > thousands of workstations, 300k of mappings or more). Problems noticed, > memory and CPU consumption, mbufs utilization etc. While the state information in pf is slightly larger than that of ipfilter= =20 (and thus the memory consumption). pf offers many functionalities that make= =20 it the "easier-to-manage" tool. There are also a couple of optimizations in= =20 pf that should make it perform better, but only measuring your specific=20 application can tell you which is the better for you. I'd guess that pf can= =20 lift the load described above with an average workstation (good NICs and=20 plenty of RAM provided). Note, however, that for CPU consumption packets pe= r=20 second is the important factor. For pf - with it's stateful inspection -=20 connection initialization has some meaning as well (once established, passi= ng=20 more traffic through a connection is cheap). Depending on your application, you might find pf's TABLES which greatly=20 improve management of large IP-sets. There are also many options to fine-tu= ne=20 the number of concurrent states that a (NAT)rule can create. This helps to= =20 keep down memory consumption during DDoS-Attacks. The additional "adaptive= =20 timeouts" can also help to manage load peaks. That is comparing pf 3.5 (what is in RELENG_5) with ipfilter 3.x (also in=20 RELENG_5). ipfilter 4.x has gained some, but isn't included in FreeBSD. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart3120092.GfOCXkcoAV Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBoklfXyyEoT62BG0RAm44AJ97LltR9sDHGbE0MN8pkwMdt0722gCfbtiT A+s77MpaW1zInUydcy5qTok= =n0GP -----END PGP SIGNATURE----- --nextPart3120092.GfOCXkcoAV-- From owner-freebsd-net@FreeBSD.ORG Tue Nov 23 07:09:42 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9760916A4CE for ; Tue, 23 Nov 2004 07:09:42 +0000 (GMT) Received: from mail.otel.net (gw3.OTEL.net [212.36.8.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 43FF643D2D for ; Tue, 23 Nov 2004 07:09:42 +0000 (GMT) (envelope-from tbyte@OTEL.net) Received: from dragon.otel.net ([212.36.8.135]) by mail.otel.net with esmtp (Exim 4.30; FreeBSD) id 1CWUo0-0007Q1-Ij for freebsd-net@freebsd.org; Tue, 23 Nov 2004 09:09:40 +0200 Message-ID: <41A2E23D.304@OTEL.net> Date: Tue, 23 Nov 2004 09:09:49 +0200 From: Iasen Kostov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.3) Gecko/20041117 X-Accept-Language: bg, en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: bridge and maximum MAC entries X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 23 Nov 2004 07:09:42 -0000 Hi, if I understand next code correctly maximum number of MACs is bound to maximum number of ports ?!?. Why is that ? code from net/bridge.c: c[n_clusters].my_macs = (struct bdg_addr *) malloc(BDG_MAX_PORTS * sizeof(struct bdg_addr), M_IFADDR, M_NOWAIT | M_ZERO); The best will be to allocate MAC entries dynamically. But there should be at least another definition for maximum MACs for port something like BDG_MAX_MACS ... which could be set at compile time because the current situation doesn't make sense at least for me or possibly I misunderstand something. From owner-freebsd-net@FreeBSD.ORG Tue Nov 23 08:58:19 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2FECC16A4CE for ; Tue, 23 Nov 2004 08:58:19 +0000 (GMT) Received: from mallaury.noc.nerim.net (smtp-102-tuesday.noc.nerim.net [62.4.17.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 89D5443D39 for ; Tue, 23 Nov 2004 08:58:18 +0000 (GMT) (envelope-from e-masson@kisoft-services.com) Received: from srvbsdnanssv.interne.kisoft-services.com (kisoftacces2.net1.nerim.net [62.212.107.52]) by mallaury.noc.nerim.net (Postfix) with ESMTP id A7D8C62DEE; Tue, 23 Nov 2004 09:58:16 +0100 (CET) Received: from localhost (localhost [127.0.0.1])58C44C0EB; Tue, 23 Nov 2004 09:58:16 +0100 (CET) Received: from srvbsdnanssv.interne.kisoft-services.com ([127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28021-04; Tue, 23 Nov 2004 09:58:06 +0100 (CET) Received: by srvbsdnanssv.interne.kisoft-services.com (Postfix, from userid 1001) id 63B5AC0E8; Tue, 23 Nov 2004 09:58:06 +0100 (CET) To: Max Laier From: Eric Masson In-Reply-To: <200411222100.26580.max@love2party.net> (Max Laier's message of "Mon, 22 Nov 2004 21:00:18 +0100") References: <867joeau4r.fsf@srvbsdnanssv.interne.kisoft-services.com> <20041122182331.GB20652@odin.ac.hmc.edu> <200411222100.26580.max@love2party.net> X-Operating-System: FreeBSD 5.3-STABLE i386 Date: Tue, 23 Nov 2004 09:58:05 +0100 Message-ID: <86fz31lz6q.fsf@srvbsdnanssv.interne.kisoft-services.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at interne.kisoft-services.com cc: freebsd-net@freebsd.org Subject: Re: gif4) & AltQ X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 23 Nov 2004 08:58:19 -0000 >>>>> "Max" == Max Laier writes: Hello Max, Max> Very true. It's more worthwhile to classify on gif and queue on Max> the real interface. How would you achieve this setup ? I can only think about this way (assuming gif0 tunnel packets flow thru ep1) : ext_if="ep1" tunnel_if=gif0" altq on $ext_if bandwidth 2Mb cbq queue { dflt, developers, marketing } queue dflt bandwidth 5% cbq(default) queue developers bandwidth 80% queue marketing bandwidth 15% pass out on $tunnel_if from 192.168.0.0/24 to any keep state queue developers pass out on $tunnel_if from 192.168.1.0/24 to any keep state queue marketing But in this setup classification is made on unencapsuled packet, and shaping is done on encapsulated packet. Does this mean that the mbuf tag set by classification rules survives the gif encapsulation process ? Max> Queueing on gif will only work in rate-limiting mode. Ok. Max> That's true as well. Take a look at the patches on: Max> http://people.freebsd.org/~mlaier/ALTQ_driver/ and the altq(9) Max> manpage to learn how to modify a driver. It's more or less looking Max> for if_snd and modifying it according to the rules in altq(9). I'll have a look. Max> Not sure how *exactly* gif(4) works, but I'll put it on my list Max> (just not a high priority, right now). Ok, thanks to you and Brooks for explanations. Regards Eric Masson -- C'est pas avec la censure que tu vas censurer les censeurs. -+- JL in GNU : Las, censeurs pour l'échafaud -+- From owner-freebsd-net@FreeBSD.ORG Tue Nov 23 09:04:48 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 20AAE16A4CE for ; Tue, 23 Nov 2004 09:04:48 +0000 (GMT) Received: from p4.roq.com (ns1.ecoms.com [207.44.130.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8079A43D55 for ; Tue, 23 Nov 2004 09:04:47 +0000 (GMT) (envelope-from mv@roq.com) Received: from p4.roq.com (localhost.roq.com [127.0.0.1]) by p4.roq.com (Postfix) with ESMTP id 3BD614C9FC for ; Tue, 23 Nov 2004 09:06:01 +0000 (GMT) Received: from [192.168.46.42] (s0D26.static.pacific.net.au [203.100.254.38]) by p4.roq.com (Postfix) with ESMTP id A007F4C9D5 for ; Tue, 23 Nov 2004 09:06:00 +0000 (GMT) Message-ID: <41A2FD30.3080301@roq.com> Date: Tue, 23 Nov 2004 20:04:48 +1100 From: Michael Vince User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.3) Gecko/20041110 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: FAST_IPSEC vs IPSEC performanc X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 23 Nov 2004 09:04:48 -0000 Hey all. I have been googling around the Internet for information about IPSEC and FAST_IPSEC for freebsd on the Internet and wondered what gives best performance when I came across this http://people.freebsd.org/~pjd/netperf/ It has some nice graphs / figures on performance of IPSEC and FAST_IPSEC via gigabit ethernet devices and as long as I am seeing this correctly it appears the regular IP_SEC is a fair bit faster in some areas then FAST_IPSEC. Does any one know if this information correct? Anyone done there own benchmarks? Thanks From owner-freebsd-net@FreeBSD.ORG Tue Nov 23 09:05:12 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 108BF16A4CE for ; Tue, 23 Nov 2004 09:05:12 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D41F43D31 for ; Tue, 23 Nov 2004 09:05:11 +0000 (GMT) (envelope-from martin.eugen@gmail.com) Received: by wproxy.gmail.com with SMTP id 68so283289wra for ; Tue, 23 Nov 2004 01:05:11 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:mime-version:content-type:content-transfer-encoding; b=oWWJf4W9YtoHM+OhjjwXnrBd947J0wnZ62pIyEtk/maW0hFLQXcO1fGeXXhrKAzFGibOo8MuzmdUXR7HJRPO8y+rqYWtcyppJJ7SWGSS0Q1Mdud+iwTCgHx6+Yo9o36hJIEU0GqnU0lDaGx/mMqi+1sTGIbuU7MUOiqAbbu+w50= Received: by 10.54.44.53 with SMTP id r53mr17269wrr; Tue, 23 Nov 2004 01:05:07 -0800 (PST) Received: by 10.54.11.42 with HTTP; Tue, 23 Nov 2004 01:05:06 -0800 (PST) Message-ID: <966ba91e04112301052fed8d6b@mail.gmail.com> Date: Tue, 23 Nov 2004 11:05:06 +0200 From: Martin Eugen To: freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: resolving routes externally X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Martin Eugen List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2004 09:05:12 -0000 Hi there, I'm currently trying to implement some networking protocols in the kernel. I would like to ask a few questions, but first, let me explain some details about those protocols: the network is composed of smaller subnets connected through gateways. Hosts have a fairly complex global addresses, and small integer subnet addresses (that are valid only in one subnet). Global routing is done at gateways, that upon reception of a packet perform some lookups based on the complex global address of the recipient in order to find the subnet and the small integer address of the next hop. May be it would be easier to understand if you imagine the internet as a network where IP addresses are not global, but hostnames are. IP packets that need to be routed outside of given subnet will carry hostnames instead of ip addresses, and gateways will do some resolving based on the domain or something of the destination hostname in order to find the next hop. At the beginning my intention was to use the routing sockets mechanisms, and say, to issue a 'missing route' message to some userland daemon capable of resolving those complex addresses (the resolving mechanism is generally a lookup in a local DB). But then I realized there is no (Am I missing it?) code in the routing modules that could make the thread handling the packet sleep until the userland daemon is looking up the route. (I'm also still not sure if a 'netisr' thread is safe to sleep?) So I started to look at the ARP code, but it of course lacks the kernel - userland communication interface. I would appreciate any ideas about what would be the easier way to implement such a thing where the kernel could wait (up to some reasonable time-out) a userland daemon to install a new route. Thanks. Regards, Martin P.S. I'm not subscribed to the list, please CC any replies. From owner-freebsd-net@FreeBSD.ORG Tue Nov 23 09:45:09 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B564816A4CE for ; Tue, 23 Nov 2004 09:45:09 +0000 (GMT) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1990B43D41 for ; Tue, 23 Nov 2004 09:45:09 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id 39E561FFACA for ; Tue, 23 Nov 2004 10:45:07 +0100 (CET) Received: by transport.cksoft.de (Postfix, from userid 66) id 578991FF9AF; Tue, 23 Nov 2004 10:45:05 +0100 (CET) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id 6621F156C2; Tue, 23 Nov 2004 09:44:04 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id 5B4D715596 for ; Tue, 23 Nov 2004 09:44:05 +0000 (UTC) Date: Tue, 23 Nov 2004 09:44:05 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: freebsd-net@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de Subject: please test: miibus GE ony PHY detection X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 23 Nov 2004 09:45:09 -0000 Please test: ! ! With the changes from mii.h rev 1.4 to adopt NetBSD checks ! using BMSR_MEDIAMASK it was missed that in rev 1.26 of mii.c ! in NetBSD there had been another change: ! ! : When probing for a PHY, look at the EXTSTAT bit in the BMSR, as well, ! : not just the media mask. This prevents PHYs/TBIs that only support ! : Gigabit media from slipping through the cracks. ! ! With this GE only ones like from the SK-9844 are detected again. ! Index: mii.c =================================================================== RCS file: /local/mirror/FreeBSD/r/ncvs/src/sys/dev/mii/mii.c,v retrieving revision 1.20 diff -u -p -r1.20 mii.c --- mii.c 15 Aug 2004 06:24:40 -0000 1.20 +++ mii.c 23 Nov 2004 08:46:30 -0000 @@ -125,7 +125,7 @@ miibus_probe(dev) */ bmsr = MIIBUS_READREG(parent, ma.mii_phyno, MII_BMSR); if (bmsr == 0 || bmsr == 0xffff || - (bmsr & BMSR_MEDIAMASK) == 0) { + (bmsr & (BMSR_EXTSTAT|BMSR_MEDIAMASK)) == 0) { /* Assume no PHY at this address. */ continue; } @@ -316,7 +316,7 @@ mii_phy_probe(dev, child, ifmedia_upd, i for (i = 0; i < MII_NPHY; i++) { bmsr = MIIBUS_READREG(dev, i, MII_BMSR); if (bmsr == 0 || bmsr == 0xffff || - (bmsr & BMSR_MEDIAMASK) == 0) { + (bmsr & (BMSR_EXTSTAT|BMSR_MEDIAMASK)) == 0) { /* Assume no PHY at this address. */ continue; } else -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-net@FreeBSD.ORG Tue Nov 23 10:02:41 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F08B916A4CE for ; Tue, 23 Nov 2004 10:02:41 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 87B8243D58 for ; Tue, 23 Nov 2004 10:02:41 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.13.1/8.13.1) with ESMTP id iANA0uq0083538 for ; Tue, 23 Nov 2004 05:00:56 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)iANA0ukQ083535 for ; Tue, 23 Nov 2004 10:00:56 GMT (envelope-from robert@fledge.watson.org) Date: Tue, 23 Nov 2004 10:00:55 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: net@FreeBSD.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Running into an mbuf leak with bridging and tap X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 23 Nov 2004 10:02:42 -0000 I'm running an ethernet over TCP bridge using a combination of the native ethernet bridge support and the tap driver. Basically, a daemon sits on /dev/tapX and bridges ethernet frames using a small header over a TCP connection. The bridge support is loaded as a kld, as is the tap support, and both modules remain resident from then on. After a couple of days, perhaps triggered by the connection going up and down and leaving bridging turned on even when nothing is listening on the tap device, the endpoints will run out of mbufs: 26707 mbufs in use 25453/25600 mbuf clusters in use (current/max) 0/3/6656 sfbufs in use (current/peak/max) 57582 KBytes allocated to network 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines Under normal circumstances (i.e., without tap and ethernet bridging on), this doesn't happen, suggesting that maybe there's a leak in the bridging code or tap code. I've now seen this with three boxes, a blend of UP and SMP. I haven't yet had a chance to sit down with a debugging kernel. Has anyone else seen anything like this? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research From owner-freebsd-net@FreeBSD.ORG Tue Nov 23 10:14:04 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 616D916A4CE; Tue, 23 Nov 2004 10:14:04 +0000 (GMT) Received: from mail.cs.ait.ac.th (mail.cs.ait.ac.th [192.41.170.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id E5AB243D2D; Tue, 23 Nov 2004 10:14:02 +0000 (GMT) (envelope-from on@cs.ait.ac.th) Received: from mail.cs.ait.ac.th (localhost.cs.ait.ac.th [127.0.0.1]) by mail.cs.ait.ac.th (8.12.11/8.12.11) with ESMTP id iANAE0s2098976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Nov 2004 17:14:00 +0700 (ICT) Received: (from on@localhost) by mail.cs.ait.ac.th (8.12.11/8.12.11/Submit) id iANAE07p098973; Tue, 23 Nov 2004 17:14:00 +0700 (ICT) Date: Tue, 23 Nov 2004 17:14:00 +0700 (ICT) Message-Id: <200411231014.iANAE07p098973@mail.cs.ait.ac.th> From: Olivier Nicole To: rwatson@freebsd.org In-reply-to: (message from Robert Watson on Tue, 23 Nov 2004 10:00:55 +0000 (GMT)) X-Virus-Scanned: on CSIM by amavisd-milter (http://www.amavis.org/) cc: net@freebsd.org Subject: Re: Running into an mbuf leak with bridging and tap X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 23 Nov 2004 10:14:04 -0000 > I'm running an ethernet over TCP bridge using a combination of the native > ethernet bridge support and the tap driver. Basically, a daemon sits on > /dev/tapX and bridges ethernet frames using a small header over a TCP Yup i think I have seen the same thing while I was using a combination of vtun (IP over IP tunnelling), tap and bridge. As it was a one day only experiment that was not critical and I just incresed mbuf. Olivier From owner-freebsd-net@FreeBSD.ORG Tue Nov 23 13:42:43 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3BE8816A4CE; Tue, 23 Nov 2004 13:42:43 +0000 (GMT) Received: from minerva.int.gov.br (nat.int.gov.br [200.20.196.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4EFF043D46; Tue, 23 Nov 2004 13:42:42 +0000 (GMT) (envelope-from jonny@jonny.eng.br) Received: from [10.0.8.17] (dinf-02 [10.0.8.17]) by minerva.int.gov.br (Postfix) with ESMTP id E60A4BE571; Tue, 23 Nov 2004 11:42:39 -0200 (BRDT) Message-ID: <41A33E4F.8060705@jonny.eng.br> Date: Tue, 23 Nov 2004 11:42:39 -0200 From: =?ISO-8859-1?Q?Jo=E3o_Carlos_Mendes_Lu=EDs?= User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin Eugen References: <966ba91e04112301052fed8d6b@mail.gmail.com> In-Reply-To: <966ba91e04112301052fed8d6b@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit cc: freebsd-net@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: resolving routes externally X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 23 Nov 2004 13:42:43 -0000 Martin Eugen wrote: > Hi there, > I'm currently trying to implement some networking protocols in the > kernel. I would like to ask a few questions, but first, let me explain > some details about those protocols: the network is composed of smaller > subnets connected through gateways. Hosts have a fairly complex global > addresses, and small integer subnet addresses (that are valid only in > one subnet). Global routing is done at gateways, that upon reception > of a packet perform some lookups based on the complex global address > of the recipient in order to find the subnet and the small integer > address of the next hop. May be it would be easier to understand if > you imagine the internet as a network where IP addresses are not > global, but hostnames are. IP packets that need to be routed outside > of given subnet will carry hostnames instead of ip addresses, and > gateways will do some resolving based on the domain or something of > the destination hostname in order to find the next hop. > At the beginning my intention was to use the routing sockets > mechanisms, and say, to issue a 'missing route' message to some > userland daemon capable of resolving those complex addresses (the > resolving mechanism is generally a lookup in a local DB). But then I > realized there is no (Am I missing it?) code in the routing modules > that could make the thread handling the packet sleep until the > userland daemon is looking up the route. (I'm also still not sure if a > 'netisr' thread is safe to sleep?) So I started to look at the ARP > code, but it of course lacks the kernel - userland communication > interface. I would appreciate any ideas about what would be the easier > way to implement such a thing where the kernel could wait (up to some > reasonable time-out) a userland daemon to install a new route. Why don´t you simply discard the packet and wait for the next retry? > P.S. I'm not subscribed to the list, please CC any replies. From owner-freebsd-net@FreeBSD.ORG Tue Nov 23 13:53:40 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7316116A4CE; Tue, 23 Nov 2004 13:53:40 +0000 (GMT) Received: from britannica.bec.de (wlan032195.uni-rostock.de [139.30.32.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D58F43D2F; Tue, 23 Nov 2004 13:53:40 +0000 (GMT) (envelope-from joerg@britannica.bec.de) Received: by britannica.bec.de (Postfix, from userid 1001) id BFE1B29F5; Tue, 23 Nov 2004 14:52:36 +0100 (CET) Date: Tue, 23 Nov 2004 14:52:36 +0100 From: Joerg Sonnenberger To: Jo?o Carlos Mendes Lu?s Message-ID: <20041123135236.GC1032@britannica.bec.de> Mail-Followup-To: Jo?o Carlos Mendes Lu?s , Martin Eugen , freebsd-net@freebsd.org, freebsd-hackers@freebsd.org References: <966ba91e04112301052fed8d6b@mail.gmail.com> <41A33E4F.8060705@jonny.eng.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41A33E4F.8060705@jonny.eng.br> User-Agent: Mutt/1.5.6i cc: freebsd-net@freebsd.org cc: Martin Eugen cc: freebsd-hackers@freebsd.org Subject: Re: resolving routes externally X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 23 Nov 2004 13:53:40 -0000 On Tue, Nov 23, 2004 at 11:42:39AM -0200, Jo?o Carlos Mendes Lu?s wrote: > >So I started to look at the ARP > >code, but it of course lacks the kernel - userland communication > >interface. I would appreciate any ideas about what would be the easier > >way to implement such a thing where the kernel could wait (up to some > >reasonable time-out) a userland daemon to install a new route. > > Why don't you simply discard the packet and wait for the next retry? Or alternatively use an internal queue of limited size to keep track of those packages. Joerg From owner-freebsd-net@FreeBSD.ORG Tue Nov 23 16:20:50 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB15316A4CE; Tue, 23 Nov 2004 16:20:50 +0000 (GMT) Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1FD4943D49; Tue, 23 Nov 2004 16:20:50 +0000 (GMT) (envelope-from maksim.yevmenkin@savvis.net) Received: from [192.168.1.254] (really [24.52.242.150]) by mta9.adelphia.net (InterMail vM.6.01.03.02 201-2131-111-104-20040324) with ESMTP id <20041123162049.JUVB14438.mta9.adelphia.net@[192.168.1.254]>; Tue, 23 Nov 2004 11:20:49 -0500 Message-ID: <41A36366.2000202@savvis.net> Date: Tue, 23 Nov 2004 08:20:54 -0800 From: Maksim Yevmenkin User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: net@freebsd.org Subject: Re: Running into an mbuf leak with bridging and tap X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 23 Nov 2004 16:20:50 -0000 Robert, > I'm running an ethernet over TCP bridge using a combination of the native > ethernet bridge support and the tap driver. Basically, a daemon sits on > /dev/tapX and bridges ethernet frames using a small header over a TCP > connection. The bridge support is loaded as a kld, as is the tap support, > and both modules remain resident from then on. After a couple of days, > perhaps triggered by the connection going up and down and leaving bridging > turned on even when nothing is listening on the tap device, the endpoints > will run out of mbufs: > > 26707 mbufs in use > 25453/25600 mbuf clusters in use (current/max) > 0/3/6656 sfbufs in use (current/peak/max) > 57582 KBytes allocated to network > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 0 requests for I/O initiated by sendfile > 0 calls to protocol drain routines > > Under normal circumstances (i.e., without tap and ethernet bridging on), > this doesn't happen, suggesting that maybe there's a leak in the bridging > code or tap code. I've now seen this with three boxes, a blend of UP and > SMP. I haven't yet had a chance to sit down with a debugging kernel. Has > anyone else seen anything like this? could you please try to use ng_bridge(4)? example scripts are in /usr/share/examples/netgraph. this could tell me if tap(4) is at fault. max From owner-freebsd-net@FreeBSD.ORG Tue Nov 23 16:26:32 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6CBDE16A4CE for ; Tue, 23 Nov 2004 16:26:32 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE5C543D1F for ; Tue, 23 Nov 2004 16:26:27 +0000 (GMT) (envelope-from martin.eugen@gmail.com) Received: by wproxy.gmail.com with SMTP id 68so312644wra for ; Tue, 23 Nov 2004 08:26:26 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=Rwk8YBbuPg2TqddLrAMNIO6+Nw6VacKqWuLmaNdmPDptBrufwm7GI43lhedb1DJ6q0lohpqZMokTxijGhbd3SY7b81FimHoZhs+JuhCHAnhsmwEurfsYAVRzLeWQbBKcvZ/jksaDNbZHKxDcTl/rCh2MSxyomp0bGczdEh13HWY= Received: by 10.54.7.15 with SMTP id 15mr177162wrg; Tue, 23 Nov 2004 08:24:48 -0800 (PST) Received: by 10.54.11.25 with HTTP; Tue, 23 Nov 2004 08:24:48 -0800 (PST) Message-ID: <966ba91e04112308246616d1b8@mail.gmail.com> Date: Tue, 23 Nov 2004 18:24:48 +0200 From: Martin Eugen To: Jo?o Carlos Mendes Lu?s , freebsd-net@freebsd.org, freebsd-hackers@freebsd.org, Joerg Sonnenberger In-Reply-To: <20041123135236.GC1032@britannica.bec.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <966ba91e04112301052fed8d6b@mail.gmail.com> <41A33E4F.8060705@jonny.eng.br> <20041123135236.GC1032@britannica.bec.de> Subject: Re: resolving routes externally X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Martin Eugen List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2004 16:26:32 -0000 On Tue, 23 Nov 2004 14:52:36 +0100, Joerg Sonnenberger wrote: > On Tue, Nov 23, 2004 at 11:42:39AM -0200, Jo?o Carlos Mendes Lu?s wrote: > > >So I started to look at the ARP > > >code, but it of course lacks the kernel - userland communication > > >interface. I would appreciate any ideas about what would be the easier > > >way to implement such a thing where the kernel could wait (up to some > > >reasonable time-out) a userland daemon to install a new route. > > > > Why don't you simply discard the packet and wait for the next retry? > Because the network is not like the internet, packet error correction and so on is done at lower layers, I mean... if there are some packets that are equivalent to the TCP SYNs, the 'SYN' timeout in our case is in minutes (because it is believed the host or a link is down or something else that could take longer time to resolve). This is bad, because connections will be established within some minutes... > Or alternatively use an internal queue of limited size to keep track of > those packages. This is probably the only solution I can think of right now, but I think poking a queue at regular, short intervals seems to me quite expensive, isn't it? Or perhaps there could be a netgraph node that handles the queue and connects to the userland daemon... but this could make things much more complicated... ? > > Joerg > From owner-freebsd-net@FreeBSD.ORG Tue Nov 23 17:15:37 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7034E16A4CE for ; Tue, 23 Nov 2004 17:15:37 +0000 (GMT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3415843D31 for ; Tue, 23 Nov 2004 17:15:37 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.91] ([66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id iANHFaWi046442 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 23 Nov 2004 09:15:36 -0800 (PST) (envelope-from sam@errno.com) From: Sam Leffler Organization: Errno Consulting To: freebsd-net@freebsd.org Date: Tue, 23 Nov 2004 09:23:38 -0800 User-Agent: KMail/1.7 References: <41A2FD30.3080301@roq.com> In-Reply-To: <41A2FD30.3080301@roq.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200411230923.38227.sam@errno.com> cc: Michael Vince Subject: Re: FAST_IPSEC vs IPSEC performanc X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 23 Nov 2004 17:15:37 -0000 On Tuesday 23 November 2004 01:04 am, Michael Vince wrote: > Hey all. > > I have been googling around the Internet for information about IPSEC and > FAST_IPSEC for freebsd on the Internet and wondered what gives best > performance > when I came across this http://people.freebsd.org/~pjd/netperf/ > It has some nice graphs / figures on performance of IPSEC and FAST_IPSEC > via gigabit ethernet devices and as long as I am seeing this correctly > it appears the regular IP_SEC is a fair bit faster in some areas then > FAST_IPSEC. > Does any one know if this information correct? > Anyone done there own benchmarks? My Usenix paper has performancomparisons from a while ago: http://www.usenix.org/publications/library/proceedings/bsdcon03/tech/full_papers/leffler_ipsec/leffler_ipsec_html/ce From owner-freebsd-net@FreeBSD.ORG Tue Nov 23 18:36:51 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 74E6216A4CE; Tue, 23 Nov 2004 18:36:51 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id AEC6A43D39; Tue, 23 Nov 2004 18:36:50 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id E1DC5653D2; Tue, 23 Nov 2004 18:36:48 +0000 (GMT) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 51694-01-4; Tue, 23 Nov 2004 18:36:48 +0000 (GMT) Received: from empiric.dek.spc.org (dhcp120.icir.org [192.150.187.120]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id F0B4E65375; Tue, 23 Nov 2004 18:36:47 +0000 (GMT) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 350406680; Tue, 23 Nov 2004 10:36:46 -0800 (PST) Date: Tue, 23 Nov 2004 10:36:46 -0800 From: Bruce M Simpson To: Martin Eugen Message-ID: <20041123183646.GB733@empiric.icir.org> Mail-Followup-To: Martin Eugen , freebsd-net@freebsd.org, freebsd-hackers@freebsd.org References: <966ba91e04112301052fed8d6b@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <966ba91e04112301052fed8d6b@mail.gmail.com> cc: freebsd-net@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: resolving routes externally X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 23 Nov 2004 18:36:51 -0000 On Tue, Nov 23, 2004 at 11:05:06AM +0200, Martin Eugen wrote: > At the beginning my intention was to use the routing sockets > mechanisms, and say, to issue a 'missing route' message to some > userland daemon capable of resolving those complex addresses (the > resolving mechanism is generally a lookup in a local DB). But then I You're on the right track here. You might also wish to investigate the RTM_RESOLVE mechanism. > realized there is no (Am I missing it?) code in the routing modules > that could make the thread handling the packet sleep until the > userland daemon is looking up the route. (I'm also still not sure if a > 'netisr' thread is safe to sleep?) So I started to look at the ARP > code, but it of course lacks the kernel - userland communication > interface. I would appreciate any ideas about what would be the easier > way to implement such a thing where the kernel could wait (up to some > reasonable time-out) a userland daemon to install a new route. If I understand correctly, you want the kernel to queue packets until layer 2 address resolution is complete. Right now we don't do this. If there is no route to a destination, packets will be dropped. The ARP code implements a queue for each IP host address which is exactly 1 mbuf long (see llinfo_arp->la_hold). This holds the most recent packet that the host is attempting to transmit to the host pending MAC address lookup. All other packets will be dropped. Making a network stack thread sleep would be a Very Bad Idea. A more appropriate approach would be to use a separate netisr queue for packets which have pending external MAC address lookup. However, rather than calling netisr_dispatch() directly, you would want to call schednetisr() directly once the route resolution was complete. I guess this is non-IP traffic, in which case making the modifications which you need will probably be easier. Regards, BMS From owner-freebsd-net@FreeBSD.ORG Wed Nov 24 01:49:20 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E92F416A50D; Wed, 24 Nov 2004 01:49:20 +0000 (GMT) Received: from mx01.bos.ma.towardex.com (mx01.bos.ma.towardex.com [65.124.16.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3DD4343D2D; Wed, 24 Nov 2004 01:49:20 +0000 (GMT) (envelope-from haesu@mx01.bos.ma.towardex.com) Received: by mx01.bos.ma.towardex.com (TowardEX ESMTP 3.0p11_DAKN, from userid 1001) id B12B82F93F; Tue, 23 Nov 2004 20:49:19 -0500 (EST) Date: Tue, 23 Nov 2004 20:49:19 -0500 From: James To: Martin Eugen , freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Message-ID: <20041124014919.GA9396@scylla.towardex.com> References: <966ba91e04112301052fed8d6b@mail.gmail.com> <20041123183646.GB733@empiric.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041123183646.GB733@empiric.icir.org> User-Agent: Mutt/1.4.1i Subject: Re: resolving routes externally X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 24 Nov 2004 01:49:21 -0000 On Tue, Nov 23, 2004 at 10:36:46AM -0800, Bruce M Simpson wrote: [ snip ] > > If I understand correctly, you want the kernel to queue packets until > layer 2 address resolution is complete. Right now we don't do this. If > there is no route to a destination, packets will be dropped. The KAME ipv6 code does this for v6 neighbor discovery (which is not arp yes..). Martin, nd6_output() in netinet6/nd6.c should be helpful if you want to look. RFC requires routers to queue packets up during layer 2 resolution process (which is why in IPv6 when destination host is down you see !A with huge latency -- i.e. 3400ms due to queueing by the router[1]). If you are queueing however, make sure you use locking or check for any safety mechanisms as you may corrupt mbuf's that are flooding inbound. BTW Martin,, what is the purpose of this intent? Just curiousity of mine. [1]: Some hardware/ASIC based routers violate the RFC unfortunately. It's a little harder to implement there (see J vendor) -J -- James Jun TowardEX Technologies, Inc. Technical Lead Boston IPv4/IPv6 Web Hosting, Colocation and james@towardex.com Network design/consulting & configuration services cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net From owner-freebsd-net@FreeBSD.ORG Wed Nov 24 01:51:56 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D4F1016A4CE; Wed, 24 Nov 2004 01:51:56 +0000 (GMT) Received: from mx01.bos.ma.towardex.com (mx01.bos.ma.towardex.com [65.124.16.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7711643D49; Wed, 24 Nov 2004 01:51:56 +0000 (GMT) (envelope-from haesu@mx01.bos.ma.towardex.com) Received: by mx01.bos.ma.towardex.com (TowardEX ESMTP 3.0p11_DAKN, from userid 1001) id 4AA5C2F947; Tue, 23 Nov 2004 20:51:56 -0500 (EST) Date: Tue, 23 Nov 2004 20:51:56 -0500 From: James To: Martin Eugen , freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Message-ID: <20041124015156.GA33719@scylla.towardex.com> References: <966ba91e04112301052fed8d6b@mail.gmail.com> <20041123183646.GB733@empiric.icir.org> <20041124014919.GA9396@scylla.towardex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041124014919.GA9396@scylla.towardex.com> User-Agent: Mutt/1.4.1i Subject: Re: resolving routes externally X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 24 Nov 2004 01:51:57 -0000 On Tue, Nov 23, 2004 at 08:49:19PM -0500, James wrote: > On Tue, Nov 23, 2004 at 10:36:46AM -0800, Bruce M Simpson wrote: > [ snip ] > > > > If I understand correctly, you want the kernel to queue packets until > > layer 2 address resolution is complete. Right now we don't do this. If > > there is no route to a destination, packets will be dropped. > > The KAME ipv6 code does this for v6 neighbor discovery (which is not > arp yes..). Martin, nd6_output() in netinet6/nd6.c should be helpful > if you want to look. RFC requires routers to queue packets up during > layer 2 resolution process (which is why in IPv6 when destination > host is down you see !A with huge latency -- i.e. 3400ms due to > queueing by the router[1]). Err my bad. I meant 'latest packet' (like in arp resolution) -J -- James Jun TowardEX Technologies, Inc. Technical Lead Boston IPv4/IPv6 Web Hosting, Colocation and james@towardex.com Network design/consulting & configuration services cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net From owner-freebsd-net@FreeBSD.ORG Wed Nov 24 01:59:32 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E560D16A4CE for ; Wed, 24 Nov 2004 01:59:31 +0000 (GMT) Received: from hotmail.com (bay24-f36.bay24.hotmail.com [64.4.18.86]) by mx1.FreeBSD.org (Postfix) with ESMTP id B595543D39 for ; Wed, 24 Nov 2004 01:59:31 +0000 (GMT) (envelope-from segr@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 23 Nov 2004 17:58:01 -0800 Message-ID: Received: from 205.206.122.73 by by24fd.bay24.hotmail.msn.com with HTTP; Wed, 24 Nov 2004 01:57:32 GMT X-Originating-IP: [205.206.122.73] X-Originating-Email: [segr@hotmail.com] X-Sender: segr@hotmail.com From: "Stephane Raimbault" To: max@love2party.net Date: Tue, 23 Nov 2004 18:57:32 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 24 Nov 2004 01:58:01.0697 (UTC) FILETIME=[07753510:01C4D1C9] cc: net@FreeBSD.org Subject: Re: Large NAT: ipf/ipnat, pf - opinions? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 24 Nov 2004 01:59:32 -0000 You mention diffrent ways to fine-tune pf. I'm particularly interested in the number of states. I have a situation where I'm running pf around 8000 states and the box seems to perform quite beautifully, I have increased the max states to 100K to cover large peaks which can occur, however I haven't yet observed anything about 10K. One problem I do find, is if one IP has 200 ~ 500 states, the user reports timeouts thru the nat. In my particular situation, I'm forwarding port 80 to a webserver in the nat environment and the clients are internet users. I don't seem to have this problem when running natd on FreeBSD 4.9, however the load of the nat box is quite a bit higher (~ 10 times) then running pf on FreeBSD 5.3. Any suggestions? Here are my pf rules # Set pf limits set limit states 100000 # NAT the internal network nat on $ext_vip from $web_servers port 80 to any -> ($ext_vip) nat on $ext_vip from $ssl_servers port 443 to any -> ($ext_vip) nat on $ext_if from $int_net to any -> ($ext_if) # Forward ports from external to internal rdr on $ext_if proto tcp from any to any port 80 -> $web_servers round-robin rdr on $ext_if proto tcp from any to any port 443 -> $ssl_servers round-robin # forward ports from internal to internal rdr on $int_if proto tcp from $int_net to $ext_if port 80 -> $web_servers round-robin rdr on $int_if proto tcp from $int_net to $ext_if port 443 -> $ssl_servers round-robin no nat on $int_if proto tcp from $int_if to $int_net nat on $int_if proto tcp from $int_net to $web_servers port 80 -> $int_if nat on $int_if proto tcp from $int_net to $ssl_servers port 443 -> $int_if Thanks, Stephane. --nextPart3120092.GfOCXkcoAV Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 22 November 2004 19:29, Pawel Malachowski wrote: >> I'm interested in opinions/comparisons how ipnat and pf perform >>on FreeBSD 5.x in real working large NAT setups (about 50Mbit/s, few >>thousands of workstations, 300k of mappings or more). Problems noticed, >>memory and CPU consumption, mbufs utilization etc. While the state information in pf is slightly larger than that of ipfilter= =20 (and thus the memory consumption). pf offers many functionalities that make= =20 it the "easier-to-manage" tool. There are also a couple of optimizations in= =20 pf that should make it perform better, but only measuring your specific=20 application can tell you which is the better for you. I'd guess that pf can= =20 lift the load described above with an average workstation (good NICs and=20 plenty of RAM provided). Note, however, that for CPU consumption packets pe= r=20 second is the important factor. For pf - with it's stateful inspection -=20 connection initialization has some meaning as well (once established, passi= ng=20 more traffic through a connection is cheap). Depending on your application, you might find pf's TABLES which greatly=20 improve management of large IP-sets. There are also many options to fine-tu= ne=20 the number of concurrent states that a (NAT)rule can create. This helps to= =20 keep down memory consumption during DDoS-Attacks. The additional "adaptive= =20 timeouts" can also help to manage load peaks. That is comparing pf 3.5 (what is in RELENG_5) with ipfilter 3.x (also in=20 RELENG_5). ipfilter 4.x has gained some, but isn't included in FreeBSD. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart3120092.GfOCXkcoAV Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBoklfXyyEoT62BG0RAm44AJ97LltR9sDHGbE0MN8pkwMdt0722gCfbtiT A+s77MpaW1zInUydcy5qTok= =n0GP -----END PGP SIGNATURE----- --nextPart3120092.GfOCXkcoAV-- _________________________________________________________________ Designer Mail isn't just fun to send, it's fun to receive. Use special stationery, fonts and colors. http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*. From owner-freebsd-net@FreeBSD.ORG Wed Nov 24 02:02:33 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5517316A4CE for ; Wed, 24 Nov 2004 02:02:33 +0000 (GMT) Received: from mail.citiz.net (ws15.citiz.net [218.1.66.100]) by mx1.FreeBSD.org (Postfix) with SMTP id 3A98343D31 for ; Wed, 24 Nov 2004 02:02:30 +0000 (GMT) (envelope-from edrt@citiz.net) Received: (umta 13601 invoked by alias); 24 Nov 2004 02:02:23 -0000 X-Lasthop: 221.137.4.49 Received: from unknown (HELO zhaoyi) (unknown@221.137.4.49) by localhost with SMTP; 24 Nov 2004 02:02:23 -0000 From: "edrt" To: freebsd-net@freebsd.org X-mailer: Foxmail 4.2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Date: Wed, 24 Nov 2004 9:59:9 +0800 Message-Id: <20041124020230.3A98343D31@mx1.FreeBSD.org> cc: edrt@citiz.net Subject: run multicast daemon on vlan interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 24 Nov 2004 02:02:33 -0000 Hi All, I tried running pimd and forwarding multicast traffic on vlan interface with a freebsd derived kernel, but it seems that kernel failed to receive multicast traffic on the vlan interface. I guess the reason partly lies in vlan_ioctl's SIOCSIFFLAGS handler doesn't take care IFF_ALLMULTI flag and call parent interface's if_allmulti. Does anyone have a success try of forwarding multicast traffic on vlan interface ? Or the kernel should be patched to support setting IFF_ALLMULTI flag on vlan interface ? Thanks Yi Zhao From owner-freebsd-net@FreeBSD.ORG Wed Nov 24 02:32:21 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B2AD116A4CE for ; Wed, 24 Nov 2004 02:32:21 +0000 (GMT) Received: from insomnia.benzedrine.cx (insomnia.benzedrine.cx [62.65.145.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id B4CF943D49 for ; Wed, 24 Nov 2004 02:32:20 +0000 (GMT) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (dhartmei@localhost [127.0.0.1]) iAO2WHRh012785 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Wed, 24 Nov 2004 03:32:17 +0100 (MET) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.13.1/8.12.10/Submit) id iAO2WGCR013662; Wed, 24 Nov 2004 03:32:16 +0100 (MET) Date: Wed, 24 Nov 2004 03:32:16 +0100 From: Daniel Hartmeier To: Pawel Worach Message-ID: <20041124023216.GH9247@insomnia.benzedrine.cx> References: <419EBE2E.9080108@telia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <419EBE2E.9080108@telia.com> User-Agent: Mutt/1.4.1i cc: freebsd-net@freebsd.org Subject: Re: SACK (and PF) wierdness X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 24 Nov 2004 02:32:21 -0000 Pawel kindly supplied a tcpdump of an entire connection. We identified the point where pf drops the packet because it sees a violation of the advertised sequence window. I think we can show that there is some problem with the TCP code, possibly related to SACK. Hence, I'd like to ask anyone familar with TCP and SACK to help. You can find the output on http://www.benzedrine.cx/pawel.txt (328k) This is an active FTP data connection, from FTP server 192.168.1.10:20 to FTP client 192.168.1.200:64828, where payload is only flowing from server to client. Both hosts run recent FreeBSD 6-current. The dump consists of 1571 packets, 940 from server to client and 631 from client to server. pf complains about the 1572th packet (not found in the dump, as it was blocked): Nov 22 23:25:20 darkstar kernel: pf: BAD state: TCP 192.168.1.10:20 192.168.1.10:20 192.168.1.200:64828 [lo=1185380879 high=1185380879 win=33304 modulator=0 wscale=1] [lo=1046638749 high=1046705357 win=33304 modulator=0 wscale=1] 4:4 A seq=1185380879 ack=1046638749 len=1448 ackskew=0 pkts=940:631 dir=out,fwd Nov 22 23:25:20 darkstar kernel: pf: State failure on: 1 | This means the server was trying to send 1448 bytes from th_seq 1185380879, but that violated the upper boundary of what pf thinks the client may accept. pf calculates this upper boundary from th_ack + th_win from the client. Let's look at what the client sent last: 23:25:20.203732 192.168.1.200.64828 > 192.168.1.10.20: . [tcp sum ok] 1046638749:1046638749(0) ack 1185318615 win 31132 (DF) [tos 0x8] (ttl 64, id 54682, len 64) Windows scaling is enabled, and both peers' scaling factors are 2^1, so the upper boundary advertised is th_ack 1185318615 + 2 * th_win 31132 == 1185380879 Why does the server try to send 1448 bytes from 1185380879 upwards? This is a violation of the client's window by the server, right? If you look at some prior packets from the client, from 23:25:20.145089 to 23:25:20.203732, it sent 33 ACKs with equal th_ack 1185314271 but different first SACK confirmations. We've looked at several examples like this, one common thing was that the last packet before the drop was always a zero-payload packet from the server to the client at exactly the client's advertised window border. Maybe that rings a bell for someone. Any ideas welcome :) Daniel From owner-freebsd-net@FreeBSD.ORG Wed Nov 24 09:07:44 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 646D816A4CE for ; Wed, 24 Nov 2004 09:07:44 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0720943D55 for ; Wed, 24 Nov 2004 09:07:44 +0000 (GMT) (envelope-from martin.eugen@gmail.com) Received: by wproxy.gmail.com with SMTP id 68so385045wra for ; Wed, 24 Nov 2004 01:07:26 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=qBV9oKsiuM9HaXy7kU1d16eoyWtfMSjHuybQFvAa3TGFnj3MI4SrGg0BitgKpj+oaw4bAN01qUT4l2QAF/f2lsk5zotZxZzttcXQFg1qe2/BR3BewyPxN1YhzzLyv6lr6ihI/1GL9tipaHPZA2gnD31jtr0MRLHjlJ/ZFQi97QU= Received: by 10.54.39.10 with SMTP id m10mr451029wrm; Wed, 24 Nov 2004 01:07:18 -0800 (PST) Received: by 10.54.11.25 with HTTP; Wed, 24 Nov 2004 01:07:17 -0800 (PST) Message-ID: <966ba91e041124010752591de6@mail.gmail.com> Date: Wed, 24 Nov 2004 11:07:17 +0200 From: Martin Eugen To: freebsd-net@freebsd.org In-Reply-To: <20041124014919.GA9396@scylla.towardex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <966ba91e04112301052fed8d6b@mail.gmail.com> <20041123183646.GB733@empiric.icir.org> <20041124014919.GA9396@scylla.towardex.com> Subject: Re: resolving routes externally X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Martin Eugen List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2004 09:07:44 -0000 To all: Thank you very much, I appreciate your help. From owner-freebsd-net@FreeBSD.ORG Wed Nov 24 09:51:50 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 30FB916A4CE for ; Wed, 24 Nov 2004 09:51:50 +0000 (GMT) Received: from SCBUKEUSXMRLA.uk.standardchartered.com (scbukeusxmrla.uk.standardchartered.com [195.224.105.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id E25A743D46 for ; Wed, 24 Nov 2004 09:51:48 +0000 (GMT) (envelope-from interscan.uk@uk.standardchartered.com) Received: from localhost (localhost [127.0.0.1])id JAA03956 for ; Wed, 24 Nov 2004 09:51:45 GMT From: interscan.uk@uk.standardchartered.com Message-Id: <200411240951.JAA03956@SCBUKEUSXMRLA.uk.standardchartered.com> To: freebsd-net@freebsd.org Date: Wed, 24 Nov 2004 09:51:45 -0000 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Virus Alert X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 24 Nov 2004 09:51:50 -0000 The mail message (file: auction_doc_ang.zip) you sent to contains a virus. (on SCBUKEUSXMRLA) From owner-freebsd-net@FreeBSD.ORG Wed Nov 24 16:33:54 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B5FA16A4EB; Wed, 24 Nov 2004 16:33:54 +0000 (GMT) Received: from r1a.corp.servercentral.net (exchange.corp.servercentral.net [66.225.247.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id C31CE43D3F; Wed, 24 Nov 2004 16:33:53 +0000 (GMT) (envelope-from martin.eugen@gmail.com) Received: from mail pickup service by r1a.corp.servercentral.net with Microsoft SMTPSVC; Wed, 24 Nov 2004 10:33:44 -0600 Received: from demandindustries.net ([161.58.224.124]) by r1a.corp.servercentral.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 24 Nov 2004 07:28:54 -0600 Received: from scanner.servercentral.net (scanner.servercentral.net [66.225.196.47]) by demandindustries.net (8.12.11/8.12.9) with ESMTP id iAODSsSO082138 for ; Wed, 24 Nov 2004 07:28:54 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by scanner.servercentral.net (Postfix) with ESMTP id 399CE8700AC for ; Wed, 24 Nov 2004 07:28:52 -0600 (CST) Received: from scanner.servercentral.net ([127.0.0.1]) by localhost (mb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04897-07 for ; Wed, 24 Nov 2004 07:28:50 -0600 (CST) Received: from mx2.freebsd.org (mx2.freebsd.org [216.136.204.119]) by scanner.servercentral.net (Postfix) with ESMTP id D46AF8700AB for ; Wed, 24 Nov 2004 07:28:50 -0600 (CST) Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 235EC55B95; Wed, 24 Nov 2004 13:28:38 +0000 (GMT) (envelope-from owner-freebsd-hackers@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 3B78F16A4DC; Wed, 24 Nov 2004 13:28:33 +0000 (GMT) Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D9CC16A4CE for ; Tue, 23 Nov 2004 16:26:28 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id CEA8F43D31 for ; Tue, 23 Nov 2004 16:26:27 +0000 (GMT) (envelope-from martin.eugen@gmail.com) Received: by wproxy.gmail.com with SMTP id 68so312645wra for ; Tue, 23 Nov 2004 08:26:26 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=Rwk8YBbuPg2TqddLrAMNIO6+Nw6VacKqWuLmaNdmPDptBrufwm7GI43lhedb1DJ6q0lohpqZMokTxijGhbd3SY7b81FimHoZhs+JuhCHAnhsmwEurfsYAVRzLeWQbBKcvZ/jksaDNbZHKxDcTl/rCh2MSxyomp0bGczdEh13HWY= Received: by 10.54.7.15 with SMTP id 15mr177162wrg; Tue, 23 Nov 2004 08:24:48 -0800 (PST) Received: by 10.54.11.25 with HTTP; Tue, 23 Nov 2004 08:24:48 -0800 (PST) Message-ID: <966ba91e04112308246616d1b8@mail.gmail.com> Date: Tue, 23 Nov 2004 18:24:48 +0200 From: Martin Eugen To: Jo?o Carlos Mendes Lu?s , freebsd-net@freebsd.org, freebsd-hackers@freebsd.org, Joerg Sonnenberger In-Reply-To: <20041123135236.GC1032@britannica.bec.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <966ba91e04112301052fed8d6b@mail.gmail.com> <41A33E4F.8060705@jonny.eng.br> <20041123135236.GC1032@britannica.bec.de> X-Mailman-Approved-At: Wed, 24 Nov 2004 13:26:03 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Sender: owner-freebsd-hackers@freebsd.org Errors-To: owner-freebsd-hackers@freebsd.org X-Virus-Scanned: by amavis for cervercentral.net X-OriginalArrivalTime: 24 Nov 2004 13:28:56.0739 (UTC) FILETIME=[8C969F30:01C4D229] Subject: Re: resolving routes externally X-BeenThere: freebsd-net@freebsd.org Reply-To: Martin Eugen List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2004 16:33:54 -0000 On Tue, 23 Nov 2004 14:52:36 +0100, Joerg Sonnenberger wrote: > On Tue, Nov 23, 2004 at 11:42:39AM -0200, Jo?o Carlos Mendes Lu?s wrote: > > >So I started to look at the ARP > > >code, but it of course lacks the kernel - userland communication > > >interface. I would appreciate any ideas about what would be the easier > > >way to implement such a thing where the kernel could wait (up to some > > >reasonable time-out) a userland daemon to install a new route. > > > > Why don't you simply discard the packet and wait for the next retry? > Because the network is not like the internet, packet error correction and so on is done at lower layers, I mean... if there are some packets that are equivalent to the TCP SYNs, the 'SYN' timeout in our case is in minutes (because it is believed the host or a link is down or something else that could take longer time to resolve). This is bad, because connections will be established within some minutes... > Or alternatively use an internal queue of limited size to keep track of > those packages. This is probably the only solution I can think of right now, but I think poking a queue at regular, short intervals seems to me quite expensive, isn't it? Or perhaps there could be a netgraph node that handles the queue and connects to the userland daemon... but this could make things much more complicated... ? > > Joerg > _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Nov 24 16:34:03 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0C98E16A4E0; Wed, 24 Nov 2004 16:34:03 +0000 (GMT) Received: from r1a.corp.servercentral.net (exchange.corp.servercentral.net [66.225.247.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8838E43D1D; Wed, 24 Nov 2004 16:34:02 +0000 (GMT) (envelope-from haesu@towardex.com) Received: from mail pickup service by r1a.corp.servercentral.net with Microsoft SMTPSVC; Wed, 24 Nov 2004 10:33:56 -0600 Received: from demandindustries.net ([161.58.224.124]) by r1a.corp.servercentral.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 24 Nov 2004 07:29:32 -0600 Received: from scanner.servercentral.net (scanner.servercentral.net [66.225.196.47]) by demandindustries.net (8.12.11/8.12.9) with ESMTP id iAODTWRu082295 for ; Wed, 24 Nov 2004 07:29:32 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by scanner.servercentral.net (Postfix) with ESMTP id 1735E8700AC for ; Wed, 24 Nov 2004 07:29:30 -0600 (CST) Received: from scanner.servercentral.net ([127.0.0.1]) by localhost (mb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04897-08 for ; Wed, 24 Nov 2004 07:29:28 -0600 (CST) Received: from mx2.freebsd.org (mx2.freebsd.org [216.136.204.119]) by scanner.servercentral.net (Postfix) with ESMTP id BDB188700AB for ; Wed, 24 Nov 2004 07:29:28 -0600 (CST) Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 5454957B32; Wed, 24 Nov 2004 13:28:52 +0000 (GMT) (envelope-from owner-freebsd-hackers@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id ABF0816A559; Wed, 24 Nov 2004 13:28:40 +0000 (GMT) Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E92F416A50D; Wed, 24 Nov 2004 01:49:20 +0000 (GMT) Received: from mx01.bos.ma.towardex.com (mx01.bos.ma.towardex.com [65.124.16.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3DD4343D2D; Wed, 24 Nov 2004 01:49:20 +0000 (GMT) (envelope-from haesu@mx01.bos.ma.towardex.com) Received: by mx01.bos.ma.towardex.com (TowardEX ESMTP 3.0p11_DAKN, from userid 1001) id B12B82F93F; Tue, 23 Nov 2004 20:49:19 -0500 (EST) Date: Tue, 23 Nov 2004 20:49:19 -0500 From: James To: Martin Eugen , freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Message-ID: <20041124014919.GA9396@scylla.towardex.com> References: <966ba91e04112301052fed8d6b@mail.gmail.com> <20041123183646.GB733@empiric.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041123183646.GB733@empiric.icir.org> User-Agent: Mutt/1.4.1i X-Mailman-Approved-At: Wed, 24 Nov 2004 13:26:03 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Sender: owner-freebsd-hackers@freebsd.org Errors-To: owner-freebsd-hackers@freebsd.org X-Virus-Scanned: by amavis for cervercentral.net X-OriginalArrivalTime: 24 Nov 2004 13:29:32.0941 (UTC) FILETIME=[A22A9BD0:01C4D229] Subject: Re: resolving routes externally X-BeenThere: freebsd-net@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2004 16:34:03 -0000 On Tue, Nov 23, 2004 at 10:36:46AM -0800, Bruce M Simpson wrote: [ snip ] > > If I understand correctly, you want the kernel to queue packets until > layer 2 address resolution is complete. Right now we don't do this. If > there is no route to a destination, packets will be dropped. The KAME ipv6 code does this for v6 neighbor discovery (which is not arp yes..). Martin, nd6_output() in netinet6/nd6.c should be helpful if you want to look. RFC requires routers to queue packets up during layer 2 resolution process (which is why in IPv6 when destination host is down you see !A with huge latency -- i.e. 3400ms due to queueing by the router[1]). If you are queueing however, make sure you use locking or check for any safety mechanisms as you may corrupt mbuf's that are flooding inbound. BTW Martin,, what is the purpose of this intent? Just curiousity of mine. [1]: Some hardware/ASIC based routers violate the RFC unfortunately. It's a little harder to implement there (see J vendor) -J -- James Jun TowardEX Technologies, Inc. Technical Lead Boston IPv4/IPv6 Web Hosting, Colocation and james@towardex.com Network design/consulting & configuration services cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Nov 24 16:34:08 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 671DF16A4F0; Wed, 24 Nov 2004 16:34:08 +0000 (GMT) Received: from r1a.corp.servercentral.net (exchange.corp.servercentral.net [66.225.247.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 00EAE43D4C; Wed, 24 Nov 2004 16:34:08 +0000 (GMT) (envelope-from haesu@towardex.com) Received: from mail pickup service by r1a.corp.servercentral.net with Microsoft SMTPSVC; Wed, 24 Nov 2004 10:34:00 -0600 Received: from demandindustries.net ([161.58.224.124]) by r1a.corp.servercentral.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 24 Nov 2004 07:29:55 -0600 Received: from scanner.servercentral.net (scanner.servercentral.net [66.225.196.47]) by demandindustries.net (8.12.11/8.12.9) with ESMTP id iAODTsUq082374 for ; Wed, 24 Nov 2004 07:29:55 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by scanner.servercentral.net (Postfix) with ESMTP id BA91D8700AC for ; Wed, 24 Nov 2004 07:29:51 -0600 (CST) Received: from scanner.servercentral.net ([127.0.0.1]) by localhost (mb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04889-10 for ; Wed, 24 Nov 2004 07:29:50 -0600 (CST) Received: from mx2.freebsd.org (mx2.freebsd.org [216.136.204.119]) by scanner.servercentral.net (Postfix) with ESMTP id 921918700AB for ; Wed, 24 Nov 2004 07:29:50 -0600 (CST) Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 36F4656AE6; Wed, 24 Nov 2004 13:29:00 +0000 (GMT) (envelope-from owner-freebsd-hackers@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 9B11716A520; Wed, 24 Nov 2004 13:28:45 +0000 (GMT) Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D4F1016A4CE; Wed, 24 Nov 2004 01:51:56 +0000 (GMT) Received: from mx01.bos.ma.towardex.com (mx01.bos.ma.towardex.com [65.124.16.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7711643D49; Wed, 24 Nov 2004 01:51:56 +0000 (GMT) (envelope-from haesu@mx01.bos.ma.towardex.com) Received: by mx01.bos.ma.towardex.com (TowardEX ESMTP 3.0p11_DAKN, from userid 1001) id 4AA5C2F947; Tue, 23 Nov 2004 20:51:56 -0500 (EST) Date: Tue, 23 Nov 2004 20:51:56 -0500 From: James To: Martin Eugen , freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Message-ID: <20041124015156.GA33719@scylla.towardex.com> References: <966ba91e04112301052fed8d6b@mail.gmail.com> <20041123183646.GB733@empiric.icir.org> <20041124014919.GA9396@scylla.towardex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041124014919.GA9396@scylla.towardex.com> User-Agent: Mutt/1.4.1i X-Mailman-Approved-At: Wed, 24 Nov 2004 13:26:03 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Sender: owner-freebsd-hackers@freebsd.org Errors-To: owner-freebsd-hackers@freebsd.org X-Virus-Scanned: by amavis for cervercentral.net X-OriginalArrivalTime: 24 Nov 2004 13:29:57.0254 (UTC) FILETIME=[B0A87A60:01C4D229] Subject: Re: resolving routes externally X-BeenThere: freebsd-net@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2004 16:34:08 -0000 On Tue, Nov 23, 2004 at 08:49:19PM -0500, James wrote: > On Tue, Nov 23, 2004 at 10:36:46AM -0800, Bruce M Simpson wrote: > [ snip ] > > > > If I understand correctly, you want the kernel to queue packets until > > layer 2 address resolution is complete. Right now we don't do this. If > > there is no route to a destination, packets will be dropped. > > The KAME ipv6 code does this for v6 neighbor discovery (which is not > arp yes..). Martin, nd6_output() in netinet6/nd6.c should be helpful > if you want to look. RFC requires routers to queue packets up during > layer 2 resolution process (which is why in IPv6 when destination > host is down you see !A with huge latency -- i.e. 3400ms due to > queueing by the router[1]). Err my bad. I meant 'latest packet' (like in arp resolution) -J -- James Jun TowardEX Technologies, Inc. Technical Lead Boston IPv4/IPv6 Web Hosting, Colocation and james@towardex.com Network design/consulting & configuration services cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Nov 24 18:57:05 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E85D016A4CE for ; Wed, 24 Nov 2004 18:57:05 +0000 (GMT) Received: from mail2.dbitech.ca (radius.wavefire.com [64.141.13.252]) by mx1.FreeBSD.org (Postfix) with SMTP id 31DDA43D5A for ; Wed, 24 Nov 2004 18:57:05 +0000 (GMT) (envelope-from darcy@wavefire.com) Received: (qmail 25437 invoked from network); 24 Nov 2004 20:00:47 -0000 Received: from dbitech.wavefire.com (HELO ?64.141.15.253?) (darcy@64.141.15.253) by radius.wavefire.com with SMTP; 24 Nov 2004 20:00:47 -0000 From: Darcy Buskermolen Organization: Wavefire Technologies Corp. To: freebsd-net@freebsd.org Date: Wed, 24 Nov 2004 10:57:03 -0800 User-Agent: KMail/1.6.2 References: <20040520162919.GA1971@straylight.m.ringlet.net> <20040520171833.GA22494@Odin.AC.HMC.Edu> <20040521070422.GA1292@straylight.m.ringlet.net> In-Reply-To: <20040521070422.GA1292@straylight.m.ringlet.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200411241057.03166.darcy@wavefire.com> cc: Peter Pentchev Subject: Re: [RFC] ifconfig: match by link-level address X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 24 Nov 2004 18:57:06 -0000 On May 21, 2004 12:04 am, Peter Pentchev wrote: > On Thu, May 20, 2004 at 10:18:38AM -0700, Brooks Davis wrote: > > On Thu, May 20, 2004 at 07:29:19PM +0300, Peter Pentchev wrote: > > > Hi, > > > > > > I found out recently that the Linux (or at least recent RedHat) startup > > > scripts could be configured to not bring up an Ethernet interface > > > unless it has a specified MAC address. This, combined with the > > > wonderful interface renaming functionality recently committed to > > > -CURRENT, led me to the idea of interface renaming on boot-up, by > > > hardware addresses - something like 'I don't care how you detected this > > > network card, or how many others like it are there, but the card with > > > MAC address > > > 00:03:0d:08:dc:a7 will be known as sis0int from now on'. > > > > > > The main missing piece was the ability to find an interface by MAC > > > address; hence the attached patch, also available at > > > http://www.ringlet.net/~roam/bsd-patches/src5/sbin-ifconfig-hwmatch.pat > > >ch > > > http://people.FreeBSD.org/~roam/bsd-patches/src5/sbin-ifconfig-hwmatch. > > >patch > > > > > > It teaches ifconfig(8) to treat interface "names" beginning with 'hw-' > > > as link-level addresses; ifconfig tries to find an interface with this > > > address and behaves as if its name was specified on the command line: > > > > > > [roam@straylight ~/fbsd/r/src/sbin/ifconfig]> ./ifconfig > > > hw-00:03:0d:08:dc:a7 sis0: > > > flags=8843 mtu 1500 > > > options=8 > > > inet 10.0.8.129 netmask 0xffff0000 broadcast 10.0.255.255 > > > inet 192.168.1.13 netmask 0xffffff00 broadcast 192.168.1.255 > > > ether 00:03:0d:08:dc:a7 > > > media: Ethernet autoselect (100baseTX ) > > > status: active > > > [roam@straylight ~/fbsd/r/src/sbin/ifconfig]> > > > > > > This could be the first step towards teaching rc.conf about something > > > like network_interfaces_rename="hw-00:03:0d:08:dc:a7 sis0int" > > > > > > I had initially written my own function for parsing the user-supplied > > > address into a sequence of bytes instead of using ether_aton(); it > > > would have the advantage of being able to specify 'hw-' to match lo0's > > > empty link-level "address". However, the odds of somebody actually > > > wishing to rename lo0 don't seem to be so high :) > > > > I don't really like the idea of adding magic values to the interface > > namespace that only work with ifconfig. If you want ifconfig to match > > the lladdr, I'd suggest adding a flag that means match interface by > > address instead of by name. That would be a fairly simple change to > > your patch and seems like a potentialy useful feature. > > Agreed, I don't like the magic hw- too much either, but.. see below for > more comments on this and interface renaming on startup. > > > FWIW, I've talked to Warner about automaticly renaming interfaces based > > on things like their MAC address or their PCI slot and we think devd > > will eventually be the place to do this. We're probably going to have > > to rethink interface configuration for this to work though. > > Well, it turned out that adding basic interface renaming support to our > startup scripts wasn't all that hard - the attached patch, also at > http://www.ringlet.net/~roam/bsd-patches/src5/etc-iface-rename.patch > http://people.FreeBSD.org/~roam/bsd-patches/src5/etc-iface-rename.patch > seems to work for both 'sis0 ethlocal xl0 ethext' and > 'hw-00:03:0d:08:dc:a7 ethlocal', since it just passes the interface name > to ifconfig(8). > > If the link-level address matching should be done with a separate > ifconfig(8) option, the interface renaming may need to be split into two > stages controlled by two configuration variables - one specifying the > 'source' interface by name, the other one by address, with the latter > code using the new ifconfig option. > > Of course, this still leaves a problem with specifying the address for > an interface that has not yet been 'found' - after all, we can't > ifmaybeload() a driver on just the link-level address of the card. This > is a case when devd might be a better solution indeed. However, I don't > think that people who use interface renaming will depend on the system > automatically discovering the *types* of network cards: if you know the > MAC address of the card, you'll probably know just what brand and model > it is, too :) > > G'luck, > Peter Sorry for the full quote, but it's been a while since this topic was in the discusions. What was the final outcome of rc.conf based interface renaming? I can't find any mention of it in rc.conf(5) man pages or other documentation sources. -- Darcy Buskermolen Wavefire Technologies Corp. ph: 250.717.0200 fx: 250.763.1759 http://www.wavefire.com From owner-freebsd-net@FreeBSD.ORG Wed Nov 24 23:32:01 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B6D816A4CE; Wed, 24 Nov 2004 23:32:01 +0000 (GMT) Received: from britannica.bec.de (wlan034068.uni-rostock.de [139.30.34.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id D055A43D48; Wed, 24 Nov 2004 23:32:00 +0000 (GMT) (envelope-from joerg@britannica.bec.de) Received: by britannica.bec.de (Postfix, from userid 1001) id 437B82A2F; Tue, 23 Nov 2004 17:57:02 +0100 (CET) Date: Tue, 23 Nov 2004 17:57:02 +0100 From: Joerg Sonnenberger To: Martin Eugen Message-ID: <20041123165702.GD850@britannica.bec.de> Mail-Followup-To: Martin Eugen , Jo?o Carlos Mendes Lu?s , freebsd-net@freebsd.org, freebsd-hackers@freebsd.org References: <966ba91e04112301052fed8d6b@mail.gmail.com> <41A33E4F.8060705@jonny.eng.br> <20041123135236.GC1032@britannica.bec.de> <966ba91e04112308246616d1b8@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <966ba91e04112308246616d1b8@mail.gmail.com> User-Agent: Mutt/1.5.6i cc: freebsd-net@freebsd.org cc: Jo?o Carlos Mendes Lu?s cc: freebsd-hackers@freebsd.org Subject: Re: resolving routes externally X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 24 Nov 2004 23:32:01 -0000 On Tue, Nov 23, 2004 at 06:24:48PM +0200, Martin Eugen wrote: > > Or alternatively use an internal queue of limited size to keep track of > > those packages. > > This is probably the only solution I can think of right now, but I > think poking a queue at regular, short intervals seems to me quite > expensive, isn't it? Or perhaps there could be a netgraph node that > handles the queue and connects to the userland daemon... but this > could make things much more complicated... ? Do you want to keep the whole name lookup in userland or query a cache like ARP is doing and fallback to the userland daemon if no entry exists in the cache? In the later case, you could just reinsert the package into the global queue after adding the cache entry. The cache handling itself could be done via normal routing messages or other communication means like polling a special device. Joerg From owner-freebsd-net@FreeBSD.ORG Thu Nov 25 14:06:48 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 16CFA16A4CE for ; Thu, 25 Nov 2004 14:06:48 +0000 (GMT) Received: from relay.bestcom.ru (relay.bestcom.ru [217.72.144.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D43C43D4C for ; Thu, 25 Nov 2004 14:06:47 +0000 (GMT) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (root@cell.sick.ru [217.72.144.68]) by relay.bestcom.ru (8.13.1/8.12.9) with ESMTP id iAPE6gaj078553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 25 Nov 2004 17:06:43 +0300 (MSK) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id iAPE6f4Q078342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 25 Nov 2004 17:06:42 +0300 (MSK) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id iAPE6fFi078341 for net@freebsd.org; Thu, 25 Nov 2004 17:06:41 +0300 (MSK) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Thu, 25 Nov 2004 17:06:41 +0300 From: Gleb Smirnoff To: net@freebsd.org Message-ID: <20041125140641.GA78210@cell.sick.ru> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Kj7319i9nmIyA2yE" Content-Disposition: inline User-Agent: Mutt/1.5.6i X-Virus-Scanned: clamd / ClamAV version devel-20041013, clamav-milter version 0.75l on 127.0.0.1 X-Virus-Status: Clean Subject: route cacheing for gif(4) should be optional X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 25 Nov 2004 14:06:48 -0000 --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Back to this problem: http://freebsd.rambler.ru/bsdmail/freebsd-net_2004/msg01305.html I've found two more people who dislike this feature of gif(4). So I'd like to make it optional. We already have LINK2 flag removing sourceroute filter from gif(4), which is commonly used in asymmetrically routed networks. I suggest to use this flag also for disabling route cacheing, since asymmetricity often appears in dynamically routed networks, and if one runs dynamic routing, he probably wants to remove route cacheing, too. Any objections? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=koi8-r Content-Disposition: attachment; filename="in_gif.c.diff" Index: in_gif.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/in_gif.c,v retrieving revision 1.26 diff -u -r1.26 in_gif.c --- in_gif.c 18 Jun 2004 02:04:07 -0000 1.26 +++ in_gif.c 25 Nov 2004 17:16:14 -0000 @@ -209,6 +209,12 @@ } error = ip_output(m, NULL, &sc->gif_ro, 0, NULL, NULL); + + if ((sc->gif_if.if_flags & IFF_LINK2) != 0) { + RTFREE(sc->gif_ro.ro_rt); + sc->gif_ro.ro_rt = NULL; + } + return (error); } --Kj7319i9nmIyA2yE-- From owner-freebsd-net@FreeBSD.ORG Thu Nov 25 17:07:20 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 60BB316A4CE for ; Thu, 25 Nov 2004 17:07:20 +0000 (GMT) Received: from mail.otel.net (gw3.OTEL.net [212.36.8.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1AB6243D64 for ; Thu, 25 Nov 2004 17:07:20 +0000 (GMT) (envelope-from tbyte@OTEL.net) Received: from dragon.otel.net ([212.36.8.135]) by mail.otel.net with esmtp (Exim 4.30; FreeBSD) id 1CXN5S-000KhK-6o; Thu, 25 Nov 2004 19:07:18 +0200 Message-ID: <41A61151.60704@OTEL.net> Date: Thu, 25 Nov 2004 19:07:29 +0200 From: Iasen Kostov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.3) Gecko/20041117 X-Accept-Language: bg, en-us, en MIME-Version: 1.0 To: Iasen Kostov References: <41A2E23D.304@OTEL.net> In-Reply-To: <41A2E23D.304@OTEL.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: bridge and maximum MAC entries X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 25 Nov 2004 17:07:20 -0000 Iasen Kostov wrote: > Hi, > if I understand next code correctly maximum number of MACs is bound to > maximum number of ports ?!?. Why is that ? > code from net/bridge.c: > c[n_clusters].my_macs = (struct bdg_addr *) > malloc(BDG_MAX_PORTS * sizeof(struct bdg_addr), > M_IFADDR, M_NOWAIT | M_ZERO); > > The best will be to allocate MAC entries dynamically. But there should > be at least another definition for > maximum MACs for port something like BDG_MAX_MACS ... which could be > set at compile time because the current > situation doesn't make sense at least for me or possibly I > misunderstand something. > > _______________________________________________ > 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" > Sorry for the noise. I really misunderstud things here. From owner-freebsd-net@FreeBSD.ORG Thu Nov 25 17:19:39 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E84C116A4CE for ; Thu, 25 Nov 2004 17:19:39 +0000 (GMT) Received: from mail.otel.net (gw3.OTEL.net [212.36.8.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9DCEB43D5A for ; Thu, 25 Nov 2004 17:19:39 +0000 (GMT) (envelope-from tbyte@OTEL.net) Received: from dragon.otel.net ([212.36.8.135]) by mail.otel.net with esmtp (Exim 4.30; FreeBSD) id 1CXNHM-000KrZ-Ei for freebsd-net@freebsd.org; Thu, 25 Nov 2004 19:19:36 +0200 Message-ID: <41A61434.3000700@OTEL.net> Date: Thu, 25 Nov 2004 19:19:48 +0200 From: Iasen Kostov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.3) Gecko/20041117 X-Accept-Language: bg, en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: multipart/mixed; boundary="------------010401070208000605010608" Subject: netstat patch for bridge stats X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 25 Nov 2004 17:19:40 -0000 This is a multi-part message in MIME format. --------------010401070208000605010608 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi, this is a small patch which will make bridge stats look nicer (or at least look some way :) ), because this is current situation: -- Bridging statistics (bdg) -- Name In Out Forward Drop Bcast Mcast Local Unknown vlan5:1 709303965749269168687899969 123884 13908828 3236774 10765 4123745 vlan904:1 759386539711221922749370414 447736 6319135 177242 49244 3022768 It is really a mess :) and does not looks like other protocol stats do. And this is how it looks after the patch: -- Bridging statistics (bdg) -- vlan5:1: 721198379 total packets recieved 762906756 total packets sent 699495544 forwarded 124082 dropped 14073971 broadcasts 3251664 multicasts 10784 for local interface 4242334 unknown packets vlan904:1: 773320391 total packets recieved 723117599 total packets sent 763146879 forwarded 447736 dropped 6424601 broadcasts 179482 multicasts 49248 for local interface 3072445 unknown packets I'll be happy to see comments about this. regards. --------------010401070208000605010608 Content-Type: text/plain; name="if.c.diff" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="if.c.diff" LS0tIHVzci5iaW4vbmV0c3RhdC9pZi5vcmcuYwlUaHUgTm92IDI1IDE4OjEzOjM0IDIwMDQK KysrIHVzci5iaW4vbmV0c3RhdC9pZi5jCVRodSBOb3YgMjUgMTg6NTk6MjkgMjAwNApAQCAt MTAxLDExICsxMDEsMTIgQEAKIAliZGdfZG9uZSA9IDE7CiAjZW5kaWYKICAgICBwcmludGYo Ii0tIEJyaWRnaW5nIHN0YXRpc3RpY3MgKCVzKSAtLVxuIiwgbmFtZSkgOwotICAgIHByaW50 ZigKLSJOYW1lICAgICAgICAgIEluICAgICAgT3V0ICBGb3J3YXJkICAgICBEcm9wICAgIEJj YXN0ICAgIE1jYXN0ICAgIExvY2FsICBVbmtub3duXG4iKTsKICAgICBmb3IgKGkgPSAwIDsg aSA8IDE2IDsgaSsrKSB7CiAJaWYgKHMuc1tpXS5uYW1lWzBdKQotCXByaW50ZigiJS02cyAl OWxkJTlsZCU5bGQlOWxkJTlsZCU5bGQlOWxkJTlsZFxuIiwKKwlwcmludGYoIiUtNnM6XG5c dCVsZCB0b3RhbCBwYWNrZXRzIHJlY2lldmVkXG5cdCVsZCB0b3RhbCBwYWNrZXRzIHNlbnRc blx0IiBcCisJICAgICAgICIlbGQgZm9yd2FyZGVkXG5cdCVsZCBkcm9wcGVkXG5cdCIgXAor CSAgICAgICAiJWxkIGJyb2FkY2FzdHNcblx0JWxkIG11bHRpY2FzdHNcblx0JWxkIGZvciBs b2NhbCBpbnRlcmZhY2Vcblx0IiBcCisJICAgICAgICIlbGQgdW5rbm93biBwYWNrZXRzXG4i LAogCSAgcy5zW2ldLm5hbWUsCiAJICBzLnNbaV0ucF9pblsoaW50KUJER19JTl0sCiAJICBz LnNbaV0ucF9pblsoaW50KUJER19PVVRdLAo= --------------010401070208000605010608-- From owner-freebsd-net@FreeBSD.ORG Thu Nov 25 19:18:50 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D8C1716A4CE for ; Thu, 25 Nov 2004 19:18:50 +0000 (GMT) Received: from manian.sics.se (manian.sics.se [193.10.66.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id D4C1943D5E for ; Thu, 25 Nov 2004 19:18:49 +0000 (GMT) (envelope-from bg@sics.se) Received: from manian.sics.se (localhost [127.0.0.1]) by manian.sics.se (8.13.1/8.13.1) with SMTP id iAPJICRE017479; Thu, 25 Nov 2004 20:18:12 +0100 (CET) (envelope-from bg@sics.se) Date: Thu, 25 Nov 2004 20:18:12 +0100 From: =?ISO-8859-1?Q?Bj=F6rn_Gr=F6nvall?= To: freebsd-net@FreeBSD.org Message-ID: <20041125201812.609e50f9@manian.sics.se> Organization: SICS X-Mailer: Sylpheed-Claws 0.9.12b (GTK+ 1.2.10; i386-portbld-freebsd5.3) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: kris@FreeBSD.org cc: alfred@FreeBSD.org cc: dnelson@allantgroup.com cc: lennox@cs.columbia.edu Subject: Linux compatible rpc.lockd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 25 Nov 2004 19:18:51 -0000 Hi, I have made a patch to address PR kern/56461, in short the patch provides two different options to be compatible with Linux lockd implementations. It can also serve as a basis for a future more robust rpc.lockd. The new options to rpc.lockd are: -s The -s option makes the client portion of rpc.lockd use synchro- nous RPC calls rather than the corresponding asynchronous proce- dures. For instance one NLM_LOCK call is used instead of two asynchronous NLM_LOCK_MSG and NLM_LOCK_RES calls. Locks origi- nated locally will use short cookies (see the -8 option below) but will not be susceptible to pid recycling problems. -8 The -8 option allows for usage of short 8 byte client cookies compatible with limitations of Linux servers. This option only effects locks of local origin and will not effect any of the rpc.lockd server functionality. Short cookies are susceptible to pid recycling problems and are thus turned off by default. When rebuilding, be careful with the copy of nfs_lock.h in /usr/include/nfsclient/. If you would like to enable this patch please make this change to /etc/rc.conf: --- /etc/rc.conf~ Thu Nov 25 19:55:08 2004 +++ /etc/rc.conf Thu Nov 25 19:57:01 2004 @@ -19,6 +19,7 @@ nfs_access_cache="" rpc_statd_enable="YES" rpc_lockd_enable="YES" +lockd_flags="-s" amd_enable="YES" Cheers, /b diff -u sys/nfsclient/nfs_lock.c sys/nfsclient.new/nfs_lock.c --- sys/nfsclient/nfs_lock.c Fri Nov 14 21:54:08 2003 +++ sys/nfsclient.new/nfs_lock.c Tue Nov 23 15:27:24 2004 @@ -260,6 +260,10 @@ if ((targetp = pfind(ansp->la_msg_ident.pid)) == NULL) return (ESRCH); + /* Fake pid_start for Linux compat (sic.). */ + if (!timevalisset(&ansp->la_msg_ident.pid_start)) + ansp->la_msg_ident.pid_start = targetp->p_nlminfo->pid_start; + /* verify the pid hasn't been reused (if we can), and it isn't waiting * for an answer from a more recent request. We return an EPIPE if * the match fails, because we've already used ESRCH above, and this diff -u sys/nfsclient/nfs_lock.h sys/nfsclient.new/nfs_lock.h --- sys/nfsclient/nfs_lock.h Thu Aug 15 23:52:22 2002 +++ sys/nfsclient.new/nfs_lock.h Tue Nov 23 16:11:46 2004 @@ -51,14 +51,17 @@ * a particular message to lockd. A sequence number is used to differentiate * multiple messages from the same process. A process start time is used to * detect the unlikely, but possible, event of the recycling of a pid. + * + * The first eight bytes of this struct may be used to generate short + * client cookies that are not robust to pid recycling. */ struct lockd_msg_ident { - pid_t pid; /* The process ID. */ + int32_t msg_seq; /* Sequence number of message */ + pid_t pid; /* The process ID. */ struct timeval pid_start; /* Start time of process id */ - int msg_seq; /* Sequence number of message */ }; -#define LOCKD_MSG_VERSION 2 +#define LOCKD_MSG_VERSION 3 /* * The structure that the kernel hands us for each lock request. @@ -76,7 +79,7 @@ u_int8_t lm_fh[NFS_SMALLFH];/* The file handle. */ } LOCKD_MSG; -#define LOCKD_ANS_VERSION 1 +#define LOCKD_ANS_VERSION 3 struct lockd_ans { int la_vers; diff -u usr.sbin/rpc.lockd/kern.c usr.sbin/rpc.lockd.new/kern.c --- usr.sbin/rpc.lockd/kern.c Sun Oct 26 07:10:44 2003 +++ usr.sbin/rpc.lockd.new/kern.c Thu Nov 25 17:55:55 2004 @@ -58,6 +58,9 @@ #include "lockd_lock.h" #include +#define MINIMAL_CLIENT_COOKIE_LEN \ + ((size_t) &((struct lockd_msg_ident *)0)->pid_start) + #define DAEMON_USERNAME "daemon" #define nfslockdans(_v, _ansp) \ @@ -81,6 +84,11 @@ int unlock_request(LOCKD_MSG *); /* + * The cookie size we use by default. + */ +int client_cookie_len = sizeof(struct lockd_msg_ident); + +/* * will break because fifo needs to be repopened when EOF'd */ #define lockd_seteuid(uid) seteuid(uid) @@ -124,6 +132,13 @@ mode_t old_umask; struct passwd *pw; + if (client_cookie_len != sizeof(struct lockd_msg_ident) && + client_cookie_len != MINIMAL_CLIENT_COOKIE_LEN) { + syslog(LOG_ERR, "disable -8 switch"); + client_cookie_len = sizeof(struct lockd_msg_ident); + } + + /* Recreate the NLM fifo. */ (void)unlink(_PATH_LCKFIFO); old_umask = umask(S_IXGRP|S_IXOTH); @@ -261,7 +276,24 @@ { CLIENT *cli; struct timeval timeout = {0, 0}; /* No timeout, no response. */ - char dummy; + int nlm_version; + xdrproc_t xdrargs; + union { + nlm_testargs arg; + nlm4_testargs arg4; + } arg ; + xdrproc_t xdrres; + union { + char dummy; + nlm_testres res; + nlm4_testres res4; + } res; + int cookie_len; + + if (asynchronous_client_rpc) + cookie_len = client_cookie_len; /* Long cookies */ + else + cookie_len = MINIMAL_CLIENT_COOKIE_LEN; if (d_calls) syslog(LOG_DEBUG, "test request: %s: %s to %s", @@ -270,53 +302,65 @@ from_addr((struct sockaddr *)&msg->lm_addr)); if (msg->lm_nfsv3) { - struct nlm4_testargs arg4; - - arg4.cookie.n_bytes = (char *)&msg->lm_msg_ident; - arg4.cookie.n_len = sizeof(msg->lm_msg_ident); - arg4.exclusive = msg->lm_fl.l_type == F_WRLCK ? 1 : 0; - arg4.alock.caller_name = hostname; - arg4.alock.fh.n_bytes = (char *)&msg->lm_fh; - arg4.alock.fh.n_len = msg->lm_fh_len; - arg4.alock.oh.n_bytes = (char *)&owner; - arg4.alock.oh.n_len = sizeof(owner); - arg4.alock.svid = msg->lm_msg_ident.pid; - arg4.alock.l_offset = msg->lm_fl.l_start; - arg4.alock.l_len = msg->lm_fl.l_len; - - if ((cli = get_client( - (struct sockaddr *)&msg->lm_addr, - NLM_VERS4)) == NULL) - return (1); - - set_auth(cli, &msg->lm_cred); - (void)clnt_call(cli, NLM_TEST_MSG, - (xdrproc_t)xdr_nlm4_testargs, &arg4, - (xdrproc_t)xdr_void, &dummy, timeout); + nlm_version = NLM_VERS4; + xdrargs = (xdrproc_t)xdr_nlm4_testargs; + xdrres = (xdrproc_t)xdr_nlm4_testres; + arg.arg4.cookie.n_bytes = (char *)&msg->lm_msg_ident; + arg.arg4.cookie.n_len = cookie_len; + arg.arg4.exclusive = msg->lm_fl.l_type == F_WRLCK ? 1 : 0; + arg.arg4.alock.caller_name = hostname; + arg.arg4.alock.fh.n_bytes = (char *)&msg->lm_fh; + arg.arg4.alock.fh.n_len = msg->lm_fh_len; + arg.arg4.alock.oh.n_bytes = (char *)&owner; + arg.arg4.alock.oh.n_len = sizeof(owner); + arg.arg4.alock.svid = msg->lm_msg_ident.pid; + arg.arg4.alock.l_offset = msg->lm_fl.l_start; + arg.arg4.alock.l_len = msg->lm_fl.l_len; } else { - struct nlm_testargs arg; + nlm_version = NLM_VERS ; + xdrargs = (xdrproc_t)xdr_nlm_testargs; + xdrres = (xdrproc_t)xdr_nlm_testres; + arg.arg.cookie.n_bytes = (char *)&msg->lm_msg_ident; + arg.arg.cookie.n_len = cookie_len; + arg.arg.exclusive = msg->lm_fl.l_type == F_WRLCK ? 1 : 0; + arg.arg.alock.caller_name = hostname; + arg.arg.alock.fh.n_bytes = (char *)&msg->lm_fh; + arg.arg.alock.fh.n_len = msg->lm_fh_len; + arg.arg.alock.oh.n_bytes = (char *)&owner; + arg.arg.alock.oh.n_len = sizeof(owner); + arg.arg.alock.svid = msg->lm_msg_ident.pid; + arg.arg.alock.l_offset = msg->lm_fl.l_start; + arg.arg.alock.l_len = msg->lm_fl.l_len; + } - arg.cookie.n_bytes = (char *)&msg->lm_msg_ident; - arg.cookie.n_len = sizeof(msg->lm_msg_ident); - arg.exclusive = msg->lm_fl.l_type == F_WRLCK ? 1 : 0; - arg.alock.caller_name = hostname; - arg.alock.fh.n_bytes = (char *)&msg->lm_fh; - arg.alock.fh.n_len = msg->lm_fh_len; - arg.alock.oh.n_bytes = (char *)&owner; - arg.alock.oh.n_len = sizeof(owner); - arg.alock.svid = msg->lm_msg_ident.pid; - arg.alock.l_offset = msg->lm_fl.l_start; - arg.alock.l_len = msg->lm_fl.l_len; - - if ((cli = get_client( - (struct sockaddr *)&msg->lm_addr, - NLM_VERS)) == NULL) - return (1); - - set_auth(cli, &msg->lm_cred); - (void)clnt_call(cli, NLM_TEST_MSG, - (xdrproc_t)xdr_nlm_testargs, &arg, - (xdrproc_t)xdr_void, &dummy, timeout); + cli = get_client((struct sockaddr *)&msg->lm_addr, nlm_version); + if (cli == NULL) + return (1); + + set_auth(cli, &msg->lm_cred); + if (asynchronous_client_rpc) + clnt_call(cli, NLM_TEST_MSG, + xdrargs, &arg, (xdrproc_t)xdr_void, &res, timeout); + else { + enum clnt_stat st; + timeout.tv_sec = synchronous_client_rpc_timeout; + bzero(&res, sizeof(res)); + st = clnt_call(cli, NLM_TEST, + xdrargs, &arg, xdrres, &res, timeout); + if (st != RPC_SUCCESS) { + expire_client(cli); + syslog(LOG_ERR, "NLM_TEST %s, server %s", + clnt_sperrno(st), + from_addr((struct sockaddr *)&msg->lm_addr)); + } else { + touch_client(cli); + lock_answer(msg->lm_msg_ident.pid, + &res.res.cookie, + res.res.stat.stat, /* union XXX */ + &res.res.stat.nlm_testrply_u.holder.svid, + nlm_version); + } + xdr_free(xdrres, &res); } return (0); } @@ -329,10 +373,25 @@ lock_request(LOCKD_MSG *msg) { CLIENT *cli; - struct nlm4_lockargs arg4; - struct nlm_lockargs arg; struct timeval timeout = {0, 0}; /* No timeout, no response. */ - char dummy; + int nlm_version; + xdrproc_t xdrargs; + union { + nlm_lockargs arg; + nlm4_lockargs arg4; + } arg; + xdrproc_t xdrres; + union { + char dummy; + nlm_res res; + nlm4_res res4; + } res; + int cookie_len; + + if (asynchronous_client_rpc) + cookie_len = client_cookie_len; /* Long cookies */ + else + cookie_len = MINIMAL_CLIENT_COOKIE_LEN; if (d_calls) syslog(LOG_DEBUG, "lock request: %s: %s to %s", @@ -341,55 +400,72 @@ from_addr((struct sockaddr *)&msg->lm_addr)); if (msg->lm_nfsv3) { - arg4.cookie.n_bytes = (char *)&msg->lm_msg_ident; - arg4.cookie.n_len = sizeof(msg->lm_msg_ident); - arg4.block = msg->lm_wait ? 1 : 0; - arg4.exclusive = msg->lm_fl.l_type == F_WRLCK ? 1 : 0; - arg4.alock.caller_name = hostname; - arg4.alock.fh.n_bytes = (char *)&msg->lm_fh; - arg4.alock.fh.n_len = msg->lm_fh_len; - arg4.alock.oh.n_bytes = (char *)&owner; - arg4.alock.oh.n_len = sizeof(owner); - arg4.alock.svid = msg->lm_msg_ident.pid; - arg4.alock.l_offset = msg->lm_fl.l_start; - arg4.alock.l_len = msg->lm_fl.l_len; - arg4.reclaim = 0; - arg4.state = nsm_state; - - if ((cli = get_client( - (struct sockaddr *)&msg->lm_addr, - NLM_VERS4)) == NULL) - return (1); - - set_auth(cli, &msg->lm_cred); - (void)clnt_call(cli, NLM_LOCK_MSG, - (xdrproc_t)xdr_nlm4_lockargs, &arg4, - (xdrproc_t)xdr_void, &dummy, timeout); + nlm_version = NLM_VERS4; + xdrargs = (xdrproc_t)xdr_nlm4_lockargs; + xdrres = (xdrproc_t)xdr_nlm4_res; + arg.arg4.cookie.n_bytes = (char *)&msg->lm_msg_ident; + arg.arg4.cookie.n_len = cookie_len; + arg.arg4.block = msg->lm_wait ? 1 : 0; + arg.arg4.exclusive = msg->lm_fl.l_type == F_WRLCK ? 1 : 0; + arg.arg4.alock.caller_name = hostname; + arg.arg4.alock.fh.n_bytes = (char *)&msg->lm_fh; + arg.arg4.alock.fh.n_len = msg->lm_fh_len; + arg.arg4.alock.oh.n_bytes = (char *)&owner; + arg.arg4.alock.oh.n_len = sizeof(owner); + arg.arg4.alock.svid = msg->lm_msg_ident.pid; + arg.arg4.alock.l_offset = msg->lm_fl.l_start; + arg.arg4.alock.l_len = msg->lm_fl.l_len; + arg.arg4.reclaim = 0; + arg.arg4.state = nsm_state; } else { - arg.cookie.n_bytes = (char *)&msg->lm_msg_ident; - arg.cookie.n_len = sizeof(msg->lm_msg_ident); - arg.block = msg->lm_wait ? 1 : 0; - arg.exclusive = msg->lm_fl.l_type == F_WRLCK ? 1 : 0; - arg.alock.caller_name = hostname; - arg.alock.fh.n_bytes = (char *)&msg->lm_fh; - arg.alock.fh.n_len = msg->lm_fh_len; - arg.alock.oh.n_bytes = (char *)&owner; - arg.alock.oh.n_len = sizeof(owner); - arg.alock.svid = msg->lm_msg_ident.pid; - arg.alock.l_offset = msg->lm_fl.l_start; - arg.alock.l_len = msg->lm_fl.l_len; - arg.reclaim = 0; - arg.state = nsm_state; - - if ((cli = get_client( - (struct sockaddr *)&msg->lm_addr, - NLM_VERS)) == NULL) - return (1); - - set_auth(cli, &msg->lm_cred); - (void)clnt_call(cli, NLM_LOCK_MSG, - (xdrproc_t)xdr_nlm_lockargs, &arg, - (xdrproc_t)xdr_void, &dummy, timeout); + nlm_version = NLM_VERS; + xdrargs = (xdrproc_t)xdr_nlm_lockargs; + xdrres = (xdrproc_t)xdr_nlm_res; + arg.arg.cookie.n_bytes = (char *)&msg->lm_msg_ident; + arg.arg.cookie.n_len = cookie_len; + arg.arg.block = msg->lm_wait ? 1 : 0; + arg.arg.exclusive = msg->lm_fl.l_type == F_WRLCK ? 1 : 0; + arg.arg.alock.caller_name = hostname; + arg.arg.alock.fh.n_bytes = (char *)&msg->lm_fh; + arg.arg.alock.fh.n_len = msg->lm_fh_len; + arg.arg.alock.oh.n_bytes = (char *)&owner; + arg.arg.alock.oh.n_len = sizeof(owner); + arg.arg.alock.svid = msg->lm_msg_ident.pid; + arg.arg.alock.l_offset = msg->lm_fl.l_start; + arg.arg.alock.l_len = msg->lm_fl.l_len; + arg.arg.reclaim = 0; + arg.arg.state = nsm_state; + } + + + cli = get_client((struct sockaddr *)&msg->lm_addr, nlm_version); + if (cli == NULL) + return (1); + + set_auth(cli, &msg->lm_cred); + if (asynchronous_client_rpc) + clnt_call(cli, NLM_LOCK_MSG, + xdrargs, &arg, (xdrproc_t)xdr_void, &res, timeout); + else { + enum clnt_stat st; + timeout.tv_sec = synchronous_client_rpc_timeout; + bzero(&res, sizeof(res)); + st = clnt_call(cli, NLM_LOCK, + xdrargs, &arg, xdrres, &res, timeout); + if (st != RPC_SUCCESS) { + expire_client(cli); + syslog(LOG_ERR, "NLM_LOCK %s, server %s", + clnt_sperrno(st), + from_addr((struct sockaddr *)&msg->lm_addr)); + } else { + touch_client(cli); + lock_answer(msg->lm_msg_ident.pid, + &res.res.cookie, + res.res.stat.stat, /* union XXX */ + NULL, + nlm_version); + } + xdr_free(xdrres, &res); } return (0); } @@ -402,10 +478,25 @@ unlock_request(LOCKD_MSG *msg) { CLIENT *cli; - struct nlm4_unlockargs arg4; - struct nlm_unlockargs arg; struct timeval timeout = {0, 0}; /* No timeout, no response. */ - char dummy; + int nlm_version; + xdrproc_t xdrargs; + union { + nlm_unlockargs arg; + nlm4_unlockargs arg4; + } arg; + xdrproc_t xdrres; + union { + char dummy; + nlm_res res; + nlm4_res res4; + } res; + int cookie_len; + + if (asynchronous_client_rpc) + cookie_len = client_cookie_len; /* Long cookies */ + else + cookie_len = MINIMAL_CLIENT_COOKIE_LEN; if (d_calls) syslog(LOG_DEBUG, "unlock request: %s: to %s", @@ -413,49 +504,69 @@ from_addr((struct sockaddr *)&msg->lm_addr)); if (msg->lm_nfsv3) { - arg4.cookie.n_bytes = (char *)&msg->lm_msg_ident; - arg4.cookie.n_len = sizeof(msg->lm_msg_ident); - arg4.alock.caller_name = hostname; - arg4.alock.fh.n_bytes = (char *)&msg->lm_fh; - arg4.alock.fh.n_len = msg->lm_fh_len; - arg4.alock.oh.n_bytes = (char *)&owner; - arg4.alock.oh.n_len = sizeof(owner); - arg4.alock.svid = msg->lm_msg_ident.pid; - arg4.alock.l_offset = msg->lm_fl.l_start; - arg4.alock.l_len = msg->lm_fl.l_len; - - if ((cli = get_client( - (struct sockaddr *)&msg->lm_addr, - NLM_VERS4)) == NULL) - return (1); - - set_auth(cli, &msg->lm_cred); - (void)clnt_call(cli, NLM_UNLOCK_MSG, - (xdrproc_t)xdr_nlm4_unlockargs, &arg4, - (xdrproc_t)xdr_void, &dummy, timeout); + nlm_version = NLM_VERS4; + xdrargs = (xdrproc_t)xdr_nlm4_unlockargs; + xdrres = (xdrproc_t)xdr_nlm4_res; + arg.arg4.cookie.n_bytes = (char *)&msg->lm_msg_ident; + arg.arg4.cookie.n_len = cookie_len; + arg.arg4.alock.caller_name = hostname; + arg.arg4.alock.fh.n_bytes = (char *)&msg->lm_fh; + arg.arg4.alock.fh.n_len = msg->lm_fh_len; + arg.arg4.alock.oh.n_bytes = (char *)&owner; + arg.arg4.alock.oh.n_len = sizeof(owner); + arg.arg4.alock.svid = msg->lm_msg_ident.pid; + arg.arg4.alock.l_offset = msg->lm_fl.l_start; + arg.arg4.alock.l_len = msg->lm_fl.l_len; } else { - arg.cookie.n_bytes = (char *)&msg->lm_msg_ident; - arg.cookie.n_len = sizeof(msg->lm_msg_ident); - arg.alock.caller_name = hostname; - arg.alock.fh.n_bytes = (char *)&msg->lm_fh; - arg.alock.fh.n_len = msg->lm_fh_len; - arg.alock.oh.n_bytes = (char *)&owner; - arg.alock.oh.n_len = sizeof(owner); - arg.alock.svid = msg->lm_msg_ident.pid; - arg.alock.l_offset = msg->lm_fl.l_start; - arg.alock.l_len = msg->lm_fl.l_len; - - if ((cli = get_client( - (struct sockaddr *)&msg->lm_addr, - NLM_VERS)) == NULL) - return (1); - - set_auth(cli, &msg->lm_cred); - (void)clnt_call(cli, NLM_UNLOCK_MSG, - (xdrproc_t)xdr_nlm_unlockargs, &arg, - (xdrproc_t)xdr_void, &dummy, timeout); + nlm_version = NLM_VERS; + xdrargs = (xdrproc_t)xdr_nlm_unlockargs; + xdrres = (xdrproc_t)xdr_nlm_res; + arg.arg.cookie.n_bytes = (char *)&msg->lm_msg_ident; + arg.arg.cookie.n_len = cookie_len; + arg.arg.alock.caller_name = hostname; + arg.arg.alock.fh.n_bytes = (char *)&msg->lm_fh; + arg.arg.alock.fh.n_len = msg->lm_fh_len; + arg.arg.alock.oh.n_bytes = (char *)&owner; + arg.arg.alock.oh.n_len = sizeof(owner); + arg.arg.alock.svid = msg->lm_msg_ident.pid; + arg.arg.alock.l_offset = msg->lm_fl.l_start; + arg.arg.alock.l_len = msg->lm_fl.l_len; } + cli = get_client((struct sockaddr *)&msg->lm_addr, nlm_version); + if (cli == NULL) + return (1); + + set_auth(cli, &msg->lm_cred); + if (asynchronous_client_rpc) + clnt_call(cli, NLM_UNLOCK_MSG, + xdrargs, &arg, (xdrproc_t)xdr_void, &res, timeout); + else { + enum clnt_stat st; + timeout.tv_sec = synchronous_client_rpc_timeout; + bzero(&res, sizeof(res)); + st = clnt_call(cli, NLM_UNLOCK, + xdrargs, &arg, xdrres, &res, timeout); + if (st != RPC_SUCCESS) { + expire_client(cli); + /* + * A list of failed locks should really be + * maintained per server so that unlocks may + * be retried if/when the server comes back. + */ + syslog(LOG_ERR, "NLM_UNLOCK %s, server %s", + clnt_sperrno(st), + from_addr((struct sockaddr *)&msg->lm_addr)); + } else { + touch_client(cli); + lock_answer(msg->lm_msg_ident.pid, + &res.res.cookie, + res.res.stat.stat, + NULL, + nlm_version); + } + xdr_free(xdrres, &res); + } return (0); } @@ -464,16 +575,21 @@ { struct lockd_ans ans; - if (netcookie->n_len != sizeof(ans.la_msg_ident)) { + if (netcookie->n_len == sizeof(ans.la_msg_ident)) { + memcpy(&ans.la_msg_ident, netcookie->n_bytes, + sizeof(ans.la_msg_ident)); + } else if (netcookie->n_len == MINIMAL_CLIENT_COOKIE_LEN) { + memcpy(&ans.la_msg_ident, netcookie->n_bytes, + MINIMAL_CLIENT_COOKIE_LEN); + ans.la_msg_ident.pid_start.tv_sec = 0; + ans.la_msg_ident.pid_start.tv_usec = 0; + } else { if (pid == -1) { /* we're screwed */ syslog(LOG_ERR, "inedible nlm cookie"); return -1; } ans.la_msg_ident.pid = pid; ans.la_msg_ident.msg_seq = -1; - } else { - memcpy(&ans.la_msg_ident, netcookie->n_bytes, - sizeof(ans.la_msg_ident)); } if (d_calls) diff -u usr.sbin/rpc.lockd/lock_proc.c usr.sbin/rpc.lockd.new/lock_proc.c --- usr.sbin/rpc.lockd/lock_proc.c Fri Jul 16 21:30:59 2004 +++ usr.sbin/rpc.lockd.new/lock_proc.c Thu Nov 25 16:14:22 2004 @@ -47,6 +47,7 @@ #include #include #include +#include #include #include @@ -184,6 +185,40 @@ } return memcmp(p1, p2, len); +} + +/* Mark server/client as down! */ +void +expire_client(CLIENT *client) +{ + int i; + + for (i = 0; i < CLIENT_CACHE_SIZE; i++) { + if (client == clnt_cache_ptr[i]) { + clnt_cache_time[i] = 0L; + clnt_destroy(client); + clnt_cache_ptr[i] = NULL; + return; + } + } +} + +/* Successfully contacted server/client! */ +void +touch_client(CLIENT *client) +{ + int i; + struct timeval time_now; + + gettimeofday(&time_now, NULL); + + for (i = 0; i < CLIENT_CACHE_SIZE; i++) { + if (client == clnt_cache_ptr[i]) { + gettimeofday(&time_now, NULL); + clnt_cache_time[i] = time_now.tv_sec; + return; + } + } } CLIENT * diff -u usr.sbin/rpc.lockd/lockd.c usr.sbin/rpc.lockd.new/lockd.c --- usr.sbin/rpc.lockd/lockd.c Fri Jul 16 21:30:59 2004 +++ usr.sbin/rpc.lockd.new/lockd.c Thu Nov 25 18:38:32 2004 @@ -68,6 +68,8 @@ #include int debug_level = 0; /* 0 = no debugging syslog() calls */ +int asynchronous_client_rpc = 1; /* XXX default to 1 */ +int synchronous_client_rpc_timeout = 5; /* Seconds */ int _rpcsvcdirty = 0; int grace_expired; @@ -98,7 +100,7 @@ struct netconfig *nconf; int maxrec = RPC_MAXDATASIZE; - while ((ch = getopt(argc, argv, "d:g:")) != (-1)) { + while ((ch = getopt(argc, argv, "ad:g:s8")) != (-1)) { switch (ch) { case 'd': debug_level = atoi(optarg); @@ -114,6 +116,15 @@ /* NOTREACHED */ } break; + case 'a': + asynchronous_client_rpc = 1; + break; + case 's': + asynchronous_client_rpc = 0; + break; + case '8': + client_cookie_len = 8; + break; default: case '?': usage(); @@ -223,7 +234,7 @@ void usage() { - errx(1, "usage: rpc.lockd [-d ] [-g ]"); + errx(1, "usage: rpc.lockd [-d ] [-g ] [-a] [-s] [-8]"); } /* diff -u usr.sbin/rpc.lockd/lockd.h usr.sbin/rpc.lockd.new/lockd.h --- usr.sbin/rpc.lockd/lockd.h Thu Nov 29 18:36:45 2001 +++ usr.sbin/rpc.lockd.new/lockd.h Thu Nov 25 16:17:06 2004 @@ -35,6 +35,9 @@ */ extern int debug_level; +extern int asynchronous_client_rpc; +extern int synchronous_client_rpc_timeout; +extern int client_cookie_len; extern int grace_expired; pid_t client_request(void); extern int nsm_state; diff -u usr.sbin/rpc.lockd/lockd_lock.h usr.sbin/rpc.lockd.new/lockd_lock.h --- usr.sbin/rpc.lockd/lockd_lock.h Thu Mar 21 23:52:45 2002 +++ usr.sbin/rpc.lockd.new/lockd_lock.h Tue Nov 23 18:16:27 2004 @@ -23,3 +23,5 @@ void transmit_result(int, nlm_res *, struct sockaddr *); void transmit4_result(int, nlm4_res *, struct sockaddr *); CLIENT *get_client(struct sockaddr *, rpcvers_t); +void expire_client(CLIENT *); +void touch_client(CLIENT *); diff -u usr.sbin/rpc.lockd/rpc.lockd.8 usr.sbin/rpc.lockd.new/rpc.lockd.8 --- usr.sbin/rpc.lockd/rpc.lockd.8 Sun Jul 14 16:45:36 2002 +++ usr.sbin/rpc.lockd.new/rpc.lockd.8 Thu Nov 25 19:09:58 2004 @@ -43,6 +43,9 @@ .Nm .Op Fl d Ar debug_level .Op Fl g Ar grace period +.Op Fl a +.Op Fl s +.Op Fl 8 .Sh DESCRIPTION The .Nm @@ -83,6 +86,26 @@ only accepts requests from hosts which are reinitialising locks which existed before the server restart. Default is 30 seconds. +.It Fl s +The +.Fl s +option makes the client portion of +.Nm +use synchronous RPC calls rather than the corresponding asynchronous +procedures. For instance one NLM_LOCK call is used instead of two +asynchronous NLM_LOCK_MSG and NLM_LOCK_RES calls. Locks originated +locally will use short cookies (see the +.Fl 8 +option below) but will not be susceptible to pid recycling problems. +.It Fl 8 +The +.Fl 8 +option allows for usage of short 8 byte client cookies compatible with +limitations of Linux servers. This option only effects locks of local +origin and will not effect any of the +.Nm +server functionality. Short cookies are susceptible to pid recycling +problems and are thus turned off by default. .El .Pp Error conditions are logged to syslog, irrespective of the debug level, From owner-freebsd-net@FreeBSD.ORG Thu Nov 25 20:28:45 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A54CB16A4CE for ; Thu, 25 Nov 2004 20:28:45 +0000 (GMT) Received: from mail.net (custpop.ca.mci.com [142.77.1.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id 01FE643D5A for ; Thu, 25 Nov 2004 20:28:45 +0000 (GMT) (envelope-from kfl@xiphos.ca) Received: from [24.200.150.83] (account kfl@xiphos.ca HELO [10.0.0.249]) by mail.net (CommuniGate Pro SMTP 4.2.5) with ESMTP id 29815804 for freebsd-net@freebsd.org; Thu, 25 Nov 2004 15:28:44 -0500 Message-ID: <41A64079.8040201@xiphos.ca> Date: Thu, 25 Nov 2004 15:28:41 -0500 From: Karim Fodil-Lemelin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: multipart/mixed; boundary="------------000402070104040603050701" Subject: ipl ftp proxy bugfix X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 25 Nov 2004 20:28:45 -0000 This is a multi-part message in MIME format. --------------000402070104040603050701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all, I have been experiencing problems reaching some ftp servers in active mode through the ftp proxy in the ipl module. Although some ftp servers would work without problems (ex: ftp.freebsd.org). Here is how you can reproduce the current problem: /etc/ipnat.rules map sis2 192.168.0.0/16 -> 0/32 proxy port ftp ftp/tcp map sis2 192.168.0.0/16 -> 0/32 ftp to a site where the welcome message/banner (220) is larger then 80 bytes (FTP_BUFSZ/2). ftp> passive Passive mode off ftp> ls 500 Illegal PORT command. The problem is that the ftp proxy entry gets deleted when ftp_server_valid() tries to get the 220 command due to the lack of \n in the buffer (striped by len = MIN(mlen, FTP_BUFSZ / 2); in ip_ftp_pxy.c). I have attached the solution. Regards, -- Karim Fodil-Lemelin Lead Programmer Xiphos Technologies Inc. www.xiplink.com --------------000402070104040603050701 Content-Type: text/plain; name="ipl.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ipl.patch" Index: ip_ftp_pxy.c =================================================================== RCS file: /usr/xiphos/cvsroot/scps/OS_port/FreeBSD/dev/sys_49/contrib/ipfilter/netinet/ip_ftp_pxy.c,v retrieving revision 1.1 diff -u -r1.1 ip_ftp_pxy.c --- ip_ftp_pxy.c 30 Aug 2004 20:48:14 -0000 1.1 +++ ip_ftp_pxy.c 25 Nov 2004 20:03:34 -0000 @@ -818,11 +818,9 @@ } for (; i; i--) { - c = *s++; - if (c == '\n') { - ftps->ftps_cmds = cmd; - return 0; - } + c = *s++; + ftps->ftps_cmds = cmd; + return 0; } #if !defined(_KERNEL) && !defined(KERNEL) fprintf(stdout, "ippr_ftp_server_valid:junk after cmd[%s]\n", buf); --------------000402070104040603050701-- From owner-freebsd-net@FreeBSD.ORG Thu Nov 25 21:52:37 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 531B916A4CE; Thu, 25 Nov 2004 21:52:37 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 78DC243D46; Thu, 25 Nov 2004 21:52:36 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 3CB9965218; Thu, 25 Nov 2004 21:52:34 +0000 (GMT) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 89813-05; Thu, 25 Nov 2004 21:52:33 +0000 (GMT) Received: from empiric.dek.spc.org (dhcp120.icir.org [192.150.187.120]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 1BAF4651FA; Thu, 25 Nov 2004 21:52:32 +0000 (GMT) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id F0B0B6680; Thu, 25 Nov 2004 13:52:25 -0800 (PST) Date: Thu, 25 Nov 2004 13:52:25 -0800 From: Bruce M Simpson To: =?iso-8859-1?Q?Bj=F6rn_Gr=F6nvall?= Message-ID: <20041125215225.GF733@empiric.icir.org> Mail-Followup-To: =?iso-8859-1?Q?Bj=F6rn_Gr=F6nvall?= , freebsd-net@FreeBSD.org, lennox@cs.columbia.edu, alfred@FreeBSD.org, kris@FreeBSD.org, dnelson@allantgroup.com References: <20041125201812.609e50f9@manian.sics.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20041125201812.609e50f9@manian.sics.se> cc: lennox@cs.columbia.edu cc: freebsd-net@FreeBSD.org cc: kris@FreeBSD.org cc: alfred@FreeBSD.org cc: dnelson@allantgroup.com Subject: Re: Linux compatible rpc.lockd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 25 Nov 2004 21:52:37 -0000 On Thu, Nov 25, 2004 at 08:18:12PM +0100, Björn Grönvall wrote: > I have made a patch to address PR kern/56461, in short the patch > provides two different options to be compatible with Linux lockd > implementations. It can also serve as a basis for a future more robust > rpc.lockd. Thank you for this. I looked at this around 8 months ago but abandoned further work on it because the approach I was taking required that nfs be refactored to use the nmount() API, and because I am not currently using NFS. It looks as though the two options implemented here helps to address the problems I was having with making sure Linux servers got the right lock cookie response. Have you tested this in production and does it work well? If so I believe it should be committed, but I'd defer to Alfred for further review. Regards, BMS From owner-freebsd-net@FreeBSD.ORG Fri Nov 26 00:47:15 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9AD6A16A4CE; Fri, 26 Nov 2004 00:47:15 +0000 (GMT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 86CF143D3F; Fri, 26 Nov 2004 00:47:15 +0000 (GMT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 7921C5C8F6; Thu, 25 Nov 2004 16:47:15 -0800 (PST) Date: Thu, 25 Nov 2004 16:47:15 -0800 From: Alfred Perlstein To: Bj?rn Gr?nvall , freebsd-net@FreeBSD.org, lennox@cs.columbia.edu, kris@FreeBSD.org, dnelson@allantgroup.com Message-ID: <20041126004715.GD69608@elvis.mu.org> References: <20041125201812.609e50f9@manian.sics.se> <20041125215225.GF733@empiric.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041125215225.GF733@empiric.icir.org> User-Agent: Mutt/1.4.2.1i Subject: Re: Linux compatible rpc.lockd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 26 Nov 2004 00:47:15 -0000 * Bruce M Simpson [041125 13:53] wrote: > On Thu, Nov 25, 2004 at 08:18:12PM +0100, Bj?rn Gr?nvall wrote: > > I have made a patch to address PR kern/56461, in short the patch > > provides two different options to be compatible with Linux lockd > > implementations. It can also serve as a basis for a future more robust > > rpc.lockd. > > Thank you for this. I looked at this around 8 months ago but abandoned > further work on it because the approach I was taking required that > nfs be refactored to use the nmount() API, and because I am not currently > using NFS. It looks as though the two options implemented here helps to > address the problems I was having with making sure Linux servers got > the right lock cookie response. > > Have you tested this in production and does it work well? If so I believe > it should be committed, but I'd defer to Alfred for further review. It looks non0invasive enough to be safe. Please see if you can get a test run and commit it. I'm in the hospital and not able to do stuff. -- - Alfred Perlstein - Research Engineering Development Inc. - email: bright@mu.org cell: 408-480-4684 From owner-freebsd-net@FreeBSD.ORG Fri Nov 26 02:55:11 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 24EDC16A4CE; Fri, 26 Nov 2004 02:55:11 +0000 (GMT) Received: from mx01.bos.ma.towardex.com (mx01.bos.ma.towardex.com [65.124.16.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id EFE8243D55; Fri, 26 Nov 2004 02:55:10 +0000 (GMT) (envelope-from haesu@mx01.bos.ma.towardex.com) Received: by mx01.bos.ma.towardex.com (TowardEX ESMTP 3.0p11_DAKN, from userid 1001) id 7A39A2F9FD; Thu, 25 Nov 2004 21:55:10 -0500 (EST) Date: Thu, 25 Nov 2004 21:55:10 -0500 From: James To: Gleb Smirnoff Message-ID: <20041126025510.GA44246@scylla.towardex.com> References: <20041125140641.GA78210@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041125140641.GA78210@cell.sick.ru> User-Agent: Mutt/1.4.1i cc: net@freebsd.org Subject: Re: route cacheing for gif(4) should be optional X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 26 Nov 2004 02:55:11 -0000 On Thu, Nov 25, 2004 at 05:06:41PM +0300, Gleb Smirnoff wrote: > Back to this problem: > > http://freebsd.rambler.ru/bsdmail/freebsd-net_2004/msg01305.html > > I've found two more people who dislike this feature of gif(4). > So I'd like to make it optional. > > We already have LINK2 flag removing sourceroute filter from gif(4), > which is commonly used in asymmetrically routed networks. I suggest > to use this flag also for disabling route cacheing, since asymmetricity > often appears in dynamically routed networks, and if one runs dynamic > routing, he probably wants to remove route cacheing, too. I'd think we should create a separate option for removing the route cache. Sometimes, certain people want to use the tunnel at the highest maximum performance possible with both sourceroute filter disabled and tunneling routes allocated at their creation time. Perhaps link3 is a good place for this option? Thanks, -J -- James Jun TowardEX Technologies, Inc. Technical Lead Boston IPv4/IPv6 Web Hosting, Colocation and james@towardex.com Network design/consulting & configuration services cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net From owner-freebsd-net@FreeBSD.ORG Fri Nov 26 08:10:02 2004 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3DB9F16A4CE; Fri, 26 Nov 2004 08:10:02 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A49943D2F; Fri, 26 Nov 2004 08:10:02 +0000 (GMT) (envelope-from silby@FreeBSD.org) Received: from freefall.freebsd.org (silby@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id iAQ8A1e9051554; Fri, 26 Nov 2004 08:10:01 GMT (envelope-from silby@freefall.freebsd.org) Received: (from silby@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id iAQ8A1gE051550; Fri, 26 Nov 2004 08:10:01 GMT (envelope-from silby) Date: Fri, 26 Nov 2004 08:10:01 GMT From: Mike Silbersack Message-Id: <200411260810.iAQ8A1gE051550@freefall.freebsd.org> To: silby@FreeBSD.org, freebsd-net@FreeBSD.org, silby@FreeBSD.org Subject: Re: kern/72502: [patch] TCP should honour incoming RSTs even if the receive window is closed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 26 Nov 2004 08:10:02 -0000 Synopsis: [patch] TCP should honour incoming RSTs even if the receive window is closed Responsible-Changed-From-To: freebsd-net->silby Responsible-Changed-By: silby Responsible-Changed-When: Fri Nov 26 08:09:32 GMT 2004 Responsible-Changed-Why: Patch committed, hook into the regression test framework and MFCs still pending. http://www.freebsd.org/cgi/query-pr.cgi?pr=72502 From owner-freebsd-net@FreeBSD.ORG Fri Nov 26 09:13:21 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3BB9316A4CE for ; Fri, 26 Nov 2004 09:13:21 +0000 (GMT) Received: from relay.bestcom.ru (relay.bestcom.ru [217.72.144.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7188843D41 for ; Fri, 26 Nov 2004 09:13:20 +0000 (GMT) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (root@cell.sick.ru [217.72.144.68]) by relay.bestcom.ru (8.13.1/8.12.9) with ESMTP id iAQ9DITJ093549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 26 Nov 2004 12:13:19 +0300 (MSK) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id iAQ9DHq4084403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Nov 2004 12:13:18 +0300 (MSK) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id iAQ9DH2n084402; Fri, 26 Nov 2004 12:13:17 +0300 (MSK) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Fri, 26 Nov 2004 12:13:16 +0300 From: Gleb Smirnoff To: James Message-ID: <20041126091316.GA84369@cell.sick.ru> References: <20041125140641.GA78210@cell.sick.ru> <20041126025510.GA44246@scylla.towardex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20041126025510.GA44246@scylla.towardex.com> User-Agent: Mutt/1.5.6i X-Virus-Scanned: clamd / ClamAV version devel-20041013, clamav-milter version 0.75l on 127.0.0.1 X-Virus-Status: Clean cc: net@freebsd.org Subject: Re: route cacheing for gif(4) should be optional X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 26 Nov 2004 09:13:21 -0000 On Thu, Nov 25, 2004 at 09:55:10PM -0500, James wrote: J> On Thu, Nov 25, 2004 at 05:06:41PM +0300, Gleb Smirnoff wrote: J> > Back to this problem: J> > J> > http://freebsd.rambler.ru/bsdmail/freebsd-net_2004/msg01305.html J> > J> > I've found two more people who dislike this feature of gif(4). J> > So I'd like to make it optional. J> > J> > We already have LINK2 flag removing sourceroute filter from gif(4), J> > which is commonly used in asymmetrically routed networks. I suggest J> > to use this flag also for disabling route cacheing, since asymmetricity J> > often appears in dynamically routed networks, and if one runs dynamic J> > routing, he probably wants to remove route cacheing, too. J> J> I'd think we should create a separate option for removing the route J> cache. Sometimes, certain people want to use the tunnel at the highest J> maximum performance possible with both sourceroute filter disabled J> and tunneling routes allocated at their creation time. Perhaps link3 is a J> good place for this option? There is no LINK3 flag :) However, gif(4) does not use LINK0 flag. It was used in past. We can utilize it now. Any objections? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Fri Nov 26 09:20:44 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1234116A4CE; Fri, 26 Nov 2004 09:20:43 +0000 (GMT) Received: from mx01.bos.ma.towardex.com (mx01.bos.ma.towardex.com [65.124.16.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD56343D2F; Fri, 26 Nov 2004 09:20:43 +0000 (GMT) (envelope-from haesu@mx01.bos.ma.towardex.com) Received: by mx01.bos.ma.towardex.com (TowardEX ESMTP 3.0p11_DAKN, from userid 1001) id 3E3222F93F; Fri, 26 Nov 2004 04:20:43 -0500 (EST) Date: Fri, 26 Nov 2004 04:20:42 -0500 From: James To: Gleb Smirnoff Message-ID: <20041126092042.GA88208@scylla.towardex.com> References: <20041125140641.GA78210@cell.sick.ru> <20041126025510.GA44246@scylla.towardex.com> <20041126091316.GA84369@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041126091316.GA84369@cell.sick.ru> User-Agent: Mutt/1.4.1i cc: net@freebsd.org cc: James Subject: Re: route cacheing for gif(4) should be optional X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 26 Nov 2004 09:20:44 -0000 On Fri, Nov 26, 2004 at 12:13:16PM +0300, Gleb Smirnoff wrote: [ snip ] > > There is no LINK3 flag :) Heheh, good call ;) > > However, gif(4) does not use LINK0 flag. It was used in past. We can utilize > it now. Any objections? I have no objections myself as long as this option is separated from existing link2 feature, so yea I agree in that link0 is good idea there. Thanks! -J -- James Jun TowardEX Technologies, Inc. Technical Lead Boston IPv4/IPv6 Web Hosting, Colocation and james@towardex.com Network design/consulting & configuration services cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net From owner-freebsd-net@FreeBSD.ORG Fri Nov 26 09:46:19 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 033FF16A4CE; Fri, 26 Nov 2004 09:46:18 +0000 (GMT) Received: from manian.sics.se (manian.sics.se [193.10.66.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5987243D1F; Fri, 26 Nov 2004 09:46:18 +0000 (GMT) (envelope-from bg@sics.se) Received: from manian.sics.se (localhost [127.0.0.1]) by manian.sics.se (8.13.1/8.13.1) with SMTP id iAQ9k2Te024511; Fri, 26 Nov 2004 10:46:02 +0100 (CET) (envelope-from bg@sics.se) Date: Fri, 26 Nov 2004 10:46:02 +0100 From: =?ISO-8859-1?Q?Bj=F6rn_Gr=F6nvall?= To: Alfred Perlstein Message-ID: <20041126104602.56845fb6@manian.sics.se> In-Reply-To: <20041126004715.GD69608@elvis.mu.org> References: <20041125201812.609e50f9@manian.sics.se> <20041125215225.GF733@empiric.icir.org> <20041126004715.GD69608@elvis.mu.org> Organization: SICS X-Mailer: Sylpheed-Claws 0.9.12b (GTK+ 1.2.10; i386-portbld-freebsd5.3) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit cc: lennox@cs.columbia.edu cc: freebsd-net@freebsd.org cc: dnelson@allantgroup.com Subject: Re: Linux compatible rpc.lockd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 26 Nov 2004 09:46:19 -0000 On Thu, 25 Nov 2004 16:47:15 -0800 Alfred Perlstein wrote: > > Have you tested this in production and does it work well? If so I believe > > it should be committed, but I'd defer to Alfred for further review. > > It looks non0invasive enough to be safe. Please see if you can > get a test run and commit it. I'm in the hospital and not able to > do stuff. I would like to test it a little bit longer but more importantly I would like to see how it works in a different environment. Historically NLM implementations use the asynchronous api, using the synchronous api may trigger bugs in other servers and I'm concerned about this. Hope that you are well soon. Take care, Björn -- _ _ ,_______________. Bjorn Gronvall (Björn Grönvall) /_______________/| Swedish Institute of Computer Science | || PO Box 1263, S-164 29 Kista, Sweden | Schroedingers || Email: bg@sics.se, Phone +46 -8 633 15 25 | Cat |/ Cellular +46 -70 768 06 35, Fax +46 -8 751 72 30 '---------------' From owner-freebsd-net@FreeBSD.ORG Fri Nov 26 12:19:22 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 880FB16A4CE for ; Fri, 26 Nov 2004 12:19:22 +0000 (GMT) Received: from borgtech.ca (borgtech.ca [216.187.106.216]) by mx1.FreeBSD.org (Postfix) with ESMTP id 45B1443D41 for ; Fri, 26 Nov 2004 12:19:22 +0000 (GMT) (envelope-from asegu@borgtech.ca) Received: from mojlaptop (unknown [161.53.212.202]) by borgtech.ca (Postfix) with ESMTP id 66A0454A5 for ; Fri, 26 Nov 2004 12:33:32 +0000 (GMT) Message-ID: <007f01c4d3b2$12597af0$cad435a1@mojlaptop> From: "Andrew Seguin" To: Date: Fri, 26 Nov 2004 13:18:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Subject: FreeBSD 5.3 Networking performance problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 26 Nov 2004 12:19:22 -0000 *Problem: Poor performance for freebsd transparent gateway. *Situation: I need to install a simple firewall for a school network I am administering. We have about 100 computers active, generating a stream of approximately 80-90K packets per minute for a load I estimate* to be a little under 10Mbps. Overall the firewall will need to filter for a /24 subnet. *Configuration: Hardware: The firewall is a Celeron 900Mhz with 128MB ram (more on the way) with one rl and one sis based network cards. The firewall is to be the bridge between the main switch and the router. Software: I built up the firewall with FreeBSD 5.3, with a recompiled kernel using options BRIDGE, IPFIREWALL, IPFIREWALL_VERBOSE, IPFIREWALL_VERBOSE_LIMIT, IPFIREWALL_DEFAULT_TO_ACCEPT and IPSTEALTH. No software is running. IPFW is left with only it's default rule of allow all. *Testing: I tested with the firewall bridging for a single computer: ping time to the router was a stable 2ms. I then tested with the whole school going through the firewall: very bad. packets were being droped and ping times were around 600ms. Internet was pretty much unuseable. I googled around and read a bit, discovered polling. I Rebuilt the kernel for it and HZ set to 1000. I set the appropriate sysctl's and saw on ifconfig polling was indicated for both network cards. I retried using the firewall for the whole school, but again it wasn't working. I disconnected the secondary switches (which is for the offices, student residence, computer lab, etc) and kept a computer on the main switch. Ping times remained stable up to a bandwith I estimated later to be of approximately 20MB/min. The last switch I added, having a trafic of 5MB/min seemed to kill the box. During my testing with the poling kernel, interupt time went up to 10% for the whole school, with 90% idle. Memory remained unchanged with 86MB free. Conclusion: I don't know what could be causing what seems to me as simply low performance under increased load. I've heard of people with higher loads then I have here**. If somebody on the list could give me some clues of what could be the problem here and pointers as to what to look at next, I would appreciate it greatly. The only idea I have here is to try and rebuild to 4.10 and see if the performance is there... is 4.10 much more performant then 5.3 ? * I have yet to get access to the router (SNMP or otherwise). I estimated the school load by using my firewall to test the traffic from each individual switch's uplink. I then extrapolated approximate traffic for our web and email servers in the very unscientific manor of comparing the lights on the main switch. **In particular the post on Nov 17 by Yar Tikhiy "polling(4) rocks!" had a claim of about 9kpps vs my load of about 1.5kpps From owner-freebsd-net@FreeBSD.ORG Fri Nov 26 13:57:04 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A8F3016A4CE for ; Fri, 26 Nov 2004 13:57:04 +0000 (GMT) Received: from mail.otel.net (gw3.OTEL.net [212.36.8.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5BB6743D2F for ; Fri, 26 Nov 2004 13:57:04 +0000 (GMT) (envelope-from tbyte@OTEL.net) Received: from dragon.otel.net ([212.36.8.135]) by mail.otel.net with esmtp (Exim 4.30; FreeBSD) id 1CXgas-000GBm-Ah; Fri, 26 Nov 2004 15:57:02 +0200 Message-ID: <41A7363A.2000201@OTEL.net> Date: Fri, 26 Nov 2004 15:57:14 +0200 From: Iasen Kostov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.3) Gecko/20041117 X-Accept-Language: bg, en-us, en MIME-Version: 1.0 To: Iasen Kostov References: <41A61434.3000700@OTEL.net> In-Reply-To: <41A61434.3000700@OTEL.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: netstat patch for bridge stats X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 26 Nov 2004 13:57:04 -0000 Iasen Kostov wrote: > Hi, > this is a small patch which will make bridge stats > look nicer (or at least look some way :) ), because > this is current situation: > > -- Bridging statistics (bdg) -- > Name In Out Forward Drop Bcast Mcast > Local Unknown > vlan5:1 709303965749269168687899969 123884 13908828 3236774 > 10765 4123745 > vlan904:1 759386539711221922749370414 447736 6319135 177242 > 49244 3022768 > > It is really a mess :) and does not looks like other protocol stats do. > And this is how it looks after the patch: > > -- Bridging statistics (bdg) -- > vlan5:1: > 721198379 total packets recieved > 762906756 total packets sent > 699495544 forwarded > 124082 dropped > 14073971 broadcasts > 3251664 multicasts > 10784 for local interface > 4242334 unknown packets > vlan904:1: > 773320391 total packets recieved > 723117599 total packets sent > 763146879 forwarded > 447736 dropped > 6424601 broadcasts > 179482 multicasts > 49248 for local interface > 3072445 unknown packets > > I'll be happy to see comments about this. > > regards. > >------------------------------------------------------------------------ > >--- usr.bin/netstat/if.org.c Thu Nov 25 18:13:34 2004 >+++ usr.bin/netstat/if.c Thu Nov 25 18:59:29 2004 >@@ -101,11 +101,12 @@ > bdg_done = 1; > #endif > printf("-- Bridging statistics (%s) --\n", name) ; >- printf( >-"Name In Out Forward Drop Bcast Mcast Local Unknown\n"); > for (i = 0 ; i < 16 ; i++) { > if (s.s[i].name[0]) >- printf("%-6s %9ld%9ld%9ld%9ld%9ld%9ld%9ld%9ld\n", >+ printf("%-6s:\n\t%ld total packets recieved\n\t%ld total packets sent\n\t" \ >+ "%ld forwarded\n\t%ld dropped\n\t" \ >+ "%ld broadcasts\n\t%ld multicasts\n\t%ld for local interface\n\t" \ >+ "%ld unknown packets\n", > s.s[i].name, > s.s[i].p_in[(int)BDG_IN], > s.s[i].p_in[(int)BDG_OUT], > > >------------------------------------------------------------------------ > >_______________________________________________ >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" > > OK I sorry to replying my self but this: vlan5:1: 1002610279 total packets received 1070806491 total packets sent could not be formated by "%9ld" :) and thus current output of "netstat -pbdg" it tottaly mean less. And the worst thing is that this are stats for 3 days ... From owner-freebsd-net@FreeBSD.ORG Fri Nov 26 18:24:26 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D1FF516A4CE for ; Fri, 26 Nov 2004 18:24:26 +0000 (GMT) Received: from mta8.srv.hcvlny.cv.net (mta8.srv.hcvlny.cv.net [167.206.5.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F70643D1D for ; Fri, 26 Nov 2004 18:24:24 +0000 (GMT) (envelope-from anthonyv@brainlink.com) Received: from superior.local.non-standard.net (ool-18b9c193.dyn.optonline.net [24.185.193.147]) by mta8.srv.hcvlny.cv.net (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0I7S005T4TSNBI@mta8.srv.hcvlny.cv.net> for freebsd-net@freebsd.org; Fri, 26 Nov 2004 13:24:24 -0500 (EST) Date: Fri, 26 Nov 2004 13:24:31 -0500 (EST) From: Anthony Volodkin X-X-Sender: anthonyv@superior.local.non-standard.net To: freebsd-net@freebsd.org Message-id: <20041126125758.T21747@superior.local.non-standard.net> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: FreeBSD kernel pppd - mppe/mschapv1/2/radius support X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 26 Nov 2004 18:24:27 -0000 Hi, After extensively googling FreeBSD pppd's support for mppe, mschapv1, mschapv2 and radius, I've stumbled into a mess of patches for very random versions of pppd and FreeBSD. Does anyone have a running setup of FreeBSD's pppd with support for these features, or perhaps a patch that encompasses all of these features, making a complete solution? If not, any comments on the matter are still appreciated. (And yes, I've tried mpd and user-ppp, but neither one suits my needs sufficiently) Thanks, Amthony Volodkin From owner-freebsd-net@FreeBSD.ORG Fri Nov 26 20:34:06 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 61A7616A4CE; Fri, 26 Nov 2004 20:34:06 +0000 (GMT) Received: from therion.astral-on.net (therion.astral-on.net [193.41.4.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id A7C9343D5A; Fri, 26 Nov 2004 20:34:04 +0000 (GMT) (envelope-from ad@astral-on.net) Received: from odin.astral-on.net (odin.astral-on.net [193.41.4.6]) iAQKXuFs063758; Fri, 26 Nov 2004 22:33:57 +0200 (EET) (envelope-from ad@astral-on.net) Received: from odin.astral-on.net (localhost [127.0.0.1]) by odin.astral-on.net (8.12.8p2/8.12.8) with ESMTP id iAQKXuwk093049; Fri, 26 Nov 2004 22:33:56 +0200 (EET) (envelope-from ad@odin.astral-on.net) Received: (from ad@localhost) by odin.astral-on.net (8.12.8p2/8.12.8/Submit) id iAQKXs5Z093048; Fri, 26 Nov 2004 22:33:55 +0200 (EET) Date: Fri, 26 Nov 2004 22:33:54 +0200 From: Andrew Degtiariov To: freebsd-net@freebsd.org Message-ID: <20041126203354.GB81834@astral-on.net> Mail-Followup-To: freebsd-net@freebsd.org, freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i cc: freebsd-current@freebsd.org Subject: rsh is malfunctioning due to pf X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ad@astral-on.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Nov 2004 20:34:06 -0000 Hello people. I have ipcad installed on 2 PC's running 5.3-RELEASE and 5-STABLE from Nov 21. ipcad (ports/net-mgmt/ipcad) provides ability to control them by rsh (ipcad implement rsh server by yourself). While using pf with primitive rulesets rsh stops its working. It seems like pf drop short packets. Using tcpdump -n -e -ttt -i pflog0 I see: ... 294896 rule 1/3(short): pass out on lo0: IP 127.0.0.1.514 > 127.0.0.1.680: FP 0:387(387) ack 18 win 35840 ... Some parts from pfctl -sa output FILTER RULES: pass in quick all pass out quick all ... Counters match 1319 8.1/s bad-offset 0 0.0/s fragment 0 0.0/s short 192 1.2/s normalize 0 0.0/s memory 0 0.0/s ... -- Andrew Degtiariov DA-RIPE From owner-freebsd-net@FreeBSD.ORG Fri Nov 26 20:53:55 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 44AD916A4CE for ; Fri, 26 Nov 2004 20:53:55 +0000 (GMT) Received: from smtp2.compt.com (smtp2.compt.com [204.50.14.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF7F443D3F for ; Fri, 26 Nov 2004 20:53:54 +0000 (GMT) (envelope-from twkonefal@yahoo.ca) Message-ID: <41A797DD.3090209@yahoo.ca> Date: Fri, 26 Nov 2004 12:53:49 -0800 From: Tomasz Konefal MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Odd routing issue X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 26 Nov 2004 20:53:55 -0000 hello, everyone. i've got a funny network layout (it's in transition) and am seeing behaviour from FreeBSD 5.2.1 that's different from an Alcatel 6600-24 and a Nortel 1424T router. that is, when i use FreeBSD to do my routing everything works, but when i use either of the other routers things don't work. there's a VIVID router we're phasing out, see below. i'll outline the network layout below and how things fail on the alcatel and the nortel. when the vivid disappears from the picture our routing issues clear up immedeately, but my question is: does the FreeBSD router work in the scenario below because of a bug or because of a feature? +-----------+ +==========+ | firewall |======| INTERNET | | 10.0.1.5 | +==========+ +-----------+ | | | route: 10.0.3.0/24 | next hop: 10.0.2.64 +-------------+ +---------------+ +------------------------+ | 10.0.1.0/24 |---| VIVID router |-----| Alcatel/Nortel/FreeBSD |<=HERE +-------------+ | 10.0.1.254 | | 10.0.1.1 10.0.2.48 | IP:10.0.1.x +---------------+ +------------------------+ GW:10.0.1.254 route: default route: default | next hop: 10.0.1.1 next hop: 10.0.1.5 | | | +----------------------+ | metro network router | | 10.0.2.64 | +----------------------+ | +===============+ | metro network | | 10.0.3.0/24 | +===============+ so, the network looks like the diagram above. putting aside the fact that this is a pretty dumb layout, i'm curious why the router point labeled "<=HERE" acts the way it does. when FreeBSD 5.2.1 (haven't tried other releases) is doing the routing at that spot all the workstations in the 10.0.1.0/24 block can see the internet and the metro network and vice versa. when the alcatel 6600-24 or the nortel 1424T is in that place all routing to the internet and to the metro network fails even though the routing tables are the same. can someone shed some light on this for me? is it possible than Spanning Tree Protocol is getting involved on the nortel and the alcatel or perhaps some other feature? note, i'm not inquiring on how to fix my network layout, only why FreeBSD works in this scenario while other equipment fails. thanks! Tomasz From owner-freebsd-net@FreeBSD.ORG Sat Nov 27 12:01:52 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3B12E16A4CE; Sat, 27 Nov 2004 12:01:52 +0000 (GMT) Received: from insomnia.benzedrine.cx (insomnia.benzedrine.cx [62.65.145.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6292743D5D; Sat, 27 Nov 2004 12:01:51 +0000 (GMT) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (dhartmei@localhost [127.0.0.1]) iARC1nMZ022263 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Sat, 27 Nov 2004 13:01:50 +0100 (MET) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.13.1/8.12.10/Submit) id iARC1n57008056; Sat, 27 Nov 2004 13:01:49 +0100 (MET) Date: Sat, 27 Nov 2004 13:01:49 +0100 From: Daniel Hartmeier To: freebsd-net@freebsd.org, freebsd-current@freebsd.org Message-ID: <20041127120149.GE23786@insomnia.benzedrine.cx> References: <20041126203354.GB81834@astral-on.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041126203354.GB81834@astral-on.net> User-Agent: Mutt/1.4.1i Subject: Re: rsh is malfunctioning due to pf X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 27 Nov 2004 12:01:52 -0000 On Fri, Nov 26, 2004 at 10:33:54PM +0200, Andrew Degtiariov wrote: > I have ipcad installed on 2 PC's running 5.3-RELEASE and 5-STABLE from > Nov 21. ipcad (ports/net-mgmt/ipcad) provides ability to control them > by rsh (ipcad implement rsh server by yourself). While using pf with > primitive rulesets rsh stops its working. It seems like pf drop short > packets. The 'short' reason is a little overloaded, it can have two meanings. The less likely case is where the mbuf didn't contain a complete IP header. More likely, the packet contains IP options, which pf blocks by default. You can isolate the problem by a) enabling debug logging with pfctl -xm and watching the console or /var/log/messages for messages from 'pf: ' b) dumping an entire packet that is being blocked, with tcpdump -s 1600 -nvvvetttSXi pflog0 c) adding 'allow-opts' to all your pass rules and see if the problem goes away Daniel From owner-freebsd-net@FreeBSD.ORG Sat Nov 27 14:08:16 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F3D416A4CE; Sat, 27 Nov 2004 14:08:16 +0000 (GMT) Received: from therion.astral-on.net (therion.astral-on.net [193.41.4.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7ACF543D49; Sat, 27 Nov 2004 14:08:14 +0000 (GMT) (envelope-from ad@astral-on.net) Received: from odin.astral-on.net (odin.astral-on.net [193.41.4.6]) iARE7AFs093427; Sat, 27 Nov 2004 16:07:12 +0200 (EET) (envelope-from ad@astral-on.net) Received: from odin.astral-on.net (localhost [127.0.0.1]) by odin.astral-on.net (8.12.8p2/8.12.8) with ESMTP id iARE7Awk027914; Sat, 27 Nov 2004 16:07:10 +0200 (EET) (envelope-from ad@odin.astral-on.net) Received: (from ad@localhost) by odin.astral-on.net (8.12.8p2/8.12.8/Submit) id iARE77BV027913; Sat, 27 Nov 2004 16:07:07 +0200 (EET) Date: Sat, 27 Nov 2004 16:07:07 +0200 From: Andrew Degtiariov To: Daniel Hartmeier Message-ID: <20041127140707.GA20356@astral-on.net> Mail-Followup-To: Daniel Hartmeier , freebsd-net@freebsd.org, freebsd-current@freebsd.org References: <20041126203354.GB81834@astral-on.net> <20041127120149.GE23786@insomnia.benzedrine.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041127120149.GE23786@insomnia.benzedrine.cx> User-Agent: Mutt/1.5.6i cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: rsh is malfunctioning due to pf X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ad@astral-on.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Nov 2004 14:08:16 -0000 On Sat, Nov 27, 2004 at 01:01:49PM +0100, Daniel Hartmeier wrote: > On Fri, Nov 26, 2004 at 10:33:54PM +0200, Andrew Degtiariov wrote: > > > I have ipcad installed on 2 PC's running 5.3-RELEASE and 5-STABLE from > > Nov 21. ipcad (ports/net-mgmt/ipcad) provides ability to control them > > by rsh (ipcad implement rsh server by yourself). While using pf with > > primitive rulesets rsh stops its working. It seems like pf drop short > > packets. > > The 'short' reason is a little overloaded, it can have two meanings. > The less likely case is where the mbuf didn't contain a complete IP > header. More likely, the packet contains IP options, which pf blocks by > default. You can isolate the problem by > > a) enabling debug logging with pfctl -xm and watching the console > or /var/log/messages for messages from 'pf: ' > b) dumping an entire packet that is being blocked, with > tcpdump -s 1600 -nvvvetttSXi pflog0 > c) adding 'allow-opts' to all your pass rules and see if the problem > goes away Yes, allow-opts restored ipcad functionality. Probality need to add warning to pf documentation about this behavior, b/c enabling pf broke multicast (ospf for me) with out rules with allow-opts. I was see note about it exists only in pf.conf (in allow-opts description) and leave out it unnoticed while read this manual page. -- Andrew Degtiariov DA-RIPE From owner-freebsd-net@FreeBSD.ORG Sat Nov 27 21:55:48 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 11F0116A4CE; Sat, 27 Nov 2004 21:55:48 +0000 (GMT) Received: from mail.dragondata.com (server3-a.your.org [64.202.112.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id ABE1443D60; Sat, 27 Nov 2004 21:55:47 +0000 (GMT) (envelope-from toasty@dragondata.com) Received: from localhost (localhost.your.org [127.0.0.1]) by mail.dragondata.com (Postfix) with ESMTP id 3BDF33D1C59; Sat, 27 Nov 2004 15:55:47 -0600 (CST) Received: from mail.dragondata.com ([127.0.0.1]) by localhost (server3.dragondata.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 41405-01-69; Sat, 27 Nov 2004 15:55:47 -0600 (CST) Received: by mail.dragondata.com (Postfix, from userid 1000) id 13EEC3D1C4A; Sat, 27 Nov 2004 15:55:47 -0600 (CST) Received: from [69.31.99.45] (pool045.dhcp.your.org [69.31.99.45]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mail.dragondata.com (Postfix) with ESMTP id AF3843D1C1D; Sat, 27 Nov 2004 15:55:45 -0600 (CST) Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <35FC873E-40BF-11D9-8850-000A95A8A1F2@dragondata.com> Content-Transfer-Encoding: 7bit From: Kevin Day Date: Sat, 27 Nov 2004 15:56:37 -0600 To: freebsd-net@freebsd.org X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server3.dragondata.com X-Spam-Level: X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.63 languages=en bayes=0.5 X-Virus-Scanned: by amavisd-new at dragondata.com cc: rwatson@freebsd.org Subject: em(4) VLAN + PROMISC still doesn't work with latest CVS version X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 27 Nov 2004 21:55:48 -0000 I recently upgraded to 5.3 on a system, and manually upgraded src/sys/dev/em/* to the latest RELENG_5 versions. (1.44.2.4 of if_em.c) While the VLAN side of things works better than the stock 5.3 version, there still is this problem: ifconfig vlan1 create ifconfig vlan1 vlan 1 vlandev em1 link0 ifconfig vlan2 create ifconfig vlan2 vlan 2 vlandev em1 link0 ifconfig vlan3 create ifconfig vlan3 vlan 3 vlandev em1 link0 ifconfig vlan1 inet 192.aaa.bbb.129 netmask 255.255.255.0 ifconfig vlan2 inet 64.ccc.ddd.61 netmask 255.255.255.192 ifconfig vlan3 inet 64.eee.fff.61 netmask 255.255.255.192 ifconfig em1 up ifconfig em1 promisc If I do this, vlan1 and vlan3 work fine. Vlan2 can receive packets, but anything sent out vlan2 doesn't seem to be heard by any foreign hosts. Setting "ifconfig em1 -promisc" makes all vlans work properly. This is better than the stock 5.3 version of em(4) where none of the vlans worked, but something still isn't right. Is this a known problem still or am I just doing something wrong?