From owner-freebsd-net Sun Dec 2 4: 6:40 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail15.bigmailbox.com (mail15.bigmailbox.com [209.132.220.46]) by hub.freebsd.org (Postfix) with ESMTP id 3810B37B416 for ; Sun, 2 Dec 2001 04:06:34 -0800 (PST) Received: (from www@localhost) by mail15.bigmailbox.com (8.10.0/8.10.0) id fB2C6Y523027; Sun, 2 Dec 2001 04:06:34 -0800 Date: Sun, 2 Dec 2001 04:06:34 -0800 Message-Id: <200112021206.fB2C6Y523027@mail15.bigmailbox.com> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary X-Mailer: MIME-tools 4.104 (Entity 4.116) Mime-Version: 1.0 X-Originating-Ip: [200.204.151.121] From: "irado@nettaxi.com" To: freebsd-net@FreeBSD.ORG Subject: problem (hairy) with dns-server Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org dear friends: I have two dns-servers at 200.198.77.34 and 200.198.77.35, and when querying it with the nslookup and dnsquery everything appears as normal. I am even using it here as my default servers - and we are not in the same link, some kilometers apart. everything runs smoothly, it is resolving any names, I am surfing in a very normal fashion. BUT: a) when starting named, after a few seconds of the message *listening on..*, suddenly pops the following message: :=== begin named[2876]:sysquery:findns error (NXDOMAIN) on deviant-1.77.198.200.in-addr.arp named[2876]:sysquery:findns error (NXDOMAIN) on deviant-2.77.198.200.in-addr.arp :=== end this is (think so) the cause of the real problem: any e-mail, either from outside or inside (lan) is refused, with the message (/var/log/mail.info): =refused - sender domain must resolve = Well, as I am using these dns and it IS resolving any query, I am completely stuck, and pulling out all my hair. Any hint, please?? (you can experiment using these dns-servers as your default ones, and sending a mail to test@dixtal.com.br), for the complete mail-error message. saudações, irado furioso com tudo GNU/Linux user CASSADO explicando o padre marcelo (mala) ´popstar´ rossi: mer%# velha com roupagem nova. por favor, clique aqui: http://www.thehungersite.com e aqui também: http://cf6.uol.com.br/umminuto/ ------------------------------------------------------------ Nettaxi would like to ask for your help in donations to the RED CROSS today! http://www.nyredcross.org/donate/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Dec 2 5:34:29 2001 Delivered-To: freebsd-net@freebsd.org Received: from mgw1.MEIway.com (mgw1.meiway.com [212.73.210.75]) by hub.freebsd.org (Postfix) with ESMTP id D7D1637B419 for ; Sun, 2 Dec 2001 05:34:20 -0800 (PST) Received: from mail.Go2France.com (ms1.meiway.com [212.73.210.73]) by mgw1.MEIway.com (Postfix Relay Hub) with ESMTP id C2F6216B13 for ; Sun, 2 Dec 2001 14:34:18 +0100 (CET) Received: from IBM-HIRXKN66F0W.Go2France.com [66.64.14.18] by mail.Go2France.com with ESMTP (SMTPD32-6.06) id A0F6456F021C; Sun, 02 Dec 2001 14:47:34 +0100 Message-Id: <5.1.0.14.0.20011202063643.03e87b98@mail.Go2France.com> X-Sender: LConrad@Go2France.com@mail.Go2France.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 02 Dec 2001 07:33:25 -0600 To: freebsd-net@FreeBSD.ORG From: Len Conrad Subject: Re: problem (hairy) with dns-server In-Reply-To: <200112021206.fB2C6Y523027@mail15.bigmailbox.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >I have two dns-servers at 200.198.77.34 and 200.198.77.35, and when >querying it with the nslookup and dnsquery everything appears as normal. when do recursive query to either, I get an answer. you should not allow recursive queries except from your trusted ip's, for BIND8 acl mynets {ip_list;}; options { allow-recursion {mynets;} ; fetch-glue no; }; >a) when starting named, after a few seconds of the message *listening >on..*, suddenly pops the following message: > >:=== begin > >named[2876]:sysquery:findns error (NXDOMAIN) on >deviant-1.77.198.200.in-addr.arp >named[2876]:sysquery:findns error (NXDOMAIN) on >deviant-2.77.198.200.in-addr.arp in-addr.arp? ".arpa" is the name of the reverse TLD parent # dig -x 200.198.77.2 ; <<>> DiG 8.3 <<>> -x ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 4 ;; flags: qr aa ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUERY SECTION: ;; 2.77.198.200.in-addr.arpa, type = ANY, class = IN ;; AUTHORITY SECTION: 77.198.200.in-addr.arpa. 1D IN SOA ns.ipaccess.diveo.net.br. hostmaster.ipaccess.diveo.net.br. ( 2001021300 ; serial 1D ; refresh 1H ; retry 2W ; expiry 1D ) ; minimum and # dig @200.198.77.3 -x 200.198.77.2 ; <<>> DiG 8.3 <<>> @200.198.77.3 -x ; (1 server found) ;; res options: init recurs defnam dnsrch ;; res_nsend to server 200.198.77.3: Operation timed out your NS's haven't been delegated with reverse authority for your subnet >(you can experiment using these dns-servers as your default ones, I didn't do that, but they both do recursion fine with dig > and sending a mail to test@dixtal.com.br), for the complete mail-error > message. works fine for me: Dec 2 13:46:26 mgw1 postfix/smtp[17844]: 08D5116B13: to=, relay=mx-sec.zazcorp.com.br[200.176.131.2], delay=121, status=sent (250 2.0.0 fB2CkKrO013294 Message accepted for delivery) DNS Expert Detailed Report for dixtal.com.br 2001-12-02, 07:30, using the analysis setting "Thorough" ====================================================================== Information ---------------------------------------------------------------------- Serial number: 2001073101 Primary name server: srv5-poa.nutecnet.com.br. Primary mail server: mail.dixtal.com.br. Number of records: N/A Errors ---------------------------------------------------------------------- o An NS record for "dixtal.com.br." refers to "srv5-poa.nutecnet.com.br." which is a CNAME record An NS record located in the zone "dixtal.com.br." refers to the host "srv5-poa.nutecnet.com.br.". The record "srv5-poa.nutecnet.com.br." is a CNAME record. NS records should always refer to canonical host names. o The name server "dns-web.zaz.com.br." is only listed in delegation data The server "dns-web.zaz.com.br." is listed as being authoritative for the zone according to the delegation data, but there is no NS record for that server in the zone data. Delegation data and zone data should always match. o The primary mail server "mail.dixtal.com.br." does not respond The mail server "mail.dixtal.com.br.", which is a primary mail server for "dixtal.com.br.", does not seem to be working. Warnings ---------------------------------------------------------------------- o The zone contains more than one authoritative name server with the same IP address The name servers "srv5-poa.nutecnet.com.br." and "dns-web.zaz.com.br.", which are authoritative for "dixtal.com.br.", have the same IP address (200.176.131.9). Len http://MenAndMice.com/DNS-training http://BIND8NT.MEIway.com : ISC BIND 8.2.4 for NT4 & W2K http://IMGate.MEIway.com : Build free, hi-perf, anti-abuse mail gateways To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Dec 2 10:21:10 2001 Delivered-To: freebsd-net@freebsd.org Received: from vega.bsdshell.net (APlessis-Bouchard-103-1-1-108.abo.wanadoo.fr [80.11.164.108]) by hub.freebsd.org (Postfix) with ESMTP id AC6A137B419 for ; Sun, 2 Dec 2001 10:20:40 -0800 (PST) Received: from there (win.bsdshell.net [172.16.1.2]) by vega.bsdshell.net (Postfix) with SMTP id D517B6AD1; Sun, 2 Dec 2001 19:26:53 +0100 (CET) Content-Type: text/plain; charset="iso-8859-1" From: Sebastien Petit Organization: BSDshell To: net@freebsd.org Subject: New network projects for FreeBSD Date: Sun, 2 Dec 2001 19:21:06 +0100 X-Mailer: KMail [version 1.3.1] Cc: spe@bsdfr.org;, announce@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20011202182653.D517B6AD1@vega.bsdshell.net> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi team, 1) A new project has borned : The High UpTime Project (HUT) This project consist of: * a VRRP v2 RFC2338 implementation (vrrpd) to do redundancy and backup of servers. * a Load Balancing Daemon (loadd) that can redirect incoming traffic with use of Divert sockets (like natd). It works with TCP traffic for the moment (not SSL and UDP yet) * you can found these projects on http://conan.lip6.fr/~spe 2) I just release a new patch file for implementing an Ethernet Firewall under FreeBSD too. the tar.gz distro come with a patch for 4.4 kernels, an utility ethfw to control rules and a man page. Is there a possibility to implement this patch (based on Luigi Rizzo ipfw code) on the FreeBSD /usr/src/sys tree ? you can download the distro at : http://conan.lip6.fr/~spe/download/ethfw-1.1-freebsd-4.4.tar.gz Regards, Sebastien Petit -- spe@bsdfr.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 3 5: 7: 0 2001 Delivered-To: freebsd-net@freebsd.org Received: from anagyris.wanadoo.fr (smtp-rt-1.wanadoo.fr [193.252.19.151]) by hub.freebsd.org (Postfix) with ESMTP id 6495D37B416 for ; Mon, 3 Dec 2001 05:06:57 -0800 (PST) Received: from mahonia.wanadoo.fr (193.252.19.58) by anagyris.wanadoo.fr; 3 Dec 2001 14:06:54 +0100 Received: from there (80.11.164.115) by mahonia.wanadoo.fr; 2 Dec 2001 11:25:17 +0100 Message-ID: <3c0a018d3c51165c@mahonia.wanadoo.fr> (added by mahonia.wanadoo.fr) Content-Type: text/plain; charset="iso-8859-1" From: Sebastien Petit Organization: BSDshell To: net@freebsd.org Subject: Ethernet Firewall for FreeBSD-4.4 Date: Sun, 2 Dec 2001 11:25:44 +0100 X-Mailer: KMail [version 1.3.1] Cc: spe@bsdfr.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I just release a new patch file for implementing an Ethernet Firewall under FreeBSD. the tar.gz distro come with a patch for 4.4 kernels, an utility ethfw to control rules and a man page. Is there a possibility to implement this patch (based on Luigi Rizzo ipfw code) on the FreeBSD /usr/src/sys tree ? you can download the distro at : http://conan.lip6.fr/~spe/download/ethfw-1.1-freebsd-4.4.tar.gz There is a Load Balancer with divert sockets too (don't work yet with SSL and UDP) and a VRRP daemon on this url too. Regards, Sebastien Petit -- spe@bsdfr.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 3 12:28:32 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 D042437B417 for ; Mon, 3 Dec 2001 12:28:30 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.3/8.11.1) id fB3KSMJ01520; Mon, 3 Dec 2001 12:28:22 -0800 (PST) (envelope-from rizzo) Date: Mon, 3 Dec 2001 12:28:22 -0800 From: Luigi Rizzo To: Sebastien Petit Cc: net@FreeBSD.ORG Subject: Re: Ethernet Firewall for FreeBSD-4.4 Message-ID: <20011203122822.A1026@iguana.aciri.org> References: <3c0a018d3c51165c@mahonia.wanadoo.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3c0a018d3c51165c@mahonia.wanadoo.fr> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Sebastien, this is a personal point of view, and I know that people think differently, but I believe it would be a lot more interesting if you would design ethfw as an add-on for ipfw as opposed to a separate thing. Not only it would remove some replication from the code (all [sg]etsockopt, basically), but would also make its adoption easier to people who already use ipfw. In fact, a very preliminary incarnation of ethernet matching was already in ipfw some time ago. I am a strong supporter of a unified interface for firewall functions. cheers luigi On Sun, Dec 02, 2001 at 11:25:44AM +0100, Sebastien Petit wrote: > Hi, > > I just release a new patch file for implementing an Ethernet Firewall under > FreeBSD. the tar.gz distro come with a patch for 4.4 kernels, an utility > ethfw to control rules and a man page. Is there a possibility to implement > this patch (based on Luigi Rizzo ipfw code) on the FreeBSD /usr/src/sys tree ? > you can download the distro at : > http://conan.lip6.fr/~spe/download/ethfw-1.1-freebsd-4.4.tar.gz > > There is a Load Balancer with divert sockets too (don't work yet with SSL and > UDP) and a VRRP daemon on this url too. > > Regards, > Sebastien Petit > -- > spe@bsdfr.org > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 3 13: 6:14 2001 Delivered-To: freebsd-net@freebsd.org Received: from vega.bsdshell.net (APlessis-Bouchard-103-1-4-88.abo.wanadoo.fr [80.13.186.88]) by hub.freebsd.org (Postfix) with ESMTP id E11F737B416 for ; Mon, 3 Dec 2001 13:06:08 -0800 (PST) Received: from there (win.bsdshell.net [172.16.1.2]) by vega.bsdshell.net (Postfix) with SMTP id DA4386ACF; Mon, 3 Dec 2001 22:12:22 +0100 (CET) Content-Type: text/plain; charset="iso-8859-1" From: Sebastien Petit Organization: BSDshell To: Luigi Rizzo Subject: Re: Ethernet Firewall for FreeBSD-4.4 Date: Mon, 3 Dec 2001 22:06:35 +0100 X-Mailer: KMail [version 1.3.1] Cc: net@FreeBSD.ORG MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20011203211222.DA4386ACF@vega.bsdshell.net> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Monday 03 December 2001 21:28, Luigi Rizzo wrote: > Sebastien, > this is a personal point of view, and I know that people think > differently, but I believe it would be a lot more interesting if > you would design ethfw as an add-on for ipfw as opposed to a separate > thing. Not only it would remove some replication from the code (all > [sg]etsockopt, basically), but would also make its adoption easier > to people who already use ipfw. In fact, a very preliminary > incarnation of ethernet matching was already in ipfw some time ago. > > I am a strong supporter of a unified interface for > firewall functions. Luigi, I'm not opposed to a merge on the ipfw code. A lot of people reports me the need to do low level filtering like ethernet filtering with mask and protocols (ARP, RARP, IPv6, IPv4 etc...), so I was starting to implement that into if_ethersubr. I don't implement it directly on ipfw because a lot of people can confuse with the name (Internet Protocol Firewall) of ipfw. The second reason is that ethernet filtering needs to move ipfw code from ip_input ip_output to if_ethersubr isn't it ?. But If you can help me to merge ethfw on ipfw, I'm totally for that, it's a great idea. Regards, Sebastien. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 3 21:32:14 2001 Delivered-To: freebsd-net@freebsd.org Received: from mta04.onebox.com (mta04.onebox.com [64.68.77.147]) by hub.freebsd.org (Postfix) with ESMTP id 46B3E37B416 for ; Mon, 3 Dec 2001 21:32:11 -0800 (PST) Received: from onebox.com ([10.1.101.6]) by mta04.onebox.com (InterMail vM.4.01.03.23 201-229-121-123-20010418) with SMTP id <20011204053202.NGMF12575.mta04.onebox.com@onebox.com>; Mon, 3 Dec 2001 21:32:02 -0800 Received: from [203.144.223.75] by onebox.com with HTTP; Mon, 03 Dec 2001 21:32:02 -0800 Date: Mon, 03 Dec 2001 21:32:02 -0800 Subject: How to manage multiple Inetnet link with FreeBSD box. From: "Chutima S." To: freebsd-net@FreeBSD.ORG Cc: chutima@infoquest.co.th Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Message-Id: <20011204053202.NGMF12575.mta04.onebox.com@onebox.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Dear all As now I have two Internet link and FreeBSD-3.4 as a Firewall for our servers. (Please see below with sample IP addresses) ISP1 dialup account to ISP2 | | -------- --------- | Router | | WebRamp | | | | | -------- --------- | | ------------------------------------------------------- | (Internet 203.154.98.184/29) ---------- | FBSD3.4 | | Firewall | ---------- | (DMZ 203.154.98.0/25) ------------------------------------------------------- | | | | --------- ------------ | | Mail | | Web Server | | | Server | | | | --------- ------------ ---------- | FBSD3.4 | | Proxy | ---------- | | (Inhouse network 192.168.10.0/24) -------------------------------------------------------- I have a problem when config default route at Firewall to WebRamp. People can not connect to our mail or web servers. How should I do to let them work together? (gated or routed???) Remark: Our IP addresses for Internet network and DMZ is come from ISP1. ISP2 is dynamic IP address from dialup modem. Thank you so much. -- Chutima S. chutima@onebox.com - email (202) 777-2646 x5475 - voicemail/fax __________________________________________________ FREE voicemail, email, and fax...all in one place. Sign Up Now! http://www.onebox.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 3 21:59: 2 2001 Delivered-To: freebsd-net@freebsd.org Received: from cody.jharris.com (cody.jharris.com [205.238.128.83]) by hub.freebsd.org (Postfix) with ESMTP id 4AC8E37B419 for ; Mon, 3 Dec 2001 21:58:59 -0800 (PST) Received: from localhost (nick@localhost) by cody.jharris.com (8.11.1/8.9.3) with ESMTP id fB45wra69919; Mon, 3 Dec 2001 23:58:53 -0600 (CST) (envelope-from nick@rogness.net) Date: Mon, 3 Dec 2001 23:58:52 -0600 (CST) From: Nick Rogness X-Sender: nick@cody.jharris.com To: "Chutima S." Cc: freebsd-net@FreeBSD.ORG, chutima@infoquest.co.th Subject: Re: How to manage multiple Inetnet link with FreeBSD box. In-Reply-To: <20011204053202.NGMF12575.mta04.onebox.com@onebox.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 3 Dec 2001, Chutima S. wrote: > Dear all > > As now I have two Internet link and FreeBSD-3.4 as a Firewall for our > servers. (Please see below with sample IP addresses) > > > ISP1 dialup account to ISP2 > | | > -------- --------- > | Router | | WebRamp | > | | | | > -------- --------- > | | > ------------------------------------------------------- > | (Internet 203.154.98.184/29) > ---------- > | FBSD3.4 | > | Firewall | > ---------- > | (DMZ 203.154.98.0/25) > ------------------------------------------------------- > | | | > | --------- ------------ > | | Mail | | Web Server | > | | Server | | | > | --------- ------------ > ---------- > | FBSD3.4 | > | Proxy | > ---------- > | > | (Inhouse network 192.168.10.0/24) > -------------------------------------------------------- > > I have a problem when config default route at Firewall to WebRamp. > People can not connect to our mail or web servers. Assuming you are not doing anything besides what you desribed, ISP2 is probably not allowing traffic from your assigned IP space. That is, ISP2 is not allowing traffic with a source address assigned from ISP1...which all your servers have. Another possiblility is that you are being filtered elsewhere. > > How should I do to let them work together? (gated or routed???) It depends if you are trying to achieve redundancy with these 2 providers. if so, you will need to run BGP. And another thing, questions like this should goto freebsd-questions@freebsd.org, not this list. Nick Rogness - Keep on Routing in a Free World... "FreeBSD: The Power to Serve!" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 3 22:17:51 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 C593837B419; Mon, 3 Dec 2001 22:17:42 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.3/8.11.1) id fB46HgJ50546; Mon, 3 Dec 2001 22:17:42 -0800 (PST) (envelope-from rizzo) Date: Mon, 3 Dec 2001 22:17:42 -0800 From: Luigi Rizzo To: net@freebsd.org Subject: HEADS-UP: net polling code now in STABLE. Message-ID: <20011203221742.A50473@iguana.aciri.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.23i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org [Bcc to -stable because of relevance there] With the approval of the release engineer, a revised version of the network polling code is now in STABLE. It would be great if you could try it out and send feedback, so we con sort out issues (if any) before the release of 4.5. Do not be afraid to upgrade, because unless you explicitly enable the new code with the kernel option mentioned below, your kernel will not be affected by the patch. The code is only for i386 architecture, non-SMP (it would be rather useless on SMP boxes, anyways). Devices supported so far are "dc", "fxp" and "sis". I can patch more drivers if you ask, but you need to test the patches yourself because i do not have access to other 100M and 1G cards (except perhaps "xl"). [As a side note -- there have been significant performance improvement changes to the "dc" and "sis" drivers recently, so if you have one of these two cards, it might be worthwhile to upgrade]. The commit message follows. Have fun. cheers luigi ----- Forwarded message from Luigi Rizzo ----- Date: Mon, 3 Dec 2001 21:57:49 -0800 (PST) From: Luigi Rizzo Subject: cvs commit: src/sys/conf options.i386 src/sys/i386/i386 swtch.s trap.c src/sys/net if.h netisr.h src/sys/sys systm.h src/sys/i386/include asnames.h src/sys/kern kern_clock.c src/sys/dev/fxp if_fxp.c src/sys/pci if_dc.c if_dcreg.h if_sis.c ... To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org luigi 2001/12/03 21:57:49 PST Modified files: (Branch: RELENG_4) sys/conf options.i386 sys/i386/i386 swtch.s trap.c sys/net if.h netisr.h sys/sys systm.h sys/i386/include asnames.h sys/kern kern_clock.c sys/dev/fxp if_fxp.c sys/pci if_dc.c if_dcreg.h if_sis.c if_sisreg.h Log: As approved by the Release Engineer, here comes the code for polling in network device drivers (x86, non-SMP only at the moment, for reasons that I have extensively explained on the -net mailing list). This code lets network devices operate in a semi-polling mode, which makes systems much more resilient to attacks and overloads. If you don't enable it with an appropriate kernel option, your kernel will be exactly the same as before this commit. No userland code is affected. To use polling you have to put the following options in your kernel config file: options DEVICE_POLLING options HZ=1000 # not compulsory but strongly recommended and enable it at runtime as follows (by default it is disabled): sysctl kern.polling.enable=1 There are basically no other tunables related to this code, though you might have a look at "sysctl kern.polling" to see what other variables are there. The device drivers supported at the moment are "dc", "fxp" and "sis", with more to come (but this code only makes sense for 100M and Gigabit devices). Unmodified drivers will continue to operate as before. Under little or moderate load you should see no difference in the behaviour of your system. Under load, you should experience a moderate improvement in peak performance, and a lot more stability and responsiveness. A quick description of the files affected (all in sys/) conf/options.i386 DEVICE_POLLING option i386/i386/swtch.s i386/i386/trap.c hooks to call the polling code net/if.h net/netisr.h sys/systm.h i386/include/asnames.h misc. constants and variable definitions (mostly one-liner). kern/kern_clock.c The bulk of the polling code. Probably this code will be moved to a separate file once equivalent functionality is added to -current. dev/fxp/if_fxp.c pci/if_dc.c pci/if_dcreg.h pci/if_sis.c pci/if_sisreg.h device driver modifications Reviewed-by: -net Approved by: jkh Revision Changes Path 1.132.2.9 +6 -1 src/sys/conf/options.i386 1.110.2.9 +56 -2 src/sys/dev/fxp/if_fxp.c 1.89.2.5 +5 -1 src/sys/i386/i386/swtch.s 1.147.2.6 +6 -1 src/sys/i386/i386/trap.c 1.44.2.4 +2 -1 src/sys/i386/include/asnames.h 1.105.2.5 +253 -1 src/sys/kern/kern_clock.c 1.58.2.3 +10 -1 src/sys/net/if.h 1.21.2.3 +2 -1 src/sys/net/netisr.h 1.9.2.25 +72 -0 src/sys/pci/if_dc.c 1.4.2.12 +7 -0 src/sys/pci/if_dcreg.h 1.13.4.10 +66 -0 src/sys/pci/if_sis.c 1.1.4.5 +3 -0 src/sys/pci/if_sisreg.h 1.111.2.11 +14 -0 src/sys/sys/systm.h ----- End forwarded message ----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 3 23: 0: 7 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 ED93837B416; Mon, 3 Dec 2001 23:00:02 -0800 (PST) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id WAA26373; Mon, 3 Dec 2001 22:49:13 -0800 (PST) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id fB46nD781640; Mon, 3 Dec 2001 22:49:13 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200112040649.fB46nD781640@arch20m.dellroad.org> Subject: differing behavior of connect(2) in -current? To: freebsd-net@freebsd.org, freebsd-current@freebsd.org Date: Mon, 3 Dec 2001 22:49:13 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, We're seeing strange behavior of mpd (netgraph-ified ppp daemon) under -current that doesn't occur under -stable. The problem is that when mpd tries to do a connect(2) on a (PF_INET, SOCK_RAW, IPPROTO_GRE), the kernel returns EINPROGRESS instead of succeeding immediately (note: this is a datagram socket so a connect should succeed immediately). The only catch is that the connect(2) is being done in the kernel by a ng_ksocket(4) node instead of via the normal system call. The ng_ksocket(4) calls soconnect() to perform the connect. I've tried reproducing the same problem with userland code but it doesn't seem to happen. So maybe this is a result of the different threading model in the -current kernel? Any ideas appreciated. Thanks, -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 Mon Dec 3 23:37:30 2001 Delivered-To: freebsd-net@freebsd.org Received: from mta03-svc.ntlworld.com (mta03-svc.ntlworld.com [62.253.162.43]) by hub.freebsd.org (Postfix) with ESMTP id 0A4CA37B417; Mon, 3 Dec 2001 23:37:24 -0800 (PST) Received: from pc1-stme2-0-cust102.cdf.cable.ntl.com ([62.252.56.102]) by mta03-svc.ntlworld.com (InterMail vM.4.01.03.23 201-229-121-123-20010418) with ESMTP id <20011204073722.ENST29646.mta03-svc.ntlworld.com@pc1-stme2-0-cust102.cdf.cable.ntl.com>; Tue, 4 Dec 2001 07:37:22 +0000 Received: from lfarr (snorlax.bka.epcdirect.co.uk [192.168.10.200]) by pc1-stme2-0-cust102.cdf.cable.ntl.com (8.11.3/8.11.3) with ESMTP id fB47bL026509; Tue, 4 Dec 2001 07:37:22 GMT (envelope-from freebsd-net@epcdirect.co.uk) From: "Lawrence Farr" To: "'Luigi Rizzo'" Cc: Subject: RE: HEADS-UP: net polling code now in STABLE. Date: Tue, 4 Dec 2001 07:37:31 -0000 Message-ID: <002c01c17c96$88631ce0$c80aa8c0@lfarr> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3311 In-Reply-To: <20011203221742.A50473@iguana.aciri.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Have you any tests I could run to verify it's stability? Lawrence Farr EPC Direct Limited > -----Original Message----- > From: owner-freebsd-stable@FreeBSD.ORG > [mailto:owner-freebsd-stable@FreeBSD.ORG] On Behalf Of Luigi Rizzo > Sent: 04 December 2001 06:18 > To: net@FreeBSD.ORG > Subject: HEADS-UP: net polling code now in STABLE. > > > [Bcc to -stable because of relevance there] > > With the approval of the release engineer, a revised version of > the network polling code is now in STABLE. It would be great if > you could try it out and send feedback, so we con sort out issues > (if any) before the release of 4.5. > > Do not be afraid to upgrade, because unless you explicitly enable > the new code with the kernel option mentioned below, your kernel > will not be affected by the patch. > > The code is only for i386 architecture, non-SMP (it would be rather > useless on SMP boxes, anyways). Devices supported so far are "dc", > "fxp" and "sis". I can patch more drivers if you ask, but you need > to test the patches yourself because i do not have access to other > 100M and 1G cards (except perhaps "xl"). > [As a side note -- there have been significant performance improvement > changes to the "dc" and "sis" drivers recently, so if you have one > of these two cards, it might be worthwhile to upgrade]. > > The commit message follows. Have fun. > > cheers > luigi > > ----- Forwarded message from Luigi Rizzo ----- > > Date: Mon, 3 Dec 2001 21:57:49 -0800 (PST) > From: Luigi Rizzo > Subject: cvs commit: src/sys/conf options.i386 > src/sys/i386/i386 swtch.s > trap.c src/sys/net if.h netisr.h src/sys/sys systm.h > src/sys/i386/include asnames.h src/sys/kern kern_clock.c > src/sys/dev/fxp if_fxp.c src/sys/pci if_dc.c > if_dcreg.h if_sis.c ... > To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org > > luigi 2001/12/03 21:57:49 PST > > Modified files: (Branch: RELENG_4) > sys/conf options.i386 > sys/i386/i386 swtch.s trap.c > sys/net if.h netisr.h > sys/sys systm.h > sys/i386/include asnames.h > sys/kern kern_clock.c > sys/dev/fxp if_fxp.c > sys/pci if_dc.c if_dcreg.h if_sis.c if_sisreg.h > Log: > As approved by the Release Engineer, here comes the code for polling > in network device drivers (x86, non-SMP only at the moment, for > reasons that I have extensively explained on the -net mailing list). > This code lets network devices operate in a semi-polling mode, > which makes systems much more resilient to attacks and overloads. > > If you don't enable it with an appropriate kernel option, your > kernel will be exactly the same as before this commit. No userland > code is affected. > > To use polling you have to put the following options in your kernel > config file: > > options DEVICE_POLLING > options HZ=1000 # not compulsory but strongly recommended > > and enable it at runtime as follows (by default it is disabled): > > sysctl kern.polling.enable=1 > > There are basically no other tunables related to this code, > though you might have a look at "sysctl kern.polling" to see > what other variables are there. > > The device drivers supported at the moment are "dc", "fxp" and > "sis", with more to come (but this code only makes sense for 100M > and Gigabit devices). Unmodified drivers will continue to operate > as before. > > Under little or moderate load you should see no difference in the > behaviour of your system. Under load, you should experience a > moderate improvement in peak performance, and a lot more stability > and responsiveness. > > A quick description of the files affected (all in sys/) > > conf/options.i386 > DEVICE_POLLING option > > i386/i386/swtch.s i386/i386/trap.c > hooks to call the polling code > > net/if.h net/netisr.h sys/systm.h i386/include/asnames.h > misc. constants and variable definitions (mostly one-liner). > > kern/kern_clock.c > The bulk of the polling code. Probably this code > will be moved to a > separate file once equivalent functionality is > added to -current. > > dev/fxp/if_fxp.c pci/if_dc.c pci/if_dcreg.h pci/if_sis.c > pci/if_sisreg.h > device driver modifications > > Reviewed-by: -net > Approved by: jkh > > Revision Changes Path > 1.132.2.9 +6 -1 src/sys/conf/options.i386 > 1.110.2.9 +56 -2 src/sys/dev/fxp/if_fxp.c > 1.89.2.5 +5 -1 src/sys/i386/i386/swtch.s > 1.147.2.6 +6 -1 src/sys/i386/i386/trap.c > 1.44.2.4 +2 -1 src/sys/i386/include/asnames.h > 1.105.2.5 +253 -1 src/sys/kern/kern_clock.c > 1.58.2.3 +10 -1 src/sys/net/if.h > 1.21.2.3 +2 -1 src/sys/net/netisr.h > 1.9.2.25 +72 -0 src/sys/pci/if_dc.c > 1.4.2.12 +7 -0 src/sys/pci/if_dcreg.h > 1.13.4.10 +66 -0 src/sys/pci/if_sis.c > 1.1.4.5 +3 -0 src/sys/pci/if_sisreg.h > 1.111.2.11 +14 -0 src/sys/sys/systm.h > > ----- End forwarded message ----- > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-stable" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 3 23:40:41 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 93B3837B417 for ; Mon, 3 Dec 2001 23:40:39 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.3/8.11.1) id fB47eVe51139; Mon, 3 Dec 2001 23:40:31 -0800 (PST) (envelope-from rizzo) Date: Mon, 3 Dec 2001 23:40:31 -0800 From: "'Luigi Rizzo'" To: Lawrence Farr Cc: net@FreeBSD.ORG Subject: Re: HEADS-UP: net polling code now in STABLE. Message-ID: <20011203234031.D50672@iguana.aciri.org> References: <20011203221742.A50473@iguana.aciri.org> <002c01c17c96$88631ce0$c80aa8c0@lfarr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002c01c17c96$88631ce0$c80aa8c0@lfarr> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Dec 04, 2001 at 07:37:31AM -0000, Lawrence Farr wrote: > Have you any tests I could run to verify it's stability? no, other than flood the interfaces with traffic and see the difference when turning kern.polling.enable on and off... cheers luigi > Lawrence Farr > EPC Direct Limited To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 4 0:23:19 2001 Delivered-To: freebsd-net@freebsd.org Received: from relay1.macomnet.ru (relay1.macomnet.ru [195.128.64.10]) by hub.freebsd.org (Postfix) with ESMTP id 3C4D337B416; Tue, 4 Dec 2001 00:23:15 -0800 (PST) Received: from news1.macomnet.ru (maxim@news1.macomnet.ru [195.128.64.14]) by relay1.macomnet.ru (8.11.3/8.11.3) with ESMTP id fB48NDR1421512; Tue, 4 Dec 2001 11:23:13 +0300 (MSK) Date: Tue, 4 Dec 2001 11:23:13 +0300 (MSK) From: Maxim Konovalov To: Luigi Rizzo Cc: net@FreeBSD.ORG Subject: Re: HEADS-UP: net polling code now in STABLE. In-Reply-To: <20011203221742.A50473@iguana.aciri.org> Message-ID: <20011204111900.C19067-100000@news1.macomnet.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi Luigi, On Mon, 3 Dec 2001, Luigi Rizzo wrote: > [Bcc to -stable because of relevance there] > > With the approval of the release engineer, a revised version of > the network polling code is now in STABLE. It would be great if > you could try it out and send feedback, so we con sort out issues > (if any) before the release of 4.5. > > Do not be afraid to upgrade, because unless you explicitly enable > the new code with the kernel option mentioned below, your kernel > will not be affected by the patch. > > The code is only for i386 architecture, non-SMP (it would be rather > useless on SMP boxes, anyways). Devices supported so far are "dc", > "fxp" and "sis". I can patch more drivers if you ask, but you need > to test the patches yourself because i do not have access to other > 100M and 1G cards (except perhaps "xl"). We have a very busy ftp server with xl card where we can test the code. So it would be great if you adopt the pathces for xl. Thank you! > [As a side note -- there have been significant performance improvement > changes to the "dc" and "sis" drivers recently, so if you have one > of these two cards, it might be worthwhile to upgrade]. > > The commit message follows. Have fun. > > cheers > luigi > [ commit message ] - -maxim -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto: maxim@macomnet.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 4 1:11:13 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.viasoft.com.cn (unknown [61.153.1.177]) by hub.freebsd.org (Postfix) with ESMTP id B5F6E37B417; Tue, 4 Dec 2001 01:11:02 -0800 (PST) Received: from viasoft.com.cn (davidwnt.viasoft.com.cn [192.168.1.239]) by mail.viasoft.com.cn (8.9.3/8.9.3) with ESMTP id RAA04704; Tue, 4 Dec 2001 17:18:20 +0800 Message-ID: <3C0C9208.90003@viasoft.com.cn> Date: Tue, 04 Dec 2001 17:06:16 +0800 From: David Xu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Luigi Rizzo Cc: net@FreeBSD.ORG Subject: Re: HEADS-UP: net polling code now in STABLE. References: <20011203221742.A50473@iguana.aciri.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org could you patch rl driver, we have 100 RealTek 8139 cards here. Regards, -- David Xu Luigi Rizzo wrote: >[Bcc to -stable because of relevance there] > >With the approval of the release engineer, a revised version of >the network polling code is now in STABLE. It would be great if >you could try it out and send feedback, so we con sort out issues >(if any) before the release of 4.5. > >Do not be afraid to upgrade, because unless you explicitly enable >the new code with the kernel option mentioned below, your kernel >will not be affected by the patch. > >The code is only for i386 architecture, non-SMP (it would be rather >useless on SMP boxes, anyways). Devices supported so far are "dc", >"fxp" and "sis". I can patch more drivers if you ask, but you need >to test the patches yourself because i do not have access to other >100M and 1G cards (except perhaps "xl"). >[As a side note -- there have been significant performance improvement >changes to the "dc" and "sis" drivers recently, so if you have one >of these two cards, it might be worthwhile to upgrade]. > >The commit message follows. Have fun. > > cheers > luigi > >----- Forwarded message from Luigi Rizzo ----- > >Date: Mon, 3 Dec 2001 21:57:49 -0800 (PST) >From: Luigi Rizzo >Subject: cvs commit: src/sys/conf options.i386 src/sys/i386/i386 swtch.s > trap.c src/sys/net if.h netisr.h src/sys/sys systm.h > src/sys/i386/include asnames.h src/sys/kern kern_clock.c > src/sys/dev/fxp if_fxp.c src/sys/pci if_dc.c if_dcreg.h if_sis.c ... >To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org > >luigi 2001/12/03 21:57:49 PST > > Modified files: (Branch: RELENG_4) > sys/conf options.i386 > sys/i386/i386 swtch.s trap.c > sys/net if.h netisr.h > sys/sys systm.h > sys/i386/include asnames.h > sys/kern kern_clock.c > sys/dev/fxp if_fxp.c > sys/pci if_dc.c if_dcreg.h if_sis.c if_sisreg.h > Log: > As approved by the Release Engineer, here comes the code for polling > in network device drivers (x86, non-SMP only at the moment, for > reasons that I have extensively explained on the -net mailing list). > This code lets network devices operate in a semi-polling mode, > which makes systems much more resilient to attacks and overloads. > > If you don't enable it with an appropriate kernel option, your > kernel will be exactly the same as before this commit. No userland > code is affected. > > To use polling you have to put the following options in your kernel > config file: > > options DEVICE_POLLING > options HZ=1000 # not compulsory but strongly recommended > > and enable it at runtime as follows (by default it is disabled): > > sysctl kern.polling.enable=1 > > There are basically no other tunables related to this code, > though you might have a look at "sysctl kern.polling" to see > what other variables are there. > > The device drivers supported at the moment are "dc", "fxp" and > "sis", with more to come (but this code only makes sense for 100M > and Gigabit devices). Unmodified drivers will continue to operate > as before. > > Under little or moderate load you should see no difference in the > behaviour of your system. Under load, you should experience a > moderate improvement in peak performance, and a lot more stability > and responsiveness. > > A quick description of the files affected (all in sys/) > > conf/options.i386 > DEVICE_POLLING option > > i386/i386/swtch.s i386/i386/trap.c > hooks to call the polling code > > net/if.h net/netisr.h sys/systm.h i386/include/asnames.h > misc. constants and variable definitions (mostly one-liner). > > kern/kern_clock.c > The bulk of the polling code. Probably this code will be moved to a > separate file once equivalent functionality is added to -current. > > dev/fxp/if_fxp.c pci/if_dc.c pci/if_dcreg.h pci/if_sis.c pci/if_sisreg.h > device driver modifications > > Reviewed-by: -net > Approved by: jkh > > Revision Changes Path > 1.132.2.9 +6 -1 src/sys/conf/options.i386 > 1.110.2.9 +56 -2 src/sys/dev/fxp/if_fxp.c > 1.89.2.5 +5 -1 src/sys/i386/i386/swtch.s > 1.147.2.6 +6 -1 src/sys/i386/i386/trap.c > 1.44.2.4 +2 -1 src/sys/i386/include/asnames.h > 1.105.2.5 +253 -1 src/sys/kern/kern_clock.c > 1.58.2.3 +10 -1 src/sys/net/if.h > 1.21.2.3 +2 -1 src/sys/net/netisr.h > 1.9.2.25 +72 -0 src/sys/pci/if_dc.c > 1.4.2.12 +7 -0 src/sys/pci/if_dcreg.h > 1.13.4.10 +66 -0 src/sys/pci/if_sis.c > 1.1.4.5 +3 -0 src/sys/pci/if_sisreg.h > 1.111.2.11 +14 -0 src/sys/sys/systm.h > >----- End forwarded message ----- > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-stable" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 4 4:14: 4 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by hub.freebsd.org (Postfix) with SMTP id A6CC137B41A for ; Tue, 4 Dec 2001 04:13:47 -0800 (PST) Received: (qmail 8557 invoked by uid 0); 4 Dec 2001 12:13:44 -0000 Received: from pd4b9eeb7.dip.t-dialin.net (HELO gmx.net) (212.185.238.183) by mail.gmx.net (mp008-rz3) with SMTP; 4 Dec 2001 12:13:44 -0000 Message-ID: <3C0CBE2D.1050505@gmx.net> Date: Tue, 04 Dec 2001 13:14:37 +0100 From: Michael Nottebrock User-Agent: Mozilla/5.0 (Windows; U; Win98; de-DE; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: de-DE MIME-Version: 1.0 To: Luigi Rizzo Cc: net@FreeBSD.ORG Subject: Re: HEADS-UP: net polling code now in STABLE. References: <20011203221742.A50473@iguana.aciri.org> Content-Type: multipart/mixed; boundary="------------010408030903010206040605" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a multi-part message in MIME format. --------------010408030903010206040605 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Luigi Rizzo wrote: > > options DEVICE_POLLING > options HZ=1000 # not compulsory but strongly recommended > > and enable it at runtime as follows (by default it is disabled): > > sysctl kern.polling.enable=1 Putting that into /etc/sysctl.conf results in a solid hang on bootup here, right after IP Filter init and before the interfaces come up: (...) IP FIlter: already initialized ipmon ipnat 0 entries flushed from NAT table 0 entries flushed from NAT list . [HANGS HERE with kern.polling.enable=1 in /etc/sysctl.conf] dc0: flags=8843 mtu 1500 inet 192.168.8.1 netmask 0xffffff00 broadcast 192.168.8.255 (...) Attached is kernel config, (normal) dmesg. Everything seems to work fine if I enable polling after booting though, so maybe this is 'correct behaviour'? Greetings, Michael Nottebrock --------------010408030903010206040605 Content-Type: text/plain; name="LOFI" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="LOFI" # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.FreeBSD.org/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ./LINT configuration file. If you are # in doubt as to the purpose or necessity of a line, check first in LINT. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.246.2.35 2001/09/27 17:43:06 alfred Exp $ machine i386 cpu I386_CPU cpu I486_CPU cpu I586_CPU cpu I686_CPU ident GENERIC maxusers 256 #Changed! #makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols options HZ=1000 # not compulsory but strongly recommended options DEVICE_POLLING options MATH_EMULATE #Support for x87 emulation options INET #InterNETworking options INET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options FFS_ROOT #FFS usable as root device [keep this!] options SOFTUPDATES #Enable FFS soft updates support options MFS #Memory Filesystem options MD_ROOT #MD is a potential root device options NFS #Network Filesystem options NFS_ROOT #NFS usable as root device, NFS required options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem options CD9660_ROOT #CD-ROM usable as root, CD9660 required options PROCFS #Process filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options USER_LDT #allow user-level control of i386 ldt options SCSI_DELAY=15000 #Delay (in ms) before probing SCSI options UCONSOLE #Allow users to grab the console options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options P1003_1B #Posix P1003_1B real-time extensions options _KPOSIX_PRIORITY_SCHEDULING options ICMP_BANDLIM #Rate limit bad replies options KBD_INSTALL_CDEV # install a CDEV entry in /dev # To make an SMP kernel, the next two are needed #options SMP # Symmetric MultiProcessor Kernel #options APIC_IO # Symmetric (APIC) I/O device isa device eisa device pci # Floppy drives device fdc0 at isa? port IO_FD1 irq 6 drq 2 device fd0 at fdc0 drive 0 device fd1 at fdc0 drive 1 # # If you have a Toshiba Libretto with its Y-E Data PCMCIA floppy, # don't use the above line for fdc0 but the following one: #device fdc0 # ATA and ATAPI devices device ata0 at isa? port IO_WD1 irq 14 device ata1 at isa? port IO_WD2 irq 15 device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID #Static device numbering # SCSI Controllers device ahb # EISA AHA1742 family device ahc # AHA2940 and onboard AIC7xxx devices device amd # AMD 53C974 (Tekram DC-390(T)) device isp # Qlogic family device ncr # NCR/Symbios Logic device sym # NCR/Symbios Logic (newer chipsets) options SYM_SETUP_LP_PROBE_MAP=0x40 # Allow ncr to attach legacy NCR devices when # both sym and ncr are configured device adv0 at isa? device adw device bt0 at isa? device aha0 at isa? device aic0 at isa? device ncv # NCR 53C500 device nsp # Workbit Ninja SCSI-3 device stg # TMC 18C30/18C50 # SCSI peripherals device scbus # SCSI bus (required) device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) # RAID controllers interfaced to the SCSI subsystem device asr # DPT SmartRAID V, VI and Adaptec SCSI RAID device dpt # DPT Smartcache - See LINT for options! device mly # Mylex AcceleRAID/eXtremeRAID # RAID controllers device aac # Adaptec FSA RAID, Dell PERC2/PERC3 device ida # Compaq Smart RAID device amr # AMI MegaRAID device mlx # Mylex DAC960 family device twe # 3ware Escalade # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc0 at isa? port IO_KBD device atkbd0 at atkbdc? irq 1 flags 0x1 device psm0 at atkbdc? irq 12 device vga0 at isa? # splash screen/screen saver pseudo-device splash # syscons is the default console driver, resembling an SCO console device sc0 at isa? flags 0x100 # Enable this and PCVT_FREEBSD for pcvt vt220 compatible console driver #device vt0 at isa? #options XSERVER # support for X server on a vt console #options FAT_CURSOR # start with block cursor # If you have a ThinkPAD, uncomment this along with the rest of the PCVT lines #options PCVT_SCANSET=2 # IBM keyboards are non-std # Floating point support - do not disable. device npx0 at nexus? port IO_NPX irq 13 # Power management support (see LINT for more options) device apm0 at nexus? disable flags 0x20 # Advanced Power Management # PCCARD (PCMCIA) support device card device pcic0 at isa? irq 0 port 0x3e0 iomem 0xd0000 device pcic1 at isa? irq 0 port 0x3e2 iomem 0xd4000 disable # Serial (COM) ports device sio0 at isa? port IO_COM1 flags 0x10 irq 4 device sio1 at isa? port IO_COM2 irq 3 device sio2 at isa? disable port IO_COM3 irq 5 device sio3 at isa? disable port IO_COM4 irq 9 # Parallel port device ppc0 at isa? irq 7 device ppbus # Parallel port bus (required) device lpt # Printer device plip # TCP/IP over parallel device ppi # Parallel port interface device #device vpo # Requires scbus and da # PCI Ethernet NICs. device de # DEC/Intel DC21x4x (``Tulip'') device txp # 3Com 3cR990 (``Typhoon'') device vx # 3Com 3c590, 3c595 (``Vortex'') # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support device dc # DEC/Intel 21143 and various workalikes device fxp # Intel EtherExpress PRO/100B (82557, 82558) device pcn # AMD Am79C97x PCI 10/100 NICs device rl # RealTek 8129/8139 device sf # Adaptec AIC-6915 (``Starfire'') device sis # Silicon Integrated Systems SiS 900/SiS 7016 device ste # Sundance ST201 (D-Link DFE-550TX) device tl # Texas Instruments ThunderLAN device tx # SMC EtherPower II (83c170 ``EPIC'') device vr # VIA Rhine, Rhine II device wb # Winbond W89C840F device wx # Intel Gigabit Ethernet Card (``Wiseman'') device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # ISA Ethernet NICs. # 'device ed' requires 'device miibus' device ed0 at isa? port 0x280 irq 10 iomem 0xd8000 device ex device ep device fe0 at isa? port 0x300 # Xircom Ethernet device xe # PRISM I IEEE 802.11b wireless NIC. device awi # WaveLAN/IEEE 802.11 wireless NICs. Note: the WaveLAN/IEEE really # exists only as a PCMCIA device, so there is no ISA attachment needed # and resources will always be dynamically assigned by the pccard code. device wi # Aironet 4500/4800 802.11 wireless NICs. Note: the declaration below will # work for PCMCIA and PCI cards, as well as ISA cards set to ISA PnP # mode (the factory default). If you set the switches on your ISA # card for a manually chosen I/O address and IRQ, you must specify # those parameters here. device an # The probe order of these is presently determined by i386/isa/isa_compat.c. device ie0 at isa? port 0x300 irq 10 iomem 0xd0000 #device le0 at isa? port 0x300 irq 5 iomem 0xd0000 device lnc0 at isa? port 0x280 irq 10 drq 0 device cs0 at isa? port 0x300 device sn0 at isa? port 0x300 irq 10 # Pseudo devices - the number indicates how many units to allocate. pseudo-device loop # Network loopback pseudo-device ether # Ethernet support pseudo-device sl 1 # Kernel SLIP pseudo-device ppp 1 # Kernel PPP pseudo-device tun # Packet tunnel. pseudo-device pty # Pseudo-ttys (telnet etc) pseudo-device md # Memory "disks" pseudo-device gif # IPv6 and IPv4 tunneling pseudo-device faith 1 # IPv6-to-IPv4 relaying (translation) # The `bpf' pseudo-device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! pseudo-device bpf #Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device usb # USB Bus (required) device ugen # Generic device uhid # "Human Interface Devices" device ukbd # Keyboard device ulpt # Printer device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse device uscanner # Scanners device urio # Diamond Rio MP3 Player # USB Ethernet, requires mii device aue # ADMtek USB ethernet device cue # CATC USB ethernet device kue # Kawasaki LSI USB ethernet #### End of generic kernel options NETSMBCRYPTO #encrypted password support for SMB # mchain library. It can be either loaded as KLD or compiled into kernel options LIBMCHAIN #mbuf management library # Kernel side iconv library options LIBICONV options NETGRAPH #netgraph(4) system options NETGRAPH_ETHER options IPFILTER #ipfilter support options IPFILTER_LOG #ipfilter logging options IPFILTER_DEFAULT_BLOCK #block all packets by default options UFS_DIRHASH --------------010408030903010206040605 Content-Type: text/plain; name="dmesg" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dmesg" Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.4-STABLE #0: Tue Dec 4 11:40:39 CET 2001 lofi@lofi.dyndns.org:/usr/obj/usr/src/sys/LOFI Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Pentium II Xeon/Celeron (501.14-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x665 Stepping = 5 Features=0x183f9ff real memory = 134205440 (131060K bytes) config> q avail memory = 125456384 (122516K bytes) Preloaded elf kernel "kernel" at 0xc04b4000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc04b409c. Pentium Pro MTRR support enabled md0: Malloc disk Using $PIR table, 5 entries at 0xc00f0d10 npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 isab0: at device 4.0 on pci0 isa0: on isab0 atapci0: port 0xd800-0xd80f at device 4.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 uhci0: port 0xd400-0xd41f irq 10 at device 4.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered chip1: port 0xe800-0xe80f at device 4.3 on pci0 dc0: port 0xd000-0xd0ff mem 0xe2000000-0xe20000ff irq 10 at device 9.0 on pci0 dc0: Ethernet address: 00:80:ad:79:23:89 miibus0: on dc0 ukphy0: on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc1: port 0xb800-0xb8ff mem 0xe1800000-0xe18000ff irq 11 at device 10.0 on pci0 dc1: Ethernet address: 00:80:ad:79:2b:42 miibus1: on dc1 ukphy1: on miibus1 ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci0: at 11.0 orm0:
Hi All,
   How does the NAT in the = ip_nat.c take=20 care of FTP port and PASV commands?
Regards
kshitij
------=_NextPart_000_004C_01C17F09.6723B0B0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 6 23:14:59 2001 Delivered-To: freebsd-net@freebsd.org Received: from snipe.prod.itd.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by hub.freebsd.org (Postfix) with ESMTP id 9B0C337B405; Thu, 6 Dec 2001 23:14:53 -0800 (PST) Received: from dialup-209.245.134.25.dial1.sanjose1.level3.net ([209.245.134.25] helo=blossom.cjclark.org) by snipe.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16CFDJ-0006jH-00; Thu, 06 Dec 2001 23:14:48 -0800 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.3) id fB77E1e12693; Thu, 6 Dec 2001 23:14:01 -0800 (PST) (envelope-from cjc) Date: Thu, 6 Dec 2001 23:14:01 -0800 From: "Crist J . Clark" To: Bill Fenner Cc: net@freebsd.org, security@freebsd.org Subject: Re: NOARP - gateway must answer and have frozen ARP table Message-ID: <20011206231401.N8975@blossom.cjclark.org> Reply-To: cjclark@alum.mit.edu References: <20011205124430.A83642@svzserv.kemerovo.su> <20011205040316.H40864@blossom.cjclark.org> <20011205231735.A1361@grosbein.pp.ru> <20011205193859.B79705@sunbay.com> <200112051835.fB5IZqH95521@whizzo.transsys.com> <20011205204526.B89520@sunbay.com> <200112051852.fB5IqmH95809@whizzo.transsys.com> <20011205121928.A3061@blossom.cjclark.org> <200112062059.MAA02282@windsor.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200112062059.MAA02282@windsor.research.att.com>; from fenner@research.att.com on Thu, Dec 06, 2001 at 12:59:39PM -0800 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, Dec 06, 2001 at 12:59:39PM -0800, Bill Fenner wrote: > > Garrett and I discussed what IFF_NOARP should mean about 4-5 years > ago; we decided that it probably menat "no ARP". We discussed > the idea of seperating it out into two flags; "Don't reply to ARP" > and "don't pay attention to ARP" but decided to wait and see what > people thought. 4-5 years is probably enough time to wait =) > > My proposal: keep IFF_NOARP, but add IFF_NOSENDARP and IFF_NOREPLYARP > (or something, I'm no good at making up names). I agree with Louie > that it makes sense for these to be per-interface as opposed to > Ruslan's sysctl. If this is really want to do, I believe you can do it with existing tools. For simplicity, I'm just going to illustrate a way to set it up rather than explain it. Store your IP-MAC address pairs in flat file as proscribed in arp(8), 192.168.10.2 01:02:03:10:11:12 192.168.10.4 01:02:03:21:22:23 ... Load your permanent ARP table with a simple, arp -f arp_list.txt In the startup and include, while read $IP $MAC; do ipfw add pass ip from $IP to any via if0 ipfw add pass ip from any to $IP via if0 done < arp_list.txt ipfw add deny ip from any to any via if0 In your rc.firewall. Now you have a static ARP table and all traffic not from those IP addresses is blocked. Since we never ARP for any other addresses, the packets are blocked before we ARP for them, we never get other entries in the ARP table. At least I think this should do what you want. I still am not quite sure what a "one-way ARP" is supposed to gain. -- "It's always funny until someone gets hurt. Then it's hilarious." Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 7 0: 2:14 2001 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 9EFC737B41D for ; Fri, 7 Dec 2001 00:02:06 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id fB781KS15548; Fri, 7 Dec 2001 10:01:20 +0200 (EET) (envelope-from ru) Date: Fri, 7 Dec 2001 10:01:20 +0200 From: Ruslan Ermilov To: Guido van Rooij Cc: Dingo , net@FreeBSD.org Subject: Re: IPSEC and IPNAT (was: Re: IPSec) Message-ID: <20011207100120.E13705@sunbay.com> References: <1007658158.24679.5.camel@devel.netwolves.com> <20011206181039.A12412@sunbay.com> <1007659326.24679.11.camel@devel.netwolves.com> <20011206192927.A14515@sunbay.com> <20011206201333.A86441@gvr.gvr.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011206201333.A86441@gvr.gvr.org> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, Dec 06, 2001 at 08:13:33PM +0100, Guido van Rooij wrote: > On Thu, Dec 06, 2001 at 07:29:27PM +0200, Ruslan Ermilov wrote: > > On Thu, Dec 06, 2001 at 10:22:05PM +0500, Dingo wrote: > > > ipfilters ipnat.... We ran into the IPSec intercept problem with 4.3, > > > can you tell me when the changes were MFCd ? it might just be a matter > > > of updateing Ipfilter on this specific server. its a 4.3 RELEASE box. > > > But If I am correct, your telling me i can create a standard VPN, in > > > tunnel or transport mode, with ipfs ipnat, no gif devices ?? like > > > > > > 10.0.xxx.xxx -> ipnat -> 4.23.122.100 -> IPSEC TUNNEL <- 4.22.121.101 <- > > > ipnat <- 10.20.xxx.xxx > > > > > [What's missing in this picture is how ipnat modifies the 10.0 -> > > 10.20 packets. I will assume it hides the 10.0.xxx.xxx addresses > > after a single 4.23.122.100.] > > > > I'm not fluent in IPFilter (and IPNAT in particular), but I think > > there may be some difference between how IPNAT and IPDIVERT work. > > With IPDIVERT, a packet is first passed to a userland process, > > natd(8) in a similar scenario, and natd(8) writes the modified > > packet back to kernel which then passes this new packet back to > > ip_output(). ip_output() is organized so that IPSEC hooks are > > called before IPDIVERT and IPNAT hooks, but with IPDIVERT it's > > no problem, since the new packet is passed again to ip_output(), > > and if you tell your IPSEC to tunnel between 4.23.122.100 and > > 4.22.121.101, IPSEC will intercept that NATed packet. > > > > If IPNAT doesn't do the same, i.e., if it doesn't consider the > > NATed packet a "new" packet, and just continues with the modified > > packet, we have a trouble -- we have no way to IPSEC modified > > packet. Let IPFilter gurus speak up. :-) > > When you NAT, outgoing packets on the 4.23.122.100 interface > get their source address modified if you have a rule like: > map 10.0.0.0/16 -> 4.23.122.100 > This happens at the end of ip_output after ipsec processing. > Return packets will have their destination address changed at > the moment thye come in, before ip_input (and ipsec) processing. > So we definitely have a problem here. IPNAT processes outgoing packet only once (just modifies its source address), i.e., it's not passed again to ip_output() processing but rather IPFILTER just forwards the modified packet using routing decision. > The packets are already encrypted by then, so no NAT will take > place. On the other hand: NAT seems unnecessary since packets are > in a tunnel anyway, so the 10 addresses will never show up. > FreeBSD: tools, not policy. :-) I can easily imagine a situation where NAT before IPSEC would be useful, though I must admit I have never used this combo, in that order. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 7 0:24:50 2001 Delivered-To: freebsd-net@freebsd.org Received: from relay1.macomnet.ru (relay1.macomnet.ru [195.128.64.10]) by hub.freebsd.org (Postfix) with ESMTP id EE3DC37B417 for ; Fri, 7 Dec 2001 00:24:46 -0800 (PST) Received: from news1.macomnet.ru (maxim@news1.macomnet.ru [195.128.64.14]) by relay1.macomnet.ru (8.11.3/8.11.3) with ESMTP id fB78OdO1697421; Fri, 7 Dec 2001 11:24:40 +0300 (MSK) Date: Fri, 7 Dec 2001 11:24:39 +0300 (MSK) From: Maxim Konovalov To: Paul Chvostek Cc: freebsd-net@FreeBSD.ORG Subject: Re: log_in_vain In-Reply-To: <20011206094325.A434@mail.it.ca> Message-ID: <20011207112237.M10311-100000@news1.macomnet.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello, On Thu, 6 Dec 2001, Paul Chvostek wrote: > > For the fun of it, I turned on log_in_vain. And I'm seeing *lots* of > stuff one might expect (port scans, Nimda poking at my mail server, > SMTP to the web server, etc). But I'm also seeing stuff I don't expect, > primarily in the areas of DNS and localhost traffic. For example: > > Dec 6 08:15:39 schplict /kernel: Connection attempt to UDP 216.126.86.8:1262 from 216.126.86.2:53 > > and > > Dec 6 08:35:37 haggis /kernel: Connection attempt to UDP 216.126.86.9:1044 from 216.126.86.2:53 > > and > > Dec 6 08:34:44 haggis /kernel: Connection attempt to UDP 127.0.0.1:512 from 127.0.0.1:1054 > Dec 6 08:34:44 haggis /kernel: Connection attempt to UDP 127.0.0.1:512 from 127.0.0.1:1058 > Dec 6 08:34:44 haggis /kernel: Connection attempt to UDP 127.0.0.1:512 from 127.0.0.1:1063 > Dec 6 08:34:45 haggis /kernel: Connection attempt to UDP 127.0.0.1:512 from 127.0.0.1:1067 > > The host at 216.126.86.2 is the first nameserver in the resolv.conf of > the both haggis and schplict. It looks to me as if the name server is > sending responses back to DNS queries which for some reason haven't > waited around. because of request timeout. > And as far as I know I'm not running biff on haggis. The frequency of > the hits makes it look as if it's running something every time ... > something ... gets launched. But biff's not in any .profile, .cshrc or > .login. So I'm left scratching my head. man 8 mail.local will help. > Can anybody shed some light on this? -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto: maxim@macomnet.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 7 0:33:16 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.realtek.com.tw (ms1.realtek.com.tw [203.69.112.3]) by hub.freebsd.org (Postfix) with ESMTP id 4F27137B417 for ; Fri, 7 Dec 2001 00:33:09 -0800 (PST) Received: from RTCN3848 ([172.20.35.162]) by mail.realtek.com.tw (Lotus Domino Release 5.0.8) with SMTP id 2001120716322937:2609 ; Fri, 7 Dec 2001 16:32:29 +0800 Message-ID: <001c01c17efa$8fc041f0$0101a8c0@RTCN3848> From: "cfliu" To: Subject: Tutorials or notes available for 4.4's ipsec, ipfw, and divert socket? Date: Fri, 7 Dec 2001 16:38:36 +0800 MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-MIMETrack: Itemize by SMTP Server on ms1/Realtek(Release 5.0.8 |June 18, 2001) at 12/07/2001 04:32:29 PM, Serialize by Router on ms1/Realtek(Release 5.0.8 |June 18, 2001) at 12/07/2001 04:32:32 PM, Serialize complete at 12/07/2001 04:32:32 PM Content-Type: multipart/alternative; boundary="----=_NextPart_000_0019_01C17F3D.9DD43FB0" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_0019_01C17F3D.9DD43FB0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="big5" Hi, I am reading the IP layer source code and I am wondering if there = have been mails on this mailing list, or other tutorial documents on the = web explaining the design principles of the implementation of ipfw , = ipsec, and divert socket in 4.4 kernel. Please tell me where can I find = them if they do exist or have shown up before in this mailing list. = Thank you very much David. ------=_NextPart_000_0019_01C17F3D.9DD43FB0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="big5"
Hi, I am reading the IP layer source code and I am = wondering=20 if there have been mails on this mailing list, or other tutorial = documents on=20 the web explaining the design principles  of the implementation of = ipfw ,=20 ipsec, and divert socket in 4.4 kernel. Please tell me where can I find = them if=20 they do exist or have shown up before in this mailing list. Thank you = very=20 much
 
David.
------=_NextPart_000_0019_01C17F3D.9DD43FB0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 7 1: 6:29 2001 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 62AC637B41E; Fri, 7 Dec 2001 01:06:15 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id fB795gb24480; Fri, 7 Dec 2001 11:05:42 +0200 (EET) (envelope-from ru) Date: Fri, 7 Dec 2001 11:05:42 +0200 From: Ruslan Ermilov To: Bill Fenner Cc: cjclark@alum.mit.edu, net@FreeBSD.ORG, security@FreeBSD.ORG Subject: Re: NOARP - gateway must answer and have frozen ARP table Message-ID: <20011207110542.J13705@sunbay.com> References: <20011205124430.A83642@svzserv.kemerovo.su> <20011205040316.H40864@blossom.cjclark.org> <20011205231735.A1361@grosbein.pp.ru> <20011205193859.B79705@sunbay.com> <200112051835.fB5IZqH95521@whizzo.transsys.com> <20011205204526.B89520@sunbay.com> <200112051852.fB5IqmH95809@whizzo.transsys.com> <20011205121928.A3061@blossom.cjclark.org> <200112062059.MAA02282@windsor.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200112062059.MAA02282@windsor.research.att.com> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, Dec 06, 2001 at 12:59:39PM -0800, Bill Fenner wrote: > > Garrett and I discussed what IFF_NOARP should mean about 4-5 years > ago; we decided that it probably menat "no ARP". We discussed > the idea of seperating it out into two flags; "Don't reply to ARP" > and "don't pay attention to ARP" but decided to wait and see what > people thought. 4-5 years is probably enough time to wait =) > Heh, but only a few months ago IFF_NOARP started to DTRT. > My proposal: keep IFF_NOARP, but add IFF_NOSENDARP and IFF_NOREPLYARP > (or something, I'm no good at making up names). I agree with Louie > that it makes sense for these to be per-interface as opposed to > Ruslan's sysctl. > What you propose is even more "flexible". :-) What's the purpose to send arp requests (!IFF_NOSENDARP) if we're not going to listen the replies (IFF_NOREPLYARP)? Also, ifnet.if_flags is declared "short" and is already fully allocated. Changing it to u_int64_t would mean introducing binary incompatibility, and what's worse, API changes, since ifreq.ifr_flags is also "short". OK, I have a proposal that should fit both opinions. I'll keep the net.link.ether.inet.static_arp to mean what it means now (keep ARP table static, no updates except from local process through a routing socket writes), and will add another sysctl that will switch the meaning of IFF_NOARP from "no arp" to "static arp on this interface". How about this? Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 7 2:31:31 2001 Delivered-To: freebsd-net@freebsd.org Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by hub.freebsd.org (Postfix) with ESMTP id 1F10737B419 for ; Fri, 7 Dec 2001 02:31:27 -0800 (PST) Received: from europe.cisco.com (europe.cisco.com [144.254.52.73]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id fB7AVP917212 for ; Fri, 7 Dec 2001 02:31:25 -0800 (PST) Received: from cobweb.example.org (dhcp-nic-val-26-117.cisco.com [64.103.26.117]) by europe.cisco.com (8.8.8+Sun/8.8.8) with SMTP id LAA12926 for ; Fri, 7 Dec 2001 11:31:22 +0100 (MET) Received: (qmail 21646 invoked by uid 1000); 7 Dec 2001 10:31:32 -0000 Date: Fri, 7 Dec 2001 11:31:32 +0100 From: Marco Molteni To: freebsd-net@FreeBSD.ORG Subject: Re: pcap_open_live() takes 1 sec to complete? Message-ID: <20011207113132.A21525@cobweb.example.org> References: <20011206141330.A17077@cobweb.example.org> <200112061823.fB6INsP49553@ambrisko.com> <20011206132924.A65556@tp.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011206132924.A65556@tp.databus.com>; from barney@databus.com on Thu, Dec 06, 2001 at 01:29:24PM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 2001-12-06, Barney Wolff wrote: > As I recall, delays like that come from the power-saving mode on > the card. Turn power-saving off to make them go away. Power saving is off: # ancontrol -C | grep "save mode" Power save mode: [ none ] > > Marco Molteni writes: > > | I am writing a small program that does a pcap_open_live() on the > > | Aironet an device, PCMCIA mode. System is a recent -stable on a > > | Toshiba Portege 7200 laptop. > > | > > | Now, pcap_open_live() takes more than 1 sec to return. Is this long > > | time expected? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 7 2:39:19 2001 Delivered-To: freebsd-net@freebsd.org Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by hub.freebsd.org (Postfix) with ESMTP id 056AF37B41B for ; Fri, 7 Dec 2001 02:39:16 -0800 (PST) Received: from europe.cisco.com (europe.cisco.com [144.254.52.73]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id fB7AdE920438 for ; Fri, 7 Dec 2001 02:39:14 -0800 (PST) Received: from cobweb.example.org (dhcp-nic-val-26-117.cisco.com [64.103.26.117]) by europe.cisco.com (8.8.8+Sun/8.8.8) with SMTP id LAA15199 for ; Fri, 7 Dec 2001 11:39:10 +0100 (MET) Received: (qmail 21684 invoked by uid 1000); 7 Dec 2001 10:39:20 -0000 Date: Fri, 7 Dec 2001 11:39:20 +0100 From: Marco Molteni To: freebsd-net@FreeBSD.ORG Cc: Doug Ambrisko Subject: Re: pcap_open_live() takes 1 sec to complete? Message-ID: <20011207113920.B21525@cobweb.example.org> References: <20011206141330.A17077@cobweb.example.org> <200112061823.fB6INsP49553@ambrisko.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200112061823.fB6INsP49553@ambrisko.com>; from ambrisko@ambrisko.com on Thu, Dec 06, 2001 at 10:23:52AM -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 2001-12-06, Doug Ambrisko wrote: > Marco Molteni writes: > | I am writing a small program that does a pcap_open_live() on the > | Aironet an device, PCMCIA mode. System is a recent -stable on a > | Toshiba Portege 7200 laptop. > | > | Now, pcap_open_live() takes more than 1 sec to return. Is this long > | time expected? > > Hmm, don't seem to recall that. My system is busy doing a make world > and stuff. I just tried it and on my busy machine it was less then > a second. Note I was not in RFMON mode. It might take longer when > I have to switch into RFMON mode. I can try that later. You might > try to compare it without RFMON if you are using RFMON. Actually I am in RFMON mode. Also, I found something strange: the first time that pcap_open_live() is called, it is fast (50 ms), but subsequent calls are slow (1000 ms). If I remove and reinsert the card, first call is once more fast. # ./airomon an0 set monitor mode: 23 ms pcap_open_live: 52 ms ^C # ./airomon an0 set monitor mode: 24 ms pcap_open_live: 1089 ms ^C > FYI, I put a sample BPF packet dumper up at: > http://www.ambrisko.com/doug/an/dump_packet/ > I used it to debug the 802.11 packet problem and to look at the raw > Aironet Header packets. > > You'll see it has some test code to check gap length. > > This is on -stable with my 802.11 aligment fix. thanks a lot for this, I will try it out. marco To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 7 5: 2:15 2001 Delivered-To: freebsd-net@freebsd.org Received: from mailserver.KOM.e-technik.tu-darmstadt.de (drum.kom.e-technik.tu-darmstadt.de [130.83.139.190]) by hub.freebsd.org (Postfix) with ESMTP id 0504537B417 for ; Fri, 7 Dec 2001 05:02:10 -0800 (PST) Received: from KOM.tu-darmstadt.de by mailserver.KOM.e-technik.tu-darmstadt.de (8.7.5/8.7.5) with ESMTP id OAA23986; Fri, 7 Dec 2001 14:02:02 +0100 (MET) From: Martin Karsten Received: from KOM.tu-darmstadt.de by KOM.tu-darmstadt.de (8.11.2/8.7.5) id fB7D1WP23207; Fri, 7 Dec 2001 14:01:32 +0100 Message-Id: <200112071301.fB7D1WP23207@KOM.tu-darmstadt.de> Subject: Re: Router alert option In-Reply-To: from Madhavi Suram at "Dec 6, 2001 07:20:51 pm" To: Madhavi Suram Date: Fri, 7 Dec 2001 14:01:32 +0100 (CET) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > I have seen Mr.Ping Pan's implementation of this. This seems to be just > for receiving a packet with some IP option through a raw IP socket. This I haven't carefully looked into the code, but it seems enable to receive as well as intercept (and send through a socket to the user-level) packets with specific options. What else would you want to do with an RA packet? > doesn't seem to be containing the kernel processing part of a packet > with router alert option. In netinet6 I have seen that the ip6_input() > function sets > ours = 1; > when it gets a packet with router alert option. Is something similar done > in case of IPv4 too? If that's the case, I couldn't figure it out in this > patch. The equivalent seems to be done within 'ipopt_input', which is called from both 'ip_input' and 'ip_forward'. > Or is it already there in the standard kernel itself? Could some one tell > me how a packet with router alert option is handled in ip_input(), or give > me some pointers to some description of this processing? No, this is not handled by the standard kernel. Only RSVP messages (some of which would usually carry the RA option) are intercepted and send to the user level (if a socket has registered to receive them). Greetings, Martin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 7 8:15: 6 2001 Delivered-To: freebsd-net@freebsd.org Received: from snowblind.mine.nu (h14n2fls33o883.telia.com [217.208.62.14]) by hub.freebsd.org (Postfix) with ESMTP id F2CEB37B417 for ; Fri, 7 Dec 2001 08:15:01 -0800 (PST) Received: (from jerry@localhost) by snowblind.mine.nu (8.11.6/8.11.6) id fB7FCwA00421 for freebsd-net@freebsd.org; Fri, 7 Dec 2001 16:12:58 +0100 (CET) (envelope-from jerry) Date: Fri, 7 Dec 2001 16:12:58 +0100 From: Jerry Eriksson To: freebsd-net@freebsd.org Subject: 3C19250 Message-ID: <20011207161257.A390@coredump.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi I've got some problems with my 3C19250 USB NIC. My sys is 5.0-CURRENT, but I get the same errors on 4.4-STABLE, dmesg: kue0: 3COM 3COM USB Network Interface (3C19250), rev 1.00/2.02, addr 2 The NIC is found and it works good but then after a while: Dec 3 19:03:14 snowblind /kernel: kue0: watchdog timeout Dec 3 19:03:14 snowblind /kernel: kue0: usb error on tx: TIMEOUT Dec 3 19:03:16 snowblind /kernel: kue0: usb error on tx: IOERROR Dec 3 19:03:16 snowblind /kernel: kue0: usb error on rx: IOERROR Dec 3 19:03:16 snowblind /kernel: kue0: usb error on rx: IOERROR Dec 3 19:03:16 snowblind /kernel: kue0: usb error on tx: IOERROR and it keeps repeating the last and doesn't seem to reset. I'm wondering if anyone else has got the same problems ? Anyone got an idea on how to solve it ?. Thank you, Jerry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 7 8:15:38 2001 Delivered-To: freebsd-net@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 82C3B37B405; Fri, 7 Dec 2001 08:15:28 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.6/8.11.6) with ESMTP id fB7GE0j22767; Fri, 7 Dec 2001 17:14:00 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: arch@freebsd.org, net@freebsd.org Subject: Request to back out Luigis polled-net patch in -stable. Date: Fri, 07 Dec 2001 17:14:00 +0100 Message-ID: <22765.1007741640@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org ------- Forwarded Message To: core@freebsd.org Subject: Request to back out Luigis polled-net patch in -stable. From: Poul-Henning Kamp Date: Fri, 07 Dec 2001 17:13:24 +0100 Message-ID: <22749.1007741604@critter.freebsd.dk> Sender: phk@critter.freebsd.dk I have not read the entire patch in details, but have focused on the part of the code which I have special insight into. My complaint is therefore mainly based on one single file: src/sys/kern/kern_clock.c which has been spammed with a lot of stuff which has absolutely no business being there. Just for starters: Adding this to sys/kern/kern_clock.c: +#ifdef DEVICE_POLLING +#include /* for vm_page_zero_idle() */ +#include /* needed by sys/if.h */ +#include /* for IFF_* flags */ +#include /* for NETISR_POLL */ +[...] +#endif /* DEVICE_POLLING */ None of this as any business here, and it certainly doesn't even look remotely possible for this to work on !i386 platforms. Most of the rest of the addition is code which should not be in sys/kern in the first place but sys/net. Just because it is #ifdef DEVICE_POLLING doesn't mean it can violate our architecture. Furthermore, according to the commit message, this was approved by jkh in his role of release-engineer, but I find it disturbing that the approval seems to have happened without any technical or architectural review of the proposed patch. Finally, I thought a significant change like this would have to go into -current at least at the same time, but preferably before it goes into -stable. Considering the repeated claims of +10% performance for this suite of changes, there is a very good chance that people will pick it up and use it, leaving us with a big problem when 5.0-R time comes around and we have to explain A) why the feature isn't there, and B) why performance is worse. Summary: I request that luigis patch gets backed out for the following reasons: 1. The patch is architecturally a mess. 2. The approval seems to have happened purely on "glossy sales-brochure" backing without any technical or architectural input. 3. It didn't go into -current first and has received no shakeout before it went into -stable. I am _NOT_ saying that the idea is bad, it sounds pretty intelligent to me, but in that case it is even more important to not mess it up. I would also like to point to the parallel piece of code: Jun-Itohs ALTQ for which he reliably has maintained a patch relative to the 4.X branch and which despite various peoples requests have not haphazardly been committed into -stable. And in that context one should not forget that ALTQ has a lot longer and better trackrecord of high quality than Luigis poll-code, or any of Luigis code for that matter. - -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ------- End of Forwarded Message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 7 10:19: 3 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail-01.foundation-i.com (mail-01.foundation-i.com [206.111.21.14]) by hub.freebsd.org (Postfix) with ESMTP id 4855837B405 for ; Fri, 7 Dec 2001 10:19:00 -0800 (PST) Subject: Gigabit for FreeBSD MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable content-class: urn:content-classes:message Date: Fri, 7 Dec 2001 10:22:44 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: <4FB6DCB8FA515F49AAE50827A60D42CD862B0F@mail-01.foundation-i.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Gigabit for FreeBSD Thread-Index: AcF/TCpPKsGbeQ0gRzOFhGkY6aDGSA== From: "David Smithson" To: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi all. Does anyone know of a good stable 1000baseTX gigabit network = adapter that works well with FreeBSD? I have this Netgear adapter that = seems to have problems. Help is -- of course -- appreciated. Thanks. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 7 10:25:31 2001 Delivered-To: freebsd-net@freebsd.org Received: from skeezix.n0qds.org (skeezix.n0qds.org [204.246.69.106]) by hub.freebsd.org (Postfix) with ESMTP id B7D0B37B41B for ; Fri, 7 Dec 2001 10:25:27 -0800 (PST) Received: from hogan (hogan.n0qds.org [204.246.69.105]) by skeezix.n0qds.org (Postfix) with ESMTP id 7D9EA97; Fri, 7 Dec 2001 12:25:26 -0600 (CST) Date: Fri, 7 Dec 2001 12:25:26 -0600 Subject: Re: Gigabit for FreeBSD Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v475) Cc: To: "David Smithson" From: Greg Putrich In-Reply-To: <4FB6DCB8FA515F49AAE50827A60D42CD862B0F@mail-01.foundation-i.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.475) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I'm using 3Com 3c985-SX and it seems to work fine. Haven't yet push it hard, but has (so far) provided connectivity. On Friday, December 7, 2001, at 12:22 , David Smithson wrote: > Hi all. Does anyone know of a good stable 1000baseTX gigabit network > adapter that works well with FreeBSD? I have this Netgear adapter that > seems to have problems. Help is -- of course -- appreciated. Thanks. -- --------------------------------------------------------------------------- Greg Putrich [h-X] Internet: gregp@n0qds.org "I have a problem with the fact that they [Microsoft] just make really third rate products." - Steve Jobs, Acting CEO, Apple Computer (6/12/96) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 7 11:21:58 2001 Delivered-To: freebsd-net@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 6559E37B405; Fri, 7 Dec 2001 11:21:53 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.3) with ESMTP id fB7JQx301437; Fri, 7 Dec 2001 11:26:59 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200112071926.fB7JQx301437@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Poul-Henning Kamp Cc: arch@freebsd.org, net@freebsd.org Subject: Re: Request to back out Luigis polled-net patch in -stable. In-reply-to: Your message of "Fri, 07 Dec 2001 17:14:00 +0100." <22765.1007741640@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 07 Dec 2001 11:26:59 -0800 From: Mike Smith Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > To: core@freebsd.org Core isn't really the appropriate forum for asking for a back-out; arch and net are where this should have been discussed and reviewed in the first place. > Subject: Request to back out Luigis polled-net patch in -stable. I'm entirely in agreement with this; the decision to commit this code was extremely ill-advised, and the best thing we can do now for everyone's sake is to pull it as quickly as possible. > I would also like to point to the parallel piece of code: Jun-Itohs > ALTQ for which he reliably has maintained a patch relative to the > 4.X branch and which despite various peoples requests have not > haphazardly been committed into -stable. And in that context one > should not forget that ALTQ has a lot longer and better trackrecord > of high quality than Luigis poll-code, or any of Luigis code for > that matter. Yes; this is an excellent example of how it can be done better. Regards, Mike -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 7 12:44:34 2001 Delivered-To: freebsd-net@freebsd.org Received: from inje.iskon.hr (inje.iskon.hr [213.191.128.16]) by hub.freebsd.org (Postfix) with ESMTP id 8360B37B41C; Fri, 7 Dec 2001 12:44:25 -0800 (PST) Received: from tel.fer.hr (zg07-209.dialin.iskon.hr [213.191.150.210]) by mail.iskon.hr (8.11.4/8.11.4/Iskon 8.11.3-1) with ESMTP id fB7Ki9O17119; Fri, 7 Dec 2001 21:44:12 +0100 (MET) Message-ID: <3C112A14.21F08D50@tel.fer.hr> Date: Fri, 07 Dec 2001 21:44:04 +0100 From: Marko Zec X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mike Smith Cc: Poul-Henning Kamp , arch@freebsd.org, net@freebsd.org Subject: Re: Request to back out Luigis polled-net patch in -stable. References: <200112071926.fB7JQx301437@mass.dis.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Mike Smith wrote: > > Subject: Request to back out Luigis polled-net patch in -stable. > > I'm entirely in agreement with this; the decision to commit this code was > extremely ill-advised, and the best thing we can do now for everyone's > sake is to pull it as quickly as possible. > > > I would also like to point to the parallel piece of code: Jun-Itohs > > ALTQ for which he reliably has maintained a patch relative to the > > 4.X branch and which despite various peoples requests have not > > haphazardly been committed into -stable. And in that context one > > should not forget that ALTQ has a lot longer and better trackrecord > > of high quality than Luigis poll-code, or any of Luigis code for > > that matter. > > Yes; this is an excellent example of how it can be done better. Sorry guys, but aren't you comparing apples with oranges? As far as I understand, ALTQ is focused on implementing various new queuing disciplines, but on outgoing traffic if I am not mistaking. Luigi's code is aimed on achieving something completely different - making the system more susceptible to huge *incoming* traffic loads, by reducing interrupt processing and some PCI bus overhead. What do these two things have in common? Concerning the request for removal of the polling code, I personally as a BSD rookie cannot judge your arguments properly, but I must admit that the wording and intonation of pkh's note wasn't very pleasant... Marko To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 7 13:22:18 2001 Delivered-To: freebsd-net@freebsd.org Received: from munin.odin-corporation.com (munin.odin-corporation.com [216.233.173.18]) by hub.freebsd.org (Postfix) with ESMTP id 78F6137B416 for ; Fri, 7 Dec 2001 13:22:07 -0800 (PST) Received: from odin-corporation.com (localhost [127.0.0.1]) by munin.odin-corporation.com (8.11.3/8.11.1) with ESMTP id fB7LM1Q35635 for ; Fri, 7 Dec 2001 15:22:01 -0600 (CST) (envelope-from lars@odin-corporation.com) Message-ID: <3C1132F8.AF4BF927@odin-corporation.com> Date: Fri, 07 Dec 2001 15:22:01 -0600 From: Lars Fredriksen Organization: Odin Corporation X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: no, en MIME-Version: 1.0 To: net@freebsd.org Subject: specifying interface to route command broken?? Content-Type: multipart/mixed; boundary="------------E8145C52065AA3D67DCADF36" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a multi-part message in MIME format. --------------E8145C52065AA3D67DCADF36 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > Hi, > > I am probably screwing something up :-) > > netstat -rn shows: > > Internet: > Destination Gateway Flags Refs Use Netif > Expire > 127.0.0.1 127.0.0.1 UH 4 31 lo0 > aaa.bbb.ccc.16/28 link#5 UC 1 0 wi0 => > > aaa.bbb.ccc.17 aaa.bbb.ccc.27 UHS 1 0 wi0 > > ifconfig -a shows: > > fxp0: flags=8802 mtu 1500 > inet aaa.bbb.ccc.26 netmask 0xfffffff0 broadcast 216.233.173.31 > ether 08:00:46:05:95:32 > media: autoselect (10baseT/UTP) status: active > supported media: autoselect 100baseTX 100baseTX > 10baseT/UTP 10baseT/UTP 100baseTX > lp0: flags=8810 mtu 1500 > lo0: flags=8049 mtu 16384 > inet 127.0.0.1 netmask 0xff000000 > ppp0: flags=8010 mtu 1500 > wi0: flags=8843 mtu 1500 > inet aaa.bbb.ccc.27 netmask 0xfffffff0 broadcast 216.233.173.31 > ether 00:02:2d:3a:4c:fd > > I am trying to add a default route to go to aaa.bbb.ccc.17 via the wi0 > interface, but it appears that since the fxp0 interface was configured > first (even though it is down at the moment) that the route always ends > up going through it! > > I tried: > > route add -ifa aaa.bbb.ccc.27 default aaa.bbb.ccc.17 > > but the default route still showed up as going through the fxp0 > interface. Anyone see what I might be doing wrong with the route command > here, or is it broken? This is on current as of 05/01/01.... > > Lars --------------E8145C52065AA3D67DCADF36 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: Received: from localhost (localhost) by munin.odin-corporation.com (8.11.3/8.11.1) id fB7LCfQ35562; Fri, 7 Dec 2001 15:12:41 -0600 (CST) (envelope-from MAILER-DAEMON) Date: Fri, 7 Dec 2001 15:12:41 -0600 (CST) From: Mail Delivery Subsystem Message-Id: <200112072112.fB7LCfQ35562@munin.odin-corporation.com> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="fB7LCfQ35562.1007759561/munin.odin-corporation.com" Subject: Returned mail: see transcript for details Auto-Submitted: auto-generated (failure) X-Mozilla-Status2: 00000000 This is a MIME-encapsulated message --fB7LCfQ35562.1007759561/munin.odin-corporation.com The original message was received at Fri, 7 Dec 2001 15:12:40 -0600 (CST) from localhost [127.0.0.1] ----- The following addresses had permanent fatal errors ----- (reason: 550 Host unknown) ----- Transcript of session follows ----- 550 5.1.2 ... Host unknown (Name server: freebsd: host not found) --fB7LCfQ35562.1007759561/munin.odin-corporation.com Content-Type: message/delivery-status Reporting-MTA: dns; munin.odin-corporation.com Received-From-MTA: DNS; localhost Arrival-Date: Fri, 7 Dec 2001 15:12:40 -0600 (CST) Final-Recipient: RFC822; net@freebsd Action: failed Status: 5.1.2 Remote-MTA: DNS; freebsd Diagnostic-Code: SMTP; 550 Host unknown Last-Attempt-Date: Fri, 7 Dec 2001 15:12:41 -0600 (CST) --fB7LCfQ35562.1007759561/munin.odin-corporation.com Content-Type: message/rfc822 Return-Path: Received: from odin-corporation.com (localhost [127.0.0.1]) by munin.odin-corporation.com (8.11.3/8.11.1) with ESMTP id fB7LCeQ35560 for ; Fri, 7 Dec 2001 15:12:40 -0600 (CST) (envelope-from lars@odin-corporation.com) Sender: lars Message-ID: <3C1130C7.9F28ABBC@odin-corporation.com> Date: Fri, 07 Dec 2001 15:12:39 -0600 From: Lars Fredriksen Organization: Odin Corporation X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: no, en MIME-Version: 1.0 To: net@freebsd Subject: specifying interface to route command broken?? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I am probably screwing something up :-) netstat -rn shows: Internet: Destination Gateway Flags Refs Use Netif Expire 127.0.0.1 127.0.0.1 UH 4 31 lo0 aaa.bbb.ccc.16/28 link#5 UC 1 0 wi0 => aaa.bbb.ccc.17 aaa.bbb.ccc.27 UHS 1 0 wi0 ifconfig -a shows: fxp0: flags=8802 mtu 1500 inet aaa.bbb.ccc.26 netmask 0xfffffff0 broadcast 216.233.173.31 ether 08:00:46:05:95:32 media: autoselect (10baseT/UTP) status: active supported media: autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP 100baseTX lp0: flags=8810 mtu 1500 lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 ppp0: flags=8010 mtu 1500 wi0: flags=8843 mtu 1500 inet aaa.bbb.ccc.27 netmask 0xfffffff0 broadcast 216.233.173.31 ether 00:02:2d:3a:4c:fd I am trying to add a default route to go to aaa.bbb.ccc.17 via the wi0 interface, but it appears that since the fxp0 interface was configured first (even though it is down at the moment) that the route always ends up going through it! I tried: route add -ifa aaa.bbb.ccc.27 default aaa.bbb.ccc.17 but the default route still showed up as going through the fxp0 interface. Anyone see what I might be doing wrong with the route command here, or is it broken? This is on current as of 05/01/01.... Lars --fB7LCfQ35562.1007759561/munin.odin-corporation.com-- --------------E8145C52065AA3D67DCADF36-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 7 13:50:54 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 3DEF437B405; Fri, 7 Dec 2001 13:50:49 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.11.3/8.11.3) with ESMTP id fB7Lns1135628; Fri, 7 Dec 2001 16:49:54 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <3C112A14.21F08D50@tel.fer.hr> References: <200112071926.fB7JQx301437@mass.dis.org> <3C112A14.21F08D50@tel.fer.hr> Date: Fri, 7 Dec 2001 16:49:51 -0500 To: Marko Zec , Mike Smith From: Garance A Drosihn Subject: Re: Request to back out Luigis polled-net patch in -stable. Cc: Poul-Henning Kamp , arch@FreeBSD.ORG, net@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org At 9:44 PM +0100 12/7/01, Marko Zec wrote: >Mike Smith wrote: > > > I would also like to point to the parallel piece of code: Jun-Itohs >> > ALTQ for which he reliably has maintained a patch relative to the >> > 4.X branch and which despite various peoples requests have not > > > haphazardly been committed into -stable. > > >> Yes; this is an excellent example of how it can be done better. > >Sorry guys, but aren't you comparing apples with oranges? They are comparing how two changes were made. Not what the changes actually *do*, but the path the changes took to get into -stable. In that sense, they are not comparing apples to oranges. They are comparing the conveyor belts under the apples vs the conveyor belts the oranges were allowed to use. >Concerning the request for removal of the polling code, I personally >as a BSD rookie cannot judge your arguments properly, but I must >admit that the wording and intonation of pkh's note wasn't very >pleasant... Poul-Henning included one comment about "track records" which may have been a bit harsh, but if you ignore that one sentence than everything he said seemed pretty reasoned (ie, "calmly thought out", as opposed to "emotional outburst"), and pretty reasonable. I think PHK and Mike Smith have made a pretty good case, but I will admit that I don't know all of the issues involved. I suspect the other side of this debate is that Luigi's change is meant for high-load situations, and very very very few people are running a 5.0-current system in those kinds of high-load situations. I can see that being a good reason to put it in stable, but even with this good reason, I think it might be better to back the change out of stable until AFTER 4.5 is released. This change did not go thru the "normal routine" for changes, and as such I do think any developer has the right to make a case that the change should be backed out. I *like* what the change is trying to do, and the methods it is using certainly sound interesting. But I don't think it would hurt to have it looked over a bit more before committing it to -stable. That's just my opinion, as I watch this debate from the sidelines. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 7 14:37:15 2001 Delivered-To: freebsd-net@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id BF14837B41A; Fri, 7 Dec 2001 14:37:05 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.6/8.11.6) with ESMTP id fB7MZHj30558; Fri, 7 Dec 2001 23:35:17 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Garance A Drosihn Cc: Marko Zec , Mike Smith , arch@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: Request to back out Luigis polled-net patch in -stable. In-Reply-To: Your message of "Fri, 07 Dec 2001 16:49:51 EST." Date: Fri, 07 Dec 2001 23:35:17 +0100 Message-ID: <30556.1007764517@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In message , Garance A Drosihn writes: >Poul-Henning included one comment about "track records" which may >have been a bit harsh, but if you ignore that one sentence than >everything he said seemed pretty reasoned (ie, "calmly thought out", >as opposed to "emotional outburst"), and pretty reasonable. I would like to defend that comment, and I apologize for it sounding harsh, it was simply meant as a flat statement of fact on my part. We have committers in the project who gets things right the first time around, every time, on time, on schedule, under budget and with a global reduction of green-house gasses as a side effect. When Bruce Evans commits something one can virtually rest assured that it has been throughly tested ever since he originally wrote it in 1974 and that several satelites and ICBMs wouldn't work and the cold war would not have ended without that patch. Then we have other committers who drag a trail of death and destruction through a sequence of more and more frantic commits until they finally (by accident ?) gets it right enough that the tree isn't broken anymore. (I wont mention names here). These are the two extremes, between them you will find the rest of us. Now, for something to go into -stable, there are certain standards, we have haggled over them from time to time. For a new feature to go into -stable, there has to be very very good reasons not to take the detour around -current. In particular there has to be a very good and convincing argument that something _will_ go into -current, so that we don't introduce a feature in -stable which the next major release will simply not have: We don't need to disappoint our users any more than we need to with our major releases. Luigi has a track record of delivering some very smart code to FreeBSD, I'm a big fan of his IPFW and DUMMYNET stuff, and I far prefer them to IPFILTER. I even think Luigi is a great guy, and I'm happy to see him being a "Professor of FreeBSD Networking" (well, not quite but...) at his University in Italy. But that doesn't change the fact that Luigis code has never been a "working first time thing wihtout a hitch" for us. There has always been some issues to work out, some things to move around a bit, things which need a bit of generalization and so on. In other words: Luigi is a perfectly normal FreeBSD committer. And that means that he should follow the rules we have for -stable: he doesn't clear the bar to cold commit a new feature into -stable. In particular it should not when it is not convincingly argued that we will be able to integrate the new features in -current any time soon. That's all. I'm not against his code, I just don't want it to go straight into -stable. If the argument holds that -stable and -current has diverged too much for it being feasible to go the usual "into -current, then MFC" walk, then we need to reexamine the entire "-current/-stable" setup and maybe add a 4-CURRENT development-branch from which things get merged to 4-STABLE. (Having worked in multi-branch environments like that, I would be strongly against any such thing and I think anyone who has tried to navigate the cisco IOS version maelström in recent years are likely to be against as well). So in summary my position is: Luigi stuff should be backed out of -stable. Luigi should figure out how to do this right in SMPng/-current and implement it there. Then when we have some experience with it, we can decide on a rational basis if it should be MFC'ed, (or committed cold into -stable if the MFC doesn't make sense). And of course Luigi is more than welcome to distribute his change as a patch against -stable, just like Jun-Itoh does with his ALTQ. (I don't know if Peter has -stable in P4, but that could be one way to make it easier for Luigi to maintain the patch if he had a branch there) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 7 15:43:48 2001 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (f31.law3.hotmail.com [209.185.241.31]) by hub.freebsd.org (Postfix) with ESMTP id C8F1437B405 for ; Fri, 7 Dec 2001 15:43:43 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 7 Dec 2001 15:43:43 -0800 Received: from 213.225.121.247 by lw3fd.law3.hotmail.msn.com with HTTP; Fri, 07 Dec 2001 23:43:43 GMT X-Originating-IP: [213.225.121.247] From: "Thor Legvold" To: lars@odin-corporation.com Cc: net@freebsd.org Subject: Re: specifying interface to route command broken?? Date: Fri, 07 Dec 2001 23:43:43 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 07 Dec 2001 23:43:43.0708 (UTC) FILETIME=[019029C0:01C17F79] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Lars wrote: > > > > Hi, > > > > I am probably screwing something up :-) > > > > netstat -rn shows: > > > > Internet: > > Destination Gateway Flags Refs Use Netif > > Expire > > 127.0.0.1 127.0.0.1 UH 4 31 lo0 > > aaa.bbb.ccc.16/28 link#5 UC 1 0 wi0 => > > > > aaa.bbb.ccc.17 aaa.bbb.ccc.27 UHS 1 0 wi0 You have no default route at startup? > > ifconfig -a shows: > > > > fxp0: flags=8802 mtu 1500 > > inet aaa.bbb.ccc.26 netmask 0xfffffff0 broadcast 216.233.173.31 > > ether 08:00:46:05:95:32 > > media: autoselect (10baseT/UTP) status: active > > supported media: autoselect 100baseTX 100baseTX > > 10baseT/UTP 10baseT/UTP 100baseTX > > lp0: flags=8810 mtu 1500 > > lo0: flags=8049 mtu 16384 > > inet 127.0.0.1 netmask 0xff000000 > > ppp0: flags=8010 mtu 1500 > > wi0: flags=8843 mtu 1500 > > inet aaa.bbb.ccc.27 netmask 0xfffffff0 broadcast 216.233.173.31 > > ether 00:02:2d:3a:4c:fd > > > > I am trying to add a default route to go to aaa.bbb.ccc.17 via the wi0 > > interface, but it appears that since the fxp0 interface was configured My experience is that if you want to add a new/different default route, you need to delete the existing one first. > > first (even though it is down at the moment) that the route always ends > > up going through it! Why not specify the interface on the route command line, then? > > I tried: > > > > route add -ifa aaa.bbb.ccc.27 default aaa.bbb.ccc.17 > > > > but the default route still showed up as going through the fxp0 > > interface. Anyone see what I might be doing wrong with the route command > > here, or is it broken? This is on current as of 05/01/01.... I'm running 4.4-Stable, and as I recall (I'm on another host at the moment) the route command accepts an option to specify the interface (wi0 in your case). Have you tried "# man route"...? > > Lars Regards, Thor -- who also has a default route via a wi0 iface... :-) _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 7 16:11:18 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 5DDFF37B405; Fri, 7 Dec 2001 16:11:12 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.3/8.11.1) id fB80BCD85704; Fri, 7 Dec 2001 16:11:12 -0800 (PST) (envelope-from rizzo) Date: Fri, 7 Dec 2001 16:11:12 -0800 From: Luigi Rizzo To: stable@freebsd.org Subject: HEADS-UP: polling code removed. Message-ID: <20011207161112.B85611@iguana.aciri.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.23i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org [Bcc to net@freebsd.org] FYI ... cheers luigi ----- Forwarded message from Luigi Rizzo ----- Date: Fri, 7 Dec 2001 16:04:16 -0800 (PST) From: Luigi Rizzo Subject: cvs commit: src/sys/conf options.i386 src/sys/dev/fxp if_fxp.c src/sys/i386/i386 swtch.s trap.c src/sys/i386/include asnames.h src/sys/kern kern_clock.c src/sys/net if.h netisr.h src/sys/pci if_dc.c if_dcreg.h if_sis.c if_sisreg.h src/sys/sys systm.h To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org luigi 2001/12/07 16:04:16 PST Modified files: (Branch: RELENG_4) sys/conf options.i386 sys/dev/fxp if_fxp.c sys/i386/i386 swtch.s trap.c sys/i386/include asnames.h sys/kern kern_clock.c sys/net if.h netisr.h sys/pci if_dc.c if_dcreg.h if_sis.c if_sisreg.h sys/sys systm.h Log: By loud (and maybe popular) demand, back out the device polling code, so we will not risk to lose this feature when -current is released, we lose it now. For those interested, the full story is archived in tne cvs-all and freebsd-net mailing lists, and maybe in some future core monthly report. Revision Changes Path 1.132.2.10 +0 -5 src/sys/conf/options.i386 1.110.2.13 +4 -59 src/sys/dev/fxp/if_fxp.c 1.89.2.6 +0 -4 src/sys/i386/i386/swtch.s 1.147.2.7 +0 -5 src/sys/i386/i386/trap.c 1.44.2.5 +0 -1 src/sys/i386/include/asnames.h 1.105.2.6 +0 -253 src/sys/kern/kern_clock.c 1.58.2.4 +0 -9 src/sys/net/if.h 1.21.2.4 +0 -1 src/sys/net/netisr.h 1.9.2.29 +0 -81 src/sys/pci/if_dc.c 1.4.2.13 +0 -4 src/sys/pci/if_dcreg.h 1.13.4.14 +0 -72 src/sys/pci/if_sis.c 1.1.4.6 +0 -3 src/sys/pci/if_sisreg.h 1.111.2.12 +0 -14 src/sys/sys/systm.h ----- End forwarded message ----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 7 16:32:21 2001 Delivered-To: freebsd-net@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id B5C5837B416; Fri, 7 Dec 2001 16:32:17 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.3) with ESMTP id fB80b8304059; Fri, 7 Dec 2001 16:37:13 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200112080037.fB80b8304059@mass.dis.org> To: Marko Zec Cc: Poul-Henning Kamp , arch@freebsd.org, net@freebsd.org Subject: Re: Request to back out Luigis polled-net patch in -stable. In-Reply-To: Message from Marko Zec of "Fri, 07 Dec 2001 21:44:04 +0100." <3C112A14.21F08D50@tel.fer.hr> Date: Fri, 07 Dec 2001 16:37:08 -0800 From: Mike Smith Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > > I would also like to point to the parallel piece of code: Jun-Itohs > > > ALTQ for which he reliably has maintained a patch relative to the ... > > Yes; this is an excellent example of how it can be done better. > > Sorry guys, but aren't you comparing apples with oranges? As far as I No. The issue at hand is procedure, not functionality. ALTQ is maintained and developed in a fashion consistent with the Project's general procedures and preferences. Luigi's code commit was not. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 7 17:14:47 2001 Delivered-To: freebsd-net@freebsd.org Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by hub.freebsd.org (Postfix) with ESMTP id 1AE1937B416 for ; Fri, 7 Dec 2001 17:14:45 -0800 (PST) Received: from dialup-209.245.131.254.dial1.sanjose1.level3.net ([209.245.131.254] helo=blossom.cjclark.org) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 16CW4i-00000O-00; Fri, 07 Dec 2001 17:14:44 -0800 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.3) id fB81EgL20664; Fri, 7 Dec 2001 17:14:42 -0800 (PST) (envelope-from cjc) Date: Fri, 7 Dec 2001 17:14:42 -0800 From: "Crist J . Clark" To: Pranay Cc: freebsd-net@FreeBSD.ORG Subject: Re: NAT and ALG Message-ID: <20011207171442.V8975@blossom.cjclark.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from p_tembhekar@hotmail.com on Fri, Dec 07, 2001 at 10:24:50AM +0530 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Dec 07, 2001 at 10:24:50AM +0530, Pranay wrote: > Hi All, > How does the NAT in the ip_nat.c take care of FTP port and PASV commands? See ip_ftp_pxy.c. For in depth IPFilter discussion, ipfilter@coombs.anu.edu.au is probably a better list. -- "It's always funny until someone gets hurt. Then it's hilarious." Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 7 23:35:51 2001 Delivered-To: freebsd-net@freebsd.org Received: from D00015.dialonly.kemerovo.su (www2.svzserv.kemerovo.su [213.184.65.86]) by hub.freebsd.org (Postfix) with ESMTP id 2FEB137B419; Fri, 7 Dec 2001 23:35:43 -0800 (PST) Received: from svzserv.kemerovo.su (localhost.dialonly.kemerovo.su [127.0.0.1]) by D00015.dialonly.kemerovo.su (8.11.6/8.11.4) with ESMTP id fB87XVU01155; Sat, 8 Dec 2001 14:33:31 +0700 (KRAT) (envelope-from eugen@svzserv.kemerovo.su) Message-ID: <3C11C24B.A980A646@svzserv.kemerovo.su> Date: Sat, 08 Dec 2001 14:33:31 +0700 From: Eugene Grosbein Organization: SVZServ X-Mailer: Mozilla 4.76 [ru] (X11; U; FreeBSD 4.4-STABLE i386) X-Accept-Language: ru, en MIME-Version: 1.0 To: Ruslan Ermilov Cc: net@FreeBSD.ORG, security@FreeBSD.ORG Subject: Re: NOARP - gateway must answer and have frozen ARP table References: <20011205124430.A83642@svzserv.kemerovo.su> <20011205040316.H40864@blossom.cjclark.org> <20011205231735.A1361@grosbein.pp.ru> <20011205193859.B79705@sunbay.com> <200112051835.fB5IZqH95521@whizzo.transsys.com> <20011205204526.B89520@sunbay.com> <200112051852.fB5IqmH95809@whizzo.transsys.com> <20011205121928.A3061@blossom.cjclark.org> <200112062059.MAA02282@windsor.research.att.com> <20011207110542.J13705@sunbay.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > OK, I have a proposal that should fit both opinions. I'll keep the > net.link.ether.inet.static_arp to mean what it means now (keep ARP > table static, no updates except from local process through a routing > socket writes), and will add another sysctl that will switch the > meaning of IFF_NOARP from "no arp" to "static arp on this interface". > How about this? This would be the best souliution at least for us :-) Eugene Grosbein To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 7 23:52:19 2001 Delivered-To: freebsd-net@freebsd.org Received: from D00015.dialonly.kemerovo.su (www2.svzserv.kemerovo.su [213.184.65.86]) by hub.freebsd.org (Postfix) with ESMTP id 8E62C37B416; Fri, 7 Dec 2001 23:52:11 -0800 (PST) Received: from svzserv.kemerovo.su (localhost.dialonly.kemerovo.su [127.0.0.1]) by D00015.dialonly.kemerovo.su (8.11.6/8.11.4) with ESMTP id fB87pil01437; Sat, 8 Dec 2001 14:51:44 +0700 (KRAT) (envelope-from eugen@svzserv.kemerovo.su) Message-ID: <3C11C690.A520577@svzserv.kemerovo.su> Date: Sat, 08 Dec 2001 14:51:44 +0700 From: Eugene Grosbein Organization: SVZServ X-Mailer: Mozilla 4.76 [ru] (X11; U; FreeBSD 4.4-STABLE i386) X-Accept-Language: ru, en MIME-Version: 1.0 To: cjclark@alum.mit.edu Cc: Bill Fenner , net@FreeBSD.ORG, security@FreeBSD.ORG Subject: Re: NOARP - gateway must answer and have frozen ARP table References: <20011205124430.A83642@svzserv.kemerovo.su> <20011205040316.H40864@blossom.cjclark.org> <20011205231735.A1361@grosbein.pp.ru> <20011205193859.B79705@sunbay.com> <200112051835.fB5IZqH95521@whizzo.transsys.com> <20011205204526.B89520@sunbay.com> <200112051852.fB5IqmH95809@whizzo.transsys.com> <20011205121928.A3061@blossom.cjclark.org> <200112062059.MAA02282@windsor.research.att.com> <20011206231401.N8975@blossom.cjclark.org> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > If this is really want to do, I believe you can do it with existing > tools. > > For simplicity, I'm just going to illustrate a way to set it up rather > than explain it. Store your IP-MAC address pairs in flat file as > proscribed in arp(8), > > 192.168.10.2 01:02:03:10:11:12 > 192.168.10.4 01:02:03:21:22:23 > ... > > Load your permanent ARP table with a simple, > > arp -f arp_list.txt > > In the startup and include, > > while read $IP $MAC; do > ipfw add pass ip from $IP to any via if0 > ipfw add pass ip from any to $IP via if0 > done < arp_list.txt > > ipfw add deny ip from any to any via if0 > > In your rc.firewall. > > Now you have a static ARP table and all traffic not from those IP > addresses is blocked. Since we never ARP for any other addresses, the > packets are blocked before we ARP for them, we never get other entries > in the ARP table. Yes, this should work. But we have many clients at the interface and IPFW table pollution is undesirable. This also increases complexity of IPWF configuration and this complexity seems to be ill-founded (at least for me) as we have a way to ignore APR. At the other hand ingorance of false ARP replies will make ARP spoofing useless at least if MAC addresses have not changed. Administrative arrangements and arpwatch helps us to deal with such klever users. > At least I think this should do what you want. I still am not quite > sure what a "one-way ARP" is supposed to gain. We need gateway be usable for our clients without forcing them to use static ARP themselves. We do not want to see unregistered machines in public segment. We also will be happy keeping our registration procedures, configs and kernel tables as simple as possible. Sysctl changing the meaning of IFF_NOARP flags would be nice solution. Eugene Grosbein To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Dec 8 9:11:39 2001 Delivered-To: freebsd-net@freebsd.org Received: from berbee.com (berbee.com [205.173.176.16]) by hub.freebsd.org (Postfix) with ESMTP id 977A737B416; Sat, 8 Dec 2001 09:11:33 -0800 (PST) Received: from Debug (berbee.com [205.173.176.16]) by berbee.com (8.11.2/8.11.2) with SMTP id fB8HBXd00931; Sat, 8 Dec 2001 11:11:33 -0600 Message-Id: <200112081711.fB8HBXd00931@berbee.com> To: questions@freebsd.org Cc: net@freebsd.org From: zietlow@berbee.com Subject: Really Weird Network issue. Date: Sat, 8 Dec 2001 17:11:33 GMT X-Mailer: Endymion MailMan Standard Edition v3.0.22 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Sorry for the cross post, but I wasn't sure which group would be able to answer this better. This is a REALLy weird issue I am having. So here it goes. My internal LAN was working fine last week. I went to work, and while I was there, I ran a make world on my laptop. It's running FreeBSD 4.4-stable. Had no issues. Fast forward today, I finish my work week and bring my laptop home. I I try to connect up to my network and get outside onto my cable modem I cannot talk to my gateway router via any other means than udp and icmp. My /etc/hosts is the same as it always has been, they are identical on both machines (except for the laptop which has some extra settings for the work lan. Totally different subnet). I thought this was a TCP issue, still could be, here are is the wackiness about this issue. I have a switched 100 base T cabling network with 6 comptuers on it, 2 windows (1 gaming, 1 dial up laptop), 2 debian (1 DHCP/back up, 1 File server), 2 FreeBSD (laptop and gateway). ALL computers can ping each other. Every computer except the laptop can SSH, telnet, http, and FTP into the gateway. The laptop can do all of these to every box on the network except the Gateway. The Gateway can ssh, telnet, http, and ftp into the laptop and every other machine on the network. I can ssh from the laptop to another computer on the network then SSH into the gateway. I cannot however SSH from the laptop to the gateway directly. I CAN ssh from the Gateway to the laptop directly though. SSH just hangs, eventually I get "Secure connection to 192.168.1.1 refused" Telnet just hangs, I get "telnet: unable to connect to host 192.168.1.1:Operation timed out" "unable to connect to remote host" FTP just hangs, NMAP TCP scan just hangs. nmap udp scan works. I can ping using Hostnames setup in /etc/hosts, I can ping via IPs. name resolution isn't an issue. Firewall isn't an issue. I use ipf. I had "pass in all/pass out all" on respective lines in my ipf.rules file. In case it was a switch issue, I put just both computers on a hub I knew worked, same issues. When I run a tcpdump. I see the out going packets from the laptop, but no response packets from the gateway. Arp isn't an issue. I can arp just fine. Here are the uname -a for each box Gateway:"FreeBSD wiggum.the-rob.com 4.4-STABLE FreeBSD 4.4-STABLE #0: Sat Dec 8 09:59:09 CST 2001 zietlow@wiggum.the-rob.com:/usr/src/sys/compile/FIREWALL i386" Laptop:"FreeBSD Homer.the-rob.com 4.4-STABLE FreeBSD 4.4-STABLE #6: Sat Dec 8 10:40:07 CST 2001 zietlow@Homer.the-rob.com:/usr/src/sys/compile/NEWKERNEL i386" If you've stayed with me this long, any ideas? I am stumped. If you need anymore info I will happily supply it. I think it's some weird tcp issue. Hints, thoughts, pointers? Thanks for listening and helping Rob To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Dec 8 11:11:45 2001 Delivered-To: freebsd-net@freebsd.org Received: from a.mx.everquick.net (a.mx.everquick.net [216.89.137.3]) by hub.freebsd.org (Postfix) with ESMTP id 6721B37B426; Sat, 8 Dec 2001 11:10:47 -0800 (PST) Received: from localhost (eddy@localhost) by a.mx.everquick.net (8.11.6/8.10.2) with ESMTP id fB8JAlV05522; Sat, 8 Dec 2001 19:10:47 GMT X-EverQuick-No-Abuse: Report any e-mail abuse to Date: Sat, 8 Dec 2001 19:10:46 +0000 (GMT) From: "E.B. Dreger" To: net@freebsd.org, smp@freebsd.org Subject: dc watchdog timeout on 4.4-R Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Greetings all, Sorry for the hefty cross-post... I've been digging through archives, and it seems that there was talk of this on -current late October of 2000, including speculation that this was an SMPng issue. I'm running a D-Link DFE570TX four-port dc (21143xx, where xx is TD if memory serves) on a dual-PII Micronics PTSAM motherboard. See /var/run/dmesg.boot following .signature for details. After my machine runs successfully for some while, I receive continuous "watchdog timeout" messages on a 10baseT/UTP HDX dc port. It doesn't seem to happen on 100baseTX FDX ports; however, being an infrequent event, I cannot vouch for the statistical validity of this claim. Once I receive these timeouts, "netstat -I dc3 -w 1" shows an output error each time I try to send traffic. A reboot is the only "cure" that I have found... i.e., it's not a cable issue. I don't recall experiencing this 4.3-R; I believe that I used the same motherboard for three months under 4.3-R, and that this is a new event since upgrading to 4.4-R. However, I'm a bit fuzzy on this, too. Anyone have any ideas? Please keep me CCed. I'm not currently subscribed. My email address is valid. However, please un-CC lists as appropriate -- if this is an SMP issue, I don't want to chew up -net, or vice versa. Again, I apologize for the large crosspost, but it's unclear to me which avenue is the correct one... TIA, Eddy --------------------------------------------------------------------------- Brotsman & Dreger, Inc. - EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --------------------------------------------------------------------------- Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.4-RELEASE #1: Wed Oct 31 14:19:51 GMT 2001 root@kaetzchen.brotsman.test:/usr/src/sys/compile/KAETZCHEN Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Pentium II Xeon/Celeron (267.27-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x634 Stepping = 4 Features=0x80fbff real memory = 134217728 (131072K bytes) avail memory = 127569920 (124580K bytes) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee00000 cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee00000 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec00000 Preloaded elf kernel "kernel" at 0xc0305000. Pentium Pro MTRR support enabled Using $PIR table, 6 entries at 0xc00f6380 npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard IOAPIC #0 intpin 19 -> irq 2 pci0: on pcib0 isab0: at device 1.0 on pci0 isa0: on isab0 atapci0: port 0xfcd0-0xfcdf at device 1.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: at 1.2 irq 2 Timecounter "PIIX" frequency 3579545 Hz chip0: port 0x2180-0x218f at device 1.3 on pci0 sym0: <875> port 0xf800-0xf8ff mem 0xfebfe000-0xfebfefff,0xfebff800-0xfebff8ff irq 16 at device 17.0 on pci0 sym0: Symbios NVRAM, ID 7, Fast-20, SE, parity checking sym0: open drain IRQ line driver, using on-chip SRAM sym0: using LOAD/STORE-based firmware. sym0: SCAN AT BOOT disabled for targets 1 2 3 4 5 6 8 9 10 11 12 13 14 15. sym0: SCAN FOR LUNS disabled for targets 0 1 2 3 4 5 6 8 9 10 11 12 13 14 15. pci0: at 18.0 irq 17 pcib2: at device 19.0 on pci0 pci1: on pcib2 dc0: port 0xec00-0xec7f mem 0xfdfff800-0xfdfffbff irq 2 at device 4.0 on pci1 dc0: Ethernet address: 00:80:c8:f8:7b:50 miibus0: on dc0 ukphy0: on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc1: port 0xe880-0xe8ff mem 0xfdfff400-0xfdfff7ff irq 18 at device 5.0 on pci1 dc1: Ethernet address: 00:80:c8:f8:7b:51 miibus1: on dc1 ukphy1: on miibus1 ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc2: port 0xe800-0xe87f mem 0xfdfff000-0xfdfff3ff irq 17 at device 6.0 on pci1 dc2: Ethernet address: 00:80:c8:f8:7b:52 miibus2: on dc2 ukphy2: on miibus2 ukphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc3: port 0xe480-0xe4ff mem 0xfdffec00-0xfdffefff irq 16 at device 7.0 on pci1 dc3: Ethernet address: 00:80:c8:f8:7b:53 miibus3: on dc3 ukphy3: on miibus3 ukphy3: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto atapci1: irq 0 at device 25.1 on pci0 atapci1: Busmastering DMA not supported pci0: (vendor=0xffff, dev=0x0000) at 25.2 pci0: (vendor=0xffff, dev=0x0000) at 25.3 pci0: (vendor=0xffff, dev=0x0000) at 25.4 pci0: (vendor=0xffff, dev=0x0000) at 25.5 pci0: (vendor=0xffff, dev=0x0000) at 25.6 pci0: (vendor=0xffff, dev=0x0000) at 25.7 pcib1: on motherboard pci2: on pcib1 orm0: