From owner-freebsd-net@FreeBSD.ORG Mon Mar 15 00:47:28 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 26BDA16A4CE for ; Mon, 15 Mar 2004 00:47:28 -0800 (PST) Received: from ns.egotop.com (unknown [220.202.4.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3070B43D46 for ; Mon, 15 Mar 2004 00:47:26 -0800 (PST) (envelope-from chenbo@egotop.com) Received: ( www.egotop.com qmail 68322 invoked from network); 15 Mar 2004 16:47:23 +0800 Received: from unknown (HELO RavProxy) (172.16.12.76) by 172.16.1.10 with SMTP; 15 Mar 2004 16:47:23 +0800 From: "chenbo" To: freebsd-net@freebsd.org X-mailer: Foxmail 4.2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Date: Mon, 15 Mar 2004 16:47:20 +0800 Message-Id: <20040315084726.3070B43D46@mx1.FreeBSD.org> Subject: help:FreeBSD4.8+IP Filter: v3.4.32,and error:/kernel: in_cksum: out of data by 3 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2004 08:47:28 -0000 Hi: I have installed the FreeBSD4.8 and IP Filter3.4.32. The FreeBSD BOX is used to NAT. But , i always get the messages "in_cksum: out of data by 3" , And the IP Packets always are droped. How to resolve the problem? the message is: cat /var/log/messages Mar 8 17:13:49 nat /kernel: in_cksum: out of data by 2 Mar 8 17:14:19 nat last message repeated 4 times Mar 8 20:10:03 nat /kernel: in_cksum: out of data by 4 Mar 9 11:59:47 nat /kernel: in_cksum: out of data by 2 Mar 9 11:59:48 nat /kernel: in_cksum: out of data by 2 Mar 9 12:40:06 nat /kernel: in_cksum: out of data by 2 Mar 9 13:32:47 nat /kernel: in_cksum: out of data by 2 Mar 9 17:27:48 nat /kernel: in_cksum: out of data by 2 Mar 9 17:28:16 nat last message repeated 3 times Mar 9 17:37:19 nat /kernel: in_cksum: out of data by 3 Mar 9 18:04:03 nat /kernel: in_cksum: out of data by 1 Mar 9 19:35:19 nat /kernel: in_cksum: out of data by 2 Mar 9 19:35:23 nat last message repeated 2 times Mar 10 09:27:43 nat /kernel: in_cksum: out of data by 2 Mar 10 15:43:08 nat /kernel: in_cksum: out of data by 3 Mar 10 15:43:09 nat /kernel: in_cksum: out of data by 3 Mar 10 19:22:34 nat /kernel: in_cksum: out of data by 2 Mar 10 19:22:55 nat last message repeated 4 times Mar 12 19:30:00 nat /kernel: in_cksum: out of data by 3 Mar 12 20:48:29 nat /kernel: in_cksum: out of data by 3 Mar 13 13:56:40 nat /kernel: in_cksum: out of data by 3 Mar 13 15:45:40 nat /kernel: in_cksum: out of data by 1 Mar 13 16:25:45 nat /kernel: in_cksum: out of data by 3 Mar 13 16:25:53 nat /kernel: in_cksum: out of data by 3 Mar 13 18:28:38 nat /kernel: in_cksum: out of data by 2 Mar 13 18:42:54 nat /kernel: in_cksum: out of data by 3 Mar 13 18:42:57 nat last message repeated 2 times Mar 13 19:04:05 nat /kernel: in_cksum: out of data by 1 Mar 13 19:33:58 nat /kernel: in_cksum: out of data by 3 Mar 13 19:34:16 nat last message repeated 3 times Mar 15 16:06:10 nat /kernel: in_cksum: out of data by 1 Mar 15 16:06:37 nat last message repeated 4 times the system information is: nat# netstat -m 213/432/240000 mbufs in use (current/peak/max): 213 mbufs allocated to data 211/432/60000 mbuf clusters in use (current/peak/max) 972 Kbytes allocated to network (0% of mb_map in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines nat# netstat -in Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll fxp0 1500 xx:xx:xx:xx:xx:xx 3630613020 14 3601258558 0 0 fxp0 1500 xx.xx.xx.xx xx.xx.xx.xx 7201 - 1332493 - - xl0 1500 xx:xx:xx:xx:xx:xx 4036405001 1 3534131265 0 0 xl0 1500 xx.xx.xx.xx xx.xx.xx.xx 285499286 - 11105 - - xl0 1500 xx.xx.xx.xx xx.xx.xx.xx 4058 - 0 - - ppp0* 1500 0 0 0 0 0 lo0 16384 28 0 28 0 0 lo0 16384 127 127.0.0.1 0 - 0 - - nat# nat# vmstat 1 procs memory page disk faults cpu r b w avm fre flt re pi po fr sr ad0 in sy cs us sy id 0 0 0 27516 790040 1 0 0 0 1 0 0 746 14 6 0 17 83 0 0 0 27516 790036 5 0 0 0 0 0 0 19842 23 8 0 40 60 0 0 0 27516 790036 3 0 0 0 0 0 0 19614 23 8 0 46 54 0 0 0 27516 790036 3 0 0 0 0 0 3 20335 23 8 0 37 63 0 0 0 27516 790036 3 0 0 0 0 0 0 20996 23 8 0 49 51 0 0 0 27516 790036 3 0 0 0 0 0 1 19973 23 9 0 45 55 0 0 0 27516 790036 3 0 0 0 0 0 0 20990 23 8 0 42 58 0 0 0 27516 790036 3 0 0 0 0 0 0 20368 27 9 0 43 57 ^C nat# cat /boot/loader.conf userconfig_script_load="YES" hw.ata.wc="1" kern.ipc.nmbclusters="60000" nat# cat /etc/sysctl.conf vfs.vmiodirenable=1 kern.ipc.maxsockbuf=2097152 kern.ipc.somaxconn=8192 kern.ipc.maxsockets=16424 kern.maxfiles=65536 kern.maxfilesperproc=32768 net.inet.tcp.rfc1323=1 net.inet.tcp.delayed_ack=0 net.inet.tcp.sendspace=65535 net.inet.tcp.recvspace=65535 net.inet.udp.recvspace=65535 net.inet.udp.maxdgram=57344 net.local.stream.recvspace=65535 net.local.stream.sendspace=65535 net.inet.ipf.fr_tcpidletimeout=7200 net.inet.ipf.fr_tcpclosewait=120 net.inet.ipf.fr_tcplastack=120 net.inet.ipf.fr_tcptimeout=240 net.inet.ipf.fr_tcpclosed=60 net.inet.ipf.fr_tcphalfclosed=300 net.inet.ipf.fr_udptimeout=90 net.inet.ipf.fr_icmptimeout=35 net.link.ether.inet.log_arp_wrong_iface=0 net.inet.icmp.drop_redirect=1 net.inet.icmp.icmplim_output=0 net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 net.inet.icmp.icmplim=300 nat# ipnat -l |wc 31572 279674 2310903 Dec 31 19:40:59 nat /kernel: Copyright (c) 1992-2003 The FreeBSD Project. Dec 31 19:40:59 nat /kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Dec 31 19:40:59 nat /kernel: The Regents of the University of California. All rights reserved. Dec 31 19:40:59 nat /kernel: FreeBSD 4.8-RELEASE #1: Fri Sep 12 09:04:24 CST 2003 Dec 31 19:40:59 nat /kernel: Timecounter "i8254" frequency 1193182 Hz Dec 31 19:40:59 nat /kernel: Timecounter "TSC" frequency 2398856292 Hz Dec 31 19:40:59 nat /kernel: CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz (2398.86-MHz 686-class CPU) Dec 31 19:40:59 nat /kernel: Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 Dec 31 19:40:59 nat /kernel: Features=0xbfebfbff Dec 31 19:40:59 nat /kernel: real memory = 1065353216 (1040384K bytes) Dec 31 19:40:59 nat /kernel: avail memory = 1033474048 (1009252K bytes) Dec 31 19:40:59 nat /kernel: Preloaded elf kernel "kernel" at 0xc02f0000. Dec 31 19:40:59 nat /kernel: Pentium Pro MTRR support enabled Dec 31 19:40:59 nat /kernel: IP Filter: v3.4.32 initialized. Default = pass all, Logging = enabled From owner-freebsd-net@FreeBSD.ORG Mon Mar 15 03:47:45 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E3D6D16A4CE for ; Mon, 15 Mar 2004 03:47:45 -0800 (PST) Received: from rincewind.c4inet.net (rincewind.c4inet.net [193.120.144.209]) by mx1.FreeBSD.org (Postfix) with SMTP id EF56243D2D for ; Mon, 15 Mar 2004 03:47:44 -0800 (PST) (envelope-from lists@rincewind.c4inet.net) Received: (qmail 32736 invoked from network); 15 Mar 2004 11:47:43 -0000 Received: from localhost.c4inet.net (HELO rincewind.c4inet.net) (127.0.0.1) by rincewind.c4inet.net with SMTP; 15 Mar 2004 11:47:43 -0000 Received: (from lists@localhost) by rincewind.c4inet.net (8.12.10/8.12.10/Submit) id i2FBlhQ0032734 for freebsd-net@freebsd.org; Mon, 15 Mar 2004 11:47:43 GMT (envelope-from lists) Date: Mon, 15 Mar 2004 11:47:43 +0000 From: Sascha Luck To: freebsd-net@freebsd.org Message-ID: <20040315114743.GB78655@rincewind.c4inet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: 802.11b / ipv6 oddity X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2004 11:47:46 -0000 I am running v4/v6 stacks in parallel on my 802.11b network. v6 is provided via tunnel over a DSL connection. AP is a FreeBSD 5.1R box with a PrismII based 802.11b card, the other machines are 5.2.1R/Lucent and -CURRENT/Broadcom(ndis). The problem now is that every download via ftp/http stalls after 65k on either client machine. Downloads on the gateway box are normal. Anything < 65k is normal as well. The MTU of the tunnel is 1280.(I've tried reducing the MTU on the wireless interfaces, makes no difference) Has anybody else come across this issue? Cheers, Sascha From owner-freebsd-net@FreeBSD.ORG Mon Mar 15 11:01:34 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A45D16A5EC for ; Mon, 15 Mar 2004 11:01:32 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD1A343D39 for ; Mon, 15 Mar 2004 11:01:32 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.10/8.12.10) with ESMTP id i2FJ1Wbv055923 for ; Mon, 15 Mar 2004 11:01:32 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.10/8.12.10/Submit) id i2FJ1WI7055917 for freebsd-net@freebsd.org; Mon, 15 Mar 2004 11:01:32 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 15 Mar 2004 11:01:32 -0800 (PST) Message-Id: <200403151901.i2FJ1WI7055917@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2004 19:01:34 -0000 Current FreeBSD problem reports Critical problems Serious problems Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/07/11] kern/54383 net NFS root configurations without dynamic p 1 problem total. From owner-freebsd-net@FreeBSD.ORG Mon Mar 15 15:38:32 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB81E16A4CE; Mon, 15 Mar 2004 15:38:32 -0800 (PST) Received: from fep04-mail.bloor.is.net.cable.rogers.com (fep04-mail.bloor.is.net.cable.rogers.com [66.185.86.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2ECD043D31; Mon, 15 Mar 2004 15:38:32 -0800 (PST) (envelope-from mikej@rogers.com) Received: from [192.168.0.1] ([63.139.3.63]) by fep04-mail.bloor.is.net.cable.rogers.comESMTP <20040315233756.QHAZ3598.fep04-mail.bloor.is.net.cable.rogers.com@[192.168.0.1]>; Mon, 15 Mar 2004 18:37:56 -0500 Received: from 192.168.0.200 (SquirrelMail authenticated user mikej) by 192.168.0.1 with HTTP; Mon, 15 Mar 2004 18:38:28 -0500 (EST) Message-ID: <2650.192.168.0.200.1079393908.squirrel@192.168.0.1> Date: Mon, 15 Mar 2004 18:38:28 -0500 (EST) From: "Mike Jakubik" To: current@freebsd.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Authentication-Info: Submitted using SMTP AUTH LOGIN at fep04-mail.bloor.is.net.cable.rogers.com from [63.139.3.63] using ID at Mon, 15 Mar 2004 18:37:56 -0500 cc: net@freebsd.org Subject: Byte counters reset at ~4GB X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2004 23:38:32 -0000 Hello, It seems that the byte counters (derived from netstat -nbi) reset at around 4 GB. Is there no way around this? It would be nice to be able to see an accurate display of totals. It just seems pointless to even have this, as 4 GB is just not that much anymore. I know this is a 32bit limitation of the variable, but that's just bad coding in my opinion (no offence intended), I mean there must be some way around this. Thank You. From owner-freebsd-net@FreeBSD.ORG Mon Mar 15 15:44:56 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4EB0816A4CE; Mon, 15 Mar 2004 15:44:56 -0800 (PST) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 384B843D31; Mon, 15 Mar 2004 15:44:56 -0800 (PST) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.10/8.12.3) with ESMTP id i2FNiqZa029938; Mon, 15 Mar 2004 15:44:52 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.10/8.12.3/Submit) id i2FNiqFR029935; Mon, 15 Mar 2004 15:44:52 -0800 Date: Mon, 15 Mar 2004 15:44:52 -0800 From: Brooks Davis To: Mike Jakubik Message-ID: <20040315234448.GA28383@Odin.AC.HMC.Edu> References: <2650.192.168.0.200.1079393908.squirrel@192.168.0.1> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zhXaljGHf11kAtnf" Content-Disposition: inline In-Reply-To: <2650.192.168.0.200.1079393908.squirrel@192.168.0.1> User-Agent: Mutt/1.5.4i X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu cc: current@freebsd.org cc: net@freebsd.org Subject: Re: Byte counters reset at ~4GB X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2004 23:44:56 -0000 --zhXaljGHf11kAtnf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 15, 2004 at 06:38:28PM -0500, Mike Jakubik wrote: > It seems that the byte counters (derived from netstat -nbi) reset at > around 4 GB. Is there no way around this? It would be nice to be able to > see an accurate display of totals. It just seems pointless to even have > this, as 4 GB is just not that much anymore. I know this is a 32bit > limitation of the variable, but that's just bad coding in my opinion (no > offence intended), I mean there must be some way around this. Please read the archives of freebsd-net. This has been discussed many times. There are valid reasons for this, particularly the fact that 64-bit counters are much more expensive to update on 32-bit architectures. API breakage is also a problem. We're aware that 2^32 is way to small a limit for modern network counters, but fixing it isn't trivial on 32-bit hardware. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --zhXaljGHf11kAtnf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFAVj/uXY6L6fI4GtQRArTxAKCuyQm/4ERbBArDIR52/mX0oPx3PQCfVeYb OwaGZEipToKOKAgmcalY4Is= =UjN1 -----END PGP SIGNATURE----- --zhXaljGHf11kAtnf-- From owner-freebsd-net@FreeBSD.ORG Mon Mar 15 15:53:31 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2006516A4CE for ; Mon, 15 Mar 2004 15:53:31 -0800 (PST) Received: from amsfep17-int.chello.nl (amsfep17-int.chello.nl [213.46.243.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4AF2343D39 for ; Mon, 15 Mar 2004 15:53:30 -0800 (PST) (envelope-from girgen@pingpong.net) Received: from palle.girgensohn.se ([213.89.137.38]) by amsfep17-int.chello.nlESMTP <20040315235328.PMLQ9102.amsfep17-int.chello.nl@palle.girgensohn.se>; Tue, 16 Mar 2004 00:53:28 +0100 Received: from localhost (localhost [127.0.0.1]) by palle.girgensohn.se (8.12.11/8.12.11) with ESMTP id i2FNrRj1056667; Tue, 16 Mar 2004 00:53:27 +0100 (CET) (envelope-from girgen@pingpong.net) Date: Tue, 16 Mar 2004 00:53:27 +0100 From: Palle Girgensohn To: net@freebsd.org Message-ID: <20240000.1079394807@palle.girgensohn.se> X-Mailer: Mulberry/3.1.0 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; FORMAT=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: sk ethernet driver: watchdog timeout X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2004 23:53:31 -0000 Hi, I have an ASUS motherboard A7V8X-E Deluxe with onboard 10/100/1000 Mbit/s NIC from Marvell Semiconductor. My problem is that it sometimes lock up with the error message sk0: watchdog timeout The network is gone for a minute or so, then it comes back. It seems to work better when connected to a gigabit switch than when connected to a 100 Mb/s switch, but it happens in both modes. Happens on at least two different machines with different cables. Any ideas? Bad driver? It also cannot use DHCP, dhclient just sits there, nothing happens. I've read a thread about this. This is a fresh FreeBSD 4-STABLE system. Regards, Palle ifconfig: sk0: flags=8843 mtu 1500 inet 192.168.1.187 netmask 0xffffff00 broadcast 192.168.1.255 inet6 fe80::20e:a6ff:fe15:2e3f%sk0 prefixlen 64 scopeid 0x1 ether 00:0e:a6:15:2e:3f media: Ethernet autoselect (1000baseTX ) status: active FreeBSD 4.9-STABLE #0: Sat Mar 13 18:11:47 CET 2004 kudo@jordgubbe.pingpong.net:/.a/banan/usr/obj/usr/src/sys/ASUS Timecounter "i8254" frequency 1193182 Hz CPU: AMD Athlon(tm) XP 2800+ (2079.56-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x6a0 Stepping = 0 Features=0x383fbff AMD Features=0xc0400000 real memory = 1073676288 (1048512K bytes) avail memory = 1040752640 (1016360K bytes) Preloaded elf kernel "kernel" at 0xc0436000. Preloaded elf module "if_sk.ko" at 0xc043609c. Preloaded elf module "snd_pcm.ko" at 0xc043613c. Pentium Pro MTRR support enabled md0: Malloc disk Using $PIR table, 12 entries at 0xc00fdea0 npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 pci0: (vendor=0x10de, dev=0x01eb) at 0.1 pci0: (vendor=0x10de, dev=0x01ee) at 0.2 pci0: (vendor=0x10de, dev=0x01ed) at 0.3 pci0: (vendor=0x10de, dev=0x01ec) at 0.4 pci0: (vendor=0x10de, dev=0x01ef) at 0.5 isab0: at device 1.0 on pci0 isa0: on isab0 pci0: (vendor=0x10de, dev=0x0064) at 1.1 irq 9 ohci0: mem 0xe9001000-0xe9001fff irq 11 at device 2.0 on pci0 usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: (0x10de) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 3 ports with 3 removable, self powered ohci1: mem 0xe9002000-0xe9002fff irq 9 at device 2.1 on pci0 usb1: OHCI version 1.0, legacy support usb1: SMM does not respond, resetting usb1: on ohci1 usb1: USB revision 1.0 uhub1: (0x10de) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 3 ports with 3 removable, self powered ums0: Logitech USB-PS/2 Optical Mouse, rev 2.00/18.00, addr 2, iclass 3/1 ums0: 6 buttons and Z dir. ukbd0: Key Tronic Keytronic USB Keyboard, rev 1.10/1.02, addr 3, iclass 3/1 kbd1 at ukbd0 pci0: at 2.2 irq 11 pci0: (vendor=0x10de, dev=0x0066) at 4.0 irq 9 pcib1: at device 8.0 on pci0 pci1: on pcib1 skc0: port 0xa000-0xa0ff mem 0xe8000000-0xe8003fff irq 7 at device 4.0 on pci1 skc0: Yukon Gigabit Ethernet 10/100/1000Base-T Adapter sk0: on skc0 sk0: Ethernet address: 00:0e:a6:15:2e:3f miibus0: on sk0 e1000phy0: on miibus0 e1000phy0: 1000baseTX-FDX, 100baseTX-FDX, 100baseTX, 10baseTX-FDX, 10baseTX, auto pci1: (vendor=0x1274, dev=0x1371) at 7.0 irq 11 xl0: <3Com 3c905B-TX Fast Etherlink XL> port 0xa800-0xa87f mem 0xe8004000-0xe800407f irq 9 at device 10.0 on pci1 xl0: Ethernet address: 00:10:5a:12:00:87 miibus1: on xl0 xlphy0: <3Com internal media interface> on miibus1 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci1: (vendor=0x1095, dev=0x3112) at 11.0 irq 11 atapci0: port 0xf000-0xf00f at device 9.0 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: (vendor=0x10de, dev=0x006e) at 13.0 irq 9 pcib2: at device 30.0 on pci0 pci3: on pcib2 pci3: at 0.0 irq 11 pci3: at 0.1 orm0: if (pipe.delay > 10000) errx(EX_DATAERR, "delay %d must be < 10000", pipe.delay); in /usr/src/sbin/ipfw/ipfw.c Limits the pipe delay for dummynet to 10 seconds. Is there any reason for this? Also, no such limit is imposed on the bandwidth why? Memory (amount of mbufs/mbclusters) is obviously a limit here but I was wondering if something else was hidden in this statement. Regards, Karim From owner-freebsd-net@FreeBSD.ORG Tue Mar 16 14:13:42 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5BB6A16A4CE; Tue, 16 Mar 2004 14:13:42 -0800 (PST) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FEDF43D2D; Tue, 16 Mar 2004 14:13:41 -0800 (PST) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id E671F530E; Tue, 16 Mar 2004 23:13:39 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id D9308530A; Tue, 16 Mar 2004 23:13:23 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id B680733C6B; Tue, 16 Mar 2004 23:13:23 +0100 (CET) To: current@freebsd.org, net@freebsd.org From: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Tue, 16 Mar 2004 23:13:23 +0100 Message-ID: User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 Subject: libalias patch for review / testing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2004 22:13:42 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Anybody running natd on -CURRENT, please test the attached patch (on top of latest sources) and report back if anything stops working. I'd also like to know if the patched version works when built with -O2 (the original apparently doesn't). DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=libalias.diff Index: Makefile =================================================================== RCS file: /home/ncvs/src/lib/libalias/Makefile,v retrieving revision 1.24 diff -u -r1.24 Makefile --- Makefile 17 Jan 2004 10:52:20 -0000 1.24 +++ Makefile 16 Mar 2004 22:13:04 -0000 @@ -8,5 +8,6 @@ alias_nbt.c alias_pptp.c alias_proxy.c alias_skinny.c alias_smedia.c \ alias_util.c alias_old.c INCS= alias.h +WARNS?= 2 .include Index: alias.c =================================================================== RCS file: /home/ncvs/src/lib/libalias/alias.c,v retrieving revision 1.40 diff -u -r1.40 alias.c --- alias.c 16 Mar 2004 21:30:41 -0000 1.40 +++ alias.c 16 Mar 2004 22:13:04 -0000 @@ -136,8 +136,13 @@ #define TFTP_PORT_NUMBER 69 #define PPTP_CONTROL_PORT_NUMBER 1723 +static __inline int +twowords(void *p) +{ + u_short *s = p; - + return (s[0] + s[1]); +} /* TCP Handling Routines @@ -295,9 +300,7 @@ original_address = GetOriginalAddress(link); DifferentialChecksum(&pip->ip_sum, - (u_short *) & original_address, - (u_short *) & pip->ip_dst, - 2); + &original_address, &pip->ip_dst, 2); pip->ip_dst = original_address; } @@ -344,7 +347,6 @@ if (link != NULL) { if (ip->ip_p == IPPROTO_UDP || ip->ip_p == IPPROTO_TCP) { - u_short *sptr; int accumulate, accumulate2; struct in_addr original_address; u_short original_port; @@ -353,12 +355,8 @@ original_port = GetOriginalPort(link); /* Adjust ICMP checksum */ - sptr = (u_short *) & (ip->ip_src); - accumulate = *sptr++; - accumulate += *sptr; - sptr = (u_short *) & original_address; - accumulate -= *sptr++; - accumulate -= *sptr; + accumulate = twowords(&ip->ip_src); + accumulate -= twowords(&original_address); accumulate += ud->uh_sport; accumulate -= original_port; accumulate2 = accumulate; @@ -369,9 +367,7 @@ /* Un-alias address in IP header */ DifferentialChecksum(&pip->ip_sum, - (u_short *) & original_address, - (u_short *) & pip->ip_dst, - 2); + &original_address, &pip->ip_dst, 2); pip->ip_dst = original_address; /* Un-alias address and port number of original IP packet @@ -379,7 +375,6 @@ ip->ip_src = original_address; ud->uh_sport = original_port; } else if (ip->ip_p == IPPROTO_ICMP) { - u_short *sptr; int accumulate, accumulate2; struct in_addr original_address; u_short original_id; @@ -388,12 +383,8 @@ original_id = GetOriginalPort(link); /* Adjust ICMP checksum */ - sptr = (u_short *) & (ip->ip_src); - accumulate = *sptr++; - accumulate += *sptr; - sptr = (u_short *) & original_address; - accumulate -= *sptr++; - accumulate -= *sptr; + accumulate = twowords(&ip->ip_src); + accumulate -= twowords(&original_address); accumulate += ic2->icmp_id; accumulate -= original_id; accumulate2 = accumulate; @@ -404,9 +395,7 @@ /* Un-alias address in IP header */ DifferentialChecksum(&pip->ip_sum, - (u_short *) & original_address, - (u_short *) & pip->ip_dst, - 2); + &original_address, &pip->ip_dst, 2); pip->ip_dst = original_address; /* Un-alias address of original IP packet and sequence number of @@ -489,9 +478,7 @@ alias_address = GetAliasAddress(link); DifferentialChecksum(&pip->ip_sum, - (u_short *) & alias_address, - (u_short *) & pip->ip_src, - 2); + &alias_address, &pip->ip_src, 2); pip->ip_src = alias_address; } @@ -539,7 +526,6 @@ if (link != NULL) { if (ip->ip_p == IPPROTO_UDP || ip->ip_p == IPPROTO_TCP) { - u_short *sptr; int accumulate; struct in_addr alias_address; u_short alias_port; @@ -548,12 +534,8 @@ alias_port = GetAliasPort(link); /* Adjust ICMP checksum */ - sptr = (u_short *) & (ip->ip_dst); - accumulate = *sptr++; - accumulate += *sptr; - sptr = (u_short *) & alias_address; - accumulate -= *sptr++; - accumulate -= *sptr; + accumulate = twowords(&ip->ip_dst); + accumulate -= twowords(&alias_addresses); accumulate += ud->uh_dport; accumulate -= alias_port; ADJUST_CHECKSUM(accumulate, ic->icmp_cksum); @@ -564,9 +546,7 @@ */ if (pip->ip_src.s_addr == ip->ip_dst.s_addr) { DifferentialChecksum(&pip->ip_sum, - (u_short *) & alias_address, - (u_short *) & pip->ip_src, - 2); + &alias_address, &pip->ip_src, 2); pip->ip_src = alias_address; } /* Alias address and port number of original IP packet @@ -574,7 +554,6 @@ ip->ip_dst = alias_address; ud->uh_dport = alias_port; } else if (ip->ip_p == IPPROTO_ICMP) { - u_short *sptr; int accumulate; struct in_addr alias_address; u_short alias_id; @@ -583,12 +562,8 @@ alias_id = GetAliasPort(link); /* Adjust ICMP checksum */ - sptr = (u_short *) & (ip->ip_dst); - accumulate = *sptr++; - accumulate += *sptr; - sptr = (u_short *) & alias_address; - accumulate -= *sptr++; - accumulate -= *sptr; + accumulate = twowords(&ip->ip_dst); + accumulate -= twowords(&alias_address); accumulate += ic2->icmp_id; accumulate -= alias_id; ADJUST_CHECKSUM(accumulate, ic->icmp_cksum); @@ -599,9 +574,7 @@ */ if (pip->ip_src.s_addr == ip->ip_dst.s_addr) { DifferentialChecksum(&pip->ip_sum, - (u_short *) & alias_address, - (u_short *) & pip->ip_src, - 2); + &alias_address, &pip->ip_src, 2); pip->ip_src = alias_address; } /* Alias address of original IP packet and sequence number of @@ -673,9 +646,7 @@ /* Restore original IP address */ DifferentialChecksum(&pip->ip_sum, - (u_short *) & original_address, - (u_short *) & pip->ip_dst, - 2); + &original_address, &pip->ip_dst, 2); pip->ip_dst = original_address; return (PKT_ALIAS_OK); @@ -706,9 +677,7 @@ /* Change source address */ DifferentialChecksum(&pip->ip_sum, - (u_short *) & alias_address, - (u_short *) & pip->ip_src, - 2); + &alias_address, &pip->ip_src, 2); pip->ip_src = alias_address; return (PKT_ALIAS_OK); @@ -737,7 +706,6 @@ struct in_addr original_address; u_short alias_port; int accumulate; - u_short *sptr; int r = 0; alias_address = GetAliasAddress(link); @@ -762,19 +730,13 @@ if (ud->uh_sum != 0) { accumulate = alias_port; accumulate -= ud->uh_dport; - sptr = (u_short *) & alias_address; - accumulate += *sptr++; - accumulate += *sptr; - sptr = (u_short *) & original_address; - accumulate -= *sptr++; - accumulate -= *sptr; + accumulate += twowords(&alias_address); + accumulate -= twowords(&original_address); ADJUST_CHECKSUM(accumulate, ud->uh_sum); } /* Restore original IP address */ DifferentialChecksum(&pip->ip_sum, - (u_short *) & original_address, - (u_short *) & pip->ip_dst, - 2); + &original_address, &pip->ip_dst, 2); pip->ip_dst = original_address; /* @@ -834,16 +796,11 @@ /* being aliased and source address is being altered */ if (ud->uh_sum != 0) { int accumulate; - u_short *sptr; accumulate = ud->uh_sport; accumulate -= alias_port; - sptr = (u_short *) & (pip->ip_src); - accumulate += *sptr++; - accumulate += *sptr; - sptr = (u_short *) & alias_address; - accumulate -= *sptr++; - accumulate -= *sptr; + accumulate += twowords(&pip->ip_src); + accumulate -= twowords(&alias_address); ADJUST_CHECKSUM(accumulate, ud->uh_sum); } /* Put alias port in UDP header */ @@ -851,9 +808,7 @@ /* Change source address */ DifferentialChecksum(&pip->ip_sum, - (u_short *) & alias_address, - (u_short *) & pip->ip_src, - 2); + &alias_address, &pip->ip_src, 2); pip->ip_src = alias_address; return (PKT_ALIAS_OK); @@ -882,7 +837,6 @@ u_short alias_port; u_short proxy_port; int accumulate; - u_short *sptr; /* Special processing for IP encoding protocols */ if (ntohs(tc->th_dport) == PPTP_CONTROL_PORT_NUMBER @@ -903,12 +857,8 @@ /* and destination port is being altered. */ accumulate = alias_port; accumulate -= tc->th_dport; - sptr = (u_short *) & alias_address; - accumulate += *sptr++; - accumulate += *sptr; - sptr = (u_short *) & original_address; - accumulate -= *sptr++; - accumulate -= *sptr; + accumulate += twowords(&alias_address); + accumulate -= twowords(&original_address); /* If this is a proxy, then modify the TCP source port and checksum accumulation */ @@ -916,13 +866,8 @@ accumulate += tc->th_sport; tc->th_sport = proxy_port; accumulate -= tc->th_sport; - - sptr = (u_short *) & pip->ip_src; - accumulate += *sptr++; - accumulate += *sptr; - sptr = (u_short *) & proxy_address; - accumulate -= *sptr++; - accumulate -= *sptr; + accumulate += twowords(&pip->ip_src); + accumulate -= twowords(&proxy_address); } /* See if ACK number needs to be modified */ if (GetAckModified(link) == 1) { @@ -930,36 +875,23 @@ delta = GetDeltaAckIn(pip, link); if (delta != 0) { - sptr = (u_short *) & tc->th_ack; - accumulate += *sptr++; - accumulate += *sptr; + accumulate += twowords(&tc->th_ack); tc->th_ack = htonl(ntohl(tc->th_ack) - delta); - sptr = (u_short *) & tc->th_ack; - accumulate -= *sptr++; - accumulate -= *sptr; + accumulate -= twowords(&tc->th_ack); } } ADJUST_CHECKSUM(accumulate, tc->th_sum); /* Restore original IP address */ - sptr = (u_short *) & pip->ip_dst; - accumulate = *sptr++; - accumulate += *sptr; - pip->ip_dst = original_address; - sptr = (u_short *) & pip->ip_dst; - accumulate -= *sptr++; - accumulate -= *sptr; + accumulate = twowords(&pip->ip_dst); + accumulate -= twowords(&pip->ip_dst); /* If this is a transparent proxy packet, then modify the source address */ if (proxy_address.s_addr != 0) { - sptr = (u_short *) & pip->ip_src; - accumulate += *sptr++; - accumulate += *sptr; + accumulate += twowords(&pip->ip_src); pip->ip_src = proxy_address; - sptr = (u_short *) & pip->ip_src; - accumulate -= *sptr++; - accumulate -= *sptr; + accumulate -= twowords(&pip->ip_src); } ADJUST_CHECKSUM(accumulate, pip->ip_sum); @@ -995,29 +927,17 @@ dest_address = pip->ip_dst; if (proxy_type != 0) { int accumulate; - u_short *sptr; accumulate = tc->th_dport; tc->th_dport = proxy_server_port; accumulate -= tc->th_dport; - - sptr = (u_short *) & (pip->ip_dst); - accumulate += *sptr++; - accumulate += *sptr; - sptr = (u_short *) & proxy_server_address; - accumulate -= *sptr++; - accumulate -= *sptr; - + accumulate += twowords(&pip->ip_dst); + accumulate -= twowords(&proxy_server_address); ADJUST_CHECKSUM(accumulate, tc->th_sum); - sptr = (u_short *) & (pip->ip_dst); - accumulate = *sptr++; - accumulate += *sptr; + accumulate = twowords(&pip->ip_dst); pip->ip_dst = proxy_server_address; - sptr = (u_short *) & (pip->ip_dst); - accumulate -= *sptr++; - accumulate -= *sptr; - + accumulate -= twowords(&pip->ip_dst); ADJUST_CHECKSUM(accumulate, pip->ip_sum); } link = FindUdpTcpOut(la, pip->ip_src, pip->ip_dst, @@ -1027,7 +947,6 @@ u_short alias_port; struct in_addr alias_address; int accumulate; - u_short *sptr; /* Save original destination address, if this is a proxy packet. Also modify packet to include destination encoding. This may @@ -1069,13 +988,8 @@ accumulate = tc->th_sport; tc->th_sport = alias_port; accumulate -= tc->th_sport; - - sptr = (u_short *) & (pip->ip_src); - accumulate += *sptr++; - accumulate += *sptr; - sptr = (u_short *) & alias_address; - accumulate -= *sptr++; - accumulate -= *sptr; + accumulate += twowords(&pip->ip_src); + accumulate -= twowords(&alias_address); /* Modify sequence number if necessary */ if (GetAckModified(link) == 1) { @@ -1083,26 +997,17 @@ delta = GetDeltaSeqOut(pip, link); if (delta != 0) { - sptr = (u_short *) & tc->th_seq; - accumulate += *sptr++; - accumulate += *sptr; + accumulate += twowords(&tc->th_seq); tc->th_seq = htonl(ntohl(tc->th_seq) + delta); - sptr = (u_short *) & tc->th_seq; - accumulate -= *sptr++; - accumulate -= *sptr; + accumulate -= twowords(&tc->th_seq); } } ADJUST_CHECKSUM(accumulate, tc->th_sum); /* Change source address */ - sptr = (u_short *) & (pip->ip_src); - accumulate = *sptr++; - accumulate += *sptr; + accumulate = twowords(&pip->ip_src); pip->ip_src = alias_address; - sptr = (u_short *) & (pip->ip_src); - accumulate -= *sptr++; - accumulate -= *sptr; - + accumulate -= twowords(&pip->ip_src); ADJUST_CHECKSUM(accumulate, pip->ip_sum); return (PKT_ALIAS_OK); @@ -1142,9 +1047,7 @@ GetFragmentAddr(link, &original_address); DifferentialChecksum(&pip->ip_sum, - (u_short *) & original_address, - (u_short *) & pip->ip_dst, - 2); + &original_address, &pip->ip_dst, 2); pip->ip_dst = original_address; return (PKT_ALIAS_OK); @@ -1160,9 +1063,7 @@ alias_address = FindAliasAddress(la, pip->ip_src); DifferentialChecksum(&pip->ip_sum, - (u_short *) & alias_address, - (u_short *) & pip->ip_src, - 2); + &alias_address, &pip->ip_src, 2); pip->ip_src = alias_address; return (PKT_ALIAS_OK); @@ -1240,9 +1141,7 @@ fpip = (struct ip *)ptr_fragment; DifferentialChecksum(&fpip->ip_sum, - (u_short *) & pip->ip_dst, - (u_short *) & fpip->ip_dst, - 2); + &pip->ip_dst, &fpip->ip_dst, 2); fpip->ip_dst = pip->ip_dst; } @@ -1443,7 +1342,6 @@ /* Change it from an aliased packet to an unaliased packet */ if (link != NULL) { if (pip->ip_p == IPPROTO_UDP || pip->ip_p == IPPROTO_TCP) { - u_short *sptr; int accumulate; struct in_addr original_address; u_short original_port; @@ -1452,12 +1350,8 @@ original_port = GetOriginalPort(link); /* Adjust TCP/UDP checksum */ - sptr = (u_short *) & (pip->ip_src); - accumulate = *sptr++; - accumulate += *sptr; - sptr = (u_short *) & original_address; - accumulate -= *sptr++; - accumulate -= *sptr; + accumulate = twowords(&pip->ip_src); + accumulate -= twowords(&original_address); if (pip->ip_p == IPPROTO_UDP) { accumulate += ud->uh_sport; @@ -1471,9 +1365,7 @@ /* Adjust IP checksum */ DifferentialChecksum(&pip->ip_sum, - (u_short *) & original_address, - (u_short *) & pip->ip_src, - 2); + &original_address, &pip->ip_src, 2); /* Un-alias source address and port number */ pip->ip_src = original_address; @@ -1486,7 +1378,6 @@ } else if (pip->ip_p == IPPROTO_ICMP) { - u_short *sptr; int accumulate; struct in_addr original_address; u_short original_id; @@ -1495,21 +1386,15 @@ original_id = GetOriginalPort(link); /* Adjust ICMP checksum */ - sptr = (u_short *) & (pip->ip_src); - accumulate = *sptr++; - accumulate += *sptr; - sptr = (u_short *) & original_address; - accumulate -= *sptr++; - accumulate -= *sptr; + accumulate = twowords(&pip->ip_src); + accumulate -= twowords(&original_address); accumulate += ic->icmp_id; accumulate -= original_id; ADJUST_CHECKSUM(accumulate, ic->icmp_cksum); /* Adjust IP checksum */ DifferentialChecksum(&pip->ip_sum, - (u_short *) & original_address, - (u_short *) & pip->ip_src, - 2); + &original_address, &pip->ip_src, 2); /* Un-alias source address and port number */ pip->ip_src = original_address; Index: alias_local.h =================================================================== RCS file: /home/ncvs/src/lib/libalias/alias_local.h,v retrieving revision 1.26 diff -u -r1.26 alias_local.h --- alias_local.h 16 Mar 2004 21:30:41 -0000 1.26 +++ alias_local.h 16 Mar 2004 22:13:04 -0000 @@ -168,8 +168,7 @@ u_short IpChecksum(struct ip *_pip); u_short TcpChecksum(struct ip *_pip); void -DifferentialChecksum(u_short * _cksum, u_short * _new, u_short * _old, - int _n); +DifferentialChecksum(u_short * _cksum, void * _new, void * _old, int _n); /* Internal data access */ struct alias_link * Index: alias_pptp.c =================================================================== RCS file: /home/ncvs/src/lib/libalias/alias_pptp.c,v retrieving revision 1.8 diff -u -r1.8 alias_pptp.c --- alias_pptp.c 16 Mar 2004 21:30:41 -0000 1.8 +++ alias_pptp.c 16 Mar 2004 22:13:04 -0000 @@ -338,9 +338,7 @@ /* Change source IP address. */ DifferentialChecksum(&pip->ip_sum, - (u_short *) & alias_addr, - (u_short *) & pip->ip_src, - 2); + &alias_addr, &pip->ip_src, 2); pip->ip_src = alias_addr; } return (0); @@ -368,9 +366,7 @@ /* Restore original IP address. */ DifferentialChecksum(&pip->ip_sum, - (u_short *) & src_addr, - (u_short *) & pip->ip_dst, - 2); + &src_addr, &pip->ip_dst, 2); pip->ip_dst = src_addr; } return (0); Index: alias_util.c =================================================================== RCS file: /home/ncvs/src/lib/libalias/alias_util.c,v retrieving revision 1.11 diff -u -r1.11 alias_util.c --- alias_util.c 16 Mar 2004 21:30:41 -0000 1.11 +++ alias_util.c 16 Mar 2004 22:13:04 -0000 @@ -136,10 +136,12 @@ void -DifferentialChecksum(u_short * cksum, u_short * new, u_short * old, int n) +DifferentialChecksum(u_short * cksum, void *newp, void *oldp, int n) { int i; int accumulate; + u_short *new = newp; + u_short *old = oldp; accumulate = *cksum; for (i = 0; i < n; i++) { --=-=-=-- From owner-freebsd-net@FreeBSD.ORG Tue Mar 16 14:14:45 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 332E416A4DA; Tue, 16 Mar 2004 14:14:45 -0800 (PST) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 66E9843D1D; Tue, 16 Mar 2004 14:14:44 -0800 (PST) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 81F16530E; Tue, 16 Mar 2004 23:14:43 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 9DF27530A; Tue, 16 Mar 2004 23:14:23 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id 88AB233C6B; Tue, 16 Mar 2004 23:14:23 +0100 (CET) To: current@freebsd.org References: From: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Tue, 16 Mar 2004 23:14:23 +0100 In-Reply-To: (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav's?= message of "Tue, 16 Mar 2004 23:13:23 +0100") Message-ID: User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 cc: net@freebsd.org Subject: Re: libalias patch for review / testing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2004 22:14:45 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable des@des.no (Dag-Erling Sm=C3=B8rgrav) writes: > Anybody running natd on -CURRENT, please test the attached patch Umm, here's a patch that actually compiles. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=libalias.diff Index: Makefile =================================================================== RCS file: /home/ncvs/src/lib/libalias/Makefile,v retrieving revision 1.24 diff -u -r1.24 Makefile --- Makefile 17 Jan 2004 10:52:20 -0000 1.24 +++ Makefile 16 Mar 2004 22:14:03 -0000 @@ -8,5 +8,6 @@ alias_nbt.c alias_pptp.c alias_proxy.c alias_skinny.c alias_smedia.c \ alias_util.c alias_old.c INCS= alias.h +WARNS?= 2 .include Index: alias.c =================================================================== RCS file: /home/ncvs/src/lib/libalias/alias.c,v retrieving revision 1.40 diff -u -r1.40 alias.c --- alias.c 16 Mar 2004 21:30:41 -0000 1.40 +++ alias.c 16 Mar 2004 22:14:03 -0000 @@ -136,8 +136,13 @@ #define TFTP_PORT_NUMBER 69 #define PPTP_CONTROL_PORT_NUMBER 1723 +static __inline int +twowords(void *p) +{ + u_short *s = p; - + return (s[0] + s[1]); +} /* TCP Handling Routines @@ -295,9 +300,7 @@ original_address = GetOriginalAddress(link); DifferentialChecksum(&pip->ip_sum, - (u_short *) & original_address, - (u_short *) & pip->ip_dst, - 2); + &original_address, &pip->ip_dst, 2); pip->ip_dst = original_address; } @@ -344,7 +347,6 @@ if (link != NULL) { if (ip->ip_p == IPPROTO_UDP || ip->ip_p == IPPROTO_TCP) { - u_short *sptr; int accumulate, accumulate2; struct in_addr original_address; u_short original_port; @@ -353,12 +355,8 @@ original_port = GetOriginalPort(link); /* Adjust ICMP checksum */ - sptr = (u_short *) & (ip->ip_src); - accumulate = *sptr++; - accumulate += *sptr; - sptr = (u_short *) & original_address; - accumulate -= *sptr++; - accumulate -= *sptr; + accumulate = twowords(&ip->ip_src); + accumulate -= twowords(&original_address); accumulate += ud->uh_sport; accumulate -= original_port; accumulate2 = accumulate; @@ -369,9 +367,7 @@ /* Un-alias address in IP header */ DifferentialChecksum(&pip->ip_sum, - (u_short *) & original_address, - (u_short *) & pip->ip_dst, - 2); + &original_address, &pip->ip_dst, 2); pip->ip_dst = original_address; /* Un-alias address and port number of original IP packet @@ -379,7 +375,6 @@ ip->ip_src = original_address; ud->uh_sport = original_port; } else if (ip->ip_p == IPPROTO_ICMP) { - u_short *sptr; int accumulate, accumulate2; struct in_addr original_address; u_short original_id; @@ -388,12 +383,8 @@ original_id = GetOriginalPort(link); /* Adjust ICMP checksum */ - sptr = (u_short *) & (ip->ip_src); - accumulate = *sptr++; - accumulate += *sptr; - sptr = (u_short *) & original_address; - accumulate -= *sptr++; - accumulate -= *sptr; + accumulate = twowords(&ip->ip_src); + accumulate -= twowords(&original_address); accumulate += ic2->icmp_id; accumulate -= original_id; accumulate2 = accumulate; @@ -404,9 +395,7 @@ /* Un-alias address in IP header */ DifferentialChecksum(&pip->ip_sum, - (u_short *) & original_address, - (u_short *) & pip->ip_dst, - 2); + &original_address, &pip->ip_dst, 2); pip->ip_dst = original_address; /* Un-alias address of original IP packet and sequence number of @@ -489,9 +478,7 @@ alias_address = GetAliasAddress(link); DifferentialChecksum(&pip->ip_sum, - (u_short *) & alias_address, - (u_short *) & pip->ip_src, - 2); + &alias_address, &pip->ip_src, 2); pip->ip_src = alias_address; } @@ -539,7 +526,6 @@ if (link != NULL) { if (ip->ip_p == IPPROTO_UDP || ip->ip_p == IPPROTO_TCP) { - u_short *sptr; int accumulate; struct in_addr alias_address; u_short alias_port; @@ -548,12 +534,8 @@ alias_port = GetAliasPort(link); /* Adjust ICMP checksum */ - sptr = (u_short *) & (ip->ip_dst); - accumulate = *sptr++; - accumulate += *sptr; - sptr = (u_short *) & alias_address; - accumulate -= *sptr++; - accumulate -= *sptr; + accumulate = twowords(&ip->ip_dst); + accumulate -= twowords(&alias_address); accumulate += ud->uh_dport; accumulate -= alias_port; ADJUST_CHECKSUM(accumulate, ic->icmp_cksum); @@ -564,9 +546,7 @@ */ if (pip->ip_src.s_addr == ip->ip_dst.s_addr) { DifferentialChecksum(&pip->ip_sum, - (u_short *) & alias_address, - (u_short *) & pip->ip_src, - 2); + &alias_address, &pip->ip_src, 2); pip->ip_src = alias_address; } /* Alias address and port number of original IP packet @@ -574,7 +554,6 @@ ip->ip_dst = alias_address; ud->uh_dport = alias_port; } else if (ip->ip_p == IPPROTO_ICMP) { - u_short *sptr; int accumulate; struct in_addr alias_address; u_short alias_id; @@ -583,12 +562,8 @@ alias_id = GetAliasPort(link); /* Adjust ICMP checksum */ - sptr = (u_short *) & (ip->ip_dst); - accumulate = *sptr++; - accumulate += *sptr; - sptr = (u_short *) & alias_address; - accumulate -= *sptr++; - accumulate -= *sptr; + accumulate = twowords(&ip->ip_dst); + accumulate -= twowords(&alias_address); accumulate += ic2->icmp_id; accumulate -= alias_id; ADJUST_CHECKSUM(accumulate, ic->icmp_cksum); @@ -599,9 +574,7 @@ */ if (pip->ip_src.s_addr == ip->ip_dst.s_addr) { DifferentialChecksum(&pip->ip_sum, - (u_short *) & alias_address, - (u_short *) & pip->ip_src, - 2); + &alias_address, &pip->ip_src, 2); pip->ip_src = alias_address; } /* Alias address of original IP packet and sequence number of @@ -673,9 +646,7 @@ /* Restore original IP address */ DifferentialChecksum(&pip->ip_sum, - (u_short *) & original_address, - (u_short *) & pip->ip_dst, - 2); + &original_address, &pip->ip_dst, 2); pip->ip_dst = original_address; return (PKT_ALIAS_OK); @@ -706,9 +677,7 @@ /* Change source address */ DifferentialChecksum(&pip->ip_sum, - (u_short *) & alias_address, - (u_short *) & pip->ip_src, - 2); + &alias_address, &pip->ip_src, 2); pip->ip_src = alias_address; return (PKT_ALIAS_OK); @@ -737,7 +706,6 @@ struct in_addr original_address; u_short alias_port; int accumulate; - u_short *sptr; int r = 0; alias_address = GetAliasAddress(link); @@ -762,19 +730,13 @@ if (ud->uh_sum != 0) { accumulate = alias_port; accumulate -= ud->uh_dport; - sptr = (u_short *) & alias_address; - accumulate += *sptr++; - accumulate += *sptr; - sptr = (u_short *) & original_address; - accumulate -= *sptr++; - accumulate -= *sptr; + accumulate += twowords(&alias_address); + accumulate -= twowords(&original_address); ADJUST_CHECKSUM(accumulate, ud->uh_sum); } /* Restore original IP address */ DifferentialChecksum(&pip->ip_sum, - (u_short *) & original_address, - (u_short *) & pip->ip_dst, - 2); + &original_address, &pip->ip_dst, 2); pip->ip_dst = original_address; /* @@ -834,16 +796,11 @@ /* being aliased and source address is being altered */ if (ud->uh_sum != 0) { int accumulate; - u_short *sptr; accumulate = ud->uh_sport; accumulate -= alias_port; - sptr = (u_short *) & (pip->ip_src); - accumulate += *sptr++; - accumulate += *sptr; - sptr = (u_short *) & alias_address; - accumulate -= *sptr++; - accumulate -= *sptr; + accumulate += twowords(&pip->ip_src); + accumulate -= twowords(&alias_address); ADJUST_CHECKSUM(accumulate, ud->uh_sum); } /* Put alias port in UDP header */ @@ -851,9 +808,7 @@ /* Change source address */ DifferentialChecksum(&pip->ip_sum, - (u_short *) & alias_address, - (u_short *) & pip->ip_src, - 2); + &alias_address, &pip->ip_src, 2); pip->ip_src = alias_address; return (PKT_ALIAS_OK); @@ -882,7 +837,6 @@ u_short alias_port; u_short proxy_port; int accumulate; - u_short *sptr; /* Special processing for IP encoding protocols */ if (ntohs(tc->th_dport) == PPTP_CONTROL_PORT_NUMBER @@ -903,12 +857,8 @@ /* and destination port is being altered. */ accumulate = alias_port; accumulate -= tc->th_dport; - sptr = (u_short *) & alias_address; - accumulate += *sptr++; - accumulate += *sptr; - sptr = (u_short *) & original_address; - accumulate -= *sptr++; - accumulate -= *sptr; + accumulate += twowords(&alias_address); + accumulate -= twowords(&original_address); /* If this is a proxy, then modify the TCP source port and checksum accumulation */ @@ -916,13 +866,8 @@ accumulate += tc->th_sport; tc->th_sport = proxy_port; accumulate -= tc->th_sport; - - sptr = (u_short *) & pip->ip_src; - accumulate += *sptr++; - accumulate += *sptr; - sptr = (u_short *) & proxy_address; - accumulate -= *sptr++; - accumulate -= *sptr; + accumulate += twowords(&pip->ip_src); + accumulate -= twowords(&proxy_address); } /* See if ACK number needs to be modified */ if (GetAckModified(link) == 1) { @@ -930,36 +875,23 @@ delta = GetDeltaAckIn(pip, link); if (delta != 0) { - sptr = (u_short *) & tc->th_ack; - accumulate += *sptr++; - accumulate += *sptr; + accumulate += twowords(&tc->th_ack); tc->th_ack = htonl(ntohl(tc->th_ack) - delta); - sptr = (u_short *) & tc->th_ack; - accumulate -= *sptr++; - accumulate -= *sptr; + accumulate -= twowords(&tc->th_ack); } } ADJUST_CHECKSUM(accumulate, tc->th_sum); /* Restore original IP address */ - sptr = (u_short *) & pip->ip_dst; - accumulate = *sptr++; - accumulate += *sptr; - pip->ip_dst = original_address; - sptr = (u_short *) & pip->ip_dst; - accumulate -= *sptr++; - accumulate -= *sptr; + accumulate = twowords(&pip->ip_dst); + accumulate -= twowords(&pip->ip_dst); /* If this is a transparent proxy packet, then modify the source address */ if (proxy_address.s_addr != 0) { - sptr = (u_short *) & pip->ip_src; - accumulate += *sptr++; - accumulate += *sptr; + accumulate += twowords(&pip->ip_src); pip->ip_src = proxy_address; - sptr = (u_short *) & pip->ip_src; - accumulate -= *sptr++; - accumulate -= *sptr; + accumulate -= twowords(&pip->ip_src); } ADJUST_CHECKSUM(accumulate, pip->ip_sum); @@ -995,29 +927,17 @@ dest_address = pip->ip_dst; if (proxy_type != 0) { int accumulate; - u_short *sptr; accumulate = tc->th_dport; tc->th_dport = proxy_server_port; accumulate -= tc->th_dport; - - sptr = (u_short *) & (pip->ip_dst); - accumulate += *sptr++; - accumulate += *sptr; - sptr = (u_short *) & proxy_server_address; - accumulate -= *sptr++; - accumulate -= *sptr; - + accumulate += twowords(&pip->ip_dst); + accumulate -= twowords(&proxy_server_address); ADJUST_CHECKSUM(accumulate, tc->th_sum); - sptr = (u_short *) & (pip->ip_dst); - accumulate = *sptr++; - accumulate += *sptr; + accumulate = twowords(&pip->ip_dst); pip->ip_dst = proxy_server_address; - sptr = (u_short *) & (pip->ip_dst); - accumulate -= *sptr++; - accumulate -= *sptr; - + accumulate -= twowords(&pip->ip_dst); ADJUST_CHECKSUM(accumulate, pip->ip_sum); } link = FindUdpTcpOut(la, pip->ip_src, pip->ip_dst, @@ -1027,7 +947,6 @@ u_short alias_port; struct in_addr alias_address; int accumulate; - u_short *sptr; /* Save original destination address, if this is a proxy packet. Also modify packet to include destination encoding. This may @@ -1069,13 +988,8 @@ accumulate = tc->th_sport; tc->th_sport = alias_port; accumulate -= tc->th_sport; - - sptr = (u_short *) & (pip->ip_src); - accumulate += *sptr++; - accumulate += *sptr; - sptr = (u_short *) & alias_address; - accumulate -= *sptr++; - accumulate -= *sptr; + accumulate += twowords(&pip->ip_src); + accumulate -= twowords(&alias_address); /* Modify sequence number if necessary */ if (GetAckModified(link) == 1) { @@ -1083,26 +997,17 @@ delta = GetDeltaSeqOut(pip, link); if (delta != 0) { - sptr = (u_short *) & tc->th_seq; - accumulate += *sptr++; - accumulate += *sptr; + accumulate += twowords(&tc->th_seq); tc->th_seq = htonl(ntohl(tc->th_seq) + delta); - sptr = (u_short *) & tc->th_seq; - accumulate -= *sptr++; - accumulate -= *sptr; + accumulate -= twowords(&tc->th_seq); } } ADJUST_CHECKSUM(accumulate, tc->th_sum); /* Change source address */ - sptr = (u_short *) & (pip->ip_src); - accumulate = *sptr++; - accumulate += *sptr; + accumulate = twowords(&pip->ip_src); pip->ip_src = alias_address; - sptr = (u_short *) & (pip->ip_src); - accumulate -= *sptr++; - accumulate -= *sptr; - + accumulate -= twowords(&pip->ip_src); ADJUST_CHECKSUM(accumulate, pip->ip_sum); return (PKT_ALIAS_OK); @@ -1142,9 +1047,7 @@ GetFragmentAddr(link, &original_address); DifferentialChecksum(&pip->ip_sum, - (u_short *) & original_address, - (u_short *) & pip->ip_dst, - 2); + &original_address, &pip->ip_dst, 2); pip->ip_dst = original_address; return (PKT_ALIAS_OK); @@ -1160,9 +1063,7 @@ alias_address = FindAliasAddress(la, pip->ip_src); DifferentialChecksum(&pip->ip_sum, - (u_short *) & alias_address, - (u_short *) & pip->ip_src, - 2); + &alias_address, &pip->ip_src, 2); pip->ip_src = alias_address; return (PKT_ALIAS_OK); @@ -1240,9 +1141,7 @@ fpip = (struct ip *)ptr_fragment; DifferentialChecksum(&fpip->ip_sum, - (u_short *) & pip->ip_dst, - (u_short *) & fpip->ip_dst, - 2); + &pip->ip_dst, &fpip->ip_dst, 2); fpip->ip_dst = pip->ip_dst; } @@ -1443,7 +1342,6 @@ /* Change it from an aliased packet to an unaliased packet */ if (link != NULL) { if (pip->ip_p == IPPROTO_UDP || pip->ip_p == IPPROTO_TCP) { - u_short *sptr; int accumulate; struct in_addr original_address; u_short original_port; @@ -1452,12 +1350,8 @@ original_port = GetOriginalPort(link); /* Adjust TCP/UDP checksum */ - sptr = (u_short *) & (pip->ip_src); - accumulate = *sptr++; - accumulate += *sptr; - sptr = (u_short *) & original_address; - accumulate -= *sptr++; - accumulate -= *sptr; + accumulate = twowords(&pip->ip_src); + accumulate -= twowords(&original_address); if (pip->ip_p == IPPROTO_UDP) { accumulate += ud->uh_sport; @@ -1471,9 +1365,7 @@ /* Adjust IP checksum */ DifferentialChecksum(&pip->ip_sum, - (u_short *) & original_address, - (u_short *) & pip->ip_src, - 2); + &original_address, &pip->ip_src, 2); /* Un-alias source address and port number */ pip->ip_src = original_address; @@ -1486,7 +1378,6 @@ } else if (pip->ip_p == IPPROTO_ICMP) { - u_short *sptr; int accumulate; struct in_addr original_address; u_short original_id; @@ -1495,21 +1386,15 @@ original_id = GetOriginalPort(link); /* Adjust ICMP checksum */ - sptr = (u_short *) & (pip->ip_src); - accumulate = *sptr++; - accumulate += *sptr; - sptr = (u_short *) & original_address; - accumulate -= *sptr++; - accumulate -= *sptr; + accumulate = twowords(&pip->ip_src); + accumulate -= twowords(&original_address); accumulate += ic->icmp_id; accumulate -= original_id; ADJUST_CHECKSUM(accumulate, ic->icmp_cksum); /* Adjust IP checksum */ DifferentialChecksum(&pip->ip_sum, - (u_short *) & original_address, - (u_short *) & pip->ip_src, - 2); + &original_address, &pip->ip_src, 2); /* Un-alias source address and port number */ pip->ip_src = original_address; Index: alias_local.h =================================================================== RCS file: /home/ncvs/src/lib/libalias/alias_local.h,v retrieving revision 1.26 diff -u -r1.26 alias_local.h --- alias_local.h 16 Mar 2004 21:30:41 -0000 1.26 +++ alias_local.h 16 Mar 2004 22:14:03 -0000 @@ -168,8 +168,7 @@ u_short IpChecksum(struct ip *_pip); u_short TcpChecksum(struct ip *_pip); void -DifferentialChecksum(u_short * _cksum, u_short * _new, u_short * _old, - int _n); +DifferentialChecksum(u_short * _cksum, void * _new, void * _old, int _n); /* Internal data access */ struct alias_link * Index: alias_pptp.c =================================================================== RCS file: /home/ncvs/src/lib/libalias/alias_pptp.c,v retrieving revision 1.8 diff -u -r1.8 alias_pptp.c --- alias_pptp.c 16 Mar 2004 21:30:41 -0000 1.8 +++ alias_pptp.c 16 Mar 2004 22:14:03 -0000 @@ -338,9 +338,7 @@ /* Change source IP address. */ DifferentialChecksum(&pip->ip_sum, - (u_short *) & alias_addr, - (u_short *) & pip->ip_src, - 2); + &alias_addr, &pip->ip_src, 2); pip->ip_src = alias_addr; } return (0); @@ -368,9 +366,7 @@ /* Restore original IP address. */ DifferentialChecksum(&pip->ip_sum, - (u_short *) & src_addr, - (u_short *) & pip->ip_dst, - 2); + &src_addr, &pip->ip_dst, 2); pip->ip_dst = src_addr; } return (0); Index: alias_util.c =================================================================== RCS file: /home/ncvs/src/lib/libalias/alias_util.c,v retrieving revision 1.11 diff -u -r1.11 alias_util.c --- alias_util.c 16 Mar 2004 21:30:41 -0000 1.11 +++ alias_util.c 16 Mar 2004 22:14:03 -0000 @@ -136,10 +136,12 @@ void -DifferentialChecksum(u_short * cksum, u_short * new, u_short * old, int n) +DifferentialChecksum(u_short * cksum, void *newp, void *oldp, int n) { int i; int accumulate; + u_short *new = newp; + u_short *old = oldp; accumulate = *cksum; for (i = 0; i < n; i++) { --=-=-=-- From owner-freebsd-net@FreeBSD.ORG Tue Mar 16 14:31:32 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ECBD616A4CE for ; Tue, 16 Mar 2004 14:31:32 -0800 (PST) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3131E43D2F for ; Tue, 16 Mar 2004 14:31:32 -0800 (PST) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.10/8.12.9) with ESMTP id i2GMZtee050252 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Mar 2004 00:35:56 +0200 (EET) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i2GMVZFF004151; Wed, 17 Mar 2004 00:31:35 +0200 (EET) (envelope-from ru) Date: Wed, 17 Mar 2004 00:31:34 +0200 From: Ruslan Ermilov To: manish gautam Message-ID: <20040316223134.GK3462@ip.net.ua> References: <20040316181003.62042.qmail@web8203.mail.in.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZG5hGh9V5E9QzVHS" Content-Disposition: inline In-Reply-To: <20040316181003.62042.qmail@web8203.mail.in.yahoo.com> User-Agent: Mutt/1.5.6i X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: freebsd-net@freebsd.org Subject: Re: How to test my own netgraph node ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2004 22:31:33 -0000 --ZG5hGh9V5E9QzVHS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 16, 2004 at 06:10:03PM +0000, manish gautam wrote: >=20 > Hi sir... >=20 > I have modified ng_tee.c to design my own netgraph > node. But i dont know how to test that it is working. >=20 > 1.Tell me the right procedure to test it. >=20 > 2.How can i pass incoming packet through it ? >=20 > 3.How can i print incoming packet info on prompt ? >=20 > reply as soon as possible >=20 It's a must read for anyone who'd like to get familiar with Netgraph: http://ezine.daemonnews.org/200003/netgraph.html Cheers, --=20 Ruslan Ermilov FreeBSD committer ru@FreeBSD.org --ZG5hGh9V5E9QzVHS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAV4BGUkv4P6juNwoRAiqnAJ9Ya0gHPPYpXHImIrLMSQZxusyP/QCfU6QL 5VWHP/Yw276rZKeiX0lEDc0= =ce6o -----END PGP SIGNATURE----- --ZG5hGh9V5E9QzVHS-- From owner-freebsd-net@FreeBSD.ORG Tue Mar 16 14:52:28 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D31D116A4CE; Tue, 16 Mar 2004 14:52:28 -0800 (PST) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1951E43D31; Tue, 16 Mar 2004 14:52:28 -0800 (PST) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.10/8.12.9) with ESMTP id i2GMuoee050508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Mar 2004 00:56:52 +0200 (EET) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i2GMqUGa004326; Wed, 17 Mar 2004 00:52:30 +0200 (EET) (envelope-from ru) Date: Wed, 17 Mar 2004 00:52:30 +0200 From: Ruslan Ermilov To: Dag-Erling Sm?rgrav Message-ID: <20040316225230.GO3462@ip.net.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UFMLoheMaWcIEZAi" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: current@FreeBSD.org cc: net@FreeBSD.org Subject: Re: libalias patch for review / testing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2004 22:52:29 -0000 --UFMLoheMaWcIEZAi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 16, 2004 at 11:14:23PM +0100, Dag-Erling Sm?rgrav wrote: > des@des.no (Dag-Erling Sm??rgrav) writes: > > Anybody running natd on -CURRENT, please test the attached patch >=20 > Umm, here's a patch that actually compiles. >=20 I know this code quite well. Where do you suspect could be a bug affecting -O2 compiles, or you just simply fixed -O2 and hope it will auto-fix the (possible) bugs in -O2? Cheers, --=20 Ruslan Ermilov FreeBSD committer ru@FreeBSD.org --UFMLoheMaWcIEZAi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAV4UuUkv4P6juNwoRAjCFAJ92LXEHoPF33O4Vhj199j31rFc4OQCfbDlJ vugtAxdWref9mm/mdGdUd/4= =RYTF -----END PGP SIGNATURE----- --UFMLoheMaWcIEZAi-- From owner-freebsd-net@FreeBSD.ORG Tue Mar 16 15:01:33 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E8F8E16A4CE; Tue, 16 Mar 2004 15:01:33 -0800 (PST) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0FAF643D1F; Tue, 16 Mar 2004 15:01:33 -0800 (PST) (envelope-from glebius@cell.sick.ru) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.9/8.12.8) with ESMTP id i2GN1UQE020384 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Mar 2004 02:01:30 +0300 (MSK) (envelope-from glebius@cell.sick.ru) Received: (from glebius@localhost) by cell.sick.ru (8.12.9/8.12.6/Submit) id i2GN1UGj020383; Wed, 17 Mar 2004 02:01:30 +0300 (MSK) Date: Wed, 17 Mar 2004 02:01:30 +0300 From: Gleb Smirnoff To: Ruslan Ermilov , julian@freebsd.org, archie@freebsd.org, freebsd-net@freebsd.org Message-ID: <20040316230130.GA20251@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , Ruslan Ermilov , julian@freebsd.org, archie@freebsd.org, freebsd-net@freebsd.org References: <200403072302.i27N2StR008804@freefall.freebsd.org> <20040308102033.GA66247@cell.sick.ru> <20040308212939.GB30394@ip.net.ua> <20040308214820.GA68803@cell.sick.ru> <20040309065356.GA55139@ip.net.ua> <20040309185957.GB74537@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20040309185957.GB74537@cell.sick.ru> User-Agent: Mutt/1.5.6i Subject: Nodes having common properties. Was: kern/63864: [patch] new control message for ng_iface(4) - getifindex X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2004 23:01:34 -0000 We have communicated a bit with ru in private mail. He insist on some OO like model: if we invent some generic properties for all interface nodes, they must be inherited, rather than supported by the node itself. So I have proposed a different approach, and ru liked it. What will you say about it? Two new fields in struct ng_type are introduced: - u_int32_t family, a generic node type. All current nodes have this field as 0, they have no similar properties. For example, interface node family has value of 1. - void *family_data, a pointer to a family specific data. In case of interface family, it'll be struct ifnet *. A macro for assigning to a specific family is written. This macro sets type and sets pointer to proper data. Within this approach we have got kind of inherited properties. The only thing node needs to join some family, is to set its family and pass pointer to data. After this, it will support all family messages. Family specific messages really never reach the node code. They are handled in ng_base.c. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Tue Mar 16 15:07:59 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E203116A4CE; Tue, 16 Mar 2004 15:07:59 -0800 (PST) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id A5CA043D31; Tue, 16 Mar 2004 15:07:59 -0800 (PST) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 92991530E; Wed, 17 Mar 2004 00:07:58 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 0FA0F530A; Wed, 17 Mar 2004 00:07:53 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id D79C733C6B; Wed, 17 Mar 2004 00:07:52 +0100 (CET) To: Ruslan Ermilov References: <20040316225230.GO3462@ip.net.ua> From: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Wed, 17 Mar 2004 00:07:52 +0100 In-Reply-To: <20040316225230.GO3462@ip.net.ua> (Ruslan Ermilov's message of "Wed, 17 Mar 2004 00:52:30 +0200") Message-ID: User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 cc: current@FreeBSD.org cc: net@FreeBSD.org Subject: Re: libalias patch for review / testing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2004 23:08:00 -0000 Ruslan Ermilov writes: > I know this code quite well. Where do you suspect could be a bug > affecting -O2 compiles, or you just simply fixed -O2 and hope it > will auto-fix the (possible) bugs in -O2? Since there is no inline asm, the most likely suspect is aliasing, which is what my patch tries to address. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-net@FreeBSD.ORG Tue Mar 16 15:21:47 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C52616A4CE; Tue, 16 Mar 2004 15:21:47 -0800 (PST) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id A00CE43D2D; Tue, 16 Mar 2004 15:21:46 -0800 (PST) (envelope-from arno@heho.snv.jussieu.fr) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.12.10/jtpda-5.4) with ESMTP id i2GNLjSF022056 ; Wed, 17 Mar 2004 00:21:45 +0100 (CET) X-Ids: 164 Received: from heho.snv.jussieu.fr (localhost [127.0.0.1]) i2GNLj6d046719 ; Wed, 17 Mar 2004 00:21:45 +0100 (MET) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.12.11/8.12.11/Submit) id i2GNLjsm046716; Wed, 17 Mar 2004 00:21:45 +0100 (MET) (envelope-from arno) To: net@freebsd.org References: <20240000.1079394807@palle.girgensohn.se> From: "Arno J. Klaassen" Date: 17 Mar 2004 00:21:44 +0100 In-Reply-To: <20240000.1079394807@palle.girgensohn.se> Message-ID: Lines: 62 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Miltered: at shiva.jussieu.fr with ID 40578C09.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Antivirus: scanned by sophie at shiva.jussieu.fr cc: current@freebsd.org Subject: Re: sk ethernet driver: watchdog timeout X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2004 23:21:47 -0000 Hello, > I have an ASUS motherboard A7V8X-E Deluxe with onboard 10/100/1000 > Mbit/s NIC from Marvell Semiconductor. > > My problem is that it sometimes lock up with the error message > > sk0: watchdog timeout I have a similar problem with 3Com cards on an ASUS A7N266; I just post in case this might be related (and in hope for a hint for a solution ) > This is a fresh FreeBSD 4-STABLE system. xl0 = 3c905C-TX xl1 = 3c900-COMBO switch = Netgear FS105 box netboots (using xl0) -Stable from a PPro server with same 3c905C-TX and works like a charm (network software development use, generating high network load) This weekend I pulled in an old scsi-card and disk and installed 5.2.1 and -current on it : - networking through xl0 gives me about 6Kbps throughput, unworkable but no freezes - networking through xl1 works more or less OK as long as I stick to NFS (udp-mounts), simple editing and serial makes; the first "make -j X" and/or "ar srv mylib lots-of-ofiles" generates : xl1: watchdog timeout system does not come back from lost network, at least not for the first couple of minutes whenever I try a "cvsup -g -L 2 /etc/my-supfile" or "cvs -d faraway update" I always get the same xl1: watchdog timeout after some dozens of seconds As said, same behaviour on 5.2.1 and -current from sunday. With or without acpi/apic/WITNESS does not make any difference. With or without CPUTYPE=athlon-xp either. Note, when I installed this system (at a co-worker) one year ago, I *had* to fix "AGP Aperture size" to 64M in the BIOS, otherwise the netboot failed. I just think about this, I did not test this weekend whether current -Stable (sic) works OK when changing this value. Thanx for your time, hope this helps to find a solution. I can bake a current kernel on another box and ask my coworker to test it. Regards, Arno From owner-freebsd-net@FreeBSD.ORG Tue Mar 16 15:28:47 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A0DE16A4CE; Tue, 16 Mar 2004 15:28:47 -0800 (PST) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id C3B9F43D2D; Tue, 16 Mar 2004 15:28:46 -0800 (PST) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.10/8.12.9) with ESMTP id i2GNX8ee051102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Mar 2004 01:33:10 +0200 (EET) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i2GNSmj5062513; Wed, 17 Mar 2004 01:28:48 +0200 (EET) (envelope-from ru) Date: Wed, 17 Mar 2004 01:28:48 +0200 From: Ruslan Ermilov To: Dag-Erling Sm?rgrav Message-ID: <20040316232848.GR3462@ip.net.ua> References: <20040316225230.GO3462@ip.net.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="soWJpSPh+l8Y6Fy7" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: current@freebsd.org cc: net@freebsd.org Subject: Re: libalias patch for review / testing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2004 23:28:47 -0000 --soWJpSPh+l8Y6Fy7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 17, 2004 at 12:07:52AM +0100, Dag-Erling Sm?rgrav wrote: > Ruslan Ermilov writes: > > I know this code quite well. Where do you suspect could be a bug > > affecting -O2 compiles, or you just simply fixed -O2 and hope it > > will auto-fix the (possible) bugs in -O2? >=20 > Since there is no inline asm, the most likely suspect is aliasing, > which is what my patch tries to address. >=20 Hmm, read this again: : `-fstrict-aliasing' : Allows the compiler to assume the strictest aliasing rules : applicable to the language being compiled. For C (and C++), this : activates optimizations based on the type of expressions. In : particular, an object of one type is assumed never to reside at : the same address as an object of a different type, unless the : types are almost the same. For example, an `unsigned int' can : alias an `int', but not a `void*' or a `double'. A character type : may alias any other type. And asking myself a question: should those (void *)'s in your patch be (char *)'s instead, e.g., in twowords() and DifferentialChecksum(), or am I misreading the above? Also, the easiest way to check if strict aliasing is guilty for not working libalias compiled with -O2, is to compile the original code with -O2 -fno-strict-aliasing. You guys who have seen a problem, can you please check and confirm that? Cheers, --=20 Ruslan Ermilov FreeBSD committer ru@FreeBSD.org --soWJpSPh+l8Y6Fy7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAV42wUkv4P6juNwoRAjfoAKCFmQfpsRXd7YlDm94ly3fatLaGgQCfb0kR H9QhpVVaijqCfWVt877nLd8= =UvNf -----END PGP SIGNATURE----- --soWJpSPh+l8Y6Fy7-- From owner-freebsd-net@FreeBSD.ORG Tue Mar 16 15:34:54 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 31CB516A4CE; Tue, 16 Mar 2004 15:34:54 -0800 (PST) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id DFE7043D3F; Tue, 16 Mar 2004 15:34:53 -0800 (PST) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 0078D530E; Wed, 17 Mar 2004 00:34:52 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id E1E28530A; Wed, 17 Mar 2004 00:34:46 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id 65A1C33C6B; Wed, 17 Mar 2004 00:34:46 +0100 (CET) To: Ruslan Ermilov References: <20040316225230.GO3462@ip.net.ua> <20040316232848.GR3462@ip.net.ua> From: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Wed, 17 Mar 2004 00:34:46 +0100 In-Reply-To: <20040316232848.GR3462@ip.net.ua> (Ruslan Ermilov's message of "Wed, 17 Mar 2004 01:28:48 +0200") Message-ID: User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 cc: current@freebsd.org cc: net@freebsd.org Subject: Re: libalias patch for review / testing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2004 23:34:54 -0000 Ruslan Ermilov writes: > : `-fstrict-aliasing' > : Allows the compiler to assume the strictest aliasing rules > : applicable to the language being compiled. For C (and C++), this > : activates optimizations based on the type of expressions. In > : particular, an object of one type is assumed never to reside at > : the same address as an object of a different type, unless the > : types are almost the same. For example, an `unsigned int' can > : alias an `int', but not a `void*' or a `double'. A character type > : may alias any other type. > > And asking myself a question: should those (void *)'s in your patch > be (char *)'s instead, e.g., in twowords() and DifferentialChecksum(), > or am I misreading the above? You're misreading, we're doing u_short * <-> void * (both pointers) but the man page speaks about int <-> void * (scalar vs pointer) Also, I doubt DifferentialChecksum() is a problem, since it's a function call. I think the problem may be in the code I've replaced with calls to twowords(). > Also, the easiest way to check if strict aliasing is guilty for not > working libalias compiled with -O2, is to compile the original code > with -O2 -fno-strict-aliasing. True, I didn't think of that. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-net@FreeBSD.ORG Tue Mar 16 15:54:16 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E34216A4CE; Tue, 16 Mar 2004 15:54:16 -0800 (PST) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id A0FAD43D31; Tue, 16 Mar 2004 15:54:15 -0800 (PST) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.10/8.12.9) with ESMTP id i2GNwbee051379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Mar 2004 01:58:39 +0200 (EET) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i2GNsHiM048275; Wed, 17 Mar 2004 01:54:17 +0200 (EET) (envelope-from ru) Date: Wed, 17 Mar 2004 01:54:17 +0200 From: Ruslan Ermilov To: Dag-Erling Sm?rgrav Message-ID: <20040316235417.GC65466@ip.net.ua> References: <20040316225230.GO3462@ip.net.ua> <20040316232848.GR3462@ip.net.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zCKi3GIZzVBPywwA" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: current@freebsd.org cc: net@freebsd.org Subject: Re: libalias patch for review / testing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2004 23:54:16 -0000 --zCKi3GIZzVBPywwA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 17, 2004 at 12:34:46AM +0100, Dag-Erling Sm?rgrav wrote: > Ruslan Ermilov writes: > > : `-fstrict-aliasing' > > : Allows the compiler to assume the strictest aliasing rules > > : applicable to the language being compiled. For C (and C++), this > > : activates optimizations based on the type of expressions. In > > : particular, an object of one type is assumed never to reside at > > : the same address as an object of a different type, unless the > > : types are almost the same. For example, an `unsigned int' can > > : alias an `int', but not a `void*' or a `double'. A character ty= pe > > : may alias any other type. > > > > And asking myself a question: should those (void *)'s in your patch > > be (char *)'s instead, e.g., in twowords() and DifferentialChecksum(), > > or am I misreading the above? >=20 > You're misreading, we're doing u_short * <-> void * (both pointers) > but the man page speaks about int <-> void * (scalar vs pointer) >=20 OK, I stand corrected. ;) > Also, I doubt DifferentialChecksum() is a problem, since it's a > function call. I think the problem may be in the code I've replaced > with calls to twowords(). >=20 Hmm, now that I think about it more, since -O2 turns -fstrict-aliasing, and the latter may produce broken code if strict aliasing rules are broken by the source, I think people (and tinderboxes!) should compile with ``-O2 -Wstrict-aliasing'' in CFLAGS rather than just -O2. For WARNS > 1 compiled code, this will be a no-op (as -Wall implies -Wstrict-aliasing), but it should help catch bugs related to breaking strict aliasing like in libalias, in code that is otherwise compiled without warnings. Cheers, --=20 Ruslan Ermilov FreeBSD committer ru@FreeBSD.org --zCKi3GIZzVBPywwA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAV5OpUkv4P6juNwoRAkGQAJ4sQy7mMiNCgX4b7vsc2HS+ZKYbHgCfcApJ Sbn6Z6pnxETzw2ZoQphZWXk= =tR29 -----END PGP SIGNATURE----- --zCKi3GIZzVBPywwA-- From owner-freebsd-net@FreeBSD.ORG Tue Mar 16 16:06:16 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8037A16A4CE for ; Tue, 16 Mar 2004 16:06:16 -0800 (PST) Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F0A743D1D for ; Tue, 16 Mar 2004 16:06:16 -0800 (PST) (envelope-from cristjc@comcast.net) Received: from blossom.cjclark.org (c-67-169-127-171.client.comcast.net[67.169.127.171]) by comcast.net (sccrmhc12) with ESMTP id <2004031700061401200nbkfre>; Wed, 17 Mar 2004 00:06:14 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.9p2/8.12.8) with ESMTP id i2H06D0m051809; Tue, 16 Mar 2004 16:06:13 -0800 (PST) (envelope-from cristjc@comcast.net) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.9p2/8.12.9/Submit) id i2H06B2D051808; Tue, 16 Mar 2004 16:06:11 -0800 (PST) (envelope-from cristjc@comcast.net) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to cristjc@comcast.net using -f Date: Tue, 16 Mar 2004 16:06:11 -0800 From: "Crist J. Clark" To: Zherdev Anatoly Message-ID: <20040317000611.GA51156@blossom.cjclark.org> References: <20040316125335.5f64cac5@dwarf.demos.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040316125335.5f64cac5@dwarf.demos.su> User-Agent: Mutt/1.4.1i X-URL: http://people.freebsd.org/~cjc/ cc: freebsd-net@freebsd.org Subject: Re: Problem with closing tcp session between cisco and freebsd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Crist J. Clark" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2004 00:06:16 -0000 On Tue, Mar 16, 2004 at 12:53:35PM +0300, Zherdev Anatoly wrote: > Hello. > > I have problem with tcp session close between cisco and freebsd > Looks like that it bug in freebsd tcp stack. > > CISCO state: > > sh tcp brief > 62935208 CISCO..990 FREEBSD.513 FINWAIT1 > > > FreeBSD state: > > netstat -an > tcp4 57352 0 FREEBSD.513 CISCO.990 ESTABLISHED > > > TCP session from cisco side: > > IP: s=CISCO (local), d=FREEBSD (FastEthernet0), len 41, > sending TCP src=990, dst=513, seq=1411875745, ack=880111139, win=3983 ACK > PSH FIN > > IP: s=FREEBSD (FastEthernet0), d=CISCO (FastEthernet0), len > 40, rcvd 3 TCP src=513, dst=990, seq=880111139, ack=1411875745, win=0 ACK [snip] ^ > TCP session from FreeBSD side: > > 12:16:25.426584 IP CISCO.990 > FREEBSD.login: FP 1411875745:1411875746(1) ack 880111139 win 3714 > > 12:16:25.426675 IP FREEBSD.login > CISCO.990: . ack 1411875745 win 0 ^ The zero window-size tells me the TCP buffer on the FreeBSD side is full. The Cisco is trying to send that last byte of data and the FIN, but the FreeBSD side cannot accept it since the buffer is full. This usually means the application on the FreeBSD side is not reading the data out of the socket. What's the 'netstat -an' for this connection on the FreeBSD side? -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org From owner-freebsd-net@FreeBSD.ORG Tue Mar 16 21:25:12 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7109F16A4CE for ; Tue, 16 Mar 2004 21:25:12 -0800 (PST) Received: from anduril.ncsa.uiuc.edu (cab-wireless-120.ncsa.uiuc.edu [141.142.102.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32E6343D3F for ; Tue, 16 Mar 2004 21:25:12 -0800 (PST) (envelope-from jdugan@anduril.ncsa.uiuc.edu) Received: by anduril.ncsa.uiuc.edu (Postfix, from userid 501) id C16DA15956A; Tue, 16 Mar 2004 23:25:11 -0600 (CST) Date: Tue, 16 Mar 2004 23:25:11 -0600 From: Jon Dugan To: freebsd-net@freebsd.org Message-ID: <20040317052511.GA4664@ncsa.uiuc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Subject: UDP bind(2) on the same port using SO_REUSEADDR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2004 05:25:12 -0000 Imagine two process, A & B. Process A which has a UDP socket bound to a specific address of the machine and a particular port (host:port, say 10.10.10.1:1234). If I set SO_REUSEADDR for the socket in Process B I am able to use the wildcard address (INADDR_ANY or 0.0.0.0) in Process B to bind to the same port (*:port, eg. *:1234). You can also do the converse, process A can bind to the wildcard address and process B can use a specific address). Unix Network Programming by W. Richard Stevens mentions this on pages 195-6 and actually says that using SO_REUSEADDR it is possible to bind to the same address:port tuple as another already running process. I was unable to do do that. Stevens goes on to say that the multiple binding is usually used for multicast, which makes sense. Should it be allowed at all for unicast? I am able to do this in 4.4-RELEASE, 4.9-RELEASE and 5.1-RELEASE. I'm not at all certain this is a bug, but it is certainly somewhat non-obvious behaviour. Is this a bug or and oddity? It came up because I am using rtg to poll many interfaces on a couple of routers on 5 second intervals (gotta love those Junipers, they don't even bat an eye). rtg uses the net-snmp library. The same machine also runs a radius server listening on the radius port (1812). radiusd bound to the socket using a specific address. rtg/net-snmp just ask for the next available port and use the wildcard address. Once in awhile (actually every 5-10 minutes) rtg/net-snmp would do an snmp get using port 1812 which the system had given to it, but radiusd would end up getting the results. This causes indigestion in radiusd... Since I spent quite a bit of time running this down today I figured I'd share with the class. Jon -- Jon Dugan | Senior Network Engineer, NCSA Network Research jdugan@ncsa.uiuc.edu | 269 CAB, 605 E Springfield, Champaign, IL 61820 217-244-7715 | http://www.ncsa.uiuc.edu/~jdugan/ From owner-freebsd-net@FreeBSD.ORG Tue Mar 16 23:14:56 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 63FD316A4CE; Tue, 16 Mar 2004 23:14:56 -0800 (PST) Received: from demos.su (mx.demos.su [194.87.0.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F97043D1F; Tue, 16 Mar 2004 23:14:55 -0800 (PST) (envelope-from tolyar@mx.ru) Received: from [194.87.2.159] (HELO dwarf.demos.su) by demos.su (CommuniGate Pro SMTP 4.1.8/D) with SMTP id 179727296; Wed, 17 Mar 2004 10:14:53 +0300 Date: Wed, 17 Mar 2004 10:14:53 +0300 From: Zherdev Anatoly To: "Crist J. Clark" Message-Id: <20040317101453.5fcdaa82@dwarf.demos.su> In-Reply-To: <20040317000611.GA51156@blossom.cjclark.org> References: <20040316125335.5f64cac5@dwarf.demos.su> <20040317000611.GA51156@blossom.cjclark.org> X-Mailer: Sylpheed version 0.9.9claws (GTK+ 1.2.10; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: cristjc@comcast.net Subject: Re: Problem with closing tcp session between cisco and freebsd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2004 07:14:56 -0000 On Tue, 16 Mar 2004 16:06:11 -0800 "Crist J. Clark" wrote: [Skip...] ^ > The zero window-size tells me the TCP buffer on the FreeBSD side is > full. The Cisco is trying to send that last byte of data and the FIN, > but the FreeBSD side cannot accept it since the buffer is full. This > usually means the application on the FreeBSD side is not reading the > data out of the socket. > > What's the 'netstat -an' for this connection on the FreeBSD side? There is netstat -an for this session tcp4 57352 0 FREEBSD.513 CISCO.990 ESTABLISHED -- Zherdev Anatoly. From owner-freebsd-net@FreeBSD.ORG Tue Mar 16 23:40:00 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8DC8E16A4CE for ; Tue, 16 Mar 2004 23:40:00 -0800 (PST) Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by mx1.FreeBSD.org (Postfix) with ESMTP id 01EE743D2D for ; Tue, 16 Mar 2004 23:40:00 -0800 (PST) (envelope-from cristjc@comcast.net) Received: from blossom.cjclark.org (c-67-169-127-171.client.comcast.net[67.169.127.171]) by comcast.net (sccrmhc12) with ESMTP id <2004031707395801200n7qeme>; Wed, 17 Mar 2004 07:39:58 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.9p2/8.12.8) with ESMTP id i2H7du0m052803; Tue, 16 Mar 2004 23:39:57 -0800 (PST) (envelope-from cristjc@comcast.net) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.9p2/8.12.9/Submit) id i2H7dueJ052802; Tue, 16 Mar 2004 23:39:56 -0800 (PST) (envelope-from cristjc@comcast.net) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to cristjc@comcast.net using -f Date: Tue, 16 Mar 2004 23:39:56 -0800 From: "Crist J. Clark" To: Zherdev Anatoly Message-ID: <20040317073956.GA52536@blossom.cjclark.org> References: <20040316125335.5f64cac5@dwarf.demos.su> <20040317000611.GA51156@blossom.cjclark.org> <20040317101453.5fcdaa82@dwarf.demos.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040317101453.5fcdaa82@dwarf.demos.su> User-Agent: Mutt/1.4.1i X-URL: http://people.freebsd.org/~cjc/ cc: freebsd-net@freebsd.org cc: cristjc@comcast.net Subject: Re: Problem with closing tcp session between cisco and freebsd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: cjclark@alum.mit.edu List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2004 07:40:00 -0000 On Wed, Mar 17, 2004 at 10:14:53AM +0300, Zherdev Anatoly wrote: > On Tue, 16 Mar 2004 16:06:11 -0800 > "Crist J. Clark" wrote: > > > [Skip...] > ^ > > The zero window-size tells me the TCP buffer on the FreeBSD side is > > full. The Cisco is trying to send that last byte of data and the FIN, > > but the FreeBSD side cannot accept it since the buffer is full. This > > usually means the application on the FreeBSD side is not reading the > > data out of the socket. > > > > What's the 'netstat -an' for this connection on the FreeBSD side? > > There is netstat -an for this session > > tcp4 57352 0 FREEBSD.513 CISCO.990 ESTABLISHED ^^^^^ This is the Recv-Q. That value wouldn't happen to coincide with the value of, $ sysctl net.inet.tcp.recvspace But it looks like my guess is probably correct. The receive buffer at the FreeBSD end is full. When it receives more TCP data, it cannot accept it so it ACKs up to whatever it has in the buffer and not what the sender sent in the last segment. It also sends a window size of zero to tell the sender it's not accepting more data at the moment. You need to flush the buffer at the FreeBSD end. The program receiving on that socket needs to read the data. If the process is frozen, kill it and things should clear up. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org From owner-freebsd-net@FreeBSD.ORG Wed Mar 17 00:00:07 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4BCD316A4CE for ; Wed, 17 Mar 2004 00:00:07 -0800 (PST) Received: from demos.su (mx.demos.su [194.87.0.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5CB4C43D41 for ; Wed, 17 Mar 2004 00:00:06 -0800 (PST) (envelope-from tolyar@mx.ru) Received: from [194.87.2.159] (HELO dwarf.demos.su) by demos.su (CommuniGate Pro SMTP 4.1.8/D) with SMTP id 179751335; Wed, 17 Mar 2004 11:00:05 +0300 Date: Wed, 17 Mar 2004 11:00:05 +0300 From: Zherdev Anatoly To: cjclark@alum.mit.edu Message-Id: <20040317110005.3925a22a@dwarf.demos.su> In-Reply-To: <20040317073956.GA52536@blossom.cjclark.org> References: <20040316125335.5f64cac5@dwarf.demos.su> <20040317000611.GA51156@blossom.cjclark.org> <20040317101453.5fcdaa82@dwarf.demos.su> <20040317073956.GA52536@blossom.cjclark.org> X-Mailer: Sylpheed version 0.9.9claws (GTK+ 1.2.10; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: cristjc@comcast.net Subject: Re: Problem with closing tcp session between cisco and freebsd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2004 08:00:07 -0000 On Tue, 16 Mar 2004 23:39:56 -0800 "Crist J. Clark" wrote: > But it looks like my guess is probably correct. The receive buffer at > the FreeBSD end is full. When it receives more TCP data, it cannot > accept it so it ACKs up to whatever it has in the buffer and not what > the sender sent in the last segment. It also sends a window size of > zero to tell the sender it's not accepting more data at the moment. > > You need to flush the buffer at the FreeBSD end. The program receiving > on that socket needs to read the data. If the process is frozen, kill > it and things should clear up. OK. Thak you. I will find problems in programs. -- Zherdev Anatoly. From owner-freebsd-net@FreeBSD.ORG Wed Mar 17 01:16:53 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3308D16A4CE for ; Wed, 17 Mar 2004 01:16:53 -0800 (PST) Received: from proton.hexanet.fr (proton.hexanet.fr [81.23.32.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B4B343D41 for ; Wed, 17 Mar 2004 01:16:52 -0800 (PST) (envelope-from c.prevotaux@hexanet.fr) Received: from hexanet.fr (localhost [127.0.0.1]) by proton.hexanet.fr (Postfix) with SMTP id BCE854C963 for ; Wed, 17 Mar 2004 10:16:50 +0100 (CET) Date: Wed, 17 Mar 2004 10:16:50 +0100 From: Christophe Prevotaux To: freebsd-net@freebsd.org Message-Id: <20040317101650.4558f1c4.c.prevotaux@hexanet.fr> Organization: HEXANET Sarl X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i386-portbld-freebsd4.9) X-NCC-RegID: fr.hexanet Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: MPLS and Netgraph X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2004 09:16:53 -0000 Hi, Is someone working or has already done an implementation of a netgraph MPLS stack?=20 -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Christophe Prevotaux Email: c.prevotaux@hexanet.fr HEXANET SARL URL: http://www.hexanet.fr/ Z.A.C Les Charmilles Tel: +33 (0)3 26 79 30 05=20 3 All=E9e Thierry Sabine Direct: +33 (0)3 26 61 77 72=20 BP202 Fax: +33 (0)3 26 79 30 06 51686 Reims Cedex 2 =20 FRANCE HEXANET Network Operation Center =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From owner-freebsd-net@FreeBSD.ORG Wed Mar 17 03:32:07 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 37B5B16A4CE for ; Wed, 17 Mar 2004 03:32:07 -0800 (PST) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 282B943D46 for ; Wed, 17 Mar 2004 03:32:07 -0800 (PST) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.8) with ESMTP id i2HBW6RS024010; Wed, 17 Mar 2004 03:32:06 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i2HBW6NV024009; Wed, 17 Mar 2004 03:32:06 -0800 (PST) (envelope-from rizzo) Date: Wed, 17 Mar 2004 03:32:06 -0800 From: Luigi Rizzo To: Karim Fodil-Lemelin Message-ID: <20040317033206.A23760@xorpc.icir.org> References: <40575A8F.8090402@xiphos.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <40575A8F.8090402@xiphos.ca>; from kfl@xiphos.ca on Tue, Mar 16, 2004 at 02:50:39PM -0500 cc: freebsd-net@freebsd.org Subject: Re: Dummynet Limitations X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2004 11:32:07 -0000 On Tue, Mar 16, 2004 at 02:50:39PM -0500, Karim Fodil-Lemelin wrote: > Hi > > This code: > > > if (pipe.delay > 10000) > errx(EX_DATAERR, "delay %d must be < 10000", > pipe.delay); > > > in /usr/src/sbin/ipfw/ipfw.c > > Limits the pipe delay for dummynet to 10 seconds. Is there any reason > for this? Also, no such limit is imposed on the bandwidth why? > Memory (amount of mbufs/mbclusters) is obviously a limit here but I was > wondering if something else was hidden in this statement. back in 1996 when i wrote that line of code, my test machine had 16MB of RAM and i did not want to exhaust it with a poorly configured pipe. You are certainly welcome to increase it or even better make it into a sysctl variable. But keep in mind that pipe.delay is the propagation delay, and i cannot make any sense (except for simulating deep-space communications) of a larger delay, in which case, though, communication is so peculiar that almost surely you need a different test environment, not something IP-based as dummynet. Also, in such cases, you probably want to simulate things faster than realtime -- makes no sense to send a packet and wait hours for it to be delivered. cheers luigi From owner-freebsd-net@FreeBSD.ORG Wed Mar 17 03:52:55 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 74DD416A4CE for ; Wed, 17 Mar 2004 03:52:55 -0800 (PST) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id 9F65F43D6B for ; Wed, 17 Mar 2004 03:52:54 -0800 (PST) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 17 Mar 2004 11:52:53 +0000 (GMT) To: freebsd-net@freebsd.org X-Request-Do: Date: Wed, 17 Mar 2004 11:52:53 +0000 From: David Malone Message-ID: <200403171152.aa43952@salmon.maths.tcd.ie> Subject: PPPoE buglet... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2004 11:52:55 -0000 I spent a while trying to get PPPoE going through a Netopia smart modem last night. To cut a long story short, the values for PTT_RELAY_SID in src/sys/netgraph/ng_pppoe.h are wrong (at least when compared with tcpdump, linux and the RFC). We have: #if BYTE_ORDER == BIG_ENDIAN #define PTT_RELAY_SID (0x0106) #else #define PTT_RELAY_SID (0x0601) #endif but we should have: #if BYTE_ORDER == BIG_ENDIAN #define PTT_RELAY_SID (0x0110) #else #define PTT_RELAY_SID (0x1001) #endif Anyone object to my fixing it? The only thing I can think of that it might break would be people using ng_pppoe as a PPPoE relay with only ng_pppoe PPPoE clients. David. From owner-freebsd-net@FreeBSD.ORG Wed Mar 17 04:41:38 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 93E6616A4CE for ; Wed, 17 Mar 2004 04:41:38 -0800 (PST) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id D173E43D6B for ; Wed, 17 Mar 2004 04:41:37 -0800 (PST) (envelope-from glebius@cell.sick.ru) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.9/8.12.8) with ESMTP id i2HCfZQE024449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Mar 2004 15:41:36 +0300 (MSK) (envelope-from glebius@cell.sick.ru) Received: (from glebius@localhost) by cell.sick.ru (8.12.9/8.12.6/Submit) id i2HCfZDv024448; Wed, 17 Mar 2004 15:41:35 +0300 (MSK) Date: Wed, 17 Mar 2004 15:41:34 +0300 From: Gleb Smirnoff To: David Malone Message-ID: <20040317124134.GC23881@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , David Malone , freebsd-net@freebsd.org References: <200403171152.aa43952@salmon.maths.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <200403171152.aa43952@salmon.maths.tcd.ie> User-Agent: Mutt/1.5.6i cc: freebsd-net@freebsd.org Subject: Re: PPPoE buglet... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2004 12:41:38 -0000 On Wed, Mar 17, 2004 at 11:52:53AM +0000, David Malone wrote: D> I spent a while trying to get PPPoE going through a Netopia smart D> modem last night. To cut a long story short, the values for D> PTT_RELAY_SID in src/sys/netgraph/ng_pppoe.h are wrong (at least D> when compared with tcpdump, linux and the RFC). We have: D> D> #if BYTE_ORDER == BIG_ENDIAN D> #define PTT_RELAY_SID (0x0106) D> #else D> #define PTT_RELAY_SID (0x0601) D> #endif D> D> but we should have: D> D> #if BYTE_ORDER == BIG_ENDIAN D> #define PTT_RELAY_SID (0x0110) D> #else D> #define PTT_RELAY_SID (0x1001) D> #endif Yes. This was noticed more than a year ago in kern/44936. D> Anyone object to my fixing it? The only thing I can think of that D> it might break would be people using ng_pppoe as a PPPoE relay with D> only ng_pppoe PPPoE clients. AFAIK, ng_pppoe is not able to act as a relay. Consequently, it never inserts incorrect tag. Thus no one uses incorrect tag and ng_pppoe never inserts it, the statement "case PTT_RELAY_SID" never returns true. Therefore, currently PTT_RELAY_SID is not used at all. So, fixing it won't break anything. And ng_pppoe based ACs will be able to work with relay agents, which is good. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Wed Mar 17 05:32:22 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A3F5F16A4CF for ; Wed, 17 Mar 2004 05:32:22 -0800 (PST) Received: from proton.hexanet.fr (proton.hexanet.fr [81.23.32.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id E8B7F43D2F for ; Wed, 17 Mar 2004 05:32:21 -0800 (PST) (envelope-from c.prevotaux@hexanet.fr) Received: from hexanet.fr (localhost [127.0.0.1]) by proton.hexanet.fr (Postfix) with SMTP id 7F7B44C963; Wed, 17 Mar 2004 14:32:20 +0100 (CET) Date: Wed, 17 Mar 2004 14:32:20 +0100 From: Christophe Prevotaux To: David Malone Message-Id: <20040317143220.6cd28174.c.prevotaux@hexanet.fr> In-Reply-To: <200403171152.aa43952@salmon.maths.tcd.ie> References: <200403171152.aa43952@salmon.maths.tcd.ie> Organization: HEXANET Sarl X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i386-portbld-freebsd4.9) X-NCC-RegID: fr.hexanet Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable cc: freebsd-net@freebsd.org Subject: Re: PPPoE buglet... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2004 13:32:22 -0000 Yes please fix it.=20 On Wed, 17 Mar 2004 11:52:53 +0000 David Malone wrote: > I spent a while trying to get PPPoE going through a Netopia smart > modem last night. To cut a long story short, the values for > PTT_RELAY_SID in src/sys/netgraph/ng_pppoe.h are wrong (at least > when compared with tcpdump, linux and the RFC). We have: >=20 > #if BYTE_ORDER =3D=3D BIG_ENDIAN > #define PTT_RELAY_SID (0x0106) > #else > #define PTT_RELAY_SID (0x0601) > #endif >=20 > but we should have: >=20 > #if BYTE_ORDER =3D=3D BIG_ENDIAN > #define PTT_RELAY_SID (0x0110) > #else > #define PTT_RELAY_SID (0x1001) > #endif >=20 > Anyone object to my fixing it? The only thing I can think of that > it might break would be people using ng_pppoe as a PPPoE relay with > only ng_pppoe PPPoE clients. >=20 -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Christophe Prevotaux Email: c.prevotaux@hexanet.fr HEXANET SARL URL: http://www.hexanet.fr/ Z.A.C Les Charmilles Tel: +33 (0)3 26 79 30 05=20 3 All=E9e Thierry Sabine Direct: +33 (0)3 26 61 77 72=20 BP202 Fax: +33 (0)3 26 79 30 06 51686 Reims Cedex 2 =20 FRANCE HEXANET Network Operation Center =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From owner-freebsd-net@FreeBSD.ORG Wed Mar 17 09:10:13 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 22A9A16A4CE for ; Wed, 17 Mar 2004 09:10:13 -0800 (PST) Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by mx1.FreeBSD.org (Postfix) with ESMTP id D7B8C43D39 for ; Wed, 17 Mar 2004 09:10:12 -0800 (PST) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (sccrmhc12) with ESMTP id <2004031717101101200nd2aoe>; Wed, 17 Mar 2004 17:10:11 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id JAA72529; Wed, 17 Mar 2004 09:10:10 -0800 (PST) Date: Wed, 17 Mar 2004 09:10:07 -0800 (PST) From: Julian Elischer To: David Malone In-Reply-To: <200403171152.aa43952@salmon.maths.tcd.ie> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: PPPoE buglet... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2004 17:10:13 -0000 The RFC is al that matters (except for the compatibility code for idiot suppliers that use the wrong ethertype.) Is there a 110 or 1001 nearby that I may have read in error in the spec? On Wed, 17 Mar 2004, David Malone wrote: > I spent a while trying to get PPPoE going through a Netopia smart > modem last night. To cut a long story short, the values for > PTT_RELAY_SID in src/sys/netgraph/ng_pppoe.h are wrong (at least > when compared with tcpdump, linux and the RFC). We have: > > #if BYTE_ORDER == BIG_ENDIAN > #define PTT_RELAY_SID (0x0106) > #else > #define PTT_RELAY_SID (0x0601) > #endif > > but we should have: > > #if BYTE_ORDER == BIG_ENDIAN > #define PTT_RELAY_SID (0x0110) > #else > #define PTT_RELAY_SID (0x1001) > #endif > > Anyone object to my fixing it? The only thing I can think of that > it might break would be people using ng_pppoe as a PPPoE relay with > only ng_pppoe PPPoE clients. > > David. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Wed Mar 17 09:26:41 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF0A916A4CF for ; Wed, 17 Mar 2004 09:26:40 -0800 (PST) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3732543D3F for ; Wed, 17 Mar 2004 09:26:40 -0800 (PST) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id 3DD871FFDC1; Wed, 17 Mar 2004 18:26:38 +0100 (CET) Received: by transport.cksoft.de (Postfix, from userid 66) id 5B6B41FFDBC; Wed, 17 Mar 2004 18:26:36 +0100 (CET) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id CF21F154FC; Wed, 17 Mar 2004 17:26:28 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id C44B915384; Wed, 17 Mar 2004 17:26:28 +0000 (UTC) Date: Wed, 17 Mar 2004 17:26:28 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: Julian Elischer In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de cc: David Malone cc: freebsd-net@freebsd.org Subject: Re: PPPoE buglet... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2004 17:26:41 -0000 On Wed, 17 Mar 2004, Julian Elischer wrote: > On Wed, 17 Mar 2004, David Malone wrote: > > > I spent a while trying to get PPPoE going through a Netopia smart > > modem last night. To cut a long story short, the values for > > PTT_RELAY_SID in src/sys/netgraph/ng_pppoe.h are wrong (at least > > when compared with tcpdump, linux and the RFC). We have: > > > > #if BYTE_ORDER == BIG_ENDIAN > > #define PTT_RELAY_SID (0x0106) > > #else > > #define PTT_RELAY_SID (0x0601) > > #endif > > > > but we should have: > > > > #if BYTE_ORDER == BIG_ENDIAN > > #define PTT_RELAY_SID (0x0110) > > #else > > #define PTT_RELAY_SID (0x1001) > > #endif > > > > Anyone object to my fixing it? The only thing I can think of that > > it might break would be people using ng_pppoe as a PPPoE relay with > > only ng_pppoe PPPoE clients. > > The RFC is al that matters (except for > the compatibility code for idiot suppliers that use the wrong > ethertype.) > > Is there a 110 or 1001 nearby that I may have read in error in the spec? 0x0110 Relay-Session-Id I think you might just have incremented the number as the paragraphs before go 0x0101, 0x0102, 0x0103, 0x0104, 0x0105, 0x010610 *uups* ;-) PS: and please no TOFU. -- Greetings Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/ From owner-freebsd-net@FreeBSD.ORG Wed Mar 17 14:56:16 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1791416A4CE for ; Wed, 17 Mar 2004 14:56:16 -0800 (PST) Received: from blake.polstra.com (blake.polstra.com [64.81.189.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id A05E843D3F for ; Wed, 17 Mar 2004 14:56:15 -0800 (PST) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (dsl081-189-067.sea1.dsl.speakeasy.net [64.81.189.67]) by blake.polstra.com (8.12.11/8.12.11) with ESMTP id i2HMuEfD040747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Mar 2004 14:56:15 -0800 (PST) (envelope-from jdp@strings.polstra.com) Received: (from jdp@localhost) by strings.polstra.com (8.12.11/8.12.11/Submit) id i2HMuEdC028110; Wed, 17 Mar 2004 14:56:14 -0800 (PST) (envelope-from jdp) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <2697.192.168.0.200.1079398101.squirrel@192.168.0.1> Date: Wed, 17 Mar 2004 14:56:14 -0800 (PST) From: John Polstra To: Mike Jakubik X-Bogosity: No, tests=bogofilter, spamicity=0.512747, version=0.14.5 cc: net@freebsd.org Subject: Re: Byte counters reset at ~4GB X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2004 22:56:16 -0000 On 16-Mar-2004 Mike Jakubik wrote: > > Got it. In just curious though... realistically, how big of an impact on > performance is this on a modern CPU? Is it not simply the original 32bit > calculation x 2? Please, just search the mailing list archives. We've already had this discussion in depth. It is not the original 32-bit calculation times two, because in order to keep it atomic on a 32-bit machine you have to use locking or a LOCK prefix or something expensive like that. Now, you tenors and altos over there: this is not your cue to repeat verse 3 where you sing all about how maybe atomicity might not be needed in this case. You already sang that one, and it's in the archives, remember? In fact, we've already sung the whole song, and the audience doesn't want to hear it again. They've got the CD, and it's called The Mailing List Archives. OK? OK! John (still working on that Bill Paul imitation) From owner-freebsd-net@FreeBSD.ORG Wed Mar 17 15:35:51 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4E94D16A4CE for ; Wed, 17 Mar 2004 15:35:51 -0800 (PST) Received: from horse.lucky.net (horse.carrier.kiev.ua [193.193.193.118]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3340A43D1F for ; Wed, 17 Mar 2004 15:35:49 -0800 (PST) (envelope-from news+freebsd-arts@news1.lucky.net) Received: from horse.lucky.net (news@localhost) by horse.lucky.net (8.11.6p2/8.11.6) with ESMTP id i2HNZjs58251 for ; Thu, 18 Mar 2004 01:35:45 +0200 (EET) (envelope-from news+freebsd-arts@news1.lucky.net) X-Authentication-Warning: horse.lucky.net: news owned process doing -bs To: freebsd-net@freebsd.org From: Alexander Motin Date: Wed, 17 Mar 2004 19:28:20 +0200 Organization: Alkar Teleport News Server Message-ID: References: <20040314091814.79495.qmail@istanbul.enderunix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: pandora.alkar.net 1079544501 92731 212.86.226.11 (17 Mar 2004 17:28:21 GMT) User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040119 X-Accept-Language: ru, en-us, en In-Reply-To: <20040314091814.79495.qmail@istanbul.enderunix.org> Sender: Alkar Teleport News Subsystem X-Verify-Sender: verified Subject: Re: mpd lcp question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2004 23:35:51 -0000 Hi Omer Faruk Sen wrote: > Hi, > I have set up an mpd server. But there is a problem. When I try to > connect with my home pc logs are generated like this: > ------------------------------------------------------ > [pptp] LCP: state change Req-Sent --> Ack-Sent > [pptp] LCP: SendConfigReq #2 > ACFCOMP > PROTOCOMP > MRU 1500 > MAGICNUM d3dbc780 > AUTHPROTO CHAP MSOFTv2 > MP MRRU 1600 > MP SHORTSEQ > ENDPOINTDISC [802.1] 00 90 27 d6 1c 0b > [pptp] LCP: rec'd Configure Reject #2 link 0 (Ack-Sent) > MP MRRU 1600 > MP SHORTSEQ > ENDPOINTDISC [802.1] 00 90 27 d6 1c 0b > [pptp] LCP: SendConfigReq #3 > ACFCOMP > PROTOCOMP > MRU 1500 > MAGICNUM d3dbc780 > AUTHPROTO CHAP MSOFTv2 > [pptp] LCP: rec'd Configure Ack #3 link 0 (Ack-Sent) > ACFCOMP > PROTOCOMP > MRU 1500 > MAGICNUM d3dbc780 > AUTHPROTO CHAP MSOFTv2 > [pptp] LCP: state change Ack-Sent --> Opened > ------------------------------------------------- > As you see from above and below (which is a partial copy of above) > [pptp] LCP: rec'd Configure Reject #2 link 0 (Ack-Sent) > MP MRRU 1600 > MP SHORTSEQ > ENDPOINTDISC [802.1] 00 90 27 d6 1c 0b > As far as I understand "mp mrru 1600", "mp shortseq" and "endpoint ..." > capabilities are rejected by mpd server. My windowsXP client sends > connection request with removing those capabilities and vpn connection > is established perfectly.. > But some XP and most Windows2k clients insists on those capabilities > rejected by mpd server thus connection is no established with an LCP error. > Is there a workaround or a way to enable "mp mrru 1600", "mp shortseq" > and "endpoint ..." properties on mpd server? Add set bundle enable multilink into your config file and mpd will support that options. > My configuration is like this: > -----mpd.conf----------- > default: > load pptp > > pptp: > new -i ng0 pptp pptp > set iface disable on-demand > set iface enable proxy-arp > set iface idle 1800 > set iface enable tcpmssfix > # set bundle enable multilink > # enable TCP-Wrapper (hosts_access(5)) to block unfriendly clients > # set bundle enable tcp-wrapper > # use RADIUS servers > # load radius > set link yes acfcomp protocomp > #set iface route default > set iface route 10.0.0.0/22 > set link no pap chap > set link enable chap > set link keep-alive 10 60 > set link mtu 1460 > set link mtu 1500 > set ipcp yes vjcomp > set ipcp ranges 10.0.0.26/32 10.0.0.54/32 > #set ipcp dns 192.168.1.3 > # 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.conf------------ > > -----mpd.links------- > pptp: > set link type pptp > set pptp self SERVER_IP > set pptp enable incoming > set pptp disable originate > -------mpd.links--------- > > ----------------------- > Omer Faruk Sen > http://www.EnderUNIX.ORG > Software Development Team @ Turkey > http://www.Faruk.NET > For Public key: http://www.enderunix.org/ofsen/ofsen.asc > ******************************************************** > From owner-freebsd-net@FreeBSD.ORG Wed Mar 17 16:51:59 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6ADB316A4CE for ; Wed, 17 Mar 2004 16:51:59 -0800 (PST) Received: from postie.sjsa.ab.ca (unknown [216.208.101.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id E4BFF43D1F for ; Wed, 17 Mar 2004 16:51:57 -0800 (PST) (envelope-from sbotsford@sjsa.ab.ca) Received: from [192.168.1.240] (helo=polaris.sjsa.internal.net) by postie.sjsa.ab.ca with esmtp (Exim 4.05) id 1B3c2T-0002ef-00 for freebsd-net@freebsd.org; Wed, 17 Mar 2004 07:28:57 -0700 From: Sherwood Botsford Organization: St. John's School of Alberta To: freebsd-net@freebsd.org Date: Wed, 17 Mar 2004 07:38:11 -0700 User-Agent: KMail/1.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200403170738.11990.sbotsford@sjsa.ab.ca> Subject: tcpdump says errors. Netstat says no. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: sbotsford@sjsa.ab.ca List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2004 00:51:59 -0000 Originally posted on FreeBSD-Questions@... I'm running mail services (exim, fetchmail, popper) on FreeBSD 4.5 In a session trying to track down a problem related to a bad cable, I found that: tcpdump -i xl0 -v -v -v host pop.incentre.net has lots of lines like this: 20:20:11.166767 postie.sjsa.internal.net.1126 > bach.ccinet.ab.ca.pop3: F [bad tcp cksum 4f5e!] 61:61(0) ack 2075 win 33304 (DF) (ttl 64, id 57145, len 52, bad cksum 0!) But netstat -I xl0 -w 10 during the same interval when the above were coming down at 5-10 per second showed: input (xl0) output packets errs bytes packets errs bytes colls 32 0 4019 28 0 4573 0 24 0 3512 22 0 4934 0 444 0 30070 433 0 227132 0 Explanations? (I also get them on the local network; it's not just this destination host.) ********************** Further testing: Xterm ssh'd into postie: netstat -I xl0 -w 10 -d input (xl0) output packets errs bytes packets errs bytes colls drops 4 0 367 4 0 298 0 0 27 0 4346 23 0 2368 0 0 21 0 1746 10 0 1170 0 0 19 0 1472 15 0 1516 0 0 4 0 429 1 0 178 0 0 ... Note: NO dropped packets, no errors. Separate xterm ssh'd to postie: tcpdump -i xl0 -c 1000 -v -v -v | grep bad | wc tcpdump: listening on xl0 477 8960 72418 Separate xterm on localhost ping postie. So you can see that nearly half of the packets have bad checksums. I think I'm missing something here. -- Sherwood Botsford St. John's School of Alberta From owner-freebsd-net@FreeBSD.ORG Wed Mar 17 16:58:42 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1E46B16A4D0 for ; Wed, 17 Mar 2004 16:58:42 -0800 (PST) Received: from vault.redlinenetworks.com (mail.redlinenetworks.com [216.136.145.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id CAE5D43D31 for ; Wed, 17 Mar 2004 16:58:40 -0800 (PST) (envelope-from sreekanth@redlinenetworks.com) Received: from SREELAPTOP (qvip194.redlinenetworks.com [192.168.4.194]) i2I0wbCH022762; Wed, 17 Mar 2004 16:58:37 -0800 (PST) (envelope-from sreekanth@redlinenetworks.com) From: "Sreekanth" To: , Date: Wed, 17 Mar 2004 16:58:20 -0800 Message-ID: <000001c40c84$1b9a4d10$c204a8c0@SREELAPTOP> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Importance: Normal In-Reply-To: <200403170738.11990.sbotsford@sjsa.ab.ca> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: RE: tcpdump says errors. Netstat says no. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2004 00:58:42 -0000 Netstat errors are those errors reported by the Hardware(NIC) for e.g, buffer underrun overrun etc,They do not check for errors in tcp layer. Sreekanth > -----Original Message----- > From: owner-freebsd-net@freebsd.org > [mailto:owner-freebsd-net@freebsd.org] On Behalf Of Sherwood Botsford > Sent: Wednesday, March 17, 2004 6:38 AM > To: freebsd-net@freebsd.org > Subject: tcpdump says errors. Netstat says no. > > > Originally posted on FreeBSD-Questions@... > > I'm running mail services (exim, fetchmail, popper) on > FreeBSD 4.5 > > In a session trying to track down a problem related to a bad > cable, I found that: > > tcpdump -i xl0 -v -v -v host pop.incentre.net > > has lots of lines like this: > > 20:20:11.166767 postie.sjsa.internal.net.1126 > > bach.ccinet.ab.ca.pop3: F [bad tcp cksum 4f5e!] > 61:61(0) ack 2075 win 33304 > (DF) (ttl 64, id 57145, len 52, bad cksum 0!) > > But netstat -I xl0 -w 10 during the same interval when the > above were coming down at 5-10 per second showed: > > input (xl0) output > packets errs bytes packets errs bytes colls > 32 0 4019 28 0 4573 0 > 24 0 3512 22 0 4934 0 > 444 0 30070 433 0 227132 0 > > Explanations? (I also get them on the local network; > it's not just this destination host.) > > ********************** > > Further testing: > Xterm ssh'd into postie: > netstat -I xl0 -w 10 -d > input (xl0) output > packets errs bytes packets errs bytes colls drops > 4 0 367 4 0 298 0 0 > 27 0 4346 23 0 2368 0 0 > 21 0 1746 10 0 1170 0 0 > 19 0 1472 15 0 1516 0 0 > 4 0 429 1 0 178 0 0 > ... > > Note: NO dropped packets, no errors. > > Separate xterm ssh'd to postie: > tcpdump -i xl0 -c 1000 -v -v -v | grep bad | wc > tcpdump: listening on xl0 > 477 8960 72418 > > Separate xterm on localhost > ping postie. > > So you can see that nearly half of the packets have bad checksums. > > I think I'm missing something here. > > > -- > Sherwood Botsford > St. John's School of Alberta > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/free> bsd-net > To > unsubscribe, send any mail to > "freebsd-net-unsubscribe@freebsd.org" > > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.573 / Virus Database: 363 - Release Date: 1/28/2004 > > From owner-freebsd-net@FreeBSD.ORG Wed Mar 17 17:30:35 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 777E116A4CE for ; Wed, 17 Mar 2004 17:30:35 -0800 (PST) Received: from pit.databus.com (p70-227.acedsl.com [66.114.70.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0CAFC43D55 for ; Wed, 17 Mar 2004 17:30:35 -0800 (PST) (envelope-from barney@pit.databus.com) Received: from pit.databus.com (localhost [127.0.0.1]) by pit.databus.com (8.12.11/8.12.11) with ESMTP id i2I1UYTC038439; Wed, 17 Mar 2004 20:30:34 -0500 (EST) (envelope-from barney@pit.databus.com) Received: (from barney@localhost) by pit.databus.com (8.12.11/8.12.11/Submit) id i2I1UY9u038438; Wed, 17 Mar 2004 20:30:34 -0500 (EST) (envelope-from barney) Date: Wed, 17 Mar 2004 20:30:34 -0500 From: Barney Wolff To: Sherwood Botsford Message-ID: <20040318013034.GA38103@pit.databus.com> References: <200403170738.11990.sbotsford@sjsa.ab.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403170738.11990.sbotsford@sjsa.ab.ca> User-Agent: Mutt/1.5.6i X-Scanned-By: MIMEDefang 2.39 cc: freebsd-net@freebsd.org Subject: Re: tcpdump says errors. Netstat says no. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2004 01:30:35 -0000 On Wed, Mar 17, 2004 at 07:38:11AM -0700, Sherwood Botsford wrote: > > In a session trying to track down a problem related to a bad > cable, I found that: > > tcpdump -i xl0 -v -v -v host pop.incentre.net > > So you can see that nearly half of the packets have bad > checksums. As I recall, xl supports doing the checksums in the nic. If all the errors you're seeing are on xmit, it's because tcpdump is seeing the packets before the checksums are computed. At least that's what I remember from some years ago when I had a 3com nic. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. From owner-freebsd-net@FreeBSD.ORG Thu Mar 18 03:20:08 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8868016A4CE for ; Thu, 18 Mar 2004 03:20:08 -0800 (PST) Received: from deliver.epitech.net (deliver.epitech.net [163.5.0.25]) by mx1.FreeBSD.org (Postfix) with SMTP id D7FD743D1D for ; Thu, 18 Mar 2004 03:20:05 -0800 (PST) (envelope-from le-hen_j@epita.fr) Received: from epita.fr ([10.42.1.60]) by deliver.epitech.net (SAVSMTP 3.1.2.35) with SMTP id M2004031812171615320 ; Thu, 18 Mar 2004 12:17:16 +0100 Received: from annelo (annelo.epita.fr [10.42.120.68]) by epita.fr id i2IBK3M05317 Thu, 18 Mar 2004 12:20:03 +0100 (CET) Date: Thu, 18 Mar 2004 12:20:02 +0100 From: jeremie le-hen To: Sherwood Botsford Message-ID: <20040318112002.GA5536@annelo.epita.fr> References: <200403170738.11990.sbotsford@sjsa.ab.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403170738.11990.sbotsford@sjsa.ab.ca> User-Agent: Mutt/1.4i cc: freebsd-net@freebsd.org Subject: Re: tcpdump says errors. Netstat says no. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2004 11:20:08 -0000 > But netstat -I xl0 -w 10 during the same interval when the > above were coming down at 5-10 per second showed: > > input (xl0) output > packets errs bytes packets errs bytes colls > 32 0 4019 28 0 4573 0 > 24 0 3512 22 0 4934 0 > 444 0 30070 433 0 227132 0 You certainly want to use the following : netstat -s -p tcp Regards, -- Jeremie LE HEN aka TtZ jeremie.le-hen@epita.fr ttz@epita.fr Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! From owner-freebsd-net@FreeBSD.ORG Thu Mar 18 04:36:13 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E449A16A4CE for ; Thu, 18 Mar 2004 04:36:12 -0800 (PST) Received: from hotmail.com (bay16-f67.bay16.hotmail.com [65.54.186.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id D875243D2D for ; Thu, 18 Mar 2004 04:36:12 -0800 (PST) (envelope-from fuhuayin@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 18 Mar 2004 04:36:12 -0800 Received: from 193.190.247.45 by by16fd.bay16.hotmail.msn.com with HTTP; Thu, 18 Mar 2004 12:36:12 GMT X-Originating-IP: [193.190.247.45] X-Originating-Email: [fuhuayin@hotmail.com] X-Sender: fuhuayin@hotmail.com From: "Fuhua Yin" To: freebsd-net@freebsd.org Date: Thu, 18 Mar 2004 13:36:12 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 18 Mar 2004 12:36:12.0841 (UTC) FILETIME=[9912D990:01C40CE5] cc: yin@helios.iihe.ac.be Subject: Multicast IPv6, socket, X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2004 12:36:13 -0000 Dear , I am trying to work on IPv6 multicast. I just wrote a small programme to test but get stuck somewhere. I wonder if someone could be of help. Many thanks in advance!! fuhua This is a client to send data from keyboard to group ff3e::2222/1234. ------- #include #include #include #include #include int main(int argc, char **argv){ int mysock; struct sockaddr_in6 servaddr6, cliaddr6; struct ipv6_mreq mreq6; int loop=0; int hops=127; int ifindex; int servlen; int n; char sendline[1024], recvline[1025]; mysock=socket(PF_INET6, SOCK_DGRAM, IPPROTO_UDP); ifindex=if_nametoindex("eth0"); bzero(&servaddr6, sizeof(servaddr6)); servaddr6.sin6_family=AF_INET6; servaddr6.sin6_port=htons(1234); inet_pton(AF_INET6, "ff3e::2222", &servaddr6.sin6_addr); if(!IN6_IS_ADDR_MULTICAST(&servaddr6.sin6_addr)){ int main(int argc, char **argv){ int mysock; struct sockaddr_in6 servaddr6, cliaddr6; struct ipv6_mreq mreq6; int loop=0; int hops=127; int ifindex; int servlen; int servlen; int n; char sendline[1024], recvline[1025]; mysock=socket(PF_INET6, SOCK_DGRAM, IPPROTO_UDP); ifindex=if_nametoindex("eth0"); bzero(&servaddr6, sizeof(servaddr6)); servaddr6.sin6_family=AF_INET6; servaddr6.sin6_port=htons(1234); inet_pton(AF_INET6, "ff3e::2222", &servaddr6.sin6_addr); if(!IN6_IS_ADDR_MULTICAST(&servaddr6.sin6_addr)){ printf(" is not multicast ip6 address \n"); exit(1); } bzero(&cliaddr6, sizeof(cliaddr6)); cliaddr6.sin6_family=AF_INET6; cliaddr6.sin6_port=htons(0); inet_pton(AF_INET6, "2001:6a8:1080:102:203:47ff:fe69:ab93", &cliaddr6.sin6_addr); bind(mysock, (struct sockaddr*)& cliaddr6,sizeof(cliaddr6)); setsockopt(mysock, IPPROTO_IPV6, IPV6_MULTICAST_IF, &ifindex,sizeof(ifindex)); setsockopt(mysock, IPPROTO_IPV6, IPV6_MULTICAST_LOOP, &loop, sizeof(loop)); setsockopt(mysock, IPPROTO_IPV6, IPV6_MULTICAST_HOPS, &hops, sizeof(hops)); while (fgets(sendline, 1024,stdin)!=NULL){ sendto(mysock, sendline, strlen(sendline),0, (struct sockaddr*)&servaddr6,sizeof(servaddr6)); printf("fuhua check\n"); fputs(sendline,stdout); } return 0; } ----------------------- This is the server to receive the message and print on screen. -- #include #include #include #include #include #include #include #include #include int main(int argc, char **argv){ int mysock; struct sockaddr_in6 myaddr, cliaddr; char msgbuf[1024]; int clilen; int msglen; mysock=socket(PF_INET6, SOCK_DGRAM, IPPROTO_UDP); memset(&myaddr,0, sizeof(myaddr)); myaddr.sin6_family=AF_INET6; myaddr.sin6_port=htons(1234); inet_pton(AF_INET6,"2001:6a8:1080:102::d",&myaddr.sin6_addr); printf("ssss \n"); mysock=socket(PF_INET6, SOCK_DGRAM, IPPROTO_UDP); bind(mysock, (struct sockaddr*) &myaddr, sizeof(myaddr)); for ( ; ; ) { printf("fuhua yin----ssss \n"); clilen=sizeof(cliaddr); msglen=recvfrom(mysock, msgbuf, 1024, 0, (struct sockaddr*)&cliaddr, &clilen); printf("how many bytes I receive from client %d",msglen); sendto(mysock, msgbuf,msglen, 0, (struct sockaddr*)&cliaddr, clilen); } return 0; _________________________________________________________________ From owner-freebsd-net@FreeBSD.ORG Thu Mar 18 04:48:43 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CABB116A4CE for ; Thu, 18 Mar 2004 04:48:43 -0800 (PST) Received: from smtp.netli.com (ip2-pal-focal.netli.com [66.243.52.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB59343D1D for ; Thu, 18 Mar 2004 04:48:43 -0800 (PST) (envelope-from vlm@netli.com) Received: (qmail 23851 invoked by uid 84); 18 Mar 2004 12:48:16 -0000 Received: from vlm@netli.com by l3-1 with qmail-scanner-0.96 (uvscan: v4.1.40/v4121. . Clean. Processed in 0.17947 secs); 18 Mar 2004 12:48:16 -0000 Received: from unknown (HELO netli.com) (172.17.1.12) by mx01-pal-lan.netli.lan with SMTP; 18 Mar 2004 12:48:16 -0000 Message-ID: <40599ACA.1040506@netli.com> Date: Thu, 18 Mar 2004 04:49:14 -0800 From: Lev Walkin Organization: Netli, Inc. User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040307 X-Accept-Language: ru, en-us, en MIME-Version: 1.0 To: Fuhua Yin References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: yin@helios.iihe.ac.be Subject: Re: Multicast IPv6, socket, X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2004 12:48:43 -0000 never check the error codes. it is a bad practice to check for error codes from system calls and library functions. please remove all checks for the error conditions from your code and try again. these checks slow down the execution and mask real problems. P.S. man assert, and use it everywhere if you're lazy to implement an adequate error checking. Fuhua Yin wrote: > Dear , > > I am trying to work on IPv6 multicast. I just wrote a small programme to > test but get stuck somewhere. I wonder if someone could be of help. > > > Many thanks in advance!! > fuhua > > This is a client to send data from keyboard to group ff3e::2222/1234. > ------- > #include > #include > #include > #include > #include > int main(int argc, char **argv){ > > int mysock; > struct sockaddr_in6 servaddr6, cliaddr6; > struct ipv6_mreq mreq6; > > int loop=0; > int hops=127; > int ifindex; > > int servlen; > int n; > char sendline[1024], recvline[1025]; > > mysock=socket(PF_INET6, SOCK_DGRAM, IPPROTO_UDP); > ifindex=if_nametoindex("eth0"); > > bzero(&servaddr6, sizeof(servaddr6)); > servaddr6.sin6_family=AF_INET6; > servaddr6.sin6_port=htons(1234); > inet_pton(AF_INET6, "ff3e::2222", &servaddr6.sin6_addr); > > if(!IN6_IS_ADDR_MULTICAST(&servaddr6.sin6_addr)){ > int main(int argc, char **argv){ > > int mysock; > struct sockaddr_in6 servaddr6, cliaddr6; > struct ipv6_mreq mreq6; > > int loop=0; > int hops=127; > int ifindex; > > int servlen; > int servlen; > int n; > char sendline[1024], recvline[1025]; > > mysock=socket(PF_INET6, SOCK_DGRAM, IPPROTO_UDP); > ifindex=if_nametoindex("eth0"); > > bzero(&servaddr6, sizeof(servaddr6)); > servaddr6.sin6_family=AF_INET6; > servaddr6.sin6_port=htons(1234); > inet_pton(AF_INET6, "ff3e::2222", &servaddr6.sin6_addr); > > if(!IN6_IS_ADDR_MULTICAST(&servaddr6.sin6_addr)){ > > printf(" is not multicast ip6 address \n"); > exit(1); > } > > > bzero(&cliaddr6, sizeof(cliaddr6)); > cliaddr6.sin6_family=AF_INET6; > cliaddr6.sin6_port=htons(0); > inet_pton(AF_INET6, "2001:6a8:1080:102:203:47ff:fe69:ab93", > &cliaddr6.sin6_addr); > > bind(mysock, (struct sockaddr*)& cliaddr6,sizeof(cliaddr6)); > > setsockopt(mysock, IPPROTO_IPV6, IPV6_MULTICAST_IF, > &ifindex,sizeof(ifindex)); > setsockopt(mysock, IPPROTO_IPV6, IPV6_MULTICAST_LOOP, &loop, > sizeof(loop)); > setsockopt(mysock, IPPROTO_IPV6, IPV6_MULTICAST_HOPS, &hops, > sizeof(hops)); > > while (fgets(sendline, 1024,stdin)!=NULL){ > > sendto(mysock, sendline, strlen(sendline),0, (struct > sockaddr*)&servaddr6,sizeof(servaddr6)); > printf("fuhua check\n"); > fputs(sendline,stdout); > > } > return 0; > > } > ----------------------- > > This is the server to receive the message and print on screen. > > -- > #include > #include > #include > #include > #include > #include > #include > #include > #include > int main(int argc, char **argv){ > > int mysock; > struct sockaddr_in6 myaddr, cliaddr; > char msgbuf[1024]; > int clilen; > int msglen; > mysock=socket(PF_INET6, SOCK_DGRAM, IPPROTO_UDP); > memset(&myaddr,0, sizeof(myaddr)); > myaddr.sin6_family=AF_INET6; > myaddr.sin6_port=htons(1234); > inet_pton(AF_INET6,"2001:6a8:1080:102::d",&myaddr.sin6_addr); > > printf("ssss \n"); > mysock=socket(PF_INET6, SOCK_DGRAM, IPPROTO_UDP); > bind(mysock, (struct sockaddr*) &myaddr, sizeof(myaddr)); > for ( ; ; ) > { > > printf("fuhua yin----ssss \n"); > clilen=sizeof(cliaddr); > msglen=recvfrom(mysock, msgbuf, 1024, 0, (struct > sockaddr*)&cliaddr, &clilen); > > printf("how many bytes I receive from client %d",msglen); > sendto(mysock, msgbuf,msglen, 0, (struct sockaddr*)&cliaddr, > clilen); > > } > > return 0; > > _________________________________________________________________ > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- Lev Walkin vlm@netli.com From owner-freebsd-net@FreeBSD.ORG Thu Mar 18 05:56:52 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD1BE16A4CF for ; Thu, 18 Mar 2004 05:56:52 -0800 (PST) Received: from gatekeeper.syskonnect.de (unknown [213.144.13.149]) by mx1.FreeBSD.org (Postfix) with ESMTP id BBB9D43D31 for ; Thu, 18 Mar 2004 05:56:51 -0800 (PST) (envelope-from gheinig@syskonnect.de) Received: from syskonnect.de (skd.de [10.9.15.1])i2IDvW7m012851 for ; Thu, 18 Mar 2004 14:57:32 +0100 (MET) Received: from syskonnect.de (localhost [127.0.0.1])i2IDun3B021145 for ; Thu, 18 Mar 2004 14:56:50 +0100 (MET) Sender: gheinig@syskonnect.de Message-ID: <4059AAAE.FE4D95BC@syskonnect.de> Date: Thu, 18 Mar 2004 14:57:02 +0100 From: Gerald Heinig Organization: SysKonnect GmbH X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: net@freebsd.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Ethernet stats in sysctl and SNMP MIBs X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2004 13:56:52 -0000 Hi all, I'm trying to retrieve Ethernet MIB data from my driver using UCD SNMP and sysctl. For some reason, I can't get any of the info I've put in (I've just set some dummy values for the moment). In particular, I'm trying to get the ISO 8802.3 MIB to display with snmpwalk. I've declared and set the pointer to the struct ifmib_iso_8802_3 in my softc struct and set the structure length. However, neither snmpwalk nor sysctl produces any dot3 MIB data. Is this implemented yet or am I doing something wrong? Cheers, Gerald -- S y s K o n n e c t G m b H A Marvell Company Siemensstr. 23 D-76275 Ettlingen, Germany --------------------------------- Gerald Heinig Software Engineer ------------------------------------- phone: + 49 (0) 7243 502 354 fax: +49 (0) 7243 502 364 email: gheinig@syskonnect.de http://www.syskonnect.com From owner-freebsd-net@FreeBSD.ORG Thu Mar 18 06:03:37 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 86C6116A4CE for ; Thu, 18 Mar 2004 06:03:37 -0800 (PST) Received: from rincewind.c4inet.net (rincewind.c4inet.net [193.120.144.209]) by mx1.FreeBSD.org (Postfix) with SMTP id 8D0CA43D3F for ; Thu, 18 Mar 2004 06:03:36 -0800 (PST) (envelope-from lists@rincewind.c4inet.net) Received: (qmail 35060 invoked from network); 18 Mar 2004 14:03:34 -0000 Received: from localhost.c4inet.net (HELO rincewind.c4inet.net) (127.0.0.1) by rincewind.c4inet.net with SMTP; 18 Mar 2004 14:03:34 -0000 Received: (from lists@localhost) by rincewind.c4inet.net (8.12.10/8.12.10/Submit) id i2IE3Ykn035058 for freebsd-net@freebsd.org; Thu, 18 Mar 2004 14:03:34 GMT (envelope-from lists) Date: Thu, 18 Mar 2004 14:03:34 +0000 From: C4INet lists To: freebsd-net@freebsd.org Message-ID: <20040318140334.GA32442@rincewind.c4inet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: ipv6 keep state on ipv6 ftp connections problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2004 14:03:37 -0000 Hi all, I've now found the reason for the problems with ipv6 ftp transmissions. It seems to be a problem with pf and the "keep state" argument. The problem was that a ipv6 ftp download would stall after ~60 kBytes transmitted. pfctl -ss showed the TCP stream(s) as CLOSED:SYN SENT. The box running pf is a DSL router/ v6 tunnel endpoint, running RELENG_5_1 and pf-2.03. The offending pf.conf rules: pass out on gif0 inet6 all keep state pass in on gif0 inet6 all keep state After removing the "keep state" argument, everything worked. Strangely, this seemed to only affect traffic from other hosts on the network, traffic originating on the router worked fine. rgds, Sascha From owner-freebsd-net@FreeBSD.ORG Thu Mar 18 07:35:56 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D612916A4CE for ; Thu, 18 Mar 2004 07:35:56 -0800 (PST) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 7344443D49 for ; Thu, 18 Mar 2004 07:35:56 -0800 (PST) (envelope-from freebsd@stevenfettig.com) Received: (qmail 16892 invoked from network); 18 Mar 2004 15:35:55 -0000 Received: from 66-168-50-57.jvl.wi.charter.com (HELO stevenfettig.com) (66.168.50.57) by relay.pair.com with SMTP; 18 Mar 2004 15:35:55 -0000 X-pair-Authenticated: 66.168.50.57 Message-ID: <4059C1C1.3020505@stevenfettig.com> Date: Thu, 18 Mar 2004 09:35:29 -0600 From: "Steven N. Fettig" User-Agent: Mozilla Thunderbird 0.5 (X11/20040305) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-questions@freebsd.org, freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Recommendation for Dual T1 Routing/Firewalling X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2004 15:35:57 -0000 Sorry to cross-post this question, but I wanted to make sure my thinking is on track regarding a FreeBSD box I am going to use for routing/firewalling. A wireless project I am working on is getting 2 T1's from Global Crossing that I want to bring into a Sangoma dual CSU/DSU card (using their software called WANPIPE to configure) in a FreeBSD box. I am considering using one of my left-over VIA mini-itx machines running at 533 MHz (512MB of RAM and a 40 GB IDE drive). Basically, I want to build a dual-homed machine that provides firewalling and NAT to the wireless network (both of the T1's are bundled by GC, so actual throughput should be around 3Mbps). There are segments of the network that I want to do NAT for and other segments where I simply want the clients to have real world addressable IP's. I have built a number of dual-homed machines before, but nothing that was critical like the system that I am about to build. Plus, I would like to test out bandwidth controls for some ranges of IP's. The questions are: a) does anyone have anything bad or good to say about Sangoma CSU/DSU cards? b) is the processor I am using more than capable of handling the bandwidth I am bringing in (considering there may be upwards of 60 machines behind the firewall either surfing via NAT or directly via their real-world IP's)? The machine is a great choice from the standpoint that there is no cooling fan and it is extremely small, so I don't have to be so concerned with mechanical failure outside of the HD. I am concerned, however, that the processor is going to be too slow and will add too much latency to the network. Like I said before, I have built dual-homed gateways before (using nothing more than a P 150 and a P II 233) and didn't have any issues with those machines, but I also wasn't dealing with the amount of bandwidth and/or clients that I am looking at for this new network. So, I am concerned about reliability and latency... Any comments or suggestions would be very much appreciated. Thanks, Steve Fettig From owner-freebsd-net@FreeBSD.ORG Thu Mar 18 07:54:11 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 586EB16A4CE for ; Thu, 18 Mar 2004 07:54:11 -0800 (PST) Received: from v6.hitachi.co.jp (galilei.v6.hitachi.co.jp [133.145.167.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1EC5B43D39 for ; Thu, 18 Mar 2004 07:54:10 -0800 (PST) (envelope-from suz@crl.hitachi.co.jp) Received: from s30.uki-uki.net (galilei.v6.hitachi.co.jp [133.145.167.4]) by v6.hitachi.co.jp (8.12.10/8.11.6) with ESMTP id i2IG1pxe055644; Fri, 19 Mar 2004 01:01:51 +0900 (JST) (envelope-from suz@crl.hitachi.co.jp) Date: Fri, 19 Mar 2004 00:54:05 +0900 Message-ID: From: SUZUKI Shinsuke To: fuhuayin@hotmail.com X-cite: xcite 1.33 In-Reply-To: References: User-Agent: User-Agent: Wanderlust/2.11.24 (Wonderwall) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Network Systems Research Dept., Central Research Laboratory, Hitachi, Ltd, Japan MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII cc: freebsd-net@freebsd.org cc: yin@helios.iihe.ac.be Subject: Re: Multicast IPv6, socket, X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2004 15:54:11 -0000 Hi, >>>>> On Thu, 18 Mar 2004 13:36:12 +0100 >>>>> fuhuayin@hotmail.com("Fuhua Yin") said: > I am trying to work on IPv6 multicast. I just wrote a small programme to > test but get stuck somewhere. I wonder if someone could be of help. Please refer to mcastsend (kame/kame/mcastsend), available in KAME SNAP Tarball. It does quite the same thing as your program. (it's not merged into freebsd-current yet, since it's normally a debugging tool for developers. If there's a strong request, I'm willing to merge it into -current, though) Thanks, ---- SUZUKI, Shinsuke @ Hitachi / KAME Project From owner-freebsd-net@FreeBSD.ORG Thu Mar 18 08:12:11 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A667616A4CE for ; Thu, 18 Mar 2004 08:12:11 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.136.123]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3CD6443D3F for ; Thu, 18 Mar 2004 08:12:09 -0800 (PST) (envelope-from jrh@it.uc3m.es) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 4C47013C1A for ; Thu, 18 Mar 2004 17:12:07 +0100 (CET) Received: from localhost.invalid (unknown [163.117.140.30]) by smtp03.uc3m.es (Postfix) with ESMTP id 2AD1813C21 for ; Thu, 18 Mar 2004 17:12:07 +0100 (CET) From: Juan Rodriguez Hervella Organization: UC3M To: freebsd-net@freebsd.org Date: Thu, 18 Mar 2004 17:12:03 +0100 User-Agent: KMail/1.6 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200403181712.03629.jrh@it.uc3m.es> Subject: sysctl -w net.link.ether.inet.proxyall=1 ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2004 16:12:11 -0000 What this is used for ? -- ****** JFRH ****** From owner-freebsd-net@FreeBSD.ORG Thu Mar 18 08:12:18 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 209DB16A4CE; Thu, 18 Mar 2004 08:12:18 -0800 (PST) Received: from pc154.iihe.ac.be (pc154.iihe.ac.be [193.190.246.174]) by mx1.FreeBSD.org (Postfix) with ESMTP id 250AC43D2F; Thu, 18 Mar 2004 08:12:17 -0800 (PST) (envelope-from yin@helios.iihe.ac.be) Received: from suma ([193.190.247.203]) by helios.iihe.ac.be (8.11.6/8.11.6) with SMTP id i2IG5Xp05940; Thu, 18 Mar 2004 17:05:33 +0100 Message-ID: <002901c40d03$c7d64d70$cbf7bec1@suma> From: "Fuhua Yin" To: "SUZUKI Shinsuke" References: Date: Thu, 18 Mar 2004 17:12:11 +0100 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.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 cc: freebsd-net@freebsd.org Subject: Re: Multicast IPv6, socket, X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2004 16:12:18 -0000 Hello Suzuki, Many thanks for your information. I just made the code work. The reason is that the multicast applications should be put on the hosts not on the multicast router (FreeBSD router). I put mcastsender.c on a linux host and mcastreceiver.c on the Freebsd multicast router. That is why it does not work. I will also check the KAME code you gave me to learn something. I did search a lot and could not find code for IPv6. thanks again, fuhua ----- Original Message ----- From: "SUZUKI Shinsuke" To: Cc: ; Sent: Thursday, March 18, 2004 4:54 PM Subject: Re: Multicast IPv6, socket, > Hi, > > >>>>> On Thu, 18 Mar 2004 13:36:12 +0100 > >>>>> fuhuayin@hotmail.com("Fuhua Yin") said: > > > I am trying to work on IPv6 multicast. I just wrote a small programme to > > test but get stuck somewhere. I wonder if someone could be of help. > > Please refer to mcastsend (kame/kame/mcastsend), available in KAME > SNAP Tarball. It does quite the same thing as your program. > > (it's not merged into freebsd-current yet, since it's normally a > debugging tool for developers. If there's a strong request, I'm > willing to merge it into -current, though) > > Thanks, > ---- > SUZUKI, Shinsuke @ Hitachi / KAME Project > > From owner-freebsd-net@FreeBSD.ORG Thu Mar 18 08:49:03 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4179216A4CE; Thu, 18 Mar 2004 08:49:03 -0800 (PST) Received: from blake.polstra.com (blake.polstra.com [64.81.189.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id D5CD343D3F; Thu, 18 Mar 2004 08:49:02 -0800 (PST) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (dsl081-189-067.sea1.dsl.speakeasy.net [64.81.189.67]) by blake.polstra.com (8.12.11/8.12.11) with ESMTP id i2IGmx3r050446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Mar 2004 08:48:59 -0800 (PST) (envelope-from jdp@strings.polstra.com) Received: (from jdp@localhost) by strings.polstra.com (8.12.11/8.12.11/Submit) id i2IGmwii029274; Thu, 18 Mar 2004 08:48:58 -0800 (PST) (envelope-from jdp) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Thu, 18 Mar 2004 08:48:58 -0800 (PST) From: John Polstra To: (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) X-Bogosity: No, tests=bogofilter, spamicity=0.353069, version=0.14.5 cc: current@freebsd.org cc: net@freebsd.org Subject: Re: libalias patch for review / testing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2004 16:49:03 -0000 On 16-Mar-2004 Dag-Erling Smørgrav wrote: > Ruslan Ermilov writes: >> I know this code quite well. Where do you suspect could be a bug >> affecting -O2 compiles, or you just simply fixed -O2 and hope it >> will auto-fix the (possible) bugs in -O2? > > Since there is no inline asm, the most likely suspect is aliasing, > which is what my patch tries to address. To eliminate aliasing problems reliably, I think you're going to have to use a union. That's the only kind of type punning that gcc promises to allow even at high optimization levels. From the info pages (in the description of "-fstrict-aliasing"): Pay special attention to code like this: union a_union { int i; double d; }; int f() { a_union t; t.d = 3.0; return t.i; } The practice of reading from a different union member than the one most recently written to (called "type-punning") is common. Even with `-fstrict-aliasing', type-punning is allowed, provided the memory is accessed through the union type. So, the code above will work as expected. However, this code might not: int f() { a_union t; int* ip; t.d = 3.0; ip = &t.i; return *ip; } Even if you use a union, it won't necessarily work with compilers other than gcc. John From owner-freebsd-net@FreeBSD.ORG Thu Mar 18 08:50:42 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A33416A4CF for ; Thu, 18 Mar 2004 08:50:42 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.136.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id B786E43D41 for ; Thu, 18 Mar 2004 08:50:41 -0800 (PST) (envelope-from jrh@it.uc3m.es) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 6B313118D7 for ; Thu, 18 Mar 2004 17:50:39 +0100 (CET) Received: from localhost.invalid (unknown [163.117.140.30]) by smtp02.uc3m.es (Postfix) with ESMTP id 4FFC6118D1 for ; Thu, 18 Mar 2004 17:50:39 +0100 (CET) From: Juan Rodriguez Hervella Organization: UC3M To: freebsd-net@freebsd.org Date: Thu, 18 Mar 2004 17:50:35 +0100 User-Agent: KMail/1.6 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200403181750.35948.jrh@it.uc3m.es> Subject: Small question about bridging and arp X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2004 16:50:42 -0000 Hello, If I do a bridge between xl0 and xl1, can the IP address configured on xl1 answer ARP-requests that come from the LAN the xl0 is connected ? Does this make sense ? -- ****** JFRH ****** From owner-freebsd-net@FreeBSD.ORG Thu Mar 18 10:14:45 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 80ED316A4CE for ; Thu, 18 Mar 2004 10:14:45 -0800 (PST) Received: from out014.verizon.net (out014pub.verizon.net [206.46.170.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C51043D46 for ; Thu, 18 Mar 2004 10:14:45 -0800 (PST) (envelope-from cswiger@mac.com) Received: from mac.com ([68.161.120.219]) by out014.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040318181444.XONK5247.out014.verizon.net@mac.com>; Thu, 18 Mar 2004 12:14:44 -0600 Message-ID: <4059E686.6050207@mac.com> Date: Thu, 18 Mar 2004 13:12:22 -0500 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juan Rodriguez Hervella References: <200403181750.35948.jrh@it.uc3m.es> In-Reply-To: <200403181750.35948.jrh@it.uc3m.es> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out014.verizon.net from [68.161.120.219] at Thu, 18 Mar 2004 12:14:44 -0600 cc: freebsd-net@freebsd.org Subject: Re: Small question about bridging and arp X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2004 18:14:45 -0000 Juan Rodriguez Hervella wrote: > If I do a bridge between xl0 and xl1, can the IP address > configured on xl1 answer ARP-requests that come from the > LAN the xl0 is connected ? Does this make sense ? Yes, it should. Bridging basicly treats xl0 and xl1 as being on the same physical network and an ARP request for an IP used by one of the two interfaces should be answered regardless of where it came from. -- -Chuck From owner-freebsd-net@FreeBSD.ORG Thu Mar 18 15:50:02 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3466516A4CE for ; Thu, 18 Mar 2004 15:50:02 -0800 (PST) Received: from fep17.inet.fi (fep17.inet.fi [194.251.242.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id D56F643D1D for ; Thu, 18 Mar 2004 15:50:00 -0800 (PST) (envelope-from tomi.kaistila@datamike.org) Received: from zeus ([80.221.213.44]) by fep17.inet.fi with ESMTP id <20040318234957.WNT17548.fep17.inet.fi@zeus> for ; Fri, 19 Mar 2004 01:49:57 +0200 From: "Tomi Kaistila" To: Date: Fri, 19 Mar 2004 01:50:10 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcQNQ79ZvTKN+gY2QTm/kIVhPxk/4Q== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-Id: <20040318234957.WNT17548.fep17.inet.fi@zeus> Subject: Filtering established connection in ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2004 23:50:02 -0000 Hello I've just sometime ago got a second computer, I installed FreebSD 5.2 on it, full installation and I'm on my way of making a server out of it. Basically from the beginning, I've been struggling with ipfw, to make up a good ruleset. I've enabled IPFIREWALL in the kernel. My philosophy is, if it's not in the rules deny it. I have a very strict ruleset at the moment, only allowing connections to certain services and all from designated ports. All other connections are denied. My problem is that this also hinders my use of Internet from this machine. Although I have a rule that allows all connection from the server to outside, many connections spawn a reply. i.e. if I ping an address, I must also enable icmp from the outside world to my machine to receive the reply. My question is, can I make a rule that allows such replies to pass the packet filter, but to drop if it is not such a reply or similar signal? I tried using the setup and established flags but either I did something wrong or it just didn't work out that way. -- Tomi From owner-freebsd-net@FreeBSD.ORG Thu Mar 18 15:58:44 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD5B316A4CE for ; Thu, 18 Mar 2004 15:58:44 -0800 (PST) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 53CDF43D31 for ; Thu, 18 Mar 2004 15:58:44 -0800 (PST) (envelope-from silby@silby.com) Received: (qmail 21531 invoked from network); 18 Mar 2004 23:58:43 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 18 Mar 2004 23:58:43 -0000 X-pair-Authenticated: 209.68.2.70 Date: Thu, 18 Mar 2004 17:58:42 -0600 (CST) From: Mike Silbersack To: Tomi Kaistila In-Reply-To: <20040318234957.WNT17548.fep17.inet.fi@zeus> Message-ID: <20040318175650.O1495@odysseus.silby.com> References: <20040318234957.WNT17548.fep17.inet.fi@zeus> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: Filtering established connection in ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2004 23:58:44 -0000 On Fri, 19 Mar 2004, Tomi Kaistila wrote: > My question is, can I make a rule that allows such replies to pass the > packet filter, but to drop if it is not such a reply or similar signal? I > tried using the setup and established flags but either I did something wrong > or it just didn't work out that way. > > -- > Tomi What you want is a stateful firewall, aka dynamic firewall rules. Just use ipfw add allow ip from yourip to any keep-state And ipfw will do what you want. This is described in the ipfw manpage, although it's perhaps not explained as well as it could be. Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Thu Mar 18 17:50:58 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2663116A4CE for ; Thu, 18 Mar 2004 17:50:58 -0800 (PST) Received: from mordrede.visionsix.net (mordrede.visionsix.com [65.202.119.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id A5BA443D3F for ; Thu, 18 Mar 2004 17:50:55 -0800 (PST) (envelope-from lists@visionsix.com) Received: from vsis169 (unverified [65.202.119.169]) by mordrede.visionsix.net for ; Thu, 18 Mar 2004 19:50:54 -0600 Message-ID: <006a01c40d54$9bc30600$df0a0a0a@visionsix.net> From: "Lewis Watson" To: "freebsd-net" Date: Thu, 18 Mar 2004 19:50:51 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: IPFW & Queues & Timeouts X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2004 01:50:58 -0000 Hello, I would greatly appreciate some advice on the following situation... Ou goal is to use a FreeBSD box as a gateway/ router for several clients. These clients are being provided Internet access through our network and other than a few common worm holes blocked and bandwidth management they should have open access. We are passing traffic through the gateway at this time and bandwidth management seems to work fine but when pinging with a minimal load (one client behind the gateway sending 500byte icmp packets) on the gateway we are getting around 25% loss of packets. I feel that it's related to the queue size but I am now not sure what is the best way to determine optimal queue size. I am using the following rules after rebuilding the kernel with the additions mentioned below. # Kernel Config Changes options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=10 options DUMMYNET options HZ=1000 # This is my attempt at a using IPFW to allow a very open network # It's essentially open except for a very few things. # See Below, it's all commented. # fwcmd="/sbin/ipfw" # Flush previous rules ${fwcmd} -f flush # Block the Microsoft Worm :-), SQL in and Ident ${fwcmd} add deny udp from any to any 135-137,139,445 ${fwcmd} add deny tcp from any to any 135-137,139,445,1434 ${fwcmd} add reset tcp from any to any 113 # Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes RESERVED-1, # DHCP auto-configuration, NET-TEST, MULTICAST (class D), and class E) ${fwcmd} add deny all from any to 0.0.0.0/8 ${fwcmd} add deny all from any to 169.254.0.0/16 ${fwcmd} add deny all from any to 192.0.2.0/24 ${fwcmd} add deny all from any to 224.0.0.0/4 # Each client would have an in and out pipe and their own subnet # ${fwcmd} add pipe 1 ip from any to 192.168.1.252/30 in ${fwcmd} add pipe 2 ip from 192.168.1.252/30 to any out ${fwcmd} pipe 1 config bw 900Kbit/s queue 112Kbytes ${fwcmd} pipe 2 config bw 900Kbit/s queue 112Kbytes ${fwcmd} add 65000 pass all from any to any Thanks, Lewis From owner-freebsd-net@FreeBSD.ORG Thu Mar 18 17:54:38 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AACEC16A4CE for ; Thu, 18 Mar 2004 17:54:38 -0800 (PST) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id D761043D48 for ; Thu, 18 Mar 2004 17:54:37 -0800 (PST) (envelope-from 789456123@gmx.de) Received: (qmail 22209 invoked by uid 0); 19 Mar 2004 01:54:36 -0000 Received: from 141.84.69.18 by www27.gmx.net with HTTP; Fri, 19 Mar 2004 02:54:37 +0100 (MET) Date: Fri, 19 Mar 2004 02:54:37 +0100 (MET) From: 789456123@gmx.de To: freebsd-net@freebsd.org MIME-Version: 1.0 X-Priority: 3 (Normal) X-Authenticated: #2273895 Message-ID: <6686.1079661277@www27.gmx.net> X-Mailer: WWW-Mail 1.6 (Global Message Exchange) X-Flags: 0001 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Subject: BIND: Lookup of CNAME records X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2004 01:54:38 -0000 I have set up a FreeBSD (5.2.1-RELEASE) box acting as a gateway and running version 8.3.7-REL of BIND. For testing purposes my configuration file looks as follows: options { directory "/etc/namedb"; pid-file "/var/run/named/pid"; forward only; forwarders { 195.62.99.42; 195.62.97.177; }; query-source address * port 53; }; zone "." { type hint; file "named.root"; }; This setup (actually a replacement for just adding the two nameservers to resolv.conf) works fine with lookup tools like "host", "nslookup", or "dnsquery". However, when I try to telnet or ftp a server whose name is a CNAME record, it takes about 77 seconds until the lookup is complete. This appears quite odd to me, as "host" does the lookup perfectly well and fast. Connections to A name records are no problem however. My first assumption was that "ftp" or "telnet" were not doing lookups properly. But modifying resolv.conf in a way that it uses the two nameservers directly (instead of the local nameserver) solved the CNAME lookup problem. What makes the whole story even more obscure: Lookups of clients on the LAN (they use the FreeBSD box as their nameserver) do work with A records as well as with CNAME records. Even when the lookup is initiated by some ftp or telnet client. My firewall is widely opened, for everything in and everything out. An upgrade to BIND-8.4.4 did not resolve my problem. I suppose the answer is quite simple, but I don't really see it at the moment, I'm afraid... Any help is greatly appreciated, Lutz -- +++ NEU bei GMX und erstmalig in Deutschland: TÜV-geprüfter Virenschutz +++ 100% Virenerkennung nach Wildlist. Infos: http://www.gmx.net/virenschutz From owner-freebsd-net@FreeBSD.ORG Thu Mar 18 20:14:29 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A1F3B16A4CE; Thu, 18 Mar 2004 20:14:29 -0800 (PST) Received: from secure.net2000.com.au (secure.net2000.com.au [203.26.98.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5128243D2F; Thu, 18 Mar 2004 20:14:28 -0800 (PST) (envelope-from ktulu@net2000.com.au) Received: (from apache@localhost) by secure.net2000.com.au (8.11.6/8.11.6) id i2J4M7i09566; Fri, 19 Mar 2004 15:22:07 +1100 X-Authentication-Warning: secure.net2000.com.au: apache set sender to ktulu@net2000.com.au using -f Received: from 202.14.179.253 ([202.14.179.253]) by secure.net2000.com.au (IMP) with HTTP for ; Fri, 19 Mar 2004 15:22:07 +1100 Message-ID: <1079670127.405a756f4bafe@secure.net2000.com.au> Date: Fri, 19 Mar 2004 15:22:07 +1100 From: ktulu@net2000.com.au To: freebsd-net@freebsd.org, freebsd-ipfw@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.1 X-Originating-IP: 202.14.179.253 Subject: port forwarding and ipfw rules X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2004 04:14:29 -0000 Hi All, I have posted this question before, but I don't think I made myself very clear in what I was hoping to achieve. Hopefully, this post will help out. I have a situation where I have one network interface (fxp1) connected to the network with the IP address xxx.xxx.19.110 which is port forwarding (on port 443) to a host xxx.xxx.19.109. Currently, this situation works fine. The problem I'm having is that I have two of these machines doing the same thing and I require the ability for one machine to take over from the other in the event of a hardware failure, etc. The diagram below basically shows what I want to achieve: Internet ---------- | | | fxp1 | fxp1 .19.110 | .19.111 | (alias) | ----------------- | FW | | Default route | | xx.xx.19.225 | | | ----------------- | / \ fxp1 / \ fxp1 .19.110/ \.19.111 (alias) / \ / \ / \ / \ / \ / \ / \ ----- ----- | | | | | | | | | | | | | | | | ----- ----- Web Server Web Server x.x.19.109:443 x.x.19.102:443 This configuration must be able to be added and removed dynamically without effecting the existing network setup (other than changing ipfw rules). Below are the relevant sections of my current configuration settings: ***BEGIN /etc/rc.conf: network interfaces="fxp1 lo0" ifconfig_lo0="inet 127.0.0.1" ifconfig_fxp1="inet xxx.xxx.19.110 netmask 255.255.255.0" defaultrouter="xxx.xxx.19.225" gateway_enable="YES" natd_enable="YES" natd_interface="fxp1" natd_flags="-l -m -redirect_port tcp xxx.xxx.19.109:443 443" firewall_enable="YES" firewall_type="custom" firewall_script="/etc/rc.firewall" firewall_quiet="NO" tcp_extensions="YES" *** END /etc/rc.conf *** BEGIN /etc/rc.firewall ############ # Set the host IP address and the forwarding IP # # Set this to your ip address. ip="xxx.xxx.19.110" # Set this to the ip of the machine traffic on 443 is being forwarded to fwd_ip="xxx.xxx.19.109" # Set this to the IP of the machine this host is used as a failover for fail_ip="xxx.xxx.19.111" # Set this to the IP of the machine traffic on 443 of the failed host is being forwarded to fail_forward="xxx.xxx.19.102" # Set this to the port of the new natd daemon for the failover fail_natd="8669" case ${firewall_type} in [Cc][Uu][Ss][Tt][Oo][Mm]) case ${natd_enable} in [Yy][Ee][Ss]) if [ -n "${natd_interface}" ]; then ${fwcmd} add 50 divert natd all from any to any via ${natd_interface} fi ;; esac # Allow anything outbound from this address. ${fwcmd} add allow all from ${ip} to any out # Deny anything outbound from other addresses. ${fwcmd} add deny log all from any to any out # Allow TCP through if setup succeeded. ${fwcmd} add allow tcp from any to any established # Allow IP fragments to pass through. ${fwcmd} add allow all from any to any frag # Allow inbound ftp, ssh, email, tcp-dns, http, https, pop3, pop3s. ${fwcmd} add allow tcp from any to ${ip} 22 setup ${fwcmd} add allow tcp from any to ${ip} 80 setup # This record has to be slightly different because this machine is # not actually listening on port 443, but just forwarding traffic on # port ${fwcmd} add allow tcp from any to ${fwd_ip} 443 # Deny inbound auth, netbios, ldap, and Microsoft's DB protocol # without logging. ${fwcmd} add deny tcp from any to ${ip} 113 setup ${fwcmd} add deny tcp from any to ${ip} 139 setup ${fwcmd} add deny tcp from any to ${ip} 389 setup ${fwcmd} add deny tcp from any to ${ip} 445 setup # Deny some chatty UDP broadcast protocols without logging. ${fwcmd} add deny udp from any 137 to any ${fwcmd} add deny udp from any to any 137 ${fwcmd} add deny udp from any 138 to any ${fwcmd} add deny udp from any 513 to any ${fwcmd} add deny udp from any 525 to any # Allow inbound DNS and NTP replies. This is somewhat of a hole, # since we're looking at the incoming port number, which can be # faked, but that's just the way DNS and NTP work. ${fwcmd} add allow udp from any 53 to ${ip} ${fwcmd} add allow udp from any 123 to ${ip} # Allow inbound DNS queries. ${fwcmd} add allow udp from any to ${ip} 53 # Deny inbound NTP queries without logging. ${fwcmd} add deny udp from any to ${ip} 123 # Allow traceroute to function, but not to get in. ${fwcmd} add unreach port udp from any to ${ip} 33435-33524 # Allow some inbound icmps - echo reply, dest unreach, source quench, # echo, ttl exceeded. ${fwcmd} add allow icmp from any to any icmptypes 0,3,4,8,11 # Everything else is denied and logged. ${fwcmd} add deny log all from any to any ;; *** END /etc/rc.firewall Basically, what I've done to try and add the other configuration to this box is as follows: 1. Add the aliased IP to fxp1: ifconfig fxp1 inet xxx.xxx.19.111 netmask 255.255.255.255 alias 2. Start the additional natd daemon: /sbin/natd -same_ports -use_sockets -port 8669 -alias_address xxx.xxx.19.111 -redirect_port tcp xxx.xxx.19.102:443 xxx.xxx.19.111:443 3. Change the ipfw rules to allow this new configuration through. This is basically the same as the firewall rules above, but each entry is doubled, where ${ip} becomes ${fail_ip}. In addition to this, another rule is entered in the "natd_enable" section to divert the new natd: case ${natd_enable} in [Yy][Ee][Ss]) if [ -n "${natd_interface}" ]; then ${fwcmd} add 50 divert natd all from any to any via ${natd_interface} ${fwcmd} add 50 divert ${fail_natd} all from any to any via ${natd_interface} fi ;; esac Once I've added this, this port forwarding on xxx.xxx.19.110 still works, but the port forwarding on the aliased IP (xxx.xxx.19.111) doesn't! I'm not sure exactly where the problem lies, but I assume it has something to do with my ipfw ruleset. I looked at a previous post here: http://lists.freebsd.org/pipermail/freebsd-ipfw/2004-March/000976.html that looks similar to my situation, but still no love. If any could help out with the config, it'd be much appreciated! I'm more than happy to provide any further config details, tcp dumps, etc. Regards, Leigh From owner-freebsd-net@FreeBSD.ORG Fri Mar 19 00:17:46 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9038B16A4CE for ; Fri, 19 Mar 2004 00:17:46 -0800 (PST) Received: from mail.ipnet.kiev.ua (ns.ip.net.ua [82.193.96.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 82F3C43D41 for ; Fri, 19 Mar 2004 00:17:45 -0800 (PST) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by mail.ipnet.kiev.ua (8.12.10/8.12.6) with ESMTP id i2J8HSU2040110 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 19 Mar 2004 10:17:28 +0200 (EET) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i2J8HKQG018777; Fri, 19 Mar 2004 10:17:20 +0200 (EET) (envelope-from ru) Date: Fri, 19 Mar 2004 10:17:20 +0200 From: Ruslan Ermilov To: Chuck Swiger Message-ID: <20040319081720.GE18091@ip.net.ua> References: <200403181750.35948.jrh@it.uc3m.es> <4059E686.6050207@mac.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tVmo9FyGdCe4F4YN" Content-Disposition: inline In-Reply-To: <4059E686.6050207@mac.com> User-Agent: Mutt/1.5.6i cc: freebsd-net@FreeBSD.org cc: Juan Rodriguez Hervella Subject: Re: Small question about bridging and arp X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2004 08:17:46 -0000 --tVmo9FyGdCe4F4YN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 18, 2004 at 01:12:22PM -0500, Chuck Swiger wrote: > Juan Rodriguez Hervella wrote: > >If I do a bridge between xl0 and xl1, can the IP address > >configured on xl1 answer ARP-requests that come from the > >LAN the xl0 is connected ? Does this make sense ? >=20 > Yes, it should. Bridging basicly treats xl0 and xl1 as being on the same= =20 > physical network and an ARP request for an IP used by one of the two=20 > interfaces should be answered regardless of where it came from. >=20 One typically also sets net.link.ether.inet.log_arp_wrong_iface=3D0, to avoid annoying kernel messages in such a setup. (See the arp(4) manpage for details.) Cheers, --=20 Ruslan Ermilov FreeBSD committer ru@FreeBSD.org --tVmo9FyGdCe4F4YN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAWqyQUkv4P6juNwoRAoKwAJ9ZJ6gtTGCvI0y1glKiWeaad5F8sQCfV8qL AYbSkC3k6XksblR91VdGqCA= =KaEy -----END PGP SIGNATURE----- --tVmo9FyGdCe4F4YN-- From owner-freebsd-net@FreeBSD.ORG Fri Mar 19 00:45:54 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6AB6816A4CE for ; Fri, 19 Mar 2004 00:45:54 -0800 (PST) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3BD6343D48 for ; Fri, 19 Mar 2004 00:45:53 -0800 (PST) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.10/8.12.9) with ESMTP id i2J8oTCP050317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Mar 2004 10:50:31 +0200 (EET) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i2J8jdtA018921; Fri, 19 Mar 2004 10:45:39 +0200 (EET) (envelope-from ru) Date: Fri, 19 Mar 2004 10:45:39 +0200 From: Ruslan Ermilov To: Juan Rodriguez Hervella Message-ID: <20040319084539.GF18091@ip.net.ua> References: <200403181712.03629.jrh@it.uc3m.es> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wtjvnLv0o8UUzur2" Content-Disposition: inline In-Reply-To: <200403181712.03629.jrh@it.uc3m.es> User-Agent: Mutt/1.5.6i X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: freebsd-net@freebsd.org Subject: Re: sysctl -w net.link.ether.inet.proxyall=1 ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2004 08:45:54 -0000 --wtjvnLv0o8UUzur2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 18, 2004 at 05:12:03PM +0100, Juan Rodriguez Hervella wrote: > What this is used for ? >=20 This is an extension to the ARP proxying feature, allowing you to easily set it up. Normally, to do an ARP proxying, you would need to set up all individual ARP proxy entries (see the arp(8) manpage for details). By turning this sysctl on, you don't need to set up each individual proxy entry. Instead, the host will act as if proxy ARP entry was already set, which some precautions made to ensure that the host acting as a proxy can can really proxy it via some other network interface: - ARP request arrives via Ethernet interface if0, - ARP code determines that the target address is not one of its own, - ARP code looks up a proxy ARP entry, and fails, - arp_proxyall is enabled (otherwise, the processing stops here), - ARP code looks for a route to the destination (from the ARP request), - if interface the request came in from is the same as the route points to, nothing is sent back, - ARP reply is constructed and sent back. Example. - A host is assigned an IP address 10.0.0.1 (with the standard class B netmask) to its Ethernet interface fxp0. - There is a ppp(8) session established over the tun0 interface with the remote end assigned the 10.0.0.2 IP address. (There's a host route pointing to 10.0.0.2 through tun0.) - The host is configured to do arp_proxyall. - An ARP request for 10.0.0.2 arrives through fxp0. - The host sends ARP reply back with its own MAC address of fxp0, allowing the LAN machines to talk to the PPP client. Cheers, --=20 Ruslan Ermilov FreeBSD committer ru@FreeBSD.org --wtjvnLv0o8UUzur2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAWrMzUkv4P6juNwoRApbDAJ94nJNGkXuehjErViY484/x8NFGYQCeIQNO 2v+cSxtqW0gHobJz7eHpH5w= =/Lmx -----END PGP SIGNATURE----- --wtjvnLv0o8UUzur2-- From owner-freebsd-net@FreeBSD.ORG Fri Mar 19 01:43:04 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE00516A4CF; Fri, 19 Mar 2004 01:43:04 -0800 (PST) Received: from hotmail.com (bay16-f100.bay16.hotmail.com [65.54.186.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id D073C43D1D; Fri, 19 Mar 2004 01:43:04 -0800 (PST) (envelope-from fuhuayin@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 19 Mar 2004 01:02:41 -0800 Received: from 193.190.247.203 by by16fd.bay16.hotmail.msn.com with HTTP; Fri, 19 Mar 2004 09:02:40 GMT X-Originating-IP: [193.190.247.203] X-Originating-Email: [fuhuayin@hotmail.com] X-Sender: fuhuayin@hotmail.com From: "Fuhua Yin" To: suz@freebsd.org Date: Fri, 19 Mar 2004 10:02:40 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 19 Mar 2004 09:02:41.0068 (UTC) FILETIME=[EF132EC0:01C40D90] cc: freebsd-net@freebsd.org cc: yin@helios.iihe.ac.be Subject: Re: Multicast IPv6, socket, X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2004 09:43:05 -0000 Hello Suzuki, Do you know how to use packet filter (BSD Packet filter) like netfilter in linux? I would appreciate if you give me some links or reference. Many thanks in advance, fuhua >From: SUZUKI Shinsuke >To: fuhuayin@hotmail.com >CC: freebsd-net@freebsd.org, yin@helios.iihe.ac.be >Subject: Re: Multicast IPv6, socket, >Date: Fri, 19 Mar 2004 00:54:05 +0900 > >Hi, > > >>>>> On Thu, 18 Mar 2004 13:36:12 +0100 > >>>>> fuhuayin@hotmail.com("Fuhua Yin") said: > > > I am trying to work on IPv6 multicast. I just wrote a small programme to > > test but get stuck somewhere. I wonder if someone could be of help. > >Please refer to mcastsend (kame/kame/mcastsend), available in KAME >SNAP Tarball. It does quite the same thing as your program. > >(it's not merged into freebsd-current yet, since it's normally a >debugging tool for developers. If there's a strong request, I'm >willing to merge it into -current, though) > >Thanks, >---- >SUZUKI, Shinsuke @ Hitachi / KAME Project _________________________________________________________________ From owner-freebsd-net@FreeBSD.ORG Fri Mar 19 03:14:19 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 50C2916A4CE; Fri, 19 Mar 2004 03:14:19 -0800 (PST) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id E5D3843D3F; Fri, 19 Mar 2004 03:14:17 -0800 (PST) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])i2JBDbJ13820; Fri, 19 Mar 2004 12:13:47 +0100 (MET) Date: Fri, 19 Mar 2004 12:13:37 +0100 (CET) From: Harti Brandt To: Gleb Smirnoff In-Reply-To: <20040316230130.GA20251@cell.sick.ru> Message-ID: <20040319115814.E41950@beagle.fokus.fraunhofer.de> References: <200403072302.i27N2StR008804@freefall.freebsd.org> <20040308102033.GA66247@cell.sick.ru> <20040308212939.GB30394@ip.net.ua> <20040308214820.GA68803@cell.sick.ru> <20040309065356.GA55139@ip.net.ua> <20040309185957.GB74537@cell.sick.ru> <20040316230130.GA20251@cell.sick.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: Nodes having common properties. Was: kern/63864: [patch] new control message for ng_iface(4) - getifindex X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2004 11:14:19 -0000 On Wed, 17 Mar 2004, Gleb Smirnoff wrote: GS>So I have proposed a different approach, and ru liked it. What will GS>you say about it? GS> GS>Two new fields in struct ng_type are introduced: GS>- u_int32_t family, a generic node type. All current nodes have this field GS> as 0, they have no similar properties. For example, interface node family GS> has value of 1. GS>- void *family_data, a pointer to a family specific data. In case of interface GS> family, it'll be struct ifnet *. GS> GS>A macro for assigning to a specific family is written. This macro sets type GS>and sets pointer to proper data. GS> GS>Within this approach we have got kind of inherited properties. The only thing GS>node needs to join some family, is to set its family and pass pointer to data. GS>After this, it will support all family messages. Family specific messages really GS>never reach the node code. They are handled in ng_base.c. It would be nice if it would be possible to classify a node to belong to more than one family. I think, that the functionality provided by the family stuff is more like the 'interface' stuff in Java. One example where this can be used are specialisation of interface nodes. I'm about to commit an ATM pseudo device node that will (among other uses) be very helpful for automatic testing of the ATM stuff. As such it implements the network interface messages (GET_IFINDEX, ...) plus common messages with the real ATM device node (ng_atm; GET_CONFIG, GET_VCCS, ...). I think there are other uses too. I see at least two ways of implementing this: 1) by handling the assignment to a family via a generic function, that, for example, manages an array of family/data pairs for each node. Instead of simply checking the family type when receiving a message you'll have to loop around (control messages handling performance shouldn't be a bottleneck). 2) making family message handling explicite instead of implicite. In foo_rcvmsg you would have something like: switch (cookie) { ... case NGM_IFACE_FAMILY_COOKIE: ng_handle_iface_family_msg(...); break; case NGM_ATMIFACE_FAMILY_COOKIE: ng_handle_atmiface_family_msg(...); break; ... } The 2nd variant seems slightly more easy to implement and more flexible than the first. harti From owner-freebsd-net@FreeBSD.ORG Fri Mar 19 04:33:37 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 713C516A4CE; Fri, 19 Mar 2004 04:33:37 -0800 (PST) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9207943D3F; Fri, 19 Mar 2004 04:33:36 -0800 (PST) (envelope-from glebius@cell.sick.ru) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.9/8.12.8) with ESMTP id i2JCXUQE039165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Mar 2004 15:33:31 +0300 (MSK) (envelope-from glebius@cell.sick.ru) Received: (from glebius@localhost) by cell.sick.ru (8.12.9/8.12.6/Submit) id i2JCXTrg039164; Fri, 19 Mar 2004 15:33:29 +0300 (MSK) Date: Fri, 19 Mar 2004 15:33:29 +0300 From: Gleb Smirnoff To: Harti Brandt Message-ID: <20040319123329.GA39103@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , Harti Brandt , Ruslan Ermilov , julian@freebsd.org, archie@freebsd.org, freebsd-net@freebsd.org References: <200403072302.i27N2StR008804@freefall.freebsd.org> <20040308102033.GA66247@cell.sick.ru> <20040308212939.GB30394@ip.net.ua> <20040308214820.GA68803@cell.sick.ru> <20040309065356.GA55139@ip.net.ua> <20040309185957.GB74537@cell.sick.ru> <20040316230130.GA20251@cell.sick.ru> <20040319115814.E41950@beagle.fokus.fraunhofer.de> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20040319115814.E41950@beagle.fokus.fraunhofer.de> User-Agent: Mutt/1.5.6i cc: freebsd-net@freebsd.org Subject: Re: Nodes having common properties. Was: kern/63864: [patch] new control message for ng_iface(4) - getifindex X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2004 12:33:37 -0000 On Fri, Mar 19, 2004 at 12:13:37PM +0100, Harti Brandt wrote: H> It would be nice if it would be possible to classify a node to belong to H> more than one family. I think, that the functionality provided by the H> family stuff is more like the 'interface' stuff in Java. One example where H> this can be used are specialisation of interface nodes. I'm about to H> commit an ATM pseudo device node that will (among other uses) be very H> helpful for automatic testing of the ATM stuff. As such it implements the H> network interface messages (GET_IFINDEX, ...) plus common messages with H> the real ATM device node (ng_atm; GET_CONFIG, GET_VCCS, ...). I think H> there are other uses too. H> H> I see at least two ways of implementing this: H> H> 1) by handling the assignment to a family via a generic function, that, H> for example, manages an array of family/data pairs for each node. Instead H> of simply checking the family type when receiving a message you'll have H> to loop around (control messages handling performance shouldn't be a H> bottleneck). H> H> 2) making family message handling explicite instead of implicite. In H> foo_rcvmsg you would have something like: H> H> switch (cookie) { H> H> ... H> H> case NGM_IFACE_FAMILY_COOKIE: H> ng_handle_iface_family_msg(...); H> break; H> H> case NGM_ATMIFACE_FAMILY_COOKIE: H> ng_handle_atmiface_family_msg(...); H> break; H> H> ... H> } H> H> The 2nd variant seems slightly more easy to implement and more flexible H> than the first. The 2nd variant seems very familiar (may be even same) as my first proposal. In private discussion with Ruslan, he said that this approach looks like a hack, and is not extendible. And he convinced me. Really, this approach means that message handlers are in the ng_foo.c files, and joining family doesn't mean automagic support of family messages. Also, it leads to code dublication, which is bad. I'd prefer first idea. In its case all you need to support family messages, is to call two methods NG_JOIN_FAMILY(NG_FAMILY_ATM, (void *)some_atm_data); NG_JOIN_FAMILY(NG_FAMILY_IFACE, (void *)priv->ifp); from your constructor method. Family messages must be supported by netgraph, not by nodes. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Fri Mar 19 05:24:51 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5731816A4CE; Fri, 19 Mar 2004 05:24:51 -0800 (PST) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id C45D443D2F; Fri, 19 Mar 2004 05:24:49 -0800 (PST) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])i2JDOlJ10124; Fri, 19 Mar 2004 14:24:47 +0100 (MET) Date: Fri, 19 Mar 2004 14:24:47 +0100 (CET) From: Harti Brandt To: Gleb Smirnoff In-Reply-To: <20040319123329.GA39103@cell.sick.ru> Message-ID: <20040319141700.J42356@beagle.fokus.fraunhofer.de> References: <200403072302.i27N2StR008804@freefall.freebsd.org> <20040308212939.GB30394@ip.net.ua><20040309065356.GA55139@ip.net.ua> <20040316230130.GA20251@cell.sick.ru> <20040319123329.GA39103@cell.sick.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: Nodes having common properties. Was: kern/63864: [patch] new control message for ng_iface(4) - getifindex X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: harti@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2004 13:24:51 -0000 On Fri, 19 Mar 2004, Gleb Smirnoff wrote: GS>On Fri, Mar 19, 2004 at 12:13:37PM +0100, Harti Brandt wrote: GS>H> It would be nice if it would be possible to classify a node to belong to GS>H> more than one family. I think, that the functionality provided by the GS>H> family stuff is more like the 'interface' stuff in Java. One example where GS>H> this can be used are specialisation of interface nodes. I'm about to GS>H> commit an ATM pseudo device node that will (among other uses) be very GS>H> helpful for automatic testing of the ATM stuff. As such it implements the GS>H> network interface messages (GET_IFINDEX, ...) plus common messages with GS>H> the real ATM device node (ng_atm; GET_CONFIG, GET_VCCS, ...). I think GS>H> there are other uses too. GS>H> GS>H> I see at least two ways of implementing this: GS>H> GS>H> 1) by handling the assignment to a family via a generic function, that, GS>H> for example, manages an array of family/data pairs for each node. Instead GS>H> of simply checking the family type when receiving a message you'll have GS>H> to loop around (control messages handling performance shouldn't be a GS>H> bottleneck). GS>H> GS>H> 2) making family message handling explicite instead of implicite. In GS>H> foo_rcvmsg you would have something like: GS>H> GS>H> switch (cookie) { GS>H> GS>H> ... GS>H> GS>H> case NGM_IFACE_FAMILY_COOKIE: GS>H> ng_handle_iface_family_msg(...); GS>H> break; GS>H> GS>H> case NGM_ATMIFACE_FAMILY_COOKIE: GS>H> ng_handle_atmiface_family_msg(...); GS>H> break; GS>H> GS>H> ... GS>H> } GS>H> GS>H> The 2nd variant seems slightly more easy to implement and more flexible GS>H> than the first. GS> GS> The 2nd variant seems very familiar (may be even same) as my first GS>proposal. In private discussion with Ruslan, he said that this approach GS>looks like a hack, and is not extendible. And he convinced me. Really, GS>this approach means that message handlers are in the ng_foo.c files, and GS>joining family doesn't mean automagic support of family messages. Also, GS>it leads to code dublication, which is bad. GS> GS> I'd prefer first idea. In its case all you need to support family GS>messages, is to call two methods GS> GS> NG_JOIN_FAMILY(NG_FAMILY_ATM, (void *)some_atm_data); GS> NG_JOIN_FAMILY(NG_FAMILY_IFACE, (void *)priv->ifp); GS> GS> from your constructor method. Family messages must be supported by GS>netgraph, not by nodes. >From the point of code duplication and extendibility both approaches are equivalent. In the second case you have the same three lines in the rcvmsg function of every node that supports a given familiy (this is reduceable to 1 line by defining appropriate macros), in the first one you have the same line in every constructor. Perhaps I made not clear that the message handling function for the familiy is not in the node's code nor in the netgraph base code, but in a family file (in both cases) and module. But I have no strong opinion: either way does it as long as it allows multiple interfaces to a given node. harti From owner-freebsd-net@FreeBSD.ORG Fri Mar 19 05:42:32 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A52B16A4CE; Fri, 19 Mar 2004 05:42:32 -0800 (PST) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6059E43D31; Fri, 19 Mar 2004 05:42:31 -0800 (PST) (envelope-from glebius@cell.sick.ru) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.9/8.12.8) with ESMTP id i2JDgSQE039852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Mar 2004 16:42:29 +0300 (MSK) (envelope-from glebius@cell.sick.ru) Received: (from glebius@localhost) by cell.sick.ru (8.12.9/8.12.6/Submit) id i2JDgSt1039851; Fri, 19 Mar 2004 16:42:28 +0300 (MSK) Date: Fri, 19 Mar 2004 16:42:28 +0300 From: Gleb Smirnoff To: harti@freebsd.org Message-ID: <20040319134228.GB39787@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , harti@freebsd.org, Ruslan Ermilov , julian@freebsd.org, archie@freebsd.org, freebsd-net@freebsd.org References: <200403072302.i27N2StR008804@freefall.freebsd.org> <20040308102033.GA66247@cell.sick.ru> <20040308212939.GB30394@ip.net.ua> <20040308214820.GA68803@cell.sick.ru> <20040309065356.GA55139@ip.net.ua> <20040309185957.GB74537@cell.sick.ru> <20040316230130.GA20251@cell.sick.ru> <20040319115814.E41950@beagle.fokus.fraunhofer.de> <20040319123329.GA39103@cell.sick.ru> <20040319141700.J42356@beagle.fokus.fraunhofer.de> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20040319141700.J42356@beagle.fokus.fraunhofer.de> User-Agent: Mutt/1.5.6i cc: freebsd-net@freebsd.org Subject: Re: Nodes having common properties. Was: kern/63864: [patch] new control message for ng_iface(4) - getifindex X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2004 13:42:32 -0000 On Fri, Mar 19, 2004 at 02:24:47PM +0100, Harti Brandt wrote: H> From the point of code duplication and extendibility both approaches are H> equivalent. In the second case you have the same three lines in the rcvmsg H> function of every node that supports a given familiy (this is reduceable H> to 1 line by defining appropriate macros), in the first one you have the H> same line in every constructor. Perhaps I made not clear that the message H> handling function for the familiy is not in the node's code nor in the H> netgraph base code, but in a family file (in both cases) and module. I understand, now. If ng_process_family_xxx_msg() is out of node, than you are right - approeaches are equivalent. H> But I have no strong opinion: either way does it as long as it allows H> multiple interfaces to a given node. OK, let's wait for reply from someone in Cc: :) -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Fri Mar 19 06:45:16 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1B98F16A4CE for ; Fri, 19 Mar 2004 06:45:16 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8758F43D2D for ; Fri, 19 Mar 2004 06:45:14 -0800 (PST) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from ocean.jinmei.org (unknown [2001:200:0:8002:1cd:a55e:4cad:fa70]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id A384A15210; Fri, 19 Mar 2004 23:45:12 +0900 (JST) Date: Fri, 19 Mar 2004 23:45:13 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: toni In-Reply-To: <1078905022.5474.18.camel@sis47.xtec.es> References: <1078905022.5474.18.camel@sis47.xtec.es> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII cc: freebsd-net@FreeBSD.org Subject: Re: ipv6 autoconf on vlan interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2004 14:45:16 -0000 >>>>> On Wed, 10 Mar 2004 08:50:22 +0100, >>>>> toni said: > i'm trying to set up a FreeBSD 5.2 with trunking with 11 vlan interfaces > to advertise ipv6 prefixes in an ipv6 native network > my purpose is that vlan interfaces will configure their address from the > prefix advertised on the same machine You seem to want to auto-configure router's addresses by router advertisement from itself. RFC2462 does not allow such a configuration, and we'll have to configure router's addresses/prefixes by hand. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-freebsd-net@FreeBSD.ORG Fri Mar 19 11:35:18 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D6FB16A4CE for ; Fri, 19 Mar 2004 11:35:18 -0800 (PST) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD10743D2F for ; Fri, 19 Mar 2004 11:35:17 -0800 (PST) (envelope-from cristjc@comcast.net) Received: from blossom.cjclark.org (c-67-169-127-171.client.comcast.net[67.169.127.171]) by comcast.net (sccrmhc11) with ESMTP id <2004031919351601100idq06e>; Fri, 19 Mar 2004 19:35:16 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.9p2/8.12.8) with ESMTP id i2JJZF0m054464; Fri, 19 Mar 2004 11:35:15 -0800 (PST) (envelope-from cristjc@comcast.net) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.9p2/8.12.9/Submit) id i2JJZEjQ054463; Fri, 19 Mar 2004 11:35:14 -0800 (PST) (envelope-from cristjc@comcast.net) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to cristjc@comcast.net using -f Date: Fri, 19 Mar 2004 11:35:14 -0800 From: "Crist J. Clark" To: 789456123@gmx.de Message-ID: <20040319193514.GB54073@blossom.cjclark.org> References: <6686.1079661277@www27.gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6686.1079661277@www27.gmx.net> User-Agent: Mutt/1.4.1i X-URL: http://people.freebsd.org/~cjc/ cc: freebsd-net@freebsd.org Subject: Re: BIND: Lookup of CNAME records X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Crist J. Clark" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2004 19:35:18 -0000 On Fri, Mar 19, 2004 at 02:54:37AM +0100, 789456123@gmx.de wrote: > I have set up a FreeBSD (5.2.1-RELEASE) box acting as a gateway and > running version 8.3.7-REL of BIND. For testing purposes my > configuration file looks as follows: > > options { > directory "/etc/namedb"; > pid-file "/var/run/named/pid"; > > forward only; > > forwarders { > 195.62.99.42; > 195.62.97.177; > }; > > query-source address * port 53; > }; > > zone "." { > type hint; > file "named.root"; > }; > > This setup (actually a replacement for just adding the two nameservers > to resolv.conf) works fine with lookup tools like "host", "nslookup", > or "dnsquery". However, when I try to telnet or ftp a server whose > name is a CNAME record, it takes about 77 seconds until the lookup is > complete. This appears quite odd to me, as "host" does the lookup > perfectly well and fast. Connections to A name records are no problem > however. How long does it take to do a reverse-lookup on the result of the previous lookups? The applications may be trying to resolve a PTR record for the final IP address they end up with. > My first assumption was that "ftp" or "telnet" were not doing lookups > properly. But modifying resolv.conf in a way that it uses the two > nameservers directly (instead of the local nameserver) solved the > CNAME lookup problem. Strange. The first issue wouldn't really explain that. You can try the following two tests and compare the difference, 1) Put the two external servers in resolv.conf, and run, # tcpdump -s512 port 53 And try your ftp or telnet. 2) Put 127.0.0.1 back into resolv.conf, clear the cache of the local BIND (not sure of a way to do that other than killing and restarting in 8.x.x), and run the same thing, # tcpdump -s512 port 53 And again try the ftp or telnet. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org From owner-freebsd-net@FreeBSD.ORG Fri Mar 19 14:05:48 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 24E2916A4CE for ; Fri, 19 Mar 2004 14:05:48 -0800 (PST) Received: from mailout02.sul.t-online.com (mailout02.sul.t-online.com [194.25.134.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id B7C7E43D2F for ; Fri, 19 Mar 2004 14:05:47 -0800 (PST) (envelope-from Holger.Eitzenberger@t-online.de) Received: from fwd01.aul.t-online.de by mailout02.sul.t-online.com with smtp id 1B4S7e-0004O9-07; Fri, 19 Mar 2004 23:05:46 +0100 Received: from kruemel.eitzenberger.name (bdHSI2ZCYeN+vjfkJ9hcPv4KA8m63Vt+rGE4TEAi+WzVmDPOukp6Ur@[62.224.20.157]) by fwd01.sul.t-online.com with esmtp id 1B4S7a-0q7al60; Fri, 19 Mar 2004 23:05:42 +0100 Received: from [192.168.10.10] (helo=jonathan.eitzenberger.name) by kruemel.eitzenberger.name with esmtp (Exim 4.22) id 1B4S6x-00009u-QD for freebsd-net@freebsd.org; Fri, 19 Mar 2004 23:05:03 +0100 Received: from holger by jonathan.eitzenberger.name with local (Exim 3.35 #1 (Debian)) id 1B4S8U-0006gN-00 for ; Fri, 19 Mar 2004 23:06:38 +0100 Date: Fri, 19 Mar 2004 23:06:38 +0100 To: freebsd-net@freebsd.org Message-ID: <20040319230638.A25674@eitzenberger.name> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WIyZ46R2i8wDzkSu" Content-Disposition: inline User-Agent: Mutt/1.2.5i From: "Holger Eitzenberger" X-Seen: false X-ID: bdHSI2ZCYeN+vjfkJ9hcPv4KA8m63Vt+rGE4TEAi+WzVmDPOukp6Ur Subject: IPsec: problems after upgrade 4.8 to 4.9 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2004 22:05:48 -0000 --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I was sucessfully running FBSD 4.8 with X509 certicate VPN. After installation of FBSD 4.9 I get the following error messages: isakmp.c:899:isakmp_ph1begin_r(): begin Identity Protection mode. ERROR: ipsec_doi.c:1318:get_transform(): Only a single transform payload i= s allowed during phase 1 processing. (*) ERROR: ipsec_doi.c:440:print_ph1mismatched(): rejected dh_group: DB(pr= op#1:trns#1):Peer(prop#0:trns#0) =3D 1024-bit MODP group:1536-bit MODP group ERROR: ipsec_doi.c:243:get_ph1approval(): no suitable proposal found. ERROR: isakmp_ident.c:782:ident_r1recv(): failed to get valid proposal. ERROR: isakmp.c:913:isakmp_ph1begin_r(): failed to process packet. =20 The connecting peer is a Linux box (FreeSwan 1.99). Line (*) looks suspicious to me. Is there some persistant data between too VPN "sessions", which is now missing on one side of the link after installation? This is my racoon configuration: path include "/usr/local/etc/racoon" ; path certificate "/usr/local/etc/racoon/cert"; log notify; # notify, debug, debug2 padding { maximum_length 20; # maximum padding length. strict_check off; # enable strict check. exclusive_tail off; # extract last one octet. } listen { isakmp XXX.XXX.XXX.XXX [500]; } timer { counter 5; interval 20 sec; persend 1; phase1 30 sec; phase2 15 sec; } remote anonymous { exchange_mode main; my_identifier asn1dn; peers_identifier asn1dn; certificate_type x509 "XXX.pem" "XXX.pem"; peers_certfile "YYY.pem"; passive on; lifetime time 1 hour; # sec,min,hour support_proxy on; proposal_check obey; proposal { encryption_algorithm 3des; hash_algorithm md5; authentication_method rsasig; dh_group 2; } } sainfo anonymous { pfs_group 1; lifetime time 30 sec; encryption_algorithm 3des; authentication_algorithm hmac_sha1,hmac_md5; compression_algorithm deflate; } /Holger --=20 ++ GnuPG Key -> http://www.t-online.de/~holger.eitzenberger ++ --WIyZ46R2i8wDzkSu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAW27uwVlL9V2akAURAqOvAJ9YqBwybt2gJrLGm69vyuhoZ74UBgCdHmzC ace4jKGwcQirSFJ0IFx1U08= =2C8V -----END PGP SIGNATURE----- --WIyZ46R2i8wDzkSu-- From owner-freebsd-net@FreeBSD.ORG Fri Mar 19 19:23:33 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5664416A4CE; Fri, 19 Mar 2004 19:23:33 -0800 (PST) Received: from mail001.syd.optusnet.com.au (mail001.syd.optusnet.com.au [211.29.132.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 682D043D1D; Fri, 19 Mar 2004 19:23:31 -0800 (PST) (envelope-from tfrank@optushome.com.au) Received: from marvin.home.local (c211-28-241-126.eburwd5.vic.optusnet.com.au [211.28.241.126])i2K3NSo06438; Sat, 20 Mar 2004 14:23:29 +1100 Received: by marvin.home.local (Postfix, from userid 1001) id 9C3031FB81; Sat, 20 Mar 2004 14:23:28 +1100 (EST) Date: Sat, 20 Mar 2004 14:23:28 +1100 From: Tony Frank To: ktulu@net2000.com.au Message-ID: <20040320032328.GA66773@marvin.home.local> References: <1079670127.405a756f4bafe@secure.net2000.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1079670127.405a756f4bafe@secure.net2000.com.au> User-Agent: Mutt/1.4.2.1i cc: freebsd-net@freebsd.org cc: freebsd-ipfw@freebsd.org Subject: Re: port forwarding and ipfw rules X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2004 03:23:33 -0000 Hi there, On Fri, Mar 19, 2004 at 03:22:07PM +1100, ktulu@net2000.com.au wrote: > Hi All, > > I have posted this question before, but I don't think I made myself very clear > in what I was hoping to achieve. Hopefully, this post will help out. > > I have a situation where I have one network interface (fxp1) connected to the > network with the IP address xxx.xxx.19.110 which is port forwarding (on port > 443) to a host xxx.xxx.19.109. Currently, this situation works fine. > > The problem I'm having is that I have two of these machines doing the same thing > and I require the ability for one machine to take over from the other in the > event of a hardware failure, etc. The diagram below basically shows what I want > to achieve: > > > Internet > ---------- > | > | > | > fxp1 | fxp1 > .19.110 | .19.111 > | (alias) > | > ----------------- > | FW | > | Default route | > | xx.xx.19.225 | > | | > ----------------- > | > / \ > fxp1 / \ fxp1 > .19.110/ \.19.111 (alias) > / \ > / \ > / \ > / \ > / \ > / \ > / \ > ----- ----- > | | | | > | | | | > | | | | > | | | | > ----- ----- > Web Server Web Server > x.x.19.109:443 x.x.19.102:443 fxp1 seems to be very busy in this picture. My understanding is that you want to do: 1. redirect any connections to .19.110:443 to .19.109:443 2. redirect any connections to .19.111:443 to .19.102:443 Assuming your uplink is sending traffic for .19.110 and .19.111 to your interface (fxp1) (You can do this by aliasing 111 to the 110 interface as you already indicated) You just need a natd.conf with something like this in it: redirect_port tcp .19.109:443 .19.110:443 redirect_port tcp .19.102:443 .19.111:443 I got it going with similar kind of setup. In my case I used port 80 and tried to get network setup as I understand your description, something like the below: (internet) | public IP +------+ | fxp0 | In my case this one runs natd/squid | ext. | so all queries to internal net appear to | f/w | originate from .10 | fxp2 | +------+ | .10 +---+------+---------+ .110 | .111 | .109 | .102 +------+ +------+ +------+ | fxp0 | | fxp0 | | fxp0 | | g/w | | www1 | | www2 | +------+ +------+ +------+ g/w is running ipfw + natd to divert traffic www1 and www2 are simple servers running apache tcpdump shows: 1. syn packet comes in to 110:80 2. syn packet is sent out to 109:80 (rewritten by natd to appear from 110:80) 3. syn+ack comes back to 110 4. 110 forwards back to original source and so on for the rest of the connection. Same deal for traffic to 111 (tcpdump output below) Note: www1 and www2 see the traffic as originating from .110 and reply appropriately. .110 sends it all to natd which replaces the IP headers so the reply traffic has source either .110 or .111 depending on where the request came from. Also my g/w (.110) is currently 5.2.1 but the config should be same for 4.9. Details follow: /etc/natd.conf: log yes dynamic yes log_denied yes deny_incoming no use_sockets yes same_ports yes target_address 255.255.255.255 log_ipfw_denied yes redirect_port tcp 192.168.200.109:80 192.168.200.110:80 redirect_port tcp 192.168.200.102:80 192.168.200.111:80 ifconfig -a: midway# ifconfig -a fxp0: flags=8943 mtu 1500 inet 192.168.200.110 netmask 0xffffff00 broadcast 192.168.200.255 inet 192.168.200.111 netmask 0xffffffff broadcast 192.168.200.111 ether 00:06:29:f1:82:72 media: Ethernet autoselect (100baseTX ) status: active plip0: flags=8810 mtu 1500 lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 ipfw rules: 00050 216691 60715152 divert 8668 ip from any to any via fxp0 00100 0 0 allow ip from any to any via lo0 00200 0 0 deny ip from any to 127.0.0.0/8 00300 0 0 deny ip from 127.0.0.0/8 to any 65000 212716 60372772 allow ip from any to any 65535 0 0 deny ip from any to any tcpdumps of the traffic: 13:47:25.595348 192.168.200.10.3881 > 192.168.200.110.80: S 642583182:642583182(0) win 65535 (DF) 13:47:25.596052 192.168.200.110.3881 > 192.168.200.109.80: S 642583182:642583182(0) win 65535 (DF) 13:47:25.596121 192.168.200.110 > 192.168.200.10: icmp: redirect 192.168.200.109 to host 192.168.200.109 (DF) 13:47:25.596495 192.168.200.109.80 > 192.168.200.110.3881: S 1971745869:1971745869(0) ack 642583183 win 65535 (DF) 13:47:25.596712 192.168.200.110.80 > 192.168.200.10.3881: S 1971745869:1971745869(0) ack 642583183 win 65535 (DF) 13:47:25.596791 192.168.200.110 > 192.168.200.109: icmp: redirect 192.168.200.10 to host 192.168.200.10 (DF) 13:47:25.596847 192.168.200.10.3881 > 192.168.200.110.80: . ack 1 win 33304 (DF) 13:47:25.597035 192.168.200.110.3881 > 192.168.200.109.80: . ack 1 win 33304 (DF) 13:47:25.597098 192.168.200.110 > 192.168.200.10: icmp: redirect 192.168.200.109 to host 192.168.200.109 (DF) 13:47:25.597211 192.168.200.10.3881 > 192.168.200.110.80: P 1:509(508) ack 1 win 33304 (DF) 13:47:25.597415 192.168.200.110.3881 > 192.168.200.109.80: P 1:509(508) ack 1 win 33304 (DF) 13:47:25.597480 192.168.200.110 > 192.168.200.10: icmp: redirect 192.168.200.109 to host 192.168.200.109 (DF) 13:47:25.616863 192.168.200.109.80 > 192.168.200.110.3881: P 1:274(273) ack 509 win 33304 (DF) 13:47:25.617161 192.168.200.110.80 > 192.168.200.10.3881: P 1:274(273) ack 509 win 33304 (DF) 13:47:25.617227 192.168.200.110 > 192.168.200.109: icmp: redirect 192.168.200.10 to host 192.168.200.10 (DF) 13:47:25.716982 192.168.200.10.3881 > 192.168.200.110.80: . ack 274 win 33304 (DF) 13:47:25.717368 192.168.200.110.3881 > 192.168.200.109.80: . ack 274 win 33304 (DF) 13:47:25.717436 192.168.200.110 > 192.168.200.10: icmp: redirect 192.168.200.109 to host 192.168.200.109 (DF) 13:49:48.703004 192.168.200.10.3882 > 192.168.200.111.80: S 3017889378:3017889378(0) win 65535 (DF) 13:49:48.703591 192.168.200.110.3882 > 192.168.200.102.80: S 3017889378:3017889378(0) win 65535 (DF) 13:49:48.703680 192.168.200.110 > 192.168.200.10: icmp: redirect 192.168.200.102 to host 192.168.200.102 (DF) 13:49:48.703941 192.168.200.102.80 > 192.168.200.110.3882: S 33897141:33897141(0) ack 3017889379 win 65535 (DF) 13:49:48.704137 192.168.200.111.80 > 192.168.200.10.3882: S 33897141:33897141(0) ack 3017889379 win 65535 (DF) 13:49:48.704201 192.168.200.110 > 192.168.200.102: icmp: redirect 192.168.200.10 to host 192.168.200.10 (DF) 13:49:48.704270 192.168.200.10.3882 > 192.168.200.111.80: . ack 1 win 33304 (DF) 13:49:48.704458 192.168.200.110.3882 > 192.168.200.102.80: . ack 1 win 33304 (DF) 13:49:48.704521 192.168.200.110 > 192.168.200.10: icmp: redirect 192.168.200.102 to host 192.168.200.102 (DF) 13:49:48.704636 192.168.200.10.3882 > 192.168.200.111.80: P 1:509(508) ack 1 win 33304 (DF) 13:49:48.704839 192.168.200.110.3882 > 192.168.200.102.80: P 1:509(508) ack 1 win 33304 (DF) 13:49:48.704904 192.168.200.110 > 192.168.200.10: icmp: redirect 192.168.200.102 to host 192.168.200.102 (DF) 13:49:48.718553 192.168.200.102.80 > 192.168.200.110.3882: P 1:274(273) ack 509 win 33304 (DF) 13:49:48.718844 192.168.200.111.80 > 192.168.200.10.3882: P 1:274(273) ack 509 win 33304 (DF) 13:49:48.718910 192.168.200.110 > 192.168.200.102: icmp: redirect 192.168.200.10 to host 192.168.200.10 (DF) 13:49:48.818588 192.168.200.10.3882 > 192.168.200.111.80: . ack 274 win 33304 (DF) 13:49:48.818947 192.168.200.110.3882 > 192.168.200.102.80: . ack 274 win 33304 (DF) 13:49:48.819014 192.168.200.110 > 192.168.200.10: icmp: redirect 192.168.200.102 to host 192.168.200.102 (DF) > This configuration must be able to be added and removed dynamically without > effecting the existing network setup (other than changing ipfw rules). Below > are the relevant sections of my current configuration settings: Should be able to do this by using ifconfig to add/remove an alias on the interface. There are various tools in ports to do this automatically. If the mappings are static, you should be able to have all combinations defined in a standard natd config file. Hope it helps, Tony From owner-freebsd-net@FreeBSD.ORG Fri Mar 19 20:56:23 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0222116A4CE for ; Fri, 19 Mar 2004 20:56:23 -0800 (PST) Received: from mx.jovenclub.cu (unknown [200.55.154.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F1BD43D1F for ; Fri, 19 Mar 2004 20:56:20 -0800 (PST) (envelope-from admin@jovenclub.cu) Received: from [200.55.154.2] (helo=tinored.jovenclub.cu) by mx.jovenclub.cu with esmtp (Exim 4.24; FreeBSD) id 1B4YWJ-0004rc-Ps for freebsd-net@freebsd.org; Fri, 19 Mar 2004 23:55:39 -0500 Received: from [192.168.4.34] (helo=r6i8w1) by tinored.jovenclub.cu with smtp (Exim 4.00) id 1B4YMP-0009LN-00 for freebsd-net@freebsd.org; Fri, 19 Mar 2004 23:45:26 -0500 Message-ID: <000f01c40e37$98a421a0$2204a8c0@r6i8w1> From: "Maikel L. Miranda" To: Date: Fri, 19 Mar 2004 23:55:40 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: unknow tcp/ip problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2004 04:56:23 -0000 Hi: Recently I installed FreeBSD 5.1 (on a P4 Xeon at 2.4GHz 1GB RAM) and it = worked fine except that from one subnet (Remote Access, attached to a = Computone RAS 2000), so I can't access to any services of the server = (ssh or telnet, this one's just for tests). The ping respond ok in both = directions, the log of my ssh client gives me this: 2004-03-19 23:41:42 Looking up host "192.168.1.25" 2004-03-19 23:41:42 Connecting to 192.168.1.25 port 22 2004-03-19 23:41:43 Server version: SSH-1.99-OpenSSH_3.6.1p1 = FreeBSD-20030924 2004-03-19 23:41:43 We claim version: SSH-1.5-PuTTY-Release-0.53b 2004-03-19 23:41:43 Using SSH protocol version 1 The telnet just hang out after I type the password. From the rest of the = network (500 computers more less) it works exelent. I've gone trough the = configuration over and over but I can't find any possible problem. I = have others servers (Gigaserver 6000) running FreeBSD 5.1 in the same = segment of the network and they work OK. Does anyone has had a problem like this?. I will apreciate any help. Thanks, Maikel L. Miranda. From owner-freebsd-net@FreeBSD.ORG Sat Mar 20 00:09:14 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A073F16A4CE for ; Sat, 20 Mar 2004 00:09:14 -0800 (PST) Received: from web8201.mail.in.yahoo.com (web8201.mail.in.yahoo.com [203.199.70.114]) by mx1.FreeBSD.org (Postfix) with SMTP id B7D8843D45 for ; Sat, 20 Mar 2004 00:09:13 -0800 (PST) (envelope-from manish_6983@yahoo.co.in) Message-ID: <20040320080904.87592.qmail@web8201.mail.in.yahoo.com> Received: from [203.199.146.111] by web8201.mail.in.yahoo.com via HTTP; Sat, 20 Mar 2004 08:09:04 GMT Date: Sat, 20 Mar 2004 08:09:04 +0000 (GMT) From: =?iso-8859-1?q?manish=20gautam?= To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: how to compile kernel with options NETGRAPH ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2004 08:09:14 -0000 how can i compile my kernel with netgraph Actually i want to attach my own created node to the existed ether node. so for that i need ether node. For that i need to compile my kernel with optins NETGRAPH. plz explain elaborately. Reply asap Best regards Manish Gautam ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From owner-freebsd-net@FreeBSD.ORG Sat Mar 20 00:17:02 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C540316A4CE for ; Sat, 20 Mar 2004 00:17:02 -0800 (PST) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81E4F43D1F for ; Sat, 20 Mar 2004 00:17:02 -0800 (PST) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (sccrmhc11) with ESMTP id <2004032008170101100ied4le>; Sat, 20 Mar 2004 08:17:01 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id AAA06821; Sat, 20 Mar 2004 00:16:59 -0800 (PST) Date: Sat, 20 Mar 2004 00:16:58 -0800 (PST) From: Julian Elischer To: =?iso-8859-1?q?manish=20gautam?= In-Reply-To: <20040320080904.87592.qmail@web8201.mail.in.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: how to compile kernel with options NETGRAPH ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2004 08:17:02 -0000 On Sat, 20 Mar 2004, [iso-8859-1] manish gautam wrote: > how can i compile my kernel with netgraph > > Actually i want to attach my own created node to the > existed ether node. so for that i need ether node. > > For that i need to compile my kernel with optins > NETGRAPH. > > plz explain elaborately. Reply asap Add some of the following options to your kernel config file: julian@jules:grep NETG /sys/conf/options # Netgraph(4). Use option NETGRAPH to enable the base netgraph code. NETGRAPH NETGRAPH_ASYNC opt_netgraph.h NETGRAPH_ATMLLC opt_netgraph.h NETGRAPH_BPF opt_netgraph.h NETGRAPH_BRIDGE opt_netgraph.h NETGRAPH_CISCO opt_netgraph.h NETGRAPH_ECHO opt_netgraph.h NETGRAPH_ETHER opt_netgraph.h NETGRAPH_FRAME_RELAY opt_netgraph.h NETGRAPH_GIF opt_netgraph.h NETGRAPH_GIF_DEMUX opt_netgraph.h NETGRAPH_HOLE opt_netgraph.h NETGRAPH_IFACE opt_netgraph.h NETGRAPH_IP_INPUT opt_netgraph.h NETGRAPH_KSOCKET opt_netgraph.h NETGRAPH_L2TP opt_netgraph.h NETGRAPH_LMI opt_netgraph.h NETGRAPH_MPPC_COMPRESSION opt_netgraph.h NETGRAPH_MPPC_ENCRYPTION opt_netgraph.h NETGRAPH_ONE2MANY opt_netgraph.h NETGRAPH_PPP opt_netgraph.h NETGRAPH_PPPOE opt_netgraph.h NETGRAPH_PPTPGRE opt_netgraph.h NETGRAPH_RFC1490 opt_netgraph.h NETGRAPH_SOCKET opt_netgraph.h NETGRAPH_SPLIT opt_netgraph.h NETGRAPH_TEE opt_netgraph.h NETGRAPH_TTY opt_netgraph.h NETGRAPH_UI opt_netgraph.h NETGRAPH_VJC opt_netgraph.h NETGRAPH_ATM_ATMPIF opt_netgraph.h or kldload netgraph kldload ng_ether kldload "mymodule" > > Best regards > Manish Gautam > > ________________________________________________________________________ > Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. > Go to: http://in.insurance.yahoo.com/licspecial/index.html > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Sat Mar 20 01:05:03 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C2A616A4CE for ; Sat, 20 Mar 2004 01:05:03 -0800 (PST) Received: from ns.korolev.net.ru (cnt150n.korolev-net.ru [213.85.109.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id F369E43D31 for ; Sat, 20 Mar 2004 01:05:02 -0800 (PST) (envelope-from dado@ns.korolev.net.ru) Received: by ns.korolev.net.ru (Postfix, from userid 100) id A48B33D9D; Sat, 20 Mar 2004 12:05:05 +0300 (MSK) Date: Sat, 20 Mar 2004 12:05:05 +0300 From: Evgenii Davidov To: freebsd-net@freebsd.org Message-ID: <20040320090505.GB37671@korolev-net.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.4i Subject: [Re: [Mpd-users] crash] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2004 09:05:03 -0000 dear freebsd-wizards! i have installed mpd from ports and it seems that it crashes the kernel via bpf: On Wed, Mar 17, 2004 at 07:51:55PM +0100, Michael Bretterklieber ÐÉÛÅÔ: > Mpd-3.16 had a bad bug (but it shouldn't crash the machine), make sure you > have installed 3.17 on both machines. yes: mpd -v Version 3.17 (root@black 13:18 16-Mar-2004) uname -a FreeBSD black 5.2.1-RELEASE-p3 FreeBSD 5.2.1-RELEASE-p3 #3: Thu Mar 18 11:57:57 MSK 2004 root@black:/ad0/usr/obj/usr/src/sys/B3 i386 finally I've got such a core: panic: page fault panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0x2ea10689 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0588dd8 stack pointer = 0x10:0xd76b1410 frame pointer = 0x10:0xd76b1478 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 29 (swi1: net) trap number = 12 panic: page fault syncing disks, buffers remaining... 3756 3756 3756 3756 3756 3756 3756 3756 3756 3756 3756 3756 3756 3756 3756 3756 3756 3756 3756 3756 giving up on 2881 buffers Uptime: 1d0h6m51s Dumping 510 MB 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496 --- Reading symbols from /boot/kernel/acpi.ko...done. Loaded symbols for /boot/kernel/acpi.ko Reading symbols from /boot/kernel/green_saver.ko...done. Loaded symbols for /boot/kernel/green_saver.ko #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 240 dumping++; (kgdb) list *0xc0588dd8 0xc0588dd8 is in bpf_filter (/usr/src/sys/net/bpf_filter.c:347). 342 continue; 343 #else 344 return 0; 345 #endif 346 } 347 A = p[k]; 348 continue; 349 350 case BPF_LDX|BPF_MSH|BPF_B: 351 k = pc->k; Evgenii V Davidov ----- End forwarded message ----- -- Evgenii V Davidov From owner-freebsd-net@FreeBSD.ORG Sat Mar 20 05:36:42 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F77B16A4CF for ; Sat, 20 Mar 2004 05:36:42 -0800 (PST) Received: from mail.performancedesign.no (a217-118-41-78.bluecom.no [217.118.41.78]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3AA1043D5E for ; Sat, 20 Mar 2004 05:36:42 -0800 (PST) (envelope-from idart@performancedesign.no) Received: from performancedesign.no (fulcrum.performancedesign.no [192.168.1.7]) by mail.performancedesign.no (Postfix) with ESMTP id 31C3A20BC8 for ; Sat, 20 Mar 2004 14:31:40 +0100 (CET) Message-ID: <405C48E8.5060903@performancedesign.no> Date: Sat, 20 Mar 2004 14:36:40 +0100 From: Idar Tollefsen Organization: Performance Design User-Agent: Mozilla Thunderbird 0.5 (Macintosh/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Firewall - why not just block everything not to/from me? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2004 13:36:42 -0000 Hello, I'll admit that networking isn't my strongest side, but I hope to learn some more, and this has been bugging me a little, so I hope someone will bear over with me and explain this. I have a firewall setup based on the "simple" setup in rc.firewall. I was wondering why the blocks for RFC1918 and other "illegal" nets on both sides of natd are as they are? Or rather, why not just block everything not destined for the address(es) on the external interface(s) before natd and everything not from the same address(es) after natd? What would I miss that should, or shouldn't, have let in/out if I do that? Another question is why I need to block incoming traffic to addresses not associated with my machine at all? Why would, for example, my box ever receive request destined for 192.168.0.1 when that's not my address? Thank your for your time. - IT From owner-freebsd-net@FreeBSD.ORG Sat Mar 20 05:38:12 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC01C16A4CF for ; Sat, 20 Mar 2004 05:38:12 -0800 (PST) Received: from web40601.mail.yahoo.com (web40601.mail.yahoo.com [66.218.78.138]) by mx1.FreeBSD.org (Postfix) with SMTP id 9D7E243D2D for ; Sat, 20 Mar 2004 05:38:12 -0800 (PST) (envelope-from pjn0211@yahoo.com) Message-ID: <20040320133812.83192.qmail@web40601.mail.yahoo.com> Received: from [202.183.248.166] by web40601.mail.yahoo.com via HTTP; Sat, 20 Mar 2004 13:38:12 GMT Date: Sat, 20 Mar 2004 13:38:12 +0000 (GMT) From: =?iso-8859-1?q?Supote=20Leelasupphakorn?= To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit cc: questions@freebsd.org Subject: How can I do this on DHCP server ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2004 13:38:12 -0000 Hi list, I've set up a DHCP server but I'd like to know which address (from address pool) hasn't assigned to any machine. Is there command line to accomplish this. PS. I use ISC-DHCP v.3 installed from ports. TIA, Pote ________________________________________________________________________ Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html From owner-freebsd-net@FreeBSD.ORG Sat Mar 20 17:35:35 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9BCAC16A4CE; Sat, 20 Mar 2004 17:35:35 -0800 (PST) Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4BABC43D3F; Sat, 20 Mar 2004 17:35:34 -0800 (PST) (envelope-from ken@panzer.kdm.org) Received: from panzer.kdm.org (localhost [127.0.0.1]) by panzer.kdm.org (8.12.9/8.12.5) with ESMTP id i2L1ZXLX037466; Sat, 20 Mar 2004 18:35:33 -0700 (MST) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.12.9/8.12.5/Submit) id i2L1ZXr8037465; Sat, 20 Mar 2004 18:35:33 -0700 (MST) (envelope-from ken) Date: Sat, 20 Mar 2004 18:35:33 -0700 From: "Kenneth D. Merry" To: freebsd-mobile@FreeBSD.org Message-ID: <20040321013533.GA37342@panzer.kdm.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="gKMricLos+KVdGMg" Content-Disposition: inline User-Agent: Mutt/1.4.1i cc: freebsd-net@FreeBSD.org Subject: WEP problems with ndis and ath drivers X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Mar 2004 01:35:35 -0000 --gKMricLos+KVdGMg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I have a Dell Inspiron 8500 laptop with an onboard TrueMobile 1300 (Broadcom, b/g chipset) and a Netgear WAG511 cardbus card (Atheros, a/b/g chipset). I have a Netgear FWAG114 firewall/access point. (Atheros based, does a, b and g.) I'm running FreeBSD-current from Friday, March 19th. Both cards talk to the access point under FreeBSD when I'm not running WEP, and neither card works with WEP enabled. (i.e., neither card will associate with the base station with WEP enabled.) I have tried putting the key in as both hex digits and as the passphrase I used on the router to generate the hex key. (The router claims it's a 128 bit key, but it only generates 26 hex digits, so it's really a 104 bit key I suppose.) Both cards work under Windows with WEP, with either the hex key or the passphrase entered. I have attached ifconfig and wicontrol output from both cards, and dmesg output from the laptop. To enable the adapter, I've been doing things like this: ifconfig {ath0|ndis0} ssid [my ssid] wepmode on wepkey `cat wepkey` (where wepkey is a file with the 26 digit hex key, starting with 0x) For what it's worth, I've tried setting the authmode to shared (instead of "open"), but all I get is the following: ifconfig ath0 authmode shared ifconfig: SIOCS80211: Invalid argument The ath driver spits out the following diagnostics when I try to associate with either the a or g part of the base station with WEP on: ath0: authentication failed (reason 13) for 00:09:5b:66:0d:f9 ath0: authentication failed (reason 13) for 00:09:5b:66:0d:f9 ath0: authentication failed (reason 13) for 00:09:5b:66:0d:f9 ath0: authentication failed (reason 13) for 00:09:5b:66:0d:f9 ath0: authentication failed (reason 13) for 00:09:5b:66:2c:5c ath0: authentication failed (reason 13) for 00:09:5b:66:2c:5c ath0: authentication failed (reason 13) for 00:09:5b:66:2c:5c ath0: authentication failed (reason 13) for 00:09:5b:66:2c:5c (The first mac address is the a base station, the second is the g base station.) The ndis driver (I'm using the Dell/Broadcom Windows drivers for the onboard chip) doesn't give any error messages, but doesn't associate either. If anyone has any clues on how to get this to work, I'd love to hear them. (Or if you have a similar setup and have managed to get it to work with WEP, that would be useful to know.) Thanks, Ken -- Kenneth Merry ken@kdm.org --gKMricLos+KVdGMg Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ath0.ifconfig" ath0: flags=8843 mtu 1500 ether 00:09:5b:68:27:df media: IEEE 802.11 Wireless Ethernet autoselect (OFDM/6Mbps) status: no carrier ssid [802.11a SSID] 1:[802.11a SSID] channel 36 authmode OPEN powersavemode OFF powersavesleep 100 wepmode MIXED weptxkey 1 wepkey 1:104-bit --gKMricLos+KVdGMg Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ath0.wicontrol" NIC serial number: [ ] Station name: [ erebor.kdm.org ] SSID for IBSS creation: [ 802.11a SSID ] Current netname (SSID): [ ] Desired netname (SSID): [ 802.11a SSID ] Current BSSID: [ 00:00:00:00:00:00 ] Channel list: [ ffe 0 1510 1515 1 0 0 0 0 2320 23 ] IBSS channel: [ 40 ] Current channel: [ 40 ] Comms quality/signal/noise: [ 0 29 0 ] Promiscuous mode: [ Off ] Intersil-Prism2 based card: [ 1 ] Port type (1=BSS, 3=ad-hoc): [ 1 ] MAC address: [ 00:09:5b:68:27:df ] TX rate (selection): [ 0 ] TX rate (actual speed): [ 6 ] RTS/CTS handshake threshold: [ 2312 ] Create IBSS: [ Off ] Access point density: [ 1 ] Power Mgmt (1=on, 0=off): [ 0 ] Max sleep time: [ 100 ] WEP encryption: [ On ] TX encryption key: [ 1 ] Encryption keys: [ 26 hex digit WEP key ][ ][ ][ ] --gKMricLos+KVdGMg Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ndis0.ifconfig" ndis0: flags=8843 mtu 1500 ether 00:90:4b:24:59:9c media: IEEE 802.11 Wireless Ethernet autoselect status: no carrier ssid "" channel 11 authmode OPEN powersavemode OFF powersavesleep 100 wepmode MIXED weptxkey 1 wepkey 1:104-bit wepkey 2:104-bit --gKMricLos+KVdGMg Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ndis0.wicontrol" NIC serial number: [ ] Station name: [ erebor.kdm.org ] SSID for IBSS creation: [ 802.11g SSID ] Current netname (SSID): [ ] Desired netname (SSID): [ 802.11g SSID ] Current BSSID: [ 00:00:00:00:00:00 ] Channel list: [ ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff 3fff ] IBSS channel: [ 11 ] Current channel: [ 11 ] Comms quality/signal/noise: [ 0 0 0 ] Promiscuous mode: [ Off ] Intersil-Prism2 based card: [ 1 ] Port type (1=BSS, 3=ad-hoc): [ 1 ] MAC address: [ 00:90:4b:24:59:9c ] TX rate (selection): [ 0 ] TX rate (actual speed): [ 0 ] RTS/CTS handshake threshold: [ 2312 ] Create IBSS: [ Off ] Access point density: [ 1 ] Power Mgmt (1=on, 0=off): [ 0 ] Max sleep time: [ 100 ] WEP encryption: [ On ] TX encryption key: [ 1 ] Encryption keys: [ 26 hex digit WEP key ][ WEP passphrase ][ ][ ] --gKMricLos+KVdGMg Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dmesg.ath_ndis.out" Copyright (c) 1992-2004 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.2-CURRENT #0: Fri Mar 19 20:38:10 MST 2004 ken@nargothrond.kdm.org:/usr/c/ken/perforce2/FreeBSD-ken/src/sys/i386/compile/erebor WARNING: WITNESS option enabled, expect reduced performance. Preloaded elf kernel "/boot/kernel/kernel" at 0xc0950000. Preloaded acpi_dsdt "/boot/acpi_dsdt.aml" at 0xc09501cc. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0950214. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Mobile Intel(R) Pentium(R) 4 - M CPU 2.50GHz (2492.65-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf27 Stepping = 7 Features=0xbfebf9ff real memory = 536535040 (511 MB) avail memory = 515301376 (491 MB) Pentium Pro MTRR support enabled ACPI: DSDT was overridden. ACPI-0374: *** Info: Table [DSDT] replaced by host OS cpu0 on motherboard npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard pcibios: BIOS version 2.10 Found $PIR table, 9 entries at 0xc00fc590 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_cpu0: port 0x530-0x537 on acpi0 acpi_tz0: port 0x530-0x537 on acpi0 acpi_acad0: on acpi0 acpi_cmbat0: on acpi0 acpi_cmbat1: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib0: slot 29 INTA is routed to irq 11 pcib0: slot 29 INTB is routed to irq 11 pcib0: slot 29 INTC is routed to irq 11 pcib0: slot 29 INTD is routed to irq 11 pcib0: slot 31 INTB is routed to irq 11 pcib0: slot 31 INTB is routed to irq 11 agp0: mem 0xec000000-0xefffffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pcib1: slot 0 INTA is routed to irq 11 pci1: at device 0.0 (no driver attached) uhci0: port 0xbf80-0xbf9f irq 11 at device 29.0 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xbf40-0xbf5f irq 11 at device 29.1 on pci0 usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xbf20-0xbf3f irq 11 at device 29.2 on pci0 usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered pci0: at device 29.7 (no driver attached) pcib2: at device 30.0 on pci0 pci2: on pcib2 pcib2: slot 1 INTA is routed to irq 11 pcib2: slot 3 INTA is routed to irq 11 cbb0: at device 1.0 on pci2 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 pcib2: slot 1 INTA is routed to irq 11 cbb0: [MPSAFE] fwohci0: vendor=104c, dev=8029 fwohci0: <1394 Open Host Controller Interface> mem 0xfaff8000-0xfaffbfff,0xfafff800-0xfaffffff irq 11 at device 1.1 on pci2 fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channel is 4. fwohci0: EUI64 38:4f:c0:00:08:9c:ec:41 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 3a:4f:c0:9c:ec:41 fwe0: Ethernet address: 3a:4f:c0:9c:ec:41 sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) pci2: at device 3.0 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xbfa0-0xbfaf,0x374-0x377,0x170-0x177,0x3f4-0x3f7,0x1f0-0x1f7 at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] ata1: at 0x170 irq 15 on atapci0 ata1: [MPSAFE] pcm0: port 0xbc40-0xbc7f,0xb800-0xb8ff mem 0xf4fff400-0xf4fff4ff,0xf4fff800-0xf4fff9ff irq 11 at device 31.5 on pci0 pcm0: pci0: at device 31.6 (no driver attached) atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model GlidePoint, device ID 0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A ppc0 port 0x778-0x77b,0x378-0x37f irq 7 drq 1 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 pmtimer0 on isa0 orm0: