From owner-freebsd-net Sun Jan 7 20:42: 6 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.globalsoftwarelabs.com (unknown [203.115.26.242]) by hub.freebsd.org (Postfix) with ESMTP id 0E50137B400 for ; Sun, 7 Jan 2001 20:41:49 -0800 (PST) Received: by T200-BLDG-20.BBN.COM with Internet Mail Service (5.5.2650.21) id ; Mon, 8 Jan 2001 10:48:01 +0600 Message-ID: <839CB59F4DAED411A6E000D0B79E98280C2532@T200-BLDG-20.BBN.COM> From: Chaminda Rathnasinghe To: freebsd-net@freebsd.org Subject: tacacs+ on freebsd-4.0 Date: Mon, 8 Jan 2001 10:47:45 +0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi I'm struggling to install tacacs+ server on freebsd 4.0. it gives file missing message. but it works fine on Linux redhat 6. where can I get tacacs+ server for freebsd 4.0.The one I have from ftp://ftp-eng.cisco.com/pub/tacacs/tac_plus.F4.0.4.alpha.tar.Z or am I doing something wrong with the instalation. Thanks Chaminda To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jan 7 22:25:48 2001 Delivered-To: freebsd-net@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 87A1237B6F3 for ; Sun, 7 Jan 2001 22:18:08 -0800 (PST) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14FVj5-0000MQ-00; Sun, 07 Jan 2001 23:24:15 -0700 Message-ID: <3A595D0F.A30E2FFA@softweyr.com> Date: Sun, 07 Jan 2001 23:24:15 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Chaminda Rathnasinghe Cc: freebsd-net@freebsd.org Subject: Re: tacacs+ on freebsd-4.0 References: <839CB59F4DAED411A6E000D0B79E98280C2532@T200-BLDG-20.BBN.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Chaminda Rathnasinghe wrote: > > I'm struggling to install tacacs+ server on freebsd 4.0. it gives file > missing message. but it works fine on Linux redhat 6. > where can I get tacacs+ server for freebsd 4.0.The one I have from > > ftp://ftp-eng.cisco.com/pub/tacacs/tac_plus.F4.0.4.alpha.tar.Z > > or am I doing something wrong with the instalation. Yes, you're doing something wrong. Somebody already took the time to port this to FreeBSD and you're not taking advantage of it. If you have installed the FreeBSD Ports system, you can install it with: # cd /usr/ports/net/tac_plus4 # make install You need to be root to do this, as I've shown with the '#' prompt. If you haven't installed the FreeBSD Ports system, you should do that ASAP. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jan 8 1:53:30 2001 Delivered-To: freebsd-net@freebsd.org Received: from krell.webweaver.net (krell.webweaver.net [64.124.90.11]) by hub.freebsd.org (Postfix) with ESMTP id 9BBF337B402 for ; Mon, 8 Jan 2001 01:52:55 -0800 (PST) Received: from xwin.nmhtech.com (xwin.daemontech.net [208.138.46.161]) by krell.webweaver.net (Postfix) with ESMTP id 6616620F04; Mon, 8 Jan 2001 01:52:55 -0800 (PST) Content-Length: 5092 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200101052302.PAA07131@implode.root.com> Date: Mon, 08 Jan 2001 01:52:55 -0800 (PST) From: Nicole To: David Greenman Subject: Re: Problem with fxp0 card and slowing/dying transmits - now I'm really confused Cc: ppX , freebsd-net@FreeBSD.ORG, Tom Samplonius Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 05-Jan-01 David Greenman wrote: >> Ahha.. Well.. Nice new word for the day "wonky" I like that :) >> >> Yea.. as I change things on the server, I can see the switch respond to my >>settings when it it is autoconfig mode. (worried abt that too :> ) >> >> So then it *Could* be the motherboard.. I mean whats left, right? > > It's very unlikely, but stranger things have happend. One other thing - > on some switches the new settings don't take effect until they are properly > written out to NVRAM. You might want to verify that the new switch settings > are really getting set. > > -DG Now I am really confused. After more testing I have found that sending a file via scp or cat'ing through sendmail works like a champ if I go to a machine outside of the network. But seems to be a problem for the same machine when trying to go to a server connected to the same switch. OK.. maybe its the switch you say. Me too. Until I just came from putting the machines on a different switch and still having the same problem. It's also a completly different make and manufacture of switch. Also one other weird question. What is the real difference between a cable with 2 pairs and a cable with 4 pairs were 10/100 ethernet is concerned. On another server that was using a SMC/DEC card I found it would go nuts when it had a 2 pair cable, but worked Ok with a 4 pair cable. From everything I can tell, 10/100 ethernet should not care abt the extra 2 pairs. Nicole off to a padded room. > > David Greenman > Co-founder, The FreeBSD Project - http://www.freebsd.org > President, TeraSolutions, Inc. - http://www.terasolutions.com > Pave the road of life with opportunities. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message On Thu, 4 Jan 2001, Nicole wrote: >> >> >> Hello all >> My poor hair is abt to come out as I keep pulling on it trying to solve what >> is, to me, a Very Very weird problem. >> >> I have a server, running FreeBSD-3.5-STABLE as of 1/2/2000. It is a dual >> 400Mhz processor system with (I think) an Intel Motherboard (could also be a >> tyan) that has built in (intel) Ethernet and SCSI. It has 256 Megs of Memory. >> It is connected to an Intel 460 switch along with abt 5 others servers very >> similar to it. >> >> The problem is that when trying to scp a file or send a large file to it via >> sendmail, (large = 253952 ) it seems to transmit along >> happily, then (at least for scp) at abt 1/2 way through, it seems to just >>start >> crawling. When I have let it run, it will go forever and will seem to >> eventually finish but will hang as the transfer speed keeps dropping through >>the floor. >> >> I have tried numerous things, including shutting off the built in Ethernet >> card and replacing it with a standard intel 10/100 pro card. (not the new >> ones with the small VLSI chip, but the older style unit, exactly like what >> the other systems have) >> >> I have tried altering net.inet.tcp.rfc1323 and net.inet.tcp.rfc1644. I have >> tried setting the card into solid 100TX via ifconfig (ifconfig fxp0 inet >> 10.0.0.1 netmask 255.255.255.0 media 100baseTX ) with no effect. >> I even tried setting it to 10/BT with no improvement. Changed the port it >> was >> in on the switch. Changed cables 3 times. Said several ancient prayers, and >> even succomed to eating dead cow over it. >> >> The only other semi clue is that it was just moved from another ISP were it >> was plugged into a Cisco switch and it seemed to be working fine there. All >> of >> the other servers with the same card seem to work fine however via the same >> Intel switch. You would think it would be happier, Intel card to Intel switch >> anyway. >> >> ANY help or clues would be appreciated. Could this be caused by the MB? What >> else can I try? >> >> Please CC me in any replies to make sure I see it right away. >> >> Thanks!!! >> >> >> Nicole >> >> nicole@home:/home/nicole> sysctl -a | grep tcp >> tcpcb: 288, 2344, 124, 142, 2761 >> net.inet.tcp.rfc1323: 0 >> net.inet.tcp.rfc1644: 1 >> net.inet.tcp.mssdflt: 512 >> net.inet.tcp.rttdflt: 3 >> net.inet.tcp.keepidle: 14400 >> net.inet.tcp.keepintvl: 150 >> net.inet.tcp.sendspace: 16384 >> net.inet.tcp.recvspace: 16384 >> net.inet.tcp.keepinit: 150 >> net.inet.tcp.log_in_vain: 0 >> net.inet.tcp.delayed_ack: 1 >> net.inet.tcp.pcbcount: 124 >> net.inet.tcp.always_keepalive: 1 >> nicole@unixgirl.com |\ __ /| (`\ http://www.unixgirl.com/ webmistress@dangermouse.org | o_o |__ ) ) http://www.dangermouse.org/ nicole@deviantimages.com // \\ http://www.deviantimages.com/ ---------------------------(((---(((---------------------------------------- -- Powered by Coka-Cola and FreeBSD -- -- I don't speak for anybody but myself - that's enough trouble -- -- Back Up My Hard Drive? I Can't Find The Reverse Switch! -- ------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jan 8 3:56:11 2001 Delivered-To: freebsd-net@freebsd.org Received: from bart.esiee.fr (bart.esiee.fr [147.215.1.20]) by hub.freebsd.org (Postfix) with ESMTP id E56E637B400 for ; Mon, 8 Jan 2001 03:55:51 -0800 (PST) Received: (from bonnetf@localhost) by bart.esiee.fr (8.11.1/8.11.1) id f08Btfc09312 for freebsd-net@freebsd.org; Mon, 8 Jan 2001 12:55:41 +0100 (MET) From: Frank Bonnet Message-Id: <200101081155.f08Btfc09312@bart.esiee.fr> Subject: rc.network clarification in adding routes (4.2) To: freebsd-net@freebsd.org Date: Mon, 08 Jan 2001 12:55:41 MET X-Mailer: Elm [revision: 212.5] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi I need some clarification on variables setup to add statics routes in the followin part on rc.network. # Set up any static routes. This should be done before router discovery. # if [ -n "${static_routes}" ]; then for i in ${static_routes}; do eval route_args=\$route_${i} route add ${route_args} done fi I've put the following in rc.conf to add internals routes static_routes="res40" res40=" -net 147.215.40 147.215.20.1 255.255.255.0" static_routes="res80" res80=" -net 147.215.80 147.215.20.1 255.255.255.0" but the route command give an invalid argument error message. Thanks for any infos. -- Frank Bonnet To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jan 8 4:26:53 2001 Delivered-To: freebsd-net@freebsd.org Received: from vista.athms.com (athms.bayarea.net [204.71.213.154]) by hub.freebsd.org (Postfix) with ESMTP id 19E2937B402 for ; Mon, 8 Jan 2001 04:26:36 -0800 (PST) Received: from goofy.int.athms.com ([192.168.100.12] helo=athms.com) by vista.athms.com with esmtp (Exim 3.16) id 14FbUs-000D6v-00 ; Mon, 08 Jan 2001 04:33:58 -0800 Message-ID: <3A59B297.9D82212F@athms.com> Date: Mon, 08 Jan 2001 04:29:11 -0800 From: Tom Czarnik X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Frank Bonnet Cc: freebsd-net@FreeBSD.ORG Subject: Re: rc.network clarification in adding routes (4.2) References: <200101081155.f08Btfc09312@bart.esiee.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Frank Bonnet wrote: > I need some clarification on variables setup to add > statics routes in the followin part on rc.network. > > I've put the following in rc.conf to add internals routes > > static_routes="res40" > res40=" -net 147.215.40 147.215.20.1 255.255.255.0" > static_routes="res80" > res80=" -net 147.215.80 147.215.20.1 255.255.255.0" > > but the route command give an invalid argument error message. static_routes="res40 res80" route_res40="-net 147.215.40 147.215.20.1 255.255.255.0" route_res80="-net 147.215.80 147.215.20.1 255.255.255.0" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jan 8 4:36: 7 2001 Delivered-To: freebsd-net@freebsd.org Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by hub.freebsd.org (Postfix) with ESMTP id 94A7E37B6A9 for ; Mon, 8 Jan 2001 04:33:07 -0800 (PST) Received: from ac.upc.es (fonoll.ac.upc.es [147.83.32.14]) by roura.ac.upc.es (8.11.0/8.11.0) with ESMTP id f08CZfO02123; Mon, 8 Jan 2001 13:35:45 +0100 (MET) Message-ID: <3A59B41D.B20E31ED@ac.upc.es> Date: Mon, 08 Jan 2001 13:35:41 +0100 From: Oscar-Ivan Lepe-Aldama Organization: DAC/UPC X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: es, en MIME-Version: 1.0 To: net@freebsd.org Subject: On the performance of the xl driver Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I have a 4.1.1 box set up as a router that seems to have trouble dealing with packet rates exceeding 1000 pkt/s. The router is a 100Mhz Pentium with 16MB of RAM and two 3Com905B-TX ethernet adapters attached each to a Ethernet subnetwork. The problem manifests itself when some packets experience a huge forwarding latency, relatively to the average value. The average forwarding latency time is 52us while the troubled packets exhibit a latency of up to 6000us. I have observed that this is due to a call to the xl_stats_update() routine while the kernel is at a high priority level (perhaps splimp). This happens as part of the xl_intr routine, when the network-adapter's interrupt status word has its XL_STAT_STATSOFLOW bit set. The xl_stats_update() takes almost 6000us to complete and processing for whichever packet that arrives during this time will be deferred. Moreover, I have observed that this only happens when the packet rate is 1000 pkt/s or more. At lower rates, the XL_STAT_STATSOFLOW bit is never set because the network-adapter's statistics buffer is periodicaly clean at a "sufficient" pace -the xl_stats_update() is called from softclock() at a low kernel's priority level.- To make matters worst, this is a phenomenon directly proportional to the packet rate. So the question is weather this is a bug or not and why. Another point. To temporarly solve this I have disable the network adapter's XL_STAT_STATSOFLOW interrupt (at if_xlreg.h, #define XL_INTRS) but I don't know what are the implications of this, so any comments are welcome. Cheers, P.S. I'm not subscribed to the list so please Cc to my email account. Thanks. -- ======================================================================== 0 0 0 Oscar-Ivan Lepe-Aldama | UPC-Campus Nord, DAC 0 0 0 e-mail: oscar@ac.upc.es | Modul D6, despatx 116 0 0 0 phone: +34 93 401 7187 | Jordi Girona, 1-3 U P C fax: +34 93 401 7055 | 08034 Barcelona - SPAIN WWW: http://www.ac.upc.es/homes/oscar/ ======================================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jan 8 6:56:32 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail2.iadfw.net (mail2.iadfw.net [206.66.12.234]) by hub.freebsd.org (Postfix) with SMTP id 0757037B699 for ; Mon, 8 Jan 2001 06:53:23 -0800 (PST) Received: from Jason from [64.31.207.237] by mail2.iadfw.net (/\##/\ Smail3.1.30.16 #30.26) with smtp for sender: id ; Mon, 8 Jan 2001 08:53:23 -0600 (CST) Message-ID: <00ce01c07983$630ac220$edcf1f40@pdq.net> From: "Jason Smethers" To: "Nicole" Cc: References: Subject: Re: Problem with fxp0 card and slowing/dying transmits - now I'm really confused Date: Mon, 8 Jan 2001 08:57:56 -0600 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 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org From: "Nicole" > Also one other weird question. What is the real difference between a cable > with 2 pairs and a cable with 4 pairs were 10/100 ethernet is concerned. On > another server that was using a SMC/DEC card I found it would go nuts when it > had a 2 pair cable, but worked Ok with a 4 pair cable. From everything I can > tell, 10/100 ethernet should not care abt the extra 2 pairs. > > Nicole > off to a padded room You'd think that just because the extra pairs aren't used to transmit, wouldn't you. It is probably a good guess that that two pair cables have all four pairs in it but the extra two are not connected? In this case the extra two pairs are not grounded and thus act as antennae. It doesn't take a lot of interference induce errors on a 100Mbp/s Ethernet system. Since you did not explicitly say that you tried multiple two and four pair cables, etc... Other problems may include cheap materials or incorrect RJ-45 connectors. e.g. the cable is solid conductor and the RJ-45 connector is designed for stranded conductor wire. There may be bends in the cable, an excessive amount of untwisting of the pairs at termination points, or the wire may be patched through to many patch panels. Are you sure that it is category 5 cable? Is or was the network punch panels once used to connect telephones? If it was there may be bridge taps laying around. - Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jan 8 10:38:53 2001 Delivered-To: freebsd-net@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id 6BC0337B6C6 for ; Mon, 8 Jan 2001 10:18:58 -0800 (PST) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id KAA14658; Mon, 8 Jan 2001 10:11:46 -0800 (PST) Message-Id: <200101081811.KAA14658@implode.root.com> To: Nicole Cc: ppX , freebsd-net@FreeBSD.ORG, Tom Samplonius Subject: Re: Problem with fxp0 card and slowing/dying transmits - now I'm really confused In-reply-to: Your message of "Mon, 08 Jan 2001 01:52:55 PST." From: David Greenman Reply-To: dg@root.com Date: Mon, 08 Jan 2001 10:11:46 -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Now I am really confused. > After more testing I have found that sending a file via scp or cat'ing through >sendmail works like a champ if I go to a machine outside of the network. But >seems to be a problem for the same machine when trying to go to a server >connected to the same switch. > OK.. maybe its the switch you say. Me too. Until I just came from putting the >machines on a different switch and still having the same problem. It's also a >completly different make and manufacture of switch. Duplex problems often show up as weird performance problems related to the speed of data transfer, size of the packets, or round-trip time to the destination. This happens because during a duplex mismatch, the full duplex side doesn't retransmit on a collision and if the half duplex side sees traffic on the receive side while it is transmitting it thinks it's a collision and stops sending the packet. So for situations (small packets or larger round-trip latency) where the ACK is unlikely to collide with the transmit, things appear to work okay. In other situations where the ACK collides, performance crawls. > Also one other weird question. What is the real difference between a cable >with 2 pairs and a cable with 4 pairs were 10/100 ethernet is concerned. On >another server that was using a SMC/DEC card I found it would go nuts when it >had a 2 pair cable, but worked Ok with a 4 pair cable. From everything I can >tell, 10/100 ethernet should not care abt the extra 2 pairs. I don't know about the affects of 2 pair vs 4 pair, but one cable related thing I do know will have an affect is stranded vs solid core wire. I've always had problems using solid core wire for any significant length (more than 6 feet) with the Pro/100. Stranded wire on the other hand has never given me a problem even for runs of >100 feet. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jan 8 12:40:57 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.wolves.k12.mo.us (mail.wolves.k12.mo.us [207.160.214.1]) by hub.freebsd.org (Postfix) with ESMTP id 84E5E37B780 for ; Mon, 8 Jan 2001 12:27:09 -0800 (PST) Received: from mail.wolves.k12.mo.us (cdillon@mail.wolves.k12.mo.us [207.160.214.1]) by mail.wolves.k12.mo.us (8.9.3/8.9.3) with ESMTP id OAA01483; Mon, 8 Jan 2001 14:26:58 -0600 (CST) (envelope-from cdillon@wolves.k12.mo.us) Date: Mon, 8 Jan 2001 14:26:58 -0600 (CST) From: Chris Dillon To: David Greenman Cc: Nicole , ppX , freebsd-net@FreeBSD.ORG, Tom Samplonius Subject: Re: Problem with fxp0 card and slowing/dying transmits - now I'm really confused In-Reply-To: <200101081811.KAA14658@implode.root.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 8 Jan 2001, David Greenman wrote: > I don't know about the affects of 2 pair vs 4 pair, but one > cable related thing I do know will have an affect is stranded vs > solid core wire. I've always had problems using solid core wire > for any significant length (more than 6 feet) with the Pro/100. > Stranded wire on the other hand has never given me a problem even > for runs of >100 feet. It really shouldn't matter wether the wire has a solid or stranded core, but wether it _at_least_ meats the Category 5 standards when doing 100BaseTX, or _at_least_ Category 3 when doing only 10BaseT. Those standards include not just the wire, but the entire link, including its terminations and any intermediary connections. We're using nearly a thousand of the Intel NICs with both short and very long runs (up to the max 100 meters or even a bit beyond), and any wiring between the patch panel and the wall outlet is always solid. All of the patch cables (between computer and wall outlet or between patch panel and hub/switch) are always stranded. We've never had a link problem in these situations, so long as the whole link met the specifications. The problem that you probably incurred by using solid-core wire as a patch cable is that you need to install solid-core terminators on the end of the cable. Stranded-core terminators often will NOT work with solid-core cable because of the wire penetrator design (the gold pins). Many times the solid cable will cause the penetrator to deflect away from the cable, causing either no connection, or an intermittent connection. Take a very close look at the penetrator design in the terminators you use. If they are perfectly straight and want to go straight down into the center of the core, they'll only work with stranded cable. If they attempt to "straddle" both sides the core, they should work well with solid cable and most likely stranded as well. -- Chris Dillon - cdillon@wolves.k12.mo.us - cdillon@inter-linc.net FreeBSD: The fastest and most stable server OS on the planet. For IA32 and Alpha architectures. IA64, PPC, and ARM under development. http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jan 8 18:16:32 2001 Delivered-To: freebsd-net@freebsd.org Received: from krell.webweaver.net (krell.webweaver.net [64.124.90.11]) by hub.freebsd.org (Postfix) with ESMTP id 8A61937B699 for ; Mon, 8 Jan 2001 18:16:14 -0800 (PST) Received: from xwin.nmhtech.com (xwin.daemontech.net [208.138.46.161]) by krell.webweaver.net (Postfix) with ESMTP id 3A37B20F04; Mon, 8 Jan 2001 18:16:14 -0800 (PST) Content-Length: 3918 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200101081811.KAA14658@implode.root.com> Date: Mon, 08 Jan 2001 18:16:14 -0800 (PST) From: Nicole To: David Greenman Subject: Re: Problem with fxp0 card and slowing/dying transmits -SOLVED! Cc: Tom Samplonius , freebsd-net@FreeBSD.ORG, ppX Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org First off, let me say thank You!! to everyone who helped. It seems that problem was a duplex problem, but not from the switch to the server but from the switch, to the switch at AboveNet. Our switch, which I had rebooted several times, was set auto neg for the uplink to their switch and was showing 100MB Half Duplex, No-BP. Since I was playing with the switch remotely and becouse the problem was communication from server to server, I never suspected the connection to the Net. The tranfer speed to/from the server via the Net was very fast. But server to server across the switch was not. However, it seems that after talking with an AboveNet engineer, that their switch was at 100MB/full Duplex. When I forced our switch to that setting (on port 1) connected to their switch. the server to server speed, went to normal. So somehow, the duplex mismatch there, was forcing the in/out bound traffic to take a very high priority over the server to server traffic. When everything possible has been exausted, it must then be something otherwise not thought possible. Nicole On 08-Jan-01 David Greenman wrote: >> Now I am really confused. >> After more testing I have found that sending a file via scp or cat'ing >> through >>sendmail works like a champ if I go to a machine outside of the network. But >>seems to be a problem for the same machine when trying to go to a server >>connected to the same switch. >> OK.. maybe its the switch you say. Me too. Until I just came from putting >> the >>machines on a different switch and still having the same problem. It's also a >>completly different make and manufacture of switch. > > Duplex problems often show up as weird performance problems related to the > speed of data transfer, size of the packets, or round-trip time to the > destination. This happens because during a duplex mismatch, the full duplex > side doesn't retransmit on a collision and if the half duplex side sees > traffic on the receive side while it is transmitting it thinks it's a > collision and stops sending the packet. So for situations (small packets or > larger round-trip latency) where the ACK is unlikely to collide with the > transmit, things appear to work okay. In other situations where the ACK > collides, performance crawls. > >> Also one other weird question. What is the real difference between a cable >>with 2 pairs and a cable with 4 pairs were 10/100 ethernet is concerned. On >>another server that was using a SMC/DEC card I found it would go nuts when it >>had a 2 pair cable, but worked Ok with a 4 pair cable. From everything I can >>tell, 10/100 ethernet should not care abt the extra 2 pairs. > > I don't know about the affects of 2 pair vs 4 pair, but one cable related > thing I do know will have an affect is stranded vs solid core wire. I've > always had problems using solid core wire for any significant length (more > than 6 feet) with the Pro/100. Stranded wire on the other hand has never > given > me a problem even for runs of >100 feet. > > -DG > > David Greenman > Co-founder, The FreeBSD Project - http://www.freebsd.org > President, TeraSolutions, Inc. - http://www.terasolutions.com > Pave the road of life with opportunities. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message nicole@unixgirl.com |\ __ /| (`\ http://www.unixgirl.com/ webmistress@dangermouse.org | o_o |__ ) ) http://www.dangermouse.org/ nicole@deviantimages.com // \\ http://www.deviantimages.com/ ---------------------------(((---(((---------------------------------------- -- Powered by Coka-Cola and FreeBSD -- -- I don't speak for anybody but myself - that's enough trouble -- -- Back Up My Hard Drive? I Can't Find The Reverse Switch! -- ------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jan 8 22:53:36 2001 Delivered-To: freebsd-net@freebsd.org Received: from VL-MS-MR003.sc1.videotron.ca (relais.videotron.ca [24.201.245.36]) by hub.freebsd.org (Postfix) with ESMTP id D792937B400; Mon, 8 Jan 2001 22:53:11 -0800 (PST) Received: from jehovah ([24.202.203.37]) by VL-MS-MR003.sc1.videotron.ca (Netscape Messaging Server 4.15) with SMTP id G6VV4904.XO9; Tue, 9 Jan 2001 01:52:57 -0500 Message-ID: <001b01c07a08$fbd0dc30$25cbca18@jehovah> From: "Bosko Milekic" To: Cc: , Subject: lock order violation? (Was: Fw: [patch] quick review) Date: Tue, 9 Jan 2001 01:54:16 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, As Alfred suggests below, there may be a potential problem with the mbuf wait code calling m_reclaim() [the drain routines] with the mmbfree (mbuf freelist mutex) lock held. Presently, to avoid a race condition, we call m_reclaim() with the lock held and recurse into it from the drain routines which call m_free{m}() to free mbufs. This was initially written this way; it was partially adopted from BSD/OS (it's done the same way). This way, the mbuf wait code is sure to be the first one to get the chance to allocate after the drain routines run. Unfortunately, as mentionned, there appears to be a potential lock order problem. Using as an example the BSD/OS code, something like this happens: - In ip_slowtimo(), IPQ_LOCK is obtained and with the lock held, ip_freef() is called. ip_freef() calls m_freem() which grabs the MBUF_LOCK. The lock order here is IPQ -> MBUF. - In ip_drain(), which is called from m_reclaim() with the MBUF lock already held, IPQ lock is acquired. Then ip_freef() is called which does m_freem() [which grabs MBUF lock]. The lock order here, since ip_drain() is called with MBUF already held is MBUF -> IPQ. Are we correct to assume that there is a potential for deadlock here? Clearly, if one thread in ip_slowtimo() has IPQ and another thread presently draining has MBUF, there is deadlock. The proposed patch (for FreeBSD) is at the address immediately below. For now, what it does is avoid the lock recursion by calling m_reclaim() without the mbuf lock held. We deal with the race condition. In the future, if we can, we may want to weed out the drain routines and make sure that there are no lock ordering problems; but for now, until we're done with all the locking, I think it's better to do it this way. Thanks, Bosko. P.S.: Please feel free to snip -arch from the CC list, if judged appropriate. Alfred Perlstein wrote: > * Bosko Milekic [010108 19:13] wrote: > > Hi Alfred, > > > > Can you please review this: > > > > http://people.freebsd.org/~bmilekic/code/no_rec_mbsleep.patch > > > > All it does is in m_mballoc_wait() [wait routine for mbuf allocation] > > drop the mbuf freelist lock before calling the drain routines. It avoids > > recursing into the lock from within the drain routines. We discussed this > > some time ago and you brought up the fact that it should probably be changed; > > although I don't recall exactly why (besides for generally just getting rid > > of the lock recursion and relatively large lock contention)... I recall you > > having an even more important reason, can you remind me, if applicable? > > It's a lock ordering problem, you _can_ unwind the lock in the protocol > drain routines before locking down a socketbuffer or whatnot, but the > fact of the matter is if you have to lock _anything_ you pretty much > have to unwind the lock or have a reversal problem as the mbuf system > should be a leaf-lock. > > You're also blocking the natural free'ing of the mbufs by other code > running. > > So the comment is sorta lacking, it's to avoid: > 1) lock recursion (as you stated) > 2) lock reversal > 3) needing to to explicitly unwind the lock to avoid #2 > > At least I think. :) > > It looks like BSD/os holds the lock during the protocol drain routines, > but I think that's a mistake. > > Would you mind reposting this to -net/-smp, I think I'm right about > this, but some peer review couldn't hurt, I wasn't sure if reposting > was ok considering this came across in private. > > -- > -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] > "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jan 8 23: 2:44 2001 Delivered-To: freebsd-net@freebsd.org Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (Postfix) with ESMTP id E62DA37B400 for ; Mon, 8 Jan 2001 23:02:26 -0800 (PST) Received: from imap.gv.tsc.tdk.com (imap.gv.tsc.tdk.com [192.168.241.198]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id XAA22130; Mon, 8 Jan 2001 23:02:19 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by imap.gv.tsc.tdk.com (8.9.3/8.9.3) with ESMTP id XAA13421; Mon, 8 Jan 2001 23:02:18 -0800 (PST) (envelope-from Don.Lewis@tsc.tdk.com) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id XAA15712; Mon, 8 Jan 2001 23:02:17 -0800 (PST) From: Don Lewis Message-Id: <200101090702.XAA15712@salsa.gv.tsc.tdk.com> Date: Mon, 8 Jan 2001 23:02:17 -0800 In-Reply-To: <20001231210746.A81834@skriver.dk> References: <20001218182600.C1856@skriver.dk> <20001219222730.A29741@skriver.dk> <200012201046.CAA19456@salsa.gv.tsc.tdk.com> <20001220155118.N81814@skriver.dk> <20001231210746.A81834@skriver.dk> X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Jesper Skriver , Don Lewis Subject: ICMP error processing (was: Re: what to do now ? Was: cvs commit: src/sys/netinet ip_icmp.c tcp_subr.c tcp_var.h) Cc: freebsd-net@FreeBSD.ORG Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [ cc: trimmed ] On Dec 31, 9:07pm, Jesper Skriver wrote: } Subject: Re: what to do now ? Was: cvs commit: src/sys/netinet ip_icmp.c } On Wed, Dec 20, 2000 at 03:51:18PM +0100, Jesper Skriver wrote: } > On Wed, Dec 20, 2000 at 02:46:21AM -0800, Don Lewis wrote: } > } > > } @@ -714,6 +715,15 @@ } > > } (lport && inp->inp_lport != lport) || } > > } (laddr.s_addr && inp->inp_laddr.s_addr != laddr.s_addr) || } > > } (fport && inp->inp_fport != fport)) { } > > } + inp = inp->inp_list.le_next; } > > } + continue; } > > } > > Wouldn't it be more cleaner (gets rid of the loop) and more efficient (if } > > we're getting blasted with ICMP messages) to use in_pcblookup_hash()? } > } > I didn't change the loop, but I'll have a look at this code, to see if } > we can improve it, but again, to get moving, I'd like to commit this, } > and leave this for a later improvement, ok ? } } I've looked at this, and as far as I can see we cannot use } in_pcblookup_hash, as it lookup a single session, and the code can in } other cases act on multiple sessions, path MTU discovery is such a case. Actually, I don't see where path MTU discovery acts on multiple sessions. It looks like we pass a non-NULL third argument to tcp_ctlinput(), which causes tcp_ctlinput() to pass the optional IP address and port information to in_pcbnotify(), and in_pcbnotify() doesn't handle the PRC_MSGSIZE specially, like it does with PRC_IS_REDIRECT and PRC_HOSTDEAD. Bug? Should path MTU discovery be handled by pfctlinput() to notify all the protocols? My concern is that having to search through all the PCBs each time an ICMP error message is received makes it too easy to DoS a busy server that has a lot of open sockets. The way icmp -> notify code is structured is kind of strange anyway (there's a nice diagram in TCP/IP Illustrated Volume 2 - Figure 22.32). I think it would make more sense to validate the ICMP error and redirect packets fairly early on by doing the PCB lookup and dropping any ICMP packets that don't have a matching PCB. Redirects *and* path MTU discovery messages would then be handled by pfctlinput(), and the other errors by the protocol specific handler. I think it is a mistake to call the same *_ctlinput() functions from both icmp_input() for one connection and pfctlinput() for many connections. I think the call chain should look something like the following, though some more thought needs to be given to sensibly unwinding things to avoid duplicate code and avoid doing duplicate work. icmp_input->{tcp,udp}_ctlinput1->in_pcbnotify1-> {pfctlinput->{tcp,udp}_ctlinput->in_pcbnotify->..., {tcp,udp}_notify, ...} In the current code, it looks like an ICMP error that the addresses and ports zeroed out will erroneously affect many sessions (what do the RFCs say?). Another bit of strangeness is pfctlinput(PRC_IF{UP,DOWN}, ...) which is passed the interface address, which is matched against the *destination* address in the TCP and UDP PCBs. Fortunately these protocols seem to ignore these commands ... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jan 9 9:16:30 2001 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 466F937B6C7 for ; Tue, 9 Jan 2001 09:16:10 -0800 (PST) Received: by freesbee.wheel.dk (Postfix, from userid 1001) id 631353E59; Tue, 9 Jan 2001 18:16:09 +0100 (CET) Date: Tue, 9 Jan 2001 18:16:09 +0100 From: Jesper Skriver To: Don Lewis Cc: freebsd-net@FreeBSD.ORG Subject: Re: ICMP error processing (was: Re: what to do now ? Was: cvs commit: src/sys/netinet ip_icmp.c tcp_subr.c tcp_var.h) Message-ID: <20010109181609.B10100@skriver.dk> References: <20001218182600.C1856@skriver.dk> <20001219222730.A29741@skriver.dk> <200012201046.CAA19456@salsa.gv.tsc.tdk.com> <20001220155118.N81814@skriver.dk> <20001231210746.A81834@skriver.dk> <200101090702.XAA15712@salsa.gv.tsc.tdk.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200101090702.XAA15712@salsa.gv.tsc.tdk.com>; from Don.Lewis@tsc.tdk.com on Mon, Jan 08, 2001 at 11:02:17PM -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Jan 08, 2001 at 11:02:17PM -0800, Don Lewis wrote: > [ cc: trimmed ] > > On Dec 31, 9:07pm, Jesper Skriver wrote: > } Subject: Re: what to do now ? Was: cvs commit: src/sys/netinet ip_icmp.c > } On Wed, Dec 20, 2000 at 03:51:18PM +0100, Jesper Skriver wrote: > } > On Wed, Dec 20, 2000 at 02:46:21AM -0800, Don Lewis wrote: > } > > } > > } @@ -714,6 +715,15 @@ > } > > } (lport && inp->inp_lport != lport) || > } > > } (laddr.s_addr && inp->inp_laddr.s_addr != laddr.s_addr) || > } > > } (fport && inp->inp_fport != fport)) { > } > > } + inp = inp->inp_list.le_next; > } > > } + continue; > } > > > } > > Wouldn't it be more cleaner (gets rid of the loop) and more efficient (if > } > > we're getting blasted with ICMP messages) to use in_pcblookup_hash()? > } > > } > I didn't change the loop, but I'll have a look at this code, to see if > } > we can improve it, but again, to get moving, I'd like to commit this, > } > and leave this for a later improvement, ok ? > } > } I've looked at this, and as far as I can see we cannot use > } in_pcblookup_hash, as it lookup a single session, and the code can in > } other cases act on multiple sessions, path MTU discovery is such a case. > > Actually, I don't see where path MTU discovery acts on multiple sessions. It was not something I studied in great detail, but the code currently has the ability to do so. > It looks like we pass a non-NULL third argument to tcp_ctlinput(), which > causes tcp_ctlinput() to pass the optional IP address and port information > to in_pcbnotify(), and in_pcbnotify() doesn't handle the PRC_MSGSIZE > specially, like it does with PRC_IS_REDIRECT and PRC_HOSTDEAD. Bug? > Should path MTU discovery be handled by pfctlinput() to notify all the > protocols? This would make sense, the MTU is protocol independent > My concern is that having to search through all the PCBs each time an > ICMP error message is received makes it too easy to DoS a busy server > that has a lot of open sockets. > > The way icmp -> notify code is structured is kind of strange anyway > (there's a nice diagram in TCP/IP Illustrated Volume 2 - Figure 22.32). > I think it would make more sense to validate the ICMP error and redirect > packets fairly early on by doing the PCB lookup and dropping any ICMP > packets that don't have a matching PCB. Redirects *and* path MTU > discovery messages would then be handled by pfctlinput(), and the other > errors by the protocol specific handler. I think it is a mistake to > call the same *_ctlinput() functions from both icmp_input() for one > connection and pfctlinput() for many connections. I think the call > chain should look something like the following, though some more thought > needs to be given to sensibly unwinding things to avoid duplicate code > and avoid doing duplicate work. > > icmp_input->{tcp,udp}_ctlinput1->in_pcbnotify1-> > {pfctlinput->{tcp,udp}_ctlinput->in_pcbnotify->..., {tcp,udp}_notify, ...} > > In the current code, it looks like an ICMP error that the addresses > and ports zeroed out will erroneously affect many sessions (what do > the RFCs say?). rfc793 doesn't mention any specific range for port numbers apart form being a 16 bit number, but it does say explicitly (in section 3.3) that the sequence number is a range from 0 to 2**32 - 1 If the port numbers and/or addresses are zero we affect many (or even all) sessions, I don't have anything near a full overview of the kernel, so I don't know if there is any check anywhere else for zero in those addresses and/or port numbers. But one "easy" fix for that would be to change the loop as you suggested to a in_pcblookup_hash lookup, I can have a look at this, but I'd appreciate if someone could review and commit kern/23986 so I don't have too many outstanding changes. > Another bit of strangeness is pfctlinput(PRC_IF{UP,DOWN}, ...) which > is passed the interface address, which is matched against the > *destination* address in the TCP and UDP PCBs. Fortunately these > protocols seem to ignore these commands ... As I see this we need a new function to do the same just for the source address in TCP and UDP PCBs, right ? /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work: Network manager @ AS3292 (Tele Danmark DataNetworks) Private: Geek @ AS2109 (A much smaller network ;-) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jan 9 12: 1:54 2001 Delivered-To: freebsd-net@freebsd.org Received: from aker.com.br (unknown [200.252.12.5]) by hub.freebsd.org (Postfix) with ESMTP id A11EA37B401; Tue, 9 Jan 2001 12:01:29 -0800 (PST) Received: from aker.com.br (jorge.aker.com.br [10.0.0.16]) by aker.com.br (8.9.3/8.9.3) with ESMTP id QAA00847; Tue, 9 Jan 2001 16:45:00 -0200 (BRST) (envelope-from jorge@aker.com.br) Message-ID: <3A5B6E27.5787D716@aker.com.br> Date: Tue, 09 Jan 2001 18:01:43 -0200 From: Jorge Peixoto Vasquez Organization: Aker Security Solutions X-Mailer: Mozilla 4.73 [en] (X11; I; FreeBSD 4.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@freebsd.org, freebsd-security@freebsd.org Subject: IPSEC: racoon and Win2K Content-Type: multipart/mixed; boundary="------------2BB9B253F9FAFFDCA0F7B238" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a multi-part message in MIME format. --------------2BB9B253F9FAFFDCA0F7B238 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I've read the mini-howto on how to setup IPSEC on the FreeBSD (http://asherah.dyndns.org/~josh/ipsec-howto.txt) and have been most succesful so far. I would be very glad if anyone could help me on the following matter: The only problem I've encountered is that, when making Win2K and FreeBSD interoperate, the IKE's phase 2 only suceeds if Win2K initiates the process. If racoon is to start it, Win2k will not accept any proposal for phase 2, complaining that the dh group number (which should correctly be either 1 or 2) received is 1 or 2 (depending on the pfs_group setting in racoon.conf) and not null(0). If I try setting pfs_group to null, I get a parse error. All the docs I found in the kame site (www.kame.net), the handbook, and the man pages haven't been of any help too. Thank you very much for your attention, Sincerely, jOrge p.s. I am using FreeBSD 4.2-Stable, racoon 20001111a and (YES) I got the high-encryption pack and SP1 installed on the Win2K box. -- Jorge Peixoto Vasquez, Elet. Eng. Aker Security Solutions tel. +55 - 61 - 340 9083 --------------2BB9B253F9FAFFDCA0F7B238 Content-Type: text/plain; charset=us-ascii; name="racoon.conf" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="racoon.conf" # search this file for pre_shared_key with various ID key. path pre_shared_key "/usr/local/etc/racoon/psk.txt" ; # "log" specifies logging level. It is followed by either "info", "notify", # "debug" or "debug2". log debug; # "padding" defines some parameter of padding. You should not touch these. padding { maximum_length 20; # maximum padding length. randomize off; # enable randomize length. strict_check off; # enable strict check. exclusive_tail off; # extract last one octet. } # Specification of default various timer. timer { # These value can be changed per remote node. counter 5; # maximum trying count to send. interval 20 sec; # maximum interval to resend. persend 1; # the number of packets per a send. # timer for waiting to complete each phase. phase1 30 sec; phase2 20 sec; } remote anonymous { exchange_mode main; doi ipsec_doi; situation identity_only; nonce_size 16; lifetime time 1 min; # sec,min,hour lifetime byte 5 MB; # B,KB,GB initial_contact on; support_mip6 on; proposal_check obey; # obey, strict or claim proposal { encryption_algorithm 3des; hash_algorithm sha1; authentication_method pre_shared_key ; dh_group 2; } } sainfo anonymous { # does not matter if 1 or 2, zero (expected by Win2K) won't parse. pfs_group 2; lifetime time 36000 sec; lifetime byte 50000 KB; encryption_algorithm 3des,des ; authentication_algorithm hmac_sha1,hmac_md5; compression_algorithm deflate ; } --------------2BB9B253F9FAFFDCA0F7B238-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jan 9 13:55:32 2001 Delivered-To: freebsd-net@freebsd.org Received: from virtual.sysadmin-inc.com (lists.sysadmin-inc.com [209.16.228.140]) by hub.freebsd.org (Postfix) with ESMTP id 0100337B404 for ; Tue, 9 Jan 2001 13:55:16 -0800 (PST) Received: from wkst ([209.16.228.146]) by virtual.sysadmin-inc.com (8.9.1/8.9.1) with SMTP id RAA31155 for ; Tue, 9 Jan 2001 17:00:56 -0500 Reply-To: From: "Peter Brezny" To: Subject: moving secondary name servers to primary Date: Tue, 9 Jan 2001 16:54:20 -0800 Message-ID: <003701c07a9f$de2db4e0$46010a0a@sysadmininc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Is there an easy way to convert a secondary bind8 name server to a primary? I had hoped to just be able to change the designation in the named.conf file from type slave to type master, however when i look at the individual zone files, they 've got a lot of mish mash in there from being secondary files. TIA Peter Brezny SysAdmin Services Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jan 9 14: 5:39 2001 Delivered-To: freebsd-net@freebsd.org Received: from krell.webweaver.net (krell.webweaver.net [64.124.90.11]) by hub.freebsd.org (Postfix) with ESMTP id 11FCA37B400 for ; Tue, 9 Jan 2001 14:05:20 -0800 (PST) Received: from xwin.nmhtech.com (xwin.daemontech.net [208.138.46.161]) by krell.webweaver.net (Postfix) with ESMTP id C40D820F12; Tue, 9 Jan 2001 14:04:33 -0800 (PST) Content-Length: 1360 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <003701c07a9f$de2db4e0$46010a0a@sysadmininc.com> Date: Tue, 09 Jan 2001 14:04:33 -0800 (PST) From: Nicole To: Peter Brezny Subject: RE: moving secondary name servers to primary Cc: freebsd-net@freebsd.org Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 10-Jan-01 Peter Brezny wrote: > Is there an easy way to convert a secondary bind8 name server to a primary? > > I had hoped to just be able to change the designation in the named.conf file > from type slave to type master, however when i look at the individual zone > files, they 've got a lot of mish mash in there from being secondary files. > > TIA > > Peter Brezny > SysAdmin Services Inc. > You should be able to use them just fine. They are esentually the same file as the primary except slightly machine generated. BTW I will most likley be giving a talk this Thursday at BABUG (www.babug.org) on Bind9 and DNS configuation. Nicole > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message nicole@unixgirl.com |\ __ /| (`\ http://www.unixgirl.com/ webmistress@dangermouse.org | o_o |__ ) ) http://www.dangermouse.org/ nicole@deviantimages.com // \\ http://www.deviantimages.com/ ---------------------------(((---(((---------------------------------------- -- Powered by Coka-Cola and FreeBSD -- -- I don't speak for anybody but myself - that's enough trouble -- -- Back Up My Hard Drive? I Can't Find The Reverse Switch! -- ------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jan 9 15:19:41 2001 Delivered-To: freebsd-net@freebsd.org Received: from rapidnet.com (rapidnet.com [205.164.216.1]) by hub.freebsd.org (Postfix) with ESMTP id C313537B401 for ; Tue, 9 Jan 2001 15:19:22 -0800 (PST) Received: from localhost (nick@localhost) by rapidnet.com (8.9.3/8.9.3) with ESMTP id QAA86049; Tue, 9 Jan 2001 16:19:19 -0700 (MST) Date: Tue, 9 Jan 2001 16:19:19 -0700 (MST) From: Nick Rogness To: Peter Brezny Cc: freebsd-net@freebsd.org Subject: Re: moving secondary name servers to primary In-Reply-To: <003701c07a9f$de2db4e0$46010a0a@sysadmininc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 9 Jan 2001, Peter Brezny wrote: > Is there an easy way to convert a secondary bind8 name server to a primary? > > I had hoped to just be able to change the designation in the named.conf file > from type slave to type master, however when i look at the individual zone > files, they 've got a lot of mish mash in there from being secondary files. Explain mish mash.. ;-) You must be refering to the SOA portion of the zone file? I've yet to see (or write) a tool that would do this conversion without pain, but I could put something together quick like. As far as the named.conf file, you should just be able to replace the slave line with type master and remove the excess stuff. This does become tedious when you have hundreds of entries in named.conf. I usually just search and replace, etc,etc the hard way. Maybe someone has a tool? Nick Rogness - Drive defensively. Buy a tank. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jan 9 15:52:29 2001 Delivered-To: freebsd-net@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id 57BBB37B400; Tue, 9 Jan 2001 15:52:10 -0800 (PST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id IAA05079; Wed, 10 Jan 2001 08:51:20 +0900 (JST) To: Jorge Peixoto Vasquez Cc: freebsd-net@freebsd.org, freebsd-security@freebsd.org In-reply-to: jorge's message of Tue, 09 Jan 2001 18:01:43 -0200. <3A5B6E27.5787D716@aker.com.br> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: IPSEC: racoon and Win2K From: itojun@iijlab.net Date: Wed, 10 Jan 2001 08:51:20 +0900 Message-ID: <5077.979084280@coconut.itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >The only problem I've encountered is that, when making Win2K and FreeBSD >interoperate, the IKE's phase 2 only suceeds if >Win2K initiates the process. If racoon is to start it, Win2k will not >accept any proposal for phase 2, complaining that the dh group number >(which should correctly be either 1 or 2) received is 1 or 2 (depending >on the pfs_group setting in racoon.conf) and not null(0). If I try >setting pfs_group to null, I get a parse error. try removing "pfs_group 2" line. the problem here is that PFS group is not negotiated (from the protocol spec), so - if Win2K uses no pfs group, racoon obeys - if racoon proposes either pfs group 1/2, Win2K rejects hope this helps. itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jan 9 17:12: 2 2001 Delivered-To: freebsd-net@freebsd.org Received: from henry.cs.adfa.edu.au (henry.cs.adfa.edu.au [131.236.21.158]) by hub.freebsd.org (Postfix) with ESMTP id 230AB37B401 for ; Tue, 9 Jan 2001 17:11:44 -0800 (PST) Received: (from wkt@localhost) by henry.cs.adfa.edu.au (8.11.1/8.9.3) id f0A1IFS27661 for freebsd-net@freebsd.org; Wed, 10 Jan 2001 12:18:15 +1100 (EST) (envelope-from wkt) From: Warren Toomey Message-Id: <200101100118.f0A1IFS27661@henry.cs.adfa.edu.au> Subject: D-link DFE530 problem in 4.2-STABLE? Help! To: freebsd-net@freebsd.org Date: Wed, 10 Jan 2001 12:18:15 +1100 (EST) Reply-To: wkt@cs.adfa.edu.au X-Mailer: ELM [version 2.4ME+ PL68 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm having problems getting throughout above 63Mbps with a 4.2_STABLE system and a D-link DFE530 Fast Ethernet card. I've put full details of the problem and the information I have up at http://minnie.cs.adfa.edu.au/Beowulf/Problem/ Would some kind soul have a look and see if they can spot anything? Thanks, Warren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jan 9 18:57:43 2001 Delivered-To: freebsd-net@freebsd.org Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (Postfix) with ESMTP id 2427637B401; Tue, 9 Jan 2001 18:57:22 -0800 (PST) Received: from imap.gv.tsc.tdk.com (imap.gv.tsc.tdk.com [192.168.241.198]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id SAA12818; Tue, 9 Jan 2001 18:57:05 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by imap.gv.tsc.tdk.com (8.9.3/8.9.3) with ESMTP id SAA21337; Tue, 9 Jan 2001 18:57:05 -0800 (PST) (envelope-from Don.Lewis@tsc.tdk.com) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id SAA19637; Tue, 9 Jan 2001 18:57:05 -0800 (PST) From: Don Lewis Message-Id: <200101100257.SAA19637@salsa.gv.tsc.tdk.com> Date: Tue, 9 Jan 2001 18:57:04 -0800 In-Reply-To: <3A5BC1D5.E5F57AE0@softweyr.com> References: <3A5BC1D5.E5F57AE0@softweyr.com> X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Wes Peters , Mike Silbersack Subject: Re: Spoofing multicast addresses Cc: Umesh Krishnaswamy , freebsd-security@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [ freebsd-net added ] On Jan 9, 6:58pm, Wes Peters wrote: } Subject: Re: Spoofing multicast addresses } Mike Silbersack wrote: } > } > The check is done when the SYN is received, hence such a situation as you } > describe should not be able to occur. } > } > >From tcp_input.c: } > } > /* } > * RFC1122 4.2.3.10, p. 104: discard bcast/mcast SYN } > * in_broadcast() should never return true on a received } > * packet with M_BCAST not set. } > * } > * Packets with a multicast source address should also } > * be discarded. } > */ } > if (m->m_flags & (M_BCAST|M_MCAST)) } > goto drop; There are some additional sanity checks that were omitted from this message. } The real problem is this check is 675 lines into tcp_input, but probably } should be at the top. I've just rescanned this and don't recall if m->m_flags } is set before tcp_input is called, or by one of the numerous functions called } in the code leading up to this check. The flags are set before tcp_input is called based on link level information. A good reason for putting these checks in their present location is that it gets them out of the main code path. Under normal circumstances, the vast majority of the incoming packets will be for established connections and it wasteful to do unnecessary checking on these packets. We need to do a PCB lookup for each incoming packet in any case, so if we never create a PCB containing any invalid addresses, then we only need the extra sanity checking on packets that don't have a matching PCB. Optimising the most frequently used code path leaves more CPU cycles available for the application. Now if someone floods the server with garbage packets, we'll expend more CPU cycles handling them than if the sanity check was done first, but there are likely to be spare CPU cycles available because the real clients won't be getting through the flood to exercise the application code. } The comment about discarding bcast/mcast SYN is misleading, there is NO } properly formatted TCP packet *to or from* a broadcast or multicast address. See what the RFC1122 4.2.3.10 says. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jan 9 23: 0:11 2001 Delivered-To: freebsd-net@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id B031037B400; Tue, 9 Jan 2001 22:59:38 -0800 (PST) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14GFKA-0000CK-00; Wed, 10 Jan 2001 00:05:34 -0700 Message-ID: <3A5C09BE.88B4A117@softweyr.com> Date: Wed, 10 Jan 2001 00:05:34 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Don Lewis Cc: Mike Silbersack , Umesh Krishnaswamy , freebsd-security@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Spoofing multicast addresses References: <3A5BC1D5.E5F57AE0@softweyr.com> <200101100257.SAA19637@salsa.gv.tsc.tdk.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Don Lewis wrote: > > [ freebsd-net added ] > > On Jan 9, 6:58pm, Wes Peters wrote: > } Subject: Re: Spoofing multicast addresses > } Mike Silbersack wrote: > } > > } > The check is done when the SYN is received, hence such a situation as you > } > describe should not be able to occur. > } > > } > >From tcp_input.c: > } > > } > /* > } > * RFC1122 4.2.3.10, p. 104: discard bcast/mcast SYN > } > * in_broadcast() should never return true on a received > } > * packet with M_BCAST not set. > } > * > } > * Packets with a multicast source address should also > } > * be discarded. > } > */ > } > if (m->m_flags & (M_BCAST|M_MCAST)) > } > goto drop; > > There are some additional sanity checks that were omitted from this message. > > } The real problem is this check is 675 lines into tcp_input, but probably > } should be at the top. I've just rescanned this and don't recall if m->m_flags > } is set before tcp_input is called, or by one of the numerous functions called > } in the code leading up to this check. > > The flags are set before tcp_input is called based on link level > information. > > A good reason for putting these checks in their present location is > that it gets them out of the main code path. Under normal circumstances, > the vast majority of the incoming packets will be for established > connections and it wasteful to do unnecessary checking on these packets. But that is exactly NOT the case when being attacked with a SYN flood or something like that. Perhaps it would be advantageous to trip a flag if we hit the bandwidth limiting rate and do the checks much earlier only if we're under attack? > We need to do a PCB lookup for each incoming packet in any case, so if You certainly don't NEED to do a PCB lookup for a TCP packet with a {broad,multi}cast address, ever. > we never create a PCB containing any invalid addresses, then we only > need the extra sanity checking on packets that don't have a matching PCB. > Optimising the most frequently used code path leaves more CPU cycles > available for the application. > > Now if someone floods the server with garbage packets, we'll expend > more CPU cycles handling them than if the sanity check was done first, > but there are likely to be spare CPU cycles available because the > real clients won't be getting through the flood to exercise the application > code. The real problem with the "stream" attack was not the volume of incoming SYN packets, but the reflector nature of the attack when using forged multicast source addresses. The code did not correctly "ignore" these packets, and replied with RST. Since no current group membership was available for the multicast source address, the system forwarded the RST packet to all attached interfaces. Augh! What do you think of my suggestion above, to shift into "flood avoidance mode" when rate limits are hit on either RST or drop? That has some potential for nearly best of both worlds performance, as long as the rate limit threshold is adjusted carefully. You'd want to tune the setting to avoid flapping the mode flag on and off. > } The comment about discarding bcast/mcast SYN is misleading, there is NO > } properly formatted TCP packet *to or from* a broadcast or multicast address. > > See what the RFC1122 4.2.3.10 says. It says exactly what I said, in more formal language, but is typically a little vague as to what to do about it. The second paragraph, "...or by the IP layer..." gives a hint as to the appropriate place to really check for this class of errors. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jan 9 23:13:36 2001 Delivered-To: freebsd-net@freebsd.org Received: from silby.com (cb34181-c.mdsn1.wi.home.com [24.183.3.139]) by hub.freebsd.org (Postfix) with ESMTP id 2C63F37B402 for ; Tue, 9 Jan 2001 23:13:18 -0800 (PST) Received: (qmail 13712 invoked by uid 1000); 10 Jan 2001 07:13:17 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 10 Jan 2001 07:13:17 -0000 Date: Wed, 10 Jan 2001 01:13:17 -0600 (CST) From: Mike Silbersack To: Wes Peters Cc: Don Lewis , Umesh Krishnaswamy , , Subject: Re: Spoofing multicast addresses In-Reply-To: <3A5C09BE.88B4A117@softweyr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 10 Jan 2001, Wes Peters wrote: > Don Lewis wrote: > > A good reason for putting these checks in their present location is > > that it gets them out of the main code path. Under normal circumstances, > > the vast majority of the incoming packets will be for established > > connections and it wasteful to do unnecessary checking on these packets. > > But that is exactly NOT the case when being attacked with a SYN flood > or something like that. Perhaps it would be advantageous to trip a flag > if we hit the bandwidth limiting rate and do the checks much earlier only > if we're under attack? I'm not sure that really matters. Since (nearly) any packet will undergo the pcb lookup, reducing the overhead of multicast packets wouldn't make much difference - attackers can just use non-multicast packets. Does anyone have an idea on what the performance impact of the multicast checks really is? Just having a single check at the top of the code would be nice from a readability standpoint. Speaking of stream, I wonder if proper multicast checks are done for icmp responses. Hrm. 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 Tue Jan 9 23:45:51 2001 Delivered-To: freebsd-net@freebsd.org Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (Postfix) with ESMTP id A1F1437B400; Tue, 9 Jan 2001 23:45:30 -0800 (PST) Received: from imap.gv.tsc.tdk.com (imap.gv.tsc.tdk.com [192.168.241.198]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id XAA17344; Tue, 9 Jan 2001 23:45:20 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by imap.gv.tsc.tdk.com (8.9.3/8.9.3) with ESMTP id XAA22463; Tue, 9 Jan 2001 23:45:20 -0800 (PST) (envelope-from Don.Lewis@tsc.tdk.com) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id XAA20130; Tue, 9 Jan 2001 23:45:19 -0800 (PST) From: Don Lewis Message-Id: <200101100745.XAA20130@salsa.gv.tsc.tdk.com> Date: Tue, 9 Jan 2001 23:45:19 -0800 In-Reply-To: References: X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Mike Silbersack , Wes Peters Subject: Re: Spoofing multicast addresses Cc: Don Lewis , Umesh Krishnaswamy , , Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Jan 10, 1:13am, Mike Silbersack wrote: } Subject: Re: Spoofing multicast addresses } } On Wed, 10 Jan 2001, Wes Peters wrote: } } > Don Lewis wrote: } > > A good reason for putting these checks in their present location is } > > that it gets them out of the main code path. Under normal circumstances, } > > the vast majority of the incoming packets will be for established } > > connections and it wasteful to do unnecessary checking on these packets. } > } > But that is exactly NOT the case when being attacked with a SYN flood } > or something like that. Perhaps it would be advantageous to trip a flag } > if we hit the bandwidth limiting rate and do the checks much earlier only } > if we're under attack? } } I'm not sure that really matters. Since (nearly) any packet will undergo } the pcb lookup, reducing the overhead of multicast packets wouldn't make } much difference - attackers can just use non-multicast packets. Yup, if we're DoSed in one of these attacks because of the expense of doing the PCB lookup before the source address check, then the attacker just has to craft the packets so that they pass the filters. I don't think an adaptive algorithm would be the way to go either. It's just more code that the CPU would have to run and an attacker might be able to keep things in the non-optimal state by varying the packet stream. } Does anyone have an idea on what the performance impact of the multicast } checks really is? Just having a single check at the top of the code would } be nice from a readability standpoint. The current checks are reasonably cheap, though I would really like to add a check of the source address against the broadcast addresses of each interface on the box. That could be quite a bit more expensive. } Speaking of stream, I wonder if proper multicast checks are done for icmp } responses. Hrm. I'm pretty sure that UDP is handled OK, but it can't hurt to take another look. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jan 10 0: 0:15 2001 Delivered-To: freebsd-net@freebsd.org Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (Postfix) with ESMTP id 7FC5137B401; Tue, 9 Jan 2001 23:59:53 -0800 (PST) Received: from imap.gv.tsc.tdk.com (imap.gv.tsc.tdk.com [192.168.241.198]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id XAA17472; Tue, 9 Jan 2001 23:59:06 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by imap.gv.tsc.tdk.com (8.9.3/8.9.3) with ESMTP id XAA22486; Tue, 9 Jan 2001 23:59:03 -0800 (PST) (envelope-from Don.Lewis@tsc.tdk.com) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id XAA20147; Tue, 9 Jan 2001 23:59:02 -0800 (PST) From: Don Lewis Message-Id: <200101100759.XAA20147@salsa.gv.tsc.tdk.com> Date: Tue, 9 Jan 2001 23:59:02 -0800 In-Reply-To: <3A5C09BE.88B4A117@softweyr.com> References: <3A5BC1D5.E5F57AE0@softweyr.com> <200101100257.SAA19637@salsa.gv.tsc.tdk.com> <3A5C09BE.88B4A117@softweyr.com> X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Wes Peters , Don Lewis Subject: Re: Spoofing multicast addresses Cc: Mike Silbersack , Umesh Krishnaswamy , freebsd-security@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Jan 10, 12:05am, Wes Peters wrote: } Subject: Re: Spoofing multicast addresses } The real problem with the "stream" attack was not the volume of incoming } SYN packets, but the reflector nature of the attack when using forged } multicast source addresses. The code did not correctly "ignore" these } packets, and replied with RST. Since no current group membership was } available for the multicast source address, the system forwarded the RST } packet to all attached interfaces. Augh! I'm actually not sure what the killer problem was. I'm pretty sure that systems with only one interface were vulnerable, so spewing mulitcast RST packets out this interface shouldn't be much worse than spewing unicast RST packets, unless I'm missing something particularly expensive in the multicast code, which I admit that I'm not at all familiar with. If I had to speculate, I'd guess that it might have something to do with the multicast packets reentering the stack through the loopback interface or maybe incoming responses to the multicast spew from other hosts on the local network. Since we added the packet sanity checks and the RST response rate limiting at the same time, we really don't know which if these helped the most. I suppose this could be an interesting experiment for someone with some spare time on their hands. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jan 10 1: 4:26 2001 Delivered-To: freebsd-net@hub.freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id B0E1237B401; Wed, 10 Jan 2001 01:04:06 -0800 (PST) Received: (from jkoshy@localhost) by freefall.freebsd.org (8.11.1/8.11.1) id f0A946A21527; Wed, 10 Jan 2001 01:04:06 -0800 (PST) (envelope-from jkoshy) Date: Wed, 10 Jan 2001 01:04:06 -0800 (PST) From: Message-Id: <200101100904.f0A946A21527@freefall.freebsd.org> X-Mailer: exmh version 2.0.2 2/24/98 To: freebsd-advocacy@FreeBSD.org Cc: freebsd-net@FreeBSD.org, jkoshy@FreeBSD.org, jkh@FreeBSD.org, itojun@iijlab.net Subject: Slides for FreeBSD/IPv6 presentation available Mime-Version: 1.0 Content-Type: text/plain Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Folks, I have put up some slides that I presented at the recent "Global IPv6 Summit" in Bangalore, under http://people.freebsd.org/~jkoshy/articles/ipv6-presentation/ The topic of my talk was `IPv6 in FreeBSD'. The talk started off with an introduction to FreeBSD, went into the details of IPv6 support in FreeBSD, and ended with a demonstration of IPv6 in action. The web page referenced above also has some notes about what went well during the talk. This may be of use to people interested in advocacy. The presentation is being made available in LaTeX and PDF forms. Thanks to for pointing me to KAME related information. Regards, Koshy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jan 10 1:49: 9 2001 Delivered-To: freebsd-net@freebsd.org Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (Postfix) with ESMTP id 2FB4337B400 for ; Wed, 10 Jan 2001 01:48:51 -0800 (PST) Received: from imap.gv.tsc.tdk.com (imap.gv.tsc.tdk.com [192.168.241.198]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id BAA18702; Wed, 10 Jan 2001 01:48:48 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by imap.gv.tsc.tdk.com (8.9.3/8.9.3) with ESMTP id BAA23165; Wed, 10 Jan 2001 01:48:47 -0800 (PST) (envelope-from Don.Lewis@tsc.tdk.com) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id BAA20498; Wed, 10 Jan 2001 01:48:46 -0800 (PST) From: Don Lewis Message-Id: <200101100948.BAA20498@salsa.gv.tsc.tdk.com> Date: Wed, 10 Jan 2001 01:48:46 -0800 In-Reply-To: <20010109181609.B10100@skriver.dk> References: <20001218182600.C1856@skriver.dk> <20001219222730.A29741@skriver.dk> <200012201046.CAA19456@salsa.gv.tsc.tdk.com> <20001220155118.N81814@skriver.dk> <20001231210746.A81834@skriver.dk> <200101090702.XAA15712@salsa.gv.tsc.tdk.com> <20010109181609.B10100@skriver.dk> X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Jesper Skriver , Don Lewis Subject: Re: ICMP error processing (was: Re: what to do now ? Was: cvs commit: src/sys/netinet ip_icmp.c tcp_subr.c tcp_var.h) Cc: freebsd-net@FreeBSD.ORG Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Jan 9, 6:16pm, Jesper Skriver wrote: } Subject: Re: ICMP error processing (was: Re: what to do now ? Was: cvs co } On Mon, Jan 08, 2001 at 11:02:17PM -0800, Don Lewis wrote: } > In the current code, it looks like an ICMP error that the addresses } > and ports zeroed out will erroneously affect many sessions (what do } > the RFCs say?). } } rfc793 doesn't mention any specific range for port numbers apart form } being a 16 bit number, but it does say explicitly (in section 3.3) that } the sequence number is a range from 0 to 2**32 - 1 } } If the port numbers and/or addresses are zero we affect many (or even all) } sessions, I don't have anything near a full overview of the kernel, so I } don't know if there is any check anywhere else for zero in those addresses } and/or port numbers. There's none that I'm aware of. We just blindly copy whatever is in the payload of the ICMP error packet and feed that to in_pcbnotify(). If the data happens to be zero, then in_pcbnotify() treats it as a wildcard. } > Another bit of strangeness is pfctlinput(PRC_IF{UP,DOWN}, ...) which } > is passed the interface address, which is matched against the } > *destination* address in the TCP and UDP PCBs. Fortunately these } > protocols seem to ignore these commands ... } } As I see this we need a new function to do the same just for the source } address in TCP and UDP PCBs, right ? Or an API change to the wildcard version of PCB lookup allows the destination address to be wildcarded. The PRC_IF{UP,DOWN} handlers in the raw IP stack would need to be tweaked to compensate, and we'd need to sweep the source for other pieces of code that might be affected. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jan 10 2:58:24 2001 Delivered-To: freebsd-net@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 8404737B402; Wed, 10 Jan 2001 02:58:02 -0800 (PST) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 10 Jan 2001 10:57:37 +0000 (GMT) To: freebsd-net@freebsd.org Cc: netch@segfault.kiev.ua, green@freebsd.org, dwmalone@maths.tcd.ie Subject: PR 21998 - outgoing ident. Date: Wed, 10 Jan 2001 10:57:36 +0000 From: David Malone Message-ID: <200101101057.aa49553@salmon.maths.tcd.ie> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In light of the chat on bugtraq about using ident services "backwards" to find out who daemons are running as, I had a look at PR 21998: http://www.FreeBSD.org/cgi/query-pr.cgi?pr=21998 I've read through and tested the patch, and is seems like a reasonable idea. Basically, it adds a flag to sockets which have been created via an accept() and then adds a new getcred_outgoing sysctl which works just like getcred but returns EPERM it is not a outgoing socket. I've run the patch by Brian Feldman, who has no objections, but suggested that I check the socket changes with people on freebsd-net. The patch below is an slightly updated version of that in the PR. David. Index: src/sys/kern/uipc_socket2.c =================================================================== RCS file: /cvs/FreeBSD-CVS/src/sys/kern/uipc_socket2.c,v retrieving revision 1.66 diff -u -r1.66 uipc_socket2.c --- src/sys/kern/uipc_socket2.c 2000/11/19 22:22:47 1.66 +++ src/sys/kern/uipc_socket2.c 2001/01/09 22:19:57 @@ -235,7 +236,7 @@ so->so_type = head->so_type; so->so_options = head->so_options &~ SO_ACCEPTCONN; so->so_linger = head->so_linger; - so->so_state = head->so_state | SS_NOFDREF; + so->so_state = head->so_state | SS_NOFDREF | SS_ISACCEPTED; so->so_proto = head->so_proto; so->so_timeo = head->so_timeo; so->so_cred = p ? p->p_ucred : head->so_cred; Index: src/sys/netinet/tcp_subr.c =================================================================== RCS file: /cvs/FreeBSD-CVS/src/sys/netinet/tcp_subr.c,v retrieving revision 1.86 diff -u -r1.86 tcp_subr.c --- src/sys/netinet/tcp_subr.c 2000/12/24 10:57:21 1.86 +++ src/sys/netinet/tcp_subr.c 2001/01/09 22:19:57 @@ -891,7 +891,9 @@ tcp_pcblist, "S,xtcpcb", "List of active TCP connections"); static int -tcp_getcred(SYSCTL_HANDLER_ARGS) +tcp_getcred_common(req, all) + struct sysctl_req *req; + int all; { struct sockaddr_in addrs[2]; struct inpcb *inp; @@ -910,18 +912,41 @@ error = ENOENT; goto out; } + if (!all && (inp->inp_socket->so_state & SS_ISACCEPTED)) { + error = EPERM; + goto out; + } error = SYSCTL_OUT(req, inp->inp_socket->so_cred, sizeof(struct ucred)); out: splx(s); return (error); } +static int +tcp_getcred_outgoing(SYSCTL_HANDLER_ARGS) +{ + return tcp_getcred_common(req, 0); +} + +SYSCTL_PROC(_net_inet_tcp, OID_AUTO, getcred_outgoing, + CTLTYPE_OPAQUE|CTLFLAG_RW, + 0, 0, tcp_getcred_outgoing, "S,ucred", + "Get the ucred of a TCP connection (outgoing connections only)"); + +static int +tcp_getcred_any(SYSCTL_HANDLER_ARGS) +{ + return tcp_getcred_common(req, 1); +} + SYSCTL_PROC(_net_inet_tcp, OID_AUTO, getcred, CTLTYPE_OPAQUE|CTLFLAG_RW, - 0, 0, tcp_getcred, "S,ucred", "Get the ucred of a TCP connection"); + 0, 0, tcp_getcred_any, "S,ucred", "Get the ucred of a TCP connection"); #ifdef INET6 static int -tcp6_getcred(SYSCTL_HANDLER_ARGS) +tcp6_getcred_common(req, all) + struct sysctl_req *req; + int all; { struct sockaddr_in6 addrs[2]; struct inpcb *inp; @@ -956,6 +981,10 @@ error = ENOENT; goto out; } + if (!all && (inp->inp_socket->so_state & SS_ISACCEPTED)) { + error = EPERM; + goto out; + } error = SYSCTL_OUT(req, inp->inp_socket->so_cred, sizeof(struct ucred)); out: @@ -963,9 +992,27 @@ return (error); } +static int +tcp6_getcred_outgoing(SYSCTL_HANDLER_ARGS) +{ + return tcp6_getcred_common(req, 0); +} + +SYSCTL_PROC(_net_inet6_tcp6, OID_AUTO, getcred_outgoing, + CTLTYPE_OPAQUE|CTLFLAG_RW, + 0, 0, + tcp6_getcred_outgoing, "S,ucred", + "Get the ucred of a TCP6 connection (outgoing only)"); + +static int +tcp6_getcred_any(SYSCTL_HANDLER_ARGS) +{ + return tcp6_getcred_common(req, 1); +} + SYSCTL_PROC(_net_inet6_tcp6, OID_AUTO, getcred, CTLTYPE_OPAQUE|CTLFLAG_RW, 0, 0, - tcp6_getcred, "S,ucred", "Get the ucred of a TCP6 connection"); + tcp6_getcred_any, "S,ucred", "Get the ucred of a TCP6 connection"); #endif Index: src/sys/sys/socketvar.h =================================================================== RCS file: /cvs/FreeBSD-CVS/src/sys/sys/socketvar.h,v retrieving revision 1.54 diff -u -r1.54 socketvar.h --- src/sys/sys/socketvar.h 2000/12/31 10:23:24 1.54 +++ src/sys/sys/socketvar.h 2001/01/09 22:19:57 @@ -131,6 +131,7 @@ #define SS_CANTSENDMORE 0x0010 /* can't send more data to peer */ #define SS_CANTRCVMORE 0x0020 /* can't receive more data from peer */ #define SS_RCVATMARK 0x0040 /* at mark on input */ +#define SS_ISACCEPTED 0x0080 /* obtained from accept() */ #define SS_NBIO 0x0100 /* non-blocking ops */ #define SS_ASYNC 0x0200 /* async i/o notify */ Index: src/usr.sbin/inetd/builtins.c =================================================================== RCS file: /cvs/FreeBSD-CVS/src/usr.sbin/inetd/builtins.c,v retrieving revision 1.29 diff -u -r1.29 builtins.c --- src/usr.sbin/inetd/builtins.c 2000/12/05 13:56:01 1.29 +++ src/usr.sbin/inetd/builtins.c 2001/01/09 22:53:03 @@ -351,7 +351,7 @@ ssize_t ssize; size_t size, bufsiz; int c, fflag = 0, nflag = 0, rflag = 0, argc = 0, usedfallback = 0; - int gflag = 0, Fflag = 0, getcredfail = 0, onreadlen; + int aflag = 0, gflag = 0, Fflag = 0, getcredfail = 0, onreadlen; u_short lport, fport; inetd_setproctitle(sep->se_service, s); @@ -373,8 +373,11 @@ size_t i; u_int32_t random; - while ((c = getopt(argc, sep->se_argv, "d:fFgno:rt:")) != -1) + while ((c = getopt(argc, sep->se_argv, "ad:fFgno:rt:")) != -1) switch (c) { + case 'a': + aflag = 1; + break; case 'd': fallback = optarg; break; @@ -530,7 +533,9 @@ sin[0].sin_port = htons(lport); sin[1] = *(struct sockaddr_in *)&ss[1]; sin[1].sin_port = htons(fport); - if (sysctlbyname("net.inet.tcp.getcred", &uc, &size, sin, + if (sysctlbyname(aflag ? "net.inet.tcp.getcred" : + "net.inet.tcp.getcred_outgoing", + &uc, &size, sin, sizeof(sin)) == -1) getcredfail = errno; break; @@ -540,7 +545,9 @@ sin6[0].sin6_port = htons(lport); sin6[1] = *(struct sockaddr_in6 *)&ss[1]; sin6[1].sin6_port = htons(fport); - if (sysctlbyname("net.inet6.tcp6.getcred", &uc, &size, sin6, + if (sysctlbyname(aflag ? "net.inet6.tcp6.getcred" : + "net.inet6.tcp6.getcred_outgoing", + &uc, &size, sin6, sizeof(sin6)) == -1) getcredfail = errno; break; Index: src/usr.sbin/inetd/inetd.8 =================================================================== RCS file: /cvs/FreeBSD-CVS/src/usr.sbin/inetd/inetd.8,v retrieving revision 1.55 diff -u -r1.55 inetd.8 --- src/usr.sbin/inetd/inetd.8 2000/12/27 15:30:04 1.55 +++ src/usr.sbin/inetd/inetd.8 2001/01/09 22:29:21 @@ -438,6 +438,9 @@ .Dq ERROR\ : HIDDEN-USER . The available arguments to this service that alter its behavior are: .Bl -tag -width indent +.It Fl a +By default, ident only provides information for outgoing connections. +This flag causes information to be provided for all connections. .It Fl d Ar fallback Provide a .Ar fallback To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jan 10 3:58: 2 2001 Delivered-To: freebsd-net@freebsd.org Received: from hq1.tyfon.net (hq1.tyfon.net [217.27.162.35]) by hub.freebsd.org (Postfix) with ESMTP id 944F237B402 for ; Wed, 10 Jan 2001 03:57:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hq1.tyfon.net (Postfix) with ESMTP id 877BC1C7DA for ; Wed, 10 Jan 2001 12:57:42 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by hq1.tyfon.net (Postfix) with ESMTP id 92BD51C5C9 for ; Wed, 10 Jan 2001 12:57:39 +0100 (CET) Date: Wed, 10 Jan 2001 12:57:39 +0100 (CET) From: Dan Larsson To: Subject: mpd concurrent pptp connections. Message-ID: Organization: Tyfon Svenska AB X-NCC-NIC: DL1999-RIPE X-NCC-RegID: se.tyfon MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by hq1.tyfon.net Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I need to be able to handle 30 concurrent pptp sessions on one machine. but I only get 10 netgraph interfaces when doing a 'ifconfig -a | grep ^ng'. Do I need to make any changes to my kernel? (I'm using FreeBSD-4.1.1-STABLE with netgraph as a kld). Regards +------ Dan Larsson | Tel: +46 8 550 120 21 Tyfon Svenska AB | Fax: +46 8 550 120 02 GPG and PGP keys | finger dl@hq1.tyfon.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jan 10 8:19:51 2001 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 69FA937B400 for ; Wed, 10 Jan 2001 08:19:32 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id LAA34225; Wed, 10 Jan 2001 11:19:18 -0500 (EST) (envelope-from wollman) Date: Wed, 10 Jan 2001 11:19:18 -0500 (EST) From: Garrett Wollman Message-Id: <200101101619.LAA34225@khavrinen.lcs.mit.edu> To: David Malone Cc: freebsd-net@FreeBSD.ORG Subject: PR 21998 - outgoing ident. In-Reply-To: <200101101057.aa49553@salmon.maths.tcd.ie> References: <200101101057.aa49553@salmon.maths.tcd.ie> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > I've read through and tested the patch, and is seems like a reasonable > idea. Basically, it adds a flag to sockets which have been created > via an accept() and then adds a new getcred_outgoing sysctl which > works just like getcred but returns EPERM it is not a outgoing > socket. I think this is the wrong way around. There is enough information in the PCB dump for identd to determine whether the socket was active- or passive-open; identd should do the work itself. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jan 10 8:41:47 2001 Delivered-To: freebsd-net@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id CBA6A37B402 for ; Wed, 10 Jan 2001 08:41:28 -0800 (PST) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 10 Jan 2001 16:41:27 +0000 (GMT) To: Garrett Wollman Cc: freebsd-net@FreeBSD.ORG Subject: Re: PR 21998 - outgoing ident. In-reply-to: Your message of "Wed, 10 Jan 2001 11:19:18 EST." <200101101619.LAA34225@khavrinen.lcs.mit.edu> X-Request-Do: Date: Wed, 10 Jan 2001 16:41:27 +0000 From: David Malone Message-ID: <200101101641.aa18613@salmon.maths.tcd.ie> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > I've read through and tested the patch, and is seems like a reasonable > > idea. Basically, it adds a flag to sockets which have been created > > via an accept() and then adds a new getcred_outgoing sysctl which > > works just like getcred but returns EPERM it is not a outgoing > > socket. > I think this is the wrong way around. There is enough information in > the PCB dump for identd to determine whether the socket was active- or > passive-open; identd should do the work itself. I presume you mean that getcred_outgoing should do the work itself rather than having identd grovel around in the kernel itself? Can you point me at the field(s) in inpcb I should be looking at? David. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jan 10 21:42:31 2001 Delivered-To: freebsd-net@freebsd.org Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by hub.freebsd.org (Postfix) with ESMTP id 7FEF337B400 for ; Wed, 10 Jan 2001 21:42:13 -0800 (PST) Received: from chimp.simianscience.com (cage.simianscience.com [64.7.134.1]) by smtp1.sentex.ca (8.11.1/8.11.1) with SMTP id f0B5gCG97478; Thu, 11 Jan 2001 00:42:12 -0500 (EST) (envelope-from mike@sentex.net) From: Mike Tancsa To: freebsd-net@freebsd.org Cc: nicole@unixgirl.com Subject: Re: Problem with fxp0 card and slowing/dying transmits Date: Thu, 11 Jan 2001 00:42:12 -0500 Message-ID: References: In-Reply-To: X-Mailer: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 5 Jan 2001 03:49:25 -0500, in sentex.lists.freebsd.net you wrote: > Yup.... Set to 100/TX via ifconfig -=20 > >Ifconfig -a shows: >fxp0: flags=3D8843 mtu 1500 >media: 100baseTX status: active > supported media: autoselect 100baseTX 100baseTX >10baseT/UTP 10baseT/UTP > > The switch is showing: 100Mbps/Half/BP-Off > > =20 > As opposed to another server on the same switch, set to auto. > >ifconfig -a >media: autoselect (100baseTX ) status: active > supported media: autoselect 100baseTX 100baseTX >10baseT/UTP 10baseT/UTP > > The switch shows: 100Mbps/Full/Enabled (IEEE 802.3x) > > > Hmm Even if I force the switch to full duplex it does not seem to = change the >server to full duplex when using autonegotiate via ifconfig.. What is = the >right syntax to force full neg via ifconfig? ifconfig fxp0 autoselect However, with some switches, its a waste of time. Best to set things manually on both ends if you can. ifconfig fxp0 media 100baseTX mediaopt full-duplex netstat -ni and=20 netstat -s will show duplex mismatches typically on input errors. ---Mike Mike Tancsa (mdtancsa@sentex.net) =09 Sentex Communications Corp, =09 Waterloo, Ontario, Canada "Given enough time, 100 monkeys on 100 routers=20 could setup a national IP network." (KDW2) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jan 11 0: 3:10 2001 Delivered-To: freebsd-net@freebsd.org Received: from matrix.csah.com (matrix.csah.com [203.127.178.1]) by hub.freebsd.org (Postfix) with ESMTP id 5146137B69F for ; Thu, 11 Jan 2001 00:02:51 -0800 (PST) Received: from capl.csah.com (capl [203.127.178.2]) by matrix.csah.com (8.9.3/8.9.3) with ESMTP id QAA15395 for ; Thu, 11 Jan 2001 16:06:01 +0800 (SGT) Received: from csah.com ([203.127.179.73]) by capl.csah.com (8.9.3/8.9.3) with ESMTP id QAA24534 for ; Thu, 11 Jan 2001 16:18:05 +0800 (SGT) Message-ID: <3A5D6B72.1ED09857@csah.com> Date: Thu, 11 Jan 2001 16:14:42 +0800 From: Fook Sheng X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net Subject: compile error - something wrong with ip_icmp.h?? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi I got these errors when I include #include In file included from rs.c:5: /usr/include/netinet/ip_icmp.h:64: syntax error before `n_short' /usr/include/netinet/ip_icmp.h:71: syntax error before `n_short' /usr/include/netinet/ip_icmp.h:93: syntax error before `n_time' /usr/include/netinet/ip_icmp.h:98: field `idi_ip' has incomplete type Is there any problems with ip_icmp.h?? i'm running FBSD 4.0 fs To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jan 11 0: 4:50 2001 Delivered-To: freebsd-net@freebsd.org Received: from elvis.mu.org (elvis.mu.org [207.154.226.10]) by hub.freebsd.org (Postfix) with ESMTP id D44D237B69F for ; Thu, 11 Jan 2001 00:04:33 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1098) id A81E82B228; Thu, 11 Jan 2001 02:04:19 -0600 (CST) Date: Thu, 11 Jan 2001 02:04:19 -0600 From: Bill Fumerola To: Fook Sheng Cc: freebsd-net Subject: Re: compile error - something wrong with ip_icmp.h?? Message-ID: <20010111020419.H35827@elvis.mu.org> References: <3A5D6B72.1ED09857@csah.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A5D6B72.1ED09857@csah.com>; from fschan@csah.com on Thu, Jan 11, 2001 at 04:14:42PM +0800 X-Operating-System: FreeBSD 4.2-FEARSOME-20001103 i386 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Jan 11, 2001 at 04:14:42PM +0800, Fook Sheng wrote: > Hi > > I got these errors when I include #include > > In file included from rs.c:5: > /usr/include/netinet/ip_icmp.h:64: syntax error before `n_short' > /usr/include/netinet/ip_icmp.h:71: syntax error before `n_short' > /usr/include/netinet/ip_icmp.h:93: syntax error before `n_time' > /usr/include/netinet/ip_icmp.h:98: field `idi_ip' has incomplete type > > Is there any problems with ip_icmp.h?? > > i'm running FBSD 4.0 man inet -- Bill Fumerola - security yahoo / Yahoo! inc. - fumerola@yahoo-inc.com / billf@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jan 11 0:41:56 2001 Delivered-To: freebsd-net@freebsd.org Received: from matrix.csah.com (matrix.csah.com [203.127.178.1]) by hub.freebsd.org (Postfix) with ESMTP id 5C0B737B400 for ; Thu, 11 Jan 2001 00:41:36 -0800 (PST) Received: from capl.csah.com (capl [203.127.178.2]) by matrix.csah.com (8.9.3/8.9.3) with ESMTP id QAA16086 for ; Thu, 11 Jan 2001 16:44:52 +0800 (SGT) Received: from csah.com ([203.127.179.73]) by capl.csah.com (8.9.3/8.9.3) with ESMTP id QAA05134 for ; Thu, 11 Jan 2001 16:56:56 +0800 (SGT) Message-ID: <3A5D748E.4C61C960@csah.com> Date: Thu, 11 Jan 2001 16:53:34 +0800 From: Fook Sheng X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 Cc: freebsd-net Subject: socket programming on FreeBSD - any references ?? References: <3A5D6B72.1ED09857@csah.com> <20010111020419.H35827@elvis.mu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi I am learning sockets programming , especially raw sockets. I rely on TCP Illustrated 123 and unix network programming. will those examples on these books work on FreeBSD?? I'm getting some funny errors when compiling my codes fs To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jan 11 0:45:50 2001 Delivered-To: freebsd-net@freebsd.org Received: from elvis.mu.org (elvis.mu.org [207.154.226.10]) by hub.freebsd.org (Postfix) with ESMTP id DE52D37B400 for ; Thu, 11 Jan 2001 00:45:33 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1098) id 5A6152B2BE; Thu, 11 Jan 2001 02:45:33 -0600 (CST) Date: Thu, 11 Jan 2001 02:45:33 -0600 From: Bill Fumerola To: Fook Sheng Cc: freebsd-net Subject: Re: socket programming on FreeBSD - any references ?? Message-ID: <20010111024533.I35827@elvis.mu.org> References: <3A5D6B72.1ED09857@csah.com> <20010111020419.H35827@elvis.mu.org> <3A5D748E.4C61C960@csah.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A5D748E.4C61C960@csah.com>; from fschan@csah.com on Thu, Jan 11, 2001 at 04:53:34PM +0800 X-Operating-System: FreeBSD 4.2-FEARSOME-20001103 i386 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Jan 11, 2001 at 04:53:34PM +0800, Fook Sheng wrote: > Hi > > I am learning sockets programming , especially raw sockets. I rely on TCP > Illustrated 123 and unix network programming. > > will those examples on these books work on FreeBSD?? > > I'm getting some funny errors when compiling my codes okay, since you didn't catch what I said in my previous email: INET(3) FreeBSD Library Functions Manual INET(3) [..] SYNOPSIS #include #include #include #include there are other files that you may have to include as well. UNP and the other stevens books use libunp.h or something similar that include all the required files for you. please stop skimming and read, the book is very explicit on how to compile. -- Bill Fumerola - security yahoo / Yahoo! inc. - fumerola@yahoo-inc.com / billf@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jan 11 3:50:49 2001 Delivered-To: freebsd-net@freebsd.org Received: from aker.com.br (unknown [200.252.12.5]) by hub.freebsd.org (Postfix) with ESMTP id 115F837B698; Thu, 11 Jan 2001 03:50:25 -0800 (PST) Received: from aker.com.br (jorge.aker.com.br [10.0.0.16]) by aker.com.br (8.9.3/8.9.3) with ESMTP id IAA05339; Thu, 11 Jan 2001 08:34:38 -0200 (BRST) (envelope-from jorge@aker.com.br) Message-ID: <3A5CD61C.673C1B83@aker.com.br> Date: Wed, 10 Jan 2001 19:37:32 -0200 From: Jorge Peixoto Vasquez Organization: Aker Security Solutions X-Mailer: Mozilla 4.73 [en] (X11; I; FreeBSD 4.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@freebsd.org, freebsd-security@freebsd.org Subject: Re: IPSEC: racoon and Win2K References: <5077.979084280@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org itojun@iijlab.net wrote: > > >The only problem I've encountered is that, when making Win2K and FreeBSD > >interoperate, the IKE's phase 2 only suceeds if > >Win2K initiates the process. If racoon is to start it, Win2k will not > >accept any proposal for phase 2, complaining that the dh group number > >(which should correctly be either 1 or 2) received is 1 or 2 (depending > >on the pfs_group setting in racoon.conf) and not null(0). If I try > >setting pfs_group to null, I get a parse error. > > try removing "pfs_group 2" line. the problem here is that PFS group > is not negotiated (from the protocol spec), so > - if Win2K uses no pfs group, racoon obeys > - if racoon proposes either pfs group 1/2, Win2K rejects > hope this helps. > I had already done it, but it acts exactly the same way as it does if I put "pfs_group 2" or "pfs_group modp1024", i.e. sends '2' to Win2K. Anyone was successfull in making these interoperate? Could you please tell me which racoon version you used and please send me the conf file? Thanx anyways, jOrge -- Jorge Peixoto Vasquez, Elet. Eng. Aker Security Solutions tel. +55 - 61 - 340 9083 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jan 11 17:16:55 2001 Delivered-To: freebsd-net@freebsd.org Received: from worldclass.jolt.nu (lgh637b.hn-krukan.AC [212.217.139.112]) by hub.freebsd.org (Postfix) with ESMTP id AA7C337B402 for ; Thu, 11 Jan 2001 17:16:36 -0800 (PST) Received: from localhost (c4@localhost) by worldclass.jolt.nu (8.9.3/8.9.3) with ESMTP id CAA03032 for ; Fri, 12 Jan 2001 02:14:53 +0100 (CET) (envelope-from c4@worldclass.jolt.nu) Date: Fri, 12 Jan 2001 02:14:51 +0100 (CET) From: ppX To: freebsd-net@freebsd.org Subject: VPN Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello I have an question regarding VPN. I have found no good documentation for the thing i want to do We want to make direct links to 2 gateways which will be connected Every computer that is linked need to be tunneling. C=Computer GW=Gateway Both gateways are active computers and must also be able to access all other computers and C1 needs to be able to connect to C6 and vice versa... If you have any tips on how to do this I really appreciate it... C1 C2 C3 \ | / \----GW 1----/ || ----GW 2---- / | \ / | \ C4 C5 C6 We have looked at PPTP but it seems to only support direct links, well maybe that would be what we can use ie Linking C1, C2, C3 directly to GW 1 and GW 1 to GW 2 and GW 2 connects the rest the same way... Also one thing GW 1 is an OpenBSD 2.8 and GW 2 is an FreeBSD 4.1.1 will this oppose any problems? OpenBSD also seems to have autmatic exchange of encryption keys, does FreeBSD support this too? C1, C2, C3 are all Linux computers C4, C5, C6 are FreeBSD 4.1.1, Linux, Linux The reason why we have to do it this strange way is because C4, C5, C6 has isp's who prohibit them to have high bandwidth outside the local DMZ but GW 2 which is connected to it does not have this problem, unless we would link C1, C2, C3 directly to it then its isp will come about and complain about the bandwidth usage it has too. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jan 11 17:44: 2 2001 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 1697237B401 for ; Thu, 11 Jan 2001 17:43:39 -0800 (PST) Received: from curve.dellroad.org (curve.dellroad.org [10.1.1.30]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id RAA85004; Thu, 11 Jan 2001 17:43:37 -0800 (PST) Received: (from archie@localhost) by curve.dellroad.org (8.11.0/8.11.0) id f0C1ha661344; Thu, 11 Jan 2001 17:43:36 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200101120143.f0C1ha661344@curve.dellroad.org> Subject: Re: mpd concurrent pptp connections. In-Reply-To: "from Dan Larsson at Jan 10, 2001 12:57:39 pm" To: Dan Larsson Date: Thu, 11 Jan 2001 17:43:36 -0800 (PST) Cc: net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Dan Larsson writes: > I need to be able to handle 30 concurrent pptp sessions > on one machine. but I only get 10 netgraph interfaces when > doing a 'ifconfig -a | grep ^ng'. > > Do I need to make any changes to my kernel? No, netgraph interfaces are created as needed on demand. > (I'm using FreeBSD-4.1.1-STABLE with netgraph as a kld). You might want to upgrade to 4.2-REL for some PPTP fixes if you have any trouble. -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 Thu Jan 11 23:31: 8 2001 Delivered-To: freebsd-net@freebsd.org Received: from white.imgsrc.co.jp (ns.imgsrc.co.jp [210.226.20.2]) by hub.freebsd.org (Postfix) with ESMTP id 49FA237B400; Thu, 11 Jan 2001 23:30:49 -0800 (PST) Received: from waterblue.imgsrc.co.jp (waterblue.imgsrc.co.jp [210.226.20.160]) by white.imgsrc.co.jp (8.11.2/8.11.0) with ESMTP id f0C7Ucj22362; Fri, 12 Jan 2001 16:30:39 +0900 (JST) Date: Fri, 12 Jan 2001 16:30:38 +0900 Message-ID: <7m1yu9mdlt.wl@waterblue.imgsrc.co.jp> From: Jun Kuriyama To: Julian Elischer Cc: net@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: HEADSUP! New netgraph code coming In-Reply-To: <3A566BCB.BFD6FA2D@elischer.org> References: <3A5567A7.A11F47E3@elischer.org> <3A566BCB.BFD6FA2D@elischer.org> User-Agent: Wanderlust/2.4.0 (Rio) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) MULE XEmacs/21.1 (patch 12) (Channel Islands) (i386--freebsd) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi Julian, I tried netgraph for the first time to work with latest vmware2 port. When I try to load netgraph kernel module, it failed with: # kldload ng_bridge kldload: can't load ng_bridge: Exec format error And /var/log/messages says: Jan 12 16:27:07 waterblue /boot/kernel/kernel: KLD ng_bridge.ko: depends on ng_ether - not available But ng_ether.ko is already loaded automatically (checked by kldstat). Is this known problem, or my local configuration mistake? # My environment is "make world"ed yesterday and kernel is latest. -- Jun Kuriyama // IMG SRC, Inc. // FreeBSD Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 12 2: 7: 5 2001 Delivered-To: freebsd-net@freebsd.org Received: from post.webmailer.de (natmail2.webmailer.de [192.67.198.65]) by hub.freebsd.org (Postfix) with ESMTP id 3A70637B69D; Fri, 12 Jan 2001 02:06:41 -0800 (PST) Received: from bastion.localhost (p3E9E165A.dip.t-dialin.net [62.158.22.90]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id LAA13640; Fri, 12 Jan 2001 11:06:37 +0100 (MET) Received: from masterpc (master [192.168.0.1]) by bastion.localhost (8.11.1/8.11.1) with ESMTP id f0CA7US01128; Fri, 12 Jan 2001 10:07:30 GMT Date: Fri, 12 Jan 2001 11:05:40 -0800 From: Boris X-Mailer: The Bat! (v1.48f) Personal Reply-To: Boris X-Priority: 3 (Normal) Message-ID: <1322983510.20010112110540@x-itec.de> To: Jorge Peixoto Vasquez Cc: freebsd-net@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: IPSEC: racoon and Win2K In-reply-To: <3A5B6E27.5787D716@aker.com.br> References: <3A5B6E27.5787D716@aker.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello Jorge, Tuesday, January 09, 2001, 12:01:43 PM, you wrote: JPV> I've read the mini-howto on how to setup IPSEC on the FreeBSD JPV> (http://asherah.dyndns.org/~josh/ipsec-howto.txt) and have been most JPV> succesful so far. Thanks for reading our IPSEC-MINI-HOWTO. JPV> The only problem I've encountered is that, when making Win2K and FreeBSD JPV> interoperate, the IKE's phase 2 only suceeds if JPV> Win2K initiates the process. If racoon is to start it, Win2k will not JPV> accept any proposal for phase 2, complaining that the dh group number I needed a connection from Win2k as initiator to my FreeBSD development server (FTP,CVS and so on) at the time of writing the win2k portability with FreeBSD. I never tested the way to connect from the bsd box to win2k, because the bsd box should never initiate the connection first. This way has some nice security advantages, too. I think its time to update the HOWTO soon. Until then, I will follow the comments on this list to collect some material for it and if I am using one or two things of someone of this list, the person will be named in the tutorial, of course. I am planning a SGML Version of the howto (DocBook 4.1 SGML) and to write some more background informations how everything works. I asked Josh about the idea, but until today I get no answer - maybe he is very busy at the moment. However, I will start updating the tutorial soon to make some things clearer. After making the update, I will contact Josh and then I will post a notification here. The most questions the people sent to me where always like these: * they contacted us first: (they should first ask the list *ggg) * phase commit errors: (no encryption pack installed) * misunderstandings about esp, why not to use ssh * how to create ssl certificates and how to use them with ipsec/ike ... I will make this things more clearer in the next update of the HOWTO. I will read some comments about the ipsec topic here in the list and after some weeks I will make a nice update, directly to sgml format that it can be read as html book. JPV> (which should correctly be either 1 or 2) received is 1 or 2 (depending JPV> on the pfs_group setting in racoon.conf) and not null(0). If I try JPV> setting pfs_group to null, I get a parse error. It takes some time to find a qualified solution to me, because I am writing and maintaining the HOWTO in my free time. I will try to find a solution, if you can explain my why to establish the connection from the bsd box first. JPV> All the docs I found in the kame site (www.kame.net), the handbook, and JPV> the man pages haven't been of any help too. We will see what we can do -) JPV> p.s. I am using FreeBSD 4.2-Stable, racoon 20001111a and (YES) I got the JPV> high-encryption pack and SP1 installed on the Win2K box. Ok thats very good and very important. -- Boris [MCSE, CNA] ................................................................... X-ITEC : Consulting * Programming * Net-Security * Crypto-Research ........: [PRIVATE ADDRESS:] : Boris Köster eMail koester@x-itec.de http://www.x-itec.de : Grüne 33-57368 Lennestadt Germany Tel: +49 (0)2721 989400 : 101 PERFECTION - SECURITY - STABILITY - FUNCTIONALITY ........:.......................................................... Everything I am writing is (c) by Boris Köster and may not be rewritten or distributed in any way without my permission. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 12 2:25:34 2001 Delivered-To: freebsd-net@freebsd.org Received: from bart.esiee.fr (bart.esiee.fr [147.215.1.20]) by hub.freebsd.org (Postfix) with ESMTP id 90C5237B400 for ; Fri, 12 Jan 2001 02:25:16 -0800 (PST) Received: (from bonnetf@localhost) by bart.esiee.fr (8.11.1/8.11.1) id f0CAPAH01637 for freebsd-net@freebsd.org; Fri, 12 Jan 2001 11:25:10 +0100 (MET) From: Frank Bonnet Message-Id: <200101121025.f0CAPAH01637@bart.esiee.fr> Subject: NTP hardware ? To: freebsd-net@freebsd.org Date: Fri, 12 Jan 2001 11:25:10 MET X-Mailer: Elm [revision: 212.5] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi Thinking to setup a NTP server for our LAN I would like to read feedback for admins that use any hardware clock connected to a FreeBSD (4.2) box. The machine is a HP PIII 350 Mhz. I'm searching for feedback/infos from experienced admins in "good" hardware devices to connect to the PC. TIA -- Frank Bonnet To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 12 3:45:42 2001 Delivered-To: freebsd-net@freebsd.org Received: from aker.com.br (unknown [200.252.12.5]) by hub.freebsd.org (Postfix) with ESMTP id 7B10137B400; Fri, 12 Jan 2001 03:45:18 -0800 (PST) Received: from aker.com.br (jorge.aker.com.br [10.0.0.16]) by aker.com.br (8.9.3/8.9.3) with ESMTP id IAA08111; Fri, 12 Jan 2001 08:29:33 -0200 (BRST) (envelope-from jorge@aker.com.br) Message-ID: <3A5EEE44.28D6BAB1@aker.com.br> Date: Fri, 12 Jan 2001 09:45:08 -0200 From: Jorge Peixoto Vasquez Organization: Aker Security Solutions X-Mailer: Mozilla 4.73 [en] (X11; I; FreeBSD 4.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Boris Cc: net@freebsd.org, security@freebsd.org Subject: Re: IPSEC: racoon and Win2K References: <3A5B6E27.5787D716@aker.com.br> <1322983510.20010112110540@x-itec.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Boris wrote: [ interesting text deleted ] > > It takes some time to find a qualified solution to me, because I am > writing and maintaining the HOWTO in my free time. I will try to find > a solution, if you can explain my why to establish the connection from > the bsd box first. > Basically, what I need is to integrate our FreeBSD-based firewalls with existing WIN2K nets our customers already have. In this (more than I would like) common situation, I can never predict which side will start the communication (mostly tunnel-mode). The problem here is full interoperation, and, for that matter, both sides should be able to establish a connection. If desired, one of then should also be able to reject it, but this must be an optional behavior. Most important: I am sure Win2K should never drop the connection because it received a request for something it supports (DH groups 1 and 2). What I am not sure of is if racoon should or should not be able to send a request with null as the desired dh group. I can't see why would it harm. jOrge -- Jorge Peixoto Vasquez, Elet. Eng. Aker Security Solutions http://www.aker.com.br tel. +55 - 61 - 340 9083 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 12 8:26:11 2001 Delivered-To: freebsd-net@freebsd.org Received: from baerenklau.de.freebsd.org (baerenklau.de.freebsd.org [195.185.195.14]) by hub.freebsd.org (Postfix) with ESMTP id EE57B37B69C for ; Fri, 12 Jan 2001 08:25:53 -0800 (PST) Received: (from uucp@localhost) by baerenklau.de.freebsd.org (8.8.8/8.8.8) with UUCP id RAA02644; Fri, 12 Jan 2001 17:25:43 +0100 (CET) (envelope-from wosch@panke.de.freebsd.org) Received: (from wosch@localhost) by paula.panke.de.freebsd.org (8.9.3/8.8.8) id RAA00722; Fri, 12 Jan 2001 17:16:46 +0100 (CET) (envelope-from wosch) Date: Fri, 12 Jan 2001 17:16:46 +0100 From: Wolfram Schneider To: Ali Boudani Cc: freebsd-net@FreeBSD.org Subject: Re: MPLS, Multicast Message-ID: <20010112171646.A706@paula.panke.de.freebsd.org> References: <3A5ED6E8.80EF85F3@irisa.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <3A5ED6E8.80EF85F3@irisa.fr>; from aboudani@irisa.fr on Fri, Jan 12, 2001 at 11:05:28AM +0100 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi Ali, I forwared your mail to the mailing list freebsd-net -Wolfram On 2001-01-12 11:05:28 +0100, Ali Boudani wrote: > Hello, > I want to know if the MPLS is implemented in the versions of FREEBSD. > And how can I contribute in this subject. > Also I want to know about the multicast appications, and how can i > contribute in the developping of these applications. > Thanx -- Wolfram Schneider http://wolfram.schneider.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 12 8:34:23 2001 Delivered-To: freebsd-net@freebsd.org Received: from sierrahill.com (sierrahill.com [209.198.135.2]) by hub.freebsd.org (Postfix) with ESMTP id 4F59737B402 for ; Fri, 12 Jan 2001 08:34:03 -0800 (PST) Received: (from rjoe@localhost) by sierrahill.com (8.9.3/8.9.3) id KAA49904 for freebsd-net@freebsd.org; Fri, 12 Jan 2001 10:34:00 -0600 (CST) (envelope-from rjoe) From: Joe Schwartz Message-Id: <200101121634.KAA49904@sierrahill.com> Subject: streaming video To: freebsd-net@freebsd.org Date: Fri, 12 Jan 2001 10:34:00 -0600 (CST) X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Folks, I see that Entera does not provide the free streamer any longer. Are there any other no cost alternatives to streaming MPG video? Thanks, Joe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 12 9: 9:23 2001 Delivered-To: freebsd-net@freebsd.org Received: from pooh.watersprings.org (pooh.watersprings.org [211.130.20.222]) by hub.freebsd.org (Postfix) with ESMTP id 9DA0737B69C for ; Fri, 12 Jan 2001 09:09:05 -0800 (PST) Received: from localhost by pooh.watersprings.org (8.8.7/2.8Wb) id RAA02389; Fri, 12 Jan 2001 17:11:26 GMT From: Noritoshi Demizu To: aboudani@irisa.fr Cc: freebsd-net@FreeBSD.org Subject: Re: MPLS, Multicast In-Reply-To: Your message of "Fri, 12 Jan 2001 17:16:46 +0100" References: <20010112171646.A706@paula.panke.de.freebsd.org> X-Mailer: Mew version 1.69 on Emacs 19.28.1 / Mule 2.3 X-URL: http://www.dd.iij4u.or.jp/~demizu/ Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010113021125R.demizu@dd.iij4u.or.jp> Date: Sat, 13 Jan 2001 02:11:25 +0900 X-Dispatcher: impost version 0.99i (Apr. 6, 1997) Lines: 19 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Dear Ali Boudani, > I want to know if the MPLS is implemented in the versions of FREEBSD. NIST Switch 0.2 runs with FreeBSD 3.3 and ALTQ-2.0 (according to their page) NIST Switch http://www.antd.nist.gov/itg/nistswitch/ Other implementations can be found at: MPLS Vendor Information's "MPLS Software" section http://www.mplsrc.com/vendor.shtml Implementation list (old info..) http://www.watersprings.org/links/mlr/#impl Best Regards, Noritoshi Demizu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 12 9:58:10 2001 Delivered-To: freebsd-net@freebsd.org Received: from gta.com (mailgate.gta.com [199.120.225.4]) by hub.freebsd.org (Postfix) with ESMTP id AFB7C37B69B for ; Fri, 12 Jan 2001 09:57:49 -0800 (PST) Received: from gta.com (GTA internal mail system) by gta.com with ESMTP id MAA92762 for ; Fri, 12 Jan 2001 12:55:09 -0500 (EST) Message-ID: <3A5F4820.634D626B@gta.com> Date: Fri, 12 Jan 2001 13:08:32 -0500 From: Larry Baird X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 4.2-RELEASE i386) X-Accept-Language: en, cs, ja, zh-TW, zh MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Strange source address problem Content-Type: multipart/mixed; boundary="------------BDE51CF92238A25D9C323930" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a multi-part message in MIME format. --------------BDE51CF92238A25D9C323930 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hopefully somebody can shed some light in helping me to understand something I am seeing on a 4.2 box. I am experimenting with a daemon that implements something very close to the VRRP (Virtual Router Redundancy Protocol). The VRRP portion of the daemon works correctly. The problem I am having has to do with the source IP address after a host has transitioned from "slave" to "master" mode. The problem can be illustrated on a standard 4.2 system not running the VRRP daemon by the following command line actions: Script started on Fri Jan 12 12:42:35 2001 sukebe# ifconfig xl0 inet 192.168.23.85 sukebe# sukebe# ifconfig xl0 xl0: flags=8843 mtu 1500 inet6 fe80::260:8ff:feaf:2bf5%xl0 prefixlen 64 scopeid 0x1 inet 192.168.23.85 netmask 0xffffff00 broadcast 192.168.23.255 ether 00:60:08:af:2b:f5 media: autoselect (none) status: no carrier supported media: autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP 100baseTX sukebe# sukebe# ./getLocalIP 192.168.23.90 local = 192.168.23.85:1178 sukebe# sukebe# ifconfig xl0 inet 192.168.23.86 sukebe# sukebe# ifconfig xl0 xl0: flags=8843 mtu 1500 inet6 fe80::260:8ff:feaf:2bf5%xl0 prefixlen 64 scopeid 0x1 inet 192.168.23.86 netmask 0xffffff00 broadcast 192.168.23.255 ether 00:60:08:af:2b:f5 media: autoselect (none) status: no carrier supported media: autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP 100baseTX sukebe# sukebe# ./getLocalIP 192.168.23.90 local = 192.168.23.85:1179 ^^^^ why is 192.168.23.85 still showing up?? This address should be gone. sukebe# sukebe# exit Script done on Fri Jan 12 12:44:35 2001 I have attached the source code to the getLocalIP program. Can anybody explain this? Thanks in advance for your help. -- ------------------------------------------------------------------------ Larry Baird Global Technology Associates, Inc. | Orlando, FL Email: lab@gta.com | TEL 407-380-0220, FAX 407-380-6080 --------------BDE51CF92238A25D9C323930 Content-Type: text/plain; charset=us-ascii; name="getLocalIP.c" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="getLocalIP.c" #include #include #include #include #include #include #include #include int main(int argc, char *argv[]) { int s; if ( argc != 2 ) fprintf( stderr, "USAGE: %s destIP[:port]\n", argv[0] ); else { if ( (s = socket( PF_INET, SOCK_DGRAM, 0 )) < 0 ) perror( "Unable to create socket" ); else { struct sockaddr_in servAddr; short port = 7; char *p; if ((p = strchr(argv[1], ':')) != NULL) { port = atoi(p + 1); *p = 0; } bzero(&servAddr, sizeof(servAddr)); servAddr.sin_family = AF_INET; servAddr.sin_port = htons( port ); if ( ! inet_aton( argv[1], &servAddr.sin_addr ) ) fprintf( stderr, "IP address invalid.\n" ); else { if ( connect( s, (struct sockaddr *)&servAddr, sizeof(servAddr) ) ) perror( "connect() failed" ); else { struct sockaddr_in local; int local_len = sizeof(local); if ( getsockname( s, (struct sockaddr *)&local, &local_len)) perror( "getsockname() failed" ); else { printf( "local = %s:%d\n", inet_ntoa(local.sin_addr), ntohs(local.sin_port)); exit( 0 ); } } } close(s); } } exit( 1 ); } --------------BDE51CF92238A25D9C323930-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 12 14:24:10 2001 Delivered-To: freebsd-net@freebsd.org Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by hub.freebsd.org (Postfix) with SMTP id 4E66837B402 for ; Fri, 12 Jan 2001 14:23:51 -0800 (PST) Received: (qmail 89403 invoked from network); 12 Jan 2001 22:21:06 -0000 Received: from unknown (HELO pipeline.ch) ([195.134.128.55]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 12 Jan 2001 22:21:06 -0000 Message-ID: <3A5F8425.15818699@pipeline.ch> Date: Fri, 12 Jan 2001 23:24:37 +0100 From: Candid Aeby Organization: Internet Pipeline AG X-Mailer: Mozilla 4.75 [de]C-CCK-MCD DT (Windows NT 5.0; U) X-Accept-Language: de-CH,en MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: problem with tap0 interface Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi I've kldloaded the if_tap.ko, created the /dev nodes but tap0 won't appear in ifconfig -a. What do I miss? TIA -- Mit freundlichen Grüssen Candid Aeby Internet Pipeline AG Hardstr. 235 8005 Zürich Tel +41 1 277 75 55 / Fax +41 1 277 75 50 http://www.pipeline.ch aeby@pipeline.ch To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 12 14:46: 0 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id 80FB537B401 for ; Fri, 12 Jan 2001 14:45:39 -0800 (PST) Received: from kairo-46.budapest.interware.hu ([195.70.50.110] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 14HCwv-0002S9-00; Fri, 12 Jan 2001 23:45:33 +0100 Message-ID: <3A5F1C86.DC8A513D@elischer.org> Date: Fri, 12 Jan 2001 07:02:30 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: ppX Cc: freebsd-net@freebsd.org Subject: Re: VPN References: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org ppX wrote: > > Hello > I have an question regarding VPN. > I have found no good documentation for the thing i want to do > We want to make direct links to 2 gateways which will be connected > Every computer that is linked need to be tunneling. > > C=Computer > GW=Gateway > > Both gateways are active computers and must also be able to access all > other computers and C1 needs to be able to connect to C6 and vice versa... > > If you have any tips on how to do this I really appreciate it... > > C1 C2 C3 > \ | / > \----GW 1----/ > || > ----GW 2---- > / | \ > / | \ > C4 C5 C6 >From what you say below, this is a better picture: C1------+ | C2------+ +--------[Internet via ISP1 ]---------- C3------+ +- - - - - - -//- - - - - - - - - | | ; GW1-----+ | ; \======+ ; VPN LINK /======+ ; GW2-----+ | ; | | ; C4------+ +- - - - - - -//- - - - - - - - - +---------[Internet via ISP]-------- C5------+ | C6------+ What is not clear is if the VPS go out through the same router as norma ISP traffic or whether you are using the ISP (ADSL? Cable?) to connect machines to your own hobs that have their own higher speed connections, via a different ISP. (or the same one with a different service agreement). > > We have looked at PPTP but it seems to only support direct links, well > maybe that would be what we can use ie Linking C1, C2, C3 directly to GW 1 > and GW 1 to GW 2 and GW 2 connects the rest the same way... > > Also one thing GW 1 is an OpenBSD 2.8 and GW 2 is an FreeBSD 4.1.1 > will this oppose any problems? > > OpenBSD also seems to have autmatic exchange of encryption keys, does > FreeBSD support this too? > > C1, C2, C3 are all Linux computers > C4, C5, C6 are FreeBSD 4.1.1, Linux, Linux > > The reason why we have to do it this strange way is because C4, C5, C6 has > isp's who prohibit them to have high bandwidth outside the local DMZ but > GW 2 which is connected to it does not have this problem, unless we would > link C1, C2, C3 directly to it then its isp will come about and complain > about the bandwidth usage it has too. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ from Perth, presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 12 14:46:10 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id 5281B37B402; Fri, 12 Jan 2001 14:45:43 -0800 (PST) Received: from kairo-46.budapest.interware.hu ([195.70.50.110] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 14HCws-0002Rr-00; Fri, 12 Jan 2001 23:45:31 +0100 Message-ID: <3A5F1788.9AD8509A@elischer.org> Date: Fri, 12 Jan 2001 06:41:12 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Jun Kuriyama Cc: net@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: HEADSUP! New netgraph code coming References: <3A5567A7.A11F47E3@elischer.org> <3A566BCB.BFD6FA2D@elischer.org> <7m1yu9mdlt.wl@waterblue.imgsrc.co.jp> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Jun Kuriyama wrote: > > Hi Julian, > > I tried netgraph for the first time to work with latest vmware2 port. > > When I try to load netgraph kernel module, it failed with: > > # kldload ng_bridge > kldload: can't load ng_bridge: Exec format error something is terribly broken with the kld loading at the moment. netgraph actually tries to load modules it needs but it hasn't been able to for some months. Also kldload ca SEE what the dependency is so the module is telling it correctly, just the kernel is failing to load the dependency.. I don't think this is Netgraph's fault. we haven;t changed anything.. it just stopped working one day. > > And /var/log/messages says: > > Jan 12 16:27:07 waterblue /boot/kernel/kernel: KLD ng_bridge.ko: depends on ng_ether - not available > > But ng_ether.ko is already loaded automatically (checked by kldstat). > > Is this known problem, or my local configuration mistake? > > # My environment is "make world"ed yesterday and kernel is latest. > > -- > Jun Kuriyama // IMG SRC, Inc. > // FreeBSD Project -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ from Perth, presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 12 15:27:16 2001 Delivered-To: freebsd-net@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 19FF737B400; Fri, 12 Jan 2001 15:26:56 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id AAA12528; Sat, 13 Jan 2001 00:26:33 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Julian Elischer Cc: Jun Kuriyama , net@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: HEADSUP! New netgraph code coming References: <3A5567A7.A11F47E3@elischer.org> <3A566BCB.BFD6FA2D@elischer.org> <7m1yu9mdlt.wl@waterblue.imgsrc.co.jp> <3A5F1788.9AD8509A@elischer.org> From: Dag-Erling Smorgrav Date: 13 Jan 2001 00:26:28 +0100 In-Reply-To: Julian Elischer's message of "Fri, 12 Jan 2001 06:41:12 -0800" Message-ID: Lines: 16 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Julian Elischer writes: > Jun Kuriyama wrote: > > # kldload ng_bridge > > kldload: can't load ng_bridge: Exec format error > > And /var/log/messages says: > > > > Jan 12 16:27:07 waterblue /boot/kernel/kernel: KLD ng_bridge.ko: depends on ng_ether - not available > > something is terribly broken with the kld loading at the moment. Something is terribly broken with ng_ether at the moment. It lacks a MODULE_VERSION line. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 12 17: 4:48 2001 Delivered-To: freebsd-net@freebsd.org Received: from cube.gelatinous.com (unknown [207.82.194.150]) by hub.freebsd.org (Postfix) with SMTP id 438B337B401 for ; Fri, 12 Jan 2001 17:04:31 -0800 (PST) Received: (qmail 5615 invoked by uid 1005); 13 Jan 2001 01:03:29 -0000 Date: 13 Jan 2001 01:03:29 -0000 Message-ID: <20010113010329.5614.qmail@cube.gelatinous.com> From: danh@gelatinous.com To: net@freebsd.org Subject: mpd problem / multiple pptp clients behind one nat Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Let's say my network is set up this way: client1---------------\ client2 \ client3 freebsd gw + natd --- internet -- freebsd machine running mpd-netgraph client4 / client5 etc...-------/ I want more than one of the client machines to connect to a vpn, with mpd-netgraph running on the vpn server. This works fine for just one client, but if more than one client tries to connect, it fails or the client already connected loses connection. I suppose the nicer correct elegant way would be to use mpd-netgraph to connect a subnet to another subnet with pptp, but I currently can't do that without renumbering my network. thanks for any help - dan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 12 17:39:34 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id C87F637B400 for ; Fri, 12 Jan 2001 17:39:14 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f0D1d3a79644; Fri, 12 Jan 2001 17:39:03 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200101130139.f0D1d3a79644@iguana.aciri.org> Subject: Re: Strange source address problem In-Reply-To: <3A5F4820.634D626B@gta.com> from Larry Baird at "Jan 12, 2001 1: 8:32 pm" To: lab@gta.com (Larry Baird) Date: Fri, 12 Jan 2001 17:39:03 -0800 (PST) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org a simplified setup to show the problem larry is experiencing is the following. Say you have a machine with address X.A and want to change it to X.B (same subnet), the router is X.C At boot you have something like ifconfig xl0 X.A route add default X.C now do a ping somehost and packets go out with a SrcIP = X.A Now do ifconfig xl0 X.B # change to new address ping somehost and packets still go out with SrcIP = X.A , which is wrong (with TCPdump you even see a reply coming in as the outside world even knows the correct MAC address, but the packet is then discarded because it fails to match any local IP). This is cured by doing a route delete default route add default X.C ping somehost at which point packets go out with the correct SrcIP = X.B (and now if you change back to X.A, you need to change the route to make the packets use the correct address). There must be something wrong in the routing table which is not deleted when the interface address changes. Problem is, it is not shown by netstat -nra -- so where should i look ? cheers luigi > [at boot:] > ifconfig xl0 192.150.187.36 netmask 0xffffff80 > route add default 192.150.187.1 > > ping x.y.z.t -> pkts go out with srcIP=92.150.187.36 > > ifconfig xl0 192.150.187.64 netmask 0xffffff80 > > ping x.y.z.t -> pkts still go out with srcIP=92.150.187.36 (wrong) > > route delete default; > route add default 192.150.187.1 > > ping x.y.z.t -> pkts now go out with srcIP=92.150.187.64 (right) > Hopefully somebody can shed some light in helping me to understand > something I am seeing on a 4.2 box. I am experimenting with a daemon > that implements something very close to the VRRP (Virtual Router > Redundancy Protocol). The VRRP portion of the daemon works correctly. > The problem I am having has to do with the source IP address after a > host > has transitioned from "slave" to "master" mode. > > The problem can be illustrated on a standard 4.2 system not > running the VRRP daemon by the following command line actions: > > Script started on Fri Jan 12 12:42:35 2001 > sukebe# ifconfig xl0 inet 192.168.23.85 > sukebe# > sukebe# ifconfig xl0 > xl0: flags=8843 mtu 1500 > inet6 fe80::260:8ff:feaf:2bf5%xl0 prefixlen 64 scopeid 0x1 > inet 192.168.23.85 netmask 0xffffff00 broadcast 192.168.23.255 > ether 00:60:08:af:2b:f5 > media: autoselect (none) status: no carrier > supported media: autoselect 100baseTX 100baseTX > 10baseT/UTP 10baseT/UTP 100baseTX > sukebe# > sukebe# ./getLocalIP 192.168.23.90 > local = 192.168.23.85:1178 > sukebe# > sukebe# ifconfig xl0 inet 192.168.23.86 > sukebe# > sukebe# ifconfig xl0 > xl0: flags=8843 mtu 1500 > inet6 fe80::260:8ff:feaf:2bf5%xl0 prefixlen 64 scopeid 0x1 > inet 192.168.23.86 netmask 0xffffff00 broadcast 192.168.23.255 > ether 00:60:08:af:2b:f5 > media: autoselect (none) status: no carrier > supported media: autoselect 100baseTX 100baseTX > 10baseT/UTP 10baseT/UTP 100baseTX > sukebe# > sukebe# ./getLocalIP 192.168.23.90 > local = 192.168.23.85:1179 > > ^^^^ why is 192.168.23.85 still showing up?? This address should be > gone. > sukebe# > sukebe# exit > > Script done on Fri Jan 12 12:44:35 2001 > > I have attached the source code to the getLocalIP program. Can > anybody explain this? Thanks in advance for your help. > > > -- > ------------------------------------------------------------------------ > Larry Baird > Global Technology Associates, Inc. | Orlando, FL > Email: lab@gta.com | TEL 407-380-0220, FAX 407-380-6080 > #include > #include > #include > #include > > #include > #include > > #include > #include > > int main(int argc, char *argv[]) > { > int s; > > if ( argc != 2 ) > fprintf( stderr, "USAGE: %s destIP[:port]\n", argv[0] ); > > else { > if ( (s = socket( PF_INET, SOCK_DGRAM, 0 )) < 0 ) > perror( "Unable to create socket" ); > > else { > struct sockaddr_in servAddr; > short port = 7; > char *p; > > if ((p = strchr(argv[1], ':')) != NULL) { > port = atoi(p + 1); > *p = 0; > } > > bzero(&servAddr, sizeof(servAddr)); > > servAddr.sin_family = AF_INET; > servAddr.sin_port = htons( port ); > > if ( ! inet_aton( argv[1], &servAddr.sin_addr ) ) > fprintf( stderr, "IP address invalid.\n" ); > else { > if ( connect( s, > (struct sockaddr *)&servAddr, > sizeof(servAddr) ) ) > perror( "connect() failed" ); > else { > struct sockaddr_in local; > int local_len = sizeof(local); > > if ( getsockname( s, > (struct sockaddr *)&local, > &local_len)) > perror( "getsockname() failed" ); > else { > printf( "local = %s:%d\n", > inet_ntoa(local.sin_addr), > ntohs(local.sin_port)); > exit( 0 ); > } > } > } > > close(s); > } > } > > exit( 1 ); > } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 12 20:32:50 2001 Delivered-To: freebsd-net@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id 1E87637B401 for ; Fri, 12 Jan 2001 20:32:33 -0800 (PST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id NAA23901; Sat, 13 Jan 2001 13:32:23 +0900 (JST) To: Luigi Rizzo Cc: lab@gta.com (Larry Baird), freebsd-net@FreeBSD.ORG In-reply-to: rizzo's message of Fri, 12 Jan 2001 17:39:03 PST. <200101130139.f0D1d3a79644@iguana.aciri.org> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Strange source address problem From: itojun@iijlab.net Date: Sat, 13 Jan 2001 13:32:22 +0900 Message-ID: <23899.979360342@coconut.itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >This is cured by doing a > route delete default > route add default X.C > ping somehost >at which point packets go out with the correct SrcIP = X.B >(and now if you change back to X.A, you need to change >the route to make the packets use the correct address). >There must be something wrong in the routing table which is >not deleted when the interface address changes. Problem is, >it is not shown by netstat -nra -- so where should i look ? rt_ifa in struct rtentry? itojun PS: i like the hostname larry have used :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 12 20:35:43 2001 Delivered-To: freebsd-net@freebsd.org Received: from oahu.WURLDLINK.NET (oahu.WURLDLINK.NET [216.235.52.1]) by hub.freebsd.org (Postfix) with ESMTP id B2F3937B404 for ; Fri, 12 Jan 2001 20:35:25 -0800 (PST) Received: from localhost (vince@localhost) by oahu.WURLDLINK.NET (8.9.3/8.9.3) with ESMTP id SAA79978 for ; Fri, 12 Jan 2001 18:35:20 -1000 (HST) (envelope-from vince@oahu.WURLDLINK.NET) Date: Fri, 12 Jan 2001 18:35:20 -1000 (HST) From: Vincent Poy To: Subject: Re: Strange source address problem In-Reply-To: <23899.979360342@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Speaking about routing in FreeBSD, is there a way to do multipath routing to a destination? Cheers, Vince - vince@WURLDLINK.NET - Vice President ________ __ ____ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] WurldLink Corporation / / / / | / | __] ] San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[____] Almighty1@IRC - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 12 21:24: 5 2001 Delivered-To: freebsd-net@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id CBB1337B400 for ; Fri, 12 Jan 2001 21:22:44 -0800 (PST) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14HJ9W-0000EV-00; Fri, 12 Jan 2001 22:22:58 -0700 Message-ID: <3A5FE632.E7E537D9@softweyr.com> Date: Fri, 12 Jan 2001 22:22:58 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Frank Bonnet Cc: freebsd-net@freebsd.org Subject: Re: NTP hardware ? References: <200101121025.f0CAPAH01637@bart.esiee.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Frank Bonnet wrote: > > Hi > > Thinking to setup a NTP server for our LAN > I would like to read feedback for admins that > use any hardware clock connected to a FreeBSD > (4.2) box. > > The machine is a HP PIII 350 Mhz. > > I'm searching for feedback/infos from experienced > admins in "good" hardware devices to connect to > the PC. The ones Warner Losh makes? ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jan 13 3: 8:55 2001 Delivered-To: freebsd-net@freebsd.org Received: from jason.argos.org (a1-3b044.neo.rr.com [24.93.181.44]) by hub.freebsd.org (Postfix) with ESMTP id D6B5E37B400 for ; Sat, 13 Jan 2001 03:08:37 -0800 (PST) Received: from localhost (mike@localhost) by jason.argos.org (8.10.1/8.10.1) with ESMTP id f0DAxv931798; Sat, 13 Jan 2001 05:59:57 -0500 Date: Sat, 13 Jan 2001 05:59:57 -0500 (EST) From: Mike Nowlin To: Frank Bonnet Cc: freebsd-net@FreeBSD.ORG Subject: Re: NTP hardware ? In-Reply-To: <200101121025.f0CAPAH01637@bart.esiee.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I'm searching for feedback/infos from experienced > admins in "good" hardware devices to connect to > the PC. I use a basic GPS receiver connected via a serial port - a simple C prog reads the data stream, and updates the system clock every few seconds from it... For most purposes, the +- 1 sec resolution it provides is good enough. The rcvrs I have all have 1PPS output, but I haven't done anything with that yet to get the accuracy down to that point. mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jan 13 5:53:14 2001 Delivered-To: freebsd-net@freebsd.org Received: from tao.org.uk (genesis.tao.org.uk [194.242.131.94]) by hub.freebsd.org (Postfix) with ESMTP id B1E0D37B401; Sat, 13 Jan 2001 05:52:53 -0800 (PST) Received: by tao.org.uk (Postfix, from userid 100) id 127F831B7; Sat, 13 Jan 2001 13:53:00 +0000 (GMT) Date: Sat, 13 Jan 2001 13:53:00 +0000 From: Josef Karthauser To: Julian Elischer Cc: Jun Kuriyama , net@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: HEADSUP! New netgraph code coming Message-ID: <20010113135300.B987@tao.org.uk> Mail-Followup-To: Josef Karthauser , Julian Elischer , Jun Kuriyama , net@FreeBSD.ORG, current@FreeBSD.ORG References: <3A5567A7.A11F47E3@elischer.org> <3A566BCB.BFD6FA2D@elischer.org> <7m1yu9mdlt.wl@waterblue.imgsrc.co.jp> <3A5F1788.9AD8509A@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A5F1788.9AD8509A@elischer.org>; from julian@elischer.org on Fri, Jan 12, 2001 at 06:41:12AM -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Jan 12, 2001 at 06:41:12AM -0800, Julian Elischer wrote: > Jun Kuriyama wrote: > > > > Hi Julian, > > > > I tried netgraph for the first time to work with latest vmware2 port. > > > > When I try to load netgraph kernel module, it failed with: > > > > # kldload ng_bridge > > kldload: can't load ng_bridge: Exec format error > > something is terribly broken with the kld loading at the moment. > netgraph actually tries to load modules it needs but it hasn't been > able to for some months. Also kldload ca SEE what the dependency is > so the module is telling it correctly, just the kernel is failing > to load the dependency.. I don't think this is Netgraph's fault. > we haven;t changed anything.. it just stopped working one day. It was broken for me last week - but upon testing yesterday it appeared to work again: genius# uname -a FreeBSD genius.tao.org.uk 5.0-CURRENT FreeBSD 5.0-CURRENT #12: Thu Jan 11 15:32:11 GMT 2001 joe@genius.tao.org.uk:/usr/obj/usr/src/sys/GENIUS i386 genius# kldload /boot/kernel/ng_bridge.ko genius# kldstat Id Refs Address Size Name 1 13 0xc0100000 2c90f0 kernel 2 1 0xc144c000 7000 linprocfs.ko 3 3 0xc1454000 12000 linux.ko 4 1 0xc14b9000 3000 daemon_saver.ko 5 1 0xc0a7c000 2000 rtc.ko 6 1 0xc0a86000 9000 vmmon_up.ko 7 1 0xc0a92000 4000 if_tap.ko 8 1 0xc1adb000 5000 ng_bridge.ko 9 1 0xc1ae1000 4000 ng_ether.ko Joe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jan 13 13: 5:57 2001 Delivered-To: freebsd-net@freebsd.org Received: from dragon.awen.com (dragon.awen.com [208.176.22.138]) by hub.freebsd.org (Postfix) with ESMTP id 7CA1B37B401 for ; Sat, 13 Jan 2001 13:05:39 -0800 (PST) Received: (from mburgett@localhost) by dragon.awen.com (8.11.2/8.11.2) id f0DL5dr06131; Sat, 13 Jan 2001 13:05:39 -0800 (PST) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Sat, 13 Jan 2001 13:05:34 -0800 (PST) Reply-To: Mike Burgett From: Mike Burgett To: freebsd-net@freebsd.org Subject: NATD/IPSec tunnel glitches.. Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I've a fairly recent -stable box (dec 19) that I use for natd/firewalling for my internal net. It has a static default route, to the outside world. Recently, I added IPSec into the equation, and setup tunnels to three networks on the other side of a Gauntlet GVPN box. The ipsec tunnels are statically keyed, so setkey is only run at init. Every thing works, _most_ of the time, and I'm able to access the remote nets from any machine in my internal net, with everything appearing on the remotes as if it came from my tunnel-end. Every so often, though, I start getting messages from natd: "failed to write packet back (No route to host)" If I go to another window, and start pinging the external IP of the GVPN box, (the other tunnel-end), it may, or may not drop a few packets, and then start working, and at that point, my IPSec tunnels seem to be working again. If I'm watching with tcpdump during this time, I don't see any ip traffic going out to the other tunnel-end. If I leave a 'ping' running to the other tunnel-end, I don't seem to see the problem. If I space it 15-30 seconds between pings, the problem seems to occur, but much more rarely that without pinging. I'd like to make sure it's not something I've misconfigured, before opening a pr on this, and I'm willing to stick in some diag lines, to try and gather more info about the circumstances surrounding these events, but don't really know where to start. Constructive suggestions welcome. I'm in the process of cvsup'ing to a current -stable, and will be rebuilding that sometime this afternoon. Thanks, Mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jan 13 14:26:10 2001 Delivered-To: freebsd-net@freebsd.org Received: from mine.kame.net (kame195.kame.net [203.178.141.195]) by hub.freebsd.org (Postfix) with ESMTP id 05BF937B401; Sat, 13 Jan 2001 14:25:50 -0800 (PST) Received: from localhost (usr-p30-76.tmisnet.com [205.197.30.76]) by mine.kame.net (8.9.3/3.7W) with ESMTP id HAA53402; Sun, 14 Jan 2001 07:23:07 +0900 (JST) To: jorge@aker.com.br Cc: freebsd-net@freebsd.org, freebsd-security@freebsd.org Subject: Re: IPSEC: racoon and Win2K In-Reply-To: Your message of "Wed, 10 Jan 2001 19:37:32 -0200" <3A5CD61C.673C1B83@aker.com.br> References: <3A5CD61C.673C1B83@aker.com.br> X-Mailer: Cue version 0.6 (001128-1517/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20010114072639Y.sakane@ydc.co.jp> Date: Sun, 14 Jan 2001 07:26:39 +0900 From: "Shoichi 'Ne' Sakane" X-Dispatcher: imput version 990905(IM130) Lines: 11 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Anyone was successfull in making these interoperate? Could you please > tell me which racoon version you used and please send me the conf file? I was successfull in that, but only with transport mode. But Win2K sometime rejected the phase 2 exchange due to proposal mismatch. I could not get the reason. See, http://www.tanu.org/~sakane/doc/public/report-ike-interop0007.html I doubt that Win2K can accept a connection of tunnel mode as a responder. Because Win2K is generally used as a client device of remote accessing into the private network through a security gateway. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message