From owner-freebsd-net@FreeBSD.ORG Sun Mar 6 11:04:33 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 63FD316A4CE for ; Sun, 6 Mar 2005 11:04:33 +0000 (GMT) Received: from te-clan.ch (ns1.te-clan.ch [217.118.194.40]) by mx1.FreeBSD.org (Postfix) with SMTP id 9597443D54 for ; Sun, 6 Mar 2005 11:04:32 +0000 (GMT) (envelope-from bachi@te-clan.ch) Received: (qmail 66674 invoked from network); 6 Mar 2005 11:03:49 -0000 Received: from unknown (HELO notebook.bachi.net) (80.219.63.44) by te-clan.ch with SMTP; 6 Mar 2005 11:03:49 -0000 From: Andreas Bachmann To: freebsd-net@freebsd.org Content-Type: text/plain Date: Sun, 06 Mar 2005 12:04:27 +0100 Message-Id: <1110107067.2060.26.camel@notebook.bachi.net> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: static pid and uid for a socket? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2005 11:04:33 -0000 hi! can a socket, which created by a user over a process (xfile.xf_uid, xfile.xf_pid), suddenly have another user or another process (maybee with setuid() or fork()) or does the socket clone? greets Andreas Bachmann From owner-freebsd-net@FreeBSD.ORG Sun Mar 6 11:36:09 2005 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 27AEC16A4CE for ; Sun, 6 Mar 2005 11:36:09 +0000 (GMT) Received: from kane.otenet.gr (kane.otenet.gr [195.170.0.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB42C43D41 for ; Sun, 6 Mar 2005 11:36:07 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from gothmog.gr (patr530-a102.otenet.gr [212.205.215.102]) j26BZo2T016004; Sun, 6 Mar 2005 13:35:51 +0200 Received: from gothmog.gr (gothmog [127.0.0.1]) by gothmog.gr (8.13.3/8.13.3) with ESMTP id j26Ba2NZ072960; Sun, 6 Mar 2005 13:36:02 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Received: (from giorgos@localhost) by gothmog.gr (8.13.3/8.13.3/Submit) id j26Ba280072959; Sun, 6 Mar 2005 13:36:02 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Date: Sun, 6 Mar 2005 13:36:02 +0200 From: Giorgos Keramidas To: Andreas Bachmann Message-ID: <20050306113602.GA72592@gothmog.gr> References: <1110107067.2060.26.camel@notebook.bachi.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1110107067.2060.26.camel@notebook.bachi.net> cc: freebsd-net@freebsd.org Subject: Re: static pid and uid for a socket? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2005 11:36:09 -0000 On 2005-03-06 12:04, Andreas Bachmann wrote: > can a socket, which created by a user over a process (xfile.xf_uid, > xfile.xf_pid), suddenly have another user or another process (maybee > with setuid() or fork()) or does the socket clone? AFAIK, this can only be done if the original process calls execve() on a setuid binary and has not marked the socket descriptor as close-on-exec. From owner-freebsd-net@FreeBSD.ORG Sun Mar 6 11:51:52 2005 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 C7A9516A4CE for ; Sun, 6 Mar 2005 11:51:52 +0000 (GMT) Received: from web20825.mail.yahoo.com (web20825.mail.yahoo.com [216.136.227.164]) by mx1.FreeBSD.org (Postfix) with SMTP id 6F64F43D46 for ; Sun, 6 Mar 2005 11:51:52 +0000 (GMT) (envelope-from stefanolteanu@yahoo.com) Received: (qmail 42107 invoked by uid 60001); 6 Mar 2005 11:51:52 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=yWMbYuvUXfyE2bW7WFUH2wyuqKaaF6CXYmnbhfJvp2CyHu2nFdHxpaIim62azL6Dtz7bOQHXiUL6Ag2g7mz5XQiSaxVGNT9CufjLvMzYnMQNKO07t6moha8ui6DAY30pyZzwNYt9/pal05Y2g7+TPuSGKUdL1gIzFeNqrH0vGJA= ; Message-ID: <20050306115152.42105.qmail@web20825.mail.yahoo.com> Received: from [213.154.146.174] by web20825.mail.yahoo.com via HTTP; Sun, 06 Mar 2005 03:51:52 PST Date: Sun, 6 Mar 2005 03:51:52 -0800 (PST) From: Stefan Olteanu To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Kernel panic with pfil 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, 06 Mar 2005 11:51:52 -0000 Hi everyone, I have a FreeBSD firewall. I get this fatal trap while in kernel mode. I experienced this every time I use dc++ on my pc from the private network. ------------------------- 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-RELEASE #0: Sun Mar 6 06:05:00 EET 2005 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/FIREWALL3 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Pentium/P55C (199.91-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x543 Stepping = 3 Features=0x8001bf real memory = 33554432 (32 MB) avail memory = 27553792 (26 MB) Intel Pentium detected, installing workaround for F00F bug npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xfc08-0xfc0b on acpi0 cpu0: on acpi0 acpi_tz0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 rl0: port 0x1000-0x10ff mem 0x44000000-0x440000ff irq 11 at device 12.0 on pci0 miibus0: on rl0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:40:f4:b2:f9:bd rl1: port 0x1400-0x14ff mem 0x44100000-0x441000ff irq 11 at device 13.0 on pci0 miibus1: on rl1 rlphy1: on miibus1 rlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl1: Ethernet address: 00:40:f4:b2:fe:f4 pci0: at device 14.0 (no driver attached) tl0: port 0x1820-0x182f irq 11 at device 16.0 on pci0 miibus2: on tl0 lxtphy0: on miibus2 lxtphy0: 100baseFX, 100baseFX-FDX, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto tlphy0: on miibus2 tlphy0: 10base2/BNC, 10base5/AUI tl0: Ethernet address: 00:80:5f:63:e0:80 tl0: if_start running deferred for Giant tl0: [GIANT-LOCKED] isab0: at device 20.0 on pci0 isa0: on isab0 atapci0: port 0x1830-0x183f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 20.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 uhci0: port 0x1800-0x181f at device 20.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 pci0: at device 20.3 (no driver attached) acpi_button0: on acpi0 speaker0: port 0x61 on acpi0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] ppc0: port 0x778-0x77d,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sio0: port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A fdc0: port 0x3f0-0x3f5 irq 6 drq 2 on acpi0 fdc0: [FAST] sio1: port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A orm0: at iomem 0xe7000-0xeffff,0xe0000-0xe6fff,0xc0000-0xc7fff 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 199905462 Hz quality 800 Timecounters tick every 10.000 msec ad0: 6150MB [13330/15/63] at ata0-master UDMA33 Mounting root from ufs:/dev/ad0s1a WARNING: / was not properly dismounted WARNING: /tmp was not properly dismounted WARNING: /usr was not properly dismounted WARNING: /var was not properly dismounted IP Filter: v3.4.35 initialized. Default = pass all, Logging = enabled tl0: adapter check: 100007 ---------------------------------------------------------------------------- Here is my backtrace output : Script started on Sun Mar 6 12:22:29 2005 [root@ crash]# gdb6 -k kernel.debug.0 vmcore.0 GNU gdb 20040803 [GDB v6.x for 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-portbld-freebsd5.3"... panic: from debugger panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0xc fault code = supervisor read, page not present instruction pointer = 0x8:0xc04f4c5c stack pointer = 0x10:0xc3eb7aec frame pointer = 0x10:0xc3eb7af8 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 29 (swi1: net) panic: from debugger Uptime: 13m22s Dumping 32 MB 16 --- #0 doadump () at pcpu.h:159 159 pcpu.h: No such file or directory. in pcpu.h doadump () at pcpu.h:159 159 in pcpu.h (kgdb) where #0 doadump () at pcpu.h:159 #1 0xc04c1ad5 in boot (howto=260) at ../../../kern/kern_shutdown.c:397 #2 0xc04c1dbd in panic (fmt=0xc0617bb0 "from debugger") at ../../../kern/kern_shutdown.c:553 #3 0xc0438959 in db_panic (addr=-1068544932, have_addr=0, count=-1, modif=0xc3eb791c "") at ../../../ddb/db_command.c:435 #4 0xc04388f0 in db_command (last_cmdp=0xc066c4c4, cmd_table=0x0, aux_cmd_tablep=0xc063cc54, aux_cmd_tablep_end=0xc063cc58) at ../../../ddb/db_command.c:349 #5 0xc04389b8 in db_command_loop () at ../../../ddb/db_command.c:455 #6 0xc043a52d in db_trap (type=12, code=0) at ../../../ddb/db_main.c:221 #7 0xc04d913a in kdb_trap (type=12, code=0, tf=0xc3eb7aac) at ../../../kern/subr_kdb.c:418 #8 0xc05f6cc9 in trap_fatal (frame=0xc3eb7aac, eva=12) at ../../../i386/i386/trap.c:804 #9 0xc05f6a4f in trap_pfault (frame=0xc3eb7aac, usermode=0, eva=12) at ../../../i386/i386/trap.c:727 #10 0xc05f664d in trap (frame= {tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = 56, tf_esi = 0, tf_ebp = -1007977736, tf_isp = -1007977768, tf_ebx = 0, tf_edx = 0, tf_ecx = 0, tf_eax = 3469992, tf_trapno = 12, tf_err = 0, tf_eip = -1068544932, tf_cs = 8, tf_eflags = 66050, tf_esp = 1, tf_ss = -1055494464}) at ../../../i386/i386/trap.c:417 #11 0xc05e6afa in calltrap () at ../../../i386/i386/exception.s:140 #12 0x00000018 in ?? () #13 0x00000010 in ?? () #14 0x00000010 in ?? () #15 0x00000038 in ?? () #16 0x00000000 in ?? () #17 0xc3eb7af8 in ?? () #18 0xc3eb7ad8 in ?? () #19 0x00000000 in ?? () #20 0x00000000 in ?? () #21 0x00000000 in ?? () #22 0x0034f2a8 in ?? () #23 0x0000000c in ?? () #24 0x00000000 in ?? () #25 0xc04f4c5c in m_copydata (m=0x0, off=0, len=56, cp=0xc1166ec0 "") at ../../../kern/uipc_mbuf.c:513 #26 0xc0ea0ac9 in ?? () #27 0xc0e18d00 in ?? () #28 0x00000000 in ?? () #29 0x00000038 in ?? () #30 0xc1166ec0 in ?? () #31 0x00000000 in ?? () #32 0xc3eb7bd8 in ?? () #33 0x00000038 in ?? () #34 0xc3eb7b94 in ?? () #35 0xc0ea095f in ?? () #36 0x00000000 in ?? () #37 0xc3eb7bd8 in ?? () #38 0xc3eb7b50 in ?? () #39 0xc3eb7b48 in ?? () #40 0xc3eb7b40 in ?? () #41 0x00000002 in ?? () #42 0xc0d8c000 in ?? () #43 0x00000000 in ?? () #44 0x00000001 in ?? () #45 0x00000028 in ?? () #46 0x00000038 in ?? () #47 0xc3eb7b58 in ?? () #48 0xc0e18d00 in ?? () #49 0x00000000 in ?? () #50 0x00306c72 in ?? () #51 0x00000000 in ?? () #52 0x00000000 in ?? () #53 0x00000000 in ?? () #54 0xffff3800 in ?? () #55 0x0000000c in ?? () #56 0x00000000 in ?? () #57 0x00004019 in ?? () #58 0x00000000 in ?? () #59 0x0000000c in ?? () #60 0xc3eb7bdc in ?? () #61 0x00004019 in ?? () #62 0xc0ebc800 in ?? () #63 0xc0e18d50 in ?? () #64 0xc3eb7c44 in ?? () #65 0xc0ea4280 in ?? () #66 0x00004019 in ?? () #67 0xc0e18d50 in ?? () #68 0xc3eb7bd8 in ?? () #69 0xc0e18d00 in ?? () #70 0xffffffff in ?? () #71 0x00000000 in ?? () #72 0x00000000 in ?? () #73 0xc0e18d00 in ?? () #74 0x00000000 in ?? () #75 0xc0ebe600 in ?? () #76 0x00000004 in ?? () #77 0x00000041 in ?? () #78 0x00000000 in ?? () #79 0xc0ea9740 in ?? () #80 0x00000000 in ?? () #81 0xc0d8c000 in ?? () #82 0x013ec004 in ?? () #83 0x8ac213c1 in ?? () #84 0x00000000 in ?? () #85 0x00000000 in ?? () #86 0x00000000 in ?? () #87 0xd5662ac2 in ?? () #88 0x00000000 in ?? () #89 0x00000000 in ?? () #90 0x00000000 in ?? () #91 0x00000000 in ?? () #92 0x00000000 in ?? () #93 0x00000003 in ?? () #94 0x00000000 in ?? () #95 0x00000014 in ?? () #96 0x00000000 in ?? () #97 0x0000000c in ?? () #98 0x00000000 in ?? () #99 0xc0ebe600 in ?? () #100 0xc0e1a844 in ?? () #101 0x000000b5 in ?? () #102 0x48fb00a1 in ?? () #103 0x00000000 in ?? () #104 0xc3eb7c80 in ?? () #105 0xc0e7a140 in ?? () #106 0xc067cee0 in ip_rsvpd () #107 0x00000001 in ?? () #108 0xc3eb7c60 in ?? () #109 0xc0ea0d06 in ?? () #110 0xc0e18d50 in ?? () #111 0x00000014 in ?? () #112 0xc0d8c000 in ?? () #113 0x00000000 in ?? () #114 0xc3eb7c80 in ?? () #115 0xc3eb7c90 in ?? () #116 0xc0532f7f in pfil_run_hooks (ph=0xc1166ec0, mp=0xc3eb7bd8, ifp=0xc3eb7b50, dir=-1055494528, inp=0xc3eb7b40) at ../../../net/pfil.c:137 Previous frame inner to this frame (corrupt stack?) (kgdb) ------------------------------------------------------------------------------- Here is my ipf.rules : ################################################################# # Outside Interface ################################################################# pass out quick on rl0 proto tcp from any to any keep state pass out quick on rl0 proto udp from any to any keep state pass out quick on rl0 proto icmp from any to any keep state block out quick on rl0 all #----------------------------------------------------------------------- # Block all inbound traffic from non-routable or reserved address spaces #----------------------------------------------------------------------- block in log quick on rl0 from 192.168.0.0/16 to any #RFC 1918 private IP block in log quick on rl0 from 172.16.0.0/12 to any #RFC 1918 private IP block in log quick on rl0 from 10.0.0.0/8 to any #RFC 1918 private IP block in log quick on rl0 from 127.0.0.0/8 to any #loopback block in log quick on rl0 from 0.0.0.0/8 to any #loopback block in log quick on rl0 from 169.254.0.0/16 to any #DHCP auto-config block in log quick on rl0 from 192.0.2.0/24 to any #reserved for doc's block in log quick on rl0 from 204.152.64.0/23 to any #Sun cluster interconnect block in quick on rl0 from 224.0.0.0/3 to any #Class D & E multicast #---------------------------------------------------------------- # Allow bootp traffic in from your ISP's DHCP server only. #---------------------------------------------------------------- pass in quick on rl0 proto udp from 194.42.102.129/32 to any port = 68 keep state block return-rst in log quick on rl0 proto tcp from any to any block return-icmp-as-dest(port-unr) in log quick on rl0 proto udp from any to any block in log quick on rl0 all ################################################################# # Inside Interface ################################################################# #---------------------------------------------------------------- # Allow out all TCP, UDP, and ICMP traffic & keep state #---------------------------------------------------------------- pass out quick on rl1 proto tcp from any to any keep state pass out quick on rl1 proto udp from any to any keep state pass out quick on rl1 proto icmp from any to any keep state block out quick on rl1 all pass out quick on tl0 proto tcp from any to any keep state pass out quick on tl0 proto udp from any to any keep state pass out quick on tl0 proto icmp from any to any keep state block out quick on tl0 all #---------------------------------------------------------------- # Allow in all TCP, UDP, and ICMP traffic & keep state #---------------------------------------------------------------- pass in quick on rl1 proto tcp from any to any keep state pass in quick on rl1 proto udp from any to any keep state pass in quick on rl1 proto icmp from any to any keep state block in quick on rl1 all pass in quick on tl0 proto tcp from any to any keep state pass in quick on tl0 proto udp from any to any keep state pass in quick on tl0 proto icmp from any to any keep state block in quick on tl0 all ################################################################# # Loopback Interface ################################################################# #---------------------------------------------------------------- # ping #---------------------------------------------------------------- pass in quick on lo0 all pass out quick on lo0 all Thank you very much for any lead on how to resolve this. Stefan Olteanu ===== From owner-freebsd-net@FreeBSD.ORG Sun Mar 6 12:05:15 2005 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 76D6316A4CE for ; Sun, 6 Mar 2005 12:05:15 +0000 (GMT) Received: from te-clan.ch (ns1.te-clan.ch [217.118.194.40]) by mx1.FreeBSD.org (Postfix) with SMTP id 4843B43D53 for ; Sun, 6 Mar 2005 12:05:14 +0000 (GMT) (envelope-from bachi@te-clan.ch) Received: (qmail 66836 invoked from network); 6 Mar 2005 12:04:31 -0000 Received: from unknown (HELO notebook.bachi.net) (80.219.63.44) by te-clan.ch with SMTP; 6 Mar 2005 12:04:31 -0000 From: Andreas Bachmann To: Giorgos Keramidas In-Reply-To: <20050306113602.GA72592@gothmog.gr> References: <1110107067.2060.26.camel@notebook.bachi.net> <20050306113602.GA72592@gothmog.gr> Content-Type: text/plain Date: Sun, 06 Mar 2005 13:05:10 +0100 Message-Id: <1110110710.2060.48.camel@notebook.bachi.net> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: static pid and uid for a socket? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2005 12:05:15 -0000 > AFAIK, this can only be done if the original process calls execve() on a > setuid binary and has not marked the socket descriptor as close-on-exec. i'm developing a gtk+ based equivalent to 'sockstat'. when a user is proposed to run a process, which creates a socket, the sockstat printout is for example: USER COMMAND LOCAL ADDRESS FOREIGN ADDRESS myuser myprog 10.0.0.10:52265 66.102.11.99:123 but, can the displayed kernel socket structure abrupty (by fork() or setuid()) change user or process (because xfile.xf_uid or xfile.xf_pid changed)? greets Andreas Bachmann From owner-freebsd-net@FreeBSD.ORG Sun Mar 6 21:46:03 2005 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 4F95616A4CE for ; Sun, 6 Mar 2005 21:46:03 +0000 (GMT) Received: from angryfist.fasttrackmonkey.com (angryfist.fasttrackmonkey.com [216.223.196.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8FFE543D2D for ; Sun, 6 Mar 2005 21:45:58 +0000 (GMT) (envelope-from spork@fasttrackmonkey.com) Received: (qmail 40880 invoked by uid 2003); 6 Mar 2005 21:40:26 -0000 Received: from spork@fasttrackmonkey.com by angryfist.fasttrackmonkey.com by uid 1001 with qmail-scanner-1.20 (clamscan: 0.65. Clear:RC:1(216.220.116.154):. Processed in 22.891161 secs); 06 Mar 2005 21:40:26 -0000 Received: from unknown (HELO localhost) (216.220.116.154) by 0 with (DHE-RSA-AES256-SHA encrypted) SMTP; 6 Mar 2005 21:40:03 -0000 Date: Sun, 6 Mar 2005 16:45:30 -0500 (EST) From: Charles Sprickman X-X-Sender: spork@oof.local To: freebsd-net@freebsd.org In-Reply-To: <20050305024850.GA96307@wjv.com> Message-ID: References: <20050305024850.GA96307@wjv.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-121837636-1110145530=:5816" Subject: Re: FreeBSD 4.x and OS-X tcp 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: Sun, 06 Mar 2005 21:46:03 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-121837636-1110145530=:5816 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Fri, 4 Mar 2005, Bill Vermillion wrote: > "Ang utong ko ay sasabog sa sarap!" exclaimed Charles Sprickman > while reading this message on Fri, Mar 04, 2005 at 18:43 > and then responded with: > >> On Fri, 4 Mar 2005, Darcy Buskermolen wrote: > >>> On Friday 04 March 2005 14:34, Charles Sprickman wrote: >>>> Howdy, > >>>> Sorry to bring what seems like a simple issue up here. >>>> I had been blaming slow afp filesharing between my OS-X >>>> (10.3.8 and previous) and FreeBSD 4.x boxes on netatalk's >>>> afp implementation for some time. Not too long ago I got >>>> frustrated with this and tried smb and then ftp. On a simple >>>> 10/100 network, and even with just a crossover between two >>>> boxes it seems that any tcp transfer tops out at around >>>> 250KB/s. > >>>> On the same network using the same switch I can get near >>>> Oline-rate to an penBSD box and to another OS-X box. > >>>> If I use nfs and force udp as the transport, I *do* get near >>>> line-rate between OS-X and FBSD. > >>>> My 5.3 box is tanked at the moment, so I cannot tell if the >>>> problem happens there as well. I do have a full ADC account, >>>> so I will be testing with the latest Tiger preview shortly, >>>> and the ADC access does give me a decent bug reporting >>>> facility if the fault lies within the OS-X tcp stack. > >>>> I'm no tcpdump wizard, would anyone care to help me track this down? > >>> I'd start with ensureing your nic's media options are properly >>> set (I've seen this exact behavior during duplex mismatches) > >> Yep, I wouldn't have come here without checking all the basics. I should >> also add that given three machines in my standard config I get the >> following results which will also help rule out cabling/speed/duplex >> issues: > >> os-x <-> obsd - good >> os-x <-> fbsd - bad >> obsd <-> fbsd - good >> os-x <-> os-x - good > I do suspect duplex problems. He was connecting to one of our > Cicso switches and Cisco has some extensive docs on some > configuration problems. Part of it comes from when some vendors > decided to add their own features and violated standards. I'd really like to move past the duplex issues. I'm very very familiar with that and already chased my tail on that one here and in my many years of working at an ISP. I did a back-to-back test with speed/duplex locked and I get the same result. All the switch ports are running clean - no errors, which is something you'd normally see if autoneg failed. Plus if you look at the matrix above, you can see that every other combination in my "normal" config works. If there were a duplex problem, I would be seeing it either from OS-X <-> OBSD or FBSD <-> OBSD. It also probably wouldn't allow me to get really fast UDP NFS between the boxes. For fun I'm going to post a full tcpdump of an ftp session from one box to the other, maybe someone can spot something there? It's attached and bzip'd. It's a tcpdump of both hosts transferring a 1MB tarfile. Thanks! Charles > http://www.cisco.com/warp/public/473/46.html > > This is the link I saved from awhile back. I hope it is > still valid. > > But problems like this usually come from one side or the other not > properly responding to auto-negotiation as documented. When > auto-neg fails at least one side will go to half-duplex, and with > the other in fdx then you usually only see throughput of > about 10% of normal because of data being sent back on a line that > the fdx line thinks is clear to send upon. > Bill > > > -- > Bill Vermillion - bv @ wjv . com > --0-121837636-1110145530=:5816 Content-Type: APPLICATION/octet-stream; name="ftpdump.txt.bz2" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="ftpdump.txt.bz2" QlpoOTFBWSZTWaLfP+4As1DfgEAQQGV/9QUASAorb8zgYIX/PgAAPvAAAA9g dXgZklgGaFAI+CUkXOvgAAHgAPbuOAAABnrjgIDecAcDx7ycZtvrp8ihoBlr QaUMlvpyjvkDD7t66vt6Fad88O7dzfeb7eXZfbnEcih32cZL7zPjNfSvsbYB oNCgGgs2b5gfOB98SJ20buc2wkeqOWm7u1pwdy8YeC9h5A7bROYs3AKeu24c ewvnPT48G+ASLMWYHhsy3vd4re3FDg48Q4chQ91tRSe9zy9zc61srb3AeXu8 veDGBjve7iadHXuMbmFOTMt73veuu5lHBi8Z57Wp5ztzdUISuTaxTjMq5iwe MHvPItY5a0NJOByMZZUDBkAAFAF8AAAAAIACGITApSijQwjIMJoBpiAklSE0 jIMjCGJhqZvVSQKSoaAMhiNGmmGnkVImiU01AAaAABKfqVIqeKaUYAAAABEi ASVJMptJtQGhoaek3/L+X8ofzn+BjnmCEYoigH/IVVAP6ggCB/iKCgH/UP6/ 1/+iqoB/5EBEP/f+VMzMxta7Y4iMzG3baMzMxsRbaIzLcy1tEIJmW2t37vPC IHCPGZnbaNu1tl07M6SBOLbQmtogiIcNS0Ii204JFtoiUttERa2gc21ttTI7 W0pmREbaHIdzUaq0dbacJCCCDiIiINtmRJFERFutiIjMzO22ZJEEeMvNonDT LbOS7pyHcluttrcQW2883i3bEERuZxEREEREblhxFutr1W0ERebRBmRq2Ddz OIcl3S1rca1qlMyNrREW24iIjNCIzI4iIiCIi1tnZEREEKRpkJESkq5W1q0i 0g2tEEW24iIgiJWBDLJxVGCQtaMEYE6MWCQkECVBI/oP67v95/pNUq/sasf1 /nEQq3UrlFtXS/tVO+bbSn/tnlOzVu+5TzZbOd1OKm+oiy8wJpXUbgvnlnkO 0bavqMnlcmmru3QrBYVZyF0sluq5VLybVFytkar2VupIY8TvnKU72BUsGGNT VMbUzi23MzXS53ss5lA6qSrVVbYmw6vAazg+S6t28zbGPBzGPsvOqlLnB2as nLuaNG09obudSPEF6rmt5WsWXxV4MVyqpVu1TvT2a1fa0aKxpzWYevrG9L3H iHScI6swcsnOpTvNzg7eqnk6qVTKneczr6uluVU4eE0w5TWWr68dzSUzyvdt 5NtSKnKvJkxWVU1mnKbsV0jls712KWXVrLmqyqlNclrnr0POM07zeKvsycCw Il3jvZONaUZm6GHNHK1t3S5c6s83SusRrqT2cSlqlUtVWlrMeB71dMhvKeFd zTq115zu1LlHDM1yT2aeBXQpYJaRczyO6ry7SkzuzqZfJauq1t3M1fbO9NOu 3qGi0F1O7xI8a5UtxyzTUpXdsXSpctmtqUtx90OZGvg9kIq1Jm8eyF29VHqo WC85JS1lGrw8+28SXDsu7aq6T5HDnXrqdNY8vNN5SO0D1J0qKb13tvbmw9aq rtZlcljzFc4pPU8XYlz2xm1TvbPUp1XVzODOtUpIUjRmCcYx9J2+fQji7lKp uqWbyJsjqVK5oLlNUrxjNxTOXTxzTqszA6kVKzm70kjRpxhU8xmZF1NmNAAA JPfn4yRZmZmZmK/2/VlEQqIxThgRUXqNYCgwiIRihFeisBjFQQiqqxVgRWAx iIjHht5LIsgRYxQYCvApBBT/Es2ZZEOVgwWcCsgKx5YoBRJeWKvQIrAeiEBg LGK8EVkDlg16y9rOlsDgjKtp555eOWaC201DHa26LljDNqrBHoryocqIyK8r wW1rbM1RZTW8Wd5v833/bd+RX/1OECNiP9BLERII/4Av8lX+g/zUDqf0V3uA KRF2AGxLsgAkBbBCqgiMVaEC1C7IKJEWxAsC7IgpEW1WwbsgCpFW1AtUNqu1 c5iCkBcqOUC7IIpEW0AsC7IKpAAtQLEuyIhBUk0n8J+j+CwIrwLHlCKsBYxT v2b1WByx4OioUktYMP3jLSKh2xuLbG2jtsbaK27XFtuK20bbmborY3atqLdW 3Hbu5SEwkCEOCxZ+6yXl4OisYoj3KDwdGKEis4JFYrwj3csaZuOtt0dbaK21 tumbrbRbbi20VtuO21JbajbR22ZkF6CM4QHgmtvBIrPf8T+P4n7sh2P5WxYI /qAGlAilIJQLEQirFEgxIoEESJIr/hBXKowAIgEE3BX+QgwEIK8oANoLBAgq RQj/OlXaiwQIowDsVdorFWAsB/nEA2CsUCKhFQiIxVgARX0RdgjFGAhECepV 2osQCKsA9BA2ABFAgrBPRAN6gIUFP36fxVEgVVAQlVQzR22i23cW2pm21M1H W27ddbUW2k7ut2js5NQzQgBGKH7VpAV5WKwHhEIqI1tGNszG2WRja1tjttM3 baLuu66tsyLbcWtrbaZmRra2xbaMyc22NszMgzNu0KuYTlAmtp2tuJ5RArLI SxVBUtbwkYJAisQaZa2iItFta2ttmQQtsttF+O3a8mW2tbW2glDHbRHGmpm7 umWmdnW7WhLXbRjY3TLbRBEW62jttGo20bZkm2jMzMzJbRpkW2zNtjbMxslt uc3bRmRBa1a1a7rScmWlblqY2kL8L5ndXddX26n9fxQ/YGm2Q221l21rQuta moG1aWrrdkC1zltLcW1Mu/t8xVi58taXarqBqq22Va7ZMtutKuslu5ya2gAQ Vku21jS5mVmXM0XKxBrTUuSN1QAt1cqbuxqrcMGLS5WYLreK5baACEt2rTdZ lG1jcy7d1MbVZd03BdZLxxeW2gC3VLglpaG1dShtjOtzrcGraaWslxbdtttg Y7W3KlNS4trgXYpusVjBci7vN20ANZrm3Cm2rgobV1LqrbnZ2Syrc8xkuc1M 3NAubsG7Ntq63JmuzpuqMXbkrk22gAczLuzLWtrm3KYq1ubboGst25am8zaG 222XTOtsEcYNVDUNq7aoOtXNJavLbtttts4dyTUNsjg2MoADWltdaO1dRxXm 2XbbYFxc2lt3bdzcyoAbyf1znOySQVoQEQ/hQ/yFf7KqoB8RVQQijIgoSKyI osjIqSIkiMFxVx13EXdwURdx3XcVDIIJIsIAwjIogX/TP73C4Zn/DVa/riK/ G/4XbszPDnx6re83rWbKR7M57Xd1W5SrSmo7K5YHtJ0cGq0rXS+FzcZOqsyq 7eNZk1oL43I19VHqZyziObVrppV1U6p2czBlPenR27yq29mu3s0br7KzQd5Z fTzu1mjErOvG75mb23aF7zRnHlhLMeO70dWaKdabpCusVvXhCF8j14MGHrNE bjpA3QrZqs5zimpRU7o6Z3qmhK0obXY+OG763mLdzXfKKzarceu9yM5T2DjV OraqeEmjbw1W9V53cdxrtvdmsciZlOZ4NWzWm2MnazTU6zjFcCJ7CskVW5kl JWQ6NSgkr16b1adzXSWaauqG12zl7b2Us7Te3bvH2msyTyzHq3M0TndiUOuw ZQky0H3dKLrdmbxiimxPK8XWeII7rFzd5eC0jePB27ZySewzXW7yxmGyCLyp zArmzmF0L6avNRnKvVKvb07gRxu85C7rJaGA0SlC27mcrpSeLcu9d46t4xk3 WZMoLC67pq5EmwbxXO5qGPcD16Tyyn3XdbNShRvX28lu3HY4uzM7w3hoqjgO O8Mq7e5IvltvK7EuV8bqsxX2dJ/6CABAgDKnhhe7Unw2IANmBKIsVJklJpTM gywgXVhddUsx1bHoRHoXSrNd2qdezL0cyXtyt5GJLZcDdsjVTcnE1NpilUmt bxM1m1KU25JcuudborLdoTTQW3NwxvEIhsldYZgFjY7NUq3VdWZmtvvyNgzy vlURzNdhlIiQgebyzy+aoN2sKxYNsSWtC6gdYa+eTyxMt8hbcjpcSzFAW7eD ZnxEghZgmHTLW4LjI2ePlmnhKGzBzm6a6zazEuQtjRmyeZ8BisPPEwWEdWUz 22xZG2PDrptFLa2MLahvNfIszREsKETwMwxo7qsK264zbNfK7yp41mZNXWWy iLo27tli6cbNy7rO47rpmlR1cndF1Lnt9c3N5VTuCxd2cbCgoJiQ3Mlku7q7 JdS3GPxWCzlbwGoqv0RVALiyT4/PZJ6PAgv0MT6qZvDrZkjkLoTLtxSXrR2d lidZpHESUNGNsOxNLwF6zXZCpK7aTK8Vnv17mS+/d89+3gAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAABbq0bhQAAAAAAAAAAAAu6pdaoAAAAAAAAAAAXWr d1W7oAAAAAAAAAAAAAAW2gQAAAAAAAAAAAAC3Vo3dAAAAAAAAAAAAAXWqW2s wAAAAAAAAAAAAAttGmgAAAAAAAAAAAALuq3CgAAAAAAAAAAAALdWriaAAAAA AAAAAAAAutUttZgAH+0OgAAAAAAAAALdWjd0AAAAB+9bPm+b169d3rE0f2BA ED/EEAQP3wqghnvO3LxV/Yr14s+muZ4YA/oCAIECAICB9d1d1V91XVdV9Vxx yRxEchIEhJJJIgvZrgIAgfngIAhPuQT0nrwHRzWCsuNmheLiit2oOzMMrrTN Fuc5LK5pbXXVbjKtqNxqt2q7AtTNTa7W7XbUAG3UUYYpjbbtWrjWl2rVxrS7 d2sMo2rTC6FXUtu2i2twxaq2twxbt1W4YtVabotpba3DFqttVrVqra3Bto2l 0xaq2twxarbVwxarbVwxStpqm2ltrcMWqtqK26LbjcMWqtrWtW662lpWttpa VrbbbW0ddjUu2uVaqjtkutbttrXW7Gw1FttbbatSigttlTa7ClUzZRVqCRBY qmHLWNXZMqWtRtLrrqprSoU1pY2uDaXGdtVtttztm5dLtsq2BbjDmy1cFrlu y7bZlLWXXbZW1aFbagAEkkk/+CAoBrQIAgfgDoiNwna/FOpnWqpTTZqnVMml RoKjJaapBss02UE3UySW6psOpQqg6dMUnJVBNyW7u1u963b113cbXd1c6d73 cV107b3t1W3p29297lVu7vda1ve0Hbe9dt7Xeu3t2972t6673t6apXe973Xc 7ve3tod7d73e2rbet03t67oXvbve73p0Ve1rWtqu9L297d3uWne297e2u23s y9MptG6XVXV723e9Zt72u3Mve96Xt1e7pe2u23sy29tW0zAtrddbjWu3re1u aruddzXe93O7dyqO3dG6XaZdG63NsULdXLpVt2cmqXQdsZ1rnW4LUbhu2Xaj o1MXYW4aOu0HGstsLs3TW0dWrbG1raCZadWkQdaFohrSuXXbKDpbnOubVbdn Zw5Wjq6ldU1tK6265sVut1zqU0pY2pAUeWJGtCtsa2ozLbCW1ttmkkcicCSC cBAQkEiQhJdEIiABwRRykCCj/mCAIHBA/sCAIGdd5P2PYxf1/D7FlPNFnWkM yddYVdXefiaw1eac1cdL5Tcmhht0eGzubJfJc9lmJNmnbRJvSZBDArBWABFW KsQCIsVYIEADIAncCY7q7sosuzuLorEl3csBXaU2tobGgo6Lbtm50j1OhRYc 3dm3SWO3VpdHo7Jptt2rtwRZSzXVLtbrrQ2qOgUYP17cDhAAgQB/TJoE3dia x+dTJvprfa7o7IqRmqm91qkGqG9xFHu3OYvCBR1lAipFEq7x/0T0D/AOB/UE AQMoAm1QQZPn1BPs/W9v3vWqHmptjGEFHYS3z2h+/PYt1fcHMpeZ9DCmbCdx HTVzPVt77hshsVoJShdve1t56ti7OhwoRdRoYJEMr6JCMjW7CQA9BHYuBBIA VhWgEbn3sZDUCps9uyRzHJDZPFVuEN2crZDO17Tw4pMzeychkkjkqomTRbz3 d3HyPpD4GqSfB7u7nt321O23Yao7b9q4iBhgrfcybm9zczctmrZkszNzQAEA AAAAeSfWS8+7595sT4+ZJFlkmYL0OsB0V0Ic6ER5Tg8GesZHOK0oARdbO6bu aNRcZHX25dKb3a7NrTIsMi3d7u5t9d11ggYU6MjlGgwanbSylMzIwUzAQAVg Pfv14zPOO/L873UaupN3UGWNjHkXx8QlcEPITTkTab3yJcqYsTfJSeBAnVh5 BDFPI1e3O1M6qmq7O9MxgcccFVmV273cpwdJEOaxjqtBkIqJSy1cBdAekYOM 0uCUVg7QGVhOGN5zndXM3it8wK8oumMsQagIZuGd7FRERVW9CjhBFVcb0DrD jdy+rL7emqIkEGFXO+7t650TDE9EgJwiwhbmxaDjIE3QBMq4ohh2HNxfXAyN sPFSZpKSQLk5axlyJlS5CTabCbb7joew9zdkWJ6hALvNwW5mu3eBroyMk5lT 3ZsXo4jEIQksVQmKXICqAL0RWu4piKGDRJoVWZ0AjNloPbdkbNBQSBoqHOms qmnfbnaAtBp0xVbugSlnO8uhWHbq0j1XlMFXRMnOTd8zN9y7muZmLbk3Jm4o AAAAAAE+Xnnk9c9X1zZNzvMnzkipVHFvV0TMdkHBErZocKMqRTq9x9mqtlJE QBAsNa3juA3c1znOc5lNdNta1rZzs7sh1GET0O8m96GYkLYlYXluZmZkSBmC sANNBr335fnx7955317778qmSQR2aLgvQACci+lWKADUiQwss50pc2LqODD1 VF7OVlvNVzdXnd2biHLYO7u7m9vLTNgdAspGdL2NFdEpWCQBMYxMbvQZ3ZRG haGmcSsKKMDUEsOBxGaaRgPgCCnysaUTW7mburYG4Bc3d3uacZHnWTEememj pJWG9Z04IVhJuO5TywMSJUYxDRMLGpN7rOzVdUkEFQeXRLJIltSEKFZt5tmL 2+EAChgpS0FDMjYIADkUDc3AMx7dHIlE7Cpdc3jWu8xkUEOq11u5sREWYgbe pzcMMUSDoUbCnErUvho2jsXD247iCbgZJgX1RkXE1co1PdODoKMDKi7sutTn RndUdIsZCu9nL7hVSG5F32Xk5ZC1RTRgwSSkiRiRJIlJu5c26azmTMuZu5zJ ulAAAAAAA989ed7zNy76+T3zO565NgRjBsgWCoA41lEPRYeXGgBrb64lxw2C RQOt7Uzd4N7t3isFxYuavc7h3Vw2YvN9c83nqe5718AQBmGmgMFxjGMdAAV3 nGj46KNKjDrCSEJJJIggiIgiIiIpCQkJCSIBSC0osRWArARii+KAAoENquRV UAzx9zvr32+765mE3jb5zyV4j2jeXMGKfZ1dOdXHr0LLbp90pSbonrDfbahm dtzxTs2CaEvdgtgBAQggQQIqxQIoxAAgQBgiIgZ28tZGZdGXOT3ZvddG7vEJ 0PuWUxaF45mZ6mcRe9KkvJ2TO3RzHdSVQ2S82TWu1ywXhMlzLSglQ5UzMty9 YqEDFbLkpG8Zls2Zu8ttl1ZqQYBubLb22Oxdt2uzwpTVlW64Ajbizcrtfs8l C/IfR3d3SdJ67nnq+kZLSzeZG5FuG/8vfl73wAAAAAAAAAAAAMFAAAAADBQA KFAAAAAoUAAAAChQAAB7++vO8n7nJOSdd87vp+e7572o3ht3SpaCt++Ogogm oKKpMgl2lwlhT9W1ZJABIJJJ+KN+Db94bE0e82CQT4oo+AagkknSEbmuFVnh wcl+p5SUpkEgnX6tPNXhgkE2l8CiSMgo9X0yuwKXvIjPTO9mpKQmQSoJkkyL IJVVVu7mzZ9/fedJBA+4IrA8+z1ZoPfjTggbEuSSjgLJIHQdR27qzshMrC2o KJIJJPMalGvXiW1VSoSEhk3d1Kmf7quDf34r99+ksOVTaX6fy0uWJ/fiQ8TJ PFH8ZCwAuYSQtMqE24IhJWzBuLuEkkkulHRnhd3AIR2EuKIJgnUiVQ35v4+b 32Z7M1QGYUmVBm4OzrAgypFlGdm12c9HdCRH3zNtGrbfPzeenzt9XveKI+VY TBIJsVPvhdpwmZHBtlEmCUktuHEkBwZYH5+Wz3BPPctRA8E9RUkQOD0X5TIJ qxomWUSQSoSy+rN0999unOozpqVJKcpMpkOZIMhTKNXIVbNX/Kl30fikgSii ATBMiyGxupkBZ7EwBh/ECjxkKnfX9m94gnEgTQSJwGEUlk5nd3epfJPsn1Is D76KiBA3y2BwWeS1EYYR8lxRdbvqiLP4gbCyZEAEkgkknwS32fb553v3wfLs jVdt7lke/jzz2zRHhkNso6CiS6+96rLBRmEiQS4SBOgP7EsXyZU5lFFJAlsN /FFpAn4C8sXvo9c93byKQSYpk0O9JkzNMTO73b0q3Z86z23y49d+b3z36yzb d8n2nZ2/s710AAAAABAe3737zMmZmZnV/OrT8nL64Tei2AHoS/Ut7ggBb8uP c8tbGntXNIG8aRi0QAsInsT3POaVfYgB+QT58lrBIAQIxfc/CNLFSIEDL+Y8 D7U9VM9PO9EB8QZRRSQuCiATUa2h2nkgu2vq+v7fvCIHJJKEGQSii7hy7h4L NPRNDu7easkDuD1CJ55anS9CkgeebYIGi/cE9Tc3Lu8zH2d9+/YCAG7vnb3u 9AwlzMzO+uanyEzaQaqkaMD9q74gmkgOgognEuKNfJmtjNxi7BMwkCQCZ0Jl JEs/GmiwPXL7kED8gnz9H1JtA+SLAolSQk4FVWPnO/a3L43ZJISH4VQQQZJB JJIUL9f33dM9DxM/WO5wmVlmgJl4V0QDgTJLJzs7s72Afpgbl9DuEgl0fCIR PuLYI+v1twe5bYAQPYn3wn5PPJc313nnplxHvmVfhtmBB7vuVvDIstFTQ+aK VtsV6q+cfg7iSEkiErHwdySiAgSR0fMMKEE9b4NuSAiCQTX7ffsbg/vl3Amw YRWhsE8EgTPwbX3x29qEgkz3u9d7yYMwZMkkgkkEpeZnd3RHFj+fnsQPzhFY E9ReD39xor9iP10tgRhIE97RMyAUSSQTkJfFH4dDb8N3KskglfQ2CbAEJAkE 2N29uwTtgWYmVJhUVoni/f5PL2EQA/IIHrhPfL583193f375ib+YmTRtrW8m YlcqV556/a9+uzLd9lXve+LSRR3W5EFFpAnSi4cm/tMr25s32d1plIQDJ4d2 xnRwMzYzqsy9ze7r7pTIpJaEy4s2OWdJNrAOktFiU4AOFQCQKs9e7LZ+MY2/ Xq2AHBYv319XED79PUVRGbrdBH8kaeTWwAnuCAreED7+b3+PyevZ+RYAffCB AgT1pNrVDsRjv5738AIABAHWO5kyS0QWdJCUywMzdOzF73yuJm6ub7N5UzYU ySSBDgeFU1b2dffxAIABAGRN+t2vfPu5DLLxh3Ocuepu5cybmxlZzbtUAAAA AAB7l558vP0/mevPn2ff3O4RzgULXbdE6daa0MWRSZIXAuH0408bnD4YBp5q cRC1iqtaUi67xar7KruEDc04Iu79O1vrvt6EEjbcKHpRbpzIiIh4URABu7go EAAfrfvlnd+7b3161umXXp52AAC9hEDLkkEh6nuNaGAwzEhWCAAzAg9INrwS Jn1BRDWdFefNt6uxw8aHAdIv3qu3Ki7ibq1vKi+sNF3Hr9tbDeg2PLdrwnGY YAEaF8DZxJPwFE+dVFAXh+FIZ2+oqVfl72DKKVwkDgJHd3ngvxZwOXiT7mgQ BAuzpLOwy/Z74xv6sZyOrvAVdDrw5mXGZl93ISbLdNNPH1rD2Xos8hPqStNZ ovLFZTW59aZcPUba/Dibas/evvm+mgMFAgAIA73rudAaaDve53vaIIAabABW IG8hslYskZH3t5ySTk7igOYICVmlBDHcZ1lAFNazYIJmAAJMUoYigJjFAgmI KiYxQ8kjOcgAIAKwA00D13e97QIAViACsEe+TkIgEVYKkUYKxUICEVfgSxEQ pERESkAIJJgmBHyqQwW+kevjUodm6KE5VZR3bqrqaxLUmMpqbsyCFcyLWLu4 nKfLOZS2rO6qjtyY1LO45VX3JhV0iwCAxUIgQCCcO0AqcLxjtMqyzBjBjBeJ izbqFlFhL2umbbiA7VC7dtaWzVy6brVuWyXMwdeYyrsdK5n7ulceUHnXsDxW zjEsNNDOU9fJx7Vs+vq1mxzPAyNoVHVvUynqvJreyuzMBXZO7cjlZ0dtIXhR 4lUeXcoAZ+XpkEAQOConJdG++5jdXSmeTd5MYuzFsAiZUOEgUW3EI0MJ8v5q jhrvHw9AwX8oLv4UFsPN3nH3puBezeZv4ts1ZCu7nu7Oy6QPD3xBNGVO3w2E PTqAPFUIqNhkaKizn0FVwzodIaIterp6KEsIbi+7PMZxGQMF1oB8hiBlYjT+ f3q22MCWMgbtxd7vd7N+3js3rGVLId900yawyQCYZBIJZ3OZ62RrbQAACAAC IiIiI4hq507hhT6GCDuFPtD0jpszxsaRVBhdGRlBsarTDBwTCz1ZEDQLxQHy q33IdfWVwF3AsCnXk+e875U3eckmFAom79le9njd6aAQ7xwOzwwcDVzez6Zm VMoQMbMACACt91WJ726jSpjYal5bnHlQuBhND0IwKXSAkLdywEO64NodSUZx DZyRWI8fCTSBmMZyrbN7LuxsBCQuUwp3dvNefDIHijjq1Zwb5hQiVNz3FMMX v1st9VgG9Lj0mR1D6rqPRYaOLsQAPyI+/BpkWQgSBmljf5YxBKBIv836H/CA kBH0hyxt2gL70vlvHvPGVd/X3YtGjTu7u125lrcEaH5N0HtxcX43stqwTQdE NKOswiVNm+w6PZ7wa7qGiRaoyYGb6PSPU8pynJWQ+xvS2EQYImSSwZcgkzuq H/L+28TIzeQ7w5HfLy8ZwgKh5ZbR07P15tUDAXRVerdzO5gN0aPTA5DjI97W sEBucU+nH9BGTtkZgQ7DqSoP4aVQhh2HBpzVnrMzGBdIgSGR8gBHmGrnaHuZ 695TA7RFjdLbXddVoYSoa7XpKQT0rQFiHThpllMzNXOazQAAAAEREREREREc AKr3WN8J5gO24HpkVAmh4a8MVSFSMLGdNyEGscHeMUSDQmEaLASs9QyvbwUk RCXstKNoTho68pYdCJDWxDqmYugg9R6O6tmzlBamFxd3ubfWg9BmwT3y5f37 zkn739+32NNAY2YAEIiIiIeFr8yVc7dNqPB03Jj7jCCUDOaaGCcGGQub3tXq lskoqNgZVBWo09WRUANPmuSoEsfaM8140vfevzTHdN8MA1ChRmZHsytvWyZs RvKSI6eLAZIpbl3gwWjWuFAyN5lxsXeNvualQ7YdXDtdvPvvMhQ75dvPAQqs 0qKCHM/3NtWzexzutAIDeOcd8o6KnYD+9U1Nb2bgQHLBd3fZnX1iQFgEVvJL h40aFpGZeWwSdZhosOdU4rceNFPOKuDjd+fAd7N8r8tzfprHqfAdGdaDIbBO Bw7w8Qg7pB3y4kNvAEAEN3K+GporBg4P2gNyYZzGlddPVoyii2GzVVHsus9Y wXrd7zAqxjdNmeL4g234RIwy4d59uHKeQIvHjTvs3FgIAJAAbU482zB00fXX ANU1D+EnEw0L1EMOFtsekRiVdM3V1h1BIEq/ZmV73u3IBEWh24EuFiBCty/r s1aXX37Nmpm4QuZstbQAAAAAAD9zkk5vvntz5Jz1PvfX7xGljrdB6aUZR0u0 2F494zdwFN2HRFKHcQrKmgkT6/L6OB972hg0tF7U1XvvqhxQsKqyb3NaUyuH jdYWFHgfMcguGoLKz0yZKBDJgBWAGm3kk4m85OvrxWd3VIiEIiIhwiIicIiI lCIiIkiIgE9f1vM9T+llu2KxNvQ9Iw0Z0TMo7um90qxLC40el4uw08mmhPbW EW3jOCr3OQatXrZe0zKl4nWWjJqoEATEAASIECNJuZNdI58pTyla6so1c5aB nno17wK7BWIJN9Y2+UhMzpTk3R4Znauh4aSOA8sui6dTtIUOLKK4ww1MtiSJ nbJHmW7TRJSxpo66xWNi8Qp1xM2aOdak00tooSx0dCOdpxeLEzIt2XctVttA AAAAAChQAKFABQoAAAABQoABgoAAAAAAAAAABAAAoUZHnEkknPU5ySXvx53z ecmZyTnyK4VeoB1VyAHc973V6+QBJnLh599AWwHn1puAVhPMYIjhTTtkun9X W1URaCWCwcHt440rtu/eqLvsvPeo92P44MzN6rvqmWLCMHt5UN8wsAVXt3cc QRL6sw0EV01nvzK5L6ZBGhB6ougV+UXIIfZ+9e5zFUC5BDAgcUDiAc3m853e uc9pIBAVYM9IssFfUres5sOnd5Y3nEFqNp0OGBdnSojfezbzw9woU6qt3azH HhB7t4MqNFuGTIpaL1AOAiGBnVPhkgrXWWYx7hXJJSbq+HAuHSuIh8q/KPVQ 8qytePvc5fsYVdgcVDoHCjdQkN8GsLoG6tLV4zwvUst94u8+fWffrz5mAutP LTRw1tjNh9u3exV3e6KKCDxM68e9vxbLeKe9yCVL18ZLhZMUzD41ZgMpeDhp ppgb7V5z2FcVAiKIAteKHmAgdeps9M+wOGGYkbN8zIZdO3mzeur6TmyXsNVb sze6SCFRBBpWhLVN2wMkksqV4zz8+aeq+57E71tU4JTgqahDNwwa4AAAAAAB +kkkd5Va+fdTXtfGqUXsEC/Gjnj3NqNwCeycSc8auc4SFCOdFwzbON6zwRnI M8QjlTD+SXtZlZRga9SnYLkrl3erjfTWX17yawrBu7v292ZUvLYdEHm6xh3K vYgCBDMAaaAwX7ydkkmcZqT7Mq86jlQIrzJiGMc5DePcPv0AAjJ4SYUD47Zw khrYjuF4m9qeZFhkJa8ezlwUKKVD4KcyI23l5cF7GICR49z2iBqNoHkRr32Z l5jDRVeK/KmK3b7Oq2++5cmHgcskCMGGHAtJMM00SXixY9cccZvSx2nLzYic xrvsXzxtLRFENm+6M/Yvk3VFa2ICIcz7M+nDrPXrp0ABXhuzDOJt5DdVZWBx DsWGsve6muHqZy/ecdtR4+kRT7G7V+p3YKzmosRntYqBIv0xomRxjFK0DQ1h 40NHeRDUs2CsL7c2IPvX4doN2DJysI7t9eREM2OhlNUjMiS2zEwgEFDpocN1 W9VwBAIbPBp6jxakLGduBmb1Irbq+zPloAM0C3Vbu7i94E9KPoIL3tnD7wcK WtOtl8SOaFIZUtHrD44hSd8II91X4emy6OhydMSpywlgwhFmPbHmnRsy1evp yxjdwcKh58FVEb7evq9F3OTNQ+X5jsz1vfnPeTnvzua2syWGS1t0oAAAEAAA f1/Oc5znJPU8Io/QuzfhwAKHnuy1w0GRg+KH00hw2D7NFiulgcTDnYxbvb6k dqIxCdOEOPlDJPqAh0q6PXNyl1Oon09XZ45rCAmcc1VNT3dvZTlhq0sstPq5 NcWbKDUzr0CHiIiIisRmAYKBAfrO9uzr7+8749zd1fL+dl18ocxups+FAEDM 696fBiHwzDs4NQsX4fCAPI7aJAn6mMxJ8SLzhQFgDmZk6u+nKzOQ7jgsJXcX 3V1PozEBO0HifZ8b1q9Bnb8uoiqgH2s9nDZwPGtFU96GuajseG30ea/uJABF QgJ7LDBfLCCVM+/OYObDX2ZQnLxCArliwO6/EcDg3cicdPsTN3mBapeZnd3W +Ck4L0YBkZPSwFoxTRhwtSrDbUMMNB2qYCvG9apC8udl9Za77z598oQgAIAK wA00BgoErABABWAGmoDGGgRgoEABABWAE1qqDBQIgAQBCsANNB1UKSgRIAFn xRs++3jGdZ33Uz3Gy971krp3Fb13N9PEPE5kZOWc0y+u5qcKq5c2u4YdZNyd HdMvL22KNTjcsXVZy4nksiD0LERMbRDpq2VVTBmGCrqSqvFJdUlKtgQ1tXIZ 6l12cS6y1Xq4oOJtzjMeK7QsDXmFjsS4ssi2ZLVXEzdZZDN0Es1OpMglZ17u WO2gRsh9K7LfVNocKusyZXdts3otB1HYHynQcMyhje4L3Jpa09tMKOUybB2T Dcc8YAAgdwmQxdVO5rKJRLCEMsJZBKLcplw5a7Rqy8vHQ7338AQAAQAiQARX WmZvq6xXWF0isFdodA2gA6Jv70e9l8/j20jfFz5zmZse6ukWGW8g2ELprIgN PDTtBb7sgDAbQLeHBi6DikkNOGhd2M9guxzartI05spg+xnbN1FzpLaqo3NC ytbwJxeUQw5Hzy/XmXiogPtckcm89933feInyytzxV1S46vFTCSUoCW5UzQA AAAAAD8ntYMhzTh8KaLC+Wh2nDj8RdvZkqmCp/i4CDbE0bDMnLmy4qdcwcFC 47D3VADQ/vCwtHve0+qrXdKG0/pn07u8mk2ZFirdp3aq36VtyMbo4H8ZQvvg Og+NIJbG5MCIjGMYxi8TGJpKgOYKCOYCKuYoAJmIKJmIiuaoDOc4zjGMYMXi Ywc99r1S31KlPnFzoJII3kcYMwg3xmZ1uoCo8y9wnwZ6WQEvPmFXGinDb3hu VhpCTXOLz3onq7J3dch+TTmVkX1c+MYM4OyWvM7xsOFOjKIlZ4Ih7UiwJIXT Q8ZZ45mphUCnW9D03rEd5+BIAqtL9iWHyHtNXhTXigdqVrli7GvjRd6A5x0B sr3Natonu6qtiPCot1WTd7r3w0EfEkmOHVCUbBleCCBs+xU+d8MW2Qlah186 YbOQQyfG68IACAMbq1AjSeCxvVe155tkIZiyVWUmdQEZCKBUNskMH7rOzx7L +5+R3pSBz4EQGFJvNZV2EnbM6gPXExM1t96V3MbBu7vd7sx3oboElNy26NHn 4d6aKLh7hpmwg5jymGngEKKfhfaIMcBzyu9Uay1/Ps+AIECACYwDSCesZ5+1 M1yZ5TnszdPRQo9CwUsWdfZtV9cKH2CbeZ0K7NGAUhxRhkmZmbmY3Zc+7uJs 3Jm96ABAAAAAP3JPT659+c8z5OZ5MfYmvS1LRc2QoEZwlFCCBSZCbqzqC1vN LDisf6Z9noPeMG2iIZk/c9CgiTqaRBOfOr+nynd9U1aDO2aoo+b21u1sUPHv YfI+7p+me5vzny/Pd7gBppmAg87O970kTMzI3GunMvGR6QMqhxnzwG5F+4ON 7CI5dXikoHAfq7Qx8QDE8Wk3RhlgiMggRka8x46iEEIUIkckg9MTnmEfMCu6 Efr8/tZx+1+/d8AbI/QME0xDhEkbgcxzHvd5994GQ+P0oIQuH5jCJIrtgGc0 8I+i/oniz9YyCFernKBhHW82P6qTPqJLjREH0BzFldtogakeykYw3FMwDaRJ dAVuiQ3zXZP37sUNWZxC67xB/XSOf361OCMSouvigeExAuBUCt0XBORIQhAu Kfpn7E/X32S8+9xn0oNRKhUVIwwxXZDEred89g++1W/fdOXmkbjAAaoSXD5M COARCRDIbu1ee/e/HO58GCC+kg4YSAH79SGzEqMCQJF0xDsOR9md9MByT8VI nvpuWB+gEgfqBz+C3rmR8Z3s479R4PJ30MEXH7klyOCFMkJVfvNMIyIYvWsN McZ7u5YBS4hERhGAwmqiI3u/Yf3vTWFEZjy4YaGB1aWUNsGmdv1Z57L9fPJ3 d0EP43iABnGpjndScz9IEjIj+IQ/iUGB5ggSTfzEk10fkR5O/vp6vt20IKBp AcwaQmxhc+7O285wAR6vaPvmIxi3wQXxYoISjzMdjXHK0bQ5BWzhJRyaUPY0 BdzF+LAUVKMDmZPRDKt2ZgSXwBBFtSQsJonx0outGR+IoyAsMvr8+Zbv4Uuj TEERpkYdydn2Xm9M1fq2fCozQd6p9uahuI5Ql/qU4MnrvGLnDJgmKkIESlKD ICMy3GpksubmXQALbQAACIiIj9J8IKm++Rn0+w18Q1Vso0IIOJLyFixJ56Wq RBFsw9OCzTlw0W1WsHxXqnBJ90exbzWIHYPUwnjSrZcR6pdRkTPC8GEQR5m9 7MzLeuG8vFcQtEz7h4rbdxrT0tUsCGCv5ne73uoLLarAfzM/k/eu5Ou7r0RE Q4REROkREQ5AIAOqe/wu7vt578+m6W53QXqq51HrqswVXGnlZxsUDbrQZzU9 Yrt3MuUSbFbPHpHaVgw0+d9OHLzmM4KMTfcpMoKUiKIcK5O42TZzfc4zcyFU 06qemRVyKXbtzty57ubYvQT00Mu1SY7XSVG659pAkS62mzV7qVsduSdMzGxX HM6yKsJteVwhbZdrU5q7TK2NMcWZl11G4Nm83XWONhY7YlprTKYFzM9tev1D ZDXxm7Jublu5thc20AAAAAAAAAAAAEAAAAAAAAAoUAChQAKFAAoUACsAAAYm XMuv5FACQBqNdooTsiABAgDpQzxqb/GxoTgYo8HGP+L11xwAH2nlD0IIFuyT 9QohxUgUvam4OUzg9bL2trMq6fTM73hvKjYNVWRe1qtmY3hGoJMrGuSxC7Gj wFWjIe1Kmzw0Jnv0zT8dJAAJPcmSutlBSozb55kQh6H2wFGDwuhb+nkbB9cq qD4G20xjSt9HqFGdyFs01bVdd54ZZYaNu7uLvc11E7yawODhWZPtDVJY2PGQ UYC56AwetNTeCbqCyKTv46YFFd2CS8Yg7yL4dzXxkUCjICauS1BmJCggm24K q/CdFDUkY3YCCgb9PJ5Vmpq73vR8Sa8BsKBlV7drYftGsE3K5YqBo0usyKhq wYzObwxWhcfNFrQ/eoKxCCgSEZF3HTBuz4YBj0O2rMCxq9+gIAJAARk+zvl3 vDmivrr5DrgT+dv1573eDmUN+2szuDw9N1TLnbfXbLO5nqeZhm025d+9RM3u 3oAAAAAAPz16+c9uXbs9fr8mevXZk2vOL6HexhI3wpqcWsM5lYFkFhK0bmrQ nNAdFkEEggZtRsSYAxBLomepCAtLDxyup6C91YKu/HeQrgsF3exk93vMIGjl 68mfb+5+k9fZ87337160BgpmAgBVVVOjMzMgli89ixt32ByO8bfmoHlg+m51 GY2fgCDXZCCJwgUDAaso+EVQdgggAAgDs2denxMqYQY2I3K5BB0/Qt9rzwqa u+s7FD5WY+WTmZ333dOUEIG+WDmazbnow0PH3uB5u97VuJctFY1wCoqi/h6p 0PDRDjW94ZMH2E6krI7wGGY6+vx8HfF1eGdsTGs0BzUiuv1d1QzZley7zuo+ BIJBAvCu7unveqrliGsZqa5I3r3uIlBEYiDHIb+zz6u5aeCiByKCHWAAlVGo R8EQEKgADjcrcAU2RUCtlIgmw36V3JkQRMS+FCKe4ygUX2NZ797eoiiVIQRP MFdQPotGPbxjm898MHC9LYgxLBEosKS5SJJmbNXWX2Sq9Hq87e874Bshcgbo Vq2tW1Q2lN96pq8YgDRb2R0XfXnbnUXY1JssEGIIAWBLV8fcl8C9oCPe524v ODkJPnIghpu+NnJs1cdbmc1UdHwIAgR8bqAKfb37xvo7vCcABA9xDQhxUccL zU9FT6Om83lIPXBIcYsyu7PRXxniOJy8TYBqTY4Rhf0oCT4diBYduIGgQbLZ NnbbbAAAAAAf18kk5Pv6ffnGXzN4AAD2/Oj40IMO68qUd7Q3eOBrMoECmIDv dfrER5nAILIKkOInY2qn1UAbnDR56CJju/XrL7OIZrWdzd5wlF4KgonX6H0O +nba67QQuTXdZX6Hy8sR1DyCR89305l4/mO04joD3F3e73Z3uTfE14ySZUU3 7Cp8SQk13dPHgCT5+x58oEAZgrADTQeTyAfZclssj6kwhW92o2K++GCb0OFN wqGwBU2ZPPsmuu1RD77eKLfv4EDkEAkADh3fffBY3M7D5vRHzPTQ82nBp7HU Pq6WnOpyASNv3pgYnf0z1dgWGQxCmZ96czMxAAgRc0NA5cPGx7IxcILFVa8A SR6pQBI04150KBrNVDG9XjfHZvnitmYXquZ7dDsze1+DaR7yboFYwJJGlhms VPRdiwSQOgXJ3lfvE1MDGZRnbU13cEq5TSrr7q6ySB57MlZMl5hyABe8uGC8 OYaptDUddEY5xpniZAUdPsTZh4ILY1mvOiI5nz7lavvz8CsANNAYKBCsAQAV gBqNAYKBAIEABABWAGmgMFaaQQAgArADTQGCgQAg9/sgAQAwPGarJvvk67VM qyVg7pdGdE7im+sY06nMPI32awZ6keeTwtPrOVKynWT2tidvBea8SLaLxYoi MQiBAYuiFQTEzml0tuTBkmtxRtLGSusq1LQzyVrugVojVY26WMtvXGM3bLSS 7XNl2XFLjRxdc4d1K0FtsGUhIuwAAIiKiW6k9dbxVSHwwrRLy3fHqrEhryXl qup3Oic5HTy7po32G5svr5ac3UrqWj/AFUBAEB0tnoZfO0m5ElCUZRBhygyu 6Y9AzMcgcNjbPx781U7oveaa6KmrqxQ6Yj1NFR7LwYI3lFcZ5y1mwxIBA0sj mbVW7dGDEynwfw9hCN4tPVYIkN6DqEJ6UkZ5DWdhr4KpJnQyjtkYuiqrz+91 36r4aOWiVmZnTtd6YXVjKlk+9nePfxG52XcXW7s1zXEYuZNNAAAAAAAPjFm8 8nj3XdSkjQj6i3Rg4gCaxej3DAoFuDcIrhmR6dwOBBW7VprASmTyfX5vOBjQ bpDFhnFuktSY605WzV88UfBSIeZvKy8tNEEAghkSBI3k4EieLWXfA08Je4bh uzsRAQA3daaAwUDvv95925uvO1e6bWiyHGXcjS7TLCuVU1iSV3TyF0Ep4tY8 g8JPhrWpm7kGDV46vDM0tRHPmQPU0PE11+jd0QaXmqvbtbbyLiOKneVTHEOW RXL1npNw2hurBvgL8Gm1URL5Xlm03azNAgfGNnEA1bM5Hp2BpVTPKr2T5KLN CsEuIgDCAIFTznh51ixjUbjvGe54iPe+tVx9Xj4yZ1ysZ1zfaVZEAC+Agv7b tIiaq7yqywAA69bEnX7g0nwbhj1fNeYv6FL7xxi/pLPgMdt2JJzCZY3BQCgQ n63EabxNHebML4oA8ZdwEGJIE9fmccz8FiwQIEAud0uWECkJUNTIbkMxJrR0 1fE5je7uhdeffTHQaxbCR+85CCr3rk3e7e7ULRXeKPCeJmGH2d6vbmgiQqcM uVDuf1Bg1FwnKS4R7fYRC72K5mSh2+QadcQMUTVCku7z2otRwuRJJBJ8eaaQ M6AeKDO16SVwCkhy/kigoUREZ1SIBJIZAghBlnixD0Wba6NftaJ9N3aEDmpB LWg5Yebq52dGZIIBAyfC4qnrMFZ8FvnqDp5ZY5t2Yyq7sLpV2t2wAAAAAIB9 /Z9vyZvokGCwV5CbFN/Q2NoEp5XlQyKBYBFsgoqbj6LxTpuchavaJFSCQuFI B4DGr5vJn1+h330b73lktEUQrY3HBBLiiilwAFKgKoNQURx6UKGO5xe34qfc cGiY4hBwJRSVnHdmez6s3RVRbOu13WsyOAZkXO1vU4KHnwQrZbyYRGCXZ7k3 HLZnvJnN++ffwKwQG7uCgQACTNnrPfu3z1+3Nkkk5znkz35nXIrqEhFffTco wUNBR8JCZBCyNzTTJlJma44b4VQVVGJUnQACd7YqEwYsETn2JYA/EvJ4h6Y3 rO6vaahho9LrNUB5PnHKguj2uXeuupq3tOQxh7AJIIJAEQGbMSsXnWub5QTe ee9JXiSQj4QRFW+InbD8FI3jlyD7vnsS4dANIkNHbO9u8GX13GE4aLeYMiAi G77dfUcz20wSuAASPWg9tHruvY1FhaW8n3D0xgRhURIlEFFQgcyWcr47Nr65 weBQNAoj5JJFfIYyz4HdV1d3nnY98aZsMYHKSHFvK99tdwikhDlnTBkwbuoT 7yQY644IbQRJm7sIFZpzCQQSKhuvCg0fEBwZVE+rm89Nfdfs2i8zSqEiI0fF 2S6apIcAzLsbeXi40JmYNgLCSSAIxvds77o+k+ej4j66fVdpjHFilz0YXsoE +VWpkCAAIAGPoZDJqjcjpZ++BNw0V1wSt3br6vG1v3XnbyS0EWAST5IDIKzM ed729fvipPxJSB6EgwSvmyS0rtjYBmCd++8KgUCXCRjD1PjQc+sOJMJeCKQB j6Es0v4EmQTgQW8nHqoOQqTB3V6/iDm6GPitULUjaeZBmZJBLjGTWvK+Nszf 2bvc9LXvjLgmVrYXCZPx6+r7N+Eum93nlu3znnkzuqkubmbLlLt3aAAAAAAQ E+WepmdubN84n79UzZDAI2MDLQggkcpn303ud4y9Vj4IK/GuW4yyfGPu2orr JSoTWS7t9yvQx4RQ+i9SLHugzQmvnoB0++HyHM+Gu8obIsQyoO+HUzhIrylY 4eOjurapyOYTsYEvBvRynPdu3vVXN4IPYdtQ0Ok0MzwftfZFGE/PbKHyevq3 5ttrjbbbZUFAgAOe5yScnJPvnZOSScknTgCADXsJc2aSys+1qamnV6LFq71l rspt8Ss1CVk3N5d9b5lbRW7WNCbErJs8jl9weGavqLycvk+UNZ1XOIu1MCQB ECeA6IAm0ZvtbltyZ7ty7l9O8wdkG4npp123lla+5be6GOx6boIrM6x3Tz53 zVsb2wMh0svHXh6oIJrGDWut4AlcZ1hmBdill2iNpElagIjni5eLFBHabWy3 NPXmNHcW2J2d72bmd1zcTXLtau7boAAAAAAFCgAAABWAAAWjQAAAACAAAAAA AAAQAAFG20AUKd8eZznOc5J676+bnz16kk5PXvvqWurmfXcxbYMHBNfGaGIJ drnEgkrUQgf4pjaqtH4XKkbKElthkVt1PwCmCmid4tjzWTOqWkgiR6HCLUzz pB/sp+/c866q7mx3diQSCPmbJzM6+xrjPIeQQ951vLzg4wrpurJLe2WYEDe6 UBsBxKFfCdGrEPuRSZUePPQiO+54FvfkkgEvZG14eyZk7RzftZFG0KrcZJHk gYuFJ7zehSgmAYBXz6siWGiPdafeUQADDL0bFiOZo679HvVvDHugyYuXdByq ai0Rp5S+Zkbfb1TgSkOQ4coIBVL+aBeHyK7vQQJAOpGLRSMAj03h2gKgi2Qh yWbMgzQSZjABGls/cE0seBpLvsYomtbBuO1weff59n5sfN67TxJ4XVANBUqz YaVLXnU/xuAz70h/mS2YJRJHBHV1ua+zvu52/3yfBQoNLOhCZlb77c345PKs Ct41X31YMaqV9zKAWQUOOrgQkjDpXHnakJoTIxB+joACa5sEyKvduL0oAgkg UUBKDBdTO6uGV6JewSegvI37LwM4vc7OlXsFkoCYgALdm/Ny6v32yuEvw8NH zUysq8zuy7BAOLz3keq/D0eiBackEHPelsx3SJB0ZwSMuW0gi1KJImfDbm1a sF0AAAAAAB38898QPaklUUVCpQI1AWFSd1K+MTzRZpELir6pnCZp5dlc5iTB wQarLq7hDJuy65W0kBXJyXo5kwYbwVyqDIAykxQkEq6YZ+hCwALWpO6nXcDM RRJHCPAI9i+tAjLc56996PiuFEjQAUE088tqvZ7J1XvUj5gmbiqLATLII8FL cMVZ31v35699NNAY37m970BAEKWEEERcHpqIVTKwbc9BqiSLS8mASLBhCYpY xZJxaoB+SvYo+0skGV247Jodcp4YYsUB6Cl9RDXONmhmfQ++MuiFoLXOfL30 q899e7UQdQ9g+VPhW7Xqrs8KukeTYtEhOEtEt14qhJQoGPhRCNBEoXMjKBph FmHCj0AtVO+z76fpCN+Bd2wb6ZYnOXBzgwM6nE6k4fKFue96jTdGs/JkubwJ QQHmhSReDvElMYqPt0u5rs++6o0a52FR3dvq7h3dVWKgBjw+KvCkSSY9FuK1 O6999S2bujr8a3rWvAhIgNRQPepFENa1q621Xbuu6bh8cvvpaAJ7wb8wQePg l0mgZpjPMRAgSMOtpn4hTJlltyUwnJne/k5n1L2QVJZPP9+bsRAgAhGLKYVd iMjrq7eDFYNViSAAD6729rVSAhmsvETJbdkWNwAAEJg4Hy1O5a6tO+aNKKxi CQv6832jpsqYe97wQBNQA57zOZrNT3spvvoSbNqAmHZJ9sKmSeKSb2GLEeWP wFQurtZTm1VWPQXJABEuDETW3O5moxEADBqC+7hS7szZ5UhlyRRs91Ap0Kz2 OeIReZnMuJTF222wAAAABbb5O+X7+zzjyYcPCol8qnFHiYznPOY+olEx8cVA wd4mYdE0YvFQffdAANkv72HJgZlh1XPJekyCmwkzL1eofNK+8UNjsghd2/en XtXd1XIRCR7noeHq3dmapF0SHFLmgPmqRA9zzxnzvvpgotluTACsANN2t4ew XbOFDeyox8fPEE2/qLu/dLqygCGt7tR5UMUl4Nbkloj9MxiSafVZ2sGwvgNa ukbWeI+IkE5wyJBB1svaR4z6D1fb3surWV9V79ywEzuCcihTzMru7plBNfcY 4qjrSwh8ENE0nj1tIKDQRodPsXfjTc14KUF+5tnxAJHq6WTCaDTbG5kZyeKI W8Ao+lAeJnxIdTEDcQiOfPgehaJRsY06qf0z1dnkd5OIKETMPu7188UJFYMH d7hu2HzkAg7aWeqeJMevEEmDyGlyHVd6ErOh0+Y3IVYYKmMJsaaXgOHplDQA ZN5zn7b36MFAgVgIAKwB97e93oGCgQQW2wAVMAhWAGmgMFAgIBABWCA00Bgo EABABWAGicSeoiAB8NxzTpB5tttO0q3kuNunhrGXoZ7tNTthdXHnZbd1uVmG rvc3MNA1tZLd3LdT3WMKlKtfbuJLpu+W9O8WhM5qiK737nJzkd2TJ31NthYR HLNuzmmzFYVrdZMzZ4Ll6ki4S5FSW2B2bNzyaFulxZrJjUOg0lKXHXV2l1bT TV7FmZtbbXZGhffzz5vUGdZuZrGEpzlbkK0pNX3WOOCdvJA2a21NCYOjk5fI zVnZmgTO8+l11uXg4mKEQoIfxOAgCBxQwoAmfc8Z3vfdwm6vPLFcgBarlFwI GS6kzK0F1i6IyEBg6iEISeIZpqnneHxjabsdl1dAkBQw09qWZzX0/Tf2edaJ BUaZuqu9zYyO8d9KLBA1jtsJxd3gfhUjQp4QK7qnVbqvHAQBAgXfbLkKelc5 esfV77ATNYk1ua3cvvH2IKcTCd9VN7q9V3Zru89m5v17W3g2qPyC5RXwI8AA 5fsPLzvUADYgYVdKOVA7ut6eb3rQ8hiSFVVwkubzN7rGXHFt3TfkydbJuRbe gAAAAAATfU++9uz3+zM889lMYg4vXHyommFPu12c+AaAOORoq8LoSLh89B+h J7voE7Hku6dSKOfZ5JKKnxz0qjOa/t30d72XeEP5IqIEXd5eed+7DjcZn6Tz N8zvzvv9vv4gAVMZgDTTGMYxMYxYgeFSwXR4ENius0c5OSG7oTKhwHiBsTQC pNzGNG8bz9nGsaMNl2iyAcAVR3WHa+HMBD83qWi1Jbup8kLgx3T3h32aQ4Pq ARyQJVgm6E34O7zOrMxPY3kEvWRJllTxXd19JuhhdOX7oee8534IMhOXYrAN KYkL7UGQSSfgVvWLxNdS4DcSQQKHKI3wpu68FzXrx5qRIoVs55RlBqsdkC9S YMCvdhe6MPAlKLWcBKsccRAa2OLuevPNVdyWkqxjmKqZrJrIqrx5p+5pQVgg C+a0CACQAGcBjNJ7lbxiJAJ+loZlP3Xmi0zCEzUSJzSppfC8QKWzUTuk+99X d9Prr740SoSaCBetyXKkBplFNsMKXINvr0UgZnnqpmlXLstlTSkUsB5OGbNS nN73aPfH4fFfB9fd1X9z6WDM21sKB3sAvKzLdnRft8MA1N5Q3HMPvc8wveMV a4vImmJvoeiSLQs7awScXVPNo+bKuZhXue9k9bQtZ8vgRZk3ftvdoB0vGqG7 67mb3NEObeY5kwi2IBIwNEQ+7N9zJmXZ7TMZlzdZcy7aAAAAAABF7256nzM8 e53Ps/Z94+ASEFfqphgmPIaWMdQoJT6Cj53TjjMyOQHN2CBpR0LxePNsa/PU emrzunBYGKu5d77d3uNjQ4dffZwwZaT6nMiZEzMzMzMMwBpoDBdknJL9+3PP PH7dvuG8nGJ2gPe5n70wwHsfLjQ0307gKlatEhkGDvdtfYBYEa/dEdYSImLB zU8rdDK27NipqICeX7pq4L5d2NHLa3ezM7nAAAJOZ4JgoEAgAggZczBf3h3M /Zwd931dIiWI4kgnOu8ij8zp9hfq+XOqM6Jcl5Mjt9vsCRbLh0JkOU70pMiG 9SfgkLPnHHpjoq6ZPV1NXvJhnrADvUbfvbWiAsIg5r0O5iPC2UhURBGRAE9v 61BDfJesAANfNAgJUEETlUoCYIoCT67FRPqaVAqLzmNd+8cdYczzfJjPPoYM WH0rwUiBECwKvkk16SZbkEiVDYMtTJQcFFh1SNyfppkRENGUpcD7776M2jhJ B8gABz+jQF3N70zOZ5yLk7yiq3cvN4gAPOOCLkU1ENIYw/miI7glweSllbEm LwsSKt9BUENXegPOjMmUGYvC6O5jF0BDvBgxpCvyeNnb95rjsmszuuswBkh3 d3s+7uoRAAJ1yVWLLy11M5srloUWTcQmS5M2bZV3QAAAEAAAe+z7+ze9m+e0 yevXrzvn332fo9pI8ZhANawxXlIQThTL+2qrBHGh7uqZu0IgHeUScFd2tLex lL+2Zrsd48O5Jveqt3uvnU3K8HCwINQjRy4vYrWbPQIiIiIiHYZgGCgQEMzO cn2Jzkk/3c5EQIAAxV+p/GT+rwdddnXdKxITWK585p6aGoqUDRocb06J7qoU NUTKOCTV6anG9m2zMjXFTViBE84AiAauq2VfHTtoYaqjOVeSYqiZU0eB3ewX lZo/lTm77XtXRrr02/X2ixfHeqcut212iE0iSm5mIJUym02lvMSDEsOWyDYc 3XcQ2EhYx3EqwwysZtocxslbbLqwgueucl0prPrXTzxhT68fF8Gw8TcW8jM4 AAAAAAAAAAUKB9DoAAAAAFCgAVgAAAAAAAAKFAAMFAAAPPX1zkgxQEnqzWMe zmzGf4/jTczRHJrma1uPDJI3HUeDAcad8UYGhSEa7TaNzwPvYugDyh4q6zeT lxYssKr2xtVs3ZvB3N0gJSgnWCdibPOSs2DJcUQ/hvz60xGcN8gvUTUiIiBT 9ly/qkUkqBoKx3i67O9VUJBQ+83tDKKiDulJwJzy1X7c9Kne9l3bnYXKjUzN bu3cN04LaSkJxd2GiKU7flmwVeKLbh7j7wgt+tnw+zPusHS+/NCmlMfDxBIG PTyK+pvsaClK8UqVDEyJkoTJX1fDbe5eXebE4CAIEtDnc3wxQyJiDshn0Pkp 3jcvH0+qr992coRKwXdi+zO3gqsZHvlx97zcfIA0h7r9N9zCjXhxUsE/Xi2O HFhnM/pXcVkJS9IOJEBxZ1rYzabqk2HGPGy/t909eTNjucSFqzIzsrb5K/Ve TAwee+vS78vnnpPdxrNuYjc3ZRugAAAIAAA9c5zmO7nqd7ycJGbyiAwsULgA ELjUwB0ybwTSid8Xm8BdnqjIrutwcQ0tlFBfCrKjMOqBu75SqifTO3UWKNvV eqpq5Eejd1PT8Vi1tOBr+Z6+/fl94AaaZgIAIQFHRnLo5pBIEicZ387VkjAw ndw7PeCTST1d04XDWm6Npul4K0gtD+x9nux5Gn51EcMhtinet+v6zg3kGqKq u7udvjr6LsffTBSK7NxaZmrVjzUPLOyKQzhwHawJP0L7cg/rd/rNDBT8tR/C EniE+70W/iqvS/L0eg18qsYuFV9W3GvztdX9d34NiEn6zUVkXt6hOYh98zpv nL8U6A+CSLelJPIQ3KqEiPIaGvAsJdyijHwIO8GGZIDg4bjC/pGQY39+cYCA yTH4jUflfD78lKO0HMyG5LURi9CYR6BC5uaDjP7GnPkw+CXBGQwY3jcEF6Gn daon099uaBZQ++byxKm5DH9nvt+z7XnZH0kD79K5yvM3Mx+hCCSCY61IwiQi HM0rcUymigl0FxBuAcgfiFZrW5Qms0LuDIMgGvikkD4hcUOxQ72i4kiGmIBz eJ+vmsaSyLO0MgH6EiJ30p0ZpZ+KAl/sfr6Zz+/fft88noLokiDuBIPovOc5 n3udnt3nZL3Yb7e/nclzJ35M235mEbmXK2bqgAIAAAEAPe795yfz+TNm5B2R eEGQU72kDEWRskimdShzB9E9AbIsIu2JcUuCEx9yYecoC5IKUQcwZumbobNy g6wX9sOywuCPIgMe5wBaB4IBIfInkJC3bm6ta1mCkgYREFKhqDgfBAK4m+9G Dzzkz9eACkNBI+TE4EkQsYat3u6ezHGGECEMYhPsbsn79sn8zkn3O8zcnOXl +e73ADTTMBMFQCA/Sfzvdfs9edub+vc9M76o9UzMx6MIdJUVo5McCOIskl1F xyJ92ucLs5+/fUYU5CRD8Seo3dJjp4lnSBNUlMamr17Pqvedh4gO+5CSwuHC E5ur0XzPE999oEomUkKEiZuKrM9WD4fBhakMwOTsSwkh+963RDBHxP1V8fU8 Y5ivvlI9gSRDohghPed3YZD394jAj9rII5U6waqXfRjvTe8Z9GAsEkwQ+++c BIygNxMAmHxdJIDykCkwmuU2+rRdyZDDWYchqKVBaUzj6J7HfqnLmtyNA++d wksOB0nCzMzu+3d0Wq5uCkv8nFoCvmAcI1TfJXb/HK7hHncQ3oiRS2ElYYfB PYZIcsFWsy/yZOefy+8/EAFYAaaAwUCAIEAFYAaaAwUCYKBAECAPveu50Bpo DH9KdggAIA/d67nQGmgMFAgj+piA5KAQgqgh/WaEaioI1FGoipIJIkgiDIIF xRAhRdFSZJmZkyTM3dvyf0+f7ASsAEAFYAaaCswUCAAgArADTQGCgTTQCACs ANNAYKBAAQAVgBpoDBRgmUoCACsGmmmgMFAhABABWAGmgMFA4gAQAVgBpoDE JYBAAR+DpWAGmgMFAiABABWAGmwBgoEABABR+73ud6BpoDBTkzAgBvDYAKzJ I9d671V1oZ873uOl5ySTkboSpOScwGckk5BYLzknJGBUz13ve9zkkk4NrX5J JOTud71gobJyTkJoJJJOQaTc5yQUXnJJyG4Hmc5JOT15555vW4xo5rWtamwQ BAyqiZzjOFQMYxgrGN00Hmck73vQVn7ve96NNAYKBAAQGmqwA00BgoHMIlGm oAKwA00BgoEABABWAGmgMFA4FYCIAVgBpoDBQIeT355554EAFYAaaAmCgRAA gArADTQGCgQAEAFYAjUTQGf1BAEDfrrF8mzvG5JJDMkmM6MlSTLmPcSRJERB ERERERERER7yIiJL2gCJIIkiAiICIgn0SRAESEESRIRARPhAiCJIhIgIiAiU iInpIl1dfKq+++6+uEkQQEQRERERERERERE+IiIiIiIhyAEAd3fHzeuq69ER ERERERAoDrnm+SAhBEQQRERERERERERETyIiIiIIiHIIiIciAAd4Drnzer45 CRERERERERERERERERE9xEoRERKQAgI6719Xr4EJEEREREREREREREREREe8 hInCIiJSAQBd3rXmAJEkERERERERERERERERNEQRDkEREORIgAOQO7u6+CIi JSIiIciEAFV9Xq+eQkEEERERBERERERER7yIiIiIiJyIcgAHp3c+r18iEiCI iCIiIiIiIiIiIiJ7iIiIAiIcgEAXd687wAkSREREREREREREREREREO7qt8X nwISIIiIiIkJCQkYpPAgCB/MEAQIn+gIAgQP+MUEEDCJ0FQZEAFGQgFCACB/ 6D/8CAIH+YIAgf2D/UQAQP8gQBA/2DACAIH/YEAQLEDgIAgbBAED+4IAgdEA ED/QEAQOh/cEAQNggCBAQBA/uCAIH+4IAgYBAED/YLBAEDAIAgf7WhIIiISD IqArAEBAwCAIHAQBA/3BAED+QIAgeBQBA/CqoBQIAgRXgKAIEUIKqgH8w+BA ED+AyH+oIAgYBAED4EAQP7iqoB/uIH9AQBAsP6iqoB+BAEDYIF1X/hdyRThQ kKLfP+4= --0-121837636-1110145530=:5816-- From owner-freebsd-net@FreeBSD.ORG Sun Mar 6 23:48:21 2005 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 8D9D016A4CF for ; Sun, 6 Mar 2005 23:48:21 +0000 (GMT) Received: from mx01.stofanet.dk (mx01.stofanet.dk [212.10.10.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 29B1443D49 for ; Sun, 6 Mar 2005 23:48:20 +0000 (GMT) (envelope-from gammelgaard@bigfoot.com) Received: from 3e6b121a.rev.stofanet.dk ([62.107.18.26] helo=snogebaeksvej.dyndns.dk) by mx01.stofanet.dk (envelope-from ) with esmtp id 1D85Tr-0007QZ-0n; Mon, 07 Mar 2005 00:48:16 +0100 Received: from localhost (localhost.my.domain [127.0.0.1]) by snogebaeksvej.dyndns.dk (Postfix) with ESMTP id 9F26157C; Mon, 7 Mar 2005 00:48:14 +0100 (CET) Received: from snogebaeksvej.dyndns.dk ([127.0.0.1]) by localhost (snog.my.domain [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28941-08; Mon, 7 Mar 2005 00:48:07 +0100 (CET) Received: from [10.0.0.44] (unknown [10.0.0.44]) by snogebaeksvej.dyndns.dk (Postfix) with ESMTP; Mon, 7 Mar 2005 00:48:07 +0100 (CET) Message-ID: <422B96B8.4040501@bigfoot.com> Date: Mon, 07 Mar 2005 00:48:08 +0100 From: Henrik Gammelgaard User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: spork@fasttrackmonkey.com References: <20050305024850.GA96307@wjv.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 4.x and OS-X tcp 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: Sun, 06 Mar 2005 23:48:21 -0000 Charles Sprickman wrote: > > I'd really like to move past the duplex issues. I'm very very > familiar with that and already chased my tail on that one here and in > my many years of working at an ISP. I did a back-to-back test with > speed/duplex locked and I get the same result. All the switch ports > are running clean - no errors, which is something you'd normally see > if autoneg failed. > > Plus if you look at the matrix above, you can see that every other > combination in my "normal" config works. If there were a duplex > problem, I would be seeing it either from OS-X <-> OBSD or FBSD <-> > OBSD. It also probably wouldn't allow me to get really fast UDP NFS > between the boxes. > > For fun I'm going to post a full tcpdump of an ftp session from one > box to the other, maybe someone can spot something there? It's > attached and bzip'd. It's a tcpdump of both hosts transferring a 1MB > tarfile. > > Thanks! > > Charles > I also had a problem recently with my PB running OS X 10.3.8 and an OpenBSD 3.6 box - no duplex settings helped and TCP performance was very very poor, just getting a working ssh connection from mac -> openbsd took maybe 10mins, oddly UDP traffic worked as it was supposed to. I didnt find the problem except that it worked OK once I replaced the NIC in the OpenBSD box with another one, think the original one was a very cheap lowend one and I replaced it with an old 3Com NIC and everything worked. With kinds regards, Henrik From owner-freebsd-net@FreeBSD.ORG Mon Mar 7 09:08:09 2005 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 AE6D916A4CE for ; Mon, 7 Mar 2005 09:08:09 +0000 (GMT) Received: from insomnia.benzedrine.cx (insomnia.benzedrine.cx [62.65.145.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id D1BB543D39 for ; Mon, 7 Mar 2005 09:08:08 +0000 (GMT) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (dhartmei@localhost [127.0.0.1]) j27983nF021361 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Mon, 7 Mar 2005 10:08:03 +0100 (MET) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.13.3/8.12.10/Submit) id j27982I1025368; Mon, 7 Mar 2005 10:08:02 +0100 (MET) Date: Mon, 7 Mar 2005 10:08:02 +0100 From: Daniel Hartmeier To: Charles Sprickman Message-ID: <20050307090802.GR26999@insomnia.benzedrine.cx> References: <20050305024850.GA96307@wjv.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 4.x and OS-X tcp 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: Mon, 07 Mar 2005 09:08:09 -0000 On Sun, Mar 06, 2005 at 04:45:30PM -0500, Charles Sprickman wrote: > For fun I'm going to post a full tcpdump of an ftp session from one box to > the other, maybe someone can spot something there? It's attached and > bzip'd. It's a tcpdump of both hosts transferring a 1MB tarfile. I can only find an FTP control connection and _one_ data connection in that dump. Client 192.168.0.40 is uploading one file of about 1.6MB to server home.manymonkeys.com. There's a pattern in the dump, looks like a TCP problem. The client pushes data to the server. Every now and then, packets are lost. Mostly, the client retransmits normally. But ten times, it seems to ignore the server ACKing below a lost segment. It quickly gets several ACKs but only retransmits the lost segment after a full 1.4 seconds. This accounts for a total of 14.5 seconds of stalling the upload. The entire transfer is 15.02 seconds, so the 1.6MB are actually uploaded in 0.5 seconds, and the stalling entirely accounts for the slow throughput. Looks like the client is at fault. There's window scaling, but with scale factors 0. No SACK. I think the client should retransmit earlier. Which OS is running on which of those hosts? Which host did you tcpdump on (or was it on a third machine, in between)? Could you get a tcpdump from both server and client simultanously for the same connection, so we can see where packets are lost, and get both peers' point of view? Would be interesting to see a tcpdump of a connection from the same client (same OS) to a different server OS, which works fine. Daniel From owner-freebsd-net@FreeBSD.ORG Mon Mar 7 10:45:36 2005 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 817CD16A4CE for ; Mon, 7 Mar 2005 10:45:36 +0000 (GMT) Received: from obelix.sunrise.ch (mailrelay3.sunrise.ch [194.158.229.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F02C43D1F for ; Mon, 7 Mar 2005 10:45:33 +0000 (GMT) (envelope-from hampi@rootshell.be) Received: from gicco.homeip.net (pop-ls-13-2-dialup-146.freesurf.ch [194.230.159.146]) by obelix.sunrise.ch (8.12.10/8.12.10) with ESMTP id j27AjUhZ014454 for ; Mon, 7 Mar 2005 11:45:31 +0100 Received: from gicco.here (localhost [127.0.0.1]) by gicco.homeip.net (8.13.1/8.12.11) with ESMTP id j27AjOPx002017 for ; Mon, 7 Mar 2005 11:45:25 +0100 (CET) (envelope-from hampi@rootshell.be) Received: (from idefix@localhost) by gicco.here (8.13.1/8.12.11/Submit) id j27AjO7G002016 for freebsd-net@freebsd.org; Mon, 7 Mar 2005 11:45:24 +0100 (CET) (envelope-from hampi@rootshell.be) X-Authentication-Warning: gicco.here: idefix set sender to hampi@rootshell.be using -f Date: Mon, 7 Mar 2005 11:45:24 +0100 From: Hanspeter Roth To: freebsd-net@freebsd.org Message-ID: <20050307104524.GA1877@gicco.homeip.net> Mail-Followup-To: freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: disabling ipv6 with ppp 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, 07 Mar 2005 10:45:36 -0000 Hello, I'm using ppp. Even though INET6 is disabled in the kernel there is some INET6 stuff configured. Netstat -rn shows: ... Internet6: Destination Gateway Flags Netif Expire ::1 ::1 UH lo0 fe80::%lo0/64 fe80::1%lo0 U lo0 fe80::1%lo0 link#4 UHL lo0 ff01::/32 ::1 U lo0 ff02::%lo0/32 ::1 UC lo0 ff02::%tun0/32 fe80::20f:3dff:feae:5416%tun0 UGS tun0 The last route to 'ff02::%tun0/32' appears only if ppp is running. Some seconds after ppp is startet (ppp -quiet -auto isp) it goes online. Trying to delete the route by hand claims it is a bad address: route delete 'ff02::%tun0/32' route: bad address: ff02::%tun0/32 How can I run ppp without INET6 support? -Hanspeter From owner-freebsd-net@FreeBSD.ORG Mon Mar 7 11:01:25 2005 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 C4AAF16A4EF for ; Mon, 7 Mar 2005 11:01:25 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8BEFD43D2D for ; Mon, 7 Mar 2005 11:01:25 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j27B1PjR037210 for ; Mon, 7 Mar 2005 11:01:25 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j27B1ON1037204 for freebsd-net@freebsd.org; Mon, 7 Mar 2005 11:01:24 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 7 Mar 2005 11:01:24 GMT Message-Id: <200503071101.j27B1ON1037204@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, 07 Mar 2005 11:01:25 -0000 Current FreeBSD problem reports Critical problems Serious problems Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/07/11] kern/54383 net [nfs] [patch] NFS root configurations wit 1 problem total. From owner-freebsd-net@FreeBSD.ORG Mon Mar 7 15:16:41 2005 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 65A7916A4CE for ; Mon, 7 Mar 2005 15:16:41 +0000 (GMT) Received: from r-dd.iij4u.or.jp (r-dd.iij4u.or.jp [210.130.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB3A243D39 for ; Mon, 7 Mar 2005 15:16:40 +0000 (GMT) (envelope-from demizu@dd.iij4u.or.jp) Received: from localhost (124.117.138.210.xn.2iij.net [210.138.117.124]) by r-dd.iij4u.or.jp (8.11.6+IIJ/8.11.6) with ESMTP id j27FGd107241; Tue, 8 Mar 2005 00:16:39 +0900 (JST) Date: Tue, 08 Mar 2005 00:17:14 +0900 (JST) Message-Id: <20050308.001714.41652371.Noritoshi@Demizu.ORG> From: Noritoshi Demizu To: freebsd-net@freebsd.org X-Mailer: Mew version 4.1 on Emacs 21 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Why TCP_MAX_SACK == 3 ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2005 15:16:41 -0000 In netinet/tcp.h, TCP_MAX_SACK is defined as follows. #define TCP_MAX_SACK 3 /* MAX # SACKs sent in any segment */ Shouldn't it be 4? If a peer node does not use TCP timestamps option, four SACK blocks can be sent. For example, if my memory serves correctly, Microsoft Windows does not use TCP timestamps option by default. By the way, currently, both window scale option and timestamps option are controled by one sysctl variable: net.inet.tcp.rfc1323. Wouldn't it be nice if each option had its own sysctl variable? Regards, Noritoshi Demizu From owner-freebsd-net@FreeBSD.ORG Mon Mar 7 16:39:51 2005 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 D7B5016A4CE for ; Mon, 7 Mar 2005 16:39:51 +0000 (GMT) Received: from mxsf28.cluster1.charter.net (mxsf28.cluster1.charter.net [209.225.28.228]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6573943D5A for ; Mon, 7 Mar 2005 16:39:51 +0000 (GMT) (envelope-from c0ldbyte@myrealbox.com) Received: from mxip12.cluster1.charter.net (mxip12a.cluster1.charter.net [209.225.28.142])j27Gdok8025554 for ; Mon, 7 Mar 2005 11:39:50 -0500 Received: from 24.247.253.134.gha.mi.chartermi.net (HELO eleanor.us1.wmi.uvac.net) (24.247.253.134) by mxip12.cluster1.charter.net with ESMTP; 07 Mar 2005 11:39:50 -0500 X-Ironport-AV: i="3.90,143,1107752400"; d="scan'208"; a="859461029:sNHT12443616" Date: Mon, 7 Mar 2005 11:39:46 -0500 (EST) From: c0ldbyte To: Noritoshi Demizu In-Reply-To: <20050308.001714.41652371.Noritoshi@Demizu.ORG> Message-ID: <20050307113917.V15707@eleanor.us1.wmi.uvac.net> References: <20050308.001714.41652371.Noritoshi@Demizu.ORG> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-net@freebsd.org Subject: Re: Why TCP_MAX_SACK == 3 ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2005 16:39:52 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 8 Mar 2005, Noritoshi Demizu wrote: > In netinet/tcp.h, TCP_MAX_SACK is defined as follows. > > #define TCP_MAX_SACK 3 /* MAX # SACKs sent in any segment */ > > Shouldn't it be 4? If a peer node does not use TCP timestamps option, > four SACK blocks can be sent. For example, if my memory serves correctly, > Microsoft Windows does not use TCP timestamps option by default. > > > By the way, currently, both window scale option and timestamps option > are controled by one sysctl variable: net.inet.tcp.rfc1323. > Wouldn't it be nice if each option had its own sysctl variable? > > Regards, > Noritoshi Demizu As Im showing in my source tree for 4.11 \ #define TCPOPT_SACK_PERMITTED 4 /* Experimental */ #define TCPOLEN_SACK_PERMITTED 2 #define TCPOPT_SACK 5 /* Experimental */ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) Comment: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xF7DF979F iD8DBQFCLIPVsmFQuvffl58RAg6ZAJ93OjZxUnjzmzVDFCsYV6vF1VSRbwCcDeTL 0Lk/WpovPFMPV9c3thb/FPY= =wKZs -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Mon Mar 7 19:04:07 2005 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 D02D016A4CE for ; Mon, 7 Mar 2005 19:04:07 +0000 (GMT) Received: from angryfist.fasttrackmonkey.com (angryfist.fasttrackmonkey.com [216.223.196.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id F193043D55 for ; Mon, 7 Mar 2005 19:04:06 +0000 (GMT) (envelope-from spork@fasttrackmonkey.com) Received: (qmail 63327 invoked by uid 2003); 7 Mar 2005 18:58:32 -0000 Received: from spork@fasttrackmonkey.com by angryfist.fasttrackmonkey.com by uid 1001 with qmail-scanner-1.20 (clamscan: 0.65. Clear:RC:1(216.220.116.154):. Processed in 0.100275 secs); 07 Mar 2005 18:58:32 -0000 Received: from unknown (HELO localhost) (216.220.116.154) by 0 with (DHE-RSA-AES256-SHA encrypted) SMTP; 7 Mar 2005 18:58:31 -0000 Date: Mon, 7 Mar 2005 14:04:01 -0500 (EST) From: Charles Sprickman X-X-Sender: spork@oof.local To: Daniel Hartmeier In-Reply-To: <20050307090802.GR26999@insomnia.benzedrine.cx> Message-ID: References: <20050305024850.GA96307@wjv.com> <20050307090802.GR26999@insomnia.benzedrine.cx> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 4.x and OS-X tcp 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: Mon, 07 Mar 2005 19:04:07 -0000 On Mon, 7 Mar 2005, Daniel Hartmeier wrote: > On Sun, Mar 06, 2005 at 04:45:30PM -0500, Charles Sprickman wrote: > >> For fun I'm going to post a full tcpdump of an ftp session from one box to >> the other, maybe someone can spot something there? It's attached and >> bzip'd. It's a tcpdump of both hosts transferring a 1MB tarfile. > > I can only find an FTP control connection and _one_ data connection in > that dump. Client 192.168.0.40 is uploading one file of about 1.6MB to > server home.manymonkeys.com. Correct. 192.168.0.40 is the OS-X box, home.manymonkeys.com (192.168.0.6) is the FreeBSD box. I sent a 1.6MB tar archive via ftp. > There's a pattern in the dump, looks like a TCP problem. The client > pushes data to the server. Every now and then, packets are lost. Mostly, > the client retransmits normally. But ten times, it seems to ignore the > server ACKing below a lost segment. It quickly gets several ACKs but > only retransmits the lost segment after a full 1.4 seconds. This > accounts for a total of 14.5 seconds of stalling the upload. The entire > transfer is 15.02 seconds, so the 1.6MB are actually uploaded in 0.5 > seconds, and the stalling entirely accounts for the slow throughput. Very interesting, thank you for that read of the tcpdump output. If you have the time, could you post back a few lines of the tcpdump with comments so that I might learn a little about what's going on? I don't have the best understanding of the intricacies of tcp... > Looks like the client is at fault. There's window scaling, but with > scale factors 0. No SACK. I think the client should retransmit earlier. > > Which OS is running on which of those hosts? Which host did you tcpdump > on (or was it on a third machine, in between)? Could you get a tcpdump > from both server and client simultanously for the same connection, so we > can see where packets are lost, and get both peers' point of view? The tcpdump was run on the server (FBSD). Later today I will gladly do this again with a dump from each side. > Would be interesting to see a tcpdump of a connection from the same > client (same OS) to a different server OS, which works fine. I will do that as well from both ends. The other box will be OpenBSD 3.3 (anything beyond 3.3 panics on boot, so I'm stuck at 3.3). For giggles I'll do a dump of a transfer via udp (NFS) between the problem boxes to see if any packet loss is happening... Thanks very much, Charles > Daniel > From owner-freebsd-net@FreeBSD.ORG Mon Mar 7 20:48:32 2005 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 5107416A4CE for ; Mon, 7 Mar 2005 20:48:32 +0000 (GMT) Received: from insomnia.benzedrine.cx (insomnia.benzedrine.cx [62.65.145.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5935343D5D for ; Mon, 7 Mar 2005 20:48:31 +0000 (GMT) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (dhartmei@localhost [127.0.0.1]) j27KmRm6008515 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Mon, 7 Mar 2005 21:48:27 +0100 (MET) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.13.3/8.12.10/Submit) id j27KmPRu021213; Mon, 7 Mar 2005 21:48:25 +0100 (MET) Date: Mon, 7 Mar 2005 21:48:25 +0100 From: Daniel Hartmeier To: Charles Sprickman Message-ID: <20050307204825.GY26999@insomnia.benzedrine.cx> References: <20050305024850.GA96307@wjv.com> <20050307090802.GR26999@insomnia.benzedrine.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 4.x and OS-X tcp 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: Mon, 07 Mar 2005 20:48:32 -0000 On Mon, Mar 07, 2005 at 02:04:01PM -0500, Charles Sprickman wrote: > Very interesting, thank you for that read of the tcpdump output. If you > have the time, could you post back a few lines of the tcpdump with > comments so that I might learn a little about what's going on? I don't > have the best understanding of the intricacies of tcp... Data is flowing only in one direction (from client to server), so we see the client sending payload and the server acknowledging it. As long as no packets are lost and the server keeps acknowledging, the client could send one continuous stream of maximum sized payload packets. However, if the server stops acknowledging, the client must stop sending more data once it has filled up the window advertised by the server and wait for the server to either acknowledge further data or increase its window. Nothing exciting happens until timestamp 16:41:29.008909 in your log. 16:41:29.008672 client 321457:322905(1448) 16:41:29.008751 server ack 322905 win 7240 16:41:29.008909 client 324353:325801(1448) Since the log represents the server's view, the lack of segment 324353:322905 in the log means that this packet from the client was lost in transit. Now the server keeps acknowledging 322905, and we expect the client to notice and retransmit the lost segment. 16:41:29.009064 server ack 322905 win 7400 16:41:29.009146 client 325801:327249(1448) 16:41:29.009233 server ack 322905 win 8424 16:41:29.009409 client 328697:330145(1448) 16:41:29.009521 server ack 322905 win 9448 The client hasn't noticed yet and is still sending further segments past the gap. The server is advertising increasing window sizes, probably because it's still draining the data up to the gap. Notice that there's a new gap created as 327249:328697(1448) was lost. 16:41:29.011250 client 335937:337385(1448) 16:41:29.011331 server ack 322905 win 14568 Now the client has filled up the window. If it doesn't retransmit now, it has to stall. It can't send anymore higher segments because the window is full. 16:41:29.011758 client 322905:324353(1448) Finally, the retransmit. 16:41:29.011919 server ack 327249 win 10224 Now the server acknowledges up the the second gap. 16:41:29.021620 server ack 327249 win 13296 ... 16:41:29.024911 server ack 327249 win 56304 And keeps acknowledging the same, while the window grows again. But nothing from the client. 16:41:29.146218 192.168.0.40.58347 > home.manymonkeys.com.ftp: . ack 376 win 65535 (DF) [tos 0x10] Odd, an acknowledgment on the FTP control connection just at this time. I don't know what that means, but it's not a coincidence, I'd bet. 16:41:30.462822 client 327249:328697(1448) Now the client finally retransmitted the segment from the second gap. But look at the timestamp, about 1.4 seconds have passed, which is much too long. After that, things go back to normal. The same thing repeats nine more times throughout the connection. You can spot the places by comparing subsequent timestamps. You'll find the spots where there are >1s delays in between two packets. > The tcpdump was run on the server (FBSD). Later today I will gladly do > this again with a dump from each side. Before we blame the client, let's look at the dump from the client. Maybe the client is trying to retransmit earlier, but those packets get lost. It's just odd that this would happen for more than a full second. Daniel From owner-freebsd-net@FreeBSD.ORG Mon Mar 7 22:42:24 2005 Return-Path: Delivered-To: freebsd-net@www.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F37016A4CE; Mon, 7 Mar 2005 22:42:24 +0000 (GMT) Received: from mail.sbb.co.yu (mail.sbb.co.yu [82.117.194.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 519FE43D1D; Mon, 7 Mar 2005 22:42:23 +0000 (GMT) (envelope-from ggajic@mail.sbb.co.yu) Received: from mail.sbb.co.yu (mail.sbb.co.yu [192.168.1.2] (may be forged)) by mail.sbb.co.yu (8.13.3/8.13.3) with ESMTP id j27MgKDb034547; Mon, 7 Mar 2005 23:42:20 +0100 (CET) Date: Mon, 7 Mar 2005 23:42:20 +0100 (CET) From: Goran Gajic To: freebsd-amd64@www.freebsd.org, freebsd-net@www.freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-SBB-MailScanner-Information: Please contact the ISP for more information X-SBB-MailScanner: Found to be clean X-MailScanner-From: ggajic@mail.sbb.co.yu Subject: ipfilter 4.1.6 won't build on FreeBSD5.3 amd64 (fwd) 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, 07 Mar 2005 22:42:24 -0000 Hi, I have tried to build ipfilter 4.1.6 as module and as part of kernel on FreeBSD 5.3 on amd64 but in both cases I have failed. When I use option IPFILTER in kernel config this is what I get: cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I../../.. -I../../../contrib/dev/acpica -I../../../contrib/altq -I../../../contrib/ipfilter -I../../../contrib/pf -I../../../contrib/dev/ath -I../../../contrib/dev/ath/freebsd -I../../../contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror ../../../contrib/ipfilter/netinet/ip_frag.c ../../../contrib/ipfilter/netinet/ip_frag.c: In function `fr_ipid_newfrag': ../../../contrib/ipfilter/netinet/ip_frag.c:394: warning: cast to pointer from integer of different size ../../../contrib/ipfilter/netinet/ip_frag.c: In function `fr_ipid_knownfrag': ../../../contrib/ipfilter/netinet/ip_frag.c:579: warning: cast from pointer to integer of different size *** Error code 1 Stop in /usr/src/sys/amd64/compile/SENT. When I have tried to build ipf.ko this is what I get: ld -warn-common -r -d -o ipf.kld.5 ip_fil.o fil.o ml_ipl.o ip_nat.o ip_frag.o ip_state.o ip_proxy.o ip_auth.o ip_log.o ip_pool.o ip_htable.o ip_lookup.o ip_rules.o ip_scan.o ip_sync.o ld -Bshareable -d -warn-common -o ipf.ko ipf.kld.5 ld: ipf.kld.5: relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC ipf.kld.5: could not read symbols: Bad value *** Error code 1 Stop in /root/ip_fil4.1.6/BSD/FreeBSD-5.3-RELEASE-amd64. *** Error code 1 Stop in /root/ip_fil4.1.6. I have tried recompling with -fPIC but when I do kld_load ipf.ko this is what I get: sen# kldload /boot/kernel/ipf.ko dmesg output: kldload: can't load /boot/kernel/ipf.ko: Exec format error kldload: Unsupported file type kldload: unexpected relocation type 7 link_elf: symbol appr_check undefined So, my question is: can ipfilter be used to NAT something like 7000 hosts on FreeBSD? Currently I have cisco 7206 that is running IOS 12.3(4r)T1 only IOS that has NAT inside CEF (otherwise CPU load is something like 80% with this IOS it is something like 20% for 7000 hosts). I want my amd64 only to NAT inside network (10.1.0.0/16) but when I have tried ipfilter v3.4.35 that comes with freebsd5.3 (compiled with LARGE_NAT) it had poor performance. (it could handle something like 120000 connections although vaules in ip_nat.h were much greater, maybe I have missed some other parameters?). Machine has two broadcom NICs so I don't think that is problem, can someone advise what to do to? Regards, Goran Gajic From owner-freebsd-net@FreeBSD.ORG Tue Mar 8 00:08:33 2005 Return-Path: Delivered-To: freebsd-net@www.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2694816A4CE; Tue, 8 Mar 2005 00:08:33 +0000 (GMT) Received: from mxsf19.cluster1.charter.net (mxsf19.cluster1.charter.net [209.225.28.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D8EC43D1D; Tue, 8 Mar 2005 00:08:32 +0000 (GMT) (envelope-from c0ldbyte@myrealbox.com) Received: from mxip19.cluster1.charter.net (mxip19a.cluster1.charter.net [209.225.28.149])j2808UGG010668; Mon, 7 Mar 2005 19:08:31 -0500 Received: from 24.247.253.134.gha.mi.chartermi.net (HELO eleanor.us1.wmi.uvac.net) (24.247.253.134) by mxip19.cluster1.charter.net with ESMTP; 07 Mar 2005 19:08:30 -0500 X-Ironport-AV: i="3.90,145,1107752400"; d="scan'208"; a="789508998:sNHT14213372" Date: Mon, 7 Mar 2005 19:08:24 -0500 (EST) From: c0ldbyte To: Goran Gajic In-Reply-To: Message-ID: <20050307190552.M80041@eleanor.us1.wmi.uvac.net> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-amd64@www.freebsd.org cc: freebsd-net@www.freebsd.org Subject: Re: ipfilter 4.1.6 won't build on FreeBSD5.3 amd64 (fwd) 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, 08 Mar 2005 00:08:33 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 7 Mar 2005, Goran Gajic wrote: > Hi, > > I have tried to build ipfilter 4.1.6 as module and as part of kernel on > FreeBSD 5.3 on amd64 but in both cases I have failed. When I use > option IPFILTER in kernel config this is what I get: > > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -Wall > -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc > -I- -I. -I../../.. -I../../../contrib/dev/acpica -I../../../contrib/altq > -I../../../contrib/ipfilter > -I../../../contrib/pf -I../../../contrib/dev/ath > -I../../../contrib/dev/ath/freebsd -I../../../contrib/ngatm -D_KERNEL > -include opt_global.h -fno-common -finline-limit=8000 --param > inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=kernel > -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow > -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror > .../../../contrib/ipfilter/netinet/ip_frag.c > .../../../contrib/ipfilter/netinet/ip_frag.c: In function `fr_ipid_newfrag': > .../../../contrib/ipfilter/netinet/ip_frag.c:394: warning: cast to pointer > from integer of different size > .../../../contrib/ipfilter/netinet/ip_frag.c: In function > `fr_ipid_knownfrag': > .../../../contrib/ipfilter/netinet/ip_frag.c:579: warning: cast from pointer > to integer of different size > *** Error code 1 > > Stop in /usr/src/sys/amd64/compile/SENT. > > > When I have tried to build ipf.ko this is what I get: > ld -warn-common -r -d -o ipf.kld.5 ip_fil.o fil.o ml_ipl.o ip_nat.o ip_frag.o > ip_state.o ip_proxy.o ip_auth.o ip_log.o ip_pool.o ip_htable.o ip_lookup.o > ip_rules.o ip_scan.o ip_sync.o > ld -Bshareable -d -warn-common -o ipf.ko ipf.kld.5 > ld: ipf.kld.5: relocation R_X86_64_32 can not be used when making a shared > object; recompile with -fPIC > ipf.kld.5: could not read symbols: Bad value > *** Error code 1 > > Stop in /root/ip_fil4.1.6/BSD/FreeBSD-5.3-RELEASE-amd64. > *** Error code 1 > > Stop in /root/ip_fil4.1.6. > > I have tried recompling with -fPIC but when I do kld_load ipf.ko this is what > I get: > sen# kldload /boot/kernel/ipf.ko > dmesg output: > kldload: can't load /boot/kernel/ipf.ko: Exec format error > kldload: Unsupported file type > kldload: unexpected relocation type 7 > link_elf: symbol appr_check undefined > > > So, my question is: can ipfilter be used to NAT something like 7000 hosts on > FreeBSD? Currently I have cisco 7206 that is running IOS 12.3(4r)T1 only IOS > that has NAT inside CEF (otherwise CPU load is something like 80% with this > IOS it is something like 20% for 7000 hosts). I want my amd64 only to NAT > inside network (10.1.0.0/16) but when I have tried ipfilter > v3.4.35 that comes with freebsd5.3 (compiled with LARGE_NAT) it had poor > performance. (it could handle something like 120000 connections although > vaules in ip_nat.h were much greater, maybe I have missed some other > parameters?). Machine has two broadcom NICs so I don't think that is > problem, can someone advise what to do to? > > Regards, > Goran Gajic Are those CFLAGS=-O2, a standard compilation or is that something you added to the make.conf ?. Ive tried some optimizations myself well building the kernel and its modules and got a very sparse build of things they dont seem to build to well when being built with -O2 opts. Good luck and best regards, check your /etc/make.conf -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) Comment: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xF7DF979F iD8DBQFCLOz8smFQuvffl58RAp8HAJ4qcQuzBU3uI9koXuoypA2lJaw6jgCeNk7O 1ffKaacnysptQNLxaaP17TE= =A712 -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Tue Mar 8 07:04:27 2005 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 407F816A4CE for ; Tue, 8 Mar 2005 07:04:27 +0000 (GMT) Received: from angryfist.fasttrackmonkey.com (angryfist.fasttrackmonkey.com [216.223.196.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7CD8943D4C for ; Tue, 8 Mar 2005 07:04:24 +0000 (GMT) (envelope-from spork@fasttrackmonkey.com) Received: (qmail 76321 invoked by uid 2003); 8 Mar 2005 06:58:49 -0000 Received: from spork@fasttrackmonkey.com by angryfist.fasttrackmonkey.com by uid 1001 with qmail-scanner-1.20 (clamscan: 0.65. Clear:RC:1(216.220.116.154):. Processed in 0.049932 secs); 08 Mar 2005 06:58:49 -0000 Received: from unknown (HELO localhost) (216.220.116.154) by 0 with (DHE-RSA-AES256-SHA encrypted) SMTP; 8 Mar 2005 06:58:49 -0000 Date: Tue, 8 Mar 2005 02:04:20 -0500 (EST) From: Charles Sprickman X-X-Sender: spork@oof.local To: Daniel Hartmeier In-Reply-To: <20050307204825.GY26999@insomnia.benzedrine.cx> Message-ID: References: <20050305024850.GA96307@wjv.com> <20050307090802.GR26999@insomnia.benzedrine.cx> <20050307204825.GY26999@insomnia.benzedrine.cx> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 4.x and OS-X tcp 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, 08 Mar 2005 07:04:27 -0000 Hello all, As promised, I have 4 tcpdump traces (saved with the "-w" option per request of another poster). Since these are a little too big to be broadcast to everyone on the list, I'm posting them here: http://home.manymonkeys.com/tcpdump/ For all tests I used os-x's command line ftp program and uploaded a 1.7MB file to each system. tcpdump.osx-fbsd - tcpdump ran on os-x box while transferring to FBSD tcpdump.fbsd-osx - tcpdump ran on FBSD box while transferring from os-x tcpdump.osx-obsd - tcpdump ran on os-x box while transferring to OBSD tcpdump.obsd-osx - tcpdump ran on OBSD box while transferring from os-x So there's a view of a single file transfer on each run of the test. Observing this showed that the os-x to fbsd transfer went at about 200KB/s and the os-x to obsd transfer went at about 2.6MB/s. Again I'd like to note that the OpenBSD box is at 3.3, which may prove important since it's quite dated. If there's anything else I can provide, let me know. Thanks, Charles On Mon, 7 Mar 2005, Daniel Hartmeier wrote: > On Mon, Mar 07, 2005 at 02:04:01PM -0500, Charles Sprickman wrote: > >> Very interesting, thank you for that read of the tcpdump output. If you >> have the time, could you post back a few lines of the tcpdump with >> comments so that I might learn a little about what's going on? I don't >> have the best understanding of the intricacies of tcp... > > Data is flowing only in one direction (from client to server), so we > see the client sending payload and the server acknowledging it. > > As long as no packets are lost and the server keeps acknowledging, the > client could send one continuous stream of maximum sized payload packets. > However, if the server stops acknowledging, the client must stop sending > more data once it has filled up the window advertised by the server and > wait for the server to either acknowledge further data or increase its > window. > > Nothing exciting happens until timestamp 16:41:29.008909 in your log. > > 16:41:29.008672 client 321457:322905(1448) > 16:41:29.008751 server ack 322905 win 7240 > 16:41:29.008909 client 324353:325801(1448) > > Since the log represents the server's view, the lack of segment > 324353:322905 in the log means that this packet from the client was lost > in transit. Now the server keeps acknowledging 322905, and we expect the > client to notice and retransmit the lost segment. > > 16:41:29.009064 server ack 322905 win 7400 > 16:41:29.009146 client 325801:327249(1448) > 16:41:29.009233 server ack 322905 win 8424 > 16:41:29.009409 client 328697:330145(1448) > 16:41:29.009521 server ack 322905 win 9448 > > The client hasn't noticed yet and is still sending further segments past > the gap. The server is advertising increasing window sizes, probably > because it's still draining the data up to the gap. > > Notice that there's a new gap created as 327249:328697(1448) was lost. > > 16:41:29.011250 client 335937:337385(1448) > 16:41:29.011331 server ack 322905 win 14568 > > Now the client has filled up the window. If it doesn't retransmit now, > it has to stall. It can't send anymore higher segments because the > window is full. > > 16:41:29.011758 client 322905:324353(1448) > > Finally, the retransmit. > > 16:41:29.011919 server ack 327249 win 10224 > > Now the server acknowledges up the the second gap. > > 16:41:29.021620 server ack 327249 win 13296 > ... > 16:41:29.024911 server ack 327249 win 56304 > > And keeps acknowledging the same, while the window grows again. But > nothing from the client. > > 16:41:29.146218 192.168.0.40.58347 > home.manymonkeys.com.ftp: . ack 376 > win 65535 (DF) [tos 0x10] > > Odd, an acknowledgment on the FTP control connection just at this time. > I don't know what that means, but it's not a coincidence, I'd bet. > > 16:41:30.462822 client 327249:328697(1448) > > Now the client finally retransmitted the segment from the second gap. > But look at the timestamp, about 1.4 seconds have passed, which is much > too long. > > After that, things go back to normal. > > The same thing repeats nine more times throughout the connection. You > can spot the places by comparing subsequent timestamps. You'll find the > spots where there are >1s delays in between two packets. > >> The tcpdump was run on the server (FBSD). Later today I will gladly do >> this again with a dump from each side. > > Before we blame the client, let's look at the dump from the client. > Maybe the client is trying to retransmit earlier, but those packets get > lost. It's just odd that this would happen for more than a full second. > > Daniel > From owner-freebsd-net@FreeBSD.ORG Tue Mar 8 10:16:43 2005 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 61FE416A4CE for ; Tue, 8 Mar 2005 10:16:43 +0000 (GMT) Received: from insomnia.benzedrine.cx (insomnia.benzedrine.cx [62.65.145.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 844DD43D2D for ; Tue, 8 Mar 2005 10:16:41 +0000 (GMT) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (dhartmei@localhost [127.0.0.1]) j28AGY89013749 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 8 Mar 2005 11:16:34 +0100 (MET) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.13.3/8.12.10/Submit) id j28AGXxO025027; Tue, 8 Mar 2005 11:16:33 +0100 (MET) Date: Tue, 8 Mar 2005 11:16:33 +0100 From: Daniel Hartmeier To: Charles Sprickman Message-ID: <20050308101633.GC26999@insomnia.benzedrine.cx> References: <20050305024850.GA96307@wjv.com> <20050307090802.GR26999@insomnia.benzedrine.cx> <20050307204825.GY26999@insomnia.benzedrine.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 4.x and OS-X tcp 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, 08 Mar 2005 10:16:43 -0000 On Tue, Mar 08, 2005 at 02:04:20AM -0500, Charles Sprickman wrote: > http://home.manymonkeys.com/tcpdump/ > Observing this showed that the os-x to fbsd transfer went at about 200KB/s > and the os-x to obsd transfer went at about 2.6MB/s. In the osx-fbsd case we see the same problem again. This time we have both the client's and server's view, which confirms the theory. Server's view: 07:43:46.916089 client 4195626636:4195628084(1448) 07:43:46.916325 client 4195628084:4195629532(1448) 07:43:46.916431 server ack 4195629532 win 5792 [ 4195629532:4195630980(1448) lost ] 07:43:46.916525 client 4195630980:4195632428(1448) 07:43:46.916594 client 4195632428:4195633876(1448) 07:43:46.916618 server ack 4195629532 win 6576 07:43:46.916667 server ack 4195629532 win 6576 07:43:46.916982 client 4195633876:4195635324(1448) 07:43:46.917051 server ack 4195629532 win 7240 07:43:46.917322 server ack 4195629532 win 10672 07:43:46.917583 client 4195635324:4195636772(1448) 07:43:46.917653 server ack 4195629532 win 12720 07:43:46.917858 client 4195636772:4195638220(1448) 07:43:46.917927 server ack 4195629532 win 14768 07:43:46.917977 client 4195638220:4195639668(1448) 07:43:46.918019 server ack 4195629532 win 14768 07:43:46.918192 client 4195639668:4195641116(1448) 07:43:46.918250 server ack 4195629532 win 16816 07:43:46.918460 client 4195641116:4195642564(1448) 07:43:46.918526 server ack 4195629532 win 18864 07:43:46.918578 client 4195642564:4195644012(1448) 07:43:46.918620 server ack 4195629532 win 18864 07:43:46.918773 client 4195644012:4195645460(1448) 07:43:46.918824 server ack 4195629532 win 20912 07:43:46.919074 client 4195645460:4195646908(1448) 07:43:46.919150 server ack 4195629532 win 22960 07:43:46.919192 client 4195646908:4195648356(1448) 07:43:46.919240 server ack 4195629532 win 22960 07:43:46.919506 server ack 4195629532 win 26032 07:43:46.919743 server ack 4195629532 win 29104 07:43:46.920027 server ack 4195629532 win 32176 07:43:46.920246 server ack 4195629532 win 35248 07:43:46.920528 server ack 4195629532 win 38320 07:43:46.920797 server ack 4195629532 win 41392 07:43:46.921097 server ack 4195629532 win 44464 07:43:46.921325 server ack 4195629532 win 47536 07:43:46.921612 server ack 4195629532 win 50608 07:43:46.921866 server ack 4195629532 win 53680 07:43:46.923727 server ack 4195629532 win 56752 07:43:46.993124 client ack on control connection [ 1s later ] 07:43:47.963778 client 4195629532:4195630980(1448) [ this is the missing segment retransmitted ] 07:43:47.963989 server ack 4195648356 win 39096 [ fully ack'd again ] 07:43:47.964301 server ack 4195648356 win 42168 07:43:47.964517 server ack 4195648356 win 45240 07:43:47.964570 client 4195648356:4195649804(1448) [ fine again ] Client's view: 07:43:46.792191 client 4195626636:4195628084(1448) 07:43:46.792199 client 4195628084:4195629532(1448) 07:43:46.792203 client 4195629532:4195630980(1448) [ this is lost ] 07:43:46.792608 server ack 4195626636 win 7424 07:43:46.792617 client 4195630980:4195632428(1448) 07:43:46.792622 client 4195632428:4195633876(1448) 07:43:46.793186 server ack 4195629532 win 5792 07:43:46.793203 client 4195633876:4195635324(1448) 07:43:46.793357 server ack 4195629532 win 6576 07:43:46.793478 server ack 4195629532 win 6576 07:43:46.793789 server ack 4195629532 win 7240 07:43:46.793799 client 4195635324:4195636772(1448) 07:43:46.794058 server ack 4195629532 win 10672 07:43:46.794067 client 4195636772:4195638220(1448) 07:43:46.794071 client 4195638220:4195639668(1448) 07:43:46.794394 server ack 4195629532 win 12720 07:43:46.794405 client 4195639668:4195641116(1448) 07:43:46.794665 server ack 4195629532 win 14768 07:43:46.794675 client 4195641116:4195642564(1448) 07:43:46.794679 client 4195642564:4195644012(1448) 07:43:46.794788 server ack 4195629532 win 14768 07:43:46.794988 server ack 4195629532 win 16816 07:43:46.794997 client 4195644012:4195645460(1448) 07:43:46.795269 server ack 4195629532 win 18864 07:43:46.795284 client 4195645460:4195646908(1448) 07:43:46.795289 client 4195646908:4195648356(1448) 07:43:46.795396 server ack 4195629532 win 18864 07:43:46.795561 server ack 4195629532 win 20912 07:43:46.795893 server ack 4195629532 win 22960 07:43:46.796014 server ack 4195629532 win 22960 07:43:46.796244 server ack 4195629532 win 26032 07:43:46.796482 server ack 4195629532 win 29104 07:43:46.796763 server ack 4195629532 win 32176 07:43:46.796982 server ack 4195629532 win 35248 07:43:46.797271 server ack 4195629532 win 38320 07:43:46.797543 server ack 4195629532 win 41392 07:43:46.797837 server ack 4195629532 win 44464 07:43:46.798061 server ack 4195629532 win 47536 07:43:46.798370 server ack 4195629532 win 50608 07:43:46.798605 server ack 4195629532 win 53680 07:43:46.800482 server ack 4195629532 win 56752 07:43:46.869732 client ack on control connection [ 1s ] 07:43:47.839990 client 4195629532:4195630980(1448) [ retransmitting lost segment ] 07:43:47.840744 server ack 4195648356 win 39096 [ fully ack'd again ] 07:43:47.840794 client 4195648356:4195649804(1448) 07:43:47.840799 client 4195649804:4195651252(1448) 07:43:47.841044 server ack 4195648356 win 42168 07:43:47.841264 server ack 4195648356 win 45240 [ fine again ] So, only one packet was lost in this part, the 4195629532:4195630980(1448) segment from client to server. This single lost packet caused an entire second of stalling. Let's look at how much loss there is in the osx-fbsd connection: $ tcpdump -nvvvtttSr tcpdump.fbsd-osx | grep '192.168.0.40.60859 > 192.168.0.6.50154' | grep -v '(0)' | cut -d ' ' -f 8 >segs_sent_fbsd $ tcpdump -nvvvtttSr tcpdump.osx-fbsd | grep '192.168.0.40.60859 > 192.168.0.6.50154' | grep -v '(0)' | cut -d ' ' -f 8 >segs_recv_fbsd $ wc -l segs_sent_fbsd 1192 segs_sent_fbsd $ wc -l segs_recv_fbsd 1177 segs_recv_fbsd 15 packets lost out of 1177 sent -> 1.27% loss (8.621s for 1.7MB -> 201.8 KB/s) Trying to locate a similar problem in the osx-obsd case we don't find one, because there is no loss at all: $ tcpdump -nvvvtttSr tcpdump.osx-obsd | grep '192.168.0.40.60892 > 192.168.0.1.62496' | grep -v '(0)' | cut -d ' ' -f 8 >segs_sent_obsd $ tcpdump -nvvvtttSr tcpdump.obsd-osx | grep '192.168.0.40.60892 > 192.168.0.1.62496' | grep -v '(0)' | cut -d ' ' -f 8 >segs_recv_obsd $ wc -l segs_sent_obsd 1171 segs_sent_obsd $ wc -l segs_recv_obsd 1171 segs_recv_obsd 0 packets lost out of 1171 sent -> 0.00% loss (0.423s for 1.7MB -> 4.01 MB/s) Also, no ACKs are lost in either connection. So, there's two questions: a) Why is there packet loss in the osx-fbsd case but not in the osx-obsd case? This could indeed be a networking problem like duplex or an issue with the fbsd NIC driver (assuming the fault is in fbsd because the same client has no issue with another server). b) Is it expected that 1.27% packet loss in such a TCP connection reduces the throughput so dramatically? I don't think it should, the OS X client should retransmit earlier. Again the stalling is accounted for completely by the loss and retransmits: $ diff -u segs_sent_fbsd segs_recv_fbsd | grep '^-' -4195629532:4195630980(1448) -4195658492:4195659940(1448) -4195662836:4195664284(1448) -4195819220:4195820668(1448) -4195949540:4195950988(1448) -4195959676:4195961124(1448) -4196081308:4196082756(1448) -4196084204:4196085652(1448) -4196091444:4196092892(1448) -4196210180:4196211628(1448) -4196475164:4196476612(1448) -4196576524:4196577972(1448) -4196737252:4196738700(1448) -4196867572:4196869020(1448) -4196877708:4196879156(1448) 4195629532:4195630980(1448) 07:43:46.869732 - 07:43:47.839990 = 0.96s 4195658492:4195659940(1448) 07:43:47.845530 - 07:43:49.340046 = 1.49s 4195662836:4195664284(1448) 07:43:49.340769 4195819220:4195820668(1448) 07:43:49.361194 4195949540:4195950988(1448) 07:43:49.388882 - 07:43:50.840161 = 1.45s 4195959676:4195961124(1448) 07:43:49.383787 4196081308:4196082756(1448) 07:43:50.861454 - 07:43:52.340202 = 1.48s 4196084204:4196085652(1448) 07:43:52.340935 4196091444:4196092892(1448) 07:43:52.341543 4196210180:4196211628(1448) 07:43:52.357681 4196475164:4196476612(1448) 07:43:52.401159 4196576524:4196577972(1448) 07:43:52.427754 - 07:43:53.840338 = 1.41s 4196737252:4196738700(1448) 07:43:53.862330 4196867572:4196869020(1448) 07:43:53.890180 - 07:43:55.340416 = 1.45s 4196877708:4196879156(1448) 07:43:55.341186 Total time stalled 8.24s, total transfer time 8.621 Can someone confirm whether this is perfectly normal or looks like a problem in the client (OS X)? Daniel From owner-freebsd-net@FreeBSD.ORG Tue Mar 8 12:46:58 2005 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 661CA16A4CE for ; Tue, 8 Mar 2005 12:46:58 +0000 (GMT) Received: from insomnia.benzedrine.cx (insomnia.benzedrine.cx [62.65.145.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id A532843D5E for ; Tue, 8 Mar 2005 12:46:56 +0000 (GMT) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (dhartmei@localhost [127.0.0.1]) j28CkoMd019331 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 8 Mar 2005 13:46:51 +0100 (MET) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.13.3/8.12.10/Submit) id j28Cklfp019318; Tue, 8 Mar 2005 13:46:47 +0100 (MET) Date: Tue, 8 Mar 2005 13:46:46 +0100 From: Daniel Hartmeier To: Charles Sprickman Message-ID: <20050308124646.GF26999@insomnia.benzedrine.cx> References: <20050305024850.GA96307@wjv.com> <20050307090802.GR26999@insomnia.benzedrine.cx> <20050307204825.GY26999@insomnia.benzedrine.cx> <20050308101633.GC26999@insomnia.benzedrine.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050308101633.GC26999@insomnia.benzedrine.cx> User-Agent: Mutt/1.5.6i cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 4.x and OS-X tcp 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, 08 Mar 2005 12:46:58 -0000 According to RFC 793 (the original TCP specification), the client may (even should) wait at least one second before retransmitting any segment. However, RFC 2001 describes Fast Retransmission, where the third acknowledgment for the same segment should be interpreted as an indication of packet loss, and cause an immediate retransmission (without waiting for the timeout of at least one second). I'd have expected Mac OS X to both implement this and enable it by default, but maybe I'm wrong. There's a sysctl net.inet.tcp.newreno which defaults to 0, and which seems to affect things. If you google, you find patches like http://www.opendarwin.org/~fkr/xnu/mach_kernel-to-517.7.21-SACK.diff which doesn't just contain SACK code, but possibly fixes fast retransmissions when newreno is not set. I'm not sure if disabling the newreno sysctl should disable fast retransmissions, or whether that's a bug. So, the Mac OS X client is not wrong in honouring RFC 793 alone. It just suffers badly from any packet loss. For you, the more relevant question is why there's 1.2% packet loss between the Mac OS X client and FreeBSD server, even when connected directly with crossover. Daniel From owner-freebsd-net@FreeBSD.ORG Tue Mar 8 14:11:24 2005 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 1674316A4CE for ; Tue, 8 Mar 2005 14:11:24 +0000 (GMT) Received: from casselton.net (casselton.net [63.165.140.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9180F43D39 for ; Tue, 8 Mar 2005 14:11:23 +0000 (GMT) (envelope-from tinguely@casselton.net) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.12.11/8.12.11) with ESMTP id j28EB155001185; Tue, 8 Mar 2005 08:11:01 -0600 (CST) (envelope-from tinguely@casselton.net) Received: (from tinguely@localhost) by casselton.net (8.12.11/8.12.11/Submit) id j28EB0Hv001184; Tue, 8 Mar 2005 08:11:00 -0600 (CST) (envelope-from tinguely) Date: Tue, 8 Mar 2005 08:11:00 -0600 (CST) From: Mark Tinguely Message-Id: <200503081411.j28EB0Hv001184@casselton.net> To: daniel@benzedrine.cx, spork@fasttrackmonkey.com In-Reply-To: <20050308101633.GC26999@insomnia.benzedrine.cx> X-Spam-Status: No, score=1.4 required=5.0 tests=REPLY_TO_EMPTY autolearn=no version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on ccn.casselton.net cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 4.x and OS-X tcp 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, 08 Mar 2005 14:11:24 -0000 Basing from what I see in Daniel Hartmeier analysis of tcpdump (I honestly did not look at the original, when is has been summerized so conveniently): The server is not telling the client that a packet has been lost. The first two ACKs are correct duplicate ACKs, but the remaining ACKs coming from he server have window adjustments, so the client does not treat them as duplicate ACKs coming from a packet loss. --Mark Tinguely From owner-freebsd-net@FreeBSD.ORG Tue Mar 8 15:01:50 2005 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 9791816A4CF for ; Tue, 8 Mar 2005 15:01:50 +0000 (GMT) Received: from smtp4.wlink.com.np (smtp4.wlink.com.np [202.79.32.87]) by mx1.FreeBSD.org (Postfix) with SMTP id 5399E43D1D for ; Tue, 8 Mar 2005 15:01:47 +0000 (GMT) (envelope-from bikrant_ml@wlink.com.np) Received: (qmail 89688 invoked from network); 8 Mar 2005 15:01:42 -0000 Received: from unknown (HELO av-scanner-02.wlink.com.np) (202.79.32.91) by 0 with SMTP; 8 Mar 2005 15:01:42 -0000 Received: (qmail 83752 invoked by uid 1009); 8 Mar 2005 15:01:39 -0000 Received: from bikrant_ml@wlink.com.np by av-scanner-02.wlink.com.np by uid 1003 with qmail-scanner-1.20 ( Clear:RC:1(202.79.32.78):. Processed in 0.014521 secs); 08 Mar 2005 15:01:39 -0000 Received: from smtp3.wlink.com.np (202.79.32.78) by av-scanner-02.wlink.com.np with SMTP; 8 Mar 2005 15:01:39 -0000 Received: (qmail 7004 invoked by uid 514); 8 Mar 2005 15:01:42 -0000 Received: from [202.79.45.235] (HELO HOME) by smtp3.wlink.com.np (qmail-smtpd) with SMTP; 08 Mar 2005 15:01:41 -0000 (Tue, 08 Mar 2005 20:46:41 +0545) Message-ID: <002a01c523ef$bc5af280$eb2d4fca@HOME> From: "Bikrant Neupane" To: Date: Tue, 8 Mar 2005 20:46:38 +0545 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Check-By: smtp3.wlink.com.np Spam: No ; -4.9 / 5.0 X-Spam-Status-WL: No, hits=-4.9 required=5.0 cc: freebsd-net@freebsd.org Subject: Session Timeout issue in pppoed 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, 08 Mar 2005 15:01:50 -0000 Hi, I have a pppoe server on FreeBSD 4.10. I have configured my Radius Server ( radiator) to set Session-Timeout parameter so that the clients who are using prepaid hour based service get disconnected when their time is over. In the ppp.log file I see the the Sessio-Timeout being accepted by the server. In the mean time the same connection has another Session-Timeout parameter set whose value is 0!! As a result the clients do not get dsconnected at the specified time. I guess this is configuration issue/problem with ppp rather than pppoed. this is a portion of my ppp.log file. ppp[18466]: Phase: PPP Started (direct mode). ppp[18466]: Phase: bundle: Establish ppp[18466]: Phase: deflink: closed -> opening ppp[18466]: Phase: deflink: Link is a netgraph node ppp[18466]: Phase: deflink: Connected! ppp[18466]: Phase: deflink: opening -> carrier ppp[18466]: Phase: deflink: carrier -> lcp ppp[18466]: Phase: bundle: Authenticate ppp[18466]: Phase: deflink: his = none, mine = PAP ppp[18466]: Phase: Pap Input: REQUEST (gomez5) ppp[18466]: Phase: Radius: Request sent ppp[18466]: Phase: Radius(auth): ACCEPT received ppp[18466]: Phase: MTU 768 ppp[18466]: Phase: VJ enabled ppp[18466]: Phase: Session-Timeout 29218 <<<<< ppp[18466]: Phase: Session-Timeout 0 <<<<< ppp[18466]: Phase: Pap Output: SUCCESS ppp[18466]: Phase: deflink: lcp -> open ppp[18466]: Phase: bundle: Network ppp[18466]: Phase: Radius(acct): Accounting response received Here is my ppp.conf file default: allow users enable pap allow mode direct set mru 1492 set mtu 1492 set speed sync set timeout 172800 #2 days: 48hrs enable lqr set ifaddr 202.79.xx.xx 202.79.xx.xx-202.79.xx.xx load server set radius /etc/radius.conf accept dns Any idea why this is happening?? Please suggest. Thank you, Bikrant From owner-freebsd-net@FreeBSD.ORG Tue Mar 8 15:55:54 2005 Return-Path: Delivered-To: freebsd-net@www.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 85D3C16A4CE for ; Tue, 8 Mar 2005 15:55:54 +0000 (GMT) Received: from mail.sbb.co.yu (mail.sbb.co.yu [82.117.194.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id D361E43D48 for ; Tue, 8 Mar 2005 15:55:53 +0000 (GMT) (envelope-from ggajic@mail.sbb.co.yu) Received: from mail.sbb.co.yu (mail.sbb.co.yu [192.168.1.2] (may be forged)) by mail.sbb.co.yu (8.13.3/8.13.3) with ESMTP id j28FtohX005485 for ; Tue, 8 Mar 2005 16:55:50 +0100 (CET) Date: Tue, 8 Mar 2005 16:55:50 +0100 (CET) From: Goran Gajic To: freebsd-net@www.freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-SBB-MailScanner-Information: Please contact the ISP for more information X-SBB-MailScanner: Found to be clean X-MailScanner-From: ggajic@mail.sbb.co.yu Subject: Re: ipfilter 4.1.6 won't build on FreeBSD5.3 amd64 (fwd) 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, 08 Mar 2005 15:55:54 -0000 Here is diff that makes ipfilter 4.1.6 able to compile on amd64 as kernel option IPFILTER: --- ip_frag.c Tue Mar 8 13:51:04 2005 +++ ip_frag.c Tue Mar 8 14:53:46 2005 @@ -391,7 +398,7 @@ WRITE_ENTER(&ipf_ipidfrag); fra = ipfr_newfrag(fin, 0, ipfr_ipidtab); if (fra != NULL) { - fra->ipfr_data = (void *)ipid; + fra->ipfr_data = (void *)(intptr_t)ipid; *ipfr_ipidtail = fra; fra->ipfr_prev = ipfr_ipidtail; ipfr_ipidtail = &fra->ipfr_next; @@ -576,7 +583,7 @@ READ_ENTER(&ipf_ipidfrag); ipf = fr_fraglookup(fin, ipfr_ipidtab); if (ipf != NULL) - id = (u_32_t)ipf->ipfr_data; + id = (u_32_t)(intptr_t)ipf->ipfr_data; else id = 0xffffffff; RWLOCK_EXIT(&ipf_ipidfrag); Regards, gg. From owner-freebsd-net@FreeBSD.ORG Tue Mar 8 16:29:37 2005 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 99C1416A4CE for ; Tue, 8 Mar 2005 16:29:37 +0000 (GMT) Received: from lithium.nettersworld.net (e131.ip.nettersworld.net [202.67.150.131]) by mx1.FreeBSD.org (Postfix) with SMTP id 535A743D5C for ; Tue, 8 Mar 2005 16:29:36 +0000 (GMT) (envelope-from mc@netx.com.hk) Received: (qmail 66532 invoked from network); 9 Mar 2005 00:30:28 +0800 Received: from lithium.nettersworld.net (202.67.150.131) by lithium.nettersworld.net with SMTP; 9 Mar 2005 00:30:28 +0800 Received: from lithium.nettersworld.net ([202.67.150.131]) by lithium.nettersworld.net with ESMTP id 41499-20 for ; Wed, 9 Mar 2005 00:30:28 +0800 (HKT) Received: from mcpm (n19z178l191.broadband.ctm.net [202.175.178.191]) by lithium.nettersworld.net (Postfix) with ESMTP id 677AD204964 for ; Wed, 9 Mar 2005 00:30:28 +0800 (HKT) Message-ID: <003e01c523fc$717a2c10$df63af0a@mcpm> From: "mc" To: Date: Wed, 9 Mar 2005 00:32:38 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="big5"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Subject: multiple uplinks from ISP 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, 08 Mar 2005 16:29:37 -0000 Hi all, If I have the following on hand... - 2 FastEthernet uplinks from ISP - 1 GigabitEthernet port on my switch - a subset of a /24 allocated by ISP The gigabit ethernet link should be connecting to my internal network. Problem: My internal network has been maxing out its 100Mbps limit, but my ISP doesn't want to give us a gigabit link, though they are willing to provide another 100Mbps link for us. Aim: Use 2*100Mbps uplinks in place of a gigabit link. I was wondering if it was possible to build a FreeBSD box acting as a router, connecting up my internal network (gigabit interface) and the uplinks provided by my isp (the two fast ethernet links)? I am expecting both the incoming traffic from the internet and the outgoing traffic from my internal network are properly balanced on the two uplinks (don't really need 50%:50% balanced, but I think the setup should be able to fill up both of the uplinks), and finally, if possible, firewall and some sort of failover for the two uplinks are desirable. I have thought about this setup: fxp0: 10.123.123.100 fxp1: 10.123.123.101 em0: 10.123.123.102 but then thousands of question marks appeared in my head.... 1) does freebsd allow assigning ip address in this way? 3 IPs in the same subnet assigned to 3 different interfaces using the same netmask. 2) should I apply the multipath patch? 3) even if the multipath patch is applied, how should I configure the default gateway? 4) suppose the gateway problem is solved. how would my isp's router know which uplink to send the traffic down? Could anyone spot me where did I get wrong? I have not carried out any experiment yet, but my intuition tells me this would not work as expected. Do I need IP addresses from different subnets, and perhaps do I need BGP4 peering with my ISP? Do I need different gateways (in different subnet?) from my provider? What elses do I need from my ISP? Do I need to make any changes to the IP address assignments to my existing internal computers? and...if possible, could anyone pls give me an example in real great details (at least including all the IP addresses of this router, the internal computers and the ISP router).? one thing more. besides getting traffic balanced on the two links, I would also know if it was possible to add some high availability to the setup.... Thanks all in advance! off topic: once upon a time when I was still in lab, I think I have tried to use a cisco router with 3 ethernet interfaces to setup a router as described above, but I don't remember the exact details (e.g. how did I assign the IPs to different interfaces). Sorry I was quite away from networking stuff for a while, pls forgive if this question sounds stupid to you. :) cheers, mc. From owner-freebsd-net@FreeBSD.ORG Tue Mar 8 17:07:17 2005 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 4B2D016A4CE for ; Tue, 8 Mar 2005 17:07:17 +0000 (GMT) Received: from smtp103.rog.mail.re2.yahoo.com (smtp103.rog.mail.re2.yahoo.com [206.190.36.81]) by mx1.FreeBSD.org (Postfix) with SMTP id CB99043D4C for ; Tue, 8 Mar 2005 17:07:16 +0000 (GMT) (envelope-from mikej@rogers.com) Received: from unknown (HELO 172.16.0.1) (mikej@69.193.222.195 with login) by smtp103.rog.mail.re2.yahoo.com with SMTP; 8 Mar 2005 17:07:16 -0000 Received: from 172.16.0.199 (SquirrelMail authenticated user mikej); by cpe000103d44c07-cm000f9f7ae88c.cpe.net.cable.rogers.com with HTTP; Tue, 8 Mar 2005 12:07:13 -0500 (EST) Message-ID: <4424.172.16.0.199.1110301633.squirrel@172.16.0.199> Date: Tue, 8 Mar 2005 12:07:13 -0500 (EST) From: "Mike Jakubik" To: freebsd-net@freebsd.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Link state messages 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, 08 Mar 2005 17:07:17 -0000 Hi, I have recently cvsuped to a new snapshot of -current, the existing system was about 1-2 months old. I am now seeing a lot of link state messages in dmesg. em0: link state changed to DOWN em0: link state changed to UP em0: link state changed to DOWN em0: link state changed to UP em0: link state changed to DOWN em0: link state changed to UP em0: link state changed to DOWN em0: link state changed to UP em0: link state changed to DOWN em0: link state changed to UP em0: link state changed to DOWN em0: link state changed to UP fxp0: link state changed to DOWN fxp0: link state changed to UP Should i be worried? From owner-freebsd-net@FreeBSD.ORG Tue Mar 8 17:39:28 2005 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 E7ACC16A4CE for ; Tue, 8 Mar 2005 17:39:28 +0000 (GMT) Received: from insomnia.benzedrine.cx (insomnia.benzedrine.cx [62.65.145.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF6BB43D2D for ; Tue, 8 Mar 2005 17:39:27 +0000 (GMT) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (dhartmei@localhost [127.0.0.1]) j28Hd9Bl011727 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 8 Mar 2005 18:39:10 +0100 (MET) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.13.3/8.12.10/Submit) id j28Hd7An012768; Tue, 8 Mar 2005 18:39:07 +0100 (MET) Date: Tue, 8 Mar 2005 18:39:07 +0100 From: Daniel Hartmeier To: Mark Tinguely Message-ID: <20050308173907.GG26999@insomnia.benzedrine.cx> References: <20050308101633.GC26999@insomnia.benzedrine.cx> <200503081411.j28EB0Hv001184@casselton.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200503081411.j28EB0Hv001184@casselton.net> User-Agent: Mutt/1.5.6i cc: spork@fasttrackmonkey.com cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 4.x and OS-X tcp 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, 08 Mar 2005 17:39:29 -0000 On Tue, Mar 08, 2005 at 08:11:00AM -0600, Mark Tinguely wrote: > The server is not telling the client that a packet has been lost. > The first two ACKs are correct duplicate ACKs, but the remaining > ACKs coming from he server have window adjustments, so the > client does not treat them as duplicate ACKs coming from a packet > loss. Ah, I didn't realize that duplicates must have the same window sizes, that explains it. Now I wonder why the server should be using the same window size on those near duplicate ACKs. It looks like th_win is recalculated every time in tcp_output(), based on how full the receive buffer is (the win = sbspace(&so->so_rcv); statement). Assuming there is usually some window space left when a loss occurs, and the sender will continue to fill the window with some more segments until the dupacks should trigger a fast retransmit, why should the receiver not adjust its window size in every ack? This seems not to occur in most cases, otherwise fast retransmit would rarely work. In this particular case, the server is increasing the window size with subsequent ACKs. What does this mean? The receive buffer became less full so quickly? The receive buffer was enlarged? Daniel From owner-freebsd-net@FreeBSD.ORG Tue Mar 8 20:19:59 2005 Return-Path: Delivered-To: freebsd-net@www.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 965EB16A4CE for ; Tue, 8 Mar 2005 20:19:59 +0000 (GMT) Received: from mail.sbb.co.yu (mail.sbb.co.yu [82.117.194.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF45543D2F for ; Tue, 8 Mar 2005 20:19:58 +0000 (GMT) (envelope-from ggajic@mail.sbb.co.yu) Received: from mail.sbb.co.yu (mail.sbb.co.yu [192.168.1.2] (may be forged)) by mail.sbb.co.yu (8.13.3/8.13.3) with ESMTP id j28KJvxn024794 for ; Tue, 8 Mar 2005 21:19:57 +0100 (CET) Date: Tue, 8 Mar 2005 21:19:57 +0100 (CET) From: Goran Gajic To: freebsd-net@www.freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-SBB-MailScanner-Information: Please contact the ISP for more information X-SBB-MailScanner: Found to be clean X-MailScanner-From: ggajic@mail.sbb.co.yu Subject: Re: ipfilter 4.1.6 won't build on FreeBSD5.3 amd64 (fwd) 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, 08 Mar 2005 20:19:59 -0000 Actually I was interested if Dual Opteron with FBSD5.3 can compare with Cisco7206 with NPE-G1 running only for NAT purpose of some 7000 hosts (and sadly more then ~80k pps can easly bring it down and no one can comfirm that 7206 with NPE-G1 can actually process 1M pps:). Ipfilter that is included in FreeBSD 5.3 is an old 3.4.35, I was not satisifed with its performance so I thoght that since ipf 4.1.6 is newer and has some new features maybe it can better cope with high NAT traffic. Unfortunately it won't compile cleanly on FBSD5.3-amd64 without supplied patch. I have compiled it with #define LARGE_NAT but so far I have tested it - only on few machines on local LAN and it works fine and I'm sure I will try it on live network with high traffic load :) Regards, gg. On Tue, 8 Mar 2005, David O'Brien wrote: > On Tue, Mar 08, 2005 at 03:12:22PM +0100, Goran Gajic wrote: >> >> >> Here is diff that makes ipfilter 4.1.6 able to compile on amd64 >> as kernel option IPFILTER: > > We don't seem to have version 4.1.6 in /usr/src/sys. > Does this apply to a port? > > -- > -- David (obrien@FreeBSD.org) > From owner-freebsd-net@FreeBSD.ORG Tue Mar 8 21:02:26 2005 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 BD93C16A4CE for ; Tue, 8 Mar 2005 21:02:26 +0000 (GMT) Received: from casselton.net (casselton.net [63.165.140.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C4FB43D53 for ; Tue, 8 Mar 2005 21:02:26 +0000 (GMT) (envelope-from tinguely@casselton.net) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.12.11/8.12.11) with ESMTP id j28L2BcJ036186; Tue, 8 Mar 2005 15:02:11 -0600 (CST) (envelope-from tinguely@casselton.net) Received: (from tinguely@localhost) by casselton.net (8.12.11/8.12.11/Submit) id j28L26HR036180; Tue, 8 Mar 2005 15:02:06 -0600 (CST) (envelope-from tinguely) Date: Tue, 8 Mar 2005 15:02:06 -0600 (CST) From: Mark Tinguely Message-Id: <200503082102.j28L26HR036180@casselton.net> To: daniel@benzedrine.cx, tinguely@casselton.net In-Reply-To: <20050308173907.GG26999@insomnia.benzedrine.cx> X-Spam-Status: No, score=1.4 required=5.0 tests=REPLY_TO_EMPTY autolearn=no version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on ccn.casselton.net cc: freebsd-net@freebsd.org cc: spork@fasttrackmonkey.com Subject: Re: FreeBSD 4.x and OS-X tcp 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, 08 Mar 2005 21:02:26 -0000 > In this particular case, the server is increasing the window size with > subsequent ACKs. What does this mean? The receive buffer became less > full so quickly? The receive buffer was enlarged? The last ACKs that you mention are window update notifications that the client application removed data from the recieve buffer. The recieving application on the FreeBSD machine fell way behind the sender. When the recieving host lost a packet, the new data will go into the fragment reassembly area and not the socket. The recieving application starts to catch up. Strange this does not happen a lot. --Mark Tinguely From owner-freebsd-net@FreeBSD.ORG Tue Mar 8 22:01:25 2005 Return-Path: Delivered-To: freebsd-net@www.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 738FC16A4CE for ; Tue, 8 Mar 2005 22:01:25 +0000 (GMT) Received: from mail.sbb.co.yu (mail.sbb.co.yu [82.117.194.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F2B443D39 for ; Tue, 8 Mar 2005 22:01:24 +0000 (GMT) (envelope-from ggajic@mail.sbb.co.yu) Received: from mail.sbb.co.yu (mail.sbb.co.yu [192.168.1.2] (may be forged)) by mail.sbb.co.yu (8.13.3/8.13.3) with ESMTP id j28M1M6A065260 for ; Tue, 8 Mar 2005 23:01:22 +0100 (CET) Date: Tue, 8 Mar 2005 23:01:22 +0100 (CET) From: Goran Gajic To: freebsd-net@www.freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-SBB-MailScanner-Information: Please contact the ISP for more information X-SBB-MailScanner: Found to be clean X-MailScanner-From: ggajic@mail.sbb.co.yu Subject: Re: multiple uplinks from ISP 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, 08 Mar 2005 22:01:25 -0000 Hi, I have used succesfuly FBSD 5.2.1 as BGP router and it is rock stable with quagga (check out www.quagga.net) - more stable then 30k $ Cisco 7206 :)) Problem is if you have AS and LIR and if you don't there are other solutions. Of course much depends is your uplink ISP willing to cooperate. Regards, gg. > Hi all, > > If I have the following on hand... > - 2 FastEthernet uplinks from ISP > - 1 GigabitEthernet port on my switch > - a subset of a /24 allocated by ISP > The gigabit ethernet link should be connecting to my internal network. From owner-freebsd-net@FreeBSD.ORG Tue Mar 8 22:13:43 2005 Return-Path: Delivered-To: freebsd-net@www.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 09FD216A4CF for ; Tue, 8 Mar 2005 22:13:43 +0000 (GMT) Received: from r2d2.bromirski.net (r2d2.bromirski.net [217.153.57.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 35D2143D55 for ; Tue, 8 Mar 2005 22:13:42 +0000 (GMT) (envelope-from lbromirski@mr0vka.eu.org) Received: from [127.0.0.1] (shield.wesola.pl [62.111.150.246]) by r2d2.bromirski.net (Postfix) with ESMTP id B2D1A1088B5; Tue, 8 Mar 2005 23:13:05 +0100 (CET) Message-ID: <422E240B.7010502@mr0vka.eu.org> Date: Tue, 08 Mar 2005 23:15:39 +0100 From: =?UTF-8?B?xYF1a2FzeiBCcm9taXJza2k=?= User-Agent: Mozilla Thunderbird 1.0.1 (Windows/20050227) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Goran Gajic References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scan-Module: SMTP[2005.03.08 (2004.11.26)] cc: freebsd-net@www.freebsd.org Subject: Re: ipfilter 4.1.6 won't build on FreeBSD5.3 amd64 (fwd) 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, 08 Mar 2005 22:13:43 -0000 Goran Gajic wrote: > Actually I was interested if Dual Opteron with FBSD5.3 > can compare with Cisco7206 with NPE-G1 running only for NAT You'll need good motherboard, NICs, 1-2GB of RAM and quite capable CPU. Two won't help much, but sometimes the motherboards for two CPUs provide higher standard (separate buses for PCI, PCI-X slots instead of regular PCI etc.), so it may be beneficial, but YMMV. > purpose of some 7000 hosts (and sadly more then ~80k pps can easly bring > it down and no one can comfirm that 7206 with NPE-G1 can actually > process 1M pps:). Yes, the 7206VXR with NPE-G1 can quite easily do 1Mpps, but the figures usually published are for routing. FreeBSD will also do this on properly configured hardware - google should return some useful usenet posts and discussions. 7200 is positioned as a router for ISPs, and they don't often do NAT - and as such, routing figures quite reliably put it in the 400-500kpps area (1Mpps full duplex). If Your problem lies in large NAT, either segregate the NAT process in few smaller chunks closer to end-users, by making few groups of "NAT-routers" that aggregate already NATed sessions on one main router, that's just routing (7200 will do just fine in that scenario), or buy some solution, that will do NAT in hardware. As for the 7200, if You wish, drop me an e-mail with some more details (running-config, exact version of IOS, modules loaded) and I can try to look for possible causes of poor performance. However please bear in mind, that NAT always requires first packet to be process/fast switched and some other requirements usually need to be met. For starters, check if You have CEF configured (`ip cef'), dropping all the usual Win$shit traffic (to not produce NAT translations for trashy traffic on the internal, ingress interface (via ACLs) and preferably control-plane configured - because sometimes DoS/semi-DoS scenarios arise from the fact, that router itself is slammered with packets. > Ipfilter that is included in FreeBSD 5.3 is an old > 3.4.35, I was not satisifed with its performance so I thoght that since > ipf 4.1.6 is newer and has some new features maybe it can better cope > with high NAT traffic. Unfortunately it won't compile cleanly on > FBSD5.3-amd64 without supplied patch. I have compiled it with #define > LARGE_NAT but so far I have tested it - only on few machines on local > LAN and it works fine and I'm sure I will try it on live network with > high traffic load :) You should try pf, it's usually faster. -- this space was intentionally left blank | Åukasz Bromirski you can insert your favourite quote here | lukasz:bromirski,net From owner-freebsd-net@FreeBSD.ORG Tue Mar 8 23:34:19 2005 Return-Path: Delivered-To: freebsd-net@www.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3DFE616A4CE for ; Tue, 8 Mar 2005 23:34:19 +0000 (GMT) Received: from mail.sbb.co.yu (mail.sbb.co.yu [82.117.194.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6152143D3F for ; Tue, 8 Mar 2005 23:34:18 +0000 (GMT) (envelope-from ggajic@mail.sbb.co.yu) Received: from mail.sbb.co.yu (mail.sbb.co.yu [192.168.1.2] (may be forged)) by mail.sbb.co.yu (8.13.3/8.13.3) with ESMTP id j28NYDCr097858; Wed, 9 Mar 2005 00:34:13 +0100 (CET) Date: Wed, 9 Mar 2005 00:34:13 +0100 (CET) From: Goran Gajic To: =?UTF-8?B?xYF1a2FzeiBCcm9taXJza2k=?= In-Reply-To: <422E240B.7010502@mr0vka.eu.org> Message-ID: References: <422E240B.7010502@mr0vka.eu.org> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1056511592-1110324853=:92805" X-SBB-MailScanner-Information: Please contact the ISP for more information X-SBB-MailScanner: Found to be clean X-MailScanner-From: ggajic@mail.sbb.co.yu cc: freebsd-net@www.freebsd.org Subject: Re: ipfilter 4.1.6 won't build on FreeBSD5.3 amd64 (fwd) 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, 08 Mar 2005 23:34:19 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1056511592-1110324853=:92805 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On my NPE-G1 running just IOS 12.3(12a) cpu utilization was something like 70-90% but with IOS 12.3(11)T3 it is 20% since this one has NAT=20 inside CEF and yes using small portions of address for NAT pool will=20 reduce CPU utilization and will improve NAT on 7206. However if you=20 compare prices of PC hardware and Cisco hardware decent PC hardware with= =20 FBSD seems like more acceptable solution to me. I was able to=20 bring down NPE-G1 with running simple ping -l 1000000 throu it and it has died at ~ 80k pps, while FBSD5.3 box was able to route this=20 without any problems. Regards, gg. On Tue, 8 Mar 2005, [UTF-8] =C5~Aukasz Bromirski wrote: > Goran Gajic wrote: > >> Actually I was interested if Dual Opteron with FBSD5.3 >> can compare with Cisco7206 with NPE-G1 running only for NAT > > You'll need good motherboard, NICs, 1-2GB of RAM and quite capable > CPU. Two won't help much, but sometimes the motherboards for two > CPUs provide higher standard (separate buses for PCI, PCI-X slots > instead of regular PCI etc.), so it may be beneficial, but YMMV. > >> purpose of some 7000 hosts (and sadly more then ~80k pps can easly bring= it=20 >> down and no one can comfirm that 7206 with NPE-G1 can actually process 1= M=20 >> pps:). > > Yes, the 7206VXR with NPE-G1 can quite easily do 1Mpps, but the > figures usually published are for routing. FreeBSD will also do > this on properly configured hardware - google should return some > useful usenet posts and discussions. > > 7200 is positioned as a router for ISPs, and they don't often do > NAT - and as such, routing figures quite reliably put it in the > 400-500kpps area (1Mpps full duplex). > > If Your problem lies in large NAT, either segregate the NAT process > in few smaller chunks closer to end-users, by making few groups of > "NAT-routers" that aggregate already NATed sessions on one main > router, that's just routing (7200 will do just fine in that > scenario), or buy some solution, that will do NAT in hardware. > > As for the 7200, if You wish, drop me an e-mail with some more > details (running-config, exact version of IOS, modules loaded) and > I can try to look for possible causes of poor performance. However > please bear in mind, that NAT always requires first packet to be > process/fast switched and some other requirements usually need to > be met. For starters, check if You have CEF configured (`ip cef'), > dropping all the usual Win$shit traffic (to not produce NAT > translations for trashy traffic on the internal, ingress interface > (via ACLs) and preferably control-plane configured - because sometimes > DoS/semi-DoS scenarios arise from the fact, that router itself is > slammered with packets. > --0-1056511592-1110324853=:92805-- From owner-freebsd-net@FreeBSD.ORG Wed Mar 9 00:13:34 2005 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 6ED6B16A4CE for ; Wed, 9 Mar 2005 00:13:34 +0000 (GMT) Received: from rosebud.otenet.gr (rosebud.otenet.gr [195.170.0.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id D68B843D1D for ; Wed, 9 Mar 2005 00:13:32 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from gothmog.gr (patr530-a164.otenet.gr [212.205.215.164]) j290DBoj012432; Wed, 9 Mar 2005 02:13:11 +0200 Received: from gothmog.gr (gothmog [127.0.0.1]) by gothmog.gr (8.13.3/8.13.3) with ESMTP id j290DPJN005537; Wed, 9 Mar 2005 02:13:25 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Received: (from giorgos@localhost) by gothmog.gr (8.13.3/8.13.3/Submit) id j290DO1Y005536; Wed, 9 Mar 2005 02:13:24 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Date: Wed, 9 Mar 2005 02:13:24 +0200 From: Giorgos Keramidas To: Andreas Bachmann Message-ID: <20050309001324.GF5173@gothmog.gr> References: <1110107067.2060.26.camel@notebook.bachi.net> <20050306113602.GA72592@gothmog.gr> <1110110710.2060.48.camel@notebook.bachi.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1110110710.2060.48.camel@notebook.bachi.net> cc: freebsd-net@freebsd.org Subject: Re: static pid and uid for a socket? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2005 00:13:34 -0000 On 2005-03-06 13:05, Andreas Bachmann wrote: > > AFAIK, this can only be done if the original process calls execve() on a > > setuid binary and has not marked the socket descriptor as close-on-exec. > > i'm developing a gtk+ based equivalent to 'sockstat'. > when a user is proposed to run a process, which creates a socket, the > sockstat printout is for example: > > USER COMMAND LOCAL ADDRESS FOREIGN ADDRESS > myuser myprog 10.0.0.10:52265 66.102.11.99:123 > > but, can the displayed kernel socket structure abrupty (by fork() or > setuid()) change user or process (because xfile.xf_uid or xfile.xf_pid > changed)? No. At least, not by a fork() that creates a new process. Each process has a (struct filedesc) in its proc structure. The filedesc holds information about all the open file descriptors of the process. The filedesc is an interface for the list of open (struct file) objects that a process holds. A somewhat simplified ASCII-art view is: struct proc +--------------------+ | | | struct filedesc | | +--------------+ | | | X---------------> struct file | | | | +------------+ | | | | | | | +--------------+ | | f_cred --------> struct ucred +--------------------+ | | +----------+ +------------+ | | +----------+ When a new process is created, its filedesc is copied from the filedesc of the parent process. The file descriptors of the parent process are copied [1]. The copying points to the very same (struct file) objects, so initially the credentials (owner) of the open files in the child are set to the same as those of the parent process. The parent and child share through their filedesc structures the same (struct file) object so far. This is not a problem, since they obviously have the same credentials anyway. When one of the processes that share open file objects in this way calls execve() (or one of its wrappers), the file decriptors are explicitly "unshared" to avoid security violations [2]. As far as I can tell, the owner of the (struct file *) object is not used(?), because the file operations accept a ucred pointer and use that for access checks to the underlying object (vnode, socket, etc). Since I'm only beginning to learn about the way file descriptors work in FreeBSD, someone who knows the internals better may put it in better words :-) [1] See revision 1.249 of kern_fork.c, near lines 416-418. [2] See revision 1.266 of kern_exec.c near lines 461-465. From owner-freebsd-net@FreeBSD.ORG Wed Mar 9 05:51:33 2005 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 CAC9016A4CE; Wed, 9 Mar 2005 05:51:33 +0000 (GMT) Received: from smtp1.skyinet.net (smtp1.skyinet.net [202.78.97.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 160BD43D2D; Wed, 9 Mar 2005 05:51:33 +0000 (GMT) (envelope-from fooler@skyinet.net) Received: from fooler (fooler.ilo.skyinet.net [202.78.118.66]) by smtp1.skyinet.net (Postfix) with SMTP id F36BD583C0; Wed, 9 Mar 2005 13:51:30 +0800 (PHT) Message-ID: <01d001c5246c$0b9ddc50$42764eca@ilo.skyinet.net> From: "fooler" To: "Bikrant Neupane" , References: <002a01c523ef$bc5af280$eb2d4fca@HOME> Date: Wed, 9 Mar 2005 13:51:31 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 cc: freebsd-net@freebsd.org Subject: Re: Session Timeout issue in pppoed 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, 09 Mar 2005 05:51:33 -0000 ----- Original Message ----- From: "Bikrant Neupane" To: Cc: Sent: Tuesday, March 08, 2005 11:01 PM Subject: Session Timeout issue in pppoed > Hi, > I have a pppoe server on FreeBSD 4.10. > I have configured my Radius Server ( radiator) to set Session-Timeout > parameter so that the clients who are using prepaid hour based service get > disconnected when their time is over. In the ppp.log file I see the the > Sessio-Timeout being accepted by the server. In the mean time the same > connection has another Session-Timeout parameter set whose value is 0!! As a > result the clients do not get dsconnected at the specified time. > I guess this is configuration issue/problem with ppp rather than pppoed. > > this is a portion of my ppp.log file. > > ppp[18466]: Phase: PPP Started (direct mode). > ppp[18466]: Phase: bundle: Establish > ppp[18466]: Phase: deflink: closed -> opening > ppp[18466]: Phase: deflink: Link is a netgraph node > ppp[18466]: Phase: deflink: Connected! > ppp[18466]: Phase: deflink: opening -> carrier > ppp[18466]: Phase: deflink: carrier -> lcp > ppp[18466]: Phase: bundle: Authenticate > ppp[18466]: Phase: deflink: his = none, mine = PAP > ppp[18466]: Phase: Pap Input: REQUEST (gomez5) > ppp[18466]: Phase: Radius: Request sent > ppp[18466]: Phase: Radius(auth): ACCEPT received > ppp[18466]: Phase: MTU 768 > ppp[18466]: Phase: VJ enabled > ppp[18466]: Phase: Session-Timeout 29218 <<<<< > ppp[18466]: Phase: Session-Timeout 0 <<<<< > ppp[18466]: Phase: Pap Output: SUCCESS > ppp[18466]: Phase: deflink: lcp -> open > ppp[18466]: Phase: bundle: Network > ppp[18466]: Phase: Radius(acct): Accounting response received > > Here is my ppp.conf file > default: > allow users > enable pap > allow mode direct > set mru 1492 > set mtu 1492 > set speed sync > set timeout 172800 #2 days: 48hrs > enable lqr > set ifaddr 202.79.xx.xx 202.79.xx.xx-202.79.xx.xx > load server > set radius /etc/radius.conf > accept dns > > > Any idea why this is happening?? Please suggest. pppoed is just a daemon processing the pppoe frames while (user) ppp is the one handling the session-timeout radius attribute once configured to use the radius service... the way i look at it, your radius server (radiator) is sending two session-timeout attributes which the user ppp accepted the two attributes and set the last value which is 0 (unlimited time)... try a tcpdump or your radiator utility if indeed your radius server is sending two session-timeout attributes... fooler. From owner-freebsd-net@FreeBSD.ORG Wed Mar 9 09:29:26 2005 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 E382516A4CE for ; Wed, 9 Mar 2005 09:29:26 +0000 (GMT) Received: from lithium.nettersworld.net (e131.ip.nettersworld.net [202.67.150.131]) by mx1.FreeBSD.org (Postfix) with SMTP id 5BEB843D48 for ; Wed, 9 Mar 2005 09:29:25 +0000 (GMT) (envelope-from mc@netx.com.hk) Received: (qmail 47902 invoked from network); 9 Mar 2005 17:30:18 +0800 Received: from lithium.nettersworld.net (202.67.150.131) by lithium.nettersworld.net with SMTP; 9 Mar 2005 17:30:18 +0800 Received: from lithium.nettersworld.net ([202.67.150.131]) by lithium.nettersworld.net with ESMTP id 30603-22 for ; Wed, 9 Mar 2005 17:30:18 +0800 (HKT) Received: from mcpm (n19z178l96.broadband.ctm.net [202.175.178.96]) by lithium.nettersworld.net (Postfix) with ESMTP id 87A34204975 for ; Wed, 9 Mar 2005 17:30:18 +0800 (HKT) Message-ID: <005501c5248a$e7ed69f0$df63af0a@mcpm> From: "mc" To: References: Date: Wed, 9 Mar 2005 17:32:25 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Subject: Re: multiple uplinks from ISP 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, 09 Mar 2005 09:29:27 -0000 Hi, The main problem is that I have no idea at all how should I setup everything..and what do I need from my ISP......I just know it was possible, but I can't recall the details inside, and a simple google did not return anything helpful to me. I agree with you that fbsd (or any other linux) is much better than cisco in terms of stability. The cisco routers at my site are crashing like cron jobs while the fbsd boxes usually have long uptimes. :) off topic: I used to be a network admin some time ago, but no longer true now....and unfortunately, in the past I had only very few chances to deal with interdomain routing, mainly in lab. I'm afraid I have forgotten everything by now :( ----- Original Message ----- From: "Goran Gajic" To: Sent: Wednesday, March 09, 2005 6:01 Subject: Re: multiple uplinks from ISP > > Hi, > > I have used succesfuly FBSD 5.2.1 as BGP router and it is rock stable with > quagga (check out www.quagga.net) - more stable then 30k $ Cisco 7206 :)) > Problem is if you have AS and LIR and if you don't there are other > solutions. Of course much depends is your uplink ISP willing to cooperate. > > Regards, > gg. > > > >> Hi all, >> >> If I have the following on hand... >> - 2 FastEthernet uplinks from ISP >> - 1 GigabitEthernet port on my switch >> - a subset of a /24 allocated by ISP >> The gigabit ethernet link should be connecting to my internal network. > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Wed Mar 9 09:53:03 2005 Return-Path: Delivered-To: freebsd-net@www.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE4AD16A4CE for ; Wed, 9 Mar 2005 09:53:03 +0000 (GMT) Received: from r2d2.bromirski.net (r2d2.bromirski.net [217.153.57.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 949C343D46 for ; Wed, 9 Mar 2005 09:53:03 +0000 (GMT) (envelope-from lbromirski@mr0vka.eu.org) Received: from [127.0.0.1] (r2d2.bromirski.net [217.153.57.194]) by r2d2.bromirski.net (Postfix) with ESMTP id 6CB551089C8; Wed, 9 Mar 2005 10:53:02 +0100 (CET) Message-ID: <422EC77D.4030602@mr0vka.eu.org> Date: Wed, 09 Mar 2005 10:53:01 +0100 From: =?ISO-8859-2?Q?=A3ukasz_Bromirski?= User-Agent: Mozilla Thunderbird 1.0.1 (Windows/20050302) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Goran Gajic References: <422E240B.7010502@mr0vka.eu.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@www.freebsd.org Subject: Re: ipfilter 4.1.6 won't build on FreeBSD5.3 amd64 (fwd) 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, 09 Mar 2005 09:53:04 -0000 Hi Goran, > On my NPE-G1 running just IOS 12.3(12a) cpu utilization was something > like 70-90% but with IOS 12.3(11)T3 it is 20% since this one has NAT > inside CEF Yes, exactly. > However if you compare prices of PC hardware and Cisco hardware > decent PC hardware with FBSD seems like more acceptable solution to me. It may be, however if You would like to implement ATM, E1/E3 termination, voice termination and for example IP-to-IP gateway (voice crossconnect), 7200 would be the platform. I'm not advocacing for 7200, just placing the focus on the right platform. Actually, I'm FreeBSD fan and most of my network runs FreeBSD, I also did some presentations regarding FreeBSD, networking and quagga ;) > I was able to bring down NPE-G1 with running simple ping -l 1000000 > throu it and it has died at ~ 80k pps, while FBSD5.3 box was > able to route this without any problems. Through or to NPE-G1? If to, then control-plane is solution, if through, the figure closely resembles process-switching figures, so it should be investigated further, as it's definitely not the optimal performance. -- this space was intentionally left blank | Lukasz Bromirski you can insert your favourite quote here | lukasz:bromirski,net From owner-freebsd-net@FreeBSD.ORG Wed Mar 9 09:55:52 2005 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 36BBC16A4CE for ; Wed, 9 Mar 2005 09:55:52 +0000 (GMT) Received: from mail.astra-sw.com (mail.astra-sw.com [82.140.87.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34A5343D39 for ; Wed, 9 Mar 2005 09:55:51 +0000 (GMT) (envelope-from Nickolay.Kritsky@astra-sw.com) Received: from exchange.stardevelopers4msi.com ([192.168.64.10]) by mail.astra-sw.com (8.12.11/8.12.11) with ESMTP id j299tnGS049771 for ; Wed, 9 Mar 2005 12:55:49 +0300 (MSK) Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Mar 2005 12:58:57 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: multiple uplinks from ISP thread-index: AcUkivvlSTW8NHl0QvSZtPdRQnkFiQAAHYjQ From: "Nickolay Kritsky" To: "mc" , Subject: RE: multiple uplinks from ISP 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, 09 Mar 2005 09:55:52 -0000 hello I do not think you should mess a lot with interdomain routing here. Such = a scenario (multiple uplinks from the same ISP) IMHO is better be solved = on the layer 2. What you need is some technology that utilizes two Ethernet ports at = once. About a week or two ago on this list was discussed similar setup = using Cisco technology. Search for subject "ng_fec and Cisco 2931". I f = your ISP is using the switch/router that supports FEC, you could do this = trick. Also most 3com intelligent switches support aggregating links via = multiple 100Mbit channels. If you have put 3com equipment on both sides = of your internet connection you'll can get what you want. Hope that helps. BTW the first and best thing to do is to ask such question to your ISP. Nick -----Original Message----- From: mc [mailto:mc@netx.com.hk] Sent: Wednesday, March 09, 2005 12:32 PM To: freebsd-net@freebsd.org Subject: Re: multiple uplinks from ISP Hi, The main problem is that I have no idea at all how should I setup=20 everything..and what do I need from my ISP......I just know it was = possible,=20 but I can't recall the details inside, and a simple google did not = return=20 anything helpful to me. I agree with you that fbsd (or any other linux) is much better than = cisco in=20 terms of stability. The cisco routers at my site are crashing like cron = jobs=20 while the fbsd boxes usually have long uptimes. :) off topic: I used to be a network admin some time ago, but no longer = true=20 now....and unfortunately, in the past I had only very few chances to = deal=20 with interdomain routing, mainly in lab. I'm afraid I have forgotten everything by now :( ----- Original Message -----=20 From: "Goran Gajic" To: Sent: Wednesday, March 09, 2005 6:01 Subject: Re: multiple uplinks from ISP > > Hi, > > I have used succesfuly FBSD 5.2.1 as BGP router and it is rock stable = with=20 > quagga (check out www.quagga.net) - more stable then 30k $ Cisco 7206 = :))=20 > Problem is if you have AS and LIR and if you don't there are other=20 > solutions. Of course much depends is your uplink ISP willing to = cooperate. > > Regards, > gg. > > > >> Hi all, >> >> If I have the following on hand... >> - 2 FastEthernet uplinks from ISP >> - 1 GigabitEthernet port on my switch >> - a subset of a /24 allocated by ISP >> The gigabit ethernet link should be connecting to my internal = network. > > _______________________________________________ > 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" >=20 _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Mar 9 10:03:18 2005 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 AC68A16A4CE for ; Wed, 9 Mar 2005 10:03:18 +0000 (GMT) Received: from lithium.nettersworld.net (e131.ip.nettersworld.net [202.67.150.131]) by mx1.FreeBSD.org (Postfix) with SMTP id 7222843D46 for ; Wed, 9 Mar 2005 10:03:15 +0000 (GMT) (envelope-from mc@netx.com.hk) Received: (qmail 64257 invoked from network); 9 Mar 2005 18:04:08 +0800 Received: from lithium.nettersworld.net (202.67.150.131) by lithium.nettersworld.net with SMTP; 9 Mar 2005 18:04:08 +0800 Received: from lithium.nettersworld.net ([202.67.150.131]) by lithium.nettersworld.net with ESMTP id 54274-10 for ; Wed, 9 Mar 2005 18:04:08 +0800 (HKT) Received: from mcpm (n19z178l96.broadband.ctm.net [202.175.178.96]) by lithium.nettersworld.net (Postfix) with ESMTP id 86E17204970 for ; Wed, 9 Mar 2005 18:04:08 +0800 (HKT) Message-ID: <005c01c5248f$a13ba0d0$df63af0a@mcpm> From: "mc" To: References: Date: Wed, 9 Mar 2005 18:06:15 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Subject: Re: multiple uplinks from ISP 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, 09 Mar 2005 10:03:18 -0000 Hi, I am using cisco 29xx and 3xxx switches. The problem with FEC is that I have no way to use dst-ip hashing as the load balancing option on these two switches, and that would cause biased utilization on a certain link only, i.e. impossible to utilize 2*100=200Mbps. and...if I were really to use FEC as the solution, I will need to get some much expensive switches from cisco, which is quite unaffordable and imho unnecessary in fact... ----- Original Message ----- From: "Nickolay Kritsky" To: "mc" ; Sent: Wednesday, March 09, 2005 17:58 Subject: RE: multiple uplinks from ISP hello I do not think you should mess a lot with interdomain routing here. Such a scenario (multiple uplinks from the same ISP) IMHO is better be solved on the layer 2. What you need is some technology that utilizes two Ethernet ports at once. About a week or two ago on this list was discussed similar setup using Cisco technology. Search for subject "ng_fec and Cisco 2931". I f your ISP is using the switch/router that supports FEC, you could do this trick. Also most 3com intelligent switches support aggregating links via multiple 100Mbit channels. If you have put 3com equipment on both sides of your internet connection you'll can get what you want. Hope that helps. BTW the first and best thing to do is to ask such question to your ISP. Nick -----Original Message----- From: mc [mailto:mc@netx.com.hk] Sent: Wednesday, March 09, 2005 12:32 PM To: freebsd-net@freebsd.org Subject: Re: multiple uplinks from ISP Hi, The main problem is that I have no idea at all how should I setup everything..and what do I need from my ISP......I just know it was possible, but I can't recall the details inside, and a simple google did not return anything helpful to me. I agree with you that fbsd (or any other linux) is much better than cisco in terms of stability. The cisco routers at my site are crashing like cron jobs while the fbsd boxes usually have long uptimes. :) off topic: I used to be a network admin some time ago, but no longer true now....and unfortunately, in the past I had only very few chances to deal with interdomain routing, mainly in lab. I'm afraid I have forgotten everything by now :( ----- Original Message ----- From: "Goran Gajic" To: Sent: Wednesday, March 09, 2005 6:01 Subject: Re: multiple uplinks from ISP > > Hi, > > I have used succesfuly FBSD 5.2.1 as BGP router and it is rock stable with > quagga (check out www.quagga.net) - more stable then 30k $ Cisco 7206 :)) > Problem is if you have AS and LIR and if you don't there are other > solutions. Of course much depends is your uplink ISP willing to cooperate. > > Regards, > gg. > > > >> Hi all, >> >> If I have the following on hand... >> - 2 FastEthernet uplinks from ISP >> - 1 GigabitEthernet port on my switch >> - a subset of a /24 allocated by ISP >> The gigabit ethernet link should be connecting to my internal network. > > _______________________________________________ > 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" > _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Mar 9 10:32:38 2005 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 069BD16A4CE for ; Wed, 9 Mar 2005 10:32:38 +0000 (GMT) Received: from mail.astra-sw.com (mail.astra-sw.com [82.140.87.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id 399AC43D6D for ; Wed, 9 Mar 2005 10:32:37 +0000 (GMT) (envelope-from Nickolay.Kritsky@astra-sw.com) Received: from exchange.stardevelopers4msi.com ([192.168.64.10]) by mail.astra-sw.com (8.12.11/8.12.11) with ESMTP id j29AWZkp055876 for ; Wed, 9 Mar 2005 13:32:36 +0300 (MSK) Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Mar 2005 13:35:44 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: multiple uplinks from ISP thread-index: AcUkj7X+U3M1wRN1S8yMU1NNiCnBGgAA/0UA From: "Nickolay Kritsky" To: "mc" , Subject: RE: multiple uplinks from ISP 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, 09 Mar 2005 10:32:38 -0000 Why can't you use dst-ip hashing? You are using /24 network for your = client machines, no? If FEC uses IP addresses for hashing that you are = ok. If it uses MAC addresses for hashing, you need to test something = else. Regarding your initial post here is my proposal: fxp0: 1.2.3.1/30 fxp1: 1.2.3.5/30 em0: 10.123.123.102/24 Your ISP gives you 2 more /30 nets for your uplinks You should have two default gateways on fxp0 and fxp1 (1.2.3.2 and = 1.2.3.6 respectively) ISP AS should have two routes to your network with the same weight. Problem: FreeBSD natively does not support two different routes to the = same destination. AFAIK this is by design. Solution: It can be solved using custom patch (I think I have seen such = for 4.x systems) or using external routing daemon like quagga. Nick -----Original Message----- From: mc [mailto:mc@netx.com.hk] Sent: Wednesday, March 09, 2005 1:06 PM To: freebsd-net@freebsd.org Subject: Re: multiple uplinks from ISP Hi, I am using cisco 29xx and 3xxx switches. The problem with FEC is that I = have=20 no way to use dst-ip hashing as the load balancing option on these two=20 switches, and that would cause biased utilization on a certain link = only,=20 i.e. impossible to utilize 2*100=3D200Mbps. and...if I were really to use FEC as the solution, I will need to get = some=20 much expensive switches from cisco, which is quite unaffordable and imho = unnecessary in fact... ----- Original Message -----=20 From: "Nickolay Kritsky" To: "mc" ; Sent: Wednesday, March 09, 2005 17:58 Subject: RE: multiple uplinks from ISP hello I do not think you should mess a lot with interdomain routing here. Such = a=20 scenario (multiple uplinks from the same ISP) IMHO is better be solved = on=20 the layer 2. What you need is some technology that utilizes two Ethernet ports at = once.=20 About a week or two ago on this list was discussed similar setup using = Cisco=20 technology. Search for subject "ng_fec and Cisco 2931". I f your ISP is=20 using the switch/router that supports FEC, you could do this trick. Also = most 3com intelligent switches support aggregating links via multiple=20 100Mbit channels. If you have put 3com equipment on both sides of your=20 internet connection you'll can get what you want. Hope that helps. BTW the first and best thing to do is to ask such question to your ISP. Nick -----Original Message----- From: mc [mailto:mc@netx.com.hk] Sent: Wednesday, March 09, 2005 12:32 PM To: freebsd-net@freebsd.org Subject: Re: multiple uplinks from ISP Hi, The main problem is that I have no idea at all how should I setup everything..and what do I need from my ISP......I just know it was = possible, but I can't recall the details inside, and a simple google did not = return anything helpful to me. I agree with you that fbsd (or any other linux) is much better than = cisco in terms of stability. The cisco routers at my site are crashing like cron = jobs while the fbsd boxes usually have long uptimes. :) off topic: I used to be a network admin some time ago, but no longer = true now....and unfortunately, in the past I had only very few chances to = deal with interdomain routing, mainly in lab. I'm afraid I have forgotten everything by now :( ----- Original Message -----=20 From: "Goran Gajic" To: Sent: Wednesday, March 09, 2005 6:01 Subject: Re: multiple uplinks from ISP > > Hi, > > I have used succesfuly FBSD 5.2.1 as BGP router and it is rock stable = with > quagga (check out www.quagga.net) - more stable then 30k $ Cisco 7206 = :)) > Problem is if you have AS and LIR and if you don't there are other > solutions. Of course much depends is your uplink ISP willing to = cooperate. > > Regards, > gg. > > > >> Hi all, >> >> If I have the following on hand... >> - 2 FastEthernet uplinks from ISP >> - 1 GigabitEthernet port on my switch >> - a subset of a /24 allocated by ISP >> The gigabit ethernet link should be connecting to my internal = network. > > _______________________________________________ > 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" > _______________________________________________ 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" _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Mar 9 10:55:39 2005 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 E800716A4CE for ; Wed, 9 Mar 2005 10:55:39 +0000 (GMT) Received: from lithium.nettersworld.net (e131.ip.nettersworld.net [202.67.150.131]) by mx1.FreeBSD.org (Postfix) with SMTP id DFECD43D2D for ; Wed, 9 Mar 2005 10:55:37 +0000 (GMT) (envelope-from mc@netx.com.hk) Received: (qmail 88139 invoked from network); 9 Mar 2005 18:56:30 +0800 Received: from lithium.nettersworld.net (202.67.150.131) by lithium.nettersworld.net with SMTP; 9 Mar 2005 18:56:30 +0800 Received: from lithium.nettersworld.net ([202.67.150.131]) by lithium.nettersworld.net with ESMTP id 58777-25; Wed, 9 Mar 2005 18:56:30 +0800 (HKT) Received: from mcpm (n19z178l96.broadband.ctm.net [202.175.178.96]) by lithium.nettersworld.net (Postfix) with ESMTP id 9B14C204964; Wed, 9 Mar 2005 18:56:29 +0800 (HKT) Message-ID: <006901c52496$f307b4b0$df63af0a@mcpm> From: "mc" To: "Nickolay Kritsky" , References: Date: Wed, 9 Mar 2005 18:58:17 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Subject: Re: multiple uplinks from ISP 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, 09 Mar 2005 10:55:40 -0000 dst-ip is not supported on one side of the switch. src-mac does not work too, due to the fact that this would lead to a biased result, causing most of the traffic goes thru the first link. dst-mac would not work as the machine is sending traffic to a single router. > fxp0: 1.2.3.1/30 > fxp1: 1.2.3.5/30 > em0: 10.123.123.102/24 Does this imply I just need to ask my ISP for two /30 and two default gateways and that's it? No other 'special' configuration or registration procedures would be needed? One more question, did you mean if I am to use quagga as the bgp daemon, I don't need to apply some kernel patches for the eq cost multipath to work? 'coz if my memory serves, quagga or other routing daemons just insert/delete/update the route entries in the kernel, they do not take part in any packet routing decisions. ----- Original Message ----- From: "Nickolay Kritsky" To: "mc" ; Sent: Wednesday, March 09, 2005 18:35 Subject: RE: multiple uplinks from ISP Why can't you use dst-ip hashing? You are using /24 network for your client machines, no? If FEC uses IP addresses for hashing that you are ok. If it uses MAC addresses for hashing, you need to test something else. Regarding your initial post here is my proposal: fxp0: 1.2.3.1/30 fxp1: 1.2.3.5/30 em0: 10.123.123.102/24 Your ISP gives you 2 more /30 nets for your uplinks You should have two default gateways on fxp0 and fxp1 (1.2.3.2 and 1.2.3.6 respectively) ISP AS should have two routes to your network with the same weight. Problem: FreeBSD natively does not support two different routes to the same destination. AFAIK this is by design. Solution: It can be solved using custom patch (I think I have seen such for 4.x systems) or using external routing daemon like quagga. Nick -----Original Message----- From: mc [mailto:mc@netx.com.hk] Sent: Wednesday, March 09, 2005 1:06 PM To: freebsd-net@freebsd.org Subject: Re: multiple uplinks from ISP Hi, I am using cisco 29xx and 3xxx switches. The problem with FEC is that I have no way to use dst-ip hashing as the load balancing option on these two switches, and that would cause biased utilization on a certain link only, i.e. impossible to utilize 2*100=200Mbps. and...if I were really to use FEC as the solution, I will need to get some much expensive switches from cisco, which is quite unaffordable and imho unnecessary in fact... ----- Original Message ----- From: "Nickolay Kritsky" To: "mc" ; Sent: Wednesday, March 09, 2005 17:58 Subject: RE: multiple uplinks from ISP hello I do not think you should mess a lot with interdomain routing here. Such a scenario (multiple uplinks from the same ISP) IMHO is better be solved on the layer 2. What you need is some technology that utilizes two Ethernet ports at once. About a week or two ago on this list was discussed similar setup using Cisco technology. Search for subject "ng_fec and Cisco 2931". I f your ISP is using the switch/router that supports FEC, you could do this trick. Also most 3com intelligent switches support aggregating links via multiple 100Mbit channels. If you have put 3com equipment on both sides of your internet connection you'll can get what you want. Hope that helps. BTW the first and best thing to do is to ask such question to your ISP. Nick -----Original Message----- From: mc [mailto:mc@netx.com.hk] Sent: Wednesday, March 09, 2005 12:32 PM To: freebsd-net@freebsd.org Subject: Re: multiple uplinks from ISP Hi, The main problem is that I have no idea at all how should I setup everything..and what do I need from my ISP......I just know it was possible, but I can't recall the details inside, and a simple google did not return anything helpful to me. I agree with you that fbsd (or any other linux) is much better than cisco in terms of stability. The cisco routers at my site are crashing like cron jobs while the fbsd boxes usually have long uptimes. :) off topic: I used to be a network admin some time ago, but no longer true now....and unfortunately, in the past I had only very few chances to deal with interdomain routing, mainly in lab. I'm afraid I have forgotten everything by now :( ----- Original Message ----- From: "Goran Gajic" To: Sent: Wednesday, March 09, 2005 6:01 Subject: Re: multiple uplinks from ISP > > Hi, > > I have used succesfuly FBSD 5.2.1 as BGP router and it is rock stable with > quagga (check out www.quagga.net) - more stable then 30k $ Cisco 7206 :)) > Problem is if you have AS and LIR and if you don't there are other > solutions. Of course much depends is your uplink ISP willing to cooperate. > > Regards, > gg. > > > >> Hi all, >> >> If I have the following on hand... >> - 2 FastEthernet uplinks from ISP >> - 1 GigabitEthernet port on my switch >> - a subset of a /24 allocated by ISP >> The gigabit ethernet link should be connecting to my internal network. > > _______________________________________________ > 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" > _______________________________________________ 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" _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Mar 9 11:21:34 2005 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 3D7AC16A4CE for ; Wed, 9 Mar 2005 11:21:34 +0000 (GMT) Received: from mail.astra-sw.com (mail.astra-sw.com [82.140.87.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2BA9143D58 for ; Wed, 9 Mar 2005 11:21:33 +0000 (GMT) (envelope-from Nickolay.Kritsky@astra-sw.com) Received: from exchange.stardevelopers4msi.com ([192.168.64.10]) by mail.astra-sw.com (8.12.11/8.12.11) with ESMTP id j29BLWCl063093 for ; Wed, 9 Mar 2005 14:21:32 +0300 (MSK) Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Mar 2005 14:24:40 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: multiple uplinks from ISP thread-index: AcUklvtM+w96qOfjQ02dEc/uh292kwAAfQCA From: "Nickolay Kritsky" To: "mc" , Subject: RE: multiple uplinks from ISP 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, 09 Mar 2005 11:21:34 -0000 1. Yes I think that should be enough. 2. Um, that's a good question. I guess I don't know the answer. you can ask quagga maintainer about the details of quagga multipath = routing. Maybe it just changes the gateway, say 10 times in a sec? Maybe = it patches kernel binary code, who knows? The best way to know would be = to build some test environment. What you need is two machines with 3 = interfaces each. One would emulate the ISP side, one will be your side. = and test. Plug them in between of some IP link and see what happens with = tcpdump and other tools. And, as it suddenly came to my mind, there is another question: what is = your outgoing/incoming traffic ratio? If it's like 1:10, maybe you won't = need multipath routing. You will use only one interface for sending = packets, and you will get them back via two interfaces. Think about it. = In this case - everything that you need is two equal-cost routes to your = network on the ISP side. Remember the KISS idea :-) Nick -----Original Message----- From: mc [mailto:mc@netx.com.hk] Sent: Wednesday, March 09, 2005 1:58 PM To: Nickolay Kritsky; freebsd-net@freebsd.org Subject: Re: multiple uplinks from ISP dst-ip is not supported on one side of the switch. src-mac does not work too, due to the fact that this would lead to a = biased=20 result, causing most of the traffic goes thru the first link. dst-mac would not work as the machine is sending traffic to a single = router. > fxp0: 1.2.3.1/30 > fxp1: 1.2.3.5/30 > em0: 10.123.123.102/24 Does this imply I just need to ask my ISP for two /30 and two default=20 gateways and that's it? No other 'special' configuration or registration = procedures would be needed? One more question, did you mean if I am to use quagga as the bgp daemon, = I=20 don't need to apply some kernel patches for the eq cost multipath to = work?=20 'coz if my memory serves, quagga or other routing daemons just=20 insert/delete/update the route entries in the kernel, they do not take = part=20 in any packet routing decisions. ----- Original Message -----=20 From: "Nickolay Kritsky" To: "mc" ; Sent: Wednesday, March 09, 2005 18:35 Subject: RE: multiple uplinks from ISP Why can't you use dst-ip hashing? You are using /24 network for your = client=20 machines, no? If FEC uses IP addresses for hashing that you are ok. If = it=20 uses MAC addresses for hashing, you need to test something else. Regarding your initial post here is my proposal: fxp0: 1.2.3.1/30 fxp1: 1.2.3.5/30 em0: 10.123.123.102/24 Your ISP gives you 2 more /30 nets for your uplinks You should have two default gateways on fxp0 and fxp1 (1.2.3.2 and = 1.2.3.6=20 respectively) ISP AS should have two routes to your network with the same weight. Problem: FreeBSD natively does not support two different routes to the = same=20 destination. AFAIK this is by design. Solution: It can be solved using custom patch (I think I have seen such = for=20 4.x systems) or using external routing daemon like quagga. Nick -----Original Message----- From: mc [mailto:mc@netx.com.hk] Sent: Wednesday, March 09, 2005 1:06 PM To: freebsd-net@freebsd.org Subject: Re: multiple uplinks from ISP Hi, I am using cisco 29xx and 3xxx switches. The problem with FEC is that I = have no way to use dst-ip hashing as the load balancing option on these two switches, and that would cause biased utilization on a certain link = only, i.e. impossible to utilize 2*100=3D200Mbps. and...if I were really to use FEC as the solution, I will need to get = some much expensive switches from cisco, which is quite unaffordable and imho unnecessary in fact... ----- Original Message -----=20 From: "Nickolay Kritsky" To: "mc" ; Sent: Wednesday, March 09, 2005 17:58 Subject: RE: multiple uplinks from ISP hello I do not think you should mess a lot with interdomain routing here. Such = a scenario (multiple uplinks from the same ISP) IMHO is better be solved = on the layer 2. What you need is some technology that utilizes two Ethernet ports at = once. About a week or two ago on this list was discussed similar setup using = Cisco technology. Search for subject "ng_fec and Cisco 2931". I f your ISP is using the switch/router that supports FEC, you could do this trick. Also most 3com intelligent switches support aggregating links via multiple 100Mbit channels. If you have put 3com equipment on both sides of your internet connection you'll can get what you want. Hope that helps. BTW the first and best thing to do is to ask such question to your ISP. Nick -----Original Message----- From: mc [mailto:mc@netx.com.hk] Sent: Wednesday, March 09, 2005 12:32 PM To: freebsd-net@freebsd.org Subject: Re: multiple uplinks from ISP Hi, The main problem is that I have no idea at all how should I setup everything..and what do I need from my ISP......I just know it was = possible, but I can't recall the details inside, and a simple google did not = return anything helpful to me. I agree with you that fbsd (or any other linux) is much better than = cisco in terms of stability. The cisco routers at my site are crashing like cron = jobs while the fbsd boxes usually have long uptimes. :) off topic: I used to be a network admin some time ago, but no longer = true now....and unfortunately, in the past I had only very few chances to = deal with interdomain routing, mainly in lab. I'm afraid I have forgotten everything by now :( ----- Original Message -----=20 From: "Goran Gajic" To: Sent: Wednesday, March 09, 2005 6:01 Subject: Re: multiple uplinks from ISP > > Hi, > > I have used succesfuly FBSD 5.2.1 as BGP router and it is rock stable = with > quagga (check out www.quagga.net) - more stable then 30k $ Cisco 7206 = :)) > Problem is if you have AS and LIR and if you don't there are other > solutions. Of course much depends is your uplink ISP willing to = cooperate. > > Regards, > gg. > > > >> Hi all, >> >> If I have the following on hand... >> - 2 FastEthernet uplinks from ISP >> - 1 GigabitEthernet port on my switch >> - a subset of a /24 allocated by ISP >> The gigabit ethernet link should be connecting to my internal = network. > > _______________________________________________ > 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" > _______________________________________________ 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" _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Mar 9 11:28:49 2005 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 3841A16A4DC for ; Wed, 9 Mar 2005 11:28:48 +0000 (GMT) Received: from mail.astra-sw.com (mail.astra-sw.com [82.140.87.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1AF4343D5C for ; Wed, 9 Mar 2005 11:28:46 +0000 (GMT) (envelope-from Nickolay.Kritsky@astra-sw.com) Received: from exchange.stardevelopers4msi.com ([192.168.64.10]) by mail.astra-sw.com (8.12.11/8.12.11) with ESMTP id j29BSjq2064673 for ; Wed, 9 Mar 2005 14:28:45 +0300 (MSK) Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Mar 2005 14:31:53 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FreeBSD 4.x and OS-X tcp performance thread-index: AcUj3WThpsdkfv+sS3CssCF2BIUUXgArSWJg From: "Nickolay Kritsky" To: "Daniel Hartmeier" , "Charles Sprickman" cc: freebsd-net@freebsd.org Subject: RE: FreeBSD 4.x and OS-X tcp 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: Wed, 09 Mar 2005 11:28:50 -0000 Here is my $0.02 I have seen such a problem with TCP flows between FreeBSD 4.5 and SUN = servers. The same scenario - ACKs getting lost on the one side of the link, which = was clearly seen on the tcpdumps taken on each sides at one time. I am = not so good in theory, but as quick fix - setting Sun's NIC to HD = helped. My guess was that packets are lost in the switch queues because of "too = high" speed of Sun's NIC. Like overflowing some internal buffers. I = don't know if it's true. Nick -----Original Message----- From: Daniel Hartmeier [mailto:daniel@benzedrine.cx] Sent: Tuesday, March 08, 2005 3:47 PM To: Charles Sprickman Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 4.x and OS-X tcp performance According to RFC 793 (the original TCP specification), the client may (even should) wait at least one second before retransmitting any segment. However, RFC 2001 describes Fast Retransmission, where the third acknowledgment for the same segment should be interpreted as an indication of packet loss, and cause an immediate retransmission (without waiting for the timeout of at least one second). I'd have expected Mac OS X to both implement this and enable it by default, but maybe I'm wrong. There's a sysctl net.inet.tcp.newreno which defaults to 0, and which seems to affect things. If you google, you find patches like http://www.opendarwin.org/~fkr/xnu/mach_kernel-to-517.7.21-SACK.diff which doesn't just contain SACK code, but possibly fixes fast retransmissions when newreno is not set. I'm not sure if disabling the newreno sysctl should disable fast retransmissions, or whether that's a bug. So, the Mac OS X client is not wrong in honouring RFC 793 alone. It just suffers badly from any packet loss. For you, the more relevant question is why there's 1.2% packet loss between the Mac OS X client and FreeBSD server, even when connected directly with crossover. Daniel _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Mar 9 11:49:44 2005 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 09FE216A4CE for ; Wed, 9 Mar 2005 11:49:44 +0000 (GMT) Received: from lithium.nettersworld.net (e131.ip.nettersworld.net [202.67.150.131]) by mx1.FreeBSD.org (Postfix) with SMTP id A839943D41 for ; Wed, 9 Mar 2005 11:49:41 +0000 (GMT) (envelope-from mc@netx.com.hk) Received: (qmail 20920 invoked from network); 9 Mar 2005 19:50:33 +0800 Received: from lithium.nettersworld.net (202.67.150.131) by lithium.nettersworld.net with SMTP; 9 Mar 2005 19:50:33 +0800 Received: from lithium.nettersworld.net ([202.67.150.131]) by lithium.nettersworld.net with ESMTP id 89988-23; Wed, 9 Mar 2005 19:50:33 +0800 (HKT) Received: from mcpm (n19z178l96.broadband.ctm.net [202.175.178.96]) by lithium.nettersworld.net (Postfix) with ESMTP id 7889C204970; Wed, 9 Mar 2005 19:50:32 +0800 (HKT) Message-ID: <007401c5249e$7ff80300$df63af0a@mcpm> From: "mc" To: "Nickolay Kritsky" , References: Date: Wed, 9 Mar 2005 19:52:40 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Subject: Re: multiple uplinks from ISP 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, 09 Mar 2005 11:49:44 -0000 In fact, the biggest problem with me is that I don't have any development machines for building a test network, in other words I cannot do experiments at anytime I want. I usually need to plan the experiment in details and do the experiment with some idle hot backup machine in the network, or I can also use things like VMware to setup a testing network, but getting VMware's network to work as expected is headache.... outgoing/incoming ratio: its the reverse actually :P. out/in is roughly equals to 10:1, usually 12Mbps incoming and 99Mbps outgoing. actually most the traffic is just generated by a single web server. > If it's like 1:10, maybe you won't need multipath routing. You will use only one interface for sending packets, and you will get them back via two interfaces. Think about it. In this case - everything that you need is two equal-cost routes to your network on the ISP side. Remember the KISS idea :-) imho this setup have several drawbacks...at least if the sending link fails, the packets would not automatically go to the other interface. also, firewalling could be made difficult if the packets are distributed like this. ----- Original Message ----- From: "Nickolay Kritsky" To: "mc" ; Sent: Wednesday, March 09, 2005 19:24 Subject: RE: multiple uplinks from ISP 1. Yes I think that should be enough. 2. Um, that's a good question. I guess I don't know the answer. you can ask quagga maintainer about the details of quagga multipath routing. Maybe it just changes the gateway, say 10 times in a sec? Maybe it patches kernel binary code, who knows? The best way to know would be to build some test environment. What you need is two machines with 3 interfaces each. One would emulate the ISP side, one will be your side. and test. Plug them in between of some IP link and see what happens with tcpdump and other tools. And, as it suddenly came to my mind, there is another question: what is your outgoing/incoming traffic ratio? If it's like 1:10, maybe you won't need multipath routing. You will use only one interface for sending packets, and you will get them back via two interfaces. Think about it. In this case - everything that you need is two equal-cost routes to your network on the ISP side. Remember the KISS idea :-) Nick -----Original Message----- From: mc [mailto:mc@netx.com.hk] Sent: Wednesday, March 09, 2005 1:58 PM To: Nickolay Kritsky; freebsd-net@freebsd.org Subject: Re: multiple uplinks from ISP dst-ip is not supported on one side of the switch. src-mac does not work too, due to the fact that this would lead to a biased result, causing most of the traffic goes thru the first link. dst-mac would not work as the machine is sending traffic to a single router. > fxp0: 1.2.3.1/30 > fxp1: 1.2.3.5/30 > em0: 10.123.123.102/24 Does this imply I just need to ask my ISP for two /30 and two default gateways and that's it? No other 'special' configuration or registration procedures would be needed? One more question, did you mean if I am to use quagga as the bgp daemon, I don't need to apply some kernel patches for the eq cost multipath to work? 'coz if my memory serves, quagga or other routing daemons just insert/delete/update the route entries in the kernel, they do not take part in any packet routing decisions. ----- Original Message ----- From: "Nickolay Kritsky" To: "mc" ; Sent: Wednesday, March 09, 2005 18:35 Subject: RE: multiple uplinks from ISP Why can't you use dst-ip hashing? You are using /24 network for your client machines, no? If FEC uses IP addresses for hashing that you are ok. If it uses MAC addresses for hashing, you need to test something else. Regarding your initial post here is my proposal: fxp0: 1.2.3.1/30 fxp1: 1.2.3.5/30 em0: 10.123.123.102/24 Your ISP gives you 2 more /30 nets for your uplinks You should have two default gateways on fxp0 and fxp1 (1.2.3.2 and 1.2.3.6 respectively) ISP AS should have two routes to your network with the same weight. Problem: FreeBSD natively does not support two different routes to the same destination. AFAIK this is by design. Solution: It can be solved using custom patch (I think I have seen such for 4.x systems) or using external routing daemon like quagga. Nick -----Original Message----- From: mc [mailto:mc@netx.com.hk] Sent: Wednesday, March 09, 2005 1:06 PM To: freebsd-net@freebsd.org Subject: Re: multiple uplinks from ISP Hi, I am using cisco 29xx and 3xxx switches. The problem with FEC is that I have no way to use dst-ip hashing as the load balancing option on these two switches, and that would cause biased utilization on a certain link only, i.e. impossible to utilize 2*100=200Mbps. and...if I were really to use FEC as the solution, I will need to get some much expensive switches from cisco, which is quite unaffordable and imho unnecessary in fact... ----- Original Message ----- From: "Nickolay Kritsky" To: "mc" ; Sent: Wednesday, March 09, 2005 17:58 Subject: RE: multiple uplinks from ISP hello I do not think you should mess a lot with interdomain routing here. Such a scenario (multiple uplinks from the same ISP) IMHO is better be solved on the layer 2. What you need is some technology that utilizes two Ethernet ports at once. About a week or two ago on this list was discussed similar setup using Cisco technology. Search for subject "ng_fec and Cisco 2931". I f your ISP is using the switch/router that supports FEC, you could do this trick. Also most 3com intelligent switches support aggregating links via multiple 100Mbit channels. If you have put 3com equipment on both sides of your internet connection you'll can get what you want. Hope that helps. BTW the first and best thing to do is to ask such question to your ISP. Nick -----Original Message----- From: mc [mailto:mc@netx.com.hk] Sent: Wednesday, March 09, 2005 12:32 PM To: freebsd-net@freebsd.org Subject: Re: multiple uplinks from ISP Hi, The main problem is that I have no idea at all how should I setup everything..and what do I need from my ISP......I just know it was possible, but I can't recall the details inside, and a simple google did not return anything helpful to me. I agree with you that fbsd (or any other linux) is much better than cisco in terms of stability. The cisco routers at my site are crashing like cron jobs while the fbsd boxes usually have long uptimes. :) off topic: I used to be a network admin some time ago, but no longer true now....and unfortunately, in the past I had only very few chances to deal with interdomain routing, mainly in lab. I'm afraid I have forgotten everything by now :( ----- Original Message ----- From: "Goran Gajic" To: Sent: Wednesday, March 09, 2005 6:01 Subject: Re: multiple uplinks from ISP > > Hi, > > I have used succesfuly FBSD 5.2.1 as BGP router and it is rock stable with > quagga (check out www.quagga.net) - more stable then 30k $ Cisco 7206 :)) > Problem is if you have AS and LIR and if you don't there are other > solutions. Of course much depends is your uplink ISP willing to cooperate. > > Regards, > gg. > > > >> Hi all, >> >> If I have the following on hand... >> - 2 FastEthernet uplinks from ISP >> - 1 GigabitEthernet port on my switch >> - a subset of a /24 allocated by ISP >> The gigabit ethernet link should be connecting to my internal network. > > _______________________________________________ > 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" > _______________________________________________ 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" _______________________________________________ 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" _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Mar 9 12:08:54 2005 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 3DC9C16A4CE for ; Wed, 9 Mar 2005 12:08:54 +0000 (GMT) Received: from mail.astra-sw.com (mail.astra-sw.com [82.140.87.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id 55C3043D4C for ; Wed, 9 Mar 2005 12:08:53 +0000 (GMT) (envelope-from Nickolay.Kritsky@astra-sw.com) Received: from exchange.stardevelopers4msi.com ([192.168.64.10]) by mail.astra-sw.com (8.12.11/8.12.11) with ESMTP id j29C8qtF070924 for ; Wed, 9 Mar 2005 15:08:52 +0300 (MSK) Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Mar 2005 15:12:01 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: multiple uplinks from ISP thread-index: AcUknogz3NIbLGUpQF+PuP9H1w4tmAAAg5cA From: "Nickolay Kritsky" To: "mc" , Subject: RE: multiple uplinks from ISP 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, 09 Mar 2005 12:08:54 -0000 Getting VMware network to network can be hard. But that's life: no pain, = no gain. Again, you can ask quagga port man: boris@tagnet.ru . I think = he knows a lot about multipath routing with or without quagga. PS: to all -net people. I think that such question is quite often here. = Maybe we can add short chapter about multipath routing in the handbook? = Explaining if it is possible, and if not, why. -----Original Message----- From: mc [mailto:mc@netx.com.hk] Sent: Wednesday, March 09, 2005 2:53 PM To: Nickolay Kritsky; freebsd-net@freebsd.org Subject: Re: multiple uplinks from ISP In fact, the biggest problem with me is that I don't have any = development=20 machines for building a test network, in other words I cannot do = experiments=20 at anytime I want. I usually need to plan the experiment in details and = do=20 the experiment with some idle hot backup machine in the network, or I = can=20 also use things like VMware to setup a testing network, but getting = VMware's=20 network to work as expected is headache.... outgoing/incoming ratio: its the reverse actually :P. out/in is roughly=20 equals to 10:1, usually 12Mbps incoming and 99Mbps outgoing. actually = most=20 the traffic is just generated by a single web server. > If it's like 1:10, maybe you won't need multipath routing. You will = use=20 only one interface for sending packets, and you will get them back via = two=20 interfaces. Think about it. In this case - everything that you need is = two=20 equal-cost routes to your network on the ISP side. Remember the KISS = idea=20 :-) imho this setup have several drawbacks...at least if the sending link = fails,=20 the packets would not automatically go to the other interface. also,=20 firewalling could be made difficult if the packets are distributed like=20 this. ----- Original Message -----=20 From: "Nickolay Kritsky" To: "mc" ; Sent: Wednesday, March 09, 2005 19:24 Subject: RE: multiple uplinks from ISP 1. Yes I think that should be enough. 2. Um, that's a good question. I guess I don't know the answer. you can ask quagga maintainer about the details of quagga multipath = routing.=20 Maybe it just changes the gateway, say 10 times in a sec? Maybe it = patches=20 kernel binary code, who knows? The best way to know would be to build = some=20 test environment. What you need is two machines with 3 interfaces each. = One=20 would emulate the ISP side, one will be your side. and test. Plug them = in=20 between of some IP link and see what happens with tcpdump and other = tools. And, as it suddenly came to my mind, there is another question: what is = your=20 outgoing/incoming traffic ratio? If it's like 1:10, maybe you won't need = multipath routing. You will use only one interface for sending packets, = and=20 you will get them back via two interfaces. Think about it. In this case = -=20 everything that you need is two equal-cost routes to your network on the = ISP=20 side. Remember the KISS idea :-) Nick -----Original Message----- From: mc [mailto:mc@netx.com.hk] Sent: Wednesday, March 09, 2005 1:58 PM To: Nickolay Kritsky; freebsd-net@freebsd.org Subject: Re: multiple uplinks from ISP dst-ip is not supported on one side of the switch. src-mac does not work too, due to the fact that this would lead to a = biased result, causing most of the traffic goes thru the first link. dst-mac would not work as the machine is sending traffic to a single = router. > fxp0: 1.2.3.1/30 > fxp1: 1.2.3.5/30 > em0: 10.123.123.102/24 Does this imply I just need to ask my ISP for two /30 and two default gateways and that's it? No other 'special' configuration or registration procedures would be needed? One more question, did you mean if I am to use quagga as the bgp daemon, = I don't need to apply some kernel patches for the eq cost multipath to = work? 'coz if my memory serves, quagga or other routing daemons just insert/delete/update the route entries in the kernel, they do not take = part in any packet routing decisions. ----- Original Message -----=20 From: "Nickolay Kritsky" To: "mc" ; Sent: Wednesday, March 09, 2005 18:35 Subject: RE: multiple uplinks from ISP Why can't you use dst-ip hashing? You are using /24 network for your = client machines, no? If FEC uses IP addresses for hashing that you are ok. If = it uses MAC addresses for hashing, you need to test something else. Regarding your initial post here is my proposal: fxp0: 1.2.3.1/30 fxp1: 1.2.3.5/30 em0: 10.123.123.102/24 Your ISP gives you 2 more /30 nets for your uplinks You should have two default gateways on fxp0 and fxp1 (1.2.3.2 and = 1.2.3.6 respectively) ISP AS should have two routes to your network with the same weight. Problem: FreeBSD natively does not support two different routes to the = same destination. AFAIK this is by design. Solution: It can be solved using custom patch (I think I have seen such = for 4.x systems) or using external routing daemon like quagga. Nick -----Original Message----- From: mc [mailto:mc@netx.com.hk] Sent: Wednesday, March 09, 2005 1:06 PM To: freebsd-net@freebsd.org Subject: Re: multiple uplinks from ISP Hi, I am using cisco 29xx and 3xxx switches. The problem with FEC is that I = have no way to use dst-ip hashing as the load balancing option on these two switches, and that would cause biased utilization on a certain link = only, i.e. impossible to utilize 2*100=3D200Mbps. and...if I were really to use FEC as the solution, I will need to get = some much expensive switches from cisco, which is quite unaffordable and imho unnecessary in fact... ----- Original Message -----=20 From: "Nickolay Kritsky" To: "mc" ; Sent: Wednesday, March 09, 2005 17:58 Subject: RE: multiple uplinks from ISP hello I do not think you should mess a lot with interdomain routing here. Such = a scenario (multiple uplinks from the same ISP) IMHO is better be solved = on the layer 2. What you need is some technology that utilizes two Ethernet ports at = once. About a week or two ago on this list was discussed similar setup using = Cisco technology. Search for subject "ng_fec and Cisco 2931". I f your ISP is using the switch/router that supports FEC, you could do this trick. Also most 3com intelligent switches support aggregating links via multiple 100Mbit channels. If you have put 3com equipment on both sides of your internet connection you'll can get what you want. Hope that helps. BTW the first and best thing to do is to ask such question to your ISP. Nick -----Original Message----- From: mc [mailto:mc@netx.com.hk] Sent: Wednesday, March 09, 2005 12:32 PM To: freebsd-net@freebsd.org Subject: Re: multiple uplinks from ISP Hi, The main problem is that I have no idea at all how should I setup everything..and what do I need from my ISP......I just know it was = possible, but I can't recall the details inside, and a simple google did not = return anything helpful to me. I agree with you that fbsd (or any other linux) is much better than = cisco in terms of stability. The cisco routers at my site are crashing like cron = jobs while the fbsd boxes usually have long uptimes. :) off topic: I used to be a network admin some time ago, but no longer = true now....and unfortunately, in the past I had only very few chances to = deal with interdomain routing, mainly in lab. I'm afraid I have forgotten everything by now :( ----- Original Message -----=20 From: "Goran Gajic" To: Sent: Wednesday, March 09, 2005 6:01 Subject: Re: multiple uplinks from ISP > > Hi, > > I have used succesfuly FBSD 5.2.1 as BGP router and it is rock stable = with > quagga (check out www.quagga.net) - more stable then 30k $ Cisco 7206 = :)) > Problem is if you have AS and LIR and if you don't there are other > solutions. Of course much depends is your uplink ISP willing to = cooperate. > > Regards, > gg. > > > >> Hi all, >> >> If I have the following on hand... >> - 2 FastEthernet uplinks from ISP >> - 1 GigabitEthernet port on my switch >> - a subset of a /24 allocated by ISP >> The gigabit ethernet link should be connecting to my internal = network. > > _______________________________________________ > 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" > _______________________________________________ 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" _______________________________________________ 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" _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Mar 9 13:45:02 2005 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 4FCC816A4CE for ; Wed, 9 Mar 2005 13:45:02 +0000 (GMT) Received: from mail.omniti.com (longsword.omniti.com [66.80.117.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 86B7543D41 for ; Wed, 9 Mar 2005 13:45:01 +0000 (GMT) (envelope-from jesus@omniti.com) DomainKey-Status: good DomainKey-Signature: q=dns; a=rsa-sha1; c=nofws; s=test; d=omniti.com; h=Received:Message-ID:Date:From:User-Agent:X-Accept-Language:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding; b=O5GQOKX1McPUGKTWQIjjQI1BCixv2QUcl9mZUDYfMmEa7aDw5bYXSa4tuxLWGX5A G/DC3hYryZR4F25WzZkK4NM2ikpQVoVk4+HvGNARj9Nl1ayA+IChWhNfisOQRapt Received: from ([10.80.116.114:60141] helo=[10.80.116.114]) by mail.omniti.com (ecelerity HEAD) with SMTP id F4/3C-27841-1DDFE224 for ; Wed, 09 Mar 2005 08:44:51 -0500 Message-ID: <422EFEE4.6090401@omniti.com> Date: Wed, 09 Mar 2005 08:49:24 -0500 From: Theo Schlossnagle User-Agent: Mozilla Thunderbird 0.9 (X11/20041127) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: FreeBSD 5.3 if_re.c (re) altq compatibility 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: Wed, 09 Mar 2005 13:45:02 -0000 Howdy, On my FreBSD 5.3-p5 box, the "re" ethernet driver doesn't support altq. Here's a patch to convert if_re.c to use the IFQ macros for altq compatibility. --- /usr/src/sys/dev/re/if_re.c.old Tue Feb 1 21:37:26 2005 +++ /usr/src/sys/dev/re/if_re.c Tue Feb 1 22:20:04 2005 @@ -1203,7 +1203,9 @@ ifp->if_baudrate = 1000000000; else ifp->if_baudrate = 100000000; - ifp->if_snd.ifq_maxlen = RL_IFQ_MAXLEN; + IFQ_SET_MAXLEN(&ifp->if_snd, RL_IFQ_MAXLEN); + ifp->if_snd.ifq_drv_maxlen = RL_IFQ_MAXLEN; + IFQ_SET_READY(&ifp->if_snd); ifp->if_capenable = ifp->if_capabilities; callout_handle_init(&sc->rl_stat_ch); @@ -1786,7 +1788,7 @@ re_rxeof(sc); re_txeof(sc); - if (ifp->if_snd.ifq_head != NULL) + if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) re_start_locked(ifp); if (cmd == POLL_AND_CHECK_STATUS) { /* also check status register */ @@ -1870,7 +1872,7 @@ } } - if (ifp->if_snd.ifq_head != NULL) + if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) re_start_locked(ifp); done_locked: @@ -2007,7 +2009,7 @@ { struct rl_softc *sc; struct mbuf *m_head = NULL; - int idx; + int idx, queued = 0; sc = ifp->if_softc; @@ -2016,7 +2018,7 @@ idx = sc->rl_ldata.rl_tx_prodidx; while (sc->rl_ldata.rl_tx_mbuf[idx] == NULL) { - IF_DEQUEUE(&ifp->if_snd, m_head); + IFQ_DRV_DEQUEUE(&ifp->if_snd, m_head); if (m_head == NULL) break; @@ -2031,25 +2033,27 @@ * to him. */ BPF_MTAP(ifp, m_head); + + queued++; } /* Flush the TX descriptors */ + if (queued) { + bus_dmamap_sync(sc->rl_ldata.rl_tx_list_tag, + sc->rl_ldata.rl_tx_list_map, + BUS_DMASYNC_PREWRITE|BUS_DMASYNC_PREREAD); - bus_dmamap_sync(sc->rl_ldata.rl_tx_list_tag, - sc->rl_ldata.rl_tx_list_map, - BUS_DMASYNC_PREWRITE|BUS_DMASYNC_PREREAD); - - sc->rl_ldata.rl_tx_prodidx = idx; + sc->rl_ldata.rl_tx_prodidx = idx; /* * RealTek put the TX poll request register in a different * location on the 8169 gigE chip. I don't know why. */ - if (sc->rl_type == RL_8169) - CSR_WRITE_2(sc, RL_GTXSTART, RL_TXSTART_START); - else - CSR_WRITE_2(sc, RL_TXSTART, RL_TXSTART_START); + if (sc->rl_type == RL_8169) + CSR_WRITE_2(sc, RL_GTXSTART, RL_TXSTART_START); + else + CSR_WRITE_2(sc, RL_TXSTART, RL_TXSTART_START); /* * Use the countdown timer for interrupt moderation. @@ -2059,12 +2063,13 @@ * interrupt. Each time we write to the TIMERCNT register, * the timer count is reset to 0. */ - CSR_WRITE_4(sc, RL_TIMERCNT, 1); + CSR_WRITE_4(sc, RL_TIMERCNT, 1); /* * Set a timeout in case the chip goes out to lunch. */ - ifp->if_timer = 5; + ifp->if_timer = 5; + } } static void -- // Theo Schlossnagle // Principal Engineer -- http://www.omniti.com/~jesus/ // Postal Engine -- http://www.postalengine.com/ // Ecelerity: fastest MTA on Earth From owner-freebsd-net@FreeBSD.ORG Wed Mar 9 13:51:20 2005 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 BC48A16A4CE for ; Wed, 9 Mar 2005 13:51:20 +0000 (GMT) Received: from casselton.net (casselton.net [63.165.140.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 475CC43D5F for ; Wed, 9 Mar 2005 13:51:20 +0000 (GMT) (envelope-from tinguely@casselton.net) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.12.11/8.12.11) with ESMTP id j29Dp4sL096492; Wed, 9 Mar 2005 07:51:04 -0600 (CST) (envelope-from tinguely@casselton.net) Received: (from tinguely@localhost) by casselton.net (8.12.11/8.12.11/Submit) id j29Dp4Kw096491; Wed, 9 Mar 2005 07:51:04 -0600 (CST) (envelope-from tinguely) Date: Wed, 9 Mar 2005 07:51:04 -0600 (CST) From: Mark Tinguely Message-Id: <200503091351.j29Dp4Kw096491@casselton.net> To: daniel@benzedrine.cx, spork@fasttrackmonkey.com In-Reply-To: X-Spam-Status: No, score=1.4 required=5.0 tests=REPLY_TO_EMPTY autolearn=no version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on ccn.casselton.net cc: freebsd-net@freebsd.org Subject: RE: FreeBSD 4.x and OS-X tcp 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: Wed, 09 Mar 2005 13:51:20 -0000 Thinking about the trace a little more, the Apple send buffer must be set much lower (about 18-19KB ballpark) than the FreeBSD recieve buffer (56 KB). If these settings were simular, the Apple machine should be providing more data as the FreeBSD gives the window updates - this would give the FreeBSD side more chances to give duplicate ACKs to recover quicker. For related curiousities, would you tell me if the FreeBSD a Uniprocessor or multiprocessor? --Mark Tinguely. From owner-freebsd-net@FreeBSD.ORG Wed Mar 9 15:32:56 2005 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 18AD616A4CE for ; Wed, 9 Mar 2005 15:32:56 +0000 (GMT) Received: from hamlet.pilgerer.org (hamlet.pilgerer.org [217.20.119.252]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1880643D5A for ; Wed, 9 Mar 2005 15:32:55 +0000 (GMT) (envelope-from benny@trial.pilgerer.de) Received: from localhost (hamlet [217.20.119.252]) by hamlet.pilgerer.org (8.13.2/8.13.2) with ESMTP id j29FWrZL048139 for ; Wed, 9 Mar 2005 16:32:53 +0100 (CET) (envelope-from benny@trial.pilgerer.de) Received: from trial.pilgerer.de (hamlet [217.20.119.252]) by hamlet.pilgerer.org (8.13.2/8.13.2) with ESMTP id j29FWmbn048133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 9 Mar 2005 16:32:48 +0100 (CET) (envelope-from benny@trial.pilgerer.de) Received: (from benny@localhost) by trial.pilgerer.de (8.13.1/8.13.1/Submit) id j29FWkZj048132 for freebsd-net@freebsd.org; Wed, 9 Mar 2005 16:32:46 +0100 (CET) (envelope-from benny) Date: Wed, 9 Mar 2005 16:32:46 +0100 From: Benjamin von Mossner To: freebsd-net@freebsd.org Message-ID: <20050309153246.GA45873@vonmossner.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD 5.3-STABLE i386 User-Agent: Mutt/1.5.6i X-DCC-sonic.net-Metrics: hamlet.pilgerer.de 1156; Body=1 Fuz1=1 Fuz2=1 X-Filter-Status: scanned by Antivir, f-prot and clamd Subject: isakmpd [Phase 1] Default= issue 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, 09 Mar 2005 15:32:56 -0000 Hi list, i have some problems with isakmpd, on FreeBSD 5.3 STABLE with isakmpd-20041207 from ports, when using the Default tag in phase 1 of the isakmpd conf. I use this tag to build up a roadwarrior configuration for users with dynamic and therefor unknow ipaddresses. The problem i realise is, that only one user at a time could use this Defaul= tag. A second user at this time, is not able zu process through phase 1, isakmpd simply stats that this (Default) type is already taken and wont proceed. In my opionion the Default tag should be able to handle multiple connections from unknown ipaddresses at the same time. Is this a isakmpd issue, or a implementation issue of isakmpd for FreeBSD? The config is 100% correct and everything works fine when only one user is using the Default tag at the same time. Help is very much appreciated :) Regards, Benny -- /"\ ASCII RIBBON CAMPAIGN | Benjamin von Mossner \ / AGAINST HTML MAIL | benny@vonmossner.de X / \ multiple exclamation marks are a sure sign of a diseased mind From owner-freebsd-net@FreeBSD.ORG Wed Mar 9 15:39:28 2005 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 6CC2E16A4CE for ; Wed, 9 Mar 2005 15:39:28 +0000 (GMT) Received: from gabrielle.polarcap.org (gabrielle.polarcap.org [62.84.209.4]) by mx1.FreeBSD.org (Postfix) with SMTP id DD2BA43D1F for ; Wed, 9 Mar 2005 15:39:26 +0000 (GMT) (envelope-from tony@polarcap.org) Received: (qmail 43161 invoked from network); 9 Mar 2005 15:36:16 -0000 Received: from localhost (HELO ?127.0.0.1?) (127.0.0.1) by 0 with SMTP; 9 Mar 2005 15:36:16 -0000 From: Tony Sarendal To: freebsd-net@freebsd.org Date: Wed, 9 Mar 2005 15:39:17 +0000 User-Agent: KMail/1.7.2 References: <422E240B.7010502@mr0vka.eu.org> In-Reply-To: <422E240B.7010502@mr0vka.eu.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200503091539.18047.tony@polarcap.org> Subject: Re: ipfilter 4.1.6 won't build on FreeBSD5.3 amd64 (fwd) 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, 09 Mar 2005 15:39:28 -0000 On Tuesday 08 March 2005 22:15, =C5=81ukasz Bromirski wrote: > > Yes, the 7206VXR with NPE-G1 can quite easily do 1Mpps, but the > figures usually published are for routing. FreeBSD will also do > this on properly configured hardware - google should return some > useful usenet posts and discussions. > > 7200 is positioned as a router for ISPs, and they don't often do > NAT - and as such, routing figures quite reliably put it in the > 400-500kpps area (1Mpps full duplex). > None of our 7200's will come anyway near those numbers. Are you sure it's cisco you are using =3D) =2D-=20 =2D-- Tony Sarendal - tony.sarendal@polarcap.org - sip:tony.sarendal@polarcap.org Cisco/Unix/Babies -=3D The scorpion replied, "I couldn't help it, it's my nature" =3D- From owner-freebsd-net@FreeBSD.ORG Wed Mar 9 16:35:47 2005 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 2201216A4CE for ; Wed, 9 Mar 2005 16:35:47 +0000 (GMT) Received: from wjv.com (fl-65-40-24-38.sta.sprint-hsd.net [65.40.24.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D66643D5A for ; Wed, 9 Mar 2005 16:35:46 +0000 (GMT) (envelope-from bv@bilver.wjv.com) Received: from bilver.wjv.com (localhost.wjv.com [127.0.0.1]) by wjv.com (8.12.11/8.13.1) with ESMTP id j29GZ8LN055464; Wed, 9 Mar 2005 11:35:08 -0500 (EST) (envelope-from bv@bilver.wjv.com) Received: (from bv@localhost) by bilver.wjv.com (8.12.11/8.13.1/Submit) id j29GZ7Zu055463; Wed, 9 Mar 2005 11:35:07 -0500 (EST) (envelope-from bv) Date: Wed, 9 Mar 2005 11:35:07 -0500 From: Bill Vermillion To: Mark Tinguely Message-ID: <20050309163507.GB54538@wjv.com> References: <200503091351.j29Dp4Kw096491@casselton.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200503091351.j29Dp4Kw096491@casselton.net> Organization: W.J.Vermillion / Orlando - Winter Park ReplyTo: bv@wjv.com User-Agent: Mutt/1.5.6i X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on bilver.wjv.com cc: spork@fasttrackmonkey.com cc: daniel@benzedrine.cx cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 4.x and OS-X tcp performance X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: bv@wjv.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2005 16:35:47 -0000 While normally not able to pour water out of a boot with instructions on the heel, on Wed, Mar 09, 2005 at 07:51 our dear friend Mark Tinguely uttered this load of codswallop: > Thinking about the trace a little more, the Apple send buffer > must be set much lower (about 18-19KB ballpark) than the FreeBSD > recieve buffer (56 KB). If these settings were simular, the > Apple machine should be providing more data as the FreeBSD gives > the window updates - this would give the FreeBSD side more > chances to give duplicate ACKs to recover quicker. > For related curiousities, would you tell me if the FreeBSD a > Uniprocessor or multiprocessor? I remember having problems with a G4 in our racks. Looking over some old messages I found something that had slipped my mind. A person I know who works for Omneon Video Technologies said they had similar problems and got a patch from Apple to fix this, and the patch was not a normally distributed one. Omneon builds high-speed media servers for broadcast and video. [www.omneon.com] I don't know if I can find this person again to check on this or not, but this problem has been seen before. I never had complete details on this - so it could be in the rumor category. My gut feeling is that it is something Apple is doing not FreeBSD - or we'd have heard a lot more about this. -- Bill Vermillion - bv @ wjv . com From owner-freebsd-net@FreeBSD.ORG Wed Mar 9 16:49:31 2005 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 5550716A4CE for ; Wed, 9 Mar 2005 16:49:31 +0000 (GMT) Received: from smtp.freemail.gr (smtp.freemail.gr [213.239.180.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D1A643D3F for ; Wed, 9 Mar 2005 16:49:30 +0000 (GMT) (envelope-from dionch@freemail.gr) Received: by smtp.freemail.gr (Postfix, from userid 101) id 1A66CBC07F; Wed, 9 Mar 2005 18:49:29 +0200 (EET) Received: from R3B (unknown [62.38.168.185])by smtp.freemail.gr (Postfix) with ESMTP id E3401BC071;Wed, 9 Mar 2005 18:49:27 +0200 (EET) Message-ID: <005f01c524c7$f230e670$3c00000a@R3B> From: "Chris Dionissopoulos" To: "Theo Schlossnagle" , References: <422EFEE4.6090401@omniti.com> Date: Wed, 9 Mar 2005 18:49:20 +0200 MIME-Version: 1.0 Content-Type: text/plain;format=flowed;charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Subject: Re: FreeBSD 5.3 if_re.c (re) altq compatibility patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Chris Dionissopoulos List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2005 16:49:31 -0000 Hi Theo, I think you must overwrite your patch @ 2016 line, with this one: @@ -2016,7 +2018,7 @@ idx = sc->rl_ldata.rl_tx_prodidx; while (sc->rl_ldata.rl_tx_mbuf[idx] == NULL) { - IF_DEQUEUE(&ifp->if_snd, m_head); + IFQ_DRV_DEQUEUE(&ifp->if_snd, m_head); if (m_head == NULL) break; if (re_encap(sc, &m_head, &idx)) { - IF_PREPEND(&ifp->if_snd, m_head); + IFQ_DRV_PREPEND(&ifp->if_snd, m_head); ifp->if_flags |= IFF_OACTIVE; break; }as refered in http://people.freebsd.org/~mlaier/ALTQ_driver/if_re.c.patchChris.----- Original Message ----- From: "Theo Schlossnagle" To: Sent: Wednesday, March 09, 2005 3:49 PM Subject: FreeBSD 5.3 if_re.c (re) altq compatibility patch > Howdy, > > On my FreBSD 5.3-p5 box, the "re" ethernet driver doesn't support altq. > Here's a patch to convert if_re.c to use the IFQ macros for altq > compatibility. > > --- /usr/src/sys/dev/re/if_re.c.old Tue Feb 1 21:37:26 2005 > +++ /usr/src/sys/dev/re/if_re.c Tue Feb 1 22:20:04 2005 > @@ -1203,7 +1203,9 @@ > ifp->if_baudrate = 1000000000; > else > ifp->if_baudrate = 100000000; > - ifp->if_snd.ifq_maxlen = RL_IFQ_MAXLEN; > + IFQ_SET_MAXLEN(&ifp->if_snd, RL_IFQ_MAXLEN); > + ifp->if_snd.ifq_drv_maxlen = RL_IFQ_MAXLEN; > + IFQ_SET_READY(&ifp->if_snd); > ifp->if_capenable = ifp->if_capabilities; > > callout_handle_init(&sc->rl_stat_ch); > @@ -1786,7 +1788,7 @@ > re_rxeof(sc); > re_txeof(sc); > > - if (ifp->if_snd.ifq_head != NULL) > + if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) > re_start_locked(ifp); > > if (cmd == POLL_AND_CHECK_STATUS) { /* also check status register > */ > @@ -1870,7 +1872,7 @@ > } > } > > - if (ifp->if_snd.ifq_head != NULL) > + if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) > re_start_locked(ifp); > > done_locked: > @@ -2007,7 +2009,7 @@ > { > struct rl_softc *sc; > struct mbuf *m_head = NULL; > - int idx; > + int idx, queued = 0; > > sc = ifp->if_softc; > > @@ -2016,7 +2018,7 @@ > idx = sc->rl_ldata.rl_tx_prodidx; > > while (sc->rl_ldata.rl_tx_mbuf[idx] == NULL) { > - IF_DEQUEUE(&ifp->if_snd, m_head); > + IFQ_DRV_DEQUEUE(&ifp->if_snd, m_head); > if (m_head == NULL) > break; > > @@ -2031,25 +2033,27 @@ > * to him. > */ > BPF_MTAP(ifp, m_head); > + > + queued++; > } > > /* Flush the TX descriptors */ > + if (queued) { > + bus_dmamap_sync(sc->rl_ldata.rl_tx_list_tag, > + sc->rl_ldata.rl_tx_list_map, > + BUS_DMASYNC_PREWRITE|BUS_DMASYNC_PREREAD); > > - bus_dmamap_sync(sc->rl_ldata.rl_tx_list_tag, > - sc->rl_ldata.rl_tx_list_map, > - BUS_DMASYNC_PREWRITE|BUS_DMASYNC_PREREAD); > - > - sc->rl_ldata.rl_tx_prodidx = idx; > + sc->rl_ldata.rl_tx_prodidx = idx; > > /* > * RealTek put the TX poll request register in a different > * location on the 8169 gigE chip. I don't know why. > */ > > - if (sc->rl_type == RL_8169) > - CSR_WRITE_2(sc, RL_GTXSTART, RL_TXSTART_START); > - else > - CSR_WRITE_2(sc, RL_TXSTART, RL_TXSTART_START); > + if (sc->rl_type == RL_8169) > + CSR_WRITE_2(sc, RL_GTXSTART, RL_TXSTART_START); > + else > + CSR_WRITE_2(sc, RL_TXSTART, RL_TXSTART_START); > > /* > * Use the countdown timer for interrupt moderation. > @@ -2059,12 +2063,13 @@ > * interrupt. Each time we write to the TIMERCNT register, > * the timer count is reset to 0. > */ > - CSR_WRITE_4(sc, RL_TIMERCNT, 1); > + CSR_WRITE_4(sc, RL_TIMERCNT, 1); > > /* > * Set a timeout in case the chip goes out to lunch. > */ > - ifp->if_timer = 5; > + ifp->if_timer = 5; > + } > } > > static void > > > -- > // Theo Schlossnagle > // Principal Engineer -- http://www.omniti.com/~jesus/ > // Postal Engine -- http://www.postalengine.com/ > // Ecelerity: fastest MTA on Earth > > > > > _______________________________________________ > 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" ____________________________________________________________________ http://www.freemail.gr - äùñåÜí õðçñåóßá çëåêôñïíéêïý ôá÷õäñïìåßïõ. http://www.freemail.gr - free email service for the Greek-speaking. From owner-freebsd-net@FreeBSD.ORG Wed Mar 9 18:40:17 2005 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 2915816A4CE for ; Wed, 9 Mar 2005 18:40:17 +0000 (GMT) Received: from angryfist.fasttrackmonkey.com (angryfist.fasttrackmonkey.com [216.223.196.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6CA7643D2F for ; Wed, 9 Mar 2005 18:40:16 +0000 (GMT) (envelope-from spork@fasttrackmonkey.com) Received: (qmail 13184 invoked by uid 2003); 9 Mar 2005 18:34:39 -0000 Received: from spork@fasttrackmonkey.com by angryfist.fasttrackmonkey.com by uid 1001 with qmail-scanner-1.20 (clamscan: 0.65. Clear:RC:1(216.220.116.154):. Processed in 0.137661 secs); 09 Mar 2005 18:34:39 -0000 Received: from unknown (HELO localhost) (216.220.116.154) by 0 with (DHE-RSA-AES256-SHA encrypted) SMTP; 9 Mar 2005 18:34:38 -0000 Date: Wed, 9 Mar 2005 13:40:08 -0500 (EST) From: Charles Sprickman X-X-Sender: spork@oof.local To: Mark Tinguely In-Reply-To: <200503091351.j29Dp4Kw096491@casselton.net> Message-ID: References: <200503091351.j29Dp4Kw096491@casselton.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-net@freebsd.org cc: daniel@benzedrine.cx Subject: RE: FreeBSD 4.x and OS-X tcp 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: Wed, 09 Mar 2005 18:40:17 -0000 On Wed, 9 Mar 2005, Mark Tinguely wrote: > For related curiousities, would you tell me if the FreeBSD a Uniprocessor > or multiprocessor? Let me give you some details: FreeBSD 4.10 p5, single Cyrix 250MHz cpu, and the nic is a Netgear identified as so: sis0: port 0xee00-0xeeff mem 0xfebff000-0xfebfffff irq 11 at device 18.0 on pci0 Anything else I can provide? Thanks, Charles > --Mark Tinguely. > > From owner-freebsd-net@FreeBSD.ORG Wed Mar 9 19:22:16 2005 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 3426316A4CE for ; Wed, 9 Mar 2005 19:22:16 +0000 (GMT) Received: from mailhost.schluting.com (schluting.com [131.252.214.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 095E043D5C for ; Wed, 9 Mar 2005 19:22:16 +0000 (GMT) (envelope-from charlie@schluting.com) Received: from localhost (localhost [127.0.0.1]) by mailhost.schluting.com (Postfix) with ESMTP id 9BDB5226E for ; Wed, 9 Mar 2005 11:22:15 -0800 (PST) Received: from mailhost.schluting.com ([127.0.0.1]) by localhost (schluting.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91400-06 for ; Wed, 9 Mar 2005 11:22:10 -0800 (PST) Received: by mailhost.schluting.com (Postfix, from userid 1001) id C304F2231; Wed, 9 Mar 2005 11:22:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailhost.schluting.com (Postfix) with ESMTP id BF448220F for ; Wed, 9 Mar 2005 11:22:10 -0800 (PST) Date: Wed, 9 Mar 2005 11:22:10 -0800 (PST) From: Charlie Schluting To: net@freebsd.org Message-ID: <20050309111759.O97008@schluting.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by your mom at schluting.com Subject: tcpdump/bpf and seeing .1q tags 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, 09 Mar 2005 19:22:16 -0000 Hi, So with tcpdump -e it somehow magically sees vlan tags.. even if hardware stripping of the tags is enabled. How? More importantly, I'm trying to figure out if a bpf read will see them as well. Any insight on this? TIA -Charlie From owner-freebsd-net@FreeBSD.ORG Wed Mar 9 19:51:09 2005 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 A94E016A4CE for ; Wed, 9 Mar 2005 19:51:09 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0FEDA43D66 for ; Wed, 9 Mar 2005 19:51:09 +0000 (GMT) (envelope-from redchin@gmail.com) Received: by rproxy.gmail.com with SMTP id a41so301092rng for ; Wed, 09 Mar 2005 11:51:07 -0800 (PST) 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=lwNmWs0S/d/Fb1n75Bl56Exr14ZTO9rMkkZcn6AmTGG8HwBEpojzRNag8R0afTFq3d9Gmpp81EfAT7vdPo9klOjD35Da99QmcjBECIXlQ1o80ra+oxCH5lRFzkzWvNeQvh0CsIiD/ZkeGme9HDThvjfiGHM3kEQKpFuhtMgYnPM= Received: by 10.38.86.28 with SMTP id j28mr1068622rnb; Wed, 09 Mar 2005 11:51:07 -0800 (PST) Received: by 10.38.149.8 with HTTP; Wed, 9 Mar 2005 11:51:07 -0800 (PST) Message-ID: <1d3ed48c050309115139a9648c@mail.gmail.com> Date: Wed, 9 Mar 2005 11:51:07 -0800 From: Kevin Downey To: freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: ath0 and reason 25 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Kevin Downey List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2005 19:51:09 -0000 I have a dlink card that uses the ath0 driver. a DLW520. And when a try to connect to an AP I get an error in dmesg "ath: association failed (reason 25)" followed by the BSSID of the AP. Is there a list of "reasons" somewhere? I have tried on an open AP a closed AP with WEP w/o WEP and I always get the same error. The card sees the AP fine. kismet finds it no problem. Sometimes wicontrol -i ath0 -L will show the AP and sometimes not. I have tried looking around in /src/sys/dev/ath and /src/sys/net80211 for " reasons" but my understanding of C / BSD internals is not very deep. From owner-freebsd-net@FreeBSD.ORG Wed Mar 9 20:21:10 2005 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 9E14616A4CE for ; Wed, 9 Mar 2005 20:21:10 +0000 (GMT) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C34E43D41 for ; Wed, 9 Mar 2005 20:21:10 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin02-en2 [10.13.10.147]) by smtpout.mac.com (8.12.6/MantshX 2.0) with ESMTP id j29KLAes019317; Wed, 9 Mar 2005 12:21:10 -0800 (PST) Received: from [192.168.1.6] (pool-68-161-53-96.ny325.east.verizon.net [68.161.53.96]) (authenticated bits=0)j29KL8Js017865; Wed, 9 Mar 2005 12:21:09 -0800 (PST) In-Reply-To: <20050309111759.O97008@schluting.com> References: <20050309111759.O97008@schluting.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3aa4b0ab62a3d4855fdc62383a77b9d5@mac.com> Content-Transfer-Encoding: 7bit From: Charles Swiger Date: Wed, 9 Mar 2005 15:21:06 -0500 To: Charlie Schluting X-Mailer: Apple Mail (2.619.2) cc: net@freebsd.org Subject: Re: tcpdump/bpf and seeing .1q tags 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, 09 Mar 2005 20:21:10 -0000 On Mar 9, 2005, at 2:22 PM, Charlie Schluting wrote: > So with tcpdump -e it somehow magically sees vlan tags.. even if > hardware stripping of the tags is enabled. How? tcpdump normally puts the interface into promiscuous mode. Perhaps retry using the '-p' flag? > More importantly, I'm trying to figure out if a bpf read will see them > as well. Any insight on this? Yes, or it will if you use promisc mode and an appropriate BPF filter: vlan [vlan_id] True if the packet is an IEEE 802.1Q VLAN packet. If [vlan_id] is specified, only true is the packet has the specified vlan_id. Note that the first vlan keyword encountered in expression changes the decoding offsets for the remainder of expression on the assumption that the packet is a VLAN packet. -- -Chuck From owner-freebsd-net@FreeBSD.ORG Wed Mar 9 20:30:54 2005 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 7AC8416A4CE for ; Wed, 9 Mar 2005 20:30:54 +0000 (GMT) Received: from mailhost.schluting.com (schluting.com [131.252.214.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0203243D31 for ; Wed, 9 Mar 2005 20:30:54 +0000 (GMT) (envelope-from charlie@schluting.com) Received: from localhost (localhost [127.0.0.1]) by mailhost.schluting.com (Postfix) with ESMTP id A3828226E for ; Wed, 9 Mar 2005 12:30:53 -0800 (PST) Received: from mailhost.schluting.com ([127.0.0.1]) by localhost (schluting.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99722-07 for ; Wed, 9 Mar 2005 12:30:47 -0800 (PST) Received: from [131.252.213.83] (schrodinger.cat.pdx.edu [131.252.213.83]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.schluting.com (Postfix) with ESMTP id BDBFB220F for ; Wed, 9 Mar 2005 12:30:47 -0800 (PST) Message-ID: <422F5CF6.9070906@schluting.com> Date: Wed, 09 Mar 2005 12:30:46 -0800 From: Charlie Schluting User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: net@freebsd.org References: <20050309111759.O97008@schluting.com> <3aa4b0ab62a3d4855fdc62383a77b9d5@mac.com> In-Reply-To: <3aa4b0ab62a3d4855fdc62383a77b9d5@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by your mom at schluting.com Subject: Re: tcpdump/bpf and seeing .1q tags 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, 09 Mar 2005 20:30:54 -0000 Charles Swiger wrote: > On Mar 9, 2005, at 2:22 PM, Charlie Schluting wrote: >> More importantly, I'm trying to figure out if a bpf read will see them >> as well. Any insight on this? > > > Yes, or it will if you use promisc mode and an appropriate BPF filter: > So promisc is enabled in my case. This seems to imply that the bpf will always see the vlan tags. (I don't want to.. that was the point of my question) I believe this is starting to make sense. Thanks for your reply. -Charlie From owner-freebsd-net@FreeBSD.ORG Wed Mar 9 20:32:44 2005 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 2F25C16A4CE for ; Wed, 9 Mar 2005 20:32:44 +0000 (GMT) Received: from mailhost.schluting.com (schluting.com [131.252.214.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id F3E1E43D5F for ; Wed, 9 Mar 2005 20:32:43 +0000 (GMT) (envelope-from charlie@schluting.com) Received: from localhost (localhost [127.0.0.1]) by mailhost.schluting.com (Postfix) with ESMTP id B008E226E for ; Wed, 9 Mar 2005 12:32:43 -0800 (PST) Received: from mailhost.schluting.com ([127.0.0.1]) by localhost (schluting.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03979-01 for ; Wed, 9 Mar 2005 12:32:38 -0800 (PST) Received: from [131.252.213.83] (schrodinger.cat.pdx.edu [131.252.213.83]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.schluting.com (Postfix) with ESMTP id 6804C220F for ; Wed, 9 Mar 2005 12:32:38 -0800 (PST) Message-ID: <422F5D66.6020808@schluting.com> Date: Wed, 09 Mar 2005 12:32:38 -0800 From: Charlie Schluting User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: net@freebsd.org References: <20050309111759.O97008@schluting.com> <3aa4b0ab62a3d4855fdc62383a77b9d5@mac.com> <422F5CF6.9070906@schluting.com> In-Reply-To: <422F5CF6.9070906@schluting.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by your mom at schluting.com Subject: Re: tcpdump/bpf and seeing .1q tags 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, 09 Mar 2005 20:32:44 -0000 Charlie Schluting wrote: > Charles Swiger wrote: > >> On Mar 9, 2005, at 2:22 PM, Charlie Schluting wrote: >> >>> More importantly, I'm trying to figure out if a bpf read will see >>> them as well. Any insight on this? >> >> >> >> Yes, or it will if you use promisc mode and an appropriate BPF filter: >> > > So promisc is enabled in my case. > > This seems to imply that the bpf will always see the vlan tags. (I don't > want to.. that was the point of my question) > > I believe this is starting to make sense. Thanks for your reply. Oh! Er.. I hit send too fast. So a BPF is supposed to ignore vlan tags unless 'vlan' is specified?? -Charlie From owner-freebsd-net@FreeBSD.ORG Wed Mar 9 20:51:39 2005 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 70C4C16A4CE for ; Wed, 9 Mar 2005 20:51:39 +0000 (GMT) Received: from r2d2.bromirski.net (r2d2.bromirski.net [217.153.57.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0235343D1F for ; Wed, 9 Mar 2005 20:51:39 +0000 (GMT) (envelope-from lbromirski@mr0vka.eu.org) Received: from [127.0.0.1] (r2d2.bromirski.net [217.153.57.194]) by r2d2.bromirski.net (Postfix) with ESMTP id 13C2310896A; Wed, 9 Mar 2005 21:51:38 +0100 (CET) Message-ID: <422F61D8.8040603@mr0vka.eu.org> Date: Wed, 09 Mar 2005 21:51:37 +0100 From: =?ISO-8859-2?Q?=A3ukasz_Bromirski?= User-Agent: Mozilla Thunderbird 1.0.1 (Windows/20050302) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tony Sarendal References: <422E240B.7010502@mr0vka.eu.org> <200503091539.18047.tony@polarcap.org> In-Reply-To: <200503091539.18047.tony@polarcap.org> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: ipfilter 4.1.6 won't build on FreeBSD5.3 amd64 (fwd) 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, 09 Mar 2005 20:51:39 -0000 Tony Sarendal wrote: > None of our 7200's will come anyway near those numbers. > Are you sure it's cisco you are using =) ;) I can't argue for any 7200 in any situation, but again let me repeat, that the numbers I gave are for pure, fast-switched/CEFed routing. I think this discussion should migrate to cisco-nsp or some other list, because it's freebsd-net, not Cisco-net. As for real life, I'm currently logged on on a 7206VXR/NPE-G1 that handles 2 full BGP feeds, does a lot of filtering (Turbo ACLs, uRPF), shaping, policing, and pushes about 200kpps (slightly above 100Mbit/s total, across two built-in GEs and some other interfaces). And it's loaded up to 60%. I unfortunately can't give You any classified or internal data, but as I said YMMV - at it actually varies ;) -- this space was intentionally left blank | Lukasz Bromirski you can insert your favourite quote here | lukasz:bromirski,net From owner-freebsd-net@FreeBSD.ORG Wed Mar 9 21:03:11 2005 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 0D9B416A4CE for ; Wed, 9 Mar 2005 21:03:11 +0000 (GMT) Received: from ylpvm29.prodigy.net (ylpvm29-ext.prodigy.net [207.115.57.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6758243D2D for ; Wed, 9 Mar 2005 21:03:10 +0000 (GMT) (envelope-from kbyanc@posi.net) Received: from gateway.posi.net (adsl-67-124-96-122.dsl.snfc21.pacbell.net [67.124.96.122])j29L2kRs025549; Wed, 9 Mar 2005 16:02:46 -0500 Received: from localhost (localhost [127.0.0.1]) by gateway.posi.net (Postfix) with ESMTP id 38D6B75E05F; Wed, 9 Mar 2005 14:05:47 -0800 (PST) Date: Wed, 9 Mar 2005 14:05:46 -0800 (PST) From: Kelly Yancey To: Charlie Schluting In-Reply-To: <422F5D66.6020808@schluting.com> Message-ID: <20050309135422.C13519@gateway.posi.net> References: <20050309111759.O97008@schluting.com> <3aa4b0ab62a3d4855fdc62383a77b9d5@mac.com> <422F5CF6.9070906@schluting.com> <422F5D66.6020808@schluting.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: net@freebsd.org Subject: Re: tcpdump/bpf and seeing .1q tags 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, 09 Mar 2005 21:03:11 -0000 On Wed, 9 Mar 2005, Charlie Schluting wrote: > Charlie Schluting wrote: > > Charles Swiger wrote: > > > >> On Mar 9, 2005, at 2:22 PM, Charlie Schluting wrote: > >> > >>> More importantly, I'm trying to figure out if a bpf read will see > >>> them as well. Any insight on this? > >> > >> > >> > >> Yes, or it will if you use promisc mode and an appropriate BPF filter: > >> > > > > So promisc is enabled in my case. > > > > This seems to imply that the bpf will always see the vlan tags. (I don't > > want to.. that was the point of my question) > > > > I believe this is starting to make sense. Thanks for your reply. > > Oh! Er.. I hit send too fast. > > So a BPF is supposed to ignore vlan tags unless 'vlan' is specified?? > Worse: tcpdump has not idea there is a tag on the packet causing any other filters to compare against the wrong data in the packet. For this reason, if you are going to run tcpdump on a parent interface, you need to either specify no filter criteria or else specify the 'vlan' keyword so tcpdump knows what it is getting. You'll have a similar issue with BPF programs you write: you'll either need to skip over the vlan tag header or not, depending on whether you snagged the packet from the parent interface or the vlan interface. Kelly -- Kelly Yancey - kbyanc@{posi.net,FreeBSD.org} - kelly@nttmcl.com "And say, finally, whether peace is best preserved by giving energy to the government or information to the people. This last is the most certain and the most legitimate engine of government." -- Thomas Jefferson to James Madison, 1787. From owner-freebsd-net@FreeBSD.ORG Wed Mar 9 21:51:08 2005 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 491E716A4CF for ; Wed, 9 Mar 2005 21:51:08 +0000 (GMT) Received: from outgoing.redshift.com (outgoing.redshift.com [207.177.231.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 853AE43D48 for ; Wed, 9 Mar 2005 21:51:07 +0000 (GMT) (envelope-from ray@redshift.com) Received: from workstation (216-228-19-21.dsl.redshift.com [216.228.19.21]) by outgoing.redshift.com (Postfix) with SMTP id 8823697081 for ; Wed, 9 Mar 2005 13:51:04 -0800 (PST) Message-Id: <3.0.1.32.20050309135120.00a7f5c0@pop.redshift.com> X-Mailer: na X-Sender: redshift.com Date: Wed, 09 Mar 2005 13:51:20 -0800 To: freebsd-net@freebsd.org From: ray@redshift.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: FreeBSD router question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2005 21:51:08 -0000 Hello (just signed up to this list), I am wondering if anyone on the list has any experience using FreeBSD 5.3 as a router in a high traffic environment? I am building a development cluster here and have decided to try using FreeBSD as my main network router instead of something like the Cisco 7200's, Force10, etc. I have 10 or 12 Xeon machines in my cluster so far, but may have as many as 50 to 100 in the future (once our site goes live). Right now I have a 2.40 GHz Xeon with 2GB of RAM running as the router using FreeBSD 5.3, ipf and ipnat (this may be upgraded to an AMD64 bit dual core shortly). So far everything seems to work fine, but it has not been under heavy load yet. The router has been up for 26 days with no problems and works great. I've made the following tweaks (see end of message) to sysctl.conf in an effort to get things going the right direction. I've also stripped down the kernel file and recompiled. I read recently that FreeBSD was able to route 1Mpps, which sounded pretty good, but I don't know if there are any specific tweaks I need to make in order to obtain this sort of speed, or how fast it works "out of the box" with just a few modifications? My main concern is that the router works okay now, but when traffic ramps up, it hits a wall without some large amount of exotic changes. I'd like to feel comfortable that the machine will handle at least 50 to 100 megabits of traffic on a fairly sustained basis without facing any major problems. Is that realistic or are there specific changes I should make to the OS? If anyone on the list has any first hand information/experience that might steer me the right direction, that would be great. Any feed back would be great, Thanks very much! :-) Ray /etc/sysctl.conf net.inet.ip.forwarding=1 # enable packet forwarding net.inet.ip.fastforwarding=0 # not sure about this, but might want to change to 1 net.inet.ip.check_interface=1 # verify incoming packets arrives on an interface w/ address matching the packet 's destination address net.link.ether.inet.log_arp_wrong_iface=0 # turn off ARP error messages - see http://www.freebsdhowtos.com/102.htm l net.inet.tcp.blackhole=2 # drop SYN packets destine to non-listening tcp/udp ports. This will net.inet.udp.blackhole=1 # create a blackhole and protect against stealth port scans net.inet.tcp.recvspace=65535 # increase TCP window size for better network performance net.inet.tcp.sendspace=65535 kern.ipc.somaxconn=1024 # increase listen queue (defense against SYN attacks, better performance) [128] net.inet.icmp.drop_redirect=1 # disable redirects [0] net.inet.icmp.log_redirect=1 # [0] net.inet.ip.redirect=0 # [1] # net.inet6.ip6.redirect=0 # not using IPv6 net.inet.ip.sourceroute=0 # disable source routing [0] net.inet.ip.accept_sourceroute=0 # [0] net.inet.icmp.bmcastecho=0 # disable broadcast ECHO response [0] net.inet.icmp.maskrepl=0 # disable other broadcast probes [0] net.link.ether.inet.max_age=1200 # ARP clean up time (prevent flooding ARP requests) [1200] From owner-freebsd-net@FreeBSD.ORG Thu Mar 10 00:18:26 2005 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 6DDA116A4CE for ; Thu, 10 Mar 2005 00:18:26 +0000 (GMT) Received: from apu.bmrc.berkeley.edu (apu.BMRC.Berkeley.EDU [169.229.12.108]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D5D943D31 for ; Thu, 10 Mar 2005 00:18:26 +0000 (GMT) (envelope-from chema@apu.bmrc.berkeley.edu) Received: from apu.bmrc.berkeley.edu (localhost [127.0.0.1]) j2A0IQmE000341; Wed, 9 Mar 2005 16:18:26 -0800 (PST) (envelope-from chema@apu.bmrc.berkeley.edu) Received: (from chema@localhost) by apu.bmrc.berkeley.edu (8.12.9p2/8.12.9/Submit) id j2A0IPXG000340; Wed, 9 Mar 2005 16:18:25 -0800 (PST) (envelope-from chema) Date: Wed, 9 Mar 2005 16:18:25 -0800 From: =?unknown-8bit?Q?Jos=E9_Mar=EDa_Gonz=E1lez?= To: freebsd-net@freebsd.org Message-ID: <20050310001825.GA320@cs.berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: Creating Multiple Discard Interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2005 00:18:26 -0000 Hi, I'm trying to create several discard interfaces on 4.9-RELEASE, and I'm having 2 problems. This is what I see (comments started by //): # ifconfig -a de0: ... lo0: ... // these are my original interfaces # kldload if_disc # ifconfig -a de0: ... lo0: ... ds0: flags=8008 mtu 65532 // surprisingly enough, just loading the if_disc kernel module creates // the ds0 interface for me. Well, I can live with that. # ifconfig ds0 create ifconfig: SIOCIFCREATE: Invalid argument # ifconfig disc0 create ifconfig: SIOCIFCREATE: Invalid argument // This makes sens, as the ds0 interface is already created # ifconfig ds1 create ifconfig: SIOCIFCREATE: Invalid argument # ifconfig disc1 create ifconfig: SIOCIFCREATE: Invalid argument // 1st problem: How do I create ds1, ds2, etc.? // Now I want to get rid of the if_disc module # ifconfig ds0 down # ifconfig ds0 destroy ifconfig: SIOCIFDESTROY: Invalid argument #ifconfig disc0 destroy ifconfig: interface disc0 does not exist # kldunload -v -i 4 Unloading if_disc.ko, id=4 kldunload: can't unload file: Invalid argument // 2nd problem: How do I get rid of the if_disc module? Thanks for any help you can provide. -Chema From owner-freebsd-net@FreeBSD.ORG Thu Mar 10 01:22:45 2005 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 2AA9316A4CE for ; Thu, 10 Mar 2005 01:22:45 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id E6E0343D46 for ; Thu, 10 Mar 2005 01:22:44 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j2A1MhOv027488; Wed, 9 Mar 2005 17:22:43 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j2A1Mh6E027487; Wed, 9 Mar 2005 17:22:43 -0800 Date: Wed, 9 Mar 2005 17:22:43 -0800 From: Brooks Davis To: =?iso-8859-1?Q?Jos=E9_Mar=EDa_Gonz=E1lez?= Message-ID: <20050310012243.GA26861@odin.ac.hmc.edu> References: <20050310001825.GA320@cs.berkeley.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zYM0uCDKw75PZbzx" Content-Disposition: inline In-Reply-To: <20050310001825.GA320@cs.berkeley.edu> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: freebsd-net@freebsd.org Subject: Re: Creating Multiple Discard Interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2005 01:22:45 -0000 --zYM0uCDKw75PZbzx Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 09, 2005 at 04:18:25PM -0800, Jos=E9 Mar=EDa Gonz=E1lez wrote: > Hi,=20 >=20 > I'm trying to create several discard interfaces on 4.9-RELEASE, and I'm= =20 > having 2 problems. This is what I see (comments started by //): >=20 > # ifconfig -a > de0: ... > lo0: ... > // these are my original interfaces >=20 > # kldload if_disc >=20 > # ifconfig -a > de0: ... > lo0: ... > ds0: flags=3D8008 mtu 65532 > // surprisingly enough, just loading the if_disc kernel module creates=20 > // the ds0 interface for me. Well, I can live with that.=20 >=20 > # ifconfig ds0 create > ifconfig: SIOCIFCREATE: Invalid argument > # ifconfig disc0 create > ifconfig: SIOCIFCREATE: Invalid argument > // This makes sens, as the ds0 interface is already created >=20 > # ifconfig ds1 create > ifconfig: SIOCIFCREATE: Invalid argument > # ifconfig disc1 create > ifconfig: SIOCIFCREATE: Invalid argument > // 1st problem: How do I create ds1, ds2, etc.? >=20 >=20 > // Now I want to get rid of the if_disc module > # ifconfig ds0 down > # ifconfig ds0 destroy > ifconfig: SIOCIFDESTROY: Invalid argument > #ifconfig disc0 destroy=20 > ifconfig: interface disc0 does not exist > # kldunload -v -i 4 > Unloading if_disc.ko, id=3D4 > kldunload: can't unload file: Invalid argument > // 2nd problem: How do I get rid of the if_disc module? The discard module is not unloadable or clonable before 5.0. You need to upgrade to 5.3+ or statically compile in the discard device with an appropriate count. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --zYM0uCDKw75PZbzx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCL6FjXY6L6fI4GtQRAi5lAKCazW5mF9+vCiKx3UjUkQ4Pzg10YQCgxeQC 7KmhFZh3/slnrZntDFVdShk= =bI+w -----END PGP SIGNATURE----- --zYM0uCDKw75PZbzx-- From owner-freebsd-net@FreeBSD.ORG Thu Mar 10 03:28:59 2005 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 B9DD516A4CE for ; Thu, 10 Mar 2005 03:28:59 +0000 (GMT) Received: from mailhost.schluting.com (schluting.com [131.252.214.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 91AA043D66 for ; Thu, 10 Mar 2005 03:28:59 +0000 (GMT) (envelope-from charlie@schluting.com) Received: from localhost (localhost [127.0.0.1]) by mailhost.schluting.com (Postfix) with ESMTP id 26E412231 for ; Wed, 9 Mar 2005 19:28:58 -0800 (PST) Received: from mailhost.schluting.com ([127.0.0.1]) by localhost (schluting.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21175-07 for ; Wed, 9 Mar 2005 19:28:53 -0800 (PST) Received: from [10.1.0.69] (c-24-20-163-50.client.comcast.net [24.20.163.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.schluting.com (Postfix) with ESMTP id 1E815209D for ; Wed, 9 Mar 2005 19:28:53 -0800 (PST) Message-ID: <422FBEF3.2060305@schluting.com> Date: Wed, 09 Mar 2005 19:28:51 -0800 From: Charlie Schluting User-Agent: Mozilla Thunderbird 1.0RC1 (Windows/20041201) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20050309111759.O97008@schluting.com> <3aa4b0ab62a3d4855fdc62383a77b9d5@mac.com> <422F5CF6.9070906@schluting.com> <422F5D66.6020808@schluting.com> <20050309135422.C13519@gateway.posi.net> In-Reply-To: <20050309135422.C13519@gateway.posi.net> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by your mom at schluting.com cc: net@freebsd.org Subject: Re: tcpdump/bpf and seeing .1q tags 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, 10 Mar 2005 03:28:59 -0000 Kelly Yancey wrote: > > You'll have a similar issue with BPF programs you write: you'll either > need to skip over the vlan tag header or not, depending on whether you > snagged the packet from the parent interface or the vlan interface. Indeed. Thanks! We skipped 12 bits ahead and everything is working now :)) -Charlie From owner-freebsd-net@FreeBSD.ORG Thu Mar 10 04:09:57 2005 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 13B8016A4CE for ; Thu, 10 Mar 2005 04:09:57 +0000 (GMT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id CDF5E43D41 for ; Thu, 10 Mar 2005 04:09:56 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.89] ([66.127.85.89]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j2A49ums062890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Mar 2005 20:09:56 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <422FC8C5.8000407@errno.com> Date: Wed, 09 Mar 2005 20:10:45 -0800 From: Sam Leffler Organization: Errno Consulting User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kevin Downey References: <1d3ed48c050309115139a9648c@mail.gmail.com> In-Reply-To: <1d3ed48c050309115139a9648c@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: ath0 and reason 25 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, 10 Mar 2005 04:09:57 -0000 Kevin Downey wrote: > I have a dlink card that uses the ath0 driver. a DLW520. And when a > try to connect to an AP I get an error in dmesg "ath: association > failed (reason 25)" followed by the BSSID of the AP. Is there a list > of "reasons" somewhere? I have tried on an open AP a closed AP with > WEP w/o WEP and I always get the same error. The card sees the AP > fine. kismet finds it no problem. Sometimes wicontrol -i ath0 -L will > show the AP and sometimes not. > I have tried looking around in /src/sys/dev/ath and /src/sys/net80211 for " > reasons" but my understanding of C / BSD internals is not very deep. You don't mention what OS version you're running. trouble% grep STATUS /usr/include/net80211/ieee80211.h|grep 25 IEEE80211_STATUS_SHORTSLOT_REQUIRED = 25, So the AP and station are not agreeing on how to configure the slot time. This may have something to do with the 11g configuration of your AP--e.g. did you fix long or short slot time in the AP? OTOH if you're running 5.x then there are some bugs in the 11g support that have been fixed in current and might cause this. Sam From owner-freebsd-net@FreeBSD.ORG Thu Mar 10 04:47:49 2005 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 3260516A4CE for ; Thu, 10 Mar 2005 04:47:49 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD5CB43D49 for ; Thu, 10 Mar 2005 04:47:48 +0000 (GMT) (envelope-from redchin@gmail.com) Received: by rproxy.gmail.com with SMTP id a41so407748rng for ; Wed, 09 Mar 2005 20:47:45 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=RcgP8m9CQ8fxpo4TDS1xnF8RqGHv1aY/f7RDgcY4NDVzZcoKj+TEl3OpK9vRjnu7aehWgc4Ub2IZ2+8BhLNilrEpu7WS2hwZ/ISzk0TAL3iM1YgNeX38yVNyQ1l9CDtRMXq7Dql14+c/MxXTOKFxmdmf4aDrIRvbw9ItbLXveX0= Received: by 10.38.86.28 with SMTP id j28mr1434458rnb; Wed, 09 Mar 2005 20:47:45 -0800 (PST) Received: by 10.38.149.8 with HTTP; Wed, 9 Mar 2005 20:47:45 -0800 (PST) Message-ID: <1d3ed48c05030920476fe55364@mail.gmail.com> Date: Wed, 9 Mar 2005 20:47:45 -0800 From: Kevin Downey To: freebsd-net@freebsd.org In-Reply-To: <422FC8C5.8000407@errno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1d3ed48c050309115139a9648c@mail.gmail.com> <422FC8C5.8000407@errno.com> Subject: Re: ath0 and reason 25 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Kevin Downey List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2005 04:47:49 -0000 Awesome. I have been thinking about tracking current anyway. Thanks a bundle. From owner-freebsd-net@FreeBSD.ORG Thu Mar 10 06:42:04 2005 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 AB58816A4CE for ; Thu, 10 Mar 2005 06:42:04 +0000 (GMT) Received: from espresso2.syncrontech.com (sync-old.syncrontech.com [213.28.98.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 80DFC43D2F for ; Thu, 10 Mar 2005 06:42:01 +0000 (GMT) (envelope-from ari@suutari.iki.fi) Received: from guinness.syncrontech.com (guinness.syncrontech.com [62.71.8.57])j2A6fvrn079513 for ; Thu, 10 Mar 2005 08:41:58 +0200 (EET) (envelope-from ari@suutari.iki.fi) Received: from [62.71.8.37] (coffee.syncrontech.com [62.71.8.37]) j2A6fpdU093814 for ; Thu, 10 Mar 2005 08:41:52 +0200 (EET) (envelope-from ari@suutari.iki.fi) Message-ID: <422FEC1B.5070105@suutari.iki.fi> Date: Thu, 10 Mar 2005 08:41:31 +0200 From: Ari Suutari User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Gemtek WLAN (conexant prism) and NDISulator problems 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, 10 Mar 2005 06:42:04 -0000 Hi, I have been trying to get WLAN working on my laptop. The built-in card is Gemtek WL850, which is using (as far as I understand) using conexant prism chip. As there is no driver for this, I have been trying to use Windows XP drivers with if_ndis. I have managed to get if_ndis.ko built ok. When I load it with kldload, it detects the card, then there is small delay (5-10 seconds), it prints out the wlan rates card supports (When I load if_ndis.ko during boot it doesn't work, I just get message that attach failed with status 6). If I try to configure ndis0 with ifconfig it behaves oddly. When I try to set ssid (ifconfig ndis0 ssid xxxx) it doesn't get set - running ifconfig ndis0 shows "" as ssid after setting it. When I try to set IP address, ifconfig takes long (again 5-10 seconds), the address gets set but things won't work. FreeBSD version is 5.3-STABLE snapshot that is available at www.freebsd.org/snapshots. Is the XP driver just bad or am I doing something wrong here ? (I have tested the wlan using older pcmcia card which is supported by wi driver - everything seems to work ok with it) Ari S. From owner-freebsd-net@FreeBSD.ORG Thu Mar 10 09:17:37 2005 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 674C616A4CE for ; Thu, 10 Mar 2005 09:17:37 +0000 (GMT) Received: from mxfep02.bredband.com (mxfep02.bredband.com [195.54.107.73]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C8B643D2F for ; Thu, 10 Mar 2005 09:17:36 +0000 (GMT) (envelope-from john@veidit.net) Received: from [192.168.20.45] ([213.115.251.220] [213.115.251.220]) by mxfep02.bredband.com with ESMTP id <20050310091734.ENR23781.mxfep02.bredband.com@[192.168.20.45]>; Thu, 10 Mar 2005 10:17:34 +0100 Message-ID: <4230109F.60808@veidit.net> Date: Thu, 10 Mar 2005 10:17:19 +0100 From: John Angelmo User-Agent: Mozilla Thunderbird 1.0 (X11/20050211) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Nickolay A. Kritsky" References: <41C15E0B.2050503@veidit.net> <671282193578.20041216144526@star-sw.com> In-Reply-To: <671282193578.20041216144526@star-sw.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: NAT problem with public network 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, 10 Mar 2005 09:17:37 -0000 Nickolay A. Kritsky wrote: > Hello John, > > You can use two ways: > 1. Add 'unregistered_only yes' to your natd.conf > 2. Run natd on xl2 with -reverse option > > If I were you I would do the first one. > I tried that with this rule on top ipfw add divert natd log all from any to any via xl0 Well that handles all the packages and just then kicks out the packets not to 192.168.20.0/24 to the rest of the IPFW rules, should I do something like this instead: ipfw add divert natd log all from 192.168.20.0/24 to any via xl0 keep-state I simply want to only nat the right rules and let the rest of the packages be handled by ipfw /John From owner-freebsd-net@FreeBSD.ORG Thu Mar 10 10:34:12 2005 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 8559B16A4CE for ; Thu, 10 Mar 2005 10:34:12 +0000 (GMT) Received: from mxfep01.bredband.com (mxfep01.bredband.com [195.54.107.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 704D143D46 for ; Thu, 10 Mar 2005 10:34:11 +0000 (GMT) (envelope-from john@veidit.net) Received: from [192.168.20.45] ([213.115.251.220] [213.115.251.220]) by mxfep01.bredband.com with ESMTP id <20050310103410.WKA26135.mxfep01.bredband.com@[192.168.20.45]> for ; Thu, 10 Mar 2005 11:34:10 +0100 Message-ID: <42302294.3060905@veidit.net> Date: Thu, 10 Mar 2005 11:33:56 +0100 From: John Angelmo User-Agent: Mozilla Thunderbird 1.0 (X11/20050211) X-Accept-Language: en-us, en MIME-Version: 1.0 To: net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Traffic statistics 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, 10 Mar 2005 10:34:12 -0000 I'm looking for some kind of software that can show me how much diffrent ports in my firewall are used and where the traffic is originating This way I can see if we get an attack over http from so I quickly can stop it in the FW /John From owner-freebsd-net@FreeBSD.ORG Thu Mar 10 10:50:52 2005 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 24FD316A4CE for ; Thu, 10 Mar 2005 10:50:52 +0000 (GMT) Received: from f38.mail.ru (f10.mail.ru [194.67.57.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id A109743D41 for ; Thu, 10 Mar 2005 10:50:51 +0000 (GMT) (envelope-from _pppp@mail.ru) Received: from mail by f38.mail.ru with local id 1D9LFR-000Bai-00; Thu, 10 Mar 2005 13:50:33 +0300 Received: from [81.200.13.122] by win.mail.ru with HTTP; Thu, 10 Mar 2005 13:50:33 +0300 From: dima <_pppp@mail.ru> To: John Angelmo Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: [81.200.13.122] Date: Thu, 10 Mar 2005 13:50:33 +0300 In-Reply-To: <42302294.3060905@veidit.net> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Message-Id: cc: net@freebsd.org Subject: Re: Traffic statistics X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: dima <_pppp@mail.ru> List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2005 10:50:52 -0000 -----Original Message----- From: John Angelmo To: net@freebsd.org Date: Thu, 10 Mar 2005 11:33:56 +0100 Subject: Traffic statistics > > I'm looking for some kind of software that can show me how much diffrent > ports in my firewall are used and where the traffic is originating > > This way I can see if we get an attack over http from country here> so I quickly can stop it in the FW You should try ng_netflow + flow-tools. > > /John > _______________________________________________ > 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 Mar 10 14:22:09 2005 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 8D74416A4CE for ; Thu, 10 Mar 2005 14:22:09 +0000 (GMT) Received: from ints.mail.pike.ru (ints.mail.pike.ru [195.9.45.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 41BBA43D5A for ; Thu, 10 Mar 2005 14:22:08 +0000 (GMT) (envelope-from babolo@cicuta.babolo.ru) Received: (qmail 26151 invoked from network); 10 Mar 2005 14:22:06 -0000 Received: from cicuta.babolo.ru (194.135.49.133) by ints.mail.pike.ru with SMTP; 10 Mar 2005 14:22:06 -0000 Received: (nullmailer pid 29388 invoked by uid 136); Thu, 10 Mar 2005 14:23:00 -0000 X-ELM-OSV: (Our standard violations) hdr-charset=KOI8-R; no-hdr-encoding=1 In-Reply-To: <3.0.1.32.20050309135120.00a7f5c0@pop.redshift.com> To: ray@redshift.com Date: Thu, 10 Mar 2005 17:23:00 +0300 (MSK) 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: <1110464580.382085.29387.nullmailer@cicuta.babolo.ru> cc: freebsd-net@freebsd.org Subject: Re: FreeBSD router question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2005 14:22:09 -0000 > Hello (just signed up to this list), > > I am wondering if anyone on the list has any experience using FreeBSD 5.3 as a > router in a high traffic environment? I am building a development cluster here > and have decided to try using FreeBSD as my main network router instead of > something like the Cisco 7200's, Force10, etc. > > I have 10 or 12 Xeon machines in my cluster so far, but may have as many as 50 > to 100 in the future (once our site goes live). Right now I have a 2.40 GHz > Xeon with 2GB of RAM running as the router using FreeBSD 5.3, ipf and ipnat > (this may be upgraded to an AMD64 bit dual core shortly). So far everything > seems to work fine, but it has not been under heavy load yet. The router has > been up for 26 days with no problems and works great. > > I've made the following tweaks (see end of message) to sysctl.conf in an effort > to get things going the right direction. I've also stripped down the kernel > file and recompiled. I read recently that FreeBSD was able to route 1Mpps, > which sounded pretty good, but I don't know if there are any specific tweaks I > need to make in order to obtain this sort of speed, or how fast it works "out of > the box" with just a few modifications? My main concern is that the router > works okay now, but when traffic ramps up, it hits a wall without some large > amount of exotic changes. I'd like to feel comfortable that the machine will > handle at least 50 to 100 megabits of traffic on a fairly sustained basis > without facing any major problems. Is that realistic or are there specific > changes I should make to the OS? > > If anyone on the list has any first hand information/experience that might steer > me the right direction, that would be great. Any feed back would be great, > Thanks very much! :-) We are using a lot of FreeBSD 4 routers. They route up to 35..40 Tbytes/router, 4..70 vlans per router, natd and argus runs for most of vlans, 1 natd and 1 argus per vlan. ipfw config is about 30..100 Kbyte, pipes for about half of traffic. Athlon XP on 760MPX mobo, 1Gbyte of memory. 2000 GHz (real) Athlon XP is 2+ faster router compare to 2.6 GHz Pentium 4. Configurators (route, arp, ipfw utilities) are something buggy under high load (we have up to 500 reconfigures/day), and second CPU is not useful if Athlon MP is used. I have bad impression on my FreeBSD 5 test on our routers and good on DragonFlyBSD test, but have no DragonFlyBSD router under full load yet. ... > net.inet.ip.fastforwarding=0 # not sure about this, but might want to It is hard to build complex ipfw rules with fastforwarding=1, dont know about ipf. > net.inet.tcp.recvspace=65535 # increase TCP window size for better > net.inet.tcp.sendspace=65535 Not used for routing. > kern.ipc.somaxconn=1024 # increase listen queue (defense against > SYN attacks, better performance) [128] Just close router fully, do not accept any connect but from one control interface from fully seperated internal net. From owner-freebsd-net@FreeBSD.ORG Fri Mar 11 02:46:48 2005 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 530CB16A4CE for ; Fri, 11 Mar 2005 02:46:48 +0000 (GMT) Received: from smtp11.wanadoo.fr (smtp11.wanadoo.fr [193.252.22.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 188B443D46 for ; Fri, 11 Mar 2005 02:46:48 +0000 (GMT) (envelope-from atkielski.anthony@wanadoo.fr) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf1106.wanadoo.fr (SMTP Server) with ESMTP id 53A1D1C00089 for ; Fri, 11 Mar 2005 03:46:47 +0100 (CET) Received: from pix.atkielski.com (ASt-Lambert-111-2-1-3.w81-50.abo.wanadoo.fr [81.50.80.3]) by mwinf1106.wanadoo.fr (SMTP Server) with ESMTP id 3DA7E1C00088 for ; Fri, 11 Mar 2005 03:46:47 +0100 (CET) X-ME-UUID: 20050311024647252.3DA7E1C00088@mwinf1106.wanadoo.fr Date: Fri, 11 Mar 2005 03:46:46 +0100 From: Anthony Atkielski X-Priority: 3 (Normal) Message-ID: <771770969.20050311034646@wanadoo.fr> To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Clock slew vulnerability in FreeBSD? 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: Fri, 11 Mar 2005 02:46:48 -0000 How vulnerable is FreeBSD to the recently announced technique for individually identifying computers by the clock slew apparent in TCP packets? If it is vulnerable to this, will there be any plans to address the vulnerability? -- Anthony From owner-freebsd-net@FreeBSD.ORG Fri Mar 11 04:02:36 2005 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 15E4A16A4CE for ; Fri, 11 Mar 2005 04:02:36 +0000 (GMT) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id A0A3543D1D for ; Fri, 11 Mar 2005 04:02:35 +0000 (GMT) (envelope-from e.schuele@computer.org) Received: from [192.168.214.218] (c-24-1-232-64.client.comcast.net[24.1.232.64]) by comcast.net (sccrmhc13) with ESMTP id <2005031104023101600hfps9e>; Fri, 11 Mar 2005 04:02:35 +0000 Message-ID: <42311883.8090102@computer.org> Date: Thu, 10 Mar 2005 22:03:15 -0600 From: Eric Schuele User-Agent: Mozilla Thunderbird 1.0 (X11/20050127) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Leffler References: <1d3ed48c050309115139a9648c@mail.gmail.com> <422FC8C5.8000407@errno.com> In-Reply-To: <422FC8C5.8000407@errno.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: ath0 and reason 25 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, 11 Mar 2005 04:02:36 -0000 Sam Leffler wrote: > Kevin Downey wrote: > >> I have a dlink card that uses the ath0 driver. a DLW520. And when a >> try to connect to an AP I get an error in dmesg "ath: association >> failed (reason 25)" followed by the BSSID of the AP. Is there a list >> of "reasons" somewhere? I have tried on an open AP a closed AP with >> WEP w/o WEP and I always get the same error. The card sees the AP >> fine. kismet finds it no problem. Sometimes wicontrol -i ath0 -L will >> show the AP and sometimes not. >> I have tried looking around in /src/sys/dev/ath and /src/sys/net80211 >> for " >> reasons" but my understanding of C / BSD internals is not very deep. > > > You don't mention what OS version you're running. > > trouble% grep STATUS /usr/include/net80211/ieee80211.h|grep 25 > IEEE80211_STATUS_SHORTSLOT_REQUIRED = 25, > > So the AP and station are not agreeing on how to configure the slot > time. This may have something to do with the 11g configuration of your > AP--e.g. did you fix long or short slot time in the AP? OTOH if you're > running 5.x then there are some bugs in the 11g support that have been > fixed in current and might cause this. Will these fixes find their way to 5.x? -Eric > > Sam > _______________________________________________ > 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" > -- Regards, Eric From owner-freebsd-net@FreeBSD.ORG Fri Mar 11 04:06:00 2005 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 D45E616A4CE for ; Fri, 11 Mar 2005 04:06:00 +0000 (GMT) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 288A443D5A for ; Fri, 11 Mar 2005 04:06:00 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) j2B45wV1033454; Thu, 10 Mar 2005 20:05:58 -0800 (PST) (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.10/meer) with ESMTP id j2B45suG088225; Thu, 10 Mar 2005 20:05:55 -0800 (PST) (envelope-from gnn@neville-neil.com) Date: Fri, 11 Mar 2005 13:05:52 +0900 Message-ID: From: gnn@freebsd.org To: Anthony Atkielski In-Reply-To: <771770969.20050311034646@wanadoo.fr> References: <771770969.20050311034646@wanadoo.fr> User-Agent: Wanderlust/2.12.0 (Your Wildest Dreams) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.7.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: Clock slew vulnerability in FreeBSD? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2005 04:06:01 -0000 At Fri, 11 Mar 2005 03:46:46 +0100, Anthony Atkielski wrote: > > > How vulnerable is FreeBSD to the recently announced technique for > individually identifying computers by the clock slew apparent in TCP > packets? If it is vulnerable to this, will there be any plans to > address the vulnerability? > I gather you mean this paper: http://www.caida.org/outreach/papers/2005/fingerprinting/ It's an interesting read. As to how vulnerable FreeBSD is to this I do not know nor do I know if we should bother to do anything about it. What, in particular are you worried about here? Also, if you consider this a security issue you should probably also include the security team in this discussion. Later, George From owner-freebsd-net@FreeBSD.ORG Fri Mar 11 04:28:46 2005 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 9CAC416A4CF for ; Fri, 11 Mar 2005 04:28:46 +0000 (GMT) Received: from smtp4.wlink.com.np (smtp4.wlink.com.np [202.79.32.87]) by mx1.FreeBSD.org (Postfix) with SMTP id 5043243D58 for ; Fri, 11 Mar 2005 04:28:43 +0000 (GMT) (envelope-from bikrant_ml@wlink.com.np) Received: (qmail 12120 invoked from network); 11 Mar 2005 04:28:38 -0000 Received: from unknown (HELO wlink.com.np) (202.79.32.45) by 0 with SMTP; 11 Mar 2005 04:28:38 -0000 Received: (qmail 32295 invoked by uid 510); 11 Mar 2005 04:28:38 -0000 Received: from 202.79.36.168 by testmx.wlink.com.np (envelope-from , uid 508) with qmail-scanner-1.25 (clamdscan: 0.83/705. Clear:RC:1(202.79.36.168):. Processed in 0.030466 secs); 11 Mar 2005 04:28:38 -0000 X-Qmail-Scanner-Mail-From: bikrant_ml@wlink.com.np via testmx.wlink.com.np X-Qmail-Scanner: 1.25 (Clear:RC:1(202.79.36.168):. Processed in 0.030466 secs) Received: from [202.79.36.168] (HELO bikrant.wlink.com.np) by wlink.com.np (qmail-smtpd) with SMTP; 11 Mar 2005 04:28:36 -0000 (Fri, 11 Mar 2005 10:13:36 +0545) From: Bikrant Neupane To: freebsd-net@freebsd.org Date: Fri, 11 Mar 2005 10:13:30 +0545 User-Agent: KMail/1.7.2 References: <002a01c523ef$bc5af280$eb2d4fca@HOME> <01d001c5246c$0b9ddc50$42764eca@ilo.skyinet.net> In-Reply-To: <01d001c5246c$0b9ddc50$42764eca@ilo.skyinet.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503111013.30287.bikrant_ml@wlink.com.np> X-Spam-Check-By: wlink.com.np Spam: No ; 4.1 / 5.0 X-Spam-Status-WL: No, hits=4.1 required=5.0 cc: freebsd-isp@freebsd.org cc: fooler Subject: Re: Session Timeout issue in pppoed 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, 11 Mar 2005 04:28:46 -0000 Exactly!!! There was a bug in our radius code :D thanks again, Bikrant On Wednesday 09 March 2005 11:36, fooler wrote: > ----- Original Message ----- > From: "Bikrant Neupane" > To: > Cc: > Sent: Tuesday, March 08, 2005 11:01 PM > Subject: Session Timeout issue in pppoed > > > Hi, > > I have a pppoe server on FreeBSD 4.10. > > I have configured my Radius Server ( radiator) to set Session-Timeout > > parameter so that the clients who are using prepaid hour based service > > get disconnected when their time is over. In the ppp.log file I see the > > the Sessio-Timeout being accepted by the server. In the mean time the > > same connection has another Session-Timeout parameter set whose value is > > 0!! As > > a > > > result the clients do not get dsconnected at the specified time. > > I guess this is configuration issue/problem with ppp rather than pppoed. > > > > this is a portion of my ppp.log file. > > > > ppp[18466]: Phase: PPP Started (direct mode). > > ppp[18466]: Phase: bundle: Establish > > ppp[18466]: Phase: deflink: closed -> opening > > ppp[18466]: Phase: deflink: Link is a netgraph node > > ppp[18466]: Phase: deflink: Connected! > > ppp[18466]: Phase: deflink: opening -> carrier > > ppp[18466]: Phase: deflink: carrier -> lcp > > ppp[18466]: Phase: bundle: Authenticate > > ppp[18466]: Phase: deflink: his = none, mine = PAP > > ppp[18466]: Phase: Pap Input: REQUEST (gomez5) > > ppp[18466]: Phase: Radius: Request sent > > ppp[18466]: Phase: Radius(auth): ACCEPT received > > ppp[18466]: Phase: MTU 768 > > ppp[18466]: Phase: VJ enabled > > ppp[18466]: Phase: Session-Timeout 29218 <<<<< > > ppp[18466]: Phase: Session-Timeout 0 <<<<< > > ppp[18466]: Phase: Pap Output: SUCCESS > > ppp[18466]: Phase: deflink: lcp -> open > > ppp[18466]: Phase: bundle: Network > > ppp[18466]: Phase: Radius(acct): Accounting response received > > > > Here is my ppp.conf file > > default: > > allow users > > enable pap > > allow mode direct > > set mru 1492 > > set mtu 1492 > > set speed sync > > set timeout 172800 #2 days: 48hrs > > enable lqr > > set ifaddr 202.79.xx.xx 202.79.xx.xx-202.79.xx.xx > > load server > > set radius /etc/radius.conf > > accept dns > > > > > > Any idea why this is happening?? Please suggest. > > pppoed is just a daemon processing the pppoe frames while (user) ppp is the > one handling the session-timeout radius attribute once configured to use > the radius service... the way i look at it, your radius server (radiator) > is sending two session-timeout attributes which the user ppp accepted the > two attributes and set the last value which is 0 (unlimited time)... try a > tcpdump or your radiator utility if indeed your radius server is sending > two session-timeout attributes... > > fooler. > > _______________________________________________ > 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 Fri Mar 11 05:56:54 2005 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 B0A2116A4CE for ; Fri, 11 Mar 2005 05:56:54 +0000 (GMT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E5FB43D39 for ; Fri, 11 Mar 2005 05:56:54 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.89] ([66.127.85.89]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j2B5ujms069720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Mar 2005 21:56:49 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <4231334F.6040109@errno.com> Date: Thu, 10 Mar 2005 21:57:35 -0800 From: Sam Leffler Organization: Errno Consulting User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Schuele References: <1d3ed48c050309115139a9648c@mail.gmail.com> <422FC8C5.8000407@errno.com> <42311883.8090102@computer.org> In-Reply-To: <42311883.8090102@computer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: ath0 and reason 25 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, 11 Mar 2005 05:56:54 -0000 Eric Schuele wrote: > Sam Leffler wrote: > >> Kevin Downey wrote: >> >>> I have a dlink card that uses the ath0 driver. a DLW520. And when a >>> try to connect to an AP I get an error in dmesg "ath: association >>> failed (reason 25)" followed by the BSSID of the AP. Is there a list >>> of "reasons" somewhere? I have tried on an open AP a closed AP with >>> WEP w/o WEP and I always get the same error. The card sees the AP >>> fine. kismet finds it no problem. Sometimes wicontrol -i ath0 -L will >>> show the AP and sometimes not. >>> I have tried looking around in /src/sys/dev/ath and /src/sys/net80211 >>> for " >>> reasons" but my understanding of C / BSD internals is not very deep. >> >> >> >> You don't mention what OS version you're running. >> >> trouble% grep STATUS /usr/include/net80211/ieee80211.h|grep 25 >> IEEE80211_STATUS_SHORTSLOT_REQUIRED = 25, >> >> So the AP and station are not agreeing on how to configure the slot >> time. This may have something to do with the 11g configuration of >> your AP--e.g. did you fix long or short slot time in the AP? OTOH if >> you're running 5.x then there are some bugs in the 11g support that >> have been fixed in current and might cause this. > > > Will these fixes find their way to 5.x? Probably not. The 802.11 code in 5.x is very out of date and backmerging even the simplest changes is problematic. I'm spending all my FreeBSD time on current. Sam From owner-freebsd-net@FreeBSD.ORG Fri Mar 11 06:00:39 2005 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 E64C516A4CE for ; Fri, 11 Mar 2005 06:00:39 +0000 (GMT) Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by mx1.FreeBSD.org (Postfix) with SMTP id F2BAA43D31 for ; Fri, 11 Mar 2005 06:00:38 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 25840 invoked from network); 11 Mar 2005 06:00:38 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 11 Mar 2005 06:00:38 -0000 X-pair-Authenticated: 209.68.2.70 Date: Fri, 11 Mar 2005 00:00:36 -0600 (CST) From: Mike Silbersack To: gnn@freebsd.org In-Reply-To: Message-ID: <20050310235904.N15599@odysseus.silby.com> References: <771770969.20050311034646@wanadoo.fr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-net@freebsd.org cc: Anthony Atkielski Subject: Re: Clock slew vulnerability in FreeBSD? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2005 06:00:40 -0000 On Fri, 11 Mar 2005 gnn@freebsd.org wrote: > As to how vulnerable FreeBSD is to this I do not know nor do I know if > we should bother to do anything about it. What, in particular are you > worried about here? Also, if you consider this a security issue you > should probably also include the security team in this discussion. > > Later, > George I'd guess that we're fully "vulnerable" to this, but I don't see it really as an issue, unless someone is trying to hide a whole bunch of FreeBSD boxes behind that. And if that's what you're doing, run PF on the NAT machine, I think it has options to scramble such things, no matter what OS the clients behind it are running. Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Fri Mar 11 06:23:59 2005 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 00C1516A4CE for ; Fri, 11 Mar 2005 06:23:59 +0000 (GMT) Received: from apu.bmrc.berkeley.edu (apu.BMRC.Berkeley.EDU [169.229.12.108]) by mx1.FreeBSD.org (Postfix) with ESMTP id A291D43D4C for ; Fri, 11 Mar 2005 06:23:58 +0000 (GMT) (envelope-from chema@apu.bmrc.berkeley.edu) Received: from apu.bmrc.berkeley.edu (localhost [127.0.0.1]) j2B6NwmE001813 for ; Thu, 10 Mar 2005 22:23:58 -0800 (PST) (envelope-from chema@apu.bmrc.berkeley.edu) Received: (from chema@localhost) by apu.bmrc.berkeley.edu (8.12.9p2/8.12.9/Submit) id j2B6NwM5001812 for freebsd-net@freebsd.org; Thu, 10 Mar 2005 22:23:58 -0800 (PST) (envelope-from chema) Date: Thu, 10 Mar 2005 22:23:58 -0800 From: =?iso-8859-1?Q?Jos=E9_Mar=EDa_Gonz=E1lez?= To: FreeBSD-net list Message-ID: <20050311062358.GA1764@cs.berkeley.edu> Mail-Followup-To: FreeBSD-net list Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: Using a pseudo-device for IPC 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, 11 Mar 2005 06:23:59 -0000 Hi, I am trying to use a network pseudo-device to do (bidirectional) IPC between 2 processes. Why such a weird thing? Well, one of the processes (S) is a simulator of a NIC we're implementing in HW. I want the other process (O) to always interact with a network device, BPF-style. My idea is, if I want to test the real NIC, I'll tell O that the network device name is "mycard0." Otherwise, I'll fire up S, and let O know that the network device name is something like "mysimulatorcard0." I don't want to create my own pseudo-devices, so I'm trying to use what there is into 4.10-RELEASE. I need a virtual device where both O and S can read and write packets. FYI, both processes open a pcap interface using a modified version of pcap_open_live (which opens the descriptor in O_RDWR mode, instead of O_RDONLY). Processes read packets using plain libpcap, and write them using "write (p->fd, ...)". Which pseudo-device should I use? - my first thought was using the discard interface. I can read and write traffic to ds0. The problem is, with only 1 device, I don't know which side a packet comes from. This means that, for bidirectional comm, I need 2 discard interfaces, and 4.10 only supports one. - I've been considering tap (I want to keep Ethernet addresses, so tap is better than tun for me). The problem is, the same piece of code that is able to inject traffic into all my other devices (I've tried ds, em, bge, and lo, and all of them work), fails silently in tap. I enclode the writer code as a PS. I've checked /var/log/messages, and every time I try to inject a packet I get the following 2 lines: ... Mar 10 22:09:48 alpo /kernel: tap1 starting, minor = 0x1 Mar 10 22:09:48 alpo /kernel: tap1 not ready. minor = 0x1, tap_flags = 0x6 ... After browsing /usr/src/sys/net, it seems tap_flags is TAP_INITED|TAP_RWAIT, i.e., the TAP_OPEN flag is not set, so tapifstart() fails. Interestingly enough, the if that makes tapifstart() fail is actually: if (((tp->tap_flags & TAP_VMNET) == 0) && ((tp->tap_flags & TAP_READY) != TAP_READY)) { ... } This seems to refer to vmnet devices. While in tap(4) says that the only difference is the minor number and that "VMnet devices do not ifconfig(8) themselves down when the control device is closed", it seems that a vmnet device may pass through this if, and therefore I could be able to use it. Am I right? Is there a better approach to do this? Thanks for any help. -Chema PS: This is the program that tests interfaces: pcap_t * my_pcap_open_live (const char *device, int snaplen, int promisc, int to_ms, char *ebuf); int main () { test_interface ("tap1"); return 0; } void test_interface (const char *interface) { char ebuf[PCAP_ERRBUF_SIZE]; int snaplen, promiscuous; pcap_t *_pcap; int timeout; int pcap_fd; int outbound, yes; bpf_u_int32 netmask, localnet; struct bpf_program fcode; int datalink; char *bpf_filter = ""; unsigned char *packet; int i, retval; fprintf (stdout, "%s: testing interface %s\n", __func__, interface); snaplen = 65000; promiscuous = 1; timeout = 1; // don't wait for packets _pcap = my_pcap_open_live(interface, snaplen, promiscuous, timeout, ebuf); if ( !_pcap ) { fprintf (stderr, "Error opening interface %s: %s\n", interface, ebuf); exit (-1); } // capture outbound traffic pcap_fd = pcap_fileno(_pcap); outbound = 1; if ( ioctl(pcap_fd, BIOCSSEESENT, &outbound) != 0 ) { fprintf (stderr, "%s: BIOCSSEESENT failed\n", __func__); exit (-1); } // set immediate capturing yes = 1; if ( ioctl(pcap_fd, BIOCIMMEDIATE, &yes) != 0 ) { fprintf (stderr, "%s: BIOCIMMEDIATE failed\n", __func__); exit (-1); } // get local net info if ( pcap_lookupnet((char *)interface, &localnet, &netmask, ebuf) < 0 ) { if ( errno != EADDRNOTAVAIL ) { fprintf (stderr, "%s: pcap_lookupnet failed (%s)\n", __func__, ebuf); exit (-1); } else { fprintf (stderr, "warning @%s: pcap_lookupnet failed (%s)\n", __func__, ebuf); netmask = 0xffffff00; } } fprintf (stdout, "%s: pcap_lookupnet produced netmask=0x%08x, " "localnet=0x%08x\n", __func__, netmask, localnet); // compile and set a void BPF filter if ( pcap_compile(_pcap, &fcode, bpf_filter, 0, netmask) < 0 ) { fprintf (stderr, "%s: pcap_compile failed (%s)\n", __func__, pcap_geterr(_pcap)); exit (-1); } if ( pcap_setfilter(_pcap, &fcode) < 0 ) { fprintf (stderr, "%s: pcap_setfilter failed (%s)\n", __func__, pcap_geterr(_pcap)); exit (-1); } // get datalink datalink = pcap_datalink(_pcap); // inject a packet packet = (unsigned char *) malloc (1024 * sizeof(unsigned char)); for (i = 0; i < 1024; i++) { packet[i] = (unsigned char)(i % 256); } retval = ((uint32_t) write(_pcap->fd, packet, 1024) == 1024 ? 0 : -1); if ( retval < 0 ) { fprintf (stderr, "%s: write failed (%s)\n", __func__, strerror(errno)); exit (-1); } // cleanup pcap_close(_pcap); return; } // the original pcap_open_live() doesn't open for writing // this is just copied from pcap-bpf.c:pcap_open_live() pcap_t * my_pcap_open_live (const char *device, int snaplen, int promisc, int to_ms, char *ebuf) { int fd; struct ifreq ifr; struct bpf_version bv; u_int v; pcap_t *p; int i; // alloc the object p = (pcap_t *) malloc(sizeof(*p)); if ( p == NULL ) { snprintf(ebuf, PCAP_ERRBUF_SIZE, "malloc: %s", pcap_strerror(errno)); return NULL; } memset(p, 0, sizeof(*p)); // open the device //fd = bpf_open(p, ebuf); fd = -1; for ( i = 0; i < 16 && fd < 0; i++ ) { char tmp[64]; sprintf(tmp, "/dev/bpf%d", i); fd = open(tmp, O_RDWR); } if ( fd < 0 ) { snprintf(ebuf, PCAP_ERRBUF_SIZE, "error opening /dev/bpf* for write: %s", strerror(errno)); return NULL; } // fill up the object p->fd = fd; p->snapshot = snaplen; if ( ioctl(fd, BIOCVERSION, (caddr_t)&bv) < 0 ) { snprintf(ebuf, PCAP_ERRBUF_SIZE, "BIOCVERSION: %s", pcap_strerror(errno)); return NULL; } // check BPF version if ( bv.bv_major != BPF_MAJOR_VERSION || bv.bv_minor < BPF_MINOR_VERSION ) { snprintf(ebuf, PCAP_ERRBUF_SIZE, "kernel bpf filter out of date"); return NULL; } // set kernel buffer size if ( (ioctl(fd, BIOCGBLEN, (caddr_t)&v) < 0) || v < 32768 ) v = 32768; for ( ; v != 0; v >>= 1) { (void) ioctl(fd, BIOCSBLEN, (caddr_t)&v); (void)strncpy(ifr.ifr_name, device, sizeof(ifr.ifr_name)); if ( ioctl(fd, BIOCSETIF, (caddr_t)&ifr) >= 0 ) break; /* that size worked; we're done */ if (errno != ENOBUFS) { snprintf(ebuf, PCAP_ERRBUF_SIZE, "BIOCSETIF: %s: %s", device, pcap_strerror(errno)); return NULL; } } if (v == 0) { snprintf(ebuf, PCAP_ERRBUF_SIZE, "BIOCSBLEN: %s: No buffer size worked", device); return NULL; } // get the data link layer type if ( ioctl(fd, BIOCGDLT, (caddr_t)&v) < 0 ) { snprintf(ebuf, PCAP_ERRBUF_SIZE, "BIOCGDLT: %s", pcap_strerror(errno)); return NULL; } v = DLT_EN10MB; /* set timeout */ if ( to_ms != 0 ) { struct timeval to; to.tv_sec = to_ms / 1000; to.tv_usec = (to_ms * 1000) % 1000000; if (ioctl(p->fd, BIOCSRTIMEOUT, (caddr_t)&to) < 0) { snprintf(ebuf, PCAP_ERRBUF_SIZE, "BIOCSRTIMEOUT: %s", pcap_strerror(errno)); return NULL; } } v = 1; if ( ioctl(p->fd, BIOCIMMEDIATE, &v) < 0 ) { snprintf(ebuf, PCAP_ERRBUF_SIZE, "BIOCIMMEDIATE: %s", pcap_strerror(errno)); return NULL; } if (promisc) { /* set promiscuous mode, okay if it fails */ if ( ioctl(p->fd, BIOCPROMISC, NULL) < 0 ) { snprintf(ebuf, PCAP_ERRBUF_SIZE, "BIOCPROMISC: %s", pcap_strerror(errno)); return NULL; } } if (ioctl(fd, BIOCGBLEN, (caddr_t)&v) < 0) { snprintf(ebuf, PCAP_ERRBUF_SIZE, "BIOCGBLEN: %s", pcap_strerror(errno)); return NULL; } p->bufsize = v; p->buffer = (u_char *)malloc(p->bufsize); if (p->buffer == NULL) { snprintf(ebuf, PCAP_ERRBUF_SIZE, "malloc: %s", pcap_strerror(errno)); return NULL; } return (p); } From owner-freebsd-net@FreeBSD.ORG Fri Mar 11 11:02:41 2005 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 4047B16A4CE; Fri, 11 Mar 2005 11:02:41 +0000 (GMT) Received: from relay.bestcom.ru (relay.bestcom.ru [217.72.144.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28F9043D41; Fri, 11 Mar 2005 11:02:40 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (root@cell.sick.ru [217.72.144.68]) by relay.bestcom.ru (8.13.1/8.12.9) with ESMTP id j2BB2bwd086145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 11 Mar 2005 14:02:37 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.1/8.12.8) with ESMTP id j2BB2a8R087338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Mar 2005 14:02:36 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.1/8.13.1/Submit) id j2BB2YQf087337; Fri, 11 Mar 2005 14:02:35 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 11 Mar 2005 14:02:34 +0300 From: Gleb Smirnoff To: Luigi Rizzo , John Baldwin , dima <_pppp@mail.ru> Message-ID: <20050311110234.GA87255@cell.sick.ru> References: <20050217161031.A46700@xorpc.icir.org> <200503011642.48813.jhb@FreeBSD.org> <20050301162949.A64187@xorpc.icir.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="X1bOJ3K7DJ5YkBrT" Content-Disposition: inline In-Reply-To: <20050301162949.A64187@xorpc.icir.org> User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV version devel-20050125, clamav-milter version 0.80ff on relay.bestcom.ru X-Virus-Status: Clean cc: pjd@FreeBSD.org cc: rwatson@FreeBSD.org cc: ru@FreeBSD.org cc: net@FreeBSD.org Subject: Re: Giant-free polling [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: Fri, 11 Mar 2005 11:02:41 -0000 --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Collegues, On Tue, Mar 01, 2005 at 04:29:49PM -0800, Luigi Rizzo wrote: L> [cc-ing net@freebsd.org to get more opinions] this good, that you have CC'ed net@, otherwise we would continue working in parallel without collaboration. Here is attached patch made in a collaboration by ru, pjd and me. We use separate mutex for polling, and we drop it before calling the poll handler to avoid LOR and contention on this mutex. We have definite evidence that now idle_poll and ISR poll can run in parallel: if we remove PRF_RUNNING flag check, we got panics because poll handlers of many drivers (e.g. if_em) are not reentrable. I think this patch is a step forward in direction of parallel polling on SMP, since we now have two polling instances (ISR + idle) working in parallel. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=koi8-r Content-Disposition: attachment; filename="kern_poll.LIST.diff" Index: kern_poll.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_poll.c,v retrieving revision 1.19 diff -u -r1.19 kern_poll.c --- kern_poll.c 25 Feb 2005 22:07:50 -0000 1.19 +++ kern_poll.c 11 Mar 2005 10:49:47 -0000 @@ -33,6 +33,7 @@ #include #include /* needed by net/if.h */ #include +#include #include /* for IFF_* flags */ #include /* for NETISR_POLL */ @@ -144,7 +145,7 @@ SYSCTL_INT(_kern_polling, OID_AUTO, residual_burst, CTLFLAG_RW, &residual_burst, 0, "# of residual cycles in burst"); -static u_int32_t poll_handlers; /* next free entry in pr[]. */ +static u_int32_t poll_handlers; SYSCTL_UINT(_kern_polling, OID_AUTO, handlers, CTLFLAG_RD, &poll_handlers, 0, "Number of registered poll handlers"); @@ -169,20 +170,33 @@ &idlepoll_sleeping, 0, "idlepoll is sleeping"); -#define POLL_LIST_LEN 128 struct pollrec { poll_handler_t *handler; struct ifnet *ifp; +#define PRF_RUNNING 0x1 +#define PRF_PINNED 0x2 + uint32_t flags; + LIST_ENTRY(pollrec) next; }; -static struct pollrec pr[POLL_LIST_LEN]; +#define PR_VALID(pr) ((pr)->handler != NULL && \ + !((pr)->flags & PRF_RUNNING) && \ + ((pr)->ifp->if_flags & (IFF_UP|IFF_RUNNING)) == \ + (IFF_UP|IFF_RUNNING)) + +static LIST_HEAD(, pollrec) poll_list = LIST_HEAD_INITIALIZER(&poll_list); + +static struct mtx poll_mtx; static void init_device_poll(void) { - netisr_register(NETISR_POLL, (netisr_t *)netisr_poll, NULL, 0); - netisr_register(NETISR_POLLMORE, (netisr_t *)netisr_pollmore, NULL, 0); + mtx_init(&poll_mtx, "polling", NULL, MTX_DEF); + netisr_register(NETISR_POLL, (netisr_t *)netisr_poll, NULL, + NETISR_MPSAFE); + netisr_register(NETISR_POLLMORE, (netisr_t *)netisr_pollmore, NULL, + NETISR_MPSAFE); } SYSINIT(device_poll, SI_SUB_CLOCKS, SI_ORDER_MIDDLE, init_device_poll, NULL) @@ -244,17 +258,26 @@ void ether_poll(int count) { - int i; - - mtx_lock(&Giant); + struct pollrec *pr, *pr1; if (count > poll_each_burst) count = poll_each_burst; - for (i = 0 ; i < poll_handlers ; i++) - if (pr[i].handler && (IFF_UP|IFF_RUNNING) == - (pr[i].ifp->if_flags & (IFF_UP|IFF_RUNNING)) ) - pr[i].handler(pr[i].ifp, 0, count); /* quick check */ - mtx_unlock(&Giant); + + mtx_lock(&poll_mtx); + LIST_FOREACH_SAFE(pr, &poll_list, next, pr1) { + if (PR_VALID(pr)) { + pr->flags |= PRF_RUNNING; + if (pr1 != NULL) + pr1->flags |= PRF_PINNED; + mtx_unlock(&poll_mtx); + pr->handler(pr->ifp, 0, count); + mtx_lock(&poll_mtx); + if (pr1 != NULL) + pr1->flags &= ~PRF_PINNED; + pr->flags &= ~PRF_RUNNING; + } + } + mtx_unlock(&poll_mtx); } /* @@ -320,17 +343,17 @@ /* * netisr_poll is scheduled by schednetisr when appropriate, typically once - * per tick. It is called at splnet() so first thing to do is to upgrade to - * splimp(), and call all registered handlers. + * per tick. */ static void netisr_poll(void) { + struct pollrec *pr, *pr1; static int reg_frac_count; - int i, cycles; + int cycles; enum poll_cmd arg = POLL_ONLY; - mtx_lock(&Giant); + mtx_lock(&poll_mtx); phase = 3; if (residual_burst == 0) { /* first call in this tick */ microuptime(&poll_start_t); @@ -372,25 +395,36 @@ residual_burst -= cycles; if (polling) { - for (i = 0 ; i < poll_handlers ; i++) - if (pr[i].handler && (IFF_UP|IFF_RUNNING) == - (pr[i].ifp->if_flags & (IFF_UP|IFF_RUNNING)) ) - pr[i].handler(pr[i].ifp, arg, cycles); + LIST_FOREACH_SAFE(pr, &poll_list, next, pr1) { + if (PR_VALID(pr)) { + pr->flags |= PRF_RUNNING; + mtx_unlock(&poll_mtx); + pr->handler(pr->ifp, arg, cycles); + mtx_lock(&poll_mtx); + pr->flags &= ~PRF_RUNNING; + } else if (pr->handler == NULL && + !(pr->flags & PRF_PINNED)) { + LIST_REMOVE(pr, next); + free(pr, M_TEMP); + } + } } else { /* unregister */ - for (i = 0 ; i < poll_handlers ; i++) { - if (pr[i].handler && - pr[i].ifp->if_flags & IFF_RUNNING) { - pr[i].ifp->if_flags &= ~IFF_POLLING; - pr[i].handler(pr[i].ifp, POLL_DEREGISTER, 1); + LIST_FOREACH_SAFE(pr, &poll_list, next, pr1) { + if (pr->handler != NULL && + pr->ifp->if_flags & IFF_RUNNING) { + pr->ifp->if_flags &= ~IFF_POLLING; + mtx_unlock(&poll_mtx); + pr->handler(pr->ifp, POLL_DEREGISTER, 1); + mtx_lock(&poll_mtx); } - pr[i].handler=NULL; + pr->handler = NULL; } residual_burst = 0; poll_handlers = 0; } /* on -stable, schednetisr(NETISR_POLLMORE); */ phase = 4; - mtx_unlock(&Giant); + mtx_unlock(&poll_mtx); } /* @@ -399,12 +433,12 @@ * A device is not supposed to register itself multiple times. * * This is called from within the *_intr() functions, so we do not need - * further locking. + * further ifnet locking. */ int ether_poll_register(poll_handler_t *h, struct ifnet *ifp) { - int s; + struct pollrec *pr; if (polling == 0) /* polling disabled, cannot register */ return 0; @@ -415,30 +449,27 @@ if (ifp->if_flags & IFF_POLLING) /* already polling */ return 0; - s = splhigh(); - if (poll_handlers >= POLL_LIST_LEN) { - /* - * List full, cannot register more entries. - * This should never happen; if it does, it is probably a - * broken driver trying to register multiple times. Checking - * this at runtime is expensive, and won't solve the problem - * anyways, so just report a few times and then give up. - */ - static int verbose = 10 ; - splx(s); - if (verbose >0) { - printf("poll handlers list full, " - "maybe a broken driver ?\n"); - verbose--; + mtx_lock(&poll_mtx); + LIST_FOREACH(pr, &poll_list, next) + if (pr->ifp == ifp && pr->handler != NULL) { + mtx_unlock(&poll_mtx); + log(LOG_DEBUG, "ether_poll_register: %s: handler" + " already registered\n", ifp->if_xname); + return (0); } - return 0; /* no polling for you */ + pr = malloc(sizeof(*pr), M_TEMP, M_NOWAIT); + if (pr == NULL) { + mtx_unlock(&poll_mtx); + log(LOG_DEBUG, "ether_poll_register: malloc() failed\n"); + return (0); } - pr[poll_handlers].handler = h; - pr[poll_handlers].ifp = ifp; + pr->handler = h; + pr->ifp = ifp; + LIST_INSERT_HEAD(&poll_list, pr, next); poll_handlers++; ifp->if_flags |= IFF_POLLING; - splx(s); + mtx_unlock(&poll_mtx); if (idlepoll_sleeping) wakeup(&idlepoll_sleeping); return 1; /* polling enabled in next call */ @@ -453,29 +484,24 @@ int ether_poll_deregister(struct ifnet *ifp) { - int i; + struct pollrec *pr; - mtx_lock(&Giant); if ( !ifp || !(ifp->if_flags & IFF_POLLING) ) { - mtx_unlock(&Giant); return 0; } - for (i = 0 ; i < poll_handlers ; i++) - if (pr[i].ifp == ifp) /* found it */ - break; - ifp->if_flags &= ~IFF_POLLING; /* found or not... */ - if (i == poll_handlers) { - mtx_unlock(&Giant); - printf("ether_poll_deregister: ifp not found!!!\n"); - return 0; - } - poll_handlers--; - if (i < poll_handlers) { /* Last entry replaces this one. */ - pr[i].handler = pr[poll_handlers].handler; - pr[i].ifp = pr[poll_handlers].ifp; - } - mtx_unlock(&Giant); - return 1; + mtx_lock(&poll_mtx); + LIST_FOREACH(pr, &poll_list, next) + if (pr->ifp == ifp && pr->handler != NULL) { + pr->handler = NULL; + poll_handlers--; + mtx_unlock(&poll_mtx); + ifp->if_flags &= ~IFF_POLLING; + return (1); + } + mtx_unlock(&poll_mtx); + log(LOG_DEBUG, "ether_poll_deregister: %s: not found!!!\n", + ifp->if_xname); + return (0); } static void @@ -495,10 +521,7 @@ for (;;) { if (poll_in_idle_loop && poll_handlers > 0) { idlepoll_sleeping = 0; - mtx_lock(&Giant); ether_poll(poll_each_burst); - mtx_unlock(&Giant); - mtx_assert(&Giant, MA_NOTOWNED); mtx_lock_spin(&sched_lock); mi_switch(SW_VOL, NULL); mtx_unlock_spin(&sched_lock); --X1bOJ3K7DJ5YkBrT-- From owner-freebsd-net@FreeBSD.ORG Fri Mar 11 11:19:43 2005 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 E566016A4CE for ; Fri, 11 Mar 2005 11:19:42 +0000 (GMT) Received: from r-dd.iij4u.or.jp (r-dd.iij4u.or.jp [210.130.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4195B43D53 for ; Fri, 11 Mar 2005 11:19:40 +0000 (GMT) (envelope-from demizu@dd.iij4u.or.jp) Received: from localhost (h076.p049.iij4u.or.jp [210.130.49.76]) by r-dd.iij4u.or.jp (8.11.6+IIJ/8.11.6) with ESMTP id j2BBJZ917920; Fri, 11 Mar 2005 20:19:36 +0900 (JST) Date: Fri, 11 Mar 2005 20:20:02 +0900 (JST) Message-Id: <20050311.202002.26516944.Noritoshi@Demizu.ORG> From: Noritoshi Demizu To: freebsd-net@freebsd.org In-Reply-To: <200503081411.j28EB0Hv001184@casselton.net> References: <20050308101633.GC26999@insomnia.benzedrine.cx> <200503081411.j28EB0Hv001184@casselton.net> X-Mailer: Mew version 4.1 on Emacs 21 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: FreeBSD 4.x and OS-X tcp 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: Fri, 11 Mar 2005 11:19:43 -0000 > The server is not telling the client that a packet has been lost. > The first two ACKs are correct duplicate ACKs, but the remaining > ACKs coming from he server have window adjustments, so the > client does not treat them as duplicate ACKs coming from a packet > loss. I made a list of ACKs with ack=4195629532. I added differences with their previous window sizes in parenthesises for each line. (See below) I guess if the difference < 2 * 1448, it would be an ACK sent in reply to an out-of-order data segment (i.e., it really is a dup ACK). Otherwise, it would be a pure window update. I added my guess for each line below. There are 12 dup ACKs, which is equal to the number of data segment beyond the lost packet. And there are 12 window updates. ack 4195629532 win 5792 (-) <- Original ACK ack 4195629532 win 6576 (+784) <- dup ACK (with window update) ack 4195629532 win 6576 (0) <- dup ACK ack 4195629532 win 7240 (+664) <- dup ACK (with window update) ack 4195629532 win 10672 (+3432) <- window update ack 4195629532 win 12720 (+2048) <- dup ACK (with window update) ack 4195629532 win 14768 (+2048) <- dup ACK (with window update) ack 4195629532 win 14768 (0) <- dup ACK ack 4195629532 win 16816 (+2048) <- dup ACK (with window update) ack 4195629532 win 18864 (+2048) <- dup ACK (with window update) ack 4195629532 win 18864 (0) <- dup ACK ack 4195629532 win 20912 (+2048) <- dup ACK (with window update) ack 4195629532 win 22960 (+2048) <- dup ACK (with window update) ack 4195629532 win 22960 (0) <- dup ACK ack 4195629532 win 26032 (+3072) <- window update ack 4195629532 win 29104 (+3072) <- window update ack 4195629532 win 32176 (+3072) <- window update ack 4195629532 win 35248 (+3072) <- window update ack 4195629532 win 38320 (+3072) <- window update ack 4195629532 win 41392 (+3072) <- window update ack 4195629532 win 44464 (+3072) <- window update ack 4195629532 win 47536 (+3072) <- window update ack 4195629532 win 50608 (+3072) <- window update ack 4195629532 win 53680 (+3072) <- window update ack 4195629532 win 56752 (+3072) <- window update There are four dup ACKs whose window field is the same as its previous ACK. If the sender counted them as dup ACKs, the sender was able to do FastRetransmit. But the sender did not. The reason would be that the sender might clear t_dupacks when receiving a window update. In FreeBSD current, line 1909 of tcp_input.c rev 1.268 does this. I am not sure it is a correct procedure. By the way, the receiver application seems to call read() with bufsize=1024. If the bufsize was larger than or equal to 2 * 1448, e.g., 4096, window updates would be sent independently from dup ACKs. Since the number of dup ACKs would be increased, the chance the receiver sends consecutive three dup ACKs might be increaced. Or if the receiver machine was replaced with a faster machine, the receiver application ran faster and the receive buffer would be always almost empty. In this case, the number of window updates would be decreased and the chance the receiver sends consecutive three dup ACKs would be increaced. These may improve the TCP performance in this particular case. Regards, Noritoshi Demizu ps. In tcpdump.osx-fbsd, I saw six retransmission timeouts. Retransmission timeout values are from 1 second to 1.5 seconds. They occupies almost all the total time of the transfer (8.6 seconds). Outstanding window seems less than 10 MSS, and in most cases, it is less than 6 MSS due to advertized window size. So, if Fast Retransmit worked, the TCP performance would be drastically improved in this particular case. From owner-freebsd-net@FreeBSD.ORG Fri Mar 11 13:55:27 2005 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 1D3BF16A4CE; Fri, 11 Mar 2005 13:55:27 +0000 (GMT) Received: from f22.mail.ru (f22.mail.ru [194.67.57.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8349043D1F; Fri, 11 Mar 2005 13:55:26 +0000 (GMT) (envelope-from _pppp@mail.ru) Received: from mail by f22.mail.ru with local id 1D9kbt-000FAj-00; Fri, 11 Mar 2005 16:55:25 +0300 Received: from [81.200.13.122] by win.mail.ru with HTTP; Fri, 11 Mar 2005 16:55:25 +0300 From: dima <_pppp@mail.ru> To: Gleb Smirnoff Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: [81.200.13.122] Date: Fri, 11 Mar 2005 16:55:25 +0300 In-Reply-To: <20050311110234.GA87255@cell.sick.ru> Content-Type: multipart/mixed; boundary="----T4Mc1hoV-B6SDJqxFbvhAdRDo:1110549325" Message-Id: cc: pjd@FreeBSD.org cc: John Baldwin cc: Luigi Rizzo cc: rwatson@FreeBSD.org cc: net@FreeBSD.org cc: ru@FreeBSD.org Subject: Re[2]: Giant-free polling [PATCH] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: dima <_pppp@mail.ru> List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2005 13:55:27 -0000 ------T4Mc1hoV-B6SDJqxFbvhAdRDo:1110549325 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit > Collegues, > > On Tue, Mar 01, 2005 at 04:29:49PM -0800, Luigi Rizzo wrote: > L> [cc-ing net@freebsd.org to get more opinions] > > this good, that you have CC'ed net@, otherwise we would continue > working in parallel without collaboration. It's a pity you didn't read the complete thread, thus the original version of my patch isn't valid anymore. > > Here is attached patch made in a collaboration by ru, pjd and me. I thought about using list also, but considered it to bring too much overhead to the code. The original idea of handling arrays seems to be very elegant. > > We use separate mutex for polling, and we drop it before calling the > poll handler to avoid LOR and contention on this mutex. The recent version of the patch uses sx lock to protect pr[] and the array of per-interface mutexes iface_locks[]. So, all CPUs can poll different interfaces at the same time now. See the complete thread for details. > > We have definite evidence that now idle_poll and ISR poll can run > in parallel: if we remove PRF_RUNNING flag check, we got panics > because poll handlers of many drivers (e.g. if_em) are not reentrable. > > I think this patch is a step forward in direction of parallel polling > on SMP, since we now have two polling instances (ISR + idle) working > in parallel. I also mentioned that poll_idle() isn't called from anywhere in the kernel. Thus we have only 2 possible sources for polling: hardclock (per-CPU) and traps. The polling code in trap handler should also be changed a bit to check for the trap's source. I attach the most recent version of the patch. The only difference is locking in ether_poll_register() suggested by Luigi. > > -- > Totus tuus, Glebius. > GLEBIUS-RIPN GLEB-RIPE ------T4Mc1hoV-B6SDJqxFbvhAdRDo:1110549325 Content-Type: application/octet-stream; name="kern_poll.patch" Content-Disposition: attachment; filename="kern_poll.patch" Content-Transfer-Encoding: base64 LS0tIG9yaWcva2Vybl9wb2xsLmMJVGh1IEZlYiAxNyAxNzoxMTowNSAyMDA1CisrKyBrZXJuX3Bv bGwuYwlGcmkgTWFyICA0IDE3OjAzOjMzIDIwMDUKQEAgLTQxLDEyICs0MSwxNyBAQAogI2luY2x1 ZGUgPHN5cy9yZXNvdXJjZXZhci5oPgogI2luY2x1ZGUgPHN5cy9rdGhyZWFkLmg+CiAKKyNpbmNs dWRlIDxzeXMvbG9jay5oPgkJCS8qIGZvciBzeCg5KQkJCSovCisjaW5jbHVkZSA8c3lzL3N4Lmg+ CisKICNpZmRlZiBTTVAKICNpZm5kZWYgQ09NUElMSU5HX0xJTlQKICNlcnJvciBERVZJQ0VfUE9M TElORyBpcyBub3QgY29tcGF0aWJsZSB3aXRoIFNNUAogI2VuZGlmCiAjZW5kaWYKIAorc3RydWN0 IHN4IHBvbGxpbmdfbG9jazsKKwogc3RhdGljIHZvaWQgbmV0aXNyX3BvbGwodm9pZCk7CQkvKiB0 aGUgdHdvIG5ldGlzciBoYW5kbGVycyAgICAgICovCiBzdGF0aWMgdm9pZCBuZXRpc3JfcG9sbG1v cmUodm9pZCk7CiAKQEAgLTE4Miw2ICsxODcsNyBAQAogfTsKIAogc3RhdGljIHN0cnVjdCBwb2xs cmVjIHByW1BPTExfTElTVF9MRU5dOworc3RydWN0IG10eCBpZmFjZV9sb2Nrc1tQT0xMX0xJU1Rf TEVOXTsKIAogc3RhdGljIHZvaWQKIGluaXRfZGV2aWNlX3BvbGwodm9pZCkKQEAgLTE4OSw2ICsx OTUsNyBAQAogCiAJbmV0aXNyX3JlZ2lzdGVyKE5FVElTUl9QT0xMLCAobmV0aXNyX3QgKiluZXRp c3JfcG9sbCwgTlVMTCwgMCk7CiAJbmV0aXNyX3JlZ2lzdGVyKE5FVElTUl9QT0xMTU9SRSwgKG5l dGlzcl90ICopbmV0aXNyX3BvbGxtb3JlLCBOVUxMLCAwKTsKKwlzeF9pbml0KCAmcG9sbGluZ19s b2NrLCAicG9sbGluZyIgKTsKIH0KIFNZU0lOSVQoZGV2aWNlX3BvbGwsIFNJX1NVQl9DTE9DS1Ms IFNJX09SREVSX01JRERMRSwgaW5pdF9kZXZpY2VfcG9sbCwgTlVMTCkKIApAQCAtMjUyLDE1ICsy NTksMTkgQEAKIHsKIAlpbnQgaTsKIAotCW10eF9sb2NrKCZHaWFudCk7CisJc3hfc2xvY2soICZw b2xsaW5nX2xvY2sgKTsKIAogCWlmIChjb3VudCA+IHBvbGxfZWFjaF9idXJzdCkKIAkJY291bnQg PSBwb2xsX2VhY2hfYnVyc3Q7CiAJZm9yIChpID0gMCA7IGkgPCBwb2xsX2hhbmRsZXJzIDsgaSsr KQotCQlpZiAocHJbaV0uaGFuZGxlciAmJiAoSUZGX1VQfElGRl9SVU5OSU5HKSA9PQotCQkgICAg KHByW2ldLmlmcC0+aWZfZmxhZ3MgJiAoSUZGX1VQfElGRl9SVU5OSU5HKSkgKQorCQlpZiggcHJb aV0uaGFuZGxlciAmJiAoIElGRl9VUCB8IElGRl9SVU5OSU5HICkgPT0KKwkJICAgICggcHJbaV0u aWZwLT5pZl9mbGFncyAmICggSUZGX1VQIHwgSUZGX1JVTk5JTkcgKSApICYmCisJCSAgICBtdHhf dHJ5bG9jayggJmlmYWNlX2xvY2tzW2ldICkgKSB7CiAJCQlwcltpXS5oYW5kbGVyKHByW2ldLmlm cCwgMCwgY291bnQpOyAvKiBxdWljayBjaGVjayAqLwotCW10eF91bmxvY2soJkdpYW50KTsKKwkJ CW10eF91bmxvY2soICZpZmFjZV9sb2Nrc1tpXSApOworCQl9CisKKwlzeF9zdW5sb2NrKCAmcG9s bGluZ19sb2NrICk7CiB9CiAKIC8qCkBAIC0zMzUsNyArMzQ2LDYgQEAKIAlzdGF0aWMgaW50IHJl Z19mcmFjX2NvdW50OwogCWludCBpLCBjeWNsZXM7CiAJZW51bSBwb2xsX2NtZCBhcmcgPSBQT0xM X09OTFk7Ci0JbXR4X2xvY2soJkdpYW50KTsKIAogCXBoYXNlID0gMzsKIAlpZiAocmVzaWR1YWxf YnVyc3QgPT0gMCkgeyAvKiBmaXJzdCBjYWxsIGluIHRoaXMgdGljayAqLwpAQCAtMzc3LDI2ICsz ODcsMzcgQEAKIAkJcmVzaWR1YWxfYnVyc3QgOiBwb2xsX2VhY2hfYnVyc3Q7CiAJcmVzaWR1YWxf YnVyc3QgLT0gY3ljbGVzOwogCisJc3hfc2xvY2soICZwb2xsaW5nX2xvY2sgKTsKKwogCWlmIChw b2xsaW5nKSB7CiAJCWZvciAoaSA9IDAgOyBpIDwgcG9sbF9oYW5kbGVycyA7IGkrKykKLQkJCWlm IChwcltpXS5oYW5kbGVyICYmIChJRkZfVVB8SUZGX1JVTk5JTkcpID09Ci0JCQkgICAgKHByW2ld LmlmcC0+aWZfZmxhZ3MgJiAoSUZGX1VQfElGRl9SVU5OSU5HKSkgKQorCQkJaWYoIHByW2ldLmhh bmRsZXIgJiYKKwkJCSAgICAoIElGRl9VUCB8IElGRl9SVU5OSU5HICkgPT0KKwkJCSAgICAoIHBy W2ldLmlmcC0+aWZfZmxhZ3MgJiAoSUZGX1VQIHwgSUZGX1JVTk5JTkcpICkgJiYKKwkJCSAgICBt dHhfdHJ5bG9jayggJmlmYWNlX2xvY2tzW2ldICkgKSB7CiAJCQkJcHJbaV0uaGFuZGxlcihwcltp XS5pZnAsIGFyZywgY3ljbGVzKTsKKwkJCQltdHhfdW5sb2NrKCAmaWZhY2VfbG9ja3NbaV0gKTsK KwkJCX0KIAl9IGVsc2UgewkvKiB1bnJlZ2lzdGVyICovCiAJCWZvciAoaSA9IDAgOyBpIDwgcG9s bF9oYW5kbGVycyA7IGkrKykgewotCQkJaWYgKHByW2ldLmhhbmRsZXIgJiYKLQkJCSAgICBwcltp XS5pZnAtPmlmX2ZsYWdzICYgSUZGX1JVTk5JTkcpIHsKKwkJCWlmKCBwcltpXS5oYW5kbGVyICYm CisJCQkgICAgcHJbaV0uaWZwLT5pZl9mbGFncyAmIElGRl9SVU5OSU5HICYmCisJCQkgICAgbXR4 X3RyeWxvY2soICZpZmFjZV9sb2Nrc1tpXSApICkgewogCQkJCXByW2ldLmlmcC0+aWZfZmxhZ3Mg Jj0gfklGRl9QT0xMSU5HOwogCQkJCXByW2ldLmhhbmRsZXIocHJbaV0uaWZwLCBQT0xMX0RFUkVH SVNURVIsIDEpOworCQkJCW10eF91bmxvY2soICZpZmFjZV9sb2Nrc1tpXSApOworCQkJCW10eF9k ZXN0cm95KCAmaWZhY2VfbG9ja3NbaV0gKTsKIAkJCX0KIAkJCXByW2ldLmhhbmRsZXI9TlVMTDsK IAkJfQogCQlyZXNpZHVhbF9idXJzdCA9IDA7CiAJCXBvbGxfaGFuZGxlcnMgPSAwOwogCX0KKwor CXN4X3N1bmxvY2soICZwb2xsaW5nX2xvY2sgKTsKKwogCS8qIG9uIC1zdGFibGUsIHNjaGVkbmV0 aXNyKE5FVElTUl9QT0xMTU9SRSk7ICovCiAJcGhhc2UgPSA0OwotCW10eF91bmxvY2soJkdpYW50 KTsKIH0KIAogLyoKQEAgLTQ0MCw5ICs0NjEsMTUgQEAKIAkJcmV0dXJuIDA7IC8qIG5vIHBvbGxp bmcgZm9yIHlvdSAqLwogCX0KIAorCXN4X3hsb2NrKCAmcG9sbGluZ19sb2NrICk7CisKIAlwcltw b2xsX2hhbmRsZXJzXS5oYW5kbGVyID0gaDsKIAlwcltwb2xsX2hhbmRsZXJzXS5pZnAgPSBpZnA7 CisJbXR4X2luaXQoICZpZmFjZV9sb2Nrc1twb2xsX2hhbmRsZXJzXSwgaWZwLT5pZl94bmFtZSwg TlVMTCwgTVRYX0RFRiApOwogCXBvbGxfaGFuZGxlcnMrKzsKKworCXN4X3h1bmxvY2soICZwb2xs aW5nX2xvY2sgKTsKKwogCWlmcC0+aWZfZmxhZ3MgfD0gSUZGX1BPTExJTkc7CiAJc3BseChzKTsK IAlpZiAoaWRsZXBvbGxfc2xlZXBpbmcpCkBAIC00NjEsMTcgKzQ4OCwxOSBAQAogewogCWludCBp OwogCi0JbXR4X2xvY2soJkdpYW50KTsKKwogCWlmICggIWlmcCB8fCAhKGlmcC0+aWZfZmxhZ3Mg JiBJRkZfUE9MTElORykgKSB7Ci0JCW10eF91bmxvY2soJkdpYW50KTsKIAkJcmV0dXJuIDA7CiAJ fQorCisJc3hfeGxvY2soICZwb2xsaW5nX2xvY2sgKTsKKwogCWZvciAoaSA9IDAgOyBpIDwgcG9s bF9oYW5kbGVycyA7IGkrKykKIAkJaWYgKHByW2ldLmlmcCA9PSBpZnApIC8qIGZvdW5kIGl0ICov CiAJCQlicmVhazsKIAlpZnAtPmlmX2ZsYWdzICY9IH5JRkZfUE9MTElORzsgLyogZm91bmQgb3Ig bm90Li4uICovCiAJaWYgKGkgPT0gcG9sbF9oYW5kbGVycykgewotCQltdHhfdW5sb2NrKCZHaWFu dCk7CisJCXN4X3h1bmxvY2soICZwb2xsaW5nX2xvY2sgKTsKIAkJcHJpbnRmKCJldGhlcl9wb2xs X2RlcmVnaXN0ZXI6IGlmcCBub3QgZm91bmQhISFcbiIpOwogCQlyZXR1cm4gMDsKIAl9CkBAIC00 NzksOCArNTA4LDEwIEBACiAJaWYgKGkgPCBwb2xsX2hhbmRsZXJzKSB7IC8qIExhc3QgZW50cnkg cmVwbGFjZXMgdGhpcyBvbmUuICovCiAJCXByW2ldLmhhbmRsZXIgPSBwcltwb2xsX2hhbmRsZXJz XS5oYW5kbGVyOwogCQlwcltpXS5pZnAgPSBwcltwb2xsX2hhbmRsZXJzXS5pZnA7CisJCW10eF9k ZXN0cm95KCAmaWZhY2VfbG9ja3NbaV0gKTsKKwkJaWZhY2VfbG9ja3NbaV0gPSBpZmFjZV9sb2Nr c1twb2xsX2hhbmRsZXJzXTsKIAl9Ci0JbXR4X3VubG9jaygmR2lhbnQpOworCXN4X3h1bmxvY2so ICZwb2xsaW5nX2xvY2sgKTsKIAlyZXR1cm4gMTsKIH0KIApAQCAtNTAxLDEwICs1MzIsMTAgQEAK IAlmb3IgKDs7KSB7CiAJCWlmIChwb2xsX2luX2lkbGVfbG9vcCAmJiBwb2xsX2hhbmRsZXJzID4g MCkgewogCQkJaWRsZXBvbGxfc2xlZXBpbmcgPSAwOwotCQkJbXR4X2xvY2soJkdpYW50KTsKKwkJ CS8qIG10eF9sb2NrKCZHaWFudCk7ICovCiAJCQlldGhlcl9wb2xsKHBvbGxfZWFjaF9idXJzdCk7 Ci0JCQltdHhfdW5sb2NrKCZHaWFudCk7Ci0JCQltdHhfYXNzZXJ0KCZHaWFudCwgTUFfTk9UT1dO RUQpOworCQkJLyogbXR4X3VubG9jaygmR2lhbnQpOworCQkJbXR4X2Fzc2VydCgmR2lhbnQsIE1B X05PVE9XTkVEKTsgKi8KIAkJCW10eF9sb2NrX3NwaW4oJnNjaGVkX2xvY2spOwogCQkJbWlfc3dp dGNoKFNXX1ZPTCwgTlVMTCk7CiAJCQltdHhfdW5sb2NrX3NwaW4oJnNjaGVkX2xvY2spOwo= ------T4Mc1hoV-B6SDJqxFbvhAdRDo:1110549325-- From owner-freebsd-net@FreeBSD.ORG Fri Mar 11 14:09:27 2005 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 8BED616A4CE; Fri, 11 Mar 2005 14:09:27 +0000 (GMT) Received: from relay.bestcom.ru (relay.bestcom.ru [217.72.144.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE66B43D53; Fri, 11 Mar 2005 14:09:26 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (root@cell.sick.ru [217.72.144.68]) by relay.bestcom.ru (8.13.1/8.12.9) with ESMTP id j2BE9Otd089256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 11 Mar 2005 17:09:24 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.1/8.12.8) with ESMTP id j2BE9N9s088849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Mar 2005 17:09:23 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.1/8.13.1/Submit) id j2BE9NSB088848; Fri, 11 Mar 2005 17:09:23 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 11 Mar 2005 17:09:22 +0300 From: Gleb Smirnoff To: dima <_pppp@mail.ru> Message-ID: <20050311140922.GA88801@cell.sick.ru> References: <20050311110234.GA87255@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV version devel-20050125, clamav-milter version 0.80ff on relay.bestcom.ru X-Virus-Status: Clean cc: pjd@FreeBSD.org cc: John Baldwin cc: Luigi Rizzo cc: rwatson@FreeBSD.org cc: net@FreeBSD.org cc: ru@FreeBSD.org Subject: Re: Giant-free polling [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: Fri, 11 Mar 2005 14:09:27 -0000 On Fri, Mar 11, 2005 at 04:55:25PM +0300, dima wrote: d> I also mentioned that poll_idle() isn't called from anywhere in the kernel. d> Thus we have only 2 possible sources for polling: hardclock (per-CPU) and traps. poll_idle is a process created on startup, so it is not called from anywhere. But it is source of polling. P.S. More comments later. Thanks! -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Fri Mar 11 14:15:06 2005 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 0B79216A4D8; Fri, 11 Mar 2005 14:15:06 +0000 (GMT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.136]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1762643D4C; Fri, 11 Mar 2005 14:15:05 +0000 (GMT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id 4B292ACB34; Fri, 11 Mar 2005 15:14:50 +0100 (CET) Date: Fri, 11 Mar 2005 15:14:50 +0100 From: Pawel Jakub Dawidek To: dima <_pppp@mail.ru> Message-ID: <20050311141450.GF9291@darkness.comp.waw.pl> References: <20050311110234.GA87255@cell.sick.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LoV0Wh4nEaYAWgxX" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 5.2.1-RC2 i386 cc: John Baldwin cc: Luigi Rizzo cc: Gleb Smirnoff cc: ru@FreeBSD.org cc: net@FreeBSD.org cc: rwatson@FreeBSD.org Subject: Re: Giant-free polling [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: Fri, 11 Mar 2005 14:15:06 -0000 --LoV0Wh4nEaYAWgxX Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 11, 2005 at 04:55:25PM +0300, dima wrote: +> I thought about using list also, but considered it to bring +> too much overhead to the code. The original idea of handling arrays +> seems to be very elegant. Overhead? Did you run any benchmarks to prove it? I find list-version much more elegant that using an array. I also don't like the idea of calling handler method with two locks held (one sx and one mutex)... There is still an unresolved problem (in your and our patch as well) of using ifnet structure fields without synchronization, as we don't have access tointerface's internal mutex, which protects those fields. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --LoV0Wh4nEaYAWgxX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFCMafaForvXbEpPzQRAl+dAJ9AdTHF9ql8GoUOC5mNaUEuElND0gCgiMd1 t2kYhRWBlXV1c7b8IcoeAi4= =ndjc -----END PGP SIGNATURE----- --LoV0Wh4nEaYAWgxX-- From owner-freebsd-net@FreeBSD.ORG Fri Mar 11 14:28:13 2005 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 396AB16A4D0; Fri, 11 Mar 2005 14:28:13 +0000 (GMT) Received: from relay.bestcom.ru (relay.bestcom.ru [217.72.144.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D2FD43D5A; Fri, 11 Mar 2005 14:28:12 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (root@cell.sick.ru [217.72.144.68]) by relay.bestcom.ru (8.13.1/8.12.9) with ESMTP id j2BES76J089634 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 11 Mar 2005 17:28:07 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.1/8.12.8) with ESMTP id j2BES5Dw089079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Mar 2005 17:28:06 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.1/8.13.1/Submit) id j2BES5gh089078; Fri, 11 Mar 2005 17:28:05 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 11 Mar 2005 17:28:05 +0300 From: Gleb Smirnoff To: Pawel Jakub Dawidek Message-ID: <20050311142805.GB88801@cell.sick.ru> References: <20050311110234.GA87255@cell.sick.ru> <20050311141450.GF9291@darkness.comp.waw.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20050311141450.GF9291@darkness.comp.waw.pl> User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV version devel-20050125, clamav-milter version 0.80ff on relay.bestcom.ru X-Virus-Status: Clean cc: dima <_pppp@mail.ru> cc: John Baldwin cc: Luigi Rizzo cc: rwatson@FreeBSD.org cc: net@FreeBSD.org cc: ru@FreeBSD.org Subject: Re: Giant-free polling [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: Fri, 11 Mar 2005 14:28:13 -0000 On Fri, Mar 11, 2005 at 03:14:50PM +0100, Pawel Jakub Dawidek wrote: P> On Fri, Mar 11, 2005 at 04:55:25PM +0300, dima wrote: P> +> I thought about using list also, but considered it to bring P> +> too much overhead to the code. The original idea of handling arrays P> +> seems to be very elegant. P> P> Overhead? Did you run any benchmarks to prove it? P> I find list-version much more elegant that using an array. It is also a small cookie for future. Now we have IFF_POLLING flag and IFCAP_POLLING, which indicate whether interface support polling and whether it actually does polling. This is not nice, from my viewpoint. I'd like to see only IFCAP_POLLING present and turning polling on/off for particular interface should be done by inserting/removing iface from polling list. This will also remove an extra unlocked check of interface flags (?). P> I also don't like the idea of calling handler method with two locks P> held (one sx and one mutex)... I agree with Pawel. We have LOR here between sx lock and driver lock: normal polling: (get sx shared) -> (get driver mutex) driver stop: (get driver mutex) -> (get sx exclusive) We will have deadlock if this two things process in parallel. And the per-interface mutex protects only reentrancy of interface poll method, is that right? P> There is still an unresolved problem (in your and our patch as well) of P> using ifnet structure fields without synchronization, as we don't have P> access tointerface's internal mutex, which protects those fields. This is unresolved in our patch, too, and I believe throughout many other places in kernel. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Fri Mar 11 14:31:18 2005 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 7B4F116A4DF; Fri, 11 Mar 2005 14:31:18 +0000 (GMT) Received: from f7.mail.ru (f7.mail.ru [194.67.57.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2F1C43D58; Fri, 11 Mar 2005 14:31:17 +0000 (GMT) (envelope-from _pppp@mail.ru) Received: from mail by f7.mail.ru with local id 1D9lAa-000FJD-00; Fri, 11 Mar 2005 17:31:16 +0300 Received: from [81.200.13.122] by win.mail.ru with HTTP; Fri, 11 Mar 2005 17:31:16 +0300 From: dima <_pppp@mail.ru> To: Pawel Jakub Dawidek Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: [81.200.13.122] Date: Fri, 11 Mar 2005 17:31:16 +0300 In-Reply-To: <20050311141450.GF9291@darkness.comp.waw.pl> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Message-Id: cc: John Baldwin cc: Luigi Rizzo cc: Gleb Smirnoff cc: ru@FreeBSD.org cc: net@FreeBSD.org cc: rwatson@FreeBSD.org Subject: Re[2]: Giant-free polling [PATCH] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: dima <_pppp@mail.ru> List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2005 14:31:18 -0000 > On Fri, Mar 11, 2005 at 04:55:25PM +0300, dima wrote: > +> I thought about using list also, but considered it to bring > +> too much overhead to the code. The original idea of handling arrays > +> seems to be very elegant. > > Overhead? Did you run any benchmarks to prove it? > I find list-version much more elegant that using an array. It was an assumption in fact. So, I didn't try to implement a list-based version. We should merge our efforts anyway and both versions should naturally be tested and benchmarked. > > I also don't like the idea of calling handler method with two locks > held (one sx and one mutex)... This gives the highest possible granularity though... > > There is still an unresolved problem (in your and our patch as well) of > using ifnet structure fields without synchronization, as we don't have > access tointerface's internal mutex, which protects those fields. I guess iface_locks[] should be removed then. We actually can get the interface's internal mutex as ifp->ifq_mtx; I will think about that on weekend. > > -- > Pawel Jakub Dawidek http://www.wheel.pl > pjd@FreeBSD.org http://www.FreeBSD.org > FreeBSD committer Am I Evil? Yes, I Am! > > ATTACHMENT: application/pgp-signature > From owner-freebsd-net@FreeBSD.ORG Fri Mar 11 14:48:52 2005 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 2F94616A4CE; Fri, 11 Mar 2005 14:48:52 +0000 (GMT) Received: from relay.bestcom.ru (relay.bestcom.ru [217.72.144.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 49BBA43D48; Fri, 11 Mar 2005 14:48:51 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (root@cell.sick.ru [217.72.144.68]) by relay.bestcom.ru (8.13.1/8.12.9) with ESMTP id j2BEmnci090050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 11 Mar 2005 17:48:50 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.1/8.12.8) with ESMTP id j2BEmmcG089386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Mar 2005 17:48:49 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.1/8.13.1/Submit) id j2BEmmck089385; Fri, 11 Mar 2005 17:48:48 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 11 Mar 2005 17:48:48 +0300 From: Gleb Smirnoff To: dima <_pppp@mail.ru> Message-ID: <20050311144848.GC88801@cell.sick.ru> References: <20050311141450.GF9291@darkness.comp.waw.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV version devel-20050125, clamav-milter version 0.80ff on relay.bestcom.ru X-Virus-Status: Clean cc: Pawel Jakub Dawidek cc: John Baldwin cc: Luigi Rizzo cc: ru@FreeBSD.org cc: net@FreeBSD.org cc: rwatson@FreeBSD.org Subject: Re: Giant-free polling [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: Fri, 11 Mar 2005 14:48:52 -0000 On Fri, Mar 11, 2005 at 05:31:16PM +0300, dima wrote: d> We should merge our efforts anyway and both versions d> should naturally be tested and benchmarked. Yes, I'll benchmark both patches in next 3-4 days. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Fri Mar 11 14:59:44 2005 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 BEC1816A4CE for ; Fri, 11 Mar 2005 14:59:44 +0000 (GMT) Received: from casselton.net (casselton.net [63.165.140.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 41A1943D58 for ; Fri, 11 Mar 2005 14:59:44 +0000 (GMT) (envelope-from tinguely@casselton.net) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.12.11/8.12.11) with ESMTP id j2BExeBW087526; Fri, 11 Mar 2005 08:59:40 -0600 (CST) (envelope-from tinguely@casselton.net) Received: (from tinguely@localhost) by casselton.net (8.12.11/8.12.11/Submit) id j2BExesE087525; Fri, 11 Mar 2005 08:59:40 -0600 (CST) (envelope-from tinguely) Date: Fri, 11 Mar 2005 08:59:40 -0600 (CST) From: Mark Tinguely Message-Id: <200503111459.j2BExesE087525@casselton.net> To: demizu@dd.iij4u.or.jp, freebsd-net@freebsd.org In-Reply-To: <20050311.202002.26516944.Noritoshi@Demizu.ORG> X-Spam-Status: No, score=1.4 required=5.0 tests=REPLY_TO_EMPTY autolearn=no version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on ccn.casselton.net Subject: Re: FreeBSD 4.x and OS-X tcp 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: Fri, 11 Mar 2005 14:59:44 -0000 on Fri, 11 Mar 2005 20:20:02 +0900 (JST), Noritoshi Demizu said: > ack 4195629532 win 5792 (-) <- Original ACK > ack 4195629532 win 6576 (+784) <- dup ACK (with window update) > ack 4195629532 win 6576 (0) <- dup ACK > ack 4195629532 win 7240 (+664) <- dup ACK (with window update) > ack 4195629532 win 10672 (+3432) <- window update The Apple machine may be rate limiting their transmissions. The Apple is sending only 2 packets per round trip time. After the packet is lost, that gap allows the FreeBSD to consume some data before sending the 3rd duplicate ACKs and so it has a window changes. --Mark. From owner-freebsd-net@FreeBSD.ORG Fri Mar 11 15:44:53 2005 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 E488416A4CE; Fri, 11 Mar 2005 15:44:52 +0000 (GMT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 66E3C43D5A; Fri, 11 Mar 2005 15:44:52 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.8) with ESMTP id j2BFinVU070807; Fri, 11 Mar 2005 07:44:49 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id j2BFinO2070806; Fri, 11 Mar 2005 07:44:49 -0800 (PST) (envelope-from rizzo) Date: Fri, 11 Mar 2005 07:44:48 -0800 From: Luigi Rizzo To: Gleb Smirnoff Message-ID: <20050311074448.A70328@xorpc.icir.org> References: <200503011642.48813.jhb@FreeBSD.org> <20050301162949.A64187@xorpc.icir.org> <20050311110234.GA87255@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20050311110234.GA87255@cell.sick.ru>; from glebius@freebsd.org on Fri, Mar 11, 2005 at 02:02:34PM +0300 cc: dima <_pppp@mail.ru> cc: pjd@freebsd.org cc: John Baldwin cc: rwatson@freebsd.org cc: net@freebsd.org Subject: Re: Giant-free polling [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: Fri, 11 Mar 2005 15:44:53 -0000 while i am happy to see interest on having this supported, and while I understand the excitement in firing the editor and writing code, i don't think this approach of hacking up some patch that allows multiple poll* instances to run without panicing the box, or discussing the performance of lists vs arrays vs IFF_* flags will lead to anything. As I asked this already, consider this msg a rant, for archival purposes, calling for a sane approach to the problem. Polling in the UP case is beneficial because it has some features listed e.g. in http://docs.freebsd.org/cgi/getmsg.cgi?fetch=128950+0+/usr/local/www/db/text/2005/freebsd-net/20050306.freebsd-net For the SMP case there are the basic issues to handle (proper locking, preventing deadlocks) but also performance issues e.g. to avoid that multiple polling instances just fight for the lock but do nothing useful, see e.g. the case described in http://docs.freebsd.org/cgi/getmsg.cgi?fetch=71980+0+/usr/local/www/db/text/2005/freebsd-net/20050306.freebsd-net Now, if you want to approach the issue seriously, you need to: 1) _design_ a locking strategy for SMP polling -- design meaning provide a description in english, even a sketchy one, which will eventually end up in a manpage such as polling(4), or in the source file as a comment. Certainly a design is not C code or patches without comments from which one should figure out the overall picture. 2) evaluate how the design compares in terms of features (e.g. those listed in the first reference above) to the UP case. I am not saying one should implement all of them, but at least it must be clear how the two things are different, if they are. 3) evaluate how the design addresses (in terms of performance) the contention problems, of which the second reference above is probably just one but at least a very obvious one; 4) implement it -- and if you want it to be reviewed, please post the full code, not just differences -- the code will be terribly different to be human readable in terms of a diff; 5) optimise it -- e.g. deal with arrays vs lists, implicit vs explicit flags, etc. It seems to me that this whole discussion is proceding from step 4 and ignoring the first 3 steps. Please, step back from your keyboards and move to the whiteboard, if nothing else to prove me that you have already addressed all the issues. cheers luigi On Fri, Mar 11, 2005 at 02:02:34PM +0300, Gleb Smirnoff wrote: > Collegues, > > On Tue, Mar 01, 2005 at 04:29:49PM -0800, Luigi Rizzo wrote: > L> [cc-ing net@freebsd.org to get more opinions] > > this good, that you have CC'ed net@, otherwise we would continue > working in parallel without collaboration. > > Here is attached patch made in a collaboration by ru, pjd and me. > > We use separate mutex for polling, and we drop it before calling the > poll handler to avoid LOR and contention on this mutex. > > We have definite evidence that now idle_poll and ISR poll can run > in parallel: if we remove PRF_RUNNING flag check, we got panics > because poll handlers of many drivers (e.g. if_em) are not reentrable. > > I think this patch is a step forward in direction of parallel polling > on SMP, since we now have two polling instances (ISR + idle) working > in parallel. > > -- > Totus tuus, Glebius. > GLEBIUS-RIPN GLEB-RIPE > Index: kern_poll.c > =================================================================== > RCS file: /home/ncvs/src/sys/kern/kern_poll.c,v > retrieving revision 1.19 > diff -u -r1.19 kern_poll.c > --- kern_poll.c 25 Feb 2005 22:07:50 -0000 1.19 > +++ kern_poll.c 11 Mar 2005 10:49:47 -0000 > @@ -33,6 +33,7 @@ > #include > #include /* needed by net/if.h */ > #include > +#include > > #include /* for IFF_* flags */ > #include /* for NETISR_POLL */ > @@ -144,7 +145,7 @@ > SYSCTL_INT(_kern_polling, OID_AUTO, residual_burst, CTLFLAG_RW, > &residual_burst, 0, "# of residual cycles in burst"); > > -static u_int32_t poll_handlers; /* next free entry in pr[]. */ > +static u_int32_t poll_handlers; > SYSCTL_UINT(_kern_polling, OID_AUTO, handlers, CTLFLAG_RD, > &poll_handlers, 0, "Number of registered poll handlers"); > > @@ -169,20 +170,33 @@ > &idlepoll_sleeping, 0, "idlepoll is sleeping"); > > > -#define POLL_LIST_LEN 128 > struct pollrec { > poll_handler_t *handler; > struct ifnet *ifp; > +#define PRF_RUNNING 0x1 > +#define PRF_PINNED 0x2 > + uint32_t flags; > + LIST_ENTRY(pollrec) next; > }; > > -static struct pollrec pr[POLL_LIST_LEN]; > +#define PR_VALID(pr) ((pr)->handler != NULL && \ > + !((pr)->flags & PRF_RUNNING) && \ > + ((pr)->ifp->if_flags & (IFF_UP|IFF_RUNNING)) == \ > + (IFF_UP|IFF_RUNNING)) > + > +static LIST_HEAD(, pollrec) poll_list = LIST_HEAD_INITIALIZER(&poll_list); > + > +static struct mtx poll_mtx; > > static void > init_device_poll(void) > { > > - netisr_register(NETISR_POLL, (netisr_t *)netisr_poll, NULL, 0); > - netisr_register(NETISR_POLLMORE, (netisr_t *)netisr_pollmore, NULL, 0); > + mtx_init(&poll_mtx, "polling", NULL, MTX_DEF); > + netisr_register(NETISR_POLL, (netisr_t *)netisr_poll, NULL, > + NETISR_MPSAFE); > + netisr_register(NETISR_POLLMORE, (netisr_t *)netisr_pollmore, NULL, > + NETISR_MPSAFE); > } > SYSINIT(device_poll, SI_SUB_CLOCKS, SI_ORDER_MIDDLE, init_device_poll, NULL) > > @@ -244,17 +258,26 @@ > void > ether_poll(int count) > { > - int i; > - > - mtx_lock(&Giant); > + struct pollrec *pr, *pr1; > > if (count > poll_each_burst) > count = poll_each_burst; > - for (i = 0 ; i < poll_handlers ; i++) > - if (pr[i].handler && (IFF_UP|IFF_RUNNING) == > - (pr[i].ifp->if_flags & (IFF_UP|IFF_RUNNING)) ) > - pr[i].handler(pr[i].ifp, 0, count); /* quick check */ > - mtx_unlock(&Giant); > + > + mtx_lock(&poll_mtx); > + LIST_FOREACH_SAFE(pr, &poll_list, next, pr1) { > + if (PR_VALID(pr)) { > + pr->flags |= PRF_RUNNING; > + if (pr1 != NULL) > + pr1->flags |= PRF_PINNED; > + mtx_unlock(&poll_mtx); > + pr->handler(pr->ifp, 0, count); > + mtx_lock(&poll_mtx); > + if (pr1 != NULL) > + pr1->flags &= ~PRF_PINNED; > + pr->flags &= ~PRF_RUNNING; > + } > + } > + mtx_unlock(&poll_mtx); > } > > /* > @@ -320,17 +343,17 @@ > > /* > * netisr_poll is scheduled by schednetisr when appropriate, typically once > - * per tick. It is called at splnet() so first thing to do is to upgrade to > - * splimp(), and call all registered handlers. > + * per tick. > */ > static void > netisr_poll(void) > { > + struct pollrec *pr, *pr1; > static int reg_frac_count; > - int i, cycles; > + int cycles; > enum poll_cmd arg = POLL_ONLY; > - mtx_lock(&Giant); > > + mtx_lock(&poll_mtx); > phase = 3; > if (residual_burst == 0) { /* first call in this tick */ > microuptime(&poll_start_t); > @@ -372,25 +395,36 @@ > residual_burst -= cycles; > > if (polling) { > - for (i = 0 ; i < poll_handlers ; i++) > - if (pr[i].handler && (IFF_UP|IFF_RUNNING) == > - (pr[i].ifp->if_flags & (IFF_UP|IFF_RUNNING)) ) > - pr[i].handler(pr[i].ifp, arg, cycles); > + LIST_FOREACH_SAFE(pr, &poll_list, next, pr1) { > + if (PR_VALID(pr)) { > + pr->flags |= PRF_RUNNING; > + mtx_unlock(&poll_mtx); > + pr->handler(pr->ifp, arg, cycles); > + mtx_lock(&poll_mtx); > + pr->flags &= ~PRF_RUNNING; > + } else if (pr->handler == NULL && > + !(pr->flags & PRF_PINNED)) { > + LIST_REMOVE(pr, next); > + free(pr, M_TEMP); > + } > + } > } else { /* unregister */ > - for (i = 0 ; i < poll_handlers ; i++) { > - if (pr[i].handler && > - pr[i].ifp->if_flags & IFF_RUNNING) { > - pr[i].ifp->if_flags &= ~IFF_POLLING; > - pr[i].handler(pr[i].ifp, POLL_DEREGISTER, 1); > + LIST_FOREACH_SAFE(pr, &poll_list, next, pr1) { > + if (pr->handler != NULL && > + pr->ifp->if_flags & IFF_RUNNING) { > + pr->ifp->if_flags &= ~IFF_POLLING; > + mtx_unlock(&poll_mtx); > + pr->handler(pr->ifp, POLL_DEREGISTER, 1); > + mtx_lock(&poll_mtx); > } > - pr[i].handler=NULL; > + pr->handler = NULL; > } > residual_burst = 0; > poll_handlers = 0; > } > /* on -stable, schednetisr(NETISR_POLLMORE); */ > phase = 4; > - mtx_unlock(&Giant); > + mtx_unlock(&poll_mtx); > } > > /* > @@ -399,12 +433,12 @@ > * A device is not supposed to register itself multiple times. > * > * This is called from within the *_intr() functions, so we do not need > - * further locking. > + * further ifnet locking. > */ > int > ether_poll_register(poll_handler_t *h, struct ifnet *ifp) > { > - int s; > + struct pollrec *pr; > > if (polling == 0) /* polling disabled, cannot register */ > return 0; > @@ -415,30 +449,27 @@ > if (ifp->if_flags & IFF_POLLING) /* already polling */ > return 0; > > - s = splhigh(); > - if (poll_handlers >= POLL_LIST_LEN) { > - /* > - * List full, cannot register more entries. > - * This should never happen; if it does, it is probably a > - * broken driver trying to register multiple times. Checking > - * this at runtime is expensive, and won't solve the problem > - * anyways, so just report a few times and then give up. > - */ > - static int verbose = 10 ; > - splx(s); > - if (verbose >0) { > - printf("poll handlers list full, " > - "maybe a broken driver ?\n"); > - verbose--; > + mtx_lock(&poll_mtx); > + LIST_FOREACH(pr, &poll_list, next) > + if (pr->ifp == ifp && pr->handler != NULL) { > + mtx_unlock(&poll_mtx); > + log(LOG_DEBUG, "ether_poll_register: %s: handler" > + " already registered\n", ifp->if_xname); > + return (0); > } > - return 0; /* no polling for you */ > + pr = malloc(sizeof(*pr), M_TEMP, M_NOWAIT); > + if (pr == NULL) { > + mtx_unlock(&poll_mtx); > + log(LOG_DEBUG, "ether_poll_register: malloc() failed\n"); > + return (0); > } > > - pr[poll_handlers].handler = h; > - pr[poll_handlers].ifp = ifp; > + pr->handler = h; > + pr->ifp = ifp; > + LIST_INSERT_HEAD(&poll_list, pr, next); > poll_handlers++; > ifp->if_flags |= IFF_POLLING; > - splx(s); > + mtx_unlock(&poll_mtx); > if (idlepoll_sleeping) > wakeup(&idlepoll_sleeping); > return 1; /* polling enabled in next call */ > @@ -453,29 +484,24 @@ > int > ether_poll_deregister(struct ifnet *ifp) > { > - int i; > + struct pollrec *pr; > > - mtx_lock(&Giant); > if ( !ifp || !(ifp->if_flags & IFF_POLLING) ) { > - mtx_unlock(&Giant); > return 0; > } > - for (i = 0 ; i < poll_handlers ; i++) > - if (pr[i].ifp == ifp) /* found it */ > - break; > - ifp->if_flags &= ~IFF_POLLING; /* found or not... */ > - if (i == poll_handlers) { > - mtx_unlock(&Giant); > - printf("ether_poll_deregister: ifp not found!!!\n"); > - return 0; > - } > - poll_handlers--; > - if (i < poll_handlers) { /* Last entry replaces this one. */ > - pr[i].handler = pr[poll_handlers].handler; > - pr[i].ifp = pr[poll_handlers].ifp; > - } > - mtx_unlock(&Giant); > - return 1; > + mtx_lock(&poll_mtx); > + LIST_FOREACH(pr, &poll_list, next) > + if (pr->ifp == ifp && pr->handler != NULL) { > + pr->handler = NULL; > + poll_handlers--; > + mtx_unlock(&poll_mtx); > + ifp->if_flags &= ~IFF_POLLING; > + return (1); > + } > + mtx_unlock(&poll_mtx); > + log(LOG_DEBUG, "ether_poll_deregister: %s: not found!!!\n", > + ifp->if_xname); > + return (0); > } > > static void > @@ -495,10 +521,7 @@ > for (;;) { > if (poll_in_idle_loop && poll_handlers > 0) { > idlepoll_sleeping = 0; > - mtx_lock(&Giant); > ether_poll(poll_each_burst); > - mtx_unlock(&Giant); > - mtx_assert(&Giant, MA_NOTOWNED); > mtx_lock_spin(&sched_lock); > mi_switch(SW_VOL, NULL); > mtx_unlock_spin(&sched_lock); > _______________________________________________ > 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 Fri Mar 11 16:13:40 2005 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 DC6F216A4CE for ; Fri, 11 Mar 2005 16:13:40 +0000 (GMT) Received: from r-dd.iij4u.or.jp (r-dd.iij4u.or.jp [210.130.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 185BB43D55 for ; Fri, 11 Mar 2005 16:13:40 +0000 (GMT) (envelope-from demizu@dd.iij4u.or.jp) Received: from localhost (124.117.138.210.xn.2iij.net [210.138.117.124]) by r-dd.iij4u.or.jp (8.11.6+IIJ/8.11.6) with ESMTP id j2BGDZI26599; Sat, 12 Mar 2005 01:13:35 +0900 (JST) Date: Sat, 12 Mar 2005 01:14:11 +0900 (JST) Message-Id: <20050312.011411.26982743.Noritoshi@Demizu.ORG> From: Noritoshi Demizu To: Mark Tinguely In-Reply-To: <200503111459.j2BExesE087525@casselton.net> References: <20050311.202002.26516944.Noritoshi@Demizu.ORG> <200503111459.j2BExesE087525@casselton.net> X-Mailer: Mew version 4.1 on Emacs 21 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 4.x and OS-X tcp 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: Fri, 11 Mar 2005 16:13:41 -0000 > The Apple machine may be rate limiting their transmissions. > The Apple is sending only 2 packets per round trip time. I think (acknowledgment number + advertized window) of ACKs sent by the FreeBSD machine limits how much data the Mac can inject into the network. Regards, Noritoshi Demizu From owner-freebsd-net@FreeBSD.ORG Fri Mar 11 18:10:31 2005 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 1AE8616A4CE; Fri, 11 Mar 2005 18:10:31 +0000 (GMT) Received: from relay.bestcom.ru (relay.bestcom.ru [217.72.144.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 49C3E43D3F; Fri, 11 Mar 2005 18:10:30 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (root@cell.sick.ru [217.72.144.68]) by relay.bestcom.ru (8.13.1/8.12.9) with ESMTP id j2BIAR9k092634 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 11 Mar 2005 21:10:27 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.1/8.12.8) with ESMTP id j2BIAQcN090531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Mar 2005 21:10:26 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.1/8.13.1/Submit) id j2BIAPt0090530; Fri, 11 Mar 2005 21:10:25 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 11 Mar 2005 21:10:25 +0300 From: Gleb Smirnoff To: Luigi Rizzo Message-ID: <20050311181025.GB90472@cell.sick.ru> References: <200503011642.48813.jhb@FreeBSD.org> <20050301162949.A64187@xorpc.icir.org> <20050311110234.GA87255@cell.sick.ru> <20050311074448.A70328@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20050311074448.A70328@xorpc.icir.org> User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV version devel-20050125, clamav-milter version 0.80ff on relay.bestcom.ru X-Virus-Status: Clean cc: dima <_pppp@mail.ru> cc: pjd@FreeBSD.org cc: John Baldwin cc: rwatson@FreeBSD.org cc: net@FreeBSD.org cc: ru@FreeBSD.org Subject: Re: Giant-free polling [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: Fri, 11 Mar 2005 18:10:31 -0000 On Fri, Mar 11, 2005 at 07:44:48AM -0800, Luigi Rizzo wrote: L> while i am happy to see interest on having this supported, and while L> I understand the excitement in firing the editor and writing code, L> i don't think this approach of hacking up some patch that allows L> multiple poll* instances to run without panicing the box, or L> discussing the performance of lists vs arrays vs IFF_* flags will L> lead to anything. L> L> As I asked this already, consider this msg a rant, for archival L> purposes, calling for a sane approach to the problem. L> L> Polling in the UP case is beneficial because it has some features L> listed e.g. in L> L> http://docs.freebsd.org/cgi/getmsg.cgi?fetch=128950+0+/usr/local/www/db/text/2005/freebsd-net/20050306.freebsd-net L> L> For the SMP case there are the basic issues to handle (proper locking, L> preventing deadlocks) but also performance issues e.g. to avoid L> that multiple polling instances just fight for the lock but do L> nothing useful, see e.g. the case described in L> L> http://docs.freebsd.org/cgi/getmsg.cgi?fetch=71980+0+/usr/local/www/db/text/2005/freebsd-net/20050306.freebsd-net L> L> L> Now, if you want to approach the issue seriously, you need to: L> L> 1) _design_ a locking strategy for SMP polling -- design meaning L> provide a description in english, even a sketchy one, L> which will eventually end up in a manpage such as polling(4), L> or in the source file as a comment. L> Certainly a design is not C code or patches without comments from which L> one should figure out the overall picture. L> L> 2) evaluate how the design compares in terms of features (e.g. those listed L> in the first reference above) to the UP case. I am not L> saying one should implement all of them, but at least it must L> be clear how the two things are different, if they are. L> L> 3) evaluate how the design addresses (in terms of performance) L> the contention problems, of which the second reference above is L> probably just one but at least a very obvious one; L> L> 4) implement it -- and if you want it to be reviewed, please post L> the full code, not just differences -- the code will be terribly L> different to be human readable in terms of a diff; L> L> 5) optimise it -- e.g. deal with arrays vs lists, implicit vs L> explicit flags, etc. L> L> It seems to me that this whole discussion is proceding from step 4 L> and ignoring the first 3 steps. Please, step back from your keyboards L> and move to the whiteboard, if nothing else to prove me that you L> have already addressed all the issues. Luigi, at this moment we are doing step 0 - removing Giant lock from polling, to make its locking independent from other Giant-locked subsystems. There is no code for SMP polling yet, and we will take into account all what you say as soon as we approach SMP polling. In both our patches polling logic and implementation is not touched, it is only surrounded with locking. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Fri Mar 11 20:00:33 2005 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 5D71216A4CE; Fri, 11 Mar 2005 20:00:33 +0000 (GMT) Received: from mx2.mail.ru (mx2.mail.ru [194.67.23.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 888D843D1F; Fri, 11 Mar 2005 20:00:32 +0000 (GMT) (envelope-from hydros@mail.ru) Received: from [195.34.231.3] (port=1452 helo=D003.D-IP04.lipetsk.ru) by mx2.mail.ru with esmtp id 1D9qJC-000GlH-00; Fri, 11 Mar 2005 23:00:31 +0300 Date: Fri, 11 Mar 2005 22:59:43 +0300 From: hydros X-Mailer: The Bat! (v3.0) Professional X-Priority: 3 (Normal) Message-ID: <1775205851.20050311225943@mail.ru> To: freebsd-bugs@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam: Not detected cc: freebsd-net@freebsd.org Subject: natd core dumps on FreeBSD 5.3-stable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: hydros List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2005 20:00:33 -0000 Hello, All. Natd dumping its core without any additional messages\logs exclude this Mar 11 22:31:54 gw kernel: pid 217 (natd), uid 0: exited on signal 11 (core dumped)-/var/log/messages I`m using following configuration FreeBSD 5.3-stable 3 interfaces: ed0 to my ISP rl0-to my internal LAN-1 and LAN-2 LAN-2 has real ip adresses rl1 to my LAN-3 ------------------------- /etc/rc.conf -------------------------- # External interface address to my ISP ifconfig_ed0="inet 213.x.x.38 netmask 255.255.255.252" #Internal for my LAN-1 and LAN-2 rl0 ifconfig_rl0="inet 192.168.1.193 netmask 255.255.255.0" #LAN-1 ifconfig_rl0_alias0="inet 194.x.x.193 netmask 255.255.255.240"#LAN-2 #Internal for my LAN-3 rl1 ifconfig_rl1="inet 194.x.x.222 netmask 255.255.255.240" defaultrouter="213.x.x.37" hostname="gw" moused_enable="YES" sshd_enable="YES" gateway_enable="YES" firewall_enable="YES" firewall_type="OPEN" firewall_script="/etc/rc.firewall" natd_enable="YES" natd_program="/sbin/natd" natd_interface="rl0" #i`m using internal interface natd_flags="-reverse -unregistered_only -log" ----------------------- ifconfig -a------------------------------ ed0: flags=108843 mtu 1500 inet 213.x.x.38 netmask 0xfffffffc broadcast 213.x.x.39 inet6 fe80::x:x:fede:683e%ed0 prefixlen 64 scopeid 0x1 ether 00:80:48:de:68:3e rl0: flags=8843 mtu 1500 options=8 inet 192.168.1.193 netmask 0xffffff00 broadcast 192.168.1.255 inet6 fe80::x:x:x:ed02%rl0 prefixlen 64 scopeid 0x2 inet 194.x.x.193 netmask 0xfffffff0 broadcast 194.x.x.207 ether 00:80:48:14:ed:02 media: Ethernet autoselect (100baseTX ) status: active rl1: flags=8843 mtu 1500 options=8 inet 194.x.x.222 netmask 0xfffffff0 broadcast 194.x.x.223 inet6 fe80::x:x:fe14:dfe9%rl1 prefixlen 64 scopeid 0x3 ether 00:80:48:14:df:e9 media: Ethernet autoselect (none) status: no carrier plip0: flags=108810 mtu 1500 lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 ---------------- ipfw show ---------------------------- 00050 157 10434 divert 8668 ip from 192.168.1.0/24 to any via rl0 00055 0 0 divert 8668 ip from any to 192.168.1.0/24 via rl0 00100 0 0 allow ip from any to any via lo0 00200 0 0 deny ip from any to 127.0.0.0/8 00300 0 0 deny ip from 127.0.0.0/8 to any 65000 8533 1392765 allow ip from any to any 65535 0 0 allow ip from any to any ------------------------------------------------------- Feel free to answer directly to my e-mail. -- Best regards, hydros mailto:hydros@mail.ru From owner-freebsd-net@FreeBSD.ORG Fri Mar 11 21:14:39 2005 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 578AC16A4CE; Fri, 11 Mar 2005 21:14:39 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id B73D043D1D; Fri, 11 Mar 2005 21:14:38 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 8D7037A403; Fri, 11 Mar 2005 13:14:38 -0800 (PST) Message-ID: <42320A3E.1020708@elischer.org> Date: Fri, 11 Mar 2005 13:14:38 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en, hu MIME-Version: 1.0 To: Gleb Smirnoff References: <20050311110234.GA87255@cell.sick.ru> <20050311141450.GF9291@darkness.comp.waw.pl> <20050311142805.GB88801@cell.sick.ru> In-Reply-To: <20050311142805.GB88801@cell.sick.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: dima <_pppp@mail.ru> cc: Pawel Jakub Dawidek cc: John Baldwin cc: Luigi Rizzo cc: rwatson@freebsd.org cc: net@freebsd.org Subject: Re: Giant-free polling [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: Fri, 11 Mar 2005 21:14:39 -0000 Gleb Smirnoff wrote: >On Fri, Mar 11, 2005 at 03:14:50PM +0100, Pawel Jakub Dawidek wrote: >P> On Fri, Mar 11, 2005 at 04:55:25PM +0300, dima wrote: >P> +> I thought about using list also, but considered it to bring >P> +> too much overhead to the code. The original idea of handling arrays >P> +> seems to be very elegant. >P> >P> Overhead? Did you run any benchmarks to prove it? >P> I find list-version much more elegant that using an array. > >It is also a small cookie for future. Now we have IFF_POLLING flag and >IFCAP_POLLING, which indicate whether interface support polling and whether >it actually does polling. This is not nice, from my viewpoint. I'd like >to see only IFCAP_POLLING present and turning polling on/off for particular >interface should be done by inserting/removing iface from polling list. > >This will also remove an extra unlocked check of interface flags (?). > >P> I also don't like the idea of calling handler method with two locks >P> held (one sx and one mutex)... > >I agree with Pawel. We have LOR here between sx lock and driver lock: > > normal polling: (get sx shared) -> (get driver mutex) > driver stop: (get driver mutex) -> (get sx exclusive) > >We will have deadlock if this two things process in parallel. > >And the per-interface mutex protects only reentrancy of interface poll >method, is that right? > >P> There is still an unresolved problem (in your and our patch as well) of >P> using ifnet structure fields without synchronization, as we don't have >P> access tointerface's internal mutex, which protects those fields. > > you need to add an interface method that has access to it.. >This is unresolved in our patch, too, and I believe throughout many >other places in kernel. > > > From owner-freebsd-net@FreeBSD.ORG Fri Mar 11 21:35:48 2005 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 23EA816A4CE; Fri, 11 Mar 2005 21:35:48 +0000 (GMT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.136]) by mx1.FreeBSD.org (Postfix) with ESMTP id B0BC343D46; Fri, 11 Mar 2005 21:35:47 +0000 (GMT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id BE9BDAC956; Fri, 11 Mar 2005 22:35:44 +0100 (CET) Date: Fri, 11 Mar 2005 22:35:44 +0100 From: Pawel Jakub Dawidek To: Julian Elischer Message-ID: <20050311213544.GH9291@darkness.comp.waw.pl> References: <20050311110234.GA87255@cell.sick.ru> <20050311141450.GF9291@darkness.comp.waw.pl> <20050311142805.GB88801@cell.sick.ru> <42320A3E.1020708@elischer.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/rPfFJkZbotMxBE6" Content-Disposition: inline In-Reply-To: <42320A3E.1020708@elischer.org> User-Agent: Mutt/1.4.2i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 5.2.1-RC2 i386 cc: dima <_pppp@mail.ru> cc: John Baldwin cc: Luigi Rizzo cc: rwatson@freebsd.org cc: net@freebsd.org Subject: Re: Giant-free polling [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: Fri, 11 Mar 2005 21:35:48 -0000 --/rPfFJkZbotMxBE6 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 11, 2005 at 01:14:38PM -0800, Julian Elischer wrote: +> >P> There is still an unresolved problem (in your and our patch as well)= of +> >P> using ifnet structure fields without synchronization, as we don't ha= ve +> >P> access tointerface's internal mutex, which protects those fields. +> >=20 +> > +>=20 +> you need to add an interface method that has access to it.. I was thinking more about moving interface mutex into ifnet structure, but Robert has some objections IIRC. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --/rPfFJkZbotMxBE6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFCMg8wForvXbEpPzQRAkh/AKCj0CedBDkj1J1iiJrMEFeg0aNgIQCeNUtP C7m3RyQzPgBy/WKLQCUaPho= =2mCX -----END PGP SIGNATURE----- --/rPfFJkZbotMxBE6-- From owner-freebsd-net@FreeBSD.ORG Fri Mar 11 23:22:46 2005 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 6EAA516A4CE for ; Fri, 11 Mar 2005 23:22:46 +0000 (GMT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3408D43D48 for ; Fri, 11 Mar 2005 23:22:46 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.89] ([66.127.85.89]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j2BNMgms074798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Mar 2005 15:22:42 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <42322875.4030404@errno.com> Date: Fri, 11 Mar 2005 15:23:33 -0800 From: Sam Leffler Organization: Errno Consulting User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <20050311110234.GA87255@cell.sick.ru> <20050311141450.GF9291@darkness.comp.waw.pl> <20050311142805.GB88801@cell.sick.ru> <42320A3E.1020708@elischer.org> <20050311213544.GH9291@darkness.comp.waw.pl> In-Reply-To: <20050311213544.GH9291@darkness.comp.waw.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: dima <_pppp@mail.ru> cc: John Baldwin cc: Luigi Rizzo cc: rwatson@freebsd.org cc: Julian Elischer cc: net@freebsd.org Subject: Re: Giant-free polling [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: Fri, 11 Mar 2005 23:22:46 -0000 Pawel Jakub Dawidek wrote: > On Fri, Mar 11, 2005 at 01:14:38PM -0800, Julian Elischer wrote: > +> >P> There is still an unresolved problem (in your and our patch as well) of > +> >P> using ifnet structure fields without synchronization, as we don't have > +> >P> access tointerface's internal mutex, which protects those fields. > +> > > +> > > +> > +> you need to add an interface method that has access to it.. > > I was thinking more about moving interface mutex into ifnet structure, > but Robert has some objections IIRC. > I don't know what Robert's objections are but I've considered doing it for a while to deal with some locking issues in net80211-based drivers. The only issue I can see is if this mutex boxes drivers into a locking model that interlocks the rx+tx paths. Sam From owner-freebsd-net@FreeBSD.ORG Sat Mar 12 04:53:39 2005 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 235DC16A4CE for ; Sat, 12 Mar 2005 04:53:39 +0000 (GMT) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id CBFCB43D4C for ; Sat, 12 Mar 2005 04:53:38 +0000 (GMT) (envelope-from e.schuele@computer.org) Received: from [192.168.214.218] (c-24-1-232-64.client.comcast.net[24.1.232.64]) by comcast.net (rwcrmhc12) with ESMTP id <2005031204533801400jib9ee>; Sat, 12 Mar 2005 04:53:38 +0000 Message-ID: <423275FE.1050901@computer.org> Date: Fri, 11 Mar 2005 22:54:22 -0600 From: Eric Schuele User-Agent: Mozilla Thunderbird 1.0 (X11/20050127) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Problems stopping pptp... 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, 12 Mar 2005 04:53:39 -0000 Hello, This was originally posted to -Questions. I thought it would be a no brainer and get an immediate response. But I haven't heard from anyone yet, so I thought I'd post here too. I have some keybindings on my laptop that allow me to easily start and stop a pptp connection to my office. The binding are of no concern other than I would like to be able to start/stop pptp as a non-root user. It looks something like: Control Shift V opens the vpn using sudo pptp x.x.x.x OFFICE Alt Shift V closes the connection sudo killall -TERM ppp When I do this (stopping pptp) I get a pptp.core in my home dir. In fact no matter what I try... I allways end up with a core. I have tried: # as myself sudo killall -TERM ppp sudo kill -TERM `cat /var/run/tun0.pid` sudo killall -TERM pptp Also tried those as root (without sudo). I have tried all of the above after issuing the pptp command from CLI as root. Still no luck I have also tried other signals (QUIT, ABRT). So... the question is.. How am I supposed to shut down a pptp connection? I would like to be able to do it with sudo, or at least some way to bind it to keys of non-root users. Thanks, -- Regards, Eric From owner-freebsd-net@FreeBSD.ORG Sat Mar 12 12:24:36 2005 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 741CD16A4CE; Sat, 12 Mar 2005 12:24:36 +0000 (GMT) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF20E43D53; Sat, 12 Mar 2005 12:24:35 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with SMTP id A319C46B6C; Sat, 12 Mar 2005 07:24:35 -0500 (EST) Date: Sat, 12 Mar 2005 12:22:09 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Pawel Jakub Dawidek In-Reply-To: <20050311213544.GH9291@darkness.comp.waw.pl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: dima <_pppp@mail.ru> cc: John Baldwin cc: Luigi Rizzo cc: Julian Elischer cc: net@freebsd.org Subject: Re: Giant-free polling [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: Sat, 12 Mar 2005 12:24:36 -0000 On Fri, 11 Mar 2005, Pawel Jakub Dawidek wrote: > On Fri, Mar 11, 2005 at 01:14:38PM -0800, Julian Elischer wrote: > +> >P> There is still an unresolved problem (in your and our patch as well) of > +> >P> using ifnet structure fields without synchronization, as we don't have > +> >P> access tointerface's internal mutex, which protects those fields. > +> > +> you need to add an interface method that has access to it.. > > I was thinking more about moving interface mutex into ifnet structure, > but Robert has some objections IIRC. My specific concern was to make sure that we don't lock device driver writers into a locking model that forces them to protect the device driver with a single mutex. There are changes floating around to protect the if_em receive and transmit components separately, since the're basically independent hardware units and can be accessed from multiple CPUs in parallel. This is also, I believe, what several Linux device drivers do. So I'm OK with a multi-layer mutex in ifnet protecting ifnet and device driver data, but only if we don't preclude the parallelism benefits that can be attained as suggested above. Robert N M Watson From owner-freebsd-net@FreeBSD.ORG Sat Mar 12 15:15:06 2005 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 E361516A4CE for ; Sat, 12 Mar 2005 15:15:06 +0000 (GMT) Received: from parrot.aev.net (host29-15.pool8174.interbusiness.it [81.74.15.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4DCCB43D41 for ; Sat, 12 Mar 2005 15:15:05 +0000 (GMT) (envelope-from ml.diespammer@netfence.it) Received: from soth.ventu (adsl-125-24.37-151.net24.it [151.37.24.125]) (authenticated bits=128) by parrot.aev.net (8.13.1/8.13.1) with ESMTP id j2CFWqGL051854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 12 Mar 2005 16:33:04 +0100 (CET) (envelope-from ml.diespammer@netfence.it) Received: from netfence.it (xanatar.ventu [10.1.2.6]) (authenticated bits=0) by soth.ventu (8.13.3/8.13.1) with ESMTP id j2CFDcAV050799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 12 Mar 2005 16:13:38 +0100 (CET) (envelope-from ml.diespammer@netfence.it) Message-ID: <423307B8.8020406@netfence.it> Date: Sat, 12 Mar 2005 16:16:08 +0100 From: Andrea Venturoli Organization: NetFence User-Agent: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.6) Gecko/20040117 X-Accept-Language: it,en,fr,de MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.45 Subject: ipfw verbosity 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, 12 Mar 2005 15:15:07 -0000 Hello. I noticed that when I issue "sh /etc/rc.firewall" to reload firewall rules from a remote console, I get disconnected (as I would expect) and locked out! The problems seems to be that "ipfw -f" prints: "command is /usr/local/...". This is in /usr/src/sbin/ipfw/ipfw2.c: fprintf(stderr, "command is %s\n", av[0]); This line does not onor the "-q" flag which, if I understand correctly, was exactly meant to allow this kind of operations without console access. Naturally, I can comment this line in my sources, but I was asking myself if this should be regarded as something to fix. bye & Thanks av. From owner-freebsd-net@FreeBSD.ORG Sat Mar 12 16:55:09 2005 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 A74CE16A4CE for ; Sat, 12 Mar 2005 16:55:09 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92FBC43D1F for ; Sat, 12 Mar 2005 16:55:08 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 83206 invoked from network); 12 Mar 2005 16:28:00 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.54]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 12 Mar 2005 16:28:00 -0000 Message-ID: <42331EED.D7714E05@freebsd.org> Date: Sat, 12 Mar 2005 17:55:09 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sam Leffler References: <20050311110234.GA87255@cell.sick.ru> <20050311141450.GF9291@darkness.comp.waw.pl> <42320A3E.1020708@elischer.org><42322875.4030404@errno.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: dima <_pppp@mail.ru> cc: Pawel Jakub Dawidek cc: John Baldwin cc: Luigi Rizzo cc: rwatson@freebsd.org cc: Julian Elischer cc: net@freebsd.org Subject: Re: Giant-free polling [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: Sat, 12 Mar 2005 16:55:09 -0000 Sam Leffler wrote: > > Pawel Jakub Dawidek wrote: > > On Fri, Mar 11, 2005 at 01:14:38PM -0800, Julian Elischer wrote: > > +> >P> There is still an unresolved problem (in your and our patch as well) of > > +> >P> using ifnet structure fields without synchronization, as we don't have > > +> >P> access tointerface's internal mutex, which protects those fields. > > +> > > > +> > > > +> > > +> you need to add an interface method that has access to it.. > > > > I was thinking more about moving interface mutex into ifnet structure, > > but Robert has some objections IIRC. > > > > I don't know what Robert's objections are but I've considered doing it > for a while to deal with some locking issues in net80211-based drivers. > The only issue I can see is if this mutex boxes drivers into a locking > model that interlocks the rx+tx paths. We don't want this. This would paint us into a corner with modern high speed hardware that can hanle the rx+tx paths simulaneously. Depending on the hardware DMA model and driver architecture you want to have a different locking model. I agree with Robert in objecting to this. -- Andre From owner-freebsd-net@FreeBSD.ORG Sat Mar 12 17:02:35 2005 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 63A8116A4CE for ; Sat, 12 Mar 2005 17:02:35 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id CCA0243D1D for ; Sat, 12 Mar 2005 17:02:34 +0000 (GMT) (envelope-from chrcoluk@gmail.com) Received: by rproxy.gmail.com with SMTP id a41so1124454rng for ; Sat, 12 Mar 2005 09:02:25 -0800 (PST) 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=iZZufRyfZhJmmT+v7GgZ1XP4mOXt9uYiW4F9ZHlAEmNUSN/3eNaU0VTcR1Nb1USMyIK0LKoUalBAdFpDiEtWKE7paNmjbm6eIf0pFIcBbXx/CiqZEQSRYFzHxSKroslXuBDEgUQBazZ9GtPjNDrpEr8VyzbjNrm5dZPCqqcq2XY= Received: by 10.38.90.20 with SMTP id n20mr3634032rnb; Sat, 12 Mar 2005 08:54:34 -0800 (PST) Received: by 10.39.1.32 with HTTP; Sat, 12 Mar 2005 08:54:34 -0800 (PST) Message-ID: <3aaaa3a0503120854d06ada7@mail.gmail.com> Date: Sat, 12 Mar 2005 16:54:34 +0000 From: Chris To: Andrea Venturoli In-Reply-To: <423307B8.8020406@netfence.it> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <423307B8.8020406@netfence.it> cc: freebsd-net@freebsd.org Subject: Re: ipfw verbosity X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Chris List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2005 17:02:35 -0000 I noticed when using check-state, the ssh session will die because the dynamic rules are flushed on the firewall reload. I can of course connect again right away. When using allow from established this problem doesnt occur and my ssh stays alive. What I would like is a way to flush only static rules and leave dynamic rules alone, this would enable me to use check-state again. Chris On Sat, 12 Mar 2005 16:16:08 +0100, Andrea Venturoli wrote: > Hello. > > I noticed that when I issue "sh /etc/rc.firewall" to reload firewall > rules from a remote console, I get disconnected (as I would expect) and > locked out! > > The problems seems to be that "ipfw -f" prints: "command is /usr/local/...". > > This is in /usr/src/sbin/ipfw/ipfw2.c: > > fprintf(stderr, "command is %s\n", av[0]); > > This line does not onor the "-q" flag which, if I understand correctly, > was exactly meant to allow this kind of operations without console access. > > Naturally, I can comment this line in my sources, but I was asking > myself if this should be regarded as something to fix. > > bye & Thanks > av. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Sat Mar 12 17:16:52 2005 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 A7BE116A4CE; Sat, 12 Mar 2005 17:16:52 +0000 (GMT) Received: from stephanie.unixdaemons.com (stephanie.unixdaemons.com [67.18.111.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 00D7843D48; Sat, 12 Mar 2005 17:16:52 +0000 (GMT) (envelope-from bmilekic@technokratis.com) Received: from stephanie.unixdaemons.com (bmilekic@localhost.unixdaemons.com [127.0.0.1])j2CHGmVR018359; Sat, 12 Mar 2005 12:16:48 -0500 (EST) Received: (from bmilekic@localhost) by stephanie.unixdaemons.com (8.13.3/8.12.1/Submit) id j2CHGmGs018358; Sat, 12 Mar 2005 12:16:48 -0500 (EST) (envelope-from bmilekic@technokratis.com) X-Authentication-Warning: stephanie.unixdaemons.com: bmilekic set sender to bmilekic@technokratis.com using -f Date: Sat, 12 Mar 2005 12:16:48 -0500 From: Bosko Milekic To: Pawel Jakub Dawidek Message-ID: <20050312171648.GA12186@technokratis.com> References: <20050311110234.GA87255@cell.sick.ru> <20050311141450.GF9291@darkness.comp.waw.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050311141450.GF9291@darkness.comp.waw.pl> User-Agent: Mutt/1.4.2.1i cc: dima <_pppp@mail.ru> cc: John Baldwin cc: Luigi Rizzo cc: Gleb Smirnoff cc: ru@FreeBSD.org cc: net@FreeBSD.org cc: rwatson@FreeBSD.org Subject: Re: Giant-free polling [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: Sat, 12 Mar 2005 17:16:52 -0000 On Fri, Mar 11, 2005 at 03:14:50PM +0100, Pawel Jakub Dawidek wrote: > On Fri, Mar 11, 2005 at 04:55:25PM +0300, dima wrote: > +> I thought about using list also, but considered it to bring > +> too much overhead to the code. The original idea of handling arrays > +> seems to be very elegant. > > Overhead? Did you run any benchmarks to prove it? > I find list-version much more elegant that using an array. You should however be aware that iterating over an array of references as opposed to a list in the polling path, if you only consider the cost of iteration itself, is faster on both SMP and UP. With the list approach, you will have to bring in at least three items into cache, at each iteration: (1) The list node; (2) The list node's member (the 'pr' reference data in your patch); (3) The device's mutex. With the array approach, you will remove (1). If the relative frequency of insertions and removals is low (which I think it is in the polling case), you ought to consider doing the array thing (considering the predictable scheduling nature of polling, you could use the cache advantages due to the use of the array). Also, you will still be able to implement dynamic removal/insertion from/to the polling array. The fact that it is an array might just require re-allocation, not a big deal. > I also don't like the idea of calling handler method with two locks > held (one sx and one mutex)... Yeah, this should be re-worked. However, the use of the sx lock is neat. Unfortunately, our sx lock implementation always resorts to using a regular mutex lock, even when doing a shared lock (read only) acquisition. Since the window of the underlying sx lock mutex is relatively short, in most cases the performance advantage of using the sx lock is noticable. However, if the window of the original mutex is also short (compared to the sx lock window), then I wonder if it is worth it. The sx lock is really only designed for optimizing long-reads, in our case. Regards, -- Bosko Milekic bmilekic@technokratis.com bmilekic@FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Sat Mar 12 18:26:44 2005 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 EB30216A4CE; Sat, 12 Mar 2005 18:26:44 +0000 (GMT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 924F343D1D; Sat, 12 Mar 2005 18:26:44 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.91] (sam@[66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j2CIQems081443 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 12 Mar 2005 10:26:42 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <423334C4.9060401@errno.com> Date: Sat, 12 Mar 2005 10:28:20 -0800 From: Sam Leffler User-Agent: Mozilla Thunderbird 1.0RC1 (X11/20041208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andre Oppermann References: <20050311110234.GA87255@cell.sick.ru> <20050311141450.GF9291@darkness.comp.waw.pl> <20050311142805.GB88801@cell.sick.ru> <42320A3E.1020708@elischer.org> <20050311213544.GH9291@darkness.comp.waw.pl> <42322875.4030404@errno.com> <42331EED.D7714E05@freebsd.org> In-Reply-To: <42331EED.D7714E05@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: dima <_pppp@mail.ru> cc: Pawel Jakub Dawidek cc: John Baldwin cc: Luigi Rizzo cc: rwatson@freebsd.org cc: Julian Elischer cc: net@freebsd.org Subject: Re: Giant-free polling [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: Sat, 12 Mar 2005 18:26:45 -0000 Andre Oppermann wrote: > Sam Leffler wrote: > >>Pawel Jakub Dawidek wrote: >> >>>On Fri, Mar 11, 2005 at 01:14:38PM -0800, Julian Elischer wrote: >>>+> >P> There is still an unresolved problem (in your and our patch as well) of >>>+> >P> using ifnet structure fields without synchronization, as we don't have >>>+> >P> access tointerface's internal mutex, which protects those fields. >>>+> > >>>+> > >>>+> >>>+> you need to add an interface method that has access to it.. >>> >>>I was thinking more about moving interface mutex into ifnet structure, >>>but Robert has some objections IIRC. >>> >> >>I don't know what Robert's objections are but I've considered doing it >>for a while to deal with some locking issues in net80211-based drivers. >> The only issue I can see is if this mutex boxes drivers into a locking >>model that interlocks the rx+tx paths. > > > We don't want this. This would paint us into a corner with modern > high speed hardware that can hanle the rx+tx paths simulaneously. > Depending on the hardware DMA model and driver architecture you > want to have a different locking model. I agree with Robert in > objecting to this. > You did not read what I wrote. The ath driver has separate tx+rx paths and it could benefit from the mutex being in the ifnet structure. Sam From owner-freebsd-net@FreeBSD.ORG Sat Mar 12 20:44:35 2005 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 8B97216A4CE for ; Sat, 12 Mar 2005 20:44:35 +0000 (GMT) Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by mx1.FreeBSD.org (Postfix) with SMTP id BE39943D49 for ; Sat, 12 Mar 2005 20:44:34 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 54475 invoked from network); 12 Mar 2005 20:44:33 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 12 Mar 2005 20:44:33 -0000 X-pair-Authenticated: 209.68.2.70 Date: Sat, 12 Mar 2005 14:44:32 -0600 (CST) From: Mike Silbersack To: Anthony Atkielski In-Reply-To: <771770969.20050311034646@wanadoo.fr> Message-ID: <20050312144141.P15599@odysseus.silby.com> References: <771770969.20050311034646@wanadoo.fr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-net@freebsd.org Subject: Re: Clock slew vulnerability in FreeBSD? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2005 20:44:35 -0000 On Fri, 11 Mar 2005, Anthony Atkielski wrote: > > How vulnerable is FreeBSD to the recently announced technique for > individually identifying computers by the clock slew apparent in TCP > packets? If it is vulnerable to this, will there be any plans to > address the vulnerability? > > -- > Anthony I finally read the paper (instead of just reading the abstract), and I must say that it's a lot more interesting than I would have expected it to be. Defeating this technique would be relatively easy to do, but there are a lot of other much easier ways to identify FreeBSD machines right now. Once those are fixed, then this can be worried about. (For example, we send the same TCP timestamps to all hosts right now; no need to measure clock skew!) Mike "Silby" Silbersack