From owner-freebsd-net Sun May 20 0:14: 3 2001 Delivered-To: freebsd-net@freebsd.org Received: from brinstar.nerim.net (brinstar.nerim.net [62.4.16.71]) by hub.freebsd.org (Postfix) with ESMTP id 6AD4B37B424 for ; Sun, 20 May 2001 00:14:00 -0700 (PDT) (envelope-from chojin@nerim.net) Received: from chojin (chojin.adsl.nerim.net [62.4.22.98]) by brinstar.nerim.net (8.11.2/Raphit-20001115) with SMTP id f4K7Dww02999 for ; Sun, 20 May 2001 09:13:59 +0200 (CEST) (envelope-from chojin@nerim.net) Message-ID: <000701c0e0fc$83a9d620$0245a8c0@chojin> From: "Chojin" To: References: Subject: Re: Restricting traffic on one interface Date: Sun, 20 May 2001 09:14:29 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Use ipf (it's not ipfw) ----- Original Message ----- From: "Orville R. Weyrich.Jr" Cc: "Freebsd Net (E-mail)" Sent: Sunday, May 20, 2001 8:07 AM Subject: Restricting traffic on one interface > Hi -- > > I have a dual homed FreeBSD-4.3 machine and want to restrict traffic on > one interface but not the other (one interface is to a trusted network and > the other is not). > > What I want is the untrusted interface to only present SMTP and HTTP > ports, while the trusted interface presents telnet, ftp, NFS, SMB, etc. > > What is the best way to do this? The machine does NOT have IP forwarding > enabled. > > ------------------------------------------------------------------- > Orville R. Weyrich, Jr. Weyrich Computer Consulting > mailto:orville@weyrich.com KD7HJV http://www.weyrich.com > ------------------------------------------------------------------- > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun May 20 1: 9: 8 2001 Delivered-To: freebsd-net@freebsd.org Received: from cody.jharris.com (cody.jharris.com [205.238.128.83]) by hub.freebsd.org (Postfix) with ESMTP id 1072737B424 for ; Sun, 20 May 2001 01:09:06 -0700 (PDT) (envelope-from nick@rogness.net) Received: from localhost (nick@localhost) by cody.jharris.com (8.11.1/8.9.3) with ESMTP id f4K9Ncs75791; Sun, 20 May 2001 04:23:38 -0500 (CDT) (envelope-from nick@rogness.net) Date: Sun, 20 May 2001 04:23:37 -0500 (CDT) From: Nick Rogness X-Sender: nick@cody.jharris.com To: "Orville R. Weyrich.Jr" Cc: "Freebsd Net (E-mail)" Subject: Re: Restricting traffic on one interface In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, 19 May 2001, Orville R. Weyrich.Jr wrote: > I have a dual homed FreeBSD-4.3 machine and want to restrict traffic > on one interface but not the other (one interface is to a trusted > network and the other is not). > > What I want is the untrusted interface to only present SMTP and HTTP > ports, while the trusted interface presents telnet, ftp, NFS, SMB, > etc. > > What is the best way to do this? The machine does NOT have IP > forwarding enabled. Run a firewall to block traffic on that interface. You can search the archives or the web for more information. See also ipfw man page. Of course, there are other ways to do this, but firewalling is probably best suited for this task. Nick Rogness - Keep on Routing in a Free World... "FreeBSD: The Power to Serve!" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun May 20 10:45:53 2001 Delivered-To: freebsd-net@freebsd.org Received: from mario.zyan.com (mario.zyan.com [209.250.96.140]) by hub.freebsd.org (Postfix) with ESMTP id 213EA37B440 for ; Sun, 20 May 2001 10:45:50 -0700 (PDT) (envelope-from orville@weyrich.com) Received: from dopey.weyrich.com (orville@node-64-249-12-250.dslspeed.zyan.com [64.249.12.250]) by mario.zyan.com (8.9.3/8.9.3) with ESMTP id KAA11765 for ; Sun, 20 May 2001 10:45:49 -0700 (PDT) (envelope-from orville@weyrich.com) Received: from localhost (orville@localhost) by dopey.weyrich.com (8.9.3/8.6.9) with ESMTP id KAA08005; Sun, 20 May 2001 10:29:55 -0700 Date: Sun, 20 May 2001 10:29:55 -0700 (MST) From: "Orville R. Weyrich.Jr" To: Nick Rogness Cc: "Freebsd Net (E-mail)" Subject: Re: Restricting traffic on one interface In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Yes, a firewall. This machine IS the inner side of a firewall -- I want to stop any unwanted traffic that gets through the outer firewall. orville. On Sun, 20 May 2001, Nick Rogness wrote: > On Sat, 19 May 2001, Orville R. Weyrich.Jr wrote: > > > I have a dual homed FreeBSD-4.3 machine and want to restrict traffic > > on one interface but not the other (one interface is to a trusted > > network and the other is not). > > > > > What I want is the untrusted interface to only present SMTP and HTTP > > ports, while the trusted interface presents telnet, ftp, NFS, SMB, > > etc. > > > > > What is the best way to do this? The machine does NOT have IP > > forwarding enabled. > > Run a firewall to block traffic on that interface. You can search > the archives or the web for more information. See also ipfw man > page. > > Of course, there are other ways to do this, but firewalling is > probably best suited for this task. > > Nick Rogness > - Keep on Routing in a Free World... > "FreeBSD: The Power to Serve!" > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > =================================================================== IF YOU WANT REFORM >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> VOTE REFORM ------------------------------------------------------------------- Orville R. Weyrich, Jr. Weyrich Computer Consulting mailto:orville@weyrich.com KD7HJV http://www.weyrich.com ------------------------------------------------------------------- Visit our online collection of book reviews: http://www.weyrich.com/book_reviews/ Ask about our world wide web services! ------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun May 20 14:56:38 2001 Delivered-To: freebsd-net@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 9BA4037B424 for ; Sun, 20 May 2001 14:56:35 -0700 (PDT) (envelope-from iedowse@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 20 May 2001 22:56:34 +0100 (BST) To: freebsd-net@freebsd.org Subject: Using connect() on UDP RPC client sockets. Date: Sun, 20 May 2001 22:56:34 +0100 From: Ian Dowse Message-ID: <200105202256.aa30752@salmon.maths.tcd.ie> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The RPC client code in libc performs UDP RPC calls with sendto() and recvfrom() using an unconnected socket. When a reply arrives, the library code checks only that the XID of the reply matches that of the request; it does not check that the reply came from the address to which the request was sent. I assume that this behaviour exists to deal with unusual servers that reply from the wrong address or port. However, since RPC is used for a number of security-sensitive protocols, this approach is not ideal, and its implications for firewall design may be surprising to some. Using sendto/recvfrom also has the disadvantage that the results of ICMP errors are not made available to the application. This can result in long timeout delays instead of a quick ECONNREFUSED or ENETRESET reply. I would like to change the RPC client code to use connect() for UDP sockets. I think this would be a more modern behaviour; it is more secure, and ICMP errors get reported back to the application. This does not require any API changes, and for most applications there will be no noticable difference in behaviour. However, I don't claim to have a lot of experience in the area of RPC, so I'd be grateful for any suggestions or comments related to taking this approach. Specifically: * Is there anything I am missing? e.g. are there any reasons that accepting a reply from any address simply must be allowed? * Should this behaviour be optional? If so should it be controllable in some system-wide fashion, or just by the application? The clnt_control() mechanism would be suitable for application-level control. * Are the issues caused by multi-homed hosts common enough that we should ensure all our RPC servers have a facility for listening on multiple UDP sockets, or implement the reverse of IP_RECVDSTADDR or whatever before changing the default RPC behaviour? Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun May 20 15:40:59 2001 Delivered-To: freebsd-net@freebsd.org Received: from tp.databus.com (p101-46.acedsl.com [160.79.101.46]) by hub.freebsd.org (Postfix) with ESMTP id ACFC637B424 for ; Sun, 20 May 2001 15:40:54 -0700 (PDT) (envelope-from barney@tp.databus.com) Received: (from barney@localhost) by tp.databus.com (8.11.3/8.11.3) id f4KMeXm83714; Sun, 20 May 2001 18:40:33 -0400 (EDT) (envelope-from barney) Date: Sun, 20 May 2001 18:40:33 -0400 From: Barney Wolff To: Ian Dowse Cc: freebsd-net@FreeBSD.ORG Subject: Re: Using connect() on UDP RPC client sockets. Message-ID: <20010520184033.A83645@tp.databus.com> References: <200105202256.aa30752@salmon.maths.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200105202256.aa30752@salmon.maths.tcd.ie>; from iedowse@maths.tcd.ie on Sun, May 20, 2001 at 10:56:34PM +0100 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 1. Multi-homed hosts are in fact very common, especially in corporate environments. To get the right source addr in its reply, the server must open separate sockets on each of its host's addresses - as named and ntpd do. And then it has to detect changes in the set of addresses. Hard work for not a lot of gain. 2. Source addr is so easy to spoof that it adds nothing to security. 3. I have not examined the kernel's socket-finding code, but it is by no means guaranteed that performance with individual connected sockets will be better, or even as good, as that with a single unconnected socket. On the other hand, it would multiply kernel buffering, which can be good or bad. I have myself used connect on udp sockets, and fought a battle with the multi-homed server guy. I won but in retrospect it was a fight that was not necessary. Where an RFC mandates that the reply source address must be the same as the request dest addr (as it does for dns, radius, some others) the extra work on the server's part is mandatory. Is it mandated for rpc? Barney Wolff On Sun, May 20, 2001 at 10:56:34PM +0100, Ian Dowse wrote: > > The RPC client code in libc performs UDP RPC calls with sendto() > and recvfrom() using an unconnected socket. When a reply arrives, > the library code checks only that the XID of the reply matches that > of the request; it does not check that the reply came from the > address to which the request was sent. > > I assume that this behaviour exists to deal with unusual servers > that reply from the wrong address or port. However, since RPC is > used for a number of security-sensitive protocols, this approach > is not ideal, and its implications for firewall design may be > surprising to some. > > Using sendto/recvfrom also has the disadvantage that the results > of ICMP errors are not made available to the application. This can > result in long timeout delays instead of a quick ECONNREFUSED or > ENETRESET reply. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon May 21 1:21:24 2001 Delivered-To: freebsd-net@freebsd.org Received: from mario.zyan.com (mario.zyan.com [209.250.96.140]) by hub.freebsd.org (Postfix) with ESMTP id C282C37B424 for ; Mon, 21 May 2001 01:21:20 -0700 (PDT) (envelope-from orville@weyrich.com) Received: from dopey.weyrich.com (orville@node-64-249-12-250.dslspeed.zyan.com [64.249.12.250]) by mario.zyan.com (8.9.3/8.9.3) with ESMTP id BAA34084 for ; Mon, 21 May 2001 01:21:19 -0700 (PDT) (envelope-from orville@weyrich.com) Received: from localhost (orville@localhost) by dopey.weyrich.com (8.9.3/8.6.9) with ESMTP id BAA11619; Mon, 21 May 2001 01:05:47 -0700 Date: Mon, 21 May 2001 01:05:47 -0700 (MST) From: "Orville R. Weyrich.Jr" To: Chojin Cc: freebsd-net@FreeBSD.ORG Subject: Re: Restricting traffic on one interface In-Reply-To: <000701c0e0fc$83a9d620$0245a8c0@chojin> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Thanks for the suggestion, but where do I get ipf? I don't see it in the FreeBSD packages region under networking or security. The closest I see in functionality I see is xinetd, but it only seems to allow me to specity ip addresses to enable/disable, but does not seem to have an option to specify the network interface. I guess xinetd is better than nothing, if I trust the outer firewall to filter out unexpected incoming ip addresses, but the whole point is that I do NOT trust the outer firewall to do it's job perfectly. Regards, orville. On Sun, 20 May 2001, Chojin wrote: > Use ipf > (it's not ipfw) > ----- Original Message ----- > From: "Orville R. Weyrich.Jr" > Cc: "Freebsd Net (E-mail)" > Sent: Sunday, May 20, 2001 8:07 AM > Subject: Restricting traffic on one interface > > > > Hi -- > > > > I have a dual homed FreeBSD-4.3 machine and want to restrict traffic on > > one interface but not the other (one interface is to a trusted network and > > the other is not). > > > > What I want is the untrusted interface to only present SMTP and HTTP > > ports, while the trusted interface presents telnet, ftp, NFS, SMB, etc. > > > > What is the best way to do this? The machine does NOT have IP forwarding > > enabled. > > > > ------------------------------------------------------------------- > > Orville R. Weyrich, Jr. Weyrich Computer Consulting > > mailto:orville@weyrich.com KD7HJV http://www.weyrich.com > > ------------------------------------------------------------------- > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > =================================================================== IF YOU WANT REFORM >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> VOTE REFORM ------------------------------------------------------------------- Orville R. Weyrich, Jr. Weyrich Computer Consulting mailto:orville@weyrich.com KD7HJV http://www.weyrich.com ------------------------------------------------------------------- Visit our online collection of book reviews: http://www.weyrich.com/book_reviews/ Ask about our world wide web services! ------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon May 21 1:27:22 2001 Delivered-To: freebsd-net@freebsd.org Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by hub.freebsd.org (Postfix) with ESMTP id 6771A37B42C for ; Mon, 21 May 2001 01:27:17 -0700 (PDT) (envelope-from luigi@info.iet.unipi.it) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id KAA06519; Mon, 21 May 2001 10:23:50 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200105210823.KAA06519@info.iet.unipi.it> Subject: Re: Restricting traffic on one interface In-Reply-To: from "Orville R. Weyrich.Jr" at "May 21, 2001 01:05:47 am" To: "Orville R. Weyrich.Jr" Date: Mon, 21 May 2001 10:23:50 +0200 (CEST) Cc: Chojin , freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > Thanks for the suggestion, but where do I get ipf? I don't see it in the it is part of the base system. BTW both ipfilter and ipfw seem to do the job you want, so recommending the use of one instead of the other is as technically sound as saying to disconnect the network cable on the internal side (which is the most secure thing you can do provided you do not have a wireless card on the motherboard... these days you cannot trust anything anymore!) cheers luigi > FreeBSD packages region under networking or security. The closest I see > in functionality I see is xinetd, but it only seems to allow me to specity > ip addresses to enable/disable, but does not seem to have an option to > specify the network interface. > > I guess xinetd is better than nothing, if I trust the outer firewall to > filter out unexpected incoming ip addresses, but the whole point is that I > do NOT trust the outer firewall to do it's job perfectly. > > Regards, > > orville. > > On Sun, 20 May 2001, Chojin wrote: > > > Use ipf > > (it's not ipfw) > > ----- Original Message ----- > > From: "Orville R. Weyrich.Jr" > > Cc: "Freebsd Net (E-mail)" > > Sent: Sunday, May 20, 2001 8:07 AM > > Subject: Restricting traffic on one interface > > > > > > > Hi -- > > > > > > I have a dual homed FreeBSD-4.3 machine and want to restrict traffic on > > > one interface but not the other (one interface is to a trusted network and > > > the other is not). > > > > > > What I want is the untrusted interface to only present SMTP and HTTP > > > ports, while the trusted interface presents telnet, ftp, NFS, SMB, etc. > > > > > > What is the best way to do this? The machine does NOT have IP forwarding > > > enabled. > > > > > > ------------------------------------------------------------------- > > > Orville R. Weyrich, Jr. Weyrich Computer Consulting > > > mailto:orville@weyrich.com KD7HJV http://www.weyrich.com > > > ------------------------------------------------------------------- > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > with "unsubscribe freebsd-net" in the body of the message > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > > > =================================================================== > IF YOU WANT REFORM >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> VOTE REFORM > ------------------------------------------------------------------- > Orville R. Weyrich, Jr. Weyrich Computer Consulting > mailto:orville@weyrich.com KD7HJV http://www.weyrich.com > ------------------------------------------------------------------- > Visit our online collection of book reviews: > > http://www.weyrich.com/book_reviews/ > > Ask about our world wide web services! > ------------------------------------------------------------------- > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon May 21 2: 4:40 2001 Delivered-To: freebsd-net@freebsd.org Received: from samar.sasken.com (samar.sasken.com [164.164.56.2]) by hub.freebsd.org (Postfix) with ESMTP id 5A79137B42C for ; Mon, 21 May 2001 02:04:35 -0700 (PDT) (envelope-from sumahr@sasken.com) Received: from samar (localhost [127.0.0.1]) by samar.sasken.com (8.11.3/8.11.3) with SMTP id f4L94Lf07577 for ; Mon, 21 May 2001 14:34:21 +0530 (IST) Received: from localhost (sumahr@localhost) by sunk3.sasi.com (8.9.3/8.9.3) with ESMTP id OAA28018; Mon, 21 May 2001 14:34:02 +0530 (IST) Date: Mon, 21 May 2001 14:34:02 +0530 (IST) From: Suma H R X-Sender: To: Cc: Suma H R Subject: Multiple IP addresses on the same host Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, We have an ethernet host & many pseudo ethernet interfaces configured. Suppose I send a packet to pseudo ethernet interface. The reply from pseudo ethernet interface is sent through the physical interface. This response, has the IP address of the physical interface instead of the IP address of Pseudo Ethernet Interface. So, the host which sent a packet to pseudo ethernet interface, is discarding this packet because of the IP address. Can anybody tell me why this is happening & suggest some way to correct it? I guess this is happening because we bind the socket to INADDR_ANY. Is that right??? Thanks, Suma To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon May 21 5:10:43 2001 Delivered-To: freebsd-net@freebsd.org Received: from ns.asdg.ru (ns.asdg.ru [212.164.69.2]) by hub.freebsd.org (Postfix) with ESMTP id 0BDAE37B422; Mon, 21 May 2001 05:10:36 -0700 (PDT) (envelope-from alex@asdg.ru) Received: from alex ([212.164.69.25]) by ns.asdg.ru (8.11.2/8.11.2) with SMTP id f4LCAe443925; Mon, 21 May 2001 19:10:41 +0700 (NOVST) (envelope-from alex@asdg.ru) Message-ID: <000901c0e1f7$716cc7a0$1945a4d4@asdg.ru> From: "Alex Markov" To: Subject: L2TP and FreeBSD - is it possible? Date: Mon, 21 May 2001 19:10:41 +0600 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Fidolook Express 2.000 for MS OE5 Organization: Fidolook Express 2.000 www.fidolook.da.ru Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello, FreeBSD community! Firstly, excuse my English! ;-) DESCRIPTION: I have Win2000 server in private network (IP = 192.168.1.1) and FreeBSD box with two netcards (one of them plugged to 192.168.1/24 network, another - in ISP's LAN). On FreeBSD i have "closed"-style firewall and some services (primary DNS, proxy & mail). I have not and even don't plan to install NAT on this box. Now, i want to grant access for our remote users to Win2000 server in internal network through L2TP+IPSec. Latter part doesn't bother me, but former... So, i need a good advice from guru: a) Is L2TP supported by FreeBSD? b) Which way is more "right" - to install L2TP server on Win2000 and divert all VPN traffic to it, or configure FreeBSD box as L2TP server? c) Is there any resources about "L2TP & FreeBSD" (i know, it should be first question)? Please, cc: to my e-mail, 'cos i have not enough time to looking through all freebsd's maillists. Thanks in advance! -- WBR, Alex Markov. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon May 21 6:43:15 2001 Delivered-To: freebsd-net@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 162F837B42C for ; Mon, 21 May 2001 06:43:11 -0700 (PDT) (envelope-from iedowse@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 21 May 2001 14:43:10 +0100 (BST) To: Barney Wolff Cc: Ian Dowse , freebsd-net@FreeBSD.ORG Subject: Re: Using connect() on UDP RPC client sockets. In-Reply-To: Your message of "Sun, 20 May 2001 18:40:33 EDT." <20010520184033.A83645@tp.databus.com> Date: Mon, 21 May 2001 14:43:09 +0100 From: Ian Dowse Message-ID: <200105211443.aa07793@salmon.maths.tcd.ie> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In message <20010520184033.A83645@tp.databus.com>, Barney Wolff writes: >1. Multi-homed hosts are in fact very common, especially in > corporate environments. To get the right source addr in > its reply, the server must open separate sockets on each > of its host's addresses - as named and ntpd do. And then > it has to detect changes in the set of addresses. Hard > work for not a lot of gain. An alternative to this approach on the server side, which has been discussed before, is a mechanism to set the source address of individual outgoing UDP datagrams. There is already the IP_RECVDSTADDR socket option which can be used to determine the source address of the incoming packet: If the IP_RECVDSTADDR option is enabled on a SOCK_DGRAM socket, the recvmsg(2) call will return the destination IP address for a UDP datagram. The msg_control field in the msghdr structure points to a buffer that contains a cmsghdr structure followed by the IP address. The cmsghdr fields have the following values: cmsg_len = sizeof(struct in_addr) cmsg_level = IPPROTO_IP cmsg_type = IP_RECVDSTADDR If an IP_SENDSRCADDR control message was implemented, servers could use it to reply from the address to which the request was sent. This would not require opening additional sockets, and it would not need to detect interface address changes. Another alternative would be to make IP_HDRINCL work with UDP sockets, so that the server could construct a UDP header at the start of the datagram containing the required source address. I would prefer to see the server-side issue being fixed so that the clients can use the simple, secure approach. Then for interoperating with `broken' servers, there needs to be a way to revert to the old client behaviour. >2. Source addr is so easy to spoof that it adds nothing to security. True, but internal networks can be trivially protected from spoofed packets coming in from less secure networks, and this is one of the most basic levels of filtering employed by most firewalls. Also, local unpriviledged accounts on unix servers cannot be used to spoof source addresses. However in both of these cases, it may still be possible to get a bogus reply accepted by an RPC client. Incoming packets do not need to spoof any addresses - they just require that the firewall lets in packets to UDP ports (i.e. many stateless firewalls). Local unpriviledged users can also send bogus replies simply by opening a UDP socket and sending a datagram to the RPC client port. It is this behaviour that I think is undesirable, and may be surprising to many people. Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon May 21 8:24:23 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by hub.freebsd.org (Postfix) with SMTP id 1774437B42C for ; Mon, 21 May 2001 08:24:19 -0700 (PDT) (envelope-from tmoestl@gmx.net) Received: (qmail 32412 invoked by uid 0); 21 May 2001 15:24:17 -0000 Received: from p3e9e03cc.dip.t-dialin.net (HELO forge.local) (62.158.3.204) by mail.gmx.net (mp006-rz3) with SMTP; 21 May 2001 15:24:17 -0000 Received: from tmm by forge.local with local (Exim 3.20 #1) id 151rXf-0000Ds-00; Mon, 21 May 2001 17:24:19 +0200 Date: Mon, 21 May 2001 17:24:19 +0200 From: Thomas Moestl To: Ian Dowse Cc: Barney Wolff , freebsd-net@FreeBSD.ORG Subject: Re: Using connect() on UDP RPC client sockets. Message-ID: <20010521172419.A672@crow.dom2ip.de> Mail-Followup-To: Thomas Moestl , Ian Dowse , Barney Wolff , freebsd-net@FreeBSD.ORG References: <20010520184033.A83645@tp.databus.com> <200105211443.aa07793@salmon.maths.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200105211443.aa07793@salmon.maths.tcd.ie>; from iedowse@maths.tcd.ie on Mon, May 21, 2001 at 02:43:09PM +0100 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 2001/05/21 at 14:43:09 +0100, Ian Dowse wrote: > In message <20010520184033.A83645@tp.databus.com>, Barney Wolff writes: > >1. Multi-homed hosts are in fact very common, especially in > > corporate environments. To get the right source addr in > > its reply, the server must open separate sockets on each > > of its host's addresses - as named and ntpd do. And then > > it has to detect changes in the set of addresses. Hard > > work for not a lot of gain. > > An alternative to this approach on the server side, which has been > discussed before, is a mechanism to set the source address of > individual outgoing UDP datagrams. There is already the IP_RECVDSTADDR > socket option which can be used to determine the source address of > the incoming packet: > > If the IP_RECVDSTADDR option is enabled on a SOCK_DGRAM > socket, the recvmsg(2) call will return the destination IP > address for a UDP datagram. The msg_control field in the > msghdr structure points to a buffer that contains a cmsghdr > structure followed by the IP address. The cmsghdr fields > have the following values: > > cmsg_len = sizeof(struct in_addr) > cmsg_level = IPPROTO_IP > cmsg_type = IP_RECVDSTADDR > > If an IP_SENDSRCADDR control message was implemented, servers could > use it to reply from the address to which the request was sent. > This would not require opening additional sockets, and it would > not need to detect interface address changes. I have a patch that does just that (although it just overloads IP_RECVDSTADDR for sendmsg instead of creating a new flag). I wrote it some time ago for a DNS server (the standard requires the source address to be the address the packet went to). It may need some resynching, but if you want, I can dig it out and prepare it for committing. I anyway wanted to do this some time... - thomas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon May 21 10:56: 6 2001 Delivered-To: freebsd-net@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id D94C637B42C for ; Mon, 21 May 2001 10:56:03 -0700 (PDT) (envelope-from iedowse@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 21 May 2001 18:56:03 +0100 (BST) To: Thomas Moestl Cc: Ian Dowse , Barney Wolff , freebsd-net@FreeBSD.ORG Subject: Re: Using connect() on UDP RPC client sockets. In-Reply-To: Your message of "Mon, 21 May 2001 17:24:19 +0200." <20010521172419.A672@crow.dom2ip.de> Date: Mon, 21 May 2001 18:56:02 +0100 From: Ian Dowse Message-ID: <200105211856.aa41143@salmon.maths.tcd.ie> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In message <20010521172419.A672@crow.dom2ip.de>, Thomas Moestl writes: > >I have a patch that does just that (although it just overloads >IP_RECVDSTADDR for sendmsg instead of creating a new flag). I wrote it >some time ago for a DNS server (the standard requires the source >address to be the address the packet went to). It may need some >resynching, but if you want, I can dig it out and prepare it for >committing. I anyway wanted to do this some time... Thanks! I know I had seen this somewhere - turns out I had saved it in my freebsd-net mailbox too. Getting this functionality committed would be a great first step towards resolving the wrong- address issue at least between FreeBSD hosts. I think the option should be renamed to something like IP_SENDSRCADDR just to avoid confusion - does this seem reasonable? I'll read through the patch shortly and maybe see if it still applies. Actually, a bit more searching has shown up some more posibilities. IPv6 uses a IPV6_PKTINFO option, based on the in6_pktinfo struct: struct in6_pktinfo { struct in6_addr ipi6_addr; /* src/dst IPv6 address */ unsigned int ipi6_ifindex; /* send/recv interface index */ }; and it seems Linux has something similar for IPv4 which uses an IP_PKTINFO option: struct in_pktinfo { unsigned int ipi_ifindex; /* Interface index */ struct in_addr ipi_spec_dst;/* Routing destination address */ struct in_addr ipi_addr; /* Header Destination address */ }; I think the idea of both is that you can specify the source address and interface of outgoing packets, and get the destination address and receive interface of incoming packets. I suppose the ipi_spec_dst in the Linux in_pktinfo is to use a different destination address for the routing table lookup; I'm not sure why you'd want to do that though. Would that seem a better interface to implement? Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon May 21 11: 2: 4 2001 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id CAE1637B422 for ; Mon, 21 May 2001 11:02:01 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id OAA08653; Mon, 21 May 2001 14:01:54 -0400 (EDT) (envelope-from wollman) Date: Mon, 21 May 2001 14:01:54 -0400 (EDT) From: Garrett Wollman Message-Id: <200105211801.OAA08653@khavrinen.lcs.mit.edu> To: Ian Dowse Cc: freebsd-net@FreeBSD.ORG Subject: Re: Using connect() on UDP RPC client sockets. In-Reply-To: <200105211856.aa41143@salmon.maths.tcd.ie> References: <20010521172419.A672@crow.dom2ip.de> <200105211856.aa41143@salmon.maths.tcd.ie> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org < said: > I think the option should be renamed to something like IP_SENDSRCADDR > just to avoid confusion - does this seem reasonable? I think it's OK to add an additional name for the same control message, but it should be possible (and documented) to use the exact control message as was returned from recvmsg() as argument to sendmsg(). -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon May 21 11:50:20 2001 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 95F8A37B424 for ; Mon, 21 May 2001 11:50:18 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id OAA09062; Mon, 21 May 2001 14:50:13 -0400 (EDT) (envelope-from wollman) Date: Mon, 21 May 2001 14:50:13 -0400 (EDT) From: Garrett Wollman Message-Id: <200105211850.OAA09062@khavrinen.lcs.mit.edu> To: Barney Wolff Cc: freebsd-net@FreeBSD.ORG Subject: Re: Using connect() on UDP RPC client sockets. In-Reply-To: <20010520184033.A83645@tp.databus.com> References: <200105202256.aa30752@salmon.maths.tcd.ie> <20010520184033.A83645@tp.databus.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org < said: > Where an RFC mandates that the reply source address must be the same > as the request dest addr This is true for *any* protocol built over IP, regardless of what the individual protocol specifications say. See RFC 1122 sections 3.3.4.2, 4.1.3.5, and 4.2.3.7. (It actually says ``SHOULD'' in the first two sections, which translates as ``you'd better have a damn good reason not to''.) -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon May 21 21:17:22 2001 Delivered-To: freebsd-net@freebsd.org Received: from tp.databus.com (p101-46.acedsl.com [160.79.101.46]) by hub.freebsd.org (Postfix) with ESMTP id 5DA2E37B422 for ; Mon, 21 May 2001 21:17:19 -0700 (PDT) (envelope-from barney@tp.databus.com) Received: (from barney@localhost) by tp.databus.com (8.11.3/8.11.3) id f4M4HF491866 for freebsd-net@freebsd.org; Tue, 22 May 2001 00:17:15 -0400 (EDT) (envelope-from barney) Date: Tue, 22 May 2001 00:17:10 -0400 From: Barney Wolff To: freebsd-net@freebsd.org Subject: Re: Using connect() on UDP RPC client sockets. Message-ID: <20010522001710.A91710@tp.databus.com> References: <200105202256.aa30752@salmon.maths.tcd.ie> <20010520184033.A83645@tp.databus.com> <200105211850.OAA09062@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200105211850.OAA09062@khavrinen.lcs.mit.edu>; from wollman@khavrinen.lcs.mit.edu on Mon, May 21, 2001 at 02:50:13PM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Well there's SCTP ... I have a general comment/question: Is there a policy on when it is appropriate to create a FreeBSD-only feature? I can certainly see it when there is a big win to be had. A feature like this, though, if not likely to become part of Posix/Single-Unix or whatever the term is these days, is of questionable value. Can anyone realistically see bind or ntpd being modified to take advantage of it when running on FreeBSD? Use of such a feature buried in FreeBSD's own rpc code is different, I suppose. Barney Wolff On Mon, May 21, 2001 at 02:50:13PM -0400, Garrett Wollman wrote: > < said: > > > Where an RFC mandates that the reply source address must be the same > > as the request dest addr > > This is true for *any* protocol built over IP, regardless of what the > individual protocol specifications say. See RFC 1122 sections > 3.3.4.2, 4.1.3.5, and 4.2.3.7. (It actually says ``SHOULD'' in the > first two sections, which translates as ``you'd better have a damn > good reason not to''.) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon May 21 22:43:50 2001 Delivered-To: freebsd-net@freebsd.org Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by hub.freebsd.org (Postfix) with ESMTP id ABB8437B422 for ; Mon, 21 May 2001 22:43:46 -0700 (PDT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from localhost ([3ffe:501:100f:10c1:f559:12e8:25cc:80f7]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id OAA15494; Tue, 22 May 2001 14:43:12 +0900 (JST) Date: Tue, 22 May 2001 13:40:19 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: David Delibasic Cc: Subject: Re: DUMMYNET and IPv6 In-Reply-To: <20010512152550.X20493-100000@spider.suxx.eu.org> References: <20010512152550.X20493-100000@spider.suxx.eu.org> User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 18 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >>>>> On Sat, 12 May 2001 15:26:08 +0200 (CEST), >>>>> David Delibasic said: > Hellow .... > Will IPv6 start supporting DUMMYNET and when ??? Sorry for the non-informative response, but I think it would still be better than ignorance... We, the KAME project, do not have any plans to implement it at this moment (acutally we have severe lack of human resourse for supporting FreeBSD IPv6 stuff...). If someone else tries it, it would be welcome very much. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon May 21 23:52:46 2001 Delivered-To: freebsd-net@freebsd.org Received: from web5302.mail.yahoo.com (web5302.mail.yahoo.com [216.115.106.111]) by hub.freebsd.org (Postfix) with SMTP id 3CF3F37B422 for ; Mon, 21 May 2001 23:52:44 -0700 (PDT) (envelope-from vishubp@yahoo.com) Message-ID: <20010522065244.10710.qmail@web5302.mail.yahoo.com> Received: from [203.200.20.3] by web5302.mail.yahoo.com; Tue, 22 May 2001 07:52:44 BST Date: Tue, 22 May 2001 07:52:44 +0100 (BST) From: =?iso-8859-1?q?vishwanath=20pargaonkar?= Subject: interface flags To: freebsd-net@freebsd.org Cc: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, i have freebsd 4.2 stable. what is difference between interface flags IFF_UP and IFF_RUNNING? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue May 22 1:51:31 2001 Delivered-To: freebsd-net@freebsd.org Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by hub.freebsd.org (Postfix) with ESMTP id 0FA0937B422 for ; Tue, 22 May 2001 01:51:28 -0700 (PDT) (envelope-from Wei.Zhao@era.ericsson.se) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f4M8pQN01916 for ; Tue, 22 May 2001 10:51:26 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Tue May 22 10:51:25 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 22 May 2001 10:46:19 +0200 Message-ID: From: "Wei Zhao (ERA)" To: "'freebsdnet'" Subject: RFC2507 implementation Date: Tue, 22 May 2001 10:51:23 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, Does anyone know where I can find the netBSD RFC2507 implementation for PPP ? Thanks a lot! Wei Zhao Ericsson Radio Systems AB Tel: +46 8 508 78097 Fax:+46 8 50878090 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue May 22 5:17:31 2001 Delivered-To: freebsd-net@freebsd.org Received: from nwcst282.netaddress.usa.net (nwcst282.netaddress.usa.net [204.68.23.27]) by hub.freebsd.org (Postfix) with SMTP id E81D937B422 for ; Tue, 22 May 2001 05:17:27 -0700 (PDT) (envelope-from ravi_prasada@usa.net) Received: (qmail 10624 invoked by uid 60001); 22 May 2001 12:17:27 -0000 Message-ID: <20010522121727.10623.qmail@nwcst282.netaddress.usa.net> Received: from 204.68.23.27 by nwcst282 for [203.200.20.3] via web-mailer(34FM.0700.17C.01) on Tue May 22 12:17:27 GMT 2001 Date: 22 May 2001 06:17:27 MDT From: ravi prasad To: freebsd-net@FreeBSD.org Subject: rtadvd rainfo structure initialization. X-Mailer: USANET web-mailer (34FM.0700.17C.01) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, In the manual pages of the rtadvd command it is mentioned that = "If there is no configuration file entry for an interface, or if the configuration file does not exist altogether, rtadvd sets all the paramet= ers to their default values. In particular, rtadvd reads all the interface r= outes from the routing table and advertises them as on-link prefixes." I found that the getconfig() in the config.c module initializes one rain= fo structure for a perticular interface given with the command & links it to= the global rainfo structure array. The getconfig() checks for the configuration file to use. If the user has= specified a configuration file through the -c option in the rtadvd comman= d then he uses that one else he uses the default "/etc/rtadvd.conf". = My doubt is this. Assume that i have not called rtadvd with -c option nor i have a file cal= led "rtadvd.conf" in the "/etc" directory. a)How are this rainfo structure getting initialized? (I mean which = = function is doing it). b)Whether any other module other than getconfig() initializes rainfo = = structures & puts it to the list. = Kindly reply. regards ravi prasad ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=3D= 1 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue May 22 11:12:28 2001 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 3A64737B43E for ; Tue, 22 May 2001 11:12:21 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id OAA20157; Tue, 22 May 2001 14:12:18 -0400 (EDT) (envelope-from wollman) Date: Tue, 22 May 2001 14:12:18 -0400 (EDT) From: Garrett Wollman Message-Id: <200105221812.OAA20157@khavrinen.lcs.mit.edu> To: =?iso-8859-1?q?vishwanath=20pargaonkar?= Cc: freebsd-net@FreeBSD.ORG Subject: interface flags In-Reply-To: <20010522065244.10710.qmail@web5302.mail.yahoo.com> References: <20010522065244.10710.qmail@web5302.mail.yahoo.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org < said: > i have freebsd 4.2 stable. > what is difference between interface flags IFF_UP and > IFF_RUNNING? IFF_UP indicates that the interface is administratively configured up. IFF_RUNNING indicates that the hardware has been set to an operational state. For Ethernet-like interfaces, which often do not provide a direct link-ready indication to software, IFF_RUNNING is usually not meaningful. (In true historic Ethernets, there was no way for even the hardware to know whether its transceiver was connected to a network or not.) -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue May 22 11:14:10 2001 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 1DC7737B422 for ; Tue, 22 May 2001 11:14:07 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id OAA20173; Tue, 22 May 2001 14:13:59 -0400 (EDT) (envelope-from wollman) Date: Tue, 22 May 2001 14:13:59 -0400 (EDT) From: Garrett Wollman Message-Id: <200105221813.OAA20173@khavrinen.lcs.mit.edu> To: Barney Wolff Cc: freebsd-net@FreeBSD.ORG Subject: Re: Using connect() on UDP RPC client sockets. In-Reply-To: <20010522001710.A91710@tp.databus.com> References: <200105202256.aa30752@salmon.maths.tcd.ie> <20010520184033.A83645@tp.databus.com> <200105211850.OAA09062@khavrinen.lcs.mit.edu> <20010522001710.A91710@tp.databus.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org < said: > Can anyone realistically see bind or ntpd being modified to take > advantage of it when running on FreeBSD? Yes, given that it results in substantial simplification and (in the case of named) enables non-privileged operation even in the presence of dynamically-configured network interfaces. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue May 22 13: 9:50 2001 Delivered-To: freebsd-net@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-9.dsl.lsan03.pacbell.net [63.207.60.9]) by hub.freebsd.org (Postfix) with ESMTP id 259F137B42C for ; Tue, 22 May 2001 13:09:47 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id C972666BF7; Tue, 22 May 2001 13:09:46 -0700 (PDT) Date: Tue, 22 May 2001 13:09:46 -0700 From: Kris Kennaway To: "Wei Zhao (ERA)" Cc: 'freebsdnet' Subject: Re: RFC2507 implementation Message-ID: <20010522130946.H27648@xor.obsecurity.org> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="SdvjNjn6lL3tIsv0" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Wei.Zhao@era.ericsson.se on Tue, May 22, 2001 at 10:51:23AM +0200 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --SdvjNjn6lL3tIsv0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 22, 2001 at 10:51:23AM +0200, Wei Zhao (ERA) wrote: > Hi, >=20 > Does anyone know where I can find the netBSD RFC2507 implementation > for PPP ? Try asking on a NetBSD list. Kris --SdvjNjn6lL3tIsv0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.5 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7CseJWry0BWjoQKURArk2AKCKnlWi2iLoQzjKZMYTqNffGa5YzACfaxfH oHx610evit3hEkoAlgMsmC8= =L+mr -----END PGP SIGNATURE----- --SdvjNjn6lL3tIsv0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu May 24 9:17:48 2001 Delivered-To: freebsd-net@freebsd.org Received: from imo-m08.mx.aol.com (imo-m08.mx.aol.com [64.12.136.163]) by hub.freebsd.org (Postfix) with ESMTP id 8A6F537B422 for ; Thu, 24 May 2001 09:17:46 -0700 (PDT) (envelope-from raviprasad20@netscape.net) Received: from raviprasad20@netscape.net by imo-m08.mx.aol.com (mail_out_v30.22.) id n.4.1745b26 (16232) for ; Thu, 24 May 2001 12:17:39 -0400 (EDT) Received: from netscape.com (aimmail09.aim.aol.com [205.188.144.201]) by air-in02.mx.aol.com (v77_r1.37) with ESMTP; Thu, 24 May 2001 12:17:39 -0400 Date: Thu, 24 May 2001 12:17:39 -0400 From: raviprasad20@netscape.net To: freebsd-net@freebsd.org Subject: rtmsg_input Mime-Version: 1.0 Message-ID: <4BBB03E1.52C6A9EE.9513E96F@netscape.net> X-Mailer: Franklin Webmailer 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, This is regarding the rtmsg_input() in the module rtadvd.c of the rtadvd daemon. I think the above function will receive message in the routing socket when a route is added or deleted. My doubt is whether this message will be generated only for addresses other than link local & multicast or it will be generated for all the addresses. Kindly reply. regards ravi prasad __________________________________________________________________ Get your own FREE, personal Netscape Webmail account today at http://webmail.netscape.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu May 24 16:40:26 2001 Delivered-To: freebsd-net@freebsd.org Received: from rgmail.regenstrief.org (rgmail.regenstrief.org [134.68.31.197]) by hub.freebsd.org (Postfix) with ESMTP id AF81737B423 for ; Thu, 24 May 2001 16:40:21 -0700 (PDT) (envelope-from gunther@aurora.regenstrief.org) Received: from aurora.regenstrief.org (rgnout.regenstrief.org [134.68.31.38]) by rgmail.regenstrief.org (8.11.0/8.8.7) with ESMTP id f4ONh9X07900 for ; Thu, 24 May 2001 18:43:09 -0500 Message-ID: <3B0D9BE4.80CB1E35@aurora.regenstrief.org> Date: Thu, 24 May 2001 23:40:20 +0000 From: Gunther Schadow Organization: Regenstrief Institute for Health Care X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: NetWare / IPX routing facts and a question Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, (sheesh, I received 17000 messages through all the freebsd groups since April!!!! How can anyone read this?) To the point: this message contains a little give and take. GIVE: A quick report of what is possible with IPX/Netware stuff in FreeBSD. TAKE: Looking for people who use the FreeBSD IPX/Netware stuff for production and can lend a hand with some of IPX weirdnesses. Please write to me directly (in addition to copying the list, I may not find your answer otherwise.) Here goes ... GIVE: I have set up a series of small PCs (Flytech 533 MHz Celeron with 8 MB DiskOnChip, 64 MB RAM, and the SOEKRIS board with AMD i486 class PC on a chip, 133 MHz, 8 MB CompactFlash, 32 MB RAM) with FreeBSD. I started with PicoBSD but have developed my own Makefile based environment to build the images for these boxes. Very slick. My boxes are VPN tunnel endpoints, routers, NAT boxes, firewalls, traffic conditioner and shaper all in one. I do IPX routing including tunneling through the VPN. VPN is IPsec in tunnel mode (without gif as it's meant to be.) I don't do IKE (racoon) just yet, but soon. For IPX I have to deal with 802.2 Ethernet frame types, so I use the pseudo-device ef(4) to handle those frame types. IPXrouted runs of course. For the tunneling of IPX traffic I use Boris Popov's experimental if_nwip.[hc] driver. I build only static kernels without dynamic module stuff, so I hooked the if_nwip stuff into the /sys/conf/files and options lists and it works. There is a problem with the BPF hooks and I have reported a kernel bug (kern/27601) on some other strangeness, which doesn't become manifest if I have two or more different ethernet device types in my kernel (even though I use only one of them.) Once the nwip device is known to the kernel I use the nwipcfg tool (also from Boris Popov) to set up the tunnel through the IPsec tunnel. The IPX packets are simply forwarded using UDP to the other side. I also planned to do this using the tap(4) device, but why reimplementing nwip if it works? Physicians now do video conferences from home through cable internet. They see patients at a nursing home at night. This works very nicely through the FreeBSD goodies. It was absolutely crucial for us to use the great ALTQ traffic shaping stuff with class based queueing to allow good audio and control connections through the bottlenecked outgoing channel. ALTQ has done miracles for us. I can give more specifics about all of these things if you want. Ask me if you have questions or problems with any of this. I plan on publishing a bit more about it. FreeBSD is great! TAKE: Now the problem. IPX acts very strangely. Oftentimes I can connect to the main IPX network and sometimes Novell servers aren't seen. They appear in the server list (nlist, or SAP stuff) but as soon as you try connecting to them they sometimes can't be connected. We have a large campus network with thousands of Novell servers. All of them are supposed to use 802.2 and almost all of them do. Certainly the servers I'm interested in use the right frame type. The systems that talk though the FreeBSD router are DOS, Novell, and Windows machines. We run a Revelation data base over IPX and it sometimes will do fine and sometimes fail to start. I am sure there is something completely stupid going on. I assume that the FreeBSD's IPX routing works flawlessly for every connection because why should it not? Yet sometimes it seems to not work. Is there some timeout I need to change on clients or servers? The randomness of the problem points toward some random timing problems. But I am really not an IPX guru and I don't know all the little corners I should be looking at. I did change all clients to use the 802.2 frame type only and that seemed to help things a little. But there are still those episodes of not-workingness, where one can't login to a server, or even if one did login, the Revelation IPX stuff would fail and die. Also the machine's booting appears overall slower. I know this is not a Windows helpdesk, but you know how these things are, the first one who gets blamed is this self-made little "Linux-box". And I want the victory be FreeBSD's! So, whoever works with IPX and FreeBSD as IPX router, please contact me so I can pick your brain! thanks, -Gunther -- Gunther Schadow, M.D., Ph.D. gschadow@regenstrief.org Medical Information Scientist Regenstrief Institute for Health Care Adjunct Assistent Professor Indiana University School of Medicine tel:1(317)630-7960 http://aurora.regenstrief.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 25 11: 7:19 2001 Delivered-To: freebsd-net@freebsd.org Received: from zibbi.icomtek.csir.co.za (zibbi.icomtek.csir.co.za [146.64.24.58]) by hub.freebsd.org (Postfix) with ESMTP id BB68C37B422 for ; Fri, 25 May 2001 11:07:07 -0700 (PDT) (envelope-from jhay@zibbi.icomtek.csir.co.za) Received: (from jhay@localhost) by zibbi.icomtek.csir.co.za (8.11.1/8.11.1) id f4PI62P92317; Fri, 25 May 2001 20:06:02 +0200 (SAT) (envelope-from jhay) From: John Hay Message-Id: <200105251806.f4PI62P92317@zibbi.icomtek.csir.co.za> Subject: Re: NetWare / IPX routing facts and a question In-Reply-To: <3B0D9BE4.80CB1E35@aurora.regenstrief.org> from Gunther Schadow at "May 24, 2001 11:40:20 pm" To: gunther@aurora.regenstrief.org (Gunther Schadow) Date: Fri, 25 May 2001 20:06:02 +0200 (SAT) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > > TAKE: Now the problem. IPX acts very strangely. Oftentimes I > can connect to the main IPX network and sometimes Novell servers > aren't seen. They appear in the server list (nlist, or SAP stuff) > but as soon as you try connecting to them they sometimes can't be > connected. We have a large campus network with thousands of Novell > servers. All of them are supposed to use 802.2 and almost all of > them do. Certainly the servers I'm interested in use the right > frame type. The systems that talk though the FreeBSD router are > DOS, Novell, and Windows machines. We run a Revelation data base > over IPX and it sometimes will do fine and sometimes fail to start. > I am sure there is something completely stupid going on. > Here is a patch that I'm running. The problem is that on a large network the SAP table can grow very large and take a long time to be transmitted. (Only 7 SAP entries fit into a packet and you need to space them 50ms apart.) The current code will do it in one go, but during that time it will not read any received packets so the input buffers can overflow. The patch will check for received packets between each SAP broadcast and process them. The other thing that this patch does is to add the ability to filter certain SAP types. You can specify them on the commandline with the -f option. So you can do something like this: IPXrouted -s -f 0x640 -f 0x64e John -- John Hay -- John.Hay@icomtek.csir.co.za diff -u IPXrouted.org/defs.h IPXrouted/defs.h --- IPXrouted.org/defs.h Tue Aug 31 08:32:48 1999 +++ IPXrouted/defs.h Tue Aug 22 12:16:43 2000 @@ -104,4 +104,4 @@ void toall(void (*f)(struct sockaddr *, int, struct interface *, int), struct rt_entry *, int); void rip_input(struct sockaddr *, int); - +void check_packets(void); diff -u IPXrouted.org/main.c IPXrouted/main.c --- IPXrouted.org/main.c Tue Aug 31 08:32:48 1999 +++ IPXrouted/main.c Tue Aug 22 21:13:09 2000 @@ -152,8 +152,28 @@ argv++, argc--; continue; } + if (strcmp(*argv, "-f") == 0) { + if(no_sap_filters == SAPFILTERS) { + fprintf(stderr, "Too many SAP filters.\n"); + exit(1); + } + argv++, argc--; + if(argc == 0) { + fprintf(stderr, "Missing SAP service number " + "after -f\n"); + exit(1); + } + sap_filter[no_sap_filters] = strtoul(*argv, NULL, 0); + fprintf(stderr, "SAP filter %d, 0x%04X\n", + no_sap_filters + 1, sap_filter[no_sap_filters]); + sap_filter[no_sap_filters] = + htons(sap_filter[no_sap_filters]); + no_sap_filters++; + argv++, argc--; + continue; + } fprintf(stderr, - "usage: ipxrouted [ -s ] [ -q ] [ -t ] [ -g ] [ -l ] [ -N ]\n"); + "usage: ipxrouted [ -s ] [ -q ] [ -t ] [ -g ] [ -l ] [ -N -f ]\n"); exit(1); } @@ -266,6 +286,51 @@ if (ttime > (lastbcast + TIMER_RATE + (TIMER_RATE * 2 / 3))) { dobcast = 1; syslog(LOG_ERR, "Missed alarm"); + } + } +} + +void +check_packets(void) +{ + int nfds, rval; + fd_set fdvar; + struct timeval to; + + nfds = ripsock; + if(dosap && (sapsock > nfds)) + nfds = sapsock; + nfds++; + + for(;;) { + to.tv_sec = 0; + to.tv_usec = 0; + + FD_ZERO(&fdvar); + if (dosap) { + FD_SET(sapsock, &fdvar); + } + FD_SET(ripsock, &fdvar); + + rval = select(nfds, &fdvar, NULL, NULL, &to); + + if(rval == 0) + return; + + if(rval == -1) { + if(errno == EINTR) + return; + perror("during select"); + exit(1); + } + + if(FD_ISSET(ripsock, &fdvar)) + process(ripsock, RIP_PKT); + + if(dosap && FD_ISSET(sapsock, &fdvar)) { + if(ftrace) + fprintf(ftrace, "YESYES got one\n"); + process(sapsock, SAP_PKT); } } } diff -u IPXrouted.org/sap.h IPXrouted/sap.h --- IPXrouted.org/sap.h Tue Aug 31 08:32:48 1999 +++ IPXrouted/sap.h Tue Aug 22 19:44:34 2000 @@ -82,6 +82,10 @@ extern struct sap_packet *sap_msg; +#define SAPFILTERS 10 +extern int no_sap_filters; +extern u_short sap_filter[SAPFILTERS]; + void sapinit(void); void sap_input(struct sockaddr *from, int size); void sapsndmsg(struct sockaddr *dst, int flags, struct interface *ifp, diff -u IPXrouted.org/sap_input.c IPXrouted/sap_input.c --- IPXrouted.org/sap_input.c Tue Aug 31 08:32:48 1999 +++ IPXrouted/sap_input.c Tue Aug 22 20:25:06 2000 @@ -38,6 +38,9 @@ int dognreply = 1; +int no_sap_filters; +u_short sap_filter[SAPFILTERS]; + /* * Process a newly received packet. */ @@ -144,6 +147,16 @@ */ if (ntohs(n->hops) > HOPCNT_INFINITY) continue; + if(no_sap_filters) { + int x; + + for(x = 0; x < no_sap_filters; x++) + if(sap_filter[x] == n->ServType) + break; + if(x < no_sap_filters) + continue; + } + sap = sap_lookup(n->ServType, n->ServName); if (sap == 0) { if (ntohs(n->hops) == HOPCNT_INFINITY) diff -u IPXrouted.org/sap_output.c IPXrouted/sap_output.c --- IPXrouted.org/sap_output.c Tue Aug 31 08:32:48 1999 +++ IPXrouted/sap_output.c Tue Aug 22 12:16:43 2000 @@ -121,7 +121,6 @@ struct sockaddr_ipx *sipx = (struct sockaddr_ipx *) dst; af_output_t *output = afswitch[dst->sa_family].af_output; int size, metric; - int delay = 0; if (sipx->sipx_port == 0) sipx->sipx_port = htons(IPXPORT_SAP); @@ -136,11 +135,9 @@ (*output)(sapsock, flags, dst, size); TRACE_SAP_OUTPUT(ifp, dst, size); n = sap_msg->sap; - delay++; - if(delay == 2) { - usleep(50000); - delay = 0; - } + usleep(50000); + /* Check and process packets received. */ + check_packets(); } if (changesonly && !(sap->state & RTS_CHANGED)) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 25 11:41:22 2001 Delivered-To: freebsd-net@freebsd.org Received: from rgmail.regenstrief.org (rgmail.regenstrief.org [134.68.31.197]) by hub.freebsd.org (Postfix) with ESMTP id 20FEA37B423 for ; Fri, 25 May 2001 11:41:19 -0700 (PDT) (envelope-from gunther@aurora.regenstrief.org) Received: from aurora.regenstrief.org (rgnout.regenstrief.org [134.68.31.38]) by rgmail.regenstrief.org (8.11.0/8.8.7) with ESMTP id f4PIhWX16342; Fri, 25 May 2001 13:43:42 -0500 Message-ID: <3B0EA72D.FAACB699@aurora.regenstrief.org> Date: Fri, 25 May 2001 18:40:45 +0000 From: Gunther Schadow Organization: Regenstrief Institute for Health Care X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: John Hay Cc: freebsd-net@FreeBSD.ORG Subject: Re: NetWare / IPX routing facts and a question References: <200105251806.f4PI62P92317@zibbi.icomtek.csir.co.za> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org John, thank you so much for this patch to IPXrouted, I'm specifically interested in the filtering mechanism, because it's a lot of IPX junk on our network (basically an entire multi-site campus.) > Here is a patch that I'm running. The problem is that on a large network > the SAP table can grow very large and take a long time to be transmitted. > (Only 7 SAP entries fit into a packet and you need to space them 50ms > apart.) The current code will do it in one go, but during that time it > will not read any received packets so the input buffers can overflow. The > patch will check for received packets between each SAP broadcast and > process them. Hmm, how would this problem become manifest? It would seem that you would not see the servers at all on the nlist. But once you see them and you try connecting to them, they should be right there, or not? My problem is that I can see the server being listed but when I try to log in or do more with it, it says that the server isn't available; or if it is, other subsequent accesses may fail. Would be nice to know what kind of problem your patch has fixed for you. I will try it anyway, and I am hopeful that the mere filtering may help to get things straightened out. Thanks again, -Gunther -- Gunther Schadow, M.D., Ph.D. gschadow@regenstrief.org Medical Information Scientist Regenstrief Institute for Health Care Adjunct Assistent Professor Indiana University School of Medicine tel:1(317)630-7960 http://aurora.regenstrief.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 25 12:17:48 2001 Delivered-To: freebsd-net@freebsd.org Received: from zibbi.icomtek.csir.co.za (zibbi.icomtek.csir.co.za [146.64.24.58]) by hub.freebsd.org (Postfix) with ESMTP id EA1D237B422 for ; Fri, 25 May 2001 12:17:28 -0700 (PDT) (envelope-from jhay@zibbi.icomtek.csir.co.za) Received: (from jhay@localhost) by zibbi.icomtek.csir.co.za (8.11.1/8.11.1) id f4PJH7f93967; Fri, 25 May 2001 21:17:07 +0200 (SAT) (envelope-from jhay) From: John Hay Message-Id: <200105251917.f4PJH7f93967@zibbi.icomtek.csir.co.za> Subject: Re: NetWare / IPX routing facts and a question In-Reply-To: <3B0EA72D.FAACB699@aurora.regenstrief.org> from Gunther Schadow at "May 25, 2001 06:40:45 pm" To: gunther@aurora.regenstrief.org (Gunther Schadow) Date: Fri, 25 May 2001 21:17:07 +0200 (SAT) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > thank you so much for this patch to IPXrouted, I'm specifically > interested in the filtering mechanism, because it's a lot > of IPX junk on our network (basically an entire multi-site > campus.) > > > Here is a patch that I'm running. The problem is that on a large network > > the SAP table can grow very large and take a long time to be transmitted. > > (Only 7 SAP entries fit into a packet and you need to space them 50ms > > apart.) The current code will do it in one go, but during that time it > > will not read any received packets so the input buffers can overflow. The > > patch will check for received packets between each SAP broadcast and > > process them. > > Hmm, how would this problem become manifest? It would seem that > you would not see the servers at all on the nlist. But once > you see them and you try connecting to them, they should be > right there, or not? My problem is that I can see the server > being listed but when I try to log in or do more with it, it > says that the server isn't available; or if it is, other subsequent > accesses may fail. Would be nice to know what kind of > problem your patch has fixed for you. > It depends on which packets got lost in the receive buffer overrun. If it was SAP packets, you wouldn't see the machine anymore, although you would be able to get to it if you use the ipx address. If it was the RIP packets that got lost, you would see the machine, but wouldn't be able to connect to it. John -- John Hay -- John.Hay@icomtek.csir.co.za To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 25 16:59:43 2001 Delivered-To: freebsd-net@freebsd.org Received: from rgmail.regenstrief.org (rgmail.regenstrief.org [134.68.31.197]) by hub.freebsd.org (Postfix) with ESMTP id BCBF837B423 for ; Fri, 25 May 2001 16:59:40 -0700 (PDT) (envelope-from gunther@aurora.regenstrief.org) Received: from aurora.regenstrief.org ([134.68.31.99]) by rgmail.regenstrief.org (8.11.0/8.8.7) with ESMTP id f4Q02BX19809; Fri, 25 May 2001 19:02:14 -0500 Message-ID: <3B0EF1DE.84C68B2F@aurora.regenstrief.org> Date: Fri, 25 May 2001 23:59:26 +0000 From: Gunther Schadow Organization: Regenstrief Institute for Health Care X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: John Hay Cc: freebsd-net@FreeBSD.ORG Subject: Re: NetWare / IPX routing facts and a question References: <200105251917.f4PJH7f93967@zibbi.icomtek.csir.co.za> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org John Hay wrote: > > > Here is a patch that I'm running. The problem is that on a large network > > > the SAP table can grow very large and take a long time to be transmitted. > > > (Only 7 SAP entries fit into a packet and you need to space them 50ms > > > apart.) The current code will do it in one go, but during that time it > > > will not read any received packets so the input buffers can overflow. The > > > patch will check for received packets between each SAP broadcast and > > > process them. > > > > Hmm, how would this problem become manifest? It would seem that ... > It depends on which packets got lost in the receive buffer overrun. If > it was SAP packets, you wouldn't see the machine anymore, although you > would be able to get to it if you use the ipx address. If it was the > RIP packets that got lost, you would see the machine, but wouldn't be > able to connect to it. Hi John, I tried you patch but still without luck. A listing of servers will show a server, then if you right click on it to login, it takes forever and all of the Windoze client hangs until finally the pop-up menu appears. If I then click "Login to server" it immediately knows that I cannot connect. I assume that on right click it has started searching for that server and then can't find it. After a very long time has passed with frequent retrials and doing other stuff, suddenly the login may work (but then quite likely this Revelation IPX database will not work anyway.) What is wrong there? Is FreeBSD simply very slow to route IPX? A bug? This is so strange. I go ahead and try debugging with some unix level tools to see whether this is a windoze problem. The routing table is 2227 entries long. Is that too much for FreeBSD to handle? Do I have to change some buffer sizes or something? regards -Gunther -- Gunther Schadow, M.D., Ph.D. gschadow@regenstrief.org Medical Information Scientist Regenstrief Institute for Health Care Adjunct Assistent Professor Indiana University School of Medicine tel:1(317)630-7960 http://aurora.regenstrief.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 25 23:38:29 2001 Delivered-To: freebsd-net@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-119.dsl.lsan03.pacbell.net [63.207.60.119]) by hub.freebsd.org (Postfix) with ESMTP id D48E437B422 for ; Fri, 25 May 2001 23:38:13 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id AFEDE66B21; Fri, 25 May 2001 23:38:12 -0700 (PDT) Date: Fri, 25 May 2001 23:38:12 -0700 From: Kris Kennaway To: net@FreeBSD.org Subject: Randomized IP ID patch Message-ID: <20010525233811.A44455@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="n8g4imXOkfNTN/H1" Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --n8g4imXOkfNTN/H1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable A while back I posted a version of this which was activated by sysctl, but people didn't like the per-packet performance overhead, so here's an updated version which uses a compile-time option. Please review; I'd like to commit this soon. Kris Index: conf/files =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/conf/files,v retrieving revision 1.517 diff -u -r1.517 files --- conf/files 2001/05/16 07:31:56 1.517 +++ conf/files 2001/05/26 05:09:59 @@ -1010,6 +1010,7 @@ netinet/in.c optional inet netinet/in_gif.c optional gif inet #netinet/in_hostcache.c optional inet +netinet/ip_id.c optional inet netinet/in_pcb.c optional inet netinet/in_proto.c optional inet netinet/in_rmx.c optional inet Index: conf/options =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/conf/options,v retrieving revision 1.271 diff -u -r1.271 options --- conf/options 2001/05/13 20:52:36 1.271 +++ conf/options 2001/05/26 05:10:39 @@ -283,6 +283,7 @@ PPP_BSDCOMP opt_ppp.h PPP_DEFLATE opt_ppp.h PPP_FILTER opt_ppp.h +RANDOM_IP_ID SLIP_IFF_OPTS opt_slip.h TCPDEBUG TCP_DROP_SYNFIN opt_tcp_input.h Index: netinet/ip_input.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/netinet/ip_input.c,v retrieving revision 1.165 diff -u -r1.165 ip_input.c --- netinet/ip_input.c 2001/03/19 09:16:16 1.165 +++ netinet/ip_input.c 2001/05/26 06:15:51 @@ -44,6 +44,7 @@ #include "opt_ipstealth.h" #include "opt_ipsec.h" #include "opt_pfil_hooks.h" +#include "opt_random_ip_id.h" =20 #include #include @@ -249,7 +250,9 @@ =20 maxnipq =3D nmbclusters/4; =20 +#ifndef RANDOM_IP_ID ip_id =3D time_second & 0xffff; +#endif ipintrq.ifq_maxlen =3D ipqmaxlen; mtx_init(&ipintrq.ifq_mtx, "ip_inq", MTX_DEF); =20 Index: netinet/ip_mroute.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/netinet/ip_mroute.c,v retrieving revision 1.62 diff -u -r1.62 ip_mroute.c --- netinet/ip_mroute.c 2001/02/06 11:20:42 1.62 +++ netinet/ip_mroute.c 2001/05/26 06:16:07 @@ -13,6 +13,7 @@ */ =20 #include "opt_mrouting.h" +#include "opt_random_ip_id.h" =20 #include #include @@ -1581,7 +1582,11 @@ */ ip_copy =3D mtod(mb_copy, struct ip *); *ip_copy =3D multicast_encap_iphdr; +#ifdef RANDOM_IP_ID + ip_copy->ip_id =3D ip_randomid(); +#else ip_copy->ip_id =3D htons(ip_id++); +#endif ip_copy->ip_len +=3D len; ip_copy->ip_src =3D vifp->v_lcl_addr; ip_copy->ip_dst =3D vifp->v_rmt_addr; Index: netinet/ip_output.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/netinet/ip_output.c,v retrieving revision 1.124 diff -u -r1.124 ip_output.c --- netinet/ip_output.c 2001/03/13 17:07:06 1.124 +++ netinet/ip_output.c 2001/05/26 06:16:24 @@ -42,6 +42,7 @@ #include "opt_ipfilter.h" #include "opt_ipsec.h" #include "opt_pfil_hooks.h" +#include "opt_random_ip_id.h" =20 #include #include @@ -208,7 +209,11 @@ if ((flags & (IP_FORWARDING|IP_RAWOUTPUT)) =3D=3D 0) { ip->ip_vhl =3D IP_MAKE_VHL(IPVERSION, hlen >> 2); ip->ip_off &=3D IP_DF; +#ifdef RANDOM_IP_ID + ip->ip_id =3D ip_randomid(); +#else ip->ip_id =3D htons(ip_id++); +#endif ipstat.ips_localout++; } else { hlen =3D IP_VHL_HL(ip->ip_vhl) << 2; Index: netinet/ip_var.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/netinet/ip_var.h,v retrieving revision 1.54 diff -u -r1.54 ip_var.h --- netinet/ip_var.h 2001/03/19 09:16:16 1.54 +++ netinet/ip_var.h 2001/05/26 03:15:06 @@ -138,7 +138,9 @@ struct sockopt; =20 extern struct ipstat ipstat; +#ifndef RANDOM_IP_ID extern u_short ip_id; /* ip packet ctr, for ids */ +#endif extern int ip_defttl; /* default IP ttl */ extern int ipforwarding; /* ip forwarding */ extern struct route ipforward_rt; /* ip forwarding cached route */ @@ -164,6 +166,10 @@ struct mbuf * ip_srcroute __P((void)); void ip_stripoptions __P((struct mbuf *, struct mbuf *)); +#ifdef RANDOM_IP_ID +u_int16_t=09 + ip_randomid __P((void)); +#endif int rip_ctloutput __P((struct socket *, struct sockopt *)); void rip_ctlinput __P((int, struct sockaddr *, void *)); void rip_init __P((void)); Index: netinet/raw_ip.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/netinet/raw_ip.c,v retrieving revision 1.76 diff -u -r1.76 raw_ip.c --- netinet/raw_ip.c 2001/05/11 14:37:34 1.76 +++ netinet/raw_ip.c 2001/05/26 06:16:51 @@ -36,6 +36,7 @@ =20 #include "opt_inet6.h" #include "opt_ipsec.h" +#include "opt_random_ip_id.h" =20 #include #include @@ -220,7 +221,11 @@ return EINVAL; } if (ip->ip_id =3D=3D 0) +#ifdef RANDOM_IP_ID + ip->ip_id =3D ip_randomid(); +#else ip->ip_id =3D htons(ip_id++); +#endif /* XXX prevent ip_output from overwriting header fields */ flags |=3D IP_RAWOUTPUT; ipstat.ips_rawout++; Index: netinet6/ipsec.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/netinet6/ipsec.c,v retrieving revision 1.10 diff -u -r1.10 ipsec.c --- netinet6/ipsec.c 2001/03/16 17:52:48 1.10 +++ netinet6/ipsec.c 2001/05/26 03:12:20 @@ -2045,7 +2045,11 @@ ipseclog((LOG_ERR, "IPv4 ipsec: size exceeds limit: " "leave ip_len as is (invalid packet)\n")); } +#ifdef RANDOM_IP_ID + ip->ip_id =3D ip_randomid(); +#else ip->ip_id =3D htons(ip_id++); +#endif bcopy(&((struct sockaddr_in *)&sav->sah->saidx.src)->sin_addr, &ip->ip_src, sizeof(ip->ip_src)); bcopy(&((struct sockaddr_in *)&sav->sah->saidx.dst)->sin_addr, Index: i386/conf/NOTES =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /mnt/ncvs/src/sys/i386/conf/NOTES,v retrieving revision 1.914 diff -u -r1.914 NOTES --- i386/conf/NOTES 2001/05/13 20:52:39 1.914 +++ i386/conf/NOTES 2001/05/26 06:34:01 @@ -590,6 +590,12 @@ options IPSTEALTH #support for stealth forwarding options TCPDEBUG =20 +# RANDOM_IP_ID causes the ID field in IP packets to be randomized +# instead of incremented by 1. This option prevents remote observers +# from determining the traffic load on the machine by watching the +# counter. +options RANDOM_IP_ID + # Statically Link in accept filters options ACCEPT_FILTER_DATA options ACCEPT_FILTER_HTTP --- /dev/null Fri May 25 23:33:00 2001 +++ netinet/ip_id.c Fri May 25 23:26:26 2001 @@ -0,0 +1,214 @@ +/* $OpenBSD: ip_id.c,v 1.2 1999/08/26 13:37:01 provos Exp $ */ + +/* + * Copyright 1998 Niels Provos + * All rights reserved. + * + * Theo de Raadt came up with the idea of using + * such a mathematical system to generate more random (yet non-repeating) + * ids to solve the resolver/named problem. But Niels designed the + * actual system based on the constraints. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. All advertising materials mentioning features or use of this software + * must display the following acknowledgement: + * This product includes software developed by Niels Provos. + * 4. The name of the author may not be used to endorse or promote products + * derived from this software without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTI= ES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. + * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF US= E, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + * + * $FreeBSD$ + */ + +/*=20 + * seed =3D random 15bit + * n =3D prime, g0 =3D generator to n, + * j =3D random so that gcd(j,n-1) =3D=3D 1 + * g =3D g0^j mod n will be a generator again. + * + * X[0] =3D random seed. + * X[n] =3D a*X[n-1]+b mod m is a Linear Congruential Generator + * with a =3D 7^(even random) mod m,=20 + * b =3D random with gcd(b,m) =3D=3D 1 + * m =3D 31104 and a maximal period of m-1. + * + * The transaction id is determined by: + * id[n] =3D seed xor (g^X[n] mod n) + * + * Effectivly the id is restricted to the lower 15 bits, thus + * yielding two different cycles by toggling the msb on and off. + * This avoids reuse issues caused by reseeding. + */ + +#include "opt_random_ip_id.h" +#include +#include +#include +#include + +#ifdef RANDOM_IP_ID +#define RU_OUT 180 /* Time after wich will be reseeded */ +#define RU_MAX 30000 /* Uniq cycle, avoid blackjack prediction */ +#define RU_GEN 2 /* Starting generator */ +#define RU_N 32749 /* RU_N-1 =3D 2*2*3*2729 */ +#define RU_AGEN 7 /* determine ru_a as RU_AGEN^(2*rand) */ +#define RU_M 31104 /* RU_M =3D 2^7*3^5 - don't change */ + +#define PFAC_N 3 +const static u_int16_t pfacts[PFAC_N] =3D { + 2,=20 + 3, + 2729 +}; + +static u_int16_t ru_x; +static u_int16_t ru_seed, ru_seed2; +static u_int16_t ru_a, ru_b; +static u_int16_t ru_g; +static u_int16_t ru_counter =3D 0; +static u_int16_t ru_msb =3D 0; +static long ru_reseed; +static u_int32_t tmp; /* Storage for unused random */ +static int randomize =3D 0; + +static u_int16_t pmod __P((u_int16_t, u_int16_t, u_int16_t)); +static void ip_initid __P((void)); +u_int16_t ip_randomid __P((void)); + +/* + * Do a fast modular exponation, returned value will be in the range + * of 0 - (mod-1) + */ + +#ifdef __STDC__ +static u_int16_t +pmod(u_int16_t gen, u_int16_t exp, u_int16_t mod) +#else +static u_int16_t +pmod(gen, exp, mod) + u_int16_t gen, exp, mod; +#endif +{ + u_int16_t s, t, u; + + s =3D 1; + t =3D gen; + u =3D exp; + + while (u) { + if (u & 1) + s =3D (s*t) % mod; + u >>=3D 1; + t =3D (t*t) % mod; + } + return (s); +} + +/*=20 + * Initalizes the seed and chooses a suitable generator. Also toggles=20 + * the msb flag. The msb flag is used to generate two distinct + * cycles of random numbers and thus avoiding reuse of ids. + * + * This function is called from id_randomid() when needed, an=20 + * application does not have to worry about it. + */ +static void=20 +ip_initid(void) +{ + u_int16_t j, i; + int noprime =3D 1; + struct timeval time; + + getmicrotime(&time); + read_random((void *) &tmp, sizeof(tmp)); + ru_x =3D (tmp & 0xFFFF) % RU_M; + + /* 15 bits of random seed */ + ru_seed =3D (tmp >> 16) & 0x7FFF; + read_random((void *) &tmp, sizeof(tmp)); + ru_seed2 =3D tmp & 0x7FFF; + + read_random((void *) &tmp, sizeof(tmp)); + + /* Determine the LCG we use */ + ru_b =3D (tmp & 0xfffe) | 1; + ru_a =3D pmod(RU_AGEN, (tmp >> 16) & 0xfffe, RU_M); + while (ru_b % 3 =3D=3D 0) + ru_b +=3D 2; +=09 + read_random((void *) &tmp, sizeof(tmp)); + j =3D tmp % RU_N; + tmp =3D tmp >> 16; + + /*=20 + * Do a fast gcd(j,RU_N-1), so we can find a j with + * gcd(j, RU_N-1) =3D=3D 1, giving a new generator for + * RU_GEN^j mod RU_N + */ + + while (noprime) { + for (i=3D0; i=3DPFAC_N) + noprime =3D 0; + else=20 + j =3D (j+1) % RU_N; + } + + ru_g =3D pmod(RU_GEN,j,RU_N); + ru_counter =3D 0; + + ru_reseed =3D time.tv_sec + RU_OUT; + ru_msb =3D ru_msb =3D=3D 0x8000 ? 0 : 0x8000;=20 +} + +u_int16_t +ip_randomid(void) +{ + int i, n; + static u_short ip_id =3D 0; /* ip packet ctr, for ids */ + static int ip_id_init =3D 0; + struct timeval time; + + getmicrotime(&time); + if (ru_counter >=3D RU_MAX || time.tv_sec > ru_reseed) + ip_initid(); + + if (!tmp) + read_random((void *) &tmp, sizeof(tmp)); + + /* Skip a random number of ids */ + n =3D tmp & 0x3; tmp =3D tmp >> 2; + if (ru_counter + n >=3D RU_MAX) + ip_initid(); + + for (i =3D 0; i <=3D n; i++) + /* Linear Congruential Generator */ + ru_x =3D (ru_a*ru_x + ru_b) % RU_M; + + ru_counter +=3D i; + + return (ru_seed ^ pmod(ru_g,ru_seed2 ^ ru_x,RU_N)) | ru_msb; + } +} + +#endif /* RANDOM_IP_ID */ --n8g4imXOkfNTN/H1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.5 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7D09TWry0BWjoQKURArqeAKD6MVsG4BfaC9perXRxzUqj1QEzKQCgpwBI rYJYEEzyJuJuqNgdjHFlJXk= =Ug87 -----END PGP SIGNATURE----- --n8g4imXOkfNTN/H1-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 25 23:46:51 2001 Delivered-To: freebsd-net@freebsd.org Received: from superconductor.rush.net (superconductor.rush.net [208.9.155.8]) by hub.freebsd.org (Postfix) with ESMTP id 5A2C837B423 for ; Fri, 25 May 2001 23:46:49 -0700 (PDT) (envelope-from bright@superconductor.rush.net) Received: (from bright@localhost) by superconductor.rush.net (8.11.2/8.11.2) id f4Q6kkA29195; Sat, 26 May 2001 02:46:46 -0400 (EDT) Date: Sat, 26 May 2001 02:46:44 -0400 From: Alfred Perlstein To: Kris Kennaway Cc: net@FreeBSD.ORG Subject: Re: Randomized IP ID patch Message-ID: <20010526024644.I17514@superconductor.rush.net> References: <20010525233811.A44455@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <20010525233811.A44455@xor.obsecurity.org>; from kris@obsecurity.org on Fri, May 25, 2001 at 11:38:12PM -0700 X-all-your-base: are belong to us. Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * Kris Kennaway [010526 02:38] wrote: > A while back I posted a version of this which was activated by sysctl, > but people didn't like the per-packet performance overhead, so here's > an updated version which uses a compile-time option. Please review; > I'd like to commit this soon. > This seems pretty cool, I'm suprised you had people objecting to a single check of whether or not to run an external function. (I'd rather see this configurable while the system is running). -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 25 23:50:16 2001 Delivered-To: freebsd-net@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-119.dsl.lsan03.pacbell.net [63.207.60.119]) by hub.freebsd.org (Postfix) with ESMTP id 4645237B422 for ; Fri, 25 May 2001 23:50:13 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id C815766B21; Fri, 25 May 2001 23:50:11 -0700 (PDT) Date: Fri, 25 May 2001 23:50:11 -0700 From: Kris Kennaway To: Alfred Perlstein Cc: Kris Kennaway , net@FreeBSD.ORG Subject: Re: Randomized IP ID patch Message-ID: <20010525235011.A44657@xor.obsecurity.org> References: <20010525233811.A44455@xor.obsecurity.org> <20010526024644.I17514@superconductor.rush.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="KsGdsel6WgEHnImy" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010526024644.I17514@superconductor.rush.net>; from bright@rush.net on Sat, May 26, 2001 at 02:46:44AM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --KsGdsel6WgEHnImy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, May 26, 2001 at 02:46:44AM -0400, Alfred Perlstein wrote: > * Kris Kennaway [010526 02:38] wrote: > > A while back I posted a version of this which was activated by sysctl, > > but people didn't like the per-packet performance overhead, so here's > > an updated version which uses a compile-time option. Please review; > > I'd like to commit this soon. > > >=20 > This seems pretty cool, I'm suprised you had people objecting to > a single check of whether or not to run an external function. > (I'd rather see this configurable while the system is running). Well, I could have done it by switching functions, but people also objected to the kernel bloat. To be fair, this is a pretty minor information leak, so many people will not care about it. Kris --KsGdsel6WgEHnImy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.5 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7D1IiWry0BWjoQKURAmt8AJ4kTf/Q5SWwaoWammCeS8hTVRPVEgCg440o cNn15qyyC1cIyV5iW08PV48= =LVbd -----END PGP SIGNATURE----- --KsGdsel6WgEHnImy-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 26 0:16: 6 2001 Delivered-To: freebsd-net@freebsd.org Received: from bazooka.unixfreak.org (bazooka.unixfreak.org [63.198.170.138]) by hub.freebsd.org (Postfix) with ESMTP id ECB2737B422 for ; Sat, 26 May 2001 00:16:02 -0700 (PDT) (envelope-from dima@unixfreak.org) Received: from spike.unixfreak.org (spike [63.198.170.139]) by bazooka.unixfreak.org (Postfix) with ESMTP id 9916C3E28; Sat, 26 May 2001 00:16:02 -0700 (PDT) To: Kris Kennaway Cc: Alfred Perlstein , net@FreeBSD.ORG Subject: Re: Randomized IP ID patch In-Reply-To: <20010525235011.A44657@xor.obsecurity.org>; from kris@obsecurity.org on "Fri, 25 May 2001 23:50:11 -0700" Date: Sat, 26 May 2001 00:16:02 -0700 From: Dima Dorfman Message-Id: <20010526071602.9916C3E28@bazooka.unixfreak.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Kris Kennaway writes: > On Sat, May 26, 2001 at 02:46:44AM -0400, Alfred Perlstein wrote: > > * Kris Kennaway [010526 02:38] wrote: > > > A while back I posted a version of this which was activated by sysctl, > > > but people didn't like the per-packet performance overhead, so here's > > > an updated version which uses a compile-time option. Please review; > > > I'd like to commit this soon. > > > > > > > This seems pretty cool, I'm suprised you had people objecting to > > a single check of whether or not to run an external function. > > (I'd rather see this configurable while the system is running). > > Well, I could have done it by switching functions, but people also > objected to the kernel bloat. To be fair, this is a pretty minor > information leak, so many people will not care about it. If it makes sense to be able to switch it on and off at run-time (e.g., it may make sense to, say, use it to compare resposne from something), you can make the sysctl conditional on the compile-time option. If Alfred just wanted to be able to switch it on without recompiling a kernel (e.g., while running GENERIC), this obviously doesn't help. Just food for thought, I guess. I like it either way :-). Thanks! Dima Dorfman dima@unixfreak.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 26 0:38:25 2001 Delivered-To: freebsd-net@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-83.dsl.lsan03.pacbell.net [63.207.60.83]) by hub.freebsd.org (Postfix) with ESMTP id 43C1737B422 for ; Sat, 26 May 2001 00:38:23 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 5EA8566B21; Sat, 26 May 2001 00:38:16 -0700 (PDT) Date: Sat, 26 May 2001 00:38:15 -0700 From: Kris Kennaway To: Kris Kennaway Cc: net@FreeBSD.ORG Subject: Re: Randomized IP ID patch Message-ID: <20010526003815.A17669@xor.obsecurity.org> References: <20010525233811.A44455@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="pf9I7BMVVzbSWLtt" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010525233811.A44455@xor.obsecurity.org>; from kris@obsecurity.org on Fri, May 25, 2001 at 11:38:12PM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Actually, this patch was broken; the updated one is at: http://www.freebsd.org/~kris/randomized-ipid.diff Kris --pf9I7BMVVzbSWLtt Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.5 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7D11mWry0BWjoQKURAugEAJ9GEW1bTAsowL9qifeGJLLoM3Ea1ACcC4jd yZkC8gTpgy4XEPgYbJHou88= =gXBs -----END PGP SIGNATURE----- --pf9I7BMVVzbSWLtt-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 26 0:40: 4 2001 Delivered-To: freebsd-net@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-83.dsl.lsan03.pacbell.net [63.207.60.83]) by hub.freebsd.org (Postfix) with ESMTP id AE59E37B423 for ; Sat, 26 May 2001 00:39:59 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id EF82966B21; Sat, 26 May 2001 00:39:58 -0700 (PDT) Date: Sat, 26 May 2001 00:39:58 -0700 From: Kris Kennaway To: Dima Dorfman Cc: Kris Kennaway , Alfred Perlstein , net@FreeBSD.ORG Subject: Re: Randomized IP ID patch Message-ID: <20010526003958.A84221@xor.obsecurity.org> References: <20010525235011.A44657@xor.obsecurity.org> <20010526071602.9916C3E28@bazooka.unixfreak.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="ZPt4rx8FFjLCG7dd" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010526071602.9916C3E28@bazooka.unixfreak.org>; from dima@unixfreak.org on Sat, May 26, 2001 at 12:16:02AM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --ZPt4rx8FFjLCG7dd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, May 26, 2001 at 12:16:02AM -0700, Dima Dorfman wrote: > If it makes sense to be able to switch it on and off at run-time > (e.g., it may make sense to, say, use it to compare resposne from > something), you can make the sysctl conditional on the compile-time > option. If Alfred just wanted to be able to switch it on without > recompiling a kernel (e.g., while running GENERIC), this obviously > doesn't help. I thought about doing this, but I really couldn't think why someone would want to do that. Kris --ZPt4rx8FFjLCG7dd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.5 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7D13OWry0BWjoQKURAlBaAKDXfYuSxyMJgj+KiKoNRWedpbRtfQCfXYYb tcVVDDFytGQhynHUKwOwBZo= =A9XD -----END PGP SIGNATURE----- --ZPt4rx8FFjLCG7dd-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 26 8:11:14 2001 Delivered-To: freebsd-net@freebsd.org Received: from zibbi.icomtek.csir.co.za (zibbi.icomtek.csir.co.za [146.64.24.58]) by hub.freebsd.org (Postfix) with ESMTP id BAA4537B422 for ; Sat, 26 May 2001 08:11:08 -0700 (PDT) (envelope-from jhay@zibbi.icomtek.csir.co.za) Received: (from jhay@localhost) by zibbi.icomtek.csir.co.za (8.11.1/8.11.1) id f4QFAaY34455; Sat, 26 May 2001 17:10:36 +0200 (SAT) (envelope-from jhay) From: John Hay Message-Id: <200105261510.f4QFAaY34455@zibbi.icomtek.csir.co.za> Subject: Re: NetWare / IPX routing facts and a question In-Reply-To: <3B0EF1DE.84C68B2F@aurora.regenstrief.org> from Gunther Schadow at "May 25, 2001 11:59:26 pm" To: gunther@aurora.regenstrief.org (Gunther Schadow) Date: Sat, 26 May 2001 17:10:36 +0200 (SAT) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > I tried you patch but still without luck. A listing of servers will > show a server, then if you right click on it to login, it takes > forever and all of the Windoze client hangs until finally the pop-up > menu appears. If I then click "Login to server" it immediately knows > that I cannot connect. I assume that on right click it has started > searching for that server and then can't find it. After a very long > time has passed with frequent retrials and doing other stuff, suddenly > the login may work (but then quite likely this Revelation IPX database > will not work anyway.) > > What is wrong there? Is FreeBSD simply very slow to route IPX? A bug? > This is so strange. I go ahead and try debugging with some unix level > tools to see whether this is a windoze problem. The routing table is > 2227 entries long. Is that too much for FreeBSD to handle? Do I have > to change some buffer sizes or something? No FreeBSD is not slow to route IPX. IPX routing is done in the kernel, just like the ip routing. It even use the same code to manage the routing tables. What you can do is to send a -INFO signal to IPXrouted when you have the problem. It will then write the RIP and SAP table out to /var/log/ipxrouted.dmp. You can then see if the entries are there. My guess is that if you can see the server in the list, but cannot connect to it, then you will find that there will be a SAP entry for the server, but no routing entry for it. Why I don't know. :-) If you have lots of disk space, you can let IPXrouted log to a file and maybe see from that what is going wrong. John -- John Hay -- John.Hay@icomtek.csir.co.za To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 26 11:51:56 2001 Delivered-To: freebsd-net@freebsd.org Received: from thor.oit.pdx.edu (thor.oit.pdx.edu [131.252.120.40]) by hub.freebsd.org (Postfix) with ESMTP id AB6BF37B422; Sat, 26 May 2001 11:51:52 -0700 (PDT) (envelope-from singh@pdx.edu) Received: from freke.odin.pdx.edu (freke.odin.pdx.edu [131.252.120.43]) by thor.oit.pdx.edu (8.11.1/8.11.1) with ESMTP id f4QIppc19267; Sat, 26 May 2001 11:51:52 -0700 (PDT) Received: from localhost (singh@localhost) by freke.odin.pdx.edu (8.11.1/8.11.1) with ESMTP id f4QIppT18291; Sat, 26 May 2001 11:51:51 -0700 (PDT) X-Authentication-Warning: freke.odin.pdx.edu: singh owned process doing -bs Date: Sat, 26 May 2001 11:51:51 -0700 (PDT) From: Harkirat Singh X-X-Sender: To: Cc: Subject: UDP - Reliable throughput mesaurement tool In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello! I want to measure UDP thruput of lossy channel, is there any tool which tests it? I looked at some of the tools but these do not take care of loss, I mean no retransmisson, just measure raw thruput of UDP (TTCP is one of these). I am looking for a measurement tool which should retransmit in case of loss and keep a track of packets, I mean make UDP reliable amd blocking calls. Thanks, Harkirat To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 26 12: 0:38 2001 Delivered-To: freebsd-net@freebsd.org Received: from clmboh1-smtp3.columbus.rr.com (clmboh1-smtp3.columbus.rr.com [65.24.0.112]) by hub.freebsd.org (Postfix) with ESMTP id 8ACF937B424; Sat, 26 May 2001 12:00:34 -0700 (PDT) (envelope-from wmoran@iowna.com) Received: from iowna.com (dhcp065-024-023-038.columbus.rr.com [65.24.23.38]) by clmboh1-smtp3.columbus.rr.com (8.11.2/8.11.2) with ESMTP id f4QIvNk22596; Sat, 26 May 2001 14:57:23 -0400 (EDT) Message-ID: <3B0FFD03.5968879E@iowna.com> Date: Sat, 26 May 2001 14:59:15 -0400 From: Bill Moran X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.3-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Harkirat Singh Cc: freebsd-net@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: UDP - Reliable throughput mesaurement tool References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Harkirat Singh wrote: > > Hello! > > I want to measure UDP thruput of lossy channel, is there any tool > which tests it? I looked at some of the tools but these do not take care > of loss, I mean no retransmisson, just measure raw thruput of UDP (TTCP > is one of these). > > I am looking for a measurement tool which should retransmit in case of > loss and keep a track of packets, I mean make UDP reliable amd blocking > calls. I may be missing something here ... but if you're looking for reliable UDP, why not use TCP? -Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 26 12: 8:36 2001 Delivered-To: freebsd-net@freebsd.org Received: from mark9.vladsempire.net (hutch-720.hutchtel.net [206.10.71.20]) by hub.freebsd.org (Postfix) with ESMTP id 8DE0037B422; Sat, 26 May 2001 12:08:17 -0700 (PDT) (envelope-from jpaetzel@hutchtel.net) Received: from mark9.vladsempire.net (mark9.vladsempire.net [10.0.0.97]) by mark9.vladsempire.net (Postfix) with SMTP id 388F22AC; Sat, 26 May 2001 14:13:37 -0500 (CDT) Content-Type: text/plain; charset="iso-8859-1" From: Josh Paetzel To: Harkirat Singh , Subject: Re: UDP - Reliable throughput mesaurement tool Date: Sat, 26 May 2001 14:13:37 -0500 X-Mailer: KMail [version 1.2] Cc: References: In-Reply-To: MIME-Version: 1.0 Message-Id: <01052614133701.54532@mark9.vladsempire.net> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Saturday 26 May 2001 13:51, Harkirat Singh wrote: > Hello! > > I want to measure UDP thruput of lossy channel, is there any tool > which tests it? I looked at some of the tools but these do not take care > of loss, I mean no retransmisson, just measure raw thruput of UDP (TTCP > is one of these). > > I am looking for a measurement tool which should retransmit in case of > loss and keep a track of packets, I mean make UDP reliable amd blocking > calls. > > Thanks, > > Harkirat > > Uhhmmm, seeing as UDP is specifically designed as being "lossy" I don't think there is going to be anything that can help you out there. There is a really good protocol that you can use if you need "reliable" delivery of packets over IP. If I remember right, it is called TCP. Josh > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-questions" 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 Sat May 26 12:24:52 2001 Delivered-To: freebsd-net@freebsd.org Received: from thor.oit.pdx.edu (thor.oit.pdx.edu [131.252.120.40]) by hub.freebsd.org (Postfix) with ESMTP id A774537B422; Sat, 26 May 2001 12:24:46 -0700 (PDT) (envelope-from singh@pdx.edu) Received: from freke.odin.pdx.edu (freke.odin.pdx.edu [131.252.120.43]) by thor.oit.pdx.edu (8.11.1/8.11.1) with ESMTP id f4QJOkc23168; Sat, 26 May 2001 12:24:46 -0700 (PDT) Received: from localhost (singh@localhost) by freke.odin.pdx.edu (8.11.1/8.11.1) with ESMTP id f4QJOjc18983; Sat, 26 May 2001 12:24:45 -0700 (PDT) X-Authentication-Warning: freke.odin.pdx.edu: singh owned process doing -bs Date: Sat, 26 May 2001 12:24:45 -0700 (PDT) From: Harkirat Singh X-X-Sender: To: Josh Paetzel Cc: , Subject: Re: UDP - Reliable throughput mesaurement In-Reply-To: <01052614133701.54532@mark9.vladsempire.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I specifically want to see the performance of UDP in lossy channel, I am sure there must be some tool to measure it, I doing a kind of study and want to analyse TCP vs. UDP! -Harkirat On Sat, 26 May 2001, Josh Paetzel wrote: > On Saturday 26 May 2001 13:51, Harkirat Singh wrote: > > Hello! > > > > I want to measure UDP thruput of lossy channel, is there any tool > > which tests it? I looked at some of the tools but these do not take care > > of loss, I mean no retransmisson, just measure raw thruput of UDP (TTCP > > is one of these). > > > > I am looking for a measurement tool which should retransmit in case of > > loss and keep a track of packets, I mean make UDP reliable amd blocking > > calls. > > > > Thanks, > > > > Harkirat > > > > > > > Uhhmmm, seeing as UDP is specifically designed as being "lossy" I don't think > there is going to be anything that can help you out there. There is a really > good protocol that you can use if you need "reliable" delivery of packets > over IP. If I remember right, it is called TCP. > > Josh > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-questions" 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 Sat May 26 12:27:10 2001 Delivered-To: freebsd-net@freebsd.org Received: from thor.oit.pdx.edu (thor.oit.pdx.edu [131.252.120.40]) by hub.freebsd.org (Postfix) with ESMTP id 4613C37B422; Sat, 26 May 2001 12:27:06 -0700 (PDT) (envelope-from singh@pdx.edu) Received: from freke.odin.pdx.edu (freke.odin.pdx.edu [131.252.120.43]) by thor.oit.pdx.edu (8.11.1/8.11.1) with ESMTP id f4QJR5c23407; Sat, 26 May 2001 12:27:05 -0700 (PDT) Received: from localhost (singh@localhost) by freke.odin.pdx.edu (8.11.1/8.11.1) with ESMTP id f4QJR5w19030; Sat, 26 May 2001 12:27:05 -0700 (PDT) X-Authentication-Warning: freke.odin.pdx.edu: singh owned process doing -bs Date: Sat, 26 May 2001 12:27:05 -0700 (PDT) From: Harkirat Singh X-X-Sender: To: Bill Moran Cc: , Subject: Re: UDP - Reliable throughput mesaurement tool In-Reply-To: <3B0FFD03.5968879E@iowna.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I am looking at performance of UDT and TCP in same network condition!! -Harkirat On Sat, 26 May 2001, Bill Moran wrote: > Harkirat Singh wrote: > > > > Hello! > > > > I want to measure UDP thruput of lossy channel, is there any tool > > which tests it? I looked at some of the tools but these do not take care > > of loss, I mean no retransmisson, just measure raw thruput of UDP (TTCP > > is one of these). > > > > I am looking for a measurement tool which should retransmit in case of > > loss and keep a track of packets, I mean make UDP reliable amd blocking > > calls. > > I may be missing something here ... but if you're looking for reliable > UDP, why not use TCP? > > -Bill > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-questions" 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 Sat May 26 12:33: 4 2001 Delivered-To: freebsd-net@freebsd.org Received: from freesbee.wheel.dk (freesbee.wheel.dk [193.162.159.97]) by hub.freebsd.org (Postfix) with ESMTP id 548EB37B422 for ; Sat, 26 May 2001 12:33:00 -0700 (PDT) (envelope-from jesper@skriver.dk) Received: by freesbee.wheel.dk (Postfix, from userid 1001) id 580265D3B; Sat, 26 May 2001 21:34:42 +0200 (CEST) Date: Sat, 26 May 2001 21:34:42 +0200 From: Jesper Skriver To: freebsd-net@FreeBSD.org Subject: control TCP send/recieve window size based on port numbers ? and a bug(?) in sendpipe/recvpipe handling ... Message-ID: <20010526213442.A95985@skriver.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-PGP-Fingerprint: 6B88 9CE8 66E9 E631 C9C5 5EB4 22AB F0EC F956 1C31 X-PGP-Public-Key: http://freesbee.wheel.dk/~jesper/gpgkey.pub Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I'm currently looking at ways to tune a ftp server, and when tuning net.inet.tcp.sendspace/net.inet.tcp.recvspace and NMBCLUSTERS, I came to think that in a ftp server role, half the TCP sessions will be control sessions, which doesn't transfer much data, so there is no reason to reserve the same number of buffers for sendspace/recvspace for these, compared to the data sessions. I was thinking of adding 3 new sysctl's net.inet.tcp.override_sendspace net.inet.tcp.override_recvspace net.inet.tcp.override_ports The latter controls which (if any) src/dst ports, trigger the session to get the overridden send and recv-space applied. Does this make any sense ? For my own testing I'm using which do this with one exception, it only allow's one port to be listed as override, I was to lazy to go into a comma separeted list for my initial testing. And I need to add these 3 sysctl's to tcp(4). My testing show that it doesn't seem to have any effect, but that actually show a different problem, as the sendpipe/recvpipe doesn't seem to have any effect either. On a box running stock -current as of may 16th root@tam% route change default -sendpipe 1024 change net default root@tam% route change default -recvpipe 1024 change net default root@tam% route get default route to: default destination: default mask: default gateway: dhcp129.skriver.dk interface: xl0 flags: recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire 1024 1024 0 0 0 0 1500 0 And then I get a file from the http server on this host, but netstat -a give me root@tam% netstat -a|head -3 Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp4 0 17520 dhcp138.skriver..http freesbee.wheel.d.1162 ESTABLISHED So the send queue is the default 16k, regardless of the fact that I've overridden the default via the route Ok, perhaps I have to change it at the cloned route. root@tam% route get 193.162.159.97 route to: freesbee.wheel.dk destination: freesbee.wheel.dk gateway: dhcp129.skriver.dk interface: xl0 flags: recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire 0 0 139462230 79 7 0 1500 3421 root@tam% route change 193.162.159.97 -sendpipe 1024 -recvpipe 1024 change host 193.162.159.97 root@tam% route get 193.162.159.97 route to: freesbee.wheel.dk destination: freesbee.wheel.dk gateway: dhcp129.skriver.dk interface: xl0 flags: recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire 1024 1024 139462230 79 7 0 1500 3390 But still I get jesper@tam% netstat -a | head -3 Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp4 0 16384 dhcp138.skriver..http freesbee.wheel.d.1177 ESTABLISHED Any ideas ? /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work: Network manager @ AS3292 (Tele Danmark DataNetworks) Private: FreeBSD committer @ AS2109 (A much smaller network ;-) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 26 12:38:42 2001 Delivered-To: freebsd-net@freebsd.org Received: from femail4.sdc1.sfba.home.com (femail4.sdc1.sfba.home.com [24.0.95.84]) by hub.freebsd.org (Postfix) with ESMTP id A3D4537B423; Sat, 26 May 2001 12:38:30 -0700 (PDT) (envelope-from justin@mac.com) Received: from grinch ([65.11.111.111]) by femail4.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010526193825.VXQR16646.femail4.sdc1.sfba.home.com@grinch>; Sat, 26 May 2001 12:38:25 -0700 Date: Sat, 26 May 2001 12:38:20 -0700 Content-Type: text/plain; format=flowed; charset=us-ascii X-Mailer: Apple Mail (2.388) From: Justin C.Walker To: , Mime-Version: 1.0 (Apple Message framework v388) In-Reply-To: Subject: Re: UDP - Reliable throughput mesaurement Content-Transfer-Encoding: 7bit Message-Id: <20010526193825.VXQR16646.femail4.sdc1.sfba.home.com@grinch> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Saturday, May 26, 2001, at 12:24 PM, Harkirat Singh wrote: > > I specifically want to see the performance of UDP in lossy > channel, I am > sure there must be some tool to measure it, I doing a kind of study and > want to analyse TCP vs. UDP! If you want to measure the performance of these two protocols, use 'netperf'. It provides several options for looking at performance. Your original message indicated you wanted a tool that provides a reliable layer on UDP, which, obviously, is not the same thing. Which do you want? UDP or a reliable datagram protocol? Regards, Justin --- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Director of Technology | It's not whether you win or lose... Nexsi Systems Corp. | It's whether *I* win or lose. 1959 Concourse Drive | San Jose, CA 95131 | *--------------------------------------*-------------------------------* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 26 12:38:50 2001 Delivered-To: freebsd-net@freebsd.org Received: from freesbee.wheel.dk (freesbee.wheel.dk [193.162.159.97]) by hub.freebsd.org (Postfix) with ESMTP id 5F3E337B424; Sat, 26 May 2001 12:38:32 -0700 (PDT) (envelope-from jesper@skriver.dk) Received: by freesbee.wheel.dk (Postfix, from userid 1001) id 541185D79; Sat, 26 May 2001 21:40:14 +0200 (CEST) Date: Sat, 26 May 2001 21:40:14 +0200 From: Jesper Skriver To: Harkirat Singh Cc: Josh Paetzel , freebsd-net@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: UDP - Reliable throughput mesaurement Message-ID: <20010526214014.C95985@skriver.dk> References: <01052614133701.54532@mark9.vladsempire.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from singh@pdx.edu on Sat, May 26, 2001 at 12:24:45PM -0700 X-PGP-Fingerprint: 6B88 9CE8 66E9 E631 C9C5 5EB4 22AB F0EC F956 1C31 X-PGP-Public-Key: http://freesbee.wheel.dk/~jesper/gpgkey.pub Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, May 26, 2001 at 12:24:45PM -0700, Harkirat Singh wrote: > On Sat, 26 May 2001, Josh Paetzel wrote: > > > On Saturday 26 May 2001 13:51, Harkirat Singh wrote: > > > > > Hello! > > > > > > I want to measure UDP thruput of lossy channel, is there any > > > tool which tests it? I looked at some of the tools but these do > > > not take care of loss, I mean no retransmisson, just measure raw > > > thruput of UDP (TTCP is one of these). > > > > > > I am looking for a measurement tool which should retransmit in > > > case of loss and keep a track of packets, I mean make UDP reliable > > > amd blocking calls. > > > > > > Thanks, > > > > > > Harkirat > > > > Uhhmmm, seeing as UDP is specifically designed as being "lossy" I > > don't think there is going to be anything that can help you out > > there. There is a really good protocol that you can use if you need > > "reliable" delivery of packets over IP. If I remember right, it is > > called TCP. > > > > Josh > > I specifically want to see the performance of UDP in lossy channel, I > am sure there must be some tool to measure it, I doing a kind of study > and want to analyse TCP vs. UDP! But when you want retransmission of UDP, you have to implement it in the application layer, and then you're actually measureing the performance of your application (and how it's retransmission algoritems compare to those of TCP) as much as your measureing the performance of UDP vs. TCP. /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work: Network manager @ AS3292 (Tele Danmark DataNetworks) Private: FreeBSD committer @ AS2109 (A much smaller network ;-) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 26 12:52:23 2001 Delivered-To: freebsd-net@freebsd.org Received: from thor.oit.pdx.edu (thor.oit.pdx.edu [131.252.120.40]) by hub.freebsd.org (Postfix) with ESMTP id 3BC1537B422; Sat, 26 May 2001 12:52:17 -0700 (PDT) (envelope-from singh@pdx.edu) Received: from freke.odin.pdx.edu (freke.odin.pdx.edu [131.252.120.43]) by thor.oit.pdx.edu (8.11.1/8.11.1) with ESMTP id f4QJqGc26502; Sat, 26 May 2001 12:52:16 -0700 (PDT) Received: from localhost (singh@localhost) by freke.odin.pdx.edu (8.11.1/8.11.1) with ESMTP id f4QJqGM19699; Sat, 26 May 2001 12:52:16 -0700 (PDT) X-Authentication-Warning: freke.odin.pdx.edu: singh owned process doing -bs Date: Sat, 26 May 2001 12:52:15 -0700 (PDT) From: Harkirat Singh X-X-Sender: To: "Justin C.Walker" Cc: , "" Subject: Re: UDP - Reliable throughput mesaurement In-Reply-To: <20010526193825.VXQR16646.femail4.sdc1.sfba.home.com@grinch> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Thanks for your reply, I looked at Netpref and that even I used for measuring thruput in case of TCP. I felt that instead of writing my own reliable application over UDP I would use some standard mesaurement tool. In Netperf they have a option called "UDP_RR" UDP Request/Reply, will this take care of loss? I feel that there must be some tool which I am not aware of. Regards, Harkirat On Sat, 26 May 2001, Justin C.Walker wrote: > > On Saturday, May 26, 2001, at 12:24 PM, Harkirat Singh wrote: > > > > > I specifically want to see the performance of UDP in lossy > > channel, I am > > sure there must be some tool to measure it, I doing a kind of study and > > want to analyse TCP vs. UDP! > > If you want to measure the performance of these two protocols, use > 'netperf'. It provides several options for looking at performance. > > Your original message indicated you wanted a tool that provides a > reliable layer on UDP, which, obviously, is not the same thing. > Which do you want? UDP or a reliable datagram protocol? > > Regards, > > Justin > > --- > Justin C. Walker, Curmudgeon-At-Large * > Institute for General Semantics | > Director of Technology | It's not whether you win > or lose... > Nexsi Systems Corp. | It's whether *I* win or lose. > 1959 Concourse Drive | > San Jose, CA 95131 | > *--------------------------------------*-------------------------------* > > 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 Sat May 26 13:16:45 2001 Delivered-To: freebsd-net@freebsd.org Received: from femail4.sdc1.sfba.home.com (femail4.sdc1.sfba.home.com [24.0.95.84]) by hub.freebsd.org (Postfix) with ESMTP id 824D237B423; Sat, 26 May 2001 13:16:40 -0700 (PDT) (envelope-from justin@mac.com) Received: from grinch ([65.11.111.111]) by femail4.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010526201635.WNXH16646.femail4.sdc1.sfba.home.com@grinch>; Sat, 26 May 2001 13:16:35 -0700 Date: Sat, 26 May 2001 13:16:32 -0700 Content-Type: text/plain; format=flowed; charset=us-ascii X-Mailer: Apple Mail (2.388) From: Justin C.Walker To: , "" Mime-Version: 1.0 (Apple Message framework v388) In-Reply-To: Subject: Re: UDP - Reliable throughput mesaurement Content-Transfer-Encoding: 7bit Message-Id: <20010526201635.WNXH16646.femail4.sdc1.sfba.home.com@grinch> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Saturday, May 26, 2001, at 12:52 PM, Harkirat Singh wrote: > > Thanks for your reply, I looked at Netpref and that even I used for > measuring thruput in case of TCP. I felt that instead of writing my own > reliable application over UDP I would use some standard > mesaurement tool. > > In Netperf they have a option called "UDP_RR" UDP Request/Reply, > will this > take care of loss? I feel that there must be some tool which I am not > aware of. There are no tools that I'm aware of that do what you want directly. The doc that comes with 'netperf' isn't exactly complete in its description of what UDP_RR does. The implication of the man page is that it complains if a request times out. Check the source is my advice. Regards, Justin --- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Director of Technology | When LuteFisk is outlawed Nexsi Systems Corp. | Only outlaws will have 1959 Concourse Drive | LuteFisk San Jose, CA 95131 | *--------------------------------------*-------------------------------* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 26 14: 0:27 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.freebsd-corp-net-guide.com (mail.freebsd-corp-net-guide.com [206.29.169.15]) by hub.freebsd.org (Postfix) with ESMTP id 4AA1D37B424; Sat, 26 May 2001 14:00:21 -0700 (PDT) (envelope-from tedm@toybox.placo.com) Received: from tedm.placo.com (nat-rtr.freebsd-corp-net-guide.com [206.29.168.154]) by mail.freebsd-corp-net-guide.com (8.11.1/8.11.1) with SMTP id f4QL0Gk88365; Sat, 26 May 2001 14:00:16 -0700 (PDT) (envelope-from tedm@toybox.placo.com) From: "Ted Mittelstaedt" To: "Harkirat Singh" , "Bill Moran" Cc: , Subject: RE: UDP - Reliable throughput mesaurement tool Date: Sat, 26 May 2001 14:00:16 -0700 Message-ID: <000201c0e626$dd311120$1401a8c0@tedm.placo.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 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Ah - NO. UDP and TCP were specifically DESIGNED for DIFFERENT network conditions. Your making an apples-to-oranges comparison here which isn't going to give you any useful information. One kind of network condition will make TCP be horrible and UDP be great - an other kind of condition will make UDP be horrible and TCP be great. Tell us which protocol you want to "win" and we can tell you how to stack the test. Ted Mittelstaedt tedm@toybox.placo.com Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com >-----Original Message----- >From: owner-freebsd-questions@FreeBSD.ORG >[mailto:owner-freebsd-questions@FreeBSD.ORG]On Behalf Of Harkirat Singh >Sent: Saturday, May 26, 2001 12:27 PM >To: Bill Moran >Cc: freebsd-net@FreeBSD.ORG; freebsd-questions@FreeBSD.ORG >Subject: Re: UDP - Reliable throughput mesaurement tool > > > >I am looking at performance of UDT and TCP in same network condition!! > >-Harkirat > >On Sat, 26 May 2001, Bill Moran wrote: > >> Harkirat Singh wrote: >> > >> > Hello! >> > >> > I want to measure UDP thruput of lossy channel, is >there any tool >> > which tests it? I looked at some of the tools but these do not >take care >> > of loss, I mean no retransmisson, just measure raw thruput of UDP (TTCP >> > is one of these). >> > >> > I am looking for a measurement tool which should retransmit in case of >> > loss and keep a track of packets, I mean make UDP reliable amd blocking >> > calls. >> >> I may be missing something here ... but if you're looking for reliable >> UDP, why not use TCP? >> >> -Bill >> >> To Unsubscribe: send mail to majordomo@FreeBSD.org >> with "unsubscribe freebsd-questions" in the body of the message >> > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-questions" 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 Sat May 26 14:38: 7 2001 Delivered-To: freebsd-net@freebsd.org Received: from herbelot.dyndns.org (s108.dhcp212-198-28.noos.fr [212.198.28.108]) by hub.freebsd.org (Postfix) with ESMTP id 6556337B422 for ; Sat, 26 May 2001 14:38:04 -0700 (PDT) (envelope-from thierry@herbelot.com) Received: from herbelot.com (multi.herbelot.nom [192.168.1.2]) by herbelot.dyndns.org (8.9.3/8.9.3) with ESMTP id XAA83609; Sat, 26 May 2001 23:59:25 +0200 (CEST) (envelope-from thierry@herbelot.com) Message-ID: <3B102232.1C513EBF@herbelot.com> Date: Sat, 26 May 2001 23:37:54 +0200 From: Thierry Herbelot X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Harkirat Singh Cc: freebsd-net@FreeBSD.ORG Subject: Re: UDP - Reliable throughput mesaurement tool References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Harkirat Singh wrote: > > Hello! > > I want to measure UDP thruput of lossy channel, is there any tool > which tests it? I looked at some of the tools but these do not take care > of loss, I mean no retransmisson, just measure raw thruput of UDP (TTCP > is one of these). Matt Dillon has written a tool called linktest, which can be a base for any UDP reliability ot throughput test (no URL, sorry, but it may be in the archives) > > I am looking for a measurement tool which should retransmit in case of > loss and keep a track of packets, I mean make UDP reliable amd blocking > calls. this is another beast : there are many ways to render UDP reliable .... > > Thanks, > > Harkirat > -- Thierry Herbelot To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 26 15: 7:21 2001 Delivered-To: freebsd-net@freebsd.org Received: from freesbee.wheel.dk (freesbee.wheel.dk [193.162.159.97]) by hub.freebsd.org (Postfix) with ESMTP id 7D2A737B423 for ; Sat, 26 May 2001 15:07:12 -0700 (PDT) (envelope-from jesper@skriver.dk) Received: by freesbee.wheel.dk (Postfix, from userid 1001) id D58005D3B; Sun, 27 May 2001 00:08:54 +0200 (CEST) Date: Sun, 27 May 2001 00:08:54 +0200 From: Jesper Skriver To: freebsd-net@FreeBSD.org Subject: Re: control TCP send/recieve window size based on port numbers ? and a bug(?) in sendpipe/recvpipe handling ... Message-ID: <20010527000854.B98021@skriver.dk> References: <20010526213442.A95985@skriver.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010526213442.A95985@skriver.dk>; from jesper@FreeBSD.org on Sat, May 26, 2001 at 09:34:42PM +0200 X-PGP-Fingerprint: 6B88 9CE8 66E9 E631 C9C5 5EB4 22AB F0EC F956 1C31 X-PGP-Public-Key: http://freesbee.wheel.dk/~jesper/gpgkey.pub Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, May 26, 2001 at 09:34:42PM +0200, Jesper Skriver wrote: > Hi, > > I'm currently looking at ways to tune a ftp server, and when > tuning net.inet.tcp.sendspace/net.inet.tcp.recvspace and > NMBCLUSTERS, I came to think that in a ftp server role, half the > TCP sessions will be control sessions, which doesn't transfer much > data, so there is no reason to reserve the same number of buffers > for sendspace/recvspace for these, compared to the data sessions. > > I was thinking of adding 3 new sysctl's > > net.inet.tcp.override_sendspace > net.inet.tcp.override_recvspace > net.inet.tcp.override_ports > > The latter controls which (if any) src/dst ports, trigger the > session to get the overridden send and recv-space applied. > > Does this make any sense ? As Mike Silbersack has educated me, the sendspace and recvspace is only the upper limit pr. session, and it's not static allocated, so this i not a problem, and thus this patch doesn't give us anything. So the only thing remaining is the bug where the sendpipe/recvpipe doesn't have any effect. /Jesper > For my own testing I'm using > > which do this with one exception, it only allow's one port to be > listed as override, I was to lazy to go into a comma separeted list > for my initial testing. > And I need to add these 3 sysctl's to tcp(4). > > My testing show that it doesn't seem to have any effect, but that > actually show a different problem, as the sendpipe/recvpipe > doesn't seem to have any effect either. > > On a box running stock -current as of may 16th > > root@tam% route change default -sendpipe 1024 > change net default > root@tam% route change default -recvpipe 1024 > change net default > root@tam% route get default > route to: default > destination: default > mask: default > gateway: dhcp129.skriver.dk > interface: xl0 > flags: > recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire > 1024 1024 0 0 0 0 1500 0 > > And then I get a file from the http server on this host, but > netstat -a give me > > root@tam% netstat -a|head -3 > Active Internet connections (including servers) > Proto Recv-Q Send-Q Local Address Foreign Address (state) > tcp4 0 17520 dhcp138.skriver..http freesbee.wheel.d.1162 ESTABLISHED > > So the send queue is the default 16k, regardless of the fact that > I've overridden the default via the route > > Ok, perhaps I have to change it at the cloned route. > > root@tam% route get 193.162.159.97 > route to: freesbee.wheel.dk > destination: freesbee.wheel.dk > gateway: dhcp129.skriver.dk > interface: xl0 > flags: > recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire > 0 0 139462230 79 7 0 1500 3421 > root@tam% route change 193.162.159.97 -sendpipe 1024 -recvpipe 1024 > change host 193.162.159.97 > root@tam% route get 193.162.159.97 > route to: freesbee.wheel.dk > destination: freesbee.wheel.dk > gateway: dhcp129.skriver.dk > interface: xl0 > flags: > recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire > 1024 1024 139462230 79 7 0 1500 3390 > > But still I get > > jesper@tam% netstat -a | head -3 > Active Internet connections (including servers) > Proto Recv-Q Send-Q Local Address Foreign Address (state) > tcp4 0 16384 dhcp138.skriver..http freesbee.wheel.d.1177 ESTABLISHED > > Any ideas ? > > /Jesper > > -- > Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 > Work: Network manager @ AS3292 (Tele Danmark DataNetworks) > Private: FreeBSD committer @ AS2109 (A much smaller network ;-) > > One Unix to rule them all, One Resolver to find them, > One IP to bring them all and in the zone to bind them. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work: Network manager @ AS3292 (Tele Danmark DataNetworks) Private: FreeBSD committer @ AS2109 (A much smaller network ;-) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 26 19:32:39 2001 Delivered-To: freebsd-net@freebsd.org Received: from fester.unkempt.net (cm623478-a.ftwrth1.tx.home.com [24.4.14.251]) by hub.freebsd.org (Postfix) with ESMTP id 545EF37B422 for ; Sat, 26 May 2001 19:32:36 -0700 (PDT) (envelope-from brandt@unkempt.net) Received: from osc20 (OSC3 [206.46.190.20]) by fester.unkempt.net (8.9.3/8.9.3) with SMTP id VAA56570 for ; Sat, 26 May 2001 21:37:05 -0500 (CDT) (envelope-from brandt@unkempt.net) Message-ID: <00c901c0e655$481099b0$14be2ece@osc20> From: "Brandt" To: Subject: natd, 2 NIC's, 2 Hubs, Something I'm missing? Date: Sat, 26 May 2001 21:32:22 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello all, this has got me stumped. FreeBSD 4.3 vr0: ip= 65.3.111.111 subnet 255.255.255.0 dc0: ip= 192.168.1.1 subnet 255.255.255.0 Kernel has been recompiled with IPDIVERT and IPFIREWALL options, and every thing WORKS fine as long as I have both NIC's pluged into the SAME hub. But shouldn't this also work when the vr0 interface is moved to a seperate hub? So that the internet interface and the LAN interface (dc0) are on seperate networks? The strange thing is that as soon as I unplug the 65.3.*.* interface from the hub, the other 192.168.1.* boxes can't ping the dc0, 192.168.1.1 interface even though they are still connected to the same hub. At the same time, the dc0 interface can still ping the other LAN boxen on the 192.168 network. Any ideas as to what is going on? - Brandt ## My Kernel ########## options IPDIVERT options IPFIREWALL ## /etc/rc.conf ########## sendmail_enable="YES" sshd_enable="YES" inetd_enable="YES" gateway_enable="YES" network_interfaces="vr0 lo0 dc0" ifconfig_vr0="inet 65.3.111.111 netmask 255.255.255.0" defaultrouter="65.3.111.1" ifconfig_dc0="inet 192.168.1.1 netmask 255.255.255.0" hostname="myhostname.mydomain.com" #NATD natd_enable="YES" natd_interface="vr0" natd_flags="-f /etc/natd.conf" #FIREWALL firewall_enable="YES" firewall_script="/etc/rc.firewall" firewall_type="open" firewall_quiet="NO" firewall_logging="YES" firewall_flags="" #ATTEMPT TO CORRECT ROUTING TABLE router_enable="YES" router="routed" router_flags="-s" ## ifconfig ########## dc0: flags=8843 mtu 1500 inet 192.168.1.1 netmask 0xffff0000 broadcast 192.168.255.255 inet6 fe80::280:c8ff:fee8:58fe%dc0 prefixlen 64 scopeid 0x1 ether ff:ff:ff:ff:ff:ff media: autoselect (100baseTX ) status: active supported media: autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none vr0: flags=8843 mtu 1500 inet 65.3.111.111 netmask 0xffffff00 broadcast 65.3.111.255 inet6 fe80::280:c8ff:fee8:58fe%vr0 prefixlen 64 scopeid 0x2 ether 00:80:c8:e8:58:fe media: autoselect (10baseT/UTP) status: active supported media: autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 26 19:52:11 2001 Delivered-To: freebsd-net@freebsd.org Received: from femail1.sdc1.sfba.home.com (femail1.sdc1.sfba.home.com [24.0.95.81]) by hub.freebsd.org (Postfix) with ESMTP id 6C74737B422 for ; Sat, 26 May 2001 19:52:07 -0700 (PDT) (envelope-from justin@mac.com) Received: from grinch ([65.11.111.111]) by femail1.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010527025207.FXQD13163.femail1.sdc1.sfba.home.com@grinch> for ; Sat, 26 May 2001 19:52:07 -0700 Date: Sat, 26 May 2001 19:52:04 -0700 Content-Type: text/plain; format=flowed; charset=us-ascii X-Mailer: Apple Mail (2.388) From: Justin C.Walker To: Mime-Version: 1.0 (Apple Message framework v388) In-Reply-To: <00c901c0e655$481099b0$14be2ece@osc20> Subject: Re: natd, 2 NIC's, 2 Hubs, Something I'm missing? Content-Transfer-Encoding: 7bit Message-Id: <20010527025207.FXQD13163.femail1.sdc1.sfba.home.com@grinch> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Your msg implies you're using NAT, but you've not included anything about the NAT config. Also, the 'ifconfig' output for dc0 doesn't jibe with the rest of your message. Regards, Justin On Saturday, May 26, 2001, at 07:32 PM, Brandt wrote: > Hello all, this has got me stumped. > > FreeBSD 4.3 > vr0: ip= 65.3.111.111 subnet 255.255.255.0 > dc0: ip= 192.168.1.1 subnet 255.255.255.0 > > Kernel has been recompiled with IPDIVERT and IPFIREWALL options, > and every thing WORKS fine as long as I have both NIC's pluged into the > SAME hub. > > But shouldn't this also work when the vr0 interface is moved to a > seperate > hub? So that the internet interface and the LAN interface (dc0) are on > seperate networks? > > The strange thing is that as soon as I unplug the 65.3.*.* > interface from the > hub, the other 192.168.1.* boxes can't ping the dc0, 192.168.1.1 > interface > even though they are still connected to the same hub. At the same > time, the > dc0 interface can still ping the other LAN boxen on the 192.168 > network. > > Any ideas as to what is going on? > > - Brandt > ## My Kernel ########## > options IPDIVERT > options IPFIREWALL > > ## /etc/rc.conf ########## > sendmail_enable="YES" > sshd_enable="YES" > inetd_enable="YES" > gateway_enable="YES" > network_interfaces="vr0 lo0 dc0" > ifconfig_vr0="inet 65.3.111.111 netmask 255.255.255.0" > defaultrouter="65.3.111.1" > ifconfig_dc0="inet 192.168.1.1 netmask 255.255.255.0" > hostname="myhostname.mydomain.com" > > #NATD > natd_enable="YES" > natd_interface="vr0" > natd_flags="-f /etc/natd.conf" > > #FIREWALL > firewall_enable="YES" > firewall_script="/etc/rc.firewall" > firewall_type="open" > firewall_quiet="NO" > firewall_logging="YES" > firewall_flags="" > > #ATTEMPT TO CORRECT ROUTING TABLE > router_enable="YES" > router="routed" > router_flags="-s" > > ## ifconfig ########## > dc0: flags=8843 mtu 1500 > inet 192.168.1.1 netmask 0xffff0000 broadcast 192.168.255.255 > inet6 fe80::280:c8ff:fee8:58fe%dc0 prefixlen 64 scopeid 0x1 > ether ff:ff:ff:ff:ff:ff > media: autoselect (100baseTX ) status: active > supported media: autoselect 100baseTX > 100baseTX 10baseT/UTP 10baseT/UTP none > vr0: flags=8843 mtu 1500 > inet 65.3.111.111 netmask 0xffffff00 broadcast 65.3.111.255 > inet6 fe80::280:c8ff:fee8:58fe%vr0 prefixlen 64 scopeid 0x2 > ether 00:80:c8:e8:58:fe > media: autoselect (10baseT/UTP) status: active > supported media: autoselect 100baseTX > 100baseTX 10baseT/UTP 10baseT/UTP none --- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Director of Technology | It's not whether you win or lose... Nexsi Systems Corp. | It's whether *I* win or lose. 1959 Concourse Drive | San Jose, CA 95131 | *--------------------------------------*-------------------------------* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 26 20: 0: 3 2001 Delivered-To: freebsd-net@freebsd.org Received: from fester.unkempt.net (cm623478-a.ftwrth1.tx.home.com [24.4.14.251]) by hub.freebsd.org (Postfix) with ESMTP id 7BD9537B422 for ; Sat, 26 May 2001 19:59:57 -0700 (PDT) (envelope-from brandt@unkempt.net) Received: from osc20 (OSC3 [206.46.190.20]) by fester.unkempt.net (8.9.3/8.9.3) with SMTP id WAA56633 for ; Sat, 26 May 2001 22:04:26 -0500 (CDT) (envelope-from brandt@unkempt.net) Message-ID: <00ef01c0e659$1a49dce0$14be2ece@osc20> From: "Brandt" To: References: <20010527025207.FXQD13163.femail1.sdc1.sfba.home.com@grinch> Subject: Re: natd, 2 NIC's, 2 Hubs, Something I'm missing? Date: Sat, 26 May 2001 21:59:23 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Well, I assumed the natd would be noticed in the subject line, and also it is listed under the "rc.conf" section I listed below. As for the dc0, I forgot I had tried a 255.255.0.0 subnet, and played with the broadcast just for giggles. Normally they are 255.255.0.0 and 192.168.1.255 respectively. And no its not the firewall rules, I don't think, but I'm no expert. ## ipfw ######### 00050 divert 8668 ip from any to any via vr0 00100 allow ip from any to any via lo0 00200 deny ip from any to 127.0.0.0/8 00300 deny ip from 127.0.0.0/8 to any 65000 allow ip from any to any 65535 deny ip from any to any ----- Original Message ----- From: "Justin C.Walker" To: Sent: Saturday, May 26, 2001 9:52 PM Subject: Re: natd, 2 NIC's, 2 Hubs, Something I'm missing? > Your msg implies you're using NAT, but you've not included anything > about the NAT config. Also, the 'ifconfig' output for dc0 doesn't > jibe with the rest of your message. > > Regards, > > Justin > > On Saturday, May 26, 2001, at 07:32 PM, Brandt wrote: > > > Hello all, this has got me stumped. > > > > FreeBSD 4.3 > > vr0: ip= 65.3.111.111 subnet 255.255.255.0 > > dc0: ip= 192.168.1.1 subnet 255.255.255.0 > > > > Kernel has been recompiled with IPDIVERT and IPFIREWALL options, > > and every thing WORKS fine as long as I have both NIC's pluged into the > > SAME hub. > > > > But shouldn't this also work when the vr0 interface is moved to a > > seperate > > hub? So that the internet interface and the LAN interface (dc0) are on > > seperate networks? > > > > The strange thing is that as soon as I unplug the 65.3.*.* > > interface from the > > hub, the other 192.168.1.* boxes can't ping the dc0, 192.168.1.1 > > interface > > even though they are still connected to the same hub. At the same > > time, the > > dc0 interface can still ping the other LAN boxen on the 192.168 > > network. > > > > Any ideas as to what is going on? > > > > - Brandt > > ## My Kernel ########## > > options IPDIVERT > > options IPFIREWALL > > > > ## /etc/rc.conf ########## > > sendmail_enable="YES" > > sshd_enable="YES" > > inetd_enable="YES" > > gateway_enable="YES" > > network_interfaces="vr0 lo0 dc0" > > ifconfig_vr0="inet 65.3.111.111 netmask 255.255.255.0" > > defaultrouter="65.3.111.1" > > ifconfig_dc0="inet 192.168.1.1 netmask 255.255.255.0" > > hostname="myhostname.mydomain.com" > > > > #NATD > > natd_enable="YES" > > natd_interface="vr0" > > natd_flags="-f /etc/natd.conf" > > > > #FIREWALL > > firewall_enable="YES" > > firewall_script="/etc/rc.firewall" > > firewall_type="open" > > firewall_quiet="NO" > > firewall_logging="YES" > > firewall_flags="" > > > > #ATTEMPT TO CORRECT ROUTING TABLE > > router_enable="YES" > > router="routed" > > router_flags="-s" > > > > ## ifconfig ########## > > dc0: flags=8843 mtu 1500 > > inet 192.168.1.1 netmask 0xffff0000 broadcast 192.168.255.255 > > inet6 fe80::280:c8ff:fee8:58fe%dc0 prefixlen 64 scopeid 0x1 > > ether ff:ff:ff:ff:ff:ff > > media: autoselect (100baseTX ) status: active > > supported media: autoselect 100baseTX > > 100baseTX 10baseT/UTP 10baseT/UTP none > > vr0: flags=8843 mtu 1500 > > inet 65.3.111.111 netmask 0xffffff00 broadcast 65.3.111.255 > > inet6 fe80::280:c8ff:fee8:58fe%vr0 prefixlen 64 scopeid 0x2 > > ether 00:80:c8:e8:58:fe > > media: autoselect (10baseT/UTP) status: active > > supported media: autoselect 100baseTX > > 100baseTX 10baseT/UTP 10baseT/UTP none > > --- > Justin C. Walker, Curmudgeon-At-Large * > Institute for General Semantics | > Director of Technology | It's not whether you win > or lose... > Nexsi Systems Corp. | It's whether *I* win or lose. > 1959 Concourse Drive | > San Jose, CA 95131 | > *--------------------------------------*-------------------------------* > > 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 Sat May 26 22: 7:45 2001 Delivered-To: freebsd-net@freebsd.org Received: from femail1.sdc1.sfba.home.com (femail1.sdc1.sfba.home.com [24.0.95.81]) by hub.freebsd.org (Postfix) with ESMTP id 41A8737B423 for ; Sat, 26 May 2001 22:07:42 -0700 (PDT) (envelope-from justin@mac.com) Received: from grinch ([65.11.111.111]) by femail1.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010527050742.IAAH13163.femail1.sdc1.sfba.home.com@grinch> for ; Sat, 26 May 2001 22:07:42 -0700 Date: Sat, 26 May 2001 22:07:40 -0700 Content-Type: text/plain; format=flowed; charset=us-ascii X-Mailer: Apple Mail (2.388) From: Justin C.Walker To: Mime-Version: 1.0 (Apple Message framework v388) In-Reply-To: <00ef01c0e659$1a49dce0$14be2ece@osc20> Subject: Re: natd, 2 NIC's, 2 Hubs, Something I'm missing? Content-Transfer-Encoding: 7bit Message-Id: <20010527050742.IAAH13163.femail1.sdc1.sfba.home.com@grinch> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Saturday, May 26, 2001, at 07:59 PM, Brandt wrote: > Well, I assumed the natd would be noticed in the subject line, and also > it is listed under the "rc.conf" section I listed below. I did indeed notice that you mentioned Natd, but without the config, it's hard to tell whether you are actually using it. It's also hard to diagnose a problem without all the info. I'm no expert in firewalls either, but your rules look a bit odd to me. They seem to work on my box, though, so I suppose they're OK. Another thing you haven't mentioned is whether you've enabled forwarding: sysctl -w net.inet.ip.fowarding=1 (at least, that's the syntax on my 3.2-based Darwin system). Regards, Justin > As for the dc0, I forgot I had tried a 255.255.0.0 subnet, and played > with the broadcast just for giggles. Normally they are 255.255.0.0 > and 192.168.1.255 respectively. > > And no its not the firewall rules, I don't think, but I'm no expert. > ## ipfw ######### > 00050 divert 8668 ip from any to any via vr0 > 00100 allow ip from any to any via lo0 > 00200 deny ip from any to 127.0.0.0/8 > 00300 deny ip from 127.0.0.0/8 to any > 65000 allow ip from any to any > 65535 deny ip from any to any > > ----- Original Message ----- > From: "Justin C.Walker" > To: > Sent: Saturday, May 26, 2001 9:52 PM > Subject: Re: natd, 2 NIC's, 2 Hubs, Something I'm missing? > --- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Director of Technology | It's not whether you win or lose... Nexsi Systems Corp. | It's whether *I* win or lose. 1959 Concourse Drive | San Jose, CA 95131 | *--------------------------------------*-------------------------------* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 26 22:39:48 2001 Delivered-To: freebsd-net@freebsd.org Received: from mailfarm.ipfnet.net (mailfarm.ipfnet.net [195.211.129.222]) by hub.freebsd.org (Postfix) with ESMTP id D45EF37B42C for ; Sat, 26 May 2001 22:39:41 -0700 (PDT) (envelope-from ml-freebsd-net@phobgate.de) Received: from [192.168.2.94] (router-195-211-129.ipfnet.net [195.211.129.1]) (authenticated) by mailfarm.ipfnet.net (8.11.3/8.11.3) with ESMTP id f4R5dUr79607; Sun, 27 May 2001 07:39:31 +0200 (CEST) Date: Sun, 27 May 2001 07:39:33 +0200 From: alex Reply-To: alex To: Brandt , freebsd-net@freebsd.org Subject: Re: natd, 2 NIC's, 2 Hubs, Something I'm missing? Message-ID: <3106695403.990949173@[192.168.2.94]> In-Reply-To: <00c901c0e655$481099b0$14be2ece@osc20> X-Mailer: Mulberry/2.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org hi, i have a fbsd 4.3 box with natd acting as a router too. unfortunately i did all the natd and ipfw stuff in my own rc.firewall script. but here my suggestions: - kernel options seems to be ok for natd - in rc.conf remove the 'natd_flags="-f /etc/natd.conf"' line in NATD section (or do you have anything special in this file..?). remove the whole 'router_*' section (you probably don't need routing when doing nat). - as you have the 'gateway_enable=YES' in your rc.conf, net.inet.ip.forwarding should already be enabled (done by rc.network if gateway_enable=yes) and anything should be fine, well i hope so :) i'm just worried about your ifconfig output for dc0, hat it really hw_addr of ff:ff:ff:ff:ff:ff ? unusual i think..?? greetings, alex --On Samstag, 26. Mai 2001 21:32 -0500 Brandt wrote: > Hello all, this has got me stumped. > > FreeBSD 4.3 > vr0: ip= 65.3.111.111 subnet 255.255.255.0 > dc0: ip= 192.168.1.1 subnet 255.255.255.0 > > Kernel has been recompiled with IPDIVERT and IPFIREWALL options, > and every thing WORKS fine as long as I have both NIC's pluged into the > SAME hub. > > But shouldn't this also work when the vr0 interface is moved to a > seperate hub? So that the internet interface and the LAN interface > (dc0) are on seperate networks? > > The strange thing is that as soon as I unplug the 65.3.*.* interface from > the hub, the other 192.168.1.* boxes can't ping the dc0, 192.168.1.1 > interface even though they are still connected to the same hub. At the > same time, the dc0 interface can still ping the other LAN boxen on the > 192.168 network. > > Any ideas as to what is going on? > > - Brandt > ## My Kernel ########## > options IPDIVERT > options IPFIREWALL > > ## /etc/rc.conf ########## > sendmail_enable="YES" > sshd_enable="YES" > inetd_enable="YES" > gateway_enable="YES" > network_interfaces="vr0 lo0 dc0" > ifconfig_vr0="inet 65.3.111.111 netmask 255.255.255.0" > defaultrouter="65.3.111.1" > ifconfig_dc0="inet 192.168.1.1 netmask 255.255.255.0" > hostname="myhostname.mydomain.com" > > #NATD > natd_enable="YES" > natd_interface="vr0" > natd_flags="-f /etc/natd.conf" > > #FIREWALL > firewall_enable="YES" > firewall_script="/etc/rc.firewall" > firewall_type="open" > firewall_quiet="NO" > firewall_logging="YES" > firewall_flags="" > > #ATTEMPT TO CORRECT ROUTING TABLE > router_enable="YES" > router="routed" > router_flags="-s" > > ## ifconfig ########## > dc0: flags=8843 mtu 1500 > inet 192.168.1.1 netmask 0xffff0000 broadcast 192.168.255.255 > inet6 fe80::280:c8ff:fee8:58fe%dc0 prefixlen 64 scopeid 0x1 > ether ff:ff:ff:ff:ff:ff > media: autoselect (100baseTX ) status: active > supported media: autoselect 100baseTX 100baseTX > 10baseT/UTP 10baseT/UTP none vr0: > flags=8843 mtu 1500 inet > 65.3.111.111 netmask 0xffffff00 broadcast 65.3.111.255 inet6 > fe80::280:c8ff:fee8:58fe%vr0 prefixlen 64 scopeid 0x2 ether > 00:80:c8:e8:58:fe > media: autoselect (10baseT/UTP) status: active > supported media: autoselect 100baseTX 100baseTX > 10baseT/UTP 10baseT/UTP none > > > > > 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