From owner-freebsd-net Sun Apr 15 8: 7:56 2001 Delivered-To: freebsd-net@freebsd.org Received: from luxren2.boostworks.com (luxren2.boostworks.com [194.167.81.214]) by hub.freebsd.org (Postfix) with ESMTP id 11BDF37B440 for ; Sun, 15 Apr 2001 08:07:49 -0700 (PDT) (envelope-from root@boostworks.com) Received: from boostworks.com (root@oldrn.lxlun.boostworks.com [192.168.8.101]) by luxren2.boostworks.com (8.11.3/8.11.3) with ESMTP id f3FF7iC97018 for ; Sun, 15 Apr 2001 17:07:45 +0200 (CEST) Message-Id: <200104151507.f3FF7iC97018@luxren2.boostworks.com> Date: Sun, 15 Apr 2001 17:10:02 +0200 (CEST) From: Remy Nonnenmacher Reply-To: remy@boostworks.com Subject: fxp+bridge: highly suspect syndrom. To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm looking for any idea about a very strange problem: Context: I'm using an interposed machine (TRACER) running bridge between to interfaces. There is two other machines (UA and OS) connected via the interposed machine: (All machines are 4.2-REL) UA ------- TRACER ------- OS All machines uses fxp interfaces. Connection is done via crossed cables. The UA machine runs a loader, requesting about 7000 HTML pages on the OS (1 connection per page). All NMBCLUSTERS are bumped up to handle this load. During a direct test (without TRACER), UA and OS run at about 15% of their maximum load and network is solid red (100Mbit/s from OS to UA). No glitches, no problems. The TRACER employ the standard briging code. It supports up to 4x100 Mbit/s @ 25-30% load, moving around 30.000 paquets/sec between the interfaces. No load or limits problem with this machine. This have been tested by pumping data between OS and UA. Problem: when the tracer is interposed _and_ the specific Loader test (the 7000 connect/data_transfert/disconnect) is run, _and_ there is more than one connection running at a time, then, between 3 and 50 times during the test, a packet is send by the OS, received by the TRACER and not forwarded until it is repeated by the OS. And now, hold your belt and grasp your suspenders: The only packet that suffer the problem is a SYN+ACK from the OS to the UA. _Never any other ones_ !. The sequence is always exactly the same: UA TRACER OS SYN---------------SYN------------------>SYN SYN+ACK<-----------SYN+ACK . . SYN+ACK<-----------SYN+ACK (repeated) SYN+ACK<------------ SYN+ACK(rep)<------- As if the TRACER<->OS interface received the first SYN+ACK but do not get an interrupt until the repeated frame comes in. What I have checked: - Bridge do not use ipfw to check packets (means: nothing knows nor care about flags) - Instrumented drivers: No packet loss, no discards. - Checked for aging of bridge table: no table aging occured - Instrumented bridge: No DROPS, no UNKNOWN, all packets forwarded regularly. What I have tried: (No effect on the problem) - Changing PCI irq for interfaces - Using same IRQ for two interfaces - Swaping fxp0/fxp1 at TRACER level - Changing cards (using dual Pro100, fxp again) - Switching from the regular 4.2-RELEASE fxp driver to the Jonathan Lemon's one (applied patchset and rebuilt kernel). What works: (changes that make the problem disappears) - using a dec2114X based card on TRACER, at OS side only. (Note that exchanging the sides ('de' on UA side and 'fxp' on OS side) makes the problem raises again (*)) - Making only one connection at a time (1 connect/transfert/disconnect phase at a time). What have a strong influence on the problem (lowers the problem frequency): - hammering the network with packets flood during the loader test - tcpdumping interfaces on TRACER - Running two independant loader test.(**) Notes: (*) This is why i believe the packet is received by the TRACER machine and not that it is kept at OS side for one second. (Outgoing packets catched via tcpdump not meaning 'physically sent on the wire'). (*) Note that the problem appears when the loaded is waiting for a connection to be established. During this time, it do not terminate other existing connections. When two independant tests are ran, it appears like the previous 'hammering' condition. ------------------- From the observation that the problem, in the worst case, repeats quiet exactly at seconds tick intervals (ie: one second runs, one second pause), May I conclude that there is something wrong that relates to (or is a combination of): - Interrupts not transmitted, processed or catched by the fxp driver when there is no other activity than finishing transmitting packets. - a race condition happening at one second intervals with something that repeats regularly (retrieving fxp stats ?) - "'Genious' work inside the 8255X component" (highly double-qoted). I have detailed files (head turning slowly, deep slow voice, slight german accent, half open eyes ;) .. containing tcpdump traces for those interested. I'll keep drilling to locate the cause. Any idea welcome. Thanks. RN. IhM To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Apr 15 8:21: 1 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 AAE3737B43E for ; Sun, 15 Apr 2001 08:20:57 -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 RAA07124; Sun, 15 Apr 2001 17:19:23 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200104151519.RAA07124@info.iet.unipi.it> Subject: Re: fxp+bridge: highly suspect syndrom. In-Reply-To: <200104151507.f3FF7iC97018@luxren2.boostworks.com> from Remy Nonnenmacher at "Apr 15, 2001 05:10:02 pm" To: remy@boostworks.com Date: Sun, 15 Apr 2001 17:19:23 +0200 (CEST) Cc: 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 X-Loop: FreeBSD.org > I'm looking for any idea about a very strange problem: Remy, bridging has been highly broken in 4.x from last summer to approx the beginning of february. Most of the times the breakage came out when using dummynet, but there were some nasty race conditions related, among other things, to passing the ethernet header as a pointer into a part of the mbuf which should not be in use. I suggest upgrading to 4.3 or a recent -stable, this should fix things (at least, the bugs that i knew of). cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone (510) 666 2927 . ----------------------------------+----------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Apr 15 8:32:20 2001 Delivered-To: freebsd-net@freebsd.org Received: from luxren2.boostworks.com (luxren2.boostworks.com [194.167.81.214]) by hub.freebsd.org (Postfix) with ESMTP id 1B4A437B424 for ; Sun, 15 Apr 2001 08:32:16 -0700 (PDT) (envelope-from root@boostworks.com) Received: from boostworks.com (root@oldrn.lxlun.boostworks.com [192.168.8.101]) by luxren2.boostworks.com (8.11.3/8.11.3) with ESMTP id f3FFW8C97061; Sun, 15 Apr 2001 17:32:09 +0200 (CEST) Message-Id: <200104151532.f3FFW8C97061@luxren2.boostworks.com> Date: Sun, 15 Apr 2001 17:34:27 +0200 (CEST) From: Remy Nonnenmacher Reply-To: remy@boostworks.com Subject: Re: fxp+bridge: highly suspect syndrom. To: luigi@info.iet.unipi.it Cc: freebsd-net@FreeBSD.ORG In-Reply-To: <200104151519.RAA07124@info.iet.unipi.it> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 15 Apr, Luigi Rizzo wrote: >> I'm looking for any idea about a very strange problem: > > Remy, > bridging has been highly broken in 4.x from last summer to approx > the beginning of february. Most of the times the breakage came out > when using dummynet, but there were some nasty race conditions > related, among other things, to passing the ethernet header as a > pointer into a part of the mbuf which should not be in use. > > I suggest upgrading to 4.3 or a recent -stable, this should > fix things (at least, the bugs that i knew of). > Hello Luigi, I really doubt the problem is in the bridging code because: 1) Using a dec214X based card solves the problem 2) I carefully read the code and instrumented it to catch any dropping case. There is none. All is pretty straight forward: peak the packet, pass the packet. Nothing else. 3) I checked that dummynet and ipfw are not implied in the problem. (dummynet is even not compiled in). Anyway, I am building a 4.3-STABLE machine to counter-check. As 4.3 employ the same 4.2-REL code for fxp, I do not expect to see any change (Else, I'll have to get out, buy a hat, and eat it ;). Thanks. RN. IaM To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Apr 15 23: 5:35 2001 Delivered-To: freebsd-net@freebsd.org Received: from germes.levi.spb.ru (ip65.levi.spb.ru [212.119.175.65]) by hub.freebsd.org (Postfix) with ESMTP id E4CF737B42C for ; Sun, 15 Apr 2001 23:05:31 -0700 (PDT) (envelope-from dms@wplus.net) Received: from wplus.net (IDENT:dms@pike.levi.spb.ru [10.246.8.43]) by germes.levi.spb.ru (8.11.1/8.11.1) with ESMTP id f3G65B729070; Mon, 16 Apr 2001 10:05:15 +0400 Message-ID: <3ADA8B97.81C06B5B@wplus.net> Date: Mon, 16 Apr 2001 10:05:11 +0400 From: Dmitry Samersoff Organization: LeviSoft X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en, ru MIME-Version: 1.0 To: remy@boostworks.com Cc: freebsd-net@FreeBSD.ORG Subject: Re: fxp+bridge: highly suspect syndrom. References: <200104151507.f3FF7iC97018@luxren2.boostworks.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Remy Nonnenmacher wrote: >- Switching from the regular 4.2-RELEASE fxp driver to the Jonathan > Lemon's one (applied patchset and rebuilt kernel). Sorry for question, I also have problem with 4.2 and fxp driver. Time-to-time my server stop responding. It sends SYN+ACK packets for each SYN and then do nothing. Changing dynamic routing table parameters (in_rmx.c) partially helps in my case (server up time increased from 12h to 3-4-7 days) but I'm still looking for complete solution. What is Jonathan Lemon's driver and where I can get it? Thank you! -- Dmitry Samersoff, dms@wplus.net, ICQ:3161705 http://devnull.wplus.net * There will come soft rains ... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Apr 15 23:32:35 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 7B7C137B440 for ; Sun, 15 Apr 2001 23:32:26 -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 IAA14921; Mon, 16 Apr 2001 08:31:01 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200104160631.IAA14921@info.iet.unipi.it> Subject: diskless stuff To: net@freebsd.org Date: Mon, 16 Apr 2001 08:31:00 +0200 (CEST) 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 X-Loop: FreeBSD.org Hi, i just gave a shot at diskless support in RELENG_4, and I am attaching some code to help setting things. The first one (a shell script called clone_root) helps you create a shared readonly root partition for the diskless clients. The second piece of code is a set of patches for /etc/rc and /etc/rc.diskless2, which do the following: /etc/rc Diskless needs a slightly different sequence of mounts. There used to be a variable, early_nfs_mounts, which controlled this, but it got nuked in 1.209 with no corresponding reinsertion in /etc/rc.diskless2. This patch fixes this. /etc/diskless2 Mount filesystems in the order needed to make things work. Also comment out the mount_null of /var/tmp on /tmp, and assume that /tmp is symlinked to /var/tmp on the root partition. For some reason the mount_null causes a panic here and this workaround seems to work anyways. Any takers to test&commit this to -current ? The clone_root script could go into /usr/share/examples/diskless cheers luigi ------------- cut here ---- file: clone_root ----------------- #!/bin/sh # # (C) 2001 Luigi Rizzo, Gabriele Cecchetti # # Revised 2001.04.16 # clone root filesystem for diskless root stuff # # usage # clone_root all to do a full copy (e.g. bin, sbin...) # clone_root update to recreate /var (including devices) # clone_root to copy /conf and password-related files # # This script assumes that you use a shared readonly root and /usr # partition. The script creates a partial clone of the root partition, # and puts it into ${DEST} (defaults to /diskless_root ) on the server, # where it is read. # # To run a diskless install you need to do the following: # # create /conf/default/etc/fstab # this will replace the standard /etc/fstab and should contain # as a minimum the following lines # ${SERVER}:${DEST} / nfs ro 0 0 # ${SERVER}:/usr /usr nfs ro 0 0 # proc /proc procfs rw 0 0 # # create /conf/default/etc/rc.conf # this will replace the standard rc.conf and should contain # the startup options for the diskless client. Most likely # you will not need to set hostname and ifconfig_* because these # will be already set by the startup code. You will also # probably need to set local_startup="" so that the server's # local startup files will not be used. # # create a kernel config file in /sys/i386/conf/DISKLESS with # options MFS # options BOOTP # options BOOTP_NFSROOT # options BOOTP_COMPAT # and do a full build of the kernel. # If you use the firewall, remember to default to open or your kernel # will not be able to send/receive the bootp packets. # # On the server: # enable NFS server and set /etc/exports as # ${DEST} -maproot=0 -alldirs # /usr -alldirs # # enable bootpd by uncommenting the bootps line in /etc/inetd.conf # and putting at least the following entries in /etc/bootptab: # .default:\ # hn:ht=1:vm=rfc1048:\ # :sm=255.255.255.0:\ # :sa=${SERVER}:\ # :gw=${GATEWAY}:\ # :rp="${SERVER}:${DEST}": # # client1:ha=0123456789ab:tc=.default # # and make sure that client1 is listed in /etc/hosts # VARIABLES: # some manual init is needed here. # DEST the diskless_root dir (goes into /etc/bootptab and /etc/exports # on the server) # DEVICES device entries to create in /dev DEST=/diskless_root DEVICES="all snd1 bktr0" # you should not touch these vars: # SYSDIRS system directories and mountpoints # DIRS mountpoints (empty dirs) # PWFILES files related to passwords # TOCOPY files and dirs to copy from root partition SYSDIRS="dev proc root usr var var/db" DIRS="c cdrom home home2 mnt mnt1 sd1 sd1/usr wd0e wd2 wd2/usr" PWFILES="master.passwd passwd spwd.db pwd.db" TOCOPY="bin boot compat etc modules sbin stand sys" init_diskless_root() { echo "Cleaning old diskless root ($DEST)" cd / rm -rf ${DEST} && echo "Old diskless root removed." echo "Creating $DEST..." mkdir -p $DEST && echo "New diskless root created." echo "+++ Now copy original tree from / ..." ex="" (cd / ; tar -clf - ${TOCOPY} ) | (cd $DEST; tar xvf - ) #(cd / ; find -x dev | cpio -o -H newc ) | \ # (cd $DEST; cpio -i -H newc -d ) echo "+++ Fixing permissions on some objects" chmod 555 $DEST/sbin/init } update_conf_and_pw() { echo "+++ Copying files in /conf and password files" (cd ${DEST} ; rm -rf conf ) (cd / ; tar clf - conf ) | (cd ${DEST}; tar xvf - ) mkdir -p ${DEST}/conf/etc # used to mount things (cd /etc ; tar cvf - ${PWFILES} ) | (cd ${DEST}/etc ; tar xf - ) } update() { echo "+++ update: create mountpoints and device entries, kernel" for i in ${SYSDIRS} ${DIRS} do rm -r -f ${DEST}/$i mkdir -p ${DEST}/$i && chown root:wheel ${DEST}/$i && echo -n "$i " done echo "." ln -s /var/tmp ${DEST}/tmp echo "+++ Now use MAKEDEV to create devices ${DEVICES}" (cd $DEST/dev ; cp /dev/MAKEDEV . ) (cd $DEST/dev ; /dev/MAKEDEV ${DEVICES} ) (cd $DEST/dev ; ln -s /dev/sysmouse mouse ) echo "+++ Copying kernel from /sys/compile/DISKLESS" cp /sys/compile/DISKLESS/kernel $DEST/kernel echo "." } # Main entry point case $1 in all) # clean and reinstall the whole diskless_root init_diskless_root update update_conf_and_pw ;; update) # clean and rebuild mountpoints and device entries update update_conf_and_pw ;; *) # copy /conf and password files update_conf_and_pw ;; esac exit 0 ### end of file ### ------------- cut here --- end of clone_root --------------- ------------- cut here --- patches for /etc/rc and /etc/rc.diskless2 ---- --- src/etc/rc Sat Apr 14 04:32:22 2001 +++ /etc/rc Mon Apr 16 06:48:27 2001 @@ -187,24 +140,24 @@ umount -a >/dev/null 2>&1 +# Run custom disk mounting function here +# +if [ -n "${diskless_mount}" -a -r "${diskless_mount}" ]; then + sh ${diskless_mount} +else # Mount everything except nfs filesystems. mount -a -t nonfs +fi case $? in 0) ;; *) echo 'Mounting /etc/fstab filesystems failed, startup aborted' exit 1 ;; esac -# Run custom disk mounting function here -# -if [ -n "${diskless_mount}" -a -r "${diskless_mount}" ]; then - sh ${diskless_mount} -fi - adjkerntz -i purgedir() { --- src/etc/rc.diskless2 Tue Mar 6 03:15:04 2001 +++ /etc/rc.diskless2 Mon Apr 16 07:12:25 2001 @@ -38,28 +38,34 @@ . /etc/rc.conf fi +echo "+++ mfs_mount of /var" mount_mfs -s ${varsize:=65536} -T qp120at dummy /var var_dirs="run dev db msgs tmp spool spool/mqueue spool/lpd spool/output \ spool/output/lpd" +echo "+++ create dirs in /var" for i in ${var_dirs} do mkdir /var/${i} done -chmod 755 /var/run -chmod 755 /var/db -chmod 755 /var/spool +chmod 755 /var/run /var/db /var/spool chmod 1777 /var/tmp + +mount -a # chown and chgrp are in /usr + chown -R root.daemon /var/spool/output chgrp daemon /var/spool/lpd # # XXX make sure to create one dir for each printer as requested by lpd # -if [ ! -h /tmp -a ! -h /var/tmp ]; then - mount_null /var/tmp /tmp -fi +# We assume that /tmp is symlinked to /var/tmp on the shared root +# echo "+++ mount_null of /var/tmp" +# if [ ! -h /tmp -a ! -h /var/tmp ]; then +# mount_null /var/tmp /tmp +# fi # extract a list of device entries, then copy them to a writable partition (cd /; find -x dev | cpio -o -H newc) > /tmp/dev.tmp +echo "+++ mount_mfs of /dev" mount_mfs -s 4096 -i 512 -T qp120at dummy /dev (cd /; cpio -i -H newc -d < /tmp/dev.tmp) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 16 2: 3:22 2001 Delivered-To: freebsd-net@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-139.dsl.lsan03.pacbell.net [63.207.60.139]) by hub.freebsd.org (Postfix) with ESMTP id DC9B537B422; Mon, 16 Apr 2001 02:03:15 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id C6CB866D8B; Mon, 16 Apr 2001 02:03:11 -0700 (PDT) Date: Mon, 16 Apr 2001 02:03:11 -0700 From: Kris Kennaway To: Mike Silbersack Cc: Mark T Roberts , freebsd-security@FreeBSD.ORG, net@FreeBSD.org Subject: Re: non-random IP IDs Message-ID: <20010416020311.A1292@xor.obsecurity.org> References: <001f01c0c30b$805b0840$d2e2fdce@netrex.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="fdj2RfSjLxBAspz7" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from silby@silby.com on Thu, Apr 12, 2001 at 12:40:32AM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 12, 2001 at 12:40:32AM -0500, Mike Silbersack wrote: > Each IP packet sent has with it a 16-bit ID. The numbers must remain > unique over a short period of time so fragmentation can work properly. As > such, everything except recent openbsds simple increments the id by 1 for > each packet sent out. >=20 > As a result, you can tell the number of packets sent on an idle host by > seeing the difference in id numbers for the packets it sends back to you. > It's not really that important of an issue, don't worry about it. Here's a patch ported from OpenBSD which randomizes this (supposedly such that it respects the constraint of not wrapping within the prescribed time period). I should wrap it in a sysctl, I guess. http://www.freebsd.org/~kris/ipid.patch Comments? Kris --fdj2RfSjLxBAspz7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE62rVOWry0BWjoQKURAmEnAKCPsC4cKouTayuBqji58oWOUH22DACdF7A0 3Is0lLB0DmTyUzAHsY6q/rU= =WMzk -----END PGP SIGNATURE----- --fdj2RfSjLxBAspz7-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 16 2:48:10 2001 Delivered-To: freebsd-net@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-27.dsl.lsan03.pacbell.net [63.207.60.27]) by hub.freebsd.org (Postfix) with ESMTP id 09C2337B424; Mon, 16 Apr 2001 02:48:06 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 441C5678BE; Mon, 16 Apr 2001 02:48:05 -0700 (PDT) Date: Mon, 16 Apr 2001 02:48:05 -0700 From: Kris Kennaway To: Kris Kennaway Cc: Mike Silbersack , Mark T Roberts , freebsd-security@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: non-random IP IDs Message-ID: <20010416024805.A688@xor.obsecurity.org> References: <001f01c0c30b$805b0840$d2e2fdce@netrex.com> <20010416020311.A1292@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="rwEMma7ioTxnRzrJ" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010416020311.A1292@xor.obsecurity.org>; from kris@obsecurity.org on Mon, Apr 16, 2001 at 02:03:11AM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --rwEMma7ioTxnRzrJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 16, 2001 at 02:03:11AM -0700, Kris Kennaway wrote: > Here's a patch ported from OpenBSD which randomizes this (supposedly > such that it respects the constraint of not wrapping within the > prescribed time period). I should wrap it in a sysctl, I guess. >=20 > http://www.freebsd.org/~kris/ipid.patch Okay, I did this and updated the patch, with the sysctl defaulting to off since the random algorithm does add some amount of overhead. > Comments? Kris --rwEMma7ioTxnRzrJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE62r/UWry0BWjoQKURAqEhAKDMfAXAwJLg+qU1Wt9RVH9q6Oi+EACeKXRN EA9+LNS3If04gRZFQ9YTGis= =l1UB -----END PGP SIGNATURE----- --rwEMma7ioTxnRzrJ-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 16 7:37:31 2001 Delivered-To: freebsd-net@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 248BD37B43F; Mon, 16 Apr 2001 07:37:25 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from [127.0.0.1] (helo=softweyr.com ident=67b8f9b839749317407b58ec008f73e6) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14pA7d-0000Vq-00; Mon, 16 Apr 2001 08:36:58 -0600 Message-ID: <3ADB0389.5D236D88@softweyr.com> Date: Mon, 16 Apr 2001 08:36:57 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Kris Kennaway Cc: freebsd-security@FreeBSD.ORG, net@FreeBSD.org Subject: Re: non-random IP IDs References: <001f01c0c30b$805b0840$d2e2fdce@netrex.com> <20010416020311.A1292@xor.obsecurity.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Kris Kennaway wrote: > > On Thu, Apr 12, 2001 at 12:40:32AM -0500, Mike Silbersack wrote: > > > Each IP packet sent has with it a 16-bit ID. The numbers must remain > > unique over a short period of time so fragmentation can work properly. As > > such, everything except recent openbsds simple increments the id by 1 for > > each packet sent out. > > > > As a result, you can tell the number of packets sent on an idle host by > > seeing the difference in id numbers for the packets it sends back to you. > > It's not really that important of an issue, don't worry about it. > > Here's a patch ported from OpenBSD which randomizes this (supposedly > such that it respects the constraint of not wrapping within the > prescribed time period). I should wrap it in a sysctl, I guess. > > http://www.freebsd.org/~kris/ipid.patch > > Comments? Looks clean. The only comment I can find is: Why not have ip_randomid() return the ID in network byte order? It would save several HTONS macros trailing the ip_randomid() calls. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 16 11:31:21 2001 Delivered-To: freebsd-net@freebsd.org Received: from caligula.anu.edu.au (caligula.anu.edu.au [150.203.224.42]) by hub.freebsd.org (Postfix) with ESMTP id C887237B43F; Mon, 16 Apr 2001 11:31:14 -0700 (PDT) (envelope-from avalon@caligula.anu.edu.au) Received: (from avalon@localhost) by caligula.anu.edu.au (8.9.3/8.9.3) id EAA01848; Tue, 17 Apr 2001 04:30:40 +1000 (EST) From: Darren Reed Message-Id: <200104161830.EAA01848@caligula.anu.edu.au> Subject: Re: non-random IP IDs To: wes@softweyr.com (Wes Peters) Date: Tue, 17 Apr 2001 04:30:40 +1000 (Australia/ACT) Cc: kris@obsecurity.org (Kris Kennaway), freebsd-security@FreeBSD.ORG, net@FreeBSD.ORG In-Reply-To: <3ADB0389.5D236D88@softweyr.com> from "Wes Peters" at Apr 16, 2001 08:36:57 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In some mail from Wes Peters, sie said: > > Kris Kennaway wrote: > > > > On Thu, Apr 12, 2001 at 12:40:32AM -0500, Mike Silbersack wrote: > > > > > Each IP packet sent has with it a 16-bit ID. The numbers must remain > > > unique over a short period of time so fragmentation can work properly. As > > > such, everything except recent openbsds simple increments the id by 1 for > > > each packet sent out. > > > > > > As a result, you can tell the number of packets sent on an idle host by > > > seeing the difference in id numbers for the packets it sends back to you. > > > It's not really that important of an issue, don't worry about it. > > > > Here's a patch ported from OpenBSD which randomizes this (supposedly > > such that it respects the constraint of not wrapping within the > > prescribed time period). I should wrap it in a sysctl, I guess. > > > > http://www.freebsd.org/~kris/ipid.patch > > > > Comments? > > Looks clean. The only comment I can find is: Why not have ip_randomid() > return the ID in network byte order? It would save several HTONS macros > trailing the ip_randomid() calls. Why do it at all ? Why do you want to covert an opaque number from one byte format to the other? The only reason ip_id should be being converted *FROM* network byte order to host byte order is for display purposes. If you disagree with me, think for a moment about what it *really* is. Afterall, two random bytes are two random bytes, regardless of which is first. Darren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 16 11:36:55 2001 Delivered-To: freebsd-net@freebsd.org Received: from caligula.anu.edu.au (caligula.anu.edu.au [150.203.224.42]) by hub.freebsd.org (Postfix) with ESMTP id DD97837B43C; Mon, 16 Apr 2001 11:36:37 -0700 (PDT) (envelope-from avalon@caligula.anu.edu.au) Received: (from avalon@localhost) by caligula.anu.edu.au (8.9.3/8.9.3) id EAA03291; Tue, 17 Apr 2001 04:36:16 +1000 (EST) From: Darren Reed Message-Id: <200104161836.EAA03291@caligula.anu.edu.au> Subject: Re: non-random IP IDs To: kris@obsecurity.org (Kris Kennaway) Date: Tue, 17 Apr 2001 04:36:15 +1000 (Australia/ACT) Cc: kris@obsecurity.org (Kris Kennaway), silby@silby.com (Mike Silbersack), newsletter@marktroberts.com (Mark T Roberts), freebsd-security@FreeBSD.ORG, net@FreeBSD.ORG In-Reply-To: <20010416024805.A688@xor.obsecurity.org> from "Kris Kennaway" at Apr 16, 2001 02:48:05 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In some mail from Kris Kennaway, sie said: > > > --rwEMma7ioTxnRzrJ > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On Mon, Apr 16, 2001 at 02:03:11AM -0700, Kris Kennaway wrote: > > > Here's a patch ported from OpenBSD which randomizes this (supposedly > > such that it respects the constraint of not wrapping within the > > prescribed time period). I should wrap it in a sysctl, I guess. > >=20 > > http://www.freebsd.org/~kris/ipid.patch > > Okay, I did this and updated the patch, with the sysctl defaulting to > off since the random algorithm does add some amount of overhead. > > > Comments? You should optimize it for mod being 2^n-1 (or make that a requirement). Also, drop the HTONS statements, they no longer make sense. Before ip_id was a counter and so it made sense (sorta) to change its byte ordering to network. Now it's just a random number so there is no longer any need. Darren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 16 12: 6:35 2001 Delivered-To: freebsd-net@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-27.dsl.lsan03.pacbell.net [63.207.60.27]) by hub.freebsd.org (Postfix) with ESMTP id 9984A37B43F; Mon, 16 Apr 2001 12:06:30 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 3B228678B7; Mon, 16 Apr 2001 12:06:30 -0700 (PDT) Date: Mon, 16 Apr 2001 12:06:30 -0700 From: Kris Kennaway To: Darren Reed Cc: Kris Kennaway , Mike Silbersack , Mark T Roberts , freebsd-security@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: non-random IP IDs Message-ID: <20010416120630.C10023@xor.obsecurity.org> References: <20010416024805.A688@xor.obsecurity.org> <200104161836.EAA03291@caligula.anu.edu.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="TYecfFk8j8mZq+dy" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200104161836.EAA03291@caligula.anu.edu.au>; from avalon@coombs.anu.edu.au on Tue, Apr 17, 2001 at 04:36:15AM +1000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --TYecfFk8j8mZq+dy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Apr 17, 2001 at 04:36:15AM +1000, Darren Reed wrote: > You should optimize it for mod being 2^n-1 (or make that a requirement). I'm afraid I don't have time to look at this right now. Perhaps it can be revisited (the sysctl defaults to off for now), or Niels Provos may be interested in the idea. > Also, drop the HTONS statements, they no longer make sense. Before ip_id > was a counter and so it made sense (sorta) to change its byte ordering to > network. Now it's just a random number so there is no longer any need. Well, it still has wrapping properties like a network-order counter, i.e. the algorithm attempts to order the output so that it doesn't wrap within the segment lifetime. That would be lost without using HTONS. Kris --TYecfFk8j8mZq+dy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE620K1Wry0BWjoQKURAn72AJ9LgQ5HdeYEA09g3tA15l62W75dYwCg9pZd g3J2gozaTEXPWVstnZjh9ts= =LYF5 -----END PGP SIGNATURE----- --TYecfFk8j8mZq+dy-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 16 12:10:27 2001 Delivered-To: freebsd-net@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-27.dsl.lsan03.pacbell.net [63.207.60.27]) by hub.freebsd.org (Postfix) with ESMTP id BB9E737B42C; Mon, 16 Apr 2001 12:10:20 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id C7B1B66D8B; Mon, 16 Apr 2001 12:10:19 -0700 (PDT) Date: Mon, 16 Apr 2001 12:10:19 -0700 From: Kris Kennaway To: Wes Peters Cc: Kris Kennaway , freebsd-security@FreeBSD.ORG, net@FreeBSD.ORG, provos@OpenBSD.org Subject: Re: non-random IP IDs Message-ID: <20010416121019.D10023@xor.obsecurity.org> References: <001f01c0c30b$805b0840$d2e2fdce@netrex.com> <20010416020311.A1292@xor.obsecurity.org> <3ADB0389.5D236D88@softweyr.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="zbGR4y+acU1DwHSi" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3ADB0389.5D236D88@softweyr.com>; from wes@softweyr.com on Mon, Apr 16, 2001 at 08:36:57AM -0600 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --zbGR4y+acU1DwHSi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Apr 16, 2001 at 08:36:57AM -0600, Wes Peters wrote: > Looks clean. The only comment I can find is: Why not have ip_randomid() > return the ID in network byte order? It would save several HTONS macros > trailing the ip_randomid() calls. I can't think of anything off the top of my head, but there was some reason why OpenBSD made this change: diff -u -r1.12 -r1.13 --- ip_mroute.c 1999/01/08 01:04:17 1.12 +++ ip_mroute.c 1999/01/08 21:51:22 1.13 @@ -1397,7 +1397,8 @@ */ ip_copy = mtod(mb_copy, struct ip *); *ip_copy = multicast_encap_iphdr; - ip_copy->ip_id = htons(ip_randomid()); + ip_copy->ip_id = ip_randomid(); + HTONS(ip_copy->ip_id); ip_copy->ip_len = len; ip_copy->ip_src = vifp->v_lcl_addr; ip_copy->ip_dst = vifp->v_rmt_addr; Presumably there was some reasoning there. Niels, can you shed any light? Kris --zbGR4y+acU1DwHSi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE620ObWry0BWjoQKURAuUHAKCdHQSfWDRrszsnqghfWJ7GduljdwCgrCzh VXHsMlwwU2Z8rsVXQhbiVlo= =beZj -----END PGP SIGNATURE----- --zbGR4y+acU1DwHSi-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 16 12:27:34 2001 Delivered-To: freebsd-net@freebsd.org Received: from a.mx.everquick.net (a.mx.everquick.net [216.89.137.3]) by hub.freebsd.org (Postfix) with ESMTP id D75CD37B422; Mon, 16 Apr 2001 12:27:28 -0700 (PDT) (envelope-from eddy+public+spam@noc.everquick.net) Received: from localhost (eddy@localhost) by a.mx.everquick.net (8.10.2/8.10.2) with ESMTP id f3GJO8u26443; Mon, 16 Apr 2001 19:24:08 GMT X-EverQuick-No-Abuse: Report any e-mail abuse to Date: Mon, 16 Apr 2001 19:24:07 +0000 (GMT) From: "E.B. Dreger" To: Kris Kennaway Cc: Wes Peters , freebsd-security@FreeBSD.ORG, net@FreeBSD.ORG, provos@OpenBSD.org Subject: Re: non-random IP IDs In-Reply-To: <20010416121019.D10023@xor.obsecurity.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Date: Mon, 16 Apr 2001 12:10:19 -0700 > From: Kris Kennaway > > I can't think of anything off the top of my head, but there was some > reason why OpenBSD made this change: > > - ip_copy->ip_id = htons(ip_randomid()); > + ip_copy->ip_id = ip_randomid(); > + HTONS(ip_copy->ip_id); > > Presumably there was some reasoning there. Niels, can you shed any > light? Without having the source in front of me, what length of value does ip_randomid() return? htons(long) != htons(short) perhaps? Eddy --------------------------------------------------------------------------- Brotsman & Dreger, Inc. EverQuick Internet / EternalCommerce Division Phone: (316) 794-8922 --------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 16 12:45:15 2001 Delivered-To: freebsd-net@freebsd.org Received: from mx.databus.com (p101-44.acedsl.com [160.79.101.44]) by hub.freebsd.org (Postfix) with ESMTP id D10C837B43C; Mon, 16 Apr 2001 12:45:08 -0700 (PDT) (envelope-from barney@mx.databus.com) Received: (from barney@localhost) by mx.databus.com (8.11.3/8.11.3) id f3GJgoH49895; Mon, 16 Apr 2001 15:42:50 -0400 (EDT) (envelope-from barney) Date: Mon, 16 Apr 2001 15:42:49 -0400 From: Barney Wolff To: "E.B. Dreger" Cc: Kris Kennaway , Wes Peters , freebsd-security@FreeBSD.ORG, net@FreeBSD.ORG, provos@OpenBSD.org Subject: Re: non-random IP IDs Message-ID: <20010416154249.A49858@mx.databus.com> References: <20010416121019.D10023@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from eddy+public+spam@noc.everquick.net on Mon, Apr 16, 2001 at 07:24:07PM +0000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org If ip_randomid() is an asm rather than C code, I have sometimes seen problems with an asm func calling another asm func. That was long ago and far away, but is the only reason I can think of for that change. But whether the id is random or a counter, there is no reason to htons it, as long as it's treated consistently, with externals never compared with internals. Barney Wolff > > Date: Mon, 16 Apr 2001 12:10:19 -0700 > > From: Kris Kennaway > > > > I can't think of anything off the top of my head, but there was some > > reason why OpenBSD made this change: > > > > - ip_copy->ip_id = htons(ip_randomid()); > > + ip_copy->ip_id = ip_randomid(); > > + HTONS(ip_copy->ip_id); > > > > Presumably there was some reasoning there. Niels, can you shed any > > light? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 16 12:50:59 2001 Delivered-To: freebsd-net@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-27.dsl.lsan03.pacbell.net [63.207.60.27]) by hub.freebsd.org (Postfix) with ESMTP id 95F5C37B42C; Mon, 16 Apr 2001 12:50:53 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 2C6FC678BB; Mon, 16 Apr 2001 12:50:53 -0700 (PDT) Date: Mon, 16 Apr 2001 12:50:53 -0700 From: Kris Kennaway To: Barney Wolff Cc: "E.B. Dreger" , Kris Kennaway , Wes Peters , freebsd-security@FreeBSD.ORG, net@FreeBSD.ORG, provos@OpenBSD.org Subject: Re: non-random IP IDs Message-ID: <20010416125053.A11446@xor.obsecurity.org> References: <20010416121019.D10023@xor.obsecurity.org> <20010416154249.A49858@mx.databus.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="J2SCkAp4GZ/dPZZf" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010416154249.A49858@mx.databus.com>; from barney@databus.com on Mon, Apr 16, 2001 at 03:42:49PM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 16, 2001 at 03:42:49PM -0400, Barney Wolff wrote: > If ip_randomid() is an asm rather than C code, I have sometimes > seen problems with an asm func calling another asm func. That > was long ago and far away, but is the only reason I can think of > for that change. >=20 > But whether the id is random or a counter, there is no reason to > htons it, as long as it's treated consistently, with externals > never compared with internals. Surely that can't work since the purpose of that field is for received packet ordering (unless I'm wrong, I'm not an IPv4 guru and only skimmed the RFC), and what's ordered in network order isn't ordered in host order. Kris --J2SCkAp4GZ/dPZZf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6200cWry0BWjoQKURAtq2AJ0X7Nt1XcCFlr9OOcWdfNtY843/kQCdEfDR 8PfVfL5oMqwnxDN9VD0TJGk= =9ZPJ -----END PGP SIGNATURE----- --J2SCkAp4GZ/dPZZf-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 16 12:59:48 2001 Delivered-To: freebsd-net@freebsd.org Received: from caligula.anu.edu.au (caligula.anu.edu.au [150.203.224.42]) by hub.freebsd.org (Postfix) with ESMTP id 1117E37B423; Mon, 16 Apr 2001 12:59:43 -0700 (PDT) (envelope-from avalon@caligula.anu.edu.au) Received: (from avalon@localhost) by caligula.anu.edu.au (8.9.3/8.9.3) id FAA08797; Tue, 17 Apr 2001 05:58:22 +1000 (EST) From: Darren Reed Message-Id: <200104161958.FAA08797@caligula.anu.edu.au> Subject: Re: non-random IP IDs To: kris@obsecurity.org (Kris Kennaway) Date: Tue, 17 Apr 2001 05:58:22 +1000 (Australia/ACT) Cc: barney@databus.com (Barney Wolff), eddy+public+spam@noc.everquick.net (E.B. Dreger), kris@obsecurity.org (Kris Kennaway), wes@softweyr.com (Wes Peters), freebsd-security@FreeBSD.ORG, net@FreeBSD.ORG, provos@OpenBSD.org In-Reply-To: <20010416125053.A11446@xor.obsecurity.org> from "Kris Kennaway" at Apr 16, 2001 12:50:53 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In some mail from Kris Kennaway, sie said: > > Surely that can't work since the purpose of that field is for received > packet ordering (unless I'm wrong, I'm not an IPv4 guru and only > skimmed the RFC), and what's ordered in network order isn't ordered in > host order. It is not used by the receiver for packet ordering, only for collection of fragments (of a larger packet). Darren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 16 13: 1:47 2001 Delivered-To: freebsd-net@freebsd.org Received: from mx.databus.com (p101-44.acedsl.com [160.79.101.44]) by hub.freebsd.org (Postfix) with ESMTP id 8E3E437B43C; Mon, 16 Apr 2001 13:01:41 -0700 (PDT) (envelope-from barney@mx.databus.com) Received: (from barney@localhost) by mx.databus.com (8.11.3/8.11.3) id f3GK1XY49993; Mon, 16 Apr 2001 16:01:33 -0400 (EDT) (envelope-from barney) Date: Mon, 16 Apr 2001 16:01:32 -0400 From: Barney Wolff To: Kris Kennaway Cc: Barney Wolff , "E.B. Dreger" , Wes Peters , freebsd-security@FreeBSD.ORG, net@FreeBSD.ORG, provos@OpenBSD.org Subject: Re: non-random IP IDs Message-ID: <20010416160132.A49963@mx.databus.com> References: <20010416121019.D10023@xor.obsecurity.org> <20010416154249.A49858@mx.databus.com> <20010416125053.A11446@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20010416125053.A11446@xor.obsecurity.org>; from kris@obsecurity.org on Mon, Apr 16, 2001 at 12:50:53PM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org No - the ip_id is used only to collect the fragments of a single packet - so all that counts is that each fragment has the same value, and that the value not collide with that in other packets/fragments that can be in flight at the same time. (I think you're confusing ip_id with the TCP sequence number.) Barney On Mon, Apr 16, 2001 at 12:50:53PM -0700, Kris Kennaway wrote: > On Mon, Apr 16, 2001 at 03:42:49PM -0400, Barney Wolff wrote: > > If ip_randomid() is an asm rather than C code, I have sometimes > > seen problems with an asm func calling another asm func. That > > was long ago and far away, but is the only reason I can think of > > for that change. > > > > But whether the id is random or a counter, there is no reason to > > htons it, as long as it's treated consistently, with externals > > never compared with internals. > > Surely that can't work since the purpose of that field is for received > packet ordering (unless I'm wrong, I'm not an IPv4 guru and only > skimmed the RFC), and what's ordered in network order isn't ordered in > host order. > > Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 16 13: 3: 7 2001 Delivered-To: freebsd-net@freebsd.org Received: from caligula.anu.edu.au (caligula.anu.edu.au [150.203.224.42]) by hub.freebsd.org (Postfix) with ESMTP id 1DC4037B42C; Mon, 16 Apr 2001 13:02:59 -0700 (PDT) (envelope-from avalon@caligula.anu.edu.au) Received: (from avalon@localhost) by caligula.anu.edu.au (8.9.3/8.9.3) id GAA09062; Tue, 17 Apr 2001 06:02:42 +1000 (EST) From: Darren Reed Message-Id: <200104162002.GAA09062@caligula.anu.edu.au> Subject: Re: non-random IP IDs To: kris@obsecurity.org (Kris Kennaway) Date: Tue, 17 Apr 2001 06:02:42 +1000 (Australia/ACT) Cc: avalon@coombs.anu.edu.au (Darren Reed), kris@obsecurity.org (Kris Kennaway), silby@silby.com (Mike Silbersack), newsletter@marktroberts.com (Mark T Roberts), freebsd-security@FreeBSD.ORG, net@FreeBSD.ORG In-Reply-To: <20010416120630.C10023@xor.obsecurity.org> from "Kris Kennaway" at Apr 16, 2001 12:06:30 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In some mail from Kris Kennaway, sie said: > > > --TYecfFk8j8mZq+dy > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > > On Tue, Apr 17, 2001 at 04:36:15AM +1000, Darren Reed wrote: > > > You should optimize it for mod being 2^n-1 (or make that a requirement). > > I'm afraid I don't have time to look at this right now. Perhaps it > can be revisited (the sysctl defaults to off for now), or Niels Provos > may be interested in the idea. Basically it means '% mod' -> '& mod' and call it with a 2^n-1 number. > > Also, drop the HTONS statements, they no longer make sense. Before ip_id > > was a counter and so it made sense (sorta) to change its byte ordering to > > network. Now it's just a random number so there is no longer any need. > > Well, it still has wrapping properties like a network-order counter, > i.e. the algorithm attempts to order the output so that it doesn't > wrap within the segment lifetime. That would be lost without using > HTONS. You're confusing properties of the local number and some opaque bits in a packet being sent over the 'net. Darren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 16 13: 4:35 2001 Delivered-To: freebsd-net@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-27.dsl.lsan03.pacbell.net [63.207.60.27]) by hub.freebsd.org (Postfix) with ESMTP id A1E1537B423; Mon, 16 Apr 2001 13:04:29 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id CE7DE678B8; Mon, 16 Apr 2001 13:04:28 -0700 (PDT) Date: Mon, 16 Apr 2001 13:04:28 -0700 From: Kris Kennaway To: Darren Reed Cc: Kris Kennaway , Barney Wolff , "E.B. Dreger" , Wes Peters , freebsd-security@FreeBSD.ORG, net@FreeBSD.ORG, provos@OpenBSD.org Subject: Re: non-random IP IDs Message-ID: <20010416130428.A11906@xor.obsecurity.org> References: <20010416125053.A11446@xor.obsecurity.org> <200104161958.FAA08797@caligula.anu.edu.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="82I3+IH0IqGh5yIs" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200104161958.FAA08797@caligula.anu.edu.au>; from avalon@coombs.anu.edu.au on Tue, Apr 17, 2001 at 05:58:22AM +1000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 17, 2001 at 05:58:22AM +1000, Darren Reed wrote: > In some mail from Kris Kennaway, sie said: > >=20 > > Surely that can't work since the purpose of that field is for received > > packet ordering (unless I'm wrong, I'm not an IPv4 guru and only > > skimmed the RFC), and what's ordered in network order isn't ordered in > > host order. >=20 > It is not used by the receiver for packet ordering, only for collection > of fragments (of a larger packet). Okay, I'll have to read the RFC again more closely. Kris --82I3+IH0IqGh5yIs Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE621BMWry0BWjoQKURAuD0AJ9HRjVa5c1gEl3KV6omdVeq/GA4EgCgwYG3 kqvhG2YMHV7SFoAmq8OdRaU= =QjdL -----END PGP SIGNATURE----- --82I3+IH0IqGh5yIs-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 16 13: 8:22 2001 Delivered-To: freebsd-net@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-27.dsl.lsan03.pacbell.net [63.207.60.27]) by hub.freebsd.org (Postfix) with ESMTP id 6F73837B422; Mon, 16 Apr 2001 13:08:15 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 0CFD5678B8; Mon, 16 Apr 2001 13:08:15 -0700 (PDT) Date: Mon, 16 Apr 2001 13:08:14 -0700 From: Kris Kennaway To: Darren Reed Cc: Kris Kennaway , Mike Silbersack , Mark T Roberts , freebsd-security@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: non-random IP IDs Message-ID: <20010416130814.A12057@xor.obsecurity.org> References: <20010416120630.C10023@xor.obsecurity.org> <200104162002.GAA09062@caligula.anu.edu.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="M9NhX3UHpAaciwkO" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200104162002.GAA09062@caligula.anu.edu.au>; from avalon@coombs.anu.edu.au on Tue, Apr 17, 2001 at 06:02:42AM +1000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --M9NhX3UHpAaciwkO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 17, 2001 at 06:02:42AM +1000, Darren Reed wrote: > > > You should optimize it for mod being 2^n-1 (or make that a requiremen= t). > >=20 > > I'm afraid I don't have time to look at this right now. Perhaps it > > can be revisited (the sysctl defaults to off for now), or Niels Provos > > may be interested in the idea. >=20 > Basically it means '% mod' -> '& mod' and call it with a 2^n-1 number. Oh, okay. > > Well, it still has wrapping properties like a network-order counter, > > i.e. the algorithm attempts to order the output so that it doesn't > > wrap within the segment lifetime. That would be lost without using > > HTONS. >=20 > You're confusing properties of the local number and some opaque bits in > a packet being sent over the 'net. Quite likely. Kris --M9NhX3UHpAaciwkO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE621EuWry0BWjoQKURApyyAKCBB7Zt5a4iTdLd/p5UfsjwffMpBwCfScng oR2Ef5UAJZl7DV94q312HM0= =hVp+ -----END PGP SIGNATURE----- --M9NhX3UHpAaciwkO-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 16 13:15:59 2001 Delivered-To: freebsd-net@freebsd.org Received: from nsmail.corp.globalstar.com (gibraltar.globalstar.com [207.88.248.142]) by hub.freebsd.org (Postfix) with ESMTP id 5A80037B440; Mon, 16 Apr 2001 13:15:51 -0700 (PDT) (envelope-from crist.clark@globalstar.com) Received: from globalstar.com ([207.88.153.184]) by nsmail.corp.globalstar.com (Netscape Messaging Server 4.15) with ESMTP id GBWIXO00.C5J; Mon, 16 Apr 2001 13:15:24 -0700 Message-ID: <3ADB52F4.1A7058B9@globalstar.com> Date: Mon, 16 Apr 2001 13:15:48 -0700 From: "Crist Clark" Organization: Globalstar LP X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Kris Kennaway Cc: Barney Wolff , "E.B. Dreger" , Wes Peters , freebsd-security@FreeBSD.ORG, net@FreeBSD.ORG, provos@OpenBSD.org Subject: Re: non-random IP IDs References: <20010416121019.D10023@xor.obsecurity.org> <20010416154249.A49858@mx.databus.com> <20010416125053.A11446@xor.obsecurity.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Kris Kennaway wrote: > > On Mon, Apr 16, 2001 at 03:42:49PM -0400, Barney Wolff wrote: > > If ip_randomid() is an asm rather than C code, I have sometimes > > seen problems with an asm func calling another asm func. That > > was long ago and far away, but is the only reason I can think of > > for that change. > > > > But whether the id is random or a counter, there is no reason to > > htons it, as long as it's treated consistently, with externals > > never compared with internals. > > Surely that can't work since the purpose of that field is for received > packet ordering (unless I'm wrong, I'm not an IPv4 guru and only > skimmed the RFC), and what's ordered in network order isn't ordered in > host order. The IP ID and the Fragment Offset are different fields within the IPv4 header. At least that's what I think you are saying. As far as the whole thread goes, no, I cannot visualize a situation where the IP ID would need to be htons()'ed. The machine generating a datagram creates a "unique" IP ID for each outgoing datagram (actually the IP ID only needs to be unique for each source host, destination host, and protocol). No routers in between ever change it; the receiving machine just uses it to figure out what fragmented datagrams go together to assemble the original datagram. The only question that arises is a non-htons'ed field any less "unique" than the htons'ed one. People have mentioned that we might have a problem with wrap-around. However, preventing wrap around from happening too quickly is just a simple minded way to ensure pseudo-uniqueness of IDs. There are no requirements about wrap around in and of itself. Even if you do use an algorithm that wraps the in-kernel value slowly to prevent wrap around, the IDs on the wire in the reversed byte-order will be just as unique because if it. -- Crist J. Clark Network Security Engineer crist.clark@globalstar.com Globalstar, L.P. (408) 933-4387 FAX: (408) 933-4926 The information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact postmaster@globalstar.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 16 14:46:15 2001 Delivered-To: freebsd-net@freebsd.org Received: from citi.umich.edu (citi.umich.edu [141.211.92.141]) by hub.freebsd.org (Postfix) with ESMTP id 5D6A137B446; Mon, 16 Apr 2001 14:46:12 -0700 (PDT) (envelope-from provos@citi.umich.edu) Received: from citi.umich.edu (ssh-mapper.citi.umich.edu [141.211.92.147]) by citi.umich.edu (Postfix) with ESMTP id 6DA3F207C1; Mon, 16 Apr 2001 17:46:11 -0400 (EDT) Subject: Re: non-random IP IDs From: Niels Provos In-Reply-To: Kris Kennaway, Mon, 16 Apr 2001 12:10:19 PDT To: Kris Kennaway Cc: Wes Peters , freebsd-security@FreeBSD.ORG, net@FreeBSD.ORG, provos@OpenBSD.org Date: Mon, 16 Apr 2001 17:46:11 -0400 Message-Id: <20010416214611.6DA3F207C1@citi.umich.edu> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <20010416121019.D10023@xor.obsecurity.org>, Kris Kennaway writes: >Presumably there was some reasoning there. Niels, can you shed any >light? No reasoning. You do not need the htons(). The fragment ids just need to be unique. An htons() does not change that property. I dont like that code very much. A variable-block-size cipher in counter mode would do the job better. However, what many ppl do not realize is that you can use predictable ip ids to anonymously port scan machines. Bugtraq talks about how to do that. Niels. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 16 18:29:18 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 1BBE937B446; Mon, 16 Apr 2001 18:29:15 -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 VAA02080; Mon, 16 Apr 2001 21:28:55 -0400 (EDT) (envelope-from wollman) Date: Mon, 16 Apr 2001 21:28:55 -0400 (EDT) From: Garrett Wollman Message-Id: <200104170128.VAA02080@khavrinen.lcs.mit.edu> To: Kris Kennaway Cc: freebsd-security@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: non-random IP IDs In-Reply-To: <20010416125053.A11446@xor.obsecurity.org> References: <20010416121019.D10023@xor.obsecurity.org> <20010416154249.A49858@mx.databus.com> <20010416125053.A11446@xor.obsecurity.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > Surely that can't work since the purpose of that field is for received > packet ordering No. The IP ID is effectively a nonce with respect to the receiving system. The only requirement is that IDs not be repeated while any packet with the same (source, dest) pair is still in the network. This is in practice impossible, so as with TCP we can simply pretend that all packets disappear after 60 seconds. Having said that, on the whole I think this whole idea is utterly pointless. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 16 18:57:26 2001 Delivered-To: freebsd-net@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 9833137B43E; Mon, 16 Apr 2001 18:57:22 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.11.2) id f3H1v4d87804; Mon, 16 Apr 2001 18:57:04 -0700 (PDT) (envelope-from dillon) Date: Mon, 16 Apr 2001 18:57:04 -0700 (PDT) From: Matt Dillon Message-Id: <200104170157.f3H1v4d87804@earth.backplane.com> To: Niels Provos Cc: Kris Kennaway , Wes Peters , freebsd-security@FreeBSD.ORG, net@FreeBSD.ORG, provos@OpenBSD.org Subject: Re: non-random IP IDs References: <20010416214611.6DA3F207C1@citi.umich.edu> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :No reasoning. You do not need the htons(). The fragment ids just :need to be unique. An htons() does not change that property. I dont :like that code very much. A variable-block-size cipher in counter :mode would do the job better. : :However, what many ppl do not realize is that you can use predictable :ip ids to anonymously port scan machines. Bugtraq talks about how to :do that. : :Niels. It's not worth doing. We would be introducing unnecessary cpu burn on every single packet we sent out, all to solve a problem that doesn't really exist. Most people doing port scans don't care whether they are anonymous or not, anyway. They just do the scans. Also, port scanning software has gotten a whole lot more sophisticated these days... usually people want to portscan a whole bunch (thousands) of machines all at once, but to prevent detection the newer programs randomize the port and host being tested on a per-packet basis so any given 'victim' doesn't actually see all that much traffic. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 16 20:33: 0 2001 Delivered-To: freebsd-net@freebsd.org Received: from filk.iinet.net.au (syncopation-dns.iinet.net.au [203.59.24.29]) by hub.freebsd.org (Postfix) with SMTP id 23C0D37B505 for ; Mon, 16 Apr 2001 20:32:54 -0700 (PDT) (envelope-from julian@elischer.org) Received: (qmail 26709 invoked by uid 666); 17 Apr 2001 03:35:35 -0000 Received: from i186-154.nv.iinet.net.au (HELO elischer.org) (203.59.186.154) by mail.m.iinet.net.au with SMTP; 17 Apr 2001 03:35:35 -0000 Message-ID: <3ADBB93B.3C9DC3DE@elischer.org> Date: Mon, 16 Apr 2001 20:32:11 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Darren Reed Cc: Kris Kennaway , Mike Silbersack , Mark T Roberts , freebsd-security@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: non-random IP IDs References: <200104161836.EAA03291@caligula.anu.edu.au> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Darren Reed wrote: > > In some mail from Kris Kennaway, sie said: > > > > > > --rwEMma7ioTxnRzrJ > > Content-Type: text/plain; charset=us-ascii > > Content-Disposition: inline > > Content-Transfer-Encoding: quoted-printable > > > > On Mon, Apr 16, 2001 at 02:03:11AM -0700, Kris Kennaway wrote: > > > > > Here's a patch ported from OpenBSD which randomizes this (supposedly > > > such that it respects the constraint of not wrapping within the > > > prescribed time period). I should wrap it in a sysctl, I guess. > > >=20 > > > http://www.freebsd.org/~kris/ipid.patch > > > > Okay, I did this and updated the patch, with the sysctl defaulting to > > off since the random algorithm does add some amount of overhead. > > > > > Comments? > > You should optimize it for mod being 2^n-1 (or make that a requirement). > > Also, drop the HTONS statements, they no longer make sense. Before ip_id > was a counter and so it made sense (sorta) to change its byte ordering to > network. Now it's just a random number so there is no longer any need. there is a site that calculates server uptime from these numbers. All the leading machines are freeBSD. When you do this it will no-longer be able to track us :-( what is the problem in having these numbers sequential? > > Darren > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 16 20:38:55 2001 Delivered-To: freebsd-net@freebsd.org Received: from silby.com (adam042-060.resnet.wisc.edu [146.151.42.60]) by hub.freebsd.org (Postfix) with ESMTP id 9EF1E37B43C for ; Mon, 16 Apr 2001 20:38:53 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 16693 invoked by uid 1000); 17 Apr 2001 03:38:52 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 17 Apr 2001 03:38:52 -0000 Date: Mon, 16 Apr 2001 22:38:52 -0500 (CDT) From: Mike Silbersack To: Julian Elischer Cc: Darren Reed , Kris Kennaway , Mark T Roberts , , Subject: Re: non-random IP IDs In-Reply-To: <3ADBB93B.3C9DC3DE@elischer.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 16 Apr 2001, Julian Elischer wrote: > there is a site that calculates server uptime from these numbers. > All the leading machines are freeBSD. When you do this it will > no-longer be able to track us :-( They're using TCP timestamps to do that, not ip ids. And if I get my way, those will be unuseable for uptime detection soon enough... :) > what is the problem in having these numbers sequential? Anonymous port scans, some firewall probing as mentioned by darren, and the ability to see the idleness of a host. Not enough to make randomization the default policy, but certainly enough to justify a sysctl. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 16 20:45:48 2001 Delivered-To: freebsd-net@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-27.dsl.lsan03.pacbell.net [63.207.60.27]) by hub.freebsd.org (Postfix) with ESMTP id B6B8E37B446; Mon, 16 Apr 2001 20:45:43 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id EAB9066D8B; Mon, 16 Apr 2001 20:45:42 -0700 (PDT) Date: Mon, 16 Apr 2001 20:45:42 -0700 From: Kris Kennaway To: Julian Elischer Cc: freebsd-security@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: non-random IP IDs Message-ID: <20010416204542.A18881@xor.obsecurity.org> References: <200104161836.EAA03291@caligula.anu.edu.au> <3ADBB93B.3C9DC3DE@elischer.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="azLHFNyN32YCQGCU" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3ADBB93B.3C9DC3DE@elischer.org>; from julian@elischer.org on Mon, Apr 16, 2001 at 08:32:11PM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 16, 2001 at 08:32:11PM -0700, Julian Elischer wrote: > there is a site that calculates server uptime from these numbers. > All the leading machines are freeBSD. When you do this it will=20 > no-longer be able to track us :-( As explained by Mike, the uptime fingerprinting doesn't involve IP IDs, but regardless, information leaks of this kind make it easier to exploit various network stack vulnerabilities. Knowing things like whether a host is idle, being able to measure the rate at which it is generating traffic (without observing the traffic directly), knowing its precise uptime, etc may allow you to mount various attacks (e.g. some of the IP stack vulnerabilties discovered in the past rely on knowing or being able to accurately guess this information). Not everyone may care to reduce this information exposure (e.g. it can add processing overhead which you may not want on a heavily-loaded server), but it should at least be made possible. Kris --azLHFNyN32YCQGCU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE627xmWry0BWjoQKURAjLXAJ9IwWqtk/3MGSwR8tIu1uQy1moJOgCdEinz o4lmxnIM7DyqMkiLWIzXmjM= =R5nQ -----END PGP SIGNATURE----- --azLHFNyN32YCQGCU-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 16 20:51:45 2001 Delivered-To: freebsd-net@freebsd.org Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by hub.freebsd.org (Postfix) with ESMTP id 453C537B422 for ; Mon, 16 Apr 2001 20:51:43 -0700 (PDT) (envelope-from mike@sentex.net) Received: from chimp.simianscience.com (cage.simianscience.com [64.7.134.1]) by smtp2.sentex.ca (8.11.1/8.11.1) with SMTP id f3H3pc899824; Mon, 16 Apr 2001 23:51:39 -0400 (EDT) (envelope-from mike@sentex.net) From: Mike Tancsa To: dms@wplus.net (Dmitry Samersoff) Cc: freebsd-net@freebsd.org Subject: Re: fxp+bridge: highly suspect syndrom. Date: Mon, 16 Apr 2001 23:51:38 -0400 Message-ID: References: <200104151507.f3FF7iC97018@luxren2.boostworks.com> In-Reply-To: X-Mailer: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 16 Apr 2001 02:05:45 -0400, in sentex.lists.freebsd.net you wrote: >=20 > What is Jonathan Lemon's driver and where I can get it? http://www.flugsvamp.com/~jlemon/fbsd/drivers/Intel_EtherExpress/ ---Mike Mike Tancsa (mdtancsa@sentex.net) =09 Sentex Communications Corp, =09 Waterloo, Ontario, Canada "Given enough time, 100 monkeys on 100 routers=20 could setup a national IP network." (KDW2) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 16 23:30:49 2001 Delivered-To: freebsd-net@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-27.dsl.lsan03.pacbell.net [63.207.60.27]) by hub.freebsd.org (Postfix) with ESMTP id 8608637B42C; Mon, 16 Apr 2001 23:30:43 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 0CE8F66D8B; Mon, 16 Apr 2001 23:30:43 -0700 (PDT) Date: Mon, 16 Apr 2001 23:30:42 -0700 From: Kris Kennaway To: Matt Dillon Cc: Niels Provos , Kris Kennaway , Wes Peters , freebsd-security@FreeBSD.ORG, net@FreeBSD.ORG, provos@OpenBSD.org Subject: Re: non-random IP IDs Message-ID: <20010416233042.A21394@xor.obsecurity.org> References: <20010416214611.6DA3F207C1@citi.umich.edu> <200104170157.f3H1v4d87804@earth.backplane.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="LQksG6bCIzRHxTLp" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200104170157.f3H1v4d87804@earth.backplane.com>; from dillon@earth.backplane.com on Mon, Apr 16, 2001 at 06:57:04PM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --LQksG6bCIzRHxTLp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 16, 2001 at 06:57:04PM -0700, Matt Dillon wrote: >=20 > :No reasoning. You do not need the htons(). The fragment ids just > :need to be unique. An htons() does not change that property. I dont > :like that code very much. A variable-block-size cipher in counter > :mode would do the job better. > : > :However, what many ppl do not realize is that you can use predictable > :ip ids to anonymously port scan machines. Bugtraq talks about how to > :do that. > : > :Niels. >=20 > It's not worth doing. We would be introducing unnecessary cpu burn on > every single packet we sent out, all to solve a problem that doesn't > really exist. Well, that's why it's a sysctl defaulting to off in my patch. Don't turn it on if you don't want to. Kris --LQksG6bCIzRHxTLp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE62+MSWry0BWjoQKURAgE9AJ96+j/E1Qs1Z1zMQq98Ig3S2lXjcwCg6V9k sRXiXBxL0MznuvHiSe7j/vk= =rx/L -----END PGP SIGNATURE----- --LQksG6bCIzRHxTLp-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 17 4:29: 1 2001 Delivered-To: freebsd-net@freebsd.org Received: from caligula.anu.edu.au (caligula.anu.edu.au [150.203.224.42]) by hub.freebsd.org (Postfix) with ESMTP id 6D10837B43E; Tue, 17 Apr 2001 04:28:51 -0700 (PDT) (envelope-from avalon@caligula.anu.edu.au) Received: (from avalon@localhost) by caligula.anu.edu.au (8.9.3/8.9.3) id VAA08430; Tue, 17 Apr 2001 21:28:25 +1000 (EST) From: Darren Reed Message-Id: <200104171128.VAA08430@caligula.anu.edu.au> Subject: Re: non-random IP IDs To: julian@elischer.org (Julian Elischer) Date: Tue, 17 Apr 2001 21:28:25 +1000 (Australia/ACT) Cc: avalon@coombs.anu.edu.au (Darren Reed), kris@obsecurity.org (Kris Kennaway), silby@silby.com (Mike Silbersack), newsletter@marktroberts.com (Mark T Roberts), freebsd-security@FreeBSD.ORG, net@FreeBSD.ORG In-Reply-To: <3ADBB93B.3C9DC3DE@elischer.org> from "Julian Elischer" at Apr 16, 2001 08:32:11 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In some mail from Julian Elischer, sie said: > > Darren Reed wrote: > > > > In some mail from Kris Kennaway, sie said: > > > > > > > > > --rwEMma7ioTxnRzrJ > > > Content-Type: text/plain; charset=us-ascii > > > Content-Disposition: inline > > > Content-Transfer-Encoding: quoted-printable > > > > > > On Mon, Apr 16, 2001 at 02:03:11AM -0700, Kris Kennaway wrote: > > > > > > > Here's a patch ported from OpenBSD which randomizes this (supposedly > > > > such that it respects the constraint of not wrapping within the > > > > prescribed time period). I should wrap it in a sysctl, I guess. > > > >=20 > > > > http://www.freebsd.org/~kris/ipid.patch > > > > > > Okay, I did this and updated the patch, with the sysctl defaulting to > > > off since the random algorithm does add some amount of overhead. > > > > > > > Comments? > > > > You should optimize it for mod being 2^n-1 (or make that a requirement). > > > > Also, drop the HTONS statements, they no longer make sense. Before ip_id > > was a counter and so it made sense (sorta) to change its byte ordering to > > network. Now it's just a random number so there is no longer any need. > > there is a site that calculates server uptime from these numbers. > All the leading machines are freeBSD. When you do this it will > no-longer be able to track us :-( IMHO, extraordinarily large uptimes are nothing to be proud of and say nothing about the quality of software. I'd almost go so far as to say uptimes greater than 1 year indicate that the system administration practises need review. Darren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 17 4:31:40 2001 Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 62E9F37B422; Tue, 17 Apr 2001 04:31:36 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f3HBVUK09190; Tue, 17 Apr 2001 04:31:30 -0700 (PDT) Date: Tue, 17 Apr 2001 04:31:30 -0700 From: Alfred Perlstein To: Darren Reed Cc: Julian Elischer , freebsd-security@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: non-random IP IDs Message-ID: <20010417043130.F976@fw.wintelcom.net> References: <3ADBB93B.3C9DC3DE@elischer.org> <200104171128.VAA08430@caligula.anu.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200104171128.VAA08430@caligula.anu.edu.au>; from avalon@coombs.anu.edu.au on Tue, Apr 17, 2001 at 09:28:25PM +1000 X-all-your-base: are belong to us. Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Darren Reed [010417 04:29] wrote: > In some mail from Julian Elischer, sie said: > > > > there is a site that calculates server uptime from these numbers. > > All the leading machines are freeBSD. When you do this it will > > no-longer be able to track us :-( > > IMHO, extraordinarily large uptimes are nothing to be proud of and > say nothing about the quality of software. > > I'd almost go so far as to say uptimes greater than 1 year indicate > that the system administration practises need review. Agreed. I've yet to hear about any seriously deployed system go without security advisories for over a year. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] Represent yourself, show up at BABUG http://www.babug.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 17 4:56:59 2001 Delivered-To: freebsd-net@freebsd.org Received: from ausmtp01.au.ibm.com (ausmtp01.au.ibm.COM [202.135.136.97]) by hub.freebsd.org (Postfix) with ESMTP id D0A5A37B43C for ; Tue, 17 Apr 2001 04:56:55 -0700 (PDT) (envelope-from skodati@in.ibm.com) Received: from f03n05e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 1.0) with ESMTP id VAA265290 for ; Tue, 17 Apr 2001 21:44:09 +1000 From: skodati@in.ibm.com Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n05e.au.ibm.com (8.8.8m3/NCO v4.96) with SMTP id VAA19970 for ; Tue, 17 Apr 2001 21:56:52 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA256A31.00419988 ; Tue, 17 Apr 2001 21:56:31 +1000 X-Lotus-FromDomain: IBMIN@IBMAU To: freebsd-net@FreeBSD.ORG Message-ID: Date: Tue, 17 Apr 2001 16:05:04 +0530 Subject: IPv6 : interface configuration Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi I have configured my system for IPv6, and the system is getting autoconfigured properly. (ifconfig shows both IPv4 and v6 addresses). I want to read the information about interfaces being configured with IPv6 address. I opened a socket for ip domain and reading the information into "ifconf" through "ioctl" with SIOCGIFCONF flag. And then reading all the addresses thru ifreq. But iam not able to find any interaces with address famly AF_INET6. I would like to know what iam missing thanks and regards Suresh Kodati To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 17 7: 4:52 2001 Delivered-To: freebsd-net@freebsd.org Received: from black.purplecat.net (ns1.purplecat.net [209.16.228.148]) by hub.freebsd.org (Postfix) with ESMTP id 7E92D37B422 for ; Tue, 17 Apr 2001 07:04:44 -0700 (PDT) (envelope-from peter@black.purplecat.net) Received: from localhost (peter@localhost) by black.purplecat.net (8.8.8/8.8.8) with ESMTP id KAA24222 for ; Tue, 17 Apr 2001 10:07:08 -0400 (EDT) (envelope-from peter@black.purplecat.net) Date: Tue, 17 Apr 2001 10:07:08 -0400 (EDT) From: Peter Brezny To: freebsd-net@freebsd.org Subject: three nics, two networks, simple routing problem... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The excerpt from my rc.conf mostly illustrates what I'm trying to do. I want to connect a host (10.30.1.15) to xl1 So that I can partition it's traffic from that of the lan connected to xl2. 10.30.1.1 GW----xl0 10.30.1.30 FW xl2----10.20.30.1 LAN | xl1 | | 10.30.1.15 FW ----- 10.20.15.1 LAN However, with my current conf files, I can't even ping xl1 from the box it's in. I can manually add a route, but I still can't ping the interface itself. What have I missed? TIA Peter Brezny SysAdmin Services Inc. my rc.conf looks like this. ifconfig_xl0="inet 10.30.1.30 netmask 255.255.255.0" ifconfig_xl1="inet 10.30.1.31 netmask 255.255.255.0" ifconfig_xl2="inet 10.20.30.1 netmask 255.255.255.0" xl1 is the iface giving problems. when you look at just the output of a ifconfig, things look ok. xl0: flags=8843 mtu 1500 inet 10.30.1.30 netmask 0xffffff00 broadcast 10.30.1.255 inet6 fe80::201:2ff:feed:4275%xl0 prefixlen 64 scopeid 0x1 ether 00:01:02:ed:42:75 media: autoselect (100baseTX ) status: active supported media: autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP 100baseTX xl1: flags=8843 mtu 1500 inet 10.30.1.31 netmask 0xffffff00 broadcast 10.30.1.255 inet6 fe80::201:2ff:feed:4225%xl1 prefixlen 64 scopeid 0x2 ether 00:01:02:ed:42:25 media: autoselect (10baseT/UTP) status: active supported media: autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP 100baseTX xl2: flags=8843 mtu 1500 inet 10.20.30.1 netmask 0xffffff00 broadcast 10.20.30.255 inet6 fe80::210:4bff:fe98:52cd%xl2 prefixlen 64 scopeid 0x3 ether 00:10:4b:98:52:cd media: autoselect (none) status: no carrier supported media: autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP 100baseTX However, netstat -r just gives this. Internet: Destination Gateway Flags Refs Use Netif Expire default 10.30.1.1 UGSc 1 7 xl0 10.20.30/24 link#3 UC 0 0 xl2 => 10.30.1/24 link#1 UC 0 0 xl0 => localhost localhost UH 1 106 lo0 Obviously the problem here is that the 10.30.1/24 network is routing through xl0, when I want to route just part of that network through xl1. Since the only machine that's going to be connected to xl1 has an address of 10.30.1.15, I tried adding a static route to it, without luck. First just with route add 10.30.1.15 10.30.1.31 still tries to send the packet through xl0, and although route add 10.30.1.15 -interface xl1 does put in the correct interface in the routing table, It doesn't work. Any Ideas? Thanks again. Peter Brezny SysAdmin Services Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 17 7:14:58 2001 Delivered-To: freebsd-net@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id 20E1C37B424 for ; Tue, 17 Apr 2001 07:14:53 -0700 (PDT) (envelope-from itojun@itojun.org) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 13BB64B0B; Tue, 17 Apr 2001 23:14:50 +0900 (JST) To: skodati@in.ibm.com Cc: freebsd-net@FreeBSD.ORG In-reply-to: skodati's message of Tue, 17 Apr 2001 16:05:04 +0530. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: IPv6 : interface configuration From: itojun@iijlab.net Date: Tue, 17 Apr 2001 23:14:50 +0900 Message-ID: <28190.987516890@itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >I have configured my system for IPv6, and the system is getting >autoconfigured properly. (ifconfig shows both IPv4 and v6 addresses). >I want to read the information about interfaces being configured with IPv6 >address. >I opened a socket for ip domain and reading the information into "ifconf" >through "ioctl" with SIOCGIFCONF flag. And then reading all the addresses >thru ifreq. >But iam not able to find any interaces with address famly AF_INET6. getifaddrs(3) is the easiest way. SIOCGIFCONF is very hard to use these days, due to buffer size management, as well as variable-length packed struct . itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 17 8: 4:46 2001 Delivered-To: freebsd-net@freebsd.org Received: from porsta.cs.Helsinki.FI (porsta.cs.Helsinki.FI [128.214.48.124]) by hub.freebsd.org (Postfix) with ESMTP id 07CE237B446 for ; Tue, 17 Apr 2001 08:04:42 -0700 (PDT) (envelope-from gurtov@cs.Helsinki.FI) Received: from saviletto.cs.Helsinki.FI (gurtov@saviletto.cs.Helsinki.FI [128.214.9.225]) by porsta.cs.Helsinki.FI (8.8.8/8.8.8) with ESMTP id SAA11579; Tue, 17 Apr 2001 18:04:38 +0300 Date: Tue, 17 Apr 2001 18:04:38 +0300 (EET DST) From: Andrei Gurtov To: Cc: Subject: initial congestion window Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi folks, At the last IETF meeting there were some debates around FreeBSD using a 16-KB initial congestion window in TCP when destination IP address is from the local subnet. Does anybody remember when it was introduced into the code and what kind of ideas were behind? Some reasons were given why it may not be a good idea: -the benefit of not having slow start on LANs is very small, i.e. some milliseconds -it is not a conformant TCP feature, i.e. not allowed by TCP Congestion Control (RFC2581) and is explicitly given in Known TCP Implementation Problems (RFC2525) "2.1 No initial slow start" and "2.3 Uninitialized CWND" -people may have the same subnet mask also over a slow PPP link. In this case the effect of the huge initial window is quite bad, see for example http://www.cs.Helsinki.FI/u/gurtov/papers/effect_of_delays_on_tcp_performance.pdf -in case of congestion on Ethernet, packets queues build up at the network interfaces in hosts and agressive TCP start-up behaviour can further increase congestion losses What are your thoughts on this? Andrei tcp_output.c: int ss_fltsz = 1; SYSCTL_INT(_net_inet_tcp, OID_AUTO, slowstart_flightsize, CTLFLAG_RW, &ss_fltsz, 1, "Slow start flight size"); int ss_fltsz_local = TCP_MAXWIN; /* something large */ SYSCTL_INT(_net_inet_tcp, OID_AUTO, local_slowstart_flightsize, CTLFLAG_RW, &ss_fltsz_local, 1, "Slow start flight size for local networks"); [...] if ( in_localaddr(tp->t_inpcb->inp_faddr) ) tp->snd_cwnd = tp->t_maxseg * ss_fltsz_local; else tp->snd_cwnd = tp->t_maxseg * ss_fltsz; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 17 8:26:46 2001 Delivered-To: freebsd-net@freebsd.org Received: from kanga.honeypot.net (kanga.honeypot.net [216.224.193.50]) by hub.freebsd.org (Postfix) with ESMTP id A004437B43E for ; Tue, 17 Apr 2001 08:26:42 -0700 (PDT) (envelope-from kirk@honeypot.net) Received: from pooh.honeypot (mail@pooh.honeypot [10.0.1.2]) by kanga.honeypot.net (8.11.3/8.11.3) with ESMTP id f3HFQfi15402 for ; Tue, 17 Apr 2001 10:26:41 -0500 (CDT) (envelope-from kirk@honeypot.net) Received: from kirk by pooh.honeypot with local (Exim 3.22 #1 (Debian)) id 14pXND-0001IC-00 for ; Tue, 17 Apr 2001 10:26:35 -0500 To: freebsd-net@freebsd.org Subject: Re: three nics, two networks, simple routing problem... References: From: Kirk Strauser Date: 17 Apr 2001 10:26:35 -0500 In-Reply-To: Message-ID: <87n19f35uc.fsf@pooh.honeypot> Lines: 34 X-Mailer: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 2001-04-17T14:07:08Z, Peter Brezny writes: > 10.30.1.1 GW----xl0 10.30.1.30 FW xl2----10.20.30.1 LAN > | > xl1 > | > | > 10.30.1.15 FW ----- 10.20.15.1 LAN > > However, with my current conf files, I can't even ping xl1 from the box > it's in. I can manually add a route, but I still can't ping the interface > itself. > > What have I missed? > > TIA > > Peter Brezny > SysAdmin Services Inc. > > my rc.conf looks like this. > > ifconfig_xl0="inet 10.30.1.30 netmask 255.255.255.0" > ifconfig_xl1="inet 10.30.1.31 netmask 255.255.255.0" > ifconfig_xl2="inet 10.20.30.1 netmask 255.255.255.0" > > xl1 is the iface giving problems. You don't get any problems from having the exact same /24 network on two different NICs? What happens if you give each NIC a different network, preferably even making sure that they don't overlap (for testing purposes)? -- Kirk Strauser To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 17 9: 6:36 2001 Delivered-To: freebsd-net@freebsd.org Received: from bsdie.rwsystems.net (bsdie.rwsystems.net [209.197.223.2]) by hub.freebsd.org (Postfix) with ESMTP id 2527C37B422; Tue, 17 Apr 2001 09:06:32 -0700 (PDT) (envelope-from jwyatt@rwsystems.net) Received: from bsdie.rwsystems.net([209.197.223.2]) (2117 bytes) by bsdie.rwsystems.net via sendmail with P:esmtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) id for ; Tue, 17 Apr 2001 11:04:28 -0500 (CDT) (Smail-3.2.0.111 2000-Feb-17 #1 built 2000-Jun-25) Date: Tue, 17 Apr 2001 11:04:27 -0500 (CDT) From: James Wyatt To: Alfred Perlstein Cc: Darren Reed , Julian Elischer , freebsd-security@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: non-random IP IDs In-Reply-To: <20010417043130.F976@fw.wintelcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 17 Apr 2001, Alfred Perlstein wrote: > * Darren Reed [010417 04:29] wrote: > > In some mail from Julian Elischer, sie said: > > > > > > there is a site that calculates server uptime from these numbers. > > > All the leading machines are freeBSD. When you do this it will > > > no-longer be able to track us :-( > > > > IMHO, extraordinarily large uptimes are nothing to be proud of and > > say nothing about the quality of software. > > > > I'd almost go so far as to say uptimes greater than 1 year indicate > > that the system administration practises need review. > > Agreed. I've yet to hear about any seriously deployed system > go without security advisories for over a year. You don't have to reboot to fix all the security advisories - just a very critical few... The last few haven't required reboots to either workaround or fix. (Replacing libc on a running system *can* be tricky; I blew a SCO box up that way once!) Some machines with long uptimes are in fairly secure places (walled-in) so they get serviced less - I've had an AIX box up 596 days, but it had *very* specific use and "couldn't" take an outage. I also used a VAX that we didn't find out could not boot until we tried. The boot params had been goofed-up about six *months* before the failure and we didn't know it until it nearly killed us... - Jy@ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 17 9:32:36 2001 Delivered-To: freebsd-net@freebsd.org Received: from ms17.hinet.net (ms17.hinet.net [168.95.4.17]) by hub.freebsd.org (Postfix) with ESMTP id 4941737B43C for ; Tue, 17 Apr 2001 09:32:26 -0700 (PDT) (envelope-from r041102@ms17.hinet.net) Received: from wen (h34.s243.ts31.hinet.net [163.31.243.34]) by ms17.hinet.net (8.8.8/8.8.8) with SMTP id AAA23948 for ; Wed, 18 Apr 2001 00:32:23 +0800 (CST) Message-ID: <001a01c0c825$aee59300$f3fb1fa3@wen> From: "Jessey" To: Subject: I call sosend occur error . The error code=22. Date: Thu, 19 Apr 2001 00:36:11 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0017_01C0C868.BBC9EA60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_0017_01C0C868.BBC9EA60 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable Dear Sir: I call sosend occur error. The error code=3D22. What wrong in my code? The code follow: socreate(); file://is ok; | } top=3Dm_get(MT_DATA,M_DONTWAIT); if(top=3D=3DNULL) { log(LOG_INFO, "top=3DNULL occur error\n"); goto out; } top->m_next=3DNULL; top->m_nextpkt=3DNULL; top->m_len=3D50; adr=3Dsizeof(struct m_hdr) +sizeof(int)+sizeof(struct ifnet *); log(LOG_INFO, "adr=3D %d \n",adr); top->m_data=3Dtop+adr; log(LOG_INFO, "top=3D %x, top->m_data=3D %x,top+adr=3D%x \n",top=20 ,top->m_data,top+adr); top->m_type=3DMT_DATA; top->m_flags=3DM_PKTHDR; top->m_pkthdr.len=3D50; top->m_pkthdr.rcvif=3DNULL; log(LOG_INFO, "top=3D %x, Data=3D %x \n",top ,top->m_data); error =3D sosend(so,(struct sockaddr *) &sin,NULL,top,=20 0,MSG_DONTROUTE); Thanks/regards ------=_NextPart_000_0017_01C0C868.BBC9EA60 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable
Dear Sir:
I call sosend occur error. The error=20 code=3D22.
What wrong in my code?

The code = follow:

socreate(); file://is=20 ok;

|
}

top=3Dm_get(MT_DATA,M_DONTWAIT);

 &n= bsp;  =20 if(top=3D=3DNULL)
    =20 {
         log(LOG_INFO, = "top=3DNULL=20 occur error\n");
         = goto=20 out;
     }

    =20 top->m_next=3DNULL;
    =20 top->m_nextpkt=3DNULL;
    =20 top->m_len=3D50;
     adr=3Dsizeof(struct = m_hdr)=20 +sizeof(int)+sizeof(struct ifnet *);
     = log(LOG_INFO,=20 "adr=3D %d \n",adr);

    =20 top->m_data=3Dtop+adr;
     log(LOG_INFO, = "top=3D %x,=20 top->m_data=3D %x,top+adr=3D%x \n",top=20
,top->m_data,top+adr);

    =20 top->m_type=3DMT_DATA;
    =20 top->m_flags=3DM_PKTHDR;
    =20 top->m_pkthdr.len=3D50;
    =20 top->m_pkthdr.rcvif=3DNULL;


     = log(LOG_INFO,=20 "top=3D %x, Data=3D %x \n",top = ,top->m_data);

    =20 error =3D sosend(so,(struct sockaddr *) &sin,NULL,top,=20
0,MSG_DONTROUTE);

Thanks/regards
------=_NextPart_000_0017_01C0C868.BBC9EA60-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 17 10:31:41 2001 Delivered-To: freebsd-net@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 717FF37B43C; Tue, 17 Apr 2001 10:31:32 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.11.2) id f3HHVFu94944; Tue, 17 Apr 2001 10:31:15 -0700 (PDT) (envelope-from dillon) Date: Tue, 17 Apr 2001 10:31:15 -0700 (PDT) From: Matt Dillon Message-Id: <200104171731.f3HHVFu94944@earth.backplane.com> To: Kris Kennaway Cc: Niels Provos , Kris Kennaway , Wes Peters , freebsd-security@FreeBSD.ORG, net@FreeBSD.ORG, provos@OpenBSD.org Subject: Re: non-random IP IDs References: <20010416214611.6DA3F207C1@citi.umich.edu> <200104170157.f3H1v4d87804@earth.backplane.com> <20010416233042.A21394@xor.obsecurity.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :> It's not worth doing. We would be introducing unnecessary cpu burn on :> every single packet we sent out, all to solve a problem that doesn't :> really exist. : :Well, that's why it's a sysctl defaulting to off in my patch. Don't :turn it on if you don't want to. : :Kris Let me put it another way: I think this sort of thing is an excellent example of introducing unnecessary kernel bloat into the system. Who gives a fart whether someone can port scan you efficiently or anonymously or not? I get port scanned every day. Most hackers don't even bother with portscans, they just try the exploit on the target machines directly. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 17 10:38:21 2001 Delivered-To: freebsd-net@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 2B59737B424; Tue, 17 Apr 2001 10:38:16 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id KAA56704; Tue, 17 Apr 2001 10:37:56 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <200104171737.KAA56704@gndrsh.dnsmgr.net> Subject: Re: non-random IP IDs In-Reply-To: <20010417043130.F976@fw.wintelcom.net> from Alfred Perlstein at "Apr 17, 2001 04:31:30 am" To: bright@wintelcom.net (Alfred Perlstein) Date: Tue, 17 Apr 2001 10:37:56 -0700 (PDT) Cc: avalon@coombs.anu.edu.au (Darren Reed), julian@elischer.org (Julian Elischer), freebsd-security@FreeBSD.ORG, 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 X-Loop: FreeBSD.org > * Darren Reed [010417 04:29] wrote: > > In some mail from Julian Elischer, sie said: > > > > > > there is a site that calculates server uptime from these numbers. > > > All the leading machines are freeBSD. When you do this it will > > > no-longer be able to track us :-( > > > > IMHO, extraordinarily large uptimes are nothing to be proud of and > > say nothing about the quality of software. > > > > I'd almost go so far as to say uptimes greater than 1 year indicate > > that the system administration practises need review. > > Agreed. I've yet to hear about any seriously deployed system > go without security advisories for over a year. Or perhaps this is a very talented system admin who values uptime and finds work arounds that don't envolve downing a system that do just as good, and sometimes better, than the vendor fix for the security issue. Security Fix != Reboot required. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 17 10:38:35 2001 Delivered-To: freebsd-net@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-27.dsl.lsan03.pacbell.net [63.207.60.27]) by hub.freebsd.org (Postfix) with ESMTP id EF51F37B43F; Tue, 17 Apr 2001 10:38:24 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 2A14F67C11; Tue, 17 Apr 2001 10:38:24 -0700 (PDT) Date: Tue, 17 Apr 2001 10:38:23 -0700 From: Kris Kennaway To: Matt Dillon Cc: Kris Kennaway , Niels Provos , Wes Peters , freebsd-security@FreeBSD.ORG, net@FreeBSD.ORG, provos@OpenBSD.org Subject: Re: non-random IP IDs Message-ID: <20010417103823.A49384@xor.obsecurity.org> References: <20010416214611.6DA3F207C1@citi.umich.edu> <200104170157.f3H1v4d87804@earth.backplane.com> <20010416233042.A21394@xor.obsecurity.org> <200104171731.f3HHVFu94944@earth.backplane.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="7JfCtLOvnd9MIVvH" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200104171731.f3HHVFu94944@earth.backplane.com>; from dillon@earth.backplane.com on Tue, Apr 17, 2001 at 10:31:15AM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 17, 2001 at 10:31:15AM -0700, Matt Dillon wrote: >=20 > :> It's not worth doing. We would be introducing unnecessary cpu bur= n on > :> every single packet we sent out, all to solve a problem that doesn= 't > :> really exist. > : > :Well, that's why it's a sysctl defaulting to off in my patch. Don't > :turn it on if you don't want to. > : > :Kris >=20 > Let me put it another way: I think this sort of thing is an excellent > example of introducing unnecessary kernel bloat into the system. Who > gives a fart whether someone can port scan you efficiently or > anonymously or not? I get port scanned every day. Most hackers don't > even bother with portscans, they just try the exploit on the target= =20 > machines directly. Tools, not policy.. You may not care about it, but others do. Kris --7JfCtLOvnd9MIVvH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE63H+PWry0BWjoQKURAjS3AJ0XbkDrdbdXfQtVsqNRMqv3FgCHwgCfW/01 LJrMwuCPS6PVA5Upc8ODp7s= =hVGy -----END PGP SIGNATURE----- --7JfCtLOvnd9MIVvH-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 17 10:41:40 2001 Delivered-To: freebsd-net@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id A8E1437B422; Tue, 17 Apr 2001 10:41:36 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.11.2) id f3HHfNZ95206; Tue, 17 Apr 2001 10:41:23 -0700 (PDT) (envelope-from dillon) Date: Tue, 17 Apr 2001 10:41:23 -0700 (PDT) From: Matt Dillon Message-Id: <200104171741.f3HHfNZ95206@earth.backplane.com> To: Kris Kennaway Cc: Kris Kennaway , Niels Provos , Wes Peters , freebsd-security@FreeBSD.ORG, net@FreeBSD.ORG, provos@OpenBSD.org Subject: Re: non-random IP IDs References: <20010416214611.6DA3F207C1@citi.umich.edu> <200104170157.f3H1v4d87804@earth.backplane.com> <20010416233042.A21394@xor.obsecurity.org> <200104171731.f3HHVFu94944@earth.backplane.com> <20010417103823.A49384@xor.obsecurity.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :> Let me put it another way: I think this sort of thing is an excellent :> example of introducing unnecessary kernel bloat into the system. Who :> gives a fart whether someone can port scan you efficiently or :> anonymously or not? I get port scanned every day. Most hackers don't :> even bother with portscans, they just try the exploit on the target= :=20 :> machines directly. : :Tools, not policy.. : :You may not care about it, but others do. : :Kris If it isn't already a kernel option, please make it one. I don't want it compiled into the binary. Those people who 'care' can add it to their kernel config. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 17 10:47: 1 2001 Delivered-To: freebsd-net@freebsd.org Received: from cithaeron.argolis.org (bgm-24-94-35-22.stny.rr.com [24.94.35.22]) by hub.freebsd.org (Postfix) with ESMTP id C9CD737B440; Tue, 17 Apr 2001 10:46:51 -0700 (PDT) (envelope-from piechota@argolis.org) Received: from localhost (piechota@localhost) by cithaeron.argolis.org (8.11.3/8.11.3) with ESMTP id f3HHjQY46361; Tue, 17 Apr 2001 13:45:27 -0400 (EDT) (envelope-from piechota@argolis.org) X-Authentication-Warning: cithaeron.argolis.org: piechota owned process doing -bs Date: Tue, 17 Apr 2001 13:45:26 -0400 (EDT) From: Matt Piechota To: Kris Kennaway Cc: Matt Dillon , Niels Provos , Wes Peters , , , Subject: Re: non-random IP IDs In-Reply-To: <20010417103823.A49384@xor.obsecurity.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 17 Apr 2001, Kris Kennaway wrote: > > :Well, that's why it's a sysctl defaulting to off in my patch. Don't > > :turn it on if you don't want to. > > > > Let me put it another way: I think this sort of thing is an excellent > > example of introducing unnecessary kernel bloat into the system. Who > > gives a fart whether someone can port scan you efficiently or > > anonymously or not? I get port scanned every day. Most hackers don't > > even bother with portscans, they just try the exploit on the target > > machines directly. > > Tools, not policy.. > > You may not care about it, but others do. Would it be better to do it as a kernel option? options IP_RANDOM_IP_ID for instance? I guess the question is, does the kernel have to do a comparison to the sysctl variable each time? -- Matt Piechota Finger piechota@emailempire.com for PGP key AOL IM: cithaeron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 17 10:54:44 2001 Delivered-To: freebsd-net@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-27.dsl.lsan03.pacbell.net [63.207.60.27]) by hub.freebsd.org (Postfix) with ESMTP id 0499F37B423; Tue, 17 Apr 2001 10:54:37 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 50227675EE; Tue, 17 Apr 2001 10:54:25 -0700 (PDT) Date: Tue, 17 Apr 2001 10:54:24 -0700 From: Kris Kennaway To: Matt Dillon Cc: freebsd-security@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: non-random IP IDs Message-ID: <20010417105424.A63938@xor.obsecurity.org> References: <20010416214611.6DA3F207C1@citi.umich.edu> <200104170157.f3H1v4d87804@earth.backplane.com> <20010416233042.A21394@xor.obsecurity.org> <200104171731.f3HHVFu94944@earth.backplane.com> <20010417103823.A49384@xor.obsecurity.org> <200104171741.f3HHfNZ95206@earth.backplane.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="WIyZ46R2i8wDzkSu" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200104171741.f3HHfNZ95206@earth.backplane.com>; from dillon@earth.backplane.com on Tue, Apr 17, 2001 at 10:41:23AM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 17, 2001 at 10:41:23AM -0700, Matt Dillon wrote: >=20 > :> Let me put it another way: I think this sort of thing is an excel= lent > :> example of introducing unnecessary kernel bloat into the system. = Who > :> gives a fart whether someone can port scan you efficiently or > :> anonymously or not? I get port scanned every day. Most hackers d= on't > :> even bother with portscans, they just try the exploit on the targe= t=3D > :=3D20 > :> machines directly. > : > :Tools, not policy.. > : > :You may not care about it, but others do. > : > :Kris >=20 > If it isn't already a kernel option, please make it one. I don't=20 > want it compiled into the binary. Those people who 'care' can > add it to their kernel config. That's probably a reasonable compromise. Kris --WIyZ46R2i8wDzkSu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE63INQWry0BWjoQKURApnUAJ4sAl/zGR1o5U5kkq3f4MPhKdlXkwCeOM6d 7BEla6Tvf4GNmd0n/wTNdrk= =2JeN -----END PGP SIGNATURE----- --WIyZ46R2i8wDzkSu-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 17 10:55: 3 2001 Delivered-To: freebsd-net@freebsd.org Received: from nsmail.corp.globalstar.com (gibraltar.globalstar.com [207.88.248.142]) by hub.freebsd.org (Postfix) with ESMTP id 225E637B43C; Tue, 17 Apr 2001 10:54:52 -0700 (PDT) (envelope-from crist.clark@globalstar.com) Received: from globalstar.com ([207.88.153.184]) by nsmail.corp.globalstar.com (Netscape Messaging Server 4.15) with ESMTP id GBY72W00.NB6; Tue, 17 Apr 2001 10:54:32 -0700 Message-ID: <3ADC8368.C96550FE@globalstar.com> Date: Tue, 17 Apr 2001 10:54:48 -0700 From: "Crist Clark" Organization: Globalstar LP X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Kris Kennaway Cc: Matt Dillon , Niels Provos , Wes Peters , freebsd-security@FreeBSD.ORG, net@FreeBSD.ORG, provos@OpenBSD.org Subject: Re: non-random IP IDs References: <20010416214611.6DA3F207C1@citi.umich.edu> <200104170157.f3H1v4d87804@earth.backplane.com> <20010416233042.A21394@xor.obsecurity.org> <200104171731.f3HHVFu94944@earth.backplane.com> <20010417103823.A49384@xor.obsecurity.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Kris Kennaway wrote: > > On Tue, Apr 17, 2001 at 10:31:15AM -0700, Matt Dillon wrote: > > > > :> It's not worth doing. We would be introducing unnecessary cpu burn on > > :> every single packet we sent out, all to solve a problem that doesn't > > :> really exist. > > : > > :Well, that's why it's a sysctl defaulting to off in my patch. Don't > > :turn it on if you don't want to. > > : > > :Kris > > > > Let me put it another way: I think this sort of thing is an excellent > > example of introducing unnecessary kernel bloat into the system. Who > > gives a fart whether someone can port scan you efficiently or > > anonymously or not? I get port scanned every day. Most hackers don't > > even bother with portscans, they just try the exploit on the target > > machines directly. > > Tools, not policy.. > > You may not care about it, but others do. Some people want it. The code already exists. Put it in the source tree so those people who want it can have it, but more importantly, so we never have to explain why OpenBSD has IP ID randomization and FreeBSD does not or otherwise go through this same thread ever again. I think the only bikesh^H^H^H^H^H^H question should be whether it is (a) always built into the kernel, but has the sysctl switched off, or (b) it requires a kernel config option like, options IP_ID_RANDOMIZE (Which will not be in GENERIC) to get the code in the kernel. Personally, I like (b). It's right there for those who want it, but the bloat-watchers don't have to see that extra few bytes going to kernelland. -- Crist J. Clark Network Security Engineer crist.clark@globalstar.com Globalstar, L.P. (408) 933-4387 FAX: (408) 933-4926 The information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact postmaster@globalstar.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 17 11: 6:38 2001 Delivered-To: freebsd-net@freebsd.org Received: from zeta.qmw.ac.uk (zeta.qmw.ac.uk [138.37.6.6]) by hub.freebsd.org (Postfix) with ESMTP id 0EBC637B42C; Tue, 17 Apr 2001 11:06:33 -0700 (PDT) (envelope-from d.m.pick@qmw.ac.uk) Received: from xi.css.qmw.ac.uk ([138.37.8.11]) by zeta.qmw.ac.uk with esmtp (Exim 3.16 #1) id 14pZry-0005qP-00; Tue, 17 Apr 2001 19:06:30 +0100 Received: from cgaa180 by xi.css.qmw.ac.uk with local (Exim 1.92 #1) id 14pZry-0002mO-00; Tue, 17 Apr 2001 19:06:30 +0100 X-Mailer: exmh version 2.0.2 2/24/98 To: freebsd-security@FreeBSD.ORG, net@FreeBSD.ORG, provos@OpenBSD.org Subject: Re: non-random IP IDs In-reply-to: Your message of "Tue, 17 Apr 2001 13:45:26 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 17 Apr 2001 19:06:30 +0100 From: David Pick Message-Id: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Would it be better to do it as a kernel option? > options IP_RANDOM_IP_ID for instance? I guess the question is, does the > kernel have to do a comparison to the sysctl variable each time? No. *IF* (big if!) something gets notified when a sysctl variable gets changed (and I don't know of this is true) then if can test the variable once and set a *function* variable to one of two functions: one simple and fast, the other complicated and slow. No test needed for every packet. Of course, the overhead of a procedure call might (in the fast case) be more than the overhead of an inline test. So perhaps write it as: if (function variable) { function_varuable(parameter) } else { /* inline code */ } But there a *lots* of other tests per packet - is one more *that* bad? -- David Pick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 17 11:18:18 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 6971837B43E; Tue, 17 Apr 2001 11:17:58 -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 OAA13455; Tue, 17 Apr 2001 14:12:40 -0400 (EDT) (envelope-from wollman) Date: Tue, 17 Apr 2001 14:12:40 -0400 (EDT) From: Garrett Wollman Message-Id: <200104171812.OAA13455@khavrinen.lcs.mit.edu> To: "Crist Clark" Cc: freebsd-security@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: non-random IP IDs In-Reply-To: <3ADC8368.C96550FE@globalstar.com> References: <20010416214611.6DA3F207C1@citi.umich.edu> <200104170157.f3H1v4d87804@earth.backplane.com> <20010416233042.A21394@xor.obsecurity.org> <200104171731.f3HHVFu94944@earth.backplane.com> <20010417103823.A49384@xor.obsecurity.org> <3ADC8368.C96550FE@globalstar.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > Personally, I like (b). It's right there for those who want it, but > the bloat-watchers don't have to see that extra few bytes going to > kernelland. I think this is reasonable. With the way memory subsystems work these days, we need to avoid wasting valuable cache in order to get the maximum possible performance. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 17 12:50:58 2001 Delivered-To: freebsd-net@freebsd.org Received: from technokratis.com (modemcable092.3-201-24.mtl.mc.videotron.ca [24.201.3.92]) by hub.freebsd.org (Postfix) with ESMTP id AC58137B422 for ; Tue, 17 Apr 2001 12:50:33 -0700 (PDT) (envelope-from bmilekic@technokratis.com) Received: (from bmilekic@localhost) by technokratis.com (8.11.3/8.11.3) id f3HJptf13211; Tue, 17 Apr 2001 15:51:55 -0400 (EDT) (envelope-from bmilekic) Date: Tue, 17 Apr 2001 15:51:54 -0400 From: Bosko Milekic To: Jessey Cc: freebsd-net@FreeBSD.ORG Subject: Re: I call sosend occur error . The error code=22. Message-ID: <20010417155154.A13132@technokratis.com> References: <001a01c0c825$aee59300$f3fb1fa3@wen> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <001a01c0c825$aee59300$f3fb1fa3@wen>; from r041102@ms17.hinet.net on Thu, Apr 19, 2001 at 12:36:11AM +0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Apr 19, 2001 at 12:36:11AM +0800, Jessey wrote: > Dear Sir: > I call sosend occur error. The error code=22. > What wrong in my code? > > The code follow: > > socreate(); file://is ok; > > | > } > > top=m_get(MT_DATA,M_DONTWAIT); > > if(top==NULL) > { > log(LOG_INFO, "top=NULL occur error\n"); > goto out; > } > > top->m_next=NULL; > top->m_nextpkt=NULL; > top->m_len=50; > adr=sizeof(struct m_hdr) +sizeof(int)+sizeof(struct ifnet *); > log(LOG_INFO, "adr= %d \n",adr); > > top->m_data=top+adr; ^^^^^^^^^^^^^^^^^^^^^^ First of all, that looks totally bogus! > log(LOG_INFO, "top= %x, top->m_data= %x,top+adr=%x \n",top > ,top->m_data,top+adr); > > top->m_type=MT_DATA; > top->m_flags=M_PKTHDR; > top->m_pkthdr.len=50; > top->m_pkthdr.rcvif=NULL; You should probably just be using m_gethdr. Is this kernel code? > log(LOG_INFO, "top= %x, Data= %x \n",top ,top->m_data); > > error = sosend(so,(struct sockaddr *) &sin,NULL,top, > 0,MSG_DONTROUTE); Error code 22 is EINVAL. Something sosend() calls is telling you that whatever you're passing to sosend() is probably invalid. Are you sure that what you're trying to do is OK? > Thanks/regards -- Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 17 13:13:14 2001 Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id D94E937B423; Tue, 17 Apr 2001 13:13:09 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f3HKD0322697; Tue, 17 Apr 2001 13:13:00 -0700 (PDT) Date: Tue, 17 Apr 2001 13:13:00 -0700 From: Alfred Perlstein To: "Rodney W. Grimes" Cc: Darren Reed , Julian Elischer , freebsd-security@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: non-random IP IDs Message-ID: <20010417131300.L976@fw.wintelcom.net> References: <20010417043130.F976@fw.wintelcom.net> <200104171737.KAA56704@gndrsh.dnsmgr.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200104171737.KAA56704@gndrsh.dnsmgr.net>; from freebsd@gndrsh.dnsmgr.net on Tue, Apr 17, 2001 at 10:37:56AM -0700 X-all-your-base: are belong to us. Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Rodney W. Grimes [010417 10:37] wrote: > > * Darren Reed [010417 04:29] wrote: > > > In some mail from Julian Elischer, sie said: > > > > > > > > there is a site that calculates server uptime from these numbers. > > > > All the leading machines are freeBSD. When you do this it will > > > > no-longer be able to track us :-( > > > > > > IMHO, extraordinarily large uptimes are nothing to be proud of and > > > say nothing about the quality of software. > > > > > > I'd almost go so far as to say uptimes greater than 1 year indicate > > > that the system administration practises need review. > > > > Agreed. I've yet to hear about any seriously deployed system > > go without security advisories for over a year. > > Or perhaps this is a very talented system admin who values uptime > and finds work arounds that don't envolve downing a system that do > just as good, and sometimes better, than the vendor fix for the > security issue. > > Security Fix != Reboot required. Well I was the one that asked Jake if he could provide a system for patching static functions in the kernel. If you search the archives there is a patch for doing this. It's actually quite reasonable to patch code out from under a running system. One can replace the entry opcode of the function with a jump to the patched code. The only time this becomes a problem is when structures change, however backporting the fix shouldn't be a problem. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] Represent yourself, show up at BABUG http://www.babug.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 17 13:47:11 2001 Delivered-To: freebsd-net@freebsd.org Received: from caligula.anu.edu.au (caligula.anu.edu.au [150.203.224.42]) by hub.freebsd.org (Postfix) with ESMTP id 819D437B43F; Tue, 17 Apr 2001 13:47:03 -0700 (PDT) (envelope-from avalon@caligula.anu.edu.au) Received: (from avalon@localhost) by caligula.anu.edu.au (8.9.3/8.9.3) id GAA04095; Wed, 18 Apr 2001 06:46:57 +1000 (EST) From: Darren Reed Message-Id: <200104172046.GAA04095@caligula.anu.edu.au> Subject: Re: non-random IP IDs To: bright@wintelcom.net (Alfred Perlstein) Date: Wed, 18 Apr 2001 06:46:57 +1000 (Australia/ACT) Cc: freebsd-security@FreeBSD.ORG, net@FreeBSD.ORG In-Reply-To: <20010417131300.L976@fw.wintelcom.net> from "Alfred Perlstein" at Apr 17, 2001 01:13:00 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In some mail from Alfred Perlstein, sie said: > > * Rodney W. Grimes [010417 10:37] wrote: > > > * Darren Reed [010417 04:29] wrote: > > > > In some mail from Julian Elischer, sie said: > > > > > > > > > > there is a site that calculates server uptime from these numbers. > > > > > All the leading machines are freeBSD. When you do this it will > > > > > no-longer be able to track us :-( > > > > > > > > IMHO, extraordinarily large uptimes are nothing to be proud of and > > > > say nothing about the quality of software. > > > > > > > > I'd almost go so far as to say uptimes greater than 1 year indicate > > > > that the system administration practises need review. [WARNING: major digression from security ahead] I'm not talking (just) about security here. I'm talking about systems maintenance. How long has your box been up ? How many changes to the system config have been made since then ? If you're not there, and it reboots, will it come up 100% functional ? Do your computers need some amount of preventative maintenance like internal cleaning to deal with dust build up, etc ? How many times do unscheduled reboots result in hardware not spinning back up and at an inconevient time ? Any non-trivial change to startup (or bootup) sequence should be tested and how do you do that without a reboot ? Else where is the egg when that "she'll be right mate" change fails at 9:00am on Monday morning and you've slept in ? There is so much more to serious system admin (from your personal desktops to mainframes) than just applying (security) patches and keeping it running with no downtime. Well, that is when you don't have hot-swap everything :) None of my personal boxes have uptimes that ever exceed 6 months, even my servers, but I have complete confidence in them rebooting and services being restarted (modulo file system damage from an unclean shutdown). Darren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 17 14:20:53 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.wlcg.com (mail.wlcg.com [207.226.17.4]) by hub.freebsd.org (Postfix) with ESMTP id BB1C637B424; Tue, 17 Apr 2001 14:20:46 -0700 (PDT) (envelope-from rsimmons@wlcg.com) Received: from localhost (rsimmons@localhost) by mail.wlcg.com (8.11.3/8.11.3) with ESMTP id f3HLJbS92759; Tue, 17 Apr 2001 17:19:41 -0400 (EDT) (envelope-from rsimmons@wlcg.com) Date: Tue, 17 Apr 2001 17:19:34 -0400 (EDT) From: Rob Simmons To: Matt Dillon Cc: Kris Kennaway , Niels Provos , Wes Peters , , , Subject: Re: non-random IP IDs In-Reply-To: <200104171731.f3HHVFu94944@earth.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 On Tue, 17 Apr 2001, Matt Dillon wrote: > Let me put it another way: I think this sort of thing is an excellent > example of introducing unnecessary kernel bloat into the system. Who > gives a fart whether someone can port scan you efficiently or > anonymously or not? I get port scanned every day. Most hackers don't > even bother with portscans, they just try the exploit on the target > machines directly. You could add a kernel config variable in case someone wants a less bloated kernel. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE63LNpv8Bofna59hYRA/5RAKCIRJTLpcf8kZ7q86QeLrfUzWBM9gCgqhuO GTxP1jwxVOgpsCpfGjx10js= =Y/2k -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 17 14:43:27 2001 Delivered-To: freebsd-net@freebsd.org Received: from bluenugget.net (skin-flute.com [64.3.150.188]) by hub.freebsd.org (Postfix) with ESMTP id 5693037B423; Tue, 17 Apr 2001 14:43:22 -0700 (PDT) (envelope-from geniusj@bluenugget.net) Received: from worsehalf (sf-gw.epylon.com [63.93.9.98]) by bluenugget.net (Postfix) with ESMTP id A81371367C; Tue, 17 Apr 2001 14:15:16 -0700 (PDT) Message-ID: <004201c0c783$7fe71df0$4904a8c0@epylon.lan> From: "Jason DiCioccio" To: "Darren Reed" , "Alfred Perlstein" Cc: , References: <200104172046.GAA04095@caligula.anu.edu.au> Subject: Re: non-random IP IDs Date: Tue, 17 Apr 2001 14:15:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org From: "Darren Reed" Subject: Re: non-random IP IDs > How long has your box been up ? How many changes to the system config > have been made since then ? If you're not there, and it reboots, will > it come up 100% functional ? Do your computers need some amount of > preventative maintenance like internal cleaning to deal with dust build > up, etc ? I don't know very many if any people that take their machines off the rack just to clean dust out of the case. > How many times do unscheduled reboots result in hardware not > spinning back up and at an inconevient time ? This would happen regardless of when/if you rebooted it. > Any non-trivial change to > startup (or bootup) sequence should be tested and how do you do that > without a reboot ? I use /usr/local/etc/rc.d, so for me it would be 'blah.sh stop && blah.sh start..' If you use rc.local or rc.* usually running the necessary commands while system is up is a good determination on whether it'll work, or putting it in a separate shell script and running that is even better (to make sure that it doesn't go into interactive mode or anything) Not to mention again, this would happen whether you rebooted it right after you made them or whether you rebooted it 6 months from then. > Else where is the egg when that "she'll be right mate" > change fails at 9:00am on Monday morning and you've slept in ? echo -n in your startup scripts works wonders :-) > > There is so much more to serious system admin (from your personal desktops > to mainframes) than just applying (security) patches and keeping it running > with no downtime. Well, that is when you don't have hot-swap everything :) > > None of my personal boxes have uptimes that ever exceed 6 months, even my > servers, but I have complete confidence in them rebooting and services being > restarted (modulo file system damage from an unclean shutdown). softupdates should take care of this, and as far as HD trouble, if you're system is really that important then mirror your disks. Cheers, -JD- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 17 23:34:54 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 C9D2537B424 for ; Tue, 17 Apr 2001 23:34:49 -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 IAA41452; Wed, 18 Apr 2001 08:33:18 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200104180633.IAA41452@info.iet.unipi.it> Subject: Re: initial congestion window In-Reply-To: from Andrei Gurtov at "Apr 17, 2001 06:04:38 pm" To: Andrei Gurtov Date: Wed, 18 Apr 2001 08:33:18 +0200 (CEST) Cc: freebsd-net@FreeBSD.ORG, Reiner.Ludwig@Ericsson.com 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 X-Loop: FreeBSD.org Hi, yes, FreeBSD is blasting the full socket buffer onto the net when the destination is "local". I think it was introduced when the T/TCP changes were committed, it kind-of makes sense with T/TCP, but other than that it is a very bad idea to have it on by default. For one, in many nets including a 100/10 switch, or slow receivers, it tends to cause an immediate loss on the first window of data because of the overload at the switch or the receiver. cheers luigi > > Hi folks, > > At the last IETF meeting there were some debates around FreeBSD using a > 16-KB initial congestion window in TCP when destination IP address is from > the local subnet. Does anybody remember when it was introduced into the > code and what kind of ideas were behind? > > Some reasons were given why it may not be a good idea: > > -the benefit of not having slow start on LANs is very small, i.e. some > milliseconds > > -it is not a conformant TCP feature, i.e. not allowed by TCP Congestion > Control (RFC2581) and is explicitly given in Known TCP Implementation > Problems (RFC2525) "2.1 No initial slow start" and "2.3 Uninitialized > CWND" > > -people may have the same subnet mask also over a slow PPP link. In this > case the effect of the huge initial window is quite bad, see for example > http://www.cs.Helsinki.FI/u/gurtov/papers/effect_of_delays_on_tcp_performance.pdf > > -in case of congestion on Ethernet, packets queues build up at the > network interfaces in hosts and agressive TCP start-up behaviour can > further increase congestion losses > > What are your thoughts on this? > > Andrei > > tcp_output.c: > > int ss_fltsz = 1; > SYSCTL_INT(_net_inet_tcp, OID_AUTO, slowstart_flightsize, CTLFLAG_RW, > &ss_fltsz, 1, "Slow start flight size"); > > int ss_fltsz_local = TCP_MAXWIN; /* something large */ > SYSCTL_INT(_net_inet_tcp, OID_AUTO, local_slowstart_flightsize, > CTLFLAG_RW, > &ss_fltsz_local, 1, "Slow start flight size for local networks"); > > [...] > if ( > in_localaddr(tp->t_inpcb->inp_faddr) > ) > tp->snd_cwnd = tp->t_maxseg * ss_fltsz_local; > else > tp->snd_cwnd = tp->t_maxseg * ss_fltsz; > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 18 3:56:17 2001 Delivered-To: freebsd-net@freebsd.org Received: from porsta.cs.Helsinki.FI (porsta.cs.Helsinki.FI [128.214.48.124]) by hub.freebsd.org (Postfix) with ESMTP id 7213837B422 for ; Wed, 18 Apr 2001 03:56:13 -0700 (PDT) (envelope-from gurtov@cs.Helsinki.FI) Received: from melkki.cs.Helsinki.FI (gurtov@melkki.cs.Helsinki.FI [128.214.48.122]) by porsta.cs.Helsinki.FI (8.8.8/8.8.8) with ESMTP id NAA28074; Wed, 18 Apr 2001 13:56:10 +0300 Date: Wed, 18 Apr 2001 13:56:10 +0300 (EET DST) From: Andrei Gurtov To: Luigi Rizzo Cc: , Subject: Re: initial congestion window In-Reply-To: <200104180633.IAA41452@info.iet.unipi.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org If there are no strong opinions supporting this feature, should we then ask the developers to set the default inital window to two segments when talking to local IPs? It would help to keep the image of FreeBSD as a 'conformant system' with regard to TCP specs. rgds, Andrei On Wed, 18 Apr 2001, Luigi Rizzo wrote: > Hi, > yes, FreeBSD is blasting the full socket buffer onto the net > when the destination is "local". > I think it was introduced when the T/TCP changes were committed, > it kind-of makes sense with T/TCP, but other than that > it is a very bad idea to have it on by default. > For one, in many nets including a 100/10 switch, or slow receivers, > it tends to cause an immediate loss on the first window of data > because of the overload at the switch or the receiver. > > cheers > luigi > > > > > Hi folks, > > > > At the last IETF meeting there were some debates around FreeBSD using a > > 16-KB initial congestion window in TCP when destination IP address is from > > the local subnet. Does anybody remember when it was introduced into the > > code and what kind of ideas were behind? > > > > Some reasons were given why it may not be a good idea: > > > > -the benefit of not having slow start on LANs is very small, i.e. some > > milliseconds > > > > -it is not a conformant TCP feature, i.e. not allowed by TCP Congestion > > Control (RFC2581) and is explicitly given in Known TCP Implementation > > Problems (RFC2525) "2.1 No initial slow start" and "2.3 Uninitialized > > CWND" > > > > -people may have the same subnet mask also over a slow PPP link. In this > > case the effect of the huge initial window is quite bad, see for example > > http://www.cs.Helsinki.FI/u/gurtov/papers/effect_of_delays_on_tcp_performance.pdf > > > > -in case of congestion on Ethernet, packets queues build up at the > > network interfaces in hosts and agressive TCP start-up behaviour can > > further increase congestion losses > > > > What are your thoughts on this? > > > > Andrei > > > > tcp_output.c: > > > > int ss_fltsz = 1; > > SYSCTL_INT(_net_inet_tcp, OID_AUTO, slowstart_flightsize, CTLFLAG_RW, > > &ss_fltsz, 1, "Slow start flight size"); > > > > int ss_fltsz_local = TCP_MAXWIN; /* something large */ > > SYSCTL_INT(_net_inet_tcp, OID_AUTO, local_slowstart_flightsize, > > CTLFLAG_RW, > > &ss_fltsz_local, 1, "Slow start flight size for local networks"); > > > > [...] > > if ( > > in_localaddr(tp->t_inpcb->inp_faddr) > > ) > > tp->snd_cwnd = tp->t_maxseg * ss_fltsz_local; > > else > > tp->snd_cwnd = tp->t_maxseg * ss_fltsz; > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > > Andrei To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 18 7:44:43 2001 Delivered-To: freebsd-net@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id D66A637B424 for ; Wed, 18 Apr 2001 07:44:37 -0700 (PDT) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id f3IEh9X09002; Wed, 18 Apr 2001 09:43:09 -0500 (CDT) (envelope-from jlemon) Date: Wed, 18 Apr 2001 09:43:09 -0500 (CDT) From: Jonathan Lemon Message-Id: <200104181443.f3IEh9X09002@prism.flugsvamp.com> To: gurtov@cs.Helsinki.FI, net@freebsd.org Subject: Re: initial congestion window X-Newsgroups: local.mail.freebsd-net In-Reply-To: References: Organization: Cc: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Actually, you could argue that both should be changed to 2-3 segments, see http://www.aciri.org/floyd/tcp_init_win.html -- Jonathan In article you write: > >If there are no strong opinions supporting this feature, should we then >ask the developers to set the default inital window to two segments when >talking to local IPs? It would help to keep the image of FreeBSD as a >'conformant system' with regard to TCP specs. > >rgds, >Andrei > >On Wed, 18 Apr 2001, Luigi Rizzo wrote: > >> Hi, >> yes, FreeBSD is blasting the full socket buffer onto the net >> when the destination is "local". >> I think it was introduced when the T/TCP changes were committed, >> it kind-of makes sense with T/TCP, but other than that >> it is a very bad idea to have it on by default. >> For one, in many nets including a 100/10 switch, or slow receivers, >> it tends to cause an immediate loss on the first window of data >> because of the overload at the switch or the receiver. >> >> cheers >> luigi >> >> > >> > Hi folks, >> > >> > At the last IETF meeting there were some debates around FreeBSD using a >> > 16-KB initial congestion window in TCP when destination IP address is from >> > the local subnet. Does anybody remember when it was introduced into the >> > code and what kind of ideas were behind? >> > >> > Some reasons were given why it may not be a good idea: >> > >> > -the benefit of not having slow start on LANs is very small, i.e. some >> > milliseconds >> > >> > -it is not a conformant TCP feature, i.e. not allowed by TCP Congestion >> > Control (RFC2581) and is explicitly given in Known TCP Implementation >> > Problems (RFC2525) "2.1 No initial slow start" and "2.3 Uninitialized >> > CWND" >> > >> > -people may have the same subnet mask also over a slow PPP link. In this >> > case the effect of the huge initial window is quite bad, see for example >> > >http://www.cs.Helsinki.FI/u/gurtov/papers/effect_of_delays_on_tcp_performance.pdf >> > >> > -in case of congestion on Ethernet, packets queues build up at the >> > network interfaces in hosts and agressive TCP start-up behaviour can >> > further increase congestion losses >> > >> > What are your thoughts on this? >> > >> > Andrei >> > >> > tcp_output.c: >> > >> > int ss_fltsz = 1; >> > SYSCTL_INT(_net_inet_tcp, OID_AUTO, slowstart_flightsize, CTLFLAG_RW, >> > &ss_fltsz, 1, "Slow start flight size"); >> > >> > int ss_fltsz_local = TCP_MAXWIN; /* something large */ >> > SYSCTL_INT(_net_inet_tcp, OID_AUTO, local_slowstart_flightsize, >> > CTLFLAG_RW, >> > &ss_fltsz_local, 1, "Slow start flight size for local networks"); >> > >> > [...] >> > if ( >> > in_localaddr(tp->t_inpcb->inp_faddr) >> > ) >> > tp->snd_cwnd = tp->t_maxseg * ss_fltsz_local; >> > else >> > tp->snd_cwnd = tp->t_maxseg * ss_fltsz; >> > >> > >> > >> > >> > To Unsubscribe: send mail to majordomo@FreeBSD.org >> > with "unsubscribe freebsd-net" in the body of the message >> > >> > >Andrei > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 18 8: 5:34 2001 Delivered-To: freebsd-net@freebsd.org Received: from mighty.grot.org (mighty.grot.org [216.15.97.5]) by hub.freebsd.org (Postfix) with ESMTP id 8363F37B422 for ; Wed, 18 Apr 2001 08:05:32 -0700 (PDT) (envelope-from lists@grot.org) Received: by mighty.grot.org (Postfix, from userid 998) id DA1855D10; Wed, 18 Apr 2001 08:05:31 -0700 (PDT) Date: Wed, 18 Apr 2001 08:05:31 -0700 From: Adi To: freebsd-net@freebsd.org Subject: ICMP echo measurement discrepancy Message-ID: <20010418080531.A35252@mighty.grot.org> Reply-To: lists@lists.grot.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have a SDSL 768K lightly loaded DSL circuit terminating on a Flowpoint 2200 SDSL router connected to an ethernet switch off of which I have 3 FreeBSD machines: ---768K SDSL---==[switch]===(FreeBSD machine) I also control the ISP end of the DSL circuit. Depending on the *line encapsulation of the SDSL circuit*, different programs running ICMP echo report different packet loss rates with otherwise the _exact_ same setup. If I run ping interactively on the command line, as in > ping -c 10 -n x where x is the ISP router interface or any other "remote" IP address from one of my FreeBSD machines, I see no packet loss, and it's been that way since the day the circuit was installed. To keep a historical measurement, I have a perl script that does the ping every 5 minutes and keeps it in an RRD much like mrtg. In the perl script I've used both a system call to fping or used Net::Ping. I currently prefer the latter, but the effects are the same. If the SDSL line encapsulation is set to PPP over ATM then I typically see no packet loss at all to a variety of sites and have measurements over 4-5 months to prove it. However, if I use fping or Net::Ping from a script, it reports packet loss quite "often" -- in fact fping seems to always report packet loss (I count the number of returned packets in it's case). The changes to the network are made over 1 hop away from any FreeBSD machines and the traffic levels have remained the same and ping interactively reports different results from 2 different programs run in the background...I'm befuddled. Any ideas (I could run ping in the background I suppose)? Thanks, Adi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 18 8:18:12 2001 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 5B4E037B42C for ; Wed, 18 Apr 2001 08:18:07 -0700 (PDT) (envelope-from larse@ISI.EDU) Received: from isi.edu (hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.2/8.11.2) with ESMTP id f3IFI6503752 for ; Wed, 18 Apr 2001 08:18:06 -0700 (PDT) Message-ID: <3ADDB02E.C56D461B@isi.edu> Date: Wed, 18 Apr 2001 08:18:06 -0700 From: Lars Eggert Organization: USC Information Sciences Institute X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en, de MIME-Version: 1.0 Cc: net@freebsd.org Subject: Re: initial congestion window References: <200104181443.f3IEh9X09002@prism.flugsvamp.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms6C1CF46104E76274E4508BD4" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a cryptographically signed message in MIME format. --------------ms6C1CF46104E76274E4508BD4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jonathan Lemon wrote: > Actually, you could argue that both should be changed to > 2-3 segments, see http://www.aciri.org/floyd/tcp_init_win.html To play with this setting, does this (in /etc/sysctl.conf) do the trick? Or does anything else need to be changed? net.inet.tcp.slowstart_flightsize=2 net.inet.tcp.local_slowstart_flightsize=2 -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California --------------ms6C1CF46104E76274E4508BD4 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIIIwYJKoZIhvcNAQcCoIIIFDCCCBACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BfQwggLYMIICQaADAgECAgMDIwUwDQYJKoZIhvcNAQEEBQAwgZQxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMQ8wDQYDVQQKEwZU aGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25h bCBGcmVlbWFpbCBSU0EgMTk5OS45LjE2MB4XDTAwMDgyNDIwMzAwOFoXDTAxMDgyNDIwMzAw OFowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVn Z2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEAz1yfcNs53rvhuw8gSDvr2+/snP8GduYY7x7WkJdyvcwb4oipNpWYIkMGP214 Zv1KrgvntGaG+jeugAGQt0n64VusgcIzQ6QDRtnMgdQDTAkVSQ2eLRSQka+nAPx6SFKJg79W EEHmgKQBMtZdMBYtYv/mTOcpm7jTJVg+7W6n04UCAwEAAaN3MHUwKgYFK2UBBAEEITAfAgEA MBowGAIBBAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1 MAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAUiKvxYINmVfTkWMdGHcBhvSPXw4wwDQYJKoZI hvcNAQEEBQADgYEAi65fM/jSCaPhRoA9JW5X2FktSFhE5zkIpFVPpv33GWPPNrncsK13HfZm s0B1rNy2vU7UhFI/vsJQgBJyffkLFgMCjp3uRZvBBjGD1q4yjDO5yfMMjquqBpZtRp5op3lT d01faA58ZCB5sxCb0ORSxvXR8tc9DJO0JIpQILa6vIAwggMUMIICfaADAgECAgELMA0GCSqG SIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYD VQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9D ZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29u YWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0 ZS5jb20wHhcNOTkwOTE2MTQwMTQwWhcNMDEwOTE1MTQwMTQwWjCBlDELMAkGA1UEBhMCWkEx FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxDzANBgNVBAoT BlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNv bmFsIEZyZWVtYWlsIFJTQSAxOTk5LjkuMTYwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB ALNpWpfU0BYLerXFXekhnCNyzRJMS/d+z8f7ynIk9EJSrFeV43theheE5/1yOTiUtOrtZaeS Bl694GX2GbuUeXZMPrlocHWEHPQRdAC8BSxPCQMXMcz0QdRyxqZd4ohEsIsuxE3x8NaFPmzz lZR4kX5A6ZzRjRVXjsJz5TDeRvVPAgMBAAGjNzA1MBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYD VR0jBBgwFoAUcknCczTGVfQLdnKBfnf0h+fGsg4wDQYJKoZIhvcNAQEEBQADgYEAa8ZZ6TH6 6bbssQPY33Jy/pFgSOrGVd178GeOxmFw523CpTfYnbcXKFYFi91cdW/GkZDGbGZxE9AQfGuR b4bgITYtwdfqsgmtzy1txoNSm/u7/pyHnfy36XSS5FyXrvx+rMoNb3J6Zyxrc/WG+Z31AG70 HQfOnZ6CYynvkwl+Vd4xggH3MIIB8wIBATCBnDCBlDELMAkGA1UEBhMCWkExFTATBgNVBAgT DFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxDzANBgNVBAoTBlRoYXd0ZTEd MBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVt YWlsIFJTQSAxOTk5LjkuMTYCAwMjBTAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAxMDQxODE1MTgwNlowIwYJKoZIhvcNAQkEMRYE FMqeJyDEkEMLyoadTxf/M2komtalMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0G CSqGSIb3DQEBAQUABIGAFed+VUco6XTROQADSUdTg1u33M9/WUcdw3acP7gi5ryIxpD/nd+m Zdoel4Bs16HLAHMJGDRWrwGNWeeyfMT/dB6d6PMnDZJ20rCvsu/a57QcXTIoAJuLGtAPnrJH x3X0AIowOCGBodcVV3kPHPqavfEy8cIJ1n8bp7UnNWQevAM= --------------ms6C1CF46104E76274E4508BD4-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 18 9:24:54 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 39FA137B422 for ; Wed, 18 Apr 2001 09:24:51 -0700 (PDT) (envelope-from justin@mac.com) Received: from lilith ([65.11.111.111]) by femail1.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010418162421.SKDH24191.femail1.sdc1.sfba.home.com@lilith> for ; Wed, 18 Apr 2001 09:24:21 -0700 Date: Wed, 18 Apr 2001 09:23:53 -0700 Content-Type: text/plain; format=flowed; charset=us-ascii X-Mailer: Apple Mail (2.379) From: Justin C.Walker To: Mime-Version: 1.0 (Apple Message framework v379) In-Reply-To: Subject: Re: three nics, two networks, simple routing problem... Content-Transfer-Encoding: 7bit Message-Id: <20010418162421.SKDH24191.femail1.sdc1.sfba.home.com@lilith> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org You have one subnet (10.30.1/24) accessible through two interfaces. That causes the kernel 'cognitive dissonance' :-}. Regards, Justin On Tuesday, April 17, 2001, at 07:07 AM, Peter Brezny wrote: > The excerpt from my rc.conf mostly illustrates what I'm trying to do. I > want to connect a host (10.30.1.15) to xl1 So that I can partition it's > traffic from that of the lan connected to xl2. > > 10.30.1.1 GW----xl0 10.30.1.30 FW xl2----10.20.30.1 LAN > | > xl1 > | > | > 10.30.1.15 FW ----- 10.20.15.1 LAN Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Director of Technology | Men are from Earth Nexsi Corp. | Women are from Earth 1959 Concourse Drive | Deal with it. 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 Wed Apr 18 12:45:22 2001 Delivered-To: freebsd-net@freebsd.org Received: from mx.databus.com (p101-44.acedsl.com [160.79.101.44]) by hub.freebsd.org (Postfix) with ESMTP id 7D53E37B422 for ; Wed, 18 Apr 2001 12:45:20 -0700 (PDT) (envelope-from barney@mx.databus.com) Received: (from barney@localhost) by mx.databus.com (8.11.3/8.11.3) id f3IJivD58575; Wed, 18 Apr 2001 15:44:57 -0400 (EDT) (envelope-from barney) Date: Wed, 18 Apr 2001 15:44:57 -0400 From: Barney Wolff To: Adi Cc: freebsd-net@FreeBSD.ORG Subject: Re: ICMP echo measurement discrepancy Message-ID: <20010418154457.A58540@mx.databus.com> References: <20010418080531.A35252@mighty.grot.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20010418080531.A35252@mighty.grot.org>; from lists@lists.grot.org on Wed, Apr 18, 2001 at 08:05:31AM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org How many packets does fping send in a burst? Perhaps it's too many for the router or switch to buffer, and they're getting dropped before ever leaving your site. Your host can send them far faster than they can be transmitted over the sdsl link. Barney Wolff On Wed, Apr 18, 2001 at 08:05:31AM -0700, Adi wrote: > I have a SDSL 768K lightly loaded DSL circuit terminating on a Flowpoint 2200 > SDSL router connected to an ethernet switch off of which I have 3 FreeBSD > machines: > > ---768K SDSL---==[switch]===(FreeBSD machine) > > I also control the ISP end of the DSL circuit. Depending on the *line > encapsulation of the SDSL circuit*, different programs running ICMP echo > report different packet loss rates with otherwise the _exact_ same setup. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 18 14:53:58 2001 Delivered-To: freebsd-net@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id 7B5FB37B43E for ; Wed, 18 Apr 2001 14:53:56 -0700 (PDT) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id f3ILqPA24376; Wed, 18 Apr 2001 16:52:25 -0500 (CDT) (envelope-from jlemon) Date: Wed, 18 Apr 2001 16:52:25 -0500 (CDT) From: Jonathan Lemon Message-Id: <200104182152.f3ILqPA24376@prism.flugsvamp.com> To: larse@ISI.EDU, net@freebsd.org Subject: Re: initial congestion window X-Newsgroups: local.mail.freebsd-net In-Reply-To: References: Organization: Cc: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article you write: >-=-=-=-=-=- > >Jonathan Lemon wrote: >> Actually, you could argue that both should be changed to >> 2-3 segments, see http://www.aciri.org/floyd/tcp_init_win.html > >To play with this setting, does this (in /etc/sysctl.conf) do the trick? Or >does anything else need to be changed? > >net.inet.tcp.slowstart_flightsize=2 >net.inet.tcp.local_slowstart_flightsize=2 That's all that should be needed. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 18 19:57:11 2001 Delivered-To: freebsd-net@freebsd.org Received: from spyder.bytecraft.au.com (bytecr1.lnk.telstra.net [139.130.142.13]) by hub.freebsd.org (Postfix) with ESMTP id 48ACC37B422 for ; Wed, 18 Apr 2001 19:56:59 -0700 (PDT) (envelope-from taylorm@bytecraft.au.com) Received: by spyder.bytecraft.au.com (Postfix, from userid 1001) id 1161FBA27; Thu, 19 Apr 2001 12:56:57 +1000 (EST) To: freebsd-net@freebsd.org Subject: Routing on an aliased IP?? Message-Id: <20010419025657.1161FBA27@spyder.bytecraft.au.com> Date: Thu, 19 Apr 2001 12:56:57 +1000 (EST) From: taylorm@bytecraft.au.com (User Taylorm) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have a host with two external interfaces - ng0 and fxp0 The system default route is ok via ng0 The fxp0 card has a 10.x.y.z address and a 'real' IP address a.b.c.1 aliased to it. The reasoning is that the 10 network is our existing M$lop addresses, and the real IP is the internet web site. (We will eventually be renumbering the Micro$lop hosts to a.b.c.??? numbers soon, at which time I expect this problem to go away) The problem I am seeing is that there does not seem to be a route from the 10 net to the a.b.c net. The DNS server is on the a.b.c.1 host and only serves a.b.c IPs. The Win hosts have a gateway set up to point to the 10.x.y.z address, yet cant ping the a.b.c address range. If I reconfigure the Win host to have a a.b.c number then it can ping other a.b.c numbers but cant ping 10. numbers! From the actual FreeSD host I can ping both 10 net and a.b.c numbers. Do I need to have separate interfaces for routing between the networks, or is there something else I can do? 75.871/3.705 ms spyder# netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default r.s.t.1 UGSc 25 71376 ng0 10.1/16 link#1 UC 0 0 fxp0 => 10.1.2.2 0:0:f8:78:97:b7 UHLW 1 6639 fxp0 1084 10.1.2.3 0:0:f8:1e:ad:9e UHLW 0 1263 fxp0 1181 10.1.2.4 0:60:67:70:af:22 UHLW 0 528 fxp0 1004 10.1.2.5 0:60:67:44:18:10 UHLW 0 0 fxp0 1188 10.1.2.7 0:60:67:70:ac:4e UHLW 1 4766 fxp0 1181 10.1.2.22 link#1 UHLW 1 8 fxp0 => 10.1.2.30 0:50:8b:f1:de:df UHLW 1 956 lo0 10.1.2.32 0:50:8b:f1:ec:37 UHLW 0 4 fxp0 261 10.1.2.46 link#1 UHLW 1 1668 fxp0 => 10.1.2.47 0:0:4c:33:d8:cd UHLW 1 43 fxp0 1096 10.1.2.129 0:10:5a:81:b0:30 UHLW 1 902 fxp0 1183 10.1.255.255 ff:ff:ff:ff:ff:ff UHLWb 2 8417 fxp0 127.0.0.1 127.0.0.1 UH 0 900 lo0 r.s.t.1 r.s.t.13 UH 25 0 ng0 a.b.c.0 ff:ff:ff:ff:ff:ff UHLWb 0 44 fxp0 => a.b.c/26 link#1 UC 0 0 fxp0 => a.b.c.1 0:50:8b:f1:de:df UHLW 0 79 lo0 a.b.c.42 0:0:4c:ed:78:5e UHLW 3 2494 fxp0 1195 a.b.c.63 ff:ff:ff:ff:ff:ff UHLWb 0 4 fxp0 spyder# ping a.b.c.42 PING a.b.c.42 (a.b.c.42): 56 data bytes 64 bytes from a.b.c.42: icmp_seq=0 ttl=128 time=0.237 ms 64 bytes from a.b.c.42: icmp_seq=1 ttl=128 time=0.256 ms ^C --- a.b.c.42 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.237/0.246/0.256/0.010 ms spyder# ping 10.1.2.4 PING 10.1.2.4 (10.1.2.4): 56 data bytes 64 bytes from 10.1.2.4: icmp_seq=0 ttl=128 time=0.275 ms 64 bytes from 10.1.2.4: icmp_seq=1 ttl=128 time=0.138 ms 64 bytes from 10.1.2.4: icmp_seq=2 ttl=128 time=0.127 ms ^C --- 10.1.2.4 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.127/0.180/0.275/0.067 ms spyder# TIA Murray T To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 18 21:11:47 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 6B23137B43E for ; Wed, 18 Apr 2001 21:11:39 -0700 (PDT) (envelope-from gunther@aurora.regenstrief.org) Received: from aurora.regenstrief.org (aurora.rg.iupui.edu [134.68.31.122]) by rgmail.regenstrief.org (8.11.0/8.8.7) with ESMTP id f3J4CNA22572; Wed, 18 Apr 2001 23:12:23 -0500 Message-ID: <3ADE656D.3A0BDD0@aurora.regenstrief.org> Date: Thu, 19 Apr 2001 04:11:25 +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: snap-users@kame.net, freebsd-net@freebsd.org Subject: KAME SPD bug, please try and confirm ... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [Sorry I resend this because it seems as if my subject line was turning everyone off from looking at this.] Below is what could be a cookbook recipe for IPsec tunnels. However, unfortunately it's a bug report. I would like some of you to try this out and confirm the problem for me, may be find the error on my part, or make suggestions on how to work around this problem. If you have an older KAME release, you may not see this bug instantaneously, instead you will notice a kernel panic when running the network for some time under higher load (~ 2 Mb/s). On KAME-SNAP as of last March no kernel panic occurs but this problem can be seen instantaneously. Here is how it goes: You need three machines A and B, and C. We begin with A and B: On machine A run: if=ed0 aip=10.10.10.1 bip=10.10.10.2 aipsec=10.99.10 bipsec=10.99.20 ifconfig ${if} inet alias ${aip} netmask 0xffffff00 ifconfig lo0 inet alias ${aipsec}.1 netmask 0xffffff00 route add -net ${bipsec}.0/24 ${aipsec}.1 setkey -c < 10.10.10.3: ESP(spi=2000,seq=0x14) 19:51:30.945915 10.10.10.3 > 10.10.10.1: ESP(spi=2001,seq=0x24) 19:51:31.953169 10.10.10.1 > 10.10.10.3: ESP(spi=2000,seq=0x15) 19:51:31.953300 10.10.10.3 > 10.10.10.1: ESP(spi=2001,seq=0x25) as it should, and remember, the C-tunnel works now. Let's go to B and ping ${aipsec}.1 tcpdump shows: 19:55:21.963950 10.10.10.2 > 10.10.10.1: ESP(spi=1001,seq=0x42) 19:55:22.975435 10.10.10.2 > 10.10.10.1: ESP(spi=1001,seq=0x43) see how A never sends an icmp echo reply? It is because it never gets the icmp messages to the upper layer. Instead netstat -s -p ip ip: 2313 total packets received 0 bad header checksums 0 with size smaller than minimum 0 with data size < data length 0 with ip length > max ip packet size 0 with header length < data size 0 with data length < header length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 packets reassembled ok 2033 packets for this host >>>>>> 267 packets for unknown/unsupported protocol 0 packets forwarded (0 packets fast forwarded) 0 packets not forwardable 13 packets received for unknown multicast group 0 redirects sent 1374 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 0 output packets discarded due to no route 0 output datagrams fragmented 0 fragments created 0 datagrams that can't be fragmented 0 tunneling packets that can't find gif 0 datagrams with bad address in header As you see, the unknown/unsupported protocol counter goes up with every icmp request sent. But, the "packets for this host" counter doen not go up. This means, the packets are not even seen as belonging to this host!!! Now let's turn this around once again. Disabling SPD entries for C and you'll see how B comes back on line: setkey -c <; Wed, 18 Apr 2001 22:14:08 -0700 (PDT) (envelope-from lists@grot.org) Received: by mighty.grot.org (Postfix, from userid 998) id 092CD5D10; Wed, 18 Apr 2001 22:14:08 -0700 (PDT) Date: Wed, 18 Apr 2001 22:14:07 -0700 From: Adi To: Barney Wolff Cc: freebsd-net@freebsd.org Subject: Re: ICMP echo measurement discrepancy Message-ID: <20010418221407.A38525@mighty.grot.org> Reply-To: lists@lists.grot.org References: <20010418080531.A35252@mighty.grot.org> <20010418154457.A58540@mx.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010418154457.A58540@mx.databus.com>; from barney@databus.com on Wed, Apr 18, 2001 at 03:44:57PM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Oops, I rearranged some text in my original message and left out the bit that said that I see packet loss when the SDSL line encapsulation is set to be bridged ethernet over ATM (RFC1483). That said, I power-cycled my router and the packet loss seems to have gone away (herring. red.) However, I have a different problem and this persists despite the power-cycle -- if I use nmap -sT to initiate a TCP port scan, it succeeds on local hosts (the router is running NAT) but not on "remote" hosts. If I run tcpdump I see the SYN's going out but no ACK's coming back...in fact nothing comes back...very odd as other tcp connections work fine, with the SDSL encapsulation set to bridged or PPPoATM. Somehow, because the line encapsulation is set to bridging, Adi On Wed, Apr 18, 2001 at 03:44:57PM -0400, Barney Wolff wrote: > How many packets does fping send in a burst? Perhaps it's too many > for the router or switch to buffer, and they're getting dropped > before ever leaving your site. Your host can send them far faster > than they can be transmitted over the sdsl link. > > Barney Wolff > > On Wed, Apr 18, 2001 at 08:05:31AM -0700, Adi wrote: > > I have a SDSL 768K lightly loaded DSL circuit terminating on a Flowpoint 2200 > > SDSL router connected to an ethernet switch off of which I have 3 FreeBSD > > machines: > > > > ---768K SDSL---==[switch]===(FreeBSD machine) > > > > I also control the ISP end of the DSL circuit. Depending on the *line > > encapsulation of the SDSL circuit*, different programs running ICMP echo > > report different packet loss rates with otherwise the _exact_ same setup. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 19 0:19:13 2001 Delivered-To: freebsd-net@freebsd.org Received: from spyder.bytecraft.au.com (bytecr1.lnk.telstra.net [139.130.142.13]) by hub.freebsd.org (Postfix) with ESMTP id D2D3237B424 for ; Thu, 19 Apr 2001 00:19:01 -0700 (PDT) (envelope-from root@bytecraft.au.com) Received: by spyder.bytecraft.au.com (Postfix, from userid 0) id 4D7BEBA27; Thu, 19 Apr 2001 17:19:00 +1000 (EST) To: freebsd-net@freebsd.org Subject: MPD setup problem Message-Id: <20010419071900.4D7BEBA27@spyder.bytecraft.au.com> Date: Thu, 19 Apr 2001 17:19:00 +1000 (EST) From: root@bytecraft.au.com (Charlie Root) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Help ... What am I missing? Given the attached mpd.conf & mpd.links files I create the following netgraph. There is an obvious ommission here.... there is no input to the ppp node ID 0000003f. I am running a netgraph frame relay interface as ng0. The mpd files create a ng1 node OK, but ngctl shows no inputs to the ppp node. The full map (frame and mpd) that develops is as follows _FRAME RELAY INTERFACE_ [ sync_sr0 ] [ ](dlci0) ------ (annexD)[ ] [ ](rawdata) ------- [ ] [ ] [ 00000001 ] [ 00000004 ] [ 00000006 ] [ sync_sr ] [ frame_relay ](dlci16) ----+ [ lmi ] | | +--------------------------------------+ | | +---- (rawdata)[ ] [ ng0 ] [ ](inet) --------- (inet)[ ] [ 00000008 ] [ 0000000a ] [ rfc1490 ] [ iface ] ip addr w.x.y.z _MPD INTERFACE_ [ mpd47081-frame- ](vjc_vjip) -------------- (vjip)[ ] [ ](vjc_vjuncomp) ------ (vjuncomp)[ ] [ ](vjc_vjcomp) ---------- (vjcomp)[ 00000041 ] [ ](vjc_ip) ------------------ (ip)[ vjc ] [ 000003f ](inet) ---------+ [ ppp ](bypass) ---+ | | | | | +------------------------------------+ | | +--- (ppp)[ ] | [ ](iface) ----+ +--- (bypass)[ ](demand) ---------- (mpd)[ 00000040 ] | [ ] [ bpf ] | [ 0000003d ] | [ socket ] | +-----------------------+ | | [ ng1 ] +-------- (inet)[ ] [ 0000003e ] [ iface ] Interface ng0 is IP address w.x.y.z and is the end of hte frame relay point-to-point link to the internet. The address a.b.c.d used in 'set pptp self a.b.c.d' is the registered IP of spyder on its fxp0 interface. This is the IP address of the target name used in the M$oft DUN VPN setup. The files ################################################################# # # MPD configuration file # # This file defines the configuration for mpd: what the # bundles are, what the links are in those bundles, how # the interface should be configured, various PPP parameters, # etc. It contains commands just as you would type them # in at the console. A blank line ends an entry. Lines # starting with a "#" are comments and get completely # ignored. # ################################################################# # # Default configuration is "pptp1" default: load pptp1 # # mpd as a PPTP server for M$ dial up networking clients # pptp1: new -i ng1 frame-pptp frame-pptp set iface disable on-demand set iface enable proxy-arp set iface idle 1800 set bundle disable multilink # set bundle authname taylorm set log pptp3 set link yes acfcomp protocomp set link no pap chap set link enable chap set link keep-alive 10 60 set ipcp yes vjcomp # require server to be .176 and remote laptop user to be .180 set ipcp ranges 10.1.2.176/32 10.1.2.180/32 # our dns server # set ipcp dns 10.1.2.52 # our WINS servers set ipcp nbns 10.1.2.3 10.1.2.7 # # The five lines below enable Microsoft Point-to-Point encryption # (MPPE) using the ng_mppc(8) netgraph node type. # set bundle enable compression set ccp yes mppc set ccp yes mpp-e40 set ccp yes mpp-e128 set ccp yes mpp-stateless ################################################################# # # MPD links file # # In this file you define the various "links" that comprise # a bundle. Each link corresponds to a single serial device. # These are commands that could be typed into the console directly. # # This file should only contain configuration for a link if # that configuration is specific to that particular link. That # is, things like device name and bandwidth. Other generic link # options # like LCP paramters belong in "mpd.conf". # # The first command for each link should be "set link type ..." # ################################################################# # # Analog modem on COM1. # not in use yet modem: set link type modem set modem device /dev/cuaa0 # # For our PPTP server # frame-pptp: set link type pptp set pptp self a.b.c.d set pptp enable incoming set pptp disable originate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 19 2:11:39 2001 Delivered-To: freebsd-net@freebsd.org Received: from porsta.cs.Helsinki.FI (porsta.cs.Helsinki.FI [128.214.48.124]) by hub.freebsd.org (Postfix) with ESMTP id 2A21637B423 for ; Thu, 19 Apr 2001 02:11:33 -0700 (PDT) (envelope-from gurtov@cs.Helsinki.FI) Received: from saviletto.cs.Helsinki.FI (gurtov@saviletto.cs.Helsinki.FI [128.214.9.225]) by porsta.cs.Helsinki.FI (8.8.8/8.8.8) with ESMTP id MAA07892; Thu, 19 Apr 2001 12:11:25 +0300 Date: Thu, 19 Apr 2001 12:11:25 +0300 (EET DST) From: Andrei Gurtov To: Jonathan Lemon Cc: , Subject: Re: initial congestion window In-Reply-To: <200104181443.f3IEh9X09002@prism.flugsvamp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I think the default initial window of two segments both for local and non-local connections is the best option now. Larger initial windows of three and four segments are still in experimental stage and should not be widely deployed yet (although it is nice to play with them in different environments to see what effect does it have). Andrei On Wed, 18 Apr 2001, Jonathan Lemon wrote: > Actually, you could argue that both should be changed to > 2-3 segments, see http://www.aciri.org/floyd/tcp_init_win.html > -- > Jonathan > > In article you write: > > > >If there are no strong opinions supporting this feature, should we then > >ask the developers to set the default inital window to two segments when > >talking to local IPs? It would help to keep the image of FreeBSD as a > >'conformant system' with regard to TCP specs. > > > >rgds, > >Andrei > > > >On Wed, 18 Apr 2001, Luigi Rizzo wrote: > > > >> Hi, > >> yes, FreeBSD is blasting the full socket buffer onto the net > >> when the destination is "local". > >> I think it was introduced when the T/TCP changes were committed, > >> it kind-of makes sense with T/TCP, but other than that > >> it is a very bad idea to have it on by default. > >> For one, in many nets including a 100/10 switch, or slow receivers, > >> it tends to cause an immediate loss on the first window of data > >> because of the overload at the switch or the receiver. > >> > >> cheers > >> luigi > >> > >> > > >> > Hi folks, > >> > > >> > At the last IETF meeting there were some debates around FreeBSD using a > >> > 16-KB initial congestion window in TCP when destination IP address is from > >> > the local subnet. Does anybody remember when it was introduced into the > >> > code and what kind of ideas were behind? > >> > > >> > Some reasons were given why it may not be a good idea: > >> > > >> > -the benefit of not having slow start on LANs is very small, i.e. some > >> > milliseconds > >> > > >> > -it is not a conformant TCP feature, i.e. not allowed by TCP Congestion > >> > Control (RFC2581) and is explicitly given in Known TCP Implementation > >> > Problems (RFC2525) "2.1 No initial slow start" and "2.3 Uninitialized > >> > CWND" > >> > > >> > -people may have the same subnet mask also over a slow PPP link. In this > >> > case the effect of the huge initial window is quite bad, see for example > >> > > >http://www.cs.Helsinki.FI/u/gurtov/papers/effect_of_delays_on_tcp_performance.pdf > >> > > >> > -in case of congestion on Ethernet, packets queues build up at the > >> > network interfaces in hosts and agressive TCP start-up behaviour can > >> > further increase congestion losses > >> > > >> > What are your thoughts on this? > >> > > >> > Andrei > >> > > >> > tcp_output.c: > >> > > >> > int ss_fltsz = 1; > >> > SYSCTL_INT(_net_inet_tcp, OID_AUTO, slowstart_flightsize, CTLFLAG_RW, > >> > &ss_fltsz, 1, "Slow start flight size"); > >> > > >> > int ss_fltsz_local = TCP_MAXWIN; /* something large */ > >> > SYSCTL_INT(_net_inet_tcp, OID_AUTO, local_slowstart_flightsize, > >> > CTLFLAG_RW, > >> > &ss_fltsz_local, 1, "Slow start flight size for local networks"); > >> > > >> > [...] > >> > if ( > >> > in_localaddr(tp->t_inpcb->inp_faddr) > >> > ) > >> > tp->snd_cwnd = tp->t_maxseg * ss_fltsz_local; > >> > else > >> > tp->snd_cwnd = tp->t_maxseg * ss_fltsz; > >> > > >> > > >> > > >> > > >> > To Unsubscribe: send mail to majordomo@FreeBSD.org > >> > with "unsubscribe freebsd-net" in the body of the message > >> > > >> > > > >Andrei > > > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org > >with "unsubscribe freebsd-net" in the body of the message > > > > Andrei To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 19 5:46:52 2001 Delivered-To: freebsd-net@freebsd.org Received: from caligula.anu.edu.au (caligula.anu.edu.au [150.203.224.42]) by hub.freebsd.org (Postfix) with ESMTP id 5CCA137B424; Thu, 19 Apr 2001 05:46:44 -0700 (PDT) (envelope-from avalon@caligula.anu.edu.au) Received: (from avalon@localhost) by caligula.anu.edu.au (8.9.3/8.9.3) id WAA14999; Thu, 19 Apr 2001 22:46:20 +1000 (EST) From: Darren Reed Message-Id: <200104191246.WAA14999@caligula.anu.edu.au> Subject: Re: non-random IP IDs To: geniusj@bluenugget.net (Jason DiCioccio) Date: Thu, 19 Apr 2001 22:46:19 +1000 (Australia/ACT) Cc: avalon@coombs.anu.edu.au (Darren Reed), bright@wintelcom.net (Alfred Perlstein), freebsd-security@FreeBSD.ORG, net@FreeBSD.ORG In-Reply-To: <004201c0c783$7fe71df0$4904a8c0@epylon.lan> from "Jason DiCioccio" at Apr 17, 2001 02:15:15 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In some mail from Jason DiCioccio, sie said: > > From: "Darren Reed" > Subject: Re: non-random IP IDs > > > > How long has your box been up ? How many changes to the system config > > have been made since then ? If you're not there, and it reboots, will > > it come up 100% functional ? Do your computers need some amount of > > preventative maintenance like internal cleaning to deal with dust build > > up, etc ? > > I don't know very many if any people that take their machines off the rack > just to clean dust out of the case. > > > How many times do unscheduled reboots result in hardware not > > spinning back up and at an inconevient time ? > > This would happen regardless of when/if you rebooted it. If you plan for these events (usually outside business hours) then it is generally less painful to deal with them. [...] > > None of my personal boxes have uptimes that ever exceed 6 months, even > my > > servers, but I have complete confidence in them rebooting and services > being > > restarted (modulo file system damage from an unclean shutdown). > > softupdates should take care of this, and as far as HD trouble, if you're > system is really that important then mirror your disks. Really ? Darren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Apr 20 11:55:17 2001 Delivered-To: freebsd-net@freebsd.org Received: from black.purplecat.net (ns1.purplecat.net [209.16.228.148]) by hub.freebsd.org (Postfix) with ESMTP id B9FC437B42C for ; Fri, 20 Apr 2001 11:55:11 -0700 (PDT) (envelope-from peter@black.purplecat.net) Received: from localhost (peter@localhost) by black.purplecat.net (8.8.8/8.8.8) with ESMTP id OAA07609 for ; Fri, 20 Apr 2001 14:57:36 -0400 (EDT) (envelope-from peter@black.purplecat.net) Date: Fri, 20 Apr 2001 14:57:36 -0400 (EDT) From: Peter Brezny To: freebsd-net@freebsd.org Subject: dual dns weirdness, DNS/bind guru needed. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I've managed to get two different instances of bind running on my primary name server, but there's something weird. Since I've gotten them running. I can't ftp to anything from the box, or even ftp through that box if a client is using it as a gateway, yet nslookup appears to work fine. my resolv.conf file shows the loopback as the name server to use, and the internal instance is configured to listen on the loopback, which it does if you run nslookup ( see below ). I also continue to be rejected by the freebsd.org mail and ftp servers due to something they don't like about the dns of virtual2.sysadmin-inc.com. I've even downloaded the djbdns tools package and used their dnstrace utility to try and find the problem, with no luck. I've attached errors and config files. Any ideas on this one? Thanks in advance. Apr 20 14:48:14 virtual2 qmail: 987792494.040993 delivery 167: deferral: 216.136.204.18_does_not_like_recipient./Remote_host_said:_450_Client_host _rejected:_cannot_find_your_hostname,_[209.16.228.145]/Giving_up_on _216.136.204.18./ ftp: purplecat.net: Non-recoverable failure in name resolution ftp> virtual2# nslookup Default Server: localhost.sysadmin-inc.com Address: 127.0.0.1 > purplecat.net Server: localhost.sysadmin-inc.com Address: 127.0.0.1 Non-authoritative answer: Name: purplecat.net Address: 209.16.228.148 virtual2# vi /etc/resolv.conf domain sysadmin-inc.com nameserver 127.0.0.1 internal named.conf options section. // $FreeBSD: src/etc/namedb/named.conf,v 1.6.2.1 2000/07/15 07:49:29 kris Exp $ options { listen-on { 10.10.1.2; 10.30.1.1; 127.0.0.1; }; directory "/usr/local/etc/namedb-int"; forwarders { 209.16.228.145; }; allow-transfer { 10.10.1.1; //virtual 10.10.1.71; //bsd1 10.10.1.21; //wcsslaw 10.10.1.25; //allsouls 10.30.1.14; //dggw 10.30.1.20; //gkgw 10.30.1.30; }; //cumcgw allow-query { 10.0.0.0/8; 127.0.0.1; }; query-source address 10.10.1.2 port 53; transfer-source 10.10.1.2; dump-file "s/named_dump.db"; pid-file "s/named.pid"; }; //end of options controls { unix "/var/run/ndc-internal" perm 0660 owner 0 group 53; }; External named.conf options section. // $FreeBSD: src/etc/namedb/named.conf,v 1.6.2.1 2000/07/15 07:49:29 kris Exp $ options { directory "/etc/namedb"; forwarders { 207.230.75.34; //ns1.deltacom.net 207.230.75.50; //ns2.deltacom.net 206.191.128.46; //c2901.wa.net 199.166.24.1; }; //ns1.vrx.net allow-transfer { 209.16.228.140; //virtual/ns2 209.16.228.150; //virtual alias 209.16.228.145; //virtual2 209.16.228.146; //bsd1 209.16.228.141; //sas 209.16.228.142; //sas 208.133.43.7; //available.New-Era.net 207.230.75.34; //ns1.deltacom.net // potentially bogus? 204.181.41.4; //ns1.deltacom.net * 207.230.75.50; }; //ns2.deltacom.net query-source address 209.16.228.145 port 53; transfer-source 209.16.228.145; listen-on { 209.16.228.145; 209.16.228.150; }; dump-file "s/named_dump.db"; pid-file "s/named.pid"; }; //end of options controls { unix "/var/run/ndc-external" perm 0660 owner 0 group 53; }; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Apr 20 12:50:39 2001 Delivered-To: freebsd-net@freebsd.org Received: from ns2.myway.com.br (ns2.myway.com.br [200.186.239.2]) by hub.freebsd.org (Postfix) with SMTP id BB9FC37B43C; Fri, 20 Apr 2001 12:50:34 -0700 (PDT) (envelope-from leal@myway.com.br) Received: from sup02 (unverified [200.186.239.5]) by ns2.myway.com.br (EMWAC SMTPRS 0.83) with SMTP id ; Fri, 20 Apr 2001 16:48:17 -0300 Message-ID: <008501c0c9d2$cee98720$1400000a@myway.com.br> From: "leal" To: Cc: References: Subject: right Date: Fri, 20 Apr 2001 16:47:51 -0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Antirelay: Good relay from local net2 200.186.239.0/24 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I believe that this question is pertinent in this forum. I have some wireless-lan's interconected with my principal lan that have internet access. Without visible answers, all my wireless-lan is with the traffic terrible!!! lost more lost. 50%, 75% of losses, this started more or less two days. i know tcpdump, how i use it??? i wanna help for debbug my network, looking for worms, viruses, i don't know... and i'm in panic. software??? how can i debbug and looking for bug's??? please... thanks :O) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Apr 20 13:19:29 2001 Delivered-To: freebsd-net@freebsd.org Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by hub.freebsd.org (Postfix) with ESMTP id C009037B43E for ; Fri, 20 Apr 2001 13:19:26 -0700 (PDT) (envelope-from oberman@ptavv.es.net) Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (8.10.1/8.10.1) with ESMTP id f3KKJNc07968; Fri, 20 Apr 2001 13:19:23 -0700 (PDT) Message-Id: <200104202019.f3KKJNc07968@ptavv.es.net> To: "leal" Cc: freebsd-net@FreeBSD.ORG Subject: Re: right In-reply-to: Your message of "Fri, 20 Apr 2001 16:47:51 -0300." <008501c0c9d2$cee98720$1400000a@myway.com.br> Date: Fri, 20 Apr 2001 13:19:23 -0700 From: "Kevin Oberman" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > From: "leal" > Date: Fri, 20 Apr 2001 16:47:51 -0300 > Sender: owner-freebsd-net@FreeBSD.ORG > > I believe that this question is pertinent in this forum. I have some > wireless-lan's interconected with my principal lan that have internet > access. Without visible answers, all my wireless-lan is with the traffic > terrible!!! lost more lost. 50%, 75% of losses, this started more or less > two days. i know tcpdump, how i use it??? i wanna help for debbug my > network, looking for worms, viruses, i don't know... and i'm in panic. > software??? how can i debbug and looking for bug's??? Before looking at packet dumps, look at interface errors. They may give you a hint. Usually large magnitude losses are the result of an auto-configuration failure that leaves one end of a connection running full-duplex while the other is half-duplex. The full-duplex end will have no collisions (by definition) but will have a lot of other errors. The half-duplex will probably also have a large number of errors, but will also show many collisions. The other thing to look for is bad interconnects. Damaged or poorly crimped cables are a source of these problems. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Apr 20 14:53:28 2001 Delivered-To: freebsd-net@freebsd.org Received: from cessium.prosolve.com (gw.prosolve.com [63.225.188.140]) by hub.freebsd.org (Postfix) with ESMTP id 7951137B43E for ; Fri, 20 Apr 2001 14:53:21 -0700 (PDT) (envelope-from SeanM@prosolve.com) Received: from fs01.prosolve.com (fs01.prosolve.com [172.16.128.50]) by cessium.prosolve.com (8.11.1/8.11.1) with ESMTP id f3KLrDi58645; Fri, 20 Apr 2001 14:53:13 -0700 (PDT) Received: by fs01.prosolve.com with Internet Mail Service (5.5.2650.21) id <28Z1MG4G>; Fri, 20 Apr 2001 14:53:13 -0700 Message-ID: From: Sean Mathias To: "'Peter Brezny'" Cc: "'freebsd-net@FreeBSD.ORG'" Subject: RE: dual dns weirdness, DNS/bind guru needed. Date: Fri, 20 Apr 2001 14:53:08 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Does the internal instance forward to the external instance to resolve external requests? Otherwise it can only resolve what you publish on the internal instance. As far as any site rejecting you, that is typicall due to not being able to perform a reverse lookup on your system IP address. -----Original Message----- From: Peter Brezny [mailto:peter@black.purplecat.net] Sent: Friday, April 20, 2001 11:58 AM To: freebsd-net@FreeBSD.ORG Subject: dual dns weirdness, DNS/bind guru needed. I've managed to get two different instances of bind running on my primary name server, but there's something weird. Since I've gotten them running. I can't ftp to anything from the box, or even ftp through that box if a client is using it as a gateway, yet nslookup appears to work fine. my resolv.conf file shows the loopback as the name server to use, and the internal instance is configured to listen on the loopback, which it does if you run nslookup ( see below ). I also continue to be rejected by the freebsd.org mail and ftp servers due to something they don't like about the dns of virtual2.sysadmin-inc.com. I've even downloaded the djbdns tools package and used their dnstrace utility to try and find the problem, with no luck. I've attached errors and config files. Any ideas on this one? Thanks in advance. Apr 20 14:48:14 virtual2 qmail: 987792494.040993 delivery 167: deferral: 216.136.204.18_does_not_like_recipient./Remote_host_said:_450_Client_host _rejected:_cannot_find_your_hostname,_[209.16.228.145]/Giving_up_on _216.136.204.18./ ftp: purplecat.net: Non-recoverable failure in name resolution ftp> virtual2# nslookup Default Server: localhost.sysadmin-inc.com Address: 127.0.0.1 > purplecat.net Server: localhost.sysadmin-inc.com Address: 127.0.0.1 Non-authoritative answer: Name: purplecat.net Address: 209.16.228.148 virtual2# vi /etc/resolv.conf domain sysadmin-inc.com nameserver 127.0.0.1 internal named.conf options section. // $FreeBSD: src/etc/namedb/named.conf,v 1.6.2.1 2000/07/15 07:49:29 kris Exp $ options { listen-on { 10.10.1.2; 10.30.1.1; 127.0.0.1; }; directory "/usr/local/etc/namedb-int"; forwarders { 209.16.228.145; }; allow-transfer { 10.10.1.1; //virtual 10.10.1.71; //bsd1 10.10.1.21; //wcsslaw 10.10.1.25; //allsouls 10.30.1.14; //dggw 10.30.1.20; //gkgw 10.30.1.30; }; //cumcgw allow-query { 10.0.0.0/8; 127.0.0.1; }; query-source address 10.10.1.2 port 53; transfer-source 10.10.1.2; dump-file "s/named_dump.db"; pid-file "s/named.pid"; }; //end of options controls { unix "/var/run/ndc-internal" perm 0660 owner 0 group 53; }; External named.conf options section. // $FreeBSD: src/etc/namedb/named.conf,v 1.6.2.1 2000/07/15 07:49:29 kris Exp $ options { directory "/etc/namedb"; forwarders { 207.230.75.34; //ns1.deltacom.net 207.230.75.50; //ns2.deltacom.net 206.191.128.46; //c2901.wa.net 199.166.24.1; }; //ns1.vrx.net allow-transfer { 209.16.228.140; //virtual/ns2 209.16.228.150; //virtual alias 209.16.228.145; //virtual2 209.16.228.146; //bsd1 209.16.228.141; //sas 209.16.228.142; //sas 208.133.43.7; //available.New-Era.net 207.230.75.34; //ns1.deltacom.net // potentially bogus? 204.181.41.4; //ns1.deltacom.net * 207.230.75.50; }; //ns2.deltacom.net query-source address 209.16.228.145 port 53; transfer-source 209.16.228.145; listen-on { 209.16.228.145; 209.16.228.150; }; dump-file "s/named_dump.db"; pid-file "s/named.pid"; }; //end of options controls { unix "/var/run/ndc-external" perm 0660 owner 0 group 53; }; 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 Apr 21 18:31:26 2001 Delivered-To: freebsd-net@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id 83C0B37B423 for ; Sat, 21 Apr 2001 18:31:23 -0700 (PDT) (envelope-from itojun@itojun.org) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id F35B14B10; Sun, 22 Apr 2001 10:31:14 +0900 (JST) To: snap-users@kame.net To: Gunther Schadow Cc: freebsd-net@freebsd.org In-reply-to: gunther's message of Thu, 19 Apr 2001 04:11:25 GMT. <3ADE656D.3A0BDD0@aurora.regenstrief.org> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: KAME SPD bug, please try and confirm ... From: itojun@iijlab.net Date: Sun, 22 Apr 2001 10:31:14 +0900 Message-ID: <19829.987903074@itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >[Sorry I resend this because it seems as if my subject line >was turning everyone off from looking at this.] >Below is what could be a cookbook recipe for IPsec tunnels. However, >unfortunately it's a bug report. I would like some of you to try >this out and confirm the problem for me, may be find the error on >my part, or make suggestions on how to work around this problem. sorry that we did not make any useful responses, some of the kame guys (mainly sakane) are trying to repeat the symptom. i ran a small test with slightly different setup on both NetBSD 1.5.1_BETA and NetBSD 1.5 + KAME SNAP 2001042x, and the problem did not repeat. i'm just guessing, but it seems that there could be some problem with your routing table setup. you are doing things like: >aip=10.10.10.1 >bip=10.10.10.2 >aipsec=10.99.10 >bipsec=10.99.20 >ifconfig ${if} inet alias ${aip} netmask 0xffffff00 >ifconfig lo0 inet alias ${aipsec}.1 netmask 0xffffff00 >route add -net ${bipsec}.0/24 ${aipsec}.1 why do you need the routing setup, and why do you need the address ${aipsec}.1 onto the loopback interface? if you want to control the source address selection, you may need to use route -ifa settings instead. a network diagram would be very helpful here. I guess you are trying to configure single ethernet segment to have two IP subnet numbers (10.99.10.0/24 and 10.10.10.0/24 are on the same network interface, right?). I really don't recommend doing that. get an extra ethernet card or two and make the device a proper firewall router. >If you have an older KAME release, you may not see this bug >instantaneously, instead you will notice a kernel panic when >running the network for some time under higher load (~ 2 Mb/s). is the following description correct? - FreeBSD 4.2-RELEASE is not affected - FreeBDS 4.2-RELEASE + KAME SNAP 200103xx has problem, but no kernel panic - FreeBSD 4.2-RELEASE + KAME SNAP 200104xx has problem, with kernel panic if you can get a kernel stack trace on panic, it would be really useful. itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Apr 21 22:29:48 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 6F4EE37B42C for ; Sat, 21 Apr 2001 22:29:44 -0700 (PDT) (envelope-from gunther@aurora.regenstrief.org) Received: from aurora.regenstrief.org (aurora.rg.iupui.edu [134.68.31.122]) by rgmail.regenstrief.org (8.11.0/8.8.7) with ESMTP id f3M5GAA19792; Sun, 22 Apr 2001 00:16:19 -0500 Message-ID: <3AE268F5.B48CC2B2@aurora.regenstrief.org> Date: Sun, 22 Apr 2001 05:15:33 +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: itojun@iijlab.net Cc: snap-users@kame.net, freebsd-net@freebsd.org Subject: Re: KAME SPD bug, please try and confirm ... References: <19829.987903074@itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org itojun@iijlab.net wrote: > sorry that we did not make any useful responses, some of the kame guys > (mainly sakane) are trying to repeat the symptom. I appreciate that very much! > i ran a small test with slightly different setup on both NetBSD > 1.5.1_BETA and NetBSD 1.5 + KAME SNAP 2001042x, and the problem did > not repeat. Hmm, may be it's a matter of FreeBSD and does not occur with NetBSD? > is the following description correct? > - FreeBSD 4.2-RELEASE is not affected yes, it is affected with kernel panic (under high loads only ...) > - FreeBDS 4.2-RELEASE + KAME SNAP 200103xx has problem, but no kernel > panic right, shows the described problems but has no such kernel panics > - FreeBSD 4.2-RELEASE + KAME SNAP 200104xx has problem, with kernel > panic actually I should test that. Will do tomorrow. > if you can get a kernel stack trace on panic, it would be really useful. I reported about the panic before (on FreeBSD's bugs) and the error was at esp4_input ... > i'm just guessing, but it seems that there could be some problem > with your routing table setup. you are doing things like: > >aip=10.10.10.1 > >bip=10.10.10.2 > >aipsec=10.99.10 > >bipsec=10.99.20 > >ifconfig ${if} inet alias ${aip} netmask 0xffffff00 > >ifconfig lo0 inet alias ${aipsec}.1 netmask 0xffffff00 > >route add -net ${bipsec}.0/24 ${aipsec}.1 > why do you need the routing setup, and why do you need the address > ${aipsec}.1 onto the loopback interface? if you want to control the > source address selection, you may need to use route -ifa settings > instead. I understood that I had to do this in order to get IPsec done right in the first place. Many howto documents describe things like that. Actually ... > a network diagram would be very helpful here. I guess you are > trying to configure single ethernet segment to have two IP subnet > numbers (10.99.10.0/24 and 10.10.10.0/24 are on the same network > interface, right?). I really don't recommend doing that. get an > extra ethernet card or two and make the device a proper firewall > router. Sure, my real setup has two etherent cards (three even :-) On those I have ifcondig ${ifinside} ${aipsec}.1 netmask 0xffffff00 ifconfig ${ifoutside} ${aip} netmask 0xffffff00 The routing setup then goes like route add -net ${bipsec}.0/24 ${aipsec}.1 just like above. So, the only thing I changed in my test scripts was to replace ${ifinside} with lo0, and I did this so that people could more easily reproduce the problem without requiring two cards (this other "alias" I use in the ifconfig for ${aip} is so that people would not lose their normal IP configuration when running the test.) There was no difference for me if I used lo0 or a real interface or if I configured with or without IP aliases. The network diagram is the same as last time: ${aipsec}.0/24 ${aip} ${bip} ${bipsec}.0/24 ...-----------GATEWAY-0---+------//--------GATEWAY-1-------------... | | ${cip} ${cipsec}.0/24 +------//--------GATEWAY-2-------------... | . . . Thank you, -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 Sat Apr 21 23:21:39 2001 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (f32.law15.hotmail.com [64.4.23.32]) by hub.freebsd.org (Postfix) with ESMTP id F298F37B422 for ; Sat, 21 Apr 2001 23:21:37 -0700 (PDT) (envelope-from fuzi001@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 21 Apr 2001 23:21:37 -0700 Received: from 65.4.220.70 by lw15fd.law15.hotmail.msn.com with HTTP; Sun, 22 Apr 2001 06:21:37 GMT X-Originating-IP: [65.4.220.70] From: "Jet Liang" To: freebsd-net@freebsd.org Subject: NAT implementation help. Date: Sun, 22 Apr 2001 06:21:37 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 22 Apr 2001 06:21:37.0834 (UTC) FILETIME=[7CA430A0:01C0CAF4] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I am going to implement NAT for a network device. Can anyone tell me when can I find out some implementation document? Thanks! Fuzi _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message