From owner-freebsd-net@FreeBSD.ORG Sun Nov 14 02:45: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 1D22516A4CE for ; Sun, 14 Nov 2004 02:45:19 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id BBBD043D4C for ; Sun, 14 Nov 2004 02:45:18 +0000 (GMT) (envelope-from mike@sentex.net) Received: from BLUELAPIS.sentex.ca (cage.simianscience.com [64.7.134.1]) by smarthost2.sentex.ca (8.13.1/8.13.1) with SMTP id iAE2jHvX014331; Sat, 13 Nov 2004 21:45:17 -0500 (EST) (envelope-from mike@sentex.net) From: Mike Tancsa To: Bruce M Simpson Date: Sat, 13 Nov 2004 21:45:26 -0500 Message-ID: <7lhdp0l2i9l94gunj0qdenaavl3o667r9m@4ax.com> References: <4194CDF9.3000609@mr0vka.eu.org> <20041112210716.GC830@empiric.icir.org> In-Reply-To: <20041112210716.GC830@empiric.icir.org> X-Mailer: Forte Agent 1.93/32.576 English (American) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: ClamAV 0.80/580/Tue Nov 9 04:53:00 2004 clamav-milter version 0.80j on clamscanner3 X-Virus-Status: Clean cc: freebsd-net@freebsd.org Subject: Re: OpenBGPd? 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, 14 Nov 2004 02:45:19 -0000 On Fri, 12 Nov 2004 13:07:16 -0800, in sentex.lists.freebsd.net you wrote: >On Fri, Nov 12, 2004 at 03:51:37PM +0100, ?ukasz Bromirski wrote: >> Is anyone working on a port of OpenBGPd, or current version of Quagga >> (0.97.3)? > >I'm not, but I intend to commit a port of XORP immediately after the >next point release. Are there advantages to XORP over say Quaaga ? =20 ---Mike > >BMS >_______________________________________________ >freebsd-net@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-net >To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sun Nov 14 18:28: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 10BFB16A4CE for ; Sun, 14 Nov 2004 18:28:59 +0000 (GMT) Received: from istanbul.enderunix.org (freefall.marmara.edu.tr [193.140.143.23]) by mx1.FreeBSD.org (Postfix) with SMTP id F0A2F43D4C for ; Sun, 14 Nov 2004 18:28:56 +0000 (GMT) (envelope-from ofsen@enderunix.org) Received: (qmail 67212 invoked by uid 89); 14 Nov 2004 18:29:02 -0000 Message-ID: <20041114182901.67208.qmail@istanbul.enderunix.org> References: <4194CDF9.3000609@mr0vka.eu.org> <41961690.8040406@he.iki.fi> <200411131712.22388.max@love2party.net> In-Reply-To: <200411131712.22388.max@love2party.net> From: Omer Faruk Sen To: Max Laier Date: Sun, 14 Nov 2004 20:29:00 +0200 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-9" Content-Transfer-Encoding: 8bit cc: freebsd-net@freebsd.org cc: net@freebsd.org Subject: Re: OpenBGPd? 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, 14 Nov 2004 18:28:59 -0000 I have downloaded openbgpd 3.6 but can not compile it. pfkey.c:24:29: netinet/ip_ipsp.h: No such file or directory pkey.c: In function `pfkey_send': pfkey.c:70: error: storage size of 'sa_flowtype' isn't known pfkey.c:70: error: storage size of 'sa_protocol' isn't known pfkey.c:159: error: `SADB_X_ADDFLOW' undeclared (first use in There must be a equivalent of ip_ipsh.h in FreeBSD but which header file. Or should it be implemented? Since I couldn't find sa_flowtype in FreeBSD /usr/include directory Max Laier writes: > On Saturday 13 November 2004 15:13, Petri Helenius wrote: >> Łukasz Bromirski wrote: >> > Hi, >> > >> > Is anyone working on a port of OpenBGPd, or current version of Quagga >> > (0.97.3)? >> >> openbgpd compiles fairly painlessly on 5.3. Making it work on 5.2.1 was >> definetly more work. > > Do you mind to submitt it as a port? > > -- > /"\ Best regards, | mlaier@freebsd.org > \ / Max Laier | ICQ #67774661 > X http://pf4freebsd.love2party.net/ | mlaier@EFnet > / \ ASCII Ribbon Campaign | Against HTML Mail and News ----------------------- Omer Faruk Sen http://www.EnderUNIX.ORG Software Development Team @ Turkey http://www.Faruk.NET For Public key: http://www.enderunix.org/ofsen/ofsen.asc ******************************************************** First Turkish FreeBSD book is out! Go check it. Duydunuz mu! Turkiye'nin ilk FreeBSD kitabi cikti. http://www.acikkod.com/freebsd.php From owner-freebsd-net@FreeBSD.ORG Sun Nov 14 18:28: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 1170016A4D1 for ; Sun, 14 Nov 2004 18:28:59 +0000 (GMT) Received: from istanbul.enderunix.org (freefall.marmara.edu.tr [193.140.143.23]) by mx1.FreeBSD.org (Postfix) with SMTP id F05E043D2F for ; Sun, 14 Nov 2004 18:28:56 +0000 (GMT) (envelope-from ofsen@enderunix.org) Received: (qmail 67212 invoked by uid 89); 14 Nov 2004 18:29:02 -0000 Message-ID: <20041114182901.67208.qmail@istanbul.enderunix.org> References: <4194CDF9.3000609@mr0vka.eu.org> <41961690.8040406@he.iki.fi> <200411131712.22388.max@love2party.net> In-Reply-To: <200411131712.22388.max@love2party.net> From: Omer Faruk Sen To: Max Laier Date: Sun, 14 Nov 2004 20:29:00 +0200 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-9" Content-Transfer-Encoding: 8bit cc: freebsd-net@freebsd.org cc: net@freebsd.org Subject: Re: OpenBGPd? 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, 14 Nov 2004 18:28:59 -0000 I have downloaded openbgpd 3.6 but can not compile it. pfkey.c:24:29: netinet/ip_ipsp.h: No such file or directory pkey.c: In function `pfkey_send': pfkey.c:70: error: storage size of 'sa_flowtype' isn't known pfkey.c:70: error: storage size of 'sa_protocol' isn't known pfkey.c:159: error: `SADB_X_ADDFLOW' undeclared (first use in There must be a equivalent of ip_ipsh.h in FreeBSD but which header file. Or should it be implemented? Since I couldn't find sa_flowtype in FreeBSD /usr/include directory Max Laier writes: > On Saturday 13 November 2004 15:13, Petri Helenius wrote: >> Łukasz Bromirski wrote: >> > Hi, >> > >> > Is anyone working on a port of OpenBGPd, or current version of Quagga >> > (0.97.3)? >> >> openbgpd compiles fairly painlessly on 5.3. Making it work on 5.2.1 was >> definetly more work. > > Do you mind to submitt it as a port? > > -- > /"\ Best regards, | mlaier@freebsd.org > \ / Max Laier | ICQ #67774661 > X http://pf4freebsd.love2party.net/ | mlaier@EFnet > / \ ASCII Ribbon Campaign | Against HTML Mail and News ----------------------- Omer Faruk Sen http://www.EnderUNIX.ORG Software Development Team @ Turkey http://www.Faruk.NET For Public key: http://www.enderunix.org/ofsen/ofsen.asc ******************************************************** First Turkish FreeBSD book is out! Go check it. Duydunuz mu! Turkiye'nin ilk FreeBSD kitabi cikti. http://www.acikkod.com/freebsd.php From owner-freebsd-net@FreeBSD.ORG Sun Nov 14 21:12: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 35D4E16A4CE for ; Sun, 14 Nov 2004 21:12:19 +0000 (GMT) Received: from mail.pogozone.net (pogo02.pogozone.net [216.57.201.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B99E43D45 for ; Sun, 14 Nov 2004 21:12:18 +0000 (GMT) (envelope-from jbarrett@amduat.net) Received: from [10.0.0.69] (client-220-234.bhm.pogozone.net [216.57.220.234]) (AUTH: LOGIN jbarrett@pogozone.net, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by mail.pogozone.net with esmtp; Sun, 14 Nov 2004 13:12:17 -0800 From: "Jacob S. Barrett" To: freebsd-net@freebsd.org Date: Sun, 14 Nov 2004 13:11:49 -0800 User-Agent: KMail/1.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200411141311.49502.jbarrett@amduat.net> Subject: Universal Client Gateway 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, 14 Nov 2004 21:12:19 -0000 I am trying to make what some call a universal client gateway. Finding anything via google on the subject is turning up nothing. Basically I want setup a gateway that will masquerade IP from any host reguardless of its IP configuration. For example if a host is configured with IP 192.168.2.2 and a gateway of 192.168.2.1 my gateway would reply to ARP requests for 192.168.2.1. When the host forwards its IP traffic to me I would masquerade the packet with my IP and forward it. When the reply comes back my gateway would de-masquerade the packet and forward it back the host. I have it all working except for the return forwarding. For proxying the configured gateway address for incoming packets I running arpd on the LAN interface. It replies to all unclaimed IP addresses. So when the host ARPs for 192.168.2.2 it replies with my gateways MAC. This works great. For the return path I have tried a few things with no luck. ARP hacks: I first looked into adding an ARP entry using arp(8), but since no interfaces have subnets that matches the hosts IP it won't add it. Also arp(8) doesn't support specifying an interface to force assignment. If I wrote my own program to force an entry into the ARP table with the correct interface would that work? Route hacks: I then tried adding a route entry for the LAN interface. I used the command: route add -host 192.168.2.2 -interface vlan1000 This produces a route entry that looks promising: 192.168.2.2 vlan1000:0.xx.xx.xx.xx.aa UHLS 0 0 vlan10 But when you dump the arp tables we see: ? (192.168.2.2) at 00:xx:xx:xx:xx:aa on vlan1000 permanent [vlan] Which is the MAC address of the gateway and not the host. What I really want is an routing entry that looks like a normal local host: 192.168.0.27 0.xx.xx.xx.xx.bb UHLW 1 4953 vlan10 904 I have tried several combinations of commands with route(8) with no luck. Is there a way to add the route as a direct route to 0.xx.xx.xx.xx.cc? Can I do it if I write my own program to add the route to the table? I don't want to go the route of adding the faked gateway address to the interface with matching subnet to fit the client's IP in. The problem with that is if a client is configure with IP 10.0.0.1/8 with a gateway of 10.255.255.254 the smallest subnet I could create would be /8. And that would mostlikely cause problems for connectly configured hosts trying to communicate to 10/8. So does anyone understand what I am trying to do? Do you know how to do it? Am I going about this all wrong? -- Jacob S. Barrett jbarrett@amduat.net www.amduat.net "I don't suffer from insanity, I enjoy every minute of it." From owner-freebsd-net@FreeBSD.ORG Sun Nov 14 22:14: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 3C12516A4CE for ; Sun, 14 Nov 2004 22:14:50 +0000 (GMT) Received: from pimout3-ext.prodigy.net (pimout3-ext.prodigy.net [207.115.63.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA8B043D48 for ; Sun, 14 Nov 2004 22:14:48 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [192.168.1.102] (adsl-68-123-122-146.dsl.snfc21.pacbell.net [68.123.122.146])iAEMEUha259984; Sun, 14 Nov 2004 17:14:35 -0500 Message-ID: <4197D8C5.5050601@elischer.org> Date: Sun, 14 Nov 2004 14:14:29 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8a3) Gecko/20041017 X-Accept-Language: en, hu MIME-Version: 1.0 To: "Jacob S. Barrett" References: <200411141311.49502.jbarrett@amduat.net> In-Reply-To: <200411141311.49502.jbarrett@amduat.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: Universal Client Gateway 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, 14 Nov 2004 22:14:50 -0000 Jacob S. Barrett wrote: > I am trying to make what some call a universal client gateway. Finding > anything via google on the subject is turning up nothing. Basically I want > setup a gateway that will masquerade IP from any host reguardless of its IP > configuration. For example if a host is configured with IP 192.168.2.2 and a > gateway of 192.168.2.1 my gateway would reply to ARP requests for > 192.168.2.1. When the host forwards its IP traffic to me I would masquerade > the packet with my IP and forward it. When the reply comes back my gateway > would de-masquerade the packet and forward it back the host. I have it all > working except for the return forwarding. > [...] > > So does anyone understand what I am trying to do? Do you know how to do it? > Am I going about this all wrong? > sounds like you just want to run natd. From owner-freebsd-net@FreeBSD.ORG Mon Nov 15 00:23: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 BA5B116A4CE for ; Mon, 15 Nov 2004 00:23:40 +0000 (GMT) Received: from mail.pogozone.net (pogo02.pogozone.net [216.57.201.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F3AF43D3F for ; Mon, 15 Nov 2004 00:23:40 +0000 (GMT) (envelope-from jbarrett@amduat.net) Received: from [10.0.0.69] (client-220-234.bhm.pogozone.net [216.57.220.234]) (AUTH: LOGIN jbarrett@pogozone.net, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by mail.pogozone.net with esmtp; Sun, 14 Nov 2004 16:23:39 -0800 From: "Jacob S. Barrett" To: freebsd-net@freebsd.org Date: Sun, 14 Nov 2004 16:23:08 -0800 User-Agent: KMail/1.7.1 References: <200411141311.49502.jbarrett@amduat.net> <4197D8C5.5050601@elischer.org> In-Reply-To: <4197D8C5.5050601@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200411141623.10060.jbarrett@amduat.net> Subject: Re: Universal Client Gateway 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, 15 Nov 2004 00:23:40 -0000 On Sunday 14 November 2004 02:14 pm, Julian Elischer wrote: > sounds like you just want to run natd. I do for all the traffic exiting the WAN interface. I am doing that and I can pass traffic from the host through the universal proxy to the destination. The traffic coming back from the destination enters WAN interface and natd and is translated back to the host interface but gets routed back out the WAN (default route) since the host is not local. I need to be able to spoof the routing table into forwarding the packet back out the LAN internface. Maybe the example below will help. Host A: (static roaming client) IP: 192.168.0.3/24 Gateway: 192.168.0.1 DNS: 192.168.0.1,192.168.0.2 Host B: (dhcp client) IP: 10.0.0.3/24 Gateway: 10.0.0.1/24 DNS: 10.0.0.1, 10.0.0.2 Gateway: Gateway: 1.2.3.4 DNS: 1.2.3.4, 1.2.3.5 LAN: IP: 10.0.0.1/24 arpd WAN IP: 1.2.3.6/24 natd Remote C: IP 4.5.6.7 So above we see that Host B will communicate normally. All traffic for host B will travel in Gateway LAN and out natd on the WAN. All returning traffic for Host B will come in the WAN natd and out LAN on Gateway. All normal stuff. Now if we look at host A. To send to Remote C it must forward through the gateway at 192.168.0.1, which obviously doesn't exist. A ARPs for 192.168.0.1. Gateway replies to the ARP with its MAC address (proxy arp with arpd). A forwards the packet to Gateway thinking it is 192.168.0.1. As expected the packet enters LAN (192.168.0.3->4.5.6.7) passes through natd (1.2.3.6->4.5.6.7) and exits WAN. The response from C comes back in WAN (4.5.6.7->1.2.3.6) through natd (4.5.6.7->192.168.0.3) like normal. Now we have a problem. Gateway needs to forward the packet to 192.168.0.3 (Host A). It doesn't have an interface that is on the subnet so it forwards to the default gateway again. It goes back out through natd and WAN. What I need to do is figure out how to trick the routing table into thinking it can just forward the packet to the LAN interface for local delivery. -- Jacob S. Barrett jbarrett@amduat.net www.amduat.net "I don't suffer from insanity, I enjoy every minute of it." From owner-freebsd-net@FreeBSD.ORG Mon Nov 15 00:49: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 59B3816A4CE for ; Mon, 15 Nov 2004 00:49:19 +0000 (GMT) Received: from pit.databus.com (p70-227.acedsl.com [66.114.70.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id A761F43D31 for ; Mon, 15 Nov 2004 00:49:18 +0000 (GMT) (envelope-from barney@pit.databus.com) Received: from pit.databus.com (localhost [127.0.0.1]) by pit.databus.com (8.13.1/8.13.1) with ESMTP id iAF0n5jt004422; Sun, 14 Nov 2004 19:49:05 -0500 (EST) (envelope-from barney@pit.databus.com) Received: (from barney@localhost) by pit.databus.com (8.13.1/8.13.1/Submit) id iAF0n5nE004421; Sun, 14 Nov 2004 19:49:05 -0500 (EST) (envelope-from barney) Date: Sun, 14 Nov 2004 19:49:05 -0500 From: Barney Wolff To: "Jacob S. Barrett" Message-ID: <20041115004905.GA4275@pit.databus.com> References: <200411141311.49502.jbarrett@amduat.net> <4197D8C5.5050601@elischer.org> <200411141623.10060.jbarrett@amduat.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200411141623.10060.jbarrett@amduat.net> User-Agent: Mutt/1.5.6i X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 cc: freebsd-net@freebsd.org Subject: Re: Universal Client Gateway 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, 15 Nov 2004 00:49:19 -0000 On Sun, Nov 14, 2004 at 04:23:08PM -0800, Jacob S. Barrett wrote: > On Sunday 14 November 2004 02:14 pm, Julian Elischer > wrote: > > sounds like you just want to run natd. > > I do for all the traffic exiting the WAN interface. I am doing that and I can > pass traffic from the host through the universal proxy to the destination. > The traffic coming back from the destination enters WAN interface and natd > and is translated back to the host interface but gets routed back out the WAN > (default route) since the host is not local. I need to be able to spoof the > routing table into forwarding the packet back out the LAN internface. When you have arpd (probably modified slightly) answer for a new "gateway" address, add it as an alias to the interface on which the arp request was received, with a netmask that will cover the address from which the request came. Then responses to the original requester will naturally go back out the right interface. Of course, this is all pretty pointless. It would be better to force the clients to use dhcp, even if they're transients. Also, it's rather dangerous - would you notice if such a client claimed to have the IP address of your Internet gateway, and thus captured everybody's traffic? -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. From owner-freebsd-net@FreeBSD.ORG Mon Nov 15 05:31:31 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 B47F716A4CE for ; Mon, 15 Nov 2004 05:31:31 +0000 (GMT) Received: from smtp814.mail.sc5.yahoo.com (smtp814.mail.sc5.yahoo.com [66.163.170.84]) by mx1.FreeBSD.org (Postfix) with SMTP id 7207B43D41 for ; Mon, 15 Nov 2004 05:31:31 +0000 (GMT) (envelope-from garbage@injvstice.com) Received: from unknown (HELO rapt0r) (drop?box@sbcglobal.net@70.241.29.105 with login) by smtp814.mail.sc5.yahoo.com with SMTP; 15 Nov 2004 05:31:30 -0000 From: "Val P" To: Date: Sun, 14 Nov 2004 23:31:24 -0600 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTK1EoucZQRx97wSyqJuI404sR5Ug== Message-Id: <20041115053131.7207B43D41@mx1.FreeBSD.org> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: OACTIVE on bge 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, 15 Nov 2004 05:31:31 -0000 We have a bridge running fbsd 4.8, and both ends of the interface are running broadcomm gigabit fiber NICs (bge2 and bge3). Periodically we see the bridge lock up with bge2 in state OACTIVE. We have resorted to having a script that periodically checks ifconfig and downs/reups the offending iface when this happens. Of course, sometimes this starts happening quite often and it creates havoc with established connections. This is not a good solution, but it's best we could have come up with. We are using this bridge in conjunction with IPF as a transparent firewall. Is this a known issue? Is there something we can fix? We are happy with 4.x but we'd consider upgrading to 5.3 if it fixed this problem. The bridge connects an Extreme Networks Black Diamond and a Foundry Big Iron... Here's the state when this happens: bge2: flags=8943 mtu 1500 options=3 media: Ethernet autoselect (1000baseSX ) status: active bge3: flags=9d43 \ mtu 1500 options=3 media: Ethernet autoselect (1000baseSX ) status: active ... 2139/2256/26624 mbufs in use (current/peak/max): 2139 mbufs allocated to data 1584/1692/6656 mbuf clusters in use (current/peak/max) 3948 Kbytes allocated to network (19% of mb_map in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines From owner-freebsd-net@FreeBSD.ORG Mon Nov 15 10:43:38 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 5ECC316A4CE; Mon, 15 Nov 2004 10:43:38 +0000 (GMT) Received: from relay.bestcom.ru (relay.bestcom.ru [217.72.144.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8695A43D49; Mon, 15 Nov 2004 10:43:37 +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 iAFAhW3V079147 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 15 Nov 2004 13:43:33 +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 iAFAhW6r093546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Nov 2004 13:43:32 +0300 (MSK) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id iAFAhVtI093545; Mon, 15 Nov 2004 13:43:31 +0300 (MSK) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Mon, 15 Nov 2004 13:43:31 +0300 From: Gleb Smirnoff To: julian@freebsd.org, archie@freebsd.org Message-ID: <20041115104331.GA93477@cell.sick.ru> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="MGYHOYXEY6WxJCY8" 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 cc: maxim@freebsd.org cc: rwatson@freebsd.org cc: net@freebsd.org Subject: divert(4) socket isn't connection oriented 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, 15 Nov 2004 10:43:38 -0000 --MGYHOYXEY6WxJCY8 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Hi! I've spent several days digging in interaction between divert protocol and ng_ksocket. I've find some oddities in there. Look at div_output(), it tells incoming packet from outgoing by presence of sockaddr_in structure. Depending on it packet is passed either to ip_input() or ip_output(). This sockaddr_in was previuosly supplied by divert interface to application at the end of divert_packet() with help of sbappendaddr_locked(). Look at ng_ksocket_incoming2(), near 'pru_soreceive'. When ng_ksocket takes data from socket it saves supplied sockaddr in m_tag attached to packet. After packet travel thru netgraph(4) it may return to ng_ksocket in ng_ksocket_rcvdata() and this sockaddr will be used in call to sosend(). It is important that ng_ksocket does not save sockaddr if socket is connected (see ng_ksocket_incoming2(), near 'pru_soreceive'). And this is correct! If a generic socket is connected, all data must be sent to connection destination. The problem is that divert(4) socket is always marked as connected (see end of div_attach()), and thus ng_ksocket_rcvdata() does not supply sockaddr in call to sosend(). So div_output() _always_ sends data to ip_output()! This is strange and odd but working - packets flow in both directions. This setup is working: /usr/sbin/ngctl -f- <<-SEQ mkpeer echo dummy dummy name .:dummy echo_div mkpeer echo_div: ksocket echo inet/raw/divert name echo_div:echo div_sock rmhook dummy msg div_sock: bind inet/0.0.0.0:8888 SEQ ipfw add 1 divert 8888 all from any to any via fxp0 in ping -c 1 www.com Since it is working, it was not noticed quickly. Real problems occur when a multicast packet comes on interface: it is diverted to ng_ksocket, returned and div_output() sends it to ip_output(). In ip_output() it is ip_mloopback()ed and if_simloop()ed. A copy of packet enters divert socket, duplicated... a forever loop and total freeze. Removing 'always connected status' from divert sockets fixes the problem and incoming packets go into ip_input(), not ip_output(). Please review attached patch. It: - removes SS_ISCONNECTED from so->so_state - removes pru_disconnect method, since it won't be called - removes pru_abort method, since it must not be called on divert socket. It was used indirectly via disconnect method. With this patch codepath of packets is correct and incoming packets do not enter ip_output() anymore. An alternative may be adding a kludge in ng_ksocket_incoming2(), so that sockaddr is saved always if socket is a divert socket. I don't like it. Awaiting for your feedback! -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE --MGYHOYXEY6WxJCY8 Content-Type: text/plain; charset=koi8-r Content-Disposition: attachment; filename="ip_divert.c.diff" Index: ip_divert.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_divert.c,v retrieving revision 1.109 diff -u -r1.109 ip_divert.c --- ip_divert.c 12 Nov 2004 22:17:42 -0000 1.109 +++ ip_divert.c 15 Nov 2004 10:14:37 -0000 @@ -415,12 +415,7 @@ inp->inp_ip_p = proto; inp->inp_vflag |= INP_IPV4; inp->inp_flags |= INP_HDRINCL; - /* The socket is always "connected" because - we always know "where" to send the packet */ INP_UNLOCK(inp); - SOCK_LOCK(so); - so->so_state |= SS_ISCONNECTED; - SOCK_UNLOCK(so); return 0; } @@ -442,32 +437,6 @@ } static int -div_abort(struct socket *so) -{ - struct inpcb *inp; - - INP_INFO_WLOCK(&divcbinfo); - inp = sotoinpcb(so); - if (inp == 0) { - INP_INFO_WUNLOCK(&divcbinfo); - return EINVAL; /* ??? possible? panic instead? */ - } - INP_LOCK(inp); - soisdisconnected(so); - in_pcbdetach(inp); - INP_INFO_WUNLOCK(&divcbinfo); - return 0; -} - -static int -div_disconnect(struct socket *so) -{ - if ((so->so_state & SS_ISCONNECTED) == 0) - return ENOTCONN; - return div_abort(so); -} - -static int div_bind(struct socket *so, struct sockaddr *nam, struct thread *td) { struct inpcb *inp; @@ -662,12 +631,10 @@ #endif struct pr_usrreqs div_usrreqs = { - .pru_abort = div_abort, .pru_attach = div_attach, .pru_bind = div_bind, .pru_control = in_control, .pru_detach = div_detach, - .pru_disconnect = div_disconnect, .pru_peeraddr = div_peeraddr, .pru_send = div_send, .pru_shutdown = div_shutdown, --MGYHOYXEY6WxJCY8-- From owner-freebsd-net@FreeBSD.ORG Mon Nov 15 11:02: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 D18C816A4CE for ; Mon, 15 Nov 2004 11:02:12 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id C477243D2D for ; Mon, 15 Nov 2004 11:02:12 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.11/8.12.11) with ESMTP id iAFB2CEV074646 for ; Mon, 15 Nov 2004 11:02:12 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id iAFB2Cua074640 for freebsd-net@freebsd.org; Mon, 15 Nov 2004 11:02:12 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 15 Nov 2004 11:02:12 GMT Message-Id: <200411151102.iAFB2Cua074640@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, 15 Nov 2004 11:02:13 -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 2 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Nov 15 14:30: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 1E34416A4CE; Mon, 15 Nov 2004 14:30:06 +0000 (GMT) Received: from mxsf11.cluster1.charter.net (mxsf11.cluster1.charter.net [209.225.28.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id 66D6C43D49; Mon, 15 Nov 2004 14:30:05 +0000 (GMT) (envelope-from archie@dellroad.org) Received: from mxip09.cluster1.charter.net (mxip09a.cluster1.charter.net [209.225.28.139])iAFEU3iF029709; Mon, 15 Nov 2004 09:30:03 -0500 Received: from cable-68-113-94-164.mtv.al.charter.com (HELO InterJet.dellroad.org) (68.113.94.164) by mxip09.cluster1.charter.net with ESMTP; 15 Nov 2004 09:30:03 -0500 X-Ironport-AV: i="3.87,88,1099285200"; d="scan'208"; a="419375156:sNHT12725424" Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.2.2.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id IAA58236; Mon, 15 Nov 2004 08:17:42 -0600 (CST) Received: from arch20m.dellroad.org (localhost [127.0.0.1]) iAFEHg6t015172; Mon, 15 Nov 2004 08:17:42 -0600 (CST) (envelope-from archie@arch20m.dellroad.org) Received: (from archie@localhost) by arch20m.dellroad.org (8.12.9p2/8.12.9/Submit) id iAFEHfhN015171; Mon, 15 Nov 2004 08:17:42 -0600 (CST) (envelope-from archie) From: Archie Cobbs Message-Id: <200411151417.iAFEHfhN015171@arch20m.dellroad.org> In-Reply-To: <20041115104331.GA93477@cell.sick.ru> To: Gleb Smirnoff Date: Mon, 15 Nov 2004 08:17:41 -0600 (CST) X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII cc: maxim@freebsd.org cc: rwatson@freebsd.org cc: net@freebsd.org Subject: Re: divert(4) socket isn't connection oriented 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, 15 Nov 2004 14:30:06 -0000 Gleb Smirnoff wrote: > Since it is working, it was not noticed quickly. Real problems occur when > a multicast packet comes on interface: it is diverted to ng_ksocket, returned > and div_output() sends it to ip_output(). In ip_output() it is ip_mloopback()ed > and if_simloop()ed. A copy of packet enters divert socket, duplicated... a > forever loop and total freeze. Your fix makes sense, but is it more of a workaround than a proper fix? It seems like the real bug is that divert is promising to write the packet as "outgoing" yet the packet loops back as "incoming". Maybe it would make more sense to attach a tag to the packet that divert would recognize and know to ignore the extra incoming packet. Also, does the same thing happen with broadcast packets? -Archie __________________________________________________________________________ Archie Cobbs * CTO, Awarix * http://www.awarix.com From owner-freebsd-net@FreeBSD.ORG Mon Nov 15 17:28:29 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 4679416A4CE; Mon, 15 Nov 2004 17:28:29 +0000 (GMT) Received: from ptcnat.era.pl (ptcnat.era.pl [213.158.197.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id BBA0143D46; Mon, 15 Nov 2004 17:28:28 +0000 (GMT) (envelope-from zaks@era.pl) Received: by localhost (Postfix, from userid 1001) id 3E28911445; Mon, 15 Nov 2004 18:28:26 +0100 (CET) From: =?iso-8859-2?Q?S=B3awek_=AFak?= To: net@freebsd.org, current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: <20041115172826.3E28911445@localhost> Date: Mon, 15 Nov 2004 18:28:26 +0100 (CET) Subject: route add -host ... -iface issues 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, 15 Nov 2004 17:28:29 -0000 Hi, I'd like to ask why a static arp entry is added when direct route to host is added like this? route add -host target -iface interface The route(8) manpage says, that such route entry is for hosts directly reachable over interface. But when packets go out on this interface, the MAC address of target host in each packet is set to local MAC for the interface, which effectively stops the target host from receiving the packet. Another thing is the order of adding routes in /etc/rc.d/routing of FreeBSD 5.3. The default gateway is added *before* other static routes are setup. Sometimes the default router is unreachable before other static routes are set configured. Is there any reason to not change the line: static_routes="default ${static_routes}" to: static_routes="${static_routes} default" ? /S From owner-freebsd-net@FreeBSD.ORG Mon Nov 15 17:54: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 BF8F316A4CE; Mon, 15 Nov 2004 17:54:47 +0000 (GMT) Received: from vbook.fbsd.ru (asplinux.ru [195.133.213.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32E4943D45; Mon, 15 Nov 2004 17:54:47 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.43 (FreeBSD)) id 1CTl3s-000L9w-VH; Mon, 15 Nov 2004 20:54:45 +0300 From: Vladimir Grebenschikov To: =?iso-8859-2?Q?S=B3awek_=AFak?= In-Reply-To: <20041115172826.3E28911445@localhost> References: <20041115172826.3E28911445@localhost> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Organization: SWsoft Date: Mon, 15 Nov 2004 20:54:43 +0300 Message-Id: <1100541283.935.30.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.0FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov cc: "current@freebsd.org" cc: freebsd-net Subject: Re: route add -host ... -iface issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: vova@fbsd.ru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2004 17:54:47 -0000 =D0=92 =D0=BF=D0=BD, 15/11/2004 =D0=B2 18:28 +0100, S=C5=82awek =C5=BBak = =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > Hi, >=20 > I'd like to ask why a static arp entry is added when direct route to = host is > added like this? >=20 > route add -host target -iface interface >=20 > The route(8) manpage says, that such route entry is for hosts directl= y > reachable over interface. But when packets go out on this interface, = the MAC > address of target host in each packet is set to local MAC for the int= erface, > which effectively stops the target host from receiving the packet. Actually you should instruct routing engine to do ARP lookup if you want to reach some IP address via ethrenet interface directly, like: route add a.b.c.0/24 -iface fxp0 -cloning or, for single host: route add a.b.c.d/32 -iface fxp0 -cloning /32 is important, it actually this enforces network route with netmask 255.255.255.255 to be added into routing table, from my practice, only network routes can be ARP-resolved. > Another thing is the order of adding routes in /etc/rc.d/routing of F= reeBSD > 5.3. The default gateway is added *before* other static routes are > setup. Sometimes the default router is unreachable before other stati= c > routes are set configured. Is there any reason to not change the line= : >=20 > static_routes=3D"default ${static_routes}" >=20 > to: >=20 > static_routes=3D"${static_routes} default" > ? Probably.=20 But looks like you want to install interface-specific routes,=20 I guess it is better to put anything interface-specific in ifconfig_[_alias*] or /etc/start_if. > /S =20 --=20 Vladimir B. Grebenchikov vova@fbsd.ru From owner-freebsd-net@FreeBSD.ORG Mon Nov 15 18:08: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 990DF16A4CE; Mon, 15 Nov 2004 18:08:52 +0000 (GMT) Received: from vbook.fbsd.ru (asplinux.ru [195.133.213.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4463243D4C; Mon, 15 Nov 2004 18:08:52 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.43 (FreeBSD)) id 1CTlHW-000LC7-Rd; Mon, 15 Nov 2004 21:08:50 +0300 From: Vladimir Grebenschikov To: =?iso-8859-2?Q?S=B3awek_=AFak?= In-Reply-To: <20041115172826.3E28911445@localhost> References: <20041115172826.3E28911445@localhost> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Organization: SWsoft Date: Mon, 15 Nov 2004 21:08:50 +0300 Message-Id: <1100542130.935.39.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.0FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov cc: "current@freebsd.org" cc: freebsd-net Subject: Re: route add -host ... -iface issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: vova@fbsd.ru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2004 18:08:52 -0000 =D0=92 =D0=BF=D0=BD, 15/11/2004 =D0=B2 18:28 +0100, S=C5=82awek =C5=BBak = =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > Hi, >=20 > I'd like to ask why a static arp entry is added when direct route to = host is > added like this? >=20 > route add -host target -iface interface >=20 > The route(8) manpage says, that such route entry is for hosts directl= y > reachable over interface. But when packets go out on this interface, = the MAC > address of target host in each packet is set to local MAC for the int= erface, > which effectively stops the target host from receiving the packet. But anyway, I have question to our routing gurus, why we need install broken routes in case of ethernet interfaces ? Like: # route add 172.1.1.1 -iface fxp0 add host 172.1.1.1: gateway fxp0 # netstat -rn | fgrep 172 172.1.1.1 08:00:46:c8:45:b3 UHLS 0 0 fxp0 # ifconfig fxp0 ether fxp0: flags=3D8843 mtu 1500 options=3D8 ether 08:00:46:c8:45:b3 # Installed routing entry is definitely broken, and can't be used, probably /sbin/route should add cloning flag automatically when direct route added for some ethernet (and like) interface ? I guess it is common mistake. Also, everyone going to add route-entry via specific MAC address will be puzzled. I know it is possible, but just now I can't remember how, and route(8) does not show any light on this question.=20 > /S =20 --=20 Vladimir B. Grebenchikov vova@fbsd.ru From owner-freebsd-net@FreeBSD.ORG Mon Nov 15 20:09: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 7EE6416A541; Mon, 15 Nov 2004 20:09:44 +0000 (GMT) Received: from relay.bestcom.ru (relay.bestcom.ru [217.72.144.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id B172943D46; Mon, 15 Nov 2004 20:09:43 +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 iAFK9cPD086989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 15 Nov 2004 23:09:39 +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 iAFK9bU9096984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Nov 2004 23:09:38 +0300 (MSK) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id iAFK9bO1096983; Mon, 15 Nov 2004 23:09:37 +0300 (MSK) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Mon, 15 Nov 2004 23:09:36 +0300 From: Gleb Smirnoff To: Archie Cobbs Message-ID: <20041115200936.GB96804@cell.sick.ru> References: <20041115104331.GA93477@cell.sick.ru> <200411151417.iAFEHfhN015171@arch20m.dellroad.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <200411151417.iAFEHfhN015171@arch20m.dellroad.org> 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: maxim@freebsd.org cc: rwatson@freebsd.org cc: net@freebsd.org Subject: Re: divert(4) socket isn't connection oriented 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, 15 Nov 2004 20:09:45 -0000 On Mon, Nov 15, 2004 at 08:17:41AM -0600, Archie Cobbs wrote: A> > Since it is working, it was not noticed quickly. Real problems occur when A> > a multicast packet comes on interface: it is diverted to ng_ksocket, returned A> > and div_output() sends it to ip_output(). In ip_output() it is ip_mloopback()ed A> > and if_simloop()ed. A copy of packet enters divert socket, duplicated... a A> > forever loop and total freeze. A> A> Your fix makes sense, but is it more of a workaround than a proper fix? I don't think so. Is divert(4) connection oriented? No, therefore so->so_state & SS_ISCONNECTED must be zero; therefore it shouldn't have pru_disconnect method. Does divert(4) has listen queue? No, therefore it shouldn't have pru_abort method. A> It seems like the real bug is that divert is promising to write the packet A> as "outgoing" yet the packet loops back as "incoming". Maybe it would make A> more sense to attach a tag to the packet that divert would recognize and A> know to ignore the extra incoming packet. This would be a workaround. divert(4) protocol uses sockaddr for this purpose, because m_tags do not pass thru userland. And ng_ksocket should emulate userland socket perfectly, otherwise it has no sense. It must understand sockaddr. A> Also, does the same thing happen with broadcast packets? No. So, the real change suggested is to remove SS_ISCONNECTED from so->so_state. All other changes are its logical consequences. What was idea of that SS_ISCONNECTED flag always set? I can't find any problems we can get by removing this code. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Mon Nov 15 20:15: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 8C72416A4CE; Mon, 15 Nov 2004 20:15:20 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 358FA43D1D; Mon, 15 Nov 2004 20:15:20 +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 iAFKDrnf028211; Mon, 15 Nov 2004 15:13:53 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)iAFKDrVu028208; Mon, 15 Nov 2004 20:13:53 GMT (envelope-from robert@fledge.watson.org) Date: Mon, 15 Nov 2004 20:13:53 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Archie Cobbs In-Reply-To: <200411151417.iAFEHfhN015171@arch20m.dellroad.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: maxim@freebsd.org cc: net@freebsd.org Subject: Re: divert(4) socket isn't connection oriented 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, 15 Nov 2004 20:15:20 -0000 On Mon, 15 Nov 2004, Archie Cobbs wrote: > Gleb Smirnoff wrote: > > Since it is working, it was not noticed quickly. Real problems occur when > > a multicast packet comes on interface: it is diverted to ng_ksocket, returned > > and div_output() sends it to ip_output(). In ip_output() it is ip_mloopback()ed > > and if_simloop()ed. A copy of packet enters divert socket, duplicated... a > > forever loop and total freeze. > > Your fix makes sense, but is it more of a workaround than a proper fix? > It seems like the real bug is that divert is promising to write the > packet as "outgoing" yet the packet loops back as "incoming". Maybe it > would make more sense to attach a tag to the packet that divert would > recognize and know to ignore the extra incoming packet. > > Also, does the same thing happen with broadcast packets? I'm not sure I'm so worried about the loopback case -- it strikes me that in a world with lots of layering, processing, tunneling, you need to be able to support the packet "coming back" based on topology (i.e., perhap a source routed packet) if it matches the criteria for diversion. The current behavior appears to be an implementation quirk associated with divert sockets permitting connection without quite having the more common datagram socket semantics for connection... I.e., what if I want the same packet to be diverted again after it's been reinjected? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research From owner-freebsd-net@FreeBSD.ORG Mon Nov 15 22:23: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 3A1F916A4D1 for ; Mon, 15 Nov 2004 22:23:16 +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 80BE543D2D for ; Mon, 15 Nov 2004 22:23:13 +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 C6E312F9AB; Mon, 15 Nov 2004 17:23:10 -0500 (EST) Date: Mon, 15 Nov 2004 17:23:10 -0500 From: James To: freebsd-net@freebsd.org Message-ID: <20041115222310.GA93130@scylla.towardex.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="tThc/1wpZn/ma/RB" Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: 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: Mon, 15 Nov 2004 22:23:16 -0000 --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Folks, 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. Few notes: o The code was again, made for 4.x, so currently does not use pfil. However, final draft that will be submitted by me later will include pfil_hooks. o In our internally modified 4.x kernel (where this code was written for initially), packets destined to router itself is sent to lo0 interface Therefore we do not have any checks for "is packet destined to us" in this code, however it is very simple to fix in KAME. I will make this correction implemented in the final draft. Thank you for your time and suggestions in the mean time. -J -- James Jun TowardEX Technologies, Inc. Technical Lead IPv4 and Native IPv6 Colocation, Bandwidth, james@towardex.com and Web Hosting Services in the Metro Boston area cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ip6_fastfwd.c" /* * Copyright (c) 2004 James Jun . All rights reserved. * Copyright (c) 2004 * TowardEX Technologies International, Inc. All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * 3. Neither the name of the project nor the names of its contributors * may be used to endorse or promote products derived from this software * without specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY THE PROJECT AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE PROJECT OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * $Wolfowitz: apc4-snap/49stable/src/sys/netinet6/ip6_fastfwd.c,v 1.0.5 2004/11/11 03:17:05 blahdy Exp $ * $Wolfowitz: apc5-snap/53L/src/sys/netinet6/ip6_fastfwd.c,v 1.0.5 2004/11/11 03:17:05 blahdy Exp $ */ /* * ip6_fastforward() is derived from FreeBSD 5.3's fully featured IPv4 * fast forwarding code. * * The ip6_fastforward() gains its speed by bypassing queuing and NETISR * completely. After packet is DMA'd from the incoming network card to * the host memory, the upper level interface driver preemptively calls * ip6_fastforward() instead of scheduling for later processing through * the network interrupt service. We then perform firewall validation * and packet validations as required by the protocol RFC's (e.g. drop * bad packets) for unicast IPv6 forwarding. We also internally resolve * IPv6 Neighbor Discovery instead of relying on nd6_output, and directly * send the packet off to the outgoing interface which DMAs the packet * to the network card. The only part of the packet we touch is simply * the IPv6 header. * * Because IPv6 patricia trie for kernel RIB can be up to as bad as O(128) * lookup constant, we leave the route structure opened in memory after * we perform the route lookup. If the next arriving packet uses the * same route, we will continue using that structure. If the next * packet uses a different destination, then we will free that structure * and perform a new RIB lookup. Some may call this route cache, but * so far, as little as I can test, it appears running a simple "if" * check to see if we can reuse a route is cheaper than rerunning * rtalloc_ign even possibly through L2 cache. Routing latency appears * to slightly increase by tens of microseconds when forcefully running * rtalloc_ign() for each fastforward call. * * Everything we don't know how to handle will be passed down to ip6_input() * for full processing. This includes multicast and IPsec routing. If this * is an IPsec tunneling broker, you should not use fastforward as we do * not support it. Otherwise, you can continue to use IPsec as encrypted * packets are destined to local system, which are processed by ip6_input. * * The hop-by-hop options in IPv6 is not supported by fast forwarding. * Packets with HBH will be sent to ip6_input for full processing. * * The performance constraint in using ip6_fastforward is essentially * limited by the following conditions: * * o Your bus speed. * o How fast your CPU and RAM can walk patricia trie for 128bit route * lookup. L2 cache can probably help here. * o The speed and efficiency of your network card/driver to quickly * setup receives and transmits. * o The complexity of your firewall rules, if you are using firewall. * The performance constraint caused by firewall configuration is * totally up to you, and how you setup the rules. * */ /* * Many thanks to Matt Thomas from NetBSD and Andre Oppermann from FreeBSD, * where this fastforwarding implementation was derived from. And lastly, * many thanks to the KAME team for their superior IPv6 stack. None of * this could've been possible without any of these folks' work. * */ #include "opt_ip6fw.h" #include "opt_inet.h" #include "opt_inet6.h" #include "opt_ip6stealth.h" #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include /* ip6.h must be declared before ip6_var obviously! */ #include #include #include #include #include SYSCTL_DECL(_net_inet6_ip6); static int ip6fastforward_active = 0; SYSCTL_INT(_net_inet6_ip6, IPV6CTL_FASTFORWARDING, fastforwarding, CTLFLAG_RW, &ip6fastforward_active, 0, "Enable fast IPv6 forwarding"); #ifdef IP6STEALTH static int ip6stealth = 0; SYSCTL_INT(_net_inet6_ip6, OID_AUTO, stealth, CTLFLAG_RW, &ip6stealth, 0, "Enable stealth IPv6 forwarding"); #endif struct route_in6 ip6_forward_rt; int ip6_fastforward(struct mbuf *m) { struct ip6_hdr *ip6; struct sockaddr_in6 *dst; struct sockaddr_in6 *gw6 = NULL; struct rtentry *rt = NULL; struct ifnet *ifp = NULL; int error = 0; u_int32_t plen; struct llinfo_nd6 *ln = NULL; /* Are we hot and forwarding IPv6? If not, drop to ip6_input */ if (!ip6fastforward_active || !ip6_forwarding) return 0; KASSERT(m != NULL && (m->m_flags & M_PKTHDR) != 0, ("apc_inet6_fastfwd: no packet header in mbuf")); /* * Update mbuf statistics */ if (m->m_flags & M_EXT) { if (m->m_next) ip6stat.ip6s_mext2m++; else ip6stat.ip6s_mext1++; } else { #define M2MMAX (sizeof(ip6stat.ip6s_m2m)/sizeof(ip6stat.ip6s_m2m[0])) if (m->m_next) { if (m->m_flags & M_LOOP) { ip6stat.ip6s_m2m[loif[0].if_index]++; /* XXX */ } else if (m->m_pkthdr.rcvif->if_index < M2MMAX) ip6stat.ip6s_m2m[m->m_pkthdr.rcvif->if_index]++; else ip6stat.ip6s_m2m[0]++; } else ip6stat.ip6s_m1++; #undef M2MMAX } #ifndef PULLDOWN_TEST /* * We have a serious problem if we don't check for invalid * mbuf chains that sometimes bad drivers or layer2 code * send us. Correct as needed. */ if (m && m->m_next != NULL && m->m_pkthdr.len < MCLBYTES) { struct mbuf *n; MGETHDR(n, M_DONTWAIT, MT_HEADER); if (n) M_MOVE_PKTHDR(n, m); if (n && n->m_pkthdr.len > MHLEN) { MCLGET(n, M_DONTWAIT); if ((n->m_flags & M_EXT) == 0) { m_freem(n); n = NULL; } } if (n == NULL) { m_freem(m); return 1; /*ENOBUFS*/ } m_copydata(m, 0, n->m_pkthdr.len, mtod(n, caddr_t)); n->m_len = n->m_pkthdr.len; m_freem(m); m = n; } IP6_EXTHDR_CHECK(m, 0, sizeof(struct ip6_hdr), 1); #endif /* * Step 1: check for packet drop conditions and sanity checks */ /* * First mbuf large enough for ipv6 header and is header there? */ if (m->m_len < sizeof(struct ip6_hdr) && (m = m_pullup(m, sizeof(struct ip6_hdr))) == 0) { ip6stat.ip6s_toosmall++; in6_ifstat_inc(m->m_pkthdr.rcvif, ifs6_in_hdrerr); return 1; /* mbuf already free'd */ } ip6 = mtod(m, struct ip6_hdr *); /* Is this IPv6? */ if ((ip6->ip6_vfc & IPV6_VERSION_MASK) != IPV6_VERSION) { ip6stat.ip6s_badvers++; in6_ifstat_inc(m->m_pkthdr.rcvif, ifs6_in_hdrerr); goto drop; } plen = (u_int32_t)ntohs(ip6->ip6_plen); /* * Is entire packet big enough as the IPv6 header * tells us? */ if (m->m_pkthdr.len - sizeof(struct ip6_hdr) < plen) { ip6stat.ip6s_tooshort++; goto drop; } /* * If entire packet is bigger than what the IPv6 * header tells us, cut the size. */ if (m->m_pkthdr.len > sizeof(struct ip6_hdr) + plen) { if (m->m_len == m->m_pkthdr.len) { m->m_len = sizeof(struct ip6_hdr) + plen; m->m_pkthdr.len = sizeof(struct ip6_hdr) + plen; } else m_adj(m, sizeof(struct ip6_hdr) + plen - m->m_pkthdr.len); } /* Record what kind of extension header each packet has.. */ ip6stat.ip6s_nxthist[ip6->ip6_nxt]++; /* * Bad-Address Check * Packets we should not be accepting should be dropped now. */ /* * The following check is not documented in specs. A malicious * party may be able to use IPv4 mapped addr to confuse tcp/udp stack * and bypass security checks (act as if it was from 127.0.0.1 by using * IPv6 src ::ffff:127.0.0.1). Be cautious. * * This check chokes if we are in an SIIT cloud. As none of BSDs * support IPv4-less kernel compilation, we cannot support SIIT * environment at all. So, it makes more sense for us to reject any * malicious packets for non-SIIT environment, than try to do a * partical support for SIIT environment. */ if (IN6_IS_ADDR_V4MAPPED(&ip6->ip6_src) || IN6_IS_ADDR_V4MAPPED(&ip6->ip6_dst) || /* * If we are seeing loopback addresses on the wire, I think the * cluephone is ringing! */ IN6_IS_ADDR_LOOPBACK(&ip6->ip6_src) || IN6_IS_ADDR_LOOPBACK(&ip6->ip6_dst) || /* * Drop packets with unspecified src/dst pair, and drop packets claiming * to be from multicast networks. * * Note that if the source addr is multicast, that is not exactly a * conforming multicast, so drop it. * [See "Developing IP Multicast Networks", Beau Williamson, * Cisco Press] */ IN6_IS_ADDR_MULTICAST(&ip6->ip6_src) || IN6_IS_ADDR_UNSPECIFIED(&ip6->ip6_dst) || IN6_IS_ADDR_UNSPECIFIED(&ip6->ip6_src)) { ip6stat.ip6s_badscope++; in6_ifstat_inc(m->m_pkthdr.rcvif, ifs6_in_addrerr); goto drop; } /* * Step 2: fallback conditions to ip6_input slowpath processing */ /* * Regular unicast IPv6 packets only. Multicast and packets claiming * to be from loopback, we don't know how to deal with, so we will bail * out and pass them onto ip6_input(). * * Further, people who forward link-local subnets with a routing * protocol must go back and take 'IPv6 for Dummies' course. We won't * drop them, but in spirit of RFC2772, we won't fast process them * either. */ if (IN6_IS_ADDR_MULTICAST(&ip6->ip6_dst) || IN6_IS_SCOPE_LINKLOCAL(&ip6->ip6_src) || IN6_IS_SCOPE_LINKLOCAL(&ip6->ip6_dst) || (m->m_pkthdr.rcvif->if_flags & IFF_LOOPBACK) || (m->m_flags & (M_BCAST|M_MCAST)) != 0 ) return 0; /* * If we are seeing a packet with a Router Alert Option [RFC2711] now, * and we are still in ip6_fastforward(), then this packet really is NOT * multicast, nor regular looking unicast. It's either RSVP or something * else not supported. Send to ip6_input() for full inspection. */ if (ip6->ip6_nxt == IPPROTO_HOPOPTS) return 0; /* Step 3: * Lookup route in the radix rib. * * We need to look up the route early, because we * need to validate whether we have a neighbor discovery * cache available in the respective rtentry. */ dst = (struct sockaddr_in6 *)&ip6_forward_rt.ro_dst; if ((ip6_forward_rt.ro_rt == 0) || !IN6_ARE_ADDR_EQUAL(&ip6->ip6_dst, &dst->sin6_addr)){ if(ip6_forward_rt.ro_rt) { RTFREE(ip6_forward_rt.ro_rt); ip6_forward_rt.ro_rt = 0; } bzero(dst, sizeof(*dst)); dst->sin6_len = sizeof(struct sockaddr_in6); dst->sin6_family = AF_INET6; dst->sin6_addr = ip6->ip6_dst; rtalloc_ign((struct route *)&ip6_forward_rt, RTF_PRCLONING); if (ip6_forward_rt.ro_rt){ rt = ip6_forward_rt.ro_rt; if (rt->rt_flags & RTF_GATEWAY) dst = (struct sockaddr_in6 *)rt->rt_gateway; ifp = rt->rt_ifp; } else { goto forwardcheck; } } else { rt = ip6_forward_rt.ro_rt; if (rt->rt_flags & RTF_GATEWAY) dst = (struct sockaddr_in6 *)rt->rt_gateway; ifp = rt->rt_ifp; } /* If the destination neighbor is in process of link layer * resolution, drop to ip6_input now. * * [See RFC 2461 Sec 7.2.2 ] * * Because we bypassed NETISR registration and queueing * under locking protection, if we just blindly attempt * to queue up small amount of packets while neighbor is * being resolved, we will corrupt or otherwise lose * mbuf's. This may lead device driver to crash, exhaust, * or otherwise crash the kernel. * * ip6_input requires packets to arrive in more of an * orderly fassion (as a tradeoff for slower performance) * so that mbuf corruption does not occur during neighbor * link layer resolution. */ if (rt->rt_flags & RTF_UP){ if (rt->rt_flags & RTF_LLINFO){ ln = (struct llinfo_nd6 *)rt->rt_llinfo; goto nd_cache_lookup; } if (nd6_is_addr_neighbor(dst, ifp) && (rt == nd6_lookup(&dst->sin6_addr, 1, ifp)) != NULL){ ln = (struct llinfo_nd6 *)rt->rt_llinfo; goto nd_cache_lookup; } nd_cache_lookup: if (ln && (ln->ln_state == (ND6_LLINFO_INCOMPLETE|ND6_LLINFO_NOSTATE))) return 0; } in6_ifstat_inc(m->m_pkthdr.rcvif, ifs6_in_receive); ip6stat.ip6s_total++; /* * Step 4: incoming packet firewall processing * XXX: Need to use pfil_hooks for APC5-dev */ forwardcheck: /* very basic ip6fw check. no divert, no dummynet, no * nothing. just permit/deny only for now. */ if (ip6_fw_enable && ip6_fw_chk_ptr) { u_short port = 0; /* If ipfw says divert, we have to just drop packet */ /* use port as a dummy argument */ if ((*ip6_fw_chk_ptr)(&ip6, NULL, &port, &m)) { m_freem(m); } if (!m) return 1; } /* * Step 5: Validate routing entry */ if (!rt){ ip6stat.ip6s_noroute++; ip6stat.ip6s_cantforward++; in6_ifstat_inc(m->m_pkthdr.rcvif, ifs6_in_noroute); icmp6_error(m, ICMP6_DST_UNREACH, ICMP6_DST_UNREACH_NOROUTE, 0); /* Do _NOT_ call RTFREE here. */ return 1; } /* Drop all reject and null routes while we are in fast * forwarding path. */ if ( rt->rt_flags & RTF_BLACKHOLE ) goto drop; if ( rt->rt_flags & RTF_REJECT ) { /* * XXX I can't seem to find any BCP, STD, RFC nor any ietf v6 * working group drafts regarding how to respond to a reject * route with ICMP6 code. So for now, we'll copycat Juniper's * behaviour. */ icmp6_error(m, ICMP6_DST_UNREACH, ICMP6_DST_UNREACH_NOROUTE, 0); return 1; /* mbuf is already gone */ } /* If route is down, we shouldn't use it */ if (!(rt->rt_flags & RTF_UP)){ ip6stat.ip6s_cantforward++; in6_ifstat_inc(m->m_pkthdr.rcvif, ifs6_in_noroute); icmp6_error(m, ICMP6_DST_UNREACH, ICMP6_DST_UNREACH_ADDR, 0); return 1; } /* * Scope check: if a packet can't be delivered to its destination * for the reason that the destination is beyond the scope of the * source address, return ICMP6 code 2. * [draft-ietf-ipngwg-icmp-v3-02.txt, Section 3.1] */ if (in6_addr2scopeid(m->m_pkthdr.rcvif, &ip6->ip6_src) != in6_addr2scopeid(ifp, &ip6->ip6_src)) { ip6stat.ip6s_cantforward++; ip6stat.ip6s_badscope++; in6_ifstat_inc(ifp, ifs6_in_discard); icmp6_error(m, ICMP6_DST_UNREACH, ICMP6_DST_UNREACH_BEYONDSCOPE, 0); return 1; } /* Decrement Hop Limit now. if hlim=0, call icmp6_error * * Note that we're doing this after we have successfully * gone through the "forwarding" stage by identifying a * functional route; we should NOT be doing TTL/HLIM work * BEFORE we even look up a usable route. At least this * appears to be the way Juniper prefers doing, in their * hardware forwarding plane implementation. */ #ifdef IP6STEALTH if (!ip6stealth) { #endif /* * Note: * Because we forward local-bound packets to lo0, it is * important that we do NOT decrement HLIM on them. If * we do, not only traceroute to router's interface IP * will show double hops, icmp6 nd advertisements will * get discarded per RFC requirement <-- this is bad. * * Furthermore, decrementing HLIM on local-bound packets * may break strict GTSM deployments that rely on HLIM * (TTL in current IPv4 BTSH deployments) to be 255 on * BGP single hop peers. */ if (!(rt->rt_flags & RTF_LOCAL)){ if (ip6->ip6_hlim <= IPV6_HLIMDEC){ icmp6_error(m, ICMP6_TIME_EXCEEDED, ICMP6_TIME_EXCEED_TRANSIT, 0); return 1; } ip6->ip6_hlim -= IPV6_HLIMDEC; } #ifdef IP6STEALTH } #endif /* * Step 6: Outgoing firewall check. Again very basic. * need to move to pfil_hooks for apc5 */ if (ip6_fw_enable && ip6_fw_chk_ptr) { u_short port = 0; /* If ipfw says divert, we have to just drop packet */ /* Send ifp, so fw knows this is outbound check */ if ((*ip6_fw_chk_ptr)(&ip6, ifp, &port, &m)) { m_freem(m); } if (!m) return 1; } /* * Step 7: Send off the packet */ #if 0 /* * Check layer1 media link state * For APC5 only. */ if (ifp->if_link_state == LINK_STATE_DOWN) { icmp6_error(m, ICMP6_DST_UNREACH, ICMP6_DST_UNREACH_ADDR, 0); return 1; } #endif /* Check if packet is too fat to fit on the outgoing link. * If it is too fat, notify the source. */ if (m->m_pkthdr.len > ifp->if_mtu) { u_long mtu; mtu = ifp->if_mtu; in6_ifstat_inc(ifp, ifs6_in_toobig); icmp6_error(m, ICMP6_PACKET_TOO_BIG, 0, mtu); return 1; } /* Clear embedded scope id's as needed */ if (IN6_IS_SCOPE_LINKLOCAL(&ip6->ip6_src)) ip6->ip6_src.s6_addr16[1] = 0; if (IN6_IS_SCOPE_LINKLOCAL(&ip6->ip6_dst)) ip6->ip6_dst.s6_addr16[1] = 0; /* * Validate layer2 link resolution for next-hop * advancing router or host. */ /* We do not deal with neighbor cache on any * interface other than ARC, ethernet, FDDI * and GIF. */ if (nd6_need_cache(ifp) == 0) goto sendpkt; if (rt->rt_flags & RTF_GATEWAY){ struct rtentry *rt0 = rt; gw6 = (struct sockaddr_in6 *)rt->rt_gateway; /* Skip link-layer addr resolution and NUD * if nexthop advancing router is not a * neighbor according to NUD. If this is * a point to point link, skip NUD. */ if (!nd6_is_addr_neighbor(gw6, ifp) || in6ifa_ifpwithaddr(ifp, &gw6->sin6_addr)) { if ((ifp->if_flags & IFF_POINTOPOINT) == 0) goto drop; goto sendpkt; } if(rt->rt_gwroute == 0) goto ndll_lookup; if (((rt = rt->rt_gwroute)->rt_flags & RTF_UP) == 0) { rtfree(rt); rt = rt0; ndll_lookup: rt->rt_gwroute = rtalloc1(rt->rt_gateway, 1, 0UL); if ((rt = rt->rt_gwroute) == 0) goto drop; } } if (!ln){ if ((ifp->if_flags & IFF_POINTOPOINT) == 0 && !(nd_ifinfo[ifp->if_index].flags & ND6_IFF_PERFORMNUD)) { log(LOG_DEBUG, "apc_inet6_fastfwd: can't allocate llinfo for %s " "(ln=%p, rt=%p)\n", ip6_sprintf(&dst->sin6_addr), ln, rt); goto drop; } goto sendpkt; /* send anyway */ } /* No need for link-layer resolution on a p2p circuit */ if ((ifp->if_flags & IFF_POINTOPOINT) != 0 && ln->ln_state < ND6_LLINFO_REACHABLE){ ln->ln_state = ND6_LLINFO_STALE; ln->ln_expire = time_second + nd6_gctimer; } /* If entry is stale, change state to DELAY and let it * expire in nd6.c (RFC2461 Sec. 7.3.3) */ if (ln->ln_state == ND6_LLINFO_STALE) { ln->ln_asked = 0; ln->ln_state = ND6_LLINFO_DELAY; ln->ln_expire = time_second + nd6_delay; } if (ln->ln_state > ND6_LLINFO_INCOMPLETE) goto sendpkt; /* * Read up comments above for reason why we are not * queuing up packet here. */ if (ln->ln_state == ND6_LLINFO_NOSTATE) ln->ln_state = ND6_LLINFO_INCOMPLETE; if (ln->ln_expire) { if (ln->ln_asked < nd6_mmaxtries && ln->ln_expire < time_second) { ln->ln_asked++; ln->ln_expire = time_second + nd_ifinfo[ifp->if_index].retrans / 1000; nd6_ns_output(ifp, NULL, &dst->sin6_addr, ln, 0); } } /* There is no need to process packets further. */ goto drop; sendpkt: error = (*ifp->if_output)(ifp, m, (struct sockaddr *)dst, rt); if (error) { ip6stat.ip6s_odropped++; in6_ifstat_inc(rt->rt_ifp, ifs6_out_discard); } else { /* if not an error, we successfully routed a packet! */ ip6stat.ip6s_forward++; ip6stat.ip6s_fastforward++; in6_ifstat_inc(rt->rt_ifp, ifs6_out_forward); } return 1; /* We are done, operation complete. */ drop: if (m) m_freem(m); return 1; } /* EOF */ --tThc/1wpZn/ma/RB-- From owner-freebsd-net@FreeBSD.ORG Mon Nov 15 22:57: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 2E9A516A4CE; Mon, 15 Nov 2004 22:57:48 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id D1D7F43D46; Mon, 15 Nov 2004 22:57:46 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 994AC7A424; Mon, 15 Nov 2004 14:57:46 -0800 (PST) Message-ID: <4199346A.3040908@elischer.org> Date: Mon, 15 Nov 2004 14:57:46 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Gleb Smirnoff References: <20041115104331.GA93477@cell.sick.ru> In-Reply-To: <20041115104331.GA93477@cell.sick.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: maxim@freebsd.org cc: rwatson@freebsd.org cc: net@freebsd.org Subject: Re: divert(4) socket isn't connection oriented 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, 15 Nov 2004 22:57:48 -0000 Gleb Smirnoff wrote: > Hi! > > I've spent several days digging in interaction between divert >protocol and ng_ksocket. I've find some oddities in there. > > Look at div_output(), it tells incoming packet from outgoing >by presence of sockaddr_in structure. Depending on it packet >is passed either to ip_input() or ip_output(). This sockaddr_in was >previuosly supplied by divert interface to application at the end >of divert_packet() with help of sbappendaddr_locked(). > > Look at ng_ksocket_incoming2(), near 'pru_soreceive'. When >ng_ksocket takes data from socket it saves supplied sockaddr in >m_tag attached to packet. After packet travel thru netgraph(4) it >may return to ng_ksocket in ng_ksocket_rcvdata() and this sockaddr >will be used in call to sosend(). > > It is important that ng_ksocket does not save sockaddr if socket is >connected (see ng_ksocket_incoming2(), near 'pru_soreceive'). And this >is correct! If a generic socket is connected, all data must be sent to >connection destination. The problem is that divert(4) socket is >always marked as connected (see end of div_attach()), and thus >ng_ksocket_rcvdata() does not supply sockaddr in call to sosend(). So >div_output() _always_ sends data to ip_output()! This is strange and odd >but working - packets flow in both directions. This setup is working: > >/usr/sbin/ngctl -f- <<-SEQ > mkpeer echo dummy dummy > name .:dummy echo_div > mkpeer echo_div: ksocket echo inet/raw/divert > name echo_div:echo div_sock > rmhook dummy > msg div_sock: bind inet/0.0.0.0:8888 >SEQ >ipfw add 1 divert 8888 all from any to any via fxp0 in >ping -c 1 www.com > It might be worthwhile looking at a direct netgraph/ipfw interface :-) ipfw add 1 netgraph any from me to you.com 666 in ipfw add 1 netgraph any from me to you.com 666 out Creating the netgraph entry would create 2 hooks called '1-in and 1-out' :-) (other syntaxes considerred) > >Since it is working, it was not noticed quickly. Real problems occur when >a multicast packet comes on interface: it is diverted to ng_ksocket, returned >and div_output() sends it to ip_output(). In ip_output() it is ip_mloopback()ed >and if_simloop()ed. A copy of packet enters divert socket, duplicated... a >forever loop and total freeze. > >Removing 'always connected status' from divert sockets fixes the problem >and incoming packets go into ip_input(), not ip_output(). Please review attached >patch. It: > >- removes SS_ISCONNECTED from so->so_state > to me this makes sense as divert is not conection based.. >- removes pru_disconnect method, since it won't be called >- removes pru_abort method, since it must not be called on divert > socket. It was used indirectly via disconnect method. > seems fair. Other possibilities may include converting the tags to something else so that data is not lost but just moved aside (but still avaliable). Making divert a non connected protocol however is ok.. I think it better fits it usage. > >With this patch codepath of packets is correct and incoming packets do >not enter ip_output() anymore. > >An alternative may be adding a kludge in ng_ksocket_incoming2(), so that sockaddr >is saved always if socket is a divert socket. I don't like it. > >Awaiting for your feedback! > > If I did it again I think I'd suggest that divert not be a part of the INET family.. It was easiest tat that time to make it so.. Archie, do you remember why we decided this? > > >------------------------------------------------------------------------ > >Index: ip_divert.c >=================================================================== >RCS file: /home/ncvs/src/sys/netinet/ip_divert.c,v >retrieving revision 1.109 >diff -u -r1.109 ip_divert.c >--- ip_divert.c 12 Nov 2004 22:17:42 -0000 1.109 >+++ ip_divert.c 15 Nov 2004 10:14:37 -0000 >@@ -415,12 +415,7 @@ > inp->inp_ip_p = proto; > inp->inp_vflag |= INP_IPV4; > inp->inp_flags |= INP_HDRINCL; >- /* The socket is always "connected" because >- we always know "where" to send the packet */ > INP_UNLOCK(inp); >- SOCK_LOCK(so); >- so->so_state |= SS_ISCONNECTED; >- SOCK_UNLOCK(so); > return 0; > } > >@@ -442,32 +437,6 @@ > } > > static int >-div_abort(struct socket *so) >-{ >- struct inpcb *inp; >- >- INP_INFO_WLOCK(&divcbinfo); >- inp = sotoinpcb(so); >- if (inp == 0) { >- INP_INFO_WUNLOCK(&divcbinfo); >- return EINVAL; /* ??? possible? panic instead? */ >- } >- INP_LOCK(inp); >- soisdisconnected(so); >- in_pcbdetach(inp); >- INP_INFO_WUNLOCK(&divcbinfo); >- return 0; >-} >- >-static int >-div_disconnect(struct socket *so) >-{ >- if ((so->so_state & SS_ISCONNECTED) == 0) >- return ENOTCONN; >- return div_abort(so); >-} >- >-static int > div_bind(struct socket *so, struct sockaddr *nam, struct thread *td) > { > struct inpcb *inp; >@@ -662,12 +631,10 @@ > #endif > > struct pr_usrreqs div_usrreqs = { >- .pru_abort = div_abort, > .pru_attach = div_attach, > .pru_bind = div_bind, > .pru_control = in_control, > .pru_detach = div_detach, >- .pru_disconnect = div_disconnect, > .pru_peeraddr = div_peeraddr, > .pru_send = div_send, > .pru_shutdown = div_shutdown, > > From owner-freebsd-net@FreeBSD.ORG Mon Nov 15 23: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 CFEB216A4CE; Mon, 15 Nov 2004 23:05:19 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id A82B643D3F; Mon, 15 Nov 2004 23:05:19 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 798217A424; Mon, 15 Nov 2004 15:05:19 -0800 (PST) Message-ID: <4199362F.2070401@elischer.org> Date: Mon, 15 Nov 2004 15:05:19 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Gleb Smirnoff References: <20041115104331.GA93477@cell.sick.ru> <200411151417.iAFEHfhN015171@arch20m.dellroad.org> <20041115200936.GB96804@cell.sick.ru> In-Reply-To: <20041115200936.GB96804@cell.sick.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: maxim@freebsd.org cc: rwatson@freebsd.org cc: Archie Cobbs cc: net@freebsd.org Subject: Re: divert(4) socket isn't connection oriented 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, 15 Nov 2004 23:05:20 -0000 Gleb Smirnoff wrote: >On Mon, Nov 15, 2004 at 08:17:41AM -0600, Archie Cobbs wrote: >A> > Since it is working, it was not noticed quickly. Real problems occur when >A> > a multicast packet comes on interface: it is diverted to ng_ksocket, returned >A> > and div_output() sends it to ip_output(). In ip_output() it is ip_mloopback()ed >A> > and if_simloop()ed. A copy of packet enters divert socket, duplicated... a >A> > forever loop and total freeze. >A> >A> Your fix makes sense, but is it more of a workaround than a proper fix? > >I don't think so. > >Is divert(4) connection oriented? No, therefore so->so_state & SS_ISCONNECTED >must be zero; therefore it shouldn't have pru_disconnect method. >Does divert(4) has listen queue? No, therefore it shouldn't have pru_abort >method. > >A> It seems like the real bug is that divert is promising to write the packet >A> as "outgoing" yet the packet loops back as "incoming". Maybe it would make >A> more sense to attach a tag to the packet that divert would recognize and >A> know to ignore the extra incoming packet. > >This would be a workaround. divert(4) protocol uses sockaddr for this purpose, >because m_tags do not pass thru userland. And ng_ksocket should emulate >userland socket perfectly, otherwise it has no sense. It must understand >sockaddr. > >A> Also, does the same thing happen with broadcast packets? > >No. > >So, the real change suggested is to remove SS_ISCONNECTED from so->so_state. All >other changes are its logical consequences. >What was idea of that SS_ISCONNECTED flag always set? I can't find any problems we >can get by removing this code. > I think that if there were any reasons they have probably been removed over the years.. I cannot remember why we did this.. maybe if we could look at the old Whistle CVS tree, we might remember but it may even have been a cut-n-paste thing with no "reason" other than teh feeling that the destination of teh packets (the IPFW module) was fixed. also there may have been code that refused to send packets using sendto() if there was a NULL address. I think we wanted a plain "write" to teh socket to do smething so that you could pipe to it.. > > > From owner-freebsd-net@FreeBSD.ORG Mon Nov 15 23:39:23 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 C71F616A4CE; Mon, 15 Nov 2004 23:39:23 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA4E643D1D; Mon, 15 Nov 2004 23:39:23 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 861F67A41E; Mon, 15 Nov 2004 15:39:23 -0800 (PST) Message-ID: <41993E2B.9060902@elischer.org> Date: Mon, 15 Nov 2004 15:39:23 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Archie Cobbs References: <200411152334.iAFNY1oS003137@arch20m.dellroad.org> In-Reply-To: <200411152334.iAFNY1oS003137@arch20m.dellroad.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: maxim@FreeBSD.ORG cc: archie@FreeBSD.ORG cc: Gleb Smirnoff cc: rwatson@FreeBSD.ORG cc: net@FreeBSD.ORG cc: julian@FreeBSD.ORG Subject: Re: divert(4) socket isn't connection oriented 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, 15 Nov 2004 23:39:23 -0000 Archie Cobbs wrote: >Julian Elischer wrote: > > >>If I did it again I think I'd suggest that divert not be a part of the >>INET family.. >>It was easiest tat that time to make it so.. >>Archie, do you remember why we decided this? >> >> > >At the time, the goal was to minimize the size of the divert patch rather >than maximizing elegance, because this was determined to give it a better >chance of being committed... in hindsight we could have structured things >more clearly. > yeah I remember now.. From owner-freebsd-net@FreeBSD.ORG Tue Nov 16 01:23:24 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 8060B16A4CE for ; Tue, 16 Nov 2004 01:23:24 +0000 (GMT) Received: from mail.pogozone.net (pogo02.pogozone.net [216.57.201.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id C56ED43D1D for ; Tue, 16 Nov 2004 01:23:23 +0000 (GMT) (envelope-from jbarrett@amduat.net) Received: from [10.0.0.69] (client-220-234.bhm.pogozone.net [216.57.220.234]) (AUTH: LOGIN jbarrett@pogozone.net, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by mail.pogozone.net with esmtp; Mon, 15 Nov 2004 17:23:23 -0800 From: "Jacob S. Barrett" To: freebsd-net@freebsd.org Date: Mon, 15 Nov 2004 17:22:21 -0800 User-Agent: KMail/1.7.1 References: <200411141311.49502.jbarrett@amduat.net> <200411141623.10060.jbarrett@amduat.net> <20041115004905.GA4275@pit.databus.com> In-Reply-To: <20041115004905.GA4275@pit.databus.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200411151722.22372.jbarrett@amduat.net> Subject: Re: Universal Client Gateway 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, 16 Nov 2004 01:23:24 -0000 On Sunday 14 November 2004 04:49 pm, Barney Wolff wrote: > When you have arpd (probably modified slightly) answer for a new "gateway" > address, add it as an alias to the interface on which the arp request was > received, with a netmask that will cover the address from which the > request came. Then responses to the original requester will naturally > go back out the right interface. Yes, but this is bad because now all traffic in that subnet will get directed out that interface. That could be really bad. One could really cause problems if thir gateway and IP forced a really large subnet. > Of course, this is all pretty pointless. It would be better to force > the clients to use dhcp, even if they're transients. Also, it's rather > dangerous - would you notice if such a client claimed to have the IP > address of your Internet gateway, and thus captured everybody's traffic? How do you for transients to use DHCP, especially when most of them are only smart enough to turn their computers on. That is why universal proxies are popular in hotels and airports. Well, in case anyone is interested or searches for this same problem later, I think I solved the problem. Actually a post earlier today about route add -host -face had the solution. To pass traffic back to the poxied machine execute this command: route add xx.xx.xx.xx/32 -iface WAN -cloning Of course, having a daemon monitoring for these proxied hosts and executing this routing command is still missing, but at least I know what my daemon needs to do now. I will probably just modify arpd to do this after it proxies the gateway ARP reply. -- Jacob S. Barrett jbarrett@amduat.net www.amduat.net "I don't suffer from insanity, I enjoy every minute of it." From owner-freebsd-net@FreeBSD.ORG Tue Nov 16 05:59: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 BFFDE16A4CE for ; Tue, 16 Nov 2004 05:59:03 +0000 (GMT) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8BD2343D54 for ; Tue, 16 Nov 2004 05:59:03 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) iAG5x2wN098761; Mon, 15 Nov 2004 21:59:02 -0800 (PST) (envelope-from gnn@neville-neil.com) Received: from h229.neville-neil.com.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 iAG5x0l8014436; Mon, 15 Nov 2004 21:59:00 -0800 (PST) (envelope-from gnn@neville-neil.com) Date: Mon, 15 Nov 2004 21:59:01 -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: Tue, 16 Nov 2004 05:59:03 -0000 Have you also forwarded this to Kame for comment? I will try to take a look at this this week. Later, George From owner-freebsd-net@FreeBSD.ORG Tue Nov 16 06:00: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 9895216A4CE; Tue, 16 Nov 2004 06:00:55 +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 6252D43D2F; Tue, 16 Nov 2004 06:00:55 +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 417CC2F949; Tue, 16 Nov 2004 01:00:55 -0500 (EST) Date: Tue, 16 Nov 2004 01:00:55 -0500 From: James To: gnn@freebsd.org Message-ID: <20041116060055.GA26901@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: Tue, 16 Nov 2004 06:00:55 -0000 On Mon, Nov 15, 2004 at 09:59:01PM -0800, gnn@freebsd.org wrote: > Have you also forwarded this to Kame for comment? Not yet, will do that this week however. > > I will try to take a look at this this week. Thank you. -J > > Later, > George > _______________________________________________ > 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" -- James Jun TowardEX Technologies, Inc. Technical Lead IPv4 and Native IPv6 Colocation, Bandwidth, james@towardex.com and Web Hosting Services in the Metro Boston area cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net From owner-freebsd-net@FreeBSD.ORG Tue Nov 16 14:58: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 E007916A4CE for ; Tue, 16 Nov 2004 14:58:59 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 266F343D31 for ; Tue, 16 Nov 2004 14:58:59 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 2CF2265410; Tue, 16 Nov 2004 14:58:57 +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 26834-01-9; Tue, 16 Nov 2004 14:58:56 +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 704156530A; Tue, 16 Nov 2004 14:58:56 +0000 (GMT) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id A15DB66A3; Tue, 16 Nov 2004 06:58:52 -0800 (PST) Date: Tue, 16 Nov 2004 06:58:52 -0800 From: Bruce M Simpson To: Mike Tancsa Message-ID: <20041116145852.GD847@empiric.icir.org> Mail-Followup-To: Mike Tancsa , freebsd-net@freebsd.org References: <4194CDF9.3000609@mr0vka.eu.org> <20041112210716.GC830@empiric.icir.org> <7lhdp0l2i9l94gunj0qdenaavl3o667r9m@4ax.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7lhdp0l2i9l94gunj0qdenaavl3o667r9m@4ax.com> cc: freebsd-net@freebsd.org Subject: Re: OpenBGPd? 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, 16 Nov 2004 14:59:00 -0000 On Sat, Nov 13, 2004 at 09:45:26PM -0500, Mike Tancsa wrote: > Are there advantages to XORP over say Quaaga ? Yes. Much faster BGP convergence times :-) See: http://www.icir.org/atanu/tmp/nsdi.html Regards, BMS From owner-freebsd-net@FreeBSD.ORG Tue Nov 16 15:36:24 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 A7E6E16A4CE for ; Tue, 16 Nov 2004 15:36:24 +0000 (GMT) Received: from avscan2.sentex.ca (avscan2.sentex.ca [199.212.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 56C9143D2F for ; Tue, 16 Nov 2004 15:36:24 +0000 (GMT) (envelope-from mike@sentex.net) Received: from localhost (localhost.sentex.ca [127.0.0.1]) by avscan2.sentex.ca (8.12.11/8.12.11) with ESMTP id iAGFaOSF043993; Tue, 16 Nov 2004 10:36:24 -0500 (EST) (envelope-from mike@sentex.net) Received: from avscan2.sentex.ca ([127.0.0.1]) by localhost (avscan2.sentex.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 43731-04; Tue, 16 Nov 2004 10:36:23 -0500 (EST) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by avscan2.sentex.ca (8.12.11/8.12.11) with ESMTP id iAGFaNS4043950; Tue, 16 Nov 2004 10:36:23 -0500 (EST) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.12.11/8.12.11) with ESMTP id iAGFaGgn051588; Tue, 16 Nov 2004 10:36:16 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <6.1.2.0.0.20041116103545.056b3658@64.7.153.2> X-Sender: mdtpop@64.7.153.2 (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 16 Nov 2004 10:43:25 -0500 To: Bruce M Simpson From: Mike Tancsa In-Reply-To: <20041116145852.GD847@empiric.icir.org> References: <4194CDF9.3000609@mr0vka.eu.org> <20041112210716.GC830@empiric.icir.org> <7lhdp0l2i9l94gunj0qdenaavl3o667r9m@4ax.com> <20041116145852.GD847@empiric.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new X-Virus-Scanned: by amavisd-new at avscan2b cc: freebsd-net@freebsd.org Subject: Re: OpenBGPd? 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, 16 Nov 2004 15:36:24 -0000 Neat! What about the underlying OS ? Is it optimized for a particular OS such as http://www.pdos.lcs.mit.edu/click/ or FreeBSD or Linux ? ---Mike At 09:58 AM 16/11/2004, Bruce M Simpson wrote: >On Sat, Nov 13, 2004 at 09:45:26PM -0500, Mike Tancsa wrote: > > Are there advantages to XORP over say Quaaga ? > >Yes. Much faster BGP convergence times :-) > >See: http://www.icir.org/atanu/tmp/nsdi.html > >Regards, >BMS From owner-freebsd-net@FreeBSD.ORG Tue Nov 16 15:58:10 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 904BC16A4CE for ; Tue, 16 Nov 2004 15:58:10 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E0E243D1D for ; Tue, 16 Nov 2004 15:58:10 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 5F16765414; Tue, 16 Nov 2004 15:58:09 +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 27404-03-12; Tue, 16 Nov 2004 15:58:09 +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 D2C436520C; Tue, 16 Nov 2004 15:58:08 +0000 (GMT) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 147B666A3; Tue, 16 Nov 2004 07:58:05 -0800 (PST) Date: Tue, 16 Nov 2004 07:58:05 -0800 From: Bruce M Simpson To: Mike Tancsa Message-ID: <20041116155805.GH847@empiric.icir.org> Mail-Followup-To: Mike Tancsa , freebsd-net@freebsd.org References: <4194CDF9.3000609@mr0vka.eu.org> <20041112210716.GC830@empiric.icir.org> <7lhdp0l2i9l94gunj0qdenaavl3o667r9m@4ax.com> <20041116145852.GD847@empiric.icir.org> <6.1.2.0.0.20041116103545.056b3658@64.7.153.2> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.1.2.0.0.20041116103545.056b3658@64.7.153.2> cc: freebsd-net@freebsd.org Subject: Re: OpenBGPd? 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, 16 Nov 2004 15:58:10 -0000 On Tue, Nov 16, 2004 at 10:43:25AM -0500, Mike Tancsa wrote: > Neat! What about the underlying OS ? Is it optimized for a particular OS > such as > http://www.pdos.lcs.mit.edu/click/ or FreeBSD or Linux ? Our primary development platform is FreeBSD. We also support Linux, and Click support should be back in for the 1.1 release. Performance work within XORP is ongoing; there is also a Win32 port planned. I just added blackhole support last week to CVS, and TCP-MD5 support has been in XORP for some months now, so hopefully by the time 1.1 comes out XORP should be a viable replacement for Quagga at least for the roles Sentex is using it for. Regards, BMS From owner-freebsd-net@FreeBSD.ORG Tue Nov 16 19:49:23 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 72C6116A4CE for ; Tue, 16 Nov 2004 19:49:23 +0000 (GMT) Received: from mail-svr1.cs.utah.edu (brahma.cs.utah.edu [155.98.64.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4607C43D1F for ; Tue, 16 Nov 2004 19:49:23 +0000 (GMT) (envelope-from vaibhave@cs.utah.edu) Received: from faith.cs.utah.edu (faith.cs.utah.edu [155.98.65.40]) by mail-svr1.cs.utah.edu (Postfix) with ESMTP id CF204346EC for ; Tue, 16 Nov 2004 12:49:20 -0700 (MST) Received: by faith.cs.utah.edu (Postfix, from userid 4969) id AECB22EC21; Tue, 16 Nov 2004 12:49:20 -0700 (MST) Received: from localhost (localhost [127.0.0.1]) by faith.cs.utah.edu (Postfix) with ESMTP id A50E934406 for ; Tue, 16 Nov 2004 19:49:20 +0000 (UTC) Date: Tue, 16 Nov 2004 12:49:20 -0700 (MST) From: Vaibhave Agarwal To: freebsd-net@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: network protocol interrupts 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, 16 Nov 2004 19:49:23 -0000 hi I was in little confusion about how the network software interrupts actually work. Is there a priority level within the network software interrupts too?? If there are two or more network level interrupts ( same priority level splnet) are pending, then does the scheduler schedules them in the order they were queued, or in the order they appear in the "netisrs" array. for example, the ip routine is defined as #define NETISR_IP 2 and polling callback as #define NETISR_POLL 0 and these are subscript of the array "netisrs". Can somebody please explain that. thanks vaibhave From owner-freebsd-net@FreeBSD.ORG Tue Nov 16 21:52: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 2AD5A16A4CE for ; Tue, 16 Nov 2004 21:52:20 +0000 (GMT) Received: from lariat.org (lariat.org [63.229.157.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F31743D45 for ; Tue, 16 Nov 2004 21:52:19 +0000 (GMT) (envelope-from brett@lariat.org) Received: (from brett@localhost) by lariat.org (8.9.3/8.9.3) id OAA06254 for net@freebsd.org; Tue, 16 Nov 2004 14:52:10 -0700 (MST) Date: Tue, 16 Nov 2004 14:52:10 -0700 (MST) From: Brett Glass Message-Id: <200411162152.OAA06254@lariat.org> To: net@freebsd.org Subject: PPTP client fails to function on 4.10-R 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, 16 Nov 2004 21:52:20 -0000 I'm tearing my hair trying to get this to work.... Maybe someone can help. Just brought up a new system with FreeBSD-4.10-R installed. Network card is an old Intel '557 (fxp); GENERIC kernel running. Tried to install and run the PPTP client from the Ports Collection, and am not able to connect to my PPTP server, even from the same LAN. Other clients (Windows-based and FreeBSD 5.2) are connecting successfully to the same server with no trouble. Has anyone noticed any problems with this port of late? Any problems doing GRE through the fxp driver? I've tried everything obvious and am looking for ideas (or for things I've missed). --Brett Glass From owner-freebsd-net@FreeBSD.ORG Tue Nov 16 22:46:27 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 59F3216A4CE for ; Tue, 16 Nov 2004 22:46:27 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A04E43D60 for ; Tue, 16 Nov 2004 22:46:26 +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 iAGMlLxv030916; Tue, 16 Nov 2004 14:47:21 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id iAGMlLO2030915; Tue, 16 Nov 2004 14:47:21 -0800 Date: Tue, 16 Nov 2004 14:47:21 -0800 From: Brooks Davis To: David Gilbert Message-ID: <20041116224721.GA30024@odin.ac.hmc.edu> References: <16789.23604.767942.781443@canoe.dclg.ca> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dDRMvlgZJXvWKvBx" Content-Disposition: inline In-Reply-To: <16789.23604.767942.781443@canoe.dclg.ca> 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: freebsd-net@freebsd.org Subject: Re: Trendnet TU-ET100C 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, 16 Nov 2004 22:46:27 -0000 --dDRMvlgZJXvWKvBx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 12, 2004 at 07:58:28PM -0500, David Gilbert wrote: > Has anyone seen, or is anyone working on a driver for the TrendNet > TU-ET100C ... which is a USB to Ethernet product. Alternatively, is > anyone working on a USB to Ethernet driver that's not yet in the tree? >=20 > Alternatively again, do USB drivers recognise themselves via product > numbers and is there a chance that there's a known chipset in there? > How might I tell? Odds are, it's supposed by one of the aue, cue, kue, or rue drivers. If you pry the case open you should be able to figure out which from reading the chips and looking in the driver sources. Once you know that, it's a fairly simple matter to add product and vendor ids to the driver. -- 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 --dDRMvlgZJXvWKvBx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBmoN4XY6L6fI4GtQRAoZHAKCNWfz8X7MGnRJhLA89h2Bz6/+IOgCgr490 TG+vjHXrEGZvwLERUKim7w0= =cJSU -----END PGP SIGNATURE----- --dDRMvlgZJXvWKvBx-- From owner-freebsd-net@FreeBSD.ORG Wed Nov 17 06:19:31 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 ED19916A4CE for ; Wed, 17 Nov 2004 06:19:31 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9BB8B43D1F for ; Wed, 17 Nov 2004 06:19:31 +0000 (GMT) (envelope-from vladgalu@gmail.com) Received: by rproxy.gmail.com with SMTP id b11so891122rne for ; Tue, 16 Nov 2004 22:19:31 -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=Ys72Kde62r6ce0pVsOFLGVTEQY0z6GDBuraszDmTNd5Vse/kq9EznG4iXuTRr3DF2QSUsfXOgfoQ1tQ3LPf8ttKtHZ4O/Eh5Pib+8MldK4/Zwbbv6L8TvejvTh4HEvidW7mU2AqaZckz77SJ8q5H+ywqEfSjffN5Hlutm7N6dqs= Received: by 10.38.81.30 with SMTP id e30mr219854rnb; Tue, 16 Nov 2004 22:19:31 -0800 (PST) Received: by 10.38.149.19 with HTTP; Tue, 16 Nov 2004 22:19:30 -0800 (PST) Message-ID: <79722fad041116221953d41781@mail.gmail.com> Date: Wed, 17 Nov 2004 08:19:30 +0200 From: Vlad GALU To: freebsd-net@freebsd.org In-Reply-To: <79722fad041112001022c29d13@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <79722fad041112001022c29d13@mail.gmail.com> Subject: Fwd: ALTQ and if_vlan X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Vlad GALU List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2004 06:19:32 -0000 ---------- Forwarded message ---------- From: Vlad GALU Date: Fri, 12 Nov 2004 08:10:30 +0000 Subject: ALTQ and if_vlan To: freebsd-pf@freebsd.org Hello. Since there wasn't any mailing list dedicated to ALTQ in particular, and Max maintains both PF and ALTQ, I came asking here. What's the status of the two things above together ? I plan to install a routing machine with an em card and I'd like to split the link to the network in vlans. Would shaping work on each vlan if I do it on the parent interface ? -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. From owner-freebsd-net@FreeBSD.ORG Wed Nov 17 16:50: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 F255B16A4D1; Wed, 17 Nov 2004 16:50:35 +0000 (GMT) Received: from vbook.fbsd.ru (asplinux.ru [195.133.213.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A3BE43D1F; Wed, 17 Nov 2004 16:50:35 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.43 (FreeBSD)) id 1CUT0q-000Dnd-L5; Wed, 17 Nov 2004 19:50:32 +0300 From: Vladimir Grebenschikov To: Max Laier In-Reply-To: <200411112124.12616.max@love2party.net> References: <200411112124.12616.max@love2party.net> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Organization: SWsoft Date: Wed, 17 Nov 2004 19:50:32 +0300 Message-Id: <1100710232.47346.5.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.0FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: in.c autoadding prefix route X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: vova@fbsd.ru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2004 16:50:36 -0000 =F7 =DE=D4, 11/11/2004 =D7 21:24 +0100, Max Laier =D0=C9=DB=C5=D4:=20 > All, >=20 > I know I have sent this a couple of times before, but never got anywhere.= This=20 > time I am set to commit! >=20 > The attached patch (http://people.freebsd.org/~mlaier/in.c.patch) derived= from=20 > WIDE via OpenBSD in.c, rev 1.21 improves the handling of automatic prefix= =20 > routes. >=20 > Right now you can't have two legs into the same network. If you want to, = you=20 > must give on of the interfaces a host address only (netmask /32). This wa= y it=20 > is not possible to hand over the route if one of the interfaces is=20 > "removed" (however this is done in the special case). >=20 > The patch allows to add more than on IPv4 address with the same prefix. I= n the=20 > case that there is a route already, we leave it alone and add the new add= ress=20 > without the IFA_ROUTE flag. When we remove an address later on, that has = a=20 > route associated, we try to find an alternative address to use for the ro= ute=20 > and hand it over. >=20 > This is required for CARP, but should be helpful for other situations as = well. >=20 > Any objections? This change actually broke one simple thing: # ifconfig lo0 alias 10.0.16.111/32 # ping 10.0.16.111 PING 10.0.16.111 (10.0.16.111): 56 data bytes ping: sendto: No route to host ^C # You should (anyway should) add routing of interface address itself to loop-back interface, like it usually done in all other cases. Please fix. --=20 Vladimir B. Grebenchikov vova@fbsd.ru From owner-freebsd-net@FreeBSD.ORG Wed Nov 17 18:14:00 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 DC2B716A4CE for ; Wed, 17 Nov 2004 18:14:00 +0000 (GMT) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 73E2143D39 for ; Wed, 17 Nov 2004 18:13:58 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.12.9p2/8.12.9) with ESMTP id iAHIDqUf050269 for ; Wed, 17 Nov 2004 21:13:52 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.12.9p2/8.12.9/Submit) id iAHIDqFT050268 for net@freebsd.org; Wed, 17 Nov 2004 21:13:52 +0300 (MSK) (envelope-from yar) Date: Wed, 17 Nov 2004 21:13:51 +0300 From: Yar Tikhiy To: net@freebsd.org Message-ID: <20041117181351.GA48071@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i Subject: polling(4) rocks! 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, 17 Nov 2004 18:14:01 -0000 Hi there, I can't but remind you that there's polling(4) in FreeBSD :-) Until today, I was convinced for some obscure reason that polling(4) was an experimental feature that might or might not work. Today I tried it on our central router box and got astounding results. The router box is a 1.4GHz Celeron PC with an fxp(4) interface split across a dozen of vlans. There is nothing special about its setup except for ~250 rules loaded into ipfw2. It is running 4.10-RELEASE. Without polling, it was able to switch full 10Mbytes/sec of traffic (~9kpps), but that took from 50 to 70% CPU time spent in interrupts. With polling on, interrupt time never exceeds 5% and it stays as low as 1-2% on average even when traffic is that high. Many thanks to folks who have had a hand in polling(4) development! Just in case: Please be aware that polling(4) won't make KDE run faster unless on a busy router ;-) -- Yar From owner-freebsd-net@FreeBSD.ORG Wed Nov 17 18:53:07 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 726BC16A4D0 for ; Wed, 17 Nov 2004 18:53:07 +0000 (GMT) Received: from grosbein.pp.ru (grgw.svzserv.kemerovo.su [213.184.64.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5212443D41 for ; Wed, 17 Nov 2004 18:53:05 +0000 (GMT) (envelope-from eugen@grosbein.pp.ru) Received: from grosbein.pp.ru (eugen@localhost [127.0.0.1]) by grosbein.pp.ru (8.13.1/8.13.1) with ESMTP id iAHIqnGg001424; Thu, 18 Nov 2004 01:52:49 +0700 (KRAT) (envelope-from eugen@grosbein.pp.ru) Received: (from eugen@localhost) by grosbein.pp.ru (8.13.1/8.13.1/Submit) id iAHIqnIu001423; Thu, 18 Nov 2004 01:52:49 +0700 (KRAT) (envelope-from eugen) Date: Thu, 18 Nov 2004 01:52:49 +0700 From: Eugene Grosbein To: Yar Tikhiy Message-ID: <20041117185248.GA1394@grosbein.pp.ru> References: <20041117181351.GA48071@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041117181351.GA48071@comp.chem.msu.su> User-Agent: Mutt/1.4.1i cc: net@freebsd.org Subject: Re: polling(4) rocks! 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, 17 Nov 2004 18:53:07 -0000 On Wed, Nov 17, 2004 at 09:13:51PM +0300, Yar Tikhiy wrote: > The router box is a 1.4GHz Celeron PC with an fxp(4) interface split > across a dozen of vlans. There is nothing special about its setup > except for ~250 rules loaded into ipfw2. It is running 4.10-RELEASE. > Without polling, it was able to switch full 10Mbytes/sec of traffic > (~9kpps), but that took from 50 to 70% CPU time spent in interrupts. > With polling on, interrupt time never exceeds 5% and it stays as low > as 1-2% on average even when traffic is that high. Does polling(4) increase latency? It is very imortant for router that handles lots of RTP (VoIP) traffic. Eugene From owner-freebsd-net@FreeBSD.ORG Wed Nov 17 19:00: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 7F08B16A4D8 for ; Wed, 17 Nov 2004 19:00:59 +0000 (GMT) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id AAA7643D4C for ; Wed, 17 Nov 2004 19:00:40 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.12.9p2/8.12.9) with ESMTP id iAHJ0ZUf052377; Wed, 17 Nov 2004 22:00:35 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.12.9p2/8.12.9/Submit) id iAHJ0YWm052376; Wed, 17 Nov 2004 22:00:34 +0300 (MSK) (envelope-from yar) Date: Wed, 17 Nov 2004 22:00:34 +0300 From: Yar Tikhiy To: Eugene Grosbein Message-ID: <20041117190034.GA52103@comp.chem.msu.su> References: <20041117181351.GA48071@comp.chem.msu.su> <20041117185248.GA1394@grosbein.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041117185248.GA1394@grosbein.pp.ru> User-Agent: Mutt/1.5.6i cc: net@freebsd.org Subject: Re: polling(4) rocks! 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, 17 Nov 2004 19:00:59 -0000 On Thu, Nov 18, 2004 at 01:52:49AM +0700, Eugene Grosbein wrote: > On Wed, Nov 17, 2004 at 09:13:51PM +0300, Yar Tikhiy wrote: > > > The router box is a 1.4GHz Celeron PC with an fxp(4) interface split > > across a dozen of vlans. There is nothing special about its setup > > except for ~250 rules loaded into ipfw2. It is running 4.10-RELEASE. > > Without polling, it was able to switch full 10Mbytes/sec of traffic > > (~9kpps), but that took from 50 to 70% CPU time spent in interrupts. > > With polling on, interrupt time never exceeds 5% and it stays as low > > as 1-2% on average even when traffic is that high. > > Does polling(4) increase latency? It is very imortant for router > that handles lots of RTP (VoIP) traffic. I did no tests of latency, but I guess that polling(4) may even decrease it in certain cases due to lower overhead of handling traffic. Of course, that should be tested in practice, but alas, we neither run nor use real-time network services here. -- Yar From owner-freebsd-net@FreeBSD.ORG Wed Nov 17 19:08:27 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 83A3716A4CE for ; Wed, 17 Nov 2004 19:08:27 +0000 (GMT) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 640EA43D55 for ; Wed, 17 Nov 2004 19:08:27 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (8.12.6/MantshX 2.0) with ESMTP id iAHJ8QYx025358; Wed, 17 Nov 2004 11:08:27 -0800 (PST) Received: from [10.1.1.245] (nfw2.codefab.com [199.103.21.225] (may be forged)) (authenticated bits=0)iAHJ8PMk024799; Wed, 17 Nov 2004 11:08:26 -0800 (PST) In-Reply-To: <20041117185248.GA1394@grosbein.pp.ru> References: <20041117181351.GA48071@comp.chem.msu.su> <20041117185248.GA1394@grosbein.pp.ru> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0E8F462B-38CC-11D9-B242-003065ABFD92@mac.com> Content-Transfer-Encoding: 7bit From: Charles Swiger Date: Wed, 17 Nov 2004 14:08:25 -0500 To: Eugene Grosbein X-Mailer: Apple Mail (2.619) cc: net@freebsd.org Subject: Re: polling(4) rocks! 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, 17 Nov 2004 19:08:27 -0000 On Nov 17, 2004, at 1:52 PM, Eugene Grosbein wrote: > On Wed, Nov 17, 2004 at 09:13:51PM +0300, Yar Tikhiy wrote: > [ ...praise of polling(4)... ] > Does polling(4) increase latency? It is very imortant for router > that handles lots of RTP (VoIP) traffic. Using polling does increase the latency of the traffic, slightly: if you follow the recommended configuration and set HZ=1000 or so, the added latency typically ends up being around 1ms. That's not enough to affect VoIP significantly. I've got 12 VoIP phone lines going through a FreeBSD 4.10 firewall using polling(4) over a T1 now. The firewall box is a Dell P3/400MHz or so using fxp and a quad-port card using the DEC 21x4x chipset. -- -Chuck From owner-freebsd-net@FreeBSD.ORG Wed Nov 17 19:38: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 77AD416A4CE for ; Wed, 17 Nov 2004 19:38:08 +0000 (GMT) Received: from stephanie.unixdaemons.com (stephanie.unixdaemons.com [67.18.111.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 019E443D53 for ; Wed, 17 Nov 2004 19:38:08 +0000 (GMT) (envelope-from bmilekic@technokratis.com) Received: from stephanie.unixdaemons.com (bmilekic@localhost.unixdaemons.com [127.0.0.1])iAHJc5Ft024385; Wed, 17 Nov 2004 14:38:05 -0500 (EST) Received: (from bmilekic@localhost) by stephanie.unixdaemons.com (8.13.1/8.12.1/Submit) id iAHJc2aR024374; Wed, 17 Nov 2004 14:38:02 -0500 (EST) (envelope-from bmilekic@technokratis.com) X-Authentication-Warning: stephanie.unixdaemons.com: bmilekic set sender to bmilekic@technokratis.com using -f Date: Wed, 17 Nov 2004 14:38:02 -0500 From: Bosko Milekic To: Charles Swiger Message-ID: <20041117193802.GA23728@technokratis.com> References: <20041117181351.GA48071@comp.chem.msu.su> <20041117185248.GA1394@grosbein.pp.ru> <0E8F462B-38CC-11D9-B242-003065ABFD92@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0E8F462B-38CC-11D9-B242-003065ABFD92@mac.com> User-Agent: Mutt/1.4.2.1i cc: Eugene Grosbein cc: net@freebsd.org Subject: Re: polling(4) rocks! 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, 17 Nov 2004 19:38:08 -0000 On Wed, Nov 17, 2004 at 02:08:25PM -0500, Charles Swiger wrote: > On Nov 17, 2004, at 1:52 PM, Eugene Grosbein wrote: > >On Wed, Nov 17, 2004 at 09:13:51PM +0300, Yar Tikhiy wrote: > >[ ...praise of polling(4)... ] > >Does polling(4) increase latency? It is very imortant for router > >that handles lots of RTP (VoIP) traffic. > > Using polling does increase the latency of the traffic, slightly: if > you follow the recommended configuration and set HZ=1000 or so, the > added latency typically ends up being around 1ms. > > That's not enough to affect VoIP significantly. I've got 12 VoIP phone > lines going through a FreeBSD 4.10 firewall using polling(4) over a T1 > now. The firewall box is a Dell P3/400MHz or so using fxp and a > quad-port card using the DEC 21x4x chipset. Latency is affected if in the case of using interrupts, it is lower than for polling. If you plot a latency versus pps graph, for example, you might notice that in the case of interrupts, the curve keeps growing beyond a certain pps number, whereas in the case of polling it flattens out. This happens because in the case of interrupts, more packets means more interrupts, always (assuming your card's coalescing abilities have been exhausted, i.e., very high pps, all the time), and more interrupts means more latency. In the case of polling, more packets does not mean more interrupts, and the system will process them at a more or less constant rate. > -- > -Chuck -- Bosko Milekic bmilekic@technokratis.com bmilekic@FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Wed Nov 17 21:03: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 46A0C16A4CE for ; Wed, 17 Nov 2004 21:03:22 +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 1C21843D1F for ; Wed, 17 Nov 2004 21:03:22 +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 8326F2F940; Wed, 17 Nov 2004 16:03:21 -0500 (EST) Date: Wed, 17 Nov 2004 16:03:21 -0500 From: James To: Eugene Grosbein Message-ID: <20041117210321.GA73977@scylla.towardex.com> References: <20041117181351.GA48071@comp.chem.msu.su> <20041117185248.GA1394@grosbein.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041117185248.GA1394@grosbein.pp.ru> User-Agent: Mutt/1.4.1i cc: Yar Tikhiy cc: net@freebsd.org Subject: Re: polling(4) rocks! 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, 17 Nov 2004 21:03:22 -0000 On Thu, Nov 18, 2004 at 01:52:49AM +0700, Eugene Grosbein wrote: > On Wed, Nov 17, 2004 at 09:13:51PM +0300, Yar Tikhiy wrote: > > > The router box is a 1.4GHz Celeron PC with an fxp(4) interface split > > across a dozen of vlans. There is nothing special about its setup > > except for ~250 rules loaded into ipfw2. It is running 4.10-RELEASE. > > Without polling, it was able to switch full 10Mbytes/sec of traffic > > (~9kpps), but that took from 50 to 70% CPU time spent in interrupts. > > With polling on, interrupt time never exceeds 5% and it stays as low > > as 1-2% on average even when traffic is that high. > > Does polling(4) increase latency? It is very imortant for router > that handles lots of RTP (VoIP) traffic. If you have a box doing lot of traffic in packets per second, enabling polling with HZ=2000 +/- will actually *decrease* latency due to far lower overhead instead of handling all those interrupts/sec. On a low-to-no traffic box, it's probably not worth it, however use your own judgement. Either way, the amount of latency polling(4) adds even in HZ=100 is very low enough (1 ms or less. if using 2000 or so, there is not much noticeable latency in line of microseconds) to affect most applications. -J -- James Jun TowardEX Technologies, Inc. Technical Lead IPv4 and Native IPv6 Colocation, Bandwidth, james@towardex.com and Web Hosting Services in the Metro Boston area cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net From owner-freebsd-net@FreeBSD.ORG Wed Nov 17 22:02: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 A1B5C16A4CE; Wed, 17 Nov 2004 22:02:56 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id D8BC843D46; Wed, 17 Nov 2004 22:02:55 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id iAHM2mhK047963; Thu, 18 Nov 2004 00:02:48 +0200 (EET) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 83815-14; Thu, 18 Nov 2004 00:02:47 +0200 (EET) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id iAHM2kFo047960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Nov 2004 00:02:47 +0200 (EET) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id iAHM2m7B081982; Thu, 18 Nov 2004 00:02:48 +0200 (EET) (envelope-from ru) Date: Thu, 18 Nov 2004 00:02:47 +0200 From: Ruslan Ermilov To: Vladimir Grebenschikov Message-ID: <20041117220247.GA60793@ip.net.ua> References: <200411112124.12616.max@love2party.net> <1100710232.47346.5.camel@localhost> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VS++wcV0S1rZb1Fb" Content-Disposition: inline In-Reply-To: <1100710232.47346.5.camel@localhost> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new at ip.net.ua cc: Max Laier cc: freebsd-arch@FreeBSD.org cc: freebsd-net@FreeBSD.org Subject: Re: in.c autoadding prefix route [PATCH] 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, 17 Nov 2004 22:02:56 -0000 --VS++wcV0S1rZb1Fb Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 17, 2004 at 07:50:32PM +0300, Vladimir Grebenschikov wrote: > =F7 =DE=D4, 11/11/2004 =D7 21:24 +0100, Max Laier =D0=C9=DB=C5=D4:=20 > > All, > >=20 > > I know I have sent this a couple of times before, but never got anywher= e. This=20 > > time I am set to commit! > >=20 > > The attached patch (http://people.freebsd.org/~mlaier/in.c.patch) deriv= ed from=20 > > WIDE via OpenBSD in.c, rev 1.21 improves the handling of automatic pref= ix=20 > > routes. > >=20 > > Right now you can't have two legs into the same network. If you want to= , you=20 > > must give on of the interfaces a host address only (netmask /32). This = way it=20 > > is not possible to hand over the route if one of the interfaces is=20 > > "removed" (however this is done in the special case). > >=20 > > The patch allows to add more than on IPv4 address with the same prefix.= In the=20 > > case that there is a route already, we leave it alone and add the new a= ddress=20 > > without the IFA_ROUTE flag. When we remove an address later on, that ha= s a=20 > > route associated, we try to find an alternative address to use for the = route=20 > > and hand it over. > >=20 > > This is required for CARP, but should be helpful for other situations a= s well. > >=20 > > Any objections? >=20 > This change actually broke one simple thing: >=20 > # ifconfig lo0 alias 10.0.16.111/32 > # ping 10.0.16.111 > PING 10.0.16.111 (10.0.16.111): 56 data bytes > ping: sendto: No route to host > ^C > # >=20 > You should (anyway should) add routing of interface address itself to > loop-back interface, like it usually done in all other cases. >=20 > Please fix. >=20 This bug was borrowed from OpenBSD (they still have it). The problem is that in "struct in_ifaddr", initially ia_ifa.ifa_addr points to ia_addr - and - ia_ifa.ifa_dstaddr points to ia_dstaddr and the IFF_LOOPBACK code in in_ifinit() just resets the ia_ifa.ifa_dstaddr pointer to point to ia_ifa.ifa_addr. But new in_addprefix() code ignores this fact, and just uses INET fields directly, i.e., ia_dstaddr (which happens to be 0.0.0.0). Then all the havoc happens (it matches another interface address (ia_addr=3D127.0.0.1, ia_dstaddr=3D0) and refuses to install a host route. The fix is a one line change, and as I later found out, it also corresponds to NetBSD revision 1.83: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/in.c.diff?r1=3D1.82&r= 2=3D1.83&cvsroot=3Dnetbsd %%% Index: in.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/netinet/in.c,v retrieving revision 1.78 diff -u -p -r1.78 in.c --- in.c 12 Nov 2004 20:53:51 -0000 1.78 +++ in.c 17 Nov 2004 21:42:44 -0000 @@ -759,7 +759,7 @@ in_ifinit(ifp, ia, sin, scrub) ia->ia_netbroadcast.s_addr =3D htonl(ia->ia_net | ~ ia->ia_netmask); } else if (ifp->if_flags & IFF_LOOPBACK) { - ia->ia_ifa.ifa_dstaddr =3D ia->ia_ifa.ifa_addr; + ia->ia_dstaddr =3D ia->ia_addr; flags |=3D RTF_HOST; } else if (ifp->if_flags & IFF_POINTOPOINT) { if (ia->ia_dstaddr.sin_family !=3D AF_INET) %%% An alternative would be to fix in_addprefix() to pay attention to ia_ifa pointers, but as this bug shows, this is error prone. It's much easier to just initialize the ia_dstaddr as appropriate. =09 Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --VS++wcV0S1rZb1Fb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBm8qHqRfpzJluFF4RAjApAJ9/D86FqpwPvb6oLRmyd41zjyWZQQCeKXuy A6+YwAicxvtMT+7Os1KcZvk= =I3CA -----END PGP SIGNATURE----- --VS++wcV0S1rZb1Fb-- From owner-freebsd-net@FreeBSD.ORG Wed Nov 17 23:07: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 2B48716A4CE; Wed, 17 Nov 2004 23:07:21 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.191]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B55743D4C; Wed, 17 Nov 2004 23:07:20 +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 1CUYtT-0004l1-00; Thu, 18 Nov 2004 00:07:19 +0100 Received: from [217.83.7.105] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1CUYtS-0000z9-00; Thu, 18 Nov 2004 00:07:19 +0100 From: Max Laier To: freebsd-net@freebsd.org Date: Thu, 18 Nov 2004 00:07:30 +0100 User-Agent: KMail/1.7.1 References: <200411112124.12616.max@love2party.net> <1100710232.47346.5.camel@localhost> <20041117220247.GA60793@ip.net.ua> In-Reply-To: <20041117220247.GA60793@ip.net.ua> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart7242309.1ZlrrbEUC1"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200411180007.39802.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 cc: Vladimir Grebenschikov cc: freebsd-arch@freebsd.org Subject: Re: in.c autoadding prefix route [PATCH] 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, 17 Nov 2004 23:07:21 -0000 --nextPart7242309.1ZlrrbEUC1 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 17 November 2004 23:02, Ruslan Ermilov wrote: > On Wed, Nov 17, 2004 at 07:50:32PM +0300, Vladimir Grebenschikov wrote: > > =D0=92 =D1=87=D1=82, 11/11/2004 =D0=B2 21:24 +0100, Max Laier =D0=BF=D0= =B8=D1=88=D0=B5=D1=82: > > > All, > > > > > > I know I have sent this a couple of times before, but never got > > > anywhere. This time I am set to commit! > > > > > > The attached patch (http://people.freebsd.org/~mlaier/in.c.patch) > > > derived from WIDE via OpenBSD in.c, rev 1.21 improves the handling of > > > automatic prefix routes. > > > > > > Right now you can't have two legs into the same network. If you want > > > to, you must give on of the interfaces a host address only (netmask > > > /32). This way it is not possible to hand over the route if one of the > > > interfaces is "removed" (however this is done in the special case). > > > > > > The patch allows to add more than on IPv4 address with the same prefi= x. > > > In the case that there is a route already, we leave it alone and add > > > the new address without the IFA_ROUTE flag. When we remove an address > > > later on, that has a route associated, we try to find an alternative > > > address to use for the route and hand it over. > > > > > > This is required for CARP, but should be helpful for other situations > > > as well. > > > > > > Any objections? > > > > This change actually broke one simple thing: > > > > # ifconfig lo0 alias 10.0.16.111/32 > > # ping 10.0.16.111 > > PING 10.0.16.111 (10.0.16.111): 56 data bytes > > ping: sendto: No route to host > > ^C > > # > > > > You should (anyway should) add routing of interface address itself to > > loop-back interface, like it usually done in all other cases. > > > > Please fix. > > This bug was borrowed from OpenBSD (they still have it). > The problem is that in "struct in_ifaddr", initially > > ia_ifa.ifa_addr points to ia_addr > - and - > ia_ifa.ifa_dstaddr points to ia_dstaddr > > and the IFF_LOOPBACK code in in_ifinit() just resets > the ia_ifa.ifa_dstaddr pointer to point to ia_ifa.ifa_addr. > But new in_addprefix() code ignores this fact, and just > uses INET fields directly, i.e., ia_dstaddr (which happens > to be 0.0.0.0). Then all the havoc happens (it matches > another interface address (ia_addr=3D127.0.0.1, ia_dstaddr=3D0) > and refuses to install a host route. > > The fix is a one line change, and as I later found out, > it also corresponds to NetBSD revision 1.83: > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/in.c.diff?r1=3D1.82= &r2=3D >1.83&cvsroot=3Dnetbsd > > %%% > Index: in.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > RCS file: /home/ncvs/src/sys/netinet/in.c,v > retrieving revision 1.78 > diff -u -p -r1.78 in.c > --- in.c 12 Nov 2004 20:53:51 -0000 1.78 > +++ in.c 17 Nov 2004 21:42:44 -0000 > @@ -759,7 +759,7 @@ in_ifinit(ifp, ia, sin, scrub) > ia->ia_netbroadcast.s_addr =3D > htonl(ia->ia_net | ~ ia->ia_netmask); > } else if (ifp->if_flags & IFF_LOOPBACK) { > - ia->ia_ifa.ifa_dstaddr =3D ia->ia_ifa.ifa_addr; > + ia->ia_dstaddr =3D ia->ia_addr; > flags |=3D RTF_HOST; > } else if (ifp->if_flags & IFF_POINTOPOINT) { > if (ia->ia_dstaddr.sin_family !=3D AF_INET) > %%% > > An alternative would be to fix in_addprefix() to pay > attention to ia_ifa pointers, but as this bug shows, > this is error prone. It's much easier to just > initialize the ia_dstaddr as appropriate. Thanks. Good analysis ... I failed to see it :-\ I agree that setting ia_dstaddr is the less painful option. Again, thanks a lot and sorry for the mess! =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 --nextPart7242309.1ZlrrbEUC1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBm9m7XyyEoT62BG0RAnI0AJ4rLuIe3rkQDhBla5REG+U3X5ZlBgCfVeLd cmuE1BIz9XdLzFOjq6lW8TU= =aShL -----END PGP SIGNATURE----- --nextPart7242309.1ZlrrbEUC1-- From owner-freebsd-net@FreeBSD.ORG Thu Nov 18 02:00:25 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 858E216A4CE for ; Thu, 18 Nov 2004 02:00:25 +0000 (GMT) Received: from smtp.freemail.gr (smtp.freemail.gr [213.239.180.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBB8743D49 for ; Thu, 18 Nov 2004 02:00:24 +0000 (GMT) (envelope-from dionch@freemail.gr) Received: by smtp.freemail.gr (Postfix, from userid 101) id 00739BC1DF; Thu, 18 Nov 2004 04:00:22 +0200 (EET) Received: from acer1501 (dslcustomer625.vivodi.gr [80.76.58.117])by smtp.freemail.gr (Postfix) with ESMTP id 925E0BC023for ; Thu, 18 Nov 2004 04:00:21 +0200 (EET) Message-ID: <002f01c4cd12$427b78b0$0100000a@acer1501> From: "Chris Dionissopoulos[freemail]" To: Date: Thu, 18 Nov 2004 03:59:35 +0200 MIME-Version: 1.0 Content-Type: text/plain;format=flowed;charset="iso-8859-7"; reply-type=original Content-Transfer-Encoding: 7bit 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: ng_fec with tap interfaces. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Chris Dionissopoulos\[freemail\]" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2004 02:00:25 -0000 Hello, I'm trying to load-balance and failover 2 lines using ng_fec. This is my configuraration and schema so far: LAN-----------------------clients_net | [router1]----[box1] -----[router2] |\---$sp-nat-1 |\---$sp-nat-2 (ISP1) (ISP2) ~\~~~~~~~~~~~~~~~~/~~~ nternet ~~~~~~\~~~~~~~~~/~~~~~~~ \ / \ / ------------------------------- | | <-----$public1,$public2 [ box2 ] Routing on Box1(freebsd5.3): ~~~~~~~~~~~ IP1 thru router1 , IP2 thru router2 ie. route add $public1/32 10.0.0.1 (LanIP of router1) route add $public2/32 10.0.1.1 (LanIP of router2) Interfaces: ~~~~~~~ openvpn --local 10.0.0.2 --remote $public1 --dev tap0 --ifconfig 10.0.3.1 0xffffff00 openvpn --local 10.0.1.2 --remote $public2 --dev tap1 --ifconfig 10.0.4.1 0xffffff00 tap0: flags=28943 mtu 1500 inet 10.0.3.1 netmask 0xffffff00 broadcast 10.0.3.255 ether 00:bd:18:6e:45:00 tap1: flags=28943 mtu 1500 inet 10.0.4.1 netmask 0xffffff00 broadcast 10.0.4.255 ether 00:bd:bc:0b:49:01 ng_fec: ~~~~~ #ngctl mkpeer fec dummy fec #ngctl msg fec0: add_iface "tap0" #ngctl msg fec0: add_iface "tap1" #ngctl msg fec0: set_mode_inet #ifoconfig fec0 up # route add default -iface fec0 Routing on Box2(freebsd5.3): ~~~~~~~~~~~ route add $default $some_gate Interfaces: ~~~~~~~ openvpn --local $public1 --remote $isp-nat-1 --dev tap0 --ifconfig 10.0.3.2 0xffffff00 openvpn --local $public2 --remote $isp-nat-2 --dev tap1 --ifconfig 10.0.4.2 0xffffff00 tap0: flags=28943 mtu 1500 inet 10.0.3.2 netmask 0xffffff00 broadcast 10.0.3.255 ether 00:bd:18:6d:42:00 tap1: flags=28943 mtu 1500 inet 10.0.4.2 netmask 0xffffff00 broadcast 10.0.4.255 ether 00:bd:be:3b:14:01 ng_fec(same as box1): ~~~~~ #ngctl mkpeer fec dummy fec #ngctl msg fec0: add_iface "tap0" #ngctl msg fec0: add_iface "tap1" #ngctl msg fec0: set_mode_inet #ifoconfig fec0 up # route add $clients_net/$clients_mask -iface fec0 Everything works great. Traffic flows both links (for incoming and outgoing), but I get "fec0: failed to check status of link tap0" and "fec0: failed to check status of link tap1" messages on console all the time. Also, when one link goes down I start to loose half of of my traffic (both sides). Searching carefully ng_fec and if_tap source code I found : ------ng_fec.c, line 612------------------- ifp = p->fec_if; error = (*ifp->if_ioctl)(ifp, SIOCGIFMEDIA, (caddr_t)&ifmr); if (error) { printf("fec%d: failed to check status " "of link %s\n", priv->unit, ifp->if_xname); continue; } -------------------------------------------- ------------if_tap.c, line 484--------------- static int tapifioctl(ifp, cmd, data) struct ifnet *ifp; u_long cmd; caddr_t data; { struct tap_softc *tp = (struct tap_softc *)(ifp->if_softc); struct ifstat *ifs = NULL; int s, dummy; switch (cmd) { case SIOCSIFFLAGS: /* XXX -- just like vmnet does */ case SIOCADDMULTI: case SIOCDELMULTI: break; case SIOCGIFSTATUS: s = splimp(); ifs = (struct ifstat *)data; dummy = strlen(ifs->ascii); mtx_lock(&tp->tap_mtx); if (tp->tap_pid != 0 && dummy < sizeof(ifs->ascii)) snprintf(ifs->ascii + dummy, sizeof(ifs->ascii) - dummy, "\tOpened by PID %d\n", tp->tap_pid); mtx_unlock(&tp->tap_mtx); splx(s); break; default: s = splimp(); dummy = ether_ioctl(ifp, cmd, data); splx(s); return (dummy); } return (0); } /* tapifioctl */ ----------------------------------------- It seems that ng_fec doesn't queries correctly if_tap for link state (default:-> dummy return). Does anyone has a workaround for this issue or any idea how to implement link-state mechanism in if_tap device? If this is imposimple (due to tap device nature) , is possible to add functions in ng_fec for an alternative link-state mechanism ? (arpings maybe, like linux channel bonding) thanks for your time, Chris Dionissopoulos. ____________________________________________________________________ http://www.freemail.gr - äůńĺÜí őđçńĺóßá çëĺęôńďíéęďý ôá÷őäńďěĺßďő. http://www.freemail.gr - free email service for the Greek-speaking. From owner-freebsd-net@FreeBSD.ORG Thu Nov 18 05:28: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 43CB316A4CE; Thu, 18 Nov 2004 05:28:12 +0000 (GMT) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D53243D1F; Thu, 18 Nov 2004 05:28:06 +0000 (GMT) (envelope-from wilkinsa@squash.dsto.defence.gov.au) Received: from ednmsw503.dsto.defence.gov.au (ednmsw503.dsto.defence.gov.au [131.185.2.150]) by digger1.defence.gov.au with ESMTP id iAI5R6Zg027175; Thu, 18 Nov 2004 15:57:06 +1030 (CST) Received: from muttley.dsto.defence.gov.au (unverified) by ednmsw503.dsto.defence.gov.au (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Thu, 18 Nov 2004 15:57:49 +1030 Received: from ednex501.dsto.defence.gov.au (ednex501.dsto.defence.gov.au [131.185.2.81]) by muttley.dsto.defence.gov.au (8.11.3/8.11.3) with ESMTP id iAI5NMh14302; Thu, 18 Nov 2004 15:53:22 +1030 (CST) Received: from squash.dsto.defence.gov.au ([131.185.40.212]) by ednex501.dsto.defence.gov.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RZJDQ89Z; Thu, 18 Nov 2004 15:53:12 +1030 Received: from squash.dsto.defence.gov.au (localhost [127.0.0.1]) by squash.dsto.defence.gov.au (8.12.11/8.12.11) with ESMTP id iAI5OIcS068285 ; Thu, 18 Nov 2004 15:54:18 +1030 (CST) (envelope-from wilkinsa@squash.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by squash.dsto.defence.gov.au (8.12.11/8.12.11/Submit) id iAI5OIhT068284; Thu, 18 Nov 2004 15:54:18 +1030 (CST) (envelope-from wilkinsa) Date: Thu, 18 Nov 2004 15:54:17 +1030 From: "Wilkinson, Alex" To: net@freebsd.org Message-ID: <20041118052417.GR66822@squash.dsto.defence.gov.au> Mail-Followup-To: net@freebsd.org, ru@freebsd.org References: <20041117181351.GA48071@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20041117181351.GA48071@comp.chem.msu.su> User-Agent: Mutt/1.5.6i Subject: Re: polling(4) rocks! 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, 18 Nov 2004 05:28:12 -0000 Why can some NIC use polling and others not ? eg I went to turn on polling on my BCM5782 Broadcom NetXtreme Gigabit Ethernet Card. And bge(4) doesn't mention anything about polling. Is it a hardware feature of the NIC ? - aW 0n Wed, Nov 17, 2004 at 09:13:51PM +0300, Yar Tikhiy wrote: Hi there, I can't but remind you that there's polling(4) in FreeBSD :-) Until today, I was convinced for some obscure reason that polling(4) was an experimental feature that might or might not work. Today I tried it on our central router box and got astounding results. The router box is a 1.4GHz Celeron PC with an fxp(4) interface split across a dozen of vlans. There is nothing special about its setup except for ~250 rules loaded into ipfw2. It is running 4.10-RELEASE. Without polling, it was able to switch full 10Mbytes/sec of traffic (~9kpps), but that took from 50 to 70% CPU time spent in interrupts. With polling on, interrupt time never exceeds 5% and it stays as low as 1-2% on average even when traffic is that high. Many thanks to folks who have had a hand in polling(4) development! Just in case: Please be aware that polling(4) won't make KDE run faster unless on a busy router ;-) -- Yar _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Thu Nov 18 05:43:35 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 26B3F16A4D0 for ; Thu, 18 Nov 2004 05:43:34 +0000 (GMT) Received: from beastie.hyow.eu.org (213-152-46-100.dsl.eclipse.net.uk [213.152.46.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A34043D2D for ; Thu, 18 Nov 2004 05:43:31 +0000 (GMT) (envelope-from mark@hyow.eu.org) Received: (qmail 61083 invoked by uid 751); 18 Nov 2004 05:51:26 +0000 Received: from mark@hyow.eu.org by beastie.hyow.eu.org by uid 731 with qmail-scanner-1.22-st-qms (clamdscan: 0.75. spamassassin: 2.64. Clear:RC:1(127.0.0.1):. Processed in 1.148575 secs); 18 Nov 2004 05:51:26 -0000 X-Antivirus-HYOW.EU.ORG-Mail-From: mark@hyow.eu.org via beastie.hyow.eu.org X-Antivirus-HYOW.EU.ORG: 1.22-st-qms (Clear:RC:1(127.0.0.1):. Processed in 1.148575 secs Process 61078) Received: from localhost.hyow.eu.org (HELO beastie.hyow.eu.org) (mark@hyow.eu.org@127.0.0.1) by beastie.hyow.eu.org with SMTP; 18 Nov 2004 05:51:24 +0000 Received: from 10.0.0.11 (SquirrelMail authenticated user mark@hyow.eu.org); by beastie.hyow.eu.org with HTTP; Thu, 18 Nov 2004 05:51:24 -0000 (GMT) Message-ID: <54762.10.0.0.11.1100757084.squirrel@10.0.0.11> In-Reply-To: <20041118052417.GR66822@squash.dsto.defence.gov.au> References: <20041117181351.GA48071@comp.chem.msu.su> <20041118052417.GR66822@squash.dsto.defence.gov.au> Date: Thu, 18 Nov 2004 05:51:24 -0000 (GMT) From: "Mark Magiera" To: "Wilkinson, Alex" User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal cc: net@freebsd.org Subject: Re: polling(4) rocks! 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, 18 Nov 2004 05:43:35 -0000 > Why can some NIC use polling and others not ? > > eg I went to turn on polling on my BCM5782 Broadcom NetXtreme Gigabit > Ethernet Card. And bge(4) doesn't mention anything about polling. > > Is it a hardware feature of the NIC ? > > - aW > >From `man 4 polling`: SUPPORTED DEVICES Polling requires explicit modifications to the device drivers. As of this writing, the dc(4), em(4), fxp(4), rl(4), and sis(4) devices are supported, with other in the works. This seems to suggest all hardware supports it, just some drivers don't at this/that(2002) moment in time. -- Mark Magiera From owner-freebsd-net@FreeBSD.ORG Thu Nov 18 07:49: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 3624616A4CE for ; Thu, 18 Nov 2004 07:49:33 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 581BC43D3F for ; Thu, 18 Nov 2004 07:49:32 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id iAI7nSnk079449; Thu, 18 Nov 2004 09:49:28 +0200 (EET) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 10587-06; Thu, 18 Nov 2004 09:49:27 +0200 (EET) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id iAI7nRJt079446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Nov 2004 09:49:27 +0200 (EET) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id iAI7nUM5063056; Thu, 18 Nov 2004 09:49:30 +0200 (EET) (envelope-from ru) Date: Thu, 18 Nov 2004 09:49:29 +0200 From: Ruslan Ermilov To: Mark Magiera Message-ID: <20041118074929.GC60828@ip.net.ua> References: <20041117181351.GA48071@comp.chem.msu.su> <20041118052417.GR66822@squash.dsto.defence.gov.au> <54762.10.0.0.11.1100757084.squirrel@10.0.0.11> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OBd5C1Lgu00Gd/Tn" Content-Disposition: inline In-Reply-To: <54762.10.0.0.11.1100757084.squirrel@10.0.0.11> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new at ip.net.ua cc: "Wilkinson, Alex" cc: net@freebsd.org Subject: Re: polling(4) rocks! 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, 18 Nov 2004 07:49:33 -0000 --OBd5C1Lgu00Gd/Tn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 18, 2004 at 05:51:24AM -0000, Mark Magiera wrote: > > Why can some NIC use polling and others not ? > > > > eg I went to turn on polling on my BCM5782 Broadcom NetXtreme Gigabit > > Ethernet Card. And bge(4) doesn't mention anything about polling. > > > > Is it a hardware feature of the NIC ? > > > > - aW > > >=20 > >From `man 4 polling`: > SUPPORTED DEVICES > Polling requires explicit modifications to the device drivers. As of > this writing, the dc(4), em(4), fxp(4), rl(4), and sis(4) devices are > supported, with other in the works. >=20 > This seems to suggest all hardware supports it, just some drivers don't at > this/that(2002) moment in time. >=20 The polling(4) in -CURRENT has much more devices supported: : Device polling requires explicit modifications to the device drivers. : As of this writing, the dc(4), em(4), fwe(4), fxp(4), ixgb(4), : nge(4), re(4), rl(4), sf(4), sis(4), ste(4), vge(4), and vr(4) : devices are supported, with others in the works. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --OBd5C1Lgu00Gd/Tn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBnFQJqRfpzJluFF4RAv2PAJ9+4bRLD3EaMhYSiexSRNqFACutoACeJLDy +ilE866BEKbjv6E7vJXKdko= =Xfa1 -----END PGP SIGNATURE----- --OBd5C1Lgu00Gd/Tn-- From owner-freebsd-net@FreeBSD.ORG Thu Nov 18 08:14:28 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 6F64016A4D0 for ; Thu, 18 Nov 2004 08:14:28 +0000 (GMT) Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by mx1.FreeBSD.org (Postfix) with SMTP id AD89743D4C for ; Thu, 18 Nov 2004 08:14:27 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 71866 invoked from network); 18 Nov 2004 08:14:26 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 18 Nov 2004 08:14:26 -0000 X-pair-Authenticated: 209.68.2.70 Date: Thu, 18 Nov 2004 02:14:25 -0600 (CST) From: Mike Silbersack To: James In-Reply-To: <20041115222310.GA93130@scylla.towardex.com> Message-ID: <20041118021307.C12314@odysseus.silby.com> References: <20041115222310.GA93130@scylla.towardex.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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: Thu, 18 Nov 2004 08:14:28 -0000 On Mon, 15 Nov 2004, James wrote: > Folks, > > 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 I think that Andre Oppermann will have a lot of interest in this, but he's on vacation at the moment, and won't be back for a few weeks. Once he returns and catches up on his e-mail, I'm sure he'll add something. If he doesn't... e-mail him directly! Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Thu Nov 18 09:11: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 38BC116A4CE; Thu, 18 Nov 2004 09:11:51 +0000 (GMT) Received: from ms-dienst.rz.rwth-aachen.de (ms-1.rz.RWTH-Aachen.DE [134.130.3.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id ADD2043D31; Thu, 18 Nov 2004 09:11:50 +0000 (GMT) (envelope-from chris@unixpages.org) Received: from r220-1 (r220-1.rz.RWTH-Aachen.DE [134.130.3.31]) by ms-dienst.rz.rwth-aachen.de (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0I7D006LHAPX9H@ms-dienst.rz.rwth-aachen.de>; Thu, 18 Nov 2004 10:08:22 +0100 (MET) Received: from relay.rwth-aachen.de ([134.130.3.1]) by r220-1 (MailMonitor for SMTP v1.2.2 ) ; Thu, 18 Nov 2004 10:08:21 +0100 (MET) Received: from haakonia.hitnet.rwth-aachen.de (haakonia.hitnet.RWTH-Aachen.DE [137.226.181.92])iAI98LZn001405; Thu, 18 Nov 2004 10:08:21 +0100 (MET) Received: from gondor.middleearth (gondor.middleearth [192.168.1.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))(Postfix) with ESMTP id C3DAA28449; Thu, 18 Nov 2004 10:08:15 +0100 (CET) Received: by gondor.middleearth (Postfix, from userid 1001) id 850162281E; Thu, 18 Nov 2004 10:08:15 +0100 (CET) Date: Thu, 18 Nov 2004 10:08:15 +0100 From: Christian Brueffer In-reply-to: <20041118052417.GR66822@squash.dsto.defence.gov.au> To: net@freebsd.org, ru@freebsd.org Message-id: <20041118090815.GG579@unixpages.org> MIME-version: 1.0 Content-type: multipart/signed; boundary=wj9ZLJVQDRFjGSdK; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-disposition: inline User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 6.0-CURRENT X-PGP-Key: http://people.freebsd.org/~brueffer/brueffer.key.asc X-PGP-Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D References: <20041117181351.GA48071@comp.chem.msu.su> <20041118052417.GR66822@squash.dsto.defence.gov.au> Subject: Re: polling(4) rocks! 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, 18 Nov 2004 09:11:51 -0000 --wj9ZLJVQDRFjGSdK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 18, 2004 at 03:54:17PM +1030, Wilkinson, Alex wrote: > Why can some NIC use polling and others not ? >=20 > eg I went to turn on polling on my BCM5782 Broadcom NetXtreme Gigabit > Ethernet Card. And bge(4) doesn't mention anything about polling. > =20 I have polling support for bge(4) in the works. - Christian --=20 Christian Brueffer chris@unixpages.org brueffer@FreeBSD.org GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --wj9ZLJVQDRFjGSdK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBnGZ/bHYXjKDtmC0RAhIOAKDtGYShYURpOnJpI+w/vZEp01VR0QCffOm/ 3Xr7REEMDMagATSLVkhzyzc= =vDSB -----END PGP SIGNATURE----- --wj9ZLJVQDRFjGSdK-- From owner-freebsd-net@FreeBSD.ORG Thu Nov 18 13:51: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 D8A0316A4CE for ; Thu, 18 Nov 2004 13:51:01 +0000 (GMT) Received: from a.mx.interacesso.pt (super11.nortenet.pt [212.13.35.201]) by mx1.FreeBSD.org (Postfix) with SMTP id 4671543D48 for ; Thu, 18 Nov 2004 13:51:00 +0000 (GMT) (envelope-from elton.machado@norteglobal.com) Received: (qmail 12650 invoked by uid 104); 18 Nov 2004 13:50:08 -0000 Received: from elton.machado@norteglobal.com by mx0.interacesso.pt by uid 101 with qmail-scanner-1.22st Clear:RC:1(212.13.50.173):. Processed in 0.088109 secs); 18 Nov 2004 13:50:08 -0000 Received: from 50-173.dial.nortenet.pt (HELO ?192.168.123.1?) (212.13.50.173) by a.mx.interacesso.pt with SMTP; 18 Nov 2004 13:50:08 -0000 Message-ID: <419CA8CA.2020401@norteglobal.com> Date: Thu, 18 Nov 2004 13:51:06 +0000 From: Elton Machado User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Help ! Proxy arp at PPTP 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, 18 Nov 2004 13:51:02 -0000 Hi! How can i have proxyarp in my tun interface created by the pptpd ? I want to connect from my pptp client to the others clients connected to the pptpd server. I have this at my config file: /etc/ppp/options.pptpd: ### lock ## turn pppd syslog debugging on debug name pptpd # Don't need this nobsdcomp proxyarp asyncmap 0 -chap -mschap +mschap-v2 require-mppe lcp-echo-failure 30 lcp-echo-interval 5 ipcp-accept-local ipcp-accept-remote ms-dns <> #radius and at /etc/ppp/ppp.conf loop: set timeout 0 set log phase chat connect lcp ipcp command set device localhost:pptp set dial set login set ifaddr 217.172.47.11 10.0.2.10-10.0.2.20 set server /var/tmp/loop "" 0177 loop-in: set timeout 0 set log phase lcp ipcp command allow mode direct pptp: load loop enable chap enable MSCHAPv2 disable deflate pred1 deny deflate pred1 set mppe 128 stateless enable MPPE accept MPPE [...] I didn't try to insert any more pptp client at configuration, but I just can't connect to other services running at different ip on pptp host. What i have to do to get it working? Thanks in advanceHel From owner-freebsd-net@FreeBSD.ORG Wed Nov 17 19:32:17 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 93EEF16A4CE; Wed, 17 Nov 2004 19:32:17 +0000 (GMT) Received: from lariat.org (lariat.org [63.229.157.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 04B8543D55; Wed, 17 Nov 2004 19:32:15 +0000 (GMT) (envelope-from brett@lariat.org) Received: from runaround.lariat.org (IDENT:ppp1000.lariat.org@lariat.org [63.229.157.2]) by lariat.org (8.9.3/8.9.3) with ESMTP id MAA20794; Wed, 17 Nov 2004 12:32:11 -0700 (MST) X-message-flag: Warning! Use of Microsoft Outlook renders your system susceptible to Internet worms. Message-Id: <6.1.2.0.2.20041117103952.05d09048@localhost> X-Sender: brett@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 17 Nov 2004 12:31:02 -0700 To: brett@lariat.org From: Brett Glass Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailman-Approved-At: Thu, 18 Nov 2004 14:00:20 +0000 Subject: Re: PPTP client not working on 4.10-R 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, 17 Nov 2004 19:32:17 -0000 Everyone: I've found what was causing the problems which I reported on net@ and questions@ involving a PPTP client. And I may have uncovered a security problem which -- if my analysis is correct -- should be addressed. (I'd like independent confirmation of this.) As mentioned in earlier postings, I'd just set up a 4.10-R machine which was to be a PPTP client. (It was using the port of the Linux PPTP client in /usr/ports/net/pptpclient.) It could not connect to a PPTP server on the same LAN, even though that PPTP server was correctly serving other clients -- including Windows machines, FreeBSD machines, and a couple of SOHO routers running embedded Linux. The problem FINALLY went away after I set the environment variable "gateway_enable" to "YES" in the client's /etc/rc.conf file and rebooted. The client machine at first seemed to work properly; TCP connections to machines on the local LAN worked correctly. It was when I tried to use the machine as a PPTP client (it was going to tunnel out through the PPTP server to the Internet) that I saw problems -- not only on the client but on the server to which it was trying to connect. After instrumenting the systems with tcpdump and setting up multiple windows to "tail" all of the logs, I saw what was going on. The PPTP call setup process (which is done via a TCP socket) worked. However, once the initial handshake was complete and the "call" was established, the client's PPP process -- which was supposed to begin LCP negotiations with the server via an encrypted GRE tunnel -- didn't receive any data from the server at all. At the same time, the server's PPP process began to report all sorts of errors. What happened was that GRE packets received by the client machine were being bounced back, verbatim, to the PPTP server. The PPTP server was mightily confused by this echoing and in fact suffered a partial crash. (Multitudes of messages accumulating in /var/ppp/ppp.log overflowed the PPTP server's /var partition, and some daemons on the machine failed when they couldn't log.) It filled its logs with error messages generated by its own reflected packets -- some whole, some corrupted. It might be worthwhile to dig a bit into the kernel code and find out why the packets were being reflected, and why the reflection stopped when I turned on packet forwarding. One shouldn't have to enable packet forwarding between interfaces to communicate with a PPTP server on one's local LAN! In fact, it can be a security risk. If you have to enable packet forwarding to establish a VPN connection, you might inadvertently open up a back door from the Internet at large to the private network which you're accessing via the VPN. Because this is a security concern, I'm posting this message to security@ as well as the two lists where I posted originally. But I'm BCC'ing all three to prevent responses from being cross-posted. --Brett Glass From owner-freebsd-net@FreeBSD.ORG Thu Nov 18 14:08: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 023E516A4CE for ; Thu, 18 Nov 2004 14:08:47 +0000 (GMT) Received: from a.mx.interacesso.pt (super11.nortenet.pt [212.13.35.201]) by mx1.FreeBSD.org (Postfix) with SMTP id 17B0643D2D for ; Thu, 18 Nov 2004 14:08:44 +0000 (GMT) (envelope-from elton.machado@norteglobal.com) Received: (qmail 29220 invoked by uid 104); 18 Nov 2004 14:07:53 -0000 Received: from elton.machado@norteglobal.com by mx0.interacesso.pt by uid 101 with qmail-scanner-1.22st Clear:RC:1(212.13.50.173):. Processed in 0.050263 secs); 18 Nov 2004 14:07:53 -0000 Received: from 50-173.dial.nortenet.pt (HELO ?192.168.123.1?) (212.13.50.173) by a.mx.interacesso.pt with SMTP; 18 Nov 2004 14:07:53 -0000 Message-ID: <419CACF2.5020402@norteglobal.com> Date: Thu, 18 Nov 2004 14:08:50 +0000 From: Elton Machado User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: How can I create and use a Tap device 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, 18 Nov 2004 14:08:47 -0000 I need a virtual ethernet device, can I use tap for that? How can I create it? Thanks From owner-freebsd-net@FreeBSD.ORG Thu Nov 18 14:51: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 1C68816A4CE for ; Thu, 18 Nov 2004 14:51:09 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8131643D48 for ; Thu, 18 Nov 2004 14:51:08 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id CD4286520C; Thu, 18 Nov 2004 14:51:06 +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 64442-01-2; Thu, 18 Nov 2004 14:51:06 +0000 (GMT) Received: from empiric.dek.spc.org (adsl-67-124-246-45.dsl.snfc21.pacbell.net [67.124.246.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id CEC7E651F4; Thu, 18 Nov 2004 14:51:05 +0000 (GMT) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id B6E306334; Thu, 18 Nov 2004 06:51:01 -0800 (PST) Date: Thu, 18 Nov 2004 06:51:01 -0800 From: Bruce M Simpson To: Elton Machado Message-ID: <20041118145101.GI697@empiric.icir.org> References: <419CACF2.5020402@norteglobal.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <419CACF2.5020402@norteglobal.com> cc: net@freebsd.org Subject: Re: How can I create and use a Tap device 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, 18 Nov 2004 14:51:09 -0000 On Thu, Nov 18, 2004 at 02:08:50PM +0000, Elton Machado wrote: > I need a virtual ethernet device, can I use tap for that? Yes. > How can I create it? Read the man page. BMS From owner-freebsd-net@FreeBSD.ORG Thu Nov 18 16:49: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 A734216A4CE for ; Thu, 18 Nov 2004 16:49:19 +0000 (GMT) Received: from a.mx.interacesso.pt (super11.nortenet.pt [212.13.35.201]) by mx1.FreeBSD.org (Postfix) with SMTP id 022BB43D41 for ; Thu, 18 Nov 2004 16:49:18 +0000 (GMT) (envelope-from elton.machado@norteglobal.com) Received: (qmail 1903 invoked by uid 104); 18 Nov 2004 16:48:27 -0000 Received: from elton.machado@norteglobal.com by mx0.interacesso.pt by uid 101 with qmail-scanner-1.22st Clear:RC:1(212.13.50.173):. Processed in 0.197889 secs); 18 Nov 2004 16:48:27 -0000 Received: from 50-173.dial.nortenet.pt (HELO ?192.168.123.1?) (212.13.50.173) by a.mx.interacesso.pt with SMTP; 18 Nov 2004 16:48:26 -0000 Message-ID: <419CD295.70103@norteglobal.com> Date: Thu, 18 Nov 2004 16:49:25 +0000 From: Elton Machado User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: net@freebsd.org References: <419CA8CA.2020401@norteglobal.com> In-Reply-To: <419CA8CA.2020401@norteglobal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Help ! Proxy arp at PPTP (FIXED) 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, 18 Nov 2004 16:49:19 -0000 I already fix it... I was using the wrong interface at pptp server side. Elton Machado wrote: > Hi! > > > How can i have proxyarp in my tun interface created by the pptpd ? > > > I want to connect from my pptp client to the others clients connected > to the pptpd server. > > I have this at my config file: > > /etc/ppp/options.pptpd: > ### > lock > ## turn pppd syslog debugging on > debug > name pptpd > # Don't need this > nobsdcomp > proxyarp > asyncmap 0 > -chap > -mschap > +mschap-v2 > require-mppe > lcp-echo-failure 30 > lcp-echo-interval 5 > ipcp-accept-local > ipcp-accept-remote > ms-dns <> > #radius > > and at /etc/ppp/ppp.conf > > loop: > set timeout 0 > set log phase chat connect lcp ipcp command > set device localhost:pptp > set dial > set login > set ifaddr 217.172.47.11 10.0.2.10-10.0.2.20 > set server /var/tmp/loop "" 0177 > > loop-in: > set timeout 0 > set log phase lcp ipcp command > allow mode direct > > pptp: > load loop > enable chap > enable MSCHAPv2 > disable deflate pred1 > deny deflate pred1 > set mppe 128 stateless > enable MPPE > accept MPPE > > [...] > > I didn't try to insert any more pptp client at configuration, but I > just can't connect to other services running at different ip on pptp > host. What i have to do to get it working? > > Thanks in advanceHel > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Thu Nov 18 16:50: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 6534616A4CE for ; Thu, 18 Nov 2004 16:50:01 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id C759E43D5A for ; Thu, 18 Nov 2004 16:50:00 +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 iAIGmSTf073999; Thu, 18 Nov 2004 11:48:28 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)iAIGmSWh073996; Thu, 18 Nov 2004 16:48:28 GMT (envelope-from robert@fledge.watson.org) Date: Thu, 18 Nov 2004 16:48:28 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Elton Machado In-Reply-To: <419CACF2.5020402@norteglobal.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: net@freebsd.org Subject: Re: How can I create and use a Tap device 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, 18 Nov 2004 16:50:01 -0000 On Thu, 18 Nov 2004, Elton Machado wrote: > I need a virtual ethernet device, can I use tap for that? > > How can I create it? Really quite easy, and fairly well documented in the man page. Basically, you need to: - Load the module or compile it in. - Open /dev/tapX where X is the interface number. When the device is opened, the network interface will be instantiated. - Read ethernet frames -- you'll get one per read, make sure to provide enough buffer room for a full frame at the MTU of choice. - Write ethernet frames -- one per write. Typically input from a tap device will look something like this: char packet[MAXPACKET]; struct ether_header *h; ssize_t len, recvlen; len = MAXPACKET; recvlen = read(tap_fd, packet, len); if (recvlen == -1) { perror("read"); return (-1); } if (len < sizeof(struct ether_header)) { fprintf(stderr, "short frame read"); return (-1); } eh = (struct ether_header *)(packet); ... And a write will look something like this: sendlen = write(tap_fd, packet, recvlen); if (sendlen == -1) { perror("write"); return (-1); } if (sendlen != recvlen) { fprintd(stderr, "short frame write"); return (-1); } Make sure to properly initialize the ethernet frame header with the protocol type, source/destination ethernet addresses, and so on. A couple of performance caveats: - Every packet delivery requires going to user space, so possibly a context switch and certainly a system call. - Every packet is copied to user space, and/or from user space, so you get a lot of memory copying. For prototyping or light-weight stuff, tap is a great tool, but to improve performance you want to run network code in the kernel, especially if there are other applications running (and/or processing packets), which will increase the number of context switches. The cost as it stands isn't bad -- I regularly use tap-derived tunnel software for remote network access without a hitch. There were recently some posts made with patches to optimize the allocation of kernel memory for packets sent using a tap device, which are in the mailing list archives (not sure if they were merged yet). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research From owner-freebsd-net@FreeBSD.ORG Thu Nov 18 18:49: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 CEBC916A4CE; Thu, 18 Nov 2004 18:49:44 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9BE1043D39; Thu, 18 Nov 2004 18:49:44 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 74F3E7A403; Thu, 18 Nov 2004 10:49:44 -0800 (PST) Message-ID: <419CEEC8.8010203@elischer.org> Date: Thu, 18 Nov 2004 10:49:44 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Robert Watson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: Elton Machado cc: net@freebsd.org Subject: Re: How can I create and use a Tap device 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, 18 Nov 2004 18:49:44 -0000 Robert Watson wrote: >On Thu, 18 Nov 2004, Elton Machado wrote: > > > >>I need a virtual ethernet device, can I use tap for that? >> >>How can I create it? >> >> >[...] > >A couple of performance caveats: > >- Every packet delivery requires going to user space, so possibly a > context switch and certainly a system call. >- Every packet is copied to user space, and/or from user space, so you get > a lot of memory copying. > You can also use netgraph's eiface node. thid delivers teh packet to a netgraph interface which can be then used for further processing in the kernel.. (e.g. a ksocket node to encapsulate it in UDP).. No extra context switches.. > >For prototyping or light-weight stuff, tap is a great tool, but to improve >performance you want to run network code in the kernel, especially if >there are other applications running (and/or processing packets), which >will increase the number of context switches. The cost as it stands isn't >bad -- I regularly use tap-derived tunnel software for remote network >access without a hitch. There were recently some posts made with patches >to optimize the allocation of kernel memory for packets sent using a tap >device, which are in the mailing list archives (not sure if they were >merged yet). > >Robert N M Watson FreeBSD Core Team, TrustedBSD Projects >robert@fledge.watson.org Principal Research Scientist, McAfee Research > > >_______________________________________________ >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 Fri Nov 19 04:47: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 D923B16A4CE for ; Fri, 19 Nov 2004 04:47:47 +0000 (GMT) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF92F43D48 for ; Fri, 19 Nov 2004 04:47:46 +0000 (GMT) (envelope-from wilkinsa@squash.dsto.defence.gov.au) Received: from ednmsw503.dsto.defence.gov.au (ednmsw503.dsto.defence.gov.au [131.185.2.150]) by digger1.defence.gov.au with ESMTP id iAJ4kkZg001175 for ; Fri, 19 Nov 2004 15:16:46 +1030 (CST) Received: from muttley.dsto.defence.gov.au (unverified) by ednmsw503.dsto.defence.gov.au (Content Technologies SMTPRS 4.3.10) with ESMTP id for ; Fri, 19 Nov 2004 15:17:40 +1030 Received: from ednex501.dsto.defence.gov.au (ednex501.dsto.defence.gov.au [131.185.2.81]) by muttley.dsto.defence.gov.au (8.11.3/8.11.3) with ESMTP id iAJ4e6h19049 for ; Fri, 19 Nov 2004 15:10:06 +1030 (CST) Received: from squash.dsto.defence.gov.au ([131.185.40.212]) by ednex501.dsto.defence.gov.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RZJDS5VH; Fri, 19 Nov 2004 15:09:55 +1030 Received: from squash.dsto.defence.gov.au (localhost [127.0.0.1]) by squash.dsto.defence.gov.au (8.12.11/8.12.11) with ESMTP id iAJ4e7BX001236 for ; Fri, 19 Nov 2004 15:10:07 +1030 (CST) (envelope-from wilkinsa@squash.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by squash.dsto.defence.gov.au (8.12.11/8.12.11/Submit) id iAJ4e68l001235 for net@freebsd.org; Fri, 19 Nov 2004 15:10:06 +1030 (CST) (envelope-from wilkinsa) Date: Fri, 19 Nov 2004 15:10:06 +1030 From: "Wilkinson, Alex" To: net@freebsd.org Message-ID: <20041119044006.GM768@squash.dsto.defence.gov.au> Mail-Followup-To: net@freebsd.org References: <20041118090815.GG579@unixpages.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20041118090815.GG579@unixpages.org> User-Agent: Mutt/1.5.6i Subject: Re: polling(4) rocks! 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, 19 Nov 2004 04:47:48 -0000 Ahh....nice ! Please send a HEADSUP when done. Thanks - aW 0n Thu, Nov 18, 2004 at 07:38:15PM +1030, Christian Brueffer wrote: On Thu, Nov 18, 2004 at 03:54:17PM +1030, Wilkinson, Alex wrote: > Why can some NIC use polling and others not ? > > eg I went to turn on polling on my BCM5782 Broadcom NetXtreme Gigabit > Ethernet Card. And bge(4) doesn't mention anything about polling. > I have polling support for bge(4) in the works. - Christian -- Christian Brueffer chris@unixpages.org brueffer@FreeBSD.org GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D From owner-freebsd-net@FreeBSD.ORG Fri Nov 19 06:38: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 78E0C16A4CE for ; Fri, 19 Nov 2004 06:38:21 +0000 (GMT) Received: from ns.trimail.co.za (ns.trimail.co.za [196.25.53.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id 25B7B43D31 for ; Fri, 19 Nov 2004 06:38:19 +0000 (GMT) (envelope-from antonrb@tridan.co.za) Received: from webserver ([196.25.53.69]) by ns.trimail.co.za (8.12.5/8.11.6) with ESMTP id iAJ6Zar9027684 for ; Fri, 19 Nov 2004 08:35:36 +0200 (SAST) (envelope-from antonrb@tridan.co.za) Message-ID: <200411190838090921.004E2A50@196.25.53.67> X-Mailer: Calypso Version 3.30.00.00 (4) Date: Fri, 19 Nov 2004 08:38:09 +0200 From: "Anton Bester" To: freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Gateway/Router X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: antonrb@tridan.co.za List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2004 06:38:21 -0000 Hello I'm trying to setup a gateway/router between my private network and my= Public network. My public network is connected via T1 and I have 5 public IP's I have installed a FreeBSD 5.1 server and enabled the following: 1. gateway 2. IPFILTER 3. IPNAT 4. defaultrouter=3D"196.x.x.1" (currently my cisco router going out to= internet) 5. Bind (only forwarding to my local DNS Server on the public network) I have put in 2 NIC's and configured them as follows: 1. rl0: to my private network (192.168.1.1) 2. ed0: to my public network (196.x.x.3) My ipnat.rules file looks as follows: map ed0 192.168.1.0/255.255.255.0 -> 196.x.x.3/255.255.255.x My problem is that I cannot access the internet from my private network, I= can do dns lookups from a command prompt from my private network. The= workstation configuration on the private network is like this: 1. IP 192.168.1.3 2. subnet 255.255.255.0 3. gateway 192.168.1.1 4. DNS 192.168.1.1 Is there anything else I need to do, the FreeBSD Manual talks about "Dual= Homed Hosts" and that it need to be enabled but it does not tell how and= were. Any help will be appreciated. Regards Extech Anton Bester Tridan Solutions (Pty) Ltd Cell: +27 82 920 6970 Tel: +27 12 347 0775 Fax: +27 (0)86 650 4606 Website: http://www.tridan.co.za From owner-freebsd-net@FreeBSD.ORG Fri Nov 19 06:51: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 24DB616A4CE for ; Fri, 19 Nov 2004 06:51:55 +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 1084C43D5F for ; Fri, 19 Nov 2004 06:51:54 +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 iAJ6pp8i077684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Nov 2004 13:51:51 +0700 (ICT) Received: (from on@localhost) by mail.cs.ait.ac.th (8.12.11/8.12.11/Submit) id iAJ6ppvq077681; Fri, 19 Nov 2004 13:51:51 +0700 (ICT) Date: Fri, 19 Nov 2004 13:51:51 +0700 (ICT) Message-Id: <200411190651.iAJ6ppvq077681@mail.cs.ait.ac.th> From: Olivier Nicole To: antonrb@tridan.co.za In-reply-to: <200411190838090921.004E2A50@196.25.53.67> (antonrb@tridan.co.za) X-Virus-Scanned: on CSIM by amavisd-milter (http://www.amavis.org/) 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: Fri, 19 Nov 2004 06:51:55 -0000 > I'm trying to setup a gateway/router between my private network and my Public network. > > My public network is connected via T1 and I have 5 public IP's Did you defined a default gateway on your router box? What is the result of "netstat -r" Olivier From owner-freebsd-net@FreeBSD.ORG Fri Nov 19 07:09: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 0963816A4CE for ; Fri, 19 Nov 2004 07:09:39 +0000 (GMT) Received: from ns.trimail.co.za (ns.trimail.co.za [196.25.53.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5755B43D45 for ; Fri, 19 Nov 2004 07:09:37 +0000 (GMT) (envelope-from extech@dod.co.za) Received: from webserver ([196.25.53.69]) by ns.trimail.co.za (8.12.5/8.11.6) with ESMTP id iAJ76Sr9028384; Fri, 19 Nov 2004 09:06:32 +0200 (SAST) (envelope-from extech@dod.co.za) Message-ID: <200411190909060609.006A7F00@196.25.53.67> In-Reply-To: <200411190651.iAJ6ppvq077681@mail.cs.ait.ac.th> References: <200411190651.iAJ6ppvq077681@mail.cs.ait.ac.th> X-Mailer: Calypso Version 3.30.00.00 (4) Date: Fri, 19 Nov 2004 09:09:06 +0200 From: "Anton Bester" To: "Olivier Nicole" Content-Type: text/plain; charset="us-ascii" cc: freebsd-net@freebsd.org Subject: Re: Gateway/Router X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: extech@dod.co.za List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2004 07:09:39 -0000 >Did you defined a default gateway on your router box? rc.conf entries: defaultrouter="196.25.53.65" gateway_enable="YES" router_enable="YES" router="/sbin/routed" router_flags="-q" >What is the result of "netstat -r" [root@gateway extech]# netstat -r Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 196.25.53.65 UGSc 0 0 ed0 localhost localhost UH 0 0 lo0 192.168.1 link#1 UC 1 0 rl0 192.168.1.2 00:08:a1:1b:3e:2f UHLW 1 2 rl0 828 196.25.53.64/29 link#2 UC 3 0 ed0 196.25.53.65 link#2 UHLW 1 0 ed0 ns 00:d0:b7:0b:f6:0c UHLW 1 38 ed0 648 196.25.53.69 00:0d:87:81:f4:da UHLW 1 137 ed0 1190 Internet6: Destination Gateway Flags Netif Expire localhost localhost UH lo0 fe80::%rl0 link#1 UC rl0 fe80::210:b5ff:feb 00:10:b5:be:74:c6 UHL lo0 fe80::%ed0 link#2 UC ed0 fe80::2c0:dfff:fea 00:c0:df:a3:05:4d UHL lo0 fe80::%lo0 fe80::1%lo0 Uc lo0 fe80::1%lo0 link#4 UHL lo0 ff01:: localhost U lo0 ff02::%rl0 link#1 UC rl0 ff02::%ed0 link#2 UC ed0 ff02::%lo0 localhost UC lo0 [root@gateway extech]# Regards From owner-freebsd-net@FreeBSD.ORG Fri Nov 19 07:18: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 C994F16A4CF for ; Fri, 19 Nov 2004 07:18:12 +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 CE69C43D39 for ; Fri, 19 Nov 2004 07:18:11 +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 iAJ7HvIm078916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Nov 2004 14:17:57 +0700 (ICT) Received: (from on@localhost) by mail.cs.ait.ac.th (8.12.11/8.12.11/Submit) id iAJ7Hvtc078913; Fri, 19 Nov 2004 14:17:57 +0700 (ICT) Date: Fri, 19 Nov 2004 14:17:57 +0700 (ICT) Message-Id: <200411190717.iAJ7Hvtc078913@mail.cs.ait.ac.th> From: Olivier Nicole To: extech@dod.co.za In-reply-to: <200411190909060609.006A7F00@196.25.53.67> (extech@dod.co.za) X-Virus-Scanned: on CSIM by amavisd-milter (http://www.amavis.org/) 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: Fri, 19 Nov 2004 07:18:12 -0000 > rc.conf entries: > > defaultrouter="196.25.53.65" > gateway_enable="YES" > router_enable="YES" > router="/sbin/routed" > router_flags="-q" > > >What is the result of "netstat -r" > > [root@gateway extech]# netstat -r > Routing tables > > Internet: > Destination Gateway Flags Refs Use Netif Expire > default 196.25.53.65 UGSc 0 0 ed0 Looks OK, what is the IP address of your interface ed0? ifconfig ed0 Olivier From owner-freebsd-net@FreeBSD.ORG Fri Nov 19 07:29: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 E032B16A4CE for ; Fri, 19 Nov 2004 07:29:04 +0000 (GMT) Received: from mailhost.schluting.com (schluting.com [131.252.214.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9002443D55 for ; Fri, 19 Nov 2004 07:29:04 +0000 (GMT) (envelope-from charlie@schluting.com) Received: from localhost (localhost [127.0.0.1]) by mailhost.schluting.com (Postfix) with ESMTP id 2125A2445 for ; Thu, 18 Nov 2004 23:29:04 -0800 (PST) Received: from mailhost.schluting.com ([127.0.0.1]) by localhost (schluting.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28734-02 for ; Thu, 18 Nov 2004 23:28:58 -0800 (PST) Received: from [10.1.0.69] (c-24-20-163-50.client.comcast.net [24.20.163.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.schluting.com (Postfix) with ESMTP id 0E66C2203 for ; Thu, 18 Nov 2004 23:28:57 -0800 (PST) Message-ID: <419DA0BD.5040504@schluting.com> Date: Thu, 18 Nov 2004 23:29:01 -0800 From: Charlie Schluting User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by your mom at schluting.com Subject: vlan module loading... 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, 19 Nov 2004 07:29:05 -0000 mkay, I have to ask a possibly stupid question. There's a recent bug where freebsd hangs with if_vlan.ko loaded when using bpf. I'm being bitten by said bug. BUT I have 'device vlan' in my kernel. Why is the module loading?! rc.conf is the only thing I've modified, WRT vlan config: dmz# grep vlan /etc/rc.conf cloned_interfaces="vlan2" ifconfig_vlan2="inet 192.168.0.10 netmask 255.255.255.192 vlan 2 vlandev fxp0" dhcpd_ifaces="fxp0 vlan2" I call it vlan2 because on my switch I send vlan1 traffic untagged to this box. Not that it matters. Why do I see this?: dmz# kldstat Id Refs Address Size Name 1 2 0xc0400000 4678e4 kernel 2 1 0xc2e60000 4000 if_vlan.ko Running: 5.2.1-RELEASE-p9 TIA :) -Charlie. From owner-freebsd-net@FreeBSD.ORG Fri Nov 19 07:30: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 19CC216A4CE for ; Fri, 19 Nov 2004 07:30:03 +0000 (GMT) Received: from ns.trimail.co.za (ns.trimail.co.za [196.25.53.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id C5DDA43D1F for ; Fri, 19 Nov 2004 07:30:00 +0000 (GMT) (envelope-from extech@dod.co.za) Received: from webserver ([196.25.53.69]) by ns.trimail.co.za (8.12.5/8.11.6) with ESMTP id iAJ7Qvr9028825; Fri, 19 Nov 2004 09:26:57 +0200 (SAST) (envelope-from extech@dod.co.za) Message-ID: <200411190929320187.007D326A@196.25.53.67> In-Reply-To: <200411190717.iAJ7Hvtc078913@mail.cs.ait.ac.th> References: <200411190717.iAJ7Hvtc078913@mail.cs.ait.ac.th> X-Mailer: Calypso Version 3.30.00.00 (4) Date: Fri, 19 Nov 2004 09:29:32 +0200 From: "Anton Bester" To: "Olivier Nicole" Content-Type: text/plain; charset="us-ascii" cc: freebsd-net@freebsd.org Subject: Re: Gateway/Router X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: extech@dod.co.za List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2004 07:30:03 -0000 >Looks OK, what is the IP address of your interface ed0? rl0: flags=8843 mtu 1500 inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255 inet6 fe80::210:b5ff:febe:74c6%rl0 prefixlen 64 scopeid 0x1 ether 00:10:b5:be:74:c6 media: Ethernet autoselect (100baseTX ) status: active ed0: flags=8843 mtu 1500 inet 196.25.53.66 netmask 0xfffffff8 broadcast 196.25.53.71 inet6 fe80::2c0:dfff:fea3:54d%ed0 prefixlen 64 scopeid 0x2 ether 00:c0:df:a3:05:4d lp0: flags=8810 mtu 1500 lo0: flags=8049 mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet 127.0.0.1 netmask 0xff000000 From owner-freebsd-net@FreeBSD.ORG Fri Nov 19 07:35: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 EB63516A4CE for ; Fri, 19 Nov 2004 07:35:02 +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 10DF043D53 for ; Fri, 19 Nov 2004 07:35: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 iAJ7YlpG079609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Nov 2004 14:34:47 +0700 (ICT) Received: (from on@localhost) by mail.cs.ait.ac.th (8.12.11/8.12.11/Submit) id iAJ7YlXS079606; Fri, 19 Nov 2004 14:34:47 +0700 (ICT) Date: Fri, 19 Nov 2004 14:34:47 +0700 (ICT) Message-Id: <200411190734.iAJ7YlXS079606@mail.cs.ait.ac.th> From: Olivier Nicole To: extech@dod.co.za In-reply-to: <200411190929320187.007D326A@196.25.53.67> (extech@dod.co.za) X-Virus-Scanned: on CSIM by amavisd-milter (http://www.amavis.org/) 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: Fri, 19 Nov 2004 07:35:03 -0000 > ed0: flags=8843 mtu 1500 > inet 196.25.53.66 netmask 0xfffffff8 broadcast 196.25.53.71 Sound good so far. I suppose that the FBSD box can connect anywhere on Internet, ping www.yahoo.com would work. So lets have a look at your client configuration, I saw you have a machine 192.168.1.2, I beleive it can ping your FBSD box ping 192.168.1.1 What does it have configured as gateway? Olivier From owner-freebsd-net@FreeBSD.ORG Fri Nov 19 07:39:07 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 540B416A4CE for ; Fri, 19 Nov 2004 07:39:07 +0000 (GMT) Received: from ns.trimail.co.za (ns.trimail.co.za [196.25.53.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9DC6D43D2F for ; Fri, 19 Nov 2004 07:39:04 +0000 (GMT) (envelope-from extech@dod.co.za) Received: from webserver ([196.25.53.69]) by ns.trimail.co.za (8.12.5/8.11.6) with ESMTP id iAJ7a8r9029056; Fri, 19 Nov 2004 09:36:08 +0200 (SAST) (envelope-from extech@dod.co.za) Message-ID: <200411190938420031.0085963E@196.25.53.67> In-Reply-To: <200411190734.iAJ7YlXS079606@mail.cs.ait.ac.th> References: <200411190734.iAJ7YlXS079606@mail.cs.ait.ac.th> X-Mailer: Calypso Version 3.30.00.00 (4) Date: Fri, 19 Nov 2004 09:38:42 +0200 From: "Anton Bester" To: "Olivier Nicole" Content-Type: text/plain; charset="us-ascii" cc: freebsd-net@freebsd.org Subject: Re: Gateway/Router X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: extech@dod.co.za List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2004 07:39:07 -0000 > ping www.yahoo.com Yip, connect to anywhere, no problem [root@gateway etc]# ping www.yahoo.com PING www.yahoo.akadns.net (68.142.226.34): 56 data bytes 64 bytes from 68.142.226.34: icmp_seq=0 ttl=57 time=280.872 ms 64 bytes from 68.142.226.34: icmp_seq=1 ttl=56 time=278.866 ms 64 bytes from 68.142.226.34: icmp_seq=2 ttl=56 time=277.444 ms 64 bytes from 68.142.226.34: icmp_seq=3 ttl=57 time=277.177 ms 64 bytes from 68.142.226.34: icmp_seq=4 ttl=57 time=277.361 ms 64 bytes from 68.142.226.34: icmp_seq=5 ttl=56 time=277.414 ms 64 bytes from 68.142.226.34: icmp_seq=6 ttl=56 time=277.096 ms ^C --- www.yahoo.akadns.net ping statistics --- 7 packets transmitted, 7 packets received, 0% packet loss round-trip min/avg/max/stddev = 277.096/278.033/280.872/1.284 ms From owner-freebsd-net@FreeBSD.ORG Fri Nov 19 07:43:46 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 59DDA16A4CE for ; Fri, 19 Nov 2004 07:43:46 +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 74D3643D49 for ; Fri, 19 Nov 2004 07:43:45 +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 iAJ7hY5h080028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Nov 2004 14:43:34 +0700 (ICT) Received: (from on@localhost) by mail.cs.ait.ac.th (8.12.11/8.12.11/Submit) id iAJ7hYsA080025; Fri, 19 Nov 2004 14:43:34 +0700 (ICT) Date: Fri, 19 Nov 2004 14:43:34 +0700 (ICT) Message-Id: <200411190743.iAJ7hYsA080025@mail.cs.ait.ac.th> From: Olivier Nicole To: extech@dod.co.za In-reply-to: <200411190938420031.0085963E@196.25.53.67> (extech@dod.co.za) X-Virus-Scanned: on CSIM by amavisd-milter (http://www.amavis.org/) 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: Fri, 19 Nov 2004 07:43:46 -0000 Please the 2 other questions? from client ping the router default gateway on the client? Olivier From owner-freebsd-net@FreeBSD.ORG Fri Nov 19 07:54: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 32A4916A4CE for ; Fri, 19 Nov 2004 07:54:19 +0000 (GMT) Received: from ns.trimail.co.za (ns.trimail.co.za [196.25.53.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC34B43D2D for ; Fri, 19 Nov 2004 07:54:17 +0000 (GMT) (envelope-from extech@dod.co.za) Received: from webserver ([196.25.53.69]) by ns.trimail.co.za (8.12.5/8.11.6) with ESMTP id iAJ7pIr9029495; Fri, 19 Nov 2004 09:51:18 +0200 (SAST) (envelope-from extech@dod.co.za) Message-ID: <200411190953520609.00937B30@196.25.53.67> In-Reply-To: <200411190734.iAJ7YlXS079606@mail.cs.ait.ac.th> References: <200411190734.iAJ7YlXS079606@mail.cs.ait.ac.th> X-Mailer: Calypso Version 3.30.00.00 (4) Date: Fri, 19 Nov 2004 09:53:52 +0200 From: "Anton Bester" To: "Olivier Nicole" Content-Type: text/plain; charset="us-ascii" cc: freebsd-net@freebsd.org Subject: Re: Gateway/Router X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: extech@dod.co.za List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2004 07:54:19 -0000 Sorry, was in a bit of a hurry. >So lets have a look at your client configuration, I saw you have a >machine 192.168.1.2, I beleive it can ping your FBSD box Yes, 192.168.1.2 ping 192.168.1.1 (NIC rl0 on FreeBSD Box) no problem >What does it have configured as gateway? 192.168.1.1 From owner-freebsd-net@FreeBSD.ORG Fri Nov 19 08:06:53 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 54FFB16A4CE for ; Fri, 19 Nov 2004 08:06:53 +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 6723A43D1D for ; Fri, 19 Nov 2004 08:06:52 +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 iAJ86fa3081161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Nov 2004 15:06:41 +0700 (ICT) Received: (from on@localhost) by mail.cs.ait.ac.th (8.12.11/8.12.11/Submit) id iAJ86fVa081158; Fri, 19 Nov 2004 15:06:41 +0700 (ICT) Date: Fri, 19 Nov 2004 15:06:41 +0700 (ICT) Message-Id: <200411190806.iAJ86fVa081158@mail.cs.ait.ac.th> From: Olivier Nicole To: extech@dod.co.za In-reply-to: <200411190953520609.00937B30@196.25.53.67> (extech@dod.co.za) X-Virus-Scanned: on CSIM by amavisd-milter (http://www.amavis.org/) 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: Fri, 19 Nov 2004 08:06:53 -0000 Hummm, it still looks correct so far. >From the client can you ping the IP of ed0 ping 126...66 I think Olivier From owner-freebsd-net@FreeBSD.ORG Fri Nov 19 08:20: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 53AAC16A4CE for ; Fri, 19 Nov 2004 08:20:02 +0000 (GMT) Received: from ns.trimail.co.za (ns.trimail.co.za [196.25.53.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F99443D1F for ; Fri, 19 Nov 2004 08:20:00 +0000 (GMT) (envelope-from extech@dod.co.za) Received: from webserver ([196.25.53.69]) by ns.trimail.co.za (8.12.5/8.11.6) with ESMTP id iAJ8HHr9030086 for ; Fri, 19 Nov 2004 10:17:18 +0200 (SAST) (envelope-from extech@dod.co.za) Message-ID: <200411191019510421.00AB444C@196.25.53.67> References: <200411190806.iAJ86fVa081158@mail.cs.ait.ac.th> <200411191019190031.00AAC5C6@196.25.53.67> X-Mailer: Calypso Version 3.30.00.00 (4) Date: Fri, 19 Nov 2004 10:19:51 +0200 From: "Anton Bester" To: freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Re: Gateway/Router X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: extech@dod.co.za List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2004 08:20:02 -0000 >>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 From owner-freebsd-net@FreeBSD.ORG Fri Nov 19 08:39: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 9D0A016A4CE for ; Fri, 19 Nov 2004 08:39:02 +0000 (GMT) Received: from vbook.fbsd.ru (asplinux.ru [195.133.213.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id CFFD343D55 for ; Fri, 19 Nov 2004 08:39:01 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.43 (FreeBSD)) id 1CUuV8-000PGb-NE for net@freebsd.org; Fri, 19 Nov 2004 01:11:38 +0300 From: Vladimir Grebenschikov To: freebsd-net Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: SWsoft Date: Fri, 19 Nov 2004 01:11:38 +0300 Message-Id: <1100815898.1347.21.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.0FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov Subject: PPTP connection over another PPTP connection 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, 19 Nov 2004 08:39:02 -0000 Hi Does anybody knows Is subject possible with mpd ? I have tried both single mpd with two links and two mpd on different machines - no luck. Looks like one mpd does not allows receiving GRE packets inside its traffic. I see only following packets on internal link (that inside another link) [sw] LCP: Up event [sw] LCP: state change Starting --> Req-Sent [sw] LCP: phase shift DEAD --> ESTABLISH [sw] LCP: SendConfigReq #199 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM d0599088 MP MRRU 1600 MP SHORTSEQ ENDPOINTDISC [802.1] 00 0e 35 03 82 74 [sw] LCP: SendConfigReq #200 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM d0599088 MP MRRU 1600 MP SHORTSEQ ENDPOINTDISC [802.1] 00 0e 35 03 82 74 [sw] LCP: SendConfigReq #201 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM d0599088 MP MRRU 1600 MP SHORTSEQ ENDPOINTDISC [802.1] 00 0e 35 03 82 74 [sw] LCP: SendConfigReq #202 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM d0599088 MP MRRU 1600 MP SHORTSEQ ENDPOINTDISC [802.1] 00 0e 35 03 82 74 [sw] LCP: SendConfigReq #203 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM d0599088 MP MRRU 1600 MP SHORTSEQ ENDPOINTDISC [802.1] 00 0e 35 03 82 74 Also by tcpdump I see outgoing packets but didn't see incoming. Any ideas ? -- Vladimir B. Grebenschikov SWsoft Inc. vova@sw-soft.com From owner-freebsd-net@FreeBSD.ORG Fri Nov 19 12:02:48 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 D189816A4CE; Fri, 19 Nov 2004 12:02:48 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB25843D49; Fri, 19 Nov 2004 12:02:48 +0000 (GMT) (envelope-from arved@FreeBSD.org) Received: from freefall.freebsd.org (arved@localhost [127.0.0.1]) iAJC2muK062602; Fri, 19 Nov 2004 12:02:48 GMT (envelope-from arved@freefall.freebsd.org) Received: (from arved@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id iAJC2met062598; Fri, 19 Nov 2004 12:02:48 GMT (envelope-from arved) Date: Fri, 19 Nov 2004 12:02:48 GMT From: Tilman Linneweh Message-Id: <200411191202.iAJC2met062598@freefall.freebsd.org> To: arved@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@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, 19 Nov 2004 12:02:49 -0000 Synopsis: [patch] TCP should honour incoming RSTs even if the receive window is closed Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: arved Responsible-Changed-When: Fri Nov 19 12:02:29 GMT 2004 Responsible-Changed-Why: over to freebsd-net mailinglist for review http://www.freebsd.org/cgi/query-pr.cgi?pr=72502 From owner-freebsd-net@FreeBSD.ORG Fri Nov 19 14: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 488ED16A4CE for ; Fri, 19 Nov 2004 14:02:41 +0000 (GMT) Received: from smtp-3.hut.fi (smtp-3.hut.fi [130.233.228.93]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6416B43D31 for ; Fri, 19 Nov 2004 14:02:40 +0000 (GMT) (envelope-from efagerho@kosh.hut.fi) Received: from localhost (katosiko.hut.fi [130.233.228.115]) by smtp-3.hut.fi (8.12.10/8.12.10) with ESMTP id iAJE2dM5031977 for ; Fri, 19 Nov 2004 16:02:39 +0200 Received: from smtp-3.hut.fi ([130.233.228.93]) by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) with LMTP id 15275-05 for ; Fri, 19 Nov 2004 16:02:38 +0200 (EET) Received: from kosh.hut.fi (kosh.hut.fi [130.233.228.10]) by smtp-3.hut.fi (8.12.10/8.12.10) with ESMTP id iAJE2bKm031968 for ; Fri, 19 Nov 2004 16:02:37 +0200 Received: (from efagerho@localhost) by kosh.hut.fi (8.12.10/8.12.9/Submit) id iAJE2aiI312254 for freebsd-net@freebsd.org; Fri, 19 Nov 2004 16:02:36 +0200 (EET) Date: Fri, 19 Nov 2004 16:02:35 +0200 From: Edvard Fagerholm To: freebsd-net@freebsd.org Message-ID: <20041119140235.GA274917@cc.hut.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on katosiko.hut.fi X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi Subject: Forcing packets out from both NICs on same subnet with 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: Fri, 19 Nov 2004 14:02:41 -0000 Hello! Could anyone try to explain what happens in the kernel when a packet is forced to the outbound queue of a NIC with pf using the route-to keyword? Specifically is IP routing touched in any way after this or is the sending of the packet only depending on ethernet/arp? I'm trying to solve the problem mentioned in my post to freebsd-questions, "Problem routing via two NICs to same subnet". To those who can't find my post on freebsd-questions, I could describe the problem as follows: My roommate and I have both connections through the same ISP. Our ISPs allocate IPs to us from the same subnet with the same gateway. I'd like to have one box route a NATed network, so that his computers would go out through his interface and mine through mine. If we only use one interface, then we only get half the bandwidth. My solution: Force my internal IPs with route-to out from my NIC, while forcing his out from his NIC. After that do nat on the outbound queues of each interface. Problem is that only one of the NICs get the routing table entry for the MAC-address of the gateway, so even though even though pf has put a packet in the outbound queue of the other interface destined to the router, the packet never leaves the firewall. I really don't care how cleanly this can be solved. After reading some kernel source yesterday, I came to the conclusion that it's only possible to store one MAC address/IP address pair. However, I know exactly which interfaces I'm working with, so I could modify the kernel so that fxp0 try to query the arp table for fxp1 and vice verca each time they try to lookup a MAC address. Is this possible to do without breaking too much? :) Any better ideas? I'm not trying to find a generic solution, only a solution that works... Thanks, Edvard From owner-freebsd-net@FreeBSD.ORG Fri Nov 19 17:21: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 7DAAB16A4CE for ; Fri, 19 Nov 2004 17:21:03 +0000 (GMT) Received: from hotmail.com (bay24-f20.bay24.hotmail.com [64.4.18.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 559ED43D45 for ; Fri, 19 Nov 2004 17:21:03 +0000 (GMT) (envelope-from segr@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 19 Nov 2004 09:21:02 -0800 Message-ID: Received: from 198.53.131.3 by by24fd.bay24.hotmail.msn.com with HTTP; Fri, 19 Nov 2004 17:20:50 GMT X-Originating-IP: [198.53.131.3] X-Originating-Email: [segr@hotmail.com] X-Sender: segr@hotmail.com In-Reply-To: <417A82BD.1090100@mac.com> From: "Stephane Raimbault" To: cswiger@mac.com Date: Fri, 19 Nov 2004 10:20:50 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 19 Nov 2004 17:21:02.0515 (UTC) FILETIME=[24EEA830:01C4CE5C] cc: net@freebsd.org Subject: Re: using natd to load balance port 80 to multiple servers 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, 19 Nov 2004 17:21:03 -0000 I finally got around to testing out FreeBSD 5.3 + pf to replace my FreeBSD 4.9 + natd to forward port 80 to multiple backend servers. I see a huge performance diffrence. FreeBSD 5.3 + pf runs about about < 5% where FreeBSD 4.9 + natd was doing the same thing for around 20% cpu. I'm very happy with the performance diffrence. During my testing, I noticed that sometimes traffic going thru pf was locking up if I was doing too many requests from the same IP concurrently. I was running ab from one machine with 50 concurrent and 50000 total requests. It seemed to lock up after hitting 500 requests. so I ran ab from 6 diffrent machines with < 500 requests and my tests revealed positive results. I have put this solution into production, however this problem seems to plague me again, apparently people behind firewalls are running into this problem as multiple users from an office would try to connect to the site. when I look at the pfctl -s state and grep for the IP address of one of these offices or firewall, I never see it go above 250 entries. Is there some sort of limitation or limit I'm reaching that I'm not aware of. Is this an anamoly or a bug? Otherwise it seems like the system is running quite well and I am very pleased. Thank you for your suggestion to pf, Stephane. >From: Chuck Swiger >To: Stephane Raimbault >CC: net@freebsd.org >Subject: Re: using natd to load balance port 80 to multiple servers >Date: Sat, 23 Oct 2004 12:11:41 -0400 > >Stephane Raimbault wrote: >>I'm currently using a freebsd box running natd to forward port 80 to >>several (5) web servers on private IP's. > >OK. > >>I have discovered that natd doesn't handle many requests/second all that >>well (seem to choke at about 200 req/second (educated guess)) > >Let's take that number as being right, although the first consideration >when doing performance tuning is that you need to measure things accurately >enough that you can see whether a change makes a meaningful difference. > >There are plenty of tools available in the ports tree, although you could >start with "ab" from apache. > >Next, you ought to read "man tuning" and look into adjusting HZ, >NMBCLUSTERS in your kernel config, using any hardware support for your NICs >(-link0 option) or try using device polling. > >You should probably investigate the net.inet sysctls, particularly those >controlling retransmit time intervals net.inet.tcp.rexmit_min and the >keepalive and net.inet.ip.fw.dyn*lifetime tunables. > >>There are other packet filtering options on FreeBSD and I wonder if I can >>use them to do what I'm trying to do with natd. > >It's true that natd runs in userspace, which creates more overhead, so >using PF instead might be worth doing, sure. > >>Would someone be able to point me to documentation or help me have either >>ipf/ipfw/pf forward port 80 traffic to private space IP's? > >Consider http://www.openbsd.org/faq/pf/index.html > >>Is there a better way of split port 80 traffic across multiple webservers >>that has elduded me? Other then a comercial content switch that is :) > >Oh, sure. > >The most obvious solution to the problem is to give all of the servers real >IPs and use some other form of balancing (DNS round-robin, or splitting the >content somehow [static vs dynamicly generated?]), and avoid dealing with >NAT altogether. > >-- >-Chuck _________________________________________________________________ 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 Fri Nov 19 18:19:00 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 1E77816A4CE for ; Fri, 19 Nov 2004 18:19:00 +0000 (GMT) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id B453343D41 for ; Fri, 19 Nov 2004 18:18:59 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from [192.168.1.250] (pool-68-161-115-118.ny325.east.verizon.net [68.161.115.118]) by pi.codefab.com (8.12.11/8.12.11) with ESMTP id iAJIIrU8053721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Nov 2004 13:18:55 -0500 (EST) Message-ID: <419E3907.8000904@mac.com> Date: Fri, 19 Nov 2004 13:18:47 -0500 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephane Raimbault References: In-Reply-To: X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.4 required=5.5 tests=AWL,BAYES_00 autolearn=ham version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on pi.codefab.com cc: net@freebsd.org Subject: Re: using natd to load balance port 80 to multiple servers 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, 19 Nov 2004 18:19:00 -0000 Stephane Raimbault wrote: > I finally got around to testing out FreeBSD 5.3 + pf to replace my > FreeBSD 4.9 + natd to forward port 80 to multiple backend servers. I > see a huge performance diffrence. FreeBSD 5.3 + pf runs about about < 5% > where FreeBSD 4.9 + natd was doing the same thing for around 20% cpu. > I'm very happy with the performance diffrence. OK, that's good. > During my testing, I noticed that sometimes traffic going thru pf was > locking up if I was doing too many requests from the same IP concurrently. [ ... ] > when I look at the pfctl -s state and grep for the IP address of one of > these offices or firewall, I never see it go above 250 entries. Is > there some sort of limitation or limit I'm reaching that I'm not aware > of. Is this an anamoly or a bug? I don't know enough about PF to give you advice on tuning it, but no, it is not surprising that you run into anamolies when you put a sufficiently large # of connections through NAT. Re-writing every packet and keeping all of that dynamic state is somewhat expensive in terms of latency and resources, and these expenses grow in proportion to the amount of traffic present. I will repeat my suggestion that you use a real IP on your webserver and switch from doing PF + NAT to doing PF or IPFW + bridging instead. -- -Chuck From owner-freebsd-net@FreeBSD.ORG Fri Nov 19 19:25:53 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 3898C16A4CE for ; Fri, 19 Nov 2004 19:25:53 +0000 (GMT) Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by mx1.FreeBSD.org (Postfix) with SMTP id 8C38143D2F for ; Fri, 19 Nov 2004 19:25:52 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 67598 invoked from network); 19 Nov 2004 19:25:51 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 19 Nov 2004 19:25:51 -0000 X-pair-Authenticated: 209.68.2.70 Date: Fri, 19 Nov 2004 13:25:50 -0600 (CST) From: Mike Silbersack To: freebsd-net@FreeBSD.org In-Reply-To: <200411191202.iAJC2met062598@freefall.freebsd.org> Message-ID: <20041119132016.S57560@odysseus.silby.com> References: <200411191202.iAJC2met062598@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: Michiel Boland 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, 19 Nov 2004 19:25:53 -0000 On Fri, 19 Nov 2004, Tilman Linneweh wrote: > Synopsis: [patch] TCP should honour incoming RSTs even if the receive window is closed > > Responsible-Changed-From-To: freebsd-bugs->freebsd-net > Responsible-Changed-By: arved > Responsible-Changed-When: Fri Nov 19 12:02:29 GMT 2004 > Responsible-Changed-Why: > over to freebsd-net mailinglist for review > > http://www.freebsd.org/cgi/query-pr.cgi?pr=72502 Wow, this bug has probably been the phantom cause of quite a few bug reports over the years - good catch! Sorry that nobody noticed the PR until now, we don't check the PR database that frequently. I love that it comes with a regression test, btw. We'll have to include that in the new regression testbench that was recently added. This should be committed within the next few days, sorry again for the delay. Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Sat Nov 20 01:29: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 7331C16A4CF for ; Sat, 20 Nov 2004 01:29:56 +0000 (GMT) Received: from neo.redjade.org (neo.redjade.org [219.254.21.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2644943D4C for ; Sat, 20 Nov 2004 01:29:55 +0000 (GMT) (envelope-from ssw@neo.redjade.org) Received: from neo.redjade.org (localhost [127.0.0.1]) by neo.redjade.org (8.13.1/8.13.1) with ESMTP id iAK1UHqi069278; Sat, 20 Nov 2004 10:30:17 +0900 (KST) (envelope-from ssw@neo.redjade.org) Received: (from ssw@localhost) by neo.redjade.org (8.13.1/8.13.1/Submit) id iAK1UG08069277; Sat, 20 Nov 2004 10:30:16 +0900 (KST) (envelope-from ssw) Date: Sat, 20 Nov 2004 10:30:16 +0900 From: Sangwoo Shim To: Chuck Swiger Message-ID: <20041120013016.GA69112@neo.redjade.org> References: <419E3907.8000904@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=euc-kr Content-Disposition: inline In-Reply-To: <419E3907.8000904@mac.com> User-Agent: Mutt/1.5.4i cc: net@freebsd.org Subject: Re: using natd to load balance port 80 to multiple servers 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, 20 Nov 2004 01:29:56 -0000 On Fri, Nov 19, 2004 at 01:18:47PM -0500, Chuck Swiger wrote: > > I will repeat my suggestion that you use a real IP on your webserver and > switch from doing PF + NAT to doing PF or IPFW + bridging instead. Is it possible (in -current of RELENG_5) to filter bridged packets using PF? I know I can do with ipfw/ipf by setting net.link.ether.bridge_ipfw=1 or net.link.ether.bridge_ipf=1. But I cannot find net.link.ether.bridge_pf or the like. Regards, Sangwo Shim From owner-freebsd-net@FreeBSD.ORG Sat Nov 20 03:52: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 6F95D16A4CE for ; Sat, 20 Nov 2004 03:52:12 +0000 (GMT) Received: from av4-2-sn3.vrr.skanova.net (av4-2-sn3.vrr.skanova.net [81.228.9.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id F302243D3F for ; Sat, 20 Nov 2004 03:52:10 +0000 (GMT) (envelope-from pawel.worach@telia.com) Received: by av4-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 582FE37F1F; Sat, 20 Nov 2004 04:52:10 +0100 (CET) Received: from smtp1-1-sn3.vrr.skanova.net (smtp1-1-sn3.vrr.skanova.net [81.228.9.177]) by av4-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 3A95D37E45 for ; Sat, 20 Nov 2004 04:52:10 +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 EFD5638003 for ; Sat, 20 Nov 2004 04:52:01 +0100 (CET) Message-ID: <419EBE2E.9080108@telia.com> Date: Sat, 20 Nov 2004 04:46:54 +0100 From: Pawel Worach User-Agent: Mozilla Thunderbird 0.9 (X11/20041110) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: multipart/mixed; boundary="------------000702090106080709040109" X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: 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: Sat, 20 Nov 2004 03:52:12 -0000 This is a multi-part message in MIME format. --------------000702090106080709040109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, 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 says:Nov 20 04:27:35 darkstar kernel: pf: BAD state: TCP 192.168.1.10:20 192.168.1.10:20 192.168.1.200:50640 [lo=3604799807 high=3604800103 win=33304 mod ulator=0 wscale=1] [lo=4089843176 high=4089909784 win=33304 modulator=0 wscale=1 ] 4:4 FPA seq=3604799807 ack=4089843176 len=296 ackskew=0 pkts=2497:1693 dir=out ,fwd Nov 20 04:27:35 darkstar kernel: pf: State failure on: 1 | 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=1373010668 high=1373010980 win=33304 mod ulator=0 wscale=1] [lo=3742879382 high=3742945990 win=33304 modulator=0 wscale=1 ] 4:4 A seq=1373010668 ack=3742879382 len=1448 ackskew=0 pkts=1266:851 dir=out,f wd Nov 20 04:27:40 darkstar kernel: pf: State failure on: 1 | 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=1373010668 high=1373010980 win=33304 mod ulator=0 wscale=1] [lo=3742879382 high=3742945990 win=33304 modulator=0 wscale=1 ] 4:4 A seq=1373010668 ack=3742879382 len=1448 ackskew=0 pkts=1266:851 dir=out,f wd 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) 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 >= 1024 flags S/SA keep state Any ideas? More info? -- Pawel --------------000702090106080709040109--