From owner-freebsd-net Mon Sep 25 10:55:46 2000 Delivered-To: freebsd-net@freebsd.org Received: from xena.gsicomp.on.ca (cr677933-a.ktchnr1.on.wave.home.com [24.42.130.87]) by hub.freebsd.org (Postfix) with ESMTP id A582437B422; Mon, 25 Sep 2000 10:55:36 -0700 (PDT) Received: from localhost (matt@localhost) by xena.gsicomp.on.ca (8.10.1/8.9.2) with SMTP id e8PHtQY79329; Mon, 25 Sep 2000 13:55:27 -0400 (EDT) (envelope-from matt@xena.gsicomp.on.ca) Date: Mon, 25 Sep 2000 13:55:26 -0400 (EDT) From: Matthew Emmerton To: treif1@netaxs.com Cc: matt@gsicomp.on.ca, questions@freebsd.org, net@freebsd.org Subject: Re: tarpitting bad HTTP requests (WAS: RE: question) In-Reply-To: <39CF7542.9795E517@reif.cncdsl.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [ crossposting to freebsd-net since this concerns TCP connection limiting ] On Mon, 25 Sep 2000, webmaster wrote: > Well, thats just it. > I'm thinking if I can slow down the attacks then have the > perl program wite a redirect to the htaccess it will save > resources. In other words, I have a random mix of proxy > servers and script kiddies hitting this server. > All of them are on very fast connections and sometimes > will hit the server 30,000 times each before the software > can redirect them. If I can find a way to slow the attacks > the perl program can then execute and redirect without using > up all these resources or generating thousands of logs. There are really two issues to this problem: - how to detect people who are flooding the server - how to handle those who are. If there is some type of distinct pattern of URLs that originate from a single host, then that can be captured. However, I doubt this so the only resort is to have some sort of threshold on the number of times a single client can connect to the server during a specific timeframe. Although this could be implemented in the web server, there are problems: - the threshold would have to be keyed to the website so that sites that legally go out and pick up the HTML, then send out n parallel requests (one for each graphic) won't be restricted. - the information on clients would have to be shared across all server instances, as people hammering the server will most likely have requested processed by all instances The better place to implement this kind of 'bandwidth control' would be at the kernel or network level, similar to how ICMP flooding is handled. Does anyone know of a way to control TCP flooding for servers that don't run from inetd and serve multiple client requests from one instance? (These two conditions are limitations of tcpwrappers) THe "how to control those who are" would be a user-defined hook, provided that it could be triggered by some sort (log message, for example) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Sep 26 2:32:33 2000 Delivered-To: freebsd-net@freebsd.org Received: from ns.bsag.ch (ns.bsag.ch [195.246.88.210]) by hub.freebsd.org (Postfix) with ESMTP id B2B9537B422 for ; Tue, 26 Sep 2000 02:32:29 -0700 (PDT) Received: (from hpr@localhost) by ns.bsag.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id LAA28241 for freebsd-net@freebsd.org; Tue, 26 Sep 2000 11:32:23 +0200 Date: Tue, 26 Sep 2000 11:32:23 +0200 From: Hanspeter Roth Bsag To: freebsd-net@freebsd.org Subject: ppp nat port/addr conflict Message-ID: <20000926113223.A28035@bs11.bsag.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, I'm trying to set up NAT to allow specific connections. The participating hosts are connected as follows: local client FreeBSD router remote host 1.0.0.2 <---> 1.0.0.1 2.0.0.1 <---> 2.0.0.2 ethernet ppp The local client has to connect to the remote host but with the router's address [1.0.0.2]. In the ppp.conf I have nat addr 1.0.0.2 2.0.0.1 This allows telnet and ftp connections from the local client [1.0.0.2] to the remote host [2.0.0.2]. (Interestingly I'm also able to connect to the remote host from the router itself.) Now I want a to allow a connection from the remote host to the router at a specific port. Thus I tried nat port tcp 2.0.0.1:6009 6009 127.0.0.1:6009 I'm aware that there is an address conflict since 2.0.0.1 is also diverted to the local client [1.0.0.2] by the `nat addr' command. I hoped that `nat port' would take precedence over `nat addr'. But packets to 2.0.0.1:6009 get diverted to the local client as well. Is there a means to resolve this conflict? -Hanspeter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Sep 26 4:50: 4 2000 Delivered-To: freebsd-net@freebsd.org Received: from vbook.express.ru (vbook.express.ru [212.24.37.106]) by hub.freebsd.org (Postfix) with ESMTP id AFF2937B422 for ; Tue, 26 Sep 2000 04:49:56 -0700 (PDT) Received: (from vova@localhost) by vbook.express.ru (8.9.3/8.9.3) id PAA74491; Tue, 26 Sep 2000 15:50:00 +0400 (MSD) (envelope-from vova) From: "Vladimir B. Grebenschikov" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14800.36198.753383.94082@vbook.express.ru> Date: Tue, 26 Sep 2000 15:49:58 +0400 (MSD) To: freebsd-net@freebsd.org Subject: netgraph question X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi ppl I need to transfer stream connections to AF_UNIX from one host to another host to tcp or AF_UNIX. So question is "Is it possible with netgraph ?". I've search a bit and don't found how to create new node automatic (something like accept()) If it not possible now is such functionality planned ? -- TSB Russian Express, Moscow Vladimir B. Grebenschikov, vova@express.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Sep 26 4:55:53 2000 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 9DA1D37B422 for ; Tue, 26 Sep 2000 04:55:47 -0700 (PDT) Received: from InterJet.elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id EAA09806; Tue, 26 Sep 2000 04:55:39 -0700 (PDT) Date: Tue, 26 Sep 2000 04:55:38 -0700 (PDT) From: Julian Elischer To: "Vladimir B. Grebenschikov" Cc: freebsd-net@freebsd.org Subject: Re: netgraph question In-Reply-To: <14800.36198.753383.94082@vbook.express.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Unfortunatly the way that AF_UNIX is implemented does not allow you to do this. literally the write code for one socket, puts the data directly on the receive queue of the other socket. Netgraph does not have any chance to intervene in this. (it would require the addition of netgraph code into the AF_UNIX code, and in fact that may be problematical due to spl levels and such. The only way I can thin would be o use a proxy, but it would be unable to do some of the things that AF_UNIX does, e.g. pass file descriptors. On Tue, 26 Sep 2000, Vladimir B. Grebenschikov wrote: > > Hi ppl > > I need to transfer stream connections to AF_UNIX from one host to > another host to tcp or AF_UNIX. > > So question is "Is it possible with netgraph ?". > > I've search a bit and don't found how to create new node automatic > (something like accept()) > > If it not possible now is such functionality planned ? > > -- > TSB Russian Express, Moscow > Vladimir B. Grebenschikov, vova@express.ru > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Sep 26 14: 3:31 2000 Delivered-To: freebsd-net@freebsd.org Received: from virtual.sysadmin-inc.com (lists.sysadmin-inc.com [209.16.228.140]) by hub.freebsd.org (Postfix) with ESMTP id A90B737B422 for ; Tue, 26 Sep 2000 14:03:28 -0700 (PDT) Received: from 98sas ([10.10.1.71]) by virtual.sysadmin-inc.com (8.9.1/8.9.1) with SMTP id RAA05137 for ; Tue, 26 Sep 2000 17:05:24 -0400 Reply-To: From: "Peter Brezny" To: Subject: interface traffic reporting Date: Tue, 26 Sep 2000 17:03:57 -0400 Message-ID: <001101c027fd$49e18720$47010a0a@fire.sysadmininc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org is there some way of getting real time network traffic information for the local interface on a freebsd 4.1-stable machine. Something like top, but only for network information. Thanks, Peter Brezny SysAdmin Services, Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Sep 26 14:22:45 2000 Delivered-To: freebsd-net@freebsd.org Received: from rapidnet.com (rapidnet.com [205.164.216.1]) by hub.freebsd.org (Postfix) with ESMTP id 4885437B423 for ; Tue, 26 Sep 2000 14:22:42 -0700 (PDT) Received: from localhost (nick@localhost) by rapidnet.com (8.9.3/8.9.3) with ESMTP id PAA13618; Tue, 26 Sep 2000 15:22:33 -0600 (MDT) Date: Tue, 26 Sep 2000 15:22:33 -0600 (MDT) From: Nick Rogness To: Peter Brezny Cc: freebsd-net@freebsd.org Subject: Re: interface traffic reporting In-Reply-To: <001101c027fd$49e18720$47010a0a@fire.sysadmininc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 26 Sep 2000, Peter Brezny wrote: > is there some way of getting real time network traffic information for the > local interface on a freebsd 4.1-stable machine. > > Something like top, but only for network information. In the net/ports, it's called ntop: news# cd /usr/ports/net/ntop news# cat pkg/DESCR ntop is a tool that shows the network usage, similar to what the popular top(1) Unix command does. ntop is based on libpcap. WWW: http://jake.unipi.it/~deri/ntop/ Bill Fumerola Nick Rogness - Drive defensively. Buy a tank. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Sep 26 15:43:16 2000 Delivered-To: freebsd-net@freebsd.org Received: from smtp4.cluster.oleane.net (smtp4.cluster.oleane.net [195.25.12.62]) by hub.freebsd.org (Postfix) with ESMTP id E86FD37B422 for ; Tue, 26 Sep 2000 15:43:13 -0700 (PDT) Received: from diabolic-cow.321.net (dyn-1-1-009.Orl.dialup.oleane.fr [195.25.26.9]) by smtp4.cluster.oleane.net with ESMTP id AAA44463 for ; Wed, 27 Sep 2000 00:43:10 +0200 (CEST) Received: by diabolic-cow.321.net (Postfix, from userid 1000) id B2D4C1EF; Tue, 26 Sep 2000 23:49:04 +0200 (CEST) Date: Tue, 26 Sep 2000 23:49:04 +0200 From: =?iso-8859-1?Q?R=E9mi_Guyomarch?= To: freebsd-net@freebsd.org Subject: Re: interface traffic reporting Message-ID: <20000926234904.B1846@diabolic-cow.321.net> References: <001101c027fd$49e18720$47010a0a@fire.sysadmininc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <001101c027fd$49e18720$47010a0a@fire.sysadmininc.com>; from peter@sysadmin-inc.com on Tue, Sep 26, 2000 at 05:03:57PM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Sep 26, 2000 at 05:03:57PM -0400, Peter Brezny wrote: > is there some way of getting real time network traffic information for the > local interface on a freebsd 4.1-stable machine. > > Something like top, but only for network information. /usr/ports/net/trafshow -- Rémi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Sep 26 16: 3:16 2000 Delivered-To: freebsd-net@freebsd.org Received: from web311.mail.yahoo.com (web311.mail.yahoo.com [216.115.105.76]) by hub.freebsd.org (Postfix) with SMTP id 167C037B423 for ; Tue, 26 Sep 2000 16:03:11 -0700 (PDT) Message-ID: <20000926230310.14650.qmail@web311.mail.yahoo.com> Received: from [24.164.238.27] by web311.mail.yahoo.com; Tue, 26 Sep 2000 16:03:10 PDT Date: Tue, 26 Sep 2000 16:03:10 -0700 (PDT) From: Benjamin Gavin Subject: Re: ppp nat port/addr conflict To: Hanspeter Roth Bsag Cc: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, Actually, if you have NAT enabled it will always appear to outside hosts as if you are connecting from the router's external address. You should only use the nat addr ... command to override this default setting. If you are using ppp based nat in addition to ipfw firewall to filter packets, then you'll need to make sure that your ipfw rules allow for the transfer. I've had a similar setup before I got broadband access. I basically setup ipfw as normal, but used the "tun0" interface as my external address in all the rulesets. Then in the ppp.linkup script, I inserted a call to a script which reloaded the firewall rulesets based on the IP address I was given from my ISP. You can then customize IPFW to allow only the things that you want into your internal box. Then for the NAT portions of the ppp.conf, I entered the following information: nat enable yes nat same_ports yes nat use_sockets yes nat unregistered_only yes Then for each port that you want to send directly to your internal machine add a line like: nat port : Then just make sure that your gateway_enable flag is set to "YES" in rc.conf and you're golden. Ben Gavin --- Hanspeter Roth Bsag wrote: > Hello, > > I'm trying to set up NAT to allow specific connections. > > The participating hosts are connected as follows: > > local client FreeBSD router remote host > 1.0.0.2 <---> 1.0.0.1 2.0.0.1 <---> 2.0.0.2 > ethernet ppp > > The local client has to connect to the remote host but with > the router's address [1.0.0.2]. > In the ppp.conf I have > > nat addr 1.0.0.2 2.0.0.1 > > This allows telnet and ftp connections from the local client > [1.0.0.2] to the remote host [2.0.0.2]. > (Interestingly I'm also able to connect to the remote host from > the router itself.) > > Now I want a to allow a connection from the remote host to the > router at a specific port. Thus I tried > > nat port tcp 2.0.0.1:6009 6009 127.0.0.1:6009 > > I'm aware that there is an address conflict since 2.0.0.1 is also > diverted to the local client [1.0.0.2] by the `nat addr' command. > I hoped that `nat port' would take precedence over `nat addr'. > But packets to 2.0.0.1:6009 get diverted to the local client as well. > > Is there a means to resolve this conflict? > > -Hanspeter > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message ===== /******************************/ Benjamin Gavin Virtual.Olympus Software Virtual_Olympus@yahoo.com http://www.virtual-olympus.com/ /******************************/ __________________________________________________ Do You Yahoo!? Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Sep 26 16:26:18 2000 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (tun.AwfulHak.org [194.242.139.173]) by hub.freebsd.org (Postfix) with ESMTP id 1CFAB37B422 for ; Tue, 26 Sep 2000 16:26:12 -0700 (PDT) Received: from hak.lan.Awfulhak.org (root@hak.lan.awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.0/8.11.0) with ESMTP id e8QNPDa17355; Wed, 27 Sep 2000 00:25:13 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.0/8.11.0) with ESMTP id e8QNMIs84950; Wed, 27 Sep 2000 00:22:18 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200009262322.e8QNMIs84950@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Benjamin Gavin Cc: Hanspeter Roth Bsag , freebsd-net@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: ppp nat port/addr conflict In-Reply-To: Message from Benjamin Gavin of "Tue, 26 Sep 2000 16:03:10 PDT." <20000926230310.14650.qmail@web311.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 27 Sep 2000 00:22:17 +0100 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [.....] > nat enable yes > nat same_ports yes > nat use_sockets yes > nat unregistered_only yes [.....] Using ``nat target MYADDR'' may also be of use. > Ben Gavin -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Sep 26 20: 9:50 2000 Delivered-To: freebsd-net@freebsd.org Received: from jade.chc-chimes.com (jade.chc-chimes.com [216.28.46.6]) by hub.freebsd.org (Postfix) with ESMTP id 495DF37B424; Tue, 26 Sep 2000 20:08:47 -0700 (PDT) Received: by jade.chc-chimes.com (Postfix, from userid 1001) id 9B13D1C41; Tue, 26 Sep 2000 23:08:46 -0400 (EDT) Date: Tue, 26 Sep 2000 23:08:46 -0400 From: Bill Fumerola To: freebsd-ipfw@freebsd.org Cc: luigi@freebsd.org Subject: REVIEW REQUEST - new ipfw options Message-ID: <20000926230846.H34501@jade.chc-chimes.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i X-Operating-System: FreeBSD 3.3-STABLE i386 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [ sent to net@ and ipfw@, discussion in ipfw@ ] Please review the following patch for ipfw, adding more fields to provide the firewall administrator with a higher level of granularity. This patch also introduces a new flags member to struct ip_fw as I ran out of space in that, and I feel that splitting up things that change the operation of ipfw internally and things that define where we poke around belong in different locations. Its possible that more things now belong in the new flag member. Everything should be pretty straightforward. One thing notably absent is the diff to ipfw.8 in this patch. That's not due to incompetence with cvs, that's due to incompetence with mdoc. It should be very easy for someone with any mdoc clue to add these options in ipfw.8, and I'd ask that someone do that. Thanks, -- Bill Fumerola - Network Architect, BOFH / Chimes, Inc. billf@chimesnet.com / billf@FreeBSD.org ----- Forwarded message from Bill Fumerola ----- Index: ipfw.c =================================================================== RCS file: /home/ncvs/src/sbin/ipfw/ipfw.c,v retrieving revision 1.89 diff -u -r1.89 ipfw.c --- ipfw.c 2000/08/16 07:36:29 1.89 +++ ipfw.c 2000/09/27 02:38:43 @@ -412,7 +412,7 @@ if (chain->fw_flg & IP_FW_F_FRAG) printf(" frag"); - if (chain->fw_ipopt || chain->fw_ipnopt) { + if (chain->fw_ipflg & IP_FW_IF_IPOPT) { int _opt_printed = 0; #define PRINTOPT(x) {if (_opt_printed) printf(",");\ printf(x); _opt_printed = 1;} @@ -428,12 +428,39 @@ if (chain->fw_ipnopt & IP_FW_IPOPT_TS) PRINTOPT("!ts"); } + if (chain->fw_ipflg & IP_FW_IF_IPLEN) + printf(" iplen %u", chain->fw_iplen); + if (chain->fw_ipflg & IP_FW_IF_IPID) + printf(" ipid 0x%04x", chain->fw_ipid); + + if (chain->fw_ipflg & IP_FW_IF_IPTOS) { + int _opt_printed = 0; + + printf(" iptos "); + if (chain->fw_iptos & IPTOS_LOWDELAY) PRINTOPT("lowdelay"); + if (chain->fw_ipntos & IPTOS_LOWDELAY) PRINTOPT("!lowdelay"); + if (chain->fw_iptos & IPTOS_THROUGHPUT) PRINTOPT("throughput"); + if (chain->fw_ipntos & IPTOS_THROUGHPUT) PRINTOPT("!throughput"); + if (chain->fw_iptos & IPTOS_RELIABILITY) PRINTOPT("reliability"); + if (chain->fw_ipntos & IPTOS_RELIABILITY) PRINTOPT("!reliability"); + if (chain->fw_iptos & IPTOS_MINCOST) PRINTOPT("mincost"); + if (chain->fw_ipntos & IPTOS_MINCOST) PRINTOPT("!mincost"); + if (chain->fw_iptos & IPTOS_CE) PRINTOPT("congestion"); + if (chain->fw_ipntos & IPTOS_CE) PRINTOPT("!congestion"); + } + + if (chain->fw_ipflg & IP_FW_IF_IPTTL) + printf(" ipttl %u", chain->fw_ipttl); + + if (chain->fw_ipflg & IP_FW_IF_IPVER) + printf(" ipversion %u", chain->fw_ipver); + if (chain->fw_tcpf & IP_FW_TCPF_ESTAB) printf(" established"); else if (chain->fw_tcpf == IP_FW_TCPF_SYN && chain->fw_tcpnf == IP_FW_TCPF_ACK) printf(" setup"); - else if (chain->fw_tcpf || chain->fw_tcpnf) { + else if (chain->fw_ipflg & IP_FW_IF_TCPOPT) { int _flg_printed = 0; #define PRINTFLG(x) {if (_flg_printed) printf(",");\ printf(x); _flg_printed = 1;} @@ -452,7 +479,7 @@ if (chain->fw_tcpf & IP_FW_TCPF_URG) PRINTFLG("urg"); if (chain->fw_tcpnf & IP_FW_TCPF_URG) PRINTFLG("!urg"); } - if (chain->fw_tcpopt || chain->fw_tcpnopt) { + if (chain->fw_ipflg & IP_FW_IF_TCPOPT) { int _opt_printed = 0; #define PRINTTOPT(x) {if (_opt_printed) printf(",");\ printf(x); _opt_printed = 1;} @@ -470,6 +497,13 @@ if (chain->fw_tcpnopt & IP_FW_TCPOPT_CC) PRINTTOPT("!cc"); } + if (chain->fw_ipflg & IP_FW_IF_TCPSEQ) + printf(" tcpseq %lu", ntohl(chain->fw_tcpseq)); + if (chain->fw_ipflg & IP_FW_IF_TCPACK) + printf(" tcpack %lu", ntohl(chain->fw_tcpack)); + if (chain->fw_ipflg & IP_FW_IF_TCPWIN) + printf(" tcpwin %hu", ntohs(chain->fw_tcpwin)); + if (chain->fw_flg & IP_FW_F_ICMPBIT) { int type_index; int first = 1; @@ -837,7 +871,15 @@ " {established|setup}\n" " tcpflags [!]{syn|fin|rst|ack|psh|urg},...\n" " ipoptions [!]{ssrr|lsrr|rr|ts},...\n" +" iplen {length}\n" +" ipid {identification number (in hex)}\n" +" iptos [!]{lowdelay|throughput|reliability|mincost|congestion}\n" +" ipttl {time to live}\n" +" ipversion {version number}\n" " tcpoptions [!]{mss|window|sack|ts|cc},...\n" +" tcpseq {sequence number}\n" +" tcpack {acknowledgement number}\n" +" tcpwin {window size}\n" " icmptypes {type[,type]}...\n" " pipeconfig:\n" " {bw|bandwidth} {bit/s|Kbit/s|Mbit/s|Bytes/s|KBytes/s|MBytes/s}\n" @@ -1148,6 +1190,40 @@ } static void +fill_iptos(u_char *set, u_char *reset, char **vp) +{ + char *p = *vp,*q; + u_char *d; + + while (p && *p) { + if (*p == '!') { + p++; + d = reset; + } else { + d = set; + } + q = strchr(p, ','); + if (q) + *q++ = '\0'; + if (!strncmp(p,"lowdelay",strlen(p))) + *d |= IPTOS_LOWDELAY; + if (!strncmp(p,"throughput",strlen(p))) + *d |= IPTOS_THROUGHPUT; + if (!strncmp(p,"reliability",strlen(p))) + *d |= IPTOS_RELIABILITY; + if (!strncmp(p,"mincost",strlen(p))) + *d |= IPTOS_MINCOST; + if (!strncmp(p,"congestion",strlen(p))) + *d |= IPTOS_CE; +#if 0 /* conflicting! */ + if (!strncmp(p,"ecntransport",strlen(p))) + *d |= IPTOS_ECT; +#endif + p = q; + } +} + +static void fill_icmptypes(types, vp, fw_flg) u_long *types; char **vp; @@ -1878,22 +1954,78 @@ rule.fw_flg |= IP_FW_F_FRAG; av++; ac--; continue; } - if (!strncmp(*av,"ipoptions",strlen(*av))) { + if (!strncmp(*av,"ipoptions",strlen(*av)) || + !strncmp(*av,"ipopts",strlen(*av))) { av++; ac--; if (!ac) show_usage("missing argument" " for ``ipoptions''"); + rule.fw_ipflg |= IP_FW_IF_IPOPT; fill_ipopt(&rule.fw_ipopt, &rule.fw_ipnopt, av); av++; ac--; continue; } + if (!strncmp(*av,"iplen",strlen(*av))) { + av++; ac--; + if (!ac) + show_usage("missing arguement" + " for ``iplen''"); + rule.fw_ipflg |= IP_FW_IF_IPLEN; + rule.fw_iplen = (u_short)strtoul(*av, NULL, 0); + av++; ac--; continue; + } + if (!strncmp(*av,"ipid",strlen(*av))) { + av++; ac--; + if (!ac) + show_usage("missing arguement" + " for ``ipid''"); + rule.fw_ipflg |= IP_FW_IF_IPID; + if (strlen(*av) != 6 || (*av)[0] != '0' || (*av)[1] != 'x' || + isxdigit((*av)[2]) == 0 || + isxdigit((*av)[3]) == 0 || + isxdigit((*av)[4]) == 0 || + isxdigit((*av)[5]) == 0) + show_usage("arguement to ipid must be in hex"); + rule.fw_ipid = (u_short)strtoul(*av, NULL, 0); + av++; ac--; continue; + } + if (!strncmp(*av,"iptos",strlen(*av))) { + av++; ac--; + if (!ac) + show_usage("missing arguement" + " for ``iptos''"); + rule.fw_ipflg |= IP_FW_IF_IPTOS; + fill_iptos(&rule.fw_iptos, &rule.fw_ipntos, av); + av++; ac--; continue; + } + if (!strncmp(*av,"ipttl",strlen(*av))) { + av++; ac--; + if (!ac) + show_usage("missing arguement" + " for ``ipttl''"); + rule.fw_ipflg |= IP_FW_IF_IPTTL; + rule.fw_ipttl = (u_short)strtoul(*av, NULL, 0); + av++; ac--; continue; + } + if (!strncmp(*av,"ipversion",strlen(*av)) || + !strncmp(*av,"ipver",strlen(*av))) { + av++; ac--; + if (!ac) + show_usage("missing arguement" + " for ``ipversion''"); + rule.fw_ipflg |= IP_FW_IF_IPVER; + rule.fw_ipver = (u_short)strtoul(*av, NULL, 0); + av++; ac--; continue; + } if (rule.fw_prot == IPPROTO_TCP) { if (!strncmp(*av,"established",strlen(*av))) { rule.fw_tcpf |= IP_FW_TCPF_ESTAB; + rule.fw_ipflg |= IP_FW_IF_TCPFLG; av++; ac--; continue; } if (!strncmp(*av,"setup",strlen(*av))) { rule.fw_tcpf |= IP_FW_TCPF_SYN; rule.fw_tcpnf |= IP_FW_TCPF_ACK; + rule.fw_ipflg |= IP_FW_IF_TCPFLG; av++; ac--; continue; } if (!strncmp(*av,"tcpflags",strlen(*av)) || !strncmp(*av,"tcpflgs",strlen(*av))) { @@ -1901,6 +2033,7 @@ if (!ac) show_usage("missing argument" " for ``tcpflags''"); + rule.fw_ipflg |= IP_FW_IF_TCPFLG; fill_tcpflag(&rule.fw_tcpf, &rule.fw_tcpnf, av); av++; ac--; continue; } @@ -1909,9 +2042,37 @@ if (!ac) show_usage("missing argument" " for ``tcpoptions''"); + rule.fw_ipflg |= IP_FW_IF_TCPOPT; fill_tcpopts(&rule.fw_tcpopt, &rule.fw_tcpnopt, av); av++; ac--; continue; } + if (!strncmp(*av,"tcpseq",strlen(*av))) { + av++; ac--; + if (!ac) + show_usage("missing arguement" + " for ``tcpseq''"); + rule.fw_ipflg |= IP_FW_IF_TCPSEQ; + rule.fw_tcpseq = htonl((u_int32_t)strtoul(*av, NULL, 0)); + av++; ac--; continue; + } + if (!strncmp(*av,"tcpack",strlen(*av))) { + av++; ac--; + if (!ac) + show_usage("missing arguement" + " for ``tcpack''"); + rule.fw_ipflg |= IP_FW_IF_TCPACK; + rule.fw_tcpack = htonl((u_int32_t)strtoul(*av, NULL, 0)); + av++; ac--; continue; + } + if (!strncmp(*av,"tcpwin",strlen(*av))) { + av++; ac--; + if (!ac) + show_usage("missing arguement" + " for ``tcpwin''"); + rule.fw_ipflg |= IP_FW_IF_TCPWIN; + rule.fw_tcpwin = htons((u_short)strtoul(*av, NULL, 0)); + av++; ac--; continue; + } } if (rule.fw_prot == IPPROTO_ICMP) { if (!strncmp(*av,"icmptypes",strlen(*av))) { Index: /sys/netinet/ip_fw.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_fw.c,v retrieving revision 1.140 diff -u -r1.140 ip_fw.c --- /sys/netinet/ip_fw.c 2000/09/12 02:38:05 1.140 +++ /sys/netinet/ip_fw.c 2000/09/26 07:14:14 @@ -193,6 +193,7 @@ iface_match __P((struct ifnet *ifp, union ip_fw_if *ifu, int byname)); static int ipopts_match __P((struct ip *ip, struct ip_fw *f)); +static int iptos_match __P((struct ip *ip, struct ip_fw *f)); static __inline int port_match __P((u_short *portptr, int nports, u_short port, int range_flag, int mask)); @@ -354,6 +355,33 @@ } static int +iptos_match(struct ip *ip, struct ip_fw *f) +{ + + u_int flags = (ip->ip_tos & 0x1f); + u_char opts, nopts, nopts_sve; + + opts = f->fw_iptos; + nopts = nopts_sve = f->fw_ipntos; + + while (flags != 0) { + u_int flag; + + flag = 1 << (ffs(flags) -1); + opts &= ~flag; + nopts &= ~flag; + flags &= ~flag; + } + + if (opts == 0 && nopts == nopts_sve) + return 1; + else + return 0; + +} + + +static int tcpopts_match(struct tcphdr *tcp, struct ip_fw *f) { register u_char *cp; @@ -1108,9 +1136,19 @@ continue; } - /* Check IP options */ - if (f->fw_ipopt != f->fw_ipnopt && !ipopts_match(ip, f)) + /* Check IP header values */ + if (f->fw_ipflg & IP_FW_IF_IPOPT && !ipopts_match(ip, f)) + continue; + if (f->fw_ipflg & IP_FW_IF_IPLEN && f->fw_iplen != ip->ip_len) + continue; + if (f->fw_ipflg & IP_FW_IF_IPID && f->fw_ipid != ip->ip_id) continue; + if (f->fw_ipflg & IP_FW_IF_IPTOS && !iptos_match(ip, f)) + continue; + if (f->fw_ipflg & IP_FW_IF_IPTTL && f->fw_ipttl != ip->ip_ttl) + continue; + if (f->fw_ipflg & IP_FW_IF_IPVER && f->fw_ipver != ip->ip_v) + continue; /* Check protocol; if wildcard, and no [ug]id, match */ if (f->fw_prot == IPPROTO_IP) { @@ -1211,9 +1249,15 @@ } tcp = (struct tcphdr *) ((u_int32_t *)ip + ip->ip_hl); - if (f->fw_tcpopt != f->fw_tcpnopt && !tcpopts_match(tcp, f)) + if (f->fw_ipflg & IP_FW_IF_TCPOPT && !tcpopts_match(tcp, f)) + continue; + if (f->fw_ipflg & IP_FW_IF_TCPFLG && !tcpflg_match(tcp, f)) + continue; + if (f->fw_ipflg & IP_FW_IF_TCPSEQ && tcp->th_seq != f->fw_tcpseq) + continue; + if (f->fw_ipflg & IP_FW_IF_TCPACK && tcp->th_ack != f->fw_tcpack) continue; - if (f->fw_tcpf != f->fw_tcpnf && !tcpflg_match(tcp, f)) + if (f->fw_ipflg & IP_FW_IF_TCPWIN && tcp->th_win != f->fw_tcpwin) continue; goto check_ports; } Index: /sys/netinet/ip_fw.h =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_fw.h,v retrieving revision 1.52 diff -u -r1.52 ip_fw.h --- /sys/netinet/ip_fw.h 2000/08/22 00:32:52 1.52 +++ /sys/netinet/ip_fw.h 2000/09/26 07:14:42 @@ -54,7 +54,7 @@ struct in_addr fw_src, fw_dst; /* Source and destination IP addr */ struct in_addr fw_smsk, fw_dmsk; /* Mask for src and dest IP addr */ u_short fw_number; /* Rule number */ - u_int fw_flg; /* Flags word */ + u_int fw_flg; /* Operational Flags word */ #define IP_FW_MAX_PORTS 10 /* A reasonable maximum */ union { u_short fw_pts[IP_FW_MAX_PORTS]; /* Array of port numbers to match */ @@ -62,9 +62,16 @@ #define IP_FW_ICMPTYPES_DIM (IP_FW_ICMPTYPES_MAX / (sizeof(unsigned) * 8)) unsigned fw_icmptypes[IP_FW_ICMPTYPES_DIM]; /* ICMP types bitmap */ } fw_uar; + u_int fw_ipflg; /* IP flags word */ u_char fw_ipopt,fw_ipnopt; /* IP options set/unset */ + u_short fw_iplen, fw_ipid; /* IP length, identification */ + u_char fw_iptos, fw_ipntos; /* IP type of service set/unset */ + u_char fw_ipttl; /* IP time to live */ + u_int fw_ipver:4; /* IP version */ u_char fw_tcpopt,fw_tcpnopt; /* TCP options set/unset */ u_char fw_tcpf,fw_tcpnf; /* TCP flags set/unset */ + u_int32_t fw_tcpseq, fw_tcpack; /* TCP sequence and acknowledgement */ + u_short fw_tcpwin; /* TCP window size */ long timestamp; /* timestamp (tv_sec) of last match */ union ip_fw_if fw_in_if, fw_out_if; /* Incoming and outgoing interfaces */ union { @@ -206,6 +213,26 @@ #define IP_FW_F_CHECK_S 0x10000000 /* check state */ #define IP_FW_F_MASK 0x1FFFFFFF /* All possible flag bits mask */ + +/* + * Flags for the 'fw_ipflg' field, for comparing values of ip and its protocols. + */ +#define IP_FW_IF_TCPOPT 0x00000001 /* tcp options */ +#define IP_FW_IF_TCPFLG 0x00000002 /* tcp flags */ +#define IP_FW_IF_TCPSEQ 0x00000004 /* tcp sequence number */ +#define IP_FW_IF_TCPACK 0x00000008 /* tcp acknowledgement number */ +#define IP_FW_IF_TCPWIN 0x00000010 /* tcp window size */ +#define IP_FW_IF_TCPMSK 0x0000001f /* mask of all tcp values */ + +#define IP_FW_IF_IPOPT 0x00000100 /* ip options */ +#define IP_FW_IF_IPLEN 0x00000200 /* ip length */ +#define IP_FW_IF_IPID 0x00000400 /* ip identification */ +#define IP_FW_IF_IPTOS 0x00000800 /* ip type of service */ +#define IP_FW_IF_IPTTL 0x00001000 /* ip time to live */ +#define IP_FW_IF_IPVER 0x00002000 /* ip version */ +#define IP_FW_IF_IPMSK 0x00003f00 /* mask of all ip values */ + +#define IP_FW_IF_MSK 0x0000ffff /* All possible bits mask */ /* * For backwards compatibility with rules specifying "via iface" but ----- 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 Wed Sep 27 6:46:29 2000 Delivered-To: freebsd-net@freebsd.org Received: from ns.bsag.ch (ns.bsag.ch [195.246.88.210]) by hub.freebsd.org (Postfix) with ESMTP id 6D49037B422 for ; Wed, 27 Sep 2000 06:46:26 -0700 (PDT) Received: (from hpr@localhost) by ns.bsag.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id PAA11571; Wed, 27 Sep 2000 15:46:20 +0200 Date: Wed, 27 Sep 2000 15:46:20 +0200 From: Hanspeter Roth Bsag To: Benjamin Gavin Cc: freebsd-net@FreeBSD.ORG Subject: Re: ppp nat port/addr conflict Message-ID: <20000927154620.C11380@bs11.bsag.ch> References: <20000926230310.14650.qmail@web311.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000926230310.14650.qmail@web311.mail.yahoo.com>; from virtual_olympus@yahoo.com on Tue, Sep 26, 2000 at 04:03:10PM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Sep 26, 2000 at 04:03:10PM -0700, Benjamin Gavin wrote: [...] > > Then for each port that you want to send directly to your internal > machine add a line like: > nat port : Ok. I have now set nat port tcp 2.0.0.1:6007-6009 6007-6009 and it works perfektly. My problem was I've first set it into the wrong entry. As soon as it's in the write entry it works. Tanks. Hanspeter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 27 7: 1:46 2000 Delivered-To: freebsd-net@freebsd.org Received: from ns.bsag.ch (ns.bsag.ch [195.246.88.210]) by hub.freebsd.org (Postfix) with ESMTP id A8F5937B422; Wed, 27 Sep 2000 07:01:41 -0700 (PDT) Received: (from hpr@localhost) by ns.bsag.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id QAA11726; Wed, 27 Sep 2000 16:01:40 +0200 Date: Wed, 27 Sep 2000 16:01:40 +0200 From: Hanspeter Roth Bsag To: freebsd-isdn@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: rc.isdn hangs the system Message-ID: <20000927160140.D11380@bs11.bsag.ch> References: <20000921105248.A9893@bs11.bsag.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000921105248.A9893@bs11.bsag.ch>; from roth@bsag.ch on Thu, Sep 21, 2000 at 10:52:48AM +0200 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Sep 21, 2000 at 10:52:48AM +0200, Hanspeter Roth Bsag wrote: > The only problem I encounter is dxpc doesn't listen on the tun0 > interface opened by ppp. (Dxpc is not started at system startup.) Sorry, I forgot the -a switch on netstat. Dxpc really does listen on all interfaces (adresses). It just appeared to me it didn't due to other configuration (NAT). (But this is fixed now.) -Hanspeter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 27 8:37:24 2000 Delivered-To: freebsd-net@freebsd.org Received: from modemcable101.200-201-24.mtl.mc.videotron.ca (modemcable101.200-201-24.mtl.mc.videotron.ca [24.201.200.101]) by hub.freebsd.org (Postfix) with SMTP id DDC6737B423 for ; Wed, 27 Sep 2000 08:37:04 -0700 (PDT) Received: (qmail 36400 invoked from network); 27 Sep 2000 15:37:03 -0000 Received: from patrak.local.mindstep.com (HELO PATRAK) (192.168.10.4) by jacuzzi.local.mindstep.com with SMTP; 27 Sep 2000 15:37:03 -0000 Message-ID: <124901c02898$ca8aadc0$040aa8c0@local.mindstep.com> From: "Patrick Bihan-Faou" To: Subject: natd and userland ppp Date: Wed, 27 Sep 2000 11:37:06 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, Sorry if this question has been answered before, but I am looking for a good reason why one should use "ppp -nat" rather than natd with ppp ? I have seen the man page for natd stating "It is intended for use with NICs - if you want to do NAT on a PPP link, use the -nat switch to ppp(8)." But this hardly gives details on why it is a bad idea to do so. Also with the "dynamic" option in natd, obtaining the correct IP address for the PPP link seems to not be a problem. I have set up a box with a PPPoE link to the internet, and for various reasons it was easier for me to use the natd daemon rather than the ppp option (although it is definitely possible as well). What I see as better for natd is: - I know exactly when it is invoked in the ipfw ruleset - I can have the same configuration wheither I have a LAN based configuration or a PPP link Can anybody enlighten me ? Patrick. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 27 8:49:40 2000 Delivered-To: freebsd-net@freebsd.org Received: from thoth.amduat.net (c500290-a.frndl1.wa.home.com [24.10.38.147]) by hub.freebsd.org (Postfix) with ESMTP id 9CAF237B422 for ; Wed, 27 Sep 2000 08:49:28 -0700 (PDT) Received: from acm.org (osiris.amduat.net [10.0.0.69]) by thoth.amduat.net (8.9.3/8.9.3) with ESMTP id IAA00278 for ; Wed, 27 Sep 2000 08:49:27 -0700 (PDT) (envelope-from jsbarrett@acm.org) Message-ID: <39D21707.BBA56A95@acm.org> Date: Wed, 27 Sep 2000 08:49:27 -0700 From: "Jacob S. Barrett" Reply-To: jbarrett@amduat.net X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: ypserv reverse DNS lookup loop Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I am having a problem with ypserv that I can't seem to solve. It appears to get stuck in a lookup loop on certain reverse DNS lookups that don't resolve. Here is the scenario I think is happening: 1) Mail server gets an email form mailing list and tries to verify the server via revers lookup on the connection IP. 2) Lookup fails on /etc/hosts so it moves to named. 3) Named fails so it asks NIS. (per the /etc/host.conf) 4) NIS server asks its local DNS server who fails and asks the upstream DNS server. 5) Step 4 repeated infinitely. Needless to say this is probably pissing off my ISP. I have patched the problem by removing NIS from the host.conf file but it would be nice to resolve this issue. Does anyone have any ideas as to what may be happening? Do I have a configuration error or something. If you would like to test this on your own machines I will tell you the IP address it always fails with if you request it. Jacob S. Barrett jsbarrett@acm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 27 9:33:36 2000 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id BF9CD37B423 for ; Wed, 27 Sep 2000 09:33:23 -0700 (PDT) Received: from InterJet.elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id JAA15156; Wed, 27 Sep 2000 09:33:11 -0700 (PDT) Date: Wed, 27 Sep 2000 09:33:10 -0700 (PDT) From: Julian Elischer To: Patrick Bihan-Faou Cc: freebsd-net@freebsd.org Subject: Re: natd and userland ppp In-Reply-To: <124901c02898$ca8aadc0$040aa8c0@local.mindstep.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org One good reason is that the PPP IP address is dynamically assigned and NATD doesn't work so well in such a dynamic environment. They are both running the same NAT library, but is you use NATD then the packet is diverted to userland TWICE, with it's attendant reduction in throughput and increase in latency.. PPP diverts packet out of the kernel once. Once it's diverted you might as well do the NAT on the packet. (and as I said, you'd have a lot of fun getting NATD synchronised with ppp. (You'd have to use all sorts of link-up and link-down scripts. Mpd can use netgraph to do all ppp processing in the kernel to reduce latency even further, but it doesn't have NAT. You could however combine it with ipfilter's in-kernel NAT to get an all-kernel solution. (we need to make a netgraph NAT module but we haven't done it yet.) On Wed, 27 Sep 2000, Patrick Bihan-Faou wrote: > Hi, > > > Sorry if this question has been answered before, but I am looking for a good > reason why one should use "ppp -nat" rather than natd with ppp ? > > > I have seen the man page for natd stating "It is intended for use with > NICs - if you want to do NAT on a PPP link, use the -nat switch to ppp(8)." > But this hardly gives details on why it is a bad idea to do so. Also with > the "dynamic" option in natd, obtaining the correct IP address for the PPP > link seems to not be a problem. > > I have set up a box with a PPPoE link to the internet, and for various > reasons it was easier for me to use the natd daemon rather than the ppp > option (although it is definitely possible as well). > > What I see as better for natd is: > - I know exactly when it is invoked in the ipfw ruleset > - I can have the same configuration wheither I have a LAN based > configuration or a PPP link > > Can anybody enlighten me ? > > > Patrick. > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 27 9:56:39 2000 Delivered-To: freebsd-net@freebsd.org Received: from modemcable101.200-201-24.mtl.mc.videotron.ca (modemcable101.200-201-24.mtl.mc.videotron.ca [24.201.200.101]) by hub.freebsd.org (Postfix) with SMTP id 45B3737B423 for ; Wed, 27 Sep 2000 09:56:27 -0700 (PDT) Received: (qmail 39974 invoked from network); 27 Sep 2000 16:56:26 -0000 Received: from patrak.local.mindstep.com (HELO PATRAK) (192.168.10.4) by jacuzzi.local.mindstep.com with SMTP; 27 Sep 2000 16:56:26 -0000 Message-ID: <128b01c028a3$e0f903d0$040aa8c0@local.mindstep.com> From: "Patrick Bihan-Faou" To: References: <124901c02898$ca8aadc0$040aa8c0@local.mindstep.com> Subject: Re: natd and userland ppp Date: Wed, 27 Sep 2000 12:56:28 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, > They are both running the same NAT library, but is you use NATD then the > packet is diverted to userland TWICE, with it's > attendant reduction in throughput and increase in latency.. This sounds like a fair reason. However it strikes me that there is quite a bit of code duplication because of this: I know that libalias is used in both, but you still need some support code in each one of them (configuration elements etc.) + calling the actual aliasing code. It seems also that some features (such as automatic holes in the firewall and dynamic rules) are a bit tricky to get working properly with aliasing in ppp. Now I probably missed some tricks on that side, so don't flame me because of that last comment, educate me! > PPP diverts packet out of the kernel once. Once it's diverted you might as > well do the NAT on the packet. (and as I said, you'd have a lot of fun > getting NATD synchronised with ppp. (You'd have to use all sorts of > link-up and link-down scripts. Well actually, with the "dynamic" option in natd, synchronizing to ppp is really painless (or at least it looks like it is working properly). Thanks to the magic of the routing socket. So this is hardly an argument. > Mpd can use netgraph to do all ppp processing in the kernel to reduce > latency even further, but it doesn't have NAT. You could however combine > it with ipfilter's in-kernel NAT to get an all-kernel solution. > (we need to make a netgraph NAT module but we haven't done it yet.) A netgraph nat module seems to be the way to go... As soon as I have some spare time (wishfull thinking :) I'll look into that. So at this point, I take it that the main reason for not using natd with ppp is because of the increased number of context switching between userland and kernel code. Patrick. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 27 10:26:32 2000 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id B235737B423 for ; Wed, 27 Sep 2000 10:26:21 -0700 (PDT) Received: from InterJet.elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id KAA15349; Wed, 27 Sep 2000 10:26:17 -0700 (PDT) Date: Wed, 27 Sep 2000 10:26:16 -0700 (PDT) From: Julian Elischer To: Patrick Bihan-Faou Cc: freebsd-net@freebsd.org Subject: Re: natd and userland ppp In-Reply-To: <128b01c028a3$e0f903d0$040aa8c0@local.mindstep.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 27 Sep 2000, Patrick Bihan-Faou wrote: > Hi, > > > > They are both running the same NAT library, but is you use NATD then the > > packet is diverted to userland TWICE, with it's > > attendant reduction in throughput and increase in latency.. > > This sounds like a fair reason. However it strikes me that there is quite a > bit of code duplication because of this: I know that libalias is used in > both, but you still need some support code in each one of them > (configuration elements etc.) + calling the actual aliasing code. well if you use the ppp nat then you don't call both sets of support code.. that's even more reason.. > > It seems also that some features (such as automatic holes in the firewall > and dynamic rules) are a bit tricky to get working properly with aliasing in > ppp. Now I probably missed some tricks on that side, so don't flame me > because of that last comment, educate me! I'm not an expert on PPP's filtering rules.. I'll let Brian answer that.. > > > > > PPP diverts packet out of the kernel once. Once it's diverted you might as > > well do the NAT on the packet. (and as I said, you'd have a lot of fun > > getting NATD synchronised with ppp. (You'd have to use all sorts of > > link-up and link-down scripts. > > > Well actually, with the "dynamic" option in natd, synchronizing to ppp is > really painless (or at least it looks like it is working properly). Thanks > to the magic of the routing socket. So this is hardly an argument. well, yes it works.. I'm not totally sure though if you can do everything quite the same. > > > > Mpd can use netgraph to do all ppp processing in the kernel to reduce > > latency even further, but it doesn't have NAT. You could however combine > > it with ipfilter's in-kernel NAT to get an all-kernel solution. > > (we need to make a netgraph NAT module but we haven't done it yet.) > > A netgraph nat module seems to be the way to go... As soon as I have some > spare time (wishfull thinking :) I'll look into that. yes I actually was considering using the NAT code from ipfilter to do the job.. the difficulty is deciding exactly wherre and how to slot a NAT module in.. if it were attached to an interface, then it would have to know about both IP and the MAC levels which would break layering. If it's attached to the IP stack (where ipfw presently gets packets for NAT from) then it loses some of the niceness of attaching it to an interface. Maybe it's not really a job for netgraph but a job for an IPFW keyword/Module. (then in that case we should look at ipfilter again as it isn't going away..) Personally I'd like a way of attaching a netgraph node between IP and the various interfaces. (I think this could be achieved by using the netgraph interface node as a frontend to the actual interfaces and not assigning IP addresses to the real interfaces you wanted to do NAT on, but instead assign those addresses to teh ng interfaces.. (hmmmm maybe..) > > > > So at this point, I take it that the main reason for not using natd with ppp > is because of the increased number of context switching between userland and > kernel code. > > > Patrick. > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 27 10:55: 3 2000 Delivered-To: freebsd-net@freebsd.org Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by hub.freebsd.org (Postfix) with ESMTP id 7A3E737B422 for ; Wed, 27 Sep 2000 10:54:42 -0700 (PDT) Received: from ac.upc.es (fonoll.ac.upc.es [147.83.32.14]) by roura.ac.upc.es (8.11.0/8.11.0) with ESMTP id e8RHsjp08290; Wed, 27 Sep 2000 19:54:46 +0200 (MET DST) Message-ID: <39D23465.F3367329@ac.upc.es> Date: Wed, 27 Sep 2000 19:54:45 +0200 From: Oscar I Lepe Organization: DAC/UPC X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: es, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: On the net.link.generic.ifdata sysctl node Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi! I would like to read the value of if_snd.ifq_drops for the configured interfaces. I read through the source code (net/if_mib.c) and find out that this should be possible by means of the net.link.generic.ifdata sysctl node. But when I use the sysctl command I get the following responses: $ sysctl net.link.generic net.link.generic.system.ifcount: 12 $ sysctl net.link.generic.ifdata $ sysctl net.link.generic.ifdata.0 sysctl: unknown oid 'net.link.generic.ifdata.0' Would someone give me some insights about why this isn't working? Is there some other way to read the vale of if_snd.ifq_drops for the configured interfaces? Thanks in advance! -- ======================================================================== 0 0 0 Oscar-Ivan Lepe-Aldama | UPC-Campus Nord, DAC 0 0 0 e-mail: oscar@ac.upc.es | Modul D6, despatx 116 0 0 0 phone: +34 93 401 7187 | Jordi Girona, 1-3 U P C fax: +34 93 401 7055 | 08034 Barcelona - SPAIN WWW: http://www.ac.upc.es/homes/oscar/ ======================================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 27 11:23:33 2000 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id A36AA37B422 for ; Wed, 27 Sep 2000 11:23:30 -0700 (PDT) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id OAA74100; Wed, 27 Sep 2000 14:23:22 -0400 (EDT) (envelope-from wollman) Date: Wed, 27 Sep 2000 14:23:22 -0400 (EDT) From: Garrett Wollman Message-Id: <200009271823.OAA74100@khavrinen.lcs.mit.edu> To: Oscar I Lepe Cc: freebsd-net@FreeBSD.ORG Subject: On the net.link.generic.ifdata sysctl node In-Reply-To: <39D23465.F3367329@ac.upc.es> References: <39D23465.F3367329@ac.upc.es> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > Is there some other way to read the vale of if_snd.ifq_drops for the > configured interfaces? See the source file tools/tools/ifinfo for information and sample code to access this MIB information. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 27 12:39:52 2000 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (f165.law4.hotmail.com [216.33.149.165]) by hub.freebsd.org (Postfix) with ESMTP id 9F70A37B422 for ; Wed, 27 Sep 2000 12:39:48 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Sep 2000 12:39:48 -0700 Received: from 24.234.122.152 by lw4fd.law4.hotmail.msn.com with HTTP; Wed, 27 Sep 2000 19:39:48 GMT X-Originating-IP: [24.234.122.152] From: "Chris Angell" To: freebsd-net@freebsd.org Subject: DNS Date: Wed, 27 Sep 2000 12:39:48 PDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Sep 2000 19:39:48.0355 (UTC) FILETIME=[B21B8530:01C028BA] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have tried everything to get my DNS working right. For some reason telnet and ftp won't resolve host names, I think because my computer won't do reverse mapping for DNS. Ping, Traceroute, and other utilities like nslookup work fine, but I don't think they do reverse mapping. I have named running on my system, but the problem persists even if I turn it off and use other name servers, like my ISP's name server. I have been struggling with this problem for a while, and it is quite annoying. I would appreciate all the help I could get on the subject. Thanks, Chris Angell dhcp152.122.lvcm.com _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 27 12:44:11 2000 Delivered-To: freebsd-net@freebsd.org Received: from jade.chc-chimes.com (jade.chc-chimes.com [216.28.46.6]) by hub.freebsd.org (Postfix) with ESMTP id C297F37B423 for ; Wed, 27 Sep 2000 12:44:09 -0700 (PDT) Received: by jade.chc-chimes.com (Postfix, from userid 1001) id 9C5D51C76; Wed, 27 Sep 2000 15:44:08 -0400 (EDT) Date: Wed, 27 Sep 2000 15:44:08 -0400 From: Bill Fumerola To: Chris Angell Cc: freebsd-net@freebsd.org Subject: Re: DNS Message-ID: <20000927154408.R34501@jade.chc-chimes.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from chris62vw@hotmail.com on Wed, Sep 27, 2000 at 12:39:48PM -0700 X-Operating-System: FreeBSD 3.3-STABLE i386 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Sep 27, 2000 at 12:39:48PM -0700, Chris Angell wrote: > I have tried everything to get my DNS working right. For some reason telnet > and ftp won't resolve host names, I think because my computer won't do > reverse mapping for DNS. Ping, Traceroute, and other utilities like > nslookup work fine, but I don't think they do reverse mapping. > > I have named running on my system, but the problem persists even if I turn > it off and use other name servers, like my ISP's name server. > > I have been struggling with this problem for a while, and it is quite > annoying. I would appreciate all the help I could get on the subject. Workaround: telnet -N Solution: Fix your name servers (or if its a real bug in FreeBSD, provide more details). -- Bill Fumerola - Network Architect, BOFH / Chimes, Inc. billf@chimesnet.com / billf@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 27 14:58:50 2000 Delivered-To: freebsd-net@freebsd.org Received: from rapidnet.com (rapidnet.com [205.164.216.1]) by hub.freebsd.org (Postfix) with ESMTP id CAF9937B423 for ; Wed, 27 Sep 2000 14:58:47 -0700 (PDT) Received: from localhost (nick@localhost) by rapidnet.com (8.9.3/8.9.3) with ESMTP id PAA17953; Wed, 27 Sep 2000 15:58:41 -0600 (MDT) Date: Wed, 27 Sep 2000 15:58:41 -0600 (MDT) From: Nick Rogness To: Chris Angell Cc: freebsd-net@freebsd.org Subject: Re: DNS In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 27 Sep 2000, Chris Angell wrote: > I have tried everything to get my DNS working right. For some reason telnet > and ftp won't resolve host names, I think because my computer won't do > reverse mapping for DNS. Ping, Traceroute, and other utilities like > nslookup work fine, but I don't think they do reverse mapping. > Yes, it is not doing reverse for those zones. Are the in-addr.arpa zones in your named.conf file? > I have named running on my system, but the problem persists even if I turn > it off and use other name servers, like my ISP's name server. Your /etc/resolv.conf file should be setup to use your local nameserver, not your upstreams. Which means it should look something like this: # cat /etc/resolv.conf domain somedomain.com nameserver 127.0.0.1 > > I have been struggling with this problem for a while, and it is quite > annoying. I would appreciate all the help I could get on the subject. > If you give more details and send your /etc/namedb/named.conf and your /etc/resolv.conf files, it should be pretty easy to fix. By details, I mean what host(s) your connecting from, which zones you you are doing reverses, slave on, etc. Nick Rogness - Drive defensively. Buy a tank. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 27 15:21:39 2000 Delivered-To: freebsd-net@freebsd.org Received: from monkeys.com (236.dsl9226.rcsis.com [63.92.26.236]) by hub.freebsd.org (Postfix) with ESMTP id 3CC7C37B422; Wed, 27 Sep 2000 15:21:25 -0700 (PDT) Received: from monkeys.com (localhost [127.0.0.1]) by monkeys.com (8.9.3/8.9.3) with ESMTP id PAA24599; Wed, 27 Sep 2000 15:21:24 -0700 (PDT) To: freebsd-questions@freebsd.org, freebsd-net@freebsd.org Subject: An (simple) example multi-client server using kqueue/kevent. From: "Ronald F. Guilmette" Date: Wed, 27 Sep 2000 15:21:24 -0700 Message-ID: <24597.970093284@monkeys.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [[This message doesn't contain a question, so maybe I shouldn't be cross- posting it to freebsd-questions, but I hope that this info may help some folks who have questions about usage of the new kqueue/kevent stuff.]] Recently, I became interested in using the new kqueue/kevent kernel primitives for a multi-client server I wanted to build. I started reading up on these new kernel functions and found that not only are they likely to be vastly more efficient than the alternatives (i.e. poll(2) and select(2)) but also, that they allow for a cleaner program design, due to the availability of an extra data field (udata) in each kqueue structure that can be used (by the application programmer) as a hook to get you vectored off to some appropriate handler routine when some specific event you are monitoring occurs. The only drawback seemed to be that I could find no good and/or complete working example of a multi-client server which used these new kernel functions or which clarified, in concrete terms, exactly what proper usage of these functions would look like. Fortunately, the fellow who designed and implemented a lot (all?) of this kqueue/kevent stuff in the kernel, Jonathan Lemon , was kind enough to converse with me, at length, via e-mail, about correct usage, so now I feel that I have a pretty good handle on how to use this stuff. Just to be sure of that however, I wrote up a trivial example multi-client network server... i.e. an ``echo'' server... and asked Jonathan to take a look at it and to send me a critique, which he obligingly did. He suggested some minor changes to the code, which I then implemented. For those of you who may be interested, the resulting example echo server may be viewed at: http://www.monkeys.com/kqueue/echo.c Some notes about the program: o I ran it and it actually seemed to work and to do what was intended. (Surprisingly, it did so the first time I actually ran it!) o Please be aware that I write code in a style which is mostly the GNU/Stallman coding style, except that I write declarations in a funny way, i.e. with const and volatile modifiers always placed as far to the right in a declaration as possible while maintaining the same semantic intent. Whereas most C coders will write `const int *', I write `int const *' instead. Both are legal C and both are semantically equivalent, but I like the former style because it allows me to read declarations right-to-left and get something that makes sense, even in English, e.g "pointer to constant integer". My apologies if my style confuses you. o The `struct ecb' type, defined in the program, is my ``event control block''. It just contains the read and write function pointers associated with some specific client of the server, along with some ancillary data, specifically, a pointer to the base of, and the length of a currently pending output buffer. Pointers to a given `ecb' thingy are used, within this server as the `udata' field of two different kevent structures, i.e. one which asks for monitoring of readability of the relevant socket, and another which asks for monitoring of writability of that same socket. o Within my event loop, I never check for either of the conditions EV_ERROR or EV_EOF. Rather, I allow the primitive socket read and write handler functions check for error and EOF conditions themselves. According to Jonathan, this approach may be sub- optimal and it would probably be better to check for EV_ERROR within the event loop (but checking for EOF in the read/write functions is entirely sensible). o Even after talking to Johnathan about this, it still isn't 100% clear whether it is better to EV_DELETE a filter that is monitor- ing a condition that you do not wish to pay attention to right now or if it is better to instead just EV_DISABLE it. In my example echo server, I use EV_DISABLE. Please send comments or critiques of the echo.c server to . Some notes about kevent/kqueue in general: o There doesn't seem to be any way, at present, to ask to be alerted ONLY when you can immediately write N bytes to some specified file descriptor *without blocking*. I have mentioned this to Johnathan, and he seemed to agree that this is a problem, and one which may require some small extension to the existing kqueue/kevent semantics in order to provide this additional functionality. o It is somewhat unfortunate that the name of the data structure used by these primitives (struct kevent) is the same as the name of one of the functions provided by the interface. The implication is that you can write: typedef struct kevent kevent; in your own code, if you want to be able to refer to the type tersely, but if you do that, you will thereafter get compile-time syntax errors where you attempt to call the kevent *function*. o If one is REALLY obeying all rules of the ANSI/ISO C standard, then one MAY NOT assign a pointer to any function to the `udata' field of the kevent structure. According to strict ANSI/ISO C rules (which will be applied by gcc when/if you use the -pedant-errors option) pointers to functions and pointers to data may NEVER be mixed in any way. I've mentioned this to Johanathan and suggested that he change the type of `udata' to be some union type that can hold either a pointer to some data item or a pointer to some function. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 27 20:59:16 2000 Delivered-To: freebsd-net@freebsd.org Received: from dipsy.tch.org (dipsy.tch.org [166.88.4.10]) by hub.freebsd.org (Postfix) with ESMTP id 1648437B423 for ; Wed, 27 Sep 2000 20:59:10 -0700 (PDT) Received: (from ser@localhost) by dipsy.tch.org (8.11.0.Beta3/8.11.0.Beta3) id e8S3x6q28381 for net@freebsd.org; Wed, 27 Sep 2000 20:59:06 -0700 (PDT) Date: Wed, 27 Sep 2000 20:59:05 -0700 From: Steve Rubin To: net@freebsd.org Subject: AX.25 Message-ID: <20000927205905.B28266@tch.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Is anyone working on AX.25 for FreeBSD? -- Steve Rubin / KG6DFV / IP Networks - San Jose, CA USA Email: ser@tch.org / Construction worker on the Information Superhighway To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 27 23:32:55 2000 Delivered-To: freebsd-net@freebsd.org Received: from osku.suutari.iki.fi (osku.syncrontech.com [213.28.98.4]) by hub.freebsd.org (Postfix) with ESMTP id E519837B43C for ; Wed, 27 Sep 2000 23:32:47 -0700 (PDT) Received: from coffee (adsl-nat.syncrontech.com [213.28.98.3]) by osku.suutari.iki.fi (8.9.3/8.9.3) with SMTP id JAA18772; Thu, 28 Sep 2000 09:32:24 +0300 (EEST) (envelope-from ari@suutari.iki.fi) Message-ID: <004d01c02915$e0656f90$0e05a8c0@intranet.syncrontech.com> From: "Ari Suutari" To: "Julian Elischer" , "Patrick Bihan-Faou" Cc: References: Subject: Re: natd and userland ppp Date: Thu, 28 Sep 2000 09:32:23 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, > One good reason is that the PPP IP address is dynamically assigned and > NATD doesn't work so well in such a dynamic environment. > They are both running the same NAT library, but is you use NATD then the > packet is diverted to userland TWICE, with it's > attendant reduction in throughput and increase in latency.. > > PPP diverts packet out of the kernel once. Once it's diverted you might as > well do the NAT on the packet. (and as I said, you'd have a lot of fun > getting NATD synchronised with ppp. (You'd have to use all sorts of > link-up and link-down scripts. I think that this is not true. Just use -dynamic flag in natd and it will automatically track down address changes on ppp interface. Ari S. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Sep 28 10:34:14 2000 Delivered-To: freebsd-net@freebsd.org Received: from orthanc.ab.ca (207-167-15-66.dsl.worldgate.ca [207.167.15.66]) by hub.freebsd.org (Postfix) with ESMTP id 6358D37B423 for ; Thu, 28 Sep 2000 10:34:00 -0700 (PDT) Received: from orthanc.ab.ca (localhost [127.0.0.1]) by orthanc.ab.ca (8.11.0.Beta3/8.11.0.Beta3) with ESMTP id e8SHXj140100; Thu, 28 Sep 2000 11:33:45 -0600 (MDT) Message-Id: <200009281733.e8SHXj140100@orthanc.ab.ca> To: Steve Rubin Cc: net@FreeBSD.ORG Subject: Re: AX.25 In-reply-to: Your message of "Wed, 27 Sep 2000 20:59:05 PDT." <20000927205905.B28266@tch.org> Date: Thu, 28 Sep 2000 11:33:45 -0600 From: Lyndon Nerenberg Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >>>>> "Steve" == Steve Rubin writes: Steve> Is anyone working on AX.25 for FreeBSD? It's been a hot-and-cold running project of mine for a couple of years now. Every time I sit down to work on it, though, something in the kernel changes out from under me. Now that winter's approaching I've been thinking about getting back to work on this again ... --lyndon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Sep 28 21: 5:34 2000 Delivered-To: freebsd-net@freebsd.org Received: from alcanet.com.au (mail.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with SMTP id 1777637B423 for ; Thu, 28 Sep 2000 21:05:20 -0700 (PDT) Received: by border.alcanet.com.au id <115252>; Fri, 29 Sep 2000 15:04:54 +1000 Content-return: prohibited Date: Fri, 29 Sep 2000 15:05:03 +1100 From: Peter Jeremy Subject: ipfw(8) divert handling To: freebsd-net@FreeBSD.ORG Reply-To: freebsd-net@FreeBSD.ORG, peter.jeremy@alcatel.com.au Message-Id: <00Sep29.150454est.115252@border.alcanet.com.au> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [Please include me in any replies] The behaviour of the ipfw divert rule in both 4-STABLE and -CURRENT is different to the ipfw(8) man page. The actual behaviour is that if the diverted packet is written back into the IP stack, it will re-enter ipfw rule processing at the rule number following the divert rule[1]. According to my reading of the code, the same thing happens for a tee rule. The man page describes two different actions: - In the section RULE FORMAT.action.divert, it states "[t]he search terminates". - In the section SYSCTL VARIABLES, net.inet.ip.fw.one_pass is described as controlling divert action as well as pipe action, with the packet being re-injected at the next rule. The term "next rule", used in several places in the man page, is also slightly misleading: For pipe and queue rules it is the next rule in sequence. For divert and tee, it is the next rule with a higher rule number (ie subsequent rules with the same rule number are skipped). IMHO, there should be a way to make the rule search terminate following a successful divert (which fw.one_pass does for pipes). The patch below does this, except when the divert process changes the rule number to 0 - in which case it restarts processing. Comments please. On a different topic, I notice that struct ip_fw includes a field next_rule_ptr which is documented as "next rule in case of match". The code in ip_fw_chk() checks this field on skipto's (to avoid needing to do a linear search for skipto rules). There's even a function flush_rule_ptrs() which back this use up. Unfortunately, the code to actually assign next_rule_ptr is missing... Is there some reason why this isn't used? [1] If the divert application uses recvfrom(2)/sendto(2), it can change the rule number, but the most common divert application (natd) don't support this. Index: ip_fw.c =================================================================== RCS file: /home/CVSROOT/src/sys/netinet/ip_fw.c,v retrieving revision 1.140 diff -u -r1.140 ip_fw.c --- ip_fw.c 2000/09/12 02:38:05 1.140 +++ ip_fw.c 2000/09/29 04:01:41 @@ -1017,6 +1017,9 @@ */ chain = LIST_FIRST(&ip_fw_chain); if (skipto != 0) { + /* Accept if passed first test */ + if (fw_one_pass) + return 0; if (skipto >= IPFW_DEFAULT_RULE) goto dropit; while (chain && chain->rule->fw_number <= skipto) Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Sep 28 22: 3:28 2000 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id CF48937B422 for ; Thu, 28 Sep 2000 22:03:11 -0700 (PDT) Received: from InterJet.elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id WAA22133; Thu, 28 Sep 2000 22:03:10 -0700 (PDT) Date: Thu, 28 Sep 2000 22:03:10 -0700 (PDT) From: Julian Elischer To: freebsd-net@FreeBSD.ORG, peter.jeremy@alcatel.com.au Subject: Re: ipfw(8) divert handling In-Reply-To: <00Sep29.150454est.115252@border.alcanet.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Your confusion results from considering the adtions after the divert and before the divert as being the same pass. on diversion, the pass through the ipfw filter is finished. The search is terminated. (as the man page states). However some state information is returned to the divert socket when the packet is passed out of the kernel. Divert also allows packets to be injected into the kernel. It also allows some state to be associated with the initial state of that packet.. It so happens, (what a coincidence!) that the state coming out and the state sent in are identical in format and semantics. The result of this is that if you re-submit a received packet, along with the state information that was received with it, the filtering is started at the next higher rule number than that at which the original divert occured. So the man page is correct . The search DID terminate. As far as the kernel is concerned, the packet that is re-injected is a DIFFERENT packet. Only the external daemon knows the relationship between the two. I have no idea what "one_pass" is trying to achieve.. it wasn't there when we wrote 'divert'. From my perspective I don't believe it should affect packets injected via divert. If the daemon wants to inject a packet that does not pass through any more ipfw rules it can specify the rule number of an 'accept rule' directly. (prefereably with a low rule number to reduce overhead). As I mentionned before, a packet injected into teh system is a NEW packet. it cannot and should not be considerred to be the same packet as one that was previously diverted.. Julian On Fri, 29 Sep 2000, Peter Jeremy wrote: > [Please include me in any replies] > > The behaviour of the ipfw divert rule in both 4-STABLE and -CURRENT is > different to the ipfw(8) man page. > > The actual behaviour is that if the diverted packet is written back > into the IP stack, it will re-enter ipfw rule processing at the rule > number following the divert rule[1]. According to my reading of the > code, the same thing happens for a tee rule. > > The man page describes two different actions: > - In the section RULE FORMAT.action.divert, it states "[t]he search > terminates". > - In the section SYSCTL VARIABLES, net.inet.ip.fw.one_pass is > described as controlling divert action as well as pipe action, with > the packet being re-injected at the next rule. > > The term "next rule", used in several places in the man page, is > also slightly misleading: For pipe and queue rules it is the next > rule in sequence. For divert and tee, it is the next rule with a > higher rule number (ie subsequent rules with the same rule number > are skipped). > > IMHO, there should be a way to make the rule search terminate > following a successful divert (which fw.one_pass does for pipes). > The patch below does this, except when the divert process changes > the rule number to 0 - in which case it restarts processing. > Comments please. > > On a different topic, I notice that struct ip_fw includes a field > next_rule_ptr which is documented as "next rule in case of match". > The code in ip_fw_chk() checks this field on skipto's (to avoid > needing to do a linear search for skipto rules). There's even a > function flush_rule_ptrs() which back this use up. Unfortunately, > the code to actually assign next_rule_ptr is missing... Is there > some reason why this isn't used? > > [1] If the divert application uses recvfrom(2)/sendto(2), it can change > the rule number, but the most common divert application (natd) > don't support this. > > Index: ip_fw.c > =================================================================== > RCS file: /home/CVSROOT/src/sys/netinet/ip_fw.c,v > retrieving revision 1.140 > diff -u -r1.140 ip_fw.c > --- ip_fw.c 2000/09/12 02:38:05 1.140 > +++ ip_fw.c 2000/09/29 04:01:41 > @@ -1017,6 +1017,9 @@ > */ > chain = LIST_FIRST(&ip_fw_chain); > if (skipto != 0) { > + /* Accept if passed first test */ > + if (fw_one_pass) > + return 0; > if (skipto >= IPFW_DEFAULT_RULE) > goto dropit; > while (chain && chain->rule->fw_number <= skipto) > > Peter > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Sep 28 22:24:13 2000 Delivered-To: freebsd-net@freebsd.org Received: from alcanet.com.au (mail.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with SMTP id B0D8C37B43C for ; Thu, 28 Sep 2000 22:24:07 -0700 (PDT) Received: by border.alcanet.com.au id <115252>; Fri, 29 Sep 2000 16:23:48 +1000 Content-return: prohibited Date: Fri, 29 Sep 2000 16:24:00 +1100 From: Peter Jeremy Subject: Re: ipfw(8) divert handling In-reply-to: ; from julian@elischer.org on Thu, Sep 28, 2000 at 10:03:10PM -0700 To: Julian Elischer Cc: freebsd-net@FreeBSD.ORG Reply-To: freebsd-net@FreeBSD.ORG, peter.jeremy@alcatel.com.au Message-Id: <00Sep29.162348est.115252@border.alcanet.com.au> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.2.5i References: <00Sep29.150454est.115252@border.alcanet.com.au> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 2000-Sep-28 22:03:10 -0700, Julian Elischer wrote: >Your confusion results from considering the adtions after the divert and >before the divert as being the same pass. Your explanation makes sense, but isn't obvious from the perspective of someone writing a NAT firewall using ipfw. >It so happens, (what a coincidence!) that the state coming out and the >state sent in are identical in format and semantics. The result of this is >that if you re-submit a received packet, along with the state information >that was received with it, the filtering is started at the next higher >rule number than that at which the original divert occured. This is mentioned in the divert(4) man page, but I think it should be in the ipfw(8) and/or natd(8) man pages. >So the man page is correct . The search DID terminate. Not totally, elsewhere it says that the behaviour depends on one_pass (the sysctl description of one_pass in the code says the same thing). Also, it fails to mention that the search will restart if the diverted packet re-enters the kernel. > If the daemon wants to inject a packet that >does not pass through any more ipfw rules it can specify the rule number >of an 'accept rule' directly. natd(8) can't do this. > As I mentionned before, a packet injected into teh >system is a NEW packet. it cannot and should not be considerred to be the >same packet as one that was previously diverted.. Thanks for that. Unless someone comes up with a more convincing reason to support my original POV, I'll write a PR to clarify the documentation and make it match the code. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Sep 28 23: 4:45 2000 Delivered-To: freebsd-net@freebsd.org Received: from urban.iinet.net.au (urban.iinet.net.au [203.59.24.231]) by hub.freebsd.org (Postfix) with ESMTP id 550CC37B423 for ; Thu, 28 Sep 2000 23:04:25 -0700 (PDT) Received: from popserver-02.iinet.net.au (popserver-02.iinet.net.au [203.59.24.148]) by urban.iinet.net.au (8.8.7/8.8.7) with ESMTP id OAA29871; Fri, 29 Sep 2000 14:04:15 +0800 Received: from elischer.org (reggae-39-24.nv.iinet.net.au [203.59.173.24]) by popserver-02.iinet.net.au (8.9.3/8.9.3) with ESMTP id OAA03064; Fri, 29 Sep 2000 14:04:06 +0800 Message-ID: <39D430C0.31F34AA@elischer.org> Date: Thu, 28 Sep 2000 23:03:44 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@FreeBSD.ORG, peter.jeremy@alcatel.com.au Subject: Re: ipfw(8) divert handling References: <00Sep29.150454est.115252@border.alcanet.com.au> <00Sep29.162348est.115252@border.alcanet.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Peter Jeremy wrote: > > On 2000-Sep-28 22:03:10 -0700, Julian Elischer wrote: > >Your confusion results from considering the actions after the divert and > >before the divert as being the same pass. > > Your explanation makes sense, but isn't obvious from the perspective of > someone writing a NAT firewall using ipfw. then I guess we should change the documentation. How would YOU express that idea? (and where) > > >It so happens, (what a coincidence!) that the state coming out and the > >state sent in are identical in format and semantics. The result of this is > >that if you re-submit a received packet, along with the state information > >that was received with it, the filtering is started at the next higher > >rule number than that at which the original divert occured. > > This is mentioned in the divert(4) man page, but I think it should be > in the ipfw(8) and/or natd(8) man pages. ok > > >So the man page is correct . The search DID terminate. > > Not totally, elsewhere it says that the behaviour depends on one_pass > (the sysctl description of one_pass in the code says the same thing). > Also, it fails to mention that the search will restart if the diverted > packet re-enters the kernel. > > > If the daemon wants to inject a packet that > >does not pass through any more ipfw rules it can specify the rule number > >of an 'accept rule' directly. > > natd(8) can't do this. That's not the kernel's problem... I also think that the section in the man page re: one_pass and divert should be removed. > > > As I mentionned before, a packet injected into the > >system is a NEW packet. it cannot and should not be considerred to be the > >same packet as one that was previously diverted.. > > Thanks for that. Unless someone comes up with a more convincing reason > to support my original POV, I'll write a PR to clarify the documentation > and make it match the code. sure > > Peter > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Perth v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 29 1:40:36 2000 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 78F0537B423 for ; Fri, 29 Sep 2000 01:40:17 -0700 (PDT) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.9.3/1.13) id LAA24381; Fri, 29 Sep 2000 11:40:07 +0300 (EEST) Date: Fri, 29 Sep 2000 11:40:07 +0300 From: Ruslan Ermilov To: freebsd-net@FreeBSD.ORG, peter.jeremy@alcatel.com.au Cc: Julian Elischer Subject: Re: ipfw(8) divert handling Message-ID: <20000929114007.B19780@sunbay.com> Mail-Followup-To: freebsd-net@FreeBSD.ORG, peter.jeremy@alcatel.com.au, Julian Elischer References: <00Sep29.150454est.115252@border.alcanet.com.au> <00Sep29.162348est.115252@border.alcanet.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <00Sep29.162348est.115252@border.alcanet.com.au>; from peter.jeremy@alcatel.com.au on Fri, Sep 29, 2000 at 04:24:00PM +1100 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Sep 29, 2000 at 04:24:00PM +1100, Peter Jeremy wrote: > On 2000-Sep-28 22:03:10 -0700, Julian Elischer wrote: > >Your confusion results from considering the adtions after the divert and > >before the divert as being the same pass. > > Your explanation makes sense, but isn't obvious from the perspective of > someone writing a NAT firewall using ipfw. > This is all nicely described in divert(4) manpage, have you looked there? Its section LOOP AVOIDANCE describes how outgoing packets re-enter firewall filter. > >It so happens, (what a coincidence!) that the state coming out and the > >state sent in are identical in format and semantics. The result of this is > >that if you re-submit a received packet, along with the state information > >that was received with it, the filtering is started at the next higher > >rule number than that at which the original divert occured. > > This is mentioned in the divert(4) man page, but I think it should be > in the ipfw(8) and/or natd(8) man pages. > The natd(8) manpage has this info: : After translation by natd, packets re-enter the firewall at the rule : number following the rule number that caused the diversion (not the : next rule if there are several at the same number). > >So the man page is correct . The search DID terminate. > > Not totally, elsewhere it says that the behaviour depends on one_pass > (the sysctl description of one_pass in the code says the same thing). > Also, it fails to mention that the search will restart if the diverted > packet re-enters the kernel. > Yes, the ipfw(8) manpage is incorrect regarding the use of fw.one_pass. I have just committed a fix. > > If the daemon wants to inject a packet that > >does not pass through any more ipfw rules it can specify the rule number > >of an 'accept rule' directly. > > natd(8) can't do this. > But you can, by supplying the `allow' rule right after `divert' one :-) > > As I mentionned before, a packet injected into teh > >system is a NEW packet. it cannot and should not be considerred to be the > >same packet as one that was previously diverted.. > > Thanks for that. Unless someone comes up with a more convincing reason > to support my original POV, I'll write a PR to clarify the documentation > and make it match the code. > No need for that. 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 Sep 29 9: 4:18 2000 Delivered-To: freebsd-net@freebsd.org Received: from ece.rice.edu (ece.rice.edu [128.42.4.34]) by hub.freebsd.org (Postfix) with ESMTP id 2FB6337B422 for ; Fri, 29 Sep 2000 09:04:15 -0700 (PDT) Received: from teddy (teddy.ece.rice.edu [128.42.4.66]) by ece.rice.edu (8.9.0/8.9.0) with SMTP id LAA07825 for ; Fri, 29 Sep 2000 11:04:13 -0500 (CDT) Message-ID: <005c01c02a2e$f93387e0$42042a80@teddy.ece.rice.edu> From: "Ping Yuan" To: Subject: IP header. Date: Fri, 29 Sep 2000 11:04:39 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3612.1700 X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I am now writing a traffic generator. I want to write something in the IP header of every packet before I send it out. Is this possible? If yes, how to implement it? If not, is there any other solutions? Thanks, -ping To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 29 9: 6:22 2000 Delivered-To: freebsd-net@freebsd.org Received: from oceana.nlanr.net (oceana.sdsc.edu [132.249.40.200]) by hub.freebsd.org (Postfix) with ESMTP id C156D37B422 for ; Fri, 29 Sep 2000 09:06:18 -0700 (PDT) Received: from localhost (tshansen@localhost) by oceana.nlanr.net (8.8.6/8.8.6) with SMTP id JAA21173 for ; Fri, 29 Sep 2000 09:06:13 -0700 (PDT) Date: Fri, 29 Sep 2000 09:06:13 -0700 (PDT) From: Todd Hansen To: freebsd-net@FreeBSD.ORG Subject: lucent wavelan cards connecting to a lucent COR Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org has anyone had any experience with getting a lucent wavelan card to connect to a lucent COR under freebsd? Thanks in advance. -todd To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 29 9:18:18 2000 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 5079837B422 for ; Fri, 29 Sep 2000 09:18:14 -0700 (PDT) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.9.3/1.13) id TAA48229; Fri, 29 Sep 2000 19:18:02 +0300 (EEST) Date: Fri, 29 Sep 2000 19:18:01 +0300 From: Ruslan Ermilov To: Ping Yuan Cc: freebsd-net@freebsd.org Subject: Re: IP header. Message-ID: <20000929191801.D47327@sunbay.com> Mail-Followup-To: Ping Yuan , freebsd-net@freebsd.org References: <005c01c02a2e$f93387e0$42042a80@teddy.ece.rice.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <005c01c02a2e$f93387e0$42042a80@teddy.ece.rice.edu>; from pyuan@ece.rice.edu on Fri, Sep 29, 2000 at 11:04:39AM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Sep 29, 2000 at 11:04:39AM -0500, Ping Yuan wrote: > Hi, > > I am now writing a traffic generator. I want to write something in the IP > header of every packet before I send it out. Is this possible? If yes, how > to implement it? If not, is there any other solutions? > You can do that by constructing an IP packet with header and sending it to raw IP socket with IP_HDRINCL socket option set. See ip(4) page for details. 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 Sep 29 9:31:16 2000 Delivered-To: freebsd-net@freebsd.org Received: from base.WN.net.UA (base.wn.net.ua [207.241.169.3]) by hub.freebsd.org (Postfix) with ESMTP id 33B5137B422 for ; Fri, 29 Sep 2000 09:31:12 -0700 (PDT) Received: (from romik@localhost) by base.WN.net.UA (8.9.3/8.9.3) id TAA41930; Fri, 29 Sep 2000 19:34:39 +0300 (EEST) (envelope-from romik) Date: Fri, 29 Sep 2000 19:34:39 +0300 From: "Roman N. Dmitrik" To: Todd Hansen Cc: freebsd-net@FreeBSD.ORG Subject: Re: lucent wavelan cards connecting to a lucent COR Message-ID: <20000929193439.A39137@WN.NET.UA> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from tshansen@nlanr.net on Fri, Sep 29, 2000 at 09:06:13AM -0700 X-NCC-RegID: ua.wnet X-Operating-System: FreeBSD Organization: W-Net Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Sep 29, 2000 at 09:06:13AM -0700, Todd Hansen wrote: R>has anyone had any experience with getting a lucent wavelan card to R>connect to a lucent COR under freebsd? Thanks in advance. Yes, I use a lucent wavelan card under freebsd. -- Regards, Roman D. R> -todd R> R> R> R>To Unsubscribe: send mail to majordomo@FreeBSD.org R>with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 29 9:33:36 2000 Delivered-To: freebsd-net@freebsd.org Received: from oceana.nlanr.net (oceana.sdsc.edu [132.249.40.200]) by hub.freebsd.org (Postfix) with ESMTP id 97C3F37B423 for ; Fri, 29 Sep 2000 09:33:34 -0700 (PDT) Received: from localhost (tshansen@localhost) by oceana.nlanr.net (8.8.6/8.8.6) with SMTP id JAA08912; Fri, 29 Sep 2000 09:33:09 -0700 (PDT) Date: Fri, 29 Sep 2000 09:33:09 -0700 (PDT) From: Todd Hansen To: "Roman N. Dmitrik" Cc: freebsd-net@FreeBSD.ORG Subject: Re: lucent wavelan cards connecting to a lucent COR In-Reply-To: <20000929193439.A39137@WN.NET.UA> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org have you been able to connect with it to a lucent COR as opposed to an Access Point. We can make it work under windows to connect directly but under freebsd we are sort of lost. -todd On Fri, 29 Sep 2000, Roman N. Dmitrik wrote: > On Fri, Sep 29, 2000 at 09:06:13AM -0700, Todd Hansen wrote: > R>has anyone had any experience with getting a lucent wavelan card to > R>connect to a lucent COR under freebsd? Thanks in advance. > Yes, I use a lucent wavelan card under freebsd. > > -- > Regards, > Roman D. > R> -todd > R> > R> > R> > R>To Unsubscribe: send mail to majordomo@FreeBSD.org > R>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 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 29 9:41:55 2000 Delivered-To: freebsd-net@freebsd.org Received: from ece.rice.edu (ece.rice.edu [128.42.4.34]) by hub.freebsd.org (Postfix) with ESMTP id 2194837B61B for ; Fri, 29 Sep 2000 09:40:09 -0700 (PDT) Received: from teddy (teddy.ece.rice.edu [128.42.4.66]) by ece.rice.edu (8.9.0/8.9.0) with SMTP id LAA08676; Fri, 29 Sep 2000 11:40:00 -0500 (CDT) Message-ID: <007a01c02a33$f910f270$42042a80@teddy.ece.rice.edu> From: "Ping Yuan" To: "Ruslan Ermilov" Cc: Subject: Re: IP header. Date: Fri, 29 Sep 2000 11:40:26 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3612.1700 X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >On Fri, Sep 29, 2000 at 11:04:39AM -0500, Ping Yuan wrote: >> Hi, >> >> I am now writing a traffic generator. I want to write something in the IP >> header of every packet before I send it out. Is this possible? If yes, how >> to implement it? If not, is there any other solutions? >> >You can do that by constructing an IP packet with header and sending it to >raw IP socket with IP_HDRINCL socket option set. See ip(4) page for details. > Then, will this IP header be the header of the UDP packet I generated? I mean, if I run tcpdump at the destination host to monitor all the UDP packets, can the bits I set in the ip header be identified? Thanks, -ping > >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 Sep 29 10:12:26 2000 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id C5BE137B422 for ; Fri, 29 Sep 2000 10:12:21 -0700 (PDT) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.9.3/1.13) id UAA51234; Fri, 29 Sep 2000 20:12:12 +0300 (EEST) Date: Fri, 29 Sep 2000 20:12:12 +0300 From: Ruslan Ermilov To: Ping Yuan Cc: freebsd-net@freebsd.org Subject: Re: IP header. Message-ID: <20000929201212.A50668@sunbay.com> Mail-Followup-To: Ping Yuan , freebsd-net@freebsd.org References: <007a01c02a33$f910f270$42042a80@teddy.ece.rice.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <007a01c02a33$f910f270$42042a80@teddy.ece.rice.edu>; from pyuan@ece.rice.edu on Fri, Sep 29, 2000 at 11:40:26AM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Sep 29, 2000 at 11:40:26AM -0500, Ping Yuan wrote: > >On Fri, Sep 29, 2000 at 11:04:39AM -0500, Ping Yuan wrote: > >> Hi, > >> > >> I am now writing a traffic generator. I want to write something in the IP > >> header of every packet before I send it out. Is this possible? If yes, > how > >> to implement it? If not, is there any other solutions? > >> > >You can do that by constructing an IP packet with header and sending it to > >raw IP socket with IP_HDRINCL socket option set. See ip(4) page for > details. > > > > Then, will this IP header be the header of the UDP packet I generated? I > mean, if I run tcpdump at the destination host to monitor all the UDP > packets, can the bits I set in the ip header be identified? > Yes, if you set the ip_p field to IPPROTO_UDP. Please also note that ip_id field (if not-zero) should be given in network byte order, while ip_off and ip_len fields in host byte order. -- 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 Sep 29 10:32:33 2000 Delivered-To: freebsd-net@freebsd.org Received: from piranha.amis.net (piranha.amis.net [212.18.32.3]) by hub.freebsd.org (Postfix) with ESMTP id 4E65B37B422 for ; Fri, 29 Sep 2000 10:32:31 -0700 (PDT) Received: from titanic.medinet.si (titanic.medinet.si [212.18.32.66]) by piranha.amis.net (Postfix) with ESMTP id EFEF95D1C; Fri, 29 Sep 2000 19:32:28 +0200 (CEST) Date: Fri, 29 Sep 2000 19:32:28 +0200 (CEST) From: Blaz Zupan X-Sender: blaz@titanic.medinet.si To: Todd Hansen Cc: freebsd-net@FreeBSD.ORG Subject: Re: lucent wavelan cards connecting to a lucent COR In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > has anyone had any experience with getting a lucent wavelan card to > connect to a lucent COR under freebsd? Thanks in advance. No, because it is not possible. Not even the Linux software has been publicly released. Currently there is only Windows client software available. Blaz Zupan, Medinet d.o.o, Linhartova 21, 2000 Maribor, Slovenia E-mail: blaz@amis.net, Tel: +386-2-320-6320, Fax: +386-2-320-6325 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 29 10:46:17 2000 Delivered-To: freebsd-net@freebsd.org Received: from modemcable101.200-201-24.mtl.mc.videotron.ca (modemcable101.200-201-24.mtl.mc.videotron.ca [24.201.200.101]) by hub.freebsd.org (Postfix) with SMTP id AB9BC37B422 for ; Fri, 29 Sep 2000 10:46:11 -0700 (PDT) Received: (qmail 68238 invoked from network); 29 Sep 2000 17:46:10 -0000 Received: from patrak.local.mindstep.com (HELO PATRAK) (192.168.10.4) by jacuzzi.local.mindstep.com with SMTP; 29 Sep 2000 17:46:10 -0000 Message-ID: <01d001c02a3d$1a04fcc0$040aa8c0@local.mindstep.com> From: "Patrick Bihan-Faou" To: "Evpaty" Cc: , References: <20337579133.20000926123544@russia.crosswinds.net> Subject: Re: Samba 2.0.7 + FreeBSD 4.1-STABLE + W2k sp1 Date: Fri, 29 Sep 2000 13:45:48 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, From: "Evpaty" > su-2.04# ifconfig > rl0: flags=8843 mtu 1500 > inet 10.0.1.102 netmask 0xffffff00 broadcast 10.0.1.255 > inet6 fe80::250:baff:fed1:de26%rl0 prefixlen 64 scopeid 0x1 > ether 00:50:ba:d1:de:26 > media: autoselect (none) status: active > supported media: autoselect 100baseTX 100baseTX 10baseT/UT > P 10baseT/UTP 100baseTX [...] > One of them looks at the coaxial subnet, one - at 100Mbit UTP5 > On the 100Mbit side of the router there is a Windows 2000 Box with 3Com 905B card. I have a problem with Samba from this box. Any operation > > like copying file to or from Samba share is done _extremely_ slow, 60-80 kb per second. This is not a network problem - ftp is 10 times Try disabling the autodetection of the link speed on the rl0 card. To do so either use: # ifconfig rl0 media 10baseT/UTP or # ifconfig rl0 media 100baseTX depending on the actual speed of the network connected to it (I am guessing it is 10 Base T). The rl0 driver has a lot of problems detecting the 10 base T networks, and although you have connectivity and everything appears to be working fine, the performance are really bad until you explicitely tell it to use 10 base T. The "media: autoselect (none) status: active" in ifconfig is a good indication of that problem. Good luck, Patrick. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 29 11: 6:19 2000 Delivered-To: freebsd-net@freebsd.org Received: from oceana.nlanr.net (oceana.sdsc.edu [132.249.40.200]) by hub.freebsd.org (Postfix) with ESMTP id 15C9F37B424 for ; Fri, 29 Sep 2000 11:06:17 -0700 (PDT) Received: from localhost (tshansen@localhost) by oceana.nlanr.net (8.8.6/8.8.6) with SMTP id LAA20700; Fri, 29 Sep 2000 11:06:07 -0700 (PDT) Date: Fri, 29 Sep 2000 11:06:07 -0700 (PDT) From: Todd Hansen To: Blaz Zupan Cc: freebsd-net@FreeBSD.ORG Subject: Re: lucent wavelan cards connecting to a lucent COR In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org ok, thanks for the info. -todd On Fri, 29 Sep 2000, Blaz Zupan wrote: > > has anyone had any experience with getting a lucent wavelan card to > > connect to a lucent COR under freebsd? Thanks in advance. > > No, because it is not possible. Not even the Linux software has been publicly > released. Currently there is only Windows client software available. > > Blaz Zupan, Medinet d.o.o, Linhartova 21, 2000 Maribor, Slovenia > E-mail: blaz@amis.net, Tel: +386-2-320-6320, Fax: +386-2-320-6325 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 29 12:28: 3 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail17.bigmailbox.com (mail17.bigmailbox.com [209.132.220.48]) by hub.freebsd.org (Postfix) with ESMTP id D2F1637B633; Fri, 29 Sep 2000 12:27:58 -0700 (PDT) Received: œby mail17.bigmailbox.com (8.8.7/8.8.7) id MAA26917; Fri, 29 Sep 2000 12:31:46 -0700 Date: Fri, 29 Sep 2000 12:31:46 -0700 Message-Id: <200009291931.MAA26917@mail17.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: [63.28.162.89] From: "gummibear@nettaxi.com" To: questions@freebsd.org, net@freebsd.org Subject: DNS messages: No default TTL set using SOA minimum instead Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello! Can someone explain to me what that means and what I may have done wrong with my DNS configuation? Thanks! Joey ------------------------------------------------------------ Nettaxi MP3 Player, Burner, Ripper - NEW Version 2.0!!! DOWNLOAD IT FREE! (5MBs) MP3 DOWNLOAD: http://www.nettaxi.com/mp3/version_2/ntxy_MP3_setup.exe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 29 12:29:26 2000 Delivered-To: freebsd-net@freebsd.org Received: from virtual.sysadmin-inc.com (lists.sysadmin-inc.com [209.16.228.140]) by hub.freebsd.org (Postfix) with ESMTP id 5344137B633 for ; Fri, 29 Sep 2000 12:29:21 -0700 (PDT) Received: from 98sas ([10.10.1.71]) by virtual.sysadmin-inc.com (8.9.1/8.9.1) with SMTP id PAA10168 for ; Fri, 29 Sep 2000 15:31:36 -0400 Reply-To: From: "Peter Brezny" To: Subject: win98 vpn to mpd-netgraph only accepts pw encrypt? Date: Fri, 29 Sep 2000 15:29:50 -0400 Message-ID: <000a01c02a4b$a3715040$47010a0a@fire.sysadmininc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Has anyone been able to get mpd-netgraph to accept a win98 vpn connection with both the encrypt password and encrypt data check boxes checked? if so, is it just a netgraph configuration deal? i've attached my configs. Thanks for your help. Peter Brezny SysAdmin Services, Inc. mpd.conf default: load pptp # # Mpd as a PPTP server compatible with Microsoft Dial-Up Networking clients. # # Suppose you have a private Office LAN numbered 192.168.1.0/24 and the # machine running mpd is at 192.168.1.1, and also has an externally visible # IP address of 1.2.3.4. # # We want to allow a client to connect to 1.2.3.4 from out on the Internet # via PPTP. We will assign that client the address 192.168.1.2 and proxy-ARP # for that address, so the virtual PPP link will be numbered 192.168.1.1 local # and 192.168.1.2 remote. From the client machine's perspective, it will # appear as if it is actually on the 192.168.1.0/24 network, even though in # reality it is somewhere far away out on the Internet. # # Our DNS server is at 192.168.1.3 and our NT workstation is at 192.168.1.4. # If you don't have an NBNS server (eg, NT workstation), leave that line out. # # See also the 'pptp' link entry in mpd.links.sample. # pptp: new -i ng0 pptp pptp set iface disable on-demand set iface enable proxy-arp set iface idle 1800 set bundle disable multilink set link yes acfcomp protocomp set link no pap chap set link enable chap set link keep-alive 10 60 set ipcp yes vjcomp set ipcp ranges 192.168.1.1/32 192.168.1.2/32 set ipcp dns 10.10.1.1 # set ipcp nbns 192.168.1.4 # If you wanted MPPE encryption and had ng_mppc(8)... # set bundle enable compression # set ccp yes mppc # set ccp yes mpp-e40 # set ccp yes mpp-e128 # set bundle enable crypt-reqd # set ccp yes mpp-stateless mpd.links # # For our PPTP server # pptp: set link type pptp set pptp self 10.10.1.70 set pptp enable incoming set pptp enable originate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 29 12:31:23 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail17.bigmailbox.com (mail17.bigmailbox.com [209.132.220.48]) by hub.freebsd.org (Postfix) with ESMTP id 04C7837B633; Fri, 29 Sep 2000 12:31:20 -0700 (PDT) Received: œby mail17.bigmailbox.com (8.8.7/8.8.7) id MAA27065; Fri, 29 Sep 2000 12:35:07 -0700 Date: Fri, 29 Sep 2000 12:35:07 -0700 Message-Id: <200009291935.MAA27065@mail17.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: [63.28.162.89] From: "gummibear@nettaxi.com" To: questions@freebsd.org, net@freebsd.org Subject: Need help understanding ARP messages in /var/log/messages Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hey all! I'm getting these messages and I'm not sure as to why. Perhaps you can clue me in to what it means and what would cause such messages. Is there a way to fix the problem, if so how? Thanks for all you help! Sep 29 11:56:48 ns /kernel: arp: 10.0.0.5 is on lo0 but got reply from 00:50:04: 18:53:47 on tl0 Sep 29 11:56:48 ns /kernel: arp: 10.0.0.12 is on xl0 but got reply from 00:90:27 :72:38:4d on tl0 Sep 29 12:04:12 ns /kernel: arp: 10.0.0.12 is on xl0 but got reply from 00:90:27 :72:38:4d on tl0 Sep 29 12:13:58 ns /kernel: arp: 10.0.0.12 is on xl0 but got reply from 00:90:27 :72:38:4d on tl0 Joey ------------------------------------------------------------ Nettaxi MP3 Player, Burner, Ripper - NEW Version 2.0!!! DOWNLOAD IT FREE! (5MBs) MP3 DOWNLOAD: http://www.nettaxi.com/mp3/version_2/ntxy_MP3_setup.exe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 29 12:32:58 2000 Delivered-To: freebsd-net@freebsd.org Received: from rapidnet.com (rapidnet.com [205.164.216.1]) by hub.freebsd.org (Postfix) with ESMTP id 968D937B633; Fri, 29 Sep 2000 12:32:49 -0700 (PDT) Received: from localhost (nick@localhost) by rapidnet.com (8.9.3/8.9.3) with ESMTP id NAA40443; Fri, 29 Sep 2000 13:32:32 -0600 (MDT) Date: Fri, 29 Sep 2000 13:32:32 -0600 (MDT) From: Nick Rogness To: "gummibear@nettaxi.com" Cc: questions@freebsd.org, net@freebsd.org Subject: Re: DNS messages: No default TTL set using SOA minimum instead In-Reply-To: <200009291931.MAA26917@mail17.bigmailbox.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 29 Sep 2000, gummibear@nettaxi.com wrote: > > Hello! > Hey. > Can someone explain to me what that means and what I may have done > wrong with my DNS configuation? Thanks! It is a time to live value assigned to each record in your zone. To fix that message add: $TTL 86400 to the top of your zone file above the soa info. Nick Rogness - Drive defensively. Buy a tank. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 29 12:41: 6 2000 Delivered-To: freebsd-net@freebsd.org Received: from ebola.biohz.net (ebola.biohz.net [206.80.1.35]) by hub.freebsd.org (Postfix) with ESMTP id 632C037B650 for ; Fri, 29 Sep 2000 12:41:04 -0700 (PDT) Received: from flu (localhost [127.0.0.1]) by ebola.biohz.net (Postfix) with SMTP id 8F0783A3D1; Fri, 29 Sep 2000 12:41:03 -0700 (PDT) Message-ID: <011801c02a4d$33dc5520$0302010a@biohz.net> From: "Renaud Waldura" To: Cc: References: <000a01c02a4b$a3715040$47010a0a@fire.sysadmininc.com> Subject: Re: win98 vpn to mpd-netgraph only accepts pw encrypt? Date: Fri, 29 Sep 2000 12:41:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Look up the archives at http://www.freebsd.org/search/search.html Your configuration was discussed fairly recently. I have also made available a sample config file for doing this at http://renaud.waldura.com/doc/freebsd-pptp/ --Renaud ----- Original Message ----- From: Peter Brezny To: Sent: Friday, September 29, 2000 12:29 PM Subject: win98 vpn to mpd-netgraph only accepts pw encrypt? > Has anyone been able to get > > mpd-netgraph to accept a win98 vpn connection with both the encrypt password > and encrypt data check boxes checked? > > if so, is it just a netgraph configuration deal? > > i've attached my configs. > > Thanks for your help. > > Peter Brezny > SysAdmin Services, Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Sep 30 7: 3:43 2000 Delivered-To: freebsd-net@freebsd.org Received: from mta03.onebox.com (mta03.onebox.com [216.33.158.210]) by hub.freebsd.org (Postfix) with ESMTP id 64C6B37B502 for ; Sat, 30 Sep 2000 07:03:41 -0700 (PDT) Received: from onebox.com ([216.33.158.148]) by mta03.onebox.com (InterMail vM.4.01.02.27 201-229-119-110) with SMTP id <20000930140341.DASZ321.mta03.onebox.com@onebox.com> for ; Sat, 30 Sep 2000 07:03:41 -0700 Received: from [203.107.232.70] by onebox.com with HTTP; Sat, 30 Sep 2000 07:03:41 -0700 Date: Sat, 30 Sep 2000 07:03:41 -0700 Subject: How to connect to Internet with 2 ISP. From: "Chutima S." To: freebsd-net@FreeBSD.ORG Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Message-Id: <20000930140341.DASZ321.mta03.onebox.com@onebox.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi I have an Internet network for my company. This network contains our Internet servers, link to one ISP and a gateway (FreeBSD box with two lan cards) act as a proxy for internal network (use interneal IP address). But I have to assure Internet connection will up all the time. If I want to connect to another ISP to my internal network. How should I arrange about IP address, routing, DNS, security? Where should I find these information? Thanks Chutima S. -- Chutima Subsirin chutima_s@zdnetonebox.com - email (202) 777-2641 ext. 6020 - voicemail/fax ___________________________________________________________________ To get your own FREE ZDNet Onebox - FREE voicemail, email, and fax, all in one place - sign up today at http://www.zdnetonebox.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Sep 30 9:32:53 2000 Delivered-To: freebsd-net@freebsd.org Received: from rapidnet.com (rapidnet.com [205.164.216.1]) by hub.freebsd.org (Postfix) with ESMTP id CBE6B37B503 for ; Sat, 30 Sep 2000 09:32:50 -0700 (PDT) Received: from localhost (nick@localhost) by rapidnet.com (8.9.3/8.9.3) with ESMTP id KAA12603; Sat, 30 Sep 2000 10:32:49 -0600 (MDT) Date: Sat, 30 Sep 2000 10:32:49 -0600 (MDT) From: Nick Rogness To: "Chutima S." Cc: freebsd-net@FreeBSD.ORG Subject: Re: How to connect to Internet with 2 ISP. In-Reply-To: <20000930140341.DASZ321.mta03.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 X-Loop: FreeBSD.org On Sat, 30 Sep 2000, Chutima S. wrote: > Hi > hello. > > How should I arrange about IP address, routing, DNS, security? Where > should I find these information? The only way to answer this question is to determine your needs. Is redundancy the only concern? Do you want load balancing? One thing is for sure, your probably want to look at some type of dynamic routing protocol. gated can accompish most of your needs (/usr/ports/net/gated), including BGP, which is what most people (99.9%) of people use to peer with other AS's. You will have to work with your ISP's to determine which type of routing options they have available and then building gated to work with that setup (www.gated.org). If, however, your upstreams do not want to do some type of routing, you will be stuck with just using static routes. DNS is pretty straight forward. Have the ISP delegate authority for the reverses (in-addr.arpa) to your DNS server. Get a good naming scheme setup. Designing IP address scheme's is quite involved and is out of scope for this mail. Let your routing decisions play a role in that. Security is such a broad topic, lets look at 2 different areas. The first being network security, have a good firewall (acl) in place to prevent spoofing, route filtering (Don't announce networks you don't own). Determine filtering on your edge (access) layer but minimize on your core...etc,etc. Develop a solid architecture. The Core-Distribution-Access model is used quite often throughout the internet. The second being systems security. Put in place a good Intrusion Detection System. The best in the business right now (IMHO) is snort (www.snort.org) which can do all, if not more, then most of the commercial IDS systems, like ISS,etc...and it takes little load to run a big ruleset (hence the light-weight part of it). Use encryption wherever (or whenever) possible. Little or weak encryption is STILL better than none at all ;-) Buy some books, do some research (Case studies). Nick Rogness - Drive defensively. Buy a tank. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message