From owner-freebsd-net@FreeBSD.ORG Sun Nov 9 02:21:54 2003 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 DA63816A4CF for ; Sun, 9 Nov 2003 02:21:54 -0800 (PST) Received: from dastardly.newsbastards.org.72.27.172.IN-addr.ARPA.NOSPAM.dyndns.dk (does-d9b91906.pool.mediaWays.net [217.185.25.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8CE9943FF7 for ; Sun, 9 Nov 2003 02:21:17 -0800 (PST) (envelope-from bounce@NOSPAM.dyndns.dk) Received: from NOSPAM.spam.NOSPAM.spam.NOSPAM.dyndns.dk (NOSPAM.spam.NOSPAM.spam.NOSPAM.dyndns.dk [2002:d9b9:1906:0:200:c0ff:fefc:19aa]) (8.11.6/8.11.6-SPAMMERS-DeLiGHt) with ESMTP id hA9AKtw32251 verified NO); Sun, 9 Nov 2003 11:20:59 +0100 (CET) (envelope-from bounce@NOSPAM.dyndns.dk) Received: (from beer@localhost)hA9AKgm34428; Sun, 9 Nov 2003 11:20:42 +0100 (CET) (envelope-from bounce@NOSPAM.dyndns.dk) Date: Sun, 9 Nov 2003 11:20:42 +0100 (CET) Message-Id: <200311091020.hA9AKgm34428@NOSPAM.spam.NOSPAM.spam.NOSPAM.dyndns.dk> X-Authentication-Warning: NOSPAM.spam.NOSPAM.spam.NOSPAM.dyndns.dk: beer set sender to bounce@NOSPAM.dyndns.dk using -f From: Barry Bouwsma To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= References: <200311021403.hA2E3OE48213@NOSPAM.spam.NOSPAM.spam.NOSPAM.dyndns.dk> cc: FreeBSD Networking Nerds Subject: Re: IPv6 autoconf addresses with changing RAs... 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, 09 Nov 2003 10:21:55 -0000 > > What I want to happen, is that when the new IPv6 address is autoconf'ed, > > the old one should disappear from the interface. (I've been too impatient > Does the following behavior of rtadvd(8) help you? Yes, thank you, Jinmei-san! Excellent! Except, > At least rtadvd contained in FreeBSD 4.8R seem to support this > behavior. which explains why the man page I have says nothing about it, nor would it work like that for me. Because I still have most of a FreeBSD 4.5 userland, although a recent 4.9-RC kernel. :-P But now I have compiled a RELENG_4 version of `rtadvd' and installed it on the router, changed the addresses, and seen exactly what the man page described: On the host, seen after changing an address on the router: ed0: flags=8843 mtu 1500 [snip] inet6 2002:d507:7774:0:200:c0ff:fefc:19aa prefixlen 64 deprecated autoconf inet6 2002:d570:7774:0:200:c0ff:fefc:19aa prefixlen 64 autoconf [I'm offline, but these are the leftover IPv4-based addresses from earlier, and a change to test this feature...] [snip] [17:46:50]root@NOSPAM.spam.NOSPAM.spam.NOSPAM.dyndns.dk:/usr/src/usr.sbin/rtadvd{1490}# ping6 2002:d570:7774:0:220:afff:fed4:dbcb PING6(56=40+8+8 bytes) 2002:d570:7774:0:200:c0ff:fefc:19aa --> 2002:d570:7774:0:220:afff:fed4:dbcb 16 bytes from 2002:d570:7774:0:220:afff:fed4:dbcb, icmp_seq=0 hlim=64 time=607.904 ms This works perfectly, and I think I no longer need to poke `rtadvd' with `rtsol' when I assign the IPv6 address(es) each time. The only thing it seems I must still do by hand, is for the host to determine its IP is changed, and notify the dynamic DNS server of this address, and for that I believe I must still use the cron job which I had hacked to delete the old IPv6 address after detecting a change. That might teach me to update my whole machine, rather than only the parts which break with a new kernel... Or maybe not, I am lazy... Many thanks again! Barry Bouwsma (above e-mail works for IPv6; dropping the hostname part only may make it work on IPv4 or not; dropping it entirely won't hurt either) From owner-freebsd-net@FreeBSD.ORG Sun Nov 9 06:11:35 2003 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 B49E516A4CF for ; Sun, 9 Nov 2003 06:11:35 -0800 (PST) Received: from freesbee.wheel.dk (freesbee.wheel.dk [193.162.159.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE6874400E for ; Sun, 9 Nov 2003 06:11:34 -0800 (PST) (envelope-from jesper@skriver.dk) Received: by freesbee.wheel.dk (Postfix, from userid 1001) id 166A538568; Sun, 9 Nov 2003 15:11:33 +0100 (CET) Date: Sun, 9 Nov 2003 15:11:32 +0100 From: Jesper Skriver To: Harti Brandt Message-ID: <20031109141132.GB32037@FreeBSD.org> References: <20031108100926.M78050@beagle.fokus.fraunhofer.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031108100926.M78050@beagle.fokus.fraunhofer.de> User-Agent: Mutt/1.4.1i X-PGP-Fingerprint: 6B88 9CE8 66E9 E631 C9C5 5EB4 22AB F0EC F956 1C31 X-PGP-Public-Key: http://freesbee.wheel.dk/~jesper/gpgkey.pub cc: "'freebsd-net@freebsd.org'" cc: Alex Hoff Subject: Re: 64 bit packet counters 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, 09 Nov 2003 14:11:35 -0000 On Sat, Nov 08, 2003 at 10:13:48AM +0100, Harti Brandt wrote: > On Fri, 7 Nov 2003, Alex Hoff wrote: > > AH>Hi, > AH> > AH>We are attempting to implement the IF-MIB, which requires the > AH>use of 64 bit packet counters and the differentiation between > AH>multicast and broadcast pkts. Since changing the if_data (by > AH>adding new counters and changing the existing to u_int64) is a bad > AH>idea, does anyone have any good ideas on how to do this? I was > AH>thinking of tacking on a new struct (lets call it ifx_data) on at > AH>the end of the current if_net struct with the appropriate counters > AH>(i/opacket, i/obyte, i/obcast, i/omcast). Apart from having to do > AH>a little double counting is there any obvious pitfals with this > AH>approach? Does anyone have an better ideas? Is there currently any > AH>plans to update the network stack to handle this properly? > > You may lookup the discussions in the mailing lists. As far as > I remember the problem with 64 bit counting was that this needs > locks because not on all architectures you have atomic 64bit add > operations. A simple method that does not involve kernel changes (and > that I plan to implement in my snmp daemon) is to periodically monitor > the counters (depending on the interface speed) and detect wraps in > the daemon. What is done in other places is to have normal 32 bit counters that are incremented per packet, and have a background task/thread to update the 64 bit counters from the 32 bit counters. That way, we avoid the locking issue per packet. /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. From owner-freebsd-net@FreeBSD.ORG Sun Nov 9 08:19:55 2003 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 E1EA916A4CE for ; Sun, 9 Nov 2003 08:19:55 -0800 (PST) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 30BF343FFB for ; Sun, 9 Nov 2003 08:19:52 -0800 (PST) (envelope-from oppermann@pipeline.ch) Received: (qmail 81579 invoked from network); 9 Nov 2003 16:22:38 -0000 Received: from unknown (HELO pipeline.ch) ([195.134.148.7]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 9 Nov 2003 16:22:38 -0000 Message-ID: <3FAE68FB.64D262FF@pipeline.ch> Date: Sun, 09 Nov 2003 17:19:07 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-current@freebsd.org, freebsd-net@freebsd.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: sam@errno.com cc: mb@imp.ch cc: ume@freebsd.org Subject: tcp hostcache and ip fastforward for review 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, 09 Nov 2003 16:19:56 -0000 Hello all, this patch contains three things (to be separated for committing): tcp_hostcache - removes protocol cloning from routing table (IPv4+6) - removes rtentry pointer from inpcb and in6pcb - removes ip route cache in ip_input.c (locking much easier) - removes most (tcp specific) metrics from rtentry metrics - adds a hostcache table which carries the metrics for tcp - works transparently for IPv4 and IPv6 - is designed for concurrent access in SMP environments - significant reduction of routing table size (no cloning anymore) - eases many routing table locking situations in ip/tcp code ip_fastforward - removes ip_flow forwarding code - adds full direct process-to-completion IPv4 forwarding code - handles ip fragmentation incl. hw support (ip_flow did not) - supports ipfw and ipfilter (ip_flow did not) - supports divert and ipfw fwd (ip_flow did not) - drops anything it can't handle back to normal ip_input tcp bug fixes and MSS DoS attack prevention - fixes wrong goto in tcp_input.c which sends two RST packets instead of one - adds tcp_minmss sysctl which limits the lowest MSS we accept during TCP setup and path MTU discovery - adds tcp_minmssoverload which disconnects a TCP session if it receives too many (1000) packets per second whose average segement size is lower than tcp_minmss - DoS attack 1: send very low MSS in syn to remote host, request large data stream (file) and let other host produce maaaany small packets which consumes a lot of CPU - DoS attack 2: make MSS very low on local side of connection and send maaaany small packet to remote host. For every packet (eg. 2 bytes payload) a sowakeup is done to the listening process. Consumes a lot of CPU there. I'm looking for any comments, testing and bug reports (if any ;-). Hajimu-san, I'm looking especially for comments on whether my changes to IPv6 are correct wrt IPv6 concepts. (I hope they are). Hopefully these things can make it into -CURRENT before 5.2 release. Sam Leffler has indicated he is willing to commit it when there are no objections to the implementation and the code. I am fully committed to fix any bugs that might come up after it's in the tree. I am running my machines with these changes for a couple of weeks now without any problems. The attached patch obviously doesn't have that much exposure because I've had to update it all the time to track Sam's locking changes and UME's IPv6 updates. The patch is here (relative to -CURRENT as of 2003-11-09): http://www.nrg4u.com/freebsd/tcphostcache+ipfastforward-20031109.patch I'm grateful for everyone who tries out the patch and reports their success and/or other findings. -- Andre From owner-freebsd-net@FreeBSD.ORG Sun Nov 9 12:59:57 2003 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 3209D16A4CE; Sun, 9 Nov 2003 12:59:57 -0800 (PST) Received: from westhost42.westhost.net (westhost42.westhost.net [216.71.84.238]) by mx1.FreeBSD.org (Postfix) with ESMTP id 21CE143FBD; Sun, 9 Nov 2003 12:59:56 -0800 (PST) (envelope-from mini@freebsd.org) Received: from [10.0.1.20] (12-228-13-123.client.attbi.com [12.228.13.123]) by westhost42.westhost.net (8.11.6/8.11.6) with ESMTP id hA9Kxs727738; Sun, 9 Nov 2003 14:59:54 -0600 In-Reply-To: <3FAE68FB.64D262FF@pipeline.ch> References: <3FAE68FB.64D262FF@pipeline.ch> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jonathan Mini Date: Sun, 9 Nov 2003 12:59:57 -0800 To: Andre Oppermann X-Mailer: Apple Mail (2.606) cc: mb@imp.ch cc: freebsd-current@freebsd.org cc: ume@freebsd.org cc: sam@errno.com cc: freebsd-net@freebsd.org Subject: Re: tcp hostcache and ip fastforward for review 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, 09 Nov 2003 20:59:57 -0000 On Nov 9, 2003, at 8:19 AM, Andre Oppermann wrote: > - DoS attack 2: make MSS very low on local side of connection > and send maaaany small packet to remote host. For every packet > (eg. 2 bytes payload) a sowakeup is done to the listening > process. Consumes a lot of CPU there. > This sounds as if it might be worthwhile to add a delay to the TF_NODELAY case for receive processing as well. -- Jonathan Mini mini@freebsd.org http://www.freebsd.org From owner-freebsd-net@FreeBSD.ORG Sun Nov 9 14:47:11 2003 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 0A20716A4CF for ; Sun, 9 Nov 2003 14:47:11 -0800 (PST) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 29A4743FE0 for ; Sun, 9 Nov 2003 14:47:08 -0800 (PST) (envelope-from oppermann@pipeline.ch) Received: (qmail 7568 invoked from network); 9 Nov 2003 22:49:55 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.54]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 9 Nov 2003 22:49:55 -0000 Message-ID: <3FAEC407.F10E7BA@pipeline.ch> Date: Sun, 09 Nov 2003 23:47:35 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Mini References: <3FAE68FB.64D262FF@pipeline.ch> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: mb@imp.ch cc: freebsd-current@freebsd.org cc: ume@freebsd.org cc: sam@errno.com cc: freebsd-net@freebsd.org Subject: Re: tcp hostcache and ip fastforward for review 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, 09 Nov 2003 22:47:11 -0000 Jonathan Mini wrote: > > On Nov 9, 2003, at 8:19 AM, Andre Oppermann wrote: > > > - DoS attack 2: make MSS very low on local side of connection > > and send maaaany small packet to remote host. For every packet > > (eg. 2 bytes payload) a sowakeup is done to the listening > > process. Consumes a lot of CPU there. > > > > This sounds as if it might be worthwhile to add a delay to > the TF_NODELAY case for receive processing as well. Unfortunatly it is not that easy. We can't just do that unconditionally to all connections. It would probably break or delay many things. You never know how much data is outstanding and whether it's just this packet with 2 bytes outstanding... As an application aware of this problematic you have currently two options: use accept filters (FreeBSD only) or set SO_RCVLOWAT to some higher value than the default 1 byte. Only the first one is workable if you don't know what and how much the clients send to you. Relying on the application to activate any such option to prevent this kind of DoS is unfortunatly whishful thinking. The code I've put in here simply caps off the extreme cases. It counts all packets and bytes in any given second and computes the average payload size per packet. If that is less than we have defined for minmss it will reset and drop the connection. However it will only start to compute the average if there are more than 1'000 packets per second on the same tcp connection. I've chosen this quite high value to never disconnect any ligitimate connection which just happens to send many small packets. In my tests I've seen telnet/ssh sending close to 100 small packets per second (some large copy-pasting and cat'ing of many small files). Probably 500 packets per second is a better cut-off value but I just want to be sure to never hit a false positive. -- Andre From owner-freebsd-net@FreeBSD.ORG Sun Nov 9 15:15:48 2003 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 C3D0516A4CE; Sun, 9 Nov 2003 15:15:48 -0800 (PST) Received: from westhost42.westhost.net (westhost42.westhost.net [216.71.84.238]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7591243FB1; Sun, 9 Nov 2003 15:15:47 -0800 (PST) (envelope-from mini@freebsd.org) Received: from [10.0.1.20] (12-228-13-123.client.attbi.com [12.228.13.123]) by westhost42.westhost.net (8.11.6/8.11.6) with ESMTP id hA9NFjU20868; Sun, 9 Nov 2003 17:15:46 -0600 In-Reply-To: <3FAEC407.F10E7BA@pipeline.ch> References: <3FAE68FB.64D262FF@pipeline.ch> <3FAEC407.F10E7BA@pipeline.ch> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jonathan Mini Date: Sun, 9 Nov 2003 15:15:48 -0800 To: Andre Oppermann X-Mailer: Apple Mail (2.606) cc: mb@imp.ch cc: freebsd-current@freebsd.org cc: ume@freebsd.org cc: sam@errno.com cc: freebsd-net@freebsd.org Subject: Re: tcp hostcache and ip fastforward for review 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, 09 Nov 2003 23:15:49 -0000 On Nov 9, 2003, at 2:47 PM, Andre Oppermann wrote: > Jonathan Mini wrote: >> >> On Nov 9, 2003, at 8:19 AM, Andre Oppermann wrote: >> >>> - DoS attack 2: make MSS very low on local side of connection >>> and send maaaany small packet to remote host. For every packet >>> (eg. 2 bytes payload) a sowakeup is done to the listening >>> process. Consumes a lot of CPU there. >>> >> >> This sounds as if it might be worthwhile to add a delay to >> the TF_NODELAY case for receive processing as well. > > Unfortunatly it is not that easy. We can't just do that unconditionally > to all connections. It would probably break or delay many things. You > never know how much data is outstanding and whether it's just this > packet with 2 bytes outstanding... This would be disastrous to the performance of interactive sockets, however theoretically those connections have NODELAY set. My above comment is a bit confusing: I meant the "non TF_NODELAY" case, that is when Nagling is enabled. In this situation, you would be delay an sowakeup until either a timeout or SO_RCVLOWAT-set value was reached. The normal SO_RCVLOWAT case delays until SO_RCVTIMEO is reached. I suppose the application could simulate this with a large SO_RCVLOWAT and a small SO_RCVTIMEO, but I was wondering about the effects of such a change as part of !TF_NODELAY. Sadly, there's this PSH bit in the TCP header that's completely unreliable and could be used for scenarios like this. > As an application aware of this problematic you have currently two > options: use accept filters (FreeBSD only) or set SO_RCVLOWAT to some > higher value than the default 1 byte. Only the first one is workable > if you don't know what and how much the clients send to you. Relying > on the application to activate any such option to prevent this kind > of DoS is unfortunatly whishful thinking. I was not suggesting that we use this to counter an attack, only asking if it might be a worthwhile performance optimization to consider. This is an unlikely case (many small packets sent to a non-interactive application), so I can't see the improvement as being globally useful. > The code I've put in here simply caps off the extreme cases. It > counts all packets and bytes in any given second and computes the > average payload size per packet. If that is less than we have defined > for minmss it will reset and drop the connection. However it will only > start to compute the average if there are more than 1'000 packets per > second on the same tcp connection. I've chosen this quite high value > to never disconnect any ligitimate connection which just happens to > send many small packets. In my tests I've seen telnet/ssh sending > close to 100 small packets per second (some large copy-pasting and > cat'ing of many small files). Probably 500 packets per second is a > better cut-off value but I just want to be sure to never hit a false > positive. This is actually a small value for TCP connections which are being used to forward messages, especially on gigabit links. Heavily-intensive web applications that are using small HTTP requests (pipelined inside a persistent connection) to update small manipulations of state are a good example of this. I wouldn't be surprised to see chatter between SQL servers follow similar patterns. Applications which use XML-based messaging often send several small packets per message, which is unfortunate. On the other hand, I'm used to looking at proxies, which are not the general case. This is why the limits are tunable, after all. =) -- Jonathan Mini mini@freebsd.org http://www.freebsd.org From owner-freebsd-net@FreeBSD.ORG Sun Nov 9 22:24:49 2003 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 32A1616A4CE for ; Sun, 9 Nov 2003 22:24:49 -0800 (PST) Received: from wrzx35.rz.uni-wuerzburg.de (wrzx35.rz.uni-wuerzburg.de [132.187.3.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C2B543F85 for ; Sun, 9 Nov 2003 22:24:47 -0800 (PST) (envelope-from elessar@galgenberg.net) Received: from wrzx30.rz.uni-wuerzburg.de (wrzx30.rz.uni-wuerzburg.de [132.187.1.30]) by wrzx35.rz.uni-wuerzburg.de (Postfix) with ESMTP id 2A0E674017 for ; Mon, 10 Nov 2003 07:24:46 +0100 (CET) Received: from virusscan (localhost [127.0.0.1]) by wrzx30.rz.uni-wuerzburg.de (Postfix) with ESMTP id 10F081955B for ; Mon, 10 Nov 2003 07:24:46 +0100 (CET) Received: from wrzx28.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by wrzx30.rz.uni-wuerzburg.de (Postfix) with ESMTP id EA1C319181 for ; Mon, 10 Nov 2003 07:24:45 +0100 (CET) Received: from frodo.galgenberg.net (wwsx14.win-screen.uni-wuerzburg.de [132.187.253.14]) by mailmaster.uni-wuerzburg.de (Postfix) with SMTP id B2AAA696D0 for ; Mon, 10 Nov 2003 07:24:45 +0100 (CET) Received: (qmail 52400 invoked from network); 10 Nov 2003 06:24:45 -0000 Received: from gb-22-219.galgenberg.net (HELO aragorn.starkstrom.lan) (172.16.22.219) by frodo.galgenberg.net with SMTP; 10 Nov 2003 06:24:45 -0000 Date: Mon, 10 Nov 2003 07:24:26 +0100 From: Joerg Pernfuss To: freebsd-net@freebsd.org Message-Id: <20031110072426.0607baf4.elessar@galgenberg.net> In-Reply-To: <200311082325.hA8NPIeF062364@gw.catspoiler.org> References: <3FAD6103.1010407@knology.net> <200311082325.hA8NPIeF062364@gw.catspoiler.org> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-portbld-freebsd5.1) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Signature=_Mon__10_Nov_2003_07_24_26_+0100_Ufw_wsPnf4ohFro6" X-Virus-Scanned: by amavisd-new (Rechenzentrum Universitaet Wuerzburg) Subject: Re: problems caused by net.inet.tcp.blackhole=2 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, 10 Nov 2003 06:24:49 -0000 --Signature=_Mon__10_Nov_2003_07_24_26_+0100_Ufw_wsPnf4ohFro6 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit On Sat, 8 Nov 2003 15:25:18 -0800 (PST) Don Lewis wrote: > On 8 Nov, Michal wrote: > > Hello, > > maybe someone will be able to help me with the problem. Namely setting > > net.inet.tcp.blackhole=2 make samba to start very slow (90sec). Also > > smbclient is slow. After samba starts there is no delay to connect from > > the another machine with persistant local problems (smbclient). > > Additionally the sysctl setting has veird impact on mozilla: trying to > > write to web forms causes freezing of mozilla. Now setting > > net.inet.tcp.blackhole=0 reverts all the problemsr: samba starts fast > > and no problems with writing to the web forms. > > my system: > > FreeBSD 5.1-CURRENT #0: Thu Oct 30 17:49:13 EST 2003 > > ports updated 11-08-03 > > > > I appreciate any suggestions > > I looked at a similar problem that someone was having a while back. It > appears that the problem is that this sysctl setting is suppressing the > sending of TCP RST packets which are needed to tear down dead > connections, and if one end of the connection thinks the connection is > still established, it is not possible to create a new connection between > the hosts that reuses the same addresses and ports as the old > connection. > > Since the whole point of net.inet.tcp.blackhole=2 is to block the RST > packets that could allow the host to be scanned, I suspect you are > stuck. That's not a bug, that is the only feature :) First of all, check on which ports the connections that time out occur. One possibility would be `tcpdump', the other is to set the sysctl net.inet.tcp.log_in_vain to 1. Then start samba and look in the logs to which closed ports connection attempts were made. Maybe there is a decent solution to provide these packets the answer they desire so hard. Joerg --Signature=_Mon__10_Nov_2003_07_24_26_+0100_Ufw_wsPnf4ohFro6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/ry8nIrY0CTTJX8ARAtMUAJ94J5C5QO+Ci1+38647/dzHMxZneQCeONwM oaOqrKheBm5rlS/XuDfoAp0= =T1si -----END PGP SIGNATURE----- --Signature=_Mon__10_Nov_2003_07_24_26_+0100_Ufw_wsPnf4ohFro6-- From owner-freebsd-net@FreeBSD.ORG Sun Nov 9 23:11:25 2003 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 E340516A4D0 for ; Sun, 9 Nov 2003 23:11:25 -0800 (PST) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 605FC43F85 for ; Sun, 9 Nov 2003 23:11:23 -0800 (PST) (envelope-from silby@silby.com) Received: (qmail 5486 invoked from network); 10 Nov 2003 07:11:21 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 10 Nov 2003 07:11:21 -0000 X-pair-Authenticated: 209.68.2.70 Date: Mon, 10 Nov 2003 01:11:20 -0600 (CST) From: Mike Silbersack To: Andre Oppermann In-Reply-To: <3FAE68FB.64D262FF@pipeline.ch> Message-ID: <20031110005543.C532@odysseus.silby.com> References: <3FAE68FB.64D262FF@pipeline.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: mb@imp.ch cc: ume@freebsd.org cc: sam@errno.com Subject: Re: tcp hostcache and ip fastforward for review 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, 10 Nov 2003 07:11:26 -0000 On Sun, 9 Nov 2003, Andre Oppermann wrote: > Hello all, > > this patch contains three things (to be separated for committing): I don't have much time free in the next week, so I cannot do a complete review. However, I just did a quick readthrough. > tcp_hostcache This looks good to me, I've been waiting for you to finish it for a long time. You actually missed a point: - Ensures that a cached entry isn't added until the 3WHS is completed. This should help make synfloods with random source addresses less damaging. Would it be possible to provide a way for netstat to view the host cache table? I think that it would be useful. > ip_fastforward No comment, I didn't read through this part, and I'm not familiar with the forwarding code. > tcp bug fixes and MSS DoS attack prevention Generally good, but: > - adds tcp_minmssoverload which disconnects a TCP session if > it receives too many (1000) packets per second whose average > segement size is lower than tcp_minmss > - DoS attack 2: make MSS very low on local side of connection > and send maaaany small packet to remote host. For every packet > (eg. 2 bytes payload) a sowakeup is done to the listening > process. Consumes a lot of CPU there. I don't think that your patch for this really solves anything. Anyone who would write such a program could just as easily make it use concurrent connections, have it auto-reconnect, and/or have it only send 900 packets per second. I think that you should remove this section of the patch, but leave a comment about this problem existing so that it will be thought more about in the future. After the rest of the code is in, we can brainstorm on other possible solutions... I think that Mini's idea of approaching it as an optimization is the correct one. Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Sun Nov 9 23:38:26 2003 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 A10BF16A4CE for ; Sun, 9 Nov 2003 23:38:26 -0800 (PST) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7764F43F3F for ; Sun, 9 Nov 2003 23:38:25 -0800 (PST) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 432B2651F1 for ; Mon, 10 Nov 2003 07:38:24 +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 44958-04-2 for ; Mon, 10 Nov 2003 07:38:24 +0000 (GMT) Received: from saboteur.dek.spc.org (unknown [82.147.19.91]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id BDCE8651EE for ; Mon, 10 Nov 2003 07:38:23 +0000 (GMT) Received: by saboteur.dek.spc.org (Postfix, from userid 1001) id 9F9B437; Mon, 10 Nov 2003 07:38:22 +0000 (GMT) Date: Mon, 10 Nov 2003 07:38:22 +0000 From: Bruce M Simpson To: freebsd-net@freebsd.org Message-ID: <20031110073822.GA20611@saboteur.dek.spc.org> Mail-Followup-To: freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Viewing multicast group membership? 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, 10 Nov 2003 07:38:26 -0000 Hi, Pardon me if this is an FAQ or answered somewhere else. I've had a quick skim through the man pages and the source, and can't seem to find a means of listing which IPv4 multicast groups a host is currently a member of. The net.igmp.stats sysctl only seems to maintain general protocol level statistics; it doesn't contain group information. This is the sysctl reported by 'netstat -g'. I guess I need to write some code to open /dev/kmem and walk ifmultihead. Or does someone have a hack lying around for this I can clean up and commit? BMS From owner-freebsd-net@FreeBSD.ORG Mon Nov 10 00:03:19 2003 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 8290E16A4CE for ; Mon, 10 Nov 2003 00:03:19 -0800 (PST) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81FAA43FAF for ; Mon, 10 Nov 2003 00:03:18 -0800 (PST) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.9p2/8.12.9) with ESMTP id hAA83AeF065509; Mon, 10 Nov 2003 00:03:14 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <200311100803.hAA83AeF065509@gw.catspoiler.org> Date: Mon, 10 Nov 2003 00:03:10 -0800 (PST) From: Don Lewis To: elessar@galgenberg.net In-Reply-To: <20031110072426.0607baf4.elessar@galgenberg.net> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-net@FreeBSD.org Subject: Re: problems caused by net.inet.tcp.blackhole=2 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, 10 Nov 2003 08:03:19 -0000 On 10 Nov, Joerg Pernfuss wrote: > On Sat, 8 Nov 2003 15:25:18 -0800 (PST) > Don Lewis wrote: > >> On 8 Nov, Michal wrote: >> > Hello, >> > maybe someone will be able to help me with the problem. Namely setting >> > net.inet.tcp.blackhole=2 make samba to start very slow (90sec). Also >> > smbclient is slow. After samba starts there is no delay to connect from >> > the another machine with persistant local problems (smbclient). >> > Additionally the sysctl setting has veird impact on mozilla: trying to >> > write to web forms causes freezing of mozilla. Now setting >> > net.inet.tcp.blackhole=0 reverts all the problemsr: samba starts fast >> > and no problems with writing to the web forms. >> > my system: >> > FreeBSD 5.1-CURRENT #0: Thu Oct 30 17:49:13 EST 2003 >> > ports updated 11-08-03 >> > >> > I appreciate any suggestions >> >> I looked at a similar problem that someone was having a while back. It >> appears that the problem is that this sysctl setting is suppressing the >> sending of TCP RST packets which are needed to tear down dead >> connections, and if one end of the connection thinks the connection is >> still established, it is not possible to create a new connection between >> the hosts that reuses the same addresses and ports as the old >> connection. >> >> Since the whole point of net.inet.tcp.blackhole=2 is to block the RST >> packets that could allow the host to be scanned, I suspect you are >> stuck. > > That's not a bug, that is the only feature :) > > First of all, check on which ports the connections that time out occur. > One possibility would be `tcpdump', the other is to set the sysctl > net.inet.tcp.log_in_vain to 1. Then start samba and look in the logs to > which closed ports connection attempts were made. > Maybe there is a decent solution to provide these packets the answer they > desire so hard. You'll probably need to crank net.inet.tcp.log_in_vain all the way up to 2. If you just set it to 1, it won't tell you about packets that don't have the SYN flag set. From owner-freebsd-net@FreeBSD.ORG Mon Nov 10 01:40:13 2003 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 40E7616A4CF for ; Mon, 10 Nov 2003 01:40:13 -0800 (PST) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5ED1543FE1 for ; Mon, 10 Nov 2003 01:40:09 -0800 (PST) (envelope-from oppermann@pipeline.ch) Received: (qmail 61745 invoked from network); 10 Nov 2003 09:42:56 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 10 Nov 2003 09:42:56 -0000 Message-ID: <3FAF5CD9.ADA58CAF@pipeline.ch> Date: Mon, 10 Nov 2003 10:39:37 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Mini References: <3FAE68FB.64D262FF@pipeline.ch> <3FAEC407.F10E7BA@pipeline.ch> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: mb@imp.ch cc: freebsd-current@freebsd.org cc: ume@freebsd.org cc: sam@errno.com cc: freebsd-net@freebsd.org Subject: Re: tcp hostcache and ip fastforward for review 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, 10 Nov 2003 09:40:13 -0000 Jonathan Mini wrote: > > On Nov 9, 2003, at 2:47 PM, Andre Oppermann wrote: > > > Jonathan Mini wrote: > >> > >> On Nov 9, 2003, at 8:19 AM, Andre Oppermann wrote: > >> > >>> - DoS attack 2: make MSS very low on local side of connection > >>> and send maaaany small packet to remote host. For every packet > >>> (eg. 2 bytes payload) a sowakeup is done to the listening > >>> process. Consumes a lot of CPU there. > >>> > >> > >> This sounds as if it might be worthwhile to add a delay to > >> the TF_NODELAY case for receive processing as well. > > > > Unfortunatly it is not that easy. We can't just do that unconditionally > > to all connections. It would probably break or delay many things. You > > never know how much data is outstanding and whether it's just this > > packet with 2 bytes outstanding... > > This would be disastrous to the performance of interactive > sockets, however theoretically those connections have > NODELAY set. My above comment is a bit confusing: I meant the > "non TF_NODELAY" case, that is when Nagling is enabled. > > In this situation, you would be delay an sowakeup until > either a timeout or SO_RCVLOWAT-set value was reached. The normal > SO_RCVLOWAT case delays until SO_RCVTIMEO is reached. I suppose > the application could simulate this with a large SO_RCVLOWAT and a > small SO_RCVTIMEO, but I was wondering about the effects of such a > change as part of !TF_NODELAY. To do this we need another callout to do the eventual wakeup if no further packet arrive within whatever/HZ. In addition it probably would make FreeBSD look bad in network benchmarks since this causes the connection RTT to go up. All in all I don't think it is worth adding this complexity. > Sadly, there's this PSH bit in the TCP header that's completely > unreliable and could be used for scenarios like this. > > > As an application aware of this problematic you have currently two > > options: use accept filters (FreeBSD only) or set SO_RCVLOWAT to some > > higher value than the default 1 byte. Only the first one is workable > > if you don't know what and how much the clients send to you. Relying > > on the application to activate any such option to prevent this kind > > of DoS is unfortunatly whishful thinking. > > I was not suggesting that we use this to counter an attack, only asking > if it might be a worthwhile performance optimization to consider. > This is an unlikely case (many small packets sent to a non-interactive > application), so I can't see the improvement as being globally useful. No, I don't think it is a worthwhile opimization. If the application wants to do it, it can do so already via socket options. Normally an application needs such a delay feature to be specific to it's message types. Like with http accept filter. > > The code I've put in here simply caps off the extreme cases. It > > counts all packets and bytes in any given second and computes the > > average payload size per packet. If that is less than we have defined > > for minmss it will reset and drop the connection. However it will only > > start to compute the average if there are more than 1'000 packets per > > second on the same tcp connection. I've chosen this quite high value > > to never disconnect any ligitimate connection which just happens to > > send many small packets. In my tests I've seen telnet/ssh sending > > close to 100 small packets per second (some large copy-pasting and > > cat'ing of many small files). Probably 500 packets per second is a > > better cut-off value but I just want to be sure to never hit a false > > positive. > > This is actually a small value for TCP connections which are being > used to forward messages, especially on gigabit links. > Heavily-intensive > web applications that are using small HTTP requests (pipelined inside a > persistent connection) to update small manipulations of state are > a good example of this. I wouldn't be surprised to see chatter > between SQL servers follow similar patterns. Applications which > use XML-based messaging often send several small packets per message, > which is unfortunate. Do you think such applications manage to send 1000 packets per second with less than 256 bytes payload per packet? I think the network code would collect some data to form a larger packet (unless TCP_NODELAY set)? > On the other hand, I'm used to looking at proxies, which are not > the general case. This is why the limits are tunable, after all. =) Is there way you could monitor such connections and compile some statistics how many small packets per second are sent? I could adjust the patch to just report the fact instead of dropping the connection. Could do it for 4.9-R too, it's fairly easy. -- Andre From owner-freebsd-net@FreeBSD.ORG Mon Nov 10 02:05:20 2003 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 83B9216A4CF for ; Mon, 10 Nov 2003 02:05:20 -0800 (PST) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 608B443FAF for ; Mon, 10 Nov 2003 02:05:17 -0800 (PST) (envelope-from oppermann@pipeline.ch) Received: (qmail 67221 invoked from network); 10 Nov 2003 10:08:05 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 10 Nov 2003 10:08:05 -0000 Message-ID: <3FAF62BE.BEA1B3EE@pipeline.ch> Date: Mon, 10 Nov 2003 11:04:46 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mike Silbersack References: <3FAE68FB.64D262FF@pipeline.ch> <20031110005543.C532@odysseus.silby.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: mb@imp.ch cc: ume@freebsd.org cc: sam@errno.com Subject: Re: tcp hostcache and ip fastforward for review 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, 10 Nov 2003 10:05:20 -0000 Mike Silbersack wrote: > > On Sun, 9 Nov 2003, Andre Oppermann wrote: > > > Hello all, > > > > this patch contains three things (to be separated for committing): > > I don't have much time free in the next week, so I cannot do a complete > review. However, I just did a quick readthrough. > > > tcp_hostcache > > This looks good to me, I've been waiting for you to finish it for a long > time. You actually missed a point: > > - Ensures that a cached entry isn't added until the 3WHS is completed. > > This should help make synfloods with random source addresses less > damaging. The cache will only be updated if the tcp connection is being closed. All updates are done in tcp_drop. The T/TCP updates have to be done inline during connection setup. I've converted all places which updated the T/TCP rtmetrics in routing table with updates to the hostcache. > Would it be possible to provide a way for netstat to view the host cache > table? I think that it would be useful. At the moment is visible via "sysctl -a net.inet.tcp.hostcache.list". Syncache ain't visible via netstat either. So far you had to use route get x.x.x.x to see the rtmetrics for a (host-)route. So I'm sure whether netstat is the right place for it. But I can do that in a second step. > > ip_fastforward > > No comment, I didn't read through this part, and I'm not familiar with > the forwarding code. > > > tcp bug fixes and MSS DoS attack prevention > > Generally good, but: > > > - adds tcp_minmssoverload which disconnects a TCP session if > > it receives too many (1000) packets per second whose average > > segement size is lower than tcp_minmss > > - DoS attack 2: make MSS very low on local side of connection > > and send maaaany small packet to remote host. For every packet > > (eg. 2 bytes payload) a sowakeup is done to the listening > > process. Consumes a lot of CPU there. > > I don't think that your patch for this really solves anything. Anyone who > would write such a program could just as easily make it use concurrent > connections, have it auto-reconnect, and/or have it only send 900 packets > per second. I think that you should remove this section of the patch, but > leave a comment about this problem existing so that it will be thought > more about in the future. The actually solves the problem. Let me explain in more detail. When we get so many small packets per second the CPU will become pretty saturated. Depending on how much data is sent it can go on for minutes or hours. This code jumps in there and disconnects the within a second. Of course someone can immediatly reconnect and do it again. But that needs the 3WHS again and gives some delay. In the end this code is like the ICMP rate limiter code. It there to migitate a problem to manageable level, not to make it go away. > After the rest of the code is in, we can brainstorm on other possible > solutions... I think that Mini's idea of approaching it as an optimization > is the correct one. Ok, for brainstorming. For Mini's idea see my answer to him. -- Andre From owner-freebsd-net@FreeBSD.ORG Mon Nov 10 02:41:56 2003 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 05BD816A4CE; Mon, 10 Nov 2003 02:41:56 -0800 (PST) Received: from westhost42.westhost.net (westhost42.westhost.net [216.71.84.238]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB2B443FA3; Mon, 10 Nov 2003 02:41:54 -0800 (PST) (envelope-from mini@freebsd.org) Received: from [172.16.0.241] (mulder.f5.com [205.229.151.150]) by westhost42.westhost.net (8.11.6/8.11.6) with ESMTP id hAAAfrl27235; Mon, 10 Nov 2003 04:41:53 -0600 In-Reply-To: <3FAF5CD9.ADA58CAF@pipeline.ch> References: <3FAE68FB.64D262FF@pipeline.ch> <3FAEC407.F10E7BA@pipeline.ch> <3FAF5CD9.ADA58CAF@pipeline.ch> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <823BFED0-136A-11D8-87D8-000A95CD3CF8@freebsd.org> Content-Transfer-Encoding: 7bit From: Jonathan Mini Date: Mon, 10 Nov 2003 02:41:57 -0800 To: Andre Oppermann X-Mailer: Apple Mail (2.606) cc: mb@imp.ch cc: freebsd-current@freebsd.org cc: ume@freebsd.org cc: sam@errno.com cc: freebsd-net@freebsd.org Subject: Re: tcp hostcache and ip fastforward for review 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, 10 Nov 2003 10:41:56 -0000 On Nov 10, 2003, at 1:39 AM, Andre Oppermann wrote: > Jonathan Mini wrote: > > All in all I don't think it is worth adding this complexity. I agree. >> This is actually a small value for TCP connections which are being >> used to forward messages, especially on gigabit links. >> Heavily-intensive >> web applications that are using small HTTP requests (pipelined inside >> a >> persistent connection) to update small manipulations of state are >> a good example of this. I wouldn't be surprised to see chatter >> between SQL servers follow similar patterns. Applications which >> use XML-based messaging often send several small packets per message, >> which is unfortunate. > > Do you think such applications manage to send 1000 packets per second > with less than 256 bytes payload per packet? I think the network code > would collect some data to form a larger packet (unless TCP_NODELAY > set)? Traffic like that only happens when TCP_NODELAY is set. Otherwise, you get what you would expect. >> On the other hand, I'm used to looking at proxies, which are not >> the general case. This is why the limits are tunable, after all. =) > > Is there way you could monitor such connections and compile some > statistics how many small packets per second are sent? I could adjust > the patch to just report the fact instead of dropping the connection. > Could do it for 4.9-R too, it's fairly easy. Alas, no. This is from anecdotal experience from our support staff at work. -- Jonathan Mini mini@freebsd.org http://www.freebsd.org From owner-freebsd-net@FreeBSD.ORG Mon Nov 10 05:58:59 2003 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 ABA7516A4CE for ; Mon, 10 Nov 2003 05:58:59 -0800 (PST) Received: from famine.e-raist.com (69-30-69-105.dq1mn.easystreet.com [69.30.69.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8723A43FE5 for ; Mon, 10 Nov 2003 05:58:57 -0800 (PST) (envelope-from aburke@nullplusone.com) Received: from thebe (12-224-164-145.client.attbi.com [12.224.164.145]) (authenticated bits=0) by famine.e-raist.com (8.12.8/8.12.8) with ESMTP id hAADwnfL036964; Mon, 10 Nov 2003 05:58:52 -0800 (PST) From: "Aaron Burke" To: <"."@babolo.ru>, Date: Mon, 10 Nov 2003 05:57:43 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <1068252022.523087.89843.nullmailer@cicuta.babolo.ru> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RE: Routing With Two ISPs? 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, 10 Nov 2003 13:58:59 -0000 > Subject: Re: Routing With Two ISPs? > > > [ Charset windows-1252 unsupported, converting... ] > > I have a 4.8 box serving as a gateway with two connections to the > > Internet. Is there some way to set the box up so that packets are > > routed out through the same interface from which they arrived? For > > example, if a connection is initiated on port 80 from a packet arriving > > on one interface, is there a way to make the outgoing packets from my > > web server use that same interface as a gateway instead of the default > > interface? > > > > Any suggestions appreciated. > It's easy IMHO Its not too difficult to set up and get running. I also have two ISP's (Cable Modem and DSL). If I understand what your asking, its similar to my situation. Because I run natd on both interfaces, I had to do a little poking around until I finally got everything working correctly. One of my ip addresses is provided via DHCP, the other is static. First off, in /etc/services copy the natd line and rename it natd2, change the port number to 8669 as well. (eg ..) natd 8668/divert # Network Address Translation natd2 8669/divert # Network Address Translation Second, I created a scripts that run natd on both ethernet cards and set them as executable. europa# more /usr/local/etc/rc.d/dc0-natd.sh #!/bin/sh if [ $# -eq 0 -o x$1 = xstart ]; then /sbin/natd -p natd -s -u -f /etc/natd.conf -n dc0 && echo -n ' natd started on dc0' cp /var/run/natd.pid /var/run/natd.dc0.pid fi if [ x$1 = xstop ]; then if [ -f /var/run/natd.dc0.pid ]; then kill `cat /var/run/natd.dc0.pid` fi fi europa# more /usr/local/etc/rc.d/ed0-natd.sh #!/bin/sh if [ $# -eq 0 -o x$1 = xstart ]; then /sbin/natd -p natd2 -s -u -f /etc/natd.conf -n ed0 && echo -n ' natd started on ed0' cp /var/run/natd.pid /var/run/natd.ed0.pid fi if [ x$1 = xstop ]; then if [ -f /var/run/natd.ed0.pid ]; then kill `cat /var/run/natd.ed0.pid` fi fi Then I commented out the natd lines in /etc/rc.conf for natd, because I am running it from these other scripts instead. I would run it from rc.conf, but I would have needed to hack up some other rc.files to get that working. A seperate script requred less code. At this point both networks work, and they can both be used as the default gateway. I also suggest adding mappings to the default gateway on both ISP's to /etc/hosts . This will save most people a small head ache. Next up, my DSL provider has given me a subnet mask of 255.255.255.224. However, he owns the entire class C address space. So to save myself a bit of time, I added a static route to his Class C in /etc/rc.conf . (in /etc/rc.conf) static_routes="dsl" route_dsl=" -net x.y.172 x.y.172.104 255.255.255.0" And finally, if you are running a firewall, you need to make sure that you have divert rules in place for both natd interfaces. In my case I use (dc0 = Cable, ed0 = DSL): ipfw add 00100 divert 8668 ip from any to any via dc0 ipfw add 00101 divert 8669 ip from any to any via ed0 > Each external iface with it's own natd, > each forwards 80 port incoming to two > http servers with different IP or port. Just remember, natd needs to run on seperate ports. And you can tell natd which port to use with the -p arguement. > > outgoing traffic can be forwarded to appropriate > natd via ipfw rules depending on src IP or port Yes, several people also divert certain types of traffic out specific interfaces using Firewall rules. My situation doesnt really require this, but several people can share there examples. Hope this is what you were asking for. And with any luck, I have not forgotten to mention anything. If it isnt working for you, feel free to get in touch with me via aburke@nullplusone.com. From owner-freebsd-net@FreeBSD.ORG Mon Nov 10 08:45:35 2003 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 5A24716A4CE; Mon, 10 Nov 2003 08:45:35 -0800 (PST) Received: from cheer.mahoroba.org (flets19-018.kamome.or.jp [218.45.19.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 80A5B43F75; Mon, 10 Nov 2003 08:45:28 -0800 (PST) (envelope-from ume@mahoroba.org) Received: from lyrics.mahoroba.org (IDENT:l6ynzkgnYr+W7R/c9IsOn8PKn0xkVeda5ewI3ogt1HOR4DqngT5BWy1ULjsmybb7@lyrics.mahoroba.org [IPv6:3ffe:501:185b:8010:280:88ff:fe03:4841]) (user=ume mech=CRAM-MD5 bits=0)hAAGiREU067618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Nov 2003 01:44:30 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Tue, 11 Nov 2003 01:44:27 +0900 Message-ID: From: Hajimu UMEMOTO To: Andre Oppermann In-Reply-To: <3FAE68FB.64D262FF@pipeline.ch> References: <3FAE68FB.64D262FF@pipeline.ch> User-Agent: xcite1.38> Wanderlust/2.11.3 (Wonderwall) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (=?ISO-2022-JP?B?GyRCOC1MWhsoQg==?=) X-Operating-System: FreeBSD 5.1-CURRENT MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on cheer.mahoroba.org cc: mb@imp.ch cc: freebsd-current@freebsd.org cc: ume@freebsd.org cc: sam@errno.com cc: freebsd-net@freebsd.org Subject: Re: tcp hostcache and ip fastforward for review 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, 10 Nov 2003 16:45:35 -0000 Hi, >>>>> On Sun, 09 Nov 2003 17:19:07 +0100 >>>>> Andre Oppermann said: oppermann> Hajimu-san, I'm looking especially for comments on whether my changes oppermann> to IPv6 are correct wrt IPv6 concepts. (I hope they are). I don't see the patch in detail, yet, it seems your change will affect KAME's development. You should ask core@kame.net for review your patch in detail before committing into FreeBSD. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@bisd.hitachi.co.jp ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-net@FreeBSD.ORG Mon Nov 10 10:16:48 2003 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 F38D116A4CE for ; Mon, 10 Nov 2003 10:16:47 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id E73B643F93 for ; Mon, 10 Nov 2003 10:16:46 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.9p2/8.12.9) with ESMTP id hAAIExMg059497; Mon, 10 Nov 2003 13:15:00 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)hAAIExqT059494; Mon, 10 Nov 2003 13:14:59 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Mon, 10 Nov 2003 13:14:59 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Bruce M Simpson In-Reply-To: <20031110073822.GA20611@saboteur.dek.spc.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: Viewing multicast group membership? 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, 10 Nov 2003 18:16:48 -0000 On Mon, 10 Nov 2003, Bruce M Simpson wrote: > Pardon me if this is an FAQ or answered somewhere else. > > I've had a quick skim through the man pages and the source, and can't > seem to find a means of listing which IPv4 multicast groups a host is > currently a member of. > > The net.igmp.stats sysctl only seems to maintain general protocol level > statistics; it doesn't contain group information. This is the sysctl > reported by 'netstat -g'. > > I guess I need to write some code to open /dev/kmem and walk > ifmultihead. Or does someone have a hack lying around for this I can > clean up and commit? I can't speak to existing code for this, but I can say I have a preference for having a sysctl version of the code available in the vague hopes that someday we can drop the setgid kmem bit from netstat... Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories From owner-freebsd-net@FreeBSD.ORG Mon Nov 10 11:01:45 2003 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 0A20816A4CE for ; Mon, 10 Nov 2003 11:01:45 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 69B3B43FAF for ; Mon, 10 Nov 2003 11:01:44 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id hAAJ1iFY050537 for ; Mon, 10 Nov 2003 11:01:44 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id hAAJ1hq4050531 for freebsd-net@freebsd.org; Mon, 10 Nov 2003 11:01:43 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 10 Nov 2003 11:01:43 -0800 (PST) Message-Id: <200311101901.hAAJ1hq4050531@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, 10 Nov 2003 19:01:45 -0000 Current FreeBSD problem reports Critical problems Serious problems Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2002/05/04] kern/37761 net process exits but socket is still ESTABLI 1 problem total. From owner-freebsd-net@FreeBSD.ORG Mon Nov 10 11:03:42 2003 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 D584B16A4CF for ; Mon, 10 Nov 2003 11:03:42 -0800 (PST) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id D090643FAF for ; Mon, 10 Nov 2003 11:03:33 -0800 (PST) (envelope-from oppermann@pipeline.ch) Received: (qmail 60626 invoked from network); 10 Nov 2003 19:06:22 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 10 Nov 2003 19:06:22 -0000 Message-ID: <3FAFE0E5.743F815A@pipeline.ch> Date: Mon, 10 Nov 2003 20:03:01 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Hajimu UMEMOTO References: <3FAE68FB.64D262FF@pipeline.ch> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: mb@imp.ch cc: freebsd-current@freebsd.org cc: ume@freebsd.org cc: sam@errno.com cc: freebsd-net@freebsd.org Subject: Re: tcp hostcache and ip fastforward for review 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, 10 Nov 2003 19:03:43 -0000 Hajimu UMEMOTO wrote: > > Hi, > > >>>>> On Sun, 09 Nov 2003 17:19:07 +0100 > >>>>> Andre Oppermann said: > > oppermann> Hajimu-san, I'm looking especially for comments on whether my changes > oppermann> to IPv6 are correct wrt IPv6 concepts. (I hope they are). > > I don't see the patch in detail, yet, it seems your change will affect > KAME's development. You should ask core@kame.net for review your > patch in detail before committing into FreeBSD. Ok, I've written an email core@kame.net. However there is not very much time for them to respond before 5.2 code freeze. I've taken care in my changes not to break IPv6 and to be only minimal intrusive. -- Andre From owner-freebsd-net@FreeBSD.ORG Mon Nov 10 11:11:45 2003 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 11ED216A4CE for ; Mon, 10 Nov 2003 11:11:45 -0800 (PST) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF81843FCB for ; Mon, 10 Nov 2003 11:11:43 -0800 (PST) (envelope-from oppermann@pipeline.ch) Received: (qmail 61307 invoked from network); 10 Nov 2003 19:14:32 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 10 Nov 2003 19:14:32 -0000 Message-ID: <3FAFE2D0.F2FC77D7@pipeline.ch> Date: Mon, 10 Nov 2003 20:11:12 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@FreeBSD.org References: <200311101901.hAAJ1hq4050531@freefall.freebsd.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: 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, 10 Nov 2003 19:11:45 -0000 FreeBSD bugmaster wrote: > > Current FreeBSD problem reports > Critical problems > Serious problems > Non-critical problems > > S Submitted Tracker Resp. Description > ------------------------------------------------------------------------------- > o [2002/05/04] kern/37761 net process exits but socket is still ESTABLI > > 1 problem total. What is going on with this? It comes up every other week. -- Andre From owner-freebsd-net@FreeBSD.ORG Mon Nov 10 11:14:58 2003 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 B688116A4D5; Mon, 10 Nov 2003 11:14:58 -0800 (PST) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 720A843FB1; Mon, 10 Nov 2003 11:14:57 -0800 (PST) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 44FD165478; Mon, 10 Nov 2003 19:14:56 +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 50213-06-5; Mon, 10 Nov 2003 19:14:55 +0000 (GMT) Received: from saboteur.dek.spc.org (unknown [82.147.19.91]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 7BFF865449; Mon, 10 Nov 2003 19:14:55 +0000 (GMT) Received: by saboteur.dek.spc.org (Postfix, from userid 1001) id A907C44; Mon, 10 Nov 2003 19:14:54 +0000 (GMT) Date: Mon, 10 Nov 2003 19:14:54 +0000 From: Bruce M Simpson To: Robert Watson Message-ID: <20031110191454.GC662@saboteur.dek.spc.org> Mail-Followup-To: Robert Watson , freebsd-net@freebsd.org References: <20031110073822.GA20611@saboteur.dek.spc.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tKW2IUtsqtDRztdT" Content-Disposition: inline In-Reply-To: cc: freebsd-net@freebsd.org Subject: Re: Viewing multicast group membership? 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, 10 Nov 2003 19:14:58 -0000 --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Nov 10, 2003 at 01:14:59PM -0500, Robert Watson wrote: > I can't speak to existing code for this, but I can say I have a preference > for having a sysctl version of the code available in the vague hopes that > someday we can drop the setgid kmem bit from netstat... During operation, the kernel routing socket will report multicast group joins/leaves using RTM_NEWMADDR/RTM_DELADDR messages. These contain an ifma_msghdr structure, which encapsulates multicast addresses in an address family independent manner. However, there is no mechanism to report currently existing associations. Maybe the way to go is to extend getifaddrs(), or create a new API a lot like it. Right now, it uses the NET_RT_IFLIST sysctl to retrieve the interface list; the kernel appends RTM_NEWADDR messages to the buffer contents returned by the sysctl to report each address family. The function sysctl_iflist() in net/rtsock.c is responsible for this. However, not all getifaddrs() consumers are likely to be interested in multicast associations, so this could end up adding bloat. The getifaddrs() libc function and sysctl_iflist() kernel code do not touch ifnet->if_multiaddrs at all. So my next question is: Do I create a new API function and sysctl, or integrate into the existing code path? BMS --tKW2IUtsqtDRztdT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Comment: '' iD8DBQE/r+OtueUpAYYNtTsRAtVmAJ47SuDA9kUxnPSIYiPWY5RRPV+dHgCgrRJA uYDx/jIVpXksVWceB5DjvPc= =7AAL -----END PGP SIGNATURE----- --tKW2IUtsqtDRztdT-- From owner-freebsd-net@FreeBSD.ORG Mon Nov 10 11:26:53 2003 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 6390A16A4CF for ; Mon, 10 Nov 2003 11:26:53 -0800 (PST) Received: from silver.he.iki.fi (helenius.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 890A543FA3 for ; Mon, 10 Nov 2003 11:26:51 -0800 (PST) (envelope-from pete@he.iki.fi) Received: from he.iki.fi (localhost [127.0.0.1]) by silver.he.iki.fi (8.12.9p2/8.11.4) with ESMTP id hAAJQmgr003629 for ; Mon, 10 Nov 2003 21:26:48 +0200 (EET) (envelope-from pete@he.iki.fi) Message-ID: <3FAFE65E.6030907@he.iki.fi> Date: Mon, 10 Nov 2003 21:26:22 +0200 From: Petri Helenius User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: libpcap again 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, 10 Nov 2003 19:26:53 -0000 (I might sound like a broken record, but...) Any chance of libpcap vendor import before 5.2 release? Pete From owner-freebsd-net@FreeBSD.ORG Mon Nov 10 11:31:28 2003 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 6617816A4CF for ; Mon, 10 Nov 2003 11:31:28 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C92443F85 for ; Mon, 10 Nov 2003 11:31:27 -0800 (PST) (envelope-from max@love2party.net) Received: from [212.227.126.208] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1AJHkx-0000dw-00; Mon, 10 Nov 2003 20:31:23 +0100 Received: from [80.131.145.25] (helo=max2400) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1AJHkx-0002Rm-00; Mon, 10 Nov 2003 20:31:23 +0100 Date: Mon, 10 Nov 2003 20:31:30 +0100 From: Max Laier X-Mailer: The Bat! (v2.00) UNREG / CD5BF9353B3B7091 Organization: n/a X-Priority: 3 (Normal) Message-ID: <7328230093.20031110203130@love2party.net> To: Andre Oppermann In-Reply-To: <3FAFE2D0.F2FC77D7@pipeline.ch> References: <200311101901.hAAJ1hq4050531@freefall.freebsd.org> <3FAFE2D0.F2FC77D7@pipeline.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@FreeBSD.org Subject: Re[2]: Current problem reports assigned to you X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Max Laier List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2003 19:31:28 -0000 Monday, November 10, 2003, 8:11:12 PM, you wrote: AO> FreeBSD bugmaster wrote: >> >> Current FreeBSD problem reports >> Critical problems >> Serious problems >> Non-critical problems >> >> S Submitted Tracker Resp. Description >> ------------------------------------------------------------------------------- >> o [2002/05/04] kern/37761 net process exits but socket is still ESTABLI >> >> 1 problem total. AO> What is going on with this? It comes up every other week. Kris wrote: "Assign to net mailing list for evaluation" when he changed resp. Seems no-one ever reads it (or uses this emacs thingy). Take a look: http://www.freebsd.org/cgi/query-pr.cgi?pr=37761 and "evaluate" -- Best regards, Max mailto:max@love2party.net From owner-freebsd-net@FreeBSD.ORG Mon Nov 10 11:35:57 2003 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 BA0F916A4CE for ; Mon, 10 Nov 2003 11:35:57 -0800 (PST) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6660443FAF for ; Mon, 10 Nov 2003 11:35:56 -0800 (PST) (envelope-from oppermann@pipeline.ch) Received: (qmail 63372 invoked from network); 10 Nov 2003 19:38:45 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 10 Nov 2003 19:38:45 -0000 Message-ID: <3FAFE87D.EF380E7C@pipeline.ch> Date: Mon, 10 Nov 2003 20:35:25 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Max Laier References: <200311101901.hAAJ1hq4050531@freefall.freebsd.org> <7328230093.20031110203130@love2party.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@FreeBSD.org Subject: Re: 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, 10 Nov 2003 19:35:57 -0000 Max Laier wrote: > > Monday, November 10, 2003, 8:11:12 PM, you wrote: > AO> FreeBSD bugmaster wrote: > >> > >> Current FreeBSD problem reports > >> Critical problems > >> Serious problems > >> Non-critical problems > >> > >> S Submitted Tracker Resp. Description > >> ------------------------------------------------------------------------------- > >> o [2002/05/04] kern/37761 net process exits but socket is still ESTABLI > >> > >> 1 problem total. > > AO> What is going on with this? It comes up every other week. > > Kris wrote: > "Assign to net mailing list for evaluation" when he changed resp. > > Seems no-one ever reads it (or uses this emacs thingy). Take a look: > http://www.freebsd.org/cgi/query-pr.cgi?pr=37761 and "evaluate" Neither do I have this emacs thing (and I don't want to install it). Anyway, this bug sounds like a fork cleanup problem. Process forks child. child opens socket. childs goes away without closing socket. Partent goes away too, and socket stays around as zombie. But how to reproduce... Maybe I will look into it a bit more but no promises. -- Andre From owner-freebsd-net@FreeBSD.ORG Mon Nov 10 11:45:55 2003 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 AACDD16A4CE for ; Mon, 10 Nov 2003 11:45:55 -0800 (PST) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id ED06643FE3 for ; Mon, 10 Nov 2003 11:45:51 -0800 (PST) (envelope-from silby@silby.com) Received: (qmail 30559 invoked from network); 10 Nov 2003 19:45:50 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 10 Nov 2003 19:45:50 -0000 X-pair-Authenticated: 209.68.2.70 Date: Mon, 10 Nov 2003 13:45:48 -0600 (CST) From: Mike Silbersack To: Andre Oppermann In-Reply-To: <3FAF62BE.BEA1B3EE@pipeline.ch> Message-ID: <20031110133307.R1101@odysseus.silby.com> References: <3FAE68FB.64D262FF@pipeline.ch> <20031110005543.C532@odysseus.silby.com> <3FAF62BE.BEA1B3EE@pipeline.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: mb@imp.ch cc: ume@freebsd.org cc: sam@errno.com Subject: Re: tcp hostcache and ip fastforward for review 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, 10 Nov 2003 19:45:55 -0000 On Mon, 10 Nov 2003, Andre Oppermann wrote: > > - Ensures that a cached entry isn't added until the 3WHS is completed. > > > > This should help make synfloods with random source addresses less > > damaging. > > The cache will only be updated if the tcp connection is being closed. > All updates are done in tcp_drop. The T/TCP updates have to be done > inline during connection setup. I've converted all places which > updated the T/TCP rtmetrics in routing table with updates to the > hostcache. Good, that's exactly how it should work. > > Would it be possible to provide a way for netstat to view the host cache > > table? I think that it would be useful. > > At the moment is visible via "sysctl -a net.inet.tcp.hostcache.list". > Syncache ain't visible via netstat either. So far you had to use > route get x.x.x.x to see the rtmetrics for a (host-)route. So I'm > sure whether netstat is the right place for it. But I can do that > in a second step. Ok, that should be good enough for now. > The actually solves the problem. Let me explain in more detail. When > we get so many small packets per second the CPU will become pretty > saturated. Depending on how much data is sent it can go on for minutes > or hours. This code jumps in there and disconnects the within a second. > Of course someone can immediatly reconnect and do it again. But that > needs the 3WHS again and gives some delay. In the end this code is > like the ICMP rate limiter code. It there to migitate a problem to > manageable level, not to make it go away. Ok, so the problem is that the sockbuf chain keeps getting longer, causing the delay to grow as more fragments pile in... I see now. I drop my objection to it. Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Mon Nov 10 11:49:43 2003 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 3ABCB16A4CE; Mon, 10 Nov 2003 11:49:43 -0800 (PST) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8874743F75; Mon, 10 Nov 2003 11:49:41 -0800 (PST) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])hAAJneU00916; Mon, 10 Nov 2003 20:49:40 +0100 (MET) Date: Mon, 10 Nov 2003 20:49:40 +0100 (CET) From: Harti Brandt To: Bruce M Simpson In-Reply-To: <20031110191454.GC662@saboteur.dek.spc.org> Message-ID: <20031110204652.A84670@beagle.fokus.fraunhofer.de> References: <20031110073822.GA20611@saboteur.dek.spc.org> <20031110191454.GC662@saboteur.dek.spc.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org cc: Robert Watson Subject: Re: Viewing multicast group membership? 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, 10 Nov 2003 19:49:43 -0000 On Mon, 10 Nov 2003, Bruce M Simpson wrote: BMS>On Mon, Nov 10, 2003 at 01:14:59PM -0500, Robert Watson wrote: BMS>> I can't speak to existing code for this, but I can say I have a preference BMS>> for having a sysctl version of the code available in the vague hopes that BMS>> someday we can drop the setgid kmem bit from netstat... BMS> BMS>During operation, the kernel routing socket will report multicast group BMS>joins/leaves using RTM_NEWMADDR/RTM_DELADDR messages. These contain an BMS>ifma_msghdr structure, which encapsulates multicast addresses in an address BMS>family independent manner. However, there is no mechanism to report currently BMS>existing associations. BMS> BMS>Maybe the way to go is to extend getifaddrs(), or create a new API BMS>a lot like it. Right now, it uses the NET_RT_IFLIST sysctl to retrieve BMS>the interface list; the kernel appends RTM_NEWADDR messages to the BMS>buffer contents returned by the sysctl to report each address family. BMS>The function sysctl_iflist() in net/rtsock.c is responsible for this. BMS> BMS>However, not all getifaddrs() consumers are likely to be interested in BMS>multicast associations, so this could end up adding bloat. The getifaddrs() BMS>libc function and sysctl_iflist() kernel code do not touch BMS>ifnet->if_multiaddrs at all. BMS> BMS>So my next question is: Do I create a new API function and sysctl, or BMS>integrate into the existing code path? I have a patch that creates a sysctl that returns the per-interface multicast address lists that mimics the sysctl that returns the interface address lists. If you can wait until tomorrow I'll send you the patch. This is running for more than two years on all my machines. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org From owner-freebsd-net@FreeBSD.ORG Mon Nov 10 12:03:54 2003 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 E79FF16A4CE; Mon, 10 Nov 2003 12:03:54 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id E877C43F85; Mon, 10 Nov 2003 12:03:51 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.9p2/8.12.9) with ESMTP id hAAK27Mg060804; Mon, 10 Nov 2003 15:02:07 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)hAAK27kk060801; Mon, 10 Nov 2003 15:02:07 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Mon, 10 Nov 2003 15:02:07 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Andre Oppermann In-Reply-To: <3FAFE2D0.F2FC77D7@pipeline.ch> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@FreeBSD.org cc: fenner@FreeBSD.org Subject: Re: 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, 10 Nov 2003 20:03:55 -0000 On Mon, 10 Nov 2003, Andre Oppermann wrote: > FreeBSD bugmaster wrote: > > > > Current FreeBSD problem reports > > Critical problems > > Serious problems > > Non-critical problems > > > > S Submitted Tracker Resp. Description > > ------------------------------------------------------------------------------- > > o [2002/05/04] kern/37761 net process exits but socket is still ESTABLI > > > > 1 problem total. > > What is going on with this? It comes up every other week. freebsd-net has been set as the owner for the PR, and gnats will send a weekly reminder e-mail that the problem report is still open until such time as it gets closed (or suspended, I suspect). Sometimes when a specific owner for a problem hasn't been found, or is considered undesured, mailing lists are assigned ownership of PRs (i.e., threads@, et al). Speaking of dangling PRs, and since we're talking generally about multicast, does anyone know if we're going to make progress on kern/58359? It sounded like this change did get picked up by Apple, but I haven't checked to see if it was picked up by other *BSD as well. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories From owner-freebsd-net@FreeBSD.ORG Mon Nov 10 12:15:39 2003 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 35D0C16A4CE; Mon, 10 Nov 2003 12:15:39 -0800 (PST) Received: from mailman.research.att.com (H-135-207-24-32.research.att.com [135.207.24.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B1A243FBD; Mon, 10 Nov 2003 12:15:38 -0800 (PST) (envelope-from fenner@research.att.com) Received: from unixmail.research.att.com (unixmail.research.att.com [135.207.26.71])hAAL8VuF012893; Mon, 10 Nov 2003 16:08:31 -0500 Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46])hAAKD2Zn016549; Mon, 10 Nov 2003 15:13:02 -0500 (EST) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id hAAKFa809083; Mon, 10 Nov 2003 12:15:36 -0800 (PST) Message-Id: <200311102015.hAAKFa809083@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rwatson@FreeBSD.org Date: Mon, 10 Nov 2003 12:15:35 -0800 Versions: dmail (solaris) 2.5a/makemail 2.9d cc: freebsd-net@FreeBSD.org Subject: Re: 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, 10 Nov 2003 20:15:39 -0000 I have been too busy over the last couple of weeks. I have no problem with the multicast filtering API change actually happening, and if someone who actually has time wants to commit it that'd be fine with me. Bill From owner-freebsd-net@FreeBSD.ORG Mon Nov 10 12:15:57 2003 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 DBB5116A4CE; Mon, 10 Nov 2003 12:15:57 -0800 (PST) Received: from ussenterprise.ufp.org (ussenterprise.ufp.org [208.185.30.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1472143F93; Mon, 10 Nov 2003 12:15:56 -0800 (PST) (envelope-from bicknell@ussenterprise.ufp.org) Received: from ussenterprise.ufp.org (bicknell@localhost [127.0.0.1]) by ussenterprise.ufp.org (8.12.9/8.12.9) with ESMTP id hAAKFt8i003701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Nov 2003 15:15:55 -0500 (EST) Received: (from bicknell@localhost) by ussenterprise.ufp.org (8.12.9/8.12.9/Submit) id hAAKFqH7003700; Mon, 10 Nov 2003 15:15:52 -0500 (EST) Date: Mon, 10 Nov 2003 15:15:52 -0500 From: Leo Bicknell To: Mike Silbersack Message-ID: <20031110201552.GA3148@ussenterprise.ufp.org> Mail-Followup-To: Mike Silbersack , Andre Oppermann , freebsd-net@freebsd.org, freebsd-current@freebsd.org, mb@imp.ch, ume@freebsd.org, sam@errno.com References: <3FAE68FB.64D262FF@pipeline.ch> <20031110005543.C532@odysseus.silby.com> <3FAF62BE.BEA1B3EE@pipeline.ch> <20031110133307.R1101@odysseus.silby.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YZ5djTAD1cGYuMQK" Content-Disposition: inline In-Reply-To: <20031110133307.R1101@odysseus.silby.com> Organization: United Federation of Planets X-PGP-Key: http://www.ufp.org/~bicknell/ cc: mb@imp.ch cc: freebsd-current@freebsd.org cc: ume@freebsd.org cc: sam@errno.com cc: freebsd-net@freebsd.org Subject: Re: tcp hostcache and ip fastforward for review 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, 10 Nov 2003 20:15:58 -0000 --YZ5djTAD1cGYuMQK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In a message written on Mon, Nov 10, 2003 at 01:45:48PM -0600, Mike Silbers= ack wrote: > > At the moment is visible via "sysctl -a net.inet.tcp.hostcache.list". > > Syncache ain't visible via netstat either. So far you had to use > > route get x.x.x.x to see the rtmetrics for a (host-)route. So I'm > > sure whether netstat is the right place for it. But I can do that > > in a second step. >=20 > Ok, that should be good enough for now. I'm not going to say it's not good enough, but more than once the whole "route get" thing has been quite inconveniant, so I'll put in a big vote that both be available in easy to get table form from some command line utility (netstat seems like a good place). --=20 Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org --YZ5djTAD1cGYuMQK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE/r/H4Nh6mMG5yMTYRAjMXAJwNWp3urXL4WURTIk8Yrps++yIkvACfb6yS 1XlKdJtg5pBFczc59On+4TY= =Bgwr -----END PGP SIGNATURE----- --YZ5djTAD1cGYuMQK-- From owner-freebsd-net@FreeBSD.ORG Mon Nov 10 12:29:59 2003 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 8051D16A4D0 for ; Mon, 10 Nov 2003 12:29:59 -0800 (PST) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id C526043FAF for ; Mon, 10 Nov 2003 12:29:55 -0800 (PST) (envelope-from oppermann@pipeline.ch) Received: (qmail 67716 invoked from network); 10 Nov 2003 20:32:44 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 10 Nov 2003 20:32:44 -0000 Message-ID: <3FAFF523.C3FF55F3@pipeline.ch> Date: Mon, 10 Nov 2003 21:29:23 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Leo Bicknell References: <3FAE68FB.64D262FF@pipeline.ch> <20031110005543.C532@odysseus.silby.com> <3FAF62BE.BEA1B3EE@pipeline.ch> <20031110133307.R1101@odysseus.silby.com> <20031110201552.GA3148@ussenterprise.ufp.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: mb@imp.ch cc: freebsd-current@freebsd.org cc: ume@freebsd.org cc: sam@errno.com cc: freebsd-net@freebsd.org Subject: Re: tcp hostcache and ip fastforward for review 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, 10 Nov 2003 20:29:59 -0000 Leo Bicknell wrote: > > In a message written on Mon, Nov 10, 2003 at 01:45:48PM -0600, Mike Silbersack wrote: > > > At the moment is visible via "sysctl -a net.inet.tcp.hostcache.list". > > > Syncache ain't visible via netstat either. So far you had to use > > > route get x.x.x.x to see the rtmetrics for a (host-)route. So I'm > > > sure whether netstat is the right place for it. But I can do that > > > in a second step. > > > > Ok, that should be good enough for now. > > I'm not going to say it's not good enough, but more than once the whole > "route get" thing has been quite inconveniant, so I'll put in a big vote > that both be available in easy to get table form from some command line > utility (netstat seems like a good place). I'll look into that when 5.2 is in code freeze. Can then put it in afterwards. -- Andre From owner-freebsd-net@FreeBSD.ORG Mon Nov 10 12:51:07 2003 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 07BD016A4CE; Mon, 10 Nov 2003 12:51:07 -0800 (PST) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id E5EDE43FDD; Mon, 10 Nov 2003 12:51:05 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id hAAKp4Da022717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK CN=khavrinen.lcs.mit.edu issuer=SSL+20Client+20CA); Mon, 10 Nov 2003 15:51:04 -0500 (EST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.9/8.12.9/Submit) id hAAKp3aN022714; Mon, 10 Nov 2003 15:51:03 -0500 (EST) (envelope-from wollman) Date: Mon, 10 Nov 2003 15:51:03 -0500 (EST) From: Garrett Wollman Message-Id: <200311102051.hAAKp3aN022714@khavrinen.lcs.mit.edu> To: Bruce M Simpson In-Reply-To: <20031110191454.GC662@saboteur.dek.spc.org> References: <20031110073822.GA20611@saboteur.dek.spc.org> <20031110191454.GC662@saboteur.dek.spc.org> X-Spam-Score: -19.8 () IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES X-Scanned-By: MIMEDefang 2.37 cc: freebsd-net@freebsd.org cc: Robert Watson Subject: Re: Viewing multicast group membership? 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, 10 Nov 2003 20:51:07 -0000 < said: > a lot like it. Right now, it uses the NET_RT_IFLIST sysctl to retrieve > the interface list; the kernel appends RTM_NEWADDR messages to the > buffer contents returned by the sysctl to report each address family. > The function sysctl_iflist() in net/rtsock.c is responsible for this. The plan was to create a parallel NET_RT_IFMLIST which returns this information. -GAWollman From owner-freebsd-net@FreeBSD.ORG Mon Nov 10 13:41:13 2003 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 23C4016A4CE for ; Mon, 10 Nov 2003 13:41:13 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.136.123]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D3EC43FDF for ; Mon, 10 Nov 2003 13:41:12 -0800 (PST) (envelope-from jrh@it.uc3m.es) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id C2D01258 for ; Mon, 10 Nov 2003 22:41:09 +0100 (CET) Received: from cimborrio (cimborrio.it.uc3m.es [163.117.139.95]) by smtp03.uc3m.es (Postfix) with ESMTP id 9351123F for ; Mon, 10 Nov 2003 22:41:09 +0100 (CET) From: Juan Rodriguez Hervella Organization: UC3M To: freebsd-net@freebsd.org Date: Mon, 10 Nov 2003 22:41:02 +0100 User-Agent: KMail/1.5.4 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200311102241.03871.jrh@it.uc3m.es> Subject: ip6fw problem, ignores "icmptypes 8" (icmp-request) 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, 10 Nov 2003 21:41:13 -0000 Hello: I'm trying to block IPv6 icmp-request packets which might be sent to my host. I'm using ip6fw on a FreeBSD-4.9.0-RELEASE. When I do this: add 100 deny ipv6-icmp from any to 2001:720:410:100f:20d:9dff:fe46:f2c9 icmptypes 8 Nothing seems to happen. I still can ping6 my host from a remote machine. Could someone else try this ? I think that "icmptypes" isn't working although it's on the man page of ip6fw. Any suggestion will be appreciated. Bye! -- ****** JFRH ****** For a good time, call (510) 642-9483 From owner-freebsd-net@FreeBSD.ORG Mon Nov 10 14:11:48 2003 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 5FEFC16A4CE; Mon, 10 Nov 2003 14:11:48 -0800 (PST) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5906A43FE5; Mon, 10 Nov 2003 14:11:42 -0800 (PST) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 93D25654A2; Mon, 10 Nov 2003 22:11:41 +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 52095-02-18; Mon, 10 Nov 2003 22:11:41 +0000 (GMT) Received: from saboteur.dek.spc.org (unknown [82.147.19.91]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id C0B4E65492; Mon, 10 Nov 2003 22:11:40 +0000 (GMT) Received: by saboteur.dek.spc.org (Postfix, from userid 1001) id AE42344; Mon, 10 Nov 2003 22:11:39 +0000 (GMT) Date: Mon, 10 Nov 2003 22:11:39 +0000 From: Bruce M Simpson To: Harti Brandt Message-ID: <20031110221139.GB2441@saboteur.dek.spc.org> Mail-Followup-To: Harti Brandt , Robert Watson , freebsd-net@freebsd.org References: <20031110073822.GA20611@saboteur.dek.spc.org> <20031110191454.GC662@saboteur.dek.spc.org> <20031110204652.A84670@beagle.fokus.fraunhofer.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031110204652.A84670@beagle.fokus.fraunhofer.de> cc: freebsd-net@freebsd.org cc: Robert Watson Subject: Re: Viewing multicast group membership? 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, 10 Nov 2003 22:11:48 -0000 On Mon, Nov 10, 2003 at 08:49:40PM +0100, Harti Brandt wrote: > I have a patch that creates a sysctl that returns the per-interface > multicast address lists that mimics the sysctl that returns the interface > address lists. If you can wait until tomorrow I'll send you the patch. > This is running for more than two years on all my machines. Sounds like what I was planning to do anyway. Ok, look forward to it. :^) BMS From owner-freebsd-net@FreeBSD.ORG Mon Nov 10 15:36:47 2003 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 964E616A4CE for ; Mon, 10 Nov 2003 15:36:47 -0800 (PST) Received: from sophia.inria.fr (sophia.inria.fr [138.96.64.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B94343FCB for ; Mon, 10 Nov 2003 15:36:46 -0800 (PST) (envelope-from Hitoshi.Asaeda@sophia.inria.fr) Received: from localhost (odie.inria.fr [138.96.88.52]) by sophia.inria.fr (8.12.10/8.12.9) with ESMTP id hAANaiKL010904; Tue, 11 Nov 2003 00:36:44 +0100 Date: Tue, 11 Nov 2003 00:36:44 +0100 (MET) Message-Id: <20031111.003644.74740537.Hitoshi.Asaeda@sophia.inria.fr> To: bms@spc.org From: Hitoshi Asaeda In-Reply-To: <20031110221139.GB2441@saboteur.dek.spc.org> References: <20031110191454.GC662@saboteur.dek.spc.org> <20031110204652.A84670@beagle.fokus.fraunhofer.de> <20031110221139.GB2441@saboteur.dek.spc.org> X-Mailer: Mew version 2.2rc1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: Viewing multicast group membership? 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, 10 Nov 2003 23:36:47 -0000 ifmcstat delievered by KAME is not sufficient? http://www.kame.net/dev/cvsweb2.cgi/kame/kame/kame/ifmcstat/ -- Hitoshi Asaeda p.s. it can also show (S,G) info if your kernel supports IGMPv3/MLDv2. From owner-freebsd-net@FreeBSD.ORG Mon Nov 10 16:11:39 2003 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 24A2E16A4CE for ; Mon, 10 Nov 2003 16:11:39 -0800 (PST) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC71943FBD for ; Mon, 10 Nov 2003 16:11:37 -0800 (PST) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 87CB865292; Tue, 11 Nov 2003 00:11:36 +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 53304-02-4; Tue, 11 Nov 2003 00:11:36 +0000 (GMT) Received: from saboteur.dek.spc.org (unknown [82.147.19.91]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id AF42865218; Tue, 11 Nov 2003 00:11:35 +0000 (GMT) Received: by saboteur.dek.spc.org (Postfix, from userid 1001) id D76911F; Tue, 11 Nov 2003 00:11:34 +0000 (GMT) Date: Tue, 11 Nov 2003 00:11:34 +0000 From: Bruce M Simpson To: Hitoshi Asaeda Message-ID: <20031111001134.GB16760@saboteur.dek.spc.org> Mail-Followup-To: Hitoshi Asaeda , freebsd-net@freebsd.org References: <20031110191454.GC662@saboteur.dek.spc.org> <20031110204652.A84670@beagle.fokus.fraunhofer.de> <20031110221139.GB2441@saboteur.dek.spc.org> <20031111.003644.74740537.Hitoshi.Asaeda@sophia.inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031111.003644.74740537.Hitoshi.Asaeda@sophia.inria.fr> cc: freebsd-net@freebsd.org Subject: Re: Viewing multicast group membership? 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, 11 Nov 2003 00:11:39 -0000 On Tue, Nov 11, 2003 at 12:36:44AM +0100, Hitoshi Asaeda wrote: > ifmcstat delievered by KAME is not sufficient? > http://www.kame.net/dev/cvsweb2.cgi/kame/kame/kame/ifmcstat/ ifmcstat only appears to report IPv6 group memberships. However, reading its manpage prompted me to try netstat -ina -- this does what I originally wanted. Thank you. However, I still think that Harti's patch is worth looking at, as expecting client programs other than netstat(1) to cough up the incantations found in intpr() on demand is too much -- there is also the fact that it relies upon being setgid kmem to discover these properties, and less of that is definitely a good thing. Regards, BMS From owner-freebsd-net@FreeBSD.ORG Mon Nov 10 20:37:56 2003 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 62F0A16A4CF for ; Mon, 10 Nov 2003 20:37:56 -0800 (PST) Received: from cheer.mahoroba.org (flets19-018.kamome.or.jp [218.45.19.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2AB9E43FBD for ; Mon, 10 Nov 2003 20:37:51 -0800 (PST) (envelope-from ume@mahoroba.org) Received: from lyrics.mahoroba.org (IDENT:hh42mMPLRbo6a3dU88QnNau0nGpemVwyp/iC9sOBE6mEDGWa3vdNOqwZoEUpuuyq@lyrics.mahoroba.org [IPv6:3ffe:501:185b:8010:280:88ff:fe03:4841]) (user=ume mech=CRAM-MD5 bits=0)hAB4atEU086128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Nov 2003 13:36:59 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Tue, 11 Nov 2003 13:36:55 +0900 Message-ID: From: Hajimu UMEMOTO To: Juan Rodriguez Hervella In-Reply-To: <200311102241.03871.jrh@it.uc3m.es> References: <200311102241.03871.jrh@it.uc3m.es> User-Agent: xcite1.38> Wanderlust/2.11.3 (Wonderwall) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (=?ISO-2022-JP?B?GyRCOC1MWhsoQg==?=) X-Operating-System: FreeBSD 5.1-CURRENT MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on cheer.mahoroba.org cc: freebsd-net@freebsd.org Subject: Re: ip6fw problem, ignores "icmptypes 8" (icmp-request) 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, 11 Nov 2003 04:37:56 -0000 Hi, >>>>> On Mon, 10 Nov 2003 22:41:02 +0100 >>>>> Juan Rodriguez Hervella said: jrh> I'm trying to block IPv6 icmp-request packets which might be sent jrh> to my host. I'm using ip6fw on a FreeBSD-4.9.0-RELEASE. jrh> When I do this: jrh> add 100 deny ipv6-icmp from any to 2001:720:410:100f:20d:9dff:fe46:f2c9 jrh> icmptypes 8 ICMPv6 is not same as ICMPv4. ICMP6_ECHO_REQUEST is 128. Please refer /usr/include/netinet/icmp6.h. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@bisd.hitachi.co.jp ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-net@FreeBSD.ORG Mon Nov 10 22:24:29 2003 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 DC91416A4CE for ; Mon, 10 Nov 2003 22:24:29 -0800 (PST) Received: from swin.edu.au (c3p0.cc.swin.edu.au [136.186.1.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6316D43FDF for ; Mon, 10 Nov 2003 22:24:28 -0800 (PST) (envelope-from pvandenbergen@swin.edu.au) Received: from pvdbergen.caia.swin.edu.au (pvdbergen.caia.swin.edu.au [136.186.229.26]) by swin.edu.au (8.9.3p2-20030918/8.9.3) with ESMTP id RAA885151 for ; Tue, 11 Nov 2003 17:24:27 +1100 (EST) From: paul van den bergen To: freebsd-net@freebsd.org Date: Tue, 11 Nov 2003 17:24:22 +1100 User-Agent: KMail/1.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200311111724.22552.pvandenbergen@swin.edu.au> Subject: Wifi discovery for FreeBSD/aironet 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, 11 Nov 2003 06:24:30 -0000 Hi all, I'm setting up a wifi network testbed atm with both prism II and aironet cards. It'd be real nice if there was a utility similar to bsd-airtools dstumbler for the aironet cards (an0) for FreeBSD... any suggestions? OR.... is it that the aironet cards do not have XXXYYYZZZ functionality that allows them to go into promiscuous mode or what ever??? -- Dr Paul van den Bergen Centre for Advanced Internet Architectures caia.swin.edu.au pvandenbergen@swin.edu.au IM:bulwynkl2002 "And some run up hill and down dale, knapping the chucky stones to pieces wi' hammers, like so many road makers run daft. They say it is to see how the world was made." Sir Walter Scott, St. Ronan's Well 1824 From owner-freebsd-net@FreeBSD.ORG Mon Nov 10 22:36:27 2003 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 D621D16A4CF for ; Mon, 10 Nov 2003 22:36:27 -0800 (PST) Received: from web10004.mail.yahoo.com (web10004.mail.yahoo.com [216.136.130.40]) by mx1.FreeBSD.org (Postfix) with SMTP id 5341F43F85 for ; Mon, 10 Nov 2003 22:36:27 -0800 (PST) (envelope-from oldpopsong@yahoo.com) Message-ID: <20031111063627.45765.qmail@web10004.mail.yahoo.com> Received: from [218.244.38.34] by web10004.mail.yahoo.com via HTTP; Tue, 11 Nov 2003 14:36:27 CST Date: Tue, 11 Nov 2003 14:36:27 +0800 (CST) From: =?gb2312?q?popsong=20old?= To: oppermann@pipeline.ch MIME-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit cc: freebsd-net@freebsd.org Subject: Re: tcp hostcache and ip fastforward for review 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, 11 Nov 2003 06:36:28 -0000 > ip_fastforward > - removes ip_flow forwarding code > - adds full direct process-to-completion IPv4 forwarding code > - handles ip fragmentation incl. hw support (ip_flow did not) > - supports ipfw and ipfilter (ip_flow did not) > - supports divert and ipfw fwd (ip_flow did not) > - drops anything it can't handle back to normal ip_input Should we worry about the locking in IPFilter? It seems that there are no locking at all in IPFilter for FreeBSD. BTW, we'll get even better performance if we keep both interfaces' MAC addresses in cache (and call ifp->if_start directly). This requires to keep ethernet header in mbuf untouched and is only relevant in ethernet though. I implemented such layer 2 cache in a local version of IPFilter and got some good results. Regards, song _________________________________________________________ Do You Yahoo!? ÑÅ»¢µçÓÊ£ºÔ¶À벡¶¾¡¢À¬»øÀ§ÈÅ£¡ http://cn.rd.yahoo.com/mail_cn/tag/?http://cn.mail.yahoo.com From owner-freebsd-net@FreeBSD.ORG Tue Nov 11 00:29:52 2003 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 2FA7216A4CE; Tue, 11 Nov 2003 00:29:52 -0800 (PST) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id B10B343FBF; Tue, 11 Nov 2003 00:29:50 -0800 (PST) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])hAB8TnU04447; Tue, 11 Nov 2003 09:29:49 +0100 (MET) Date: Tue, 11 Nov 2003 09:29:49 +0100 (CET) From: Harti Brandt To: Bruce M Simpson In-Reply-To: <20031110221139.GB2441@saboteur.dek.spc.org> Message-ID: <20031111092650.P7611@beagle.fokus.fraunhofer.de> References: <20031110073822.GA20611@saboteur.dek.spc.org> <20031110204652.A84670@beagle.fokus.fraunhofer.de> <20031110221139.GB2441@saboteur.dek.spc.org> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1145545882-1068539389=:7611" cc: freebsd-net@freebsd.org cc: Robert Watson Subject: Re: Viewing multicast group membership? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: harti@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2003 08:29:52 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-1145545882-1068539389=:7611 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 10 Nov 2003, Bruce M Simpson wrote: BMS>On Mon, Nov 10, 2003 at 08:49:40PM +0100, Harti Brandt wrote: BMS>> I have a patch that creates a sysctl that returns the per-interface BMS>> multicast address lists that mimics the sysctl that returns the interface BMS>> address lists. If you can wait until tomorrow I'll send you the patch. BMS>> This is running for more than two years on all my machines. BMS> BMS>Sounds like what I was planning to do anyway. Ok, look forward to it. :^) Here you are. This was even once (about a year ago) reviewed by someone, but did make it into the tree, because I did not insist. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org --0-1145545882-1068539389=:7611 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="rtsock.diff" Content-Transfer-Encoding: BASE64 Content-ID: <20031111092949.A7611@beagle.fokus.fraunhofer.de> Content-Description: Content-Disposition: attachment; filename="rtsock.diff" SW5kZXg6IHN5cy9zb2NrZXQuaA0KPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0K UkNTIGZpbGU6IC9leHBvcnQvY3ZzL2ZyZWVic2Qvc3JjL3N5cy9zeXMvc29j a2V0Lmgsdg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjcyDQpkaWZmIC11IC1y MS43MiBzb2NrZXQuaA0KLS0tIHN5cy9zb2NrZXQuaAk1IE1hciAyMDAzIDE5 OjI0OjI0IC0wMDAwCTEuNzINCisrKyBzeXMvc29ja2V0LmgJMTEgTm92IDIw MDMgMDg6Mjk6MzUgLTAwMDANCkBAIC0zNTEsMTMgKzM1MSwxNSBAQA0KICNk ZWZpbmUgTkVUX1JUX0RVTVAJMQkJLyogZHVtcDsgbWF5IGxpbWl0IHRvIGEu Zi4gKi8NCiAjZGVmaW5lIE5FVF9SVF9GTEFHUwkyCQkvKiBieSBmbGFncywg ZS5nLiBSRVNPTFZJTkcgKi8NCiAjZGVmaW5lIE5FVF9SVF9JRkxJU1QJMwkJ Lyogc3VydmV5IGludGVyZmFjZSBsaXN0ICovDQotI2RlZmluZQlORVRfUlRf TUFYSUQJNA0KKyNkZWZpbmUJTkVUX1JUX0lGTUFMSVNUCTQJCS8qIHJldHVy biBtdWx0aWNhc3QgYWRkcmVzcyBsaXN0ICovDQorI2RlZmluZQlORVRfUlRf TUFYSUQJNQ0KIA0KICNkZWZpbmUgQ1RMX05FVF9SVF9OQU1FUyB7IFwNCiAJ eyAwLCAwIH0sIFwNCiAJeyAiZHVtcCIsIENUTFRZUEVfU1RSVUNUIH0sIFwN CiAJeyAiZmxhZ3MiLCBDVExUWVBFX1NUUlVDVCB9LCBcDQogCXsgImlmbGlz dCIsIENUTFRZUEVfU1RSVUNUIH0sIFwNCisJeyAiaWZtYWxpc3QiLCBDVExU WVBFX1NUUlVDVCB9LCBcDQogfQ0KICNlbmRpZiAvKiBfX0JTRF9WSVNJQkxF ICovDQogDQpJbmRleDogbmV0L3J0c29jay5jDQo9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09DQpSQ1MgZmlsZTogL2V4cG9ydC9jdnMvZnJlZWJzZC9zcmMvc3lz L25ldC9ydHNvY2suYyx2DQpyZXRyaWV2aW5nIHJldmlzaW9uIDEuOTQNCmRp ZmYgLXUgLXIxLjk0IHJ0c29jay5jDQotLS0gbmV0L3J0c29jay5jCTggTm92 IDIwMDMgMjM6MzY6MzAgLTAwMDAJMS45NA0KKysrIG5ldC9ydHNvY2suYwkx MSBOb3YgMjAwMyAwODoyOTozNSAtMDAwMA0KQEAgLTg1LDYgKzg1LDcgQEAN CiBzdGF0aWMgaW50CXJ0X3hhZGRycyhjYWRkcl90LCBjYWRkcl90LCBzdHJ1 Y3QgcnRfYWRkcmluZm8gKik7DQogc3RhdGljIGludAlzeXNjdGxfZHVtcGVu dHJ5KHN0cnVjdCByYWRpeF9ub2RlICpybiwgdm9pZCAqdncpOw0KIHN0YXRp YyBpbnQJc3lzY3RsX2lmbGlzdChpbnQgYWYsIHN0cnVjdCB3YWxrYXJnICp3 KTsNCitzdGF0aWMgaW50CXN5c2N0bF9pZm1hbGlzdChpbnQgYWYsIHN0cnVj dCB3YWxrYXJnICp3KTsNCiBzdGF0aWMgaW50CXJvdXRlX291dHB1dChzdHJ1 Y3QgbWJ1ZiAqLCBzdHJ1Y3Qgc29ja2V0ICopOw0KIHN0YXRpYyB2b2lkCXJ0 X3NldG1ldHJpY3ModV9sb25nLCBzdHJ1Y3QgcnRfbWV0cmljcyAqLCBzdHJ1 Y3QgcnRfbWV0cmljcyAqKTsNCiBzdGF0aWMgdm9pZAlydF9kaXNwYXRjaChz dHJ1Y3QgbWJ1ZiAqLCBzdHJ1Y3Qgc29ja2FkZHIgKik7DQpAQCAtNjg0LDYg KzY4NSwxMCBAQA0KIAkJbGVuID0gc2l6ZW9mKHN0cnVjdCBpZl9tc2doZHIp Ow0KIAkJYnJlYWs7DQogDQorCWNhc2UgUlRNX05FV01BRERSOg0KKwkJbGVu ID0gc2l6ZW9mKHN0cnVjdCBpZm1hX21zZ2hkcik7DQorCQlicmVhazsNCisN CiAJZGVmYXVsdDoNCiAJCWxlbiA9IHNpemVvZihzdHJ1Y3QgcnRfbXNnaGRy KTsNCiAJfQ0KQEAgLTEwMTQsNiArMTAxOSw1OSBAQA0KIAlyZXR1cm4gKGVy cm9yKTsNCiB9DQogDQoraW50DQorc3lzY3RsX2lmbWFsaXN0KGFmLCB3KQ0K KwlpbnQJYWY7DQorCXJlZ2lzdGVyIHN0cnVjdAl3YWxrYXJnICp3Ow0KK3sN CisJcmVnaXN0ZXIgc3RydWN0IGlmbmV0ICppZnA7DQorCXN0cnVjdCBpZm11 bHRpYWRkciAqaWZtYTsNCisJc3RydWN0CXJ0X2FkZHJpbmZvIGluZm87DQor CWludAlsZW4sIGVycm9yID0gMDsNCisNCisJYnplcm8oKGNhZGRyX3QpJmlu Zm8sIHNpemVvZihpbmZvKSk7DQorCS8qIElGTkVUX1JMT0NLKCk7ICovCQkv KiBjb3VsZCBzbGVlcCBYWFggKi8NCisJVEFJTFFfRk9SRUFDSChpZnAsICZp Zm5ldCwgaWZfbGluaykgew0KKwkJaWYgKHctPndfYXJnICYmIHctPndfYXJn ICE9IGlmcC0+aWZfaW5kZXgpDQorCQkJY29udGludWU7DQorCQlUQUlMUV9G T1JFQUNIKGlmbWEsICZpZnAtPmlmX211bHRpYWRkcnMsIGlmbWFfbGluaykg ew0KKwkJCWlmIChhZiAmJiBhZiAhPSBpZm1hLT5pZm1hX2FkZHItPnNhX2Zh bWlseSkNCisJCQkJY29udGludWU7DQorCQkJaWYgKGphaWxlZChjdXJwcm9j LT5wX3VjcmVkKSAmJg0KKwkJCSAgICBwcmlzb25faWYoY3VycHJvYy0+cF91 Y3JlZCwgaWZtYS0+aWZtYV9hZGRyKSkNCisJCQkJY29udGludWU7DQorCQkJ aW5mby5ydGlfaW5mb1tSVEFYX0lGQV0gPSBpZm1hLT5pZm1hX2FkZHI7DQor CQkJaW5mby5ydGlfaW5mb1tSVEFYX0lGUF0gPSBOVUxMOw0KKwkJCWlmIChU QUlMUV9GSVJTVCgmaWZwLT5pZl9hZGRyaGVhZCkpDQorCQkJCWluZm8ucnRp X2luZm9bUlRBWF9JRlBdID0NCisJCQkJICAgIFRBSUxRX0ZJUlNUKCZpZnAt PmlmX2FkZHJoZWFkKS0+aWZhX2FkZHI7DQorDQorCQkJaW5mby5ydGlfaW5m b1tSVEFYX0dBVEVXQVldID0gTlVMTDsNCisJCQlpZiAoaWZtYS0+aWZtYV9h ZGRyLT5zYV9mYW1pbHkgIT0gQUZfTElOSykNCisJCQkJaW5mby5ydGlfaW5m b1tSVEFYX0dBVEVXQVldID0gaWZtYS0+aWZtYV9sbGFkZHI7DQorDQorCQkJ bGVuID0gcnRfbXNnMihSVE1fTkVXTUFERFIsICZpbmZvLCAwLCB3KTsNCisJ CQlpZiAody0+d19yZXEgJiYgdy0+d190bWVtKSB7DQorCQkJCXJlZ2lzdGVy IHN0cnVjdCBpZm1hX21zZ2hkciAqaWZtYW07DQorDQorCQkJCWlmbWFtID0g KHN0cnVjdCBpZm1hX21zZ2hkciAqKXctPndfdG1lbTsNCisJCQkJaWZtYW0t PmlmbWFtX2luZGV4ID0gaWZtYS0+aWZtYV9pZnAtPmlmX2luZGV4Ow0KKwkJ CQlpZm1hbS0+aWZtYW1fZmxhZ3MgPSAwOw0KKwkJCQlpZm1hbS0+aWZtYW1f YWRkcnMgPSBpbmZvLnJ0aV9hZGRyczsNCisJCQkJZXJyb3IgPSBTWVNDVExf T1VUKHctPndfcmVxLCB3LT53X3RtZW0sIGxlbik7DQorCQkJCWlmIChlcnJv cikNCisJCQkJCWdvdG8gZG9uZTsNCisJCQl9DQorCQl9DQorCQlpbmZvLnJ0 aV9pbmZvW1JUQVhfSUZBXSA9IE5VTEw7DQorCQlpbmZvLnJ0aV9pbmZvW1JU QVhfSUZQXSA9IE5VTEw7DQorCQlpbmZvLnJ0aV9pbmZvW1JUQVhfR0FURVdB WV0gPSBOVUxMOw0KKwl9DQorZG9uZToNCisJLyogSUZORVRfUlVOTE9DSygp OyAqLyAvKiBYWFggKi8NCisJcmV0dXJuIChlcnJvcik7DQorfQ0KKw0KIHN0 YXRpYyBpbnQNCiBzeXNjdGxfcnRzb2NrKFNZU0NUTF9IQU5ETEVSX0FSR1Mp DQogew0KQEAgLTEwNjYsNiArMTEyNCwxMSBAQA0KIA0KIAljYXNlIE5FVF9S VF9JRkxJU1Q6DQogCQllcnJvciA9IHN5c2N0bF9pZmxpc3QoYWYsICZ3KTsN CisJCWJyZWFrOw0KKw0KKwljYXNlIE5FVF9SVF9JRk1BTElTVDoNCisJCWVy cm9yID0gc3lzY3RsX2lmbWFsaXN0KGFmLCAmdyk7DQorCQlicmVhazsNCiAJ fQ0KIAlzcGx4KHMpOw0KIAlpZiAody53X3RtZW0pDQo= --0-1145545882-1068539389=:7611-- From owner-freebsd-net@FreeBSD.ORG Tue Nov 11 01:38:00 2003 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 B32F816A4CE for ; Tue, 11 Nov 2003 01:38:00 -0800 (PST) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A6D643F93 for ; Tue, 11 Nov 2003 01:37:59 -0800 (PST) (envelope-from oppermann@pipeline.ch) Received: (qmail 41068 invoked from network); 11 Nov 2003 09:40:49 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 11 Nov 2003 09:40:49 -0000 Message-ID: <3FB0ADE8.44B00CF9@pipeline.ch> Date: Tue, 11 Nov 2003 10:37:44 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: popsong old References: <20031111063627.45765.qmail@web10004.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: tcp hostcache and ip fastforward for review 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, 11 Nov 2003 09:38:00 -0000 popsong old wrote: > > > ip_fastforward > > > - removes ip_flow forwarding code > > - adds full direct process-to-completion IPv4 > forwarding code > > - handles ip fragmentation incl. hw support > (ip_flow did not) > > - supports ipfw and ipfilter (ip_flow did not) > > - supports divert and ipfw fwd (ip_flow did not) > > - drops anything it can't handle back to normal > ip_input > > Should we worry about the locking in IPFilter? It > seems that there are no locking at all in IPFilter for > FreeBSD. I haven't touched ipfilter, but yes, there is currently no locking in ipfilter. This ain't good I suppose. I guess it would be easy to slap a global ipfilter lock on there. We can't go directly into ipfilter to do locking because that would take ipfilter off the vendor branch and would make updating it impossible. > BTW, we'll get even better performance if we keep both > interfaces' MAC addresses in cache (and call > ifp->if_start directly). This requires to keep > ethernet header in mbuf untouched and is only relevant > in ethernet though. I implemented such layer 2 cache > in a local version of IPFilter and got some good > results. I don't understand why you want to do that unless you are doing bridging. We have to look up the mac address of the next hop anyway. If that is not already in the routing table it needs to do a arp lookup. -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Nov 11 07:26:00 2003 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 82B4C16A4CE; Tue, 11 Nov 2003 07:26:00 -0800 (PST) Received: from cheer.mahoroba.org (flets19-018.kamome.or.jp [218.45.19.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 85FF643FF2; Tue, 11 Nov 2003 07:25:56 -0800 (PST) (envelope-from ume@mahoroba.org) Received: from lyrics.mahoroba.org (IDENT:ygcmI3DUzInNlIq0w12bebMOEqTxmSs0IGDpunGlZ8+Z5GQsbD6WiKcXaL3E/tEp@lyrics.mahoroba.org [IPv6:3ffe:501:185b:8010:280:88ff:fe03:4841]) (user=ume mech=CRAM-MD5 bits=0)hABFOnEU041480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Nov 2003 00:24:52 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Wed, 12 Nov 2003 00:24:47 +0900 Message-ID: From: Hajimu UMEMOTO To: Andre Oppermann In-Reply-To: <3FAE68FB.64D262FF@pipeline.ch> References: <3FAE68FB.64D262FF@pipeline.ch> User-Agent: xcite1.38> Wanderlust/2.11.3 (Wonderwall) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (=?ISO-2022-JP?B?GyRCOC1MWhsoQg==?=) X-Operating-System: FreeBSD 5.1-CURRENT MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.6 required=5.0 tests=DOMAIN_4U2 autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on cheer.mahoroba.org cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: mb@imp.ch cc: sam@errno.com Subject: Re: tcp hostcache and ip fastforward for review 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, 11 Nov 2003 15:26:00 -0000 Hi, >>>>> On Sun, 09 Nov 2003 17:19:07 +0100 >>>>> Andre Oppermann said: oppermann> The patch is here (relative to -CURRENT as of 2003-11-09): oppermann> http://www.nrg4u.com/freebsd/tcphostcache+ipfastforward-20031109.patch The patch cannot be compiled: cc -c -O -pipe -march=pentium3 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/home/ume/cvs/freefall/current/src/sys -I/usr/home/ume/cvs/freefall/current/src/sys/contrib/dev/acpica -I/usr/home/ume/cvs/freefall/current/src/sys/contrib/ipfilter -I/usr/home/ume/cvs/freefall/current/src/sys/contrib/dev/ath -I/usr/home/ume/cvs/freefall/current/src/sys/contrib/dev/ath/freebsd -I/usr/home/ume/cvs/freefall/current/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/home/ume/cvs/freefall/current/src/sys/netinet/ip_input.c /usr/home/ume/cvs/freefall/current/src/sys/netinet/ip_input.c: In function `ip_forward': /usr/home/ume/cvs/freefall/current/src/sys/netinet/ip_input.c:1960: warning: implicit declaration of function `ipsec_getpolicybyaddr' /usr/home/ume/cvs/freefall/current/src/sys/netinet/ip_input.c:1963: warning: assignment makes pointer from integer without a cast *** Error code 1 There is no ipsec_getpolicybyaddr() for IPSEC. And, #ifdef is slightly complex. I don't tested it actually, yet. --- sys/netinet/ip_input.c.orig Wed Nov 12 00:08:42 2003 +++ sys/netinet/ip_input.c Wed Nov 12 00:18:50 2003 @@ -1957,10 +1957,17 @@ int ipsechdr; struct route *ro; +#ifdef IPSEC + sp = ipsec4_getpolicybyaddr(mcopy, + IPSEC_DIR_OUTBOUND, + IP_FORWARDING, + &ipsecerror); +#else sp = ipsec_getpolicybyaddr(mcopy, IPSEC_DIR_OUTBOUND, IP_FORWARDING, &ipsecerror); +#endif if (sp != NULL) { /* count IPsec header size */ @@ -1995,13 +2002,11 @@ #else KEY_FREESP(&sp); #endif - ipstat.ips_cantfrag++; - break; - } else -#endif /*IPSEC || FAST_IPSEC*/ - destifp = ia->ia_ifp; -#if defined(IPSEC) || defined(FAST_IPSEC) + } else + destifp = ia->ia_ifp; } +#else + destifp = ia->ia_ifp; #endif /*IPSEC || FAST_IPSEC*/ ipstat.ips_cantfrag++; break; Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@bisd.hitachi.co.jp ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-net@FreeBSD.ORG Tue Nov 11 07:42:01 2003 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 0A97416A4CE for ; Tue, 11 Nov 2003 07:42:01 -0800 (PST) Received: from hotmail.com (law12-oe18.law12.hotmail.com [64.4.18.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F92E43FBD for ; Tue, 11 Nov 2003 07:42:00 -0800 (PST) (envelope-from company2210@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 11 Nov 2003 07:42:00 -0800 Received: from 81.17.78.11 by law12-oe18.law12.hotmail.com with DAV; Tue, 11 Nov 2003 15:42:00 +0000 X-Originating-IP: [81.17.78.11] X-Originating-Email: [company2210@hotmail.com] From: "Company 2210" To: Date: Tue, 11 Nov 2003 15:42:02 -0000 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300 Message-ID: X-OriginalArrivalTime: 11 Nov 2003 15:42:00.0171 (UTC) FILETIME=[58866BB0:01C3A86A] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: PPPoE Daemon Problems 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, 11 Nov 2003 15:42:01 -0000 Hi, I have a Windows XP computer connecting to a FreeBSD 4.8 Stable box = running PPPoE Daemon. The connection, disconnection works perfectly - = however if I yank out the cable of 'live' PPPoE connection (or terminate = it via a windows crash) on the Windows XP PC, the tunnel interface fails = to be placed in a 'down' state on the PPPoE FreeBSD box. This results in = a debug error informing me that: Error: ipcp_InterfaceUp: unable to set ip address repeatadly. Only a reboot seems to resolve the issue. I assume this = message is referring to the fact it thinks the IP address is in use and = bound to a tunnel currently in an 'UP' state. Does PPP not maintain a = link state? Is this a bug? Or is their a way around the problem so that = when a user terminates, the tunnel is brought down gracefully at the = FreeBSD end, freeing the IP address? My ppp.conf is: default: set log Chat Command Phase enable chap =20 allow mode direct enable proxy =20 disable ipv6cp set mru 1472 set mtu 1472 set ifaddr 82.17.66.1 82.17.66.10 accept dns Many Thanks Colin.=20 From owner-freebsd-net@FreeBSD.ORG Tue Nov 11 08:30:35 2003 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 E915716A4CF; Tue, 11 Nov 2003 08:30:35 -0800 (PST) Received: from hercules.icarz.com (ns1.icarz.com [207.99.22.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3BBBD43FBD; Tue, 11 Nov 2003 08:30:30 -0800 (PST) (envelope-from kenm@icarz.com) Received: from deanna.icarz.com (deanna.icarz.com [207.99.22.19]) by hercules.icarz.com (8.11.6/8.10.1) with ESMTP id hABGUT412423; Tue, 11 Nov 2003 11:30:29 -0500 (EST) Received: from kenxp (netb-178.icarz.com [209.123.219.178]) by deanna.icarz.com (8.12.9p2/8.12.9) with SMTP id hABGUS8O078013; Tue, 11 Nov 2003 11:30:28 -0500 (EST) (envelope-from kenm@icarz.com) Message-ID: <063d01c3a870$550b18e0$b2db7bd1@icarz.com> From: "Ken Menzel" To: "Andre Oppermann" , , References: <3FAE68FB.64D262FF@pipeline.ch> Date: Tue, 11 Nov 2003 11:24:50 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Scanned-By: MIMEDefang 2.38 Subject: Re: tcp hostcache and ip fastforward for review 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, 11 Nov 2003 16:30:36 -0000 Hi Andre, Your patch applies just fine for me now on Oct 10th current sources. Everything seems to be working fine on dual processor Dell 2500 with SMP kernel. This is a network backup machine. I don't see any problems, just as fast as always and seems to be solid so far, it has only been running a few hours. I ran some network backups to this server and ssh sessions out. Thanks Ken riker# sysctl -a net.inet.tcp.hostcache.list net.inet.tcp.hostcache.list: IP address MTU SSTRESH RTT RTTVAR BANDWIDTH CWND SENDPIPE RECVPIPE HITS UPD EXP 209.123.219.10 0 0 14ms 9ms 1805600 6516 0 0 4 3 3600 207.99.22.19 0 0 17ms 13ms 1098400 65535 0 0 4 3 600 ----- Original Message ----- From: "Andre Oppermann" To: ; Cc: ; ; Sent: Sunday, November 09, 2003 11:19 AM Subject: tcp hostcache and ip fastforward for review > Hello all, > > this patch contains three things (to be separated for committing): > > tcp_hostcache > > - removes protocol cloning from routing table (IPv4+6) > - removes rtentry pointer from inpcb and in6pcb From owner-freebsd-net@FreeBSD.ORG Tue Nov 11 08:57:02 2003 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 1835216A4CE; Tue, 11 Nov 2003 08:57:02 -0800 (PST) Received: from cheer.mahoroba.org (flets19-018.kamome.or.jp [218.45.19.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1FD3E43FAF; Tue, 11 Nov 2003 08:57:00 -0800 (PST) (envelope-from ume@mahoroba.org) Received: from lyrics.mahoroba.org (IDENT:E2VfnZZLwlqDniE95ivBORJ+cvnvKlVb3Sibr1MJqBxV/I8pSuECFOMQYM3w3UlA@lyrics.mahoroba.org [IPv6:3ffe:501:185b:8010:280:88ff:fe03:4841]) (user=ume mech=CRAM-MD5 bits=0)hABGu1EU036553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Nov 2003 01:56:04 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Wed, 12 Nov 2003 01:56:01 +0900 Message-ID: From: Hajimu UMEMOTO To: Andre Oppermann In-Reply-To: <3FAE68FB.64D262FF@pipeline.ch> References: <3FAE68FB.64D262FF@pipeline.ch> User-Agent: xcite1.38> Wanderlust/2.11.3 (Wonderwall) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (=?ISO-2022-JP?B?GyRCOC1MWhsoQg==?=) X-Operating-System: FreeBSD 5.1-CURRENT MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.6 required=5.0 tests=DOMAIN_4U2 autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on cheer.mahoroba.org cc: mb@imp.ch cc: freebsd-current@freebsd.org cc: ume@freebsd.org cc: sam@errno.com cc: freebsd-net@freebsd.org Subject: Re: tcp hostcache and ip fastforward for review 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, 11 Nov 2003 16:57:02 -0000 Hi, >>>>> On Sun, 09 Nov 2003 17:19:07 +0100 >>>>> Andre Oppermann said: oppermann> The patch is here (relative to -CURRENT as of 2003-11-09): oppermann> http://www.nrg4u.com/freebsd/tcphostcache+ipfastforward-20031109.patch It panics at boot around invoking rtsol(8): Fatal trap 12: page fault while in kernel mode fault virtual address = 0x80 fault code = supervisor write, page not present instruction pointer = 0x8:0xc05b5278 stack pointer = 0x10:0xd7be0944 frame pointer = 0x10:0xd7be0998 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 4912 (rtsol) trap number = 12 panic: page fault #0 doadump () at /usr/home/ume/cvs/freefall/current/src/sys/kern/kern_shutdown.c:240 240 dumping++; (kgdb) bt #0 doadump () at /usr/home/ume/cvs/freefall/current/src/sys/kern/kern_shutdown.c:240 #1 0xc04fad80 in boot (howto=256) at /usr/home/ume/cvs/freefall/current/src/sys/kern/kern_shutdown.c:372 #2 0xc04fb168 in panic () at /usr/home/ume/cvs/freefall/current/src/sys/kern/kern_shutdown.c:550 #3 0xc0662316 in trap_fatal (frame=0xd7be0904, eva=0) at /usr/home/ume/cvs/freefall/current/src/sys/i386/i386/trap.c:821 #4 0xc0661fb2 in trap_pfault (frame=0xd7be0904, usermode=0, eva=128) at /usr/home/ume/cvs/freefall/current/src/sys/i386/i386/trap.c:735 #5 0xc0661b05 in trap (frame= {tf_fs = -1068629992, tf_es = -675414000, tf_ds = -675414000, tf_edi = -1010894932, tf_esi = -675411476, tf_ebp = -675411560, tf_isp = -675411664, tf_ebx = 0, tf_edx = -1010048384, tf_ecx = 0, tf_eax = 4, tf_trapno = 12, tf_err = 2, tf_eip = -1067756936, tf_cs = 8, tf_eflags = 66118, tf_esp = -675411440, tf_ss = -675411320}) at /usr/home/ume/cvs/freefall/current/src/sys/i386/i386/trap.c:420 #6 0xc0652df8 in calltrap () at {standard input}:94 #7 0xc05b4b5b in in6_selectsrc (dstsock=0xd7be09ec, opts=0xd7be0a88, mopts=0x0, ro=0x0, laddr=0xc3bef7ac, errorp=0xd7be0a84) at /usr/home/ume/cvs/freefall/current/src/sys/netinet6/in6_src.c:242 #8 0xc05cda65 in rip6_output (m=0xc19a1000) at /usr/home/ume/cvs/freefall/current/src/sys/netinet6/raw_ip6.c:426 #9 0xc05ce4ec in rip6_send (so=0xc3bdf660, flags=0, m=0xc19a1000, nam=0x0, control=0x0, td=0xc3cbe280) at /usr/home/ume/cvs/freefall/current/src/sys/netinet6/raw_ip6.c:742 #10 0xc053a62d in sosend (so=0xc3bdf660, addr=0xc39bbb20, uio=0xd7be0bf4, top=0xc19a1000, control=0xc19a1100, flags=0, td=0xc3cbe280) at /usr/home/ume/cvs/freefall/current/src/sys/kern/uipc_socket.c:715 #11 0xc053ef7c in kern_sendit (td=0xc3cbe280, s=3, mp=0xd7be0ca4, flags=0, control=0x0) ---Type to continue, or q to quit--- at /usr/home/ume/cvs/freefall/current/src/sys/kern/uipc_syscalls.c:722 #12 0xc053ed9e in sendit (td=0x0, s=0, mp=0xd7be0ca4, flags=0) at /usr/home/ume/cvs/freefall/current/src/sys/kern/uipc_syscalls.c:662 #13 0xc053f393 in sendmsg (td=0x0, uap=0xd7be0d10) at /usr/home/ume/cvs/freefall/current/src/sys/kern/uipc_syscalls.c:900 #14 0xc06626a0 in syscall (frame= {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 5, tf_esi = 1, tf_ebp = -1077940776, tf_isp = -675410572, tf_ebx = 134549504, tf_edx = 134545504, tf_ecx = 134545504, tf_eax = 28, tf_trapno = 12, tf_err = 2, tf_eip = 671923007, tf_cs = 31, tf_eflags = 514, tf_esp = -1077940852, tf_ss = 47}) at /usr/home/ume/cvs/freefall/current/src/sys/i386/i386/trap.c:1010 #15 0xc0652e4d in Xint0x80_syscall () at {standard input}:136 ---Can't read userspace from dump, or kernel process--- (kgdb) frame 7 #7 0xc05b4b5b in in6_selectsrc (dstsock=0xd7be09ec, opts=0xd7be0a88, mopts=0x0, ro=0x0, laddr=0xc3bef7ac, errorp=0xd7be0a84) at /usr/home/ume/cvs/freefall/current/src/sys/netinet6/in6_src.c:242 242 if ((*errorp = in6_selectif(dstsock, opts, mopts, ro, &ifp)) != 0) (kgdb) Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@bisd.hitachi.co.jp ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-net@FreeBSD.ORG Tue Nov 11 09:06:11 2003 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 26BB816A4D1 for ; Tue, 11 Nov 2003 09:06:11 -0800 (PST) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id DFB6243FD7 for ; Tue, 11 Nov 2003 09:06:06 -0800 (PST) (envelope-from oppermann@pipeline.ch) Received: (qmail 36173 invoked from network); 11 Nov 2003 17:08:57 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 11 Nov 2003 17:08:57 -0000 Message-ID: <3FB116FD.5BB0CF7A@pipeline.ch> Date: Tue, 11 Nov 2003 18:06:05 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Hajimu UMEMOTO References: <3FAE68FB.64D262FF@pipeline.ch> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: mb@imp.ch cc: sam@errno.com Subject: Re: tcp hostcache and ip fastforward for review 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, 11 Nov 2003 17:06:11 -0000 Hajimu UMEMOTO wrote: > > Hi, > > >>>>> On Sun, 09 Nov 2003 17:19:07 +0100 > >>>>> Andre Oppermann said: > > oppermann> The patch is here (relative to -CURRENT as of 2003-11-09): > oppermann> http://www.nrg4u.com/freebsd/tcphostcache+ipfastforward-20031109.patch > > The patch cannot be compiled: > > cc -c -O -pipe -march=pentium3 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/home/ume/cvs/freefall/current/src/sys -I/usr/home/ume/cvs/freefall/current/src/sys/contrib/dev/acpica -I/usr/home/ume/cvs/freefall/current/src/sys/contrib/ipfilter -I/usr/home/ume/cvs/freefall/current/src/sys/contrib/dev/ath -I/usr/home/ume/cvs/freefall/current/src/sys/contrib/dev/ath/freebsd -I/usr/home/ume/cvs/freefall/current/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/home/ume/cvs/freefall/current/src/sys/netinet/ip_input.c > /usr/home/ume/cvs/freefall/current/src/sys/netinet/ip_input.c: In function `ip_forward': > /usr/home/ume/cvs/freefall/current/src/sys/netinet/ip_input.c:1960: warning: implicit declaration of function `ipsec_getpolicybyaddr' > /usr/home/ume/cvs/freefall/current/src/sys/netinet/ip_input.c:1963: warning: assignment makes pointer from integer without a cast > *** Error code 1 > > There is no ipsec_getpolicybyaddr() for IPSEC. And, #ifdef is > slightly complex. I've applied you fix. This was an oversight by me when collapsing the two IPSEC and FAST_IPSEC ifdef's. However there is a problem in netkey/key.c with the static variable ipsec_esp_auth which is unused if IPSEC_ESP is not defined. -- Andre > I don't tested it actually, yet. > > --- sys/netinet/ip_input.c.orig Wed Nov 12 00:08:42 2003 > +++ sys/netinet/ip_input.c Wed Nov 12 00:18:50 2003 > @@ -1957,10 +1957,17 @@ > int ipsechdr; > struct route *ro; > > +#ifdef IPSEC > + sp = ipsec4_getpolicybyaddr(mcopy, > + IPSEC_DIR_OUTBOUND, > + IP_FORWARDING, > + &ipsecerror); > +#else > sp = ipsec_getpolicybyaddr(mcopy, > IPSEC_DIR_OUTBOUND, > IP_FORWARDING, > &ipsecerror); > +#endif > > if (sp != NULL) { > /* count IPsec header size */ > @@ -1995,13 +2002,11 @@ > #else > KEY_FREESP(&sp); > #endif > - ipstat.ips_cantfrag++; > - break; > - } else > -#endif /*IPSEC || FAST_IPSEC*/ > - destifp = ia->ia_ifp; > -#if defined(IPSEC) || defined(FAST_IPSEC) > + } else > + destifp = ia->ia_ifp; > } > +#else > + destifp = ia->ia_ifp; > #endif /*IPSEC || FAST_IPSEC*/ > ipstat.ips_cantfrag++; > break; > > Sincerely, > > -- > Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan > ume@mahoroba.org ume@bisd.hitachi.co.jp ume@{,jp.}FreeBSD.org > http://www.imasy.org/~ume/ From owner-freebsd-net@FreeBSD.ORG Tue Nov 11 09:28:36 2003 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 76EFF16A4CF for ; Tue, 11 Nov 2003 09:28:36 -0800 (PST) Received: from cheer.mahoroba.org (flets19-018.kamome.or.jp [218.45.19.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 15C0343FBD for ; Tue, 11 Nov 2003 09:28:35 -0800 (PST) (envelope-from ume@mahoroba.org) Received: from lyrics.mahoroba.org (IDENT:Wv8zVp5UYy3Yyy+AZ0p/LjWQrvWU33zoCeOi++DsoUSVxMDgtR17wOc2MavHz35u@lyrics.mahoroba.org [IPv6:3ffe:501:185b:8010:280:88ff:fe03:4841]) (user=ume mech=CRAM-MD5 bits=0)hABHRiEU045561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Nov 2003 02:27:44 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Wed, 12 Nov 2003 02:27:44 +0900 Message-ID: From: Hajimu UMEMOTO To: Andre Oppermann In-Reply-To: <3FB116FD.5BB0CF7A@pipeline.ch> References: <3FAE68FB.64D262FF@pipeline.ch> <3FB116FD.5BB0CF7A@pipeline.ch> User-Agent: xcite1.38> Wanderlust/2.11.3 (Wonderwall) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (=?ISO-2022-JP?B?GyRCOC1MWhsoQg==?=) X-Operating-System: FreeBSD 5.1-CURRENT MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on cheer.mahoroba.org cc: mb@imp.ch cc: freebsd-current@freebsd.org cc: Hajimu UMEMOTO cc: sam@errno.com cc: freebsd-net@freebsd.org Subject: Re: tcp hostcache and ip fastforward for review 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, 11 Nov 2003 17:28:36 -0000 Hi, >>>>> On Tue, 11 Nov 2003 18:06:05 +0100 >>>>> Andre Oppermann said: oppermann> However there is a problem in netkey/key.c with the static variable oppermann> ipsec_esp_auth which is unused if IPSEC_ESP is not defined. Thanks. I've just committed to define ipsec_esp_auth only when IPSEC_ESP is defined. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@bisd.hitachi.co.jp ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-net@FreeBSD.ORG Tue Nov 11 10:26:46 2003 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 2721C16A4CE for ; Tue, 11 Nov 2003 10:26:46 -0800 (PST) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 409DB43FD7 for ; Tue, 11 Nov 2003 10:26:43 -0800 (PST) (envelope-from oppermann@pipeline.ch) Received: (qmail 44110 invoked from network); 11 Nov 2003 18:29:33 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 11 Nov 2003 18:29:33 -0000 Message-ID: <3FB129E1.5D8F4D16@pipeline.ch> Date: Tue, 11 Nov 2003 19:26:41 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Hajimu UMEMOTO References: <3FAE68FB.64D262FF@pipeline.ch> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: mb@imp.ch cc: freebsd-current@freebsd.org cc: ume@freebsd.org cc: sam@errno.com cc: freebsd-net@freebsd.org Subject: Re: tcp hostcache and ip fastforward for review 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, 11 Nov 2003 18:26:46 -0000 Hajimu UMEMOTO wrote: > > Hi, > > >>>>> On Sun, 09 Nov 2003 17:19:07 +0100 > >>>>> Andre Oppermann said: > > oppermann> The patch is here (relative to -CURRENT as of 2003-11-09): > > oppermann> http://www.nrg4u.com/freebsd/tcphostcache+ipfastforward-20031109.patch > > It panics at boot around invoking rtsol(8): I have fixed the panic. It was a stupid braino in the test whether we have to free the allocated route. It was trying to free a null pointer route which obviously doesn't work. :-^ The updated patch is here: http://www.nrg4u.com/freebsd/tcphostcache+ipfastforward-20031111.patch If you could try again please? -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Nov 11 12:00:54 2003 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 577CB16A4D3; Tue, 11 Nov 2003 12:00:54 -0800 (PST) Received: from cheer.mahoroba.org (flets19-018.kamome.or.jp [218.45.19.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1AB0C43FBF; Tue, 11 Nov 2003 12:00:36 -0800 (PST) (envelope-from ume@mahoroba.org) Received: from lyrics.mahoroba.org (IDENT:DBE/pCtzxnacCBNAgpeqo2h2A8SP09D9Kk8lwVAYedXzoxMZB616axRFeeD/Qyvv@lyrics.mahoroba.org [IPv6:3ffe:501:185b:8010:280:88ff:fe03:4841]) (user=ume mech=CRAM-MD5 bits=0)hABJxVEU098515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Nov 2003 04:59:34 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Wed, 12 Nov 2003 04:59:31 +0900 Message-ID: From: Hajimu UMEMOTO To: Andre Oppermann In-Reply-To: <3FB129E1.5D8F4D16@pipeline.ch> References: <3FAE68FB.64D262FF@pipeline.ch> <3FB129E1.5D8F4D16@pipeline.ch> User-Agent: xcite1.38> Wanderlust/2.11.3 (Wonderwall) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (=?ISO-2022-JP?B?GyRCOC1MWhsoQg==?=) X-Operating-System: FreeBSD 5.1-CURRENT MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.6 required=5.0 tests=DOMAIN_4U2 autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on cheer.mahoroba.org cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: mb@imp.ch cc: sam@errno.com Subject: Re: tcp hostcache and ip fastforward for review 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, 11 Nov 2003 20:00:54 -0000 Hi, >>>>> On Tue, 11 Nov 2003 19:26:41 +0100 >>>>> Andre Oppermann said: oppermann> I have fixed the panic. It was a stupid braino in the test whether oppermann> we have to free the allocated route. It was trying to free a null oppermann> pointer route which obviously doesn't work. :-^ oppermann> The updated patch is here: oppermann> http://www.nrg4u.com/freebsd/tcphostcache+ipfastforward-20031111.patch oppermann> If you could try again please? It panics at another point on boot. panic: page fault panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0x7d1efae8 fault code = supervisor write, page not present instruction pointer = 0x8:0xc058e2bf stack pointer = 0x10:0xd2e5e84c frame pointer = 0x10:0xd2e5e874 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 10384 (racoon) trap number = 12 panic: page fault #0 doadump () at /usr/home/ume/cvs/freefall/current/src/sys/kern/kern_shutdown.c:240 240 dumping++; (kgdb) bt #0 doadump () at /usr/home/ume/cvs/freefall/current/src/sys/kern/kern_shutdown.c:240 #1 0xc04fad80 in boot (howto=260) at /usr/home/ume/cvs/freefall/current/src/sys/kern/kern_shutdown.c:372 #2 0xc04fb168 in panic () at /usr/home/ume/cvs/freefall/current/src/sys/kern/kern_shutdown.c:550 #3 0xc05441e1 in bremfreel (bp=0xcae402a8) at /usr/home/ume/cvs/freefall/current/src/sys/kern/vfs_bio.c:647 #4 0xc05440eb in bremfree (bp=0x0) at /usr/home/ume/cvs/freefall/current/src/sys/kern/vfs_bio.c:629 #5 0xc054f1a9 in cluster_wbuild (vp=0xc3c1ca44, size=16384, start_lbn=1, len=1) at /usr/home/ume/cvs/freefall/current/src/sys/kern/vfs_cluster.c:804 #6 0xc054ecf1 in cluster_write (bp=0xcae402a8, filesize=32768, seqcount=127) at /usr/home/ume/cvs/freefall/current/src/sys/kern/vfs_cluster.c:590 #7 0xc05fb428 in ffs_write (ap=0xd2e5e33c) at /usr/home/ume/cvs/freefall/current/src/sys/ufs/ffs/ffs_vnops.c:748 #8 0xc062cd53 in vnode_pager_generic_putpages (vp=0xc3c1ca44, m=0xd2e5e480, bytecount=4096, flags=12, rtvals=0xd2e5e440) at vnode_if.h:432 #9 0xc05507c0 in vop_stdputpages (ap=0x0) at /usr/home/ume/cvs/freefall/current/src/sys/kern/vfs_default.c:813 #10 0xc054fb98 in vop_defaultop (ap=0x0) at /usr/home/ume/cvs/freefall/current/src/sys/kern/vfs_default.c:161 #11 0xc060a208 in ufs_vnoperate (ap=0x0) at /usr/home/ume/cvs/freefall/current/src/sys/ufs/ufs/ufs_vnops.c:2793 #12 0xc062ca88 in vnode_pager_putpages (object=0xc3c20b90, m=0x0, count=0, sync=12, rtvals=0x0) at vnode_if.h:1357 #13 0xc0623b1e in vm_pageout_flush (mc=0xd2e5e480, count=1, flags=12) at /usr/home/ume/cvs/freefall/current/src/sys/vm/vm_pager.h:146 #14 0xc061dac6 in vm_object_page_collect_flush (object=0xc3c20b90, p=0xc14e54f0, curgeneration=1, pagerflags=12) ---Type to continue, or q to quit--- at /usr/home/ume/cvs/freefall/current/src/sys/vm/vm_object.c:948 #15 0xc061d4be in vm_object_page_clean (object=0xc3c20b90, start=7, end=0, flags=4) at /usr/home/ume/cvs/freefall/current/src/sys/vm/vm_object.c:747 #16 0xc055d5b9 in vfs_msync (mp=0xc3a4ac00, flags=2) at /usr/home/ume/cvs/freefall/current/src/sys/kern/vfs_subr.c:3235 #17 0xc055e769 in sync (td=0xc06e6fa0, uap=0x0) at /usr/home/ume/cvs/freefall/current/src/sys/kern/vfs_syscalls.c:140 #18 0xc04fa88d in boot (howto=256) at /usr/home/ume/cvs/freefall/current/src/sys/kern/kern_shutdown.c:281 #19 0xc04fb168 in panic () at /usr/home/ume/cvs/freefall/current/src/sys/kern/kern_shutdown.c:550 #20 0xc0662326 in trap_fatal (frame=0xd2e5e80c, eva=0) at /usr/home/ume/cvs/freefall/current/src/sys/i386/i386/trap.c:821 #21 0xc0661fc2 in trap_pfault (frame=0xd2e5e80c, usermode=0, eva=2099182312) at /usr/home/ume/cvs/freefall/current/src/sys/i386/i386/trap.c:735 #22 0xc0661b15 in trap (frame= {tf_fs = 24, tf_es = -756744176, tf_ds = -1067319280, tf_edi = -756684608, tf_esi = 2099182272, tf_ebp = -756684684, tf_isp = -756684744, tf_ebx = 1500, tf_edx = -1014756864, tf_ecx = -1014277120, tf_eax = 4, tf_trapno = 12, tf_err = 2, tf_eip = -1067916609, tf_cs = 8, tf_eflags = 68103, tf_esp = -756684268, tf_ss = -1013112832}) at /usr/home/ume/cvs/freefall/current/src/sys/i386/i386/trap.c:420 #23 0xc0652e08 in calltrap () at {standard input}:94 #24 0xc058e637 in tcp_hc_getmtu (inc=0x0) at /usr/home/ume/cvs/freefall/current/src/sys/netinet/tcp_hostcache.c:420 #25 0xc05bce17 in ip6_getpmtu (ro_pmtu=0x7d1efac0, ro=0x0, ifp=0xc38b5c00, dst=0xd2e5e9e0, mtup=0x0, alwaysfragp=0xd2e5e980) at /usr/home/ume/cvs/freefall/current/src/sys/netinet6/ip6_output.c:1400 #26 0xc05bbf1f in ip6_output (m0=0xd2e5eaa0, opt=0xd2e5eaa0, ro=0xd2e5ea10, flags=0, im6o=0x0, ifpp=0x0, inp=0xc3b2d900) ---Type to continue, or q to quit--- at /usr/home/ume/cvs/freefall/current/src/sys/netinet6/ip6_output.c:830 #27 0xc05cf5b9 in udp6_output (in6p=0xc3b2d900, m=0xc19a0b00, addr6=0xc19a0bf8, control=0xc199db00, td=0xc3840a00) at /usr/home/ume/cvs/freefall/current/src/sys/netinet6/udp6_output.c:297 #28 0xc05d03ce in udp6_send (so=0xc3c1b110, flags=0, m=0xc19a0a00, addr=0xc39bb5e0, control=0xc199db00, td=0xc3840a00) at /usr/home/ume/cvs/freefall/current/src/sys/netinet6/udp6_usrreq.c:758 #29 0xc053a62d in sosend (so=0xc3c1b110, addr=0xc39bb5e0, uio=0xd2e5ebf4, top=0xc19a0a00, control=0xc199db00, flags=0, td=0xc3840a00) at /usr/home/ume/cvs/freefall/current/src/sys/kern/uipc_socket.c:715 #30 0xc053ef7c in kern_sendit (td=0xc3840a00, s=6, mp=0xd2e5eca4, flags=0, control=0x0) at /usr/home/ume/cvs/freefall/current/src/sys/kern/uipc_syscalls.c:722 #31 0xc053ed9e in sendit (td=0x0, s=0, mp=0xd2e5eca4, flags=0) at /usr/home/ume/cvs/freefall/current/src/sys/kern/uipc_syscalls.c:662 #32 0xc053f393 in sendmsg (td=0x0, uap=0xd2e5ed10) at /usr/home/ume/cvs/freefall/current/src/sys/kern/uipc_syscalls.c:900 #33 0xc06626b0 in syscall (frame= {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1077941600, tf_esi = 2, tf_ebp = -1077941400, tf_isp = -756683404, tf_ebx = 0, tf_edx = 27, tf_ecx = -1077942160, tf_eax = 28, tf_trapno = 0, tf_err = 2, tf_eip = 673524543, tf_cs = 31, tf_eflags = 658, tf_esp = -1077941956, tf_ss = 47}) at /usr/home/ume/cvs/freefall/current/src/sys/i386/i386/trap.c:1010 #34 0xc0652e5d in Xint0x80_syscall () at {standard input}:136 ---Can't read userspace from dump, or kernel process--- (kgdb) frame 24 #24 0xc058e637 in tcp_hc_getmtu (inc=0x0) at /usr/home/ume/cvs/freefall/current/src/sys/netinet/tcp_hostcache.c:420 420 hc_entry = tcp_hc_lookup(inc); (kgdb) Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@bisd.hitachi.co.jp ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-net@FreeBSD.ORG Tue Nov 11 14:03:56 2003 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 A96EE16A4CE; Tue, 11 Nov 2003 14:03:56 -0800 (PST) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 50A2843FE1; Tue, 11 Nov 2003 14:03:54 -0800 (PST) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.9/8.12.3) with ESMTP id hABM3pOT017776; Tue, 11 Nov 2003 14:03:51 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.9/8.12.3/Submit) id hABM3pVT017773; Tue, 11 Nov 2003 14:03:51 -0800 Date: Tue, 11 Nov 2003 14:03:51 -0800 From: Brooks Davis To: pdeuskar@freebsd.org Message-ID: <20031111220351.GA14761@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jI8keyz6grp/JLjh" Content-Disposition: inline User-Agent: Mutt/1.5.4i X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu cc: net@freebsd.org Subject: locking issues in em_watchdog 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, 11 Nov 2003 22:03:56 -0000 --jI8keyz6grp/JLjh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable em_watchdog() currently does not lock around the call to em_stop which means that if the lock is not held, it panics. I recently ran into this problem when the ACPI/SMP commits broke one of my machines. The following patch keeps the watchdog timer from being an instant panic on this system. It doesn't make the driver work, but I don't think that's actually a driver issue. -- Brooks =3D=3D=3D=3D //depot/user/brooks/xname/sys/dev/em/if_em.c#7 - /home/brooks/= working/freebsd/p4/xname/sys/dev/em/if_em.c =3D=3D=3D=3D @@ -767,8 +767,10 @@ =20 ifp->if_flags &=3D ~IFF_RUNNING; =20 + EM_LOCK(adapter); em_stop(adapter); - em_init(adapter); + em_init_locked(adapter); + EM_UNLOCK(adapter); =20 ifp->if_oerrors++; return; --=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 --jI8keyz6grp/JLjh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/sVy7XY6L6fI4GtQRAuGqAJ44TFl6x8nq7mmstkCLVxYE45clUQCfYWFL Gde54tVdupt3jzoFkio3qA8= =iXJf -----END PGP SIGNATURE----- --jI8keyz6grp/JLjh-- From owner-freebsd-net@FreeBSD.ORG Tue Nov 11 14:21:57 2003 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 705FA16A4CF for ; Tue, 11 Nov 2003 14:21:57 -0800 (PST) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6ABC943F85 for ; Tue, 11 Nov 2003 14:21:55 -0800 (PST) (envelope-from oppermann@pipeline.ch) Received: (qmail 60920 invoked from network); 11 Nov 2003 22:24:45 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.54]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 11 Nov 2003 22:24:45 -0000 Message-ID: <3FB16101.66A10F00@pipeline.ch> Date: Tue, 11 Nov 2003 23:21:53 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ken Menzel References: <3FAE68FB.64D262FF@pipeline.ch> <063d01c3a870$550b18e0$b2db7bd1@icarz.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: tcp hostcache and ip fastforward for review 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, 11 Nov 2003 22:21:57 -0000 Ken Menzel wrote: > > Hi Andre, > Your patch applies just fine for me now on Oct 10th current > sources. Everything seems to be working fine on dual processor Dell > 2500 with SMP kernel. This is a network backup machine. I don't see > any problems, just as fast as always and seems to be solid so far, > it has only been running a few hours. I ran some network backups to > this server and ssh sessions out. Great! Many thanks for testing and feedback! -- Andre > Thanks Ken > riker# sysctl -a net.inet.tcp.hostcache.list > net.inet.tcp.hostcache.list: > IP address MTU SSTRESH RTT RTTVAR BANDWIDTH CWND > SENDPIPE RECVPIPE HITS UPD EXP > 209.123.219.10 0 0 14ms 9ms 1805600 6516 > 0 0 4 3 3600 > 207.99.22.19 0 0 17ms 13ms 1098400 65535 > 0 0 4 3 600 > > ----- Original Message ----- > From: "Andre Oppermann" > To: ; > Cc: ; ; > Sent: Sunday, November 09, 2003 11:19 AM > Subject: tcp hostcache and ip fastforward for review > > > Hello all, > > > > this patch contains three things (to be separated for committing): > > > > tcp_hostcache > > > > - removes protocol cloning from routing table (IPv4+6) > > - removes rtentry pointer from inpcb and in6pcb > From owner-freebsd-net@FreeBSD.ORG Tue Nov 11 14:28:12 2003 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 435AF16A4CE for ; Tue, 11 Nov 2003 14:28:12 -0800 (PST) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE5A843FCB for ; Tue, 11 Nov 2003 14:28:08 -0800 (PST) (envelope-from oppermann@pipeline.ch) Received: (qmail 61418 invoked from network); 11 Nov 2003 22:30:59 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.54]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 11 Nov 2003 22:30:59 -0000 Message-ID: <3FB16277.9E658A8E@pipeline.ch> Date: Tue, 11 Nov 2003 23:28:07 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Hajimu UMEMOTO References: <3FAE68FB.64D262FF@pipeline.ch> <3FB129E1.5D8F4D16@pipeline.ch> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: mb@imp.ch cc: sam@errno.com Subject: Re: tcp hostcache and ip fastforward for review 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, 11 Nov 2003 22:28:12 -0000 Hajimu UMEMOTO wrote: > > Hi, > > >>>>> On Tue, 11 Nov 2003 19:26:41 +0100 > >>>>> Andre Oppermann said: > > oppermann> I have fixed the panic. It was a stupid braino in the test whether > oppermann> we have to free the allocated route. It was trying to free a null > oppermann> pointer route which obviously doesn't work. :-^ > > oppermann> The updated patch is here: > > oppermann> http://www.nrg4u.com/freebsd/tcphostcache+ipfastforward-20031111.patch > > oppermann> If you could try again please? > > It panics at another point on boot. > (kgdb) frame 24 > #24 0xc058e637 in tcp_hc_getmtu (inc=0x0) > at /usr/home/ume/cvs/freefall/current/src/sys/netinet/tcp_hostcache.c:420 > 420 hc_entry = tcp_hc_lookup(inc); > (kgdb) Did the panic message say "tcp_hc_lookup with NULL in_conninfo pointer"? I can't find why inc can be possibly NULL because its fresh and directly on the stack. But I'm too tired right now (that's probably why I don't see atm). Next try tomorrow morning (mid-European time). -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Nov 11 18:45:08 2003 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 6BA9A16A4CE for ; Tue, 11 Nov 2003 18:45:08 -0800 (PST) Received: from web10007.mail.yahoo.com (web10007.mail.yahoo.com [216.136.130.43]) by mx1.FreeBSD.org (Postfix) with SMTP id 7E69643F93 for ; Tue, 11 Nov 2003 18:45:07 -0800 (PST) (envelope-from oldpopsong@yahoo.com) Message-ID: <20031112024507.89398.qmail@web10007.mail.yahoo.com> Received: from [218.244.38.34] by web10007.mail.yahoo.com via HTTP; Tue, 11 Nov 2003 18:45:07 PST Date: Tue, 11 Nov 2003 18:45:07 -0800 (PST) From: popsong old To: Andre Oppermann In-Reply-To: <3FB0ADE8.44B00CF9@pipeline.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: freebsd-net@freebsd.org Subject: Re: tcp hostcache and ip fastforward for review 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, 12 Nov 2003 02:45:08 -0000 --- Andre Oppermann wrote: > > BTW, we'll get even better performance if we keep both > > interfaces' MAC addresses in cache (and call > > ifp->if_start directly). This requires to keep > > ethernet header in mbuf untouched and is only relevant > > in ethernet though. I implemented such layer 2 cache > > in a local version of IPFilter and got some good > > results. > > I don't understand why you want to do that unless you > are doing bridging. We have to look up the mac address > of the next hop anyway. If that is not already in the > routing table it needs to do a arp lookup. > > -- > Andre Ah, my fault. I didn't read your patch carefully and assumed that ip fastforward do flow caching as ip_flow does. However, I think ip flow caching is a good thing and maybe implementing it in ip fastforward is a good idea. song __________________________________ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree From owner-freebsd-net@FreeBSD.ORG Tue Nov 11 22:45:40 2003 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 ACDD416A4CE for ; Tue, 11 Nov 2003 22:45:40 -0800 (PST) Received: from silver.he.iki.fi (helenius.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D80E43FAF for ; Tue, 11 Nov 2003 22:45:39 -0800 (PST) (envelope-from pete@he.iki.fi) Received: from he.iki.fi (localhost [127.0.0.1]) by silver.he.iki.fi (8.12.9p2/8.11.4) with ESMTP id hAC6jZgr013529; Wed, 12 Nov 2003 08:45:36 +0200 (EET) (envelope-from pete@he.iki.fi) Message-ID: <3FB1D6F5.8020403@he.iki.fi> Date: Wed, 12 Nov 2003 08:45:09 +0200 From: Petri Helenius User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: popsong old References: <20031112024507.89398.qmail@web10007.mail.yahoo.com> In-Reply-To: <20031112024507.89398.qmail@web10007.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: tcp hostcache and ip fastforward for review 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, 12 Nov 2003 06:45:40 -0000 popsong old wrote: >Ah, my fault. I didn't read your patch carefully and assumed that ip >fastforward do flow caching as ip_flow does. However, I think ip flow >caching is a good thing and maybe implementing it in ip fastforward is >a good idea. > > > Caching flows has mixed results, it works for you if you have to keep flow-based state like in firewalling situations but usually takes performance in generic packet forwarding because of the great number of flows per host in current public Internet. Pete From owner-freebsd-net@FreeBSD.ORG Wed Nov 12 02:35:41 2003 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 CCD2A16A4CE for ; Wed, 12 Nov 2003 02:35:41 -0800 (PST) Received: from cg-coreel.com (mail2.hostek.com [216.15.163.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0CC1A43FD7 for ; Wed, 12 Nov 2003 02:35:41 -0800 (PST) (envelope-from ipsita@cg-coreel.com) Received: from IPSIT [203.196.158.195] by cg-coreel.com with ESMTP (SMTPD32-7.15) id AE8E9240120; Wed, 12 Nov 2003 04:42:22 -0600 Message-ID: <007001c3a908$b34aeb90$9600a2c0@IPSIT> From: "ipsita" To: Date: Wed, 12 Nov 2003 16:05:26 +0530 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4922.1500 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: Ethernet interface trunking and 802.3ad 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, 12 Nov 2003 10:35:41 -0000 Hello Patrick.. Can U pls make me undersand abt link aggregation considering its = architecture into account. I've certains doubts in its architecture like: 1) How a Port aggregator does aggregation? 2) How a LACP does automatic port trunking? pls send some links as well so tht I can be able to ustand the port = aggregation architecture. hope to see a response fm U soon... Regards ###################################### Ipsita (Design Engg) CG-CoreEl Programmables Solution Pvt.LtD Bangalore- 560034 India ###################################### From owner-freebsd-net@FreeBSD.ORG Wed Nov 12 02:36:31 2003 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 5B25A16A4CE for ; Wed, 12 Nov 2003 02:36:31 -0800 (PST) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 18B1D43F85 for ; Wed, 12 Nov 2003 02:36:30 -0800 (PST) (envelope-from oppermann@pipeline.ch) Received: (qmail 37444 invoked from network); 12 Nov 2003 10:39:21 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.54]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 12 Nov 2003 10:39:21 -0000 Message-ID: <3FB20D2B.73624906@pipeline.ch> Date: Wed, 12 Nov 2003 11:36:27 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: popsong old References: <20031112024507.89398.qmail@web10007.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: tcp hostcache and ip fastforward for review 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, 12 Nov 2003 10:36:31 -0000 popsong old wrote: > > --- Andre Oppermann wrote: > > > BTW, we'll get even better performance if we keep both > > > interfaces' MAC addresses in cache (and call > > > ifp->if_start directly). This requires to keep > > > ethernet header in mbuf untouched and is only relevant > > > in ethernet though. I implemented such layer 2 cache > > > in a local version of IPFilter and got some good > > > results. > > > > I don't understand why you want to do that unless you > > are doing bridging. We have to look up the mac address > > of the next hop anyway. If that is not already in the > > routing table it needs to do a arp lookup. > > > > -- > > Andre > > Ah, my fault. I didn't read your patch carefully and assumed that ip > fastforward do flow caching as ip_flow does. However, I think ip flow > caching is a good thing and maybe implementing it in ip fastforward is > a good idea. Please explain why flowcaching is good. Cisco did away with it quite some time ago because it didn't scale at all. Plus it is very complex in the context of the BSD network stack. For IP fastforward we look at one thing, that is the destination IP address. In a flow cache we need look at the destination IP address and the destination host. Then we have to make a hash based cache of size n. Problem number one: Is it really faster to look into the hash table than the routing table? Problem number two: Is there any caching effect at all in the hash table? Answer number one: No, it is not faster on today's hardware. And if we don't find it in the hash table we have to do the routing table lookup anyway. Answer number two: Unless you have only a couple of flows the hit rate is very low. If you have a couple of flows only then the routing table stays in L1/2 cache of the CPU anyway as does the routing table. No gain there. With too many flows you simply start thrashing the hash table for no benefit. -- Andre From owner-freebsd-net@FreeBSD.ORG Wed Nov 12 07:13:28 2003 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 427DF16A4CE for ; Wed, 12 Nov 2003 07:13:28 -0800 (PST) Received: from perrin.nxad.com (internal.nxad.com [69.1.70.251]) by mx1.FreeBSD.org (Postfix) with ESMTP id AFF5343FBF for ; Wed, 12 Nov 2003 07:13:27 -0800 (PST) (envelope-from hmp@nxad.com) Received: by perrin.nxad.com (Postfix, from userid 1072) id B34D02106F; Wed, 12 Nov 2003 07:13:07 -0800 (PST) Date: Wed, 12 Nov 2003 07:13:07 -0800 From: Hiten Pandya To: Ivan Boule Message-ID: <20031112151307.GA69141@perrin.nxad.com> References: <200310061345.h96Djgce016037@mail.Jaluna.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200310061345.h96Djgce016037@mail.Jaluna.COM> X-Operating-System: FreeBSD FreeBSD 4.7-STABLE User-Agent: Mutt/1.5.4i cc: freebsd-net@freebsd.org Subject: Re: Support for RFC2991/RFC2992 in freeBSD 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, 12 Nov 2003 15:13:28 -0000 On Mon, Oct 06, 2003 at 03:45:10PM +0200, Ivan Boule wrote: : I would like to know which freeBSD release includes support : for RFC2991/RFC2992 (multipath routing). : : More globally, it there a place where valuable information such as : "list of supported RFCs" is available for every freeBSD release? Late response (sigh); but check if the KAME developers (kame.net) have implemented this. They are pretty active... Regards, -- Hiten Pandya hmp@FreeBSD.ORG From owner-freebsd-net@FreeBSD.ORG Wed Nov 12 07:22:42 2003 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 38EB816A4CE for ; Wed, 12 Nov 2003 07:22:42 -0800 (PST) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8EC7843FAF for ; Wed, 12 Nov 2003 07:22:39 -0800 (PST) (envelope-from oppermann@pipeline.ch) Received: (qmail 91642 invoked from network); 12 Nov 2003 15:25:31 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 12 Nov 2003 15:25:31 -0000 Message-ID: <3FB2503E.53B21470@pipeline.ch> Date: Wed, 12 Nov 2003 16:22:38 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Hajimu UMEMOTO References: <3FAE68FB.64D262FF@pipeline.ch> <3FB129E1.5D8F4D16@pipeline.ch> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: mb@imp.ch cc: sam@errno.com Subject: Re: tcp hostcache and ip fastforward for review 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, 12 Nov 2003 15:22:42 -0000 Hajimu UMEMOTO wrote: > > Hi, > > >>>>> On Tue, 11 Nov 2003 19:26:41 +0100 > >>>>> Andre Oppermann said: > > oppermann> I have fixed the panic. It was a stupid braino in the test whether > oppermann> we have to free the allocated route. It was trying to free a null > oppermann> pointer route which obviously doesn't work. :-^ > > oppermann> The updated patch is here: > > oppermann> http://www.nrg4u.com/freebsd/tcphostcache+ipfastforward-20031111.patch > > oppermann> If you could try again please? > > It panics at another point on boot. > (kgdb) frame 24 > #24 0xc058e637 in tcp_hc_getmtu (inc=0x0) > at /usr/home/ume/cvs/freefall/current/src/sys/netinet/tcp_hostcache.c:420 > 420 hc_entry = tcp_hc_lookup(inc); > (kgdb) Ok, I found the bug. It was in the ipv6 hash function where I made a mistake with the hashmask. The updated patch is here: http://www.nrg4u.com/freebsd/tcphostcache+ipfastforward-20031112.patch Could you try again please? I have organized a second IPv6 capable machine (OpenBSD) for testing and I was able to ssh from my development machine to the OpenBSD via IPv6 tcp connection. I hope the last update has ironed out all ip6 bugs now. -- Andre From owner-freebsd-net@FreeBSD.ORG Wed Nov 12 08:45:53 2003 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 DB59616A4CE for ; Wed, 12 Nov 2003 08:45:53 -0800 (PST) Received: from blacklamb.mykitchentable.net (207-173-254-228.bras01.elk.ca.frontiernet.net [207.173.254.228]) by mx1.FreeBSD.org (Postfix) with ESMTP id E143F43FF9 for ; Wed, 12 Nov 2003 08:45:52 -0800 (PST) (envelope-from drew@mykitchentable.net) Received: from l035522 (unknown [165.107.42.110]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by blacklamb.mykitchentable.net (Postfix) with ESMTP id 41DFF3BF39E; Wed, 12 Nov 2003 08:45:51 -0800 (PST) Message-ID: <017901c3a93c$6ec7b6e0$6e2a6ba5@lc.ca.gov> From: "Drew Tomlinson" To: "Helge Oldach" , "Lars Eggert" , <"."@babolo.ru>, "Aaron Burke" , "Joshua Sahala" , "Lowell Gilbert" References: <022501c3a491$e46bf780$6e2a6ba5@lc.ca.gov> Date: Wed, 12 Nov 2003 08:45:50 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 cc: freebsd-net@freebsd.org Subject: Re: Routing With Two ISPs? 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, 12 Nov 2003 16:45:54 -0000 ----- Original Message ----- From: "Drew Tomlinson" Sent: Thursday, November 06, 2003 10:14 AM > I have a 4.8 box serving as a gateway with two connections to the > Internet. Is there some way to set the box up so that packets are > routed out through the same interface from which they arrived? For > example, if a connection is initiated on port 80 from a packet arriving > on one interface, is there a way to make the outgoing packets from my > web server use that same interface as a gateway instead of the default > interface? > > Any suggestions appreciated. Thank you to all that responded. Because of my unique situation that requires NAT to be run on the Linksys AP/router, and it's limitation of only forwarding to IP addresses in it's own subnet, I'm not sure if I will be able to accomplish my goal. However, I will try the suggestions and post my results over the next few weeks. I just wanted to acknowledge all that responded and say "thank you". Drew From owner-freebsd-net@FreeBSD.ORG Wed Nov 12 09:13:49 2003 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 263DB16A4CE for ; Wed, 12 Nov 2003 09:13:49 -0800 (PST) Received: from mailout06.sul.t-online.com (mailout06.sul.t-online.com [194.25.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF15D43FAF for ; Wed, 12 Nov 2003 09:13:47 -0800 (PST) (envelope-from Alexander@Leidinger.net) Received: from fwd02.aul.t-online.de by mailout06.sul.t-online.com with smtp id 1AJyYs-0002sR-07; Wed, 12 Nov 2003 18:13:46 +0100 Received: from Andro-Beta.Leidinger.net (SU1yc-ZfYeb5AjPg-ZrRNZ0RjbHTmS9EYgspgHp+Ah8oXAeyTiF3r0@[217.83.27.192]) by fmrl02.sul.t-online.com with esmtp id 1AJyYd-1YrtBY0; Wed, 12 Nov 2003 18:13:31 +0100 Received: from Magelan.Leidinger.net (Magellan [192.168.1.1]) hACHDPAR016490 for ; Wed, 12 Nov 2003 18:13:26 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from Magelan.Leidinger.net (netchild@localhost [127.0.0.1]) by Magelan.Leidinger.net (8.12.10/8.12.10) with SMTP id hACHDPot003318 for ; Wed, 12 Nov 2003 18:13:25 +0100 (CET) (envelope-from Alexander@Leidinger.net) Date: Wed, 12 Nov 2003 18:13:25 +0100 From: Alexander Leidinger To: net@freebsd.org Message-Id: <20031112181325.0d0fc62e.Alexander@Leidinger.net> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-portbld-freebsd5.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Seen: false X-ID: SU1yc-ZfYeb5AjPg-ZrRNZ0RjbHTmS9EYgspgHp+Ah8oXAeyTiF3r0@t-dialin.net Subject: how to debug the network stack? problems with an icc compiled kernel 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, 12 Nov 2003 17:13:49 -0000 Hi, please CC me, I'm not (yet) subscribed. I've booted a P4 with an icc compiled kernel, and the network is missing, even a ping to 127.0.0.1 doesn't work (no firewall). I see the outgoing echo requests with tcpdump, but that's all. Is someone out there who can guide me through the network stack or is someone willing to install an icc compiled kernel and debug it? Bye, Alexander. -- "One world, one web, one program" -- Microsoft promotional ad "Ein Volk, ein Reich, ein Fuehrer" -- Adolf Hitler http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 From owner-freebsd-net@FreeBSD.ORG Wed Nov 12 11:18:11 2003 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 A65CD16A4CE for ; Wed, 12 Nov 2003 11:18:11 -0800 (PST) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34B8043F75 for ; Wed, 12 Nov 2003 11:18:10 -0800 (PST) (envelope-from don@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2657.72) id ; Wed, 12 Nov 2003 14:18:08 -0500 Message-ID: From: Don Bowman To: "'freebsd-net@freebsd.org'" Date: Wed, 12 Nov 2003 14:18:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Subject: high number of pcb's, core dump in sysctl -a 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, 12 Nov 2003 19:18:11 -0000 net.inet.tcp.pcbcount: 76043 when i do 'sysctl net.inet.tcp', i get a core dump, while trying to read 'net.inet.tcp.pcblist'. Is there some built in limit to the size of a sysctl result? --don From owner-freebsd-net@FreeBSD.ORG Wed Nov 12 11:55:05 2003 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 EA44F16A4CE for ; Wed, 12 Nov 2003 11:55:05 -0800 (PST) Received: from mx01.bos.ma.towardex.com (a65-124-16-8.svc.towardex.com [65.124.16.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 33AFC43FDD for ; Wed, 12 Nov 2003 11:55:05 -0800 (PST) (envelope-from haesu@mx01.bos.ma.towardex.com) Received: by mx01.bos.ma.towardex.com (TowardEX ESMTP 3.0p11_DAKN, from userid 1001) id 6752B2F893; Wed, 12 Nov 2003 14:55:29 -0500 (EST) Date: Wed, 12 Nov 2003 14:55:29 -0500 From: Haesu To: Andre Oppermann , freebsd-net@freebsd.org Message-ID: <20031112195529.GA48020@scylla.towardex.com> References: <20031112024507.89398.qmail@web10007.mail.yahoo.com> <3FB20D2B.73624906@pipeline.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FB20D2B.73624906@pipeline.ch> User-Agent: Mutt/1.4.1i Subject: Re: tcp hostcache and ip fastforward for review 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, 12 Nov 2003 19:55:06 -0000 I agree in that flow cache is bad and it should not be used. It only takes x num. of kpps with diverse destinations to knock off a router running flow based caching. Extreme switches use flow based caching (called ipfdb) and any DoS attack that uses diverse destinations will kill it pretty quickly.. -hc -- Haesu C. TowardEX Technologies, Inc. Consulting, colocation, web hosting, network design and implementation http://www.towardex.com | haesu@towardex.com Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | POC: HAESU-ARIN On Wed, Nov 12, 2003 at 11:36:27AM +0100, Andre Oppermann wrote: > popsong old wrote: > > > > --- Andre Oppermann wrote: > > > > BTW, we'll get even better performance if we keep both > > > > interfaces' MAC addresses in cache (and call > > > > ifp->if_start directly). This requires to keep > > > > ethernet header in mbuf untouched and is only relevant > > > > in ethernet though. I implemented such layer 2 cache > > > > in a local version of IPFilter and got some good > > > > results. > > > > > > I don't understand why you want to do that unless you > > > are doing bridging. We have to look up the mac address > > > of the next hop anyway. If that is not already in the > > > routing table it needs to do a arp lookup. > > > > > > -- > > > Andre > > > > Ah, my fault. I didn't read your patch carefully and assumed that ip > > fastforward do flow caching as ip_flow does. However, I think ip flow > > caching is a good thing and maybe implementing it in ip fastforward is > > a good idea. > > Please explain why flowcaching is good. Cisco did away with it > quite some time ago because it didn't scale at all. Plus it is > very complex in the context of the BSD network stack. > > For IP fastforward we look at one thing, that is the destination IP > address. In a flow cache we need look at the destination IP address > and the destination host. Then we have to make a hash based cache > of size n. Problem number one: Is it really faster to look into the > hash table than the routing table? Problem number two: Is there any > caching effect at all in the hash table? Answer number one: No, it > is not faster on today's hardware. And if we don't find it in the > hash table we have to do the routing table lookup anyway. Answer > number two: Unless you have only a couple of flows the hit rate is > very low. If you have a couple of flows only then the routing table > stays in L1/2 cache of the CPU anyway as does the routing table. No > gain there. With too many flows you simply start thrashing the hash > table for no benefit. > > -- > Andre > _______________________________________________ > 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 Wed Nov 12 12:31:20 2003 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 EF1CE16A4CE; Wed, 12 Nov 2003 12:31:20 -0800 (PST) Received: from cheer.mahoroba.org (flets19-018.kamome.or.jp [218.45.19.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C9C943FE3; Wed, 12 Nov 2003 12:31:12 -0800 (PST) (envelope-from ume@mahoroba.org) Received: from mille.mahoroba.org (IDENT:6jncerZMCbYEeC1esOkVvRKkyXsVywPWWJeKNNqlj/i/0p/yLbuJyBjHKCCIGuBR@mille.mahoroba.org [IPv6:3ffe:501:185b:8010:202:2dff:fe41:8630]) (user=ume mech=CRAM-MD5 bits=0)hACKU4EU007926 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Nov 2003 05:30:05 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Thu, 13 Nov 2003 05:30:04 +0900 Message-ID: From: Hajimu UMEMOTO To: Andre Oppermann In-Reply-To: <3FB2503E.53B21470@pipeline.ch> References: <3FAE68FB.64D262FF@pipeline.ch> <3FB129E1.5D8F4D16@pipeline.ch> <3FB2503E.53B21470@pipeline.ch> User-Agent: xcite1.38> Wanderlust/2.11.0 (Wonderwall) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (=?ISO-2022-JP?B?GyRCOC1MWhsoQg==?=) X-Operating-System: FreeBSD 4.9-RELEASE MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.6 required=5.0 tests=DOMAIN_4U2 autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on cheer.mahoroba.org cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: mb@imp.ch cc: sam@errno.com Subject: Re: tcp hostcache and ip fastforward for review 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, 12 Nov 2003 20:31:21 -0000 Hi, >>>>> On Wed, 12 Nov 2003 16:22:38 +0100 >>>>> Andre Oppermann said: oppermann> Ok, I found the bug. It was in the ipv6 hash function where I made oppermann> a mistake with the hashmask. oppermann> The updated patch is here: oppermann> http://www.nrg4u.com/freebsd/tcphostcache+ipfastforward-20031112.patch oppermann> Could you try again please? It does repeatable panic. Unfortunately, my laptop hanguped during dumping core, and I couldn't get core. So, I copied the output from ddb by hand. Fatal trap 12: page fault while in kernel mode fault virtual address = 0x1c fault code = supervisor read, page not present instruction pointer = 0x8:0xc05b68c5 stack pointer = 0x10:0xd208ea28 frame pointer = 0x10:0xd208ea64 code segment = base 0x0, limit 0xffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 27 (swi1: net) kernel: type 12 trap, code=0 Stopped at in6_selecthlim+0x35: cmpl $0,0x1c(%esi) db> trace in6_selecthlim(0,0,28,0,fadd8ac9) at in6_selecthlim+0x35 syncache_respond(c3f6f000,c19a0600,1,c19a0600,0) at syncache_respond+0x31c syncache_add(d208eb80,d208ebf4,c1fc4836,d208eb4c,c19a0600) at syncache_add+0x4f4 tcp_input(c19a0600,28,0,d208ec40,6) at tcp_input+0xdae tcp6_input(d208ec84,d208ec60,6,d208ec84,28) at tcp6_input+0xf5 ip6_input(c19a0600,d018930f,39d40a1e,c0724474,0) at ip6_input+0xc18 netisr_processqueue(c06f0484,aa,7b1c1ccb,351110b4,c050250d) at netisr_processqueue+0xd9 swi_net(0,0,0,0,c199254c) at swi_net+0xd9 ithread_loop(c1988580,d208ed48,4d,55ff44fd,0) at ithread_loop+0x1d8 fork_exit(c04e4d90,c1988580,d208ed48) at fork_exit+0x80 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xd208ed7c, ebp = 0 --- db> Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@bisd.hitachi.co.jp ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-net@FreeBSD.ORG Wed Nov 12 12:40:35 2003 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 AEB3016A4CE for ; Wed, 12 Nov 2003 12:40:35 -0800 (PST) Received: from c7.campus.utcluj.ro (c7.campus.utcluj.ro [193.226.6.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 5D39B43F93 for ; Wed, 12 Nov 2003 12:40:32 -0800 (PST) (envelope-from veedee@c7.campus.utcluj.ro) Received: (qmail 377 invoked by uid 1008); 12 Nov 2003 20:40:31 -0000 From: veedee@c7.campus.utcluj.ro Date: Wed, 12 Nov 2003 22:40:31 +0200 To: freebsd-net@freebsd.org Message-ID: <20031112204031.GA333@c7.campus.utcluj.ro> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: SMC9452TX (Marvell chipset) supported? 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, 12 Nov 2003 20:40:35 -0000 Hellos, I just bought a SMC 9452TX card and got a little surprise. FreeBSD 4.9-STABLE doesn't recognize it. Is there any current support for it (an update to nge as nge seems to support SMC EZ Card 1000 (SMC9462TX)?), or are there any plans to integrate support for it in the future? I bought it hoping that NGE would work and I could get polling... For 55euros it was pretty cheap (probably even cheaper in other parts of the world). Guess I was wrong... :/ Thanks. PS. dmesg shows pci0: (vendor=0x11ab, dev=0x4320) at 9.0 irq 12 PPS. the chipset has a big M on it (Marvel?). I think it's safe to assume it's not a National Semiconductor on it? I also found some references at http://www.marvell.com/products/pcconn/yukon/88E8003.jsp... Yukon 88E8003. That's what I found writen on the chipset also. -- | Radu Bogdan 'veedee' Rusu | NetSysAdm at campus dot utcluj dot ro | Personal gallery at http://rrb.so.ro/gallery/ | ...mirroring FreeBSD and coffee From owner-freebsd-net@FreeBSD.ORG Wed Nov 12 12:49:50 2003 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 CF25C16A4CE for ; Wed, 12 Nov 2003 12:49:50 -0800 (PST) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id E822243FEA for ; Wed, 12 Nov 2003 12:49:47 -0800 (PST) (envelope-from oppermann@pipeline.ch) Received: (qmail 24248 invoked from network); 12 Nov 2003 20:52:39 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 12 Nov 2003 20:52:39 -0000 Message-ID: <3FB29CEA.1F5B9149@pipeline.ch> Date: Wed, 12 Nov 2003 21:49:46 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Hajimu UMEMOTO References: <3FAE68FB.64D262FF@pipeline.ch> <3FB129E1.5D8F4D16@pipeline.ch> <3FB2503E.53B21470@pipeline.ch> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: mb@imp.ch cc: sam@errno.com Subject: Re: tcp hostcache and ip fastforward for review 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, 12 Nov 2003 20:49:50 -0000 Hajimu UMEMOTO wrote: > > Hi, > > >>>>> On Wed, 12 Nov 2003 16:22:38 +0100 > >>>>> Andre Oppermann said: > > oppermann> Ok, I found the bug. It was in the ipv6 hash function where I made > oppermann> a mistake with the hashmask. > oppermann> The updated patch is here: > oppermann> http://www.nrg4u.com/freebsd/tcphostcache+ipfastforward-20031112.patch > oppermann> Could you try again please? > > It does repeatable panic. Unfortunately, my laptop hanguped during > dumping core, and I couldn't get core. So, I copied the output from > ddb by hand. -snip- > Stopped at in6_selecthlim+0x35: cmpl $0,0x1c(%esi) > db> trace > in6_selecthlim(0,0,28,0,fadd8ac9) at in6_selecthlim+0x35 > syncache_respond(c3f6f000,c19a0600,1,c19a0600,0) at syncache_respond+0x31c Grmpf... That is a logic error by me. Please add the following check on line 707 in the patched netinet6/in6_src.c: else if (in6p && !IN6_IS_ADDR_UNSPECIFIED(&in6p->in6p_faddr)) { ^^^^ ^^ Thank you for your effort in testing my changes! -- Andre From owner-freebsd-net@FreeBSD.ORG Wed Nov 12 13:12:09 2003 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 1C0C616A4CE for ; Wed, 12 Nov 2003 13:12:09 -0800 (PST) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id B3CCC43FA3 for ; Wed, 12 Nov 2003 13:12:07 -0800 (PST) (envelope-from jkim@niksun.com) Received: from daemon.mj.niksun.com (daemon.mj.niksun.com [10.70.0.244]) hACLBeuv092190; Wed, 12 Nov 2003 16:11:42 -0500 (EST) (envelope-from jkim@niksun.com) X-RAV-AntiVirus: This e-mail has been scanned for viruses. From: Jung-uk Kim Organization: Niksun, Inc. To: veedee@c7.campus.utcluj.ro, freebsd-net@freebsd.org Date: Wed, 12 Nov 2003 16:11:35 -0500 User-Agent: KMail/1.5.4 References: <20031112204031.GA333@c7.campus.utcluj.ro> In-Reply-To: <20031112204031.GA333@c7.campus.utcluj.ro> MIME-Version: 1.0 Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200311121611.35809.jkim@niksun.com> Subject: Re: SMC9452TX (Marvell chipset) supported? 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, 12 Nov 2003 21:12:09 -0000 On Wednesday 12 November 2003 03:40 pm, veedee@c7.campus.utcluj.ro wrote: > Hellos, > > I just bought a SMC 9452TX card and got a little surprise. FreeBSD > 4.9-STABLE doesn't recognize it. Is there any current support for > it (an update to nge as nge seems to support SMC EZ Card 1000 > (SMC9462TX)?), or are there any plans to integrate support for it > in the future? > > I bought it hoping that NGE would work and I could get polling... > For 55euros it was pretty cheap (probably even cheaper in other > parts of the world). Guess I was wrong... :/ > > Thanks. > > PS. dmesg shows > pci0: (vendor=0x11ab, dev=0x4320) at 9.0 irq 12 Use 'sk' driver. JK > PPS. the chipset has a big M on it (Marvel?). I think it's safe to > assume it's not a National Semiconductor on it? I also found some > references at > http://www.marvell.com/products/pcconn/yukon/88E8003.jsp... Yukon > 88E8003. That's what I found writen on the chipset also. From owner-freebsd-net@FreeBSD.ORG Wed Nov 12 13:24:22 2003 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 3D86716A4CF for ; Wed, 12 Nov 2003 13:24:22 -0800 (PST) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F19444017 for ; Wed, 12 Nov 2003 13:24:19 -0800 (PST) (envelope-from jkim@niksun.com) Received: from daemon.mj.niksun.com (daemon.mj.niksun.com [10.70.0.244]) hACLNZuv092515; Wed, 12 Nov 2003 16:23:35 -0500 (EST) (envelope-from jkim@niksun.com) X-RAV-AntiVirus: This e-mail has been scanned for viruses. From: Jung-uk Kim Organization: Niksun, Inc. To: veedee@c7.campus.utcluj.ro, freebsd-net@freebsd.org Date: Wed, 12 Nov 2003 16:23:30 -0500 User-Agent: KMail/1.5.4 References: <20031112204031.GA333@c7.campus.utcluj.ro> <200311121611.35809.jkim@niksun.com> In-Reply-To: <200311121611.35809.jkim@niksun.com> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_STqs/tT9NXi8A9B" Message-Id: <200311121623.30654.jkim@niksun.com> Subject: Re: SMC9452TX (Marvell chipset) supported? 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, 12 Nov 2003 21:24:22 -0000 --Boundary-00=_STqs/tT9NXi8A9B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Wednesday 12 November 2003 04:11 pm, Jung-uk Kim wrote: > > pci0: (vendor=0x11ab, dev=0x4320) at 9.0 irq 12 > > Use 'sk' driver. I am sorry that I made too quick conclusion. This one seems to use Marvell's vendor ID. Try the attached patch. Thanks, JK --Boundary-00=_STqs/tT9NXi8A9B Content-Type: text/plain; charset="euc-kr"; name="sk.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="sk.diff" --- src/sys/pci/if_sk.c.orig Tue Oct 14 14:22:42 2003 +++ src/sys/pci/if_sk.c Wed Nov 12 16:20:02 2003 @@ -148,6 +148,11 @@ "SysKonnect Gigabit Ethernet (V2.0)" }, { + VENDORID_MARVELL, + DEVICEID_SK_V2, + "Marvell Gigabit Ethernet" + }, + { VENDORID_3COM, DEVICEID_3COM_3C940, "3Com 3C940 Gigabit Ethernet" --- src/sys/pci/if_skreg.h.orig Tue Oct 14 19:22:55 2003 +++ src/sys/pci/if_skreg.h Wed Nov 12 16:20:19 2003 @@ -60,6 +60,11 @@ #define VENDORID_SK 0x1148 /* + * Marvell PCI vendor ID + */ +#define VENDORID_MARVELL 0x11AB + +/* * SK-NET gigabit ethernet device IDs */ #define DEVICEID_SK_V1 0x4300 --Boundary-00=_STqs/tT9NXi8A9B-- From owner-freebsd-net@FreeBSD.ORG Wed Nov 12 13:56:25 2003 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 7B7D216A4CF for ; Wed, 12 Nov 2003 13:56:25 -0800 (PST) Received: from c7.campus.utcluj.ro (c7.campus.utcluj.ro [193.226.6.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 0458943FE9 for ; Wed, 12 Nov 2003 13:56:24 -0800 (PST) (envelope-from veedee@c7.campus.utcluj.ro) Received: (qmail 385 invoked by uid 1008); 12 Nov 2003 21:56:22 -0000 From: veedee@c7.campus.utcluj.ro Date: Wed, 12 Nov 2003 23:56:22 +0200 To: Jung-uk Kim Message-ID: <20031112215622.GA347@c7.campus.utcluj.ro> References: <20031112204031.GA333@c7.campus.utcluj.ro> <200311121611.35809.jkim@niksun.com> <200311121623.30654.jkim@niksun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200311121623.30654.jkim@niksun.com> cc: freebsd-net@freebsd.org Subject: Re: SMC9452TX (Marvell chipset) supported? 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, 12 Nov 2003 21:56:25 -0000 On Wed, Nov 12, 2003 at 04:23:30PM -0500, Jung-uk Kim wrote: > On Wednesday 12 November 2003 04:11 pm, Jung-uk Kim wrote: > > > pci0: (vendor=0x11ab, dev=0x4320) at 9.0 irq 12 > > > > Use 'sk' driver. > > I am sorry that I made too quick conclusion. This one seems to use > Marvell's vendor ID. Try the attached patch. No problem. Thanks for the patch. It seems to work now! skc0: port 0xd000-0xd0ff mem 0xe9500000-0xe9503fff irq 12 at device 9.0 o n pci0 skc0: SMC EZ Card 1000 (SMC9452TX V.2) sk0: on skc0 sk0: Ethernet address: 00:04:e2:9a:46:9c miibus0: on sk0 e1000phy0: on miibus0 e1000phy0: 1000baseTX-FDX, 100baseTX-FDX, 100baseTX, 10baseTX-FDX, 10baseTX, auto Any ideas if sk will support polling anytime soon? > > Thanks, > > JK Thanks for the quick reply. -- | Radu Bogdan 'veedee' Rusu | NetSysAdm at campus dot utcluj dot ro | Personal gallery at http://rrb.so.ro/gallery/ | ...mirroring FreeBSD and coffee From owner-freebsd-net@FreeBSD.ORG Wed Nov 12 14:15:22 2003 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 BBF3416A4CE for ; Wed, 12 Nov 2003 14:15:22 -0800 (PST) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id C4C5543F85 for ; Wed, 12 Nov 2003 14:15:21 -0800 (PST) (envelope-from jkim@niksun.com) Received: from daemon.mj.niksun.com (daemon.mj.niksun.com [10.70.0.244]) hACMDhuv093745; Wed, 12 Nov 2003 17:13:43 -0500 (EST) (envelope-from jkim@niksun.com) X-RAV-AntiVirus: This e-mail has been scanned for viruses. From: Jung-uk Kim Organization: Niksun, Inc. To: veedee@c7.campus.utcluj.ro Date: Wed, 12 Nov 2003 17:13:39 -0500 User-Agent: KMail/1.5.4 References: <20031112204031.GA333@c7.campus.utcluj.ro> <200311121623.30654.jkim@niksun.com> <20031112215622.GA347@c7.campus.utcluj.ro> In-Reply-To: <20031112215622.GA347@c7.campus.utcluj.ro> MIME-Version: 1.0 Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200311121713.39187.jkim@niksun.com> cc: freebsd-net@freebsd.org Subject: Re: SMC9452TX (Marvell chipset) supported? 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, 12 Nov 2003 22:15:22 -0000 On Wednesday 12 November 2003 04:56 pm, veedee@c7.campus.utcluj.ro wrote: > On Wed, Nov 12, 2003 at 04:23:30PM -0500, Jung-uk Kim wrote: > > On Wednesday 12 November 2003 04:11 pm, Jung-uk Kim wrote: > > > > pci0: (vendor=0x11ab, dev=0x4320) at 9.0 irq > > > > 12 > > > > > > Use 'sk' driver. > > > > I am sorry that I made too quick conclusion. This one seems to > > use Marvell's vendor ID. Try the attached patch. > > No problem. Thanks for the patch. It seems to work now! > skc0: port 0xd000-0xd0ff mem > 0xe9500000-0xe9503fff irq 12 at device 9.0 o n pci0 > skc0: SMC EZ Card 1000 (SMC9452TX V.2) > sk0: on skc0 > sk0: Ethernet address: 00:04:e2:9a:46:9c > miibus0: on sk0 > e1000phy0: on miibus0 > e1000phy0: 1000baseTX-FDX, 100baseTX-FDX, 100baseTX, 10baseTX-FDX, > 10baseTX, auto I am glad that it worked. > Any ideas if sk will support polling anytime soon? I saw a patch was floating around in the mailing list long time ago but I cannot find it any more. If it is really important for you, it shouldn't be hard to implement it. > > Thanks, > > > > JK > > Thanks for the quick reply. No problem. JK From owner-freebsd-net@FreeBSD.ORG Wed Nov 12 14:53:30 2003 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 635A116A4CE; Wed, 12 Nov 2003 14:53:30 -0800 (PST) Received: from freesbee.wheel.dk (freesbee.wheel.dk [193.162.159.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B4CC43FB1; Wed, 12 Nov 2003 14:53:28 -0800 (PST) (envelope-from jesper@skriver.dk) Received: by freesbee.wheel.dk (Postfix, from userid 1001) id 91134384E7; Wed, 12 Nov 2003 23:53:26 +0100 (CET) Date: Wed, 12 Nov 2003 23:53:26 +0100 From: Jesper Skriver To: Andre Oppermann Message-ID: <20031112225326.GI41949@FreeBSD.org> Mail-Followup-To: Jesper Skriver , Andre Oppermann , freebsd-current@freebsd.org, freebsd-net@freebsd.org, sam@errno.com, mb@imp.ch, ume@freebsd.org References: <3FAE68FB.64D262FF@pipeline.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FAE68FB.64D262FF@pipeline.ch> User-Agent: Mutt/1.4.1i X-PGP-Fingerprint: 6B88 9CE8 66E9 E631 C9C5 5EB4 22AB F0EC F956 1C31 X-PGP-Public-Key: http://freesbee.wheel.dk/~jesper/gpgkey.pub cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: mb@imp.ch cc: ume@freebsd.org cc: sam@errno.com Subject: Re: tcp hostcache and ip fastforward for review 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, 12 Nov 2003 22:53:30 -0000 On Sun, Nov 09, 2003 at 05:19:07PM +0100, Andre Oppermann wrote: > Hello all, > > this patch contains three things (to be separated for committing): > > tcp_hostcache > > - removes protocol cloning from routing table (IPv4+6) > - removes rtentry pointer from inpcb and in6pcb > - removes ip route cache in ip_input.c (locking much easier) > - removes most (tcp specific) metrics from rtentry metrics > - adds a hostcache table which carries the metrics for tcp > - works transparently for IPv4 and IPv6 > - is designed for concurrent access in SMP environments > - significant reduction of routing table size (no cloning anymore) > - eases many routing table locking situations in ip/tcp code > > ip_fastforward > > - removes ip_flow forwarding code > - adds full direct process-to-completion IPv4 forwarding code > - handles ip fragmentation incl. hw support (ip_flow did not) > - supports ipfw and ipfilter (ip_flow did not) > - supports divert and ipfw fwd (ip_flow did not) > - drops anything it can't handle back to normal ip_input I have a few comments to this code, see inline, look for #jesper Apart from that it looks good. /Jesper > +int > +ip_fastforward(struct mbuf *m) > +{ > + struct ip *ip; > + struct mbuf *m0 = NULL; > +#ifdef IPDIVERT > + struct ip *tip; > + struct mbuf *teem = NULL; > +#endif > + struct mbuf *tag = NULL; > + struct route ro; > + struct sockaddr_in *dst = NULL; > + struct in_ifaddr *ia = NULL; > + struct ifaddr *ifa = NULL; > + struct ifnet *ifp = NULL; > + struct ip_fw_args args; > + in_addr_t odest, dest; > + u_short sum; > + int hlen; > + int error = 0; > + int ipfw; > + > + /* > + * Are we active and forwarding packets? > + */ > + if (!ipfastforward_active || !ipforwarding) > + return 0; > + > + /* > + * If there is any MT_TAG we fall back to ip_input because we can't > + * handle TAGs here. > + */ > + if (m && m->m_type == MT_TAG) > + return 0; > + > + M_ASSERTVALID(m); > + M_ASSERTPKTHDR(m); > + [...] > + > + /* > + * Only unicast IP, not from loopback, no L2 or IP broadcast, > + * no multicast, no INADDR_ANY > + */ > + if ((m->m_pkthdr.rcvif->if_flags & IFF_LOOPBACK) || > + (ntohl(ip->ip_src.s_addr) == (u_long)INADDR_BROADCAST) || #jesper You will never see packets with a multicast source address. > + (ntohl(ip->ip_dst.s_addr) == (u_long)INADDR_BROADCAST) || > + (IN_MULTICAST(ntohl(ip->ip_src.s_addr))) || > + (IN_MULTICAST(ntohl(ip->ip_dst.s_addr))) || > + (ip->ip_dst.s_addr == INADDR_ANY) ) > + goto fallback; > + > + /* > + * Is it for a local address on this host? > + */ > + LIST_FOREACH(ia, INADDR_HASH(ip->ip_dst.s_addr), ia_hash) { > + if (IA_SIN(ia)->sin_addr.s_addr == ip->ip_dst.s_addr) { > + goto fallback; > + } > + } > + > + /* > + * Or is it for a local IP broadcast address on this host? > + */ > + if (m->m_pkthdr.rcvif->if_flags & IFF_BROADCAST) { > + TAILQ_FOREACH(ifa, &m->m_pkthdr.rcvif->if_addrhead, ifa_link) { > + if (ifa->ifa_addr->sa_family != AF_INET) > + continue; > + ia = ifatoia(ifa); > + if (ia->ia_netbroadcast.s_addr == ip->ip_dst.s_addr) > + goto fallback; > + if (satosin(&ia->ia_broadaddr)->sin_addr.s_addr == > + ip->ip_dst.s_addr) > + goto fallback; > + continue; > +fallback: > + /* drop the packet back to netisr */ > + ip->ip_len = htons(ip->ip_len); > + ip->ip_off = htons(ip->ip_off); > + return 0; > + } > + } > + ipstat.ips_total++; #jesper If we stored special "for us" /32 routes in the routing table for addresses configured on this host, we could avoid the above 2 loops, which can quite expensive. These special routes will simply mean that the packet is for us, and needs to given to ip_input > + /** > + ** Third: incoming packet firewall processing > + **/ > + > + odest = dest = ip->ip_dst.s_addr; #jesper You could save a few cycles by doing #ifdef PFIL_HOOKS odest = ip->ip_dst.s_addr; /* * Run through list of ipfilter hooks for input packets */ if (pfil_run_hooks(&inet_pfil_hook, &m, m->m_pkthdr.rcvif, PFIL_IN) || m == NULL) return 1; M_ASSERTVALID(m); M_ASSERTPKTHDR(m); ip = mtod(m, struct ip *); /* if m changed during fw processing */ dest = ip->ip_dst.s_addr; #else odest = dest = ip->ip_dst.s_addr; #endif Thus avoiding writing to dest twice. > +#ifdef PFIL_HOOKS > + /* > + * Run through list of ipfilter hooks for input packets > + */ > + if (pfil_run_hooks(&inet_pfil_hook, &m, m->m_pkthdr.rcvif, PFIL_IN) || > + m == NULL) > + return 1; > + > + M_ASSERTVALID(m); > + M_ASSERTPKTHDR(m); > + > + ip = mtod(m, struct ip *); /* if m changed during fw processing */ > + dest = ip->ip_dst.s_addr; > +#endif > + > + /* > + * Run through ipfw for input packets > + */ > + if (fw_enable && IPFW_LOADED) { > + bzero(&args, sizeof(args)); > + args.m = m; > + ipfw = 0; > + > + ipfw = ip_fw_chk_ptr(&args); > + m = args.m; > + > + M_ASSERTVALID(m); > + M_ASSERTPKTHDR(m); > + > + /* > + * Packet denied, drop it > + */ > + if ( (ipfw & IP_FW_PORT_DENY_FLAG) || m == NULL) { > + if (m) > + m_freem(m); > + return 1; > + } > + /* > + * Send packet to the appropriate pipe > + */ > + if (DUMMYNET_LOADED && (ipfw & IP_FW_PORT_DYNT_FLAG) != 0) { #jesper Whitespace bug, spaces instead of tabs > + ip_dn_io_ptr(m, ipfw & 0xffff, DN_TO_IP_IN, &args); > + return 1; > + } > +#ifdef IPDIVERT > + /* > + * Divert packet > + */ > + if (ipfw != 0 && (ipfw & IP_FW_PORT_DYNT_FLAG) == 0) { > + /* > + * See if this is a fragment > + */ > + if (ip->ip_off & (IP_MF | IP_OFFMASK)) { > + MGETHDR(tag, M_DONTWAIT, MT_TAG); > + if (tag == NULL) { > + m_freem(m); > + return 1; > + } > + tag->m_flags = PACKET_TAG_DIVERT; > + tag->m_data = (caddr_t)(u_long)args.divert_rule; > + tag->m_next = m; > + m = tag; > + tag = NULL; > + > + goto droptoours; #jesper Whitespace bug, spaces instead of tabs > + } > + /* > + * Tee packet > + */ > + if ((ipfw & IP_FW_PORT_TEE_FLAG) != 0) > + teem = m_dup(m, M_DONTWAIT); > + else > + teem = m; > + if (teem == NULL) > + goto passin; > + > + M_ASSERTVALID(teem); > + M_ASSERTPKTHDR(teem); > + > + /* > + * Delayed checksums are not compatible > + */ > + if (teem->m_pkthdr.csum_flags & CSUM_DELAY_DATA) { > + in_delayed_cksum(teem); > + teem->m_pkthdr.csum_flags &= ~CSUM_DELAY_DATA; > + } > + /* > + * Restore packet header fields to original values > + */ > + tip = mtod(teem, struct ip *); > + tip->ip_len = htons(tip->ip_len); > + tip->ip_off = htons(tip->ip_off); > + /* > + * Deliver packet to divert input routine > + */ > + divert_packet(teem, 0, ipfw & 0xffff, args.divert_rule); > + /* > + * If this was not tee, we are done > + */ > + if ((ipfw & IP_FW_PORT_TEE_FLAG) == 0) > + return 1; > + /* Continue if it was tee */ > + goto passin; > + } > +#endif > + if (ipfw == 0 && args.next_hop != NULL) { > + dest = args.next_hop->sin_addr.s_addr; > + goto passin; > + } > + /* > + * Let through or not? > + */ > + if (ipfw != 0) { > + m_freem(m); > + return 1; > + } > + } > +passin: > + ip = mtod(m, struct ip *); /* if m changed during fw processing */ > + > + /* > + * Destination address changed? > + */ > + if (odest != dest) { > + /* > + * Is it now for a local address on this host? > + */ > + LIST_FOREACH(ia, INADDR_HASH(ip->ip_dst.s_addr), ia_hash) { > + if (IA_SIN(ia)->sin_addr.s_addr == ip->ip_dst.s_addr) > + goto forwardlocal; > + } #jesper Same comment as above - and do we really want to see if the original destination address was ours if we're doing NAT ? > + /* > + * Go on with new destination address > + */ > + } > + > + M_ASSERTVALID(m); > + M_ASSERTPKTHDR(m); > + > + /** > + ** Forth: decrement TTL and look up route > + **/ > + > + /* > + * Check TTL > + */ > +#ifdef IPSTEALTH > + if (!ipstealth) { > +#endif > + if (ip->ip_ttl <= IPTTLDEC) { > + icmp_error(m, ICMP_TIMXCEED, ICMP_TIMXCEED_INTRANS, NULL, NULL); > + return 1; > + } > + > + /* > + * Decrement the TTL and incrementally change the checksum. > + * Don't bother doing this with hw checksum offloading. > + */ > + ip->ip_ttl -= IPTTLDEC; > + if (ip->ip_sum >= (u_int16_t) ~htons(IPTTLDEC << 8)) > + ip->ip_sum -= ~htons(IPTTLDEC << 8); > + else > + ip->ip_sum += htons(IPTTLDEC << 8); > +#ifdef IPSTEALTH > + } > +#endif > + > + /* > + * Find route to destination. > + */ > + bzero(&ro, sizeof(ro)); > + dst = (struct sockaddr_in *)&ro.ro_dst; > + dst->sin_family = AF_INET; > + dst->sin_len = sizeof(*dst); > + dst->sin_addr.s_addr = dest; > + rtalloc(&ro); > + > + /* > + * Route there and interface still up? > + */ > + if ((ro.ro_rt) && > + (ro.ro_rt->rt_flags & RTF_UP) && > + (ro.ro_rt->rt_ifp->if_flags & IFF_UP)) { > + ia = ifatoia(ro.ro_rt->rt_ifa); > + ifp = ro.ro_rt->rt_ifp; > + if (ro.ro_rt->rt_flags & RTF_GATEWAY) > + dst = (struct sockaddr_in *)ro.ro_rt->rt_gateway; > + } else { > + ipstat.ips_noroute++; > + ipstat.ips_cantforward++; > + icmp_error(m, ICMP_UNREACH, ICMP_UNREACH_HOST, NULL, NULL); > + if (ro.ro_rt) > + RTFREE(ro.ro_rt); > + return 1; > + } > + > + > + /** > + ** Fifth: outgoing firewall packet processing > + **/ > + > +#ifdef PFIL_HOOKS > + /* > + * Run through list of hooks for output packets. > + */ > + if (pfil_run_hooks(&inet_pfil_hook, &m, ifp, PFIL_OUT) || > + m == NULL) { > + RTFREE(ro.ro_rt); > + return 1; > + } > + > + M_ASSERTVALID(m); > + M_ASSERTPKTHDR(m); > + > + ip = mtod(m, struct ip *); > + dest = ip->ip_dst.s_addr; > +#endif > + if (fw_enable && IPFW_LOADED && !args.next_hop) { > + bzero(&args, sizeof(args)); > + args.m = m; > + args.oif = ifp; > + ipfw = 0; > + > + ipfw = ip_fw_chk_ptr(&args); > + m = args.m; > + > + M_ASSERTVALID(m); > + M_ASSERTPKTHDR(m); > + > + if ( (ipfw & IP_FW_PORT_DENY_FLAG) || m == NULL) { > + if (m) > + m_freem(m); > + RTFREE(ro.ro_rt); > + return 1; > + } > + if (DUMMYNET_LOADED && (ipfw & IP_FW_PORT_DYNT_FLAG) != 0) { #jesper Whitespace bug, spaces instead of tabs > + /* > + * XXX note: if the ifp or rt entry are deleted > + * while a pkt is in dummynet, we are in trouble! > + */ > + args.ro = &ro; /* dummynet does not save it */ > + args.dst = dst; > + > + ip_dn_io_ptr(m, ipfw & 0xffff, DN_TO_IP_OUT, &args); > + RTFREE(ro.ro_rt); > + return 1; > + } > +#ifdef IPDIVERT > + if (ipfw != 0 && (ipfw & IP_FW_PORT_DYNT_FLAG) == 0) { > + /* > + * See if this is a fragment > + */ > + if (ip->ip_off & (IP_MF | IP_OFFMASK)) { > + MGETHDR(tag, M_DONTWAIT, MT_TAG); > + if (tag == NULL) { > + m_freem(m); > + RTFREE(ro.ro_rt); > + return 1; > + } > + tag->m_flags = PACKET_TAG_DIVERT; > + tag->m_data = (caddr_t)(u_int32_t)args.divert_rule; > + tag->m_next = m; > + m = tag; > + tag = NULL; > + > + goto droptoours; > + } > + /* > + * Tee packet > + */ > + if ((ipfw & IP_FW_PORT_TEE_FLAG) != 0) > + teem = m_dup(m, M_DONTWAIT); > + else > + teem = m; > + if (teem == NULL) > + goto passout; > + > + M_ASSERTVALID(m); > + M_ASSERTPKTHDR(m); > + > + /* > + * delayed checksums are not compatible with divert > + */ > + if (teem->m_pkthdr.csum_flags & CSUM_DELAY_DATA) { > + in_delayed_cksum(teem); > + teem->m_pkthdr.csum_flags &= ~CSUM_DELAY_DATA; > + } > + /* > + * Restore packet header fields to original values > + */ > + tip = mtod(teem, struct ip *); > + tip->ip_len = htons(tip->ip_len); > + tip->ip_off = htons(tip->ip_off); > + /* > + * Deliver packet to divert input routine > + */ > + divert_packet(teem, 0, ipfw & 0xffff, args.divert_rule); > + /* > + * If this was not tee, we are done > + */ > + if ((ipfw & IP_FW_PORT_TEE_FLAG) == 0) { > + RTFREE(ro.ro_rt); > + return 1; > + } > + /* Continue if it was tee */ > + goto passout; > + } > +#endif > + if (ipfw == 0 && args.next_hop != NULL) { > + dest = args.next_hop->sin_addr.s_addr; > + goto passout; > + } > + /* > + * Let through or not? > + */ > + if (ipfw != 0) { > + m_freem(m); > + return 1; > + } > + } > +passout: > + ip = mtod(m, struct ip *); > + > + /* > + * Destination address changed? > + */ > + if (odest != dest) { > + /* > + * Is it now for a local address on this host? > + */ #jesper Again, do we really want to look for packets destined for us after being translated ? > + LIST_FOREACH(ia, INADDR_HASH(ip->ip_dst.s_addr), ia_hash) { > + if (IA_SIN(ia)->sin_addr.s_addr == ip->ip_dst.s_addr) { > +forwardlocal: > + if(args.next_hop) { > + MGETHDR(tag, M_DONTWAIT, MT_TAG); > + if (tag == NULL) { > + m_freem(m); > + if(ro.ro_rt) > + RTFREE(ro.ro_rt); > + return 1; > + } > + tag->m_flags = PACKET_TAG_IPFORWARD; > + tag->m_data = (caddr_t)args.next_hop; > + tag->m_next = m; > + m = tag; > + tag = NULL; > + } > +#ifdef IPDIVERT > +droptoours: /* Used for DIVERT */ > +#endif > + MGETHDR(tag, M_DONTWAIT, MT_TAG); > + if (tag == NULL) { > + m_freem(m); > + if(ro.ro_rt) > + RTFREE(ro.ro_rt); > + return 1; > + } > + tag->m_flags = PACKET_TAG_IPFASTFWD_OURS; > + tag->m_data = NULL; > + tag->m_next = m; #jesper Whitespace bug, spaces instead of tabs > + m = tag; > + tag = NULL; > + > +#if 0 > + /* > + * Do some checks, we never know what fw has > + * done to it. > + */ > + if (m->m_pkthdr.rcvif == NULL) > + m->m_pkthdr.rcvif = ifunit("lo0"); > + if (m->m_pkthdr.csum_flags & CSUM_DELAY_DATA) { > + m->m_pkthdr.csum_flags |= > + CSUM_DATA_VALID | CSUM_PSEUDO_HDR; > + m->m_pkthdr.csum_data = 0xffff; > + } > + m->m_pkthdr.csum_flags |= > + CSUM_IP_CHECKED | CSUM_IP_VALID; > +#endif > + > + /* ip still points to the real packet */ > + ip->ip_len = htons(ip->ip_len); > + ip->ip_off = htons(ip->ip_off); > + > + M_ASSERTVALID(m); > + > + /* > + * Drop packet to ip_input > + */ > + if (ro.ro_rt) > + RTFREE(ro.ro_rt); > + return 0; > + } > + } > + /* > + * Redo route lookup with new destination address > + */ > + RTFREE(ro.ro_rt); > + bzero(&ro, sizeof(ro)); > + dst = (struct sockaddr_in *)&ro.ro_dst; > + dst->sin_family = AF_INET; > + dst->sin_len = sizeof(*dst); > + dst->sin_addr.s_addr = dest; > + rtalloc(&ro); > + > + /* > + * Route there and interface still up? > + */ > + if ((ro.ro_rt) && > + (ro.ro_rt->rt_flags & RTF_UP) && > + (ro.ro_rt->rt_ifp->if_flags & IFF_UP)) { > + ia = ifatoia(ro.ro_rt->rt_ifa); > + ifp = ro.ro_rt->rt_ifp; > + if (ro.ro_rt->rt_flags & RTF_GATEWAY) > + dst = (struct sockaddr_in *)ro.ro_rt->rt_gateway; > + } else { > + ipstat.ips_noroute++; > + ipstat.ips_cantforward++; > + icmp_error(m, ICMP_UNREACH, ICMP_UNREACH_HOST, NULL, NULL); > + if (ro.ro_rt) > + RTFREE(ro.ro_rt); > + return 1; > + } > + } > + > + M_ASSERTVALID(m); > + M_ASSERTPKTHDR(m); > + > + /** > + ** Sixth: send off the packet > + **/ > + > + /* > + * Check if packet fits MTU or if hardware will fragement for us > + */ > + if (ip->ip_len <= ifp->if_mtu || (ifp->if_hwassist & CSUM_FRAGMENT && > + ((ip->ip_off & IP_DF) == 0))) { > + /* > + * Restore packet header fields to original values > + */ > + ip->ip_len = htons(ip->ip_len); > + ip->ip_off = htons(ip->ip_off); > + /* > + * Send off the packet via outgoing interface > + */ > + error = (ifp->if_output)(ifp, m, (struct sockaddr *)dst, ro.ro_rt); > + if (ia) { > + ia->ia_ifa.if_opackets++; > + ia->ia_ifa.if_obytes += m->m_pkthdr.len; > + } > + } else { > + /* > + * Handle EMSGSIZE with icmp reply needfrag for TCP MTU discovery > + */ > + if (ip->ip_off & IP_DF) { > + icmp_error(m, ICMP_UNREACH, ICMP_UNREACH_NEEDFRAG, NULL, ifp); > + ipstat.ips_cantfrag++; > + RTFREE(ro.ro_rt); > + return 1; > + } else { > + /* > + * We have to fragement the packet > + */ > + m->m_pkthdr.csum_flags |= CSUM_IP; > + if (ip_fragment(ip, &m, ifp->if_mtu, ifp->if_hwassist, > + (~ifp->if_hwassist & CSUM_DELAY_IP))) { > + m_freem(m); > + RTFREE(ro.ro_rt); > + return 1; > + } > + /* > + * Send off the fragments via outgoing interface > + */ > + for (; m; m = m0) { > + m0 = m->m_nextpkt; > + m->m_nextpkt = 0; > + > + M_ASSERTVALID(m); > + M_ASSERTPKTHDR(m); > + > + if (error == 0) { > + error = (*ifp->if_output)(ifp, m, > + (struct sockaddr *)dst, ro.ro_rt); > + if (ia) { > + ia->ia_ifa.if_opackets++; > + ia->ia_ifa.if_obytes += m->m_pkthdr.len; > + } > + } else { > + m_freem(m); > + } > + } > + if (error == 0) > + ipstat.ips_fragmented++; > + } > + } > + > + if (error == ENOBUFS) > + ipstat.ips_odropped++; > + else if (error != 0) > + ipstat.ips_odropped++; > + else { > + ro.ro_rt->rt_rmx.rmx_pksent++; > + ipstat.ips_forward++; > + ipstat.ips_fastforward++; > + } > + RTFREE(ro.ro_rt); > + return 1; > +} > + From owner-freebsd-net@FreeBSD.ORG Wed Nov 12 15:13:19 2003 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 5D2E716A4D0 for ; Wed, 12 Nov 2003 15:13:19 -0800 (PST) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id B509543FA3 for ; Wed, 12 Nov 2003 15:13:15 -0800 (PST) (envelope-from oppermann@pipeline.ch) Received: (qmail 33232 invoked from network); 12 Nov 2003 23:16:07 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.54]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 12 Nov 2003 23:16:07 -0000 Message-ID: <3FB2BE8A.6C880085@pipeline.ch> Date: Thu, 13 Nov 2003 00:13:14 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jesper Skriver References: <3FAE68FB.64D262FF@pipeline.ch> <20031112225326.GI41949@FreeBSD.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: mb@imp.ch cc: ume@freebsd.org cc: sam@errno.com Subject: Re: tcp hostcache and ip fastforward for review 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, 12 Nov 2003 23:13:19 -0000 Jesper Skriver wrote: > > On Sun, Nov 09, 2003 at 05:19:07PM +0100, Andre Oppermann wrote: > > Hello all, > > > > this patch contains three things (to be separated for committing): ... > > ip_fastforward > > > > - removes ip_flow forwarding code > > - adds full direct process-to-completion IPv4 forwarding code > > - handles ip fragmentation incl. hw support (ip_flow did not) > > - supports ipfw and ipfilter (ip_flow did not) > > - supports divert and ipfw fwd (ip_flow did not) > > - drops anything it can't handle back to normal ip_input > > I have a few comments to this code, see inline, look for #jesper Answers also inline. [All whitespace bugs are fixed and omitted here] > Apart from that it looks good. Thanks for reviewing! > /Jesper > > > +int > > +ip_fastforward(struct mbuf *m) > > +{ ... > > + > > + /* > > + * Only unicast IP, not from loopback, no L2 or IP broadcast, > > + * no multicast, no INADDR_ANY > > + */ > > + if ((m->m_pkthdr.rcvif->if_flags & IFF_LOOPBACK) || > > + (ntohl(ip->ip_src.s_addr) == (u_long)INADDR_BROADCAST) || > > #jesper > You will never see packets with a multicast source address. I hope so but we can never be sure. Here we look at what we've got straight from the wire. Everything is possible there. I only need to craft an apropriate packet... > > + (ntohl(ip->ip_dst.s_addr) == (u_long)INADDR_BROADCAST) || > > + (IN_MULTICAST(ntohl(ip->ip_src.s_addr))) || > > + (IN_MULTICAST(ntohl(ip->ip_dst.s_addr))) || > > + (ip->ip_dst.s_addr == INADDR_ANY) ) > > + goto fallback; ... > > + /* > > + * Or is it for a local IP broadcast address on this host? > > + */ > > + if (m->m_pkthdr.rcvif->if_flags & IFF_BROADCAST) { > > + TAILQ_FOREACH(ifa, &m->m_pkthdr.rcvif->if_addrhead, ifa_link) { > > + if (ifa->ifa_addr->sa_family != AF_INET) > > + continue; > > + ia = ifatoia(ifa); > > + if (ia->ia_netbroadcast.s_addr == ip->ip_dst.s_addr) > > + goto fallback; > > + if (satosin(&ia->ia_broadaddr)->sin_addr.s_addr == > > + ip->ip_dst.s_addr) > > + goto fallback; > > + continue; > > +fallback: > > + /* drop the packet back to netisr */ > > + ip->ip_len = htons(ip->ip_len); > > + ip->ip_off = htons(ip->ip_off); > > + return 0; > > + } > > + } > > + ipstat.ips_total++; > > #jesper > If we stored special "for us" /32 routes in the routing table for > addresses configured on this host, we could avoid the above 2 loops, > which can quite expensive. Good idea. I will look at that after 5.2 code freeze. > These special routes will simply mean that the packet is for us, and > needs to given to ip_input > > > + /** > > + ** Third: incoming packet firewall processing > > + **/ > > + > > + odest = dest = ip->ip_dst.s_addr; > > #jesper > You could save a few cycles by doing Well, you're right. However I don't think it makes any difference and I'd like to keep it the current way for clarity and ease of reading and understanding the code. > #ifdef PFIL_HOOKS > odest = ip->ip_dst.s_addr; > /* > * Run through list of ipfilter hooks for input packets > */ > if (pfil_run_hooks(&inet_pfil_hook, &m, m->m_pkthdr.rcvif, PFIL_IN) || > m == NULL) > return 1; > > M_ASSERTVALID(m); > M_ASSERTPKTHDR(m); > > ip = mtod(m, struct ip *); /* if m changed during fw processing */ > dest = ip->ip_dst.s_addr; > #else > odest = dest = ip->ip_dst.s_addr; > #endif > > Thus avoiding writing to dest twice. > > > +#ifdef PFIL_HOOKS > > + /* > > + * Run through list of ipfilter hooks for input packets > > + */ > > + if (pfil_run_hooks(&inet_pfil_hook, &m, m->m_pkthdr.rcvif, PFIL_IN) || > > + m == NULL) > > + return 1; > > + > > + M_ASSERTVALID(m); > > + M_ASSERTPKTHDR(m); > > + > > + ip = mtod(m, struct ip *); /* if m changed during fw processing */ > > + dest = ip->ip_dst.s_addr; > > +#endif ... > > +passin: > > + ip = mtod(m, struct ip *); /* if m changed during fw processing */ > > + > > + /* > > + * Destination address changed? > > + */ > > + if (odest != dest) { > > + /* > > + * Is it now for a local address on this host? > > + */ > > + LIST_FOREACH(ia, INADDR_HASH(ip->ip_dst.s_addr), ia_hash) { > > + if (IA_SIN(ia)->sin_addr.s_addr == ip->ip_dst.s_addr) > > + goto forwardlocal; > > + } > > #jesper > > Same comment as above - and do we really want to see if the original > destination address was ours if we're doing NAT ? Yes, we have to do that for ipfw fwd and ipfilter address rewrite (from ipnat). It may be that the packet has been hijacked in a transparent proxy situation and has to be delivered to a local socket. > > + /* > > + * Go on with new destination address > > + */ ... > > + /* > > + * Destination address changed? > > + */ > > + if (odest != dest) { > > + /* > > + * Is it now for a local address on this host? > > + */ > > #jesper > > Again, do we really want to look for packets destined for us after being > translated ? Same answer as above. > > + LIST_FOREACH(ia, INADDR_HASH(ip->ip_dst.s_addr), ia_hash) { > > + if (IA_SIN(ia)->sin_addr.s_addr == ip->ip_dst.s_addr) { > > +forwardlocal: ... -- Andre From owner-freebsd-net@FreeBSD.ORG Wed Nov 12 15:23:47 2003 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 42D7516A4CE; Wed, 12 Nov 2003 15:23:47 -0800 (PST) Received: from freesbee.wheel.dk (freesbee.wheel.dk [193.162.159.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 21F4143F85; Wed, 12 Nov 2003 15:23:44 -0800 (PST) (envelope-from jesper@skriver.dk) Received: by freesbee.wheel.dk (Postfix, from userid 1001) id BD2793850A; Thu, 13 Nov 2003 00:23:41 +0100 (CET) Date: Thu, 13 Nov 2003 00:23:41 +0100 From: Jesper Skriver To: Andre Oppermann Message-ID: <20031112232341.GJ41949@skriver.dk> Mail-Followup-To: Jesper Skriver , Andre Oppermann , freebsd-current@freebsd.org, freebsd-net@freebsd.org, sam@errno.com, mb@imp.ch, ume@freebsd.org References: <3FAE68FB.64D262FF@pipeline.ch> <20031112225326.GI41949@FreeBSD.org> <3FB2BE8A.6C880085@pipeline.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FB2BE8A.6C880085@pipeline.ch> User-Agent: Mutt/1.4.1i X-PGP-Fingerprint: 6B88 9CE8 66E9 E631 C9C5 5EB4 22AB F0EC F956 1C31 X-PGP-Public-Key: http://freesbee.wheel.dk/~jesper/gpgkey.pub cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: mb@imp.ch cc: ume@freebsd.org cc: sam@errno.com Subject: Re: tcp hostcache and ip fastforward for review 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, 12 Nov 2003 23:23:47 -0000 On Thu, Nov 13, 2003 at 12:13:14AM +0100, Andre Oppermann wrote: > Jesper Skriver wrote: > > > > On Sun, Nov 09, 2003 at 05:19:07PM +0100, Andre Oppermann wrote: > > > Hello all, > > > > > > this patch contains three things (to be separated for committing): > ... > > > ip_fastforward > > > > > > - removes ip_flow forwarding code > > > - adds full direct process-to-completion IPv4 forwarding code > > > - handles ip fragmentation incl. hw support (ip_flow did not) > > > - supports ipfw and ipfilter (ip_flow did not) > > > - supports divert and ipfw fwd (ip_flow did not) > > > - drops anything it can't handle back to normal ip_input > > > > I have a few comments to this code, see inline, look for #jesper > > Answers also inline. [All whitespace bugs are fixed and omitted here] One comment at the bottom. > > Apart from that it looks good. > > Thanks for reviewing! > > > /Jesper > > > > > +int > > > +ip_fastforward(struct mbuf *m) > > > +{ > ... > > > + > > > + /* > > > + * Only unicast IP, not from loopback, no L2 or IP broadcast, > > > + * no multicast, no INADDR_ANY > > > + */ > > > + if ((m->m_pkthdr.rcvif->if_flags & IFF_LOOPBACK) || > > > + (ntohl(ip->ip_src.s_addr) == (u_long)INADDR_BROADCAST) || > > > > #jesper > > You will never see packets with a multicast source address. > > I hope so but we can never be sure. Here we look at what we've got > straight from the wire. Everything is possible there. I only need > to craft an apropriate packet... True, but do we really care if forwarded such a packet ? And if we want to check, we should just drop it directly instead of giving the packet to ip_input. /Jesper From owner-freebsd-net@FreeBSD.ORG Wed Nov 12 15:43:36 2003 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 E479616A4CF for ; Wed, 12 Nov 2003 15:43:35 -0800 (PST) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE90543FBF for ; Wed, 12 Nov 2003 15:43:32 -0800 (PST) (envelope-from oppermann@pipeline.ch) Received: (qmail 34994 invoked from network); 12 Nov 2003 23:46:24 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.54]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 12 Nov 2003 23:46:24 -0000 Message-ID: <3FB2C5A3.E6F33B07@pipeline.ch> Date: Thu, 13 Nov 2003 00:43:31 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jesper Skriver References: <3FAE68FB.64D262FF@pipeline.ch> <20031112225326.GI41949@FreeBSD.org> <3FB2BE8A.6C880085@pipeline.ch> <20031112232341.GJ41949@skriver.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: mb@imp.ch cc: ume@freebsd.org cc: sam@errno.com Subject: Re: tcp hostcache and ip fastforward for review 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, 12 Nov 2003 23:43:36 -0000 Jesper Skriver wrote: > > On Thu, Nov 13, 2003 at 12:13:14AM +0100, Andre Oppermann wrote: > > Jesper Skriver wrote: > > > > > > On Sun, Nov 09, 2003 at 05:19:07PM +0100, Andre Oppermann wrote: > > > > Hello all, > > > > > > > > this patch contains three things (to be separated for committing): > > ... > > > > ip_fastforward > > > > > > > > - removes ip_flow forwarding code > > > > - adds full direct process-to-completion IPv4 forwarding code > > > > - handles ip fragmentation incl. hw support (ip_flow did not) > > > > - supports ipfw and ipfilter (ip_flow did not) > > > > - supports divert and ipfw fwd (ip_flow did not) > > > > - drops anything it can't handle back to normal ip_input > > > > > > I have a few comments to this code, see inline, look for #jesper > > > > Answers also inline. [All whitespace bugs are fixed and omitted here] > > One comment at the bottom. > > > > Apart from that it looks good. > > > > Thanks for reviewing! > > > > > /Jesper > > > > > > > +int > > > > +ip_fastforward(struct mbuf *m) > > > > +{ > > ... > > > > + > > > > + /* > > > > + * Only unicast IP, not from loopback, no L2 or IP broadcast, > > > > + * no multicast, no INADDR_ANY > > > > + */ > > > > + if ((m->m_pkthdr.rcvif->if_flags & IFF_LOOPBACK) || > > > > + (ntohl(ip->ip_src.s_addr) == (u_long)INADDR_BROADCAST) || > > > > > > #jesper > > > You will never see packets with a multicast source address. > > > > I hope so but we can never be sure. Here we look at what we've got > > straight from the wire. Everything is possible there. I only need > > to craft an apropriate packet... > > True, but do we really care if forwarded such a packet ? Yes, never forward anything that should not be. Stop the problem right here instead of letting it become a problem somewhere else. > And if we want to check, we should just drop it directly instead of > giving the packet to ip_input. Makes sense. Can we ever have a packet that has a source address with INADDR_BROADCAST or IN_MULTICAST? I can't think of such a case. Can we ever have a packet with destination address INADDR_ANY? Maybe for BOOTP? But then the source address would be 0.0.0.0 too? With fallback to ip_input() in all those cases I wanted to make sure that I don't break any obscure hack or protocol I didn't think of. -- Andre From owner-freebsd-net@FreeBSD.ORG Wed Nov 12 18:06:12 2003 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 A608316A4CF for ; Wed, 12 Nov 2003 18:06:12 -0800 (PST) Received: from jchurch.neville-neil.com (jchurch.neville-neil.com [209.157.133.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id A3C8243FAF for ; Wed, 12 Nov 2003 18:06:11 -0800 (PST) (envelope-from gnn@neville-neil.com) Received: from jchurch.neville-neil.com.neville-neil.com (localhost [127.0.0.1])hAD26ACm025887 for ; Wed, 12 Nov 2003 18:06:10 -0800 (PST) (envelope-from gnn@neville-neil.com) Date: Wed, 12 Nov 2003 18:06:10 -0800 Message-ID: <87r80dqay5.wl@jchurch.neville-neil.com.neville-neil.com> From: "George V. Neville-Neil" To: freebsd-net@freebsd.org User-Agent: Wanderlust/2.10.0 (Venus) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (=?ISO-8859-4?Q?Kashiharajing=FE-mae?=) APEL/10.4 Emacs/21.2 (i386--freebsd) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Subject: Is this a 64 bit bug? 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, 13 Nov 2003 02:06:12 -0000 Hi Folks, While wandering through -CURRENT last night I found that icmp_error() passes the destination address as a plain n_long. Won't this cause problems on 64 bit architectures? Shouldn't this be a sockaddr of some flavor? Thanks, George From owner-freebsd-net@FreeBSD.ORG Wed Nov 12 20:07:40 2003 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 2C1FC16A4CE; Wed, 12 Nov 2003 20:07:40 -0800 (PST) Received: from swin.edu.au (c3p0.cc.swin.edu.au [136.186.1.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 68D4B44001; Wed, 12 Nov 2003 20:07:37 -0800 (PST) (envelope-from pvandenbergen@swin.edu.au) Received: from pvdbergen.caia.swin.edu.au (pvdbergen.caia.swin.edu.au [136.186.229.26]) by swin.edu.au (8.9.3p2-20030918/8.9.3) with ESMTP id PAA627810; Thu, 13 Nov 2003 15:07:36 +1100 (EST) From: paul van den bergen To: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org, hardware@freebsd.org Date: Thu, 13 Nov 2003 15:07:36 +1100 User-Agent: KMail/1.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200311131507.36373.pvandenbergen@swin.edu.au> Subject: WiFi intermittant cutout - IPv6 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, 13 Nov 2003 04:07:40 -0000 Hi all, I've noticed some odd and frustrating behaviour and am looking for some help. I have a 3 network setup for MIP6 (aka Kame snap of a few weeks ago). consider one section of the network. CN (host) <-> fec0:200:: <-> HN (router) <-> fec0:10:: <-> MN (host) the fec0:10:: network is an 802.11b network. I can either set it up as an AP based connection e.g. HN - wi0 - - - - AP - - - - an0 - MN or as an adhoc connection HN - wi0 - - - - - - an0 - MN for some reason, every now and again, the connectivity between the two ends drops off, with either a No route to host or ping rejection, depending which side of the remote host I am pinging... this is independant of adhoc or AP sometimes I can get the network connected by doing wicontrol -c 1 or some such - starting tcpdump on the an0 interface after starting the pings seems guarenteed to kill connectivity. but starting tcpdump ahead of time mostly doesn't. the hosts are accepting rtadv and the routers are forwarding ipv6 traffic. the same behaviour if I set up IPv4... HN wicontrol output NIC serial number: [ 99SA01000000 ] Station name: [ HomeNet ] SSID for IBSS creation: [ MAGIC-ADHOC ] Current netname (SSID): [ MAGIC-ADHOC ] Desired netname (SSID): [ MAGIC-ADHOC ] Current BSSID: [ 62:00:e6:00:06:01 ] Channel list: [ 2047 ] IBSS channel: [ 1 ] Current channel: [ 1 ] Comms quality/signal/noise: [ 92 154 13 ] Promiscuous mode: [ Off ] Process 802.11b Frame: [ Off ] Intersil-Prism2 based card: [ 1 ] Port type (1=BSS, 3=ad-hoc): [ 3 ] MAC address: [ 00:30:ab:20:a2:4c ] TX rate (selection): [ 3 ] TX rate (actual speed): [ 11 ] RTS/CTS handshake threshold: [ 2347 ] Create IBSS: [ Off ] Access point density: [ 1 ] Power Mgmt (1=on, 0=off): [ 0 ] Max sleep time: [ 100 ] WEP encryption: [ Off ] TX encryption key: [ 1 ] Encryption keys: [ ][ ][ ][ ] MN ancontrol -C output Operating mode: [ ad-hoc ] Receive mode: [ broadcast/multicast/unicast ] Fragment threshold: [ 2312 ] RTS threshold: [ 2312 ] MAC address: [ 00:09:7c:85:82:74 ] Supported rates: [ 1.0Mbps 2.0Mbps 5.5Mbps 11.0Mbps ] Short retry limit: [ 16 ] Long retry limit: [ 16 ] TX MSDU lifetime: [ 5000 ] RX MSDU lifetime: [ 10000 ] Stationary: [ Off ] Ordering: [ Off ] Device type: [ unknown (7f) ] Scanning mode: [ active ] Probe delay: [ 3 ] Probe energy timeout: [ 3 ] Probe response timeout: [ 20 ] Beacon listen timeout: [ 40 ] IBSS join network timeout: [ 10000 ] Authentication timeout: [ 2000 ] WEP enabled: [ no ] Authentication type: [ open ] Association timeout: [ 5000 ] Specified AP association timeout: [ 10000 ] Offline scan interval: [ 0 ] Offline scan duration: [ 0 ] Link loss delay: [ 0 ] Max beacon loss time: [ 500 ] Refresh interval: [ 10000 ] Power save mode: [ none ] Sleep through DTIMs: [ Off ] Power save listen interval: [ 200 ] Power save fast listen interval: [ 100 ] Power save listen decay: [ 2 ] Power save fast listen decay: [ 200 ] AP/ad-hoc Beacon period: [ 100 ] AP/ad-hoc ATIM duration: [ 0 ] AP/ad-hoc current channel: [ 1 ] AP/ad-hoc DTIM period: [ 1 ] Radio type: [ 802.11 DS ] RX Diversity: [ antenna 1 and 2 ] TX Diversity: [ antenna 1 and 2 ] Transmit power level: [ 100 ] RSS threshold: [ 0 ] Node name: [ MobileNode ] ARL threshold: [ 65535 ] ARL decay: [ 65535 ] ARL delay: [ 65535 ] Configuration: [ Enterprise Configuration ] WEP Key status: The active transmit key is 0 any idea why my network is goign up and down? -- Dr Paul van den Bergen Centre for Advanced Internet Architectures caia.swin.edu.au pvandenbergen@swin.edu.au IM:bulwynkl2002 "And some run up hill and down dale, knapping the chucky stones to pieces wi' hammers, like so many road makers run daft. They say it is to see how the world was made." Sir Walter Scott, St. Ronan's Well 1824 From owner-freebsd-net@FreeBSD.ORG Wed Nov 12 23:17:08 2003 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 9EDDB16A4CE for ; Wed, 12 Nov 2003 23:17:08 -0800 (PST) Received: from c7.campus.utcluj.ro (c7.campus.utcluj.ro [193.226.6.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 1321643F85 for ; Wed, 12 Nov 2003 23:17:07 -0800 (PST) (envelope-from veedee@c7.campus.utcluj.ro) Received: (qmail 7591 invoked by uid 1008); 13 Nov 2003 07:17:05 -0000 From: veedee@c7.campus.utcluj.ro Date: Thu, 13 Nov 2003 09:17:05 +0200 To: Jung-uk Kim Message-ID: <20031113071705.GB7378@c7.campus.utcluj.ro> References: <20031112204031.GA333@c7.campus.utcluj.ro> <200311121623.30654.jkim@niksun.com> <20031112215622.GA347@c7.campus.utcluj.ro> <200311121713.39187.jkim@niksun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200311121713.39187.jkim@niksun.com> cc: freebsd-net@freebsd.org Subject: Re: SMC9452TX (Marvell chipset) supported? 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, 13 Nov 2003 07:17:08 -0000 On Wed, Nov 12, 2003 at 05:13:39PM -0500, Jung-uk Kim wrote: > On Wednesday 12 November 2003 04:56 pm, veedee@c7.campus.utcluj.ro > wrote: > > On Wed, Nov 12, 2003 at 04:23:30PM -0500, Jung-uk Kim wrote: > > > On Wednesday 12 November 2003 04:11 pm, Jung-uk Kim wrote: > > > > > pci0: (vendor=0x11ab, dev=0x4320) at 9.0 irq > > > > > 12 > > > > > > > > Use 'sk' driver. > > > > > > I am sorry that I made too quick conclusion. This one seems to > > > use Marvell's vendor ID. Try the attached patch. > > > > No problem. Thanks for the patch. It seems to work now! > > skc0: port 0xd000-0xd0ff mem > > 0xe9500000-0xe9503fff irq 12 at device 9.0 o n pci0 > > skc0: SMC EZ Card 1000 (SMC9452TX V.2) > > sk0: on skc0 > > sk0: Ethernet address: 00:04:e2:9a:46:9c > > miibus0: on sk0 > > e1000phy0: on miibus0 > > e1000phy0: 1000baseTX-FDX, 100baseTX-FDX, 100baseTX, 10baseTX-FDX, > > 10baseTX, auto > > I am glad that it worked. > > > Any ideas if sk will support polling anytime soon? > > I saw a patch was floating around in the mailing list long time ago > but I cannot find it any more. If it is really important for you, it > shouldn't be hard to implement it. Sure it is. Less CPU usage with polling on high "traffic". Ok, I'll try to search for it. If you find the patch by mistake, please let me know. Thanks. > > JK > -- | Radu Bogdan 'veedee' Rusu | NetSysAdm at campus dot utcluj dot ro | Personal gallery at http://rrb.so.ro/gallery/ | ...mirroring FreeBSD and coffee From owner-freebsd-net@FreeBSD.ORG Thu Nov 13 00:05:29 2003 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 80FA916A4CE for ; Thu, 13 Nov 2003 00:05:29 -0800 (PST) Received: from pasmtp.tele.dk (pasmtp.tele.dk [193.162.159.95]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8575143FF2 for ; Thu, 13 Nov 2003 00:05:28 -0800 (PST) (envelope-from krask@isupport.dk) Received: from pc100 (0x50a3814c.unknown.tele.dk [80.163.129.76]) by pasmtp.tele.dk (Postfix) with SMTP id DF9BD1EC379 for ; Thu, 13 Nov 2003 09:05:26 +0100 (CET) Message-ID: <001501c3a9bc$e24abb00$0a01a8c0@esesecurity.lan> From: "Kristian Rask" To: Date: Thu, 13 Nov 2003 09:05:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: multiple VLAN's public IP's and NATd's : HowTo ? 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, 13 Nov 2003 08:05:29 -0000 Hi all How would one go about running several instances of natd with unique = public IP's for several VLAN's terminated on the same interface ? The idea being that multiple seperate RFC-1918 networks are terminated as VLANS in the FreeBSD machine and that each VLAN goes through a seperate NAT'd instance in order to NAT on a particular public IP. 1. House full of businesses.. (here shown w. 5/8) 2. Each buisiness has it's own LAN 3. Each LAN goes into a switch where the port is configured as a = particular LAN 4. The switch is connected to a FreeBSD machine w. a set of VLAN's matching those in the seperate businesses 5. There should be 1 instance of NATd running for each VLAN 6. Each NATd uses seperate public IP's 7. WAN Staticly configured using a /30 8. /29 net for 5/8 seperate NATd's (a.b.c.0/29) routed to the wan. 9. possibly "ifconfig SomePhysIf0 a.b.c.1/29" I think for 5 IP's it would be something like: for i in 2 3 4 5 6; do natd -port 100${i} \ -f /etc/natd_${i}.conf \ -n \ -a a.b.c.${i} done for i in 2 3 4 5 6; do ipfw add divert 100${i} all ....=20 (from VLAN-if | VLAN-CIDR | ... ?)=20 to any ...(in via VLAN-if | out via WAN-if | .... ?) done i *assume* i need to configure the /29 somewhere .. i *suspect* that i can do something "weird" and actually use all 8 IP's ... perhaps configure the 8 IP's as aliases on lo ? we will have more than a few addresses in order to be able to deliver routeable addresses if anyone so requests.. like.. a /26 of wich we use a /28 for permanent IP's and can deliver 6 /29 for the few who actually needs a routable network. anyone has any experiences or hints / pointers ? TIA and regards Kristian aka The eternal newbie From owner-freebsd-net@FreeBSD.ORG Thu Nov 13 02:26:48 2003 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 6ADF316A4CE for ; Thu, 13 Nov 2003 02:26:48 -0800 (PST) Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id C28AE43FDF for ; Thu, 13 Nov 2003 02:26:45 -0800 (PST) (envelope-from ru@sunbay.com) Received: from whale.sunbay.crimea.ua (ru@localhost [127.0.0.1]) hADAQgsw000816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Nov 2003 12:26:42 +0200 (EET) (envelope-from ru@sunbay.com) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.12.9p2/8.12.9/Submit) id hADAQesD000811; Thu, 13 Nov 2003 12:26:40 +0200 (EET) (envelope-from ru) Date: Thu, 13 Nov 2003 12:26:40 +0200 From: Ruslan Ermilov To: Kristian Rask Message-ID: <20031113102640.GB99572@sunbay.com> References: <001501c3a9bc$e24abb00$0a01a8c0@esesecurity.lan> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="v9Ux+11Zm5mwPlX6" Content-Disposition: inline In-Reply-To: <001501c3a9bc$e24abb00$0a01a8c0@esesecurity.lan> User-Agent: Mutt/1.5.5.1i cc: freebsd-net@freebsd.org Subject: Re: multiple VLAN's public IP's and NATd's : HowTo ? 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, 13 Nov 2003 10:26:48 -0000 --v9Ux+11Zm5mwPlX6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 13, 2003 at 09:05:11AM +0100, Kristian Rask wrote: > Hi all >=20 > How would one go about running several instances of natd with unique > public IP's for several VLAN's terminated on the same interface ? >=20 How this is different from having several LANs (NICs) connected to one central hub, and running multiple natd(8)'s on them? Cheers, --=20 Ruslan Ermilov Sysadmin and DBA, ru@sunbay.com Sunbay Software Ltd, ru@FreeBSD.org FreeBSD committer --v9Ux+11Zm5mwPlX6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/s1xgUkv4P6juNwoRAhzFAJ9o9Wx/k4wNRaeFz8Y6OrXT7ioJ1QCfQJr3 9BY5J5H+LGMUbxgTCYY9GMM= =qwhR -----END PGP SIGNATURE----- --v9Ux+11Zm5mwPlX6-- From owner-freebsd-net@FreeBSD.ORG Thu Nov 13 04:56:16 2003 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 EB88516A4CE for ; Thu, 13 Nov 2003 04:56:16 -0800 (PST) Received: from paf.se (argc.paf.se [195.66.31.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1428143F75 for ; Thu, 13 Nov 2003 04:56:15 -0800 (PST) (envelope-from anders@lowinger.se) Received: by paf.se (CommuniGate Pro PIPE 4.1) with PIPE id 1232099; Thu, 13 Nov 2003 13:57:28 +0100 Received: from [62.119.74.3] (account anders@lowinger.se HELO lowinger.se) by paf.se (CommuniGate Pro SMTP 4.1) with ESMTP id 1232097; Thu, 13 Nov 2003 13:56:41 +0100 Message-ID: <3FB37F09.4050908@lowinger.se> Date: Thu, 13 Nov 2003 13:54:33 +0100 From: Anders Lowinger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031110 Thunderbird/0.4a X-Accept-Language: en-us, en MIME-Version: 1.0 To: Haesu References: <20031112024507.89398.qmail@web10007.mail.yahoo.com> <3FB20D2B.73624906@pipeline.ch> <20031112195529.GA48020@scylla.towardex.com> In-Reply-To: <20031112195529.GA48020@scylla.towardex.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-6.0 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: freebsd-net@freebsd.org Subject: Re: tcp hostcache and ip fastforward for review 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, 13 Nov 2003 12:56:17 -0000 Haesu wrote: > I agree in that flow cache is bad and it should not be used. Everything is not black or white. A flow cache can accelerate for example Access Control Lists and/or firewalling, since only the first packet needs to be verified. Cisco just added ACL bypass for firewall, which is a similar feature. http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_feature_guide09186a00801d33da.html > It only takes x num. of kpps with diverse destinations to knock off a router running flow based caching. Yep, that is true and its hard to work around. > Extreme switches use flow based caching (called ipfdb) and any DoS attack that uses > diverse destinations will kill it pretty quickly.. Cisco's newer stuff does the flow-cache independent of the forwarding, i.e. the flow is more of an accounting cache. --Anders, not affiliated with Cisco From owner-freebsd-net@FreeBSD.ORG Thu Nov 13 05:50:33 2003 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 1F5AF16A4CE for ; Thu, 13 Nov 2003 05:50:33 -0800 (PST) Received: from mail.vineyard.net (k1.vineyard.net [204.17.195.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9F5843FA3 for ; Thu, 13 Nov 2003 05:50:31 -0800 (PST) (envelope-from ericx_lists@vineyard.net) Received: from localhost (loopback [127.0.0.1]) by mail.vineyard.net (Postfix) with ESMTP id 1FE599279F; Thu, 13 Nov 2003 08:50:31 -0500 (EST) Received: from mail.vineyard.net ([127.0.0.1]) by localhost (king1.vineyard.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92629-09; Thu, 13 Nov 2003 08:50:30 -0500 (EST) Received: from fortiva (fortiva.vineyard.net [204.17.195.104]) by mail.vineyard.net (Postfix) with SMTP id C29729279E; Thu, 13 Nov 2003 08:50:30 -0500 (EST) Message-ID: <171c01c3a9ec$f9c79b10$68c311cc@fortiva> From: "Eric W. Bates" To: "Kristian Rask" References: <001501c3a9bc$e24abb00$0a01a8c0@esesecurity.lan> Date: Thu, 13 Nov 2003 08:49:35 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: by AMaViS at Vineyard.NET cc: freebsd-net@freebsd.org Subject: Re: multiple VLAN's public IP's and NATd's : HowTo ? 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, 13 Nov 2003 13:50:33 -0000 X-List-Received-Date: Thu, 13 Nov 2003 13:50:33 -0000 VGhlcmUgd2FzIGEgdGhyZWFkIG9uIHRoaXMgbGlzdCBhYm91dCBob3cgdG8gZG8gbXVsdGlwbGUg bmF0J3RpbmdzIGxlc3MgdGhhbiBhIHllYXIgYWdvLg0KDQpSdW4geW91ciBuYXRkJ3Mgb24gc2Vw YXJhdGUgcG9ydHMuDQpHZXQgaXBmdyB0byBkbyBsb3RzIG9mIGxvZ2dpbmcuIChkb24ndCBtYWtl IHRoZSBtaXN0YWtlIG9mIGhhdmluZyBuYXRkIGxvZzogYWxsIGluc3RhbmNlcyB0cnkgdG8gb3Bl biB0aGUgc2FtZSBsb2cgZmlsZSBwYXRoKQ0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0t IA0KRnJvbTogIktyaXN0aWFuIFJhc2siIDxrcmFza0Bpc3VwcG9ydC5kaz4NClRvOiA8ZnJlZWJz ZC1uZXRAZnJlZWJzZC5vcmc+DQpTZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgMTMsIDIwMDMgMzow NSBBTQ0KU3ViamVjdDogbXVsdGlwbGUgVkxBTidzIHB1YmxpYyBJUCdzIGFuZCBOQVRkJ3MgOiBI b3dUbyA/DQoNCg0KSGkgYWxsDQoNCkhvdyB3b3VsZCBvbmUgZ28gYWJvdXQgcnVubmluZyBzZXZl cmFsIGluc3RhbmNlcyBvZiBuYXRkIHdpdGggdW5pcXVlIHB1YmxpYyBJUCdzIGZvciBzZXZlcmFs IFZMQU4ncyB0ZXJtaW5hdGVkIG9uIHRoZSBzYW1lIGludGVyZmFjZSA/DQoNClRoZSBpZGVhIGJl aW5nIHRoYXQgbXVsdGlwbGUgc2VwZXJhdGUgUkZDLTE5MTggbmV0d29ya3MgYXJlDQp0ZXJtaW5h dGVkIGFzIFZMQU5TIGluIHRoZSBGcmVlQlNEIG1hY2hpbmUgYW5kIHRoYXQNCmVhY2ggVkxBTiBn b2VzIHRocm91Z2ggYSBzZXBlcmF0ZSBOQVQnZCBpbnN0YW5jZSBpbiBvcmRlciB0bw0KTkFUIG9u IGEgcGFydGljdWxhciBwdWJsaWMgSVAuDQoNCjEuIEhvdXNlIGZ1bGwgb2YgYnVzaW5lc3Nlcy4u IChoZXJlIHNob3duIHcuIDUvOCkNCjIuIEVhY2ggYnVpc2luZXNzIGhhcyBpdCdzIG93biBMQU4N CjMuIEVhY2ggTEFOIGdvZXMgaW50byBhIHN3aXRjaCB3aGVyZSB0aGUgcG9ydCBpcyBjb25maWd1 cmVkIGFzIGEgcGFydGljdWxhciBMQU4NCjQuIFRoZSBzd2l0Y2ggaXMgY29ubmVjdGVkIHRvIGEg RnJlZUJTRCBtYWNoaW5lIHcuIGEgc2V0IG9mDQpWTEFOJ3MgbWF0Y2hpbmcgdGhvc2UgaW4gdGhl IHNlcGVyYXRlIGJ1c2luZXNzZXMNCjUuIFRoZXJlIHNob3VsZCBiZSAxIGluc3RhbmNlIG9mIE5B VGQgcnVubmluZyBmb3IgZWFjaCBWTEFODQo2LiBFYWNoIE5BVGQgdXNlcyBzZXBlcmF0ZSBwdWJs aWMgSVAncw0KNy4gV0FOIFN0YXRpY2x5IGNvbmZpZ3VyZWQgdXNpbmcgYSAvMzANCjguIC8yOSBu ZXQgZm9yIDUvOCBzZXBlcmF0ZSBOQVRkJ3MgKGEuYi5jLjAvMjkpIHJvdXRlZCB0byB0aGUgd2Fu Lg0KOS4gcG9zc2libHkgImlmY29uZmlnIFNvbWVQaHlzSWYwIGEuYi5jLjEvMjkiDQoNCkkgdGhp bmsgZm9yIDUgSVAncyBpdCB3b3VsZCBiZSBzb21ldGhpbmcgbGlrZToNCg0KZm9yIGkgaW4gIDIg MyA0IDUgNjsgZG8NCiAgbmF0ZCAtcG9ydCAxMDAke2l9IFwNCiAgLWYgL2V0Yy9uYXRkXyR7aX0u Y29uZiBcDQogIC1uIDxwaHlzLWlmIG9yIHZsYW4gPz4gXA0KICAtYSBhLmIuYy4ke2l9DQpkb25l DQoNCmZvciBpIGluIDIgMyA0IDUgNjsgZG8NCiAgaXBmdyBhZGQgZGl2ZXJ0IDEwMCR7aX0gYWxs IC4uLi4gDQogICAoZnJvbSBWTEFOLWlmIHwgVkxBTi1DSURSIHwgLi4uID8pIA0KICAgdG8gYW55 IC4uLihpbiB2aWEgVkxBTi1pZiB8IG91dCB2aWEgV0FOLWlmIHwgLi4uLiA/KQ0KZG9uZQ0KDQpp ICphc3N1bWUqIGkgbmVlZCB0byBjb25maWd1cmUgdGhlIC8yOSBzb21ld2hlcmUgLi4NCmkgKnN1 c3BlY3QqIHRoYXQgaSBjYW4gZG8gc29tZXRoaW5nICJ3ZWlyZCIgYW5kIGFjdHVhbGx5DQp1c2Ug YWxsIDggSVAncyAgLi4uIHBlcmhhcHMgY29uZmlndXJlIHRoZSA4IElQJ3MgYXMgYWxpYXNlcyBv biBsbyA/DQoNCndlIHdpbGwgaGF2ZSBtb3JlIHRoYW4gYSBmZXcgYWRkcmVzc2VzIGluIG9yZGVy IHRvIGJlIGFibGUgdG8gZGVsaXZlcg0Kcm91dGVhYmxlIGFkZHJlc3NlcyBpZiBhbnlvbmUgc28g cmVxdWVzdHMuLg0KbGlrZS4uIGEgLzI2IG9mIHdpY2ggd2UgdXNlIGEgLzI4IGZvciBwZXJtYW5l bnQgSVAncyBhbmQgY2FuIGRlbGl2ZXINCjYgLzI5IGZvciB0aGUgZmV3IHdobyBhY3R1YWxseSBu ZWVkcyBhIHJvdXRhYmxlIG5ldHdvcmsuDQoNCmFueW9uZSBoYXMgYW55IGV4cGVyaWVuY2VzIG9y IGhpbnRzIC8gcG9pbnRlcnMgPw0KDQoNCg0KVElBIGFuZCByZWdhcmRzDQoNCktyaXN0aWFuIGFr YSBUaGUgZXRlcm5hbCBuZXdiaWUNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpmcmVlYnNkLW5ldEBmcmVlYnNkLm9yZyBtYWlsaW5nIGxpc3QNCmh0dHA6 Ly9saXN0cy5mcmVlYnNkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ZyZWVic2QtbmV0DQpUbyB1bnN1 YnNjcmliZSwgc2VuZCBhbnkgbWFpbCB0byAiZnJlZWJzZC1uZXQtdW5zdWJzY3JpYmVAZnJlZWJz ZC5vcmciDQo= From owner-freebsd-net@FreeBSD.ORG Thu Nov 13 05:51:09 2003 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 B647316A4CE for ; Thu, 13 Nov 2003 05:51:09 -0800 (PST) Received: from mx01.bos.ma.towardex.com (a65-124-16-8.svc.towardex.com [65.124.16.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B4DA43FDF for ; Thu, 13 Nov 2003 05:51:06 -0800 (PST) (envelope-from haesu@mx01.bos.ma.towardex.com) Received: by mx01.bos.ma.towardex.com (TowardEX ESMTP 3.0p11_DAKN, from userid 1001) id 8F98D2F893; Thu, 13 Nov 2003 08:51:30 -0500 (EST) Date: Thu, 13 Nov 2003 08:51:30 -0500 From: Haesu To: Anders Lowinger , freebsd-net@freebsd.org Message-ID: <20031113135130.GA22054@scylla.towardex.com> References: <20031112024507.89398.qmail@web10007.mail.yahoo.com> <3FB20D2B.73624906@pipeline.ch> <20031112195529.GA48020@scylla.towardex.com> <3FB37F09.4050908@lowinger.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FB37F09.4050908@lowinger.se> User-Agent: Mutt/1.4.1i Subject: Re: tcp hostcache and ip fastforward for review 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, 13 Nov 2003 13:51:09 -0000 > Everything is not black or white. > > A flow cache can accelerate for example Access Control Lists > and/or firewalling, since only the first packet needs to be > verified. That is true , yea. But also note that ACLs in provider environment are often used during times of diverse DoS attacks which flow-based routing systems can faint easily.. :-( [ ... snip ... ] > > Cisco's newer stuff does the flow-cache independent of the forwarding, i.e. > the > flow is more of an accounting cache. Yup, and we use it extensively at the border (Netflow) to do accounting and traffic statistics as well. But still, Cisco relies on use of CEF to actually route, I believe Netflow is used for accounting purposes now (although back in the old days, netflow used to be the acceleration mechanism, but CEF took over the routing part..).....<--But, I may be wrong here :) Where as at the same time, many "layer-3 switches" vendors (the E vendor, the F vendor, tsk tsk) completely rely on use of flow based for actual _routing_ of the packet while marketing their stuff "OMG 16GBPS BACKBPLANE". Well, 16Gbps is good and all during well behaved traffic, but good luck handling a diverse DoS :( I've had an E-vendor switch that went haywire during 56kpps diverse-destination DDoS a while back.. Regards, -hc -- Haesu C. TowardEX Technologies, Inc. Consulting, colocation, web hosting, network design and implementation http://www.towardex.com | haesu@towardex.com Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | POC: HAESU-ARIN > > --Anders, not affiliated with Cisco > > _______________________________________________ > 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 13 08:47:17 2003 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 1E84216A4CE; Thu, 13 Nov 2003 08:47:17 -0800 (PST) Received: from mail.tcoip.com.br (erato.tco.net.br [200.220.254.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13D0843FDF; Thu, 13 Nov 2003 08:47:10 -0800 (PST) (envelope-from dcs@tcoip.com.br) Received: from tcoip.com.br ([10.0.2.6]) by mail.tcoip.com.br (8.11.6/8.11.6) with ESMTP id hADGl0b11196; Thu, 13 Nov 2003 14:47:00 -0200 Message-ID: <3FB3B583.1060307@tcoip.com.br> Date: Thu, 13 Nov 2003 14:46:59 -0200 From: "Daniel C. Sobral" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en, pt-br, ja MIME-Version: 1.0 To: Andre Oppermann References: <3FAE68FB.64D262FF@pipeline.ch> <20031112225326.GI41949@FreeBSD.org> <3FB2BE8A.6C880085@pipeline.ch> In-Reply-To: <3FB2BE8A.6C880085@pipeline.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable cc: freebsd-net@freebsd.org cc: mb@imp.ch cc: Jesper Skriver cc: ume@freebsd.org cc: sam@errno.com Subject: Re: tcp hostcache and ip fastforward for review 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, 13 Nov 2003 16:47:17 -0000 Andre Oppermann wrote: >>If we stored special "for us" /32 routes in the routing table for >>addresses configured on this host, we could avoid the above 2 loops, >>which can quite expensive. >=20 > Good idea. I will look at that after 5.2 code freeze. Question from someone who doesn't really understand the code...=20 Presently, if I have a /32 route defined, I can't add an alias to the=20 same address to an interface. I was expecting this changes to make that=20 possible, which would be really useful to me, and it seems the=20 suggestion above would make that not possible again... So, just in case I'm reading the situation correctly, here's my request=20 for it not to happen. :-) --=20 Daniel C. Sobral Ger=EAncia de Opera=E7=F5es Divis=E3o de Comunica=E7=E3o de Dados Coordena=E7=E3o de Seguran=E7a VIVO Centro Oeste Norte Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: Daniel.Capo@tco.net.br Daniel.Sobral@tcoip.com.br dcs@tcoip.com.br From owner-freebsd-net@FreeBSD.ORG Thu Nov 13 09:01:54 2003 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 A8D2B16A4CE; Thu, 13 Nov 2003 09:01:54 -0800 (PST) Received: from mail.tcoip.com.br (erato.tco.net.br [200.220.254.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 276A743FD7; Thu, 13 Nov 2003 09:01:52 -0800 (PST) (envelope-from dcs@tcoip.com.br) Received: from tcoip.com.br ([10.0.2.6]) by mail.tcoip.com.br (8.11.6/8.11.6) with ESMTP id hADH1fb11583; Thu, 13 Nov 2003 15:01:41 -0200 Message-ID: <3FB3B8F5.7010809@tcoip.com.br> Date: Thu, 13 Nov 2003 15:01:41 -0200 From: "Daniel C. Sobral" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en, pt-br, ja MIME-Version: 1.0 To: Andre Oppermann References: <3FAE68FB.64D262FF@pipeline.ch> <20031112225326.GI41949@FreeBSD.org> <3FB2BE8A.6C880085@pipeline.ch> <20031112232341.GJ41949@skriver.dk> <3FB2C5A3.E6F33B07@pipeline.ch> In-Reply-To: <3FB2C5A3.E6F33B07@pipeline.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable cc: mb@imp.ch cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: ume@freebsd.org cc: sam@errno.com Subject: Re: tcp hostcache and ip fastforward for review 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, 13 Nov 2003 17:01:54 -0000 Andre Oppermann wrote: >=20 > Makes sense. >=20 > Can we ever have a packet that has a source address with INADDR_BROADCA= ST > or IN_MULTICAST? I can't think of such a case. >=20 > Can we ever have a packet with destination address INADDR_ANY? Maybe > for BOOTP? But then the source address would be 0.0.0.0 too? IIRC, in case you have an IP-less interface and you want to subscribe it = to some multicast address, the outgoing packet source address is 0.0.0.0.= --=20 Daniel C. Sobral Ger=EAncia de Opera=E7=F5es Divis=E3o de Comunica=E7=E3o de Dados Coordena=E7=E3o de Seguran=E7a VIVO Centro Oeste Norte Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: Daniel.Capo@tco.net.br Daniel.Sobral@tcoip.com.br dcs@tcoip.com.br From owner-freebsd-net@FreeBSD.ORG Thu Nov 13 09:46:28 2003 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 E831316A4CE; Thu, 13 Nov 2003 09:46:28 -0800 (PST) Received: from mtl.alis.com (mtl.alis.com [199.84.165.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE7ED43FE3; Thu, 13 Nov 2003 09:46:26 -0800 (PST) (envelope-from vgoupil@alis.com) Received: from alis-2k.alis.domain (alis-2k.alis.com [199.84.165.130]) by mtl.alis.com (8.12.8p2/8.12.8) with ESMTP id hADHkP5G018531; Thu, 13 Nov 2003 12:46:25 -0500 (EST) (envelope-from vgoupil@alis.com) Received: by alis-2k.alis.domain with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Nov 2003 12:46:25 -0500 Message-ID: From: Vincent Goupil To: "'freebsd-ipfw@freebsd.org'" , "'freebsd-net@freebsd.org'" , "'freebsd-isp@freebsd.org'" Date: Thu, 13 Nov 2003 12:46:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: IPSec VPN & NATD (problem with alias_address vs redirect_address) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2003 17:46:29 -0000 I setup a firewall with ipfw2 and natd on freebsd 4.9 release. I have mapped my subnet with alias_address I have mapped 4 private ip address with 4 public ip address Everything is working fine (web, email, ftp, etc..) for outgoing and incoming connexion for anyone on my network. With this configuration, 5 person at a time (on my network) could dial = to the same VPN server. 4 with different IP and the one with the alias_address. I supposed = that only one person at a time can use the alias_address with the IPSec VPN = (I think, tell me if I'm wrong) I have authorized AH and ESP to pass through my firewall. Also incoming UDP 500 I'm able to use the VPN for the people mapped with alias_address. I can't use the VPN with the people using the redirect_address. Is there any problem with the redirect_address directive with natd for = the protocol 51 and 51. Is there any other way to have these 5 people at the same time to communicate to the same vpn server ? I though that I could use the redirect_address to do that. So the = incoming connexion to the VPN server appear from a different IP source address. Vincent Goupil Administrateur r=E9seau / Network administrator From owner-freebsd-net@FreeBSD.ORG Thu Nov 13 12:23:48 2003 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 2826916A4CE; Thu, 13 Nov 2003 12:23:48 -0800 (PST) Received: from mta4.adelphia.net (mta4.adelphia.net [68.168.78.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id B34EE43FA3; Thu, 13 Nov 2003 12:23:46 -0800 (PST) (envelope-from tscrum@1wisp.com) Received: from wolf ([68.235.82.98]) by mta4.adelphia.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20031113202350.YLNS19804.mta4.adelphia.net@wolf>; Thu, 13 Nov 2003 15:23:50 -0500 From: "Thomas S. Crum" To: "'Vincent Goupil'" , , , Date: Thu, 13 Nov 2003 15:23:47 -0500 Organization: 1WISP, Inc. Message-ID: <000701c3aa24$0e11fbb0$6252eb44@wolf> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300 Importance: Normal Subject: RE: IPSec VPN & NATD (problem with alias_address vs redirect_address) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2003 20:23:48 -0000 It's my understanding that certain IPSEC does not encrypt the entire packet, leaving the header to be mangled by nat or whatever and refused by the IPSEC machine that you are connecting to. I believe therein your problem lies. Best, Tom -----Original Message----- From: owner-freebsd-ipfw@freebsd.org [mailto:owner-freebsd-ipfw@freebsd.org] On Behalf Of Vincent Goupil Sent: Thursday, November 13, 2003 12:46 PM To: 'freebsd-ipfw@freebsd.org'; 'freebsd-net@freebsd.org'; 'freebsd-isp@freebsd.org' Subject: IPSec VPN & NATD (problem with alias_address vs redirect_address) I setup a firewall with ipfw2 and natd on freebsd 4.9 release. I have mapped my subnet with alias_address I have mapped 4 private ip address with 4 public ip address Everything is working fine (web, email, ftp, etc..) for outgoing and incoming connexion for anyone on my network. With this configuration, 5 person at a time (on my network) could dial to the same VPN server. 4 with different IP and the one with the alias_address. I supposed that only one person at a time can use the alias_address with the IPSec VPN (I think, tell me if I'm wrong) I have authorized AH and ESP to pass through my firewall. Also incoming UDP 500 I'm able to use the VPN for the people mapped with alias_address. I can't use the VPN with the people using the redirect_address. Is there any problem with the redirect_address directive with natd for the protocol 51 and 51. Is there any other way to have these 5 people at the same time to communicate to the same vpn server ? I though that I could use the redirect_address to do that. So the incoming connexion to the VPN server appear from a different IP source address. Vincent Goupil Administrateur r=E9seau / Network administrator _______________________________________________ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Thu Nov 13 12:24:20 2003 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 6D37A16A4CF for ; Thu, 13 Nov 2003 12:24:20 -0800 (PST) Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by mx1.FreeBSD.org (Postfix) with ESMTP id 62EF043F3F for ; Thu, 13 Nov 2003 12:24:19 -0800 (PST) (envelope-from cristjc@comcast.net) Received: from blossom.cjclark.org (12-234-156-182.client.attbi.com[12.234.156.182]) by comcast.net (sccrmhc12) with ESMTP id <2003111320241801200s2it7e>; Thu, 13 Nov 2003 20:24:18 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.9p2/8.12.8) with ESMTP id hADKOasb026646 for ; Thu, 13 Nov 2003 12:24:36 -0800 (PST) (envelope-from cristjc@comcast.net) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.9p2/8.12.9/Submit) id hADKOa9X026645 for net@freebsd.org; Thu, 13 Nov 2003 12:24:36 -0800 (PST) (envelope-from cristjc@comcast.net) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to cristjc@comcast.net using -f Date: Thu, 13 Nov 2003 12:24:35 -0800 From: "Crist J. Clark" To: net@freebsd.org Message-ID: <20031113202435.GA25920@blossom.cjclark.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-URL: http://people.freebsd.org/~cjc/ Subject: netgraph(4) divert(4) to UDP Tunnel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: cjclark@alum.mit.edu List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2003 20:24:20 -0000 I'm trying to play around with netgraph(4) for the first time and there seem to be some aspects of it that haven't "clicked" in my head just yet. What I want to do seems like it should be pretty easy. I want to send some packets through a UDP tunnel. There is an /usr/share/examples/netgraph/udp.tunnel file that is close to what I want, but not quite. I want to send packets that have been divert(4)ed to the tunnel. I can make my two ng_ksocket(8) nodes via the ngctl(8) interface, + mkpeer ksocket d0 inet/dgram/udp + name d0 udptun + msg d0 bind inet/192.168.64.70:10000 + msg d0 connect inet/192.168.64.50:10000 + mkpeer ksocket d1 inet/raw/divert + name d1 divtun + msg d1 bind inet/0.0.0.0:8668 But how do I then connect the two of them up? I assume that I use 'connect' within ngctl(8), but I haven't figured out what the arguments need to be with the documentation and examples I've found. The other thing I suspect I should be doing, is actually running the 'mkpeer' through the first node I create in ngctl(8), but I can't seem to get that to work, + mkpeer ksocket d0 inet/dgram/udp + name d0 udptun + msg d0 bind inet/192.168.64.70:10000 + msg d0 connect inet/192.168.64.50:10000 + mkpeer d0 ksocket d1 inet/raw/divert ngctl: send msg: Socket is already connected I think it is actually complaining about the hook between my ngctl node and the udptun node and not the creation of the divert socket? Basically, I think my conceptual problem is with the fact that you start with the ngctl(8) node in the middle of everything. How do I create my new nodes and get the ngctl(8) node out of the middle? -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org From owner-freebsd-net@FreeBSD.ORG Thu Nov 13 13:16:05 2003 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 C439F16A4CF; Thu, 13 Nov 2003 13:16:05 -0800 (PST) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 74DD143F3F; Thu, 13 Nov 2003 13:16:03 -0800 (PST) (envelope-from cristjc@comcast.net) Received: from blossom.cjclark.org (12-234-156-182.client.attbi.com[12.234.156.182]) by comcast.net (rwcrmhc13) with ESMTP id <2003111321160201500q5553e>; Thu, 13 Nov 2003 21:16:02 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.9p2/8.12.8) with ESMTP id hADLGLsb026811; Thu, 13 Nov 2003 13:16:21 -0800 (PST) (envelope-from cristjc@comcast.net) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.9p2/8.12.9/Submit) id hADLGKhn026810; Thu, 13 Nov 2003 13:16:20 -0800 (PST) (envelope-from cristjc@comcast.net) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to cristjc@comcast.net using -f Date: Thu, 13 Nov 2003 13:16:20 -0800 From: "Crist J. Clark" To: Vincent Goupil Message-ID: <20031113211620.GB25920@blossom.cjclark.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-URL: http://people.freebsd.org/~cjc/ cc: "'freebsd-isp@freebsd.org'" cc: "'freebsd-ipfw@freebsd.org'" cc: "'freebsd-net@freebsd.org'" Subject: Re: IPSec VPN & NATD (problem with alias_address vs redirect_address) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Crist J. Clark" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2003 21:16:06 -0000 On Thu, Nov 13, 2003 at 12:46:24PM -0500, Vincent Goupil wrote: > I setup a firewall with ipfw2 and natd on freebsd 4.9 release. > > I have mapped my subnet with alias_address > I have mapped 4 private ip address with 4 public ip address > > Everything is working fine (web, email, ftp, etc..) for outgoing and > incoming connexion for anyone on my network. > > With this configuration, 5 person at a time (on my network) could dial to > the same VPN server. > 4 with different IP and the one with the alias_address. I supposed that > only one person at a time can use the alias_address with the IPSec VPN (I > think, tell me if I'm wrong) [snip] Nope, that's right. You can have only one machine behind natd(8) using ESP at a time (you could actually have one AH and one ESP at the same time, but since NAT breaks AH, what's the point?). The reason within natd(8) is that accept for a few protocols (TCP, UDP, ICMP, etc.), all that it enters into its translation table is, IPproto: IPsrc_addr-IPdst_addr -> IPalias_addr-IPdst_addr The obvious problem is that you can only have one mapping like this. If you had more than one, when you receive a packet of IPproto from IPdst_addr, to which internal machine do you send it? Now, that's why natd(8) has problems. Why not add a feature to natd(8) to get around it? Because there is no way to get around the problem. ESP packets have this nice SPI field that one could potentially use to map the traffic between multiple machines behind NAT to a single VPN end point on the other side, but there is no practical way for the NAT box to learn the SPI of incoming packets. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org From owner-freebsd-net@FreeBSD.ORG Thu Nov 13 13:55:05 2003 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 B1C1716A4CE; Thu, 13 Nov 2003 13:55:05 -0800 (PST) Received: from mtl.alis.com (mtl.alis.com [199.84.165.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id C146043FE1; Thu, 13 Nov 2003 13:55:03 -0800 (PST) (envelope-from vgoupil@alis.com) Received: from alis-2k.alis.domain (alis-2k.alis.com [199.84.165.130]) by mtl.alis.com (8.12.8p2/8.12.8) with ESMTP id hADLt25G022315; Thu, 13 Nov 2003 16:55:02 -0500 (EST) (envelope-from vgoupil@alis.com) Received: by alis-2k.alis.domain with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Nov 2003 16:55:02 -0500 Message-ID: From: Vincent Goupil To: "'Crist J. Clark'" , "'freebsd-ipfw@freebsd.org'" , "'freebsd-net@freebsd.org'" , "'freebsd-isp@freebsd.org'" Date: Thu, 13 Nov 2003 16:55:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: RE: IPSec VPN & NATD (problem with alias_address vs redirect_addr ess) 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, 13 Nov 2003 21:55:06 -0000 But if I use this config file for natd: unregistered_only use_sockets log log_denied redirect_address 192.168.1.50 208.x.y.120 redirect_address 192.168.1.51 208.x.y.121 redirect_address 192.168.1.52 208.x.y.122 redirect_address 192.168.1.53 208.x.y.123 alias_address 208.x.y.124 With this setup, I should be able to do 5 VPN IPSec connection at the same time. Since, the ESP packet coming on 208.x.y.120 is mapped directly to 192.168.1.50 and so on for the others using the redirect_address directive. I also understand that I can use only one computer at a time for the others using the alias_address (the rest of the network). I'm currently using this setup. I can do only IPSec with the 192.168.1.10-25 witch is mapped by the alias_address. The computer using the IP from 208.x.y.120-123 can't use the VPN and I don't know why. Vincent -----Original Message----- From: Crist J. Clark [mailto:cristjc@comcast.net] Sent: 13 novembre, 2003 16:16 To: Vincent Goupil Cc: 'freebsd-ipfw@freebsd.org'; 'freebsd-net@freebsd.org'; 'freebsd-isp@freebsd.org' Subject: Re: IPSec VPN & NATD (problem with alias_address vs redirect_address) On Thu, Nov 13, 2003 at 12:46:24PM -0500, Vincent Goupil wrote: > I setup a firewall with ipfw2 and natd on freebsd 4.9 release. > > I have mapped my subnet with alias_address > I have mapped 4 private ip address with 4 public ip address > > Everything is working fine (web, email, ftp, etc..) for outgoing and > incoming connexion for anyone on my network. > > With this configuration, 5 person at a time (on my network) could dial to > the same VPN server. > 4 with different IP and the one with the alias_address. I supposed that > only one person at a time can use the alias_address with the IPSec VPN (I > think, tell me if I'm wrong) [snip] Nope, that's right. You can have only one machine behind natd(8) using ESP at a time (you could actually have one AH and one ESP at the same time, but since NAT breaks AH, what's the point?). The reason within natd(8) is that accept for a few protocols (TCP, UDP, ICMP, etc.), all that it enters into its translation table is, IPproto: IPsrc_addr-IPdst_addr -> IPalias_addr-IPdst_addr The obvious problem is that you can only have one mapping like this. If you had more than one, when you receive a packet of IPproto from IPdst_addr, to which internal machine do you send it? Now, that's why natd(8) has problems. Why not add a feature to natd(8) to get around it? Because there is no way to get around the problem. ESP packets have this nice SPI field that one could potentially use to map the traffic between multiple machines behind NAT to a single VPN end point on the other side, but there is no practical way for the NAT box to learn the SPI of incoming packets. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org From owner-freebsd-net@FreeBSD.ORG Thu Nov 13 14:33:53 2003 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 0FD2016A4CE for ; Thu, 13 Nov 2003 14:33:53 -0800 (PST) Received: from freesbee.wheel.dk (freesbee.wheel.dk [193.162.159.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B73543F3F for ; Thu, 13 Nov 2003 14:33:50 -0800 (PST) (envelope-from jesper@skriver.dk) Received: by freesbee.wheel.dk (Postfix, from userid 1001) id 956BA384E7; Thu, 13 Nov 2003 23:33:49 +0100 (CET) Date: Thu, 13 Nov 2003 23:33:49 +0100 From: Jesper Skriver To: Anders Lowinger Message-ID: <20031113223349.GB84594@FreeBSD.org> References: <20031112024507.89398.qmail@web10007.mail.yahoo.com> <3FB20D2B.73624906@pipeline.ch> <20031112195529.GA48020@scylla.towardex.com> <3FB37F09.4050908@lowinger.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FB37F09.4050908@lowinger.se> User-Agent: Mutt/1.4.1i X-PGP-Fingerprint: 6B88 9CE8 66E9 E631 C9C5 5EB4 22AB F0EC F956 1C31 X-PGP-Public-Key: http://freesbee.wheel.dk/~jesper/gpgkey.pub cc: freebsd-net@freebsd.org cc: Haesu Subject: Re: tcp hostcache and ip fastforward for review 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, 13 Nov 2003 22:33:53 -0000 On Thu, Nov 13, 2003 at 01:54:33PM +0100, Anders Lowinger wrote: > >It only takes x num. of kpps with diverse destinations to knock off a > >router running flow based caching. > > Yep, that is true and its hard to work around. > > >Extreme switches use flow based caching (called ipfdb) and any DoS > >attack that uses diverse destinations will kill it pretty quickly.. > > Cisco's newer stuff does the flow-cache independent of the forwarding, > i.e. the flow is more of an accounting cache. With CEF enabled, the flow cache (NetFlow) is only for accounting etc. purposes, and is not involved in forwarding. /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. From owner-freebsd-net@FreeBSD.ORG Thu Nov 13 15:37:25 2003 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 DB4F916A4CE for ; Thu, 13 Nov 2003 15:37:25 -0800 (PST) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6096543FD7 for ; Thu, 13 Nov 2003 15:37:22 -0800 (PST) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 5114E65439 for ; Wed, 12 Nov 2003 10:10: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 68560-02 for ; Wed, 12 Nov 2003 10:10:06 +0000 (GMT) Received: from saboteur.dek.spc.org (unknown [82.147.19.91]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id E967C6530D for ; Wed, 12 Nov 2003 10:10:05 +0000 (GMT) Received: by saboteur.dek.spc.org (Postfix, from userid 1001) id 795B9BD; Wed, 12 Nov 2003 10:10:05 +0000 (GMT) Date: Wed, 12 Nov 2003 10:10:05 +0000 From: Bruce M Simpson To: freebsd-net@freebsd.org Message-ID: <20031112101005.GB22550@saboteur.dek.spc.org> Mail-Followup-To: freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: subnets_are_local unused? 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, 13 Nov 2003 23:37:26 -0000 X-List-Received-Date: Thu, 13 Nov 2003 23:37:26 -0000 X-List-Received-Date: Thu, 13 Nov 2003 23:37:26 -0000 Hi, The sysctl net.inet.ip.subnets_are_local doesn't appear to be referenced anywhere anymore (in RELENG_4 or HEAD). Can it go in the bin? Or is it there for a specific reason? BMS From owner-freebsd-net@FreeBSD.ORG Thu Nov 13 15:37:26 2003 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 B4A2616A4CF; Thu, 13 Nov 2003 15:37:26 -0800 (PST) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 610AD43FEC; Thu, 13 Nov 2003 15:37:22 -0800 (PST) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 793C66543B; Wed, 12 Nov 2003 20:34:29 +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 73799-02-4; Wed, 12 Nov 2003 20:34:29 +0000 (GMT) Received: from saboteur.dek.spc.org (unknown [82.147.19.91]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id D4481653FF; Wed, 12 Nov 2003 20:34:28 +0000 (GMT) Received: by saboteur.dek.spc.org (Postfix, from userid 1001) id 86852BD; Wed, 12 Nov 2003 20:34:28 +0000 (GMT) Date: Wed, 12 Nov 2003 20:34:28 +0000 From: Bruce M Simpson To: harti@freebsd.org Message-ID: <20031112203428.GD24791@saboteur.dek.spc.org> Mail-Followup-To: harti@freebsd.org, Robert Watson , freebsd-net@freebsd.org References: <20031110073822.GA20611@saboteur.dek.spc.org> <20031110191454.GC662@saboteur.dek.spc.org> <20031110204652.A84670@beagle.fokus.fraunhofer.de> <20031110221139.GB2441@saboteur.dek.spc.org> <20031111092650.P7611@beagle.fokus.fraunhofer.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031111092650.P7611@beagle.fokus.fraunhofer.de> cc: freebsd-net@freebsd.org cc: Robert Watson Subject: Re: Viewing multicast group membership? 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, 13 Nov 2003 23:37:26 -0000 On Tue, Nov 11, 2003 at 09:29:49AM +0100, Harti Brandt wrote: > Here you are. This was even once (about a year ago) reviewed by someone, > but did make it into the tree, because I did not insist. I've put the userland code (and a cleaned up version of this diff) up at http://people.freebsd.org/~bms/dump/mcastlist/ for those who care. Basically I created a getifmaddrs() API for prospective merging into libc as the sysctl returns data without the preceding RTM_IFINFO expected by the regular getifaddrs() API. BMS From owner-freebsd-net@FreeBSD.ORG Thu Nov 13 15:37:28 2003 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 BA6D016A4D0; Thu, 13 Nov 2003 15:37:28 -0800 (PST) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 60ED543FE9; Thu, 13 Nov 2003 15:37:22 -0800 (PST) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id B6C0B654B5; Wed, 12 Nov 2003 12:20: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 69535-01; Wed, 12 Nov 2003 12:20:57 +0000 (GMT) Received: from saboteur.dek.spc.org (unknown [82.147.19.91]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 5E6DF6549B; Wed, 12 Nov 2003 12:20:56 +0000 (GMT) Received: by saboteur.dek.spc.org (Postfix, from userid 1001) id E6C15BD; Wed, 12 Nov 2003 12:20:55 +0000 (GMT) Date: Wed, 12 Nov 2003 12:20:55 +0000 From: Bruce M Simpson To: harti@freebsd.org Message-ID: <20031112122055.GD22320@saboteur.dek.spc.org> Mail-Followup-To: harti@freebsd.org, Robert Watson , freebsd-net@freebsd.org References: <20031110073822.GA20611@saboteur.dek.spc.org> <20031110191454.GC662@saboteur.dek.spc.org> <20031110204652.A84670@beagle.fokus.fraunhofer.de> <20031110221139.GB2441@saboteur.dek.spc.org> <20031111092650.P7611@beagle.fokus.fraunhofer.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NDin8bjvE/0mNLFQ" Content-Disposition: inline In-Reply-To: <20031111092650.P7611@beagle.fokus.fraunhofer.de> cc: freebsd-net@freebsd.org cc: Robert Watson Subject: Re: Viewing multicast group membership? 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, 13 Nov 2003 23:37:28 -0000 --NDin8bjvE/0mNLFQ Content-Type: multipart/mixed; boundary="4Ckj6UjgE2iN1+kY" Content-Disposition: inline --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Nov 11, 2003 at 09:29:49AM +0100, Harti Brandt wrote: > Here you are. This was even once (about a year ago) reviewed by someone, > but did make it into the tree, because I did not insist. Ok. The NET_RT_IFMALIST sysctl is not completely identical to the existing NET_RT_IFLIST interface. I've made a few changes to your diff, and rolled a userland interface; please review. BMS --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="rtsock.diff" Content-Transfer-Encoding: quoted-printable Index: rtsock.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/net/rtsock.c,v retrieving revision 1.89 diff -u -r1.89 rtsock.c --- rtsock.c 5 Mar 2003 19:24:22 -0000 1.89 +++ rtsock.c 12 Nov 2003 11:28:43 -0000 @@ -73,6 +73,7 @@ static int rt_xaddrs(caddr_t, caddr_t, struct rt_addrinfo *); static int sysctl_dumpentry(struct radix_node *rn, void *vw); static int sysctl_iflist(int af, struct walkarg *w); +static int sysctl_ifmalist(int af, struct walkarg *w); static int route_output(struct mbuf *, struct socket *); static void rt_setmetrics(u_long, struct rt_metrics *, struct rt_metrics = *); =20 @@ -658,6 +659,10 @@ len =3D sizeof(struct if_msghdr); break; =20 + case RTM_NEWMADDR: + len =3D sizeof(struct ifma_msghdr); + break; + default: len =3D sizeof(struct rt_msghdr); } @@ -994,6 +999,61 @@ return (error); } =20 +int +sysctl_ifmalist(af, w) + int af; + register struct walkarg *w; +{ + register struct ifnet *ifp; + struct ifmultiaddr *ifma; + struct rt_addrinfo info; + int len, error =3D 0; + + bzero((caddr_t)&info, sizeof(info)); + /* IFNET_RLOCK(); */ /* could sleep XXX */ + TAILQ_FOREACH(ifp, &ifnet, if_link) { + if (w->w_arg && w->w_arg !=3D ifp->if_index) + continue; + TAILQ_FOREACH(ifma, &ifp->if_multiaddrs, ifma_link) { + if (af && af !=3D ifma->ifma_addr->sa_family) + continue; + if (jailed(curproc->p_ucred) && + prison_if(curproc->p_ucred, ifma->ifma_addr)) + continue; + info.rti_addrs =3D RTA_IFA; + info.rti_info[RTAX_IFA] =3D ifma->ifma_addr; + if (TAILQ_FIRST(&ifp->if_addrhead)) { + info.rti_addrs |=3D RTA_IFP; + info.rti_info[RTAX_IFP] =3D + TAILQ_FIRST(&ifp->if_addrhead)->ifa_addr; + } else + info.rti_info[RTAX_IFP] =3D NULL; + + if (ifma->ifma_addr->sa_family !=3D AF_LINK) { + info.rti_addrs |=3D RTA_GATEWAY; + info.rti_info[RTAX_GATEWAY] =3D ifma->ifma_lladdr; + } else + info.rti_info[RTAX_GATEWAY] =3D NULL; + + len =3D rt_msg2(RTM_NEWMADDR, &info, 0, w); + if (w->w_req && w->w_tmem) { + register struct ifma_msghdr *ifmam; + + ifmam =3D (struct ifma_msghdr *)w->w_tmem; + ifmam->ifmam_index =3D ifma->ifma_ifp->if_index; + ifmam->ifmam_flags =3D 0; + ifmam->ifmam_addrs =3D info.rti_addrs; + error =3D SYSCTL_OUT(w->w_req, w->w_tmem, len); + if (error) + goto done; + } + } + } +done: + /* IFNET_RUNLOCK(); */ /* XXX */ + return (error); +} + static int sysctl_rtsock(SYSCTL_HANDLER_ARGS) { @@ -1046,6 +1106,11 @@ =20 case NET_RT_IFLIST: error =3D sysctl_iflist(af, &w); + break; + + case NET_RT_IFMALIST: + error =3D sysctl_ifmalist(af, &w); + break; } splx(s); if (w.w_tmem) --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ifmaddrs.h" struct ifmaddrs { struct ifmaddrs *ifma_next; struct sockaddr *ifma_name; struct sockaddr *ifma_addr; struct sockaddr *ifma_gateway; void *ifma_data; }; --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="getifmaddrs.c" Content-Transfer-Encoding: quoted-printable #include #include #include #include #include #include #include #include #include #include #include #include #include "ifmaddrs.h" #if !defined(AF_LINK) #define SA_LEN(sa) sizeof(struct sockaddr) #endif #if !defined(SA_LEN) #define SA_LEN(sa) (sa)->sa_len #endif #define SALIGN (sizeof(long) - 1) #define SA_RLEN(sa) ((sa)->sa_len ? (((sa)->sa_len + SALIGN) & ~SALIGN) : (= SALIGN + 1)) #ifndef ALIGNBYTES /* * On systems with a routing socket, ALIGNBYTES should match the value * that the kernel uses when building the messages. */ #define ALIGNBYTES XXX #endif #ifndef ALIGN #define ALIGN(p) (((u_long)(p) + ALIGNBYTES) &~ ALIGNBYTES) #endif #define MAX_SYSCTL_TRY 5 int getifmaddrs(struct ifmaddrs **pif) { int icnt =3D 1; int dcnt =3D 0; int ncnt =3D 0; int ntry =3D 0; int mib[6]; size_t needed; char *buf; char *next; char *p, *p0; struct rt_msghdr *rtm; struct ifma_msghdr *ifmam; struct sockaddr *sa; struct ifmaddrs *ifa, *ift; u_short idx =3D 0; int i; size_t len, alen; char *data; char *names; mib[0] =3D CTL_NET; mib[1] =3D PF_ROUTE; mib[2] =3D 0; /* protocol */ mib[3] =3D 0; /* wildcard address family */ mib[4] =3D NET_RT_IFMALIST; mib[5] =3D 0; /* no flags */ do { if (sysctl(mib, 6, NULL, &needed, NULL, 0) < 0) return (-1); if ((buf =3D malloc(needed)) =3D=3D NULL) return (-1); if (sysctl(mib, 6, buf, &needed, NULL, 0) < 0) { if (errno !=3D ENOMEM || ++ntry >=3D MAX_SYSCTL_TRY) { free(buf); return (-1); } free(buf); buf =3D NULL; }=20 } while (buf =3D=3D NULL); for (next =3D buf; next < buf + needed; next +=3D rtm->rtm_msglen) { rtm =3D (struct rt_msghdr *)(void *)next; if (rtm->rtm_version !=3D RTM_VERSION) continue; switch (rtm->rtm_type) { case RTM_NEWMADDR: ifmam =3D (struct ifma_msghdr *)(void *)rtm; #define RTA_MASKS (RTA_GATEWAY | RTA_IFP | RTA_IFA) if ((ifmam->ifmam_addrs & RTA_IFA) =3D=3D 0) break; p =3D (char *)(void *)(ifmam + 1); ++icnt; #ifdef HAVE_IFAM_DATA dcnt +=3D sizeof(ifmam->ifmam_data) + ALIGNBYTES; #endif /* HAVE_IFAM_DATA */ /* Scan to look for length of address */ alen =3D 0; for (p0 =3D p, i =3D 0; i < RTAX_MAX; i++) { if ((RTA_MASKS & ifmam->ifmam_addrs & (1 << i)) =3D=3D 0) continue; sa =3D (struct sockaddr *)(void *)p; len =3D SA_RLEN(sa); if (i =3D=3D RTAX_IFA) { alen =3D len; break; } p +=3D len; } for (p =3D p0, i =3D 0; i < RTAX_MAX; i++) { if ((RTA_MASKS & ifmam->ifmam_addrs & (1 << i)) =3D=3D 0) continue; sa =3D (struct sockaddr *)(void *)p; len =3D SA_RLEN(sa); dcnt +=3D len; p +=3D len; } break; } } if (icnt + dcnt + ncnt =3D=3D 1) { *pif =3D NULL; free(buf); return (0); } data =3D malloc(sizeof(struct ifmaddrs) * icnt + dcnt + ncnt); if (data =3D=3D NULL) { free(buf); return(-1); } ifa =3D (struct ifmaddrs *)(void *)data; data +=3D sizeof(struct ifmaddrs) * icnt; names =3D data + dcnt; memset(ifa, 0, sizeof(struct ifmaddrs) * icnt); ift =3D ifa; idx =3D 0; for (next =3D buf; next < buf + needed; next +=3D rtm->rtm_msglen) { rtm =3D (struct rt_msghdr *)(void *)next; if (rtm->rtm_version !=3D RTM_VERSION) continue; switch (rtm->rtm_type) { case RTM_NEWMADDR: ifmam =3D (struct ifma_msghdr *)(void *)rtm; if ((ifmam->ifmam_addrs & RTA_IFA) =3D=3D 0) break; ift->ifma_data =3D NULL; p =3D (char *)(void *)(ifmam + 1); /* Scan to look for length of address */ alen =3D 0; for (p0 =3D p, i =3D 0; i < RTAX_MAX; i++) { if ((RTA_MASKS & ifmam->ifmam_addrs & (1 << i)) =3D=3D 0) continue; sa =3D (struct sockaddr *)(void *)p; len =3D SA_RLEN(sa); if (i =3D=3D RTAX_IFA) { alen =3D len; break; } p +=3D len; } for (p =3D p0, i =3D 0; i < RTAX_MAX; i++) { if ((RTA_MASKS & ifmam->ifmam_addrs & (1 << i)) =3D=3D 0) continue; sa =3D (struct sockaddr *)(void *)p; len =3D SA_RLEN(sa); switch (i) { case RTAX_GATEWAY: ift->ifma_gateway =3D (struct sockaddr *)(void *)data; memcpy(data, p, len); data +=3D len; break; case RTAX_IFP: ift->ifma_name =3D (struct sockaddr *)(void *)data; memcpy(data, p, len); data +=3D len; break; case RTAX_IFA: ift->ifma_addr =3D (struct sockaddr *)(void *)data; memcpy(data, p, len); data +=3D len; break; default: data +=3D len; break; } p +=3D len; } ift =3D (ift->ifma_next =3D ift + 1); break; } } free(buf); if (--ift >=3D ifa) { ift->ifma_next =3D NULL; *pif =3D ifa; } else { *pif =3D NULL; free(ifa); } return (0); } void freeifmaddrs(struct ifmaddrs *ifp) { free(ifp); } --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=Makefile # $Id$ PROG= matest SRCS= getifmaddrs.c matest.c CFLAGS= -g3 -Wall NOMAN= defined .include --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="matest.c" #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include "ifmaddrs.h" extern int getifmaddrs(struct ifmaddrs **ifap); extern void freeifmaddrs(struct ifmaddrs *ifp); void ifmalist_dump(void); int main(int argc, char *argv[]) { ifmalist_dump(); exit(EXIT_SUCCESS); } union sockunion { struct sockaddr_storage ss; struct sockaddr sa; struct sockaddr_dl sdl; struct sockaddr_in sin; struct sockaddr_in6 sin6; }; typedef union sockunion sockunion_t; void ifmalist_dump(void) { struct ifmaddrs *ifmap, *ifma; sockunion_t *psa; if (getifmaddrs(&ifmap)) err(EX_OSERR, "getifmaddrs"); for (ifma = ifmap; ifma; ifma = ifma->ifma_next) { fprintf(stderr, "%p: ", ifma); psa = (sockunion_t *)ifma->ifma_name; if (psa != NULL) { fprintf(stderr, "name AF(%d) ", psa->sa.sa_family); switch (psa->sa.sa_family) { case AF_INET: fprintf(stderr, "%s ", inet_ntoa(psa->sin.sin_addr)); break; case AF_LINK: fprintf(stderr, "%s ", link_ntoa(&psa->sdl)); break; } } else fprintf(stderr, "name NULL "); psa = (sockunion_t *)ifma->ifma_addr; if (psa != NULL) { fprintf(stderr, "addr AF(%d) ", psa->sa.sa_family); switch (psa->sa.sa_family) { case AF_INET: fprintf(stderr, "%s ", inet_ntoa(psa->sin.sin_addr)); break; case AF_INET6: { void *addr; static char addrbuf[INET6_ADDRSTRLEN]; addr = &psa->sin6.sin6_addr; inet_ntop(psa->sa.sa_family, addr, addrbuf, sizeof(addrbuf)); fprintf(stderr, "%s ", addrbuf); } break; case AF_LINK: fprintf(stderr, "%s ", link_ntoa(&psa->sdl)); break; } } else fprintf(stderr, "addr NULL "); psa = (sockunion_t *)ifma->ifma_gateway; if (psa != NULL) { fprintf(stderr, "gw AF(%d) ", psa->sa.sa_family); switch (psa->sa.sa_family) { case AF_INET: fprintf(stderr, "%s ", inet_ntoa(psa->sin.sin_addr)); break; case AF_LINK: fprintf(stderr, "%s ", link_ntoa(&psa->sdl)); break; } } else fprintf(stderr, "gw NULL "); fputc('\n', stderr); } freeifmaddrs(ifmap); } --4Ckj6UjgE2iN1+kY-- --NDin8bjvE/0mNLFQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Comment: '' iD8DBQE/siWnueUpAYYNtTsRAnoaAJ99BxIJDPfHuDq1NCUCqw8/EeRTcwCghufB POj3BPpMCws/wpUgfMEk5VI= =kYkF -----END PGP SIGNATURE----- --NDin8bjvE/0mNLFQ-- From owner-freebsd-net@FreeBSD.ORG Thu Nov 13 15:50:36 2003 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 C2A3A16A4D6 for ; Thu, 13 Nov 2003 15:50:36 -0800 (PST) Received: from ints.mail.pike.ru (ints.mail.pike.ru [195.9.45.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5469A4400F for ; Thu, 13 Nov 2003 15:50:34 -0800 (PST) (envelope-from babolo@cicuta.babolo.ru) Received: (qmail 46579 invoked from network); 14 Nov 2003 00:04:36 -0000 Received: from babolo.ru (HELO cicuta.babolo.ru) (194.58.226.160) by ints.mail.pike.ru with SMTP; 14 Nov 2003 00:04:36 -0000 Received: (nullmailer pid 6939 invoked by uid 136); Thu, 13 Nov 2003 23:52:22 -0000 X-ELM-OSV: (Our standard violations) hdr-charset=KOI8-R; no-hdr-encoding=1 In-Reply-To: <001501c3a9bc$e24abb00$0a01a8c0@esesecurity.lan> To: Kristian Rask Date: Fri, 14 Nov 2003 02:52:22 +0300 (MSK) From: "."@babolo.ru X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <1068767542.493047.6938.nullmailer@cicuta.babolo.ru> cc: freebsd-net@freebsd.org Subject: Re: multiple VLAN's public IP's and NATd's : HowTo ? 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, 13 Nov 2003 23:50:37 -0000 [ Charset ISO-8859-1 unsupported, converting... ] > How would one go about running several instances of natd with unique public IP's for several VLAN's terminated on the same interface ? > > The idea being that multiple seperate RFC-1918 networks are > terminated as VLANS in the FreeBSD machine and that > each VLAN goes through a seperate NAT'd instance in order to > NAT on a particular public IP. > > 1. House full of businesses.. (here shown w. 5/8) > 2. Each buisiness has it's own LAN > 3. Each LAN goes into a switch where the port is configured as a particular LAN > 4. The switch is connected to a FreeBSD machine w. a set of > VLAN's matching those in the seperate businesses > 5. There should be 1 instance of NATd running for each VLAN > 6. Each NATd uses seperate public IP's > 7. WAN Staticly configured using a /30 > 8. /29 net for 5/8 seperate NATd's (a.b.c.0/29) routed to the wan. > 9. possibly "ifconfig SomePhysIf0 a.b.c.1/29" > > I think for 5 IP's it would be something like: > > for i in 2 3 4 5 6; do > natd -port 100${i} \ > -f /etc/natd_${i}.conf \ > -n \ > -a a.b.c.${i} > done > > for i in 2 3 4 5 6; do > ipfw add divert 100${i} all .... > (from VLAN-if | VLAN-CIDR | ... ?) > to any ...(in via VLAN-if | out via WAN-if | .... ?) > done > > i *assume* i need to configure the /29 somewhere .. > i *suspect* that i can do something "weird" and actually > use all 8 IP's ... perhaps configure the 8 IP's as aliases on lo ? > > we will have more than a few addresses in order to be able to deliver > routeable addresses if anyone so requests.. > like.. a /26 of wich we use a /28 for permanent IP's and can deliver > 6 /29 for the few who actually needs a routable network. > > anyone has any experiences or hints / pointers ? I configure home networks nodes, now about 5000 private clients and several small ofice nets on 4 routers. What is my method. natd: 0sw~(2)>ps -axww | grep nat 54729 ?? Ss 344:53,82 /sbin/natd -f /var/net/conf/nat.base -P /var/run/natd.100.pid -a xxx.xxx.49.191 -i 100 -o 101 -d 54731 ?? Ss 191:18,86 /sbin/natd -f /var/net/conf/nat.base -P /var/run/natd.102.pid -a xxx.xxx.49.224 -i 102 -o 103 -d 54733 ?? Ss 360:08,39 /sbin/natd -f /var/net/conf/nat.base -P /var/run/natd.104.pid -a xxx.xxx.50.127 -i 104 -o 105 -d 54735 ?? Ss 421:39,83 /sbin/natd -f /var/net/conf/nat.base -P /var/run/natd.106.pid -a xxx.xxx.49.63 -i 106 -o 107 -d 54737 ?? Ss 108:41,81 /sbin/natd -f /var/net/conf/nat.base -P /var/run/natd.108.pid -a xxx.xxx.49.127 -i 108 -o 109 -d 54739 ?? Ss 182:34,17 /sbin/natd -f /var/net/conf/nat.base -P /var/run/natd.110.pid -a xxx.xxx.50.63 -i 110 -o 111 -d 54741 ?? Ss 302:56,97 /sbin/natd -f /var/net/conf/nat.base -P /var/run/natd.112.pid -a xxx.xxx.50.159 -i 112 -o 113 -d 54743 ?? Ss 367:51,88 /sbin/natd -f /var/net/conf/nat.base -P /var/run/natd.114.pid -a xxx.xxx.50.31 -i 114 -o 115 -d ..... 0sw~(3)>cat /var/net/conf/nat.base # can skip log_denied yes same_ports yes 0sw~(4)>sysctl net.inet.ip.fw.one_pass net.inet.ip.fw.one_pass: 0 and ipfw rules looks like .... 01200 skipto 30000 ip from any to any out ..... 04800 skipto 10000 ip from any to any in recv external_iface ..... ..... allow and deny for all local traffic ..... 20200 divert 106 ip from any to xxx.xxx.49.63 20200 divert 108 ip from any to xxx.xxx.49.127 20200 divert 100 ip from any to xxx.xxx.49.191 20200 divert 102 ip from any to xxx.xxx.49.224 20200 divert 114 ip from any to xxx.xxx.50.31 20200 divert 110 ip from any to xxx.xxx.50.63 20200 divert 104 ip from any to xxx.xxx.50.127 20200 divert 112 ip from any to xxx.xxx.50.159 ..... ..... allow and deny for all local traffic ..... 49600 divert 101 ip from 10.105.1.0/24 to any out 49600 divert 105 ip from 10.105.5.0/24 to any out 49600 divert 109 ip from 10.105.9.0/24 to any out 49600 divert 111 ip from 10.105.11.0/24 to any out 49600 divert 115 ip from 10.105.15.0/24 to any out 49600 divert 103 ip from 10.105.2.0/23 to any out 49600 divert 107 ip from 10.105.6.0/23 to any out 49600 divert 113 ip from 10.105.12.0/23 to any out ..... nat addresses (xxx.xxx.49.63, xxx.xxx.49.127 so on) does not need to be addresses of some iface, they must be routed from Internet to router. Sorry for bad English. I can ansver more if interested. From owner-freebsd-net@FreeBSD.ORG Thu Nov 13 22:02:54 2003 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 9827416A4CF for ; Thu, 13 Nov 2003 22:02:54 -0800 (PST) Received: from modernage.dns-safe.com (ns3.dns-safe.com [64.62.137.158]) by mx1.FreeBSD.org (Postfix) with ESMTP id 934A844001 for ; Thu, 13 Nov 2003 22:02:53 -0800 (PST) (envelope-from jason@dixongroup.net) Received: from md-wmnsmd-cuda1-c8c-27.chvlva.adelphia.net ([68.170.95.27] helo=uniauth1.corp.digex.com) by modernage.dns-safe.com with esmtp (Exim 4.24) id 1AKX2k-0005li-CW for freebsd-net@freebsd.org; Fri, 14 Nov 2003 00:02:32 -0600 From: Jason Dixon To: freebsd-net@freebsd.org Content-Type: text/plain Organization: DixonGroup Consulting Message-Id: <1068789760.2775.18.camel@lappy.fuzzypenguin.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 14 Nov 2003 01:02:40 -0500 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - modernage.dns-safe.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dixongroup.net Subject: Static route via address, not interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2003 06:02:54 -0000 Sorry if this is well-traveled territory, but I haven't found anything relevant in the lists, handbook or FAQ. I have a setup on a network where 802.11b traffic from a group of wireless hosts is "reflected" off the internal interface of an OpenBSD firewall. In order to encrypt all wireless traffic, I enforce a series of host tunnels from the wireless clients into the gateway. This requires that *all* LAN hosts "bounce" off the firewall in order to ensure proper routing both ways. For any traffic destined from one of these systems (say, my Linux laptop, for example) to another local host, packets traverse an IPsec tunnel, exit on enc0 of the firewall, and are NATted back into the wired segment (fxp1). With Linux and Windows hosts, I'm able to add static routes to bind to the gateway IP address (192.168.0.1). Unfortunately, it appears that FreeBSD (4.9-RELEASE) ignores my intent, instead assuming(?) that I wish to assign the route to the interface, rather than the IP. The expected behavior is that traffic is routed locally, rather than across the gateway, breaking all TCP traffic. Any ideas? Am I overlooking something simple? Here is the route command I've used and my routing table: route add -net 192.168.0.0 192.168.0.1 -netmask 255.255.255.0 Destination Gateway Flags Refs Use Netif Expire default 192.168.0.1 UGSc 2 0 fxp0 127.0.0.1 127.0.0.1 UH 1 0 lo0 192.168.0 link#1 UC 3 0 fxp0 192.168.0.1 00:a0:cc:e2:7e:f4 UHLW 3 808 fxp0 596 192.168.0.42 00:05:5d:a6:df:e3 UHLW 1 63 fxp0 992 192.168.0.53 127.0.0.1 UGHS 0 0 lo0 Thanks in advance, -- Jason Dixon, RHCE DixonGroup Consulting http://www.dixongroup.net From owner-freebsd-net@FreeBSD.ORG Fri Nov 14 00:28:51 2003 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 0075516A4D3; Fri, 14 Nov 2003 00:28:51 -0800 (PST) Received: from diomedes.noc.ntua.gr (diomedes.noc.ntua.gr [147.102.222.220]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC83A43FCB; Fri, 14 Nov 2003 00:28:49 -0800 (PST) (envelope-from past@noc.ntua.gr) Received: from ajax.noc.ntua.gr (ajax.noc.ntua.gr [147.102.220.1]) hAE8Slru011381; Fri, 14 Nov 2003 10:28:47 +0200 (EET) (envelope-from past@noc.ntua.gr) Received: from hal.noc.ntua.gr (hal.noc.ntua.gr [147.102.220.45]) by ajax.noc.ntua.gr (8.12.9p1/8.12.9) with ESMTP id hAE8SkoN047011; Fri, 14 Nov 2003 10:28:47 +0200 (EET) (envelope-from past@noc.ntua.gr) From: Panagiotis Astithas Organization: NTUA/NMC To: freebsd-net@freebsd.org Date: Fri, 14 Nov 2003 10:28:46 +0200 User-Agent: KMail/1.5.4 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200311141028.46237.past@noc.ntua.gr> cc: freebsd-ports@freebsd.org Subject: New port: mcl 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, 14 Nov 2003 08:28:51 -0000 Hi, I have submitted a port (ports/58728) of mcl (http://www.inrialpes.fr/planete/ people/roca/mcl/mcl.html), an implementation of Reliable Multicast Protocols. To quote from pkg-descr: The MCLv3 project is an Open-Source GNU/GPL, multi-platform implementation of the two major reliable multicast protocols being standardized by the RMT IETF working group: ALC/LCT and NORM. It is composed of a C/C++ library and several applications built on top of it and provides an easy-to-use and integrated solution for reliable and highly scalable multicast delivery of data. It gets a clean pass from portlint. I would be grateful if someone would review and commit it. Regards, -- Panagiotis Astithas Electrical & Computer Engineer, PhD Network Management Center National Technical University of Athens, Greece From owner-freebsd-net@FreeBSD.ORG Fri Nov 14 00:36:12 2003 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 0969916A4CE for ; Fri, 14 Nov 2003 00:36:12 -0800 (PST) Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A79F43FF3 for ; Fri, 14 Nov 2003 00:36:09 -0800 (PST) (envelope-from ru@sunbay.com) Received: from whale.sunbay.crimea.ua (ru@localhost [127.0.0.1]) hAE8Ztsw015170 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Nov 2003 10:35:55 +0200 (EET) (envelope-from ru@sunbay.com) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.12.9p2/8.12.9/Submit) id hAE8Zrkm015163; Fri, 14 Nov 2003 10:35:53 +0200 (EET) (envelope-from ru) Date: Fri, 14 Nov 2003 10:35:53 +0200 From: Ruslan Ermilov To: cjclark@alum.mit.edu Message-ID: <20031114083553.GA12701@sunbay.com> References: <20031113202435.GA25920@blossom.cjclark.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZPt4rx8FFjLCG7dd" Content-Disposition: inline In-Reply-To: <20031113202435.GA25920@blossom.cjclark.org> User-Agent: Mutt/1.5.5.1i cc: net@freebsd.org Subject: Re: netgraph(4) divert(4) to UDP Tunnel 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, 14 Nov 2003 08:36:12 -0000 --ZPt4rx8FFjLCG7dd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 13, 2003 at 12:24:35PM -0800, Crist J. Clark wrote: > I'm trying to play around with netgraph(4) for the first time and > there seem to be some aspects of it that haven't "clicked" in my head > just yet. >=20 > What I want to do seems like it should be pretty easy. I want to > send some packets through a UDP tunnel. There is an > /usr/share/examples/netgraph/udp.tunnel file that is close to what I > want, but not quite. I want to send packets that have been divert(4)ed > to the tunnel. >=20 > I can make my two ng_ksocket(8) nodes via the ngctl(8) interface, >=20 > + mkpeer ksocket d0 inet/dgram/udp > + name d0 udptun > + msg d0 bind inet/192.168.64.70:10000 > + msg d0 connect inet/192.168.64.50:10000 > + mkpeer ksocket d1 inet/raw/divert > + name d1 divtun > + msg d1 bind inet/0.0.0.0:8668 >=20 > But how do I then connect the two of them up? I assume that I use > 'connect' within ngctl(8), but I haven't figured out what the > arguments need to be with the documentation and examples I've found. >=20 > The other thing I suspect I should be doing, is actually running the > 'mkpeer' through the first node I create in ngctl(8), but I can't seem > to get that to work, >=20 > + mkpeer ksocket d0 inet/dgram/udp > + name d0 udptun > + msg d0 bind inet/192.168.64.70:10000 > + msg d0 connect inet/192.168.64.50:10000 > + mkpeer d0 ksocket d1 inet/raw/divert > ngctl: send msg: Socket is already connected >=20 > I think it is actually complaining about the hook between my ngctl > node and the udptun node and not the creation of the divert socket? >=20 > Basically, I think my conceptual problem is with the fact that you > start with the ngctl(8) node in the middle of everything. How do I > create my new nodes and get the ngctl(8) node out of the middle? >=20 I don't think this is currently possible (I'd like to be mistaken). The main difference between ng_iface (from the classical tunnel example) and ng_ksocket is that the first is so-called ``persistent'' node, i.e., when the number of hooks becomes zero, the node does not get removed automatically. This same is not true for ksocket. But I think this could be a work around: ngctl + mkpeer tee dummy left2right + name dummy mytee + mkpeer mytee: ksocket left inet/dgram/udp + name mytee:left udp1 + mkpeer mytee: ksocket right inet/dgram/udp + name mytee:right udp2 + exit # ngctl show mytee: Name: mytee Type: tee ID: 0000000e Num hooks: 2 Local hook Peer name Peer type Peer ID Peer hook ---------- --------- --------- ------- --------- right udp2 ksocket 00000010 inet/dgram/u= dp left udp1 ksocket 0000000f inet/dgram/u= dp I've omitted any socket-related ops, and both sockets are of type UDP (I don't have the divert(4) support compiled in on this machine), but this should not be important. Cheers, --=20 Ruslan Ermilov Sysadmin and DBA, ru@sunbay.com Sunbay Software Ltd, ru@FreeBSD.org FreeBSD committer --ZPt4rx8FFjLCG7dd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/tJPpUkv4P6juNwoRAidzAJ9Z3kVCjl2QwvKp1QHy1xx4z9xi0gCeKZht +Uff3Qp7G1+MKi6dCmEMoZo= =HKUO -----END PGP SIGNATURE----- --ZPt4rx8FFjLCG7dd-- From owner-freebsd-net@FreeBSD.ORG Fri Nov 14 01:22:50 2003 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 6A05B16A4CE; Fri, 14 Nov 2003 01:22:50 -0800 (PST) Received: from mizar.origin-it.net (mizar.origin-it.net [194.8.96.234]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1F0B43FE5; Fri, 14 Nov 2003 01:22:47 -0800 (PST) (envelope-from helge.oldach@atosorigin.com) Received: from matar.hbg.de.int.atosorigin.com (dehsfw3e.origin-it.net [194.8.96.68])hAE9M8UQ065683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Nov 2003 10:22:08 +0100 (CET) (envelope-from helge.oldach@atosorigin.com) Received: from galaxy.hbg.de.ao-srv.com (galaxy.hbg.de.ao-srv.com [161.89.20.4])ESMTP id hAE9M835051462; Fri, 14 Nov 2003 10:22:08 +0100 (CET) (envelope-from helge.oldach@atosorigin.com) Received: (from hmo@localhost) by galaxy.hbg.de.ao-srv.com (8.9.3p2/8.9.3/hmo30mar03) id KAA17257; Fri, 14 Nov 2003 10:22:06 +0100 (MET) Message-Id: <200311140922.KAA17257@galaxy.hbg.de.ao-srv.com> In-Reply-To: <20031113211620.GB25920@blossom.cjclark.org> from "Crist J. Clark" at "Nov 13, 2003 10:16:20 pm" To: cjc@freebsd.org Date: Fri, 14 Nov 2003 10:22:06 +0100 (MET) From: Helge Oldach X-Address: Atos Origin GmbH, Friesenstraße 13, D-20097 Hamburg, Germany X-Phone: +49 40 7886 7464, Fax: +49 40 7886 9464, Mobile: +49 160 4782517 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: freebsd-isp@freebsd.org cc: freebsd-ipfw@freebsd.org cc: vgoupil@alis.com cc: freebsd-net@freebsd.org Subject: Re: IPSec VPN & NATD (problem with alias_address vs redirect_addr ess) 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, 14 Nov 2003 09:22:50 -0000 Crist J. Clark: >On Thu, Nov 13, 2003 at 12:46:24PM -0500, Vincent Goupil wrote: >> I setup a firewall with ipfw2 and natd on freebsd 4.9 release. >> >> I have mapped my subnet with alias_address >> I have mapped 4 private ip address with 4 public ip address >> >> Everything is working fine (web, email, ftp, etc..) for outgoing and >> incoming connexion for anyone on my network. >> >> With this configuration, 5 person at a time (on my network) could dial to >> the same VPN server. >> 4 with different IP and the one with the alias_address. I supposed that >> only one person at a time can use the alias_address with the IPSec VPN (I >> think, tell me if I'm wrong) >[snip] > >Nope, that's right. You can have only one machine behind natd(8) using >ESP at a time (you could actually have one AH and one ESP at the same >time, but since NAT breaks AH, what's the point?). The reason within >natd(8) is that accept for a few protocols (TCP, UDP, ICMP, etc.), all >that it enters into its translation table is, > > IPproto: IPsrc_addr-IPdst_addr -> IPalias_addr-IPdst_addr > >The obvious problem is that you can only have one mapping like >this. If you had more than one, when you receive a packet of IPproto >from IPdst_addr, to which internal machine do you send it? > >Now, that's why natd(8) has problems. Why not add a feature to natd(8) >to get around it? Because there is no way to get around the >problem. ESP packets have this nice SPI field that one could >potentially use to map the traffic between multiple machines behind >NAT to a single VPN end point on the other side, but there is no >practical way for the NAT box to learn the SPI of incoming packets. Certainly there is. This is actually implemented in most modern VPN devices. They do NAT translation according to SPI. The alternative is to encapsulate IPSec traffic in UDP (using port 4500) packets which can be neatly NATted. In Cisco IOS speak: cisco(config)#crypto ipsec nat-transparency ? spi-matching Match inbound SPI to outbound SPI for IPsec aware NAT udp-encapsulation UDP encapsulation of IPsec protocols cisco(config)# The core issue is that FreeBSD does neither support SPI-based NAT, nor does it support UDP-encapsulated IPSec. Helge From owner-freebsd-net@FreeBSD.ORG Fri Nov 14 02:36:28 2003 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 C481116A4CE for ; Fri, 14 Nov 2003 02:36:28 -0800 (PST) Received: from ints.mail.pike.ru (ints.mail.pike.ru [195.9.45.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id ADD5943FF2 for ; Fri, 14 Nov 2003 02:36:27 -0800 (PST) (envelope-from babolo@cicuta.babolo.ru) Received: (qmail 3960 invoked from network); 14 Nov 2003 10:50:33 -0000 Received: from babolo.ru (HELO cicuta.babolo.ru) (194.58.226.160) by ints.mail.pike.ru with SMTP; 14 Nov 2003 10:50:33 -0000 Received: (nullmailer pid 7786 invoked by uid 136); Fri, 14 Nov 2003 10:38:19 -0000 X-ELM-OSV: (Our standard violations) hdr-charset=KOI8-R; no-hdr-encoding=1 To: freebsd-net@freebsd.org Date: Fri, 14 Nov 2003 13:38:19 +0300 (MSK) From: "."@babolo.ru X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <1068806299.210616.7785.nullmailer@cicuta.babolo.ru> Subject: what about 5000 .. 10000 VLANs in one system? 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, 14 Nov 2003 10:36:28 -0000 I remember that VLAN tag has 12 bits :-) I need in system with 5000 .. 10000 VLAN interfaces on 2 .. 6 physical ethernets. Does anybody has such expienence? Stability? Performance? From owner-freebsd-net@FreeBSD.ORG Fri Nov 14 04:38:14 2003 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 8C35F16A4CE for ; Fri, 14 Nov 2003 04:38:14 -0800 (PST) Received: from vbook.fbsd.ru (asplinux.ru [195.133.213.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7407543F93 for ; Fri, 14 Nov 2003 04:38:13 -0800 (PST) (envelope-from vova@vbook.fbsd.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.24; FreeBSD 5.1) id 1AKdDb-0000UM-5D; Fri, 14 Nov 2003 15:38:31 +0300 From: "Vladimir B. Grebenschikov" To: Jason Dixon In-Reply-To: <1068789760.2775.18.camel@lappy.fuzzypenguin.net> References: <1068789760.2775.18.camel@lappy.fuzzypenguin.net> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: quoted-printable Organization: SWsoft Inc. Message-Id: <1068813508.814.4.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 14 Nov 2003 15:38:30 +0300 Sender: Vladimir Grebenschikov cc: freebsd-net Subject: Re: Static route via address, not interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2003 12:38:14 -0000 =F7 =D0=D4, 14.11.2003, =D7 09:02, Jason Dixon =D0=C9=DB=C5=D4: > Sorry if this is well-traveled territory, but I haven't found anything > relevant in the lists, handbook or FAQ. >=20 > I have a setup on a network where 802.11b traffic from a group of > wireless hosts is "reflected" off the internal interface of an OpenBSD > firewall. In order to encrypt all wireless traffic, I enforce a series > of host tunnels from the wireless clients into the gateway. This > requires that *all* LAN hosts "bounce" off the firewall in order to > ensure proper routing both ways. >=20 > For any traffic destined from one of these systems (say, my Linux > laptop, for example) to another local host, packets traverse an IPsec > tunnel, exit on enc0 of the firewall, and are NATted back into the wired > segment (fxp1). With Linux and Windows hosts, I'm able to add static > routes to bind to the gateway IP address (192.168.0.1). >=20 > Unfortunately, it appears that FreeBSD (4.9-RELEASE) ignores my intent, > instead assuming(?) that I wish to assign the route to the interface, > rather than the IP. The expected behavior is that traffic is routed > locally, rather than across the gateway, breaking all TCP traffic. >=20 > Any ideas? Am I overlooking something simple? Here is the route > command I've used and my routing table: >=20 > route add -net 192.168.0.0 192.168.0.1 -netmask 255.255.255.0 >=20 > Destination Gateway Flags Refs Use Netif Expir= e > default 192.168.0.1 UGSc 2 0 fxp0 > 127.0.0.1 127.0.0.1 UH 1 0 lo0 > 192.168.0 link#1 UC 3 0 fxp0 > 192.168.0.1 00:a0:cc:e2:7e:f4 UHLW 3 808 fxp0 59= 6 > 192.168.0.42 00:05:5d:a6:df:e3 UHLW 1 63 fxp0 99= 2 > 192.168.0.53 127.0.0.1 UGHS 0 0 lo0 I guess - you already have 192.168.0.0/24 route entry, added by command: ifconfig fxp0 192.168.0.53/24=20 so now you need: remove network route via interface: route delete 192.168.0.0/24 add interface route (kernel should know how to reach router)=20 route add 192.168.0.1/32 -iface fxp0 -cloning and then add network route via router route add 192.168.0.0/24 192.168.0.1 > Thanks in advance, --=20 Vladimir B. Grebenschikov SWsoft Inc. From owner-freebsd-net@FreeBSD.ORG Fri Nov 14 06:02:35 2003 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 9EF7F16A4CE for ; Fri, 14 Nov 2003 06:02:35 -0800 (PST) Received: from hypernet.hyper.net (hypernet.hyper.net [193.218.1.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A16543F75 for ; Fri, 14 Nov 2003 06:02:33 -0800 (PST) (envelope-from dxoch@escape.gr) Received: from escape.gr (bus.hyper.gr [193.218.2.30]) ESMTP id hAEDwpu13167 for ; Fri, 14 Nov 2003 15:58:52 +0200 Date: Fri, 14 Nov 2003 16:02:29 +0200 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Jim Xochellis To: net@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <2F1F5F98-16AB-11D8-B2D7-003065C4E486@escape.gr> X-Mailer: Apple Mail (2.552) Subject: ip-up script of pppd no triggered 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, 14 Nov 2003 14:02:35 -0000 Hi list, I have also posted this mail to the freebsd-questions list a few days ago, but I had no luck. Hence, I decided to try this list too, which probably is the most appropriate for my problem. I need to persuade pppd to call its ip-up script in order to add a non-default route as soon as the link is up and running. Unfortunately it seems that my ip-up script is not being called. The mode of the file is rwxr-xr-x and the owner root:wheel. I am calling the pppd from inside a "/usr/local/etc/rc.d/ppp.sh" script by using the following command: "/usr/sbin/pppd /dev/cuaa0 115200 A.A.A.A:B.B.B.B noauth persist netmask 255.255.255.252" I have read all the chapter #18 of the handbook, but I haven't found anything about the ip-up script. On the contrary the PPPD(8) man page claims that the /etc/ppp/ip-up is executed when the link is available for sending and receiving IP packets. My link becomes available for sending/receiving IP packets, but ip-up is never executed. Any ideas why? By the way, I am using kernel PPP, (on ppp0) if it makes any difference. Am I doing something wrong? Thanks in advance Jim Xochellis From owner-freebsd-net@FreeBSD.ORG Fri Nov 14 08:10:26 2003 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 A04D716A4DD; Fri, 14 Nov 2003 08:10:26 -0800 (PST) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8090E43FAF; Fri, 14 Nov 2003 08:10:23 -0800 (PST) (envelope-from cristjc@comcast.net) Received: from blossom.cjclark.org (12-234-156-182.client.attbi.com[12.234.156.182]) by comcast.net (rwcrmhc12) with ESMTP id <2003111416102301400q0daje>; Fri, 14 Nov 2003 16:10:23 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.9p2/8.12.8) with ESMTP id hAEGAfsb062018; Fri, 14 Nov 2003 08:10:42 -0800 (PST) (envelope-from cristjc@comcast.net) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.9p2/8.12.9/Submit) id hAEGAfhk062017; Fri, 14 Nov 2003 08:10:41 -0800 (PST) (envelope-from cristjc@comcast.net) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to cristjc@comcast.net using -f Date: Fri, 14 Nov 2003 08:10:40 -0800 From: "Crist J. Clark" To: Ruslan Ermilov Message-ID: <20031114161040.GA61960@blossom.cjclark.org> References: <20031113202435.GA25920@blossom.cjclark.org> <20031114083553.GA12701@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031114083553.GA12701@sunbay.com> User-Agent: Mutt/1.4.1i X-URL: http://people.freebsd.org/~cjc/ cc: net@freebsd.org Subject: Re: netgraph(4) divert(4) to UDP Tunnel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: cjclark@alum.mit.edu List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2003 16:10:26 -0000 On Fri, Nov 14, 2003 at 10:35:53AM +0200, Ruslan Ermilov wrote: > On Thu, Nov 13, 2003 at 12:24:35PM -0800, Crist J. Clark wrote: > > I'm trying to play around with netgraph(4) for the first time and > > there seem to be some aspects of it that haven't "clicked" in my head > > just yet. > > > > What I want to do seems like it should be pretty easy. I want to > > send some packets through a UDP tunnel. There is an > > /usr/share/examples/netgraph/udp.tunnel file that is close to what I > > want, but not quite. I want to send packets that have been divert(4)ed > > to the tunnel. > > > > I can make my two ng_ksocket(8) nodes via the ngctl(8) interface, > > > > + mkpeer ksocket d0 inet/dgram/udp > > + name d0 udptun > > + msg d0 bind inet/192.168.64.70:10000 > > + msg d0 connect inet/192.168.64.50:10000 > > + mkpeer ksocket d1 inet/raw/divert > > + name d1 divtun > > + msg d1 bind inet/0.0.0.0:8668 > > > > But how do I then connect the two of them up? I assume that I use > > 'connect' within ngctl(8), but I haven't figured out what the > > arguments need to be with the documentation and examples I've found. > > > > The other thing I suspect I should be doing, is actually running the > > 'mkpeer' through the first node I create in ngctl(8), but I can't seem > > to get that to work, > > > > + mkpeer ksocket d0 inet/dgram/udp > > + name d0 udptun > > + msg d0 bind inet/192.168.64.70:10000 > > + msg d0 connect inet/192.168.64.50:10000 > > + mkpeer d0 ksocket d1 inet/raw/divert > > ngctl: send msg: Socket is already connected > > > > I think it is actually complaining about the hook between my ngctl > > node and the udptun node and not the creation of the divert socket? > > > > Basically, I think my conceptual problem is with the fact that you > > start with the ngctl(8) node in the middle of everything. How do I > > create my new nodes and get the ngctl(8) node out of the middle? > > > I don't think this is currently possible (I'd like to be mistaken). > The main difference between ng_iface (from the classical tunnel > example) and ng_ksocket is that the first is so-called ``persistent'' > node, i.e., when the number of hooks becomes zero, the node does > not get removed automatically. This same is not true for ksocket. > > But I think this could be a work around: > > ngctl > + mkpeer tee dummy left2right > + name dummy mytee > + mkpeer mytee: ksocket left inet/dgram/udp > + name mytee:left udp1 > + mkpeer mytee: ksocket right inet/dgram/udp > + name mytee:right udp2 > + exit Thanks for the suggestion. I had already tried this, and it did indeed work. However, you actually can do one better. If you now shutdown the ng_tee(8) node, the two ksockets end up directly attached. I found that out by accident and haven't looked to see where that interesting behavior is documented. Here're the commands I used, #!/usr/sbin/ngctl -f mkpeer tee hub left2right mkpeer hub ksocket right inet/dgram/udp name hub.right udptun msg hub.right bind inet/192.168.64.70:10000 msg hub.right connect inet/192.168.64.50:10000 mkpeer hub ksocket left inet/raw/divert name hub.left divtun msg hub.left bind inet/0.0.0.0:8668 shutdown hub After I run this, # ngctl list There are 3 total nodes: Name: ngctl13605 Type: socket ID: 0000003b Num hooks: 0 Name: divtun Type: ksocket ID: 0000003a Num hooks: 1 Name: udptun Type: ksocket ID: 00000039 Num hooks: 1 # ngctl show divtun: Name: divtun Type: ksocket ID: 0000003a Num hooks: 1 Local hook Peer name Peer type Peer ID Peer hook ---------- --------- --------- ------- --------- inet/raw/divert udptun ksocket 00000039 inet/dgram/udp Which is exactly what I wanted. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org From owner-freebsd-net@FreeBSD.ORG Fri Nov 14 08:36:38 2003 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 7BD5716A4CE; Fri, 14 Nov 2003 08:36:38 -0800 (PST) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3919D43FE0; Fri, 14 Nov 2003 08:36:37 -0800 (PST) (envelope-from cristjc@comcast.net) Received: from blossom.cjclark.org (12-234-156-182.client.attbi.com[12.234.156.182]) by comcast.net (rwcrmhc11) with ESMTP id <2003111416363601300hutqre>; Fri, 14 Nov 2003 16:36:36 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.9p2/8.12.8) with ESMTP id hAEGatsb062096; Fri, 14 Nov 2003 08:36:55 -0800 (PST) (envelope-from cristjc@comcast.net) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.9p2/8.12.9/Submit) id hAEGasev062095; Fri, 14 Nov 2003 08:36:54 -0800 (PST) (envelope-from cristjc@comcast.net) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to cristjc@comcast.net using -f Date: Fri, 14 Nov 2003 08:36:54 -0800 From: "Crist J. Clark" To: Helge Oldach Message-ID: <20031114163654.GB61960@blossom.cjclark.org> References: <20031113211620.GB25920@blossom.cjclark.org> <200311140922.KAA17257@galaxy.hbg.de.ao-srv.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200311140922.KAA17257@galaxy.hbg.de.ao-srv.com> User-Agent: Mutt/1.4.1i X-URL: http://people.freebsd.org/~cjc/ cc: freebsd-isp@freebsd.org cc: freebsd-ipfw@freebsd.org cc: vgoupil@alis.com cc: freebsd-net@freebsd.org Subject: Re: IPSec VPN & NATD (problem with alias_address vs redirect_addr ess) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: cjclark@alum.mit.edu List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2003 16:36:38 -0000 On Fri, Nov 14, 2003 at 10:22:06AM +0100, Helge Oldach wrote: > Crist J. Clark: > >On Thu, Nov 13, 2003 at 12:46:24PM -0500, Vincent Goupil wrote: > >> I setup a firewall with ipfw2 and natd on freebsd 4.9 release. > >> > >> I have mapped my subnet with alias_address > >> I have mapped 4 private ip address with 4 public ip address > >> > >> Everything is working fine (web, email, ftp, etc..) for outgoing and > >> incoming connexion for anyone on my network. > >> > >> With this configuration, 5 person at a time (on my network) could dial to > >> the same VPN server. > >> 4 with different IP and the one with the alias_address. I supposed that > >> only one person at a time can use the alias_address with the IPSec VPN (I > >> think, tell me if I'm wrong) > >[snip] > > > >Nope, that's right. You can have only one machine behind natd(8) using > >ESP at a time (you could actually have one AH and one ESP at the same > >time, but since NAT breaks AH, what's the point?). The reason within > >natd(8) is that accept for a few protocols (TCP, UDP, ICMP, etc.), all > >that it enters into its translation table is, > > > > IPproto: IPsrc_addr-IPdst_addr -> IPalias_addr-IPdst_addr > > > >The obvious problem is that you can only have one mapping like > >this. If you had more than one, when you receive a packet of IPproto > >from IPdst_addr, to which internal machine do you send it? > > > >Now, that's why natd(8) has problems. Why not add a feature to natd(8) > >to get around it? Because there is no way to get around the > >problem. ESP packets have this nice SPI field that one could > >potentially use to map the traffic between multiple machines behind > >NAT to a single VPN end point on the other side, but there is no > >practical way for the NAT box to learn the SPI of incoming packets. > > Certainly there is. Nope, there isn't a general way to do it. > This is actually implemented in most modern VPN > devices. They do NAT translation according to SPI. The alternative is to > encapsulate IPSec traffic in UDP (using port 4500) packets which can be > neatly NATted. It's not actually very neat. Most vendor kludges to do this are not interoperable. The IETF draft for it isn't widely implemented AFAIK. > In Cisco IOS speak: > > cisco(config)#crypto ipsec nat-transparency ? > spi-matching Match inbound SPI to outbound SPI for IPsec aware NAT Not sure what that is going to accomplish. The inbound SPI and outbound SPI are, in general, completely indpendent values. The whole problem is that there is no way to know what the incoming (from the external VPN end point to the one behind the NAT device) SPI is going to be. There are heuristics a NAT device could use to guess (when a new SPI shows up at the doorstep, it's to the host that most recently had some IKE activity), but it's just that, a guess. (And if two systems start up or rekey at the same time, you're hosed when guessing by key traffic. Worse yet, there is no requirement to use IKE to setup IPsec SAs, so then what's a NAT box to do?) > udp-encapsulation UDP encapsulation of IPsec protocols > cisco(config)# > > The core issue is that FreeBSD does neither support SPI-based NAT, 'Cause unless you have a hacked up IPsec implementation that uses the same SPI both directions, it is useless. > nor > does it support UDP-encapsulated IPSec. I'll post some instructions on how to do this (not compliant with the draft below). But that still is not a panecea, http://ietf.org/internet-drafts/draft-ietf-ipsec-nat-reqts-06.txt http://ietf.org/internet-drafts/draft-ietf-ipsec-udp-encaps-06.txt NAT is evil. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org From owner-freebsd-net@FreeBSD.ORG Fri Nov 14 08:38:41 2003 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 414E716A4CE for ; Fri, 14 Nov 2003 08:38:41 -0800 (PST) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 501F243F3F for ; Fri, 14 Nov 2003 08:38:40 -0800 (PST) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 764F06542F for ; Fri, 14 Nov 2003 16:38:39 +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 95554-01-4 for ; Fri, 14 Nov 2003 16:38:39 +0000 (GMT) Received: from saboteur.dek.spc.org (unknown [82.147.19.91]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 1CCB7651F4 for ; Fri, 14 Nov 2003 16:38:39 +0000 (GMT) Received: by saboteur.dek.spc.org (Postfix, from userid 1001) id 1ED2826; Fri, 14 Nov 2003 16:38:37 +0000 (GMT) Date: Fri, 14 Nov 2003 16:38:37 +0000 From: Bruce M Simpson To: freebsd-net@freebsd.org Message-ID: <20031114163837.GA64140@saboteur.dek.spc.org> Mail-Followup-To: freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: ng_nat vs natd vs ipnat? 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, 14 Nov 2003 16:38:41 -0000 Has anyone implemented NAT as a Netgraph node? If so, how does performance compare to natd and ipnat? Regards, BMS From owner-freebsd-net@FreeBSD.ORG Fri Nov 14 08:42:02 2003 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 5E75016A4CE; Fri, 14 Nov 2003 08:42:02 -0800 (PST) Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E5C243FE5; Fri, 14 Nov 2003 08:36:37 -0800 (PST) (envelope-from ru@sunbay.com) Received: from whale.sunbay.crimea.ua (ru@localhost [127.0.0.1]) hAEGZisw059988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Nov 2003 18:35:44 +0200 (EET) (envelope-from ru@sunbay.com) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.12.9p2/8.12.9/Submit) id hAEGZhD9059971; Fri, 14 Nov 2003 18:35:43 +0200 (EET) (envelope-from ru) Date: Fri, 14 Nov 2003 18:35:43 +0200 From: Ruslan Ermilov To: cjclark@alum.mit.edu Message-ID: <20031114163543.GA57826@sunbay.com> References: <20031113202435.GA25920@blossom.cjclark.org> <20031114083553.GA12701@sunbay.com> <20031114161040.GA61960@blossom.cjclark.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UlVJffcvxoiEqYs2" Content-Disposition: inline In-Reply-To: <20031114161040.GA61960@blossom.cjclark.org> User-Agent: Mutt/1.5.5.1i cc: Julian Elischer cc: net@freebsd.org Subject: Re: netgraph(4) divert(4) to UDP Tunnel 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, 14 Nov 2003 16:42:02 -0000 --UlVJffcvxoiEqYs2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 14, 2003 at 08:10:40AM -0800, Crist J. Clark wrote: > On Fri, Nov 14, 2003 at 10:35:53AM +0200, Ruslan Ermilov wrote: > > On Thu, Nov 13, 2003 at 12:24:35PM -0800, Crist J. Clark wrote: > > > I'm trying to play around with netgraph(4) for the first time and > > > there seem to be some aspects of it that haven't "clicked" in my head > > > just yet. > > >=20 > > > What I want to do seems like it should be pretty easy. I want to > > > send some packets through a UDP tunnel. There is an > > > /usr/share/examples/netgraph/udp.tunnel file that is close to what I > > > want, but not quite. I want to send packets that have been divert(4)ed > > > to the tunnel. > > >=20 > > > I can make my two ng_ksocket(8) nodes via the ngctl(8) interface, > > >=20 > > > + mkpeer ksocket d0 inet/dgram/udp > > > + name d0 udptun > > > + msg d0 bind inet/192.168.64.70:10000 > > > + msg d0 connect inet/192.168.64.50:10000 > > > + mkpeer ksocket d1 inet/raw/divert > > > + name d1 divtun > > > + msg d1 bind inet/0.0.0.0:8668 > > >=20 > > > But how do I then connect the two of them up? I assume that I use > > > 'connect' within ngctl(8), but I haven't figured out what the > > > arguments need to be with the documentation and examples I've found. > > >=20 > > > The other thing I suspect I should be doing, is actually running the > > > 'mkpeer' through the first node I create in ngctl(8), but I can't seem > > > to get that to work, > > >=20 > > > + mkpeer ksocket d0 inet/dgram/udp > > > + name d0 udptun > > > + msg d0 bind inet/192.168.64.70:10000 > > > + msg d0 connect inet/192.168.64.50:10000 > > > + mkpeer d0 ksocket d1 inet/raw/divert > > > ngctl: send msg: Socket is already connected > > >=20 > > > I think it is actually complaining about the hook between my ngctl > > > node and the udptun node and not the creation of the divert socket? > > >=20 > > > Basically, I think my conceptual problem is with the fact that you > > > start with the ngctl(8) node in the middle of everything. How do I > > > create my new nodes and get the ngctl(8) node out of the middle? > > >=20 > > I don't think this is currently possible (I'd like to be mistaken). > > The main difference between ng_iface (from the classical tunnel > > example) and ng_ksocket is that the first is so-called ``persistent'' > > node, i.e., when the number of hooks becomes zero, the node does > > not get removed automatically. This same is not true for ksocket. > >=20 > > But I think this could be a work around: > >=20 > > ngctl > > + mkpeer tee dummy left2right > > + name dummy mytee > > + mkpeer mytee: ksocket left inet/dgram/udp > > + name mytee:left udp1 > > + mkpeer mytee: ksocket right inet/dgram/udp > > + name mytee:right udp2 > > + exit >=20 > Thanks for the suggestion. I had already tried this, and it did indeed > work. However, you actually can do one better. If you now shutdown the > ng_tee(8) node, the two ksockets end up directly attached. I found > that out by accident and haven't looked to see where that interesting > behavior is documented. Here're the commands I used, >=20 > #!/usr/sbin/ngctl -f >=20 > mkpeer tee hub left2right >=20 > mkpeer hub ksocket right inet/dgram/udp > name hub.right udptun > msg hub.right bind inet/192.168.64.70:10000 > msg hub.right connect inet/192.168.64.50:10000 >=20 > mkpeer hub ksocket left inet/raw/divert > name hub.left divtun > msg hub.left bind inet/0.0.0.0:8668 >=20 > shutdown hub >=20 > After I run this, >=20 > # ngctl list > There are 3 total nodes: > Name: ngctl13605 Type: socket ID: 0000003b Num hooks:= 0 > Name: divtun Type: ksocket ID: 0000003a Num hooks:= 1 > Name: udptun Type: ksocket ID: 00000039 Num hooks:= 1 > # ngctl show divtun: > Name: divtun Type: ksocket ID: 0000003a Num hooks:= 1 > Local hook Peer name Peer type Peer ID Peer hook > ---------- --------- --------- ------- --------= -=20 > inet/raw/divert udptun ksocket 00000039 inet/dgr= am/udp >=20 > Which is exactly what I wanted. >=20 Strange, I've tried exactly this sequence in the morning when replying, and it didn't work. Ah, I now see: it works this way on 4.9-STABLE only, but not on 5.1-CURRENT anymore. This is due to the following code that took care of reconnecting hooks commented out in 5.1-CURRENT (due to the internal differences in the node shutdown code in RELENG_4 and HEAD): : ngt_shutdown(node_p node) : { : const sc_p privdata =3D NG_NODE_PRIVATE(node); : #if 0 /* can never happen as cutlinks is already called */ : if (privdata->left.hook && privdata->right.hook) : ng_bypass(privdata->left.hook, privdata->right.hook); : #endif Possible solutions: - add a new control message for ng_tee that will effectively call ng_bypass() as shown above, - "fix" NGM_CONNECT to allow for node reconnection. Cheers, --=20 Ruslan Ermilov Sysadmin and DBA, ru@sunbay.com Sunbay Software Ltd, ru@FreeBSD.org FreeBSD committer --UlVJffcvxoiEqYs2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/tQRfUkv4P6juNwoRAiNFAJ9ExdFPQqbI1DJgkZQhAqj1aohwgwCfa6Us llZUwqcdZGd+GlUVZFVnXkg= =TpXj -----END PGP SIGNATURE----- --UlVJffcvxoiEqYs2-- From owner-freebsd-net@FreeBSD.ORG Fri Nov 14 09:19:00 2003 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 363B116A4CE for ; Fri, 14 Nov 2003 09:19:00 -0800 (PST) Received: from venus.vincentjardin.net (AVelizy-102-1-2-230.w217-128.abo.wanadoo.fr [217.128.206.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 385AF43FA3 for ; Fri, 14 Nov 2003 09:18:58 -0800 (PST) (envelope-from jardin@venus.vincentjardin.net) Received: from venus.vincentjardin.net (localhost [127.0.0.1]) hAEHKf9A012645; Fri, 14 Nov 2003 18:20:41 +0100 (CET) (envelope-from jardin@venus.vincentjardin.net) Received: from localhost (localhost [[UNIX: localhost]]) by venus.vincentjardin.net (8.12.9/8.12.9/Submit) id hAEHKeJM012644; Fri, 14 Nov 2003 18:20:40 +0100 (CET) From: Vincent Jardin To: Bruce M Simpson , freebsd-net@freebsd.org Date: Fri, 14 Nov 2003 18:20:40 +0100 User-Agent: KMail/1.5.2 References: <20031114163837.GA64140@saboteur.dek.spc.org> In-Reply-To: <20031114163837.GA64140@saboteur.dek.spc.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200311141820.40593.vjardin@free.fr> Subject: Re: ng_nat vs natd vs ipnat? 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, 14 Nov 2003 17:19:00 -0000 Sorry I did not. So maybe I should not answer. By the way, I think that a ng_nat would have quite the same perfomance than ipnat. Moreover I think that many ng_nat_xxx would be required in order to support the ALGs: - ng_nat_ftp - ng_nat_sip - ng_nat_h323 - ... ng_nat would be only the core of the NAT service. Vincent On Friday 14 November 2003 17:38, Bruce M Simpson wrote: > Has anyone implemented NAT as a Netgraph node? > If so, how does performance compare to natd and ipnat? > > Regards, > 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 Fri Nov 14 09:23:48 2003 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 DCA5216A4CE; Fri, 14 Nov 2003 09:23:47 -0800 (PST) Received: from mizar.origin-it.net (mizar.origin-it.net [194.8.96.234]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0298743FE5; Fri, 14 Nov 2003 09:23:46 -0800 (PST) (envelope-from helge.oldach@atosorigin.com) Received: from matar.hbg.de.int.atosorigin.com (dehsfw3e.origin-it.net [194.8.96.68])hAEHN3UQ089189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Nov 2003 18:23:03 +0100 (CET) (envelope-from helge.oldach@atosorigin.com) Received: from galaxy.hbg.de.ao-srv.com (galaxy.hbg.de.ao-srv.com [161.89.20.4])ESMTP id hAEHN335075842; Fri, 14 Nov 2003 18:23:03 +0100 (CET) (envelope-from helge.oldach@atosorigin.com) Received: (from hmo@localhost) by galaxy.hbg.de.ao-srv.com (8.9.3p2/8.9.3/hmo30mar03) id SAA19138; Fri, 14 Nov 2003 18:22:55 +0100 (MET) Message-Id: <200311141722.SAA19138@galaxy.hbg.de.ao-srv.com> In-Reply-To: <20031114163654.GB61960@blossom.cjclark.org> from "Crist J. Clark" at "Nov 14, 2003 5:36:54 pm" To: cjclark@alum.mit.edu Date: Fri, 14 Nov 2003 18:22:55 +0100 (MET) From: Helge Oldach X-Address: Atos Origin GmbH, Friesenstraße 13, D-20097 Hamburg, Germany X-Phone: +49 40 7886 7464, Fax: +49 40 7886 9464, Mobile: +49 160 4782517 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: freebsd-isp@freebsd.org cc: freebsd-ipfw@freebsd.org cc: vgoupil@alis.com cc: freebsd-net@freebsd.org Subject: Re: IPSec VPN & NATD (problem with alias_address vs redirect_addr ess) 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, 14 Nov 2003 17:23:48 -0000 Crist J. Clark: >> >ESP packets have this nice SPI field that one could >> >potentially use to map the traffic between multiple machines behind >> >NAT to a single VPN end point on the other side, but there is no >> >practical way for the NAT box to learn the SPI of incoming packets. >> Certainly there is. > >Nope, there isn't a general way to do it. Agreed, there is no *general* trick. But the hacks I have described work very well in many business environments. >> This is actually implemented in most modern VPN >> devices. They do NAT translation according to SPI. The alternative is to >> encapsulate IPSec traffic in UDP (using port 4500) packets which can be >> neatly NATted. > >It's not actually very neat. Most vendor kludges to do this are not >interoperable. The IETF draft for it isn't widely implemented AFAIK. As I said, must modern VPN devices have it. As a minimum, virtually any el-cheapo DSL router supports ESP-NAT for a single device (assuming that all SPIs belong to a single internal address). But many also support SPI-aware NAT. >> In Cisco IOS speak: >> >> cisco(config)#crypto ipsec nat-transparency ? >> spi-matching Match inbound SPI to outbound SPI for IPsec aware NAT > >Not sure what that is going to accomplish. The inbound SPI and >outbound SPI are, in general, completely indpendent values. The whole >problem is that there is no way to know what the incoming (from the >external VPN end point to the one behind the NAT device) SPI is going >to be. Correct. Cisco requires that you use IKE in order to make it work. Basically this is NAT for ESP, and the SPI-NAT table is being built up using IKE cookie matching. There is no heuristics involved. >> udp-encapsulation UDP encapsulation of IPsec protocols >> cisco(config)# >> >> The core issue is that FreeBSD does neither support SPI-based NAT, > >'Cause unless you have a hacked up IPsec implementation that uses the >same SPI both directions, it is useless. Nothing that works well and has noticeable exposure is useless. This definitely has both. Not with FreeBSD, though. It does work with Windows 2000 SP4, to put a name up... So it's definitely out there. >> nor >> does it support UDP-encapsulated IPSec. > >I'll post some instructions on how to do this (not compliant with the >draft below). But that still is not a panecea, Thank you, this is very interesting. >NAT is evil. Of course. But it's also a fact of life... Helge From owner-freebsd-net@FreeBSD.ORG Fri Nov 14 09:41:23 2003 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 425F716A4CE for ; Fri, 14 Nov 2003 09:41:23 -0800 (PST) Received: from modernage.dns-safe.com (ns3.dns-safe.com [64.62.137.158]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7591443FAF for ; Fri, 14 Nov 2003 09:41:22 -0800 (PST) (envelope-from jason@dixongroup.net) Received: from md-wmnsmd-cuda1-c8c-27.chvlva.adelphia.net ([68.170.95.27] helo=uniauth1.corp.digex.com) by modernage.dns-safe.com with esmtp (Exim 4.24) id 1AKhwg-00043p-Ck for freebsd-net@freebsd.org; Fri, 14 Nov 2003 11:41:00 -0600 From: Jason Dixon To: freebsd-net@freebsd.org In-Reply-To: <1068813508.814.4.camel@localhost> References: <1068789760.2775.18.camel@lappy.fuzzypenguin.net> <1068813508.814.4.camel@localhost> Content-Type: text/plain Organization: DixonGroup Consulting Message-Id: <1068831665.2775.33.camel@lappy.fuzzypenguin.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 14 Nov 2003 12:41:05 -0500 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - modernage.dns-safe.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dixongroup.net Subject: Re: Static route via address, not interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2003 17:41:23 -0000 On Fri, 2003-11-14 at 07:38, Vladimir B. Grebenschikov wrote: > I guess - you already have 192.168.0.0/24 route entry, added by command: > ifconfig fxp0 192.168.0.53/24 > > so now you need: > remove network route via interface: > route delete 192.168.0.0/24 > add interface route (kernel should know how to reach router) > route add 192.168.0.1/32 -iface fxp0 -cloning > and then add network route via router > route add 192.168.0.0/24 192.168.0.1 I guess I didn't make it clear enough, let me try again. I'm attempting to create a static route for my FreeBSD host so that *all* local traffic is routed across the gateway firewall, rather than being delivered on the local network segment, as is the default with LANs. If you view the routing table (below) again, you'll notice that traffic from the FreeBSD box (192.168.0.53) to another box on the same subnet (192.168.0.42) is still being delivered locally, rather than being routed through the gateway (192.168.0.1). This is *after* I've added a static route for 192.168.0.0/24 to use 192.168.0.1. Destination Gateway Flags Refs Use Netif Expire default 192.168.0.1 UGSc 2 0 fxp0 127.0.0.1 127.0.0.1 UH 1 0 lo0 192.168.0 link#1 UC 3 0 fxp0 192.168.0.1 00:a0:cc:e2:7e:f4 UHLW 3 808 fxp0 596 192.168.0.42 00:05:5d:a6:df:e3 UHLW 1 63 fxp0 992 192.168.0.53 127.0.0.1 UGHS 0 0 lo0 There are no routers inbetween. Just a host on a LAN behind a firewall (which routes between the LAN and the internet, of course). -- Jason Dixon, RHCE DixonGroup Consulting http://www.dixongroup.net From owner-freebsd-net@FreeBSD.ORG Fri Nov 14 10:47:08 2003 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 16A9E16A4CE for ; Fri, 14 Nov 2003 10:47:08 -0800 (PST) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F94643F85 for ; Fri, 14 Nov 2003 10:47:07 -0800 (PST) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.9/8.12.3) with ESMTP id hAEIl2OT003236; Fri, 14 Nov 2003 10:47:02 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.9/8.12.3/Submit) id hAEIl1f5003234; Fri, 14 Nov 2003 10:47:01 -0800 Date: Fri, 14 Nov 2003 10:47:01 -0800 From: Brooks Davis To: "."@babolo.ru Message-ID: <20031114184700.GC28455@Odin.AC.HMC.Edu> References: <1068806299.210616.7785.nullmailer@cicuta.babolo.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kVXhAStRUZ/+rrGn" Content-Disposition: inline In-Reply-To: <1068806299.210616.7785.nullmailer@cicuta.babolo.ru> User-Agent: Mutt/1.5.4i X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu cc: freebsd-net@freebsd.org Subject: Re: what about 5000 .. 10000 VLANs in one system? 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, 14 Nov 2003 18:47:08 -0000 --kVXhAStRUZ/+rrGn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 14, 2003 at 01:38:19PM +0300, "."@babolo.ru wrote: >=20 > I remember that VLAN tag has 12 bits :-) >=20 > I need in system with 5000 .. 10000 VLAN > interfaces on 2 .. 6 physical ethernets. >=20 > Does anybody has such expienence? > Stability? Performance? I think is should work, but performance may be poor. Currently, vlan_input() finds the correct vlan by searching the list of all vlans until it finds the correct one. For that many vlans, it might be necessicary to modify the code to use some form of balanced tree instead of a simple list. This should be fairly straight forward to fix. -- 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 --kVXhAStRUZ/+rrGn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/tSMjXY6L6fI4GtQRAjDmAJ42Q3egeyFVtFb+NZWH6+EIVKJWRgCgklla TaQ8sUBYgojfOjQ3n3CMECI= =pu7r -----END PGP SIGNATURE----- --kVXhAStRUZ/+rrGn-- From owner-freebsd-net@FreeBSD.ORG Fri Nov 14 10:49:11 2003 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 00DDC16A4CE for ; Fri, 14 Nov 2003 10:49:11 -0800 (PST) Received: from blake.polstra.com (dsl081-189-066.sea1.dsl.speakeasy.net [64.81.189.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id D69F043FBF for ; Fri, 14 Nov 2003 10:49:09 -0800 (PST) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (dsl081-189-067.sea1.dsl.speakeasy.net [64.81.189.67]) by blake.polstra.com (8.12.9p2/8.12.9) with ESMTP id hAEIn48b049042; Fri, 14 Nov 2003 10:49:04 -0800 (PST) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <1068806299.210616.7785.nullmailer@cicuta.babolo.ru> Date: Fri, 14 Nov 2003 10:49:04 -0800 (PST) From: John Polstra To: "."@babolo.ru X-Bogosity: No, tests=bogofilter, spamicity=0.499987, version=0.14.5 cc: freebsd-net@freebsd.org Subject: RE: what about 5000 .. 10000 VLANs in one system? 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, 14 Nov 2003 18:49:11 -0000 On 14-Nov-2003 "."@babolo.ru wrote: > > I remember that VLAN tag has 12 bits :-) > > I need in system with 5000 .. 10000 VLAN > interfaces on 2 .. 6 physical ethernets. Er, so what is your strategy for packing 5000-10000 different values into a 12-bit field? > Does anybody has such expienence? > Stability? Performance? I doubt it would perform very well. When a tagged packet comes into the system, the matching VLAN interface is found using a linear search. It will be pretty slow if there are a lot of VLANs. John From owner-freebsd-net@FreeBSD.ORG Fri Nov 14 10:53:57 2003 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 61B4916A4D0 for ; Fri, 14 Nov 2003 10:53:57 -0800 (PST) Received: from blake.polstra.com (dsl081-189-066.sea1.dsl.speakeasy.net [64.81.189.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A4CA43FA3 for ; Fri, 14 Nov 2003 10:53:56 -0800 (PST) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (dsl081-189-067.sea1.dsl.speakeasy.net [64.81.189.67]) by blake.polstra.com (8.12.9p2/8.12.9) with ESMTP id hAEIrt8b049072; Fri, 14 Nov 2003 10:53:56 -0800 (PST) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20031114184700.GC28455@Odin.AC.HMC.Edu> Date: Fri, 14 Nov 2003 10:53:55 -0800 (PST) From: John Polstra To: Brooks Davis X-Bogosity: No, tests=bogofilter, spamicity=0.499775, version=0.14.5 cc: freebsd-net@freebsd.org Subject: Re: what about 5000 .. 10000 VLANs in one system? 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, 14 Nov 2003 18:53:57 -0000 On 14-Nov-2003 Brooks Davis wrote: > > I think is should work, but performance may be poor. Currently, > vlan_input() finds the correct vlan by searching the list of all vlans > until it finds the correct one. For that many vlans, it might be > necessicary to modify the code to use some form of balanced tree instead > of a simple list. This should be fairly straight forward to fix. Why not simply index directly into an array of 4096 pointers? Anybody running that many VLANs can afford the extra 16 kB per physical interface. John From owner-freebsd-net@FreeBSD.ORG Fri Nov 14 11:07:19 2003 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 B5C9016A4CE for ; Fri, 14 Nov 2003 11:07:19 -0800 (PST) Received: from modernage.dns-safe.com (ns3.dns-safe.com [64.62.137.158]) by mx1.FreeBSD.org (Postfix) with ESMTP id 652F643FB1 for ; Fri, 14 Nov 2003 11:07:18 -0800 (PST) (envelope-from jason@dixongroup.net) Received: from md-wmnsmd-cuda1-c8c-27.chvlva.adelphia.net ([68.170.95.27] helo=uniauth1.corp.digex.com) by modernage.dns-safe.com with esmtp (Exim 4.24) id 1AKjHq-0000uc-JR for freebsd-net@freebsd.org; Fri, 14 Nov 2003 13:06:56 -0600 From: Jason Dixon To: freebsd-net@freebsd.org In-Reply-To: <1068831665.2775.33.camel@lappy.fuzzypenguin.net> References: <1068789760.2775.18.camel@lappy.fuzzypenguin.net> <1068813508.814.4.camel@localhost> <1068831665.2775.33.camel@lappy.fuzzypenguin.net> Content-Type: text/plain Organization: DixonGroup Consulting Message-Id: <1068836821.2775.42.camel@lappy.fuzzypenguin.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 14 Nov 2003 14:07:01 -0500 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - modernage.dns-safe.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dixongroup.net Subject: Re: Static route via address, not interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2003 19:07:19 -0000 On Fri, 2003-11-14 at 12:41, Jason Dixon wrote: > I'm attempting to create a static route for my FreeBSD host so that > *all* local traffic is routed across the gateway firewall, rather than > being delivered on the local network segment, as is the default with > LANs. If you view the routing table (below) again, you'll notice that > traffic from the FreeBSD box (192.168.0.53) to another box on the same > subnet (192.168.0.42) is still being delivered locally, rather than > being routed through the gateway (192.168.0.1). This is *after* I've > added a static route for 192.168.0.0/24 to use 192.168.0.1. Sorry for the self-reply, but I noticed some interesting behavior. Using the "static_routes" entry in rc.conf, I noticed that the following has no effect... static_routes="test" route_test="-net 192.168.0.0/24 192.168.0.1" But this works great, on a host-by-host basis... static_routes="test" route_test="-host 192.168.0.42/32 192.168.0.1" Obviously, this doesn't scale. Can anyone think of a way to override the local routing behavior? Thanks! -- Jason Dixon, RHCE DixonGroup Consulting http://www.dixongroup.net From owner-freebsd-net@FreeBSD.ORG Fri Nov 14 11:07:37 2003 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 D8F9016A4CE; Fri, 14 Nov 2003 11:07:37 -0800 (PST) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 85AB943FA3; Fri, 14 Nov 2003 11:07:36 -0800 (PST) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id ACD4765418; Fri, 14 Nov 2003 19:07:33 +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 96911-03; Fri, 14 Nov 2003 19:07:33 +0000 (GMT) Received: from saboteur.dek.spc.org (unknown [82.147.19.91]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id A13966520E; Fri, 14 Nov 2003 19:07:32 +0000 (GMT) Received: by saboteur.dek.spc.org (Postfix, from userid 1001) id 5338026; Fri, 14 Nov 2003 19:07:30 +0000 (GMT) Date: Fri, 14 Nov 2003 19:07:30 +0000 From: Bruce M Simpson To: harti@freebsd.org Message-ID: <20031114190730.GD64140@saboteur.dek.spc.org> Mail-Followup-To: harti@freebsd.org, Bruce M Simpson , Robert Watson , freebsd-net@freebsd.org References: <20031110073822.GA20611@saboteur.dek.spc.org> <20031110191454.GC662@saboteur.dek.spc.org> <20031110204652.A84670@beagle.fokus.fraunhofer.de> <20031110221139.GB2441@saboteur.dek.spc.org> <20031111092650.P7611@beagle.fokus.fraunhofer.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031111092650.P7611@beagle.fokus.fraunhofer.de> cc: Robert Watson cc: freebsd-net@freebsd.org Subject: Re: Viewing multicast group membership? 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, 14 Nov 2003 19:07:38 -0000 On Tue, Nov 11, 2003 at 09:29:49AM +0100, Harti Brandt wrote: > Here you are. This was even once (about a year ago) reviewed by someone, > but did make it into the tree, because I did not insist. Committed with userland API and some fixups. Thanks! BMS From owner-freebsd-net@FreeBSD.ORG Fri Nov 14 11:14:03 2003 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 EAEEE16A4CE for ; Fri, 14 Nov 2003 11:14:03 -0800 (PST) Received: from relay.macomnet.ru (relay.macomnet.ru [195.128.64.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1322B43FBF for ; Fri, 14 Nov 2003 11:14:00 -0800 (PST) (envelope-from maxim@macomnet.ru) Received: from news1.macomnet.ru (ydhsbkam@news1.macomnet.ru [195.128.64.14]) by relay.macomnet.ru (8.12.10/8.12.10) with ESMTP id hAEJDiSi23725575; Fri, 14 Nov 2003 22:13:44 +0300 (MSK) Date: Fri, 14 Nov 2003 22:13:44 +0300 (MSK) From: Maxim Konovalov To: Jim Xochellis In-Reply-To: <2F1F5F98-16AB-11D8-B2D7-003065C4E486@escape.gr> Message-ID: <20031114221030.E70547@news1.macomnet.ru> References: <2F1F5F98-16AB-11D8-B2D7-003065C4E486@escape.gr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: net@freebsd.org Subject: Re: ip-up script of pppd no triggered 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, 14 Nov 2003 19:14:04 -0000 On Fri, 14 Nov 2003, 16:02+0200, Jim Xochellis wrote: > Hi list, > > I have also posted this mail to the freebsd-questions list a few days > ago, but I had no luck. Hence, I decided to try this list too, which > probably is the most appropriate for my problem. > > I need to persuade pppd to call its ip-up script in order to add a > non-default route as soon as the link is up and running. Unfortunately > it seems that my ip-up script is not being called. The mode of the file > is rwxr-xr-x and the owner root:wheel. I am calling the pppd from > inside a "/usr/local/etc/rc.d/ppp.sh" script by using the following > command: > "/usr/sbin/pppd /dev/cuaa0 115200 A.A.A.A:B.B.B.B noauth persist > netmask 255.255.255.252" > > I have read all the chapter #18 of the handbook, but I haven't found > anything about the ip-up script. On the contrary the PPPD(8) man page > claims that the /etc/ppp/ip-up is executed when the link is available > for sending and receiving IP packets. My link becomes available for > sending/receiving IP packets, but ip-up is never executed. Any ideas > why? > By the way, I am using kernel PPP, (on ppp0) if it makes any difference. > > Am I doing something wrong? Did you look at /usr/share/examples/pppd/ip-up.sample ? ip-up worked for me six months ago. -- Maxim Konovalov, maxim@macomnet.ru, maxim@FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Fri Nov 14 11:23:04 2003 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 10F4716A4CE for ; Fri, 14 Nov 2003 11:23:04 -0800 (PST) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 403BA43FAF for ; Fri, 14 Nov 2003 11:23:03 -0800 (PST) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.9/8.12.3) with ESMTP id hAEJMwOT014749; Fri, 14 Nov 2003 11:22:58 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.9/8.12.3/Submit) id hAEJMwEE014746; Fri, 14 Nov 2003 11:22:58 -0800 Date: Fri, 14 Nov 2003 11:22:58 -0800 From: Brooks Davis To: John Polstra Message-ID: <20031114192258.GD28455@Odin.AC.HMC.Edu> References: <20031114184700.GC28455@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EY/WZ/HvNxOox07X" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu cc: freebsd-net@freebsd.org Subject: Re: what about 5000 .. 10000 VLANs in one system? 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, 14 Nov 2003 19:23:04 -0000 --EY/WZ/HvNxOox07X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 14, 2003 at 10:53:55AM -0800, John Polstra wrote: > On 14-Nov-2003 Brooks Davis wrote: > >=20 > > I think is should work, but performance may be poor. Currently, > > vlan_input() finds the correct vlan by searching the list of all vlans > > until it finds the correct one. For that many vlans, it might be > > necessicary to modify the code to use some form of balanced tree instead > > of a simple list. This should be fairly straight forward to fix. >=20 > Why not simply index directly into an array of 4096 pointers? Anybody > running that many VLANs can afford the extra 16 kB per physical > interface. I suggested the balanced tree because we've got two implementations in sys/tree.h, but you are correct that the space probably isn't worth the overhead of the trees. You'd have to use per physical interface trees anyway, so that part would be the same. -- 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 --EY/WZ/HvNxOox07X Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/tSuQXY6L6fI4GtQRAisYAJ48TiJjeeMm2Wyd4tpQhuU5q6xg1gCgkJPD aJwpoqSPe3Hzz0ltYvhSHYQ= =ZCHr -----END PGP SIGNATURE----- --EY/WZ/HvNxOox07X-- From owner-freebsd-net@FreeBSD.ORG Fri Nov 14 12:10:27 2003 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 91B9616A4CE for ; Fri, 14 Nov 2003 12:10:27 -0800 (PST) Received: from ns1.interbgc.com (mail.interbgc.com [217.9.224.3]) by mx1.FreeBSD.org (Postfix) with SMTP id 8ECDD44034 for ; Fri, 14 Nov 2003 12:10:25 -0800 (PST) (envelope-from misho@interbgc.com) Received: (qmail 11631 invoked from network); 14 Nov 2003 20:10:23 -0000 Received: from misho@interbgc.com by keeper.interbgc.com by uid 1002 with qmail-scanner-1.14 (uvscan: v4.1.60/v4301. spamassassin: 2.50. Clear:SA:0(-10.5/8.0):. Processed in 0.31498 secs); 14 Nov 2003 20:10:23 -0000 X-Spam-Status: No, hits=-10.5 required=8.0 Received: from misho.ddns.cablebg.net (HELO mishovsqmdizm8) (213.240.202.214) by mail.interbgc.com with SMTP; 14 Nov 2003 20:10:23 -0000 Message-ID: <009401c3aaeb$3eecd210$d6caf0d5@mishovsqmdizm8> From: "Mihail Balikov" To: References: Date: Fri, 14 Nov 2003 22:09:44 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4922.1500 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 Subject: Re: what about 5000 .. 10000 VLANs in one system? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Mihail Balikov List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2003 20:10:27 -0000 > > Why not simply index directly into an array of 4096 pointers? Anybody > running that many VLANs can afford the extra 16 kB per physical > interface. > > John I have wrote such patch for STABLE. On router with ~150 vlans and 50kpps, it works very well Mihail From owner-freebsd-net@FreeBSD.ORG Fri Nov 14 12:12:34 2003 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 2E79516A4CE; Fri, 14 Nov 2003 12:12:34 -0800 (PST) Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by mx1.FreeBSD.org (Postfix) with ESMTP id A43A544017; Fri, 14 Nov 2003 12:12:31 -0800 (PST) (envelope-from cristjc@comcast.net) Received: from blossom.cjclark.org (12-234-156-182.client.attbi.com[12.234.156.182]) by comcast.net (sccrmhc12) with ESMTP id <2003111420123001200s535ue>; Fri, 14 Nov 2003 20:12:30 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.9p2/8.12.8) with ESMTP id hAEKCmsb062924; Fri, 14 Nov 2003 12:12:48 -0800 (PST) (envelope-from cristjc@comcast.net) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.9p2/8.12.9/Submit) id hAEKCkrn062923; Fri, 14 Nov 2003 12:12:46 -0800 (PST) (envelope-from cristjc@comcast.net) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to cristjc@comcast.net using -f Date: Fri, 14 Nov 2003 12:12:46 -0800 From: "Crist J. Clark" To: Helge Oldach Message-ID: <20031114201246.GA62521@blossom.cjclark.org> References: <20031114163654.GB61960@blossom.cjclark.org> <200311141722.SAA19138@galaxy.hbg.de.ao-srv.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200311141722.SAA19138@galaxy.hbg.de.ao-srv.com> User-Agent: Mutt/1.4.1i X-URL: http://people.freebsd.org/~cjc/ cc: freebsd-isp@freebsd.org cc: freebsd-ipfw@freebsd.org cc: vgoupil@alis.com cc: freebsd-net@freebsd.org Subject: Re: IPSec VPN & NATD (problem with alias_address vs redirect_addr ess) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: cjclark@alum.mit.edu List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2003 20:12:34 -0000 On Fri, Nov 14, 2003 at 06:22:55PM +0100, Helge Oldach wrote: > Crist J. Clark: [snip] > >> This is actually implemented in most modern VPN > >> devices. They do NAT translation according to SPI. The alternative is to > >> encapsulate IPSec traffic in UDP (using port 4500) packets which can be > >> neatly NATted. > > > >It's not actually very neat. Most vendor kludges to do this are not > >interoperable. The IETF draft for it isn't widely implemented AFAIK. > > As I said, must modern VPN devices have it. As a minimum, virtually any > el-cheapo DSL router supports ESP-NAT for a single device (assuming that > all SPIs belong to a single internal address). But many also support > SPI-aware NAT. FreeBSD natd(8) will work fine for a single VPN end point behind a many-to-one mapping. In fact, it will work fine for arbitrarily many VPN end points behind NAT as long as each one has a unique address at the other end. > >> In Cisco IOS speak: > >> > >> cisco(config)#crypto ipsec nat-transparency ? > >> spi-matching Match inbound SPI to outbound SPI for IPsec aware NAT > > > >Not sure what that is going to accomplish. The inbound SPI and > >outbound SPI are, in general, completely indpendent values. The whole > >problem is that there is no way to know what the incoming (from the > >external VPN end point to the one behind the NAT device) SPI is going > >to be. > > Correct. Cisco requires that you use IKE in order to make it work. > Basically this is NAT for ESP, and the SPI-NAT table is being built up > using IKE cookie matching. There is no heuristics involved. The IKE cookies, the IKE-SPI, do not have anything to do with IPsec protocol SPIs. The cookies can be used to perform NAT tricks with IKE traffic, but not IPsec (unless there are proprietary vendor kludges to make the IPsec SPIs derivatives of the IKE-SPI). > >> udp-encapsulation UDP encapsulation of IPsec protocols > >> cisco(config)# > >> > >> The core issue is that FreeBSD does neither support SPI-based NAT, > > > >'Cause unless you have a hacked up IPsec implementation that uses the > >same SPI both directions, it is useless. > > Nothing that works well and has noticeable exposure is useless. This > definitely has both. Not with FreeBSD, though. It does work with Windows > 2000 SP4, to put a name up... So it's definitely out there. Two different ESP end points behind many-to-one NAT connected to a single ESP end point on the other side of the NAT? I'd be very curious to get the documentation on how they are cheating to get that to work. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org From owner-freebsd-net@FreeBSD.ORG Fri Nov 14 12:28:56 2003 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 71DC716A4CE for ; Fri, 14 Nov 2003 12:28:56 -0800 (PST) Received: from overlord.e-gerbil.net (e-gerbil.net [69.31.1.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2DE2943FE0 for ; Fri, 14 Nov 2003 12:28:53 -0800 (PST) (envelope-from ras@overlord.e-gerbil.net) Received: from overlord.e-gerbil.net (ras@localhost.e-gerbil.net [127.0.0.1]) by overlord.e-gerbil.net (8.12.9/8.12.9) with ESMTP id hAEKSpjg078330; Fri, 14 Nov 2003 15:28:51 -0500 (EST) (envelope-from ras@overlord.e-gerbil.net) Received: (from ras@localhost) by overlord.e-gerbil.net (8.12.9/8.12.9/Submit) id hAEKSlLf078329; Fri, 14 Nov 2003 15:28:47 -0500 (EST) (envelope-from ras) Date: Fri, 14 Nov 2003 15:28:47 -0500 From: Richard A Steenbergen To: Haesu Message-ID: <20031114202847.GX82121@overlord.e-gerbil.net> References: <20031112024507.89398.qmail@web10007.mail.yahoo.com> <3FB20D2B.73624906@pipeline.ch> <20031112195529.GA48020@scylla.towardex.com> <3FB37F09.4050908@lowinger.se> <20031113135130.GA22054@scylla.towardex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031113135130.GA22054@scylla.towardex.com> User-Agent: Mutt/1.5.1i cc: freebsd-net@freebsd.org Subject: Re: tcp hostcache and ip fastforward for review 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, 14 Nov 2003 20:28:56 -0000 On Thu, Nov 13, 2003 at 08:51:30AM -0500, Haesu wrote: > > Yup, and we use it extensively at the border (Netflow) to do accounting and > traffic statistics as well. But still, Cisco relies on use of CEF to actually > route, I believe Netflow is used for accounting purposes now (although back > in the old days, netflow used to be the acceleration mechanism, but CEF took > over the routing part..).....<--But, I may be wrong here :) Where as at the > same time, many "layer-3 switches" vendors (the E vendor, the F vendor, tsk > tsk) completely rely on use of flow based for actual _routing_ of the packet > while marketing their stuff "OMG 16GBPS BACKBPLANE". Well, 16Gbps is good and > all during well behaved traffic, but good luck handling a diverse DoS :( > > I've had an > E-vendor switch that went haywire during 56kpps diverse-destination DDoS a while > back.. Hrm looks like I missed some interesting discussion while not reading this list. :) You're a little off on the implementation of the layer 3 switches. They do not use "flows" persay, but rather their hardware destination lookups are not pre-programmed. This means that when you hit a new destination which has never been seen before, the software must do a slow lookup to program the CAM. This is more like Cisco's fastcache than flowcache, but yes the end result is poor (or rather, unpredictable) performance during random destination routing (worms anyone). The correct solution for scale is to pre-populate the forwarding db with resolutions for every route, every time a routing change is made. In software this is done with a forwarding-only data structure called a FIB, usually a multibit trie. Trading off a meg or two of memory for enhanced and consistant routing performance is certainly acceptable for a router, but it may not make as much sense for a host. Also something to note is that once you move to an architecture which is assured of having a FIB (for longest prefix match lookups), a patricia tree as a RIB becomes one of the worst implementations you can use (for only insertions, deletions, and exact matches). If you're making a router, this is certainly the way to go, but for a host I suspect you're probably going to end up stuck with a toggle switch and a patricia rib for a while to come. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From owner-freebsd-net@FreeBSD.ORG Fri Nov 14 12:43:46 2003 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 B0B3D16A4CE for ; Fri, 14 Nov 2003 12:43:46 -0800 (PST) Received: from overlord.e-gerbil.net (e-gerbil.net [69.31.1.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id B060243FD7 for ; Fri, 14 Nov 2003 12:43:45 -0800 (PST) (envelope-from ras@overlord.e-gerbil.net) Received: from overlord.e-gerbil.net (ras@localhost.e-gerbil.net [127.0.0.1]) by overlord.e-gerbil.net (8.12.9/8.12.9) with ESMTP id hAEKhijg078446; Fri, 14 Nov 2003 15:43:44 -0500 (EST) (envelope-from ras@overlord.e-gerbil.net) Received: (from ras@localhost) by overlord.e-gerbil.net (8.12.9/8.12.9/Submit) id hAEKhiYB078445; Fri, 14 Nov 2003 15:43:44 -0500 (EST) (envelope-from ras) Date: Fri, 14 Nov 2003 15:43:44 -0500 From: Richard A Steenbergen To: Haesu Message-ID: <20031114204344.GY82121@overlord.e-gerbil.net> References: <20031112024507.89398.qmail@web10007.mail.yahoo.com> <3FB20D2B.73624906@pipeline.ch> <20031112195529.GA48020@scylla.towardex.com> <3FB37F09.4050908@lowinger.se> <20031113135130.GA22054@scylla.towardex.com> <20031114202847.GX82121@overlord.e-gerbil.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031114202847.GX82121@overlord.e-gerbil.net> User-Agent: Mutt/1.5.1i cc: freebsd-net@freebsd.org Subject: Re: tcp hostcache and ip fastforward for review 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, 14 Nov 2003 20:43:46 -0000 On Fri, Nov 14, 2003 at 03:28:47PM -0500, Richard A Steenbergen wrote: > > You're a little off on the implementation of the layer 3 switches. They do > not use "flows" persay, but rather their hardware destination lookups are > not pre-programmed. This means that when you hit a new destination which > has never been seen before, the software must do a slow lookup to program > the CAM. This is more like Cisco's fastcache than flowcache, but yes the > end result is poor (or rather, unpredictable) performance during random > destination routing (worms anyone). Actually I'll take that back, as it's not 100% accurate for everyone. Some vendors actually do install a /32 route for every active destination by traffic (which still isn't quite netflow, src+dst+port+(maybe tos) pairs, but almost as bad). Without some form of accelerated expiration mechanism under load (coughghettohackcough), you end up exhausting the cache space available. It's just shooting yourself in the same foot with a different gun. The other ghetto hack available is to aggregate CAM entries, usually based on having default routes and very few real egress ports. I believe Cisco is actually pre-programming the CAM starting on the sup2/msfc2 now. Bottom line, that kind of performance is what you get when you take hardware designed for layer 2 exact match lookups (mac addresses), try to turn it into a caching mechanism for l3 routing, and sell it to enterprise customers who don't really care about performance under "core routing" (or otherwise random destination) conditions. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From owner-freebsd-net@FreeBSD.ORG Fri Nov 14 15:05:03 2003 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 056CC16A4CE for ; Fri, 14 Nov 2003 15:05:03 -0800 (PST) Received: from sizone.org (mortar.sizone.org [65.126.154.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id F280F43FAF for ; Fri, 14 Nov 2003 15:05:01 -0800 (PST) (envelope-from dgilbert@daveg.ca) Received: by sizone.org (Postfix, from userid 66) id 2BF4C30693; Fri, 14 Nov 2003 18:05:01 -0500 (EST) Received: by canoe.dclg.ca (Postfix, from userid 101) id 4353B1D1D0E; Fri, 14 Nov 2003 18:05:04 -0500 (EST) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16309.24479.422972.852980@canoe.dclg.ca> Date: Fri, 14 Nov 2003 18:05:03 -0500 To: Brooks Davis In-Reply-To: <20031114192258.GD28455@Odin.AC.HMC.Edu> References: <20031114184700.GC28455@Odin.AC.HMC.Edu> <20031114192258.GD28455@Odin.AC.HMC.Edu> X-Mailer: VM 7.17 under 21.4 (patch 14) "Reasonable Discussion" XEmacs Lucid cc: freebsd-net@freebsd.org cc: John Polstra Subject: Re: what about 5000 .. 10000 VLANs in one system? 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, 14 Nov 2003 23:05:03 -0000 >>>>> "Brooks" == Brooks Davis writes: >> Why not simply index directly into an array of 4096 pointers? >> Anybody running that many VLANs can afford the extra 16 kB per >> physical interface. Brooks> I suggested the balanced tree because we've got two Brooks> implementations in sys/tree.h, but you are correct that the Brooks> space probably isn't worth the overhead of the trees. You'd Brooks> have to use per physical interface trees anyway, so that part Brooks> would be the same. I would vote for the 4096 pointer model (or at least an option for same). We often use machines with 100 or more vlans. Constant time packet delivery is a "good thing" (tm). Dave. -- ============================================================================ |David Gilbert, Independent Contractor. | Two things can only be | |Mail: dave@daveg.ca | equal if and only if they | |http://daveg.ca | are precisely opposite. | =========================================================GLO================ From owner-freebsd-net@FreeBSD.ORG Fri Nov 14 15:16:37 2003 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 4AE7616A4CE for ; Fri, 14 Nov 2003 15:16:37 -0800 (PST) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id D1EFE43F85 for ; Fri, 14 Nov 2003 15:16:35 -0800 (PST) (envelope-from oppermann@pipeline.ch) Received: (qmail 51326 invoked from network); 14 Nov 2003 23:19:30 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 14 Nov 2003 23:19:30 -0000 Message-ID: <3FB56251.F58DBF6A@pipeline.ch> Date: Sat, 15 Nov 2003 00:16:33 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: David Gilbert References: <20031114184700.GC28455@Odin.AC.HMC.Edu> <16309.24479.422972.852980@canoe.dclg.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: John Polstra Subject: Re: what about 5000 .. 10000 VLANs in one system? 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, 14 Nov 2003 23:16:37 -0000 David Gilbert wrote: > > >>>>> "Brooks" == Brooks Davis writes: > > >> Why not simply index directly into an array of 4096 pointers? > >> Anybody running that many VLANs can afford the extra 16 kB per > >> physical interface. > > Brooks> I suggested the balanced tree because we've got two > Brooks> implementations in sys/tree.h, but you are correct that the > Brooks> space probably isn't worth the overhead of the trees. You'd > Brooks> have to use per physical interface trees anyway, so that part > Brooks> would be the same. > > I would vote for the 4096 pointer model (or at least an option for > same). We often use machines with 100 or more vlans. Constant time > packet delivery is a "good thing" (tm). Yes, my vote would go there as well. -- Andre From owner-freebsd-net@FreeBSD.ORG Fri Nov 14 17:15:44 2003 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 0D04816A4CE for ; Fri, 14 Nov 2003 17:15:44 -0800 (PST) Received: from ints.mail.pike.ru (ints.mail.pike.ru [195.9.45.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 840B743FD7 for ; Fri, 14 Nov 2003 17:15:40 -0800 (PST) (envelope-from babolo@cicuta.babolo.ru) Received: (qmail 75609 invoked from network); 15 Nov 2003 01:29:48 -0000 Received: from babolo.ru (HELO cicuta.babolo.ru) (194.58.226.160) by ints.mail.pike.ru with SMTP; 15 Nov 2003 01:29:48 -0000 Received: (nullmailer pid 95548 invoked by uid 136); Sat, 15 Nov 2003 01:17:33 -0000 X-ELM-OSV: (Our standard violations) hdr-charset=KOI8-R; no-hdr-encoding=1 In-Reply-To: <3FB56251.F58DBF6A@pipeline.ch> To: Andre Oppermann Date: Sat, 15 Nov 2003 04:17:32 +0300 (MSK) From: "."@babolo.ru X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <1068859053.126816.95547.nullmailer@cicuta.babolo.ru> cc: freebsd-net@freebsd.org cc: David Gilbert Subject: Re: what about 5000 .. 10000 VLANs in one system? 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, 15 Nov 2003 01:15:44 -0000 > David Gilbert wrote: > > > > >>>>> "Brooks" == Brooks Davis writes: > > > > >> Why not simply index directly into an array of 4096 pointers? > > >> Anybody running that many VLANs can afford the extra 16 kB per > > >> physical interface. > > > > Brooks> I suggested the balanced tree because we've got two > > Brooks> implementations in sys/tree.h, but you are correct that the > > Brooks> space probably isn't worth the overhead of the trees. You'd > > Brooks> have to use per physical interface trees anyway, so that part > > Brooks> would be the same. > > > > I would vote for the 4096 pointer model (or at least an option for > > same). We often use machines with 100 or more vlans. Constant time > > packet delivery is a "good thing" (tm). > Yes, my vote would go there as well. theoretically each ethernet interface can have about 4000 VLANs, and 26 ethernets in one PC ip possible (but my routers maximum is 12) so table expandable by 2x is interesting (4096, 8192, 16384) Sorry my bad English From owner-freebsd-net@FreeBSD.ORG Fri Nov 14 21:18:53 2003 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 9C7B616A4CE for ; Fri, 14 Nov 2003 21:18:53 -0800 (PST) Received: from overlord.e-gerbil.net (e-gerbil.net [69.31.1.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB5FB43FBF for ; Fri, 14 Nov 2003 21:18:52 -0800 (PST) (envelope-from ras@overlord.e-gerbil.net) Received: from overlord.e-gerbil.net (ras@localhost.e-gerbil.net [127.0.0.1]) by overlord.e-gerbil.net (8.12.9/8.12.9) with ESMTP id hAF5Imjg081492; Sat, 15 Nov 2003 00:18:48 -0500 (EST) (envelope-from ras@overlord.e-gerbil.net) Received: (from ras@localhost) by overlord.e-gerbil.net (8.12.9/8.12.9/Submit) id hAF5IlVg081491; Sat, 15 Nov 2003 00:18:47 -0500 (EST) (envelope-from ras) Date: Sat, 15 Nov 2003 00:18:47 -0500 From: Richard A Steenbergen To: John Polstra Message-ID: <20031115051847.GC82121@overlord.e-gerbil.net> References: <1068806299.210616.7785.nullmailer@cicuta.babolo.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i cc: "."@babolo.ru cc: freebsd-net@freebsd.org Subject: Re: what about 5000 .. 10000 VLANs in one system? 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, 15 Nov 2003 05:18:53 -0000 On Fri, Nov 14, 2003 at 10:49:04AM -0800, John Polstra wrote: > On 14-Nov-2003 "."@babolo.ru wrote: > > > > I remember that VLAN tag has 12 bits :-) > > > > I need in system with 5000 .. 10000 VLAN > > interfaces on 2 .. 6 physical ethernets. > > Er, so what is your strategy for packing 5000-10000 different values > into a 12-bit field? 2-3 interfaces. :) or There are quite a few "double vlan" implementations out there if you're really that desperate, though I don't think there is a standard so that they all interoperate. This is mainly used to provision metro ethernet services where you provide a vlan per customer and they want to be able to use their own vlans without consulting you for numbering. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From owner-freebsd-net@FreeBSD.ORG Fri Nov 14 22:55:33 2003 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 7B5F916A4CE; Fri, 14 Nov 2003 22:55:33 -0800 (PST) Received: from mizar.origin-it.net (mizar.origin-it.net [194.8.96.234]) by mx1.FreeBSD.org (Postfix) with ESMTP id D397F43F85; Fri, 14 Nov 2003 22:55:31 -0800 (PST) (envelope-from Helge.Oldach@atosorigin.com) Received: from matar.hbg.de.int.atosorigin.com (dehsfw3e.origin-it.net [194.8.96.68])hAF6soUQ023422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Nov 2003 07:54:51 +0100 (CET) (envelope-from Helge.Oldach@atosorigin.com) Received: from dehhx004.hbg.de.int.atosorigin.com (dehhx004.hbg.de.int.atosorigin.com [161.90.164.40]) ESMTP id hAF6so35007855; Sat, 15 Nov 2003 07:54:50 +0100 (CET) (envelope-from Helge.Oldach@atosorigin.com) Received: by dehhx004.hbg.de.int.atosorigin.com with Internet Mail Service (5.5.2657.72) id ; Sat, 15 Nov 2003 07:54:50 +0100 Message-ID: From: "Oldach, Helge" To: "'cjclark@alum.mit.edu'" Date: Sat, 15 Nov 2003 07:54:40 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" cc: freebsd-isp@freebsd.org cc: freebsd-ipfw@freebsd.org cc: vgoupil@alis.com cc: freebsd-net@freebsd.org Subject: RE: IPSec VPN & NATD (problem with alias_address vs redirect_addr ess) 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, 15 Nov 2003 06:55:33 -0000 From: Crist J. Clark [mailto:cristjc@comcast.net] > On Fri, Nov 14, 2003 at 06:22:55PM +0100, Helge Oldach wrote: > > Nothing that works well and has noticeable exposure is useless. This > > definitely has both. Not with FreeBSD, though. It does work with Windows > > 2000 SP4, to put a name up... So it's definitely out there. > > Two different ESP end points behind many-to-one NAT connected to a > single ESP end point on the other side of the NAT? I'd be very curious > to get the documentation on how they are cheating to get that to work. You have posted a reference already. W2k SP4 supports UDP encapsulation of IPSec. And yes, it works fine, and reliably. Further, all of Cisco's and Checkpoints VPN gear support IPSec-over-UDP as well. This alone is >70% market share. Note that an MS employee has co-authored one of the IETF drafts you had mentioned. This is apparently not just coincidence... I do well understand that there is no general solution. However, FreeBSD is definitely behind what is available on the commercial market today. Call it "cheating" - but it's out there and it works. I would rather prefer to see a feature that doesn't solve a 100% case than to see nothing because we feel that a "general specification" is missing. Helge From owner-freebsd-net@FreeBSD.ORG Sat Nov 15 04:52:06 2003 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 1739316A4CE for ; Sat, 15 Nov 2003 04:52:06 -0800 (PST) Received: from freebsd.giovannelli.com (freebsd.giovannelli.com [194.184.65.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id 453E443FDF for ; Sat, 15 Nov 2003 04:52:01 -0800 (PST) (envelope-from gmarco@giovannelli.it) Received: from usul.giovannelli.it (usul.giovannelli.com [10.254.254.4]) hAFCreuE033183; Sat, 15 Nov 2003 13:53:41 +0100 (CET) (envelope-from gmarco@giovannelli.it) Message-Id: <6.0.0.22.2.20031115121950.03168f20@194.184.65.4> X-Sender: gmarco@194.184.65.4 (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Sat, 15 Nov 2003 13:58:28 +0100 To: net@freebsd.org From: Gianmarco Giovannelli Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed cc: esperti@gufi.org Subject: mpd & freeradius: MS-CHAP2 problem ? and more ... (long) 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, 15 Nov 2003 12:52:06 -0000 Hi all, I have updated my mpd server (ppptp, on FreeBSD 4.x-stable) to use the last mpd 3.15. I am trying now to authenticate against a freeradius server (FreeBSD 4.x-stable , freeradius 0.9.2). But I got an error : [pptp1] RADIUS: RadiusAddServer Adding 172.16.33.236 [pptp1] RADIUS: RadiusPutAuth: RADIUS_CHAP (MSOFTv2) peer name: gmarco [pptp1] RADIUS: RadiusSendRequest: RAD_ACCESS_ACCEPT for user gmarco [pptp1] RADIUS: RadiusGetParams: RAD_FRAMED_PROTOCOL: 2 [pptp1] RADIUS: RadiusGetParams: RAD_FRAMED_PROTOCOL: 1 [pptp1] RADIUS: RadiusGetParams: RAD_FRAMED_IP_ADDRESS: 192.168.79.253 [pptp1] RADIUS: RadiusGetParams: RAD_FRAMED_IP_NETMASK: 255.255.255.255 [pptp1] RADIUS: RadiusGetParams: PANIC no MS-CHAPv2 response received #### MPD #### mpd.conf is: ---> begin <--- default: load client1 load client2 [...] client1: new -i ng0 pptp1 pptp1 load pptp_common_settings client2: new -i ng1 pptp2 pptp2 load pptp_common_settings [...] pptp_common_settings: set iface disable on-demand set iface enable proxy-arp set iface idle 0 set iface enable tcpmssfix set link yes acfcomp protocomp set link no pap chap set link enable chap set link mtu 1440 set link keep-alive 25 60 set ipcp yes vjcomp set ipcp dns 172.16.16.254 set ipcp nbns 172.16.16.254 set bundle enable multilink set bundle enable compression set ccp yes mppc set ccp yes mpp-e40 set ccp yes mpp-e128 set ccp yes mpp-stateless load radius radius: set radius retries 3 set radius timeout 3 set radius server 172.16.33.236 testing123 1812 1813 set radius me 172.16.16.239 set ipcp yes radius-ip set bundle enable radius-auth radius-fallback set bundle enable radius-acct ---> end <--- mpd.log are: ---> begin <--- Nov 15 12:19:08 freebsd mpd: [pptp1] IFACE: Open event Nov 15 12:19:08 freebsd mpd: [pptp1] IPCP: Open event Nov 15 12:19:08 freebsd mpd: [pptp1] IPCP: state change Initial --> Starting Nov 15 12:19:08 freebsd mpd: [pptp1] IPCP: LayerStart Nov 15 12:19:08 freebsd mpd: [pptp1] IPCP: Open event Nov 15 12:19:08 freebsd mpd: [pptp1] bundle: OPEN event in state CLOSED Nov 15 12:19:08 freebsd mpd: [pptp1] opening link "pptp1"... Nov 15 12:19:08 freebsd mpd: [pptp1] link: OPEN event Nov 15 12:19:08 freebsd mpd: [pptp1] LCP: Open event Nov 15 12:19:08 freebsd mpd: [pptp1] LCP: state change Initial --> Starting Nov 15 12:19:08 freebsd mpd: [pptp1] LCP: LayerStart Nov 15 12:19:08 freebsd mpd: [pptp1] device: OPEN event in state DOWN Nov 15 12:19:08 freebsd mpd: [pptp1] attaching to peer's outgoing call Nov 15 12:19:08 freebsd mpd: [pptp1] device is now in state OPENING Nov 15 12:19:08 freebsd mpd: [pptp1] device: UP event in state OPENING Nov 15 12:19:08 freebsd mpd: [pptp1] device is now in state UP Nov 15 12:19:08 freebsd mpd: [pptp1] link: UP event Nov 15 12:19:08 freebsd mpd: [pptp1] link: origination is remote Nov 15 12:19:08 freebsd mpd: [pptp1] LCP: Up event Nov 15 12:19:08 freebsd mpd: [pptp1] LCP: state change Starting --> Req-Sent Nov 15 12:19:08 freebsd mpd: [pptp1] LCP: phase shift DEAD --> ESTABLISH Nov 15 12:19:08 freebsd mpd: [pptp1] LCP: SendConfigReq #1 Nov 15 12:19:08 freebsd mpd: ACFCOMP Nov 15 12:19:08 freebsd mpd: PROTOCOMP Nov 15 12:19:08 freebsd mpd: MRU 1500 Nov 15 12:19:08 freebsd mpd: MAGICNUM 57172c6d Nov 15 12:19:08 freebsd mpd: AUTHPROTO CHAP MSOFTv2 Nov 15 12:19:08 freebsd mpd: [pptp1] LCP: rec'd Configure Request #1 link 0 (Req-Sent) Nov 15 12:19:08 freebsd mpd: PROTOCOMP Nov 15 12:19:08 freebsd mpd: ACFCOMP Nov 15 12:19:08 freebsd mpd: [pptp1] LCP: SendConfigAck #1 Nov 15 12:19:08 freebsd mpd: PROTOCOMP Nov 15 12:19:08 freebsd mpd: ACFCOMP Nov 15 12:19:08 freebsd mpd: ACFCOMP Nov 15 12:19:08 freebsd mpd: PROTOCOMP Nov 15 12:19:08 freebsd mpd: MRU 1500 Nov 15 12:19:08 freebsd mpd: MAGICNUM 57172c6d Nov 15 12:19:08 freebsd mpd: AUTHPROTO CHAP MSOFTv2 Nov 15 12:19:08 freebsd mpd: [pptp1] LCP: rec'd Configure Request #1 link 0 (Req-Sent) Nov 15 12:19:08 freebsd mpd: [pptp1] LCP: state change Req-Sent --> Ack-Sent Nov 15 12:19:10 freebsd mpd: [pptp1] LCP: SendConfigReq #2 Nov 15 12:19:10 freebsd mpd: ACFCOMP Nov 15 12:19:10 freebsd mpd: PROTOCOMP Nov 15 12:19:10 freebsd mpd: MRU 1500 Nov 15 12:19:10 freebsd mpd: MAGICNUM 57172c6d Nov 15 12:19:10 freebsd mpd: AUTHPROTO CHAP MSOFTv2 Nov 15 12:19:10 freebsd mpd: [pptp1] LCP: rec'd Configure Reject #2 link 0 (Ack-Sent) Nov 15 12:19:10 freebsd mpd: MAGICNUM 57172c6d Nov 15 12:19:10 freebsd mpd: [pptp1] LCP: SendConfigReq #3 Nov 15 12:19:10 freebsd mpd: ACFCOMP Nov 15 12:19:10 freebsd mpd: PROTOCOMP Nov 15 12:19:10 freebsd mpd: MRU 1500 Nov 15 12:19:10 freebsd mpd: AUTHPROTO CHAP MSOFTv2 Nov 15 12:19:11 freebsd mpd: [pptp1] LCP: rec'd Configure Ack #3 link 0 (Ack-Sent) Nov 15 12:19:11 freebsd mpd: ACFCOMP Nov 15 12:19:11 freebsd mpd: PROTOCOMP Nov 15 12:19:11 freebsd mpd: MRU 1500 Nov 15 12:19:11 freebsd mpd: AUTHPROTO CHAP MSOFTv2 Nov 15 12:19:11 freebsd mpd: [pptp1] LCP: state change Ack-Sent --> Opened Nov 15 12:19:11 freebsd mpd: [pptp1] LCP: phase shift ESTABLISH --> AUTHENTICATE Nov 15 12:19:11 freebsd mpd: [pptp1] LCP: auth: peer wants nothing, I want CHAP Nov 15 12:19:11 freebsd mpd: [pptp1] CHAP: sending CHALLENGE Nov 15 12:19:11 freebsd mpd: [pptp1] LCP: LayerUp Nov 15 12:19:13 freebsd mpd: [pptp1] CHAP: sending CHALLENGE Nov 15 12:19:13 freebsd mpd: [pptp1] CHAP: rec'd RESPONSE #2 Nov 15 12:19:13 freebsd mpd: Name: "gmarco" Nov 15 12:19:13 freebsd mpd: [pptp1] RADIUS: RadiusAddServer Adding 172.16.33.236 Nov 15 12:19:13 freebsd mpd: [pptp1] RADIUS: RadiusPutAuth: RADIUS_CHAP (MSOFTv2) peer name: gmarco Nov 15 12:19:13 freebsd mpd: [pptp1] RADIUS: RadiusSendRequest: RAD_ACCESS_ACCEPT for user gmarco Nov 15 12:19:13 freebsd mpd: [pptp1] RADIUS: RadiusGetParams: RAD_FRAMED_PROTOCOL: 2 Nov 15 12:19:13 freebsd mpd: [pptp1] RADIUS: RadiusPutAuth: RADIUS_CHAP (MSOFTv2) peer name: gmarco Nov 15 12:19:13 freebsd mpd: [pptp1] RADIUS: RadiusSendRequest: RAD_ACCESS_ACCEPT for user gmarco Nov 15 12:19:13 freebsd mpd: [pptp1] RADIUS: RadiusGetParams: RAD_FRAMED_PROTOCOL: 2 Nov 15 12:19:13 freebsd mpd: [pptp1] RADIUS: RadiusGetParams: RAD_FRAMED_PROTOCOL: 1 Nov 15 12:19:13 freebsd mpd: [pptp1] RADIUS: RadiusGetParams: RAD_FRAMED_IP_ADDRESS: 192.168.79.253 Nov 15 12:19:13 freebsd mpd: [pptp1] RADIUS: RadiusGetParams: RAD_FRAMED_IP_NETMASK: 255.255.255.255 Nov 15 12:19:13 freebsd mpd: [pptp1] RADIUS: RadiusGetParams: PANIC no MS-CHAPv2 response received Nov 15 12:19:13 freebsd mpd: Peer name: "gmarco" Nov 15 12:19:13 freebsd mpd: Can't get credentials for "gmarco" Nov 15 12:19:13 freebsd mpd: [pptp1] CHAP: sending FAILURE Nov 15 12:19:13 freebsd mpd: [pptp1] LCP: authorization failed Nov 15 12:19:13 freebsd mpd: [pptp1] device: CLOSE event in state UP Nov 15 12:19:13 freebsd mpd: pptp0-0: clearing call Nov 15 12:19:13 freebsd mpd: pptp0-0: killing channel Nov 15 12:19:13 freebsd mpd: [pptp1] PPTP call terminated Nov 15 12:19:13 freebsd mpd: [pptp1] IFACE: Close event Nov 15 12:19:13 freebsd mpd: [pptp1] IPCP: Close event Nov 15 12:19:13 freebsd mpd: [pptp1] IPCP: state change Starting --> Initial Nov 15 12:19:13 freebsd mpd: [pptp1] IPCP: LayerFinish Nov 15 12:19:13 freebsd mpd: [pptp1] IFACE: Close event Nov 15 12:19:13 freebsd mpd: pptp0: closing connection with xxx.xxx.xxx.xxx:56888 Nov 15 12:19:13 freebsd mpd: [pptp1] IFACE: Close event Nov 15 12:19:13 freebsd mpd: [pptp1] device is now in state CLOSING Nov 15 12:19:13 freebsd mpd: [pptp1] bundle: CLOSE event in state OPENED [...] ---> end <--- mpd.links --> begin <--- pptp1: set link type pptp set pptp self yyy.yyy.yyy.yyy set pptp enable incoming set pptp disable originate [...] ---> end <--- I have an empty mpd.secrets ### FreeRadius #### The (freeradius) users relevant part is: ---> begin <--- gmarco Auth-Type := MS-CHAP, User-Password == "mypwd" Service-Type = Framed-User, Framed-Protocol = PPP, Framed-IP-Address = 192.168.79.253, Framed-IP-Netmask = 255.255.255.255, ---> end <--- and I have in the freeradius radius.conf: ---> begin <--- [...] mschap { authtype = MS-CHAP use_mppe = yes require_encryption = yes require_strong = yes } [...] authorize { preprocess suffix files mschap } authenticate { authtype MS-CHAP { mschap } } ---> end <--- freeradius instead claims that eveything is fine: ---> radius.log <--- Sat Nov 15 12:23:03 2003 : Auth: Login OK: [gmarco/] (from client freebsd port 0 cli xxx.xxx.xxx.xxx) ---> end <--- ---> detail <--- Sat Nov 15 11:06:24 2003 NAS-Identifier = "freebsd.mydomain.it" NAS-IP-Address = 172.16.16.239 NAS-Port = 0 NAS-Port-Type = Virtual Service-Type = Framed-User Framed-Protocol = PPP Calling-Station-Id = "xxx.xxx.xxx.xxx" User-Name = "gmarco" Framed-IP-Address = 192.168.79.253 Acct-Status-Type = Start Acct-Session-Id = "8890553-pptp1" Acct-Multi-Session-Id = "8890553-pptp1" Acct-Link-Count = 1 Acct-Authentic = RADIUS Timestamp = 1068890784 Sat Nov 15 11:07:04 2003 NAS-Identifier = "freebsd.mydomain.it" NAS-IP-Address = 172.16.16.239 NAS-Port = 0 NAS-Port-Type = Virtual Service-Type = Framed-User Framed-Protocol = PPP Calling-Station-Id = "xxx.xxx.xxx.xxx" User-Name = "gmarco" Framed-IP-Address = 192.168.79.253 Acct-Status-Type = Stop Acct-Session-Id = "8890553-pptp1" Acct-Multi-Session-Id = "8890553-pptp1" Acct-Link-Count = 1 Acct-Authentic = RADIUS Acct-Terminate-Cause = User-Request Acct-Session-Time = 60 Acct-Input-Octets = 5055 Acct-Input-Packets = 55 Acct-Output-Octets = 4132 Acct-Output-Packets = 47 Timestamp = 1068890824 --> end <--- If I use an mpd.secret like this for example: ---> begin <--- gmarco mypwd 192.168.78.100 ---> end <--- I get authenticated but I receive a lot of errors like these: --> begin <-- [pptp1] rec'd unexpected protocol COMPD on link 0 [pptp1] CCP: rec'd Configure Request #3 link 0 (Ack-Sent) MPPC 0x010000e0: MPPE, 40 bit, 56 bit, 128 bit, stateless [pptp1] CCP: Checking wether 40 bits are acceptable -> yes [pptp1] CCP: Checking wether 56 bits are acceptable -> no [pptp1] CCP: Checking wether 128 bits are acceptable -> yes [pptp1] CCP: SendConfigNak #3 MPPC 0x01000040: MPPE, 128 bit, stateless [pptp1] CCP: state change Ack-Sent --> Req-Sent [pptp1] CCP: rec'd Configure Ack #6 link 0 (Req-Sent) MPPC 0x01000040: MPPE, 128 bit, stateless [pptp1] CCP: state change Req-Sent --> Ack-Rcvd [pptp1] rec'd unexpected protocol COMPD on link 0 [pptp1] CCP: rec'd Configure Request #3 link 0 (Ack-Rcvd) MPPC 0x010000e0: MPPE, 40 bit, 56 bit, 128 bit, stateless [pptp1] CCP: Checking wether 40 bits are acceptable -> yes [pptp1] CCP: Checking wether 56 bits are acceptable -> no [pptp1] CCP: Checking wether 128 bits are acceptable -> yes [pptp1] CCP: SendConfigNak #3 MPPC 0x01000040: MPPE, 128 bit, stateless [pptp1] CCP: rec'd Configure Request #4 link 0 (Ack-Rcvd) MPPC 0x01000040: MPPE, 128 bit, stateless [pptp1] CCP: Checking wether 128 bits are acceptable -> yes [pptp1] CCP: SendConfigAck #4 MPPC 0x01000040: MPPE, 128 bit, stateless [pptp1] CCP: state change Ack-Rcvd --> Opened [pptp1] CCP: LayerUp Compress using: MPPE, 128 bit, stateless Decompress using: MPPE, 128 bit, stateless [pptp1] setting interface ng0 MTU to 1436 bytes [pptp1] rec'd unexpected protocol 0x4409 on link -1, rejecting [pptp1] rec'd unexpected protocol 0x0099 on link -1, rejecting [pptp1] rec'd unexpected protocol 0x0091 on link -1, rejecting [pptp1] rec'd proto 0xc867 on MP link! (ignoring) ---> end <--- Everything seems fine if I remove the: load radius line from mpd.conf and I use only mpd.secret ... Any idea/help are welcome .... Best Regards, Gianmarco Giovannelli , "Unix expert since yesterday" http://www.gufi.org/~gmarco From owner-freebsd-net@FreeBSD.ORG Sat Nov 15 05:07:07 2003 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 3882516A4CE for ; Sat, 15 Nov 2003 05:07:07 -0800 (PST) Received: from mail.a-quadrat.at (mail.a-quadrat.at [81.223.141.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A37843F93 for ; Sat, 15 Nov 2003 05:07:06 -0800 (PST) (envelope-from mbretter@a-quadrat.at) Received: from [192.168.90.200] (ras01.a-quadrat.at [192.168.90.200]) by files.a-quadrat.at (Postfix) with ESMTP id 1E8275C03C; Sat, 15 Nov 2003 14:06:36 +0100 (CET) Date: Sat, 15 Nov 2003 14:07:01 +0100 (CET) From: Michael Bretterklieber To: Gianmarco Giovannelli In-Reply-To: <6.0.0.22.2.20031115121950.03168f20@194.184.65.4> Message-ID: <20031115135336.T359@worf.a-quadrat.at> References: <6.0.0.22.2.20031115121950.03168f20@194.184.65.4> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: esperti@gufi.org cc: net@freebsd.org Subject: Re: mpd & freeradius: MS-CHAP2 problem ? and more ... (long) 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, 15 Nov 2003 13:07:07 -0000 Hi, On Sat, 15 Nov 2003, Gianmarco Giovannelli wrote: > Hi all, > I have updated my mpd server (ppptp, on FreeBSD 4.x-stable) to use the last > mpd 3.15. > I am trying now to authenticate against a freeradius server (FreeBSD > 4.x-stable , freeradius 0.9.2). > > But I got an error : > > > [pptp1] RADIUS: RadiusAddServer Adding 172.16.33.236 > [pptp1] RADIUS: RadiusPutAuth: RADIUS_CHAP (MSOFTv2) peer name: gmarco > [pptp1] RADIUS: RadiusSendRequest: RAD_ACCESS_ACCEPT for user gmarco > [pptp1] RADIUS: RadiusGetParams: RAD_FRAMED_PROTOCOL: 2 > [pptp1] RADIUS: RadiusGetParams: RAD_FRAMED_PROTOCOL: 1 > [pptp1] RADIUS: RadiusGetParams: RAD_FRAMED_IP_ADDRESS: 192.168.79.253 > [pptp1] RADIUS: RadiusGetParams: RAD_FRAMED_IP_NETMASK: 255.255.255.255 > [pptp1] RADIUS: RadiusGetParams: PANIC no MS-CHAPv2 response received - please check, if you have included the microsoft dictionary $INCLUDE dictionary.microsoft (file dictionary) > > [pptp1] CCP: state change Ack-Rcvd --> Opened > [pptp1] CCP: LayerUp > Compress using: MPPE, 128 bit, stateless > Decompress using: MPPE, 128 bit, stateless > [pptp1] setting interface ng0 MTU to 1436 bytes > [pptp1] rec'd unexpected protocol 0x4409 on link -1, rejecting > [pptp1] rec'd unexpected protocol 0x0099 on link -1, rejecting > [pptp1] rec'd unexpected protocol 0x0091 on link -1, rejecting > [pptp1] rec'd proto 0xc867 on MP link! (ignoring) this is a problem we the MPPE-Key generation, first we should try getting your RADIUS config to work, bye, -- ------------------------------- ---------------------------------- Michael Bretterklieber - http://www.bretterklieber.com A-Quadrat Automation GmbH - http://www.a-quadrat.at Tel: ++43-(0)3172-41679 - GSM: ++43-(0)699 12861847 ------------------------------- ---------------------------------- "...the number of UNIX installations has grown to 10, with more expected..." - Dennis Ritchie and Ken Thompson, June 1972 From owner-freebsd-net@FreeBSD.ORG Sat Nov 15 05:26:55 2003 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 27D1E16A4CE for ; Sat, 15 Nov 2003 05:26:55 -0800 (PST) Received: from freebsd.giovannelli.com (freebsd.giovannelli.com [194.184.65.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE31543F85 for ; Sat, 15 Nov 2003 05:26:52 -0800 (PST) (envelope-from gmarco@giovannelli.it) Received: from usul.giovannelli.it (usul.giovannelli.com [10.254.254.4]) hAFDSduE033421; Sat, 15 Nov 2003 14:28:39 +0100 (CET) (envelope-from gmarco@giovannelli.it) Message-Id: <6.0.0.22.2.20031115142623.03c7fc88@194.184.65.7> X-Sender: gmarco@194.184.65.4 (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Sat, 15 Nov 2003 14:33:28 +0100 To: net@freebsd.org From: Gianmarco Giovannelli In-Reply-To: <20031115135336.T359@worf.a-quadrat.at> References: <6.0.0.22.2.20031115121950.03168f20@194.184.65.4> <20031115135336.T359@worf.a-quadrat.at> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed cc: esperti@gufi.org Subject: Re: mpd & freeradius: MS-CHAP2 problem ? and more ... (long) 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, 15 Nov 2003 13:26:55 -0000 At 15/11/2003, Michael Bretterklieber wrote: Thanks very much for your so quick answer. > > [pptp1] RADIUS: RadiusAddServer Adding 172.16.33.236 > > [pptp1] RADIUS: RadiusPutAuth: RADIUS_CHAP (MSOFTv2) peer name: gmarco > > [pptp1] RADIUS: RadiusSendRequest: RAD_ACCESS_ACCEPT for user gmarco > > [pptp1] RADIUS: RadiusGetParams: RAD_FRAMED_PROTOCOL: 2 > > [pptp1] RADIUS: RadiusGetParams: RAD_FRAMED_PROTOCOL: 1 > > [pptp1] RADIUS: RadiusGetParams: RAD_FRAMED_IP_ADDRESS: 192.168.79.253 > > [pptp1] RADIUS: RadiusGetParams: RAD_FRAMED_IP_NETMASK: 255.255.255.255 > > [pptp1] RADIUS: RadiusGetParams: PANIC no MS-CHAPv2 response received >- please check, if you have included the microsoft dictionary >$INCLUDE dictionary.microsoft (file dictionary) It fixes the problem :-) Infact now: [pptp1] CHAP: sending CHALLENGE [pptp1] LCP: LayerUp pptp0-0: ignoring SetLinkInfo [pptp1] LCP: rec'd Ident #2 link 0 (Opened) MESG: MSRASV5.10 [pptp1] CHAP: rec'd RESPONSE #1 Name: "gmarco" [pptp1] RADIUS: RadiusAddServer Adding 172.16.33.236 [pptp1] RADIUS: RadiusPutAuth: RADIUS_CHAP (MSOFTv2) peer name: gmarco [pptp1] RADIUS: RadiusSendRequest: RAD_ACCESS_ACCEPT for user gmarco [pptp1] RADIUS: RadiusGetParams: RAD_FRAMED_PROTOCOL: 2 [pptp1] RADIUS: RadiusGetParams: RAD_FRAMED_PROTOCOL: 1 [pptp1] RADIUS: RadiusGetParams: RAD_FRAMED_IP_ADDRESS: 192.168.79.253 [pptp1] RADIUS: RadiusGetParams: RAD_FRAMED_IP_NETMASK: 255.255.255.255 [pptp1] RADIUS: RadiusGetParams: RAD_MICROSOFT_MS_CHAP2_SUCCESS: S=F8DD7B9D0D116 CE031E25CD8448C84D4FE49644F [pptp1] RADIUS: RadiusGetParams: RAD_MICROSOFT_MS_MPPE_RECV_KEY [pptp1] RADIUS: RadiusGetParams: RAD_MICROSOFT_MS_MPPE_SEND_KEY [pptp1] RADIUS: RadiusGetParams: RAD_MICROSOFT_MS_MPPE_ENCRYPTION_POLICY: 2 (Req uired) [pptp1] RADIUS: RadiusGetParams: RAD_MICROSOFT_MS_MPPE_ENCRYPTION_TYPES: 4 (128 bit) [pptp1] RADIUS: RadiusSetAuth: Trying to use IP-address from radius-server [pptp1] RADIUS: RadiusSetAuth: using this IP: 192.168.79.253 Response is valid [pptp1] CHAP: sending SUCCESS [pptp1] LCP: authorization successful [pptp1] LCP: phase shift AUTHENTICATE --> NETWORK > > [pptp1] rec'd unexpected protocol 0x4409 on link -1, rejecting > > [pptp1] rec'd unexpected protocol 0x0099 on link -1, rejecting > > [pptp1] rec'd unexpected protocol 0x0091 on link -1, rejecting > > [pptp1] rec'd proto 0xc867 on MP link! (ignoring) >this is a problem we the MPPE-Key generation, first we should try getting >your RADIUS config to work, Now I don't get them anymore :-) Thanks again very much ... Best Regards, Gianmarco Giovannelli , "Unix expert since yesterday" http://www.gufi.org/~gmarco From owner-freebsd-net@FreeBSD.ORG Sat Nov 15 10:23:56 2003 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 67C0216A4CE; Sat, 15 Nov 2003 10:23:56 -0800 (PST) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id C0B3343FD7; Sat, 15 Nov 2003 10:23:54 -0800 (PST) (envelope-from cristjc@comcast.net) Received: from blossom.cjclark.org (12-234-156-182.client.attbi.com[12.234.156.182]) by comcast.net (sccrmhc13) with ESMTP id <2003111518235301600kc4vue>; Sat, 15 Nov 2003 18:23:53 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.9p2/8.12.8) with ESMTP id hAFIOCsb002059; Sat, 15 Nov 2003 10:24:12 -0800 (PST) (envelope-from cristjc@comcast.net) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.9p2/8.12.9/Submit) id hAFIO9lk002057; Sat, 15 Nov 2003 10:24:10 -0800 (PST) (envelope-from cristjc@comcast.net) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to cristjc@comcast.net using -f Date: Sat, 15 Nov 2003 10:24:09 -0800 From: "Crist J. Clark" To: "Oldach, Helge" Message-ID: <20031115182409.GA2001@blossom.cjclark.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-URL: http://people.freebsd.org/~cjc/ cc: freebsd-isp@freebsd.org cc: freebsd-ipfw@freebsd.org cc: vgoupil@alis.com cc: freebsd-net@freebsd.org Subject: Re: IPSec VPN & NATD (problem with alias_address vs redirect_addr ess) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: cjclark@alum.mit.edu List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2003 18:23:56 -0000 On Sat, Nov 15, 2003 at 07:54:40AM +0100, Oldach, Helge wrote: > From: Crist J. Clark [mailto:cristjc@comcast.net] > > On Fri, Nov 14, 2003 at 06:22:55PM +0100, Helge Oldach wrote: > > > Nothing that works well and has noticeable exposure is useless. This > > > definitely has both. Not with FreeBSD, though. It does work with Windows > > > 2000 SP4, to put a name up... So it's definitely out there. > > > > Two different ESP end points behind many-to-one NAT connected to a > > single ESP end point on the other side of the NAT? I'd be very curious > > to get the documentation on how they are cheating to get that to work. > > You have posted a reference already. W2k SP4 supports UDP encapsulation of > IPSec. And yes, it works fine, and reliably. Further, all of Cisco's and > Checkpoints VPN gear support IPSec-over-UDP as well. This alone is >70% > market share. Oh, yeah, I know of UDP or TCP encapsulation tricks that work. I have dealt with several of these implementations too. I thought that you were implying that there were working NAT implementations that could deal with ESP in these circumstances. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org From owner-freebsd-net@FreeBSD.ORG Sat Nov 15 12:44:37 2003 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 BDFCD16A4CE for ; Sat, 15 Nov 2003 12:44:37 -0800 (PST) Received: from hypernet.hyper.net (hypernet.hyper.net [193.218.1.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id A6FEC43FBD for ; Sat, 15 Nov 2003 12:44:35 -0800 (PST) (envelope-from dxoch@escape.gr) Received: from escape.gr (patrinos-2.hyper.gr [193.218.2.19]) ESMTP id hAFKemu06059; Sat, 15 Nov 2003 22:40:49 +0200 Date: Sat, 15 Nov 2003 22:44:28 +0200 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: Maxim Konovalov From: Jim Xochellis In-Reply-To: <20031114221030.E70547@news1.macomnet.ru> Message-Id: <8167F99F-17AC-11D8-9B39-003065C4E486@escape.gr> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) cc: net@freebsd.org Subject: Re: ip-up script of pppd no triggered 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, 15 Nov 2003 20:44:37 -0000 Hi Maxim, On Friday, November 14, 2003, at 09:13 PM, Maxim Konovalov wrote: > On Fri, 14 Nov 2003, 16:02+0200, Jim Xochellis wrote: > >> Hi list, >> >> I have also posted this mail to the freebsd-questions list a few days >> ago, but I had no luck. Hence, I decided to try this list too, which >> probably is the most appropriate for my problem. >> >> I need to persuade pppd to call its ip-up script in order to add a >> non-default route as soon as the link is up and running. Unfortunately >> it seems that my ip-up script is not being called. The mode of the >> file >> is rwxr-xr-x and the owner root:wheel. I am calling the pppd from >> inside a "/usr/local/etc/rc.d/ppp.sh" script by using the following >> command: >> "/usr/sbin/pppd /dev/cuaa0 115200 A.A.A.A:B.B.B.B noauth persist >> netmask 255.255.255.252" >> >> I have read all the chapter #18 of the handbook, but I haven't found >> anything about the ip-up script. On the contrary the PPPD(8) man page >> claims that the /etc/ppp/ip-up is executed when the link is available >> for sending and receiving IP packets. My link becomes available for >> sending/receiving IP packets, but ip-up is never executed. Any ideas >> why? >> By the way, I am using kernel PPP, (on ppp0) if it makes any >> difference. >> >> Am I doing something wrong? > > Did you look at /usr/share/examples/pppd/ip-up.sample ? > > ip-up worked for me six months ago. Yes I have looked at ip-up.sample file. Please note that my problem is not what to put inside the script, but the fact that the script itself is not being called. On the contrary your are saying that it worked for you and thats great news! Was it in the /etc/ppp/ip-up path? What were its file mode? Any other info maybe? Thanks for the response Jim Xochellis Escape Information Services From owner-freebsd-net@FreeBSD.ORG Sat Nov 15 13:02:45 2003 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 88D8616A4D0 for ; Sat, 15 Nov 2003 13:02:45 -0800 (PST) Received: from relay.macomnet.ru (relay.macomnet.ru [195.128.64.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B29C43FE0 for ; Sat, 15 Nov 2003 13:02:44 -0800 (PST) (envelope-from maxim@macomnet.ru) Received: from news1.macomnet.ru (3m67u23s@news1.macomnet.ru [195.128.64.14]) by relay.macomnet.ru (8.12.10/8.12.10) with ESMTP id hAFL2YSi23891380; Sun, 16 Nov 2003 00:02:34 +0300 (MSK) Date: Sun, 16 Nov 2003 00:02:34 +0300 (MSK) From: Maxim Konovalov To: Jim Xochellis In-Reply-To: <8167F99F-17AC-11D8-9B39-003065C4E486@escape.gr> Message-ID: <20031115235809.R94964@news1.macomnet.ru> References: <8167F99F-17AC-11D8-9B39-003065C4E486@escape.gr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: net@freebsd.org Subject: Re: ip-up script of pppd no triggered 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, 15 Nov 2003 21:02:45 -0000 On Sat, 15 Nov 2003, 22:44+0200, Jim Xochellis wrote: > Hi Maxim, > > On Friday, November 14, 2003, at 09:13 PM, Maxim Konovalov wrote: > > > On Fri, 14 Nov 2003, 16:02+0200, Jim Xochellis wrote: > > > >> Hi list, > >> > >> I have also posted this mail to the freebsd-questions list a few days > >> ago, but I had no luck. Hence, I decided to try this list too, which > >> probably is the most appropriate for my problem. > >> > >> I need to persuade pppd to call its ip-up script in order to add a > >> non-default route as soon as the link is up and running. Unfortunately > >> it seems that my ip-up script is not being called. The mode of the > >> file > >> is rwxr-xr-x and the owner root:wheel. I am calling the pppd from > >> inside a "/usr/local/etc/rc.d/ppp.sh" script by using the following > >> command: > >> "/usr/sbin/pppd /dev/cuaa0 115200 A.A.A.A:B.B.B.B noauth persist > >> netmask 255.255.255.252" > >> > >> I have read all the chapter #18 of the handbook, but I haven't found > >> anything about the ip-up script. On the contrary the PPPD(8) man page > >> claims that the /etc/ppp/ip-up is executed when the link is available > >> for sending and receiving IP packets. My link becomes available for > >> sending/receiving IP packets, but ip-up is never executed. Any ideas > >> why? > >> By the way, I am using kernel PPP, (on ppp0) if it makes any > >> difference. > >> > >> Am I doing something wrong? > > > > Did you look at /usr/share/examples/pppd/ip-up.sample ? > > > > ip-up worked for me six months ago. > > Yes I have looked at ip-up.sample file. Please note that my problem is > not what to put inside the script, but the fact that the script itself > is not being called. On the contrary your are saying that it worked for Are you sure it isn't called? Did you check pppd logs? Were there any interesting? Is there '#!/bin/sh' on the top of your script? > you and thats great news! Was it in the /etc/ppp/ip-up path? What were > its file mode? Any other info maybe? It was /etc/ppp/ip-up, 0555. -- Maxim Konovalov, maxim@macomnet.ru, maxim@FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Sat Nov 15 19:01:18 2003 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 172A416A4CE; Sat, 15 Nov 2003 19:01:18 -0800 (PST) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id A468E43FD7; Sat, 15 Nov 2003 19:01:15 -0800 (PST) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id EFAD3651F7; Sat, 15 Nov 2003 07:20:15 +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 06312-04-7; Sat, 15 Nov 2003 07:20:15 +0000 (GMT) Received: from saboteur.dek.spc.org (unknown [82.147.19.91]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 01205651F1; Sat, 15 Nov 2003 07:20:14 +0000 (GMT) Received: by saboteur.dek.spc.org (Postfix, from userid 1001) id 575815; Sat, 15 Nov 2003 07:20:10 +0000 (GMT) Date: Sat, 15 Nov 2003 07:20:10 +0000 From: Bruce M Simpson To: "Oldach, Helge" Message-ID: <20031115072010.GA72782@saboteur.dek.spc.org> Mail-Followup-To: "Oldach, Helge" , "'cjclark@alum.mit.edu'" , freebsd-isp@freebsd.org, freebsd-ipfw@freebsd.org, vgoupil@alis.com, freebsd-net@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: cc: freebsd-isp@freebsd.org cc: freebsd-ipfw@freebsd.org cc: "'cjclark@alum.mit.edu'" cc: vgoupil@alis.com cc: freebsd-net@freebsd.org Subject: Re: IPSec VPN & NATD (problem with alias_address vs redirect_addr ess) 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, 16 Nov 2003 03:01:18 -0000 On Sat, Nov 15, 2003 at 07:54:40AM +0100, Oldach, Helge wrote: > I do well understand that there is no general solution. However, FreeBSD > is definitely behind what is available on the commercial market today. Call > it "cheating" - but it's out there and it works. I would rather prefer to > see > a feature that doesn't solve a 100% case than to see nothing because we feel > that a "general specification" is missing. I'm in agreement here. The fact alone that hundreds of DSL providers are blocking tunneling and VPN protocols should be enough. So far, though, our provider passes ESP, so I'm not in a hurry to implement this myself. BMS