From owner-freebsd-net Sun Jul 29 5:47:36 2001 Delivered-To: freebsd-net@freebsd.org Received: from aussie.org (hallam.lnk.telstra.net [139.130.54.166]) by hub.freebsd.org (Postfix) with ESMTP id D472437B403 for ; Sun, 29 Jul 2001 05:47:29 -0700 (PDT) (envelope-from mlnn4@oaks.com.au) Received: from dualp2 (dualp2 [203.29.75.73]) by aussie.org (8.11.3/8.11.4) with SMTP id f6TClRB02477 for ; Sun, 29 Jul 2001 22:47:27 +1000 (EST) (envelope-from mlnn4@oaks.com.au) Message-Id: <200107291247.f6TClRB02477@aussie.org> From: "Chris" To: "freebsd-net@freebsd.org" Date: Sun, 29 Jul 2001 22:47:22 +1000 Reply-To: "Chris" X-Mailer: PMMail 98 Standard (2.01.1600) For Windows NT (5.0.2195;2) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: kernel upgrade causes truncated IPSEC packets Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Greets, I've run up against a wall trying to fix a IPSEC tunnel setup that was working up until I did a kernel update a few days ago. Certain packets seem to go out of the system and then vanish into thin air (or thin electrons, at least:). It's related to the running kernel as if I boot the old (about three months) kernel, the problem goes away. I have seen it happen on two machines in different physical locations. I have not changed the kernel configuration file. I have tracked the problem as far as the physical PPP interface. The situation is as follows (you may need to refer to the network description I have below): if packets enter my IPSEC tunnel from the FreeBSD box, they are (mostly; see below) encapsulated as AH/ESP as per normal and make their way to the remote end. This works fine. If, however, they enter the FreeBSD gateway from the LAN, and use the same tunnel, they seem to always get lost. They *do* get encapsulated by IPSEC properly (it's not a forwarding issue), and in fact everything looks fine. tcpdump shows them going through the tun0 interface and the modem lights flash happily. Except the AH/ESP packets never turn up at the far end's router ... Once I had eliminated other possibilities I was only left with the thought that it was getting lost inside ppp somewhere, so I turned on ppp async debugging. This was very helpful, because it showed that the outgoing packets were being truncated under certain circumstances. Note that when I say they are truncated, I don't mean at the IP level; the packet header shows the correct length for the AH and ESP-encapsulated packet. But the PPP process only sees the first 36 bytes or so of it (for example, a packet which arrives as 263 bytes becomes 320 bytes after encapsulation. This is what is shown by both tcpdump and the packet header, as read from the ppp async stream), but only 36 bytes of it make it through to the modem (plus the PPP overhead of about 5 bytes). I have since discovered that this will also happen for some packets that originate on the local FBSD box. If they are over a certain length (220 bytes prior to encapsulation), they also suffer the 'only send 36 bytes' problem (I wonder if the fact that 220 + 36 == 256 has something to do with this?) FWIW the other machines that we have implementing IPSEC tunnels, and which are running the same kernel and tunnel config, but which do not use PPP to connect to the net, do not suffer from this problem. It only seems to hurt encapsulated packets under the above circumstances when combined with PPP. I note that some significant changes happened to if_tun.c between the working and non-working kernels (the old kernel was cvsupped on about April 19) but I don't know enough about the kernel to work out if this is the cause. I hope this is enough info for someone who does know it better to figure it out. ---------------------------- Configuration: we have a number of machines (4.3-STABLE) acting as permanently dialled-up gateways for an IPSEC-protected VPN connecting their local LAN's to two central gateways in two cities. This has been in place and working for a good part of a year. I recently did a kernel update on the central gateways and that caused no problems (the previous kernels were a few months old). I then updated two of the field machines and started experiencing the abovementioned problems. Topology (IP's are illustrative) - o Local LAN has machine 'A' at 10.0.58.2/24 o A's default gateway is the FBSD box 'B' at 10.0.58.1/24 o B is dialled up using ppp to routable address 1.2.3.4 o Central gateway 'C' is on the net at 5.6.7.8 o C has an interface hosting a local LAN at 10.0.48.1/24 I use IPSEC transport mode between 'B' and 'C', and have set up a native IPSEC tunnel (not using gif) between 10.0.58.0/24 and 10.0.48.0/24. Once key exchange has occurred, I do have a working tunnel in that I can, from 'A', 'ping -S 10.0.58.1 10.0.48.1' and get replies back. tcpdump shows ESP encrypted packets as expected. Likewise 10.0.48.1 can ping 10.0.58.1. However, since the kernel update, if 'C' at 10.0.48.1 pings machine 'A' at 10.0.58.2, the packets get delivered to 'A' and the replies to 'B', but the replies go missing after B's tun0. Likewise if 'A' tries to send traffic to 'C' or any address in 10.0.48.0/24, the packets go missing due, presumably, to the above PPP issue. -- Chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jul 29 13: 4:44 2001 Delivered-To: freebsd-net@freebsd.org Received: from lucifer.fuzion.za.org (pta-dial-196-31-186-98.mweb.co.za [196.31.186.98]) by hub.freebsd.org (Postfix) with ESMTP id 6C52E37B401; Sun, 29 Jul 2001 13:04:27 -0700 (PDT) (envelope-from psyv@root.org.za) Received: from localhost (psyv@localhost) by lucifer.fuzion.za.org (8.11.3/8.11.3) with ESMTP id f6TK5Xl37496; Sun, 29 Jul 2001 22:05:44 +0200 (SAST) (envelope-from psyv@root.org.za) X-Authentication-Warning: lucifer.fuzion.za.org: psyv owned process doing -bs Date: Sun, 29 Jul 2001 22:05:30 +0200 (SAST) From: The Psychotic Viper X-Sender: psyv@lucifer.fuzion.za.org To: Ping Pan Cc: freebsd-net@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: Voice Conferencing In-Reply-To: <3B638238.3090407@cs.columbia.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, 28 Jul 2001, Ping Pan wrote: > > Have you tried vic, vat and rat? Essentially, the voice streams are sent > in RTP and RTCP. By setting up firewall rules, I had gotten vic/vat > working in the past.... but not NAT. Curious to find out.... You may > also want to ask the question in avt@ietf.org mailing list. Thanks Ill try one of the 3 but noticed that Speak Freely supports those transport streams, was wondering if u can send a sample ruleset or just a hint into what should I do (fwd ports to the win2k box like Im assuming?). And thanx for the pointer to that list and all ur help so far. Oh and Id use Speak Freely via my gateway just the microphone seems to stay at signal "off" mode and is undetected.(anyone?) > Good luck! > > - Ping Thanx , seems I am in dire need of luck PsyV To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jul 29 13:20:29 2001 Delivered-To: freebsd-net@freebsd.org Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.121.12]) by hub.freebsd.org (Postfix) with ESMTP id 1513837B401; Sun, 29 Jul 2001 13:20:23 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.140.234.Dial1.SanJose1.Level3.net [209.245.140.234]) by harrier.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id NAA23285; Sun, 29 Jul 2001 13:19:59 -0700 (PDT) Message-ID: <3B64647E.85BAE179@mindspring.com> Date: Sun, 29 Jul 2001 12:31:10 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Wemm Cc: Julian Elischer , "Eugene L. Vorokov" , Soren Kristensen , freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Why two cards on the same segment... References: <20010727164602.46DBC380B@overcee.netplex.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Peter Wemm wrote: > Have you seen Bill Paul's FEC stuff? It works very nicely, but using the > cisco Fast EtherChannel instead of VRRP. While it isn't the same, we have > used it with four interfaces merged into one virtual interface quite > happily. I haven't played with it... does it handle one of the four dropping out, and do the right thing? Say I have four boxes, and I want to have four virtual interfaces; can you define more than one virtual interface for the group at the same time, and keep four virtual interfaces going with only three boxes? That seems like the most useful configuration (to me, anyway...). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 30 7:22:50 2001 Delivered-To: freebsd-net@freebsd.org Received: from relay.tecc.co.uk (luggage.tecc.co.uk [193.128.6.129]) by hub.freebsd.org (Postfix) with SMTP id 75FF137B401 for ; Mon, 30 Jul 2001 07:22:46 -0700 (PDT) (envelope-from andy@tecc.co.uk) Received: from southampton [195.217.37.155] by relay.tecc.co.uk with smtp (Exim 1.70 #1) id 15RDwT-0006lN-00; Mon, 30 Jul 2001 15:22:45 +0100 From: "Andy" To: Subject: ioctl and fxp/tl drivers Date: Mon, 30 Jul 2001 15:22:45 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi all This maybe a dumb question but a bit stumped at the mo. When I make an ioctl call to the fxp or tl drivers thus: if ((ret=ioctl(s, SIOCSIFLLADDR, (caddr_t)&ifr)) < 0) syslog(LOG_ERR, "ioctl (set lladdr): %m"); I get:- ioctl (set lladdr): Inappropriate ioctl for device Also, :- ret = ioctl(fd, addF ? SIOCADDMULTI : SIOCDELMULTI, (char *) &ifr); if (ret) { syslog( LOG_ERR, "Can't %s on %s: %m" ,addF ? "SIOCADDMULTI" : "SIOCDELMULTI" ,ifname); } I get:- Can't SIOCADDMULTI on fxp0: Can't assign requested address Also, when the call is SIOCDELMULTI (rather than ADD) I get Can't SIOCDELMULTI on fxp0: No such file or directory Same on the tl device. I've had a look in the driver source and those calls appear to be supported. Can supply some debug info if required but maybe the combined brains out there can spot the obvious I'm missing? tia, regards Andy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 30 8: 5:23 2001 Delivered-To: freebsd-net@freebsd.org Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by hub.freebsd.org (Postfix) with ESMTP id B5F1637B403 for ; Mon, 30 Jul 2001 08:05:19 -0700 (PDT) (envelope-from oberman@ptavv.es.net) Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (8.10.1/8.10.1) with ESMTP id f6UF5Cb23264; Mon, 30 Jul 2001 08:05:12 -0700 (PDT) Message-Id: <200107301505.f6UF5Cb23264@ptavv.es.net> To: "stephane antoine" Cc: freebsd-net@FreeBSD.ORG Subject: Re: Wlan 802.11 support for FreeBSD 4.2 In-reply-to: Your message of "Sat, 28 Jul 2001 22:23:24 BST." <010701c117ab$a638c7b0$400b4989@eee.kcl.ac.uk> Date: Mon, 30 Jul 2001 08:05:12 -0700 From: "Kevin Oberman" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I'm glad it's working. Unfortunately, I only found this by poking around in the /etc/defaults/rc.conf file. I don't think there is any man page covering the general issue of getting PCCards to work. I really should write a man page on the subject, but I have no idea when/if I or someone else will get to it. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 30 8: 9:49 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by hub.freebsd.org (Postfix) with ESMTP id 0FAF037B401 for ; Mon, 30 Jul 2001 08:09:48 -0700 (PDT) (envelope-from fenner@research.att.com) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 2A0784CE98; Mon, 30 Jul 2001 11:09:47 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id LAA21627; Mon, 30 Jul 2001 11:09:45 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id IAA15303; Mon, 30 Jul 2001 08:09:45 -0700 (PDT) Message-Id: <200107301509.IAA15303@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: daniel.sobral@tcoip.com.br Subject: Re: TCP window and vlans Cc: net@freebsd.org Date: Mon, 30 Jul 2001 08:09:44 -0700 Versions: dmail (solaris) 2.2j/makemail 2.9b Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Are the VLAN interfaces trunked on the FreeBSD side (i.e. vlanN)? Are you getting bitten by the device driver dropping large frames (VLAN trunks need a higher MRU/MTU, which no drivers seem to support; see http://www.euitt.upm.es/~pjlobo/fbsdvlan.html for if_fxp patches) If you set the MTU to 1496 do things get better? Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 30 9: 1:38 2001 Delivered-To: freebsd-net@freebsd.org Received: from purus.tcoip (unknown [200.199.244.162]) by hub.freebsd.org (Postfix) with ESMTP id 762DC37B419 for ; Mon, 30 Jul 2001 09:01:32 -0700 (PDT) (envelope-from daniel.sobral@tcoip.com.br) Received: from tcoip.com.br (9lki25i471fth56p@dcs.intra.tcoip.com.br [192.168.60.194]) by purus.tcoip (8.11.1/8.11.1) with ESMTP id f6UFwbA08411; Mon, 30 Jul 2001 12:58:37 -0300 Message-ID: <3B65842C.90407@tcoip.com.br> Date: Mon, 30 Jul 2001 12:58:36 -0300 From: "Daniel C. Sobral" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.2) Gecko/20010705 X-Accept-Language: en, pt-br, ja MIME-Version: 1.0 To: Bill Fenner Cc: net@freebsd.org Subject: Re: TCP window and vlans References: <200107301509.IAA15303@windsor.research.att.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Bill Fenner wrote: > Are the VLAN interfaces trunked on the FreeBSD side (i.e. vlanN)? Yes. > Are you getting bitten by the device driver dropping large frames > (VLAN trunks need a higher MRU/MTU, which no drivers seem to support; > see http://www.euitt.upm.es/~pjlobo/fbsdvlan.html for if_fxp patches) I don't know about these patches. Someone said to me just setting mtu for vlan to 1500 would work with an fxp. Before that I had tried increasing the maximum size of the ethernet. Both things seemed to work (large pings went ok). Anyway this doesn't seem to match with the symptoms. Things stop being transmitted only when the receiver side sends a window size smaller than the average packet, and the buffer of the connection gets filled up. > If you set the MTU to 1496 do things get better? No because if I do that all my routing goes to outer space and I wouldn't be able to send a single packet. -- Daniel C. Sobral (8-DCS) Daniel.Sobral@tcoip.com.br dcs@newsguy.com dcs@freebsd.org capo@notorious.bsdconspiracy.net What PROGRAM are they watching? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 30 14:21: 6 2001 Delivered-To: freebsd-net@freebsd.org Received: from net-ninja.com (cc213180-a.plymr1.tn.home.com [65.8.203.28]) by hub.freebsd.org (Postfix) with ESMTP id 0C76C37B401 for ; Mon, 30 Jul 2001 14:21:04 -0700 (PDT) (envelope-from mwade@st3.com) Received: by net-ninja.com (Postfix, from userid 1000) id CE7A16E8D0; Mon, 30 Jul 2001 17:20:21 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by net-ninja.com (Postfix) with ESMTP id BD812176020 for ; Mon, 30 Jul 2001 17:20:21 -0400 (EDT) Date: Mon, 30 Jul 2001 17:20:21 -0400 (EDT) From: Mike Wade X-Sender: mwade@fxp0.net-ninja.com To: freebsd-net@FreeBSD.ORG Subject: FreeBSD 4.3 -> Windows 2000 Network Performance Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I'm serving several Windows 2000 clients from several FreeBSD 4.3 servers and I'm running into a performance bottleneck somewhere which appears to be on the Windows 2000 side of things. Performance w/ FreeBSD -> FreeBSD is great! Hardware: * Intel 2x1 Ghz CPUs * 1 gig of RAM * Extreme Summit 1i w/ Copper and SX Interfaces Performance w/ ttcp (for UNIX + Win32): FreeBSD 4.3 + Netgear 622T -> FreeBSD 4.3 + Netgear 622T = 875 Mbps FreeBSD 4.3 + Netgear 622T -> Windows 2000 + Netgear 622T = 350 Mbps FreeBSD 4.3 + Netgear 622T -> Windows 2000 + 3Com 3c985-SX = 350 Mbps I've tried running multiple instances (overlapping) of ttcp w/ no performance increases (ie: each instance halfs thruput) and I've tried tweaking the following on FreeBSD with no results: sysctl -w net.inet.tcp.delayed_ack=0 sysctl -w net.inet.tcp.sendspace=65535 sysctl -w net.inet.tcp.recvspace=65535 Does anyone have any opinions on how to tweak the performance on either end? Thanks in advance! --- Mike Wade (mwade@st3.com) Network Engineer To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 30 14:24:22 2001 Delivered-To: freebsd-net@freebsd.org Received: from aries.ai.net (aries.ai.net [205.134.163.4]) by hub.freebsd.org (Postfix) with ESMTP id B245337B406 for ; Mon, 30 Jul 2001 14:24:19 -0700 (PDT) (envelope-from deepak@ai.net) Received: from blood (adsl-138-88-48-20.bellatlantic.net [138.88.48.20]) by aries.ai.net (8.9.3/8.9.3) with SMTP id RAA29101; Mon, 30 Jul 2001 17:30:42 -0400 (EDT) (envelope-from deepak@ai.net) Reply-To: From: "Deepak Jain" To: "Mike Wade" , Subject: RE: FreeBSD 4.3 -> Windows 2000 Network Performance Date: Mon, 30 Jul 2001 17:28:13 -0400 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) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Have you tried the Windows 2000 -> Windows 2000 scenario? Deepak Jain AiNET -----Original Message----- From: owner-freebsd-net@FreeBSD.ORG [mailto:owner-freebsd-net@FreeBSD.ORG]On Behalf Of Mike Wade Sent: Monday, July 30, 2001 5:20 PM To: freebsd-net@FreeBSD.ORG Subject: FreeBSD 4.3 -> Windows 2000 Network Performance I'm serving several Windows 2000 clients from several FreeBSD 4.3 servers and I'm running into a performance bottleneck somewhere which appears to be on the Windows 2000 side of things. Performance w/ FreeBSD -> FreeBSD is great! Hardware: * Intel 2x1 Ghz CPUs * 1 gig of RAM * Extreme Summit 1i w/ Copper and SX Interfaces Performance w/ ttcp (for UNIX + Win32): FreeBSD 4.3 + Netgear 622T -> FreeBSD 4.3 + Netgear 622T = 875 Mbps FreeBSD 4.3 + Netgear 622T -> Windows 2000 + Netgear 622T = 350 Mbps FreeBSD 4.3 + Netgear 622T -> Windows 2000 + 3Com 3c985-SX = 350 Mbps I've tried running multiple instances (overlapping) of ttcp w/ no performance increases (ie: each instance halfs thruput) and I've tried tweaking the following on FreeBSD with no results: sysctl -w net.inet.tcp.delayed_ack=0 sysctl -w net.inet.tcp.sendspace=65535 sysctl -w net.inet.tcp.recvspace=65535 Does anyone have any opinions on how to tweak the performance on either end? Thanks in advance! --- Mike Wade (mwade@st3.com) Network Engineer To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 30 15:53: 6 2001 Delivered-To: freebsd-net@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id 4933337B403; Mon, 30 Jul 2001 15:52:08 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id f6UMq7721055; Mon, 30 Jul 2001 15:52:07 -0700 Date: Mon, 30 Jul 2001 15:52:07 -0700 From: Brooks Davis To: net@freebsd.org, hackers@freebsd.org Subject: review request: vlan cloning and modularization patch Message-ID: <20010730155207.A19629@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="GvXjxJ+pjyke8COw" Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Please review and test the following patch. It adds cloning support to vlan devices and allows loading and unloading of VLAN support. The downside of the this loadability is that it currently appears to require enabling VLAN support on NICs that support it all the time which I am concerned may have performance issues. Can anyone confirm or deny this? If there are performance issues, I believe changes will need to be made to provide a machanism by which arbitrary ethernet interfaces may be notified of VLAN attachments so they can enable support only if there is someone there to use it. The patch should be applied as follows: cd /usr/src mkdir sys/modules/if_vlan patch < vlan.diff The patch may also be obtained from: http://people.freebsd.org/~brooks/patches/vlan.diff -- 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 Index: share/man/man4/vlan.4 =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/share/man/man4/vlan.4,v retrieving revision 1.1 diff -u -r1.1 vlan.4 --- share/man/man4/vlan.4 2001/07/28 12:27:06 1.1 +++ share/man/man4/vlan.4 2001/07/30 22:38:49 @@ -33,7 +33,7 @@ .Nd IEEE 802.1Q VLAN network interface .Sh SYNOPSIS .\" In -stable: .Cd pseudo-device vlan Op Ar count -.Cd device vlan Op Ar count +.Cd device vlan .\" .Sh DESCRIPTION The Index: sys/conf/files =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/conf/files,v retrieving revision 1.555 diff -u -r1.555 files --- sys/conf/files 2001/07/26 23:04:46 1.555 +++ sys/conf/files 2001/07/30 22:33:18 @@ -907,7 +907,7 @@ net/if_stf.c optional stf net/if_tun.c optional tun net/if_tap.c optional tap -net/if_vlan.c count vlan +net/if_vlan.c optional vlan net/intrq.c standard net/net_osdep.c standard net/ppp_deflate.c optional ppp_deflate Index: sys/dev/nge/if_nge.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/dev/nge/if_nge.c,v retrieving revision 1.19 diff -u -r1.19 if_nge.c --- sys/dev/nge/if_nge.c 2001/07/25 00:19:55 1.19 +++ sys/dev/nge/if_nge.c 2001/07/27 20:42:20 @@ -87,8 +87,6 @@ * if the user selects an MTU larger than 8152 (8170 - 18). */ =20 -#include "vlan.h" - #include #include #include @@ -102,11 +100,8 @@ #include #include #include - -#if NVLAN > 0 #include #include -#endif =20 #include =20 @@ -1335,16 +1330,19 @@ m->m_pkthdr.csum_data =3D 0xffff; } =20 -#if NVLAN > 0 /* * If we received a packet with a vlan tag, pass it * to vlan_input() instead of ether_input(). */ if (extsts & NGE_RXEXTSTS_VLANPKT) { - vlan_input_tag(eh, m, extsts & NGE_RXEXTSTS_VTCI); + if (vlan_input_tag_p !=3D NULL) { + (*vlan_input_tag_p)(eh, m, + extsts & NGE_RXEXTSTS_VTCI); + } else { + m_free(m); + } continue; } -#endif =20 ether_input(ifp, eh, m); } @@ -1539,14 +1537,12 @@ struct nge_desc *f =3D NULL; struct mbuf *m; int frag, cur, cnt =3D 0; -#if NVLAN > 0 struct ifvlan *ifv =3D NULL; =20 if ((m_head->m_flags & (M_PROTO1|M_PKTHDR)) =3D=3D (M_PROTO1|M_PKTHDR) && m_head->m_pkthdr.rcvif !=3D NULL && m_head->m_pkthdr.rcvif->if_type =3D=3D IFT_L2VLAN) ifv =3D m_head->m_pkthdr.rcvif->if_softc; -#endif =20 /* * Start packing the mbufs in this chain into @@ -1588,12 +1584,10 @@ NGE_TXEXTSTS_UDPCSUM; } =20 -#if NVLAN > 0 if (ifv !=3D NULL) { sc->nge_ldata->nge_tx_list[cur].nge_extsts |=3D (NGE_TXEXTSTS_VLANPKT|ifv->ifv_tag); } -#endif =20 sc->nge_ldata->nge_tx_list[cur].nge_mbuf =3D m_head; sc->nge_ldata->nge_tx_list[cur].nge_ctl &=3D ~NGE_CMDSTS_MORE; @@ -1754,7 +1748,6 @@ */ CSR_WRITE_4(sc, NGE_VLAN_IP_RXCTL, NGE_VIPRXCTL_IPCSUM_ENB); =20 -#if NVLAN > 0 /* * If VLAN support is enabled, tell the chip to detect * and strip VLAN tag info from received frames. The tag @@ -1762,7 +1755,6 @@ */ NGE_SETBIT(sc, NGE_VLAN_IP_RXCTL, NGE_VIPRXCTL_TAG_DETECT_ENB|NGE_VIPRXCTL_TAG_STRIP_ENB); -#endif =20 /* Set TX configuration */ CSR_WRITE_4(sc, NGE_TX_CFG, NGE_TXCFG); @@ -1772,14 +1764,12 @@ */ CSR_WRITE_4(sc, NGE_VLAN_IP_TXCTL, NGE_VIPTXCTL_CSUM_PER_PKT); =20 -#if NVLAN > 0 /* * If VLAN support is enabled, tell the chip to insert * VLAN tags on a per-packet basis as dictated by the * code in the frame encapsulation routine. */ NGE_SETBIT(sc, NGE_VLAN_IP_TXCTL, NGE_VIPTXCTL_TAG_PER_PKT); -#endif =20 /* Set full/half duplex mode. */ if ((mii->mii_media_active & IFM_GMASK) =3D=3D IFM_FDX) { Index: sys/dev/txp/if_txp.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/dev/txp/if_txp.c,v retrieving revision 1.4 diff -u -r1.4 if_txp.c --- sys/dev/txp/if_txp.c 2001/07/27 19:38:56 1.4 +++ sys/dev/txp/if_txp.c 2001/07/27 21:49:57 @@ -39,8 +39,6 @@ * Driver for 3c990 (Typhoon) Ethernet ASIC */ =20 -#include "vlan.h" - #include #include #include @@ -54,6 +52,7 @@ #include #include #include +#include =20 #include #include @@ -66,10 +65,6 @@ =20 #include =20 -#if NVLAN > 0 -#include -#endif - #include /* for vtophys */ #include /* for vtophys */ #include /* for DELAY */ @@ -805,14 +800,17 @@ m->m_pkthdr.csum_data =3D 0xffff; } =20 -#if NVLAN > 0 if (rxd->rx_stat & RX_STAT_VLAN) { - if (vlan_input_tag(eh, m, - htons(rxd->rx_vlan >> 16)) < 0) + if (vlan_input_tag_p !=3D NULL) { + if ((*vlan_input_tag_p)(eh, m, + htons(rxd->rx_vlan >> 16)) < 0) + ifp->if_noproto++; + } else { + m_free(m); ifp->if_noproto++; + } goto next; } -#endif =20 eh =3D mtod(m, struct ether_header *); /* Remove header from mbuf and pass it on. */ @@ -1318,9 +1316,7 @@ struct mbuf *m, *m0; struct txp_swdesc *sd; u_int32_t firstprod, firstcnt, prod, cnt; -#if NVLAN > 0 struct ifvlan *ifv; -#endif =20 if ((ifp->if_flags & (IFF_RUNNING | IFF_OACTIVE)) !=3D IFF_RUNNING) return; @@ -1357,14 +1353,13 @@ if (++cnt >=3D (TX_ENTRIES - 4)) goto oactive; =20 -#if NVLAN > 0 if ((m->m_flags & (M_PROTO1|M_PKTHDR)) =3D=3D (M_PROTO1|M_PKTHDR) && m->m_pkthdr.rcvif !=3D NULL) { ifv =3D m->m_pkthdr.rcvif->if_softc; txd->tx_pflags =3D TX_PFLAGS_VLAN | (htons(ifv->ifv_tag) << TX_PFLAGS_VLANTAG_S); } -#endif + if (m->m_pkthdr.csum_flags & CSUM_IP) txd->tx_pflags |=3D TX_PFLAGS_IPCKSUM; =20 @@ -1880,12 +1875,10 @@ sc->sc_tx_capability =3D ext->ext_1 & OFFLOAD_MASK; sc->sc_rx_capability =3D ext->ext_2 & OFFLOAD_MASK; =20 -#if NVLAN > 0 if (rsp->rsp_par2 & rsp->rsp_par3 & OFFLOAD_VLAN) { sc->sc_tx_capability |=3D OFFLOAD_VLAN; sc->sc_rx_capability |=3D OFFLOAD_VLAN; } -#endif =20 #if 0 /* not ready yet */ Index: sys/i386/conf/NOTES =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/i386/conf/NOTES,v retrieving revision 1.942 diff -u -r1.942 NOTES --- sys/i386/conf/NOTES 2001/07/25 00:15:02 1.942 +++ sys/i386/conf/NOTES 2001/07/30 22:36:29 @@ -517,7 +517,7 @@ # See pppd(8) for more details. # device ether #Generic Ethernet -device vlan 1 #VLAN support +device vlan #VLAN support device token #Generic TokenRing device fddi #Generic FDDI device sppp #Generic Synchronous PPP Index: sys/net/ethernet.h =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/ethernet.h,v retrieving revision 1.16 diff -u -r1.16 ethernet.h --- sys/net/ethernet.h 2000/07/18 22:44:52 1.16 +++ sys/net/ethernet.h 2001/07/27 00:15:29 @@ -99,6 +99,10 @@ extern void (*ng_ether_attach_p)(struct ifnet *ifp); extern void (*ng_ether_detach_p)(struct ifnet *ifp); =20 +extern int (*vlan_input_p)(struct ether_header *eh, struct mbuf *m); +extern int (*vlan_input_tag_p)(struct ether_header *eh, struct mbuf *m, + u_int16_t t); + #else /* _KERNEL */ =20 #include Index: sys/net/if_ethersubr.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/if_ethersubr.c,v retrieving revision 1.94 diff -u -r1.94 if_ethersubr.c --- sys/net/if_ethersubr.c 2001/06/15 21:00:32 1.94 +++ sys/net/if_ethersubr.c 2001/07/27 00:16:04 @@ -39,7 +39,6 @@ #include "opt_inet6.h" #include "opt_ipx.h" #include "opt_bdg.h" -#include "opt_netgraph.h" =20 #include #include @@ -101,11 +100,6 @@ #include #endif =20 -#include "vlan.h" -#if NVLAN > 0 -#include -#endif /* NVLAN > 0 */ - /* netgraph node hooks for ng_ether(4) */ void (*ng_ether_input_p)(struct ifnet *ifp, struct mbuf **mp, struct ether_header *eh); @@ -115,6 +109,10 @@ void (*ng_ether_attach_p)(struct ifnet *ifp); void (*ng_ether_detach_p)(struct ifnet *ifp); =20 +int (*vlan_input_p)(struct ether_header *eh, struct mbuf *m); +int (*vlan_input_tag_p)(struct ether_header *eh, struct mbuf *m, + u_int16_t t); + static int ether_resolvemulti __P((struct ifnet *, struct sockaddr **, struct sockaddr *)); u_char etherbroadcastaddr[6] =3D { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff }; @@ -524,13 +522,11 @@ =20 ether_type =3D ntohs(eh->ether_type); =20 -#if NVLAN > 0 - if (ether_type =3D=3D vlan_proto) { - if (vlan_input(eh, m) < 0) + if (ether_type =3D=3D ETHERTYPE_VLAN) { + if (vlan_input_p !=3D NULL && (*vlan_input_p)(eh, m) < 0) ifp->if_data.ifi_noproto++; return; } -#endif /* NVLAN > 0 */ =20 switch (ether_type) { #ifdef INET Index: sys/net/if_vlan.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/if_vlan.c,v retrieving revision 1.30 diff -u -r1.30 if_vlan.c --- sys/net/if_vlan.c 2001/07/24 17:14:37 1.30 +++ sys/net/if_vlan.c 2001/07/27 00:19:01 @@ -54,7 +54,6 @@ * tag value that goes with it. */ =20 -#include "vlan.h" #include "opt_inet.h" =20 #include @@ -67,6 +66,8 @@ #include #include #include +#include /* XXX: Shouldn't really be required! */ +#include =20 #include #include @@ -81,23 +82,32 @@ #include #endif =20 +#define VLANNAME "vlan" +#define VLAN_MAXUNIT 0x7fff /* ifp->if_unit is only 15 bits */ + SYSCTL_DECL(_net_link); SYSCTL_NODE(_net_link, IFT_L2VLAN, vlan, CTLFLAG_RW, 0, "IEEE 802.1Q VLAN"= ); SYSCTL_NODE(_net_link_vlan, PF_LINK, link, CTLFLAG_RW, 0, "for consistency= "); - -u_int vlan_proto =3D ETHERTYPE_VLAN; -SYSCTL_INT(_net_link_vlan_link, VLANCTL_PROTO, proto, CTLFLAG_RW, &vlan_pr= oto, - 0, "Ethernet protocol used for VLAN encapsulation"); =20 -static struct ifvlan ifv_softc[NVLAN]; +static MALLOC_DEFINE(M_VLAN, "vlan", "802.1Q Virtual LAN Interface"); +static struct rman vlanunits[1]; +static LIST_HEAD(, ifvlan) ifv_list; =20 +static int vlan_clone_create(struct if_clone *, int *); +static void vlan_clone_destroy(struct ifnet *); static void vlan_start(struct ifnet *ifp); static void vlan_ifinit(void *foo); +static int vlan_input(struct ether_header *eh, struct mbuf *m); +static int vlan_input_tag(struct ether_header *eh, struct mbuf *m, + u_int16_t t); static int vlan_ioctl(struct ifnet *ifp, u_long cmd, caddr_t addr); static int vlan_setmulti(struct ifnet *ifp); static int vlan_unconfig(struct ifnet *ifp); static int vlan_config(struct ifvlan *ifv, struct ifnet *p); =20 +struct if_clone vlan_cloner =3D + IF_CLONE_INITIALIZER("vlan", vlan_clone_create, vlan_clone_destroy); + /* * Program our multicast filter. What we're actually doing is * programming the multicast filter of the parent. This has the @@ -142,14 +152,14 @@ if (error) return(error); SLIST_REMOVE_HEAD(&sc->vlan_mc_listhead, mc_entries); - free(mc, M_DEVBUF); + free(mc, M_VLAN); } =20 /* Now program new ones. */ TAILQ_FOREACH(ifma, &ifp->if_multiaddrs, ifma_link) { if (ifma->ifma_addr->sa_family !=3D AF_LINK) continue; - mc =3D malloc(sizeof(struct vlan_mc_entry), M_DEVBUF, M_WAITOK); + mc =3D malloc(sizeof(struct vlan_mc_entry), M_VLAN, M_WAITOK); bcopy(LLADDR((struct sockaddr_dl *)ifma->ifma_addr), (char *)&mc->mc_addr, ETHER_ADDR_LEN); SLIST_INSERT_HEAD(&sc->vlan_mc_listhead, mc, mc_entries); @@ -163,44 +173,40 @@ return(0); } =20 -static void -vlaninit(void) -{ - int i; - - for (i =3D 0; i < NVLAN; i++) { - struct ifnet *ifp =3D &ifv_softc[i].ifv_if; - - ifp->if_softc =3D &ifv_softc[i]; - ifp->if_name =3D "vlan"; - ifp->if_unit =3D i; - /* NB: flags are not set here */ - ifp->if_linkmib =3D &ifv_softc[i].ifv_mib; - ifp->if_linkmiblen =3D sizeof ifv_softc[i].ifv_mib; - /* NB: mtu is not set here */ - - ifp->if_init =3D vlan_ifinit; - ifp->if_start =3D vlan_start; - ifp->if_ioctl =3D vlan_ioctl; - ifp->if_output =3D ether_output; - ifp->if_snd.ifq_maxlen =3D ifqmaxlen; - ether_ifattach(ifp, ETHER_BPF_SUPPORTED); - /* Now undo some of the damage... */ - ifp->if_data.ifi_type =3D IFT_L2VLAN; - ifp->if_data.ifi_hdrlen =3D EVL_ENCAPLEN; - } -} - static int vlan_modevent(module_t mod, int type, void *data)=20 {=20 + int err; + switch (type) {=20 case MOD_LOAD:=20 - vlaninit(); + vlanunits->rm_type =3D RMAN_ARRAY; + vlanunits->rm_descr =3D "configurable if_vlan units"; + err =3D rman_init(vlanunits); + if (err !=3D 0) + return (err); + err =3D rman_manage_region(vlanunits, 0, VLAN_MAXUNIT); + if (err !=3D 0) { + printf("%s: vlanunits: rman_manage_region: Failed %d\n", + VLANNAME, err); + rman_fini(vlanunits); + return (err); + } + LIST_INIT(&ifv_list); + vlan_input_p =3D vlan_input; + vlan_input_tag_p =3D vlan_input_tag; + if_clone_attach(&vlan_cloner); break;=20 case MOD_UNLOAD:=20 - printf("if_vlan module unload - not possible for this module type\n");= =20 - return EINVAL;=20 + if_clone_detach(&vlan_cloner); + vlan_input_p =3D NULL; + vlan_input_tag_p =3D NULL; + while (!LIST_EMPTY(&ifv_list)) + vlan_clone_destroy(&LIST_FIRST(&ifv_list)->ifv_if); + err =3D rman_fini(vlanunits); + if (err !=3D 0) + return (err); + break; }=20 return 0;=20 }=20 @@ -213,7 +219,81 @@ =20 DECLARE_MODULE(if_vlan, vlan_mod, SI_SUB_PSEUDO, SI_ORDER_ANY); =20 +static int +vlan_clone_create(struct if_clone *ifc, int *unit) +{ + struct resource *r; + struct ifvlan *ifv; + struct ifnet *ifp; + int s; + + if (*unit > VLAN_MAXUNIT) + return (ENXIO); + + if (*unit < 0) { + r =3D rman_reserve_resource(vlanunits, 0, VLAN_MAXUNIT, 1, + RF_ALLOCATED | RF_ACTIVE, NULL); + if (r =3D=3D NULL) + return (ENOSPC); + *unit =3D rman_get_start(r); + } else { + r =3D rman_reserve_resource(vlanunits, *unit, *unit, 1, + RF_ALLOCATED | RF_ACTIVE, NULL); + if (r =3D=3D NULL) + return (EEXIST); + } + + ifv =3D malloc(sizeof(struct ifvlan), M_VLAN, M_WAITOK); + memset(ifv, 0, sizeof(struct ifvlan)); + ifp =3D &ifv->ifv_if; + SLIST_INIT(&ifv->vlan_mc_listhead); + + s =3D splnet(); + LIST_INSERT_HEAD(&ifv_list, ifv, ifv_list); + splx(s); + + ifp->if_softc =3D ifv; + ifp->if_name =3D "vlan"; + ifp->if_unit =3D *unit; + ifv->r_unit =3D r; + /* NB: flags are not set here */ + ifp->if_linkmib =3D &ifv->ifv_mib; + ifp->if_linkmiblen =3D sizeof ifv->ifv_mib; + /* NB: mtu is not set here */ + + ifp->if_init =3D vlan_ifinit; + ifp->if_start =3D vlan_start; + ifp->if_ioctl =3D vlan_ioctl; + ifp->if_output =3D ether_output; + ifp->if_snd.ifq_maxlen =3D ifqmaxlen; + ether_ifattach(ifp, ETHER_BPF_SUPPORTED); + /* Now undo some of the damage... */ + ifp->if_data.ifi_type =3D IFT_L2VLAN; + ifp->if_data.ifi_hdrlen =3D EVL_ENCAPLEN; + + return (0); +} + static void +vlan_clone_destroy(struct ifnet *ifp) +{ + struct ifvlan *ifv =3D ifp->if_softc; + int s; + int err; + + s =3D splnet(); + LIST_REMOVE(ifv, ifv_list); + vlan_unconfig(ifp); + splx(s); + + ether_ifdetach(ifp, ETHER_BPF_SUPPORTED); + + err =3D rman_release_resource(ifv->r_unit); + KASSERT(err =3D=3D 0, ("Unexpected error freeing resource")); + free(ifv, M_VLAN); +} + +static void vlan_ifinit(void *foo) { return; @@ -294,7 +374,7 @@ sizeof(struct ether_header)); evl =3D mtod(m, struct ether_vlan_header *); evl->evl_proto =3D evl->evl_encap_proto; - evl->evl_encap_proto =3D htons(vlan_proto); + evl->evl_encap_proto =3D htons(ETHERTYPE_VLAN); evl->evl_tag =3D htons(ifv->ifv_tag); #ifdef DEBUG printf("vlan_start: %*D\n", sizeof *evl, @@ -316,19 +396,18 @@ return; } =20 -int +static int vlan_input_tag(struct ether_header *eh, struct mbuf *m, u_int16_t t) { - int i; struct ifvlan *ifv; =20 - for (i =3D 0; i < NVLAN; i++) { - ifv =3D &ifv_softc[i]; + for (ifv =3D LIST_FIRST(&ifv_list); ifv !=3D NULL; + ifv =3D LIST_NEXT(ifv, ifv_list)) { if (ifv->ifv_tag =3D=3D t) break; } =20 - if (i >=3D NVLAN || (ifv->ifv_if.if_flags & IFF_UP) =3D=3D 0) { + if (ifv !=3DNULL || (ifv->ifv_if.if_flags & IFF_UP) =3D=3D 0) { m_free(m); return -1; /* So the parent can take note */ } @@ -345,21 +424,20 @@ return 0; } =20 -int +static int vlan_input(struct ether_header *eh, struct mbuf *m) { - int i; struct ifvlan *ifv; =20 - for (i =3D 0; i < NVLAN; i++) { - ifv =3D &ifv_softc[i]; + for (ifv =3D LIST_FIRST(&ifv_list); ifv !=3D NULL; + ifv =3D LIST_NEXT(ifv, ifv_list)) { if (m->m_pkthdr.rcvif =3D=3D ifv->ifv_p && (EVL_VLANOFTAG(ntohs(*mtod(m, u_int16_t *))) =3D=3D ifv->ifv_tag)) break; } =20 - if (i >=3D NVLAN || (ifv->ifv_if.if_flags & IFF_UP) =3D=3D 0) { + if (ifv !=3D NULL || (ifv->ifv_if.if_flags & IFF_UP) =3D=3D 0) { m_freem(m); return -1; /* so ether_input can take note */ } @@ -462,7 +540,7 @@ if (error) return(error); SLIST_REMOVE_HEAD(&ifv->vlan_mc_listhead, mc_entries); - free(mc, M_DEVBUF); + free(mc, M_VLAN); } } =20 Index: sys/net/if_vlan_var.h =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/if_vlan_var.h,v retrieving revision 1.9 diff -u -r1.9 if_vlan_var.h --- sys/net/if_vlan_var.h 2001/07/24 00:03:51 1.9 +++ sys/net/if_vlan_var.h 2001/07/27 21:01:48 @@ -47,6 +47,8 @@ u_int16_t ifvm_tag; /* tag to apply on packets leaving if */ } ifv_mib; SLIST_HEAD(__vlan_mchead, vlan_mc_entry) vlan_mc_listhead; + LIST_ENTRY(ifvlan) ifv_list; + struct resource *r_unit; /* resource allocated for this unit */ }; #define ifv_if ifv_ac.ac_if #define ifv_tag ifv_mib.ifvm_tag @@ -77,13 +79,5 @@ }; #define SIOCSETVLAN SIOCSIFGENERIC #define SIOCGETVLAN SIOCGIFGENERIC - -#ifdef _KERNEL -/* shared with if_ethersubr.c: */ -extern u_int vlan_proto; -extern int vlan_input(struct ether_header *eh, struct mbuf *m); -extern int vlan_input_tag(struct ether_header *eh, - struct mbuf *m, u_int16_t t); -#endif =20 #endif /* _NET_IF_VLAN_VAR_H_ */ Index: sys/pci/if_ti.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/pci/if_ti.c,v retrieving revision 1.51 diff -u -r1.51 if_ti.c --- sys/pci/if_ti.c 2001/07/25 00:19:59 1.51 +++ sys/pci/if_ti.c 2001/07/27 20:42:41 @@ -78,8 +78,6 @@ * - Andrew Gallatin for providing FreeBSD/Alpha support. */ =20 -#include "vlan.h" - #include #include #include @@ -94,14 +92,11 @@ #include #include #include - -#include - -#if NVLAN > 0 #include #include -#endif =20 +#include + #include #include #include @@ -1334,9 +1329,7 @@ if (sc->arpcom.ac_if.if_hwassist) rcb->ti_flags |=3D TI_RCB_FLAG_TCP_UDP_CKSUM | TI_RCB_FLAG_IP_CKSUM | TI_RCB_FLAG_NO_PHDR_CKSUM; -#if NVLAN > 0 rcb->ti_flags |=3D TI_RCB_FLAG_VLAN_ASSIST; -#endif =20 /* Set up the jumbo receive ring. */ rcb =3D &sc->ti_rdata->ti_info.ti_jumbo_rx_rcb; @@ -1347,9 +1340,7 @@ if (sc->arpcom.ac_if.if_hwassist) rcb->ti_flags |=3D TI_RCB_FLAG_TCP_UDP_CKSUM | TI_RCB_FLAG_IP_CKSUM | TI_RCB_FLAG_NO_PHDR_CKSUM; -#if NVLAN > 0 rcb->ti_flags |=3D TI_RCB_FLAG_VLAN_ASSIST; -#endif =20 /* * Set up the mini ring. Only activated on the @@ -1367,9 +1358,7 @@ if (sc->arpcom.ac_if.if_hwassist) rcb->ti_flags |=3D TI_RCB_FLAG_TCP_UDP_CKSUM | TI_RCB_FLAG_IP_CKSUM | TI_RCB_FLAG_NO_PHDR_CKSUM; -#if NVLAN > 0 rcb->ti_flags |=3D TI_RCB_FLAG_VLAN_ASSIST; -#endif =20 /* * Set up the receive return ring. @@ -1403,9 +1392,7 @@ rcb->ti_flags =3D 0; else rcb->ti_flags =3D TI_RCB_FLAG_HOST_RING; -#if NVLAN > 0 rcb->ti_flags |=3D TI_RCB_FLAG_VLAN_ASSIST; -#endif if (sc->arpcom.ac_if.if_hwassist) rcb->ti_flags |=3D TI_RCB_FLAG_TCP_UDP_CKSUM | TI_RCB_FLAG_IP_CKSUM | TI_RCB_FLAG_NO_PHDR_CKSUM; @@ -1738,22 +1725,18 @@ u_int32_t rxidx; struct ether_header *eh; struct mbuf *m =3D NULL; -#if NVLAN > 0 u_int16_t vlan_tag =3D 0; int have_tag =3D 0; -#endif =20 cur_rx =3D &sc->ti_rdata->ti_rx_return_ring[sc->ti_rx_saved_considx]; rxidx =3D cur_rx->ti_idx; TI_INC(sc->ti_rx_saved_considx, TI_RETURN_RING_CNT); =20 -#if NVLAN > 0 if (cur_rx->ti_flags & TI_BDFLAG_VLAN_TAG) { have_tag =3D 1; vlan_tag =3D cur_rx->ti_vlan_tag & 0xfff; } -#endif =20 if (cur_rx->ti_flags & TI_BDFLAG_JUMBO_RING) { TI_INC(sc->ti_jumbo, TI_JUMBO_RX_RING_CNT); @@ -1815,17 +1798,19 @@ m->m_pkthdr.csum_data =3D cur_rx->ti_tcp_udp_cksum; } =20 -#if NVLAN > 0 /* * If we received a packet with a vlan tag, pass it * to vlan_input() instead of ether_input(). */ if (have_tag) { - vlan_input_tag(eh, m, vlan_tag); + if (vlan_input_tag_p !=3D NULL) { + (*vlan_input_tag_p)(eh, m, vlan_tag); + } else { + m_free(m); + } have_tag =3D vlan_tag =3D 0; continue; } -#endif ether_input(ifp, eh, m); } =20 @@ -1963,14 +1948,12 @@ struct mbuf *m; u_int32_t frag, cur, cnt =3D 0; u_int16_t csum_flags =3D 0; -#if NVLAN > 0 struct ifvlan *ifv =3D NULL; =20 if ((m_head->m_flags & (M_PROTO1|M_PKTHDR)) =3D=3D (M_PROTO1|M_PKTHDR) && m_head->m_pkthdr.rcvif !=3D NULL && m_head->m_pkthdr.rcvif->if_type =3D=3D IFT_L2VLAN) ifv =3D m_head->m_pkthdr.rcvif->if_softc; -#endif =20 m =3D m_head; cur =3D frag =3D *txidx; @@ -2013,14 +1996,14 @@ TI_HOSTADDR(f->ti_addr) =3D vtophys(mtod(m, vm_offset_t)); f->ti_len =3D m->m_len; f->ti_flags =3D csum_flags; -#if NVLAN > 0 + if (ifv !=3D NULL) { f->ti_flags |=3D TI_BDFLAG_VLAN_TAG; f->ti_vlan_tag =3D ifv->ifv_tag & 0xfff; } else { f->ti_vlan_tag =3D 0; } -#endif + /* * Sanity check: avoid coming within 16 descriptors * of the end of the ring. --- sys/modules/if_vlan/Makefile.orig Fri Jul 13 17:14:21 2001 +++ sys/modules/if_vlan/Makefile Fri Jul 27 14:00:14 2001 @@ -0,0 +1,12 @@ +# $FreeBSD$ + +.PATH: ${.CURDIR}/../../net + +KMOD=3D if_vlan +SRCS=3D if_vlan.c opt_inet.h +NOMAN=3D + +opt_inet.h: + echo "#define INET 1" > ${.TARGET} + +.include --GvXjxJ+pjyke8COw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7ZeUWXY6L6fI4GtQRAgL+AKCM49r/UFCHvriO3uagKvFtO3Zk3wCfSOLE Hmr8m5Yajymonr4MmKgmEO0= =92jk -----END PGP SIGNATURE----- --GvXjxJ+pjyke8COw-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 31 5:21:18 2001 Delivered-To: freebsd-net@freebsd.org Received: from purus.tcoip (unknown [200.199.244.162]) by hub.freebsd.org (Postfix) with ESMTP id 658EC37B401 for ; Tue, 31 Jul 2001 05:21:15 -0700 (PDT) (envelope-from daniel.sobral@tcoip.com.br) Received: from tcoip.com.br (3d4mpiqpyv3hb25x@dcs.intra.tcoip.com.br [192.168.60.194]) by purus.tcoip (8.11.1/8.11.1) with ESMTP id f6VCKmA02318 for ; Tue, 31 Jul 2001 09:20:48 -0300 Message-ID: <3B66A2A0.2030603@tcoip.com.br> Date: Tue, 31 Jul 2001 09:20:48 -0300 From: "Daniel C. Sobral" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.2) Gecko/20010705 X-Accept-Language: en, pt-br, ja MIME-Version: 1.0 To: net@freebsd.org Subject: VLAN collisions Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I am seeing something weird here. I get collisions on one of my vlan interfaces. Huh? How come? How can this happen? -- Daniel C. Sobral (8-DCS) Daniel.Sobral@tcoip.com.br dcs@newsguy.com dcs@freebsd.org capo@notorious.bsdconspiracy.net It is undignified for a woman to play servant to a man who is not hers. -- Spock, "Amok Time", stardate 3372.7 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 31 8:28:59 2001 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 55C9C37B403 for ; Tue, 31 Jul 2001 08:28:55 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id f6VFSeA15660; Tue, 31 Jul 2001 11:28:40 -0400 (EDT) (envelope-from wollman) Date: Tue, 31 Jul 2001 11:28:40 -0400 (EDT) From: Garrett Wollman Message-Id: <200107311528.f6VFSeA15660@khavrinen.lcs.mit.edu> To: "Daniel C. Sobral" Cc: net@FreeBSD.ORG Subject: VLAN collisions In-Reply-To: <3B66A2A0.2030603@tcoip.com.br> References: <3B66A2A0.2030603@tcoip.com.br> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org < said: > I am seeing something weird here. I get collisions on one of my vlan > interfaces. Huh? How come? How can this happen? UTSL. /* * Do not run parent's if_start() if the parent is not up, * or parent's driver will cause a system crash. */ if ((p->if_flags & (IFF_UP | IFF_RUNNING)) != (IFF_UP | IFF_RUNNING)) { m_freem(m); ifp->if_data.ifi_collisions++; continue; } -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 31 11:47: 7 2001 Delivered-To: freebsd-net@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id E24CD37B403; Tue, 31 Jul 2001 11:46:09 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id f6VIk9q16945; Tue, 31 Jul 2001 11:46:09 -0700 Date: Tue, 31 Jul 2001 11:46:09 -0700 From: Brooks Davis To: net@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: review request: vlan cloning and modularization patch Message-ID: <20010731114609.A16327@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="PEIAKu/WMn1b1Hv9" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010730155207.A19629@Odin.AC.HMC.Edu>; from brooks@one-eyed-alien.net on Mon, Jul 30, 2001 at 03:52:07PM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I've updated the patch to fix a bug in ether_input and wrap vlan_input(_tag) in marcos to enable locking later. This patch also reflects the latest fixes to the txp driver. I've included it below or you can find it at: http://people.freebsd.org/~brooks/patches/vlan.diff Apply the patch as before. -- 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 Index: share/man/man4/vlan.4 =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/share/man/man4/vlan.4,v retrieving revision 1.1 diff -u -r1.1 vlan.4 --- share/man/man4/vlan.4 2001/07/28 12:27:06 1.1 +++ share/man/man4/vlan.4 2001/07/30 22:38:49 @@ -33,7 +33,7 @@ .Nd IEEE 802.1Q VLAN network interface .Sh SYNOPSIS .\" In -stable: .Cd pseudo-device vlan Op Ar count -.Cd device vlan Op Ar count +.Cd device vlan .\" .Sh DESCRIPTION The Index: sys/conf/files =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/conf/files,v retrieving revision 1.555 diff -u -r1.555 files --- sys/conf/files 2001/07/26 23:04:46 1.555 +++ sys/conf/files 2001/07/30 22:33:18 @@ -907,7 +907,7 @@ net/if_stf.c optional stf net/if_tun.c optional tun net/if_tap.c optional tap -net/if_vlan.c count vlan +net/if_vlan.c optional vlan net/intrq.c standard net/net_osdep.c standard net/ppp_deflate.c optional ppp_deflate @@ -1020,8 +1020,11 @@ netgraph/ng_echo.c optional netgraph_echo netgraph/ng_ether.c optional netgraph_ether netgraph/ng_frame_relay.c optional netgraph_frame_relay +netgraph/ng_gif.c optional netgraph_gif +netgraph/ng_gif_demux.c optional netgraph_gif_demux netgraph/ng_hole.c optional netgraph_hole netgraph/ng_iface.c optional netgraph_iface +netgraph/ng_ip_input.c optional netgraph_ip_input netgraph/ng_ksocket.c optional netgraph_ksocket netgraph/ng_lmi.c optional netgraph_lmi netgraph/ng_mppc.c optional netgraph_mppc_compression Index: sys/dev/nge/if_nge.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/dev/nge/if_nge.c,v retrieving revision 1.19 diff -u -r1.19 if_nge.c --- sys/dev/nge/if_nge.c 2001/07/25 00:19:55 1.19 +++ sys/dev/nge/if_nge.c 2001/07/31 00:23:42 @@ -87,8 +87,6 @@ * if the user selects an MTU larger than 8152 (8170 - 18). */ =20 -#include "vlan.h" - #include #include #include @@ -102,11 +100,8 @@ #include #include #include - -#if NVLAN > 0 #include #include -#endif =20 #include =20 @@ -1335,16 +1330,14 @@ m->m_pkthdr.csum_data =3D 0xffff; } =20 -#if NVLAN > 0 /* * If we received a packet with a vlan tag, pass it * to vlan_input() instead of ether_input(). */ if (extsts & NGE_RXEXTSTS_VLANPKT) { - vlan_input_tag(eh, m, extsts & NGE_RXEXTSTS_VTCI); + VLAN_INPUT_TAG(ifp, eh, m, extsts & NGE_RXEXTSTS_VTCI); continue; } -#endif =20 ether_input(ifp, eh, m); } @@ -1539,14 +1532,12 @@ struct nge_desc *f =3D NULL; struct mbuf *m; int frag, cur, cnt =3D 0; -#if NVLAN > 0 struct ifvlan *ifv =3D NULL; =20 if ((m_head->m_flags & (M_PROTO1|M_PKTHDR)) =3D=3D (M_PROTO1|M_PKTHDR) && m_head->m_pkthdr.rcvif !=3D NULL && m_head->m_pkthdr.rcvif->if_type =3D=3D IFT_L2VLAN) ifv =3D m_head->m_pkthdr.rcvif->if_softc; -#endif =20 /* * Start packing the mbufs in this chain into @@ -1588,12 +1579,10 @@ NGE_TXEXTSTS_UDPCSUM; } =20 -#if NVLAN > 0 if (ifv !=3D NULL) { sc->nge_ldata->nge_tx_list[cur].nge_extsts |=3D (NGE_TXEXTSTS_VLANPKT|ifv->ifv_tag); } -#endif =20 sc->nge_ldata->nge_tx_list[cur].nge_mbuf =3D m_head; sc->nge_ldata->nge_tx_list[cur].nge_ctl &=3D ~NGE_CMDSTS_MORE; @@ -1754,7 +1743,6 @@ */ CSR_WRITE_4(sc, NGE_VLAN_IP_RXCTL, NGE_VIPRXCTL_IPCSUM_ENB); =20 -#if NVLAN > 0 /* * If VLAN support is enabled, tell the chip to detect * and strip VLAN tag info from received frames. The tag @@ -1762,7 +1750,6 @@ */ NGE_SETBIT(sc, NGE_VLAN_IP_RXCTL, NGE_VIPRXCTL_TAG_DETECT_ENB|NGE_VIPRXCTL_TAG_STRIP_ENB); -#endif =20 /* Set TX configuration */ CSR_WRITE_4(sc, NGE_TX_CFG, NGE_TXCFG); @@ -1772,14 +1759,12 @@ */ CSR_WRITE_4(sc, NGE_VLAN_IP_TXCTL, NGE_VIPTXCTL_CSUM_PER_PKT); =20 -#if NVLAN > 0 /* * If VLAN support is enabled, tell the chip to insert * VLAN tags on a per-packet basis as dictated by the * code in the frame encapsulation routine. */ NGE_SETBIT(sc, NGE_VLAN_IP_TXCTL, NGE_VIPTXCTL_TAG_PER_PKT); -#endif =20 /* Set full/half duplex mode. */ if ((mii->mii_media_active & IFM_GMASK) =3D=3D IFM_FDX) { Index: sys/dev/txp/if_txp.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/dev/txp/if_txp.c,v retrieving revision 1.5 diff -u -r1.5 if_txp.c --- sys/dev/txp/if_txp.c 2001/07/31 16:38:58 1.5 +++ sys/dev/txp/if_txp.c 2001/07/31 18:27:57 @@ -39,8 +39,6 @@ * Driver for 3c990 (Typhoon) Ethernet ASIC */ =20 -#include "vlan.h" - #include #include #include @@ -54,6 +52,7 @@ #include #include #include +#include =20 #include #include @@ -66,10 +65,6 @@ =20 #include =20 -#if NVLAN > 0 -#include -#endif - #include /* for vtophys */ #include /* for vtophys */ #include /* for DELAY */ @@ -809,14 +804,11 @@ /* Remove header from mbuf and pass it on. */ m_adj(m, sizeof(struct ether_header)); =20 -#if NVLAN > 0 if (rxd->rx_stat & RX_STAT_VLAN) { - if (vlan_input_tag(eh, m, - htons(rxd->rx_vlan >> 16)) < 0) - ifp->if_noproto++; + VLAN_INPUT_TAG(ifp, eh, m, htons(rxd->rx_vlan >> 16)); goto next; } -#endif + ether_input(ifp, eh, m); =20 next: @@ -1317,9 +1309,7 @@ struct mbuf *m, *m0; struct txp_swdesc *sd; u_int32_t firstprod, firstcnt, prod, cnt; -#if NVLAN > 0 struct ifvlan *ifv; -#endif =20 if ((ifp->if_flags & (IFF_RUNNING | IFF_OACTIVE)) !=3D IFF_RUNNING) return; @@ -1356,14 +1346,13 @@ if (++cnt >=3D (TX_ENTRIES - 4)) goto oactive; =20 -#if NVLAN > 0 if ((m->m_flags & (M_PROTO1|M_PKTHDR)) =3D=3D (M_PROTO1|M_PKTHDR) && m->m_pkthdr.rcvif !=3D NULL) { ifv =3D m->m_pkthdr.rcvif->if_softc; txd->tx_pflags =3D TX_PFLAGS_VLAN | (htons(ifv->ifv_tag) << TX_PFLAGS_VLANTAG_S); } -#endif + if (m->m_pkthdr.csum_flags & CSUM_IP) txd->tx_pflags |=3D TX_PFLAGS_IPCKSUM; =20 @@ -1879,12 +1868,10 @@ sc->sc_tx_capability =3D ext->ext_1 & OFFLOAD_MASK; sc->sc_rx_capability =3D ext->ext_2 & OFFLOAD_MASK; =20 -#if NVLAN > 0 if (rsp->rsp_par2 & rsp->rsp_par3 & OFFLOAD_VLAN) { sc->sc_tx_capability |=3D OFFLOAD_VLAN; sc->sc_rx_capability |=3D OFFLOAD_VLAN; } -#endif =20 #if 0 /* not ready yet */ Index: sys/i386/conf/NOTES =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/i386/conf/NOTES,v retrieving revision 1.942 diff -u -r1.942 NOTES --- sys/i386/conf/NOTES 2001/07/25 00:15:02 1.942 +++ sys/i386/conf/NOTES 2001/07/31 00:48:01 @@ -517,7 +517,7 @@ # See pppd(8) for more details. # device ether #Generic Ethernet -device vlan 1 #VLAN support +device vlan #VLAN support device token #Generic TokenRing device fddi #Generic FDDI device sppp #Generic Synchronous PPP Index: sys/net/ethernet.h =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/ethernet.h,v retrieving revision 1.16 diff -u -r1.16 ethernet.h --- sys/net/ethernet.h 2000/07/18 22:44:52 1.16 +++ sys/net/ethernet.h 2001/07/31 00:45:51 @@ -99,6 +99,41 @@ extern void (*ng_ether_attach_p)(struct ifnet *ifp); extern void (*ng_ether_detach_p)(struct ifnet *ifp); =20 +extern int (*vlan_input_p)(struct ether_header *eh, struct mbuf *m); +extern int (*vlan_input_tag_p)(struct ether_header *eh, struct mbuf *m, + u_int16_t t); +#define _VLAN_INPUT(ifp, eh, m) do { \ + if (vlan_input_p !=3D NULL) { \ + if ((*vlan_input_p)(eh, m) =3D=3D -1) \ + (ifp)->if_noproto++; \ + } else { \ + m_free(m); \ + (ifp)->if_noproto++; \ + } \ +} while (0) + +#define VLAN_INPUT(ifp, eh, m) do { \ + /* XXX: lock */ \ + _VLAN_INPUT(ifp, eh, m); \ + /* XXX: unlock */ \ +} while (0) + +#define _VLAN_INPUT_TAG(ifp, eh, m, t) do { \ + if (vlan_input_tag_p !=3D NULL) { \ + if ((*vlan_input_tag_p)(eh, m, t) =3D=3D -1) \ + (ifp)->if_noproto++; \ + } else { \ + m_free(m); \ + (ifp)->if_noproto++; \ + } \ +} while (0) + +#define VLAN_INPUT_TAG(ifp, eh, m, t) do { \ + /* XXX: lock */ \ + _VLAN_INPUT_TAG(ifp, eh, m, t); \ + /* XXX: unlock */ \ +} while (0) + #else /* _KERNEL */ =20 #include Index: sys/net/if_ethersubr.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/if_ethersubr.c,v retrieving revision 1.94 diff -u -r1.94 if_ethersubr.c --- sys/net/if_ethersubr.c 2001/06/15 21:00:32 1.94 +++ sys/net/if_ethersubr.c 2001/07/31 00:18:02 @@ -39,7 +39,6 @@ #include "opt_inet6.h" #include "opt_ipx.h" #include "opt_bdg.h" -#include "opt_netgraph.h" =20 #include #include @@ -101,11 +100,6 @@ #include #endif =20 -#include "vlan.h" -#if NVLAN > 0 -#include -#endif /* NVLAN > 0 */ - /* netgraph node hooks for ng_ether(4) */ void (*ng_ether_input_p)(struct ifnet *ifp, struct mbuf **mp, struct ether_header *eh); @@ -115,6 +109,10 @@ void (*ng_ether_attach_p)(struct ifnet *ifp); void (*ng_ether_detach_p)(struct ifnet *ifp); =20 +int (*vlan_input_p)(struct ether_header *eh, struct mbuf *m); +int (*vlan_input_tag_p)(struct ether_header *eh, struct mbuf *m, + u_int16_t t); + static int ether_resolvemulti __P((struct ifnet *, struct sockaddr **, struct sockaddr *)); u_char etherbroadcastaddr[6] =3D { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff }; @@ -524,14 +522,6 @@ =20 ether_type =3D ntohs(eh->ether_type); =20 -#if NVLAN > 0 - if (ether_type =3D=3D vlan_proto) { - if (vlan_input(eh, m) < 0) - ifp->if_data.ifi_noproto++; - return; - } -#endif /* NVLAN > 0 */ - switch (ether_type) { #ifdef INET case ETHERTYPE_IP: @@ -582,6 +572,9 @@ aarpinput(IFP2AC(ifp), m); /* XXX */ return; #endif NETATALK + case ETHERTYPE_VLAN: + VLAN_INPUT(ifp, eh, m); + return; default: #ifdef IPX if (ef_inputp && ef_inputp(ifp, eh, m) =3D=3D 0) Index: sys/net/if_vlan.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/if_vlan.c,v retrieving revision 1.30 diff -u -r1.30 if_vlan.c --- sys/net/if_vlan.c 2001/07/24 17:14:37 1.30 +++ sys/net/if_vlan.c 2001/07/27 00:19:01 @@ -54,7 +54,6 @@ * tag value that goes with it. */ =20 -#include "vlan.h" #include "opt_inet.h" =20 #include @@ -67,6 +66,8 @@ #include #include #include +#include /* XXX: Shouldn't really be required! */ +#include =20 #include #include @@ -81,23 +82,32 @@ #include #endif =20 +#define VLANNAME "vlan" +#define VLAN_MAXUNIT 0x7fff /* ifp->if_unit is only 15 bits */ + SYSCTL_DECL(_net_link); SYSCTL_NODE(_net_link, IFT_L2VLAN, vlan, CTLFLAG_RW, 0, "IEEE 802.1Q VLAN"= ); SYSCTL_NODE(_net_link_vlan, PF_LINK, link, CTLFLAG_RW, 0, "for consistency= "); - -u_int vlan_proto =3D ETHERTYPE_VLAN; -SYSCTL_INT(_net_link_vlan_link, VLANCTL_PROTO, proto, CTLFLAG_RW, &vlan_pr= oto, - 0, "Ethernet protocol used for VLAN encapsulation"); =20 -static struct ifvlan ifv_softc[NVLAN]; +static MALLOC_DEFINE(M_VLAN, "vlan", "802.1Q Virtual LAN Interface"); +static struct rman vlanunits[1]; +static LIST_HEAD(, ifvlan) ifv_list; =20 +static int vlan_clone_create(struct if_clone *, int *); +static void vlan_clone_destroy(struct ifnet *); static void vlan_start(struct ifnet *ifp); static void vlan_ifinit(void *foo); +static int vlan_input(struct ether_header *eh, struct mbuf *m); +static int vlan_input_tag(struct ether_header *eh, struct mbuf *m, + u_int16_t t); static int vlan_ioctl(struct ifnet *ifp, u_long cmd, caddr_t addr); static int vlan_setmulti(struct ifnet *ifp); static int vlan_unconfig(struct ifnet *ifp); static int vlan_config(struct ifvlan *ifv, struct ifnet *p); =20 +struct if_clone vlan_cloner =3D + IF_CLONE_INITIALIZER("vlan", vlan_clone_create, vlan_clone_destroy); + /* * Program our multicast filter. What we're actually doing is * programming the multicast filter of the parent. This has the @@ -142,14 +152,14 @@ if (error) return(error); SLIST_REMOVE_HEAD(&sc->vlan_mc_listhead, mc_entries); - free(mc, M_DEVBUF); + free(mc, M_VLAN); } =20 /* Now program new ones. */ TAILQ_FOREACH(ifma, &ifp->if_multiaddrs, ifma_link) { if (ifma->ifma_addr->sa_family !=3D AF_LINK) continue; - mc =3D malloc(sizeof(struct vlan_mc_entry), M_DEVBUF, M_WAITOK); + mc =3D malloc(sizeof(struct vlan_mc_entry), M_VLAN, M_WAITOK); bcopy(LLADDR((struct sockaddr_dl *)ifma->ifma_addr), (char *)&mc->mc_addr, ETHER_ADDR_LEN); SLIST_INSERT_HEAD(&sc->vlan_mc_listhead, mc, mc_entries); @@ -163,44 +173,40 @@ return(0); } =20 -static void -vlaninit(void) -{ - int i; - - for (i =3D 0; i < NVLAN; i++) { - struct ifnet *ifp =3D &ifv_softc[i].ifv_if; - - ifp->if_softc =3D &ifv_softc[i]; - ifp->if_name =3D "vlan"; - ifp->if_unit =3D i; - /* NB: flags are not set here */ - ifp->if_linkmib =3D &ifv_softc[i].ifv_mib; - ifp->if_linkmiblen =3D sizeof ifv_softc[i].ifv_mib; - /* NB: mtu is not set here */ - - ifp->if_init =3D vlan_ifinit; - ifp->if_start =3D vlan_start; - ifp->if_ioctl =3D vlan_ioctl; - ifp->if_output =3D ether_output; - ifp->if_snd.ifq_maxlen =3D ifqmaxlen; - ether_ifattach(ifp, ETHER_BPF_SUPPORTED); - /* Now undo some of the damage... */ - ifp->if_data.ifi_type =3D IFT_L2VLAN; - ifp->if_data.ifi_hdrlen =3D EVL_ENCAPLEN; - } -} - static int vlan_modevent(module_t mod, int type, void *data)=20 {=20 + int err; + switch (type) {=20 case MOD_LOAD:=20 - vlaninit(); + vlanunits->rm_type =3D RMAN_ARRAY; + vlanunits->rm_descr =3D "configurable if_vlan units"; + err =3D rman_init(vlanunits); + if (err !=3D 0) + return (err); + err =3D rman_manage_region(vlanunits, 0, VLAN_MAXUNIT); + if (err !=3D 0) { + printf("%s: vlanunits: rman_manage_region: Failed %d\n", + VLANNAME, err); + rman_fini(vlanunits); + return (err); + } + LIST_INIT(&ifv_list); + vlan_input_p =3D vlan_input; + vlan_input_tag_p =3D vlan_input_tag; + if_clone_attach(&vlan_cloner); break;=20 case MOD_UNLOAD:=20 - printf("if_vlan module unload - not possible for this module type\n");= =20 - return EINVAL;=20 + if_clone_detach(&vlan_cloner); + vlan_input_p =3D NULL; + vlan_input_tag_p =3D NULL; + while (!LIST_EMPTY(&ifv_list)) + vlan_clone_destroy(&LIST_FIRST(&ifv_list)->ifv_if); + err =3D rman_fini(vlanunits); + if (err !=3D 0) + return (err); + break; }=20 return 0;=20 }=20 @@ -213,7 +219,81 @@ =20 DECLARE_MODULE(if_vlan, vlan_mod, SI_SUB_PSEUDO, SI_ORDER_ANY); =20 +static int +vlan_clone_create(struct if_clone *ifc, int *unit) +{ + struct resource *r; + struct ifvlan *ifv; + struct ifnet *ifp; + int s; + + if (*unit > VLAN_MAXUNIT) + return (ENXIO); + + if (*unit < 0) { + r =3D rman_reserve_resource(vlanunits, 0, VLAN_MAXUNIT, 1, + RF_ALLOCATED | RF_ACTIVE, NULL); + if (r =3D=3D NULL) + return (ENOSPC); + *unit =3D rman_get_start(r); + } else { + r =3D rman_reserve_resource(vlanunits, *unit, *unit, 1, + RF_ALLOCATED | RF_ACTIVE, NULL); + if (r =3D=3D NULL) + return (EEXIST); + } + + ifv =3D malloc(sizeof(struct ifvlan), M_VLAN, M_WAITOK); + memset(ifv, 0, sizeof(struct ifvlan)); + ifp =3D &ifv->ifv_if; + SLIST_INIT(&ifv->vlan_mc_listhead); + + s =3D splnet(); + LIST_INSERT_HEAD(&ifv_list, ifv, ifv_list); + splx(s); + + ifp->if_softc =3D ifv; + ifp->if_name =3D "vlan"; + ifp->if_unit =3D *unit; + ifv->r_unit =3D r; + /* NB: flags are not set here */ + ifp->if_linkmib =3D &ifv->ifv_mib; + ifp->if_linkmiblen =3D sizeof ifv->ifv_mib; + /* NB: mtu is not set here */ + + ifp->if_init =3D vlan_ifinit; + ifp->if_start =3D vlan_start; + ifp->if_ioctl =3D vlan_ioctl; + ifp->if_output =3D ether_output; + ifp->if_snd.ifq_maxlen =3D ifqmaxlen; + ether_ifattach(ifp, ETHER_BPF_SUPPORTED); + /* Now undo some of the damage... */ + ifp->if_data.ifi_type =3D IFT_L2VLAN; + ifp->if_data.ifi_hdrlen =3D EVL_ENCAPLEN; + + return (0); +} + static void +vlan_clone_destroy(struct ifnet *ifp) +{ + struct ifvlan *ifv =3D ifp->if_softc; + int s; + int err; + + s =3D splnet(); + LIST_REMOVE(ifv, ifv_list); + vlan_unconfig(ifp); + splx(s); + + ether_ifdetach(ifp, ETHER_BPF_SUPPORTED); + + err =3D rman_release_resource(ifv->r_unit); + KASSERT(err =3D=3D 0, ("Unexpected error freeing resource")); + free(ifv, M_VLAN); +} + +static void vlan_ifinit(void *foo) { return; @@ -294,7 +374,7 @@ sizeof(struct ether_header)); evl =3D mtod(m, struct ether_vlan_header *); evl->evl_proto =3D evl->evl_encap_proto; - evl->evl_encap_proto =3D htons(vlan_proto); + evl->evl_encap_proto =3D htons(ETHERTYPE_VLAN); evl->evl_tag =3D htons(ifv->ifv_tag); #ifdef DEBUG printf("vlan_start: %*D\n", sizeof *evl, @@ -316,19 +396,18 @@ return; } =20 -int +static int vlan_input_tag(struct ether_header *eh, struct mbuf *m, u_int16_t t) { - int i; struct ifvlan *ifv; =20 - for (i =3D 0; i < NVLAN; i++) { - ifv =3D &ifv_softc[i]; + for (ifv =3D LIST_FIRST(&ifv_list); ifv !=3D NULL; + ifv =3D LIST_NEXT(ifv, ifv_list)) { if (ifv->ifv_tag =3D=3D t) break; } =20 - if (i >=3D NVLAN || (ifv->ifv_if.if_flags & IFF_UP) =3D=3D 0) { + if (ifv !=3DNULL || (ifv->ifv_if.if_flags & IFF_UP) =3D=3D 0) { m_free(m); return -1; /* So the parent can take note */ } @@ -345,21 +424,20 @@ return 0; } =20 -int +static int vlan_input(struct ether_header *eh, struct mbuf *m) { - int i; struct ifvlan *ifv; =20 - for (i =3D 0; i < NVLAN; i++) { - ifv =3D &ifv_softc[i]; + for (ifv =3D LIST_FIRST(&ifv_list); ifv !=3D NULL; + ifv =3D LIST_NEXT(ifv, ifv_list)) { if (m->m_pkthdr.rcvif =3D=3D ifv->ifv_p && (EVL_VLANOFTAG(ntohs(*mtod(m, u_int16_t *))) =3D=3D ifv->ifv_tag)) break; } =20 - if (i >=3D NVLAN || (ifv->ifv_if.if_flags & IFF_UP) =3D=3D 0) { + if (ifv !=3D NULL || (ifv->ifv_if.if_flags & IFF_UP) =3D=3D 0) { m_freem(m); return -1; /* so ether_input can take note */ } @@ -462,7 +540,7 @@ if (error) return(error); SLIST_REMOVE_HEAD(&ifv->vlan_mc_listhead, mc_entries); - free(mc, M_DEVBUF); + free(mc, M_VLAN); } } =20 Index: sys/net/if_vlan_var.h =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/if_vlan_var.h,v retrieving revision 1.9 diff -u -r1.9 if_vlan_var.h --- sys/net/if_vlan_var.h 2001/07/24 00:03:51 1.9 +++ sys/net/if_vlan_var.h 2001/07/27 21:01:48 @@ -47,6 +47,8 @@ u_int16_t ifvm_tag; /* tag to apply on packets leaving if */ } ifv_mib; SLIST_HEAD(__vlan_mchead, vlan_mc_entry) vlan_mc_listhead; + LIST_ENTRY(ifvlan) ifv_list; + struct resource *r_unit; /* resource allocated for this unit */ }; #define ifv_if ifv_ac.ac_if #define ifv_tag ifv_mib.ifvm_tag @@ -77,13 +79,5 @@ }; #define SIOCSETVLAN SIOCSIFGENERIC #define SIOCGETVLAN SIOCGIFGENERIC - -#ifdef _KERNEL -/* shared with if_ethersubr.c: */ -extern u_int vlan_proto; -extern int vlan_input(struct ether_header *eh, struct mbuf *m); -extern int vlan_input_tag(struct ether_header *eh, - struct mbuf *m, u_int16_t t); -#endif =20 #endif /* _NET_IF_VLAN_VAR_H_ */ Index: sys/pci/if_ti.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/pci/if_ti.c,v retrieving revision 1.51 diff -u -r1.51 if_ti.c --- sys/pci/if_ti.c 2001/07/25 00:19:59 1.51 +++ sys/pci/if_ti.c 2001/07/31 00:21:47 @@ -78,8 +78,6 @@ * - Andrew Gallatin for providing FreeBSD/Alpha support. */ =20 -#include "vlan.h" - #include #include #include @@ -94,14 +92,11 @@ #include #include #include - -#include - -#if NVLAN > 0 #include #include -#endif =20 +#include + #include #include #include @@ -1334,9 +1329,7 @@ if (sc->arpcom.ac_if.if_hwassist) rcb->ti_flags |=3D TI_RCB_FLAG_TCP_UDP_CKSUM | TI_RCB_FLAG_IP_CKSUM | TI_RCB_FLAG_NO_PHDR_CKSUM; -#if NVLAN > 0 rcb->ti_flags |=3D TI_RCB_FLAG_VLAN_ASSIST; -#endif =20 /* Set up the jumbo receive ring. */ rcb =3D &sc->ti_rdata->ti_info.ti_jumbo_rx_rcb; @@ -1347,9 +1340,7 @@ if (sc->arpcom.ac_if.if_hwassist) rcb->ti_flags |=3D TI_RCB_FLAG_TCP_UDP_CKSUM | TI_RCB_FLAG_IP_CKSUM | TI_RCB_FLAG_NO_PHDR_CKSUM; -#if NVLAN > 0 rcb->ti_flags |=3D TI_RCB_FLAG_VLAN_ASSIST; -#endif =20 /* * Set up the mini ring. Only activated on the @@ -1367,9 +1358,7 @@ if (sc->arpcom.ac_if.if_hwassist) rcb->ti_flags |=3D TI_RCB_FLAG_TCP_UDP_CKSUM | TI_RCB_FLAG_IP_CKSUM | TI_RCB_FLAG_NO_PHDR_CKSUM; -#if NVLAN > 0 rcb->ti_flags |=3D TI_RCB_FLAG_VLAN_ASSIST; -#endif =20 /* * Set up the receive return ring. @@ -1403,9 +1392,7 @@ rcb->ti_flags =3D 0; else rcb->ti_flags =3D TI_RCB_FLAG_HOST_RING; -#if NVLAN > 0 rcb->ti_flags |=3D TI_RCB_FLAG_VLAN_ASSIST; -#endif if (sc->arpcom.ac_if.if_hwassist) rcb->ti_flags |=3D TI_RCB_FLAG_TCP_UDP_CKSUM | TI_RCB_FLAG_IP_CKSUM | TI_RCB_FLAG_NO_PHDR_CKSUM; @@ -1738,22 +1725,18 @@ u_int32_t rxidx; struct ether_header *eh; struct mbuf *m =3D NULL; -#if NVLAN > 0 u_int16_t vlan_tag =3D 0; int have_tag =3D 0; -#endif =20 cur_rx =3D &sc->ti_rdata->ti_rx_return_ring[sc->ti_rx_saved_considx]; rxidx =3D cur_rx->ti_idx; TI_INC(sc->ti_rx_saved_considx, TI_RETURN_RING_CNT); =20 -#if NVLAN > 0 if (cur_rx->ti_flags & TI_BDFLAG_VLAN_TAG) { have_tag =3D 1; vlan_tag =3D cur_rx->ti_vlan_tag & 0xfff; } -#endif =20 if (cur_rx->ti_flags & TI_BDFLAG_JUMBO_RING) { TI_INC(sc->ti_jumbo, TI_JUMBO_RX_RING_CNT); @@ -1815,17 +1798,15 @@ m->m_pkthdr.csum_data =3D cur_rx->ti_tcp_udp_cksum; } =20 -#if NVLAN > 0 /* * If we received a packet with a vlan tag, pass it * to vlan_input() instead of ether_input(). */ if (have_tag) { - vlan_input_tag(eh, m, vlan_tag); + VLAN_INPUT_TAG(ifp, eh, m, vlan_tag); have_tag =3D vlan_tag =3D 0; continue; } -#endif ether_input(ifp, eh, m); } =20 @@ -1963,14 +1944,12 @@ struct mbuf *m; u_int32_t frag, cur, cnt =3D 0; u_int16_t csum_flags =3D 0; -#if NVLAN > 0 struct ifvlan *ifv =3D NULL; =20 if ((m_head->m_flags & (M_PROTO1|M_PKTHDR)) =3D=3D (M_PROTO1|M_PKTHDR) && m_head->m_pkthdr.rcvif !=3D NULL && m_head->m_pkthdr.rcvif->if_type =3D=3D IFT_L2VLAN) ifv =3D m_head->m_pkthdr.rcvif->if_softc; -#endif =20 m =3D m_head; cur =3D frag =3D *txidx; @@ -2013,14 +1992,14 @@ TI_HOSTADDR(f->ti_addr) =3D vtophys(mtod(m, vm_offset_t)); f->ti_len =3D m->m_len; f->ti_flags =3D csum_flags; -#if NVLAN > 0 + if (ifv !=3D NULL) { f->ti_flags |=3D TI_BDFLAG_VLAN_TAG; f->ti_vlan_tag =3D ifv->ifv_tag & 0xfff; } else { f->ti_vlan_tag =3D 0; } -#endif + /* * Sanity check: avoid coming within 16 descriptors * of the end of the ring. --- sys/modules/if_vlan/Makefile.orig Fri Jul 13 17:14:21 2001 +++ sys/modules/if_vlan/Makefile Fri Jul 27 14:00:14 2001 @@ -0,0 +1,12 @@ +# $FreeBSD$ + +.PATH: ${.CURDIR}/../../net + +KMOD=3D if_vlan +SRCS=3D if_vlan.c opt_inet.h +NOMAN=3D + +opt_inet.h: + echo "#define INET 1" > ${.TARGET} + +.include --PEIAKu/WMn1b1Hv9 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7ZvztXY6L6fI4GtQRAitUAKDCzY6h29Ka3WO/r+skpOM1VguFaQCePNri NcTwIVt7wdfInWrkZaOdkAs= =gm7s -----END PGP SIGNATURE----- --PEIAKu/WMn1b1Hv9-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 31 19:42:24 2001 Delivered-To: freebsd-net@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id 2D25337B401; Tue, 31 Jul 2001 19:42:18 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id f712gIU12586; Tue, 31 Jul 2001 19:42:18 -0700 Date: Tue, 31 Jul 2001 19:42:17 -0700 From: Brooks Davis To: net@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: review request: vlan cloning and modularization patch Message-ID: <20010731194217.A12426@Odin.AC.HMC.Edu> References: <20010730155207.A19629@Odin.AC.HMC.Edu> <20010731114609.A16327@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="YiEDa0DAkWCtVeE4" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010731114609.A16327@Odin.AC.HMC.Edu>; from brooks@one-eyed-alien.net on Tue, Jul 31, 2001 at 11:46:09AM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 31, 2001 at 11:46:09AM -0700, Brooks Davis wrote: > I've updated the patch to fix a bug in ether_input and wrap > vlan_input(_tag) in marcos to enable locking later. This patch also > reflects the latest fixes to the txp driver. I've included it below or > you can find it at: >=20 > http://people.freebsd.org/~brooks/patches/vlan.diff >=20 > Apply the patch as before. One last follow up. I'm going to be offline until around Monday the 6th so if you do find bugs or issues, I'm not ignoring you. :-) -- 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 --YiEDa0DAkWCtVeE4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7Z2yJXY6L6fI4GtQRAvNfAKDDTaP8yb3Y3LlB4rchCnzpmMmcoQCePR9j 9svljSU8zRcPek9GmvBkJtw= =68hC -----END PGP SIGNATURE----- --YiEDa0DAkWCtVeE4-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 1 5: 1:44 2001 Delivered-To: freebsd-net@freebsd.org Received: from assaris.sics.se (assaris.sics.se [193.10.66.234]) by hub.freebsd.org (Postfix) with ESMTP id 1EECD37B403 for ; Wed, 1 Aug 2001 05:01:33 -0700 (PDT) (envelope-from assar@assaris.sics.se) Received: (from assar@localhost) by assaris.sics.se (8.9.3/8.9.3) id OAA82195; Wed, 1 Aug 2001 14:00:59 +0200 (CEST) (envelope-from assar) To: Ian Dowse Cc: itojun@iijlab.net, freebsd-net@FreeBSD.ORG, Bernd Walter , Hajimu UMEMOTO Subject: Re: how to get AF_LOCAL from getaddrinfo() References: <200107161844.aa52089@salmon.maths.tcd.ie> From: Assar Westerlund Date: 01 Aug 2001 14:00:59 +0200 In-Reply-To: Ian Dowse's message of "Mon, 16 Jul 2001 18:44:39 +0100" Message-ID: <5lg0bct2f8.fsf@assaris.sics.se> Lines: 14 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) Emacs/20.6 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Ian Dowse writes: > Another important reason to add this feature is for compatibility > with other platforms' getaddrinfo() implementations. I just tried > a random Linux box here, and it seems to have very similar behaviour > to that implemented by my patch. There is also the general idea > that the way to encourage people to use a "preferred" interface is > to make it useful in as many situations as possible :-) Note that glibc just commented out PF_LOCAL support. But before that, getaddrinfo PF_UNSPEC actually could return PF_LOCAL addresses, which I think is not obvious and kind of wrong. Having it work for ai_family == PF_LOCAL seems ok to me. /assar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 1 6:55: 7 2001 Delivered-To: freebsd-net@freebsd.org Received: from net-ninja.com (cc213180-a.plymr1.tn.home.com [65.8.203.28]) by hub.freebsd.org (Postfix) with ESMTP id 17CA237B405 for ; Wed, 1 Aug 2001 06:55:04 -0700 (PDT) (envelope-from mwade@st3.com) Received: by net-ninja.com (Postfix, from userid 1000) id 51B616E8D0; Wed, 1 Aug 2001 09:54:19 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by net-ninja.com (Postfix) with ESMTP id 3F85A176020; Wed, 1 Aug 2001 09:54:19 -0400 (EDT) Date: Wed, 1 Aug 2001 09:54:19 -0400 (EDT) From: Mike Wade X-Sender: mwade@fxp0.net-ninja.com To: Deepak Jain Cc: freebsd-net@FreeBSD.ORG Subject: RE: FreeBSD 4.3 -> Windows 2000 Network Performance In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 30 Jul 2001, Deepak Jain wrote: > Have you tried the Windows 2000 -> Windows 2000 scenario? I botched the whole testing process... It appears the performance for both FreeBSD and Windows 2000 is ~350 mbit/sec. --- Mike Wade (mwade@st3.com) Network Engineer To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 1 8:36:32 2001 Delivered-To: freebsd-net@freebsd.org Received: from nef.ens.fr (nef.ens.fr [129.199.96.32]) by hub.freebsd.org (Postfix) with ESMTP id BA2D637B401; Wed, 1 Aug 2001 08:36:26 -0700 (PDT) (envelope-from Thomas.Pornin@ens.fr) Received: from bolet.ens.fr (bolet.ens.fr [129.199.99.10]) by nef.ens.fr (8.10.1/1.01.28121999) with ESMTP id f71FaPm71511 ; Wed, 1 Aug 2001 17:36:25 +0200 (CEST) Received: from (pornin@localhost) by bolet.ens.fr (8.11.3/jb-1.1) Date: Wed, 1 Aug 2001 17:36:25 +0200 From: Thomas Pornin To: freebsd-net@freebsd.org Cc: freebsd-alpha@freebsd.org Subject: PPPoE + Alpha + 32/64 bits Message-ID: <20010801173624.A13674@bolet.ens.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello, I recently connected my FreeBSD/Alpha (4.3-RELEASE) to an ADSL link using an Alcatel Speed Touch Home modem. As is, it was not working; after some digging, I found that there is a bug either in the ng_pppoe support, or in the modem. The problem is in the pppoe_finduniq() function. In order to identify sessions, the PPPoE code sends a tag with the first packet it sends to the modem; this tag is in fact a 64-bit pointer to some data structure in kernel space. When a packet of type PADO_CODE or PADS_CODE is received, the tag is compared with known pointers. However, only 32 bits are present in the return tag. So, if the original pointer is 0xfffffc00003b3d00, the tag contains only 0x003b3d00, which are the first four bytes of data (in little-endian representation). If I modify the pppoe_finduniq() function to accept matches on these four bytes, the connection is established, and remains fully functionnal afterwards. Some details: The Alpha is little-endian, but the data in the packets is big-endian. If the original pointer is 0xfffffc00003b3d00, the rebuilt tag from the response packet is actually 0x003b3d0000000000. I do not know if the 8-bytes tag is sent correctly, or if the modem is buggy, or whatever. Machine configuration: AXPpci33 at 166 MHz, 32 MB ram ethernet PCI adapter RealTek 8029 10baseT (ed0) modem Alcatel Speed Touch Home (ethernet) FreeBSD 4.3-RELEASE (with a small patch to enable ed0) Feel free to ask for any detail. --Thomas Pornin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 1 10:49:30 2001 Delivered-To: freebsd-net@freebsd.org Received: from hirogen.kabelfoon.nl (hirogen.kabelfoon.nl [62.45.45.69]) by hub.freebsd.org (Postfix) with ESMTP id A486E37B401; Wed, 1 Aug 2001 10:49:20 -0700 (PDT) (envelope-from pblok@inter.NL.net) Received: from ntpc (kf-pij-tg01-426.dial.kabelfoon.nl [62.45.89.172]) by hirogen.kabelfoon.nl (Postfix) with SMTP id 353B77C3D; Wed, 1 Aug 2001 19:49:15 +0200 (CEST) Reply-To: From: "Peter Blok" To: "'Thomas Pornin'" , Cc: Subject: RE: PPPoE + Alpha + 32/64 bits Date: Wed, 1 Aug 2001 19:45:09 +0200 Message-ID: <000001c11ab1$b5b92d70$8a02a8c0@ntpc> 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 CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20010801173624.A13674@bolet.ens.fr> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org What did you patch in the mpd daemon. I found a lot endian issues with it, but due to work pressure I didn't finish it. -----Original Message----- From: owner-freebsd-alpha@FreeBSD.ORG [mailto:owner-freebsd-alpha@FreeBSD.ORG]On Behalf Of Thomas Pornin Sent: Wednesday, August 01, 2001 17:36 To: freebsd-net@freebsd.org Cc: freebsd-alpha@freebsd.org Subject: PPPoE + Alpha + 32/64 bits Hello, I recently connected my FreeBSD/Alpha (4.3-RELEASE) to an ADSL link using an Alcatel Speed Touch Home modem. As is, it was not working; after some digging, I found that there is a bug either in the ng_pppoe support, or in the modem. The problem is in the pppoe_finduniq() function. In order to identify sessions, the PPPoE code sends a tag with the first packet it sends to the modem; this tag is in fact a 64-bit pointer to some data structure in kernel space. When a packet of type PADO_CODE or PADS_CODE is received, the tag is compared with known pointers. However, only 32 bits are present in the return tag. So, if the original pointer is 0xfffffc00003b3d00, the tag contains only 0x003b3d00, which are the first four bytes of data (in little-endian representation). If I modify the pppoe_finduniq() function to accept matches on these four bytes, the connection is established, and remains fully functionnal afterwards. Some details: The Alpha is little-endian, but the data in the packets is big-endian. If the original pointer is 0xfffffc00003b3d00, the rebuilt tag from the response packet is actually 0x003b3d0000000000. I do not know if the 8-bytes tag is sent correctly, or if the modem is buggy, or whatever. Machine configuration: AXPpci33 at 166 MHz, 32 MB ram ethernet PCI adapter RealTek 8029 10baseT (ed0) modem Alcatel Speed Touch Home (ethernet) FreeBSD 4.3-RELEASE (with a small patch to enable ed0) Feel free to ask for any detail. --Thomas Pornin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 1 11: 8: 3 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 0457337B403; Wed, 1 Aug 2001 11:07:54 -0700 (PDT) (envelope-from julian@elischer.org) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA40999; Wed, 1 Aug 2001 13:01:13 -0700 (PDT) Date: Wed, 1 Aug 2001 13:01:12 -0700 (PDT) From: Julian Elischer To: Thomas Pornin Cc: freebsd-net@freebsd.org, freebsd-alpha@freebsd.org Subject: Re: PPPoE + Alpha + 32/64 bits In-Reply-To: <20010801173624.A13674@bolet.ens.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org can you send us a patch that works for you? we can make it #ifdef __Alpha__ or something. can you ocnfirm that the outgoing packet has a tag-lenth of '8' and that teh return tag has a length of '4'? (maybe 9 and 5) sounds like a brain-dead router at the other end.. On Wed, 1 Aug 2001, Thomas Pornin wrote: > Hello, > > I recently connected my FreeBSD/Alpha (4.3-RELEASE) to an ADSL link > using an Alcatel Speed Touch Home modem. As is, it was not working; > after some digging, I found that there is a bug either in the ng_pppoe > support, or in the modem. > > The problem is in the pppoe_finduniq() function. In order to identify > sessions, the PPPoE code sends a tag with the first packet it sends to > the modem; this tag is in fact a 64-bit pointer to some data structure > in kernel space. When a packet of type PADO_CODE or PADS_CODE is > received, the tag is compared with known pointers. > > However, only 32 bits are present in the return tag. So, if the original > pointer is 0xfffffc00003b3d00, the tag contains only 0x003b3d00, which > are the first four bytes of data (in little-endian representation). If > I modify the pppoe_finduniq() function to accept matches on these four > bytes, the connection is established, and remains fully functionnal > afterwards. > > Some details: The Alpha is little-endian, but the data in the packets is > big-endian. If the original pointer is 0xfffffc00003b3d00, the rebuilt > tag from the response packet is actually 0x003b3d0000000000. I do not > know if the 8-bytes tag is sent correctly, or if the modem is buggy, or > whatever. > > Machine configuration: > AXPpci33 at 166 MHz, 32 MB ram > ethernet PCI adapter RealTek 8029 10baseT (ed0) > modem Alcatel Speed Touch Home (ethernet) > FreeBSD 4.3-RELEASE (with a small patch to enable ed0) > > Feel free to ask for any detail. > > > --Thomas Pornin > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 1 11: 8:11 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 5848F37B401; Wed, 1 Aug 2001 11:07:59 -0700 (PDT) (envelope-from julian@elischer.org) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA41031; Wed, 1 Aug 2001 13:07:20 -0700 (PDT) Date: Wed, 1 Aug 2001 13:07:20 -0700 (PDT) From: Julian Elischer To: Peter Blok Cc: "'Thomas Pornin'" , freebsd-net@freebsd.org, freebsd-alpha@freebsd.org Subject: RE: PPPoE + Alpha + 32/64 bits In-Reply-To: <000001c11ab1$b5b92d70$8a02a8c0@ntpc> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I think he was using ppp, not mpd. he's doing adsl/pppoe and not pptp. On Wed, 1 Aug 2001, Peter Blok wrote: > What did you patch in the mpd daemon. I found a lot endian issues with it, > but due to work pressure I didn't finish it. > > -----Original Message----- > From: owner-freebsd-alpha@FreeBSD.ORG > [mailto:owner-freebsd-alpha@FreeBSD.ORG]On Behalf Of Thomas Pornin > Sent: Wednesday, August 01, 2001 17:36 > To: freebsd-net@freebsd.org > Cc: freebsd-alpha@freebsd.org > Subject: PPPoE + Alpha + 32/64 bits > > > Hello, > > I recently connected my FreeBSD/Alpha (4.3-RELEASE) to an ADSL link > using an Alcatel Speed Touch Home modem. As is, it was not working; > after some digging, I found that there is a bug either in the ng_pppoe > support, or in the modem. > > The problem is in the pppoe_finduniq() function. In order to identify > sessions, the PPPoE code sends a tag with the first packet it sends to > the modem; this tag is in fact a 64-bit pointer to some data structure > in kernel space. When a packet of type PADO_CODE or PADS_CODE is > received, the tag is compared with known pointers. > > However, only 32 bits are present in the return tag. So, if the original > pointer is 0xfffffc00003b3d00, the tag contains only 0x003b3d00, which > are the first four bytes of data (in little-endian representation). If > I modify the pppoe_finduniq() function to accept matches on these four > bytes, the connection is established, and remains fully functionnal > afterwards. > > Some details: The Alpha is little-endian, but the data in the packets is > big-endian. If the original pointer is 0xfffffc00003b3d00, the rebuilt > tag from the response packet is actually 0x003b3d0000000000. I do not > know if the 8-bytes tag is sent correctly, or if the modem is buggy, or > whatever. > > Machine configuration: > AXPpci33 at 166 MHz, 32 MB ram > ethernet PCI adapter RealTek 8029 10baseT (ed0) > modem Alcatel Speed Touch Home (ethernet) > FreeBSD 4.3-RELEASE (with a small patch to enable ed0) > > Feel free to ask for any detail. > > > --Thomas Pornin > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-alpha" in the body of the message > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 1 11:10:20 2001 Delivered-To: freebsd-net@freebsd.org Received: from ra.eng.mindspring.net (ra.eng.mindspring.net [207.69.192.184]) by hub.freebsd.org (Postfix) with SMTP id 352F037B405 for ; Wed, 1 Aug 2001 11:10:17 -0700 (PDT) (envelope-from sj@ra.eng.mindspring.net) Received: (qmail 5425 invoked by uid 52477); 1 Aug 2001 18:09:37 -0000 To: Thomas Pornin Cc: freebsd-net@freebsd.org, freebsd-alpha@freebsd.org Subject: Re: PPPoE + Alpha + 32/64 bits References: <20010801173624.A13674@bolet.ens.fr> From: Sudish Joseph Date: 01 Aug 2001 14:09:36 -0400 In-Reply-To: <20010801173624.A13674@bolet.ens.fr> (Thomas Pornin's message of "Wed, 1 Aug 2001 17:36:25 +0200") Message-ID: Lines: 26 User-Agent: Gnus/5.090003 (Oort Gnus v0.03) XEmacs/21.2 (Hera) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Thomas Pornin writes: > The problem is in the pppoe_finduniq() function. In order to identify > sessions, the PPPoE code sends a tag with the first packet it sends to > the modem; this tag is in fact a 64-bit pointer to some data structure > in kernel space. When a packet of type PADO_CODE or PADS_CODE is > received, the tag is compared with known pointers. > However, only 32 bits are present in the return tag. So, if the original > pointer is 0xfffffc00003b3d00, the tag contains only 0x003b3d00, which > are the first four bytes of data (in little-endian representation). If > I modify the pppoe_finduniq() function to accept matches on these four > bytes, the connection is established, and remains fully functionnal > afterwards. Yes, exactly. I ran into the same issue. See PR kern/27767 (http://www.freebsd.org/cgi/query-pr.cgi?pr=27767) for the bug report. The PR also contains the (gross, alpha-specific) hack I use right now to work around this issue. It simply masks out the upper 32 bits in the pointer when making the comparison. Obviously not a real solution, however it suffices for now since all of the pointers being compared are in the same 32-bit segment. -- Sudish Joseph To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 1 11:14: 7 2001 Delivered-To: freebsd-net@freebsd.org Received: from ra.eng.mindspring.net (ra.eng.mindspring.net [207.69.192.184]) by hub.freebsd.org (Postfix) with SMTP id 009DE37B405 for ; Wed, 1 Aug 2001 11:14:00 -0700 (PDT) (envelope-from sj@ra.eng.mindspring.net) Received: (qmail 5449 invoked by uid 52477); 1 Aug 2001 18:13:25 -0000 To: Julian Elischer Cc: Thomas Pornin , freebsd-net@freebsd.org, freebsd-alpha@freebsd.org Subject: Re: PPPoE + Alpha + 32/64 bits References: <20010801173624.A13674@bolet.ens.fr> From: Sudish Joseph Date: 01 Aug 2001 14:13:25 -0400 In-Reply-To: (Julian Elischer's message of "Wed, 1 Aug 2001 13:01:12 -0700 (PDT)") Message-ID: Lines: 20 User-Agent: Gnus/5.090003 (Oort Gnus v0.03) XEmacs/21.2 (Hera) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Julian Elischer writes: > can you send us a patch that works for you? > we can make it #ifdef __Alpha__ or something. From PR kern/27767: --- /sys/netgraph/ng_pppoe.c Sat Nov 4 08:23:16 2000 +++ /sys/netgraph/ng_pppoe.c Wed Apr 4 22:59:52 2001 @@ -441,7 +441,7 @@ if ((hook->private == &privp->debug_hook) || (hook->private == &privp->ethernet_hook)) continue; - if (uniq.pointer == hook->private) + if (uniq.pointer == (void *)(((long) hook->private) << 32)) break; } return (hook); -- Sudish Joseph To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 1 11:21:22 2001 Delivered-To: freebsd-net@freebsd.org Received: from ra.eng.mindspring.net (ra.eng.mindspring.net [207.69.192.184]) by hub.freebsd.org (Postfix) with SMTP id 565BE37B405 for ; Wed, 1 Aug 2001 11:21:16 -0700 (PDT) (envelope-from sj@ra.eng.mindspring.net) Received: (qmail 5496 invoked by uid 52477); 1 Aug 2001 18:20:39 -0000 To: Thomas Pornin Cc: freebsd-net@freebsd.org, freebsd-alpha@freebsd.org Subject: Re: PPPoE + Alpha + 32/64 bits References: <20010801173624.A13674@bolet.ens.fr> From: Sudish Joseph Date: 01 Aug 2001 14:20:39 -0400 In-Reply-To: (Sudish Joseph's message of "01 Aug 2001 14:09:36 -0400") Message-ID: Lines: 16 User-Agent: Gnus/5.090003 (Oort Gnus v0.03) XEmacs/21.2 (Hera) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Sudish Joseph writes: > The PR also contains the (gross, alpha-specific) hack I use right now > to work around this issue. It simply masks out the upper 32 bits in > the pointer when making the comparison. Obviously not a real > solution, however it suffices for now since all of the pointers being > compared are in the same 32-bit segment. BTW, if you put in the workaround from kern/27767 for this, you'll run into the problem detailed in PR alpha/27766, where pppd core dumps on certain dns lookups. The patch in that PR was committed and MFC'ed to 4.3-STABLE, but after 4.3 was released, iirc. You might need to cvsup and rebuild world. -- Sudish Joseph To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 1 14:38:38 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail3.mx.voyager.net (mail3.mx.voyager.net [216.93.66.202]) by hub.freebsd.org (Postfix) with ESMTP id 7EA0637B401 for ; Wed, 1 Aug 2001 14:38:35 -0700 (PDT) (envelope-from mhagerty@voyager.net) Received: from thunderbird.voyager.net (216-93-124-123.mdmmi.voyager.net [216.93.124.123]) by mail3.mx.voyager.net (8.10.2/8.10.2) with ESMTP id f71LcY085661 for ; Wed, 1 Aug 2001 17:38:34 -0400 (EDT) Message-Id: <5.0.2.1.2.20010801172921.0185f050@pop.voyager.net> X-Sender: mhagerty@pop.voyager.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 01 Aug 2001 17:40:07 -0400 To: freebsd-net@FreeBSD.ORG From: Matthew Hagerty Subject: DHCP configure as an alias? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Greetings, Is it possible to configure an interface with DHCP as an alias? What I have is a NATd server attached to my cable modem and 1 assigned static IP address configured to the external interface. I am allowed 5 other IP addresses, however they are not static, so how can I configure my NATd box to grab the other addresses with DHCP and forward them to internal IP addresses? Thanks, Matthew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 1 15:43:58 2001 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (gw.Awfulhak.org [217.204.245.18]) by hub.freebsd.org (Postfix) with ESMTP id 77C8337B401; Wed, 1 Aug 2001 15:43:48 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.4/8.11.4) with ESMTP id f71Mhjs05940; Wed, 1 Aug 2001 23:43:46 +0100 (BST) (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.4/8.11.4) with ESMTP id f71Mhi809898; Wed, 1 Aug 2001 23:43:44 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200108012243.f71Mhi809898@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Julian Elischer Cc: Thomas Pornin , freebsd-net@FreeBSD.ORG, freebsd-alpha@FreeBSD.ORG, Brian Somers , FreeBSD-gnats-submit@FreeBSD.ORG Subject: kern/27767: (was: PPPoE + Alpha + 32/64 bits) In-Reply-To: Message from Julian Elischer of "Wed, 01 Aug 2001 13:01:12 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 01 Aug 2001 23:43:44 +0100 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I think the attached will fix it properly -- but I haven't got an alpha to test with, so can someone do the honours for me ? Ta. > can you send us a patch that works for you? > we can make it #ifdef __Alpha__ or something. > > can you ocnfirm that the outgoing packet has a tag-lenth of '8' > and that teh return tag has a length of '4'? > (maybe 9 and 5) > > sounds like a brain-dead router at the other end.. > > > On Wed, 1 Aug 2001, Thomas Pornin wrote: > > > Hello, > > > > I recently connected my FreeBSD/Alpha (4.3-RELEASE) to an ADSL link > > using an Alcatel Speed Touch Home modem. As is, it was not working; > > after some digging, I found that there is a bug either in the ng_pppoe > > support, or in the modem. > > > > The problem is in the pppoe_finduniq() function. In order to identify > > sessions, the PPPoE code sends a tag with the first packet it sends to > > the modem; this tag is in fact a 64-bit pointer to some data structure > > in kernel space. When a packet of type PADO_CODE or PADS_CODE is > > received, the tag is compared with known pointers. > > > > However, only 32 bits are present in the return tag. So, if the original > > pointer is 0xfffffc00003b3d00, the tag contains only 0x003b3d00, which > > are the first four bytes of data (in little-endian representation). If > > I modify the pppoe_finduniq() function to accept matches on these four > > bytes, the connection is established, and remains fully functionnal > > afterwards. > > > > Some details: The Alpha is little-endian, but the data in the packets is > > big-endian. If the original pointer is 0xfffffc00003b3d00, the rebuilt > > tag from the response packet is actually 0x003b3d0000000000. I do not > > know if the 8-bytes tag is sent correctly, or if the modem is buggy, or > > whatever. > > > > Machine configuration: > > AXPpci33 at 166 MHz, 32 MB ram > > ethernet PCI adapter RealTek 8029 10baseT (ed0) > > modem Alcatel Speed Touch Home (ethernet) > > FreeBSD 4.3-RELEASE (with a small patch to enable ed0) > > > > Feel free to ask for any detail. > > > > > > --Thomas Pornin -- Brian http://www.freebsd-services.com/ Don't _EVER_ lose your sense of humour ! Index: ng_pppoe.c =================================================================== RCS file: /home/ncvs/src/sys/netgraph/ng_pppoe.c,v retrieving revision 1.45 diff -u -r1.45 ng_pppoe.c --- ng_pppoe.c 2001/07/25 03:34:07 1.45 +++ ng_pppoe.c 2001/08/01 22:40:15 @@ -868,7 +868,7 @@ struct { struct pppoe_tag hdr; union uniq data; - } uniqtag; + } __attribute ((packed)) uniqtag; /* * kick the state machine into starting up @@ -910,7 +910,7 @@ struct { struct pppoe_tag hdr; union uniq data; - } uniqtag; + } __attribute ((packed)) uniqtag; negp neg = NULL; struct mbuf *m; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 1 16: 8: 8 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 0192837B401; Wed, 1 Aug 2001 16:07:57 -0700 (PDT) (envelope-from julian@elischer.org) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id SAA42348; Wed, 1 Aug 2001 18:11:13 -0700 (PDT) Date: Wed, 1 Aug 2001 18:11:11 -0700 (PDT) From: Julian Elischer To: Brian Somers Cc: Thomas Pornin , freebsd-net@FreeBSD.ORG, freebsd-alpha@FreeBSD.ORG, Brian Somers , FreeBSD-gnats-submit@FreeBSD.ORG Subject: Re: kern/27767: (was: PPPoE + Alpha + 32/64 bits) In-Reply-To: <200108012243.f71Mhi809898@hak.lan.Awfulhak.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org DUH! (slaps forhead with palm "obvious when shown") can you try this thomas? On Wed, 1 Aug 2001, Brian Somers wrote: > Hi, > > I think the attached will fix it properly -- but I haven't got an > alpha to test with, so can someone do the honours for me ? > > Ta. > > > can you send us a patch that works for you? > > we can make it #ifdef __Alpha__ or something. > > > > can you ocnfirm that the outgoing packet has a tag-lenth of '8' > > and that teh return tag has a length of '4'? > > (maybe 9 and 5) > > > > sounds like a brain-dead router at the other end.. > > > > > > On Wed, 1 Aug 2001, Thomas Pornin wrote: > > > > > Hello, > > > > > > I recently connected my FreeBSD/Alpha (4.3-RELEASE) to an ADSL link > > > using an Alcatel Speed Touch Home modem. As is, it was not working; > > > after some digging, I found that there is a bug either in the ng_pppoe > > > support, or in the modem. > > > > > > The problem is in the pppoe_finduniq() function. In order to identify > > > sessions, the PPPoE code sends a tag with the first packet it sends to > > > the modem; this tag is in fact a 64-bit pointer to some data structure > > > in kernel space. When a packet of type PADO_CODE or PADS_CODE is > > > received, the tag is compared with known pointers. > > > > > > However, only 32 bits are present in the return tag. So, if the original > > > pointer is 0xfffffc00003b3d00, the tag contains only 0x003b3d00, which > > > are the first four bytes of data (in little-endian representation). If > > > I modify the pppoe_finduniq() function to accept matches on these four > > > bytes, the connection is established, and remains fully functionnal > > > afterwards. > > > > > > Some details: The Alpha is little-endian, but the data in the packets is > > > big-endian. If the original pointer is 0xfffffc00003b3d00, the rebuilt > > > tag from the response packet is actually 0x003b3d0000000000. I do not > > > know if the 8-bytes tag is sent correctly, or if the modem is buggy, or > > > whatever. > > > > > > Machine configuration: > > > AXPpci33 at 166 MHz, 32 MB ram > > > ethernet PCI adapter RealTek 8029 10baseT (ed0) > > > modem Alcatel Speed Touch Home (ethernet) > > > FreeBSD 4.3-RELEASE (with a small patch to enable ed0) > > > > > > Feel free to ask for any detail. > > > > > > > > > --Thomas Pornin > > -- > Brian > http://www.freebsd-services.com/ > Don't _EVER_ lose your sense of humour ! > > Index: ng_pppoe.c > =================================================================== > RCS file: /home/ncvs/src/sys/netgraph/ng_pppoe.c,v > retrieving revision 1.45 > diff -u -r1.45 ng_pppoe.c > --- ng_pppoe.c 2001/07/25 03:34:07 1.45 > +++ ng_pppoe.c 2001/08/01 22:40:15 > @@ -868,7 +868,7 @@ > struct { > struct pppoe_tag hdr; > union uniq data; > - } uniqtag; > + } __attribute ((packed)) uniqtag; > > /* > * kick the state machine into starting up > @@ -910,7 +910,7 @@ > struct { > struct pppoe_tag hdr; > union uniq data; > - } uniqtag; > + } __attribute ((packed)) uniqtag; > negp neg = NULL; > struct mbuf *m; > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 1 20:37:48 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.internet2.edu (list.internet2.edu [209.211.239.181]) by hub.freebsd.org (Postfix) with ESMTP id 60E8337B403; Wed, 1 Aug 2001 20:37:43 -0700 (PDT) (envelope-from shalunov@internet2.edu) Received: from cain.internet2.edu (localhost [127.0.0.1]) by mail.internet2.edu (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f723bfh05900; Wed, 1 Aug 2001 23:37:41 -0400 X-Authentication-Warning: mail.internet2.edu: Host localhost [127.0.0.1] claimed to be cain.internet2.edu Received: by cain.internet2.edu (Postfix, from userid 1000) id BD5328E8; Wed, 1 Aug 2001 23:32:29 -0400 (EDT) To: Bill Paul , Ken Merry Cc: freebsd-net@FreeBSD.org Subject: TCP problems with large window sizes on FreeBSD (GigaTCP) From: stanislav shalunov Date: 01 Aug 2001 23:32:29 -0400 Message-ID: <87bslzt9v6.fsf@cain.internet2.edu> Lines: 43 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org We want to build two or more machines that would be capable of achieving TCP throughputs of 700-800Mb/s over WAN (with a single TCP connection). The motivations of this exercise are spelled out on the referred web page. Additionally, I believe that getting through with this exercise with FreeBSD as the OS would advance FreeBSD's cause with network researchers and advanced users of high-performance networks. In order to run at such high throughput over links with RTT of roughly 70ms we'd need window sizes in the vicinity of 8-16MB. (And, naturally, the unidirectional loss event probability has to be less than (.7*MSS/(RTT*bandwidth))^2 = 1e-7. We believe that we have networks that lose less than one packet in ten million.) We have built the boxes now. I have started with back-to-back testing with large window sizes. Back-to-back testing is believed to be valid because it's hard to expect that inserting 70ms delay between the host will make the situation any better. I cannot get it to run with window sizes greater than half a megabyte. The story, with some very preliminary analysis, is at http://www.internet2.edu/~shalunov/gigatcp/ I'm not reposting it here; there are 29KB of text and 3MB of data there. I'm adding and updating stuff as I progress. The questions that I have for you guys are, in decreasing order of importance: 1. How do I fix the ti driver problem that apparently is holding me back? What number of jumbo slots would be "good"? 2. Why doesn't Fast Retransmit kick in? (See the annotated sender's view of the stalled connection.) 3. Is there an off-by-one error in RST handling? (See the end of the annotated receiver's view of the stalled connection.) -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ "Nuclear war would really set back cable [television]." -- Ted Turner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 1 22: 3:55 2001 Delivered-To: freebsd-net@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id AC62537B40E for ; Wed, 1 Aug 2001 22:03:38 -0700 (PDT) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id f7253jY08157; Thu, 2 Aug 2001 00:03:45 -0500 (CDT) (envelope-from jlemon) Date: Thu, 2 Aug 2001 00:03:45 -0500 (CDT) From: Jonathan Lemon Message-Id: <200108020503.f7253jY08157@prism.flugsvamp.com> To: shalunov@internet2.edu, net@freebsd.org Subject: Re: TCP problems with large window sizes on FreeBSD (GigaTCP) X-Newsgroups: local.mail.freebsd-net In-Reply-To: Organization: Cc: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In article you write: > >I cannot get it to run with window sizes greater than half a megabyte. > >The story, with some very preliminary analysis, is at >http://www.internet2.edu/~shalunov/gigatcp/ Very nice analysis! >1. How do I fix the ti driver problem that apparently is holding me > back? What number of jumbo slots would be "good"? I think problem 2 is a larger issue here. However, you should be able to bump up the number of jumbo buffers allocated simply by tweaking TI_JSLOTS to a larger value; the number of actual hardware descriptors used is specified elsewhere (TI_JUMBO_RX_RING_CNT == 256). > >2. Why doesn't Fast Retransmit kick in? (See the annotated sender's > view of the stalled connection.) Because the acks aren't completely duplicate acks, the window size changed. Fast Retransmit doesn't kick in unless a completely duplicate ack is received. The packets are stored in the reassembly queue, and don't count against the advertised receive window. However, since the receiver is slowly draining the buffer, it keeps opening the window and no dupacks are actually transmitted. >3. Is there an off-by-one error in RST handling? (See the end of the > annotated receiver's view of the stalled connection.) Looks like it. The code currently reads: if (SEQ_GEQ(th->th_seq, tp->last_ack_sent) && SEQ_LT(th->th_seq, tp->last_ack_sent + tp->rcv_wnd)) { And this probably should be "SEQ_GEQ(..) && SEQ_LEQ(...)". -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 1 23: 8:59 2001 Delivered-To: freebsd-net@freebsd.org Received: from technokratis.com (modemcable052.174-202-24.mtl.mc.videotron.ca [24.202.174.52]) by hub.freebsd.org (Postfix) with ESMTP id C72ED37B405; Wed, 1 Aug 2001 23:08:54 -0700 (PDT) (envelope-from bmilekic@technokratis.com) Received: (from bmilekic@localhost) by technokratis.com (8.11.4/8.11.3) id f726Ack04317; Thu, 2 Aug 2001 02:10:38 -0400 (EDT) (envelope-from bmilekic) Date: Thu, 2 Aug 2001 02:10:38 -0400 From: Bosko Milekic To: stanislav shalunov Cc: Bill Paul , Ken Merry , freebsd-net@FreeBSD.ORG Subject: Re: TCP problems with large window sizes on FreeBSD (GigaTCP) Message-ID: <20010802021038.A4181@technokratis.com> References: <87bslzt9v6.fsf@cain.internet2.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <87bslzt9v6.fsf@cain.internet2.edu>; from shalunov@internet2.edu on Wed, Aug 01, 2001 at 11:32:29PM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi Stanislav, On Wed, Aug 01, 2001 at 11:32:29PM -0400, stanislav shalunov wrote: > We want to build two or more machines that would be capable of > achieving TCP throughputs of 700-800Mb/s over WAN (with a single TCP > connection). The motivations of this exercise are spelled out on the > referred web page. Additionally, I believe that getting through with > this exercise with FreeBSD as the OS would advance FreeBSD's cause > with network researchers and advanced users of high-performance > networks. > > In order to run at such high throughput over links with RTT of roughly > 70ms we'd need window sizes in the vicinity of 8-16MB. (And, > naturally, the unidirectional loss event probability has to be less > than (.7*MSS/(RTT*bandwidth))^2 = 1e-7. We believe that we have > networks that lose less than one packet in ten million.) > > We have built the boxes now. I have started with back-to-back testing > with large window sizes. Back-to-back testing is believed to be valid > because it's hard to expect that inserting 70ms delay between the host > will make the situation any better. > > I cannot get it to run with window sizes greater than half a megabyte. > > The story, with some very preliminary analysis, is at > http://www.internet2.edu/~shalunov/gigatcp/ > > I'm not reposting it here; there are 29KB of text and 3MB of data > there. I'm adding and updating stuff as I progress. > > The questions that I have for you guys are, in decreasing order of > importance: > > 1. How do I fix the ti driver problem that apparently is holding me > back? What number of jumbo slots would be "good"? I would recommend, seeing as how you're targeting specifically TCP throughput and are not too concerned with lack of physical memory, to increase TI_JSLOTS to at least 500-600. This would have the effect of reserving roughly 5M of physically contiguous memory during driver attachment, which I think you can safely spare. If you discover that you need even more than 500-600 jumbo buffers, feel free to experiment with the TI_JSLOTS constant. For what concerns memory buffer tuning, I would also recommend, to be on the safe side, the following changes: - in uipc_mbuf.c, increase NCL_INIT to roughly 20. Seeing as how you're using if_ti which allocates its own buffer space, I don't suspect that you'll be needing many regular clusters. Check with `netstat -m' to see how many are typically in use during a test and increase NCL_INIT to that number. All this will do is pre-allocate the pool at boot time and avoid potentially expensive map allocations while your tests are running. - also in uipc_mbuf.c, increase NMB_INIT to 10240, or any sensible value you have detected is required (again, see with `netstat -m' during testing, try to determine the maximum number of mbufs you'll need). All this will do is, again, allocate them at boot time and speed up memory buffer allocations during performance testing. If you set the number to 10240, remember that each mbuf is merely 256 bytes, so you'll be giving up a mere ~2.7M for the cause, and speeding up allocations altogether. Finally, I noticed at one point in your analysis that you increased NMBCLUSTERS. You'll find that, unless you're actually running out of mbufs and/or clusters, that increasing N{MB,CL}_INIT is probably what you want to do instead. > 2. Why doesn't Fast Retransmit kick in? (See the annotated sender's > view of the stalled connection.) > > 3. Is there an off-by-one error in RST handling? (See the end of the > annotated receiver's view of the stalled connection.) I believe jlemon covered these two issues in his post, which very much makes sense as he's the overall stack guru. :-) > -- > Stanislav Shalunov http://www.internet2.edu/~shalunov/ > > "Nuclear war would really set back cable [television]." -- Ted Turner -- Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 2 0:23:31 2001 Delivered-To: freebsd-net@freebsd.org Received: from bugz.infotecs.ru (bugz.infotecs.ru [195.210.139.22]) by hub.freebsd.org (Postfix) with ESMTP id B93C437B401; Thu, 2 Aug 2001 00:23:23 -0700 (PDT) (envelope-from vel@bugz.infotecs.ru) Received: (from root@localhost) by bugz.infotecs.ru (8.11.1/8.11.1) id f727dbY02620; Thu, 2 Aug 2001 11:39:37 +0400 (MSD) (envelope-from vel) From: "Eugene L. Vorokov" Message-Id: <200108020739.f727dbY02620@bugz.infotecs.ru> Subject: ipfw "established" option To: freebsd-net@freebsd.org Date: Thu, 2 Aug 2001 11:39:37 +0400 (MSD) Cc: freebsd-hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello, I've found some strange issue regarding ipfw. I have freebsd 4.2-RELEASE. Guess I have rules: 1 allow tcp from any to 195.210.139.22 established 2 deny tcp from any to 195.210.139.22 2 allow all from any to any The intention is to allow the machine itself connect outside and accept responces once connection is established, but deny attepmts to connect to this machine from outside. I was thinking that first packet which tries to establish TCP connection should never match rule 1. However, I've found that it depends on which operating system tries to connect in ! When I try this from machine with freebsd 4.3-RELEASE, it gets dropped as expected. tcpdump on my machine says: 11:15:01.841594 195.222.16.243.1117 > 195.210.139.22.21: S 3910802910:3910802910(0) win 16384 (DF) [tos 0x10] 11:15:04.911908 195.222.16.243.1117 > 195.210.139.22.21: S 3910802910:3910802910(0) win 16384 (DF) [tos 0x10] 11:15:07.804934 195.222.16.243.1117 > 195.210.139.22.21: S 3910802910:3910802910(0) win 16384 (DF) [tos 0x10] Okay, that's fine. But then I try the same from Linux machine (2.4.5). I am able to successfully telnet in ! tcpdump says: 11:15:51.479203 195.230.76.28.39925 > 195.210.139.22.21: S [ECN-Echo,CWR] 4162184178:4162184178(0) win 5840 (DF) [tos 0x10] 11:15:51.479466 195.210.139.22.21 > 195.230.76.28.39925: S 2404031587:2404031587(0) ack 4162184179 win 17520 (DF) 11:15:51.565124 195.230.76.28.39925 > 195.210.139.22.21: . ack 1 win 5840 (DF) [tos 0x10] 11:15:51.590818 195.210.139.22.21 > 195.230.76.28.39925: P 1:58(57) ack 1 win 17520 (DF) [tos 0x10] 11:15:51.648107 195.230.76.28.39925 > 195.210.139.22.21: . ack 58 win 5840 (DF) [tos 0x10] Firewall logs also say that the initial packet matched the rule 1 and was passed. Why is it like that ? Am I missing something ? Regards, Eugene To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 2 0:31: 0 2001 Delivered-To: freebsd-net@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 0C11537B401; Thu, 2 Aug 2001 00:30:57 -0700 (PDT) (envelope-from billf@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1098) id CF3D181D06; Thu, 2 Aug 2001 02:30:46 -0500 (CDT) Date: Thu, 2 Aug 2001 02:30:46 -0500 From: Bill Fumerola To: "Eugene L. Vorokov" Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: ipfw "established" option Message-ID: <20010802023046.X2759@elvis.mu.org> References: <200108020739.f727dbY02620@bugz.infotecs.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200108020739.f727dbY02620@bugz.infotecs.ru>; from vel@bugz.infotecs.ru on Thu, Aug 02, 2001 at 11:39:37AM +0400 X-Operating-System: FreeBSD 4.3-FEARSOME-20010712 i386 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, Aug 02, 2001 at 11:39:37AM +0400, Eugene L. Vorokov wrote: > Hello, > > I've found some strange issue regarding ipfw. I have freebsd 4.2-RELEASE. this was fixed in more recent versions of freebsd. -- Bill Fumerola - security yahoo / Yahoo! inc. - fumerola@yahoo-inc.com / billf@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 2 2:17:11 2001 Delivered-To: freebsd-net@freebsd.org Received: from nef.ens.fr (nef.ens.fr [129.199.96.32]) by hub.freebsd.org (Postfix) with ESMTP id 8A4A437B401; Thu, 2 Aug 2001 02:17:07 -0700 (PDT) (envelope-from Thomas.Pornin@ens.fr) Received: from bolet.ens.fr (bolet.ens.fr [129.199.99.10]) by nef.ens.fr (8.10.1/1.01.28121999) with ESMTP id f729H6m38776 ; Thu, 2 Aug 2001 11:17:06 +0200 (CEST) Received: from (pornin@localhost) by bolet.ens.fr (8.11.3/jb-1.1) Date: Thu, 2 Aug 2001 11:17:03 +0200 From: Thomas Pornin To: Julian Elischer Cc: Brian Somers , freebsd-net@freebsd.org, freebsd-alpha@freebsd.org, FreeBSD-gnats-submit@freebsd.org Subject: Re: kern/27767: (was: PPPoE + Alpha + 32/64 bits) Message-ID: <20010802111703.A38800@bolet.ens.fr> References: <200108012243.f71Mhi809898@hak.lan.Awfulhak.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from julian@elischer.org on Wed, Aug 01, 2001 at 06:11:11PM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, Aug 01, 2001 at 06:11:11PM -0700, Julian Elischer wrote: > can you try this thomas? I tried. It works like a charm. Thanks ! --Thomas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 2 3:31: 8 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.im.tku.edu.tw (unknown [163.13.200.193]) by hub.freebsd.org (Postfix) with ESMTP id 5A58837B401 for ; Thu, 2 Aug 2001 03:31:04 -0700 (PDT) (envelope-from maverick@mail.im.tku.edu.tw) Received: (from maverick@localhost) by mail.im.tku.edu.tw (8.9.3/8.9.3) id AAA13306; Tue, 24 Jul 2001 00:02:15 +0800 Date: Tue, 24 Jul 2001 00:02:15 +0800 (CST) From: Maverick To: freebsd-net@freebsd.org Subject: frequentl lost default route Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org dear all i have 2 freebsd-20010710-stable box "A" & "B", all same hardware compaq-1600 + 3c905c-TX connect to switch, switch connect to router so the seting is easy all defaultroute is the router. it works great. But suddenly box "A" frequentl lost default route it happen less in 2 minute, and to keep on recurring.. i don't know how to solve this problem,so i write a script to write default route again and again temporary solve this problem. box "B" doesn't have this problem it works greate.. when i use tcodump on box "A" to monitor arp tcpdump -e -p arp i found a strange problem , box "A" doesn't know it self. 09:53:06.482174 Box_A_MAC Broadcast arp 60: arp who-has BOX_A_IP tell BOX_A_IP thanks for your help .. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 2 4:24:35 2001 Delivered-To: freebsd-net@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id 9C57037B401 for ; Thu, 2 Aug 2001 04:24:33 -0700 (PDT) (envelope-from itojun@itojun.org) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 89AB94B21; Thu, 2 Aug 2001 20:24:26 +0900 (JST) To: tech-net@netbsd.org Cc: net@freebsd.org In-reply-to: mouse's message of Thu, 02 Aug 2001 02:24:51 -0400. <200108020624.CAA16288@Twig.Rodents.Montreal.QC.CA> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: getaddrinfo() and PF_LOCAL From: itojun@iijlab.net Date: Thu, 02 Aug 2001 20:24:26 +0900 Message-ID: <14756.996751466@itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org (this is about PF_LOCAL support for getaddrinfo/getnameinfo) we had a local discussion within KAME. we do not really like to support PF_LOCAL, unless there's clear standard behavior for AF_LOCAL case. for AF independent programming point of view, unlink(2) call issue is really bitching us. also, we cannot just add incompatible functionality from others (note that glibc now drops it, so we are now compatible with glibc at this point). getaddrinfo/ getnameinfo behavior itself is rather vaguely defined in the standards (POSIX drafts as well as RFC2553/bis), and we don't want to add more jitter to it. so if you want it - get the POSIX guys to document getaddrinfo/ getnameinfo behavior for PF_LOCAL, exactly and explicitly. itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 2 5:37:26 2001 Delivered-To: freebsd-net@freebsd.org Received: from aussie.org (hallam.lnk.telstra.net [139.130.54.166]) by hub.freebsd.org (Postfix) with ESMTP id 9775837B403 for ; Thu, 2 Aug 2001 05:37:22 -0700 (PDT) (envelope-from mlnn4@oaks.com.au) Received: from dualp2 (dualp2 [203.29.75.73]) by aussie.org (8.11.3/8.11.4) with SMTP id f72CbKQ00596 for ; Thu, 2 Aug 2001 22:37:20 +1000 (EST) (envelope-from mlnn4@oaks.com.au) Message-Id: <200108021237.f72CbKQ00596@aussie.org> From: "Chris" To: "freebsd-net@freebsd.org" Date: Thu, 02 Aug 2001 22:36:06 +1000 Reply-To: "Chris" X-Mailer: PMMail 98 Standard (2.01.1600) For Windows NT (5.0.2195;2) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: re: kernel upgrade causes truncated IPSEC packets Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >packet. But the PPP process only sees the first 36 bytes or so of it (for >example, a packet which arrives as 263 bytes becomes 320 bytes after >encapsulation. This is what is shown by both tcpdump and the packet header, >as read from the ppp async stream), but only 36 bytes of it make it through >to the modem (plus the PPP overhead of about 5 bytes). I re-posted this to -stable, and thanks to Bill Fenner it is now fixed. It seems that the IPSEC code for some reason will sometimes insert a zero- length mbuf into the mbuf chain. if_tun.c will cease following the linked list of mbufs if it sees a zero-length one, thus causing the truncated output packets. Dunno how long it's been like that (probably 7 weeks) but it would have affected anyone who used IPSEC over a /dev/tunN device. -- Chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 2 6:36: 6 2001 Delivered-To: freebsd-net@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id 66D7537B401 for ; Thu, 2 Aug 2001 06:36:01 -0700 (PDT) (envelope-from itojun@itojun.org) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 023F74B21; Thu, 2 Aug 2001 22:35:58 +0900 (JST) To: "Chris" Cc: "freebsd-net@freebsd.org" In-reply-to: mlnn4's message of Thu, 02 Aug 2001 22:36:06 +1000. <200108021237.f72CbKQ00596@aussie.org> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: kernel upgrade causes truncated IPSEC packets From: itojun@iijlab.net Date: Thu, 02 Aug 2001 22:35:58 +0900 Message-ID: <16101.996759358@itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >>packet. But the PPP process only sees the first 36 bytes or so of it (for >>example, a packet which arrives as 263 bytes becomes 320 bytes after >>encapsulation. This is what is shown by both tcpdump and the packet header, >>as read from the ppp async stream), but only 36 bytes of it make it through >>to the modem (plus the PPP overhead of about 5 bytes). > >I re-posted this to -stable, and thanks to Bill Fenner it is now fixed. > >It seems that the IPSEC code for some reason will sometimes insert a zero- >length mbuf into the mbuf chain. if_tun.c will cease following the linked >list of mbufs if it sees a zero-length one, thus causing the truncated output >packets. Dunno how long it's been like that (probably 7 weeks) but it would >have affected anyone who used IPSEC over a /dev/tunN device. was the fix committed to sys/net/if_tun.c? i guess other *BSDs have the same issue. itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 2 7:55:28 2001 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id CFD6A37B407 for ; Thu, 2 Aug 2001 07:55:20 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id f72Eson49865; Thu, 2 Aug 2001 10:54:50 -0400 (EDT) (envelope-from wollman) Date: Thu, 2 Aug 2001 10:54:50 -0400 (EDT) From: Garrett Wollman Message-Id: <200108021454.f72Eson49865@khavrinen.lcs.mit.edu> To: itojun@iijlab.net Cc: tech-net@netbsd.org, net@FreeBSD.ORG Subject: Re: getaddrinfo() and PF_LOCAL In-Reply-To: <14756.996751466@itojun.org> References: <200108020624.CAA16288@Twig.Rodents.Montreal.QC.CA> <14756.996751466@itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org < so if you want it - get the POSIX guys to document getaddrinfo/ > getnameinfo behavior for PF_LOCAL, exactly and explicitly. Note that it is far too late in the current POSIX.1 review cycle to make such normative changes, so any redefinition of this interface will require at the very least an interpretation against the new standard (after it comes out late this year), and quite possibly an amendment if the interpretation request comes back unfavorably. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 2 8:15:54 2001 Delivered-To: freebsd-net@freebsd.org Received: from assaris.sics.se (assaris.sics.se [193.10.66.234]) by hub.freebsd.org (Postfix) with ESMTP id A19C437B409 for ; Thu, 2 Aug 2001 08:15:48 -0700 (PDT) (envelope-from assar@assaris.sics.se) Received: (from assar@localhost) by assaris.sics.se (8.9.3/8.9.3) id RAA89940; Thu, 2 Aug 2001 17:15:31 +0200 (CEST) (envelope-from assar) To: itojun@iijlab.net Cc: tech-net@netbsd.org, net@freebsd.org Subject: Re: getaddrinfo() and PF_LOCAL References: <14756.996751466@itojun.org> From: Assar Westerlund Date: 02 Aug 2001 17:15:30 +0200 In-Reply-To: itojun@iijlab.net's message of "Thu, 02 Aug 2001 20:24:26 +0900" Message-ID: <5lk80mebn1.fsf@assaris.sics.se> Lines: 19 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) Emacs/20.6 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org itojun@iijlab.net writes: > we had a local discussion within KAME. we do not really like to > support PF_LOCAL, unless there's clear standard behavior for AF_LOCAL > case. I think this is the wrong approach. If we're always going to wait for a clear and standarized behaviour of something before implementing it, I'm afraid that this is not going to appear and if there is actually a standard for it, then it will have been written without the help of implementation and usage experience. > getaddrinfo/ > getnameinfo behavior itself is rather vaguely defined in the standards > (POSIX drafts as well as RFC2553/bis), and we don't want to add > more jitter to it. agree :-) /assar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 2 8:28:11 2001 Delivered-To: freebsd-net@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id D3F0E37B405 for ; Thu, 2 Aug 2001 08:28:07 -0700 (PDT) (envelope-from itojun@itojun.org) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id AC7FB4B27; Fri, 3 Aug 2001 00:28:04 +0900 (JST) To: tech-net@netbsd.org, net@freebsd.org In-reply-to: assar's message of 02 Aug 2001 17:15:30 +0200. <5lk80mebn1.fsf@assaris.sics.se> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: getaddrinfo() and PF_LOCAL From: itojun@iijlab.net Date: Fri, 03 Aug 2001 00:28:04 +0900 Message-ID: <17251.996766084@itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >> we had a local discussion within KAME. we do not really like to >> support PF_LOCAL, unless there's clear standard behavior for AF_LOCAL >> case. >I think this is the wrong approach. If we're always going to wait for >a clear and standarized behaviour of something before implementing it, >I'm afraid that this is not going to appear and if there is actually a >standard for it, then it will have been written without the help of >implementation and usage experience. we can probably try it out (if it seems really necessary for us) on KAME tree, but not on *BSD-current nor *BSD official releases. itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 2 8:34:38 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.internet2.edu (list.internet2.edu [209.211.239.181]) by hub.freebsd.org (Postfix) with ESMTP id CEA4537B401 for ; Thu, 2 Aug 2001 08:34:34 -0700 (PDT) (envelope-from shalunov@internet2.edu) Received: from cain.internet2.edu (localhost [127.0.0.1]) by mail.internet2.edu (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f72FYWh02102; Thu, 2 Aug 2001 11:34:33 -0400 X-Authentication-Warning: mail.internet2.edu: Host localhost [127.0.0.1] claimed to be cain.internet2.edu Received: by cain.internet2.edu (Postfix, from userid 1000) id DAD9A8E8; Thu, 2 Aug 2001 11:34:31 -0400 (EDT) To: Jonathan Lemon Cc: net@freebsd.org Subject: Re: TCP problems with large window sizes on FreeBSD (GigaTCP) References: <200108020503.f7253jY08157@prism.flugsvamp.com> From: stanislav shalunov Date: 02 Aug 2001 11:34:31 -0400 In-Reply-To: <200108020503.f7253jY08157@prism.flugsvamp.com> Message-ID: <87y9p2qxvc.fsf@cain.internet2.edu> Lines: 47 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Jonathan Lemon writes: > I think problem 2 is a larger issue here. However, you should be able > to bump up the number of jumbo buffers allocated simply by tweaking > TI_JSLOTS to a larger value; the number of actual hardware descriptors > used is specified elsewhere (TI_JUMBO_RX_RING_CNT == 256). I'll try increasing the value of TI_JSLOTS to 8192 (twice the number of 4K packets in 16MB window) and see if it makes a difference. Burning 73MB on driver buffers does seem silly, but it's not like I need that memory for something else. > >2. Why doesn't Fast Retransmit kick in? (See the annotated sender's > > view of the stalled connection.) > > Because the acks aren't completely duplicate acks, the window size changed. It looks like they are fully duplicate ACKs, see, e.g.: 23:54:24.005786 10.0.0.1.5001 > 10.0.0.2.1072: . ack 532481 win 32768 (DF) (ttl 64, id 18469) 23:54:24.005875 10.0.0.2.1072 > 10.0.0.1.5001: . 2621441:2625537(4096) ack 1 win 32768 (DF) (ttl 64, id 32684) 23:54:24.005899 10.0.0.1.5001 > 10.0.0.2.1072: . ack 532481 win 32768 (DF) (ttl 64, id 18470) 23:54:24.006007 10.0.0.2.1072 > 10.0.0.1.5001: P 2625537:2629633(4096) ack 1 win 32768 (DF) (ttl 64, id 32685) 23:54:24.006037 10.0.0.2.1072 > 10.0.0.1.5001: . 532481:536577(4096) ack 1 win 32768 (DF) (ttl 64, id 32686) 23:54:24.006060 10.0.0.1.5001 > 10.0.0.2.1072: . ack 532481 win 32768 (DF) (ttl 64, id 18471) 23:54:24.006178 10.0.0.1.5001 > 10.0.0.2.1072: . ack 532481 win 32768 (DF) (ttl 64, id 18472) Here are four consecutive ACKs for 532481 with window 32768 (2097152 taking into account wscale 6, the full window size) and the same timestamp echo value of 2323870. > >3. Is there an off-by-one error in RST handling? > Looks like it. The code currently reads: > > if (SEQ_GEQ(th->th_seq, tp->last_ack_sent) && > SEQ_LT(th->th_seq, tp->last_ack_sent + tp->rcv_wnd)) { > > And this probably should be "SEQ_GEQ(..) && SEQ_LEQ(...)". While not really important for my particular test, it's probably something that should be fixed in the code then... -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ "Hey! Who took the cork off my lunch?!" -- W. C. Fields To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 2 8:45:54 2001 Delivered-To: freebsd-net@freebsd.org Received: from assaris.sics.se (assaris.sics.se [193.10.66.234]) by hub.freebsd.org (Postfix) with ESMTP id A13C437B401 for ; Thu, 2 Aug 2001 08:45:51 -0700 (PDT) (envelope-from assar@assaris.sics.se) Received: (from assar@localhost) by assaris.sics.se (8.9.3/8.9.3) id RAA90048; Thu, 2 Aug 2001 17:45:42 +0200 (CEST) (envelope-from assar) To: itojun@iijlab.net Cc: tech-net@netbsd.org, net@freebsd.org Subject: Re: getaddrinfo() and PF_LOCAL References: <17251.996766084@itojun.org> From: Assar Westerlund Date: 02 Aug 2001 17:45:41 +0200 In-Reply-To: itojun@iijlab.net's message of "Fri, 03 Aug 2001 00:28:04 +0900" Message-ID: <5lk80m79ei.fsf@assaris.sics.se> Lines: 9 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) Emacs/20.6 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org itojun@iijlab.net writes: > we can probably try it out (if it seems really necessary for us) > on KAME tree, but not on *BSD-current nor *BSD official releases. I believe one of the intended uses of this would be for telnet/rpcbind, so I think it would really have to go into *BSD-current to be used that way. /assar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 2 8:47:16 2001 Delivered-To: freebsd-net@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id F35A337B40E for ; Thu, 2 Aug 2001 08:47:09 -0700 (PDT) (envelope-from itojun@itojun.org) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id E578B4B24; Fri, 3 Aug 2001 00:47:08 +0900 (JST) To: Assar Westerlund Cc: tech-net@netbsd.org, net@freebsd.org In-reply-to: assar's message of 02 Aug 2001 17:45:41 +0200. <5lk80m79ei.fsf@assaris.sics.se> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: getaddrinfo() and PF_LOCAL From: itojun@iijlab.net Date: Fri, 03 Aug 2001 00:47:08 +0900 Message-ID: <17607.996767228@itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >> we can probably try it out (if it seems really necessary for us) >> on KAME tree, but not on *BSD-current nor *BSD official releases. >I believe one of the intended uses of this would be for >telnet/rpcbind, so I think it would really have to go into >*BSD-current to be used that way. we do have usr.bin/telnet and libexec/telnetd on kame tree, as we needed to experiment with newer APIs (2553bis/2292bis). itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 2 9: 2:48 2001 Delivered-To: freebsd-net@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id E071537B401; Thu, 2 Aug 2001 09:02:39 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id CAA28278; Fri, 3 Aug 2001 02:02:10 +1000 Date: Fri, 3 Aug 2001 01:59:36 +1000 (EST) From: Bruce Evans X-X-Sender: To: Julian Elischer Cc: Brian Somers , Thomas Pornin , , , Brian Somers , Subject: Re: kern/27767: (was: PPPoE + Alpha + 32/64 bits) In-Reply-To: Message-ID: <20010803015717.B1110-100000@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 1 Aug 2001, Julian Elischer wrote: > DUH! > (slaps forhead with palm "obvious when shown") > On Wed, 1 Aug 2001, Brian Somers wrote: > > Index: ng_pppoe.c > > =================================================================== > > RCS file: /home/ncvs/src/sys/netgraph/ng_pppoe.c,v > > retrieving revision 1.45 > > diff -u -r1.45 ng_pppoe.c > > --- ng_pppoe.c 2001/07/25 03:34:07 1.45 > > +++ ng_pppoe.c 2001/08/01 22:40:15 > > @@ -868,7 +868,7 @@ > > struct { > > struct pppoe_tag hdr; > > union uniq data; > > - } uniqtag; > > + } __attribute ((packed)) uniqtag; > > > > /* > > * kick the state machine into starting up > > @@ -910,7 +910,7 @@ > > struct { > > struct pppoe_tag hdr; > > union uniq data; > > - } uniqtag; > > + } __attribute ((packed)) uniqtag; > > negp neg = NULL; > > struct mbuf *m; Obviously a syntax error. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 2 10: 7: 5 2001 Delivered-To: freebsd-net@freebsd.org Received: from imo-m06.mx.aol.com (imo-m06.mx.aol.com [64.12.136.161]) by hub.freebsd.org (Postfix) with ESMTP id 2377337B403 for ; Thu, 2 Aug 2001 10:07:03 -0700 (PDT) (envelope-from raviprasad20@netscape.net) Received: from raviprasad20@netscape.net by imo-m06.mx.aol.com (mail_out_v31.9.) id n.5d.946603 (16245) for ; Thu, 2 Aug 2001 13:06:58 -0400 (EDT) Received: from netscape.com (mow-m05.webmail.aol.com [64.12.184.133]) by air-in03.mail.aol.com (v79.27) with ESMTP id MAILININ39-0802130658; Thu, 02 Aug 2001 13:06:58 -0400 Date: Thu, 02 Aug 2001 13:06:58 -0400 From: raviprasad20@netscape.net To: freebsd-net@freebsd.org Subject: kvm_read Message-ID: <54494153.542CCC41.9513E96F@netscape.net> X-Mailer: Atlas Mailer 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I found that some of the commands read the virtual memory of the kernel. Is there a way for me to know which address of the memory is currently being accessed? regards ravi prasad __________________________________________________________________ Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/ Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 2 10:25:10 2001 Delivered-To: freebsd-net@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id CE09E37B401; Thu, 2 Aug 2001 10:24:59 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.4/8.11.4) with SMTP id f72HOjf73349; Thu, 2 Aug 2001 13:24:45 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Thu, 2 Aug 2001 13:24:44 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: "Eugene L. Vorokov" Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: ipfw "established" option In-Reply-To: <200108020739.f727dbY02620@bugz.infotecs.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org As Bill Fumerola has indicated, and I thought I'd follow up in with a bit more detail, the behavior you're seeing is the result of a bug in the FreeBSD IPFW code. FreeBSD did a direct comparison of the TCP header flag field with an internal field in the IPFW rule description structure. Unfortunately, at some point, someone decided to overload the IPFW rule description structure field to add a flag representing "ESTABLISHED". They used a flag value that was previously unused by the TCP protocol (which doesn't make it safer, just less noticeable). Later, when that flag was allocated for ECN (Endpoint Congestion Notification) in TCP, and Linux began using ECN by default, the packets began to match ESTABLISHED rules regardless of the other TCP header flags. This bug was corrected on the RELENG_4 branch, and security advisory for the bug was released. This was, needless to say, a pretty serious bug, and good example of why you should be very careful to compare only the bits you really mean to, and should seperate packet state from protocol state in management structures, as well as make use of extensive testing to make sure rules actually have the effect you describe. I understand a number of such tests are available for the ipfilter firewall module--it might make sense to modify them to test similar functionality in IPFW. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services On Thu, 2 Aug 2001, Eugene L. Vorokov wrote: > Hello, > > I've found some strange issue regarding ipfw. I have freebsd 4.2-RELEASE. > Guess I have rules: > > 1 allow tcp from any to 195.210.139.22 established > 2 deny tcp from any to 195.210.139.22 > 2 allow all from any to any > > The intention is to allow the machine itself connect outside and accept > responces once connection is established, but deny attepmts to connect > to this machine from outside. I was thinking that first packet which tries > to establish TCP connection should never match rule 1. > > However, I've found that it depends on which operating system tries to > connect in ! When I try this from machine with freebsd 4.3-RELEASE, it gets > dropped as expected. tcpdump on my machine says: > > 11:15:01.841594 195.222.16.243.1117 > 195.210.139.22.21: S 3910802910:3910802910(0) win 16384 (DF) [tos 0x10] > 11:15:04.911908 195.222.16.243.1117 > 195.210.139.22.21: S 3910802910:3910802910(0) win 16384 (DF) [tos 0x10] > 11:15:07.804934 195.222.16.243.1117 > 195.210.139.22.21: S 3910802910:3910802910(0) win 16384 (DF) [tos 0x10] > > Okay, that's fine. But then I try the same from Linux machine (2.4.5). > I am able to successfully telnet in ! tcpdump says: > > 11:15:51.479203 195.230.76.28.39925 > 195.210.139.22.21: S [ECN-Echo,CWR] 4162184178:4162184178(0) win 5840 (DF) [tos 0x10] > 11:15:51.479466 195.210.139.22.21 > 195.230.76.28.39925: S 2404031587:2404031587(0) ack 4162184179 win 17520 (DF) > 11:15:51.565124 195.230.76.28.39925 > 195.210.139.22.21: . ack 1 win 5840 (DF) [tos 0x10] > 11:15:51.590818 195.210.139.22.21 > 195.230.76.28.39925: P 1:58(57) ack 1 win 17520 (DF) [tos 0x10] > 11:15:51.648107 195.230.76.28.39925 > 195.210.139.22.21: . ack 58 win 5840 (DF) [tos 0x10] > > Firewall logs also say that the initial packet matched the rule 1 > and was passed. > > Why is it like that ? Am I missing something ? > > Regards, > Eugene > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 2 10:46:51 2001 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (f248.law11.hotmail.com [64.4.17.248]) by hub.freebsd.org (Postfix) with ESMTP id 3F8CE37B401; Thu, 2 Aug 2001 10:46:46 -0700 (PDT) (envelope-from sroberts84@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 2 Aug 2001 10:46:45 -0700 Received: from 213.122.201.198 by lw11fd.law11.hotmail.msn.com with HTTP; Thu, 02 Aug 2001 17:46:45 GMT X-Originating-IP: [213.122.201.198] From: "Stacey Roberts" To: bde@zeta.org.au, julian@elischer.org Cc: brian@Awfulhak.org, Thomas.Pornin@ens.fr, freebsd-net@FreeBSD.ORG, freebsd-alpha@FreeBSD.ORG, brian@freebsd-services.com, FreeBSD-gnats-submit@FreeBSD.ORG Subject: FreeBSD V4.3 running on ABIT VP6 Dual Proc Date: Thu, 02 Aug 2001 17:46:45 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 02 Aug 2001 17:46:45.0981 (UTC) FILETIME=[192420D0:01C11B7B] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi Guys, I've just ordered FreeBSD V4.3, hoping to install it on a VP6 Dual proc system running two P111 933's. I've tried searching for known issues with this particular motherboard via all the search facilities at the FreeBSD sites, but cannot find any actual documentation on whether or not this motherboard is actually compatible with FreeBSD V4.3. Can any of you assist / advise? Cheers Stacey _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 2 11:24:11 2001 Delivered-To: freebsd-net@freebsd.org Received: from smtp05.wxs.nl (smtp05.wxs.nl [195.121.6.57]) by hub.freebsd.org (Postfix) with ESMTP id 3192C37B401 for ; Thu, 2 Aug 2001 11:24:07 -0700 (PDT) (envelope-from rtek@dolfijntje.nl) Received: from dolfijntje.nl ([195.121.188.57]) by smtp05.wxs.nl (Netscape Messaging Server 4.05) with ESMTP id GHGDS501.1AG; Thu, 2 Aug 2001 20:24:05 +0200 Message-ID: <3B699AC3.802104CA@dolfijntje.nl> Date: Thu, 02 Aug 2001 20:24:03 +0200 From: Sjaak Jobses X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Stacey Roberts , freebsd-net@freebsd.org Subject: Re: FreeBSD V4.3 running on ABIT VP6 Dual Proc References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Stacey Roberts wrote: > > Hi Guys, > I've just ordered FreeBSD V4.3, hoping to install it on a VP6 Dual proc > system running two P111 933's. > > I've tried searching for known issues with this particular motherboard via > all the search facilities at the FreeBSD sites, but cannot find any actual > documentation on whether or not this motherboard is actually compatible with > FreeBSD V4.3. > > Can any of you assist / advise? > > Cheers > > Stacey > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message As long as the board will support the Intel MP (1.1?) specification, I don't think it will be any problem. Then again, I could be wrong... -- Sjaak Jobses aka rtek To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 2 11:28:27 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 2A80337B406; Thu, 2 Aug 2001 11:28:20 -0700 (PDT) (envelope-from julian@elischer.org) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA46920; Thu, 2 Aug 2001 13:38:46 -0700 (PDT) Date: Thu, 2 Aug 2001 13:38:46 -0700 (PDT) From: Julian Elischer To: Bruce Evans Cc: Brian Somers , Thomas Pornin , freebsd-net@FreeBSD.ORG, freebsd-alpha@FreeBSD.ORG, Brian Somers , FreeBSD-gnats-submit@FreeBSD.ORG Subject: Re: kern/27767: (was: PPPoE + Alpha + 32/64 bits) In-Reply-To: <20010803015717.B1110-100000@besplex.bde.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org care to explain? On Fri, 3 Aug 2001, Bruce Evans wrote: > On Wed, 1 Aug 2001, Julian Elischer wrote: > > > DUH! > > (slaps forhead with palm "obvious when shown") > > > On Wed, 1 Aug 2001, Brian Somers wrote: > > > Index: ng_pppoe.c > > > =================================================================== > > > RCS file: /home/ncvs/src/sys/netgraph/ng_pppoe.c,v > > > retrieving revision 1.45 > > > diff -u -r1.45 ng_pppoe.c > > > --- ng_pppoe.c 2001/07/25 03:34:07 1.45 > > > +++ ng_pppoe.c 2001/08/01 22:40:15 > > > @@ -868,7 +868,7 @@ > > > struct { > > > struct pppoe_tag hdr; > > > union uniq data; > > > - } uniqtag; > > > + } __attribute ((packed)) uniqtag; > > > > > > /* > > > * kick the state machine into starting up > > > @@ -910,7 +910,7 @@ > > > struct { > > > struct pppoe_tag hdr; > > > union uniq data; > > > - } uniqtag; > > > + } __attribute ((packed)) uniqtag; > > > negp neg = NULL; > > > struct mbuf *m; > > Obviously a syntax error. > > Bruce > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 2 11:50: 6 2001 Delivered-To: freebsd-net@freebsd.org Received: from ringworld.nanolink.com (unknown [217.75.135.248]) by hub.freebsd.org (Postfix) with SMTP id B565137B406 for ; Thu, 2 Aug 2001 11:49:54 -0700 (PDT) (envelope-from roam@orbitel.bg) Received: (qmail 31979 invoked by uid 1000); 2 Aug 2001 18:48:41 -0000 Date: Thu, 2 Aug 2001 21:48:41 +0300 From: Peter Pentchev To: bstephens@regionsmortgage.com Cc: net@FreeBSD.org Subject: Re: Using FreeBSD server as a router?? Message-ID: <20010802214841.E11105@ringworld.oblivion.bg> References: <86256A9C.00636E33.00@smtp.regionsmortgage.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <86256A9C.00636E33.00@smtp.regionsmortgage.com>; from bstephens@regionsmortgage.com on Thu, Aug 02, 2001 at 12:57:09PM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, Aug 02, 2001 at 12:57:09PM -0500, bstephens@regionsmortgage.com wrote: > > > I have been combing the freebsd.org site for the last two days > attempting to find some documentation on how to configure and use a > FreeBSD server as a router. I have found some information on > configuring the server as a bridge as well as a filtering bridge, but > no router info. Does anyone have any leads on some info? There seems > to be a number of such articles/books for doing a similar feet under > Linux, but I can't seem to find any such documentation for FreeBSD. I > have been wondering about using the filtering bridge scheme. It would > provide the segmentation of traffic that I need but does it provide > routing tables, shortest data path info, etc. as a router would? Any > assistance is appreciated. I believe this message belongs in -net. G'luck, Peter -- This sentence contains exactly threee erors. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 2 12:10:59 2001 Delivered-To: freebsd-net@freebsd.org Received: from ns2.myway.com.br (ns2.myway.com.br [200.186.239.2]) by hub.freebsd.org (Postfix) with SMTP id 5EF0037B401; Thu, 2 Aug 2001 12:10:53 -0700 (PDT) (envelope-from leal@myway.com.br) Received: from myway.com.br (unverified [200.186.239.10]) by ns2.myway.com.br (EMWAC SMTPRS 0.83) with SMTP id ; Thu, 02 Aug 2001 16:09:45 -0300 Message-ID: <3B69A676.5FE8CAC0@myway.com.br> Date: Thu, 02 Aug 2001 16:13:58 -0300 From: Marcelo Leal Organization: webcom X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.2-RELEASE i386) X-Accept-Language: pt-BR, en MIME-Version: 1.0 To: Julian Elischer Cc: Bruce Evans , Brian Somers , Thomas Pornin , freebsd-net@FreeBSD.ORG, freebsd-alpha@FreeBSD.ORG, Brian Somers , FreeBSD-gnats-submit@FreeBSD.ORG Subject: Re: kern/27767: (was: PPPoE + Alpha + 32/64 bits) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Antirelay: Good relay from local net2 200.186.239.0/24 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Why my arp table is wrong???? the windows machines and my freebsd box are with crazy arp table!!! my freebsd box sad: arp 10.0.0.1 moved from xxxxx to xxxxx and don't ping anything... my windows machines too. but windows don't tell me anything!!!! i have one server dhcp (FreeBSD) and this machine run NAT for my dhcp clients. another problem is that two or more machines ping one internet host, the reply go to just one. thanks!!!! help... sorry by the english. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 2 13:14:25 2001 Delivered-To: freebsd-net@freebsd.org Received: from ns2.myway.com.br (ns2.myway.com.br [200.186.239.2]) by hub.freebsd.org (Postfix) with SMTP id BA8FE37B403; Thu, 2 Aug 2001 13:14:14 -0700 (PDT) (envelope-from leal@myway.com.br) Received: from myway.com.br (unverified [200.186.239.10]) by ns2.myway.com.br (EMWAC SMTPRS 0.83) with SMTP id ; Thu, 02 Aug 2001 17:13:10 -0300 Message-ID: <3B69B553.FE5F0C@myway.com.br> Date: Thu, 02 Aug 2001 17:17:23 -0300 From: Marcelo Leal Organization: webcom X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.2-RELEASE i386) X-Accept-Language: pt-BR, en MIME-Version: 1.0 To: Chris Dillon Cc: Terry Lambert , Julian Elischer , "Eugene L. Vorokov" , Soren Kristensen , freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: arp References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Antirelay: Good relay from local net2 200.186.239.0/24 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org thanks!!! sorry but just now i see your message... the problem is alive... i will look what you sugest... but this problem don't would be the switch ports??? switch arp tables??? the linux machines (clients) don't loose the arp address of my dhcp server... but the windows machines and freebsd boxes do. do ipfnat nat for icmp requests??? when two or more machines ping the same host in internet, just one receive the reply. these two problems are drive me crazy! the linux box (dhcp server) did not had these problems... i trust in freebsd... if i add more time to leases... when the time go out the problem will come back... right??? why the linux boxes (clients) work fine???? thanks Chris Dillon wrote: > > On Fri, 27 Jul 2001, Marcelo Leal wrote: > > > folks... > > sorry, but i trust in you :O) > > i have a problem, and don't know where find the answers... and that list > > is for net problems... > > my desktop freebsd give me a message: arp moved from: xxx to xxx... ARP > > MOVED???? > > when i look in arp table.... the arp address of my dhcpd server is > > wrong!!! i put the right there... and reboot... look and.... the > > wrong!!!! > > this mac address is not from my network... (machines) .. > > maybe arp of the switch ports... > > thanks!!! > > and sorry by the english... :O) > > i'm brazilian. > > You have more than one machine on the network that is attempting to > use the same IP address and/or your DHCP server is handing out leases > that are shorter than the ARP cache life and you are recycling DHCP > leases quickly. > > I suggest you set your DHCP lease times to at least an hour or more > (my DHCP leases are one week), and make sure there are no > manually-configured machines that are attempting to use an address > from the DHCP address pool, or two manually-configured machines trying > to use the same address. > > -- Chris Dillon - cdillon@wolves.k12.mo.us - cdillon@inter-linc.net > FreeBSD: The fastest and most stable server OS on the planet > - Available for IA32 (Intel x86) and Alpha architectures > - IA64 (Itanium), PowerPC, and ARM architectures under development > - http://www.freebsd.org > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 2 13:52: 5 2001 Delivered-To: freebsd-net@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 0D4AC37B401; Thu, 2 Aug 2001 13:51:56 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id GAA09412; Fri, 3 Aug 2001 06:51:28 +1000 Date: Fri, 3 Aug 2001 06:48:54 +1000 (EST) From: Bruce Evans X-X-Sender: To: Julian Elischer Cc: Brian Somers , Thomas Pornin , , , Brian Somers , Subject: Re: kern/27767: (was: PPPoE + Alpha + 32/64 bits) In-Reply-To: Message-ID: <20010803054935.M2890-100000@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, 2 Aug 2001, Julian Elischer wrote: > care to explain? Please trim quotes and reply after the quoted section[s]. > On Fri, 3 Aug 2001, Bruce Evans wrote: > > > On Wed, 1 Aug 2001, Brian Somers wrote: > > > > @@ -910,7 +910,7 @@ > > > > struct { > > > > struct pppoe_tag hdr; > > > > union uniq data; > > > > - } uniqtag; > > > > + } __attribute ((packed)) uniqtag; > > > > negp neg = NULL; > > > > struct mbuf *m; > > > > Obviously a syntax error. `__attribute ((packed))' is a syntax error in Standard C. Dependencies on compiler features are supposed to be centralized in places like . Many invocations of __attribute__(()) are placed there. This is not possible for the `packed' attribute because this attribute has non-cosmetic effects. Structs must be carefully laid out to give some chance of them not having any internal padding for any compiler. This sometimes involves using struct members with an unnatural type. has many examples. Here I don't see how packing the struct helps on alphas. Doesn't it cause traps by misaligning uniqtag.data.pointer? I think you need something like: struct { struct pppoe_tag hdr; char data[sizeof(void *)]; } uniqtag; void *pointer; ... pointer = sp; memcpy(uniqtag.data, &pointer, sizeof(uniqtag.data)); Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 2 14: 8:38 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.internet2.edu (list.internet2.edu [209.211.239.181]) by hub.freebsd.org (Postfix) with ESMTP id 2F05437B401 for ; Thu, 2 Aug 2001 14:08:35 -0700 (PDT) (envelope-from shalunov@internet2.edu) Received: from cain.internet2.edu (localhost [127.0.0.1]) by mail.internet2.edu (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f72L8Xh25897 for ; Thu, 2 Aug 2001 17:08:33 -0400 X-Authentication-Warning: mail.internet2.edu: Host localhost [127.0.0.1] claimed to be cain.internet2.edu Received: by cain.internet2.edu (Postfix, from userid 1000) id 46AEB8E8; Thu, 2 Aug 2001 17:08:32 -0400 (EDT) To: net@freebsd.org Subject: Re: TCP problems with large window sizes on FreeBSD (GigaTCP) References: <200108020503.f7253jY08157@prism.flugsvamp.com> <87y9p2qxvc.fsf@cain.internet2.edu> From: stanislav shalunov Date: 02 Aug 2001 17:08:32 -0400 In-Reply-To: <87y9p2qxvc.fsf@cain.internet2.edu> Message-ID: <87n15inp9r.fsf@cain.internet2.edu> Lines: 24 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org stanislav shalunov writes: > I'll try increasing the value of TI_JSLOTS to 8192 (twice the number > of 4K packets in 16MB window) and see if it makes a difference. FWIW, this seems to have improved the situation and the burst loss doesn't happen anymore. For those who might care to look at the new numbers, see http://www.internet2.edu/~shalunov/gigatcp/ There seems to be a problem with the ti driver in that it doesn't recover from the situation of jumbo slots shortage right away after supply of packets is removed, as one would expect it to. The condition lingers for a long time afterwards. It seems to recover eventually, but after quite different time for diffirent conditions: sometimes it's seconds, sometimes it's minutes. The "slow" case appears to be an example of fast periodic recovery, while in the "stalled" case the recovery doesn't happen until the TCP connection times out. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ "I didn't attend the funeral, but I sent a nice letter saying that I approved of it." -- Mark Twain To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 2 15: 0:38 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.disney.com (mail.disney.com [204.128.192.15]) by hub.freebsd.org (Postfix) with ESMTP id D139B37B403 for ; Thu, 2 Aug 2001 15:00:36 -0700 (PDT) (envelope-from Jim.Pirzyk@disney.com) Received: from pain10.corp.disney.com (root@pain10.corp.disney.com [153.7.110.100]) by mail.disney.com (Switch-2.0.1/Switch-2.0.1) with SMTP id f72Lxle29975 for ; Thu, 2 Aug 2001 14:59:47 -0700 (PDT) Received: from [172.30.50.1] by pain.corp.disney.com with ESMTP for freebsd-net@freebsd.org; Thu, 2 Aug 2001 14:57:29 -0700 Received: from plio.fan.fa.disney.com (plio.fan.fa.disney.com [153.7.118.2]) by pecos.fa.disney.com (8.11.3/8.11.3) with ESMTP id f72LwOs02040 for ; Thu, 2 Aug 2001 14:58:24 -0700 (PDT) Received: from mercury.fan.fa.disney.com (mercury.fan.fa.disney.com [153.7.119.1]) by plio.fan.fa.disney.com (8.9.2/8.9.2) with ESMTP id OAA26418 for ; Thu, 2 Aug 2001 14:56:31 -0700 (PDT) (envelope-from Jim.Pirzyk@disney.com) Received: from snoopy.fan.fa.disney.com by mercury.fan.fa.disney.com for freebsd-net@freebsd.org; Thu, 2 Aug 2001 14:56:30 -0700 Content-Type: text/plain; charset="us-ascii" From: Jim Pirzyk Organization: Walt Disney Feature Animation To: freebsd-net@freebsd.org Subject: ng_one2many usage Date: Thu, 2 Aug 2001 14:56:30 -0700 X-Mailer: KMail [version 1.2] MIME-Version: 1.0 Message-Id: <01080214563006.36347@snoopy> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org So I tried to use the one2many netgraph module, but I get errors right away. Here is what I get: Jim.Pirzyk@snoopy:~ 47>sudo ngctl -d mkpeer trnk0: one2many upper one ngctl: sendto(trnk0:): No such file or directory ngctl: send msg: No such file or directory Any ideas on what is going wrong? - JimP -- --- @(#) $Id: dot.signature,v 1.10 2001/05/17 23:38:49 Jim.Pirzyk Exp $ __o Jim.Pirzyk@disney.com ------------- pirzyk@freebsd.org _'\<,_ Senior Systems Engineer, Walt Disney Feature Animation (*)/ (*) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 2 15: 4:17 2001 Delivered-To: freebsd-net@freebsd.org Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by hub.freebsd.org (Postfix) with SMTP id 6AB7637B405 for ; Thu, 2 Aug 2001 15:04:09 -0700 (PDT) (envelope-from oppermann@telehouse.ch) Received: (qmail 41034 invoked from network); 2 Aug 2001 22:03:37 -0000 Received: from unknown (HELO telehouse.ch) ([62.48.21.178]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 2 Aug 2001 22:03:37 -0000 Message-ID: <3B69CE3F.1BCCB280@telehouse.ch> Date: Fri, 03 Aug 2001 00:03:43 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Cc: freebsd-net@freebsd.org Subject: 303,000 routes in kernel Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello guys have got a small problem. I'm running a secondary DNS server for the ccTLD .ch here in Switzerland. The box is a Intel ISP2150 with a PIII-750 and 512MB RAM plus 18GB SCSI disk. Two fxp cards inside. This machine is running FreeBSD 4.3-RELEASE and tinydns as DNS server. It answering approximatly 100 dns requests per second for the .ch ccTLD zone. These DNS requests come from all over the world so I see basically the whole allocated IP address space here. The problem I've got now is that for every packet I get the kernel is making one host entry in the routing table. Because of the many UDP DNS requests from all over the world I've got 303'000 (yes, three- hundredthreethousand) entries in the kernel routing table which have not expired yet. So I'm getting error messages like this now: Aug 2 23:57:14 ccTLD /kernel: arpresolve: can't allocate llinfo for 194.42.48.126 rt Aug 2 23:57:14 ccTLD /kernel: arplookup 194.42.48.126 failed: could not allocate llinfo # netstat -m 149/640/6144 mbufs in use (current/peak/max): 146 mbufs allocated to data 3 mbufs allocated to packet headers 128/304/1536 mbuf clusters in use (current/peak/max) 768 Kbytes allocated to network (16% of mb_map in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines # netstat -rn | wc -l 303875 # vmstat -m Memory statistics by type Type Kern Type InUse MemUse HighUse Limit Requests Limit Limit Size(s) ... routetbl607857 85480K 85480K 85480K 2420956 0 0 16,32,64,128,256 ... Memory Totals: In Use Free Requests 91073K 2948K 786316696 So many routing entries are total overkill, all I would need in reality are the default route plus some other, or in worst case a full view of the Internet prefixes (approx. 105,000 at the moment) but definatly not a host route for every UDP packet I get. The network route would be absolutely sufficient for delivering the packet back to it's origin. Any ideas on how to deal with this? TIA -- Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 2 15: 9:43 2001 Delivered-To: freebsd-net@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 8474B37B401; Thu, 2 Aug 2001 15:09:38 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.4/8.11.4) with ESMTP id f72M9Qx93102; Fri, 3 Aug 2001 00:09:26 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Andre Oppermann Cc: freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: 303,000 routes in kernel In-Reply-To: Your message of "Fri, 03 Aug 2001 00:03:43 +0200." <3B69CE3F.1BCCB280@telehouse.ch> Date: Fri, 03 Aug 2001 00:09:26 +0200 Message-ID: <93100.996790166@critter> From: Poul-Henning Kamp Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In message <3B69CE3F.1BCCB280@telehouse.ch>, Andre Oppermann writes: >The problem I've got now is that for every packet I get the kernel is >making one host entry in the routing table. Because of the many UDP >DNS requests from all over the world I've got 303'000 (yes, three- >hundredthreethousand) entries in the kernel routing table which have >not expired yet. So I'm getting error messages like this now: Hmm, I wasn't aware that we cloned routes for UDP packets, are you sure that is what is causing the routes to exists ? (Just to mention the obvious: it's not CodeRed probes ?) You can tweak the route behaviour with some sysctls: Notably: net.inet.ip.rtexpire: 473 net.inet.ip.rtminexpire: 10 net.inet.ip.rtmaxcache: 128 There's probably also a detailed explanation what they do somewhere... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 2 15:27:48 2001 Delivered-To: freebsd-net@freebsd.org Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by hub.freebsd.org (Postfix) with SMTP id 03DCD37B405 for ; Thu, 2 Aug 2001 15:27:38 -0700 (PDT) (envelope-from oppermann@telehouse.ch) Received: (qmail 41895 invoked from network); 2 Aug 2001 22:27:11 -0000 Received: from unknown (HELO telehouse.ch) ([62.48.21.178]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 2 Aug 2001 22:27:11 -0000 Message-ID: <3B69D3C5.3562B7C4@telehouse.ch> Date: Fri, 03 Aug 2001 00:27:17 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Poul-Henning Kamp Cc: freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: 303,000 routes in kernel References: <93100.996790166@critter> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Poul-Henning Kamp wrote: > > In message <3B69CE3F.1BCCB280@telehouse.ch>, Andre Oppermann writes: > > >The problem I've got now is that for every packet I get the kernel is > >making one host entry in the routing table. Because of the many UDP > >DNS requests from all over the world I've got 303'000 (yes, three- > >hundredthreethousand) entries in the kernel routing table which have > >not expired yet. So I'm getting error messages like this now: > > Hmm, I wasn't aware that we cloned routes for UDP packets, are you sure > that is what is causing the routes to exists ? (Just to mention the > obvious: it's not CodeRed probes ?) No, it's not code red probes. My apache log is only 3 Meg in size and has not been rotated in the past 2 month. So, yes, it looks like UDP packets are also generating cloned routes. > You can tweak the route behaviour with some sysctls: > > Notably: > net.inet.ip.rtexpire: 473 > net.inet.ip.rtminexpire: 10 > net.inet.ip.rtmaxcache: 128 Isn't this for fastforwarding? > There's probably also a detailed explanation what they do somewhere... Is there any knob to turn route cloning off? Would that hurt? -- Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 2 15:36:33 2001 Delivered-To: freebsd-net@freebsd.org Received: from volatile.chemikals.org (unknown [24.6.40.144]) by hub.freebsd.org (Postfix) with ESMTP id 90F2737B401; Thu, 2 Aug 2001 15:36:27 -0700 (PDT) (envelope-from morganw@chemikals.org) Received: (from morganw@localhost) by volatile.chemikals.org (8.11.5/8.11.3) id f72MaQo00797; Thu, 2 Aug 2001 18:36:26 -0400 (EDT) (envelope-from morganw) Date: Thu, 2 Aug 2001 18:36:25 -0400 (EDT) From: Wesley Morgan To: Cc: Subject: wi and fxp Message-ID: <20010802183223.Q629-100000@volatile.chemikals.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I'm having trouble using my wavelan card (gold, with ISA adapter) along side a newly installed Intel Pro/100 lan card. With the fxp card in the system, whether or not the driver is compiled in, pccardd cant find the wavelan. Once the card is removed, it works fine. I'm fairly sure this isn't an issue of interrupts because if I stick in an old 3c509 they work fine together. There is another pci ethernet card in the system, a realtek 8029. Is anyone using a setup similar to this with success? -- _ __ ___ ____ ___ ___ ___ Wesley N Morgan _ __ ___ | _ ) __| \ morganw@chemikals.org _ __ | _ \._ \ |) | FreeBSD: The Power To Serve _ |___/___/___/ 6bone: 3ffe:1ce3:7::b4ff:fe53:c297 Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 2 16:38:22 2001 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (gw.Awfulhak.org [217.204.245.18]) by hub.freebsd.org (Postfix) with ESMTP id 8592D37B401; Thu, 2 Aug 2001 16:38:10 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.4/8.11.4) with ESMTP id f72Nc7s17630; Fri, 3 Aug 2001 00:38:07 +0100 (BST) (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.4/8.11.4) with ESMTP id f72Nc6u09427; Fri, 3 Aug 2001 00:38:06 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200108022338.f72Nc6u09427@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Bruce Evans Cc: Julian Elischer , Brian Somers , Thomas Pornin , freebsd-net@FreeBSD.ORG, freebsd-alpha@FreeBSD.ORG, Brian Somers , FreeBSD-gnats-submit@FreeBSD.ORG, brian@freebsd-services.com Subject: Re: kern/27767: (was: PPPoE + Alpha + 32/64 bits) In-Reply-To: Message from Bruce Evans of "Fri, 03 Aug 2001 06:48:54 +1000." <20010803054935.M2890-100000@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <9420.996795486.1@hak.lan.Awfulhak.org> Date: Fri, 03 Aug 2001 00:38:06 +0100 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > `__attribute ((packed))' is a syntax error in Standard C. > > Dependencies on compiler features are supposed to be centralized in > places like . Many invocations of __attribute__(()) are > placed there. This is not possible for the `packed' attribute because > this attribute has non-cosmetic effects. Structs must be carefully > laid out to give some chance of them not having any internal padding > for any compiler. This sometimes involves using struct members with > an unnatural type. has many examples. > > Here I don't see how packing the struct helps on alphas. Doesn't it > cause traps by misaligning uniqtag.data.pointer? I think you need > something like: It doesn't cause a trap as the compiler is (now) smart enough to handle it properly. Note where we have the alignment problem here: beast:~ $ cat x.c #include struct s { short x, y; }; union u { char c[sizeof(void*)]; void *v; }; struct x { struct s s; union u u; } __attribute ((packed)); int main() { struct x x; char c[] = "hello"; int i; x.u.v = c; /* This is ok despite it not being aligned */ i = (char *)&x.u.v - (char *)&x; printf("Got \"%s\", offset %d\n", (char *)x.u.v, i); *(void **)((char *)&x + 4) = c; /* This is not ok */ printf("Without knowledge of packed... \"%s\"\n", (char *)x.u.v); return 0; } beast:~ $ cc -o x x.c beast:~ $ ./x Got "hello", offset 4 pid 30842 (x): unaligned access: va=0x11ffba64 pc=0x120000894 ra=0x120000884 op=stq Without knowledge of packed... "hello" > struct { > struct pppoe_tag hdr; > char data[sizeof(void *)]; > } uniqtag; > void *pointer; > ... > pointer = sp; > memcpy(uniqtag.data, &pointer, sizeof(uniqtag.data)); That's probably better. I went with the __attribute((packed)) stuff because it was already done that way in the rest of the code. In this specific case however, it may be best to just send the variable plus the alignment padding as the tag: struct { struct pppoe_tag hdr; union uniq data; } uniqtag; ...... uniqtag.hdr.tag_type = PTT_HOST_UNIQ; uniqtag.hdr.tag_len = htons((u_int16_t)(sizeof(uniqtag) - sizeof(uniqtag.hdr)); uniqtag.data.pointer = sp; But I'm not convinced it gains anything given the other uses of __attribute((packed)) in this code. > Bruce -- Brian http://www.freebsd-services.com/ Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 2 17: 6:43 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 21D5337B401; Thu, 2 Aug 2001 17:06:39 -0700 (PDT) (envelope-from julian@elischer.org) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id TAA48308; Thu, 2 Aug 2001 19:11:59 -0700 (PDT) Date: Thu, 2 Aug 2001 19:11:58 -0700 (PDT) From: Julian Elischer To: Brian Somers Cc: Bruce Evans , Thomas Pornin , freebsd-net@FreeBSD.ORG, freebsd-alpha@FreeBSD.ORG, Brian Somers , FreeBSD-gnats-submit@FreeBSD.ORG, Brian Somers Subject: Re: kern/27767: (was: PPPoE + Alpha + 32/64 bits) In-Reply-To: <200108022338.f72Nc6u09427@hak.lan.Awfulhak.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 3 Aug 2001, Brian Somers wrote: > > That's probably better. I went with the __attribute((packed)) stuff > because it was already done that way in the rest of the code. > > In this specific case however, it may be best to just send the variable > plus the alignment padding as the tag: > > struct { > struct pppoe_tag hdr; > union uniq data; > } uniqtag; > > ...... > uniqtag.hdr.tag_type = PTT_HOST_UNIQ; > uniqtag.hdr.tag_len = htons((u_int16_t)(sizeof(uniqtag) - sizeof(uniqtag.hdr)); > uniqtag.data.pointer = sp; urk I prefer bruce's method :-) but if the rest use packed.. we can probably use it here to be consistant.. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 3 0:45:27 2001 Delivered-To: freebsd-net@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id B772F37B401; Fri, 3 Aug 2001 00:45:22 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id f737jLF02396; Fri, 3 Aug 2001 01:45:21 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.3/8.11.4) with ESMTP id f737jKH62746; Fri, 3 Aug 2001 01:45:21 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200108030745.f737jKH62746@harmony.village.org> To: Wesley Morgan Subject: Re: wi and fxp Cc: mobile@FreeBSD.ORG, net@FreeBSD.ORG In-reply-to: Your message of "Thu, 02 Aug 2001 18:36:25 EDT." <20010802183223.Q629-100000@volatile.chemikals.org> References: <20010802183223.Q629-100000@volatile.chemikals.org> Date: Fri, 03 Aug 2001 01:45:20 -0600 From: Warner Losh Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In message <20010802183223.Q629-100000@volatile.chemikals.org> Wesley Morgan writes: : I'm having trouble using my wavelan card (gold, with ISA adapter) along : side a newly installed Intel Pro/100 lan card. With the fxp card in the : system, whether or not the driver is compiled in, pccardd cant find the : wavelan. Once the card is removed, it works fine. I'm fairly sure this : isn't an issue of interrupts because if I stick in an old 3c509 they work : fine together. There is another pci ethernet card in the system, a realtek : 8029. Check to make sure that the fxp card doesn't have a ROM that lives in the ISA space that you've assigned for the pccard. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 3 2:50: 0 2001 Delivered-To: freebsd-net@freebsd.org Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by hub.freebsd.org (Postfix) with ESMTP id E303D37B406; Fri, 3 Aug 2001 02:49:55 -0700 (PDT) (envelope-from ticso@mail.cicely.de) Received: from mail.cicely.de (cicely20 [10.1.1.22]) by srv1.cosmo-project.de (8.11.0/8.11.0) with ESMTP id f739ktV45602; Fri, 3 Aug 2001 11:46:55 +0200 (CEST) Received: (from ticso@localhost) by mail.cicely.de (8.11.0/8.11.0) id f739koY02574; Fri, 3 Aug 2001 11:46:50 +0200 (CEST) Date: Fri, 3 Aug 2001 11:46:49 +0200 From: Bernd Walter To: Andre Oppermann Cc: freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: 303,000 routes in kernel Message-ID: <20010803114648.A2565@cicely20.cicely.de> References: <3B69CE3F.1BCCB280@telehouse.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B69CE3F.1BCCB280@telehouse.ch>; from oppermann@telehouse.ch on Fri, Aug 03, 2001 at 12:03:43AM +0200 X-Operating-System: NetBSD cicely20.cicely.de 1.5 sparc Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Aug 03, 2001 at 12:03:43AM +0200, Andre Oppermann wrote: > The problem I've got now is that for every packet I get the kernel is > making one host entry in the routing table. Because of the many UDP > DNS requests from all over the world I've got 303'000 (yes, three- > hundredthreethousand) entries in the kernel routing table which have > not expired yet. So I'm getting error messages like this now: Are you shure that these are not created via redirects when sending the packet? You might try to disable acepting redirects via sysctl and/or setting the routes so that packets have a better chance to be send to the right router. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 3 6:32:13 2001 Delivered-To: freebsd-net@freebsd.org Received: from purus.tcoip (cerberus.tcoip.com.br [200.220.254.3]) by hub.freebsd.org (Postfix) with ESMTP id 7AC5C37B405; Fri, 3 Aug 2001 06:32:06 -0700 (PDT) (envelope-from daniel.sobral@tcoip.com.br) Received: from tcoip.com.br (0nidqupfb5nnznrf@dcs.intra.tcoip.com.br [192.168.60.194]) by purus.tcoip (8.11.1/8.11.1) with ESMTP id f73DU5A30277; Fri, 3 Aug 2001 10:30:05 -0300 Message-ID: <3B6AA752.4070003@tcoip.com.br> Date: Fri, 03 Aug 2001 10:29:54 -0300 From: "Daniel C. Sobral" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.2) Gecko/20010705 X-Accept-Language: en, pt-br, ja MIME-Version: 1.0 To: stable@freebsd.org Subject: Request for testers: multicast patch Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org [Bcc'ed to -net] On http://people.freebsd.org/~dcs/ip_output.c there is a port to stable of the revisions 1.127 through 1.130 of /sys/netinet/ip_output.c. These patches do the following: 1) Enable one to send multicast packets without a default route or routes to the multicast addresses. 2) Enable one to send multicast packets on an interface without an address. 3) Prevent trouble if packets are sent through an interface without an address (vlan excluded). A similar version of these patches has been running on current for about three weeks (well, maybe 10 days if you exclude version 1.130 which addresses points 2 and 3). The main difference is that stable already has a check that is not present on current (I wonder why it was removed...). If a few people would be so kind as to test these patches... -- Daniel C. Sobral (8-DCS) Daniel.Sobral@tcoip.com.br dcs@newsguy.com dcs@freebsd.org capo@notorious.bsdconspiracy.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 3 7:38:30 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.andy.de (mail.andy.de [212.8.199.66]) by hub.freebsd.org (Postfix) with ESMTP id 1567437B406 for ; Fri, 3 Aug 2001 07:38:27 -0700 (PDT) (envelope-from andy@andy.de) Received: from ag.intra (gateway.buero.teuto.net [212.8.197.50]) by mail.andy.de (Postfix) with ESMTP id EA62847730A for ; Fri, 3 Aug 2001 16:38:19 +0200 (CEST) Date: Fri, 03 Aug 2001 16:35:47 +0200 From: Andreas Gerstenberg To: freebsd-net@freebsd.org Subject: VLANs with MTU 1500 an fxp driver? Message-ID: <27320000.996849347@ag.intra> X-Mailer: Mulberry/2.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I'm using VLANs (IEEE 802.1q taggig) with the fxp driver. In the past (up to 4.3 RELEASE and STABLE) the was a patch nessesary to get the MTU up to 1500 Bytes on the vlan-interfaces. I was using the patch found on http://www.euitt.upm.es/~pjlobo/fbsdvlan.html. This patch looks outdated, I think the fxp driver has changed (now uses miibus) in the 4.3 STABLE branch. I haven't another machine to test this, so I have to ask. Does the fxp driver run with VLANs using a MTU of 1500? Thank you, Andy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 3 7:46:51 2001 Delivered-To: freebsd-net@freebsd.org Received: from webmail.chimesnet.com (mail001.level3.chc-chimes.com [63.211.16.2]) by hub.freebsd.org (Postfix) with ESMTP id 6131F37B403 for ; Fri, 3 Aug 2001 07:46:47 -0700 (PDT) (envelope-from mayres@chimesnet.com) Received: from jade.chc-chimes.com (jade.chc-chimes.com [216.28.46.6]) by webmail.chimesnet.com (Postfix) with ESMTP id 7AE4DCAC502; Fri, 3 Aug 2001 10:46:46 -0400 (EDT) Received: by jade.chc-chimes.com (Postfix, from userid 1101) id 3DA421C7A; Fri, 3 Aug 2001 10:44:35 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by jade.chc-chimes.com (Postfix) with ESMTP id 2F9FD385C; Fri, 3 Aug 2001 10:44:35 -0400 (EDT) Date: Fri, 3 Aug 2001 10:44:35 -0400 (EDT) From: Matt Ayres X-X-Sender: To: Andreas Gerstenberg Cc: Subject: Re: VLANs with MTU 1500 an fxp driver? In-Reply-To: <27320000.996849347@ag.intra> Message-ID: <20010803104339.N85967-100000@jade.chc-chimes.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Yes, you need to add 'options VLAN' to your kernel. I believe this is done automatically for the fxp module. Thanks, -- Matt Ayres Network Architect Chimes, Inc. On Fri, 3 Aug 2001, Andreas Gerstenberg wrote: > Hi, > > I'm using VLANs (IEEE 802.1q taggig) with the fxp driver. In the past (up > to 4.3 RELEASE and STABLE) the was a patch nessesary to get the MTU up to > 1500 Bytes on the vlan-interfaces. I was using the patch found on > http://www.euitt.upm.es/~pjlobo/fbsdvlan.html. This patch looks outdated, I > think the fxp driver has changed (now uses miibus) in the 4.3 STABLE > branch. I haven't another machine to test this, so I have to ask. > > Does the fxp driver run with VLANs using a MTU of 1500? > > Thank you, > Andy > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 3 8:20:34 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.disney.com (mail.disney.com [204.128.192.15]) by hub.freebsd.org (Postfix) with ESMTP id 2BF8A37B403; Fri, 3 Aug 2001 08:20:29 -0700 (PDT) (envelope-from Jim.Pirzyk@disney.com) Received: from pain10.corp.disney.com (root@pain10.corp.disney.com [153.7.110.100]) by mail.disney.com (Switch-2.0.1/Switch-2.0.1) with SMTP id f73FJYe02549; Fri, 3 Aug 2001 08:19:34 -0700 (PDT) Received: from [172.30.50.1] by pain.corp.disney.com with ESMTP; Fri, 3 Aug 2001 08:21:20 -0700 Received: from plio.fan.fa.disney.com (plio.fan.fa.disney.com [153.7.118.2]) by pecos.fa.disney.com (8.11.3/8.11.3) with ESMTP id f73FMOs26923; Fri, 3 Aug 2001 08:22:24 -0700 (PDT) Received: from mercury.fan.fa.disney.com (mercury.fan.fa.disney.com [153.7.119.1]) by plio.fan.fa.disney.com (8.9.2/8.9.2) with ESMTP id IAA28010; Fri, 3 Aug 2001 08:20:22 -0700 (PDT) (envelope-from Jim.Pirzyk@disney.com) Received: from snoopy.fan.fa.disney.com by mercury.fan.fa.disney.com; Fri, 3 Aug 2001 08:20:22 -0700 Content-Type: text/plain; charset="us-ascii" From: Jim Pirzyk Organization: Walt Disney Feature Animation To: freebsd-net@freebsd.org, freebsd-mobile@freebsd.org Subject: Anyone using SMC 8040TX pccard? Date: Fri, 3 Aug 2001 08:20:22 -0700 X-Mailer: KMail [version 1.2] MIME-Version: 1.0 Message-Id: <01080308202200.73864@snoopy> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org So I have an SMC 8040TX pccard in an IBM Thinkpad 701CS. It is currently using the ed driver to talk on the network and this driver works ok (I can get 5+ Mb/sec outbound), but the performance problem is that I only get < 1Mb/sec inbound. So I have two questions, 1) is the ed driver the correct driver for this card, or should I be using the sn driver (which works for the SMC 8020 combo card) and 2) how would I get 100Mb/sec, since my understanding is that the ed driver only supports 10Mb/sec? TIA - JimP -- --- @(#) $Id: dot.signature,v 1.10 2001/05/17 23:38:49 Jim.Pirzyk Exp $ __o Jim.Pirzyk@disney.com ------------- pirzyk@freebsd.org _'\<,_ Senior Systems Engineer, Walt Disney Feature Animation (*)/ (*) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 3 9:13: 1 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by hub.freebsd.org (Postfix) with ESMTP id 7D81B37B408; Fri, 3 Aug 2001 09:12:59 -0700 (PDT) (envelope-from fenner@research.att.com) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id EB01A4CE05; Fri, 3 Aug 2001 12:12:58 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id MAA13674; Fri, 3 Aug 2001 12:12:53 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id JAA18086; Fri, 3 Aug 2001 09:12:52 -0700 (PDT) Message-Id: <200108031612.JAA18086@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: ru@freebsd.org Subject: Re: cvs commit: src/sys/netinet ip_output.c Cc: bde@zeta.org.au, kris@obsecurity.org, dcs@freebsd.org, net@freebsd.org References: <200107190710.f6J7AVl44738@freefall.freebsd.org> <20010719011806.A28830@xor.obsecurity.org> <20010719135423.G69276@sunbay.com> Date: Fri, 3 Aug 2001 09:12:52 -0700 Versions: dmail (solaris) 2.2j/makemail 2.9b Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >@@ -964,7 +957,7 @@ sendorfree: > /* clean ipsec history once it goes out of the node */ > ipsec_delaux(m); > #endif >- if (error == 0) { >+ if (error == 0 && ia) { > /* Record statistics for this interface address. */ > ia->ia_ifa.if_opackets++; > ia->ia_ifa.if_obytes += m->m_pkthdr.len; Sorry I missed this the first time we went through this. Putting the && ia here causes fragmented packets sent on interfaces without addresses to not be sent -- which is not really the right plan. I think the if (ia) belongs around the stats updates, but not around the ifp_output() call. Testing should include something like "% ping -I 0.0.0.1 -s 2000 224.0.0.1" (where the "1" is the ifindex of an up multicast-capable interface with no source address and "2000" is larger than its MTU), and running tcpdump to make sure those packets make it out. Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 3 9:18:12 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by hub.freebsd.org (Postfix) with ESMTP id A3EE137B408; Fri, 3 Aug 2001 09:18:07 -0700 (PDT) (envelope-from fenner@research.att.com) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id CC3B21E019; Fri, 3 Aug 2001 12:18:06 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id MAA13736; Fri, 3 Aug 2001 12:18:05 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id JAA18164; Fri, 3 Aug 2001 09:18:05 -0700 (PDT) Message-Id: <200108031618.JAA18164@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: oppermann@telehouse.ch Subject: Re: 303,000 routes in kernel Cc: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org Date: Fri, 3 Aug 2001 09:18:04 -0700 Versions: dmail (solaris) 2.2j/makemail 2.9b Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org What do the routes look like? Could they be a side effect of routing (e.g. default route pointing to the wrong router -> redirects, or default route pointing to the interface -> proxy arp for the whole world)? Can you send a sample few (don't need 303,000 =)? Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 3 9:58:33 2001 Delivered-To: freebsd-net@freebsd.org Received: from avengers.ivision.co.uk (avengers.ivision.co.uk [212.25.225.7]) by hub.freebsd.org (Postfix) with ESMTP id D1FC937B405; Fri, 3 Aug 2001 09:58:27 -0700 (PDT) (envelope-from jasper@ivision.co.uk) Received: from [212.25.225.7] (helo=avengers) by avengers.ivision.co.uk with esmtp (Exim 2.04 #1) id 15SiHK-00049h-00; Fri, 3 Aug 2001 17:58:26 +0100 Date: Fri, 3 Aug 2001 17:58:26 +0100 (BST) From: Jasper Wallace X-Sender: To: Andre Oppermann Cc: , Subject: Re: 303,000 routes in kernel In-Reply-To: <3B69CE3F.1BCCB280@telehouse.ch> Message-ID: X-NCC-RegID: uk.instant-web MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 3 Aug 2001, Andre Oppermann wrote: > Hello guys > > have got a small problem. I'm running a secondary DNS server for the > ccTLD .ch here in Switzerland. > # vmstat -m > Memory statistics by type Type Kern > Type InUse MemUse HighUse Limit Requests Limit Limit Size(s) > ... > routetbl607857 85480K 85480K 85480K 2420956 0 0 > 16,32,64,128,256 > ... > Memory Totals: In Use Free Requests > 91073K 2948K 786316696 If you want to wack up the amount of ram used for the routing table you can adjust the amount of ram the kernel uses for it's stuff with something like this in your kernel config file: # 1/2 RAM for the kernel - lets us have full routes. options VM_KMEM_SIZE_SCALE="(2)" If anyone knows a better way to persuade the kernel to use more space for the routing table i'd love to know. -- Internet Vision Internet Consultancy Tel: 020 7589 4500 60 Albert Court & Web development Fax: 020 7589 4522 Prince Consort Road vision@ivision.co.uk London SW7 2BE http://www.ivision.co.uk/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 3 10: 7:20 2001 Delivered-To: freebsd-net@freebsd.org Received: from purus.tcoip (cerberus.tcoip.com.br [200.220.254.3]) by hub.freebsd.org (Postfix) with ESMTP id A9C4437B407; Fri, 3 Aug 2001 10:07:11 -0700 (PDT) (envelope-from daniel.sobral@tcoip.com.br) Received: from tcoip.com.br (0bmygebhrjattr7q@dcs.intra.tcoip.com.br [192.168.60.194]) by purus.tcoip (8.11.1/8.11.1) with ESMTP id f73H4xA05095; Fri, 3 Aug 2001 14:04:59 -0300 Message-ID: <3B6AD9AD.10403@tcoip.com.br> Date: Fri, 03 Aug 2001 14:04:45 -0300 From: "Daniel C. Sobral" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.2) Gecko/20010705 X-Accept-Language: en, pt-br, ja MIME-Version: 1.0 To: Bill Fenner Cc: ru@FreeBSD.ORG, mjacob@FreeBSD.ORG, stable@FreeBSD.ORG Subject: Re: Request for testers: multicast patch References: <200108031553.IAA17847@windsor.research.att.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Bill Fenner wrote: > It looks like the patch causes packets not to be sent if > ia == 0. The inner part of the sendorfree: loop went from > > if (error == 0) { > update if stats > call if_output > } > > to > > if (error == 0 && ia) { > update ia stats > call if_output > } > > where I think it's more likely correct to do > > if (error == 0) { > if (ia) update ia state > call if_output > } > > I realize this bug was just introducd in rev 1.131, but let's not propogate > it to stable. Duh! This is plain wrong. Stable is correct and needs no patch, as evidenced by the patch itself: @@ -936,7 +942,7 @@ /* clean ipsec history once it goes out of the node */ ipsec_delaux(m); #endif - if (error == 0) { + if (error == 0 && ia) { /* Record statistics for this interface address. */ if (ia != NULL) { ia->ia_ifa.if_opackets++; You see that the statistics are _already_ checked for ia == NULL. In the other point where we added the check for ia == NULL on current stable was correct too, I just didn't notice it was correct on both places when I generated the patch. I just wonder when and why the test went out of the window on current. I'll fix it (the patch and current). -- Daniel C. Sobral (8-DCS) Daniel.Sobral@tcoip.com.br dcs@newsguy.com dcs@freebsd.org capo@notorious.bsdconspiracy.net Men of peace usually are [brave]. -- Spock, "The Savage Curtain", stardate 5906.5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 3 10:22:17 2001 Delivered-To: freebsd-net@freebsd.org Received: from purus.tcoip (cerberus.tcoip.com.br [200.220.254.3]) by hub.freebsd.org (Postfix) with ESMTP id 0B4DC37B40F; Fri, 3 Aug 2001 10:22:13 -0700 (PDT) (envelope-from daniel.sobral@tcoip.com.br) Received: from tcoip.com.br (sntt48v0q7osivhf@dcs.intra.tcoip.com.br [192.168.60.194]) by purus.tcoip (8.11.1/8.11.1) with ESMTP id f73HKoA05464; Fri, 3 Aug 2001 14:20:50 -0300 Message-ID: <3B6ADD66.8010009@tcoip.com.br> Date: Fri, 03 Aug 2001 14:20:38 -0300 From: "Daniel C. Sobral" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.2) Gecko/20010705 X-Accept-Language: en, pt-br, ja MIME-Version: 1.0 To: Bill Fenner Cc: ru@FreeBSD.org, bde@zeta.org.au, kris@obsecurity.org, dcs@FreeBSD.org, net@FreeBSD.org, Ian Dowse Subject: Re: cvs commit: src/sys/netinet ip_output.c References: <200107190710.f6J7AVl44738@freefall.freebsd.org> <20010719011806.A28830@xor.obsecurity.org> <20010719135423.G69276@sunbay.com> <200108031612.JAA18086@windsor.research.att.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Bill Fenner wrote: >>@@ -964,7 +957,7 @@ sendorfree: >> /* clean ipsec history once it goes out of the node */ >> ipsec_delaux(m); >>#endif >>- if (error == 0) { >>+ if (error == 0 && ia) { >> /* Record statistics for this interface address. */ >> ia->ia_ifa.if_opackets++; >> ia->ia_ifa.if_obytes += m->m_pkthdr.len; >> > > Sorry I missed this the first time we went through this. Putting the && > ia here causes fragmented packets sent on interfaces without addresses to > not be sent -- which is not really the right plan. I think the if (ia) > belongs around the stats updates, but not around the ifp_output() call. > > Testing should include something like "% ping -I 0.0.0.1 -s 2000 > 224.0.0.1" (where the "1" is the ifindex of an up multicast-capable > interface with no source address and "2000" is larger than its MTU), > and running tcpdump to make sure those packets make it out. Heh. I checked past revisions and discovered the correct tests were put in stable on revision 1.99.2.13, by Ian, but were never a part of current. I'll be merging this from stable. -- Daniel C. Sobral (8-DCS) Daniel.Sobral@tcoip.com.br dcs@newsguy.com dcs@freebsd.org capo@notorious.bsdconspiracy.net Show me a man who is a good loser and I'll show you a man who is playing golf with his boss. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 3 10:53:32 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by hub.freebsd.org (Postfix) with ESMTP id AED0537B403 for ; Fri, 3 Aug 2001 10:53:30 -0700 (PDT) (envelope-from fenner@research.att.com) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 8F9881E0A8; Fri, 3 Aug 2001 13:53:14 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id NAA16039; Fri, 3 Aug 2001 13:53:13 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id KAA19454; Fri, 3 Aug 2001 10:53:13 -0700 (PDT) Message-Id: <200108031753.KAA19454@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: itojun@iijlab.net Subject: Re: kernel upgrade causes truncated IPSEC packets Cc: mlnn4@oaks.com.au, freebsd-net@freebsd.org Date: Fri, 3 Aug 2001 10:53:13 -0700 Versions: dmail (solaris) 2.2j/makemail 2.9b Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > was the fix committed to sys/net/if_tun.c? i guess other *BSDs have > the same issue. I just committed it. If anyone is interested in tracking down the problem in the IPSEC stack, the problem only seems to occur when the data is in a cluster mbuf (thus Chris's observation that small packets get through). My observation was: mbuf 1: IP header mbuf 2: AH header mbuf 3: ESP header mbuf 4: 0 length mbuf 5: cluster mbuf containing data When the data mbuf is a small mbuf, mbuf 4 is not inserted. I will spend a little more time on this in the next couple of weeks but it might be better if someone more familiar with the IPSEC code could look at it. Itojun, if you'll be at the IETF perhaps we can get together and look at it there? Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 3 12: 1: 6 2001 Delivered-To: freebsd-net@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [24.14.150.180]) by hub.freebsd.org (Postfix) with ESMTP id D8C8837B401; Fri, 3 Aug 2001 12:00:59 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f73J0xM91833; Fri, 3 Aug 2001 12:00:59 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id A63933811; Fri, 3 Aug 2001 12:00:59 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Poul-Henning Kamp Cc: Andre Oppermann , freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: 303,000 routes in kernel In-Reply-To: <93100.996790166@critter> Date: Fri, 03 Aug 2001 12:00:59 -0700 From: Peter Wemm Message-Id: <20010803190059.A63933811@overcee.netplex.com.au> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Poul-Henning Kamp wrote: > In message <3B69CE3F.1BCCB280@telehouse.ch>, Andre Oppermann writes: > > >The problem I've got now is that for every packet I get the kernel is > >making one host entry in the routing table. Because of the many UDP > >DNS requests from all over the world I've got 303'000 (yes, three- > >hundredthreethousand) entries in the kernel routing table which have > >not expired yet. So I'm getting error messages like this now: > > Hmm, I wasn't aware that we cloned routes for UDP packets, are you sure > that is what is causing the routes to exists ? (Just to mention the > obvious: it's not CodeRed probes ?) Dont forget that DNS can query you over tcp as well.. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 3 13:39:15 2001 Delivered-To: freebsd-net@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id 532C537B407 for ; Fri, 3 Aug 2001 13:39:11 -0700 (PDT) (envelope-from itojun@itojun.org) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 5F9EC4B23; Sat, 4 Aug 2001 05:38:50 +0900 (JST) To: Bill Fenner Cc: mlnn4@oaks.com.au, freebsd-net@freebsd.org In-reply-to: fenner's message of Fri, 03 Aug 2001 10:53:13 MST. <200108031753.KAA19454@windsor.research.att.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: kernel upgrade causes truncated IPSEC packets From: itojun@iijlab.net Date: Sat, 04 Aug 2001 05:38:50 +0900 Message-ID: <4738.996871130@itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >> was the fix committed to sys/net/if_tun.c? i guess other *BSDs have >> the same issue. >I just committed it. >If anyone is interested in tracking down the problem in the IPSEC stack, >the problem only seems to occur when the data is in a cluster mbuf >(thus Chris's observation that small packets get through). My observation >was: >mbuf 1: IP header >mbuf 2: AH header >mbuf 3: ESP header >mbuf 4: 0 length >mbuf 5: cluster mbuf containing data this is perfectly legal, and can happen by result of m_cat()/m_split() calls from ipsec code. itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 3 14: 4:40 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by hub.freebsd.org (Postfix) with ESMTP id 7AB9037B407 for ; Fri, 3 Aug 2001 14:04:38 -0700 (PDT) (envelope-from fenner@research.att.com) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id C49DB4CE80; Fri, 3 Aug 2001 17:04:37 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id RAA21481; Fri, 3 Aug 2001 17:04:37 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id OAA22596; Fri, 3 Aug 2001 14:04:37 -0700 (PDT) Message-Id: <200108032104.OAA22596@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: itojun@iijlab.net Subject: Re: kernel upgrade causes truncated IPSEC packets Cc: freebsd-net@freebsd.org Date: Fri, 3 Aug 2001 14:04:36 -0700 Versions: dmail (solaris) 2.2j/makemail 2.9b Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > [0-length mbuf in the chain] is perfectly legal, and can happen > by result of m_cat()/m_split() calls from ipsec code. I don't see any m_cat() or m_split() happening on output; they're all in ah_input.c and esp_input.c . A 0-length mbuf in the chain is at best useless and perhaps fairly unexpected (thus the bug in if_tun.c lasting for 6.5 years before being found). Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 3 14: 7:23 2001 Delivered-To: freebsd-net@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id EBD3937B401 for ; Fri, 3 Aug 2001 14:07:21 -0700 (PDT) (envelope-from itojun@itojun.org) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id DFC934B21; Sat, 4 Aug 2001 06:07:20 +0900 (JST) To: Bill Fenner Cc: freebsd-net@freebsd.org In-reply-to: fenner's message of Fri, 03 Aug 2001 14:04:36 MST. <200108032104.OAA22596@windsor.research.att.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: kernel upgrade causes truncated IPSEC packets From: itojun@iijlab.net Date: Sat, 04 Aug 2001 06:07:20 +0900 Message-ID: <5032.996872840@itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >> [0-length mbuf in the chain] is perfectly legal, and can happen >> by result of m_cat()/m_split() calls from ipsec code. >I don't see any m_cat() or m_split() happening on output; they're all in >ah_input.c and esp_input.c . i need to go through the detail, but something equivalent to these functions happen everywhere in ipsec code. itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 3 18:26:35 2001 Delivered-To: freebsd-net@freebsd.org Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by hub.freebsd.org (Postfix) with ESMTP id 3C03937B401; Fri, 3 Aug 2001 18:26:28 -0700 (PDT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id KAA01541; Sat, 4 Aug 2001 10:28:44 +0900 (JST) Date: Sat, 04 Aug 2001 08:11:34 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Poul-Henning Kamp Cc: Andre Oppermann , freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: 303,000 routes in kernel In-Reply-To: <93100.996790166@critter> References: <3B69CE3F.1BCCB280@telehouse.ch> <93100.996790166@critter> User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 29 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >>>>> On Fri, 03 Aug 2001 00:09:26 +0200, >>>>> Poul-Henning Kamp said: >> The problem I've got now is that for every packet I get the kernel is >> making one host entry in the routing table. Because of the many UDP >> DNS requests from all over the world I've got 303'000 (yes, three- >> hundredthreethousand) entries in the kernel routing table which have >> not expired yet. So I'm getting error messages like this now: > Hmm, I wasn't aware that we cloned routes for UDP packets, are you sure > that is what is causing the routes to exists ? (Just to mention the > obvious: it's not CodeRed probes ?) Since udp_output calls in_pcbconnect(), which is shared with TCP and makes cloned host routes, unbound UDP socket can have such routes. However, I guess DNS server implementations do bind(2) specific addresses to UDP sockets, because they have to ensure an query's destination equals to a corresponding reply's source. So, I'd like to see the result of % netstat -f inet -an | grep 53 on the server node to see if the DNS server binds specific addresses. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 3 19:26: 6 2001 Delivered-To: freebsd-net@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id F0E5937B403; Fri, 3 Aug 2001 19:25:59 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id MAA18601; Sat, 4 Aug 2001 12:25:30 +1000 Date: Sat, 4 Aug 2001 12:23:04 +1000 (EST) From: Bruce Evans X-X-Sender: To: Brian Somers Cc: Julian Elischer , Thomas Pornin , , , Brian Somers , , Brian Somers Subject: Re: kern/27767: (was: PPPoE + Alpha + 32/64 bits) In-Reply-To: <200108022338.f72Nc6u09427@hak.lan.Awfulhak.org> Message-ID: <20010804121134.G16179-100000@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 3 Aug 2001, Brian Somers wrote: > > [bde wrote] > > Here I don't see how packing the struct helps on alphas. Doesn't it > > cause traps by misaligning uniqtag.data.pointer? I think you need > > something like: > > It doesn't cause a trap as the compiler is (now) smart enough to > handle it properly. Note where we have the alignment problem here: I guess it knows how to handle this in packed structs and not in many other cases. > > struct { > > struct pppoe_tag hdr; > > char data[sizeof(void *)]; > > } uniqtag; > > void *pointer; > > ... > > pointer = sp; > > memcpy(uniqtag.data, &pointer, sizeof(uniqtag.data)); > > That's probably better. I went with the __attribute((packed)) stuff > because it was already done that way in the rest of the code. I think the packed attributes in ng_pppoe.h are no-ops on most machines. > In this specific case however, it may be best to just send the variable > plus the alignment padding as the tag: > > struct { > struct pppoe_tag hdr; > union uniq data; > } uniqtag; > > ...... > uniqtag.hdr.tag_type = PTT_HOST_UNIQ; > uniqtag.hdr.tag_len = htons((u_int16_t)(sizeof(uniqtag) - sizeof(uniqtag.hdr)); > uniqtag.data.pointer = sp; You might also have to zero everything to ensure that there is no stack garbage in the message. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 3 22:52:44 2001 Delivered-To: freebsd-net@freebsd.org Received: from softweyr.com (softweyr.com [208.247.99.111]) by hub.freebsd.org (Postfix) with ESMTP id 1818A37B401 for ; Fri, 3 Aug 2001 22:52:42 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from blabber.softweyr.com ([204.68.178.36] helo=softweyr.com) by softweyr.com with esmtp (Exim 3.22 #1) id 15SuWO-000AI0-00; Sat, 04 Aug 2001 00:02:48 -0600 Message-ID: <3B6B8E8C.BE6F0FBF@softweyr.com> Date: Fri, 03 Aug 2001 23:56:28 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sjaak Jobses Cc: Stacey Roberts , freebsd-net@freebsd.org Subject: Re: FreeBSD V4.3 running on ABIT VP6 Dual Proc References: <3B699AC3.802104CA@dolfijntje.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Sjaak Jobses wrote: > > Stacey Roberts wrote: > > > > Hi Guys, > > I've just ordered FreeBSD V4.3, hoping to install it on a VP6 Dual proc > > system running two P111 933's. > > > > I've tried searching for known issues with this particular motherboard via > > all the search facilities at the FreeBSD sites, but cannot find any actual > > documentation on whether or not this motherboard is actually compatible with > > FreeBSD V4.3. > > > > Can any of you assist / advise? > > As long as the board will support the Intel MP (1.1?) specification, > I don't think it will be any problem. > Then again, I could be wrong... I have it's predecessory, the BP6; it has been running 4.x and 5.0 under SMP for just about a year without a hitch. Greg Lehey uses the same board for 5.0 development work. I'll be happy to trade for my BP6 with 2x Celeron 500 if you're unhappy. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 3 23: 6:44 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id A16F637B403 for ; Fri, 3 Aug 2001 23:06:41 -0700 (PDT) (envelope-from julian@elischer.org) Received: from elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id BAA54460; Sat, 4 Aug 2001 01:12:54 -0700 (PDT) Message-ID: <3B6B8DE2.ADC797FF@elischer.org> Date: Fri, 03 Aug 2001 22:53:38 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Jim Pirzyk Cc: freebsd-net@freebsd.org Subject: Re: ng_one2many usage References: <01080214563006.36347@snoopy> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Jim Pirzyk wrote: > > So I tried to use the one2many netgraph module, but I get errors > right away. Here is what I get: > > Jim.Pirzyk@snoopy:~ > 47>sudo ngctl -d mkpeer trnk0: one2many upper one > ngctl: sendto(trnk0:): No such file or directory > ngctl: send msg: No such file or directory > > Any ideas on what is going wrong? is there a node called trnk0: ? > > - JimP > > -- > --- @(#) $Id: dot.signature,v 1.10 2001/05/17 23:38:49 Jim.Pirzyk Exp $ > __o Jim.Pirzyk@disney.com ------------- pirzyk@freebsd.org > _'\<,_ Senior Systems Engineer, Walt Disney Feature Animation > (*)/ (*) > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Aug 4 2: 0:38 2001 Delivered-To: freebsd-net@freebsd.org Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by hub.freebsd.org (Postfix) with SMTP id 2763637B403 for ; Sat, 4 Aug 2001 02:00:35 -0700 (PDT) (envelope-from oppermann@telehouse.ch) Received: (qmail 68362 invoked from network); 4 Aug 2001 09:00:06 -0000 Received: from unknown (HELO telehouse.ch) ([62.48.21.234]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 4 Aug 2001 09:00:06 -0000 Message-ID: <3B6BB99C.ED16B804@telehouse.ch> Date: Sat, 04 Aug 2001 11:00:12 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: JINMEI@telehouse.ch, Tatuya@telehouse.ch, /@telehouse.ch, "$B?\"@L@C#:H"@FreeBSD.ORG Cc: Poul-Henning Kamp , freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: 303,000 routes in kernel References: <3B69CE3F.1BCCB280@telehouse.ch> <93100.996790166@critter> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org JINMEI Tatuya / $B?@L@C#:H(B wrote: > > >>>>> On Fri, 03 Aug 2001 00:09:26 +0200, > >>>>> Poul-Henning Kamp said: > > >> The problem I've got now is that for every packet I get the kernel is > >> making one host entry in the routing table. Because of the many UDP > >> DNS requests from all over the world I've got 303'000 (yes, three- > >> hundredthreethousand) entries in the kernel routing table which have > >> not expired yet. So I'm getting error messages like this now: > > > Hmm, I wasn't aware that we cloned routes for UDP packets, are you sure > > that is what is causing the routes to exists ? (Just to mention the > > obvious: it's not CodeRed probes ?) > > Since udp_output calls in_pcbconnect(), which is shared with TCP and > makes cloned host routes, unbound UDP socket can have such routes. > > However, I guess DNS server implementations do bind(2) specific > addresses to UDP sockets, because they have to ensure an query's > destination equals to a corresponding reply's source. So, I'd like to > see the result of > > % netstat -f inet -an | grep 53 Ok, here is the output: # netstat -f inet -an | grep 53 udp4 0 0 194.42.48.120.53 *.* > on the server node to see if the DNS server binds specific addresses. Yes, it does. > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp -- Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Aug 4 2: 2: 1 2001 Delivered-To: freebsd-net@freebsd.org Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by hub.freebsd.org (Postfix) with SMTP id D06AE37B407 for ; Sat, 4 Aug 2001 02:01:56 -0700 (PDT) (envelope-from oppermann@telehouse.ch) Received: (qmail 68388 invoked from network); 4 Aug 2001 09:01:28 -0000 Received: from unknown (HELO telehouse.ch) ([62.48.21.234]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 4 Aug 2001 09:01:28 -0000 Message-ID: <3B6BB9EF.1922470@telehouse.ch> Date: Sat, 04 Aug 2001 11:01:35 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Wemm Cc: Poul-Henning Kamp , freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: 303,000 routes in kernel References: <20010803190059.A63933811@overcee.netplex.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Peter Wemm wrote: > > Poul-Henning Kamp wrote: > > In message <3B69CE3F.1BCCB280@telehouse.ch>, Andre Oppermann writes: > > > > >The problem I've got now is that for every packet I get the kernel is > > >making one host entry in the routing table. Because of the many UDP > > >DNS requests from all over the world I've got 303'000 (yes, three- > > >hundredthreethousand) entries in the kernel routing table which have > > >not expired yet. So I'm getting error messages like this now: > > > > Hmm, I wasn't aware that we cloned routes for UDP packets, are you sure > > that is what is causing the routes to exists ? (Just to mention the > > obvious: it's not CodeRed probes ?) > > Dont forget that DNS can query you over tcp as well.. This machine (with djb tinydns) does not have tcp queries enabled. So this can't be the source of the route entries. -- Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Aug 4 2: 6:11 2001 Delivered-To: freebsd-net@freebsd.org Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by hub.freebsd.org (Postfix) with SMTP id 7005B37B403 for ; Sat, 4 Aug 2001 02:06:05 -0700 (PDT) (envelope-from oppermann@telehouse.ch) Received: (qmail 68525 invoked from network); 4 Aug 2001 09:05:37 -0000 Received: from unknown (HELO telehouse.ch) ([62.48.21.234]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 4 Aug 2001 09:05:37 -0000 Message-ID: <3B6BBAE7.D572B4CB@telehouse.ch> Date: Sat, 04 Aug 2001 11:05:43 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jasper Wallace Cc: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org Subject: Re: 303,000 routes in kernel References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Jasper Wallace wrote: > > On Fri, 3 Aug 2001, Andre Oppermann wrote: > > > Hello guys > > > > have got a small problem. I'm running a secondary DNS server for the > > ccTLD .ch here in Switzerland. > > > # vmstat -m > > Memory statistics by type Type Kern > > Type InUse MemUse HighUse Limit Requests Limit Limit Size(s) > > ... > > routetbl607857 85480K 85480K 85480K 2420956 0 0 > > 16,32,64,128,256 > > ... > > Memory Totals: In Use Free Requests > > 91073K 2948K 786316696 > > If you want to wack up the amount of ram used for the routing table you can > adjust the amount of ram the kernel uses for it's stuff with something like > this in your kernel config file: > > # 1/2 RAM for the kernel - lets us have full routes. > options VM_KMEM_SIZE_SCALE="(2)" > > If anyone knows a better way to persuade the kernel to use more space for > the routing table i'd love to know. On some machines that do routing and have a full view in the kernel I do this is in /boot/loader.conf: kern.vm.kmem.size="128000000" # Sets the size of kernel memory (bytes) But this is not very optimal because only half of the kernel memory can be used for the routing table. The other half (64MB here) is mostly empty. I'l like to know if there is a way to adjust this ratio in the kernel so I get 96MB for the routing table and 32MB for the kernel itself. -- Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Aug 4 4:16:38 2001 Delivered-To: freebsd-net@freebsd.org Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by hub.freebsd.org (Postfix) with SMTP id 0523D37B408 for ; Sat, 4 Aug 2001 04:16:32 -0700 (PDT) (envelope-from oppermann@telehouse.ch) Received: (qmail 75145 invoked from network); 4 Aug 2001 11:16:03 -0000 Received: from unknown (HELO telehouse.ch) ([62.48.21.221]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 4 Aug 2001 11:16:03 -0000 Message-ID: <3B6BD979.5BFD5890@telehouse.ch> Date: Sat, 04 Aug 2001 13:16:09 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bernd Walter Cc: freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: 303,000 routes in kernel References: <3B69CE3F.1BCCB280@telehouse.ch> <20010803114648.A2565@cicely20.cicely.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Bernd Walter wrote: > > On Fri, Aug 03, 2001 at 12:03:43AM +0200, Andre Oppermann wrote: > > The problem I've got now is that for every packet I get the kernel is > > making one host entry in the routing table. Because of the many UDP > > DNS requests from all over the world I've got 303'000 (yes, three- > > hundredthreethousand) entries in the kernel routing table which have > > not expired yet. So I'm getting error messages like this now: > > Are you shure that these are not created via redirects when sending > the packet? > You might try to disable acepting redirects via sysctl and/or > setting the routes so that packets have a better chance to be send > to the right router. I think we have a winner here! With icmp redirect turned off the box having only three routes, link, net and default. This box is directly connected to the TIX Internet Exchange with 45 ISP. Although it does not do BGP itself it has one of the BGP routers as it's default route. Depending on where the DNS request came from the BGP router simply sent an ICMP redirect so the box could send the reply packet directly to that ISP. Unfortunatly the redirects are host routes this is why the routing table got so big, otherwise it would have stopped at 105'000 routes which is still managable. -- Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Aug 4 7:23:53 2001 Delivered-To: freebsd-net@freebsd.org Received: from aussie.org (hallam.lnk.telstra.net [139.130.54.166]) by hub.freebsd.org (Postfix) with ESMTP id 7235A37B406 for ; Sat, 4 Aug 2001 07:23:47 -0700 (PDT) (envelope-from mlnn4@oaks.com.au) Received: from dualp2 (dualp2 [203.29.75.73]) by aussie.org (8.11.3/8.11.4) with SMTP id f74ENf306222 for ; Sun, 5 Aug 2001 00:23:41 +1000 (EST) (envelope-from mlnn4@oaks.com.au) Message-Id: <200108041423.f74ENf306222@aussie.org> From: "Chris" To: "freebsd-net" Date: Sun, 05 Aug 2001 00:22:12 +1000 Reply-To: "Chris" X-Mailer: PMMail 98 Standard (2.01.1600) For Windows NT (5.0.2195;2) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: Fw: kernel upgrade causes truncated IPSEC packets Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Friday, 3 August 2001 Itojun wrote: > i need to go through the detail, but something equivalent to > these functions happen everywhere in ipsec code. Well, I can say that as far as I can tell, we weren't getting 0-length mbufs from IPSEC a few months ago. It's a new occurance. -- Chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Aug 4 7:23:54 2001 Delivered-To: freebsd-net@freebsd.org Received: from aussie.org (hallam.lnk.telstra.net [139.130.54.166]) by hub.freebsd.org (Postfix) with ESMTP id 73B1C37B408 for ; Sat, 4 Aug 2001 07:23:47 -0700 (PDT) (envelope-from mlnn4@oaks.com.au) Received: from dualp2 (dualp2 [203.29.75.73]) by aussie.org (8.11.3/8.11.4) with SMTP id f74ENf306225 for ; Sun, 5 Aug 2001 00:23:41 +1000 (EST) (envelope-from mlnn4@oaks.com.au) Message-Id: <200108041423.f74ENf306225@aussie.org> From: "Chris" To: "freebsd-net" Date: Sun, 05 Aug 2001 00:23:21 +1000 Reply-To: "Chris" X-Mailer: PMMail 98 Standard (2.01.1600) For Windows NT (5.0.2195;2) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: kernel upgrade causes truncated IPSEC packets Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Friday, 3 August 2001 Bill Fenner wrote: > A 0-length mbuf in the chain is at best useless and perhaps fairly > unexpected (thus the bug in if_tun.c lasting for 6.5 years before > being found). Indeed. And I have to wonder how many other interfaces will have the same problem. IMO getting IPSEC to work well is hard enough as it is (if the feedback I get from from other folks is correct; I was fortunate that I had experience doing Cisco VPN's before I tackled the KAME ones) without having other problems like this in the way. Most folk would just give up if they faced a problem like this the first time they tried to use IPSEC. Goodness knows, -I- almost gave up, and I had the advantage of knowing that there was nothing wrong with my configuration ... I spent many, many hours chasing the problem to the point where I discovered it was in the PPP code. I know that in retrospect that sounds stupid (I should have dumped the PPP async stuff earlier), but since I could actually *see* the packets leaving the machine (blinkenlights on modem) and tcpdump also showed good packets, I simply refused to believe that the problem was inside the machine ... -- Chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Aug 4 9:28:36 2001 Delivered-To: freebsd-net@freebsd.org Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by hub.freebsd.org (Postfix) with ESMTP id 70B6837B401; Sat, 4 Aug 2001 09:28:29 -0700 (PDT) (envelope-from ticso@mail.cicely.de) Received: from mail.cicely.de (cicely20 [10.1.1.22]) by srv1.cosmo-project.de (8.11.0/8.11.0) with ESMTP id f74GSQV57935; Sat, 4 Aug 2001 18:28:26 +0200 (CEST) Received: (from ticso@localhost) by mail.cicely.de (8.11.0/8.11.0) id f74GSRw07311; Sat, 4 Aug 2001 18:28:27 +0200 (CEST) Date: Sat, 4 Aug 2001 18:28:26 +0200 From: Bernd Walter To: Andre Oppermann Cc: Bernd Walter , freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: 303,000 routes in kernel Message-ID: <20010804182825.A7176@cicely20.cicely.de> References: <3B69CE3F.1BCCB280@telehouse.ch> <20010803114648.A2565@cicely20.cicely.de> <3B6BD979.5BFD5890@telehouse.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B6BD979.5BFD5890@telehouse.ch>; from oppermann@telehouse.ch on Sat, Aug 04, 2001 at 01:16:09PM +0200 X-Operating-System: NetBSD cicely20.cicely.de 1.5 sparc Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, Aug 04, 2001 at 01:16:09PM +0200, Andre Oppermann wrote: > Bernd Walter wrote: > > > > On Fri, Aug 03, 2001 at 12:03:43AM +0200, Andre Oppermann wrote: > > > The problem I've got now is that for every packet I get the kernel is > > > making one host entry in the routing table. Because of the many UDP > > > DNS requests from all over the world I've got 303'000 (yes, three- > > > hundredthreethousand) entries in the kernel routing table which have > > > not expired yet. So I'm getting error messages like this now: > > > > Are you shure that these are not created via redirects when sending > > the packet? > > You might try to disable acepting redirects via sysctl and/or > > setting the routes so that packets have a better chance to be send > > to the right router. > > I think we have a winner here! With icmp redirect turned off the box > having only three routes, link, net and default. > > This box is directly connected to the TIX Internet Exchange with > 45 ISP. Although it does not do BGP itself it has one of the BGP > routers as it's default route. Depending on where the DNS request > came from the BGP router simply sent an ICMP redirect so the box > could send the reply packet directly to that ISP. Unfortunatly the > redirects are host routes this is why the routing table got so big, > otherwise it would have stopped at 105'000 routes which is still > managable. I have managed servers (proxy, dns and news) in similar configurations. You might think about exporting /16 and bigger routes via BGP or OSPF to the server. That way you don't need to have all packets go through your default- router. DNS servers are known to bring a good load on routers as the packets are usually small with a high rate. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Aug 4 9:46:44 2001 Delivered-To: freebsd-net@freebsd.org Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by hub.freebsd.org (Postfix) with SMTP id A0BA037B406 for ; Sat, 4 Aug 2001 09:46:37 -0700 (PDT) (envelope-from oppermann@telehouse.ch) Received: (qmail 88934 invoked from network); 4 Aug 2001 16:46:08 -0000 Received: from unknown (HELO telehouse.ch) ([62.48.21.214]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 4 Aug 2001 16:46:08 -0000 Message-ID: <3B6C26D6.FB006403@telehouse.ch> Date: Sat, 04 Aug 2001 18:46:14 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bernd Walter Cc: Andre Oppermann , freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: 303,000 routes in kernel References: <3B69CE3F.1BCCB280@telehouse.ch> <20010803114648.A2565@cicely20.cicely.de> <3B6BD979.5BFD5890@telehouse.ch> <20010804182825.A7176@cicely20.cicely.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Bernd Walter wrote: > > On Sat, Aug 04, 2001 at 01:16:09PM +0200, Andre Oppermann wrote: > > Bernd Walter wrote: > > > > > > On Fri, Aug 03, 2001 at 12:03:43AM +0200, Andre Oppermann wrote: > > > > The problem I've got now is that for every packet I get the kernel is > > > > making one host entry in the routing table. Because of the many UDP > > > > DNS requests from all over the world I've got 303'000 (yes, three- > > > > hundredthreethousand) entries in the kernel routing table which have > > > > not expired yet. So I'm getting error messages like this now: > > > > > > Are you shure that these are not created via redirects when sending > > > the packet? > > > You might try to disable acepting redirects via sysctl and/or > > > setting the routes so that packets have a better chance to be send > > > to the right router. > > > > I think we have a winner here! With icmp redirect turned off the box > > having only three routes, link, net and default. > > > > This box is directly connected to the TIX Internet Exchange with > > 45 ISP. Although it does not do BGP itself it has one of the BGP > > routers as it's default route. Depending on where the DNS request > > came from the BGP router simply sent an ICMP redirect so the box > > could send the reply packet directly to that ISP. Unfortunatly the > > redirects are host routes this is why the routing table got so big, > > otherwise it would have stopped at 105'000 routes which is still > > managable. > > I have managed servers (proxy, dns and news) in similar configurations. > You might think about exporting /16 and bigger routes via BGP or OSPF > to the server. I will be doing BGP on the box itself but not yet. > That way you don't need to have all packets go through your default- > router. DNS servers are known to bring a good load on routers as > the packets are usually small with a high rate. The router, a Foundry BigIron, is supposed to do gigabit routing at wirespeed, even with small packets. But who knows... ;-) Thanks -- Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Aug 4 12:55:41 2001 Delivered-To: freebsd-net@freebsd.org Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by hub.freebsd.org (Postfix) with ESMTP id CD39337B401; Sat, 4 Aug 2001 12:55:32 -0700 (PDT) (envelope-from ticso@mail.cicely.de) Received: from mail.cicely.de (cicely20 [10.1.1.22]) by srv1.cosmo-project.de (8.11.0/8.11.0) with ESMTP id f74JtTV58688; Sat, 4 Aug 2001 21:55:30 +0200 (CEST) Received: (from ticso@localhost) by mail.cicely.de (8.11.0/8.11.0) id f74JtUg07710; Sat, 4 Aug 2001 21:55:30 +0200 (CEST) Date: Sat, 4 Aug 2001 21:55:29 +0200 From: Bernd Walter To: Andre Oppermann Cc: Bernd Walter , freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: 303,000 routes in kernel Message-ID: <20010804215529.C7176@cicely20.cicely.de> References: <3B69CE3F.1BCCB280@telehouse.ch> <20010803114648.A2565@cicely20.cicely.de> <3B6BD979.5BFD5890@telehouse.ch> <20010804182825.A7176@cicely20.cicely.de> <3B6C26D6.FB006403@telehouse.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B6C26D6.FB006403@telehouse.ch>; from oppermann@telehouse.ch on Sat, Aug 04, 2001 at 06:46:14PM +0200 X-Operating-System: NetBSD cicely20.cicely.de 1.5 sparc Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, Aug 04, 2001 at 06:46:14PM +0200, Andre Oppermann wrote: > Bernd Walter wrote: > > That way you don't need to have all packets go through your default- > > router. DNS servers are known to bring a good load on routers as > > the packets are usually small with a high rate. > > The router, a Foundry BigIron, is supposed to do gigabit routing at > wirespeed, even with small packets. But who knows... ;-) Most big routers do softwarerouting and implement shortcuts in hardware. Unfortunately DNS packets have a compareable small short cut hit rate. That said - I don't know your Foundry router and it's base load. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Aug 4 13:23:46 2001 Delivered-To: freebsd-net@freebsd.org Received: from verdi.nethelp.no (verdi.nethelp.no [158.36.41.162]) by hub.freebsd.org (Postfix) with SMTP id 3C54137B403 for ; Sat, 4 Aug 2001 13:23:41 -0700 (PDT) (envelope-from sthaug@nethelp.no) Received: (qmail 32303 invoked by uid 1001); 4 Aug 2001 20:23:39 +0000 (GMT) To: ticso@mail.cicely.de Cc: oppermann@telehouse.ch, freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: 303,000 routes in kernel From: sthaug@nethelp.no In-Reply-To: Your message of "Sat, 4 Aug 2001 21:55:29 +0200" References: <20010804215529.C7176@cicely20.cicely.de> X-Mailer: Mew version 1.05+ on Emacs 19.34.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Sat, 04 Aug 2001 22:23:39 +0200 Message-ID: <32301.996956619@verdi.nethelp.no> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > The router, a Foundry BigIron, is supposed to do gigabit routing at > > wirespeed, even with small packets. But who knows... ;-) > > Most big routers do softwarerouting and implement shortcuts in hardware. > Unfortunately DNS packets have a compareable small short cut hit rate. I'm not sure what you mean by shortcut here. However, as far as I know most "big routers" do *not* use route caches, because it was found quite a while ago that these don't scale. There are plenty of "big routers" that can do line rate with minimum sized packets. Steinar Haug, Nethelp consulting, sthaug@nethelp.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Aug 4 15:23: 2 2001 Delivered-To: freebsd-net@freebsd.org Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by hub.freebsd.org (Postfix) with ESMTP id C90D437B401; Sat, 4 Aug 2001 15:22:54 -0700 (PDT) (envelope-from ticso@mail.cicely.de) Received: from mail.cicely.de (cicely20 [10.1.1.22]) by srv1.cosmo-project.de (8.11.0/8.11.0) with ESMTP id f74MMoV59520; Sun, 5 Aug 2001 00:22:51 +0200 (CEST) Received: (from ticso@localhost) by mail.cicely.de (8.11.0/8.11.0) id f74MMYI08015; Sun, 5 Aug 2001 00:22:34 +0200 (CEST) Date: Sun, 5 Aug 2001 00:22:33 +0200 From: Bernd Walter To: sthaug@nethelp.no Cc: ticso@mail.cicely.de, oppermann@telehouse.ch, freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: 303,000 routes in kernel Message-ID: <20010805002233.A7991@cicely20.cicely.de> References: <20010804215529.C7176@cicely20.cicely.de> <32301.996956619@verdi.nethelp.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <32301.996956619@verdi.nethelp.no>; from sthaug@nethelp.no on Sat, Aug 04, 2001 at 10:23:39PM +0200 X-Operating-System: NetBSD cicely20.cicely.de 1.5 sparc Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, Aug 04, 2001 at 10:23:39PM +0200, sthaug@nethelp.no wrote: > > > The router, a Foundry BigIron, is supposed to do gigabit routing at > > > wirespeed, even with small packets. But who knows... ;-) > > > > Most big routers do softwarerouting and implement shortcuts in hardware. > > Unfortunately DNS packets have a compareable small short cut hit rate. > > I'm not sure what you mean by shortcut here. However, as far as I know > most "big routers" do *not* use route caches, because it was found quite > a while ago that these don't scale. The routing "hardware" can't look into the full routing table because todays routing tables are serveral megabytes big. The hardware is definately getting some kind of most often used records. Yes hardware vendors don't call it route cache - but it's similar in concept beside that typical route caches are software and this "cache" is much faster hardware. > There are plenty of "big routers" that can do line rate with minimum > sized packets. No doubt about it - but after all it's still avoidable load on the router and lan. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Aug 4 15:41:50 2001 Delivered-To: freebsd-net@freebsd.org Received: from ussenterprise.ufp.org (ussenterprise.ufp.org [208.185.30.210]) by hub.freebsd.org (Postfix) with ESMTP id CDA0137B403; Sat, 4 Aug 2001 15:41:41 -0700 (PDT) (envelope-from bicknell@ussenterprise.ufp.org) Received: (from bicknell@localhost) by ussenterprise.ufp.org (8.11.1/8.11.1) id f74MejC87934; Sat, 4 Aug 2001 18:40:45 -0400 (EDT) (envelope-from bicknell) Date: Sat, 4 Aug 2001 18:40:45 -0400 From: Leo Bicknell To: Bernd Walter Cc: sthaug@nethelp.no, oppermann@telehouse.ch, freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: 303,000 routes in kernel Message-ID: <20010804184045.A87444@ussenterprise.ufp.org> Mail-Followup-To: Leo Bicknell , Bernd Walter , sthaug@nethelp.no, oppermann@telehouse.ch, freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG References: <20010804215529.C7176@cicely20.cicely.de> <32301.996956619@verdi.nethelp.no> <20010805002233.A7991@cicely20.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010805002233.A7991@cicely20.cicely.de>; from ticso@mail.cicely.de on Sun, Aug 05, 2001 at 12:22:33AM +0200 Organization: United Federation of Planets Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, Aug 05, 2001 at 12:22:33AM +0200, Bernd Walter wrote: > The routing "hardware" can't look into the full routing table because > todays routing tables are serveral megabytes big. We're rapidly getting off topic here, but for the record... Route caching has not delivered acceptable performance for "core" routers for some time. As the internet got larger and used more, the percentage of the total routing table that was in use (and hence cached) grew larger and larger, exhausing the smaller, faster cache memories. All of the current designs used in the core, and many of the edge designs as well keep the "full table" (distilled to the minimum amount of information to forward a packet) available to the hardware forwarding engine. This includes Cisco's GSR line, and Junipers M-series routers. While working differently, Cisco's 7200's and 3600's also do the "full table thing". Looking at next generation designs, all vendors agree the only designs that will work in the core are designs that will work. So, unless the packet needs local processing (eg ICMP pings) a packet is a packet is a packet to today's routers. -- Leo Bicknell - bicknell@ufp.org Systems Engineer - Internetworking Engineer - CCIE 3440 Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Aug 4 17:28: 8 2001 Delivered-To: freebsd-net@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id AC7EB37B401; Sat, 4 Aug 2001 17:28:02 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.4/8.11.2) id f750RkG77073; Sat, 4 Aug 2001 17:27:46 -0700 (PDT) (envelope-from dillon) Date: Sat, 4 Aug 2001 17:27:46 -0700 (PDT) From: Matt Dillon Message-Id: <200108050027.f750RkG77073@earth.backplane.com> To: Leo Bicknell Cc: Bernd Walter , sthaug@nethelp.no, oppermann@telehouse.ch, freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: 303,000 routes in kernel References: <20010804215529.C7176@cicely20.cicely.de> <32301.996956619@verdi.nethelp.no> <20010805002233.A7991@cicely20.cicely.de> <20010804184045.A87444@ussenterprise.ufp.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org :We're rapidly getting off topic here, but for the record... : :Route caching has not delivered acceptable performance for "core" :routers for some time. As the internet got larger and used more, :the percentage of the total routing table that was in use (and :hence cached) grew larger and larger, exhausing the smaller, faster :cache memories. : :All of the current designs used in the core, and many of the edge :designs as well keep the "full table" (distilled to the minimum :amount of information to forward a packet) available to the hardware :forwarding engine. This includes Cisco's GSR line, and Junipers :M-series routers. While working differently, Cisco's 7200's and :3600's also do the "full table thing". I agree re: the route cache concept. It's dead. As far as I know routers on the edge tend to have full route tables, but I was under the impression that modern core designs - that is, the routers in the middle of a network, tended to use more of a layer-2 tagged switching model. The incoming edge routers with the full route tables tag the packet, then intermediate routers switch the packet using the tag (and ignore the IP address), and then when the packet gets to the other edge of the network it gets run through a normal routing table again. This allows routers in the middle of the network to use simple array lookups / layer-2 switched designs which are much faster then full-route-table designs. -Matt :Looking at next generation designs, all vendors agree the only :designs that will work in the core are designs that will work. :So, unless the packet needs local processing (eg ICMP pings) :a packet is a packet is a packet to today's routers. : :-- :Leo Bicknell - bicknell@ufp.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Aug 4 17:55:55 2001 Delivered-To: freebsd-net@freebsd.org Received: from ussenterprise.ufp.org (ussenterprise.ufp.org [208.185.30.210]) by hub.freebsd.org (Postfix) with ESMTP id 8A75F37B401; Sat, 4 Aug 2001 17:55:50 -0700 (PDT) (envelope-from bicknell@ussenterprise.ufp.org) Received: (from bicknell@localhost) by ussenterprise.ufp.org (8.11.1/8.11.1) id f750stm94328; Sat, 4 Aug 2001 20:54:55 -0400 (EDT) (envelope-from bicknell) Date: Sat, 4 Aug 2001 20:54:55 -0400 From: Leo Bicknell To: Matt Dillon Cc: Leo Bicknell , Bernd Walter , sthaug@nethelp.no, oppermann@telehouse.ch, freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: 303,000 routes in kernel Message-ID: <20010804205455.A94273@ussenterprise.ufp.org> Mail-Followup-To: Leo Bicknell , Matt Dillon , Leo Bicknell , Bernd Walter , sthaug@nethelp.no, oppermann@telehouse.ch, freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG References: <20010804215529.C7176@cicely20.cicely.de> <32301.996956619@verdi.nethelp.no> <20010805002233.A7991@cicely20.cicely.de> <20010804184045.A87444@ussenterprise.ufp.org> <200108050027.f750RkG77073@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200108050027.f750RkG77073@earth.backplane.com>; from dillon@earth.backplane.com on Sat, Aug 04, 2001 at 05:27:46PM -0700 Organization: United Federation of Planets Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, Aug 04, 2001 at 05:27:46PM -0700, Matt Dillon wrote: > As far as I know routers on the edge tend to have full route > tables, but I was under the impression that modern core designs - that > is, the routers in the middle of a network, tended to use more of a > layer-2 tagged switching model. The incoming edge routers with the full > route tables tag the packet, then intermediate routers switch the packet > using the tag (and ignore the IP address), and then when the packet > gets to the other edge of the network it gets run through a normal routing > table again. This allows routers in the middle of the network to use > simple array lookups / layer-2 switched designs which are much faster > then full-route-table designs. This can be done. Some designs using MPLS implement this sort of routing, and some ATM based designs come close to this idea. That said, I'd venture about half of the largest ISP's still use plain old routing in the core, every router has a full table and does a layer 3 lookup. Of those that use MPLS and ATM, they probably only eliminate 10-25% of the layer-3 lookups through the network. It's the old cost problem, doing the full route table lookup is expensive (usually in high speed-ram), which impacts the cost of the edge box more than the core box. When you're spending $500k-2.5M on a core router, the fact that it has $100k of RAM vrs $70k of ram is just not your big worry. :-) -- Leo Bicknell - bicknell@ufp.org Systems Engineer - Internetworking Engineer - CCIE 3440 Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Aug 4 21:44:57 2001 Delivered-To: freebsd-net@freebsd.org Received: from opensrs.saignon.net (216-120-17-31.dsl.cust.tfb.com [216.120.17.31]) by hub.freebsd.org (Postfix) with ESMTP id 766BF37B401 for ; Sat, 4 Aug 2001 21:44:45 -0700 (PDT) (envelope-from tony@saignon.net) Received: from tsaignmobl (216-120-17-17.dsl.cust.tfb.com [216.120.17.17]) by opensrs.saignon.net (8.11.4/8.11.3) with SMTP id f754iad00628 for ; Sat, 4 Aug 2001 21:44:36 -0700 (PDT) (envelope-from tony@saignon.net) From: Tony Saign To: Subject: RE: PPP help! Date: Sat, 4 Aug 2001 21:44:30 -0700 Message-ID: <000001c11d69$5163a160$fcffa8c0@tsaignmobl> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <000001c11c3a$c23971b0$da0b010a@tsaignmobl> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I have a problem with dialing into a server. I can dial in from a Windows system, so I know the account is working. PPP seems to be rejecting IPX/SPX Aug 4 01:05:51 p3 ppp[398]: tun0: Phase: Unknown protocol 0x802b (Novell IPX Control Protocol) I was also getting the below: Aug 4 01:05:51 p3 ppp[398]: tun0: CCP: MPPE: Not usable without CHAP81 So, I added CHAP81 to ppp.conf, and now I am not receiving the CHAP81 errors. After authentication it starts rejecting the IPX/SPX packets, and the server hangs up on me. I installed mpd from the ports collection, and it also appears to have problems with IPX/SPX Shortly after a successfull authentication, it references rejections ^^ and the system hangs up on me. If anyone can offer me some advice I would greatly appreciate it!!!! I don't know what else to try!! Please reply off list, if I get it working I'll post the results. -Tony * -----Original Message----- * From: owner-freebsd-isp@freebsd.org * [mailto:owner-freebsd-isp@freebsd.org]On Behalf Of Tony Saign * Sent: Friday, August 03, 2001 9:39 AM * To: freebsd-isp@freebsd.org * Subject: PPP help! * * * Can anyone tell me what I need to do to get a PPP connection * working, I'm getting the below error message(s); * I included the whole log, in case someone can actually make * sense out of it... * The failure seems to occur on CHAP (it's a Windows NT server! * no wonder!), something about CHAP81 not supported? * Is there an upgrade for CHAP? I remember hearing something * about this on a Linux system. * * My system is FreeBSD 4.3 * Thanks in advance, * -Tony * * Aug 4 01:05:45 p3 ppp[398]: tun0: Chat: Received: CONNECT * 42666/ARQ/V90/LAPM/V42BIS^M * Aug 4 01:05:45 p3 ppp[398]: tun0: Phase: deflink: dial -> carrier * Aug 4 01:05:46 p3 ppp[398]: tun0: Phase: deflink: * /dev/cuaa0: CD detected * Aug 4 01:05:46 p3 ppp[398]: tun0: Phase: deflink: carrier -> login * Aug 4 01:05:46 p3 ppp[398]: tun0: Phase: deflink: login -> lcp * Aug 4 01:05:46 p3 ppp[398]: tun0: LCP: FSM: Using "deflink" * as a transport * Aug 4 01:05:46 p3 ppp[398]: tun0: LCP: deflink: State change * Initial --> Closed * Aug 4 01:05:46 p3 ppp[398]: tun0: LCP: deflink: State change * Closed --> Stopped * Aug 4 01:05:47 p3 ppp[398]: tun0: LCP: deflink: LayerStart * Aug 4 01:05:47 p3 ppp[398]: tun0: LCP: deflink: * SendConfigReq(1) state = Stopped * Aug 4 01:05:47 p3 ppp[398]: tun0: LCP: ACFCOMP[2] * Aug 4 01:05:47 p3 ppp[398]: tun0: LCP: PROTOCOMP[2] * Aug 4 01:05:47 p3 ppp[398]: tun0: LCP: ACCMAP[6] 0x00000000 * Aug 4 01:05:47 p3 ppp[398]: tun0: LCP: MRU[4] 1500 * Aug 4 01:05:47 p3 ppp[398]: tun0: LCP: MAGICNUM[6] 0xe3903dea * Aug 4 01:05:47 p3 ppp[398]: tun0: LCP: deflink: State change * Stopped --> Req-Sent * Aug 4 01:05:47 p3 ppp[398]: tun0: LCP: deflink: * RecvConfigReq(1) state = Req-Sent * Aug 4 01:05:47 p3 ppp[398]: tun0: LCP: MRU[4] 1500 * Aug 4 01:05:47 p3 ppp[398]: tun0: LCP: ACCMAP[6] 0x00000000 * Aug 4 01:05:47 p3 ppp[398]: tun0: LCP: MAGICNUM[6] 0xd8a2a2b2 * Aug 4 01:05:47 p3 ppp[398]: tun0: LCP: PROTOCOMP[2] * Aug 4 01:05:47 p3 ppp[398]: tun0: LCP: ACFCOMP[2] * Aug 4 01:05:47 p3 ppp[398]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) * Aug 4 01:05:47 p3 ppp[398]: tun0: LCP: deflink: * SendConfigAck(1) state = Req-Sent * Aug 4 01:05:47 p3 ppp[398]: tun0: LCP: MRU[4] 1500 * Aug 4 01:05:47 p3 ppp[398]: tun0: LCP: ACCMAP[6] 0x00000000 * Aug 4 01:05:47 p3 ppp[398]: tun0: LCP: MAGICNUM[6] 0xd8a2a2b2 * Aug 4 01:05:47 p3 ppp[398]: tun0: LCP: PROTOCOMP[2] * Aug 4 01:05:47 p3 ppp[398]: tun0: LCP: ACFCOMP[2] * Aug 4 01:05:47 p3 ppp[398]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) * Aug 4 01:05:47 p3 ppp[398]: tun0: LCP: deflink: State change * Req-Sent --> Ack-Sent * Aug 4 01:05:50 p3 ppp[398]: tun0: LCP: deflink: * SendConfigReq(1) state = Ack-Sent * Aug 4 01:05:50 p3 ppp[398]: tun0: LCP: ACFCOMP[2] * Aug 4 01:05:50 p3 ppp[398]: tun0: LCP: PROTOCOMP[2] * Aug 4 01:05:50 p3 ppp[398]: tun0: LCP: ACCMAP[6] 0x00000000 * Aug 4 01:05:50 p3 ppp[398]: tun0: LCP: MRU[4] 1500 * Aug 4 01:05:50 p3 ppp[398]: tun0: LCP: MAGICNUM[6] 0xe3903dea * Aug 4 01:05:50 p3 ppp[398]: tun0: LCP: deflink: * RecvConfigAck(1) state = Ack-Sent * Aug 4 01:05:50 p3 ppp[398]: tun0: LCP: deflink: State change * Ack-Sent --> Opened * Aug 4 01:05:50 p3 ppp[398]: tun0: LCP: deflink: LayerUp * Aug 4 01:05:50 p3 ppp[398]: tun0: Phase: bundle: Authenticate * Aug 4 01:05:50 p3 ppp[398]: tun0: Phase: deflink: his = PAP, * mine = none * Aug 4 01:05:50 p3 ppp[398]: tun0: Phase: Pap Output: trs004 ******** * Aug 4 01:05:51 p3 ppp[398]: tun0: Phase: Pap Input: SUCCESS * (Login Succeeded) * Aug 4 01:05:51 p3 ppp[398]: tun0: IPCP: Using trigger address 0.0.0.0 * Aug 4 01:05:51 p3 ppp[398]: tun0: CCP: FSM: Using "deflink" * as a transport * Aug 4 01:05:51 p3 ppp[398]: tun0: CCP: deflink: State change * Initial --> Closed * Aug 4 01:05:51 p3 ppp[398]: tun0: CCP: deflink: LayerStart. * Aug 4 01:05:51 p3 ppp[398]: tun0: CCP: MPPE: Not usable * without CHAP81 * Aug 4 01:05:51 p3 ppp[398]: tun0: CCP: deflink: * SendConfigReq(1) state = Closed * Aug 4 01:05:51 p3 ppp[398]: tun0: CCP: DEFLATE[4] win 15 * Aug 4 01:05:51 p3 ppp[398]: tun0: CCP: deflink: State change * Closed --> Req-Sent * Aug 4 01:05:51 p3 ppp[398]: tun0: Phase: deflink: lcp -> open * Aug 4 01:05:51 p3 ppp[398]: tun0: Phase: bundle: Network * Aug 4 01:05:51 p3 ppp[398]: tun0: IPCP: FSM: Using "deflink" * as a transport * Aug 4 01:05:51 p3 ppp[398]: tun0: IPCP: deflink: State * change Initial --> Closed * Aug 4 01:05:51 p3 ppp[398]: tun0: IPCP: deflink: LayerStart. * Aug 4 01:05:51 p3 ppp[398]: tun0: IPCP: deflink: * SendConfigReq(1) state = Closed * Aug 4 01:05:51 p3 ppp[398]: tun0: IPCP: IPADDR[6] 0.0.0.0 * Aug 4 01:05:51 p3 ppp[398]: tun0: IPCP: COMPPROTO[6] 16 VJ * slots with slot compression * Aug 4 01:05:51 p3 ppp[398]: tun0: IPCP: PRIDNS[6] 216.120.17.17 * Aug 4 01:05:51 p3 ppp[398]: tun0: IPCP: SECDNS[6] 216.120.17.17 * Aug 4 01:05:51 p3 ppp[398]: tun0: IPCP: deflink: State * change Closed --> Req-Sent * Aug 4 01:05:51 p3 ppp[398]: tun0: Phase: Unknown protocol * 0x802b (Novell IPX Control Protocol) * Aug 4 01:05:51 p3 ppp[398]: tun0: LCP: deflink: * SendProtocolRej(2) state = Opened * Aug 4 01:05:51 p3 ppp[398]: tun0: CCP: deflink: * RecvConfigRej(1) state = Req-Sent * Aug 4 01:05:51 p3 ppp[398]: tun0: CCP: DEFLATE[4] win 15 * Aug 4 01:05:51 p3 ppp[398]: tun0: CCP: MPPE: Not usable * without CHAP81 * Aug 4 01:05:51 p3 ppp[398]: tun0: CCP: deflink: * SendConfigReq(2) state = Req-Sent * Aug 4 01:05:51 p3 ppp[398]: tun0: CCP: [EMPTY] * Aug 4 01:05:51 p3 ppp[398]: tun0: CCP: deflink: * RecvConfigReq(1) state = Req-Sent * Aug 4 01:05:51 p3 ppp[398]: tun0: CCP: STAC[5] * Aug 4 01:05:51 p3 ppp[398]: tun0: CCP: deflink: * SendConfigRej(1) state = Req-Sent * Aug 4 01:05:51 p3 ppp[398]: tun0: CCP: STAC[5] * Aug 4 01:05:51 p3 ppp[398]: tun0: IPCP: deflink: * RecvConfigReq(1) state = Req-Sent * Aug 4 01:05:51 p3 ppp[398]: tun0: IPCP: COMPPROTO[6] 16 VJ * slots without slot compression * Aug 4 01:05:51 p3 ppp[398]: tun0: IPCP: IPADDR[6] 155.45.59.40 * Aug 4 01:05:51 p3 ppp[398]: tun0: IPCP: deflink: * SendConfigAck(1) state = Req-Sent * Aug 4 01:05:51 p3 ppp[398]: tun0: IPCP: COMPPROTO[6] 16 VJ * slots without slot compression * Aug 4 01:05:51 p3 ppp[398]: tun0: IPCP: IPADDR[6] 155.45.59.40 * Aug 4 01:05:51 p3 ppp[398]: tun0: IPCP: deflink: State * change Req-Sent --> Ack-Sent * Aug 4 01:05:54 p3 ppp[398]: tun0: IPCP: deflink: * SendConfigReq(1) state = Ack-Sent * Aug 4 01:05:54 p3 ppp[398]: tun0: IPCP: IPADDR[6] 0.0.0.0 * Aug 4 01:05:54 p3 ppp[398]: tun0: IPCP: COMPPROTO[6] 16 VJ * slots with slot compression * Aug 4 01:05:54 p3 ppp[398]: tun0: IPCP: PRIDNS[6] 216.120.17.17 * Aug 4 01:05:54 p3 ppp[398]: tun0: IPCP: SECDNS[6] 216.120.17.17 * Aug 4 01:05:54 p3 ppp[398]: tun0: CCP: MPPE: Not usable * without CHAP81 * Aug 4 01:05:54 p3 ppp[398]: tun0: CCP: deflink: * SendConfigReq(2) state = Req-Sent * Aug 4 01:05:54 p3 ppp[398]: tun0: CCP: [EMPTY] * Aug 4 01:05:54 p3 ppp[398]: tun0: IPCP: deflink: * RecvConfigReq(2) state = Ack-Sent * Aug 4 01:05:54 p3 ppp[398]: tun0: IPCP: COMPPROTO[6] 16 VJ * slots without slot compression * Aug 4 01:05:54 p3 ppp[398]: tun0: IPCP: IPADDR[6] 155.45.59.40 * Aug 4 01:05:54 p3 ppp[398]: tun0: IPCP: deflink: * SendConfigAck(2) state = Ack-Sent * Aug 4 01:05:54 p3 ppp[398]: tun0: IPCP: COMPPROTO[6] 16 VJ * slots without slot compression * Aug 4 01:05:54 p3 ppp[398]: tun0: IPCP: IPADDR[6] 155.45.59.40 * Aug 4 01:05:57 p3 ppp[398]: tun0: IPCP: deflink: * SendConfigReq(1) state = Ack-Sent * Aug 4 01:05:57 p3 ppp[398]: tun0: IPCP: IPADDR[6] 0.0.0.0 * Aug 4 01:05:57 p3 ppp[398]: tun0: IPCP: COMPPROTO[6] 16 VJ * slots with slot compression * Aug 4 01:05:57 p3 ppp[398]: tun0: IPCP: PRIDNS[6] 216.120.17.17 * Aug 4 01:05:57 p3 ppp[398]: tun0: IPCP: SECDNS[6] 216.120.17.17 * Aug 4 01:05:57 p3 ppp[398]: tun0: CCP: MPPE: Not usable * without CHAP81 * Aug 4 01:05:57 p3 ppp[398]: tun0: CCP: deflink: * SendConfigReq(2) state = Req-Sent * Aug 4 01:05:57 p3 ppp[398]: tun0: CCP: [EMPTY] * Aug 4 01:05:57 p3 ppp[398]: tun0: IPCP: deflink: * RecvConfigReq(3) state = Ack-Sent * Aug 4 01:05:57 p3 ppp[398]: tun0: IPCP: COMPPROTO[6] 16 VJ * slots without slot compression * Aug 4 01:05:57 p3 ppp[398]: tun0: IPCP: IPADDR[6] 155.45.59.40 * Aug 4 01:05:57 p3 ppp[398]: tun0: IPCP: deflink: * SendConfigAck(3) state = Ack-Sent * Aug 4 01:05:57 p3 ppp[398]: tun0: IPCP: COMPPROTO[6] 16 VJ * slots without slot compression * Aug 4 01:05:57 p3 ppp[398]: tun0: IPCP: IPADDR[6] 155.45.59.40 * Aug 4 01:06:00 p3 ppp[398]: tun0: IPCP: deflink: * SendConfigReq(1) state = Ack-Sent * Aug 4 01:06:00 p3 ppp[398]: tun0: IPCP: IPADDR[6] 0.0.0.0 * Aug 4 01:06:00 p3 ppp[398]: tun0: IPCP: COMPPROTO[6] 16 VJ * slots with slot compression * Aug 4 01:06:00 p3 ppp[398]: tun0: IPCP: PRIDNS[6] 216.120.17.17 * Aug 4 01:06:00 p3 ppp[398]: tun0: IPCP: SECDNS[6] 216.120.17.17 * Aug 4 01:06:00 p3 ppp[398]: tun0: CCP: MPPE: Not usable * without CHAP81 * Aug 4 01:06:00 p3 ppp[398]: tun0: CCP: deflink: * SendConfigReq(2) state = Req-Sent * Aug 4 01:06:00 p3 ppp[398]: tun0: CCP: [EMPTY] * Aug 4 01:06:01 p3 ppp[398]: tun0: IPCP: deflink: * RecvConfigReq(4) state = Ack-Sent * Aug 4 01:06:01 p3 ppp[398]: tun0: IPCP: COMPPROTO[6] 16 VJ * slots without slot compression * Aug 4 01:06:01 p3 ppp[398]: tun0: IPCP: IPADDR[6] 155.45.59.40 * Aug 4 01:06:01 p3 ppp[398]: tun0: IPCP: deflink: * SendConfigAck(4) state = Ack-Sent * Aug 4 01:06:01 p3 ppp[398]: tun0: IPCP: COMPPROTO[6] 16 VJ * slots without slot compression * Aug 4 01:06:01 p3 ppp[398]: tun0: IPCP: IPADDR[6] 155.45.59.40 * Aug 4 01:06:03 p3 ppp[398]: tun0: IPCP: deflink: * SendConfigReq(1) state = Ack-Sent * Aug 4 01:06:03 p3 ppp[398]: tun0: IPCP: IPADDR[6] 0.0.0.0 * Aug 4 01:06:03 p3 ppp[398]: tun0: IPCP: COMPPROTO[6] 16 VJ * slots with slot compression * Aug 4 01:06:03 p3 ppp[398]: tun0: IPCP: PRIDNS[6] 216.120.17.17 * Aug 4 01:06:03 p3 ppp[398]: tun0: IPCP: SECDNS[6] 216.120.17.17 * Aug 4 01:06:03 p3 ppp[398]: tun0: CCP: MPPE: Not usable * without CHAP81 * Aug 4 01:06:03 p3 ppp[398]: tun0: CCP: deflink: * SendConfigReq(2) state = Req-Sent * Aug 4 01:06:03 p3 ppp[398]: tun0: CCP: [EMPTY] * Aug 4 01:06:04 p3 ppp[398]: tun0: IPCP: deflink: * RecvConfigReq(5) state = Ack-Sent * Aug 4 01:06:04 p3 ppp[398]: tun0: IPCP: COMPPROTO[6] 16 VJ * slots without slot compression * Aug 4 01:06:04 p3 ppp[398]: tun0: IPCP: IPADDR[6] 155.45.59.40 * Aug 4 01:06:04 p3 ppp[398]: tun0: IPCP: deflink: * SendConfigAck(5) state = Ack-Sent * Aug 4 01:06:04 p3 ppp[398]: tun0: IPCP: COMPPROTO[6] 16 VJ * slots without slot compression * Aug 4 01:06:04 p3 ppp[398]: tun0: IPCP: IPADDR[6] 155.45.59.40 * Aug 4 01:06:06 p3 ppp[398]: tun0: IPCP: deflink: LayerFinish. * Aug 4 01:06:06 p3 ppp[398]: tun0: IPCP: Connect time: 15 * secs: 0 octets in, 0 octets out * Aug 4 01:06:06 p3 ppp[398]: tun0: IPCP: : 0 packets in, 0 packets out * Aug 4 01:06:06 p3 ppp[398]: tun0: IPCP: total 0 bytes/sec, * peak 0 bytes/sec on Sat Aug 4 01:06:06 2001 * Aug 4 01:06:06 p3 ppp[398]: tun0: IPCP: deflink: State * change Ack-Sent --> Stopped * Aug 4 01:06:06 p3 ppp[398]: tun0: Phase: bundle: Terminate * Aug 4 01:06:06 p3 ppp[398]: tun0: CCP: deflink: State change * Req-Sent --> Starting * Aug 4 01:06:06 p3 ppp[398]: tun0: CCP: deflink: LayerFinish. * Aug 4 01:06:06 p3 ppp[398]: tun0: CCP: deflink: State change * Starting --> Initial * Aug 4 01:06:06 p3 ppp[398]: tun0: LCP: deflink: LayerDown * Aug 4 01:06:06 p3 ppp[398]: tun0: LCP: deflink: * SendTerminateReq(2) state = Opened * Aug 4 01:06:06 p3 ppp[398]: tun0: LCP: deflink: State change * Opened --> Closing * Aug 4 01:06:06 p3 ppp[398]: tun0: Phase: deflink: open -> lcp * Aug 4 01:06:06 p3 ppp[398]: tun0: IPCP: deflink: State * change Stopped --> Closed * Aug 4 01:06:06 p3 ppp[398]: tun0: IPCP: deflink: State * change Closed --> Initial * Aug 4 01:06:06 p3 ppp[398]: tun0: LCP: deflink: * RecvTerminateAck(6), dropped (expected 2) * Aug 4 01:06:07 p3 ppp[398]: tun0: Phase: deflink: Carrier lost * Aug 4 01:06:07 p3 ppp[398]: tun0: LCP: deflink: LayerFinish * Aug 4 01:06:07 p3 ppp[398]: tun0: LCP: deflink: State change * Closing --> Initial * Aug 4 01:06:07 p3 ppp[398]: tun0: Phase: deflink: Disconnected! * Aug 4 01:06:07 p3 ppp[398]: tun0: Phase: deflink: lcp -> logout * Aug 4 01:06:07 p3 ppp[398]: tun0: Phase: deflink: Disconnected! * Aug 4 01:06:07 p3 ppp[398]: tun0: Phase: deflink: logout -> hangup * Aug 4 01:06:07 p3 ppp[398]: tun0: Phase: deflink: Connect * time: 45 secs: 501 octets in, 591 octets out * Aug 4 01:06:07 p3 ppp[398]: tun0: Phase: deflink: : 17 * packets in, 23 packets out * Aug 4 01:06:07 p3 ppp[398]: tun0: Phase: total 24 * bytes/sec, peak 127 bytes/sec on Sat Aug 4 01:06:07 2001 * Aug 4 01:06:07 p3 ppp[398]: tun0: Phase: deflink: hangup -> closed * Aug 4 01:06:07 p3 ppp[398]: tun0: Phase: bundle: Dead * Aug 4 01:06:13 p3 ppp[398]: tun0: Command: /dev/tty: q * Aug 4 01:06:13 p3 ppp[398]: tun0: Phase: PPP Terminated (normal). * * * * To Unsubscribe: send mail to majordomo@FreeBSD.org * with "unsubscribe freebsd-isp" in the body of the message * To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Aug 4 23: 4:41 2001 Delivered-To: freebsd-net@freebsd.org Received: from roam.psg.com (host217-33-136-77.ietf.ignite.net [217.33.136.77]) by hub.freebsd.org (Postfix) with ESMTP id D959D37B401; Sat, 4 Aug 2001 23:04:37 -0700 (PDT) (envelope-from randy@psg.com) Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15TGwI-0000bu-00; Sun, 05 Aug 2001 06:59:02 +0100 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Leo Bicknell Cc: freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: 303,000 routes in kernel References: <20010804215529.C7176@cicely20.cicely.de> <32301.996956619@verdi.nethelp.no> <20010805002233.A7991@cicely20.cicely.de> <20010804184045.A87444@ussenterprise.ufp.org> <200108050027.f750RkG77073@earth.backplane.com> Message-Id: Date: Sun, 05 Aug 2001 06:59:02 +0100 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > All of the current designs used in the core, and many of the edge > designs as well keep the "full table" (distilled to the minimum > amount of information to forward a packet) available to the hardware > forwarding engine. This includes Cisco's GSR line, and Junipers > M-series routers. While working differently, Cisco's 7200's and > 3600's also do the "full table thing". to be clear. they keep the *forwarding* table on card/in-cache, not the routing table. the ribs (for ospf, bgp, is-is, etc.) are kept on only the route processor, gated in our analog. randy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message