From owner-freebsd-net@FreeBSD.ORG Sun Oct 24 14:50:09 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 B691016A4D1 for ; Sun, 24 Oct 2004 14:50:09 +0000 (GMT) Received: from mail.bsdmon.com (ALyon-203-1-4-30.w80-15.abo.wanadoo.fr [80.15.86.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id D93B543D45 for ; Sun, 24 Oct 2004 14:50:05 +0000 (GMT) (envelope-from hika@bsdmon.com) Received: from localhost (localhost [127.0.0.1]) by sdf1.macross.vfx (Postfix) with ESMTP id 43AE83F6B0 for ; Sun, 24 Oct 2004 16:47:58 +0200 (CEST) Received: from sdf1.macross.vfx ([127.0.0.1]) by localhost (sdf1.bsdmon.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00595-04 for ; Sun, 24 Oct 2004 16:47:55 +0200 (CEST) Received: by sdf1.macross.vfx (Postfix, from userid 1001) id E2AB03F848; Sun, 24 Oct 2004 16:47:54 +0200 (CEST) Date: Sun, 24 Oct 2004 16:47:54 +0200 From: Gilbert Cao To: freebsd-net@freebsd.org Message-ID: <20041024144754.GA1670@bsdmon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Operating-System: FreeBSD 5.3-RC1 i386 Organization: BSDMon User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new Subject: Kernel panic with pf 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, 24 Oct 2004 14:50:09 -0000 Hi everyone, I just experienced a kernel panic when I have execute a small program I just grab from apache2 configure script. I guess this program just check the TCP_NODELAY behaviour ... ------------------------------------------------------------------------------- Here is the following source code : #include #include #include #include #include /*typedef int socklen_t;*/ int main(void) { int listen_s, connected_s, client_s; int listen_port, rc; struct sockaddr_in sa; socklen_t sa_len; socklen_t option_len; int option; listen_s = socket(AF_INET, SOCK_STREAM, 0); if (listen_s < 0) { perror("socket"); exit(1); } option = 1; rc = setsockopt(listen_s, IPPROTO_TCP, TCP_NODELAY, &option, sizeof option); if (rc < 0) { perror("setsockopt TCP_NODELAY"); exit(1); } memset(&sa, 0, sizeof sa); sa.sin_family = AF_INET; #ifdef BEOS sa.sin_addr.s_addr = htonl(INADDR_LOOPBACK); #endif /* leave port 0 to get ephemeral */ rc = bind(listen_s, (struct sockaddr *)&sa, sizeof sa); if (rc < 0) { perror("bind for ephemeral port"); exit(1); } /* find ephemeral port */ sa_len = sizeof(sa); rc = getsockname(listen_s, (struct sockaddr *)&sa, &sa_len); if (rc < 0) { perror("getsockname"); exit(1); } listen_port = sa.sin_port; rc = listen(listen_s, 5); if (rc < 0) { perror("listen"); exit(1); } client_s = socket(AF_INET, SOCK_STREAM, 0); if (client_s < 0) { perror("socket"); exit(1); } memset(&sa, 0, sizeof sa); sa.sin_family = AF_INET; sa.sin_port = listen_port; #ifdef BEOS sa.sin_addr.s_addr = htonl(INADDR_LOOPBACK); #endif /* leave sin_addr all zeros to use loopback */ rc = connect(client_s, (struct sockaddr *)&sa, sizeof sa); if (rc < 0) { perror("connect"); exit(1); } sa_len = sizeof sa; connected_s = accept(listen_s, (struct sockaddr *)&sa, &sa_len); if (connected_s < 0) { perror("accept"); exit(1); } option_len = sizeof option; rc = getsockopt(connected_s, IPPROTO_TCP, TCP_NODELAY, &option, &option_len); if (rc < 0) { perror("getsockopt"); exit(1); } if (!option) { fprintf(stderr, "TCP_NODELAY is not set in the child.\n"); exit(1); } return 0; } ------------------------------------------------------------------------------- Here is my dmesg output : 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.3-RC1 #6: Sat Oct 23 11:47:59 CEST 2004 root@sdf1.bsdmon.com:/usr/obj/usr/src/sys/SDF1BSD ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) XP (1249.41-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x662 Stepping = 2 Features=0x383fbff AMD Features=0xc0400000 real memory = 536805376 (511 MB) avail memory = 511422464 (487 MB) MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-23 on motherboard npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 cpu0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0x6000-0x607f,0x5000-0x500f,0x4080-0x40ff,0x4000-0x407f,0xcf8-0xcff on acpi0 ACPI link \\_SB_.PCI0.LNKD has invalid initial irq 9, ignoring pci0: on pcib0 agp0: mem 0xe0000000-0xe3ffffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 nvidia0: mem 0xd0000000-0xdfffffff,0xe4000000-0xe4ffffff irq 16 at device 0.0 on pci1 nvidia0: [GIANT-LOCKED] isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xc000-0xc00f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 7.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 uhci0: port 0xc400-0xc41f irq 10 at device 7.2 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhid0: Logitech WingMan Precision USB, rev 1.10/1.03, addr 2, iclass 3/0 uhci1: port 0xc800-0xc81f irq 10 at device 7.3 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered pci0: at device 7.5 (no driver attached) rl0: port 0xdc00-0xdcff mem 0xe7000000-0xe70000ff irq 17 at device 8.0 on pci0 miibus0: on rl0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:50:fc:43:a7:8a trm0: port 0xe000-0xe0ff mem 0xe7001000-0xe7001fff irq 18 at device 9.0 on pci0 trm0: [GIANT-LOCKED] pcm0: port 0xe400-0xe41f irq 19 at device 10.0 on pci0 pcm0: fdc0: port 0x3f7,0x3f2-0x3f5 irq 6 drq 2 on acpi0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0: port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode ppbus0: on ppc0 ppi0: on ppbus0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse Explorer, device ID 4 orm0: at iomem 0xd0000-0xd7fff on isa0 pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 1249409092 Hz quality 800 Timecounters tick every 10.000 msec IP Filter: v3.4.35 initialized. Default = pass all, Logging = enabled ipfw2 initialized, divert enabled, rule-based forwarding enabled, default to accept, logging unlimited ad0: 38166MB [77545/16/63] at ata0-master UDMA100 ad1: 57241MB [116301/16/63] at ata0-slave UDMA100 acd0: DVDR at ata1-slave UDMA33 Waiting 15 seconds for SCSI devices to settle cd0 at trm0 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 20.000MB/s transfers (20.000MHz, offset 15) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed cd1 at ata1 bus 0 target 1 lun 0 cd1: Removable CD-ROM SCSI-0 device cd1: 33.000MB/s transfers cd1: Attempt to query device size failed: NOT READY, Medium not present Mounting root from ufs:/dev/ad0s1a WARNING: / was not properly dismounted WARNING: /usr was not properly dismounted /usr: mount pending error: blocks 12 files 4 NVRM: detected agp.ko, aborting NVIDIA AGP setup! NVRM: detected agp.ko, aborting NVIDIA AGP setup! ------------------------------------------------------------------------------- Here is my backtrace output : # kgdb /usr/obj/usr/src/sys/SDF1BSD/kernel.debug /usr/crash/vmcore.0 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". doadump () at pcpu.h:159 (kgdb) list 159 pcpu.h: No such file or directory. in pcpu.h (kgdb) where #0 doadump () at pcpu.h:159 #1 0xc065106b in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:397 #2 0xc06513c1 in panic (fmt=0xc082c23e "from debugger") at /usr/src/sys/kern/kern_shutdown.c:553 #3 0xc049cbd5 in db_panic (addr=-1069012735, have_addr=0, count=-1, modif=0xd55f18d4 "") at /usr/src/sys/ddb/db_command.c:435 #4 0xc049cb6c in db_command (last_cmdp=0xc0900244, cmd_table=0x0, aux_cmd_tablep=0xc087c2fc, aux_cmd_tablep_end=0xc087c318) at /usr/src/sys/ddb/db_command.c:349 #5 0xc049cc34 in db_command_loop () at /usr/src/sys/ddb/db_command.c:455 #6 0xc049e7ad in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:221 #7 0xc0668f53 in kdb_trap (type=12, code=0, tf=0x1) at /usr/src/sys/kern/subr_kdb.c:418 #8 0xc07f589d in trap_fatal (frame=0xd55f1a68, eva=296) at /usr/src/sys/i386/i386/trap.c:804 #9 0xc07f55fb in trap_pfault (frame=0xd55f1a68, usermode=0, eva=296) at /usr/src/sys/i386/i386/trap.c:727 #10 0xc07f51f1 in trap (frame= {tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -715187408, tf_esi = -715187412, tf_ebp = -715187500, tf_isp = -715187564, tf_ebx = -1038093076, tf_edx = -1042521712, tf_ecx = 16885952, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1069012735, tf_cs = 8, tf_eflags = 66050, tf_esp = -1673396224, tf_ss = -1040125440}) at /usr/src/sys/i386/i386/trap.c:417 #11 0xc07e307a in calltrap () at /usr/src/sys/i386/i386/exception.s:140 #12 0x00000018 in ?? () #13 0x00000010 in ?? () #14 0x00000010 in ?? () #15 0xd55f1b30 in ?? () #16 0xd55f1b2c in ?? () #17 0xd55f1ad4 in ?? () #18 0xd55f1a94 in ?? () #19 0xc21ff4ec in ?? () #20 0xc1dc6190 in ?? () #21 0x0101a8c0 in ?? () #22 0x00000000 in ?? () #23 0x0000000c in ?? () #24 0x00000000 in ?? () #25 0xc0482901 in pf_socket_lookup (uid=0xd55f1b2c, gid=0xd55f1b30, direction=1, pd=0x0, inp_arg=0x0) at /usr/src/sys/contrib/pf/net/pf.c:2509 #26 0xc0483199 in pf_test_tcp (rm=0xd55f1b98, sm=0x0, direction=1, kif=0xc202c800, m=0xc200f200, off=20, h=0xc200f240, pd=0xd55f1be8, am=0xd55f1b9c, rsm=0xd55f1ba0, inp=0x0) at /usr/src/sys/contrib/pf/net/pf.c:2778 #27 0xc048a0b7 in pf_test (dir=1, ifp=0xc1f19400, m0=0xd55f1c84, inp=0x0) at /usr/src/sys/contrib/pf/net/pf.c:5988 #28 0xc04931ad in pf_check_in (arg=0x0, m=0xd55f1c84, ifp=0xc1f19400, dir=1, inp=0x0) at /usr/src/sys/contrib/pf/net/pf_ioctl.c:3226 #29 0xc06c3603 in pfil_run_hooks (ph=0xc09265e0, mp=0xd55f1ccc, ifp=0xc1f19400, dir=1, inp=0x0) at /usr/src/sys/net/pfil.c:137 #30 0xc06dfae7 in ip_input (m=0xc200f200) at /usr/src/sys/netinet/ip_input.c:439 #31 0xc06c1ddf in netisr_processqueue (ni=0xc0925318) at /usr/src/sys/net/netisr.c:233 #32 0xc06c220a in swi_net (dummy=0x0) at /usr/src/sys/net/netisr.c:346 #33 0xc063c965 in ithread_loop (arg=0xc1d89c80) at /usr/src/sys/kern/kern_intr.c:547 #34 0xc063ba15 in fork_exit (callout=0xc063c80c , arg=0xc1d89c80, frame=0xd55f1d48) at /usr/src/sys/kern/kern_fork.c:811 #35 0xc07e30dc in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:209 (kgdb) ------------------------------------------------------------------------------- Here is my pf config : int_if="rl0" int_addr="192.168.1.1" int_net="192.168.1.0/24" wifi_net="192.168.0.0/24" restricted_users="{ 1001 >< 1004, 1004 >< 65354 }" # Options set optimization aggressive # Normalization des paquets scrub in all fragment reassemble block in log quick from any os "NMAP" to any block log quick proto { tcp, udp } all user $restricted_users # Règle sur la machine locale pass in quick on lo0 all pass out quick on lo0 all # On peut sortir sur l'extérieur, et accepter les retours pass out quick on $int_if proto tcp from $int_addr to any keep state pass out quick on $int_if proto udp from $int_addr to any pass out quick on $int_if proto icmp from $int_addr to any block in log quick from any to 127.0.0.0/8 block out log quick from any to 127.0.0.0/8 block in log quick from 127.0.0.0/8 to any block out log quick from 127.0.0.0/8 to any # On ouvre de l'extérieur vers les services internes pass in quick on $int_if proto tcp from any to $int_addr port { 21, 22, 25, 80, 210, 1113, 6671, 10080 } flags S/SA keep state pass in quick on $int_if proto tcp from any to $int_addr port 59999 >< 60101 flags S/SA keep state pass in quick on $int_if proto tcp from any to $int_addr port 5499 >< 5511 flags S/SA keep state pass in quick on $int_if proto tcp from any to $int_addr port 7880 >< 8000 flags S/SA keep state pass in quick on $int_if proto udp from any port { 53, 123 } to $int_addr pass in quick on $int_if proto icmp from any to $int_addr # On accepte les réponses au PING # pass in quick on $int_if proto icmp from any to $int_addr icmp-type # echorep # On fait confiance aux réseaux locales pass in quick on $int_if proto tcp from $int_net to $int_addr flags S/SA keep state pass in quick on $int_if proto udp from $int_net to $int_addr pass in quick on $int_if proto udp from $int_net to $int_net pass in quick on $int_if proto tcp from $wifi_net to $int_addr flags S/SA keep state pass in quick on $int_if proto udp from $wifi_net to $int_addr pass in quick on $int_if proto udp from $wifi_net to $int_net # On bloque tout et on logge sinon block log all --------------------------------- ** IMPORTANT NOTE : When I remove the following line from my pf.conf : block log quick proto { tcp, udp } all user $restricted_users The kernel does not panic ! Thanks in advance. Gilbert Cao. From owner-freebsd-net@FreeBSD.ORG Sun Oct 24 15:22:50 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 EE2A316A4CF for ; Sun, 24 Oct 2004 15:22:49 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2358243D2F for ; Sun, 24 Oct 2004 15:22:49 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.208] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1CLkCk-0001nj-00; Sun, 24 Oct 2004 17:22:46 +0200 Received: from [84.128.128.40] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1CLkCk-0003IC-00; Sun, 24 Oct 2004 17:22:46 +0200 From: Max Laier To: freebsd-net@freebsd.org Date: Sun, 24 Oct 2004 17:22:27 +0200 User-Agent: KMail/1.7 References: <20041024144754.GA1670@bsdmon.com> In-Reply-To: <20041024144754.GA1670@bsdmon.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1427486.4sISMGO8RB"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200410241722.34910.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 cc: Gilbert Cao Subject: Re: Kernel panic with pf 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, 24 Oct 2004 15:22:50 -0000 --nextPart1427486.4sISMGO8RB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 24 October 2004 16:47, Gilbert Cao wrote: > Hi everyone, > > I just experienced a kernel panic when I have execute > a small program I just grab from apache2 configure script. > I guess this program just check the TCP_NODELAY behaviour ... > --------------------------------- > ** IMPORTANT NOTE : > When I remove the following line from my pf.conf : > block log quick proto { tcp, udp } all user $restricted_users > > The kernel does not panic ! Are you running with debug.mpsafenet=3D0? In order to use user/group rule=20 modificators you have to run with debug.mpsafenet=3D0 as there is a problem= =20 with locks. This is mentioned in the BUGS section of pf.conf(5). Please tel= l=20 me if the problem is persistent with debug.mpsafenet turned off. Thanks. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1427486.4sISMGO8RB Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBe8i6XyyEoT62BG0RAomlAJ9/nhWOAvAcWwc02iBSeSK9hfbgIwCeNW8Y JncI48n06lpiC/gE8bHuIew= =+3gX -----END PGP SIGNATURE----- --nextPart1427486.4sISMGO8RB-- From owner-freebsd-net@FreeBSD.ORG Sun Oct 24 16:04: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 EC91516A4CF for ; Sun, 24 Oct 2004 16:04:07 +0000 (GMT) Received: from mail.bsdmon.com (ALyon-203-1-4-30.w80-15.abo.wanadoo.fr [80.15.86.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB9A043D2D for ; Sun, 24 Oct 2004 16:04:06 +0000 (GMT) (envelope-from hika@bsdmon.com) Received: from localhost (localhost [127.0.0.1]) by sdf1.macross.vfx (Postfix) with ESMTP id 4F5CD3F735; Sun, 24 Oct 2004 18:02:39 +0200 (CEST) Received: from sdf1.macross.vfx ([127.0.0.1]) by localhost (sdf1.bsdmon.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00586-02; Sun, 24 Oct 2004 18:02:36 +0200 (CEST) Received: by sdf1.macross.vfx (Postfix, from userid 1001) id 1B6EC3F75A; Sun, 24 Oct 2004 18:02:35 +0200 (CEST) Date: Sun, 24 Oct 2004 18:02:35 +0200 From: Gilbert Cao To: Max Laier Message-ID: <20041024160235.GA1016@bsdmon.com> References: <20041024144754.GA1670@bsdmon.com> <200410241722.34910.max@love2party.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200410241722.34910.max@love2party.net> X-Operating-System: FreeBSD 5.3-RC1 i386 Organization: BSDMon User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new cc: freebsd-net@freebsd.org Subject: Re: Kernel panic with pf 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, 24 Oct 2004 16:04:08 -0000 On Sun, Oct 24, 2004 at 05:22:27PM +0200, Max Laier wrote: > > Are you running with debug.mpsafenet=0? In order to use user/group rule > modificators you have to run with debug.mpsafenet=0 as there is a problem > with locks. This is mentioned in the BUGS section of pf.conf(5). Please tell > me if the problem is persistent with debug.mpsafenet turned off. > > Thanks. > I have debug.mpsafenet=1 when my kernel panics, but I just have the same problem with debug.mpsafenet=0 in /boot/loader.conf ... Regards. Gilbert Cao. From owner-freebsd-net@FreeBSD.ORG Sun Oct 24 16:48: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 B8FBE16A4CE for ; Sun, 24 Oct 2004 16:48:48 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D5DF43D2F for ; Sun, 24 Oct 2004 16:48:48 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.208] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1CLlXx-0007bS-00; Sun, 24 Oct 2004 18:48:46 +0200 Received: from [84.128.128.40] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1CLlXx-0004gP-00; Sun, 24 Oct 2004 18:48:46 +0200 From: Max Laier To: Gilbert Cao Date: Sun, 24 Oct 2004 18:48:28 +0200 User-Agent: KMail/1.7 References: <20041024144754.GA1670@bsdmon.com> <200410241722.34910.max@love2party.net> <20041024160235.GA1016@bsdmon.com> In-Reply-To: <20041024160235.GA1016@bsdmon.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6540196.794D3IZyG3"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200410241848.35446.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 cc: freebsd-net@freebsd.org Subject: Re: Kernel panic with pf 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, 24 Oct 2004 16:48:48 -0000 --nextPart6540196.794D3IZyG3 Content-Type: multipart/mixed; boundary="Boundary-01=_ez9eB3CzEWHq24F" Content-Transfer-Encoding: 7bit Content-Disposition: inline --Boundary-01=_ez9eB3CzEWHq24F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 24 October 2004 18:02, Gilbert Cao wrote: > On Sun, Oct 24, 2004 at 05:22:27PM +0200, Max Laier wrote: > > Are you running with debug.mpsafenet=3D0? In order to use user/group ru= le > > modificators you have to run with debug.mpsafenet=3D0 as there is a pro= blem > > with locks. This is mentioned in the BUGS section of pf.conf(5). Please > > tell me if the problem is persistent with debug.mpsafenet turned off. > > > > Thanks. > > I have debug.mpsafenet=3D1 when my kernel panics, > but I just have the same problem with debug.mpsafenet=3D0 in > /boot/loader.conf ... Hmmm ... that's bad. Can you please test the attached patch. It is a wild=20 guess as I am currently not able to test. Please tell me if it helps. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --Boundary-01=_ez9eB3CzEWHq24F Content-Type: text/x-diff; charset="iso-8859-1"; name="pf.c.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="pf.c.diff" Index: pf.c =================================================================== RCS file: /usr/store/mlaier/fcvs/src/sys/contrib/pf/net/pf.c,v retrieving revision 1.18.2.2 diff -u -r1.18.2.2 pf.c --- pf.c 3 Oct 2004 17:04:39 -0000 1.18.2.2 +++ pf.c 24 Oct 2004 16:45:33 -0000 @@ -2506,6 +2506,11 @@ } #ifdef __FreeBSD__ INP_LOCK(inp); + if ((inp->inp_socket == NULL) || (inp->inp_socket->so_cred == NULL)) { + INP_UNLOCK(inp); + INP_INFO_RUNLOCK(pi); + return (0); + } *uid = inp->inp_socket->so_cred->cr_uid; *gid = inp->inp_socket->so_cred->cr_groups[0]; INP_UNLOCK(inp); --Boundary-01=_ez9eB3CzEWHq24F-- --nextPart6540196.794D3IZyG3 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBe9zjXyyEoT62BG0RAns+AJ9g6kemq3w1u1YUlDBlPc6y+TxsvgCePdR+ o7yI7P1a/Tht8RW1Bp5eHF0= =/4LZ -----END PGP SIGNATURE----- --nextPart6540196.794D3IZyG3-- From owner-freebsd-net@FreeBSD.ORG Sun Oct 24 19:14:15 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 4925016A4CE for ; Sun, 24 Oct 2004 19:14:15 +0000 (GMT) Received: from mail.bsdmon.com (ALyon-203-1-3-117.w80-14.abo.wanadoo.fr [80.14.178.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA1C943D1D for ; Sun, 24 Oct 2004 19:14:11 +0000 (GMT) (envelope-from hika@bsdmon.com) Received: from localhost (localhost [127.0.0.1]) by sdf1.macross.vfx (Postfix) with ESMTP id 01F613F85A; Sun, 24 Oct 2004 21:14:08 +0200 (CEST) Received: from mail.bsdmon.com ([127.0.0.1]) by localhost (sdf1.bsdmon.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00581-02; Sun, 24 Oct 2004 21:14:07 +0200 (CEST) Received: by sdf1.macross.vfx (Postfix, from userid 1001) id 03ED23F862; Sun, 24 Oct 2004 21:14:06 +0200 (CEST) Date: Sun, 24 Oct 2004 21:14:06 +0200 From: Gilbert Cao To: Max Laier Message-ID: <20041024191406.GA1022@bsdmon.com> References: <20041024144754.GA1670@bsdmon.com> <200410241722.34910.max@love2party.net> <20041024160235.GA1016@bsdmon.com> <200410241848.35446.max@love2party.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200410241848.35446.max@love2party.net> X-Operating-System: FreeBSD 5.3-RC1 i386 Organization: BSDMon User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new cc: freebsd-net@freebsd.org Subject: Re: Kernel panic with pf 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, 24 Oct 2004 19:14:15 -0000 On Sun, Oct 24, 2004 at 06:48:28PM +0200, Max Laier wrote: > > Hmmm ... that's bad. Can you please test the attached patch. It is a wild > guess as I am currently not able to test. Please tell me if it helps. > > -- > /"\ Best regards, | mlaier@freebsd.org > \ / Max Laier | ICQ #67774661 > X http://pf4freebsd.love2party.net/ | mlaier@EFnet > / \ ASCII Ribbon Campaign | Against HTML Mail and News > Index: pf.c > =================================================================== > RCS file: /usr/store/mlaier/fcvs/src/sys/contrib/pf/net/pf.c,v > retrieving revision 1.18.2.2 > diff -u -r1.18.2.2 pf.c > --- pf.c 3 Oct 2004 17:04:39 -0000 1.18.2.2 > +++ pf.c 24 Oct 2004 16:45:33 -0000 > @@ -2506,6 +2506,11 @@ > } > #ifdef __FreeBSD__ > INP_LOCK(inp); > + if ((inp->inp_socket == NULL) || (inp->inp_socket->so_cred == NULL)) { > + INP_UNLOCK(inp); > + INP_INFO_RUNLOCK(pi); > + return (0); > + } > *uid = inp->inp_socket->so_cred->cr_uid; > *gid = inp->inp_socket->so_cred->cr_groups[0]; > INP_UNLOCK(inp); Thanks. That works, no panic. Should I also test with debug.mpsafenet=0, or is it useless ? Gilbert Cao. From owner-freebsd-net@FreeBSD.ORG Sun Oct 24 19:28:26 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 86D6616A4CE for ; Sun, 24 Oct 2004 19:28:26 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id BFCA043D2D for ; Sun, 24 Oct 2004 19:28:25 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.209] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1CLo2S-0002eG-00; Sun, 24 Oct 2004 21:28:24 +0200 Received: from [84.128.128.40] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1CLo2R-0001x4-00; Sun, 24 Oct 2004 21:28:24 +0200 From: Max Laier To: freebsd-net@freebsd.org Date: Sun, 24 Oct 2004 21:27:46 +0200 User-Agent: KMail/1.7 References: <20041024144754.GA1670@bsdmon.com> <200410241848.35446.max@love2party.net> <20041024191406.GA1022@bsdmon.com> In-Reply-To: <20041024191406.GA1022@bsdmon.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1194873.PyyCbIgSAv"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200410242127.53782.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 cc: Gilbert Cao Subject: Re: Kernel panic with pf 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, 24 Oct 2004 19:28:26 -0000 --nextPart1194873.PyyCbIgSAv Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 24 October 2004 21:14, Gilbert Cao wrote: > On Sun, Oct 24, 2004 at 06:48:28PM +0200, Max Laier wrote: > > Hmmm ... that's bad. Can you please test the attached patch. It is a wi= ld > > guess as I am currently not able to test. Please tell me if it helps. > > > > -- > > /"\ Best regards, | mlaier@freebsd.org > > \ / Max Laier | ICQ #67774661 > > X http://pf4freebsd.love2party.net/ | mlaier@EFnet > > / \ ASCII Ribbon Campaign | Against HTML Mail and News > > > > Index: pf.c > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > RCS file: /usr/store/mlaier/fcvs/src/sys/contrib/pf/net/pf.c,v > > retrieving revision 1.18.2.2 > > diff -u -r1.18.2.2 pf.c > > --- pf.c 3 Oct 2004 17:04:39 -0000 1.18.2.2 > > +++ pf.c 24 Oct 2004 16:45:33 -0000 > > @@ -2506,6 +2506,11 @@ > > } > > #ifdef __FreeBSD__ > > INP_LOCK(inp); > > + if ((inp->inp_socket =3D=3D NULL) || (inp->inp_socket->so_cred =3D=3D= NULL)) { > > + INP_UNLOCK(inp); > > + INP_INFO_RUNLOCK(pi); > > + return (0); > > + } > > *uid =3D inp->inp_socket->so_cred->cr_uid; > > *gid =3D inp->inp_socket->so_cred->cr_groups[0]; > > INP_UNLOCK(inp); > > Thanks. > That works, no panic. Thanks. Going to commit it. > Should I also test with debug.mpsafenet=3D0, or is it useless ? You should not use user/group rules in a debug.mpsafenet=3D1 environment. I= t=20 will cause hard lockups and the like. The fix for these lockups is non-=20 trivial and will take some more time. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1194873.PyyCbIgSAv Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBfAI5XyyEoT62BG0RAhRfAJ0WQ8tz4TByMP+KPYfU2eoRasnbQwCfYeE1 4l3LT9IlIUWztHdEH2bXW5s= =9U7p -----END PGP SIGNATURE----- --nextPart1194873.PyyCbIgSAv-- From owner-freebsd-net@FreeBSD.ORG Mon Oct 25 00:22: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 D165116A4CF for ; Mon, 25 Oct 2004 00:22:31 +0000 (GMT) Received: from grummit.biaix.org (86.Red-213-97-212.pooles.rima-tde.net [213.97.212.86]) by mx1.FreeBSD.org (Postfix) with SMTP id 22CF243D5C for ; Mon, 25 Oct 2004 00:22:28 +0000 (GMT) (envelope-from lists-freebsd-questions@biaix.org) Received: (qmail 36834 invoked by uid 1000); 25 Oct 2004 00:20:08 -0000 Date: Mon, 25 Oct 2004 02:20:08 +0200 From: Joan Picanyol To: freebsd-stable@freebsd.org Message-ID: <20041025002008.GA36161@grummit.biaix.org> Mail-Followup-To: freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i cc: freebsd-fs@freebsd.org cc: freebsd-net@freebsd.org Subject: process stuck in nfsfsync state 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, 25 Oct 2004 00:22:32 -0000 [please honour Mail-Followup-To:, no need to keep the crosspost] This is a repost of http://docs.FreeBSD.org/cgi/mid.cgi?20041014110752.GA57541, with some additional information. I've updated the client to RC1, and the problem still persists. In short, a 5.3-RC1 client mounting /home off a 4.10-p3 server can't use the NFS fs anymore when trying to start GNOME, since gconfd and gnome-session are in nfsfsync state. Any process accessing the fs hungs, and the console gets full of nfs server grummit:/fs/home/mount: not responding messages, even though the client can still ping the server and other mount points are still available. AFAICT, nfsd and friends are running both on the client and the server, and the client can use RPC properly (checked via rpcinfo). Also, doing 'tcpdump -vv -s 192 port nfs' on the client and the server seems support the hypothesis of a locking issue, since I see a write request for the same fh repeating over and over. The trace of gnome-session is as follows: db> tr 610 sched_switch(c180b4b0,0,1,11d,27b8ea4) at sched_switch+0x190 mi_switch(1,0,c063d701,19d,2) at mi_switch+0x2ac sleepq_switch(c216d23c,c0639f0f,18e,2,da518a5c) at sleepq_switch+0x134 sleepq_wait(c216d23c,0,c063b2f5,db,0) at sleepq_wait+0x41 msleep(c216d23c,c216d210,4d,c1906703,0) at msleep+0x3b5 nfs_flush(c216d210,c17fed00,1,c180b4b0,0) at nfs_flush+0x961 nfs_close(da518b8c,1,c0643a5e,140,c0681da0) at nfs_close+0x7e vn_close(c216d210,2,c17fed00,c180b4b0,c0692c20) at vn_close+0x67 vn_closefile(c1c2b6e8,c180b4b0,c0637a98,829,c1c2b6e8) at vn_closefile+0xc4 fdrop_locked(c1c2b6e8,c180b4b0,c0637a98,768) at fdrop_locked+0xb4 fdrop(c1c2b6e8,c180b4b0,3,c180b4b0,da518c98) at fdrop+0x3c closef(c1c2b6e8,c180b4b0,c0637a98,3e3,0) at closef+0x21c close(c180b4b0,da518d14,4,431,1) at close+0x135 syscall(2f,2f,2f,0,28d38ec0) at syscall+0x272 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (6, FreeBSD ELF32, close), eip = 0x28ca1e6f, esp = 0xbfbfe52c, ebp = 0xbfbfe538 --- I have a debugging kernel and a console attached, feel free to ask for any other information of interest. This is driving me nuts, and I'm surely not the only one using GNOME over NFS, is anyone else seeing this? What exactly is going on? How can I fix it? It might be that the problem appeared going from BETA3 to BETA6, but I've been unable to "downgrade" the workstation; where can I get a copy of BETA3 to test this? tks -- pica From owner-freebsd-net@FreeBSD.ORG Mon Oct 25 01:15: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 36C3416A4CE for ; Mon, 25 Oct 2004 01:15:54 +0000 (GMT) Received: from note.orchestra.cse.unsw.EDU.AU (note.orchestra.cse.unsw.EDU.AU [129.94.242.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A6E743D39 for ; Mon, 25 Oct 2004 01:15:53 +0000 (GMT) (envelope-from lukem@cse.unsw.edu.au) Received: From wagner With LocalMail ; Mon, 25 Oct 2004 11:15:51 +1000 From: lukem.freebsd@cse.unsw.edu.au Sender: lukem@cse.unsw.edu.au To: freebsd-net@freebsd.org Date: Mon, 25 Oct 2004 11:15:51 +1000 (EST) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Underutilisation of CPU --- am I PCI bus bandwidth limited? 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, 25 Oct 2004 01:15:54 -0000 I posted this to freebsd-performance, but have as yet not satisfactorily answered the question. Since it is primarily network related, I'm reposting it here. I have been doing some benchmarking as a part of some driver development work, and have encountered a phenomenon I can't explain. I am using FreeBSD 5.2.1-RELEASE with SMP and IO-APIC disabled. I am using a dual 2.8GHz xeon box, but only one CPU without hyperthreading. The box in question has three em interfaces, and one fxp. Two of the em's are 133Mhz/64bit, and one is 33MHz/32bit. I have verified these values by modifying the em driver to print out what it detects. em0: MAC type:82546 r3 Bus speed:133MHz Bus width:64bit Bus type:PCI-X em1: MAC type:82546 r3 Bus speed:133MHz Bus width:64bit Bus type:PCI-X em2: MAC type:82540 Bus speed:33MHz Bus width:32bit Bus type:PCI The particular benchmark I have been using is a UDP echo test, where I have a number of linux boxes sending UDP packets to a freebsd box, which the freebsd box echoes at user-level (think inetd udp echo, though in fact I have also used an optimised server which gets higher throughput). Throughput is measured on the boxes which generate the UDP packets. I am measuring idle time using a CPU soaker process which runs at a very low priority. Top seems to confirm the output it gives. What I see is strange. CPU utilisation always peaks (and stays) at between 80 & 85%. If I increase the amount of work done by the UDP echo program (by inserting additional packet copies), CPU utilisation does not rise, but rather, throughput declines. The 80% figure is common to both the slow and fast PCI cards as well. This is rather confusing, as I cannot tell if the system is IO bound or CPU bound. Certainly I would not have expected the 133/64 PCI bus to be saturated given that peak throughput is around 550Mbit/s with 1024-byte packets. (Such a low figure is not unexpected given there are 2 syscalls per packet). no additional packet copies: (echoed) (applied) (CPU%) 499.5Mbps 500.0Mbps 76.2 549.0Mbps 550.0Mbps 80.4 562.2Mbps 600,0Mbps 81.9 32 additional packet copies: (echoed) (applied) (CPU%) 297.8Mbps 500.0Mbps 81.1 298.6Mbps 550.0Mbps 81.8 297.1Mbps 600.0Mbps 82.4 I have only included data around the MLFRR. If anyone has any insight into what might cause this behaviour, please let me know, as it has me stumped. -- Luke From owner-freebsd-net@FreeBSD.ORG Mon Oct 25 04:50: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 B143616A4CE for ; Mon, 25 Oct 2004 04:50:04 +0000 (GMT) Received: from pimout1-ext.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6875843D39 for ; Mon, 25 Oct 2004 04:50:04 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [192.168.1.102] (adsl-68-123-122-146.dsl.snfc21.pacbell.net [68.123.122.146])i9P4o2WC212824; Mon, 25 Oct 2004 00:50:03 -0400 Message-ID: <417C85FA.5050708@elischer.org> Date: Sun, 24 Oct 2004 21:50:02 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8a3) Gecko/20041017 X-Accept-Language: en, hu MIME-Version: 1.0 To: Stephane Raimbault References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: net@freebsd.org Subject: Re: using natd to load balance port 80 to multiple servers 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, 25 Oct 2004 04:50:04 -0000 Stephane Raimbault wrote: > Hi All, > > I'm currently using a freebsd box running natd to forward port 80 to > several (5) web servers on private IP's. > > I have discovered that natd doesn't handle many requests/second all that > well (seem to choke at about 200 req/second (educated guess)) > use the "ipfw fwd" option to directly send the packets to the appropriate machine. Should be able to forwarrd at wire speed. you will probably need ipfw fwd running on both sides of the forward.. one on the switch machine to forward packets to one machine and one on that machine to "capture" those packets to a local socket. > There are other packet filtering options on FreeBSD and I wonder if I > can use them to do what I'm trying to do with natd. > > Would someone be able to point me to documentation or help me have > either ipf/ipfw/pf forward port 80 traffic to private space IP's? > From owner-freebsd-net@FreeBSD.ORG Mon Oct 25 05:35: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 4E89816A4CE for ; Mon, 25 Oct 2004 05:35:45 +0000 (GMT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 375E643D67 for ; Mon, 25 Oct 2004 05:35:45 +0000 (GMT) (envelope-from billf@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1098) id 1F9EB5CA33; Sun, 24 Oct 2004 22:35:45 -0700 (PDT) Date: Sun, 24 Oct 2004 22:35:45 -0700 From: Bill Fumerola To: Julian Elischer Message-ID: <20041025053545.GJ67216@elvis.mu.org> References: <417C85FA.5050708@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <417C85FA.5050708@elischer.org> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 4.10-MUORG-20040525 i386 X-PGP-Key: 1024D/7F868268 X-PGP-Fingerprint: 5B2D 908E 4C2B F253 DAEB FC01 8436 B70B 7F86 8268 cc: Stephane Raimbault cc: net@freebsd.org Subject: Re: using natd to load balance port 80 to multiple servers 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, 25 Oct 2004 05:35:45 -0000 On Sun, Oct 24, 2004 at 09:50:02PM -0700, Julian Elischer wrote: > Stephane Raimbault wrote: > >I'm currently using a freebsd box running natd to forward port 80 to > >several (5) web servers on private IP's. > > > >I have discovered that natd doesn't handle many requests/second all that > >well (seem to choke at about 200 req/second (educated guess)) > > use the "ipfw fwd" option to directly send the packets to the appropriate > machine. > Should be able to forwarrd at wire speed. doesn't work for any configuration involving more than one backend machine. through what magic does ipfw determine "the appropriate machine"? it has to be consistent throughout each tcp connection.. the only way to do this entirely in ipfw (that i can think of) would be to do something horrible like this: frontend# ifconfig fxp0 VIRTUAL netmask 255.255.255.255 -alias backends# ifconfig lo0 VIRTUAL netmask 255.255.255.255 -alias frontend# ipfw add 100 fwd backend1 tcp from 0.0.0.0/2 to VIRTUAL 80 frontend# ipfw add 200 fwd backend2 tcp from 64.0.0.0/2 to VIRTUAL 80 frontend# ipfw add 300 fwd backend3 tcp from 128.0.0.0/2 to VIRTUAL 80 frontend# ipfw add 400 fwd backend4 tcp from 192.0.0.0/2 to VIRTUAL 80 which is essentially one of the world's worst load balancing algorithms. i suppose basing it on src ports would be even worse. you could use non-contigous masks too for "better" distribution than cutting the space into 1/N chunks. anyways, it needs to be something that per-packet always maps a tcp connection to the same backend server. we could do something neat and marry ipfw dynamic rules with 'ipfw fwd' by adding a nexthop field to the ipfw_dyn_rule, rule op codes to feed and lookup from the table, add a least conns selection method, add a round robin method, add the ability to point to a table of machines (possibly allow marking a machine as 'no new connections') for picking nexthops. that would bring us up to the basic hardware vendor implementations available circa 1999. -- - bill fumerola / billf@FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Mon Oct 25 05:43:30 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 300FB16A4CE; Mon, 25 Oct 2004 05:43:30 +0000 (GMT) Received: from pimout1-ext.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9CD3C43D1F; Mon, 25 Oct 2004 05:43:29 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [192.168.1.102] (adsl-68-123-122-146.dsl.snfc21.pacbell.net [68.123.122.146])i9P5hQWC320160; Mon, 25 Oct 2004 01:43:27 -0400 Message-ID: <417C927B.8050304@elischer.org> Date: Sun, 24 Oct 2004 22:43:23 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8a3) Gecko/20041017 X-Accept-Language: en, hu MIME-Version: 1.0 To: Bill Fumerola References: <417C85FA.5050708@elischer.org> <20041025053545.GJ67216@elvis.mu.org> In-Reply-To: <20041025053545.GJ67216@elvis.mu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: Stephane Raimbault cc: net@FreeBSD.org Subject: Re: using natd to load balance port 80 to multiple servers 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, 25 Oct 2004 05:43:30 -0000 Bill Fumerola wrote: > On Sun, Oct 24, 2004 at 09:50:02PM -0700, Julian Elischer wrote: > >>Stephane Raimbault wrote: >> >>>I'm currently using a freebsd box running natd to forward port 80 to >>>several (5) web servers on private IP's. >>> >>>I have discovered that natd doesn't handle many requests/second all that >>>well (seem to choke at about 200 req/second (educated guess)) >> >>use the "ipfw fwd" option to directly send the packets to the appropriate >>machine. >>Should be able to forwarrd at wire speed. > > > doesn't work for any configuration involving more than one backend > machine. through what magic does ipfw determine "the appropriate machine"? > it has to be consistent throughout each tcp connection.. > > the only way to do this entirely in ipfw (that i can think of) would be > to do something horrible like this: > > frontend# ifconfig fxp0 VIRTUAL netmask 255.255.255.255 -alias > backends# ifconfig lo0 VIRTUAL netmask 255.255.255.255 -alias > frontend# ipfw add 100 fwd backend1 tcp from 0.0.0.0/2 to VIRTUAL 80 > frontend# ipfw add 200 fwd backend2 tcp from 64.0.0.0/2 to VIRTUAL 80 > frontend# ipfw add 300 fwd backend3 tcp from 128.0.0.0/2 to VIRTUAL 80 > frontend# ipfw add 400 fwd backend4 tcp from 192.0.0.0/2 to VIRTUAL 80 I have used noncontiguous masks and based if on purely the lowest 2 bits of the 3rd octet. worked quite well as a "quick and nasty" load balancer. certainly equal to using natd for the same thing with less work. > > which is essentially one of the world's worst load balancing algorithms. > i suppose basing it on src ports would be even worse. you could use > non-contigous masks too for "better" distribution than cutting the space > into 1/N chunks. anyways, it needs to be something that per-packet always > maps a tcp connection to the same backend server. as I said above... > > we could do something neat and marry ipfw dynamic rules with 'ipfw fwd' > by adding a nexthop field to the ipfw_dyn_rule, rule op codes to feed > and lookup from the table, add a least conns selection method, add a > round robin method, add the ability to point to a table of machines > (possibly allow marking a machine as 'no new connections') for picking > nexthops. that would bring us up to the basic hardware vendor > implementations available circa 1999. yep.. > From owner-freebsd-net@FreeBSD.ORG Mon Oct 25 11:02:09 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 42AF016A4E7 for ; Mon, 25 Oct 2004 11:02:09 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3867343D48 for ; Mon, 25 Oct 2004 11:02:09 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.11/8.12.11) with ESMTP id i9PB29kr078289 for ; Mon, 25 Oct 2004 11:02:09 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i9PB26Hm078282 for freebsd-net@freebsd.org; Mon, 25 Oct 2004 11:02:06 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 25 Oct 2004 11:02:06 GMT Message-Id: <200410251102.i9PB26Hm078282@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, 25 Oct 2004 11:02:09 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2002/07/26] kern/41007 net overfull traffic on third and fourth adap o [2003/10/14] kern/57985 net [patch] Missing splx in ether_output_fram 2 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2001/02/08] kern/24959 net proper TCP_NOPUSH/TCP_CORK compatibility o [2003/07/11] kern/54383 net [nfs] [patch] NFS root configurations wit 2 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Oct 25 12:03:26 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 89FD516A4CF for ; Mon, 25 Oct 2004 12:03:26 +0000 (GMT) Received: from mail.bsdmon.com (ALyon-203-1-3-117.w80-14.abo.wanadoo.fr [80.14.178.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 61E7C43D48 for ; Mon, 25 Oct 2004 12:03:25 +0000 (GMT) (envelope-from hika@bsdmon.com) Received: from localhost (localhost [127.0.0.1]) by sdf1.macross.vfx (Postfix) with ESMTP id 3733B3F7FA; Mon, 25 Oct 2004 14:03:23 +0200 (CEST) Received: from mail.bsdmon.com ([127.0.0.1]) by localhost (sdf1.bsdmon.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00579-02; Mon, 25 Oct 2004 14:03:21 +0200 (CEST) Received: by sdf1.macross.vfx (Postfix, from userid 1001) id 608E63F848; Mon, 25 Oct 2004 14:03:21 +0200 (CEST) Date: Mon, 25 Oct 2004 14:03:21 +0200 From: Gilbert Cao To: Max Laier Message-ID: <20041025120321.GA3425@bsdmon.com> References: <20041024144754.GA1670@bsdmon.com> <200410241848.35446.max@love2party.net> <20041024191406.GA1022@bsdmon.com> <200410242127.53782.max@love2party.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200410242127.53782.max@love2party.net> X-Operating-System: FreeBSD 5.3-RC1 i386 Organization: BSDMon User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new cc: freebsd-net@freebsd.org Subject: Re: Kernel panic with pf 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, 25 Oct 2004 12:03:26 -0000 On Sun, Oct 24, 2004 at 09:27:46PM +0200, Max Laier wrote: > Thanks. Going to commit it. > > > Should I also test with debug.mpsafenet=0, or is it useless ? > > You should not use user/group rules in a debug.mpsafenet=1 environment. It > will cause hard lockups and the like. The fix for these lockups is non- > trivial and will take some more time. Yeah, I mean debug.mpsafenet=1 ... sorry for anyone who have misunderstand what I said about testing with debug.mpsafenet=0 ... > > -- > /"\ Best regards, | mlaier@freebsd.org > \ / Max Laier | ICQ #67774661 > X http://pf4freebsd.love2party.net/ | mlaier@EFnet > / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-net@FreeBSD.ORG Mon Oct 25 12:21: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 E7BB216A4CE for ; Mon, 25 Oct 2004 12:21:16 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id 80AAE43D3F for ; Mon, 25 Oct 2004 12:21:16 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.205] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1CM3qc-0005nU-00; Mon, 25 Oct 2004 14:21:14 +0200 Received: from [217.83.15.163] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1CM3qc-0007oa-00; Mon, 25 Oct 2004 14:21:14 +0200 From: Max Laier To: freebsd-net@freebsd.org Date: Mon, 25 Oct 2004 14:20:44 +0200 User-Agent: KMail/1.7 References: <20041024144754.GA1670@bsdmon.com> <200410242127.53782.max@love2party.net> <20041025120321.GA3425@bsdmon.com> In-Reply-To: <20041025120321.GA3425@bsdmon.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1633228.Z4P7gAXhVn"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200410251421.05186.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 cc: Gilbert Cao Subject: Re: Kernel panic with pf 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, 25 Oct 2004 12:21:17 -0000 --nextPart1633228.Z4P7gAXhVn Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 25 October 2004 14:03, Gilbert Cao wrote: > On Sun, Oct 24, 2004 at 09:27:46PM +0200, Max Laier wrote: > > Thanks. Going to commit it. > > > > > Should I also test with debug.mpsafenet=3D0, or is it useless ? > > > > You should not use user/group rules in a debug.mpsafenet=3D1 environmen= t. > > It will cause hard lockups and the like. The fix for these lockups is > > non- trivial and will take some more time. > > Yeah, I mean debug.mpsafenet=3D1 ... sorry for anyone who have > misunderstand what I said about testing with debug.mpsafenet=3D0 ... Oh nevermind! Thank you a lot for your report and testing. I was just tryin= g=20 to make this point clear. I am very unhappy with the situation, but I can't= =20 help it and hence try to educate users to not fall into that trap. Thanks again. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1633228.Z4P7gAXhVn Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBfO+xXyyEoT62BG0RAgaoAJ9lV5LhSFjOe7J78QZ0Emj3CeajrACggfUG DwbWAzhFM5NL0Mtsyw8ugWo= =1Df9 -----END PGP SIGNATURE----- --nextPart1633228.Z4P7gAXhVn-- From owner-freebsd-net@FreeBSD.ORG Mon Oct 25 13:05: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 4A89A16A4CE; Mon, 25 Oct 2004 13:05:53 +0000 (GMT) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2457C43D49; Mon, 25 Oct 2004 13:05:53 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) i9PD4aa2035437; Mon, 25 Oct 2004 06:04:37 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (pc1.oakwoodazabu1-unet.ocn.ne.jp [220.110.140.201]) by mail.meer.net (8.12.10/8.12.2/meer) with ESMTP id i9PD4X0E006877; Mon, 25 Oct 2004 06:04:34 -0700 (PDT) (envelope-from gnn@neville-neil.com) Date: Mon, 25 Oct 2004 22:04:32 +0900 Message-ID: From: gnn@freebsd.org To: rwatson@freebsd.org User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.5 Emacs/21.2 (powerpc-apple-darwin) MULE/5.0 (SAKAKI) 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: kame Subject: Updated scope6.c locking patch... 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, 25 Oct 2004 13:05:53 -0000 Hi Folks, Enclosed please find my updated patch for scope6 locking for the IPv6 code in FreeBSD-CURRENT. The major change was to remove the IFNET list locking because this actually needs to be done outside of the IPv6 code and to add address family (AF) data locking because that's something we can and should do within the scope6 code. I have tested this locally in the following way: 1) Open a shell on the machine (shell1) and do: shell1> ifconfig lo1 create shell1> while 1 shell1> scope6config -l 1 -s 2 -o 3 lo1 shell1> end 2) Open a second shell on the same machine (shell2) and do: shell2> ifconfig lo1 destroy shell2> ifconfig lo1 create etc. The messages in the shell1 window should switch between: lo1: 0, 6, 1, 0, 0, 2, 0, 0, 3, 0, 0, 0, 0, 0, 0, 0 and scope6config: ioctl(SIOCSSCOPE6): Device not configured and the kernel should not panic ;-) Later, George --- sys/netinet6/scope6.c.orig +++ sys/netinet6/scope6.c @@ -71,7 +71,6 @@ scope6_ifattach(ifp) struct ifnet *ifp; { - int s = splnet(); struct scope6_id *sid; sid = (struct scope6_id *)malloc(sizeof(*sid), M_IFADDR, M_WAITOK); @@ -89,7 +88,6 @@ sid->s6id_list[IPV6_ADDR_SCOPE_ORGLOCAL] = 1; #endif - splx(s); return sid; } @@ -106,12 +104,17 @@ struct ifnet *ifp; struct scope6_id *idlist; { - int i, s; + int i; int error = 0; - struct scope6_id *sid = SID(ifp); + struct scope6_id *sid = NULL; + + IF_AFDATA_LOCK(ifp); + sid = SID(ifp); - if (!sid) /* paranoid? */ + if (!sid) { /* paranoid? */ + IF_AFDATA_UNLOCK(ifp); return (EINVAL); + } /* * XXX: We need more consistency checks of the relationship among @@ -123,8 +126,6 @@ * interface addresses, routing table entries, PCB entries... */ - s = splnet(); - SCOPE6_LOCK(); for (i = 0; i < 16; i++) { if (idlist->s6id_list[i] && @@ -135,7 +136,8 @@ */ if (i == IPV6_ADDR_SCOPE_INTFACELOCAL && idlist->s6id_list[i] != ifp->if_index) { - splx(s); + IF_AFDATA_UNLOCK(ifp); + SCOPE6_UNLOCK(); return (EINVAL); } @@ -147,7 +149,8 @@ * IDs, but we check the consistency for * safety in later use. */ - splx(s); + IF_AFDATA_UNLOCK(ifp); + SCOPE6_UNLOCK(); return (EINVAL); } @@ -160,7 +163,7 @@ } } SCOPE6_UNLOCK(); - splx(s); + IF_AFDATA_UNLOCK(ifp); return (error); } @@ -170,15 +173,20 @@ struct ifnet *ifp; struct scope6_id *idlist; { + /* We only need to lock the interface's afdata for SID() to work. */ + IF_AFDATA_LOCK(ifp); struct scope6_id *sid = SID(ifp); - if (sid == NULL) /* paranoid? */ + if (sid == NULL) { /* paranoid? */ + IF_AFDATA_UNLOCK(ifp); return (EINVAL); + } SCOPE6_LOCK(); *idlist = *sid; SCOPE6_UNLOCK(); + IF_AFDATA_UNLOCK(ifp); return (0); } @@ -259,7 +267,11 @@ { int scope; u_int32_t zoneid = 0; - struct scope6_id *sid = SID(ifp); + struct scope6_id *sid = NULL; + + IF_AFDATA_LOCK(ifp); + + sid = SID(ifp); #ifdef DIAGNOSTIC if (sid == NULL) { /* should not happen */ @@ -277,10 +289,12 @@ * interface. */ if (IN6_IS_ADDR_LOOPBACK(addr)) { - if (!(ifp->if_flags & IFF_LOOPBACK)) + if (!(ifp->if_flags & IFF_LOOPBACK)) { + IF_AFDATA_UNLOCK(ifp); return (-1); - else { + } else { *ret_id = 0; /* there's no ambiguity */ + IF_AFDATA_UNLOCK(ifp); return (0); } } @@ -315,6 +329,9 @@ SCOPE6_UNLOCK(); *ret_id = zoneid; + + IF_AFDATA_UNLOCK(ifp); + return (0); } @@ -323,7 +340,7 @@ struct ifnet *ifp; /* note that this might be NULL */ { /* - * Currently, this function just set the default "interfaces" + * Currently, this function just sets the default "interfaces" * and "links" according to the given interface. * We might eventually have to separate the notion of "link" from * "interface" and provide a user interface to set the default. From owner-freebsd-net@FreeBSD.ORG Mon Oct 25 13:37:26 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 C408D16A4CE for ; Mon, 25 Oct 2004 13:37:26 +0000 (GMT) Received: from exchange.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 573A243D54 for ; Mon, 25 Oct 2004 13:37:26 +0000 (GMT) (envelope-from don@sandvine.com) X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Oct 2004 09:37:25 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Underutilisation of CPU --- am I PCI bus bandwidth limited? Thread-Index: AcS6MEOg7GvNpXSNRF+ty+EHWjEBuwAZ3jKA From: "Don Bowman" To: , Subject: RE: Underutilisation of CPU --- am I PCI bus bandwidth limited? 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, 25 Oct 2004 13:37:26 -0000 From: lukem.freebsd@cse.unsw.edu.au >=20 ... >=20 > This is rather confusing, as I cannot tell if the system is=20 > IO bound or CPU=20 > bound. Certainly I would not have expected the 133/64 PCI bus=20 > to be saturated=20 > given that peak throughput is around 550Mbit/s with 1024-byte=20 > packets. (Such a=20 > low figure is not unexpected given there are 2 syscalls per packet). You may find you have not loaned the em driver enough buffers, (max_rxd, max_txd). you may find you want to use device polling, poll on idle, and play with the polling parameters. In this config i have achieved ~2Gbps of throughput with these large packets, so i know it can be done. From owner-freebsd-net@FreeBSD.ORG Mon Oct 25 13:44: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 38B2C16A4CE for ; Mon, 25 Oct 2004 13:44:04 +0000 (GMT) Received: from ox.eicat.ca (ox.eicat.ca [66.96.30.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id C939343D45 for ; Mon, 25 Oct 2004 13:44:03 +0000 (GMT) (envelope-from dgilbert@daveg.ca) Received: by ox.eicat.ca (Postfix, from userid 66) id D5032C936; Mon, 25 Oct 2004 09:43:59 -0400 (EDT) Received: by canoe.dclg.ca (Postfix, from userid 101) id 983C21D1DB9; Mon, 25 Oct 2004 09:43:47 -0400 (EDT) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16765.787.356237.161540@canoe.dclg.ca> Date: Mon, 25 Oct 2004 09:43:47 -0400 To: lukem.freebsd@cse.unsw.edu.au In-Reply-To: References: X-Mailer: VM 7.17 under 21.5 (beta17) "chayote" (+CVS-20040321) XEmacs Lucid cc: freebsd-net@freebsd.org Subject: Underutilisation of CPU --- am I PCI bus bandwidth limited? 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, 25 Oct 2004 13:44:04 -0000 >>>>> "lukem" == lukem freebsd writes: lukem> I posted this to freebsd-performance, but have as yet not lukem> satisfactorily answered the question. Since it is primarily lukem> network related, I'm reposting it here. lukem> The particular benchmark I have been using is a UDP echo test, lukem> where I have a number of linux boxes sending UDP packets to a lukem> freebsd box, which the freebsd box echoes at user-level (think lukem> inetd udp echo, though in fact I have also used an optimised lukem> server which gets higher throughput). Throughput is measured on lukem> the boxes which generate the UDP packets. lukem> I am measuring idle time using a CPU soaker process which runs lukem> at a very low priority. Top seems to confirm the output it lukem> gives. lukem> What I see is strange. CPU utilisation always peaks (and stays) lukem> at between 80 & 85%. If I increase the amount of work done by lukem> the UDP echo program (by inserting additional packet copies), lukem> CPU utilisation does not rise, but rather, throughput lukem> declines. The 80% figure is common to both the slow and fast lukem> PCI cards as well. lukem> This is rather confusing, as I cannot tell if the system is IO lukem> bound or CPU bound. Certainly I would not have expected the lukem> 133/64 PCI bus to be saturated given that peak throughput is lukem> around 550Mbit/s with 1024-byte packets. (Such a low figure is lukem> not unexpected given there are 2 syscalls per packet). lukem> no additional packet copies: (echoed) (applied) (CPU%) lukem> 499.5Mbps 500.0Mbps 76.2 549.0Mbps 550.0Mbps 80.4 562.2Mbps lukem> 600,0Mbps 81.9 lukem> 32 additional packet copies: (echoed) (applied) (CPU%) lukem> 297.8Mbps 500.0Mbps 81.1 298.6Mbps 550.0Mbps 81.8 297.1Mbps lukem> 600.0Mbps 82.4 lukem> I have only included data around the MLFRR. lukem> If anyone has any insight into what might cause this behaviour, lukem> please let me know, as it has me stumped. -- Luke Well... you're going to get a lot more packets through (likely) if you turn on polling, but keep in mind that your low priority "soaker" process will no longer be accurate. Seeing bytes/packets decline and cpu stay the same is the same failure mode that I've observed in my packet passing testing. Dave. -- ============================================================================ |David Gilbert, Independent Contractor. | Two things can only be | |Mail: dave@daveg.ca | equal if and only if they | |http://daveg.ca | are precisely opposite. | =========================================================GLO================ From owner-freebsd-net@FreeBSD.ORG Mon Oct 25 16:13: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 795A616A4CE for ; Mon, 25 Oct 2004 16:13:19 +0000 (GMT) Received: from mail.otel.net (gw3.OTEL.net [212.36.8.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA41043D1F for ; Mon, 25 Oct 2004 16:13:16 +0000 (GMT) (envelope-from tbyte@OTEL.net) Received: from dragon.otel.net ([212.36.8.135]) by mail.otel.net with esmtp (Exim 4.30; FreeBSD) id 1CM7T8-000Dqt-09 for freebsd-net@freebsd.org; Mon, 25 Oct 2004 19:13:14 +0300 Message-ID: <417D25E2.1080309@OTEL.net> Date: Mon, 25 Oct 2004 19:12:18 +0300 From: Iasen Kostov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.1) Gecko/20040728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: arp_rtrequest() panich & patch for comments 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, 25 Oct 2004 16:13:19 -0000 The problem is that there is a route in zebra's conf like this "ip route 192.168.100.0/24 tun0" and when zebra first starts there is still not tun0. In the moment of setting up the tun0 interface (creating or associating IP) it looks like zebra tries to add this route which until this moment is inactive. And then *POOF* kernel panic in arp_rtrequest() at 180. This is the segment of code: if ((rt->rt_flags & RTF_HOST) == 0 && SIN(rt_mask(rt))->sin_addr.s_addr != 0xffffffff) rt->rt_flags |= RTF_CLONING; I saw that rtrequest1() does checks for rt_mask(rt) != NULL, so why arp_rtrequest() does not ? Then I've changed it like this: if ((rt->rt_flags & RTF_HOST) == 0 && + rt_mask(rt) != NULL && SIN(rt_mask(rt))->sin_addr.s_addr != 0xffffffff) rt->rt_flags |= RTF_CLONING; and the panic disappeared but this is what the kernel complains in that case : arp_rtrequest: bad gateway 192.168.100.0 (!AF_LINK) and adds a nice route like this: 192.168.100 0.0.0.0 U1 0 0 vlan5 There is vlan5 and route : 192.168.96/20 link#6 UC 0 0 vlan5 so it clones it or ... I don't really know what's happening :) but possibly is not right. And if the interface tun0 exists everything is as it should be: 192.168.100 tun0 U1 0 0 tun0 but whatever is the case - user space program should not be able to panic the kernel so easy ... I don't know where really the bug is - in arp_rtrequest() or somewhere in the pipe that at the end calls arp_rtrequest(). Regards. From owner-freebsd-net@FreeBSD.ORG Mon Oct 25 16:17: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 3C01716A4CE for ; Mon, 25 Oct 2004 16:17:47 +0000 (GMT) Received: from mail.otel.net (gw3.OTEL.net [212.36.8.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id DCA8E43D46 for ; Mon, 25 Oct 2004 16:17:46 +0000 (GMT) (envelope-from tbyte@OTEL.net) Received: from dragon.otel.net ([212.36.8.135]) by mail.otel.net with esmtp (Exim 4.30; FreeBSD) id 1CM7XT-000E9i-FK for freebsd-net@freebsd.org; Mon, 25 Oct 2004 19:17:43 +0300 Message-ID: <417D26F0.5060406@OTEL.net> Date: Mon, 25 Oct 2004 19:16:48 +0300 From: Iasen Kostov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.1) Gecko/20040728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <417D25E2.1080309@OTEL.net> In-Reply-To: <417D25E2.1080309@OTEL.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: arp_rtrequest() panich & patch for comments 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, 25 Oct 2004 16:17:47 -0000 Iasen Kostov wrote: > The problem is that there is a route in zebra's conf like this "ip > route 192.168.100.0/24 tun0" and when zebra first starts there is > still not tun0. In the moment of setting up the tun0 interface > (creating or associating IP) it looks like zebra tries to add this > route which until this moment is inactive. And then *POOF* kernel > panic in arp_rtrequest() at 180. > This is the segment of code: > > if ((rt->rt_flags & RTF_HOST) == 0 && > SIN(rt_mask(rt))->sin_addr.s_addr != 0xffffffff) > rt->rt_flags |= RTF_CLONING; > > I saw that rtrequest1() does checks for rt_mask(rt) != NULL, so why > arp_rtrequest() does not ? > Then I've changed it like this: > > > if ((rt->rt_flags & RTF_HOST) == 0 && > + rt_mask(rt) != NULL && > SIN(rt_mask(rt))->sin_addr.s_addr != 0xffffffff) > rt->rt_flags |= RTF_CLONING; > > and the panic disappeared but this is what the kernel complains in > that case : > > arp_rtrequest: bad gateway 192.168.100.0 (!AF_LINK) > > and adds a nice route like this: > > 192.168.100 0.0.0.0 U1 0 0 vlan5 > > There is vlan5 and route : > > 192.168.96/20 link#6 UC 0 0 vlan5 > > so it clones it or ... I don't really know what's happening :) but > possibly is not right. And if the interface tun0 exists > everything is as it should be: > > 192.168.100 tun0 U1 0 0 tun0 > > but whatever is the case - user space program should not be able to > panic the kernel so easy ... > I don't know where really the bug is - in arp_rtrequest() or somewhere > in the pipe that at the end calls arp_rtrequest(). > > Regards. > > _______________________________________________ > 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" > I forgot. This is "FreeBSD DraGoN.OTEL.net 5.3-STABLE FreeBSD 5.3-STABLE #15: Thu Jan 17 21:22:51 EET 2002 root@LANGW4.OTEL.net:/usr/src/sys/i386/compile/DRAGON i386" sorry fo that :( Regards From owner-freebsd-net@FreeBSD.ORG Mon Oct 25 16:19:50 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 29EDE16A4CE for ; Mon, 25 Oct 2004 16:19:50 +0000 (GMT) Received: from shellma.zin.lublin.pl (shellma.zin.lublin.pl [212.182.126.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id A354A43D2D for ; Mon, 25 Oct 2004 16:19:49 +0000 (GMT) (envelope-from pawmal-posting@freebsd.lublin.pl) Received: by shellma.zin.lublin.pl (Postfix, from userid 1018) id 571FC347BA8; Mon, 25 Oct 2004 18:18:25 +0200 (CEST) Date: Mon, 25 Oct 2004 18:18:25 +0200 From: Pawel Malachowski To: Iasen Kostov Message-ID: <20041025161825.GA33749@shellma.zin.lublin.pl> References: <417D25E2.1080309@OTEL.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <417D25E2.1080309@OTEL.net> User-Agent: Mutt/1.4.2i cc: freebsd-net@freebsd.org Subject: Re: arp_rtrequest() panich & patch for comments X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd-net@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2004 16:19:50 -0000 On Mon, Oct 25, 2004 at 07:12:18PM +0300, Iasen Kostov wrote: > This is the segment of code: > > if ((rt->rt_flags & RTF_HOST) == 0 && > SIN(rt_mask(rt))->sin_addr.s_addr != 0xffffffff) > rt->rt_flags |= RTF_CLONING; BTW, http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/42030 -- Pawe³ Ma³achowski From owner-freebsd-net@FreeBSD.ORG Mon Oct 25 16: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 237CD16A4CE for ; Mon, 25 Oct 2004 16:21:47 +0000 (GMT) Received: from mail.otel.net (gw3.OTEL.net [212.36.8.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id A25EA43D2F for ; Mon, 25 Oct 2004 16:21:46 +0000 (GMT) (envelope-from tbyte@OTEL.net) Received: from dragon.otel.net ([212.36.8.135]) by mail.otel.net with esmtp (Exim 4.30; FreeBSD) id 1CM7bM-000EIi-LZ for freebsd-net@freebsd.org; Mon, 25 Oct 2004 19:21:44 +0300 Message-ID: <417D27E1.10709@OTEL.net> Date: Mon, 25 Oct 2004 19:20:49 +0300 From: Iasen Kostov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.1) Gecko/20040728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <417D25E2.1080309@OTEL.net> <417D26F0.5060406@OTEL.net> In-Reply-To: <417D26F0.5060406@OTEL.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: arp_rtrequest() panich & patch for comments 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, 25 Oct 2004 16:21:47 -0000 Iasen Kostov wrote: > Iasen Kostov wrote: > >> The problem is that there is a route in zebra's conf like this "ip >> route 192.168.100.0/24 tun0" and when zebra first starts there is >> still not tun0. In the moment of setting up the tun0 interface >> (creating or associating IP) it looks like zebra tries to add this >> route which until this moment is inactive. And then *POOF* kernel >> panic in arp_rtrequest() at 180. >> This is the segment of code: >> >> if ((rt->rt_flags & RTF_HOST) == 0 && >> SIN(rt_mask(rt))->sin_addr.s_addr != 0xffffffff) >> rt->rt_flags |= RTF_CLONING; >> >> I saw that rtrequest1() does checks for rt_mask(rt) != NULL, so why >> arp_rtrequest() does not ? >> Then I've changed it like this: >> >> >> if ((rt->rt_flags & RTF_HOST) == 0 && >> + rt_mask(rt) != NULL && >> SIN(rt_mask(rt))->sin_addr.s_addr != 0xffffffff) >> rt->rt_flags |= RTF_CLONING; >> >> and the panic disappeared but this is what the kernel complains in >> that case : >> >> arp_rtrequest: bad gateway 192.168.100.0 (!AF_LINK) >> >> and adds a nice route like this: >> >> 192.168.100 0.0.0.0 U1 0 0 vlan5 >> >> There is vlan5 and route : >> >> 192.168.96/20 link#6 UC 0 0 vlan5 >> >> so it clones it or ... I don't really know what's happening :) but >> possibly is not right. And if the interface tun0 exists >> everything is as it should be: >> >> 192.168.100 tun0 U1 0 0 tun0 >> >> but whatever is the case - user space program should not be able to >> panic the kernel so easy ... >> I don't know where really the bug is - in arp_rtrequest() or >> somewhere in the pipe that at the end calls arp_rtrequest(). >> >> Regards. >> >> _______________________________________________ >> 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" >> > I forgot. This is "FreeBSD DraGoN.OTEL.net 5.3-STABLE FreeBSD > 5.3-STABLE #15: Thu Jan 17 21:22:51 EET 2002 > root@LANGW4.OTEL.net:/usr/src/sys/i386/compile/DRAGON i386" > sorry fo that :( I'll shot myself ... Real date is "Thu Oct 21 2004" (cvsup date) > Regards > > _______________________________________________ > 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 Mon Oct 25 16:27: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 57A2516A4CE for ; Mon, 25 Oct 2004 16:27:04 +0000 (GMT) Received: from mail.otel.net (gw3.OTEL.net [212.36.8.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE34A43D49 for ; Mon, 25 Oct 2004 16:27:02 +0000 (GMT) (envelope-from tbyte@OTEL.net) Received: from dragon.otel.net ([212.36.8.135]) by mail.otel.net with esmtp (Exim 4.30; FreeBSD) id 1CM7gT-000EXf-Ba for freebsd-net@freebsd.org; Mon, 25 Oct 2004 19:27:01 +0300 Message-ID: <417D291E.4060102@OTEL.net> Date: Mon, 25 Oct 2004 19:26:06 +0300 From: Iasen Kostov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.1) Gecko/20040728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <417D25E2.1080309@OTEL.net> <20041025161825.GA33749@shellma.zin.lublin.pl> In-Reply-To: <20041025161825.GA33749@shellma.zin.lublin.pl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: arp_rtrequest() panich & patch for comments 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, 25 Oct 2004 16:27:04 -0000 Pawel Malachowski wrote: >On Mon, Oct 25, 2004 at 07:12:18PM +0300, Iasen Kostov wrote: > > > >>This is the segment of code: >> >> if ((rt->rt_flags & RTF_HOST) == 0 && >> SIN(rt_mask(rt))->sin_addr.s_addr != 0xffffffff) >> rt->rt_flags |= RTF_CLONING; >> >> > >BTW, http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/42030 > > > > It's looks the same thing ... I think the creation of virtual devices like tap or tun should be anounced a bit later Same is for destruction may be but little earlier following the logic. From owner-freebsd-net@FreeBSD.ORG Tue Oct 26 01:56: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 C405416A4CE for ; Tue, 26 Oct 2004 01:56:22 +0000 (GMT) Received: from note.orchestra.cse.unsw.EDU.AU (note.orchestra.cse.unsw.EDU.AU [129.94.242.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C28843D46 for ; Tue, 26 Oct 2004 01:56:22 +0000 (GMT) (envelope-from lukem@cse.unsw.edu.au) Received: From wagner With LocalMail ; Tue, 26 Oct 2004 11:56:20 +1000 From: lukem.freebsd@cse.unsw.edu.au Sender: lukem@cse.unsw.edu.au To: freebsd-net@freebsd.org Date: Tue, 26 Oct 2004 11:56:20 +1000 (EST) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: poor performance of nge interface 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, 26 Oct 2004 01:56:22 -0000 I notice that there are some poorly defined default values: dev/nge/if_nge.c: CSR_WRITE_4(sc, NGE_IHR, 0x01); dev/nge/if_nge_reg.h: #define NGE_RX_LIST_CNT 128 #define NGE_TX_LIST_CNT 128 net/if.h: #define IFQ_MAXLEN 50 netinet/ip_input.c: static int ipqmaxlen = IFQ_MAXLEN; ipintrq.ifq_maxlen = ipqmaxlen; This results in default behaviour under load that when the device interrupts with a full rx queue, packets are dequeued from the receive ring and are promptly dropped on the floor when they hit the IP queue. With the default interrupt holdoff time of 100us, we could expect a maximum of 128/0.0001 = 128kpps, which is probably a bit low for small packet sizes. -- Luke From owner-freebsd-net@FreeBSD.ORG Tue Oct 26 03:28: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 4BE7616A4CF for ; Tue, 26 Oct 2004 03:28:04 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 655E143D58 for ; Tue, 26 Oct 2004 03:28:03 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 5B4A065218; Tue, 26 Oct 2004 04:28:01 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 47817-02; Tue, 26 Oct 2004 04:28:00 +0100 (BST) Received: from empiric.dek.spc.org (dhcp120.icir.org [192.150.187.120]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 0C91C651FC; Tue, 26 Oct 2004 04:28:00 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 7107D61CB; Mon, 25 Oct 2004 20:27:47 -0700 (PDT) Date: Mon, 25 Oct 2004 20:27:47 -0700 From: Bruce M Simpson To: Iasen Kostov Message-ID: <20041026032747.GH706@empiric.icir.org> Mail-Followup-To: Iasen Kostov , freebsd-net@freebsd.org References: <417D25E2.1080309@OTEL.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3siQDZowHQqNOShm" Content-Disposition: inline In-Reply-To: <417D25E2.1080309@OTEL.net> cc: freebsd-net@freebsd.org Subject: Re: arp_rtrequest() panich & patch for comments 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, 26 Oct 2004 03:28:04 -0000 --3siQDZowHQqNOShm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, Can you please contact me off-list with more information about your Zebra configuration? On Mon, Oct 25, 2004 at 07:12:18PM +0300, Iasen Kostov wrote: > if ((rt->rt_flags & RTF_HOST) =3D=3D 0 && > + rt_mask(rt) !=3D NULL && > SIN(rt_mask(rt))->sin_addr.s_addr !=3D 0xffffffff) > rt->rt_flags |=3D RTF_CLONING; Good catch. This can and should be committed; it's a common sense null pointer check. > arp_rtrequest: bad gateway 192.168.100.0 (!AF_LINK) > 192.168.100 0.0.0.0 U1 0 0 vlan5 > 192.168.96/20 link#6 UC 0 0 vlan5 192.168.100.0/24 is a subnet of 192.168.96/20. Was the /20 there before? The 1 flag is set in the case of the 192.168.100.0 route, so it is being added by Quagga/Zebra somehow, and doesn't have the WASCLONED flag set. Also, the LLINFO flag is not set. There's clearly an interaction going on here between a more specific non-cloning network route and a more general cloning network route. > possibly is not right. And if the interface tun0 exists > everything is as it should be: >=20 > 192.168.100 tun0 U1 0 0 tun0 This is the correct line that I'd expect for an interface route to a network, which has the PROTO1 flag set, and is not static, and has no link-layer information (is not an ARP entry). Zebra is trying to add the route when the interface doesn't exist. So the RTF_GATEWAY flag should be cleared (as per route(8)) and a sockaddr_dl containing *the name of the interface* should be sent in the rtmsg. From the looks of the Zebra code, it does this. However you should run route(8) in monitor mode and watch the routing socket to be absolutely sure. > but whatever is the case - user space program should not be able to=20 > panic the kernel so easy ... > I don't know where really the bug is - in arp_rtrequest() or somewhere=20 > in the pipe that at the end calls arp_rtrequest(). Trying to walk through the code, I don't see RTF_ANNOUNCE being set anywhere in the kernel so that part in arp_rtrequest() can probably be skipped. Back in userland, the quagga/zebra call graph looks like this: rt_socket.c:kernel_add_ipv4() rt_socket.c:kernel_rtm_ipv4(RTM_ADD, p, rib, AF_INET); rtm_write(...) Not knowing more about your Zebra config it's difficult to do more. It is more than likely that Zebra is passing the wrong interface index to its rtm_write() function and this results in the inconsistency you see. BMS --3siQDZowHQqNOShm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Comment: '' iD8DBQFBfcQyueUpAYYNtTsRAqILAJ9pbA/n7qqYxJXfGP/+ffLtdySEWgCeNbq6 rH16nnA/DIKy3GRZn2YoFWo= =Levw -----END PGP SIGNATURE----- --3siQDZowHQqNOShm-- From owner-freebsd-net@FreeBSD.ORG Tue Oct 26 03:41: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 39A5B16A4CE; Tue, 26 Oct 2004 03:41:37 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id E830843D3F; Tue, 26 Oct 2004 03:41:36 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 007F1651FA; Tue, 26 Oct 2004 04:41:36 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 47817-04-2; Tue, 26 Oct 2004 04:41:35 +0100 (BST) Received: from empiric.dek.spc.org (dhcp120.icir.org [192.150.187.120]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 4A858651EB; Tue, 26 Oct 2004 04:41:35 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 3229961CB; Mon, 25 Oct 2004 20:41:26 -0700 (PDT) Date: Mon, 25 Oct 2004 20:41:26 -0700 From: Bruce M Simpson To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Message-ID: <20041026034126.GI706@empiric.icir.org> Mail-Followup-To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org, freebsd-net@FreeBSD.org References: <200410260331.i9Q3Vxbv060994@repoman.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200410260331.i9Q3Vxbv060994@repoman.freebsd.org> cc: freebsd-net@FreeBSD.org Subject: Re: cvs commit: src/sys/netinet if_ether.c 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, 26 Oct 2004 03:41:37 -0000 On Tue, Oct 26, 2004 at 03:31:59AM +0000, Bruce M Simpson wrote: > Log: > Check that rt_mask(rt) is non-NULL before dereferencing it, in the > RTM_ADD case, thus avoiding a panic. PR: kern/42030 It isn't immediately clear to me if this is a routing socket API issue or a client issue. The panic, at least, is worked around, but the root problem needs to be fixed -- it is most likely a synchronization problem in zebra whereby it is attempting to add a route to the kernel FIB which references an interface which does not yet exist or has gone away. At least one person who has reported this was running vtund, which plumbs its own tun instances on demand; the other I think was running userland ppp. I haven't seen anything similar with XORP yet. BMS From owner-freebsd-net@FreeBSD.ORG Tue Oct 26 05:19:05 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 A26E716A4CE; Tue, 26 Oct 2004 05:19:05 +0000 (GMT) Received: from v6.hitachi.co.jp (galilei.v6.hitachi.co.jp [133.145.167.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3EC4843D39; Tue, 26 Oct 2004 05:19:04 +0000 (GMT) (envelope-from suz@crl.hitachi.co.jp) Received: from flora210w.uki-uki.net (localhost [IPv6:::1]) by v6.hitachi.co.jp (8.12.11/8.12.11) with ESMTP id i9Q5J1Oc046258; Tue, 26 Oct 2004 14:19:02 +0900 (JST) (envelope-from suz@crl.hitachi.co.jp) Date: Tue, 26 Oct 2004 14:19:02 +0900 Message-ID: From: SUZUKI Shinsuke To: peter.lei@ieee.org X-cite: xcite 1.33 In-Reply-To: <4179ACB8.4020108@ieee.org> References: <4177C8AD.6060706@freebsd.org> <20041021153933.GK13756@empiric.icir.org> <4177E25E.804639E@freebsd.org> <20041021213248.223cab2c.molter@tin.it> <4179ACB8.4020108@ieee.org> User-Agent: Wanderlust/2.11.32 (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.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII cc: freebsd-net@freebsd.org cc: andre@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: SCTP in KAME / Re: Removing T/TCP and replacing it withsomething simpler 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, 26 Oct 2004 05:19:05 -0000 >>>>> On Fri, 22 Oct 2004 19:58:32 -0500 >>>>> peter.lei@ieee.org(Peter Lei) said: > While the SCTP API hasn't gone through last call, it's fairly > stable and we have both "converted" many applications from TCP > to SCTP using the sockets API, as well as had portability between > the KAME SCTP stack and the linux stack for some test applications > used at the last interop event (except for the standard sockets > issues that one runs into even for TCP like no sin_length field > in the sockaddr struct). > I'm not aware of any KAME SNAP compilation failures w/and w/o SCTP. > The major changes to our SCTP code when it gets committed into KAME > has been that of code format/style. What I found was the following two issues. Although these two are technically quite trivial, what I was fearing was a lack of report to KAME, since this may mean a lack of KAME-SCTP users. - inconsistency between KAME specific kernel code and SCTP leads to an kernel compilation error. Of course, it's a technically trivial bug and our own bug. - including SCTP in getaddrinfo() causes 'configure' script error in many ports applications. This is also a trivial problem, and maybe specific to KAME SCTP. And some of such ports are already fixed when I encounter this problem. (e.g. http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/python/files/patch-configure.diff?r1=1.7&r2=1.8) But now I understand that lack of report does not mean a lack of testing users (since SCTP-lovers seems communicating directly to your team). So I can be much more optimistic now, and don't object to merging it into -current, since such trivial bugs can be fixed easily in -current. (I myself haven't tested SCTP very well, so I cannot comment on its stability itself. But at least, SCTP does not seem to affect the behavior of other protocols) Thanks and sorry if you feel my previous comments were insulting... ---- SUZUKI, Shinsuke @ KAME Project From owner-freebsd-net@FreeBSD.ORG Tue Oct 26 10:42: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 BD64B16A4CE; Tue, 26 Oct 2004 10:42:02 +0000 (GMT) Received: from stewart.chicago.il.us (dpc674425142.direcpc.com [67.44.25.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3606D43D3F; Tue, 26 Oct 2004 10:42:00 +0000 (GMT) (envelope-from randall@stewart.chicago.il.us) Received: from stewart.chicago.il.us (localhost [127.0.0.1]) i9QAfaT8007280; Tue, 26 Oct 2004 06:41:42 -0400 (EDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <417E2985.2070609@stewart.chicago.il.us> Date: Tue, 26 Oct 2004 06:40:05 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SUZUKI Shinsuke References: <4177C8AD.6060706@freebsd.org> <20041021153933.GK13756@empiric.icir.org> <4177E25E.804639E@freebsd.org> <20041021213248.223cab2c.molter@tin.it> <4179ACB8.4020108@ieee.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: andre@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: SCTP in KAME / Re: Removing T/TCP and replacing itwithsomething simpler 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, 26 Oct 2004 10:42:03 -0000 SUZUKI Shinsuke wrote: >>>>>>On Fri, 22 Oct 2004 19:58:32 -0500 >>>>>>peter.lei@ieee.org(Peter Lei) said: > > >>While the SCTP API hasn't gone through last call, it's fairly >>stable and we have both "converted" many applications from TCP >>to SCTP using the sockets API, as well as had portability between >>the KAME SCTP stack and the linux stack for some test applications >>used at the last interop event (except for the standard sockets >>issues that one runs into even for TCP like no sin_length field >>in the sockaddr struct). >>I'm not aware of any KAME SNAP compilation failures w/and w/o SCTP. >>The major changes to our SCTP code when it gets committed into KAME >>has been that of code format/style. > > > What I found was the following two issues. Although these two are > technically quite trivial, what I was fearing was a lack of report to > KAME, since this may mean a lack of KAME-SCTP users. > > - inconsistency between KAME specific kernel code and SCTP leads > to an kernel compilation error. > Of course, it's a technically trivial bug and our own bug. > > - including SCTP in getaddrinfo() causes 'configure' script error > in many ports applications. > This is also a trivial problem, and maybe specific to KAME SCTP. > And some of such ports are already fixed when I encounter this > problem. > (e.g. http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/python/files/patch-configure.diff?r1=1.7&r2=1.8) > > But now I understand that lack of report does not mean a lack of > testing users (since SCTP-lovers seems communicating directly to your > team). So I can be much more optimistic now, and don't object to > merging it into -current, since such trivial bugs can be fixed easily > in -current. (I myself haven't tested SCTP very well, so I cannot > comment on its stability itself. But at least, SCTP does not seem to > affect the behavior of other protocols) > > Thanks and sorry if you feel my previous comments were insulting... > ---- > Suzuki-san: None of us on the SCTP team took your comments as insults ... we all want software with no bugs.. but it is perfectly understandable that if you don't get any bug reports you would feel no one is using it... As to compilation errors... it is difficult for me since when I prepare a patch of course I compile it but often times it takes many weeks for one of the KAME team to find the time to apply it.. this then causes a possiblity that some other changes made by KAME will make it uncompilable... or for that matter a change that KAME makes can cause SCTP not to compile and I would not have a chance to see such an issue... I am sorry I cannot help more :-0 Today I will finish running down a couple of "extra-shutdown's" and a case where no HB happens... (these are my reported bugs that are left.. nothing serious ... just a couple of strange behaviors)... Once I am done with that I can do my performance testing and then on to loading 6.0 :-D R -- Randall Stewart 803-345-0369 815-342-5222(cell) From owner-freebsd-net@FreeBSD.ORG Tue Oct 26 14:45: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 9E01816A4CE; Tue, 26 Oct 2004 14:45:03 +0000 (GMT) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B93643D39; Tue, 26 Oct 2004 14:45:03 +0000 (GMT) (envelope-from peter.lei@ieee.org) Received: from [192.168.0.203] (229-pool1.ras11.ilchi.alerondial.net[206.148.80.229]) by comcast.net (sccrmhc13) with ESMTP id <20041026144452016001rah7e> (Authid: peterlei); Tue, 26 Oct 2004 14:44:54 +0000 Message-ID: <417E62D9.2080807@ieee.org> Date: Tue, 26 Oct 2004 09:44:41 -0500 From: Peter Lei User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SUZUKI Shinsuke References: <4177C8AD.6060706@freebsd.org> <20041021153933.GK13756@empiric.icir.org> <4177E25E.804639E@freebsd.org> <20041021213248.223cab2c.molter@tin.it> <4179ACB8.4020108@ieee.org> In-Reply-To: X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010709090807020301090904" cc: freebsd-net@freebsd.org cc: andre@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: SCTP in KAME / Re: Removing T/TCP and replacing itwithsomething simpler 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, 26 Oct 2004 14:45:03 -0000 This is a cryptographically signed message in MIME format. --------------ms010709090807020301090904 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit SUZUKI Shinsuke wrote: >>>>>>On Fri, 22 Oct 2004 19:58:32 -0500 >>>>>>peter.lei@ieee.org(Peter Lei) said: > > >>While the SCTP API hasn't gone through last call, it's fairly >>stable and we have both "converted" many applications from TCP >>to SCTP using the sockets API, as well as had portability between >>the KAME SCTP stack and the linux stack for some test applications >>used at the last interop event (except for the standard sockets >>issues that one runs into even for TCP like no sin_length field >>in the sockaddr struct). >>I'm not aware of any KAME SNAP compilation failures w/and w/o SCTP. >>The major changes to our SCTP code when it gets committed into KAME >>has been that of code format/style. > > > What I found was the following two issues. Although these two are > technically quite trivial, what I was fearing was a lack of report to > KAME, since this may mean a lack of KAME-SCTP users. > > - inconsistency between KAME specific kernel code and SCTP leads > to an kernel compilation error. > Of course, it's a technically trivial bug and our own bug. This might be due to the fact that the SCTP CVS repository code is sometimes more up-to-date than the KAME one, so we can get out of sync. Randy releases patch kits based on some point in the KAME repository and we know it compiles (and runs) fine at that point, but by the time it is committed into the KAME repository, things may have changed. > - including SCTP in getaddrinfo() causes 'configure' script error > in many ports applications. > This is also a trivial problem, and maybe specific to KAME SCTP. > And some of such ports are already fixed when I encounter this > problem. > (e.g. http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/python/files/patch-configure.diff?r1=1.7&r2=1.8) Ok... I understand what you mean by compile errors now. I haven't done too much with existing apps but haven't run into this at all much yet. > But now I understand that lack of report does not mean a lack of > testing users (since SCTP-lovers seems communicating directly to your > team). So I can be much more optimistic now, and don't object to > merging it into -current, since such trivial bugs can be fixed easily > in -current. (I myself haven't tested SCTP very well, so I cannot > comment on its stability itself. But at least, SCTP does not seem to > affect the behavior of other protocols) I understand... the lack of bugs filed might lead you to believe the code isn't being used at all. > Thanks and sorry if you feel my previous comments were insulting... No, no... not at all. I just wanted to be sure that people know that the stack is indeed being used and that people are finding bugs and we are fixing them :-) regards, --peter > ---- > SUZUKI, Shinsuke @ KAME Project > --------------ms010709090807020301090904 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII7TCC AtEwggI6oAMCAQICAwvwrTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwMzE3MjE1NjMzWhcNMDUwMzE3MjE1NjMz WjBEMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSEwHwYJKoZIhvcNAQkBFhJw ZXRlci5sZWlAaWVlZS5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDX4PR3 QP+rgEBZtv1Q4YhKjRXUZQSk+9xNzesbK7pyirmUxKnm209ZGibDUAb/yC0ghvl3GbvNv/72 cyfC7JVjiABrDxY19L9mRGLKzjlK/bgBPY8SIu4blM/RtyabN4CdYk24LoGPHuLLkJIvvvQR LG0IJIfP8zvoHy0UGzyXOM/S4msxF1zDpBu7lYMe4Dpu5O9uaE2j1G/jswVmO2KMyQmffOGx 0Mw18tiGNMWkjMAwSJnXO2VSHzvh+I3OM71ReFo9ET2TtiXzqdDM5z0/LTsIyy1vP4Ib3Co9 xZNTe6JqVk2BsH7EZKPxi+oD7f/HctNWTZk0sesgba7D97jLAgMBAAGjLzAtMB0GA1UdEQQW MBSBEnBldGVyLmxlaUBpZWVlLm9yZzAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GB AB86WuVOs/pHjC4SPdbKb+obiQZVqR813FD3JcW+stkaZQHTPHoln/SYRd3TZcZIXageyme6 f5Gl3lOsamSUrtkov5u6B0vvtuDuMQH7deh1ARTQfC+R3hv29vVQ+uSPlLo/AGWaPcW030NW Bp96xBIESmHBMWGuYWkxMDHII/R+MIIC0TCCAjqgAwIBAgIDC/CtMA0GCSqGSIb3DQEBBAUA MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNDAz MTcyMTU2MzNaFw0wNTAzMTcyMTU2MzNaMEQxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBN ZW1iZXIxITAfBgkqhkiG9w0BCQEWEnBldGVyLmxlaUBpZWVlLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBANfg9HdA/6uAQFm2/VDhiEqNFdRlBKT73E3N6xsrunKKuZTE qebbT1kaJsNQBv/ILSCG+XcZu82//vZzJ8LslWOIAGsPFjX0v2ZEYsrOOUr9uAE9jxIi7huU z9G3Jps3gJ1iTbgugY8e4suQki++9BEsbQgkh8/zO+gfLRQbPJc4z9LiazEXXMOkG7uVgx7g Om7k725oTaPUb+OzBWY7YozJCZ984bHQzDXy2IY0xaSMwDBImdc7ZVIfO+H4jc4zvVF4Wj0R PZO2JfOp0MznPT8tOwjLLW8/ghvcKj3Fk1N7ompWTYGwfsRko/GL6gPt/8dy01ZNmTSx6yBt rsP3uMsCAwEAAaMvMC0wHQYDVR0RBBYwFIEScGV0ZXIubGVpQGllZWUub3JnMAwGA1UdEwEB /wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAHzpa5U6z+keMLhI91spv6huJBlWpHzXcUPclxb6y 2RplAdM8eiWf9JhF3dNlxkhdqB7KZ7p/kaXeU6xqZJSu2Si/m7oHS++24O4xAft16HUBFNB8 L5HeG/b29VD65I+Uuj8AZZo9xbTfQ1YGn3rEEgRKYcExYa5haTEwMcgj9H4wggM/MIICqKAD AgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVy biBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5n MSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZy ZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoG A1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcN AQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHy v1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsY Pge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0T AQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20v VGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQe MBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD 6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZ GwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC 3CEZNd4ksdMdRv9dX2VPMYIDOzCCAzcCAQEwaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIElzc3VpbmcgQ0ECAwvwrTAJBgUrDgMCGgUAoIIBpzAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDEwMjYxNDQ0NDFaMCMGCSqGSIb3DQEJ BDEWBBS6dbbvBCwqYEOWb9rrC2lY3V5WAjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29u c3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg SXNzdWluZyBDQQIDC/CtMHoGCyqGSIb3DQEJEAILMWugaTBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwvwrTANBgkqhkiG9w0BAQEFAASCAQAY+p+f t0w3mRIyWAeyB+CmcInZMTHpm2By+r2wf9t/5T+/5dYtBGMMB5s9MIOkI9AOHAz8b+ZVFLSb Dliw/hNaX7CsWfHNlvOYZfTivVp6oJ15hvX4AF/9YfITlgi+1W57PLkDVEJabtXBXfc0tdM9 6Jewjwh9OXqo57ojSQ7eQKZ2loUDicLuLfWH4f3DtaEwysXnE5wDfYp9tII+s/V9f36Fb+Mv kDYtvqgBlg7JT74rrykaBHnOo6ec+sPvdZKpjFYPbUbHfJRjm7mfuhZC/sSQQWM4dyOBLNlc mmcNYGXQhCvAJtfEnkQvDhytWO9nStDFcWYc4J07E68bldr3AAAAAAAA --------------ms010709090807020301090904-- From owner-freebsd-net@FreeBSD.ORG Tue Oct 26 15:31:09 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 677B116A4CE for ; Tue, 26 Oct 2004 15:31:09 +0000 (GMT) Received: from shellma.zin.lublin.pl (shellma.zin.lublin.pl [212.182.126.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11BD943D41 for ; Tue, 26 Oct 2004 15:31:09 +0000 (GMT) (envelope-from pawmal-posting@freebsd.lublin.pl) Received: by shellma.zin.lublin.pl (Postfix, from userid 1018) id AC60D347BA8; Tue, 26 Oct 2004 17:31:08 +0200 (CEST) Date: Tue, 26 Oct 2004 17:31:08 +0200 From: Pawel Malachowski To: freebsd-net@freebsd.org Message-ID: <20041026153108.GA91134@shellma.zin.lublin.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.4.2i Subject: PPTP/PPPoE mpd/poptop performance 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, 26 Oct 2004 15:31:09 -0000 Hello, I would like to ask people using mpd about performance on particular hardware setups. I am interested in the numbers of sessions (probably PPTP with weak encryption) and total bandwith, that can be achieved with, e.g.: . 300MHz CPU, . 1GHz CPU, . 2GHz CPU. Won't PPPoE behave better than PPTP? (My goals are authentication and performace.) I guess poptop will be much slower and is not a good solution for bigger setup (since it works entirely in userland)? I'm talking about small ISP environment, about 100-200 simultaneous connections over LAN, about 5-10Mbit/s total bandwith. TIA, -- Pawe³ Ma³achowski From owner-freebsd-net@FreeBSD.ORG Tue Oct 26 16:26:50 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 DDE7E16A4CE for ; Tue, 26 Oct 2004 16:26:50 +0000 (GMT) Received: from mail.otel.net (gw3.OTEL.net [212.36.8.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id EDC0243D55 for ; Tue, 26 Oct 2004 16:26:49 +0000 (GMT) (envelope-from tbyte@OTEL.net) Received: from dragon.otel.net ([212.36.8.135]) by mail.otel.net with esmtp (Exim 4.30; FreeBSD) id 1CMU9m-000EBe-Vl; Tue, 26 Oct 2004 19:26:46 +0300 Message-ID: <417E7A91.9080402@OTEL.net> Date: Tue, 26 Oct 2004 19:25:53 +0300 From: Iasen Kostov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.1) Gecko/20040728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pawel Malachowski References: <20041026153108.GA91134@shellma.zin.lublin.pl> In-Reply-To: <20041026153108.GA91134@shellma.zin.lublin.pl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: PPTP/PPPoE mpd/poptop performance 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, 26 Oct 2004 16:26:51 -0000 Pawel Malachowski wrote: >Hello, > >I would like to ask people using mpd about performance on particular hardware >setups. I am interested in the numbers of sessions (probably PPTP with weak >encryption) and total bandwith, that can be achieved with, e.g.: >. 300MHz CPU, >. 1GHz CPU, >. 2GHz CPU. >Won't PPPoE behave better than PPTP? (My goals are authentication and >performace.) >I guess poptop will be much slower and is not a good solution for bigger >setup (since it works entirely in userland)? >I'm talking about small ISP environment, about 100-200 simultaneous >connections over LAN, about 5-10Mbit/s total bandwith. > > >TIA, > > I'm using poptop + pppoed (both with ppp) with upstream of 100MBit/sec but shapped users (max 2MBit/sec). This all on 2.6 - 3GHz machines and 1GB of RAM each (4.9 and 5.3 machines) . Every of these can handle about 370 users(depending on the max speed of users connected to it). mpd is not good for me becouse it can't (as far as I know) create bundles on the fly - You should have them all in the config files... I think that mpd should be faster choice becouse bigger part of his job is done in the kernel via NG framework. And yes PPPoE (after some test) is faster than PPTP (no encryption at all). From owner-freebsd-net@FreeBSD.ORG Tue Oct 26 16:29: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 60D5D16A4CE for ; Tue, 26 Oct 2004 16:29:29 +0000 (GMT) Received: from silver.he.iki.fi (helenius.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 06EB243D72 for ; Tue, 26 Oct 2004 16:29:28 +0000 (GMT) (envelope-from pete@he.iki.fi) Received: from [193.64.42.134] (h86.vuokselantie10.fi [193.64.42.134]) by silver.he.iki.fi (8.13.1/8.11.4) with ESMTP id i9QGTNTY008163; Tue, 26 Oct 2004 19:29:23 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <417E7B65.3050607@he.iki.fi> Date: Tue, 26 Oct 2004 19:29:25 +0300 From: Petri Helenius User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pawel Malachowski References: <20041026153108.GA91134@shellma.zin.lublin.pl> In-Reply-To: <20041026153108.GA91134@shellma.zin.lublin.pl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: PPTP/PPPoE mpd/poptop performance 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, 26 Oct 2004 16:29:29 -0000 Pawel Malachowski wrote: >Hello, > >I would like to ask people using mpd about performance on particular hardware >setups. I am interested in the numbers of sessions (probably PPTP with weak >encryption) and total bandwith, that can be achieved with, e.g.: >. 300MHz CPU, >. 1GHz CPU, >. 2GHz CPU. > > Although I'm not expert on mpd, I couldn't resist mentioning that not all MHz are created equal and you probably achieve more performance difference by carefully choosing a well performing NIC than the absolute MHz on the box. Pete >Won't PPPoE behave better than PPTP? (My goals are authentication and >performace.) >I guess poptop will be much slower and is not a good solution for bigger >setup (since it works entirely in userland)? >I'm talking about small ISP environment, about 100-200 simultaneous >connections over LAN, about 5-10Mbit/s total bandwith. > > >TIA, > > From owner-freebsd-net@FreeBSD.ORG Tue Oct 26 19:39: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 7945516A4CE for ; Tue, 26 Oct 2004 19:39:58 +0000 (GMT) Received: from shellma.zin.lublin.pl (shellma.zin.lublin.pl [212.182.126.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id EBC1A43D3F for ; Tue, 26 Oct 2004 19:39:57 +0000 (GMT) (envelope-from pawmal-posting@freebsd.lublin.pl) Received: by shellma.zin.lublin.pl (Postfix, from userid 1018) id E9FB4347E01; Tue, 26 Oct 2004 21:39:57 +0200 (CEST) Date: Tue, 26 Oct 2004 21:39:57 +0200 From: Pawel Malachowski To: freebsd-net@freebsd.org Message-ID: <20041026193957.GB91134@shellma.zin.lublin.pl> References: <20041026153108.GA91134@shellma.zin.lublin.pl> <417E7B65.3050607@he.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <417E7B65.3050607@he.iki.fi> User-Agent: Mutt/1.4.2i Subject: Re: PPTP/PPPoE mpd/poptop performance X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd-net@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2004 19:39:58 -0000 On Tue, Oct 26, 2004 at 07:29:25PM +0300, Petri Helenius wrote: > Although I'm not expert on mpd, I couldn't resist mentioning that not > all MHz are created equal and you probably achieve more performance > difference by carefully choosing a well performing NIC than the absolute > MHz on the box. As I said, we are talking about 5-10Mbit bandwith, NIC performance is not so important (however, I use fxp(4) and dc(4) everywhere:)). In this case, CPU power may be quite significant because of encryption. That's why I'm looking for feedback from sysadmins of PPTP or PPPoE hubs utilizong mpd or poptop, working in production environment. Just to know, what can I expect from my old Celeron 300MHz etc., before I decide to touch this. :) -- Pawe³ Ma³achowski From owner-freebsd-net@FreeBSD.ORG Tue Oct 26 19:57: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 310D216A4CE for ; Tue, 26 Oct 2004 19:57:51 +0000 (GMT) Received: from dstsystems.com (dstsys-cp.dstsystems.com [204.167.177.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id B0DDC43D69 for ; Tue, 26 Oct 2004 19:57:50 +0000 (GMT) (envelope-from GEWhite@dstoutput.com) Received: from dstnm02.dstsystems.com (localhost [127.0.0.1]) by dstsystems.com (8.8.8+Sun/8.7.5) with ESMTP id OAA09603 for ; Tue, 26 Oct 2004 14:57:49 -0500 (CDT) From: GEWhite@dstoutput.com To: freebsd-net@freebsd.org Message-ID: Date: Tue, 26 Oct 2004 14:55:27 -0500 X-MIMETrack: Serialize by Router on DSTNM02/Server/DST/US(Release 6.0.4|June 01, 2004) at 10/26/2004 14:55:28 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: George White is out of the office. 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, 26 Oct 2004 19:57:51 -0000 I will be out of the office starting 10/26/2004 and will not return until 11/01/2004. I will respond to your message when I return. If it is urgent please contact Heinz Ambach @ X4212 or Christine lovett @ X4409. From owner-freebsd-net@FreeBSD.ORG Tue Oct 26 20:27:26 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 5B28416A4CF for ; Tue, 26 Oct 2004 20:27:26 +0000 (GMT) Received: from ints.mail.pike.ru (ints.mail.pike.ru [195.9.45.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B30C43D48 for ; Tue, 26 Oct 2004 20:27:25 +0000 (GMT) (envelope-from babolo@cicuta.babolo.ru) Received: (qmail 72427 invoked from network); 26 Oct 2004 20:32:37 -0000 Received: from cicuta.babolo.ru (194.135.49.133) by ints.mail.pike.ru with SMTP; 26 Oct 2004 20:32:37 -0000 Received: (nullmailer pid 98696 invoked by uid 136); Tue, 26 Oct 2004 20:29:12 -0000 X-ELM-OSV: (Our standard violations) hdr-charset=KOI8-R; no-hdr-encoding=1 In-Reply-To: <417C85FA.5050708@elischer.org> To: Julian Elischer Date: Wed, 27 Oct 2004 00:29:12 +0400 (MSD) From: "."@babolo.ru X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <1098822552.745683.98695.nullmailer@cicuta.babolo.ru> cc: Stephane Raimbault cc: net@freebsd.org Subject: Re: using natd to load balance port 80 to multiple servers 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, 26 Oct 2004 20:27:26 -0000 [ Charset ISO-8859-1 unsupported, converting... ] > Stephane Raimbault wrote: > > Hi All, > > > > I'm currently using a freebsd box running natd to forward port 80 to > > several (5) web servers on private IP's. > > > > I have discovered that natd doesn't handle many requests/second all that > > well (seem to choke at about 200 req/second (educated guess)) > > > > use the "ipfw fwd" option to directly send the packets to the appropriate machine. > Should be able to forwarrd at wire speed. > > you will probably need ipfw fwd running on both sides of the forward.. > one on the switch machine to forward packets to one machine and one on > that machine to "capture" those packets to a local socket. Simplier. ifconfig lo1 inet IP with the same IP on every balansed computer, and then fwd balanserIP ip from any:mask to IP for each balanserIP, where IP is some address, routable by router, the same for each balansed computer. > > There are other packet filtering options on FreeBSD and I wonder if I > > can use them to do what I'm trying to do with natd. > > > > Would someone be able to point me to documentation or help me have > > either ipf/ipfw/pf forward port 80 traffic to private space IP's? From owner-freebsd-net@FreeBSD.ORG Wed Oct 27 07:39: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 391F616A4CE for ; Wed, 27 Oct 2004 07:39:11 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3267943D49 for ; Wed, 27 Oct 2004 07:39:10 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 969756538E for ; Wed, 27 Oct 2004 08:39:08 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 68184-01-3 for ; Wed, 27 Oct 2004 08:39:08 +0100 (BST) Received: from empiric.dek.spc.org (adsl-67-121-95-134.dsl.snfc21.pacbell.net [67.121.95.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 7C99465375 for ; Wed, 27 Oct 2004 08:39:07 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 0AFC16246; Wed, 27 Oct 2004 00:38:58 -0700 (PDT) Date: Wed, 27 Oct 2004 00:38:58 -0700 From: Bruce M Simpson To: freebsd-net@freebsd.org Message-ID: <20041027073858.GC719@empiric.icir.org> Mail-Followup-To: freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mojUlQ0s9EVzWg2t" Content-Disposition: inline Subject: Implementing IP_SENDIF (like SO_BINDTODEVICE) 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, 27 Oct 2004 07:39:11 -0000 --mojUlQ0s9EVzWg2t Content-Type: multipart/mixed; boundary="RnlQjJ0d97Da+TV1" Content-Disposition: inline --RnlQjJ0d97Da+TV1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline It annoys me that we have to resort to BPF to send IP datagrams on unnumbered interfaces. Here is a half baked idea. Please look and tell me what you think. --RnlQjJ0d97Da+TV1 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ip_sendif_rev1.patch" Content-Transfer-Encoding: quoted-printable Adding IP_SENDIF (like Linux's SO_BINDTODEVICE) support to FreeBSD. Clean up the RFC 1724 hack in ip_output.c TODO: Add IP_SENDIF processing to ip_ctloutput. Move inp_depend6.inp6_ifindex into general inpcb structure. Update #define. Pass IP_ROUTETOIF flag to ip_output() from udp and rawip. Pass inp_ifindex to ip_output() as destination from udp and rawip. Index: src/sys/netinet/ip_output.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/netinet/ip_output.c,v retrieving revision 1.225.2.4 diff -u -p -r1.225.2.4 ip_output.c --- src/sys/netinet/ip_output.c 22 Sep 2004 19:23:38 -0000 1.225.2.4 +++ src/sys/netinet/ip_output.c 27 Oct 2004 07:27:24 -0000 @@ -93,7 +93,7 @@ SYSCTL_INT(_net_inet_ip, OID_AUTO, mbuf_ #endif =20 static struct mbuf *ip_insertoptions(struct mbuf *, struct mbuf *, int *); -static struct ifnet *ip_multicast_if(struct in_addr *, int *); +static struct ifnet *ina_to_rfc1724_if(struct in_addr *, int *); static void ip_mloopback (struct ifnet *, struct mbuf *, struct sockaddr_in *, int); static int ip_getmoptions @@ -206,19 +206,30 @@ again: dst->sin_addr =3D ip->ip_dst; } /* - * If routing to interface only, - * short circuit routing lookup. + * If routing to interface only, short circuit routing lookup. + * + * Assume the destination is either the destination end of a + * point-to-point interface, the network address of an interface, + * or the address of an interface itself. In the last case, an + * interface may be specified by index as per RFC 1724. + *=20 */ if (flags & IP_ROUTETOIF) { - if ((ia =3D ifatoia(ifa_ifwithdstaddr(sintosa(dst)))) =3D=3D NULL && - (ia =3D ifatoia(ifa_ifwithnet(sintosa(dst)))) =3D=3D NULL) { + ia =3D ifatoia(ifa_ifwithdstaddr(sintosa(dst))); + if (ia =3D=3D NULL) + ia =3D ifatoia(ifa_ifwithnet(sintosa(dst))); + if (ia !=3D NULL) + ifp =3D ia->ia_ifp; + else + ifp =3D ina_to_rfc1724_if(&dst->sin_addr, NULL); + if (ifp =3D=3D NULL) { ipstat.ips_noroute++; error =3D ENETUNREACH; goto bad; } - ifp =3D ia->ia_ifp; ip->ip_ttl =3D 1; - isbroadcast =3D in_broadcast(dst->sin_addr, ifp); + isbroadcast =3D (flags & IP_SENDONES) | + in_broadcast(dst->sin_addr, ifp); } else if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr)) && imo !=3D NULL && imo->imo_multicast_ifp !=3D NULL) { /* @@ -1531,11 +1542,15 @@ bad: * standard option (IP_TTL). */ =20 +#define INADDR_IFINDEX_MASK 0x00FFFFFF /* 0.0.0.0/8 */ + /* - * following RFC1724 section 3.3, 0.0.0.0/8 is interpreted as interface in= dex. + * Look up the ifnet corresponding to a given IPv4 host address, taking the + * RFC1724 hack into account. If the address given has the network prefix + * 0.0.0.0/8, interpret the host portion as an interface index. */ static struct ifnet * -ip_multicast_if(a, ifindexp) +ina_to_rfc1724_if(a, ifindexp) struct in_addr *a; int *ifindexp; { @@ -1544,8 +1559,8 @@ ip_multicast_if(a, ifindexp) =20 if (ifindexp) *ifindexp =3D 0; - if (ntohl(a->s_addr) >> 24 =3D=3D 0) { - ifindex =3D ntohl(a->s_addr) & 0xffffff; + if ((ntohl(a->s_addr) & ~INADDR_IFINDEX_MASK) =3D=3D 0) { + ifindex =3D ntohl(a->s_addr) & 0x00FFFFFF; if (ifindex < 0 || if_index < ifindex) return NULL; ifp =3D ifnet_byindex(ifindex); @@ -1554,7 +1569,7 @@ ip_multicast_if(a, ifindexp) } else { INADDR_TO_IFP(*a, ifp); } - return ifp; + return (ifp); } =20 /* @@ -1634,7 +1649,7 @@ ip_setmoptions(sopt, imop) * it supports multicasting. */ s =3D splimp(); - ifp =3D ip_multicast_if(&addr, &ifindex); + ifp =3D ina_to_rfc1724_if(&addr, &ifindex); if (ifp =3D=3D NULL || (ifp->if_flags & IFF_MULTICAST) =3D=3D 0) { splx(s); error =3D EADDRNOTAVAIL; @@ -1731,7 +1746,7 @@ ip_setmoptions(sopt, imop) RTFREE(ro.ro_rt); } else { - ifp =3D ip_multicast_if(&mreq.imr_interface, NULL); + ifp =3D ina_to_rfc1724_if(&mreq.imr_interface, NULL); } =20 /* @@ -1799,7 +1814,7 @@ ip_setmoptions(sopt, imop) if (mreq.imr_interface.s_addr =3D=3D INADDR_ANY) ifp =3D NULL; else { - ifp =3D ip_multicast_if(&mreq.imr_interface, NULL); + ifp =3D ina_to_rfc1724_if(&mreq.imr_interface, NULL); if (ifp =3D=3D NULL) { error =3D EADDRNOTAVAIL; splx(s); --RnlQjJ0d97Da+TV1-- --mojUlQ0s9EVzWg2t Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Comment: '' iD8DBQFBf1CRueUpAYYNtTsRAq2ZAJsEpxqxKF2l20jgnztRsZhElDNZHQCeLb7l bPPlc+nBc/B3muPtA0NpVdU= =V3uW -----END PGP SIGNATURE----- --mojUlQ0s9EVzWg2t-- From owner-freebsd-net@FreeBSD.ORG Wed Oct 27 19:12: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 478A616A4CE; Wed, 27 Oct 2004 19:12:37 +0000 (GMT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8927943D1F; Wed, 27 Oct 2004 19:12:36 +0000 (GMT) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id i9RJCXLd045514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Oct 2004 23:12:34 +0400 (MSD) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id i9RJCXcG045513; Wed, 27 Oct 2004 23:12:33 +0400 (MSD) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Wed, 27 Oct 2004 23:12:33 +0400 From: Gleb Smirnoff To: bms@freebsd.org Message-ID: <20041027191233.GF44427@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , bms@freebsd.org, freebsd-net@FreeBSD.org References: <200410260331.i9Q3Vxbv060994@repoman.freebsd.org> <20041026034126.GI706@empiric.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20041026034126.GI706@empiric.icir.org> User-Agent: Mutt/1.5.6i cc: freebsd-net@freebsd.org Subject: Re: cvs commit: src/sys/netinet if_ether.c 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, 27 Oct 2004 19:12:37 -0000 Bruce, On Mon, Oct 25, 2004 at 08:41:26PM -0700, Bruce M Simpson wrote: B> On Tue, Oct 26, 2004 at 03:31:59AM +0000, Bruce M Simpson wrote: B> > Log: B> > Check that rt_mask(rt) is non-NULL before dereferencing it, in the B> > RTM_ADD case, thus avoiding a panic. B> B> PR: kern/42030 B> B> It isn't immediately clear to me if this is a routing socket API issue B> or a client issue. B> B> The panic, at least, is worked around, but the root problem needs to be B> fixed -- it is most likely a synchronization problem in zebra whereby it B> is attempting to add a route to the kernel FIB which references an B> interface which does not yet exist or has gone away. B> B> At least one person who has reported this was running vtund, which plumbs B> its own tun instances on demand; the other I think was running userland ppp. B> B> I haven't seen anything similar with XORP yet. If we are interested in tracking this down, we should add a printf, so that people who hit this will notce it and report. Otherwise this problem will be left forever in a workaround state. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Wed Oct 27 19:28: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 DEF5116A4CE for ; Wed, 27 Oct 2004 19:28:22 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id B262443D1D for ; Wed, 27 Oct 2004 19:28:22 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 884177A427; Wed, 27 Oct 2004 12:28:22 -0700 (PDT) Message-ID: <417FF6D6.4010201@elischer.org> Date: Wed, 27 Oct 2004 12:28:22 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Bruce M Simpson References: <20041027073858.GC719@empiric.icir.org> In-Reply-To: <20041027073858.GC719@empiric.icir.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: Implementing IP_SENDIF (like SO_BINDTODEVICE) 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, 27 Oct 2004 19:28:23 -0000 Bruce M Simpson wrote: >It annoys me that we have to resort to BPF to send IP datagrams on >unnumbered interfaces. Here is a half baked idea. Please look and >tell me what you think. > I've sent lots of datagrams on un-numberred interfaces using netgraph.. > > >------------------------------------------------------------------------ > >Adding IP_SENDIF (like Linux's SO_BINDTODEVICE) support to FreeBSD. >Clean up the RFC 1724 hack in ip_output.c > >TODO: > >Add IP_SENDIF processing to ip_ctloutput. >Move inp_depend6.inp6_ifindex into general inpcb structure. >Update #define. >Pass IP_ROUTETOIF flag to ip_output() from udp and rawip. >Pass inp_ifindex to ip_output() as destination from udp and rawip. > >Index: src/sys/netinet/ip_output.c >=================================================================== >RCS file: /home/ncvs/src/sys/netinet/ip_output.c,v >retrieving revision 1.225.2.4 >diff -u -p -r1.225.2.4 ip_output.c >--- src/sys/netinet/ip_output.c 22 Sep 2004 19:23:38 -0000 1.225.2.4 >+++ src/sys/netinet/ip_output.c 27 Oct 2004 07:27:24 -0000 >@@ -93,7 +93,7 @@ SYSCTL_INT(_net_inet_ip, OID_AUTO, mbuf_ > #endif > > static struct mbuf *ip_insertoptions(struct mbuf *, struct mbuf *, int *); >-static struct ifnet *ip_multicast_if(struct in_addr *, int *); >+static struct ifnet *ina_to_rfc1724_if(struct in_addr *, int *); > static void ip_mloopback > (struct ifnet *, struct mbuf *, struct sockaddr_in *, int); > static int ip_getmoptions >@@ -206,19 +206,30 @@ again: > dst->sin_addr = ip->ip_dst; > } > /* >- * If routing to interface only, >- * short circuit routing lookup. >+ * If routing to interface only, short circuit routing lookup. >+ * >+ * Assume the destination is either the destination end of a >+ * point-to-point interface, the network address of an interface, >+ * or the address of an interface itself. In the last case, an >+ * interface may be specified by index as per RFC 1724. >+ * > */ > if (flags & IP_ROUTETOIF) { >- if ((ia = ifatoia(ifa_ifwithdstaddr(sintosa(dst)))) == NULL && >- (ia = ifatoia(ifa_ifwithnet(sintosa(dst)))) == NULL) { >+ ia = ifatoia(ifa_ifwithdstaddr(sintosa(dst))); >+ if (ia == NULL) >+ ia = ifatoia(ifa_ifwithnet(sintosa(dst))); >+ if (ia != NULL) >+ ifp = ia->ia_ifp; >+ else >+ ifp = ina_to_rfc1724_if(&dst->sin_addr, NULL); >+ if (ifp == NULL) { > ipstat.ips_noroute++; > error = ENETUNREACH; > goto bad; > } >- ifp = ia->ia_ifp; > ip->ip_ttl = 1; >- isbroadcast = in_broadcast(dst->sin_addr, ifp); >+ isbroadcast = (flags & IP_SENDONES) | >+ in_broadcast(dst->sin_addr, ifp); > } else if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr)) && > imo != NULL && imo->imo_multicast_ifp != NULL) { > /* >@@ -1531,11 +1542,15 @@ bad: > * standard option (IP_TTL). > */ > >+#define INADDR_IFINDEX_MASK 0x00FFFFFF /* 0.0.0.0/8 */ >+ > /* >- * following RFC1724 section 3.3, 0.0.0.0/8 is interpreted as interface index. >+ * Look up the ifnet corresponding to a given IPv4 host address, taking the >+ * RFC1724 hack into account. If the address given has the network prefix >+ * 0.0.0.0/8, interpret the host portion as an interface index. > */ > static struct ifnet * >-ip_multicast_if(a, ifindexp) >+ina_to_rfc1724_if(a, ifindexp) > struct in_addr *a; > int *ifindexp; > { >@@ -1544,8 +1559,8 @@ ip_multicast_if(a, ifindexp) > > if (ifindexp) > *ifindexp = 0; >- if (ntohl(a->s_addr) >> 24 == 0) { >- ifindex = ntohl(a->s_addr) & 0xffffff; >+ if ((ntohl(a->s_addr) & ~INADDR_IFINDEX_MASK) == 0) { >+ ifindex = ntohl(a->s_addr) & 0x00FFFFFF; > if (ifindex < 0 || if_index < ifindex) > return NULL; > ifp = ifnet_byindex(ifindex); >@@ -1554,7 +1569,7 @@ ip_multicast_if(a, ifindexp) > } else { > INADDR_TO_IFP(*a, ifp); > } >- return ifp; >+ return (ifp); > } > > /* >@@ -1634,7 +1649,7 @@ ip_setmoptions(sopt, imop) > * it supports multicasting. > */ > s = splimp(); >- ifp = ip_multicast_if(&addr, &ifindex); >+ ifp = ina_to_rfc1724_if(&addr, &ifindex); > if (ifp == NULL || (ifp->if_flags & IFF_MULTICAST) == 0) { > splx(s); > error = EADDRNOTAVAIL; >@@ -1731,7 +1746,7 @@ ip_setmoptions(sopt, imop) > RTFREE(ro.ro_rt); > } > else { >- ifp = ip_multicast_if(&mreq.imr_interface, NULL); >+ ifp = ina_to_rfc1724_if(&mreq.imr_interface, NULL); > } > > /* >@@ -1799,7 +1814,7 @@ ip_setmoptions(sopt, imop) > if (mreq.imr_interface.s_addr == INADDR_ANY) > ifp = NULL; > else { >- ifp = ip_multicast_if(&mreq.imr_interface, NULL); >+ ifp = ina_to_rfc1724_if(&mreq.imr_interface, NULL); > if (ifp == NULL) { > error = EADDRNOTAVAIL; > splx(s); > > From owner-freebsd-net@FreeBSD.ORG Wed Oct 27 19:50:40 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 AF06016A4CE; Wed, 27 Oct 2004 19:50:40 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7400843D45; Wed, 27 Oct 2004 19:50:40 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 74B6A65339; Wed, 27 Oct 2004 20:50:39 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 77178-03-4; Wed, 27 Oct 2004 20:50:39 +0100 (BST) Received: from empiric.dek.spc.org (c-24-7-102-181.client.comcast.net [24.7.102.181]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 9FDDF6530A; Wed, 27 Oct 2004 20:50:38 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 7CC8F6246; Wed, 27 Oct 2004 12:50:29 -0700 (PDT) Date: Wed, 27 Oct 2004 12:50:29 -0700 From: Bruce M Simpson To: Gleb Smirnoff , freebsd-net@FreeBSD.org Message-ID: <20041027195029.GB770@empiric.icir.org> Mail-Followup-To: Gleb Smirnoff , freebsd-net@FreeBSD.org References: <200410260331.i9Q3Vxbv060994@repoman.freebsd.org> <20041026034126.GI706@empiric.icir.org> <20041027191233.GF44427@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041027191233.GF44427@cell.sick.ru> Subject: Re: cvs commit: src/sys/netinet if_ether.c 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, 27 Oct 2004 19:50:40 -0000 On Wed, Oct 27, 2004 at 11:12:33PM +0400, Gleb Smirnoff wrote: > If we are interested in tracking this down, we should add a printf, > so that people who hit this will notce it and report. > Otherwise this problem will be left forever in a workaround state. That's what revision 1.109 was for, but I have only had 2 reports of this. Once the ARP rewrite is finished, and ARP is finally separated from the routing table, we will probably not see this any more. My theory right now is that a sockaddr_dl is being interpreted as a link-layer address when actually only the sdl_index field needs to be interpreted. BMS From owner-freebsd-net@FreeBSD.ORG Wed Oct 27 19:52: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 D6C4716A4CE for ; Wed, 27 Oct 2004 19:52:44 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DB0143D46 for ; Wed, 27 Oct 2004 19:52:44 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id ADE416538E; Wed, 27 Oct 2004 20:52:43 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 77178-03-8; Wed, 27 Oct 2004 20:52:43 +0100 (BST) Received: from empiric.dek.spc.org (c-24-7-102-181.client.comcast.net [24.7.102.181]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 115EE65381; Wed, 27 Oct 2004 20:52:43 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id E82536246; Wed, 27 Oct 2004 12:52:33 -0700 (PDT) Date: Wed, 27 Oct 2004 12:52:33 -0700 From: Bruce M Simpson To: Julian Elischer Message-ID: <20041027195233.GC770@empiric.icir.org> Mail-Followup-To: Julian Elischer , freebsd-net@freebsd.org References: <20041027073858.GC719@empiric.icir.org> <417FF6D6.4010201@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <417FF6D6.4010201@elischer.org> cc: freebsd-net@freebsd.org Subject: Re: Implementing IP_SENDIF (like SO_BINDTODEVICE) 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, 27 Oct 2004 19:52:44 -0000 On Wed, Oct 27, 2004 at 12:28:22PM -0700, Julian Elischer wrote: > >It annoys me that we have to resort to BPF to send IP datagrams on > >unnumbered interfaces. Here is a half baked idea. Please look and > >tell me what you think. > > I've sent lots of datagrams on un-numberred interfaces using netgraph.. I should qualify my post a bit more: I began thinking along these lines with the intention of enabling ISC dhcp (and dhclient) to be compiled without using bpf support. I don't have the time or interest to port ISC dhcp to use netgraph, but I'd be interested to see the results if that happened. BMS From owner-freebsd-net@FreeBSD.ORG Thu Oct 28 02:29: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 41D8C16A4CE for ; Thu, 28 Oct 2004 02:29:56 +0000 (GMT) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C79043D31 for ; Thu, 28 Oct 2004 02:29:56 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) i9S2Tia4084644; Wed, 27 Oct 2004 19:29:44 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (pc1.oakwoodazabu1-unet.ocn.ne.jp [220.110.140.201]) by mail.meer.net (8.12.10/8.12.2/meer) with ESMTP id i9S2TdRw019708; Wed, 27 Oct 2004 19:29:43 -0700 (PDT) (envelope-from gnn@neville-neil.com) Date: Thu, 28 Oct 2004 11:29:36 +0900 Message-ID: From: "George V. Neville-Neil" To: Julian Elischer , freebsd-net@freebsd.org In-Reply-To: <20041027195233.GC770@empiric.icir.org> References: <20041027073858.GC719@empiric.icir.org> <417FF6D6.4010201@elischer.org> <20041027195233.GC770@empiric.icir.org> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.5 Emacs/21.2 (powerpc-apple-darwin) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Subject: Re: Implementing IP_SENDIF (like SO_BINDTODEVICE) 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, 28 Oct 2004 02:29:56 -0000 At Wed, 27 Oct 2004 12:52:33 -0700, Bruce M Simpson wrote: > > On Wed, Oct 27, 2004 at 12:28:22PM -0700, Julian Elischer wrote: > > >It annoys me that we have to resort to BPF to send IP datagrams on > > >unnumbered interfaces. Here is a half baked idea. Please look and > > >tell me what you think. > > > > I've sent lots of datagrams on un-numberred interfaces using netgraph.. > > I should qualify my post a bit more: I began thinking along these lines > with the intention of enabling ISC dhcp (and dhclient) to be compiled > without using bpf support. I don't have the time or interest to port ISC > dhcp to use netgraph, but I'd be interested to see the results if that > happened. > Just one quick question. Does the use of this option require root privilege? I think it should :-) Later, George From owner-freebsd-net@FreeBSD.ORG Thu Oct 28 11:38: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 7B0F616A4CE for ; Thu, 28 Oct 2004 11:38:13 +0000 (GMT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id A491043D2F for ; Thu, 28 Oct 2004 11:38:12 +0000 (GMT) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id i9SBc8l5050582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Oct 2004 15:38:09 +0400 (MSD) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id i9SBc856050581; Thu, 28 Oct 2004 15:38:08 +0400 (MSD) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Thu, 28 Oct 2004 15:38:08 +0400 From: Gleb Smirnoff To: Pawel Malachowski Message-ID: <20041028113808.GB50262@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , Pawel Malachowski , freebsd-net@freebsd.org References: <20041026153108.GA91134@shellma.zin.lublin.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20041026153108.GA91134@shellma.zin.lublin.pl> User-Agent: Mutt/1.5.6i cc: freebsd-net@freebsd.org Subject: Re: PPTP/PPPoE mpd/poptop performance 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, 28 Oct 2004 11:38:13 -0000 On Tue, Oct 26, 2004 at 05:31:08PM +0200, Pawel Malachowski wrote: P> I would like to ask people using mpd about performance on particular hardware P> setups. I am interested in the numbers of sessions (probably PPTP with weak P> encryption) and total bandwith, that can be achieved with, e.g.: P> . 300MHz CPU, P> . 1GHz CPU, P> . 2GHz CPU. P> Won't PPPoE behave better than PPTP? (My goals are authentication and P> performace.) P> I guess poptop will be much slower and is not a good solution for bigger P> setup (since it works entirely in userland)? P> I'm talking about small ISP environment, about 100-200 simultaneous P> connections over LAN, about 5-10Mbit/s total bandwith. If your going to use encryption, then it will be the bottleneck. And even difference between kernel(mpd) and userland(poptop,pppoed) implementations is not going to be significant. You will need as much fast CPU as possible. I'd suggest to choose PPPoE, not PPTP, because the latter is quite complicated and violated by some client implementation. You will not find any problems with PPPoE, since ng_pppoe is compatible with all known PPPoE implementations. I'm running two PPPoE servers with no encryption: 1) userland ppp, ~200 sessions, ~2Mbit/s. Under peak traffic load is significant. 2) mpd, 10 - 50 clients (a small net). The load is almost zero. Can handle wirespeed 100Mbit, with interrupt load equal to load on pure Ethernet routing. I have no experience with number of clients > 200. I suppose we are going to notice performance degradation in linear search functions in netgraph or interface code only when number of clients >> 1000. If someone has such requirements, I'd be happy to work with him. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Thu Oct 28 11:41: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 7FEC716A4CE for ; Thu, 28 Oct 2004 11:41:41 +0000 (GMT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id C32B943D1D for ; Thu, 28 Oct 2004 11:41:40 +0000 (GMT) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id i9SBfZF8050627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Oct 2004 15:41:35 +0400 (MSD) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id i9SBfYaL050626; Thu, 28 Oct 2004 15:41:34 +0400 (MSD) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Thu, 28 Oct 2004 15:41:34 +0400 From: Gleb Smirnoff To: Julian Elischer , freebsd-net@freebsd.org Message-ID: <20041028114134.GC50262@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , Julian Elischer , freebsd-net@freebsd.org References: <20041027073858.GC719@empiric.icir.org> <417FF6D6.4010201@elischer.org> <20041027195233.GC770@empiric.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20041027195233.GC770@empiric.icir.org> User-Agent: Mutt/1.5.6i Subject: Re: Implementing IP_SENDIF (like SO_BINDTODEVICE) 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, 28 Oct 2004 11:41:41 -0000 On Wed, Oct 27, 2004 at 12:52:33PM -0700, Bruce M Simpson wrote: B> On Wed, Oct 27, 2004 at 12:28:22PM -0700, Julian Elischer wrote: B> > >It annoys me that we have to resort to BPF to send IP datagrams on B> > >unnumbered interfaces. Here is a half baked idea. Please look and B> > >tell me what you think. B> > B> > I've sent lots of datagrams on un-numberred interfaces using netgraph.. B> B> I should qualify my post a bit more: I began thinking along these lines B> with the intention of enabling ISC dhcp (and dhclient) to be compiled B> without using bpf support. I don't have the time or interest to port ISC B> dhcp to use netgraph, but I'd be interested to see the results if that B> happened. ng_device can be attached to "orphans" hook of ng_ether. /dev/ngdX opened by dhcpd, and packets processed. What is benefit to get rid of bpf? What is problem with it? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Thu Oct 28 13:13: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 7C2B916A4CE for ; Thu, 28 Oct 2004 13:13:07 +0000 (GMT) Received: from shellma.zin.lublin.pl (shellma.zin.lublin.pl [212.182.126.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0824A43D49 for ; Thu, 28 Oct 2004 13:13:07 +0000 (GMT) (envelope-from pawmal-posting@freebsd.lublin.pl) Received: by shellma.zin.lublin.pl (Postfix, from userid 1018) id 4D12D347BA8; Thu, 28 Oct 2004 15:13:16 +0200 (CEST) Date: Thu, 28 Oct 2004 15:13:16 +0200 From: Pawel Malachowski To: freebsd-net@freebsd.org Message-ID: <20041028131316.GA73157@shellma.zin.lublin.pl> References: <20041026153108.GA91134@shellma.zin.lublin.pl> <20041028113808.GB50262@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20041028113808.GB50262@cell.sick.ru> User-Agent: Mutt/1.4.2i Subject: Re: PPTP/PPPoE mpd/poptop performance 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, 28 Oct 2004 13:13:07 -0000 On Thu, Oct 28, 2004 at 03:38:08PM +0400, Gleb Smirnoff wrote: > I'd suggest to choose PPPoE, not PPTP, because the latter is quite > complicated and violated by some client implementation. You will > not find any problems with PPPoE, since ng_pppoe is compatible with > all known PPPoE implementations. This is what I am currently looking at. I am considering PPTP only because client is already available in Windows machines for free. While in XP PPPoE is already in, I don't see free PPPoE clients for Win9x. I am a bit worried about behaviour in lossy WiFi environments; I'll give it a try in free time, I guess. > 1) userland ppp, ~200 sessions, ~2Mbit/s. Under peak traffic load > is significant. > 2) mpd, 10 - 50 clients (a small net). The load is almost zero. > Can handle wirespeed 100Mbit, with interrupt load equal to > load on pure Ethernet routing. Thanks. -- Pawe³ Ma³achowski From owner-freebsd-net@FreeBSD.ORG Thu Oct 28 15:49: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 B275916A4CE for ; Thu, 28 Oct 2004 15:49:41 +0000 (GMT) Received: from mail.otel.net (gw3.OTEL.net [212.36.8.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id D6EBD43D53 for ; Thu, 28 Oct 2004 15:49:40 +0000 (GMT) (envelope-from tbyte@OTEL.net) Received: from dragon.otel.net ([212.36.8.135]) by mail.otel.net with esmtp (Exim 4.30; FreeBSD) id 1CNCWw-000OB9-4Z; Thu, 28 Oct 2004 18:49:38 +0300 Message-ID: <418114DE.6000600@OTEL.net> Date: Thu, 28 Oct 2004 18:48:46 +0300 From: Iasen Kostov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20041027 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pawel Malachowski References: <20041026153108.GA91134@shellma.zin.lublin.pl> <20041028113808.GB50262@cell.sick.ru> <20041028131316.GA73157@shellma.zin.lublin.pl> In-Reply-To: <20041028131316.GA73157@shellma.zin.lublin.pl> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: PPTP/PPPoE mpd/poptop performance 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, 28 Oct 2004 15:49:41 -0000 Pawel Malachowski wrote: >On Thu, Oct 28, 2004 at 03:38:08PM +0400, Gleb Smirnoff wrote: > > > >>I'd suggest to choose PPPoE, not PPTP, because the latter is quite >>complicated and violated by some client implementation. You will >>not find any problems with PPPoE, since ng_pppoe is compatible with >>all known PPPoE implementations. >> >> > >This is what I am currently looking at. I am considering PPTP only because >client is already available in Windows machines for free. While in XP PPPoE >is already in, I don't see free PPPoE clients for Win9x. >I am a bit worried about behaviour in lossy WiFi environments; I'll give it >a try in free time, I guess. > > > I use them both(PPTP and PPPoE) on every machine serving as access concentrator - and leave decision of "what to use" to the client side :). (btw there are PPPoE clients for win98 - RASPPPoE it was I think). From owner-freebsd-net@FreeBSD.ORG Thu Oct 28 17:35:40 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 0570916A4CF for ; Thu, 28 Oct 2004 17:35:40 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id D3BF643D39 for ; Thu, 28 Oct 2004 17:35:37 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 91E6F7A425; Thu, 28 Oct 2004 10:35:35 -0700 (PDT) Message-ID: <41812DE7.7020908@elischer.org> Date: Thu, 28 Oct 2004 10:35:35 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: "George V. Neville-Neil" References: <20041027073858.GC719@empiric.icir.org> <417FF6D6.4010201@elischer.org> <20041027195233.GC770@empiric.icir.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: Implementing IP_SENDIF (like SO_BINDTODEVICE) 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, 28 Oct 2004 17:35:40 -0000 George V. Neville-Neil wrote: >At Wed, 27 Oct 2004 12:52:33 -0700, >Bruce M Simpson wrote: > > >>On Wed, Oct 27, 2004 at 12:28:22PM -0700, Julian Elischer wrote: >> >> >>>>It annoys me that we have to resort to BPF to send IP datagrams on >>>>unnumbered interfaces. Here is a half baked idea. Please look and >>>>tell me what you think. >>>> >>>> >>>I've sent lots of datagrams on un-numberred interfaces using netgraph.. >>> >>> >>I should qualify my post a bit more: I began thinking along these lines >>with the intention of enabling ISC dhcp (and dhclient) to be compiled >>without using bpf support. I don't have the time or interest to port ISC >>dhcp to use netgraph, but I'd be interested to see the results if that >>happened. >> >> >> > >Just one quick question. Does the use of this option require root >privilege? I think it should :-) > netgraph requires root privs to set up a graph.. > >Later, >George >_______________________________________________ >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 Thu Oct 28 17:38: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 646D316A4CE for ; Thu, 28 Oct 2004 17:38:23 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 04A9443D53 for ; Thu, 28 Oct 2004 17:38:23 +0000 (GMT) (envelope-from adnichols@gmail.com) Received: by wproxy.gmail.com with SMTP id 44so260024wri for ; Thu, 28 Oct 2004 10:38:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=sJfnUcOzUg+vUN7mK3DrT1GVJx2jQoL0dvtOD12USmXq5UwcSIKfsumjztpjdBgqmIpxVNjw0uVKHHmdItFPvplyttD0TTSP4xLtAO3jztkXwhOGfhdqcR99s53rw16dtPGt+gNKXoP27IPA/ZzkNKx4C/YPAZKzttsxHIf6SfM= Received: by 10.54.35.64 with SMTP id i64mr135543wri; Thu, 28 Oct 2004 10:38:19 -0700 (PDT) Received: by 10.54.35.52 with HTTP; Thu, 28 Oct 2004 10:38:19 -0700 (PDT) Message-ID: Date: Thu, 28 Oct 2004 10:38:19 -0700 From: Aaron Nichols To: freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Problems with NAT on gif interface for VPN X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Aaron Nichols List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2004 17:38:23 -0000 All, I didn't get any hits on freebsd-questions so I'm re-posting this here. Any help is much appreciated. This is 4.10-RELEASE-p2. -- All, I'm having a problem getting nat to work on a gif interface. My goal here is to have a FreeBSD host (which is the gateway for a home network) connect to a VPN using a "client vpn" setup and masquerade (nat) the network behind the FreeBSD host using a single IP provided by the corporate VPN server. At this point I have racoon/ipfw/natd working to the point that I can pass traffic over the VPN from the FreeBSD host itself just fine. However, if I send traffic from a client on the LAN, it goes all the way across the VPN, I see the destination host send a response and I see the incoming ESP packet on the FreeBSD hosts wan interface, but I never see the packet sent out the LAN and I'm having trouble tracking where it is being dropped. If I perform a packet capture on gif0, I see neither the outgoing or incoming traffic, which seems incorrect to me since I do know the traffic is going out and is coming back when I initiate it from the FreeBSD host itself. I have started two natd processes bound to two different ports for divert use on each interface, they are shown below. Anyways, here are the details: Host A (FreeBSD) LAN: 192.168.1.1/24 WAN: a.b.c.d (dynamic IP from cable provider) Host B (VPN server) LAN: 10.1.8.12/24 (larger /8 behind this) WAN: w.x.y.z VPN client IP is 10.1.13.100 --- setkey -DP: w.x.y.z[any] a.b.c.d[any] ip4 in ipsec esp/tunnel/w.x.y.z-a.b.c.d/require spid=67 seq=3 pid=94282 refcnt=1 10.0.0.0/8[any] 10.1.13.100[any] any in ipsec esp/tunnel/w.x.y.z-a.b.c.d/require spid=69 seq=2 pid=94282 refcnt=1 a.b.c.d[any] w.x.y.z[any] ip4 out ipsec esp/tunnel/a.b.c.d-w.x.y.z/require spid=66 seq=1 pid=94282 refcnt=1 10.1.13.100[any] 10.0.0.0/8[any] any out ipsec esp/tunnel/a.b.c.d-w.x.y.z/require spid=68 seq=0 pid=94282 refcnt=1 --- Relevant routing entries Destination Gateway Flags Refs Use Netif Expire 10 10.1.8.12 UGSc 1 9098 gif0 10.1.8.12 10.1.13.100 UH 1 0 gif0 --- ifconfig: xl0: flags=8843 mtu 1500 inet6 fe80::260:8ff:fea5:d095%xl0 prefixlen 64 scopeid 0x1 inet a.b.c.d netmask 0xfffffe00 broadcast 255.255.255.255 ether 00:60:08:a5:d0:95 media: Ethernet autoselect (100baseTX ) status: active vr0: flags=8943 mtu 1500 inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255 inet6 fe80::250:8dff:fe5d:c6d%vr0 prefixlen 64 scopeid 0x2 inet 192.168.1.2 netmask 0xffffffff broadcast 192.168.1.2 ether 00:50:8d:5d:0c:6d media: Ethernet autoselect (100baseTX ) status: active gif0: flags=28151 mtu 1280 tunnel inet a.b.c.d --> w.x.y.z inet6 fe80::260:8ff:fea5:d095%gif0 prefixlen 64 scopeid 0x8 inet 10.1.13.100 --> 10.1.8.12 netmask 0xffffffff --- natd processes (latter is setup for debugging): /sbin/natd -dynamic -use_sockets -unregistered_only -n xl0 /sbin/natd -v -l -n gif0 -log_denied -p 8669 --- ipfw show (Yes, this set isn't that clean - it's been hacked up while trying to figure out this issue - please forgive any redundancies or ineficiencies you see unless they may impact this problem) 00100 1458262 852524563 divert 8668 ip from any to any via xl0 00200 3436 370488 divert 8669 ip from any to any via gif0 00300 0 0 check-state 00400 890895 403006370 allow ip from any to any keep-state out xmit xl0 00500 0 0 allow ip from any to any keep-state via gif0 00600 4 432 allow esp from any to any 00700 0 0 allow udp from any to me 500 in 00800 2770 5371008 allow ip from any to any via lo0 00900 1364895 918328465 allow ip from any to any keep-state via vr0 01000 6699 1015786 allow tcp from any to any 22 keep-state in 01100 44273 13145900 allow tcp from any to any 25 keep-state in 01200 3361 1924613 allow tcp from any to any 80 keep-state in 01300 392 26364 allow icmp from any to any 01400 55996 18161747 deny log ip from any to any 65535 104 11992 deny ip from any to any -- So, at this point when I send traffic from a machine on the LAN, I can confirm the following: NAT seems to work based on the debug output of natd: Out [ICMP] [ICMP] 192.168.1.101 -> 10.1.2.115 8(0) aliased to [ICMP] 10.1.13.100 -> 10.1.2.115 8(0) I see the icmp packet reach the other side of the VPN via tcpdump, and I see an icmp echo response sent back. If I sniff my xl0 interface while doing this I see the following: 11:03:34.093263 a.b.c.d > w.x.y.z: ESP(spi=0xa9c55011,seq=0x5) 11:03:34.128605 w.x.y.z > a.b.c.d.167: ESP(spi=0x0dcf2aab,seq=0x5) These packets correspond w/ the ICMP request/response I see on the other side of the VPN so I assume that 2nd ESP packet is the ping response. My problem is that I never see any icmp on gif0 (neither the ping request or response) and I never see the icmp response on vr0. Obviously the machine on the LAN never recieves it either. Questions: 1) Why would I not be seeing all traffic over the VPN on gif0? It doesn't seem likely that it's going via another interface because the source of traffic is correct and NAT seems to be working outbound, so I think I should see it. 2) Are there problems with my configuration which anyone can identify as preventing only the response traffic back into this network? If you need additional info I'm happy to provide it - but I thought this was a good (and definitely long enough) starting point. If there is another list better suited to answering this questions let me know. Thanks in advance, Aaron From owner-freebsd-net@FreeBSD.ORG Thu Oct 28 17: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 40D2C16A4CE for ; Thu, 28 Oct 2004 17:47:28 +0000 (GMT) Received: from mail.star-sw.com (mail.star-sw.com [217.195.82.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 469C743D41 for ; Thu, 28 Oct 2004 17:47:27 +0000 (GMT) (envelope-from nkritsky@star-sw.com) Received: from ARGON.star-sw.com (argon.star-sw.com [217.195.82.10]) by mail.star-sw.com (8.12.11/8.12.11) with ESMTP id i9SHlPcH017347; Thu, 28 Oct 2004 21:47:25 +0400 (MSD) Received: from ibmka.star-sw.com ([192.168.32.230]) by ARGON.star-sw.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 28 Oct 2004 21:47:25 +0400 Date: Thu, 28 Oct 2004 21:47:24 +0400 From: "Nickolay A. Kritsky" X-Mailer: The Bat! (v1.49) Personal X-Priority: 3 (Normal) Message-ID: <62721446609.20041028214724@star-sw.com> To: Aaron Nichols In-reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Oct 2004 17:47:25.0049 (UTC) FILETIME=[2F1BAE90:01C4BD16] cc: freebsd-net@freebsd.org Subject: Re: Problems with NAT on gif interface for VPN X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Nickolay A. Kritsky" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2004 17:47:28 -0000 Hello Aaron, Please make sure that you have option IPSEC_FILTERGIF in your kernel. See LINT and -net archives for more details. Thursday, October 28, 2004, 9:38:19 PM, Aaron Nichols wrote: AN> All, AN> I didn't get any hits on freebsd-questions so I'm re-posting this AN> here. Any help is much appreciated. This is 4.10-RELEASE-p2. AN> -- AN> All, AN> I'm having a problem getting nat to work on a gif interface. My AN> goal here is to have a FreeBSD host (which is the gateway for a home AN> network) connect to a VPN using a "client vpn" setup and masquerade AN> (nat) the network behind the FreeBSD host using a single IP provided AN> by the corporate VPN server. -- Best regards, ; Nickolay A. Kritsky ; SysAdmin STAR Software LLC ; mailto:nkritsky@star-sw.com From owner-freebsd-net@FreeBSD.ORG Thu Oct 28 19:51:10 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 ECF0E16A4CE for ; Thu, 28 Oct 2004 19:51:10 +0000 (GMT) Received: from segfault-outgoing-helo.monkeys.com (segfault.monkeys.com [66.60.159.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F64F43D39 for ; Thu, 28 Oct 2004 19:51:10 +0000 (GMT) (envelope-from rfg@monkeys.com) Received: from segfault-nmh-helo.monkeys.com (localhost [127.0.0.1]) by segfault.monkeys.com (Postfix) with ESMTP id CEDCF54A8 for ; Thu, 28 Oct 2004 12:51:09 -0700 (PDT) To: freebsd-net@freebsd.org Date: Thu, 28 Oct 2004 12:51:09 -0700 Message-ID: <89563.1098993069@monkeys.com> From: "Ronald F. Guilmette" Subject: Strange result (EPERM) from a call to connect(2) 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, 28 Oct 2004 19:51:11 -0000 I am testing a program that I am developing that makes quite a lot of simultaneous outbound TCP connections. While performing the testing, one of the calls to connect(2) within the program returned a -1 (error) result, and when the errno value was then checked, it had a value of EPERM. This is very unexpected and highly disconcerting. In the man page for connect(2) on the system I am using (4.10-RELEASE) there is no mention of the possibility of EPERM being a type of result that one might expect from a failed call to connect(2). So anyway, my questions: What conditions may cause connect(2) to yield EPERM on 4.10-RELEASE? What, if anything, can be done to mitigate or eliminate such error conditions? If there some sysctl variable or some kernel build-time variable that I could adjust that might possible eliminate this error, or at least cause it to be less common in practice? From owner-freebsd-net@FreeBSD.ORG Thu Oct 28 21:03: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 AA4F816A4CE for ; Thu, 28 Oct 2004 21:03:14 +0000 (GMT) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE19343D46 for ; Thu, 28 Oct 2004 21:03:13 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id 07F481F048; Thu, 28 Oct 2004 23:03:13 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id E1D9468DE; Thu, 28 Oct 2004 23:03:12 +0200 (CEST) Date: Thu, 28 Oct 2004 23:03:12 +0200 From: Marc Olzheim To: "Ronald F. Guilmette" Message-ID: <20041028210312.GA19693@stack.nl> References: <89563.1098993069@monkeys.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cWoXeonUoKmBZSoM" Content-Disposition: inline In-Reply-To: <89563.1098993069@monkeys.com> X-Operating-System: FreeBSD hammer.stack.nl 5.2-CURRENT FreeBSD 5.2-CURRENT X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.6i cc: freebsd-net@freebsd.org Subject: Re: Strange result (EPERM) from a call to connect(2) 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, 28 Oct 2004 21:03:14 -0000 --cWoXeonUoKmBZSoM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Oct 28, 2004 at 12:51:09PM -0700, Ronald F. Guilmette wrote: > What conditions may cause connect(2) to yield EPERM on 4.10-RELEASE? Being blocked by your own firewall is the one I can come up with... Marc --cWoXeonUoKmBZSoM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBgV6QezjnobFOgrERAoJoAKCc6XFoyivJhoq0Xda7QCfEVkdIWwCdG4LC AgSdKgGGeo9kvwV1SMenDSI= =ECYv -----END PGP SIGNATURE----- --cWoXeonUoKmBZSoM-- From owner-freebsd-net@FreeBSD.ORG Thu Oct 28 22:32: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 E423116A4CE; Thu, 28 Oct 2004 22:32:51 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id E4F7243D3F; Thu, 28 Oct 2004 22:32:50 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 13D676520C; Thu, 28 Oct 2004 23:32:49 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 97745-01; Thu, 28 Oct 2004 23:32:48 +0100 (BST) Received: from empiric.dek.spc.org (vernpaq.icir.org [192.150.187.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 36944651EE; Thu, 28 Oct 2004 23:32:43 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 1671A6247; Thu, 28 Oct 2004 15:32:30 -0700 (PDT) Date: Thu, 28 Oct 2004 15:32:29 -0700 From: Bruce M Simpson To: Gleb Smirnoff , Julian Elischer , freebsd-net@freebsd.org Message-ID: <20041028223229.GC2063@empiric.icir.org> Mail-Followup-To: Gleb Smirnoff , Julian Elischer , freebsd-net@freebsd.org References: <20041027073858.GC719@empiric.icir.org> <417FF6D6.4010201@elischer.org> <20041027195233.GC770@empiric.icir.org> <20041028114134.GC50262@cell.sick.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NtwzykIc2mflq5ck" Content-Disposition: inline In-Reply-To: <20041028114134.GC50262@cell.sick.ru> Subject: Re: Implementing IP_SENDIF (like SO_BINDTODEVICE) 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, 28 Oct 2004 22:32:52 -0000 --NtwzykIc2mflq5ck Content-Type: multipart/mixed; boundary="tqI+Z3u+9OQ7kwn0" Content-Disposition: inline --tqI+Z3u+9OQ7kwn0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Oct 28, 2004 at 03:41:34PM +0400, Gleb Smirnoff wrote: > ng_device can be attached to "orphans" hook of ng_ether. /dev/ngdX opened > by dhcpd, and packets processed. This seems to me like pure configuration overkill. It would require that people compile and load netgraph to run dhclient, and that the netgraph graph be created and populated correctly. > What is benefit to get rid of bpf? What is problem with it? IPV6_NEXTHOP is intended to support this for IPv6. It doesn't right now, it returns EAFNOSUPPORT. Please see my attached game plan. BMS --tqI+Z3u+9OQ7kwn0 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ip-unnumbered.txt" The story with FreeBSD and 'ip unnumbered' in IPv4 land - Multicast group membership - Dealt with in ip_multicast_if() (can specify ifIndex in 0/8 as per RFC1724 hack) - IP forwarding FIB - Routes can be specified with the rt_gate field set to an sockaddr_dl (AF_LINK) filled out only with an interface name and no RTF_GATEWAY or RTF_LLINFO flag set for an unnumbered serial interface. - For host mode, sending packets to destinations whose prefix and next-hop match such a route in the FIB are OK, but the source address may need to be explicitly specified (it may default to INADDR_ANY otherwise). - Unicast sends - Currently no way to explicitly send a udp datagram to such an interface without specifying a destination with a route pointing to that interface. - Running BGP over an unnumbered interface is possible. For an active session open, there has to be a route to one of the addresses configured on the remote peer which traverses the unnumbered interface, and this address must be specified during connect(). For a passive session open, it would probably require that net.inet.ip.check_interface is 0, so that incoming sessions can be accepted on the unnumbered interface for passive open. The IP address for the passive open (seen during accept() will of course have to correspond to one of the other addresses configured on the local host. - For a protocol which needs to send broadcasts via the existing unicast path and which cannot use multicast, there is no way of doing this in the current iteration of the code. TODO: - Add support for explicitly specifying the interface used during ip_output(). This would require SO_DONTROUTE and IP_SENDIF to be set. SO_BINDTODEVICE could be emulated. IP_SENDIF specified as a control message would be purely temporary and only necessary for an unconnected datagram socket send. The inpcb already has an interface index field for IPv6. This should be unravelled for IPv4 too. IP_SENDIF passed to setsockopt() would be like SO_BINDTODEVICE only instead of specifying an interface name, the interface index is specified and cached in the inpcb. SO_BINDTODEVICE would perform a lookup of the interface index by name, just like Linux, then perform the same action as IP_SENDIF when used as a socket option. This means calling ifunit() to resolve the name to an ifnet, then just cache ifnet->if_index in the inpcb. SO_BINDTODEVICE can either be implemented purely in the Linuxulator, or within src/sys/net/ itself. The actual hack in ip_output() would need to check if the interface had gone away, and if it had, drop the datagram - this stuff only takes effect if SO_DONTROUTE is specified. This is easily done... (SO_DONTROUTE of course implies IP_ROUTETOIF - they are defined to be identical). --tqI+Z3u+9OQ7kwn0-- --NtwzykIc2mflq5ck Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Comment: '' iD8DBQFBgXN8ueUpAYYNtTsRAqsvAJ9JK2Jjpe2wzXWyj+HjwFtW7TvP/wCgiv1L 8kTrLdrMgwGT8Cnz+9qkoa0= =sFOf -----END PGP SIGNATURE----- --NtwzykIc2mflq5ck-- From owner-freebsd-net@FreeBSD.ORG Thu Oct 28 23:02: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 692FC16A4CE; Thu, 28 Oct 2004 23:02:34 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A80343D3F; Thu, 28 Oct 2004 23:02:34 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 31633651F4; Fri, 29 Oct 2004 00:02:33 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 97625-06-3; Fri, 29 Oct 2004 00:02:32 +0100 (BST) Received: from empiric.dek.spc.org (vernpaq.icir.org [192.150.187.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 384E5651EB; Fri, 29 Oct 2004 00:02:32 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 3F2586247; Thu, 28 Oct 2004 16:02:23 -0700 (PDT) Date: Thu, 28 Oct 2004 16:02:23 -0700 From: Bruce M Simpson To: Gleb Smirnoff , Julian Elischer , freebsd-net@freebsd.org Message-ID: <20041028230223.GD2063@empiric.icir.org> Mail-Followup-To: Gleb Smirnoff , Julian Elischer , freebsd-net@freebsd.org References: <20041027073858.GC719@empiric.icir.org> <417FF6D6.4010201@elischer.org> <20041027195233.GC770@empiric.icir.org> <20041028114134.GC50262@cell.sick.ru> <20041028223229.GC2063@empiric.icir.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="84ND8YJRMFlzkrP4" Content-Disposition: inline In-Reply-To: <20041028223229.GC2063@empiric.icir.org> Subject: Re: Implementing IP_SENDIF (like SO_BINDTODEVICE) 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, 28 Oct 2004 23:02:34 -0000 --84ND8YJRMFlzkrP4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Looking at http://www.cisco.com/warp/public/701/20.html I notice a few differences. Seems to me that a route to one of the peer's other addresses is going to be needed, and that the supernet example given there might not work. --84ND8YJRMFlzkrP4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Comment: '' iD8DBQFBgXp+ueUpAYYNtTsRAkowAJ0Uv20lW2DSCMSZqI4L4iFifIUIRgCgidmy 8UQFq2FOlw/icgxzBULUTVs= =zEQD -----END PGP SIGNATURE----- --84ND8YJRMFlzkrP4-- From owner-freebsd-net@FreeBSD.ORG Fri Oct 29 01:32: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 51CB416A4CE; Fri, 29 Oct 2004 01:32:37 +0000 (GMT) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 380A043D1D; Fri, 29 Oct 2004 01:32:35 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) i9T1V9a2002222; Thu, 28 Oct 2004 18:31:09 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (pc1.oakwoodazabu1-unet.ocn.ne.jp [220.110.140.201]) by mail.meer.net (8.12.10/8.12.2/meer) with ESMTP id i9T1Ux6H093035; Thu, 28 Oct 2004 18:31:00 -0700 (PDT) (envelope-from gnn@neville-neil.com) Date: Fri, 29 Oct 2004 10:30:57 +0900 Message-ID: From: gnn@freebsd.org To: Gleb Smirnoff , Julian Elischer , freebsd-net@freebsd.org In-Reply-To: <20041028223229.GC2063@empiric.icir.org> References: <20041027073858.GC719@empiric.icir.org> <417FF6D6.4010201@elischer.org> <20041027195233.GC770@empiric.icir.org> <20041028114134.GC50262@cell.sick.ru> <20041028223229.GC2063@empiric.icir.org> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.5 Emacs/21.2 (powerpc-apple-darwin) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Subject: Re: Implementing IP_SENDIF (like SO_BINDTODEVICE) 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, 29 Oct 2004 01:32:37 -0000 At Thu, 28 Oct 2004 15:32:29 -0700, Bruce M Simpson wrote: > Please see my attached game plan. > I think it looks like a good plan. Unnumbered interfaces have other uses than dhclient and it would be good to have clean support for them. Later, George From owner-freebsd-net@FreeBSD.ORG Fri Oct 29 03:17: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 77DED16A4CE for ; Fri, 29 Oct 2004 03:17:38 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id F3FA843D49 for ; Fri, 29 Oct 2004 03:17:37 +0000 (GMT) (envelope-from adnichols@gmail.com) Received: by wproxy.gmail.com with SMTP id 64so584007wri for ; Thu, 28 Oct 2004 20:17:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=UddPe/zEdqWI+H0yw2zoGOnzkqzk4BN4lHHbjICggOeFBQ4/k2kWi0MZp0dnrVMTsgf9sQxXv0wxBIGXmfo69lbtmg4QmuePl3/61ZPS+5HycfVqtEZPRZNo6YpFAEvix2MpIjGyEAjpoLhmvWLhJbMN1pgJCFns6P/2G7Hbd6k= Received: by 10.54.26.24 with SMTP id 24mr149830wrz; Thu, 28 Oct 2004 20:17:30 -0700 (PDT) Received: by 10.54.35.52 with HTTP; Thu, 28 Oct 2004 20:17:30 -0700 (PDT) Message-ID: Date: Thu, 28 Oct 2004 20:17:30 -0700 From: Aaron Nichols To: "Nickolay A. Kritsky" In-Reply-To: <62721446609.20041028214724@star-sw.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <62721446609.20041028214724@star-sw.com> cc: freebsd-net@freebsd.org Subject: Re: Problems with NAT on gif interface for VPN X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Aaron Nichols List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2004 03:17:38 -0000 On Thu, 28 Oct 2004 21:47:24 +0400, Nickolay A. Kritsky wrote: > Hello Aaron, > > Please make sure that you have option IPSEC_FILTERGIF in your kernel. > See LINT and -net archives for more details. Thanks for the hint - and that makes more sense, however I think I'm still in the same position. Rather than a "problem" with ipfw however, I think I've got a fundamental problem with how to do this. If I understand correctly, in order for natd to "reverse" a divert rule (translate the destination IP back to the original IP on return traffic) the packet has to come through the same interface it was originally seen by natd on - is this correct? For whatever reason I still seem to be unable to use gif0 for this purpose, which seems to be the closest thing to an "ipsec interface" available (I'm beginning to think it's nowhere near as useful as enc0 on OpenBSD). Thus, I'm stuck translating packets when they either enter the LAN interface or leave the WAN, the former seems the best option. The problem I have however, is that if I apply the divert rule on vr0 (LAN) then the return traffic is never transmitted out vr0 and thus never gets translated back (I assume it's dropped somewhere earlier in the process). I tried using a 'fwd' rule to push return traffic out vr0 on the return trip but that seems to have been fruitless. On Cisco routers I know you can do some interesting nat tricks by using policy routing and forcing VPN traffic to an intermediate loopback interface so that all VPN traffic goes in/out the same interface before being delivered to its ultimate destination. Can I do something similar on FreeBSD? For example: Lan to Remote site: PC -> vr0 -> some_int0 -> ipsec -> xl0 ... Remote site reponse traffic: xl0 -> ipsec -> some_int0 -> vr0 -> PC Thus, all traffic would go in/out of 'some_int0' and I could apply divert rules there correctly. I apologize if this doesn't make any sense to those who understand the system - evidently I don't have a strong enough understand of the processing order to piece this together myself. At this point I think the relevant question is - does anyone know if this is possible and have any pointers to a working configuration? Thanks again for your time and patience. Aaron From owner-freebsd-net@FreeBSD.ORG Fri Oct 29 12:35:26 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 D9F8716A4D5 for ; Fri, 29 Oct 2004 12:35:26 +0000 (GMT) Received: from mutare.noc.clara.net (mutare.noc.clara.net [195.8.70.95]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F64043D31 for ; Fri, 29 Oct 2004 12:35:07 +0000 (GMT) (envelope-from ollie@mutare.noc.clara.net) Received: from ollie by mutare.noc.clara.net with local (Exim 4.43) id 1CNVyE-0008Be-EV for freebsd-net@freebsd.org; Fri, 29 Oct 2004 13:35:06 +0100 Date: Fri, 29 Oct 2004 13:35:06 +0100 From: Ollie Cook To: freebsd-net@freebsd.org Message-ID: <20041029123506.GG19662@mutare.noc.clara.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.10-STABLE i386 X-NCC-RegID: uk.claranet Sender: Ollie Cook Subject: Efficient copying between sockets 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, 29 Oct 2004 12:35:27 -0000 Good afternoon, I am currently writing a potentially high bandwidth (think fileserver) application which will proxy data from one PF_INET socket to another (no reason it has to be PF_INET, but that's how the application stands). At the moment this is implemented as follows (in pseudo-C; no error-checking for brevity and clarity): written_bytes = 0; read_bytes = read(sock_src, buffer, sz_buffer); while (written_bytes < read_bytes) written_bytes -= write(sock_dst, buffer, read_bytes - written_bytes) I am wondering if there is a more efficient approach to this which might avoid copying data into a userspace buffer, and then writing it back to the kernel? In actual fact, I know in advance exactly how many bytes need to be copied from one socket to the other, so if there was any way of doing something like: socket_redirect(sock_src, sock_dst, bytes_to_copy); it would be ideal. However I'd be very surprised if such a trivial way to do that did actually exist. If anyone has any advice at all on a more efficient way to copy data between sockets I'd be very glad to hear about it. The software is very much prototype at the moment, but I'd like to make it as efficient as possible from the beginning and this seems like a prime area for optimisation. Yours, Ollie -- Ollie Cook Systems Architect, Claranet UK ollie@uk.clara.net +44 20 7685 8065 From owner-freebsd-net@FreeBSD.ORG Fri Oct 29 14:14:09 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 BCD4416A4CE for ; Fri, 29 Oct 2004 14:14:09 +0000 (GMT) Received: from smtp.cegetel.net (mf00.sitadelle.com [212.94.174.77]) by mx1.FreeBSD.org (Postfix) with ESMTP id 894C843D31 for ; Fri, 29 Oct 2004 14:14:09 +0000 (GMT) (envelope-from tataz@sitadelle.com) Received: from droopy.tech.sitadelle.com (213-223-184-193.dti.cegetel.net [213.223.184.193]) by smtp.cegetel.net (Postfix) with ESMTP id 1D46C672A0; Fri, 29 Oct 2004 16:14:07 +0200 (CEST) Received: by droopy.tech.sitadelle.com (Postfix, from userid 1000) id 2167AFC00E; Fri, 29 Oct 2004 16:14:11 +0200 (CEST) Date: Fri, 29 Oct 2004 16:14:11 +0200 From: Jeremie Le Hen To: Aaron Nichols Message-ID: <20041029141411.GE10641@sitadelle.com> References: <62721446609.20041028214724@star-sw.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i cc: freebsd-net@freebsd.org Subject: Re: Problems with NAT on gif interface for VPN 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, 29 Oct 2004 14:14:09 -0000 > Rather than a "problem" with ipfw however, I think I've got a > fundamental problem with how to do this. If I understand correctly, in > order for natd to "reverse" a divert rule (translate the destination > IP back to the original IP on return traffic) the packet has to come > through the same interface it was originally seen by natd on - is this > correct? > > For whatever reason I still seem to be unable to use gif0 for this > purpose, which seems to be the closest thing to an "ipsec interface" > available (I'm beginning to think it's nowhere near as useful as enc0 > on OpenBSD). Thus, I'm stuck translating packets when they either > enter the LAN interface or leave the WAN, the former seems the best > option. IIRC, I read somewhere this is precisely the reason why enc(4) was written. -- Jeremie Le Hen jeremie@le-hen.org From owner-freebsd-net@FreeBSD.ORG Fri Oct 29 15:05: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 358F716A4CE for ; Fri, 29 Oct 2004 15:05:47 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id ADF9343D53 for ; Fri, 29 Oct 2004 15:05:46 +0000 (GMT) (envelope-from adnichols@gmail.com) Received: by wproxy.gmail.com with SMTP id 57so695520wri for ; Fri, 29 Oct 2004 08:05:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=C22yxwrkuf1r0bDeqre7ML3NgJI0IGd70IrFLZnSvIY7tWpdBdyZY0XPCMKlrl8w8/qwYjUBtMKH6pq9Yq3C3ixxH3JL1a6gjavCxmRTtS+IFo3dyerRCEhdi10ulBGZxtw88QV9/fM1RzcWyVIH8EgAgnopHSK8E8sNaPuiOkk= Received: by 10.54.35.64 with SMTP id i64mr165284wri; Fri, 29 Oct 2004 08:05:46 -0700 (PDT) Received: by 10.54.35.52 with HTTP; Fri, 29 Oct 2004 08:05:46 -0700 (PDT) Message-ID: Date: Fri, 29 Oct 2004 08:05:46 -0700 From: Aaron Nichols To: Jeremie Le Hen In-Reply-To: <20041029141411.GE10641@sitadelle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <62721446609.20041028214724@star-sw.com> <20041029141411.GE10641@sitadelle.com> cc: freebsd-net@freebsd.org Subject: Re: Problems with NAT on gif interface for VPN X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Aaron Nichols List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2004 15:05:47 -0000 On Fri, 29 Oct 2004 16:14:11 +0200, Jeremie Le Hen wrote: > IIRC, I read somewhere this is precisely the reason why enc(4) was > written. Yep, that seems to be exactly what I need. I don't suppose there are any plans to implement something similar in FreeBSD anytime soon? Considering I'm so close to getting this to work it's frustrating to think that I would need to migrate to OpenBSD to have this functionality and uproot everything else this server already does (mail, dns, web, etc). Bummer. Thanks for all your help Aaron From owner-freebsd-net@FreeBSD.ORG Fri Oct 29 16:28: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 735DF16A4CE for ; Fri, 29 Oct 2004 16:28:11 +0000 (GMT) Received: from segfault-outgoing-helo.monkeys.com (segfault.monkeys.com [66.60.159.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 40DD743D41 for ; Fri, 29 Oct 2004 16:28:11 +0000 (GMT) (envelope-from rfg@monkeys.com) Received: from segfault-nmh-helo.monkeys.com (localhost [127.0.0.1]) by segfault.monkeys.com (Postfix) with ESMTP id 9836654A8; Fri, 29 Oct 2004 09:28:10 -0700 (PDT) To: Marc Olzheim In-reply-to: Your message of Thu, 28 Oct 2004 23:03:12 +0200. <20041028210312.GA19693@stack.nl> Date: Fri, 29 Oct 2004 09:28:10 -0700 Message-ID: <79488.1099067290@monkeys.com> From: "Ronald F. Guilmette" cc: freebsd-net@freebsd.org Subject: Re: Strange result (EPERM) from a call to connect(2) 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, 29 Oct 2004 16:28:11 -0000 In message <20041028210312.GA19693@stack.nl>, you wrote: >On Thu, Oct 28, 2004 at 12:51:09PM -0700, Ronald F. Guilmette wrote: >> What conditions may cause connect(2) to yield EPERM on 4.10-RELEASE? > >Being blocked by your own firewall is the one I can come up with... YES! Thank you for pointing this out. It was non-obvious, at least to me. P.S. I misspoke earlier when I said that I was getting EPERM errors. Rather, my program was printing the error message "Permission denied", which I interpreted to be equivalent to EPERM. But I see now that that was incorrect. The actual synbolic error code associated with that specific error string is "EACCES" (errno=13). From owner-freebsd-net@FreeBSD.ORG Fri Oct 29 20: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 0D8B616A4CE for ; Fri, 29 Oct 2004 20:45:16 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9EAE43D2F for ; Fri, 29 Oct 2004 20:45:15 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id D44187A403; Fri, 29 Oct 2004 13:45:15 -0700 (PDT) Message-ID: <4182ABDB.7040104@elischer.org> Date: Fri, 29 Oct 2004 13:45:15 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Ollie Cook References: <20041029123506.GG19662@mutare.noc.clara.net> In-Reply-To: <20041029123506.GG19662@mutare.noc.clara.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: Efficient copying between sockets 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, 29 Oct 2004 20:45:16 -0000 Ollie Cook wrote: >Good afternoon, > >I am currently writing a potentially high bandwidth (think fileserver) >application which will proxy data from one PF_INET socket to another (no reason >it has to be PF_INET, but that's how the application stands). > >At the moment this is implemented as follows (in pseudo-C; no error-checking >for brevity and clarity): > > written_bytes = 0; > read_bytes = read(sock_src, buffer, sz_buffer); > while (written_bytes < read_bytes) > written_bytes -= write(sock_dst, buffer, read_bytes - written_bytes) > >I am wondering if there is a more efficient approach to this which might avoid >copying data into a userspace buffer, and then writing it back to the kernel? > you can do it entirely in the kernel if you write a program to configure two netgraph ksockets to each other > >In actual fact, I know in advance exactly how many bytes need to be copied from >one socket to the other, so if there was any way of doing something like: > > socket_redirect(sock_src, sock_dst, bytes_to_copy); > >it would be ideal. However I'd be very surprised if such a trivial way to do >that did actually exist. > >If anyone has any advice at all on a more efficient way to copy data between >sockets I'd be very glad to hear about it. The software is very much prototype >at the moment, but I'd like to make it as efficient as possible from the >beginning and this seems like a prime area for optimisation. > >Yours, > >Ollie > > > From owner-freebsd-net@FreeBSD.ORG Sat Oct 30 06:28: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 D626E16A4CE; Sat, 30 Oct 2004 06:28:00 +0000 (GMT) Received: from fep18.inet.fi (fep18.inet.fi [194.251.242.243]) by mx1.FreeBSD.org (Postfix) with ESMTP id 959A743D1D; Sat, 30 Oct 2004 06:27:56 +0000 (GMT) (envelope-from ari@suutari.iki.fi) Received: from mato.dyndns.suutari.iki.fi ([80.222.160.96]) by fep18.inet.fi with ESMTP <20041030062754.CNVC16862.fep18.inet.fi@mato.dyndns.suutari.iki.fi>; Sat, 30 Oct 2004 09:27:54 +0300 Received: from instant.lemi.suutari.iki.fi (instant.lemi.suutari.iki.fi [192.168.53.130])i9U6RrhI004722; Sat, 30 Oct 2004 09:27:54 +0300 (EEST) (envelope-from ari@suutari.iki.fi) From: Ari Suutari To: freebsd-net@freebsd.org Date: Sat, 30 Oct 2004 09:27:50 +0300 User-Agent: KMail/1.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200410300927.51286.ari@suutari.iki.fi> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.5.6 (mato.dyndns.suutari.iki.fi [80.222.160.96]); Sat, 30 Oct 2004 09:27:54 +0300 (EEST) cc: freebsd-current@freebsd.org Subject: ipfw and ipsec processing order for outgoing packets wrong 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, 30 Oct 2004 06:28:01 -0000 Hi, I noticed that processing order of ipsec and ipfw (pfil_hook) is not correct for outgoing packets. Currently, ipsec processing is done first, which makes packets to go through without firewall inspection. This might be a security problem for someone, but at least it breaks stateful rule handling. My test setup is (all freebsd 5.3-rc1 machines): freebsd laptop <-> ipsec tunnel <->freebsd server When server sends packet to laptop, it now goes like this: ip_output -> ipsec -> ip_output -> ipfw -> network It should go like this: ip_output -> ipfw -> ipsec -> ip_output -> ipfw -> network I think that this could be fixed by just moving pfil_hook processing in ip_output before ipsec processing. Ari S. From owner-freebsd-net@FreeBSD.ORG Sat Oct 30 21:42:15 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 B868916A4CE for ; Sat, 30 Oct 2004 21:42:15 +0000 (GMT) Received: from bps.jodocus.org (g157016.upc-g.chello.nl [80.57.157.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id CCB9743D2D for ; Sat, 30 Oct 2004 21:42:14 +0000 (GMT) (envelope-from joost@jodocus.org) Received: from jodocus.org (localhost [127.0.0.1]) by bps.jodocus.org (8.13.1/8.13.1) with ESMTP id i9ULgDuU001958; Sat, 30 Oct 2004 23:42:13 +0200 (CEST) (envelope-from joost@jodocus.org) Received: (from joost@localhost) by jodocus.org (8.13.1/8.13.1/Submit) id i9ULgCum001957; Sat, 30 Oct 2004 23:42:12 +0200 (CEST) (envelope-from joost) Date: Sat, 30 Oct 2004 23:42:12 +0200 From: Joost Bekkers To: Ari Suutari Message-ID: <20041030214212.GA1737@bps.jodocus.org> Mail-Followup-To: Joost Bekkers , Ari Suutari , freebsd-net@freebsd.org References: <200410300927.51286.ari@suutari.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200410300927.51286.ari@suutari.iki.fi> User-Agent: Mutt/1.4.2.1i cc: freebsd-net@freebsd.org Subject: Re: ipfw and ipsec processing order for outgoing packets wrong 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, 30 Oct 2004 21:42:15 -0000 On Sat, Oct 30, 2004 at 09:27:50AM +0300, Ari Suutari wrote: > Hi, > > I noticed that processing order of ipsec and ipfw (pfil_hook) is not > correct for outgoing packets. Currently, ipsec processing is done first, > which makes packets to go through without firewall inspection. > This might be a security problem for someone, but at least it > breaks stateful rule handling. > > My test setup is (all freebsd 5.3-rc1 machines): > > freebsd laptop <-> ipsec tunnel <->freebsd server > > When server sends packet to laptop, it now goes like this: > > ip_output -> ipsec -> ip_output -> ipfw -> network > > It should go like this: > > ip_output -> ipfw -> ipsec -> ip_output -> ipfw -> network > > I think that this could be fixed by just moving pfil_hook > processing in ip_output before ipsec processing. > I've been pondering the same issue and am currently running 5.3-R modified in the way you've described. (diff at http://jodocus.org/ipsec-pfil.diff I'm not an experienced kernel-hacker, so use at own risk) For IPSEC this also means that the resulting ESP and AH packets don't traverse the firewall when leaving the system. (at least if I read the code correctly; not tested) With FAST_IPSEC both the original and the resulting ESP/AH packets traverse the firewall. In my case I also stumbled on a nice FAST_IPSEC feature where the decoded packets seemed to arrive through the corresponding gif* interface. (with tunnel-mode ipsec) -- greetz Joost joost@jodocus.org