From owner-freebsd-net Sun Apr 14 3: 4:59 2002 Delivered-To: freebsd-net@freebsd.org Received: from mars-gw.morning.ru (ns.morning.ru [195.161.98.5]) by hub.freebsd.org (Postfix) with ESMTP id 188C037B400; Sun, 14 Apr 2002 03:04:50 -0700 (PDT) Received: (from root@localhost) by mars-gw.morning.ru (8.11.5/8.11.5) id g3EA4lC05175; Sun, 14 Apr 2002 18:04:47 +0800 (KRAST) Date: Sun, 14 Apr 2002 18:04:47 +0800 From: Igor M Podlesny To: net@FreeBSD.ORG Cc: freebsd-isp@FreeBSD.ORG Subject: patch -- An ingress filter (RFC2827) Message-ID: <20020414180447.A93954@mars-gw.morning.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello! I'd like to know your opinion about this patch http://www.morning.ru/~poige/patchzone/ingressfiltering.patch which is mine attempt to implement an ingress filter being inspired by RFC2827 "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing". (http://www.ietf.org/rfc/rfc2827.txt) It should be mentioned IMHO that this code makes another one in ip_input.c a kind of redundant -- I mean code checking/blocking the 127/8 network "on wire". BTW, I suggest if not removing it completely then adding (sys)logging into, -- 127/8-spoofing certainly should be logged. :) Another thing to pay an attention to: I deem it'd be better if a such filter was built-in into ip_fw.c, allowing such syntax for ipfw(8): deny log ip from any to any in via fxp0 spoofed But AFAIS in ip_fw.h: #define IP_FW_F_IN 0x00000100 ... #define IP_FW_F_DME 0x40000000 /* destination = me */ #define IP_FW_F_MASK 0x7FFFFFFF /* All possible flag bits mask */ and u_int32_t fw_flg; there is no free space for any additional flags... So, I was a bit unsure whether should I expand fw_flg to u_int64_t, and do any other extensions. For now I decided just to wrote something like a draft, test it (it seems to be working ;), and asking you, people, for your comments/ideas on it. P.S. A bit more info on this patch is at http://www.morning.ru/~poige/patchzone/ -- Igor M Podlesny a.k.a. Poige http://WwW.MorninG.RU/~poige To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Apr 14 14:25:49 2002 Delivered-To: freebsd-net@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id EAE7C37B400; Sun, 14 Apr 2002 14:25:40 -0700 (PDT) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g3ELPRR19424; Sun, 14 Apr 2002 14:25:27 -0700 (PDT) (envelope-from rizzo) Date: Sun, 14 Apr 2002 14:25:27 -0700 From: Luigi Rizzo To: Igor M Podlesny Cc: net@FreeBSD.ORG, freebsd-isp@FreeBSD.ORG Subject: Re: patch -- An ingress filter (RFC2827) Message-ID: <20020414142527.B18991@iguana.icir.org> References: <20020414180447.A93954@mars-gw.morning.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020414180447.A93954@mars-gw.morning.ru> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, this is more a comment on rfc2827 than on the patch (which seems to do basically what is in the RFC). This kind of filtering gives very little protection. For single-homed systems with a default route, basically the only packets that it can deny are those with a 127/8 source address on the wire. And even the case of multi-homed routers, in most cases it will likely protect only from attacks coming from the inside of your network. Finally, i agree that the place for this code is within ip_fw.c, definitely not ip_input.c cheers luigi > > Hello! > > I'd like to know your opinion about this patch > > http://www.morning.ru/~poige/patchzone/ingressfiltering.patch > > which is mine attempt to implement an ingress filter being inspired by > RFC2827 "Network Ingress Filtering: Defeating Denial of Service Attacks > which employ IP Source Address Spoofing". > > (http://www.ietf.org/rfc/rfc2827.txt) > > It should be mentioned IMHO that this code makes another one in ip_input.c a > kind of redundant -- I mean code checking/blocking the 127/8 network "on > wire". BTW, I suggest if not removing it completely then adding (sys)logging > into, -- 127/8-spoofing certainly should be logged. :) > > Another thing to pay an attention to: I deem it'd be better if a such filter > was built-in into ip_fw.c, allowing such syntax for ipfw(8): > > deny log ip from any to any in via fxp0 spoofed > > But AFAIS in ip_fw.h: > > #define IP_FW_F_IN 0x00000100 > ... > #define IP_FW_F_DME 0x40000000 /* destination = me */ > > #define IP_FW_F_MASK 0x7FFFFFFF /* All possible flag bits mask */ > > and u_int32_t fw_flg; > > there is no free space for any additional flags... > > So, I was a bit unsure whether should I expand fw_flg to u_int64_t, and do > any other extensions. For now I decided just to wrote something like a > draft, test it (it seems to be working ;), and asking you, people, for your > comments/ideas on it. > > P.S. A bit more info on this patch is at http://www.morning.ru/~poige/patchzone/ > > -- > Igor M Podlesny a.k.a. Poige > http://WwW.MorninG.RU/~poige > > 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 Sun Apr 14 17: 5:17 2002 Delivered-To: freebsd-net@freebsd.org Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by hub.freebsd.org (Postfix) with ESMTP id 440B537B419; Sun, 14 Apr 2002 17:05:09 -0700 (PDT) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.37.22]) by shiva.jussieu.fr (8.12.1/jtpda-5.4) with ESMTP id g3F058YD062922 ; Mon, 15 Apr 2002 02:05:08 +0200 (CEST) Received: from heho.snv.jussieu.fr (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.12.2/jtpda-5.2) with ESMTP id g3F04gmX014250 ; Mon, 15 Apr 2002 02:04:42 +0200 (MEST) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.12.2/8.12.2/Submit) id g3F04g3k014247; Mon, 15 Apr 2002 02:04:42 +0200 (MEST) From: "Arno J. Klaassen" To: freebsd-stable@freebsd.org Cc: freebsd-net@freebsd.org Subject: ntp problems; am i the only one? Date: 15 Apr 2002 02:04:42 +0200 Message-ID: Lines: 70 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello, I did not pay much attention, but since a couple of weeks (the latest "daylight savings in Europe????") mu ntp programs do not function anymore and host clocks drift further and further (both for machines I upgraded to -stable as for machines which have a couple a months old -stable ...). When I do: ntpdate -bv ntp1.oleane.net I get 15 Apr 01:53:24 ntpdate[14191]: ntpdate 4.1.0-a Sat Apr 13 21:23:32 MEST 2002 (1) 15 Apr 01:53:28 ntpdate[14191]: no server suitable for synchronization found When I do : ntpdate -bdv ntp1.oleane.net I get 15 Apr 01:53:33 ntpdate[14192]: ntpdate 4.1.0-a Sat Apr 13 21:23:32 MEST 2002 (1) transmit(194.2.0.58) receive(194.2.0.58) transmit(194.2.0.58) receive(194.2.0.58) transmit(194.2.0.58) receive(194.2.0.58) transmit(194.2.0.58) receive(194.2.0.58) transmit(194.2.0.58) server 194.2.0.58, port 123 stratum 2, precision -17, leap 00, trust 000 refid [192.36.143.152], delay 0.02751, dispersion 0.00008 transmitted 4, in filter 4 reference time: c06494ad.61d3dc8b Mon, Apr 15 2002 1:52:13.382 originate timestamp: c0649517.53f7be12 Mon, Apr 15 2002 1:53:59.327 transmit timestamp: c06494fd.f09a133c Mon, Apr 15 2002 1:53:33.939 filter delay: 0.02794 0.02751 0.02791 0.02780 0.00000 0.00000 0.00000 0.00000 filter offset: 25.38715 25.38698 25.38685 25.38704 0.000000 0.000000 0.000000 0.000000 delay 0.02751, dispersion 0.00008 offset 25.386989 15 Apr 01:53:33 ntpdate[14192]: step time server 194.2.0.58 offset 25.386989 sec i.e. looks like ntpdate finds the correct offset, but is no longer capable to apply it; I tried with "ntpd -q" but without succes as well. I am not aware of any changes I did, apart form the classical world-cycle on *part* of my boxes, but the problem exists on *all* boxes. This might be a firewall-issue of the university, but then, even "ntpdate -v box-next-to-me" gives the sames behaviour. I would be glad to know if there is another european FreeBSD sysadmin who can tell me if he is capable or not to use ntp. Thanx in advance. Arno -- Arno J. Klaassen INSERM U483 9 quai st bernard Paris arno@ccr.jussieu.fr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Apr 14 19: 5:44 2002 Delivered-To: freebsd-net@freebsd.org Received: from mars-gw.morning.ru (ns.morning.ru [195.161.98.5]) by hub.freebsd.org (Postfix) with ESMTP id 018EF37B419; Sun, 14 Apr 2002 19:05:34 -0700 (PDT) Received: (from root@localhost) by mars-gw.morning.ru (8.11.5/8.11.5) id g3F252I26454; Mon, 15 Apr 2002 10:05:02 +0800 (KRAST) Date: Mon, 15 Apr 2002 10:05:01 +0800 From: Igor M Podlesny To: Richard A Steenbergen Cc: Luigi Rizzo , Igor M Podlesny , net@FreeBSD.ORG, freebsd-isp@FreeBSD.ORG Subject: Re: patch -- An ingress filter (RFC2827) Message-ID: <20020415100501.B93954@mars-gw.morning.ru> References: <20020414180447.A93954@mars-gw.morning.ru> <20020414142527.B18991@iguana.icir.org> <20020414225243.GW523@overlord.e-gerbil.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020414225243.GW523@overlord.e-gerbil.net>; from ras@e-gerbil.net on Sun, Apr 14, 2002 at 06:52:43PM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, Apr 14, 2002 at 06:52:43PM -0400, Richard A Steenbergen wrote: > On Sun, Apr 14, 2002 at 02:25:27PM -0700, Luigi Rizzo wrote: > > > > Hi, > > this is more a comment on rfc2827 than on the patch (which seems to do > > basically what is in the RFC). > > This kind of filtering gives very little protection. For single-homed > > systems with a default route, basically the only packets that it > > can deny are those with a 127/8 source address on the wire. > > And even the case of multi-homed routers, in most cases it will likely > > protect only from attacks coming from the inside of your network. > > I do completely agree with Richard A Steenbergen who's saying: > The point of RFC2827 isn't to protect you from an attack by spoofing > source addresses it is to prevent you (and/or your downstream customers) > from being the source of address spoofing attacks against others. Of > course it was written from the router point of view, "ingress" refering to > the traffic you take in from your customers. > > Finally, i agree that the place for this code is within ip_fw.c, > > definitely not ip_input.c yeah, this'd be a better choice. > On a system level, this means preventing your server from being > compromised and used to attack others (or at least attack others with > spoofed source addresses). This would probably be most closely associated > with a securelevel, which drops packets sent through raw sockets with a > source address that you don't have on your system. Unfortunately, there is > nothing preventing an attacker from adding fake aliases to an interface > and then spoofing from those IPs, but it would certainly clamp down on > random source attacks. > Of course, you would have to adjust securelevel to prevent interface and > routing changes as well. But securelevel sucks, why not get rid of it. It > would be much better to have the ability to cut off specific capabilities > for the entire system (some simple sysctl's), without being forced into > setting things you don't want to when you only have a few "modes" of > operation. this refers to a host(router)-itself protection, IMHO... > After you do that, this filtering would actually be a fairly > useful feature. Great, any specific ideas? :) > -- > Richard A Steenbergen http://www.e-gerbil.net/ras -- Igor M Podlesny a.k.a. Poige http://WwW.MorninG.RU/~poige To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Apr 14 19: 8:16 2002 Delivered-To: freebsd-net@freebsd.org Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by hub.freebsd.org (Postfix) with ESMTP id 449C637B404 for ; Sun, 14 Apr 2002 19:08:12 -0700 (PDT) Received: from ns.iij.ad.jp (ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id LAA09464 for ; Mon, 15 Apr 2002 11:08:11 +0900 (JST) Received: from localhost (keiichi01.osaka.iij.ad.jp [192.168.65.66]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id LAA03826; Mon, 15 Apr 2002 11:08:10 +0900 (JST) Date: Mon, 15 Apr 2002 11:07:53 +0900 (JST) Message-Id: <20020415.110753.50151185.keiichi@iij.ad.jp> To: freebsd-net@FreeBSD.ORG Subject: IPv6 configuration document? From: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= X-Mailer: Mew version 3.0.55 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, Does anyone know where is the document for configuring IPv6 on FreeBSD, if any? The NetBSD web page has a really cool manual (http://www.netbsd.org/Documentation/network/ipv6/) for IPv6 people using NetBSD. I'm looking for such a document for FreBSD. --- Keiichi SHIMA IIJ Research Laboratory KAME Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Apr 14 23:25:51 2002 Delivered-To: freebsd-net@freebsd.org Received: from spf1.hq.outblaze.com (202-77-223-26.outblaze.com [202.77.223.26]) by hub.freebsd.org (Postfix) with ESMTP id 3624937B426 for ; Sun, 14 Apr 2002 23:25:00 -0700 (PDT) Received: from yusufg.portal2.com (202-77-223-2.outblaze.com [202.77.223.2]) by spf1.hq.outblaze.com (Postfix) with SMTP id 2596026BC9 for ; Mon, 15 Apr 2002 06:24:02 +0000 (GMT) Received: (qmail 13654 invoked by uid 500); 15 Apr 2002 06:24:51 -0000 Date: 15 Apr 2002 06:24:51 -0000 Message-ID: <20020415062451.13653.qmail@yusufg.portal2.com> From: Yusuf Goolamabbas To: freebsd-net@freebsd.org Subject: What does FreeBSD do when listen queue is full ? Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org We are using sendmail 8.11.6 patched to support mysql lookups. This is on FreeBSD 4.4-stable (cvsup'ed early December 2001) Recently my colleague turned on ConnectionRateThrottle and set it for a value of 20 Shortly he would observe that connections would get reset immediately after the client connected (but before the sendmail banner was shown) [yusufg@yusufg yusufg]$ telnet target.sendmail.server smtp Trying a.b.c.d... Connected to target.sendmail.server Escape character is '^]'. Connection closed by foreign host. At that time, neither MaxChildren nor load average had reached their threshold which would make sendmail close its listening socket. Sendmail's behaviour on reaching ConnectionRateThrottle threshold is to sleep for 1 second which is likely to cause the listen queue to back up This would not occur on all connections but would occur quite frequently and this behaviour would go away if we did not use ConnectionRateThrottle tcpdump traces showed that the target sendmail server was sending an RST packet immediately after sending a SYN-ACK in response to our SYN Subsequently, we changed the listen backlog to 128 via DAEMON_OPTIONS(`Port=smtp, Name=MTA, Listen=128') and turned ConnectionRateThrottle back on with a value of 20. Now, the immediate reset is triggered but quite infrequently I thought that FreeBSD might be sending a RESET when the listen queue is full but that would be contrary to what the listen(2) man page says 'If a connection request arrives with the queue full the client may receive an error with an indication of ECONNREFUSED, or, if the underlying protocol supports retransmission, the request may be ignored so that retries may succeed.' My understanding of the term 'underlying protocol' was that it referred to TCP/IP which support retransmission and thus when the listen queue is full, requests are ignored Another colleague/myself looked through the FreeBSD sources and made the following observations When a new connection request comes in, tcp_input does a few things first and then calls sonewconn (implemented in uipc_socket2.c) to create a socket to queue the incoming request. The first thing sonewconn does is to check if the socket queue length is > 3/2 * so_qlimit, and if so, it returns a NULL pointer. If a NULL pointer is returned, sodropablereq (implemented in uipc_socket2.c) is called to randomly select a connection from the socket's queue of incomplete connection for dropping. If a connection is selected for dropping, the function tcp_drop (implemented in tcp_subr.c) is called to drop the selected connection. tcp_drop will send a RST to the peer if the selected connection is in a synchronized state (i.e., SYN received and we have sent a SYN + ACK). Is this a correct reading/interpretation of the code, thus does it imply that FreeBSD 4.4-stable sends an RST under certain conditions when the listen queue is full. In that case, the man page can be modified to mention this In 4.5-RELEASE, there seems to be no caller for sodropablereq, however the function is declared in sys/sys/socketvar.h and defined in sys/kern/uipc_socket2.c. Maybe it can be deleted from the source tree I have yet to read J.Lemon's Usenix paper on syncache and figure out how that affects tcp input processing Regards, Yusuf -- Yusuf Goolamabbas yusufg@outblaze.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Apr 14 23:38:42 2002 Delivered-To: freebsd-net@freebsd.org Received: from patrocles.silby.com (d27.as28.nwbl0.wi.voyager.net [169.207.69.27]) by hub.freebsd.org (Postfix) with ESMTP id 55EDB37B400 for ; Sun, 14 Apr 2002 23:38:35 -0700 (PDT) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.2/8.12.2) with ESMTP id g3FCcCLx003453; Mon, 15 Apr 2002 07:38:12 -0500 (CDT) (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.2/8.12.2/Submit) with ESMTP id g3FCc9No003450; Mon, 15 Apr 2002 07:38:11 -0500 (CDT) X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Mon, 15 Apr 2002 07:38:08 -0500 (CDT) From: Mike Silbersack To: Yusuf Goolamabbas Cc: freebsd-net@freebsd.org Subject: Re: What does FreeBSD do when listen queue is full ? In-Reply-To: <20020415062451.13653.qmail@yusufg.portal2.com> Message-ID: <20020415073620.F3157-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 15 Apr 2002, Yusuf Goolamabbas wrote: > In 4.5-RELEASE, there seems to be no caller for sodropablereq, however > the function is declared in sys/sys/socketvar.h and defined in > sys/kern/uipc_socket2.c. Maybe it can be deleted from the source tree I'll go look into cleaning that up tomorrow. > I have yet to read J.Lemon's Usenix paper on syncache and figure out > how that affects tcp input processing > > Regards, Yusuf The syncache changes syn processing entirely, and seems to have a very positive effect. Rather than analyzing the old behavior, you're best off spending time upgrading to RELENG_4_5. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Apr 14 23:52:43 2002 Delivered-To: freebsd-net@freebsd.org Received: from patrocles.silby.com (d27.as28.nwbl0.wi.voyager.net [169.207.69.27]) by hub.freebsd.org (Postfix) with ESMTP id A9BE137B4C2 for ; Sun, 14 Apr 2002 23:51:52 -0700 (PDT) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.2/8.12.2) with ESMTP id g3FCpLLx003543; Mon, 15 Apr 2002 07:51:21 -0500 (CDT) (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.2/8.12.2/Submit) with ESMTP id g3FCpKRt003540; Mon, 15 Apr 2002 07:51:21 -0500 (CDT) X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Mon, 15 Apr 2002 07:51:20 -0500 (CDT) From: Mike Silbersack To: Yusuf Goolamabbas Cc: freebsd-net@freebsd.org Subject: Re: What does FreeBSD do when listen queue is full ? In-Reply-To: <20020415062451.13653.qmail@yusufg.portal2.com> Message-ID: <20020415074210.V3157-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 15 Apr 2002, Yusuf Goolamabbas wrote: > Subsequently, we changed the listen backlog to 128 via > DAEMON_OPTIONS(`Port=smtp, Name=MTA, Listen=128') > and turned ConnectionRateThrottle back on with a value of 20. Now, the > immediate reset is triggered but quite infrequently > > I thought that FreeBSD might be sending a RESET when the listen queue is > full but that would be contrary to what the listen(2) man page says > > 'If a connection request arrives with the queue full the client may > receive an error with an indication of ECONNREFUSED, or, if the > underlying protocol supports retransmission, the request may be ignored > so that retries may succeed.' There used to be two listen queues; one for completed connections and one for incomplete connections. (Complete referring to the TCP three-way handshake completing.) The syncache replaces the incomplete connection queue, meaning that the listen queue depth is no longer relevant there. I just did a quick look over the code, and it appears that the complete connection queue is still intact, and takes on 3/2*listen backlog as its length. Therefore, if sendmail is deciding to not accept() all connections ASAP, a backlog will build up, and RSTs will be sent to incoming connections. This should be true under 4.4 or 4.5. The listen manpage looks to be pretty accurate in its description. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 15 0: 8: 2 2002 Delivered-To: freebsd-net@freebsd.org Received: from spf1.hq.outblaze.com (202-77-223-26.outblaze.com [202.77.223.26]) by hub.freebsd.org (Postfix) with ESMTP id 8135537B405 for ; Mon, 15 Apr 2002 00:07:58 -0700 (PDT) Received: from yusufg.portal2.com (202-77-223-2.outblaze.com [202.77.223.2]) by spf1.hq.outblaze.com (Postfix) with SMTP id 5DE8C26B99 for ; Mon, 15 Apr 2002 07:07:06 +0000 (GMT) Received: (qmail 13935 invoked by uid 500); 15 Apr 2002 07:07:53 -0000 Date: Mon, 15 Apr 2002 15:07:53 +0800 From: Yusuf Goolamabbas To: freebsd-net@freebsd.org Subject: Re: What does FreeBSD do when listen queue is full ? Message-ID: <20020415070753.GA13864@outblaze.com> References: <20020415062451.13653.qmail@yusufg.portal2.com> <20020415074210.V3157-100000@patrocles.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020415074210.V3157-100000@patrocles.silby.com> User-Agent: Mutt/1.3.28i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > There used to be two listen queues; one for completed connections and one > for incomplete connections. (Complete referring to the TCP three-way > handshake completing.) The syncache replaces the incomplete connection > queue, meaning that the listen queue depth is no longer relevant there. What is the maximum size of the queue for completed connections ? Is there a sysctl setting for this > I just did a quick look over the code, and it appears that the complete > connection queue is still intact, and takes on 3/2*listen backlog as its > length. Therefore, if sendmail is deciding to not accept() all > connections ASAP, a backlog will build up, and RSTs will be sent to > incoming connections. This should be true under 4.4 or 4.5. > > The listen manpage looks to be pretty accurate in its description. What about the statement 'or,if the underlying protocol supports retransmission, the request may be ignored so that retries may succeed' What does 'underlying protocol' refer to then since you are saying that even with TCP which supports retransmission, the stack sends a RST when the listen queue is full Regards, Yusuf -- Yusuf Goolamabbas yusufg@outblaze.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 15 0:21:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from patrocles.silby.com (d27.as28.nwbl0.wi.voyager.net [169.207.69.27]) by hub.freebsd.org (Postfix) with ESMTP id 419CC37B404 for ; Mon, 15 Apr 2002 00:21:09 -0700 (PDT) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.2/8.12.2) with ESMTP id g3FDKmLx003701; Mon, 15 Apr 2002 08:20:48 -0500 (CDT) (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.2/8.12.2/Submit) with ESMTP id g3FDKkmO003698; Mon, 15 Apr 2002 08:20:47 -0500 (CDT) X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Mon, 15 Apr 2002 08:20:46 -0500 (CDT) From: Mike Silbersack To: Yusuf Goolamabbas Cc: freebsd-net@freebsd.org Subject: Re: What does FreeBSD do when listen queue is full ? In-Reply-To: <20020415070753.GA13864@outblaze.com> Message-ID: <20020415081535.O3157-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 15 Apr 2002, Yusuf Goolamabbas wrote: > > There used to be two listen queues; one for completed connections and one > > for incomplete connections. (Complete referring to the TCP three-way > > handshake completing.) The syncache replaces the incomplete connection > > queue, meaning that the listen queue depth is no longer relevant there. > > What is the maximum size of the queue for completed connections ? Is > there a sysctl setting for this The listen backlog parameter should determine this. > > The listen manpage looks to be pretty accurate in its description. > > What about the statement > > 'or,if the underlying protocol supports retransmission, the request may > be ignored so that retries may succeed' > > What does 'underlying protocol' refer to then since you are saying that > even with TCP which supports retransmission, the stack sends a RST when > the listen queue is full > > Regards, Yusuf > > -- > Yusuf Goolamabbas That statement makes sense to me if the incomplete connection queue is being referred to. (Although that would be incorrect wrt the default behavior in 4.4, and the syncache isn't a queue.) Maybe I can word that better when I go through and make sure all the comments in the source are up to date. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 15 2:13:37 2002 Delivered-To: freebsd-net@freebsd.org Received: from pump3.york.ac.uk (pump3.york.ac.uk [144.32.128.131]) by hub.freebsd.org (Postfix) with ESMTP id B164C37B416; Mon, 15 Apr 2002 02:13:32 -0700 (PDT) Received: from ury.york.ac.uk (ury.york.ac.uk [144.32.108.81]) by pump3.york.ac.uk (8.10.2/8.10.2) with ESMTP id g3F9DHj15478; Mon, 15 Apr 2002 10:13:27 +0100 (BST) Received: from localhost (gavin@localhost) by ury.york.ac.uk (8.11.6/8.11.3) with ESMTP id g3F9D2S44324; Mon, 15 Apr 2002 10:13:02 +0100 (BST) (envelope-from gavin.atkinson@ury.york.ac.uk) X-Authentication-Warning: ury.york.ac.uk: gavin owned process doing -bs Date: Mon, 15 Apr 2002 10:13:02 +0100 (BST) From: Gavin Atkinson To: "Arno J. Klaassen" Cc: , Subject: Re: ntp problems; am i the only one? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 15 Apr 2002, Arno J. Klaassen wrote: > I did not pay much attention, but since a couple of weeks > (the latest "daylight savings in Europe????") mu ntp > programs do not function anymore and host clocks > drift further and further (both for machines > I upgraded to -stable as for machines which have a couple > a months old -stable ...). > > When I do: ntpdate -bv ntp1.oleane.net I get > > 15 Apr 01:53:24 ntpdate[14191]: ntpdate 4.1.0-a Sat Apr 13 21:23:32 MEST 2002 (1) > 15 Apr 01:53:28 ntpdate[14191]: no server suitable for synchronization found > > I would be glad to know if there is another european FreeBSD sysadmin > who can tell me if he is capable or not to use ntp. I'm currently seeing a similar problem, but so far have been unable to confirm if it's my boxes or the NTP server. (I've only found a single server that doesn't seem to work with ntpdate, though it seems to be fine with ntpd) Don't know if that helps anything. Gavin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 15 2:34:50 2002 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (oe69.pav0.hotmail.com [64.4.33.211]) by hub.freebsd.org (Postfix) with ESMTP id BE61237B400 for ; Mon, 15 Apr 2002 02:34:42 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 15 Apr 2002 02:34:42 -0700 X-Originating-IP: [212.3.13.44] From: "Mattias Eriksson" To: Subject: mpd & pptp problem Date: Mon, 15 Apr 2002 11:34:18 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 15 Apr 2002 09:34:42.0645 (UTC) FILETIME=[C59C9050:01C1E460] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello, I am trying to establish a pptp-tunnel from a freebsd-server to a watchguard firewall without any luck. I notice in the logfile that my server sends challenges and expects an answer from the firewall. After that it fails. Anyone seen this before? It works fine with a windows2000-klient. The protocols in use are mschapv2 and mppe128. [vpn] LCP: state change Ack-Sent --> Opened [vpn] LCP: phase shift ESTABLISH --> AUTHENTICATE [vpn] LCP: auth: peer wants CHAP, I want CHAP [vpn] CHAP: sending CHALLENGE [vpn] LCP: LayerUp [vpn] CHAP: rec'd CHALLENGE #1 Name: "xxxxx" Using authname "yyyyy" [vpn] CHAP: sending RESPONSE [vpn] CHAP: rec'd SUCCESS #1 MESG: S=3b1b5220ea3ea895c60fe2d59cf1e2cb927a5b6d [vpn] CHAP: sending CHALLENGE [vpn] CHAP: sending CHALLENGE [vpn] LCP: authorization timer expired [vpn] LCP: authorization failed [vpn] device: CLOSE event in state UP pptp0-0: clearing call [vpn] device is now in state CLOSING [vpn] device: DOWN event in state CLOSING [vpn] device is now in state DOWN Mattias E. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 15 2:36:35 2002 Delivered-To: freebsd-net@freebsd.org Received: from unix.za.net (unix.za.net [137.158.96.78]) by hub.freebsd.org (Postfix) with ESMTP id 007B137B404; Mon, 15 Apr 2002 02:35:30 -0700 (PDT) Received: from unix.za.net (daniel@localhost [IPv6:::1]) by unix.za.net (8.12.2/8.12.2) with ESMTP id g3F9ZKfl056163; Mon, 15 Apr 2002 11:35:20 +0200 (SAST) (envelope-from daniel@unix.za.net) Received: from localhost (daniel@localhost) by unix.za.net (8.12.2/8.12.2/Submit) with ESMTP id g3F9ZJHW056160; Mon, 15 Apr 2002 11:35:19 +0200 (SAST) Date: Mon, 15 Apr 2002 11:35:19 +0200 (SAST) From: Daniel Schroder To: Gavin Atkinson Cc: "Arno J. Klaassen" , , Subject: Re: ntp problems; am i the only one? In-Reply-To: Message-ID: <20020415113424.W55944-100000@unix.za.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I had problems , they went away when I specified the config file to use , this may or may not be related to problems at hand. --Daniel Schroder (Private email daniel@unix.os.org.za) Unix users .. South Africa To : Arno J. Klaassen From : Gavin Atkinson date : Apr 15 Address : gavin@ury.york.ac.uk +27839904029@sms.co.za : Unable to locate coffee. Operator halted. On Mon, 15 Apr 2002, Gavin Atkinson wrote: > On 15 Apr 2002, Arno J. Klaassen wrote: > > > I did not pay much attention, but since a couple of weeks > > (the latest "daylight savings in Europe????") mu ntp > > programs do not function anymore and host clocks > > drift further and further (both for machines > > I upgraded to -stable as for machines which have a couple > > a months old -stable ...). > > > > When I do: ntpdate -bv ntp1.oleane.net I get > > > > 15 Apr 01:53:24 ntpdate[14191]: ntpdate 4.1.0-a Sat Apr 13 21:23:32 MEST 2002 (1) > > 15 Apr 01:53:28 ntpdate[14191]: no server suitable for synchronization found > > > > I would be glad to know if there is another european FreeBSD sysadmin > > who can tell me if he is capable or not to use ntp. > > I'm currently seeing a similar problem, but so far have been unable to > confirm if it's my boxes or the NTP server. (I've only found a single > server that doesn't seem to work with ntpdate, though it seems to be fine > with ntpd) > > Don't know if that helps anything. > > Gavin > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-stable" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 15 3:13:40 2002 Delivered-To: freebsd-net@freebsd.org Received: from mailhost.firstcallgroup.co.uk (dilbert.firstcallgroup.co.uk [194.200.93.142]) by hub.freebsd.org (Postfix) with ESMTP id B87F337B404; Mon, 15 Apr 2002 03:13:35 -0700 (PDT) Received: from pfrench by mailhost.firstcallgroup.co.uk with local (Exim 3.34 #1) id 16x3UH-000Nr0-00; Mon, 15 Apr 2002 11:13:29 +0100 To: arno@heho.snv.jussieu.fr, freebsd-stable@freebsd.org Subject: Re: ntp problems; am i the only one? Cc: freebsd-net@freebsd.org In-Reply-To: Message-Id: From: Pete French Date: Mon, 15 Apr 2002 11:13:29 +0100 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > This might be a firewall-issue of the university, but then, even > "ntpdate -v box-next-to-me" gives the sames behaviour. Try giving the '-u' argument to ntpdate... I needed that to get through a firewall when I used ntpdate to set the clock on my boxes. > I would be glad to know if there is another european FreeBSD sysadmin > who can tell me if he is capable or not to use ntp. For what its worth I am using ntp quite happily in three completely separate locations; and two of those are runnign a -STABLE from last week. The NTP servers are all in the UK: server 195.66.241.2 # ntp.linx.net server 195.66.241.3 # ntp.linx.net server 158.43.128.33 # ntp0.pipex.net server 158.43.128.66 # ntp1.pipex.net server 158.43.192.66 # ntp2.pipex.net server 194.72.6.51 # ntp0.bt.net server 194.74.77.190 # ntp1.bt.net server 194.72.6.60 # ntp2.bt.net -pcf. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 15 9:47:30 2002 Delivered-To: freebsd-net@freebsd.org Received: from fubar.damon.com (damon.com [199.98.84.2]) by hub.freebsd.org (Postfix) with ESMTP id E000F37B416; Mon, 15 Apr 2002 09:47:24 -0700 (PDT) Received: from fubar.damon.com (localhost [127.0.0.1]) by fubar.damon.com (8.12.2/8.12.2) with ESMTP id g3FGlJwM000418; Mon, 15 Apr 2002 11:47:19 -0500 (CDT) (envelope-from dap@fubar.damon.com) Received: (from dap@localhost) by fubar.damon.com (8.12.2/8.12.2/Submit) id g3FGlIqq000417; Mon, 15 Apr 2002 11:47:18 -0500 (CDT) Date: Mon, 15 Apr 2002 11:47:18 -0500 From: Damon Permezel To: jlemon@FreeBSD.org Cc: freebsd-net@FreeBSD.org Subject: gx problems with IP frags. Message-ID: <20020415164718.GA343@fubar.damon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.27i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi. No response, so I decided to have a look. The 82543 doesn't support checksum generation for IP frags. Can't say for sure about the 82544, as I don't have the spex. To fix this problem for the gx driver, change the features to be: #define GX_CSUM_FEATURES (CSUM_IP | CSUM_TCP | CSUM_UDP) in dev/gx/if_gx.c. Cheers, Damon. -- -- Damon Permezel dap@damon.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 15 12:42:37 2002 Delivered-To: freebsd-net@freebsd.org Received: from relay.flashnet.it (ems.flashnet.it [194.247.160.44]) by hub.freebsd.org (Postfix) with ESMTP id ED20337B41A for ; Mon, 15 Apr 2002 12:42:18 -0700 (PDT) Received: from smtp.flashnet.it (ip059.pool-110.cyb.it [195.191.17.188]) by relay.flashnet.it (/) with SMTP id g3FJgBX10083 for ; Mon, 15 Apr 2002 21:42:11 +0200 Message-Id: <200204151942.g3FJgBX10083@relay.flashnet.it> To: freebsd-net@freebsd.org X-Mailer: Post Road Mailer for OS/2 (Green Edition Ver 3.0) Date: Mon, 15 Apr 2002 21:42:12 EST From: Andrea Venturoli Reply-To: Andrea Venturoli Subject: Two DHCP servers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Is it possible to have two DHCP servers on the same net? If so, how do you keep them in sync? bye & Thanks av. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 15 13: 7: 9 2002 Delivered-To: freebsd-net@freebsd.org Received: from freesbee.wheel.dk (freesbee.wheel.dk [193.162.159.97]) by hub.freebsd.org (Postfix) with ESMTP id 1771937B400 for ; Mon, 15 Apr 2002 13:07:07 -0700 (PDT) Received: by freesbee.wheel.dk (Postfix, from userid 1038) id 1D64D5F83; Mon, 15 Apr 2002 22:07:06 +0200 (CEST) Date: Mon, 15 Apr 2002 22:07:06 +0200 From: Michael =?iso-8859-1?Q?Lyngb=F8l?= To: Andrea Venturoli Cc: freebsd-net@freebsd.org Subject: Re: Two DHCP servers Message-ID: <20020415200705.GA28028@freesbee.wheel.dk> Mail-Followup-To: Andrea Venturoli , freebsd-net@freebsd.org References: <200204151942.g3FJgBX10083@relay.flashnet.it> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200204151942.g3FJgBX10083@relay.flashnet.it> User-Agent: Mutt/1.3.28i X-Operating-System: FreeBSD/i386 4.5-STABLE SMP X-PGP-Fingerprint: 3CA6 3789 1455 8FC2 D499 F22A D763 1ABB 9E4A 37AE X-PGP-Public-Key: finger lyngbol@tigerdyr.wheel.dk Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 15.04.2002 21:42:12 +0000, Andrea Venturoli wrote: > Is it possible to have two DHCP servers on the same net? > If so, how do you keep them in sync? ISC's DHCPd can do failover. ; /usr/ports/net/isc-dhcp3/ -- Michael Lyngbøl -- michael at lyngbol dot dk TDC Tele Danmark, DataNetworks, IP·backbone To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 15 13:24:35 2002 Delivered-To: freebsd-net@freebsd.org Received: from owa1.digisle.com (ex-owa-sj.digisle.com [165.193.27.217]) by hub.freebsd.org (Postfix) with ESMTP id 96ED337B41A; Mon, 15 Apr 2002 13:24:03 -0700 (PDT) Received: from digisle.net ([206.220.227.147] RDNS failed) by owa1.digisle.com over TLS secured channel with Microsoft SMTPSVC(5.0.2195.2966); Mon, 15 Apr 2002 13:24:02 -0700 Message-ID: <3CBB36DB.850B4BEE@digisle.net> Date: Mon, 15 Apr 2002 13:23:55 -0700 From: Maksim Yevmenkin Organization: Digital Island X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-current@freebsd.org, freebsd-net@freebsd.org Subject: Bluetooth stack for FreeBSD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Apr 2002 20:24:03.0037 (UTC) FILETIME=[7BD098D0:01C1E4BB] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Folks, [probably should be cc'd to -mobile as well] An engineering release of Bluetooth stack for -current FreeBSD is available for download at http://www.geocities.com/m_evmenkin/ngbt-fbsd-20020415.tar.gz i'm interested to hear from people who familiar with FreeBSD kernel, Netgraph and/or Bluetooth. all your questions/comments/ suggestions are accepted and greatly appreciated. this is my first Netgraph stack, so please don't me hard :) thanks, max To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 15 16:40:35 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 8D11B37B405; Mon, 15 Apr 2002 16:40:09 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020415234008.VPQX1901.rwcrmhc52.attbi.com@InterJet.elischer.org>; Mon, 15 Apr 2002 23:40:08 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA88954; Mon, 15 Apr 2002 16:24:10 -0700 (PDT) Date: Mon, 15 Apr 2002 16:24:09 -0700 (PDT) From: Julian Elischer To: Maksim Yevmenkin Cc: freebsd-current@freebsd.org, freebsd-net@freebsd.org Subject: Re: Bluetooth stack for FreeBSD In-Reply-To: <3CBB36DB.850B4BEE@digisle.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi... I have been reading the (well actually, "looking at" may be more acurate.. some minor comments.. ng_btsocket.c: unmodified: line 674 sbappendrecord(&pcb->so->so_snd, m); m = m_dup(m, M_TRYWAIT); if (m == NULL) { error = ENOBUFS; goto drop1; } you are m_dup'ing an mbuf you have given away to the socket layer. on an SMP system this may already be destroyed by the time you do the m_dup() in fact if the sbappendrecord() fails due to a full queue, it may already be invalid... (I think) also all functions should be 'prototype format' e.g. static int ng_btsocket_peeraddr(so, nam) struct socket *so; struct sockaddr **nam; { should be: static int ng_btsocket_peeraddr(struct socket *so, struct sockaddr **nam) { also: __P() is now "deprecated" and should not be used in new code. Your idea of making a special bluetooth socket type, implemented by a Netgraph node is interesting. Maybe we should it easier to do this by extending the netgraph socket type with the ability to make sockets of arbitrary types... i.e. register a node type that acts as a 'subtype' of the 'socket' type, and inherrits generic socket behaviour, but allow the 'child type' to specify other parts to replace normal behaviour.. I guess we would need to see a few more cases of this done before we could deduce what is likely to be a good candidate for abstraction. you ask: /* * XXX FIXME/VERIFY i assume here that "hook" is a pointer * to the local hook we have received message from. For * L2CAP messages "hook" is required. */ This is true for 5.0 in 4.x there is no such thing as an arrival hook for a message. You should however not assume that it is non-NULL. test it in normal running code.. not in a KASSERT. There are transitional moments (during shutdown for example) when a message may arrive without a hook, in fact a malicious user might force that to happen at any time by simply send ing that message directly to the ID of the node. For messages passed by a neighbour via a hokk the hook field will be filled in but there are other ways that you may get a message. [out of time for now.. will read more later] Julian On Mon, 15 Apr 2002, Maksim Yevmenkin wrote: > Folks, > > [probably should be cc'd to -mobile as well] > > An engineering release of Bluetooth stack for -current FreeBSD > is available for download at > > http://www.geocities.com/m_evmenkin/ngbt-fbsd-20020415.tar.gz > > i'm interested to hear from people who familiar with FreeBSD > kernel, Netgraph and/or Bluetooth. all your questions/comments/ > suggestions are accepted and greatly appreciated. this is my > first Netgraph stack, so please don't me hard :) > > thanks, > max > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 15 16:46: 9 2002 Delivered-To: freebsd-net@freebsd.org Received: from mailtest.btconnex.net (mailtest.btconnex.net [209.47.192.8]) by hub.freebsd.org (Postfix) with SMTP id E8FCC37B400 for ; Mon, 15 Apr 2002 16:46:04 -0700 (PDT) Received: (qmail 48794 invoked from network); 15 Apr 2002 23:42:43 -0000 Received: from unknown (HELO ?192.168.66.55?) (192.168.66.55) by mailtest.btconnex.net with SMTP; 15 Apr 2002 23:42:43 -0000 Date: Mon, 15 Apr 2002 19:44:28 -0400 (EDT) From: Elliott Perrin X-X-Sender: To: Archie Cobbs Cc: "freebsd-net@FreeBSD.ORG" Subject: Re: mpd PPTP and NAT In-Reply-To: <200204122211.g3CMBko12496@arch20m.dellroad.org> Message-ID: <20020415193707.S20736-100000@decalpha.beanfield.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Apr 12, 2002: Archie Cobbs eloquently stated the following: > Archie Cobbs writes: > > > that is exactly what I am seeing, the clients are behind this stupid > > > little GVC IP0008 machine, and I am using your mpd software for the pptp > > > server. I know about the "BUG" in libalias. > > > > > > Is this part of the PPTP spec, that only one TCP control connection can be > > > open to an IP, or is it a purely libalias thing. > > > > Yes it is part of the PPTP spec.. however, I've seen servers > > that ignore the spec and accept multiple connections from a > > single remote source. Mpd should probably do the same thing > > when configured for 'server only' mode.. hmm, maybe I'll look > > into that (will send you a patch if/when). > > Please try the patch below and see if it works. > I haven't tested it at all myself.. > > Thanks, > -Archie > __________________________________________________________________________ > Archie Cobbs * Packet Design * http://www.packetdesign.com I definitely will.... I solved the problem for now, but not very elegant to say the least. I am using ipfilter round-robin rdr rules to map the public IP on this machine, to 10 private IP's on the internal NIC. I rewrote my mpd.conf to listen on these IP's instead, and it is working, but has not had a load thrown at it yet. I am going to apply this patch on another mpd machine I have running and see if it solves the problem. Then i can get rid of my nasty ipnat and ipf rules that i had to write to make it work. Thanks a bunch, will let you know in the next 1-2 days Regards, Elliott Perrin eperrin@beanfield.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 15 18:20:17 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id 27A9837B41C; Mon, 15 Apr 2002 18:20:09 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020416012008.QIKU1083.rwcrmhc53.attbi.com@InterJet.elischer.org>; Tue, 16 Apr 2002 01:20:08 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id SAA89304; Mon, 15 Apr 2002 18:04:38 -0700 (PDT) Date: Mon, 15 Apr 2002 18:04:37 -0700 (PDT) From: Julian Elischer To: Maksim Yevmenkin Cc: freebsd-current@freebsd.org, freebsd-net@freebsd.org Subject: Re: Bluetooth stack for FreeBSD In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 15 Apr 2002, Julian Elischer wrote: > > [out of time for now.. will read more later] > > Julian > ok, read a bit more: you say: 2) Locking/SMP External code now uses ng_send_fn to inject data into Netgraph, so it should be fine as long as Netgraph is SMP safe. Just need to verify it. yes this is correct While Netgraph is not completely SMP safe yet, this is only because there are several nodes that do not do what you do here. By doing it corectly here you have ensured that this will not be one of the nodes that needs to be reworked when this becomes important. (soon). Any node that changes it's internal state with reception of DATA (as opposed to control messages) should ensure that it by doing: NG_NODE_FORCE_WRITER(node); This is because in the default state, multiple data messages may (under SMP) be transitting the node at a time, as they only take out READER locks. If DATA can change some state variable or similar then this becomes unsafe, and they should be serialised. If only SOME data can do this, you have the option to takew reader-locks and only after confirming that a message is a writer, upgrade to a writer lock by 'requeueing' it as such. Alternatively teh sender can mark a packet as 'writer'. --- NG_NODE_PRIVATE(NG_HOOK_NODE(hook)) can be saved if you store information relavant to a hook in it's own private data pointer.. In some nodes I store the same data in NG_HOOK_PRIVATE(hook) as is in NG_NODE_PRIVATE(node), just to save the dereference if it's going to be done per packet. Sometimes there are better things to store there however.. --- /* Detach mbuf, discard item and process data */ NGI_GET_M(item, m); NG_FREE_ITEM(item); If there is any chance that you will need a new 'item' in a function or a child function, then it's worth keeping them around to save teh expense of re-allocating them.. I guess I shuld make a macro NG_FWD_DATA_HOOK() to make this easier to do.. -- > > > > On Mon, 15 Apr 2002, Maksim Yevmenkin wrote: > > > Folks, > > > > [probably should be cc'd to -mobile as well] > > > > An engineering release of Bluetooth stack for -current FreeBSD > > is available for download at > > > > http://www.geocities.com/m_evmenkin/ngbt-fbsd-20020415.tar.gz > > > > i'm interested to hear from people who familiar with FreeBSD > > kernel, Netgraph and/or Bluetooth. all your questions/comments/ > > suggestions are accepted and greatly appreciated. this is my > > first Netgraph stack, so please don't me hard :) > > > > thanks, > > max > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-current" in the body of the message > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 15 21:15: 5 2002 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 8537537B400 for ; Mon, 15 Apr 2002 21:15:02 -0700 (PDT) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id VAA47627; Mon, 15 Apr 2002 21:11:14 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g3G4A6926802; Mon, 15 Apr 2002 21:10:06 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200204160410.g3G4A6926802@arch20m.dellroad.org> Subject: Re: mpd & pptp problem In-Reply-To: "from Mattias Eriksson at Apr 15, 2002 11:34:18 am" To: Mattias Eriksson Date: Mon, 15 Apr 2002 21:10:06 -0700 (PDT) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Mattias Eriksson writes: > I am trying to establish a pptp-tunnel from a freebsd-server to a watchguard > firewall without any luck. > > I notice in the logfile that my server sends challenges and expects an > answer from the firewall. After that it fails. Try "set link disable chap". -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 16 0:40:33 2002 Delivered-To: freebsd-net@freebsd.org Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by hub.freebsd.org (Postfix) with ESMTP id 9898537B404 for ; Tue, 16 Apr 2002 00:40:10 -0700 (PDT) Received: by hanoi.cronyx.ru id LAA17847 for freebsd-net@FreeBSD.ORG.checked; (8.9.3/vak/2.1) Tue, 16 Apr 2002 11:38:02 +0400 (MSD) (envelope-from rik@cronyx.ru) Received: from cronyx.ru by hanoi.cronyx.ru with ESMTP id LAA17789; (8.9.3/vak/2.1) Tue, 16 Apr 2002 11:36:23 +0400 (MSD) (envelope-from rik@cronyx.ru) Message-ID: <3CBBD5AC.1000004@cronyx.ru> Date: Tue, 16 Apr 2002 11:41:32 +0400 From: Roman Kurakin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: freebsd-net@FreeBSD.ORG Cc: Julian Elischer Subject: Re: 5.Current Netgraph, Mutex References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I am workin with 5.Current branch and I have some problems while unloading my driver or better to say after it done all unload stuff. If I comment kernel options that allow better debuging of MUTEX (WITNESS*) all works, but if I turn them on I will get kernel fault. (sppp + witness also works with out any problems, only netgraph + witness leads to fault) Any suggestions? Best regards, Roman Kurakin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 16 1: 0:15 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id 6CC6937B405 for ; Tue, 16 Apr 2002 01:00:13 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020416080013.WNZ1083.rwcrmhc53.attbi.com@InterJet.elischer.org>; Tue, 16 Apr 2002 08:00:13 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id AAA90587; Tue, 16 Apr 2002 00:53:50 -0700 (PDT) Date: Tue, 16 Apr 2002 00:53:49 -0700 (PDT) From: Julian Elischer To: Roman Kurakin Cc: freebsd-net@FreeBSD.ORG Subject: Re: 5.Current Netgraph, Mutex In-Reply-To: <3CBBD5AC.1000004@cronyx.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I'm sorry I have not tried it for some time (a couple of months) I do not know what has been broken. I will try look tomorrow. It only uses mutex in a few places so I will hopefully find what has changed.. Can you give more information (e.g. stack trace?) On Tue, 16 Apr 2002, Roman Kurakin wrote: > Hi, > > I am workin with 5.Current branch and I have some problems while > unloading > my driver or better to say after it done all unload stuff. If I comment > kernel options > that allow better debuging of MUTEX (WITNESS*) all works, but if I turn > them on > I will get kernel fault. (sppp + witness also works with out any > problems, only > netgraph + witness leads to fault) Any suggestions? > > Best regards, > Roman Kurakin > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 16 10:51:59 2002 Delivered-To: freebsd-net@freebsd.org Received: from moebius2.Space.Net (moebius2.Space.Net [195.30.1.100]) by hub.freebsd.org (Postfix) with SMTP id D17A337B419 for ; Tue, 16 Apr 2002 10:51:54 -0700 (PDT) Received: (qmail 38837 invoked by uid 1013); 16 Apr 2002 17:51:53 -0000 Date: Tue, 16 Apr 2002 19:51:53 +0200 From: Markus Stumpf To: "Keiichi SHIMA / ?$BEg7D0l?(B" Cc: freebsd-net@FreeBSD.ORG Subject: Re: IPv6 configuration document? Message-ID: <20020416195153.U25964@Space.Net> References: <20020415.110753.50151185.keiichi@iij.ad.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020415.110753.50151185.keiichi@iij.ad.jp>; from keiichi@iij.ad.jp on Mon, Apr 15, 2002 at 11:07:53AM +0900 Organization: SpaceNet AG, Muenchen, Germany X-PGP-Fingerprint: 66 F3 75 79 01 D0 B8 5F 1A C7 77 88 4A B6 70 DF Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Apr 15, 2002 at 11:07:53AM +0900, Keiichi SHIMA / ?$BEg7D0l?(B wrote: > Does anyone know where is the document for configuring IPv6 on > FreeBSD, if any? The NetBSD web page has a really cool manual > (http://www.netbsd.org/Documentation/network/ipv6/) for IPv6 people > using NetBSD. I'm looking for such a document for FreBSD. Not exactly the same type of document, but http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ipv6.html made at least a start for me found it via google and it was "the best" within the first about 50 hits for my keywords. \Maex -- SpaceNet AG | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0 Research & Development | D-80807 Muenchen | Fax: +49 (89) 32356-299 "The security, stability and reliability of a computer system is reciprocally proportional to the amount of vacuity between the ears of the admin" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 16 12:21:18 2002 Delivered-To: freebsd-net@freebsd.org Received: from proton.hexanet.fr (proton.hexanet.fr [81.23.32.33]) by hub.freebsd.org (Postfix) with ESMTP id B08F637B405; Tue, 16 Apr 2002 12:21:13 -0700 (PDT) Received: from hexanet.fr (localhost [127.0.0.1]) by proton.hexanet.fr (8.11.6/8.11.6) with SMTP id g3GJLBc03195; Tue, 16 Apr 2002 21:21:11 +0200 (CEST) (envelope-from c.prevotaux@hexanet.fr) Date: Tue, 16 Apr 2002 21:21:10 +0200 From: Christophe Prevotaux To: "Arno J. Klaassen" Cc: freebsd-stable@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: ntp problems; am i the only one? Message-Id: <20020416212110.75881037.c.prevotaux@hexanet.fr> In-Reply-To: References: Organization: HEXANET Sarl X-Mailer: Sylpheed version 0.7.4 (GTK+ 1.2.10; i386-portbld-freebsd4.4) X-NCC-RegID: fr.hexanet Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 15 Apr 2002 02:04:42 +0200 "Arno J. Klaassen" wrote: > art form the classical > world-cycle on *part* of my boxes, but the problem exists on *all* > boxes. > This might be a firewall-issue of the university, but then, even > "ntpdate -v box-next-to-me" gives the sames behaviour. I do have the same problem -- =============================================================== Christophe Prevotaux Email: c.prevotaux@hexanet.fr HEXANET SARL URL: http://www.hexanet.fr/ Z.A.C Les Charmilles Tel: +33 (0)3 26 79 30 05 3 Allée Thierry Sabine Direct: +33 (0)3 26 79 08 02 BP202 Fax: +33 (0)3 26 79 30 06 51686 Reims Cedex 2 FRANCE HEXANET Network Operation Center =============================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 16 14:26:51 2002 Delivered-To: freebsd-net@freebsd.org Received: from owa1.digisle.com (ex-owa-sj.digisle.com [165.193.27.217]) by hub.freebsd.org (Postfix) with ESMTP id 8E0BC37B421; Tue, 16 Apr 2002 14:26:13 -0700 (PDT) Received: from digisle.net ([206.220.227.147] RDNS failed) by owa1.digisle.com over TLS secured channel with Microsoft SMTPSVC(5.0.2195.2966); Tue, 16 Apr 2002 14:26:12 -0700 Message-ID: <3CBC96F2.3032077A@digisle.net> Date: Tue, 16 Apr 2002 14:26:10 -0700 From: Maksim Yevmenkin Organization: Digital Island X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: freebsd-current@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Bluetooth stack for FreeBSD References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Apr 2002 21:26:12.0310 (UTC) FILETIME=[550C3F60:01C1E58D] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Julian, thanks for the comments, as always i found them very useful :) i have combined both e-mail into one and included my answers inline. > ng_btsocket.c: unmodified: line 674 > sbappendrecord(&pcb->so->so_snd, m); > m = m_dup(m, M_TRYWAIT); > if (m == NULL) { > error = ENOBUFS; > goto drop1; > } > > you are m_dup'ing an mbuf you have given away to the socket layer. > on an SMP system this may already be destroyed by the time > you do the m_dup() in fact if the sbappendrecord() fails > due to a full queue, it may already be invalid... fixed. thanks. > also all functions should be 'prototype format' > e.g. > static int > ng_btsocket_peeraddr(so, nam) > struct socket *so; > struct sockaddr **nam; > { > should be: > static int > ng_btsocket_peeraddr(struct socket *so, struct sockaddr **nam) > { > > also: > __P() is now "deprecated" and should not be used in new code. i should read style(9) more often. i fixed my code. > Your idea of making a special bluetooth socket type, implemented by > a Netgraph node is interesting. Maybe we should it easier to do this > by extending the netgraph socket type with the ability to > make sockets of arbitrary types... i.e. register a node type that acts > as a 'subtype' of the 'socket' type, and inherrits generic > socket behaviour, but allow the 'child type' to specify > other parts to replace normal behaviour.. I guess we would need to see a > few more cases of this done before we could deduce what is > likely to be a good candidate for abstraction. i must admit that current socket implementation is a mess :( my original plan was to use Netgraph sockets only and then write several user space libraries to perform actual connection. of course that idea had its own disadvantages. so i wrote sockets layer. i will try to clean up it a little bit (remove mutexes etc.) and also there probably should be support for HCI and raw L2CAP sockets as well. > you ask: > /* > * XXX FIXME/VERIFY i assume here that "hook" is a pointer > * to the local hook we have received message from. For > * L2CAP messages "hook" is required. > */ > > This is true for 5.0 > in 4.x there is no such thing as an arrival hook for a message. > You should however not assume that it is non-NULL. test it in > normal running code.. not in a KASSERT. fixed. > ok, read a bit more: > > [....] > > Any node that changes it's internal state with reception of DATA > (as opposed to control messages) should ensure that it by doing: > NG_NODE_FORCE_WRITER(node); > > This is because in the default state, multiple data messages may > (under SMP) be transitting the node at a time, as they > only take out READER locks. If DATA can change some state variable or > similar then this becomes unsafe, and they should be serialised. > If only SOME data can do this, you have the option to takew reader-locks > and only after confirming that a message is a writer, upgrade to a writer > lock by 'requeueing' it as such. Alternatively teh sender can mark a > packet as 'writer'. initially all nodes were WRITERs to "release the stack", but then i changed my strategy and now i'm serializing data at the edge of graph. for example both "bt3c" and "h4" nodes will NG_HOOK_FORCE_WRITER on upstream hook. also i probably should should turn WRITER bit on "ctl" hook for HCI node since it accepts data. L2CAP node accepts whole L2CAP packet from upstream hook, so (i think) it should be fine unless these packets gets re-ordered somehow. protocols that run over L2CAP may not like it. is it possible that SMP Netgraph can re-order data? if so then sockets node probably should turn WRITER bit on downstream hooks too. > NG_NODE_PRIVATE(NG_HOOK_NODE(hook)) > can be saved if you store information relavant to a hook in it's own > private data pointer.. > In some nodes I store the same data in NG_HOOK_PRIVATE(hook) > as is in NG_NODE_PRIVATE(node), just to save the dereference > if it's going to be done per packet. Sometimes there are better things to > store there however.. i'm sorry, but i'm not sure what do you mean here. i use such calls in several places (connect, disconnect, rcvdata) to get to the node private structure, but (i think) it just a macros that expanded to a couple pointer accesses. > /* Detach mbuf, discard item and process data */ > NGI_GET_M(item, m); > NG_FREE_ITEM(item); > > If there is any chance that you will need a new 'item' in a function or a > child function, then it's worth keeping them around to save teh expense of > re-allocating them.. > > I guess I shuld make a macro NG_FWD_DATA_HOOK() to make this easier to > do.. you right. i should not destroy item and use NG_FWD_ITEM_HOOK where required. again thank you for your comments, i'm looking forward to hear more :) thanks, max To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 16 16:40:38 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id C040E37B404; Tue, 16 Apr 2002 16:40:17 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020416234017.LBRI1901.rwcrmhc52.attbi.com@InterJet.elischer.org>; Tue, 16 Apr 2002 23:40:17 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA93950; Tue, 16 Apr 2002 16:35:51 -0700 (PDT) Date: Tue, 16 Apr 2002 16:35:51 -0700 (PDT) From: Julian Elischer To: Maksim Yevmenkin Cc: freebsd-current@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Bluetooth stack for FreeBSD In-Reply-To: <3CBC96F2.3032077A@digisle.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, 16 Apr 2002, Maksim Yevmenkin wrote: > > initially all nodes were WRITERs to "release the stack", but then i > changed my strategy and now i'm serializing data at the edge of graph. > for example both "bt3c" and "h4" nodes will NG_HOOK_FORCE_WRITER on > upstream hook. also i probably should should turn WRITER bit on "ctl" > hook for HCI node since it accepts data. L2CAP node accepts whole > L2CAP packet from upstream hook, so (i think) it should be fine unless > these packets gets re-ordered somehow. protocols that run over L2CAP > may not like it. > > is it possible that SMP Netgraph can re-order data? if so then sockets > node probably should turn WRITER bit on downstream hooks too. it is not likely that data is re-ordered, but remember that data may enter the graph from different edge nodes simultaneously on different processors so that a single node may be processing both incoming and outgoing data at the same time unless the node itself is marked as needing a writer lock. > > > NG_NODE_PRIVATE(NG_HOOK_NODE(hook)) > > can be saved if you store information relavant to a hook in it's own > > private data pointer.. > > In some nodes I store the same data in NG_HOOK_PRIVATE(hook) > > as is in NG_NODE_PRIVATE(node), just to save the dereference > > if it's going to be done per packet. Sometimes there are better things to > > store there however.. > > i'm sorry, but i'm not sure what do you mean here. i use such calls > in several places (connect, disconnect, rcvdata) to get to the node > private structure, but (i think) it just a macros that expanded to a > couple pointer accesses. It's not a serious comment. just that you should be aware that one can sometimes simplify code by using the per-hook private information as well. > > > /* Detach mbuf, discard item and process data */ > > NGI_GET_M(item, m); > > NG_FREE_ITEM(item); > > > > If there is any chance that you will need a new 'item' in a function or a > > child function, then it's worth keeping them around to save teh expense of > > re-allocating them.. > > > > I guess I shuld make a macro NG_FWD_DATA_HOOK() to make this easier to > > do.. > > you right. i should not destroy item and use NG_FWD_ITEM_HOOK where > required. > Netgraph is not an unchangeable work.. If you have comments on things that may mek it easier to do what you need then please let us (archie & me) know.. > again thank you for your comments, i'm looking forward to hear more :) > thanks, > max > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 17 1:14:50 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.baerum.kommune.no (mail.baerum.kommune.no [195.134.40.62]) by hub.freebsd.org (Postfix) with SMTP id 4D19A37B416 for ; Wed, 17 Apr 2002 01:14:45 -0700 (PDT) Received: from SA-D01-Message_Server by mail.baerum.kommune.no with Novell_GroupWise; Wed, 17 Apr 2002 10:14:21 +0200 Message-Id: X-Mailer: Novell GroupWise 5.5.2 Date: Wed, 17 Apr 2002 10:14:11 +0200 From: "Idar Tollefsen" To: Subject: How to set up a gateway? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello, I have a machine running FreeBSD 4.5 STABLE. This machine has two NICs in it, one connected to the internal LAN and one connected to a ADSL modem (I'm using PPPoE). I've successfully managed to set them up so that the FreeBSD machine has access to the Internet, that works flawlessly, but I'm not able to get this machine to act as a gateway for other computers on my network. For the time being, internal IP addresses are used, but real once will be put in place in the not so distant future. I've done the following: rc.conf: PPP_NAT=3D"YES" ENABLE_GATWAY=3D"YES" ppp.conf: nat enable yes I've compiled netgraph into the kernel (NETGRAPH, NETGRAPH_EHTER, NETGRAPH_SOCKET). Of the two NICs, only the one connected to the LAN is configured during startup. The ADSL connection is also established during startup and tun0 is added as the default gateway interface. I don't have a firewall running (yet). I have a DNS server on this machine, and other machines can successfully lookup hostnames. But when I tell them that they should use the FreeBSD machine as a gateway, they simply time out when trying to connect to something outside of the LAN. Any idea what I'm forgetting or doing wrong? - IT To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 17 1:33:48 2002 Delivered-To: freebsd-net@freebsd.org Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by hub.freebsd.org (Postfix) with ESMTP id 9FE8A37B41B for ; Wed, 17 Apr 2002 01:31:12 -0700 (PDT) Received: by hanoi.cronyx.ru id MAA20075 for freebsd-net@FreeBSD.ORG.checked; (8.9.3/vak/2.1) Wed, 17 Apr 2002 12:29:03 +0400 (MSD) (envelope-from rik@cronyx.ru) Received: from cronyx.ru by hanoi.cronyx.ru with ESMTP id MAA19970; (8.9.3/vak/2.1) Wed, 17 Apr 2002 12:26:20 +0400 (MSD) (envelope-from rik@cronyx.ru) Message-ID: <3CBD32E3.1060808@cronyx.ru> Date: Wed, 17 Apr 2002 12:31:31 +0400 From: Roman Kurakin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Julian Elischer Cc: freebsd-net@FreeBSD.ORG Subject: Re: 5.Current Netgraph, Mutex References: Content-Type: multipart/mixed; boundary="------------090508090207000700080608" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a multi-part message in MIME format. --------------090508090207000700080608 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, Call stack looks like this: witness_destroy mtx_destroy fdtree exit1 sys_exit syscall syscall_with_err_pushed This is all information I have at that moment. I could also send full texts of driver. I also have question about ng_rmtype (&typestruct) function. It seems that no one uses it. Thus all driver are broken as modules. Best regards, Roman Kurakin Julian Elischer wrote: >I'm sorry I have not tried it for some time (a couple of months) >I do not know what has been broken. > >I will try look tomorrow. >It only uses mutex in a few places so I will hopefully find what has >changed.. > >Can you give more information (e.g. stack trace?) > >On Tue, 16 Apr 2002, Roman Kurakin wrote: > >>Hi, >> >> I am workin with 5.Current branch and I have some problems while >>unloading >>my driver or better to say after it done all unload stuff. If I comment >>kernel options >>that allow better debuging of MUTEX (WITNESS*) all works, but if I turn >>them on >>I will get kernel fault. (sppp + witness also works with out any >>problems, only >>netgraph + witness leads to fault) Any suggestions? >> >>Best regards, >> Roman Kurakin >> >> >> >> >> > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-net" in the body of the message > > --------------090508090207000700080608 Content-Type: text/plain; name="if_cp.c" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="if_cp.c" /* * Cronyx-Tau-PCI adapter driver for FreeBSD. * Supports PPP/HDLC, Cisco/HDLC and FrameRelay protocol in synchronous mode, * and asyncronous channels with full modem control. * Keepalive protocol implemented in both Cisco and PPP modes. * * Copyright (C) 1999-2002 Cronyx Engineering Ltd. * Authors: * Kurakin Roman, * Serge Vakulenko, * * This software is distributed with NO WARRANTIES, not even the implied * warranties for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. * * Authors grant any other persons or organisations permission to use * or modify this software as long as this message is kept with the software, * all derivative works or modified versions. */ #include "pci.h" #if NPCI > 0 #include #include #include #include #include #include #include #include #include #include #include #if __FreeBSD_version >= 400000 #include #endif #include #include #include #include #include #include #if __FreeBSD_version >= 500000 # include # include #else # include # include #endif #include #include #include #include #include "opt_ng_cronyx.h" #ifdef NETGRAPH_CRONYX # include "opt_netgraph.h" # ifndef NETGRAPH # error #option NETGRAPH missed from configuration # endif # include # include # if __FreeBSD_version >= 500000 # include # else # include # endif #else # if __FreeBSD_version <= 500000 # include "sppp.h" # if NSPPP <= 0 # error The device cp requires sppp or netgraph. # endif # endif # include # include # define PP_CISCO IFF_LINK2 #if __FreeBSD_version < 400000 # include # if NBPFILTER > 0 # include # endif #else # include # include # define NBPFILTER NBPF #endif #endif #define DEBUG(d,s) ({if (d->chan->debug) {\ printf ("%s: ", d->name); printf s;}}) #define DEBUG2(d,s) ({if (d->chan->debug>1) {\ printf ("%s: ", d->name); printf s;}}) #define CDEV_MAJOR 134 #if __FreeBSD_version >= 400000 static int cp_probe __P((device_t)); static int cp_attach __P((device_t)); static int cp_detach __P((device_t)); static device_method_t cp_methods[] = { /* Device interface */ DEVMETHOD(device_probe, cp_probe), DEVMETHOD(device_attach, cp_attach), DEVMETHOD(device_detach, cp_detach), {0, 0} }; typedef struct _bdrv_t { cp_board_t *board; struct resource *cp_res; struct resource *cp_irq; void *cp_intrhand; } bdrv_t; static driver_t cp_driver = { "cp", cp_methods, sizeof(bdrv_t), }; static devclass_t cp_devclass; #endif typedef struct _drv_t { char name [8]; cp_chan_t *chan; cp_board_t *board; cp_buf_t buf; int running; #ifdef NETGRAPH char nodename [NG_NODELEN+1]; hook_p hook; hook_p debug_hook; node_p node; struct ifqueue queue; struct ifqueue hi_queue; short timeout; struct callout_handle timeout_handle; #else struct sppp pp; #endif #if __FreeBSD_version >= 400000 dev_t devt; #endif } drv_t; static void cp_receive (cp_chan_t *c, char *data, int len); static void cp_transmit (cp_chan_t *c, void *attachment, int len); static void cp_error (cp_chan_t *c, int data); static void cp_up (drv_t *d); static void cp_start (drv_t *d); static void cp_down (drv_t *d); static void cp_watchdog (drv_t *d); #ifdef NETGRAPH extern struct ng_type typestruct; #else static void cp_ifstart (struct ifnet *ifp); static void cp_tlf (struct sppp *sp); static void cp_tls (struct sppp *sp); static void cp_ifwatchdog (struct ifnet *ifp); static int cp_sioctl (struct ifnet *ifp, u_long cmd, caddr_t data); static void cp_initialize (void *softc); #endif static cp_board_t *adapter [NBRD]; static drv_t *channel [NBRD*NCHAN]; static cp_qbuf_t queue [NBRD]; static struct callout_handle led_timo [NBRD]; static struct callout_handle timeout_handle; static int cp_destroy = 0; /* * Print the mbuf chain, for debug purposes only. */ static void printmbuf (struct mbuf *m) { printf ("mbuf:"); for (; m; m=m->m_next) { if (m->m_flags & M_PKTHDR) printf (" HDR %d:", m->m_pkthdr.len); if (m->m_flags & M_EXT) printf (" EXT:"); printf (" %d", m->m_len); } printf ("\n"); } /* * Make an mbuf from data. */ static struct mbuf *makembuf (void *buf, unsigned len) { struct mbuf *m; MGETHDR (m, M_DONTWAIT, MT_DATA); if (! m) return 0; MCLGET (m, M_DONTWAIT); if (! (m->m_flags & M_EXT)) { m_freem (m); return 0; } m->m_pkthdr.len = m->m_len = len; bcopy (buf, mtod (m, caddr_t), len); return m; } #if __FreeBSD_version < 400000 static const char *cp_probe (pcici_t tag, pcidi_t type) { if (tag->vendor == cp_vendor_id && tag->device == cp_device_id) return "Cronyx-Tau-PCI serial adapter"; return 0; } #else static int cp_probe (device_t dev) { if ((pci_get_vendor (dev) == cp_vendor_id) && (pci_get_device (dev) == cp_device_id)) { device_set_desc (dev, "Cronyx-Tau-PCI serial adapter"); return 0; } return ENXIO; } #endif static void cp_timeout (void *arg) { drv_t *d; int s, i; for (i=0; ichan->type != T_G703) { splx (s); continue; } cp_g703_timer (d->chan); splx (s); } s = splimp (); if (!cp_destroy) timeout_handle = timeout (cp_timeout, 0, hz); splx (s); } static void cp_led_off (void *arg) { cp_board_t *b = arg; int s = splimp (); if (cp_destroy) { splx (s); return; } cp_led (b, 0); led_timo[b->num].callout = 0; splx (s); } static void cp_intr (void *arg) { #if __FreeBSD_version < 400000 cp_board_t *b = arg; #else bdrv_t *bd = arg; cp_board_t *b = bd->board; #endif int s = splimp (); if (cp_destroy) { splx (s); return; } /* Turn LED on. */ cp_led (b, 1); cp_interrupt (b); /* Turn LED off 50 msec later. */ if (!led_timo[b->num].callout) led_timo[b->num] = timeout (cp_led_off, b, hz/20); splx (s); } extern struct cdevsw cp_cdevsw; /* * Called if the probe succeeded. */ #if __FreeBSD_version < 400000 static void cp_attach (pcici_t tag, int unit) { vm_offset_t pbase; #else static int cp_attach (device_t dev) { bdrv_t *bd = device_get_softc (dev); int unit = device_get_unit (dev); int rid, error; #endif vm_offset_t vbase; cp_board_t *b; cp_chan_t *c; drv_t *d; int s = splimp (); b = malloc (sizeof(cp_board_t), M_DEVBUF, M_WAITOK); adapter[unit] = b; bzero (b, sizeof(cp_board_t)); #if __FreeBSD_version < 400000 if (! pci_map_mem (tag, PCIR_MAPS, &vbase, &pbase)) { printf ("cp%d: cannot map memory\n", unit); free (b, M_DEVBUF); splx (s); return; } #else bd->board = b; b->sys = bd; rid = PCIR_MAPS; bd->cp_res = bus_alloc_resource (dev, SYS_RES_MEMORY, &rid, 0, ~0, 1, RF_ACTIVE); if (! bd->cp_res) { printf ("cp%d: cannot map memory\n", unit); free (b, M_DEVBUF); splx (s); return (ENXIO); } vbase = (vm_offset_t) rman_get_virtual (bd->cp_res); #endif cp_init (b, unit, (u_char*) vbase); cp_reset (b, queue+unit, vtophys (queue+unit)); #if __FreeBSD_version < 400000 if (! pci_map_int (tag, cp_intr, b, &net_imask)) printf ("cp%d: cannot map interrupt\n", unit); #else rid = 0; bd->cp_irq = bus_alloc_resource (dev, SYS_RES_IRQ, &rid, 0, ~0, 1, RF_SHAREABLE | RF_ACTIVE); if (! bd->cp_irq) { printf ("cp%d: cannot map interrupt\n", unit); bus_release_resource (dev, SYS_RES_MEMORY, PCIR_MAPS, bd->cp_res); free (b, M_DEVBUF); splx (s); return (ENXIO); } error = bus_setup_intr (dev, bd->cp_irq, INTR_TYPE_NET, cp_intr, bd, &bd->cp_intrhand); if (error) { printf ("cp%d: cannot set up irq\n", unit); bus_release_resource (dev, SYS_RES_MEMORY, PCIR_MAPS, bd->cp_res); bus_release_resource (dev, SYS_RES_IRQ, 0, bd->cp_irq); free (b, M_DEVBUF); splx (s); return (ENXIO); } #endif printf ("cp%d: %s, clock %ld MHz\n", unit, b->name, b->osc / 1000000); for (c=b->chan; cchan+NCHAN; ++c) { if (! c->type) continue; d = contigmalloc (sizeof(drv_t), M_DEVBUF, M_WAITOK, 0x100000, 0xffffffff, 16, 0); channel [b->num*NCHAN + c->num] = d; bzero (d, sizeof(drv_t)); sprintf (d->name, "cp%d.%d", b->num, c->num); d->board = b; d->chan = c; c->sys = d; #ifdef NETGRAPH if (ng_make_node_common (&typestruct, &d->node) != 0) { printf ("%s: cannot make common node\n", d->name); d->node = NULL; continue; } #if __FreeBSD_version >= 500000 NG_NODE_SET_PRIVATE (d->node, d); #else d->node->private = d; #endif sprintf (d->nodename, "%s%d", NG_CP_NODE_TYPE, c->board->num*NCHAN + c->num); if (ng_name_node (d->node, d->nodename)) { printf ("%s: cannot name node\n", d->nodename); #if __FreeBSD_version >= 500000 NG_NODE_UNREF (d->node); #else ng_rmnode (d->node); ng_unref (d->node); #endif continue; } d->queue.ifq_maxlen = IFQ_MAXLEN; d->hi_queue.ifq_maxlen = IFQ_MAXLEN; #if __FreeBSD_version >= 500000 mtx_init (&d->queue.ifq_mtx, "cp_queue", MTX_DEF); mtx_init (&d->hi_queue.ifq_mtx, "cp_queue_hi", MTX_DEF); #endif #else /*NETGRAPH*/ d->pp.pp_if.if_softc = d; d->pp.pp_if.if_unit = b->num * NCHAN + c->num; d->pp.pp_if.if_name = "cp"; d->pp.pp_if.if_mtu = PP_MTU; d->pp.pp_if.if_flags = IFF_POINTOPOINT | IFF_MULTICAST; d->pp.pp_if.if_ioctl = cp_sioctl; d->pp.pp_if.if_start = cp_ifstart; d->pp.pp_if.if_watchdog = cp_ifwatchdog; d->pp.pp_if.if_init = cp_initialize; sppp_attach (&d->pp.pp_if); if_attach (&d->pp.pp_if); d->pp.pp_tlf = cp_tlf; d->pp.pp_tls = cp_tls; #if __FreeBSD_version >= 400000 || NBPFILTER > 0 /* If BPF is in the kernel, call the attach for it. * The header size of PPP or Cisco/HDLC is 4 bytes. */ bpfattach (&d->pp.pp_if, DLT_PPP, 4); #endif #endif /*NETGRAPH*/ cp_start_e1 (c); cp_start_chan (c, 1, 1, &d->buf, vtophys (&d->buf)); /* Register callback functions. */ cp_register_transmit (c, &cp_transmit); cp_register_receive (c, &cp_receive); cp_register_error (c, &cp_error); #if __FreeBSD_version >= 400000 d->devt = make_dev (&cp_cdevsw, b->num*NCHAN+c->num, UID_ROOT, GID_WHEEL, 0600, "cp%d", b->num*NCHAN+c->num); #endif } splx (s); #if __FreeBSD_version >= 400000 return 0; #endif } #if __FreeBSD_version >= 400000 static int cp_detach (device_t dev) { bdrv_t *bd = device_get_softc (dev); cp_board_t *b = bd->board; cp_chan_t *c; int s = splimp (); /* Check if the device is busy (open). */ for (c=b->chan; cchan+NCHAN; ++c) { drv_t *d = (drv_t*) c->sys; if (! d || ! d->chan->type) continue; if (d->running) { splx (s); return EBUSY; } } /* Ok, we can unload driver */ /* At first we should stop all channels */ for (c=b->chan; cchan+NCHAN; ++c) { drv_t *d = (drv_t*) c->sys; if (! d || ! d->chan->type) continue; cp_stop_chan (c); cp_stop_e1 (c); cp_set_dtr (d->chan, 0); cp_set_rts (d->chan, 0); } /* Reset the adapter. */ cp_destroy = 1; cp_interrupt_poll (b, 1); cp_led_off (b); if (led_timo[b->num].callout) untimeout (cp_led_off, b, led_timo[b->num]); for (c=b->chan; cchan+NCHAN; ++c) { drv_t *d = (drv_t*) c->sys; if (! d || ! d->chan->type) continue; #ifndef NETGRAPH #if __FreeBSD_version >= 410000 && NBPFILTER > 0 /* Detach from the packet filter list of interfaces. */ bpfdetach (&d->pp.pp_if); #endif /* Detach from the sync PPP list. */ sppp_detach (&d->pp.pp_if); /* Detach from the system list of interfaces. */ if_detach (&d->pp.pp_if); #else #if __FreeBSD_version >= 500000 if (d->node) { ng_rmnode_self (d->node); NG_NODE_UNREF (d->node); d->node = NULL; } #endif #endif #if __FreeBSD_version >= 400000 destroy_dev (d->devt); #endif } /* Disable the interrupt request. */ bus_teardown_intr (dev, bd->cp_irq, bd->cp_intrhand); bus_deactivate_resource (dev, SYS_RES_IRQ, 0, bd->cp_irq); bus_release_resource (dev, SYS_RES_IRQ, 0, bd->cp_irq); bus_release_resource (dev, SYS_RES_MEMORY, PCIR_MAPS, bd->cp_res); cp_led_off (b); if (led_timo[b->num].callout) untimeout (cp_led_off, b, led_timo[b->num]); splx (s); s = splimp (); for (c=b->chan; cchan+NCHAN; ++c) { drv_t *d = (drv_t*) c->sys; if (! d || ! d->chan->type) continue; channel [b->num*NCHAN + c->num] = 0; /* Deallocate buffers. */ contigfree (d, sizeof (*d), M_DEVBUF); } adapter [b->num] = 0; free (b, M_DEVBUF); splx (s); return 0; } #endif #if __FreeBSD_version < 400000 static u_long cp_count; static struct pci_device cp_driver = {"cp", cp_probe, cp_attach, &cp_count, 0}; DATA_SET (pcidevice_set, cp_driver); #endif #ifndef NETGRAPH static void cp_ifstart (struct ifnet *ifp) { drv_t *d = ifp->if_softc; cp_start (d); } static void cp_ifwatchdog (struct ifnet *ifp) { drv_t *d = ifp->if_softc; cp_watchdog (d); } static void cp_tlf (struct sppp *sp) { drv_t *d = sp->pp_if.if_softc; DEBUG2 (d, ("cp_tlf\n")); /* cp_set_dtr (d->chan, 0);*/ /* cp_set_rts (d->chan, 0);*/ sp->pp_down (sp); } static void cp_tls (struct sppp *sp) { drv_t *d = sp->pp_if.if_softc; DEBUG2 (d, ("cp_tls\n")); sp->pp_up (sp); } /* * Process an ioctl request. */ static int cp_sioctl (struct ifnet *ifp, u_long cmd, caddr_t data) { drv_t *d = ifp->if_softc; int error, was_up, should_be_up; was_up = (ifp->if_flags & IFF_RUNNING) != 0; error = sppp_ioctl (ifp, cmd, data); if (error) return error; if (! (ifp->if_flags & IFF_DEBUG)) d->chan->debug = 0; else if (! d->chan->debug) d->chan->debug = 1; switch (cmd) { default: DEBUG2 (d, ("ioctl 0x%lx\n", cmd)); return 0; case SIOCADDMULTI: DEBUG2 (d, ("ioctl SIOCADDMULTI\n")); return 0; case SIOCDELMULTI: DEBUG2 (d, ("ioctl SIOCDELMULTI\n")); return 0; case SIOCSIFFLAGS: DEBUG2 (d, ("ioctl SIOCSIFFLAGS\n")); break; case SIOCSIFADDR: DEBUG2 (d, ("ioctl SIOCSIFADDR\n")); break; } /* We get here only in case of SIFFLAGS or SIFADDR. */ should_be_up = (ifp->if_flags & IFF_RUNNING) != 0; if (! was_up && should_be_up) { /* Interface goes up -- start it. */ cp_up (d); cp_start (d); } else if (was_up && ! should_be_up) { /* Interface is going down -- stop it. */ /* if ((ifp->if_flags & PP_CISCO))*/ cp_down (d); } return 0; } /* * Initialization of interface. * It seems to be never called by upper level? */ static void cp_initialize (void *softc) { drv_t *d = softc; DEBUG (d, ("cp_initialize\n")); } #endif /*NETGRAPH*/ /* * Stop the interface. Called on splimp(). */ static void cp_down (drv_t *d) { int s = splimp (); DEBUG (d, ("cp_down\n")); /* Interface is going down -- stop it. */ cp_set_dtr (d->chan, 0); cp_set_rts (d->chan, 0); d->running = 0; splx (s); } /* * Start the interface. Called on splimp(). */ static void cp_up (drv_t *d) { int s = splimp (); DEBUG (d, ("cp_up\n")); cp_set_dtr (d->chan, 1); cp_set_rts (d->chan, 1); d->running = 1; splx (s); } /* * Start output on the interface. Get another datagram to send * off of the interface queue, and copy it to the interface * before starting the output. */ static void cp_send (drv_t *d) { struct mbuf *m; u_short len; DEBUG2 (d, ("cp_send, tn=%d te=%d\n", d->chan->tn, d->chan->te)); /* No output if the interface is down. */ if (! d->running) return; /* No output if the modem is off. */ if (! (d->chan->lloop || d->chan->type != T_SERIAL || cp_get_dsr (d->chan))) return; while (cp_transmit_space (d->chan)) { /* Get the packet to send. */ #ifdef NETGRAPH IF_DEQUEUE (&d->hi_queue, m); if (! m) IF_DEQUEUE (&d->queue, m); #else m = sppp_dequeue (&d->pp.pp_if); #endif if (! m) return; #if (__FreeBSD_version >= 400000 || NBPFILTER > 0) && !defined (NETGRAPH) if (d->pp.pp_if.if_bpf) bpf_mtap (&d->pp.pp_if, m); #endif len = m->m_pkthdr.len; if (len >= BUFSZ) printf ("%s: too long packet: %d bytes: ", d->name, len); else if (! m->m_next) cp_send_packet (d->chan, (u_char*) mtod (m, caddr_t), len, 0); else { u_char *buf = d->chan->tbuf[d->chan->te]; m_copydata (m, 0, len, buf); cp_send_packet (d->chan, buf, len, 0); } m_freem (m); /* Set up transmit timeout, if the transmit ring is not empty.*/ #ifdef NETGRAPH d->timeout = 10; #else d->pp.pp_if.if_timer = 10; #endif } #ifndef NETGRAPH d->pp.pp_if.if_flags |= IFF_OACTIVE; #endif } /* * Start output on the interface. * Always called on splimp(). */ static void cp_start (drv_t *d) { int s = splimp (); if (d->running) { if (! d->chan->dtr) cp_set_dtr (d->chan, 1); if (! d->chan->rts) cp_set_rts (d->chan, 1); cp_send (d); } splx (s); } /* * Handle transmit timeouts. * Recover after lost transmit interrupts. * Always called on splimp(). */ static void cp_watchdog (drv_t *d) { int s; DEBUG (d, ("device timeout\n")); if (d->running) { s = splimp (); cp_stop_chan (d->chan); cp_stop_e1 (d->chan); cp_start_e1 (d->chan); cp_start_chan (d->chan, 1, 1, 0, 0); cp_set_dtr (d->chan, 1); cp_set_rts (d->chan, 1); splx (s); cp_start (d); } } static void cp_transmit (cp_chan_t *c, void *attachment, int len) { drv_t *d = c->sys; #ifdef NETGRAPH d->timeout = 0; #else ++d->pp.pp_if.if_opackets; d->pp.pp_if.if_flags &= ~IFF_OACTIVE; d->pp.pp_if.if_timer = 0; #endif cp_start (d); } static void cp_receive (cp_chan_t *c, char *data, int len) { drv_t *d = c->sys; struct mbuf *m; #if __FreeBSD_version >= 500000 && defined NETGRAPH int error; #endif if (! d->running) return; m = makembuf (data, len); if (! m) { DEBUG (d, ("no memory for packet\n")); #ifndef NETGRAPH ++d->pp.pp_if.if_iqdrops; #endif return; } if (c->debug > 1) printmbuf (m); #ifdef NETGRAPH m->m_pkthdr.rcvif = 0; #if __FreeBSD_version >= 500000 NG_SEND_DATA_ONLY (error, d->hook, m); #else ng_queue_data (d->hook, m, 0); #endif #else ++d->pp.pp_if.if_ipackets; m->m_pkthdr.rcvif = &d->pp.pp_if; #if __FreeBSD_version >= 400000 || NBPFILTER > 0 /* Check if there's a BPF listener on this interface. * If so, hand off the raw packet to bpf. */ if (d->pp.pp_if.if_bpf) bpf_tap (&d->pp.pp_if, data, len); #endif sppp_input (&d->pp.pp_if, m); #endif } static void cp_error (cp_chan_t *c, int data) { drv_t *d = c->sys; switch (data) { case CP_FRAME: DEBUG (d, ("frame error\n")); #ifndef NETGRAPH ++d->pp.pp_if.if_ierrors; #endif break; case CP_CRC: DEBUG (d, ("crc error\n")); #ifndef NETGRAPH ++d->pp.pp_if.if_ierrors; #endif break; case CP_OVERRUN: DEBUG (d, ("overrun error\n")); #ifndef NETGRAPH ++d->pp.pp_if.if_collisions; ++d->pp.pp_if.if_ierrors; #endif break; case CP_OVERFLOW: DEBUG (d, ("overflow error\n")); #ifndef NETGRAPH ++d->pp.pp_if.if_ierrors; #endif break; case CP_UNDERRUN: DEBUG (d, ("underrun error\n")); #ifdef NETGRAPH d->timeout = 0; #else ++d->pp.pp_if.if_oerrors; d->pp.pp_if.if_flags &= ~IFF_OACTIVE; d->pp.pp_if.if_timer = 0; #endif cp_start (d); break; default: DEBUG (d, ("error #%d\n", data)); break; } } /* * You also need read, write, open, close routines. * This should get you started */ #if __FreeBSD_version < 500000 static int cp_open (dev_t dev, int oflags, int devtype, struct proc *p) #else static int cp_open (dev_t dev, int oflags, int devtype, struct thread *td) #endif { int unit = minor (dev); drv_t *d; if (unit >= NBRD*NCHAN || ! (d = channel[unit])) return ENXIO; DEBUG2 (d, ("cp_open\n")); return 0; } /* * Only called on the LAST close. */ #if __FreeBSD_version < 500000 static int cp_close (dev_t dev, int fflag, int devtype, struct proc *p) #else static int cp_close (dev_t dev, int fflag, int devtype, struct thread *td) #endif { drv_t *d = channel [minor (dev)]; DEBUG2 (d, ("cp_close\n")); return 0; } static int cp_modem_status (cp_chan_t *c) { drv_t *d = c->sys; int status, s; status = d->running ? TIOCM_LE : 0; s = splimp (); if (cp_get_cd (c)) status |= TIOCM_CD; if (cp_get_cts (c)) status |= TIOCM_CTS; if (cp_get_dsr (c)) status |= TIOCM_DSR; if (c->dtr) status |= TIOCM_DTR; if (c->rts) status |= TIOCM_RTS; splx (s); return status; } #if __FreeBSD_version < 500000 static int cp_ioctl (dev_t dev, u_long cmd, caddr_t data, int flag, struct proc *p) #else static int cp_ioctl (dev_t dev, u_long cmd, caddr_t data, int flag, struct thread *td) #endif { drv_t *d = channel [minor (dev)]; cp_chan_t *c = d->chan; struct serial_statistics *st; struct e1_statistics *opte1; int error, s; char mask[16]; switch (cmd) { case SERIAL_GETREGISTERED: DEBUG2 (d, ("ioctl: getregistered\n")); bzero (mask, sizeof(mask)); for (s=0; spp.pp_if.if_flags & PP_CISCO) ? "cisco" : "ppp"); return 0; case SERIAL_SETPROTO: DEBUG2 (d, ("ioctl: setproto\n")); /* Only for superuser! */ #if __FreeBSD_version < 400000 error = suser (p->p_ucred, &p->p_acflag); #elif __FreeBSD_version < 500000 error = suser (p); #else error = suser_td (td); #endif if (error) return error; if (d->pp.pp_if.if_flags & IFF_RUNNING) return EBUSY; if (! strcmp ("cisco", (char*)data)) { d->pp.pp_flags |= PP_KEEPALIVE; d->pp.pp_if.if_flags |= PP_CISCO; } else if (! strcmp ("ppp", (char*)data)) { d->pp.pp_flags &= ~(PP_KEEPALIVE); d->pp.pp_if.if_flags &= ~(PP_CISCO); } else return EINVAL; return 0; case SERIAL_GETKEEPALIVE: DEBUG2 (d, ("ioctl: getkeepalive\n")); if ((d->pp.pp_if.if_flags & PP_CISCO)) return EINVAL; *(int*)data = (d->pp.pp_flags & PP_KEEPALIVE) ? 1 : 0; return 0; case SERIAL_SETKEEPALIVE: DEBUG2 (d, ("ioctl: setkeepalive\n")); /* Only for superuser! */ #if __FreeBSD_version < 400000 error = suser (p->p_ucred, &p->p_acflag); #elif __FreeBSD_version < 500000 error = suser (p); #else error = suser_td (td); #endif if (error) return error; if ((d->pp.pp_if.if_flags & PP_CISCO)) return EINVAL; s = splimp (); if (*(int*)data) d->pp.pp_flags |= PP_KEEPALIVE; else d->pp.pp_flags &= ~PP_KEEPALIVE; splx (s); return 0; #endif /*NETGRAPH*/ case SERIAL_GETMODE: DEBUG2 (d, ("ioctl: getmode\n")); *(int*)data = SERIAL_HDLC; return 0; case SERIAL_SETMODE: /* Only for superuser! */ #if __FreeBSD_version < 400000 error = suser (p->p_ucred, &p->p_acflag); #elif __FreeBSD_version < 500000 error = suser (p); #else error = suser_td (td); #endif if (error) return error; if (c->type != T_E1) return EINVAL; if (*(int*)data != SERIAL_HDLC) return EINVAL; return 0; case SERIAL_GETCFG: DEBUG2 (d, ("ioctl: getcfg\n")); if (c->type != T_E1 || c->unfram) return EINVAL; *(char*)data = c->board->mux ? 'c' : 'a'; return 0; case SERIAL_SETCFG: DEBUG2 (d, ("ioctl: setcfg\n")); #if __FreeBSD_version < 400000 error = suser (p->p_ucred, &p->p_acflag); #elif __FreeBSD_version < 500000 error = suser (p); #else error = suser_td (td); #endif if (error) return error; if (c->type != T_E1) return EINVAL; s = splimp (); cp_set_mux (c->board, *((char*)data) == 'c'); splx (s); return 0; case SERIAL_GETSTAT: DEBUG2 (d, ("ioctl: getstat\n")); st = (struct serial_statistics*) data; st->rintr = c->rintr; st->tintr = c->tintr; st->mintr = 0; st->ibytes = c->ibytes; st->ipkts = c->ipkts; st->obytes = c->obytes; st->opkts = c->opkts; st->ierrs = c->overrun + c->frame + c->crc; st->oerrs = c->underrun; return 0; case SERIAL_GETESTAT: DEBUG2 (d, ("ioctl: getestat\n")); opte1 = (struct e1_statistics*) data; opte1->status = c->status; opte1->cursec = c->cursec; opte1->totsec = c->totsec + c->cursec; opte1->currnt.bpv = c->currnt.bpv; opte1->currnt.fse = c->currnt.fse; opte1->currnt.crce = c->currnt.crce; opte1->currnt.rcrce = c->currnt.rcrce; opte1->currnt.uas = c->currnt.uas; opte1->currnt.les = c->currnt.les; opte1->currnt.es = c->currnt.es; opte1->currnt.bes = c->currnt.bes; opte1->currnt.ses = c->currnt.ses; opte1->currnt.oofs = c->currnt.oofs; opte1->currnt.css = c->currnt.css; opte1->currnt.dm = c->currnt.dm; opte1->total.bpv = c->total.bpv + c->currnt.bpv; opte1->total.fse = c->total.fse + c->currnt.fse; opte1->total.crce = c->total.crce + c->currnt.crce; opte1->total.rcrce = c->total.rcrce + c->currnt.rcrce; opte1->total.uas = c->total.uas + c->currnt.uas; opte1->total.les = c->total.les + c->currnt.les; opte1->total.es = c->total.es + c->currnt.es; opte1->total.bes = c->total.bes + c->currnt.bes; opte1->total.ses = c->total.ses + c->currnt.ses; opte1->total.oofs = c->total.oofs + c->currnt.oofs; opte1->total.css = c->total.css + c->currnt.css; opte1->total.dm = c->total.dm + c->currnt.dm; for (s=0; s<48; ++s) { opte1->interval[s].bpv = c->interval[s].bpv; opte1->interval[s].fse = c->interval[s].fse; opte1->interval[s].crce = c->interval[s].crce; opte1->interval[s].rcrce = c->interval[s].rcrce; opte1->interval[s].uas = c->interval[s].uas; opte1->interval[s].les = c->interval[s].les; opte1->interval[s].es = c->interval[s].es; opte1->interval[s].bes = c->interval[s].bes; opte1->interval[s].ses = c->interval[s].ses; opte1->interval[s].oofs = c->interval[s].oofs; opte1->interval[s].css = c->interval[s].css; opte1->interval[s].dm = c->interval[s].dm; } return 0; case SERIAL_CLRSTAT: DEBUG2 (d, ("ioctl: clrstat\n")); /* Only for superuser! */ #if __FreeBSD_version < 400000 error = suser (p->p_ucred, &p->p_acflag); #elif __FreeBSD_version < 500000 error = suser (p); #else error = suser_td (td); #endif if (error) return error; c->rintr = 0; c->tintr = 0; c->ibytes = 0; c->obytes = 0; c->ipkts = 0; c->opkts = 0; c->overrun = 0; c->frame = 0; c->crc = 0; c->underrun = 0; bzero (&c->currnt, sizeof (c->currnt)); bzero (&c->total, sizeof (c->total)); bzero (c->interval, sizeof (c->interval)); return 0; case SERIAL_GETBAUD: DEBUG2 (d, ("ioctl: getbaud\n")); *(long*)data = c->baud; return 0; case SERIAL_SETBAUD: DEBUG2 (d, ("ioctl: setbaud\n")); /* Only for superuser! */ #if __FreeBSD_version < 400000 error = suser (p->p_ucred, &p->p_acflag); #elif __FreeBSD_version < 500000 error = suser (p); #else error = suser_td (td); #endif if (error) return error; s = splimp (); cp_set_baud (c, *(long*)data); splx (s); return 0; case SERIAL_GETLOOP: DEBUG2 (d, ("ioctl: getloop\n")); *(int*)data = c->lloop; return 0; case SERIAL_SETLOOP: DEBUG2 (d, ("ioctl: setloop\n")); /* Only for superuser! */ #if __FreeBSD_version < 400000 error = suser (p->p_ucred, &p->p_acflag); #elif __FreeBSD_version < 500000 error = suser (p); #else error = suser_td (td); #endif if (error) return error; s = splimp (); cp_set_lloop (c, *(int*)data); splx (s); return 0; case SERIAL_GETDPLL: DEBUG2 (d, ("ioctl: getdpll\n")); if (c->type != T_SERIAL) return EINVAL; *(int*)data = c->dpll; return 0; case SERIAL_SETDPLL: DEBUG2 (d, ("ioctl: setdpll\n")); /* Only for superuser! */ #if __FreeBSD_version < 400000 error = suser (p->p_ucred, &p->p_acflag); #elif __FreeBSD_version < 500000 error = suser (p); #else error = suser_td (td); #endif if (error) return error; if (c->type != T_SERIAL) return EINVAL; s = splimp (); cp_set_dpll (c, *(int*)data); splx (s); return 0; case SERIAL_GETNRZI: DEBUG2 (d, ("ioctl: getnrzi\n")); if (c->type != T_SERIAL) return EINVAL; *(int*)data = c->nrzi; return 0; case SERIAL_SETNRZI: DEBUG2 (d, ("ioctl: setnrzi\n")); /* Only for superuser! */ #if __FreeBSD_version < 400000 error = suser (p->p_ucred, &p->p_acflag); #elif __FreeBSD_version < 500000 error = suser (p); #else error = suser_td (td); #endif if (error) return error; if (c->type != T_SERIAL) return EINVAL; s = splimp (); cp_set_nrzi (c, *(int*)data); splx (s); return 0; case SERIAL_GETDEBUG: DEBUG2 (d, ("ioctl: getdebug\n")); *(int*)data = d->chan->debug; return 0; case SERIAL_SETDEBUG: DEBUG2 (d, ("ioctl: setdebug\n")); /* Only for superuser! */ #if __FreeBSD_version < 400000 error = suser (p->p_ucred, &p->p_acflag); #elif __FreeBSD_version < 500000 error = suser (p); #else error = suser_td (td); #endif if (error) return error; d->chan->debug = *(int*)data; #ifndef NETGRAPH if (d->chan->debug) d->pp.pp_if.if_flags |= IFF_DEBUG; else d->pp.pp_if.if_flags &= ~IFF_DEBUG; #endif return 0; case SERIAL_GETHIGAIN: DEBUG2 (d, ("ioctl: gethigain\n")); if (c->type != T_E1) return EINVAL; *(int*)data = c->higain; return 0; case SERIAL_SETHIGAIN: DEBUG2 (d, ("ioctl: sethigain\n")); /* Only for superuser! */ #if __FreeBSD_version < 400000 error = suser (p->p_ucred, &p->p_acflag); #elif __FreeBSD_version < 500000 error = suser (p); #else error = suser_td (td); #endif if (error) return error; if (c->type != T_E1) return EINVAL; s = splimp (); cp_set_higain (c, *(int*)data); splx (s); return 0; case SERIAL_GETPHONY: DEBUG2 (d, ("ioctl: getphony\n")); if (c->type != T_E1) return EINVAL; *(int*)data = c->phony; return 0; case SERIAL_SETPHONY: DEBUG2 (d, ("ioctl: setphony\n")); /* Only for superuser! */ #if __FreeBSD_version < 400000 error = suser (p->p_ucred, &p->p_acflag); #elif __FreeBSD_version < 500000 error = suser (p); #else error = suser_td (td); #endif if (error) return error; if (c->type != T_E1) return EINVAL; s = splimp (); cp_set_phony (c, *(int*)data); splx (s); return 0; case SERIAL_GETUNFRAM: DEBUG2 (d, ("ioctl: getunfram\n")); if (c->type != T_E1) return EINVAL; *(int*)data = c->unfram; return 0; case SERIAL_SETUNFRAM: DEBUG2 (d, ("ioctl: setunfram\n")); /* Only for superuser! */ #if __FreeBSD_version < 400000 error = suser (p->p_ucred, &p->p_acflag); #elif __FreeBSD_version < 500000 error = suser (p); #else error = suser_td (td); #endif if (error) return error; if (c->type != T_E1) return EINVAL; s = splimp (); cp_set_unfram (c, *(int*)data); splx (s); return 0; case SERIAL_GETMONITOR: DEBUG2 (d, ("ioctl: getmonitor\n")); if (c->type != T_E1) return EINVAL; *(int*)data = c->monitor; return 0; case SERIAL_SETMONITOR: DEBUG2 (d, ("ioctl: setmonitor\n")); /* Only for superuser! */ #if __FreeBSD_version < 400000 error = suser (p->p_ucred, &p->p_acflag); #elif __FreeBSD_version < 500000 error = suser (p); #else error = suser_td (td); #endif if (error) return error; if (c->type != T_E1) return EINVAL; s = splimp (); cp_set_monitor (c, *(int*)data); splx (s); return 0; case SERIAL_GETUSE16: DEBUG2 (d, ("ioctl: getuse16\n")); if (c->type != T_E1 || c->unfram) return EINVAL; *(int*)data = c->use16; return 0; case SERIAL_SETUSE16: DEBUG2 (d, ("ioctl: setuse16\n")); /* Only for superuser! */ #if __FreeBSD_version < 400000 error = suser (p->p_ucred, &p->p_acflag); #elif __FreeBSD_version < 500000 error = suser (p); #else error = suser_td (td); #endif if (error) return error; if (c->type != T_E1) return EINVAL; s = splimp (); cp_set_use16 (c, *(int*)data); splx (s); return 0; case SERIAL_GETCRC4: DEBUG2 (d, ("ioctl: getcrc4\n")); if (c->type != T_E1 || c->unfram) return EINVAL; *(int*)data = c->crc4; return 0; case SERIAL_SETCRC4: DEBUG2 (d, ("ioctl: setcrc4\n")); /* Only for superuser! */ #if __FreeBSD_version < 400000 error = suser (p->p_ucred, &p->p_acflag); #elif __FreeBSD_version < 500000 error = suser (p); #else error = suser_td (td); #endif if (error) return error; if (c->type != T_E1) return EINVAL; s = splimp (); cp_set_crc4 (c, *(int*)data); splx (s); return 0; case SERIAL_GETCLK: DEBUG2 (d, ("ioctl: getclk\n")); if (c->type != T_E1 && c->type != T_G703) return EINVAL; switch (c->gsyn) { default: *(int*)data = E1CLK_INTERNAL; break; case GSYN_RCV: *(int*)data = E1CLK_RECEIVE; break; case GSYN_RCV0: *(int*)data = E1CLK_RECEIVE_CHAN0; break; case GSYN_RCV1: *(int*)data = E1CLK_RECEIVE_CHAN1; break; case GSYN_RCV2: *(int*)data = E1CLK_RECEIVE_CHAN2; break; case GSYN_RCV3: *(int*)data = E1CLK_RECEIVE_CHAN3; break; } return 0; case SERIAL_SETCLK: DEBUG2 (d, ("ioctl: setclk\n")); /* Only for superuser! */ #if __FreeBSD_version < 400000 error = suser (p->p_ucred, &p->p_acflag); #elif __FreeBSD_version < 500000 error = suser (p); #else error = suser_td (td); #endif if (error) return error; if (c->type != T_E1 && c->type != T_G703) return EINVAL; s = splimp (); switch (*(int*)data) { default: cp_set_gsyn (c, GSYN_INT); break; case E1CLK_RECEIVE: cp_set_gsyn (c, GSYN_RCV); break; case E1CLK_RECEIVE_CHAN0: cp_set_gsyn (c, GSYN_RCV0); break; case E1CLK_RECEIVE_CHAN1: cp_set_gsyn (c, GSYN_RCV1); break; case E1CLK_RECEIVE_CHAN2: cp_set_gsyn (c, GSYN_RCV2); break; case E1CLK_RECEIVE_CHAN3: cp_set_gsyn (c, GSYN_RCV3); break; } splx (s); return 0; case SERIAL_GETTIMESLOTS: DEBUG2 (d, ("ioctl: gettimeslots\n")); if (c->type != T_E1 || c->unfram) return EINVAL; *(u_long*)data = c->ts; return 0; case SERIAL_SETTIMESLOTS: DEBUG2 (d, ("ioctl: settimeslots\n")); /* Only for superuser! */ #if __FreeBSD_version < 400000 error = suser (p->p_ucred, &p->p_acflag); #elif __FreeBSD_version < 500000 error = suser (p); #else error = suser_td (td); #endif if (error) return error; if (c->type != T_E1) return EINVAL; s = splimp (); cp_set_ts (c, *(u_long*)data); splx (s); return 0; case SERIAL_GETINVCLK: DEBUG2 (d, ("ioctl: getinvclk\n")); #if 1 return EINVAL; #else if (c->type != T_SERIAL) return EINVAL; *(int*)data = c->invtxc; return 0; #endif case SERIAL_SETINVCLK: DEBUG2 (d, ("ioctl: setinvclk\n")); /* Only for superuser! */ #if __FreeBSD_version < 400000 error = suser (p->p_ucred, &p->p_acflag); #elif __FreeBSD_version < 500000 error = suser (p); #else error = suser_td (td); #endif if (error) return error; if (c->type != T_SERIAL) return EINVAL; s = splimp (); cp_set_invtxc (c, *(int*)data); cp_set_invrxc (c, *(int*)data); splx (s); return 0; case SERIAL_GETINVTCLK: DEBUG2 (d, ("ioctl: getinvtclk\n")); if (c->type != T_SERIAL) return EINVAL; *(int*)data = c->invtxc; return 0; case SERIAL_SETINVTCLK: DEBUG2 (d, ("ioctl: setinvtclk\n")); /* Only for superuser! */ #if __FreeBSD_version < 400000 error = suser (p->p_ucred, &p->p_acflag); #elif __FreeBSD_version < 500000 error = suser (p); #else error = suser_td (td); #endif if (error) return error; if (c->type != T_SERIAL) return EINVAL; s = splimp (); cp_set_invtxc (c, *(int*)data); splx (s); return 0; case SERIAL_GETINVRCLK: DEBUG2 (d, ("ioctl: getinvrclk\n")); if (c->type != T_SERIAL) return EINVAL; *(int*)data = c->invrxc; return 0; case SERIAL_SETINVRCLK: DEBUG2 (d, ("ioctl: setinvrclk\n")); /* Only for superuser! */ #if __FreeBSD_version < 400000 error = suser (p->p_ucred, &p->p_acflag); #elif __FreeBSD_version < 500000 error = suser (p); #else error = suser_td (td); #endif if (error) return error; if (c->type != T_SERIAL) return EINVAL; s = splimp (); cp_set_invrxc (c, *(int*)data); splx (s); return 0; case SERIAL_GETLEVEL: DEBUG2 (d, ("ioctl: getlevel\n")); if (c->type != T_G703) return EINVAL; s = splimp (); *(int*)data = cp_get_lq (c); splx (s); return 0; case SERIAL_RESET: DEBUG2 (d, ("ioctl: reset\n")); /* Only for superuser! */ #if __FreeBSD_version < 400000 error = suser (p->p_ucred, &p->p_acflag); #elif __FreeBSD_version < 500000 error = suser (p); #else error = suser_td (td); #endif if (error) return error; s = splimp (); cp_reset (c->board, 0, 0); splx (s); return 0; case SERIAL_HARDRESET: DEBUG2 (d, ("ioctl: hardreset\n")); /* Only for superuser! */ #if __FreeBSD_version < 400000 error = suser (p->p_ucred, &p->p_acflag); #elif __FreeBSD_version < 500000 error = suser (p); #else error = suser_td (td); #endif if (error) return error; s = splimp (); /* hard_reset (c->board); */ splx (s); return 0; case SERIAL_GETCABLE: DEBUG2 (d, ("ioctl: getcable\n")); if (c->type != T_SERIAL) return EINVAL; s = splimp (); *(int*)data = cp_get_cable (c); splx (s); return 0; case SERIAL_GETDIR: DEBUG2 (d, ("ioctl: getdir\n")); if (c->type != T_E1) return EINVAL; *(int*)data = c->dir; return 0; case SERIAL_SETDIR: DEBUG2 (d, ("ioctl: setdir\n")); /* Only for superuser! */ #if __FreeBSD_version < 400000 error = suser (p->p_ucred, &p->p_acflag); #elif __FreeBSD_version < 500000 error = suser (p); #else error = suser_td (td); #endif if (error) return error; s = splimp (); cp_set_dir (c, *(int*)data); splx (s); return 0; case SERIAL_GETDXC: DEBUG2 (d, ("ioctl: getdxc\n")); if (c->type != T_E1) return EINVAL; *(cp_dxc_t*)data = c->dxc; return 0; case SERIAL_SETDXC: DEBUG2 (d, ("ioctl: setdxc\n")); /* Only for superuser! */ #if __FreeBSD_version < 400000 error = suser (p->p_ucred, &p->p_acflag); #elif __FreeBSD_version < 500000 error = suser (p); #else error = suser_td (td); #endif if (error) return error; s = splimp (); cp_set_dxc (c, (cp_dxc_t*)data); splx (s); return 0; case TIOCSDTR: /* Set DTR */ s = splimp (); cp_set_dtr (c, 1); splx (s); return 0; case TIOCCDTR: /* Clear DTR */ s = splimp (); cp_set_dtr (c, 0); splx (s); return 0; case TIOCMSET: /* Set DTR/RTS */ s = splimp (); cp_set_dtr (c, (*(int*)data & TIOCM_DTR) ? 1 : 0); cp_set_rts (c, (*(int*)data & TIOCM_RTS) ? 1 : 0); splx (s); return 0; case TIOCMBIS: /* Add DTR/RTS */ s = splimp (); if (*(int*)data & TIOCM_DTR) cp_set_dtr (c, 1); if (*(int*)data & TIOCM_RTS) cp_set_rts (c, 1); splx (s); return 0; case TIOCMBIC: /* Clear DTR/RTS */ s = splimp (); if (*(int*)data & TIOCM_DTR) cp_set_dtr (c, 0); if (*(int*)data & TIOCM_RTS) cp_set_rts (c, 0); splx (s); return 0; case TIOCMGET: /* Get modem status */ *(int*)data = cp_modem_status (c); return 0; } return ENOTTY; } #if __FreeBSD_version < 400000 static struct cdevsw cp_cdevsw = { cp_open, cp_close, noread, nowrite, cp_ioctl, nullstop, nullreset, nodevtotty, seltrue, nommap, NULL, "cp", NULL, -1 }; #elif __FreeBSD_version < 500000 static struct cdevsw cp_cdevsw = { cp_open, cp_close, noread, nowrite, cp_ioctl, nopoll, nommap, nostrategy, "taupci", CDEV_MAJOR, nodump, nopsize, D_NAGGED, -1 }; #else static struct cdevsw cp_cdevsw = { cp_open, cp_close, noread, nowrite, cp_ioctl, nopoll, nommap, nostrategy, "taupci", CDEV_MAJOR, nodump, nopsize, D_NAGGED, }; #endif #ifdef NETGRAPH static int ng_cp_constructor (node_p nodep) { return EINVAL; } static int ng_cp_newhook (node_p node, hook_p hook, const char *name) { #if __FreeBSD_version >= 500000 drv_t *d = NG_NODE_PRIVATE (node); #else drv_t *d = node->private; #endif /* Attach debug hook */ if (strcmp (name, NG_CP_HOOK_DEBUG) == 0) { #if __FreeBSD_version >= 500000 NG_HOOK_SET_PRIVATE (hook, NULL); #else hook->private = 0; #endif d->debug_hook = hook; return 0; } /* Check for raw hook */ if (strcmp (name, NG_CP_HOOK_RAW) != 0) return EINVAL; #if __FreeBSD_version >= 500000 NG_HOOK_SET_PRIVATE (hook, d); #else hook->private = d; #endif d->hook = hook; cp_up (d); return 0; } static char *format_timeslots (u_long s) { static char buf [100]; char *p = buf; int i; for (i=1; i<32; ++i) if ((s >> i) & 1) { int prev = (i > 1) & (s >> (i-1)); int next = (i < 31) & (s >> (i+1)); if (prev) { if (next) continue; *p++ = '-'; } else if (p > buf) *p++ = ','; if (i >= 10) *p++ = '0' + i / 10; *p++ = '0' + i % 10; } *p = 0; return buf; } static int print_modems (char *s, cp_chan_t *c, int need_header) { int status = cp_modem_status (c); int length = 0; if (need_header) length += sprintf (s + length, " LE DTR DSR RTS CTS CD\n"); length += sprintf (s + length, "%4s %4s %4s %4s %4s %4s\n", status & TIOCM_LE ? "On" : "-", status & TIOCM_DTR ? "On" : "-", status & TIOCM_DSR ? "On" : "-", status & TIOCM_RTS ? "On" : "-", status & TIOCM_CTS ? "On" : "-", status & TIOCM_CD ? "On" : "-"); return length; } static int print_stats (char *s, cp_chan_t *c, int need_header) { int length = 0; if (need_header) length += sprintf (s + length, " Rintr Tintr Mintr Ibytes Ipkts Ierrs Obytes Opkts Oerrs\n"); length += sprintf (s + length, "%7ld %7ld %7ld %8lu %7ld %7ld %8lu %7ld %7ld\n", c->rintr, c->tintr, 0l, (unsigned long) c->ibytes, c->ipkts, c->overrun + c->frame + c->crc, (unsigned long) c->obytes, c->opkts, c->underrun); return length; } static char *format_e1_status (u_char status) { static char buf [80]; if (status & E1_NOALARM) return "Ok"; buf[0] = 0; if (status & E1_LOS) strcat (buf, ",LOS"); if (status & E1_AIS) strcat (buf, ",AIS"); if (status & E1_LOF) strcat (buf, ",LOF"); if (status & E1_LOMF) strcat (buf, ",LOMF"); if (status & E1_FARLOF) strcat (buf, ",FARLOF"); if (status & E1_AIS16) strcat (buf, ",AIS16"); if (status & E1_FARLOMF) strcat (buf, ",FARLOMF"); if (status & E1_TSTREQ) strcat (buf, ",TSTREQ"); if (status & E1_TSTERR) strcat (buf, ",TSTERR"); if (buf[0] == ',') return buf+1; return "Unknown"; } static int print_frac (char *s, int leftalign, u_long numerator, u_long divider) { int n, length = 0; if (numerator < 1 || divider < 1) { length += sprintf (s+length, leftalign ? "/- " : " -"); return length; } n = (int) (0.5 + 1000.0 * numerator / divider); if (n < 1000) { length += sprintf (s+length, leftalign ? "/.%-3d" : " .%03d", n); return length; } *(s + length) = leftalign ? '/' : ' '; length ++; if (n >= 1000000) n = (n+500) / 1000 * 1000; else if (n >= 100000) n = (n+50) / 100 * 100; else if (n >= 10000) n = (n+5) / 10 * 10; switch (n) { case 1000: length += printf (s+length, ".999"); return length; case 10000: n = 9990; break; case 100000: n = 99900; break; case 1000000: n = 999000; break; } if (n < 10000) length += sprintf (s+length, "%d.%d", n/1000, n/10%100); else if (n < 100000) length += sprintf (s+length, "%d.%d", n/1000, n/100%10); else if (n < 1000000) length += sprintf (s+length, "%d.", n/1000); else length += sprintf (s+length, "%d", n/1000); return length; } static int print_e1_stats (char *s, cp_chan_t *c) { struct e1_counters total; u_long totsec; int length = 0; totsec = c->totsec + c->cursec; total.bpv = c->total.bpv + c->currnt.bpv; total.fse = c->total.fse + c->currnt.fse; total.crce = c->total.crce + c->currnt.crce; total.rcrce = c->total.rcrce + c->currnt.rcrce; total.uas = c->total.uas + c->currnt.uas; total.les = c->total.les + c->currnt.les; total.es = c->total.es + c->currnt.es; total.bes = c->total.bes + c->currnt.bes; total.ses = c->total.ses + c->currnt.ses; total.oofs = c->total.oofs + c->currnt.oofs; total.css = c->total.css + c->currnt.css; total.dm = c->total.dm + c->currnt.dm; length += sprintf (s + length, " Unav/Degr Bpv/Fsyn CRC/RCRC Err/Lerr Sev/Bur Oof/Slp Status\n"); /* Unavailable seconds, degraded minutes */ length += print_frac (s + length, 0, c->currnt.uas, c->cursec); length += print_frac (s + length, 1, 60 * c->currnt.dm, c->cursec); /* Bipolar violations, frame sync errors */ length += print_frac (s + length, 0, c->currnt.bpv, c->cursec); length += print_frac (s + length, 1, c->currnt.fse, c->cursec); /* CRC errors, remote CRC errors (E-bit) */ length += print_frac (s + length, 0, c->currnt.crce, c->cursec); length += print_frac (s + length, 1, c->currnt.rcrce, c->cursec); /* Errored seconds, line errored seconds */ length += print_frac (s + length, 0, c->currnt.es, c->cursec); length += print_frac (s + length, 1, c->currnt.les, c->cursec); /* Severely errored seconds, burst errored seconds */ length += print_frac (s + length, 0, c->currnt.ses, c->cursec); length += print_frac (s + length, 1, c->currnt.bes, c->cursec); /* Out of frame seconds, controlled slip seconds */ length += print_frac (s + length, 0, c->currnt.oofs, c->cursec); length += print_frac (s + length, 1, c->currnt.css, c->cursec); length += sprintf (s + length, " %s\n", format_e1_status (c->status)); /* Print total statistics. */ length += print_frac (s + length, 0, total.uas, totsec); length += print_frac (s + length, 1, 60 * total.dm, totsec); length += print_frac (s + length, 0, total.bpv, totsec); length += print_frac (s + length, 1, total.fse, totsec); length += print_frac (s + length, 0, total.crce, totsec); length += print_frac (s + length, 1, total.rcrce, totsec); length += print_frac (s + length, 0, total.es, totsec); length += print_frac (s + length, 1, total.les, totsec); length += print_frac (s + length, 0, total.ses, totsec); length += print_frac (s + length, 1, total.bes, totsec); length += print_frac (s + length, 0, total.oofs, totsec); length += print_frac (s + length, 1, total.css, totsec); length += sprintf (s + length, " -- Total\n"); return length; } static int print_chan (char *s, cp_chan_t *c) { drv_t *d = c->sys; int length = 0; length += sprintf (s + length, "cp%d", c->board->num * NCHAN + c->num); if (d->chan->debug) length += sprintf (s + length, " debug=%d", d->chan->debug); if (c->board->mux) { length += sprintf (s + length, " cfg=C"); } else { length += sprintf (s + length, " cfg=A"); } if (c->baud) length += sprintf (s + length, " %ld", c->baud); else length += sprintf (s + length, " extclock"); if (c->type == T_E1 || c->type == T_G703) switch (c->gsyn) { case GSYN_INT : length += sprintf (s + length, " syn=int"); break; case GSYN_RCV : length += sprintf (s + length, " syn=rcv"); break; case GSYN_RCV0 : length += sprintf (s + length, " syn=rcv0"); break; case GSYN_RCV1 : length += sprintf (s + length, " syn=rcv1"); break; case GSYN_RCV2 : length += sprintf (s + length, " syn=rcv2"); break; case GSYN_RCV3 : length += sprintf (s + length, " syn=rcv3"); break; } if (c->type == T_SERIAL) { length += sprintf (s + length, " dpll=%s", c->dpll ? "on" : "off"); length += sprintf (s + length, " nrzi=%s", c->nrzi ? "on" : "off"); length += sprintf (s + length, " invclk=%s", c->invtxc ? "on" : "off"); } if (c->type == T_E1) length += sprintf (s + length, " higain=%s", c->higain ? "on" : "off"); length += sprintf (s + length, " loop=%s", c->lloop ? "on" : "off"); if (c->type == T_E1) length += sprintf (s + length, " ts=%s", format_timeslots (c->ts)); if (c->type == T_G703) { int lq, x; x = splimp (); lq = cp_get_lq (c); splx (x); length += sprintf (s + length, " (level=-%.1fdB)", lq / 10.0); } length += sprintf (s + length, "\n"); return length; } #if __FreeBSD_version >= 500000 static int ng_cp_rcvmsg (node_p node, item_p item, hook_p lasthook) { drv_t *d = NG_NODE_PRIVATE (node); struct ng_mesg *msg; #else static int ng_cp_rcvmsg (node_p node, struct ng_mesg *msg, const char *retaddr, struct ng_mesg **rptr) { drv_t *d = node->private; #endif struct ng_mesg *resp = NULL; int error = 0; #if __FreeBSD_version >= 500000 NGI_GET_MSG (item, msg); #endif switch (msg->header.typecookie) { default: error = EINVAL; break; case NGM_CP_COOKIE: printf ("Not implemented yet\n"); error = EINVAL; break; case NGM_GENERIC_COOKIE: switch (msg->header.cmd) { default: error = EINVAL; break; case NGM_TEXT_STATUS: { char *s; int l = 0; int dl = sizeof (struct ng_mesg) + 730; #if __FreeBSD_version >= 500000 NG_MKRESPONSE (resp, msg, dl, M_NOWAIT); #else MALLOC (resp, struct ng_mesg *, dl, M_NETGRAPH, M_NOWAIT); if (! resp) { error = ENOMEM; break; } bzero (resp, dl); (resp)->header.version = NG_VERSION; (resp)->header.arglen = strlen (s) + 1; (resp)->header.token = msg->header.token; (resp)->header.typecookie = NGM_CP_COOKIE; (resp)->header.cmd = msg->header.cmd; #endif if (! resp) { error = ENOMEM; break; } s = (resp)->data; if (d) { l += print_chan (s + l, d->chan); l += print_stats (s + l, d->chan, 1); l += print_modems (s + l, d->chan, 1); l += print_e1_stats (s + l, d->chan); } else l += sprintf (s + l, "Error: node not connect to channel"); strncpy ((resp)->header.cmdstr, "status", NG_CMDSTRLEN); } break; } break; } #if __FreeBSD_version >= 500000 NG_RESPOND_MSG (error, node, item, resp); NG_FREE_MSG (msg); #else *rptr = resp; FREE (msg, M_NETGRAPH); #endif return error; } #if __FreeBSD_version >= 500000 static int ng_cp_rcvdata (hook_p hook, item_p item) { drv_t *d = NG_NODE_PRIVATE (NG_HOOK_NODE(hook)); struct mbuf *m; meta_p meta; #else static int ng_cp_rcvdata (hook_p hook, struct mbuf *m, meta_p meta) { drv_t *d = hook->node->private; #endif struct ifqueue *q; int s; #if __FreeBSD_version >= 500000 NGI_GET_M (item, m); NGI_GET_META (item, meta); NG_FREE_ITEM (item); #endif if (! NG_HOOK_PRIVATE (hook) || ! d) { #if __FreeBSD_version >= 500000 NG_FREE_M (m); NG_FREE_META (meta); #else NG_FREE_DATA (m,meta); #endif return ENETDOWN; } q = (meta && meta->priority > 0) ? &d->hi_queue : &d->queue; s = splimp (); #if __FreeBSD_version >= 500000 IF_LOCK (q); if (_IF_QFULL (q)) { _IF_DROP (q); IF_UNLOCK (q); splx (s); NG_FREE_M (m); NG_FREE_META (meta); return ENOBUFS; } _IF_ENQUEUE (q, m); IF_UNLOCK (q); #else if (IF_QFULL (q)) { IF_DROP (q); splx (s); NG_FREE_DATA (m, meta); return ENOBUFS; } IF_ENQUEUE (q, m); #endif splx (s); cp_start (d); return 0; } static int ng_cp_rmnode (node_p node) { #if __FreeBSD_version >= 500000 drv_t *d = NG_NODE_PRIVATE (node); if (d && d->running) cp_down (d); #ifdef KLD_MODULE if (node->nd_flags & NG_REALLY_DIE) { NG_NODE_SET_PRIVATE (node, NULL); NG_NODE_UNREF (node); } node->nd_flags &= ~NG_INVALID; #endif #else drv_t *d = node->private; if (d && d->running) cp_down (d); node->flags |= NG_INVALID; ng_cutlinks (node); #ifdef KLD_MODULE #if __FreeBSD_version >= 400000 /* We do so because of pci module problem, see also comment in cp_unload. Not in 4.x. */ ng_unname (node); ng_unref (node); #else node->flags &= ~NG_INVALID; #endif #endif #endif return 0; } static void ng_cp_watchdog (void *arg) { drv_t *d = arg; if (d) { if (d->timeout == 1) cp_watchdog (d); if (d->timeout) d->timeout--; d->timeout_handle = timeout (ng_cp_watchdog, d, hz); } } static int ng_cp_connect (hook_p hook) { #if __FreeBSD_version >= 500000 drv_t *d = NG_NODE_PRIVATE (NG_HOOK_NODE (hook)); #else drv_t *d = hook->node->private; #endif if (d) d->timeout_handle = timeout (ng_cp_watchdog, d, hz); return 0; } static int ng_cp_disconnect (hook_p hook) { #if __FreeBSD_version >= 500000 drv_t *d = NG_NODE_PRIVATE (NG_HOOK_NODE (hook)); #else drv_t *d = hook->node->private; #endif if (d) { #if __FreeBSD_version >= 500000 if (NG_HOOK_PRIVATE (hook)) #else if (hook->private) #endif cp_down (d); untimeout (ng_cp_watchdog, d, d->timeout_handle); } return 0; } #endif #if __FreeBSD_version < 400000 #ifdef KLD_MODULE extern STAILQ_HEAD(devlist, pci_devinfo) pci_devq; static struct pci_devinfo *pci_device_find (u_int16_t device, u_int16_t vendor, int unit) { pcicfgregs *cfg; struct pci_devinfo *dinfo; int u=0,i; for (dinfo = STAILQ_FIRST (&pci_devq), i=0; dinfo && (i < pci_numdevs); dinfo = STAILQ_NEXT (dinfo, pci_links), i++) { cfg = &dinfo->cfg; if ((device == cfg->device) && (vendor == cfg->vendor)) { if (u == unit) return dinfo; u++; } } return 0; } /* * Function called when loading the driver. */ static int cp_load (void) { int i, s; pcicfgregs *cfg; struct pci_devinfo *dinfo; s = splimp (); for (i=0; icfg; cp_attach (cfg, i); dinfo->device = &cp_driver; strncpy (dinfo->conf.pd_name, cp_driver.pd_name, sizeof(dinfo->conf.pd_name)); dinfo->conf.pd_name[sizeof(dinfo->conf.pd_name) - 1] = 0; dinfo->conf.pd_unit = i; } splx (s); if (! i) { /* Deactivate the timeout routine. */ untimeout (cp_timeout, 0, timeout_handle); return ENXIO; } return 0; } /* * Function called when unloading the driver. */ static int cp_unload (void) { #if 0 /* Currently pci loadable module not fully supported, so we just return EBUSY. Do not forget to correct ng_cp_rmnode then probelm would be solved. */ return EBUSY; #else int i, s; /* Check if the device is busy (open). */ for (i=0; ichan->type && d->running) return EBUSY; } s = splimp (); /* Deactivate the timeout routine. */ untimeout (cp_timeout, 0, timeout_handle); /* OK to unload the driver, unregister the interrupt first. */ for (i=0; iport) continue; cp_reset (b, 0 ,0); pci_unmap_int (tag, cp_intr, b, &net_imask); /* Here should be something like pci_unmap_mem ()*/ } for (i=0; i= 400000 || NBPFILTER > 0 /* Detach from the packet filter list of interfaces. */ { struct bpf_if *q, **b = &bpf_iflist; while ((q = *b)) { if (q->bif_ifp == d->pp.pp_if) { *b = q->bif_next; free (q, M_DEVBUF); } b = &(q->bif_next); } } #endif /* Detach from the sync PPP list. */ sppp_detach (&d->pp.pp_if); /* Detach from the system list of interfaces. */ { struct ifaddr *ifa; TAILQ_FOREACH (ifa, &d->pp.pp_if.if_addrhead, ifa_link) { TAILQ_REMOVE (&d->pp.pp_if.if_addrhead, ifa, ifa_link); free (ifa, M_IFADDR); } TAILQ_REMOVE (&ifnet, &d->pp.pp_if, if_link); } #endif /* Deallocate buffers. */ /* free (d, M_DEVBUF);*/ } for (i=0; iport) free (b, M_DEVBUF); } splx (s); return 0; #endif } #endif #endif #if __FreeBSD_version < 400000 #ifdef KLD_MODULE static int cp_modevent (module_t mod, int type, void *unused) { dev_t dev; switch (type) { case MOD_LOAD: dev = makedev (CDEV_MAJOR, 0); cdevsw_add (&dev, &cp_cdevsw, 0); timeout_handle = timeout (cp_timeout, 0, hz*5); return cp_load (); case MOD_UNLOAD: return cp_unload (); case MOD_SHUTDOWN: break; } return 0; } #endif /* KLD_MODULE */ #else /* __FreeBSD_version < 400000 */ static int cp_modevent (module_t mod, int type, void *unused) { dev_t dev; static int load_count = 0; dev = makedev (CDEV_MAJOR, 0); switch (type) { case MOD_LOAD: if (devsw (dev)) { printf ("Tau-PCI driver is already in system\n"); return (ENXIO); } #if __FreeBSD_version >= 500000 && defined NETGRAPH if (ng_newtype (&typestruct)) printf ("Failed to register ng_cp\n"); #endif ++load_count; cdevsw_add (&cp_cdevsw); timeout_handle = timeout (cp_timeout, 0, hz*5); break; case MOD_UNLOAD: if (devsw (dev) && (load_count == 1)) { printf ("Removing device entry for Tau-PCI\n"); cdevsw_remove (&cp_cdevsw); } untimeout (cp_timeout, 0, timeout_handle); --load_count; break; case MOD_SHUTDOWN: break; } return 0; } #endif /* __FreeBSD_version < 400000 */ #ifdef NETGRAPH static struct ng_type typestruct = { #if __FreeBSD_version >= 500000 NG_ABI_VERSION, #else NG_VERSION, #endif NG_CP_NODE_TYPE, #if __FreeBSD_version < 400000 && (defined KLD_MODULE) cp_modevent, #else NULL, #endif ng_cp_constructor, ng_cp_rcvmsg, ng_cp_rmnode, ng_cp_newhook, NULL, ng_cp_connect, ng_cp_rcvdata, ng_cp_disconnect, NULL }; #if __FreeBSD_version < 500000 NETGRAPH_INIT_ORDERED (cp, &typestruct, SI_SUB_DRIVERS,\ SI_ORDER_MIDDLE + CDEV_MAJOR); #else MODULE_DEPEND (ng_cp, netgraph, NG_ABI_VERSION, NG_ABI_VERSION, NG_ABI_VERSION); #endif #endif /*NETGRAPH*/ #if __FreeBSD_version < 400000 #ifdef KLD_MODULE #ifndef NETGRAPH static moduledata_t cpmod = { "cp", cp_modevent, NULL}; DECLARE_MODULE (cp, cpmod, SI_SUB_DRIVERS, SI_ORDER_MIDDLE + CDEV_MAJOR); #endif #else /* KLD_MODULE */ /* * Now for some driver initialisation. * Occurs ONCE during boot (very early). * This is if we are NOT a loadable module. */ static void cp_drvinit (void *unused) { dev_t dev; dev = makedev (CDEV_MAJOR, 0); cdevsw_add (&dev, &cp_cdevsw, 0); /* Activate the timeout routine. */ timeout_handle = timeout (cp_timeout, 0, hz); #ifdef NETGRAPH #if 0 /* Register our node type in netgraph */ if (ng_newtype (&typestruct)) printf ("Failed to register ng_cp\n"); #endif #endif } SYSINIT (cpdev, SI_SUB_DRIVERS, SI_ORDER_MIDDLE+CDEV_MAJOR, cp_drvinit, 0) #endif /* KLD_MODULE */ #else DRIVER_MODULE (if_cp, pci, cp_driver, cp_devclass, cp_modevent, NULL); #endif #endif /* NPCI */ --------------090508090207000700080608-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 17 2:16:30 2002 Delivered-To: freebsd-net@freebsd.org Received: from astnet.astelit.ru (astnet.astelit.ru [195.96.64.250]) by hub.freebsd.org (Postfix) with ESMTP id B96D737B405 for ; Wed, 17 Apr 2002 02:16:24 -0700 (PDT) Received: from ISAEV (cq.astelit.ru [195.96.64.172]) by astnet.astelit.ru (8.12.2/8.12.2) with ESMTP id g3H9GMa6010799 for ; Wed, 17 Apr 2002 13:16:22 +0400 (MSD) Date: Wed, 17 Apr 2002 13:13:47 +0400 From: Alexander Isaev X-Mailer: The Bat! (v1.53d) Reply-To: Alexander Isaev X-Priority: 3 (Normal) Message-ID: <16114655943.20020417131347@astelit.ru> To: freebsd-net@FreeBSD.ORG Subject: FreeBSD 4.5 and network problems MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I have installed FreeBSD 4.5. Everything worked OK from the console. But when I tried to connect to it remotely (using SSH) I had some network troubles. From time to time to time the connection hangs for a short time. First of all I've tried to install another network card (I've replaced D-Link 550 with D-Link 538TX). But the problem still exists. Later I've noticed that network timeouts happen also when sending or receiving large files over SMTP/POP3. Can someone help me to solve this problem? Best regards, Alexander Isaev mailto:A.Isaev@astelit.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 17 4:42: 3 2002 Delivered-To: freebsd-net@freebsd.org Received: from studsboll.realworld.nu (a189.flamman.student.liu.se [130.236.218.189]) by hub.freebsd.org (Postfix) with ESMTP id BC46137B404 for ; Wed, 17 Apr 2002 04:41:45 -0700 (PDT) Received: from studsboll.realworld.nu (localhost [127.0.0.1]) by studsboll.realworld.nu (8.11.6/8.11.6) with SMTP id g3HBfcF00676 for ; Wed, 17 Apr 2002 13:41:39 +0200 (CEST) (envelope-from doktorn@realworld.nu) Date: Wed, 17 Apr 2002 13:41:38 +0200 From: Rickard Borgmäster To: net@FreeBSD.ORG Subject: Tunneling - No gif interface? Why? Message-Id: <20020417134138.53d68990.doktorn@realworld.nu> X-Mailer: Sylpheed version 0.7.2 (GTK+ 1.2.10; i386-portbld-freebsd4.5) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I need to create a tunnel to an OpenBSD host. This is because the OpenBSD host is my mailrelay, and my local sendmail (port 25) is blocked by a firewall out of my control. But somewhere it seems that the necessary parts are not in the system.... $ apropos tunnel gif(4) - generic tunnel interface gifconfig(8) - configure generic IP tunnel nos-tun(8) - implement ``nos'' or ``ka9q'' style IP over IP tunnel stf(4) - 6to4 tunnel interface tap(4) - Ethernet tunnel software network interface tun(4) - tunnel software network interface gif, that's what I want! from gifconfig(8): SYNOPSIS gifconfig interface [af] [physsrc physdest] [...] EXAMPLES If you would like to configure IPv6 over IPv4 (aka IPv6 in IPv4) tunnel between 10.1.1.1 and 10.2.3.4, you should perform the following command: # gifconfig gif0 inet 10.1.1.1 10.2.3.4 Nice! So lets rock: $ gifconfig gif0 130.236.218.63 213.88.128.169 gifconfig: interface gif0 does not exist Oh... $ ifconfig -a xl0: flags=8843 mtu 1500 inet 130.236.218.63 netmask 0xffffff00 broadcast 130.236.218.255 lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 ppp0: flags=8010 mtu 1500 vmnet1: flags=8843 mtu 1500 inet 10.0.8.30 netmask 0xfffffff0 broadcast 10.0.8.31 ether 00:bd:da:0d:00:01 But... $ grep tun /usr/src/sys/i386/conf/KERNEL pseudo-device tun 2 # Packet tunnel. pseudo-device gif 2 # IPv6 and IPv4 tunneling Why don't I have the gif0 interface? -- Rickard .--. .--. .----------------------------------------. | | | | .-. | Rickard Borgmäster | | | | |/ / | doktorn@sub.nu | .-^ | .--. | < | http://doktorn.sub.nu/ | ( o | ( () ) | |\ \ `----------------------------------------' `-----' `--' `--' `--' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 17 4:49:25 2002 Delivered-To: freebsd-net@freebsd.org Received: from h38n2fls34o1000.telia.com (h38n2fls34o1000.telia.com [213.64.210.38]) by hub.freebsd.org (Postfix) with ESMTP id B402737B405 for ; Wed, 17 Apr 2002 04:49:20 -0700 (PDT) Received: from veidit.net ([213.88.166.91]) (authenticated bits=0) by h38n2fls34o1000.telia.com (8.12.2/8.12.2) with ESMTP id g3HBnAq5001194 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 17 Apr 2002 13:49:18 +0200 (CEST) Message-ID: <3CBD612F.3030801@veidit.net> Date: Wed, 17 Apr 2002 13:49:03 +0200 From: John Angelmo User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.9) Gecko/20020414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Rickard_Borgm=E4ster?= Cc: net@FreeBSD.ORG Subject: Re: Tunneling - No gif interface? Why? References: <20020417134138.53d68990.doktorn@realworld.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Rickard Borgmäster wrote: > I need to create a tunnel to an OpenBSD host. This is because the > OpenBSD host is my mailrelay, and my local sendmail (port 25) is > blocked by a firewall out of my control. > > But somewhere it seems that the necessary parts are not in the > system.... > > $ apropos tunnel > gif(4) - generic tunnel interface > gifconfig(8) - configure generic IP tunnel > nos-tun(8) - implement ``nos'' or ``ka9q'' style IP over IP > tunnel stf(4) - 6to4 tunnel interface > tap(4) - Ethernet tunnel software network interface > tun(4) - tunnel software network interface > > gif, that's what I want! > > from gifconfig(8): > SYNOPSIS > gifconfig interface [af] [physsrc physdest] > [...] > EXAMPLES > If you would like to configure IPv6 over IPv4 (aka IPv6 in IPv4) > tunnel between 10.1.1.1 and 10.2.3.4, you should perform the following > command: # gifconfig gif0 inet 10.1.1.1 10.2.3.4 > > Nice! So lets rock: > > $ gifconfig gif0 130.236.218.63 213.88.128.169 > gifconfig: interface gif0 does not exist > > Oh... > > $ ifconfig -a > xl0: flags=8843 mtu 1500 > inet 130.236.218.63 netmask 0xffffff00 broadcast 130.236.218.255 > lo0: flags=8049 mtu 16384 > inet 127.0.0.1 netmask 0xff000000 > ppp0: flags=8010 mtu 1500 > vmnet1: flags=8843 mtu 1500 > inet 10.0.8.30 netmask 0xfffffff0 broadcast 10.0.8.31 > ether 00:bd:da:0d:00:01 > > But... > > $ grep tun /usr/src/sys/i386/conf/KERNEL > pseudo-device tun 2 # Packet tunnel. > pseudo-device gif 2 # IPv6 and IPv4 tunneling > > Why don't I have the gif0 interface? > > Is options INET6 added to your kernel config file? /John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 17 5:51: 2 2002 Delivered-To: freebsd-net@freebsd.org Received: from daydreamer.dk (213.237.14.128.adsl.ho.worldonline.dk [213.237.14.128]) by hub.freebsd.org (Postfix) with SMTP id 6178437B41D for ; Wed, 17 Apr 2002 05:50:56 -0700 (PDT) Received: (qmail 71956 invoked from network); 17 Apr 2002 12:50:48 -0000 Received: from unknown (HELO dpws) (192.168.1.3) by 0 with SMTP; 17 Apr 2002 12:50:48 -0000 Message-ID: <015f01c1e60e$5fcff780$0301a8c0@dpws> From: "Dennis Pedersen" To: =?iso-8859-1?Q?Rickard_Borgm=E4ster?= , References: <20020417134138.53d68990.doktorn@realworld.nu> Subject: Re: Tunneling - No gif interface? Why? Date: Wed, 17 Apr 2002 14:49:55 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org ----- Original Message ----- From: "Rickard Borgmäster" To: Sent: Wednesday, April 17, 2002 1:41 PM Subject: Tunneling - No gif interface? Why? > $ gifconfig gif0 130.236.218.63 213.88.128.169 > gifconfig: interface gif0 does not exist > > Oh... > > $ ifconfig -a > xl0: flags=8843 mtu 1500 > inet 130.236.218.63 netmask 0xffffff00 broadcast 130.236.218.255 > lo0: flags=8049 mtu 16384 > inet 127.0.0.1 netmask 0xff000000 > ppp0: flags=8010 mtu 1500 > vmnet1: flags=8843 mtu 1500 > inet 10.0.8.30 netmask 0xfffffff0 broadcast 10.0.8.31 > ether 00:bd:da:0d:00:01 Try something like this: ifconfig gif0 create Then your gif0 interface should bee created /Dennis To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 17 6: 5:47 2002 Delivered-To: freebsd-net@freebsd.org Received: from darkstar.wavenet.com.br (ipcorp-C8B16E82.ssa.terraempresas.com.br [200.177.110.130]) by hub.freebsd.org (Postfix) with ESMTP id 6375737B41B; Wed, 17 Apr 2002 06:05:41 -0700 (PDT) Received: (from root@localhost) by darkstar.wavenet.com.br (8.12.2/8.12.2) id g3HD6fb4049850; Wed, 17 Apr 2002 10:06:41 -0300 (BRT) Received: from jcrr (wv-acc2-ssa-C8B06E01.brdterra.com.br [200.176.110.1]) by darkstar.wavenet.com.br (8.12.2/8.12.2av) with SMTP id g3HD6dNt049843; Wed, 17 Apr 2002 10:06:40 -0300 (BRT) Message-ID: <004401c1e610$d2f596a0$2c00a8c0@intranet.wavenet.com.br> From: "Joao Carlos" To: Subject: Bridging with Cisco Aironet Card Date: Wed, 17 Apr 2002 10:07:26 -0300 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.6700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Virus-Scanned: by AMaViS perl-10 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I need to know if it's possible to create a bridge (options BRIDGE) with the Cisco Aironet Cards. I'm trying to do this for a long time and had no success. Please, someone tell me if it's possible. I know that it's possible to put the card in promiscuous mode, but i couldn't find out if it can send packets with others MAC address (as the bridge documentantion requires). Thanks Joao Carlos To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 17 9: 1: 0 2002 Delivered-To: freebsd-net@freebsd.org Received: from fubar.damon.com (damon.com [199.98.84.2]) by hub.freebsd.org (Postfix) with ESMTP id 6F48937B400 for ; Wed, 17 Apr 2002 09:00:51 -0700 (PDT) Received: from fubar.damon.com (localhost [127.0.0.1]) by fubar.damon.com (8.12.2/8.12.2) with ESMTP id g3HG0jwM006284; Wed, 17 Apr 2002 11:00:45 -0500 (CDT) (envelope-from dap@fubar.damon.com) Received: (from dap@localhost) by fubar.damon.com (8.12.2/8.12.2/Submit) id g3HG0jen006283; Wed, 17 Apr 2002 11:00:45 -0500 (CDT) Date: Wed, 17 Apr 2002 11:00:45 -0500 From: Damon Permezel To: Alexander Isaev Cc: freebsd-net@FreeBSD.ORG Subject: Re: FreeBSD 4.5 and network problems Message-ID: <20020417160045.GQ343@fubar.damon.com> References: <16114655943.20020417131347@astelit.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16114655943.20020417131347@astelit.ru> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Not sure about the initial delays, but I found a bug which does cause throughput to drop dramatically once it is hit. Consider the sender of a bulk data transfer (1/2 duplex). When header prediction is successful, the ACK stream coming back is handled by the fast path code. For this to be true, the window info in that ACK stream cannot change. tiwin && tiwin == tp->snd_wnd When the window finally does change, we go to the slow path. There is a check against WL1 and WL2 to ensure that the window update is not from an earlier packet. The fast-path code does not drag WL1/WL2 along. In this example, only WL2 (the ACK) changes, as the peer is sending no data. Because WL2 has not been dragged along, the check to see if the current ACK is "fresh" can fail. I was seeing this all the time with a gigabit-rate xfer I was using for a test. Because the slow-path ACKs do not update the window, the snd_wnd closes, and becomes 0. Once snd_wnd becomes zero, we end up performing zero-window probes on the sender. We send one byte. The receiver, meanwhile, has opened his window up again, and ACKs the byte, with an open window. The slow-path processing of this ACK will still ignore the window update, and the following code will set snd_wnd to -1. if (acked > so->so_snd.sb_cc) { tp->snd_wnd -= so->so_snd.sb_cc; sbdrop(&so->so_snd, (int)so->so_snd.sb_cc); ourfinisacked = 1; } else { sbdrop(&so->so_snd, acked); tp->snd_wnd -= acked; ourfinisacked = 0; } acked was 1, tp->snd_wnd was 0. snd_wnd is unsigned. We suddenly have a huge send window. Blast away! ... except we end up being driven by the rexmit timer and slow start, again and again. I am not really sure what happens in this mode. The activity light on the link turns out except for brief, intermittent flashes, so I suppose it rexmits, slow starts, gets going, overruns the window, ..... The snd_wnd keeps being decremented and will, given sufficient time, wrap down to reasonable values, and this might recover. I have not had the patience. There is a simple fix: if (tp->t_state == TCPS_ESTABLISHED && (thflags & (TH_SYN|TH_FIN|TH_RST|TH_URG|TH_ACK)) == TH_ACK && ((tp->t_flags & (TF_NEEDSYN|TF_NEEDFIN)) == 0) && ((to.to_flags & TOF_TS) == 0 || TSTMP_GEQ(to.to_tsval, tp->ts_recent)) && /* * Using the CC option is compulsory if once started: * the segment is OK if no T/TCP was negotiated or * if the segment has a CC option equal to CCrecv */ ((tp->t_flags & (TF_REQ_CC|TF_RCVD_CC)) != (TF_REQ_CC|TF_RCVD_CC) || ((to.to_flags & TOF_CC) != 0 && to.to_cc == tp->cc_recv)) && th->th_seq == tp->rcv_nxt && tiwin && tiwin == tp->snd_wnd && tp->snd_nxt == tp->snd_max) { /* * drag along the snd_wl1 and snd_wl2 as we are implicitly * updating the window with the new (same) value. */ tp->snd_wl1 = th->th_seq; tp->snd_wl2 = th->th_ack; BTW: I have not made this change to FreeBSD, but to a FreeBSD-derived embedded network stack, so I can't even assure you that the above two lines compile (as I had to edit them slightly to recast into the F-BSD idiom). Cheers, Damon. On Wed, Apr 17, 2002 at 01:13:47PM +0400, Alexander Isaev wrote: > > I have installed FreeBSD 4.5. Everything worked OK from the console. > But when I tried to connect to it remotely (using SSH) I had some network troubles. > From time to time to time the connection hangs for a short time. > First of all I've tried to install another network card (I've replaced > D-Link 550 with D-Link 538TX). But the problem still exists. Later > I've noticed that network timeouts happen also when sending or > receiving large files over SMTP/POP3. > > Can someone help me to solve this problem? > > Best regards, > Alexander Isaev mailto:A.Isaev@astelit.ru > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- -- Damon Permezel dap@damon.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 17 9:35:20 2002 Delivered-To: freebsd-net@freebsd.org Received: from owa1.digisle.com (ex-owa-sj.digisle.com [165.193.27.217]) by hub.freebsd.org (Postfix) with ESMTP id 5AB8537B405 for ; Wed, 17 Apr 2002 09:35:17 -0700 (PDT) Received: from digisle.net ([206.220.227.147] RDNS failed) by owa1.digisle.com over TLS secured channel with Microsoft SMTPSVC(5.0.2195.2966); Wed, 17 Apr 2002 09:35:12 -0700 Message-ID: <3CBDA43E.87D2E163@digisle.net> Date: Wed, 17 Apr 2002 09:35:10 -0700 From: Maksim Yevmenkin Organization: Digital Island X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Roman Kurakin Cc: Julian Elischer , freebsd-net@FreeBSD.ORG Subject: Re: 5.Current Netgraph, Mutex References: <3CBD32E3.1060808@cronyx.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Apr 2002 16:35:13.0059 (UTC) FILETIME=[D8EFB730:01C1E62D] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Roman Kurakin wrote: > #if __FreeBSD_version >= 500000 > mtx_init (&d->queue.ifq_mtx, "cp_queue", MTX_DEF); > mtx_init (&d->hi_queue.ifq_mtx, "cp_queue_hi", MTX_DEF); > #endif my guess would be that you forgot to call mtx_destroy() for queue and hi_queue mutexes. thanks, max To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 17 9:52:45 2002 Delivered-To: freebsd-net@freebsd.org Received: from proton.hexanet.fr (proton.hexanet.fr [81.23.32.33]) by hub.freebsd.org (Postfix) with ESMTP id C928837B417 for ; Wed, 17 Apr 2002 09:52:40 -0700 (PDT) Received: from hexanet.fr (localhost [127.0.0.1]) by proton.hexanet.fr (8.11.6/8.11.6) with SMTP id g3HGqSa03207; Wed, 17 Apr 2002 18:52:28 +0200 (CEST) (envelope-from c.prevotaux@hexanet.fr) Date: Wed, 17 Apr 2002 18:52:28 +0200 From: Christophe Prevotaux To: Damon Permezel Cc: A.Isaev@astelit.ru, freebsd-net@FreeBSD.ORG Subject: Re: FreeBSD 4.5 and network problems Message-Id: <20020417185228.7bada407.c.prevotaux@hexanet.fr> In-Reply-To: <20020417160045.GQ343@fubar.damon.com> References: <16114655943.20020417131347@astelit.ru> <20020417160045.GQ343@fubar.damon.com> Organization: HEXANET Sarl X-Mailer: Sylpheed version 0.7.4 (GTK+ 1.2.10; i386-portbld-freebsd4.4) X-NCC-RegID: fr.hexanet Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Are you talking about IP over Satellite link ? On Wed, 17 Apr 2002 11:00:45 -0500 Damon Permezel wrote: > Not sure about the initial delays, but I found a bug which does cause > throughput to drop dramatically once it is hit. > > Consider the sender of a bulk data transfer (1/2 duplex). > When header prediction is successful, the ACK stream coming back > is handled by the fast path code. For this to be true, the window info > in that ACK stream cannot change. > > tiwin && tiwin == tp->snd_wnd -- =============================================================== Christophe Prevotaux Email: c.prevotaux@hexanet.fr HEXANET SARL URL: http://www.hexanet.fr/ Z.A.C Les Charmilles Tel: +33 (0)3 26 79 30 05 3 Allée Thierry Sabine Direct: +33 (0)3 26 79 08 02 BP202 Fax: +33 (0)3 26 79 30 06 51686 Reims Cedex 2 FRANCE HEXANET Network Operation Center =============================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 17 10: 2:47 2002 Delivered-To: freebsd-net@freebsd.org Received: from fubar.damon.com (damon.com [199.98.84.2]) by hub.freebsd.org (Postfix) with ESMTP id 6EC4237B400 for ; Wed, 17 Apr 2002 10:02:41 -0700 (PDT) Received: from fubar.damon.com (localhost [127.0.0.1]) by fubar.damon.com (8.12.2/8.12.2) with ESMTP id g3HH2ZwM006518; Wed, 17 Apr 2002 12:02:35 -0500 (CDT) (envelope-from dap@fubar.damon.com) Received: (from dap@localhost) by fubar.damon.com (8.12.2/8.12.2/Submit) id g3HH2ZiC006517; Wed, 17 Apr 2002 12:02:35 -0500 (CDT) Date: Wed, 17 Apr 2002 12:02:35 -0500 From: Damon Permezel To: Christophe Prevotaux Cc: A.Isaev@astelit.ru, freebsd-net@FreeBSD.ORG Subject: Re: FreeBSD 4.5 and network problems Message-ID: <20020417170235.GV343@fubar.damon.com> References: <16114655943.20020417131347@astelit.ru> <20020417160045.GQ343@fubar.damon.com> <20020417185228.7bada407.c.prevotaux@hexanet.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20020417185228.7bada407.c.prevotaux@hexanet.fr> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I am talking about IP over gigabit ethernet. Concievably, if one had enough time, one might observe this over a satellite link. The necessary flows are bandwidth independent, but the time to observe the problem is bandwidth dependent. On Wed, Apr 17, 2002 at 06:52:28PM +0200, Christophe Prevotaux wrote: > Are you talking about IP over Satellite link ? > > > > On Wed, 17 Apr 2002 11:00:45 -0500 > Damon Permezel wrote: > > > Not sure about the initial delays, but I found a bug which does cause > > throughput to drop dramatically once it is hit. > > > > Consider the sender of a bulk data transfer (1/2 duplex). > > When header prediction is successful, the ACK stream coming back > > is handled by the fast path code. For this to be true, the window info > > in that ACK stream cannot change. > > > > tiwin && tiwin == tp->snd_wnd > > > > -- > =============================================================== > Christophe Prevotaux Email: c.prevotaux@hexanet.fr > HEXANET SARL URL: http://www.hexanet.fr/ > Z.A.C Les Charmilles Tel: +33 (0)3 26 79 30 05 > 3 Allée Thierry Sabine Direct: +33 (0)3 26 79 08 02 > BP202 Fax: +33 (0)3 26 79 30 06 > 51686 Reims Cedex 2 > FRANCE HEXANET Network Operation Center > =============================================================== -- -- Damon Permezel dap@damon.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 17 11:43:30 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.vbcomm.net (climax.vbcomm.net [208.178.120.12]) by hub.freebsd.org (Postfix) with ESMTP id 3DEF037B404 for ; Wed, 17 Apr 2002 11:43:25 -0700 (PDT) X-Real-Return-Path: filipak@earthlink.net Received: from earthlink.net ([208.178.123.64]) by mail.vbcomm.net (8.9.3/8.8.7) with ESMTP id OAA29889 for ; Wed, 17 Apr 2002 14:35:15 -0400 Message-ID: <3CBDC24D.3AF5B005@earthlink.net> Date: Wed, 17 Apr 2002 14:43:25 -0400 From: Mark Filipak X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@FreeBSD.ORG Subject: Hello from Mark Filipak Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello All! This is an introduction and a ping. I live in Mansfield, Ohio, USA, and have some very specific problems and questions. The first should probably be whether this is the right list for me.... so.... I just installed GallantWEB. It is a pre-configured version of FreeBSD 3.3 that acts as a gateway/firewall/server. It is up and running but doesn't recognize my D-Link DFE-530TX+ ethernet cards. What I have to work with ======================== I have the full FreeBSD 3.3 distribution (6 discs) from Walnut Creek. I have C source code and makefile for the D-Link DFE-530TX+ ethernet card. It was written for Linux. The name of the driver source code is Rtl8139.C. I have Greg Lehey's book: "The Complete FreeBSD". I also have the full FreeBSD 4.0 distribution (4 discs) from Walnut Creek, but I don't want to tackle that right now and would like to get 3.3 fully functional first. What I need =========== I would appreciate help/advice for porting the D-Link DFE-530TX+ driver to FreeBSD 3.3. There are at least four aspects to this project =============================================== 1 - Discovering what I need to grab from the full 3.3 distribution and put into the running system -- for example, the running system has no C compiler or linker -- and where those should go. 2 - Revising the actual C source code and makefile. 3 - Discovering where Rtl8139.o should go in the running system. 4 - Getting the system to actually use the ported driver. About me ======== I'm a 55 year old hardware engineer. I've used UNIX systems in the distant past, but I'm pretty raw. 8^) I write Java and Javascript, but don't have much experience with C -- but it is obviously very similar to Java. Global Question =============== Is this discussion list (freebsd-net) the right place for me or do I need to subscribe to a driver or hardware list? Thanks. All help is appreciated and some day I'm sure I will be in a position to pass it on. I know I'm taking my first steps down a long road. So here's a wave and a 'Hello' from me to you folks who are so far up the road that I can barely see you. Ciao -- Mark -- See my resume: http://home.earthlink.net/~filipak/resume/ See my music trade pages: http://home.earthlink.net/~filipak/music/ Last updated: 14 April 2002 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 17 12: 9: 5 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.30.103]) by hub.freebsd.org (Postfix) with ESMTP id B8C1937B419 for ; Wed, 17 Apr 2002 12:09:02 -0700 (PDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 441381E06A; Wed, 17 Apr 2002 15:09:02 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id PAA13202; Wed, 17 Apr 2002 15:09:01 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id MAA01611; Wed, 17 Apr 2002 12:09:01 -0700 (PDT) Message-Id: <200204171909.MAA01611@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: silby@silby.com Subject: Re: What does FreeBSD do when listen queue is full ? Cc: freebsd-net@FreeBSD.ORG Date: Wed, 17 Apr 2002 12:09:00 -0700 Versions: dmail (solaris) 2.4/makemail 2.9b Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >I just did a quick look over the code, and it appears that the complete >connection queue is still intact, and takes on 3/2*listen backlog as its >length. Therefore, if sendmail is deciding to not accept() all >connections ASAP, a backlog will build up, and RSTs will be sent to >incoming connections. Boy, I hope not. Incoming SYNs should be ignored if the backlog is met, so that the client can retransmit them. I know Microsoft decided to use RST as a "my queue is full" indicator, but I hope we're not following in their footsteps!... Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 17 12:11:35 2002 Delivered-To: freebsd-net@freebsd.org Received: from smtp05.wxs.nl (smtp05.wxs.nl [195.121.6.57]) by hub.freebsd.org (Postfix) with ESMTP id 7741237B417; Wed, 17 Apr 2002 12:11:30 -0700 (PDT) Received: from there ([80.60.248.65]) by smtp05.wxs.nl (Netscape Messaging Server 4.15) with SMTP id GUQ7Z400.VTK; Wed, 17 Apr 2002 21:11:28 +0200 Content-Type: text/plain; charset="iso-8859-1" From: "Peter J. Blok" To: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org Subject: vlan traffic over ipsec tunnel Date: Wed, 17 Apr 2002 21:11:28 +0200 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020417191130.7741237B417@hub.freebsd.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi All, I'd like to accomplish the following: I have two locations, connected via an IPSEC tunnel. Is it possible to connect the vlans at both ends through the tunnel. Is this possible with existing software? What would it take to do something like this? Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 17 12:34:25 2002 Delivered-To: freebsd-net@freebsd.org Received: from patrocles.silby.com (d152.as2.nwbl0.wi.voyager.net [169.207.95.26]) by hub.freebsd.org (Postfix) with ESMTP id 87E9837B6B1 for ; Wed, 17 Apr 2002 12:28:50 -0700 (PDT) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.2/8.12.2) with ESMTP id g3I1S2Lx016597; Wed, 17 Apr 2002 20:28:02 -0500 (CDT) (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.2/8.12.2/Submit) with ESMTP id g3I1Rv2i016594; Wed, 17 Apr 2002 20:28:01 -0500 (CDT) X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Wed, 17 Apr 2002 20:27:57 -0500 (CDT) From: Mike Silbersack To: Bill Fenner Cc: freebsd-net@FreeBSD.ORG Subject: Re: What does FreeBSD do when listen queue is full ? In-Reply-To: <200204171909.MAA01611@windsor.research.att.com> Message-ID: <20020417201853.C16380-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 17 Apr 2002, Bill Fenner wrote: > Boy, I hope not. Incoming SYNs should be ignored if the backlog > is met, so that the client can retransmit them. I know Microsoft > decided to use RST as a "my queue is full" indicator, but I hope > we're not following in their footsteps!... > > Bill Actually, I read the code slightly wrong. We don't send a RST, we just silently drop the connection. However, at the point we're talking about, we're already past the 3-way handshake, so either way the connection has been lost. Heh, actually, I take that back. With a syncookie, a retransmitted ACK should end up reestablishing the connection. Clever... I think that you're referring to the case where we receive an initial SYN, and the listen queue is full. With the syncache/syncookies, this is no longer a problem; either a syn cookie is returned, or the syn is silently dropped (depending on whether or not syn cookies are enabled.) With the pre-syncache code, yes, a RST was sent at that time. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 17 12:39:54 2002 Delivered-To: freebsd-net@freebsd.org Received: from apollo.sitaranetworks.com (apollo.sitaranetworks.com [199.103.141.105]) by hub.freebsd.org (Postfix) with ESMTP id A092C37B42F for ; Wed, 17 Apr 2002 12:39:34 -0700 (PDT) Received: from rios.sitaranetworks.com (rios.sitaranetworks.com [199.103.141.78]) by apollo.sitaranetworks.com (8.10.2+Sun/8.9.3) with ESMTP id g3HJVd823700; Wed, 17 Apr 2002 15:31:39 -0400 (EDT) Received: by rios.sitaranetworks.com with Internet Mail Service (5.5.2653.19) id <27RX2XZ3>; Wed, 17 Apr 2002 15:32:01 -0400 Message-ID: <31269226357BD211979E00A0C9866DAB03755DC9@rios.sitaranetworks.com> From: Jim McGrath To: "'Mark Filipak'" Cc: freebsd-net@FreeBSD.ORG Subject: RE: Hello from Mark Filipak Date: Wed, 17 Apr 2002 15:31:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The FreeBSD vr driver supports the DFE530TX NIC. If it is not linked into the GallantWEB kernel, you have two choices. The one I would recommend based on your level of experience is to replace your NICs with ones that are supported. NICs are not expensive, and this may be a very practical approach. The second choice is to build a custom kernel. Greg Lehey's book is a good place to start. The problem with this is you are going to also have to learn all the firewall/ gateway configuration options that came packaged with the GallantWEB software. There is certainly no need to port a LINUX driver to FreeBSD. Basicly you have to redo everything that came with GallantWEB. Jim -----Original Message----- From: Mark Filipak [mailto:filipak@earthlink.net] Sent: Wednesday, April 17, 2002 2:43 PM To: freebsd-net@FreeBSD.ORG Subject: Hello from Mark Filipak Hello All! This is an introduction and a ping. I live in Mansfield, Ohio, USA, and have some very specific problems and questions. The first should probably be whether this is the right list for me.... so.... I just installed GallantWEB. It is a pre-configured version of FreeBSD 3.3 that acts as a gateway/firewall/server. It is up and running but doesn't recognize my D-Link DFE-530TX+ ethernet cards. What I have to work with ======================== I have the full FreeBSD 3.3 distribution (6 discs) from Walnut Creek. I have C source code and makefile for the D-Link DFE-530TX+ ethernet card. It was written for Linux. The name of the driver source code is Rtl8139.C. I have Greg Lehey's book: "The Complete FreeBSD". I also have the full FreeBSD 4.0 distribution (4 discs) from Walnut Creek, but I don't want to tackle that right now and would like to get 3.3 fully functional first. What I need =========== I would appreciate help/advice for porting the D-Link DFE-530TX+ driver to FreeBSD 3.3. There are at least four aspects to this project =============================================== 1 - Discovering what I need to grab from the full 3.3 distribution and put into the running system -- for example, the running system has no C compiler or linker -- and where those should go. 2 - Revising the actual C source code and makefile. 3 - Discovering where Rtl8139.o should go in the running system. 4 - Getting the system to actually use the ported driver. About me ======== I'm a 55 year old hardware engineer. I've used UNIX systems in the distant past, but I'm pretty raw. 8^) I write Java and Javascript, but don't have much experience with C -- but it is obviously very similar to Java. Global Question =============== Is this discussion list (freebsd-net) the right place for me or do I need to subscribe to a driver or hardware list? Thanks. All help is appreciated and some day I'm sure I will be in a position to pass it on. I know I'm taking my first steps down a long road. So here's a wave and a 'Hello' from me to you folks who are so far up the road that I can barely see you. Ciao -- Mark -- See my resume: http://home.earthlink.net/~filipak/resume/ See my music trade pages: http://home.earthlink.net/~filipak/music/ Last updated: 14 April 2002 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 17 12:57:12 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by hub.freebsd.org (Postfix) with ESMTP id 3E3A237B404 for ; Wed, 17 Apr 2002 12:57:05 -0700 (PDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id EDD4F4CEA8; Wed, 17 Apr 2002 15:57:00 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id PAA14290; Wed, 17 Apr 2002 15:57:00 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id MAA02194; Wed, 17 Apr 2002 12:56:59 -0700 (PDT) Message-Id: <200204171956.MAA02194@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: silby@silby.com Subject: Re: What does FreeBSD do when listen queue is full ? Cc: freebsd-net@FreeBSD.ORG Date: Wed, 17 Apr 2002 12:56:59 -0700 Versions: dmail (solaris) 2.4/makemail 2.9b Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >We don't send a RST, we just silently drop the connection. This is wrong too; it should silently drop the ACK and leave the connection in the pending queue. >However, at the point we're talking about, >we're already past the 3-way handshake I thought we were talking about the ACK that finished the 3-way handshake. >I think that you're referring to the case where we receive an initial SYN, >and the listen queue is full. I'm referring to the case where the server has specified a backlog and that backlog is full. RST is never an appropriate response in this condition, whether in response to the SYN or to the ACK of our SYN/ACK, Microsoft's implementation notwithstanding. Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 17 13: 0:45 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id 0ED8137B438 for ; Wed, 17 Apr 2002 13:00:10 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020417200009.ULVO1143.rwcrmhc51.attbi.com@InterJet.elischer.org>; Wed, 17 Apr 2002 20:00:09 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA98177; Wed, 17 Apr 2002 12:45:18 -0700 (PDT) Date: Wed, 17 Apr 2002 12:45:17 -0700 (PDT) From: Julian Elischer To: Mark Filipak Cc: freebsd-net@FreeBSD.ORG Subject: Re: Hello from Mark Filipak In-Reply-To: <3CBDC24D.3AF5B005@earthlink.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 17 Apr 2002, Mark Filipak wrote: > Hello All! Hi > > > I just installed GallantWEB. It is a pre-configured version of FreeBSD > 3.3 that acts as a gateway/firewall/server. It is up and running but > doesn't recognize my D-Link DFE-530TX+ ethernet cards. The RL driver supprts this card.. from teh 4.5 rlease notes: RealTek 8129/8139 Fast Ethernet NICs ( rl(4) driver) Accton ``Cheetah'' EN1207D (MPX 5030/5038; RealTek 8139 clone) Allied Telesyn AT2550 Allied Telesyn AT2500TX D-Link DFE-538TX <-----------------------------(**) Farallon NetLINE 10/100 PCI Genius GF100TXR (RTL8139) KTX-9130TX 10/100 Fast Ethernet NDC Communications NE100TX-E Netronix Inc. EA-1210 NetEther 10/100 OvisLink LEF-8129TX OvisLink LEF-8139TX SMC EZ Card 10/100 PCI 1211-TX > > What I have to work with > ======================== > I have the full FreeBSD 3.3 distribution (6 discs) from Walnut Creek. > > I have C source code and makefile for the D-Link DFE-530TX+ ethernet card. It was written for Linux. The name of the driver source code is Rtl8139.C. > > I have Greg Lehey's book: "The Complete FreeBSD". > > I also have the full FreeBSD 4.0 distribution (4 discs) from Walnut Creek, but I don't want to tackle that right now and would like to get 3.3 fully functional first. the driver was added for release 3.1 check: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/pci/if_rl.c and http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/pci/if_rlreg.h support for the Dlink was added at version 1.58 see note:------------------------------------------------------------ Revision 1.58 / (download) - annotate - [select for diffs], Wed Feb 21 20:54:21 2001 UTC (13 months, 3 weeks ago) by wpaul Branch: MAIN Changes since 1.57: +8 -6 lines Diff to previous 1.57 (colored) Big round of minor updates: - Use pci_get_powerstate()/pci_set_powerstate() in all the other drivers that need them so we don't have to fiddle with the PCI power management registers directly. - Use pci_enable_busmaster()/pci_enable_io() to turn on busmastering and PIO/memory mapped accesses. - Add support to the RealTek driver for the D-Link DFE-530TX+ which has a RealTek 8139 with its own PCI ID. (Submitted by Jason Wright) - Have the SiS 900/National DP83815 driver be sure to disable PME mode in sis_reset(). This apparently fixes a problem on some motherboards where the DP83815 chip fails to receive packets. (Submitted by Chuck McCrobie ) how much you can just use the 1.58 version of the file depends on what else was changed, but it's probably easier than starting withj a LINUX driver :-) you may need toonly add the following lines to your present driver: /* @@ -152,6 +152,8 @@ static struct rl_type rl_devs[] = { "Delta Electronics 8139 10/100BaseTX" }, { ADDTRON_VENDORID, ADDTRON_DEVICEID_8139, "Addtron Technolgy 8139 10/100BaseTX" }, + { DLINK_VENDORID, DLINK_DEVICEID_530TXPLUS, + "D-Link DFE-530TX+ 10/100BaseTX" }, { 0, 0, NULL } }; > > What I need > =========== > I would appreciate help/advice for porting the > D-Link DFE-530TX+ driver to FreeBSD 3.3. see above.. you are just runing an old version of freeBSD.. regards.. Julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 17 13:13:42 2002 Delivered-To: freebsd-net@freebsd.org Received: from tomts23-srv.bellnexxia.net (tomts23.bellnexxia.net [209.226.175.185]) by hub.freebsd.org (Postfix) with ESMTP id F327237B405 for ; Wed, 17 Apr 2002 13:13:37 -0700 (PDT) Received: from xena.gsicomp.on.ca ([65.95.179.11]) by tomts23-srv.bellnexxia.net (InterMail vM.4.01.03.23 201-229-121-123-20010418) with ESMTP id <20020417201336.TWCN22105.tomts23-srv.bellnexxia.net@xena.gsicomp.on.ca>; Wed, 17 Apr 2002 16:13:36 -0400 Received: from xena.gsicomp.on.ca (xena.gsicomp.on.ca [192.168.0.3]) by xena.gsicomp.on.ca (8.11.3/8.11.3) with ESMTP id g3HK27718807; Wed, 17 Apr 2002 16:02:07 -0400 (EDT) (envelope-from matt@xena.gsicomp.on.ca) Date: Wed, 17 Apr 2002 16:02:06 -0400 (EDT) From: Matthew Emmerton To: Mark Filipak Cc: freebsd-net@FreeBSD.ORG Subject: Re: Hello from Mark Filipak In-Reply-To: <3CBDC24D.3AF5B005@earthlink.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 17 Apr 2002, Mark Filipak wrote: > Hello All! > > This is an introduction and a ping. > > I live in Mansfield, Ohio, USA, and have some very specific problems and questions. The first should probably be whether this is the right list for me.... so.... > > I just installed GallantWEB. It is a pre-configured version of FreeBSD 3.3 that acts as a gateway/firewall/server. It is up and running but doesn't recognize my D-Link DFE-530TX+ ethernet cards. > > What I have to work with > ======================== > I have the full FreeBSD 3.3 distribution (6 discs) from Walnut Creek. > > I have C source code and makefile for the D-Link DFE-530TX+ ethernet > card. It was written for Linux. The name of the driver source code is > Rtl8139.C. > > I have Greg Lehey's book: "The Complete FreeBSD". > > I also have the full FreeBSD 4.0 distribution (4 discs) from Walnut > Creek, but I don't want to tackle that right now and would like to get > 3.3 fully functional first. The DFE-530TX+ driver was first supported in FreeBSD 4.4. You'll inflict the least amount of pain if you just get a copy of FreeBSD 4.4 or 4.5. You might be able to backfit this driver to FreeBSD 4.0 -- I've successfully done it for 4.2 and 4.3. -- Matt Emmerton To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 17 13:32:56 2002 Delivered-To: freebsd-net@freebsd.org Received: from patrocles.silby.com (d152.as2.nwbl0.wi.voyager.net [169.207.95.26]) by hub.freebsd.org (Postfix) with ESMTP id 57B7637B417 for ; Wed, 17 Apr 2002 13:32:47 -0700 (PDT) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.2/8.12.2) with ESMTP id g3I2WaLx016821; Wed, 17 Apr 2002 21:32:36 -0500 (CDT) (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.2/8.12.2/Submit) with ESMTP id g3I2WZJn016818; Wed, 17 Apr 2002 21:32:35 -0500 (CDT) X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Wed, 17 Apr 2002 21:32:34 -0500 (CDT) From: Mike Silbersack To: Bill Fenner Cc: freebsd-net@FreeBSD.ORG Subject: Re: What does FreeBSD do when listen queue is full ? In-Reply-To: <200204171956.MAA02194@windsor.research.att.com> Message-ID: <20020417211402.O16380-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 17 Apr 2002, Bill Fenner wrote: > >We don't send a RST, we just silently drop the connection. > > This is wrong too; it should silently drop the ACK and leave the > connection in the pending queue. Hm, I suppose that could work. It still feels icky, though; if the problem is that the app is building up a backlog, I'd think that it should be handled by increasing the length of the backlog queue. OTOH, keeping a syncache socket around waiting for an ack to be retransmitted IS better than dropping the connection... Accept filters might interact badly with such a change, that'd have to be checked. Also, this would open up the potential that one bad app could fill the syncache. That would require a lot of work though; someone with a local account can already do much worse things. How do the apps which try to rate-limit connections (OpenSSH, sendmail) do it? Would that behavior be defeated with your proposed changes? I'm not opposed to your idea, I'd just like to fully understand the implications before any changes are made. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 17 14:38:20 2002 Delivered-To: freebsd-net@freebsd.org Received: from bushwire.net (f1.bushwire.net [66.92.187.124]) by hub.freebsd.org (Postfix) with SMTP id 92D7037B426 for ; Wed, 17 Apr 2002 14:38:08 -0700 (PDT) Received: (qmail 9911 invoked by uid 1001); 17 Apr 2002 21:38:05 -0000 Date: Wed, 17 Apr 2002 21:38:05 +0000 From: Mark Delany To: Mike Silbersack Cc: Bill Fenner , freebsd-net@FreeBSD.ORG Subject: Re: What does FreeBSD do when listen queue is full ? Message-ID: <20020417213805.A91259@bushwire.net> References: <200204171956.MAA02194@windsor.research.att.com> <20020417211402.O16380-100000@patrocles.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020417211402.O16380-100000@patrocles.silby.com>; from silby@silby.com on Wed, Apr 17, 2002 at 09:32:34PM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, Apr 17, 2002 at 09:32:34PM -0500, Mike Silbersack allegedly wrote: > > This is wrong too; it should silently drop the ACK and leave the > > connection in the pending queue. > How do the apps which try to rate-limit connections (OpenSSH, sendmail) do > it? Would that behavior be defeated with your proposed changes? Are we discussing what happens when the number of pending connections exceeds the backlog? If the suggestion is to leave such connections pending then the question becomes what's the real purpose of backlog? If the suggestion is something else, then excuse me for misconstruing as it makes my following comments irrelevant. FWIW, I use backlog as a method of indicating how long a client can expect to wait before getting serviced. This is especially useful with servers behind load balancers. For arguments sake, say I have a web server that I know handles 10 requests per second and I want to offer a 2 second response time. To do this I set the backlog to 20 on each of the web servers and configure the load balancer to periodically check each server by attempting to establish a session. If the load balancer connection attempt fails then it knows that that particular server already has 2 seconds worth of work so it should not consider that server as available at the moment (note that some load balancer configurations mean that connection counting is not possible and, oftentimes they don't do so accurately anyway). By making the backlog effectively infinite, my application cannot give feedback on anticipated service times and the load balancers will have to timeout on their periodic checks. Neither sounds very satisfactory to me. To be sure there are philosophical arguments about whether the client or the server should decide on waiting times or indeed whether there are better load balancer strategies, but I think genuine cases exist where a server wants to communicate service times back to the client and backlog strikes me as a reasonable way to do this. Regards. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 17 15:15:28 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by hub.freebsd.org (Postfix) with ESMTP id B2AEB37B41A for ; Wed, 17 Apr 2002 15:15:13 -0700 (PDT) Received: from vicor-nb.com (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 7E2E65922F for ; Wed, 17 Apr 2002 15:15:13 -0700 (PDT) Message-ID: <3CBDF3F1.75848D5E@vicor-nb.com> Date: Wed, 17 Apr 2002 15:15:13 -0700 From: Julian Elischer Organization: VICOR X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.5-STABLE i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: net@freebsd.org Subject: VLANS in Netgraph.. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Someone was writing some VLAN code using Netgraph. I think they told me they were almost done and it just required some documentation to be done.. since then I have heard nothing. It that was YOU then if I dropped the ball, I'm sorry. Either way, if you know who/where/when let me know.. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 17 15:26:17 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.datapipe.com (mail.datapipe.com [64.27.120.46]) by hub.freebsd.org (Postfix) with ESMTP id 004BE37B41B; Wed, 17 Apr 2002 15:26:06 -0700 (PDT) Received: from tool [64.27.64.34] by mail.datapipe.com with ESMTP (SMTPD32-6.06) id A67D20BA00BC; Wed, 17 Apr 2002 18:26:05 -0400 Date: Wed, 17 Apr 2002 18:26:05 -0400 (EDT) From: Matt Ayres X-X-Sender: matta@tool.teb2.datapipe.net To: "Peter J. Blok" Cc: freebsd-hackers@FreeBSD.ORG, Subject: Re: vlan traffic over ipsec tunnel In-Reply-To: <20020417191130.7741237B417@hub.freebsd.org> Message-ID: <20020417182441.B1723-100000@tool.teb2.datapipe.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I don't know of a way to do this in FreeBSD, however OpenBSD's bridging code does support this. man brconfig on an OpenBSD box. Simply bridging a tunneling device and an ethernet device might work under FreeBSD. Matt On Wed, 17 Apr 2002, Peter J. Blok wrote: > Hi All, > > I'd like to accomplish the following: I have two locations, connected via an > IPSEC tunnel. Is it possible to connect the vlans at both ends through the > tunnel. > > Is this possible with existing software? What would it take to do something > like this? > > Peter > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 17 15:40:12 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 46C0737B404 for ; Wed, 17 Apr 2002 15:40:09 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020417224008.ZHMW1901.rwcrmhc52.attbi.com@InterJet.elischer.org>; Wed, 17 Apr 2002 22:40:08 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id PAA98791; Wed, 17 Apr 2002 15:22:52 -0700 (PDT) Date: Wed, 17 Apr 2002 15:22:51 -0700 (PDT) From: Julian Elischer To: Attila Nagy Cc: freebsd-net@freebsd.org Subject: Re: Bridging vlan0 with de0 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Szia! el aptom azt email-szimet? (probably unintelligable :-) did I give you this guy's address? On Thu, 20 Dec 2001, Julian Elischer wrote: > it is being donated by a french fellow. > He is just polishing it. > I will try commit it in the next few days. > > On Thu, 20 Dec 2001, Attila Nagy wrote: > > > Hello, > > > > > I believe you can bridge a vlan interface if you use the new upcoming > > > netgraph vlan node. It shuold be committed soon. (Vlans done the way > > > it should have been done ;-) > > Is it possible that this one will fix my FEC and VLAN problems? Is there a > > patch for -STABLE out there? I would be glad to test this :) > > > > -------------------------------------------------------------------------- > > Attila Nagy e-mail: Attila.Nagy@fsn.hu > > Budapest Polytechnic (BMF.HU) @work: +361 210 1415 (194) > > H-1084 Budapest, Tavaszmezo u. 15-17. cell.: +3630 306 6758 > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 17 15:49:33 2002 Delivered-To: freebsd-net@freebsd.org Received: from web20505.mail.yahoo.com (web20505.mail.yahoo.com [216.136.226.140]) by hub.freebsd.org (Postfix) with SMTP id 1589537B41D for ; Wed, 17 Apr 2002 15:49:17 -0700 (PDT) Message-ID: <20020417224913.8883.qmail@web20505.mail.yahoo.com> Received: from [169.139.115.185] by web20505.mail.yahoo.com via HTTP; Wed, 17 Apr 2002 15:49:13 PDT Date: Wed, 17 Apr 2002 15:49:13 -0700 (PDT) From: jon Subject: 3com pcmcia nic To: net@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1589565195-1019083753=:4426" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --0-1589565195-1019083753=:4426 Content-Type: text/plain; charset=us-ascii can a 3com pcmcia nic be put in promiscuous mode? if so what models? thanks -- Jon mailto:juostaus@yahoo.com --------------------------------- Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax --0-1589565195-1019083753=:4426 Content-Type: text/html; charset=us-ascii
   can a 3com pcmcia nic be put in promiscuous mode? if so what
   models? thanks

--

Jon                          mailto:juostaus@yahoo.com


Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax --0-1589565195-1019083753=:4426-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 17 16:20: 9 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id A1C4537B400 for ; Wed, 17 Apr 2002 16:20:07 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020417232007.PUN1901.rwcrmhc52.attbi.com@InterJet.elischer.org>; Wed, 17 Apr 2002 23:20:07 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA98994; Wed, 17 Apr 2002 16:16:25 -0700 (PDT) Date: Wed, 17 Apr 2002 16:16:23 -0700 (PDT) From: Julian Elischer To: Maksim Yevmenkin Cc: Roman Kurakin , freebsd-net@FreeBSD.ORG Subject: Re: 5.Current Netgraph, Mutex In-Reply-To: <3CBDA43E.87D2E163@digisle.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I can't find this code, where is it? On Wed, 17 Apr 2002, Maksim Yevmenkin wrote: > Roman Kurakin wrote: > > > #if __FreeBSD_version >= 500000 > > mtx_init (&d->queue.ifq_mtx, "cp_queue", MTX_DEF); > > mtx_init (&d->hi_queue.ifq_mtx, "cp_queue_hi", MTX_DEF); > > #endif > > my guess would be that you forgot to call mtx_destroy() for > queue and hi_queue mutexes. > > thanks, > max > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 17 16:40:15 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id 228EC37B417 for ; Wed, 17 Apr 2002 16:40:07 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020417234006.PEWD12144.rwcrmhc53.attbi.com@InterJet.elischer.org>; Wed, 17 Apr 2002 23:40:06 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA99042; Wed, 17 Apr 2002 16:25:32 -0700 (PDT) Date: Wed, 17 Apr 2002 16:25:31 -0700 (PDT) From: Julian Elischer To: Maksim Yevmenkin Cc: Roman Kurakin , freebsd-net@FreeBSD.ORG Subject: Re: 5.Current Netgraph, Mutex In-Reply-To: <3CBDA43E.87D2E163@digisle.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Roman, Having finally found the original mail, I concur. it looks like you have 'leaked' mutexes. (and the witness code accesses all mutexes even after the driver has unloaded... (*boom*)) I have not looked at the locks yet but you may be able to take advantage of netgraph's inherrant locking and queueing to simplify your usage of mutexes in some cases. (But I have to look at it more..) On Wed, 17 Apr 2002, Maksim Yevmenkin wrote: > Roman Kurakin wrote: > > > #if __FreeBSD_version >= 500000 > > mtx_init (&d->queue.ifq_mtx, "cp_queue", MTX_DEF); > > mtx_init (&d->hi_queue.ifq_mtx, "cp_queue_hi", MTX_DEF); > > #endif > > my guess would be that you forgot to call mtx_destroy() for > queue and hi_queue mutexes. > > thanks, > max > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 17 16:50:20 2002 Delivered-To: freebsd-net@freebsd.org Received: from patrocles.silby.com (d84.as9.nwbl0.wi.voyager.net [169.207.132.212]) by hub.freebsd.org (Postfix) with ESMTP id DB6F637B404 for ; Wed, 17 Apr 2002 16:50:13 -0700 (PDT) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.2/8.12.2) with ESMTP id g3I5nnLx017543; Thu, 18 Apr 2002 00:49:49 -0500 (CDT) (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.2/8.12.2/Submit) with ESMTP id g3I5nj8O017540; Thu, 18 Apr 2002 00:49:47 -0500 (CDT) X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Thu, 18 Apr 2002 00:49:45 -0500 (CDT) From: Mike Silbersack To: Mark Delany Cc: Bill Fenner , Subject: Re: What does FreeBSD do when listen queue is full ? In-Reply-To: <20020417213805.A91259@bushwire.net> Message-ID: <20020418004301.K17506-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 17 Apr 2002, Mark Delany wrote: > Are we discussing what happens when the number of pending connections > exceeds the backlog? If the suggestion is to leave such connections > pending then the question becomes what's the real purpose of backlog? Yes, that is what we're discussing. > For arguments sake, say I have a web server that I know handles 10 > requests per second and I want to offer a 2 second response time. To > do this I set the backlog to 20 on each of the web servers and > configure the load balancer to periodically check each server by > attempting to establish a session. > > If the load balancer connection attempt fails then it knows that that > particular server already has 2 seconds worth of work so it should not > consider that server as available at the moment (note that some load > balancer configurations mean that connection counting is not possible > and, oftentimes they don't do so accurately anyway). Well, 4.5+ would already be considered broken by your standards; it does not send a RST when dropping connections that have exceeded the backlog. I understand your method, but it seems perhaps a bit too simplistic. Have you considered having the load balancer make a simple request (fetching a static piece of html) every .25 seconds or so? The total response time from such connections would presumably give you a much better picture of how loaded the server is. If we do go ahead and make the changes that Bill proposes, it should be possible to add a sysctl that would cause a RST to be emitted rather than the connection to be returned to the syncache. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 17 16:51:15 2002 Delivered-To: freebsd-net@freebsd.org Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by hub.freebsd.org (Postfix) with ESMTP id 3E81837B405; Wed, 17 Apr 2002 16:51:05 -0700 (PDT) Received: (from uucp@localhost) by srv1.cosmo-project.de (8.11.6/8.11.6) with UUCP id g3HNowQ84236; Thu, 18 Apr 2002 01:50:58 +0200 (CEST) (envelope-from ticso@cicely9.cicely.de) Received: from mail.cicely.de (cicely20.cicely.de [10.1.1.22]) by cicely5.cicely.de (8.12.1/8.12.1) with ESMTP id g3HNiE6e001336; Thu, 18 Apr 2002 01:44:18 +0200 (CEST)?g (envelope-from ticso@cicely9.cicely.de) Received: from cicely9.cicely.de (cicely9.cicely.de [10.1.1.11]) by mail.cicely.de (8.11.0/8.11.0) with ESMTP id g3HNiDX06009; Thu, 18 Apr 2002 01:44:13 +0200 (CEST) Received: (from ticso@localhost) by cicely9.cicely.de (8.11.6/8.11.6) id g3HNiBq72286; Thu, 18 Apr 2002 01:44:11 +0200 (CEST) (envelope-from ticso) Date: Thu, 18 Apr 2002 01:44:11 +0200 From: Bernd Walter To: "Peter J. Blok" Cc: freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: vlan traffic over ipsec tunnel Message-ID: <20020417234411.GI70839@cicely9.cicely.de> References: <20020417191130.7741237B417@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020417191130.7741237B417@hub.freebsd.org> User-Agent: Mutt/1.3.28i X-Operating-System: FreeBSD cicely9.cicely.de 5.0-CURRENT alpha Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, Apr 17, 2002 at 09:11:28PM +0200, Peter J. Blok wrote: > Hi All, > > I'd like to accomplish the following: I have two locations, connected via an > IPSEC tunnel. Is it possible to connect the vlans at both ends through the > tunnel. > > Is this possible with existing software? What would it take to do something > like this? With netgraph you can bridge ethernets over IP which then gets encypted via ipsec - at least in theory. But If you only want to connect IP based lans you should route instead. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 17 17:11:35 2002 Delivered-To: freebsd-net@freebsd.org Received: from hall.mail.mindspring.net (hall.mail.mindspring.net [207.69.200.60]) by hub.freebsd.org (Postfix) with ESMTP id 4D67337B405 for ; Wed, 17 Apr 2002 17:11:29 -0700 (PDT) Received: from user-2ivemtr.dsl.mindspring.com ([165.247.91.187] helo=compaq) by hall.mail.mindspring.net with smtp (Exim 3.33 #1) id 16xzWJ-00072n-00 for freebsd-net@freebsd.org; Wed, 17 Apr 2002 20:11:27 -0400 Message-ID: <003a01c1e66c$deff1500$bb5bf7a5@compaq> From: "Naga R Narayanaswamy" To: Subject: xauth support in ipsec ? Date: Wed, 17 Apr 2002 20:06:20 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org All, Probably this mail should be directed at the kame newsgroup. But anyone know if xauth authorization scheme which is in draft stage is incorporated in the ipsec protocol in FreeBSD ? I know some corporate vpn gateways started incorporating xauth so, standard based clients will fail establishment process. (Ref: http://www.ietf.org/internet-drafts/draft-beaulieu-ike-xauth-02.txt ) Thanks! Naga. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 17 17:26:46 2002 Delivered-To: freebsd-net@freebsd.org Received: from avocet.prod.itd.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by hub.freebsd.org (Postfix) with ESMTP id 8C0A037B417; Wed, 17 Apr 2002 17:26:32 -0700 (PDT) Received: from pool0056.cvx22-bradley.dialup.earthlink.net ([209.179.198.56] helo=mindspring.com) by avocet.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16xzks-0001RP-00; Wed, 17 Apr 2002 17:26:30 -0700 Message-ID: <3CBE129B.BE50CD2B@mindspring.com> Date: Wed, 17 Apr 2002 17:26:03 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Peter J. Blok" Cc: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org Subject: Re: vlan traffic over ipsec tunnel References: <20020417191130.7741237B417@hub.freebsd.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org "Peter J. Blok" wrote: > I'd like to accomplish the following: I have two locations, connected via an > IPSEC tunnel. Is it possible to connect the vlans at both ends through the > tunnel. > > Is this possible with existing software? What would it take to do something > like this? Bridging doesn't work with the vlanX interface currently in FreeBSD. Julian promised (last December) that he would be committing a VLAN netgraph node for doing VLAN "the right way", but I have not seen anything. I tried to ping him twice on this, but I think he's pretending not to get the pings... 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 17 17:28:44 2002 Delivered-To: freebsd-net@freebsd.org Received: from avocet.prod.itd.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by hub.freebsd.org (Postfix) with ESMTP id 73C7237B404; Wed, 17 Apr 2002 17:28:31 -0700 (PDT) Received: from pool0056.cvx22-bradley.dialup.earthlink.net ([209.179.198.56] helo=mindspring.com) by avocet.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16xzmn-0003Vb-00; Wed, 17 Apr 2002 17:28:29 -0700 Message-ID: <3CBE130B.4CD7C5E7@mindspring.com> Date: Wed, 17 Apr 2002 17:27:55 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Peter J. Blok" , freebsd-hackers@freebsd.org, freebsd-net@freebsd.org Subject: Re: vlan traffic over ipsec tunnel References: <20020417191130.7741237B417@hub.freebsd.org> <3CBE129B.BE50CD2B@mindspring.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Terry Lambert wrote: > Bridging doesn't work with the vlanX interface currently in > FreeBSD. > > Julian promised (last December) that he would be committing a > VLAN netgraph node for doing VLAN "the right way", but I have > not seen anything. I tried to ping him twice on this, but I > think he's pretending not to get the pings... 8-). Spoke too soon... just saw his posting to -net... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 17 18:13:25 2002 Delivered-To: freebsd-net@freebsd.org Received: from bushwire.net (f1.bushwire.net [66.92.187.124]) by hub.freebsd.org (Postfix) with SMTP id 9178737B400 for ; Wed, 17 Apr 2002 18:13:22 -0700 (PDT) Received: (qmail 60609 invoked by uid 1001); 18 Apr 2002 01:13:20 -0000 Date: 18 Apr 2002 01:13:20 +0000 Message-ID: <20020418011320.60326.qmail@prefix.bushwire.net> From: "Mark Delany" To: "Mike Silbersack" Cc: "Bill Fenner" , freebsd-net@FreeBSD.ORG Subject: Re: What does FreeBSD do when listen queue is full ? References: <20020417213805.A91259@bushwire.net> <20020418004301.K17506-100000@patrocles.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020418004301.K17506-100000@patrocles.silby.com>; from silby@silby.com on Thu, Apr 18, 2002 at 12:49:45AM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, Apr 18, 2002 at 12:49:45AM -0500, Mike Silbersack allegedly wrote: > > On Wed, 17 Apr 2002, Mark Delany wrote: > > > Are we discussing what happens when the number of pending connections > > exceeds the backlog? If the suggestion is to leave such connections > > pending then the question becomes what's the real purpose of backlog? > > Yes, that is what we're discussing. Goodo. > > For arguments sake, say I have a web server that I know handles 10 > Well, 4.5+ would already be considered broken by your standards; it does > not send a RST when dropping connections that have exceeded the backlog. Agreed. I think that RST is the right choice actually. > I understand your method, but it seems perhaps a bit too simplistic. Have Right. It was really only intended as an example to demonstrate the concept. It raises the question as to the purpose of backlog. Is it really only intended as a resource hint or does it represent a firm threshold beyond which the OS should act differently? If the latter, then the purpose of the threshold can only be of real benefit to the client as the server can trivially track its own resource usage, true? So, if backlog is a threshold for communicating to clients, then I think RST is the right choice as it communicates server state unambiguously. Conversely dropping the ACK is ambiguous to the client - is the server busy or is the network dropping packets? Additional dropping the ACK is a painfully slow way to communicate as the client has to timeout the connection attempt to find out that service is not forthcoming. Regards. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 17 21:10:45 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by hub.freebsd.org (Postfix) with ESMTP id 7E09F37B41A for ; Wed, 17 Apr 2002 21:10:41 -0700 (PDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id EF20F4CE5C; Thu, 18 Apr 2002 00:10:40 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id AAA20936; Thu, 18 Apr 2002 00:10:40 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id VAA07075; Wed, 17 Apr 2002 21:10:40 -0700 (PDT) Message-Id: <200204180410.VAA07075@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: markd@BushWire.Net Subject: Re: What does FreeBSD do when listen queue is full ? Cc: freebsd-net@FreeBSD.ORG References: <20020417213805.A91259@bushwire.net> <20020418004301.K17506-100000@patrocles.silby.com> <20020418011320.60326.qmail@prefix.bushwire.net> Date: Wed, 17 Apr 2002 21:10:39 -0700 Versions: dmail (solaris) 2.4/makemail 2.9b Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >So, if backlog is a threshold for communicating to clients, then I >think RST is the right choice as it communicates server state >unambiguously. I disagree; RST does not communicate server state unambiguously. RST is used in response to an erroneous packet on a synchronized connection, in response to a packet to a connection that doesn't exist (e.g. SYN to a closed port), or in response to an ACK that acknowledges something that hasn't been sent. None of these applies to this situation. Dropping the ACK and allowing the TCP backoff to retry the connection is exactly the right behavior when there is one server supplying the service, because the retries are subject to exponential backoffs. Please don't break the normal case for the load-balanced case. Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 17 21:36:58 2002 Delivered-To: freebsd-net@freebsd.org Received: from patrocles.silby.com (d84.as9.nwbl0.wi.voyager.net [169.207.132.212]) by hub.freebsd.org (Postfix) with ESMTP id D822837B416 for ; Wed, 17 Apr 2002 21:36:54 -0700 (PDT) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.2/8.12.2) with ESMTP id g3IAakLx018797; Thu, 18 Apr 2002 05:36:46 -0500 (CDT) (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.2/8.12.2/Submit) with ESMTP id g3IAaibu018794; Thu, 18 Apr 2002 05:36:45 -0500 (CDT) X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Thu, 18 Apr 2002 05:36:44 -0500 (CDT) From: Mike Silbersack To: Mark Delany Cc: Bill Fenner , Subject: Re: What does FreeBSD do when listen queue is full ? In-Reply-To: <20020418011320.60326.qmail@prefix.bushwire.net> Message-ID: <20020418053441.L17827-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 18 Apr 2002, Mark Delany wrote: > It raises the question as to the purpose of backlog. Is it really only > intended as a resource hint or does it represent a firm threshold > beyond which the OS should act differently? > > If the latter, then the purpose of the threshold can only be of real > benefit to the client as the server can trivially track its own > resource usage, true? Well, the problem with being fast and free with RSTs is that I don't think many clients react well to them. Hence, in the standalone server case I suspect that Bill's idea of ignoring the ACK and waiting for it to be retransmitted is the better idea. After that is done, adding a sysctl which enables the RST functionality wouldn't be a problem if you think that it may be beneficial for those using load balancers. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 18 0:28:42 2002 Delivered-To: freebsd-net@freebsd.org Received: from s30.crl.hitachi.co.jp (kame202.kame.net [203.178.141.202]) by hub.freebsd.org (Postfix) with ESMTP id 5CE5A37B41B; Thu, 18 Apr 2002 00:28:32 -0700 (PDT) Received: from s30.crl.hitachi.co.jp (localhost [127.0.0.1]) by s30.crl.hitachi.co.jp (8.12.2/8.12.2) with ESMTP id g3I7SCNs018552; Thu, 18 Apr 2002 16:28:13 +0900 (JST) (envelope-from suz@crl.hitachi.co.jp) Date: Thu, 18 Apr 2002 16:28:11 +0900 Message-ID: From: SUZUKI Shinsuke To: ru@FreeBSD.ORG, jayanth@FreeBSD.ORG Cc: freebsd-net@FreeBSD.ORG Subject: Questions on ip_output.c's patch for FreeBSD-SA-02:21.tcpip In-Reply-To: <200204171923.g3HJNg958905@freefall.freebsd.org> References: <200204171923.g3HJNg958905@freefall.freebsd.org> User-Agent: User-Agent: Wanderlust/2.9.9 (Unchained Melody) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: IP Network Research Center, R & D Group, Hitachi, Ltd, Japan MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: multipart/mixed; boundary="Multipart_Thu_Apr_18_16:28:11_2002-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --Multipart_Thu_Apr_18_16:28:11_2002-1 Content-Type: text/plain; charset=US-ASCII Hello all, #I'm not sure where to discuss this issue. So please forward this #mail or reply with CC for the appropriate person or ML. > FreeBSD-SA-02:21.tcpip Security Advisory > Topic: routing table memory leak > Category: core > Module: net > Announced: 2002-04-17 > Credits: Jayanth Vijayaraghavan > Ruslan Ermilov I have one proposal for this fix. In this patch, ip_output() is assumed to receive non-NULL rtentry argument from its caller. Two files are patched to support this, so there's no problem right now. However if some new module calls ip_output() carelessly with NULL rtentry argument, kernel would crash. I don't think it is a good change. KAME rewrote the attached patch to improve this point: - This memory leak is fixed, of course:-) (at least I confirmed on 5-current). - Non-NULL rtentry for ip_output() is still accepted. So only a patch in ip_output.c is enough. Could you please correct me if I'm wrong, or consider adopting this patch? (it's a patch for 5-current, but it's not so difficult to modify it for 4-stable and 4.5-release branch) Thanks, ---- SUZUKI, Shinsuke / KAME Project --Multipart_Thu_Apr_18_16:28:11_2002-1 Content-Type: text/plain; charset=US-ASCII Index: ip_output.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_output.c,v retrieving revision 1.154 diff -u -u -r1.154 ip_output.c --- ip_output.c 1 Apr 2002 21:31:06 -0000 1.154 +++ ip_output.c 18 Apr 2002 07:11:01 -0000 @@ -123,12 +123,12 @@ struct mbuf *m = m0; int hlen = sizeof (struct ip); int len, off, error = 0; + struct route iproute; struct sockaddr_in *dst; struct in_ifaddr *ia; int isbroadcast, sw_csum; struct in_addr pkt_dst; #ifdef IPSEC - struct route iproute; struct socket *so = NULL; struct secpolicy *sp = NULL; #endif @@ -189,9 +189,6 @@ #ifdef DIAGNOSTIC if ((m->m_flags & M_PKTHDR) == 0) panic("ip_output no HDR"); - if (!ro) - panic("ip_output no route, proto = %d", - mtod(m, struct ip *)->ip_p); #endif if (opt) { m = ip_insertoptions(m, opt, &len); @@ -217,6 +214,11 @@ hlen = IP_VHL_HL(ip->ip_vhl) << 2; } + /* Route packet. */ + if (ro == NULL) { + ro = &iproute; + bzero(ro, sizeof(*ro)); + } dst = (struct sockaddr_in *)&ro->ro_dst; /* * If there is a cached route, @@ -1004,11 +1006,11 @@ ipstat.ips_fragmented++; } done: -#ifdef IPSEC if (ro == &iproute && ro->ro_rt) { RTFREE(ro->ro_rt); ro->ro_rt = NULL; } +#ifdef IPSEC if (sp != NULL) { KEYDEBUG(KEYDEBUG_IPSEC_STAMP, printf("DP ip_output call free SP:%p\n", sp)); --Multipart_Thu_Apr_18_16:28:11_2002-1-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 18 0:34:28 2002 Delivered-To: freebsd-net@freebsd.org Received: from sofia.digsys.bg (sofia.digsys.bg [193.68.3.250]) by hub.freebsd.org (Postfix) with ESMTP id 7F3CE37B404 for ; Thu, 18 Apr 2002 00:34:18 -0700 (PDT) Received: from comm.uni-svishtov.bg (ns.uni-svishtov.bg [193.68.172.1]) by sofia.digsys.bg (8.9.0/8.9.0) with ESMTP id KAA10234; Thu, 18 Apr 2002 10:33:56 +0300 (EEST) Received: from grinch.uni-svishtov.bg (grinch.uni-svishtov.bg [193.68.172.9]) by comm.uni-svishtov.bg (8.9.3/8.9.3) with ESMTP id DAA18627; Thu, 18 Apr 2002 03:43:19 +0300 (EEST) Received: from deckland (deckland.uni-svishtov.bg [193.68.173.82]) by grinch.uni-svishtov.bg (8.12.1/8.12.1) with SMTP id g3I0hE1w010805; Thu, 18 Apr 2002 03:43:17 +0300 (EEST) Message-ID: <001901c1e672$07bf1cb0$52ad44c1@deckland> From: "Radoslav Vasilev" To: "Bernd Walter" Cc: References: <20020417191130.7741237B417@hub.freebsd.org> <20020417234411.GI70839@cicely9.cicely.de> Subject: Re: vlan traffic over ipsec tunnel Date: Thu, 18 Apr 2002 03:43:17 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Scanned-By: MIMEDefang 2.6 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org How in practise one can bridge two separate lans through netgraph/whatever ehternet over IP) ? ----- Original Message ----- From: "Bernd Walter" To: "Peter J. Blok" Cc: ; Sent: Thursday, April 18, 2002 2:44 AM Subject: Re: vlan traffic over ipsec tunnel > On Wed, Apr 17, 2002 at 09:11:28PM +0200, Peter J. Blok wrote: > > Hi All, > > > > I'd like to accomplish the following: I have two locations, connected via an > > IPSEC tunnel. Is it possible to connect the vlans at both ends through the > > tunnel. > > > > Is this possible with existing software? What would it take to do something > > like this? > > With netgraph you can bridge ethernets over IP which then gets > encypted via ipsec - at least in theory. > But If you only want to connect IP based lans you should route instead. > > -- > B.Walter COSMO-Project http://www.cosmo-project.de > ticso@cicely.de Usergroup info@cosmo-project.de > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 18 1: 1:56 2002 Delivered-To: freebsd-net@freebsd.org Received: from scribble.fsn.hu (scribble.fsn.hu [193.224.40.95]) by hub.freebsd.org (Postfix) with SMTP id 6566737B41A for ; Thu, 18 Apr 2002 01:01:52 -0700 (PDT) Received: (qmail 24428 invoked by uid 1000); 18 Apr 2002 08:03:36 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 18 Apr 2002 08:03:36 -0000 Date: Thu, 18 Apr 2002 10:03:36 +0200 (CEST) From: Attila Nagy To: Julian Elischer Cc: freebsd-net@freebsd.org Subject: Re: Bridging vlan0 with de0 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello, > Szia! > el aptom azt email-szimet? (probably unintelligable :-) Julian, you are so nice :) Elkerhetem az email cimet? This is the right sentence. > did I give you this guy's address? Yes. He is EGLES Guillaume I have the mail with the source and some docs, so I can send you that if you get no feedback. > > > Is it possible that this one will fix my FEC and VLAN problems? Is there a > > > patch for -STABLE out there? I would be glad to test this :) FEC+VLANs, anyone? :) --------[ Free Software ISOs - ftp://ftp.fsn.hu/pub/CDROM-Images/ ]------- Attila Nagy e-mail: Attila.Nagy@fsn.hu Free Software Network (FSN.HU) phone @work: +361 210 1415 (194) cell.: +3630 306 6758 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 18 2:10:55 2002 Delivered-To: freebsd-net@freebsd.org Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by hub.freebsd.org (Postfix) with ESMTP id 9B7E837B41D for ; Thu, 18 Apr 2002 02:10:50 -0700 (PDT) Received: (from uucp@localhost) by srv1.cosmo-project.de (8.11.6/8.11.6) with UUCP id g3I9ANd91928; Thu, 18 Apr 2002 11:10:23 +0200 (CEST) (envelope-from ticso@cicely9.cicely.de) Received: from mail.cicely.de (cicely20.cicely.de [10.1.1.22]) by cicely5.cicely.de (8.12.1/8.12.1) with ESMTP id g3I91W6e004672; Thu, 18 Apr 2002 11:01:32 +0200 (CEST)?g (envelope-from ticso@cicely9.cicely.de) Received: from cicely9.cicely.de (cicely9.cicely.de [10.1.1.11]) by mail.cicely.de (8.11.0/8.11.0) with ESMTP id g3I91VX07096; Thu, 18 Apr 2002 11:01:31 +0200 (CEST) Received: (from ticso@localhost) by cicely9.cicely.de (8.11.6/8.11.6) id g3I91VN73633; Thu, 18 Apr 2002 11:01:31 +0200 (CEST) (envelope-from ticso) Date: Thu, 18 Apr 2002 11:01:30 +0200 From: Bernd Walter To: Radoslav Vasilev Cc: freebsd-net@freebsd.org Subject: Re: vlan traffic over ipsec tunnel Message-ID: <20020418090130.GK70839@cicely9.cicely.de> References: <20020417191130.7741237B417@hub.freebsd.org> <20020417234411.GI70839@cicely9.cicely.de> <001901c1e672$07bf1cb0$52ad44c1@deckland> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001901c1e672$07bf1cb0$52ad44c1@deckland> User-Agent: Mutt/1.3.28i X-Operating-System: FreeBSD cicely9.cicely.de 5.0-CURRENT alpha Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, Apr 18, 2002 at 03:43:17AM +0300, Radoslav Vasilev wrote: > How in practise one can bridge two separate lans through netgraph/whatever > ehternet over IP) ? Take a look into /usr/share/examples/netgraph. There is an example for ethernet bridging and udp tunnel. You just have to put ksocket nodes between the ethernet nodes instead of connecting them directly. > ----- Original Message ----- > From: "Bernd Walter" > To: "Peter J. Blok" > Cc: ; > Sent: Thursday, April 18, 2002 2:44 AM > Subject: Re: vlan traffic over ipsec tunnel > > > > On Wed, Apr 17, 2002 at 09:11:28PM +0200, Peter J. Blok wrote: > > > Hi All, > > > > > > I'd like to accomplish the following: I have two locations, connected > via an > > > IPSEC tunnel. Is it possible to connect the vlans at both ends through > the > > > tunnel. > > > > > > Is this possible with existing software? What would it take to do > something > > > like this? > > > > With netgraph you can bridge ethernets over IP which then gets > > encypted via ipsec - at least in theory. > > But If you only want to connect IP based lans you should route instead. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 18 2:47:47 2002 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 67F5B37B416; Thu, 18 Apr 2002 02:47:29 -0700 (PDT) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id g3I9lM729958; Thu, 18 Apr 2002 12:47:22 +0300 (EEST) (envelope-from ru) Date: Thu, 18 Apr 2002 12:47:22 +0300 From: Ruslan Ermilov To: SUZUKI Shinsuke Cc: Garrett Wollman , jayanth@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Questions on ip_output.c's patch for FreeBSD-SA-02:21.tcpip Message-ID: <20020418094722.GG98788@sunbay.com> References: <200204171923.g3HJNg958905@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="17/8oYur5Y32USnW" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --17/8oYur5Y32USnW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 18, 2002 at 04:28:11PM +0900, SUZUKI Shinsuke wrote: > Hello all, >=20 > #I'm not sure where to discuss this issue. So please forward this > #mail or reply with CC for the appropriate person or ML. >=20 > > FreeBSD-SA-02:21.tcpip Security Ad= visory > > Topic: routing table memory leak > > Category: core > > Module: net > > Announced: 2002-04-17 > > Credits: Jayanth Vijayaraghavan > > Ruslan Ermilov > I have one proposal for this fix. >=20 > In this patch, ip_output() is assumed to receive non-NULL rtentry > argument from its caller. >=20 > Two files are patched to support this, so there's no problem right > now. However if some new module calls ip_output() carelessly with > NULL rtentry argument, kernel would crash. > I don't think it is a good change. >=20 > KAME rewrote the attached patch to improve this point: > - This memory leak is fixed, of course:-) > (at least I confirmed on 5-current). > - Non-NULL rtentry for ip_output() is still accepted. So only a > patch in ip_output.c is enough. >=20 > Could you please correct me if I'm wrong, or consider adopting this > patch? > (it's a patch for 5-current, but it's not so difficult to modify it for > 4-stable and 4.5-release branch) >=20 I strongly object to this change. BSD historically didn't allow for ip_output() to be called with the NULL route pointer. I changed this in rev. 1.143 in a blind attempt to fix a panic condition I introduced in ip_icmp.c,v 1.64. Unfortunately, this didn't actually fix the ip_icmp.c bug but rather _hided_ it. Many respectful people objected to the 1.143 change, including Garrett Wollman, but I didn't realize at the time why this was bad. I since have fixed my mind, and I now realize why it's bad. The details could be found in the commit log for ip_output.c,v 1.153. Hopefully you can follow that. Cheers, --=20 Ruslan Ermilov Sysadmin and 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 --17/8oYur5Y32USnW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE8vpYqUkv4P6juNwoRAmzcAJ9cWMbvRHo79AQmjxeAki78XJ1IdwCeKi8d G4dXVXEh90y1CuSMFayRvOU= =0RVN -----END PGP SIGNATURE----- --17/8oYur5Y32USnW-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 18 4: 6:21 2002 Delivered-To: freebsd-net@freebsd.org Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by hub.freebsd.org (Postfix) with ESMTP id 3875B37B400 for ; Thu, 18 Apr 2002 04:06:17 -0700 (PDT) Received: from ns.iij.ad.jp (ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id UAA26087 for ; Thu, 18 Apr 2002 20:06:16 +0900 (JST) Received: from localhost (ssh.iij.ad.jp [192.168.2.7]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id UAA03302; Thu, 18 Apr 2002 20:06:15 +0900 (JST) Date: Thu, 18 Apr 2002 20:05:50 +0900 (JST) Message-Id: <20020418.200550.110156595.keiichi@iij.ad.jp> To: freebsd-net@FreeBSD.ORG Subject: Re: Questions on ip_output.c's patch for FreeBSD-SA-02:21.tcpip From: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= In-Reply-To: <20020418094722.GG98788@sunbay.com> References: <200204171923.g3HJNg958905@freefall.freebsd.org> <20020418094722.GG98788@sunbay.com> X-Mailer: Mew version 3.0.55 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, From: Ruslan Ermilov > I strongly object to this change. BSD historically didn't allow for > ip_output() to be called with the NULL route pointer. I changed this I don't know the history of BSD, but, if the reason is the history (that BSD didn't allow NULL route), I agree your fix is the only way. > in rev. 1.143 in a blind attempt to fix a panic condition I introduced > in ip_icmp.c,v 1.64. Unfortunately, this didn't actually fix the > ip_icmp.c bug but rather _hided_ it. Many respectful people objected > to the 1.143 change, including Garrett Wollman, but I didn't realize > at the time why this was bad. I since have fixed my mind, and I now > realize why it's bad. The details could be found in the commit log > for ip_output.c,v 1.153. Hopefully you can follow that. If the reason is "Prevent icmp_reflect() from calling ip_output() with a NULL route pointer which will then result in the allocated route's ~~~~~~~~~~~~~~~~~~~~~ reference count never being decremented.", I think both patches can ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ fix this problem. Regards, --- Keiichi SHIMA IIJ Research Laboratory KAME Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 18 4:13:53 2002 Delivered-To: freebsd-net@freebsd.org Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by hub.freebsd.org (Postfix) with ESMTP id 3F23B37B405 for ; Thu, 18 Apr 2002 04:13:50 -0700 (PDT) Received: from ns.iij.ad.jp (ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id UAA00319 for ; Thu, 18 Apr 2002 20:13:49 +0900 (JST) Received: from localhost (ssh.iij.ad.jp [192.168.2.7]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id UAA04538 for ; Thu, 18 Apr 2002 20:13:49 +0900 (JST) Date: Thu, 18 Apr 2002 20:13:24 +0900 (JST) Message-Id: <20020418.201324.33971457.keiichi@iij.ad.jp> To: freebsd-net@FreeBSD.ORG Subject: Re: IPv6 configuration document? From: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= In-Reply-To: <20020416195153.U25964@Space.Net> References: <20020415.110753.50151185.keiichi@iij.ad.jp> <20020416195153.U25964@Space.Net> X-Mailer: Mew version 3.0.55 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org From: Markus Stumpf > On Mon, Apr 15, 2002 at 11:07:53AM +0900, Keiichi SHIMA / ?$BEg7D0l?(B wrote: > > Does anyone know where is the document for configuring IPv6 on > > FreeBSD, if any? The NetBSD web page has a really cool manual > > (http://www.netbsd.org/Documentation/network/ipv6/) for IPv6 people > > using NetBSD. I'm looking for such a document for FreBSD. > > Not exactly the same type of document, but > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ipv6.html > made at least a start for me Thank you for pointing a good documentation! Though it is not for the novice, I think it is a very good document for the starting point. Thanks! --- Keiichi SHIMA IIJ Research Laboratory KAME Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 18 5:48:40 2002 Delivered-To: freebsd-net@freebsd.org Received: from smtp-send.myrealbox.com (smtp-send.myrealbox.com [192.108.102.143]) by hub.freebsd.org (Postfix) with ESMTP id 9CC7B37B41D for ; Thu, 18 Apr 2002 05:48:34 -0700 (PDT) Received: from joker.netcabo.pt pizomer@smtp-send.myrealbox.com [213.22.65.23] by smtp-send.myrealbox.com with Novell NIMS $Revision: 2.88.1.1 $ on Novell NetWare via secured & encrypted transport (TLS); Thu, 18 Apr 2002 06:48:35 -0600 Date: Thu, 18 Apr 2002 13:48:07 -0700 (Pacific Daylight Time) From: Zomer Pi To: freebsd-net@freebsd.org Cc: =?iso-8859-1?Q?Rickard_Borgm=E4ster?= Subject: Re: Tunneling - No gif interface? Why? In-Reply-To: <20020417134138.53d68990.doktorn@realworld.nu> Message-ID: X-X-Sender: pizomer@imap.myrealbox.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 2002-04-17 - 13:41 - [+0200], Rickard Borgm=E4ster wrote to net@FreeBSD= =2EORG: > From: Rickard Borgm=E4ster > > I need to create a tunnel to an OpenBSD host. This is because the > OpenBSD host is my mailrelay, and my local sendmail (port 25) is > blocked by a firewall out of my control. > > But somewhere it seems that the necessary parts are not in the > system.... > > $ apropos tunnel > gif(4) - generic tunnel interface > gifconfig(8) - configure generic IP tunnel > nos-tun(8) - implement ``nos'' or ``ka9q'' style IP over IP > tunnel stf(4) - 6to4 tunnel interface > tap(4) - Ethernet tunnel software network interface > tun(4) - tunnel software network interface > > gif, that's what I want! > > from gifconfig(8): > SYNOPSIS > gifconfig interface [af] [physsrc physdest] > [...] > EXAMPLES > If you would like to configure IPv6 over IPv4 (aka IPv6 in IPv4) > tunnel between 10.1.1.1 and 10.2.3.4, you should perform the followin= g > command: # gifconfig gif0 inet 10.1.1.1 10.2.3.4 > > Nice! So lets rock: > > $ gifconfig gif0 130.236.218.63 213.88.128.169 > gifconfig: interface gif0 does not exist > I'm no expert but i think you'll need to make the device in /dev/gif0 or something like that > Oh... > > $ ifconfig -a > xl0: flags=3D8843 mtu 1500 > =09inet 130.236.218.63 netmask 0xffffff00 broadcast 130.236.218.255 > lo0: flags=3D8049 mtu 16384 > =09inet 127.0.0.1 netmask 0xff000000 > ppp0: flags=3D8010 mtu 1500 > vmnet1: flags=3D8843 mtu 1500 > =09inet 10.0.8.30 netmask 0xfffffff0 broadcast 10.0.8.31 > =09ether 00:bd:da:0d:00:01 > > But... > > $ grep tun /usr/src/sys/i386/conf/KERNEL > pseudo-device=09tun=092=09# Packet tunnel. > pseudo-device=09gif=092=09# IPv6 and IPv4 tunneling > > Why don't I have the gif0 interface? > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 18 6:30:43 2002 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 8F74737B41C for ; Thu, 18 Apr 2002 06:30:31 -0700 (PDT) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id g3IDU9I64652; Thu, 18 Apr 2002 16:30:09 +0300 (EEST) (envelope-from ru) Date: Thu, 18 Apr 2002 16:30:09 +0300 From: Ruslan Ermilov To: Keiichi SHIMA / ????????? Cc: freebsd-net@FreeBSD.ORG Subject: Re: Questions on ip_output.c's patch for FreeBSD-SA-02:21.tcpip Message-ID: <20020418133009.GB63157@sunbay.com> References: <200204171923.g3HJNg958905@freefall.freebsd.org> <20020418094722.GG98788@sunbay.com> <20020418.200550.110156595.keiichi@iij.ad.jp> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vGgW1X5XWziG23Ko" Content-Disposition: inline In-Reply-To: <20020418.200550.110156595.keiichi@iij.ad.jp> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --vGgW1X5XWziG23Ko Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 18, 2002 at 08:05:50PM +0900, Keiichi SHIMA / ????????? wrote: > Hi, >=20 > From: Ruslan Ermilov >=20 > > I strongly object to this change. BSD historically didn't allow for > > ip_output() to be called with the NULL route pointer. I changed this >=20 > I don't know the history of BSD, but, if the reason is the history > (that BSD didn't allow NULL route), I agree your fix is the only way. >=20 > > in rev. 1.143 in a blind attempt to fix a panic condition I introduced > > in ip_icmp.c,v 1.64. Unfortunately, this didn't actually fix the > > ip_icmp.c bug but rather _hided_ it. Many respectful people objected > > to the 1.143 change, including Garrett Wollman, but I didn't realize > > at the time why this was bad. I since have fixed my mind, and I now > > realize why it's bad. The details could be found in the commit log > > for ip_output.c,v 1.153. Hopefully you can follow that. >=20 > If the reason is "Prevent icmp_reflect() from calling ip_output() with > a NULL route pointer which will then result in the allocated route's > ~~~~~~~~~~~~~~~~~~~~~ > reference count never being decremented.", I think both patches can > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > fix this problem. >=20 The problem is _already_ fixed. And I don't want to fix similar problems in the future. Cheers, --=20 Ruslan Ermilov Sysadmin and 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 --vGgW1X5XWziG23Ko Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE8vsphUkv4P6juNwoRAmygAJ0azYaagNtpvzAQ1VhKuJURfvP0GACdH3Qw 4q0p2xo4us+gLztE6Q3/n/8= =XiLD -----END PGP SIGNATURE----- --vGgW1X5XWziG23Ko-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 18 7:23:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by hub.freebsd.org (Postfix) with ESMTP id 1A7A737B404; Thu, 18 Apr 2002 07:23:06 -0700 (PDT) Received: from localhost ([3ffe:501:100f:1048:200:39ff:fed9:21d7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g3IEN4o33341; Thu, 18 Apr 2002 23:23:04 +0900 (JST) Date: Thu, 18 Apr 2002 23:23:09 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ruslan Ermilov Cc: SUZUKI Shinsuke , Garrett Wollman , jayanth@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Questions on ip_output.c's patch for FreeBSD-SA-02:21.tcpip In-Reply-To: <20020418094722.GG98788@sunbay.com> References: <200204171923.g3HJNg958905@freefall.freebsd.org> <20020418094722.GG98788@sunbay.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 52 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >>>>> On Thu, 18 Apr 2002 12:47:22 +0300, >>>>> Ruslan Ermilov said: >> KAME rewrote the attached patch to improve this point: >> - This memory leak is fixed, of course:-) >> (at least I confirmed on 5-current). >> - Non-NULL rtentry for ip_output() is still accepted. So only a >> patch in ip_output.c is enough. >> >> Could you please correct me if I'm wrong, or consider adopting this >> patch? >> (it's a patch for 5-current, but it's not so difficult to modify it for >> 4-stable and 4.5-release branch) > I strongly object to this change. BSD historically didn't allow for > ip_output() to be called with the NULL route pointer. I changed this I'm not sure what you meant by "BSD" and "historically" here, but please let me point out that this behavior is specific to FreeBSD. At least BSD-4.4 Lite2 allows for ip_output to take the NULL route pointer (see the rev. 1.1.1.1. for FreeBSD). Additionally, BSD/OS, NetBSD, and OpenBSD still allow the case. FreeBSD prohibited the NULL route pointer argument for ip_output at the change from 1.34 to 1.35 (6 years ago, so I admit we could say this "historically"). > in rev. 1.143 in a blind attempt to fix a panic condition I introduced > in ip_icmp.c,v 1.64. Unfortunately, this didn't actually fix the > ip_icmp.c bug but rather _hided_ it. Many respectful people objected > to the 1.143 change, including Garrett Wollman, but I didn't realize > at the time why this was bad. I since have fixed my mind, and I now > realize why it's bad. The details could be found in the commit log > for ip_output.c,v 1.153. Hopefully you can follow that. We understood the issue, but when we proposed the other fix (from suz) we did not realize that the "iproute" local variable was "re-"enabled in 1.143, and thought that this was an IPsec issue. Since FreeBSD has been able to live with the code disabling the NULL iproute for ip_output (and requiring all callers to pass a non NULL argument) for 6 years, I agree that the proposed fix in the advisory is natural for FreeBSD. The only concern that I think of is that we may see kernel panic when porting code that calls ip_output() from other BSDs, since the others may pass the NULL pointer to ip_output(). But, perhaps this issue has already been discussed and thus the current code... JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 18 8:51:49 2002 Delivered-To: freebsd-net@freebsd.org Received: from studsboll.realworld.nu (a63.flamman.student.liu.se [130.236.218.63]) by hub.freebsd.org (Postfix) with ESMTP id D8F1F37B405 for ; Thu, 18 Apr 2002 08:51:43 -0700 (PDT) Received: from localhost (doktorn@localhost) by studsboll.realworld.nu (8.11.6/8.11.6) with ESMTP id g3IFpfW08233 for ; Thu, 18 Apr 2002 17:51:41 +0200 (CEST) (envelope-from doktorn@realworld.nu) Date: Thu, 18 Apr 2002 17:51:41 +0200 (CEST) From: =?ISO-8859-1?Q?Rickard_Borgm=E4ster?= To: net@freebsd.org Subject: Tunneling - will gif do the trick? Message-ID: <20020418174656.W8193-100000@studsboll.realworld.nu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Thanks do Dennis I now got the gif0 interface... However, I have trouble moving on... A host 213.88.128.169 is a secondary mailserver for 130.236.218.63. 130.236.218.63 has now been placed in a net where the smtp port is blocked from the world. I have no access to this firewall. So how can I make 213.88.128.169 deliver the mail to 130.236.218.63? I looked at SSH tunneling, but it doesn't seem doable with that. But how abouts gif? relayhost# ifconfig gif0 tunnel 213.88.128.169 130.236.218.63 relayhost# ifconfig gif0 gif0: flags=3D8051 mtu 1280 tunnel inet 213.88.128.169 --> 130.236.218.63 relayhost# telnet 130.236.218.63 25 Trying 130.236.218.63... telnet: connect to address 130.236.218.63: No route to host Uhm... ok, so what am I missing, or did I misunderstand this completely...? Rickard .--. .--. =2E----------------------------------------. | | | | .-. | Rickard Borgm=E4ster | | | | |/ / | doktorn@sub.nu | .-^ | .--. | < | http://doktorn.sub.nu/ | ( o | ( () ) | |\ \ `----------------------------------------' `-----' `--' `--' `--' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 18 9:40:54 2002 Delivered-To: freebsd-net@freebsd.org Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by hub.freebsd.org (Postfix) with ESMTP id B321A37B405 for ; Thu, 18 Apr 2002 09:40:48 -0700 (PDT) Received: from ns.iij.ad.jp (ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id BAA12577 for ; Fri, 19 Apr 2002 01:40:47 +0900 (JST) Received: from localhost (ssh.iij.ad.jp [192.168.2.7]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id BAA10159 for ; Fri, 19 Apr 2002 01:40:45 +0900 (JST) Date: Fri, 19 Apr 2002 01:40:15 +0900 (JST) Message-Id: <20020419.014015.33683638.keiichi@iij.ad.jp> To: freebsd-net@FreeBSD.ORG Subject: Re: Questions on ip_output.c's patch for FreeBSD-SA-02:21.tcpip From: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= In-Reply-To: <20020418133009.GB63157@sunbay.com> References: <20020418094722.GG98788@sunbay.com> <20020418.200550.110156595.keiichi@iij.ad.jp> <20020418133009.GB63157@sunbay.com> X-Mailer: Mew version 3.0.55 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org From: Ruslan Ermilov > > If the reason is "Prevent icmp_reflect() from calling ip_output() with > > a NULL route pointer which will then result in the allocated route's > > ~~~~~~~~~~~~~~~~~~~~~ > > reference count never being decremented.", I think both patches can > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > fix this problem. > > > The problem is _already_ fixed. And I don't want to fix similar > problems in the future. I have dug the cvs repositry and finally understand the policy and the style of ip_output() of FreeBSD. Sorry for my misunderstanding. Regards, --- Keiichi SHIMA IIJ Research Laboratory KAME Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 18 10:20:19 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 5403F37B404 for ; Thu, 18 Apr 2002 10:20:12 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020418172011.FCUG1901.rwcrmhc52.attbi.com@InterJet.elischer.org>; Thu, 18 Apr 2002 17:20:11 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id KAA02778; Thu, 18 Apr 2002 10:02:02 -0700 (PDT) Date: Thu, 18 Apr 2002 10:02:00 -0700 (PDT) From: Julian Elischer To: Attila Nagy Cc: freebsd-net@freebsd.org Subject: Re: Bridging vlan0 with de0 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, 18 Apr 2002, Attila Nagy wrote: > Hello, > > > Szia! > > el aptom azt email-szimet? (probably unintelligable :-) > Julian, you are so nice :) > Elkerhetem az email cimet? This is the right sentence. oops. I meant to write eladtam .. bad fingers.. and Dalma says that I should have said megadtam.... > > > did I give you this guy's address? > Yes. He is EGLES Guillaume > I have the mail with the source and some docs, so I can send you that if > you get no feedback. Thanks.. with his email address I could find the orignal mail :-) > > > > > Is it possible that this one will fix my FEC and VLAN problems? Is there a > > > > patch for -STABLE out there? I would be glad to test this :) > FEC+VLANs, anyone? :) > > --------[ Free Software ISOs - ftp://ftp.fsn.hu/pub/CDROM-Images/ ]------- > Attila Nagy e-mail: Attila.Nagy@fsn.hu > Free Software Network (FSN.HU) phone @work: +361 210 1415 (194) > cell.: +3630 306 6758 > > > 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 Apr 18 11: 6:40 2002 Delivered-To: freebsd-net@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id C4F8D37B416 for ; Thu, 18 Apr 2002 11:06:31 -0700 (PDT) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id g3II2sv06900; Thu, 18 Apr 2002 11:02:54 -0700 Date: Thu, 18 Apr 2002 11:02:54 -0700 From: Brooks Davis To: =?iso-8859-1?Q?Rickard_Borgm=E4ster?= Cc: net@FreeBSD.ORG Subject: Re: Tunneling - will gif do the trick? Message-ID: <20020418110254.A25502@Odin.AC.HMC.Edu> References: <20020418174656.W8193-100000@studsboll.realworld.nu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="opJtzjQTFsWo+cga" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020418174656.W8193-100000@studsboll.realworld.nu>; from doktorn@realworld.nu on Thu, Apr 18, 2002 at 05:51:41PM +0200 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --opJtzjQTFsWo+cga Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 18, 2002 at 05:51:41PM +0200, Rickard Borgm=E4ster wrote: > Thanks do Dennis I now got the gif0 interface... >=20 > However, I have trouble moving on... >=20 > A host 213.88.128.169 is a secondary mailserver for 130.236.218.63. > 130.236.218.63 has now been placed in a net where the smtp port is blocked > from the world. I have no access to this firewall. >=20 > So how can I make 213.88.128.169 deliver the mail to 130.236.218.63? I > looked at SSH tunneling, but it doesn't seem doable with that. But how > abouts gif? >=20 > relayhost# ifconfig gif0 tunnel 213.88.128.169 130.236.218.63 >=20 > relayhost# ifconfig gif0 > gif0: flags=3D8051 mtu 1280 > tunnel inet 213.88.128.169 --> 130.236.218.63 >=20 > relayhost# telnet 130.236.218.63 25 > Trying 130.236.218.63... > telnet: connect to address 130.236.218.63: No route to host >=20 > Uhm... ok, so what am I missing, or did I misunderstand this > completely...? You've misunderstood tunnels. 213.88.128.169 and 130.236.218.63 must be able to talk to each other over normal IP protocols (specificaly, over IP protocol 4). If that is the case, you use the above configuration to connect the tunnel between them and then do something like "ifconfig gif0 10.0.0.1 10.0.0.2" to configure the tunneled addresses. After doing the same thing at the other end (with the addresses swapped) you should be able to telnet to 10.0.0.2 port 25. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --opJtzjQTFsWo+cga Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8vwpNXY6L6fI4GtQRAiSTAKC72R1c83E9vR6Bd4GLG4XJ8U0q3gCgnAHX BhfB3C4qMoxlP01lLIUORSU= =880j -----END PGP SIGNATURE----- --opJtzjQTFsWo+cga-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 18 11:46:29 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id B9B9437B9A6 for ; Thu, 18 Apr 2002 11:40:47 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020418184021.JFS1102.rwcrmhc54.attbi.com@InterJet.elischer.org>; Thu, 18 Apr 2002 18:40:21 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA03078; Thu, 18 Apr 2002 11:25:53 -0700 (PDT) Date: Thu, 18 Apr 2002 11:25:52 -0700 (PDT) From: Julian Elischer To: Bernd Walter Cc: Radoslav Vasilev , freebsd-net@freebsd.org Subject: Re: vlan traffic over ipsec tunnel In-Reply-To: <20020418090130.GK70839@cicely9.cicely.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The example of how to make a tunnel is part of it two.. what you suggest is a combination of thetwo.. actually I have a suggestion you should but the 'bridge' node on BOTH ENDS of the tunnel. this will stop traffic that is not wanted from travelling over the link. if you don't do that, then incidental traffic read off the remote network (the one without a bridge node) will all be needlessly carried across the link just to be discarded by the bridge node at the far end. Adding a bridge node at each end ensures that this doesn't happen. On Thu, 18 Apr 2002, Bernd Walter wrote: > On Thu, Apr 18, 2002 at 03:43:17AM +0300, Radoslav Vasilev wrote: > > How in practise one can bridge two separate lans through netgraph/whatever > > ehternet over IP) ? > > Take a look into /usr/share/examples/netgraph. > There is an example for ethernet bridging and udp tunnel. > You just have to put ksocket nodes between the ethernet nodes > instead of connecting them directly. > > > ----- Original Message ----- > > From: "Bernd Walter" > > To: "Peter J. Blok" > > Cc: ; > > Sent: Thursday, April 18, 2002 2:44 AM > > Subject: Re: vlan traffic over ipsec tunnel > > > > > > > On Wed, Apr 17, 2002 at 09:11:28PM +0200, Peter J. Blok wrote: > > > > Hi All, > > > > > > > > I'd like to accomplish the following: I have two locations, connected > > via an > > > > IPSEC tunnel. Is it possible to connect the vlans at both ends through > > the > > > > tunnel. > > > > > > > > Is this possible with existing software? What would it take to do > > something > > > > like this? > > > > > > With netgraph you can bridge ethernets over IP which then gets > > > encypted via ipsec - at least in theory. > > > But If you only want to connect IP based lans you should route instead. > > -- > B.Walter COSMO-Project http://www.cosmo-project.de > ticso@cicely.de Usergroup info@cosmo-project.de > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 18 16:18:30 2002 Delivered-To: freebsd-net@freebsd.org Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by hub.freebsd.org (Postfix) with ESMTP id E881D37B416 for ; Thu, 18 Apr 2002 16:18:15 -0700 (PDT) Received: from milk.yahoo.com (milk.yahoo.com [216.145.52.137]) by mrout2.yahoo.com (8.11.6/8.11.6/y.out) with ESMTP id g3INHuE77559; Thu, 18 Apr 2002 16:17:56 -0700 (PDT) Received: (from root@localhost) by milk.yahoo.com (8.11.0/8.11.0) id g3INHtG20060; Thu, 18 Apr 2002 16:17:55 -0700 (PDT) (envelope-from jayanth) Date: Thu, 18 Apr 2002 16:17:55 -0700 From: jayanth To: Mike Silbersack Cc: Mark Delany , Bill Fenner , freebsd-net@FreeBSD.ORG Subject: Re: What does FreeBSD do when listen queue is full ? Message-ID: <20020418161755.A19016@yahoo-inc.com> References: <20020417213805.A91259@bushwire.net> <20020418004301.K17506-100000@patrocles.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20020418004301.K17506-100000@patrocles.silby.com>; from silby@silby.com on Thu, Apr 18, 2002 at 12:49:45AM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > > For arguments sake, say I have a web server that I know handles 10 > > requests per second and I want to offer a 2 second response time. To > > do this I set the backlog to 20 on each of the web servers and > > configure the load balancer to periodically check each server by > > attempting to establish a session. > > > > If the load balancer connection attempt fails then it knows that that > > particular server already has 2 seconds worth of work so it should not > > consider that server as available at the moment (note that some load > > balancer configurations mean that connection counting is not possible > > and, oftentimes they don't do so accurately anyway). > > Well, 4.5+ would already be considered broken by your standards; it does > not send a RST when dropping connections that have exceeded the backlog. It does not send a RST immediately, but will send one if the peer retransmits the ACK or sends data. In syncache_socket() /* * Ok, create the full blown connection, and set things up * as they would have been set up if we had created the * connection when the SYN arrived. If we can't create * the connection, abort it. */ so = sonewconn(lso, SS_ISCONNECTED); if (so == NULL) { /* * Drop the connection; we will send a RST if the peer * retransmits the ACK, */ tcpstat.tcps_listendrop++; goto abort; } when the listen queue is full and the syncache entry is dropped there is a side effect that will cause the subsequent ACK or ACK w data to be rejected because the syncookie lookup code for the ACK packet always returns NULL. The reason NULL is returned is because of the following check in syncookie_lookup(). if (tcp_secret[idx].ts_expire < ticks || sototcpcb(so)->ts_recent + SYNCOOKIE_TIMEOUT < ticks) return (NULL); ts_recent will be zero at this point. The ts_recent flag of the listening socket is used as a timer and an indicator that a syncache entry has been removed. A dropped entry due to listen q full should be treated the same way as zone allocation failure, bucket or cache overflow, by updating ts_recent. This will not reject the ACK assuming that the listen queue is not full again. jayanth To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 18 21:26:17 2002 Delivered-To: freebsd-net@freebsd.org Received: from lariat.org (lariat.org [12.23.109.2]) by hub.freebsd.org (Postfix) with ESMTP id C317F37B404 for ; Thu, 18 Apr 2002 21:25:55 -0700 (PDT) Received: from mustang.lariat.org (IDENT:ppp0.lariat.org@lariat.org [12.23.109.2]) by lariat.org (8.9.3/8.9.3) with ESMTP id WAA27182 for ; Thu, 18 Apr 2002 22:25:43 -0600 (MDT) X-message-flag: Warning! Use of Microsoft Outlook may make your system susceptible to Internet worms. Message-Id: <4.3.2.7.2.20020418220457.0223da60@nospam.lariat.org> X-Sender: brett@nospam.lariat.org X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 18 Apr 2002 22:25:38 -0600 To: freebsd-net@freebsd.org From: Brett Glass Subject: Configuring a router to work on an unregistered internal subnet Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I'm in the process of creating a router which will sit on an ISP's internal subnet, which uses unregistered addresses. The router's upstream interface will have an unregistered address, say, 10.X.Y.Z. Its downstream interfaces will have registered IPs, so it looks like this: _ A.B.C.1 -> feeds A.B.C/25 10.X.Y.Z / ISP and Internet ---------[Router]\_ A.B.D.1 -> feeds A.B.D/26 10.X.Y/24 etc. But here's the rub. When the router communicates with the outside world on its own behalf (which it has to do; it's going to serve as a transparent Web cache as well as a router), it needs to use one of its registered addresses as the source address, or the packets won't leave the ISP's internal network. My first attempt at configuring a FreeBSD machine to do this didn't work. When attempting to speak to the Internet at large, it used its 10.X.Y.Z address as the source address on its packets, and of course this caused them to stop at the ISP's gateway router (which is not doing NAT). What's the easiest way to tell it to use the address of one of its internal interfaces (say, A.B.C.1) when talking to the rest of the world, but send those packets out the 10.X.Y.Z interface? Also, if I'm doing an FTP install of FreeBSD on the router (I want to load 4.5-RELEASE-p3 rather than 4.5-RELEASE, to nuke the zlib, OpenSSH, and tcp memory leak bugs), how do I configure the interfaces, etc. from sysinstall to do The Right Thing? (If this is really tough, I do have another network I can plug the machine into, but I'll have to unbolt it from a rack and schlep it to another part of the building.) --Brett Glass P.S. -- I'm not currently subscribed to FreeBSD-net, so please copy me on responses. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Apr 19 4:31:24 2002 Delivered-To: freebsd-net@freebsd.org Received: from scribble.fsn.hu (scribble.fsn.hu [193.224.40.95]) by hub.freebsd.org (Postfix) with SMTP id 1B3F537B41C for ; Fri, 19 Apr 2002 04:31:21 -0700 (PDT) Received: (qmail 989 invoked by uid 1000); 19 Apr 2002 11:33:14 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 19 Apr 2002 11:33:14 -0000 Date: Fri, 19 Apr 2002 13:33:14 +0200 (CEST) From: Attila Nagy To: Julian Elischer Cc: freebsd-net@freebsd.org Subject: Re: Bridging vlan0 with de0 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello, > oops. I meant to write eladtam .. bad fingers.. and Dalma says that I > should have said megadtam.... Oh, I see now. > Thanks.. with his email address I could find the orignal mail :-) Good luck! :) --------[ Free Software ISOs - ftp://ftp.fsn.hu/pub/CDROM-Images/ ]------- Attila Nagy e-mail: Attila.Nagy@fsn.hu Free Software Network (FSN.HU) phone @work: +361 210 1415 (194) cell.: +3630 306 6758 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Apr 19 6:14:58 2002 Delivered-To: freebsd-net@freebsd.org Received: from mw1.texas.net (mw1.texas.net [206.127.30.11]) by hub.freebsd.org (Postfix) with ESMTP id 46CDF37B416 for ; Fri, 19 Apr 2002 06:14:55 -0700 (PDT) Received: from staff3.texas.net (staff3.texas.net [207.207.0.40]) by mw1.texas.net (8.11.6/8.11.6) with ESMTP id g3JDEsG26787 for ; Fri, 19 Apr 2002 08:14:54 -0500 (CDT) Received: (from msmith@localhost) by staff3.texas.net (8.11.6/8.11.6) id g3JDEsc36315 for freebsd-net@freebsd.org; Fri, 19 Apr 2002 08:14:54 -0500 (CDT) (envelope-from msmith) Date: Fri, 19 Apr 2002 08:14:54 -0500 From: Michael Smith To: freebsd-net@freebsd.org Subject: network traffic analysis with a network switch Message-ID: <20020419081453.X30314@staff.texas.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Not quite sure how to set this up, or even if it can be setup... I have a windows box, a FreeBSD box (gateway) and a RH box all connected to a 100base-T network switch. The FreeBSD box is then connected to a Cable Modem and a T1 router. I have a program on the RH box that can snoop and analyze some of the network traffic of the windows box, however due to the nature of network switches, it never sees the traffic. Don't ask about the analyzer, I'm rather annoyed that it was written specifically to compile and run only on RH and it's very close Linux relatives. Here is a rough visualization of the setup. +-------------+ +----+ | Cable Modem | | T1 | +-------------+ +----+ \ / +---------+ | FreeBSD | +---------+ | +------------------+ | 100base-T Switch | +------------------+ / | \ +----------+ +----+ +----------+ | Windows1 | | RH | | Windows3 | +----------+ +----+ +----------+ What I would like to be able to do is somehow send copies of network traffic to the RH box without having to move it between the FreeBSD box and the switch. Is this possible and if so, how would I go about setting this up? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Apr 19 10:17: 8 2002 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id D4C5737B425; Fri, 19 Apr 2002 10:16:35 -0700 (PDT) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id KAA75254; Fri, 19 Apr 2002 10:14:47 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g3JHDVg41265; Fri, 19 Apr 2002 10:13:31 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200204191713.g3JHDVg41265@arch20m.dellroad.org> Subject: Re: vlan traffic over ipsec tunnel In-Reply-To: <3CBE129B.BE50CD2B@mindspring.com> "from Terry Lambert at Apr 17, 2002 05:26:03 pm" To: Terry Lambert Date: Fri, 19 Apr 2002 10:13:31 -0700 (PDT) Cc: "Peter J. Blok" , freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Terry Lambert writes: > Bridging doesn't work with the vlanX interface currently in FreeBSD. Why not? I believe you, I've just never used vlans and always assumed that they acted like normal Ethernet interfaces. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Apr 19 10:30:14 2002 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 30E4E37B41A for ; Fri, 19 Apr 2002 10:30:03 -0700 (PDT) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id KAA75319; Fri, 19 Apr 2002 10:18:01 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g3JHGjI41280; Fri, 19 Apr 2002 10:16:45 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200204191716.g3JHGjI41280@arch20m.dellroad.org> Subject: Re: xauth support in ipsec ? In-Reply-To: <003a01c1e66c$deff1500$bb5bf7a5@compaq> "from Naga R Narayanaswamy at Apr 17, 2002 08:06:20 pm" To: Naga R Narayanaswamy Date: Fri, 19 Apr 2002 10:16:45 -0700 (PDT) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Naga R Narayanaswamy writes: > Probably this mail should be directed at the kame newsgroup. But > anyone know if xauth authorization scheme which is in draft stage > is incorporated in the ipsec protocol in FreeBSD ? FreeBSD itself does not do ISAKMP, that is done by the "racoon" port; you should pose your question to snap-users@kame.net. But I can tell you what the probable response is: "because XAUTH is not a standard". Same thing for mode-config. WHY it's not a standard-- that I have yet to hear explained. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Apr 19 11:34:20 2002 Delivered-To: freebsd-net@freebsd.org Received: from web21108.mail.yahoo.com (web21108.mail.yahoo.com [216.136.227.110]) by hub.freebsd.org (Postfix) with SMTP id C136437B41E for ; Fri, 19 Apr 2002 11:34:16 -0700 (PDT) Message-ID: <20020419183416.4527.qmail@web21108.mail.yahoo.com> Received: from [152.15.26.29] by web21108.mail.yahoo.com via HTTP; Fri, 19 Apr 2002 11:34:16 PDT Date: Fri, 19 Apr 2002 11:34:16 -0700 (PDT) From: Vinod Subject: ethernet card not recognized To: freebsd-net@freebsd.org Cc: frebsd-questions@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I had a windows machine with an SMC1211TX ethernet card.i just installed freebsd 4.5 release on it,removing windows.but it doesnt seem to recognize the card at all and there isnt a eth0 or fxp0 interface recognized.What needs to be done?isnt this card supported.its a pretty common one,lil old though. Thanks in advance, Vinod __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Apr 19 13: 3:11 2002 Delivered-To: freebsd-net@freebsd.org Received: from ambrisko.com (adsl-64-174-51-42.dsl.snfc21.pacbell.net [64.174.51.42]) by hub.freebsd.org (Postfix) with ESMTP id C5F4337B416; Fri, 19 Apr 2002 13:02:41 -0700 (PDT) Received: (from ambrisko@localhost) by ambrisko.com (8.11.6/8.11.6) id g3JK1q748470; Fri, 19 Apr 2002 13:01:52 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200204192001.g3JK1q748470@ambrisko.com> Subject: Re: vlan traffic over ipsec tunnel In-Reply-To: <200204191713.g3JHDVg41265@arch20m.dellroad.org> To: Archie Cobbs Date: Fri, 19 Apr 2002 13:01:52 -0700 (PDT) Cc: Terry Lambert , "Peter J. Blok" , freebsd-hackers@FreeBSD.org, freebsd-net@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Archie Cobbs writes: | Terry Lambert writes: | > Bridging doesn't work with the vlanX interface currently in FreeBSD. | | Why not? | | I believe you, I've just never used vlans and always assumed | that they acted like normal Ethernet interfaces. Same here: a21p# ngctl list There are 5 total nodes: Name: ngctl53375 Type: socket ID: 00000006 Num hooks: 0 Name: an0 Type: ether ID: 00000005 Num hooks: 0 Name: vmnet1 Type: ether ID: 00000004 Num hooks: 0 Name: vlan0 Type: ether ID: 00000003 Num hooks: 0 Name: fxp0 Type: ether ID: 00000002 Num hooks: 0 a21p# ifconfig vlan0 vlan0: flags=8843 mtu 1500 inet 192.168.33.1 netmask 0xffffff00 broadcast 192.168.33.255 ether 00:10:a4:91:2e:ce vlan: 34 parent interface: fxp0 a21p# Would imply it should just work to bridge vlan's via netgraph bridging. As Archie said I have not tested this to prove how it does or does not work since I haven't had a need to try it. Doug A. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Apr 19 13:20:15 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id 4EFE637B400; Fri, 19 Apr 2002 13:20:09 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020419202009.KVXL1143.rwcrmhc51.attbi.com@InterJet.elischer.org>; Fri, 19 Apr 2002 20:20:09 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA08505; Fri, 19 Apr 2002 13:19:43 -0700 (PDT) Date: Fri, 19 Apr 2002 13:19:42 -0700 (PDT) From: Julian Elischer To: Doug Ambrisko Cc: Archie Cobbs , Terry Lambert , "Peter J. Blok" , freebsd-hackers@FreeBSD.org, freebsd-net@FreeBSD.org Subject: Re: vlan traffic over ipsec tunnel In-Reply-To: <200204192001.g3JK1q748470@ambrisko.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 19 Apr 2002, Doug Ambrisko wrote: > Archie Cobbs writes: > | Terry Lambert writes: > | > Bridging doesn't work with the vlanX interface currently in FreeBSD. > | > | Why not? > | > | I believe you, I've just never used vlans and always assumed > | that they acted like normal Ethernet interfaces. > > Same here: > a21p# ngctl list > There are 5 total nodes: > Name: ngctl53375 Type: socket ID: 00000006 Num hooks: 0 > Name: an0 Type: ether ID: 00000005 Num hooks: 0 > Name: vmnet1 Type: ether ID: 00000004 Num hooks: 0 > Name: vlan0 Type: ether ID: 00000003 Num hooks: 0 > Name: fxp0 Type: ether ID: 00000002 Num hooks: 0 > a21p# ifconfig vlan0 > vlan0: flags=8843 mtu 1500 > inet 192.168.33.1 netmask 0xffffff00 broadcast 192.168.33.255 > ether 00:10:a4:91:2e:ce > vlan: 34 parent interface: fxp0 > a21p# > > Would imply it should just work to bridge vlan's via netgraph bridging. > As Archie said I have not tested this to prove how it does or does not > work since I haven't had a need to try it. I don't know, but it may have problems setting promiscuous mode.. is there such a thing in vlan mode? > > Doug A. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Apr 19 13:20:49 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id DAEE437B425; Fri, 19 Apr 2002 13:20:19 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020419202019.KWBZ1143.rwcrmhc51.attbi.com@InterJet.elischer.org>; Fri, 19 Apr 2002 20:20:19 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA08503; Fri, 19 Apr 2002 13:18:17 -0700 (PDT) Date: Fri, 19 Apr 2002 13:18:16 -0700 (PDT) From: Julian Elischer To: Doug Ambrisko Cc: Archie Cobbs , Terry Lambert , "Peter J. Blok" , freebsd-hackers@FreeBSD.org, freebsd-net@FreeBSD.org Subject: Re: vlan traffic over ipsec tunnel In-Reply-To: <200204192001.g3JK1q748470@ambrisko.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org failing that, I have just had "contributed" some code that produces an actual "vlan" netgraph node. You attach it to the ethernet node.. I'm still reading it to work out what it does.. On Fri, 19 Apr 2002, Doug Ambrisko wrote: > Archie Cobbs writes: > | Terry Lambert writes: > | > Bridging doesn't work with the vlanX interface currently in FreeBSD. > | > | Why not? > | > | I believe you, I've just never used vlans and always assumed > | that they acted like normal Ethernet interfaces. > > Same here: > a21p# ngctl list > There are 5 total nodes: > Name: ngctl53375 Type: socket ID: 00000006 Num hooks: 0 > Name: an0 Type: ether ID: 00000005 Num hooks: 0 > Name: vmnet1 Type: ether ID: 00000004 Num hooks: 0 > Name: vlan0 Type: ether ID: 00000003 Num hooks: 0 > Name: fxp0 Type: ether ID: 00000002 Num hooks: 0 > a21p# ifconfig vlan0 > vlan0: flags=8843 mtu 1500 > inet 192.168.33.1 netmask 0xffffff00 broadcast 192.168.33.255 > ether 00:10:a4:91:2e:ce > vlan: 34 parent interface: fxp0 > a21p# > > Would imply it should just work to bridge vlan's via netgraph bridging. > As Archie said I have not tested this to prove how it does or does not > work since I haven't had a need to try it. > > Doug A. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Apr 19 13:45: 5 2002 Delivered-To: freebsd-net@freebsd.org Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id B18D637B405; Fri, 19 Apr 2002 13:45:01 -0700 (PDT) Received: from pool0151.cvx22-bradley.dialup.earthlink.net ([209.179.198.151] helo=mindspring.com) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 16yfFQ-0006V5-00; Fri, 19 Apr 2002 13:44:48 -0700 Message-ID: <3CC081A3.976291AD@mindspring.com> Date: Fri, 19 Apr 2002 13:44:19 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Archie Cobbs Cc: "Peter J. Blok" , freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: vlan traffic over ipsec tunnel References: <200204191713.g3JHDVg41265@arch20m.dellroad.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Archie Cobbs wrote: > Terry Lambert writes: > > Bridging doesn't work with the vlanX interface currently in FreeBSD. > > Why not? > > I believe you, I've just never used vlans and always assumed > that they acted like normal Ethernet interfaces. According to people in -questions on 18 Dec of last year, it's not possible. I imagine it's because the vlan interfaces don't push their packets through ether_input, like real interfaces do. Julian's approach would put the vlan's on ng_ether, which would push through the code that does the bridging. Last December 20 on -net, he said the caode for a VLAN netgraph node was being donated by "this French committer" (sorry, I don't remember the exact words he used; I only scanned the posting in passing, 4 months ago, when VLAN's weren't important to me). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Apr 19 13:48:12 2002 Delivered-To: freebsd-net@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id EFAB037B404; Fri, 19 Apr 2002 13:47:53 -0700 (PDT) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g3JKloq71696; Fri, 19 Apr 2002 13:47:50 -0700 (PDT) (envelope-from rizzo) Date: Fri, 19 Apr 2002 13:47:50 -0700 From: Luigi Rizzo To: Terry Lambert Cc: Archie Cobbs , "Peter J. Blok" , freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: vlan traffic over ipsec tunnel Message-ID: <20020419134750.A71672@iguana.icir.org> References: <200204191713.g3JHDVg41265@arch20m.dellroad.org> <3CC081A3.976291AD@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CC081A3.976291AD@mindspring.com> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org i recently (late february) made some commits that among other things enabled the native bridging in FreeBSD to work on vlans. Both on -stable and -current. cheers luigi On Fri, Apr 19, 2002 at 01:44:19PM -0700, Terry Lambert wrote: > Archie Cobbs wrote: > > Terry Lambert writes: > > > Bridging doesn't work with the vlanX interface currently in FreeBSD. > > > > Why not? > > > > I believe you, I've just never used vlans and always assumed > > that they acted like normal Ethernet interfaces. > > According to people in -questions on 18 Dec of last year, it's > not possible. > > I imagine it's because the vlan interfaces don't push their > packets through ether_input, like real interfaces do. > > Julian's approach would put the vlan's on ng_ether, which > would push through the code that does the bridging. Last > December 20 on -net, he said the caode for a VLAN netgraph > node was being donated by "this French committer" (sorry, I > don't remember the exact words he used; I only scanned the > posting in passing, 4 months ago, when VLAN's weren't > important to me). > > -- Terry > > 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 Apr 19 14: 0: 0 2002 Delivered-To: freebsd-net@freebsd.org Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id 6532037B405; Fri, 19 Apr 2002 13:59:28 -0700 (PDT) Received: from pool0151.cvx22-bradley.dialup.earthlink.net ([209.179.198.151] helo=mindspring.com) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 16yfTD-0007Qz-00; Fri, 19 Apr 2002 13:59:03 -0700 Message-ID: <3CC084F1.1951442A@mindspring.com> Date: Fri, 19 Apr 2002 13:58:25 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: Doug Ambrisko , Archie Cobbs , "Peter J. Blok" , freebsd-hackers@FreeBSD.org, freebsd-net@FreeBSD.org Subject: Re: vlan traffic over ipsec tunnel References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Julian Elischer wrote: > > Would imply it should just work to bridge vlan's via netgraph bridging. > > As Archie said I have not tested this to prove how it does or does not > > work since I haven't had a need to try it. > > I don't know, but it may have problems setting promiscuous mode.. > is there such a thing in vlan mode? It might work with the Netgraph bridging. It's not going to work with the packet fast forwarding. The new netgraph version goes through ether_input, so it should not be a problem. Promiscuous mode isn't really necessary (IMO), at least on the interface to which it's trunked. It *might* be an issue for the VLAN itself, though, if it's supposed to bridge to a non-VLAN. My impression of bridging in theis context was that you would use it to create a virtual LAN at otherwise physically disjoint locations, so that bridging should be automatic, at least that way. That implied (to me) that the bridging was e.g. to allow a box to be on the local net with an ethernet interface, and act as a bridge between that net and another local net, using the VLAN as a transport, over something else (e.g. a point-to-point IPSEC link between the "bridges"). From old DEC days, I'd say it was the moral equivalent of a DELNI, where you have half a bridge, a quarter mile of optical fiber, and the other half of the bridge, and everything on either side just sees a bridge. I imagine that the primary use would be for VPN's, where there were N nodes at one site and M nodes at another, where N > 1 && M > 1. Unfortunately, I don't have a Cisco Catalyst 2900 or other toys necessary to play with VLAN interoperability at the moment, I can only play with FreeBSD<->FreeBSD VLAN stuff, and then draw conclusions based on the RFCs and Cisco and other documentation. Sorry to be so vague. 8-(. Maybe someone with a larger "toy" budget than I have could contribute something to the conversation? I know Bill Paul has done a lot of work with VLAN code (he wrote the FreeBSD FEC code), and I expect Jon Lemon would be quite knowledgable, too, being a Cisco employee (plus have access to toys we haven't even heard of, yet ;^)). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Apr 19 14: 1: 8 2002 Delivered-To: freebsd-net@freebsd.org Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id E37A537B405; Fri, 19 Apr 2002 14:00:44 -0700 (PDT) Received: from pool0151.cvx22-bradley.dialup.earthlink.net ([209.179.198.151] helo=mindspring.com) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 16yfUj-0001cP-00; Fri, 19 Apr 2002 14:00:37 -0700 Message-ID: <3CC08558.DC64E500@mindspring.com> Date: Fri, 19 Apr 2002 14:00:08 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: Doug Ambrisko , Archie Cobbs , "Peter J. Blok" , freebsd-hackers@FreeBSD.org, freebsd-net@FreeBSD.org Subject: Re: vlan traffic over ipsec tunnel References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Julian Elischer wrote: > > failing that, I have just had "contributed" > some code that produces an actual "vlan" netgraph node. > You attach it to the ethernet node.. I'm still > reading it to work out what it does.. Is this the "VLAN implemented in Netgraph" thing you were talking about last December, or is it the just glue code? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Apr 19 14: 2:53 2002 Delivered-To: freebsd-net@freebsd.org Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id 81DCD37B405; Fri, 19 Apr 2002 14:02:41 -0700 (PDT) Received: from pool0151.cvx22-bradley.dialup.earthlink.net ([209.179.198.151] helo=mindspring.com) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 16yfWL-0003X9-00; Fri, 19 Apr 2002 14:02:18 -0700 Message-ID: <3CC085BD.B58BE3C6@mindspring.com> Date: Fri, 19 Apr 2002 14:01:49 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Luigi Rizzo Cc: Archie Cobbs , "Peter J. Blok" , freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: vlan traffic over ipsec tunnel References: <200204191713.g3JHDVg41265@arch20m.dellroad.org> <3CC081A3.976291AD@mindspring.com> <20020419134750.A71672@iguana.icir.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Luigi Rizzo wrote: > i recently (late february) made some commits that among other > things enabled the native bridging in FreeBSD to work on vlans. > Both on -stable and -current. OK, then I'm out of date. Does this work with ip.fastforwarding? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Apr 19 14:19:19 2002 Delivered-To: freebsd-net@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 68C2937B419; Fri, 19 Apr 2002 14:19:14 -0700 (PDT) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g3JLJBF71922; Fri, 19 Apr 2002 14:19:11 -0700 (PDT) (envelope-from rizzo) Date: Fri, 19 Apr 2002 14:19:11 -0700 From: Luigi Rizzo To: Terry Lambert Cc: Archie Cobbs , "Peter J. Blok" , freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: vlan traffic over ipsec tunnel Message-ID: <20020419141911.A71847@iguana.icir.org> References: <200204191713.g3JHDVg41265@arch20m.dellroad.org> <3CC081A3.976291AD@mindspring.com> <20020419134750.A71672@iguana.icir.org> <3CC085BD.B58BE3C6@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CC085BD.B58BE3C6@mindspring.com> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Apr 19, 2002 at 02:01:49PM -0700, Terry Lambert wrote: > Luigi Rizzo wrote: > > i recently (late february) made some commits that among other > > things enabled the native bridging in FreeBSD to work on vlans. > > Both on -stable and -current. > > OK, then I'm out of date. > > Does this work with ip.fastforwarding? well, i don't understand the question given that bridging is below IP and is done within ether_input() -- so technically yes, bridged packets are processed to completion irrespective of the settin of ip.fastforwarding cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Apr 19 14:21: 1 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id E2DD937B404; Fri, 19 Apr 2002 14:20:13 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020419212013.YYFH1102.rwcrmhc54.attbi.com@InterJet.elischer.org>; Fri, 19 Apr 2002 21:20:13 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA08727; Fri, 19 Apr 2002 14:02:13 -0700 (PDT) Date: Fri, 19 Apr 2002 14:02:13 -0700 (PDT) From: Julian Elischer To: Terry Lambert Cc: Archie Cobbs , "Peter J. Blok" , freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: vlan traffic over ipsec tunnel In-Reply-To: <3CC081A3.976291AD@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 19 Apr 2002, Terry Lambert wrote: > > Julian's approach would put the vlan's on ng_ether, which > would push through the code that does the bridging. Last > December 20 on -net, he said the caode for a VLAN netgraph > node was being donated by "this French committer" (sorry, I > don't remember the exact words he used; I only scanned the > posting in passing, 4 months ago, when VLAN's weren't > important to me). I have the netgraph vlan code now.. I'm reading it to try understand what it does.. > > -- Terry > > 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 Apr 19 14:21:54 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id F2A6837B47D; Fri, 19 Apr 2002 14:20:20 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020419212019.YYHG1102.rwcrmhc54.attbi.com@InterJet.elischer.org>; Fri, 19 Apr 2002 21:20:19 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA08738; Fri, 19 Apr 2002 14:04:10 -0700 (PDT) Date: Fri, 19 Apr 2002 14:04:09 -0700 (PDT) From: Julian Elischer To: Terry Lambert Cc: Doug Ambrisko , Archie Cobbs , "Peter J. Blok" , freebsd-hackers@FreeBSD.org, freebsd-net@FreeBSD.org Subject: Re: vlan traffic over ipsec tunnel In-Reply-To: <3CC08558.DC64E500@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org apparently, though I am still trying to understand it.. On Fri, 19 Apr 2002, Terry Lambert wrote: > Julian Elischer wrote: > > > > failing that, I have just had "contributed" > > some code that produces an actual "vlan" netgraph node. > > You attach it to the ethernet node.. I'm still > > reading it to work out what it does.. > > Is this the "VLAN implemented in Netgraph" thing you were > talking about last December, or is it the just glue code? > > -- Terry > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Apr 19 14:58: 9 2002 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 E065A37B405 for ; Fri, 19 Apr 2002 14:58:06 -0700 (PDT) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.6) id g3JLw3X78021; Fri, 19 Apr 2002 17:58:03 -0400 (EDT) (envelope-from wollman) Date: Fri, 19 Apr 2002 17:58:03 -0400 (EDT) From: Garrett Wollman Message-Id: <200204192158.g3JLw3X78021@khavrinen.lcs.mit.edu> To: Julian Elischer Cc: freebsd-net@FreeBSD.ORG Subject: Re: vlan traffic over ipsec tunnel In-Reply-To: References: <200204192001.g3JK1q748470@ambrisko.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org < said: > I don't know, but it may have problems setting promiscuous mode.. > is there such a thing in vlan mode? Certainly -- but the other VLANs configured on the same interface have to be prepared to appropriately ignore the traffic they receive that isn't addressed to them. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Apr 19 17:35:10 2002 Delivered-To: freebsd-net@freebsd.org Received: from garbo.lodgenet.com (garbo.lodgenet.com [204.124.122.252]) by hub.freebsd.org (Postfix) with ESMTP id 8F2E637B404 for ; Fri, 19 Apr 2002 17:35:05 -0700 (PDT) Received: from hardy.lodgenet.com (hardy.lodgenet.com [10.0.104.235]) by garbo.lodgenet.com (8.11.4/8.11.4) with ESMTP id g3K0Z4429008 for ; Fri, 19 Apr 2002 19:35:04 -0500 (CDT) Received: from chaplin.lodgenet.com (not verified[10.0.104.215]) by hardy.lodgenet.com with MailMarshal (4,2,5,0) id ; Fri, 19 Apr 2002 19:28:51 -0500 Received: by chaplin.lodgenet.com with Internet Mail Service (5.5.2653.19) id <2FNAT32J>; Fri, 19 Apr 2002 19:30:57 -0500 Message-ID: <3EA88113DE92D211807300805FA7994209149CFA@chaplin.lodgenet.com> From: "McKenna, Lee" To: "'freebsd-net@freebsd.org'" Subject: pxeboot and realtek 8139 Date: Fri, 19 Apr 2002 19:30:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Using 4.5-stable, I can get an Intel fxp0 card to work fine using pxeboot in a diskless configuration, but if I try the onboard RealTek 8139 it hangs when loading the kernel. I tried "BOOTP_WIRED_TO=rl0" but that didnt make a difference. Motherboard is a shuttle fv-24, with builtin RealTek 8139. About the only thing I can configure is the amount of memory for the network boot on the 8139, either 8, 16, 32, 64, or 128 -- changing this makes no difference. I'd rather just use the built-in 8139 so I dont have to buy an Intel card for all these machines... Any suggestions? Thanks, --Lee lmckenna@lodgenet.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Apr 19 23:18:33 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 35B2337B417 for ; Fri, 19 Apr 2002 23:18:30 -0700 (PDT) Received: from blossom.cjclark.org ([12.234.91.48]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020420061829.TVXQ1901.rwcrmhc52.attbi.com@blossom.cjclark.org>; Sat, 20 Apr 2002 06:18:29 +0000 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.6) id g3K6IT670329; Fri, 19 Apr 2002 23:18:29 -0700 (PDT) (envelope-from cjc) Date: Fri, 19 Apr 2002 23:18:28 -0700 From: "Crist J. Clark" To: Michael Smith Cc: freebsd-net@FreeBSD.ORG Subject: Re: network traffic analysis with a network switch Message-ID: <20020419231828.B70074@blossom.cjclark.org> References: <20020419081453.X30314@staff.texas.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020419081453.X30314@staff.texas.net>; from msmith@texas.net on Fri, Apr 19, 2002 at 08:14:54AM -0500 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Apr 19, 2002 at 08:14:54AM -0500, Michael Smith wrote: > Not quite sure how to set this up, or even if it can be setup... > I have a windows box, a FreeBSD box (gateway) and a RH box all > connected to a 100base-T network switch. The FreeBSD box > is then connected to a Cable Modem and a T1 router. > > I have a program on the RH box that can snoop and analyze some of > the network traffic of the windows box, however due to the nature > of network switches, it never sees the traffic. Don't ask about > the analyzer, I'm rather annoyed that it was written specifically > to compile and run only on RH and it's very close Linux relatives. > > Here is a rough visualization of the setup. > > +-------------+ +----+ > | Cable Modem | | T1 | > +-------------+ +----+ > \ / > +---------+ > | FreeBSD | > +---------+ > | > +------------------+ > | 100base-T Switch | > +------------------+ > / | \ > +----------+ +----+ +----------+ > | Windows1 | | RH | | Windows3 | > +----------+ +----+ +----------+ > > What I would like to be able to do is somehow send copies of > network traffic to the RH box without having to move it > between the FreeBSD box and the switch. Is this possible > and if so, how would I go about setting this up? Tell the Windows box that RH's IP is its gateway. Turn on IP forwarding on RH. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Apr 19 23:48:35 2002 Delivered-To: freebsd-net@freebsd.org Received: from nelly.internal.irrelevant.org (irrelevant.demon.co.uk [158.152.220.121]) by hub.freebsd.org (Postfix) with ESMTP id 7726437B41D; Fri, 19 Apr 2002 23:48:29 -0700 (PDT) Received: from simond by nelly.internal.irrelevant.org with local (Exim 3.35 #1) id 16yofX-0000mY-00; Sat, 20 Apr 2002 07:48:23 +0100 Date: Sat, 20 Apr 2002 07:48:23 +0100 From: Simon Dick To: Vinod Cc: freebsd-net@freebsd.org, frebsd-questions@freebsd.org Subject: Re: ethernet card not recognized Message-ID: <20020420064823.GC2488@irrelevant.org> References: <20020419183416.4527.qmail@web21108.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020419183416.4527.qmail@web21108.mail.yahoo.com> User-Agent: Mutt/1.3.28i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Apr 19, 2002 at 11:34:16AM -0700, Vinod wrote: > I had a windows machine with an SMC1211TX ethernet > card.i just installed freebsd 4.5 release on > it,removing windows.but it doesnt seem to recognize > the card at all and there isnt a eth0 or fxp0 > interface recognized.What needs to be done?isnt this > card supported.its a pretty common one,lil old though. I believe you need the rl driver for that card. -- Simon Dick simond@irrelevant.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Apr 20 9:17:55 2002 Delivered-To: freebsd-net@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id A424937B404; Sat, 20 Apr 2002 09:17:50 -0700 (PDT) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id g3KGHXG23172; Sat, 20 Apr 2002 09:17:33 -0700 Date: Sat, 20 Apr 2002 09:17:33 -0700 From: Brooks Davis To: Julian Elischer Cc: Doug Ambrisko , Archie Cobbs , Terry Lambert , "Peter J. Blok" , freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: vlan traffic over ipsec tunnel Message-ID: <20020420091733.A21119@Odin.AC.HMC.Edu> References: <200204192001.g3JK1q748470@ambrisko.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="FCuugMFkClbJLl1L" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from julian@elischer.org on Fri, Apr 19, 2002 at 01:18:16PM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 19, 2002 at 01:18:16PM -0700, Julian Elischer wrote: > failing that, I have just had "contributed" > some code that produces an actual "vlan" netgraph node. > You attach it to the ethernet node.. I'm still > reading it to work out what it does.. One thing worth noting. I'm pretty sure that a netgraph vlan node is going to have all sorts of trouble with cards that support hardware vlan decoding (that's most of the gigabit Ethernet cards). The problem is that vlan'd frames won't make it to ether_input at all. I believe the correct solution is to implement a nic capability which can be used to turn this support on and off like we're supposed to be able to do for hardware checksuming. Alternativly, the current driver code could be modified to fake up a vlan header and then call ether_input with the packet when the vlan driver isn't loaded (it currently discards the packet.) There may even be something to be said for doing both. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --FCuugMFkClbJLl1L Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8wZScXY6L6fI4GtQRApryAJ9UXW1TonFjTFQXAtgvVOPsPcsKWACg0LQv UeWvKfjCkNOGbZRWkxQuCd4= =1kjn -----END PGP SIGNATURE----- --FCuugMFkClbJLl1L-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Apr 20 22:12: 6 2002 Delivered-To: freebsd-net@freebsd.org Received: from web20004.mail.yahoo.com (web20004.mail.yahoo.com [216.136.225.49]) by hub.freebsd.org (Postfix) with SMTP id 3E37637B41A for ; Sat, 20 Apr 2002 22:12:05 -0700 (PDT) Message-ID: <20020421051205.33101.qmail@web20004.mail.yahoo.com> Received: from [61.223.0.54] by web20004.mail.yahoo.com via HTTP; Sat, 20 Apr 2002 22:12:05 PDT Date: Sat, 20 Apr 2002 22:12:05 -0700 (PDT) From: Vincent Chen Subject: why prefer old SA in KAME's IPSec? To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Dear all, I tried to establish ipsec tunnel between freebsd and several other platforms. Recently, I found that ipsec usually failed after the other machine reboot or crash. It seems that the machine use new SA after re-negotiate but freebsd use old SA. After searching maillist, I found that net.key.prefered_oldsa=0 will solve that problem. But why prefer old one? Thanks, Vincent Chen __________________________________________________ Do You Yahoo!? Yahoo! Games - play chess, backgammon, pool and more http://games.yahoo.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message