From owner-freebsd-net Sun Aug 27 10:34: 9 2000 Delivered-To: freebsd-net@freebsd.org Received: from web1607.mail.yahoo.com (web1607.mail.yahoo.com [128.11.23.149]) by hub.freebsd.org (Postfix) with SMTP id 5011A37B43E for ; Sun, 27 Aug 2000 10:34:08 -0700 (PDT) Received: (qmail 15743 invoked by uid 60001); 27 Aug 2000 17:41:29 -0000 Message-ID: <20000827174129.15742.qmail@web1607.mail.yahoo.com> Received: from [128.42.22.80] by web1607.mail.yahoo.com; Sun, 27 Aug 2000 10:41:29 PDT Date: Sun, 27 Aug 2000 10:41:29 -0700 (PDT) From: Ping Yuan Subject: Setting buffer size. 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, I am now using Freebsd 3.2 as a router. I noticed that when the router was busy, more packets would be dropped. What I want to do is to have a larger buffer size, then, less packets will be dropped. It seems freeBSD should have a configuration of its total buffer size. Can you point me to this code? Thanks in advance, -Ping __________________________________________________ Do You Yahoo!? Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Aug 27 11:37:17 2000 Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id B978537B43C for ; Sun, 27 Aug 2000 11:37:10 -0700 (PDT) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e7RIb9N09861; Sun, 27 Aug 2000 11:37:09 -0700 (PDT) Date: Sun, 27 Aug 2000 11:37:09 -0700 From: Alfred Perlstein To: Ping Yuan Cc: freebsd-net@FreeBSD.ORG Subject: Re: Setting buffer size. Message-ID: <20000827113709.C1209@fw.wintelcom.net> References: <20000827174129.15742.qmail@web1607.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <20000827174129.15742.qmail@web1607.mail.yahoo.com>; from yuanpinghh@yahoo.com on Sun, Aug 27, 2000 at 10:41:29AM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Ping Yuan [000827 10:34] wrote: > Hi, > > I am now using Freebsd 3.2 as a router. I noticed that > when the router was busy, more packets would be > dropped. What I want to do is to have a larger buffer > size, then, less packets will be dropped. > > It seems freeBSD should have a configuration of its > total buffer size. Can you point me to this code? > > Thanks in advance, See "man loader" kern.ipc.nmbclusters Set the number of mbuf clusters to be allocated. The value cannot be set below the default determined when the kernel was compiled. Modifies NMBCLUSTERS. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Aug 27 14:38:17 2000 Delivered-To: freebsd-net@freebsd.org Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (Postfix) with ESMTP id 3B54237B422; Sun, 27 Aug 2000 14:38:01 -0700 (PDT) Received: (from smap@localhost) by whistle.com (8.10.0/8.10.0) id e7RLQ3T26925; Sun, 27 Aug 2000 14:26:03 -0700 (PDT) Received: from bubba.whistle.com( 207.76.205.7) by whistle.com via smap (V2.0) id xma026923; Sun, 27 Aug 2000 14:25:56 -0700 Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.3) id OAA66159; Sun, 27 Aug 2000 14:25:55 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200008272125.OAA66159@bubba.whistle.com> Subject: Proposal to clarify mbuf handling rules To: freebsd-net@freebsd.org, freebsd-current@freebsd.org Date: Sun, 27 Aug 2000 14:25:55 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In looking at some of the problems relating to divert, bridging, etc., it's apparent that lots of code is breaking one of the rules for handling mbufs: that mbuf data can sometimes be read-only. Each mbuf may be either a normal mbuf or a cluster mbuf (if the mbuf flags contains M_EXT). Cluster mbufs point to an entire page of memory, and this page of memory may be shared by more than one cluster mbuf (see m_copypacket()). This effectively makes the mbuf data read-only, because a change to one mbuf affects all of the mbufs, not just the one you're working on. There have been (and still are) several FreeBSD bugs because of this subtlety. A test for an mbuf being "read-only" is: if ((m->m_flags & M_EXT) != 0 && MEXT_IS_REF(m)) ... So an implicit rule for handling mbufs is that they should be treated as read-only unless/until you either check that it's not, and/or pullup a new (non-cluster) mbuf that covers the data area that you're going to modify. However, many routines that take an mbuf parameter assume that the mbuf given to them is modifiable and proceed to write all over it. A few examples are: ip_input(), in_arpinput(), tcp_input(), divert_packt(), etc. In practice, this is often not a problem because the mbuf is actually modifiable (because there are no other references to it). But this is just because we've been lucky. When you throw things like bridging, dummynet, divert, and netgraph into the mix, not to mention other site-specific hacks, then these assumptions no longer hold. At the minimum these assumptions should be clearly commented, but that's not even the case right now. Routines that don't change any data, or that only do m_pullup(), M_PREPEND(), m_adj(), etc. don't have a problem. So I'd like to propose a mini-project to clarify and fix this problem. Here is the propsal: 1. All routines that take an mbuf as an argument must not assume that any mbuf in the chain is modifyable, unless expclicitly and clearly documented (in the comment at the top of the function) as doing so. 2. For routines that don't modify data, incorporate liberal use of the "const" keyword to make this clear. For example, change struct ip *ip; ip = mtod(m, struct ip *); to: const struct ip *ip; ip = mtod(m, const struct ip *); 3. For any routines that do need to modify mbuf data, but don't assume anything about the mbuf, alter those routines to do an m_pullup() when necessary to make the data are they are working on modifiable. For example: struct ip *ip; /* Pull up IP header */ if (m->m_len < sizeof(*ip) && !(m = m_pullup(m, sizeof(*ip)))) return; ip = mtod(m, struct ip *); #ifdef NEW_CODE_BEING_ADDED /* Make sure the IP header area is writable */ if ((m->m_flags & M_EXT) != 0 && MEXT_IS_REF(m)) { /* m_pullup() *always* prepends a fresh, non-cluster mbuf */ if ((m = m_pullup(m, sizeof(struct ip))) == 0) return; ip = mtod(m, struct ip *); } #endif /* Modify the header */ ip->ip_len = 123; ... The only negative is the addition of the NEW_CODE_BEING_ADDED code in the relevant places. In practice this test will usually fail, as most mbufs are modifiable, so there should be no noticable slowdown. However, robustness should improve, especially when bridging, diverting, etc. What do people think? If this is generally agreeable I'll try to work on putting together a patch set for review. -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 Sun Aug 27 14:50:14 2000 Delivered-To: freebsd-net@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 4BF1337B423; Sun, 27 Aug 2000 14:50:12 -0700 (PDT) Received: from lanczos.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 27 Aug 2000 22:50:11 +0100 (BST) Date: Sun, 27 Aug 2000 22:50:11 +0100 From: David Malone To: Archie Cobbs Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: Proposal to clarify mbuf handling rules Message-ID: <20000827225011.A10714@lanczos.maths.tcd.ie> References: <200008272125.OAA66159@bubba.whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200008272125.OAA66159@bubba.whistle.com>; from archie@whistle.com on Sun, Aug 27, 2000 at 02:25:55PM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Aug 27, 2000 at 02:25:55PM -0700, Archie Cobbs wrote: > What do people think? If this is generally agreeable I'll try to > work on putting together a patch set for review. Myself and Ian Dowse have been talking about almost this issue recently in relation to sbcompress. At the moment sbcompress is too conservative about compressing mbuf chains, with the result that it is easily possible to run many machines out of mbuf clusters. (We've seen this problem with netscape and kioslave). At the moment sbcompress only compresses into mbufs, where it could also compress into clusters, providing they have a reference count of 1. However, this still means it can't compress into jumbo buffers associated with gigabit ethernet and the like. We were thinking it might be a good idea to have a flag associated with mbufs which means they are writable, providing the reference count is 1. Then we can provide a macro for checking writability. This flag could be set on jumbo ethernet buffers, but not sendfile buffers (for example). David. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Aug 27 15:10:16 2000 Delivered-To: freebsd-net@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 56BBF37B424; Sun, 27 Aug 2000 15:09:59 -0700 (PDT) Received: from lanczos.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 27 Aug 2000 23:09:58 +0100 (BST) Date: Sun, 27 Aug 2000 23:09:58 +0100 From: David Malone To: Archie Cobbs Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: Proposal to clarify mbuf handling rules Message-ID: <20000827230958.B10714@lanczos.maths.tcd.ie> References: <200008272125.OAA66159@bubba.whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200008272125.OAA66159@bubba.whistle.com>; from archie@whistle.com on Sun, Aug 27, 2000 at 02:25:55PM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Aug 27, 2000 at 02:25:55PM -0700, Archie Cobbs wrote: > Each mbuf may be either a normal mbuf or a cluster mbuf (if the > mbuf flags contains M_EXT). Cluster mbufs point to an entire page > of memory, and this page of memory may be shared by more than one > cluster mbuf (see m_copypacket()). Clusters are currently 2048 bytes in size - which I don't think it a page on the alpha or the i386. (Not that this is really important). > his effectively makes the mbuf > data read-only, because a change to one mbuf affects all of the > mbufs, not just the one you're working on. There have been (and > still are) several FreeBSD bugs because of this subtlety. > > A test for an mbuf being "read-only" is: > > if ((m->m_flags & M_EXT) != 0 && MEXT_IS_REF(m)) ... You should also check that it's really a cluster you're looking at: if ((m->m_flags & M_EXT) != 0 && (MEXT_IS_REF(m) || (m)->m_ext.ext_free != NULL)) { /* data is read only */ } (This is why the flag I was talking about in the other mail would be useful for spotting other cases where the storage may be writable, even if it's not a cluster). Cleaning up this sounds like a good plan. It would be worth getting Ian and Bosko involved if possible. David. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Aug 27 17: 3:59 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 088B137B42C for ; Sun, 27 Aug 2000 17:03:58 -0700 (PDT) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id UAA21054; Sun, 27 Aug 2000 20:03:55 -0400 (EDT) (envelope-from wollman) Date: Sun, 27 Aug 2000 20:03:55 -0400 (EDT) From: Garrett Wollman Message-Id: <200008280003.UAA21054@khavrinen.lcs.mit.edu> To: Ping Yuan Cc: freebsd-net@FreeBSD.ORG Subject: Setting buffer size. In-Reply-To: <20000827174129.15742.qmail@web1607.mail.yahoo.com> References: <20000827174129.15742.qmail@web1607.mail.yahoo.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > I am now using Freebsd 3.2 as a router. I noticed that > when the router was busy, more packets would be > dropped. This is a fundamental limitation of BSD's network stack and two-level interrupt scheme. More memory will not help; when packets are being dropped, the kernel is already receiving more packets per unit time than it is capable of forwarding. See, for exampl, Jeff Mogul's ``Receive Livelock'' paper. -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 Sun Aug 27 17:17:54 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 3F23B37B424; Sun, 27 Aug 2000 17:17:50 -0700 (PDT) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id UAA21141; Sun, 27 Aug 2000 20:17:48 -0400 (EDT) (envelope-from wollman) Date: Sun, 27 Aug 2000 20:17:48 -0400 (EDT) From: Garrett Wollman Message-Id: <200008280017.UAA21141@khavrinen.lcs.mit.edu> To: Archie Cobbs Cc: freebsd-net@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Proposal to clarify mbuf handling rules In-Reply-To: <200008272125.OAA66159@bubba.whistle.com> References: <200008272125.OAA66159@bubba.whistle.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > However, many routines that take an mbuf parameter assume that the > mbuf given to them is modifiable and proceed to write all over it. s/assume/require as a necessary precondition/ It's not a coding error, it's part of the specification. No, it's not documented -- but it's pretty clear from the design of the original code. > 3. For any routines that do need to modify mbuf data, but don't > assume anything about the mbuf, alter those routines to do > an m_pullup() when necessary to make the data are they are > working on modifiable. m_pullup is evil. It would be better to fix the places (i.e., ip_input and ip_output) which make the modification necessary. -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 Sun Aug 27 19:43:25 2000 Delivered-To: freebsd-net@freebsd.org Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (Postfix) with ESMTP id 6A05C37B422; Sun, 27 Aug 2000 19:43:22 -0700 (PDT) Received: (from smap@localhost) by whistle.com (8.10.0/8.10.0) id e7S2hC928224; Sun, 27 Aug 2000 19:43:12 -0700 (PDT) Received: from bubba.whistle.com( 207.76.205.7) by whistle.com via smap (V2.0) id xma028222; Sun, 27 Aug 2000 19:42:49 -0700 Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.3) id TAA66974; Sun, 27 Aug 2000 19:42:48 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200008280242.TAA66974@bubba.whistle.com> Subject: Re: Proposal to clarify mbuf handling rules In-Reply-To: <20000827225011.A10714@lanczos.maths.tcd.ie> "from David Malone at Aug 27, 2000 10:50:11 pm" To: David Malone Date: Sun, 27 Aug 2000 19:42:48 -0700 (PDT) Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org David Malone writes: > We were thinking it might be a good idea to have a flag associated > with mbufs which means they are writable, providing the reference > count is 1. Then we can provide a macro for checking writability. > This flag could be set on jumbo ethernet buffers, but not sendfile > buffers (for example). That's a good idea.. I forgot about things like sendfile, where the mbuf is read-only due to other reasons. So we need some kind of flag it seems. That's good -- it makes it even more obvious. -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 Sun Aug 27 20:54:25 2000 Delivered-To: freebsd-net@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id D16E037B422; Sun, 27 Aug 2000 20:54:17 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 13TG6e-0000Nv-00; Sun, 27 Aug 2000 22:01:09 -0600 Message-ID: <39A9E404.F47030C7@softweyr.com> Date: Sun, 27 Aug 2000 22:01:08 -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: Jim Flowers Cc: Theo PAGTZIS , Eric Kozowski , freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: fbsd box acting as a wavelan BS References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Jim Flowers wrote: > > Last I checked the wi driver will not do IBSS and says so in the > documentation. I also tried it and couldn't get anywhere. Would be nice. You must've last checked a long time ago: DESCRIPTION The wicontrol command controls the operation of WaveLAN/IEEE wireless networking devices via the wi(4) driver. Most of the parameters that can be changed relate to the IEEE 802.11 protocol which the WaveLAN imple- ments. This includes the station name, whether the station is operating in ad-hoc (point to point) or BSS (service set) mode, and the network name of a service set to join (IBSS) if BSS mode is enabled. The wicon- trol command can also be used to view the current settings of these pa- rameters and to dump out the values of the card's statistics counters. -- "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 Sun Aug 27 20:56:47 2000 Delivered-To: freebsd-net@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 0EA3737B43F; Sun, 27 Aug 2000 20:56:34 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 13TG97-0000O4-00; Sun, 27 Aug 2000 22:03:41 -0600 Message-ID: <39A9E49D.A79BF6FD@softweyr.com> Date: Sun, 27 Aug 2000 22:03:41 -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: Jim Flowers Cc: Theo PAGTZIS , Eric Kozowski , freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: fbsd box acting as a wavelan BS References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Jim Flowers wrote: > > Last I checked the wi driver will not do IBSS and says so in the > documentation. I also tried it and couldn't get anywhere. Would be nice. Uh, er, if you mean to create a service set, Lucent apparently hasn't seen fit to release that sort of information about the cards yet. I can probably get access to it, but it would be under NDA and therefore not useful. Your best bet is to bug your friendly neighborhood Lucent rep into releaseing the full documentation (and sample source code) to Bill Paul. -- "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 Mon Aug 28 0: 3:34 2000 Delivered-To: freebsd-net@freebsd.org Received: from onoe2.sm.sony.co.jp (onoe2.sm.sony.co.jp [133.138.10.2]) by hub.freebsd.org (Postfix) with ESMTP id 3A96637B43C; Mon, 28 Aug 2000 00:03:30 -0700 (PDT) Received: from duplo.sm.sony.co.jp (onoe@localhost) by onoe2.sm.sony.co.jp (8.9.0/3.7W) with ESMTP id QAA13801; Mon, 28 Aug 2000 16:02:59 +0900 (JST) Received: (from onoe@localhost) by duplo.sm.sony.co.jp (8.11.0/8.10.2) id e7S732S01248; Mon, 28 Aug 2000 16:03:02 +0900 (JST) Date: Mon, 28 Aug 2000 16:03:02 +0900 (JST) From: Atsushi Onoe Message-Id: <200008280703.e7S732S01248@duplo.sm.sony.co.jp> To: wes@softweyr.com Cc: jflowers@peony.ezo.net, T.Pagtzis@cs.ucl.ac.uk, eric@svjava.com, freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: fbsd box acting as a wavelan BS In-Reply-To: Your message of "Sun, 27 Aug 2000 22:03:41 -0600" <39A9E49D.A79BF6FD@softweyr.com> References: <39A9E49D.A79BF6FD@softweyr.com> X-Mailer: Cue version 0.6 (000608-1919/onoe) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > Last I checked the wi driver will not do IBSS and says so in the > > documentation. I also tried it and couldn't get anywhere. Would be nice. > > Uh, er, if you mean to create a service set, Lucent apparently hasn't seen > fit to release that sort of information about the cards yet. I can probably > get access to it, but it would be under NDA and therefore not useful. Your > best bet is to bug your friendly neighborhood Lucent rep into releaseing > the full documentation (and sample source code) to Bill Paul. Lucent have shipped newer firmware this March which DOES support creating IBSS. The verision 6.04 of the firmware creates IBSS by setting wicontrol -c 1 with -p 1 (BSS mode), and joins to IBSS if no access points found. It seems that the name of created IBSS follows "network name" specified by -n option, not "SSID" by -q option. Regards, Atsushi Onoe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 28 2:52:18 2000 Delivered-To: freebsd-net@freebsd.org Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by hub.freebsd.org (Postfix) with SMTP id 086C137B423; Mon, 28 Aug 2000 02:52:07 -0700 (PDT) Received: from ginger.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 28 Aug 2000 10:50:40 +0100 Message-ID: <39AA35ED.BC9E6428@cs.ucl.ac.uk> Date: Mon, 28 Aug 2000 10:50:37 +0100 From: Theo PAGTZIS Reply-To: t.pagtzis@cs.ucl.ac.uk Organization: UCL X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: el, en MIME-Version: 1.0 To: Wes Peters Cc: Jim Flowers , Theo PAGTZIS , Eric Kozowski , freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: fbsd box acting as a wavelan BS References: <39A9E404.F47030C7@softweyr.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Wes Peters wrote: > Jim Flowers wrote: > > > > Last I checked the wi driver will not do IBSS and says so in the > > documentation. I also tried it and couldn't get anywhere. Would be nice. > > You must've last checked a long time ago: > > DESCRIPTION > The wicontrol command controls the operation of WaveLAN/IEEE wireless > networking devices via the wi(4) driver. Most of the parameters that can > be changed relate to the IEEE 802.11 protocol which the WaveLAN imple- > ments. This includes the station name, whether the station is operating > in ad-hoc (point to point) or BSS (service set) mode, and the network > name of a service set to join (IBSS) if BSS mode is enabled. The wicon- > trol command can also be used to view the current settings of these pa- > rameters and to dump out the values of the card's statistics counters. > > -- > "Where am I, and what am I doing in this handbasket?" > > Wes Peters Softweyr LLC > wes@softweyr.com http://softweyr.com/ Wes, quite correct. I considered revisiting the matter non-important since anyone that would use fbsd 3.4 or later should have such features by default...(otherwise wavelan support would be pretty stranded :).. Now, I have my reservations about the card's statistics counters.....I have yet to see working statistics on the wavelan interface...That has *not* been working since 3.4 for me...anyone that can tell me I am wrong...please do as I want to use these stats pretty badly... Theo To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 28 5: 6:46 2000 Delivered-To: freebsd-net@freebsd.org Received: from peony.ezo.net (peony.ezo.net [206.102.130.11]) by hub.freebsd.org (Postfix) with ESMTP id 34E1637B42C; Mon, 28 Aug 2000 05:06:37 -0700 (PDT) Received: from localhost (jflowers@localhost) by peony.ezo.net (8.11.0.Beta3/8.11.0.Beta3) with ESMTP id e7SCYsY10486; Mon, 28 Aug 2000 08:34:54 -0400 (EDT) Date: Mon, 28 Aug 2000 08:34:54 -0400 (EDT) From: Jim Flowers To: Wes Peters Cc: Theo PAGTZIS , Eric Kozowski , freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: fbsd box acting as a wavelan BS In-Reply-To: <39A9E404.F47030C7@softweyr.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 My point was only that the fbsd wi driver does not appear to allow the creation of a service set as the original poster wanted to do, therefore to use IBSS mode you have to have a WavePointII. From the current wicontrol man page: snip--------------------- Allow the station to create a service set (IBSS). Permitted values are 0 (don't create IBSS) and 1 (enable creation of IBSS). The default is 0. Note: this option is provided for experimental purposes only: enabling the creation of an IBSS on a host system doesn't appear to actually work. --------------- Jim Flowers #4 ranked ISP on C|NET #1 in Ohio On Sun, 27 Aug 2000, Wes Peters wrote: > Jim Flowers wrote: > > > > Last I checked the wi driver will not do IBSS and says so in the > > documentation. I also tried it and couldn't get anywhere. Would be nice. > > You must've last checked a long time ago: > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 28 5:24: 5 2000 Delivered-To: freebsd-net@freebsd.org Received: from peony.ezo.net (peony.ezo.net [206.102.130.11]) by hub.freebsd.org (Postfix) with ESMTP id 8E5B137B42C; Mon, 28 Aug 2000 05:23:57 -0700 (PDT) Received: from localhost (jflowers@localhost) by peony.ezo.net (8.11.0.Beta3/8.11.0.Beta3) with ESMTP id e7SCqFb10567; Mon, 28 Aug 2000 08:52:15 -0400 (EDT) Date: Mon, 28 Aug 2000 08:52:15 -0400 (EDT) From: Jim Flowers To: Theo PAGTZIS Cc: Wes Peters , Eric Kozowski , freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: fbsd box acting as a wavelan BS In-Reply-To: <39AA35ED.BC9E6428@cs.ucl.ac.uk> 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 Seems to work ok on 4.0-RELEASE #0. Jim Flowers #4 ranked ISP on C|NET #1 in Ohio On Mon, 28 Aug 2000, Theo PAGTZIS wrote: > > Wes, > > quite correct. I considered revisiting the matter non-important since anyone > that would > use fbsd 3.4 or later should have such features by default...(otherwise wavelan > support would > be pretty stranded :).. > > Now, I have my reservations about the card's statistics counters.....I have yet to > see working statistics > on the wavelan interface...That has *not* been working since 3.4 for me...anyone > that can tell me I am > wrong...please do as I want to use these stats pretty badly... > > Theo > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 28 5:52:58 2000 Delivered-To: freebsd-net@freebsd.org Received: from server.osny.com.br (osny.com.br [200.215.110.57]) by hub.freebsd.org (Postfix) with ESMTP id AE44037B42C for ; Mon, 28 Aug 2000 05:52:50 -0700 (PDT) Received: from osny.com.br ([172.20.185.22]) by server.osny.com.br (8.10.1/8.10.1) with ESMTP id e7SCsAB07036 for ; Mon, 28 Aug 2000 09:54:13 -0300 (EST) Message-ID: <39AA37C6.543F5660@osny.com.br> Date: Mon, 28 Aug 2000 09:58:30 +0000 From: Michelangelo Pisa Organization: Agencia Maritima Osny X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: free inglish Subject: Re: Fetchmail References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Thanks, but do you know if exists a good tutorial then.. it's a program in the ports? or give one example of the sintaxe? thanks mica Bernie Doehner wrote: > Use popclient :) > > Unfortunately, it's been removed from recent ports and replaced with > fetchmail. popclient was a nice, VERY compact program, that only does POP3 > and very well and will do what you want very easily. > > fetchmail does that and much else, from what I am seen, but it's not as > easy to control. > > Bernie > > On Fri, 25 Aug 2000, Michelangelo Pisa wrote: > > > Hi!!! > > Someone know how I get messages from a POP3 server using > > Fetchmail , where I > > don't need to do a password it's include on the sintaxe of the > > command? which is the sintaxe? > > Best Regards > > > > -- > > Agencia Marítima Osny LTDA > > Mica's > > Michelangelo Pisa > > Administrador de Sistemas e Flamenguista > > E-mail: michelangelo@osny.com.br > > Fone: (0xx47) 348 2800 > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > -- Agencia Marítima Osny LTDA Mica's Michelangelo Pisa Administrador de Sistemas e Flamenguista E-mail: michelangelo@osny.com.br Fone: (0xx47) 348 2800 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 28 8:51:32 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail.telemere.net (mail.telemere.net [63.224.9.4]) by hub.freebsd.org (Postfix) with ESMTP id 6A04837B423 for ; Mon, 28 Aug 2000 08:51:26 -0700 (PDT) Received: by mail.telemere.net (Postfix, from userid 1001) id 26CB220F01; Mon, 28 Aug 2000 10:54:22 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by mail.telemere.net (Postfix) with ESMTP id 226051D101 for ; Mon, 28 Aug 2000 10:54:22 -0500 (CDT) Date: Mon, 28 Aug 2000 10:54:14 -0500 (CDT) From: Visigoth To: freebsd-net@freebsd.org Subject: LOCAL_CREDS for PF_UNIX sockets... 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greets all... I have been lookin around for the FreeBSD "version" of the whole LOCAL_CREDS socket option with struct fcred as ancillary data and all, and have been so far unsuccessful. If someone could point me in the directions of some docs related to sending credentials on a PF_LOCAL socket I would appreciate it very much. Is there a reason for the lack of this socket option and structure? Depreciated? Please CC me as well, as I am not on -net mailing list... Visigoth Damieon Stark Sr. Unix Systems Administrator visigoth@telemere.net PGP Public Key: www.telemere.net/~visigoth/visigoth.asc ____________________________________________________________________________ | M$ -Where do you want to go today? | Linux -Where do you want to go tomorrow?| FreeBSD - The POWER to serve Freebsd -Are you guys coming or what? | http://www.freebsd.org | | - ---------------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.1i iQA/AwUBOap9HDnmC/+RTnGeEQISewCaAoizVkA0pDhVEHzruxm9jDXbE10AoMsF kkQC6QyZeEoVwlGXf5uIds/B =UUIi -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 28 9:10: 7 2000 Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 1825F37B42C for ; Mon, 28 Aug 2000 09:10:04 -0700 (PDT) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e7SGA2B09529; Mon, 28 Aug 2000 09:10:02 -0700 (PDT) Date: Mon, 28 Aug 2000 09:10:01 -0700 From: Alfred Perlstein To: Visigoth Cc: freebsd-net@FreeBSD.ORG Subject: Re: LOCAL_CREDS for PF_UNIX sockets... Message-ID: <20000828091001.J1209@fw.wintelcom.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: ; from visigoth@telemere.net on Mon, Aug 28, 2000 at 10:54:14AM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Visigoth [000828 08:51] wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Greets all... > > I have been lookin around for the FreeBSD "version" of the whole > LOCAL_CREDS socket option with struct fcred as ancillary data and all, and > have been so far unsuccessful. If someone could point me in the > directions of some docs related to sending credentials on a PF_LOCAL > socket I would appreciate it very much. Is there a reason for the lack of > this socket option and structure? Depreciated? > > Please CC me as well, as I am not on -net mailing list... I think you mean to be using SCM_CREDS see sys/socket.h -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 28 10:59:22 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail.telemere.net (mail.telemere.net [63.224.9.4]) by hub.freebsd.org (Postfix) with ESMTP id E701337B440 for ; Mon, 28 Aug 2000 10:59:20 -0700 (PDT) Received: by mail.telemere.net (Postfix, from userid 1001) id AB2C820F01; Mon, 28 Aug 2000 13:02:19 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by mail.telemere.net (Postfix) with ESMTP id A91691D101; Mon, 28 Aug 2000 13:02:19 -0500 (CDT) Date: Mon, 28 Aug 2000 13:02:07 -0500 (CDT) From: Visigoth To: Alfred Perlstein Cc: freebsd-net@FreeBSD.ORG Subject: Re: LOCAL_CREDS for PF_UNIX sockets... In-Reply-To: <20000828091001.J1209@fw.wintelcom.net> 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > I think you mean to be using SCM_CREDS see sys/socket.h Perfect thanks ;) Damieon Stark Sr. Unix Systems Administrator visigoth@telemere.net PGP Public Key: www.telemere.net/~visigoth/visigoth.asc ____________________________________________________________________________ | M$ -Where do you want to go today? | Linux -Where do you want to go tomorrow?| FreeBSD - The POWER to serve Freebsd -Are you guys coming or what? | http://www.freebsd.org | | - ---------------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.1i iQA/AwUBOaqbEznmC/+RTnGeEQIs3wCeIOU8ZlEghzEwa394bE5Gs+EYKDwAn2Lo 4RBzTu6eXC0oHd2Wt4xzNyEl =/YEz -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 28 11:22:57 2000 Delivered-To: freebsd-net@freebsd.org Received: from field.videotron.net (field.videotron.net [205.151.222.108]) by hub.freebsd.org (Postfix) with ESMTP id B740937B43C; Mon, 28 Aug 2000 11:22:40 -0700 (PDT) Received: from modemcable136.203-201-24.mtl.mc.videotron.net ([24.201.203.136]) by field.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0G0000083KSVTM@field.videotron.net>; Mon, 28 Aug 2000 14:02:55 -0400 (EDT) Date: Mon, 28 Aug 2000 14:06:08 -0400 (EDT) From: Bosko Milekic Subject: Re: Proposal to clarify mbuf handling rules In-reply-to: <20000827230958.B10714@lanczos.maths.tcd.ie> X-Sender: bmilekic@jehovah.technokratis.com To: David Malone Cc: Archie Cobbs , freebsd-net@FreeBSD.ORG, freebsd-current@FreeBSD.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 Sun, 27 Aug 2000, David Malone wrote: [...] > (This is why the flag I was talking about in the other mail > would be useful for spotting other cases where the storage > may be writable, even if it's not a cluster). Thoughts: 1) The mbuf should be marked read-only explicitly with a single additional M_FLAG. #define M_RDONLY 0x0x2000 2) The flag should be ORed in in MEXT_ADD_REF() only if the ref_cnt is equal to or greater than 2. This is unfortunate because an additional check would have to be introduced. 3) The flag should be removed in _MEXTFREE only if that first MEXT_IS_REF() evaluates true and if, upon returning from MEXT_REM_REF(), the new ref_cnt is exactly 1. I'm pretty sure that this way, the subsystem will take care of the read-onlyness itself pretty transparently, so that relevant code can simply check for the M_RDONLY bit. (2) is questionable. As for the protocol routines that rely on the mbuf to be "read-only," there may be other side-effects besides for this illegal sharing of multiple-reference ext_bufs that could result from the possibility of passing these "read-only mbufs" to them. This possibility should be investigated. > Cleaning up this sounds like a good plan. It would be worth > getting Ian and Bosko involved if possible. > > David. Sure. If I remember correctly, it was Ian who initially brought this up. This is perhaps a 2-month old issue by now -- I, at the time, was busy with the referencing stuff as well as the allocator re-writing/playing around with (which I will have to continue once the direction of SMP is further cleared up - at least for this part of the code) - so I did not want to mix apples and oranges. I wonder if Ian has some code, though. I have _some_ modifications regarding this already in my local tree but have not yet been able to roll over a diff as my monitor is presently broken (until the end of this week). In any case, how do you propose coordinating the work? This seems like a fairly straightforward change. I'm ready to put on hold whatever I'm doing right now in order to do this, but only if that's okay with you guys - I want to make sure that no efforts are being duplicated. Regards, Bosko. bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 28 12: 5:19 2000 Delivered-To: freebsd-net@freebsd.org Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (Postfix) with ESMTP id E3B8837B422; Mon, 28 Aug 2000 12:05:09 -0700 (PDT) Received: (from smap@localhost) by whistle.com (8.10.0/8.10.0) id e7SJ4N906391; Mon, 28 Aug 2000 12:04:23 -0700 (PDT) Received: from bubba.whistle.com( 207.76.205.7) by whistle.com via smap (V2.0) id xma006386; Mon, 28 Aug 2000 12:04:12 -0700 Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.3) id MAA70786; Mon, 28 Aug 2000 12:04:06 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200008281904.MAA70786@bubba.whistle.com> Subject: Re: Proposal to clarify mbuf handling rules In-Reply-To: "from Bosko Milekic at Aug 28, 2000 02:06:08 pm" To: Bosko Milekic Date: Mon, 28 Aug 2000 12:04:06 -0700 (PDT) Cc: dwmalone@maths.tcd.ie, freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [ note: trimming -current from the CC: list ] Bosko Milekic writes: > 1) The mbuf should be marked read-only explicitly with a single > additional M_FLAG. > > #define M_RDONLY 0x0x2000 > > 2) The flag should be ORed in in MEXT_ADD_REF() only if the ref_cnt is > equal to or greater than 2. This is unfortunate because an additional > check would have to be introduced. > > 3) The flag should be removed in _MEXTFREE only if that first > MEXT_IS_REF() evaluates true and if, upon returning from MEXT_REM_REF(), > the new ref_cnt is exactly 1. > > I'm pretty sure that this way, the subsystem will take care of the > read-onlyness itself pretty transparently, so that relevant code can > simply check for the M_RDONLY bit. (2) is questionable. Sounds good. By the way, MEXT_REM_REF() should be defined differently if INVARIANTS is defined so it KASSERT's the reference count is > 0. > As for the protocol routines that rely on the mbuf to be "read-only," > there may be other side-effects besides for this illegal sharing of > multiple-reference ext_bufs that could result from the possibility of > passing these "read-only mbufs" to them. This possibility should be > investigated. Not sure what you mean here.. got an example? > > Cleaning up this sounds like a good plan. It would be worth > > getting Ian and Bosko involved if possible. > > Sure. If I remember correctly, it was Ian who initially brought this > up. This is perhaps a 2-month old issue by now -- I, at the time, was > busy with the referencing stuff as well as the allocator > re-writing/playing around with (which I will have to continue once the > direction of SMP is further cleared up - at least for this part of the > code) - so I did not want to mix apples and oranges. I wonder if Ian has > some code, though. > > I have _some_ modifications regarding this already in my local tree but > have not yet been able to roll over a diff as my monitor is presently > broken (until the end of this week). In any case, how do you propose > coordinating the work? This seems like a fairly straightforward change. > I'm ready to put on hold whatever I'm doing right now in order > to do this, but only if that's okay with you guys - I want to make sure > that no efforts are being duplicated. Let's keep the discussion on freebsd-net. Here's a proposed sequence of steps, at least to get started.. 1. Implement your 1, 2, 3 above: add the flag and adjust the macros 2. Sprinkle code with const's and KASSERT()'s 3. Wait and see what blows up 4. Continue with my proposed changes -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 28 12:50:50 2000 Delivered-To: freebsd-net@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id D671E37B667 for ; Mon, 28 Aug 2000 12:46:23 -0700 (PDT) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 28 Aug 2000 20:46:22 +0100 (BST) To: Bosko Milekic Cc: David Malone , Archie Cobbs , freebsd-net@FreeBSD.ORG Subject: Re: Proposal to clarify mbuf handling rules In-Reply-To: Your message of "Mon, 28 Aug 2000 14:06:08 EDT." Date: Mon, 28 Aug 2000 20:46:20 +0100 From: Ian Dowse Message-ID: <200008282046.aa01881@salmon.maths.tcd.ie> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message , Bosko Milekic writes: > #define M_RDONLY 0x0x2000 > >2) The flag should be ORed in in MEXT_ADD_REF() only if the ref_cnt is > equal to or greater than 2. This is unfortunate because an additional > check would have to be introduced. > >3) The flag should be removed in _MEXTFREE only if that first > MEXT_IS_REF() evaluates true and if, upon returning from MEXT_REM_REF(), > the new ref_cnt is exactly 1. > > I'm pretty sure that this way, the subsystem will take care of the > read-onlyness itself pretty transparently, so that relevant code can > simply check for the M_RDONLY bit. (2) is questionable. This is good, but the M_RDONLY flag should only be used as an indication that the underlying ext_buf must never be written to. Hence the mbuf system should never modify this flag (except of course to clear it when the mbuf is returned to the free pool). Point (3) above would clear the M_RDONLY flag on a sendfile sf_buf when the reference count becomes 1; this is not the desired effect. Another way of looking at the M_RDONLY flag is as an indication that the underlying ext_buf does _not_ follow cluster semantics; cluster semantics being defined as 'it is safe to write if the reference count is exactly 1'. However, the idea of caching the value of the expression: if (m->m_flags & M_EXT) != 0 && (MEXT_IS_REF(m) || (m->m_flags & M_RDONLY))) { /* data is read only */ } in a flag is nice, but if implemented, that would have to be a separate flag to the above M_RDONLY. 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 28 13:42:15 2000 Delivered-To: freebsd-net@freebsd.org Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (Postfix) with ESMTP id 5FC6637B422 for ; Mon, 28 Aug 2000 13:42:11 -0700 (PDT) Received: (from smap@localhost) by whistle.com (8.10.0/8.10.0) id e7SKfT407522; Mon, 28 Aug 2000 13:41:29 -0700 (PDT) Received: from bubba.whistle.com( 207.76.205.7) by whistle.com via smap (V2.0) id xma007516; Mon, 28 Aug 2000 13:41:21 -0700 Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.3) id NAA71818; Mon, 28 Aug 2000 13:41:16 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200008282041.NAA71818@bubba.whistle.com> Subject: Re: Proposal to clarify mbuf handling rules In-Reply-To: <200008282046.aa01881@salmon.maths.tcd.ie> "from Ian Dowse at Aug 28, 2000 08:46:20 pm" To: Ian Dowse Date: Mon, 28 Aug 2000 13:41:16 -0700 (PDT) Cc: bmilekic@dsuper.net, dwmalone@maths.tcd.ie, freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ian Dowse writes: > >3) The flag should be removed in _MEXTFREE only if that first > > MEXT_IS_REF() evaluates true and if, upon returning from MEXT_REM_REF(), > > the new ref_cnt is exactly 1. > > > > I'm pretty sure that this way, the subsystem will take care of the > > read-onlyness itself pretty transparently, so that relevant code can > > simply check for the M_RDONLY bit. (2) is questionable. > > This is good, but the M_RDONLY flag should only be used as an > indication that the underlying ext_buf must never be written to. > Hence the mbuf system should never modify this flag (except of > course to clear it when the mbuf is returned to the free pool). > > Point (3) above would clear the M_RDONLY flag on a sendfile sf_buf > when the reference count becomes 1; this is not the desired effect. > > Another way of looking at the M_RDONLY flag is as an indication > that the underlying ext_buf does _not_ follow cluster semantics; > cluster semantics being defined as 'it is safe to write if the > reference count is exactly 1'. > > However, the idea of caching the value of the expression: > > if (m->m_flags & M_EXT) != 0 && > (MEXT_IS_REF(m) || (m->m_flags & M_RDONLY))) { > /* data is read only */ > } > > in a flag is nice, but if implemented, that would have to be a > separate flag to the above M_RDONLY. So there are really three possibilities: (a) The mbuf data should not be written to under any circumstances. even if it is a cluster mbuf and the reference count becomes 1. (b) The mbuf data may be written to. This implies that if this mbuf is a cluster, then the reference count is 1. (c) The mbuf data may not be written to, BUT if it is a cluster mbuf and the reference count decreases to 1, then it may then be written to. Maybe we should have two flags M_RDONLY and M_WRITABLE, with these four possibilities: (m->m_flags & (M_RDONLY|M_WRITABLE)) == M_RDONLY -> case (a) above (m->m_flags & (M_RDONLY|M_WRITABLE)) == M_WRITABLE -> case (b) above (m->m_flags & (M_RDONLY|M_WRITABLE)) == 0 -> case (c) above (m->m_flags & (M_RDONLY|M_WRITABLE)) == (M_RDONLY|M_WRITABLE) -> Invalid comibination, kernel panic! Invariants: - If the mbuf is not a cluster mbuf then case (b) MUST hold - If case (a) then the mbuf MUST be a cluster mbuf - If case (c) then the mbuf MUST be a cluster mbuf - Never both M_RDONLY and M_WRITABLE set at the same time -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 28 13:59: 0 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail.numachi.com (numachi.numachi.com [198.175.254.2]) by hub.freebsd.org (Postfix) with SMTP id 9116737B43C for ; Mon, 28 Aug 2000 13:58:54 -0700 (PDT) Received: (qmail 9851 invoked by uid 1001); 28 Aug 2000 20:58:47 -0000 Date: Mon, 28 Aug 2000 16:58:47 -0400 From: Brian Reichert To: freebsd-net@freebsd.org Subject: Macronix NIC not up to snuff? Message-ID: <20000828165847.A9262@numachi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre4i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I intend to open a bug report on this, but first wanted to pester people for advice, in case I'm being silly. On our LAN, we have several boxes, including several versions of FreeBSD. I'm upgrading our internal switch to some Cisco hardware. Upon migrating our cables over however, we have two FreeBSD boxes, running 4.x, with varieties of the Macronix 98715 chipset. ------------------ machine 'one': FreeBSD 4.1-RELEASE #0: Fri Jul 28 14:30:31 GMT 2000 jkh@ref4.freebsd.org:/usr/src/sys/compile/GENERIC dc0: port 0xe800-0xe8ff mem 0xffafff00-0xffafffff irq 9 at device 18.0 on pci0 dc0: Ethernet address: 00:20:78:e1:4a:e1 miibus0: on dc0 dcphy0: on miibus0 dcphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc0: flags=8843 mtu 1500 inet 198.175.254.6 netmask 0xffffff00 broadcast 198.175.254.255 inet6 fe80::220:78ff:fee1:4ae1%dc0 prefixlen 64 scopeid 0x1 inet 198.175.254.4 netmask 0xffffffff broadcast 198.175.254.4 ether 00:20:78:e1:4a:e1 media: autoselect (10baseT/UTP) status: active supported media: autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP 100baseTX none ------------------ machine 'two': FreeBSD 4.0-RELEASE #0: Mon Mar 20 22:50:22 GMT 2000 root@monster.cdrom.com:/usr/src/sys/compile/GENERIC dc0: port 0x3000-0x30ff mem 0xf4111000-0xf41110ff irq 10 at device 14.0 on pci1 dc0: Ethernet address: 00:20:78:e0:6d:48 miibus0: on dc0 dcphy0: on miibus0 dcphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc0: supplying EUI64: 00:20:78:ff:fe:e0:6d:48 dc0: flags=8843 mtu 1500 inet 198.175.254.16 netmask 0xffffff00 broadcast 198.175.254.255 inet6 fe80::220:78ff:fee0:6d48%dc0 prefixlen 64 scopeid 0x1 ether 00:20:78:e0:6d:48 media: autoselect (10baseT/UTP) status: active supported media: autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP 100baseTX none ------------------ Both of these boxes work fine with our FlowPoint DSL router, a cheesy 3Com 10bT hub, and an even cheesier Ark Technologies autosensing switch. I'm installing a Cisco Catalyst 2924 XL running IOS Version 11.2(8)SA3. The symptoms: machine 'one': Upon reboot, both the switch and the NIC would report a link, but as soon as the OS initialized the card, both the switch and NIC would stop reporting a link. 'ifconfig' would reveal 'autosense: no carrier' (typed from memory, so perhaps not an exact quote). machine 'two': Both the NIC and the switch would report a link, but no traffic (pinging, etc.) would come though. (I did not attempt a tcpdump.) I only see one Macronix-related error reported (kern/17728), but the PR doesn't have any real info. Has anyone else seen problems like this with these NICs? -- Brian 'you Bastard' Reichert reichert@numachi.com 37 Crystal Ave. #303 Daytime number: (603) 434-6842 Derry NH 03038-1713 USA Intel architecture: the left-hand path To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 28 14: 8:42 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 4621637B43C for ; Mon, 28 Aug 2000 14:08:39 -0700 (PDT) Received: by jade.chc-chimes.com (Postfix, from userid 1001) id F14281C70; Mon, 28 Aug 2000 17:08:38 -0400 (EDT) Date: Mon, 28 Aug 2000 17:08:38 -0400 From: Bill Fumerola To: Brian Reichert Cc: freebsd-net@freebsd.org Subject: Re: Macronix NIC not up to snuff? Message-ID: <20000828170838.J33771@jade.chc-chimes.com> References: <20000828165847.A9262@numachi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20000828165847.A9262@numachi.com>; from reichert@numachi.com on Mon, Aug 28, 2000 at 04:58:47PM -0400 X-Operating-System: FreeBSD 3.3-STABLE i386 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Aug 28, 2000 at 04:58:47PM -0400, Brian Reichert wrote: > > Both of these boxes work fine with our FlowPoint DSL router, a > cheesy 3Com 10bT hub, and an even cheesier Ark Technologies > autosensing switch. > > I'm installing a Cisco Catalyst 2924 XL running IOS Version > 11.2(8)SA3. Crisco ethernet switches are notorious for screwing up autodetect. Force them with media or mediaopt, and force the duplex and speed on the cisco and see if that helps. -- 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 Mon Aug 28 14:29:51 2000 Delivered-To: freebsd-net@freebsd.org Received: from katroo.Sendmail.COM (katroo.Sendmail.COM [209.246.26.35]) by hub.freebsd.org (Postfix) with ESMTP id 290AC37B423 for ; Mon, 28 Aug 2000 14:29:44 -0700 (PDT) Received: from sam.sendmail.com (root@sam.Sendmail.COM [10.210.109.78]) by katroo.Sendmail.COM (8.9.3/8.9.3) with ESMTP id OAA21305 for ; Mon, 28 Aug 2000 14:29:43 -0700 (PDT) Received: (from emechler@localhost) by sam.sendmail.com (8.9.3/8.9.3/Debian 8.9.3-21) id OAA14919 for freebsd-net@freebsd.org; Mon, 28 Aug 2000 14:28:34 -0700 Date: Mon, 28 Aug 2000 14:28:34 -0700 From: Erick Mechler To: freebsd-net@freebsd.org Subject: de problems Message-ID: <20000828142833.M14442@sendmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.2i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Howdy. I'm having some troubles with the Digital 21143 Fast Ethernet cards I have. They're 4-port cards, and I have four of them (all total, I have de0 through de11). Here's the output of "ifconfig de9": de9: flags=8843 mtu 1500 inet 10.210.100.93 netmask 0xffffff00 broadcast 10.210.100.255 ether 00:c0:95:e0:4a:a9 media: autoselect (10baseT/UTP) status: active supported media: autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP Based on this, it appears that I can run these cards at 100baseTX full-duplex. However, the autosense on bootup assigns (as you can see above) 10baseT/UTP to the cards. I have tried manually setting the media to 100baseTX full-duplex, but it doesn't fully work. After setting de9 to 100baseTX full-duplex I'm able to ping the IP assigned to de9, but I can't reach any other machines on the de9 network. My question to the list is whether or not anybody has gotten these cards to work on 100MB. I'm running 3.5-STABLE as of 16 Aug. Thanks in advance. Regards, Erick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 28 14:30:13 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail.numachi.com (numachi.numachi.com [198.175.254.2]) by hub.freebsd.org (Postfix) with SMTP id AFAB137B423 for ; Mon, 28 Aug 2000 14:30:11 -0700 (PDT) Received: (qmail 10158 invoked by uid 1001); 28 Aug 2000 21:30:09 -0000 Date: Mon, 28 Aug 2000 17:30:09 -0400 From: Brian Reichert To: Bill Fumerola Cc: Brian Reichert , freebsd-net@freebsd.org Subject: Re: Macronix NIC not up to snuff? Message-ID: <20000828173009.G8519@numachi.com> References: <20000828165847.A9262@numachi.com> <20000828170838.J33771@jade.chc-chimes.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre4i In-Reply-To: <20000828170838.J33771@jade.chc-chimes.com>; from billf@chimesnet.com on Mon, Aug 28, 2000 at 05:08:38PM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Aug 28, 2000 at 05:08:38PM -0400, Bill Fumerola wrote: > On Mon, Aug 28, 2000 at 04:58:47PM -0400, Brian Reichert wrote: > > > > Both of these boxes work fine with our FlowPoint DSL router, a > > cheesy 3Com 10bT hub, and an even cheesier Ark Technologies > > autosensing switch. > > > > I'm installing a Cisco Catalyst 2924 XL running IOS Version > > 11.2(8)SA3. > > Crisco ethernet switches are notorious for screwing up autodetect. That may very well be, but only these cards are suffering. > Force them with media or mediaopt, and force the duplex and speed > on the cisco and see if that helps. This might be a useful workaraound (which I'll try later), but it doesn't clear my worries that it's the NIC+OS combination that's wonky... (I have other 4.x boxes with other NICs that work fine...) > -- > Bill Fumerola - Network Architect, BOFH / Chimes, Inc. > billf@chimesnet.com / billf@FreeBSD.org -- Brian 'you Bastard' Reichert reichert@numachi.com 37 Crystal Ave. #303 Daytime number: (603) 434-6842 Derry NH 03038-1713 USA Intel architecture: the left-hand path To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 28 14:32: 9 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 0EB7E37B424 for ; Mon, 28 Aug 2000 14:32:02 -0700 (PDT) Received: by jade.chc-chimes.com (Postfix, from userid 1001) id 9AE9D1C66; Mon, 28 Aug 2000 17:32:01 -0400 (EDT) Date: Mon, 28 Aug 2000 17:32:01 -0400 From: Bill Fumerola To: Brian Reichert Cc: freebsd-net@freebsd.org Subject: Re: Macronix NIC not up to snuff? Message-ID: <20000828173201.L33771@jade.chc-chimes.com> References: <20000828165847.A9262@numachi.com> <20000828170838.J33771@jade.chc-chimes.com> <20000828173009.G8519@numachi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20000828173009.G8519@numachi.com>; from reichert@numachi.com on Mon, Aug 28, 2000 at 05:30:09PM -0400 X-Operating-System: FreeBSD 3.3-STABLE i386 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Aug 28, 2000 at 05:30:09PM -0400, Brian Reichert wrote: > > > Both of these boxes work fine with our FlowPoint DSL router, a > > > cheesy 3Com 10bT hub, and an even cheesier Ark Technologies > > > autosensing switch. > > > > > > I'm installing a Cisco Catalyst 2924 XL running IOS Version > > > 11.2(8)SA3. > > > > Crisco ethernet switches are notorious for screwing up autodetect. > > That may very well be, but only these cards are suffering. > > > Force them with media or mediaopt, and force the duplex and speed > > on the cisco and see if that helps. > > This might be a useful workaraound (which I'll try later), but it > doesn't clear my worries that it's the NIC+OS combination that's > wonky... Logically, you say the combination works find with: A dsl router a 3com hub an offbrand switch but it doesn't work with: the cisco. search the mail archives, this has been brought up before. -- 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 Mon Aug 28 15:24:48 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail.numachi.com (numachi.numachi.com [198.175.254.2]) by hub.freebsd.org (Postfix) with SMTP id 2A46337B424 for ; Mon, 28 Aug 2000 15:24:44 -0700 (PDT) Received: (qmail 10465 invoked by uid 1001); 28 Aug 2000 22:24:42 -0000 Date: Mon, 28 Aug 2000 18:24:42 -0400 From: Brian Reichert To: Wes Peters Cc: Brian Reichert , Bill Fumerola , freebsd-net@freebsd.org Subject: Re: Macronix NIC not up to snuff? Message-ID: <20000828182441.H8519@numachi.com> References: <20000828165847.A9262@numachi.com> <20000828170838.J33771@jade.chc-chimes.com> <20000828173009.G8519@numachi.com> <39AAE64E.96584FB8@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre4i In-Reply-To: <39AAE64E.96584FB8@softweyr.com>; from wes@softweyr.com on Mon, Aug 28, 2000 at 04:23:10PM -0600 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Aug 28, 2000 at 04:23:10PM -0600, Wes Peters wrote: > > > Force them with media or mediaopt, and force the duplex and speed > > > on the cisco and see if that helps. > > > > This might be a useful workaraound (which I'll try later), but it > > doesn't clear my worries that it's the NIC+OS combination that's > > wonky... > > No, it's the combination of the PHY on the switch vs. the PHY on the NIC. > What he gave you isn't a workaround, it's a solution to an endemic problem: > autodetection often doesn't work. If it doesn't work, no amount of wanting > it to work is going to fix the problem, so go fix the problem. Ok, I concede. I guess I'm lucky: the hundreds of combinations of NICs and switches/hubs I'm messed with over the years never gave this grief. Thanks for the advice, everyone... > -- > "Where am I, and what am I doing in this handbasket?" > > Wes Peters Softweyr LLC > wes@softweyr.com http://softweyr.com/ -- Brian 'you Bastard' Reichert reichert@numachi.com 37 Crystal Ave. #303 Daytime number: (603) 434-6842 Derry NH 03038-1713 USA Intel architecture: the left-hand path To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 28 17: 8:48 2000 Delivered-To: freebsd-net@freebsd.org Received: from field.videotron.net (field.videotron.net [205.151.222.108]) by hub.freebsd.org (Postfix) with ESMTP id EFB3F37B422 for ; Mon, 28 Aug 2000 17:08:44 -0700 (PDT) Received: from modemcable136.203-201-24.mtl.mc.videotron.net ([24.201.203.136]) by field.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0G0100EE91IHQ1@field.videotron.net> for freebsd-net@FreeBSD.ORG; Mon, 28 Aug 2000 20:03:54 -0400 (EDT) Date: Mon, 28 Aug 2000 20:07:07 -0400 (EDT) From: Bosko Milekic Subject: Re: de problems In-reply-to: <20000828142833.M14442@sendmail.com> X-Sender: bmilekic@jehovah.technokratis.com To: Erick Mechler Cc: freebsd-net@FreeBSD.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 Hi, Yeah, the cards should work fine in full-duplex. How are you connecting your machines? Through a 10/100 hub, a switch, or what? Cheers, Bosko. On Mon, 28 Aug 2000, Erick Mechler wrote: > Howdy. > > I'm having some troubles with the Digital 21143 Fast Ethernet cards I have. > They're 4-port cards, and I have four of them (all total, I have de0 > through de11). Here's the output of "ifconfig de9": > > de9: flags=8843 mtu 1500 > inet 10.210.100.93 netmask 0xffffff00 broadcast 10.210.100.255 > ether 00:c0:95:e0:4a:a9 > media: autoselect (10baseT/UTP) status: active > supported media: autoselect 100baseTX 100baseTX > 10baseT/UTP 10baseT/UTP > > Based on this, it appears that I can run these cards at 100baseTX > full-duplex. However, the autosense on bootup assigns (as you can see > above) 10baseT/UTP to the cards. > > I have tried manually setting the media to 100baseTX full-duplex, but it > doesn't fully work. After setting de9 to 100baseTX full-duplex I'm able to > ping the IP assigned to de9, but I can't reach any other machines on the > de9 network. > > My question to the list is whether or not anybody has gotten these cards to > work on 100MB. I'm running 3.5-STABLE as of 16 Aug. Thanks in advance. > > Regards, > Erick -- Bosko Milekic * Voice/Mobile: 514.865.7738 * Pager: 514.921.0237 bmilekic@technokratis.com * http://www.technokratis.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 29 3:59:11 2000 Delivered-To: freebsd-net@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id A508737B440 for ; Tue, 29 Aug 2000 03:59:08 -0700 (PDT) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 29 Aug 2000 11:59:07 +0100 (BST) To: Archie Cobbs Cc: bmilekic@dsuper.net, dwmalone@maths.tcd.ie, freebsd-net@FreeBSD.ORG, iedowse@maths.tcd.ie Subject: Re: Proposal to clarify mbuf handling rules In-reply-to: Your message of "Mon, 28 Aug 2000 13:41:16 PDT." <200008282041.NAA71818@bubba.whistle.com> X-Request-Do: Date: Tue, 29 Aug 2000 11:59:06 +0100 From: David Malone Message-ID: <200008291159.aa60672@salmon.maths.tcd.ie> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > (a) The mbuf data should not be written to under any circumstances. > even if it is a cluster mbuf and the reference count becomes 1. > (b) The mbuf data may be written to. This implies that if this mbuf > is a cluster, then the reference count is 1. > (c) The mbuf data may not be written to, BUT if it is a cluster mbuf > and the reference count decreases to 1, then it may then be > written to. I think it would be a nice idea not to tie this to clusters, but to have the M_RDONLY as an option which is given at the time which external storage is first attached to a mbuf. This means we set M_RDONLY for sendfile bufs, but don't set it for mbuf's with no external storage, regular clusters or for jumbo ethernet storage (once we've checked this with Bill Paul naturally). We will have to be careful with the M_WRITABLE flag, as it is stored in the mbufs rather than the externam storage, and there may be multiple mbufs referencing this storage. Think of the following situations: 1) When we first make a mbuf we set M_WRITABLE according to !M_RDONLY. 2) If we make a second mbuf which references this original mbuf we can clear M_WRITABLE in both mbufs, as we have access to both. 3) Adding references from now on isn't a problem as M_WRITABLE is clear. 4) Now, consider the situation where we are freeing the second last mbuf referencing this storage. We have access to the mbuf we are freeing, but not to the remain mbuf, in which we want to set M_WRITABLE. I can't see an obvious way around this, so we may find situations where M_WRITABLE is not set, but the storage is writable. This would translate to a M_IS_WRITABLE macro like: #define M_IS_WRITABLE(m) ((m)->m_flags & M_WRITABLE) || \ (!((m)->m_flags & M_RDONLY) && !MEXT_IS_REF(m) && \ ((m)->m_flags |= M_WRITABLE) \ ) Note, this macro actually sets the M_WRITABLE flag, which is a bit icky - but seems reasonable given that M_WRITABLE is supposed to be cache for the value of !((m)->m_flags & M_RDONLY) && !MEXT_IS_REF(m). The alternative is to just add the M_RDONLY flag and define: #define M_IS_WRITABLE(m) (!((m)->m_flags & M_RDONLY) && !MEXT_IS_REF(m)) I think in real terms we may find this is a cleaner solution; This check is not going to be a hugely expensive operation compared to the alternative above. Finally, it might actually be better to have the opposit sense for the M_RDONLY flag (call is M_MAYBEWRITEABLE or somethign more catchy). This would mean that if someone initially forgets to set the flag, it will be zero and the storage will not accidently be written to. I think it would also give us a better chance of catching things we're accidently writing to with KASSERTs. David. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 29 5:24:46 2000 Delivered-To: freebsd-net@freebsd.org Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by hub.freebsd.org (Postfix) with SMTP id 9B7CB37B42C; Tue, 29 Aug 2000 05:24:38 -0700 (PDT) Received: from ginger.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 29 Aug 2000 13:22:46 +0100 Message-ID: <39ABAB14.D3001EA@cs.ucl.ac.uk> Date: Tue, 29 Aug 2000 13:22:44 +0100 From: Theo PAGTZIS Reply-To: t.pagtzis@cs.ucl.ac.uk Organization: UCL X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: el, en MIME-Version: 1.0 To: Jim Flowers Cc: Theo PAGTZIS , Wes Peters , Eric Kozowski , freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: fbsd box acting as a wavelan BS and stats References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Jim Flowers wrote: > Seems to work ok on 4.0-RELEASE #0. > > Jim Flowers > #4 ranked ISP on C|NET #1 in Ohio > > On Mon, 28 Aug 2000, Theo PAGTZIS wrote: > > > > Wes, > > > > quite correct. I considered revisiting the matter non-important since anyone > > that would > > use fbsd 3.4 or later should have such features by default...(otherwise wavelan > > support would > > be pretty stranded :).. > > > > Now, I have my reservations about the card's statistics counters.....I have yet to > > see working statistics > > on the wavelan interface...That has *not* been working since 3.4 for me...anyone > > that can tell me I am > > wrong...please do as I want to use these stats pretty badly... > > > > Theo > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message Jim, I have 7 fbsd 4.1 boxes...I do basic ping between machines and then try wicontrol -i wi0 -o all I get is Transmitted unicast frames: 0 Transmitted multicast frames: 0 Transmitted fragments: 0 Transmitted unicast octets: 0 Transmitted multicast octets: 0 Single transmit retries: 0 Multiple transmit retries: 0 Transmit retry limit exceeded: 0 Transmit discards: 0 Transmit discards due to wrong SA: 0 Received unicast frames: 0 Received multicast frames: 0 Received fragments: 0 Received unicast octets: 0 Received multicast octets: 0 Receive FCS errors: 0 Receive discards due to no buffer: 0 Can't decrypt WEP frame: 0 Received message fragments: 0 Received message bad fragments: 0 Is that what you get? Theo To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 29 5:50:49 2000 Delivered-To: freebsd-net@freebsd.org Received: from web3006.mail.yahoo.com (web3006.mail.yahoo.com [204.71.202.169]) by hub.freebsd.org (Postfix) with SMTP id 2006237B43C for ; Tue, 29 Aug 2000 05:50:47 -0700 (PDT) Received: (qmail 8227 invoked by uid 60001); 29 Aug 2000 12:50:41 -0000 Message-ID: <20000829125041.8226.qmail@web3006.mail.yahoo.com> Received: from [164.164.56.2] by web3006.mail.yahoo.com; Tue, 29 Aug 2000 05:50:41 PDT Date: Tue, 29 Aug 2000 05:50:41 -0700 (PDT) From: deepika kakrania Subject: Problem in calling ip_input() To: freebsd-net@freeBSD.ORG, freebsd-hackers@freeBSD.O Cc: deepika_77@yahoo.com 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 changed if_ethersubr.c slightly to support a new protocol. In ehter_output, an additional header is added for this protocol between ethernet herader and IP header. ethernet header|New protocol header| IP header| Transport layer header In ether_input(), after doing neccesary checks for this protocol,the packet is assigned to ipintrq for normal ip processing in following manner. schednetisr(NETISR_IP) inq = &ipintrq; Now for testing when i send some ping packets with this additional new header to a host(which supports this new protocol), i find that i get reply only for first packet after rebooting. For rest packets , ip_input is not being called even after packets are enqued in ipintrq. Could anyone explain to me what can be the problem here? Thanks in advance. regards, deepika __________________________________________________ Do You Yahoo!? Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 29 6:31:25 2000 Delivered-To: freebsd-net@freebsd.org Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by hub.freebsd.org (Postfix) with SMTP id E09A537B43E; Tue, 29 Aug 2000 06:31:17 -0700 (PDT) Received: from ginger.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 29 Aug 2000 14:30:17 +0100 Message-ID: <39ABBAE7.558D6011@cs.ucl.ac.uk> Date: Tue, 29 Aug 2000 14:30:15 +0100 From: Theo PAGTZIS Reply-To: t.pagtzis@cs.ucl.ac.uk Organization: UCL X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: el, en MIME-Version: 1.0 To: Bernie Doehner Cc: Jim Flowers , Wes Peters , Eric Kozowski , freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: fbsd box acting as a wavelan BS and stats References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Bernie, Bernie Doehner wrote: > Quick clarrification is in order.. Are you running wi0 or wl0 driver? I am running the wi0 driver, I am only referring to wi0 driver, nothing else.. > > To the best of my knowledge wicontrol only works with the wi0 driver. > > I only have the first gen NCR full-height ISA cards at my site, so I am > using the wl0 driver, and wicontrol does not work with it. > > Bernie > > On Tue, 29 Aug 2000, Theo PAGTZIS wrote: > > > Jim Flowers wrote: > > > > > Seems to work ok on 4.0-RELEASE #0. > > > > > > Jim Flowers > > > #4 ranked ISP on C|NET #1 in Ohio > > > > > > On Mon, 28 Aug 2000, Theo PAGTZIS wrote: > > > > > > > > Wes, > > > > > > > > quite correct. I considered revisiting the matter non-important since anyone > > > > that would > > > > use fbsd 3.4 or later should have such features by default...(otherwise wavelan > > > > support would > > > > be pretty stranded :).. > > > > > > > > Now, I have my reservations about the card's statistics counters.....I have yet to > > > > see working statistics > > > > on the wavelan interface...That has *not* been working since 3.4 for me...anyone > > > > that can tell me I am > > > > wrong...please do as I want to use these stats pretty badly... > > > > > > > > Theo > > > > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > with "unsubscribe freebsd-hackers" in the body of the message > > > > Jim, > > > > I have 7 fbsd 4.1 boxes...I do basic ping between machines and then try wicontrol -i > > wi0 -o > > all I get is > > Transmitted unicast frames: 0 > > Transmitted multicast frames: 0 > > Transmitted fragments: 0 > > Transmitted unicast octets: 0 > > Transmitted multicast octets: 0 > > Single transmit retries: 0 > > Multiple transmit retries: 0 > > Transmit retry limit exceeded: 0 > > Transmit discards: 0 > > Transmit discards due to wrong SA: 0 > > Received unicast frames: 0 > > Received multicast frames: 0 > > Received fragments: 0 > > Received unicast octets: 0 > > Received multicast octets: 0 > > Receive FCS errors: 0 > > Receive discards due to no buffer: 0 > > Can't decrypt WEP frame: 0 > > Received message fragments: 0 > > Received message bad fragments: 0 > > > > Is that what you get? > > > > Theo > > > > > > > > > > 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 Tue Aug 29 9:11:17 2000 Delivered-To: freebsd-net@freebsd.org Received: from peony.ezo.net (peony.ezo.net [206.102.130.11]) by hub.freebsd.org (Postfix) with ESMTP id 2DCE637B423; Tue, 29 Aug 2000 09:11:11 -0700 (PDT) Received: from localhost (jflowers@localhost) by peony.ezo.net (8.11.0.Beta3/8.11.0.Beta3) with ESMTP id e7TGB2018577; Tue, 29 Aug 2000 12:11:02 -0400 (EDT) Date: Tue, 29 Aug 2000 12:11:01 -0400 (EDT) From: Jim Flowers To: Theo PAGTZIS Cc: Wes Peters , Eric Kozowski , freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: fbsd box acting as a wavelan BS and stats In-Reply-To: <39ABAB14.D3001EA@cs.ucl.ac.uk> 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 Nope snip ----------------------- wicontrol -i wi0 -o Transmitted unicast frames: 181061 Transmitted multicast frames: 0 Transmitted fragments: 181161 Transmitted unicast octets: 25702660 Transmitted multicast octets: 0 Single transmit retries: 13557 Multiple transmit retries: 10208 Transmit retry limit exceeded: 15151 Transmit discards: 0 Transmit discards due to wrong SA: 0 Received unicast frames: 215209 Received multicast frames: 11804 Received fragments: 5396844 Received unicast octets: 177192551 Received multicast octets: 969400 Receive FCS errors: 739429 Receive discards due to no buffer: 0 Can't decrypt WEP frame: 0 Received message fragments: 412 Received message bad fragments: 12513 ----------- Jim Flowers #4 ranked ISP on C|NET #1 in Ohio On Tue, 29 Aug 2000, Theo PAGTZIS wrote: > Jim Flowers wrote: > > > Seems to work ok on 4.0-RELEASE #0. > > > > Jim Flowers > > #4 ranked ISP on C|NET #1 in Ohio > > > > On Mon, 28 Aug 2000, Theo PAGTZIS wrote: > > Jim, > > I have 7 fbsd 4.1 boxes...I do basic ping between machines and then try wicontrol -i > wi0 -o > all I get is > Transmitted unicast frames: 0 > Transmitted multicast frames: 0 > Transmitted fragments: 0 > Transmitted unicast octets: 0 > Transmitted multicast octets: 0 > Single transmit retries: 0 > Multiple transmit retries: 0 > Transmit retry limit exceeded: 0 > Transmit discards: 0 > Transmit discards due to wrong SA: 0 > Received unicast frames: 0 > Received multicast frames: 0 > Received fragments: 0 > Received unicast octets: 0 > Received multicast octets: 0 > Receive FCS errors: 0 > Receive discards due to no buffer: 0 > Can't decrypt WEP frame: 0 > Received message fragments: 0 > Received message bad fragments: 0 > > Is that what you get? > > Theo > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 29 9:29:57 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 685F437B424; Tue, 29 Aug 2000 09:29:35 -0700 (PDT) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.9.3/1.13) id TAA39938; Tue, 29 Aug 2000 19:29:13 +0300 (EEST) Date: Tue, 29 Aug 2000 19:29:13 +0300 From: Ruslan Ermilov To: net@FreeBSD.org Cc: Garrett Wollman , Bill Fenner , Darren Reed , Kannan Varadhan , Frank Volf Subject: CFR: patch for ICMP error generation bugs Message-ID: <20000829192913.A39253@sunbay.com> Mail-Followup-To: net@FreeBSD.org, Garrett Wollman , Bill Fenner , Darren Reed , Kannan Varadhan , Frank Volf Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="5vNYLRcllDrimb99" X-Mailer: Mutt 1.0i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --5vNYLRcllDrimb99 Content-Type: text/plain; charset=us-ascii Hi! There are at least two problem reports PR 16240 and PR 20877 that this patch addresses. You can easily see yourself what gets wrong by monitoring ICMP error messages containing part of original datagram with `tcpdump -vvnx icmp' and comparing the original datagram with one in generated ICMP error. You will notice that sometimes fields are in host byte order, or TTL field is decremented. At least one case is not fixed by this patch -- in an IPFW based firewall, when we have a `unreach foo' rule matching `out'going packets, the ip_ttl field is still decremented. Please note that `udp_usrreq.c,v 1.71 by darrenr' should be backed out in order to apply and test this patch. Comments please, -- 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 --5vNYLRcllDrimb99 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p Index: ip_icmp.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_icmp.c,v retrieving revision 1.43 diff -u -p -r1.43 ip_icmp.c --- ip_icmp.c 2000/06/02 20:18:38 1.43 +++ ip_icmp.c 2000/08/29 15:50:18 @@ -191,7 +191,13 @@ icmp_error(n, type, code, dest, destifp) icp->icmp_code = code; bcopy((caddr_t)oip, (caddr_t)&icp->icmp_ip, icmplen); nip = &icp->icmp_ip; - nip->ip_len = htons((u_short)(nip->ip_len + oiplen)); + + /* + * Convert fields to network representation. + */ + HTONS(nip->ip_len); + HTONS(nip->ip_id); + HTONS(nip->ip_off); /* * Now, copy old ip header (without options) Index: ip_input.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_input.c,v retrieving revision 1.138 diff -u -p -r1.138 ip_input.c --- ip_input.c 2000/07/31 23:41:47 1.138 +++ ip_input.c 2000/08/29 15:50:19 @@ -1290,7 +1290,6 @@ nosourcerouting: } return (0); bad: - ip->ip_len -= IP_VHL_HL(ip->ip_vhl) << 2; /* XXX icmp_error adds in hdr length */ icmp_error(m, type, code, 0, 0); ipstat.ips_badoptions++; return (1); @@ -1496,19 +1495,14 @@ ip_forward(m, srcrt) m_freem(m); return; } - HTONS(ip->ip_id); #ifdef IPSTEALTH - if (!ipstealth) { + if (!ipstealth) #endif if (ip->ip_ttl <= IPTTLDEC) { icmp_error(m, ICMP_TIMXCEED, ICMP_TIMXCEED_INTRANS, dest, 0); return; } - ip->ip_ttl -= IPTTLDEC; -#ifdef IPSTEALTH - } -#endif sin = (struct sockaddr_in *)&ipforward_rt.ro_dst; if ((rt = ipforward_rt.ro_rt) == 0 || @@ -1534,7 +1528,14 @@ ip_forward(m, srcrt) * we need to generate an ICMP message to the src. */ mcopy = m_copy(m, 0, imin((int)ip->ip_len, 64)); + if (mcopy && (mcopy->m_flags & M_EXT)) + m_copydata(mcopy, 0, sizeof(struct ip), mtod(mcopy, caddr_t)); +#ifdef IPSTEALTH + if (!ipstealth) +#endif + ip->ip_ttl -= IPTTLDEC; + /* * If forwarding packet using same interface that it came in on, * perhaps should send a redirect to sender to shortcut a hop. @@ -1567,6 +1568,7 @@ ip_forward(m, srcrt) } } + HTONS(ip->ip_id); error = ip_output(m, (struct mbuf *)0, &ipforward_rt, IP_FORWARDING, 0); if (error) @@ -1672,6 +1674,8 @@ ip_forward(m, srcrt) m_freem(mcopy); return; } + if (mcopy->m_flags & M_EXT) + m_copyback(mcopy, 0, sizeof(struct ip), mtod(mcopy, caddr_t)); icmp_error(mcopy, type, code, dest, destifp); } Index: ip_output.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_output.c,v retrieving revision 1.109 diff -u -p -r1.109 ip_output.c --- ip_output.c 2000/07/31 13:11:41 1.109 +++ ip_output.c 2000/08/29 15:50:19 @@ -462,6 +462,7 @@ sendit: if (fw_enable && ip_fw_chk_ptr) { struct sockaddr_in *old = dst; + NTOHS(ip->ip_id); off = (*ip_fw_chk_ptr)(&ip, hlen, ifp, &divert_cookie, &m, &rule, &dst); /* @@ -482,6 +483,7 @@ sendit: error = EACCES; goto done; } + HTONS(ip->ip_id); if (off == 0 && dst == old) /* common case */ goto pass ; #ifdef DUMMYNET Index: udp_usrreq.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/udp_usrreq.c,v retrieving revision 1.70 diff -u -p -r1.70 udp_usrreq.c --- udp_usrreq.c 2000/07/04 16:35:05 1.70 +++ udp_usrreq.c 2000/08/29 15:50:19 @@ -353,11 +353,12 @@ udp_input(m, off, proto) udpstat.udps_noportbcast++; goto bad; } - *ip = save_ip; if (badport_bandlim(0) < 0) goto bad; if (blackhole) goto bad; + *ip = save_ip; + ip->ip_len += iphlen; icmp_error(m, ICMP_UNREACH, ICMP_UNREACH_PORT, 0, 0); return; } --5vNYLRcllDrimb99-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 29 9:48:19 2000 Delivered-To: freebsd-net@freebsd.org Received: from ns1.infowest.com (ns1.infowest.com [204.17.177.10]) by hub.freebsd.org (Postfix) with ESMTP id B11D337B422; Tue, 29 Aug 2000 09:48:06 -0700 (PDT) Received: from tambler.infowest.com (sgutab-mega01-ethfxp0.infowest.net [216.190.25.202]) by ns1.infowest.com (Postfix) with SMTP id D4D4A20F08; Tue, 29 Aug 2000 10:48:00 -0600 (MDT) From: "Aaron Gifford" To: , Subject: Bug in jail with UDP??? Message-Id: <20000829164800.D4D4A20F08@ns1.infowest.com> Date: Tue, 29 Aug 2000 10:48:00 -0600 (MDT) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org /* (The body of this email message is a C program that demonstrates the bug in the FreeBSD jail system when using UDP. Please save the body of this message with a file name like udpjailtest.c or some other appropriate name if you wish to test this demo.) Hello, While setting up a FreeBSD 4.1-STABLE (as of 15 Aug 2000) jail for running the Jabber instant messaging system inside, including an ICQ transport/gateway, I discovered the following unusual or at least unexpected (by me) behavior of FreeBSD's jail: A UDP datagram socket that uses connect() without first using bind() will end up using the primary interface IP address for the connection instead of the expected jail IP address (which in this case was an alias IP address on that same interface). I wrote this little C program (this message IS the C test program) to demonstrate this. Compile this program, then create an alias IP address, then run this program within a jail using that alias IP address; Assuming a jail environment in /path/to/jail/env and assuming an etheret interface of fxp0 and a primary IP address on that interface of 10.50.23.200/255.255.255.0: cc -o /path/to/jail/env/udpjailtest udpjailtest.c ifconfig fxp0 inet 10.50.23.233 netmask 255.255.255.255 alias jail /path/to/jail/env jail.host.name 10.50.23.233 udpjailtest Then you would see something like: The following socket (asock) has NOT been bound to a local address using bind() and so if in a jail this socket will probably show the host's main IP address instead of the jail IP address: Socket name is IP address 10.50.23.200 port 50189 The following socket (bsock) HAS been bound to a local address (INADDR_ANY) using bind() and so inside of a jail, this should show the proper jail IP address as expected: Socket name is IP address 10.50.23.233 port 49933 Why is this so? Of course I would expect any program worth its salt to bind() the datagram socket before connect()ing to a remote address, but there are cases where programs do not bother with that step. The case in point being the icqtransport program for the Jabber IM system. Can anyone enlighten me as to whether this is a bug in the jail() system, or a feature? Thanks! Aaron out. */ #include #include #include #include #include #include #include /* I use a.root-servers.net, but any remote IP will do */ #define REMOTE_NAMESERVER_IP "198.41.0.4" void showsockname(int sock) { socklen_t len = sizeof(struct sockaddr_in); struct sockaddr_in addr; if (getsockname(sock, (struct sockaddr *)&addr, &len) != 0) { printf("getsockname(): %d %s\n", errno, strerror(errno)); return; } printf("Socket name is IP address %s port %d\n", inet_ntoa(addr.sin_addr), addr.sin_port); } main() { struct sockaddr_in local; struct sockaddr_in remote; int asock, bsock; unsigned long ip; if ((asock = socket(PF_INET, SOCK_DGRAM, 0)) < 0) { printf("socket(): %d %s\n", errno, strerror(errno)); return; } if ((bsock = socket(PF_INET, SOCK_DGRAM, 0)) < 0) { printf("socket(): %d %s\n", errno, strerror(errno)); return; } bzero(&local, sizeof(struct sockaddr_in)); bzero(&remote, sizeof(struct sockaddr_in)); local.sin_family = remote.sin_family = AF_INET; local.sin_addr.s_addr = INADDR_ANY; remote.sin_addr.s_addr = inet_addr(REMOTE_NAMESERVER_IP); local.sin_port = htons(0); remote.sin_port = htons(53); /* Only bsock gets boundto INADDR_ANY */ if (bind(bsock,(struct sockaddr *)&local, sizeof(struct sockaddr_in)) != 0) { printf("bind(): %d %s\n", errno, strerror(errno)); return; } if (connect(asock, (struct sockaddr *)(&remote), sizeof(struct sockaddr_in)) != 0) { printf("connect(): %d %s\n", errno, strerror(errno)); return; } if (connect(bsock, (struct sockaddr *)(&remote), sizeof(struct sockaddr_in)) != 0) { printf("connect(): %d %s\n", errno, strerror(errno)); return; } printf("The following socket (asock) has NOT been bound to a local address using\n"); printf("bind() and so if in a jail this socket will probably show the host's main\n"); printf("IP address instead of the jail IP address:\n"); showsockname(asock); printf("\nThe following socket (bsock) HAS been bound to a local address (INADDR_ANY)\n"); printf("using bind() and so inside of a jail, this should show the proper jail IP\n"); printf("address as expected:\n"); showsockname(bsock); } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 29 10:25:33 2000 Delivered-To: freebsd-net@freebsd.org Received: from onion.ish.org (onion.ish.org [210.145.219.202]) by hub.freebsd.org (Postfix) with ESMTP id 47A5737B422 for ; Tue, 29 Aug 2000 10:25:28 -0700 (PDT) Received: from localhost (ishizuka@localhost [127.0.0.1]) by onion.ish.org (8.9.3/3.7Wpl2-2000/05/28) with ESMTP id CAA69603 for ; Wed, 30 Aug 2000 02:25:26 +0900 (JST) To: freebsd-net@freebsd.org Subject: bridge on FreeBSD 4.1R X-Mailer: Mew version 1.94.2 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) X-PGP-Fingerprint20: 276D 697A C2CB 1580 C683 8F18 DA98 1A4A 50D2 C4CB X-PGP-Fingerprint16: C6 DE 46 24 D7 9F 22 EB 79 E2 90 AB 1B 9A 35 2E X-PGP-Public-Key: http://www.ish.org/pgp-public-key.txt X-URL: http://www.ish.org/ Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000830022526S.ishizuka@onion.ish.org> Date: Wed, 30 Aug 2000 02:25:26 +0900 From: Masachika ISHIZUKA X-Dispatcher: imput version 20000414(IM141) Lines: 55 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I want to use bridge on 4.1-RELEASE with the following kernel options and two fxp NICs. options IPFIREWALL options IPFIREWALL_VERBOSE options BRIDGE options DUMMYNET I have two questions. (1) options IPFIREWALL_DEFAULT_TO_ACCEPT is needed ? On 4.0R, I think the 'options IPFIREWALL_DEFAULT_TO_ACCEPT' is needed to pass the non IP packets like ARP. On 4.1R, with the 'options IPFIREWALL_DEFAULT_TO_ACCEPT', the counter values of 'ipfw -at list 65535' is not up even when passing ARP packets. I think the line number of 681 in /sys/net/bridge.c is bypass the ipfw for non IP packets. Is it right ? (2) Arp invalid MAC address once a week or less ? I use bridge shown as follows. Backbone #1 Backbone #2 ^ ^ | | +-----+-----+ +-----+-----+ |cisco 7206 | |cisco 7513 | +-----+-----+ +-----+-----+ | | ------+------------+------------+------ | |MAC: A1:A2:A3:A4:A5:A6 +-----+-----+ | bridge | | (4.1R) | +-----+-----+ |MAC: B1:B2:B3:B4:B5:B6 | |MAC: C1:C2:C3:C4:C5:C6, IP: 10.1.1.1 +-----+-----+ | client PC | | (4.1R) | +-----------+ Normally, the arp tables of cisco 7206 and cisco 7513 are '10.1.1.1 C1C2.C3C4.C5C6'. But once a week or less, The arp tables of both cisco routers are '10.1.1.1 B1B2.B3B4.C5C6', that is the first 4 bytes of MAC address in arp table is invalid. Are there any one with the same problems ? Thank you for advice and sorry to my poor English. -- ishizuka@ish.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 29 10:53:45 2000 Delivered-To: freebsd-net@freebsd.org Received: from maxwell.syr.edu (maxwell.syr.edu [128.230.129.5]) by hub.freebsd.org (Postfix) with ESMTP id EB20C37B43E for ; Tue, 29 Aug 2000 10:53:43 -0700 (PDT) Received: from exchange.maxwell.syr.edu (exchange.maxwell.syr.edu [128.230.129.241]) by maxwell.syr.edu (8.9.3/8.9.1) with ESMTP id NAA61434 for ; Tue, 29 Aug 2000 13:53:47 -0400 (EDT) Received: by exchange.maxwell.syr.edu with Internet Mail Service (5.5.2650.21) id ; Tue, 29 Aug 2000 13:53:42 -0400 Message-ID: From: "Christopher M. Sedore" To: freebsd-net@FreeBSD.ORG Subject: Route advertising Date: Tue, 29 Aug 2000 13:53:38 -0400 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 I feel a little silly asking this, but: what is the recommended way to "force" a route announcement via RIP in FreeBSD 4.1? The situation is this: I have a remote network connected back into my own with a ipsec tunnel. I need to advertise the remote network on my local network, and, for a variety of reasons, I don't want to let RIP propagate the route all the way back from the interface on the FreeBSD box at the remote site. I have a router/firewall running 4.1-RELEASE that the is the local endpoint of the ipsec tunnel and I'd like to force routed to advertise a route to this remote net. -Chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 29 12:12:51 2000 Delivered-To: freebsd-net@freebsd.org Received: from web9301.mail.yahoo.com (web9301.mail.yahoo.com [216.136.129.50]) by hub.freebsd.org (Postfix) with SMTP id BA90437B423 for ; Tue, 29 Aug 2000 12:12:49 -0700 (PDT) Message-ID: <20000829191216.68328.qmail@web9301.mail.yahoo.com> Received: from [12.40.126.90] by web9301.mail.yahoo.com; Tue, 29 Aug 2000 12:12:16 PDT Date: Tue, 29 Aug 2000 12:12:16 -0700 (PDT) From: Chris Griffiths Subject: mpd-netgraph and vpn issues To: 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 Hello, I was wondering if anyone has a working implementation of mpd-netgraph under 4.1 -stable on the pptp server side and a client Win2k vpn pptp. I can successfully connect, however I am unable to ping from the client side on the Win2k system to the work subnet. I was wondering if anyone has tried this setup and gotten it to work. Please let me know. thanks Chris __________________________________________________ Do You Yahoo!? Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 29 13:12:44 2000 Delivered-To: freebsd-net@freebsd.org Received: from hq.ezo.net (hq.ezo.net [206.150.211.190]) by hub.freebsd.org (Postfix) with ESMTP id DBEE737B422; Tue, 29 Aug 2000 13:12:35 -0700 (PDT) Received: from zinnia (zinnia.ezo.net [206.150.211.129]) by hq.ezo.net (8.9.3/8.9.3) with SMTP id QAA03348; Tue, 29 Aug 2000 16:15:25 -0400 (EDT) (envelope-from jflowers@ezo.net) Message-ID: <003e01c011f4$31770530$81d396ce@ezo.net> From: "Jim Flowers" To: "Atsushi Onoe" , Cc: , References: <39A9E49D.A79BF6FD@softweyr.com> <200008280703.e7S732S01248@duplo.sm.sony.co.jp> Subject: Re: fbsd box acting as a wavelan BS Date: Tue, 29 Aug 2000 16:03:24 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Great. I'll try it. Bummer - it doesn't work. wicontrol dumps on next iteration after -c 1. Latest ISA board I have is Model ISAPC-00 with a barcode of 91805300 010053/C. Do you know how I can tell what version of the firmware I have? I may have to buy a new one (shudder) from Lucent. ----- Original Message ----- From: "Atsushi Onoe" To: Cc: ; ; ; ; Sent: Monday, August 28, 2000 3:03 AM Subject: Re: fbsd box acting as a wavelan BS > > > Last I checked the wi driver will not do IBSS and says so in the > > > documentation. I also tried it and couldn't get anywhere. Would be nice. > > > > Uh, er, if you mean to create a service set, Lucent apparently hasn't seen > > fit to release that sort of information about the cards yet. I can probably > > get access to it, but it would be under NDA and therefore not useful. Your > > best bet is to bug your friendly neighborhood Lucent rep into releaseing > > the full documentation (and sample source code) to Bill Paul. > > Lucent have shipped newer firmware this March which DOES support creating > IBSS. The verision 6.04 of the firmware creates IBSS by setting wicontrol > -c 1 with -p 1 (BSS mode), and joins to IBSS if no access points found. > It seems that the name of created IBSS follows "network name" specified by > -n option, not "SSID" by -q option. > > Regards, > > Atsushi Onoe > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 29 13:28:51 2000 Delivered-To: freebsd-net@freebsd.org Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by hub.freebsd.org (Postfix) with SMTP id F279237B424; Tue, 29 Aug 2000 13:28:43 -0700 (PDT) Received: from ginger.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 29 Aug 2000 21:28:25 +0100 Message-ID: <39AC1CE5.70C4FA9@cs.ucl.ac.uk> Date: Tue, 29 Aug 2000 21:28:21 +0100 From: Theo PAGTZIS Reply-To: t.pagtzis@cs.ucl.ac.uk Organization: UCL X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: el, en MIME-Version: 1.0 To: Jim Flowers Cc: Atsushi Onoe , wes , freebsd-hackers , freebsd-net Subject: Re: fbsd box acting as a wavelan BS References: <39A9E49D.A79BF6FD@softweyr.com> <200008280703.e7S732S01248@duplo.sm.sony.co.jp> <003e01c011f4$31770530$81d396ce@ezo.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Jim Flowers wrote: > Great. I'll try it. Bummer - it doesn't work. wicontrol dumps on next > iteration after -c 1. > > Latest ISA board I have is Model ISAPC-00 with a barcode of 91805300 > 010053/C. Do you know how I can tell what version of the firmware I have? > I may have to buy a new one (shudder) from Lucent. > > ----- Original Message ----- > From: "Atsushi Onoe" > To: > Cc: ; ; ; > ; > Sent: Monday, August 28, 2000 3:03 AM > Subject: Re: fbsd box acting as a wavelan BS > > > > > Last I checked the wi driver will not do IBSS and says so in the > > > > documentation. I also tried it and couldn't get anywhere. Would be > nice. > > > > > > Uh, er, if you mean to create a service set, Lucent apparently hasn't > seen > > > fit to release that sort of information about the cards yet. I can > probably > > > get access to it, but it would be under NDA and therefore not useful. > Your > > > best bet is to bug your friendly neighborhood Lucent rep into releaseing > > > the full documentation (and sample source code) to Bill Paul. > > > > Lucent have shipped newer firmware this March which DOES support creating > > IBSS. The verision 6.04 of the firmware creates IBSS by setting wicontrol > > -c 1 with -p 1 (BSS mode), and joins to IBSS if no access points found. > > It seems that the name of created IBSS follows "network name" specified by > > -n option, not "SSID" by -q option. > > > > Regards, > > > > Atsushi Onoe > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message Jim, I think the firmware is not with the ISA bridge but with the wavelan card...If it is what I think then you should be able to upgrade the firmware through a windows box with the facility they provide together with the firmware upgrade.. Theo To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 29 13:33:25 2000 Delivered-To: freebsd-net@freebsd.org Received: from darren2.lnk.telstra.net (darren2.lnk.telstra.net [139.130.53.33]) by hub.freebsd.org (Postfix) with ESMTP id 3C93737B424; Tue, 29 Aug 2000 13:33:18 -0700 (PDT) Received: (from root@localhost) by darren2.lnk.telstra.net (8.9.1/8.8.7) id UAA28443; Tue, 29 Aug 2000 20:32:56 GMT From: Darren Reed Message-Id: <200008292032.HAA19847@avalon.reed.wattle.id.au> Subject: Re: CFR: patch for ICMP error generation bugs In-Reply-To: <20000829192913.A39253@sunbay.com> from Ruslan Ermilov at "Aug 29, 0 07:29:13 pm" To: ru@FreeBSD.org (Ruslan Ermilov) Date: Wed, 30 Aug 2000 06:32:40 +1000 (EST) Cc: net@FreeBSD.org, wollman@FreeBSD.org, fenner@FreeBSD.org, darrenr@FreeBSD.org, kannanv@malgudi.research.bell-labs.com, volf@oasis.IAEhv.nl X-Mailer: ELM [version 2.4ME+ PL37 (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 In some email I received from Ruslan Ermilov, sie wrote: > Hi! > > There are at least two problem reports PR 16240 and PR 20877 > that this patch addresses. You can easily see yourself what > gets wrong by monitoring ICMP error messages containing part > of original datagram with `tcpdump -vvnx icmp' and comparing > the original datagram with one in generated ICMP error. You > will notice that sometimes fields are in host byte order, or > TTL field is decremented. > > At least one case is not fixed by this patch -- in an IPFW > based firewall, when we have a `unreach foo' rule matching > `out'going packets, the ip_ttl field is still decremented. [...] 1. I wouldn't remove the {}'s for the "ip (!ipstealth)" bit. This is more aesthetics some might argue :) 2. IMHO, "IPSTEALTH" should disappear. I understand why someone wants it but as a general "kernel option" I think it is right out of place. Let someone hack it into ipfw directly if they feel they desperately need it. But that's a separate issue. I'd not seen where it was/what it did until now. Anyone for changing FreeBSD's name to "HackBSD" ? ;-) 3. Your patch does fix up an imbalance on where HTONS()/NTOHS() - almost. ip_id should not be converted *back* to network byte order until the other fields are. This should get rid of your changes around the ipfw check in ip_output() ? Darren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 29 13:35:16 2000 Delivered-To: freebsd-net@freebsd.org Received: from news.IAEhv.nl (news.IAE.nl [194.151.64.4]) by hub.freebsd.org (Postfix) with ESMTP id 0769737B43C; Tue, 29 Aug 2000 13:35:13 -0700 (PDT) Received: (from uucp@localhost) by news.IAEhv.nl (8.9.1/8.9.1) with IAEhv.nl id WAA10123; Tue, 29 Aug 2000 22:35:12 +0200 (MET DST) Received: from avalon.oasis.IAEhv.nl (avalon.oasis.IAEhv.nl [192.168.1.3]) by drawbridge.oasis.IAEhv.nl (Postfix) with ESMTP id 7DF2D3E39; Tue, 29 Aug 2000 22:32:51 +0200 (CEST) Received: by avalon.oasis.IAEhv.nl (Postfix, from userid 226) id 69E7E3D; Tue, 29 Aug 2000 22:32:45 +0200 (CEST) Subject: Re: CFR: patch for ICMP error generation bugs In-Reply-To: <20000829192913.A39253@sunbay.com> "from Ruslan Ermilov at Aug 29, 2000 07:29:13 pm" To: Ruslan Ermilov Date: Tue, 29 Aug 2000 22:32:45 +0200 (CEST) Cc: net@FreeBSD.org, Garrett Wollman , Bill Fenner , Darren Reed , Kannan Varadhan , Frank Volf X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <20000829203245.69E7E3D@avalon.oasis.IAEhv.nl> From: volf@oasis.IAEhv.nl (Frank Volf) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi Ruslan, I checked the patch on FreeBSD 4.1-STABLE and it seems to work for me (but I do not have a very special or high traffic setup). Many thanks for your efforts. Kind regards, Frank Ruslan Ermilov wrote: > Hi! > > There are at least two problem reports PR 16240 and PR 20877 > that this patch addresses. You can easily see yourself what > gets wrong by monitoring ICMP error messages containing part > of original datagram with `tcpdump -vvnx icmp' and comparing > the original datagram with one in generated ICMP error. You > will notice that sometimes fields are in host byte order, or > TTL field is decremented. > > At least one case is not fixed by this patch -- in an IPFW > based firewall, when we have a `unreach foo' rule matching > `out'going packets, the ip_ttl field is still decremented. > > Please note that `udp_usrreq.c,v 1.71 by darrenr' should be > backed out in order to apply and test this patch. > > > Comments please, > -- > 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 [ Attachment, skipping... ] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 29 16:56:26 2000 Delivered-To: freebsd-net@freebsd.org Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (Postfix) with ESMTP id F3DA737B423 for ; Tue, 29 Aug 2000 16:56:22 -0700 (PDT) Received: (from smap@localhost) by whistle.com (8.10.0/8.10.0) id e7TNtcO21819; Tue, 29 Aug 2000 16:55:38 -0700 (PDT) Received: from bubba.whistle.com( 207.76.205.7) by whistle.com via smap (V2.0) id xma021817; Tue, 29 Aug 2000 16:55:25 -0700 Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.3) id QAA80880; Tue, 29 Aug 2000 16:55:20 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200008292355.QAA80880@bubba.whistle.com> Subject: Re: Proposal to clarify mbuf handling rules In-Reply-To: <200008291159.aa60672@salmon.maths.tcd.ie> "from David Malone at Aug 29, 2000 11:59:06 am" To: David Malone Date: Tue, 29 Aug 2000 16:55:20 -0700 (PDT) Cc: bmilekic@dsuper.net, iedowse@maths.tcd.ie, freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org David Malone writes: > > (a) The mbuf data should not be written to under any circumstances. > > even if it is a cluster mbuf and the reference count becomes 1. > > (b) The mbuf data may be written to. This implies that if this mbuf > > is a cluster, then the reference count is 1. > > (c) The mbuf data may not be written to, BUT if it is a cluster mbuf > > and the reference count decreases to 1, then it may then be > > written to. > > I think it would be a nice idea not to tie this to clusters, but > to have the M_RDONLY as an option which is given at the time which > external storage is first attached to a mbuf. This means we set > M_RDONLY for sendfile bufs, but don't set it for mbuf's with no > external storage, regular clusters or for jumbo ethernet storage > (once we've checked this with Bill Paul naturally). Right.. M_RDONLY means "the originator of this M_EXT mbuf doesn't want it to be written to, ever, period." M_WRITABLE would mean "M_RDONLY is not set, and moreover you can go ahead and write to the mbuf without further checking." > We will have to be careful with the M_WRITABLE flag, as it is stored > in the mbufs rather than the externam storage, and there may be > multiple mbufs referencing this storage. Think of the following > situations: > > 1) When we first make a mbuf we set M_WRITABLE according to !M_RDONLY. > > 2) If we make a second mbuf which references this original mbuf we > can clear M_WRITABLE in both mbufs, as we have access to both. > > 3) Adding references from now on isn't a problem as M_WRITABLE is > clear. > > 4) Now, consider the situation where we are freeing the second last > mbuf referencing this storage. We have access to the mbuf we are > freeing, but not to the remain mbuf, in which we want to set > M_WRITABLE. Ah.. didn't think of that. > I can't see an obvious way around this, so we may find situations > where M_WRITABLE is not set, but the storage is writable. This would > translate to a M_IS_WRITABLE macro like: > > #define M_IS_WRITABLE(m) ((m)->m_flags & M_WRITABLE) || \ > (!((m)->m_flags & M_RDONLY) && !MEXT_IS_REF(m) && \ > ((m)->m_flags |= M_WRITABLE) \ > ) < > Note, this macro actually sets the M_WRITABLE flag, which is a bit > icky - but seems reasonable given that M_WRITABLE is supposed to be > cache for the value of !((m)->m_flags & M_RDONLY) && !MEXT_IS_REF(m). > The alternative is to just add the M_RDONLY flag and define: > > #define M_IS_WRITABLE(m) (!((m)->m_flags & M_RDONLY) && !MEXT_IS_REF(m)) > > I think in real terms we may find this is a cleaner solution; This > check is not going to be a hugely expensive operation compared to > the alternative above. I agree.. you are probably right. Let's get rid of M_WRITABLE altogether. We can keep M_RDONLY and use M_IS_WRITABLE(m) as a macro. Except it needs to be this instead I think: #define M_IS_WRITABLE(m) (!((m)->m_flags & M_RDONLY) \ && (!((m)->m_flags & M_EXT) || !MEXT_IS_REF(m))) > Finally, it might actually be better to have the opposit sense for > the M_RDONLY flag (call is M_MAYBEWRITEABLE or somethign more > catchy). This would mean that if someone initially forgets to set > the flag, it will be zero and the storage will not accidently be > written to. I think it would also give us a better chance of > catching things we're accidently writing to with KASSERTs. Not sure about this idea.. it seems like in practice mbufs are usually writable, whearas being M_RDONLY is the exception. If we used M_MAYBEWRITEABLE then we'd have to change a lot more code. -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 Tue Aug 29 17: 8:12 2000 Delivered-To: freebsd-net@freebsd.org Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (Postfix) with ESMTP id 932EF37B424 for ; Tue, 29 Aug 2000 17:08:09 -0700 (PDT) Received: (from smap@localhost) by whistle.com (8.10.0/8.10.0) id e7U088X21946; Tue, 29 Aug 2000 17:08:08 -0700 (PDT) Received: from bubba.whistle.com( 207.76.205.7) by whistle.com via smap (V2.0) id xma021941; Tue, 29 Aug 2000 17:07:43 -0700 Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.3) id RAA80926; Tue, 29 Aug 2000 17:07:43 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200008300007.RAA80926@bubba.whistle.com> Subject: Re: mpd-netgraph and vpn issues In-Reply-To: <20000829191216.68328.qmail@web9301.mail.yahoo.com> "from Chris Griffiths at Aug 29, 2000 12:12:16 pm" To: Chris Griffiths Date: Tue, 29 Aug 2000 17:07:43 -0700 (PDT) Cc: net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Chris Griffiths writes: > I was wondering if anyone has a working implementation > of mpd-netgraph > under 4.1 -stable on the pptp server side and a client > Win2k vpn pptp. > > I can successfully connect, however I am unable to > ping from the client > side on the Win2k system to the work subnet. I was > wondering if anyone > has tried this setup and gotten it to work. It should work, assuming your Windows machine is properly configured. Are you trying to do client PPTP with proxy ARP or LAN to LAN routing? Does a tcpdump on ng0 show the packets going out? -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 Tue Aug 29 17:48:19 2000 Delivered-To: freebsd-net@freebsd.org Received: from falla.videotron.net (falla.videotron.net [205.151.222.106]) by hub.freebsd.org (Postfix) with ESMTP id B21F637B42C for ; Tue, 29 Aug 2000 17:48:10 -0700 (PDT) Received: from modemcable136.203-201-24.mtl.mc.videotron.net ([24.201.203.136]) by falla.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0G020068KXOJFB@falla.videotron.net> for freebsd-net@FreeBSD.ORG; Tue, 29 Aug 2000 20:36:19 -0400 (EDT) Date: Tue, 29 Aug 2000 20:39:35 -0400 (EDT) From: Bosko Milekic Subject: Re: Proposal to clarify mbuf handling rules In-reply-to: <200008291159.aa60672@salmon.maths.tcd.ie> X-Sender: bmilekic@jehovah.technokratis.com To: David Malone Cc: freebsd-net@FreeBSD.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, 29 Aug 2000, David Malone wrote: > > (a) The mbuf data should not be written to under any circumstances. > > even if it is a cluster mbuf and the reference count becomes 1. > > > (b) The mbuf data may be written to. This implies that if this mbuf > > is a cluster, then the reference count is 1. > > > (c) The mbuf data may not be written to, BUT if it is a cluster mbuf > > and the reference count decreases to 1, then it may then be > > written to. All of these different possibilities add quite a bit of hysteria for just figuring out which of the above a given mbuf falls under from within the mbuf subsystem alone. I think that it's rather clear that if we do intend to implement some sort of permissions structure with respect to external buffers that we need to have the mbufs referring to these ext_bufs share a unique permissions field. The solution: Change mext_refcnt union to be a mext_descr union with an additional field falling within like so: union mext_descr { union mext_descr *next_desc; struct { u_long refcnt; u_int perms; } desc; }; The cost: Additional 4 bytes per every M_EXT mbuf. (These unions are typically allocated en-masse from mb_map during bootup and more are added from mb_map on demand, assuming we have the space in mb_map, otherwise, ... we'll probably have to implement another tsleep mechanism). perms is to be modified atomically and can contain, for now: M_RDWR 0x00000000 M_RDONLY 0x00000001 [... more to come ...?] (Notice that the mext_descr _only_ contains SMP-safe atomically modifiable and shareable settings for the ext_buf -- this is like shared space for M_EXT mbufs referring to the same ext_buf -- the SMP-friendly version of the doubly-linked list solution). This solution would allow on-the-fly modification of ext_bufs permissions. If this works for you guys, and if you think it's worth it, then we should also add an ext_flags in the m_ext structure while we're add it, because it will cost us nothing (m_ext is within a union containing ample amount of scratch space in an M_EXT mbuf) and because it will allow me to remove the code that assumes that if ext_free is NULL, that we're dealing with an mcluster (which is true for now); but the new check of the flag would make the code a little faster at 0 extra overhead. The idea would be to have that ext_flags contain one of M_CLUSTER, M_WHATEVER, M_OTHER. > I think it would be a nice idea not to tie this to clusters, but > to have the M_RDONLY as an option which is given at the time which > external storage is first attached to a mbuf. This means we set > M_RDONLY for sendfile bufs, but don't set it for mbuf's with no > external storage, regular clusters or for jumbo ethernet storage > (once we've checked this with Bill Paul naturally). > > We will have to be careful with the M_WRITABLE flag, as it is stored > in the mbufs rather than the externam storage, and there may be > multiple mbufs referencing this storage. Think of the following > situations: > > 1) When we first make a mbuf we set M_WRITABLE according to !M_RDONLY. > > 2) If we make a second mbuf which references this original mbuf we > can clear M_WRITABLE in both mbufs, as we have access to both. > > 3) Adding references from now on isn't a problem as M_WRITABLE is > clear. > > 4) Now, consider the situation where we are freeing the second last > mbuf referencing this storage. We have access to the mbuf we are > freeing, but not to the remain mbuf, in which we want to set > M_WRITABLE. > > I can't see an obvious way around this, so we may find situations > where M_WRITABLE is not set, but the storage is writable. This would > translate to a M_IS_WRITABLE macro like: > > #define M_IS_WRITABLE(m) ((m)->m_flags & M_WRITABLE) || \ > (!((m)->m_flags & M_RDONLY) && !MEXT_IS_REF(m) && \ > ((m)->m_flags |= M_WRITABLE) \ > ) > > Note, this macro actually sets the M_WRITABLE flag, which is a bit > icky - but seems reasonable given that M_WRITABLE is supposed to be > cache for the value of !((m)->m_flags & M_RDONLY) && !MEXT_IS_REF(m). > The alternative is to just add the M_RDONLY flag and define: > > #define M_IS_WRITABLE(m) (!((m)->m_flags & M_RDONLY) && !MEXT_IS_REF(m)) > > I think in real terms we may find this is a cleaner solution; This > check is not going to be a hugely expensive operation compared to > the alternative above. > > Finally, it might actually be better to have the opposit sense for > the M_RDONLY flag (call is M_MAYBEWRITEABLE or somethign more > catchy). This would mean that if someone initially forgets to set > the flag, it will be zero and the storage will not accidently be > written to. I think it would also give us a better chance of > catching things we're accidently writing to with KASSERTs. > > David. If we decide to go with the above proposal, there can be one macro to set perms, and it can be of course used to remove a bit as well. There can also be two "wrapper" macros that will essentially either call the reference count increment macro and set RDONLY if it becomes > 1 or call the reference count decrement macro and unset RDONLY if it becomes exactly 1. The wrapper macros are only to be called for those wishing this specific behavior. We can have a number of such macros, if we judge them to be useful, based on the different possibilities that you listed at the beginning of this Email. Let me know what you think. Regards, Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 29 19:40:35 2000 Delivered-To: freebsd-net@freebsd.org Received: from web9305.mail.yahoo.com (web9305.mail.yahoo.com [216.136.129.54]) by hub.freebsd.org (Postfix) with SMTP id 51CB937B423 for ; Tue, 29 Aug 2000 19:40:32 -0700 (PDT) Message-ID: <20000830024002.93525.qmail@web9305.mail.yahoo.com> Received: from [216.158.26.30] by web9305.mail.yahoo.com; Tue, 29 Aug 2000 19:40:02 PDT Date: Tue, 29 Aug 2000 19:40:02 -0700 (PDT) From: Chris Griffiths Subject: Re: mpd-netgraph and vpn issues To: Archie Cobbs Cc: 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 I am trying to do client pptp with proxy arp. I can ping the client just fine from the server once connected, but cannot get any info back the other way. I will try tcpdump tommrow to see if anything is coming back up stream but I do not think it is. Please let me know if you have any suggestion and/or have tried this. Thanks Chris --- Archie Cobbs wrote: > Chris Griffiths writes: > > I was wondering if anyone has a working > implementation > > of mpd-netgraph > > under 4.1 -stable on the pptp server side and a > client > > Win2k vpn pptp. > > > > I can successfully connect, however I am unable to > > ping from the client > > side on the Win2k system to the work subnet. I > was > > wondering if anyone > > has tried this setup and gotten it to work. > > It should work, assuming your Windows machine is > properly > configured. Are you trying to do client PPTP with > proxy ARP > or LAN to LAN routing? > > Does a tcpdump on ng0 show the packets going out? > > -Archie > > ___________________________________________________________________________ > Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com __________________________________________________ Do You Yahoo!? Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 29 21:48:59 2000 Delivered-To: freebsd-net@freebsd.org Received: from ebola.biohz.net (ebola.biohz.net [206.80.1.35]) by hub.freebsd.org (Postfix) with ESMTP id 9112737B422 for ; Tue, 29 Aug 2000 21:48:56 -0700 (PDT) Received: by ebola.biohz.net (Postfix, from userid 1001) id 297023A457; Tue, 29 Aug 2000 21:48:51 -0700 (PDT) Date: Tue, 29 Aug 2000 21:48:51 -0700 From: Renaud Waldura To: Chris Griffiths Cc: net@freebsd.org Subject: Re: mpd-netgraph and vpn issues Message-ID: <20000829214851.A75349@ebola.biohz.net> Reply-To: Renaud Waldura Mail-Followup-To: Chris Griffiths , net@freebsd.org References: <20000830024002.93525.qmail@web9305.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <20000830024002.93525.qmail@web9305.mail.yahoo.com>; from ctg1701@yahoo.com on Tue, Aug 29, 2000 at 07:40:02PM -0700 X-Web-Site: http://renaud.waldura.com/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org It's working fine and dandy between FreeBSD 4.1 and Windows 2000 clients *using a subnet*. I include my configuration below, I'm still working on it. ### mpd.conf ### # create the bundle "ligos" with link "pptp" new ligos pptp # single link set bundle disable multilink set iface disable on-demand set iface idle 1800 # range of addresses assigned to clients set ipcp ranges 192.168.150.1/32 192.168.150.2/24 # we route that network set iface disable proxy-arp set iface route 192.168.150.0/24 # primary and secondary DNS servers set ipcp dns 192.168.1.1 # primary and secondary WINS servers #set ipcp nbns XXX # do VJ compression set ipcp yes vjcomp # accept compression & encryption? set bundle accept compression set bundle accept encryption #set bundle enable crypt-reqd # accept Microsoft compression and encryption # working? set ccp accept mppc set ccp accept mpp-compress set ccp accept mpp-e40 set ccp accept mpp-e128 #set ccp accept mpp-stateless ### mpd.links ### pptp: set link type pptp # this is a PPTP server only #set pptp mode passive set pptp enable incoming set pptp disable originate # the PPTP interface address set pptp self 207.238.131.190 # CHAP authenticated set link enable chap set link disable pap # protocol compression set link enable acfcomp protocomp set link keep-alive 10 75 set link enable no-orig-auth Once again, the crowd goes wild over FreeBSD's technical excellence, and thanks Archie Cobbs for everything, --Renaud On Tue, Aug 29, 2000 at 07:40:02PM -0700, Chris Griffiths wrote: > I am trying to do client pptp with proxy arp. > > I can ping the client just fine from the server once > connected, but cannot get any info back the other way. > > I will try tcpdump tommrow to see if anything is > coming back up stream but I do not think it is. > > Please let me know if you have any suggestion and/or > have tried this. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 29 21:55:19 2000 Delivered-To: freebsd-net@freebsd.org Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (Postfix) with ESMTP id A8ABB37B422 for ; Tue, 29 Aug 2000 21:55:16 -0700 (PDT) Received: (from smap@localhost) by whistle.com (8.10.0/8.10.0) id e7U4tEo23675; Tue, 29 Aug 2000 21:55:14 -0700 (PDT) Received: from bubba.whistle.com( 207.76.205.7) by whistle.com via smap (V2.0) id xma023672; Tue, 29 Aug 2000 21:55:12 -0700 Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.3) id VAA81933; Tue, 29 Aug 2000 21:55:12 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200008300455.VAA81933@bubba.whistle.com> Subject: Re: mpd-netgraph and vpn issues In-Reply-To: <20000830024002.93525.qmail@web9305.mail.yahoo.com> "from Chris Griffiths at Aug 29, 2000 07:40:02 pm" To: Chris Griffiths Date: Tue, 29 Aug 2000 21:55:12 -0700 (PDT) Cc: net@freebsd.org X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Chris Griffiths writes: > I am trying to do client pptp with proxy arp. > > I can ping the client just fine from the server once > connected, but cannot get any info back the other way. > > I will try tcpdump tommrow to see if anything is > coming back up stream but I do not think it is. > > Please let me know if you have any suggestion and/or > have tried this. It's definitely worked here.. tcpdump should help resolve the problem. Also make sure ipfw is allowing traffic, etc. -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 Wed Aug 30 5: 3:41 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 D8C2837B423; Wed, 30 Aug 2000 05:03:31 -0700 (PDT) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.9.3/1.13) id PAA70532; Wed, 30 Aug 2000 15:03:27 +0300 (EEST) Date: Wed, 30 Aug 2000 15:03:27 +0300 From: Ruslan Ermilov To: committers@FreeBSD.org, net@FreeBSD.org Cc: Garrett Wollman , Bill Fenner , Darren Reed , Kannan Varadhan , Frank Volf Subject: [Call for review] ICMP error generation fixes Message-ID: <20000830150327.C69333@sunbay.com> Mail-Followup-To: committers@FreeBSD.org, net@FreeBSD.org, Garrett Wollman , Bill Fenner , Darren Reed , Kannan Varadhan , Frank Volf References: <20000829192913.A39253@sunbay.com> <200008292032.HAA19847@avalon.reed.wattle.id.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200008292032.HAA19847@avalon.reed.wattle.id.au>; from darrenr@reed.wattle.id.au on Wed, Aug 30, 2000 at 06:32:40AM +1000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi! The patch is ready for your review that addresses almost all issues with broken ICMP error generation and eliminates some other inconsistencies. The bugs are easily discovered by `tcpdump -nvvx' on ICMP error messages generated by a FreeBSD router. They could also be used by nmap-like utilities for remote OS recognition. I have put my patch (264 lines) here: http://people.FreeBSD.org/~ru/icmp-fixes.2 If everything goes OK I intend to commit my patch on Friday, September 1. Here are the details of what has been fixed: 1. icmp_error() now does not add IP header length. This fixes the problem when icmp_error() is called from ip_forward(). In this case the ip_len of part of the original IP datagram returned in ICMP error message was computed incorrectly. 2. icmp_error() expects all three fields, ip_len, ip_id and ip_off in host byte order and converts them to network byte order. This fixes the problem described in PR 16240 and PR 20877, when ip_id field was returned in a host byte order. 3. TTL decrement operation in ip_forward() was moved down to make sure that this change does not corrupt the part of original IP packet passed later to icmp_error(). 4. A copy of a part of original IP packet (mcopy) in ip_forward() was made a real (read-write, independent) copy. This fixes the problem I first reported to Garrett Wollman and Bill Fenner and later in PR 16240, when ip_output() sometimes(!!!) converts the fields of original packet to a network byte order, but because `mcopy' and `m' share the same cluster, this also corrupts the copy `mcopy'. 5. Following the suggestion from Darren Reed, ip_output() now expects all three fields, ip_len, ip_off and ip_id(!) in host byte order. It was a headache for years. The only compatibility issue here I can think of is the raw IP socket case with IP_HDRINCL socket option and ip_id field being non-zero, but ip.4 manual page is unclear on whether in this case ip_id field should be in host byte order or not. I see two alternatives here: either convert ip_id in rip_output() back to a host byte order for backwards compatibility, or add a HISTORY entry to the ip.4 manual describing this change. I personally like the second. 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 Wed Aug 30 10:24:32 2000 Delivered-To: freebsd-net@freebsd.org Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (Postfix) with ESMTP id D479437B424; Wed, 30 Aug 2000 10:24:26 -0700 (PDT) Received: (from smap@localhost) by whistle.com (8.10.0/8.10.0) id e7UHOQF29606; Wed, 30 Aug 2000 10:24:26 -0700 (PDT) Received: from bubba.whistle.com( 207.76.205.7) by whistle.com via smap (V2.0) id xma029604; Wed, 30 Aug 2000 10:24:21 -0700 Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.3) id KAA30942; Wed, 30 Aug 2000 10:24:21 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200008301724.KAA30942@bubba.whistle.com> Subject: Re: [Call for review] ICMP error generation fixes In-Reply-To: <20000830150327.C69333@sunbay.com> "from Ruslan Ermilov at Aug 30, 2000 03:03:27 pm" To: Ruslan Ermilov Date: Wed, 30 Aug 2000 10:24:21 -0700 (PDT) Cc: committers@FreeBSD.org, net@FreeBSD.org, Garrett Wollman , Bill Fenner , Darren Reed , Kannan Varadhan , Frank Volf X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ruslan Ermilov writes: > http://people.FreeBSD.org/~ru/icmp-fixes.2 > > 5. Following the suggestion from Darren Reed, ip_output() now expects all > three fields, ip_len, ip_off and ip_id(!) in host byte order. It was You need to add a NTOHS(ip->ip_id) to div_output() as well. Did you grep for all occurrences of calls to ip_output()? There may be others as well. -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 Wed Aug 30 11:18: 2 2000 Delivered-To: freebsd-net@freebsd.org Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (Postfix) with ESMTP id AA9DB37B424 for ; Wed, 30 Aug 2000 11:17:59 -0700 (PDT) Received: (from smap@localhost) by whistle.com (8.10.0/8.10.0) id e7UIHv000425; Wed, 30 Aug 2000 11:17:57 -0700 (PDT) Received: from bubba.whistle.com( 207.76.205.7) by whistle.com via smap (V2.0) id xma000422; Wed, 30 Aug 2000 11:17:44 -0700 Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.3) id LAA31504; Wed, 30 Aug 2000 11:17:43 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200008301817.LAA31504@bubba.whistle.com> Subject: Re: Problem in calling ip_input() In-Reply-To: <20000829125041.8226.qmail@web3006.mail.yahoo.com> "from deepika kakrania at Aug 29, 2000 05:50:41 am" To: deepika kakrania Date: Wed, 30 Aug 2000 11:17:43 -0700 (PDT) Cc: freebsd-net@FreeBSD.ORG, freebsd-hackers@freeBSD.O X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org deepika kakrania writes: > I have changed if_ethersubr.c slightly to support a > new protocol. In ehter_output, an additional header is > added for this protocol between ethernet herader and > IP header. > > ethernet header|New protocol header| IP header| > Transport layer header > > In ether_input(), after doing neccesary checks for > this protocol,the packet is assigned to ipintrq for > normal ip processing in following manner. > > schednetisr(NETISR_IP) > inq = &ipintrq; > > Now for testing when i send some ping packets with > this additional new header to a host(which supports > this new protocol), i find that i get reply only for > first packet after rebooting. For rest packets , > ip_input is not being called even after packets are > enqued in ipintrq. > > Could anyone explain to me what can be the problem > here? Perhaps you called splimp() somewhere in your code and forgot to call splx() (or something like that)? -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 Wed Aug 30 11:35: 8 2000 Delivered-To: freebsd-net@freebsd.org Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (Postfix) with ESMTP id B887B37B424 for ; Wed, 30 Aug 2000 11:34:57 -0700 (PDT) Received: (from smap@localhost) by whistle.com (8.10.0/8.10.0) id e7UIY4X00735; Wed, 30 Aug 2000 11:34:04 -0700 (PDT) Received: from bubba.whistle.com( 207.76.205.7) by whistle.com via smap (V2.0) id xma000733; Wed, 30 Aug 2000 11:33:50 -0700 Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.3) id LAA31594; Wed, 30 Aug 2000 11:33:49 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200008301833.LAA31594@bubba.whistle.com> Subject: Re: Proposal to clarify mbuf handling rules In-Reply-To: "from Bosko Milekic at Aug 29, 2000 08:39:35 pm" To: Bosko Milekic Date: Wed, 30 Aug 2000 11:33:49 -0700 (PDT) Cc: David Malone , freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Bosko Milekic writes: > > > (a) The mbuf data should not be written to under any circumstances. > > > even if it is a cluster mbuf and the reference count becomes 1. > > > > > (b) The mbuf data may be written to. This implies that if this mbuf > > > is a cluster, then the reference count is 1. > > > > > (c) The mbuf data may not be written to, BUT if it is a cluster mbuf > > > and the reference count decreases to 1, then it may then be > > > written to. > > All of these different possibilities add quite a bit of hysteria for > just figuring out which of the above a given mbuf falls under from within > the mbuf subsystem alone. > I think that it's rather clear that if we do intend to implement some > sort of permissions structure with respect to external buffers that we > need to have the mbufs referring to these ext_bufs share a unique > permissions field. > The solution: Change mext_refcnt union to be a mext_descr union with > an additional field falling within like so: > > union mext_descr { > union mext_descr *next_desc; > struct { > u_long refcnt; > u_int perms; > } desc; > }; > > The cost: Additional 4 bytes per every M_EXT mbuf. (These unions are > typically allocated en-masse from mb_map during bootup and more are added > from mb_map on demand, assuming we have the space in mb_map, otherwise, > ... we'll probably have to implement another tsleep mechanism). > > perms is to be modified atomically and can contain, for now: > > M_RDWR 0x00000000 > M_RDONLY 0x00000001 > [... more to come ...?] > > (Notice that the mext_descr _only_ contains SMP-safe atomically > modifiable and shareable settings for the ext_buf -- this is like shared > space for M_EXT mbufs referring to the same ext_buf -- the SMP-friendly > version of the doubly-linked list solution). > > This solution would allow on-the-fly modification of ext_bufs > permissions. > > If this works for you guys, and if you think it's worth it, then we > should also add an ext_flags in the m_ext structure while we're add it, > because it will cost us nothing (m_ext is within a union containing ample > amount of scratch space in an M_EXT mbuf) and because it will allow me to > remove the code that assumes that if ext_free is NULL, that we're dealing > with an mcluster (which is true for now); but the new check of the flag > would make the code a little faster at 0 extra overhead. The idea would > be to have that ext_flags contain one of M_CLUSTER, M_WHATEVER, M_OTHER. It makes sense to put the info about the shared mbuf data into the (single) union mext_descr that all the mbuf's point to. But why not put ext_flags in there as well? Also, why are "perms" and "refcnt" in the same union? It seems like you will lose the "perms" information when you increase refcnt to 2, leading to the same problem mentioned before (a shared mbuf data region going from 2 -> 1 reference does not become writable again). What is "next_desc" used for? How does that affect this? -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 Wed Aug 30 11:53: 5 2000 Delivered-To: freebsd-net@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 84B0837B43E for ; Wed, 30 Aug 2000 11:53:02 -0700 (PDT) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 30 Aug 2000 19:53:01 +0100 (BST) To: Bosko Milekic Cc: David Malone , freebsd-net@FreeBSD.ORG Subject: Re: Proposal to clarify mbuf handling rules In-reply-to: Your message of "Tue, 29 Aug 2000 20:39:35 EDT." X-Request-Do: Date: Wed, 30 Aug 2000 19:53:00 +0100 From: David Malone Message-ID: <200008301953.aa98962@salmon.maths.tcd.ie> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > If we decide to go with the above proposal, there can be one macro to > set perms, and it can be of course used to remove a bit as well. There > can also be two "wrapper" macros that will essentially either call the > reference count increment macro and set RDONLY if it becomes > 1 or call > the reference count decrement macro and unset RDONLY if it becomes > exactly 1. The wrapper macros are only to be called for those wishing > this specific behavior. We can have a number of such macros, if we judge > them to be useful, based on the different possibilities that you listed > at the beginning of this Email. Personally, I'd go for the simplest option, to just add a M_RDONLY flag to the m_flags and use the three condition check for writability. (That way we can even make normal mbuf read only if we want to - not that that is necessarily an advantage ;-) I guess we could impliment it either way and use macros so it is easy to change later. David. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 30 12:29: 1 2000 Delivered-To: freebsd-net@freebsd.org Received: from web1601.mail.yahoo.com (web1601.mail.yahoo.com [128.11.23.201]) by hub.freebsd.org (Postfix) with SMTP id 03C7637B422 for ; Wed, 30 Aug 2000 12:28:58 -0700 (PDT) Received: (qmail 11974 invoked by uid 60001); 30 Aug 2000 19:28:57 -0000 Message-ID: <20000830192857.11973.qmail@web1601.mail.yahoo.com> Received: from [128.42.12.162] by web1601.mail.yahoo.com; Wed, 30 Aug 2000 12:28:57 PDT Date: Wed, 30 Aug 2000 12:28:57 -0700 (PDT) From: Ping Yuan Subject: Buffer. 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, I am now using a netcard with 4 interfaces, which means that I can have 4 network connections. My question here is that how OS allocates buffer for these 4 connections. Do they share the same buffer space? If so, other connections will be affected when one connection is busy, right? Or, may OS allocate buffer space for each connection seperately? Then, they can not affect each other. Who can help me out of this? Thanks for your help in advance, Ping __________________________________________________ Do You Yahoo!? Yahoo! Mail - Free email you can access from anywhere! http://mail.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 30 13:42:25 2000 Delivered-To: freebsd-net@freebsd.org Received: from clickarray.com (adsl-63-197-76-246.dsl.snfc21.pacbell.net [63.197.76.246]) by hub.freebsd.org (Postfix) with ESMTP id 9FE5637B42C for ; Wed, 30 Aug 2000 13:42:18 -0700 (PDT) Received: from clickarray.com (eagles.clickarray.com [10.2.17.1]) by clickarray.com (8.9.3/8.9.3) with ESMTP id QAA25100 for ; Sat, 26 Aug 2000 16:02:29 -0700 (PDT) (envelope-from smh@clickarray.com) Message-ID: <39A84CE6.D3F0454B@clickarray.com> Date: Sat, 26 Aug 2000 16:04:06 -0700 From: Stephen Head X-Mailer: Mozilla 4.72 [en] (X11; I; FreeBSD 4.0-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@FreeBSD.ORG Subject: public vrrpd src for FreeBSD? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, anyone know of a public source code version for VRRP that is a full implementation (I'm already aware of the vrrpd 0.2 for linux). Thanks, Steve (smh@clickarray.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 30 14:11:17 2000 Delivered-To: freebsd-net@freebsd.org Received: from field.videotron.net (field.videotron.net [205.151.222.108]) by hub.freebsd.org (Postfix) with ESMTP id C15AD37B424 for ; Wed, 30 Aug 2000 14:11:10 -0700 (PDT) Received: from modemcable136.203-201-24.mtl.mc.videotron.net ([24.201.203.136]) by field.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0G04003AUIEYL7@field.videotron.net> for freebsd-net@FreeBSD.ORG; Wed, 30 Aug 2000 17:01:47 -0400 (EDT) Date: Wed, 30 Aug 2000 17:05:05 -0400 (EDT) From: Bosko Milekic Subject: Re: Proposal to clarify mbuf handling rules In-reply-to: <200008301833.LAA31594@bubba.whistle.com> X-Sender: bmilekic@jehovah.technokratis.com To: Archie Cobbs Cc: freebsd-net@FreeBSD.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 Wed, 30 Aug 2000, Archie Cobbs wrote: > It makes sense to put the info about the shared mbuf data into the > (single) union mext_descr that all the mbuf's point to. But why > not put ext_flags in there as well? Simply because we don't need it shared. And since we don't need it shared, then we don't need to waste another 4 bytes per M_EXT mbuf for it. > Also, why are "perms" and "refcnt" in the same union? It seems like > you will lose the "perms" information when you increase refcnt to 2, > leading to the same problem mentioned before (a shared mbuf data > region going from 2 -> 1 reference does not become writable again). Uhm, no. They are _not_ in the same union. They are in the same structure, which is a member of a union containing both that structure and a next_desc pointer for the union free list. Read the code right now in -CURRENT, look for mext_refcnt union format. > What is "next_desc" used for? How does that affect this? For the free list, used solely by the mext_refcnt (to be mext_descr) allocator. > -Archie > > ___________________________________________________________________________ > Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com Regards, Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 30 14:52:51 2000 Delivered-To: freebsd-net@freebsd.org Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (Postfix) with ESMTP id AF7B337B424 for ; Wed, 30 Aug 2000 14:52:48 -0700 (PDT) Received: (from smap@localhost) by whistle.com (8.10.0/8.10.0) id e7ULqC602861; Wed, 30 Aug 2000 14:52:12 -0700 (PDT) Received: from bubba.whistle.com( 207.76.205.7) by whistle.com via smap (V2.0) id xma002859; Wed, 30 Aug 2000 14:51:57 -0700 Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.3) id OAA33212; Wed, 30 Aug 2000 14:51:57 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200008302151.OAA33212@bubba.whistle.com> Subject: Re: Proposal to clarify mbuf handling rules In-Reply-To: "from Bosko Milekic at Aug 30, 2000 05:05:05 pm" To: Bosko Milekic Date: Wed, 30 Aug 2000 14:51:57 -0700 (PDT) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Bosko Milekic writes: > > It makes sense to put the info about the shared mbuf data into the > > (single) union mext_descr that all the mbuf's point to. But why > > not put ext_flags in there as well? > > Simply because we don't need it shared. And since we don't need it > shared, then we don't need to waste another 4 bytes per M_EXT mbuf for > it. > > > Also, why are "perms" and "refcnt" in the same union? It seems like > > you will lose the "perms" information when you increase refcnt to 2, > > leading to the same problem mentioned before (a shared mbuf data > > region going from 2 -> 1 reference does not become writable again). > > Uhm, no. They are _not_ in the same union. They are in the same > structure, which is a member of a union containing both that structure > and a next_desc pointer for the union free list. Read the code right now > in -CURRENT, look for mext_refcnt union format. OK, that makes more sense... I misread it before. > > What is "next_desc" used for? How does that affect this? > > For the free list, used solely by the mext_refcnt (to be mext_descr) > allocator. OK.. so, no effect. So.. this all sounds good to me now. -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 Wed Aug 30 15: 4:51 2000 Delivered-To: freebsd-net@freebsd.org Received: from hq.ezo.net (hq.ezo.net [206.150.211.190]) by hub.freebsd.org (Postfix) with ESMTP id BE54637B43C; Wed, 30 Aug 2000 15:04:44 -0700 (PDT) Received: from zinnia (zinnia.ezo.net [206.150.211.129]) by hq.ezo.net (8.9.3/8.9.3) with SMTP id SAA05016; Wed, 30 Aug 2000 18:08:05 -0400 (EDT) (envelope-from jflowers@ezo.net) Message-ID: <002101c012cd$0b4a53b0$81d396ce@ezo.net> From: "Jim Flowers" To: "Atsushi Onoe" Cc: , References: <39A9E49D.A79BF6FD@softweyr.com> <200008280703.e7S732S01248@duplo.sm.sony.co.jp> Subject: Re: fbsd box acting as a wavelan BS (Yes it can) Date: Wed, 30 Aug 2000 17:55:42 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The 6.04 firmware does, indeed, allow establishing a network with an ISA card in a FreeBSD box, however, when doing the PCCard upgrade with a Windows machine it requires the drivers to be upgraded to 4.01 first and if you want to talk to it with the IEEE/Wave Manager Client update it, as well. Everything seems to be backward compatible (ad-hoc, Infrastructure, WaveManageer/Client, Manager. The good news is that it works farily well and will setup a network netname, with the procedure you indicated. You can also move away from the default frequency in either direction and the remote stations will follow it so the beacons must work. Works with multiple clients (simultaneously) but the cache (-C) only reports levels on a single remote. Haven't tried multiple throughput tests yet. Statistics (-o) don't show any values but these are on 4.1-STABLE #0 and maybe that is the same problem reported by Theo Pagtzis. The bad news is that the unit is not really running as an infrastructure network and is reported by the WaveManager Client as a "public ad-hoc workgroup" with the specified netname. I don't mind so much that the site monitor doesn't work (the link tests do work) but it's really a downer that, being identified as an ad-hoc network type, the max transmit rate is locked at 2 Mbps which limits TCP throughput to about 1.2 - 1.5 Mbps in both directions with turbo bronze cards. Sure would be great if someone could find a way around that but I don't hold out much hope for a simple driver modification after reading Bill Paul's driver comments. Looks like Lucent is intent on restricting the third-party functionality to avoid eating their children. Still, it can make a nice distribution point sitting out at the end of a single T-1 and we've got lots of 2 Mb cards. After looking through the Lucent driver for Linux, I see that they don't even have that much. ----- Original Message ----- From: "Atsushi Onoe" To: Cc: ; ; ; ; Sent: Monday, August 28, 2000 3:03 AM Subject: Re: fbsd box acting as a wavelan BS > > > Last I checked the wi driver will not do IBSS and says so in the > > > documentation. I also tried it and couldn't get anywhere. Would be nice. > > > > Uh, er, if you mean to create a service set, Lucent apparently hasn't seen > > fit to release that sort of information about the cards yet. I can probably > > get access to it, but it would be under NDA and therefore not useful. Your > > best bet is to bug your friendly neighborhood Lucent rep into releaseing > > the full documentation (and sample source code) to Bill Paul. > > Lucent have shipped newer firmware this March which DOES support creating > IBSS. The verision 6.04 of the firmware creates IBSS by setting wicontrol > -c 1 with -p 1 (BSS mode), and joins to IBSS if no access points found. > It seems that the name of created IBSS follows "network name" specified by > -n option, not "SSID" by -q option. > > Regards, > > Atsushi Onoe > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 30 15:15: 3 2000 Delivered-To: freebsd-net@freebsd.org Received: from falla.videotron.net (falla.videotron.net [205.151.222.106]) by hub.freebsd.org (Postfix) with ESMTP id 3105337B423 for ; Wed, 30 Aug 2000 15:14:56 -0700 (PDT) Received: from modemcable136.203-201-24.mtl.mc.videotron.net ([24.201.203.136]) by falla.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0G04006REK887N@falla.videotron.net> for freebsd-net@FreeBSD.ORG; Wed, 30 Aug 2000 17:40:57 -0400 (EDT) Date: Wed, 30 Aug 2000 17:44:15 -0400 (EDT) From: Bosko Milekic Subject: Re: Proposal to clarify mbuf handling rules In-reply-to: <200008301953.aa98962@salmon.maths.tcd.ie> X-Sender: bmilekic@jehovah.technokratis.com To: David Malone Cc: freebsd-net@FreeBSD.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 Wed, 30 Aug 2000, David Malone wrote: > Personally, I'd go for the simplest option, to just add a M_RDONLY > flag to the m_flags and use the three condition check for writability. > (That way we can even make normal mbuf read only if we want to - > not that that is necessarily an advantage ;-) > > I guess we could impliment it either way and use macros so it is easy > to change later. > > David. But how would you take care of removing a M_RDONLY flag for an mbuf referring to certain external storage where that one mbuf is not the only mbuf referring to it? i.e. you would have to remove M_RDONLY from all the mbufs referring to the same ext_buf, and this is impossible (and undesired, actually, as it would involve big overhead as a result of giant locks). Or, if that doesn't matter, because you'll be using the three condition check for safe-writability testing, then why do we need the M_RDONLY flag in the first place? Cheers, Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 30 17:59:53 2000 Delivered-To: freebsd-net@freebsd.org Received: from w250.z064001178.sjc-ca.dsl.cnc.net (w250.z064001178.sjc-ca.dsl.cnc.net [64.1.178.250]) by hub.freebsd.org (Postfix) with SMTP id AFC1037B423 for ; Wed, 30 Aug 2000 17:59:50 -0700 (PDT) Received: (qmail 55350 invoked by uid 1000); 30 Aug 2000 06:12:58 -0000 Date: Tue, 29 Aug 2000 23:12:58 -0700 From: Jos Backus To: net@freebsd.org Subject: mpd PPTP question Message-ID: <20000829231258.A55314@lizzy.bugworks.com> Reply-To: Jos Backus Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [My apologies if this is deemed -question material...] Has anybody succeeded in using mpd to connect to an NT server using PPTP? I'm trying to get this to work but I'm not having much luck. Two things in particular I'm seeing: Aug 29 22:54:03 lizzy mpd: [work] LCP: state change Opened --> Req-Sent Aug 29 22:54:03 lizzy mpd: [work] LCP: phase shift AUTHENTICATE --> ESTABLISH Aug 29 22:54:03 lizzy mpd: pptp0: CID 0x5f9c in SetLinkInfo not found <-- ? Aug 29 22:54:03 lizzy mpd: [work] LCP: rec'd Configure Reject #2 link 0 (Req-Sent) and the other thing is that the session never makes it beyond LCP, for reasons I'm unable to determine based on the log :-/ My config: # mpd.links work: set link type pptp set pptp self set pptp peer set pptp enable originate outcall # mpd.conf work: new ms-pptp work set iface disable on-demand set iface addrs 10.0.0.1 10.0.1.1 set iface idle 300 set iface route set iface route set bundle disable multilink set bundle authname "user" set bundle password "pass" set link yes acfcomp protocomp set link no pap set link yes chap # If remote machine is NT you need this.. # set link enable no-orig-auth set link keep-alive 10 75 set ipcp yes vjcomp set ipcp ranges 0.0.0.0/0 1.2.3.4/0 # If you wanted MPPE encryption and had ng_mppc(8)... set bundle enable compression set ccp yes mppc set ccp yes mpp-e40 set ccp yes mpp-e128 set bundle enable crypt-reqd set ccp yes mpp-stateless open This is with a day old -current, and the latest mpd port. Thanks, -- Jos Backus _/ _/_/_/ "Modularity is not a hack." _/ _/ _/ -- D. J. Bernstein _/ _/_/_/ _/ _/ _/ _/ jbackus@plex.nl _/_/ _/_/_/ use Std::Disclaimer; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 30 23: 9:41 2000 Delivered-To: freebsd-net@freebsd.org Received: from fork.computel.sk (fork.computel.sk [195.28.96.96]) by hub.freebsd.org (Postfix) with ESMTP id 6753D37B440 for ; Wed, 30 Aug 2000 23:09:36 -0700 (PDT) Received: from tempest.sk (t74.tempest.sk [195.28.100.74]) by fork.computel.sk with ESMTP id IAA03865; Thu, 31 Aug 2000 08:08:56 +0200 Message-ID: <39ADF671.42CDC92A@tempest.sk> Date: Thu, 31 Aug 2000 08:08:49 +0200 From: Pavol Adamec Organization: Tempest X-Mailer: Mozilla 4.72 [en] (X11; I; FreeBSD 4.0-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Head , freebsd-net@freebsd.org Subject: Re: public vrrpd src for FreeBSD? References: <39A84CE6.D3F0454B@clickarray.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I was also looking for vrrp implementation for FreeBSD. Nothing found. Neither VRRP nor HSRP. As for the Linux vrrpd code - it wouldn't be so difficult to port it to FreeBSD with the exception of SIOCSIFHWADDR - set MAC address for NIC. AFAIK this feature is not present in FreeBSD - but it's not so difficult to implement it. Some time ago there was a thread on -net (I hope) about SIOCSIFHWADDR. paul Stephen Head wrote: > > Hi, anyone know of a public source code version for VRRP > that is a full implementation (I'm already aware of > the vrrpd 0.2 for linux). Thanks, > > Steve (smh@clickarray.com) > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 31 0:19:49 2000 Delivered-To: freebsd-net@freebsd.org Received: from hand.dotat.at (sfo-gw.covalent.net [207.44.198.62]) by hub.freebsd.org (Postfix) with ESMTP id 3C0F937B43E for ; Thu, 31 Aug 2000 00:19:48 -0700 (PDT) Received: from fanf by hand.dotat.at with local (Exim 3.15 #3) id 13UOcp-0007U1-00; Thu, 31 Aug 2000 07:19:03 +0000 Date: Thu, 31 Aug 2000 07:19:02 +0000 From: Tony Finch To: Pavol Adamec Cc: Stephen Head , freebsd-net@freebsd.org Subject: Re: public vrrpd src for FreeBSD? Message-ID: <20000831071902.G25064@hand.dotat.at> References: <39A84CE6.D3F0454B@clickarray.com> <39ADF671.42CDC92A@tempest.sk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <39ADF671.42CDC92A@tempest.sk> Organization: Covalent Technologies, Inc Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Pavol Adamec wrote: > >I was also looking for vrrp implementation for FreeBSD. >Nothing found. Neither VRRP nor HSRP. As for the Linux >vrrpd code - it wouldn't be so difficult to port it to >FreeBSD with the exception of SIOCSIFHWADDR - set MAC >address for NIC. AFAIK this feature is not present >in FreeBSD - but it's not so difficult to implement it. It was added recently with the name SIOCSIFLLADDR. Tony. -- en oeccget g mtcaa f.a.n.finch v spdlkishrhtewe y dot@dotat.at eatp o v eiti i d. fanf@covalent.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 31 0:37: 8 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 237CA37B43F; Thu, 31 Aug 2000 00:36:51 -0700 (PDT) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.9.3/1.13) id KAA04457; Thu, 31 Aug 2000 10:36:28 +0300 (EEST) Date: Thu, 31 Aug 2000 10:36:28 +0300 From: Ruslan Ermilov To: Archie Cobbs Cc: committers@FreeBSD.org, net@FreeBSD.org, Garrett Wollman , Bill Fenner , Darren Reed , Kannan Varadhan , Frank Volf Subject: Re: [Call for review] ICMP error generation fixes Message-ID: <20000831103628.A4165@sunbay.com> Mail-Followup-To: Archie Cobbs , committers@FreeBSD.org, net@FreeBSD.org, Garrett Wollman , Bill Fenner , Darren Reed , Kannan Varadhan , Frank Volf References: <20000830150327.C69333@sunbay.com> <200008301724.KAA30942@bubba.whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200008301724.KAA30942@bubba.whistle.com>; from archie@whistle.com on Wed, Aug 30, 2000 at 10:24:21AM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Aug 30, 2000 at 10:24:21AM -0700, Archie Cobbs wrote: > Ruslan Ermilov writes: > > http://people.FreeBSD.org/~ru/icmp-fixes.2 > > > > 5. Following the suggestion from Darren Reed, ip_output() now expects all > > three fields, ip_len, ip_off and ip_id(!) in host byte order. It was > > You need to add a NTOHS(ip->ip_id) to div_output() as well. > Yesterday when I was going to go home I found this bug myself, i.e. outgoing packets after being diverted were sent with wrong ip_id, and later, being already at home, I figured I forgot to modify div_output(). > Did you grep for all occurrences of calls to ip_output()? > There may be others as well. > Will give it a more close look... Thanks for review, Archie! -- 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 Thu Aug 31 0:45:26 2000 Delivered-To: freebsd-net@freebsd.org Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by hub.freebsd.org (Postfix) with SMTP id EBE9037B422; Thu, 31 Aug 2000 00:45:23 -0700 (PDT) Received: from ginger.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 31 Aug 2000 08:45:20 +0100 Message-ID: <39AE0D0D.804963FD@cs.ucl.ac.uk> Date: Thu, 31 Aug 2000 08:45:17 +0100 From: Theo PAGTZIS Reply-To: t.pagtzis@cs.ucl.ac.uk Organization: UCL X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: el, en MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: ls -l | more inverts colour Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi All, for some strange reason an ls -l | more inverts the colour on an xterm. If I vi a file then colour comes back to normal (I gather vi resets xterm) Is that known? Theo To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 31 0:57:15 2000 Delivered-To: freebsd-net@freebsd.org Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by hub.freebsd.org (Postfix) with SMTP id D6A5337B423; Thu, 31 Aug 2000 00:57:02 -0700 (PDT) Received: from ginger.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 31 Aug 2000 08:56:49 +0100 Message-ID: <39AE0FBE.6CD145C4@cs.ucl.ac.uk> Date: Thu, 31 Aug 2000 08:56:46 +0100 From: Theo PAGTZIS Reply-To: t.pagtzis@cs.ucl.ac.uk Organization: UCL X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: el, en MIME-Version: 1.0 To: Jim Flowers Cc: Atsushi Onoe , freebsd-hackers , freebsd-net , freebsd-mobile@FreeBSD.ORG Subject: Re: fbsd box acting as a wavelan BS (Yes it can) References: <39A9E49D.A79BF6FD@softweyr.com> <200008280703.e7S732S01248@duplo.sm.sony.co.jp> <002101c012cd$0b4a53b0$81d396ce@ezo.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Jim, Jim Flowers wrote: > The 6.04 firmware does, indeed, allow establishing a network with an ISA > card in a FreeBSD box, however, when doing the PCCard upgrade with a Windows > machine it requires the drivers to be upgraded to 4.01 first and if you want > to talk to it with the IEEE/Wave Manager Client update it, as well. > Everything seems to be backward compatible (ad-hoc, Infrastructure, > WaveManageer/Client, Manager. > > The good news is that it works farily well and will setup a network netname, > with the procedure you indicated. You can also move away from the default > frequency in either direction and the remote stations will follow it so the > beacons must work. Works with multiple clients (simultaneously) but the > cache (-C) only reports levels on a single remote. Haven't tried multiple > throughput tests yet. Statistics (-o) don't show any values but these are > on 4.1-STABLE #0 and maybe that is the same problem reported by Theo > Pagtzis. > thanks for checking it out. I tried to print a single statistic from the wavelan card after experiencing the 0ed wi_counters from within the kernel (device_print)... for some reason once I did that the machine...rebooted...(not beneignly :) Could someone point me on info about kernel debugging? Do I get the impression that there is something wrong with the interrupt assigned to the card. Jim mentioned that it is probably best to have the interrupt assigned to the card isolated (at least that was my impression from what Jim mentioned as grandfathering) Also in some of the new fbsd boxes (4.1 stable + KAME snap) we have here the wavelan card although detected when inserted (which is a pccardd function) it keeps giving a "no such card in database". The card is in the database of pccard.conf, I use interrupt 9 which is not in use by another device. Can anyone understand the dumpcis info from the pccardc request? I dunno if that helps in understanding the problem as I cannot understand what it means..(at least a good part of it..) Any hints? Theo To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 31 1:54:59 2000 Delivered-To: freebsd-net@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id BFFE337B449 for ; Thu, 31 Aug 2000 01:54:56 -0700 (PDT) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 31 Aug 2000 09:54:55 +0100 (BST) To: Bosko Milekic Cc: David Malone , freebsd-net@FreeBSD.ORG Subject: Re: Proposal to clarify mbuf handling rules In-reply-to: Your message of "Wed, 30 Aug 2000 17:44:15 EDT." X-Request-Do: Date: Thu, 31 Aug 2000 09:54:53 +0100 From: David Malone Message-ID: <200008310954.aa57200@salmon.maths.tcd.ie> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > But how would you take care of removing a M_RDONLY flag for an mbuf > referring to certain external storage where that one mbuf is not the only > mbuf referring to it? At the time external storage is first attached to a mbuf you can set M_RDONLY if it must never be written to (eg. sendfile bufs or parts of the NFS zero copy stuff might want to do similar). If the M_RDONLY flag is set you must not write to the buffer, otherwise you can write to the buffer if it's a simple mbuf or if the reference count on the external storage is 1. (Atleast, this is the system I had in mind). David. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 31 2:34:12 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 080E337B422; Thu, 31 Aug 2000 02:33:59 -0700 (PDT) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.9.3/1.13) id MAA10384; Thu, 31 Aug 2000 12:33:34 +0300 (EEST) Date: Thu, 31 Aug 2000 12:33:33 +0300 From: Ruslan Ermilov To: Archie Cobbs Cc: committers@FreeBSD.org, net@FreeBSD.org, Garrett Wollman , Bill Fenner , Darren Reed , Kannan Varadhan , Frank Volf Subject: Re: [Call for review] ICMP error generation fixes Message-ID: <20000831123333.A9980@sunbay.com> Mail-Followup-To: Archie Cobbs , committers@FreeBSD.org, net@FreeBSD.org, Garrett Wollman , Bill Fenner , Darren Reed , Kannan Varadhan , Frank Volf References: <20000830150327.C69333@sunbay.com> <200008301724.KAA30942@bubba.whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200008301724.KAA30942@bubba.whistle.com>; from archie@whistle.com on Wed, Aug 30, 2000 at 10:24:21AM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Aug 30, 2000 at 10:24:21AM -0700, Archie Cobbs wrote: > Ruslan Ermilov writes: > > http://people.FreeBSD.org/~ru/icmp-fixes.2 > > > > 5. Following the suggestion from Darren Reed, ip_output() now expects all > > three fields, ip_len, ip_off and ip_id(!) in host byte order. It was > > You need to add a NTOHS(ip->ip_id) to div_output() as well. > An updated patch could be found here: http://people.FreeBSD.org/~ru/icmp-fixes.3 MD5 (icmp-fixes.3) = 76e8cfae742bbaa225136c70dff05500 It fixes the problem Archie and I noticed (diverted outgoing packets had wrong ip_id) with previous version of the patch. The problem was caused by the changing ip_output() so that it now expects ip_id in host byte order as well, and somehow I forgot to update div_output(). > Did you grep for all occurrences of calls to ip_output()? > There may be others as well. > I tried really hard and found nothing. -- 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 Thu Aug 31 4:19:25 2000 Delivered-To: freebsd-net@freebsd.org Received: from genius.systems.pavilion.net (genius.systems.pavilion.net [212.74.1.100]) by hub.freebsd.org (Postfix) with ESMTP id E9ECE37B440; Thu, 31 Aug 2000 04:19:17 -0700 (PDT) Received: by genius.systems.pavilion.net (Postfix, from userid 100) id 0088A9B3F; Thu, 31 Aug 2000 12:19:16 +0100 (BST) Date: Thu, 31 Aug 2000 12:19:16 +0100 From: Josef Karthauser To: Theo PAGTZIS Cc: freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: ls -l | more inverts colour Message-ID: <20000831121916.D50038@pavilion.net> Mail-Followup-To: Josef Karthauser , Theo PAGTZIS , freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG References: <39AE0D0D.804963FD@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <39AE0D0D.804963FD@cs.ucl.ac.uk>; from T.Pagtzis@cs.ucl.ac.uk on Thu, Aug 31, 2000 at 08:45:17AM +0100 X-NCC-RegID: uk.pavilion Organisation: Pavilion Internet plc, Lees House, 21-23 Dyke Road, Brighton, England Phone: +44-845-333-5000 Fax: +44-845-333-5001 Mobile: +44-403-596893 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Aug 31, 2000 at 08:45:17AM +0100, Theo PAGTZIS wrote: > Hi All, > > for some strange reason an ls -l | more inverts the colour on an > xterm. If I vi a file then colour comes back to normal (I gather vi > resets xterm) > > Is that known? What versions are you running? Please send the results of running: # uname -a # ls -l /bin/ls # env Joe -- Josef Karthauser FreeBSD: How many times have you booted today? Technical Manager Viagra for your server (http://www.uk.freebsd.org) Pavilion Internet plc. [joe@pavilion.net, joe@uk.freebsd.org, joe@tao.org.uk] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 31 5:15:21 2000 Delivered-To: freebsd-net@freebsd.org Received: from worldclass.jolt.nu (lgh2901b.hn-krukan.AC [212.217.139.149]) by hub.freebsd.org (Postfix) with ESMTP id 81B8437B43C for ; Thu, 31 Aug 2000 05:14:58 -0700 (PDT) Received: from localhost (c4@localhost) by worldclass.jolt.nu (8.9.3/8.9.3) with ESMTP id OAA57349 for ; Thu, 31 Aug 2000 14:14:36 GMT (envelope-from c4@worldclass.jolt.nu) Date: Thu, 31 Aug 2000 14:14:35 +0000 (GMT) From: Tobias Fredriksson X-Sender: c4@worldclass To: freebsd-net@freebsd.org Subject: vr0 timeouts (applies to ALL? miibus cards) 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 in 4.0 there is a problem with the miibus driver and i think this applies to all cards that use this driver(that is all 100mbit non intel/3com as it appears to me) vr(D-Link among others) rl(RealTek) etc... in 3.4-RELEASE + 3.5.1-RELEASE i havn't had a single problem with the vr driver, not a timeout nothing speeds are usually 50-60mbit/s when uploading to the computer and 80-90mbit/s when downloading from it. does anybody know if there is an fix/patch/workaround etc for 4.0/4.1-STABLE? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 31 8: 4:44 2000 Delivered-To: freebsd-net@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 0E70B37B440 for ; Thu, 31 Aug 2000 08:04:40 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 13TXJ8-0000IU-00; Mon, 28 Aug 2000 16:23:10 -0600 Message-ID: <39AAE64E.96584FB8@softweyr.com> Date: Mon, 28 Aug 2000 16:23:10 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 4.1-RC i386) X-Accept-Language: en MIME-Version: 1.0 To: Brian Reichert Cc: Bill Fumerola , freebsd-net@freebsd.org Subject: Re: Macronix NIC not up to snuff? References: <20000828165847.A9262@numachi.com> <20000828170838.J33771@jade.chc-chimes.com> <20000828173009.G8519@numachi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Brian Reichert wrote: > > On Mon, Aug 28, 2000 at 05:08:38PM -0400, Bill Fumerola wrote: > > On Mon, Aug 28, 2000 at 04:58:47PM -0400, Brian Reichert wrote: > > > > > > Both of these boxes work fine with our FlowPoint DSL router, a > > > cheesy 3Com 10bT hub, and an even cheesier Ark Technologies > > > autosensing switch. > > > > > > I'm installing a Cisco Catalyst 2924 XL running IOS Version > > > 11.2(8)SA3. > > > > Crisco ethernet switches are notorious for screwing up autodetect. > > That may very well be, but only these cards are suffering. So the seesko blows autodetection only on these cards? Trust me, that's not at all rare. > > Force them with media or mediaopt, and force the duplex and speed > > on the cisco and see if that helps. > > This might be a useful workaraound (which I'll try later), but it > doesn't clear my worries that it's the NIC+OS combination that's > wonky... No, it's the combination of the PHY on the switch vs. the PHY on the NIC. What he gave you isn't a workaround, it's a solution to an endemic problem: autodetection often doesn't work. If it doesn't work, no amount of wanting it to work is going to fix the problem, so go fix the problem. -- "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 31 10:31:24 2000 Delivered-To: freebsd-net@freebsd.org Received: from guard.polynet.lviv.ua (Guard.PolyNet.Lviv.UA [209.58.62.194]) by hub.freebsd.org (Postfix) with SMTP id 2938937B423 for ; Thu, 31 Aug 2000 10:31:05 -0700 (PDT) Received: (qmail 6377 invoked from network); 31 Aug 2000 17:31:01 -0000 Received: from unknown (HELO postoffice.polynet.lviv.ua) (unknown) by unknown with SMTP; 31 Aug 2000 17:31:01 -0000 Received: (qmail 61319 invoked from network); 31 Aug 2000 17:31:00 -0000 Received: (ofmipd unknown); 31 Aug 2000 17:30:38 -0000 Date: 31 Aug 2000 20:30:57 +0300 Message-ID: <8630326.20000831203057@polynet.lviv.ua> From: "Andriy Korud" Reply-To: "Andriy Korud" To: freebsd-net@freebsd.org X-Mailer: The Bat! (v1.44) X-Priority: 3 (Normal) Subject: ALTQ integration? 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 Hello all, Is ALTQ integrated into FreeBSD4-STABLE? If no, is there exist some branch? If no, will ALTQ 2.2 apply to 4-STABLE or 4.1-RELEASE? Will there be any difference between KAME source tree and integrated ALTQ? And last: If I need production router with ALTQ on dc and sppp interfaces on the next week, which is the best solution? -- Best regards, Andriy mailto:akorud@polynet.lviv.ua To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 31 13:16: 7 2000 Delivered-To: freebsd-net@freebsd.org Received: from moutvdom00.kundenserver.de (moutvdom00.kundenserver.de [195.20.224.149]) by hub.freebsd.org (Postfix) with ESMTP id D5DC537B424 for ; Thu, 31 Aug 2000 13:16:04 -0700 (PDT) Received: from [195.20.224.204] (helo=mrvdom00.kundenserver.de) by moutvdom00.kundenserver.de with esmtp (Exim 2.12 #2) id 13Uakl-0004qM-00 for freebsd-net@freebsd.org; Thu, 31 Aug 2000 22:16:03 +0200 Received: from [62.96.169.19] (helo=gottt) by mrvdom00.kundenserver.de with smtp (Exim 2.12 #2) id 13Uakg-0003yQ-00 for freebsd-net@FreeBSD.ORG; Thu, 31 Aug 2000 22:15:59 +0200 Message-ID: <003101c01388$bf2aff40$13a9603e@gottt> From: "Nicolas" To: Subject: Date: Thu, 31 Aug 2000 22:19:12 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org auth 4267aeed unsubscribe freebsd-net list@rachinsky.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 31 14: 3:23 2000 Delivered-To: freebsd-net@freebsd.org Received: from gizmo.csl.sony.co.jp (dhcp181.sigcomm.sics.se [212.181.55.181]) by hub.freebsd.org (Postfix) with ESMTP id DE4B937B42C for ; Thu, 31 Aug 2000 14:03:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gizmo.csl.sony.co.jp (8.9.3/8.9.3) with ESMTP id GAA05532; Fri, 1 Sep 2000 06:01:34 +0900 (JST) (envelope-from kjc@csl.sony.co.jp) To: akorud@polynet.lviv.ua Cc: freebsd-net@freebsd.org Subject: Re: ALTQ integration? From: Kenjiro Cho In-Reply-To: <8630326.20000831203057@polynet.lviv.ua> References: <8630326.20000831203057@polynet.lviv.ua> X-Mailer: Mew version 1.94.1 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000901060134N.kjc@csl.sony.co.jp> Date: Fri, 01 Sep 2000 06:01:34 +0900 X-Dispatcher: imput version 990905(IM130) Lines: 29 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Andriy Korud wrote: > Is ALTQ integrated into FreeBSD4-STABLE? not yet. > If no, is there exist some branch? not in the FreeBSD tree. > If no, will ALTQ 2.2 apply to 4-STABLE or 4.1-RELEASE? altq-2.2 supports only 4.0. > Will there be any difference between KAME source tree and integrated > ALTQ? The latest KAME snap supports 4.1 and has altq-3.0a that is still under development. > And last: > If I need production router with ALTQ on dc and sppp interfaces on the > next week, which is the best solution? You have 2 choices: - FreeBSD-4.0R + altq-2.2 - FreeBSD-4.1R + KAME snap -Kenjiro To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 31 15:53:49 2000 Delivered-To: freebsd-net@freebsd.org Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (Postfix) with ESMTP id 3988537B43E for ; Thu, 31 Aug 2000 15:53:45 -0700 (PDT) Received: (from smap@localhost) by whistle.com (8.10.0/8.10.0) id e7VMrhX14458; Thu, 31 Aug 2000 15:53:43 -0700 (PDT) Received: from bubba.whistle.com( 207.76.205.7) by whistle.com via smap (V2.0) id xma014456; Thu, 31 Aug 2000 15:53:35 -0700 Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.3) id PAA80819; Thu, 31 Aug 2000 15:53:35 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200008312253.PAA80819@bubba.whistle.com> Subject: Re: mpd PPTP question In-Reply-To: <20000829231258.A55314@lizzy.bugworks.com> "from Jos Backus at Aug 29, 2000 11:12:58 pm" To: Jos Backus Date: Thu, 31 Aug 2000 15:53:35 -0700 (PDT) Cc: net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Jos Backus writes: > Has anybody succeeded in using mpd to connect to an NT server using PPTP? I'm > trying to get this to work but I'm not having much luck. Two things in > particular I'm seeing: > > Aug 29 22:54:03 lizzy mpd: [work] LCP: state change Opened --> Req-Sent > Aug 29 22:54:03 lizzy mpd: [work] LCP: phase shift AUTHENTICATE --> ESTABLISH > > Aug 29 22:54:03 lizzy mpd: pptp0: CID 0x5f9c in SetLinkInfo not found <-- ? Probably a bug in the NT server (or mpd, but I just checked and didn't see it). In any case this is not a big deal and you can ignore it. > and the other thing is that the session never makes it beyond LCP, for reasons > I'm unable to determine based on the log :-/ Let's see the log and I'll take a look.. -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 Thu Aug 31 16:24:58 2000 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (tun.AwfulHak.org [194.242.139.173]) by hub.freebsd.org (Postfix) with ESMTP id C5B0737B423 for ; Thu, 31 Aug 2000 16:24:55 -0700 (PDT) Received: from hak.lan.Awfulhak.org (root@hak.lan.awfulhak.org [172.16.0.12]) by Awfulhak.org (8.9.3/8.9.3) with ESMTP id AAA53461; Fri, 1 Sep 2000 00:21:32 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.0/8.11.0) with ESMTP id e7VNLM706775; Fri, 1 Sep 2000 00:21:22 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200008312321.e7VNLM706775@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Tobias Fredriksson Cc: freebsd-net@FreeBSD.org, brian@Awfulhak.org Subject: Re: vr0 timeouts (applies to ALL? miibus cards) In-Reply-To: Message from Tobias Fredriksson of "Thu, 31 Aug 2000 14:14:35 -0000." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 01 Sep 2000 00:21:22 +0100 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > in 4.0 there is a problem with the miibus driver and i think this applies > to all cards that use this driver(that is all 100mbit non intel/3com as it > appears to me) > vr(D-Link among others) rl(RealTek) etc... > in 3.4-RELEASE + 3.5.1-RELEASE i havn't had a single problem with the vr > driver, not a timeout nothing speeds are usually 50-60mbit/s when > uploading to the computer and 80-90mbit/s when downloading from it. > > does anybody know if there is an fix/patch/workaround etc for > 4.0/4.1-STABLE? FWIW, I just installed two Davicom cards in a -current and a -stable box. The -stable box complains about timeouts all over the shop. The -current box is fine. I've tried bringing the -stable boxes mii code up to -current, but it doesn't help. I need to make some time to look into this more... -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 31 16:41:10 2000 Delivered-To: freebsd-net@freebsd.org Received: from w250.z064001178.sjc-ca.dsl.cnc.net (w250.z064001178.sjc-ca.dsl.cnc.net [64.1.178.250]) by hub.freebsd.org (Postfix) with SMTP id 1246437B43C for ; Thu, 31 Aug 2000 16:39:55 -0700 (PDT) Received: (qmail 93644 invoked by uid 1000); 31 Aug 2000 23:42:26 -0000 Date: Thu, 31 Aug 2000 16:42:26 -0700 From: Jos Backus To: net@freebsd.org Subject: Re: mpd PPTP question Message-ID: <20000831164226.A93633@lizzy.bugworks.com> Reply-To: Jos Backus Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi Archie, >Probably a bug in the NT server (or mpd, but I just checked >and didn't see it). >In any case this is not a big deal and you can ignore it. OK (Wouldn't surprise me.) >Let's see the log and I'll take a look.. Here it is. It's big, sorry about that. Thanks for looking into this. Jos Aug 31 16:36:14 lizzy mpd: mpd: pid 93631, version 3.0 (root@lizzy.bugworks.com 22:49 24-Aug-2000) Aug 31 16:36:14 lizzy mpd: [ms-pptp] ppp node is "mpd93631-ms-ppt" Aug 31 16:36:14 lizzy mpd: [ms-pptp] using interface ng0 Aug 31 16:36:14 lizzy mpd: [ms-pptp] IFACE: Open event Aug 31 16:36:14 lizzy mpd: [ms-pptp] IPCP: Open event Aug 31 16:36:14 lizzy mpd: [ms-pptp] IPCP: state change Initial --> Starting Aug 31 16:36:15 lizzy mpd: [ms-pptp] IPCP: LayerStart Aug 31 16:36:15 lizzy mpd: [ms-pptp] bundle: OPEN event in state CLOSED Aug 31 16:36:15 lizzy mpd: [ms-pptp] opening link "work"... Aug 31 16:36:15 lizzy mpd: [work] link: OPEN event Aug 31 16:36:15 lizzy mpd: [work] LCP: Open event Aug 31 16:36:15 lizzy mpd: [work] LCP: state change Initial --> Starting Aug 31 16:36:15 lizzy mpd: [work] LCP: LayerStart Aug 31 16:36:15 lizzy mpd: [work] device: OPEN event in state DOWN Aug 31 16:36:15 lizzy mpd: pptp0: connecting to 209.240.195.15:1723 Aug 31 16:36:15 lizzy mpd: [work] device is now in state OPENING Aug 31 16:36:15 lizzy mpd: pptp0: connected to 209.240.195.15:1723 Aug 31 16:36:15 lizzy mpd: pptp0: attached to connection with 209.240.195.15:1723 Aug 31 16:36:15 lizzy mpd: pptp0-0: outgoing call connected at -2137614336 bps Aug 31 16:36:15 lizzy mpd: [work] PPTP call successful Aug 31 16:36:15 lizzy mpd: [work] device: UP event in state OPENING Aug 31 16:36:15 lizzy mpd: [work] device is now in state UP Aug 31 16:36:15 lizzy mpd: [work] link: UP event Aug 31 16:36:15 lizzy mpd: [work] link: origination is local Aug 31 16:36:15 lizzy mpd: [work] LCP: Up event Aug 31 16:36:15 lizzy mpd: [work] LCP: state change Starting --> Req-Sent Aug 31 16:36:15 lizzy mpd: [work] LCP: phase shift DEAD --> ESTABLISH Aug 31 16:36:15 lizzy mpd: [work] LCP: SendConfigReq #1 Aug 31 16:36:15 lizzy mpd: ACFCOMP Aug 31 16:36:15 lizzy mpd: PROTOCOMP Aug 31 16:36:15 lizzy mpd: MRU 1500 Aug 31 16:36:15 lizzy mpd: MAGICNUM 46c5df8e Aug 31 16:36:15 lizzy mpd: AUTHPROTO CHAP MSOFT Aug 31 16:36:15 lizzy mpd: [work] LCP: rec'd Configure Request #0 link 0 (Req-Sent) Aug 31 16:36:15 lizzy mpd: AUTHPROTO CHAP 0x81 Aug 31 16:36:15 lizzy mpd: MAGICNUM 5813148c Aug 31 16:36:15 lizzy mpd: PROTOCOMP Aug 31 16:36:15 lizzy mpd: ACFCOMP Aug 31 16:36:15 lizzy mpd: CALLBACK Aug 31 16:36:15 lizzy mpd: Not supported Aug 31 16:36:15 lizzy mpd: [work] LCP: SendConfigRej #0 Aug 31 16:36:15 lizzy mpd: CALLBACK Aug 31 16:36:15 lizzy mpd: [work] LCP: rec'd Configure Ack #1 link 0 (Req-Sent) Aug 31 16:36:15 lizzy mpd: ACFCOMP Aug 31 16:36:15 lizzy mpd: PROTOCOMP Aug 31 16:36:15 lizzy mpd: MRU 1500 Aug 31 16:36:15 lizzy mpd: MAGICNUM 46c5df8e Aug 31 16:36:15 lizzy mpd: AUTHPROTO CHAP MSOFT Aug 31 16:36:15 lizzy mpd: [work] LCP: state change Req-Sent --> Ack-Rcvd Aug 31 16:36:15 lizzy mpd: [work] LCP: rec'd Configure Request #1 link 0 (Ack-Rcvd) Aug 31 16:36:15 lizzy mpd: AUTHPROTO CHAP 0x81 Aug 31 16:36:15 lizzy mpd: MAGICNUM 5813148c Aug 31 16:36:15 lizzy mpd: PROTOCOMP Aug 31 16:36:15 lizzy mpd: ACFCOMP Aug 31 16:36:15 lizzy mpd: [work] LCP: SendConfigNak #1 Aug 31 16:36:15 lizzy mpd: AUTHPROTO CHAP MD5 Aug 31 16:36:15 lizzy mpd: [work] LCP: rec'd Configure Request #2 link 0 (Ack-Rcvd) Aug 31 16:36:15 lizzy mpd: AUTHPROTO CHAP MSOFT Aug 31 16:36:15 lizzy mpd: MAGICNUM 5813148c Aug 31 16:36:15 lizzy mpd: PROTOCOMP Aug 31 16:36:15 lizzy mpd: ACFCOMP Aug 31 16:36:15 lizzy mpd: [work] LCP: SendConfigAck #2 Aug 31 16:36:15 lizzy mpd: AUTHPROTO CHAP MSOFT Aug 31 16:36:15 lizzy mpd: MAGICNUM 5813148c Aug 31 16:36:15 lizzy mpd: PROTOCOMP Aug 31 16:36:15 lizzy mpd: ACFCOMP Aug 31 16:36:15 lizzy mpd: [work] LCP: state change Ack-Rcvd --> Opened Aug 31 16:36:15 lizzy mpd: [work] LCP: phase shift ESTABLISH --> AUTHENTICATE Aug 31 16:36:15 lizzy mpd: [work] LCP: auth: peer wants CHAP, I want CHAP Aug 31 16:36:15 lizzy mpd: [work] CHAP: sending CHALLENGE Aug 31 16:36:15 lizzy mpd: [work] LCP: LayerUp Aug 31 16:36:15 lizzy mpd: pptp0: CID 0x5c10 in SetLinkInfo not found Aug 31 16:36:15 lizzy mpd: [work] CHAP: rec'd CHALLENGE #0 Aug 31 16:36:15 lizzy mpd: Name: "PPTPSERVER" Aug 31 16:36:15 lizzy mpd: Using authname "user" Aug 31 16:36:15 lizzy mpd: [work] CHAP: sending RESPONSE Aug 31 16:36:15 lizzy mpd: [work] CHAP: rec'd SUCCESS #0 Aug 31 16:36:15 lizzy mpd: [work] LCP: rec'd Configure Request #4 link 0 (Opened) Aug 31 16:36:15 lizzy mpd: AUTHPROTO CHAP 0x81 Aug 31 16:36:15 lizzy mpd: MAGICNUM 5a7969e8 Aug 31 16:36:15 lizzy mpd: PROTOCOMP Aug 31 16:36:15 lizzy mpd: ACFCOMP Aug 31 16:36:15 lizzy mpd: CALLBACK Aug 31 16:36:15 lizzy mpd: Not supported Aug 31 16:36:15 lizzy mpd: [work] LCP: LayerDown Aug 31 16:36:15 lizzy mpd: [work] LCP: SendConfigReq #2 Aug 31 16:36:15 lizzy mpd: ACFCOMP Aug 31 16:36:15 lizzy mpd: PROTOCOMP Aug 31 16:36:15 lizzy mpd: MRU 1500 Aug 31 16:36:15 lizzy mpd: MAGICNUM 46c5df8e Aug 31 16:36:15 lizzy mpd: AUTHPROTO CHAP MSOFT Aug 31 16:36:15 lizzy mpd: [work] LCP: SendConfigRej #4 Aug 31 16:36:15 lizzy mpd: CALLBACK Aug 31 16:36:15 lizzy mpd: [work] LCP: state change Opened --> Req-Sent Aug 31 16:36:15 lizzy mpd: [work] LCP: phase shift AUTHENTICATE --> ESTABLISH Aug 31 16:36:15 lizzy mpd: pptp0: CID 0x5c10 in SetLinkInfo not found Aug 31 16:36:15 lizzy mpd: [work] LCP: rec'd Configure Reject #2 link 0 (Req-Sent) Aug 31 16:36:15 lizzy mpd: AUTHPROTO CHAP MSOFT Aug 31 16:36:15 lizzy mpd: [work] LCP: SendConfigReq #3 Aug 31 16:36:15 lizzy mpd: ACFCOMP Aug 31 16:36:15 lizzy mpd: PROTOCOMP Aug 31 16:36:15 lizzy mpd: MRU 1500 Aug 31 16:36:15 lizzy mpd: MAGICNUM 46c5df8e Aug 31 16:36:15 lizzy mpd: AUTHPROTO CHAP MSOFT Aug 31 16:36:15 lizzy mpd: [work] LCP: rec'd Configure Request #5 link 0 (Req-Sent) Aug 31 16:36:15 lizzy mpd: AUTHPROTO CHAP 0x81 Aug 31 16:36:15 lizzy mpd: MAGICNUM 5a7969e8 Aug 31 16:36:15 lizzy mpd: PROTOCOMP Aug 31 16:36:15 lizzy mpd: ACFCOMP Aug 31 16:36:15 lizzy mpd: [work] LCP: SendConfigNak #5 Aug 31 16:36:15 lizzy mpd: AUTHPROTO CHAP MD5 Aug 31 16:36:15 lizzy mpd: [work] LCP: rec'd Configure Reject #3 link 0 (Req-Sent) Aug 31 16:36:15 lizzy mpd: AUTHPROTO CHAP MSOFT Aug 31 16:36:15 lizzy mpd: [work] LCP: SendConfigReq #4 Aug 31 16:36:15 lizzy mpd: ACFCOMP Aug 31 16:36:15 lizzy mpd: PROTOCOMP Aug 31 16:36:15 lizzy mpd: MRU 1500 Aug 31 16:36:15 lizzy mpd: MAGICNUM 46c5df8e Aug 31 16:36:15 lizzy mpd: AUTHPROTO CHAP MSOFT Aug 31 16:36:15 lizzy mpd: [work] LCP: rec'd Configure Request #6 link 0 (Req-Sent) Aug 31 16:36:15 lizzy mpd: AUTHPROTO CHAP MSOFT Aug 31 16:36:15 lizzy mpd: MAGICNUM 5a7969e8 Aug 31 16:36:15 lizzy mpd: PROTOCOMP Aug 31 16:36:15 lizzy mpd: ACFCOMP Aug 31 16:36:15 lizzy mpd: [work] LCP: SendConfigAck #6 Aug 31 16:36:15 lizzy mpd: AUTHPROTO CHAP MSOFT Aug 31 16:36:15 lizzy mpd: MAGICNUM 5a7969e8 Aug 31 16:36:15 lizzy mpd: PROTOCOMP Aug 31 16:36:15 lizzy mpd: ACFCOMP Aug 31 16:36:15 lizzy mpd: [work] LCP: state change Req-Sent --> Ack-Sent Aug 31 16:36:15 lizzy mpd: [work] LCP: rec'd Configure Reject #4 link 0 (Ack-Sent) Aug 31 16:36:15 lizzy mpd: AUTHPROTO CHAP MSOFT Aug 31 16:36:15 lizzy mpd: [work] LCP: SendConfigReq #5 Aug 31 16:36:15 lizzy mpd: ACFCOMP Aug 31 16:36:15 lizzy mpd: PROTOCOMP Aug 31 16:36:15 lizzy mpd: MRU 1500 Aug 31 16:36:15 lizzy mpd: MAGICNUM 46c5df8e Aug 31 16:36:15 lizzy mpd: AUTHPROTO CHAP MSOFT Aug 31 16:36:15 lizzy mpd: [work] LCP: rec'd Configure Reject #5 link 0 (Ack-Sent) Aug 31 16:36:15 lizzy mpd: AUTHPROTO CHAP MSOFT Aug 31 16:36:15 lizzy mpd: [work] LCP: SendConfigReq #6 Aug 31 16:36:15 lizzy mpd: ACFCOMP Aug 31 16:36:15 lizzy mpd: PROTOCOMP Aug 31 16:36:15 lizzy mpd: MRU 1500 Aug 31 16:36:15 lizzy mpd: MAGICNUM 46c5df8e Aug 31 16:36:15 lizzy mpd: AUTHPROTO CHAP MSOFT Aug 31 16:36:15 lizzy mpd: [work] LCP: rec'd Configure Reject #6 link 0 (Ack-Sent) Aug 31 16:36:15 lizzy mpd: AUTHPROTO CHAP MSOFT Aug 31 16:36:15 lizzy mpd: [work] LCP: SendConfigReq #7 Aug 31 16:36:15 lizzy mpd: ACFCOMP Aug 31 16:36:15 lizzy mpd: PROTOCOMP Aug 31 16:36:15 lizzy mpd: MRU 1500 Aug 31 16:36:15 lizzy mpd: MAGICNUM 46c5df8e Aug 31 16:36:15 lizzy mpd: AUTHPROTO CHAP MSOFT Aug 31 16:36:15 lizzy mpd: [work] LCP: rec'd Terminate Request #7 link 0 (Ack-Sent) Aug 31 16:36:15 lizzy mpd: [work] LCP: state change Ack-Sent --> Req-Sent Aug 31 16:36:15 lizzy mpd: [work] LCP: SendTerminateAck #8 Aug 31 16:36:17 lizzy mpd: [work] LCP: rec'd Terminate Request #8 link 0 (Req-Sent) Aug 31 16:36:17 lizzy mpd: [work] LCP: SendTerminateAck #9 Aug 31 16:36:17 lizzy mpd: [work] LCP: SendConfigReq #10 Aug 31 16:36:17 lizzy mpd: ACFCOMP Aug 31 16:36:17 lizzy mpd: PROTOCOMP Aug 31 16:36:17 lizzy mpd: MRU 1500 Aug 31 16:36:17 lizzy mpd: MAGICNUM 46c5df8e Aug 31 16:36:17 lizzy mpd: AUTHPROTO CHAP MSOFT Aug 31 16:36:19 lizzy mpd: pptp0: CID 0x83cb in CallClearRequest not found Aug 31 16:36:19 lizzy mpd: [work] LCP: SendConfigReq #11 Aug 31 16:36:19 lizzy mpd: ACFCOMP Aug 31 16:36:19 lizzy mpd: PROTOCOMP Aug 31 16:36:19 lizzy mpd: MRU 1500 Aug 31 16:36:19 lizzy mpd: MAGICNUM 46c5df8e Aug 31 16:36:19 lizzy mpd: AUTHPROTO CHAP MSOFT Aug 31 16:36:21 lizzy mpd: [work] LCP: SendConfigReq #12 Aug 31 16:36:21 lizzy mpd: ACFCOMP Aug 31 16:36:21 lizzy mpd: PROTOCOMP Aug 31 16:36:21 lizzy mpd: MRU 1500 Aug 31 16:36:21 lizzy mpd: MAGICNUM 46c5df8e Aug 31 16:36:21 lizzy mpd: AUTHPROTO CHAP MSOFT Aug 31 16:36:23 lizzy mpd: [work] LCP: SendConfigReq #13 Aug 31 16:36:23 lizzy mpd: ACFCOMP Aug 31 16:36:23 lizzy mpd: PROTOCOMP Aug 31 16:36:23 lizzy mpd: MRU 1500 Aug 31 16:36:23 lizzy mpd: MAGICNUM 46c5df8e Aug 31 16:36:23 lizzy mpd: AUTHPROTO CHAP MSOFT Aug 31 16:36:25 lizzy mpd: [work] LCP: SendConfigReq #14 Aug 31 16:36:25 lizzy mpd: ACFCOMP Aug 31 16:36:25 lizzy mpd: PROTOCOMP Aug 31 16:36:25 lizzy mpd: MRU 1500 Aug 31 16:36:25 lizzy mpd: MAGICNUM 46c5df8e Aug 31 16:36:25 lizzy mpd: AUTHPROTO CHAP MSOFT Aug 31 16:36:27 lizzy mpd: [work] LCP: SendConfigReq #15 Aug 31 16:36:27 lizzy mpd: ACFCOMP Aug 31 16:36:27 lizzy mpd: PROTOCOMP Aug 31 16:36:27 lizzy mpd: MRU 1500 Aug 31 16:36:27 lizzy mpd: MAGICNUM 46c5df8e Aug 31 16:36:27 lizzy mpd: AUTHPROTO CHAP MSOFT Aug 31 16:36:29 lizzy mpd: [work] LCP: SendConfigReq #16 Aug 31 16:36:29 lizzy mpd: ACFCOMP Aug 31 16:36:29 lizzy mpd: PROTOCOMP Aug 31 16:36:29 lizzy mpd: MRU 1500 Aug 31 16:36:29 lizzy mpd: MAGICNUM 46c5df8e Aug 31 16:36:29 lizzy mpd: AUTHPROTO CHAP MSOFT Aug 31 16:36:29 lizzy mpd: [work] error writing len 27 frame to bypass: No buffer space available Aug 31 16:36:31 lizzy mpd: [work] LCP: SendConfigReq #17 Aug 31 16:36:31 lizzy mpd: ACFCOMP Aug 31 16:36:31 lizzy mpd: PROTOCOMP Aug 31 16:36:31 lizzy mpd: MRU 1500 Aug 31 16:36:31 lizzy mpd: MAGICNUM 46c5df8e Aug 31 16:36:31 lizzy mpd: AUTHPROTO CHAP MSOFT Aug 31 16:36:33 lizzy mpd: [work] LCP: SendConfigReq #18 Aug 31 16:36:33 lizzy mpd: ACFCOMP Aug 31 16:36:33 lizzy mpd: PROTOCOMP Aug 31 16:36:33 lizzy mpd: MRU 1500 Aug 31 16:36:33 lizzy mpd: MAGICNUM 46c5df8e Aug 31 16:36:33 lizzy mpd: AUTHPROTO CHAP MSOFT Aug 31 16:36:33 lizzy mpd: [work] error writing len 27 frame to bypass: No buffer space available Aug 31 16:36:35 lizzy mpd: [work] LCP: state change Req-Sent --> Stopped Aug 31 16:36:35 lizzy mpd: [work] LCP: LayerFinish Aug 31 16:36:35 lizzy mpd: [work] LCP: parameter negotiation failed Aug 31 16:36:35 lizzy mpd: [work] LCP: LayerFinish Aug 31 16:36:35 lizzy mpd: [work] device: CLOSE event in state UP Aug 31 16:36:35 lizzy mpd: pptp0-0: clearing call Aug 31 16:36:35 lizzy mpd: [work] device is now in state CLOSING Aug 31 16:36:35 lizzy mpd: [work] device: CLOSE event in state CLOSING Aug 31 16:36:35 lizzy mpd: [work] device is now in state CLOSING Aug 31 16:36:35 lizzy mpd: [work] device: DOWN event in state CLOSING Aug 31 16:36:35 lizzy mpd: [work] device is now in state DOWN Aug 31 16:36:35 lizzy mpd: [work] link: DOWN event Aug 31 16:36:35 lizzy mpd: [work] LCP: Down event Aug 31 16:36:35 lizzy mpd: [work] LCP: state change Stopped --> Starting Aug 31 16:36:35 lizzy mpd: [work] LCP: phase shift ESTABLISH --> DEAD Aug 31 16:36:35 lizzy mpd: [work] LCP: LayerStart Aug 31 16:36:35 lizzy mpd: [work] device: OPEN event in state DOWN Aug 31 16:36:35 lizzy mpd: [work] pausing 8 seconds before open Aug 31 16:36:35 lizzy mpd: [work] device is now in state DOWN Aug 31 16:36:35 lizzy mpd: [work] device: OPEN event in state DOWN Aug 31 16:36:35 lizzy mpd: [work] device is now in state DOWN Aug 31 16:36:42 lizzy mpd: mpd: caught fatal signal int Aug 31 16:36:42 lizzy mpd: mpd: fatal error, exiting Aug 31 16:36:42 lizzy mpd: [ms-pptp] IPCP: Down event Aug 31 16:36:42 lizzy mpd: [ms-pptp] IFACE: Close event Aug 31 16:36:42 lizzy mpd: [ms-pptp] IPCP: Close event Aug 31 16:36:42 lizzy mpd: [ms-pptp] IPCP: state change Starting --> Initial Aug 31 16:36:42 lizzy mpd: [ms-pptp] IPCP: LayerFinish Aug 31 16:36:42 lizzy mpd: mpd: process 93631 terminated Groetjes, -- Jos Backus _/ _/_/_/ "Modularity is not a hack." _/ _/ _/ -- D. J. Bernstein _/ _/_/_/ _/ _/ _/ _/ josb@cncdsl.com _/_/ _/_/_/ use Std::Disclaimer; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 31 16:50:27 2000 Delivered-To: freebsd-net@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id B76E137B423; Thu, 31 Aug 2000 16:50:25 -0700 (PDT) Received: from localhost (kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id QAA31637; Thu, 31 Aug 2000 16:50:25 -0700 (PDT) (envelope-from kris@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs Date: Thu, 31 Aug 2000 16:50:25 -0700 (PDT) From: Kris Kennaway To: Kenjiro Cho Cc: akorud@polynet.lviv.ua, freebsd-net@freebsd.org Subject: Re: ALTQ integration? In-Reply-To: <20000901060134N.kjc@csl.sony.co.jp> 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, 1 Sep 2000, Kenjiro Cho wrote: > > If no, is there exist some branch? > > not in the FreeBSD tree. A number of us are eager to get ALTQ integrated into the main tree, so once the new version is sufficiently "ready" we'll likely do that. 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 Thu Aug 31 17:40:31 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 DB90637B42C; Thu, 31 Aug 2000 17:40:28 -0700 (PDT) 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 JAA19023; Fri, 1 Sep 2000 09:40:27 +0900 (JST) To: Kris Kennaway Cc: freebsd-net@freebsd.org In-reply-to: kris's message of Thu, 31 Aug 2000 16:50:25 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: ALTQ integration? From: itojun@iijlab.net Date: Fri, 01 Sep 2000 09:40:27 +0900 Message-ID: <19021.967768827@coconut.itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> > If no, is there exist some branch? >> not in the FreeBSD tree. >A number of us are eager to get ALTQ integrated into the main tree, so >once the new version is sufficiently "ready" we'll likely do that. one question - does ALTQ work sufficiently friendly with dummynet/netgraph/whatever layer 2/3 tricks in freebsd? 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 31 18: 0: 9 2000 Delivered-To: freebsd-net@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 59C2537B424; Thu, 31 Aug 2000 18:00:05 -0700 (PDT) Received: from localhost (kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id SAA41185; Thu, 31 Aug 2000 18:00:05 -0700 (PDT) (envelope-from kris@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs Date: Thu, 31 Aug 2000 18:00:05 -0700 (PDT) From: Kris Kennaway To: itojun@iijlab.net Cc: freebsd-net@freebsd.org Subject: Re: ALTQ integration? In-Reply-To: <19021.967768827@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 Fri, 1 Sep 2000 itojun@iijlab.net wrote: > > >> > If no, is there exist some branch? > >> not in the FreeBSD tree. > >A number of us are eager to get ALTQ integrated into the main tree, so > >once the new version is sufficiently "ready" we'll likely do that. > > one question - does ALTQ work sufficiently friendly with > dummynet/netgraph/whatever layer 2/3 tricks in freebsd? Good question. One would hope those things are sufficiently modular as to not affect altq (too much), but I have no idea. 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 Thu Aug 31 18:56: 0 2000 Delivered-To: freebsd-net@freebsd.org Received: from falla.videotron.net (falla.videotron.net [205.151.222.106]) by hub.freebsd.org (Postfix) with ESMTP id C743737B42C for ; Thu, 31 Aug 2000 18:55:52 -0700 (PDT) Received: from modemcable136.203-201-24.mtl.mc.videotron.net ([24.201.203.136]) by falla.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0G060089CPHWCL@falla.videotron.net> for freebsd-net@FreeBSD.ORG; Thu, 31 Aug 2000 21:29:56 -0400 (EDT) Date: Thu, 31 Aug 2000 21:33:09 -0400 (EDT) From: Bosko Milekic Subject: Re: Proposal to clarify mbuf handling rules In-reply-to: <200008310954.aa57200@salmon.maths.tcd.ie> X-Sender: bmilekic@jehovah.technokratis.com To: David Malone Cc: freebsd-net@FreeBSD.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 Thu, 31 Aug 2000, David Malone wrote: > At the time external storage is first attached to a mbuf you can set > M_RDONLY if it must never be written to (eg. sendfile bufs or parts > of the NFS zero copy stuff might want to do similar). If the M_RDONLY > flag is set you must not write to the buffer, otherwise you can write > to the buffer if it's a simple mbuf or if the reference count on the > external storage is 1. > > (Atleast, this is the system I had in mind). OK, well, if the system is limited to the above, and will remain so (which is conceivable), then the single RDONLY flag + the macro should do. The question is always performance vs. memory, though. If you decide to sacrifice the extra 4 bytes per MEXT mbuf, you get faster execution time (as you are only checking for that one bit), and this for all execution cases. The drawbacks are the 4 byte loss and of course, the fact that you cannot mark individual mbufs with no external storage as read-only. But I don't see how the latter would be useful anyway. The other advantage is that you can later decide the you _do_ want to write to the external buffer and be able to remove the RDONLY bit on-the-fly. But this isn't presently a requirement, so feel free to consider the point moot. If you decide to not sacrifice the extra 4 bytes per MEXT mbuf, then you will have slower execution time, as the macro does a much longer check, which you must do in every case, but the one which finds the RDONLY bit already set. In either case, I am prepared to do at least the first part of the implementation. For the first case, I've already made the mext_descr changes here. But reverting to the second case is very easy, as one would assume. Diffs can be rolled out before the end of this weekend, unless one of you guys can pull off something even sooner, in which case please let me know. Cheers, Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 1 0:11:54 2000 Delivered-To: freebsd-net@freebsd.org Received: from gizmo.csl.sony.co.jp (dhcp181.sigcomm.sics.se [212.181.55.181]) by hub.freebsd.org (Postfix) with ESMTP id BC1BA37B424 for ; Fri, 1 Sep 2000 00:11:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gizmo.csl.sony.co.jp (8.9.3/8.9.3) with ESMTP id QAA00922; Fri, 1 Sep 2000 16:10:09 +0900 (JST) (envelope-from kjc@csl.sony.co.jp) To: itojun@iijlab.net Cc: freebsd-net@freebsd.org Subject: Re: ALTQ integration? From: Kenjiro Cho In-Reply-To: <19021.967768827@coconut.itojun.org> References: <19021.967768827@coconut.itojun.org> X-Mailer: Mew version 1.94.1 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000901161009J.kjc@csl.sony.co.jp> Date: Fri, 01 Sep 2000 16:10:09 +0900 X-Dispatcher: imput version 990905(IM130) Lines: 20 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > one question - does ALTQ work sufficiently friendly with > dummynet/netgraph/whatever layer 2/3 tricks in freebsd? > > itojun ALTQ currently works with dummynet but not with netgraph. The problem with layer 2 tricks is that the classifier needs to parse multiple link headers (e.g., PPPoE) to look at the IP header. In the new ALTQ design, the classifier hook and the scheduler hook are separated so that the classifier can be called before prepending link headers. But it might need another trick to pass the classifier result to the enqueue operation if the classifier hook and the enqueue operation can't be placed in the same function. (one possible solution is to tag the result to mbuf itself but this is going to be a seperate project.) -Kenjiro To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 1 0:26:25 2000 Delivered-To: freebsd-net@freebsd.org Received: from guard.polynet.lviv.ua (Guard.PolyNet.Lviv.UA [209.58.62.194]) by hub.freebsd.org (Postfix) with SMTP id 78A9F37B422 for ; Fri, 1 Sep 2000 00:26:18 -0700 (PDT) Received: (qmail 26210 invoked from network); 1 Sep 2000 07:26:14 -0000 Received: from unknown (HELO postoffice.polynet.lviv.ua) (unknown) by unknown with SMTP; 1 Sep 2000 07:26:14 -0000 Received: (qmail 80353 invoked from network); 1 Sep 2000 07:26:13 -0000 Received: (ofmipd unknown); 1 Sep 2000 07:25:51 -0000 Date: 1 Sep 2000 10:26:26 +0300 Message-ID: <8250759177.20000901102626@polynet.lviv.ua> From: "Andriy Korud" Reply-To: "Andriy Korud" To: freebsd-net@freebsd.org X-Mailer: The Bat! (v1.44) X-Priority: 3 (Normal) Subject: Re[2]: ALTQ integration? In-reply-To: <20000901060134N.kjc@csl.sony.co.jp> References: <8630326.20000831203057@polynet.lviv.ua> <20000901060134N.kjc@csl.sony.co.jp> 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 Hello Kenjiro, Friday, September 01, 2000, 12:01:34 AM, you wrote: Kenjiro> Andriy Korud wrote: >> Is ALTQ integrated into FreeBSD4-STABLE? Kenjiro> not yet. >> If no, is there exist some branch? Kenjiro> not in the FreeBSD tree. >> If no, will ALTQ 2.2 apply to 4-STABLE or 4.1-RELEASE? Kenjiro> altq-2.2 supports only 4.0. >> Will there be any difference between KAME source tree and integrated >> ALTQ? Kenjiro> The latest KAME snap supports 4.1 and has altq-3.0a that is still Kenjiro> under development. >> And last: >> If I need production router with ALTQ on dc and sppp interfaces on the >> next week, which is the best solution? Kenjiro> You have 2 choices: Kenjiro> - FreeBSD-4.0R + altq-2.2 Kenjiro> - FreeBSD-4.1R + KAME snap Kenjiro> -Kenjiro OK, more questions: 1. Where can I get userland tools for ALTQ in KAME snap? 2. I CVSUPed KAME snap yesterday and in if_dc.c found comments something like "driver broke xxx, disabling ALTQ for this chip". So, is ALTQ actually supported on dc interface? (DLINK DFE-570TX) 3. If I need only ALTQ and don't need IPv6 and IPSEC, I think I don't need to patch userland FreeBSD's software? -- Best regards, Andriy mailto:akorud@polynet.lviv.ua To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 1 0:49: 6 2000 Delivered-To: freebsd-net@freebsd.org Received: from vbook.express.ru (vbook.express.ru [212.24.37.106]) by hub.freebsd.org (Postfix) with ESMTP id 795B837B440 for ; Fri, 1 Sep 2000 00:49:03 -0700 (PDT) Received: (from vova@localhost) by vbook.express.ru (8.9.3/8.9.3) id LAA51080; Fri, 1 Sep 2000 11:49:22 +0400 (MSD) (envelope-from vova) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14767.24449.353037.707473@vbook.express.ru> Date: Fri, 1 Sep 2000 11:49:21 +0400 (MSD) To: freebsd-net@freebsd.org In-Reply-To: <39A84CE6.D3F0454B@clickarray.com> References: <39A84CE6.D3F0454B@clickarray.com> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid From: "Vladimir B. Grebenschikov" Subject: public vrrpd src for FreeBSD? Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Stephen Head writes: > Hi, anyone know of a public source code version for VRRP > that is a full implementation (I'm already aware of > the vrrpd 0.2 for linux). Thanks, ftp://ftp.dev.express.ru/pub/FreeBSD/utils/vrrpd.tgz This is ported version for FreeBSD without SIOCSIFLLADDR > Steve (smh@clickarray.com) -- TSB Russian Express, Moscow Vladimir B. Grebenschikov, vova@express.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 1 1: 7:24 2000 Delivered-To: freebsd-net@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id E8DEC37B424 for ; Fri, 1 Sep 2000 01:07:21 -0700 (PDT) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 1 Sep 2000 09:07:20 +0100 (BST) To: Bosko Milekic Cc: freebsd-net@FreeBSD.ORG, dwmalone@maths.tcd.ie Subject: Re: Proposal to clarify mbuf handling rules In-reply-to: Your message of "Thu, 31 Aug 2000 21:33:09 EDT." X-Request-Do: Date: Fri, 01 Sep 2000 09:07:19 +0100 From: David Malone Message-ID: <200009010907.aa78923@salmon.maths.tcd.ie> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > OK, well, if the system is limited to the above, and will remain so > (which is conceivable), then the single RDONLY flag + the macro should > do. The question is always performance vs. memory, though. > > If you decide to sacrifice the extra 4 bytes per MEXT mbuf, you get > faster execution time (as you are only checking for that one bit), and > this for all execution cases. You still have to check if the storage is external - so you need to make two checks. Without the extra 4 bytes the test is: #define M_WRITABLE(m) (!((m)->m_flags & M_RDONLY) && \ (!((m)->m_flags & M_EXT) || !MEXT_IS_REF(m))) With the extra 4 bytes the test is: #define M_WRITABLE(m) (!((m)->m_flags & M_EXT) || \ ((m)->m_ext.ref_cnt->flags & M_EXT_WRITABLE)) I'd guess that we'll find the difference unmeasurable in practice, given that in the second case we'll have deal with m_ext.ref_cnt->flags in a SMP safe way when updating it, which will have to be done in the ADD_REF and REM_REF macros. > The drawbacks are the 4 byte loss and of > course, the fact that you cannot mark individual mbufs with no external > storage as read-only. But I don't see how the latter would be useful > anyway. Me neither - but you never know ;-) > The other advantage is that you can later decide the you _do_ > want to write to the external buffer and be able to remove the RDONLY bit > on-the-fly. But this isn't presently a requirement, so feel free to > consider the point moot. This could be useful in the future, but I'd be inclined to wait until we need it. Did you have any other interesting uses for M_EXT flags in mind? > In either case, I am prepared to do at least the first part of the > implementation. For the first case, I've already made the mext_descr > changes here. But reverting to the second case is very easy, as one would > assume. Diffs can be rolled out before the end of this weekend, unless > one of you guys can pull off something even sooner, in which case > please let me know. Great! Maybe Archie should say which he thinks we opt for in the beginning, and we can see if we can get some patches reviewed. (We seem to all be badly seperated by timezones, which is slowing this process down quite a bit ;-) David. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 1 1:30:43 2000 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 98F6E37B424; Fri, 1 Sep 2000 01:30:38 -0700 (PDT) Received: from InterJet.elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id BAA26494; Fri, 1 Sep 2000 01:30:25 -0700 (PDT) Date: Fri, 1 Sep 2000 01:30:24 -0700 (PDT) From: Julian Elischer To: itojun@iijlab.net Cc: Kris Kennaway , freebsd-net@freebsd.org Subject: Re: ALTQ integration? In-Reply-To: <19021.967768827@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 Fri, 1 Sep 2000 itojun@iijlab.net wrote: > > > one question - does ALTQ work sufficiently friendly with > dummynet/netgraph/whatever layer 2/3 tricks in freebsd? I believe that altq and netgraph shouldbe orthogonal there may be 1 or two very small changes to netgraph queueing but they would be trivial. > > itojun > > > 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 Sep 1 2:36: 7 2000 Delivered-To: freebsd-net@freebsd.org Received: from gizmo.csl.sony.co.jp (dhcp181.sigcomm.sics.se [212.181.55.181]) by hub.freebsd.org (Postfix) with ESMTP id ABE6E37B43C for ; Fri, 1 Sep 2000 02:36:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gizmo.csl.sony.co.jp (8.9.3/8.9.3) with ESMTP id SAA02153; Fri, 1 Sep 2000 18:34:31 +0900 (JST) (envelope-from kjc@csl.sony.co.jp) To: akorud@polynet.lviv.ua Cc: freebsd-net@freebsd.org Subject: Re: Re[2]: ALTQ integration? From: Kenjiro Cho In-Reply-To: <8250759177.20000901102626@polynet.lviv.ua> References: <8630326.20000831203057@polynet.lviv.ua> <20000901060134N.kjc@csl.sony.co.jp> <8250759177.20000901102626@polynet.lviv.ua> X-Mailer: Mew version 1.94.1 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000901183431A.kjc@csl.sony.co.jp> Date: Fri, 01 Sep 2000 18:34:31 +0900 X-Dispatcher: imput version 990905(IM130) Lines: 25 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Andriy Korud wrote: > OK, more questions: > 1. Where can I get userland tools for ALTQ in KAME snap? altqd and altqstat are in the KAME tree. If you need tools under altq-2.2/legacy-tools, you need to install them from altq-2.2 (you need to edit Makefiles). > 2. I CVSUPed KAME snap yesterday and in if_dc.c found comments > something like "driver broke xxx, disabling ALTQ for this chip". So, > is ALTQ actually supported on dc interface? (DLINK DFE-570TX) Most devices supported by the dc driver work with ALTQ except a few chips that doesn't do scatter/gather DMA. I believe those are only Davicom devices. > 3. If I need only ALTQ and don't need IPv6 and IPSEC, I think I don't > need to patch userland FreeBSD's software? KAME snap doesn't patch the existing software and their userland tools are installed into /usr/local/v6 and don't overwrite the existing tools. So, if you don't need them, just don't use them. -Kenjiro To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 1 11: 2:54 2000 Delivered-To: freebsd-net@freebsd.org Received: from field.videotron.net (field.videotron.net [205.151.222.108]) by hub.freebsd.org (Postfix) with ESMTP id DB1A037B43C for ; Fri, 1 Sep 2000 11:02:46 -0700 (PDT) Received: from modemcable136.203-201-24.mtl.mc.videotron.net ([24.201.203.136]) by field.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0G0700F3IZA4A2@field.videotron.net> for freebsd-net@FreeBSD.ORG; Fri, 1 Sep 2000 13:58:52 -0400 (EDT) Date: Fri, 01 Sep 2000 14:02:07 -0400 (EDT) From: Bosko Milekic Subject: Re: Proposal to clarify mbuf handling rules In-reply-to: <200009010907.aa78923@salmon.maths.tcd.ie> X-Sender: bmilekic@jehovah.technokratis.com To: David Malone Cc: freebsd-net@FreeBSD.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 Fri, 1 Sep 2000, David Malone wrote: > You still have to check if the storage is external - so you need to make > two checks. Without the extra 4 bytes the test is: > > #define M_WRITABLE(m) (!((m)->m_flags & M_RDONLY) && \ > (!((m)->m_flags & M_EXT) || !MEXT_IS_REF(m))) > > With the extra 4 bytes the test is: > > #define M_WRITABLE(m) (!((m)->m_flags & M_EXT) || \ > ((m)->m_ext.ref_cnt->flags & M_EXT_WRITABLE)) As we do not have a use for read-only non-external buffer mbufs (and it's less probable that we will ever need that, compared to, for example, being able to remove M_RDONLY on the fly), then you ultimately have to test for M_EXT in both cases anyway. Your second M_WRITABLE above looks bogus because I use M_RDONLY, so it will be more like: #define M_READONLY(m) ((m)->m_flags & M_EXT) && \ ((m)->m_ext.descr->perms & M_RDONLY)) will evaluate to true if the data is not to be tampered with. For the moment, I will re-work the code as per your and Ian's ideas, because it's simpler and it meets our needs. I cannot justify having to remove M_RDONLY in the middle of something. At the same time, I *will* add a type or flags variable to m_ext, as it will make things slightly cleaner at no extra expense. > I'd guess that we'll find the difference unmeasurable in practice, > given that in the second case we'll have deal with m_ext.ref_cnt->flags > in a SMP safe way when updating it, which will have to be done in > the ADD_REF and REM_REF macros. That is true, both would need to be wrapped such that they remove or add the flag, respectively, if the ref. count suddenly drops to 1, or increases from 1. Actually, now that you bring up SMP, you remind me that we may even have to hold a BGL when doing this, so that if the ref count happens to increase while we're at it, so that we do not end up messing things up. This is unpractical, and you're right. > This could be useful in the future, but I'd be inclined to wait until > we need it. Did you have any other interesting uses for M_EXT flags in > mind? No, I cannot presently justify it. > Great! Maybe Archie should say which he thinks we opt for in the beginning, > and we can see if we can get some patches reviewed. > > (We seem to all be badly seperated by timezones, which is slowing this > process down quite a bit ;-) > > David. Okay, I will post *something* by this upcoming Monday (long weekend here!). Later, Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 1 12:39:40 2000 Delivered-To: freebsd-net@freebsd.org Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (Postfix) with ESMTP id 4298E37B505 for ; Fri, 1 Sep 2000 12:39:38 -0700 (PDT) Received: (from smap@localhost) by whistle.com (8.10.0/8.10.0) id e81Jcnn23793; Fri, 1 Sep 2000 12:38:49 -0700 (PDT) Received: from bubba.whistle.com( 207.76.205.7) by whistle.com via smap (V2.0) id xma023790; Fri, 1 Sep 2000 12:38:40 -0700 Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.3) id MAA86592; Fri, 1 Sep 2000 12:38:34 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200009011938.MAA86592@bubba.whistle.com> Subject: Re: Proposal to clarify mbuf handling rules In-Reply-To: <200009010907.aa78923@salmon.maths.tcd.ie> "from David Malone at Sep 1, 2000 09:07:19 am" To: David Malone Date: Fri, 1 Sep 2000 12:38:34 -0700 (PDT) Cc: Bosko Milekic , freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org David Malone writes: > Great! Maybe Archie should say which he thinks we opt for in the beginning, > and we can see if we can get some patches reviewed. I like what you guys have agreed upon and my only comment is to "do it with macros" so we can change things around later but that should be obvious already. Unfortunately I'll be out of email contact next week but look forward to seeing where things stand upon returning. Cheers, -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 Fri Sep 1 12:55: 5 2000 Delivered-To: freebsd-net@freebsd.org Received: from mailserver.KOM.e-technik.tu-darmstadt.de (drum.kom.e-technik.tu-darmstadt.de [130.83.139.190]) by hub.freebsd.org (Postfix) with ESMTP id 4C10D37B42C for ; Fri, 1 Sep 2000 12:55:02 -0700 (PDT) Received: from KOM.tu-darmstadt.de by mailserver.KOM.e-technik.tu-darmstadt.de (8.7.5/8.7.5) with ESMTP id VAA24721; Fri, 1 Sep 2000 21:55:00 +0200 (MET DST) From: Martin Karsten Received: from KOM.tu-darmstadt.de by KOM.tu-darmstadt.de (8.9.3/8.7.5) id VAA07262; Fri, 1 Sep 2000 21:54:58 +0200 Message-Id: <200009011954.VAA07262@KOM.tu-darmstadt.de> Subject: Re: kern/20984: conflict between IP_RSVP_ON and IP_RSVP_VIF_ON To: kjc@csl.sony.co.jp Date: Fri, 1 Sep 2000 21:54:58 +0200 (CEST) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL66 (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 Kenjiro, following your advice, I have submitted my request as the subjected bug report with send-pr. I have tested the change with ISI's rsvpd once again and as described in the bug report, the proposed small change does not affect the (however unsatisfying) behaviour of rsvpd. I have reported this behaviour as well as the proposed fix to the rsvp-test list at isi.edu about one year ago, but I have never really received any answer. Thanks and best regards, Martin PS: please include my email address in any further discussion, since I am not subscribed to freebsd-net ----- Forwarded message from gnats-admin@FreeBSD.org ----- From gnats@FreeBSD.org Fri Sep 1 19:21:55 2000 Date: Fri, 1 Sep 2000 10:20:00 -0700 (PDT) Message-Id: <200009011720.KAA78463@freefall.freebsd.org> To: Martin.Karsten@KOM.tu-darmstadt.de From: gnats-admin@FreeBSD.org Subject: Re: kern/20984: conflict between IP_RSVP_ON and IP_RSVP_VIF_ON Reply-To: gnats-admin@FreeBSD.org, freebsd-bugs@FreeBSD.org In-Reply-To: Your message of Fri, 1 Sep 2000 10:11:50 -0700 (PDT) <20000901171150.8FC4D37B43C@hub.freebsd.org> Sender: gnats@FreeBSD.org Thank you very much for your problem report. It has the internal identification `kern/20984'. The individual assigned to look at your report is: freebsd-bugs. You can access the state of your problem report at any time via this link: http://www.freebsd.org/cgi/query-pr.cgi?pr=20984 >Category: kern >Responsible: freebsd-bugs >Synopsis: conflict between IP_RSVP_ON and IP_RSVP_VIF_ON >Arrival-Date: Fri Sep 01 10:20:00 PDT 2000 ----- End of forwarded message from gnats-admin@FreeBSD.org ----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Sep 2 4:34:56 2000 Delivered-To: freebsd-net@freebsd.org Received: from guard.polynet.lviv.ua (Guard.PolyNet.Lviv.UA [209.58.62.194]) by hub.freebsd.org (Postfix) with SMTP id 2FC6437B43C for ; Sat, 2 Sep 2000 04:34:49 -0700 (PDT) Received: (qmail 26799 invoked from network); 2 Sep 2000 11:34:43 -0000 Received: from unknown (HELO postoffice.polynet.lviv.ua) (unknown) by unknown with SMTP; 2 Sep 2000 11:34:43 -0000 Received: (qmail 42284 invoked from network); 2 Sep 2000 11:34:42 -0000 Received: (ofmipd unknown); 2 Sep 2000 11:34:20 -0000 Date: 2 Sep 2000 14:35:43 +0300 Message-ID: <122572553.20000902143543@polynet.lviv.ua> From: "Andriy Korud" Reply-To: "Andriy Korud" To: altq@csl.sony.co.jp Cc: freebsd-net@freebsd.org X-Mailer: The Bat! (v1.44) X-Priority: 3 (Normal) Subject: Running ALTQ X-Sender: Andriy Korud 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 Hello all, I've successfully compiled KAME cvsup, everything is working fine, but when I try to run altqd with the following cfg file (very simple, just for test): interface dc0 bandwidth 100M cbq class cbq dc0 root_class NULL priority 0 admission none pbandwidth 100 class cbq dc0 def_class root_class borrow pbandwidth 95 default # class cbq dc0 tcp_class0 def_class pbandwidth 1 filter dc0 tcp_class0 0 0 0 0 6 I got the following output: ALTQ config file is /etc/altq.conf tbr installed on dc0 (rate:100.00M size:11.72K) cbq_flowspec: maxburst=16,minburst=2,pkt_size=1500 nsPerByte=80.00 ns, link's nsPerByte=80.00, f=1.000 packet time=120 [us] warning: maxburst smaller than timer granularity! maxburst=16, packet_time=120 [us] maxidle=3.75 us offtime=0.00 us minidle=-120.00 us maxq=30 cbq_flowspec: maxburst=16,minburst=2,pkt_size=1500 nsPerByte=86.02 ns, link's nsPerByte=80.00, f=0.930 packet time=129 [us] warning: maxburst smaller than timer granularity! maxburst=16, packet_time=129 [us] maxidle=5.98 us offtime=18.36 us minidle=-129.03 us maxq=30 cbq_flowspec: maxburst=16,minburst=2,pkt_size=1500 nsPerByte=4000.00 ns, link's nsPerByte=80.00, f=0.020 packet time=6000 [us] maxidle=3892.14 us offtime=11949.68 us minidle=-6000.00 us maxq=30 dc0: add a filter (null) to class ctl_class Filter Dest Addr: 0.0.0.0 (mask 0) Port: 0 Src Addr: 0.0.0.0 (mask 0) Port: 0 Protocol: 1 TOS 0 (mask 0) dc0: add a filter (null) to class ctl_class Filter Dest Addr: 0.0.0.0 (mask 0) Port: 0 Src Addr: 0.0.0.0 (mask 0) Port: 0 Protocol: 2 TOS 0 (mask 0) dc0: add a filter (null) to class ctl_class Filter Dest Addr: 0.0.0.0 (mask 0) Port: 0 Src Addr: 0.0.0.0 (mask 0) Port: 0 Protocol: 46 TOS 0 (mask 0) syscall error: add filter failed! : Invalid argument can't add ctl class filter on interface 'dc0' cbq_flowspec: maxburst=4,minburst=2,pkt_size=1500 nsPerByte=8000.00 ns, link's nsPerByte=80.00, f=0.010 packet time=12000 [us] maxidle=1608.68 us offtime=24143.23 us minidle=-12000.00 us maxq=30 dc0: add a filter (null) to class tcp_class0 Filter Dest Addr: 0.0.0.0 (mask 0xffffffff) Port: 0 Src Addr: 0.0.0.0 (mask 0xffffffff) Port: 0 Protocol: 6 TOS 0 (mask 0) cbq enabled on interface dc0 (mtu:1500) Please note the error. And there is no limit - interface is working on full speed. Any ideas/suggestions? -- Best regards, Andriy mailto:akorud@polynet.lviv.ua To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Sep 2 8:18: 9 2000 Delivered-To: freebsd-net@freebsd.org Received: from lh2.rdc1.tx.home.com (ha2.rdc1.tx.home.com [24.4.0.67]) by hub.freebsd.org (Postfix) with ESMTP id DFC3137B42C for ; Sat, 2 Sep 2000 08:18:04 -0700 (PDT) Received: from c158580a ([24.21.170.113]) by lh2.rdc1.tx.home.com (InterMail vM.4.01.02.00 201-229-116) with SMTP id <20000902151804.CHJI22866.lh2.rdc1.tx.home.com@c158580a> for ; Sat, 2 Sep 2000 08:18:04 -0700 Message-ID: <001a01c014f1$6b5859c0$71aa1518@mesqt1.tx.home.com> From: "MrBoboo" To: Subject: ip aliasing Date: Sat, 2 Sep 2000 10:21:08 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0017_01C014C7.827188E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_0017_01C014C7.827188E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable my FBSD box is my internet gateway (firewall/gateway/connection to = net), my win98se box is set to private IP addy, ok, i am on a cable modem (@home) and they are on a DHCP network, the = only thing that stays the same is the HOSTNAME,=20 if in that confiuration, how am i supposed to setup (in windows) my = gateway in network properties, also the DNS in on the otherside of my = FBSD computer, how am i supposed to setup my DNS and Gateway??? i can ping my FBSD system by computer name and both IP's (internal and = external), i cant ping anything else i have also changed my windows DNS settings to my ISP's DNS server IP, = but i also had the hostname and the domain name to set, my ISP domain is = @home form what i know, how do you totally find that out?? also the hostname i set to both mrboboo-2 and c158580-a and neither = worked (mrboboo-2 is the name of the win98se computer, c158580-a is the = FBSD computer when online) any clues?? my /etc/rc.conf looks like this:=20 network_interfaces=3D"rl0 vr0" ifconfig_vr0-"inet 192.168.1.1netmask 255.255.255.0" defaultrouter=3D"DHCP" hostname=3D"c158580-a" gateway_enable=3D"YES" =20 my looks like this: interface "rl0" { send host-name "cr123456-a"; request subnet-mask, broadcast-address, routers, domain-name-servers, domain-name, time-servers; require domain-name-servers; } =20 my /etc/hosts looks like this: 127.0.0.1 localhost.yowza.com localost #dont know how but = this works properly which was set as default with the OS 192.168.1.2 mrboboo-2 #this works fine also, i can ping the = windows machine by comp name and internal IP =20 =20 =20 =20 if anyone knows how to get windows to work properly with dynamic DNS = and GATEWAY info, then pllez help or if they know of a better way than to configure it, like if i am = trying to do it incorrectly =20 Rob Wideman =20 ------=_NextPart_000_0017_01C014C7.827188E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
my FBSD box is my internet gateway (firewall/gateway/connection = to net),=20 my win98se box is set to private IP addy,
ok, i am on a cable modem = (@home)=20 and they are on a DHCP network, the only thing that stays the same is = the=20 HOSTNAME,
if in that confiuration, how am i supposed to setup (in = windows)=20 my gateway in network properties, also the DNS in on the otherside of = my FBSD=20 computer, how am i supposed to setup my DNS and Gateway???
i can = ping my=20 FBSD system by computer name and both IP's (internal and external), i = cant=20 ping anything else
i have also changed my windows DNS = settings to my=20 ISP's DNS server IP, but i also had the hostname and the domain name = to set,=20 my ISP domain is @home form what i know, how do you totally find that=20 out??
also the hostname i set to both = mrboboo-2 and=20 c158580-a and neither worked (mrboboo-2 is the name of the win98se = computer,=20 c158580-a is the FBSD computer when online)
any clues??

my = /etc/rc.conf looks=20 like this:
network_interfaces=3D"rl0 vr0"
ifconfig_vr0-"inet=20 192.168.1.1netmask=20 = 255.255.255.0"
defaultrouter=3D"DHCP"
hostname=3D"c158580-a"=
gateway_enable=3D"YES"
 
my  looks like this:
interface "rl0" {
send host-name = "cr123456-a";
request=20 subnet-mask, broadcast-address,=20 routers,
         =20 domain-name-servers, domain-name, time-servers;
require=20 domain-name-servers;
}
 
my=20 /etc/hosts looks like=20 this:
127.0.0.1       =20 localhost.yowza.com localost    #dont know how but this = works=20 properly which was set as default with the=20 OS
192.168.1.2       =20 mrboboo-2    #this works fine also, i can ping the = windows=20 machine by comp name and internal=20 IP
 
 
 
 
if=20 anyone knows how to get windows to work properly with dynamic DNS and = GATEWAY=20 info, then pllez help
or if they know of a better way than = to=20 configure it, like if i am trying to do it = incorrectly
 
Rob=20 Wideman
 

= ------=_NextPart_000_0017_01C014C7.827188E0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Sep 2 21:38:40 2000 Delivered-To: freebsd-net@freebsd.org Received: from avocet.prod.itd.earthlink.net (avocet.prod.itd.earthlink.net [207.217.121.50]) by hub.freebsd.org (Postfix) with ESMTP id CDDF037B424 for ; Sat, 2 Sep 2000 21:38:38 -0700 (PDT) Received: from nukemhigh (hybrid-024-221-117-152.phoenix.speedchoice.com [24.221.117.152]) by avocet.prod.itd.earthlink.net (8.9.3-EL_1_3/8.9.3) with SMTP id VAA24762 for ; Sat, 2 Sep 2000 21:38:34 -0700 (PDT) Message-Id: <200009030438.VAA24762@avocet.prod.itd.earthlink.net> X-Sender: egravel@mail.earthlink.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Sat, 02 Sep 2000 21:44:17 -0700 To: freebsd-net@freebsd.org From: Emmanuel Gravel Subject: Increasing network performance Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have a few machines in network. I'm using FreeBSD as my NAT/firewall. The NIC's in the FreeBSD box are 3c509B's. It's a P90 with 32 MB of RAM, and at least double of swap. Not running any caching/proxy servers, unless you consider NAT as a proxy. When exchanging files between my FreeBSD box and others on the network, and no Internet traffic, at maximum I've seen ~ 250 KB/s (not quite 2 Mb/s) transfer rates. When I get Internet traffic, the transfer rate goes way down if I also try to transfer files, and I get strange behaviour from the network. Traffic happens in bursts, which seem usually (but not always) disrupted by collisions, and usually there's a fairly long pause (a few seconds) before traffic starts again. I would think part of it has to do with the system being dual-homed, with two 509's, but I'm sure there has to be something to do to improve performance somehow. Does anyone know where I should look to get my box to react a little more sanely? If there's anything else you want to know just ask :) Thanks! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Sep 2 22:59: 2 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 4B0AE37B43E for ; Sat, 2 Sep 2000 22:58:59 -0700 (PDT) Received: from localhost (winter@localhost) by sasami.jurai.net (8.9.3/8.8.7) with ESMTP id BAA35754; Sun, 3 Sep 2000 01:58:56 -0400 (EDT) Date: Sun, 3 Sep 2000 01:58:56 -0400 (EDT) From: "Matthew N. Dodd" To: Emmanuel Gravel Cc: freebsd-net@FreeBSD.ORG Subject: Re: Increasing network performance In-Reply-To: <200009030438.VAA24762@avocet.prod.itd.earthlink.net> 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, 2 Sep 2000, Emmanuel Gravel wrote: > Does anyone know where I should look to get my box to react a little > more sanely? If there's anything else you want to know just ask :) 3c509s are a wee bit CPU hungry. The driver still has a few issues that make the cards a poor choice for performance under FreeBSD. -- | 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 Sep 2 23: 7:52 2000 Delivered-To: freebsd-net@freebsd.org Received: from avocet.prod.itd.earthlink.net (avocet.prod.itd.earthlink.net [207.217.121.50]) by hub.freebsd.org (Postfix) with ESMTP id 7222337B423 for ; Sat, 2 Sep 2000 23:07:51 -0700 (PDT) Received: from nukemhigh (hybrid-024-221-117-152.phoenix.speedchoice.com [24.221.117.152]) by avocet.prod.itd.earthlink.net (8.9.3-EL_1_3/8.9.3) with SMTP id XAA17067 for ; Sat, 2 Sep 2000 23:07:49 -0700 (PDT) Message-Id: <200009030607.XAA17067@avocet.prod.itd.earthlink.net> X-Sender: egravel@mail.earthlink.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Sat, 02 Sep 2000 23:13:34 -0700 To: freebsd-net@FreeBSD.ORG From: Emmanuel Gravel Subject: Re: Increasing network performance In-Reply-To: References: <200009030438.VAA24762@avocet.prod.itd.earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ah! I knew there were driver issues, but didn't think it would be that bad. Which NIC's would best suit my needs (decent performance, dual homed, P90 CPU, and not too expensive)? Thanks! At 01:58 AM 9/3/00 -0400, Matthew N. Dodd wrote: >On Sat, 2 Sep 2000, Emmanuel Gravel wrote: >> Does anyone know where I should look to get my box to react a little >> more sanely? If there's anything else you want to know just ask :) > >3c509s are a wee bit CPU hungry. The driver still has a few issues that >make the cards a poor choice for performance under FreeBSD. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Sep 2 23:10:43 2000 Delivered-To: freebsd-net@freebsd.org Received: from lh2.rdc1.tx.home.com (ha2.rdc1.tx.home.com [24.4.0.67]) by hub.freebsd.org (Postfix) with ESMTP id 4403937B422 for ; Sat, 2 Sep 2000 23:10:40 -0700 (PDT) Received: from c158580a ([24.21.170.113]) by lh2.rdc1.tx.home.com (InterMail vM.4.01.02.00 201-229-116) with SMTP id <20000903061040.UTCS22866.lh2.rdc1.tx.home.com@c158580a> for ; Sat, 2 Sep 2000 23:10:40 -0700 Message-ID: <001f01c0156e$1da7dca0$71aa1518@mesqt1.tx.home.com> From: "MrBoboo" To: "freebsd net" Subject: kernel thing Date: Sun, 3 Sep 2000 01:13:45 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001C_01C01544.34B96AA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_001C_01C01544.34B96AA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable is there a way to view the settings or configuration for the curent = kernel that is running instead of making a kernel from scratch, i just = want to change some lines in my current one, is there a way to do = that??? basically do a CP of the current to a new file name perhaps MYKERNEL, = then edit MYKERNEL and then you know the rest if so pleez help, thanx Rob Wideman ------=_NextPart_000_001C_01C01544.34B96AA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
is there a way to view the settings or=20 configuration for the curent kernel that is running instead of making a = kernel=20 from scratch, i just want to change some lines in my current one, is = there a way=20 to do that???
basically do a CP of the current to a = new file name=20 perhaps MYKERNEL, then edit MYKERNEL and then you know the = rest
if so pleez help, thanx
Rob = Wideman
------=_NextPart_000_001C_01C01544.34B96AA0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message