From owner-freebsd-net Sun Aug 6 5: 0:42 2000 Delivered-To: freebsd-net@freebsd.org Received: from happy.carrier.kiev.ua (happy.carrier.kiev.ua [193.193.192.209]) by hub.freebsd.org (Postfix) with ESMTP id 8369037BB6A for ; Sun, 6 Aug 2000 05:00:31 -0700 (PDT) (envelope-from gul@lucky.carrier.kiev.ua) Received: from lucky.carrier.kiev.ua (lucky.carrier.kiev.ua [193.193.192.212]) by happy.carrier.kiev.ua (8.The.Best/UUCP_FOREVER) with SMTP id PAA11084; Sun, 6 Aug 2000 15:00:32 +0300 (envelope-from gul@lucky.carrier.kiev.ua) Received: by lucky.carrier.kiev.ua (IBM OS/2 Sendmail v.2.02) id PAA265.57; Sun, 6 Aug 2000 15:00:30 +0300 Date: Sun, 6 Aug 2000 15:00:30 +0300 From: Pavel Gulchouck To: Tarik Alj Cc: freebsd-net@freebsd.org Subject: Re: VLAN MTU? 1500? 1504? Why? Message-ID: <20000806150029.A26345@lucky.carrier.kiev.ua> Reply-To: gul@gul.kiev.ua References: <200008041342.JAA05141@cholla.INRS-Telecom.UQuebec.CA> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.94.15i In-Reply-To: <200008041342.JAA05141@cholla.INRS-Telecom.UQuebec.CA>; from Tarik Alj on Fri, Aug 04, 2000 at 04:44:59PM +0300 X-Operating-System: OS/2 X-FTN-Address: 2:463/68 X-Flames-To: /dev/null X-GC: GCC d- s+: a29 C+++ UL++++ UB P+ L++ E--- W++ N++ o-- K- w--- O++ X-GC: M? V- PS PE+ Y+ PGP+ t? 5? X? R? !tv b+ DI? D? G e h--- r+++ y+++ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi! On Fri, Aug 04, 2000 at 04:44:59PM +0300, Tarik Alj writes: > >Louie, Thanks for your comments and for framing the question more > >clearly. > > > >Let's assume we do want to do 1500-byte frames on the virtual interfaces > >and go on to an ugly aspect of implementing it. > > > >Longer frames seem to require that the physical interface "know" that > >1504-byte frames should be allowed when the VLAN or 802.1p driver is > >above it but prohibited otherwise. Conversely, the VLAN driver should > >"ask" before assuming that the physical interface can handle the larger > >frames so that it can fail the open in those cases where the driver can't > >handle them? > > > >Is there any existing mechanism for "negotiation" of MTU between the > >physical layer and virtual layer? If not, should there be? I suppose we > >could crank the MTU of all physical interfaces up to whatever they can > >really handle instead of artificially limiting them to 1500 bytes, but > >that sounds icky. > > > >In short, it seem kind of gross to have to hack the source code of the > >physical driver when you intend to use it with a virtual driver above it. > >Is it worth making an elegant solution to this or should we just let the > >few who need longer frames continue futzing the source of the physical > >drivers? > > Well the actual solution isn't very elegant, is it? But there doesn't seem to be > a simple way to fix this. A _new_ MTU will require the existing drivers to be > modified anyways, but as things go more and more NICs should support 802.1Q > tagging. > > In my opinion VLANs are most useful (and were designed, I believe) for bridging > segments (that includes trunking), thus 802.1Q tagging should be done by the > bridge module. > > If you follow IEEE (a document that goes by the name P802.3ac/D3.1, "Frame > Extensions for VLAN Tagging on 802.3 Networks) it is the Ethernet frame that > gets bigger, not the IP packet that gets smaller. (my 2c :). Now I have 802.1Q trunk on FreeBSD 4.1-stable with Catalyst 3548. And I don't know how I can solve the MTU problem. 1500-bytes ping does not pass, but 1400-bytes does. 'ifconfig vlan0 mtu 1500' has no effect. 'ifconfig fxp0 mtu 1504' responds "Invalid argument". Catalyst says "% Interface FastEthernet0/2 does not support user settable mtu.". I cannot decrease ip mtu at all interfaces of all devices on the vlans in the network, because here's colocation servers. What should I do? And I found one curious feature: if I'm running tcpdump on fxp0, all packets passes ok. Without tcpdump they drops. Now I'm thinking about run tcpdump as daemon. ;-) Here's tcpdump out on vlan interface with running tcpdump on fxp0: 13:46:05.231569 zeus.call > isida.call: icmp: echo request (frag 13715:1472@0+) 13:46:05.231580 zeus.call > isida.call: (frag 13715:36@1472) 13:46:05.233872 isida.call > zeus.call: icmp: echo reply (frag 13715:1480@0+) 13:46:05.233880 isida.call > zeus.call: (frag 13715:28@1480) 13:46:06.241441 zeus.call > isida.call: icmp: echo request (frag 13738:1472@0+) 13:46:06.241450 zeus.call > isida.call: (frag 13738:36@1472) 13:46:06.243809 isida.call > zeus.call: icmp: echo reply (frag 13738:1480@0+) 13:46:06.243818 isida.call > zeus.call: (frag 13738:28@1480) 13:46:07.251321 zeus.call > isida.call: icmp: echo request (frag 13758:1472@0+) 13:46:07.251331 zeus.call > isida.call: (frag 13758:36@1472) 13:46:07.253628 isida.call > zeus.call: icmp: echo reply (frag 13758:1480@0+) 13:46:07.253636 isida.call > zeus.call: (frag 13758:28@1480) 13:46:08.261198 zeus.call > isida.call: icmp: echo request (frag 13777:1472@0+) 13:46:08.261207 zeus.call > isida.call: (frag 13777:36@1472) 13:46:08.263541 isida.call > zeus.call: icmp: echo reply (frag 13777:1480@0+) 13:46:08.263549 isida.call > zeus.call: (frag 13777:28@1480) And here's without dumping fxp0: 13:46:42.390477 zeus.call > isida.call: icmp: echo request (frag 14372:1472@0+) 13:46:42.390486 zeus.call > isida.call: (frag 14372:36@1472) 13:46:42.392800 isida.call > zeus.call: (frag 14372:28@1480) 13:46:43.397059 zeus.call > isida.call: icmp: echo request (frag 14397:1472@0+) 13:46:43.397065 zeus.call > isida.call: (frag 14397:36@1472) 13:46:43.399602 isida.call > zeus.call: (frag 14397:28@1480) 13:46:44.406963 zeus.call > isida.call: icmp: echo request (frag 14415:1472@0+) 13:46:44.406970 zeus.call > isida.call: (frag 14415:36@1472) 13:46:44.409305 isida.call > zeus.call: (frag 14415:28@1480) 13:46:45.411392 zeus.call > isida.call: icmp: echo request (frag 14434:1472@0+) 13:46:45.411399 zeus.call > isida.call: (frag 14434:36@1472) 13:46:45.413675 isida.call > zeus.call: (frag 14434:28@1480) 13:46:46.426710 zeus.call > isida.call: icmp: echo request (frag 14448:1472@0+) 13:46:46.426717 zeus.call > isida.call: (frag 14448:36@1472) 13:46:46.429018 isida.call > zeus.call: (frag 14448:28@1480) Zeus (FreeBSD) sends to isida (Cisco router) packets fragmented to 1472 bytes. Isida responds packets fragmented to 1480 bytes. This 1480-bytes packets drops without tcpdump and reaches the destination with tcpdump running. Ping between cisco routers via trunk link are always ok (mtu 1500). Any comments? gul@zeus;~>ifconfig fxp0 fxp0: flags=8843 mtu 1500 ether 00:d0:b7:60:67:7e media: autoselect (100baseTX ) status: active supported media: autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP gul@zeus;~>ifconfig vlan2 vlan2: flags=8843 mtu 1496 inet 10.0.1.1 netmask 0xffffff00 broadcast 10.0.1.255 ether 00:d0:b7:60:67:7e vlan: 1 parent interface: fxp0 -- Lucky carrier, Pavel To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Aug 6 13:30:28 2000 Delivered-To: freebsd-net@freebsd.org Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by hub.freebsd.org (Postfix) with ESMTP id 5EC9F37BA9D for ; Sun, 6 Aug 2000 13:30:24 -0700 (PDT) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.0) with SMTP id GAA19435 for ; Mon, 7 Aug 2000 06:30:21 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 7 Aug 2000 06:30:20 +1000 (EST) From: Ian Smith To: net@FreeBSD.org Subject: Intel 'Pro 4041' card? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org A local surplus store has a bunch of Intel ISA nics which were described as being marked 'Intel Pro 4041'. I haven't seen the cards yet, and on hunting through supported cards I'm not sure if it fits any description. Is this card supported (on 2.2.6 and/or 3.3)? If so, which driver? Any issues? Any good? Thanks, Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Aug 6 19:24:49 2000 Delivered-To: freebsd-net@freebsd.org Received: from wireco.net (mental.wireco.net [206.107.119.3]) by hub.freebsd.org (Postfix) with SMTP id EF26737B604 for ; Sun, 6 Aug 2000 19:24:46 -0700 (PDT) (envelope-from hornback@wireco.net) Received: (qmail 26953 invoked from network); 7 Aug 2000 02:24:44 -0000 Received: from d23.johnson-city.tn.us.wireco.net (HELO challenger) (206.107.119.212) by mental.wireco.net with SMTP; 7 Aug 2000 02:24:44 -0000 Reply-To: From: "Andrew C. Hornback" To: "'Ian Smith'" Cc: Subject: RE: Intel 'Pro 4041' card? Date: Sun, 6 Aug 2000 22:22:59 -0400 Message-ID: <002401c00016$680f5650$d4776bce@challenger> 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 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 In-Reply-To: Importance: Normal Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm not sure about Intel and their product numbers (being totally and completely enamored by SMC's network hardware myself), but, I'd imagine that if they're Ethernet and not Token Ring, the standard NE2000 driver would work. It seems to work for just about anything "generic"... --- Andy > -----Original Message----- > From: owner-freebsd-net@FreeBSD.ORG > [mailto:owner-freebsd-net@FreeBSD.ORG]On Behalf Of Ian Smith > Sent: Sunday, August 06, 2000 4:30 PM > To: net@FreeBSD.org > Subject: Intel 'Pro 4041' card? > > > A local surplus store has a bunch of Intel ISA nics which > were described > as being marked 'Intel Pro 4041'. I haven't seen the cards > yet, and on > hunting through supported cards I'm not sure if it fits any > description. > > Is this card supported (on 2.2.6 and/or 3.3)? If so, which > driver? Any > issues? Any good? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Aug 6 20:53: 7 2000 Delivered-To: freebsd-net@freebsd.org Received: from netplex.com.au (adsl-63-207-30-186.dsl.snfc21.pacbell.net [63.207.30.186]) by hub.freebsd.org (Postfix) with ESMTP id 0573237BC48 for ; Sun, 6 Aug 2000 20:53:01 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (peter@localhost [127.0.0.1]) by netplex.com.au (8.9.3/8.9.3) with ESMTP id UAA65444; Sun, 6 Aug 2000 20:52:41 -0700 (PDT) (envelope-from peter@netplex.com.au) Message-Id: <200008070352.UAA65444@netplex.com.au> X-Mailer: exmh version 2.1.1 10/15/1999 To: Archie Cobbs Cc: jayanth , freebsd-net@FreeBSD.ORG Subject: Re: Max data queued for UDP In-Reply-To: <200008030001.RAA28226@bubba.whistle.com> Date: Sun, 06 Aug 2000 20:52:41 -0700 From: Peter Wemm Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Archie Cobbs wrote: > jayanth writes: > > while running some tests for udp with very small packets(25 bytes) > > I found that the total amount of data that can be queued > > at the socket buffer(just queued, not read) is very limited, > > close to around 4k - 5k bytes. > > One of the issues is that the driver uses a cluster for > > every data packet, however small the data packet is. > > There is a per socket limit on the total amount of network > > memory that can be used for a socket (sb->sb_mbmax), which > > is typically 256k. There is also a variable that keeps > > count of the total n/w network memory actually used > > by the socket (sb->mb_cnt). The mb_cnt variable is > > incremented by a cluster + sizeof(mbuf) for every > > incoming packet. So for very small udp packets the total > > no. of packets that can be queued is > > sb_mbmax / (cluster + mbuf) = 256K / (2048 + 256) = 113 packets. > > At this point, the sbspace() macro declares that there is > > no space in the socket buffer, in terms of n/w memory. > > (sbmax - sb_mbcnt becomes -ve) > > > > TCP already has an sbcompress() and I have code that does > > the same for UDP. The code basically compresses the > > data from the cluster into the mbuf and frees the > > cluster, if the data fits in one mbuf. > > > > I am a little hesitant to do it in the driver code or > > the ether_input() code as it might do a copy for > > every protocol including tcp. > > > > feedback, please... > > IMHO, it makes sense to do it for UDP and raw sockets, but not > generically. TCP sockets generally copy the data in the recieve path to pack it into the socket buffers. UDP is the odd one out that enqueues the entire data mbuf (usually a cluster these days on a busmaster ethernet controller) and another mbuf for the address, and possibly a third mbuf for control data. For small UDP packets, this is hideously inefficient. Wasting a whole mbuf to hold a sockaddr_in (or sockaddr_in6) is terrible. Unconditionally wasting a whole mbuf+cluster (2.25K of KVM) to hold something like 50 bytes of data is pretty bad. Considering the advent of voice over IP (often UDP), we need a way to decide if or when to copy to a smaller object. Jayanth's patch pretty much does this. It moves the data from the cluster to the already-existing mbuf. A possible improvement might be to create a socket option or sysctl to specify a threshhold (or group of threshholds). Some sort of indicator about when to copy and when it is not worth it. > When you say "the driver uses a cluster for every data packet, > however small the data packet is" are you referring to a specific > Ethernet driver? If so then that driver is lame. It should at > least have two possibilities: (a) normal mbuf, and (b) cluster. > It's very easy and fast to make that minimal decision. Not when it is preallocated and the driver busmaster DMA's into a space provided by the driver. You cannot know in advance what the size of a packet will be. Some hardware has dual queues where you can use small and large inbound buffers and have the hardware choose an appropriate sized one. But this isn't available on most current 100baseT hardware. > -Archie 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 Sun Aug 6 21:45:54 2000 Delivered-To: freebsd-net@freebsd.org Received: from inetfw.sonycsl.co.jp (inetfw.SonyCSL.Co.Jp [203.137.129.4]) by hub.freebsd.org (Postfix) with ESMTP id 89F5537BA01 for ; Sun, 6 Aug 2000 21:45:47 -0700 (PDT) (envelope-from kjc@csl.sony.co.jp) Received: from hotaka.csl.sony.co.jp (hotaka.csl.sony.co.jp [43.27.98.57]) by inetfw.sonycsl.co.jp (8.9.3+3.2W/3.7Ws3/inetfw/2000050701) with ESMTP id NAA15292 for ; Mon, 7 Aug 2000 13:45:44 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by hotaka.csl.sony.co.jp (8.9.3+3.2W/3.7Ws3/hotaka/2000061722) with ESMTP id NAA08999 for ; Mon, 7 Aug 2000 13:45:44 +0900 (JST) To: freebsd-net@freebsd.org Subject: redesign of ifqueue in ALTQ X-Mailer: Mew version 1.94.2 on Emacs 20.6 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000807134544T.kjc@csl.sony.co.jp> Date: Mon, 07 Aug 2000 13:45:44 +0900 From: Kenjiro Cho X-Dispatcher: imput version 20000228(IM140) Lines: 62 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Following up a thread on drop-tail. I'm currently working on redesigning the ifqueue model from my 4-year experience with ALTQ. The new model tries to remove FIFO-queue assumptions from the BSD network code and drivers in order to accommodate various packet scheduler and queue management mechanisms. A brief summary of the design is attached below. The full text of the (still incomplete) design note is available from http://www.csl.sony.co.jp/~kjc/software/altq-new-design.txt The new model is already implemneted in the KAME development tree, and working code is available for FreeBSD-2.2.8/3.5/4.1, NetBSD-1.4.2 and OpenBSD-2.7 as a KAME snap kit. http://www.kame.net/ I'd like to hear comments and suggestions. (the copy of this message is sent to freebsd-net@freebsd.org, tech-net@netbsd.org, and tech@openbsd.org) -Kenjiro Notes on the new ALTQ implementation The BSD systems need better output queueing abstraction to support packet scheduling (e.g., CBQ) or active queue management (e.g., RED). To introduce a new model, we need to convert the existing code to be conformant to the new model. But the problem is that there are too many drivers to convert all at once. This is a proposal that allows incremental transition to the new model. (If we are going to modify the existing drivers, we need to get it right.) The model is designed for ALTQ but it is general enough for other implementations so that we can make the driver conversion once and for all. The new model removes direct references to the fields within ifp->if_snd, and defines the following macros to manipulate ifp->if_snd: IFQ_ENQUEUE(ifq, m, err) IFQ_DEQUEUE(ifq, m) IFQ_POLL(ifq, m) IFQ_PURGE(ifq) IFQ_IS_EMPTY(ifq) The new model also enforces some rules regarding how to use these macros. Another requirement for a driver is to work under rate-limiting. - IFQ_DEQUEUE() could return NULL even when IFQ_IS_EMPTY() is FALSE under rate-limiting. a driver should always check if (m == NULL). - a driver is supposed to call if_start from the tx complete interrupt under late-limiting (in order to trigger the next dequeue). For most drivers, it is a simple task of replacing old-style lines by the corresponding new-style lines, and usually just a few lines need to be modified. But some drivers need more than that. The old-style drivers still work with the original FIFO queue but they cannot take advantage of new queueing disciplines. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 7 0: 5:59 2000 Delivered-To: freebsd-net@freebsd.org Received: from pr.infosec.ru (pr.infosec.ru [194.135.141.98]) by hub.freebsd.org (Postfix) with ESMTP id 3BD3037B58E for ; Mon, 7 Aug 2000 00:05:51 -0700 (PDT) (envelope-from blaze@infosec.ru) Received: from xen.infosec.ru (WS_BLAZE [200.0.0.51]) by pr.infosec.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id QL1RKL7L; Mon, 7 Aug 2000 11:06:06 +0400 Date: Mon, 7 Aug 2000 11:07:31 +0400 (MSD) From: Andrey Sverdlichenko To: Archie Cobbs Cc: freebsd-net@FreeBSD.ORG Subject: Re: netgraph ethernet module In-Reply-To: <200008042300.QAA22438@bubba.whistle.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 4 Aug 2000, Archie Cobbs wrote: > Andrey Sverdlichenko writes: > > Are there any plans to develop ethernet encapsulation module for netgraph, > > something that can be inserted between ng_iface and ng_ether? > > Not a bad idea.. So, there is no currently work in progress, and i'll start a new one? > But really this should be separate module(s) for each protocol type. [skip] > IPX (0x8137) +---------------+ AppleTalk (0x809B) > ... ---------| ng_ether_mux |--------------- ... > +---------------+ > | > | > +-----------+ > | ng_ether | > +-----------+ Is there a way to get hardware address from ng_ether? ng_ether_mux must fill source address in ethernet header, and AFAIK the only way it can get it now is downstream->peer->node->private->ac_enaddr, which is dirty hack. Possibly a control message should be added to this node type? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 7 0:26:46 2000 Delivered-To: freebsd-net@freebsd.org Received: from gto.networkphysics.com (DNS1.networkphysics.com [63.194.71.40]) by hub.freebsd.org (Postfix) with ESMTP id 6F14C37B76C for ; Mon, 7 Aug 2000 00:26:43 -0700 (PDT) (envelope-from pavel@cutlass.networkphysics.com) Received: from cutlass.networkphysics.com (cutlass.networkphysics.com [10.1.0.21]) by gto.networkphysics.com (8.9.3/8.9.3) with ESMTP id AAA02758; Mon, 7 Aug 2000 00:26:09 -0700 (PDT) (envelope-from pavel@cutlass.networkphysics.com) Message-Id: <200008070726.AAA02758@gto.networkphysics.com> To: gul@gul.kiev.ua Cc: Tarik Alj , freebsd-net@FreeBSD.ORG Subject: Re: VLAN MTU? 1500? 1504? Why? In-Reply-To: Message from Pavel Gulchouck of "Sun, 06 Aug 2000 15:00:30 +0300." <20000806150029.A26345@lucky.carrier.kiev.ua> Date: Mon, 07 Aug 2000 00:26:09 -0700 From: Tom Pavel Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >>>>> On Sun, 6 Aug 2000, Pavel Gulchouck writes: > And I found one curious feature: if I'm running tcpdump on fxp0, > all packets passes ok. Without tcpdump they drops. Now I'm thinking > about run tcpdump as daemon. ;-) Just a pointer in case you haven't figured this one out yet: The fxp driver conditionalizes its acceptance of "invalid" ethernet packets on the promiscuous flag. Hence, with the interface in promiscuous mode, you will capture packets with CRC errors (I think), packets that are too short, and packets that are too long. static void fxp_init(xsc) void *xsc; { ... prm = (ifp->if_flags & IFF_PROMISC) ? 1 : 0; ... cbp->save_bf = prm; /* save bad frames */ ... /* * Start the config command/DMA. */ fxp_scb_wait(sc); CSR_WRITE_4(sc, FXP_CSR_SCB_GENERAL, vtophys(&cbp->cb_status)); CSR_WRITE_1(sc, FXP_CSR_SCB_COMMAND, FXP_SCB_COMMAND_CU_START); /* ...and wait for it to complete. */ while (!(cbp->cb_status & FXP_CB_STATUS_C)); ... It might be nice if the fxp driver exported a way to set these flags independently (i.e. cbp->save_bf, cbp->rcv_crc_xfer, cbp->disc_short_rx, and receiving long packets). I have not studied the other major ethernet drivers to see how the equivalent thing is done there. Obviously, link-layer bridging applications will need to pass (and interpret) the long encapsulated VLAN packets, but will want to drop runts and CRC-errors efficiently. Tom Pavel Network Physics Inc. pavel@networkphysics.com / pavel@alum.mit.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 7 1:11:46 2000 Delivered-To: freebsd-net@freebsd.org Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by hub.freebsd.org (Postfix) with ESMTP id C35BA37BD31 for ; Mon, 7 Aug 2000 01:11:44 -0700 (PDT) (envelope-from vivek@cs.rice.edu) Received: (from vivek@localhost) by cs.rice.edu (8.9.0/8.9.0) id DAA14294 for freebsd-net@freebsd.org; Mon, 7 Aug 2000 03:11:43 -0500 (CDT) Date: Mon, 7 Aug 2000 03:11:43 -0500 (CDT) From: Vivek Sadananda Pai Message-Id: <200008070811.DAA14294@cs.rice.edu> To: freebsd-net@freebsd.org Subject: apparently FreeBSD-specific DNS failure Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm trying to track down a DNS lookup failure that seems to be specific to FreeBSD. The site in question is www.wtime.net. Doing an nslookup on it is fine, but gethostbyname and getaddrinfo both fail on this - telnet fails, for example. I've tried with Solaris and Tru64, and both of them seem to have no problem. Any help would be greatly appreciated. Thanks, Vivek To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 7 1:20:31 2000 Delivered-To: freebsd-net@freebsd.org Received: from euitt.upm.es (haddock.euitt.upm.es [138.100.52.102]) by hub.freebsd.org (Postfix) with ESMTP id E97AE37BD2B for ; Mon, 7 Aug 2000 01:20:15 -0700 (PDT) (envelope-from pjlobo@euitt.upm.es) Received: from deneb.euitt.upm.es (deneb.euitt.upm.es [138.100.52.12]) by euitt.upm.es (8.9.3/8.9.3) with ESMTP id KAA11581; Mon, 7 Aug 2000 10:19:47 +0200 (MET DST) Date: Mon, 7 Aug 2000 10:19:47 +0200 (CEST) From: "Pedro J. Lobo" To: Bob Van Valzah Cc: freebsd-net@FreeBSD.ORG Subject: Re: VLAN Config Advice In-Reply-To: <398C491E.D7ED5E9F@WhiteBarn.Com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 5 Aug 2000, Bob Van Valzah wrote: > I'm having trouble getting VLANs to work on a 4.1-RELEASE system and > would appreciate any advice from those who have it running. (If I'm able > to get a decent understanding of the issues involved, I may even tackle > writing a section for the Handbook on VLANs.) > > Here's the setup. The physical device is fxp0. I have not applied any > patches to the physical driver for larger MTUs. > > If I don't ifconfig fxp0 and try to go straight to an ifconfig of vlan0, > the kernel panics. (I haven't looked at why yet, but probably could if > somebody thought it'd help.) This a snippet from my rc.conf: network_interfaces="fxp0 vlan0 vlan1 vlan2 lo0" ifconfig_fxp0="up" ifconfig_vlan0="inet 138.100.52.12 netmask 255.255.255.128 vlan 33 vlandev fxp0" ifconfig_vlan1="inet 138.100.52.182 netmask 255.255.255.192 vlan 34 vlandev fxp0" ifconfig_vlan2="inet 10.0.52.112 netmask 255.255.255.0 vlan 1 vlandev fxp0" And it works like a charm. > If I do ifconfig fxp0 first and then ifconfig vlan0 on top of it, I get > a booted system. However, arp issues lots of warning messages about > packets arriving on fxp0 when they should be on vlan0 and I can't ping > the box. Hmmm, I've been using simultaneously fxp0 (i.e., without tag) and vlan0 (tagged, hooked on fxp0) without any problems. Are you sure you are configuring fxp1 and vlan0 with addresses that are on different subnets? Cheers, Pedro. -- --------------------------------------------------------------------- Pedro José Lobo Perea Tel: +34 91 336 78 19 Centro de Cálculo Fax: +34 91 331 92 29 E.U.I.T. Telecomunicación e-mail: pjlobo@euitt.upm.es Universidad Politécnica de Madrid Ctra. de Valencia, Km. 7 E-28031 Madrid - España / Spain To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 7 1:48:41 2000 Delivered-To: freebsd-net@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 4844A37BD32; Mon, 7 Aug 2000 01:48:38 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from localhost (kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id BAA34593; Mon, 7 Aug 2000 01:48:38 -0700 (PDT) (envelope-from kris@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs Date: Mon, 7 Aug 2000 01:48:38 -0700 (PDT) From: Kris Kennaway To: Vivek Sadananda Pai Cc: freebsd-net@freebsd.org Subject: Re: apparently FreeBSD-specific DNS failure In-Reply-To: <200008070811.DAA14294@cs.rice.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 7 Aug 2000, Vivek Sadananda Pai wrote: > I'm trying to track down a DNS lookup failure that seems to be > specific to FreeBSD. The site in question is www.wtime.net. Doing an > nslookup on it is fine, but gethostbyname and getaddrinfo both fail on > this - telnet fails, for example. You neglected to mention which version of FreeBSD. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 7 2: 3:45 2000 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 BF68237BD43 for ; Mon, 7 Aug 2000 02:03:40 -0700 (PDT) (envelope-from sthaug@nethelp.no) Received: (qmail 71463 invoked by uid 1001); 7 Aug 2000 09:03:38 +0000 (GMT) To: vivek@cs.rice.edu Cc: freebsd-net@freebsd.org Subject: Re: apparently FreeBSD-specific DNS failure From: sthaug@nethelp.no In-Reply-To: Your message of "Mon, 7 Aug 2000 03:11:43 -0500 (CDT)" References: <200008070811.DAA14294@cs.rice.edu> X-Mailer: Mew version 1.05+ on Emacs 19.34.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Mon, 07 Aug 2000 11:03:38 +0200 Message-ID: <71461.965639018@verdi.nethelp.no> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I'm trying to track down a DNS lookup failure that seems to be > specific to FreeBSD. The site in question is www.wtime.net. Doing an > nslookup on it is fine, but gethostbyname and getaddrinfo both fail on > this - telnet fails, for example. > > I've tried with Solaris and Tru64, and both of them seem to have no > problem. Any help would be greatly appreciated. wtime.net has an inconsistent DNS configuration, and you should *expect* something to fail. From the .net name servers: wtime.net. 2D IN NS NS.JCITY.NET. wtime.net. 2D IN NS NS.wtime.net. NS.JCITY.NET. 2D IN A 210.217.192.1 NS.wtime.net. 2D IN A 211.116.92.5 Asking 210.217.192.1, we find only *one* name server: wtime.net. 1H IN NS ns.wtime.net. ns.wtime.net. 1H IN CNAME tdc_srv1.wtime.net. tdc_srv1.wtime.net. 1H IN A 211.116.92.5 and it is an alias - which is illegal. The name server at 211.116.92.5 responds the same way. Fix the DNS configuration - and if FreeBSD *still* fails we can investigate. 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 Mon Aug 7 2: 8:30 2000 Delivered-To: freebsd-net@freebsd.org Received: from iclub.nsu.ru (iclub.nsu.ru [193.124.222.66]) by hub.freebsd.org (Postfix) with ESMTP id 7662F37BD55; Mon, 7 Aug 2000 02:07:35 -0700 (PDT) (envelope-from fjoe@iclub.nsu.ru) Received: from localhost (fjoe@localhost) by iclub.nsu.ru (8.9.3/8.9.3) with ESMTP id QAA00737; Mon, 7 Aug 2000 16:07:11 +0700 (NSS) (envelope-from fjoe@iclub.nsu.ru) Date: Mon, 7 Aug 2000 16:07:11 +0700 (NSS) From: Max Khon To: Kris Kennaway Cc: Vivek Sadananda Pai , freebsd-net@FreeBSD.org Subject: Re: apparently FreeBSD-specific DNS failure In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org hi, there! On Mon, 7 Aug 2000, Kris Kennaway wrote: > > I'm trying to track down a DNS lookup failure that seems to be > > specific to FreeBSD. The site in question is www.wtime.net. Doing an > > nslookup on it is fine, but gethostbyname and getaddrinfo both fail on > > this - telnet fails, for example. > > You neglected to mention which version of FreeBSD. at least 4.1-STABLE (1 Aug) /fjoe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 7 3:11:23 2000 Delivered-To: freebsd-net@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 3312337B5D2; Mon, 7 Aug 2000 03:11:20 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from localhost (kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id DAA47204; Mon, 7 Aug 2000 03:11:20 -0700 (PDT) (envelope-from kris@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs Date: Mon, 7 Aug 2000 03:11:20 -0700 (PDT) From: Kris Kennaway To: Vivek Sadananda Pai Cc: freebsd-net@freebsd.org Subject: Re: apparently FreeBSD-specific DNS failure In-Reply-To: <200008070811.DAA14294@cs.rice.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 7 Aug 2000, Vivek Sadananda Pai wrote: > I'm trying to track down a DNS lookup failure that seems to be > specific to FreeBSD. The site in question is www.wtime.net. Doing an > nslookup on it is fine, but gethostbyname and getaddrinfo both fail on > this - telnet fails, for example. Okay, I found it.. ;; ANSWER SECTION: www.wtime.net. 49M IN CNAME tdc_srv1.wtime.net. tdc_srv1.wtime.net. 49M IN A 211.116.92.5 '_' is not a valid character for DNS host names. The FreeBSD resolver correctly (i.e. following the RFC) refuses to perform an invalid address query. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 7 6:15:45 2000 Delivered-To: freebsd-net@freebsd.org Received: from procsys.com (PPP-180-236.bng.vsnl.net.in [203.197.180.236]) by hub.freebsd.org (Postfix) with SMTP id 0843837B7B4 for ; Mon, 7 Aug 2000 06:15:36 -0700 (PDT) (envelope-from pran@procsys.com) Received: from procsys.com ([192.168.1.115]) by procsys.com with SMTP; Mon, 07 Aug 2000 18:48:05 +0800 Message-ID: <398EB732.2EFFFFB6@procsys.com> Date: Mon, 07 Aug 2000 18:48:42 +0530 From: Pran Joseph Reply-To: pran@procsys.com Organization: Processor Systems (India) Pvt. Ltd X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Newbie:Ethernet Driver References: <200008070811.DAA14294@cs.rice.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I am new to freebsd driver. I am trying to write a PCI ethernet driver for freebsd 3.4 . Can any of you point to some documentation or some links that will help me in writing the driver. -Pran Joseph pran@procsys.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 7 6:21:46 2000 Delivered-To: freebsd-net@freebsd.org Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by hub.freebsd.org (Postfix) with ESMTP id B2EEF37B78C for ; Mon, 7 Aug 2000 06:21:42 -0700 (PDT) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.0) with SMTP id XAA13757; Mon, 7 Aug 2000 23:21:32 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 7 Aug 2000 23:21:31 +1000 (EST) From: Ian Smith To: "Andrew C. Hornback" Cc: freebsd-net@FreeBSD.ORG Subject: RE: Intel 'Pro 4041' card? In-Reply-To: <002401c00016$680f5650$d4776bce@challenger> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 6 Aug 2000, Andrew C. Hornback wrote: > I'm not sure about Intel and their product numbers (being totally and > completely enamored by SMC's network hardware myself), but, I'd imagine that > if they're Ethernet and not Token Ring, the standard NE2000 driver would > work. It seems to work for just about anything "generic"... > > --- Andy Thanks Andy. I could just try using the ed driver and see what happens, but I'd like to be a bit more sure before bolting in a new card. Guess I'll troll Intel's website after work and see what I can find. Cheers, Ian > > -----Original Message----- [.. trimmed ..] > > A local surplus store has a bunch of Intel ISA nics which > > were described > > as being marked 'Intel Pro 4041'. I haven't seen the cards > > yet, and on > > hunting through supported cards I'm not sure if it fits any > > description. > > > > Is this card supported (on 2.2.6 and/or 3.3)? If so, which > > driver? Any > > issues? Any good? [..] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 7 6:29:28 2000 Delivered-To: freebsd-net@freebsd.org Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by hub.freebsd.org (Postfix) with ESMTP id 4210137B796 for ; Mon, 7 Aug 2000 06:29:26 -0700 (PDT) (envelope-from vivek@cs.rice.edu) Received: (from vivek@localhost) by cs.rice.edu (8.9.0/8.9.0) id IAA17333 for freebsd-net@freebsd.org; Mon, 7 Aug 2000 08:29:25 -0500 (CDT) Date: Mon, 7 Aug 2000 08:29:25 -0500 (CDT) From: Vivek Sadananda Pai Message-Id: <200008071329.IAA17333@cs.rice.edu> To: freebsd-net@freebsd.org Subject: Re: apparently FreeBSD-specific DNS failure Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have to say that I'm floored by the speed of all of your answers. I've never received answers so quickly. Thank you all very much. If I may make a suggestion - I don't know how much flexibility there is to change error codes for gethostbyname and getaddrinfo. I realize this may be governed by some common spec and is therefore undoable. However, if there is some flexibility in the matter, and if FreeBSD can determine that these records are improper, it would be nice to have an extra error code to handle this case. The error in getaddrinfo was EAI_FAIL and it was the "unknown" case when I called hstrerror after gethostbyname. Barring that, if there's any way to have the lookup work even in the case of improper setup, that might also have some merit. I realize it's a debatable proposition since it's better to have the records fixed by the owner. Still, it's one of those things where people may not ask for help, but will erroneously conclude that something is wrong with FreeBSD. I'll pass on the responses to the site's owner and see if it gets fixed. Thanks again, Vivek To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 7 6:37: 0 2000 Delivered-To: freebsd-net@freebsd.org Received: from mgw1.MEIway.com (mgw1.meiway.com [212.73.210.75]) by hub.freebsd.org (Postfix) with ESMTP id 2ED9237B659 for ; Mon, 7 Aug 2000 06:36:57 -0700 (PDT) (envelope-from lconrad@Go2France.com) Received: from mail.Go2France.com (ms1.meiway.com [212.73.210.73]) by mgw1.MEIway.com (Postfix Relay Hub) with ESMTP id DCF256A907 for ; Mon, 7 Aug 2000 15:37:15 +0200 (CEST) Received: from sv.Go2France.com [212.73.210.79] by mail.Go2France.com with ESMTP (SMTPD32-6.04) id ABC47E30278; Mon, 07 Aug 2000 15:38:12 +0200 Message-Id: <4.3.2.7.2.20000807153427.029b3de0@mail.Go2France.com> X-Sender: lconrad%Go2France.com@mail.Go2France.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 07 Aug 2000 15:37:47 +0200 To: freebsd-net@freebsd.org From: Len Conrad Subject: Re: apparently FreeBSD-specific DNS failure In-Reply-To: <200008071329.IAA17333@cs.rice.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >I have to say that I'm floored by the speed of all of your >answers. I've never received answers so quickly. So many DNS zones are so badly, so blatantly screwed up, finding DSN pb's is like shooting fish in a barrel, even if shooting from the hip. Plus the barrel is in full public view: a public DNS server. Len http://BIND8NT.MEIway.com: ISC BIND 8.2.2 p5 installable binary for NT4 http://IMGate.MEIway.com: Build free, hi-perf, anti-spam mail gateways To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 7 7: 7:58 2000 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 2BFAB37BBDF for ; Mon, 7 Aug 2000 07:07:55 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id KAA08680; Mon, 7 Aug 2000 10:07:45 -0400 (EDT) (envelope-from wollman) Date: Mon, 7 Aug 2000 10:07:45 -0400 (EDT) From: Garrett Wollman Message-Id: <200008071407.KAA08680@khavrinen.lcs.mit.edu> To: Kenjiro Cho Cc: freebsd-net@FreeBSD.ORG Subject: redesign of ifqueue in ALTQ In-Reply-To: <20000807134544T.kjc@csl.sony.co.jp> References: <20000807134544T.kjc@csl.sony.co.jp> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > The new model removes direct references to the fields > within ifp->if_snd, and defines the following macros to manipulate > ifp-> if_snd: I tried to do this about four years ago, and was stymied by an important driver's (mis-)use of the interface queue structure for its own internal record-keeping. Best of luck in making this work. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 7 7:11:56 2000 Delivered-To: freebsd-net@freebsd.org Received: from wireless.net (wireless.net [207.137.156.159]) by hub.freebsd.org (Postfix) with ESMTP id 66C9037B5AF for ; Mon, 7 Aug 2000 07:11:54 -0700 (PDT) (envelope-from bad@wireless.net) Received: from localhost (bad@localhost) by wireless.net (8.9.3/8.9.3) with SMTP id HAA08266 for ; Mon, 7 Aug 2000 07:11:56 -0700 (PDT) Date: Mon, 7 Aug 2000 07:11:55 -0700 (PDT) From: Bernie Doehner To: net@freebsd.org Subject: Restoring old IPv4 raw socket behavior under 4.1-RELEASE Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi All: Just upgraded from 4.0-RELEASE to 4.1-RELEASE, and now a custom application of ours that used to do: socket(AF_INET, SOCK_RAW, 4); No longer works with: Protocol not supported opening socket. As far as I can tell, this is because SOCK_RAW sockets now default to IPv6. Is there a SIMPLE way to restore old ipv4 SOCK_RAW socket() behavior, so that I don't need to have any IPv6 routes at all? I tried replacing AF_INET with AF_INET6, but then I got host unreachable from the sendto(), because I don't have IPv6 routes set up. Thanks, Bernie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 7 9:24:43 2000 Delivered-To: freebsd-net@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id 0B22637BA59 for ; Mon, 7 Aug 2000 09:24:38 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.3) id JAA07533; Mon, 7 Aug 2000 09:24:34 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200008071624.JAA07533@bubba.whistle.com> Subject: Re: netgraph ethernet module In-Reply-To: from Andrey Sverdlichenko at "Aug 7, 2000 11:07:31 am" To: Andrey Sverdlichenko Date: Mon, 7 Aug 2000 09:24:34 -0700 (PDT) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL68 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Andrey Sverdlichenko writes: > > Andrey Sverdlichenko writes: > > > Are there any plans to develop ethernet encapsulation module for netgraph, > > > something that can be inserted between ng_iface and ng_ether? > > > > Not a bad idea.. > > So, there is no currently work in progress, and i'll start a new one? Sure! :-) > > But really this should be separate module(s) for each protocol type. > [skip] > > IPX (0x8137) +---------------+ AppleTalk (0x809B) > > ... ---------| ng_ether_mux |--------------- ... > > +---------------+ > > | > > | > > +-----------+ > > | ng_ether | > > +-----------+ > > Is there a way to get hardware address from ng_ether? ng_ether_mux must > fill source address in ethernet header, and AFAIK the only way it can get > it now is downstream->peer->node->private->ac_enaddr, which is dirty hack. > Possibly a control message should be added to this node type? Yeah, that's a good idea, and it would be easy to do.. I'll put it on my list. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 7 9:44: 3 2000 Delivered-To: freebsd-net@freebsd.org Received: from smtp.whitebarn.com (Spin.WhiteBarn.Com [216.0.13.113]) by hub.freebsd.org (Postfix) with ESMTP id 8B15437B50B for ; Mon, 7 Aug 2000 09:43:57 -0700 (PDT) (envelope-from Bob@WhiteBarn.Com) Received: from WhiteBarn.Com (BarnStorm.WhiteBarn.Com [216.0.13.81]) by smtp.whitebarn.com (8.9.3/8.9.3) with ESMTP id LAA28631; Mon, 7 Aug 2000 11:42:20 -0500 (CDT) (envelope-from Bob@WhiteBarn.Com) Message-ID: <398EE6EC.26646EE9@WhiteBarn.Com> Date: Mon, 07 Aug 2000 11:42:20 -0500 From: Bob Van Valzah Organization: WhiteBarn Web Works X-Mailer: Mozilla 4.61 [en] (X11; I; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Pedro J. Lobo" Cc: freebsd-net@FreeBSD.ORG Subject: Re: VLAN Config Advice References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I found my problem in misconfiguration between my Cisco FreeBSD. Details below. "Pedro J. Lobo" wrote: > > If I do ifconfig fxp0 first and then ifconfig vlan0 on top of it, I get > > a booted system. However, arp issues lots of warning messages about > > packets arriving on fxp0 when they should be on vlan0 and I can't ping > > the box. > > Hmmm, I've been using simultaneously fxp0 (i.e., without tag) and vlan0 > (tagged, hooked on fxp0) without any problems. Are you sure you are > configuring fxp1 and vlan0 with addresses that are on different subnets? I've learned that 802.1q has this notion of a "native VLAN." On Ciscos (at least) that defaults to VLAN 1. My problem was that I had my FreeBSD vlan0 interface configured on an IP network that was on VLAN 1. My cisco wasn't tagging packets for VLAN 1 so they appeared to arp as if they were arriving on fxp0 (the physical interface) even though the arp request went out on vlan0. There are two simple fixes. 1) On the cisco side: "switchport trunk native vlan 999" or some other VLAN you're not using. This has the effect of forcing the Cisco to tag traffic for all VLANs in use. 2) Configure the physical interface for the IP network on VLAN 1. This is probably a little cleaner in that it doesn't depend on the VLAN code working at all to have at least one working IP address. Does anybody with experience on other switches know if VLAN 1 is always the default native VLAN? Either way, this quirk should be mentioned in the Handbook in the VLAN section (still to be written). Thanks, Bob To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 7 9:48:37 2000 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 EAB1437BC88 for ; Mon, 7 Aug 2000 09:48:32 -0700 (PDT) (envelope-from itojun@itojun.org) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id BAA21907; Tue, 8 Aug 2000 01:48:22 +0900 (JST) To: Bernie Doehner Cc: net@freebsd.org In-reply-to: bad's message of Mon, 07 Aug 2000 07:11:55 MST. 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: Restoring old IPv4 raw socket behavior under 4.1-RELEASE From: itojun@iijlab.net Date: Tue, 08 Aug 2000 01:48:22 +0900 Message-ID: <21905.965666902@coconut.itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Just upgraded from 4.0-RELEASE to 4.1-RELEASE, and now a custom >application of ours that used to do: > >socket(AF_INET, SOCK_RAW, 4); > >No longer works with: >Protocol not supported opening socket. > >As far as I can tell, this is because SOCK_RAW sockets now default to >IPv6. Is there a SIMPLE way to restore old ipv4 SOCK_RAW >socket() behavior, so that I don't need to have any IPv6 routes at all? no, the observation is incorrect. we simply need rip_{output,ctloutput} family listed in protosw. itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 7 9:55:12 2000 Delivered-To: freebsd-net@freebsd.org Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by hub.freebsd.org (Postfix) with ESMTP id 7476837BAAE; Mon, 7 Aug 2000 09:55:09 -0700 (PDT) (envelope-from randy@psg.com) Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13LqB4-0005df-00; Mon, 07 Aug 2000 09:55:02 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Kris Kennaway Cc: freebsd-net@freebsd.org Subject: Re: apparently FreeBSD-specific DNS failure References: <200008070811.DAA14294@cs.rice.edu> Message-Id: Date: Mon, 07 Aug 2000 09:55:02 -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > '_' is not a valid character for DNS host names. bzzzt! see rfc 2181 sec 11 randy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 7 9:56: 1 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail.targetnet.com (mail.targetnet.com [207.245.246.3]) by hub.freebsd.org (Postfix) with ESMTP id 4449E37BA83 for ; Mon, 7 Aug 2000 09:55:50 -0700 (PDT) (envelope-from james@targetnet.com) Received: from james by mail.targetnet.com with local (Exim 3.02 #1) id 13LqBi-0002UF-00; Mon, 07 Aug 2000 12:55:42 -0400 Date: Mon, 7 Aug 2000 12:55:42 -0400 From: James FitzGibbon To: Bob Van Valzah Cc: James FitzGibbon , freebsd-net@freebsd.org Subject: Re: VLAN Config Advice Message-ID: <20000807125542.B8692@targetnet.com> References: <398C491E.D7ED5E9F@WhiteBarn.Com> <20000806005221.A8147@ehlo.com> <398CFAEC.9F11947F@WhiteBarn.Com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre1i In-Reply-To: <398CFAEC.9F11947F@WhiteBarn.Com> Organization: Targetnet.com Inc. Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Bob Van Valzah (Bob@WhiteBarn.Com) [000806 01:43]: > I should've said I'm on a Cisco 2924XL. I'm using this config for the port > > interface FastEthernet0/13 > switchport trunk encapsulation dot1q > switchport mode trunk I've done this with a 2924XL running IOS 12 and also with a 7204VXR running IOS 12.1. I didn't use switchport trunk though; that's usually for trunking two physical ports into one virtual port so that you can have more than 100Mb/s bandwidth between two units (usually two switches). On the 2924XL, I use this type of config for a port which is just on one VLAN: interface FastEthernet0/1 switchport access vlan 1 If the port is on multiple VLANs: interface FastEthernet0/1 switchport multi vlan 2,3 On the router I use 'encapsulation dot1q #' to configure the sub-interfaces of the physical interface I am doing vlans on. -- j. James FitzGibbon james@targetnet.com Targetnet.com Inc. Voice/Fax +1 416 306-0466/0452 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 7 10:13:13 2000 Delivered-To: freebsd-net@freebsd.org Received: from smtp.whitebarn.com (Spin.WhiteBarn.Com [216.0.13.113]) by hub.freebsd.org (Postfix) with ESMTP id C8E6237B7E3 for ; Mon, 7 Aug 2000 10:13:09 -0700 (PDT) (envelope-from Bob@WhiteBarn.Com) Received: from WhiteBarn.Com (BarnStorm.WhiteBarn.Com [216.0.13.81]) by smtp.whitebarn.com (8.9.3/8.9.3) with ESMTP id MAA28951; Mon, 7 Aug 2000 12:13:03 -0500 (CDT) (envelope-from Bob@WhiteBarn.Com) Message-ID: <398EEE1E.959C5443@WhiteBarn.Com> Date: Mon, 07 Aug 2000 12:13:03 -0500 From: Bob Van Valzah Organization: WhiteBarn Web Works X-Mailer: Mozilla 4.61 [en] (X11; I; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James FitzGibbon Cc: James FitzGibbon , freebsd-net@freebsd.org Subject: Re: VLAN Config Advice References: <398C491E.D7ED5E9F@WhiteBarn.Com> <20000806005221.A8147@ehlo.com> <398CFAEC.9F11947F@WhiteBarn.Com> <20000807125542.B8692@targetnet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org James FitzGibbon wrote: > I've done this with a 2924XL running IOS 12 and also with a 7204VXR running > IOS 12.1. I didn't use switchport trunk though; that's usually for trunking > two physical ports into one virtual port so that you can have more than > 100Mb/s bandwidth between two units (usually two switches). I believe that "port grouping" is what Cisco calls it when multiple physical ports are combined between switches. Grouping ports seems to be an independent concept from trunking VLANs. This example would combine ports 21 and 22 into a port group destined for another switch. interface FastEthernet0/21 port group 1 switchport mode trunk ! interface FastEthernet0/22 port group 1 switchport mode trunk It looks to me like the grouped trunk ports above will default to ISL encapsulation which won't work with FreeBSD AFIK. > On the 2924XL, I use this type of config for a port which is just on one > VLAN: > > interface FastEthernet0/1 > switchport access vlan 1 I believe this generates untagged frames on the port for the statically assigned VLAN. > If the port is on multiple VLANs: > > interface FastEthernet0/1 > switchport multi vlan 2,3 I went to try that and found that multi vlan conflicts with the nice VLAN trunking I had in place between my switches. :-( But I've found happiness with this simple rule: use dot1q encapsulation with FreeBSD but configure VLAN 1 on the physical interface and all others on vlan interfaces. Bob To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 7 10:24:10 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail2.netcologne.de (mail2.netcologne.de [194.8.194.103]) by hub.freebsd.org (Postfix) with ESMTP id AB1DB37B9BD; Mon, 7 Aug 2000 10:24:02 -0700 (PDT) (envelope-from pherman@frenchfries.net) Received: from bagabeedaboo.security.at12.de (dial-213-168-72-68.netcologne.de [213.168.72.68]) by mail2.netcologne.de (8.9.3/8.9.3) with ESMTP id TAA05285; Mon, 7 Aug 2000 19:23:59 +0200 (MET DST) Received: from localhost (localhost.security.at12.de [127.0.0.1]) by bagabeedaboo.security.at12.de (8.10.2/8.10.2) with ESMTP id e77HNq902614; Mon, 7 Aug 2000 19:23:52 +0200 (CEST) Date: Mon, 7 Aug 2000 19:23:52 +0200 (CEST) From: Paul Herman To: Randy Bush Cc: Kris Kennaway , freebsd-net@FreeBSD.ORG Subject: Re: apparently FreeBSD-specific DNS failure In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 7 Aug 2000, Randy Bush wrote: > > '_' is not a valid character for DNS host names. > > bzzzt! see rfc 2181 sec 11 I think you might have read that wrong. In that section it uses the word "binary" to mean binary records, not "binary" entries (i.e. records with a LHS and RHS, not charaters like \0012 or whatever.) Besides that, section 11 suggests reading RFC1123 which is pretty clear about names (in section 2.1) which outlines a single relaxing of the name convention in RFC952 (which BTW doesn't allow for a '_') -Paul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 7 10:25:17 2000 Delivered-To: freebsd-net@freebsd.org Received: from wireless.net (wireless.net [207.137.156.159]) by hub.freebsd.org (Postfix) with ESMTP id D36C337B9BD for ; Mon, 7 Aug 2000 10:25:13 -0700 (PDT) (envelope-from bad@wireless.net) Received: from localhost (bad@localhost) by wireless.net (8.9.3/8.9.3) with SMTP id KAA08902; Mon, 7 Aug 2000 10:25:02 -0700 (PDT) Date: Mon, 7 Aug 2000 10:25:02 -0700 (PDT) From: Bernie Doehner To: itojun@iijlab.net Cc: net@freebsd.org Subject: Re: Restoring old IPv4 raw socket behavior under 4.1-RELEASE In-Reply-To: <21905.965666902@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 8 Aug 2000 itojun@iijlab.net wrote: > > >Just upgraded from 4.0-RELEASE to 4.1-RELEASE, and now a custom > >application of ours that used to do: > > > >socket(AF_INET, SOCK_RAW, 4); > > > >No longer works with: > >Protocol not supported opening socket. > > > >As far as I can tell, this is because SOCK_RAW sockets now default to > >IPv6. Is there a SIMPLE way to restore old ipv4 SOCK_RAW > >socket() behavior, so that I don't need to have any IPv6 routes at all? > > no, the observation is incorrect. we simply need rip_{output,ctloutput} > family listed in protosw. > > itojun > Hi Itojun: Thanks for responding.. This all seems to be new. I don't remmember any rip_ functions. Is there documentation somewhere on how to do this? It's the first time I have ever seen this. I see the { SOCK_RAW, &inetdomain, IPPROTO_IPV4, PR_ATOMIC|PR_ADDR, encap4_input, 0, 0, rip_ctloutput, .... } entry in in_proto.c. Isn't that what sets up the binding between AF_INET and SOCK_RAW and protocol 4? Thanks for unconfusing me. Bernie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 7 10:31: 5 2000 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 764C837B646 for ; Mon, 7 Aug 2000 10:31:01 -0700 (PDT) (envelope-from sthaug@nethelp.no) Received: (qmail 76266 invoked by uid 1001); 7 Aug 2000 17:30:58 +0000 (GMT) To: james@targetnet.com Cc: Bob@WhiteBarn.Com, james@ehlo.com, freebsd-net@freebsd.org Subject: Re: VLAN Config Advice From: sthaug@nethelp.no In-Reply-To: Your message of "Mon, 7 Aug 2000 12:55:42 -0400" References: <20000807125542.B8692@targetnet.com> X-Mailer: Mew version 1.05+ on Emacs 19.34.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Mon, 07 Aug 2000 19:30:58 +0200 Message-ID: <76264.965669458@verdi.nethelp.no> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > interface FastEthernet0/13 > > switchport trunk encapsulation dot1q > > switchport mode trunk > > I've done this with a 2924XL running IOS 12 and also with a 7204VXR running > IOS 12.1. I didn't use switchport trunk though; that's usually for trunking > two physical ports into one virtual port so that you can have more than > 100Mb/s bandwidth between two units (usually two switches). Not necessarily. We use it here anytime we need a trunk (carrying multiple VLANs with the appropriate 802.1q or ISL encapsulation) between switches, or between a switch and a router. 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 Mon Aug 7 10:47:10 2000 Delivered-To: freebsd-net@freebsd.org Received: from inetfw.sonycsl.co.jp (inetfw.SonyCSL.Co.Jp [203.137.129.4]) by hub.freebsd.org (Postfix) with ESMTP id B225737B56C for ; Mon, 7 Aug 2000 10:47:05 -0700 (PDT) (envelope-from kjc@csl.sony.co.jp) Received: from hotaka.csl.sony.co.jp (hotaka.csl.sony.co.jp [43.27.98.57]) by inetfw.sonycsl.co.jp (8.9.3+3.2W/3.7Ws3/inetfw/2000050701/smtpfeed 1.07) with ESMTP id CAA26276; Tue, 8 Aug 2000 02:47:03 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by hotaka.csl.sony.co.jp (8.9.3+3.2W/3.7Ws3/hotaka/2000061722) with ESMTP id CAA42650; Tue, 8 Aug 2000 02:47:03 +0900 (JST) To: wollman@khavrinen.lcs.mit.edu Cc: freebsd-net@FreeBSD.ORG Subject: Re: redesign of ifqueue in ALTQ In-Reply-To: <200008071407.KAA08680@khavrinen.lcs.mit.edu> References: <20000807134544T.kjc@csl.sony.co.jp> <200008071407.KAA08680@khavrinen.lcs.mit.edu> X-Mailer: Mew version 1.94.2 on Emacs 20.6 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000808024702G.kjc@csl.sony.co.jp> Date: Tue, 08 Aug 2000 02:47:02 +0900 From: Kenjiro Cho X-Dispatcher: imput version 20000228(IM140) Lines: 21 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Garrett Wollman wrote: > < said: > > The new model removes direct references to the fields > > within ifp->if_snd, and defines the following macros to manipulate > > ifp-> if_snd: > > I tried to do this about four years ago, and was stymied by an > important driver's (mis-)use of the interface queue structure for its > own internal record-keeping. Complex drivers (e.g., de) are hard to convert. But this approach allows the old-style drivers to coexist so that we can start with easier drivers. Good news is that Bill Paul's drivers are much easier to convert. > Best of luck in making this work. Thanks for your support! -Kenjiro To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 7 10:54:42 2000 Delivered-To: freebsd-net@freebsd.org Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by hub.freebsd.org (Postfix) with ESMTP id 7CCE537B979; Mon, 7 Aug 2000 10:54:40 -0700 (PDT) (envelope-from randy@psg.com) Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13Lr6j-00066a-00; Mon, 07 Aug 2000 10:54:37 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Paul Herman Cc: Kris Kennaway , freebsd-net@FreeBSD.ORG Subject: Re: apparently FreeBSD-specific DNS failure References: Message-Id: Date: Mon, 07 Aug 2000 10:54:37 -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >>> '_' is not a valid character for DNS host names. >> bzzzt! see rfc 2181 sec 11 > I think you might have read that wrong. uh, i wrote it, not read it. > In that section it uses the word "binary" to mean binary records, not > "binary" entries (i.e. records with a LHS and RHS, not charaters like > \0012 or whatever.) nope. randy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 7 11:11:18 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail2.netcologne.de (mail2.netcologne.de [194.8.194.103]) by hub.freebsd.org (Postfix) with ESMTP id 231D937BC95 for ; Mon, 7 Aug 2000 11:09:52 -0700 (PDT) (envelope-from pherman@frenchfries.net) Received: from bagabeedaboo.security.at12.de (dial-195-14-254-210.netcologne.de [195.14.254.210]) by mail2.netcologne.de (8.9.3/8.9.3) with ESMTP id UAA10958; Mon, 7 Aug 2000 20:09:39 +0200 (MET DST) Received: from localhost (localhost.security.at12.de [127.0.0.1]) by bagabeedaboo.security.at12.de (8.10.2/8.10.2) with ESMTP id e77I9Sq02891; Mon, 7 Aug 2000 20:09:28 +0200 (CEST) Date: Mon, 7 Aug 2000 20:09:28 +0200 (CEST) From: Paul Herman To: Randy Bush Cc: freebsd-net@FreeBSD.ORG Subject: Re: apparently FreeBSD-specific DNS failure In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 7 Aug 2000, Randy Bush wrote: > >>> '_' is not a valid character for DNS host names. > >> bzzzt! see rfc 2181 sec 11 > > I think you might have read that wrong. > > uh, i wrote it, not read it. Yes, after rereading it I see now you do mean binary octets. I must say, reading it is ambiguous, and you don't explicitly state that each octet MAY take on all values, or if not, which ones. If I were writing a DNS stack based on this, that would give me many unanswered questions. Perhaps it would also be a good idea (purely for sake of clarity) to indeed reference the RFCs in the same breath which it would be obsoleting while making those proposals (as did RFC1123.) I think that would even be more clear. What luck! I've got the author himself on the horn. When do we get to use umlauts in our domain names here in Germany? :) -Paul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 7 11:55:24 2000 Delivered-To: freebsd-net@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id 9705537BADA for ; Mon, 7 Aug 2000 11:55:21 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.3) id LAA12675; Mon, 7 Aug 2000 11:55:18 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200008071855.LAA12675@bubba.whistle.com> Subject: Re: netgraph ethernet module In-Reply-To: from Andrey Sverdlichenko at "Aug 7, 2000 11:07:31 am" To: Andrey Sverdlichenko Date: Mon, 7 Aug 2000 11:55:18 -0700 (PDT) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL68 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Andrey Sverdlichenko writes: > Is there a way to get hardware address from ng_ether? ng_ether_mux must > fill source address in ethernet header, and AFAIK the only way it can get > it now is downstream->peer->node->private->ac_enaddr, which is dirty hack. > Possibly a control message should be added to this node type? OK, I just checked in this change into -current: > Add three new control messages to the ng_ether(4) netgraph node type: > > NGM_ETHER_GET_ENADDR: Get the device's Ethernet address > NGM_ETHER_SET_PROMISC: Enable/disable promiscuous mode > NGM_ETHER_SET_AUTOSRC: Enable/disable packet source address override Let me know if there are any problems. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 7 12:10:12 2000 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 C62E337B792 for ; Mon, 7 Aug 2000 12:10:04 -0700 (PDT) (envelope-from sthaug@nethelp.no) Received: (qmail 77458 invoked by uid 1001); 7 Aug 2000 19:06:50 +0000 (GMT) To: pherman@frenchfries.net Cc: randy@psg.com, freebsd-net@FreeBSD.ORG Subject: Re: apparently FreeBSD-specific DNS failure From: sthaug@nethelp.no In-Reply-To: Your message of "Mon, 7 Aug 2000 20:09:28 +0200 (CEST)" References: X-Mailer: Mew version 1.05+ on Emacs 19.34.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Mon, 07 Aug 2000 21:06:50 +0200 Message-ID: <77456.965675210@verdi.nethelp.no> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > What luck! I've got the author himself on the horn. When do we get to > use umlauts in our domain names here in Germany? :) If you *really* want to open that can of worms, have a look at draft-oscarsson-i18ndns-00.txt: "Internationalisation of the Domain Name Service". Or register your domains under .nu (no, I don't particularly recommend this). 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 Mon Aug 7 13:42:48 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail2.netcologne.de (mail2.netcologne.de [194.8.194.103]) by hub.freebsd.org (Postfix) with ESMTP id CD59137B96F for ; Mon, 7 Aug 2000 13:42:43 -0700 (PDT) (envelope-from pherman@frenchfries.net) Received: from bagabeedaboo.security.at12.de (dial-194-8-209-133.netcologne.de [194.8.209.133]) by mail2.netcologne.de (8.9.3/8.9.3) with ESMTP id WAA00093; Mon, 7 Aug 2000 22:42:40 +0200 (MET DST) Received: from localhost (localhost.security.at12.de [127.0.0.1]) by bagabeedaboo.security.at12.de (8.10.2/8.10.2) with ESMTP id e77KgUf04287; Mon, 7 Aug 2000 22:42:30 +0200 (CEST) Date: Mon, 7 Aug 2000 22:42:30 +0200 (CEST) From: Paul Herman To: sthaug@nethelp.no Cc: randy@psg.com, freebsd-net@FreeBSD.ORG Subject: Re: apparently FreeBSD-specific DNS failure In-Reply-To: <77456.965675210@verdi.nethelp.no> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 7 Aug 2000 sthaug@nethelp.no wrote: > If you *really* want to open that can of worms, have a look at > draft-oscarsson-i18ndns-00.txt: OK, but to sum up (and kill) this thread: The '_' character in domain names is: legal in RFC 1033 not legal in RFC 1035 not legal in RFC 1123 legal in RFC 2181 legal in draft-oscarsson-i18ndns-00 However, according to RFC 2400 which names the documents which are currently standard, required, recommended, elective, proposed, or just drafts, only RFC 1123 is required. RFC 1033 is not even mentioned RFC 1035 is recommended RFC 2181 is elective draft-oscarsson-i18ndns-00 is a new draft this year, (not mentioned) I, too, hope that the papers written by Randy Bush, Dan Oscarsson and others will someday (soon!) become required internet standards. I tip my hat (if I had one) off to them. However, I think we can very safely say that (at least on August 7th, 2000) the '_' character is not a "legal" character in a domain name. (This is actually a FAQ from comp.protocols.tcp-ip.domains, so I apologize for stating the already stated.) -Paul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 7 14:44:58 2000 Delivered-To: freebsd-net@freebsd.org Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by hub.freebsd.org (Postfix) with ESMTP id 5C93337BBAF for ; Mon, 7 Aug 2000 14:44:40 -0700 (PDT) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.0) with SMTP id HAA25693 for ; Tue, 8 Aug 2000 07:44:36 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Tue, 8 Aug 2000 07:44:36 +1000 (EST) From: Ian Smith To: net@FreeBSD.ORG Subject: Solved: Intel 'Pro 4041' card? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 7 Aug 2000, Ian Smith wrote: > A local surplus store has a bunch of Intel ISA nics which were described > as being marked 'Intel Pro 4041'. I haven't seen the cards yet, and on Sorry folks, you can all stop looking now :-) Turns out they're EtherExpress Pro/10 ISA cards (Intel part PCLA8215A) which I'll assume are most likely ok, unleses someone says otherwise? That 'Pro 4041' moniker appears only on their endplates, and of course is nowhere on Intel's site. Maybe it's the endplate's part no? Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 7 15:32:56 2000 Delivered-To: freebsd-net@freebsd.org Received: from smtp.whitebarn.com (Spin.WhiteBarn.Com [216.0.13.113]) by hub.freebsd.org (Postfix) with ESMTP id 411EE37B8DF for ; Mon, 7 Aug 2000 15:32:52 -0700 (PDT) (envelope-from Bob@WhiteBarn.Com) Received: from WhiteBarn.Com (BarnStorm.WhiteBarn.Com [216.0.13.81]) by smtp.whitebarn.com (8.9.3/8.9.3) with ESMTP id RAA31597; Mon, 7 Aug 2000 17:32:14 -0500 (CDT) (envelope-from Bob@WhiteBarn.Com) Message-ID: <398F38ED.776E84E2@WhiteBarn.Com> Date: Mon, 07 Aug 2000 17:32:14 -0500 From: Bob Van Valzah Organization: WhiteBarn Web Works X-Mailer: Mozilla 4.61 [en] (X11; I; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Garrett Wollman Cc: freebsd-net@FreeBSD.ORG Subject: Re: VLAN MTU? 1500? 1504? Why? References: <398A3549.902A31F5@WhiteBarn.Com> <200008040434.AAA41523@whizzo.transsys.com> <398AB99C.9D5938B9@WhiteBarn.Com> <200008041446.KAA27928@khavrinen.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ok, it looks to me like some code is needed that doesn't exist. I'd be glad to help make it happen if I had a sample. Can anybody help get me started? Here's the state of the world as I understand it based on comments here and my own experimentation. Please set me straight if I'm off base. 1) A 1500-byte IPv4 MTU on an Ethernet VLAN is desirable. Things sometimes things break over VLAN interfaces that only support 1496-byte IPv4 MTUs. 2) 4.1-RELEASE contains a working vlan pseudo device driver, but only the ti driver is capable of running a 1500-byte IPv4 MTUs with it "as shipped." 3) A patch is available (http://www.euitt.upm.es/~pjlobo/fxp-mtu-patch-4.x) for the fxp driver of 4.0-RELEASE that allows a 1500-byte IPv4 MTU. However, this patch doesn't "negotiate" with the physical device--it just assumes that all physical devices can handle the larger link-layer headers. 4) It is possible (see below) for such negotiation to take place. I haven't been able to find an example of it yet. If somebody could provide me with a sample of this negotiation, I'd be happy to port it to the fxp and all the other capable cards I have around here. Bob Garrett Wollman wrote: > < said: > > > Is there any existing mechanism for "negotiation" of MTU between the > > physical layer and virtual layer? > > Yes. In FreeBSD's implementation, the network interface driver > indicates its ability to handle 802.1p-enacapsulated frames (as used > in 802.1Q) by advertising a header length of 18 rather than the > standard (no encapsulation) 14 octets. (The current implementation > does not, however, have a mechanism for rejecting 1518-byte > *unencapsulated* packets, as should officially be done. I don't think > this is a serious problem.) > > -GAWollman > > -- > Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same > wollman@lcs.mit.edu | O Siem / The fires of freedom > Opinions not those of| Dance in the burning flame > MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 7 17:44:29 2000 Delivered-To: freebsd-net@freebsd.org Received: from web312.mail.yahoo.com (web312.mail.yahoo.com [216.115.105.77]) by hub.freebsd.org (Postfix) with SMTP id CBC6237B8CA for ; Mon, 7 Aug 2000 17:44:26 -0700 (PDT) (envelope-from virtual_olympus@yahoo.com) Message-ID: <20000808004424.2838.qmail@web312.mail.yahoo.com> Received: from [209.103.207.168] by web312.mail.yahoo.com; Mon, 07 Aug 2000 17:44:24 PDT Date: Mon, 7 Aug 2000 17:44:24 -0700 (PDT) From: Benjamin Gavin Subject: NATD and non-UDP/TCP packets To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hey all, I've browsed through the archives and haven't found the answer (although I have found the question) numerous times. What I am trying to do is setup some VPN software which uses the ESP and AH protocols (50/51). Unfortunately natd will not so the translation (as neither are UDP/TCP nor PPTP). Are there other services available for FreeBSD which will perform these functions, or is there any possibility that these protocols will be included in future NATD versions? What are the fundamental differences between ESP/AH and TCP/UDP? Are they inherently more complicated to translate, or is there some checksum built into the packet which would have to be recalculated upon translation?? The problem (as I see it) is that natd doesn't touch the outgoing packets, so the destination machine tries to reply to the internal address numbers. I can watch the packets with both tcpdump and by logging their denial on the firewall, but is it possible to get these things NAT'd?? Thanks much, Ben Gavin __________________________________________________ Do You Yahoo!? Kick off your party with Yahoo! Invites. http://invites.yahoo.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 7 19:58:41 2000 Delivered-To: freebsd-net@freebsd.org Received: from wireco.net (mental.wireco.net [206.107.119.3]) by hub.freebsd.org (Postfix) with SMTP id 799BD37B514 for ; Mon, 7 Aug 2000 19:58:35 -0700 (PDT) (envelope-from hornback@wireco.net) Received: (qmail 8114 invoked from network); 8 Aug 2000 02:58:31 -0000 Received: from d23.johnson-city.tn.us.wireco.net (HELO challenger) (206.107.119.212) by mental.wireco.net with SMTP; 8 Aug 2000 02:58:31 -0000 Reply-To: From: "Andrew C. Hornback" To: "'Ian Smith'" Cc: Subject: RE: Solved: Intel 'Pro 4041' card? Date: Mon, 7 Aug 2000 22:56:16 -0400 Message-ID: <003d01c000e4$38c768f0$d4776bce@challenger> 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 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 In-Reply-To: Importance: Normal Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org From my experience with Intel networking hardware, those are good cards, and there should be a driver available for them. --- Andy > -----Original Message----- > From: owner-freebsd-net@FreeBSD.ORG > [mailto:owner-freebsd-net@FreeBSD.ORG]On Behalf Of Ian Smith > Sent: Monday, August 07, 2000 5:45 PM > To: net@FreeBSD.ORG > Subject: Solved: Intel 'Pro 4041' card? > > > On Mon, 7 Aug 2000, Ian Smith wrote: > > > A local surplus store has a bunch of Intel ISA nics which > were described > > as being marked 'Intel Pro 4041'. I haven't seen the > cards yet, and on > > Sorry folks, you can all stop looking now :-) > > Turns out they're EtherExpress Pro/10 ISA cards (Intel part > PCLA8215A) > which I'll assume are most likely ok, unleses someone says otherwise? > > That 'Pro 4041' moniker appears only on their endplates, and of course > is nowhere on Intel's site. Maybe it's the endplate's part > no? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 8 0:35:54 2000 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 4EC1537B534 for ; Tue, 8 Aug 2000 00:35:47 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.9.3/1.13) id KAA12462; Tue, 8 Aug 2000 10:35:37 +0300 (EEST) Date: Tue, 8 Aug 2000 10:35:36 +0300 From: Ruslan Ermilov To: Benjamin Gavin Cc: freebsd-net@freebsd.org Subject: Re: NATD and non-UDP/TCP packets Message-ID: <20000808103536.C11454@sunbay.com> Mail-Followup-To: Benjamin Gavin , freebsd-net@freebsd.org References: <20000808004424.2838.qmail@web312.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20000808004424.2838.qmail@web312.mail.yahoo.com>; from virtual_olympus@yahoo.com on Mon, Aug 07, 2000 at 05:44:24PM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Aug 07, 2000 at 05:44:24PM -0700, Benjamin Gavin wrote: > Hey all, > I've browsed through the archives and haven't found the answer (although > I have found the question) numerous times. What I am trying to do is > setup some VPN software which uses the ESP and AH protocols (50/51). > Unfortunately natd will not so the translation (as neither are UDP/TCP nor > PPTP). Are there other services available for FreeBSD which will perform > these functions, or is there any possibility that these protocols will be > included in future NATD versions? > You can redirect a particular IP protocol with -redirect_proto rule, or any protocol with -redirect_address rule. > What are the fundamental differences between ESP/AH and TCP/UDP? Are > they inherently more complicated to translate, or is there some checksum > built into the packet which would have to be recalculated upon > translation?? > The main differences is that both TCP and UDP have a concept of port, while generic IP encapsulation protocols do not have it. Please refer to libalias(3) manual page, section CONCEPTUAL BACKGROUND, for more details. > The problem (as I see it) is that natd doesn't touch the outgoing > packets, so the destination machine tries to reply to the internal address > numbers. I can watch the packets with both tcpdump and by logging their > denial on the firewall, but is it possible to get these things NAT'd?? > Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 8 2: 8:51 2000 Delivered-To: freebsd-net@freebsd.org Received: from sasi.com (samar.sasi.com.56.164.164.in-addr.arpa [164.164.56.2]) by hub.freebsd.org (Postfix) with ESMTP id ED1B437B743 for ; Tue, 8 Aug 2000 02:08:41 -0700 (PDT) (envelope-from gbnaidu@sasi.com) Received: from samar (sasi.com [164.164.56.2]) by sasi.com (8.9.3/8.9.3) with SMTP id OAA09908 for ; Tue, 8 Aug 2000 14:39:40 +0530 (IST) Received: from pcd75.sasi.com ([10.0.16.75]) by sasi.com; Tue, 08 Aug 2000 14:39:39 +0000 (IST) Received: from localhost (gbnaidu@localhost) by pcd75.sasi.com (8.9.3/8.9.3) with ESMTP id OAA09747 for ; Tue, 8 Aug 2000 14:39:26 +0530 Date: Tue, 8 Aug 2000 14:39:25 +0530 (IST) From: "G.B.Naidu" To: freebsd-net@FreeBSD.org Subject: divert rule in ipfw... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I have a ipfw rule like this: ipfw add divert natd all from any to any via de0 This will divert all packets to natd. But I would like to divert all packets except the packets generated from the machine say 10.0.16.63 where the natd is running. For this I tried to use some thing like this: ipfw add divert natd not 10.0.16.63 to not 10.0.16.63 via de0 Still looks like it diverts all the packets. Can some body let me know how do I avoid divreting packets generated from the machine where the natd is running. thanks --gb -- Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 8 2:54:21 2000 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 61E9B37B77D for ; Tue, 8 Aug 2000 02:54:11 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.9.3/1.13) id MAA18621; Tue, 8 Aug 2000 12:53:33 +0300 (EEST) Date: Tue, 8 Aug 2000 12:53:32 +0300 From: Ruslan Ermilov To: "G.B.Naidu" Cc: freebsd-net@FreeBSD.org Subject: Re: divert rule in ipfw... Message-ID: <20000808125332.A17316@sunbay.com> Mail-Followup-To: "G.B.Naidu" , freebsd-net@FreeBSD.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from gbnaidu@sasi.com on Tue, Aug 08, 2000 at 02:39:25PM +0530 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Aug 08, 2000 at 02:39:25PM +0530, G.B.Naidu wrote: > > Hi, > > I have a ipfw rule like this: > > ipfw add divert natd all from any to any via de0 > > This will divert all packets to natd. But I would like to divert all > packets except the packets generated from the machine say 10.0.16.63 where > the natd is running. For this I tried to use some thing like this: > > ipfw add divert natd not 10.0.16.63 to not 10.0.16.63 via de0 > > Still looks like it diverts all the packets. Can some body let me know > how do I avoid divreting packets generated from the machine where the natd > is running. > The above rule works like expected here. You can always add a `log' keyword to it and see what actual packets match the rule. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 8 7: 9:21 2000 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 C4E0037B7E8 for ; Tue, 8 Aug 2000 07:09:12 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id KAA13542; Tue, 8 Aug 2000 10:08:03 -0400 (EDT) (envelope-from wollman) Date: Tue, 8 Aug 2000 10:08:03 -0400 (EDT) From: Garrett Wollman Message-Id: <200008081408.KAA13542@khavrinen.lcs.mit.edu> To: Benjamin Gavin Cc: freebsd-net@FreeBSD.ORG Subject: NATD and non-UDP/TCP packets In-Reply-To: <20000808004424.2838.qmail@web312.mail.yahoo.com> References: <20000808004424.2838.qmail@web312.mail.yahoo.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > What are the fundamental differences between ESP/AH and TCP/UDP? Are > they inherently more complicated to translate, They are designed to be cryptographically secure, and hence, impossible to NAT. If you want to do NAT, you'll have to terminate the SAs at the boundary and create an appropriate new set for the ``public'' side. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 8 7:11:27 2000 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 BF33637B9AD for ; Tue, 8 Aug 2000 07:11:23 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id KAA13563; Tue, 8 Aug 2000 10:11:16 -0400 (EDT) (envelope-from wollman) Date: Tue, 8 Aug 2000 10:11:16 -0400 (EDT) From: Garrett Wollman Message-Id: <200008081411.KAA13563@khavrinen.lcs.mit.edu> To: Bob Van Valzah Cc: freebsd-net@FreeBSD.ORG Subject: Re: VLAN MTU? 1500? 1504? Why? In-Reply-To: <398F38ED.776E84E2@WhiteBarn.Com> References: <398A3549.902A31F5@WhiteBarn.Com> <200008040434.AAA41523@whizzo.transsys.com> <398AB99C.9D5938B9@WhiteBarn.Com> <200008041446.KAA27928@khavrinen.lcs.mit.edu> <398F38ED.776E84E2@WhiteBarn.Com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > If somebody could provide me with a sample of this negotiation, I'd > be happy to port it to the fxp and all the other capable cards I > have around here. ifp->if_data.ifi_hdrlen = sizeof(struct ether_vlan_header); -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 8 7:13:57 2000 Delivered-To: freebsd-net@freebsd.org Received: from rapidnet.com (rapidnet.com [205.164.216.1]) by hub.freebsd.org (Postfix) with ESMTP id 817A737B8D3 for ; Tue, 8 Aug 2000 07:13:42 -0700 (PDT) (envelope-from nick@rapidnet.com) Received: from localhost (nick@localhost) by rapidnet.com (8.9.3/8.9.3) with ESMTP id IAA07450; Tue, 8 Aug 2000 08:13:25 -0600 (MDT) Date: Tue, 8 Aug 2000 08:13:25 -0600 (MDT) From: Nick Rogness To: "G.B.Naidu" Cc: freebsd-net@FreeBSD.org Subject: Re: divert rule in ipfw... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 8 Aug 2000, G.B.Naidu wrote: > > > This will divert all packets to natd. But I would like to divert all > packets except the packets generated from the machine say 10.0.16.63 where > the natd is running. For this I tried to use some thing like this: > > ipfw add divert natd not 10.0.16.63 to not 10.0.16.63 via de0 > > Still looks like it diverts all the packets. Can some body let me know > how do I avoid divreting packets generated from the machine where the natd > is running. > Add a rule before the natd rule to allow traffic from this machine (10.0.16.63) to any. Example: ipfw add 50 allow ip from 10.0.16.63 to any ipfw add 51 allow ip from any to 10.0.16.63 ipfw add 100 divert natd ip from any to any via de0 That is how I've always done it. However, the rule you are using should work... Nick Rogness - Drive defensively. Buy a tank. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 8 7:47:20 2000 Delivered-To: freebsd-net@freebsd.org Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by hub.freebsd.org (Postfix) with ESMTP id F41FA37C058 for ; Tue, 8 Aug 2000 07:47:13 -0700 (PDT) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.0) with SMTP id AAA19588; Wed, 9 Aug 2000 00:43:47 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Wed, 9 Aug 2000 00:43:46 +1000 (EST) From: Ian Smith To: "Andrew C. Hornback" Cc: freebsd-net@freebsd.org Subject: RE: Solved: Intel 'Pro 4041' card? In-Reply-To: <003d01c000e4$38c768f0$d4776bce@challenger> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 7 Aug 2000, Andrew C. Hornback wrote: > From my experience with Intel networking hardware, those are good cards, > and there should be a driver available for them. Yep, building a kernel with the ex driver tonight, installing the card and new LAN segment tomorrow. Will sing out if it _doesn't_ work :) Thanks Andy, Cheers, Ian [..] > > Turns out they're EtherExpress Pro/10 ISA cards (Intel part > > PCLA8215A) > > which I'll assume are most likely ok, unleses someone says otherwise? [..] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 8 12:36:11 2000 Delivered-To: freebsd-net@freebsd.org Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by hub.freebsd.org (Postfix) with ESMTP id 3968F37B62A for ; Tue, 8 Aug 2000 12:36:00 -0700 (PDT) (envelope-from vivek@cs.rice.edu) Received: (from vivek@localhost) by cs.rice.edu (8.9.0/8.9.0) id OAA24188 for freebsd-net@freebsd.org; Tue, 8 Aug 2000 14:35:53 -0500 (CDT) Date: Tue, 8 Aug 2000 14:35:53 -0500 (CDT) From: Vivek Sadananda Pai Message-Id: <200008081935.OAA24188@cs.rice.edu> To: freebsd-net@freebsd.org Subject: Intel Pro/1000 on 4.0-release? Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I've got a Dell Optiplex GXa with an Intel Pro/1000 Gigabit adapter and I'm trying to run the system under 4.0-release. I bought the 4.0 Powerpak and performed a fairly standard install. This is an ancient machine with an 3c905-equivalent fast ethernet on the motherboard. Originally, when the machine first came up, neither card autodetected the media. At some later point, the 10/100 card magically came to life. The gigabit card still seems to not detect the carrier. It's connected to an Intel Gigabit switch, which is an ancient beast that does full duplex only with no autonegotiation. I know the hardware's OK because this machine used to run RedHat 6.2, but the network performance seemed really low. Has anyone gotten this card working on 4.0-release? I'd use an alteon card, but this switch seems to hate them, and I've got a free supply of the Intel cards. I'll include details from ifconfig and dmesg below. I've tried doing 'ifconfig wx0 up' and 'ifconfig wx0 mediaopt full-duplex' but neither see to help. Any help would be appreciated. I've got a cluster of these boxes sitting around, and would love to run FreeBSD on them. Thanks, Vivek wx0: flags=8803 mtu 1500 inet6 fe80::2d0:b7ff:fe45:8549%wx0 prefixlen 64 scopeid 0x1 ether 00:d0:b7:45:85:49 media: 1000baseSX (autoselect) status: no carrier supported media: 1000baseSX 1000baseSX xl0: flags=8843 mtu 1500 inet6 fe80::2c0:4fff:feac:9524%xl0 prefixlen 64 scopeid 0x2 inet 128.112.40.75 netmask 0xfffffe00 broadcast 128.112.41.255 ether 00:c0:4f:ac:95:24 media: autoselect (100baseTX ) status: active supported media: autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP 100baseTX Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-RELEASE #0: Mon Mar 20 22:50:22 GMT 2000 root@monster.cdrom.com:/usr/src/sys/compile/GENERIC Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Pentium II Xeon/Celeron (298.00-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x634 Stepping = 4 Features=0x80f9ff real memory = 134217728 (131072K bytes) config> di sn0 config> di lnc0 config> di le0 config> di ie0 config> di fe0 config> di ed0 config> di cs0 config> q avail memory = 126255104 (123296K bytes) Preloaded elf kernel "kernel" at 0xc03c0000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc03c009c. Pentium Pro MTRR support enabled md0: Malloc disk npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at 0.0 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xffa0-0xffaf at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: at 7.2 irq 11 chip1: port 0x850-0x85f at device 7.3 on pci0 wx0: mem 0xfa020000-0xfa03ffff irq 10 at device 14.0 on pci0 wx0: Ethernet address 00:d0:b7:45:85:49 wx0: supplying EUI64: 00:d0:b7:ff:fe:45:85:49 pcib2: at device 15.0 on pci0 pci2: on pcib2 xl0: <3Com 3c905-TX Fast Etherlink XL> port 0xdc80-0xdcbf irq 11 at device 17.0 on pci0 xl0: Ethernet address: 00:c0:4f:ac:95:24 miibus0: on xl0 nsphy0: on miibus0 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: at port 0x60-0x6f on isa0 atkbd0: irq 1 on atkbdc0 psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 sc0: on isa0 sc0: VGA <16 virtual consoles, flags=0x200> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppi0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port plip0: on ppbus0 unknown0: at port 0x534-0x537,0x388-0x38b,0x220-0x22f irq 5 drq 1,0 on isa0 unknown1: at port 0x3a0-0x3a7 on isa0 unknown2: at port 0xf00-0xf07 on isa0 unknown3: at port 0x330-0x331 on isa0 ad0: 6149MB [13328/15/63] at ata0-master using UDMA33 ad1: 6149MB [13328/15/63] at ata0-slave using UDMA33 acd0: CDROM at ata1-master using PIO4 Mounting root from ufs:/dev/ad0s1a xl0: starting DAD for fe80:0002::02c0:4fff:feac:9524 xl0: DAD complete for fe80:0002::02c0:4fff:feac:9524 - no duplicates found wx0: link never came up wx0: link never came up wx0: link never came up wx0: starting DAD for fe80:0001::02d0:b7ff:fe45:8549 wx0: link never came up wx0: DAD complete for fe80:0001::02d0:b7ff:fe45:8549 - no duplicates found wx0: link never came up cd9660: RockRidge Extension cd9660: RockRidge Extension cd9660: RockRidge Extension cd9660: RockRidge Extension cd9660: RockRidge Extension wx0: link never came up To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 8 13:26:57 2000 Delivered-To: freebsd-net@freebsd.org Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by hub.freebsd.org (Postfix) with ESMTP id CB00337B761 for ; Tue, 8 Aug 2000 13:26:54 -0700 (PDT) (envelope-from vivek@cs.rice.edu) Received: (from vivek@localhost) by cs.rice.edu (8.9.0/8.9.0) id PAA25413 for freebsd-net@freebsd.org; Tue, 8 Aug 2000 15:26:52 -0500 (CDT) Date: Tue, 8 Aug 2000 15:26:52 -0500 (CDT) From: Vivek Sadananda Pai Message-Id: <200008082026.PAA25413@cs.rice.edu> To: freebsd-net@freebsd.org Subject: Re: Intel Pro/1000 on 4.0-release? Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Please ignore my earlier request - I was kindly sent the following pointer. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/pci/if_wx.c I'll try out the new version of the driver and see what happens Thanks, Vivek To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 8 14:10:53 2000 Delivered-To: freebsd-net@freebsd.org Received: from sn1oexchr02.nextvenue.com (pony.nextvenue.com [209.0.251.199]) by hub.freebsd.org (Postfix) with SMTP id 9C66D37B716 for ; Tue, 8 Aug 2000 14:10:48 -0700 (PDT) (envelope-from nevans@nextvenue.com) Received: FROM sn1exchmbx.nextvenue.com BY sn1oexchr02.nextvenue.com ; Tue Aug 08 17:10:34 2000 -0400 Received: by sn1exchmbx.nextvenue.com with Internet Mail Service (5.5.2650.21) id ; Tue, 8 Aug 2000 17:10:07 -0400 Message-ID: <712384017032D411AD7B0001023D799B33B207@sn1exchmbx.nextvenue.com> From: Nick Evans To: "'freebsd-net@freebsd.org'" Subject: connection limit for ftpd Date: Tue, 8 Aug 2000 17:10:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0017D.0344BC70" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0017D.0344BC70 Content-Type: text/plain; charset="iso-8859-1" Does anyone know where or how I can limit the number of connections to an individual ftp server running ftpd? The archive keeps turning up bandwidth limited solutions, but I need to do this on a connection basis and I'd like to stick with ftpd and not go with wu or some other package... thanks, nick ------------------------------------------ nick.evans network.engineering NextVenue, Inc. phone: (212) 909.2988 pager: (888) 642.5541 ------_=_NextPart_001_01C0017D.0344BC70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable connection limit for ftpd

Does anyone know where or how I can limit the number = of connections to an individual ftp server running ftpd? The archive = keeps turning up bandwidth limited solutions, but I need to do this on = a connection basis and I'd like to stick with ftpd and not go with wu = or some other package...

thanks,
nick

------------------------------------------
nick.evans
network.engineering
NextVenue, Inc.
phone: (212) 909.2988
pager: (888) 642.5541

------_=_NextPart_001_01C0017D.0344BC70-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 8 14:19:34 2000 Delivered-To: freebsd-net@freebsd.org Received: from jade.chc-chimes.com (jade.chc-chimes.com [216.28.46.6]) by hub.freebsd.org (Postfix) with ESMTP id 3A8AE37B695 for ; Tue, 8 Aug 2000 14:19:29 -0700 (PDT) (envelope-from billf@jade.chc-chimes.com) Received: by jade.chc-chimes.com (Postfix, from userid 1001) id 213A51C70; Tue, 8 Aug 2000 17:19:28 -0400 (EDT) Date: Tue, 8 Aug 2000 17:19:28 -0400 From: Bill Fumerola To: Nick Evans Cc: "'freebsd-net@freebsd.org'" Subject: Re: connection limit for ftpd Message-ID: <20000808171928.I95620@jade.chc-chimes.com> References: <712384017032D411AD7B0001023D799B33B207@sn1exchmbx.nextvenue.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <712384017032D411AD7B0001023D799B33B207@sn1exchmbx.nextvenue.com>; from nevans@nextvenue.com on Tue, Aug 08, 2000 at 05:10:00PM -0400 X-Operating-System: FreeBSD 3.3-STABLE i386 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Aug 08, 2000 at 05:10:00PM -0400, Nick Evans wrote: > Does anyone know where or how I can limit the number of connections to an > individual ftp server running ftpd? The archive keeps turning up bandwidth > limited solutions, but I need to do this on a connection basis and I'd like > to stick with ftpd and not go with wu or some other package... man inetd and use questions@freebsd.org next time. -- Bill Fumerola - Network Architect, BOFH / Chimes, Inc. billf@chimesnet.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 Tue Aug 8 15:17: 9 2000 Delivered-To: freebsd-net@freebsd.org Received: from mrout2.yahoo.com (mrout2.yahoo.com [208.48.125.152]) by hub.freebsd.org (Postfix) with ESMTP id C9A3A37B675 for ; Tue, 8 Aug 2000 15:17:04 -0700 (PDT) (envelope-from jayanth@yahoo-inc.com) Received: from milk.yahoo.com (milk.yahoo.com [206.251.16.37]) by mrout2.yahoo.com (8.10.0/8.10.0/y.out) with ESMTP id e78MH0s52602 for ; Tue, 8 Aug 2000 15:17:00 -0700 (PDT) Received: (from jayanth@localhost) by milk.yahoo.com (8.8.8/8.6.12) id PAA16022 for freebsd-net@FreeBSD.ORG; Tue, 8 Aug 2000 15:03:19 -0700 (PDT) Date: Tue, 8 Aug 2000 15:03:19 -0700 From: jayanth To: freebsd-net@FreeBSD.ORG Subject: initial congestion window in the cached route Message-ID: <20000808150319.B22552@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1us Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Another value that could be added to the tcp information cached in the routing table is the initial congestion window (max = max of slowstart_flightsize segments). It will help speed up short transfers which have experienced low latency or loss, which is something that could also be cached. Currently the slowstart_flightsize will be used for all connections. jayanth To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 8 19:34:31 2000 Delivered-To: freebsd-net@freebsd.org Received: from web311.mail.yahoo.com (web311.mail.yahoo.com [216.115.105.76]) by hub.freebsd.org (Postfix) with SMTP id D3A0537B85E for ; Tue, 8 Aug 2000 19:34:27 -0700 (PDT) (envelope-from virtual_olympus@yahoo.com) Message-ID: <20000809023338.12896.qmail@web311.mail.yahoo.com> Received: from [209.103.207.168] by web311.mail.yahoo.com; Tue, 08 Aug 2000 19:33:38 PDT Date: Tue, 8 Aug 2000 19:33:38 -0700 (PDT) From: Benjamin Gavin Subject: Re: NATD and non-UDP/TCP packets To: Ruslan Ermilov Cc: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I'm responding to both of these responses (Mostly because then I can keep my thoughts a little more coherent), so bear with me :). First: --- Ruslan Ermilov wrote: > > these functions, or is there any possibility that these protocols will > be > > included in future NATD versions? > > > You can redirect a particular IP protocol with -redirect_proto rule, or > any protocol with -redirect_address rule. > I'm using 3.5-STABLE, and this "redirect_proto" doesn't exist in natd. Is this an old/deprecated feature, or a new feature of 4.0+?? Does the redirect_proto command (assuming I can use it :) ) only allow for redirection to a single host, or will is perform standard nat on any protocol (sans port)? The redirect_address is not an acceptable solution. The reason I ask is because of the second response I got, which is what I was expecting (and hoping wasn't the case). > Please refer to libalias(3) manual page, section CONCEPTUAL BACKGROUND, > for > more details. Thanks, I'll take a look. -------- Reply to second message >> What are the fundamental differences between ESP/AH and TCP/UDP? > Are >> they inherently more complicated to translate, > >They are designed to be cryptographically secure, and hence, >impossible to NAT. If you want to do NAT, you'll have to terminate >the SAs at the boundary and create an appropriate new set for the >``public'' side. > >-GAWollman Hmmmm... I may be going braindead (P.S. What's an SA?), but will this be possible on the same firewall box?? How will the routing work, even assuming I can get the proper clients for FreeBSD? (Now: I've thought about it more, and do you mean setting up a server-server tunnel, then routing traffic through it and not having the clients have tunnel software installed?? I'm not concerned about the traffic on the local nets, just across the internet. I've done that type of thing before, but I don't know if it will apply to this problem :( ). It may be appropriate to include (which I missed in my original message) that I am running FreeBSD 3.5-STABLE (mentioned earlier), and that I am trying to get the Cisco SafeNet VPN client (yes, I would prefer something else, but I don't have a choice) working from behind it. Cisco doesn't seem to know whether this combination will work (at least none of their on-line docs say it won't), so I am optimistically assuming it can be done. Any creative ideas (and I'm not against hacking the natd daemon)?? Of course, I would prefer if someone had gotten it working and that they just share their secrets :). Thanks, Ben __________________________________________________ Do You Yahoo!? Kick off your party with Yahoo! Invites. http://invites.yahoo.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 9 2:46:18 2000 Delivered-To: freebsd-net@freebsd.org Received: from asustek.asus.com.tw (asustek.asus.com.tw [192.72.126.1]) by hub.freebsd.org (Postfix) with ESMTP id 7D77537B775; Wed, 9 Aug 2000 02:45:44 -0700 (PDT) (envelope-from Thomas_Chen@asus.com.tw) Received: from asusgs1.asus.com.tw ([192.168.4.100]) by asustek.asus.com.tw (8.8.5/8.8.5) with ESMTP id RAA04555; Wed, 9 Aug 2000 17:45:27 +0800 Received: by asusgs1.asus.com.tw with Internet Mail Service (5.5.2448.0) id ; Wed, 9 Aug 2000 17:59:36 +0800 Message-ID: From: =?big5?B?VGhvbWFzIENoZW4os6+n06n3KQ==?= To: freebsd-net@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: cannot be gateway in KDE kppp Date: Wed, 9 Aug 2000 17:59:35 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="big5" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org when I use the ppp in console, it's ok to be a gateway. but in KDE kppp, my machine cannot be a gateway. why? what's the difference? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 9 6: 9:22 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail.wanlogistics.net (mail.wanlogistics.net [63.209.114.3]) by hub.freebsd.org (Postfix) with ESMTP id E9D9B37B6F0 for ; Wed, 9 Aug 2000 06:09:15 -0700 (PDT) (envelope-from chuck@mail.wanlogistics.net) Received: (from chuck@localhost) by mail.wanlogistics.net (8.9.3/8.9.3) id JAA90952 for freebsd-net@freebsd.org; Wed, 9 Aug 2000 09:09:13 -0400 (EDT) (envelope-from chuck) Message-Id: <200008091309.JAA90952@mail.wanlogistics.net> Subject: Re: apparently FreeBSD-specific DNS failure In-Reply-To: from Paul Herman at "Aug 7, 2000 10:42:30 pm" To: freebsd-net@freebsd.org Date: Wed, 9 Aug 2000 09:09:13 -0400 (EDT) Reply-To: bv@wjv.com From: bv@wjv.com Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Reply to: bv@wjv.com X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > On Mon, 7 Aug 2000 sthaug@nethelp.no wrote: > > If you *really* want to open that can of worms, have a look at > > draft-oscarsson-i18ndns-00.txt: > OK, but to sum up (and kill) this thread: The '_' character in domain > names is: > > legal in RFC 1033 > not legal in RFC 1035 > not legal in RFC 1123 > legal in RFC 2181 > legal in draft-oscarsson-i18ndns-00 > However, according to RFC 2400 which names the documents which are > currently standard, required, recommended, elective, proposed, or just > drafts, only RFC 1123 is required. ... > However, I think we can very safely say that (at least on August 7th, > 2000) the '_' character is not a "legal" character in a domain name. I'm surprised this is still biting people. I setup internet connectivity for a local CC about 1994. At that time the docs I read said that _ was going away and was not going to work in future systems. I told the peole cat the college that they had several machines with an undercore in them, and they should make plans to change them, so you can't say this was an entirely unexpected thing - except for those who don't read the information. Of course at that time there were problems with domains with a numeric as their first character - eg 3com for example Bill -- Bill Vermillion - bv@wjv.com. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 9 6:58:11 2000 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 8023F37B999 for ; Wed, 9 Aug 2000 06:58:08 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id JAA18502; Wed, 9 Aug 2000 09:58:08 -0400 (EDT) (envelope-from wollman) Date: Wed, 9 Aug 2000 09:58:08 -0400 (EDT) From: Garrett Wollman Message-Id: <200008091358.JAA18502@khavrinen.lcs.mit.edu> To: Benjamin Gavin Cc: freebsd-net@FreeBSD.ORG Subject: Re: NATD and non-UDP/TCP packets In-Reply-To: <20000809023338.12896.qmail@web311.mail.yahoo.com> References: <20000809023338.12896.qmail@web311.mail.yahoo.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > Hmmmm... I may be going braindead (P.S. What's an SA?), but will this Security Association. IPSEC cryptographic parameters are indexed on both endpoints using the tuple , so if you change either address you have irretrievably corrupted the packet. (The fact that IPSEC can't be NAT'ed is considered by many people to be a Good Thing.) > be possible on the same firewall box?? How will the routing work, even > assuming I can get the proper clients for FreeBSD? (Now: I've thought > about it more, and do you mean setting up a server-server tunnel, then > routing traffic through it and not having the clients have tunnel software > installed?? I'm not concerned about the traffic on the local nets, just > across the internet. I've done that type of thing before, but I don't > know if it will apply to this problem :( ). I can't parse this. > It may be appropriate to include (which I missed in my original message) > that I am running FreeBSD 3.5-STABLE (mentioned earlier), and that I > am You'll need the KAME kit for FreeBSD 3.5 in order to terminate an IPSEC tunnel there. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 9 7:40:41 2000 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (f305.law7.hotmail.com [216.33.236.183]) by hub.freebsd.org (Postfix) with ESMTP id 23D3937BB11; Wed, 9 Aug 2000 07:40:34 -0700 (PDT) (envelope-from johnnyteardrop@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 9 Aug 2000 07:40:27 -0700 Received: from 209.249.186.215 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 09 Aug 2000 GMT X-Originating-IP: [209.249.186.215] From: "Greg Thompson" To: freebsd-hackers@FreeBSD.ORG, freebsd-net@freebsd.org Subject: threadsafe name resolution Date: Wed, 09 Aug 2000 10:40:27 EDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 09 Aug 2000 14:40:27.0286 (UTC) FILETIME=[C23C2360:01C0020F] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org i've just received confirmation from the author of the KAME resolution code that it isn't at all thread safe: >Sure. As noted in name6.c, thread related stuff is not implemented yet. >Since our resolver code based on bind4 doesn't aware thread safeness, >all I can do now would be only putting mutex, anyway. sure enough, name6.c says: /* * TODO for thread safe * use mutex for _hostconf, _hostconf_init. * rewrite resolvers to be thread safe */ now, i'd say that it's fairly important for some form of threadsafe name resolution to exist. until the KAME code is fixed, how about adding in the ipv4 _r methods that have been discussed from time to time? or, at the very least, put something in the manpage for getipnodebyname and friends indicating that the funcs are not threadsafe. as you can probably tell, i wasted several hours worth of work bumping into this problem. -- -greg ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 9 9:51:33 2000 Delivered-To: freebsd-net@freebsd.org Received: from spirit.jaded.net (shortbus.jaded.net [216.94.132.8]) by hub.freebsd.org (Postfix) with ESMTP id B353437BE69; Wed, 9 Aug 2000 09:51:16 -0700 (PDT) (envelope-from dan@spirit.jaded.net) Received: (from dan@localhost) by spirit.jaded.net (8.9.3/8.9.3) id MAA00815; Wed, 9 Aug 2000 12:51:12 -0400 (EDT) (envelope-from dan) Date: Wed, 9 Aug 2000 12:51:12 -0400 From: Dan Moschuk To: Greg Thompson Cc: freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: threadsafe name resolution Message-ID: <20000809125112.C293@spirit.jaded.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from johnnyteardrop@hotmail.com on Wed, Aug 09, 2000 at 10:40:27AM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org | i've just received confirmation from the author of the KAME resolution code | that it isn't at all thread safe: | | >Sure. As noted in name6.c, thread related stuff is not implemented yet. | >Since our resolver code based on bind4 doesn't aware thread safeness, | >all I can do now would be only putting mutex, anyway. | | sure enough, name6.c says: | | /* | * TODO for thread safe | * use mutex for _hostconf, _hostconf_init. | * rewrite resolvers to be thread safe | */ | | now, i'd say that it's fairly important for some form of threadsafe name | resolution to exist. until the KAME code is fixed, how about adding in the | ipv4 _r methods that have been discussed from time to time? or, at the very | least, put something in the manpage for getipnodebyname and friends | indicating that the funcs are not threadsafe. | | as you can probably tell, i wasted several hours worth of work bumping into | this problem. The problem lies deeper than that. Calls like gethostbyname() and friends are not threadsafe either, as they use an internal struct hostent and return a pointer to it (that another thread would happily clobber with its own data). Thread-happy functions we're supposed to be added by the Vixie people, and since I haven't checked up on it in about a year, they could be in there by now, but since we use BINDs name-resolver library, it's a contrib/ issue and our policy isn't to hack up the contrib/ tree. Of course, the door is always open for you to write the code and submit it to the bind team. 8) -Dan -- Man is a rational animal who always loses his temper when he is called upon to act in accordance with the dictates of reason. -- Oscar Wilde To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 9 10:36:38 2000 Delivered-To: freebsd-net@freebsd.org Received: from web313.mail.yahoo.com (web313.mail.yahoo.com [216.115.105.78]) by hub.freebsd.org (Postfix) with SMTP id B9FFB37BB53 for ; Wed, 9 Aug 2000 10:36:21 -0700 (PDT) (envelope-from virtual_olympus@yahoo.com) Message-ID: <20000809173613.15761.qmail@web313.mail.yahoo.com> Received: from [216.163.6.29] by web313.mail.yahoo.com; Wed, 09 Aug 2000 10:36:13 PDT Date: Wed, 9 Aug 2000 10:36:13 -0700 (PDT) From: Benjamin Gavin Subject: Re: NATD and non-UDP/TCP packets To: freebsd-net@FreeBSD.ORG MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, --- Garrett Wollman wrote: > < said: > > > Hmmmm... I may be going braindead (P.S. What's an SA?), but will > this > > Security Association. IPSEC cryptographic parameters are indexed on > both endpoints using the tuple , so if you > change either address you have irretrievably corrupted the packet. > (The fact that IPSEC can't be NAT'ed is considered by many people to > be a Good Thing.) I was wondering if this was the case. It looks like this will cause a major problem :(. It looks like their are some conflicting interests in my current setup (i.e. Wanting to be able to access a tunnel from behind a NATing firewall, and not wanting to terminate the tunnel on the firewall itself.) > > > be possible on the same firewall box?? How will the routing work, > ...... > > know if it will apply to this problem :( ). > > I can't parse this. > Hmm, that doesn't make much sense does it :). I mean this: 1. I've setup server to server tunnels to connect 2 networks before, this works great and accomplishes one of the goals of my setup => secure communications between the two networks. 2. Server-to-Server tunnels is not a viable solution for my current problem. Because there may be many customers which want to use tunnelling for remote access, and since customer network numbers may (and cuurently do) collide, I need a solution which allows the clients (on our network) to initiate the connection (to the remote endpoint) through our NATing firewall. => This doesn't seem to be possible using IPSEC tunnels (i.e. Cisco's SafeNET VPN). It appears that these two constraints are mutually exclusive. I can't NAT IPSEC tunnels, and I can't allow generic server-to-server tunnelling. I just wanted to verify that this is the case, so I didn't spend hours going down a dead end. > > It may be appropriate to include (which I missed in my original > message) > > that I am running FreeBSD 3.5-STABLE (mentioned earlier), and that I > > am > > You'll need the KAME kit for FreeBSD 3.5 in order to terminate an > IPSEC tunnel there. Thanks, I'll take a look at this. Ben Gavin __________________________________________________ Do You Yahoo!? Kick off your party with Yahoo! Invites. http://invites.yahoo.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 9 11: 7:24 2000 Delivered-To: freebsd-net@freebsd.org Received: from houston.matchlogic.com (houston.matchlogic.com [205.216.147.127]) by hub.freebsd.org (Postfix) with ESMTP id 4951A37BE60; Wed, 9 Aug 2000 11:07:15 -0700 (PDT) (envelope-from crandall@matchlogic.com) Received: by houston.matchlogic.com with Internet Mail Service (5.5.2650.21) id ; Wed, 9 Aug 2000 12:07:03 -0600 Message-ID: <5FE9B713CCCDD311A03400508B8B301302978F3E@bdr-xcln.is.matchlogic.com> From: Charles Randall To: Dan Moschuk , Greg Thompson Cc: freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: RE: threadsafe name resolution Date: Wed, 9 Aug 2000 12:07:01 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Is there a reason that ADNS won't work for this? http://www.chiark.greenend.org.uk/~ian/adns/ Charles -----Original Message----- From: Dan Moschuk [mailto:dan@FreeBSD.ORG] Sent: Wednesday, August 09, 2000 10:51 AM To: Greg Thompson Cc: freebsd-hackers@FreeBSD.ORG; freebsd-net@FreeBSD.ORG Subject: Re: threadsafe name resolution | i've just received confirmation from the author of the KAME resolution code | that it isn't at all thread safe: | | >Sure. As noted in name6.c, thread related stuff is not implemented yet. | >Since our resolver code based on bind4 doesn't aware thread safeness, | >all I can do now would be only putting mutex, anyway. | | sure enough, name6.c says: | | /* | * TODO for thread safe | * use mutex for _hostconf, _hostconf_init. | * rewrite resolvers to be thread safe | */ | | now, i'd say that it's fairly important for some form of threadsafe name | resolution to exist. until the KAME code is fixed, how about adding in the | ipv4 _r methods that have been discussed from time to time? or, at the very | least, put something in the manpage for getipnodebyname and friends | indicating that the funcs are not threadsafe. | | as you can probably tell, i wasted several hours worth of work bumping into | this problem. The problem lies deeper than that. Calls like gethostbyname() and friends are not threadsafe either, as they use an internal struct hostent and return a pointer to it (that another thread would happily clobber with its own data). Thread-happy functions we're supposed to be added by the Vixie people, and since I haven't checked up on it in about a year, they could be in there by now, but since we use BINDs name-resolver library, it's a contrib/ issue and our policy isn't to hack up the contrib/ tree. Of course, the door is always open for you to write the code and submit it to the bind team. 8) -Dan -- Man is a rational animal who always loses his temper when he is called upon to act in accordance with the dictates of reason. -- Oscar Wilde 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 Wed Aug 9 11:15:22 2000 Delivered-To: freebsd-net@freebsd.org Received: from spirit.jaded.net (shortbus.jaded.net [216.94.132.8]) by hub.freebsd.org (Postfix) with ESMTP id 5703337C0BE; Wed, 9 Aug 2000 11:15:12 -0700 (PDT) (envelope-from dan@spirit.jaded.net) Received: (from dan@localhost) by spirit.jaded.net (8.9.3/8.9.3) id OAA01367; Wed, 9 Aug 2000 14:14:56 -0400 (EDT) (envelope-from dan) Date: Wed, 9 Aug 2000 14:14:56 -0400 From: Dan Moschuk To: Charles Randall Cc: Greg Thompson , freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: threadsafe name resolution Message-ID: <20000809141456.L293@spirit.jaded.net> References: <5FE9B713CCCDD311A03400508B8B301302978F3E@bdr-xcln.is.matchlogic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <5FE9B713CCCDD311A03400508B8B301302978F3E@bdr-xcln.is.matchlogic.com>; from crandall@matchlogic.com on Wed, Aug 09, 2000 at 12:07:01PM -0600 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org | Is there a reason that ADNS won't work for this? | | http://www.chiark.greenend.org.uk/~ian/adns/ Technically, no. Morally, it's GNU. :-) -- Man is a rational animal who always loses his temper when he is called upon to act in accordance with the dictates of reason. -- Oscar Wilde To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 9 11:21:28 2000 Delivered-To: freebsd-net@freebsd.org Received: from lindt.urgle.com (lindt.urgle.com [195.173.172.169]) by hub.freebsd.org (Postfix) with ESMTP id 4F9EF37BA7D; Wed, 9 Aug 2000 11:21:19 -0700 (PDT) (envelope-from mike@urgle.com) Received: from mike by lindt.urgle.com with local (Exim 3.03 #1) id 13MaTQ-000478-00; Wed, 09 Aug 2000 19:21:04 +0100 Date: Wed, 9 Aug 2000 19:21:04 +0100 From: Mike Bristow To: Charles Randall Cc: Dan Moschuk , Greg Thompson , freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: threadsafe name resolution Message-ID: <20000809192104.A15793@lindt.urgle.com> References: <5FE9B713CCCDD311A03400508B8B301302978F3E@bdr-xcln.is.matchlogic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <5FE9B713CCCDD311A03400508B8B301302978F3E@bdr-xcln.is.matchlogic.com>; from crandall@matchlogic.com on Wed, Aug 09, 2000 at 12:07:01PM -0600 X-Rated: IRA, insider dealing Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Aug 09, 2000 at 12:07:01PM -0600, Charles Randall wrote: > Is there a reason that ADNS won't work for this? Firstly, adns doesn't do IPv6 (at least not yet, according to the web page you gave). Secondly, I'm not sure if it's thread safe (although being nice 'n async it's not hard to use it in threaded apps even if it isn't). Thirdly, adns is GPLed, which means you'll have a hell of a job getting people to include it into the base system. -- Mike Bristow, seebitwopie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 9 11:36:52 2000 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (f39.law7.hotmail.com [216.33.237.39]) by hub.freebsd.org (Postfix) with ESMTP id 6EBCD37BA1C; Wed, 9 Aug 2000 11:36:44 -0700 (PDT) (envelope-from johnnyteardrop@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 9 Aug 2000 11:36:40 -0700 Received: from 209.249.186.215 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 09 Aug 2000 GMT X-Originating-IP: [209.249.186.215] From: "Greg Thompson" To: crandall@matchlogic.com Cc: freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: RE: threadsafe name resolution Date: Wed, 09 Aug 2000 14:36:40 EDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 09 Aug 2000 18:36:40.0153 (UTC) FILETIME=[C1EC0490:01C00230] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >From: Charles Randall > >Is there a reason that ADNS won't work for this? > >http://www.chiark.greenend.org.uk/~ian/adns/ in addition to the other reasons mentioned, it won't work for me because it's not a part of the os. as an application developer, i'd expect the basic services to work without me having to grab random packages to solve already solved problems. someone else pointed out that the old gethostbyname/addr pair isn't threadsafe. i realize this. what i was suggesting is that someone could perhaps implement gethostbyname_r and gethostbyaddr_r. call these a hack if you will, but they solve the problem just fine on other platforms. as long as nothing other than getipnodebyname and byaddr share resources with those two, i'm safe if i just throw a mutex around my calls to byname/addr. unfortuantely, this solution gets the "big suck" rating. if the operating system ships with mechanisms that are documented as being thread-safe, they should be. if they're not, it should be clearly stated in a bug report somewhere that this is the case. i have submitted a bug with KAME. i hope they fix it soon. in the meantime, it'd be nice if freebsd had an alternative. ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 9 14:14:51 2000 Delivered-To: freebsd-net@freebsd.org Received: from lychee.itojun.org (h066.p043.iij4u.or.jp [210.130.43.66]) by hub.freebsd.org (Postfix) with ESMTP id 9FC9C37BA28; Wed, 9 Aug 2000 14:14:47 -0700 (PDT) (envelope-from itojun@itojun.org) Received: from kiwi.itojun.org (localhost [127.0.0.1]) by itojun.org (8.10.0/3.7W) with ESMTP id e79LEI610855; Thu, 10 Aug 2000 06:14:18 +0900 (JST) Message-Id: <200008092114.e79LEI610855@itojun.org> To: "Greg Thompson" Cc: crandall@matchlogic.com, freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG In-reply-to: johnnyteardrop's message of Wed, 09 Aug 2000 14:36:40 EDT. 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: threadsafe name resolution From: Jun-ichiro itojun Hagino Date: Thu, 10 Aug 2000 06:14:18 +0900 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >as long as nothing other than getipnodebyname and byaddr share resources >with those two, i'm safe if i just throw a mutex around my calls to >byname/addr. unfortuantely, this solution gets the "big suck" rating. if >the operating system ships with mechanisms that are documented as being >thread-safe, they should be. if they're not, it should be clearly stated in >a bug report somewhere that this is the case. i have submitted a bug with >KAME. i hope they fix it soon. in the meantime, it'd be nice if freebsd >had an alternative. sorry for bad documentation, manpage should be updated to state "the current implementation is not thread safe" in BUGS section. 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 10 4:17:34 2000 Delivered-To: freebsd-net@freebsd.org Received: from philos.philosys.de (philos.philosys.de [193.100.254.1]) by hub.freebsd.org (Postfix) with ESMTP id C396837BDD0 for ; Thu, 10 Aug 2000 04:17:25 -0700 (PDT) (envelope-from Roland.Geier@philosys.de) Received: from philosys.de (intranet.philosys.de [193.100.254.65]) by philos.philosys.de (8.8.8/8.8.8) with ESMTP id NAA20867 for ; Thu, 10 Aug 2000 13:19:56 +0200 (MET DST) Message-ID: <39928FDB.28E687B9@philosys.de> Date: Thu, 10 Aug 2000 13:19:55 +0200 From: Roland Geier Organization: Philosys Software GmbH X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.15 i586) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: syn received on half open connection Content-Type: multipart/mixed; boundary="------------F97D64E3D6AEC89A5AB8798B" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a multi-part message in MIME format. --------------F97D64E3D6AEC89A5AB8798B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, I've got a question concerning the fits-to-specs-behaviour of BSD derived tcp implementations when a syn is received on half open connections. Therefore, please assume the scenario that is pointed out in rfc793, section 'Half-Open Connections and Other Anomalies': --------------- excerpt from rfc793 --------------- Assume that two user processes A and B are communicating with one another when a crash occurs causing loss of memory to A's TCP. Depending on the operating system supporting A's TCP, it is likely that some error recovery mechanism exists. When the TCP is up again, A is likely to start again from the beginning or from a recovery point. As a result, A will probably try to OPEN the connection again or try to SEND on the connection it believes open. In the latter case, it receives the error message "connection not open" from the local (A's) TCP. In an attempt to establish the connection, A's TCP will send a segment containing SYN. This scenario leads to the example shown in figure 10. After TCP A crashes, the user attempts to re-open the connection. TCP B, in the meantime, thinks the connection is open. TCP A TCP B 1. (CRASH) (send 300,receive 100) 2. CLOSED ESTABLISHED 3. SYN-SENT --> --> (??) 4. (!!) <-- <-- ESTABLISHED 5. SYN-SENT --> --> (Abort!!) 6. SYN-SENT CLOSED 7. SYN-SENT --> --> When the SYN arrives at line 3, TCP B, being in a synchronized state, and the incoming segment outside the window, responds with an acknowledgment indicating what sequence it next expects to hear (ACK 100). TCP A sees that this segment does not acknowledge anything it sent and, being unsynchronized, sends a reset (RST) because it has detected a half-open connection. TCP B aborts at line 5. TCP A will continue to try to establish the connection; the problem is now reduced to the basic 3-way handshake. --------------- end of excerpt --------------- I assume two different cases when the SYN arrives on a half open connection: (a) the SYN packet's ISS is *within* the receive window of TCP B (b) the SYN packet's ISS is *not* within the receive window of TCP B AS shown in [Code A] (see TCP/IP Illustrated Vol. II, Fig. 28.37), case (a) is considered to be an error and BSD implementations will send a RST and drop the connection: ----- [Code A] ----- /* * If a SYN is in the window, then this is an * error and we send an RST and drop the connection. */ if (tiflags & TH_SYN) { tp = tcp_drop(tp, ECONNRESET); goto dropwithreset; } Let's now assume case (b), i.e. the syn is *not* in the window. In this case the SYN-Flag is explicitly switched off (see [Code B], taken from Fig. 28.24): ----- [Code B] ----- todrop = tp->rcv_nxt - ti->ti_seq; if (todrop > 0) { if (tiflags & TH_SYN) { tiflags &= ~TH_SYN; ti->ti_seq++; : } As [Code B] is located before [Code A], BSD won't send a reset if the syn is *not* within the window as the SYN bit was explicitly reset. Furthermore, [Code C] (see Fig. 28.37 again), directly following [Code A], states: ----- [Code C] ----- /* * If the ACK bit is off we drop the segment and return. */ if ((tiflags & TH_ACK) == 0) goto drop; As in an initial SYN request the ACK bit isn't set, a SYN request that does not fall into the window will be silently dropped in BSD instead of sending an ACK before dropping the packet. If I did not miss the point, this behaviour violates the spec. A colleague of mine found out that the original implementation did not trigger this bug (see. Fig 28.25) as the 'goto dropafterack' in line 671 forced an ACK to be sent. The correction suggested in Fig. 28.30 doesn't do that. Suggested fix: Use the 'TF_ACKNOW'-marker set in Fig. 28.30 to trigger the ACK later on. Attached you'll find a patch for tcp_input.c (Version 1.118). I'd like to open this patch for discussion. Roland --------------F97D64E3D6AEC89A5AB8798B Content-Type: text/plain; charset=us-ascii; name="synpatch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="synpatch" *** tcp_input.c-1.118 Thu Aug 10 11:45:05 2000 --- tcp_input.c Thu Aug 10 11:52:06 2000 *************** *** 1678,1686 **** if (tp->t_state == TCPS_SYN_RECEIVED || (tp->t_flags & TF_NEEDSYN)) goto step6; ! else ! goto drop; ! } /* * Ack processing. --- 1678,1694 ---- if (tp->t_state == TCPS_SYN_RECEIVED || (tp->t_flags & TF_NEEDSYN)) goto step6; ! /* ! * if we want resynchronization ack's to be generated, ! * here is the place to do it: the marker set above now ! * can be evaluated and jumping to dropafterack will then ! * generate the resynchronization ack. ! */ ! else if (tp->t_flags & TF_ACKNOW) ! goto dropafterack; ! else ! goto drop; ! } /* * Ack processing. --------------F97D64E3D6AEC89A5AB8798B-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 10 13:39:50 2000 Delivered-To: freebsd-net@freebsd.org Received: from gvr.gvr.org (gvr.gvr.org [194.151.74.97]) by hub.freebsd.org (Postfix) with ESMTP id BBCA437BA88 for ; Thu, 10 Aug 2000 13:39:41 -0700 (PDT) (envelope-from guido@gvr.org) Received: by gvr.gvr.org (Postfix, from userid 657) id CAE7A5807; Thu, 10 Aug 2000 22:39:37 +0200 (CEST) Date: Thu, 10 Aug 2000 22:39:37 +0200 From: Guido van Rooij To: freebsd-net@freebsd.org Cc: John Polstra Subject: Perhaps a TCP stack problem? Message-ID: <20000810223937.A24172@gvr.gvr.org> References: <20000810095049.C17481@gvr.gvr.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: ; from John Polstra on Thu, Aug 10, 2000 at 06:53:53AM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org A couple of days ago, I discovered that the cvsup server kept sending my system ACKs where my firewall in between thought that the connection was long gone. The firewall does have the policy to just send a RST in response. However, the RST sent was incorrect: 22:14:52.807104 AAA.BBB.CCC.DDD.5999 > UUU.VVV.WWW.XXX.1035: . 145135143:145135144(1) ack 40231428 win 17520 (DF) 22:14:52.808313 UUU.VVV.WWW.XXX.1035 > AAA.BBB.CCC.DDD.5999: R 4254735869:4254735869(0) ack 0 win 0 (never mind why, that is not the issue). On the cvsup we see the following tcp 0 17190 AAA.BBB.CCC.DDD.5999 UUU.VVV.WWW.XXX.1035 FIN_WAIT_1 It seems that tcp_timer.c:tcp_timer_persist() does not get into the following if-clause (which should also be in your code): if (tp->t_rxtshift == TCP_MAXRXTSHIFT && ((ticks - tp->t_rcvtime) >= tcp_maxpersistidle || (ticks - tp->t_rcvtime) >= TCP_REXMTVAL(tp) * tcp_totbackoff)) { tcpstat.tcps_persistdrop++; tp = tcp_drop(tp, ETIMEDOUT); goto out; } The reason for that is that after a protocol control block has been found that match the address/port combination of the incoming RST, the TCP stack immediately increases tp->t_rcvtime. This on turn means that ticks - tp->t_rcvtime will never be larger then a couple of ticks. I am not sure but I guess that in certain cases, like if incoming packet makes absolutely no sense given the current windows and sequence numbers, tp->t_rcvtime should not be increased. I am not sure what the standards have to say about this but it seems easy to detect this kind of situation and make sure that the persist will eventually time out. Right now it seems that a broken TCP stack on the other side will prevend that. -Guido To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 10 14: 9:10 2000 Delivered-To: freebsd-net@freebsd.org Received: from gvr.gvr.org (gvr.gvr.org [194.151.74.97]) by hub.freebsd.org (Postfix) with ESMTP id 6353437BADF for ; Thu, 10 Aug 2000 14:09:05 -0700 (PDT) (envelope-from guido@gvr.org) Received: by gvr.gvr.org (Postfix, from userid 657) id EBC155807; Thu, 10 Aug 2000 23:09:03 +0200 (CEST) Date: Thu, 10 Aug 2000 23:09:03 +0200 From: Guido van Rooij To: freebsd-net@freebsd.org Cc: John Polstra Subject: Re: Perhaps a TCP stack problem? Message-ID: <20000810230903.A25260@gvr.gvr.org> References: <20000810095049.C17481@gvr.gvr.org> <20000810223937.A24172@gvr.gvr.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <20000810223937.A24172@gvr.gvr.org>; from Guido van Rooij on Thu, Aug 10, 2000 at 10:39:37PM +0200 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Aug 10, 2000 at 10:39:37PM +0200, Guido van Rooij wrote: > A couple of days ago, I discovered that the cvsup server kept sending > my system ACKs where my firewall in between thought that the connection > was long gone. The firewall does have the policy to just send a RST > in response. However, the RST sent was incorrect: > > 22:14:52.807104 AAA.BBB.CCC.DDD.5999 > UUU.VVV.WWW.XXX.1035: . 145135143:145135144(1) ack 40231428 win 17520 (DF) > 22:14:52.808313 UUU.VVV.WWW.XXX.1035 > AAA.BBB.CCC.DDD.5999: R 4254735869:4254735869(0) ack 0 win 0 When looking further, the RST _is_ correct. It is just my tcpdump that was broken. Here are the packets: 4500 0029 de3e 4000 3406 73a6 AAAA BBBB CCCC DDDD 176f 040b 08a6 9627 0265 e204 5010 4470 7cc7 0000 5b 4500 0028 4fb3 0000 4006 3633 CCCC DDDD AAAA BBBB 040b 176f 0000 0000 08a6 9627 5014 0000 009f 0000 The SEQ field in the RST packet is set to 0. Looking at the relevant section in ip_input.c: if (thflags & TH_RST) { if (SEQ_GEQ(th->th_seq, tp->last_ack_sent) && SEQ_LT(th->th_seq, tp->last_ack_sent + tp->rcv_wnd)) { switch (tp->t_state) { .... case TCPS_FIN_WAIT_1: case TCPS_FIN_WAIT_2: case TCPS_CLOSE_WAIT: so->so_error = ECONNRESET; close: tp->t_state = TCPS_CLOSED; tcpstat.tcps_drops++; tp = tcp_close(tp); break; .... } /* here we want an else clause; see below */ } goto drop; That means that if the RST does not contain a sequence number we expect, we just drop the packet. But that is certainly broken: if a host goes down and comes backup before the persist state was timed out, we will never timeout as the RST do have unexpected sequence numbers with rather high probability. IMHO, tp->t_rcvtime should be reset in an else {} clause just above the 'goto drop;' statement in the above piece of code. -Guido -Guido To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 10 14:29:24 2000 Delivered-To: freebsd-net@freebsd.org Received: from gvr.gvr.org (gvr.gvr.org [194.151.74.97]) by hub.freebsd.org (Postfix) with ESMTP id 3916E37BAB5 for ; Thu, 10 Aug 2000 14:29:18 -0700 (PDT) (envelope-from guido@gvr.org) Received: by gvr.gvr.org (Postfix, from userid 657) id 14DE55808; Thu, 10 Aug 2000 23:29:16 +0200 (CEST) Date: Thu, 10 Aug 2000 23:29:16 +0200 From: Guido van Rooij To: freebsd-net@freebsd.org Cc: John Polstra Subject: Re: Perhaps a TCP stack problem? Message-ID: <20000810232916.A25672@gvr.gvr.org> References: <20000810095049.C17481@gvr.gvr.org> <20000810223937.A24172@gvr.gvr.org> <20000810230903.A25260@gvr.gvr.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <20000810230903.A25260@gvr.gvr.org>; from Guido van Rooij on Thu, Aug 10, 2000 at 11:09:03PM +0200 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Aug 10, 2000 at 11:09:03PM +0200, Guido van Rooij wrote: > On Thu, Aug 10, 2000 at 10:39:37PM +0200, Guido van Rooij wrote: > > A couple of days ago, I discovered that the cvsup server kept sending > > my system ACKs where my firewall in between thought that the connection > > was long gone. The firewall does have the policy to just send a RST > > in response. However, the RST sent was incorrect: > > > > 22:14:52.807104 AAA.BBB.CCC.DDD.5999 > UUU.VVV.WWW.XXX.1035: . 145135143:145135144(1) ack 40231428 win 17520 (DF) > > 22:14:52.808313 UUU.VVV.WWW.XXX.1035 > AAA.BBB.CCC.DDD.5999: R 4254735869:4254735869(0) ack 0 win 0 > > When looking further, the RST _is_ correct. It is just my tcpdump that was > broken. Here are the packets: Please disregard this second email. The first one was correct after all. (the sequence number of the RST should have been set to the ACK value of the first packet). -Guido To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 10 20:57:21 2000 Delivered-To: freebsd-net@freebsd.org Received: from obie.softweyr.com (obie.softweyr.com [204.68.178.33]) by hub.freebsd.org (Postfix) with ESMTP id EEA6237B6ED; Thu, 10 Aug 2000 20:57:15 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from softweyr.com (Foolstrustident!@homer.softweyr.com [204.68.178.39]) by obie.softweyr.com (8.8.8/8.8.8) with ESMTP id VAA07160; Thu, 10 Aug 2000 21:57:12 -0600 (MDT) (envelope-from wes@softweyr.com) Message-ID: <39937AED.7A9DCAE@softweyr.com> Date: Thu, 10 Aug 2000 22:02:53 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.1-RC i386) X-Accept-Language: en MIME-Version: 1.0 To: Greg Thompson Cc: freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: threadsafe name resolution References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Greg Thompson wrote: > > i've just received confirmation from the author of the KAME resolution code > that it isn't at all thread safe: > > >Sure. As noted in name6.c, thread related stuff is not implemented yet. > >Since our resolver code based on bind4 doesn't aware thread safeness, > >all I can do now would be only putting mutex, anyway. > > sure enough, name6.c says: > > /* > * TODO for thread safe > * use mutex for _hostconf, _hostconf_init. > * rewrite resolvers to be thread safe > */ > > now, i'd say that it's fairly important for some form of threadsafe name > resolution to exist. until the KAME code is fixed, how about adding in the > ipv4 _r methods that have been discussed from time to time? or, at the very > least, put something in the manpage for getipnodebyname and friends > indicating that the funcs are not threadsafe. > > as you can probably tell, i wasted several hours worth of work bumping into > this problem. I've been working on fleshing out the _r routines for quite some time now. I've done all the easy ones, and the ones you're looking for are just screaming butt-ugly. It would be simple enough to create a mutex-protected variant of each, but that's not nearly as good a solution as make a REAL _r implementation. If you have implementations to offer, I'd be quite happy to review and commit them. I haven't had enough spare time to even crack the code in months now, unfortunately. -- "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 Thu Aug 10 23:42:20 2000 Delivered-To: freebsd-net@freebsd.org Received: from mrout1.yahoo.com (mrout1.yahoo.com [208.48.125.95]) by hub.freebsd.org (Postfix) with ESMTP id 38DEC37BF20 for ; Thu, 10 Aug 2000 23:42:13 -0700 (PDT) (envelope-from jayanth@yahoo-inc.com) Received: from milk.yahoo.com (milk.yahoo.com [206.251.16.37]) by mrout1.yahoo.com (8.10.0/8.10.0/y.out) with ESMTP id e7B6ff720262; Thu, 10 Aug 2000 23:41:42 -0700 (PDT) Received: (from jayanth@localhost) by milk.yahoo.com (8.8.8/8.6.12) id XAA09869; Thu, 10 Aug 2000 23:41:40 -0700 (PDT) Date: Thu, 10 Aug 2000 23:41:40 -0700 From: jayanth To: Guido van Rooij Cc: freebsd-net@FreeBSD.ORG, John Polstra Subject: Re: Perhaps a TCP stack problem? Message-ID: <20000810234140.B8997@yahoo-inc.com> References: <20000810095049.C17481@gvr.gvr.org> <20000810223937.A24172@gvr.gvr.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1us In-Reply-To: <20000810223937.A24172@gvr.gvr.org>; from guido@gvr.org on Thu, Aug 10, 2000 at 10:39:37PM +0200 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org It makes sense not to update tp->t_rcvtime for invalid sequence nos. We could always add a check to see if the sequence number falls within the expected window and then update t_rcvtime. In tcp_input.c we could do the following: if (SEQ_GEQ(th->th_seq, tp->last_ack_sent) && SEQ_LT(th->th_seq, tp->last_ack_sent + tp->rcv_wnd)) tp->t_rcvtime = ticks; jayanth Guido van Rooij (guido@gvr.org) wrote: > A couple of days ago, I discovered that the cvsup server kept sending > my system ACKs where my firewall in between thought that the connection > was long gone. The firewall does have the policy to just send a RST > in response. However, the RST sent was incorrect: > > 22:14:52.807104 AAA.BBB.CCC.DDD.5999 > UUU.VVV.WWW.XXX.1035: . 145135143:145135144(1) ack 40231428 win 17520 (DF) > 22:14:52.808313 UUU.VVV.WWW.XXX.1035 > AAA.BBB.CCC.DDD.5999: R 4254735869:4254735869(0) ack 0 win 0 > > (never mind why, that is not the issue). On the cvsup we see the following > tcp 0 17190 AAA.BBB.CCC.DDD.5999 UUU.VVV.WWW.XXX.1035 FIN_WAIT_1 > > It seems that tcp_timer.c:tcp_timer_persist() does not get into the > following if-clause (which should also be in your code): > > if (tp->t_rxtshift == TCP_MAXRXTSHIFT && > ((ticks - tp->t_rcvtime) >= tcp_maxpersistidle || > (ticks - tp->t_rcvtime) >= TCP_REXMTVAL(tp) * tcp_totbackoff)) { > tcpstat.tcps_persistdrop++; > tp = tcp_drop(tp, ETIMEDOUT); > goto out; > } > > The reason for that is that after a protocol control block has been > found that match the address/port combination of the incoming RST, > the TCP stack immediately increases tp->t_rcvtime. > This on turn means that ticks - tp->t_rcvtime will never be larger > then a couple of ticks. > I am not sure but I guess that in certain cases, like if incoming packet > makes absolutely no sense given the current windows and sequence > numbers, tp->t_rcvtime should not be increased. > > I am not sure what the standards have to say about this but it seems > easy to detect this kind of situation and make sure that the persist > will eventually time out. Right now it seems that a broken TCP stack > on the other side will prevend that. > > -Guido > > > 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 11 6: 4:58 2000 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 9B23137C11E for ; Fri, 11 Aug 2000 06:04:49 -0700 (PDT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from localhost (shuttle.sixyards.wide.toshiba.co.jp [3ffe:501:100f:0:200:f8ff:fe01:61cf]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id VAA05097 for ; Fri, 11 Aug 2000 21:50:49 +0900 (JST) Date: Fri, 11 Aug 2000 22:00:41 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: net@FreeBSD.ORG Subject: a serious bug fix about IPv6 for 4.1 and current User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.6 Mule/4.0 (HANANOEN) 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: 48 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, We recently found a serios bug, which might cause kernel crash, in IPv6 code developed by the KAME project. Unfortunately, the bug has been merged into FreeBSD 4.1 (and current), and we confirmed kernel crash could happen on "pure" FreeBSD 4.1, too. The attached is a patch for FreeBSD 4.1 to fix the problem. If you enable IPv6 on FreeBSD 4.1 or current, please be sure to apply the fix. Also, I believe that it should be merged into the FreeBSD repository (I can't do this by myself, since I'm not a committer. Sorry about that). I'd really apologize for the messy bug. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp *** nd6_rtr.c.orig Fri Aug 11 21:55:40 2000 --- nd6_rtr.c Fri Aug 11 21:56:34 2000 *************** *** 549,557 **** #ifdef ND6_USE_RTSOCK defrouter_msg(RTM_DELETE, oldrt); #endif ! if (oldrt->rt_refcnt <= 0) ! oldrt->rt_refcnt++; /* XXX */ ! rtfree(oldrt); } if (dofree) /* XXX: necessary? */ --- 549,562 ---- #ifdef ND6_USE_RTSOCK defrouter_msg(RTM_DELETE, oldrt); #endif ! if (oldrt->rt_refcnt <= 0) { ! /* ! * XXX: borrowed from the RTM_DELETE case of ! * rtrequest(). ! */ ! oldrt->rt_refcnt++; ! rtfree(oldrt); ! } } if (dofree) /* XXX: necessary? */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 11 17:22:13 2000 Delivered-To: freebsd-net@freebsd.org Received: from gatekeeper.whistle.com (gatekeeper.whistle.com [207.76.204.2]) by hub.freebsd.org (Postfix) with ESMTP id 8E2EB37BD44; Fri, 11 Aug 2000 17:21:59 -0700 (PDT) (envelope-from archie@whistle.com) Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by gatekeeper.whistle.com (8.9.3/8.9.3) with ESMTP id RAA13624; Fri, 11 Aug 2000 17:21:57 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.3) id RAA51816; Fri, 11 Aug 2000 17:21:57 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200008120021.RAA51816@bubba.whistle.com> Subject: SIOCSIFLLADDR ioctl() patch To: freebsd-net@freebsd.org Date: Fri, 11 Aug 2000 17:21:57 -0700 (PDT) Cc: wpaul@freebsd.org, rwatson@freebsd.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Anyone care to review this patch? I've tried to block a couple of things that would crash the kernel, e.g., calling SIOCSIFLLADDR on an interface type that doesn't use struct arpcom in ifp->if_softc. The ulterior motive is to export if_setlladdr() so that ng_ether(4) can hook into it. Thanks, -Archie P.S. Is IFT_8021_VLAN ever going to get promoted from if_vlan_var.h to if_types.h? ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com Index: if.c =================================================================== RCS file: /home/ncvs/src/sys/net/if.c,v retrieving revision 1.91 diff -u -r1.91 if.c --- if.c 2000/07/16 01:46:42 1.91 +++ if.c 2000/08/12 00:20:14 @@ -54,6 +54,7 @@ #include #include #include +#include #include #include @@ -762,8 +763,6 @@ { register struct ifnet *ifp; register struct ifreq *ifr; - register struct ifaddr *ifa; - struct sockaddr_dl *sdl; struct ifstat *ifs; int error; short oif_flags; @@ -917,29 +916,9 @@ error = suser(p); if (error) return (error); - ifa = ifnet_addrs[ifp->if_index - 1]; - if (ifa == NULL) - return(EINVAL); - sdl = (struct sockaddr_dl *)ifa->ifa_addr; - if (sdl == NULL) - return(EINVAL); - bcopy(ifr->ifr_addr.sa_data, - ((struct arpcom *)ifp->if_softc)->ac_enaddr, - ifr->ifr_addr.sa_len); - bcopy(ifr->ifr_addr.sa_data, LLADDR(sdl), - ifr->ifr_addr.sa_len); - /* - * If the interface is already up, we need - * to re-init it in order to reprogram its - * address filter. - */ - if (ifp->if_flags & IFF_UP) { - ifp->if_flags &= ~IFF_UP; - (*ifp->if_ioctl)(ifp, SIOCSIFFLAGS, NULL); - ifp->if_flags |= IFF_UP; - (*ifp->if_ioctl)(ifp, SIOCSIFFLAGS, NULL); - } - return(0); + return if_setlladdr(ifp, + ifr->ifr_addr.sa_data, ifr->ifr_addr.sa_len); + default: oif_flags = ifp->if_flags; if (so->so_proto == 0) @@ -1337,6 +1316,52 @@ free(ifma, M_IFMADDR); return 0; +} + +/* + * Set the link layer address on an interface. + * + * At this time we only support certain types of interfaces, + * and we don't allow the length of the address to change. + */ +int +if_setlladdr(struct ifnet *ifp, const u_char *lladdr, int len) +{ + struct sockaddr_dl *sdl; + struct ifaddr *ifa; + + ifa = ifnet_addrs[ifp->if_index - 1]; + if (ifa == NULL) + return (EINVAL); + sdl = (struct sockaddr_dl *)ifa->ifa_addr; + if (sdl == NULL) + return (EINVAL); + if (len != sdl->sdl_alen) /* don't allow length to change */ + return (EINVAL); + switch (ifp->if_type) { + case IFT_ETHER: /* these types use struct arpcom */ + case IFT_FDDI: + case IFT_XETHER: + case IFT_ISO88025: + case IFT_PROPVIRTUAL: /* XXX waiting for IFT_8021_VLAN */ + bcopy(lladdr, ((struct arpcom *)ifp->if_softc)->ac_enaddr, len); + bcopy(lladdr, LLADDR(sdl), len); + break; + default: + return (ENODEV); + } + /* + * If the interface is already up, we need + * to re-init it in order to reprogram its + * address filter. + */ + if ((ifp->if_flags & IFF_UP) != 0) { + ifp->if_flags &= ~IFF_UP; + (*ifp->if_ioctl)(ifp, SIOCSIFFLAGS, NULL); + ifp->if_flags |= IFF_UP; + (*ifp->if_ioctl)(ifp, SIOCSIFFLAGS, NULL); + } + return (0); } struct ifmultiaddr * Index: if_var.h =================================================================== RCS file: /home/ncvs/src/sys/net/if_var.h,v retrieving revision 1.25 diff -u -r1.25 if_var.h --- if_var.h 2000/07/13 22:54:30 1.25 +++ if_var.h 2000/08/12 00:20:14 @@ -340,6 +340,7 @@ void if_detach __P((struct ifnet *)); void if_down __P((struct ifnet *)); void if_route __P((struct ifnet *, int flag, int fam)); +int if_setlladdr __P((struct ifnet *, const u_char *, int)); void if_unroute __P((struct ifnet *, int flag, int fam)); void if_up __P((struct ifnet *)); /*void ifinit __P((void));*/ /* declared in systm.h for main() */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 11 18: 7:23 2000 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 2B8D737BA48 for ; Fri, 11 Aug 2000 18:07:19 -0700 (PDT) (envelope-from itojun@itojun.org) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id KAA27154; Sat, 12 Aug 2000 10:07:16 +0900 (JST) To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: net@FreeBSD.ORG In-reply-to: jinmei's message of Fri, 11 Aug 2000 22:00:41 JST. 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: a serious bug fix about IPv6 for 4.1 and current From: itojun@iijlab.net Date: Sat, 12 Aug 2000 10:07:16 +0900 Message-ID: <27152.966042436@coconut.itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >We recently found a serios bug, which might cause kernel crash, in >IPv6 code developed by the KAME project. Unfortunately, the bug has >been merged into FreeBSD 4.1 (and current), and we confirmed kernel >crash could happen on "pure" FreeBSD 4.1, too. > >The attached is a patch for FreeBSD 4.1 to fix the problem. If you >enable IPv6 on FreeBSD 4.1 or current, please be sure to apply the >fix. Also, I believe that it should be merged into the FreeBSD >repository (I can't do this by myself, since I'm not a >committer. Sorry about that). > >I'd really apologize for the messy bug. The patch is in freebsd repository, main trunc and RELENG_4 branch. netbsd-current, netbsd 1.5_ALPHA, openbsd 2.7, openbsd-current are not affected. 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 11 22:50:27 2000 Delivered-To: freebsd-net@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [63.67.141.99]) by hub.freebsd.org (Postfix) with ESMTP id 9728A37B69D for ; Fri, 11 Aug 2000 22:50:24 -0700 (PDT) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.9.3/8.8.7) with ESMTP id BAA23218; Sat, 12 Aug 2000 01:50:11 -0400 (EDT) Date: Sat, 12 Aug 2000 01:50:11 -0400 (EDT) From: "Matthew N. Dodd" To: "Andrew C. Hornback" Cc: "'Ian Smith'" , freebsd-net@FreeBSD.ORG Subject: RE: Solved: Intel 'Pro 4041' card? In-Reply-To: <003d01c000e4$38c768f0$d4776bce@challenger> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 7 Aug 2000, Andrew C. Hornback wrote: > From my experience with Intel networking hardware, those are good > cards, and there should be a driver available for them. The cards aren't too daffy but the driver is a little raw around the edges. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Aug 12 8:29:13 2000 Delivered-To: freebsd-net@freebsd.org Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by hub.freebsd.org (Postfix) with ESMTP id B283937BDB4 for ; Sat, 12 Aug 2000 08:29:07 -0700 (PDT) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.0) with SMTP id BAA11712; Sun, 13 Aug 2000 01:28:27 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sun, 13 Aug 2000 01:28:27 +1000 (EST) From: Ian Smith To: "Matthew N. Dodd" Cc: "Andrew C. Hornback" , freebsd-net@FreeBSD.ORG Subject: RE: Solved: Intel 'Pro 4041' card? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 12 Aug 2000, Matthew N. Dodd wrote: > On Mon, 7 Aug 2000, Andrew C. Hornback wrote: > > From my experience with Intel networking hardware, those are good > > cards, and there should be a driver available for them. > > The cards aren't too daffy but the driver is a little raw around the > edges. Any specific problems? Was the ex driver at 2.2.6 and 3.3 any worse? The new segment's been put off for a few days anyway, so there's still time to whack in a spare ne2000 clone if it's not such a great idea .. fwiw there's a couple more Pro/10 cards in the 'dozeboxen it's feeding. Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Aug 12 9:39:49 2000 Delivered-To: freebsd-net@freebsd.org Received: from castle.jp.freebsd.org (castle.jp.FreeBSD.org [210.226.20.15]) by hub.freebsd.org (Postfix) with ESMTP id 0B0C937B5E8 for ; Sat, 12 Aug 2000 09:39:46 -0700 (PDT) (envelope-from matusita@jp.freebsd.org) Received: from localhost (localhost [127.0.0.1]) by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) with ESMTP id BAA11010; Sun, 13 Aug 2000 01:39:44 +0900 (JST) (envelope-from matusita@jp.FreeBSD.org) Cc: jinmei@isl.rdc.toshiba.co.jp In-Reply-To: References: X-Face: '*aj"d@ijeQ:/X}]oM5c5Uz{ZZZk90WPt>a^y4$cGQp8:!H\W=hSM;PuNiidkc]/%,;6VGu e+`&APmz|P;F~OL/QK%;P2vU>\j4X.8@i%j6[%DTs_3J,Fff0)*oHg$A.cDm&jc#pD24WK@{,"Ef!0 P\):.2}8jo-BiZ?X&t$V X-User-Agent: Mew/1.94.2 XEmacs/21.2 (Molpe) X-FaceAnim: (-O_O-)(O_O- )(_O- )(O- )(- -)( -O)( -O_)( -O_O)(-O_O-) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Dispatcher: imput version 20000228(IM140) Lines: 10 From: Makoto MATSUSHITA To: net@freebsd.org Subject: Re: a serious bug fix about IPv6 for 4.1 and current Date: Sun, 13 Aug 2000 01:39:40 +0900 Message-Id: <20000813013940K.matusita@jp.FreeBSD.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org jinmei> (I can't do this by myself, since I'm not a committer. Sorry jinmei> about that). Would you please confirm that the difference between revsion 1.4 and 1.6 (1.2.2.1 and 1.2.2.2 for 4-stable) of src/sys/netinet6/nd6_rtr.c will fix the problem? -- - Makoto `MAR' MATSUSHITA To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Aug 12 9:54:51 2000 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 1A28037B68B for ; Sat, 12 Aug 2000 09:54:41 -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 BAA12904; Sun, 13 Aug 2000 01:40:22 +0900 (JST) Date: Sun, 13 Aug 2000 01:49:33 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: matusita@jp.freebsd.org Cc: net@FreeBSD.ORG Subject: Re: a serious bug fix about IPv6 for 4.1 and current In-Reply-To: In your message of "Sun, 13 Aug 2000 01:39:40 +0900" <20000813013940K.matusita@jp.FreeBSD.org> References: <20000813013940K.matusita@jp.FreeBSD.org> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.6 Mule/4.0 (HANANOEN) 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: 19 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >>>>> On Sun, 13 Aug 2000 01:39:40 +0900, >>>>> Makoto MATSUSHITA said: jinmei> (I can't do this by myself, since I'm not a committer. Sorry jinmei> about that). > Would you please confirm that the difference between revsion 1.4 and > 1.6 (1.2.2.1 and 1.2.2.2 for 4-stable) of src/sys/netinet6/nd6_rtr.c > will fix the problem? I'm not sure what you meant by "confirm" here, but as long as I see in the diff at cvsweb, the fix seems fine to solve the problem. Thanks, 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 Sat Aug 12 10:34:20 2000 Delivered-To: freebsd-net@freebsd.org Received: from castle.jp.freebsd.org (castle.jp.FreeBSD.org [210.226.20.15]) by hub.freebsd.org (Postfix) with ESMTP id CB23C37C088 for ; Sat, 12 Aug 2000 10:34:11 -0700 (PDT) (envelope-from matusita@jp.freebsd.org) Received: from localhost (localhost [127.0.0.1]) by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) with ESMTP id CAA12994 for ; Sun, 13 Aug 2000 02:34:07 +0900 (JST) (envelope-from matusita@jp.FreeBSD.org) In-Reply-To: References: <20000813013940K.matusita@jp.FreeBSD.org> X-Face: '*aj"d@ijeQ:/X}]oM5c5Uz{ZZZk90WPt>a^y4$cGQp8:!H\W=hSM;PuNiidkc]/%,;6VGu e+`&APmz|P;F~OL/QK%;P2vU>\j4X.8@i%j6[%DTs_3J,Fff0)*oHg$A.cDm&jc#pD24WK@{,"Ef!0 P\):.2}8jo-BiZ?X&t$V X-User-Agent: Mew/1.94.2 XEmacs/21.2 (Molpe) X-FaceAnim: (-O_O-)(O_O- )(_O- )(O- )(- -)( -O)( -O_)( -O_O)(-O_O-) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Dispatcher: imput version 20000228(IM140) Lines: 14 From: Makoto MATSUSHITA To: net@FreeBSD.ORG Subject: Re: a serious bug fix about IPv6 for 4.1 and current Date: Sun, 13 Aug 2000 02:34:01 +0900 Message-Id: <20000813023401T.matusita@jp.FreeBSD.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Very thankyou for your reply. jinmei> but as long as I see in the diff at cvsweb, the fix seems fine jinmei> to solve the problem. Now we can say "if you are using IPv6 protocol stack on -current or 4-stable, be sure that your src/sys/netinet6/nd6_rtr.c is revision 1.6/1.2.2.2 or later; if not, update the file ASAP." Maybe it's easy to remember than having a patch :-) -- - Makoto `MAR' MATSUSHITA To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message